An old colleague of mine, Alan Burchill, has started a new blog dedicated to Group Policy – Group Policy Center. He’s started to get some great content up there and I expect much more to come.

Alan has an excellent set of posts covering Group Policy Setting of the Week, although at that rate I calculate that it’s going to take 59 years to get through the current set of policies. . If Group Policy is your thing, add his feed to your reader here.

New Group Policy Blog – Group Policy Center is post from stealthpuppy.com. Except as noted otherwise, this work is ©2005-2010 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Here’s a great document from the Microsoft writing team on planning and deploying Group Policy for Windows Server 2008. Many of the details in this document do apply to Windows Server 2003 and Windows 2000 Server as well. This document is the place to start for anyone dealing with Group Policy, no matter what your experience is.

This guide provides the information needed to successfully plan and deploy Group Policy using Windows Server 2008 and the Group Policy Management Console.

Planning and Deploying Group Policy

This document reinforces a number of Group Policy design tenets that I see ignored in many organisations, especially this one:

Use the Enforced and Block Policy Inheritance features sparingly. Routine use of these features can make it difficult to troubleshoot policy because it is not immediately clear to administrators of other GPOs why certain policy settings do or do not apply.

and this one that I see far too often:

If you need to modify the policy settings contained in the Default Domain Policy GPO, we recommend that you create a new GPO for this purpose, link it to the domain, and set the Enforce option. In general, do not modify the Default Domain Policy GPO or the Default Domain Controller Policy GPO. If you do, be sure to back up these and any other GPOs in your network by using the GPMC to ensure that you can restore them

Here’s a fun fact: did you know that Windows will not process more than 999 Group Policy objects? That’s a lot of coffee while you wait for youR machine to boot to the desktop!

A maximum of 999 GPOs is supported for processing GPOs on any one user or computer. If you exceed the maximum, no GPOs will be processed. This limitation affects only the number of GPOs that can be applied at the same time; it does not affect the number of GPOs you can create and store in a domain.

Here’s a link to plenty more Group Policy resources on the Microsoft Download centre.

Planning and Deploying Group Policy? This Is For You is post from stealthpuppy.com. Except as noted otherwise, this work is ©2005-2010 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

If you are working with PolicyMaker Registry Extension, or any of the other PolicyMaker products, you will find the Microsoft Management Console will crash when you select the User Settings / Registry node when editing the Group Policy on machine that also has Internet Explorer 7 installed. If you look at the crash details you will see that the fault is with MSHTML.DLL.

Fortunately there is a work around until the next version of PolicyMaker is released to address the issue. The DesktopStandard knowledgebase has details on the issue and the workaround:

SYMPTOMS:
When PolicyMaker is installed on a computer with Internet Explorer 7 also installed, attempting to configure PolicyMaker items in the GPMC results in the following error message:

Event ID: 1000 Faulting application mmc.exe, version 5.1.600.2180, faulting module mshtml.dll, version 7.0.5730.11,
fault address 0x00156e17

RESOLUTION:
This will be fixed in the next release of PolicyMaker products.

As a workaround, Internet Explorer 7 should be uninstalled, or the PolicyMaker snapin should be installed on a computer that does not have Internet Explorer 7 installed. Alternatively, you can disable the PolicyMaker extended view tab in the MMC. This prevents the errors and still allows you to edit PolicyMaker items.

Simply rename the following Registry keys:

