Physical efforts in virtualization and mobility
I was recently engaged in a project for a large organisation using physical desktops which were a mixture of Windows XP, Vista and 7 (Oddly, Vista took the lions share by a considerable margin). Roaming profiles were in use and users did indeed roam between workstations. Sadly for them, this meant that they also roamed between the three generations of operating system with the same profile – As you can imagine, profile corruption was a common occurrence; as was calls into the service desk where and profile resets and users having to setup their environment again. A Windows 7 rollout was in progress but was slow going, partially due to the myriad of different applications in use. It would be complete but probably not for eighteen months plus.
Option 1: Bin roaming profiles, this would make life considerably easier for support teams and is a viable solution as it would also in some respects make life easier for the end users. Yes users would have a more stable environment but would have a lack of flexibility. In a scenario whereby users only roam to a few machines and it’s the same ones each time, they only need to go through the pain of setting up their profile once per first time logon of each workstation. If users constantly move around an organisation, to different sites within and a hot desking strategy is in use, the limitations grow further. I have come across a number of organisations that have taken this easy way out and just decided to switch off roaming and move to local profiles.
Option 2: Implement a third party profile management solution such as AppSense Desktop now (Environment Manager/Personalization server). This would enable full cross platform support hiving off personalization into a central SQL database resulting in a consistent look and feel and slick logon times. This preferred and the Rolls Royce Solution, the trouble with is it comes with a Rolls Royce price tag for the number of users and endpoints concerned (a few hundred k).
Option 3: A more dynamic approach to standard Windows roaming profiles, this is where each of the three OS types in use is tied to a profile relevant to it. In the scenario where an end user logs onto XP, Vista and 7 over a given period this will result in them having three separate profiles and yes they would need to set it up three times for each initial login (…but maybe not, more on that later) but they will be able to roam freely with a significantly reduced risk of profile corruption.
Dynamic OS Profiles
Now as you may have guessed we went with Option 3 (although option 1 was popular within IT). Before finding out how to facilitate this solution, I did think about how profiles could be tied to an OS but it wasn’t my own so I’m not making any claims to this idea, it is explained in this blog which I found:
I’m going to go through the implementation of this in a real world scenario though as it sounds great in theory. Basically as described in the above blog it relies upon an environment variable to be on each desktop in the organisation, and remember it really does need to be all of them as potentially any all users within AD will end up with a generic user profile path. The variable is referenced in the profile path so the target workstation must be able to understand what that variable is, otherwise it will not direct users to the correct directory on the file server. You will end up with a directory called %variablename% containing the profiles of users that logged onto machines that don’t have the variable set. As a side note we decided to take the added opportunity to move the profiles to a new file server.
I have described one of the pitfalls above, so it is key that we get that variable set, what we used was:
%OSVer% = WinXP
%OSVer% = WinVista
%OSVer% = Win7
So for this, as described we wanted to use on policy harnessing Group Policy Preferences (GPP) and item level targeting to point to the OS specific for that particular variable. But there was a stumbling block, only the Windows 7 workstations could process the policy because both XP and Vista require the Group Policy Client Side Extensions pack (KB943729). Now there’s a couple of points I would like to make here:
Oh well rant over, so Windows 7 desktops would be fine in this case but they only made up about 40% of the estate, we have another 8,000 or so machines to deal with. Well, it’s quite simple really as WSUS was up and running so we pushed it out. This leads to another issue though in that WSUS hit rate is by no means 100% so we needed to cover ourselves. Enter one of my own ideas (something new!)
ADM Template to set environment variable
So to handle legacy clients that do not have the CSE’s installed I created an ADM template (old school) so the variable by can be added via classic policy instead of preferences. It uses the registry location for where variables are stored and enters it there with a free text field.
<pre> CATEGORY "Operating System Identifier" KEYNAME "SYSTEM\CurrentControlSet\Control\Session Manager\Environment" POLICY "OSVer" PART "OSVer" EDITTEXT DEFAULT "WinXP" VALUENAME "OSVer" END PART END POLICY END CATEGORY CLASS MACHINE
It looks like this:
Of course this is only part of the solution, clearly we need three independent policies; one for each OS but we need to make sure the correct policy applies to the relevant OS. This is where WMI filters come in.
The Windows 7 policy may as well use the GPP method, there is no point in using the classic ADM file method for that. At some point once all of the legacy clients are replaced this will be the only policy in use and it can be used to cover profile variations for Windows 7, 8, 8.1 and 10. So that leaves two WMI queries to create which are below:
Under the root\CIMv2 namespace
Description: Checks if the OS is Windows XP
Query: select * from Win32_OperatingSystem where Version like “5.1%” and ProductType = “1”
Description: Checks if the OS is Windows Vista
Query: select * from Win32_OperatingSystem WHERE Version like “6.0%” AND ProductType=”1″
Then in the Scope section for the policy in the previous screenshot assign the filter:
Pushing the Go button
Now this is complete we can change all users to point to a single common profile path in their AD account:
Pro tip: Do yourself a favour and use a dfs namespace for this, it will make your life easier in the long-run
So say we have thousands of users that we want to change the profile path on, what’s the best approach for achieving this? Run a script to update the path perhaps? Yes this would work, if you are going for a big bang approach but I prefer staged migrations. Start with say 10, review, then based upon results, increase to 20 then 50, peaking at no more than 100 per day. What this results in is a background task that takes a few minutes out of every day.
The method I prefer over scripting in this instance as to use the multiple selection option of Active Directory Objects. You know, hold down Ctrl, scroll down and select type of thing, then go to properties of the multiple objects. Select 50 per day (once past pilot) and what you will end up with is something like this, a reduced set of properties that can be set for all selected objects:
Tick the Profile path: box and input the path detailed above.
We have a solution; it’s all very well having an answer to a problem but pushing the go button is another thing entirely. How do we want to handle this, use it as an opportunity to refresh everyones profile? Copy the existing ones from and old file server to the new? Well initially I thought the former but then I thought do I really want to deal with the support issues that 10,000 plus users may have setting up their Outlook profiles, complaining they have lost their NK2 cache and signatures etc.? No thanks.
How about copying the profiles as is from one location to another? Not ideal considering they are all currently in one flat and mixed up lump as they need to be in the three separate folders per operating system. It may be possible to move the XP ones out but although we know Vista and 7 profiles are incompatible, I couldn’t any discernible differences from a file system perspective.
What we are left with is only one real option and that is to rely upon the local cached profile. What this means is that if we make the profile path change detailed above, when the user logs on, it will log on no differently to normal. Then at logon time, it will write back to the new location. Of course we are likely to be making the changes when the user is still logged on. This is fine as the change will not take effect until the next subsequent logon.
As a safety net I wrote a backup / restore batch script to protect against any issues that may occur as a result of using these cached profiles. This blog is quite long enough so I’ll cover that in a separate post.
As you can see, this method is a bit of a phaff and I haven’t even explained it all here as it is explained in detail in the linked blog. If you can, you should try and go for Option 2, it is superior to Option 3.
It does work though, and is better than the alternative of sharing incompatible profiles.