Subscribe via Email

Subscribe via RSS/JSON


Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan


[Aside] NetScaler and WireShark

FYI to myself: NetScaler + WireShark. Lots of useful WireShark tips and tweaks.

[Aside] Profile Manager NTUSER.DAT editing

I liked this blog post. That’s something I had thought of trying earlier when I was thinking about registry keys and applying them via GPP vs other methods. For now I am applying a huge bunch of my registry keys via the default profile and if there’s any subsequent changes then I’ll push the change out via GPP (for existing users) and also modify the default profile (for new users). But the geeky method the author followed of loading each user’s NTUSER.DAT and modifying the registry key directly is fun and something I had considered. Only catch though is that this has to be done during a period no users are logged in. Coz of this I don’t think I’ll be trying this in my environment but I liked the idea.

Citrix – Word could not create the work file

I came across the problem outlined in this blog in our Citrix environment. It’s only got two test users (one of whom is me) and it only happened once to either of us, so I am not sure if it’s really the same thing or not.

The author’s findings are that it is because the %USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache folder is missing. In my case the folder was present when I took a look, but maybe it got created – I dunno. The odd thing in my case was that I was trying to launch both Outlook and Word together and that’s when Word complained. Once I Word opened after Outlook had launched, it was fine. Also, oddly, this wasn’t the first time I had launched Word either. Previous attempts had worked fine.

What I did for now is add the above path to UPM to be synchronized. Hoping that helps. Else I’ll make a GPP like the author has suggested.

[Aside] Citrix StoreFront customizations & tweaks

As a reference to myself for the future:

Citrix not working externally via gateway; ICA file does not contain gateway address or STA

This is something that had me stumped since Thursday. I was this close to having my Citrix implementation accessible externally via a NetScaler gateway, but it wasn’t working. What was the issue? The ICA file did not have the gateway address, it only contained the internal address of the VDA and obviously that isn’t reachable over the Internet.

The ICA file had this (an internal address) (FYI: you can enable ICA logging to get a copy of the ICA file):

While it should have had something like this (STA info along with the external address of my gateway):

Everything was configured correctly as far as I could see, but obviously something was missing.

First question: who generates the ICA file? As far as I know it is the StoreFront, but was I sure about that? Because whoever was generating the ICA file wasn’t doing a good job of it. Either they were wrongly detecting my external connection attempt as coming internally and hence skipping out the STA etc. information, or they knew I was connecting externally but choosing to not input the gateway information. Found this excellent blog post (cached PDF version just in case) on the flow of traffic and that confirmed that it is the StoreFront who generates the ICA file.

  • Upon login via NetScaler (or directly) the StoreFront creates a page with all the available resources.
  • User clicks on a resource. This request makes its way to the StoreFront server – either directly or via NetScaler.
  • StoreFront contacts the XML/ STA service on the Delivery Controller which will decide where to launch the resource on (which server/ desktop etc).
  • The XML/ STA service will put all this information in an STA ticket (basically an XML file) and send back to the StoreFront server.
  • The StoreFront will create an ICA file and send to the user. The ICA file is based on a template, per store, and can be found at C:\inetpub\wwwroot\Citrix\<store>\App_Data\default.ica.
    • Depending on whether the connection is internal or via gateway the StoreFront server will put in the correct address in the ICA file. (We will come back to this in a bit)
  • The StoreFront passes this ICA file to the gateway if its an external connection, or to the receiver / browser directly if its an internal connection.

Ok, so the StoreFront is the one who generates the ICA file. So far so good.

How does the StoreFront know the connection is via a gateway? There’s this thing of “beacons” which is supposed to help detect if a connection is external or internal but that’s used by the receiver, not by the StoreFront. Basically a store has an internal URL and an external URL (via gateway) and once you add a store to Citrix Receiver the Receiver uses beacons to identify if its internal or external and use the correct URL. Note: this is for connecting to a store – i.e. logging in and getting a list of resources etc, nothing to do with ICA files or launching a resource (which is what I am interested in).

StoreFronts have a list of gateways corresponding to the various NetScaler gateways that can connect to its stores. Each gateway definition contains the URL of the gateway as well as a NetScaler SNIP address (now optional; the article I link to is a good read btw). When a connection comes to the StoreFront it can match it against the gateway URL or the SNIP (if that’s defined) and thus identify if the connection is external or internal. (When a user connects through, the StoreFront will attempt to authenticate it against the gateway URL so make sure your StoreFront can talk to the gateway. Also, if the gateway URL has a different IP and you can’t modify DNS with the internal IP, then put an entry in the hosts file).

