Jaa

Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style

  • Artikkeli

Hi, Ned here again. You’ve probably already started reading about how Windows Server 2008 now supports using Distributed File System Replication (DFSR) technology to synchronize SYSVOL. This means that the legacy File Replication Service (FRS) is no longer necessary and all the DFSR advantages for reliability, scalability, and performance can be realized.

As with any migration, it’s important that you enter and leave in a stable state – we don’t want to fight the domain environment’s issues midstream in the migration after all. So today we will talk about how to validate that replication is working in FRS before you migrate and that DFSR is working when the migration is completed.

Before I begin – the official TechNet documentation for the migration process is still in progress. Also, when it is released the docs will reference using (a not yet released version of) the Ultrasound tool. This post will not be about Ultrasound. Instead, I am going to use a combination of FRSDIAG and the DFSR Propagation tool. This is not as sophisticated as using Ultrasound, but it’s considerably simpler and easier – both good selling points.

Understanding the Migration Process

Before you attempt the migration, there is some mandatory reading. Even though I stated earlier that the SYSVOL TechNet docs are coming, there is an outstanding series of articles from the DFSR Core Development team PM Mahesh Unnikrishnan that covers the process in a systematic manner:

SYSVOL Migration Series: Part 1 – Introduction to the SYSVOL migration process SYSVOL Migration Series: Part 2 – Dfsrmig.exe: The SYSVOL migration tool SYSVOL Migration Series: Part 3 - Migrating to the 'PREPARED' state SYSVOL Migration Series: Part 4 – Migrating to the ‘REDIRECTED’ state SYSVOL Migration Series: Part 5 – Migrating to the ‘ELIMINATED’ state

These docs cover the entire migration end to end. You will see in Part 3 that it quickly covers verifying your FRS replication health with SONAR, FRSDIAG, or Ultrasound (and I’d throw MOM 2005 or SCOM 2007 in there as well).

FRS testing prior to setting migration to the Prepared state

When migrating SYSVOL, the Prepared state is phase where FRS is still replicating files and the SYSVOL share still points to its old location. We need to make sure that there are no existing replication problems with FRS before we go buck wild with DFSR – even though DFSR will do its own replication once we enter prepared state, the data it starts from FRS with needs to be consistent . Not to mention sensitivity about FRS will be heightened now and existing issues with FRS are more likely to be:

1) Noticed.
2) Blamed on the migration process.

So let’s do this:

1. Download FRSDIAG.

2. Install it on PDC Emulator.

3. Create a file called FRSCANARYTEST.TXT in the \\domain\sysvol\domain path

(ex: \\contoso.com\sysvol\contoso.com\FRSCANARYTEST.txt).

clip_image002

4. Verify there are no other TXT files in this location.

5. Allow the file enough time to replicate to all DC's in the domain (you need to have an understanding of what expected SYSVOL replication time is in your environment – it could be several days in severely latent networks).

6. Run FRSDIAG and click Browse under 'Target Servers' - add all DC's in that domain.

clip_image004

7. Click: Tools -> Propagation File Tracer

clip_image006

8. Change the path to <your fqdn domain>\*.txt

(ex: contoso.com\*.txt)

clip_image008

9. Set 'Expected number of hits' to 1.

10. Click GO.

11. Examine results to verify all servers return green, status done, results passed. If not, examine the failed servers directly – are there errors in the server details tab in FRSDIAG, the FRS event logs and is SYSVOL shared out?

clip_image010

DFSR testing prior to setting migration to the Eliminated state

So everything was fine with FRS (or not, and we fixed it) and we’ve moved through the Prepared and Redirected phases of the SYSVOL migration. Now we’re ready to move into the Eliminated state and we want to make sure that DFSR is working fine for SYSVOL replication – because there’s no going back! We won’t need any add-on tools now because DFSR gives us its own reporting mechanism:

1. Start DFSMGMT.MSC.

2. Expand Replication -> Domain System Volume

3. Select 'Create Diagnostic Report'

clip_image012

4. Select 'Propagation Test'

clip_image014

5. Select SYSVOL Share, select the PDCE as the propagation server, click Next.

clip_image016

6. Select Create and Close. Wait as long as it should take for your replication convergence to occur (only you can know this for your environment)

7. Select 'Create Diagnostic Report'

8. Select 'Propagation Report'

9. Select SYSVOL Share, select the PDCE as the propagation server, click Next.

10. Create and Close.

11. Open the propagation report when prompted and verify file replicated to all
DC's.

And lookee lookee:

clip_image018 clip_image020 clip_image022

Pretty slick. It told us where we replicated from, to which DC’s, and how long it took. If the propagation file had not yet shown up yet or there had been errors, we’d see them here.

Wrap Up

As you can see, testing the state of SYSVOL replication doesn’t require complex or expensive tools. This post was not intended to be the final word of course – testing your AD replication is just as important, since ultimately the settings in the Active Directory database are what FRS and DFSR use to configure replication. I intentionally did not go into detail on what to do if you find file replication problems either, since they’ve been pretty documented for years now. If you’re interested in that kind of info anyway, please let us know.

Ned Pyle

Comments

  • Anonymous
    May 23, 2008
    PingBack from http://blog.binaryfactory.ca/2008/05/verifying-file-replication-in-2008-dfs/

  • Anonymous
    July 02, 2008
    The comment has been removed

  • Anonymous
    December 16, 2008
    After running dfsrmig /setglobalstate 3 on my test domain, it ran fine. However, I am getting residual errors in the FRS log saying: "The File Replication Service cannot replicate c:system volumesysvoldomain because the pathname of the replicated directory is not the fully qualified pathname of an existing, accessible local directory." FRS still wants to replicate the old sysvol path. The DFSRMIG GETGLOBALSTATE and GETMIRATIONSTATE all say succeded. Any idea why these errors are showing?

  • Anonymous
    December 16, 2008
    Hi, We've seen one circumstance where some of the FRS AD objects might not get cleaned up (the details escape me and I'm not in the office to check - I seem to recall it had to do with RODC's). That was not the error I remember though (in fact, there were no errors - we just dangled behind some AD FRS data that never got used by the service). If you look in ADSIEDIT.MSC under the DC objects CN=NTFRS Subscriptions,CN=ARRENC1,OU=Domain Controllers,DC=a,DC=com do you still see the NTFRS objects for SYSVOL? And in the CN=File Replication Service,CN=System,DC=A,DC=COM path? Is there anything you can tell me about how you reproduced this scenario? Do your test machines also host custom FRS/DFSN replica sets?

  • Anonymous
    May 01, 2009
    The comment has been removed

  • Anonymous
    May 01, 2009
    The comment has been removed

  • Anonymous
    May 14, 2009
    It’s come to my attention (in a blunt object kind of way) that you’ve been waiting to migrate from Windows