DesktopStandard Application Security: (FYI) This product is owned by BeyondTrust

regsvr32 %systemroot%\system32\polseccl.dll

Once this is done, reboot the computer. PolicyMaker settings should start applying again. You can deploy the RegSvr32 commands as a computer startup script, or run the scripts as a post SP3 installation script. For example:

Please remember that Policymaker is in extended support and there are no further updates being released. Policymaker has been superseded by the free Group Policy Preferences CSE’s and is included with Windows Server 2008 and RSAT for Windows Vista SP1. GPP can be used on Windows XP and Windows Server 2003 as well.

Mike here. Sometimes you need to enable additional logging when you are troubleshooting a particular component in Windows. Group Policy Preferences includes the ability to create verbose debug logging for each included client-side extensions. You activate Preference debug logging through Group Policy. Preference debug logging policy settings are located under the Computer Configuration\Policies\Administrative Templates\System\Group Policy node when editing a Group Policy object.

Figure 1 Group Policy Preferences debug logging

You can individually enable each preference client-side extension. Logging and tracing entries provide you with a several configuration options including what type of data to write to the event logs (Informational, Errors, Warnings, or all), enable trace logging and the location of the trace log file, and the size of the file.

Figure 2 Preference Logging and Tracing policy settings

You can configure the location of the trace files; however, keep in mind that file system permissions changed on Server 2008 and Windows Vista. Make sure permissions do not interfere with creating the log file. You'll notice the default location for all three log files is %COMMONAPPDATA%\GroupPolicy\Preference\Trace. The variable %COMMONAPPDATA% is not recognized by Windows, however; it is meaningful to Preference client-side extensions. Preference client-side extensions recognize this variable and expand it according to operating system on which the client-side extension is installed. For Windows Server 2003 and Windows XP, %COMMONAPPDATA% expands to %SYSTEMDRIVE%\Documents and Settings\All Users\Application Data. The equivalent path for Windows Server 2008 and Windows Vista is %SYSTEMDRIVE%\ProgramData (this folder is hidden by default, but you can manually type the path in Windows Explorer).

Logging and tracing missing from RSAT

You've installed Windows Vista Service Pack 1; you've downloaded and installed RSAT. You try to enable Logging and tracing, but it's not there. Well, there is a reason for this.

Figure 3 Logging and tracing missing from RSAT

Administrative Templates show in the user interface because of two files: an .ADMX and an .ADML. Logging and tracing does not appear because the GroupPolicyPreferences.admx and .adml files are not included with RSAT. You need to copy these to your local or central store.

The Group Policy Preferences ADMX installation creates an additional folder named Preferences, which contains a single ADMX file with multiple locale folders. You want to copy the GroupPolicyPreferences.admx file into your policydefinition folder. If you are using a central store, then you must copy the file to the policydefinition folder on SYSVOL, otherwise; copy the file to your local store. You'll then want to copy the .ADML file to the corresponding locale folder located in your policydefinition folder. See the Managing Group Policy ADMX Files Step-by-step guide for more information on managing ADMX Files and creating a central store. After you've copied both the .ADMX and .ADML file into the proper store, then close all instances of GPMC and its editor. Restart GPMC and edit the GPO in which you want to add Logging and tracing policy settings. Expand the nodes under Computer Configuration and you should now see Logging and Tracing options.

Ned here again. When setting up Distributed File System Replication (DFSR) on Windows Server 2003 R2 and Windows Server 2008, it’s fairly common to hear the following from a customer:

“I setup DFSR a few hours ago, but it does not seem to be configured on all the servers”

“I ran the DFSR Diagnostic health report and after hours it still says:

‘This member is waiting for initial replication for replicated folder FOO and is not currently participating in replication. This delay can occur because the member is waiting for the DFS Replication service to retrieve replication settings from Active Directory. After the member detects that it is part of replication group, the member will begin initial replication.’

What’s up here?

How DFSR works

First, a little background. DFSR depends almost completely on Active Directory (AD) and a Domain Controller (DC) to get settings, topology, and all the other goo that configures replication. It pulls them from two places:

Within a global container for the domain, like:

CN=DFSR-GlobalSettings,CN=System,DC=DomainNC

And within each DFSR server’s container, like:

CN=DFSR-LocalSettings,CN=ServerName,OU=SomeOU,DC=DomainNC

This means that for DFSR configuration to take effect, your DC’s must have replicated in the data. Furthermore, DFSR has what we call “DC affinity”. Once it finds a DC, the DFSR service will stick with that DC until the DFSR service is itself restarted. Yes, even if that DC is down or if it no longer exists. The DFSR service will poll its DC every 15 minutes and pick up these changes – if the data is not on that DC yet through replication, the changes will not take effect.

Finding the DC

So now we know the importance of AD to DFSR. When we get the ‘waiting to retrieve’ warning, what can we do to figure out what’s going on? Let’s go through this step by step.

