Apr 122016

Thank you Microsoft for changing fundamental things about your operating system, with little or no regard to those of us running in an RDS/XenApp type environment. Check out this technet article. In this article it states how changes have been made.

“In  Pre-Win 8, apps could set the default handler for a file type/protocol by manipulating the registry, this means you could easily have a script or a group policy manipulating the registry. For example  for Mailto protocol you just needed to change the “default” value under HKEY_CLASSES_ROOT\mailto\shell\open\command”

More importantly, you were able to use Group Policy Preferences (GPP) to set these values inside a GPO. You could also Item Level Target (ITL) them by using the GPP. This means you could easily have users run Acrobat Pro for .pdfs on SecurityGroupA and Adobe Reader for .pdfs on SecurityGroupB. However, the technet article goes on to say that in post Windows 8,

“the registry changes are verified by a hash (unique per user and app) “

A little more digging tells us that the new hashing mechanism is also on a per-machine basis. This means that a hash would be different for each user, per app, per XenApp server. Very inconvenient and annoying. This also means that we can not use the built in GPP functions in Active Directory to set these file type associations. Also very inconvenient and annoying.

James Rankin did a great blogpost on this subject as well. You can read that here. He did a great job overviewing this issue and provided a solution with using AppSense. This blog will show you how to do this with good old batch scripting and group policy. To be honest, I’m quite annoyed that I had to put together this “hack” to get around something that worked PERFECTLY FINE in 2008R2 with GPPs. If anyone has a more elegant solution, I’d love to see it. I’m not the best scripter in the world, but I’m very pragmatic. “It works”

The first thing we want to do is create a logoff script to delete HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf. However, because of that pesky Deny in the UserChoice key, we are unable to simply do this. So, I have made a simple “regini” command to overwrite the permissions on that key so that we can delete. In my environment, I have created FTA_PDF.txt in the NETLOGON directory. Inside this file is simply a registry value and some codes, which allow SYSTEM, Administrators, Interactive User, etc, FULL CONTROL of the key.

Next, I create a FTA_Delete.bat file in NETLOGON. This runs the “regini” command to change the permissions, then a “reg delete” command to delete the key.

Then we need to create the script for the logon process. I’ve busted out good old “ifmember” for this one. It’s a simple executable that will check AD group membership. My script is pretty simple. It checks to see if a user is a member of the Acrobat group. If so, run the “reg add” to add the association to Acrobat. If not, it falls back to the default .pdf reader in this environment. In this case, it’s Adobe Reader. Keep in mind that you can add multiple programs and associations using this method. You can add Foxit here if you would like.

So, the sad fact of the matter is when I tried to set this as an actual “Logon Script” the functionality didn’t work. I had to set this in a User GPO: Administrative Templates\System\Logon\Run these programs at user logon. I’m also the type of person that hates to see a CMD window flash up on the screen right after I login. So, I wrote ANOTHER script called FTA_Starter.bat to call this script to run in a minimized window.

This is the script I added to the GPO.

So, I fought with this for a long time and it wasn’t working. I had to re-read James’s blog and found this little blub at the bottom.

“Update – I built a third XenApp server, just to be sure, and this time the solution wouldn’t work until I removed the Registry key HKLM\Software\Classes\.pdf.”

This DID NOT WORK until the HKLM key was deleted from the servers. Do not forget this step.

I hope this helps you work through this issue in less time that it took me to do it.

Jan 292014


I’m sure we are all familiar with the Shutdown Event Tracker. Hypervisor crash for “no reason”? Have a bunch of servers power down hard “by accident”? It happens to all of us. What’s annoying about this, specifically in a XenApp/RDS environment is the fact that when a regular user logs in they will see this message unless an administrator has already gone in and removed it.

Now, you could just remove it via GPO all together, but I’m not really a fan of that. I would think that this would be available for administrators only, and not regular users. The GPO supplied is a computer based GPO and does not allow that type of granularity. This is in Computer Configuration / Policies / System. As you can see it basically has no options for users.

Simple fix though. After about two seconds of troubleshooting I found that this tracker is controlled by c:\windows\system32\shutdown.exe. So, you could simply just take ownership of this file and remove users read access to this and that works fine. However, if you want to do this in some scale, you can setup a Software Restriction policy and apply it to your RDS/XenApp users. This is also pretty simple.

Drill down to User Configuration / Policies / Windows Settings / Software Restriction Policies. Go to Action and select “New Software Restriction Policy”.

