Forum Discussion
Benjamin_Donato
Jun 15, 2023Copper Contributor
Need a PS Script to Search Registry and Delete Keys
Situation
The organization configured laptops with an MDM that we no longer have access to. We are now enrolling all Windows computers into the Intune MDM. The laptops that are still enrolled in the previous MDM will not enroll in Intune. I have figured out how to remove the enrollment by deleting specific keys in the registry, but these key are not named the same so I can't just simply target and delete them.
The key name used is consistent on the computer A but will be different on computer B.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\FE600696-F255-4BB9-AE5E-63CC2A35047D
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\FE600696-F255-4BB9-AE5E-63CC2A35047D HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\omadm\Accounts\FE600696-F255-4BB9-AE5E-63CC2A35047D
Script Needed
There appears to be only one key under the following paths:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\omadm\Accounts\
Need a script that can read the name of the key under one of these two paths and then search for and delete the same key and any child keys under the path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Enrollments\
Benjamin_Donato
I feel like there's not enough information on what sits below the GUID to write a safe script, but the sample below "should" be okay so long as you run it on the client before it is enrolled into InTune.Once the client has been enrolled in InTune, I would expect this script to no longer be safe to run as it is scoped to all accounts registered below
HKLM:\SOFTWARE\Microsoft\Provisioning\omadm\Accounts.I feel like if we knew what the structures below
HKLM:\SOFTWARE\Microsoft\Provisioning\omadm\Accounts looked like, we might be able to better-scope a script to the outgoing MDM.Anyhow, with those disclaimers aside, here's a basic skeleton that will do what you asked with a little bit of checking and reporting thrown in.
$AccountsPath = "HKLM:\SOFTWARE\Microsoft\Provisioning\omadm\Accounts"; $SearchPaths = @("HKLM:\SOFTWARE\Microsoft\Enrollments", "HKLM:\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked"); (Get-ChildItem -Path $AccountsPath).PSChildName | ForEach-Object { $Account = $_; $OkayToRemoveAccount = $true; $SearchPaths | ForEach-Object { $RegPath = "$_\$Account"; if (Test-Path -Path $RegPath) { try { # Try removing the path and throw an exception if we cannot for some reason. Remove-Item -Path $RegPath -Recurse -ErrorAction:Stop -Force; } catch { # If an error was thrown, indicate that we are not yet in a position to delete the account entry and report the error as a warning. $OkayToRemoveAccount = $false; Write-Warning -Message "$($_.CategoryInfo.Category) on $RegPath."; } } else { # Report that we couldn't find this particular path, which might occur if a previous run was partially-successful and we're running the script a second (or more) time. # This is not really an issue though, so there's no actions worth taking beyond notifying the operator. Write-Warning "Skipping due to path not found: $RegPath."; } } if ($OkayToRemoveAccount) { Remove-Item -Path "$AccountsPath\$Account" -Recurse -ErrorAction:Continue -Force; } else { Write-Warning "Unwilling to remove $AccountsPath\$Account due to an earlier error."; } }
And here's some example output for each basic scenario.NOTE: I don't use an MDM so I created a basic subkey named "1" instead. In your case, this "1" corresponds to your GUID-based "FE600696-F255-4BB9-AE5E-63CC2A35047D" subkey from your post.
Access denied scenario
The key takeaway here is that the account is not removed, which allows you to safely run the script again after fixing the access denied issue.
Skipping a path that's already been deletedIgnore the access denied, as they key takeaway in this example is the reporting of the path being skipped, indicating it's already been deleted (which is fine based on what you're trying to achieve.)
A successful result with one path having been skipped
In a successful removal where no paths have been skipped, there will be no output.
Again, do not run this on a client if it has already been enrolled into InTune.
Cheers,
Lain
- LainRobertsonSilver Contributor
Benjamin_Donato
I feel like there's not enough information on what sits below the GUID to write a safe script, but the sample below "should" be okay so long as you run it on the client before it is enrolled into InTune.Once the client has been enrolled in InTune, I would expect this script to no longer be safe to run as it is scoped to all accounts registered below
HKLM:\SOFTWARE\Microsoft\Provisioning\omadm\Accounts.I feel like if we knew what the structures below
HKLM:\SOFTWARE\Microsoft\Provisioning\omadm\Accounts looked like, we might be able to better-scope a script to the outgoing MDM.Anyhow, with those disclaimers aside, here's a basic skeleton that will do what you asked with a little bit of checking and reporting thrown in.
$AccountsPath = "HKLM:\SOFTWARE\Microsoft\Provisioning\omadm\Accounts"; $SearchPaths = @("HKLM:\SOFTWARE\Microsoft\Enrollments", "HKLM:\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked"); (Get-ChildItem -Path $AccountsPath).PSChildName | ForEach-Object { $Account = $_; $OkayToRemoveAccount = $true; $SearchPaths | ForEach-Object { $RegPath = "$_\$Account"; if (Test-Path -Path $RegPath) { try { # Try removing the path and throw an exception if we cannot for some reason. Remove-Item -Path $RegPath -Recurse -ErrorAction:Stop -Force; } catch { # If an error was thrown, indicate that we are not yet in a position to delete the account entry and report the error as a warning. $OkayToRemoveAccount = $false; Write-Warning -Message "$($_.CategoryInfo.Category) on $RegPath."; } } else { # Report that we couldn't find this particular path, which might occur if a previous run was partially-successful and we're running the script a second (or more) time. # This is not really an issue though, so there's no actions worth taking beyond notifying the operator. Write-Warning "Skipping due to path not found: $RegPath."; } } if ($OkayToRemoveAccount) { Remove-Item -Path "$AccountsPath\$Account" -Recurse -ErrorAction:Continue -Force; } else { Write-Warning "Unwilling to remove $AccountsPath\$Account due to an earlier error."; } }
And here's some example output for each basic scenario.NOTE: I don't use an MDM so I created a basic subkey named "1" instead. In your case, this "1" corresponds to your GUID-based "FE600696-F255-4BB9-AE5E-63CC2A35047D" subkey from your post.
Access denied scenario
The key takeaway here is that the account is not removed, which allows you to safely run the script again after fixing the access denied issue.
Skipping a path that's already been deletedIgnore the access denied, as they key takeaway in this example is the reporting of the path being skipped, indicating it's already been deleted (which is fine based on what you're trying to achieve.)
A successful result with one path having been skipped
In a successful removal where no paths have been skipped, there will be no output.
Again, do not run this on a client if it has already been enrolled into InTune.
Cheers,
Lain
- Benjamin_DonatoCopper ContributorThank you, I will try this script and reply back with the results.
- Andres-BohrenSteel Contributor
Start with this
$Childs = Get-ChildItem HKLM:\SOFTWARE\Microsoft\Enrollments\
$Childs[0] | flRegards
Andres
- Benjamin_DonatoCopper ContributorThank you, I will try starting with this and let you know what I get.