Forum Discussion
Azure AD Endpoint Manager User Profile Corruption: Black Screen Flashing Taskbar Explorer Crash Loop
- Jul 24, 2023
Daniel,
We just discovered the same thing and rolled out a fix for it in our environment. For users with an email address in on-prem AD, Azure AD Connect Sync was creating the accounts in Azure online with the pre-Windows 2000 NetBIOS domain name which matches the pre-Windows 2000 NetBIOS user logon name. However, for those without an email, it was creating the account in Azure with the subdomain of the domain FQDN instead of the pre-Windows 2000 name as specified on the account or in Domains and Trusts. Azure AD Cloud Sync was trying to update all accounts to the subdomain and completely ignoring the pre-Windows 2000 names entirely.
As far as experiencing the taskbar issue, once it occurred for one account on the machine, it would then impact all accounts on the machine both pre-existing and new sign-ins. However, accounts that did not have an AD mail attribute would not experience the issue. We found the same SubPkgs key and those that were in the NetBIOS subkeys would have the taskbar, permission, and general SID mismatch errors but those that were in the subdomain subkey would not.
We shut down our Azure AD Connect and are now relying entirely on Cloud Sync. Then, to fix the machines without a reimage, we performed a full Cloud Sync and then ran the following PowerShell script on Azure AD joined machines to clean up the broken accounts. This allowed users to sign in fresh with the subdomain instead of NetBIOS prefix and the issue has not reoccurred, but it's only been about a week.
$CurrentUserSID = (C:\Windows\System32\whoami.exe /User /Fo CSV | ConvertFrom-Csv).SID $CachedAccounts = Get-CimInstance -Classname win32_userprofile | where-object { (!$_.Special) -And ($_.SID -like 'S-1-12-1-*') -And ($_.SID -NotLike $CurrentUserSID) } foreach ($Account in $CachedAccounts) { $SIDtoUser = $null $SID = New-Object System.Security.Principal.SecurityIdentifier($Account.SID) try { $SIDtoUser = $SID.Translate([System.Security.Principal.NTAccount]) Write-Host "Removing $SIDtoUser from list of cached accounts." if ($SIDtoUser -ne $null) { $CachedAccounts = @($CachedAccounts | Where-Object SID -ne $SID) } } catch { Write-Host "Unable to translate SID ($SID) to user." } } if ($CachedAccounts.Count -gt 0) { Write-Host 'Accounts to be removed:' $CachedAccounts | Select LocalPath,SID | ft $Confirmation = Read-Host "Do you want to remove those accounts? (Yes or No)" if ($Confirmation.ToLower() -like "y*") { Write-Host "Removing accounts..." $CachedAccounts | Remove-CimInstance -Verbose } else { Write-Host 'Accounts not removed.' } } else { Write-Host 'No accounts to remove.' }
Hopefully, this script and info helps someone else.
Rexford
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IdentityStore\LogonCache\B16898C6-A148-4967-9171-64D755DA8520\SubPkgs
The keys should represent the NetBIOS name of the on-prem domain, in our situation we had ABC and ABC-GLOBAL, ABC represented the actual NetBIOS name while ABC-GLOBAL was the first part of the FQDN (looking at the domain properties in powershell it was it's "Name"). Both of these keys had a value for "AuthenticatingAuthorityDns" which matched our domain FQDN so the assumption here is some kind of conflict. The solution was to simply delete the key which wasn't out domain NetBIOS name (required taking ownership etc). After a reboot the users could login again.
The value for netBIOSName in AzureAD is populated using %Domain.Netbios% for AD Connect and
%DomainNetBios% in Cloud Sync. I've not been able to find anymore information about how these values are obtained. I can only assume that Cloud Sync isn't using exactly the same value as AD Connect. Maybe this only impacts where the "Name" and "NetbiosName" (from a get-addomain) are different.
Anyway that was my experience, I hope this helps people in the future or gives people pointers to allow cloud sync migrations without this issue,
Daniel,
We just discovered the same thing and rolled out a fix for it in our environment. For users with an email address in on-prem AD, Azure AD Connect Sync was creating the accounts in Azure online with the pre-Windows 2000 NetBIOS domain name which matches the pre-Windows 2000 NetBIOS user logon name. However, for those without an email, it was creating the account in Azure with the subdomain of the domain FQDN instead of the pre-Windows 2000 name as specified on the account or in Domains and Trusts. Azure AD Cloud Sync was trying to update all accounts to the subdomain and completely ignoring the pre-Windows 2000 names entirely.
As far as experiencing the taskbar issue, once it occurred for one account on the machine, it would then impact all accounts on the machine both pre-existing and new sign-ins. However, accounts that did not have an AD mail attribute would not experience the issue. We found the same SubPkgs key and those that were in the NetBIOS subkeys would have the taskbar, permission, and general SID mismatch errors but those that were in the subdomain subkey would not.
We shut down our Azure AD Connect and are now relying entirely on Cloud Sync. Then, to fix the machines without a reimage, we performed a full Cloud Sync and then ran the following PowerShell script on Azure AD joined machines to clean up the broken accounts. This allowed users to sign in fresh with the subdomain instead of NetBIOS prefix and the issue has not reoccurred, but it's only been about a week.
$CurrentUserSID = (C:\Windows\System32\whoami.exe /User /Fo CSV | ConvertFrom-Csv).SID
$CachedAccounts = Get-CimInstance -Classname win32_userprofile | where-object { (!$_.Special) -And ($_.SID -like 'S-1-12-1-*') -And ($_.SID -NotLike $CurrentUserSID) }
foreach ($Account in $CachedAccounts) {
$SIDtoUser = $null
$SID = New-Object System.Security.Principal.SecurityIdentifier($Account.SID)
try {
$SIDtoUser = $SID.Translate([System.Security.Principal.NTAccount])
Write-Host "Removing $SIDtoUser from list of cached accounts."
if ($SIDtoUser -ne $null) {
$CachedAccounts = @($CachedAccounts | Where-Object SID -ne $SID)
}
} catch {
Write-Host "Unable to translate SID ($SID) to user."
}
}
if ($CachedAccounts.Count -gt 0) {
Write-Host 'Accounts to be removed:'
$CachedAccounts | Select LocalPath,SID | ft
$Confirmation = Read-Host "Do you want to remove those accounts? (Yes or No)"
if ($Confirmation.ToLower() -like "y*") {
Write-Host "Removing accounts..."
$CachedAccounts | Remove-CimInstance -Verbose
} else {
Write-Host 'Accounts not removed.'
}
} else {
Write-Host 'No accounts to remove.'
}
Hopefully, this script and info helps someone else.
Rexford
- slider484Sep 18, 2024Copper Contributor
We have just dealt with this issue and confirmed this is a the fix. The Entra ID Cloud sync attribute mapping for the netbios name is set by default to %netbiosdomain%. Update this attribute mapping to netbiosname and re-sync Entra ID cloud sync. The run the script with all domain accounts logged out as a local admin. Reboot the machine and users can log back in again and don't have the issue. Note - It does look like this does re-profile the users. We are rolling this out currently but will see if this fixes the issue long term
- Daniel_GatleySep 18, 2024Copper Contributor
slider484 I would suggest reaching out to Microsoft support on this, I had a running ticket with them and they advised there is a fix which is behind a feature flag which they enabled in my environment and it works without issue now (since mid April). The wording from Microsoft seems to suggest it should be turned on "in production" but if there are still reports of issue then it would seem not.
Microsoft advised "This feature is released to production, but it is behind a feature flag that is disabled in production. I am going to enable this in production over the next 2 weeks. Please confirm that the customer is okay to enable this feature in production. Once the feature is enabled, cloud sync will fix the domainNetBiosName for all users for the customer's tenant."
Not sure if it helps but the ticket tracking ID was TrackingID#2404090050003764.
- MskeeteSep 18, 2024Copper ContributorOur team might've just resolved this thanks to your script.
In any case, thanks for being a legend and posting that script. - Edmundo PenaJul 28, 2023Brass ContributorThank you to the Microsoft Community for finally shedding light on this issue. Great work team!