Let op! Om dit artikel niet te langdradig te maken, gaan we er van uit dat de lezer al ervaring met MDT heeft en beschikt over een werkende (test) installatie van een recente versie van MDT. In dit artikel zal ik gebruik maken van Server 2008R2 met de meest recente versie van MDT: 2012RC1.

Als je je wil inlezen op het gebied van MDT dan raad ik het volgende artikel op windowsnetworking.com (link) aan. Deze is wel al wat verouderd maar erg uitgebreid en duidelijk geschreven.

Als basis voor dit blog gaan we uit van het volgende scenario, waarbij er deployments uitgevoerd moeten worden zonder hierbij input te hoeven geven op de computer:

- Een werkende ADDS-infrastructuur (2008 R2)
- Een recente versie van MDT in gebruik voor het deployen van computers, in Native Mode.
- Client systemen welke PXE/Networkboot als eerste in de bootorder hebben staan.

Starten via het netwerk is een ideale oplossing om makkelijk veel system te voorzien van een nieuw image, maar zonder actieve controle op welke machines er van het netwerk mogen starten is dit erg arbeidsintensief. Je wil niet naar elk systeem toe lopen en ook de gebruiker niet belasten met instructies over hoe ze het systeem van het netwerk kunnen laten starten. De eerste stap in deze serie is dan ook de controle krijgen over welke systemen er van het netwerk mogen starten en welke niet.

Wat willen we precies bereiken? 

Onbekende systemen starten niet via PXE
- Bekende systemen zonder "advertisement" starten niet via PXE
- Bekende systemen met "advertisement" starten via PXE (en krijgen de juiste task sequence toegewezen, deel 2)
- Toekennen van een deployment versimpelen door RES Automation Manager in te richten.

Hoe willen we dit gaan bereiken?

Aan de basis van het starten naar de WDS/MDT omgeving staat een bootprogram. De meest bekende is "abortpxe.com" welke bij genoeg mensen wel eens voor hoofdpijn gezorgd heeft. In dit artikel is het echter onze grote vriend.

Na wat ploegen in het Windows register kwam ik de volgende waardes tegen:

"Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlset\services\WDSServer\Providers\WDSPXE\Providers\BINLSVC\Bootprograms\"

Onder deze hive staat een drietal keys: 
- ia64 
- x64
- x86

De "x64" en de "x86" zijn de keys die worden aangesproken voor het booten van respectievelijk 64-bits en 32-bits systemen.

Onder beide keys kun je de volgende strings vinden:

- Default     REG_SZ     boot\x64\pxeboot.com
- N12          REG_SZ     boot\x64\pxeboot.n12

Het is je misschien direct wel duidelijk dat deze strings de waarde bevatten die gegeven wordt wanneer een computer van het netwerk mag starten. Door het laatste gedeelte (pxeboot.com/n12) te veranderen in "abortpxe.com", zullen alle computers die van het netwerk starten direct de instructie krijgen om te stoppen met het starten van het netwerk. In WDS zullen we dus ook de instellingen zo veranderen dat alle computers zonder vraag van PXE zullen booten, zoals in onderstaand screenshot:


 

Om het booten van onbekende systemen te versnellen lijkt het mij het verstandigst om de PXE Response zoals hieronder in te stellen:

Met deze instelling starten alle systemen, bekend of onbekend, via PXE op en door de eerder gemaakte instellingen zal het commando "abortpxe" uitgevoerd worden en zal het systeem op een andere manier booten. Er zijn scenario's te bedenken waar je de optie "Require administrator approval...." aan wil zetten, bijvoorbeeld als je niet beschikt over een lijst met computernamen en MAC-adressen. Wanneer je deze optie aanzet kun je in de WDS-console de computer handmatig goedkeuren en ook een computernaam geven. Deze wordt dan meteen met het goede GUID in AD aangemaakt waardoor het een "approved" computer is geworden. 

Oké, nu start dus niets en niemand meer van het netwerk, wat nu?

Na wat onderzoek ben ik erachter gekomen dat een computeraccount in AD voorzien kan worden van verschillende attributen die door WDS uitgelezen worden, namelijk:

- netbootMachineFilePath met value naar het bootprogram
- netbootGUID met value "0000000000000000000012345678912" (unicode, 20 * 0 en het MAC-adres van de client)

Deze variabelen kunnen we heel makkelijk via de properties van een computeraccount in Active Directory Users and Computers (ADUC) aanpassen. Wanneer je de properties van een computeraccount opent en naar het tabblad "Remote Install" gaat zul je de waarden zoals in het onderstaande voorbeeld vinden:

Als "unique ID" vullen we hier het MAC-adres van de client in, met daarvoor twintig nullen. Is bijvoorbeeld je MAC-adres "00-0C-29-6D-B8-2D", dan vul je "{00000000-0000-0000-0000-000C296DB82D}" in.

In het vakje "Remote Installation Server" kun je nu het volgende invullen:

"\boot\x64\pxeboot.n12", waar tussen haakjes natuurlijk het FQDN van je WDS server staat.

Pxeboot.n12 zorgt ervoor dat het systeem direct via het netwerk geboot wordt. Wil je toch nog wat interactie overhouden of bijvoorbeeld er voor zorgen dat je niet per ongeluk een verkeerde client of server gaat deployen dan kun je kiezen voor pxeboot.com. Deze zal eerst vragen om F12 in te drukken alvorens van het netwerk te starten. 

Alle bovengenoemde stappen zijn overigens ook via de commandline te doen, zodat je het eventueel kan scripten of in een bestaande applicatie (bijvoorbeeld UMRA, RES Automation Manager) kan hangen.

De commandline is als volgt:

Bij een nieuw systeem, dat gestaged moet worden (wat we uitvoeren kun je "prestagen" noemen)

wdsutil /add-device /device:/ID:00000000000000000000

Dit creëert een nieuwe computer in AD met de gekozen computernaam en MAC-adres. Eventueel kun je met de  "/OU:"-waarde nog bepalen in welke OU nieuwe computers moeten komen. Dit kan van toepassing zijn op bijvoorbeeld welke task sequence uitgevoerd wordt door MDT.

Een bestaand systeem kan zo voorzien worden van de juiste GUID:

wdsutil /set-device /device:/ID:00000000000000000000

Wat kan helpen bij het bouwen van een meer geautomatiseerde oplossing is de kennis dat de computer attribute "netbootMachineFilePath" overeenkomt met de "Remote Installation Server" en de computer attribute "netbootGUID" onder water hetzelfde is als "Computer's unique ID". 

Wat hebben we nu bereikt? 

Wanneer we alle computers geprestaged hebben en alle zijn voorzien van de juiste GUID hebben we de volgende controle gekregen:

- Onbekende systemen krijgen reactie van de PXE server maar laden abortpxe.com
- Bekende systemen krijgen reactie van de PXE server maar laden abortpxe.com
- Bekende systemen waarbij we de "Remote Installation Server" aangepast hebben starten naar WDS/MDT

Wordt vervolgd

In het volgende blog gaan we de tweede stap in het automatiseren van deployments aanpakken. Dit zullen we gaan doen door MDT zodanig te configureren dat:
1. Na het starten via PXE de "Remote Installation Server" weer blanco gemaakt wordt zodat het systeem niet meer via het netwerk start.
2. De MDT wizard kijkt naar welke groep of OU de computer lid van is en op basis van deze informatie een task sequence kiest.
3. Na de deployment de computer weer naar de algemene OU verplaatst.