The triggers are one of the most powerful features of AppSense and particularly Environment Manager. Group Policy generally applies user settings at logon time and refresh time, but aside from the logon you can’t really determine with any particular certainty when your settings will apply. EM, on the other hand, lets you use triggers to narrow down policy configuration to a fine level.#
Here’s a case in point. I worked with a client once where they used a piece of software that was, to put it lightly, not too flexible for XenApp/thin client environments. It insisted that each user had a local copy of the software files available to them, and this location was clearly hard-coded to a folder off the root of the system drive. Now, it’s easy enough to sit and say “the vendor should sort it out”, but when companies are dependent on this sort of software, it often falls to support teams and consultants to find a way around this because the vendor can’t or won’t do it. It’s also easy enough to declare that all software should be well-written and constantly updated for new technologies, but I’ve yet to work with any client where they haven’t had at least one piece of software that was poorly-written, outdated or completely inflexible, and naturally, they couldn’t do without.
Roaming profiles were no good because of the file location (and previous issues meant they wanted to get away from them anyway), so it meant that each user using the software from a XenApp platform potentially needed 55MB of files copying to %systemdrive%\Rubbish_App\%username% every time they wanted to use it – and changes to these files needed to be saved and roam with the users. The other problem was that every user in the company needed to be able to use the software – but not all of them used it constantly, some users just accessed it once a month. So how to solve this? Do we have every user who logs in copying 55MB of files into the system drive at login time? Limiting the file copies by group would make no difference, because just about everyone needed access to it – just not all the time. With up to 50 users per server, we were looking at over 2.5GB of extra files swelling the system drive and being passed across the network at peak logon times – to up to 10 XenApp servers. Not a great situation when performance is key. DFS and junction points were thrown up at various points as suggestions but neither fitted the bill, for reasons I can’t easily recall (this was a few years ago, please forgive me!) But that’s when we realised we had an upgrade to AppSense v8 available, with the new selection of triggers that hadn’t been present in v7.
The first task, then, was to define the a node under the trigger we want to use for our Rubbish App, which in this case goes under Process Started
This ensures that the actions we are now going to configure only run when Rubbish_App.exe starts. Therefore, as not all users will launch apps at the same time or even, in this case, on the same days, we’ve already shifted the load away from the logon times.
The next thing to do is create a Condition. We filtered it by AD group, as although most users at the company used the app, there were a few (execs, contractors, etc.) who didn’t, so avoiding duplicating the actions was another way to save valuable resources. We use Conditions | User | User Group
So now, when the process starts, EM will evaluate the user’s group memberships to see if it should continue or not.
Next we add the first action – creating the folder that RubbishApp insists on using, with Action | File and Folder | Create Folder
Next we need to copy the required files into that folder from a network share where they are held, so we use Action | File and Folder | Copy File. We use the * wildcard to copy all files from the folder. You can also configure exclusions and conditions here for extra granularity, but we don’t need these at the moment, we want a catch-all copy
Now our node looks like this
So, to recap, when the process starts, it checks for an AD group membership, if that is satisfied, it creates the local folder and copies in the files. The user can now do whatever they need to with RubbishApp.exe without any error messages, and without hammering the network with multitudes of folder copies at logon time. We’re still dragging the 55MB in, but not for every user, and not all around the same time of day.
But hang on, didn’t we mention that certain files in this folder structure (ones that contain printer settings and some report files) need to roam with the user from session to session? So somehow we need to grab a copy of this folder back to the network location when the user is finished. How can we do this? Well, our Process Started trigger is nicely complemented by another by the name of Process Stopped, which we will create now
So we will put in the same Condition as previously, the AD group check, and then we will add another File Copy action, with the source and destination in reverse.
However, this time our destination files already exist, so we can cut down on the network traffic at process exit by using one of the other tabs in our Action, Condition. By ticking the box, we can set certain conditions for the file copy to run. In this instance, we will select the Compare With Destination option, and set the Property to Last Modified Time Is Greater Than. So, only the files from the source that have a Last Modified time after those of the destination will be copied, which works out well for us as it turns out there are only two files that should have been modified.
Finally, we will want rid of the files that have been stored on the XenApp server, as the user may switch servers before launching the app again, so we will add an Action from Action | Folder | Delete Folder and use the Force Delete switch to make sure it is gone.
For posterity, here’s the finished Process Stopped node
So now we’ve managed, without any complex scripting, to get around the limitations of this poorly-written program and provide our thin client users with a familiar app that roams the settings they need, avoiding overloading the network and affecting the performance of our XenApp servers. The simplicity of the user interface is another thing that lends itself to adoption. If a contractor comes in and writes a 500-line script in VB or PowerShell to do something like this or another task, what happens if the next system admin then struggles to understand or update it? EM, on the other hand, is nicely laid-out in a clear hierarchial structure.
There are probably ways this can be done better within EM, and part of the EM experience is being able to constantly tweak and refine the configuration as it grows with your user base. For instance, what if a user logged in on one machine, ran this app, then started the same app in another XenApp session without closing the first one? Keeping the files updated in this situation would be a challenge that would probably necessitate some more advanced work and might even bring Personalization Server into the equation, but that’s beyond the scope of this quick look at building configurations using Triggers. Hopefully though, you can see the benefits of being able to launch actions beyond the capabilities of what Group Policy and custom scripts bring to the table, and see how it is delivered in a much more user-friendly fashion for the administrator.
Share
