Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

Restoring a Windows user profile: what copying the files does not bring back

Technical article
Backup & Recovery

Originally published:

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

A user's laptop is replaced, or their profile will not load, and someone restores their C:\Users\name folder from last night's backup. The documents are there. Then the complaints start: the browser has forgotten saved sign-ins, an accounting package asks to be activated again, a VPN certificate is missing, and some files cannot be opened.

An incomplete or inconsistent backup is one possible cause, but it is not the only one. A Windows profile is more than a folder, and several parts of it depend on things a folder copy does not establish: the account's security identifier, the user's password and sometimes the original computer (our reading of the sources below). This guide explains those dependencies, what Microsoft's migration tool covers, and how to check a restored profile without changing it.

Why it matters

For a small business, one user's profile can hold the only copy of a working setup: mail profiles, line-of-business application settings, certificates for remote access, and passwords saved over years (our reading). Knowing in advance which parts can be restored by copying files, which need the original account, and which need re-entering lets you plan the recovery honestly and tell the user what to expect.

What a profile is

Microsoft's profile documentation says "The system creates a user profile the first time that a user logs on to a computer." It describes two elements:

  • A registry hive. "The registry hive is the file NTuser.dat. The hive is loaded by the system at user logon, and it is mapped to the HKEY_CURRENT_USER registry key." It "maintains the user's registry-based preferences and configuration."
  • Profile folders. "User-profile files are stored in the Profiles directory, on a folder per-user basis", and applications populate them with per-user data and configuration.

The registry documentation adds that a user's hive "contains specific registry information pertaining to the user's application settings, desktop, environment, network connections, and printers", and that its supporting files are Ntuser.dat and Ntuser.dat.log.

Two consequences follow (our reading). First, because the hive is loaded at sign-in, a backup taken while the user is signed in needs a method that can read open files consistently; if NTUSER.DAT was skipped, the settings it held are not in that backup at all. Second, restoring files into a profile while that user is signed in can leave the restored hive overwritten when they sign out.

The account identity: SIDs

Windows does not track accounts by name. The security identifier documentation explains that "Internally, the operating system refers to accounts and processes that run in the security context of the account by using their SIDs."

It is also explicit that a re-created account is a different account: "Security authorities never issue the same SID twice, and they never reuse SIDs for deleted accounts." Its example is a returning employee given a new account: "The new SID doesn't match the old one, so none of the user's access from their old account is transferred to the new account."

For a profile restore, this means (our reading):

  • File and folder permissions in the restored profile name the old SID. Under a new account with the same name, Windows may refuse access until ownership and permissions are corrected.
  • Windows records which profile folder belongs to which SID. Copying a folder into C:\Users does not by itself make Windows load it for an account.
  • Restoring to the same account removes the different-SID mismatch, but does not by itself establish correct profile registration, complete hive restoration, readable secrets or application compatibility. A re-created account remains a different identity even if its name matches.

Secrets bound to the password and the computer: DPAPI

Many applications, and Windows itself, protect saved secrets with the Data Protection API (DPAPI). Microsoft's documentation for CryptProtectData says: "Typically, only a user with the same logon credential as the user who encrypted the data can decrypt the data. In addition, the encryption and decryption usually must be done on the same computer." The remarks add an exception: "However, a user with a roaming profile can decrypt the data from another computer on the network."

The wording is "typically" and "usually", and the exceptions matter, but the general effect for a restore is clear (our reading): encrypted blobs inside a restored profile may be present yet unreadable if the restore lands on a different computer, or under a different account.

Password resets

The DPAPI backup key documentation covers domain accounts: "Normally, domain users encrypt DPAPI-protected data using keys that are derived from their own passwords. However, if the user forgets their password, or if their password is administratively reset or reset from another device, the previously encrypted data can no longer be decrypted using the new keys derived from the user's new password."

For domain users, Windows has a recovery path: "the data can still be decrypted using the Backup keys stored on the Active Directory domain controllers." That document also stresses how sensitive those keys are, and that "anyone who has the DPAPI Backup keys for a domain will be able to decrypt DPAPI-encrypted data for any domain user". It adds: "It's also critical to protect Active Directory backups with as much vigilance as you protect the domain controllers themselves."

The domain backup key path does not exist for a local account, so resetting a local account's password before restoring can leave its DPAPI-protected secrets unrecoverable (our understanding; confirm for your Windows version). Before anyone resets a password during a recovery, decide whether the user's saved secrets matter.

Stored credentials

Windows Credential Manager stores two kinds of credentials. The Credentials Management documentation says that for domain credentials, "Only code running in-process with the LSA can read and write domain credentials", while generic credentials, used by applications that manage authentication themselves, "can be read and written by user processes." Plan on users re-entering saved network and application passwords after a restore to a different computer or account, and treat any that survive as a bonus (our recommendation).

What Microsoft's migration tool does not carry

The User State Migration Tool (USMT) is Microsoft's supported way to move user state between Windows 10 and Windows 11 computers. It is not a backup product, but its documentation is the clearest Microsoft statement of what can and cannot be moved (our reading).

USMT's MigUser.xml "gathers everything in a user's profile" plus files with listed extensions elsewhere. Its page on what USMT does not migrate includes:

  • Application settings: "Settings for Microsoft Store applications", and "Settings from earlier versions of an application. The versions of each application must match on the source and destination computers" (with an exception for Microsoft Office).
  • Operating system settings: "Local printers, hardware-related settings, drivers, passwords, application binary files, synchronization files, DLL files, or other executable files."
  • Shared folders: "After migration, any folders that were shared on the source computer must be manually re-shared."
  • Start menu layout, which needs separate export and import.
  • Identity changes: "USMT doesn't support migrating user profiles from Active Directory domain joined devices to Microsoft Entra joined devices", nor the reverse, nor between Entra joined devices.

