Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Aliaska Varieva
A Windows profile is a folder plus a ProfileList registry key, and deleting only one of them is how the temporary-profile ticket starts. The four supported ways to delete a user profile on Windows 11, what to back up first, the grayed-out and access-denied errors, and the script that cleans a fleet.
A user profile on Windows is two things, and deleting only one of them is how a help desk ends up with a "temporary profile" ticket the next morning. The folder under C:\Users is the half everyone sees. This guide covers the half under the registry, and the right way to delete a user profile on Windows 11 so the machine stays clean.
An account is the identity: a local user, a domain user, or an Entra ID user. A profile is what Windows builds on a machine the first time that identity signs in: the folder at C:\Users<name>, the registry hive inside it (NTUSER.DAT), and a key under ProfileList that ties the folder to the account's SID. One account can have a profile on fifty machines. Deleting the account in Settings or in Active Directory does not touch any of them.
So "delete the user" is usually two tickets. Removing the sign-in is covered in removing a Microsoft account and in the handover steps in changing the administrator. This post is the other ticket: the profile on the device, whether the account still exists or not.
Every profile has an entry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, one subkey per SID, with a ProfileImagePath value pointing at the folder. Delete the folder in File Explorer and that key stays behind. At the next sign-in, Windows finds the key, follows the path, finds nothing, renames the key to <SID>.bak, and signs the user in with a temporary profile. Microsoft's cleanup script page states the consequence plainly: if profiles are "incompletely or improperly removed, additional user folders can be created, or users may receive TEMP profiles upon logging in."
A temporary profile looks like a working desktop with nothing on it. Whatever the user saves is deleted at sign-out. The .bak key sits in the registry until someone removes it, and every sign-in after that repeats the loop. Renaming the folder to .old as a safety copy triggers the same path, which is exactly what happened in this r/sysadmin thread: the admin had done it before, this time the user got a temporary profile, and the fix in the top reply was the ProfileList key.
A profile delete is not reversible, and the things people miss are not in Documents. Copy these out first, with the user signed out:
AppData\Local\Google\Chrome\User Data and the Edge equivalent, which hold saved passwords, bookmarks and open-tab sessions that never synced if the user was signed out of the browser.AppData\Local\Microsoft\Outlook: the OST is rebuildable from the mailbox, but a PST archive is not, and signatures live in AppData\Roaming\Microsoft\Signatures.AppData\Roaming: line-of-business apps, VPN clients and RDP connection files often keep their only copy there.If the user is leaving and the data has to be retained, copy the whole folder to the retention share before touching anything, then delete. One reply in the thread above put it well: if you are not sure you can delete the data, you have a retention process problem, not a Windows problem.
The methods below all end in the same place, a folder gone and a ProfileList key gone. They differ in what they can reach and how many machines they cover.
Sign in as a different administrator, open sysdm.cpl, go to the Advanced tab, and click Settings under User Profiles. Pick the profile and click Delete. This is Microsoft's documented method, in its delete a user profile article, and it removes the folder, unloads the hive and clears the registry key in one step. Delete is grayed out for the profile you are signed in with and for any profile that is still loaded, so the user has to be signed out, not just locked.
The dialog above calls the Win32_UserProfile provider, and you can call it directly. From an elevated prompt:
powershellGet-CimInstance -ClassName Win32_UserProfile | Where-Object { $_.LocalPath -like 'C:\Users\jsmith' } | Remove-CimInstance
That removes the folder and the registry entry together, which is why it is the method to script. Add -WhatIf on the last line the first time you run anything that filters by pattern, because a wildcard that matches C:\Users\j* takes every J in the building with it.
When a folder is already gone and the GUI no longer lists the profile, or the only trace is a .bak key, open Regedit at the ProfileList key, find the SID whose ProfileImagePath points at the missing or stale folder, and delete that subkey. Check the path value before you delete anything; two keys can reference the same folder after a failed repair. If a plain SID key and a matching .bak key both exist, the fix for the temporary-profile loop is to delete the plain key (the temp one) and rename the .bak key back to the bare SID, then sign in again. Microsoft's sample script on the page linked above does this inventory for you and reports orphaned keys and orphaned folders before it deletes anything.
Shared desktops, classrooms and kiosks fill up with profiles nobody will sign into again. The policy named "Delete user profiles older than a specified number of days on system restart" (Computer Configuration, Administrative Templates, System, User Profiles) tells the User Profile Service to remove anything unused for N days at the next restart. Per Microsoft's policy reference, one day is counted as 24 hours since the profile was last accessed, and the same setting is available to Intune as the CleanupProfiles ADMX policy. Test it with Group Policy Editor on one machine first, because "last accessed" includes any process that touched the profile, not only a sign-in.
Three errors cover nearly every stuck delete. "Delete" grayed out in System Properties means the profile is loaded: the user is signed in on another session, a scheduled task or service is running as that account, or an app kept a handle on the hive. Sign the user out, check Task Manager's Users tab, and if a process is still holding the hive a restart clears it. "The profile is currently in use" from Remove-CimInstance is the same condition from the other side, and the Loaded property on the object tells you before you try.
"Access denied" on the folder after the registry entry is already gone is a permissions problem, not a profile problem. The folder's ACL grants the deleted account's SID and the administrators group, and if a previous attempt stripped inheritance, take ownership first, then delete. The account the profile belonged to does not need to exist for any of this; the SID in the key is all Windows uses.
On a domain-joined or Entra-joined PC the profile belongs to a SID the machine still trusts, so deleting the profile does nothing to the account and the account can rebuild the profile at the next sign-in. For offboarding, the order is: disable the account in Active Directory or Entra ID, wait for the machine to see it, then delete the profile. Do it the other way round and the departed user's cached credentials still sign in and recreate the folder you removed.
Two domain-specific cases are worth knowing. If the machine's own secure channel to the domain is broken, profile operations fail in confusing ways and the fix is the one in trust relationship failed, not a profile delete. And a machine that has been joined at some point carries a ProfileGUID key next to ProfileList; Microsoft's cleanup script checks it for orphaned entries too, so run the script rather than editing by hand on domain machines.
The r/sysadmin thread below is the fleet version of the question: a technician deleting all but three profiles on about 100 machines through System Properties, one at a time. The top replies are the two answers above, PowerShell for the backlog and the Group Policy for keeping it clean.
The script that does it has four filters, in this order: skip Special profiles (the system accounts), skip anything Loaded, skip the named accounts you keep, and then apply the age cutoff.
powershell$keep = @('C:\Users\itadmin', 'C:\Users\kiosk') $cutoff = (Get-Date).AddDays(-90) Get-CimInstance -ClassName Win32_UserProfile | Where-Object { -not $_.Special -and -not $_.Loaded -and $keep -notcontains $_.LocalPath -and $_.LastUseTime -lt $cutoff } | Remove-CimInstance -WhatIf
Read the -WhatIf output on a handful of machines before you drop the switch. LastUseTime is the weak link: security agents and backup clients open profile hives on a schedule, and several admins in the threads above report it moving on profiles nobody signed into. If the field looks fresh on every profile, fall back to the newest write time of files in the folder, ignoring the .dat files, as the safer age test. If you run OpenFrame, that inventory is one script run across a client's devices with the output collected, so you see every stale profile before deleting any of them.
A profile is a folder plus a registry key, and the delete has to take both. Use System Properties or Remove-CimInstance and it does; delete the folder by hand and Windows hands the user a temporary desktop that forgets everything at sign-out. Back up AppData before you start, sign the user out, disable the account first on domain and Entra machines, and let a script with -WhatIf do the fleet.
If the ticket started with "the user is leaving", the rest of the handover is in changing the administrator on Windows 11. If the profile has to go because it is corrupt rather than unwanted, the PowerShell vs CMD guide covers the shell you will be doing the rebuild from.
Head of Platform
Hi! I’m Aliaska, and I’ve been working as a software engineer (mostly Java + a bit Kotlin) for over 8 years now. I mostly spend my time building backend services, integrating systems, fixing bugs (the fun part 🙃), and making sure things don’t fall apart behind the scenes.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.