There are a few ways we can determine which DC is being polled.

Check the DFSR event log

If we open the Event Viewer snap-in on the server, navigate to the DFSR event log, and then search for the most recent 1206 event, we will see which DC the server is talking to:

The downside to this is the event log may have already wrapped when you look here. If you restart the DFSR service the new event will be added, but there’s the risk that it might start talking to another DC which isn’t having a problem. So your problem is (kind of) fixed, but you still don’t have a root cause.

Use a WMI query

A more reliable way to determine the DC is by using the WMIC command. Open a CMD prompt as an administrator on the DFSR server and run:

There’s our domain controller. If it’s not in the latest log, you will need to unzip the DFSR debug logs using a tool that understands the GZ format (such as 7-Zip, Winzip, WinRar, etc), and then you can find the entry. As you can tell, using the debug logs is probably the least friendly way to find – but you’ll see later that it’s critical for troubleshooting.

Figuring out why DFSR doesn’t have the info from AD

When we talk to customers in this scenario, DFSR is always blameless – it’s really just exposing a deeper issue in Active Directory. Since we now know the DC in question, let’s run through the five most common reasons why we might be getting this warning:

1. AD replication latency

Active Directory replication is based on the theory of ‘multi-master loose consistency with convergence’. Intra-site replication on Win2003 DC’s will only take fifteen seconds, but by default inter-site replication is 180 minutes (three hours).

So if I have a chain of sites connected like below and my original DFSR configuration was set on a DC in Site B, those three DC’s would have the change available for their DFSR customers within 30 seconds or so. But the DC in Site F might not see it for nine hours.

So actually this isn’t really always an ‘issue’ per se – just a fact of your environmental configuration.

2. AD replication blocked due to network misconfigurations

It’s possible that your DC is not actually replicating at all. Historically, the most likely reason for this is network misconfigurations. These come from DNS resolution, firewall blocks, etc. To step through the most common areas, check out:

Whatever you suspect, it’s always advisable to start with a REPADMIN.EXE /SHOWREPS on the DC just to get a line on what replication health looks like.

3. AD replication blocked due to topology misconfigurations

AD replication might be in a state where if just knew where its partners were, it could replicate fine. It’s common to find a variety of site topology missteps in environments, so make sure you run down:

Now we have moved past trivial configuration issues into a much more insidious ground. Lingering objects are typically objects that exist in the read-only GC partition of a domain controller but no longer exist in the read-write source domain partition. This can happen when an administrator brings a DC back online after it has been shut off for months; source objects that were deleted and tombstoned are longer available and the old DC can’t be told about the deletions anymore, so he still has ‘reanimated’ versions.

If ‘strict replication consistency’ is in place, that server is not allowed to replicate anymore until it’s fixed (this is a good thing – and if you don’t think so, I will be happy to tell you stories about lingering object cleanup on a forest with 20 domains and 3000 DC’s, all infected with LO’s). So you will want to follow:

Honestly, if you get this one, you should call us. Event ID 2042 (“It has been too long since this machine replicated”) is tricky to fix without having a frank discussion about the ramifications for your environment. While we do have some techniques, the cure is usually worse than the disease. In most circumstances, the best answer is to forcibly demote the DC because you (of course!) have several other DC’s that can handle the load in the meantime.

Summary

So you came here looking to fix DFSR and left having to fix Active Directory. That’s the funny thing about troubleshooting distributed systems; often the component throwing the errors isn’t actually at fault. In order for DFSR to function smoothly, it needs solid information from its domain controller – keeping that in mind will help you through all your days.

One last thing - I can already hear people yelling ‘USN Rollback!’, ‘Target principal name incorrect!’ and other more esoteric scenarios that might cause AD replication failures. We’re just trying to cover the 99% here, you AD veterans. :-)

Mike here again. For some time now, we’ve had inquiries about where the Group Policy Management Console (GPMC) is located in Windows Server 2008 or Windows Vista SP1. It’s well documented that Server 2008 includes GPMC but, it does not appear in the administrative tools.

The Group Policy Management Console is included in Windows Server 2008; however, you must install it before you can use it. The domain controller promotion process installs GPMC on the server, in addition to adding the domain controller to the domain. Additionally, you can install GPMC on a member server as long as it’s a member of the domain. Let’s look at two ways to install GPMC on Windows Server 2008 (other than through DCPROMO).

Installing GPMC using Server Manager (Windows Server 2008)

The Group Policy Management Console is a Feature in Windows Server 2008. You install Features using Server Manager. Once installed, you can access the feature using Server Manager or you can the specific management console (like gpmc.msc).

Open Server Manager by click Start and then point to Administrative Tools. Click Server Manager

Click Features in the console tree. In the Features pane, click Add Features

Select Group Policy Management from the list of available features in the Add Feature Wizard. Click Install.

Start using GPMC or close Server Manager.

