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 :)

StoreFront 2.5 Gotcha

While the main new features of StoreFront 2.5 have been extensively covered (Citrix blog post here), I found a new addition has been quietly slipped in and because at the time of writing the Citrix eDocs site has not been updated for StoreFront 2.5, it caught me out.

If you have setup StoreFront and NetScaler Gateway before you will be familiar with the process of adding the NetScaler Gateway settings, which also adds the corresponding Authentication Method “Pass-though from NetScaler Gateway” under the Authentication pane.  Here’s the new bit though – in the Receiver for Web pane, there is now a separate Authentication Methods option just for Receiver for Web.  And when you add a NetScaler Gateway to your deployment and check the “Pass-though from NetScaler Gateway” authentication option under the Authentication pane, it doesn’t automatically enable the same option in the Receiver for Web pane.


For reference, the symptoms of not having this configured correctly are logging on to the NetScaler, then being prompted again for credentials by StoreFront.  However StoreFront still will not log you in, and you get a message in the event log of your StoreFront server similar to:

"Gateway data from the request and the authentication token are not matching. Request was made to store XYZ Apps."

So there you have it – make sure you check this option under both the Authentication and Receiver for Web panes, I hope the time I burned figuring this out will save someone else wasting their time!

NetScaler Gateway session profiles and Receiver for Windows RT clients

This one catches me out occasionally, because there’s only about three people in the world who use a Surface tablet and now and again one of those three people is a customer of mine.  Symptoms are an otherwise functioning Citrix XenApp or XenDesktop environment can be accessed (via a NetScaler) by any Receiver client with the exception of the Receiver for Windows RT client.  The usual symptoms are after entering the server URL and authentication credentials, you will get a blank “My Apps” screen and the progress/busy dots (I’m sure there’s an official name for them) just continually zip across the screen, the apps will never actually populate.

Receiver RT Screenshot

The issue lies with the URL in the Session Profile.  Your URL should look like the following screenshot:


Ie, it should read https://storefront.ActiveDirectoryFQDN.internal and there should be no trailing slash.  Bizarrely though, most Receiver clients will tolerate any of the following:

1: https://storefront.ActiveDirectoryFQDN.internal/Citrix/StoreName/
2: https://storefront.ActiveDirectoryFQDN.internal/Citrix/StoreName
3: https://storefront.ActiveDirectoryFQDN.internal/
or the correct
4: https://storefront.ActiveDirectoryFQDN.internal

The exception to this is the Receiver for Windows RT client, it works with the 2nd, 3rd and 4th options but not the first, displaying the behaviour described at the start of this post.  So either remove the trailing slash from your URL, or remove the sub-paths from the URL, and you should be good to go!

XenDesktop 7.1 Studio XML Error

On several customer sites now I have seen the error displayed in the screenshot below, when clicking into the Seach page whether directly or via something like right-click a Delivery Group and shoosing “Show Machines”.  Note that clicking Close lets you continue to use the Studio console as normal.

There is an error in XML Document (12,11)

“There is an error in XML document (12,11).”  Clicking the “View Error Details” button doesn’t reveal anything immediately useful, but if you look closely there are some nuggets of information hiding there that hint at the cause:

Error Id: XDDS:14743EA8

 System.InvalidOperationException There is an error in XML document (12, 11).
 at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
 at System.Xml.Serialization.XmlSerializer.Deserialize(TextReader textReader)
 at Citrix.Console.CommonControls.Mmc.SearchTabbedResultPaneViewModelBase.GetSavedSearchesFromDisk()
Inner Exception:
 System.ArgumentNullException Value cannot be null.
 Parameter name: enumType
 at System.Enum.GetValues(Type enumType)
 at Citrix.Console.Models.Search.EnumSearchFilterTerm.UpdateValue()
 at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderObservableCollection1.Read10_EnumSearchFilterTerm(Boolean isNullable, Boolean checkType)
 at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderObservableCollection1.Read14_SearchFilterTermModel(Boolean isNullable, Boolean checkType)
 at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderObservableCollection1.Read15_SearchFilterModel(Boolean isNullable, Boolean checkType)
 at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderObservableCollection1.Read16_AdvancedSearchModel(Boolean isNullable, Boolean checkType)
 at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderObservableCollection1.Read17_ArrayOfAdvancedSearchModel()

The word “GetSavedSearchesFromDisk” drew my attention.  I searched the user profile folder and the ProgramData\Citrix folder for Citrix related XML files, and found just one:


Viewing this file in Notepad it seemed to contain a saved search of some description.  I experimented with removing this file and re-opening the Studio console to the searches page, and the error did not appear.  Creating a new search in the Studio console and saving it created a corresponding new XML file.  Curiously enough after this new search was saved, closing and re-opening the Studio console brought back the error, so I can only assume there is a bug in the XenDesktop Studio console that does not allow this file to be properly parsed once it has been created.

So – if you get this error, it seems you can’t take advantage of the Saved Searches feature, you will have to remove the XML file and make do without it for now.  I’m going to log a ticket with Citrix Support about this issue and will update the page when I have a response or fix.

XenMobile Device Manager and SAN Certificates

I knew that most Citrix components work with SAN certificates, as per the eDocs at  However when installing my first site that wanted to use a SAN certificate for their XenMobile Device Manager server, it would not accept the SAN certificate during the setup process.


Note in the above screenshot, the certificate and password are accepted but you cannot click Next, and the FQDN and other details are not picked up from the certificate.

There is an easy way round this however, instead complete your XenMobile install using the self signed certificate that gets generated during the install.  Then swap the self-signed certificate for your SAN certificate by following this excellent post from Port25Guy:

Once you have followed the above instructions and restarted the XenMobile service, the console should be accessible, and devices able to communicate with the XDM server and enroll etc using the SAN certificate without complaints.

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.