Group Policy Preferences

Microsoft Word – Show all formatting marks

Posted on by Adam Fowler

Microsoft Word 2016 and earlier versions have a handy toggle for ‘Show/Hide paragraph marks and other hidden formatting symbols’. It’s that backwards P looking thing in the Word ribbon:

… but also choosable from Word’s options under the Display section, called ‘Show all formatting marks’:

By default, this option is off. I had a business requirement to have it on by default, which proved harder to work out than I thought.

Normally for Word and Office, a user option is controlled by the registry. Procmon is great for capturing those changes, but I couldn’t see anything when toggling this option.

Jeremy Moskowitz from PolicyPak gave me a hint on finding the solution on this one; Word sets some of it’s user settings at the time of closing Word, rather than changing an option and pressing ‘OK’.

Once I knew that, the setting was easy to find.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Word\Options

DWORD Value - ShowAllFormatting

1 - Enabled / On

0 - Disabled / Off

Word will read this setting at startup, and write to it at shutdown based on what the setting was last set to.

Using Group Policy Preferences and setting the option ‘Apply once and do not reapply’ to push out the registry setting will make it the default, but let users change it as they please.

Group Policy Preferences – Replace Existing File

Posted on by Adam Fowler

I’ve written before on how great Group Policy Preferences are, and thought I’d write a quick ‘how to’ on a likely common scenario – replacing an older file with a new one, but only if it already exists.

Pushing out a file via Group Policy Preferences is quite easy and has been around for a long time.

When creating a new file rule, you’ll see 4 options under ‘Action’ – Create, Replace, Update and Delete:

gpp2

Create will only copy the file from the source to the destination if the file doesn’t exist at the destination
Replace will actually remove a file (if one exists), and copy the source to the destination regardless if a file existed or not
Update is the misleading one, it will modify the file attributes of the destination file to match the source – if the files themselves are different, it won’t copy them. If the file doesn’t exist, it will copy the file to the destination though!
Delete will delete the file(s) specified.

None of these provide a solution to ‘Replace file only if it exists’ though. There’s two obvious ways this can be achieved; you can use ‘Replace’ but this will continually replace the file every time Group Policy is run, which in the user context is every 90 minutes. You also can’t use the option ‘Apply once and do not reapply’ because it will run regardless of the file existing or not – which means if the file isn’t there before group policy runs, the file may be replaced by a software install or other mechanism, and with the order out of whack, resulting in the wrong file being left there in the end.

The next logical way to make sure the order is correct is to use Item Level Targeting. Under the ‘Common’ tab, you can tick the box for ‘Item Level Targeting’ and point to the file in question:

gpp3

This will only run once though, and that is regardless of the ‘Item Level Targeting’ being true or false. That only controls whether the policy does what it’s configured to do, at the client side it’s still ‘run’ the policy, it just had nothing to do.

thommck had the best answer on how to get around this that I’ve found – use a custom WMI query. You’ll need to remove the ‘Apply once and do not reapply’ tick, but the file itself will only be copied over when both targeting rules are true. Please read his post for all the details, but the second item will need to be a WMI query, and have a string similar to this:

SELECT LastModified FROM CIM_DataFile WHERE name=”C:\\windows\regedit.exe” AND LastModified < ‘20160701000000.000000+060’

This is checking the date of the file, and will only be ‘true’ if it’s less than that date.

Keep in mind that this is less than ideal, as WMI queries aren’t the most efficient way of processing group policy preferences, but it may be better than copying files around your network to every PC, every 90 minutes.

How To Apply HKLM Settings Per User

Posted on by Adam Fowler

Normally when you think of Windows Registry, you’re normally worried about the two sections: HKEY_LOCAL_MACHINE (HKLM) and HKEY_CURRENT_USER (HKCU).

It’s fairly obvious that settings under each area apply to either the PC itself (machine) or just to the currently logged in user. This is usually fine, but there are scenarios where there’s a setting that will only apply to a machine due to how the program is written, but you actually want to turn it on or off based on the logged on user.

With Group Policy Preferences (GPP) which was introduced with Windows Server 2008, this is much easier to do. Before this, you would have need to have written complex logon scripts using 3rd party tools to perform lookup commands, create variables and then adjust the registry accordingly, while providing administrator credentials.

GPP lets you apply registry settings rather easily. One of the main benefits of GPP is how flexible and granular you can be with the settings you apply.

