Ken Brumfield's Blog

Return of the Little Shop of Drivers

2009-10-30T17:19:00Z

It's been a while since I've posted. Just over a year actually... I have this long list of half started posts, but just somehow can never seem to find the time to finish them up. However, with the exciting new release of Win7, I have managed to update my scripts to automatically add stuff to the WIMs for deployment. As such, here is the updated script deprecating IMAGEX and PEIMG for DISM. Hope this helps with some of your automation needs.

Editorial comments: I do like DISM much better as it is a little easier in the syntax, plus searches directory heirarchies for drivers. This makes it a little easier when I toss stuff into %DRIVERS_ROOT_PATH% so I don't have to waste time figuring out which directory contains the actual drivers (as you may have noticed, there is sometimes a whole bunch of other stuff in driver downloads).

@echo off
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Check Inputs
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
IF "%1"=="" (
Echo Enter the directory root for the drivers and packages to add to the image.
GOTO END
)

IF "%2"=="" (
Echo Enter WIM file name. This must be in the root of the
GOTO END
)

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::SET Variables
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
SET REFERENCENAME=%1
SET MOUNTPOINT=D:\FOO\%REFERENCENAME%
SET FILES_ROOT_PATH=D:\%REFERENCENAME%
SET IMAGEFILE=%FILES_ROOT_PATH%\%2
SET DRIVERS_ROOT_PATH=%FILES_ROOT_PATH%\Drivers
SET PACKAGES_ROOT_PATH=%FILES_ROOT_PATH%\Packages
SET LOGS_ROOT_PATH=%FILES_ROOT_PATH%\Logs
::SET WIN_AIK_INSTALL_PATH=C:\Program Files\Windows AIK\Tools
::echo %WIN_AIK_INSTALL_PATH%

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Ensure needed directories exist and are ready to be used
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
if not exist %MOUNTPOINT% (md %MOUNTPOINT%) ELSE (DISM /Unmount-Wim /MountDir:%MOUNTPOINT% /discard)
if not exist %LOGS_ROOT_PATH% (md %LOGS_ROOT_PATH%) ELSE (del /s /q %LOGS_ROOT_PATH%>NUL)

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Identify number of images in WIM and process each image
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
for /f "tokens=1,2 delims=: " %%i in ('dism /get-wiminfo /wimfile:%IMAGEFILE%') do if "%%i"=="Index" SET IMAGE_COUNT=%%j
Echo This WIM contains %IMAGE_COUNT% image(s).
For /l %%i in (1,1,%IMAGE_COUNT%) do call :update %IMAGEFILE% %%i
GOTO END

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Process per image steps
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:update
Echo Updating %1 - Image #%2
DISM /Mount-WIM /WimFile:%1 /Index:%2 /MountDir:%MOUNTPOINT%
DISM /Image:%MOUNTPOINT% /Add-Driver /Driver:%DRIVERS_ROOT_PATH% /recurse /ForceUnsigned
::for /f %%i in ('dir /ad /b %PACKAGES_ROOT_PATH%') do Call :InstallPackage %%i %2
DISM /Unmount-Wim /MountDir:%MOUNTPOINT% /Commit
goto :EOF

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Install a specified package
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:InstallPackage
Echo Installing Package %PACKAGES_ROOT_PATH%\%1
ECHO DISM /Image:%MOUNTPOINT% /Apply-Unattend:%PACKAGES_ROOT_PATH%\%1\%1.xml /Log-Path:%LOGS_ROOT_PATH%\%2-%1>NUL
IF ERRORLEVEL 1 ECho ERROR: Couldn't Install Package "%1"
GOTO :EOF

:END
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Clean up variables
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
SET IMAGE_COUNT=
SET REFERENCENAME=
SET IMAGEFILE=
SET MOUNTPOINT=
SET FILES_ROOT_PATH=
SET DRIVERS_ROOT_PATH=
SET PACKAGES_ROOT_PATH=
SET WIN_AIK_INSTALL_PATH=

Getting the most out of the redundancy native to AD when making applications "AD Aware"

2009-02-10T02:11:00Z