There’s another way to install GPMC using Server Manager, which usually installs quicker that using the Server Manager user interface. Server Manager includes a command line utility for installing Features and Roles named ServerManagercmd.exe.

Installing GPMC from the Command Line

Open an elevated command prompt.

In the command prompt, type ServerManagercmd –install gpmc

Start GPMC from the command prompt by typing start gpmc.msc

Close the command prompt.

Installing GPMC on Windows Vista Service Pack 1

Installing GPMC on Windows Vista Service Pack 1 can be a little confusing. First, you must download the Remote Server Administration Tools for Windows Vista Service Pack 1 before you can install GPMC. You may remember that GPMC was included in Windows Vista RTM; however Service Pack 1 removes it. After installing RSAT, you then want to install GPMC. Installing RSAT simply includes the Remote Server Administration tools on the Windows Vista SP1 computer but does not deploy for use—you’ll want to choose which RSAT tools you want used on the computer.

Click Group Policy Management Tools and click OK to complete the installation.

You’ll now see Group Policy Management included under the list of Administrative Tools (On Vista, you may need to actually show the Administrative Tools on the start menu – this can be done through Control Panel –> Taskbar and Start Menu –> Start Menu –> Customize –> System Administrative Tools). You can also start GPMC from the command line or run/search menu by typing gpmc.msc.

Ned here again. With the release of Windows Server 2008, a number of customers have asked us whether or not they need to extend the Active Directory schema in order to use the new version of Distributed File System Replication (DFSR).

The answer is, of course: it depends. :)

There are a few DFSR scenarios available in Windows Server 2008, so let’s start by talking about them. Then we’ll see what you as an administrator can decide to do in your environment.

DFSR with SYSVOL

If you want to stop using the legacy File Replication Service (FRS) to keep your SYSVOL shares in sync, you definitely need to extend the schema. This is because only Win2008 DC’s can participate in SYSVOL replication using DFSR, and in order to add Win2008 DC’s, the schema must be at 2008 level (i.e. version 44). Additionally in that scenario, you must be at a Windows Server 2008 Native Domain Functional Level. You can check the schema version of your forest by looking at the objectVersion attribute on the Schema object. You can view this with ADSIEdit or with a Dsquery command:

Here things get a bit muddier. When we extend the schema to version 44, fifteen new DFSR-related attributes are added. Here’s a table describing them:

Attribute name

Status

ms-DFSR-CachePolicy

Not currently used by DFSR code

ms-DFSR-CommonStagingPath

Not currently used by DFSR code

ms-DFSR-CommonStagingSizeInMb

Not currently used by DFSR code

ms-DFSR-DefaultCompressionExclusionFilter

Used by Windows Server 2008 DFSR

ms-DFSR-DeletedPath

Not currently used by DFSR code

ms-DFSR-DeletedSizeInMb

Not currently used by DFSR code

ms-DFSR-DisablePacketPrivacy

Not currently used by DFSR code

ms-DFSR-MaxAgeInCacheInMin

Not currently used by DFSR code

ms-DFSR-MinDurationCacheInMin

Not currently used by DFSR code

ms-DFSR-OnDemandExclusionDirectoryFilter

Not currently used by DFSR code

ms-DFSR-OnDemandExclusionFileFilter

Not currently used by DFSR code

ms-DFSR-Options2

Not currently used by DFSR code

ms-DFSR-Priority

Not currently used by DFSR code

ms-DFSR-ReadOnly

Used by Windows Server 2008 DFSR

ms-DFSR-StagingCleanupTriggerInPercent

Not currently used by DFSR code

It turns out only two of these new attributes are actually used. The rest are reserved for the future of DFSR (and some are pretty tantalizing, aren’t they? Please don’t get your hopes up too high; there are R2 DFSR attributes that are still unused).

So by extending the schema, there are only two attributes added. What if we didn’t bother? The good news is DFSR will still work fine, replicate data, and not give you any errors or problems about these attributes. The downside is:

You would not be able to make full use of the ms-DFSR-DefaultCompressionExclusionFilter functionality described in KB951003.

You would not be able to make use of the msDFSR-ReadOnly functionality (which is only for RODC’s anyway, so no big loss if you are not using them).

And yes – Win2008 and Win2003 R2 DFSR servers will still happily replicate with each other in this scenario.

So is that it?

Of course not! There is really no compelling reason not to upgrade your schema once you have started to deploy Windows Server 2008 and Vista. If you don’t extend, you won’t get all the other interesting attributes that you might find useful. Things like Bitlocker Drive Encryption Recovery, Credential Roaming, DFS Namespace Version 2, Read-Only Domain Controllers, and the aforementioned DFSR SYSVOL support. These are really compelling features and you’ll need your schema extended to get them.

If you need to track down all the other schema changes made by Win2008, the best two references are:

(Update 6/3/09 - now includes 2008 R2 schema version. And no, there are no new Schema updates for DFSR in 2008 R2, nor do any of the reserved Schema updates described above change for R2 or start being used.)