Ask the Directory Services Team

Group Policy Preferences Logging and Windows 7

mstephen — Thu, 19 Nov 2009 22:26:00 GMT

Hi all, Mike here again. Back in July of 2007, I posted a blog explaining how to enable Group Policy Preferences debug logging using RSAT. As a refresher, Group Policy Preferences debug logging is enabled through Group Policy administrative templates. Many customers experienced a problem when trying to enable the logging using RSAT and Windows Vista: the policy settings did not exist. You’ll experience the same behavior when using Windows 7 RSAT.

Figure 1 Windows 7 RSAT View

The Group Policy Preferences administrative template is not included with Windows 7; however, it is included in Windows Server 2008 R2. The simply solution is copy the ADMX and ADML files from Windows Server 2008 R2 to the Windows 7 computer. Or, you can copy the files from this blog post. The procedure remains the same as it was from Windows Vista. Check out the blog from July 2007 for the detailed procedures.

Figure 2 Windows 2008 R2 GPMC view

Note: There are some subtle differences between the Vista and Windows 7 Group Policy Preferences administrative templates—no change in functionality—but many string names have changed in the ADL file. Do not try to mix and match the ADMX from one version of Windows with the ADML of another.

Mike “Neebler-Treehouse builder” Stephens

Get a 90 day trial copy of Windows 7 Enterprise

NedPyle — Wed, 18 Nov 2009 22:37:00 GMT

Still not sure about taking the Windows 7 plunge in your company? Get a fully functional 90-day evaluation copy here.

Guidelines on usage:

Protect your PC and data. Be sure to back up your data and please don’t test Windows 7 on your primary home or business PC.
You have 10 days to activate the product. If not activated within 10 days, the system will shut down once every hour until activated. Unsure on how to activate? Visit our FAQ.
The 90-day Trial is the full working version of the Windows 7 Enterprise, the version most of you will be working with in your corporate environment. It will not require a product key (it is embedded with the download).
The 90-day Trial will shut down once every hour when you have reached the end of the 90-day evaluation period.
The 90-day Trial is offered for a limited time and in limited quantity. The download will be available through March 31, 2010, while supplies last.
After the 90-day Trial expires, if you wish to continue to use Windows 7 Enterprise, please note that you will be required to purchase and perform a clean installation of Windows 7, including drivers and applications. Please keep this in mind; Windows 7 Enterprise is not available through retail channels.
Technical details/updates/questions: Please review our FAQ or visit the Windows 7 support forum.
Stay informed. You can keep up with general technical information and news by following the Springboard Series blog. Want technical guidance, tips, and tools? Visit the Springboard Series on TechNet.
Keep your PC updated: Be sure to turn on automatic updates in Windows Update in case we publish updates for the 90-day Trial.
Microsoft Partners-: Learn more about Windows 7 on the Microsoft Partner Portal.

Still not sure after that? Seek medical attention, there's something wrong with you.

Ned "get some!" Pyle

Implementing Content Freshness protection in DFSR

NedPyle — Wed, 18 Nov 2009 21:33:00 GMT

Hi all, Ned here again. Starting in Windows Server 2008 and continuing in Windows Server 2008 R2, DFSR supports a protective mechanism called “Content Freshness”. Today I’ll discuss this protection, how to implement it, and what to do when it swings into operation.

Background

Content Freshness is an admin-defined setting that you can set on a per-computer basis when using DFSR on Win2008 or Win2008 R2 – it does not exist on Windows Server 2003 R2. The DFSR database has a record for each Replicated Folder (RF) called CONTENT_SET_RECORD. This record contains a timestamp called “LastConnected”. We store this record on a per-Replicated-Folder basis because it’s possible for a replicated folder to be current when it’s connected to other members in that replication group. At the same time, another replicated folder can be stale because it is not connected with other members in its replication group. Every day, DFSR updates this timestamp to show the opportunity for replication occurred. When attempting replication for an RF between computers, the DFSR service checks if the last time replication was allowed is older than the freshness date. If the last-allowed-replicated date is older, it replicates. If it’s not, we block replication.

