As I see it, Group Policy Preferences is a lot like sushi: You either love it, or you've never truly experienced it.
To use them or see them you need to make a click on Font Settings link available on the left part of the Fonts window. The following Font settings window will have an option called Hide font based on language settings in the Font Settings section. Now enter the value name for the font this is its name and if its an open type or true type to do this open the font and confirm. Click OK; Now either Test or deploy the font.
GPPs aren't new. They've been around since the release of Windows Server 2008. But, oddly, still today I don't find them in widespread use. In and among other reasons, GPPs were introduced to Group Policy to overcome a fairly significant hurdle: While using existing Group Policy settings is a relatively easy process; creating your own custom Group Policy settings isn't.
If the configuration you need to enforce with Group Policy is something that's already built-in, the process requires creating a Group Policy Object, enabling the setting, and adding any setting-specific configuration that's required. Apply the GPO to an OU and you're done. On the other hand, enforcing custom Group Policy settings requires hand-coding your own ADM or ADMX file. If you don't know the ADM secret language or aren't comfortable with ADMX's XML roots, you've got a big problem.
While Group Policy Preferences is able to configure all sorts of different settings, there's one in particular that comes in handy for my uses all the time. That use is in setting and enforcing specific registry values for the different applications on my network. With it, I can automatically tick a checkbox or set a value in my applications on behalf of my users. Gone are all those awful How to Setup Application XYZ documents that my users summarily ignored.
Also gone are most of the help desk calls that invariably result when they don't follow directions.
Standardization, Outlook Style
One such setting that became necessary very recently was the need to standardize on a common Outlook email experience. After years of dealing with inconsistencies in how emails looked from different users, our company decided to enforce a specific typeface, font size, and color for every corporate email.
Figure 1: Signatures and Stationary
It's a legitimate request. Some people's 'creativity' just doesn't exude corporate professionalism. Problem is that telling people to conform their settings in Outlook 2010's Signatures and Stationary control panel (seen in Figure 1 above) is a far cry from them actually doing it.
You probably know that you can get to that control panel by navigating to File | Options | Mail, and then clicking Stationary and Fonts. What you might not know is that any settings here are actually stored in the registry, specifically in each user's HKEY_CURRENT_USER hive. For Outlook 2010, the exact path is HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonMailSettings. Depending on what you've set in Signatures and Stationary, you'll see different keys and values inside this location.
Here's where Group Policy Preferences gets ridiculously powerful. Traditionally, making changes to user settings in HKCU has been nightmarishly difficult because these settings are only loaded when the user logs in. A GPP who's User Configuration is enabled, however, also executes when that user logs in. That means no matter where they are, they're going to get your enforced setting.
Even better, because GPPs are designed to configure custom settings, you can point that GPP in the Group Policy Management Editor at the registry of an already-configured user and use their settings as the template for setting and enforcing everyone else.
Outlook 2010 Enforcement, the Easy Way
Here's how to solve this otherwise nasty problem. Find yourself a computer with Outlook 2010 installed and navigate to the Signatures and Stationary control panel you see in Figure 1. There, configure whatever settings you need to enforce. I'll set mine to the Compass theme. I also miss the good old days when Times New Roman was king of fonts, so I'll set that as the font for Composing and reading plain text messages.
Figure 2: MailSettings
After clicking OK, bring up the registry editor (regedit.exe) and navigate to HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0CommonMailSettings on that same computer. You'll see something similar to Figure 2, although the values in your data column will probably be slightly different.
Figure 3: Edit Binary Value
What you're seeing are hexadecimal values that correspond with the settings you just selected in the interface. Double-click TextFontComplex and you'll bring up a window called Edit Binary Value (see Figure 3). That windows shows how the hex values map to a set of plaintext characters. Luckily you don't have to worry about the exact data here. You've asked Outlook to create this data when you configured the setting in Outlook's GUI interface.
Figure 4: New Registry Properties
It's at this point where GPPs get really exciting. Launch the Group Policy Management Console and create and edit a new GPO. Navigate to User Configuration | Preferences | Windows Settings | Registry and right-click to create a New Registry Item. You'll see a screen similar to Figure 4. Click the button with the three '' dots to launch the Registry Item Browser. This little tool is freakishly cool.
Figure 5: Registry Item Browser
Inside it you can navigate down the registry tree to the same location in HKEY_CURRENT_USER. There, as you can see in Figure 5, you'll find Outlook's settings along with all that nasty hexadecimal data that you configured in the GUI. Highlight one of the items and click Select.
Figure 6: New Registry Properties (with values)
You should return back to the New Registry Properties screen, but this time all the values are already filled out for you. At this point you can click OK and repeat this process for each registry key you want to configure and enforce. In this case, that might be the keys for NewTheme, TextFontComplex, and TextFontSimple, but yours can really be anything. Finish up, close the Group Policy Management Editor, link the GPO to an OU full of users to configure, and your job is complete.
'but what about Computers without Outlook?
An excellent question, one that's kind of solved in Figure 6's Common tab. Bring back up that screen and view the Common tab. There, check the box next to Item-level targeting and click the Targeting button. What results is a new control panel called the Targeting Editor.
The job of this Targeting Editor is to limit the application of a Group Policy Preference. In it you can add one or more custom items that must be fulfilled if the GPP's setting is to be applied to the computer that user is logging into. In our case, we don't want this setting to apply when Outlook isn't present on the computer. Doing so would have no effect. Worse, it would muddy up the computer's registry, adding a setting where no setting should exist.
Figure 7: Targeting Editor
To resolve this, click to create a New Item called File Match and configure it to apply the GPP when Outlook's OUTLOOK.EXE file is found in C:Program Files (x86)Microsoft OfficeOffice14. If you want to get really creative, you can limit it further to apply only when the Outlook it finds is actually Outlook 2010. That version will be somewhere between version 14 and 15, which is information you can learn by viewing the properties of OUTLOOK.EXE and checking out the Details tab.
What you see with this Targeting Editor is pretty much what you get with limiting configurations. This tool is great when your configurations are fairly broad in scope. If you need more fine-tuned targeting control, such as delivering different settings to different people, you might look elsewhere to third party solutions that add more granular control.
Notwithstanding, GPPs are indeed your friend. Or, at least they should be. Now go use them to their fullest potential. And while you're at it, think about giving that raw fish a try. You might just find something unexpectedly wonderful.
I’ve been sorting through our group policies and rewriting them ready for a switch over to Windows 7. During my thorough investigation it turns out our current policies overlap a fair bit, and it’s no wonder we have trouble tracking down why something we’re sure we’ve set in GP turns up unset on logon1 .
So my big project has been going through our settings one by one, and deciding which of these categories they fall into:
- Common Computer settings - all the computers should get these as they are vital to the function of the network, or are likely to break something if they aren’t explicitly set for our staff and students.
- Common User settings - everything else that just can’t be set in the Computer policy.
- Staff Settings
- Student Settings
- Printers
The interesting trick I’ve learned about the printer GPs though is how to apply printers based on the computer’s OU without using local loopback!
The Problem
The problem with managing printers in a school environment is that unlike corporations (which GP is clearly geared towards) people move around all the time but want to be connected to both their printers in their offices on the other side of the school, but also the local printer in the classroom they’re in2. Microsoft decided that without any extra tricks they would let you set a default printer for a user, but not for a room because Betty from HR will only ever use the one computer in her office.
The Old Trick
Then they told people you could get around this by enabling local loopback, which applies both computer and user policies to a user, so you could set the printer as default in a computer policy using the “user” section, then make the computer read the computer section at logon and apply the printer. The problem with this3 is that it could slow down your logins, as it increases the number of policies it has to read and evaluate to prepare the desktop.
The New Way
In my quest to eliminate unnecessary policies, I wanted to kill local-loopback too. A bit of research turned up this page on using GP Preferences to assign default printers, which I already knew and was using, but it advocated using local-loopback.
![Fonts Fonts](http://www.itingredients.com/wp-content/uploads/2015/07/Group-Policy-Management-Editor.png)
But
Further down that page was a comment by Michael Moore who had this bit of advice:
Actually, if you Item Level target a group which has a computer in it, it will still install the printer even though these preferences are under the User Configuration Section of the GPO. Try it, saved on loopback. – Michael Moore
So I followed the directions on that site (it has helpful screenshots) to create a printer policy and target specific computer OUs, but then instead of turning on local-loopback, I simply ticked Run in logged-on user’s security context (user policy option).
Now my printers deploy and are set as default based on the current computer’s OU without using local-loopback at all.
- This is going to get more technical than usual. Regular readers can tune out… Now ↩
- they also want the computer to magically know which one they want to print to by default each time it changes, but that’s another story ↩
- anecdotally at least, I can’t find hard evidence ↩