It turns out that, when the site is created NetScaler records the GSLB local site IP in its list of IP addresses. The RTM version of NetScaler 10.0 (build 54.6) has a bug in that it doesn’t delete this IP address.

Bacause a Global Site IP already exists, you cannot “add” another one. So, if you need to change the IP address used for the local GSLB site, you just need to delete the IP address recorded here and you are good to go. The other choice it to update the firmware to the current version as this bug is fixed in build 54.7.

http://lmgtfy.com/?q=How to use Google

There are many reasons this may occur but I have noticed it always occurs with the latest version of the licensing server 11.10 whether you have specified the correct Product Type or not. The work around for me was to choose “Select the model at a later time”

This will let you complete the wizard. You can then use Citrix policies to set the license server location, port and model type at which point everything works.

This sort of stops you being able to update the device IP address to configure it further. To get the configuration menu back, simply type in configns and press return.

The above are for individual disks or those configured in RAID 0. Don’t forget to take account of your RAID penalty !

This blog post details installing Desktop Director in a pure XenApp environment. My XenApp server is running Xenapp 6.5. The process itself is relatively simplistic but the first thing you need to do is get a copy of the software. This is available in the downloads section of the Citrix site, just log on with your MyCitrix id, browse to XenApp 6.5 (I access Enterprise Edition) and expand out the language you prefer. You should see a link like the below:

This separate iso contains the installation binaries. Simply access the ISO (burn it to disk or present it up to your VM etc) and open the Desktop Director folder. Double click on InstallDesktopDirector and work through the guided installation.

Desktop Director has 2 pre-requisites, .NT Framework 3.5 and IIS. The install routine took care of the installation of both of these for me. When asked for a XenDesktop controller I entered in the FQDN of my XenApp 6.5 controller server.

Once Desktop Director has been installed we need to configure the solution. This involves the following:

1. Configure Desktop Director to contact one of our XenApp controllers.
2. Allow Desktop Director through the firewall on the XenApp servers (port 2513).
3. Configure each XenApp server for remote management.

To configure the Desktop Director server to contact XenApp, access the IIS Management Console and drill down to the DesktopDirector virtual application. In the right hand pane you will see “Application Settings”.

Double clicking allows us to configure the application settings. For XenDesktop an entry already exists for Service.AutoDiscoveryAddresses and it is this field that we populated earlier. This can be edited and the address of our XenApp server removed. For desktop Director to monitor XenApp we need to add another field for the application, Service.AutoDiscoveryAddressesXA.

To do this we simply click on the Add button on the top right of the screen.

We then name and populate our field.

We enter the server address of one controller per XenApp farm: Any of the other controllers in a XenApp farm are then used automatically for failover. Desktop Director does not load balance between controllers. If we are running multiple farms we separate the names of the designated controlelrs with commas. The Value field will look as below:

FarmAController,FarmBController

Once that’s done we just need to configure our XenApp servers. The next two steps can either be done manually or by using a GPO, for more than 2 or 3 servers, use of a GPO is the preferred method.

First we allow Desktop Director to connect to the controller servers on port 2513 (the old CMC port).

To maintain security the rule can be restricted to only allow access from the Desktop Director server.

We then enable Windows Remote Management on each XenApp worker server (Session Host). This can be done by running the WinRM QuickConfig command on each host.

This does three things.

1. It creates a listener to listen on port 80 (which will need to be allowed through the firewall if it isn’t already).
   
   
   

    

2. It sets the WinRM service to automatically start.
   
   

    

3. It opens port 5985 on the server for external clients to manage the server. Again, this can be limited to the Desktop Director if required. This port is already configured as a disabled rule and can simply be enabled if required.
   
   

Once the above steps are done you should now be able to access Desktop Director using the URL http://servername/DesktopDirector.

As stated, WinRM can be configured using GPO’s and details on how to do that are at http://support.citrix.com/article/CTX125243. Equally, the firewall port (2513) can also be set using a GPO. This is true for our full administrative account. But what about helpdesk users ? Well, if they are full administrators on the XenApp servers then there is no problem. If a more restrictive assignment of rights is required this can be achieved by following the guide at http://support.citrix.com/proddocs/topic/director-200/director-cfg-machine-permission.html.