How to Manage User Profiles With PowerShell

Enumerating user profiles

Gaming industry consultant Lukasz Kubiak likened managing user profiles with PowerShell to wielding a Swiss Army knife for IT tasks: It saves time and keeps things efficient. 

“The ability to automate repetitive actions, such as identifying and removing outdated profiles, is a game-changer,” Kubiak said. “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 is possible to view user profiles by navigating to the C:\Users folder on a local machine. However, this method is limited; it fails to provide a complete picture of a profile’s status and often triggers file system access errors. A more reliable approach involves using Windows Management Instrumentation (WMI) or the Common Information Model (CIM).

Why use WMI or CIM for profile management?

Jason Wingate, CEO of product development specialists Emerald Ocean, explained that for large enterprise-scale implementations, PowerShell, CIM and WMI offer significant advantages over traditional methods. 

“PowerShell’s automation capabilities can eliminate hours of error-prone manual work, while CIM and WMI provide deeper access to Windows components,” Wingate noted. “This combination is particularly powerful when managing profiles across multiple systems — you get both efficiency and precise control.”

The Win32_UserProfile WMI class contains detailed information about all profiles on a Windows system, including properties a simple folder view cannot provide, such as the profile’s security identifier (SID) and loaded status. Administrators can use PowerShell cmdlets (many of which are delivered through specialized PowerShell modules) to enumerate or remove these profiles programmatically.

Cmdlets to enumerate and manage profiles

Wingate recommends starting with Get-CimInstance or Get-WmiObject for profile enumeration and using Remove-CimInstance for removal, while always testing with -WhatIf first. “The last thing you want is to have critical profile losses from a rushed implementation,” Wingate warned.

Using PowerShell, administrators can retrieve detailed profile data with Get-CimInstance (recommended for modern systems) or Get-WmiObject (legacy). Figure 1 illustrates retrieving the first user profile on a local computer, where properties such as LastUseTime and SID are immediately visible. This approach also exposes path definitions for folders like Desktop and Documents.

Because this method uses WMI/CIM, it scales easily across a network. You can query multiple remote computers simultaneously using the -ComputerName parameter. For compatibility with older operating systems, the script below uses Get-WmiObject to list profiles on the remote systems MEMBERSRV1 and CLIENT2:

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

Removing user profiles

Deleting user profiles is sometimes necessary when files become corrupted or when offboarding employees. A common mistake is manually deleting the C:\Users\<UserName> directory. This “dirty” deletion often leaves orphaned registry entries, which can prevent the user from logging in successfully later. A cleaner and more reliable method is to initiate removal via WMI or CIM.
Using the same WMI class, administrators can view profiles and remove them completely — similar to using the Delete button in the User Profiles section under System settings.

Use WMI to safely remove profiles

To perform the deletion, you first enumerate the profiles and apply a filter to isolate the specific user (steps that administrators often wrap into reusable PowerShell functions) when managing profiles at scale. In the example below, the script targets a profile named Administrator.CLIENT1. By using the Where-Object cmdlet, the script parses the LocalPath property to find the matching folder name.

Get-WmiObject -Class Win32_UserProfile |

  Where-Object { $_.LocalPath.Split(‘\’)[-1] -eq ‘Administrator.CLIENT1’ } |

  ForEach-Object { $_.Delete() }

Once narrowed down to a single profile, you can call the Delete() method for each object returned by Get-WmiObject, which removes the user profile from both the file system and the registry.

Get-WmiObject -Class Win32_UserProfile | where

{$_.LocalPath.Split(‘\’)[-1] -eq ‘Administrator.CLIENT1’} | foreach

{$_.Delete()}

To extend this across multiple computers, use the -ComputerName parameter with Get-WmiObject:

Get-WmiObject -Class Win32_UserProfile -ComputerName CLIENT1,CLIENT2 |

  Where-Object { $_.LocalPath.Split(‘\’)[-1] -eq ‘Administrator.CLIENT1’ } |

  ForEach-Object { $_.Delete() }

Wingate explained that common challenges include permissions issues, profile corruption and system compatibility concerns, and emphasized the importance of testing scripts thoroughly before deployment and using minimal required privileges. “Strong error handling in your scripts is also crucial,” Wingate noted. “Implement comprehensive logging, too, as it makes troubleshooting significantly more efficient.”

Use WMI, not the file system

You’ve now seen a more reliable way to enumerate and remove Windows user profiles. If you previously relied on manually deleting the C:\Users\<Username> folder, it’s clear that a user profile is more complex than just its file directory. Leveraging WMI or CIM helps ensure a cleaner, safer removal process that maintains system stability.

While WMI remains a powerful tool for managing user profiles, many IT teams are also exploring newer management approaches to streamline profile administration across devices and environments.

Wingate noted that 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,” Wingate explained. “These practical improvements are making significant differences in enterprise environments.”

Mark Fairlie contributed this article. Source interviews were conducted for a previous version of this article.