Many customers ask how they can best configure applications so that the applications can take full advantage of the fault tolerance built into Active Directory (AD). While there is no one right answer to this question, there are several common strategies that are frequently used. However, these strategies are not without their own shortcomings and thus deserve some discussion around the shortcomings of each of these strategies.

To set the context, in all strategies that must be employed the application developer (yes we are talking about the other guy/gal, and not the AD guy) must handle the following scenarios in some fashion or another within their code:

Server inaccessible - Whether the server isn't online at all, or it goes down at some point after the connection was established
Concurrency - Since AD is loosely convergent, it may take several seconds to several hours (depending on the replication interval) for the data to replicate from one DC to another. If there is the need to read the data immediately after it is written, or ensure consistency between multiple applications for any reason, all sensitive operations should occur on one box.

Pointing all LDAP enabled applications to a DNS Alias - i.e. "activedirectory.contoso.com"

Pros

Easy for the developers to grasp and use. Also a very low cost from the infrastructure perspective

Cons

Breaks Kerberos - To use Kerberos to authenticate against LDAP, the Service Principal Name of "LDAP/requestedserver.contoso.com" is queried. In this case, "LDAP/activedirectory.contoso.com" would be searched for and would not be found. Kerberos authentication thus fails and the application then tries NTLM. While NTLM will work, it is well known that NTLM is less secure than Kerberos and we thus should avoid unless absolutely necessary.
Enabling Kerberos by registering the ServicePrincipalNames "LDAP/activedirectory.contoso.com" and "LDAP/activedirectory" on all DCs is not the best way to fix this. The reasons not to are a Kerberos discussion, and are out of scope for this conversation.
Costly to setup and maintain from a labor perspective. Every time a DC is added to or removed from the environment, this must be updated. Also, if a DC is taken down for an extended period, this DNS record should be cleaned up.
Breaks concurrency since there is no guarantee that any two applications that require consistency of the data will communicate with the same box.
Not site aware. Depending on the administrators' configuration of the alias, the LDAP searches may traverse a WAN link.
Does not distinguish between Global Catalog and non-Global Catalog Domain Controllers.
Unpredictable selection of DCs

Using the FQDN of the domain (i.e. contoso.com):

Pros:

Easy for the developers to grasp and use. Also a very low cost from the infrastructure perspective
DNS 'A' records are automatically maintained by the Domain Controllers and are registered by the NETLOGON service

Cons:

Not site aware. All DCs register here (unless otherwise tuned) reference http://support.microsoft.com/kb/258213)
Does not distinguish between Global Catalog and non-Global Catalog Domain Controllers

Using the FQDN of the domain to locate Global Catalogs (i.e. gc._msdcs.contoso.com):

All the same concerns relating to the FQDN of the domain are relevant except that this record distinguishes a list of GCs.

Using site specific SRV records:

_ldap._tcp.SITENAME._sites.dc._msdcs.contoso.com

_ldap._tcp.SITENAME._sites.gc._msdcs.contoso.com

Pros:

Ensures a DC or GC is located near the calling application.
DNS 'SRV' records are automatically maintained by the Domain Controllers and are registered by the NETLOGON service

Cons:

Requires more code. Since this returns SRV type records, name resolution must be done separately and each record returned must be attempted individually to accommodate a system that might not be online at any point in time.
Accuracy is dependant on the efficiency of the AD site design. However, this will affect clients above and beyond the current application

Using non-site specific SRV records:

_ldap._tcp.dc._msdcs.contoso.com

_ldap._tcp.gc._msdcs.contoso.com

Pros:

DNS 'SRV' records are automatically maintained by the Domain Controllers and are registered by the NETLOGON service

Cons:

See "Using site specific SRV records"
Not site specific.

Using DsGetDomainControllerInfo:

Pros:

Provides extensive detail about the Domain Controller

Cons

Requires more code. Since this returns a list of servers, name resolution must be done separately and each record returned must be attempted individually to accommodate a system that might not be online at any point in time.
Can accommodate site awareness, since the site the DC is in is returned. However, this site awareness must be implemented in code.

Hard coding to a specific DC:

Pros:

Predictable

Cons:

Requires specific knowledge of the AD environment.
Should be a configuration option of the application. We all know how many problems we can run into if we are hard coding values inside of an application and have to change them later.
Need to figure out a strategy to keep the application on line when the server goes down.

Managing netbootGuid

2008-11-13T16:19:00Z

The attribute on AD computer objects netbootGuid is very important to allowing some deployment options (RIS and WDS) to locate the computer object the hardware belongs to. Unfortunately certain activities, such as replacing the system board or swapping in new hardware but using a pre-existing computer name, can invalidate the accuracy of the netbootGuid attribute stored in AD.

I wrote the script below (more precisely cobbled together since my VBScript is very rusty) to automatically check to make sure the netbootGuid is correct and update it if it isn't. This script can be deployed as a startup script via Group Policies to ensure every time the computer boots, the netbootGuid will be updated if needed. However, in order for this to work, the ACLs on the computer objects must be changed to allow SELF to write to the netbootGuid property.

References (from whence I cobbled):

Note: I'm not entirely fond of having to write out to a temp file to turn the GUID into a byte array. But it works. I'm open to feedback on alternate methods as to how I can rewrite the function baConvertGuidToByteArray without writing out to the temporary file. Thanks in advance.

'http://support.microsoft.com/kb/302467
'The sample uses WMI to return the UUID on the system.
'If a UUID can not be found on the system it returns all F's.
'What RIS does in this case is it uses a zero'd out version of the MAC
'address of the NIC the machine is booting off of.
'This sample will return the value required to set the
'netbootGUID attribute

Option Explicit

Call UpdateNetbootGuid(guidGetUUID, szGetDn)

Function guidGetUUID
Dim SystemSet, SystemItem, NetworkAdapterSet, NetworkAdapter

Set SystemSet = GetObject("winmgmts:").InstancesOf ("Win32_ComputerSystemProduct")
For Each SystemItem In SystemSet
  If SystemItem.UUID = "FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF" Then
   Set NetworkAdapterSet = GetObject("winmgmts:").InstancesOf ("Win32_NetworkAdapter")
    For Each NetworkAdapter In NetworkAdapterSet
    If NetworkAdapter.AdapterType = "Ethernet 802.3" And NetworkAdapter.Description <> "Packet Scheduler Miniport" Then
     guidGetUUID = "00000000-0000-0000-0000-" & Replace(NetworkAdapter.MACAddress, ":", "")
    End If
   Next
  Else
   guidGetUUID = SystemItem.UUID
  End If
Next
End Function

Function szGetDN
' Use the NameTranslate object to convert the NT name of the computer to
' the Distinguished name required for the LDAP provider. Computer names
' must end with "$". Returns comma delimited string to calling code.

Dim objTrans, objDomain, wshNetwork, strComputerName
' Constants for the NameTranslate object.
Const ADS_NAME_INITTYPE_GC = 3
Const ADS_NAME_TYPE_NT4 = 3
Const ADS_NAME_TYPE_1779 = 1

Set wshNetwork = CreateObject("WScript.Network")
strComputerName = wshNetwork.ComputerName
Set objTrans = CreateObject("NameTranslate")
Set objDomain = getObject("LDAP://rootDse")
objTrans.Init ADS_NAME_INITTYPE_GC, ""
objTrans.Set ADS_NAME_TYPE_NT4, wshNetwork.UserDomain & "\" _
& strComputerName & "$"
szGetDN = objTrans.Get(ADS_NAME_TYPE_1779)
'Set DN to upper Case
szGetDN = UCase(szGetDN)
End Function

Sub UpdateNetbootGuid(guidUUID, szComputerDn)
Dim oComputer

'Get parentcontainer
Set oComputer = GetObject("LDAP://" & szComputerDn)

If ByteArrayToGuid(oComputer.netbootGuid) <> guidUUID Then
oComputer.Put "netbootGuid", baConvertGuidToByteArray(guidUUID)
oComputer.SetInfo
End If

'Clean up
Set oComputer = Nothing
End Sub

Function ByteArrayToGuid(arrbytOctet)
If Not IsEmpty(arrbytOctet) Then
ByteArrayToGuid = _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 4, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 3, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 2, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 1, 1))), 2) & _
  "-" & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 6, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 5, 1))), 2) & _
  "-" & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 8, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 7, 1))), 2) & _
  "-" & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 9, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 10, 1))), 2) & _
  "-" & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 11, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 12, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 13, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 14, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 15, 1))), 2) & _
  Right("0" & Hex(AscB(MidB(arrbytOctet, 16, 1))), 2)
End If
End Function

Function baConvertGuidToByteArray(ByVal strHexString)
Dim fso, stream, temp, ts, n, szScrubbedString
Set fso = CreateObject ("scripting.filesystemobject")
Set stream = CreateObject ("adodb.stream")
Const TemporaryFolder = 2

temp = fso.GetSpecialFolder(TemporaryFolder) & fso.gettempname ()

Set ts = fso.createtextfile (temp)

szScrubbedString = Replace(strHexString, "-", "")

ts.write Chr("&h" & Mid(szScrubbedString, 7, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 5, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 3, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 1, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 11, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 9, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 15, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 13, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 17, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 19, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 21, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 23, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 25, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 27, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 29, 2))
ts.write Chr("&h" & Mid(szScrubbedString, 31, 2))

ts.close

stream.type = 1
stream.open
stream.loadfromfile temp

baConvertGuidToByteArray = stream.read

stream.close
fso.deletefile temp

Set stream = Nothing
Set fso = Nothing
End Function

</VBScript>

Little Shop of Drivers

2008-10-19T02:26:00Z

I take all my drivers and put them in %DRIVERS_ROOT_PATH% (see batch code below) and the install images I want to mess with in %FILES_ROOT_PATH%. One folder per driver, the script iterates through each of the folders, and runs imagex /inf for each folder. As I'm testing, this makes it much easier to start over from scratch as I was trying to get different stuff to work.

Note: I wrote this for the x64 Install.wim which only has 4 images in it, the x86 has 7, but it will work for x86 WIM if the bold/italicized number below is changed. Then all the images within the WIM will be updated.

Note: I have put some work into this since my initial posting, and determined updating, rather than reposting made the most sense. This will now also automate adding packages to the image so long as the packages are in %PACKAGES_ROOT_PATH% (Ensure the Directory name is the same as the .CAB file from the package so that it knows which CAB to install).
This has also been generalized to work with a WIM that has any number of images. This script assumes that the WIM file is in root of the folder structure that the drivers and packages are in, but that can easily be changed using the SET statements below.

IF "%2"=="" (
Echo Enter WIM file name. This must be in the root of the
GOTO END
)

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::SET Variables
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
SET REFERENCENAME=%1
SET MOUNTPOINT=D:\FOO\%REFERENCENAME%
SET FILES_ROOT_PATH=D:\%REFERENCENAME%
SET IMAGEFILE=%FILES_ROOT_PATH%\%2
SET DRIVERS_ROOT_PATH=%FILES_ROOT_PATH%\Drivers
SET PACKAGES_ROOT_PATH=%FILES_ROOT_PATH%\Packages
SET LOGS_ROOT_PATH=%FILES_ROOT_PATH%\Logs
SET WIN_AIK_INSTALL_PATH=C:\Program Files\Windows AIK\Toolsecho %WIN_AIK_INSTALL_PATH%
Goto :End

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Ensure needed directories exist and are ready to be used
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
if not exist %MOUNTPOINT% (md %MOUNTPOINT%) ELSE *"c:\Program Files\Windows AIK\Tools\x86\imagex.exe" /unmount %MOUNTPOINT%)
if not exist %LOGS_ROOT_PATH% (md %LOGS_ROOT_PATH%) ELSE (del /s /q %LOGS_ROOT_PATH%>NUL)

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Identify number of images in WIM and process each image
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
for /f "tokens=1,2 delims=:" %%i in ('imagex /info %IMAGEFILE%') do if "%%i"=="Image Count" SET IMAGE_COUNT=%%j
Echo This WIM contains%IMAGE_COUNT% image(s).
For /l %%i in (1,1,%IMAGE_COUNT%) do call :update %IMAGEFILE% %%i
GOTO END

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Process per image steps
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:update
Echo Updating %1 - Image #%2
"c:\Program Files\Windows AIK\Tools\x86\imagex.exe" /mountrw "%1" %2 %MOUNTPOINT%
for /f %%i in ('dir /ad /b %DRIVERS_ROOT_PATH%') do Call :InstallDriver %%i
for /f %%i in ('dir /ad /b %PACKAGES_ROOT_PATH%') do Call :InstallPackage %%i %2
"%WIN_AIK_INSTALL_PATH%\x86\imagex.exe" /unmount /commit %MOUNTPOINT%
goto :EOF

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Install a specified driver
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:InstallDriver
Echo Installing Drivers from %DRIVERS_ROOT_PATH%\%1
"C:\Program Files\Windows AIK\Tools\PETools\peimg.exe" /verbose /inf=%DRIVERS_ROOT_PATH%\%1\*.inf /image=%MOUNTPOINT%>NUL
IF ERRORLEVEL 1 ECho ERROR: Couldn't Install Driver "%1"
goto :EOF

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Install a specified package
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
f:InstallPackage
Echo Installing Package %PACKAGES_ROOT_PATH%\%1
"%WIN_AIK_INSTALL_PATH%\Servicing\pkgmgr" /n:"%PACKAGES_ROOT_PATH%\%1\%1.xml" /o:%MOUNTPOINT%;%MOUNTPOINT%\Windows /s:%TEMP% /l:%LOGS_ROOT_PATH%\%2-%1>NUL
IF ERRORLEVEL 1 ECho ERROR: Couldn't Install Package "%1"
:: /m:"%PACKAGES_ROOT_PATH%\%1\%1.cab"
GOTO :EOF