So how to find out whether my connections via gateway were being considered as internal or external? For this we need to enable debug logging on the StoreFront.This is pretty straight-forward actually. Log on to the StoreFront server, open  PowerShell with admin rights, and run the following cmdlets:

Then we need to download DebugView from SysInternals and Click Capture and select Capture Global Win32. In my case I could see in the debug console straight away that the connection was being detected as external:

Hmm, so all good there too. StoreFront was definitely detecting my connection as external and yet not putting in the gateway address.

At this point I hadn’t enabled access from my NetScaler to the internal VDAs (because I hadn’t reached that stage yet). So I modified my firewall rules to allow access from the NetScaler SNIP to my XenApp subnet. Still no luck.

On a side note (something which I wasn’t previously clear on and came about while reading on this issue): when defining a gateway on the StoreFront the Callback URL is optional and only required for SmartAccess. Basically a NetScaler gateway can work in Basic/ ICA proxy mode or SmartAccess (full VPN?). I was using the gateway as an ICA proxy only so there was no need for the Callback URL (not that removing it made any difference in my case!).

Also, if you are using two-factor authentication on the gateway then the logon type in the gateway definition should say “Domain and security token”.

This blog post by the amazing Carl Stalhood on StoreFront configuration for NetScaler gateway is a must-read. If nothing else it is a handy checklist to make sure you haven’t missed anything in your configuration.

Also a quick shout-out to this great post on troubleshooting NetScaler gateway connection issues. It is a great reference on the whole process of connection as well as the ICA file and what you can do at each step etc. (One of the things I learnt from that post is that apart from the STA ticket the ICA file also contains an NFuse ticket – this is the previous name of Citrix StoreFront/ Web Interface and is found as a line LogonTicket= in the ICA file).

And since I am anyways linking to two great posts at this point, I’d like to re-link to a post I linked to above (from Bas van Kaam) explaining the XenApp logon flow etc.

Anyhow. After a whole lot of Googling I came across this forum post (in all fairness, I came across it as soon as I had started Googling, but I mis-read the suggestion the first few times). It’s a cool thing, so I’d like to take a moment to explain first before going on into what I had mis-configured.

At the firm where I work we have multiple sites. Each site has its own infrastructure, complete with Delivery Controllers, StoreFronts, and NetScaler gateway. Users of each site visit their respective gateway and access their resources. There’s nothing wrong with this approach just that it is kind of unnecessary for users to keep track of the correct URL to visit. We actually have a landing page with the gateway URLs of each of our sites and users can click on that to go to the correct gateway.

It makes sense to each site to have its own resources – the XenApp/ XenDesktop servers. It also makes sense to have separate Delivery Controllers per site – so they are close to the resources. And it makes super sense to have a NetScaler gateway per site so that user connections go from their remote location (e.g. home) to the site gateway to the XenApp/ XenDesktop resource. But we don’t really need separate StoreFront servers do we? What if we could have the StoreFront servers in a single location – serving all the locations – yet each user’s connecting to the resources in their location go via the NetScaler gateway in that location? Turns out this is possible. And this feature is called Optimal HDX Routing.

  1. We would have a NetScaler gateway in a central site. This site would also have a bunch of StoreFront servers.
  2. Each non-central site would have its own Delivery Controllers with VDA infrastructure etc.
  3. On the StoreFront servers in the central site we define one or more stores. To the stores we associate the Delivery Controllers in all the other sites.
  4. At this point a user could login to the gateway/ StoreFront in the central site and potentially connect to a resource in any of the sites. This is because the StoreFront is aware of the Delivery Controllers in all the sites. 
    1. I am not entirely clear which Delivery Controller the StoreFront would query though to get a list of resources (coz I am still figuring out this stuff). My feeling is this is where the concept of zones come in. I think once I create a zone I’d be associating users and Delivery Controllers to it so that’s how the StoreFront knows whom to contact.
  5. The StoreFront server in the central location passes on this info to its gateway (i.e the one in the central location).
  6. (fast-forwarding a bit) Say its a user in a remote site and they select a resource to use (in the remote site because they are mapped to it via zones). The request is sent to the StoreFront in the central location.
  7. At this point the StoreFront can launch the resource via the Delivery Controller of the remote site. But how should the user connect to this resource though? Should it connect via the NetScaler gateway in the central site – inefficient – or is there a way we can have a NetScaler gateway in each remote site and have the user connect via that?

