Inventory script for installing a Rollup Pack

In the log file, the server with and without the rollup package are now separated into two separate lists (the hots are ordered alphabetically)

-----
12/01/2010
-----
If you're passing a Rollup Pack on a farm PS 4.0 (in our case), and want to know the progress of the installation of Rollup Pack on your farm.
Farm_RollupV1.wsf script allows you to list all member servers of a farm, and tells you if the rollup pack is installed or not on each server.
In the script you change the variable MyRollup line 70, to specify the Rollup Pack that you want to inventory.
Once the script is executed, a file named XenApp_NomDeVotreFerme-MyRollup.txt is created at the root of C: (you can change the name and location of lines 74 and 77).
List of servers with Rollup Pack installed (in the example the Rollup Pack 6 for PS 4.0)
If the Rollup Pack is not installed (in the example Rollup Pack 05 for a PS 4.0)

At the end of the file you have three totals:

• Total servers with Rollup pack installed

• Total servers without the Rollup Pack

• Total farm member servers

Be kind to the code

Post Active Directory Cmdlets

Easter Egg XenApp

At a bend in PS 4.0 troubleshooting, one of our colleagues (AF) came across a pretty cool Easter Egg.
On a server PS 4.0, XenApp 4.5 or 5.0 (tested on a server in 2003), type the command line: query CITR! X

And you get the list of team engineer Citrix .
Our screenshot was made on a XenApp 5.0, the list differs depending on the version of course .
Looking in the registry is actually found in "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Terminal Server \ Utilities \ query" value "CITR" x ".
This Easter Egg was already posted in eeggs.com (in particular), how do we pass rate .
It seems that Windows 2008 does not work without the kb958652 .

Remove a server or application via DsCheck.exe

Sometimes your DataStore contains corrupted records.

In our case a server whose registration was corrupted.
The only way (accessible) can check the status of your DataStore is the use of DsCheck.exe (dscheck command allows you to validate the consistency of the DataStore and can repair inconsistencies found).
A prior backup of the DataStore is recommended .
Commands to delete an application in the DatasStore:

dscheck / full Apps "App Name" / deleteMF / SILENT dscheck / full Apps "App Name" / deleteComApp / SILENT

Commands to remove a server in the DatasStore:

dscheck / full servers "Server HostName" / deleteMF / SILENT dscheck / full servers "Server HostName" / deleteComApp / SILENT

The / DeleteMF deletes the entry of the record in the DataStore
The / DeleteComApp removes the common input in the DataStore.
If you want more information on DsCheck.exe:
CTX124406 (XenApp 4.5 / 5 for Windows 2003 32/64 Bits)
CTX107800 (Presentation Server 3.0/4.0 for Windows 2000/2003)

License Server 11.6.1 Admin Login Fails - The User name or password is incorrect.

Need to reset the password for admin user. (The default user name and password is admin. All the characters must be in lower case. It doesn't support any upper case)

Solution :  

1) Open the "server.xml" file in <system drive>:\Program Files\Citrix\Licensing\LS\conf. If on Win2k8 you will need to open your editor as an admin.

2) Find the entry that looks something like this:
<user firstName="System" id="admin" lastName="Administrator" password="(ENC-01)UaFz17cJ2oNQ+LkskjkzUyVV5ZcmaoJCDCiuiusbB6zk2P0uR" passwordExpired="false" privileges="admin"/>;

3) Erase the contents between the double quotes after "password="
4) Enter a plaintext password so it looks like this: password="test"
5) Change the passwordExpired value to be "true"
6) Save the server.xml file.
7) Restart the licensing services. I also closed and re-opened the LAC but this may not be necessary.
8) Log into the LAC using user name "admin" and the password you set.
9) You will be prompted to change your password. Do it. By doing it, the new password will be encrypted in the server.xml file.
10) To check that everything is working as planned, re-open the server.xml to check that the password is now encrypted.

Deploying a Pre-Configured Citrix Client using Active Directory

This article will show you how to create a pre-configured Citrix Client and leverage Active Directory to deploy the client as well as overcome some of the idiosyncrasies found in the Citrix Client packager.

Download any Xenapp Client from here.

This article will show you how to create a pre-configured Citrix Client and leverage Active Directory to deploy the client. You may ask, “Why would I want to use Active Directory to deploy the client. Doesn’t Citrix offer the Auto Client Update?” The answer is yes, Citrix does provide an auto client update feature, but there are limitations such as:

If a workstation already has a Citrix client that was installed from an .msi package, then you cannot use the Auto Client Update feature.

From page 90 of the Citrix client Administrator’s Guide:
“Important You cannot automatically update previous versions of the client installed with Windows Installer (.msi) packages. You must redeploy a client installer package when a new version of the client is released.”

Also, refer to Citrix Article CTX108584.
The Auto Client Update feature also adds steps to the logon process since it has to check to see if the workstation has an up-to-date client. This can cause longer login times and user frustration. In fact, I recommend you turn off the Auto Client Update feature via a Citrix policy:

Getting Started
Tools Needed:

• Citrix Presentation Server Client Packager
• ORCA to modify the MSI file (today’s trivia, ORCA stands for One Really Cool Application)
• Citrix Transform File to enable Single Sign On in the MSI file (optional)

The first thing you will need to do is get the Citrix Presentation Server Client Packager. You can download the latest Citrix Client Packager at http://www.citrix.com/download. The Citrix Client Packager contains the Citrix Program Neighborhood client, the Citrix Web client, and the Citrix Program Neighborhood Agent client.

Quote from Citrix:
You can customize the client packager to deploy and maintain any number and combination of clients network-wide. Based on Windows Installer technology (msi), the client packager lets you install, uninstall, modify, and repair clients as well as perform controlled client upgrades. An easy-to-use wizard guides you through the configuration step by step.