Idiosyncratic Windows Deployment Server Vista Setup Options

2008-10-18T21:58:00Z

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.

Trials and Tribulations of Learning the Vista Automated Installation Functionality

2008-10-18T17:17:00Z

I've pretty much come to the end of my initial learning curve on how to automate Vista installations using the AIK. There is some great documentation out there on how to execute the specific tasks necessary to add drivers and packages to the image. However, there are some gaps on how to tie it all together. It's the subtlties that really hurt my learning curve (and installing the OS over and over and over... to test the effect of each change) that don't seem to be well documented anywhere. I'm hoping to share at least the trickiest items that I encountered in order to save someone else many hours of learning. As a note, I have not tried to use what used to be called "Business Desktop Deployment" (BDD) and is now "Microsoft Deployment Toolkit" (MDT) and some of the challenges I have below may be addressed in that.

I'm doing my deployments via Windows Deployment Server (WDS), the replacement for Remote Installation Server (RIS). In RIS, I never really used the RIPREP functionality because I found the administrative burden of creating a new RIPREP image for each hardware platform and every time I needed to deploy new software excessive. Though RIPREP could push the complete OS and applications much faster than going through the install process, I just found it easier to deal with one scripted install I could add drivers for all the hardware to, and deploy applications via SMS.

First off, for anyone who has used RIS and the "unattend.txt" methods of installs in the past, there are a couple of features I really miss or have not yet figured out how to do in WDS:

What I miss most from RIS: If it did not find a computer object with the netbootGuid attribute populated with the machine's UUID, it would prompt for a computer name during the initial startup screens. This meant I did not have to pre-stage the system before the user or SA installed it, but if it ever had to be re-installed it would keep the same name and OU location in the hierarchy (very useful in DR scenarios) since RIS would populate the netbootGUID with the UUID upon creation (WDS has an approval process scenario that requires manual intervention, but doesn't have a "auto approval" mode). Additionally, since computer name is really the only unique piece of information needed for each and every system I really liked the fact that I could deliver a 4 step install process to users and administrators and leave them with a fully provisioned system:

Press F12 on boot
Log in
Enter computer name
Go do something else for several hours

