I once worked with a client where some users ran published XenApp desktops from thin clients, and other users ran traditional XenApp published apps from a Windows PC thick client, using the Program Neighborhood Agent/Online Plug-In/Receiver/Enterprise Receiver/whatever Citrix’s latest name is for the ICA Client. The problem with their configuration was that the XenApp servers hosting the published desktops, and the XenApp servers hosting the published applications, were one and the same. Personally I would have separated the published desktop servers and the published application servers into two distinct silos, but this project was way past that stage when I came on board.
The problem in hand was that all of the Environment Manager actions for users running published desktops, as they were hosted on the same servers, were also running for users launching single published apps. For instance, published desktop users had their App-V shortcuts delivered to their desktop by a fairly long set of actions in one node, and this action was also happening for the published app users – despite the fact they would never see the desktop icons this convoluted routine created. Clearly, the logon actions for the people on thin clients needed to be separated from those using thick clients, as the launch time for the published applications was very slow.
My first thought was, create two AD groups, Thin Client Users and Thick Client Users, and only apply the actions necessary for each set of users to the group they were a member of. All well and good, until I was told that users often roamed between thin and thick clients, meaning that users would have to contact the service desk every time they moved location and have their group memberships changed – another non-starter idea! I was beginning to think that the published application users were doomed to unnecessarily long logon times until I remembered that AppSense EM can also use published application names as a condition for an action.
This appears under Condition | Session & Client | Published Application Name and can be expressed as Equal To, Not Equal To, Query or Regular Expression. We simply performed this check as either Equal or Not Equal at the top of each Logon node and then performed the logon actions based on whether the user was connecting to the published desktop or not, greatly reducing the logon time for the users of the standard published applications.
There turned out to be only one problem with this plan – at the time I was using Environment Manager 8.0, in which there was a bug which meant this condition didn’t actually evaluate properly! Don’t panic – it was in the bug fix list for version 8.1, so if you’re planning on using it any of the latest versions of EM should work just fine. However, at the time, short of running the upgrade with very little preparation, I only had the option of trying to find another way around this. Luckily, the WYSE terminals all had names that were prefixed with WT, therefore I could identify the thin client users based around another handy condition – Conditions | Session & Client | Client NetBIOS Name. Using the Query option, I could enter WT* and filter the required clients out in a different way. Thankfully, after the 8.1 upgrade I could use the Published Application Name and avoid any possible confusion caused by a misnamed PC or WYSE terminal.
These examples hopefully illustrate the ability of the powerful EM conditions to address user-land issues that otherwise would have involved a long and possibly costly reconfiguration of the client environment, and also highlights the fact that proper, well-thought-out planning phases can avoid these sorts of issues in future.
Share