Create an Admin Install of the Citrix Client Packager
This is the part where you pre-configure the client(s).
Run msiexec /a Ica32Pkg.msi to create an administrative install of the package.
Note: this doesn’t actually install the client; it just creates the customized client installation files.

Select the “Uncompressed” option if you want to make modifications to the files (such as branding the client).
For this exercise, I have chosen not to install the full Program Neighborhood Client.

Important: If you elect to use the Local Name and Password, you will need to modify the MSI file using a transform (MST) file in order for this to work. More on this later.

In this example, I removed all the dialog boxes. It is not necessary to show any dialogs since we are going to push this client via Active Directory.

Making Post Setup Modifications
There are a couple of common post setup modifications that need to be made for the options I chose in this exercise. The first modification involves a bug in the client packager. If you specify not to install the Program Neighborhood client (as I chose not to in this exercise), it will still be installed to the workstation anyway as “Install on Demand” (see Citrix Article CTX105642).
So, to get around this, you will need to modify the MSI file by following these steps:

• Launch ORCA.
• Open the admin install MSI file (Ica32Pkg.msi) created earlier.
• Select the Condition table.
• Change the condition to “Not Installed” for the Program Neighborhood client.

There is another “feature” in the client packager that puts an icon for Program Neighborhood on the workstation desktop even if you chose not to install Program Neighborhood (see Citrix Article CTX108212)
So, once again, it’s ORCA to the rescue:

• Launch ORCA.
• Open the admin install MSI file (Ica32Pkg.msi) created earlier.
• Select the Shortcut table.
• Right click the row with “DesktopFolder…” in the Directory column and select Drop Row.

Enable Single Sign On for Active Directory Deployment
There is yet another “feature” in the client that disables single sign on in the client when deploying via Active Directory (see Citrix article CTX103439). As the article states, you will need to apply a transform (MST) in order for Single Sign On to work.

• Download slfregfix.mst from http://support.citrix.com/article/entry.jspa?entryID=3936
• Launch ORCA
• Open the Ica32Pkg.msi file created above.
• Select Transform -> Apply Transform…
• Browse to slfregfix.mst.
• Click on File -> Save Transformed As… and save the package as a different name (such as mod_Ica32Pkg.msi).

Deploy the Package with Active Directory
Finally, after all the blood sweat and tears to create the admin install client package, you can deploy the package with Active Directory. The question you must answer here is do you want to assign or publish this package? Also, if you assign the package, do you want to assign it to computer or user objects? In this exercise, I assigned the package to computer objects. (For more information about assigning and publishing packages via a GPO with Active Directory, check out Active Directory® for Microsoft® Windows® Server 2003 Technical Reference)

 I strongly suggest you toughly test this in a separate test environment if you have one. If you do not have a separate test environment, at least create a test OU in your Active Directory to try this out.

• Open up Active Directory Users and Computers.
• Right click on the OU you want to use to host the GPO to deploy the package and select Properties
• Select the Group Policy tab.
• Click edit to edit an existing Group Policy or New to create a new Group Policy. (Again, I suggest creating a new GPO for testing purposes).
• Browse to Computer Configuration -> Software Settings -> Software installation.
• Right click Software installation and select New -> Package.
• Browse to the package created above.
• Select Assigned on the Deploy Software Dialog.

Now, any computer object you move into this OU will automatically have the pre-configured Citrix ICA client installed upon logon (I suggest you only try moving a few computer objects into the OU for testing purposes). 

Publishing Network Application from a Mapped Drive Fails in XenApp 6

Symptoms
A published application is running from a network share as a mapped drive. In this example, the path to the executable is W:\windows\system32\notepad.exe. Launching the published application from a XenApp 6 2008 R2 servers and gives the following error(s).
“Citrix online plug-in could not contact the server. Please check your network connection.”

“The remote server failed to execute the application launch request. Please contact your administrator for further details.

The online plug-in does an application refresh. The server event viewer show an error similar the one below:
“Application XYZ is published to the server X, but the command line “w:\windows\system32\notepad.exe” is not valid on X. Verify the correct servers and/or work groups are assigned to XYZ and ensure that the application is installed on X.
Where XYZ is the application name and X is the server name.

For the application to launch, the drive must first be mapped for the user launching the session. There is no problem launching the application in a published desktop, but a published application fails.
Cause
XenApp 6 adds a new check called the Application Installation Check during load balancing to ensure that the published application exists on the server being returned by load balancing. The Citrix Services Manager service now ensures that the file specified in the application’s command line exists on the server selected by load balancing. If this check fails, you will see the error message listed above in the event log of the server.
Note: Because the application installation check is performed before the user’s session is created, user environment variables can no longer be used in an application’s command line. Only system environment variables are supported in XenApp 6.
The application installation check will retry load balancing up to five times to return a valid server to the user. This check is intended to prevent a few misconfigured servers from creating a black hole condition in the XenApp farm. However, administrators should always make sure that applications are installed at the correct locations on the correct servers, and not rely on this check for day-to-day load balancing.
Resolution
Publish a batch file that maps the network drive and then calls the application. You could also publish the path through UNC, but certain applications require a drive letter and are also run from a network share.
A simple batch file for this example could be something like the following code:
net use w: \\server-name\share-name
w:\windows\system32\notepad.exe
Name this batch file “my-app.cmd” and save it to a local drive such as C:\. In the published application location, point to the batch file rather than the network drive location.
This is by design in XenApp 6.0 because of the new Application Installation Check feature explained above.
for more info check -> http://support.citrix.com/article/CTX125104