Vandaag hebben we het genoegen een zeer speciale bijdrage te delen van Bart, een gewaardeerde technologie-expert bij onze klant. Als een ‘vriend van Nimble’ heeft Bart nauw samengewerkt met ons team om enkele van de meest uitdagende IT-landschappen te navigeren en te innoveren. Zijn meest recente avontuur? Het upgraden naar Microsoft Windows Server 2022 en het finetunen van Citrix Provisioning Services (PVS) golden images.
Deze post is meer dan alleen een verslag; het is een eerlijke duik in de realiteit van systeembeheer, compleet met de hoogtepunten en valkuilen van het upgradeproces. Bart deelt niet alleen zijn successen maar ook de obstakels die hij tegenkwam en hoe hij deze overwon, waardoor dit een onschatbare bron van kennis is voor iedereen die met soortgelijke uitdagingen te maken heeft.
Dus, leun achterover en bereid je voor om te leren van Barts ervaringen, die ons herinneren aan het belang van veerkracht, samenwerking en de onmisbare waarde van een goede community in de snel evoluerende wereld van IT.
Microsoft Windows Server 2022 Standard, het is al een uitdaging geweest. Zeker in het traject om het als OS te gebruiken voor onze Citrix PVS golden image .
Februari – maart 2023. Het is eindelijk zo ver: Microsoft Apps 365 (versie 2302 of later) is officieel ondersteund op Microsoft Windows Server 2022. Tijd om er een Citrix golden image van te maken 😊.
We beginnen met de group policies: Alle best practices van Microsoft en een hoop extra security => Check! Clean image gestart, alle applicaties er op, Citrix PVS, VDA, WEM, FSLogix profile containers, … Zowat alles hetzelfde als onze huidige productie image gebaseerd op Microsoft Windows Server 2019, maar dan properder, recenter. We zijn er klaar voor. We starten de testen 😊.
Windows Search issue #1
Hmmm, raar de Windows Search lijkt niet te werken, even testen wat er mis is. Misschien hetzelfde als in het begin van Microsoft Windows Server 2019? Nee, de events kloppen niet. Een beetje eigen research met onze lievelingen van Sysinternals (procmon.exe en procexp.exe) en natuurlijk Google.
Aha, iets gevonden: https://learn.microsoft.com/en-us/answers/questions/1121054/fslogix-and-windows-search-issues-in-server-2022 . Komt overeen met onze ervaringen! Process Explorer erbij en wat zien we, de search database van de user wordt na login niet zichtbaar in de handles van “Searchindexer.exe”. Windows Search service herstarten en jawel, daar zijn de handles naar de databases van de logged in users.
Ok, workaround: een event zoeken waarmee ik de Windows Search service kan herstarten bij aanlog van de gebruiker, shell start lijkt ideaal. Na wat wikken en wegen event id 2 van “Microsoft-Windows-User Profile Service/Operational” Profile Service gebruikt. Dat werkt, maar verre van ideaal, de searchindexen zullen weer rap corrupt zijn.
Opzetten testserver (volledig clean, niks config, …), RDSH toevoegen, testen … ah, het is al naar de knoppen en we hebben nog niet eens FSLogix geïnstalleerd! Ok, ticket bij Microsoft gelogd. Meerdere mails, testen en demonstraties later: De Microsoft engineers hebben hetzelfde in hun testomgeving en geven door aan de product group. Intussen eerste backport fix gekregen voor test, maar helaas, nog steeds kapot. Gelukkig genoeg kan de Microsoft support escalation engineer dit ook bevestigen en hij geeft enige tijd later aan dat ze het gevonden hebben en dat een volledige fix eraan komt.
FSLogix issue #1
Mensen die me kennen weten dat enkele bugs me niet kunnen stoppen om onze productie omgeving toch verder te testen, want de ervaring was goed. Windows Search (vooral in Outlook en OneNote nodig) werkt. Een tijdje later, huh, de 2 test productiemachines op Microsoft Windows Server 2022 rebooten met een BSOD. Dump nakijken … KMODE_EXCEPTION_NOT_HANDLED 0x0000001e ffffffffc0000005 fffff8064df67ab2 0000000000000000 0000000000000048 frxdrvvt.sys frxdrvvt.sys+7ab2 .
Verdorie, FSLogix. Wat is daar de oorzaak van? Lap, zelf veroorzaakt ☹. Een remote search op alle machines naar .ost files onder “C:\Users” doet de machines crashen (alle users hebben een FSLogix profile disk). Testserver opzetten (volledig clean, niks config, …), FSLogix er op:
- Search in “C:\Users”, geen issue.
- Search in “\\127.0.0.1\c$\users” => BSOD.
Vraagje stellen op Microsoft Q&A. https://learn.microsoft.com/en-us/answers/questions/1275494/fslogix-bsod-frxdrvvt-sys-on-windows-server-2022 . Geen reactie.
Dan maar ticket naar Microsoft. Deze keer heel snel respons! Ik heb de indruk dat FSLogix support rap reageert. Enkele sessies verder, ze hebben hetzelfde in hun testomgeving. Preview fix gekregen (Microsoft FSLogix 2210 hotfix 2), yes, opgelost. We kunnen weer verder.
Onedrive / Storage Sense
Ok, we kiezen er voor binnen ons computer / user park / Citrix omgeving weg te gaan van een homedrive op een netwerk server naar Microsoft OneDrive. Iedereen had op alle locaties wel al OneDrive, maar het was nog niet de standaard locatie.
Dat pak ik samen met de migratie naar onze Citrix image met Server 2022. We hebben intussen besloten iedereen te laten starten met een nieuwe lege FSLogix profile disk om alle achtergebleven zaken van onze Server 2016/2019 profielen achter ons te laten (behalve hun browser favorieten, die kunnen ze echt niet missen).
OneDrive hadden we dus in het verleden ook al, maar misschien was het nu tijd om er Storage Sense eens op los te laten, immers mensen gingen massaal data versluizen naar OneDrive, dus de FSLogix profile disks gingen anders de pan uit swingen.
Storage sense werkt ook effectief maar vanaf Windows versie 1903 en dus wel op Server 2022, maar niet op 2019 (tenzij misschien manueel via de registry settings).
Of dat nu veel extra load geeft of niet heb ik jammer genoeg niet doorgetest. De extra load die erbij kwam (disk queues en netwerk, … ) door de massale dataverhuis naar OneDrive baarde me wel wat extra zorgen, dus heb ik die policies maar rap terug disabled.
OneDrive move
OneDrive, … . Op de laptops / desktops was het al duidelijk dat de “Windows known folder move” precies niet echt deed wat het moet doen. Bij sommige gebruikers waren de mappen onder “quick access” en “This PC” soms wel OneDrive, soms niet.
Bij gevolg stonden er soms documenten gewoon in het userprofile, wat bij issues al eens werd gewist.
Ook op onze Citrix omgeving leek het niet consequent te lukken tijdens onze eigen testen, dus zijn we beginnen ingrijpen met iets of wat “gevaarlijke” registry settings. Gevaarlijk in de zin van: Microsoft kan hier aanpassingen doen en dan hebben we het zitten 😊. Long story short: een hele combinatie van “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders” manueel te targeten naar de OneDrive locaties. Die Onedrive locaties moeten soms nog “actief” worden, aangezien de sync client tijd nodig heeft om op te starten, dus de icoontjes op de desktop zijn “broken” tot de sync client actief is.
Verder zorgt dit er wel voor dat de gebruikers hun documenten steeds op de juiste locatie staan. Weer een stapje verder dus.
Windows Search issue #2
Een tijd verder, alle Citrix gebruikers zitten intussen op de nieuwe Windows Server 2022 image, maar we ervaren steeds meer high CPU load op de machines. Hoe meer gebruikers, hoe hoger de load (vrij logisch natuurlijk). Al snel zitten de machines tegen de 100% CPU gebruik. De verantwoordelijke: Explorer.exe. Na verloop van tijd begint die 100% van 1 CPU core te gebruiken en hoge IO reads te vertonen.
Dan maar weer Sysinternals (procmon.exe en procexp.exe) erbij halen. Na enige tijd zoeken toch een verband gevonden met Windows Search. Searchindexer.exe vertoont geen speciale CPU / IO / Memory load, maar toch valt er uit de procmon.exe traces een verband te leggen: Wanneer een machine met meerdere explorer.exe’s zit die de pan uitswingen, en we stoppen Windows Search, valt de hele machine praktisch terug naar idle.
Oef, gevonden, Windows Search … again … . Niet volledig abnormaal zou je denken aangezien we die service resetten bij aanlog van een gebruiker. We besluiten toch dat Windows Search onmisbaar is voor Outlook gebruikers en gaan op zoek naar een oplossing.
Na wat testen zijn we tot volgende group policies gekomen. Outlook indexing werkt, enkel OneNote wil niet steeds zoeken in pagina’s. Samenvatting GPO’s:
SentinelOne issue
De nieuwe Teams komt eraan. Tijd om die ook eens te testen (deze keer op de non-prod omgeving 😊 ).
Aangezien de nieuwe Teams dezelfde opbouw heeft als andere UWP apps, zoals tegenwoordig ook het NVIDIA Control Panel (MSIX, APPX), … zal dat wel enkele speciallekes met zich meebrengen. Misschien ook ineens het moment om van AppV pakketten naar MSIX over te schakelen. Ware het niet dat ik daar in het verleden al wat issue mee had op onze Windows Server 2022 omgeving.
Het is zover, Microsoft vraagt de nieuwe private preview van FSLogix te testen met de nieuwe Teams: Geen succes, het start en werkt de eerste keer wel, maar na afloggen en aanloggen enkel nog een foutmelding en events die aangeven dat de applicatie container niet kan gemaakt worden en het process niet kan starten.
Exact hetzelfde gedrag bij het NVIDIA Control Panel en een Notepad++ die ik voor test eens in een MSIX had gepackaged.
Ook hier weer een zoektocht, maar al redelijk snel zet iemand anders de oorzaak hier: https://techcommunity.microsoft.com/t5/fslogix-blog/announcing-fslogix-2210-hotfix-3-preview-2-9-8716-30241/ba-p/4001561 . SentinelOne “Behavior detection AI” engine blijkt degene die roet in het eten gooit. Zodra deze wordt uitgeschakeld werkt alles zoals het moet.
Intussen is SentinelOne ervan op de hoogte en zijn ze een onderzoek gestart. Hopelijk lossen ze het snel op, want Microsoft wil toch wel snel overschakelen naar de nieuwe Teams.
