DeployWindows•Info

A while ago we got a new model from Dell to certify, Latitude E4310, and during the certification we noticed that Remote Assistance didn’t work in the optimized screen resolution 1366×768. It looked like this

errorscreen2

 

First we thought it was something wrong with the Intel drivers, but we could replicate the problem with both Dell and HP using NVidia graphic cards as well.

We started to look at the group policy settings regarding Remote Assistance and came to the Turn on bandwidth optimization and noticed that if you enabled this and use one of the first three options it will not work, but if you choose Full optimization it works like a charm!

Settings1

To summarize the problem only affects screen resolution 1366×768 while Turn on bandwidth optimization is not set to Full optimization, strange but true Smile

View original post

Geplaatst in Het moet ergens onder staan

Installatie van multi language packs via commandline in Windows 2008 R2/Windows 7


Na installatie van het OS, wat wij als IT-ers natuurlijk in het engels installeren, kan het voor komen dat je nog een extra taal wilt toevoegen. Nou kan dat via de GUI, maar dat wil je niet altijd. Het liefst zou je zien dat je deze via RES Automation Manager of een andere uitroltool geïnstalleerd kan krijgen.

Op de languagepack cd’s van Windows 2008 en Windows 7 vind je meerdere directories. Kies de directory met de taal die je wil installeren en neem hier de lp.cab uit. Deze kun je via de commandline installeren via lpksetup /i * /p [patch of/en bestandsnaam van de languagepack] /r /s

De switches achter lpksetup.exe dienen de volgende doelen:

/i Installeer een taal
/i *

/i [taalkeuze]

Installeer alle talen in het languagepack. Mocht je een languagepack hebben met meerdere talen dan kun je hier één selectie uit maken door bv. nl-NL te gebruiken ipv ster.
/p [path naar languagepack directory]

/p [path+bestandnaam van languagepack]

Path naar een directory met alle languagepacks die je wil installeren. Wil je maar één bepaalde languagepack installeren, dan moet je ook de bestandsnaam erbij plaatsen
/r Geen reboot op het einde van de installatie
/s Stille installatie

Let er bij het gebruik van een languagepack op, dat je versie van Windows wel meerdere talen ondersteund. Installeer je een languagepack op een Windows versie die geen multi-language ondersteund, dan wordt de hoofdtaal van die installatie overschreven!

Na installatie van een languagepack heb je via de GUI de mogelijkheid om de taal in te stellen voor de gebruiker en voor het systeem. Bij Terminal Servers (of Citrix XenApp) wil je in de meeste gevallen dat bij een Nederlands bedrijf Nederlands de standaard taal wordt voor gebruikers en voor het OS/System account.

Dit kun je via de volgende commandline doen: control.exe intl.cpl,,/f:”[path naar configuratie.xml]”

Het configuratiebestand moet er voor Nederlands als volgt uitzien:

<gs:GlobalizationServices xmlns:gs=”urn:longhornGlobalizationUnattend”>

<!– user list –>
  <gs:UserList>
    <gs:User UserID=”Current” CopySettingsToDefaultUserAcct=”true” CopySettingsToSystemAcct=”true”/>
  </gs:UserList>

<!– GeoID –>
  <gs:LocationPreferences>
    <gs:GeoID Value=”176″/>
  </gs:LocationPreferences>

<!– UI Language Prefernces –>
  <gs:MUILanguagePreferences>
    <gs:MUILanguage Value=”nl-NL”/>
    <gs:MUIFallback Value=”en-US”/>
  </gs:MUILanguagePreferences>

<!– system locale –>
  <gs:SystemLocale Name=”nl-NL”/>
<!– user locale –>

<gs:UserLocale>
   <gs:Locale Name=”nl-NL” SetAsCurrent=”true” ResetAllSettings=”false”>
   </gs:Locale>
</gs:UserLocale>

</gs:GlobalizationServices>

