How to Manage User Profiles With PowerShell

Enumerating user profiles

“Managing user profiles with PowerShell is like wielding a Swiss Army knife for IT tasks — it saves time and keeps things efficient,” said Lukasz Kubiak, gaming consultant at The End of the Sun. “The ability to automate repetitive actions, such as identifying and removing outdated profiles, is a game-changer. For example, I once ran a script to clean up a slew of corrupted profiles across our network, and what would’ve taken hours manually was done in minutes.”

It’s easy to take a peek at user profiles on the file system on a single Windows computer. Look in the C:Users folder. However, when you do this, you are not getting the full picture, and it’s also troublesome due to potential file system access problems. There’s a better way — Windows Management Instrumentation (WMI). 

“For large enterprise-scale implementations, PowerShell, CIM and WMI offer significant advantages over traditional methods,” Jason Wingate, CEO of product development specialists Emerald Ocean, told business.com. “PowerShell’s automation capabilities can eliminate hours of error-prone manual work, while CIM and WMI provide deeper access to Windows components. This combination is particularly powerful when managing profiles across multiple systems — you get both efficiency and precise control.”

In WMI, a class exists called Win32_UserProfile. This class holds user profile information on Windows systems. It contains all the profiles that exist on a machine and lots of other useful information a simple file system folder won’t show you. Together with PowerShell modules, you can enumerate, create or delete user profiles. 

“Start with Get-CimInstance or Get-WmiObject for profile enumeration,” suggested Wingate. “For removal, use Remove-CimInstance but always test with -WhatIf first. The last thing you want is to have critical profile losses from a rushed implementation.”

Using PowerShell you can access this WMI class with the Get-CimInstance or Get-WmiObject cmdlets. In Figure 1 below, you find the first user profile on the local computer. You’ll notice many useful tidbits of information, such as LastUseTime and SID. From here, you can also drill down further and get specific paths like Desktop, Documents and Favorites.

Figure 1

Since this is part of WMI, you can easily extend this from a single computer to many computers using the ComputerName parameter. To be compatible with down-level operating systems, you can use the Get-WmiObject cmdlet here to enumerate user profiles on the MEMBERSRV1 and CLIENT2 computers.

Get-WmiObject -Class Win32_UserProfile -ComputerName ‘MEMBERSRV1’,’CLIENT2’

“The real beauty of PowerShell is how easily it scales,” said Kubiak. “Using commands like Invoke-Command lets you manage user profiles across multiple systems simultaneously, making life much easier for anyone managing a larger network.”

Removing user profiles

Another common task when managing user profiles is removal. This is sometimes necessary because files can become corrupted. After removal, you need the user to log in again and recreate their profile. Sometimes, you might have the user log off and remove the C:Users<UserName> folder from the file system. Usually, this works, but sometimes it doesn’t. The problem with this technique is that it leaves some remnants behind. The proper way to do this — and the easier way — is to initiate a removal via WMI.

Using the same WMI class, it’s possible to view profiles and completely remove them. This is the same as going into the User Profiles box under System settings and hitting the Delete button.

To do this, enumerate the user profiles again and this time apply a filter to pick a single user profile to remove. In this case, remove the user profile called Administrator.CLIENT1. You can use PowerShell’s Where-Object cmdlet and some string manipulation to grab the user folder name from the LocalPath property — that section is shown below in bold.

Get-WmiObject -Class Win32_UserProfile | where {$_.LocalPath.split(”)[-1] -eq ‘Administrator.CLIENT1’} | foreach {$_.Delete()}

Once you’re able to narrow down to a single profile, you can then call the Delete() method for each object that Get-WmiObject outputs — in this case only 1 — which will then remove the user profile from the file system as well as the registry.

Get-WmiObject -Class Win32_UserProfile | where {$_.LocalPath.split(”)[-1] -eq ‘Administrator.CLIENT1’} | foreach {$_.Delete()}

Again, if you’d like to extend this to multiple computers, you’d use the –ComputerName parameter on Get-WmiObject.

Get-WmiObject -Class Win32_UserProfile –ComputerName CLIENT1,CLIENT2 | where {$_.LocalPath.split(”)[-1] -eq ‘Administrator.CLIENT1’} | foreach {$_.Delete()}

“The main challenges IT professionals will face are permissions, profile corruption and system compatibility issues,” said Wingate. “The key, however, is thorough testing before deployment and running scripts with minimal required privileges. Strong error handling in your scripts is also crucial. Implement comprehensive logging, too, as it makes troubleshooting significantly more efficient.”

Use WMI, not the file system

You’ve now seen an easy way to enumerate and remove Windows user profiles. If you weren’t aware of the WMI class Win32_UserProfile you may have been correlating the C:Users<Username> folder as the profile. Now, you can see there’s much more to the user profile than a simple file system folder. Use WMI the next time you need to query or remove user profiles from computers in your environment.

While WMI remains a powerful tool for managing user profiles, IT professionals are increasingly adopting new techniques to further streamline user profile management.

Wingate said, “cloud-based management through platforms like Microsoft Intune is becoming increasingly important. While AI and other machine learning solutions are showing promise, the real value lies in improved automation tools and better cross-platform integration. These practical improvements are making significant differences in enterprise environments.”

Mark Fairlie contributed this article.