Elsewhere

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:

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:

1

2

3

4

5

[Remote Desktop Conn]

Address=10.xxx.xxx.xxx:1494

AutologonAllowed=ON

BrowserProtocol=HTTPonTCP

CGPAddress=*:2598

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:

Was also looking into why Citrix Receiver wasn’t creating shortcuts for our published apps even though we had ticked it in in Citrix Studio. The trick was to mark the application as a Favorite in Receiver and the shortcut would be created. Here’s some links I had found while reading on this: