OK so we start up Windows System Image Manager (WSIM) and create a deployment share, which is in my Setup share (where all the other setup files and images are stored). AIK uses something similar to MDT; as far as I can tell, MDT adds a few folders to a basic AIK deployment share. I’ve started up a new one rather than trying to use one of my MDT shares. Next, select an image – I went into MDT shares and selected the Windows 7 Ent x86 image. Then create an answer file and do stuff to it.
I think we need stuff in the answer file for the following passes:
-
offlineServicing – DSIM uses this to inject the drivers. We “insert the driver path” to this pass and then later on we run DSIM and pass the answer file to it. This step should inject our custom platform drivers. Since MDT doesn’t actually create physical subfolders when you tell it to “create a folder” under “Drivers” we are just going to give it the OOBD folder and see what happens. That will give it a lot of drivers.
-
specialize – this is where many of the useful custom settings are applied when the platform is rebooted after a sysprep with the /generalize switch. Essentially this is where some of the settings are put for an unattended installation.
-
generalize – this specifies settings for a sysprep which is using this switch.
-
oobeSystem – other settings for unattended installation.
Inserting the driver path is done from the menus in WISM. The other components are inserted by browsing the list of components under the image that I selected, and right clicking gives you the option to insert the component to the appropriate pass of the answer file.
Once the answer file is complete it would be copied into C:WindowsSystem32sysprep on the target platform. Sysprep.exe is there already. Then run sysprep and give it the answer file and tell it to shut down the VM. Then copy the VHD to somewhere convenient. Run DISM and pass it the answer file and it will go get the drivers and copy them into the image. Then deploy, hopefully.
After this point specifying those components is the tricky part, like which ones do you need? These are the ones I’m trying out first:
-
Microsoft-Windows-International-Core [4 specialize]: this enables us to specify our specific regional settings. That’s the stuff that Windows Setup would normally ask us for, so it makes sense to put it into an answer file.
-
InputLocale: en-US
-
SystemLocale: en-US
-
UILanguage: en-US (en-NZ is not the correct value for this field)
-
UILanguageFallback: en-US
-
UserLocale: en-NZ
-
-
Microsoft-Windows-Shell-Setup [7 oobeSystem]: various settings for first time setup. N.B. Some of these settings are only available for [7 oobeSystem] pass and some are only available for [4 specialize] pass.
-
Autologon
-
Username: Administrator (this enables the default Administrator account)
-
Enabled: True (this doesn’t get set by default and will cause an error if left blank. Needs to be True to ensure the account is enabled.)
-
LogonCount: 1 (a workaround to make sure the administrator account gets enabled)
-
-
OOBE
-
NetworkLocation: Work
-
ProtectYourPC: 1
-
HideEULAPage: True (hide the page asking the user to accept license)
-
HideWirelessSetupInOOBE: True (set this one to make sure it doesn’t pop up)
-
-
ProductKey: Your Windows 7 MAK (this setting can only be entered for the 4 specialize pass)
-
RegisteredOrganization: Name of organisation
-
RegisteredUser: Name of user
-
ShowWindowsLive: False
-
TimeZone: New Zealand Standard Time
-
UserAccounts
-
AdministratorPassword: whatever (the account must be enabled with AutologonUsername as above)
-
-
-
Microsoft-Windows-UnattendedJoin [4 specialize]: Enables an unattended domain join. This is useful even if you let the system choose a random name. At the moment we’ll leave this off and join manually after we’ve customised the computer name manually.
There are several corrections in the above which are underlined, these were found necessary to fix issues.
And that’s about it. Because the VHD already contains the OS we don’t need to bother about Windows PE pass settings. Save the answer file and then do the sysprep. I use the following command line in a command script file to automate sysprep:
-
sysprep.exe /shutdown /generalize /oobe /unattend:c:windowssystem32sysprepunattend.xml
To do this put sysprep.cmd (the command script containing this line) and unattend.xml in the sysprep folder shown in the above command, start up the virtual machine then browse to that folder in Explorer and double click sysprep.cmd. You will then see a dialog box that shows a moving progress bar as Sysprep does its thing. Eventually if you’re still watching, you will see a “Sysprep_succeeded.tag” file generated in the directory and then your VM will automatically shut down.
The next step is to run DISM to inject the drivers. DISM works offline whereas Sysprep works online. This means that my next step is to make another copy of my VHD (the post sysprepped one) and then call up DISM to inject drivers into that particular VHD instance. However right now I’m going to skip that and instead deploy the sysprepped but not yet DISMed VHD to my target platform in order to test out the unattend settings.
Before doing a sysprep stage I recommend you shut down your VM and make a backup copy of your VHD. I keep copies of the VHD both pre and post sysprep. After making the pre copy, start the VM up again before sysprepping it live. When the VM shuts itself down, make the post copy VHD for DISMing before it goes to deployment. Restore your pre copy to the VM before you do any more work with it.