Archive for August, 2011

List Active Directory sites and their associated subnets

Thursday, August 25th, 2011

If you ever need to look up which subnet is associated with which active directory site then just paste the below into vbs and pipe its output to a text file.

‘Get list of AD subnets
Set oRootDSE = GetObject(“LDAP://RootDSE”)
sConfigurationNC = oRootDSE.Get(“configurationNamingContext”)
Set oRootDSE = Nothing
sSubnetsContainer = “LDAP://cn=Subnets,cn=Sites” & “,” & sConfigurationNC
Set oSubnetsContainer = GetObject(sSubnetsContainer)
For Each sResult In oSubnetsContainer
aSNInfo = Split(, “/”)
If Instr(sResult.siteObject, “,”) = 0 Then
sSN = aSNInfo(0)
sSN = aSNInfo(0) & “,” & _
Mid(Left(sResult.siteObject, Instr(sResult.siteObject, “,”) – 1), 4)
End if
wscript.echo ssn

If you name the script listsites.vbs and want to output to a file call sitelist.csv and the script sites in a folder called “support” you can just run the following command line.

cscript c:\support\listsites.vbs > c:\support\sitelist.csv

Deploying the Configuration Logging Database in XenApp 6

Tuesday, August 23rd, 2011

This blog post will walk you through deploying the configuration logging database in XenApp 6. I’ll be deploying the database on SQL 2008 SP1 running on Windows 2008 SP2 32 bit.

The first thing to do is create a standard domain account to own and connect to the SQL server database. I’ll call my account svcConfigLogging. The account should be set so that its password never expires.


Next, we create a blank database in SQL. I have called mine XAConfigLogging. You should follow best practice by pre-setting the database and log file sizes, holding them on separate disks, setting up backup plans etc.


We now add the service account created above (svcConfigLogging) to SQL as a logon. The default database for the logon is set to the database created above (XAConfigLogging).


Grant the user “db_owner” role access privileges.


As the database and security are created we can now use the Delivery Services Console to create the tables and objects in the database and the connection. To do this, right click the farm name and choose “Farm Properties”.



Select Configuration Logging and then click on the “Configure Database” button.


Enter the fully qualified domain name (FQDN) or IP address of the SQL server hosting the database created above (XAConfigLogging) and the credentials of the account created earlier which has db_owner rights to that database (svcConfigLogging).


Select the database created above (XAConfigLogging)

Change use Encryption to “No” (use of encryption requires the use of SSL certificates. As these are not in place a connection error will be generated).


Click on the “Test Database Connection” button

The connection should be successful (if it isn’t you will need to go back and check the settings entered).

Clicking on “Finish” will return you to the configuration screen.

The balance of the settings can now be configured. If you do not tick the “Log administrative tasks to Configuration Logging Database” then configuration logging does not take place.

Click on OK to complete configuration.

You can now make changes to the configuration of XenApp and they will be recorded to the database.

To view changes made to the configuration select the “History” node in the Delivery Services Console.



Clicking on the “Set Filter” link allows the SELECT statement to retrieve from the database to be constructed using the GUI.

Clicking on the “Get Log” link will retrieve the changes made within the constraints of the filter applied.


“Standard” administrators will have their changes logged to the database but will not be able to read from the database by default (i.e. will not be able to retrieve the log in history). To do this they need to be granted EXECUTE permissions against the stored procedures for the XAConfigLogging database.


The permissions required for administrators to the database are detailed at If security is not a concern then administrators can be granted db_owner rights to the database. Granting of rights is most easily achieved using domain groups.

How to reset the admin password for Citrix Licensing Server

Monday, August 22nd, 2011

Sometimes the Citrix licensing server doesn’t get accessed for a long time, maybe the admin leaves and is replaced and no-one made a note of the password. Suddenly, you can’t access the licensing server any more. What to do ?

If you have access to the disk sub system (ie.. the files) on the licensing server then it is possible to reset the admin password.

1. Open the “server.xml” file in C:\Program Files\Citrix\Licensing\LS\conf. If on Win2k8 you will need to open your editor as an admin. (Take a copy of the file first – if anything goes wrong you can simply copy the file back to restore the original settings).

2. Find the entry that looks something like this:

<user firstName=”System” id=”admin” lastName=”Administrator” password=”(ENC-01)LKJ338u98uxkllS(*U+ljljlja-$78923ghJgs” passwordExpired=”false” privileges=”admin”/>;

3. Erase the contents between the double quotes after “password=”

4. Enter a plain text password , for example password=”TemporaryPassword”

5. Change the passwordExpired value to be “true” and save the server.xml file.

6. Restart the licensing services or, at a push, reboot the server.

7. Log into the licensing console using user name “admin” and the password set above.

8. You will be prompted to change your password. The new password will be encrypted in the server.xml file.

Installing applications to XenApp that require a reboot

Sunday, August 14th, 2011

When you install applications to XenApp you place the server into “install” mode (using change user /install) to start recording per user registry key changes to the shadow key (HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software).

Occasionally the software installation requires a reboot part way through before continuing the installation. However, when you reboot the server is placed back into execute mode and changes are no longer recorded. But, you can’t place the server back into install mode before the installation continues.

What to do ?

One way the server knows how to continue the software installation after a reboot is to write the string to the RunOnce key at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce. So, you can simply delete the appropriate part of this key, reboot the server, place it back into install mode and then manually run the command that was originally written to this key.

In this way you can still capture the changes made.

Other keys to check (just in case the installer utilises these keys) are: