I noticed that XenApp 5 Feature Pack comes with a new version of the Web Interface (5.2) (it is also available as standalone download). The parameters to install it in silent mode have changed but there’s no documentation at all on the Citrix Site:

(more…)

convert this post to pdf.

A few days ago I noticed that an unattended installation of Citrix XenApp 5 was installing very slowly. When I looked at the various jobs and their installation time in the (Altiris) Deployment Server I saw that it was the Citrix Access Management Console that took almost 45 minutes to install:

It was clear that this wasn’t normal since the install job is taking installing OS components like IIS and all subcomponents, activating Application Server and reboot in around 9 minutes. The installation of Citrix XenApp itsself takes only 14 minutes.

I searched with Google and one of the first links was this knowledge base article from Citrix: Slow Access Management Console Installation on XenApp 5.0. The article clearly describes that the delay is occurred by failing checks for Publisher’s and Server Certificate Revocation (because there’s no Internet Connection) and suggests to turn these checks off. Indeed my servers do not have a direct internet connection so the cause and solution were clear.

And actually I had seen similar issues before in other (non Citrix) installations, some examples are Exchange 2007 (here and here) and SQL Server 2008 (the SQL Installer actually checks if there’s an internet connection in the prerequisites check).

The suggested, manual way, of turning of these checks is to clear the following checkboxes in Internet Explorer’s advanced settings Dialog:

But since I had to do this on many servers I decided it would be better to do it with a little VBS script.

(more…)

convert this post to pdf.

I was deploying an unattended installation of Citrix XenApp 5.0 with Altiris Deployment Server. The installation consists of several prerequisites, the installation of XenApp and finally the Citrix Management Consoles.

The installation is performed with a special account and not the Local System account because the install packages are located on the network.

When testing the deployment on a Windows Server 2008 I noticed that sometimes MSI based installations would fail with error code 1603 or 1601.

(more…)

convert this post to pdf.