Blog - Title

July, 2008

  • Enabling Group Policy Preferences Debug Logging using the RSAT

    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.

    You have two options as to how to get a copy of the Group Policy Preferences ADMX files. You can download the entire Windows Server 2008 ADMX file set, or you can download just the Group Policy Preferences ADMX file set. You can download the installer for either of these file sets from These MSI applications install their contents to the default location of %PROGRAMFILES%\Microsoft Group Policy.

    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.

    - Mike Stephens

  • Five Common Causes of “Waiting for the DFS Replication service to retrieve replication settings from Active Directory”

     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:



    And within each DFSR server’s container, like:



    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:

    WMIC /namespace:\\root\microsoftdfs path DfsrReplicationGroupConfig get LastChangeSource

    This will return the DC you are talking to:


    • Examine the DFSR debug logs

    Finally, you can examine the DFSR debug logs. Go to %systemroot%\debug and open the DFSR<somenumber>.log file. Look for:

    20080521 10:57:47.110 2972 CFAD 7256 Config::AdConfig::Connect Binding to dcAddr:\\ dcDnsName:\\

    20080521 10:57:47.110 2972 CFAD 6586 Config::AdConfig::BindToAd Trying to connect.

    20080521 10:57:47.130 2972 CFAD 6605 Config::AdConfig::BindToAd Bound.

    20080521 10:57:47.130 2972 CFAD 6641 Config::AdConfig::BindToDc Try to bind. hostName:\\ domainName:<null>

    20080521 10:57:47.150 2972 CFAD 6651 Config::AdConfig::BindToDc Bound. hostName:\\ domainName:<null>

    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.


    You have a few options here:

    A. Wait patiently and enjoy some light reading.

    B. Force replication using REPADMIN (with /replicate /force) or REPLMON (with synchronize directory partition).

    C. Change your replication schedule and topology.

    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:

    A. Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088)

    B. Fixing Replication Connectivity Problems (Event ID 1925)

    C. Troubleshooting RPC Endpoint Mapper errors using the Windows Server 2003 Support Tools

    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:

    Fixing Replication Topology Problems

    Your event logs and DSSITE.MSC will tell the tale…

    4. AD replication blocked due to lingering objects

    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:

    A. Outdated Active Directory objects generate event ID 1988 in Windows Server 2003

    B. Lingering objects may remain after you bring an out-of-date global catalog server back online on Windows 2000

    5. AD replication blocked due to tombstone lifetime

    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.


    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. :-)

    - Ned Pyle

  • Installing GPMC on Windows Server 2008 and Windows Vista Service Pack 1

     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).

    1. Open Server Manager by click Start and then point to Administrative Tools. Click Server Manager
    2. Click Features in the console tree. In the Features pane, click Add Features
    3. Select Group Policy Management from the list of available features in the Add Feature Wizard. Click Install.
    4. 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

    1. Open an elevated command prompt.
    2. In the command prompt, type ServerManagercmd –install gpmc
    3. Start GPMC from the command prompt by typing start gpmc.msc
    4. 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.

    1. Download and install the Remote Server Administration Tools (
    2. After the installation is complete, then click Start, click Control Panel, and then click Programs.
    3. Click Turn Windows Features on or off from Programs and Features.
    4. Click Remote Server Administration Tools and then click Feature Administration Tools from the Windows Features dialog box.
    5. 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.

    - Mike Stephens

  • What are the Schema Extension Requirements for running Windows Server 2008 DFSR?

    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:

    dsquery.exe * "CN=Schema,CN=Configuration,DC=contoso,DC=com" -scope base -attr objectversion

    Here is what the versions will mean:

    47 = Windows Server 2008 R2
    44 = Windows Server 2008
    31 = Windows Server 2003 R2
    30 = Windows Server 2003
    13 = Windows 2000

    DFSR on member servers

    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



    Not currently used by DFSR code


    Not currently used by DFSR code


    Not currently used by DFSR code


    Used by Windows Server 2008 DFSR


    Not currently used by DFSR code


    Not currently used by DFSR code


    Not currently used by DFSR code


    Not currently used by DFSR code


    Not currently used by DFSR code


    Not currently used by DFSR code


    Not currently used by DFSR code


    Not currently used by DFSR code


    Not currently used by DFSR code


    Used by Windows Server 2008 DFSR


    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:

    1. You would not be able to make full use of the ms-DFSR-DefaultCompressionExclusionFilter functionality described in KB951003.
    2. 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:

    As always, feel free to comment below. This is ASKDS after all…

    (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.)

    - Ned Pyle

  • ADMT 3.1 Released

    Hi everyone, David here. I just wanted to spread the word that ADMT 3.1 is now available for download. Like all previous versions of ADMT, it’s free to install and use.

    The big change in this version of the Active Directory Migration Tool is support for migration using Windows Server 2008 domain controllers.

    Also included with this are new versions of the Password Export Service (for 32-bit and 64-bit DCs), and an updated migration guide, which we highly recommend for anyone planning to do a migration.

    As always, if you’re planning on doing a migration project, we recommend testing carefully before doing anything with production computers and users.

    - David Beach

  • PolicyMaker stops working after installing Windows XP SP3

    Hi this is Rob again. We had a couple cases recently where PolicyMaker settings were not applying to computer and users after installing Windows XP Service Pack 3.

    We found that PolicyMaker client-side extensions (CSE) are not registered after installing Service Pack 3. Examine the following location using regedit:

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions

    You should see the different client-side extensions for the computer. Here is the list of PolicyMaker CSEs:

    {00000040-789B-494F-BF51-216A4110581C} - PolicyMaker License
    {08E9566B-1390-4BFB-B19F-EA465BAD922D} - PolicyMaker Environment
    {08F5166F-E66B-4F15-80BF-DE94F083472A} - PolicyMaker Local Users and Groups
    {0947EA96-E4DE-48C5-99AD-FCC1829FFE86} - PolicyMaker Device Settings
    {15D30905-443F-4097-8FA8-0A2E35B475DC} - PolicyMaker Network Options
    {1EA5E892-2292-438F-8D05-40E7B0007585} - PolicyMaker Drive Maps
    {F0DB2806-FD46-45B7-81BD-AA3744B32765} - PolicyMaker Folders
    {F17E8B5B-78F2-49A6-8933-7B767EDA5B41} - PolicyMaker Files
    {F27A6DA8-D22B-4179-A042-3D715F9E75B5} - PolicyMaker Data Sources
    {F55DA052-16E1-434B-803F-F6A9F6945957} - PolicyMaker INI Files
    {F581DAE7-8064-444A-AEB3-1875662A61CE} - PolicyMaker Services
    {F5BFF32F-D563-460D-8764-890933FB03C0} - PolicyMaker Folder Options
    {F648C781-42C9-4ED4-BB24-AEB8853701D0} - PolicyMaker Scheduled Tasks
    {F6E72D5A-6ED3-43D9-9710-4440455F6934} - PolicyMaker Registry
    {F9C77450-3A41-477E-9310-9ACD617BD9E3} - PolicyMaker Applications
    {FD023FFE-C165-40D5-A201-439FC65AC8A5} - PolicyMaker Printers
    {FD2D917B-6519-4BF7-8403-456C0C64312F} - PolicyMaker Shortcuts
    {FD44098A-CA65-4054-8A70-EBAFAB263C70} - PolicyMaker Mail Profiles
    {FEF373ED-6CBE-4294-83EC-008D502B394A} - PolicyMaker Internet Settings
    {FF87F78A-E3A2-4AAE-B049-7E6BB1670D7B} - PolicyMaker Start Menu Settings
    {FFAA00BB-0D9B-401B-B71B-EF5ED1D88E6D} - PolicyMaker Regional Options
    {FFC64763-70D2-45BC-8DEE-7ACAF1BA7F89} - PolicyMaker Power Options

    NOTE: If you have purchased other products from DesktopStandard you may have more. Microsoft did not acquire all the products DesktopStandard offered.

    If you are missing these client-side extensions, you can register the DLL’s again by typing the following commands for the product listed:

    PolicyMaker Standard Edition:

    regsvr32 %systemroot%\system32\polprocl.dll
    regsvr32 %systemroot%\system32\polcmncl.dll

    DesktopStandard Software Update:  (FYI) This product is not supported

    regsvr32 %systemroot%\system32\polsucl.dll

    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:

    @echo off
    REM Sample DesktopStandard CSE Registration Script

    REM This script is provided "AS IS"
    with no warranties and confers no rights.
    REM For more information please visit
    REM to find terms of use.

    regsvr32.exe /s %systemroot%\system32\polprocl.dll
    regsvr32.exe /s %systemroot%\system32\polcmncl.dll

    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.

    - Rob Greene

  • Network Browsing with Windows Server 2008

    Ned here. I wanted to make sure all of our loyal readers know about an important post at our sister site Enterprise Networking:

    NetBIOS browsing across subnets may fail after upgrading to Windows Server 2008 

    While not a pure DS issue, it could definitely cause DS-related technologies to act oddly or fail. Be sure to give it a quick read.

    - Ned Pyle