From the The-GPO-has-you Dept. As of recent, one of my clients was facing an interesting issue: They wanted to do a seamless switchover from a currently windows GPO managed environment to a RES Workspace Manager environment. Essentially the job was to devise a method to make one system let go and have the other one take over at the same time. This example was built on a 2012R2 AD with a Win7 front-end.
This method revolves around using a simple AD group that serves a dual purpose. 1) When a user is put in the group, specified policies are denied and 2) Workspace Manager takes effect. The nice part of this approach is that it is fully reversible, just by removing the user from the group.
Relax. I’m not about to embark on a marathon rant on what I think about MS policies. Suffice to say is that when you’ve got Workspace Manager, the one good thing about policies, is that they can be denied! This is exactly the mechanism that we are going to use in this scenario. This means that you can implement this step without any impact in a production environment. For my example here (and since for obvious reasons I don’t use policies on a daily basis), I created a demo policy that is mapping a drive. For the giggles, I configured it to set the drive’s friendly-name to “Mapped by AD Policy” This will make it easy to spot when the policy is taking effect and when it’s not. The whole thing looks like this (click to enlarge):
The following are the items we need to put in place before we can start switching things around, denying the policy and afterwards enabeling the Workspace Manager:
- Start by creating a regular global security group somwhere in your AD. I’m a fan of no-nonsense names and since we’re going to have a bit of twisted logic it’s especially important to name the group in such a way that there is no misunderstanding what happens when you put someone in it. Love it or hate it; I called the group POLICYno-RESWMyes.
- Next thing to do is to load up your Group Policy Management console and locate the policies which you want to disable, once Workspace Manager is active.
- For each policy, rightclick and edit, then in the Group Policy Management Editor rightclick on the policy at the top and select properties.
- Go to the Security tab and add the group created in step 1, then select Deny for the Read permission. Once you hit okay, the console will pop a warning that a Deny will override everything else, and that’s exactly how we like it.
So far the above will effect no change to your production environment, as long as you don’t lob any users into the group just yet. We’ve got a few more things to do before we are ready to proceed.
Unless configured otherwise, certain policies have a nasty tendency to stick, like gum in your hair after a Dublin pubcrawl with the E2E crowd. Group Policy Preferences is an example of this. There are however ways to deal with mentioned behavior, however some assembly is required, as you will need to drill into every GPP policy you want to have stand down on command. (if there’s a smarter way of doing this, feel free to comment). The goal of this part is to ensure that Windows lifts the configuration policy, when it is no longer required.
Warning: The following changes could potentially impact your production environment. For example, if you have policies that you think are in effect but are actually just reminiscent leftovers, which haven’t been lifted, implementing this change will in fact pull the policies back from any user’s not affected. Thus the morale of the story is: Be ready with a RES WM environment capable of taking over, when you effectuate the change.
- In the Group Policy Editor, drill down into each GPP policy below User Configuration|Preferences
- On the Common tab, look for the option called “Remove this item when it’s no longer applied”. Checking this box will ensure the item is removed once the policy is disabled.
Other policies should generally revert themselves by default when denied, although your mileage may vary: Keep in mind the change may take a while to propagate throughout your installation.
The workspace container:
Next up, we need to turn our attention to the Workspace Manager. For the sake of keeping this article within the bounds of sanity, I will have to presume you already have built a WM environment that configuration-wise is capable to replace all your current user policies. If you need help with this, well – you know where to call :) The real question is, are you already using WM for some users or not? This is a very important question to answer, as this will have impact on how we configure things:
- If you are building a fresh new and shiny RES environment, which has not been delegated to anyone yet, then things are relatively easy. The rationale is that everything in WM is turned off per default when you install it. In that case we will need to configure an exception WM for turning things ON or enabling features, when you are member of the AD group above. We will call this the GreenField scenario.
- If you are actively using workspace manager to configure things for some users already, you will need to create an exception to disable or turn things completely OFF for the users still being managed by policies. We will refer to this as the As-Is scenario. We’ll get into that in a bit.
Either way, follow these steps to set up the proper workspace container.
- Under User Context|Workspace Containers, create a new container. If you are configuring for a greenfield RES environment, call this container WM.Enabled or WM.Disabled according to which of the two scenarios you are dealing with.
- On the Computer Control tab, mark the [ ] Include all agents checkbox.
- On the Access Control tab add the AD group from the previos tab to the Identity box
- If you are in a As-is scenario as described above, hit Edit on the group rule and check the box [ ] Exclude members of the selected group. This will effectively negate the logic.
NOTE: If this is your first workspace container, be aware of the login-restrictions on workspace containers: When one or more workspace containers exist, you must have access to at least one of them in order to get into the managed workspace. See article RG052 for more information how to deal with that.
The workspace exception:
Once you have the workspace container in place, it’s time to configure WM to do things different when the container lights up. Once again this ties into your current mode of operation; either GreenField or As-Is. The operation is as follows:
- In the WM console, go to the Administration main node and into Workspace Model
- Hit the [+] menu and add the workspace container you created above. A new tab will appear.
- Make sure you move this container to the front of the processing queue by rightclicking on it selecting Increase Priority until it’s as far to the left as it will go..
- If you are building to an As-is scenario: Turn everything off in the workspace model (note: as of SR3 22.214.171.124 there is still a BUG (yes – that’s what they are are called). If you disable Hyperdrive in your workspace model it will throw an error when users log on, so leave that setting alone.
- If you are building towards a Greenfield scenario, it’s a lot simpler. Workspace Manager will per definition have everything turned off per default, so your exception workspace container you will just need to turn on the items that are needed when Workspace Manager is active.
One potential item to keep an eye on, if employing this approach is this: If you are dealing with a hybrid environment, for example if you are employing XenApp as well as local computers and the currently active policies are in effect in both environments. Since the policies we are interested in disabeling are user policies it may be necessary to enable loopback processing of the active policy on the target environments. There is more information on that here.
If that isn’t your cuppa Joe, you might consider bringing up both environments to a state where they are ready to switch to WM management. Again presuming you’ve already built the WM configuration, then in most cases it is a matter of just getting the WM agent out to all target environments before making the switch for a user that logs into both.
Last, bear in mind that Workspace Manager is actually running in the session, regardless if the user is in the denial group or not. Thus it may make sense for you to disable all splash screens under Desktop|Lockdown & Behavior. Remember: Last guy to show a splash screen always gets the blame.
Once you have the above working, all you need to do is to add/remove people from an AD group to determine if either GPO’s are handling the session or RES Workspace Manager is. From here on out, I’d recommend adding extra Awesome Sauce, by creating an IT Store service around this, so for example a service desk can migrate users into WM using the simple point and click interface of the IT Store’s web front.