By now, you’re asking yourself “why would I want to block replication.” Good question. DFSR has a JET database just like Active Directory, and it uses multi-master replication just like AD. This means that it must implement tombstones to deleted items to replicate. When a file is deleted in DFSR, the local database records the deletion as a tombstone in the database – a logical deletion. After 60 days DFSR garbage collects the record from the database and it is truly gone – a physical deletion. Online defragmentation of the database can now reclaim that whitespace. The 60 days allows all the replication partners to learn about the deletion and act on it.

And herein lays the problem. If a DFSR server cannot replicate an RF for more than 60 days, but then replication is allowed later, it can replicate out old deletions for files that are actually live or replicate out stale data and overwrite existing files. If you’ve ever worked on an Active Directory “lingering object” issue, you have seen what can happen when a DC that was offline for months is brought back up. This is why Strict Replication Consistency was invented for AD – Content Freshness protection is the same thing.

Being “unable to replicate” can mean any one of these scenarios:

Disabling the replication connections.
Deleting the replication connections (either one-way or in both directions).
Stopping the DFSR service.
Closing the schedule (i.e. setting “no replication”)
Keeping the server shut off.

This whole content freshness idea is novel enough that we went to the trouble of applying for a patent on it.

Implementing Content Freshness Protection

Content Freshness protection is not enabled by default. To turn it on you simply modify the DfsrMachineConfig setting for MaxOfflineTimeInDays on each DFSR server with:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=<some value>

The recommendation is to set the value to 60:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=60

Remember, this has to be done on all DFSR servers, as this change only affects the computer itself. This value is not stored in a central AD location, but instead in the DfsrMachineConfig.XML file that resides in the hidden operating system folder “%systemdrive%\system volume information\dfsr\config”:

You can also view your existing MaxOfflineTimeInDays with:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

Remember, by default this protection is OFF and be assumed to be zero if there are no entries in the DfsrMachineConfig.xml.

Note: Sharp-eyed admins may notice that we actually have an AD attribute stamped on every Replication Group called

ms-DFSR-TombstoneExpiryInMin that appears to control tombstone lifetime. It even has the value - in minutes - for 60 days. Sorry to disappoint you, but this attribute is never read by DFSR and changing it has no effect – tombstone lifetime garbage collection is always hard-coded to 60 days in the service and cannot be changed.

Protection in Action

Let’s see how all this works. My repro environment:

A pair of Windows Server 2008 R2 computers named 2008r2-fresh-01 and 2008r2-fresh-02
Replicating in a Replication Group named “RG1”
Using a Replicated Folder named “RF1”
Keeping a few user files in sync.
MaxOfflineTimeInDays set to 60 on 2008r2-fresh-02

Important note: I am going to simulate the offline time by rolling clocks forward. Never ever do this in production – this is for testing and demonstration purposes only. Also, I only set MaxOfflineTimeInDays on one server – you would do this on all servers.

So here’s my data:

Now I stop DFSR on 2008r2-fresh-02 and roll time forward to January 1^st, 2010 on both servers - about 75 days from this writing. I then make a few changes on 2008r2-fresh-02.

And then I start the DFSR service back up on 2008r2-fresh-02.

My changed files do not replicate out
New files do not replicate in

I now have this event:

Log Name:      DFS Replication
Source:        DFSR
Date:          1/1/2010 3:37:14 PM
Event ID:      4012
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      2008r2-fresh-02.blueyonderairlines.com
Description:
The DFS Replication service stopped replication on the replicated folder at local path c:\rf1. It has been disconnected from other partners for 76 days, which is longer than the MaxOfflineTimeInDays parameter. Because of this, DFS Replication considers this data to be stale, and will replace it with data from other members of the replication group during the next replication. DFS Replication will move the stale files to the local Conflict folder. No user action is required.
Additional Information:
Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: rf1
Replicated Folder ID: 5856C18F-CA72-4D2D-9D89-4CC1D8042D86
Replication Group Name: rg1
Replication Group ID: BC5976EF-997E-4149-819D-57193F21EC76
Member ID: FAEC4B17-E81F-4036-AAD9-78AA46814606

Note: this event has incorrect wording. The first two sentences in the description are good, but the following sentences are wrong. DFSR does not self-correct this situation, it does not move files into the ConflictAndDeleted folder, and you, the user, have actions you need to take. More on this later.

The DFSR Debug logs will show (edited for brevity):

