Blog - Title

January, 2008

  • New DFSR Data Restoration Script

    Hi, Ned here. Just a quick heads up - there is a new DFSR data recovery script posted below. This allows you to restore data from the ConflictAndDeleted or PreExisting folders within DFSR, primarily during disaster recovery. As always, we prefer you use your backup system to do this, as the script is 'at your own risk' and unsupported.

    Updated 10/15/10

    The latest script is now hosted on Code Gallery:

    Update 6/12/14

    Well that gallery is kaput. Now hosted from here.

    This old script is really gross, I recommend instead using our new Windows PowerShell cmdlet Restore-DfsrPreservedFiles instead. You can restore from 8.1 client if you install RSAT, or from a WS2012 R2 server. Can either run locally or just map a drive to \\dfsrserver\h$ or whatever the root drive is, then restore.

    Take a look at for steps on using this cmdlet.


    Remember, this script must be run from a CMD prompt using cscript. Don't just double-click it.


    The script also requires to edit three paths (your source files, a new destination path, and the XML manifest you are calling) . If you fail to edit those the script will exit with an error:

    ' Section must be operator-edited to provide valid paths

    ' Change path to specify location of XML Manifest
    ' Example 1: "C:\Data\DfsrPrivate\ConflictAndDeletedManifest.xml"
    ' Example 2: "C:\Data\DfsrPrivate\preexistingManifest.xml"


    ' Change path to specify location of source files

    ' Example 1: "C:\data\DfsrPrivate\ConflictAndDeleted"
    ' Example 2: "C:\data\DfsrPrivate\preexisting"

    SourceFolder = ("C:\your_replicated_folder\DfsrPrivate\ConflictAndDeleted")

    ' Change path to specify output folder

    OutputFolder = ("c:\your_dfsr_repair_tree")


    - Ned Pyle

  • Understanding “Read Only Domain Controller” authentication

    Hello there. Bob Drake here to discuss how Windows Server 2008 “Read Only Domain Controllers” (RODC’s) authenticate users differently from the way Windows Server 2003 and Windows Server 2008 standard domain controllers do. The “Read Only Domain Controller” is new to Windows Server 2008 and allows for the installation of a domain controller to accommodate common scenarios where users are authenticating over a wide area network (WAN) or there is a physical security concern for the domain controller, such as installations at branch office locations. Another new feature to Windows Server 2008 RODC’s is “Password Replication Policy” and depending on how they are configured determines how an RODC authenticates a user.

    To understand the authentication difference between a standard domain controller and an RODC, we need to review the “How interactive Logon works” and “Kerberos authentication” TechNet articles. In the section Domain Login (How interactive logon works article), a user’s credentials are received by Winlogon and passed to the LSA (local security authority) which negotiates Kerberos and contacts the domain controller. The domain controller then returns the logon success to the local computers LSA which generates the user’s access token. The Kerberos authentication is seen in the following diagram (taken from the Kerberos authentication article):


    To see the authentication on the wire, we would need to install a network capture application such as Netmon3.1 (or Wireshark, Ethereal, Packetyzer). In the following network trace, we see a client machine authenticate to a domain controller and is granted access with the “KRB_AS_REP” and “KRB_TGS_REP”:


    Now let’s take a look at the “Password Replication Policies” and how they affect the RODC authentication behavior. With the installation of an RODC, there are four new attributes and two built-in groups to support RODC operations:

    • msDS-Reveal-OnDemandGroup. This attribute points to the distinguished name (DN) of the Allowed List. The credentials of the members of the Allowed List are permitted to replicate to the RODC.
    • msDS-NeverRevealGroup. This attribute points to the distinguished names of security principals that are denied replication to the RODC. This has no impact on the ability of these security principals to authenticate using the RODC. The RODC never caches the credentials of the members of the Denied List. A default list of security principals whose credentials are denied replication to the RODC is provided. This helps ensure that RODCs are secure by default.
    • msDS-RevealedList. This attribute is a list of security principals whose passwords have ever been replicated to the RODC.
    • msDS-AuthenticatedToAccountList. This attribute contains a list of security principals in the local domain that have authenticated to the RODC. The purpose of the attribute is to help an administrator determine which computers and users are using the RODC for logon. This enables the administrator to refine the Password Replication Policy for the RODC.

    • Allowed RODC Password Replication Group. This group is added to the msDS-Reveal-OnDemandGroup.
    • Denied RODC Password Replication Group. This group is added to the msDS-NeverRevealGroup.

    Note: The “Allowed RODC Password Replication Group” has no members by default, and the “Denied RODC Password Replication Group” contains all the ‘VIP’ accounts (Enterprise Administrators, Cert Publishers, Schema Administrators, Etc). As with most things, Deny always trumps Allow.

    Using the commands for “Repadmin.exe” (this is built into Windows Server 2008) an administrator can modify the Password Replication Policy groups. To view the current PRP for a specified user:

    Repadmin /prp view <RODC> {<List_Name >|<User>}

    The following shows the settings for the groups on the RODC through several commands:


    Awesome information here! We can see who is on the allowed list (msDS-RevealOnDemand), who is on the deny list (msDS-NeverRevealGroup), who is actually revealed (msDS-RevealedList) and who actually has authenticated to the RODC (msDS-AuthenticatedToAccountlist).

    The configuration of a Password Replication Policy is pretty straight forward. Open Active Directory Users and Computers snap-in and select the RODC in the Domain Controllers organizational unit. On the “Password Replication Policy” tab, there are the two groups: “Allowed RODC Password Replication Group” and “Denied RODC Password Replication Group”. A user can be added to either of the desired groups.

    Another really cool feature is the “Prepopulate the password cache for an RODC” button. This button (pictured) allows an administrator to pre-add users that will be authenticating to the RODC.


    An administrator could also use the “Repadmin” utility to populate the password cache with the following command:

    Repadmin /rodcpwdrepl [DSA_LIST] <Hub DC> <User1 Distinguished Name> [<Computer1 Distinguished name> <User2 Distinguished Name>…].

    The following shows the user “Ned Pyle” being added to the password cache using Repadmin:


    So how does this affect the RODC? When a user authenticates to an RODC a check is performed to see if the password is cached. If the password is cached, the RODC will authenticate the user account locally. If the user’s password is not cached, then the RODC forwards the authentication request to a writable Windows Server 2008 Domain Controller which in turn authenticates the account and passes the authenticated request back to the RODC. Once the user account is authenticated, the RODC makes another request for the replication of the user’s password in a unidirectional replication providing the account has been configured to allow replication.

    This finally brings us to seeing the difference in authentication. For the following NetMon 3.1 trace, I have configured a user account whose password has been denied replication to the RODC. The user authenticates to the RODC (2k3DOM2k8DC2) and the RODC forwards the request to the writable domain controller (2k3DOM2k8DC). We see the extra traffic since the user’s password has not been cached:


    For the last trace I have allowed the user password to be cached by configuring the Password Replication Policy. The user authentication is the same as above, with the exception to what the RODC does after authenticating the user. Now see the RODC make the request for the user’s password to be replicated, but in subsequent logins the password replication request would not be seen since it has been cached:


    Note: If the Wide Area Network (WAN) is down and the user account and password has NOT been cached, then the user account will fail to authenticate.

    To wrap it up, when a user account is not cached, the RODC forwards the authentication to a writable Domain Controller which does the authentication. If the Users password is allowed to be cached, then the RODC will pull that through a replication request. Once the user has been authenticated, and their password has been cached, any subsequent login can then be handled by the RODC alone. Some people may see an increase in Wide Area Network (WAN) traffic with the introduction to an RODC, but after caching user passwords there should be a significant reduction in traffic and a more secure environment. In my next blog I will discuss how account lockout thresholds affect this process and what Administrators might run into with them.

    -Bob Drake

  • Security Policy Settings and User Account Control

    Hi, Mike here. This post was originally published in the Group Policy Team blog in September 2006—anticipating the launch of Windows Vista. Here it is again—refreshed—for the upcoming launch of Windows Server 2008.

    User Account Control in Windows Server 2008 and Windows Vista requires all users run in a standard user mode; its purpose: to limit the user’s ability from changing critical operating system files or expose their computer and network to viruses and malware. Windows displays an authorization dialog box when a task requires administrative privileges, such as opening the Microsoft Management Console (MMC). You, the administrator, provide administrative credentials to “elevate” your privileges for the specific process (You can read more about User Account Control, on the Microsoft Windows Vista TechNet site Windows Server 2008 and Windows Vista provide you with nine security policy settings to control how User Account Control behaves. You can locate these security policy settings in the Local Group Policy Editor under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options or Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options when editing domain-based GPOs using GPMC included in Windows Server 2008 or when using Remote Server Administration Tool on Windows Vista Service Pack 1.

    Figure 1- UAC security policy parent node in a domain-based GPO.

    These security policy settings apply only to computers running Windows Server 2008 or Windows Vista RTM or later. These security policy settings can co-exist in GPOs applicable to clients earlier than Windows Vista. Operating systems other than Windows Server 2008 and Windows Vista ignore the settings.

    Figure 2- UAC Computer security policy settings

    Before I begin, I want to tell you about another feature with security policy settings. This valuable feature is a little hard to find. Each security policy setting has “explain” text similar to registry-based policy settings. Simply double-click on the security policy setting and then click on the Explain tab to view detailed information about the security policy setting; enabled and disabled behavior; and default values. Now, let us move on to the User Account Control policy settings.


    Figure 3 - Explain text in Security policy settings

    Windows Vista provides nine security policy settings to control the behavior of User Account Control. You can enable these security policy settings in Local Computer and Domain-based Group Policy objects. Each security policy setting starts with “User Account Control” and then the actual name of the policy settings. The Group Policy Object Editor lists security policy settings in alphabetical order, so just scroll to the end.

    The first of these policies controls the Admin Approval Mode for the built-in administrators account. When enabled, the Admin Approval mode is on for the built-in administrator account causes Windows prompts the administrators for any operations requiring an elevation in privilege. The prompt gives the administrator the choice to Permit or Deny the request for elevation. When disabled, Admin Approval mode is off. The built-in administrator account runs all applications using full administrative privileges and does not prompt for elevation.

    The next two security policy settings control the type of prompt for User Account Control uses. These security policy settings are Behavior of the elevation prompt for administrators in Admin Approval Mode and Behavior of the elevation prompt for standard users. Behavior of the elevation prompt for administrators in Admin Approval Mode security policy setting provides three choices

    • Prompt for Consent –provides a dialog box asking you to either Permit or Deny the request for elevation.
    • Prompt for Credentials –provides an authentication dialog box asking you to provide administrative credentials to permit the request for elevation.
    • Elevate without Prompting –automatically permits the request for elevation without prompting the administrator.

    The Behavior of the elevation prompt for standard users security policy setting provides two choices. Prompt for Credentials and Automatically deny elevation requests where Windows denies all requests for elevation and displays an Access Denied error message.

    When enabled, the Detect application installation and prompt for elevation security policy setting causes Windows to detect heuristically for installation packages that require an elevation of privilege and triggers a User Account Control prompt for elevation. Disabling this security policy setting disables detection process.

    Enabling the security policy setting Only elevate executables that are signed and validated enforces Windows Vista to validate the Public Key Infrastructure (PKI) certificate chain before permitting it to run. Disabling this security policy setting does not enforce validation of the PKI certificate chain.

    The next security policy setting listed is, Only elevate UIAccess applications that are installed in secure locations. UIAccess applications are applications designed specifically to assist with user accessibility. These applications typically send information to other applications. The on-screen keyboard is an example of a UIAccess application. When enabled, Windows enforces UIAccess application to run from a secure location. These secure locations include:

    • …\Program Files\... including all sub folders.
    • …\Windows\System32\...
    • …\Program Files (x86)\... including all sub folders (64-bit versions).

    Your desktop appearance changes when Windows Vista prompts you for elevation. Windows displays a gradient shade of gray over your existing desktop and then you see the prompt for elevation, in color. Actually, Windows switches your desktop to a secure desktop before prompting you for elevation. This describes the enabled behavior of the security policy setting Switch to the secure desktop when prompting for elevation. When disabled, Windows prompts for elevation on your existing desktop.

    Some applications read or write registry information or files to locations that Windows protects from normal users. This usually requires the user to run the application as an administrator until an application upgrade becomes available. Windows Vista helps by providing virtualized file and registry writes to areas previously protected from normal users. This feature redirects writes destined for protected locations to locations where users have write access. The security policy setting Virtualize file and registry write failures to per-user locations provides this behavior, when enabled. When you disable this security policy setting, applications attempting to write in protected locations fail as with earlier versions of Windows.

    The last security policy setting controlling User Account Control behavior is probably the most important one. Run all users, including administrators, as standard users is a security policy setting the affects all other User Account Control security policy settings. Enabling this policy turns on Admin Approval Mode and enables all other User Account Control polices to their default values. Disabling this policy turns off Admin Approval Mode and disables all related User Account Control security policy settings. Lastly, changing this security policy setting requires a reboot.

    So, when you are evaluating your security policy during your Windows Server 2008 or Windows Vista deployment, look at the explain text for each security policy setting. Make sure you fully understand its impact before changing a security policy setting. Then, do not forget to include User Account Control policy settings in your security policy. These security policy settings can help you keep your computer, network, and data safe and secure.

    - Mike Stephens

  • Which KB articles resolve the most Directory Services issues?

    Hi, Craig here. It can be frustrating to call support only to have your issue resolved by an article in the Microsoft Knowledge Base. Sometimes you are just happy to get the problem solved, but most people prefer to solve something themselves and avoid calling support. So it may be interesting to know which KB articles are used the most in Directory Services support to solve customer issues. By becoming more familiar with these articles you can improve your troubleshooting skills for the most common Active Directory-related issues.

    When we resolve an issue using a specific KB article, we can link that article to the case for reporting purposes. We report on this to get an idea of which articles are most useful, as well as to help understand the types of issues we see the most. While there are other ways we report on top issues, this is one of the few that shows KB article usage.

    Note that this is not a report on which KB articles get the most page views on Just because an article gets a lot of hits doesn’t mean it is particularly helpful. For example, many articles offer generic troubleshooting steps for common issues, so they come up high in search results, but they may not provide a complete solution to your problem. Also keep in mind that this report shouldn’t necessarily be seen as a list of the most common Directory Services issues. There are KB articles that customers use all the time to fix themselves without ever calling support. This list only shows articles that were used when someone called Microsoft product support.

    Depending on how you slice it, we support about 30 different Windows components in the Directory Services specialty. But to give you a general idea of the types of articles that are included in the report, here is a more concise list of what technologies we support.

    •    Active Directory
    •    Authentication
    •    Authorization
    •    File Replication Service
    •    DFS Namespaces
    •    DFS Replication
    •    Public Key Infrastructure
    •    User Profiles
    •    Terminal Server Licensing
    •    Windows Time Service

    Because most issues with those components are dependent on healthy network connectivity, the list includes some articles that deal with network issues that will impact Directory Services components. KB 936594 about the TCP offload features introduced in Windows Server 2003 SP2 is a good example of that. And since Active Directory is heavily dependent on DNS, there are some DNS-related articles listed as well.

    Hopefully that puts it in the proper context. Here are the top 50 KB articles used to solve issues in Directory Services support during the first quarter of Microsoft fiscal year 2008 (July 2007 through September 2007).




    How to remove data in Active Directory after an unsuccessful domain controller demotion


    The function of Terminal Server CALs in Windows Server 2003


    Windows Server 2003 Terminal Server licensing issues and requirements for deployment


    Error message when you run the Active Directory Installation Wizard: "The version of the Active Directory schema of the source forest is not compatible with the version of Active Directory on this computer"


    Using the BurFlags registry key to reinitialize File Replication Service replica sets


    How to override the license server discovery process in Windows Server 2003 Terminal Services


    Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller


    How to rebuild Windows 2000 and 2003 Terminal Services Licensing database


    You may experience network-related problems after you install Windows Server 2003 SP2 or the Scalable Networking Pack on a Windows Small Business Server 2003-based computer


    "Directory Services cannot start" error message when you start your Windows-based or SBS-based domain controller


    How to rebuild the SYSVOL tree and its content in a domain


    How to activate a License Server by using Terminal Server Licensing in Windows Server 2003


    How to restore deleted user accounts and their group memberships in Active Directory


    How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000


    How to configure an authoritative time server in Windows Server 2003


    Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server


    How to upgrade Windows 2000 domain controllers to Windows Server 2003


    Applying Group Policy causes Userenv errors and events to occur on your computers that are running Windows Server 2003, Windows XP, or Windows 2000


    You cannot deploy a Windows Server 2003 R2 x64 Edition-based domain controller in a Windows Server 2003 forest


    A Windows Server 2003-based computer may stop responding when it is resumed from standby and events 1030 and 1058 are logged in the application log of a domain controller


    Delegated permissions are not available and inheritance is automatically disabled


    How to Activate a Terminal Services License Server and Install CALs Over the Internet


    In Windows Server 2003 and in Windows XP, W32Time frequently logs Event ID 50, and poor time synchronization occurs


    How to configure a firewall for domains and trusts


    Description of the License Logging Service in Windows Server operating systems


    How to reset security settings back to the defaults


    Systems that have changed the default Access Control List permissions on the %windir%\registration directory may experience various problems after you install the Microsoft Security Bulletin MS05-051 for COM+ and MS DTC


    Domain controller is not functioning correctly


    You cannot host TCP connections when Receive Side Scaling is enabled in Windows Server 2003 with Service Pack 2


    The Microsoft Windows Server 2003 Scalable Networking Pack release


    How to detect and recover from a USN rollback in Windows Server 2003


    Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003


    How to Troubleshoot Black Hole Router Issues


    How to use Netdom.exe to reset machine account passwords of a Windows Server 2003 domain controller


    Establishing preferred Windows 2000 Terminal Services license server


    Error Message "Target Principal Name is Incorrect" When Manually Replicating Data Between Domain Controllers


    Replicated files are copied over the network when you use the Distributed File System (DFS) Replication feature on a Windows Server 2003 R2-based computer


    Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments


    How to perform an authoritative restore to a domain controller in Windows 2000


    Troubleshooting journal_wrap errors on Sysvol and DFS replica sets


    Event ID 1004 is logged when a thin client tries to obtain a Terminal Services license


    Trust between a Windows NT domain and an Active Directory domain cannot be established or it does not work as expected


    The "Send As" right is removed from a user object after you configure the "Send As" right in the Active Directory Users and Computers snap-in in Exchange Server


    How To Use Netdom.exe to Reset Machine Account Passwords of a Windows 2000 Domain Controller


    Some firewalls may reject network traffic that originates from Windows Server 2003 Service Pack 1-based or Windows Vista-based computers


    Frequently asked questions about Windows 2000 DNS and Windows Server 2003 DNS


    You experience slow TCP/IP performance and long data transfer delay times on a Windows Server 2003-based computer or on a Microsoft WindowsXP x64 version-based computer


    How to enable user environment debug logging in retail builds of Windows


    "Windows cannot unload your registry class file" error message when you log off Terminal Services


    Service overview and network port requirements for the Windows Server system

    - Craig Landis

  • Customizing file compression in DFSR on Windows Server 2008 (no, not RDC)

    Hi, Ned here. If you’re a regular reader of the Filing Cabinet, you’ve probably already read about all the new features for DFS Replication (DFSR) added in Windows Server 2008. If not, trot on over here and drink your fill. Just to summarize some of these cool new features:

    Windows Server 2003 R2


    Windows Server 2008


    SYSVOL replicated with FRS service
    SYSVOL replicated with DFSR (via migration or by creating your domain in 2008 functional mode)
    RPC synchronous pipes
    RPC asynchronous pipes (when replicating between 2008 servers)
    Synchronous inputs/outputs (I/Os)
    Asynchronous I/Os
    Buffered I/Os
    Unbuffered I/Os
    Normal Priority I/Os
    Low Priority I/Os (this reduces the load on the system as a result of replication)
    4 concurrent file downloads
    16 concurrent file downloads
    Database recovery mechanism
    Improved Dirty Shutdown Recovery
    DFSR scheduler
    Algorithmic Enhancements for the scheduler
    Number of Replication Groups * number of Replicated Folders * number of simultaneously replicating Connections must be less than 1024
    Limited only by your hardware, network connections, and frequency of data change.

    But there’s something missing. There’s a little history here, so walk with me down technical memory lane.

    When DFSR was released on Windows Server 2003 R2 in February 2006, it had a list of file extensions that were non-compressible. These were:


    When you added a file to a DFSR content set and it was at least 64KB in size, the DFSR service placed a copy of the file in the Staging folder. The file had an alternate data stream added that held the computed Remote Differential Compression (RDC) signatures. RDC is what allows DFSR to only replicate the parts of the file that have changed. But files were also compressed with a standard compression algorithm called XPRESS, which is similar to ZIP or RAR compression. Any files that ended up in staging were compressed with XPRESS unless they had an extension that was on this list. Since there was no point in trying to shrink files that were already compressed (like ZIP or JPG), we simply didn’t bother; it wasted disk and CPU resources after all.

    After digging around in the product design request database here, looking at the source code, and pinging the developers, I came up short: the list was hardcoded. Rats. I wrote up a short internal article and promptly forgot about it.

    Fast forward to Windows Server 2008.

    You guessed it – we can do this now and here are the steps:

    1. Your Active Directory forest schema must have been extended with ADPREP to Windows Server 2008 (or you have installed a new Win2008 forest). If this is not done you won’t have the new attribute necessary for this to work.

    2. Setup DFSR on a few Win2008 machines (add the role through Server Manager, use DFSMGMT.MSC to configure, and let the servers pick up the new settings).


    3. On one of your domain controllers run ADSIEDT.MSC as a Domain Administrator.

    4. Navigate to your content set that you want to modify. So for example:


    cn=Public,cn=content,cn=Shared, cn=dfsr-globalsettings,cn=system,dc=cohowinery,dc=com

    5. Right-click the replicated folder (cn=public) and choose properties.

    6. Scroll down a ways and edit the attribute msDFSR-DefaultCompressionExclusionFilter.

    Important Notes: Any extensions we add in here will become the new rule for compression. So if we just add FOO then all files that are *.foo will no longer be compressed. We need to make sure we comma separate a list of files, and there must not be any spaces. Also, this list is destructive – if we put anything in here, then the default list of extensions like ZIP or JPG is ignored going forward unless we add them back. Finally, if the attribute is set to “<Not Set>” it will use the default extension list from above.

    7. So let’s add our new extension. We have an application that creates drawing files called *.NED. These NED files are already compressed so we don’t want DFSR to waste time trying to compress them more. In the Value field of our msDFSR-DefaultCompressionExclusionFilter attribute we all of the below:


    8. We click ok and exit out of ADSIEDIT. We wait for AD replication to complete. We wait for the DFSR servers to pick up the change through their polling process (or run DFSRDIAG POLLAD).

    Now when NED files are created or modified, they will no longer be compressed in the staging directory. Sweet! If for some reason you wanted to turn off all file compression, you can set the msDFSR-DefaultCompressionExclusionFilter attribute to contain just an asterisk. This would have the minor upside of saving some CPU and disk time when staging, but could have a significant downside in bandwidth consumption and replication time for larger files – so this is not recommended and you shouldn’t do this without significant testing in your lab environment. You cannot tailor RDC to only affect certain file types – it is limited to off/on/minimum size, just like in R2.

    And yes, we have a KB article for this in the works. The beauty of blogging means you don’t have to wait for it. :)

    - Ned Pyle

  • New KB articles January 13-19

    Here are the new Directory Services-related KB articles for the week. Also, although it isn't entirely new, I was reminded that we have the Windows Server 2008 command reference available now. So here are links to both the 2008 and 2003 versions. They are good as a quick reference when you need a command's syntax but also interesting to look at to be aware of tools you might not use on a daily basis. AD admins will want to familiarize themselves with Wevtutil and Icacls, both are new to Vista/2008.

    Windows Server 2008 Command Reference

    Windows Server 2003 Command-Line Reference

    KB Title


    After you reapply Internet Explorer Maintenance Group Policy settings on a computer that has Internet Explorer 7 installed, a pop-up blocker exception site that you manually added is missing


    Certain Windows XP-related user accounts and groups remain on the computer after you upgrade to Windows Vista


    You receive an access denied message on a Windows Vista-based computer when you click offline files that are not synchronized with the file server


    A Windows Vista-based computer may be unable to connect to the network after you configure the computer to use machine authentication and to validate the RADIUS server certificate


    On a computer that is a Windows Server 2003 domain member, you may experience problems when the name of the local user account is the same as the domain name


    A Windows Vista-based computer is frequently unresponsive for 30 seconds if the Documents folder is redirected to a shared folder, and the folder is made available offline

    - Craig Landis

  • Replacing an Expired DRA Certificate

    Hi, Tom here from the Directory Services team. One of the most common EFS issues we see is for an expired Domain Data Recovery Agent (DRA) certificate. It is also one of the easiest things to resolve. You may have seen the error Recovery Policy for this system contains an invalid recovery certificate or ERROR_BAD_RECOVERY_POLICY.


    Since you can’t extend the life of a Recovery Agent certificate you will need to remove the expired ones first. You start by opening up the Default Domain Policy and navigating to Encrypting File System. On the right side you will see the expired certificate. Right click on the expired certificate and select All Tasks | Export, and export the file to a .CER format. Although this certificate has expired it can still be used to decrypt files that have already been encrypted with this Recovery Certificate specified. (The original DRA private key resides in the Administrator profile of the first domain controller in the domain. If this profile or domain controller no longer exists you may not be able to use this certificate to decrypt files.) Once this is completed you should delete this certificate from the Policy.


    There are a couple of ways to get a new DRA certificate. If you are running an Enterprise Certificate Authority in your Domain you can choose Create Data Recovery Agent and a new certificate should be automatically installed. If you don’t have an Enterprise Certificate Authority or if you want the certificate to be good for a much longer period of time you can use the cipher command and create a self-signed certificate that will be good for 99 years.


    If you choose to create a Data Recovery Agent using your Enterprise Certificate Authority, please make sure to Export the newly created certificate and Export the Private key to maintain security. To do this, right-click on the new certificate, choose All Tasks and then Export. A wizard will guide you through the export process. Choose Yes, export the private key and then click next. As a best practice, the private key should be deleted from the system when a successful export is complete. Strong private key protection should also be used as an extra level of security on the private key while it exists on a file system (CD, Floppy, hard drive).


    Once the *.PFX file and private key have been exported, the file should be secured on a stable media in a secure location. For example, you may want to preserve the *.PFX file on one or more CD-ROMs that are stored in a safety deposit box, vault, etc. that has strict physical access controls. If the file and associated private key are lost, it will be impossible to decrypt any existing files that have used that specific DRA certificate as the data recovery agent.

    Creating a Self-Signed DRA Certificate

    You may decide that even with an Enterprise Certificate Authority you want to use a Self-Signed DRA Certificate. The benefit of doing this is that you will not have to go through this process again. The downside is that there will be no Key Archival of the Private Key.

    To create a new self-signed DRA certificate you need to open a command prompt on a XP/2003/Vista computer and then type cipher /r:filename where filename equals the name of the file you want to create. In my example below I used the name recovery. Use any password you want when prompted.


    With the newly created DRA certificate, you go back to the Default Domain policy we were looking at above and select Add Data Recovery Agent and then choose Browse Folders select the certificate you just created. If you get a pop up box saying Windows cannot determine if this certificate has been revoked and a question about Do you want to install this certificate just click Yes.

    Now you need to make sure that all of your clients will trust this newly created certificate so you need to import it into the Trusted Root Certification Authorities. Just right click and select Import and with a few more clicks you will almost done.


    Getting Your Clients to Use the New Certificate

    After you finish the above steps you need to refresh the Group Policy on the clients. You can do this by typing gpupdate /force at a command prompt. Once the policy has refreshed you should update the DRA information for the encrypted files by typing cipher /u at a command prompt. This will update only the files on the local machine so if you need to do this on a large number of machines you may want to put it in a login script. If you have any problems here you may need to reboot and try it again.

    Now that you have done all of this how can you be sure that your encrypted files have been updated with the new DRA? Just check the Advanced Attributes for an encrypted file and compare the thumbprint of the DRA to the thumbprint of the certificate you just created.


    You can also use the command EFSINFO /R /C in the directory where you have encrypted files and it will show you the DRA information. EFSInfo is a resource kit utility and can be downloaded at the following location:

    Remember to copy the .PFX file you created earlier and put it away somewhere for safe keeping. This is the file you will need to import onto a user’s computer to decrypt a file should the need ever arise. If you created a new DRA certificate using your Certificate Authority you should export that certificate along with the private key and put it away as well.

    Next time I’ll talk about some of the reasons you can get an Access Denied while trying to decrypt files.

    Other Reading:

    929103 Error message when you try to renew the default recovery agent certificate in Windows Server 2003, in Windows XP, or in Windows 2000: "This certificate cannot be renewed because it does not contain enough information to generate a renewal request";EN-US;929103

    241201 How to back up the recovery agent Encrypting File System (EFS) private key in Windows Server 2003, in Windows 2000, and in Windows XP;EN-US;241201

    - Tom Ausburne

  • New KB articles December 22-28

    Hi, Craig here. We are going to be posting the new KB articles that relate to Directory Services. Here are the ones published between Dec. 22-28. For the most part the articles will be for components that our group supports, but we'll also throw in ones that are related to networking, administration, or troubleshooting.

    KB Title


    Trace events in the log output are randomly lost on a Windows Vista-based computer that has the ETW trace log enabled


    The Reg.exe utility in Windows Server 2003 unexpectedly returns the REG_SZ registry type for registry values in the REG_EXPAND_SZ type


    The LsaLookupSids function may return the old user name instead of the new user name if the user name has changed on a domain controller


    The object picker ignores all the characters after the opening parenthesis when you query a group name that begins with an opening parenthesis on a Windows XP-based client computer

    - Craig Landis