WinProfileOps

Author(s)

• LarryWisherMan

Tags

WindowsProfiles ProfileManagement OrphanedProfiles RegistryOperations FilesystemOperations RemoteManagement UserProfiles ProfileCleanup WindowsRegistry SystemAdministration Automation ProfileValidation WindowsManagement ITAdministration UserProfileTools

Functions

Get-OrphanedProfiles Get-UserProfilesFromFolders Get-UserProfilesFromRegistry Invoke-UserProfileAudit Remove-UserProfilesFromRegistry

Dependencies

• • WisherTools.Helpers

Release Notes

## [0.3.0-preview0007] - 2024-10-01

### Fixed

- Removed bug from `Process-RegistryProfiles` regarding populating the `FolderName`
variable.
- Refactored model to create a UserProfile object to better handel different removal
scenarios.
- Fixed bug in `Join-UserProfiles` regarding User Folders with no resolvable SIDS

### Added

#### Functions

- New helper function `Validate-SIDFormat` to verify SID value upon retrieval in
`Get-ProfilePathFromSID`.

- **Admin Detection and Environment Variable**: Added logic to detect whether
the current user is an administrator and set an environment variable
`WinProfileOps_IsAdmin` accordingly.
 
 - If the user is an administrator, `$env:WinProfileOps_IsAdmin` is set to
 `$true`. If not, it's set to `$false`.
 
 - The environment variable is automatically removed when the module is unloaded
 or when PowerShell exits.
 
 - Registered an `OnRemove` script block and a `PowerShell.Exiting` event to
 ensure cleanup of the environment variable on module removal or session exit.

- **Remove-UserProfilesFromRegistry**: Added a new function to remove user profiles
from the Windows registry based on SIDs, Usernames, or UserProfile objects.
 
 - Supports three parameter sets: `UserProfileSet`, `SIDSet`, and `UserNameSet`.
 
 - Can be run in `AuditOnly` mode, where no actual deletion is performed, or
 in deletion mode where profiles are removed.
 
 - Includes a `Force` switch to bypass confirmation prompts and a
 `ComputerName` parameter for targeting remote computers.
 
 - Graceful error handling and logging for cases where the registry key cannot
 be opened or profiles cannot be processed for specific computers.

#### Environment Variables

- **`$env:WinProfileOps_IsAdmin`**: A boolean value that determines if the current
user has administrative privileges. This is set by checking the user's security
role against the built-in Administrator group using Windows security principals.

- **`$env:WinProfileOps_RegistryPath`**: Specifies the registry path used to
manage user profiles. Default value: `"SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList"`.

- **`$env:WinProfileOps_RegistryHive`**: Defines the registry hive to use, which
is set to `LocalMachine` by default.

- **`$env:WinProfileOps_RegBackUpDirectory`**: Specifies the directory where
registry backups are stored. Default value: `"C:\LHStuff\RegBackUp"`.

- **`$env:WinProfileOps_ProfileFolderPath`**: The profile folder path, defaulting
to the system drive's `Users` folder. Example: `"C:\Users"`.

### Changed

- **Get-UserProfilesFromRegistry**: Updated the function to handle scenarios
where the current user does not have administrative privileges.
 
 - The function now checks if the user is an administrator by evaluating the
  `WinProfileOps_IsAdmin` environment variable.
 
 - If the user has administrator privileges, the function retrieves user
  profiles from the registry using `Get-SIDProfileInfo`.
 
 - A warning is logged when the fallback method is used, indicating that special
  system accounts are excluded.

- Updated `UserProfile` object creation in `Test-OrphanedProfile` for
`$AccessError` scenarios.

- The module is now using `WinRegOps` version `0.4.0` for more refined registry
value retrieval.

- Refactored `Get-SIDFromUsername` to use `.NET` classes
(`System.Security.Principal.NTAccount` and `System.Security.Principal.SecurityIdentifier`)
 instead of relying on `Get-CimInstance` for SID resolution.

- `Get-UserAccountFromSID` and `Get-SIDFromUsername` now invoke locally / Remotely
to resolve without null values