Tag Archives: group policy

Practical tips on simplifying GPOs and OU organization

Practical tips on simplifying GPOs and OU organization

Summary: Deep paths within Active Directory can complicate Organizational Units and Group Policy Objects organization. IT pro Rick Vanover shares his approach to managing the complexity of GPOs.

One of the most powerful centralized administration tasks for Windows Servers and PCs is deploying Group Policy Objects (GPOs). So much so, in fact, that I could argue Group Policy is one of the best solutions Microsoft has ever provided.

While I’m very fond of GPOs and their flexibility to configure user and computer settings centrally, we can easily get out of control with conflicting rules and overly complicated implementations. I’m sure we’ve all seen a domain that has a very ugly configuration of GPOs, and let’s not even get started on the security groups.

In my Active Directory practice, I go back and forth in determining how deep the GPOs and Organizational Units (OUs) should go. I frequently don’t do more than three GPOs flowing in series with the OUs.

By series I mean one GPO in a parent OU and another GPO in a child OU, like Figure A where the green GPO applies to the parent OU and the red GPO applies to the child OU (as well as the green GPO).

Figure A

Click the image to enlarge.

OUs are great for granular classification of various Active Directory objects, though I don’t really have an incredible issue going very deep (within reason) in terms of levels for this configuration. GPOs, on the other hand, are not good candidates for multiple applications for each OU as the tree goes deeper.

It is too complicated to keep the configuration rules in mind for planning and quick thinking. To help simplify how GPOs are organized, here are some tips:

  • Leverage GPO filtering by security group to make more GPOs at a higher OU instead of more GPOs in deeper OUs
  • Never add individual users or computer accounts (always use the group trick above)
  • Combine user and computer settings by role, rather than separate GPOs
  • Self-document the names of the GPOs to be intuitive to the role and location
  • Use a consistent GPO nomenclature, including renaming GPOs to get there
  • Scour around for GPOs that have one setting and consolidate it with other GPOs

GPOs are great, but the tools require organization and thought. These tips are general guidelines, and any of you keeping score will note that my screenshot from my personal lab is not exactly following all of these recommendations. It’s fine for a lab, but in production, that’s a different story.

Rick Vanover is an IT infrastructure manager for a financial services organization in Columbus, Ohio. He has years of IT experience and focuses on virtualization, Windows-based server administration and system hardware.

Also read:

 

Configure server, desktop, laptop power options with Group Policy

Disable Server Manager and Initial Configuration Tasks via Group Policy

Enable remote server management through a GPO

Enable remote server management through a GPO

Summary : Ability to manage servers remotely is critical for ease of administration and reducing the number of open remote desktop connections. Rick Vanover shows how to deploy this configuration centrally.

When I wrote my tip on how to administer Windows Server Core systems remotely, I didn’t give much thought to automating the process.

Maybe I didn’t see myself using the new Server Manager utility as much or possibly was focused too much on possibly using Windows Firewall centrally through Group Policy for all servers on an internal network. However, when I look at my track record, I use remote server management all the time.

Remote server management is a perfect thing to automate centrally with a Group Policy Object (GPO). It’s quite easy to do, though it will go a lot better if you have Windows Firewall set up centrally within Group Policy. I’ve never used Windows Firewall on internal networks; I’ve played with ideas and configurations that may have used it, but I never pushed it out to a bunch of servers with a firewall profile for an internal network.

In most of my recent environments, especially labs, I’ve set Windows Firewall to be disabled via Group Policy. If you have that in place, this will be a rather easy addition.

To enable remote management, you need to run a winrm command. This is the running configuration for Windows Remote Management, and the associated Windows service is installed and running automatically with default installations of Windows Server 2008 R2. For one-off systems, simply running winrm quickconfig will enable remote management. If you want to apply it centrally to a number of computer accounts, a GPO is the way to go.

