on some computers in our network we get a blank popup window where we normally insert our login credentials to have access to AVD.

Thanks, i've been already reading and trying out some of the links you've noted.

I will first give you more info.

The issue occurs on like only 5 devices on a total of 250 devices spread over different locations. We have hardware firewalls and do not use the windows firewall.
All devices use MS Windows 10 and office 365. Each user logs in on multiple devices on the domain in the organization and on each device they start using AVD with remote desktop tool Azure Virtual Desktop.

There are 2 computers in a different building which do not function and they have the issue from the blank screen. When they use the web interface through the url they can work on that device perfectly. I've tried to let them login on my laptop in the same domain and then they can use the AVD desktop client normally.

It seems indeed that there is an issue that just occurs on those 5 devices...

What i've tried so far also with no luck are these solutions that I found online after i discovered in the local event viewer several errors the exact moment the white sign-in screen appears:

1. DistributedCOM
   Can't start DCOM Server Microsoft.AAD.BrokerPlugin... Windows.Security.Authentication.Web.Core.BackgroundGetToken.Task.ClassId.WebAccountProvider as non available;
   Error "2147942402" is found when running "C:\Windows\System32\BackgroundTaskHost.exe" -ServerNameBackgroundTaskHost.WebAccountProvider
2. DistributedCOM
   Can't start DCOM Server Microsoft.AAD.BrokerPlugin... as non available;
   Error "2147942402" is found when running "C:\Windows\SystemApps\Microsoft.AAD.BrokerPlugin-cw5n1h2txyewy\Microsoft.AAD.BrokerPlugin.exe" -ServerName:App.AppXqvz.....mca

https://thegeekpage.com/unable-to-start-a-dcom-server/ Fix 1 en 3 NOK

https://learn.microsoft.com/en-us/answers/questions/842652/unable-to-start-a-dcom-server-microsoftwindowsclie.html Fix NOK

https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flearn.microsoft.com%2Fnl-nl%2Fmicrosoft-365%2Ftroubleshoot%2Fauthentication%2Fautomatic-authentication-fails&data=05%7C01%7C%7C47ed9b8cfcfa410a8b8108dad44f9af6%7C0e088a5e27e2495cac552145f416281f%7C0%7C0%7C638055735616356931%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RhDGhQj5vkV9eM3kxdmgDIy745cyLiZwkjyNHcx%2B5ao%3D&reserved=0

Fix powershell: nok

Fix Microsoft support and recovery assistant: nok

Hey Toon!
Ik had enkele dagen geleden hetzelfde probleem.

Op het eerste zicht lijkt mij het meest waarschijnlijk bij u een beschadigd register te zijn. Eerste stappen om te proberen zijn SFC uitvoeren en alle apps opnieuw registreren via Powershell. Vervolgens ook de AAD Broker Plugin (staat vermoedelijk voor Azure Active Domain of zo) opnieuw in te stellen. Het is al zeker weten een probleem tijdens het starten van deze UWP en de logboeken hiervan zijn onder event viewer (Win + X -> L) en dan Logboeken Toepassingen en Services > Microsoft > Windows > Apps > Microsoft-Windows-TWinUI/Operational

Het bleek dat de oorzaak in mijn geval een beschadigd UsrClass.dat bestand was.
Ik heb namelijk deze informatie in de event viewer gevonden:

Het register kan niet worden geladen. Dit probleem wordt vaak veroorzaakt door onvoldoende geheugen of onvoldoende beveiligingsrechten. > DETAIL - The configuration registry database is corrupt.> voor C:\Users<Username>\AppData\Local\Microsoft\Windows\UsrClass.dat

Het kan zijn dat bij u het een gelijkaardig geval is, in ieder geval is het overduidelijk een probleem met de activering van de WebAccountProvider app. Om een of andere reden word de Microsoft authenticatie met een UWP app gedaan die dan de login pagna in webview open doet en de tokens voor de sessie terug stuurt. Het probleem met UWP apps is dat deze extreem gevoelig zijn. We hebben dan ook een heleboel dingen die elke UWP app nodig heeft om geactiveerd te kunnen worden. Hier is zowat alles wat in orde moet zijn voor een geldige COM activatie:

