Blog - Title

October, 2009

  • New Directory Services KB Articles/Blogs 10/18-10/24

    KB

    976723

    IPv6 network address seems case-sensitive at address assignment for multiple network adapters installed on a Windows7 and Windows Sever 2008 R2 based computer.

    976647

    The migration of hotfixes may fail after the installation of a Windows Server 2003 or Windows XP service pack

    975702

    Error message when you change security settings for a folder that contains a child object for which you do not have access permission: "Access is denied"

    974971

    Error message when you use the CryptAcquireContext function to request a handle to a third-party CSP on a computer that is running Windows Vista or Windows Server 2008: "0x800b0100 (Invalid Signature)"

    974504

    The Windows Remote Manager (WinRM) service does not start after you uninstall WinRM 2.0 on Windows Server 2008 or on Windows Vista

    975815

    File corruption occurs under a stress situation when the CopyFileEx function is used to copy a file between two computers that are running Windows Server 2008 or Windows Vista

    976924

    You receive Windows Time Service event IDs 24, 29, and 38 on a virtualized domain controller that is running on a Windows Server 2008-based host server with Hyper-V

    974909

    The network connection of a running Hyper-V virtual machine is lost under heavy outgoing network traffic on a Windows Server 2008 R2-based computer

    974625

    You cannot uninstall ADMT 3.1 after you perform an in-place upgrade to Windows Server 2008 R2

    976659

    Known issues that may occur when you use ADMT 3.1 to migrate to a domain that contains Windows Server 2008 R2 domain controllers

    976826

    Upgrading a member server to Windows Server 2008 R2 does not fully remove FRS

    976736

    How to install Windows PowerShell on a computer that is running Windows Server 2008 R2 Core

    976888

    Error message when you try to manage a server that is running Windows Server 2008 R2 by using the Remote Server Administration Tools for Windows 7: "You do not have the permission to complete this task"

    Blogs

    ADMT, RODC’s, and Error 800704f1

    Importing the DFS Replication Management Pack

    Group Policy Slow Link Detection in Vista and beyond

    Linus Torvalds gives Microsoft Windows 7 a thumbs up!

    RDS CAL Single Pack now available in Retail channel

    View/Configure Protected ACL and Fixing Broken Inheritance

    Installing the DFS Replication Management Pack

    Windows 7 Virtual PC and XP Mode RTM - now available for download

    How do you tell AdFind that you only want just the xyz attribute returned?

    Interesting Issue with Major Implications

    Windows 7 / Windows Server 2008 R2: Problem Steps Recorder

    Group Policy Changes in Windows XP SP3

    Microsoft releases Windows-7-friendly version of Desktop Optimization Pack

    DFS Replication Management Pack for Operations Manager 2007 is available

    Windows 7 / Windows Server 2008 R2: AppLocker

  • Comment issues, continued

    Hey all. If you have a moment, please try and post a comment on this post. Especially non-Microsoft employees. We're still trying to see why comments stopped working.

    Update Nov 2: Well, it seems to be working now. :-) Thanks for all the help folks, it's much appreciated. Comment away, we'll see 'em now.

    Thanks,

    Ned

  • Explanation of the Remote Desktop Services CAL Upgrade behavior in Windows Server 2003 and Windows Server 2008

    Hello everyone, Brian Singleton here. There has been a lot of confusion over the Remote Desktop Services (aka Terminal Server) client access license upgrade process in Windows and this posting is an explanation on how the behavior is actually supposed to function.

    In Windows Server 2003 as well as Windows Server 2008 and Windows Server 2008 R2 we have a group policy setting called, “Prevent License Upgrade” and below is a description of the setting:

    The license server will always try to provide the appropriate RDS CAL for a connection.  For example a license Server provides a Windows 2000 Remote desktop services (RDS) CAL token for clients connecting to a terminal server running Windows 2000, operating system, a Windows Server 2003 family RDS CAL token for a connection to a terminal server running Windows Server 2003, and a Windows Server 2008 family RDS CAL token for a connection to a terminal server running Windows Server 2008.

    By default, if the most appropriate RDS CAL is not available for a connection, a Windows Server 2003 license server will issue a Windows Server 2003 RDS CAL, if available, to the following:

    • A client connecting to a Windows 2000 terminal server

    In the case of a Windows Server 2008 license server, it will issue a Windows Server 2008 RDS CAL, if available, to the following:

    • A client connecting to a Windows Server 2003 terminal server
    • A client connecting to a Windows 2000 terminal server

    So if it works like it is stated in the group policy setting by default, “why does it not work for me”?

    This feature is only utilized in mixed terminal server\terminal server license server environments.

    The RDS CAL upgrade behavior functions as follows:

    Scenario 1: Windows 2000 and Windows Server 2003:

    In my environment I have a Windows Server 2000 licensing server as well as a Windows Server 2003 licensing server (TLS).  The Windows 2000 TLS does not have any available Windows 2000 TS CAL tokens, but my Windows Server 2003 TLS has only Windows Server 2003 Per Device TS CAL tokens installed.  I also have a Windows 2000 terminal server which retrieves its TS CAL token from the Windows Server 2000 TLS via license server override. In this scenario my client is a WinCE thin client, since we require a purchased TS CAL to be installed.  The first time I connect to the Windows 2000 terminal server, I obtain a Windows 2000 Temporary TS CAL token from my Windows 2000 TLS.  The second time I connect to the Windows 2000 terminal server the following occurs:

    Since my Windows 2000 TLS does not have any purchased, permanent TS CAL tokens available, the Windows 2000 TLS will forward the request to another TLS via TS licensing discovery, in the case of my environment, to the Windows Server 2003 TLS.  Since my Windows Server 2003 TLS does not have any Windows 2000 TS CAL tokens installed it will issue a Windows Server 2003 TS CAL token to the client connecting to the Windows 2000 terminal server.

    Scenario 2: Windows Server 2003 and Windows Server 2008/Windows Server 2008 R2:

    In my environment I have a Windows Server 2003 licensing server as well as a Windows Server 2008 licensing server.  The Windows Server 2003 TLS does not have any Windows Server 2003 TS CAL tokens available, but my Windows Server 2008 TLS has only Windows Server 2008 Per Device RDS CAL tokens installed.  I also have a Windows Server 2003 terminal server which retrieves its TS CAL tokens from the Windows Server 2003 TLS via license server override.

    In this scenario my client is a Windows XP Professional client.  The first time I connect to the Windows Server 2003 terminal server, I obtain a Windows Server 2003 Temporary TS CAL token from my Windows Server 2003 TLS.  The second time I connect to the Windows Server 2003 terminal server the following occurs:

    Since my Windows Server 2003 TLS does not have any permanent TS CAL tokens available, the Windows Server 2003 TLS will forward the request to another TLS via TS licensing discovery, in the case of my environment, to the Windows Server 2008 TLS.  Since my Windows Server 2008 TLS does not have any Windows Server 2003 TS CAL tokens installed it will issue a Windows Server 2008 RDS CAL token to the client connecting to the Windows Server 2003 terminal server.

    I hope this explanation on the TS CAL upgrade process has cleared the confusions you may have on this feature.

    Brian “Bingleton” Singleton

  • DFS Referrals and IPv6: Outta site!

    Hi, David Everett here again to discuss an issue where DFS clients connect to out-of-site targets when the IPv6 protocol has been partially disabled using an incorrect method.

    The customer deployed a DFS link replicated by DFSR. An in-site DFS namespace (DFSN) target called ContosoFS1 was deployed in the branch site. It wasn’t long before branch site users started reporting slow performance access data on the DFS link.

    The 1st step was to determine what Active Directory site the DFS clients resided, whether in-site targets existed in the DFS referral and if the in-site target was the Active Target of the DFS client.

    To determine which site the client thought it belonged to in Active Directory, we ran this command from the client’s command prompt:

    Nltest.exe /dsgetsite

    This returned the correct site name. Then in order to determine if the in-site target server was appearing in the list of servers we had the user connect to the DFS link and had the user run this command at the command prompt:

    Dfsutil.exe /pktinfo

    We found that the client was seeing the in-site DFS target server in the referral. As shown below the in-site DFS target server, which is also a DFS Root server, was at the top of the referral order for \\contoso\dfsroot but ContosoFS1 was at the bottom of the referral order for the in-site folder target.

    c:\>dfsutil /pktinfo
    Microsoft(R) Windows(TM) Dfs Utility Version 4.2
    Copyright (C) Microsoft Corporation 1991-2005. All Rights Reserved.

    --mup.sys--
    4 entries...
    Entry: \Contoso\DFSRoot
    ShortEntry: \Contoso\DFSRoot
    Expires in 0 seconds
    UseCount: 3 Type:0x81 ( REFERRAL_SVC DFS )
       0:[\ContosoFS1\DFSRoot] State:0x119 ( ACTIVE TARGETSET )
       1:[\ContosoFS2\DFSRoot] State:0x09 ( )
       2:[\ContosoFS3\DFSRoot] State:0x109 ( )
       3:[\ContosoFS4\DFSRoot] State:0x09 ( )
       4:[\ContosoFS5\DFSRoot] State:0x09 ( )

    Entry: \Contoso\DFSRoot\TargetFolder
    ShortEntry: \Contoso\DFSRoot\TargetFolder
    Expires in 0 seconds
    UseCount: 0 Type:0x1 ( DFS )
       0:[\ContosoFS4\TargetFolder] State:0x131 ( ACTIVE TARGETSET )  
    <- out of site IPv4-only W2K3 target that client is connected to
       1:[\ContosoFS3\TargetFolder] State:0x21 ( )   
    <- out of site IPv4-only W2K3 target
       2:[\ContosoFS5\TargetFolder] State:0x21 ( )   
    <- out of site IPv4-only W2K3 target
       3:[\ContosoFS1\TargetFolder] State:0x121 ( )    <- In-site target that should be at top of list but isn't because IPv6 is incorrectly disabled

    Once we knew the client was determine its site correctly from active Directory and that the in-site DFS target server was appearing in the DFS referral the focus turned from the client to the Active Directory and the target server.

    A quick glance at Active Directory Sites and Services snap-in suggested the IPv4 Site/Subnet logic was properly configured and correct site discovery by the client reinforced this. However, there were no Site/Subnet associations for IPv6 which is the preferred protocol for Windows Server 2008.

    Since IPv6 is the preferred protocol for Vista and later Operating Systems I was going to implement an IPv6 Site/Subnet association in Active Directory Sites and Services and see if this would improve DFS referral ordering of the in-site DFS target server. I checked the configuration of IPv6 on ContosoFS1 and found the protocol had been unchecked; which is not a good practice.

    It’s a common misconception that unchecking IPv6 disables the protocol when in fact all it does is introduce transient errors. Windows Vista and later operating systems heavily rely upon IPv6 for internal operation, which means the protocol cannot be disabled or uninstalled entirely. Unchecking IPv6 on the adapter settings only unbinds the protocol from the NIC and the OS can still attempt to send remote traffic to the NIC where it never hits the wire.

    There are three solutions for this:

    I. The preferred method is to place a check mark next to "Internet Protocol Version 6 (TCP /IPv6)" on the IP Properties of the Adapter and reboot the server.

    II. Configure Static IPv6 addresses on your Windows Server 2008 DFS target servers and then define IPv6 Subnet/Site associations in Active Directory Sites and Services. See the following TechNet article on how to do this:

    Create a Subnet Object or Objects and Associate them with a Site

    III. For those who have some aversion to having any IPv6 traffic hitting the wire there is a “supported” [not recommended by the Microsoft Product Group] way to disable outbound IPv6 using the DisabledComponents registry value as directed in KB929852. Contrary to what the article states, it is possible to simply use Group Policy Preferences to disable IPv6 domain-wide – there is no need for a custom ADMX.

    NOTE: It is beyond the scope of this blog to determine which components of IPv6 should be disabled in a given environment using DisabledComponents. To completely disable all External use of IPv6 configure DisabledComponents to ffffffff. Also, if you find IPv6 remains checked in the UI after configuring DisabledComponents in the registry rest assured the protocol is disabled for all remote traffic.

    For those interested in more about DFS Site Discovery and Target Selection please see the DFS FAQ.

    -David “Dy-no-miiiite!” Everett

  • Followup - more info on the new SCOM 2007 Management Pack for DFSR

    Hey all, Ned here again. Mahesh from the DFSR development team has new posts up on the System Center Operations Manager 2007 management pack that was released for DFSR. Give them a read, Mahesh always writes good stuff.

    Installing the management pack

    Importing the management pack

    Configuring the management pack

    Optional configuration – enabling backlog monitoring 

    These are in addition to the post I referenced back here

    - Ned 'the redirector' Pyle

  • How to Decommission an ADAM/ADLDS server and Add Additional Servers

    Hello, LaNae here again. Recently I worked with a customer that was looking for a comprehensive document that outlined the steps for decommissioning a server that had an ADAM/ADLDS instance installed on it. I along with the customer realized there is no such document and you have to piece together multiple documents to get the steps. I decided to write this blog at the urging of the customer so that others do not have this issue.

    For the purpose of this blog we will work with the following example:

    Current Configuration

    • There are 2 ADAM/AD LDS instances in one configuration set.
    • Server A and Server B are the names of the servers that host the instances.

    Goal

    Add Server C and Server D and install and configure ADAM/AD LDS instances that will be part of the existing configuration set. Remove the ADAM/AD LDS instances from Server A and Server B and decommission them.

    Overview of Steps

    1. Install ADAM or the AD LDS role on servers C and D.

    2. Install and configure the ADAM/AD LDS instances one on each server to be members of the existing configuration set. Steps for ADAM: Managing Configuration Sets Steps for AD LDS: Practice Managing Replica AD LDS Instances

    3. Once replication is complete you will need to transfer the ADAM/AD LDS built-in FSMO roles from Server A or B which ever holds the roles to Server C or D. There are only 2 roles you will need to transfer, Naming Master and Schema Master. Replication in ADAM or AD LDS

    Check Replication

    From an ADAM command prompt or regular command prompt depending on whether this is ADAM or AD LDS you can run the following command to check replication.

    Repadmin /showreps servername:portnumber of instance

    Determining FSMO Role Holder

    If ADAM is installed all the following steps must be done from the ADAM command prompt. If using ADLDS a regular command prompt is fine.

    1. Type dsmgmt <enter>

    2. Type roles <enter>

    3. Type connections <enter>

    4. Type connect to server servername:portnumber of instance <enter>

    5. Type quit <enter>

    6. Type select operation target <enter>

    7. Type list roles for connected server <enter> Note: This should list who owns the FSMO roles.

    image

    Transfer FSMO Roles to new Server

    The following steps need to be done from an ADAM command prompt if running ADAM.

    1. Open an ADAM tools command prompt.

    2. At the command prompt, type: dsmgmt

    3. At the dsmgmt: command prompt, type: roles

    4. At the FSMO maintenance: command prompt, type: connections

    5. At the server connections: command prompt, type: connect to server servername:portnumber where servername:portnumber is the computer name and communications port number of the ADAM instance that you want to use as the new naming master or schema master.

    6. At the server connections: command prompt, type: quit

    7. At the FSMO maintenance: command prompt, type: transfer rolename

    image

    Remove the Instances from the old servers

    To remove an ADAM instance

    1. Open Add or Remove Programs.

    2. Click Change or Remove Programs, and then click the ADAM instance that you want to remove.

    3. Click Remove.

    To remove an AD LDS instance

    1. To open Programs and Features, click Start, click Settings, click Control Panel, and then double-click Programs and Features.

    2. Locate and click the AD LDS instance that you want to remove.

    3. Click Uninstall.

    You can now decommission Server A and B.

    - Lanae Wade

  • Using ADMT 3.1 to migrate to Windows Server 2008 R2 domains

    UPDATE June 19 2010 - stop reading and go here, we released ADMT 3.2:

    http://blogs.technet.com/b/askds/archive/2010/06/19/admt-3-2-released.aspx

    ===============

    Hi all, Ned here again. Microsoft is still working on ADMT 3.2, which can be installed on Windows Server 2008 R2 servers for migrations. There's no estimated date for this new tool yet.

    In the meantime, we have tested ADMT 3.1 and come up with supported scenarios for using it to migrate to R2 domains. Below are two KB articles that cover the requirements, what's supported, and known issues. As anyone who has emailed me already knows, we definitely support running ADMT 3.1 on a Windows Server 2008 DC or member server in an R2 domain, and migrating with it will be supported. Read more about this:

    Known issues that may occur when you use ADMT 3.1 to migrate to a domain that contains Windows Server 2008 R2 domain controllers - http://support.microsoft.com/kb/976659

    You cannot uninstall ADMT 3.1 after you perform an in-place upgrade to Windows Server 2008 R2 -
    http://support.microsoft.com/kb/974625 

    Important note: If you do not have Windows Server 2008 (i.e. you went from Windows 2000 or Windows Server 2003 straight to Windows Server 2008 R2), you do have downgrade rights. See this website on how to get product keys and media for R2:

    http://www.microsoft.com/windowsserver2008/en/us/downgrade-rights.aspx

    Perhaps the onslaught of emails about this can now subside... :-)

    - Ned "go go go" Pyle

  • Group Policy Slow Link Detection using Windows Vista and later

    Mike here again. Many Group Policy features rely on a well connected network for their success. However, not every connection is perfect or ideal; some connections are slow. The Group Policy infrastructure has always provided functionality to detect slow links. However, the means by which Group Policy determines this are different between operating systems prior to Windows Server 2008 and Windows Vista.

    Before Windows Server 2008 and Vista

    Windows Server 2003, Windows XP, and Windows 2000 Group Policy uses the ICMP protocol to determine a slow link between the Group Policy client and the domain controller. This process is documented in Microsoft Knowledgebase article 227260: How a slow link is detected for processing user profiles and Group Policy (http://support.microsoft.com/default.aspx?scid=kb;EN-US;227260).

    The Group Policy infrastructure performs a series of paired ICMP pings from the Group Policy client to the domain controller. The first ping contains a zero byte payload while the second ping contains a payload size of 2048 bytes. The results from both pings are computed and voila, we have the bandwidth estimation. However, using ICMP has some limitations.

    Many "not-so-nice" applications use ICMP maliciously. This new found use increased ICMP’s popularity forced IT professional to take precautions. These precautions included blocking ICMP. The solution to block ICMP provided relief from the susceptibility of malicious ICMP packets, but broke Group Policy. Workarounds were created (Microsoft Knowledgebase article 816045 Group Policies may not apply because of network ICMP policies); But the update did not remove the ICMP dependency.

    The Windows Server 2008 and Vista era

    Windows 7 and Windows Vista to the rescue! These new operating systems implement a new slow link detection mechanism that DOES NOT use ICMP-- but we already knew this. The question we will answer is how does the new Group Policy slow link detection work?

    The easy answer to how the new slow link detection works is Network Location Awareness (NLA). This networking layer service and programming interface allows applications, like Group Policy, to solicit networking information from the network adapters in a computer, rather than implementing their own methods and algorithms. NLA accomplishes this by monitoring the existing traffic of a specific network interface. This provided two important benefits: 1) it does not require any additional network traffic to accomplish its bandwidth estimate-- no network overhead, and 2) it does not use ICMP.

    Group Policy using NLA

    The question commonly asked is how does Group Policy slow link detection implement NLA. The actual algorithms used by NLA are not as important as what Group Policy does during its request to NLA for bandwidth estimation.

    Locate a domain controller

    A Group Policy client requires communication with a domain controller to successfully apply Group Policy. The Group Policy service must discover a domain controller. The service accomplishes this by using the DCLocator service. Windows clients typically have already discovered a domain controller prior to Group Policy application. DCLocator caches this information makes it available to other applications and services. The Group Policy service makes three attempts to contact a domain controller, with the first attempt using the domain controller information stored in the cache. The latter two attempts force DCLocator to rediscover domain controller information. Retrieving cached domain controller information does not traverse the network, but forceful rediscovery does. Domain controller information includes the IP address of the domain controller. The Group Policy service uses the IP address of the domain controller (received from DCLocator) to begin bandwidth estimation.

    During bandwidth estimation

    The Group Policy service begins bandwidth estimation after it successfully locates a domain controller. Domain controller location includes the IP address of the domain controller. The Group Policy service performs the following actions during bandwidth estimation.

    NOTE: All actions listed in this section generate network traffic from the client to the domain controller unless otherwise noted. I've included a few actions that do not generate network traffic because their results could be accomplished using methods that generate network traffic. These actions are added for clarity.

    Authentication

    The first action performed during bandwidth estimation is an authenticated LDAP connect and bind to the domain controller returned during the DCLocator process. This connection to the domain controller is done under the user's security context and uses Kerberos for authentication. This connection does not support using NTLM. Therefore, this authentication sequence must succeed using Kerberos for Group Policy to continue to process. Once successful, the Group Policy service closes the LDAP connection.

    NOTE: The user's security context is relative to the type of Group Policy processing. The security context for computer Group Policy processing is the computer. The security context for the user is the current user for the current session.

    The Group Policy service makes an authenticated LDAP connection as the computer when user policy processing is configured in loopback-replace mode.

    Determine network name

    The Group Policy services then determines the network name. The service accomplishes this by using IPHelper APIs to determine the best network interface in which to communicate with the IP address of the domain controller. The action also uses Winsock APIs; however, this action does not create any network traffic. Additionally, the domain controller and network name are saved in the client computer's registry for future use.

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History is where the service stores these values. The value names are DCName and NetworkName.

    NOTE: The NetworkName registry value is used by the Windows firewall to determine if it should load the domain firewall profile.

    Site query

    Group Policy processing must know the site to which the computer belongs. To accomplish this, the Group Policy service uses the Netlogon service. Client site discovery is an RPC call from the client computer to a domain controller. The client netlogon service internally caches the computer's site name. The time-to-live (TTL) for the site name cache is five minutes. However, TTL expiry is on demand. This means the client only checks the TTL during client discovery. This check is implemented by Netlogon (not the Group Policy service). If the cached name is older than five minutes from when the name was last retrieved from the domain controller, then the Netlogon service makes an RPC call to the domain controller to discover the computer site. This explains why you may not see the RPC call during Group Policy processing. However, the opportunity for network traffic exists.

    Determine scope of management

    The following Group Policy actions vary based on Group Policy processing mode. Computer Group Policy processing only uses normal Group Policy processing. However, user Group Policy processing can use normal, loopback-merge, and loopback-replace modes.

    Normal mode

    Normal Group Policy processing is the most common Group Policy processing actions. Conceptually these work the same regardless of user or computer. The most significant difference is the distinguished name used by the Group Policy service.

    Building the OU and domain list

    The Group Policy service uses the distinguished name of the computer or user to determine the list of OUs and the domain it must search for group policy objects. The Group Policy service builds this list by analyzing the distinguished name from left to right. The service scans the name looking for each instance of OU= in the name. The service then copies the distinguished name to a list, which it uses later. The Group Policy service continues to scan the distinguished name until for OUs until it encounters the first instance of DC=. At this point, the Group Policy service has found the domain name, which completes the list. This action does not generate any network traffic.

    Example: Here is the list from a given distinguished name

    Distinguished Name:
                cn=user,OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
    List:
                OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
                OU=hq,DC=na,DC=contoso,DC=com
                DC=na,DC=contoso,DC=com

    Evaluate scope of management

    The Group Policy service uses the list OUs to determine the Group Policy objects linked to each scope of management and the options associated with each link. The service determines linked Group Policy objects by using a single LDAP query to the domain controller discovered earlier.

    LDAP requests have four main components: base, scope, filter, and attributes. The base is used to specify the location within the directory the search should begin, which is usually represented as a distinguished name. The scope determines how far the search should traverse into the directory; starting from the base. The options include base, one-level, and subtree. The base scope option limits the search to only return objects matching the filter that matches the base. The onelevel option return objects from one level below the base, but not including the base. The subtree option returns objects from the base and all levels below the base. The filter provides a way to control what objects the search should return (see MSDN for more information on LDAP search filter syntax). The attribute setting is a list of attributes the search should return for the objects discovered that match the filter.

    The service builds the LDAP request with the following arguments:

    BaseDN:  domain
    Scope: Sub Tree
    Filter: (|(distinguishedname=OU=xxx)( more OUs)(ends domainNC DC=))
    Attributes: gpLink, gpOptions, ntSecurityDescriptor

    Example:  Scope of management LDAP search
           BaseDN: DC=na,DC=contoso,DC=com
           Scope: SubTree
           Filter: (|(distinguishedname= OU=marketing,OU=hq,DC=na,DC=contoso,DC=com)
                   (distinguishedname =OU=hq,DC=na,DC=contoso,DC=com)
                   (distinguishedname =DC=na,DC=contoso,DC=com))
        Attributes:gPlink,gPoptions,nTSecurityDescriptor

    Determining the scope of normal Group Policy processing mode occurs in the security context of the applying security principal. The computer performs the LDAP query computer processing and the user performs the LDAP query for user processing. Merge and Replace are user-only processing modes, which occur under the security context of the user.

    Replace user-processing performs an LDAP query using the computer’s distinguished name. Each component of the distinguished name is inserted into the filter portion of the LDAP query. The LDAP query filter parameter ends with the distinguished name of the domain (which is assembled using the parts of the computer’s distinguished name.

    Merge user-processing performs two LDAP queries. The first LDAP query uses the distinguished name of the user object. The second query uses the distinguished name of the computer object. The Group Policy links returned from both queries are merged into one list. The Group Policy service merges these lists together by adding the Group Policy links returned from the computer query to the end of the list of Group Policy links returned from the user query. Concatenating the computer list to the end of the user list results with the Group Policy links listed in the order they apply.

    Determine the Link Status:

    The Group Policy service is ready to determine the status of the link between the client computer and the domain controller. The service asks NLA to report the estimated bandwidth it measured while earlier Group Policy actions occurred. The Group Policy service compares the value returned by NLA to the GroupPolicyMinTransferRate named value stored in HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon, which is the preference key or, HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System, which is the policy key. The default minimum transfer rate to measure Group Policy slow link is 500 (Kbps). The link between the domain controller and the client is slow if the estimated bandwidth returned by NLA is lower than the value stored in the registry. The policy value has precedence over the preference value if both values appear in the registry. After successfully determining the link state (fast or slow—no errors), then the Group Policy service writes the slow link status into the Group Policy history, which is stored in the registry. The named value is IsSlowLink and is located at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History. This value is an REG_DWORD value that is interpreted as a Boolean value; with a non-zero value equaling false and a zero value equaling true. If the Group Policy service encounters an error, it read the last recorded value from the history key and uses that true or false value for the slow link status.

    Conclusion

    Group Policy slow link detection has matured since the days of using ICMP for slow link detection. Today, Windows 7 and Windows Vista’s Group Policy services use NLA to sample TCP communication between the client and the domain controller, without sending additional network traffic.

    - Mike “Huuuh, whaaaa?” Stephens