The answer to that last question is where optimal HDX routing comes in. StoreFront doesn’t know of zones (though you can mention zones for info I think) but what it does know is Delivery Controllers. So what a StoreFront can do – when it creates an ICA file for the user – is to look at the Delivery Controller that is serving the request and choose a NetScaler gateway which can service the request. The StoreFront can then put this NetScaler gateway address in the ICA file, forcing the user to connect to the resource in the remote site via that remote NetScaler gateway. Neat huh!

I don’t think I have explained this as best as can be done so I’d like to point to this blog post by JG Spiers. He does a way better job than me.

Here’s what the issue was in my case. Take a look at this screenshot from the Optimal HDX Routing section –

Notice the default entry called “Direct HDX connection” and how it is currently empty under the Delivery Controllers column? Well this entry basically means “don’t use a gateway for any connections brokered by the listed Delivery Controllers” – it’s a way of keeping a bunch of Delivery Controllers for non-gateway use only. For whatever reason – I must have been fiddling around while setting up – I had put in both my Delivery Controllers in this “Direct HDX connection” section. Because of this even though my StoreFront knew that the connection was external, since the entry for my gateway (not shown in the screenshot) had no Delivery Controllers associated with it the StoreFront wasn’t returning any gateway address. The fix thus was to remove the Delivery Controllers from the “Direct HDX connection” section. Either don’t assign the Delivery Controllers to any section, or assign it to the entry for my gateway.

Here’s similar info from the Citrix docs. I still prefer the blog post by JG Spiers.

Took me a while to track down the cause of this issue but it was well worth it in the end! :)

Update: From a blog post of Carl Stalhood:

If you have StoreFront (and NetScaler Gateway) in multiple datacenters, GSLB is typically used for the initial user connection but GSLB doesn’t provide much control over which datacenter a user initially reaches. So the ultimate datacenter routing logic must be performed by StoreFront. Once the user is connected to StoreFront in any datacenter, StoreFront looks up the user’s Active Directory group membership and gives the user icons from multiple farms in multiple datacenters and can aggregate identical icons based on farm priority order. When the user clicks on one of the icons, Optimal Gateway directs the ICA connection through the NetScaler Gateway that is closest to the destination VDA. Optimal Gateway requires datacenter-specific DNS names for NetScaler Gateway.

That clarifies some of the stuff I wasn’t clear on above.

[Aside] Enable ICA file logging

Very useful when you are troubleshooting and want to see the ICA file received by the client/ receiver. Instructions at

%TEMP% environment variable has a \2 or other number after it

For my XenApp servers I had set the TEMP and TMP environment variables via GPO to be the following: %USERPROFILE%\AppData\Local\Temp. But that seems to be ignored as all my users were getting these variables set to %USERPROFILE%\AppData\Local\Temp\2 or some similar number. Weird!

Reason for that is that there are 4 different contexts where a variable is set. I knew two of these and kind of knew the third of these, but I had no idea of the fourth one. These four contexts are:

  1. System variable – a variable that applies to all users of the system. These are stored at HKLM\System\CurrentControlSet\Control\Session Manager\Environment.
  2. User variable – a variable that applies to the currently logged in user. These are stored at HKCU\Environment.
  3. Process variable – a variable that you can apply to a particular process and its children. These are not stored in the registry. I kind of knew of such variables (though I hadn’t formalized them in my head) coz I knew you could launch a process and put a variable assignment before it to set the variable just for that process and its children. (Hmm, now that I think about it was that for Linux or Windows?)
  4. Volatile variable – a variable that applies to the current context of the currently logged in user. These are not saved between log offs or reboots. They are stored at HKCU\VolatileEnvironment.

Whoa! So volatile variables. I had no idea of these, but sure enough when I checked the registry location TEMP and TMP were set there just like I was seeing.

(All the above info was from this helpful TechNet page by the way).

I had no idea a single user could have multiple sessions open on a machine. Server or desktop, I was under the impression you were restricted to a single session; but I guess I was mistaken. From a forum post:

This concept was originally was created by Citrix when they produced WinFrame as a way of handling multiple user sessions on the same machine as a way to handle keeping each user’s temp location unique to each user. Microsoft added it to their OS subsequently as they added Windows Terminal Services to the OS, and this only happened when logging into a terminal services session.

With the evolution of the OS in the Vista timeframe, Micrsooft added the ability for you to have multiple users logged into the OS console at the same time and switch between user sessions, to do that they used the same concept borrowed from the Windows Terminal Services side of the OS.

It is just a mechanism to keep the temp variable locations unique and separate between users. The number used for the directory is actually the session ID number for the user session.

Anyhow, what can I do to fix this? Turns out we can disable this multiple TEMP folders per session thing via GPO. The relevant setting is under: Windows Components/Remote Desktop Services/Remote Desktop Session Host/Temporary folders. Here I set “Do not use temporary folders per session” to true and now I don’t have multiple TEMP folders. Since I don’t want separate sessions (mainly coz I don’t know what they are used for in terms of XenApp) I also went ahead and disabled that from Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connections where you can find a setting called “Restrict Remote Desktop Services users to a single Remote Desktop Services session”.

[Aside] Citrix Storefront Sync Problems – Propagate Changes – Server is not reachable. Configuration settings might be out of date.

A quick thank you to this blog post for making my day slightly better today! Stumbled upon this issue and when a quick reboot and a look at the running services didn’t show any obvious errors I was at a loss of what to do. Wouldn’t have thought these two accounts were getting removed via GPOs. :)

TIL: XenApp and Desktops

If you want to publish desktops via XenApps, the users must be in the “Remote Desktop Users” builtin group. This only allows them RDP access via ICA.

Once VDA is installed, a new group called “Direct Access Users” is created and only its members are allowed direct RDP access.

[Aside] Group Policy Objects – VDA User Settings

An amazing post from Carl Stalhood (as a reference to myself for later):

Group Policy Objects – VDA User Settings

Various Citrix and Profile and Folder Redirection bits and bobs

I am a bit all over the place as I am trying to do multiple things and discovering so many new things. It’s exciting, but also a bit overwhelming. I know I should note it all down for future reference (as I may not be implementing most of these now) and rather than wait for things to settle down and then write a more organized blog post – which may not happen coz I could have forgotten by then – I think I’ll just “dump” things as they are now. :)

First off: I noticed that my freshly installed Citrix Director wasn’t showing any logon performance data. Empty. Said there’s no logons, nothing to report. Googled a bit, found some forum posts, but this blog post is what I will link to. Now if you look at that it suggests viewing the Monitoring database to see if some columns are NULL. How to do that? I had no idea, but again Googled a bit and found that if I go to the database table via SQL Management Studio I can view the table as below –

Once you have UPM installed, it takes care of the performance data. This runs via entries in the HKLM\Software\Microsoft\Windows\CurrentVersion\Run key and could be blocked via some GPO. That wasn’t my case, but I went ahead and disabled the setting anyways. (Didn’t check whether logon performance data is working since then).

Next: speeding up logon times.

Since Windows 8/ Server 2012 there’s a 5-10 second delay for applications when they are launched during startup (i.e. logon). This messes up with the figures from Citrix Director (as the process for monitoring too is delayed) plus gives you a slower logon experience. To remove that delay a registry key needs to be added: StatupDelayInMSec (REG_DWORD) to 0 in HKCU\Software\Microsoft\Windows \CurrentVersion\Explorer\Serialize. Came across this nugget of info from another blog post too which has some more useful suggestions (especially the one about removing the CD-ROM drive – I’ve done that). In a similar vein this post from XenAppBlog (great blog!!) is also useful. It mentions what I had written above about Citrix Director stats being skewed coz of the startup delay.

There’s a sequel to the post from XenAppBlog. From that I came across Citrix’s own optimization guide (it’s for Windows 8 & 8.1 but I figure I can harvest it for 2012 R2 info too). And this post from is awesome (I learnt about modifying the default user profile itself where possible than using GPPs to get that extra bit of performance). The author has a Server 2016 optimization script too which I hope to pull in bits and pieces from.

I am fascinated by the idea of modifying the default profile. That makes so much more sense than applying all these GPPs. I love GPOs but I am not a huge fan of them either. For me they serve a purpose but must be used in moderation. I’d much rather set the correct defaults via MST files when installing a package or just modifying the default settings some other way. I guess it’s coz I have seen the delays that happen during login when a large number of GPOs apply (at work for instance, my laptop has some 31 GPOs applying to it!).

