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

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:

Dell servers, Citrix Provisioning server en Windows 7/Windows 2008R2 SP1

Als je Citrix Provisioning Server (PVS) gebruikt op een Dell server, dan kan het zomaar gebeuren dat je na het maken van een image van een master device een ander device start van hetzelfde image en je onderstaande scherm te zien krijgt:

Dit is een STOP: 0x0000007B error ( STOP 0x7B INACCESSIBLE_BOOT_DEVICE). Deze treedt op direct na het Windows logo (of eigenlijk het ‘wandelend’ balkje). Dat is het punt dat Windows de harddisk probeert te benaderen en het punt dat de PVS driver dus de boel moet oppakken, wat die blijkbaar niet doet.

Helaas is het geen probleem van PVS, maar van Windows. Het probleem treedt ook op bij het wisselen van een iSCCI controller. Citrix heeft dit uitgezocht met Dell (zie ook CTX125317 ) en Microsoft heeft hier later een patch voor uitgebracht (zie KB2344941 ). Deze patch had in SP1 moeten zitten, maar om een of andere reden heeft Microsoft hier een foutje in gemaakt. De hotfix zit NIET in SP1, erger nog, SP1 draait de patch terug. Dus mocht je al een Dell server hebben draaien met PVS en dit probleem eerder hebben opgelost met KB2344941, dan moet je er rekening mee houden dat de fout terug komt als je SP1 installeert. De huidige hotfix van Microsoft kun je niet installeren op SP1, deze weigert domweg te installeren omdat het OS patchlevel niet klopt. Microsoft heeft het ‘probleem’ op dit moment in onderzoek .

Voorlopig is er een workaround. Hiervoor moet je de pci.sys van een werkende server met de patch kopieren naar de server waar je al SP1 op hebt gezet. Dit is echter niet zo makkelijk als het lijkt. Windows blokkeert namelijk het overschrijven van systeembestanden, en dat is pci.sys. Mocht je het toch proberen dan krijg je de melding “You do not have permissions to perform this operation” of “You need authoriszation from TrustedInstaller in order to perform this action”. Gelukkig is hier om heen te werken en wel op de volgende manier:

  1. Mount de vdisk met het image MET SP1 erop in de verkenner. Dit kun je doen onder disk management of via de PVS console (rechtermuis op de vdisk -> mount vdisk)
  2. Klik rechts op pci.sys (te vinden in x:windowssystem32drivers -> vervang X door de driveletter van de gemounte vdisk) en kies voor Properties
  3. Ga naar het tabblad security en druk op Advanced

  4. Klik nu vervolgens op het tabblad Owner. Je zult zien dat hier “TrustedInstaller” staat.

  5. Klik op Edit en voeg jezelf (of domain admins) toe als owner van het bestand.
  6. Nadat je je zelf het toegevoegd geeft Windows het desbetreffende account als owner weer. Kies vervolgens OK in elk scherm totdat je terug bent in de Windows Verkenner.
  7. Ga nu opnieuw naar de properties van pci.sys en ga naar het tabblad security. Kies vervolgens voor Edit

  8. Voeg nu Domain admins of jou eigen account toe aan de lijst gebruikers en geef deze vervolgens Full Control

  9. Druk vervolgens op OK en nogmaals op OK. Nu mag je pci.sys aanpassen (renamen, verwijderen, overschrijven). Mijn advies, rename de huidige pci.sys naar pci.org en kopieer dan de pci.sys van de server zonder SP1 maar met de hotfix in deze directory.
  10. Unmount de image en boot de target device (niet de master). Je zult zien dat hij nu wel de volledige bootprocedure doorloopt.

(methode en screenshots gedeeltelijk overgenomen van HelpdeskGeek: Windows 7 – How to Delete Files Protected by TrustedInstaller )

— Update 4 mei 2012 —

Ondertusssen heeft Microsoft ook de fix beschikbaar gesteld voor SP1. Zie daarvoor KB2550978