This will create some new folders under Software Restriction Policies. Drill down to Additional Rules and right-click “New Path Rule”.

Simply type in the path and hit “ok”

Make sure this policy is applied only to non-admin users and not administrators. I have a large GPO that I apply to all regular users that access XenApp, so I simply applied it there. That’s about it. Now when your non-admin users’ login they will not be allowed to launch shutdown.exe, which in turn will stop the Shutdown Event Tracker from appearing.

You can validate this by running a command prompt as a regular user. They should be getting this message.

Have fun!

Jun 272013


I’ve been using PNAgent to create Desktop/Start Menu shortcuts for years. I’ve always thought it was a good method to give users only what icons they have access to launch. With the new Group Policy Preferences that have come out with Server 2008, we now have another option. I find that GPP based shortcuts are more stable than PNAgent based shortcuts as they do not rely on XML to be functioning for users to launch applications. Keep in mind however, for this method to work you will need to have the applications actually installed on the XenApp servers themselves.

|Atum| on CitrixIRC started with a simple little script that was able to take some information and convert it to XML to import into a GPP. I gave this information to one of our developers, losethisurl, in CitrixIRC to enhance it. Below will be the scripts and steps to convert PNA based shortcuts to GPP based shortcuts.

The first thing we want to do is check your execution policy to make sure its set to something that will allow this script to run. In my test environment it’s currently set to RemoteSigned.

The first script is called Get-CitrixAppList.ps1. This basically runs a Get-XAApplicationReport and parses the information out in a format that we can use to import into another script. We run this from one of your XenApp Servers. The script is smart enough to load the Citrix snap ins if they are not already loaded. You need to use OutputFileName to specify a filename and optionally you can use OutputFilePath to copy it somewhere. Otherwise it will just save in the current directory.

Notice how XAApplications.csv is now in the folder. Let’s take a look at what’s in there.

So, let’s take this file and convert it to some XML for our GPP. Copy this to your AD controller, or any box that has the Quest AD PowerShell command templates. You can download those here. Now we can use the script Convert-CitrixAppCSVtoGPPShortcutsXML.ps1 file. All we need to do here is run the script and point it to the CSV file.

Notice this creates an Out.xml file. Let’s take a look. If you are familiar with GPP XML files, this should look pretty familiar to you.

So, what do we do with these? Well, that’s pretty simple. All we need to do is copy/paste these into the existing GPP shortcuts policy. I assume you should already have some kind of XenApp Users Policy. If so edit that one. If you do not have one, simply create one with a dummy shortcut. I’ll show you how. First, create a GPO object (or edit an existing). Go to User Configurations/Preferences/Windows Settings/Shortcuts. Right-Click and create a new shortcut.

Click Ok and close the window. Next, go to the “Details” tab on the GPO object and note the Unique ID.

Browse to \\fqdn\SYSVOL\fqdn\policies\<Unique ID>\User\Preferences\Shortcuts\ and edit Shortcuts.xml

You should already see some crap in there for where you created a shortcut earlier. Remove everything right of the blue line.

It should then look like this.

Now copy/paste your Out.xml and paste it on the blank line above </Shortcuts>.

Save the file then close it. Now go back into your GPO and look at the Shortcuts GPP section.

Excellent! Now we have GPP based shortcuts. You may need to go in there and delete things you don’t want, such as “Full Desktop 6” in this example. You can also adjust their locations and item-level-targeting as needed. By default the script will already use item level targeting based on the user group that was assigned to the application in AppCenter (or DSC).

So now that this is populated you don’t want to have duplicate icons published from PNA and GPP.  Make SURE that you have the shortcuts delete on logoff inside of the services site before you start this whole thing.


I also have a script that will disable all of the applications in the farm that you are publishing. Keep in mind to go back and re-enable any applications that aren’t locally installed on the XenApp server. So, let’s go back to the XenApp server and take a look at the Console.

All you need to do is run Disable-AllPublishedApps.ps1 from the XenApp server.  This will disable all apps, and remove “Show on Desktop” and “Show on Start Menu”.

Take a look at the console now. Notice that it excludes any published desktop. That’s a feature. J

That’s about it. This is a real time saver, especially if you have 50 or so applications created through PNA.

Feel free to look at the scripts below and jump in CitrixIRC to talk about it! You can join the conversation at http://join.citrixirc.com. If you already have an IRC client you can simply join #Citrix on the Freenode IRC network.