The only catch with modifying the default user profile is that you can’t push out subsequent changes to all profiles. What I mean is once a user logs in and has a profile, and then I go ahead and make some changes to the default profile, I can’t push these out to the profiles that were already created. All I can do is delete the already created profiles so that next time they login the changes are pulled over.

Reading about this I came across this nice blog post. And what a blog too! Some amazing posts there. 

Group Policy Preferences must be processed to determine whether they have been applied. Whilst GPPs can implement a preference rather than a policy, Windows must determine whether the preference has been applied by reading a flag. Whilst checking those flags isn’t a big problem, implementing GPPs should be considered in the context of whatever else is running at logon, how many preferences are implemented plus what happens to the environment over time (how many additional policies, applications, scripts etc. will be added to the environment over the life of that desktop).

The author has a few scripts on editing the default policy directly during Windows deployment.

From that blog I came across a nice (and funny) post on folder redirection. When I was fiddling with folder redirection, initially I too had redirected the Documents folder to the user’s home directory and was struck by what the author mentions in his blog. All my user folders started showing the name “Documents”. So irritating! I had to manually go and delete the desktop.ini file (from previous experience I knew the desktop.ini file plays a part in the folder names and icons etc). Since then I changed the Documents folder to point to %HOMESHARE%%HOMEPATH%\My Documents. This blog post also made me realize one can redirect more folders via some registry keys present at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders.

Speaking of variables that be used in folder redirection the officially supported ones seem to be %USERNAME%, %USERPROFILE%, %HOMESHARE%, and %HOMEPATH%.

(For anyone interested in more quirks of Windows Explorer this blog post is a good read).

Btw, as a matter of terminology, there is a different between folder and directory. A folder is more of a virtual construct while a directory actually exists. In most cases folders are same as directories, but when we look at redirected folders for instance then folders are not the same as directory. There’s a folder called “My Documents” for instance (under C:\Users\Username) but there’s no corresponding directory. The folder is virtual and points to a directory at say (\\myfileserver\RedirectedFolders\Documents\Username).

Part 2 of the above post on folder redirection. Has a bunch of videos on various situations and the impact. Key takeaways:

  • Windows logon process is not solely dependent on the user PC. It depends on the load of the file servers too hosting the profiles (for roaming profiles).
  • Heavily loaded profile server means slow login time for roaming profile user.
  • If using folder redirection, then heavily loaded profile server means not so slow login time (as less data is transferred initially) but experience may not be great post login as the desktop etc. icons need to be pulled from the profile server and that is under load. This is made worse if AppData too is redirected as it impacts app launches too.
    • On a side note: I think redirecting AppData is a bad idea. I have had made experience with it at work. Best to keep AppData as part of the roaming profile and not redirected. AppData has a lot of read-writes too – is not suited for redirection.
  • If using Citrix streaming profiles and the profile server is loaded, login time is better as it is streamed as required.
  • The author doesn’t talk about Citrix streaming profiles + folder redirection and heavily loaded servers. That’s the scenario I was interested in.

Nice! Part 3 of the post on folder redirection shows the impact of not redirecting AppData. :) BTW, note to self: when you redirect AppData you redirect the Start Menu too. Obvious in hindsight, as I know the Start Menu is in the AppData folder, but I had forgotten.

Part 4 is on the impact on logon duration. Part 5 is on the impact of the SMB version (basically, use the latest version where possible, for better performance). Windows 8/ Server 2012 and above use SMB3 (well 3.0 and 3.02 for 8.1/ 2012 R2). And speaking of SMB, SMB is not CIFS. :) CIFS is ancient stuff, superseded by SMB1.

Another bunch of posts by these same others on folder redirection (yay!). Three parts again. Nice quote from part 1:

Folder redirection remains a popular method of user data and profile management because it can improve the user experience by achieving two things:

1. Faster logons – redirecting AppData out of the profile reduces the amount of data required to be copied locally at user logon

2. Abstracting user data – moving user data out of the profile to a home folder ensures data is available on any desktop and allows IT to protect that data

Abstracting user data. I like that. That’s exactly what I had in mind when I discovered the joys of separating a profile from the user data (as in limit a profile to just the settings or “profile” sort of stuff; keep all data redirected elsewhere so it can be shared among multiple profiles or even multiple versions of the profile). I won’t go into much detail other than link to the first part and also this post on how they did the tests (some good tools there).

Lastly, some alternatives to folder redirection. I am not a decision maker in my firm for desktop stuff, so I will skip this for now. Some day … :)

