I am getting the following error during Pre-Install:
[Pre-Install] :: Cannot process argument transformation on parameter ‘SID’.
Cannot convert value “S-1-5-21-2292945232-817140371-388603619-1131.bak” to type “System.Security.Principal.SecurityIdentifier”.
Error: “Value was invalid. Parameter name: sddlForm”
Occurred in: Get-ADTUserProfiles
Script location: PSAppDeployToolkit.psm1, line 9881
Stack trace:
Get-ADTUserProfiles → Get-ADTPresentationSettingsEnabledUsers → Test-ADTUserIsBusy → Show-ADTBalloonTip → Show-ADTInstallationProgress → Install-ADTDeployment
Toolkit version: 4.0.6
The issue was the key “S-1-5-21-2292945232-817140371-388603619-1131.bak” at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Is there a way to get PSADT to ignore .bak user profiles in the registry so it doesn’t choke on them?
We’ve added handling for this in 4.1.0, but the correct answer is to stop renaming things like that in the registry as it’s not good/proper practice.
Meanwhile, I have Intune consultants creating BS win32apps packages that registry keys with backslashes in the name of individual keys!
Windows does that automatically though.
Sorry, what do you mean by not this?
Bomgar in their infinite wisdom likes to use square brackets in the DisplayName uninstall entry which really screws with certain wildcard queries
Not sure if this is helpful, but i felt like commiserating.
Sorry, what do you mean by not this?
Try to create a reg key with backslashes \ in them with regedit.exe. I’ll wait.
Oh, I thought you were talking about .bak.
Windows creates .bak keys in the registry so it would be great if PSADT could ignore them.
I’ve personally never seen Windows do that, but I know admins have manually been known to in the past. If Windows does in fact, rename profiles like this with .bak, then I apologise for being incorrect on that!
As mentioned here though, the issue shouldn’t be a problem in 4.1.0 as we’ve got code to work around it.
I think they are using reg.exe to copy reg keys as “backup” in a half-backed CMD batch file and don’t care to remove the backup afterwards. I just don’t have the time to police that right now.
No this is Windows behavior for corrupted profiles. When a user gets a temporary account that .bak key is created by Windows. I have some scripts that look for this when users get temp accounts.
References:
Google AI in search for “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList .bak”
The registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList is a crucial location within the Windows registry that stores information about user profiles. The .bak extension on a subkey within this path indicates a corrupted or backup profile, often related to issues where Windows logs into a temporary account instead of the user's actual profile. Fixing this often involves manipulating these registry keys to point to the correct profile.
Explanation:
HKEY_LOCAL_MACHINE (HKLM):
This is a root key in the Windows registry that stores configuration data for the entire computer, including hardware and software settings, according to Lenovo.
SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList:
This specific path within the registry holds information about each user profile on the system. Each user profile is represented by a unique Security Identifier (SID) as a subkey within this path.
.bak extension:
When a user profile becomes corrupted or inaccessible, Windows might create a backup copy of the profile's registry key, appending .bak to the original SID.
https://support.firstmutualholding.com/support/solutions/articles/47001250683-temporary-user-account-error-bak-profile-removal
3 Likes
Learn something new every day. I’ve always assumed it was admin’s doing this stuff.
1 Like
