About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
When a file server is lost, the first question is usually whether the files are safe. If the backup is good, they are. But a file server is more than a disk full of folders. Users do not open a folder on a disk; they connect to a share, by name, on a server, by name, with permissions that decide what they can do.
All of that can be missing after a restore that brought back every file perfectly. This article sets out, from Microsoft's documentation, what a Windows file server is made of beyond its data, and how to make sure a recovery brings all of it back.
What a file server is made of
In our reading, a Windows file server has at least five layers that a recovery must reproduce:
- The files and folders, with their own permissions, which a file backup protects. Permissions on files are a separate recovery responsibility.
- The share definitions: each share's name and the folder it points to.
- Share permissions: a separate set of permissions on each share, applied in addition to the file permissions.
- Share settings: options that change how each share behaves.
- The server's identity: its name and domain membership, which every path users have saved depends on.
A backup that captures only the first layer leaves the other four to be rebuilt by hand, from memory, during an outage.
Share definitions and share permissions live in the system, not the data
Microsoft's support article Saving and restoring existing Windows shares describes how Windows stores shares: share names and the permissions assigned to them are kept in the server's registry, not on the data volume. The article explains how to save them before, for example, reinstalling Windows or moving data drives to another server.
Two statements in that article are useful for planning, whatever method is used. First, about what is kept: Only permissions for domain users are restored. It explains that a local user's unique security identifier is lost. Second, about what is separate: NTFS permissions on folders and files are not affected when you save and restore the shares key.
In our reading, that second point confirms the split. Share permissions and file permissions are stored in different places, are restored by different means, and must both be right for users to have the access they had before.
The article also carries a caution about restoring share definitions onto a working server: This step overrides the shares that already exist on the Windows computer with the shares from the saved file. In our view, that makes it a rebuild tool, not something to apply to a server that already has shares people are using.
A note on that article: its steps are written for Windows NT, Windows 2000 and Windows Server 2003, and Microsoft lists it as applying to supported versions of Windows client. It was last updated in February 2026. In our view, its explanation of where shares are stored is still useful, but its procedure should not be followed on a current server without checking current guidance first. This article does not give its registry steps.
Share settings that are easy to forget
Shares carry settings that change how they behave, and those settings live with the share definition. Microsoft's reference for the PowerShell command New-SmbShare, which creates shares, lists many of them as options. Among them:
- Which files users can see. The folder enumeration option Specifies which files and folders in the SMB share are visible to users. With access-based enumeration, users only see the items they have permission to open. The cmdlet reference says this is disabled by default for new shares; its default is Unrestricted.
- Offline caching. The caching option Specifies the caching mode of the offline files for the SMB share.
- Encryption. An option indicates that the share is encrypted. Microsoft’s SMB overview explains that its security features protect data in transit between users and the server.
- Continuous availability, used on clustered file servers.
In our reading, each of these is a decision someone once made for a reason. Access-based enumeration may have been turned on so that staff do not see the names of folders belonging to other departments. Encryption may have been required for a share holding sensitive records. Offline caching may have been disabled for a share holding a database. A rebuilt share that omits them still works, which is exactly why the omission can go unnoticed: folder names become visible, data travels unencrypted, or files start being cached on laptops.
DFS namespaces have their own access-based enumeration setting. Microsoft's guide to Enable access-based enumeration on a namespace explains that Access-based enumeration hides files and folders that users do not have permissions to access. It notes that the feature is not enabled for namespaces by default, so in our view it is worth recording separately for each namespace as well as for each share.
Server-wide settings sit above the shares
Some settings apply to the whole server rather than to one share. Microsoft's overview What is SMB File Sharing for Windows and Windows Server? describes the protocol's security features: SMB provides multiple layers of protection including encryption, signing, NTLM blocking, and authentication rate limiting. In our understanding, their availability and defaults depend on the Windows version, and several can be set for the server as a whole, often through Group Policy, as well as or instead of per share.
In our reading, this matters in two ways after a rebuild. A server that was hardened by hand, rather than by policy, can come back with weaker settings than it had, and nothing will warn anyone, because clients still connect. And a server that is hardened by policy can come back stricter than some older clients or devices can handle, such as a scanner that saves to a share. Either way, the settings belong in the record of the server, and the policies that apply them belong in the recovery plan, with the domain they come from.
The access-based enumeration guide also notes a performance point worth knowing before a rebuilt server takes its full load: In some environments, enabling access-based enumeration can cause high CPU utilization on the server and slow response times for users. In our view, a replacement server should be sized with its real settings switched on, not tested with them off.
How a system state backup helps
Microsoft's reference for wbadmin start systemstatebackup describes how Windows Server Backup Creates a system state backup of the local computer. In our understanding, the system state includes the server's registry, and with it the share definitions and settings. The same reference notes one exclusion: Windows Server Backup does not back up or recover per-user registry hives as part of system state.
A system-state backup can preserve important machine configuration, but its restore requirements are narrower than “copy this onto another server”. Check the supported operating-system instance and recovery route before relying on it. A bare-metal recovery and a new-server rebuild are different paths. For a rebuild, keep a readable share and security inventory as well as the appropriate server backup.
The server's name is part of the data path
Users rarely type a server's name. It is built into mapped drives, shortcuts, links inside documents and spreadsheets, application settings and scripts. If a file server is rebuilt under a new name, paths that directly name the old server can fail, even if every share is recreated perfectly.
Microsoft's Storage Migration Service overview shows how Microsoft approaches the same problem in a planned migration. The service can Rapidly transfer files, file shares, and security configuration from the source servers, and can Optionally take over the identity of the source servers (also known as cutting over) so that users and apps don't have to change anything to access existing data.
In our reading of its source-to-destination transfer model, Storage Migration Service needs the source available for that transfer and does not replace a retained backup after the source is lost. In our reading, its value here is as a checklist: files, shares, security configuration and identity are the four things Microsoft moves to make a new server indistinguishable from the old one. A recovery plan for a lost server has to reproduce the same four, without the old server to copy from.
The overview also notes a constraint that applies just as much to recovery: if computers belong to a domain, they should all be in the same forest, and the destination must be in the same domain as the source to take over its domain name. In our view, recovering a file server into a different domain therefore raises identity questions about both the server and the security identifiers in its permissions.
A DFS namespace can reduce dependence on a particular server name, but the namespace also needs its own recovery plan. When users connect through a namespace path rather than a server name, the server behind it can be replaced by changing the folder target, without touching every shortcut.
Keep a readable record of the shares
In our view, the most useful single piece of preparation is a regularly refreshed, human-readable inventory of each file server's shares, stored somewhere other than the server itself. For each share, we suggest it records:
| Item | Why it matters in recovery |
|---|---|
| Share name and folder path | Recreates the path users connect to |
| Share permissions, by group | Separate from file permissions |
| Access-based enumeration | Controls what folder names users can see |
| Offline caching mode | Controls what is copied to users' devices |
| Encryption | Controls protection of data in transit |
| Continuous availability | Needed for clustered file shares |
| Server name and namespace paths | Every saved path depends on them |
PowerShell can list share properties, and that output makes a good basis for the record. This article does not give commands.
What we recommend
- Back up system state on each file server, as well as its data.
- Keep a readable share inventory outside the server, refreshed after changes.
- Grant share permissions to domain groups, not local accounts, which do not survive a move between servers.
- Record share settings alongside permissions, not only share names.
- Plan for the server's name: either rebuild under the same name, or move users onto namespace paths beforehand.
- Test rebuilding one share from the inventory on a test server, and compare it setting by setting.
- Check after any restore that users see what they should, and only that.
Accept the service through the paths users actually use
Test the restored service using a normal client identity and the recorded share or namespace name. Confirm that an authorised user can read and, where intended, write, and that a user outside the permitted group cannot. Compare share permissions with the file ACLs rather than treating either as sufficient on its own. Verify encryption, signing and caching requirements using the actual client population.
A server name must also resolve and authenticate correctly. DNS alone does not recreate domain identity, service principal names or application dependencies. Keep the failed source from returning with the same identity while its replacement is active. For clustered shares, the clustered role and its storage dependencies need their own recovery plan; a collection of standalone share definitions is not equivalent. Record what was verified from a client and what remains dependent on directory or cluster recovery before releasing the service to users.
Risks and limits of this article
- Based on Microsoft documentation as read on 11 November 2026.
- The share-saving support article was written for early Windows versions; its principles are quoted, its procedure is not.
- What system state contains is stated as our understanding.
- No shares, servers or backups were changed for this article, and no commands or registry paths are given.
Sources
Writer research: 11 November 2026. Independently reopened for review: 13 November 2026.
- Microsoft Learn: Saving and restoring existing Windows shares
- Microsoft Learn: New-SmbShare
- Microsoft Learn: Enable access-based enumeration on a namespace
- Microsoft Learn: What is SMB File Sharing for Windows and Windows Server?
- Microsoft Learn: wbadmin start systemstatebackup
- Microsoft Learn: Storage Migration Service overview
This article was originally published on .