In RIS, if the security on the images was managed in such that a user was only allowed to see one image, RIS automatically selected that image and installed it. Regardless as whether or not only one image is available, WDS prompts the end user to select an image.
In the "unattend.txt" install automation method, the disk configuration options were tied to the image being deployed. I really liked this feature since I could have both a server OS image and a client OS image on the deployment server and allow the server operator to create the partitions they wanted according to their needs while automating the partitioning of the client system disks. Now I think I need two WDS servers to provide the same level of functionality. I don't think this is WDS limitation, but more a limitation related to the 2 stage install process Vista uses. I still miss this functionality, regardless of where it falls.
The ability to have one OS build/WIM and multiple configuration files if the only difference, for example, is that one department doesn't want their users to have certain windows features installed by default (think the default Windows games).
The RIS UI loaded very fast, this cut down the time an administrator was sitting idle on a system rebuild, cutting operational costs.

What I really like about the new tools:

Multi-cast - large deployments = nuff said.
The administrative tools are much better.
The tools and documentation for generating the scripted installs made life a lot easier than the initial learning curve I recall going through with unattend.txt.
Driver management. Run a couple of command lines and the image is updated. There is no longer a need to have to manually update a text file (typos... grrr) and build out a folder structure for every image/driver set managed. Adding in new drivers to the boot image is much easier than in RIS and uses the same methodology as the install images, which is a very nice win. And no more drivers all using oemsetup.inf tripping over each other in the boot image and fighting with that.
Drive partitioning tools are much better. Even if the UI can't provide the functionality needed, the ability to drop to a command line and use diskpart for the fine grained configuration desired is awesome.

Identifying Stale User and Computer Accounts

2008-09-16T19:20:00Z

Using AD to determine whether or not people are still working for the company and are allowed to logon to the systems is not the ideal, and account management should happen based on knowing what accounts should and should not be use, and not by figuring out which haven’t been used. Realistically, if a fired employee is still logging on to the system we are not going to pick up the account that is stale and disable/delete it like actually needs to be done.

That said, in the real world things aren't always quite that easy. As such, regardless of whether the account is a user account or computer account we have several attributes that are stored with the account that help us determine if it is used recently. Unfortunately they all are potentially inaccurate in one fashion or another. These attributes are pwdLastSet, lastLogon, and lastLogonTimeStamp (as of Windows 2003 DFL).

Essentially you can determine if the account is stale by ensuring all of the attributes are over a designated threshold. A starting threshold for users is 3 times the maximum user password age and for computers is also 3 times the maximum computer password age. In short, if both pwdLastSet and lastLogonTimeStamp are greater than the threshold, it is pretty safe to delete the account, unless you are in academia and the faculty member may be on sabbatical.

If you don’t have both of those, it gets a little more questionable as to whether or not the account is still in use, as each attribute can incorrectly report how recently the account was used in the following fashions:

pwdLastSet

This is systemically is inaccurate if either the domain has no password policy specifying an age limit or the account has the userAccountControl attribute PASSWD_CANT_CHANGE bit set. Note, computer accounts can be configured to not change their password, but I have not observed many environments which change this setting.
This can be also misrepresent the recentness of account usage if, for example, the user or computer has not authenticated to the network in the intervening time between when the password needed to be changed and any threshold you may specify. Think user is on vacation or sabbatical (common in academic environments).
This is also inaccurate if a user has a laptop and travels for extended periods. Since the system is not on the network to communicate with the Domain Controller at boot, it can not reset the account. This can be addressed by several methods, restarting the netlogon service after VPN has been established or using nltest or netdom to reset the password in a VPN startup script.

lastLogon

The data in this attribute is not replicated, thus this is only accurate on the DC the user last logged into. Unless all DCs for the domain are queried, the data may be inaccurate.
Since AD clients are site aware, this also means that if there was only one DC in a remote location (or as happens sometimes, only one DC listed in WINS or DNS if they aren’t configured properly) and that system is decommissioned or lost due to some sort of outage it is entirely possible any indication the account ever logged in no longer exists.
This only tracks interactive logons. This essentially means that a user has to press Ctrl+Alt+Del in order for this to register.
Terminal services logons are a different type of logon in the SECURITY_LOGON_TYPE enumeration, of type RemoteInteractive and may not update lastLogon. At some point I will test this and update the blog (possibly, “best laid plans of mice and men” and all that).
This is updated only when a client logs on. If a user does not log off their machine for 90 days and the machine does not reboot, this will report the user has last logged on 90 days ago, which is exactly the truth. It does not update in order to report that the user has been accessing the system and the network for the last 90 days.
Updating only when logon occurs also affects computers if they are not rebooted. If the computers have remained up and running, the lastLogon is when they booted up. This is highly unlikely to impact client systems, but may impact servers if they are up for greater than a specified threshold.
Extremely long uptimes are much less likely if security updates are being deployed regularly.