While on the topic of folder redirection, I wanted to point to this post too on automatic conflict resolution.

I guess that’s all for now. More later …


An excellent post by Helge Klein on the impact of GPOs on logon performance. I am awed by people like Helge Klein and Aaron Parker (whose posts I link to above). It takes a certain level of effort and persistence to test the impact of various settings across multiple scenarios. It’s something I would like to know of, but am lazy or disorganized to actually get off my butt and do. Very impressed. Check out the CSE Overhead section in the post I link to. Registry settings applied via policies have way different impact to registry settings applied via preferences. The latter has nearly twice the impact (i.e. registry keys via policies is less than 20ms, registry keys via preferences is about 50ms). Damn!

Beware of using preferences to set shortcuts, ini files, and environment variables.

Also interesting to note, it is better to put all settings in a single/ less number of GPOs than to spread them across multiple GPOs. Not a huge impact, but it matters. (That said – the version of a GPO is associated to the GPO, and not to the individual settings in it. So if you have a less number of GPOs with a lot of settings in them, a change to a single setting will result in the GPO having a new version and hence be reapplied (see below)).

Note to self for the future: registry settings via policies (we can’t control these directly, they are what the policies set) is stored in a registry.pol binary file. Registry settings via preferences are XML files.

The post has more nuggets such as the processing order of GPOs (admin templates first, followed by others – check the post for the order). Also, worth remembering that gpupdate is smart enough to only apply any changes Group Policies and what the /force switch does is tell it to re-apply everything – you don’t really need that in most cases. Group Policy be default keeps track of what settings have been applied.

The Client Side Extensions (CSEs) in a GPO are controlled per machine under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. The CSEs are modules basically which do the actual applying of a GPO setting (e.g. drive mappings, registry settings, admin templates stuff). Worth noting that each CSE has a value called NoGPOListChanges. If this is 0 (the default) it means the CSE will process a group policy even if there’s no changes between the cached list and the currently downloaded list (note this contradicts what I said with gpudate above). If this setting is 1 then the CSE will process a group policy only if there are changes.

From this Microsoft blog post:

A Client-Side Extension is nothing more than a file (in most cases it’s a .dll file, but not always) that has been installed on the client machine which has the ability to interpret and process certain of the settings in a GPO. Because there are many different types of settings, there are different Client-Side Extensions. In order for your client to process a portion of a GPO, the CSE associated with that portion of the GPO will need to be present on the client machine. An example of this is the security settings that are found under Policies/Windows Settings/Security Settings on both the Machine and User nodes of a GPO. To process any settings that have been configured within these containers, your client will need the scecli.dll file.

Part 2 of the same post: When a computer starts up (machine policies) or a user logs in (user policies) the group policies are processed. This can be thought of as foreground processing – you see it happening. Apart from this, every 90 mins (which can be changed) with an offset, the group policies are also processed in the background.

  • During background processing only GPOs with NoGPOListChanges set to 1 are processed (i.e. only if there are changes).
    • Fun fact: background processing runs multi-threaded. All other GPO processing is single-threaded!
  • During foreground processing there’s two modes that processing can operate in. :) Asynchronous – which is the default – means policies apply without delaying the user login. That is to say when a user logs in, the full set of policies may not have applied – they can apply in the background. This is good in the sense that logins appear fast, but not good if you want all policies to apply before a user logs in. The alternative is Synchronous wherein all policies apply and then only the user logs in. When we go and change this GPO setting – Computer Configuration > Policies > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon – a common practice in an enterprise environment, you are basically switching foreground processing to be synchronous.
    • Note: you need synchronous processing to ensure folder redirection applies in a single login. 
    • During synchronous foreground processing all CSEs are processed, irrespective of there being any changes or not. :) So NoGPOListChanges is ignored.

More fun stuff: disabling the computer or user configuration in a GPO has not much effect. And if you want to enable debugging and logging it is possible too.

Part 3: Lots of cool info on the effect of WMI filters and Item Level Targeting (ILT). Skipping WMI here for now as I am not using it currently (for Citrix purposes), but good to know about ILT: avoid using it via evaluations against AD such as OU, LDAP queries, Domain, and Site. Querying against an AD group is fine.