20100101 15:37:14.410 1008 CSMG 5504 [WARN] ContentSetManager::CheckContentSetState This replicated folder has not connected to other partners for a long time. lastOnlineTime: [*** Logger Runtime Error:-114757888 ***]

20100101 15:37:14.410 1008 CSMG 7492 [ERROR] ContentSetManager::Initialize Failed to initialize ContentSetManager csId:{5856C18F-CA72-4D2D-9D89-4CC1D8042D86} csName:rf1 Error:

+ [Error:9061(0x2365) ContentSetManager::CheckContentSetState contentsetmanager.cpp:5596 1008 C The replicated folder has been offline for too long.]

20100101 15:37:14.410 1008 CSMG 7972 ContentSetManager::Run csId:{5856C18F-CA72-4D2D-9D89-4CC1D8042D86} csName:rf1 state:InitialBuilding

20100101 15:37:14.504 1948 SRTR 957 [WARN] SERVER_EstablishSession Failed to establish a replicated folder session. connId:{5E05AE2A-6117-4206-B745-7785DB316F74} csId:{5856C18F-CA72-4D2D-9D89-4CC1D8042D86} Error:

+ [Error:9028(0x2344) UpstreamTransport::EstablishSession upstreamtransport.cpp:808 1948 C The content set was not found]

The state of the replicated folder will be “In Error” – i.e. set to 5:

wmic.exe /namespace:\\root\microsoftdfs path DfsrReplicatedFolderInfo get ReplicationGroupName,ReplicatedFolderName,State

ReplicatedFolderName ReplicationGroupName State
rf1 rg1 5

The above is Content Freshness protection in action. It is protecting your DFSR environment from sending divergent data out to the rest of your working servers.

Recovering DFSR from Content Protection

Important note: Before repairing the blocked replication, get a backup of the data on the affected server and its partners. Failure to do will tempt Murphy's Law to disastrous new heights. Understand that by following these steps below, any DFSR data that was on this server and never replicated will be moved to PreExisting and/or ConflictAndDeleted - this server goes through non-authoritative sync again and loses all conflicts with other DFSR servers. You have been warned!!!

Also, whatever is being done to stop replication from working needs to be ironed out - whether it is leaving the service off for months on end or not having any connections. Otherwise this is just going to happen again.

To get things back in order, do the following:

1. Start DFSMGMT.MSC on the affected server.

2. On any affected replication groups this server is a member of, select the computer on the Membership tab and "Disable" it.

3. Accept the warning prompt.

4. If the reason for replication never occurring was the schedule being set to "no replication" on the RG or RF, or no bi-directional connections being place between servers, fix that situation now.

5. Force AD Replication and verify it has converged.

6. On the affected server, run:

DFSRADMIN.EXE POLLAD

7. Wait for the 4008 and 4114 events being written to the DFSR event log to confirm that the replicated folder(s) are no longer being replicated.

8. In DFSMGMT.MSC, "Enable" the replication again on the affected replicated folders for that server.

9. Force AD replication and POLLAD again.

The server goes through non-authoritative initial sync, as if it was setup the first time. All matching data is unchanged and does not replicate. Any files on the server that do not exist on its authoritative partner are moved to the PreExisting folder. Any files on the server that have been changed locally are moved to the ConflictAndDeleted folder and the authoritative server's copy is replicated inbound.

The Sum Up

Content Freshness protection is a good thing and putting it in place may someday save you some real pain. Trust me – we work cases here where Content Freshness being enabled would have stopped huge problems. All it takes is Windows Server 2008 or later, and a few moments of your time.

- Ned “Kool and the Gang” Pyle

I Hate Mondays

NedPyle — Mon, 16 Nov 2009 18:04:57 GMT

The lesson here is if you go on vacation for a week, make sure your boss is gone too. Otherwise he will do this to your cubicle:

Which just goes to show how important a manager’s time really is, of course. Ah well, at least I got some cookies.

I hate you Mike.

- Ned “Neebler Elf” Pyle

New Directory Services KB Articles/Blogs 10/25-10/31

Craig — Wed, 04 Nov 2009 16:03:59 GMT

