From the REScue 911 Dept. Recently I was involved in a client project where they had a problem. And it was a big problem: Effectively they were using another profile management product which was malfunctioning. I’d prefer not to give the game away by naming the vendor. Not that I have any problem with verbally beating vendors over the head when they deserve it – this is out of courtesy to the client.
Suffice to say, the product in question employed by my client was practically holding the user’s profile settings hostage. Allow me to clarify: If your current UEM tool redirects a write to a proprietary format, you are putting all the user’s profile data into a basket you have no or little control over. Meaning: If you switch said UEM tool off, then all your user’s settings are stuck in said basket. Before anyone gets their knickers in a bunch over Workspace Manager’s UPR and UPF files, let’s make one thing clear: RES Workspace Manager does not redirect settings into it’s own format. Instead it makes copies of existing specific profile items, be it HKCU settings and/or files – into a proprietary format. This means if you decide to turn off RES Workspace Manager, whatever settings were deposited in your profile, will still be where they were left. That being said, if you are running a volatile environment (non-persistent VDI’s or mandatory profiles) then obviously you have no place to keep things. Choosing RESWM to store your stuff would then obviously have the same net-effect.
With that out of the way, let’s look at the problem at hand. Essentially we have a large number of users with their settings trapped in another UEM product. The only time the users settings are accessible is therefore when their session is live, since at sessionend the current UEM product is redirecting all profile changes into whatever fiery pit of hell the developer thought was a good idea.
Our end-state gold is two-fold: First, we want to sift out profile settings while the user’s session is live. This should be do-able as the working presumption is that the UEM product at some point has to write it’s settings at some point before the user launches them. Second: Since the environment is a live production environment, we will have to provide a new fresh environment without said UEM tool.
We have now established there will be two environments. We’ll call them Old and New. We are going to create two RES databases with a shared user-settings location. One will only be reading settings out of the Old environment, storing them in the central user-settings repository. The other database, will read+write user settings for the New environment to this location. Once a user is moved from the Old to the New environment his/her settings will be preserved. The drawing below might help explain things:
The nice thing about this method is that it can be implemented without any risk to the existing Old environment and introduced at a pace of one user at a time if necessary. We will start by installing a workspace manager instance for the Old environment. If you don’t know how to do this, I’ll be happy to help you with it. The steps are as follows:
- Install a workspace manager console somewhere and create a WM database.
- In Application Settings, disable the disablement of Process Interception. In the Queens English, just turn it on. And yes, I hate double negatives in UI’s too) Note: Do not enable shortcut creation in here.
- Define the managed applications for which you want to grab stuff.
- Don’t turn on the User Settings subsystem just yet until you’re ready. Start creating User Settings entries as necessary. I will not lie to you, this part will take some time. Even with all the nice built-in templates, sample mode, etc. Depending on the number of applications for which you need to rescue settings, there will be some work to be done here before we can throw the lifeboat in the water. The following are tips for this work:
- If you are able to, go have a look in the existing UEM product and see what profile pieces are being grabbed. Then implement these in WM to the limit they make sense. Making sense is a fuzzy term as it can mean many things. An example is: If the existing UEM product worst-case is just grabbing the entire HKCU and %userprofile% then it would be asinine to implement it the same way in WM. Use common sense and try to break things down a bit.
- Be mindful of what should be global and app-specific settings in WM. For example all things relating to the explorer/desktop should be globally defined per default.
- Implement user settings using Capturing, not tracking. Remember capturing is great for acquiring settings from the past up to the present. Tracking is aimed at the present to the future. Since we are trying to get rid of the old environment, it’s future is limited.
- If you are in doubt when an app stores it settings, change capture mode to session-end instead of application end.
- Consider grouping applications into suites already at this point. Said grouping will make life easier when employing the captured settings in the New environment later. See this article for further information.
- Use sample mode to your advantage: Remember, when using Capturing, Sample mode will log the settings you are missing.
- Change the location of the User settings to a path accessible from the upcoming New environment as well. I usually recommend a UNC path like \\server\share\%username% if possible.
- Contact RESguru.com if none of the above makes any sense and we’ll get you started! I’m more affordable than RESPS ;)
- The last piece of advice is most important: As you create each user setting, be sure to uncheck the Apply flag to ensure it only gets stored by WM. See graphic on the right above. You could of course elect to do this later with search&replace. We will get back to this.
Once you have your anticipated user settings ready, it’s time to rig Workspace Manager to Run Silent and Deep. You may recall an old article from days past on how to do a StealthMode installation. No matter what you call it, this is the art of quietly slipping WM into a user’s session. There are several ways of doing this depending on if you’re trying to rescue an image based TS/Citrix or a workstation environment, physical or virtual. The key element here is configuring Lockdown & Behavior correctly:
- Be sure to disable any L&B items that may interfere with the user’s current environment. An important thing to remember: Even though Lockdown & Behavior is turned off, all the items marked with a gear icon () are still processed.
- Pay special attention to disabling all splash screens, as we don’t want the users wondering what is going on with that. Things are probably bad enough as they are (chances are that’s why you are reading this article) so there is no reason to give the support phone another opportunity to ring.
- Shutdown options (if physical workstations) may be a concern, even though it ought not to be touched by workspace manager as it’s a disabled lockdown item ( ). However, history has taught us there is a potential bug that users may loose their shutdown option, even if the subsystem seems to be turned off. I would recommend going through all the settings with a comb once and disable anything that even remotely smells of restriction in any way. That way you are sure WM doesn’t touch the target Old environment in any way.
A few optional tweaks to consider at this point would be A) enable Usage Tracking, B) enable Access Balancing and C) consider deploying the Desktop Sampler. Usage Tracking will give you a great overview of what’s actually being used and how much in the Old environment. Second, the Access Balancing logon-time monitoring will give you an idea how long it takes for Workspace Manager to silently spin up in the Old environment. Third, the Desktop Sampler will allow you to pick up session (not user) specific configuration being thrown at the user in the old environment. This is great for getting rid of any old logon scripts.
The half time summary
At this point you should have Process intercept enabled, User Settings configured and pointing towards the central storage path. You should have an unattended RES agent installed unattended onto your Old environment or baked into your VDI image, whatever may be the case. The WM agent is hooked up one way or another to a WM datastore. Said datastore configures the agent to run silent with no splash screen interaction and no workspace restrictions of any kind.
It’s time to throw the switch by enabling the Workspace Composer on the agent(s). Logging in as a regular user in the Old environment, one should notice nothing out of the ordinary except perhaps a slightly longer login time. The Workspace Composer needs time to start up as well. Monitoring the central storage location defined previously, you should see user directories starting to populate. Underneath these a userprefs folder will eventually be created with .upr/.upf files. When this happens, depends on how the individual UserSetting was defined; if the capture happens at app- or session end.
At this point, when a user has logged out of the old system (Something easily detectable via the WM console) in effect they are ready for migration. But we have to build something to migrate them into. That is the topic of the next article. Until then!