Brian Desmond - Windows Server

Using Device Manager Remotely

If you have servers running the Server Core version of Windows Server, you may need to look at what devices and drivers are installed. While you can accomplish this task with various command line tools, the command line tools are difficult to use. Instead, with a bit of configuration work, you can use the familiar Device Manager GUI remotely.

To do this, you’ll need to configure a Group Policy setting for the affected servers:

Computer Configuration \ Policies \ Administrative Templates \ System \ Device Installation \ "Allow remote access to the Plug and Play interface”

Set the value to enabled:

If you don’t do this, you’ll get an error similar to the following:

---------------------------
Device Manager
---------------------------
Unable to access the computer SERVER01
Make sure that this computer is on the network, has remote administration enabled, and is running the "Plug and Play" and "Remote registry" services.
The error was: Access is denied.

---------------------------
OK
---------------------------

Once you’ve got things in place and the policy is effective, you can use Computer Management to target a remote machine and use the Device Manager snap-in:

---------------------------
Device Manager
---------------------------
Device Manager is running in read-only mode because you are running it on a remote computer. To uninstall devices or to change device properties or drivers, you must run Device Manager on the computer where you wish to make changes.
---------------------------
OK
---------------------------

You won’t be able to make changes, but, you’ll certainly be able to view all of the relevant details.

Script to Ping a List of Servers with PowerShell

I needed to quickly get the IP addresses of about 100 servers from their names. I pasted all the servers into a text file, one per line, and ran the following loop:

$servers = Get-Content .\serverList.txt
$ping = New-Object System.Net.NetworkInformation.Ping

foreach($s in $servers)
{
    $("$s,$($ping.Send($s).Address)")
}

This loop outputs a comma delimited list of ServerName,IP to the window like this:

TEST-SF6,10.12.3.96
W2003TEST,10.1.34.80
W2003TEST2,10.8.51.27

I pasted the list into a new email in Outlook, highlighted it, and then used the Convert Text to Table feature in Word (and Outlook):

Word turned my pasted CSV list into a nice table and I sent it off.

Thoughts on Building a Server Image