975830	The memory usage of the Dns.exe process keeps increasing after you install hotfix 941672 on a computer that is running Windows Server 2003 SP2 and that has the DNS server role installed
972622	The Active Directory Application Mode index may become corrupted if you search the instance by using the LDAP virtual list view control
975792	Numeric host names cannot be resolved on a computer that is running Windows Vista or Windows Server 2008
969371	Error message when you run a command at the Command Prompt window in Windows Server 2008 Server Core: "The specified service does not exist as an installed Service"
975943	Error code when an application uses the CredSSP if the authenticated user account is a member of many security groups on a computer that is running Windows Vista or Windows Server 2008: "0x80090329"
976921	A DFSR propagation report logs the following error on a Windows Server 2008 domain controller: "Cannot open test file on the member The network path was not found."
976922	The "Run only allowed Windows applications" Group Policy setting displays no entries on a computer that is running Windows Vista, Windows Server 2008, or Windows 7
968929	Description of the Windows Management Framework on Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008
974522	A LDAP simple bind action fails on a domain controller that is running Windows Server 2008 if the distinguished name of the user account exceeds 256 characters
976427	Computers that are running Windows 7 or Windows Server 2008 R2 stop responding at a black screen if a screen saver is enabled
977110	How to select time zone for countries or regions that are not listed in Windows time zone list

Blogs

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

DFS Referrals and IPv6: Outta site!

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

Using ADMT 3.1 to migrate to Windows Server 2008 R2 domains

Learn more about system image backup

Quick, Dirty, Super-Useful Scripting

Remote Desktop Load Simulation Toolset

DNSSEC Security Guide – update now available

Free MS Press ebook: Introducing Windows Server 2008 R2

Snapshot recovery tool strikes back

Cross post: Terminal Server 2003 issues with Group Policy Preferences History Folder

Announcing the availability of Remote Desktop Connection 7.0 for Windows XP SP3, Windows Vista SP1, and Windows Vista SP2

Update: Free P2V tool: Disk2Vhd.exe – Command line support

Cool new tool for comparing IE Zone Security Settings

Powershell v2 is yours!

Windows Management Framework is here!

New DirectAccess documentation is now available

Optional configuration for the DFS Replication Management Pack

Windows 7 - Do I need to change my Active Directory for new Group Policy features?

Configuring the DFS Replication Management Pack

Scalable Networking Pack revisited for 2008

Auditing Password and Account Lockout Policy on Windows Server 2008 and R2

NedPyle — Mon, 02 Nov 2009 18:13:39 GMT

Ned here again. Let’s talk about auditing your domain for changes made to Password and Account Lockout policies. Frankly, it’s a real pain in the neck to figure out Password and Account Lockout auditing and there are legacy architectural decisions behind how this all works, so I’ll make sure to cover all the bases. This also includes auditing your Fine Grain Password policies (FGPP), for you bleeding-edge types.

Understanding how these policies work

We use Password and Account Lockout policies to control domain authentication. Password policies set requirements for things like password length, complexity, and maximum age. Account Lockout policies control lockout threshold and duration, and are very popular with The Devil.

There are two types of Password and Account Lockout policies in a domain:

Domain-wide – Introduced in Windows NT and set in Active Directory through domain security policy.
Fine Grained – Introduced in Windows Server 2008 and set in AD through manual means like ADSIEDIT or AD PowerShell. It configures settings on a user or group-membership basis, and there can be as many as you like.

Domain-based policy, while being set through security policy, is actually written to attributes on the root of the domain. ADSIEdit shows this object using the distinguished name of the domain name. This odd location results from providing NT 4.0 compatibility. Since NT 4.0 could not apply group policy, we had to store these values somewhere and answer requests about the settings in an NT fashion.

On the other hand, Fine Grained policies write to their own location. Windows stores each policy as a leaf object.

When you edit your built-in Default Domain password policy, you are actually editing:

\\contoso.com\sysvol\contoso.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

All your settings are in this format:

[System Access]
MinimumPasswordAge = 0
MaximumPasswordAge = 60
MinimumPasswordLength = 8
PasswordComplexity = 1
PasswordHistorySize = 4
LockoutBadCount = 50
ResetLockoutCount = 30
LockoutDuration = 30
RequireLogonToChangePassword = 0
ForceLogoffWhenHourExpire = 0
ClearTextPassword = 0
LSAAnonymousNameLookup = 0