HKEY_CLASSES_ROOT\CLSID\{45B01F1C-5AC2-458C-9457-42A81B34A26D}
HKEY_CLASSES_ROOT\CLSID\{{A8EEA101-3610-4D97-A8AE-E88E50DD5488}
HKEY_CLASSES_ROOT\CLSID\{{6EA87A55-745F-4c28-8DDC-B679A68E3E01}

The easiest thing to do is add a dash to the end of the key name, so it will be disabled, but you can easily find it to re-enable it later. Note that you may not have all three of these keys, if you don’t have all of our products installed. Just rename the ones that you have.

PolicyMaker and Internet Explorer 7 is post from stealthpuppy.com. Except as noted otherwise, this work is ©2005-2010 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

The ADM/ADMX templates have been updated and include the fix for the Outlook template. See the download link below to update your templates.

When adding the Outlook 2007 ADM template file, OUTLK12.ADM, to a Group Policy object, you may encounter the following error displayed when you view a settings report in the GPMC:

The .adm file “\\company.local\SysVol\clariti.internal\Policies\{C08857CE-A103-456A-8D3D-0A4F869B8C4A}\Adm\outlk12.adm” is in not in a valid format and must be replaced. Details: A value name is expected before line 2461.

To fix this issue follow these steps:

1. Make a copy of OUTLK12.ADM, e.g. OUTLK12-Fixed.ADM

2. Open OUTLK12-Fixed.ADM in Notepad and go to line 2461 (Edit / Go To..)

3. This line should be in a section that looks like this, starting at line 2459 and ending at 2464:

KEYNAME Software\Policies\Microsoft\Office\12.0\Outlook\Security
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
VALUENAME PromoteErrorsAsWarnings
EXPLAIN !!L_PromotingerrorsaswarningsExplain
END POLICY

4. Swap the text on line 2460 with the text on line 2462, so that is now looks like this:

KEYNAME Software\Policies\Microsoft\Office\12.0\Outlook\Security
VALUENAME PromoteErrorsAsWarnings
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
EXPLAIN !!L_PromotingerrorsaswarningsExplain
END POLICY

5. Save the template and add it back into your Group Policy object and it should now work.

It’s a little odd that this problem is there right out of the box but I don’t know if anyone else is experiencing this issue. You can get the Office 2007 ADM files from here:

2007 Office System Administrative Templates

This download includes updated Group Policy Administrative Template files and Office Customization Tool OPA files for use with the 2007 Microsoft Office system programs. It also includes an \Admin folder with an updated Office Customization Tool, and ADMX and ADML versions of the 2007 Microsoft Office system Administrative Template files for Windows Vista and Windows Server 2008. In Windows Vista and Windows Server 2008 operating systems, the ADM files are replaced by ADMX files, which use an XML-based file format to display registry-based policy settings. This download also includes a workbook (Office2007GroupPolicyAndOCTSettings.xls) that provides information about the 2007 Office system Group Policy settings and OPA settings.

Error with OUTLK12.ADM is post from stealthpuppy.com. Except as noted otherwise, this work is ©2005-2010 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

In This Series: Office 2007 Deployment

1. Office 2007 Deployment via Group Policy
2. Deploying Office 2007 with Group Policy Startup Scripts
3. Installing Office 2007 on Terminal Server
4. Set Default Formats for New Office Documents from Windows Explorer
5. Disable Office User Interface Elements

If you are looking at deploying Office 2007 via Group Policy you may have noticed that Microsoft have changed the game. Office 2007 is no longer deployed using transform files; it now uses Windows Installer patches (.MSP) or CONFIG.XML to customise the Office installation.

When you deploy any of the Office 2007 applications, you can add MSP files to the \Updates folder and they will be installed automatically by Office setup. This simplifies updating Office by ensuring updated machines can still use the original network sources files but means that administrative installations are no longer available The change to MSP files for customising Office has implications for deployment – you can’t add an MSP file to an application in the Group Policy object.

Microsoft has recently added a document on TechNet that describes what you’ll need to do to deploy Office 2007 via Group Policy. In this document they give details why software deployment via Group Policy is not scalable for larger customers:

• Unable to schedule installations and controlling bandwidth.
• Limited scalability for concurrent deployment more than 200 concurrent installs could cause issues.

These types of limitations are well known to anyone who has deployed applications via Group Policy, but here’s a few more that are Office 2007 specific:

• MSP files added to the \Updates folder are not installed when deploying Office via Group Policy. This is obviously a big hurdle and Microsoft doesn’t give any reason for this behaviour.
• Office 2007 cannot be advertised or assigned to users. Given that Office is licensed per device, I don’t see the issue with this.
• Challenging to maintain/update. WSUS is a pretty good solution for most customers so again I don’t see the issue here.

The changes Microsoft have made to the Office 2007 Setup routine appear to be aimed at making Office 2007 easier to deploy and maintain for larger customers who generally have tools like SMS for application deployment. So what options do organisations that rely on Group Policy for application deployment have? Here’s the lowdown:

1. Customise CONFIG.XML and deploy Office by adding the MSI file to a Group Policy object.
2. Create an MSP or customise CONFIG.XML and deploy Office via a Group Policy Startup script.

If you want to use the first option you will need to make a copy of Office for each separate installation type e.g. installing Access on some computers but not others. This could require higher maintenance and as using CONFIG.XML is a limited option compared to MSP files, who really wants to use the limited option when there is a nice Office Customisation Tool GUI available?

This leaves you with deploying Office 2007 via a MSP files and a Startup script and I think this will give you the most options. To install via a script use SETUP /ADMINFILE adminfile.MSP to install Office with the customisations you require (run SETUP /? to see a fill list of command line options). Microsoft have a page on using Startup scripts, Use Group Policy to Assign Startup Scripts for 2007 Office Deployment, however this page is not available at the moment.

So there we have it the way you used to deploy Office no longer works and you’ll have to do some preparation when it comes to Office 2007. Make sure you check out the page on TechNet for more details.

Office 2007 Deployment via Group Policy is post from stealthpuppy.com. Except as noted otherwise, this work is ©2005-2010 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

If you are starting to deploy Windows Vista you may have noticed that any user who has administrative access to their workstation will not receive mapped drives or printers. This is due to the new privilege model introduced in Windows Vista with User Account Control.

Microsoft has a complete explanation of why this behaviour with Group Policy scripts occurs at the TechNet site – Deploying Group Policy Using Windows Vista. Just over half way down the page you’ll find a section titled ‘Group Policy Scripts can fail due to User Account Control‘, however here’s a quote from that page that summarises the issue:

When the administrative user logs on, Windows processes the logon scripts using the elevated token. The script actually works and maps the drive. However, Windows blocks the view of the mapped network drives because the desktop uses the limited token while the drives were mapped using the elevated token.

So what do we do to get around this? There are a few different methods:

1. Don’t add users to the local Administrators group on the workstation
2. Detect Windows Vista and create a scheduled task to run a logon script via Task Scheduler
3. Disable User Account Control

My first recommendation, don’t add users to the local Administrators group, is the best way forward. By not adding users to the local Administrators group, the user will never have an administrative token and the logon script runs at the same elevation level as Windows Explorer. This way you don’t need to make any script changes and you are in the best position for protecting your machines against malware.

If this method is not for you, then you will have to follow the instructions listed in the Deploying Group Policy Using Windows Vista article and run a logon script using the task scheduler. To do this you will have to detect the presence of Windows Vista and then use LaunchApp.WSF to create a scheduled task to run the actual logon script.

I think the easiest way is to use a WMI Filter to ensure a Group Policy runs only on Windows Vista. This will require two separate Group Policy objects – one GPO used for Windows Server 2003 and below and another for Windows Vista and above. The WMI Filters would then look like this:

Windows Server 2003 and below:

Select * from Win32_OperatingSystem where BuildNumber < "6000"

Windows Vista and above:

Select * from Win32_OperatingSystem where BuildNumber >= "6000"

Another method would be to detect the operating system version as a part of a script and then launch specific logon scripts depending on what operating system is detected. Here’s a VBscript that will do this for you (the original source for this script came from here):

Dim wshShell
Set wshShell = CreateObject("WScript.Shell")
If IsVista Then
	runVistaStyle
Else
	runNormalStyle
End If

Sub runVistaStyle()
	wshShell.Run("cscript [path_to_launchapp.wsf] [path_to_userlogin_script]")
End Sub

Sub runNormalStyle()
	wshShell.Run("[path_to_userlogin_script]")
End Sub

Function IsVista()
	strComputer = "."
	Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
	Set colOSes = objWMIService.ExecQuery("Select * from Win32_OperatingSystem")
	For Each objOS in colOSes
		BuildNumber = objOS.BuildNumber
	Next
	If BuildNumber >= 6000 Then
		IsVista = True
	Else
		IsVista = False
	End If
End Function

Lastly you have the option to disable User Account Control completely; however I do not recommend this at all and as it’s a topic all of it’s own, I’m not going into the how or why of this option here.

UPDATE: Josh points out you can add the following key to the registry as a work around, however it is not supported by Microsoft:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections = 1 (DWord)

I still recommend your best option is not to make users administrators of their machines.

Group Policy Scripts can fail due to UAC is post from stealthpuppy.com. Except as noted otherwise, this work is ©2005-2010 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Microsoft have pulled the PolicyMaker Regsitry Extension download. This product is part of what is now known as Group Policy Preferences, a new feature of Windows Server 2008 and 2008 R2.

If you are still writing custom ADM templates for your application deployments and haven’t heard of DesktopStandard PolicyMaker Registry Extension, then it’s definitely something you should be looking at. It reduces the need to create time consuming ADM templates and offers much more over non-managed policies.

Microsoft purchased DesktopStandard last year and PolicyMaker Registry Extension is one of the Group Policy products acquired as a part of the purchase. Along with PolicyMaker Standard Edition and Share Manager, Registry Extension will be rolled into the core Group Policy feature set in the future, which is really good news. Until then, Registry Extension is still available for download from the DesktopStandard web site. So what does it actually do? Let’s take a quick look:

Historically, because application developers haven’t written ADM templates for their applications themselves, we’ve had to create custom ADM templates to use Group Policy to enforce registry settings. There are even a few 3^rd party tools available that make the job of custom ADM templates easier. PolicyMaker Registry Extension, however, extends Group Policy to make implementing custom registry settings a far more simple process.

Use of Registry Extension requires the deployment of agent software to each machine that will be managed. This is simple though and only requires installation of the software which you can do via Group Policy. There are no custom settings required, just add the MSI to a network share and deploy via a GPO. The software weighs in at 8.5Mb, so deployment should be fairly straight-forward. I’ve also created a transform that you can use to disable the shortcut added to the Start Menu by the installer. Check the bottom of this article for the download.

You can use Registry Extension to create, replace, update and delete registry settings from any location in the registry. Once you have installed the extension you will see additional registry options available to you in any GPO (including the local Group Policy). Within each of these items you can create registry keys and collections of registry keys as well is import a set of registry keys using a wizard:

Adding a registry key is very simple – you can manually specify a registry key and value or you can import directly from the current machine unfortunately there is no way to import settings from a file. You can though, copy items directly between Group Policy Objects.

What makes Registry Extension compelling are the extra features it packs because it includes a client side agent:

• Treating settings as a preference – rather than enforce settings it will only touch the registry key once;
• Removes settings when they no longer apply, just like managed settings – no more tattooing the registry;
• You can apply filters to settings so that action is only taken if the filter is matched.

Filters add a lot of flexibility to your application of registry settings and as you see from this screenshot there are 29 items to filter on. You can also build filter queries using the AND/OR operators.

PolicyMaker Registry Extension is a great fit for any Windows network and while you might miss out on the portability of ADM templates, it is far more flexible and dynamic than ADM templates, thus giving you more choice and saving you time.

Here’s a link to the Registry Extension download (try a search if this download is missing)

Transform to disable the Start Menu shortcut

Why Are You Still Writing ADM Templates? is post from stealthpuppy.com. Except as noted otherwise, this work is ©2005-2010 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Here’s an interesting new feature of Windows Vista that will be a help to shared computing environments such as public libraries or those still inflicted with Windows NT 4.0 domains – Multiple Local Group Policy.

In environments where Windows is installed and not connected to a domain, locking down the user interface with Group Policy has been a challenge because local Group Policy applies to all users including Administrators. Windows Vista and Longhorn Server now allow the administrator to create multiple local Group Policy objects that can be applied to specific users or groups. It’s a simple process:

1. Open the Microsoft Management Console by running MMC.EXE
2. In the Console1 window, click File, and then click Add/Remove Snap-in.
3. In the Add/Remove Snap-in dialog box, in the Available snap-ins list, click Group Policy Object Editor, and then click Add.
4. In the Select Group Policy Object dialog box, ensure Local computer appears under Group Policy Object. Click Finish. This will add a standard local Group Policy object that will apply to the computer and all local users.
5. To add a second local GPO to apply to non-Administrators, click Group Policy Object Editor under the Available standalone snap-ins list and then click Add.
6. In the Select Group Policy Object dialog box, click Browse. Click the Users tab. Click the Non-Administrators group. Click OK. Click Finish.

It’s a simple as that. Now you can apply policies to non-Administrators without affecting administrator accounts on the machine. For a full step by step guide and discussion on this feature check out the following document from Microsoft:

Step-by-Step Guide to Managing Multiple Local Group Policy

Windows Vista 101: Multiple Local Group Policy is post from stealthpuppy.com. Except as noted otherwise, this work is ©2005-2010 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.