lastLogonTimeStamp

This requires Windows 2003 domain functional level (DFL).
Prior to Windows 2003 SP1 this did not track all network logons.
http://support.microsoft.com/kb/886705
This can be up to 14 days off, though by adjusting your threshold but this shouldn’t be a problem if the number is sufficiently high.
As with pwdLastSet, this is also inaccurate if a user has a laptop and travels for extended periods. The concerns and methods to address this are the same methods as pwdLastSet.

Also, when pulling this data you could also run into null values and these cause the following concerns:

pwdLastSet – the password gets set, updating this attribute, if you use any of the native Microsoft tools to create the account or when the computer is first joined to the domain. If this is "0" (zero), some 3^rd party code probably created the account and the computer never joined. Except for a minor inconvenience to whomever pre-created the account, this account can be safely deleted unless one of the other timestamps is not null
lastLogon – this could be null for any number of reasons. The user never logged on interactively (think user who only uses web based e-mail), the user never logged on to the DC(s) queried, or the user last logged on to a DC that no longer exists.
If this is null on all DCs and lastLogonTimeStamp is not available, do not assume the account is stale unless no decommissions of DCs have occurred within the threshold.
lastLogonTimeStamp – if this is null the account has never logged on since the domain was brought to DFL 2003. This is only a concern if the DFL was raised within the threshold designated for the account to be stale.

Be careful with place holder computer accounts for non-Windows OSs prior to as they may behave differently. If you look at the operatingSystem attribute on the computer object you can determine if it needs more attention. Examples:

Microsoft Cluster Server Virtual Server computer accounts.
OS X
Unix Interop
SAMBA
NetAPP

Performance Optimization Philosophy

2008-08-14T15:20:00Z

Optimizing performance is not just about making things run faster, it is about making them run appropriately fast based on perception and cost.

Several questions may be posed at this junction:

Why does philosophy need to be discussed?
Isn't performance just about making things run faster?

There is a common misconception that performance optimization is about making things faster. In actuality, optimizing is actually about finding the correct balance between any number of tradeoffs. Often and simplistically this optimization is balancing between either cost and hardware (think upgrading processor), or cost and labor (think development/test time).

The other component is user perception. This is often the most challenging part of the equation and is often what triggers reviews of existing infrastructure due to perceived poor performance. It is not uncommon that the software is behaving normally and that the issue is not due to a hardware scalability issue, but the end user still feels that the software is not fast enough. Unfortunately, in these scenarios, there is often little that can be done in the short run without waiting for hardware to catch up with the needs of the code, optimizing the code, or waiting for fundamental architectural changes (like moving from x86 to x64) to come to pass in order be able to eliminate hardware bottlenecks. In short, the return on investment (ROI) of throwing more hardware at the code to fix user perception may not be there.

Here are some analogies to illustrate the point:
My grandmother is looking for a new car. She lives on a fixed income and, since she is getting older, doesn't travel much anymore, mostly to the grocery store or bingo, which are within 3 miles of her house. Due to her needs, the Lamborghini Murciélago is probably a little excessive though it probably performs well. I'm sure that pretty much any car that runs will be performant enough for her needs. Furthermore, making the investment in the Murciélago is probably not going to fix her perception that it takes too long to go the 3 miles to the supermarket.

Stretching the analogy a little:
Regardless of what car she gets, it is not a plane, thus it will never ever fly. But also, there is no guarantee that if she gets a plane it will be faster than a car (the land speed record is 766 mph and a Piper Cub goes about 130 MPH). Just like it is critical never to assume that moving from x86 to x64 will speed up the application. It would be more analogous to moving from a car to a tractor trailer where more stuff can be stored (increased addressable memory) so fewer trips (to disk/network) need to be made.