When DC applies this security policy during the five minute group policy refresh, the DC stamps these settings on the domainDNS object. And voila, you have your policies in place. But think about that – the DC stamps these settings in place when applying computer policy. Who do you think will be listed as the user in your audit event logs? That’s right – the DC itself. And that’s where this blog post comes in. :-)

Auditing Domain-Wide Policy

There are three main things you need to do to see domain-wide password and account lockout setting changes, but they differ slightly by OS:

1. Put an auditing entry on the “Policies” container. Enabling auditing for EVERYONE on the “CN=Policies,CN=System,DC=<your domain>” container causes auditing to track all writes, deletes, and permission modifications. The audit event shows the user modifying group policy in general. Obviously, this is useful for more than just password policy changes – “Hey, who set this policy to push a Domo-Kun wallpaper out to all the computers?”

2. Enable subcategory auditing for:

    a. “Authentication Policy Change” (if using Windows Server 2008 R2 DC’s).

    b. “Other Account Management Events” (if using Windows Server 2008 DC’s).

3. Enable subcategory auditing for “Directory Service Changes”.

    Note: In Windows Server 2008 R2, granular subcategory auditing is available through GPMC.

In Windows Server 2008, you need to use the script provided in KB921469.

After enabling auditing, Windows then generates security audit events for anyone editing domain-wide security policy for passwords and account lockouts:

1.    An event 5136 will be written that shows the versionNumber attribute of the policy being raised:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 3:04:17 PM
Event ID:      5136
Task Category: Directory Service Changes
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
A directory service object was modified.
Subject:
    Security ID:        CONTOSO\Administrator
    Account Name:        Administrator
    Account Domain:        CONTOSO
    Logon ID:        0x1e936

Directory Service:
    Name:    contoso.com
    Type:    Active Directory Domain Services
Object:
    DN:    CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=POLICIES,CN=SYSTEM,DC=CONTOSO,DC=COM
    GUID:    CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=contoso,DC=com
    Class:    groupPolicyContainer
Attribute:
    LDAP Display Name:    versionNumber
    Syntax (OID):    2.5.5.9
    Value:    121

Note: The event ID shows the name of the user that modified the policy – every policy edit raises the version number. Now we know to go look at the policy and that someone changed it.

2. Windows writes a follow-up event (event id 4739) for each type of change – lockout policy or password policy. For example:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 3:01:28 PM
Event ID:      4739
Task Category: Authentication Policy Change
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
Domain Policy was changed.

Change Type:        Lockout Policy modified

Subject:
    Security ID:        SYSTEM
    Account Name:        2008R2-F-01$
    Account Domain:        CONTOSO
    Logon ID:        0x3e7

Domain:
    Domain Name:        CONTOSO
    Domain ID:        CONTOSO\

Changed Attributes:
    Min. Password Age:    -
    Max. Password Age:    -
    Force Logoff:        -
    Lockout Threshold:    500
    Lockout Observation Window:
    Lockout Duration:
    Password Properties:
    Min. Password Length:
    Password History Length:
    Machine Account Quota:
    Mixed Domain Mode:
    Domain Behavior Version:
    OEM Information:    -

====

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 3:04:23 PM
Event ID:      4739
Task Category: Authentication Policy Change
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
Domain Policy was changed.

Change Type:        Password Policy modified

Subject:
    Security ID:        SYSTEM
    Account Name:        2008R2-F-01$
    Account Domain:        CONTOSO
    Logon ID:        0x3e7

Domain:
    Domain Name:        CONTOSO
    Domain ID:        CONTOSO\

Changed Attributes:
    Min. Password Age:    -
    Max. Password Age:    -
    Force Logoff:        -
    Lockout Threshold:    -
    Lockout Observation Window:    -
    Lockout Duration:    -
    Password Properties:    -
    Min. Password Length:    5
    Password History Length:    -
    Machine Account Quota:    -
    Mixed Domain Mode:    -
    Domain Behavior Version:    -
    OEM Information:    -

Notice the account name is the DC itself. This event, while useful, needs to be correlated with the 5136 event to see what changed. And even then, these events can sometimes be difficult to understand – what is a “password property” after all? (it’s for complexity being turned on or off). You should probably use these events as a notification to go examine the actual policies in GPMC.