The command to run via a script, applied to a computer account GPO, is winrm quickconfig -q and can be saved as a PowerShell script, a .bat, or a .cmd file. This script can be run to a computer account, and it doesn’t require a user to log on to execute this script, which makes security provisioning quite easy. The computer script running winrm would go in Computer Configuration | Policies | Windows Settings | Scripts | Startup (Figure A).

Figure A

Click the image to enlarge.

 

Once the computers apply the GPO (usually on the next boot), remote connections from Server Manager are quite easy.

Rick Vanover (MCITP, MCSA, VCP, vExpert) is an IT Infrastructure Manager for a financial services organization in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.

Tips on copying and backing up Group Policy Objects

 

Tips on copying and backing up Group Policy Objects

 

Summary : Group Policy configuration is one of the most powerful aspects of Windows. Read several tips on copying and backing up Group Policy Objects, which can save admins a lot of time.

A cornerstone technology of Windows is Group Policy, which can be assigned locally (a single policy for a Windows system) or managed centrally in an Active Directory domain. When leveraging Active Directory, a number of Group Policy Objects (GPOs) can be assigned to computers and users.

I believe that GPOs are one of the most critical and powerful management tools available; that said, GPOs can also be complicated to work with. For instance, if you need to recreate a GPO, it may require a tedious maneuvering of screens to verify settings from one GPO to another. Fortunately, the Group Policy Management console allows us to do a few things to tackle this task efficiently. The first is a centralized list of GPOs for the entire domain, regardless of the Organizational Unit (OU) where they reside. This panel is shown in Figure A.

Figure A 
 
Click the image to enlarge.

This console serves a number of purposes, but one that irritates me is nomenclature. Figure A is a screenshot of my personal lab, and I have not done a good job in naming the GPOs. Ideally, a GPO is self-documenting so that it tells you: what it does, where it lives, and who it applies to (users, groups, computers, etc.).

Please excuse my lab’s sloppy nomenclature, and let’s focus on the ability to copy and back up a GPO in this console. When we right-click the individual GPO, a very powerful context menu appears. (Note: This menu is not available where the GPO resides in terms of the OUs listed above; it is only available in the Group Policy Objects section.) This context menu is shown in Figure B.

Figure B 
 
Click the image to enlarge.

The copy and backup options are the two tasks that can really save administrators a lot of time. The copy operation will take an existing GPO, and allow you to paste it into the Group Policy Objects section. This may not be intuitive, and Figure C shows where it becomes an option.

Figure C 
 
Click the image to enlarge.

A new GPO is created as a copy of the source GPO, and it can be linked to an OU later. This can be very helpful when a GPO is built over time, but is not ready to be applied to the destination OU.

The ability to back up a GPO exports the GPO to an .XML file, which can be archived and used to recover a previous version of a GPO. There also is an option to back up all GPOs, which will make a large .XML repository in a specified folder path. In both situations, the ability to have the GPOs on outside of the domain controller can be attractive. While backup solutions can protect down to this level, simply for a quick check by hand, the backup options within the Group Policy Management console can be of great aid. Viewing the .XML file isn’t very helpful, but can be an easy way to spot-check settings (Figure D).

Figure D 
 
Click the image to enlarge.

Rick Vanover is an IT infrastructure manager for a financial services organization in Columbus, Ohio. He has years of IT experience and focuses on virtualization, Windows-based server administration and system hardware.

 

How To Manage Active Directory Password Policies in Windows Server 2008/R2 – Redmondmag.com

How To Manage Active Directory Password Policies in Windows Server 2008/R2 — Redmondmag.com.

How To Manage Active Directory Password Policies in Windows Server 2008/R2

So, you think you know how password policies work in Active Directory? Well, you might … or you might not. Find out how to manage Active Directory password policies in Windows Server 2008 and Windows Server 2008 R2.

