January, 2008

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.

- Craig Landis

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:

http://www.microsoft.com/downloads/details.aspx?FamilyID=9c70306d-0ef3-4b0c-ab61-81da208f5c47&DisplayLang=en

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"
http://support.microsoft.com/default.aspx?scid=kb;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
http://support.microsoft.com/default.aspx?scid=kb;EN-US;241201

- Tom Ausburne

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: http://code.msdn.microsoft.com/restoredfsr

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

CSCRIPT.EXE RESTOREDFSR.VBS

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"

objXMLDoc.load("C:\your_replicated_folder\DfsrPrivate\ConflictAndDeletedManifest.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

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 Microsoft.com. 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).

- Craig Landis