Idiosyncratic Windows Deployment Server Vista Setup Options

I found getting both of the below topics to work the way I wanted in Windows Deployment Server (WDS) to be surprisingly tricky and fraught with unexpected results that took me quite a while to figure out. After all, one has to run through some large portion of the OS install before finding out that it fails. Multiple mistakes = multiple OS Installs, which drag out this learning curve rather significantly. I hope to save people some of these reboots and time lost by sharing what I learned.

Computer Naming and Domain Join (applies to Windows 2008 Server as well):

I really like eliminating the majority of repetitive trivial tasks. When managing desktops in an enterprise, something as simple as A) logon and change the computer name, B) reboot, C) join the computer to the domain, and D) reboot, which only takes 10 minutes can have a significant impact. Even on a deployment as small as 5000 computers, this can add up to a significant cost. 5000 systems * 10 minutes per system / 60 minutes per hour = ~833 man hours, just renaming the computer and joining it to the domain. SYSPREP and the mini setup do a lot to help reduce this impact, but that still means that some administrator has to revisit the computer after the OS is deployed to the box and before a user can work. This seems an incredibly inefficient use of labor to me.

As a result of this, I like to have the system join the domain during the install process. Unfortunately, this was a little more challenging in the Vista automation than one would suspect, and there are several postings on this throughout various forums. Unfortunately, the bits of the information are scattered about in a fashion that doesn't really help to put the full picture together. The key items I learned are:

• %MACHINENAME% will pick up the computer name from AD if the netbootGUID attribute is populated for the system UUID as expected (See earlier posting regards this).
• %MACHINENAME% will function as "*" if the above case is not true.
• "*" will give the computer a random name (as documented). However, even if the "Microsoft-Windows-UnattendedJoin" element of the XML is populated correctly, the computer will not be joined to the domain when the system has to generate a name.

Within the WDS/AIK space, this forces an administrator to pre-stage each and every machine. Of course, joining the domain can be managed outside of the WDS/AIK space either by manual methods or scripting (i.e. use netdom and batch files) to overcome this limitation, but I wanted to avoid using “Autologon” functionality and writing “code” in order to accomplish something that could be taken care of during the install process. I may, at some point, end up working on this in order to address the scenarios where it won’t fail above, but I have my learning curve on the “Microsoft Deployment Toolkit” to go through first to see if it provides the level of functionality I desire.

Note: At some point we seem to have updated Windows so that the computer can be renamed and joined to a domain in one shot, though it seems that many people either don't know or don't use this. It is a little tricky too; the computer name must be changed first, then the domain membership. If this is done in the reverse order, it won’t rename the computer account in AD that was created when the domain was joined.

Required Unattend.XML settings:

·         Specialize Pass

o    Microsoft-Windows-Shell-Setup\ComputerName = %MACHINENAME%

o    Microsoft-Windows-UnattendedJoin\Identification\JoinDomain = <Enter Domain Name>

o    Microsoft-Windows-UnattendedJoin\Identification\MachineObjectOU = <Enter OU>

o    Microsoft-Windows-UnattendedJoin\Identification\Credentials\Domain = <Enter Domain Name>

o    Microsoft-Windows-UnattendedJoin\Identification\Credentials\Password = <Enter Domain Name>

§  Note: This password will not be encrypted when the following setting is enabled. Hide Sensitive Data in an Answer File

o    Microsoft-Windows-UnattendedJoin\Identification\Credentials\UserName = <Enter Account Name>

Eliminating the Mid-Install Wizard ( Out-Of-the-Box-Experience) :

Also, within my continued endeavors to make installs as low touch as possible, I feel having the computer pause for human intervention somewhere in the middle of installing the OS undermines much of the other automation. Thus, a wizard that pops up mid-install to ask what language it is desired to run the computer in and to create a local account is something I would seek to eliminate.

Though the dialog the wizard presents a reasonable question (locality settings) that the average user could handle, it wouldn't bother me so much if there wasn't another delay that prevented the system from being used immediately afterwards (the computer goes through the performance tests to determine the Windows Performance Index). Having a user or administrator sit through that progress bar is also a productivity impact, again the reason I seek to eliminate that interim step. Also, since the workstation is joined to a domain, I do not want to create additional and unused accounts for no good reason in order to make the box just disappear from the user experience (though I would have settled with doing so and saw some suggestions on forums to this end).

Normally it will show the wizard if regional settings and creation of a local account are not both configured. As I stated above, I wanted to avoid creating a user account, thus as a work around, I found that setting Microsoft-Windows-Shell-Setup/OOBE/SkipMachineOOBE to “true” in the oobeSystem pass bypassed this mid-install wizard. The nice part is that this did allow me to set the settings I desired (i.e. regional settings) and bypass the others (local user account).

As a warning, the help context states that SkipMachineOOBE is deprecated and shouldn’t be used, which may cause additional issues as the install process may be changed in future versions of Windows, but it currently works for my needs. Also, heed the warning in the article, and setting SkipMachineOOBE to true may leave the machine in an unusable state, see the next step.

Required Unattend.XML settings:

· oobeSystem

o Microsoft-Windows-Shell-Setup\OOBE\SkipMachineOOBE = True

Suggested Unattend.XML settings:

· oobeSystem

o Microsoft-Windows-International-Core\InputLocale = <Enter SelectedLocale>

o Microsoft-Windows-International-Core\SystemLocale = <Enter SelectedLocale>

o Microsoft-Windows-International-Core\UILanguage = <Enter SelectedLocale>

o Microsoft-Windows-International-Core\UserLocale = <Enter SelectedLocale>

o Microsoft-Windows-Shell-Setup\OOBE\HideEULAPage = true

o Microsoft-Windows-Shell-Setup\OOBE\ProtectYourPC = 3

o Microsoft-Windows-Shell-Setup\OOBE\NetworkLocation = Work

o Microsoft-Windows-Shell-Setup\OOBE\SkipMachineOOBE = True

o Microsoft-Windows-Shell-Setup\UserAccounts\AdministratorPassword = <Enter a Password>

Administrator account warning:

By default, on Vista the administrator account is disabled. Thus, if no local account is created and the computer does not get properly joined to the domain, the machine will appear to be useless. This is not as bad as it seems, by following the guidance on Windows Vista Security : Built-in Administrator Account Disabled the computer can still be joined to the domain. In short, boot into “Safe Mode with Networking” and join the computer to the domain.

Note: I found in the documentation for the unattended install settings where it states that the administrator account can be enabled via Microsoft-Windows-Shell-Setup\AutoLogon\Username. I didn’t have any luck getting this to work on (using Vista SP1 was the only version I tried), but it doesn't matter since there is another workaround.

On Windows 2008 Server, if the domain join fails the administrator is prompted to set the Administrator account password, so this is not a concern.