The event ID 2104 is logged in the DFS Replication log on a downstream server when the DFS Replication service stops

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=supportNote The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Workaround for the DFS Replication error

To work around this issue, manually perform a tombstone operation on the old ID_RECORD record and creates a new global version sequence number. To do this, follow these steps:

1. Determine the originating DFSR server and the file path. This consists of the file GVSN's GUID and the RG Name, where the CSID's match.
   
   So in the above case, for example:
   
   20091213 01:55:56.862 8820 RDCX 808 Rdc::SeedFile::Initialize The hashes coincide. The download is redundant, uid:{8BB53DB2-9446-47D0-94E0-F93A56589D18}-v2357 gvsn:{58A90409-3866-4DC1-B474-BE1C8DE41B84}-v22461 fileName:4-5269.dot csId:{B890770A-6043-4004-A149-41E3A1935AC1
   
   20091213 01:55:57.705 8820 DOWN 5186 [ERROR] DownstreamTransport::RdcGet Failed on connId:{7D927665-24BF-4F16-B503-708AABDBC9AE} csId:{B890770A-6043-4004-A149-41E3A1935AC1} rgName:SOME_RG update:
   
   Run:
   
   
   DFSRDIAG.EXE GUID2NAME /rgname:"SOME_RG" /guid:{58A90409-3866-4DC1-B474-BE1C8DE41B84}
   

2. Now that you know the server, you can go to that computer.

   • If the upstream server is running Windows Server 2008 R2, run the following command:

     DFSRDIAG IDRECORD

   • If the upstream server is running Windows Server 2003 or Windows Server 2008, run the following command:

     WMIC.EXE /namespace:\\root\microsoftdfs path dfsridrecordinfo.Uid="<UID of the duplicated GVSN on the upstream server side>" call getfullfilepath

3. Locate the full path of file having a problem.

   1. If using Windows Server 2008 R2, use DFSRDIAG IDRECORD. For example:
      
      
      DFSRDIAG.EXE IDRECORD /UID:{8BB53DB2-9446-47D0-94E0-F93A56589D18}-v2357

   2. If using Win2003 or Win2008, use WMIC. For example:
      
      WMIC.EXE /namespace:\\root\microsoftdfs path dfsridrecordinfo.Uid="{8BB53DB2-9446-47D0-94E0-F93A56589D18}-v2357" call getfullfilepath
      

4. Make a copy of the file (in the example above "4-5269.dot") in the same folder and call it some random name like "fixed.ned".

5. Delete the old file (in the example above "4-5269.dot").

6. Rename the copied file back to the original name (so from "fixed.ned" back to "4-5269.dot").

7. This will tombstone the old ID_RECORD and create a new GVSN, and all will be well.

Workaround example

For example, assume that you receive the following debug log on the affected downstream server:
20091213 01:55:56.862 8820 RDCX 808 Rdc::SeedFile::Initialize The hashes coincide. The download is redundant, uid:{8BB53DB2-9446-47D0-94E0-F93A56589D18}-v2357 gvsn:{58A90409-3866-4DC1-B474-BE1C8DE41B84}-v22461 fileName:4-5269.dot csId:{B890770A-6043-4004-A149-41E3A1935AC120091213 01:55:57.705 8820 DOWN 5186 [ERROR] DownstreamTransport::RdcGet Failed on connId:{7D927665-24BF-4F16-B503-708AABDBC9AE} csId:{B890770A-6043-4004-A149-41E3A1935AC1} rgName:SOME_RG update: In this scenario, the "{58A90409-3866-4DC1-B474-BE1C8DE41B84}-v22461" GUID and the "SOME_RG" RgName have the same "{B890770A-6043-4004-A149-41E3A1935AC1}" CSID. Therefore, follow these steps to work around the delay issue in this scenario:

1. Run the following command to obtain the problematic upstream server name:
   

   DFSRDIAG.EXE GUID2NAME /rgname:"SOME_RG" /guid:{58A90409-3866-4DC1-B474-BE1C8DE41B84}

2. On the upstream server, find the GUID of the duplicated global version sequence number in its debug log. Then, run one of the following commands to obtain the full path of the file that has the duplicated global version sequence number:
   

   • For Windows Server 2008 R2, use the following command:
     

     DFSRDIAG.EXE IDRECORD /UID:{8BB53DB2-9446-47D0-94E0-F93A56589D18}-v2357

   • For Windows Server 2003 R2 or for Windows Server 2008, use the following command:WMIC.EXE /namespace:\\root\microsoftdfs path dfsridrecordinfo.Uid="{8BB53DB2-9446-47D0-94E0-F93A56589D18}-v2357" call getfullfilepath

3. Assume that you obtain the "4-5269.dot" file name. Copy the "4-5269.dot" file, and then rename the copied file to the "fix.dot" file name. Make sure that you put the "4-5269.dot" and "fix.dot" files in the same folder.
   

4. Delete the "4-5269.dot" file.

5. Rename the "fix.dot" file to the "4-5269.dot" file name.

By following these steps, you can work around the DFS Replication database issue in the example.