By the end of this build sheet a small business has retired its last file server: the S: drive every employee has known for twenty years now lands on an Azure file share, mapped automatically at sign-in, with the same folders and the same permissions, and the server in the closet is powered off with nothing left to miss. One share, one weekend, no DFS, no drama.
Prerequisites: the destination share with identity working ([AF 1.1]/[AF 2.1]; for a cloud-native shop that means Entra-joined Windows 11 24H2+ devices, for an AD shop the hybrid path with synced groups); a network path decided per [AF 3], and for a small shop being honest, that is usually the hardened public endpoint from a business ISP that passes 445, or Global Secure Access if the team roams; the storage account key for the copy; and a Saturday. The worked example throughout: a 900 GiB S: drive on a dying 2016 server, 30 staff, folders for Office, Jobs, and Archive.
Step 1: Build the destination to match what users know
Create the share company sized per [AF 4] (for the example: 1,024 GiB provisioned on HDD provisioned v2 at default IOPS and throughput, about $60 a month at list), and stamp the three top-level folders with ACLs before copying, per the [AF 2.1] portal or RestSetAcls method: AZF-Company-RW modify on Office and Jobs, read on Archive; AZF-Company-Admins modify everywhere. Do not redesign the folder tree during a migration; users forgive a new location for the S: drive, they do not forgive a reorganized one. Redesign is a separate project for a calmer month.
Step 2: Copy Friday night, delta Saturday
The [AF 6.1] RoboCopy discipline, shrunk to one server. From the server itself (it is the machine with the data and, usually, the best circuit). One warning carries over unchanged and matters more here, because a small shop has one share and no second chance: /MIR deletes anything at the destination that is not at the source. Run it with /L appended first, confirm the summary describes the copy you intended, and keep users off the destination until cutover.
net use M: \\stvciofiles01.file.core.windows.net\company `
/user:Azure\stvciofiles01 <storage-account-key> /persistent:no
robocopy D:\Shares\Company M:\ /MIR /COPY:DATSO /DCOPY:DAT /B `
/MT:16 /R:2 /W:1 /NP /NFL /NDL /XD '$RECYCLE.BIN' "System Volume Information" `
/UNILOG:C:\mig-pass1.logAt 900 GiB on a 200 Mbps uplink the arithmetic says about ten hours at perfect line rate, which is the number to plan around and not the number you will get: small files, per-file overhead, a circuit shared with a working office, and antivirus on the source all push it out, and a tree of many small files can take several times the theoretical figure. Measure rather than assume. Copy one representative folder, note the achieved rate, and extrapolate from that before you commit to a Saturday. Saturday morning, stop the old share (net share Company /delete stops new writes while leaving the data in place), run the same command once more as the final delta, and read the log tail: FAILED must be 0. A cloud-native shop whose ACL principals were never synced to Entra skips ACL fidelity intentionally (the copied ACEs are dead on arrival per [AF 6]), copies with /COPY:DAT instead, and relies on the Step 1 folder ACLs, which for a thirty-person company modeled in three groups is not a compromise, it is the whole permission model, now legible for the first time in years.
Step 3: Map the drives, three ways
Users do not want a migration; they want S: to be there Monday. Pick the one mechanism that matches how the fleet is managed and delete the other two from your plan.
Domain or hybrid fleet, Group Policy. The mapping your users already have probably lives in a GPO, so the migration is an edit, not an invention. In Group Policy Management, open the policy holding the map, User Configuration, Preferences, Windows Settings, Drive Maps, and update the existing S: item:
| Setting | Value | Why |
|---|---|---|
| Action | Replace | Tears down the old mapping and creates the new one in a single item; Update leaves stale properties behind. |
| Location | \\stvciofiles01.file.core.windows.net\company | Always the FQDN, never an IP; DNS steering from [AF 3.1] depends on it. |
| Drive letter | S: | The letter is the user experience; keep it. |
| Reconnect | Enabled | Persistent across sign-ins. |
| Item-level targeting | The share’s RW/RO security groups | Only people with access get the letter; everyone else never sees a broken drive. |
Entra-joined fleet, Intune. No GPO applies, so deliver the mapping in user context through Intune. Be clear-eyed about the delivery mechanism: a platform script runs once per user and is not a sign-in agent, so it will not repair a mapping a user breaks next Tuesday. Use a remediation with a detection script and a schedule if you want the mapping to be self-healing, which on a fleet you no longer visit in person you do. Detection has to be sharper than “does S: exist,” because the failure that actually happens is S: existing and pointing at the dead server:
# Detection: exit 0 when S: is mapped to the correct target, 1 otherwise
$target = "\\stvciofiles01.file.core.windows.net\company"
$mapping = Get-SmbMapping -LocalPath "S:" -ErrorAction SilentlyContinue
if ($mapping -and $mapping.RemotePath -eq $target -and $mapping.Status -eq "OK") {
exit 0
}
exit 1
# Remediation: remove a wrong or broken mapping, then create the right one
$target = "\\stvciofiles01.file.core.windows.net\company"
$mapping = Get-SmbMapping -LocalPath "S:" -ErrorAction SilentlyContinue
if ($mapping) { Remove-SmbMapping -LocalPath "S:" -Force -ErrorAction SilentlyContinue }
New-SmbMapping -LocalPath "S:" -RemotePath $target -Persistent $trueNo credentials appear anywhere in that script, and that absence is the point: the device’s Entra Kerberos machinery from [AF 1.1] authenticates the user silently. If a credential prompt appears, the identity chain is broken (registry setting, consent, CA exclusion), and the fix is never to type a password into the mapping.
The hand-managed handful, plain net use. For the five-person office with no management plane at all, the honest answer is the command that has worked since the nineties, run once per machine per user profile:
net use S: \\stvciofiles01.file.core.windows.net\company /persistent:yesWindows remembers persistent mappings per user and reconnects at sign-in. The known wrinkle: reconnection races the network at boot, and a cold laptop sometimes shows S: with a red X until first click. That is cosmetic; the mapping revives on access. What you must not do in any of the three mechanisms is embed the storage account key in a mapping or script, because that converts every workstation into a copy of your superuser credential.
Step 4: Monday-morning validation
The end-to-end test is a standard user, not you: one member of the RW group signs in on their normal machine, S: appears without a prompt, a file saves into Jobs, and a file in Archive opens but refuses a save. One member of the RO population confirms the inverse. On any failure, triage in this order because it matches observed frequency: the device cannot pass 445 on its current network (the [AF 1.1] Step 6 test settles it in ten seconds), the mapping mechanism has not applied yet (gpupdate /force or an Intune sync), then the identity chain per [AF 2.1]. Keep the old server powered on but shared-out-of-existence for thirty days, then let it go. For the small shop the decommission list is short and satisfying: cancel the server’s backup agent, point the [AF 7.x] cloud backup at the share instead, rotate the storage key that traveled through Step 2, and recycle a machine that has been on borrowed time since 2022.
That is the whole migration for the shop that just wanted the server gone: the share from article two, the identity from article three, a Friday copy, and a drive letter mapped the old-fashioned way. What remains for every estate, small or large, is running the thing well, and that is where the series goes next: backup that survives ransomware, the three alerts worth having, and the disaster recovery story told without euphemism.
Azure Files
‹ Previous: [AF 6.1] Build Sheet: The Migration Run
Next: [AF 7] Operating Azure Files: Backup, Monitoring, and the DR You Actually Have ›
