Maandelijks archief: juni 2011

PVS probleem: Windows niet legitiem na booten target device

Geplaatst op door

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

Geplaatst op door

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

Disk Quota’s, FSRM en DFS Replicatie

Geplaatst op door

Deze week een geval tegen gekomen van misconfiguratie en gebruik van oudere technieken waardoor DFS Replicatie niet helemaal lekker wilde lopen. Het probleem lag in de instellingen van quota’s waardoor replicatie niet meer wilde lopen. Daarnaast waren de quota’s niet handig geconfigureerd. Sinds Windows 2003 R2 heeft Microsoft File Server Resource Manager (FSRM) in het leven geroepen voor het beheer van disk en folder quota’s. Dit geeft een betere quota beheer dan vroeger met de disk quota’s mogelijk was. FSRM kan quota’s zetten op folder niveau en berekend het niet per bestands-owner, maar echt de hoeveelheid data die in de folder staat. Voor homedrives is dit dus de perfecte manier om quota’s in te stellen. Als deze quota’s via FSRM worden gezet op “toepassen op alle bestaande en nieuwe subfolders” ontstaat echter een probleem bij gebruik van DFS replicatie. Standaard wordt de replicatie cache namelijk in de folder geplaatst die gerepliceerd moet worden. Als daar op hoger niveau quota’s staan gedefinieerd, krijgt de DFS folder daar ook mee te maken. Je kunt dan de volgende foutmelding aantreffen in het eventlog: “The DFS Replication service encountered errors replicating one or more files because adequate free space was not available on volume X. This volume contains the replicated folder, the staging folder, or both. Please make sure that enough free space is available on this volume for replication to proceed. The service will retry replication periodically”. Als je op dat moment binnen FSRM kijkt (en je hebt in Windows Explorer aangegeven dat je ook systeem/hidden folders wilt zien – anders toont FSRM ze ook niet!), dan zul je zien dat de staging directory van DFSR op 100% vol staat. Dit kun je op 2 manieren oplossen:

  1. Andere quota binnen FSRM toekennen aan de DFSR staging area.
  2. Staging area verplaatsen naar een locatie zonder quota’s (dit kan ook een andere disk zijn!)

Optie A heeft wat mij betreft niet de voorkeur. Mocht DFS de staging area opnieuw aanmaken, dan verdwijnt het veranderde quota op die subfolder en krijg je het probleem later terug. Optie B is wat dat betreft veiliger. Optie B is in Windows 2008 R2 makkelijk te regelen. Open hiervoor DFS management en gaan naar de replicatie tak. Kies de replicatie dfs-share waarvan je de staging area wilt aanpassen. Rechtermuisknop op de replicated folder en kies voor Properties. Je krijgt dan onderstaande scherm te zien. Kies hier voor het tabblad staging. Hier kun je een ander path opgeven voor de staging, dan het default path wat er staat. Tevens kun je eventueel de staging cache wat groter of kleiner maken. Na het drukken op OK zal de het nieuwe path bij de 1st volgende synchronisatie automatisch in gebruik worden genomen. Dit kan enkele minuten duren, afhankelijk van de snelheid van replicatie. Deze instellingen moet je uiteraard voor alle replicated folders aanpassen, als er op alle shares quota’s worden gehanteerd.

Disk Quota’s

Helaas werkte het na deze aanpassing bij de desbetreffende klant nog steeds niet. Na verder onderzoek bleek dat er ook Disk Quota’s waren ingesteld. Deze raad ik echter af te gebruiken en moet je zeker niet gebruiken in combinatie met quota’s die via FSRM zijn gezet. Ten eerste kun je deze alleen op een volledige disk plaatsen en niet op losse folders en daarnaast werken deze Quota’s met behulp van de owner van bestanden. Dat is niet de meest handige manier. Want als je als administrator bestanden terug plaatst uit een backup of kopieert na een migratie, wordt jij de owner en niet de gebruiker die de bestanden daadwerkelijk in zijn homedrive heeft. Deze ingestelde disk quota’s kunnen echter ook de DFS replicatie in de weg zitten. De staging folders zijn immers ook onderhevig aan deze quota’s. Disk Quota’s zijn in te zien door een rechtermuis op een diskstation te klikken en dan te kiezen voor properties. Ga daarna na het tabblad quota’s. Je ziet dan onderstaande (of alles is grijs, als de quota’s niet zijn ingesteld). Note: Let op, het repliceren van homedrives of profielen via DFS (in een full-mess situatie) wordt door Microsoft officieel niet ondersteund. Lees meer daarover op http://blogs.technet.com/b/askds/archive/2010/09/01/microsoft-s-support-statement-around-replicated-user-profile-data.aspx