It's a long time since I last focused on anything to do with the usage of Group Policy settings and files in Environment Manager. To be honest, the original article is getting a bit old - and some of the images seem to have become corrupted, rather distressingly - so we will give it a quick rewrite and bring it back to the present day :-)
Let's start with some basics.
Why use Environment Manager to deploy Group Policy settings?
Why indeed? Most environments have the Group Policy engine running alongside their Active Directory infrastructure, so why would you need to use EM to deploy your GPO settings? Well, first and foremost is the idea of having "everything under one roof". I've worked at lots of places where, to troubleshoot a user issue, you'd have to look at the AppSense console, rake through Group Policy, dig into some Citrix policies, open the App-V Management Console, and finally read through a logon script. All this takes time, and for support guys time is often of the essence when users are screaming about not being able to work. If you are using AppSense the software has enough power for you to seriously consider using it as your "one-stop shop" for the deployment of all user settings - and, if you want to, a lot of your machine ones too. AppSense Environment Manager and Application Manager together can give you all the functionality of most GPOs, just about anything in Group Policy Preferences, probably everything you ever wrote into logon scripts, deploy streamed apps from App-V and replicate most (but not all, sadly) of the functionality you get from Citrix policies (something which we will touch on in a later post).
The limitations around the GPO functionality reside around things that are normally found outside of the Administrative Templates, which include things such as setting startup types for services, account policies, and the like. If you desperately needed to get all GPO functionality into the AppSense console, you could accomplish it with registry imports and custom scripts, but there's no shame in having some of your settings still provided by standard GPOs, particularly if they are flowing down into your AppSense-enabled systems from a higher OU. A lot of places adopt a mantra that sometimes you will hear from AppSense themselves - "manage the user through AppSense, and the device through Group Policy". Whilst not suitable for all, it's certainly a good guideline to adopt if you occasionally find EM and GP at odds with each other.
And don't forget, there's always the chance that later versions of AppSense EM and AM may incorporate functionality that allow you to do these things that currently you have to fall back on GPOs to accomplish. For instance, the latest version of Application Manager includes the functionality to dynamically assign User Rights to users or groups from the domain. There are also functions in Environment Manager that cover commonly-used GPO tasks like Folder Redirection, which in Group Policy land is also outside of Administrative Templates.
When Microsoft acquired the Group Policy Preferences part of their software they certainly ramped up the competition between themselves and AppSense, but AppSense still wins on one major count - the unique trigger actions that AppSense allows you to take advantage of. Currently, user-level Group Policies apply at logon and then reapply every x minutes, machine policies apply at startup and again every x minutes. With AppSense, you can cut down your logon time by only applying the GPOs when you need them - "just in time, not just in case". For instance, if you had a whole host of GPOs associated with Microsoft Word, why do they need to be imported when a user logs in? Using AppSense EM, you can import them when Word starts, saving valuable logon time - and also ensure that the policies are never applied again until the user starts a new session. Without AppSense, you can only limit the scope of your GPOs by OU/site, or by security group/user, unless you fancy doing some tricky WMI filtering. With AppSense, you have a whole host of Triggers and Conditions to take advantage of that are quick and easy to set up. You could launch GPOs based on logon/logoff, processes starting, session locks and unlocks, registry keys, environment variables, date and time, files and folders, screen resolution, even screen colour depth! Most, if not all, of the "item-level targeting" features you get from Group Policy Preferences are available through Environment Manager - with the added bonus of the triggers too, which GPP doesn't have in its armoury.
I also prefer to use Group Policy Actions with AppSense Environment Manager rather than using Registry Actions. This preference also involves me using old-fashioned .ADM files as well as .ADMX files, because I find it easier to write old ADM files than use XML :-) But seriously, I know Microsoft themselves actually recommend using Group Policy Preferences to deploy Registry settings rather than using an old ADM file, but look at it this way - from the two screenshots below, which of them is better at telling the administrator what the setting you are deploying actually does?
 |