This is how I would normally use to deploy a setting, but have it easily managable: Have two settings for the registry, one setting it on and the other off (normally done by a 1 for on, 0 for off but it depends on the setting). The targeting for having the setting on or off is based by user membership to an Active Directory (AD) group, but the setting is not applied in the user context meaning it’s applied by ‘System’ which will have full access to the HKLM registry.

This will then mean the HKLM setting changes from 0 to 1 and back based on which user logs in!

I prefer this than just applying particular users individually to the item because it will reduce processing time having a single check vs many, and that anyone can easily manage an AD group rather than mucking about with Group Policy and potentially doing something wrong, affecting the entire user base.

How to create a Group Policy that applies HKLM settings per user:

First, create a Policy. I’m going to assume you’re able to open Group Policy Management and create a Group Policy Object (GPO).

We’ll be working under User Configuration > Preferences > Windows Settings > Registry.

Here’s what you should see without my registry item already created:gpp1

Right click in the big open white space and choose New > Registry Item. Fill in the General tab for the registry item you want to create. Here’s an example:

gpp3

Next, go to the Common tab and tick ‘Item Level Targeting’. Then click the ‘Targeting’ button and you’ll be taken to the Targeting Editor. This is where all the granular control is, and you’ll find many options on what criteria needs to be met to either apply, or not apply the registry item.

You can define what you like for the rules, but I’ll be doing ‘the user is a member of the security group’. You can click the ellipsis … button and find your group in Active Directory (or quickly go there to create it first).

gpp2

After you’ve done this then pressed ‘OK’ twice, you’ll have your first registry entry ready to apply. We need a second one to do set the registry setting to a different value if a user is NOT in the group, so right click on the registry item and choose ‘copy’ then right click on the blank area and choose ‘paste’.

Go into the properties of your copied item, and change the value data to the second setting, and go into the ‘Targeting’ area and change the rule to ‘Is Not’ rather than ‘Is’ under the ‘Item Options’ dropdown menu.

One note is that AD group membership is checked when the user logs in, so if you’re testing and running ‘gpupdate’ to force a group policy check, it may not work as it won’t realise the user is in or out of the group. Just log off and back on to test instead.

I am a big fan of Group Policy Preferences and this is one of the examples of how powerful it can be, so if you are not already using it – get started!

Group Policy Preferences – What Takes Preference?

Posted on by Adam Fowler
How do you know if one Group Policy Preference occurs before another?

Hi again everyone,

Today I’m sharing something that I have just found out about, thanks to the very helpful Alan Burchill (Twitter) who is a MVP in Group Policy. Thanks Alan!

So, I’ve talked about Group Policy Preferences before – wonderful, and not widely used enough yet – but they’ll do pretty much anything you could do with a login script with the added benefits of high granularity, GUID and targeting based on almost any criteria you can think of rather than writing complex scripts and error reporting in event viewer.

I came into a scenario where I needed to delete all of the files in a directory, then copy several files back into that same directory. As I created this, I then wondered how I’d make sure that the delete occured before the copy. If it happened the other way around, the end result would be an empty directory!

If you’re doing multiple settings of the same type, then they get an Order number as per the screenshot below. You can move the order around, to make sure things occur in their proper turn. Something like environmnet variables may need this, since your second variable may use the first variable as part of it’s path, and if it was the wrong order then you wouldn’t have the first environment variable set before it was called:

gppenv

Simple enough. But, what if you need an environment variable in place before you map a drive using that variable? The next screenshot is from the same policy, using one of the variables above to map a drive. But, if you look at the order number, it’s also a 1. The order is only relevant for items in that same area (as per this example, Drive Maps).

 gppdrive

 

 

How do you know what will happen first? This is what Alan Burchill found out for me. There is a set order in which each client side extension runs, and to view this you need to delve into the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions

 

gppreg

The order is based on the GUID. I’ve highlighted the second one, which is Group Policy Environment – the environment variables. They’re all self explanatory once you click on them, or you can search what you’re looking for and then ensure that they are in the order you need them to be. There’s one exception to this, which is {35378EAC-683F-11D2-A89A-00C04FBBCFA2} but that’s a blank entry… possibly so you can force something to be first if needed? We’re not quite sure on that bit!

I hope that helps you if you ever run into this sort of thing. There are other workarounds you can do, such as creating two seperate GPO’s and put those GPO’s in the correct order, but best practise is to have as few GPO’s as possible.Anyway, for my example above, the environment variables come before drive mappings which is {5794DAFD-BE60-433f-88A2-1A31939AC01F} so we’re safe.