In an interview recently I was posed a fairly interesting question which concerned restricting laptop users at low-bandwidth sites from running locally-installed applications.
It’s an interesting theory, the idea being that at low-bandwidth sites the laptop users would be forced to use XenApp-based applications (such as Office) rather than running these apps locally and connecting up to the myriad file servers to open documents in their locally-installed apps across what was a very poor connection. Before we discuss how to achieve this, I must confess to not being entirely convinced of the merits of this approach. What you are looking at is whether the volume of data handled by the application running in a client/server config is larger than the volume of traffic shuttled forth between XenApp client and XenApp server during a session. You’d also have to give some thought to latency – some apps are more tolerant of this than others. Suffice to say, deploying this fix to address issues across sites with low-bandwidth links would have to be subject to some sort of testing – it’s not something you’d simply want to put in place to try and speed things up without being sure that there is some benefit to be gained.
These disclaimers aside, I was instantly drawn to Application Manager (naturally) when trying to think of a solution to this hypothetical problem. It’s the part of the AppSense Management Suite that deals with restriction of execution. What you would have to do is configure a Device Rule based around the IP subnet that then blocked access to local installations of Office applications.
First of all you’ll need to right-click the Device Rules section and choose Add Device Rule. As usual, rename it to something intuitive. Next right-click in the blank area on the right and choose Add Client Device
You can see you have several configurable options here, specifying a hostname, IP address or IP range (using static boundaries or a wildcard). As an example here, we will simply specify anything in the 192.168.1.x subnet, which represents our theoretical low-bandwidth site. I don’t know why Application Manager doesn’t support adding an AD site in this section (that could probably done via a Scripted Rule), but that’s maybe something for the future.
Important to note here is the difference between the Computer and Connecting Device options. In base terms Computer relies on the %hostname% variable whereas Connecting Device relies on the %clientname% variable. Obviously if your AppSense-enabled endpoint is a remote system like XenApp or XenDesktop the Connecting Device option is valid, but in this instance we are talking about an AppSense-enabled laptop so Computer is the option we want. Obviously if we chose Connecting Device, the restriction we are about to put in would apply on the XenApp servers so would work in reverse for what we want to do in this example.
Next we need to add some Prohibited Items under this rule. We’re looking to restrict Microsoft Office from executing, so we will right-click in Prohibited Items and choose Add Folder, which should allow us to catch all the locally-installed Office executables in one setting
Some of you are probably thinking “well the users could just copy the Office folder to the D: drive and run apps from there!” Agreed, but if you think your users are savvy enough to try this (and they actually have another drive partition with Write access), you could simply restrict that too. Application Manager lets you restrict files, signature items, network locations, folders or entire drives, so you have plenty of options. You could even restrict the file names directly without paths – but you may want to test this thoroughly first.
For a transparent way of doing this, you could also use Environment Manager to deliver desktop shortcuts for the remote XenApp version of Office (possibly even removing any existing local shortcuts and replacing them) when a user logs on from a site in the target subnet range. This would ensure that the whole process of forcing the apps to run remotely is more or less invisible to the user. You could even use AppSense to ensure that the PNAgent/Online Plug-In/Receiver/whatever-it’s-called-now only runs for the user when they are at the remote site, making the whole process even more seamless.
Hopefully this should give you a bit more of an idea of the kind of things you can achieve by using the various parts of the AppSense Management Suite together, even though I’m not convinced of the validity of the exercise in this case. AppSense’s products can certainly provide a solution for a huge amount of use case scenarios.
Share
