Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Asynchronous processing of Group Policy Preferences

My XenApp servers are set to process their GPOs synchronously (because I apply folder re-direction via GPO) and unless I do it synchronously there’s a chance that the user could login without folder redirection and only on the next login will folder redirection kick in.

However I have a bunch of registry keys I am setting via Group Policy Preferences (GPPs) and these take a long time. Eventually I decided to remove these from GPP and set in the default profile itself, and I have to figure out what to do later on when I need to make changes etc (I guess that’s still better as I only need to target the keys that need changing). But before I did that I was reading into how I can set GPPs to run asynchronously. I am ok with the registry keys being set after the user is logged in.

Well, turns out you can use Item Level Targeting (ILT) to have the GPP apply only in non-synchronous mode. I found this via this forum post.

If you want to do this en-masse for all your GPP registry keys you can edit the XML file itself where the GPP settings are stored. (Which is a cool thing about GPPs by the way – I hadn’t realized until now. All GPP settings, such as registry keys, shortcuts, etc. are stored in XML files in the policy. You can copy that XML file elsewhere, make changes, delete the GPP settings and copy paste the XML file into the GPP).

Anyhoo – in the XML file if your existing line for a setting is like this one (:

Add a new line like this after the above:

This adds a filter to that setting causing it to run only if the GPO mode is not synchronous.

This didn’t seem to make much of a difference in my case (in a very unscientific observation of staring at the screen while GPOs are being applied :)) so  I didn’t go down this route eventually.

On this topic, FYI to myself. By default GPPs are processed even if there is no change to the GPP. This is not the expected behavior. GPPs are called “preferences” so the impression one might get is that they set preferences, but let users change the settings. So I could have a GPP that sets an environment variable to something. The user could change it to something else. Since I haven’t changed the GPP after this, I wouldn’t expect GPO processing to look at the GPP again and re-set the environment variable. But that’s not what happens. Even if a GPP hasn’t changed, it is reconsidered during the asynchronous and background processing and re-applied. This can be turned off via GPO by the way. Lookie here: Computer Configuration\Administrative Templates\System\Group Policy\.

Totally unrelated, but came across as I was thinking of ways to apply a bunch of registry settings without resorting to GPPs: a nice article on the RunOnce process in Windows. Brief summary (copy pasted from the article):

  • The Windows registry contains these 4 keys:
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Run
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  • HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
  • HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

HKCU keys will run the task when a specific user, while HKLM keys will run the task at first machine boot, regardless of the user logging in.

The Run registry keys will run the task every time there’s a login. The RunOnce registry keys will run the taks once and then delete that key. If you want to ensure that a RunOnce key is deleted only if its task is run successfully, you can prepend the key name value with an exclamation mark ‘!’.

 

Registry keys for various settings

Continuing in the vein of my previous post where I want to try and apply more settings via registry key changes to the default user profile as opposed to a GPO change, I thought I should have one place where in I can put the info I find.

Setting the wallpaper

Via this forum post.

Bear in mind this works like a preference not a policy. Users will be able to change the theme and wallpaper. That’s not what I want, so I won’t be using this – but it’s good info to have handy.

Setting IE proxy settings

By default Windows has per user proxy settings. But it is possible to set a registry key so the proxy settings are per machine.

Setting the color scheme in Server 2012

Via Server Fault: two registry values at HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM.

I’ve linked to this earlier, but this seems to be a good place to link to again: changing the start menu colors and background solid colors etc.

Drive Mappings

Look under HKCU\Network.

Environment Variables

Look under HKCU\Environment.

Changing the location of the default profile

Go to HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CurrentVersion\ProfileList and change the value of Default.

Removing the list of newly installed apps

Via this blog post:

Go to HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced and add a value called Start_NotifyNewApps of data 0 and type DWORD.

I am feeling less enthusiastic about replacing GPPs with a default use profile. I like the idea and it’s fast but the problem is that I can imagine users making changes and hence their profiles not being consistent with others. At least with GPPs I know there’s a baseline I can expect as the registry keys I expect will be present in the user profile; but with a default profile I have no such guarantee. If a user goes on and deletes one of my default registry keys, it won’t come back on next login unless I delete the profile.

Started thinking of mandatory profiles and came across this XenApp best practices post from Citrix. Probably wont go that route either but it’s good to keep in mind.

Importing Registry keys via GPP. Also, item-level targeting.

I wanted to do two things. 1) Import a bunch of registry keys for all users. And 2) Set some key values differently for users depending on their location.

Basically these were registry keys containing the details of all our WorkSite databases and I wanted to enable Auto Login to the local WorkSite DMS of each user. So basically import all the registry keys, and if a user’s location is XYZ (preferably identified via an LDAP query to the l attribute) set the DMS of that site to be AutoLogin.

Found this helpful post on how to export a registry key and convert it into an XML file you can copy paste in Group Policy Preferences. Damn! Nice one.

Next I created a copy of the key in question, set it to a higher number in the order (that happens by default when you do a copy) (we need it to be a higher number so that it overrides the other copy of that same key), and in its properties I enabled item-level targeting based on LDAP. Used a query like this: (&(objectClass=User)(sAMAccountName=%USERNAME%)(l=Dubai))

Some screenshots:

Here are the two keys I mentioned. The second one (with a higher order, 9) is set to a different value. The one with higher order will over-ride the one with lower order.

UPDATE: I was wrong. The lower number has higher precedence, so my screenshot above is wrong. I have hence swapped the order. The order is similar to that of GPOs. Lower number wins.

UPDATE 2: Maybe I wasn’t wrong after all. :) Even with the precedence change this didn’t work. I didn’t troubleshoot more (I suck, I know) – instead I just split these into separate GPOs. One to apply all the default settings, and one with higher precedence but scoped to the group I want to apply the different setting to. That did the trick.

I have set the higher order value to target specific users only though.

In this case, if the query searches for an User class object of matching login name and city (the l attribute) set to either Dubai or Abu Dhabi (the two offices for whom I want this key to be different).

[Aside] Using GPP Item-Level targeting to set environment variables based on AD attributes

The subject says it all. Wanted to do this, found the following. Excellent!

Unrelated, but I was Googling on this and I want to put the links somewhere –

Msiexec /fu {ProductCode} : repairs all user-specific registry settings

Msiexec /fup {ProductCode}: repairs all user-specific registry settings and reinstalls missing files