Repeatable, consistent, and predictable are three things that add an incredible amount of value in IT, and building servers from a base image is one way to deliver on this. I was just replying to a thread on a discussion alias where the person who started the thread had reviewed a blog post (http://www.jasonsamuel.com/2010/05/07/how-to-build-a-vmware-vsphere-vm-template-for-windows-server-2008-r2/) on how to build such an image for VMWare. I and a number of people disputed the recommendations made in the referenced blog post in addition to the various other things the individual who started the thread was planning to install in his image/template.

At a high level, the most important thing from my reply, I think, is that you should not be customizing a server for it to be convenient to your work style. The server is there for a purpose driven task. You shouldn’t even be connected to it via Remote Desktop (or sitting at the console) unless you’re troubleshooting a problem which can only be investigated from the desktop. What this means is that all the little utilities and tweaks you have on your desktop should stay on your desktop. Things like PDF readers, Internet Explorer customizations, screensavers and colors, and taskbar preferences, etc. First and foremost, many of these tweaks are profile specific so when you login with a domain account later, after running sysprep, the tweaks will be gone unless you push them into the default profile and in turn push them on to all users. Secondly, when you move on to the next big opportunity, your successor shouldn’t be expected to inherit and adapt (or spend weeks undoing) your personal preferences.

As far as system settings (e.g. page files, network settings, etc.), tweaking or disabling things just because some random guy on the Internet (including me) told you to is not a great idea. When you install an application from a vendor, be it Microsoft or any third party ISV, chances are they made assumptions in their testing that the OS is in a state relatively close to the default install. When you start disabling services (e.g. Indexing, Print Spooler, etc.) by default in an image, you provide a baseline that doesn’t meet this assumption. Rather than customizing by default, customize for specific applications. The settings in an image should be the ones required to operate at a minimum level of functionality on your network (e.g. maybe you need some custom DNS search suffixes to join the domain or settings to meet security standards). This extends to most any system level default. When you’re looking at changing a default setting, I’d first stop and ask yourself “why?”. What’s the reason this is being changed? Next, consider whether or not it should be or needs to be hardcoded in the image or if you can simply apply that configuration change via Group Policy. Anything hardcoded will require you to come back and update and re-test, and re-release the image when the value needs to be changed, whereas a Group Policy setting is easily tweaked centrally.

Inevitably there are various tools, gadgets, trinkets, etc., which make troubleshooting easier. My experience is that a great many of these tools don’t require installation and will simply run from a network share. Rather than caching tools locally on each server, or installing individual copies, put them out on a share that you can access from any machine. This way you only need to refresh one location when a tool gets updated and you also aren’t installing essentially random software on servers on an as-necessary basis. As soon as those installs aren’t consistent across all servers, you start permuting your test matrix. Personally the only thing I consistently install on a server build is Netmon or Wireshark and occasionally BgInfo (Sysinternals).

Script to Collect Hardware Inventory Data

The VBScript below will collect a number of hardware demographics from machines and output them to a CSV file. These demographics include:

Host Name
Serial Number
Make
Model
BIOS Version
Operating System
CPU
Memory (MB)
Disk Drives

You’ll need to supply an input file with one hostname or fqdn per line. You can configure the input and output files on lines 14 and 15 of the script.

'==========================================================================
' NAME: Script to Collect Serial Number, Make, Model, Color, etc.
'
' AUTHOR: Brian Desmond
' DATE  : 10/22/2006
' DATE    : 7/16/2007 - added cpu, memory, disk, and error handling
'==========================================================================

Option Explicit

Const wbemFlagReturnImmediately = &h10
Const wbemFlagForwardOnly = &h20

Const PATH_TO_INPUT = "Machines.txt"
Const PATH_TO_OUTPUT = "MachineInventory.csv"

Dim fso
Set fso = WScript.CreateObject("Scripting.FileSystemObject")

Dim shl
Set shl = WScript.CreateObject("WScript.Shell")

Dim input
Set input = fso.OpenTextFile(PATH_TO_INPUT)

Dim output
Set output = fso.CreateTextFile(PATH_TO_OUTPUT, True)

output.WriteLine "Hostname,Serial Number,Make,Model,BIOS Version,Operating System,CPU,Memory (MB),Disk Drives"

Dim wmiService
Dim wmiResults

Dim hostname
Dim make
Dim model
Dim biosversion
Dim operatingSystem
Dim serialNumber
Dim cpu
Dim memory
Dim drives

Dim line
Dim exec
Dim pingResults 
While Not input.AtEndOfStream
    line = input.ReadLine
    hostname = ""
    make = ""
    model = ""
    biosversion = ""
    operatingSystem = ""
    serialNumber = "" 
    cpu = ""
    memory = ""
    drives = ""
    
    Set exec = shl.Exec("ping -n 2 -w 1000 " & line)
    pingResults = LCase(exec.StdOut.ReadAll)
    
    If InStr(pingResults, "reply from") Then
        WScript.Echo "Reply From: " & line 
        On Error Resume Next 
        
        Set wmiService = GetObject("winmgmts:\\" & line & "\root\CIMV2")
    
        If Not Err.Number = 0 Then
            output.WriteLine line & ",Error: " & Err.Description
            WScript.Echo line & ",Error: " & Err.Description
            On Error GoTo 0
        Else
            On Error GoTo 0
            hostname = line

            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_BIOS", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
        
            Dim item
            For Each item In wmiResults
                serialNumber = Trim(item.SerialNumber)
                biosversion = Trim(item.SMBIOSBIOSVersion)        
            Next
            
            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_ComputerSystem", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
            
            For Each item In wmiResults
                make = Trim(item.Manufacturer)
                model = Trim(item.Model)
            Next
            
            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_OperatingSystem", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
            
            For Each item In wmiResults
                operatingSystem = Trim(item.Name)
                operatingSystem = Split(operatingSystem, "|")(0)
                memory = Round(Trim(item.TotalVisibleMemorySize) / 1024, 2)
            Next
    
            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_Processor", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
    
            For Each item In wmiResults
                cpu = Trim(item.Name)
            Next
            
            Set wmiResults = wmiService.ExecQuery("SELECT * FROM Win32_LogicalDisk WHERE DriveType=3", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
    
            For Each item In wmiResults
                drives = drives & Trim(item.DeviceID) & " " & Round(Trim(item.Size) / (1024^2), 2) & ";"
            Next
            
            output.WriteLine hostname & "," & serialNumber & "," & make & "," & model & "," & biosversion & "," & operatingSystem & "," & cpu & "," & memory & "," & drives
            WScript.Echo hostname & "," & serialNumber & "," & make & "," & model & "," & biosversion & "," & operatingSystem & "," & cpu & "," & memory & "," & drives
        End If
    Else
        output.WriteLine line & ",No Response"
        WScript.Echo line & ",No Response"
    End If 
Wend 

output.Close
input.Close

Set wmiService = Nothing
Set wmiresults = Nothing

Date and Time Math with PowerShell

How many times have you had to figure out what date was X days, months, or years ago, or perhaps what time was Y minutes, hours, or seconds ago? Producing a report of all the users who have not logged in during the past 90 days is a pretty common request. It’s very easy to calculate date and time math with Windows PowerShell. The .NET Framework includes two data structures that you can use for calculating all sorts of date math – DateTime and TimeSpan.

90 days before today:

[DateTime]::Now.Subtract([TimeSpan]::FromDays(90))

Thursday, August 26, 2010 5:53:39 PM

90 days after today:

[DateTime]::Now.Add([TimeSpan]::FromDays(90))

Tuesday, February 22, 2011 6:03:16 PM

2 years before today:

[DateTime]::Now.Subtract([TimeSpan]::FromDays(2 * 365))

Monday, November 24, 2008 6:06:59 PM

2 years after today:

[DateTime]::Now.Add([TimeSpan]::FromDays(2 * 365))

Friday, November 23, 2012 6:06:51 PM

Note: We’re not taking leap years in to account in the above two examples.

37 minutes ago:

[DateTime]::Now.Subtract([TimeSpan]::FromMinutes(37))

Wednesday, November 24, 2010 5:32:18 PM

37 minutes from now:

[DateTime]::Now.Add([TimeSpan]::FromMinutes(37))

Wednesday, November 24, 2010 6:47:41 PM

Finally, if you’re looking to construct an LDAP filter based on a timestamp attribute (e.g. pwdLastSet, lastLogonTimeStamp, etc.), you can either use adfind (which will do the encoding for you) or you can convert the time you want to filter on to a standard Windows File Time:

[DateTime]::Now.ToFileTime()

129351176175846050

You can use the ToFileTime() method on any of the above expressions, so, if for example you wanted 90 days ago in this format you could do this:

[DateTime]::Now.Subtract([TimeSpan]::FromDays(90)).ToFileTime()

Installing WinPcap Silently

A standard part of my server build I do everywhere is installing WireShark. WireShark of course requires WinPcap. While you can install WireShark silently, it conveniently doesn’t install WinPcap, rendering it useless. I used to work around this by installing NMap as part of the build since NMap does include WinPcap in its’ silent install. Unfortunately this seems to have broken under Windows Server 2008 R2.

The good news is you can work around this with the hackish but effective AutoIt. Below is my AutoIt script for installing WinPcap 4.1.1.

; ==========================================================================
; NAME: WinPcap AutoIt Installer
; 
; AUTHOR: Brian Desmond, brian@briandesmond.com
; DATE  : 11/28/2009
; ==========================================================================
#RequireAdmin

Run("WinPcap_4_1_1.exe")
WinWaitActive("WinPcap 4.1.1 Setup")
Send("!n")
WinWaitActive("WinPcap 4.1.1 Setup", "Welcome to the WinPcap")
Send("!n")
WinWaitActive("WinPcap 4.1.1 Setup", "License Agreement")
Send("!a")
WinWaitActive("WinPcap 4.1.1 Setup", "Installation options")
ControlClick("WinPcap 4.1.1 Setup", "Installation options", "[CLASS:Button; INSTANCE:2]") ; hack to click the install button
WinWaitActive("WinPcap 4.1.1 Setup", "Completing the WinPcap")
Send("!f")

Note: This depends on the version number strings in the WinPcap setup. If it changes, you’ll need to tweak the script above accordingly.

I just compiled this to an EXE using the AutoIt compiler and it worked just fine.

Remotely Configuring DRAC Cards

The two scripts below are a quick solution to pushing out an identical (except for IP and hostname) configuration to a large number of Dell DRAC boards. They’re not the most efficient and they were written for a specific scenario, but, they should be easy enough to customize. There are two scripts:

RemoteDracConfig.vbs – This one will take a config template, customize it for a host, and apply it via psexec
RemoteDracConfigLoop.vbs – This one will read an input CSV and call RemoteDracConfig.vbs for each line

I seperated the scripts specifically so that the first one could easily be used as part of a build process without having to generate an input file for it. To get started, you’ll need to configure a reference DRAC and export its configuration. Once you’ve done the configuration work, run racadm getconfig –f baseline.txt on the reference machine. You’ll next need to replace the machine specific info with tokens. I support two:

%drac-ip% – this one will get replaced with the IP to use for the DRAC
%drac-hostname% – this one will get replaced with the hostname to use for the DRAC

Note: This script assumes that the drac-hostname will actually be the server’s hostname with something appended on the end. For example all my DRACs I’m using server-drac.domain.com as the FQDN, so, the relevant lines in my DRAC config look like this:

cfgDNSRacName=%drac-hostname%-drac
cfgDNSDomainName=domain.com

If you want to do something different, you’ll need to modify the script.

The baseline config also will not have any passwords in it. You’ll need to scroll down to the cfgUserAdmin section and uncomment the # cfgUserAdminPassword=******** (Write-Only) line and replace it with cfgUserAdminPassword=YourPassword. You’ll also need a copy of psexec from Sysinternals. The path to that is hardcoded at the top of RemoteDracConfig.vbs. You’ll need to change this.

Here is RemoteDracConfig.vbs:

'==========================================================================
' NAME: Remote Drac Config
'
' AUTHOR: Brian Desmond, brian@briandesmond.com
' DATE  : 11/25/2009
'
' COMMENT: 
'    cscript RemoteDracConfig.vbs <targetServer> <targetDracIp>
'==========================================================================

Option Explicit

Const BASE_CONFIG = "baseline.txt"
Const PSEXEC_PATH = "z:\tools\sysinternals\psexec.exe"

Dim shl
Set shl = WScript.CreateObject("WScript.Shell")

Dim fso
Set fso = WScript.CreateObject("Scripting.FileSystemObject")

Dim targetServerName
targetServerName = WScript.Arguments(0)

Dim targetDracIp
targetDracIp = WScript.Arguments(1)

Dim baseConfig
Set baseConfig = fso.OpenTextFile(BASE_CONFIG)

Dim baseConfigStr
baseConfigStr = baseConfig.ReadAll

baseConfig.Close()

baseConfigStr = Replace(baseConfigStr, "%drac-hostname%", targetServerName)
baseConfigStr = Replace(baseConfigStr, "%drac-ip%", targetDracIp)

If fso.FolderExists("\\" & targetServerName & "\c$\temp") = False Then 
    fso.CreateFolder "\\" & targetServerName & "\c$\temp"
End If 

Dim configOutput
Set configOutput = fso.CreateTextFile("\\" & targetServerName & "\c$\temp\dracConfig.txt", True)

configOutput.write baseConfigStr
configOutput.Close

shl.Run PSEXEC_PATH & " \\"& targetServerName & " racadm config -f c:\temp\dracconfig.txt -p", 1, True 
shl.Run PSEXEC_PATH & " \\"& targetServerName & " racadm racreset", 1, True 

fso.DeleteFile "\\" & targetServerName & "\c$\temp\dracConfig.txt", True

Here is RemoteDracConfigLoop.vbs:

'==========================================================================
' NAME: Drac Config Loop
'
' AUTHOR: Brian Desmond, brian@briandesmond.com
' DATE  : 11/25/2009
'
' COMMENT: 
'
'==========================================================================

' Input File Format
'    DracIp,ServerNbtName
' Example:
'    10.10.10.102,srv1
'    10.10.10.104,srv2

Option Explicit

Const INPUT_FILE = "input.txt"

Dim shl
Set shl = WScript.CreateObject("WScript.Shell")

Dim fso
Set fso = WScript.CreateObject("Scripting.FileSystemObject")

Dim inputFile
Set inputFile = fso.OpenTextFile(INPUT_FILE)

Dim line
Dim tokens
While Not inputFile.AtEndOfStream
    line = inputFile.ReadLine
    tokens = Split(line, ",")
    WScript.Echo tokens(1)
    
    shl.Run "cscript RemoteDracConfig.vbs " & tokens(1) & " " & tokens(0), 1, True 
Wend 

inputFile.Close()

I tested this against several Windows Server 2008 x64 and Windows Server 2008 R2 machines equipped with DRAC5 boards and it worked well. YMMV of course. The racadm tool ships with the Dell OpenManage Server Administrator components so you’ll need those installed on each machine in order for this to work.

How to Sysprep in Windows Server 2008 R2 and Windows 7

Note: This post discusses Sysprep as it pertains to Windows 7 and Windows Server 2008 R2. If you’re working with a different version of Windows, check out these posts:

About eighteen months ago, I blogged about how to run Sysprep for Windows Server 2008 and this has turned out to be the most popular article on this site by a long shot, so I figured I'd update it for Windows Server 2008 R2 (and Windows 7). If you never had the need to look at Sysprep in Windows Vista/2008, you'll find that it's nothing like what you're used to on Windows Server 2003, XP, etc.

The first step is acquiring the Windows Automated Installation Kit (WAIK) and installing it on a machine. It will run fine on a Windows Vista or Windows Server 2008 machine. You can get it from Microsoft's website at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=696dd665-9f76-4177-a811-39c26d3b3b34.

The tool of choice is the Windows System Image Manager (WSIM). When you start it you'll get a blank screen like this:

The first step is to open the image file for the Windows SKU you want to build a sysprep file for by going to File>Select Windows Image:

Note: You may need to first create a catalog file before completing the preceding step. In order to do this, you'll first need to copy the install.wim from your installation media DVD sources folder to the hard drive as the tool won't work with it if it doesn't have write access to the WIM file. You can then go to Tools>Create Catalog and create the catalog file.

All of the settings you will want to setup in your unattend.xml file are in the tree under Windows Image. The documentation for all the settings can be found in the Unattended Windows Setup Reference CHM file which ships with the WAIK. This link http://technet.microsoft.com/en-us/library/cc749272(WS.10).aspx shows a mapping table between the sysprep.inf file and the new unattend.xml format. This link is for Windows Vista but it still applies.

All of the various settings can be applied during different passes of the setup process which sysprep will trigger. You can read about these passes here. I built a simple unattend file just for sysprep'ing my base image which includes settings in the generalize, specialize, and oobeSystem passes. All of the settings I chose are outlined below.

My answer file tree:

Disabling the initial configuration dialog:

Disabling Server Manager from loading at first run:

Setting the Internet Explorer homepage to "about:blank", turning off the IE8 Accelerators, and disabling the first run wizard:

Setting Google as my default Search Provider in Internet Explorer:

Note: To do this, you should right click on SearchScopes and Insert New Scope.

There are two versions of Internet Explorer on a 64-bit machine – the 64-bit IE and the 32-bit one. You'll need to set the settings for them independently. Duplicate the above IE configuration in the wow64_Microsoft-Windows-IE-InternetExplorer_neutral component:

Setting my product key, timezone settings, and my name:

Configuring localization settings – if you want something other than US English, look under Input Locales in the index of the Unattended Windows Setup Reference CHM file referenced earlier:

Configuring the screen resolution and color depth - 1280x960 is what works for me in VMWare full screen mode with the tabs across the top:

Configuring setup not to show me the EULA again:

Configuring setup to install a default local administrator account password:

One of the things that's unlike Sysprep from Windows 2000 – Windows Server 2003 is that the unattend.xml file isn't deleted at the conclusion of the Sysprep process. The down level Sysprep deletes the c:\sysprep folder when it finishes. In order to replicate this functionality, you can put a command in to delete the unattend.xml file in the SetupComplete.cmd batch file (which must be located in c:\windows\setup\scripts\) which gets called at the end of Sysprep.

I put a simple one line command in my SetupComplete.cmd file:

del /Q /F c:\windows\system32\sysprep\unattend.xml

In order to run Sysprep you'll need a new command. The old Sysprep UI that was there in Windows 2000 - 2003 doesn't really exist anymore. All of the Sysprep command line switches are documented at http://technet.microsoft.com/en-us/library/dd744330(WS.10).aspx.

sysprep /generalize /oobe /shutdown /unattend:unattend.xml

Missing Windows Time Service

I ran into a domain controller at a customer today which was completely missing the Windows Time (w32time) service. You can run w32tm /register to recreate the service with default parameters.

Troubleshooting a Spooler Crash

I ran into an interesting issue this evening where the Spooler service on a customer's print server was crashing constantly immediately after logging an event about unpublishing a specific printer. Since this was a Windows 2000 machine, troubleshooting this was a bit more involved than usual on 2003.

In general, you troubleshoot these issues by collecting a dump at the time of the process crash with adplus. Adplus is a VBScript available in the Debugging Tools for Windows package. To start, you'll need the PID of the Spooler process – you can get this from Task Manager. Look for spoolsv.exe, if the PID is missing, go to View>Select Columns to get it. The syntax to attach adplus to the process and wait for it to crash goes like this: cscript adplus.vbs –quiet –crash –p pid.

If you're running under Windows 2000 (or NT4), there is an extra step if you're also connecting to the problem server via Remote Desktop. The extra step here involves another tool in the Debugging Tools for Windows package called remote.exe. The steps are:

Create a batch file on the problem server, let's call it remotecmd.cmd, and save it in c:\debuggers. In the batch file, put this line in c:\debuggers\remote.exe /s "cmd.exe" remoteshell.

Note: You should replace C:\debuggers with the path you installed the debugging tools to. I always use c:\debuggers, but if you use the default path or another, remember to quote paths with spaces as necessary.

Use AT to schedule the batch file to run in one minute. If the current server time is 23:15, run this command AT 23:16 c:\debuggers\remotecmd.cmd.
Wait for remote.exe to spawn the command prompt (you'll see remote.exe running in task manager).
Connect from another machine to the remote. Run remote.exe /c ProblemServer remoteshell. Replace ProblemServer with the name of the machine having the issues and running the remote session.
From the remote shell, launch adplus - cscript adplus.vbs –quiet –crash –p pid.

ADPlus will create a folder inside c:\debuggers (or wherever you launch it from). The folder will be named Crash_Mode__Date…. Inside of here there will be a number of files including a couple of dumps. There will be mini-dumps and full ones, grab the full dump, probably named similar to PID-7996__SPOOLSV.EXE__2nd_chance_AccessViolation__full_1710_2009-01-04_21-30-10-290_1f3c.

Open the dump using WinDbg (Ctrl+D), and if you don't have symbols configured, issue these two commands:

.symfix c:\symbols
.reload

Chances are the !analyze –v debugger will be able to pinpoint the correct thread and display the stack where the crash occurred. In my case this was the stack:

ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0182f430 01db23e8 000db6d8 000dad90 000d2b1c zsdzplui!BlankSheetProc+0x71e
0182f49c 7780564d 00000000 0182f4d0 00000000 zsdzplui!BlankSheetProc+0x766
0182f4b4 77805797 00000000 0182f4d0 00000000 winspool!DocumentPropertySheets+0x126
0182f4f4 7614fc1c 00000000 000d2b1c 016261b8 winspool!DocumentPropertiesW+0xdc
0182f524 7614cfd2 016261b8 10000000 016260a0 localspl!ThisIsAColorPrinter+0x32
0182ff30 7614ed5d 01648778 016260a0 016260a0 localspl!UpdateDsDriverKey+0x2bb
0182ff58 7614144c 0182ffac 01648778 7c57b400 localspl!DsUpdatePrinter+0x142
0182ff6c 7614edd0 00cd2130 0182ffac 7614ebfd localspl!RunForEachPrinter+0x2c
0182ff7c 761413fa 0182ffac 00cd2130 7c57b400 localspl!DsUpdateSpooler+0x19
0182ff90 7614eec0 0182ffac 7614edb7 00070000 localspl!RunForEachSpooler+0x21
0182ffb4 7c57b3bc 0162b360 00070000 00070748 localspl!DsUpdate+0xec
0182ffec 00000000 7614edd6 0162b360 00000000 KERNEL32!BaseThreadStart+0x52

The important piece of information here is the module at the top of the stack (zsdzplui) which is a third party print driver. You can use the lmvm command to get more information:

0:012> lmvm zsdzplui
start    end        module name
01db0000 01dbe000   zsdzplui   (export symbols)       zsdzplui.dll
    Loaded symbol image file: zsdzplui.dll
    Image path: C:\WINNT\system32\spool\drivers\w32x86\2\zsdzplui.dll
    Image name: zsdzplui.dll
    Timestamp:        Fri Dec 30 05:05:36 2005 (43B51480)
    CheckSum:         0001B3AB
    ImageSize:        0000E000
    File version:     1.0.0.40
    Product version: 1.0.0.40
    File flags:       2 (Mask 3F) Pre-release
    File OS:          10001 DOS Win16
    File type:        3.2 Driver
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Number Five Software
    ProductName:      ZUD Printer Driver
    InternalName:     ZUDUI
    OriginalFilename: zsdui.dll
    ProductVersion:   1, 0, 0, 40
    FileVersion:      1, 0, 0, 40
    PrivateBuild:     1, 0, 0, 40
    SpecialBuild:     1, 0, 0, 40
    FileDescription: ZUD Printer Driver UI
    LegalCopyright:   Copyright © Number Five Software 2001-2005
    LegalTrademarks: Copyright © Number Five Software 2001-2005
    Comments:         Copyright © Number Five Software 2001-2005

The first thing to notice here is that this driver is three years old – that's really old. Now unfortunately there's no real easy way for most folks to figure out which printer driver this file corresponds to, especially on a busy print server. It's at least somewhat simpler if you know what make of printer to start looking under – in this case that's not obvious either. The good news is that I happen to know that with this particular driver you should be looking under Zebra, so if this is your exact problem, part of the work is done. If it's a different vendor, a couple tricks for doing this at home:

Go in the Printers Control Panel, right click and select Server Properties. Go to the Drivers tab and start pulling the Properties of the installed drivers – the files the driver uses will be listed.
Open up Regedit and browse to HKLM\System\CurrentControlSet\Control\Print\Environments. Search on the DLL in question – it will be listed under here somewhere and you can get the name of the driver from the parent key.

Once you've identified the driver in question (in our case it happens to be a Zebra 170XiIII), obtain an update from the manufacturer and see if that helps.

In the case of the problem I had, the spooler service was crashing constantly and thus nobody would be able to print. Based on the stack it was obvious that something was going wrong when the Spooler was trying to publish this printer in Active Directory. What's happening is that quite a bit of printer information is published in AD and in order to collect some of that data, Windows has to ask the print driver to provide it.

The obvious solution was of course to go in the Printers Control Panel, and access the properties of each printer using the problem driver, and uncheck List in the Directory. The problem is that Explorer came back with an error and refused t load the printer properties.

So what to do in this situation? There's a tool called setprinter.exe in the Windows 2003 Resource Kit Tools download. This particular tool lets you mess with the properties of printers in an unintuitive but direct way. I ran the command below on each printer using the problem driver to just disable the publishing all together for those printers. This band-aid'ed the problem such that the spooler could continue the publishing sequence for each printer on the server and stay up.

C:\Program Files\Windows Resource Kits\Tools>setprinter \\ProblemServer\BustedPrinter 7 "dwAction=unpublish"
Set printer on '\\ProblemServer\BustedPrinter' succeeded (DS operation pending).

Script to Inventory Print Servers

The script goes out to AD and collects all of the printQueue objects in the domain (these represent published printers). From this list the script compiles a list of print servers and dumps all the printer info off each server. The downside to this is that if you have printer servers with no published printers, they'll be missed. This is the data currently collected and outputted to a pipe separated text file:

Server
Name
ShareName
Comment
Error
DriverName
EnableBIDI
JobCount
Location
PortName
Published
Queued
Shared
Status

You can easily add more data to this by adding more fields inside the loop. I tested this with some really slow links and Wn2k/Win2k3 servers and it seems to work fine.

In order to use the script, you'll need to provide the FQDN of your domain in the DOMAIN_TO_SEARCH field at the top of the script. Additionally you'll need to optionally modify the FILE_PATH field to change the output destination.

Feel free to leave any suggestions, issues, etc in the comments area below.

'==========================================================================
' NAME: Query AD Printers
'
' AUTHOR: Brian Desmond, brian@briandesmond.com
'==========================================================================

Option Explicit 

Const DOMAIN_TO_SEARCH = "dc=sub,dc=domain,dc=com"
Const FILE_PATH = "PrinterInventory.txt"

Dim fso
Set fso = WScript.CreateObject("Scripting.FileSystemObject")

Dim PrinterArray
Set PrinterArray = WScript.CreateObject("Scripting.Dictionary") ' this way we eliminate dupes

' populate our list of printers
Dim cnxn
Set cnxn = WScript.CreateObject("ADODB.Connection")
cnxn.Provider = "ADsDSOObject"
cnxn.Open "Active Directory Provider"

Dim cmd
Set cmd = WScript.CreateObject("ADODB.Command")
cmd.ActiveConnection = cnxn

cmd.CommandText = "<LDAP://" & DOMAIN_TO_SEARCH & ">;(&(objectcategory=printQueue)(objectClass=printQueue));serverName;subtree"
cmd.Properties("Page Size") = 100
cmd.Properties("Timeout") = 30
cmd.Properties("Cache Results") = False

Dim rs
Set rs = cmd.Execute

While Not rs.eof 
	If Not PrinterArray.Exists(rs.Fields("serverName").Value) Then
		PrinterArray.Add rs.Fields("serverName").Value, rs.Fields("serverName").Value
	End If 
			
	rs.MoveNext
Wend 

rs.close
cnxn.Close

Dim outputData
Set outputData = fso.CreateTextFile(FILE_PATH, True)
outputData.WriteLine "Server|Name|ShareName|Comment|Error|DriverName|EnableBIDI|JobCount|Location|PortName|Published|Queued|Shared|Status"

Dim wmiSvc
Dim wmiItems
Dim line
Dim serverVersion
Dim serverName

Dim i
For Each i In PrinterArray.Keys
	If Not Trim(PrinterArray.Item(i)) = "" Then 
		serverName = PrinterArray.Item(i)
		WScript.Echo "Trying: " & serverName
		On Error Resume Next 
		serverVersion = CDbl(Left(GetWindowsVersion(serverName), Len(GetWindowsVersion(serverName)) - 5))
		
		Set wmiSvc = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & serverName & "\root\cimv2")
		Set wmiItems = wmiSvc.ExecQuery("SELECT * FROM Win32_Printer",, 48)
		
		If Err.Number <> 0 Then 
			WScript.Echo "Error: " & serverName
			On Error GoTo 0 
		Else 		
			On Error GoTo 0 
			Dim printer
			For Each printer In wmiItems
				line = ""
				
				line = serverName & "|" 
				line = line & printer.Name & "|"
				line = line & printer.ShareName & "|"
				If serverVersion > 5.0 Then ' Comment supported on XP & newer
					If InStr(printer.Comment, VbCrLf) > 0 Then  'scrub bad text
						line = line & replace(printer.Comment, VbCrLf, " ") & "|"
					Else
						line = line & printer.comment & "|"
					End If 
				Else
					line = line & "|"
				End If 
				line = line & GetErrorStateString(printer.DetectedErrorState) & "|"
				line = line & printer.DriverName & "|"
				If serverVersion > 5.0 Then ' Comment & enablebidi supported on XP & newer			
					line = line & printer.EnableBIDI & "|"
				Else
					line = line & "|"
				End If 
				line = line & printer.JobCountSinceLastReset & "|"
				If InStr(printer.location, VbCrLf) > 0 Then 'scrub bad text
					line = line & Replace(printer.Location, VbCrLf, "") & "|"
				Else
					line = line & printer.Location & "|"
				End If 
				line = line & printer.PortName & "|"
				If serverVersion > 5.0 Then ' published, queued, shared supported on XP & newer
					line = line & printer.Published & "|"
					line = line & printer.Queued & "|"
					line = line & printer.Shared & "|"
				Else
					line = line & "|||"
				End If 							
				line = line & printer.Status
				
				outputData.WriteLine line
			Next
		End If 
	End If 
Next

outputData.Close

Set outputData = Nothing
Set fso = Nothing 
Set wmiItems = Nothing
Set wmiSvc = Nothing 

' translates Win32_Printer.DetectedErrorState
Function GetErrorStateString(errorState)
		Select Case errorState
			Case 0
				GetErrorStateString = "Unknown"
			Case 1
				GetErrorStateString = "Other"
			Case 2
				GetErrorStateString = "No Error"
			Case 3
				GetErrorStateString = "Low Paper"
			Case 4
				GetErrorStateString = "No Paper"
			Case 5
				GetErrorStateString = "Low Toner"
			Case 6
				GetErrorStateString = "No Toner"
			Case 7
				GetErrorStateString = "Door Open"
			Case 8
				GetErrorStateString = "Jammed"
			Case 9
				GetErrorStateString = "Offline"
			Case 10
				GetErrorStateString = "Service Requested"
			Case 11
				GetErrorStateString = "Output Bin Full"
			Case Else
				GetErrorStateString = errorState		
		End Select 
End Function 

' this function returns the windows version
Function GetWindowsVersion(server)
	Dim sbWmiSvc
	Set sbWmiSvc = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & server & "\root\cimv2")

	Dim version
	
	Dim osInstances
	Set osInstances = sbWmiSvc.ExecQuery("SELECT * From Win32_OperatingSystem")
	
	Dim os
	For Each os In osInstances
		version = os.Version
	Next
	
	GetWindowsVersion = version
	
	Set sbWmiSvc = Nothing
	Set osInstances = Nothing
	Set os = Nothing 
End Function

Forcing a Blue Screen via iLO – iLO2 Version

Sometimes one of the most useful resources at your disposal when troubleshooting a hang or other issues is the memory dump file Windows will write out during a blue screen. If a system is hung and you are not able to get to it locally, pressing Ctrl+ScrollLock, ScrollLock isn't going to be a feasible solution. If the server is an HP server with an iLO card (Integrated Lights Out), and you've set a registry key in Windows ahead of time, you can force the system to blue screen, write the memory dump, and restart.

The key to doing this is generating what's called a nonmaskable interrupt or NMI. The long and short of it is that NMIs are hardware interrupts which have to be serviced immediately. Windows has a concept of IRQ levels, or IRQLs. The highest IRQL is always serviced, preempting any lower level interrupts which are currently being serviced. The preemptive behavior here is called masking the interrupt. So, an NMI is an interrupt which must be serviced immediately. Generally you get an NMI when there's a major hardware fault that prevents the operating system from continuing. This is exactly what happens if we trigger one manually in the iLO.

This post covers working with an iLO2. If you're using an iLO1, visit http://briandesmond.com/blog/forcing-a-blue-screen-via-ilo/.

The first step to getting this functionality working is setting a registry key outlined in KB 927069. Don't mind the part about this only applying to Windows 2000 Server. This works on 2000 and newer. Here's the registry info:

Path: HKLM\System\CurrentControlSet\Control\CrashControl
Value: NMICrashDump
Data: 1
Type: REG_DWORD

You'll need to reboot for the change to take effect. If you don't reboot after making this change, you'll see the effect illustrated here.

Note: If you have the Automated System Recovery (ASR) functionality enabled on the server and you need to get a full memory dump, you will need to turn it off as it can interfere with this process. This is a BIOS setting which I don't have the steps to change readily available. If there's demand (leave a comment), I can track them down.

To crash the box, these are the steps. I shot these screens on a DL365 G5 which is recent hardware with an iLO version 2. If you are using an older server with an iLO version 1, visit this link.

1. Login to the ILO and then proceed to the "Diagnostics" link on the left hand navigation:

2. Click the "Generate NMI to System" button:

Warning: I can't guarantee that this button generates a warning when you click it on all versions of the iLO firmware. Generating an NMI will HALT your system. Don't click this button just to see what happens!

3. You will get a warning dialog to make sure you're really certain this is what you want to happen. Remember, doing this will HALT your system!

4. The iLO will write a status message to the status bar in IE:

5. At this point Windows will crash with a 0x80 bugcheck and reboot (assuming your machine is configured to automatically reboot after a blue screen). You can hopefully use the memory dump to assist in troubleshooting the problem at hand.

Note: If you don't get a traditional blue screen and instead get the nontraditional blue screen pictured here, you've made an error entering the registry setting described earlier or you did not reboot.

After rebooting, my test server stopped at a Press F1 prompt to tell me there was a critical error prior to this power-up. I assume there is a BIOS setting somewhere to disable this although I don't know where it is offhand:

Note: This capability is present in the Dell DRAC3 cards. I spoke with Dell and they advised me that this functionality is not available in newer generation DRAC cards.

NMI Blue Screen

Ever had a blue screen pop up with a message like this?

*** Hardware Malfunction

Call your hardware vendor for support

*** The system has halted ***

Windows makes this screen look something like this:

There are a couple of other specific errors that can sometimes pop up in these messages:

NMI: Parity Check / Memory Parity Error
NMI: Channel Check / IOCHK

Note: There are some other assorted specific errors you can get on this screen outside of the two above, however they're only possible if you're on a machine with an EISA bus.

As the message indicates, you've got a hardware problem of some sort. These screens are generated when your system encounters a Non Maskable Interrupt (NMI). The long and short of it is that NMIs are hardware interrupts which have to be serviced immediately. Windows has a concept of IRQ levels, or IRQLs. The highest IRQL is always serviced, preempting any lower level interrupts which are currently being serviced. The preemptive behavior here is called masking the interrupt. So, an NMI is an interrupt which must be serviced immediately. Generally you get an NMI when there's a major hardware fault that prevents the operating system from continuing.

Some systems allow you to trigger an NMI either via a physical switch on the machine, or via something like an iLO.

Read/Write ILO Details from the Command Line

If you have access to an HP server running Windows but you don't have access to ILO information (such as IP info), you can export it all to an XML file using a tool HP includes in the Proliant Support Pack. The tool is called hponcfg.exe and it's located under C:\Program Files\HP\hponcfg on x86 and x64 systems.

In order to use hponcfg, you'll need to have the ILO driver installed on the system. If you go in Device Manager, you'll see an entry under Multifunction Adapters like this:

If the driver isn't loaded, you'll get an error when you try to run the tool:

HPONCFG RILOE-II/iLO setup and configuration utility
Version 1.4 (c) Hewlett-Packard Company, 2005

ERROR: CPQSMIF.DLL and SM2USER.DLL not found.
ACTION REQUIRED: Please install the latest Proliant support pack.

So, to write out the config to an XML file, you'd do something like this:

hponcfg /w ILOConfig.xml

You'll get a file something like this:


 



<DIR_INFO MODE="write">
<MOD_DIR_CONFIG>
<DIR_AUTHENTICATION_ENABLED VALUE = "N"/>
<DIR_LOCAL_USER_ACCT VALUE = "Y"/>
<DIR_SERVER_ADDRESS VALUE = ""/>
<DIR_SERVER_PORT VALUE = "636"/>
<DIR_OBJECT_DN VALUE = ""/>
<DIR_OBJECT_PASSWORD VALUE = ""/>
<DIR_USER_CONTEXT_1 VALUE = ""/>
<DIR_USER_CONTEXT_2 VALUE = ""/>
<DIR_USER_CONTEXT_3 VALUE = ""/>

 

<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "10"/>
<FULL_DUPLEX VALUE = "N"/>
<DHCP_ENABLE VALUE = "N"/>
<DHCP_GATEWAY VALUE = "Y"/>
<DHCP_DNS_SERVER VALUE = "Y"/>
<DHCP_STATIC_ROUTE VALUE = "Y"/>
<DHCP_WINS_SERVER VALUE = "Y"/>
<REG_WINS_SERVER VALUE = "Y"/>
<IP_ADDRESS VALUE = "192.168.100.100"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "192.168.100.1"/>
<DNS_NAME VALUE = "ILOSGH123ABC4"/>
<DOMAIN_NAME VALUE = "briandesmond.net"/>
<PRIM_DNS_SERVER value = "192.168.100.10"/>
<SEC_DNS_SERVER value = "192.168.100.11"/>
<TER_DNS_SERVER value = "0.0.0.0"/>
<PRIM_WINS_SERVER value = "192.168.100.12"/>
<SEC_WINS_SERVER value = "192.168.100.13"/>
<STATIC_ROUTE_1 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_2 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_3 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>

 

<USER_INFO MODE="write">
<ADD_USER
USER_NAME = "admin"
USER_LOGIN = "admin"
PASSWORD = "%user_password%">
<ADMIN_PRIV value = "Y"/>
<REMOTE_CONS_PRIV value = "Y"/>
<RESET_SERVER_PRIV value = "Y"/>
<VIRTUAL_MEDIA_PRIV value = "Y"/>
<CONFIG_ILO_PRIV value = "Y"/>

There's a few interesting things you can glean from this:

The login at the top of the file is bogus, and as long as you're logged in locally as an administrator, you don't need to specify ILO credentials to use the tool
Under network settings, because SPEED_AUTOSELECT is "Y" (think auto/auto on the NIC), you can ignore the next two entries for NIC_SPEED and FULL_DUPLEX
Towards the bottom under users, it doesn't write out passwords, but it does write out usernames, so, we can see that this ILO has one user with username "admin"

You can use the XML file dumped here as a template that you can customize and import into other ILOs with the same hponcfg tool. To do this, you would run something like this:

hponcfg /f IloConfig.xml

This would import the contents of iloconfig.xml to the local ILO. As noted earlier as long as you're a local admin on the box, you can leave the bogus credentials at the top of the file. The tool is very finicky about the XML so if any of it is invalid, you'll get a confusing error pointing to the XML though rarely in the correct location. In general I'd recommend your remove any sections you're not configuring from your input file as the defaults will be retained.

Managing ILO Users & Passwords from the Command Line

To follow up on the previous post I made about ILO scripting, this one runs through how you can change the password or add a user without having the login details to the ILO. I do thi al the time when I get new servers built in the field and while the local folks load the OS, they don't always remember to provide the username/password off the tag hanging off the server or they typo it, etc. This example also assumes that you have administrator level access to the actual server. You'll need hponcfg and the ILO driver loaded as discussed previously as well.

When you dump the ILO config, you'll be able to glean what users exist on the ILO from the info provided. In this example I'm just going to change the password for the admin user by using the following xml file. We'll set the password to "MyPassword".

  
   
 <USER_INFO MODE="write">  
   <MOD_USER USER_LOGIN="admin">

The command to run is hponcfg /f iloconfig.xml where iloconfig.xml is the file holding the above text.

Note: As long as you're a local administrator on the machine, the credentials at the top in the <LOGIN> tag can be bogus.

Scripting the Installation of Supplemental Language Support

I've spent a lot of time lately working on automating server builds. One of my TODOs which I finally tackled today was installing support for the Complex Script and East Asian language packs which you normally have to manually check off in the regional control panel:

If you have run Active Directory in a large environment, particularly with domain controllers in Asia or the Middle East, chances are you've gotten this event before (or a similar one):

Event Type:    Error
Event Source:    NTDS ISAM
Event Category:    General
Event ID:        604
Date:            11/17/2008
Time:            12:23:28 AM
User:            N/A
Computer:        TOKYO-DC02
Description:
NTDS (648) NTDSA: Locale ID 0x00000411 (Japanese Japanese) is either invalid or not installed on this machine.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

You get these when Outlook clients connect via NSPI and they're running one of the languages you need to manually install support for with the UI above. Checking the boxes, providing Windows with your install CD, and rebooting will take care of these errors. There's no particularly easy way to do this from a script though. Some Google searching revealed that KB289125 discusses how to do this. This blog entry also has a lengthy discussion in the comments.

I came up with the following little script which works properly on Windows Server 2003 (x86 and x64 versions). Note you'll need to reboot for these changes to be complete:

Dim shl
Set shl = WScript.CreateObject("WScript.Shell")

Dim fso
Set fso = WScript.CreateObject("Scripting.FileSystemObject")

' install complex character & far east support
WScript.Echo "Installing Complex Script and East Asian language support"
Dim intlConfig
Set intlConfig = fso.CreateTextFile("c:\scripts\intlunattend.txt")

intlConfig.WriteLine "[RegionalSettings]"
intlConfig.WriteLine "LanguageGroup = 7,11" ' 7 = Japanese, 11 = Thai
intlConfig.Close    

shl.Run "cmd /c start /wait rundll32 shell32,Control_RunDLL intl.cpl,,/f:""c:\scripts\intlunattend.txt""", 0, True

NOTE:On Windows Server 2003 x64, you need to have access to the AMD64 and i386 folders in order for this to work. I spent a bunch of time running in circles on this.

The entry point called here will use the base Windows Setup APIs, so, it will reference these two registry keys by default:

HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\SourcePath
HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\ServicePackSourcePath

The correct syntax for these is to point to the parent folder containing the setup files. So, if your setup files are in C:\i386, you would set these registry keys to "C:\".

If you want to specify a custom path to the installer (let's say E:\AMD64), you should add /s:"E:\AMD64" to the command (remember to double quote in VBScript) right after the /f call:

shl.Run "cmd /c start /wait rundll32 shell32,Control_RunDLL intl.cpl,,/f:""c:\scripts\intlunattend.txt"" /s:""e:\amd64""", 0, True

You can also do all this during unattended setup. Take a look at the [RegionalSettings] section of deploy.chm if you're planning on doing this as there are some caveats and additional steps (nothing complex though). Also note that I believe all this is totally different in Vista/2008 so I don't think any of this will work in that scenario

Amazon EC2 on Windows

Amazon announced the ability to run Windows virtual machines on their cloud computing platform, EC2, a few weeks ago. I had the opportunity to play with the technology for a few weeks and I was really impressed all around with the experience. If you're looking at solutions for on demand computing or want to have a relatively inexpensive and flexible hosting solution you can control completely, you should definitely take a look at EC2.

I wrote a couple of articles for Amazon as part of the launch of Windows on EC2. The articles cover deploying an ASP.Net app on an EC2 instance and configuring SQL Server 2005 to work with the Amazon EC2 platform. If you're interested in getting a quick feel for how the platform works, check these articles out:

Retrieving Machine Serial Numbers from the Command Line

Here's a handy trick I discovered recently when I needed to get a lot of server serial numbers pretty quickly. Normally you have to login to the Dell or HP management website and dig around before you can get the serial number. Sometimes the website doesn't work and you're either negotiating with the local support guy to go find it for you (and then the data's suspect by definition), or you're just out of luck.

You can grab this easily from the command prompt. Look up the wmic switches for info on connecting remotely to a machine:

C:\>wmic

wmic:root\cli>systemenclosure get serialnumber

SerialNumber
ABC12345

wmic:root\cli>exit

C:\>

Cool Remote Shutdown Trick

I learnt today how to shut down/reboot a huge number of computers en masse regardless of whether or not they're turned on. Windows XP and Server 2003 have a command line utility called “shutdown”. If you pass a /i switch to it, a cool GUI interface pops up. At the top, you can add one or more computers to reboot/shutdown. I generated text file dumps of my computer labs with each computer on its own line. I paste the whole thing into the box, and click okay. From there, I just set the wait time to two seconds, pick a reason for the shutdown/reboot, and click okay. The utility iterates through the list gracefully, and handles any unreachable machines without error. Machines which are inaccessible have their names printed out the command line once the utility is through.

How to Sysprep in Windows Vista and Windows Server 2008

Note: This post discusses Sysprep as it pertains to Windows Vista and Windows Server 2008. If you’re working with a different version of Windows, check out these posts:

I thought I'd document how to setup the new Sysprep process equivalent on Windows 2008 since the old setupmgr tool for making sysprep.inf's doesn't exist anymore (and neither does the sysprep.inf file itself).

The first step is acquiring the Windows Automated Installation Kit (WAIK) from somewhere. You can get this package in ISO file format from Microsoft's website at http://www.microsoft.com/downloads/details.aspx?FamilyID=94bb6e34-d890-4932-81a5-5b50c657de08&DisplayLang=en. The download is about an 800MB install on a Windows Server 2003 SP2 x86 machine.

The tool of choice for building your Sysprep configuration is the Windows System Image Manager (WSIM). When you start it you'll get a blank screen like this:

The first step is to catalog the image file. You can do this from Tools>Create Catalog, selecting your install.wim and then what image(s) to catalog. I'm setting up Windows Server 2008 Enterprise so I selected the appropriate option. The final three choices are the server core variants:

Note: You'll also need to copy the install.wim from your installation media DVD sources folder to the hard drive as the tool won't work with it if it doesn't have write access to the WIM file.

All of the settings you will want to setup in your unattend.xml file are in the tree under Windows Image. The documentation for all the settings can be found at http://technet2.microsoft.com/WindowsVista/en/library/69eee519-55a6-440d-ab94-56330ef57e291033.mspx. This link shows a mapping table between the sysprep.inf file and the new unattend.xml format.

My answer file tree:

Disabling the initial configuration dialog:

Disabling auto-starting the server manager application:

Setting my product key, timezone settings, and my name:

Configuring the screen resolution and color depth - 1280x960 is what works in VMWare full screen mode with the tabs across the top:

Configuring setup not to show me the EULA again:

Configuring setup to install a default local administrator account password:

One of the things I discovered doing this is that unlike Sysprep from Windows 2000 - 2003, the unattend.xml file isn't deleted at the conclusion of the Sysprep process. When down-level Sysprep completes, it deletes the c:\sysprep folder. In order to replicate this functionality, you can put a command in to delete the unattend.xml file in the SetupComplete.cmd batch file (which must be located in c:\windows\setup\scripts\) which gets called at the end of Sysprep. Reference this link for more info.

I put a simple one line command in my SetupComplete.cmd file:

del /Q /F c:\windows\system32\sysprep\unattend.xml

In order to run Sysprep you'll need to use a new command. The old Sysprep user interface that was there in Windows 2000 – Windows Server 2003 doesn't really exist anymore. All of the Sysprep command line switches are documented at http://technet2.microsoft.com/WindowsVista/en/library/72cc64e2-a0f3-4516-84fc-097577127fc91033.mspx.

sysprep /generalize /oobe /shutdown /unattend:sysprep.xml

So far this process is working fine for me with Windows Server 2008 Enterprise x86 full installs. I haven't tried it with server core yet, but if it's different I'll post something about that.

How to Build a Sysprep Answer File: Windows XP and 2003

Note: This post discusses Sysprep as it pertains to Windows 2000, Windows XP, and Windows Server 2003. If you’re working with a newer version of Windows, check out these posts:

Sysprep is one of those things that seems to have a certain mystique that surrounds it. My experience is that administrators either don't run it because they don't understand it or because they don't know how. Urban legend is also that it’s just not necessary to run Sysprep in some scenarios. The bottom line is that when making an image for duplicating Windows installs Sysprep is absolutely necessary as part of the imaging process. I'm not going to cover what Sysprep does here since that's not the focus, but the summary version is that Sysprep removes all identifying information about the source machine when it's executed (e.g. Computer name, SID, Product key, etc.). The rest of this post is geared primarily towards desktop imaging, but everything still applies for building server images.

Sysprep is on the Windows CD and the service pack CDs in the support folder in a file called deploy.cab. It's also available online:

If you need a version that isn't linked above either grab it from the CD or just search www.microsoft.com/downloads for Sysprep. There's a utility called setupmgr.exe in the archive which is what we can use to build the majority of the answer file for us. Most of it is self explanatory, I've included screenshots and explanations of steps that require some planning/thought.

The first question of note is what type of answer file to build. For this procedure we want a Sysprep setup:

The next important question is when we're asked about the license agreement and if we want to fully automate the installation (we do):

After telling the wizard you wish to fully automate the installation you'll get a screen with a tree view on the left and a set of Back/Next buttons. Most of this stuff is very self explanatory. The product key is an important one. You need to have a volume license key or you'll be activating each machine (and you'll run out of activations). Imaging without volume license keys is a recipe for disaster; I've seen it happen:

Computer name is another step that depends on a few factors. If you're doing mass imaging with a product like Ghost or Altiris, set it to Automatically Generate. If you're going to be doing one off imaging without something to automate the naming for you, leave it to Automatically Generate and we'll come back later to set Sysprep to prompt for this information.

Unfortunately, the wizard doesn't seem to support setting the Administrator Password by default, so just put something temporary in for now and we'll get rid of it later. You also get the option to automatically log on as the administrator some N number times. This is useful for running post imaging scripts. A word of caution is that the username and password for the administrator account is stored in the registry in plain text when this option is used, and it is not cleaned up at the end, so make sure your script does this cleanup step when it finishes!

I leave Networking Components set as-is as it defaults to DHCP. Make sure your image machine is set to DHCP when it shuts down to be imaged or it may not come up that way!

Workgroup or domain is another option which depends on the imaging/duplication mechanism you employ. For one off imaging, it can be helpful to setup Sysprep to automatically join the machine to your domain. This is especially nice if you delegate the imaging process to a junior admin who may not have rights to do this themselves as the wizard will take care of it all. The account specified should have rights to create and delete computer objects and write access to all properties for Computer objects. It also needs the Add Computers to the Domain right delegated at the domain level. Don't be cheap and add the account to the Domain Admins group and forget about it. There is an additional option which can be specified in the Sysprep.inf file that will be generated which tells Sysprep to put the machine in a specific OU (this is not supported in Windows 2000). If you use this option the account only needs rights over that OU.

If you're using something like the Ghost Agent to automate the post imaging process, just choose the workgroup option and let Ghost manage joining the domain.

The rest of the wizard is pretty straight forward and I just fill it out even if some of the prompts aren’t really necessary. Install Printers is something I generally do via Group Policy, so I don't typically use that feature. Additional Commands can be used to specify post imaging tasks (e.g. scripts). Identification String has no functional value out of the box. It's just a string that's stored in the registry. I typically set it to something that identifies each image e.g. "Dell GX260 XP Pro BCD v1.1". This tells me that this machine is built with version 1.1 of my XP Pro image for the Dell GX260. I can then use scripts/inventory tools to report on what images are on PCs in my domain. The Identification String page has the Finish button which saves the Sysprep.inf file.

At this point you're done, or you can customize the process more by editing the resultant INF file manually. The two CHM files that come with Sysprep fully document every option available and are worth skimming just to know the format if nothing else.

As an example, I'm going to edit the Sysprep.inf file and setup a few additional settings:

Using the administrator password configuration in my image rather than setting a new one;
Extending the C partition to fill the hard disk;
Prompting for the computer name;
Joining the domain and putting the computer in a specific Organizational Unit.

Fresh out of the wizard the Sysprep.inf file should look something like this:

;SetupMgrTag
[Unattended]
    OemSkipEula=Yes
    InstallFilesPath=C:\sysprep\i386

[GuiUnattended]
    AdminPassword="password1"
    EncryptedAdminPassword=NO
    TimeZone=35
    OEMSkipRegional=1
    OemSkipWelcome=1

[UserData]
    ProductKey=ABCDE-ABCDE-ABCDE-ABCDE-ABCDE
    FullName="Brian Desmond"
    OrgName="Brian Desmond Consulting, LLC"
    ComputerName=*

[SetupMgr]
    DistFolder=C:\sysprep\i386
    DistShare=windist

[Identification]
    JoinDomain=DOMAIN
    DomainAdmin=sysprepadmin
    DomainAdminPassword=password

[Networking]
    InstallDefaultComponents=Yes

To use the administrator password in the image, set AdminPassword=*. Also remove the EncryptedAdminPassword=NO line.

Extending the C partition to fill the hard disk is something I often do for desktop images depending upon the environment. To do this, add a line in the [Unattended] section called ExtendOEMPartition=1.

To prompt for the computer name, delete everything behind the =, such that ComputerName= is the whole line

To put the computer in a specific Organizational Unit in the Active Directory domain, add a line under the [Identification] section called similar to this: MachineObjectOU="OU=Desktops,OU=Machines,DC=Domain,DC=local". Obviously you’ll need to customize this string for your environment.

With all these additions the Sysprep.inf file now looks like this:

;SetupMgrTag
[Unattended]
    OemSkipEula=Yes
    InstallFilesPath=C:\sysprep\i386
    ExtendOEMPartition=1

[GuiUnattended]
    AdminPassword="!Password1"
    EncryptedAdminPassword=NO
    OEMSkipRegional=1
    OemSkipWelcome=1

[UserData]
    ProductKey=ABCDE-ABCDE-ABCDE-ABCDE-ABCDE
    FullName="Brian Desmond"
    OrgName="Brian Desmond Consulting, LLC"
    ComputerName=*
    
[SetupMgr]
    DistFolder=C:\sysprep\i386
    DistShare=windist

[Identification]
    JoinDomain=DOMAIN
    DomainAdmin=sysprepadmin
    DomainAdminPassword=password
    MachineObjectOU="OU=Desktops,OU=Machines,DC=Domain,DC=local"

[Networking]
    InstallDefaultComponents=Yes

To run the Sysprep utility, copy everything from the deploy.cab or the download to a folder called c:\sysprep and launch sysprep.exe. Choose the Reseal option and make sure the option to run mini-setup is checked. Everything will take care of itself from here. The machine will shutdown and be ready to have an image captured. My suggestion is to boot the machine back up and test the Sysprep process to make sure things go as planned.

Warning: Sysprep will delete the entire c:\sysprep folder when complete, so make sure you have a backup of the configuration elsewhere.

That's it. I keep a folder called Syspreps on the imaging server which I then create subfolders of for each configuration. I copy the entire contents of the deploy.cab as well as the Sysprep.inf for each configuration to this folder so I have it available anytime an image is going to get updated.

Getting Total Installed Memory with WMI

Getting the amount of memory installed in a machine with WMI is a bit confusing particuarly if you only read the docs partially. I was initially using Win32_ComputerSystem::TotalPhysicalMemory, but the documentation warns "Be aware that, under some circumstances, this property may not return an accurate value for the physical memory. For example, it is not accurate if the BIOS is using some of the physical memory."

The suggested alternative is Win32_PhysicalMemory::Capacity. This was an easy switch in my script, but, I was getting numbers I knew were wrong for the machines I was querying. The part I didn't read was that each instance of Win32_PhysicalMemory represents a single stick of RAM, so, you need to loop through them all and take the sum to get the RAM installed. This snippet will get you the total memory in megabytes:

Set colItems = wmiSvc.ExecQuery("SELECT * FROM Win32_PhysicalMemory", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)
totalMemory = 0
For Each item In colItems
totalMemory = totalMemory + CLng(item.Capacity) / (1024^2)
Next

Script to Collect Local Administrators Membership

Another script I wrote the other day, this one will take an input file called workstations.txt and produce a CSV which is easy to view in Excel and look at the local administrators group membership for the list of machines. The script could easily be modified to get the list from Active Directory although he framework I usually use for these is setup for a text file so I just export a list if AD is my source. The script will attempt to ping the machine before connecting in order to try and determine availability. If you have firewalls or routers filtering ICMP between the target machine and the host executing the script you may need to remove or modify this feature.

The script produces two files - a CSV and a log file. These three parameters are all configurable at the top by modifying lines 11 - 13:

Const LogFile = "LocalAdmins.log"
Const resultFile = "LocalAdministratorsMembership.csv"
Const inputFile = "c:\scripts\workstations.txt"

The script is attached below in a ZIP file. If you have any comments, bugs, etc, feel free to post them in the comments box below and I'll certainly take a look. Enjoy.

UPDATE: Script download URL - http://www.briandesmond.com/blog-attachments/dumplocaladministrators.zip

Script to Collect Basic Inventory Data From Machines

This is another useful script I sometimes use when I need to collect some basic inventory data from a list of machines. The attached vbscript takes an input file called workstations.txt and produces an comma separated output file called workstationinventory.txt. You can modify the two constants at the top of the file as noted below if you want to change this:

The script currently only outputs a limited set of information but the framework is there to extend it to collect really anything available via WMI. The fields currently exported are:

Make
Model
BIOS Version
Operation System
Serial Number

To configure the input and output file modify lines 12 and 13:

Const PATH_TO_INPUT = "workstations.txt"
Const PATH_TO_OUTPUT = "workstationinventory.txt"

If you're looking for some guidance on other WMI data, check out the Scriptomatic tool from Microsoft.

The script is attached below in a zip. If you have any comments, bugs, etc feel free to leave them in the comments field and I'll take a look.

UPDATE: Script download link - http://www.briandesmond.com/blog-attachments/collectworkstationinventory.zip

Script to Reset Local Administrator Passwords

I realized I hadn't posted this one answering a newsgroup post this morning. The attached script will iterate through a list of workstation names in a text file, ping them, and if the ping returns then reset the local administrator account password to whatever is defined at the top of the script. This is pretty basic and would potentially need some customization. You might want to adapt it to iterate through an OU or set of OUs instead and get the computer names from there, or perhaps set different administrator passwords on the machines.

Feel free to leave any questions/comments/etc in the comments box below and I'll take a look.

UPDATE - Script download link: http://www.briandesmond.com/blog-attachments/changelocaladminpasswords.zip

Forcing a Blue Screen via iLO

This post covers working with an iLO1. If you’re using an iLO2, visit http://briandesmond.com/blog/forcing-a-blue-screen-via-ilo-ilo2-version/.

Path: HKLM\System\CurrentControlSet\Control\CrashControl
Value: NMICrashDump
Data: 1
Type: REG_DWORD

You’ll need to reboot for the change to take effect. If you don’t reboot after making this change, you’ll see the effect illustrated here.

Note: If you have the Automated System Recovery (ASR) functionality enabled on the server and you need to get a full memory dump, you will need to turn it off as it can interfere with this process. This is a BIOS setting which I don't have the steps to change easily available. If there's demand (leave a comment), I can track them down.

To crash the box, these are the steps. I shot these screens on a DL360 G4 which is fairly recent hardware. I suspect the screens and locations of options may vary a bit by age (and especially on older legacy Compaq stuff), but the basic process is the same.

1. Login to the ILO and then proceed to the "Server and iLO Diagnostics" link on the left hand navigation:

2. Select the Virtual NMI Button option on the toolbar:

Warning! I can’t guarantee that this button generates a warning when you click it on all versions of the iLO firmware. Generating an NMI will HALT your system. Don’t click this button just to see what happens.

3. Generate the NMI. This button is towards the bottom of the page so if your browser doesn't automatically scroll down to it, you'll have to drill down:

4. You will get a warning dialog to make sure you're really certain this is what you want to happen. Remember, doing this will HALT your system!

5. The iLO will write a status message to the status bar in IE:

6. At this point Windows will crash with a 0x80 bugcheck and reboot (assuming your machine is configured to automatically reboot after a bluescreen). You can hopefully use the memory dump to assist in troubleshooting the problem at hand.

Note: If you don’t get a traditional blue screen and instead get the nontraditional blue screen pictured here, you’ve made an error entering the registry setting described earlier or you did not reboot.

Note: This capability is present in the Dell DRAC3 cards. I spoke with Dell and they advised me that this functionality is not available in newer generation DRAC cards.

How to Turn on Remote Desktop Remotely

Here's a simple trick that I've used countless times for enabling remote desktop on an XP or 2003 machine remotely. Windows 2000 requires a service to be installed, so this won't help there.

Just connect to the remote machine with regedit (or use reg.exe from the command line if you want), browse to HKLM\System\CurrentControlSet\Control\Terminal Server, and set or create fDenyTSConnections (a DWORD) to 0.

Command Prompt History

The Windows command prompt will actually show you a little history view of all the commands you've typed in the current session. You can use the arrow keys to select a past command and execute it again as well. To access this view just press F7:

Enabling the Telnet Client on Windows Servers and Desktops

The Telnet Client is not installed by default on Windows. Instead, the Telnet Client is an optional feature that you must install. To do this, on a client computer, follow these steps:

Open the Control Panel
Click Programs and Features
Click "Turn Windows features on or off" on the left.
Check the "Telnet Client" box.

On a server, the procedure is slightly different:

Open an elevated command prompt
Run the command below:

dism /online /Enable-Feature /FeatureName:"TelnetClient"