QuickPost – how to start a process when a Citrix published application launches

This sounds easy, right?

For a lot of my Citrix Virtual Apps deployments (so I’m talking published applications only, not desktops), I sometimes lean on CloudDriveMapper for connecting to OneDrive. I’m not going to go into the setup of it right now – I have another post in the drafts dealing with that. But one thing you have to do is make sure the CloudDriveMapper process launches when the user launches their published applications, otherwise they won’t get connected to their OneDrive files and folders. On a desktop, this is super easy – CDM itself writes into the Run key in the Registry when it’s installed, so when the user launches a desktop, they connect and everything is good. But with applications, it’s a different matter.

In my first deployment to published applications I simply used Ivanti (AppSense) to trigger a process launch so it was pretty straightforward. I hadn’t given the published applications conundrum much thought after that until Ryan Gallier mentioned it over on World of EUC Slack. But like I said, it sounds easy – there are stacks of entry points that you can use to auto-launch something even if you don’t have Ivanti UWM or Citrix WEM to do it. Right? RIGHT?

Actually, no. Let’s get some of them out of the way straight away.

What doesn’t work

First of all, there are the Run keys in the Registry. These exist in both HKLM and HKCU and have entries in the “standard” and “Wow6432Node” trees. In case you’re not familiar, they are generally under \Software\Microsoft\Windows\CurrentVersion\Run.

These don’t work at all – they’re only processed when you launch the shell. So if you’re publishing Explorer, they will work – but Explorer isn’t likely to be the only application you’re publishing, unless you’re mental. For general application purposes, they’re no use.

There are also GPOs for auto-launching applications when users log on. They appear in both User Config and Computer Config, and sit in Admin Templates | System | Logon

Small problem, though – these GPOs are only processed when you launch a full desktop.

What about RailRunOnce? This is a Registry value that sits in HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server and basically is designed for launching processes when RemoteApp applications are started. This sounds really promising…

But no, this doesn’t work either. It works nicely with pure RDSH and Azure Virtual Desktop native, but because it relies on rdpshell.exe, then it doesn’t graft with Citrix published applications. Jeez.

What about the blatantly obvious – putting a shortcut in the user’s Startup folder?

Well – it writes the shortcut OK, but…..you guessed it, it is ignored unless running a full desktop 🙁

Now there’s the old AppSetup value in the Registry too, you know, the one that launched usrlogon.cmd? Would sticking our executable in here work? It sits under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon and is a comma-separated list of values

You can scratch that too – the process launches, but a) it is hidden from the user, and b) it basically halts the logon until the process exits, so the user never sees their published app. The same thing happens if you’re crazy enough to try to add the process to usrlogon.cmd, so don’t bother.

Is there anything that does do the trick?

What does work

There are actually a few options that work, but they have their pros and cons.

Now a logon script (either in GPO or on the AD user object) actually works, but the question remains – why would you want to? Logon scripts are old, archaic and fiddly, and we are trying to get away from them. So it is a legitimate working option – but it feels wrong and dirty.

Launching your Citrix published applications via a .bat or .cmd file that calls CloudDriveMapper (or whatever process you’re targeting) and then runs the published application will also work, but all of the above references to logon scripts also apply here, and…..do you really want to reconfigure all of your published applications to run in this fashion?

There’s also the old “UserInit” key in the Registry, which people often use to block logon scripts from running, found at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. This works fine, but the problem is that it is processed for all users

But by far the cleanest option is to use a Scheduled Task. If you configure it correctly, it can be scoped to an AD group, it can be deployed automatically, it doesn’t require any scripting or Registry faffing and it feels a lot cleaner than all the other working options.

Go into User Configuration | Preferences | Control Panel Settings | Scheduled Tasks. It is MEGA important to use User Configuration, NOT Computer Configuration, as the same settings exist in both.

Create a new Scheduled Task (At least Windows 7) and set the options as below. The pertinent ones are highlighted

Changing the user account context to an AD group allows you to limit the task to specific users as shown above

Obviously, set the program to whatever it is you want to run!

This setting is also very important – it means that if the process is already running for another user session it will start a new one for the user logging in, which we want

Be VERY careful NOT to check either of the highlighted sections above. These will break the application of the policy, because GPP Scheduled Tasks run in the context that is set on the task level, not on any of these. Make sure this is set correctly.

Once you have set this up, link it to your Citrix Virtual Apps systems as required, refresh the GPOs, and you should see the task appear in the Scheduler UI

Now, when users log in who are members of that particular AD group, they should see the process launching that you have specified in the task.

Obviously, because this process has been launched you need to make sure it gracefully exits when users log out. The Citrix Registry value LogoffCheckSysModules is ideal for this.

Summary

This felt a lot harder than it needed to be, but at least there’s a way to do it without leaning on scripts.

So anyway – if you do have to run a particular process within your Citrix published apps, then the Scheduled Task is by far the cleanest and most manageable way to do it. Especially if you want to be able to target it.

Thanks for continuing to read my content – hopefully very soon we will have some more video and website instalments for you to read, possibly focusing on application deployment.