NetScaler – StoreFront monitor quick tip

Citrix NetScaler has a built-in monitor that monitors the state of your StoreFront store – rather than just checking port 443 is up, it checks the state of several services.  For a description of what it does and how it works check here:

When you configure a monitor and bind it to your StoreFront services, you may find it does not work as expected and marks the services as “down”.  As you can see in the screenshot below, the details in the monitor are correct for the store in question yet the services are still marked as down.


This is because if you have a Store name with a space in it, eg “Company Apps” and enter this into the monitor it doesn’t work.  What the monitor really needs rather than the store name, is the sub-path on the IIS site – usually this will be “CompanyApps” from the full path of  Check your StoreFront or IIS console to be sure.

One last tip – in NetScaler 10 the detail of why a monitor failed was quite easy to find, in NetScaler 11 less so – look under Traffic Management -> Load Balancing -> Service Groups -> Edit the service group -> Service Group Members -> Monitor Details.


StoreFront Legacy PNA Tips

Just a quick post on a couple of StoreFront Legacy PNA customisations I’ve implemented for customers, as you won’t find these documented in eDocs or the Citrix KB (that i’ve seen anyway!)

To enable SSON for Legacy PNA sites

To enable single sign-on, edit the file:

Change the line:

<pnaProtocolResources changePasswordAllowed="ExpiredOnly" logonMethod="prompt"


<pnaProtocolResources changePasswordAllowed="ExpiredOnly" logonMethod="sson"

(ie change “prompt” to “sson”)

Edit the file:

Change the line:

<LogonMethod><%= ViewData[PnaConfigViewConstants.LogonMethodId]%></LogonMethod>



(ie change “<%= ViewData[PnaConfigViewConstants.LogonMethodId]%>” to “sson” (without quotes))

Change the line:

<EnableKerberos><%= ViewData[PnaConfigViewConstants.EnableKerberosId] %></EnableKerberos>



Remember your clients need to be configured to support SSON as well, as per CTX133982 or CTX134280.

To change Start Menu folder for Legacy PNA apps

By default, shortcuts to the Citrix published applications will appear in the root of the Programs folder on the Start Menu.  To place all published apps under a sub-folder (which was a GUI option in the old Web Interface console), edit the file:

Change the line:

<RootFolder root="programs" modifiable="true" forcedefault="false"></RootFolder>


<RootFolder root="programs" modifiable="true" forcedefault="false">Citrix Apps</RootFolder>

(ie add “Citrix Apps” or substitute whatever folder name you like(without quotes))

Lastly – remember that if you have more than one StoreFront server in a cluster, make these changes on your primary server with the StoreFront console closed.  Then open the console and propagate the changes to the remaining StoreFront servers in the cluster.

Edit – note these customisations were tested with StoreFront 2.5, they may or may not work for other versions :)

XenDesktop 7 upgrade and Citrix Policy errors

You may encounter an issue after upgrading XenDesktop 7 where upgraded policies in the Citrix Studio cannot be edited or deleted, and you receive the error “The given key was not present in the dictionary” as per CTX138498.  What the article doesn’t tell you is some of the additional steps and requirements in order to remediate your policies.  When you setup the temporary server, you will need to:

a) need to choose the option to install SQL Express, or have a SQL server available elsewhere on your network.

b) You need to configure a temporary XenDesktop site, don’t try and add the XenDesktop 5 controller back into your XenDesktop 7 site.  Also when running the wizard to configure the temporary site you don’t need to choose a hypervisor, just pick “None”.

c) If your old pre-XD7 controllers had the Citrix Group Policy 1.7 update applied (which is part of XenDesktop 5.6 FP1) you will need to re-install this as well.  Otherwise you will receive errors such as “Found invalid data while decoding” trying to view your imported policies on the XD5 server.  If you need to re-download this component, go to (login required).  Drill into XenDesktop 5.6 Feature Pack 1, choose your edition, and download and install the “HDX and Group Policy Update”.

If this information was present in CTX138498 it would have saved me a good couple of hours while I figured all this out – hopefully I can save someone else some time instead!

XenServer iSCSI LUNs not mapping

I’m not a big fan of iSCSI – probably a hangover from years of fibre channel experience before ethernet based storage networks became commonplace – and the issue I ran into today didn’t do anything to increase my comfort level.  My experience to date is that fibre channel storage systems seem to “just work” whereas iSCSI can be finnicky and temperamental.

A customer had purchased a new HP P2000 G3 iSCSI storage array to provide a shared storage repository for XenServer HA for the blades hosting their XenDesktop farm, in addition to providing a storage location for templates and a handful of test VMs.  I configured two ports on each P2000 controller and assigned two NICs from each XenServer blade for iSCSI traffic as per the XenServer multipathing best practice guide which you can find at CTX136354.  I enabled multipathing on all hosts in the farm and proceeded to create the storage repository.

After creating the SR it was visible on one host only, and on the rest it showed with a status of “Unplugged” in XenCenter.  Watching the SMLog file while trying to “repair” the SR from the GUI, or running “xe pbd-plug uuid=…” from the command line, generated errors similar to the below:

Aug 21, 2013 4:27:14 AM Error: Repairing SR P2000_HA - Internal error: Failure("Storage_access failed with: SR_BACKEND_FAILURE: [ non-zero exit; ; Traceback (most recent call last):\n  File \"/opt/xensource/sm/LVMoISCSISR\", line 549, in ?\n, DRIVER_INFO)\n  File \"/opt/xensource/sm/\", line 250, in run\n    sr = driver(cmd, cmd.sr_uuid)\n  File \"/opt/xensource/sm/\", line 136, in __init__\n    self.load(sr_uuid)\n  File \"/opt/xensource/sm/LVMoISCSISR\", line 150, in load\n    self.iscsi = self.iscsiSRs[0]\nIndexError: list index out of range\n ]")

Needless to say this didn’t make a lot of sense.  Eventually after running out of ideas, some semi-random googling uncovered that the /etc/iscsi/initiatorname.iscsi file was missing (on 10 of 11 servers in the pool!!) and was not recreated by changing the IQN in the XenCenter console.  To fix this, I ran the following commands (note the initiator name must be the same as what is set in the XenCenter console)

[root@XenHome ~]# echo > /etc/iscsi/initiatorname.iscsi
[root@XenHome ~]# echo InitiatorAlias=XenServer01 >> /etc/iscsi/initiatorname.iscsi
[root@XenHome ~]# /etc/init.d/open-iscsi stop
[root@XenHome ~]# /etc/init.d/open-iscsi start

To test iSCSI was now operational, I ran the following command (replace the IP address with the address of your iSCSI SAN):

[root@XenHome ~]# iscsiadm -m discovery -t sendtargets -p

A list of target LUNs was returned, I was able to successfully “repair” the SR and get on with my day.