You’re probably asking yourself why I didn’t just audit the actual domain root object and skip using the “Authentication Policy Change” and “Other Account Management Events”. This is another of the vagaries of security policy auditing – it doesn’t work. Simply auditing the “DC=domain,DC=com” object does not return any information about password or lockout changes. Go figure.

Auditing Fine-Grained Policy

Auditing FGPP is simpler and the data is easier to read. FGPP does not contain intermediate security policy settings. Creating and modifying these policies directly edits the objects in Active Directory. You can create or modify FGPP using PowerShell, LDP, LDIFDE, or ADSIEDIT. This means there’s no layer between doing work on your behalf. Also, your audit events are clean and self-evident.

1. Put an auditing entry on the “Password Settings Container” container. Enabling auditing for EVERYONE on the “CN=Password Settings Container,CN=System,DC=<your domain>” object causes Windows to track all users who write, delete, and modify permissions on any FGPPs.

2. Enable subcategory auditing for “Directory Service Changes” (see previous section for steps).

After enabling auditing, Windows generates a security audit event for anyone editing FGPPs for each change made. Also, the audit event includes the new value and the value prior to the change:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 4:20:54 PM
Event ID:      5136
Task Category: Directory Service Changes
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
A directory service object was modified.
Subject:
    Security ID:        CONTOSO\RobGreene
    Account Name:        RobGreene
    Account Domain:        CONTOSO
    Logon ID:        0x1e936

Directory Service:
    Name:    contoso.com
    Type:    Active Directory Domain Services
Object:
    DN:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
    GUID:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
    Class:    msDS-PasswordSettings
Attribute:
    LDAP Display Name:    msDS-PasswordComplexityEnabled
    Syntax (OID):    2.5.5.8
    Value:    TRUE
Operation:
    Type:    Value Deleted
    Correlation ID:    {6afa8930-85cd-44d9-828b-9cc3c1b5a8b9}
    Application Correlation ID:    -

===

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          10/24/2009 4:20:54 PM
Event ID:      5136
Task Category: Directory Service Changes
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      2008r2-f-01.contoso.com
Description:
A directory service object was modified.
Subject:
    Security ID:        CONTOSO\RobGreene
    Account Name:        RobGreene
    Account Domain:        CONTOSO
    Logon ID:        0x1e936

Directory Service:
    Name:    contoso.com
    Type:    Active Directory Domain Services
Object:
    DN:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
    GUID:    CN=VIP DomainUsersPSO,CN=Password Settings Container,CN=System,DC=contoso,DC=com
    Class:    msDS-PasswordSettings
Attribute:
    LDAP Display Name:    msDS-PasswordComplexityEnabled
    Syntax (OID):    2.5.5.8
    Value:    FALSE
Operation:
    Type:    Value Added
    Correlation ID:    {6afa8930-85cd-44d9-828b-9cc3c1b5a8b9}
    Application Correlation ID:    -

Here I can see the user RobGreene logged on and changed the password complexity requirements from TRUE to FALSE. I knew it! Rob Greene, always breaking my stuff…

See Edie, I told you I’d write a blog post on this. :-)

- Ned “the chiropractor” Pyle

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

Craig — Fri, 30 Oct 2009 19:21:43 GMT

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

NedPyle — Thu, 29 Oct 2009 21:38:00 GMT

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

NedPyle — Thu, 29 Oct 2009 13:32:26 GMT

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!

NedPyle — Wed, 28 Oct 2009 13:33:11 GMT

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 1^st 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 two solutions for this:

I. The preferred method is to 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

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

NedPyle — Tue, 27 Oct 2009 15:34:00 GMT

Hey all. 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

NedPyle — Tue, 27 Oct 2009 15:29:30 GMT

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.

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

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

NedPyle — Mon, 26 Oct 2009 13:52:00 GMT

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

NedPyle — Fri, 23 Oct 2009 15:13:31 GMT

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

Come and get it

NedPyle — Thu, 22 Oct 2009 22:20:00 GMT

Windows 7 and Windows Server 2008 R2 reached general availability today.

The line in our site’s company store was out the door, but we were able to snag some for this nice picture taken from a new Windows Mobile phone. Yeah, I went there too.

Win7 and R2 Beta have been my fulltime job since October 2008 and it's been the most fun I've ever had as a Microsoft employee. I hope you enjoy using it as much as I enjoyed breaking it.

- Ned “The Shill” Pyle