It also warns that tools must run with administrative credentials, or "only the user profile that is logged on is included in the migration."

Encrypted files

If the user has files encrypted with the Encrypting File System (EFS), the USMT documentation states that "by default, the User State Migration Tool (USMT) fails if an encrypted file is found unless the /efs option is specified." Microsoft documents automatic EFS certificate migration and handling of encrypted files under the chosen /efs policy. The policy matters: aborting, skipping, decrypting or preserving encrypted data are different outcomes. Decryptability after recovery requires the applicable private-key or authorised recovery material. A file copy alone does not demonstrate that material is available.

USMT's migration support boundary is not a statement that every other recovery method is incapable of restoring the same component. A supported whole-system recovery, an application-specific recovery and a profile-only file copy preserve different state. Choose and validate the method against the required account, machine and application outcome.

Read-only checks

These commands read information and change nothing. Run them on the original computer before an incident, where possible, and on the restored computer afterwards. Keep the output and any errors.

Command Prompt (cmd.exe), as the user:

whoami /user
cmdkey /list

whoami /user "Displays the current domain and user name and the security identifier (SID)." cmdkey /list "Displays the list of stored user names and credentials"; the documentation notes "Passwords are not displayed after they're stored." Compare the list before and after.

Windows PowerShell 5.1 or PowerShell 7, as administrator:

Get-CimInstance -ClassName Win32_UserProfile |
  Select-Object SID, LocalPath, Loaded, Special

This lists each profile's SID, folder and whether it is loaded. The class documentation (a legacy page) describes LocalPath as "the local path of the user profile" and SID as "the Security Identifier (SID) of the user who owns the user profile." Use Select-Object only; the class also has methods that change profiles, which you should not call.

Encrypted files (Command Prompt):

cipher /u /n

The documentation says this "Finds all encrypted files on the local drive(s). If used with the /n parameter, no updates are made." Without /n, the command can update keys, so include it. It scans local drives and may take some time.

Profile errors (Event Viewer): Microsoft's troubleshooting guide starts with "Warning and Error events that User Profile Service records in the Application log", then the User Profile Service Operational log. It notes that event 1530, "Windows detected your registry file is still in use by other applications or services", can be safely ignored.

These checks are partial. They show identity, stored credential names, profile registration and encrypted files; they do not show which application secrets are readable (our reading).

Safe restore rehearsal

Do this in an authorised, isolated lab, not on a user's real computer (our recommendation).

  1. Build two isolated test machines. Use an isolated test domain for the same-domain-account comparison across machines. For standalone machines, explicitly treat local accounts with the same name as different identities; do not clone or manipulate SIDs to simulate sameness.
  2. Create a test user and sign in. Create sample documents, record their SHA-256 hashes (Get-FileHash -Algorithm SHA256 in PowerShell), save a dummy credential for a test share, and set a few application preferences.
  3. Record the baseline with the read-only checks above.
  4. Back up the profile with your normal method and settings while the user is signed out, and again while signed in, to see whether NTUSER.DAT is captured both ways.
  5. Compare the authorised test cases: the same account on its original test machine; the same test-domain account on the other test machine; and a separately created same-name account. If no test domain is available, omit the second case and record that it was not tested.
  6. Compare file hashes, the stored credential list, application settings and access to files in each case.

Diagnosing what you find

  • Documents present, settings missing: the hive was not in the backup; the restore was done while the user was signed in; or the setting belongs to an application whose settings are tied to that machine or version. If the backup never held the hive, no restore of that backup will bring the settings back; a new backup that captures it is the fix.
  • Access denied on restored files: the files carry the old SID's permissions (new account), or inherited permissions differ on the new machine.
  • Saved passwords gone: restored under a different account or computer; password reset before restore; or the application stores secrets outside the profile.
  • Files that will not open with an encryption error: investigate the applicable EFS key/recovery material, identity and permissions, and file integrity. An open failure alone does not prove that a particular certificate was omitted.

Have a qualified person review the procedure before adapting it to a real user's profile, and take a copy of the current profile before changing it.

Worked example (illustrative)

The following is invented to show the pattern. A bookkeeper's laptop is stolen. The office has a nightly file backup of each user's profile folder. On the new laptop, the IT contractor creates a new local account with the same name and copies the profile folder back.

Documents are fine after permissions are corrected. The accounting software asks to be reactivated, the browser has no saved sign-ins, and the bank's security certificate is missing. The contractor tells the bookkeeper in advance which items will need re-entering, collects the certificate again from the bank, and records two changes: a domain or directory account so the identity outlives the hardware, and a written list of which applications hold secrets that only the user can re-enter.

Risks and limits

  • DPAPI behaviour is described by Microsoft as typical, with exceptions such as roaming profiles. Test your own applications.
  • Local account password resets and their effect on saved secrets are our understanding; confirm before relying on it.
  • Taking ownership or changing permissions on restored folders changes security settings; do it deliberately and record it.
  • DPAPI backup keys and Active Directory backups are highly sensitive. Protect them accordingly.
  • No commands in this guide were run in a lab. Test every step in an isolated environment first.

Sources

All accessed 14 November 2026.

Related future topics

  • Planning a laptop replacement so the user's identity outlives the hardware
  • Protecting Active Directory backups and DPAPI backup keys
  • EFS certificates: backing up and recovering the user's key

This article was originally published on .