13.8 Migrating DFS Namespaces & DFS Replication to Azure File Sync

Migrating DFS Namespaces & DFS Replication to Azure File Sync

The AZ-800 blueprint lists "Migrate Distributed File System (DFS) to Azure File Sync" as its own objective inside Configure and manage Azure Files. It is a favourite scenario item because DFS-N and DFS-R behave completely differently when Azure File Sync (AFS) arrives: one is a namespace service that AFS happily lives alongside, the other is a competing replication engine that must eventually be retired. Confusing the two is the single most common mistake on this objective.

---

1. DFS-N and DFS-R Interoperability, Side by Side

Azure File Sync supports interoperability with both DFS Namespaces (DFS-N) and DFS Replication (DFS-R), but the intent is different in each case.

Because DFS-N only hands out referrals and never moves file data, it is complementary: users keep hitting \\contoso.com\public, while AFS quietly handles sync and cloud tiering behind each folder target. Migration to AFS therefore usually leaves the namespace untouched, which is precisely why DFS-N is the low-risk half of this objective.

DFS-R is different. Two independent replication engines writing to the same folder produce conflicts, so Microsoft's guidance is to replace it. There are, however, three documented scenarios where DFS-R and AFS legitimately run together:

1. You are mid-migration from a DFS-R deployment to an AFS deployment.
2. Not every on-premises server that needs a copy of the data can connect directly to the internet.
3. Branch servers consolidate data onto a single hub server, and you want AFS on the hub.

Rules for running DFS-R and AFS side by side

When both are running at once, three constraints apply, and each maps directly to an exam distractor:

• You must disable Azure File Sync cloud tiering on volumes that hold DFS-R replicated folders.
• You shouldn't configure server endpoints on DFS-R read-only replication folders.
• Only a single server endpoint may overlap a DFS-R location. Multiple server endpoints overlapping other active DFS-R locations can lead to conflicts.

[!WARNING] The cloud-tiering prohibition is the one candidates miss. Tiering replaces a local file with a reparse point; DFS-R sees a changed file and attempts to replicate a stub, which corrupts the replication group's view of the data. Cloud tiering stays off for the entire coexistence window.

---

2. The Documented DFS-R to Azure File Sync Migration

Microsoft publishes an ordered procedure. The sequence matters — the exam tests when DFS-R is disabled and when cloud tiering may finally be enabled.

+---------------------------------------------------------------------------+
|            DFS-R  ->  AZURE FILE SYNC MIGRATION SEQUENCE                  |
|                                                                           |
|  1. Create a sync group representing the DFS-R topology being replaced    |
|  2. Pick the server holding the FULL data set; install AFS on it          |
|  3. Register it, create a server endpoint -- CLOUD TIERING OFF            |
|  4. Let ALL data sync up to the Azure file share (cloud endpoint)         |
|  5. Install + register the AFS agent on the REMAINING DFS-R servers       |
|  6. ---- DISABLE DFS-R ----                                               |
|  7. Create a server endpoint on each -- CLOUD TIERING STILL OFF           |
|  8. Let sync finish; test the topology                                    |
|  9. ---- RETIRE DFS-R ----                                                |
| 10. NOW enable cloud tiering on any server endpoint as needed             |
+---------------------------------------------------------------------------+

Written out:

1. Create a sync group to represent the DFS Replication topology you're replacing.
2. Start on the server that has the full set of data in the DFS-R topology. Install Azure File Sync on that server.
3. Register that server and create a server endpoint for it. Don't enable cloud tiering.
4. Let all of the data sync to your Azure file share (the cloud endpoint).
5. Install and register the Azure File Sync agent on each of the remaining DFS-R servers.
6. Disable DFS-R.
7. Create a server endpoint on each of the DFS-R servers. Don't enable cloud tiering.
8. Ensure that sync finishes, and test your topology as needed.
9. Retire DFS-R.
10. You can now enable cloud tiering on any server endpoint as needed.

Three ordering facts carry the marks:

• The authoritative-copy server goes first (step 2). Seeding from a partially-populated DFS-R member risks uploading an incomplete namespace as the cloud master.
• DFS-R is disabled at step 6, after the agents are installed on the remaining servers but before their server endpoints are created. Creating a second server endpoint while DFS-R is still replicating is what produces conflict files.
• Cloud tiering is enabled only at step 10, after DFS-R is retired — never during the migration.

---

3. Keeping the Namespace Stable with DFS-N

Because DFS-N is fully supported with AFS, the user-visible path survives the migration untouched. A typical hybrid end state:

                 \\contoso.com\public   (DFS-N namespace root)
                            |
             +--------------+--------------+
             |                             |
      \\FS-HQ\public              \\FS-BR1\public
      (AFS server endpoint)        (AFS server endpoint)
             |                             |
             +---------> Azure file share <-+
                        (cloud endpoint)

Both folder targets are now AFS server endpoints syncing to one cloud endpoint, and DFS-N continues to steer clients to the site-local target. If you decommission a branch file server, you retarget or remove its DFS-N folder target; clients following \\contoso.com\public never see a changed path.

For a full lift to the cloud, Azure Files can be surfaced directly under a DFS-N folder target, letting you retire the on-premises server while keeping the namespace.

---

4. Related Constraints Worth Memorizing

Pre-seeding remains available for the bulk data movement itself — RoboCopy with /MIR /COPY:DATSO /DCOPY:DAT, Azure Data Box, or AzCopy — but pre-seeding is a data transfer optimization, not a substitute for the DFS-R retirement sequence above.

---

5. Exam Traps