Michael Niehaus' Windows and Office deployment ramblings
Windows AIK 1.0 included a BOOTSECT.EXE tool that could update the boot sector to either a Windows Vista/Server 2008 (/nt60) or a Windows XP/Server 2003 (/nt52) version. But it didn't provide a way to update the master boot record (MBR). If you wanted to do that, you had to boot into the Windows recovery environment and then run "FIXBOOT /MBR". The downside of that: it can't easily be automated. (What's the difference between a boot sector and an MBR? Read up on it at http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/prork/prcb_dis_qxql.mspx?mfr=true.)
The MBR code was updated for Windows Vista, and if you install Windows Vista using SETUP.EXE (e.g. straight from the DVD or using MDT Lite Touch) it will update the MBR appropriately. And running DISKPART "CLEAN" will also update the MBR. But if you aren't wiping the disk and aren't using SETUP.EXE, the old MBR would be left in place.
Why does this even matter? One noticeable reason: BitLocker wants to see a Windows Vista MBR, and won't let you enable BitLocker if it doesn't find one. So you need a way to do that, something easily automated. That something is a new version of BOOTSECT.EXE included in Windows AIK 1.1. This version has a new /MBR switch that takes care of installing the latest MBR.
This is actually related to why ConfigMgr 2007 SP1 requires Windows AIK 1.1: it wants to use the new BOOTSECT.EXE /MBR command, so it needs the latest BOOTSECT.EXE /MBR command. The old BOOTSECT.EXE will fail if you specify this previously-nonexistent command line option. (MDT 2008 Lite Touch uses slightly different logic: it tries the BOOTSECT.EXE /NT60 /MBR command and if it fails it tries again without the /MBR switch. So we can still support Windows AIK 1.0 and 1.1.)
In the Microsoft Deployment Toolkit refresh scenario (back up user state from current OS, boot to PE, wipe old OS from disk, install new OS image, boot into new OS, restore user state) we normally don't support any type of disk repartitioning or reformatting because we are actively running from the disk. But there is a scenario that can be done successfully: remove a second partition and go back to having a single-partition setup. So how would you do that? It's really not too difficult:
The custom DISKPART script removes the second partition (make sure there's nothing on it you want to keep first), and then the Windows XP mini-setup or Windows Vista specialize process takes care of extending the OS partition to take up the remainder of the disk.
On a slightly-related topic, it's actually this extension process that causes the issues described in KB 931760 (the uberbug). If you deploy Windows XP with a sysprep.inf that doesn't specify ExtendOemPartition=1 you probably won't see any issues and won't have to do any of the workarounds described in the KB article.
If you want to move the other direction (from a single partition to two partitions) let me try to talk you out of it :-) (I'm not a big fan of multiple-partition configurations, e.g. one partition for the OS and one partition for user data.) It is possible to move from one to two, but it is more difficult. The basic process would be to defragment the disk (in case there is something at the end of the partition), boot into Windows PE 2.0 (running from a RAMdisk so that the existing partition isn't in use), and then run DISKPART to shrink the current partition:SELECT DISK 0SELECT PARTITION 1SHRINK QUERYMAXSHRINK DESIRED=10000 MINIMUM=5000
In this case, the "QUERYMAX" statement would tell you how much you can shrink the partition, while the DESIRED and MINIMUM parameters specify how much to actually do (in MB). (The SHRINK command was added in the Windows Vista/Windows PE 2.0 version of DISKPART, in case you missed it.)
Wow, no more separate downloads and archive files - just grab them from \\live.sysinternals.com\tools. (If for some reason this doesn't work for you, try http://live.sysinternals.com.) I see a new XCOPY command in my standard computer installation process:
XCOPY \\live.sysinternals.com\tools\*.* C:\Tools
See the announcement for this new beta program at http://blogs.technet.com/sysinternals/archive/2008/05/28/updates-process-explorer-v11-20-zoomit-v2-0-sigcheck-v1-53-handle-v3-4-and-introducing-sysinternals-live-beta.aspx.
In the US this year, they are trying something different: a two-week TechEd conference with the first week (June 3-6) focusing on developer topics and the second week (June 10-13) focusing on IT Professional topics. (Don't worry, you will register for each week separately.) This is very similar to the organization used for the European version of the conference, not surprisingly (although this year for the European event in November the IT Professional week will be held first).
For more information on the events, see the official websites at http://www.microsoft.com/events/teched2008/itpro/default.mspx and http://www.microsoft.com/events/teched2008/developer/default.mspx. Full session catalogs are available.
The sessions I am presenting are pretty much the same as those given at MMS 2008 in Las Vegas last month, with a couple of additional ones added to make our lives a little more interesting:
Advanced Operating System Deployment with Microsoft System Center Configuration Manager: Extending OS Deployment with the Microsoft Deployment Toolkit (Part 3 of 4)
Microsoft Deployment is the next version of Business Desktop Deployment (BDD) 2007. New features in Microsoft Deployment integrate with and extend the native OS deployment functionality of Configuration Manager 2007 while providing thorough project management guidance. Examine how the Microsoft Deployment toolkit uses and extends the OS deployment capabilities presented in parts 1 and 2, providing new wizards, task sequence templates, additional server deployment automation, and other features.
Advanced Operating System Deployment with Microsoft System Center Configuration Manager: Provisioning Your Windows Deployment with Microsoft Deployment (BDD) (Part 4 of 4)
Now that you have a good understanding of the OS deployment features and functionality provided by Configuration Manager and Microsoft Deployment, explore ways to create dynamic, data-driven deployment processes. We discuss performing rules-based, data-driven deployments; using external data sources; adding your own scripts and customizing those provided with Microsoft Deployment; overriding task sequence properties; and other advanced topics.
What's New in Microsoft Deployment Toolkit (MDT) 2008? Updates for Windows Server 2008 and Windows Vista SP1
Windows Server 2008 and Windows Vista SP1 introduce new changes in the underlying service stack and Windows Automated Installation Kit. These changes are addressed in the second release of the Microsoft Deployment Toolkit (MDT) 2008 (formerly BDD). This session introduces MDT 2008 changes. MDT 2008 focuses on Windows Vista SP1 support and Windows Server enhancements; it provides broader support for automated role installation using Server Manager in Windows Server 2008. This session is presented first-hand by solution developers and provides a current roadmap and release schedule for future MDT releases.
Unleash the Power of the Microsoft Deployment Toolkit (MDT) 2008 (formerly BDD) with Customization
This session is for those who fully understand the Microsoft Deployment Toolkit (MDT) 2008, Microsoft Business Desktop Deployment (BDD) 2007, Microsoft System Center Configuration Manager 2007, and Systems Management Server 2003 with OS Deployment FP toolsets, but are looking to do more. We pool the key deployment customization themes and provide concrete examples to improve your deployments. In this session, we do not cover overview themes or 300-level content, but we discuss topics such as: understanding and using rules, deep dive into the deployment wizards, how to utilize the scripting framework to create your own scripts, using naming conventions, custom database lookups, and Web service lookups. We encourage open dialog for additional advanced customization themes and requests.
Automated Windows Server 2008 Imaging and Deployment Using the Microsoft Deployment Accelerator
Deployment tools for Windows Server 2008 have changed and most legacy tools will not support automated installation of Windows Server 2008. Microsoft Deployment is the next version of Business Desktop Deployment (BDD) 2007. The fourth generation deployment accelerator supports Windows Server 2008 imaging and deployment. This session is delivered by solution developers and explains how you can use Microsoft Deployment to plan deployments, create disk images, customize installation task sequences, automate disk and NIC configuration, and automate server role defintion. We discuss the current released tools (System Center Configuration Manager 2007 and Windows Deployment Services [WDS] with multicast support), features and limitations, and the Microsoft Deployment release roadmap.
See http://support.microsoft.com/kb/950527 for the ConfigMgr 2007 hotfix that adds new supported platform entries for:
These changes should be included in ConfigMgr SP1 too, so you can choose to wait for that too.
A separate hotfix for SMS 2003 SP3 should be available in the near future.
Yes, in fact there are two different types:
The MSDN web page at http://msdn.microsoft.com/en-us/library/ms791134.aspx talks about the different classes of drivers, but doesn't get into too much detail about the differences. For most purposes, you really shouldn't care too much either, unless you are working with products or scripts that need to know the difference. That brings us to Configuration Manager 2007 and Microsoft Deployment Toolkit: both care about driver classes and need to take into account that there are two different types. Unfortunately, neither one did when they were released:
If you are using newer hardware that supports SATA disks but you've never run into either of these issues, it might be because you've configured your hardware in ATA or legacy mode, instead of using AHCI mode. Generally, I believe you should avoid ATA/legacy mode, as you lose some of the benefits of AHCI, including hot plug support (primarily beneficial with eSATA ports, http://www.intel.com/support/chipsets/imst/sb/CS-012308.htm), native command queing (http://www.intel.com/support/chipsets/imst/sb/CS-012305.htm), and on some hardware, RAID array support.
Keep in mind though that you can't just switch from one to the other without careful planning - because ATA/legacy and AHCI modes require different drivers, Windows has to know about the new driver before making the switch. See http://support.microsoft.com/kb/922976 for some details on what needs to be done for Windows Vista. Also check out http://support.microsoft.com/kb/928253 if you have SATA-based optical drives. Both of those issues are fixed in Windows Vista SP1.
Driver support for common AHCI-based mass storage controllers is included in Windows Vista SP1. For Windows XP, though, you need to make sure that the right drivers are included in the image. (That's what ConfigMgr and MDT 2008 are trying to do for you.)
Microsoft Deployment Toolkit includes a check in the Lite Touch script LTISysprep.wsf to ensure that you are using the right version of SYSPREP when preparing your Windows XP image for capture. With the release of Windows XP SP3, that means you need to have updated SYSPREP files too. If you integrate the service pack into Windows XP SP2, you'll get the latest OS files, but you won't get the latest SYSPREP files - the SUPPORT\TOOLS\DEPLOY.CAB will not be updated.
So, that leads to the question: Where get I get an updated DEPLOY.CAB with the right SYSPREP files? Simple, download one of these:
Windows XP Service Pack 3 Deployment Tools (just the DEPLOY.CAB)http://www.microsoft.com/downloads/details.aspx?familyid=673a1019-8e3e-4be0-ac31-70dd21b5afa7&displaylang=en
Windows XP Service Pack 3 - ISO-9660 CD Image File (the DEPLOY.CAB plus the rest of the SP3 content)http://www.microsoft.com/downloads/details.aspx?FamilyID=2fcde6ce-b5fb-4488-8c50-fe22559d164e&DisplayLang=en
If you donwload the ISO, you'll need to either burn it to a CD or mount it using an appropriate tool. Then you can get to the DEPLOY.CAB in the SUPPORT\TOOLS\DEPLOY.CAB folder.
Once you have the DEPLOY.CAB file, overlay the SUPPORT\TOOLS\DEPLOY.CAB in your XP SP3 source directory (e.g. \Distribution\Operating Systems\XPSP3\SUPPORT\TOOLS\DEPLOY.CAB) with this new version. (If you have extracted the SYSPREP file and placed them in the OS source directory, you'll need to repeat that process with the SP3 versions of the files, or just remove the extracted SYSPREP files and let the LTISysprep.wsf script take care of it for you as part of the capture process.)
(Updated to include a link directly to the DEPLOY.CAB download, posted today. Thanks to Blake Handler, http://bhandler.spaces.live.com/, for pointing that out.)
For those of you familiar with how BDD 2007 and MDT used the SMS 2003 OSDSWDEXEC.EXE program to install packages specified via CustomSettings.ini or in the BDD/MDT database. That same capability is present with ConfigMgr 2007 using the built-in "Install Software" step. See more on that at http://technet.microsoft.com/en-us/library/bb680842.aspx.
From an MDT 2008 perspective, the implementation is nearly identical to what we did before with SMS 2003: we need to build up a list of packages using task sequence variables, specifying a common base name and a sequential numeric suffix. In our default ConfigMgr task sequence template, we use a base variable name of "PACKAGES". So you could specify entries in CustomSettings.ini like so:
PACKAGES001=XXX00001:InstallPACKAGES002=XXX00002:InstallPACKAGES003=XXX00003:Install
(Replace "XXXnnnnn" with your package ID and "Install" with your program name. Also, in the case of CustomSettings.ini, we don't care if you specify PACKAGES1, PACKAGES2, PACKAGES3 or PACKAGES001, PACKAGES002, PACKAGES003 as we'll do the necessary translation to the ConfigMgr-mandated three-digit suffix.)
You could also specify the same values in the MDT database (on the Packages tab; we'll take care of building the proper list); in ConfigMgr collection or computer variables (you need to specify the PACKAGES001-style names, with no gaps in the sequence); via your own scripts; or via "Set Variable" steps added to the task sequence. Regardless of how these values are set, the "Install Software" step that we have configured to look at the "PACKAGES" base variable name will see the entries in the list and install them all in the order specified. Getting into all the pros and cons of one method versus another is a subject for a later day - for those of you who attended the "Part 4" session Tim and I gave at MMS 2008, you already heard this.
There is one other requirement to keep in mind (covered in the documentation at the link above, in case you didn't read that far): Before ConfigMgr will allow a specific package:program to be installed, you have to enable it by checking the "Allow this program to be installed from a list of software packages in the "Install Software" task sequence step without being advertised" checkbox on the program. This is a security feature in ConfigMgr: it wants your permission as an administrator before allowing this.
If you want to enable this option for all of your programs, consider running a script like this which will flip the required ProgramFlags bit for each program:
sProviderServer = "" sSiteCode = "CEN" sNamespace = "root\sms\site_" & sSiteCode sUsername = "" sPassword = "" ' Connect to the SMS provider Set oLocator = CreateObject("WbemScripting.SWbemLocator") Set oSMS = oLocator.ConnectServer(sProviderServer, sNamespace, sUsername, sPassword) ' Build the query sQuery = "SELECT * FROM SMS_Program" ' Process the query iCount = 0 Set oPrograms = oSMS.ExecQuery(sQuery) For each oProgram in oPrograms If (oProgram.ProgramFlags and 1) = 0 then oProgram.ProgramFlags = oProgram.ProgramFlags or 1 WScript.Echo "Enabling: " & oProgram.PackageID & ":" & oProgram.ProgramName On Error Resume Next oProgram.Put_ If Err then WScript.Echo "ERROR enabling " & oProgram.PackageID & ":" & oProgram.ProgramName & " possibly because of insufficient rights or because the package is not owned by this site. " & Err.Description Else iCount = iCount + 1 End if End if Next WScript.Echo "Total programs enabled: " & iCount
sProviderServer = "" sSiteCode = "CEN" sNamespace = "root\sms\site_" & sSiteCode sUsername = "" sPassword = ""
' Connect to the SMS provider
Set oLocator = CreateObject("WbemScripting.SWbemLocator") Set oSMS = oLocator.ConnectServer(sProviderServer, sNamespace, sUsername, sPassword)
' Build the query
sQuery = "SELECT * FROM SMS_Program"
' Process the query
iCount = 0 Set oPrograms = oSMS.ExecQuery(sQuery) For each oProgram in oPrograms If (oProgram.ProgramFlags and 1) = 0 then oProgram.ProgramFlags = oProgram.ProgramFlags or 1 WScript.Echo "Enabling: " & oProgram.PackageID & ":" & oProgram.ProgramName On Error Resume Next oProgram.Put_ If Err then WScript.Echo "ERROR enabling " & oProgram.PackageID & ":" & oProgram.ProgramName & " possibly because of insufficient rights or because the package is not owned by this site. " & Err.Description Else iCount = iCount + 1 End if End if
Next
WScript.Echo "Total programs enabled: " & iCount
The script loops through each program, checking to see if the first bit (AUTHORIZED_DYNAMIC_INSTALL, described briefly in the ConfigMgr SDK) of the ProgramFlags field is enabled, and if it isn't the script enables it. In most cases, you would want to run this program (using an account with sufficient rights) on your central primary site server, although if you have packages and programs defined at lower-level sites you would want to run it on them as well if you plan to use a task sequence to install any of those programs.
If you don't want to enable this on all programs, you can either modify the script above or you can manually enable the programs that you want.
Microsoft Deployment Toolkit contains a script named ZTIWindowsUpdate.wsf that can be enabled to run during Lite Touch OS deployments. By default, it will talk to the Microsoft Update site on the internet to get the latest updates needed for your Windows OS and Microsoft applications like Office. But you might not want all of the machines you deploy doing that. So with MDT 2008, we added the ability to install updates from a WSUS server. The "Toolkit Reference" document describes the basic process:
MDT 2008 can also configure WUA to collect updates from computers on the corporate network that are running WSUS instead of connecting to Microsoft Updates over the Internet. MDT 2008 can optionally configure WUA to use a specific computer running WSUS using the WSUSServer property.
But the actual description of the WSUSServer property, and a sample of how to set it, was accidentally left out of the documentation. This needs to be configured via CustomSettings.ini by adding an entry that looks like this:
WSUSServer=http://mywsusservername
With that set, the ZTIWindowsUpdate.wsf script will automatically configure the Windows Update Agent to talk to this WSUS server instead of using Microsoft Update.
One other note: the new OS being deployed to the machine must be running a supported version of the Windows Update Agent (WUA). Windows XP and Windows Server 2003 don't contain that needed version, so they need to be upgraded. This will be done automatically by the script, downloading the files from the internet if necessary. But it would be more efficient for you to download them in advance and place them where the script can find them. Again from the documentation:
For additional information and for WUA deployment instructions, go to http://technet.microsoft.com/en-us/library/bb932139.aspx. You can obtain the latest version of the WUA stand-alone installer for: x86 versions (WindowsUpdateAgent30-x86.exe) at http://go.microsoft.com/fwlink/?LinkID=100334. x64 version (WindowsUpdateAgent30-x64.exe) at http://go.microsoft.com/fwlink/?LinkID=100335. Windows Vista and Windows Server 2008 include the most recent version of WUA, so no upgrade is necessary for these operating systems. In Windows XP and Windows Server 2003, one of the following will occur: If the WUA 3.0 stand-alone installer files are in the TOOLS\architecture folder (where architecture is either x86 or x64) on the deployment point, MDT 2008 will automatically install WUA on the target computer. When downloading the WUA 3.0 stand-alone installer files, save them in the distribution\TOOLS\architecture folder (where distribution is the folder where the distribution point is created). If the WUA 3.0 stand-alone installer files are not in the TOOLS\architecture folder on the deployment point and if the existing version of WUA is configured for a WSUS server, then WUA will attempt to update itself from a WSUS server. If the existing version of WUA is not configured for a WSUS server, then MDT 2008 will attempt to download and install WUA 3.0 from the Microsoft Update site. In this case, Internet access is required for the target computer.
For additional information and for WUA deployment instructions, go to http://technet.microsoft.com/en-us/library/bb932139.aspx.
You can obtain the latest version of the WUA stand-alone installer for:
Windows Vista and Windows Server 2008 include the most recent version of WUA, so no upgrade is necessary for these operating systems. In Windows XP and Windows Server 2003, one of the following will occur:
So if you set WSUSServer and download the updated stand-alone installers, then the ZTIWindowsUpdate.wsf script will be able to update your computer without access the internet to do so.