Dit configuratie bestand zorgt ervoor dat de taal van de huidige user op Nederlands wordt gezet en dat de regionale instellingen worden gekopieerd naar het default-user profiel en naar het systeem account. De regionale instellingen worden zelf niet ingesteld (dit kan wel) en ook de toetsenbord instelling wordt niet aangepast. De instellingen worden na een reboot aktief op de machine.

Voor meer opties en meer uitleg over de opbouw van het xml-bestand kun je terecht op:

Geplaatst in IT-Tips, Microsoft, Windows 2008 R2, Windows 7 | Tags: , , ,

RES Automation Manager: RunBook Parameter Linking


In een eerdere blog heb ik laten zien hoe je via RES Automation Manager een gebruiker aan kan maken, waarbij de user logonname automatisch via een counter wordt verhoogd in het geval dat er al een gebruiker bestaat met dezelfde logonnaam. In deze blog laat ik zien hoe je die aangemaakt logonname kunt gebruiken om de homedrive voor die gebruiker aan te maken. Uiteraard zou je dit nog verder door kunnen trekken, door ook de mailbox, etc. aan te maken. Het linken of transporteren van de waarde van een module naar een andere module, kan vanaf RES AM 2011 SR1. Datgene wat wij er in deze blog mee gaan doen, kan vanaf RES AM 2011 SR2 of RES AM 2012 IR1. Het is namelijk niet mogelijk om een waarde door te geven op het moment dat de module de status ‘finished with errors’ heeft in RES AM 2011 SR1.

Create Homedrive module

Als eerste maken we een module aan voor het creëren van de homedrive. Geef de module een logische naam, zoals ‘create a homedrive’. Ga vervolgens naar de tab ‘parameters’ en maak een nieuwe parameter aan. Geef deze de naam ‘UserLogonName’ (zonder de ‘ ‘) en stel de parameter zo in dat deze vraagt om een waarde op het moment dat hij gescheduled word. Check tevens de checkboxen en zorg ervoor dat alleen de box ‘Hide parameter if parameter is not used directly’ aangevinkt is.

Ga vervolgens naar het tabblad ‘Tasks’ en maak een nieuwe task aan. Kies voor ‘Configuration -> Files -> Perform operations. Maak hierin een nieuwe aktie type ‘Create Folder’ aan. Bij ‘Folder Path’ type je het path waar de folder aangemaakt moet worden. De driveletter is de letter van de drive van de server waar de map op aangemaakt word. Deze server moet uiteraard ook een RES AM Agent geïnstalleerd hebben. Plaats de cursor vervolgens achter de laatste ‘\’ in het path en selecteer de ‘UserLogonName’-parameter (dit kun je doen door een rechtermuisknop -> Insert Parameter -> $[UserLogonName] )

Klik OK en nogmaals OK om de ‘Perform file operation’-task af te sluiten.

Maak nu een nieuwe taak aan in de module. Kies hiervoor Security -> File Permissions -> Set. Gebruik dezelfde folder als in de ‘create folder’-task die je net hebt aangemaakt en vink het vinkje bij ‘Remove all existing permissions’ uit. Dit voorkomt dat standaard permissies die al bestaan op de folder (bv. Domain Users full control), worden verwijderd. Kies vervolgens voor ‘Add Entry’

In de ‘Add entry’ dialog venster kies je voor the ‘UserLogonName’-parameter (via rechtermuisknop) en vervolgens voor ‘Full control’ en ‘Add access allowed’

Klik vervolgens op OK, nog eens OK (om het venster van de taak Folder Permissies te sluiten) en nogmaals op OK (om de module te sluiten). De module voor het aanmaken van de homedrive is nu klaar. Je kunt deze testen door de module eenmaal uit te voeren, een testuseraccount op te geven en deze te module te starten op de machine waar de homedrives op aangemaakt worden. Controleer na het uitvoeren of de directory is aangemaakt en de juiste rechten er op zijn uitgedeeld.

Runbook parameter linking

