The case of… het zwarte scherm na aanmelden op XenApp omgeving

Gepubliceerd door Erik Bakker op

Enige tijd geleden ben ik door en ICT organisatie benaderd om eens een troubleshoot uit te voeren op een Citrix omgeving die bij een van hun klanten draaide. (ik word als freelancer vaker voor dit soort klussen benaderd als de eigen organisatie een probleem heeft waar ze zelf niet uitkomen en graag een onafhankelijke partij er eens een blik op willen laten werpen)

Na het oorspronkelijke probleem opgelost te hebben (oorzaak en oplossing zijn wellicht leuk voor in een later blogitem) leek het mij en de organisatie zelf wel slim om ook de core componenten van de omgeving eens te voorzien van de broodnodige updates. de XenApp delivery controllers en ook de VDA’s op de Citrix server zijn vervolgens geüpdatet naar de nieuwste versie.

Omdat de klant ook gebruikt maakt van Citrix Provisioning Server (7.1) is besloten om ook deze componenten te updaten.  Servercomponenten heb je vrij snel geupdate zonder veel handelingen, echter om de targets te updaten moet er een zogenaamde ‘reverse image’ gemaakt worden van de disk naar een ‘lokale virtuele disk’  waarna de target device software geüpdatet kan worden. dit is in veel gevallen een tijdrovende klus omdat de volledige windows installatie teruggezet moet worden naar een disk waarna als de update klaar is de disk weer geimaged moet worden naar de Provisioning server. hoe groter de disk en hoe trager de onderliggen infrastructuur hoe langer de klus duurt

kortom: image ingeladen in private mode, bnimage gestart op de server en een reverse image gemaakt, target device geüpdatet naar 7.6 SP 3 en voila.. rebooten en met bnimage terugzetten naar de PVS server.

…en toen.. gebeurde er na het inloggen he-le-maal niets.. geen RES startscherm maar een ‘black screen’  zonder dat er iets gebeurde in de sessie…hmmm niet leuk!  na enig troubleshooting tot de conclusie gekomen dat de citrix hooking dll’s niet geladen konden worden omdat deze verwezen naar c:\progra~1\citrix\system32 en het pad hierna er niet meer was.. althans niet in zijn korte  formaat maar wel in c:\program files\citrix\system32 en tja die verwijzing werkt dan niet meer als je geen lange bestandsnamen meer hebt op het systeem.

hoe kan dat? 8.3 bestandsnamen heb ik niet expliciet uitgezet dus om een of andere reden is dit door bnimage uitgezet tijdens het terugzetten van het image.

nu zijn er gevallen bekend uit het verleden (PVS 6.1) waarbij bnimage.exe idd de 8.3 bestandsnamen om zeep kon helpen. maar in 7.1 nog steeds? wat als ik nu zoals het artikel aangaf XenConvert ging gebruiken?

..apart met XenConvert hetzelfde probleem, althans al ik een disbox open om de status van de 8.3 bestandsnamen te bekijken dan zie ik voordat ik de bnimage of xenconvert start het volgende

Schermafbeelding 2016-02-13 om 20.32.18

kortom: 8dot3 name creation staat aan op het volume waar ik het image op wil terugzetten (reverse image) en dat dit een ‘per volume’ setting is middels het register (default, niks aan gedaan) zo ingesteld is

nu starten we echter bnimage.exe om een image te maken van C: naar D:

HEY! zodra ik een image ga maken en vervolgens op de achtergrond een query doe van de 8.3 status op de disk zie ik deze ‘disabled’ worden

Schermafbeelding 2016-02-13 om 20.35.25

dan is bnimage dus de boosdoener en heeft versie 7.1 (die er toen nog opstond dus het probleem) ok dan ga ik conform KB artikel van citrix niet bnimage.exe gebruik om een image te maken maar xenconvert.

ja hoor, zodra ik een image wil omzetten van C: naar D: zet Xenconvert ook het vlaggetje om 8.3 bestandsnamen te maken uit (!)

Schermafbeelding 2016-02-13 om 20.40.29

das een naar bugje! om eea eens nader uit te sluiten heb ik ipv de standaard optie ‘per volume’ in het register van windows eens ingesteld om dit gewoon altijd te doen dus niet ‘per volume basis’

dit kan via onderstaande key

https://technet.microsoft.com/en-us/library/cc778996(WS.10).aspx

je hebt dus 4 mogelijkheden waarbij de standaard waarde ‘2’ is welke dus staat voor ‘per volume’

wat nu als ik deze eens op een andere waar zet? de waarde 0 zou dan voor de hand liggen ‘altijd korte bestandsnamen genereren’

fsutil 8dot3name query d: geeft nu het volgende weer

Schermafbeelding 2016-02-13 om 20.47.30

state is 0 dus altijd aan voor alle volumes.. ok dan. normaals bnimage.exe starten en kijken wat hij doet.

ik zie dat bnimage het vlaggetje wel op disabled heeft gezet voor het volume maar dat de registry key die op 0 staat hem overruled en zegt ‘8.3 namen wel gebruiken’

Schermafbeelding 2016-02-13 om 20.53.18

voila, nu werkt het wel goed. 8.3 namen worden aangemaakt en bnimage blijft nu gewoon van het volume af.

moraal van dit verhaal: zet altijd via een GPO deze setting op 0, zo voorkom je problemen bij het reverse image maken. overigens vanaf PVS 7.6SP1 is een reverse image niet meer nodig als je upgrade naar nieuwe versies van PVS (bv naar 7.7) maar helaas nog wel als je je HyperV integration services moet upgraden (of XenServer tools)

Categorieën: CitrixXenApp