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
- sjohn777Aug 15, 2022Copper Contributor
Edmundo Pena MS is still reviewing out logs. We however did review WHEN our endpoints were AzureAD joined and such occurred months ago. So we're not certain that's our root cause. We still have yet to find a clear root cause and it (for now) seems to only be for a subset of our endpoints, but it's affected about 16.
- Edmundo PenaAug 16, 2022Brass Contributor
This particular issue has now effected 25% of the 350+ users we have in production and reoccurred across 15 users after adding 20 endpoints over the weekend to the Azure AD tenant.
I am fighting to have this escalated this Microsoft Bug escalated to a more capable team from what is currently provided through professional partner support (while being chastised for it).
Steps we’ve taken while waiting to hear from Microsoft Support:
1. Disabled Directory Sync (Hopefully clears on-premise attributes from current AD users)
2. We’ve currently renamed all effected user accounts to email address removed for privacy reasons
3. Recreated Azure AD Users with original UPNs
4. Migrating Exchange, OneDrive & Teams Data from old users to newly recreated users- Colin KnessAug 18, 2022Copper Contributor
- Edmundo PenaAug 15, 2022Brass ContributorThey won't find anything. Proc Mon won't load on the effected profiles so they don't have the logs they needs to effectively troubleshoot the problem. They are looking at this from the wrong perspective. The issue is specific to Hybrid Accounts on Azure Joined Endpoints. I think is has to do with a mismatch of the Azure vs on-premise SAM account name that the User Profile Service tries to create on the local workstation but no one at Microsoft is paying attention. 10% of one of our customers is down this morning because of it.