Nu we beide modules hebben voor het aanmaken van een gebruiker en het aanmaken van een homedrive, gaan we deze samen plaatsen in een RunBook. Hierbij gebruiken we de aangemaakt UserLogonName uit de eerste module als input voor de ‘create homedrive’-module.

Maak een nieuwe RunBook aan en geef deze een goede naam, zoals ‘Create user and homedrive’. Ga vervolgens naar het tabblad ‘Jobs’ en maak hier een nieuwe job aan. In het ‘Add RunBook job’ venster kies je eerst voor ‘What’. Selecteer vervolgens de ‘Create domain user’ task. Vervolgens kies je in het ‘Who’ veld de juiste machine. In het geval van het aanmaken van een user account, zal dit waarschijnlijk de domain controller zijn. Op deze machine moet ook de juiste connector voor deze taak zijn geïnstalleerd. Onder het venster kies je voor ‘Continue Run Book on Error’ in het ‘Error control’ veld. Deze instelling is nodig om het RunBook door te laten gaan in het geval de module met het resultaat ‘Finished with errors’ terug komt (wat niet onwaarschijnlijk is dat dit gebeurd, omdat er regelmatig mensen zijn die dezelfde gebruikersnaam opleveren). Druk vervolgens op OK om de job aan te maken.

Maak vervolgens een tweede job aan. Selecteer hierbij de ‘create user homedrive’ en zorg ervoor dat deze op de fileserver komt te draaien. De fileserver kan van een normale agent worden voorzien. Laat ‘error control’ op de default waarde ‘stop run book on error’ staan.

Nu beide jobs in het RunBook staan, kies je voor het tabblad ‘Run Book parameters’ en klik je vervolgens op de knop ‘AutoCreate’ (onderin het venster). RES Automation Manager creeerd nu alle parameters die ook in de modules en/of projecten worden gebruikt. Verwijder na het aanmaken de ‘Counter’-parameter. Dubbelklik vervolgens op de UserLogonName om deze aan te passen. Maak het veld ‘Value’ leeg en ga vervolgens naar de ‘Links’ tab in dit dialoog venster. Klik hier met rechts op de ‘Create User Account’-job en kies vervolgens voor Action -> Get final value. Dit zorgt ervoor dat op het einde van de job, de waarde van UserLogonName wordt teruggegeven aan het RunBook.

Klik vervolgens met de rechtermuisknop op de ‘Create home drive’-job en kies voor ‘Set initial value’. Het resultaat zou vervolgens moeten zijn wat hieronder staat. De richting van de pijlen is hierbij het belangrijkste.

Klik op OK om terug te gaan naar de RunBook parameters tab. Klik hier op de ‘Links’ tab, deze zou er ongeveer zo uit moeten zien:

Op dit moment hebben we een RunBoom met twee verschillende jobs die mogelijk draaien op twee verschillende servers. De 2de job (het aanmaken van een homedrive) is afhankelijk van de gebruikersnaam die de eerste job (create user) heeft aangemaakt. Als de eerste job heeft gedraaid, wordt door het linken van de parameters, de laatste waarde van de UserLogonName-parameter van de job, getransporteerd naar de gelijkwaardige parameter in de RunBook. Het RunBook start vervolgens de 2de job en geeft deze (ook weer via de gelinkte parameters) de waarde mee die hij van de 1ste job heeft ontvangen. De 2de job maakt daardoor een homedrive aan met de user logonname die de 1ste job uiteindelijk heeft gecreeerd.

Nu hebben we alleen een problem als de ‘create user’-job faalt en het resultaat ‘failed’ krijgt. Doordat is aangegeven dat het RunBook door moet gaan als er problemen optreden, zal hij ook doorgaan als het resultaat ‘failed’ is. Om dit te voorkomen moeten we een conditie op de 2de job zetten. Ga daarvoor naar het tabblad ‘jobs’ van het RunBook, selecteer de 2de job (‘create home drive’) en klik onderaan het scherm op ‘condition’. Maak een nieuwe conditie aan met de volgende waarde ‘Status of previously executed job <> Failed’. Als de conditie WAAR (TRUE) is dan ‘Executed job’. De waarde bij FALSE komt op ‘Skip this and all other jobs’. Dit zorgt ervoor dat andere jobs (na het creeeren van de homedrive) in hetzelfde RunBook ook niet gedraaid worden (bijvoorbeeld het aanmaken van een mailbox).

