Blog - Title

December, 2009

  • New Directory Services KB Articles/Blogs 11/29-12/5



    Error message when a Group Policy client-side extension cannot log RSOP Data:''0x80041002"


    Error 1789 when you use the LookupAccountName function on a computer that is running Windows 7 or Windows Server 2008 R2


    Windows Event Log Service is Starting… and my domain is down!

    Link-Pairs and Configuring Bridgeheads in ADAM/ADLDS

    Understanding USMT 4.0 Behavior with UEL and UE

    User Account Control and WMI

    Alternative DNS… Google.

    AD RMS Certificates and Licensing on the Client and the Server

    IN Progress: AD replication test script

    Problems with FDCC’s XP File Permissions

    Wingin' Migration -- Now migrate even MORE server roles to Windows Server 2008 R2!

    PowerShell Resources

    How it works: Active Directory Rights Management Services

    Just a quick post on IIS7 cert mapping setup

    Microsoft updates its enterprise ABC (Active Directory, BizTalk and Communications Server) roadmaps

    RSoP & GP Preferences

  • Windows Event Log Service is Not Starting… and my domain is down!

    Hi everybody, Scott Goad here to discuss an issue that I worked recently where the customer was unable to logon to the domain. The end result was a group policy preference setting, so enjoy the read.

    The issue occurred after a change was made to set a group policy preference item to change the clock display setting, but at first glance this was unrelated. The scenario:

    1. Change made to group policy preferences.
    2. No one could logon to the domain, regardless of Operating System.
    3. Windows Event Log service would not start on Windows Server 2008 servers.

    Knowing this information, it was time to start investigating why no one could logon. The usual items were checked, with running DCDIAG /v /e and checking the servers for errors. There were only 2 domain controllers, so we started with the first. We gathered the DCDIAG output and tried to open Event Viewer to see if there were any outstanding errors reported, but we could not launch the MMC. This was interesting, but still not the focus of the investigation.

    The next step was network connectivity – could we ping the DCs in question? Checking this allowed us to learn that the DNS Server Service was stopped, and trying to start the service resulted in:

    Error 1722: The RPC server is unavailable.

    Since the Event Log service would not start, this was the only error information reported from the OS. The Services snap-in shows that the Windows Event Log service was “Starting…”, and the Task Scheduler service and DNS Server Service were set to automatic, but not able to start.

    In discussing with the customer, it was apparent that they had set Locale-specific information via group policy preferences, and now had this issue. It turns out that there’s a known issue in group policy preferences, as outlined in KB:

    951430 A non-administrator user cannot log on to a domain from a computer that is running Windows Server 2008 if you set the locale information for the user by using a Group Policy preference setting;EN-US;951430

    As the article describes, the issue is within group policy preferences, but what is missing is the workaround information. To resolve the issue, you have to set the following registry value:

    HKEY_USERS\.Default\Control Panel\International
    Locale (REG_SZ)

    Set Locale to: 0000409 (Default for English – United States)

    Additional Locale IDs can be found here:

    The hotfix from the KB article will prevent this issue from happening in the future; however, to resolve the situation, the customer had to set the registry value and reboot. Once this had been set, the servers came back and were functional again.

    The KB 951430 has been rewritten to better identify this scenario, and will be published with the new content, similar to this article.

    If any of these symptoms sound familiar, check the version of gpprefcl.dll and gppref.dll and be sure it’s at least as high or newer as mentioned in the KB.

    Scott “Red Herring” Goad

  • Link-Pairs and Configuring Bridgeheads in ADAM/ADLDS

    Well, hello there AskDS readers. "Terrible" Tim Springston here with a little cross-posting blog action requested by my BFF Ned Pyle.

    Occasionally we come across things that are not so well documented. One of those is the ADAM or Lightweight Directory Services series of steps needed to configure replication topology.

    In Active Directory it’s a straightforward thing. You simply load up Active Directory Sites and Services (DSSite.msc) and you are given a nice and pretty graphical user interface that you can use to create sites, site links, select bridgehead servers and create replication connections. That’s not the case with ADAM/LDS-there is no snap-in designed to act like DSSite.msc for ADAM/LDS. We’ll chalk that up to being part of the “lightweight” aspect.

    So how do you create your site topology if you don’t have that tool? Well, creating sites and site links at least is easy. In ADAMADSIEdit.msc you simply create the new objects and are prompted to fill in the attributes that must be present (these are the “must-contain” items defined for that class of object in the schema).

    Selecting a bridgehead server - a server which will take care of inter-site replication between the specified sites in a sitelink - for two given sites is a little more difficult. Without a nice user interface we need to have a better understanding of how a server is shown to be the selected bridgehead server under the hood.

    First, let’s go back to the concept of linked pair relationships. In Active Directory we have some attributes whose values have a relationship to an attribute on another type of object. The obvious example of this is the link relationship between the User class object memberof attribute and the Group class object member attribute. If you add UserA to GroupB then there is a link between their respective memberof and member attributes.

    Here’s a graphic intended to illustrate that link pair relationship:


    Also part of the link pair concept is the idea that there is a forward end of this link as well as a backward end of it. The forward end of the link is the part that, if populated or depopulated results in the backward end also being updated.   In other words, if we remove UserA from being a member of GroupB then that link is gone as well. In DSA.MSC that action would be removing the user from being a member of that group on the group object, and then checking the user objects member list and seeing that, yep, that’s been updated too.  In the case of memberof and member the forward link of this relationship is on the group object.

    This linked value relationship is most often discovered by administrators as an unpleasant surprise following a disaster recovery.  Although we have excellent steps that will walk admins through the recovery process so that no problems are seen, if the steps aren’t followed then it’s possible for a user to be replicated inbound (following both that user and a given group’s deletion) before the group of which the user is a member.  Since the forward link of that relationship is not present, the link is removed.  The end result to the users in that circumstance can be email not delivered without distribution group membership or an “access denied” error to an object in the case of security groups.

    But let’s refocus on our need to create a bridgehead server. Link-pairs are important in the act of specifying a bridgehead server or servers.  There is a link pair relationship between two attributes and that is how a bridgehead server is identified.

    Those attributes are on two different objects. They are the bridgeheadTransportList attribute on the CN=<servename>,CN=Servers,CN=<sitename>,CN=Sites,CN=Configuration,DC=X object and the bridgeheadServerListBL attribute on the CN=<sitelinkname>,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,CN=X object. 

    You can view these attributes in ADAMADSIEdit.msc. Here’s a snapshot of brdgeheadServerListBL:


    As an interesting data point, we know that these two attributes have a link pair relationship because the MSDN schema definition of them says so-it shows bridgeheadTransportList as linkID 98 and bridgeheadServerListBL as linkID 99.  The even number of the bridgeheadTransportList linkID signifies that it is the forward link of the relationship. As an additional tip, the “BL” in an attribute name typically signifies that it is a back link of a link pair.

    Now let’s apply what we have learned about selecting a bridgehead in ADAM/LDS.

    Let’s say I have ADAM/LDS sites named LA, KC and NY and I want to specify the bridgehead servers for the LA to KC site link.  We are assuming that you have already created the site link object for LAtoKC which is easily done using ADAMADSIEdit.msc

    • To select our bridgeheads we simply edit the bridgeheadTransportList attribute on the servers we would like to select to bridgehead servers for this link. 
    • Specifically, for the LA site we would edit that attribute using LDP.EXE or ADAMADSIEDIT.MSC on the chosen LA DC’s object (which has a distinguished name like CN=LADC1,CN=Servers,CN=LA,CN=Sites,CN=Configuration,DC=X.
    • In the bridgeheadTransportList attribute you simply paste in the distinguished name of the sitelink object between the two sites.  
    • We would likewise do this for a DC in KC as well-pasting the DN of the same sitelink into the bridgeheadTransportList attribute.

    In this way we have told ADAM/LDS that these replicas are the selected bridgeheads for intersite replication for that site link.   You can verify that since the distinguished name of the respective DCs in KC and LA will then appear in the bridgeheadServerListBL attribute list on the site link as a result of the linked pair relationship those two attributes have.

    Now you’re one step closer to customizing your replication topology sans a custom user interface for the job.

    Tim “Rick Roll” Springston