I85PREP
⌘ K
Azure AZ-800 study materials
Azure AZ-800 study resources

Adatum - Replacing DFS-R with Azure File Sync on a 9 TB File Estate

Azure AZ-800 · Put your knowledge to work in context.

All case studies

Adatum - Replacing DFS-R with Azure File Sync on a 9 TB File Estate

Adatum has 9 TB of file data on FS01, a Windows Server 2019 file server, published through a DFS namespace. Three branch offices each run a Windows Server 2016 server that replicates 2 TB of that data with DFS-R. Branch users complain that opening large drawings takes minutes, and Monday-morning logons are slow while DFS-R catches up.

Adatum wants to replace DFS-R with Azure File Sync and cloud tiering: one Azure file share, FS01 as the primary server endpoint with 1.5 TB of local SSD, and each branch server with a 500 GB cache.

The data set contains a folder with 400,000 small files in a single directory, 300 GB of PST files, and 1.2 TB of CAD files that 40 engineers open daily. Adatum also wants to stop backing up to tape.

1. Can Adatum run DFS-R and Azure File Sync together during the transition? Explain the migration order.

Read the worked answer

No.

  • Azure File Sync does not support DFS-R. You cannot have both mechanisms replicating the same data, and you should not attempt a coexistence phase where a folder is a DFS-R replica member and a server endpoint at the same time - conflicts and orphaned data are the predictable outcome.
  • What you can keep is the DFS Namespace (DFS-N). The namespace is a referral layer, independent of replication, and it lets you move users from the old UNC path to the new server endpoints without changing shortcuts.

Migration order

  1. Stop DFS-R replication on the affected replicated folders and confirm the branches quiesce (no backlog).
  2. Remove the replicated folder from the replication group; back up each branch server's copy before deleting it.
  3. Open the firewall/proxy path for the Azure File Sync agent, then install and register the agent on FS01.
  4. Create the sync group and the FS01 server endpoint; enable cloud tiering after the initial upload completes, not before.
  5. Seed the branches from the Azure share (or from FS01), then add each branch as a server endpoint in the same sync group.
  6. Repoint the DFS-N folder targets and validate before decommissioning the old replica sets.

Do not skip step 2 to save time - DFS-R backlog plus an AFS initial upload on the same volume is how a "simple" cutover becomes a week-long incident.

2. Evaluate the proposed cache sizing and tiering configuration. What would you change, and why?

Read the worked answer

The 1.5 TB cache on FS01 is undersized

  • Roughly 1.2 TB of CAD files are opened daily by 40 engineers; that is the working set and it must stay resident. With a volume free-space policy reserving, say, 20% of a 1.5 TB volume, you have about 1.2 TB of usable cache before any other data. Every recall is a full download and a latency hit for 40 people at once.
  • Rule of thumb: size the cache to hold the active working set plus headroom, not as a fixed fraction of total data. For this estate, provision at least 2.5–3 TB on FS01; 9 TB of data does not need to be local, but the 1.2 TB that is touched daily does.

Policy settings

  • Enable volume free space tiering (e.g. 20%) so tiering never fills the disk and stalls the server.
  • Add a date policy (e.g. files not accessed in 30+ days) for the archive-style content, but exclude the CAD folders from aggressive date tiering - aging out a file someone opens weekly defeats the purpose.
  • Exclude the 300 GB of PST files. They are locked, they churn in place, and they are the worst possible fit for a tiering engine. Move them to another solution or remove them from the sync group entirely.
  • The 400,000-file directory makes the initial upload and any directory enumeration slow. Seed it during a quiet window, and expect the initial sync to take substantially longer than the byte count suggests.

Branch caches at 500 GB are fine only if the branch working set is genuinely small - verify it from file-access data rather than assuming.

3. The CIO reads that Azure File Sync keeps a copy in Azure and proposes cancelling the tape backup contract. Respond, including what the replacement should be.

Read the worked answer

No - Azure File Sync is a replication and tiering service, not a backup.

  • Deletions and ransomware propagate. A file deleted or encrypted on a server endpoint is deleted or encrypted in the Azure share. There is no retention window you can roll back to.
  • Cloud tiering means the share holds the only copy of tiered files in some designs, which raises the stakes rather than lowering them.
  • There is no point-in-time restore, no immutable copy, and no ability to recover a server that has lost both its cache and its volume.

What to put in place

  1. Azure Backup for the file data: either back up the Azure file share with share snapshots and a vault policy, or run the MARS agent on the on-premises file server for the local volumes. Prefer the share-level backup so recovery does not depend on a server that may itself be the thing that failed.
  2. Retention that matches the business requirement (daily/weekly/monthly), with at least one copy that is immutable or soft-deleted so ransomware cannot encrypt it.
  3. A tested restore of a folder and of a whole share. A backup contract you have not restored from is a hope, not a control.
  4. Keep soft delete on the Azure file share as a first-line guard against accidental deletion - it complements backup, it does not replace it.

Tell the CIO plainly: retiring tape is fine; retiring backup is not. The sync service changes where the copy lives, not whether you can go back in time.