Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

[Aside] XenApp beta testing with Application Groups

Application Groups is a new feature introduced in XenApp and XenDesktop 7.9 (speaking of which: XenApp and XenDesktop are the same thing just that different functionality is exposed based on the license. I kind of knew this, but thanks to proper testing by James Rankin as shown in his YouTube video I can now say this with confidence). I’d thought of writing a blog post on this but (a) I am lazy and (b) this blog post from Citrix explains it much better. Take note of the example they give with beta testers – that’s just what I do in my environment too.

Machine Catalogs contain your machines. Delivery Groups target a subset (or entirety) of the machines in a Machine Catalog. Delivery Groups can contain machines from multiple Machine Catalogs but a single machine can only be a member of one Delivery Group.

Typically you’d create Machine Catalogs and assign machines from these to a Delivery Group. Then you’d define applications in the Delivery Group and assign users who can access them. When you use Application Groups, however, you continue to assign users in Delivery Groups but now you associate the Application Group with one or more Delivery Groups and define applications in the Application Group. You can set priorities for the Delivery Groups within an Application Group, and if an application is present in more than one Delivery Group (and the user launching the application has permissions to these Delivery Groups) then it is launched from the Delivery Group with the higher priority (a lower number has higher priority).

Once we start using Application Groups there’s no need to define applications in Delivery Groups.

Application Groups also help in targeting specific machines in a Delivery Group. As I mentioned above a Delivery Group can contain machines from multiple Catalogs. Using Application Groups its possible that some users are “pinned” to applications from machines in specific Machine Catalogs.

Here are more links on how Application Groups can be used along with tags:

Adding Registry keys to NTUSER.DAT for multiple users

A while ago I had pointed to a blog post I found wherein the author wrote a script to push registry keys to the NTUSER.DAT profile file of a large number of users. I wanted to try something similar in my own environment and while I didn’t go with the script I found I made up something quick and dirty of my own. I know it isn’t as thorough as the one from that blog post (so I’ll link to it again) but it serves my need. :)

So here’s the deal. I have a bunch of profiles located at “\\path\to\profiles\ctxprofiles$“. It has both v4 and v6 profiles. I’d only like to target the v4 profiles, and that too a specific user for testing. This user’s name contains the word “CtxTest” so I match against it. (Post testing I can remove the pipeline and target everyone).

All I do is get the list of folders, and for each of them load the NTUSER.DAT file from the correct location (it’s under a folder called UPM_Profile as I am using Citrix UPM). I just use the REG commands to load the registry hive, import a registry file, and unload the hive. Easy peasy. No error checking etc. so like I said it’s not as great a script as it can be.

[Aside] How to roam AppData\Local too

Came across this video from James Rankin. Apart from being an excellent video, it has one important thing which I felt I must note down here as a reference to myself. I always thought AppData\Local and AppData\LocalLow were not synced as part of your roaming profile because they were special in some way. Today I realized that there’s nothing special about them. They are not synced because of a key called ExcludeProfileDirs in HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. Any folder mentioned there is not synced as part of your roaming profile. Nice!

So to make AppData\Local roam, simply remove it from that registry key. Then selectively add any sub-folders you might want to exclude.

XenApp and Run/ RunOnce keys

Reminder to myself: the Run and RunOnce entries in HKLM and HKCU are not processed if an application is launched via XenApp. That’s because these keys are processed by explorer.exe and that doesn’t run when you launch single applications (as opposed to the desktop).

Set 7-Zip as the default for zip files

Had to do this for my XenApp install (7-Zip on a Server 2012R2). Thanks to this post which is in turn based on this post. Trick is to put the following into a registry file and double click/ import it on the machine:

After this go to Control Panel > Default Programs and 7-Zip will appear there. You can set it as the default for all extensions/ choose the ones you want.

Update: Frustratingly, I learnt that the Control Panel way doesn’t do the trick for Citrix. Later I learnt that maybe HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\ might be where FTAs (file type associations) are stored, so spent some time exporting the keys from there and pushing out via GPO. Turns out that didn’t do the trick either as it includes a hash tying the file type association to the user & machine where it was set to (bummer eh!). Thanks to these two posts [1][2] I learnt that the official approach is to use DISM to export the FTAs for a user and then deploy it via GPO. The FTAs are deployed to machines, so you can’t have per user customizations this way (but the two posts above have some workarounds).

The DISM command is: dism /online /Export-DefaultAppAssociations:c:\ftas.xml.

Update2: Here’s a blog post containing a tool that lets you bypass this hash issue.

Update3: This is a blog post about the OEMDefaultAssociations.xml. This is the file where the default customizations are stored, which you can over-ride via GPO. Or you could edit this file itself per machine. I learnt via trial and error – this file is very sensitive. If there are missing entries (the default ones) or even out of order entries it seems to be ignored altogether.

The entries in this are configured on new user profiles (existing ones are left untouched) and users can modify the associations if they want. The entries in the GPO cannot be changed by users.

The Citrix Desktop Service failed to obtain a list of delivery controllers with which to register.

Funny little problem.

So I installed VDA 7.13 on a brand new Server 2016. Did the usual to create a catalog etc. But the VM doesn’t register with the Delivery Controller. Application event logs are filled with messages like these:

I am not looking to AD etc. for the list of Delivery Controllers, so why this error? Open up regedit and HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\VirtualDesktopAgent\ListOfDDCs has the correct names too. So what gives?!

Turns out when I put in the Delivery Controllers name here I had set them as “DC1.fqdn. DC2.fqdn.“. I could ping either of these and connect to the ports etc from the VM, but just on a hunch I removed the “.” in the “fqdn.” and tada! it began working. :)

Moral of the story: Citrix Desktop Service expects Delivery Controllers to be of format “DC1.fqdn DC2.fqdn“. If it sees a dot it ignores the ListOfDDCs key and looks towards AD. It doesn’t tell you that it’s ignoring the registry key, so you are stuck wondering why it’s looking towards AD. :)

[Aside] Always offline mode for cached files

I wasn’t aware of this until a few weeks ago. Starting with Windows 8/ Server 2012 there’s an always offline mode for cached files and folders. That’s useful!

[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 https://support.citrix.com/article/CTX115304.

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