Imagebeheer automatiseren: doen of niet doen?

Als er voor machines op basis van images wordt gekozen, zoals bij VDI of booten met Citrix PVS, moet er nagedacht worden over de methode van image-opbouw en -beheer. In deze blog laat ik zien welke mogelijkheden er zijn en welke methode het beste werkt in de praktijk.

Lees verder

Citrix XenApp 6.5 Full Load bij MUI pack

Ik ben erg voorstander van de advanced loadbalancer (of load evaluator) van Citrix XenApp, om ervoor te zorgen dat alle gebruikers netjes verdeelt worden over de servers. Over het algemeen stel ik een maximum aantal users in (na een performance test) in combinatie met CPU- en Memoryload en Load Throttling (tegen inlog-stormen)

Bij een klant is de omgeving opgebouwd zoals normaal. Engelse versie van Windows 2008 R2, XenApp 6.5, Nederlands MUI pack, laatste Microsoft fixes en XenApp updates. Default staat bij de opbouw de load balancer op default en rond de periode dat we de performance tests gaan doen en de pilot groep op de servers gaat landen schakelen we de advanced loadbalancer in. Deze keer liep ik echter tegen een probleem op die ik in andere omgeving nog niet heb gezien. Zo gauw CPU- en Memoryload in de load balancer werden geactiveerd gingen alle servers op Full Load (load van 10000) en kwam er niemand meer op, terwijl de servers zelf niets te doen hadden.

De verdenking viel al snel op regionale instellingen, maar nadat alles op engels was gezet (incl. system en default user) hadden we het probleem nog steeds.

Na wat zoekwerk kwam ik uit bij CTX124991. Een wat ouder artikel wat het probleem omschrijft op 64 bit systemen die een MUI geïnstalleerd hebben. De oplossing is om een key toe te voegen:

HKLM\Software\Wow6432Node\Citrix\Ima\LMS

DWORD:EnableTranslation = 1

Deze key kon echter niet zonder slag of stoot worden toegevoegd. De key is beveiligd zodat alleen het Citrix serviceaccount en System er bij kunnen. Om dit op te lossen moet je eerst een Take Ownership doen op de key (CTX133412). Daarbij krijg je foutmeldingen bij het toepassen omdat een subkey geen ownership heeft. Die foutmelding kun je negeren, na het wegklikken ervan kun je via Annuleren (anders blijf je de foutmelding krijgen) alles afsluiten en de eigenschappen van de key weer openen. Vervolgens kun je bovenstaande key wel toevoegen.

Let op: Als je Citrix Provisioning Server (PVS) gebruikt moet je deze key opnemen in het image. De key opnemen in een GPO Extensions geeft deze te laat door aan de services waardoor hij niet wordt doorgevoerd en je alsnog een Full Load krijgt.

PVS probleem: Windows niet legitiem na booten target device

Om te zorgen dat alle target devices bij Citrix Provisioning Server geactiveerd worden, moet je in het kort de volgende stappen doorlopen bij gebruik van een KMS server:

  1. Installeer het OS op je master device
  2. Activeer deze via een KMS key
  3. Maak een image via de image converter, kies in de wizard voor KMS
  4. Plaats het nieuwe image/vdisk in private mode. Boot een target device van de vdisk
  5. Na booten open je een administratieve commandprompt en type je slmgr /rearm
  6. Nu kun je de machine afsluiten, de disk in standard mode zetten en andere machines er mee booten. Deze zijn als unieke machines bekend op de KMS server. Bij volgende updates van de vdisk hoef je dit niet meer te doen.

Althans, dat is de uitleg van Citrix. Helaas kom ik toch regelmatig voor dat, ondanks dat je bovenstaande stappen volgt, de vdisk toch een probleem laat zien na een update, welke allemaal wijzen op een mislukte activatie en het niet meer geldig zijn van de KMS configuratie. Mogelijkheden bevatten onder andere:

  • De melding “An unauthorised change was made to the system…” .. “er is een niet-toegestane wijziging in Windows aangebracht”


  • Melding rechtsonderin het bureablad dat Windows niet meer legitiem is, al dan niet met een zwarte achtergrond

  • Een activatiescherm nadat je ingelogd bent, met het verzoek opnieuw te activeren.

Als je hierna via het dos-commande slmgr –dlv de status van activatie opvraagt, zul je een foutmelding krijgen dat er geen serialkey is ingevoerd.

Deze meldingen kun je oplossen door de activatie procedure opnieuw te volgen. Hiervoor moet je de volgende stappen doorlopen:

  1. Zet de target device uit.
  2. Open de file properties van de vDisk.
  3. Zet in de vdisk properties de KMS op none en plaats de vdisk daarna in private mode.

    Mocht de vDisk al in private mode staan, zat hem dan eerst op standard mode en sluit de properties af. Open daarna het propertiesscherm weer en plaats de vdisk terug in private mode.

    De reden dat je dat op deze manier moet doen, is omdat de PVS console de instellingen van MAK/KMS alleen opslaat als de vdisk mode wordt aangepast.

  4. Zet de vdisk in Private mode en boot de machine.
  5. Log in, negeer de “serialkey is niet geldig”-meldingen die je kan krijgen. Sluit eventuele activatie vensters.
  6. Open een administrative commandprompt
  7. Type in slmgr -ipk [serialkey voor kms] (zoek hier de juiste KMS serialkey die je moet gebruiken en type de serialkey zonder de [ ] erom)
  8. Type in slmgr -dlv om te checken of de key goed is doorgevoerd. Je zou een melding moeten krijgen dat activatie pending is, zoals hieronder:

  9. Type in slmgr -ato om te testen of activatie via kms goed gaat. Je kunt hierna weer via slmgr –dlv testen of alles goed is. Je zou dan ongeveer de volgende melding moeten krijgen:

    Onderin staat aangegeven bij welke KMS server de client zich heeft aangemeld (kms-computernaam van DNS).

  10. Type in slmgr -rearm om de alles op scherp te zetten voor heractivatie.
  11. Voor office 2010 met KMS: type in c:Program Files(x86)Common Filesmicrosoft sharedOfficeSoftwareProtectionPlatformOSPPREARM.EXE
  12. Sluit de vdisk af.
  13. In de vdisk properties weer KMS inschakelen en de disk in standard mode zetten.

Start nu meerdere target devices op. Als het goed is, krijg je nu geen meldingen meer. Op het moment dat je in de machines een commandprompt start en slmgr –dlv invoert, behoort elke CMID (client kms-id) anders te zijn op de verschillende target devices. Deze CMID is bijna onderin het scherm te vinden. Als dit ID niet uniek is op alle machines, krijg je in later stadium activatie problemen. Het kan meerdere oorzaken hebben, waaronder het niet goed doorlopen van bovenstaande punten en/of niet goed werkende PVS servers/agents (check logfiles).

Meer informatie over: