Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style
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
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.
7. Click: Tools -> Propagation File Tracer
8. Change the path to <your fqdn domain>\*.txt
(ex: contoso.com\*.txt)
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?
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'
4. Select 'Propagation Test'
5. Select SYSVOL Share, select the PDCE as the propagation server, click Next.
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:
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