NTLMv2 or not NTLMv2, that is the question.

2008-08-08T23:44:00Z

Enabling NTLMv2 is a project always fraught with challenges, mostly due to the lack of visibility into exactly which authentication protocol is being used by a client machine. Management often is not gung-ho about the try it and see what breaks methodology of identifying systems that can not support NTLMv2. As such, many administrators have often asked to deploy NTLMv2 to the enterprise with minimal impact to client systems.

Up until now, sniffing network traffic was the only option available, and not a very good option. With the release of Windows Vista and 2008, this becomes dramatically easier as both event filtering is improved AND security auditing has been dramatically improved. And, since there is plenty of documentation on how to deploy NTLMv2, this will just tell you how to identify which systems are not using NTLMv2.

On a Windows Vista or 2008 machine use the command line to enable auditing for Logon Events.
"auditpol /set /subcategory:logon /success:enable /failure:enable"
Create a custom view or filter the security log using the following syntax (copy/paste the content between the quotes):
"<QueryList> <Query Id="0" Path="Security"> <Select Path="Security">*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and (EventID=4624)] and EventData[Data[@Name='LmPackageName']!='-'] and EventData[Data[@Name='LmPackageName']!='NTLM V2']]</Select> </Query> </QueryList>"

If auditing is enabled on the DCs, all the domain accounts being used anywhere in the enterprise will be caught.

Check out Eric Fitzgerald's blog for how to script wevtutil. If used with the above filter you can easily automate pulling the data you want out of the security log. Also, my thanks to Eric for the insight into the fact that we now audit the hash used during authentication
http://blogs.msdn.com/ericfitz/archive/2008/07/16/wevtutil-scripting.aspx

Here is a sample event for reference:
Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          5/28/2008 9:51:11 AM
Event ID:      4624
Task Category: Logon
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      computer.contoso.com
Description:
An account was successfully logged on.

Subject:
Security ID:  NULL SID
Account Name:  -
Account Domain:  -
Logon ID:  0x0

Logon Type: 3

New Logon:
Security ID:  ANONYMOUS LOGON
Account Name:  ANONYMOUS LOGON
Account Domain:  NT AUTHORITY
Logon ID:  0x1161d3f3
Logon GUID:  {00000000-0000-0000-0000-000000000000}

Process Information:
Process ID: 0x0
Process Name: -

Network Information:
Workstation Name: SOURCEMACHINE
Source Network Address: 192.168.X.X
Source Port: 4996

Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): NTLM V1
Key Length: 128

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{00000000-0000-0000-0000-000000000000}" />
    <EventID>4624</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12544</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2008-05-28T13:51:11.177Z" />
    <EventRecordID>63818</EventRecordID>
    <Correlation />
    <Execution ProcessID="656" ThreadID="752" />
    <Channel>Security</Channel>
    <Computer>computer.contoso.com</Computer>
    <Security />
</System>
<EventData>
    <Data Name="SubjectUserSid">S-1-0-0</Data>
    <Data Name="SubjectUserName">-</Data>
    <Data Name="SubjectDomainName">-</Data>
    <Data Name="SubjectLogonId">0x0</Data>
    <Data Name="TargetUserSid">S-1-5-7</Data>
    <Data Name="TargetUserName">ANONYMOUS LOGON</Data>
    <Data Name="TargetDomainName">NT AUTHORITY</Data>
    <Data Name="TargetLogonId">0x1161d3f3</Data>
    <Data Name="LogonType">3</Data>
    <Data Name="LogonProcessName">NtLmSsp </Data>
    <Data Name="AuthenticationPackageName">NTLM</Data>
    <Data Name="WorkstationName">SOURCEMACHINE</Data>
    <Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
    <Data Name="TransmittedServices">-</Data>
    <Data Name="LmPackageName">NTLM V1</Data>
    <Data Name="KeyLength">128</Data>
    <Data Name="ProcessId">0x0</Data>
    <Data Name="ProcessName">-</Data>
    <Data Name="IpAddress">192.168.X.X</Data>
    <Data Name="IpPort">4996</Data>
</EventData>
</Event>