This article focuses on a challenge that administrators would face, deploying RES Workspace Manager into an existing windows estate: How to sneak the software onto the user’s computer without them noticing it. Why do this? I believe most of us who have ever dealt with support and/or user administration are painfully aware, that the slightest of changes to the user’s environment is likely to cause the supportphone to glow red hot, things being blown out of proportions and wildly exaggerated. Finally, you are likely to find yourself blamed for everything from the neighbors dog doing it’s business on their lawn, to the fall of Ancient Rome. Exaggerated? Absolutely, I just had to get that off my chest. We can probably all relate, so let’s get down to business.
One of the key features which was introduced back in PowerFuse 2010, was the ability to do gradual Desktop Transformation which is exactly what we need to address this challenge. Using transformation we can bring in managed configuration and changes into the existing environment in the tempo we are comfortable with. In addition, RES Workspace Manager offers you the ability to use Workspace Models, which is a powerful ally in this game. There is a separate article RG027 that explains the ins and outs of these objects. You will also likely need a Workspace Container for this job.
- As the very first step of this transformation, you will likely want to deploy the RES Workspace Manager Desktop Sampler (DTS) well in advance. By doing this, you will be able to record all the non-application specific settings inside each and every user’s environment. Let the Desktop Sampler run for 1-2 weeks at minumum. The longer you run it the better, but the relevancy of the extracted data per typically peaks around 30 days. The Desktop Sampler is completely unobtrusive and is described from page 16 in the RES Workspace Manager Administrative Guide. I might do a separate article on it later if there is a need. Once the DTS is deployed, there’s no need to sit back and idle. Now we will deploy Workspace Manager in Stealth Mode:
- Next thing to do, is to switch off the Splash Screen. Reason being there is no need to call attention to the fact that something has changed on the user’s computers. Note that when you switch off the splash screen, this is a global option. In other words, you cannot choose to display the splash to some users, while hiding it for others. In the Workspace Manager console, go to Composition | Desktop | Lockdown and behavior and mark the checkbox for Hide Splash screen. Don’t worry that the Desktop and Lockdown node seems to be disabled. It’s only the items with the Padlock icons ( ) on that are disabled. See this part of the Workspace Model article for further info.
- Before you do the following two steps, it’s worth stopping up and consider something. If you are creating a new Workspace Manager 2010 database from scratch, the default workspace models Global Settings has everything turned off already. In effect, a Workspace Manager agent deployed and connected to this new database would behave quite stealthy without any changes. This means that if you haven’t enabled anything yet, you can skip the next two steps and the ADDTOWORKSPACE attribute described further down. I will however in this article presume that you’ve already made some sort of changes, enabled some items in the global settings. This way you will learn how to make an exception workspace model so you can have some computers already fully managed, while introducing Workspace Manager gradually on others.
- So, presuming we need to make an exception, Go to Context | Workspace Containers, and create a new Workspace Container, call it anything you like. I’d suggest the name StealthMode.
- Go to Setup | Workspace Models and create a new model for the StealthMode container, using the PlusMenu. Again, if you are not sure what’s going on at this point, read article RG027. Be sure to switch everything off in the new model. Have the top setting for Managed Applications set to “Do Nothing”, and make sure the Global setting for Shell is set to “Use Microsoft Windows Shell as the default shell”, as it cannot be overridden by exception workspace models.
- Using your favorite deployment tool (which I of course presume is RES Automation Manager’s MSI installer task :) you would create an unattended installation of the RES Workspace Manager agent/client. There are several MSI public attributes that deal with connecting the agent to the central Datastore, however while these are important, they are not the scope of this article. See this article (Link to parameter article) or look at Page 303 in the Admin Guide. The parameters we need to focus on are the following:
The ADDTOWORKSPACE attribute will automagically place the Workspace Manager agent into the Computer Control tab of the specified workspace container, thereby making sure that the attached workspace model becomes active for it when the Workspace Composer is fired up later. The other two attributes, AI_DESKTOP and AI_STARTMENU controls if icons for Workspace Manager components (such as the console, etc) are placed respectively onto the Desktop and Start Menu. Default value, if ommited is 1, but if you set these two to 0, no icons are created. Net result is more stealth!
Last comment about the deployment job is to NOT add a reboot task. This measure will become clear in a few steps; have patience young Padawan.. :)
- Normally we would reboot the target computer to enable the Workspace Manager kernal mode driver. However, since we’re trying to operate under the user’s radar here, we don’t want to barge in and reboot his computer in the middle of everything. When the deployment job is finished, you will find the newly installed computer in the console’s Setup | Agents viev. If you’re already there, hit F5 to refresh. You will notice that the columb named ‘AppGuard Version’ will display INVALID on the new agent. The reason is simply that the given computer hasn’t been rebooted yet, hence the kernal driver hasn’t registered yet.
- At this point there’s not much to do but wait around until the user restarts his computer. Usually this will happen at the start of next business day when they fire up their computer again. Note, that if it’s a laptop and they are offline, the kernal driver will come active, but you won’t know about it until the laptop is online with the corporate network once again. If you’re the impatient sort of fellow or perhaps a regular BOFH, you could (hey, I didn’t say should!) pop down in the basement and Chuck-Norris-Roundhouse the fusebox, blaming the power company afterwards… :-)
- Once the target computers have been rebooted (one way or another..) the column ‘AppGuard version’ will change to a x.x.x.x version number. This can sometimes take a couple of minutes as the RES Service (link) has to start and connect to the database, so don’t panic if you don’t see the change immediately. Once you see the change for a given computer you can proceed to the next step.
- Rightclick on the agent and select ‘Run Workspace Composer’. Set the agent to Automatic. For more info on what’s going on here see this article. Next time the user logs on, he/she will in fact be running inside a Workspace Manager session. You can verify this by going to the console’s Diagnostics | User Sessions tab, where you should see the username on the given machine. This is where the fun starts.
From here on out, it’s really up to you what you want to do first as part of your Desktop transformation process. Go to your StealthMode workspace model (or just your global settings, if you started from scratch) and gradually switch on the items you would like to inject into the user’s environment, for example you could start with eliminating the loginscript drivemappings. Since you ran the desktop sampler in the first step, you should have a bunch of nice .dts files ready to import, so this step should be a snap. Then you could move on to applications, gradually replacing existing shortcuts with Managed applications, where you in the workspace model would chose Merge with unmanaged shortcuts.
Another suggestion on what to do here, is to switch on User Settings in stealthmode, create a managed application, where you set the zero profile mode to specified mode, perhaps also switch on sampling mode, and only put on the preserve flag. This will pick up existing known settings from the existing environment and enable to cargo-lift them into a new managed state of the environment. If this sounds like utter gibberish to you, I will probably crank out an article on the subject later on.
Finally, to help you on your way, here is a nice little RES Automation Manager module that I put together for you to help you deploy Workspace Manager in StealthMode. Note, there are no binaries in this buildingblock as I’d probably get roasted 50 different ways if they were. All you have to do to get the buildingblock to work is to replace the dummy-resource-x.nnn resources with the RES-Workspace Manager-2010-SR1.msi installer and the language pack installer Auto-LanguagePack-2010-SR1.exe. Both files are available for download either via the corporate DL site (registration required) or the RES Portal (login required)
No comments yet.