| Deploying a setting via a Registry value (whether set by EM or GPP) - not very clear as to what the setting does |
 |
| Deploying a setting via a Group Policy file - much more clear as to what the setting does |
Naturally, it's the second one - the ADM file we have created gives us much more of an understandable explanation than the simple path to the Registry key, some of which can be far more cryptic than the example provided.
AppSense's implementation of Group Policy is also configurable in little ways that make it even more appealing. There's the option to use User Personalization to either override or be overriden by GPOs - essentially allowing you to turn any Policy into a Preference of sorts. They also have a handy "apply policy settings permanently" check box which lets you decide whether or not the GPO can "tattoo" the user profile. There are settings similar to this in GPP - think "remove this item when no longer applied" - but the AppSense setting can also apply to standard GPO settings.
However - there are limitations. Group Policy is applied on a scheduled refresh basis, whereas the AppSense policy is pushed out based on pre-determined triggers. Additionally, in a PVS or other streamed-disk environment, Computer GPOs are much easier to deploy than AppSense Computer Startup actions, which currently necessitate a vDisk update every time you make a minor change. There's also the overhead of finding out some of the Registry keys involved and/or creating ADM/ADMX files for settings you may find that are beyond the scope of the software - although AppSense are getting good at adding new things into there as time goes by.
And now onto the bit you really want to know :-)
So, how do we deploy Group Policy settings using the AppSense console?
Well, the first thing to do is create a central share or repository where you can find all of your required ADM and ADMX files and add new ones as required. You can either create a central area or alternatively place them all into your golden image, if you're using a technology like Citrix Provisioning Services. The main thing to remember at this stage is put the files somewhere all admins can get to them - no matter where they have the consoles installed - because there's nothing more frustrating than an error message like this when you are trying to edit a GPO Action
So, once you've done this bit and ensured that all of your ADM and ADMX files are globally available to your designated admins, let's start creating some settings! We will put together some settings for the Screen Saver in this example.
Another quick note before we start - for troubleshooting and optimization purposes, it is important to keep your GPO Actions as "one setting, one Action". (I mean each GPO setting you configure should be contained in an individual Group Policy Action in the console, in case I'm not being clear enough) Now, if because of previous bad practice you end up having to migrate a single Action containing tens or hundreds of settings into individual ones, you may experience a lot of frustration - but believe me, the frustration will be worth it because it will a) run more smoothly, and b) be a hell of a lot easier for your support staff to troubleshoot. When you have many settings in one Action, you can only disable them individually by removing and re-adding them - but if you have one setting per Action, you can simply right-click and choose Disable, making trial-and-error troubleshooting vastly easier. Examples of good and bad Actions are shown below.
 |
| An example of a BAD Group Policy Action - many settings in the single Action |
 |
| And a GOOD Group Policy Action - a Node with lots of settings in individual Actions |
Now, we are going to put these Screen Saver settings in the Logon trigger, as that is the most logical position for them. If you were creating something like Microsoft Word settings, you would place them inside the Process Started trigger for winword.exe, as we must load our policy settings when we need them - not if we need them.
To insert a Group Policy Action, we right-click in the right-hand pane and choose Action | Group Policy | Set ADMX Policy or Set ADM Policy (naturally this is defined as to whether you are using ADM or ADMX files for the settings!) Most newer Windows systems use the XML-based ADMX format, as will most custom files these days, unless they're written by me :-)
Next you will be confronted by this screen. If you've stored your ADM/ADMX files in a different location to the default (the default for ADMX is c:\windows\PolicyDefinitions, and for ADM it is c:\windows\inf), you will need to use the Browse button to locate the folder where the target files are stored.
Note the "apply policy settings permanently" option (unchecked by default). If this option is checked, the settings applied by your Group Policy Action will not be removed at logoff. Effectively, they will be saved as Registry settings under the user Registry in the user profile (ntuser.dat, if it's writeable) or into Personalization Server, if you're using it. Machine settings in this case would be saved into the endpoint's own Registry. I'd recommend not using this setting unless you have a particular need for it - otherwise you may end up putting together Registry Actions just to reverse the possible implications of one-time Group Policy Actions.
Some people have recommended using the "apply policy settings permanently" feature, especially with mandatory profiles, to ensure that issues with mid-session configuration changes don't revert GPO settings. Whilst this is technically correct - the nature of a mandatory profile will mean that settings can't persist in this way - it's not recommended, especially if you use Personalization Server, another profile management tool or any form of Registry hiving. If you're having issues with mid-session configuration changes, I'd update to the very latest version of the AppSense DesktopNow software and log a case with AppSense support if your issues continue, rather than continuing to box around the issues by using a feature that could give you problems in the future.
Some people have recommended using the "apply policy settings permanently" feature, especially with mandatory profiles, to ensure that issues with mid-session configuration changes don't revert GPO settings. Whilst this is technically correct - the nature of a mandatory profile will mean that settings can't persist in this way - it's not recommended, especially if you use Personalization Server, another profile management tool or any form of Registry hiving. If you're having issues with mid-session configuration changes, I'd update to the very latest version of the AppSense DesktopNow software and log a case with AppSense support if your issues continue, rather than continuing to box around the issues by using a feature that could give you problems in the future.
Next we click the Add button to add in a policy and are presented with this screen. Obviously, if you've already defined some policies here, you can use the Remove button to get rid of them - although if you've stuck to "one setting, one Action", then you just have to remove the Action itself, and the Remove button will become redundant.
This screen shows you all the available Group Policy settings from the folder specified earlier (so if you've got something like the Microsoft Office ADMX files loaded, expect to see a lot more settings displayed here). Note in the bottom left of this screen, the input bar which allows you to Filter the settings. This is a very handy utility - start typing into it and it will dynamically filter the settings until you find the one you're looking for. In this case, we will start by typing Screen saver
and you can see that the list of available settings has been reduced instantly, making the job of finding a setting so much easier. Cool!
So now we will locate the setting we want to deploy, which is Enable Screen Saver, and double-click the setting to configure it
then click OK three times (yes, three times, that's a bit of a pain, unfortunately), and we're done!
Now it's time to rinse and repeat this as many times as necessary to get all of your Group Policy Actions set up - nesting them as required inside of Conditions and Nodes to achieve the correct settings for all of your users.
It's worth mentioning that I've seen GPO settings deployed in this fashion behave somewhat strangely on a couple of occasions when configurations are deployed mid-session, and it doesn't appear to be limited to Actions that avoid the use of the "apply policy settings permanently" checkbox. If you do see anything like this, I'd recommend updating your software to EM8 FR4 SP1 (due to be released in the next few weeks, if I remember correctly) as soon as possible, as this seemed to resolve the issue for me.
The other feature around Group Policy Actions is the Personalization (UEM) tab. If you are using the Personalization Server feature to save profile settings, if a user changes the setting, Personalization Server will capture this and apply it at next logon. This tab allows you to select whether the policy setting (set by you) or the Personalization Server setting (set by the user) takes precedence. In effect it is giving you the choice of setting this option as a Policy (can't be changed) or a Preference (set at first logon, but can then be altered by the user). In most cases you will probably want the setting to persist, so if that's what you want, set the policy to override Personalization Server as shown below. Note that the Personalization (UEM) tab only appears in Group Policy Actions configured in the Process Started trigger - as Personalization Server only operates on a per-application basis.
Hopefully this covers all of the questions that people have around using Group Policy ADM and ADMX files in Environment Manager, as well as replacing the damaged article that was published on this subject originally. In my opinion - and especially for userland settings - running Group Policy settings through EM gives you a far more granular control of your user environment. When combined with custom files, they also allow you to do everything Group Policy Preferences can achieve - and more. I am working on providing some downloadable custom files to allow us to work with things that we currently can't in Environment Manager, such as Citrix policies and Folder Options, to name a couple off the top of my head. Hopefully these will be available soon and we can extend the power of EM combined with Group Policy further still!