Event ID 1511 and 1515: RDS users land in a temporary profile every logon

Fix it now

Windows could not load the user’s real profile and built a throwaway one, so the desktop is empty and everything done in the session is discarded at logoff. The usual cause is a leftover .bak entry under ProfileList, and repairing that key pair brings the real profile back with the data intact.

reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" C:\temp\profilelist.reg
whoami /user

1. Stop the user logging back on while you work, or the temporary profile is rebuilt on top of your changes.
2. Open regedit and go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Find the user’s SID. Two keys for the same SID, one of them ending .bak, is the fault.
3. Delete the key without the suffix, which describes the temporary profile, then rename the .bak key so the suffix is gone.
4. In the restored key, set RefCount and State to 0, and confirm ProfileImagePath points at a folder that still exists on disk.
5. Log the user on and confirm their own desktop, documents and application settings are back.

Be certain which SID belongs to which user before you delete anything. Removing the wrong key orphans a profile and the user loses access to their existing data until it is repointed.

If their real profile returns, you are done. If it happens again to the same person, or to several people at once, the next section covers what is actually failing at load time.

Why it happens

Every profile on a machine has an entry under ProfileList keyed by the account’s SID. That entry records where the profile folder lives, how many sessions currently hold it, and what state it is in. At logon Windows reads the entry, loads NTUSER.DAT from the folder named in ProfileImagePath, and mounts it as the user’s registry hive. If any part of that fails, Windows renames the entry with a .bak suffix, builds a temporary profile so the logon can still complete, and logs the failure. The real profile is left alone on disk, which is why this is almost always recoverable.

On a Session Host the effect is disguised. One person at a time is affected, they get a working but empty desktop, and it is reported as that person’s problem rather than as a profile service fault. The tell is that everything they do vanishes at logoff and comes back to nothing the next morning.

Roaming setups add a second surface. The profile lives on a share, is copied down at logon and back at logoff, and the folder carries a version suffix tied to the Windows build: .V2 for Windows 7 and Server 2008 R2, through .V5 for Windows 10, and .V6 from Windows 10 version 1607 onwards. An unreachable share, permissions that stop the user reading their own folder, a full volume, or a host rebuilt at a different Windows version that now expects a different suffix all produce a temporary profile while the real data sits untouched on the server.

One thing to discount early. The User Profile Service also logs an entry saying the registry file is still in use by other applications or services, and it is tempting to treat that as the smoking gun for a handle leak. Microsoft states plainly that this one can safely be ignored. If you are chasing a repeat offender, chase the pattern, not that entry.

Full reference

The values inside a ProfileList entry

Where to read what happened

Microsoft does not publish meanings for the individual profile event numbers, so read the text of the entries rather than looking the numbers up. The one number Microsoft does address is the ‘registry file is still in use’ entry, and it says to ignore it.

Roaming profile folder suffixes

A host moved to a newer Windows version looks for a suffix that does not exist yet, finds nothing, and creates a new profile. That is not a fault to repair, it is a migration to plan. Mixed-version collections make it a permanent condition, which is the real argument for keeping every host in a collection on one build.

Before you delete a profile

• Copy the folder somewhere safe first. A rebuild loses application settings, mail signatures, stored credentials and anything saved outside redirected folders.
• Delete through the profile list in System Properties, or with the policy that removes profiles older than a set age, rather than by deleting the folder. Deleting the folder leaves the ProfileList entry behind and the next logon fails differently.
• Confirm what is actually redirected before you assume a rebuild is cheap. If Documents and Desktop are redirected, a rebuild costs the user their settings but not their files; if nothing is, it costs them everything.

Reducing how often this happens

Two changes make temporary profiles rare rather than routine. The first is folder redirection, which moves the large, user-owned folders out of the roaming profile entirely; redirected data is not part of the roaming profile and is synchronised in the background with Offline Files after logon, so a slow or briefly unavailable share stops being a logon-blocking event. The second is keeping the profile itself small, so the copy at logon and logoff is short enough that a transient share problem does not interrupt it.

Neither removes the ProfileList mechanism, and neither is a substitute for fixing a share whose permissions are wrong. They shrink the window in which a failure can happen, which on a busy Session Host is most of the benefit.

Every code this article covers

Confirm the fix worked

1. The affected user logs on and finds their own desktop, documents and application settings.
2. ProfileList holds a single entry for that SID, with no .bak counterpart.
3. RefCount and State in that entry are 0 after a clean logoff.
4. The user logs off and on again and the profile loads a second time without intervention.
5. No new profile-load failures appear for that account over the following week.

Questions people ask about this