• Geldig register in C:\Windows\System32\config. Op installaties ouder dan Windows 10 1803 (1709 en vorige) kan je RegBack gebruiken om een update van enkele dagen of weken geleden terug te zetten. Op nieuwere systemen bestaat RegBack nog maar moet je dit handmatig terug inschakelen in het register, ik raad dit aan omdat het 90% van de problemen met Windows opstarten kan oplossen, het gebeurt namelijk zeer zelden dat een kritiek bestand voor opstarten beschadigd raakt, maar het register is zeer gevoelig, zeker wanneer de schijf bijna vol is. Één ongelukkige schrijffout naar het register en je installatie start niet meer.
• Een geldig register in %localappdata%\Microsoft\Windows\UsrClass.dat. Ik was zelf vergeten hier een backup van te maken en dan zelfs vergeten dat dit register bestaat. Het is dan ook niet belangrijk op het eerste zicht, het bevat enkel de geregistreerde bestandsnaam extensie toepassingen en de aangepaste protocollen (gebruikelijk voor UWPs zodat Microsoft shorcuts naar hun apps kan maken vanuit hun website, om bijvoorbeeld op apps.microsoft.com een app te openen recht naar de Store app, of calculator://. Zelfs candycrushsodasaga:// bestaat.) Blijkbaar bevat dit bestand dan ook kritieke regstratie van UWP apps met daarbij de app resources als naam, icoon en app model id, wat uiterst noodzakelijk is voor de activatie van een app. Zo zien we veel sleutels met "AppX..." en daaronder dus de info voor elke app, waarschijnlijk gebruikt voor de start menu. Hierin zit dus het model id dat nodig is om de app te identificeren bij het activeren. Zo kunnen we dus het model id gebruiken vanuit de command line of zelfs uit Windows Verkenner navigatiebalk: explorer shell:appsfolder\Microsoft.WindowsStore_8wekyb3d8bbwe!App
• Een geldig register in %userprofile%\NTUSER.DAT.
• Een intacte app repository SQL database C:\ProgramData\Microsoft\Windows\AppRepository. Hier worden dus de apps echt geregistreerd met al hun eigenschappen die zich in het manifest bevinden.
• Juiste permissies (op zen minst alle toepassingspakketten of all application packages afhangend van de taal van je installatie) in de volgende locaties:
  • C:\Program Files\WindowsApps
  • %localappdata%\Packages

Nu kunnen we uitzoeken hoe we specifieke problemen met ieder onderdeel kunnen oplossen.

Hoe ik het heb opgelost:

• Hernoem het bestand %localappdata%\Microsoft\Windows\UsrClass.dat. Dit kan gedaan worden vanuit een ander account (ingebouwde Administrator bijvoorbeeld) of een ander besturingssysteem dat NTFS of jouw specifiek bestandsysteem ondersteunt. Dat kan een live installatie, installatiemedia of een installatie op een andere partitie.
  De reden waarom dit werkt is omdat dit bestand een register is waarin de gebruiker zijn klassen opgeslagen worden. Dit zijn dus de definities van wat welk programma moet open doen. Daaronder zijn de protocollen en welk programma met welk protocol geopend moet worden. De bestands extensies die herkend worden en welke programma's geopend moeten worden door welk bestandstype (ik heb bijvoorbeeld hier gevonden dat ".c5e2524a-ea46-4f67-841f-6a9465d9d515" een geldige bestandsextensie is die de verborgen Windows Phone Verkenner opent). Dit zijn dus de gebruiker specifieke klassen, er zijn ook systeem standaard klassen. Er bevinden zich ook aangepaste context menu items en andere shell extensies. Het kan dus geen kwaad om dit bestand te hernoemen neem ik aan, want deze protocollen en extensies worden geregistreerd bij het installeren van een programma, maakt niet uit of het UWP of Win32 is. Dit merk je aan dat als je het kapotte register hernoemt of verwijderd het bij inloggen gewoon terug verschijnt met alle standaard extensies terug in het bestand. Om de UWP protocollen opnieuw te registeren kan je de volgende methode gebruiken om alle apps opnieuw te registreren en dus alles wat er bij de registratie hoort ook terug in te stellen. Het registeren van de protocollen en de app lokalisatie en resources in de gebruiker klassen wordt gedaan op het moment dat in Powershell het registratieproces op 3% staat. De user klassen kunnen indien succesvol geladen gevonden worden in regedit onder HKEY_USERS\<SID>_Classes.

De andere mogelijke oplossingen:

• Opnieuw registreren van alle UWP apps. Dit lost zowel alle niet permissie problemen met UWP apps op. Natuurlijk wel indien de registratie van de apps volledig lukt in deze stap, indien niet is het een probleem met de toegang of integriteit van een van de vereisten hierboven genoemd. Om de individuele apps opnieuw te registeren voeren we het volgende commando in:
  Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
  En om de applicatie bundels ook nog eens te registeren: get-appxpackage -all -packagetype bundle |% {add-appxpackage -register -disabledevelopmentmode ($_.installlocation + "\appxmetadata\appxbundlemanifest.xml")}
• Uitvoeren van generieke systeem scans en reparaties in de juiste volgorde en vanuit C:\ en met voldoende opslag vrij (1GB zeker aangeraden vooral voor dism):

1. chkdsk /F /X /R - Deze zorgt ervoor dat er al geen fouten zijn op de schijf om te beginnen.
2. icacls * /T /Q /C /reset - Deze zorgt ervoor dat de minimum permissies worden toegekend aan alle mappen, dus administrator en systeem.
3. dism /online /cleanup-image /restorehealth - Dit herstelt de component based servicing opslag (C:\Windows\WinSXS). De componenten zijn noodzakelijk voor de system file checker in de volgende stap.
4. sfc /scannow - Voert de system file checker uit om beschadigde bestanden in windows te vervangen met deze van de component opslag via component based servicing (CBS).
5. Optioneel kan de component store opgeschoond worden (enkel onnodige componenten worden verwijderd): dism /online /cleanup-image /startcomponentcleanup /resetbase. Resetbase is optioneel maar kan extra opslag vrij maken.

• Het terug zetten van het oude register via een backup of system restore point. De permissies worden automatisch juist gezet door object inheritance in de map config.
• Hernoemen of verwijderen van de map %localappdata%\Packages\Microsoft.AAD.BrokerPlugin... zodat deze opnieuw gemaakt kan worden.

De vermoedelijke oorzaak voor dit probleem is een volle harde schijf tijdens het afmelden van de computer waardoor er een grote kans ontstaat dat een van de registers niet correct afgesloten raakt en zodanig beschadigd of incompleet is dat hij "onleesbaar" is verklaard door Windows. Meestal zijn alle gegevens in het register intact maar er kan een onvolledige sleutel of een foute header zijn die een fout veroorzaakt tijdens het inladen van het register. De tweede mogelijke oorzaak is een fout in Windows die de permissies aantast van de UWP app. Het is dus ook mogelijk dat de computer geforceerd is afgesloten voordat dit probleem verscheen. Het is namelijk nooit gezond om een computer geforceerd uit te schakelen of de stekker plots uit te trekken, als deze aan het schrijven was naar een van de registers tijdens dat deze uitgezet word kan het een half geschreven sleutel of header veroorzaken wat fouten geeft bij het daarna laden van de registers.

Als niks van deze informatie helpt laat het mij weten, dan zoek ik voor nog mogelijke oorzaken voor dit specifiek probleem. Google is meestal kompleet nutteloos bij van die specifieke dingen die niet veel mensen aan de hand hebben.

Bedankt en fijne dag verder!

• Lasse Lauwerys