Resultaat

Als we dit RunBook nu draaien en de voornaam, achternaam, etc. opgeven, maakt het RunBook eerst een gebruikersaccount aan. Daarnaa wordt de homedrive gecreëerd, tenzij de gebruikersnaam niet aangemaakt kon worden. Vraag je de uitslag van het RunBook op na draaien, dan zie je ongeveer hetgene hieronder:

  1. Het aanmaken van de user. De eerste 5x gingen niet goed. Na de 5de keer werd de gebruiker wel goed aangemaakt.
  2. Toont de settings die uiteindelijk via parameters gebruikt zijn in het process van het aanmaken van de gebruiker. De uiteindelijke gebruikersnaam is DuckK5 geworden.
  3. Let op de counter, deze toont het getal 5. Dit zijn de verhogingen van het getal achter de gebruikersnaam die ontstaan zijn doordat het aanmaken de eerste 4 keer niet goed ging, omdat die gebruikersnamen al bestonden.
  4. The job parameter die doorgegeven is aan de job ‘create home drive’. Deze bevat de user logonnaam die in de eerste stappen is gemaakt door de 1ste job.

Dit RunBook kun nu eenvoudig uitgebreid worden met bv. het aanmaken van een mailbox of het geven van rechten op andere systemen waar de gebruikersnaam van belang is. Via een CSV bestand kunnen snel meerdere gebruikers aangemaakt worden en ook is via Service Orchestration deze module te gebruiken om automatisch gebruikers aan te maken.

Geplaatst in Automation Manager, RES | Tags: , , ,

XenClient: Backup en Restore VM’s zonder Synchronizer


Mocht je Citrix XenClient testen of gebruiken, dan wil je af en toe wel een backup maken van je VM, voor het geval dat er eens iets mis gaat. Ook als je upgrade naar een nieuwe versie van XenClient kan het handig zijn om een backup te maken. Bij een upgrade is het namelijk niet altijd mogelijk om de bestaande VM’s te bewaren.

Normaal is dit eenvoudig te bewerkstelligen via de Synchronizer. Alleen, niet iedereen heeft die beschikbaar. Het is met wat omwegen toch mogelijk een backup te maken. Hiervoor heb je wel een extra computer in hetzelfde netwerk nodig.

Op de disk van de machine met XenClient staan een aantal directories. XenClient slaat de configuratie van VM’s op in de .\config\vms directory. De daadwerkelijke VHD’s van de VM’s worden opgeslagen in .\storage\disks. Helaas zijn de configuratie bestanden en de disken niet onder een logische naam opgeslagen, maar onder UUID’s.

Backup van een XenClient VM

Stap 1: Opvragen van VM UUID

Als eerste moet je erachter komen wat de UUID is van de VM die je wilt backuppen. Open daarvoor eerst een Terminal venster door in de GUI van XenClient de toetsencombinatie Control+Shift+T in te drukken. Er opent zich nu een terminal venster, waarin gevraagd wordt naar het root-wachtwoord. Voer deze in. Je krijgt nu “root@xenclient-dom0:~#” te zien. Voer hier het commando xec-vm in. Hiermee vraag je een overzicht op van alle VM’s die binnen XenClient bekend zijn, met hun logische naam en hun UUID. De uitvoer ziet er ongeveer als volgt uit:

Onthou de UUID van de machine die je wilt backuppen.

Stap 2: Remote verbinding met XenClient

Voor het extern verbinding maken met XenClient vanaf een andere machine moet je SSH hebben geactiveerd. Het activeren van SSH wordt gevraagd bij de installatie van XenClient. Heb je het toen niet geactiveerd, dan kun je het via het terminal venster alsnog activeren. Type het volgende commando om SSH binnen XenClient te activeren: touch /config/ssh_enabled , druk daarna op control+q om de interface van XenClient een refresh te geven en SSH te activeren.

