File Replication Service (FRS)—with
all its Burflags, cryptic logs and hotfixes—
was a fly in the ointment for
admins ever since its implementation
with Windows 2000.When Microsoft
released Windows Server 2003 R2,
administrators finally found some
relief with the improved, efficient
and more reliable replication engine
known as Distributed File System
Replication (DFSR).
Unfortunately in R2, Microsoft only
had time to add DFSR to replicate
DFS data, meaning that System Volume
(SYSVOL) data still required the
use of FRS for replication. In Windows
2008, users can now migrate SYSVOL
to use the new DFSR engine and turn
off FRS—once and for all.
DFSR (not FRS) is the replication
engine used for SYSVOL upon initial
installation of a Windows 2008
domain. But when you upgrade a
Windows Server 2003 domain to
Windows 2008, FRS will replicate
SYSVOL, not DFSR. You must migrate
from FRS to DFSR for SYSVOL; DFSR
replication for DFS shares is the same
as it was in R2.
SYSVOL migration to DFSR can
be compared to the Domain Rename
operation introduced in Windows
Server 2003. It uses a command-line
utility, DFSRMig.exe. There are several
phases you must initiate using the
command-line tool, and this all must
be initiated from a single machine. Like Domain Rename, it depends on
Active Directory (AD) replication to
transfer instructions to all DCs; however,
SYSVOL migration to DFSR is more
resilient and offers users an escape
route. You can back out of the migration
prior to implementing the final
step.
Preparing for the migration
Every migration process involves
some prior preparation. Following are
some prerequisites that must be met
before beginning the move.
- Set the domain functional level to Windows Server 2008 using the same method that you did in Windows Server 2003.
- Ensure that FRS is healthy. Tools
such as Ultrasound, Sonar and FRSDiag
can be used to monitor its health. Be
sure that the staging directories are
not backed up, and look for errors and
warnings in the NTFRS event logs.
- Be sure that AD replication is
healthy. To perform a quick check,
use the Repadmin/Replsum/bysrc/
bydest/sort:Delta command.
- Understand replication latency in
your forest to get an idea of how long
DFSR migration will take.
- Back up the existing SYSVOL folder.
If FRS is healthy and staging directories
are empty, you only need to
back up one of the DC's SYSVOL.
This should be done on the Primary
Domain Controller (PDC).
- DFSR should have started by default,
but double check.
- Locate the DFSRmig.exe tool in
%windir%\System32. This only exists
on DCs. Figure 1 shows the DFSRmig
help file, which will be beneficial
during migration.
- The entire migration process
will take place from within the PDC.
Be sure that you have access to it.
FIGURE 1 ...
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
(click to enlarge)
[IMAGE]
Four migration steps
There are four steps to this migration
process, each of which is referred to
as a "State."
State 0: Start—This is the default
state for a domain that was upgraded to Windows Server 2008
domain functional mode. No
actions have been performed.
NOTE: A newly installed Windows
2008 domain that has always been
in domain functional mode will show
an initial state of Expired.
State 1: Prepared—Creates a new
SYSVOL_DFSR folder, and copies
SYSVOL contents to it.
State 2: Redirected—Points the
SYSVOL share path to the
SYSVOL_DFSR folder, and then
restarts Netlogon.
State 3: Eliminated—Deletes old
NTFRS AD objects and the SYSVOL
folder.
NOTE: This is the last point in the
migration process in which you can
revert back to FRS and SYSVOL.
Moving to the next migration state
is destructive.
In terms of the replication engine,
this migration is a gradual move from
FRS to DFSR (Table 1).
TABLE 1
[IMAGE]
Global migration state and local migration state
The global migration state is a global
"directive" that includes any instructions
the PDC gives to other DCs in
the domain to perform local operations
and obtain a certain state. When
using the dfsrmig/setGlobalState 1
command, the state directive is stored
in Active Directory and then replicated
to all DCs.When each DC obtains
the state information, it begins a local
migration process to bring itself up
to that state.
Administrators performing this
migration should know when all DCs
have performed their local operations
before transitioning to the next state.
Two commands should be used to
do this:
- DFSRmig/getGlobalState—Returns
what the global "directive" is. It's
not a report of what the DCs have
achieved, but it alerts you that you've
instructed the DCs to get to a specific
state using the /setGlobalState
command.
- DFSRmig/getMigrationState—
Reports if all DCs have achieved a
particular state. This command also
reports which DCs haven't achieved
a certain state. If DCs remain in this
condition, investigate the cause
(i.e., broken replication, network issue,
etc.), and correct it. The DC will
proceed once the condition is fixed.
NOTE: While these commands can
be run on any DC, Microsoft recommends
running them on the PDC to
check the migration progress.
Migrating to DFSR
- You should begin at Start State:
No command needed. If you issue a
DFSRmig/getGlobalState, it should
read Start. If it denotes Eliminated, you
have either achieved the migration,
or it is a native domain and not an
upgradedWindows 2008 domain.
- Migrate to Prepared State:
DFSRMig/setGlobalState 1.
- Create global settings and global
AD objects.
- Create member objects for readonly
domain controllers (RODCs).
- Create a SYSVOL_dfsr folder.
- Robocopy copies SYSVOL
contents to SYSVOL_dfsr folder.
- Local AD objects are created.
- FRS remains as the SYSVOL
replication engine.
- DFSRMig/getMigrationState—
Ensure that all DCs are at State 1.
- Netlogon stops sharing SYSVOL.
- SYSVOL path points to
SYSVOL_dfsr.
- Netlogon shares SYSVOL.
- DFSRMig/getMigrationState—
Ensure that all DCs are at State 2.
- Eliminated state—DFSRMig/
setMigrationState 3
- You cannot revert to FRS after
this step.
- Delete NTFRS AD objects.
- Delete SYSVOL folder.
- NTFRS does not stop automatically
if it's used to replicate non-
SYSVOL (DFS) folders. An admin
must stop and disable it manually.
- Validate: DFSRMig/get
MigrationState—Ensure that all
DCs are in the Eliminated State.
- Be sure that replication is healthy
and that policies are replicating.
Check the event log for errors.
Reverting back to FRS
The ability to revert back to FRS if
something goes wrong makes this
migration low risk. How this occurs
is the interesting aspect.
During the migration process, at
State 3: Redirected, you will replicate
SYSVOL with DFSR, but FRS is still
present.
Suppose you determine that the
new DFSR structure, which has been
replicated under the folder SYSOVOL_
DFSR, is not replicating properly.
This may occur because one of the
DCs isn't getting updates to the Redirected
State or there is an AD replication
problem. This also could mean
that the maintenance window that
administers this will expire in 30
minutes. There are several things
that can happen, but you can try
again.
To back out, use the /setMigrationState command and set the migration
to an earlier state. For example, if you
want to back all the way out of the
migration at State 2: Redirected,
instruct the system to go back to
State 0 using the command:
DFSRmig/setMigrationState 0
This moves DCs back to the Start
State. If you want to revert back one
step, you could also move to State 1
using the command:
DFSRmig/setMigrationState 1
If AD replication fails, there may
be a network outage. If so, fix the AD
replication problem first.When the
global directive is sent to that DC, the
migration will occur and no additional
intervention is needed.
[IMAGE]Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.