Some things in life, like death and taxes, are guaranteed. There are other things in life that you think are guaranteed, or at least you think you know how they work — such as Active Directory password policies. Then, there are things that you want to work, and when they come along, you feel you know how they work before you even look at them — such as fine-grained password policies (FGPPs). I’m not going to discuss death and taxes, but I am going to clarify the misconceptions surrounding Active Directory password policies and FGPPs.

With the technology of password policies having existed for more than 10 years now, you’d think this topic would be infinitely clear. However, based on my exposure to network administrators who are still confused about how Active Directory password policies work, that’s not the case.

 

Basic Facts
These basic facts have been the same in Active Directory domains since Windows 2000, which was released 11 years ago:

  • The Default Domain Policy defines the password policies by default for every user in Active Directory and every user located in the local Security Account Manager (SAM) on every server and desktop that joins Active Directory.
  • There can be only one password policy for domain users in a Windows 2000 and Windows Server 2003 Active Directory domain.
  • It’s not possible to configure the password policy for an organizational unit (OU) of users to be different than that of other users in the domain or in a different OU.
  • The password policy settings can’t be extended to include additional settings without using a third-party tool or developing a custom password policy solution.
  • It’s not possible to configure a password policy for the root domain and have it “funnel” down to the other domains in the Active Directory tree.

I still see administrators and organizations try to explain that they have an environment different than what is possible. With that said, I’d encourage all of the admins and organizations that think they have a different configuration for passwords to “test” what they believe. Unless you have a third-party product in place or have Windows Server 2008 native mode domains, you can’t have anything but what I detailed here.

Possible Settings in the Password Policy
When you edit a standard Group Policy Object (GPO) from the Group Policy Management Console (GPMC), you’ll find the same options for the Account Policy. To find the password policy settings, which are under the Account Policy, open up the following path of policy folders: Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies. Once there, you’ll find three policy folders: Password Policy, Account Lockout Policy and Kerberos Policy.

For each of these folders and the settings contained within them, there’s a default in Windows Server 2003, Windows Server 2008 and Windows Server 2008 R2 freshly installed domains. The default settings are as shown in Table 1.

Policy Setting Default Setting Value
Enforce password history 24 days
Maximum password age 42 days
Minimum password age 1 day
Minimum password length 7
Password must meet complexity requirements Enabled
Store passwords using reversible encryption Disabled
Account lockout duration Not defined
Account lockout threshold 0
Reset account lockout counter after Not defined
Enforce user logon restrictions Enabled
Maximum lifetime for service ticket 600 minutes
Maximum lifetime for user ticket 10 days
Maximum lifetime for user ticket renewal 7 hours
Maximum tolerance for computer clock synchronization 5 minutes

Table 1. Account Policy settings default values.