Here’s an official Microsoft blog post on pretty much the same info as above (not the performance tests etc). The official recommendation seems to be to use asynchronous foreground processing (the default) with the caveat that it won’t work for redirected folders. Bugger. :) Also, a good Microsoft Technet article on Group Policy performance. It touches on a lot of the same topics as the blog posts above but gives a different perspective.

I need to find a way of applying per user registry keys, environment variables, and drive mappings. These are the three things for which I currently using GPPs and I want to try and avoid that. I guess I can use Active Setup, or perhaps Scheduled Tasks? I could also look at modifying the default user profile but I am not too keen on that now (coz what would I do if there are changes? I don’t want to keep deleting user profiles so they pick up a new default profile).

Speaking of Active Setup, an excellent post by Helge Klein. I wasn’t aware the Version value could be used to run the same component in case of changes. Sounds useful in my scenario.

The Citrix servers do not trust the server. This message was reported from the XML Service at address …

If you are able to login to your Citrix Storefront and get a list of application, but when launching something you get an error –

And checking the “Citrix Delivery Services” logs on your Storefront gives errors such as these –

  • The Citrix servers do not trust the server. This message was reported from the XML Service at address http://xxx/scripts/wpnbr.dll [NFuseProtocol.TRequestAddress].
  • Failed to launch the resource 'xxxx' using the Citrix XML Service at address 'http://xxx/scripts/wpnbr.dll'. The XML service returned error: 'not-trusted'.

You have come to the right place. :)

This is because you probably have “Domain pass-through” authentication enabled on your Store and/ or the Receiver for Websites (note the latter: easy to miss out). When this is enabled and users visit the Storefront page, they don’t get the usual username password prompt. Instead they get an option to login with the Windows credentials.

The problem with this is that these Windows credentials are passed on to the Storefront server. The Storefront server is happy, gives the users a list of apps and desktops assigned to them, etc. But when the user clicks on something, it is the Citrix Receiver that comes into play and needs to pass on the credentials to the concerned XenApp or XenDesktop server. Citrix Receiver needs to be explicitly installed with the ability to do Single Sign-On (i.e. pass on Windows credentials) and if that’s not the case users will not be able to launch any app or desktop. (The command line to do such an install is: CitrixReceiver.exe /includeSSON). Once this is done an additional component called ssonsvr.exe will be present on the user machine, and that facilitates SSO.

For more details on Citrix Receiver and SSO check out this link. And for an official explanation of what I wrote above, check out this blog post.

Lastly, if you don’t want to do any of this, there is a work around. :)

Citrix – Cannot connect to the Citrix XenApp server. Network issues are preventing your connection.

Been banging my head on this since yesterday.

Initially I tracked it down to the fact that I couldn’t ping my XenApp servers. Dummy error on my part – I had forgotten to set the default gateway in the DHCP scope. That didn’t help though, and even though I could ping the XenApp servers and connect to ports 1494 and 2598. Learnt how to enable Citrix Reciver logging but that didn’t give any errors either (go to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\Logging for 64-bit OS, or HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\Logging for 32-bit OS, specify a value for LogFile, and set everything to true). Googled a lot, read various forum posts, finally came across this blog post that suggested turning off the IE proxy settings. And that helped. Aaargh!

I had specifically tried via the Receiver application rather than IE just to avoid any gotchas like this. But my bad, the Receiver uses IE proxy settings it seems.

Update: So why was the proxy affecting my Citrix connections? For this the log file provided an answer.

When connecting to any of my resources, I noticed that the connection was being made via IP address using an HTTP request to port 1494:

This is because I was connecting to the StoreFront server directly and it was redirecting me to a resource.

In contrast, if I were using a NetScaler gateway, the same entries would look like this:

No IP address is involved there as the NetScalers do the needful via the STAs etc.

So all I had to do was add an exception for the IP range of the XenApp servers in my wpad.dat/ global.pac files to go DIRECT rather than via proxy.

TIL: Citrix Receiver does not connect to non-HTTPS stores since version 3.1

You can of course configure it to accept HTTP stores:

[Aside] Links to DFSR, Profile Data, etc.

Been reading quite a bit about user profiles and stuff lately. I’ve always imagined profiles as this blob of user settings + data under the C:\Users\<username> location. And every time we need to reset a profile there’s this arduous task of backing up the user data too and restoring it. Silly.

But turns out it’s just easier to use folder redirection and redirect all your data folders to a common place. Advantage of this is that roaming profile users can login any place and have the latest up-to-date data. None of the hassle of requiring a logoff-login for the profile to sync etc.