Daarnaast heb je het IP adres nodig van de XenClient. Heb je de XenClient 2 TechPreview of hoger, ga dan binnen de XenClient GUI naar het netwerk icoon rechtsbovenin. Kies daarna voor “Connection Information“. Hier vind je het ip adres van de wireless of wired verbinding. Heb je nog XenClient 1, dan kun je het volgende commando invoeren in een terminal venster: ifconfig | less
. Het IP adres wordt getoond bij brbridged (bij bedrade verbinding) en bij wlan0 (bij draadloze verbinding).

Installeer nu WinSCP op een andere machine. Open WinSCP en maak een verbinding naar de XenClient machine door het ip-adres in te voeren, root als user name en het wachtwoord van de root.

Druk vervolgens op Login. Mocht je een waarschuwing krijgen over een certificaat, dan kun je deze gewoon vertrouwen en opslaan. Dit is het self-made certificaat dat XenClient gebruikt.

Je krijgt nu een scherm te zien met aan de linkerkant de machine waar WinSCP op draait en op de rechterkant van het scherm de disk van de XenClient machine.

Stap 3: Opzoeken locatie van de VHD

Browse in het rechterveld van WinSCP naar ..\config\vms.

Hier staan enkele bestanden in, met dezelde UUID’s als in stap 1. Open het bestand dat correspondeert met de UUID die je wil backuppen, door er op te dubbelklikken. In het bestand dat zich nu opent moet je op zoek gaan naar het trefwoord “disk”. Iets daaronder staat het path naar de VHD die gebruikt wordt voor de VM.

Mochten in dit bestand meerdere VHD’s staan. Dan is de VM al een keer gesynchroniseerd met een Synchronizer, of heb je de VM gedownload van een Synchronizer. In dat geval kun je niet zomaar een backup maken van de VHD. In dat geval moet je naast de VHD’s die in dit bestand staan, ook de config file backuppen.

Stap 4: Backup van de VHD

Een backup maken is nu simpel. Ga in het rechterscherm naar de locatie die je in stap 3 hebt gevonden. Alle VHD’s staan in de directory ..\storage\disks. In het linker gedeelte van WinSCP ga je naar de locatie waar je de backup van de VHD wil plaatsen. Sleep nu het VHD bestand van het rechterscherm naar de linkerkant. WinSCP kopieert nu de VHD naar je backup locatie.

Restoren van een XenClient VM

Het restoren gaat op de volgende manier:

  1. Maak een nieuwe VM aan via de Add-VM Wizard. De grootte van de harddisk van de VM maakt niet uit. Deze kun je gerust op 10gb zetten. Kies op het einde om de VM wel aan te maken, maar nog geen installatie te doen.
  2. Vraag de UUID op (zie stap 1 van backup)
  3. Maak verbinding via WinSCP (zie stap 2 van backup)
  4. Open de configfile (zie stap 3 van backup)
  5. Ga naar de directory met de VHD’s en rename de originele vhd van de VM (bv. door deze de extensie .old te geven)
  6. Kopieer nu de backup VHD naar de storage locatie van de XenClient.
  7. Rename de oude vhd naar de UUID van de disk die bij de net aangemaakt VHD hoort.
  8. Start de VM
Geplaatst in Citrix, IT-Tips, XenClient | Tags: , ,

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 Files\microsoft shared\OfficeSoftwareProtectionPlatform\OSPPREARM.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:

Geplaatst in Citrix, Provisioning Server | Tags: , , , , ,

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:\windows\system32\drivers -> 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 )

Geplaatst in Citrix, IT-Tips, Provisioning Server | Tags: , , , , , , ,

Disk Quota’s, FSRM en DFS Replicatie


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

Geplaatst in IT-Tips, Microsoft, Windows 2008, Windows 2008 R2 | Tags: , , , ,