(You can use fine grained password policies. http://technet.microsoft.com/en-us/library/cc770394(v=ws.10).aspx)

In-Depth

How To Manage Active Directory Password Policies in Windows Server 2008/R2

  • 08/03/2011

Limitations of the Password Policy for Domain Users
To ensure you understand what I mean by domain users, let’s scope out where these users reside. Domain users are those users that are created and stored in the Active Directory database. This means all users stored on your domain controllers (DCs) fall under this definition. One easy way to see whom this entails would be to open up the Active Directory Users and Computers (ADUC) and do a search on all users for that domain. Every user that shows up on that search falls into this scope.

The only way to control the password policy for domain users is to configure the aforementioned Account Policy in a GPO linked to the domain. That is the only way by default! Yes, it’s true the GPO that contains the default password policy settings is the Default Domain Policy, but this is just the default. You can easily create a new GPO, configure the Account Policy settings as you wish and ensure this GPO has the highest precedence in the GPMC. The result will be that this new GPO will control the Account Policy settings for all domain users.

Default Password Policies
When you install a new Active Directory domain within Windows Server 2008 or Windows Server 2008 R2, or upgrade a Windows 2000 or Windows Server 2003 domain to have Windows Server 2008 or Windows Server 2008 R2 DCs, you can configure the domain to be at the Windows Server 2008 Domain Functional Level. At this functional level, you have more capabilities for configurations within the domain, but that doesn’t mean that the default behavior changes. This is the case with the Account Policies for domain users.

When you have a basic Active Directory domain that’s running at the Windows Server 2008 Domain Functional Level, the Account Policies for all domain users behave the exact same way they always have. A Windows Server 2008 or Windows Server 2008 R2 Active Directory domain, without FGPPs implemented, has the following characteristics for passwords affecting domain users:

  • The Default Domain Policy defines the password policies by default for every user in Active Directory and every user located in the local SAM on every server and desktop that joins Active Directory.
  • There can be only one password policy for domain users using Group Policy.
  • It’s not possible to configure the password policy in a GPO linked to an OU to affect users in the OU differently than other users in the domain or in a different OU.
  • The password policy settings can’t be extended to include additional settings without using a third-party tool or developing a custom password policy solution.
  • It’s not possible to configure a password policy for the root domain and have it “funnel” down to the other domains in the Active Directory tree.

Notice that the bullet list here is very similar to the list that was at the beginning of this article. The reason is that the Account Policy and password policy, even for Windows Server 2008 R2 domains, behave the exact same way as previous Windows 2000 and 2003 domains by default.

FGPPs
The preceding section was clear in stating that the default behavior of the Account Policies in a Windows Server 2008 and Windows Server 2008 R2 domain is exactly the same as it is in any other Active Directory domain before it. The difference comes when the Active Directory domain contains only Windows Server 2008 or Windows Server 2008 R2 DCs, and is moved to Windows Server 2008 Domain Functionality Level. When this occurs, it opens the door for FGPPs. Again, just to reiterate, without FGPPs configured, any Windows domain (including Windows Server 2008 R2 domains) acts the same as it always has.

The reason you’d want to configure FGPPs is to allow multiple password policies in the same Active Directory domain. Yes, that’s correct. The same Active Directory domain can have multiple password policies. The result could be the following:

  • IT employees have a minimum character limit of 20
  • HR and finance employees have a minimum character limit of 15
  • Standard employees have a minimum character limit of 10

In order to configure FGPPs, you won’t be using Group Policy — FGPPs don’t use Group Policy. Instead, the implementation of FGPPs is done by modifying the Active Directory database. The database is altered by adding one or more additional Active Directory objects, referred to as Password Settings Objects (PSOs). This might sound odd, and I must agree it is. If you decide to implement FGPPs, you’ll have a mixture of Account Policy settings, via GPOs and FGPPs, in your environment.

To complete the configuration of your FGPPs, you’ll need to complete the following steps:

  1. Launch ADSIEDIT.MSC on your DC.
  2. Select the View toolbar menu option, then click on the Connect to option.
  3. In the Connection Settings dialog box click the OK button (see Figure 1).
  4. Within ADSIEDIT, expand the view of your domain down to the CN=System, so you can see the contents available under this node.
  5. Right-click on the CN=Password Settings Container.
  6. Select the option to Create | Object.
  7. Fill out the values for each entry; Table 2 is a guide.

[Click on image for larger view.]
Figure 1. ADSIEDIT connection options.

 

 



Attribute Value Explanation
Cn HRPasswordPolicy The name of the password policy object in Active Directory. Should be named after which user group it will affect.
msDS-PasswordSettingsPrecedence 10 A reference number, compared to other precedence settings for other FGPPs, which will resolve a conflict if user is member of two groups and each group has an FGPP. Smaller numbers have higher precedence.
msDS-PasswordReversibleEncryptionEnabled False Boolean value to define if passwords should be stored with reversible encryption.
msDS-PasswordHistoryLength 24 Number of unique passwords user must input before reusing a password.
msDS-PasswordComplexityEnabled True Defines if password complexity should be enabled or not.
msDS-MinimumPasswordLength 15 Minimum number of characters in each user password.
msDS-MinimumPasswordAge -864000000000 Minimum password age (one day).
msDS-MaximumPasswordAge -36288000000000 Maximum password age (42 days).
msDS-LockoutThreshold 30 Number of failed password attempts before user is locked out.
msDS-LockoutObservationWindow -18000000000 Elapsed time to reset password lockout counter to maximum (in this case 30 minutes).
msDS-LockoutDuration -18000000000 If the number of bad passwords is met in observation window time, this defines how long the account should remain locked out (30 minutes).

Table 2. FGPP/PSO values to create a new object.

 

Note that the values inputs for minute/hour/day in Table 2 seem very odd. This is due to the fact that they’re input in the “18” data type. The 18 data type follows an odd format, which can be seen in Table 3.

Time Unit Formula Example Time Value
m minutes -60*(10^7) = – 600000000 30 minutes -18000000000
h hours -60*60* (10^7) = -36000000000 10 hours -360000000000
d days -24*60*60*(10^7) = -864000000000 42 days -36288000000000

Table 3. The “18” data type formatting for minutes, hours and days.

In order to link the FGPP/PSO to the correct user or group, you’ll need to configure an object attribute. In order to see the correct object attribute, ensure the FGPP/PSO in ADUC or ADSIEDIT is set properly, which can be seen in Figure 2.

 

 

 


[Click on image for larger view.]
Figure 2. FGPP/PSO filter settings to see correct attributes for setting up permissions.

In the attribute list for your FGPP/PSO, scroll down to the msDS-PSOAppliesTo entry and double-click this attribute to see the Multi-valued Distinguished Name With Security Principal Editor dialog box, as shown in Figure 3.

 


[Click on image for larger view.]
Figure 3. Multi-valued Distinguished Name With Security Principal Editor for FGPP/PSO.

You can enter a domain name, username or security group into the editor. Select the correct button, then add in your object to the editor. I added the HR group, as shown in Figure 4.


[Click on image for larger view.]
Figure 4. HR group added to the HRPasswordPolicy FGPP/PSO.

Verify that user in the HR group has the correct password policy by viewing the user account properties from within ADUC, then looking at the msDS-ResultantPSO attribute.

A New Path
The default password policy settings for a Windows Active Directory domain haven’t changed for the past 11 years, and in a default Windows Server 2008 R2 domain they’re the same to begin with. The Default Domain Policy controls all domain user password policies by default but can be altered by another GPO linked to the domain with higher precedence. Once the domain is configured to be a Windows Server 2008 Domain Functional Level domain, FGPPs can be used.

You can use ADSIEDIT.MSC to create and configure one or more FGPP objects or PSOs, which will now allow you to have multiple password policies in the same domain. The FGPPs/PSOs will be associated with a domain name, user or group — and have nothing to do with Group Policy, which you’ve known password policies to rely on for the past 11 years. Now you can obtain that segregation of password lengths for the different users in your single Active Directory domain.

Why it is best advised NOT to unlink the Default Domain and the Default Domain Controllers Group Policy – TechNet Blogs

Revisiting and important question – Jane Lewis’s Weblog – Site Home – TechNet Blogs.

 
1 May 2009 6:15 PM 

A little while ago I posted about what is considered best practice with regards to the Default Domain Controller policies and Default Domain Policy.

http://blogs.technet.com/janelewis/archive/2007/04/24/just-don-t-do-it.aspx

At the time I was struggling to find some good examples to back up my post. However After some discussion internally some learned and  senior escalation engineers for Microsoft in the U.K. have  explained further the reasons why it is best advised NOT to unlink the Default Domain and the Default Domain Controllers Group Policy.

The summation the key points are below;

GUIDs for these policies are well known – the same in every AD domain and forest since we shipped Windows 2000.

Domain GPO GUID {31B2F340-016D-11D2-945F-00C04FB984F9}

DC GPO GUID {6AC1786C-016F-11D2-945F-00C04FB984F9}

The reason they are fixed is that internal API’s will have knowledge of what policy to update without having ascertain which ones are applying to the current Domain or Domain Controllers. Examples of these policies are LSA/SAM policy – the API’s allow in -memory (DS) policy, such as audit; privileges; password settings on a DC, to be set directly – the type of configuration information which you would normally expect to be read from Group Policy  at start up  and background refresh are examples of API’s that do this.

In order to keep LSA/SAM policy and Group Policy in sync there is a callback mechanism . When one is updated directly then the respective  Group Policy is updated too. if the Default Group Policies are unlinked then they will still be updated and replicated but obviously as they are  not read again at startup by other DC’s  the policy change is not reflected on those boxes. Another example of direct use of those Well Known GUID’s  is  that  Adprep explicitly sets ACEs on them.Customers do unlink these policies and run without experiencing related issues .Or indeed what could could be happening is that  they do not  notice, as the difference may be quite subtle. For example some users may be prompted to change their passwords after 20 days instead of  30 days.Customers need to be aware that there is a risk associated with doing so. Potentially something may break as a consequence of unlinking these policies.

It is therefore advisable to as I stated in a previous post.

“If you must use a different Group Policy for your Domain Controllers simply modify the order in which the Policies are being processed by having the Default Domain Controllers Policy running at a lower priority and your customised Domain Controller Policy running at a higher priority.”

The Basics of Group Policies – Ask the Performance Team – TechNet Blogs

The Basics of Group Policies – Ask the Performance Team – Site Home – TechNet Blogs.

The Basics of Group Policies

 
5 Jun 2007 6:41 AM 

The Performance team handles Group Policies for several different components – most notably Printing, Internet Explorer and Terminal Server.  In most environments, the Active Directory administrator handles the design, implementation and maintenance all of the group policies – even if another group is responsible for the technologies affected by the policies.  When an issue arises with one of these technologies, often it is the administrator for that system who is trying to troubleshoot the problem – who may not know much about the policies in place.  So today we’re going to go over some basic Group Policy concepts.

The primary purpose of Group Policy is to apply policy settings to computers and users in an Active Directory domain to enable IT administrators to automate one-to-many management of users and computers.  This simplifies administrative tasks and reduces IT costs.  Administrators can efficiently implement security settings, enforce IT policies, and distribute software consistently across a given site, domain, or range of organizational units.

The Group Policy engine is the infrastructure that processes Group Policy components including server-side snap-in extensions and client-side extensions.  It is a framework that handles client-side extension (CSE) processing and interacts with other elements of Group Policy.  The Group Policy engine is contained within userenv.dll which runs inside winlogon.exe.  So let’s take a quick look at the Group Policy architecture:

image

When a client logs in to the Active Directory, it processes the appropriate group policies based on its membership within the domain, within a specific group, or within an organizational unit.  For example, if your machine is a member of an AD domain, then there will be a set of domain-wide policies that are applied to the machine when it is booted up.  There may also be policies applied based on where the machine is located geographically, or based on which business unit the machine belongs to.  The same principle applies to users.

The Group Policy Objects themselves are located on the SYSVOL share of the domain controllers within the AD.  Once the policies are brought down to the client, the individual client-side extensions (CSE) will apply the policies to the appropriate areas.

Client-Side Extensions (or CSE’s) are called by the Winlogon process at computer startup, user logon and at the Group Policy refresh interval.  Each CSE is registered with Winlogon in the registry.  This registration information includes a DLL and a DLL entry point (function call) by which the CSE processing can be initiated.  The Winlogon process uses these to trigger Group Policy processing.  Each extension can opt not to perform processing at any of these points (for example, avoid processing during background refresh).

Each CSE is registered with Winlogon in the following registry key:HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions.  Each extension is identified by a key named after the GUID of the extension.  Some common extensions and GUID’s are shown below:

GUID Extension Name
35378EAC-683F-11D2-A89A-00C04FBBCFA2 Administrative Templates
3610EDA5-77EF-11D2-8DC5-00C04FA31A66 Disk Quotas
B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A EFS Recovery
25537BA6-77A8-11D2-9B6C-0000F8080861 Folder Redirection
A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B Internet Explorer Maintenance
E437BC1C-AA7D-11D2-A382-00C04F991E27 IP Security
426031c0-0b47-4852-b0ca-ac3d37bfcb39 QOS Packet Scheduler
42B5FAAE-6536-11D2-AE5A-0000F87571E3 Scripts
827D319E-6EAC-11D2-A4EA-00C04F79F83A Security
C6DC5466-785A-11D2-84D0-00C04FB169F7 Software Installation

The diagram below shows the Group Policy Client-side extension components.

image

When a policy is created, the policy will be given a unique GUID.  A folder with this GUID will be created on the domain controller in the SYSVOL folder and then replicated to the other domain controllers.  The Group Policy template folder contains the following subfolders:

  • ADM:  Contains all of the .adm files for the GPO
  • Machine: Includes a Registry.pol file that contains the registry settings to be applied to computers (HKEY_LOCAL_MACHINE)
  • User: Includes a Registry.pol file that contains the registry settings to be applied to users (HKEY_CURRENT_USERS)

The User and Machine folders are created at install time, and the other folders are created as needed when the policy is set.  Each time GPOs are processed, a record of all of the GPOs applied to the user or computer is written to the registry.

  • GPOs applied to the local computer are stored in the following registry path:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
  • GPOs applied to the currently logged on user are stored in the following registry path:
    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History

OK – so now that you know a little bit about the behind the scenes workings of Group Policies, let’s quickly cover some basic GPO tools.  The three main tools to become familiar with are gpresult, the userenv.log and Resultant Set of Policies Snap-in (rsop.msc).  GPResult is a command-line utility that can be run with several different switches to determine what policies are applying (or might apply) to a particular user on the machine on which it is executed.  TheUserenv.log file is a diagnostic log to record detailed information about processing of the Group Policy engine.  The logging is enabled via the registry in the following key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon.  The specific value to set is UserenvDebugLevel.  This value is a DWORD value that should be set to 0x10002 to enable verbose logging to a log file.  The log file is written to the %Systemroot%\Debug\UserMode\Userenv.log file.

And that brings us to the Resultant Set of Policies Snap-in (rsop.msc).  All Group Policy processing information is collected and stored in a Common Information Model Object Management (CIMOM) database on the local computer.  This information, such as the list, content, and logging of processing details for each GPO, can then be accessed by tools using Windows Management Instrumentation (WMI).  The Resultant Set of Policies Snap-in leverages WMI to list the GPO details.  RSOP functionality is only available on Windows XP / Windows Server 2003 and later Operating Systems

And that wraps up our overview of Group Policies.  In future posts, we will be looking at GPO’s as they pertain to Internet Explorer, Terminal Services and other technologies supported by the Performance team.  Until next time …

Additional Resources:

 

Comments

Chris Warwick 
6 Jun 2007 10:53 AM

Good article – thanks!

Since you’re looking at the internals of Group Policy processing it might be worth mentioning the role of the Dfs client.  Specifically Dfs is used by the client to connect to the Sysvol to read group policy.  This isn’t clearly stated in many places – a while back it wasn’t stated anywhere.

I bashfully admit that many years ago while hardening/locking down machine configurations I disabled (via GPO) the client Dfs service; it was just an extra service we weren’t using, or so we thought, so best practice was to disable it.  Of course, this was a one-way step.  Apart from taking an age to debug the resulting mess it couldn’t even be backed out by reverting to the old policy (since policy processing had stopped!)

Whenever I’m describing GPO to others I’ve always made a point of mentioning this:-)

Thanks,

Chris