Blog - Title

December, 2009

  • Windows 7, Windows Server 2008 R2 and the Group Policy Central Store

    Mike here again to help bring clarity to something we are seeing with Windows Server 2008 R2 and existing Group Policy central store. Before that discussion, let us cover some background information.

    ADMX Files and the Group Policy Central Store

    Microsoft introduced the ADMX file format with Windows Vista and Windows Server 2008. This XML-based file format replaced the token-based ADM file format used by earlier versions of Windows to define administrative templates. Group Policy uses administrative templates to represent registry-based policy settings that appear when editing Group Policy. The content included in administrative templates describes the user interface used by Group Policy editors and registry locations where Windows stores policy settings. Windows Server 2008 R2 and Windows 7 provide a new set of administrative template files in the ADMX format.

    Windows 7 ADMX files now include support for two registry types: REG_MULTI_SZ and REG_QWORD. The REG_MULTI_SZ registry data type represents multi strings entries within a single registry value. The REG_QWORD registry data type represents a 64-bit number, which is twice the size of the 32-bit number stored in REG_DWORD. These new aspects of the ADMX syntax are only viewable when using the GPMC and Group Policy editors from Windows Server 2008 R2 or Windows 7 Remote Server Administration Tools (RSAT). Group Policy editors and the GPMC from Windows Vista cannot read ADMX files containing this new syntax.

    The Central Store

    Earlier versions of Group Policy that used ADM files suffered from a symptom known as SYSVOL bloat. These versions of Windows copied the set of ADM files into each Group Policy object stored on SYSVOL. Each set of ADM files required approximately 4MB of disk space. A domain can realistically have 100 Group Policy objects. One hundred Group Policy objects multiplied by 4 megabytes of disk space equates to 400MB of redundant data—what a waste. Windows Server 2008 and Vista introduced the concept of the Group Policy Central Store to overcome SYSVOL bloat. The Group Policy Central Store is a single folder on each domain controllers SYSVOL that stores one set of ADMX files for the entire domain. The central store effectively relieves the symptoms of SYSVOL bloat and reduces the amount of data transferred during SYSVOL replication when new Group Policy objects are created. Some documentation refers to the Group Policy Central Store as an alternate location to store ADMX files (the other location is the local store found in %SYSTEMROOT%\PolicyDefinitions). A more accurate description of the Central Store is the preferred location.

    So what’s the Problem?

    The Group Policy Management Console and the Group Policy Management Editor always use the Group Policy Central store, when it is present. The pro here is that all instances of the GPMC and GPME use the same set of ADMX files. The con is that servicing ADMX files is difficult. Also, GPMC cannot use the local store as long as a Group Policy Central Store exists. So adding a single ADMX set for a single computer is not possible when using a central store. So, when we released Windows 7 and Windows Server 2008 R2, we also released a new set of ADMX files (within the operating system). These new ADMX files expose new Windows 7 and Windows 2008 R2 policy settings as well as policy settings for previous operating systems. Therefore, you need these files to configure Windows 7 Group Policies. Here’s where the dilemma continues.

    A Central Store and Windows 7

    If you have a central store (presumably hosted with Windows Server 2008 ADMX files), then you have two choices: upgrade the ADMX files or remove the central store.

    Updating the Central Store

    Updating the Central Store affects all users in the domain that use GPMC and its editor. It is important to understand this because newer ADMX files may not be compatible with older versions of Group Policy Tools, as in the case with Windows Server 2008 R2. The screen capture below occurs in Windows Vista and Windows Server 2008 computers attempting to read a Group Policy Central store hosted with Windows Server 2008 R2 ADMX files.

    image

    Windows Server 2008 R2 ADMX file, in this example the TerminalServer-Server.adml, contains an unknown element named <multiTextBox>. This element represents the REG_MULTI_SZ implementation that is new with Windows 7 and Windows Server 2008 R2. Newer ADMX files can contain new features, which older Group Policy Tools may not understand. This is why it is always a best practice to use the latest Group Policy Tools to manage Group Policy. Backwards compatibility is an important aspect of Group Policy; however, forward compatibility is not.

    Also, you may be using Windows 7, but do not see Windows 7 policy settings. Remember, GPMC prefers the Group Policy Central Store over the local store. The Windows 7 GPMC (actually RSAT) uses the Group Policy Central Store (hosted with Windows Vista or Windows Server 2008 ADMX files) over its local store that hosts the Windows 7 ADMX. If you want to see Windows 7 policy settings, then you’ll need to upgrade your central store or remove it.

    Note: I have successfully used Windows Vista RSAT with an upgraded Group Policy Central Store. However, the ADMX and ADML files were from a Windows 7 computer. Using Windows Server 2008 R2 ADMX files produces the error in the preceding image using GPMC from Windows Server 2008 or Windows Vista RSAT.

    image

    Removing the Group Policy Central Store

    Removing the Central Store targets all Group Policy tools to use their local store for ADMX file. This allows Windows 7 RSAT and Windows Server 2008 R2 computer to use their ADMX files. Windows Vista RSAT and Windows Server 2008 use their local ADMX files. Windows Vista computers cannot manage or report on Windows 7 policy settings.

    An Alternative to the Central Store

    There is way for us to “have our cake and eat it too”. The answer is Terminal Services. I often suggest to customers that have many people managing Group Policy to setup a GPMC Terminal Server. Dedicating a single server as the means to manage Group Policy provides:

    • The concept of a central store
    • A single point of Group Policy management
    • Easy to audit and maintain

    A dedicate Group Policy Terminal Server can provide the look and feel of a Group Policy Central Store without implementing a Central Store. ADMX files are located in one location, the terminal server. GPMC does not load the ADMX files from a network location. Domain controllers do not need to replicate the additional content of a Central Store—all the benefits of a Central Store, without creating one.

    Group Policy is a critical part of the enterprise and yet it seems little is done to reduce its exposure. A dedicated Terminal Server running GPMC provide a true single point of management for the entire Group Policy experience. Terminal Services security can be implemented to reduce the number of people having access to GPMC. Auditing interactive logons can further assist with identifying changes made to Group Policy. Combine this with using Group Policy to prevent other computers from opening GPMC and you’ve effectively lowered the surface and exposure to Group Policy to only the people that actually need it.

    Hopefully, this helps with understanding the pros and cons of using a Group Policy Central Store. Also, it should help with answer some of the common questions that arise regarding updating the central store or managing the latest Group Policy settings with Windows 7. And lastly, perhaps consolidating Group Policy Management to a Terminal Server will help limit access to Group Policy management to only the people that actually need it.

    Mike “He’s making a left turn” Stephens

  • Troubleshooting Credential Roaming

    Hi. Jim here again from Directory Services with a follow up to my Understanding Credential Roaming blog post. To review, credential roaming makes it possible to roam the user's credentials in a manageable, secure manner that is ultimately transparent to the user. What follows is a deeper dive into the inner workings of Credential Roaming. I will point out what must be setup initially and verified if you are planning to deploy Credential Roaming in your enterprise. Or you may have already deployed Credential Roaming and are interested in finding out what to check if your users report issues that would indicate their credentials are not roaming.

    Potential credential roaming problems can be broken down into three major areas:

    1. Initial setup requirements
    2. Client Side Problems
    3. Active Directory database size growth

    I will give you guidance on how to avoid some common problems with initial setup if you are currently planning to test and deploy credential roaming in your environment.

    To help with all the different things that have to be checked Rob Greene has created a vbscript data gathering tool that can be used in a user logon script or run as a “one off” on a workstation to collect this information for you about the users in your environment. Of course, this script is provided “as is” without any warranties and it is not supported by Microsoft. This script requires CAPICOM.DLL to be deployed and registered on all workstations. I have included the link to the CollectUserStore.vbs” script at the bottom of this post.

    Let’s begin now with the initial setup.

    Initial Setup

    In this section I will illustrate the preliminary steps that must be taken to prepare your environment for credential roaming. These steps must be taken prior to the deployment of the credential roaming group policy.

    If you are using Windows XP (pre-SP3) or Windows Server 2003 (Pre-SP2) you will need to deploy the latest credential roaming hotfixes to these operating systems before credential roaming will function properly. If you are using Windows Vista (pre-SP1) you must deploy SP1 or SP2 or you are unsupported. The following is the most recent Credential Roaming hotfix for XP at the time this blog was published:

    907247 - Description of the Credential Roaming service update for Windows Server 2003 and for Windows XP - http://support.microsoft.com/default.aspx?scid=kb;EN-US;907247

    and

    973502 The size of the Ntds.dit file becomes larger on one or more domain controllers that are running Windows Server 2003 or Windows Server 2008 after you enable the credential roaming feature for the domain - http://support.microsoft.com/default.aspx?scid=kb;EN-US;973502

    If your workstations and servers are running the latest versions of service packs then you only need install KB973502.

    If you “turn on” credential roaming by configuring and applying the credential roaming group policy before deploying the 907247 hotfix or XP service pack 3 to your environment, your users might enroll for new certificates when they logon to computers where the 907247 hotfix has not been installed. This will result in differences within the certificate stores between workstations that the user logs into.

    Before setting up credential roaming, one thing that we have found is that it’s best if you clean up unused user profiles from workstations and servers. If you are running Windows XP/2003 we recommend that you use DelProf.exe to clean up old or unused user profiles. This can be deployed via System Center or other management applications. If you do not have this ability you can use DelProf with a computer startup script. When a user starts to logon to multiple computers in the environment if they already have an existing profile on the computer they will start collecting old certificates and DPAPI master keys which will cause your Active Directory database size to grow. If you are using Windows Vista SP1 / 2008 or later there is a group policy setting that can be implemented in your environment that will delete older user profiles based on the number of days:

    image

    Computer Configuration\Policies\Administrative Templates\System\User Profiles\Delete user profiles older than a specified number of days on system restart

    Client Side Problems

    Profiles

    It is also necessary to determine if you are using roaming profiles or folder redirection in your environment. In a large enterprise with many administrators this could prove to be a daunting task. It will be necessary to modify these policies to configure an exclusion list in Group Policy for the roaming folders required for credential roaming.

    User Configuration\Administrative Templates\System\User Profiles\Exclude directories in roaming profile: Enabled

    Windows XP/2003:

    Application Data\Microsoft\Crypto
    Application Data\Microsoft\Protect
    Application Data\Microsoft\SystemCertificates

    Windows Vista and higher:

    AppData\Roaming\Microsoft\Credentials
    AppData\Roaming\Microsoft\Crypto
    AppData\Roaming\Microsoft\Protect
    AppData\Roaming\Microsoft\SystemCertificates

    The CollectUserStore.vbs script that is linked at the bottom of this post will detect if the folders have not been excluded as required and will report the following:

    User Profile type is: Roaming
    ERROR: You are not excluding the following directory from your roaming profile: Application Data\Microsoft\Crypto
    ERROR: You are not excluding the following directory from your roaming profile: Application Data\Microsoft\Protect
    ERROR: You are not excluding the following directory from your roaming profile: Application Data\Microsoft\SystemCertificates

    Credential roaming will not work properly when folder redirection has been enabled for “Application Data” when running Windows XP or Windows Server 2003. The user can face unexpected results if the previously mentioned folders are being redirected to file servers. This issue does not occur in Windows 7, Windows Server 2008 R2, Windows Vista, or Windows Server 2008. Folder redirection in these operating systems automatically excludes the listed folders.

    You can check the following locations in the registry on the client computer manually. This is where the aforementioned exclusion settings can be verified. You must check both locations below because the profile code merges the two locations.

    Standard registry location:

    HKEY_Current_User\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
    Value name: ExcludeProfileDirs
    Data type: REG_SZ

    Group Policy registry location:

    HKEY_Current_User\SOFTWARE\Policies\Microsoft\Windows\System
    Value name: ExcludeProfileDirs
    Data type: REG_SZ

    Verify the installation of the credential roaming DLL:

    Another thing to do prior to implementation is to validate the client side settings before applying the Credential Roaming group policy in test or production. If you have Windows XP or Windows Server 2003 clients you will want to make sure that DIMSNtfy.dll is listed under Winlogon in the registry as illustrated in Figure 1 below. In Windows Vista and later a new dll called dimsjob.dll replaces the dimsnotfy.dll. This new dimsjob.dll as well as dimsroam.dll and pautoenr.dll are loaded within the Task Engine Process as illustrated later.

    HKEY_Local_Machine\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\dimsntfy

    image

    The dimsntfy key exported –

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\dimsntfy
    "Asynchronous"=dword:00000001
    "DllName"=%SystemRoot%\system32\dimsntfy.dll”
    "Startup"="WlDimsStartup"
    "Shutdown"="WlDimsShutdown"
    "Logon"="WlDimsLogon"
    "Logoff"="WlDimsLogoff"
    "StartShell"="WlDimsStartShell"
    "Lock"="WlDimsLock"
    "Unlock"="WlDimsUnlock"

    We are looking for the existence and values for Winlogon Notification packages specifically the dimsntfy registry key and the values underneath it. If this key is missing, certificates are not being downloaded or uploaded from AD. It also means that the hotfix 907247 was not installed.

    The CollectUserStore.vbs script will look for the existence of the DLLName value.

    The error below will be displayed if the credential roaming hotfix has not been applied:

    ERROR: The Credential Roaming Hotfix has not been applied or is not registered with Winlogon

    On Vista and Windows 7 verify the scheduled task UserTask-Roam for credential roaming is in the ready status:

    clip_image002[1]

    Verify Group Policy settings are applied as a post configuration check –

    Verify that the group policy settings are being applied to the user. Right click - export the following registry keys while logged on as the user:

    HKEY_Current_User\Software\Policies\Microsoft\Cryptography\AutoEnrollment

    The screenshot below is what you should expect to see on a client machine if the credential roaming group policy settings have applied successfully.

    image

    The AutoEnrollmentkey exported –

    HKEY_CURRENT_USER\Software\Policies\Microsoft\Cryptography\AutoEnrollment
    "AEPolicy"=dword:00000007
    "DIMSRoaming"=dword:00000001
    "DIMSRoamingTombstoneDays"=dword:0000003c
    "DIMSRoamingMaxNumTokens"=dword:000007d0
    "DIMSRoamingMaxTokenSize"=dword:0000ffff

    After the client side settings have been validated you can begin issuing the Credential Roaming group policy to test computers and verify the policy is being applied successfully.

    NOTE: DIMSRoaming registry value might be a value of 0x9 if you have Windows Vista or higher and enabled Stored User name and password roaming. Here we are looking for the group policy keys being applied to the user.

    The “CollectUserStore.vbs” script will also collect this information:

    Credentials Roaming Group Policy Settings appear OK
    DIMSRoaming = 1
    DIMSRoamingMaxNumTokens = 2000
    DIMSRoamingMaxTokenSize = 65535
    DIMSRoamingTombstoneDays = 60

    Verify State.dat file creation:

    When credential roaming is enabled there are two files created on the client machine. As a post configuration task after Credential Roaming is configured you should verify that there is a state.dat and state.da~ files in the following directory:

    • Windows XP/2003: %USERPROFILE%\Local Settings\Application Data\Microsoft\DIMS
    • Windows Vista/2008: %LOCALAPPDATA%\Microsoft\DIMS

    NOTE: You have to make sure that you can see Hidden and System files. The State.dat file acts like a traffic cop between the client machine and AD. It reconciles the certificates that are present in the user certificate store with the information that is stored in Active Directory. We can verify the last roaming time stamp on the State.dat file which will be modified whenever the credential roaming series of events occur as explained here.

    Testing credential roaming:

    If you are testing credential roaming before deploying it throughout the environment you DO NOT delete the certificates using certmgr.msc or from Internet Explorer’s internet options - content - security – certificates menu.

    image

    This effectively deletes the certificates from the local store. When this is done, now that credential roaming is enabled the certificate is now tombstoned. The settings for “Maximum tombstone credentials lifetime in days” is configured within the .adm template for credential roaming. It is 60 days by default. In Vista/2008 this group policy setting is integrated into the built in security settings under User Configuration. Essentially the certificate is gone because Credential Roaming not only brings the certificates down from Active Directory but also replicates deletions up to Active Directory.

    The proper way to test if credential roaming is working optimally is to:

    1. Use a test user account instead of a production user account.
    2. Backup your certificates by exporting them.
    3. Logon as an administrator of the computer and delete the test users’ profile.
    4. Logoff as administrator account.
    5. Logon again as the test user.
    6. Verify the certificates are replicated down to the certificate store.

    Active Directory Database Size Growth

    Before deploying Group Policy to enable credential roaming for client computers you should plan for the estimated growth of the Active Directory database.

    Click here for more information on key sizes and a formula to determine the potential growth of the NTDS.DIT ahead of time. Keep in mind that the use of the word “Token” refers to a certificate private key, certificate public key, DPAPI Master key, and if enabled for Windows Vista each stored user name and password.

    Again, make sure that you have deployed at least Vista SP1. Vista RTM is not supported, and had problems with credential roaming that could make your NTDS.DIT endlessly grow.

    Taking the necessary preliminary steps to configure credential roaming and taking the time to perform initial testing in a controlled deployment will help to eliminate headaches later on.

    Jim Tierney

  • Windows XP Power Management and Group Policy Preferences

    Hi everyone, Mike here again to discuss a common scenario that generates calls to Microsoft. The scenario covers managing power on Windows XP client computers using Group Policy Preferences. Let’s cover how Windows XP manages power before we cover Group Policy Preferences Power Management.

    Windows XP Power Management

    Windows XP only has one active power scheme for the entire computer and that scheme is based on the current or previously logged on user—that is to say Windows XP power schemes are only user-based. This means the power scheme can change as each user logs on. Also, it means that last logged on user’s power settings are the settings that remain once the user logs off. And yes, each user has its own power configuration; however, the entire operating system only has one active power scheme.

    A recently started computer at the logon prompt makes the power configuration from the .DEFAULT profile the active power profile. User X logs on to the same computer. The active power profile is now read from user X’s user profile. User X logs off the computer. User X’s power profile remains the active power profile for the computer. Windows XP does not make the .DEFAULT power profile the active power profile. User Y logs on the computer. User Y’s power settings now become the active power profile. User Y’s power settings remain the active power profile after they log off the computer. We restart the computer and, once again, the active power profile is read from .DEFAULT.

    image

    Figure 1 Evolution of Windows XP's active power profile

    Group Policy Preferences Power Options

    Understanding how Windows XP manages the active power profile helps us better understand how Group Policy Power Option preference items manipulate Windows XP’s active power profile. Let’s start with computer startup. We’ve established that Windows XP reads power settings from the .DEFAULT profile into the active power profile. A Power Option preference item applying to a Windows XP computer does two things: it changes the power settings in the .DEFAULT profile and it makes those new settings the active power profile. A Power Option preference item applying to a user does two things: It changes the power settings in that user’s profile and it makes those new settings the active power profile. Remember there is only one active power profile—it’s the profile that was last made active.

    image

    Figure 2 GPP Power Option application

    Precedence

    So predicting GPP Power Option precedence is trivial for computer startup and user logon. But background refresh can introduce some confusion. The computer starts up and receives GPP Power Item A. GPP Power Item A becomes the active power profile. User X logs on and receives GPP Power Item B. The active power scheme changes from A to B. Now, let’s presume that User X is a local administrator. This means User X can change the power settings, which changes the active power settings. So, User X changes the active power profile to power settings C. Now, a Group Policy background refresh occurs.

    The background refresh changes the active power profile. And, as we previously covered, the last applied GPP Power item is the active power profile. When we last left our example computer, the active power profile was power settings C, which were created when the user changed their settings using the user interface. If the computer receives GPP Power Item A, and the user receives GPP Power Item B, then what is the resulting power profile? Power item B becomes the active power profile because it is the last power profile that is made active.

    Let’s change the scenario. Let’s deploy GPP Power Item A to the computer and not deploy anything to the user because we want to apply a single power profile that affects all the users of the computer. Makes sense right? No, not in this case. The computer starts up and applies GPP Power Item A to .DEFAULT and makes GPP Power Item A the active power profile. User X logs on, and does not have a GPP Power item applied. The user loads their power profile from their user profile, and it becomes the active power profile. The power profile does not change until the user changes it (the need to be a local administrator) or during Group Policy refresh when the computer reapplies the GPP Power item; thus becoming the active power profile. You need combine Group Policy loopback processing (in replace mode) with GPP Power items to create one single GPP Power item that applies to all users of a computer.

    Summary

    I could easily add another five pages to cover all the different combinations of GPP Power items between computer and user settings. However, the main important thing to remember is there is only one active power profile for the entire computer running Windows XP. And, the active power profile is the power profile that was made active on the computer, regardless if it was done in the context of the user or computer. There, I’m done beating Ned… I mean the “proverbial” horse.

    Mike “wow, three posts this week” Stephens

  • WDS and DFSR: Love at First Sync

    Ned here again. Windows Server 2008 introduced a new way to roll out your computers called Windows Deployment Services (WDS). WDS replaces the old Remote Installation Services introduced a decade ago with Windows 2000. By leveraging WDS, you can create image-based deployments, script settings, multicast, and all that other stuff that gets the OS installation folks excited.

    If you dig into the WDS documentation you will find that DFSR and DFSN are recommended for scaling out your deployment servers. You can centralize administration and improve performance by creating multiple distribution points that replicate OS images. All while using components you already paid for when you bought your servers.

    A few months ago, someone asked if DFSR’s Remote Differential Compression (RDC) feature had any benefits when being used with WDS, where OS images are periodically updated. Would a robocopy script perform better? Are there any interoperability issues? Is the only advantage that files are automatically copied?

    I’ve been asked about this a few more times since then, so today I’ll talk about the results. Spoiler alert: WDS and DFSR work really well together. :)

    The Test Environment

    With the invaluable assistance of Scott “the silver fox” McArthur from our sibling Web site AskCore I setup the following repro environment:

    • Two Windows Server 2008 R2 WDS servers
    • Both servers running DFSR with hotfix 975763 to update DFSRS.EXE.
    • Server “A” is the WDS administrative server where all management work is done
    • Server “B” is a WDS branch server that simply accepts whatever is sent to him and is used to deploy computers remotely
    • A variety of Win7/R2 family WIM files in an install image group, plus their single instance store RWM file. More on this in a bit.

    image

    image

    • Using WDS methodology to:
    1. Export an image
    2. Mount it
    3. Make changes to it ( in my case, about ~1MB of data added to the image)
    4. Dismount it
    5. Replace the previous image

    WDS uses a single instance store (SIS) as part of its storage mechanism. In basic terms, this means that data common among images is unified in one RWM file. And then the differences are stored in the OS image WIM file, which operates like a stub when you start installing the OS. This saves disk space, which is critical when you’re talking about dozens of images. This also means that both the Install*.WIM and Res.RWM files are altered when modifying your image.

    Note: in my case I did not have to increase the staging quota as my files still easily fit in the 4GB default staging space. You may need to increase it using our old, reliable DFSR performance tuning article:

    http://blogs.technet.com/b/askds/archive/2010/03/31/tuning-replication-performance-in-dfsr-especially-on-win2008-r2.aspx

    The Results

    WDS always replaces the existing Install*.WIM file with another copy. Additionally, the binary contents of the replaced file are effectively completely different than the original – it’s just how WIM creation works. So RDC does not provide any gains when replicating a WIM file. The file is copied in its entirety, but more on this below. However, the WIM files in WDS are comparatively small, so DFSR moves them very fast.

    WDS does not replace RWM files; it modifies them in place. This means that DFSR uses RDC and we see substantial savings over the wire in bandwidth. In our test, we added a small amount of data to the mounted image, which modifies the Res.RWM file. DFSR dies not replicate the whole 3.6GB of data; instead, DFSR replicates the delta of the change plus some overhead. The total delta of replicated data with the RWM file was around 1MB of data. That is an RDC savings of roughly 99.98%.

    The cost here when using RDC, is that a file this large spends most of its time in local disk I/O and CPU time on both WDS servers.

    • Upstream on “A” - copying the file to staging, walking all of its data to create signatures – took several minutes
    • Downstream on B – copying the file to staging (unless it already exists), walking all of its data to create signatures, taking the bits that were sent over the wire and reconstructing the file with its changes, installing the file

    So only a few seconds and 1MB of data was network time – the rest is “thinking time”. If you have a low-latency, high-bandwidth, gigabit network between all servers, then using DFSR with RDC to save bandwidth is not advantageous over just copying the files with say robocopy or xcopy – it might appear slightly slower. But if the network WAN connections are not fast or high bandwidth, then DFSR with RDC saves a ton of bandwidth and time. Also, you can turn off RDC on just these super-fast network scenarios and at least get DFSR’s “keep my files in sync so I don’t have to think about it” advantage.

    That’s the short answer. Not everyone likes to read my DFSR debug diatribes, but if you do, carry on to the next section.

    Seeing it all under the covers

    20091007 18:06:13.330 2680 USNC  2450 UsnConsumer::UpdateIdRecord LDB Updating ID Record: ß file is modified, not replaced
    +      fid                             0x30000000000B0
    +      usn                             0x6b480
    +      uidVisible                      1
    +      filtered                        0
    +      journalWrapped                  0
    +      slowRecoverCheck                0
    +      pendingTombstone                0
    +      internalUpdate                  0
    +      dirtyShutdownMismatch           0
    +      meetInstallUpdate               0
    +      meetReanimated                  0
    +      recUpdateTime                   20091007 21:29:29.115 GMT
    +      present                         1
    +      nameConflict                    0
    +      attributes                      0x2020
    +      ghostedHeader                   0
    +      data                            0
    +      gvsn                            {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v241
    +      uid                             {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v138
    +      parent                          {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v128
    +      fence                           Default (3)
    +      clockDecrementedInDirtyShutdown 0
    +      clock                           20091007 22:06:13.298 GMT (0x1ca479a624956e1)
    +      createTime                      20091007 18:46:43.088 GMT
    +      csId                            {35F6E8DD-422B-4566-B7AD-9D13338E498C}
    +      hash                            00000000-00000000-00000000-00000000
    +      similarity                      00000000-00000000-00000000-00000000
    +      name                            Res.RWM
    ß the RWM file

    20091007 18:06:13.330 2680 USNC  2453 UsnConsumer::UpdateIdRecord ID record updated from USN_RECORD: ß USN update showing modification
    +      USN_RECORD:
    +      RecordLength:        80
    +      MajorVersion:        2
    +      MinorVersion:        0
    +      FileRefNumber:       0x30000000000B0
    +      ParentFileRefNumber: 0x10000000000C7
    +      USN:                 0x6b480
    +      TimeStamp:           20091007 18:06:13.298 Eastern Standard Time
    +      Reason:              Close Data Extend Data Overwrite
    ß modifying here, not replacing
    +      SourceInfo:          0x0
    +      SecurityId:          0x0
    +      FileAttributes:      0x2020
    +      FileNameLength:      14
    +      FileNameOffset:      60
    +      FileName:            Res.RWM
    ß the RWM file

    20091007 18:06:13.689 2808 STAG  4257 Staging::GetStageReaderOrWriter ß file gets staged
    +      fid                             0x30000000000B0
    +      usn                             0x6b480
    +      uidVisible                      1
    +      filtered                        0
    +      journalWrapped                  0
    +      slowRecoverCheck                0
    +      pendingTombstone                0
    +      internalUpdate                  0
    +      dirtyShutdownMismatch           0
    +      meetInstallUpdate               0
    +      meetReanimated                  0
    +      recUpdateTime                   20091007 22:06:13.330 GMT
    +      present                         1
    +      nameConflict                    0
    +      attributes                      0x2020
    +      ghostedHeader                   0
    +      data                            0
    +      gvsn                            {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v241
    +      uid                             {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v138
    +      parent                          {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v128
    +      fence                           Default (3)
    +      clockDecrementedInDirtyShutdown 0
    +      clock                           20091007 22:06:13.298 GMT (0x1ca479a624956e1)
    +      createTime                      20091007 18:46:43.088 GMT
    +      csId                            {35F6E8DD-422B-4566-B7AD-9D13338E498C}
    +      hash                            00000000-00000000-00000000-00000000
    +      similarity                      00000000-00000000-00000000-00000000
    +      name                            Res.RWM
    ß the RWM file
    +      StageReader:0000000000000000 StageWriter:000000000032A1B0 Policy:1

    20091007 18:06:14.064 2808 RDCX   467 StreamToIndex RDC generate begin: (0..4), uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v138 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v241 fileName:Res.RWM csId:{35F6E8DD-422B-4566-B7AD-9D13338E498C} ß RDC signature calculation starts
    20091007 18:09:49.903 2808 RDCX   509 StreamToIndex RDC generate end: (0..4), uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v138 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v241 fileName:Res.RWM csId:{35F6E8DD-422B-4566-B7AD-9D13338E498C} ß RDC signatures calculation done (took ~ 3 minutes 35 seconds)

    20091007 18:09:50.341 2808 SRTR  2592 InitializeFileTransferAsyncState::~InitializeFileTransferAsyncState this:000000000032FD00
    20091007 18:14:37.972 2228 OUTC  3273 OutConnectionContentSetContext::SERVER_RdcGetSignatures Sent requested RDC signatures. context:00000000003BE770 rdcState:00000000003194B0 reader:0000000000000000 level:1 offset:32826220 length:422 sizeRead:422 uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v138 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v241 csId:{35F6E8DD-422B-4566-B7AD-9D13338E498C}
    ß signature data gets used to creates packages of data and is sent – this takes ~ 4 minutes 15 seconds comparing to signatures downstream and sending the data

    20091007 18:14:44.113 2228 RDCX  2927 Rdc::SyncServerState::~SyncServerState RDC Need Reader Statistics: uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v138 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v241 connId:{D3F93FEA-BF07-4CEF-8E4E-E82564BE2E7B} csId:{35F6E8DD-422B-4566-B7AD-9D13338E498C}
    +      TOTAL                       
    +      Compression Ratio            31
    +      RDC Need Size                1381790
    +      Bytes sent to downstream     958704
    ß Only about 1MB (!!!) of data from the 3756455865 byte file actually had to be sent to B though. Very cool RDC savings!
    +      Uncompressed XPRESS blocks   0
    +      Compressed XPRESS blocks     4
    +      Copied XPRESS Blocks         1
    +      Bytes read using async I/Os  914469

    Server B:

    20091007 18:14:43.826  324 XRNA   276 XpressRdcNeedAssembler::ProcessRdcNeeds All needs processed. this:0000000017384710
    20091007 18:14:43.826  324 XRNA   291 XpressRdcNeedAssembler::FinalizeRpcDownload Shutting down RPC pipe thread this:0000000017384710
    20091007 18:14:43.826 1436 XRNA   919 XpressRdcNeedAssembler::GetSourceRdcNeedDataThread Exiting RDC source need download thread. this:0000000017384710
    ß finished getting the files bits

    20091007 18:14:43.873  324 STAG   798 StageWriter::CompleteDownloadStage Completed download or stage file 241-{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v138-{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v241-Downloaded.frx
    20091007 18:18:08.843  324 ASYN   508 AsyncUnbufferedFileWriter::Close Async WRITE Statistics:
    ß all bits put together, ready to drop into real replicated folder

    20091007 18:18:08.843  324 MEET  3013 Meet::InstallRename Moving contents from Installing to final destination. Attributes:0x2020 updateName:Res.RWM uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v138 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v241 connId:{D3F93FEA-BF07-4CEF-8E4E-E82564BE2E7B} csName:RemoteInstall ß done. Took ~12 minutes of “real time”, but you saved 3.6 GB on the wire(!!!)

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

    INSTALL.WIM behavior:

    Server A:

    20091007 18:06:12.830 2680 USNC  2881 UsnConsumer::TombstoneOrDelete LDB Updating ID Record: ß install.wim is deleted and database record updated
    +      fid                             0x500000000006A
    +      usn                             0x6b388
    +      uidVisible                      1
    +      filtered                        0
    +      journalWrapped                  0
    +      slowRecoverCheck                0
    +      pendingTombstone                0
    +      internalUpdate                  0
    +      dirtyShutdownMismatch           0
    +      meetInstallUpdate               0
    +      meetReanimated                  0
    +      recUpdateTime                   20091007 21:29:31.255 GMT
    +      present                         0
    +      nameConflict                    0
    +      attributes                      0x2020
    +      ghostedHeader                   0
    +      data                            0
    +      gvsn                            {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v240
    +      uid                             {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v137
    +      parent                          {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v128
    +      fence                           Default (3)
    +      clockDecrementedInDirtyShutdown 0
    +      clock                           20091007 22:06:12.642 GMT (0x1ca479a61e532f7)
    +      createTime                      20091007 18:47:25.714 GMT
    +      csId                            {35F6E8DD-422B-4566-B7AD-9D13338E498C}

    +      hash                            5DB57C5A-C50E04D8-DEAAFED0-04B337A2
    +      similarity                      3E311339-251E183B-20271C15-2C183010
    +      name                            install.wim
    ß the WIM

    20091007 18:06:13.455 2680 USNC  3490 UsnConsumer::UidTunnelReanimate LDB Updating ID Record: ß same named/pathed file was written in (aka the delete above was really an overwrite)
    +      fid                             0x600000000006A
    +      usn                             0x6b5d8
    +      uidVisible                      1
    +      filtered                        0
    +      journalWrapped                  0
    +      slowRecoverCheck                0
    +      pendingTombstone                0
    +      internalUpdate                  0
    +      dirtyShutdownMismatch           0
    +      meetInstallUpdate               0
    +      meetReanimated                  0
    +      recUpdateTime                   20091007 22:06:12.830 GMT
    +      present                         1
    +      nameConflict                    0
    +      attributes                      0x2020
    +      ghostedHeader                   0
    +      data                            0
    +      gvsn                            {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v242
    +      uid                             {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v137
    +      parent                          {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v128
    +      fence                           Default (3)
    +      clockDecrementedInDirtyShutdown 0
    +      clock                           20091007 22:06:13.408 GMT (0x1ca479a625a0788)
    +      createTime                      20091007 18:47:25.714 GMT
    +      csId                            {35F6E8DD-422B-4566-B7AD-9D13338E498C}
    +      hash                            00000000-00000000-00000000-00000000
    +      similarity                      00000000-00000000-00000000-00000000
    +      name                            install.wim
    ß the WIM

    20091007 18:06:13.783 2680 USNC  2450 UsnConsumer::UpdateIdRecord LDB Updating ID Record: ß WDS writes some more data to the file
    +      fid                             0x600000000006A
    +      usn                             0x6b6e0
    +      uidVisible                      1
    +      filtered                        0
    +      journalWrapped                  0
    +      slowRecoverCheck                0
    +      pendingTombstone                0
    +      internalUpdate                  0
    +      dirtyShutdownMismatch           0
    +      meetInstallUpdate               0
    +      meetReanimated                  0
    +      recUpdateTime                   20091007 22:06:13.752 GMT
    +      present                         1
    +      nameConflict                    0
    +      attributes                      0x2020
    +      ghostedHeader                   0
    +      data                            0
    +      gvsn                            {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v244
    ß note how we’re at 244, so it’s been modified a bit more by WDS
    +      uid                             {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v137
    +      parent                          {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v128
    +      fence                           Default (3)
    +      clockDecrementedInDirtyShutdown 0
    +      clock                           20091007 22:06:13.752 GMT (0x1ca479a628e7bdf)
    +      createTime                      20091007 18:47:25.714 GMT
    +      csId                            {35F6E8DD-422B-4566-B7AD-9D13338E498C}
    +      hash                            00000000-00000000-00000000-00000000
    +      similarity                      00000000-00000000-00000000-00000000
    +      name                            install.wim     

    20091007 18:06:13.783 2680 USNC  2453 UsnConsumer::UpdateIdRecord ID record updated from USN_RECORD:
    +      USN_RECORD:
    +      RecordLength:        88
    +      MajorVersion:        2
    +      MinorVersion:        0
    +      FileRefNumber:       0x600000000006A
    +      ParentFileRefNumber: 0x10000000000C7
    +      USN:                 0x6b6e0
    +      TimeStamp:           20091007 18:06:13.752 Eastern Standard Time
    +      Reason:              Close Data Extend Data Overwrite
    ß data added
    +      SourceInfo:          0x0
    +      SecurityId:          0x0
    +      FileAttributes:      0x2020
    +      FileNameLength:      22
    +      FileNameOffset:      60
    +      FileName:            install.wim

    20091007 18:06:16.502  556 RDCX  2927 Rdc::SyncServerState::~SyncServerState RDC Need Reader Statistics: uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v137 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v245 connId:{D3F93FEA-BF07-4CEF-8E4E-E82564BE2E7B} csId:{35F6E8DD-422B-4566-B7AD-9D13338E498C}
    +      TOTAL
    +      Compression Ratio            0
    +      RDC Need Size                2660306
    +      Bytes sent to downstream     2682260
    ß we have to send these many bytes to server B. There is no RDC saving here, the file was scrambled by WIM format.
    +      Uncompressed XPRESS blocks   0
    +      Compressed XPRESS blocks     0
    +      Copied XPRESS Blocks         2
    +      Bytes read using async I/Os  2656520

    20091007 18:06:16.517  556 ASYN  1289 AsyncUnbufferedFileReader::Close Async READ Statistics:
    +      Total I/O Bytes             2656520 (3 buffers)
    +      Number of Async Buffers     2
    +      Size of Async Buffers       1048576
    +      Number of Async I/Os        3
    +      Number of Sync I/Os         0
    +      Number of Pending Calls     1
    +      Number of Queue Depth Empty 0
    +      Number of Buffers Used      2

    On Server B:

    20091007 18:06:18.139 1852 INCO  6593 InConnection::LogTransferActivity Received RAWGET uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v137 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v246 fileName:install.wim connId:{D3F93FEA-BF07-4CEF-8E4E-E82564BE2E7B} csId:{35F6E8DD-422B-4566-B7AD-9D13338E498C} stagedSize:2657686 ß RDC could not be used – no matching signatures - so we do a raw copy

    20091007 18:06:18.545 1852 INCO  4825 InConnection::UpdateProcessed Received Update. updatesLeft:0 processed:1 failures:0 sessionId:6 open:0 updateType:0 processStatus:0 connId:{D3F93FEA-BF07-4CEF-8E4E-E82564BE2E7B} csId:{35F6E8DD-422B-4566-B7AD-9D13338E498C} csName:RemoteInstall update: ß final version of file replicated
    +      present                         1
    +      nameConflict                    0
    +      attributes                      0x2020
    +      ghostedHeader                   0
    +      data                            0
    +      gvsn                            {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v245
    +      uid                             {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v137
    +      parent                          {7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v128
    +      fence                           Default (3)
    +      clockDecrementedInDirtyShutdown 0
    +      clock                           20091007 22:06:13.767 GMT (0x1ca479a6290de3f)
    +      createTime                      20091007 18:47:25.714 GMT
    +      csId                            {35F6E8DD-422B-4566-B7AD-9D13338E498C}
    +      hash                            2BAC2FE6-3735E3A6-F89F8423-37C51923
    +      similarity                      1D2A1A21-262A310C-0C060426-06291D0B
    +      name                            install.wim

    20091007 18:06:18.498 1852 MEET  1804 Meet::InstallStep Done installing file updateName:install.wim uid:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v137 gvsn:{7E4661CA-F75E-48D6-9F23-828FE47C23C6}-v246 connId:{D3F93FEA-BF07-4CEF-8E4E-E82564BE2E7B} csName:RemoteInstall ß B has the new file. Took about 6 seconds on a fast network so this would be much slower on most WAN's. And since the file was never that big anyways, probably acceptable behavior.

    So there it is. If you’re using WDS and DFSR and your servers are not connected purely by gigabit end-to-end, modifying your images and letting DFSR take care of the modification can save big time and bandwidth. And that is something you can put towards your bottom line with more productive users who can use more of that WAN for other things.

    - Ned “the matchmaker” Pyle

  • Control Extended Protection for Authentication using Security Policy

    Mike here again. Microsoft has introduced additional security measures for authentication known as Extended Protection for Authentication, also known as channel binding token (CBT). Extended protection can cause a variety of interoperability issues including but not limited to:

    • Windows clients that support channel binding fail to be authenticated by a non-Windows Kerberos server
    • NTLM authentication failures from Proxy servers
    • NTLM authentication failures from non-Windows NTLM servers
    • NTLM authentication failures when there is a time difference between the client and DC or workgroup server

    Note: Read more about Extended Protection for Authentication in Microsoft Knowledge base article 968389 and MSDN.

    Administrators may want to control the state of Extended Protection to multiple client computers. This can be accomplished using security policy. Security policy is the most appropriate solution to distribute the registry setting that controls Extended Protection for Authentication because the setting is stored under the LSA key in HKEY_LOCAL_MACHINE. Also, distributing the setting using security policy increases the chance of the desired settings winning all conflicts because, by default, security settings always apply during Group Policy Processing. Once the policy is applied, any user or application that changes the registry location will be reverted back to the desired configuration during the next application of security policy.

    Add the policy setting to Security Policy settings

    The Extended Protection for Authentication policy setting must be added to Security Policy editor to include the policy setting in Group Policy. To accomplish this:

    1. Copy the following text

    ==== Start copy after this line ====

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeCEdit\Reg Values\MACHINE/System/CurrentControlSet/Control/Lsa/SuppressExtendedProtection]
    "ValueType"=dword:00000004
    "DisplayType"=dword:00000003
    "DisplayName"="Network Security: Extended Protection for Authentication"
    "DisplayChoices"=hex(7):30,00,7c,00,45,00,6e,00,61,00,62,00,6c,00,65,00,64,00,\
      00,00,33,00,7c,00,44,00,69,00,73,00,61,00,62,00,6c,00,65,00,64,00,00,00,00,\
      00

    ==== Stop copy before this line ====

    2. Open Notepad and paste the text from step one into Notepad.

    3. Click File and then Click Save As.

    4. In the File name box, type secpoladd.reg.

    5. In the Save as type list, click All Files. Remember the path to which the file is saved.

    6. Click Save and close Notepad.

    7. Locate the saved file from the path in step 5. Double-click the secpoladd.reg file. Click Yes to the Registry Editor dialog box.

    It is only required to modify the security editor on the computer used to manage Group Policy. This allows the Extended Protection for Authentication policy setting to be included in a Group Policy object. Extending this security setting to other computers is not required for client computers to receive the security setting.

    Include the Extended Protection for Authentication policy setting in Group Policy

    image

    With the security editor extended, you can now include the security setting within a Group Policy object. To do this:

    1. Using GPMC, edit the Group Policy object that is to contain the security setting.

    2. Navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.

    3. In the right pane of the MMC, scroll through the list of security settings to locate
    Network Security: Extended Protection for Authentication. Double-click the security setting.

    4. Select Define this policy setting. Choose the desired configuration from the list and click OK.

    5. Close the Group Policy object.

    6. The Group Policy object now contains the security policy setting. Use GPMC to deploy the GPO to clients as needed.

    Conclusion

    Improving security always poses a risk with application compatibility. The long term solution is to determine why applications no longer work when security in heightened. A short-term solution during the investigation may be to reduce security to allow the application to work, pending the results of the investigation. Controlling this using Group Policy helps manage the setting for the enterprise.

    Mike “I make tree-bicles” Stephens

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

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

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

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

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

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

    Error 1722: The RPC server is unavailable.

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

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

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

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;951430

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

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

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

    Additional Locale IDs can be found here:
    http://msdn.microsoft.com/en-us/goglobal/bb964664.aspx

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

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

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

    Scott “Red Herring” Goad

  • New Directory Services KB Articles/Blogs 12/13-12/19

    KB

    978335

    Windows Server Update Services keeps reinstalling the root certificates update that is described in KB 931125 on the clients that are running Windows XP

    978175

    An empty encrypted folder remains on a computer that is running Windows Vista after you move the folder to a network share

    977611

    After you apply a GPO to redirect a folder to a new network share, the redirected folder is empty on client computers that are running Windows Vista or Windows Server 2008

    978319

    How to restore the Windows Remote Management settings when all authentication schemes are disabled on a computer that is running Windows Server 2008 R2

    978323

    Domain controllers are incorrectly listed as offline in Active Directory Administration Center

    978324

    High CPU utilization when the DFS Replication service is installed on a failover cluster node running Windows Server 2008 R2

    978326

    Error message and event log warning 6804 when you complete a DFS Replication SYSVOL migration by using the Dfsrmig.exe tool on a domain controller that is running Windows Server 2008 R2: "No connections exist for Domain System Volume"

    978591

    You cannot change User Account Control (UAC) settings on Windows 7

    Blogs

    Troubleshooting Credential Roaming

    WDS and DFSR: Love at First Sync

    Windows Server 2008 R2 eBook

    Windows 7 Kernel Enhancements

    Announcing the AD FS 2.0 Release Candidate and More

    Announcing WIF support for Windows Server 2003 !!

    Using DNS Aliases on Windows Machines.

    Microsoft begins testing new tech support forum staffed by paid 'independent experts'

    High CPU on Wmiprvse.exe caused by memory leak DNSPROV.DLL Windows 2003

    Windows Server 2008 R2 Quick Look- Installing the Migration Tools

    Why didn't my Group Policy settings apply?

    DNS Security (DNSSec) Overview

    Selecting the Right Virtualization Technology – R2 IPD Guide now available

    Reposted : 5 Group Policy Myths

    UAG reaches RTM

    Where do my FSMO roles go when I delete a DC in “Active Directory Users and Computers”?

    Windows 7 XP Mode User Experience

    Finding out which machines are Laptops in a domain

  • Our Long Winter's Nap

    Hi all. Most of us that maintain this blog are out of the office for Christmas and New Year. Hopefully you don't care because you are celebrating with your family and friends - not working. Feel free to keep sending us emails and comments, but don’t expect any answers until January 4th.

    In the tradition of this blog and a significant day, I leave you with disturbing clip art.

    image

    Happy holidays everyone!

    - The AskDS team