CHAPTER 22
Operating System Deployment

One of an organization’s most difficult information technology (IT) tasks is managing operating systems (OSs); this includes upgrading to new versions, migrating to new hardware, performing clean installs, and more. To help address these needs, Microsoft includes operating system deployment (OSD) components in System Center Configuration Manager (ConfigMgr). ConfigMgr first included OSD components with ConfigMgr 2007. OSD was refined in ConfigMgr 2012 and continues to be enhanced with ConfigMgr Current Branch to meet today’s many needs from an OSD perspective.

OSD involves delivering a mass deployment of a new instance of the Windows OS to compatible devices. While that may seem simple, due to the philosophy and architecture of Windows, it is not always as easy as it sounds. Mass delivery of the Windows OS is nothing new; enterprises have been creating an image of a single system and copying it to other systems since Windows became the de facto standard OS for businesses.

Following are some reasons OSD is the tool to use for this task:

OSD is about automating the entire process, from image creation and image maintenance to actual image deployment.

OSD is not just about creating and deploying an image. It is an entire process that allows you to define actions before the image is applied to a system. This includes partitioning and formatting the drive or even BIOS upgrades and actions after applying the image, such as software update installation or application deployment.

OSD is dynamic, enabling different yet automatic deployment time behavior based on an unbounded set of criteria, including hardware type, location, and intended user or system roles.

OSD is extensible to meet the needs of any organization. The Microsoft Deployment Toolkit (MDT) and its subset feature, User Driven Installation (UDI), are excellent examples of this extensibility.

OSD is integrated into ConfigMgr, enabling you to utilize the other powerful features of the product, including software distribution, software updates, and reporting, all from a single management console in a seamless manner.

This chapter covers OSD in depth, including applicable scenarios, detailed use, guidance, best practices, and troubleshooting. This single chapter cannot and does not cover the complete range of information and knowledge required to deploy Windows fully in an enterprise environment, nor does it cover supplemental tools such as MDT.

Upgrade an Operating System from an Upgrade Package: This TS type, found in the Create Task Sequence Wizard, creates steps to upgrade systems from Windows 7, 8, and 8.1 to Windows 10.

WinPE Peer Cache: This allows systems running a TS to download content from a local peer machine while in Windows Preinstallation Environment (WinPE).

Windows 10 Servicing: While not completely an OSD item, Windows 10 servicing allows you to upgrade Windows 10 devices from one version of the Semi-Annual Channel to another version, using the software updates feature. For a complete overview of this process, which can help keep your Windows 10 devices current, see Chapter 15, “Managing Software Updates.”

Evaluate Software Updates from Cached Scan Results: This is a check box in the Install Software Updates TS step. If it is unchecked, the system can connect to the software update point (SUP) and download the latest software updates catalog to scan against and determine what software updates are needed.

The SMSTSSoftwareUpdateScanTimeout Variable: This TS variable controls the timeout for the software updates scan during the install software updates TS step.

OSDPreserveDriveLetter Variable Has Been Deprecated: This TS variable allowed you to choose the drive letter to use during OSD; this is now automatically determined by Windows Setup.

Customize the RamDisk TFTP Window Size: You can customize the window size for the RamDisk Trivial File Transfer Protocol (TFTP) when using Preboot eXecution Environment (PXE), so you can optimize the traffic across the network.

The TSUEFIDrive Variable: This variable allows you to customize an OSD TS so the restart computer step prepares a FAT32 partition on the hard drive for transition to Unified Extensible Firmware Interface (UEFI).

Prepare ConfigMgr Client for Capture TS Step: This step now completely removes the Configuration Manager client instead of only removing key information.

Secure Boot Information Is Now Collected with Hardware Inventory: There is a new WMI class called SMS_Firmware, which allows ConfigMgr to collect the UEFI and secure boot information from machines that have these newer updates to their hardware. This class is enabled by default in the hardware inventory classes.

Collapsible Task Sequence Groups: This new item allows you to collapse or expand groups with a TS. This can be a big benefit for large TSs with many groups inside them. Collapsing allows the user to more easily focus on specific areas of the TS. The groups can be expanded or collapsed all at once with buttons at the top of the TS, or they can be expanded or collapsed individually with the plus (+) or minus (-) on the left-hand side of the TS.

Reload Boot Images with the Current WinPE Version: The 1706 version of ConfigMgr Current Branch provides the option to reload the latest version of WinPE installed on the machine with the Windows Assessment and Deployment Kit (ADK) when you update your distribution points (DPs). When choosing to update the boot image on the DPs, a new wizard page is displayed that shows the current version of the boot image, OS version, and ConfigMgr client version, as well as the installed version of the ADK. To update to the newer ADK version, select the check box at the bottom of the screen, and the boot image will be updated using the ADK version that is installed.

Upgrade: Involves an in-place upgrade of the current OS to a new OS. It preserves user data and applications, and some consider it the best choice when moving an organization to a new OS. The downside is it preserves misconfigurations, unauthorized software, and any existing malware.

New Computer: This name is a little misleading as it can apply to new systems out of the box or to those that are being completely reloaded. Its distinguishing factor is that any user data and applications on an existing system are ignored. Often referred to as bare-metal or wipe-and-load, this scenario assumes that nothing on the system is valid, and the system should be built from scratch or bare metal.

Refresh: Involves installing a fresh, new OS on an existing system while preserving applicable user data and reinstalling authorized applications—in effect refreshing just the OS. This reload can result in a variety of situations:

The version of Windows is updated from an older version to a newer version.

The current OS installation is broken beyond repair.

The OS installation does not meet current standards.

Replace: While similar to the refresh scenario, the replace scenario involves replacing the physical system. It also preserves applicable user data and reinstalls authorized applications.

Generates new and unique identifiers for the system

Enables the input of a new Windows product key

Reruns the plug-and-play hardware detection

Reruns the driver installation process

OSD fully automates the mini-setup process with the unattend.xml configuration file. It builds the appropriate file or uses one that is supplied, inserting information automatically into the file, including the product key, organization name, networking information, and domain credentials. Incorporating this functionality increases OSD’s flexibility by eliminating the need to maintain multiple Sysprep files supporting multiple deployment scenarios.

Using OSD fully automates and completely integrates the many details of using the tools in the ADK. You can also use it to manipulate images outside OSD. The tools in the ADK follow:

WinPE: A mini-operating system based on Windows 10, WinPE includes support for networking, Windows Management Instrumentation (WMI), VBScript, batch files, and database access. Its advantage is that it is much smaller than the full-blown OS, loads from a read-only disk, and runs in a RAM disk (a minimum of 512MB of memory is required for the version of WinPE included with and used by OSD in ConfigMgr) suitable for booting from a CD/DVD or over the network using PXE. OSD uses WinPE as a boot environment, ensuring that the currently installed operating system will not interfere with the deployment process.

Windows System Image Manager (WSIM): This GUI tool builds unattended answer files for Windows. You do not need to worry about the syntax of the answer file because WSIM graphically presents all available options and generates the unattend.xml file for you. This same file format is utilized for Sysprep files used by the mini-setup to complete setup of Windows systems.

Deployment Image Servicing and Management: This command-line tool manually services and manages Windows and WinPE images. Servicing changes an image’s content; managing involves listing the content of the image file or combining two image files together. Servicing specifically includes adding updates and drivers to the image; OSD uses DISM for both. Images can be offline or online; offline can be in a Windows Imaging (WIM) file or extracted to disk, making managing many aspects of Windows seamless, regardless of where the OS is located or its state.

Microsoft ties the ADK to the version of Windows you are using but makes it backward compatible; for example, the Windows 8 version of the ADK works with Windows 8 and Windows 7, so the question is when to upgrade the ADK. The authors recommend upgrading when you upgrade Windows; this lets you keep everything tightly integrated with support for the current version and backward compatibility with older versions of Windows that are not yet upgraded.

The information USMT captures is highly customizable by modifying or creating a series of Extensible Markup Language (XML) configuration files that describe the files, folders, and Registry entries to capture; you can specify exact filenames and Registry locations or perform wildcard searches to locate data or settings in these files. USMT uses these configuration files to capture all specified data and settings and place them into an archive used to restore to a destination system. To accomplish this, USMT uses the following tools:

LoadState.exe

ScanState.exe

As their names imply, ScanState.exe captures the data and settings whereas LoadState.exe restores them.

Who: Who are you deploying Windows to—or for? To your entire organization or a subset? Who initiates deployment to each system? End users, field technicians, you, or someone else?

What: What OS are you deploying? What version and edition? Do different users or systems get different versions or editions? What applications will be deployed with the OS? Will they differ for different user or system roles? Are there other customizations to make to the OS or applications? To which hardware models are you deploying?

When: When will you deploy? Do you need to meet a deadline? Are you going to deploy during the day or after hours?

Other: Do you care about user data? How does your organization update Windows and other software? What other desktop standards must be part of a Windows deployment?

These questions and their answers will guide your efforts; the answers provide a blueprint for your Windows rollout. Depending on your organization, you may not be able to answer all these questions yourself, and it may take time to gain consensus from all the key players. Knowing the answers ahead of time will save you work or rework later.

When you understand the requirements and are equipped with the answers to the previous questions, you can move forward. The following items may assist in this planning process:

Preparation: You need to start gathering the needed resources, importing them into your ConfigMgr lab, and performing any necessary ConfigMgr changes to meet those requirements. Resources include OS source media, application source files, drivers, configuration scripts, test systems, and storage space. Many of these must be imported into ConfigMgr for use in OSD. Based on your organization’s physical nature, you may need to add site systems or modify current site systems. For example, to support PXE, you may need to add that role to your DPs as well as modify the network to allow PXE packets to cross routers.

Creation: The core of the OSD process is putting in place all the requirements to deploy Windows. This part of the process is usually the second-most time-consuming step. It involves taking all the information gathered so far and putting it together to form a Windows image you can use for testing. This is often a repetitive process, involving building a basic structure, testing, adding to the basic structure, testing again, and so on. As requirements change, the repetitive process continues even after implementing OSD into production.

Testing: This is the most time-consuming process of OSD. It is a self-explanatory step that is often overlooked and rarely given the time or attention it deserves. So many different permutations and factors exist even in smaller and simpler environments that you can probably never test all of them; however, not properly and thoroughly testing as many as possible results in poor results, lost data, and sleepless nights. Test against every scenario and hardware model possible for your organization. While it may seem that much of your time is watching progress bars or waiting for the OS image to download, without this testing, you will never actually know if your design work will result in the desired outcome of properly deployed Windows that meets all your requirements.

Be sure to perform all your imports and testing in a lab environment. You may find that you did not need all those drivers after all, or maybe you do not need to modify your WinPE image. Once testing is complete and you have a successful image, move all the needed items over to your production hierarchy.

The wizard has seven pages, three of which are the standard Summary, Progress, and Completion pages included in all ConfigMgr wizards. The following sections cover the pages that are unique to this wizard.

Import All Drivers in the Following Network Path (UNC): Use this radio button to import a number of drivers at once. The path you specify to the folder containing the drivers must be in Universal Naming Convention (UNC) format; you cannot specify a drive letter. Some hardware manufacturers create a file with all the drivers for a specific model of their hardware; once this file is expanded to a folder containing all the drivers, you can use this option to import all those drivers at once.

Import a Specific Driver by Specifying the Network Path (UNC) to its .inf or txtsetup.oem File: If you need to test a specific driver and not a whole package, use this option to import that single driver. Again, the path must be a UNC path and point to an .inf file or a .txtsetup.oem file. These two file types are part of the driver files you download.

Specify the Option for Duplicate Drivers: This dropdown menu allows you to select how the import wizard should handle a duplicate driver. These are the options:

Import the driver and append a new category to the existing categories.

Import the driver and overwrite the existing categories.

Do not import the driver.

This page includes a lot of information, and the more drivers you add, the busier it looks. The first part of the page shows the path location from where the drivers will be imported. Two check boxes follow:

Hide Drivers That Are Not in a Storage or Network Class (for Boot Images): Select this check box to allow the user to filter out drivers that would not be used in a boot image.

Hide Drivers That Are Not Digitally Signed: This is checked by default. If a driver is not digitally signed, it should not be loaded; this is a security precaution.

The middle of the page contains a list box listing the drivers found by the wizard. If you chose to install a single driver, details are shown for that driver only. There is a check box beside each driver; all are checked by default. To skip importing a driver, uncheck its box. The list box also shows the class, architecture, version, and whether the driver is signed.

The following options are available at the bottom of the page:

Enable These Drivers and Allow Computers to Install Them: This check box determines if the driver is enabled or disabled after the import completes. Uncheck the box to disable the drivers so they are not usable when the import finishes.

Assign This Driver to One or More Categories for Filtering: This option allows you to choose an existing category or create a new one to which to add the drivers. You can either create a new category or click Categories to see categories already created and choose one.

The driver packages are in the list box; choose one or more or all. At the bottom of the list box, click New Package to create a new package if you are not using any existing packages.

Pre-create a driver package by navigating to Software Library -> Overview -> Operating Systems -> Driver Packages and choosing Create Driver Package from the ribbon bar or after right-clicking Driver Package. You get a dialog box where you enter a name, comment, and the path of the package, using UNC format. The path specified must be an empty folder. This is not the path you imported the drivers from or will import them from; it is the source location used to populate the DPs. From the same menu, you can also choose to import a driver package.

The middle of the page displays a list box showing all boot images. None are checked by default. Place a checkmark next to each image into which you want to inject the drivers. You can choose more than one boot image. If you do not want to inject drivers into a boot image, leave its check box unchecked.

After importing the drivers, you must distribute the driver package or packages; if you are injecting drivers into the boot image or images, they also must be distributed to DPs. Right-click the driver package or boot image and choose Distribute Content to open the Distribute Content Wizard, where the only page allows you to choose the DPs to which to distribute the content. The authors recommend choosing all DPs if using OSD in multiple locations.

Data Source: Enter the full path to the OS image you want to add. The path must be a UNC path that points all the way to the .wim file. You do not need to create a unique folder for each WIM file, as the path must point to the actual file. If you are not using unique folders, the authors recommend assigning a complete and descriptive name for each .wim file so you can distinguish between them.

General: Define the name, version, and comments about the WIM image you are adding. The name is automatically filled in based on what is in the WIM; change it to anything you want.

After adding the OS image to ConfigMgr, you must distribute it to your DPs to be available for use in OSD. Right-click the image and choose Distribute Content to open the Distribute Content Wizard; the only page asks you to choose DPs to which you want to distribute the content. The authors recommend choosing all DPs if using OSD in multiple locations.

Data Source: Enter the path to the Windows source files used for the upgrade. These should be the files from your Windows install media. The path must be a UNC and point to the folder containing setup.exe.

General: Define the name, version, and comments about the upgrade package you are adding. The name is automatically filled in, based on the name of the source folder name; you can change this to anything you want for the name.

When the OS upgrade package is added to ConfigMgr, distribute it to your DPs to be available for use in OSD. Right-click the package and choose Distribute Content to open the Distribute Content Wizard; the only page allows you to choose the DPs to which to distribute the content. The authors recommend choosing all DPs when using OSD in multiple locations.

After adding your OS images and/or OS upgrade packages to ConfigMgr, you must update them when new security updates are released. The authors recommend updating quarterly. Navigate to Software Library -> Overview -> Operating Systems -> Operating System Images or Software Library -> Overview -> Operating Systems -> Operating System Upgrade Packages. Select the image or upgrade package and choose Schedule Updates to launch the Schedule Updates Wizard, shown in Figure 22.6. This wizard has five pages, the last three of which are the standard Summary, Progress, and Completion pages. You must complete two pages:

Choose Updates: This page is filled in automatically, though it might take several seconds or longer for this to occur. ConfigMgr opens the image or update package and compares it with known software updates. It determines which updates are needed and shows them in the list box on this page. Uncheck any of them that you do not want to apply.

Set Schedule: Decide when to apply the software updates; either select to apply them as soon as possible or set a custom date and time. You can also choose to stop applying updates if an error occurs or continue regardless of errors, and you can update the DPs after the process has completed.

WinPE is ideal because it is small, easy to deliver, and fast, and it runs from a RAM disk without needing persistent storage. It also shares the core kernel and driver model with Windows itself, can run any valid native Windows executable, and provides much of the same automation-enabling functionality, including batch scripting and VBScript.

The default boot images work for most organizations for OSD requirements, but there may be a time when you need to add a separate boot image to ConfigMgr. This is fully supported—but only when you use a boot image based on a supported version of WinPE:

WinPE 10: This version of WinPE is part of the Windows 10 ADK and installed as a prerequisite for ConfigMgr. It is also the version of WinPE on which the default boot images are based. This version is customizable from within the ConfigMgr console.

WinPE 5: This version comes from the Windows 8.1 ADK. It cannot be customized from the ConfigMgr console. The boot images are supported but must be customized elsewhere, using the version of DISM installed with the Windows 8.1 ADK.

WinPE 3.1: From the Windows Automated Installation Kit (AIK) supplement for Windows 7 Service Pack (SP) 1, this version is an upgrade to the Windows 7 AIK. You cannot customize it in the ConfigMgr console.

For complete information on how to customize older versions of WinPE, see https://docs.microsoft.com/sccm/osd/get-started/customize-boot-images.

To add a boot image to ConfigMgr, navigate to Software Library -> Overview -> Operating Systems -> Boot Images. Choose Add Boot Image from the ribbon bar or after right-clicking Boot Images to launch a five-page wizard. The last three wizard pages are the standard Summary, Progress, and Completion pages. The other two pages have items you must fill in:

Data Source: Enter the path to the boot image you want to add. The path must be in UNC format and point to the actual .wim file.

General: Define the name, version, and comments about the boot image you are adding. The name and version are filled in automatically, although you can change the name to anything you want. The authors recommend adding comments to explain what this boot image is for, to avoid confusion with other boot images.

After adding or customizing a boot image, it must be distributed before being used by OSD. Right-click an image and choose Distribute Content to open the Distribute Content Wizard, whose only page allows you to choose the DPs to distribute the content. The authors recommend choosing all DPs if you plan to use OSD in multiple locations.

View a boot image’s properties by right-clicking it and choosing Properties to open the Boot Image Properties dialog box. Figure 22.7 displays the Customization tab selected.

While you can create completely custom boot images from scratch, this generally is not necessary as the built-in boot images are sufficiently customizable to meet nearly any need. The following customizations are available in the Customization tab shown in Figure 22.7:

Prestart Commands: Prestart commands run before the OSD process. They are typically used to display information and prompt the interactive user for input such as the system’s location, desired name, or role. There are no predefined prestart commands; this type of customization is completely up to your needs and abilities. In general, any valid Windows script (batch, VBScript, Jscript, or PowerShell script) will work. Prestart commands often require additional files, such as executables or scripts that are not part of the default boot image. Add these files by specifying the folder containing them in the Properties dialog. Using this section to add files to the boot image is helpful even if not using a prestart command; these could be diagnostic scripts that help in troubleshooting. Add cmd/c to the start of the command line that runs any program; otherwise, the command will not close after it runs, forcing the deployment to wait for the command to finish and putting you in a loop where nothing else starts.

You can also enter prestart commands when you create specific boot media, which means you can create the media and commands at the same time. More information about the prestart commands can be found at https://docs.microsoft.com/sccm/osd/understand/prestart-commands-for-task-sequence-media.

Windows PE Background: Specify an image to use as the background during OSD instead of the default provided by Microsoft. You can customize the background to your organization’s logo and color scheme, for example, so users know the OSD process is from your organization.

Windows PE Scratch Space (MB): This is temporary RAM-based storage used by WinPE applications that need to write temporary files. WinPE points the application to this area, and the application sees it as a hard drive to write the files it needs.

Enable Command Support (Testing Only): Check this check box to launch a command prompt anytime during the OSD process by pressing F8. This is useful for troubleshooting. When the process is working correctly, the authors recommend unchecking this box so users are not able to open the command prompt.

The Drivers tab is another area you might want to customize in the Boot Image Properties dialog. It allows you to inject drivers into the image so they can be used at boot time. Click the yellow starburst icon to bring up the Select a driver dialog box, which lists all the drivers imported into ConfigMgr and allows you to pick drivers to add to the image. The authors recommend using only boot-critical drivers, such as network and mass storage drivers. Ensure that the drivers you are adding match the architecture of the boot image: x64 drivers for an x64 image, x86 drivers for an x86 boot image.

After making any changes to your boot images, update the DPs by right-clicking the boot image and choosing Update Distribution Points; if the boot images have not been distributed to the DPs, choose Distribute Content.

Figure 22.8 shows several different TSs you can choose from. Each presents some different pages as well as some of the same pages as in the Create Task Sequence Wizard.

Task Sequence Information: Provide a name and description. The page also allows you to pick a boot image; click Browse to bring up a list of boot images to choose from. Select a boot image whose architecture will work on the destination hardware, such as an x64 boot image for x64 hardware; do not pick an x64 boot image for x86 hardware.

Install Windows: Choose an OS image package to deploy, the image index if the image has more than one, and whether to partition and format the target computer before installing the OS. A check box allows you to configure the TS for use with BitLocker encryption software. Enter your product key and server licensing mode. At the bottom, choose to use a randomly generated password for the administrator account and disable the account or enter a password and enable the account.

Configure Network: Specify your connection to a domain or a workgroup. If choosing a workgroup, enter its name; for a domain, enter the domain and organizational unit (OU) in which to create the computer account. Click Browse to select these settings if you do not want to enter them manually. The last option is to enter an account with permissions to join the machine to the domain. Use Set to search for an account to use or enter it manually in the format domainuser.

Install Configuration Manager Client: Enter the parameters needed to install the ConfigMgr client. There are two settings: Package and Installation properties. The information is prepopulated from the site’s client push settings; change these to any valid settings you like.

State Migration: Specify some of the basic configuration for using the state migration tools. Use a check box to capture users’ settings or not; if this box is checked, choose the USMT package to use (this is prepopulated). You can also specify using a state migration point (SMP) to save user files and settings, or you can capture and store it locally by using hard links. Choose whether to capture network and Windows settings.

Include Updates: Specify whether to have software updates installed as part of the OSD process. Choose to install the required mandatory software updates only, to install all software updates, or not to install any software updates.

Install Applications: Add applications to install into the TS. Use the yellow starburst icon to select from a list of applications; choose as many as needed. A check box allows the TS to continue installing applications if one of the applications fails to install.

After creating your TS, edit its properties to verify that the correct boot image is selected, among other items. Edit the properties by right-clicking the TS and choosing Properties or highlighting the TS and then choosing Properties from the ribbon bar.

General: Use this tab to change the name of the TS, add a description for the TS, add a category for the TS, and choose between using the default text Running: <task sequence name> or creating a custom text entry to show the user when the TS is executing.

Advanced: This tab has several options you can select:

Run Another Program First: This check box is valid only for TSs started while in an existing OS. It runs the specified program from the specified package before executing the TS if the program has not been previously run on the system. If the Always run this program first option is selected, the specified program is always run, regardless of its previous run status or result.

Suppress Task Sequence Notifications: Checking this check box turns off any notifications to the user that the TS is available for execution.

Disable Task Sequence on Computers Where It Is Deployed: You can select this option to disable the TS.

Maximum Allowed Run Time (Minutes): The number of minutes specified for this option is used when calculating whether a TS should run in an available maintenance window. If a TS exceeds this time, it is terminated.

Use a Boot Image: Choose the boot image to use for this TS. For non-OSD TSs, such as those used to deploy applications or a complex series of ordered tasks that may involve some advanced conditional logic available in a TS, you can choose to use no boot image.

Run on Any Platform or Run Only on the Specified Platforms: Use this option to limit the platforms on which a TS can run. Choose from a series of Windows versions or choose to run on any platform.

System Preparation: Select the package that contains the appropriate version of Sysprep to use to capture the reference computer’s settings. This page is grayed out for Windows Vista or later because Vista was the first version of Windows to automatically include Sysprep as part of the OS.

Image Properties: Add information about the image in terms of who created it, what version it is, and a description of the image.

Capture Image: Enter the details of where the captured image is stored. The path is entered as a UNC (\<servername><sharename><filename>); click Browse to select the path to avoid entering it manually. The account you enter must have permissions to access the share and the folder where the image is created. Full admin permissions are not required but suggested by the authors to help prevent problems with the capture process.

These TSs use the same pages that the Install an existing image package page uses except for the following pages that are removed from the TS:

State Migration

Include Updates

For more in-depth information on this TS and about how to use VHDs within ConfigMgr, reference https://docs.microsoft.com/sccm/osd/deploy-use/use-a-task-sequence-to-manage-virtual-hard-disks.

Use the Upgrade the Windows Operating System page to select an upgrade package to use; the middle of the page then shows the package’s OS version, edition, language, and architecture. This allows you to verify that you selected the correct upgrade package to use. At the bottom of the page is a dropdown menu to choose the correct index of the Windows edition you want to use. You can enter your product key as well. Figure 22.9 shows the upgrade TS created with this wizard in Edit mode.

The TS adds in a Pre-Upgrade group and a Post-Upgrade group that allow the upgrade to Windows 10 to occur with checks and balances:

Prepare for Upgrade: This adds the step Check readiness for upgrade to the TS to ensure the target system has enough memory, processor speed, and free disk space to meet Windows 10 prerequisites. If the target system does not meet these standards, the TS fails. You may need to modify the settings for your organization’s standards. You can add additional steps to uninstall applications, drivers, or other items known to not be compatible with Windows 10.

Post-Processing: Add applications, drivers, or other items to install after the upgrade finishes.

Rollback: This is added by default and should not be removed. If an error occurs during the upgrade, the TS variable _SMSTSSetupRollback is set to True. This step has a condition to check that variable; if it is set to True, the TS rolls back the upgrade to the previously installed OS. If there are additional steps you need to take after that rollback occurs, add them to this group.

These custom TSs are usually created for non-OSD tasks that typically must be executed in a particular set of steps. These TSs are the perfect solution for those deployments. For more information about steps to add to these custom TSs, see https://docs.microsoft.com/sccm/osd/understand/task-sequence-steps.

To edit a TS, navigate to Software Library -> Overview -> Operating Systems -> Task Sequences and right-click the TS, or select the TS, and from the ribbon bar choose Edit to launch the TS editor. Figure 22.10 shows the TS editor for a TS created using the Install an Existing Image Package Wizard.

To add a group or a task, select the Add menu item. Tasks are divided into seven categories, with tasks under each one. Figure 22.11 shows the first of these built-in categories and the tasks in the General category.

When you add a task to the TS (see the “Add Condition” bullet in the Options tab discussion that follows), the editor adds the task below the current highlighted step. Each task has its own set of parameters that must be filled for the task to execute correctly. When a task is added to the TS, it shows an icon with a red X beside the name, indicating that it has a required parameter that must be completed; once all parameters are filled in, the icon turns into a green checkmark, indicating that the step is ready to execute. Each task has two tabs:

Properties

Options

The Properties tab contains all parameters that must be completed for the task to become execution ready. In-depth information on each task and its parameters can be found at https://docs.microsoft.com/sccm/osd/understand/task-sequence-steps.

The Options tab generally has the same settings for each task; sometimes there is an additional parameter, but none are required. The Options tab always has the following items:

Disable This Step: Allows you to disable the step so it is not performed when the TS executes. A common use for this is when you are creating a TS and are not sure if all steps need to be performed.

Continue on Error: Allows the TS to continue running if the step that is running fails. The error is logged in the SMSTS.log file, and the TS continues to the next step. This is handy for troubleshooting issues when a step in the TS keeps failing but you need to execute the rest of the TS.

Add Condition: Allows you to add logical conditions to the step. If a condition evaluates to true, the step executes; if the condition is false, the step is skipped. The most common use for conditions is when installing drivers. For example, you may have a driver package for each model of system you are deploying. You would want to check the model number of the system to see if the drivers should be applied.

Conditions can be combined by using If statements to form a master conditional statement. This is a collection of substatements that evaluate to either True or False, based on the logical evaluation of those substatements. There are three types of master statements, and each type of evaluation affects how the master statement is evaluated:

All child statements must be true.

Any child statement is true.

No child statements are true.

You can chain If statements together to form complex logical statements. If statements in this context closely resemble the traditional logical operators AND/OR, and can be used in a similar way.

Action: These variables specify parameters for specific tasks. The variable is used by a single step in the TS and is initialized before the step is run and is only available while the step is running. The value for the variable is removed after the step finishes. Nearly all action variables are directly editable using the task sequence editor.

Custom: This is a simple name/value pair that you can define as you see fit.

Built-in: These variables are almost always read-only. They start with an underscore and are automatically generated by the TS; they generally describe the environment where the TS executes. The value of the variable is available throughout the entire TS.

Find a full list of TS action variables at https://docs.microsoft.com/sccm/osd/understand/task-sequence-action-variables and a list of the built-in variables at https://docs.microsoft.com/sccm/osd/understand/task-sequence-built-in-variables.

Each GUI field shown in a task in the TS editor has a corresponding TS variable. Setting these values in the GUI defines the action’s runtime behavior, making your TS static for the most part. Setting TS variables based on collection membership or using a script while executing the TS makes your TSs dynamic, performing tasks differently or even performing different tasks based on runtime conditions. You can set action variables and custom variables in a number of ways:

Use a Set Task Sequence Variable task.

Statically assign one to a specific computer resource.

Statically assign one to a collection.

Use the Microsoft.SMS.TSEnvironment COM object in a script or other COM-aware tool, development environment, or language. See http://msdn.microsoft.com/library/cc145669.aspx for more information on using this COM object; the page refers to ConfigMgr 2007 but also applies to ConfigMgr Current Branch.

You can also set a TS variable on a device collection or computer resource in the ConfigMgr console. For device collections, open the collection’s Properties page and navigate to the Collection variables tab; for computer resources, open the resource’s Properties page and select the Variables tab. TSs initiated on applicable resources will have all variables initially set. If you leave the value of a collection or computer variable blank, the built-in TS UI prompts the user for values for these empty variables.

Finally, there is an order to the precedence of TS variables:

1. Task sequence variables set at runtime (using a Set Task Sequence Variable task or the Microsoft.SMS.TSEnvironment COM object)

2. Task sequence variables set on computer resources

3. Task sequence variables set on collections

4. Task sequence variables set at design time in the GUI

Distribution Point

PXE Point (part of the DP role)

Multicast (part of the DP role)

State Migration Point

Applications

Boot images

Driver packages

Operating system images

Operating system upgrade packages

Software distribution packages

Software update deployment packages

While the system is executing the TS, it requests these types of content as needed. The content is downloaded from the DP to the local client and processed according to the step in the TS. Not all of the package may be used; it depends on the tasks in the TS.

Starting with ConfigMgr 2012, the PXE point is included as part of the DP properties. Install PXE and configure it by navigating to Administration -> Overview -> Distribution Points; then either right-click the DP name and select Properties or select the DP and from the ribbon bar, choose Properties, and click the PXE tab. Figure 22.12 shows the PXE tab of a DP’s properties.

The first step in installing and configuring the PXE point is to check the box Enable PXE support for clients. You see a warning popup dialog box, as shown in Figure 22.13. The warning explains that PXE uses certain ports to transfer packets across the network. These ports must be open to allow traffic through the firewall on systems and routers for PXE to work correctly. If you are using a Windows firewall, ConfigMgr opens the ports for you. Click Yes in the warning dialog box to be presented with the PXE tab to configure; click No, and the checkbox remains unchecked with the rest of the PXE tab grayed out.

The PXE tab has several other items to complete:

Allow This Distribution Point to Respond to Incoming PXE Requests: Checking this box sets up WDS on this DP/PXE point to respond to any incoming PXE requests. Unchecking it stops or disables the ability to answer incoming PXE requests.

Enable Unknown Computer Support: Checking this option allows the WDS/PXE server to respond to incoming requests from systems not managed by ConfigMgr. A system without the ConfigMgr client installed or discovered by ConfigMgr is an unknown system. In OSD terms, these typically are bare-metal systems without an installed OS. If this option is checked, you see a warning popup dialog box, as shown in Figure 22.14, explaining that when these types of systems PXE boot, they can run any of the deployed TSs to the unknown computer collection. This could result in formatting the hard drive and losing data. Click OK to turn on this support.

Require a Password When Computers Use PXE: Selecting this option requires a password for the system to complete a PXE boot; the boot aborts if the password is not returned by the user of the system. If this option is enabled, you must enter your password and confirm it in the second box. This is a good way to prevent users from PXE booting and running a TS that is not meant for them.

User Device Affinity: For this option, you can select one of three options: Do not use device affinity, Allow user device affinity with manual approval, or Allow user device affinity with automatic approval. Device affinity allows you to marry a user to a single device. For more about this, see https://docs.microsoft.com/sccm/osd/get-started/associate-users-with-a-destination-computer.

Network Interfaces: This option allows you to specify that either all NICs respond to the PXE requests or only specific NICs respond, assuming that you have multiple NICs on this DP/PXE server. If you choose to use specific NICs, use the yellow starburst icon to open a dialog box where you can enter the media access control (MAC) addresses of the NICs you want to respond.

Specify the PXE Server Response Delay (Seconds): Use this option to delay the response from this PXE point to the incoming PXE request. If you have multiple DP/PXE servers, you might want to establish a precedence for which responds first. This setting allows you to tune the response from each DP/PXE server. It is not an exact way to set prioritization, but it does work.

How exactly does PXE work? At a high level, the steps are as follows:

1. The system boots, and because no OS is installed or the user presses the F12 key, the NIC attempts to get a DHCP address and start the process of PXE booting; the PXE packet is sent to the DHCP server.

2. The PXE-enabled DP sends back a packet that contains the boot filename and location along with the WDS network boot program.

3. The client opens a session and starts transferring boot files from the server.

4. The system boots into WinPE, and the TS boot shell is started from the SMS folder that is in the WinPE image.

For more detailed information about how PXE works and several processes in-between these steps, see the complete walkthrough at https://support.microsoft.com/help/10082/troubleshooting-pxe-boot-issues-in-configuration-manager-2012. This article is for ConfigMgr 2012 but also applies to ConfigMgr Current Branch.

Multicasting is configured as part of the DP properties; you can install multicasting and configure it by navigating to Administration -> Overview -> Distribution Points and right-clicking the DP name and selecting Properties or selecting the DP and from the ribbon bar choosing Properties and clicking the Multicast tab. Figure 22.15 shows the Multicast tab of a DP’s properties.

Once the box is checked to enable multicast to simultaneously send data to multiple clients, the following options are available:

Multicast Connection Account: This account, which by default is the local machine account, is used to communicate with the site database. If you choose to use a different account, Set becomes available, and you can select between using an existing account ConfigMgr already knows about or using a new account.

Multicast Address Settings: Use the default range of IPv4 addresses from a DHCP server or enter an IPv4 address range to use.

UDP Port Range for Multicast: Choose the User Datagram Protocol (UDP) range of ports you want to use. The default set of ports is entered automatically but can be changed. Remember that no matter what ports you set, they must be allowed through any firewalls or routers.

Client Transfer Rate: Set the speed at which the content is downloaded. Take care to ensure that not all of the bandwidth is consumed on the network.

Maximum Clients: Set the maximum number of clients that can download content at the same time.

Enable Schedule Multicast: Control the schedule at which systems are allowed to download the content. When this option is checked, you can set the session start delay time, which is 15 minutes by default. This is the amount of time set aside before the first clients start to download the content. The minimum session size also becomes available; it is 20 by default but can be changed. This is the number of clients that must request the content before it is available for download.

While there are many options on this page, most organizations can enable multicasting and leave all settings at their default values.

If you intend to use multicasting, the next step in the process is to enable the OS image packages and any packages used during WinPE to use multicast. Navigate to Software Library -> Overview -> Operating Systems -> Operating System Images and select your OS image. Then choose Properties either from the ribbon bar or after right-clicking on the OS image. Select the Distribution Settings tab of the properties dialog that appears. At the bottom of the page, look for the Operating system deployment settings section, which offers these options:

Allow This Package to Be Transferred via Multicast (WinPE Only): Allows the OS image package to be transferred to the client by multicast. If this option is unchecked, multicast is not used.

Encrypt Multicast Packages: Allows ConfigMgr to encrypt the data in packages sent by multicast. Packages sent via multicast go over the network in clear text; if they have any sensitive information, the authors recommend checking this box.

Transfer This Package Only via Multicast: Allows the package to be transferred only via a multicast session. The image package cannot be downloaded by any other method.

SMPs can be installed on new servers added to the ConfigMgr hierarchy or on existing servers such as DPs that are already part of the hierarchy. There are some considerations to take into account when deciding where to put your SMP:

User State Size: User state data usually consists of the user’s data stored in the Documents folder. This is a mix of documents, pictures, music, and other data, and it could be quite large, depending on the organization’s policy for user data. For example, if you include Outlook Personal Store (PST) files, this can be many gigabytes of data. How many migrations will occur at the same time? These all must be taken into account when considering the amount of space to allocate for the SMP.

Retention Policies: These policies deal with the amount of time to keep user data on the SMP. It may not be as simple as capture the data, restore the data, and then delete it. What happens if a user has issues a day or a week after the data was deleted? How do you deal with a user who says not all the data has been restored to the new system? Consider these questions when determining how much space is needed and how long that space will be in use on an SMP; you may determine that you need to place SMPs in different locations or even on separate servers.

After gathering the SMP information, answering the questions, creating the policies, and creating the SMP’s server layout, you can install the SMP. Navigate to Administration -> Overview -> Site Configuration -> Servers and Site System Roles. If adding the role to an existing server, highlight that server and either right-click it and choose Add Site System Roles or from the ribbon bar choose Add Site System Roles. If adding the SMP role to a new server to the ConfigMgr hierarchy from the ribbon bar, choose Create Site System Server. Both options launch a wizard with very similar pages:

General: Click Browse and select the FQDN name, add a site code from a dropdown list, select an FQDN for the system to use if it will be on the Internet, define whether the site server will initiate connections to this site system, and choose what site system installation account to use. If adding the SMP role to an existing server, some fields are grayed out.

Proxy: This page allows you to define what proxy to use if one is needed.

System Role Selection: This page lists all roles that can be installed on this server. If using an existing server, roles that are already installed on the server do not display. Place a checkmark in the box for State Migration Point.

State Migration Point: As shown in Figure 22.16, this page allows you to configure options for the SMP. You must complete three options:

Folder details: Define the folder to use for SMP data. Clicking the yellow starburst icon allows you to choose a folder location, which must already exist. You can also select the maximum number of clients and the minimum amount of free disk space.

Deletion Policy: Select when you want to remove the SMP data marked for deletion: immediately or after a certain number of days or hours.

Restore-Only Mode: Set the SMP in a restore-only mode so no new SMP data can be written to it. This might be useful when disk space is filling up. You can turn this on, wait for data to be restored, and delete the data and turn it back off.

Boundary Groups: This page allows you to associate an SMP to a boundary group so clients know which SMP to use. The Add and Create choices allow you to add a previously created boundary group or create a new boundary group.

The final three pages of this wizard are the standard Summary, Progress, and Completion pages.

There are six pages to the wizard; the last three are the standard Summary, Progress, and Completion pages. The following are the unique pages:

General: This page provides information only, and there is really nothing to configure. It shows the TS you selected, and at the bottom a check box is automatically checked to allow detection of any associated content dependencies to the TS.

Content: This is another information-only page. You might notice a slight delay in moving from the General page to this page; this is because of the content detection occurring in the background. This page shows all the content associated with the TS, and this content is now added to the distribution, which means you can distribute all the content at one time.

Content Destination: Select a collection, a DP, or a DP group to which to send the content by using the dropdown menu under Add. If you have DP groups, the authors recommend using that as your choice, to get the content to every DP in the group.

Depending on the content already distributed, the number of DPs to which you are sending content, the size of the content, and how many sites are in the hierarchy, it may take some time to finish distributing the content to the DPs. It is not unusual for a TS to need over 10GB of content. The images can be quite large, depending on what is actually in them. Before proceeding to the next step of deploying the TS, the authors recommend waiting for all the content to be distributed.

You may run into an issue with a low-bandwidth site where it takes too long for content to reach the DP. Solve this by prestaging the content. Select the TS in the console and choose Create Prestaged Content File from the ribbon bar to bring up a wizard that walks you through creating the prestaged content file. After creating the file, use other means to get the content copied over to the DP. When the file is on the DP, use the Extract Content tool to add the content to your DP. For more information about prestaging content, see https://docs.microsoft.com/sccm/core/servers/deploy/configure/deploy-and-manage-content#a-namebkmkprestagea-use-prestaged-content.

To monitor distribution status, navigate to Monitoring-> Overview -> Distribution Status and choose Content Status or Distribution Point Group Status. If you choose Content Status, you must search each content item and check its status. If you choose Distribution Point Group Status, highlight the DP group you select and choose View Status from the ribbon bar to open a status window where you see a pie chart, a list of content, and current status.

Task Sequence: Filled automatically with the name of the TS you selected to deploy. Change the default by clicking Browse.

Collection: Required; allows you to select the collection to which you want to deploy the TS. Click Browse to select a collection from the list. You can select only one collection.

Use Default Distribution Point Groups Associated to This Collection: This option is grayed out unless the collection you chose has been associated with a DP group. Associate a collection to a DP group by navigating to Administration -> Overview -> Distribution Point Groups and selecting the DP group, and then either from the ribbon bar or after right-clicking the DP group, choose Properties. In the Collections tab of the properties dialog, click Add to choose the collection to associate with this DP group. You can add as many collections as you like.

Automatically Distribute Content for Dependencies: This option is grayed out unless applications in the TS have a dependency assigned to them.

Comments: This is an optional field for entering comments about the deployment.

Purpose: Select whether the deployment is mandatory. There are two choices from a dropdown menu:

Required

Available

Require Administrator Approval if Users Request This Application: This option appears only when Purpose is set to Available. This option is usually grayed out for TSs that are imaging a device.

Send Wake-up Packets: This option appears only when Purpose is set to Required. If this option is checked, ConfigMgr uses its built-in Wake on LAN functionally to send the magic packet that wakes up the client. Before using this option, computers and the network must be configured for Wake on LAN.

Allow Clients on a Metered Internet Connection to Download Content After the Installation Deadline, Which Might Incur Additional Costs: This option appears only when Purpose is set to Required. Checking this option tells the client it can download content while using a metered Internet connection. Some Internet network providers charge based on the amount of data you send and receive with your Internet connection. The authors recommend that you not enable this option.

Make Available to the Following: This option allows you to choose to whom the TS is available. There are four choices:

Only Configuration Manager Clients: With this choice selected, any ConfigMgr client in the collection can see this deployment in Software Center. TS media and PXE booting systems are not able to see this deployment.

Configuration Manager Clients, Media, and PXE: With this choice selected, ConfigMgr clients can see the deployment in Software Center, and TS media and PXE-booted machines can also see the deployment.

Only Media and PXE: With this choice selected, TS media and PXE-booted systems can see the deployment, and ConfigMgr clients do not see the deployment.

Only Media and PXE (Hidden): With this choice selected, the deployment is hidden from the TS media and PXE-booted systems, making it an automated TS. You must set up your TS to be completely automated if you want to use this option.

For most OS imaging deployments, the authors recommend using the option Only Media and PXE to make the deployment available to TS media and PXE-booted systems only.

Schedule When This Deployment Will Become Available: Select the day and time for the TS deployment to become available.

Schedule When This Deployment Will Expire: Select the day and time when this TS deployment will expire.

Assignment Schedule: This option is available only if Purpose on the Deployment Settings page is set to Required. It allows you to set a schedule for when the TS deployment becomes mandatory. You can choose an exact date and time, or you can assign it to become mandatory as soon as possible, after a logon event, or after a logoff event.

Rerun Behavior: This option is available only if Purpose on the Deployment Settings page is set to Required. It provides a dropdown menu that allows you to choose how ConfigMgr will handle reruns of the deployment. These are the options:

Never rerun deployed program

Always rerun program (default option)

Rerun if failed previous attempt

Rerun if succeeded on previous attempt

Notification Settings: Choose what the user can see and run. There are two choices:

Allow Users to Run the Program Independently of Assignments: This option is available only if the Purpose setting on the Deployment Settings page is set to Required. If this option is checked, the end user can see this TS deployment in Software Center and run it at will.

Show Task Sequence Progress: This option allows the user to see the progress bar the TS shows when running each step of the TS. Unchecking this box allows the non-OSD TS to run silently.

Activities Performed Outside of the Maintenance Window: This option allows you to select between allowing software installation and system restarts to occur if the available time of the deployment falls outside a scheduled maintenance window assigned to the collection.

Write Filter Handling for Windows Embedded Devices: Check this box to commit the changes at the deadline or during a maintenance window. Windows Embedded Systems (WES) use an overlay to store changes made to the OS; those changes are removed when the device is restarted, and the device is restored back to its original state. When you check this box and the WES gets a TS deployment, the ConfigMgr client requires the WES to reboot and enter service mode, allowing only administrators to log in. ConfigMgr then executes the TS and restarts the WES back into normal mode.

Allow Task Sequence to Run for a Client on the Internet: This option allows a non-OSD TS to run on an Internet-based client. OSD imaging is not supported on these clients.

Threshold for Successful Deployment: This option is available only if the Purpose setting on the Deployment Settings page is set to Required. If this option is checked, you must choose the percentage amount that must be successful by a date and time you choose. If the percentage is not met by that time, an alert is generated inside the ConfigMgr console.

Threshold for Failed Deployment: When this option is checked, you can pick a percentage number for the failed deployments. When the deployments reach that failed percentage, an alert is generated inside the ConfigMgr console.

Download Content Locally When Needed by the Running Task Sequence: This option appears in a dropdown menu but is the only item on the menu. TS deployments always require the content to be downloaded locally to the machine running the TS.

When No Local Distribution Point Is Available Use a Remote Distribution Point: Selecting this option allows you to have the TS download content from a remote DP if the content is not found on a DP within its boundary. The authors recommend considering this setting carefully. OSD imaging content can be very large—10GB or greater in some cases. If the remote DP is across a slow network link, this could cause network errors.

Allow Clients to Use Distribution Points from the Default Site Boundary Group: Selecting this option allows the system to fall back to the default site boundary group to find and download content when a local DP within its own boundary group does not have the content available.

Allow Clients to Share Content with Other Clients on the Same Subnet: Selecting this option allows clients to use BranchCache for content downloads. If BranchCache is not installed on the clients, this item does not affect the content download.

Stand-alone media

Bootable media

Capture media

Prestaged media

To create the TS media, navigate in the console to Software Library -> Overview -> Operating Systems -> Task Sequences and either from the ribbon bar or by right-clicking Task Sequences, choose Create Task Sequence Media to launch the Create Task Sequence Media Wizard. This wizard has different pages, depending the type of media you choose to create; in all cases, the last three pages are the standard Summary, Progress, and Completion. Figure 22.20 shows the wizard.

Removable USB Drive: Create media using a USB drive plugged into the machine running the console; if you remoted into the site server, the USB drive must be plugged into that site server. Selecting this option makes the Drive box available so you can select the USB drive. You can also format the drive and make it bootable. One caution on using a USB drive: Be sure it is large enough to hold the full set of media. Stand-alone media includes all drivers, packages, applications, boot images, and the OS image. It is not unheard of for the stand-alone media to be 32GB or more.

CD/DVD Set: Choose the media size from a dropdown menu; 650MB, 4.7GB, 8.5GB, or unlimited. The sizes correspond to sizes of CD and DVD media. The thought is that you write the information to an ISO file and then burn the ISO file to CD or DVD for the machine to be booted with it. Before choosing the media size, have a good estimate of the content size. If the content is more than 8.5GB, you can make multiple files of the size you choose, or you can choose unlimited and create only one file.

Media File: This option, which is available when the CD/DVD set is chosen, allows you to click Browse and select a folder and filename to use. You can also enter the path and filename (ending with .iso) in the list box. If you did not start the ConfigMgr console with the Run as Administrator option and UAC is enabled, you may receive an error saying you do not have write permissions to the location. Solve this by right-clicking the console icon and choosing Run as Administrator.

The purpose of this page is to select the DP or DPs with all the packages you need to create the stand-alone media. It may be that all packages are distributed to all the DPs; in this case, you might end up selecting multiple DPs so that all of the content is covered.

Variables: At the top of the page, add any OSD variables you want to use. Clicking the yellow starburst icon launches a dialog box that allows you to add the variable name and value and then confirm the value. There is also a box that allows you to hide the value from the ConfigMgr console. For a refresher on OSD variables, see the “Using Variables” section, earlier in this chapter.

Enable Prestart Command: Checking this box enables a text box where you enter the command you want to run before the TS begins. There is also a check box to include any files you might need for the prestart command. Check this box to select the package that the files are in by using the Set option; click Browse to choose what DP that package is on so it can be downloaded by the stand-alone media installer. An example might be that you need to run a script to check the ConfigMgr database to see if the machine running the stand-alone media is already in the database. You might need to delete that entry for the TS to run correctly. More in-depth information is available at https://blogs.msdn.microsoft.com/steverac/2015/04/22/power-belongs-to-youthe-osd-prestart-command/.

Dynamic Media: Allows the media to query MPs to find the correct MP, based on the site boundary for the IP address of that system.

Site-Based Media: Allows you to pick an MP to use during the OSD process. That MP will be used until the ConfigMgr client is installed, at which point it will find an MP based on the site boundary information.

Enable Unknown Computer Support: Checking this option allows the bootable media to work with an unknown computer. In ConfigMgr, an unknown computer is any system without the ConfigMgr client installed or a system that has not been discovered.

Create Self-Signed Media Certificate: Checking this option allows the Create TS Media Wizard to create a self-signed certificate using the date and time you choose for the start and expiration dates. This certificate is included with the boot media used to authenticate the system running the bootable media with the MP, telling the MP this is a real client that needs access and not a rogue client. The default length of time for the certificate is one year; when the certificate expires, the boot media will no longer work. Using this option allows communication over HTTP.

Import PKI Certificate: Select this option to import a certificate from your organization’s certificate authority. Browse to select the certificate to import. You must include the password associated with the certificate you want to import. Using this option allows communication over HTTPS.

User Device Affinity: Use this option to choose how to set up device affinity for the user. User device affinity is the ability for ConfigMgr to understand which device is the user’s primary device. When this option is set for a device, that device becomes the user’s primary device. Applications or other items can then be targeted to the primary device. There are three options to choose from:

Do not allow user device affinity (default option)

Allow user device affinity pending administrator approval

Allow user device affinity with auto-approval

Boot Image: Pick the boot image you want to use for this media creation. Choose the boot image that will work with the systems you are imaging; for example, if imaging x86 systems, pick an x86 boot image.

Distribution Point: Choose the DP from which the wizard will download the boot image. When creating the boot media, the wizard must download the boot image to a local folder on the system running the console. If no DPs are shown when you click Browse, you must distribute the boot image content to your DPs.

Associated Management Points: The option varies depending on the option you selected on the Media Management page. If you choose Dynamic Media, a list box appears, allowing you to click Add to select multiple MPs for the boot media to use when starting communication. If you choose Site Media, the box is a single list box where you can click Browse to select a single MP to use for that initial communication.

The wizard has only two pages besides the standard Summary, Progress, and Completion pages—the Media type and Boot image pages. These pages are described earlier in this chapter for other media creations. The capture media contains the ConfigMgr binary files as well as the boot image that you selected in the wizard.

The wizard has several pages, some of which have been discussed before. The Task Sequence page of this wizard is the same page as the Stand-Alone CD/DVD seen in the wizard for stand-alone media. The following sections discuss pages of the wizard that are different.

Created by

Version

Comment

Media file

Image Package: Click Browse and select the image package that you want to use with this media.

Image Index: Sometimes an image WIM file contains multiple images, which are separated in the WIM file by different indexes. You see this mostly on OS images that come from the OS manufacturer. An example is the Windows 10 image file, which can contain the Home, Professional, and Enterprise versions in the same WIM file. Use this option to choose the index you want to use from a dropdown menu.

Distribution Point: Click Browse and choose the DP you want the wizard to use to pull the content from when creating the prestaged media WIM file.

Select Application

Select Package

Select Driver Package

Each page has a list box with Add and Remove choices to select from a list of applications, packages, and driver packages, allowing you to add those items to the WIM file. This allows the content to be stored locally in the WIM file so that if a step in the TS references it, the content is pulled from the local store and not from a DP across the network. It allows you to add tasks into the TS that will install applications, packages, and drivers without having the system connected to the network.

Success: Machines listed here are those that have successfully completed the OSD deployment. They report in green.

In Process: These machines are currently running the OSD deployment but are not yet finished. These are reported in yellow.

Error: These machines received the OSD deployment but ran into an error when trying to download the content or execute the deployment. Dig deeper by looking at the lower part of the page to see the asset details. One of the details is the error code returned from the client; use this as a starting point to look for the issue with that client.

Requirements Not Met: Machines in this state received the deployment but did not meet the rules that allow the deployment to run.

Unknown: All systems appear in this state after the deployment is created. When a system returns a state message, it moves out of this state. If you see machines in this state after the deployment runs for some time, they did not receive the deployment and could be broken clients.

The Monitoring view can help you understand the deployment status and where machines are in the process (successful or still work in progress), but if you need to dig a little deeper, reporting might be your next step. ConfigMgr has an extensive report library you can access by navigating to Monitoring -> Overview -> Reporting -> Reports.

With each version of ConfigMgr, the number of reports has increased, and Current Branch has 478 reports. Of these reports, 28 of them deal specifically with OSD and TSs. By default the reports are sorted by the Name column in the ConfigMgr console. To focus solely on OSD reports, click the Category column and look for Task Sequence. If using the SQL Server Reporting Services (SSRS) web interface, you see the reports divided between four categories:

Task Sequence-Deployment Status

Task Sequence-Deployments

Task Sequence-Progress

Task Sequence-References

Some of the 28 reports are more helpful than others. The authors recommend looking at the following 3 reports as a starting point:

Status Summary of a Specific Task Sequence Deployment: This report provides an overall summary of all resources targeted by the deployment.

History of a Task Sequence Deployment on a Computer: Use this report to view what the TS executed on the target system and the output or exit code. This is a good report when you are seeing issues with the TS running tasks on the target system, as it shows what tasks were completed and the status message IDs.

Summary Report for a Task Sequence Deployment: This report summarizes the number of systems that executed the TS, start and end times, and how many failed. While more of a 30,000-foot view, it is a great overall report if you just want a quick summary.

To enable command support, ensure that the box Enable command support (testing only) is checked. If you change the boot image here or in one of the other tabs, you must redistribute the boot image to your DPs before the change becomes active in WinPE. Once the box is checked and a system boots that boot image, pressing the F8 key on the keyboard opens a command window where you can run commands. For example, if you need to verify the IP address, you can run ipconfig /all in the window to return the IP information. A command that administrators commonly run to test network connectivity is the ping command. Use this command to verify that you can reach other network locations.

When creating TS media, the log file is CreateTsMedia.log, found on the site server in the ConfigMgr installation folder AdminConsoleAdminUILog. If on a remote machine running the console, the log is located in %ProgramFiles(x86)%Microsoft Configuration ManagerAdminConsoleAdminUILog. The filename is the same.

The log file when using TSs for deployments is SMSTS.log. This log file lives in different places, depending on the stage of the deployment process. It contains a detailed record of every TS-related action on the target system and usually contains any error that occurred as well as successful executions of TS steps. Referencing this file is the single most important step for troubleshooting a TS and should be the first thing you ask for when troubleshooting. Press the F8 key to open the command window to obtain the log. Table 22.1 shows the location of the log, depending the state of the TS.

TABLE 22.1 SMSTS.log File Locations

Deployment Complete	TS Status	ConfigMgr Client Installed	SMSTS.log Location
No	WinPE Running	N/A	Windows temp folder in WinPE X:WindowsTempSMSTS.log
No	Deployed OS Running with a TS running	Yes	SMSTSLog subfolder in the ConfigMgr client logs folder: C:WindowsCCMLogsSMSTSLogSMSTS.log
No	OS Setup running	No	SMSTSLog folder C drive: %_SMSTSMDataPath%LogsSMSTSLogsmsts.log
Yes	Deployed OS Running no TS is running	Yes	ConfigMgr client logs folder: C:WindowsCCMLogsSMSTS.log

You may need to check the SMSTS.log if the TS fails, but you may discover that the target system rebooted before you could access the file. An example of this might be when you are testing your TS; you initiate the sequence and then go home for the night, expecting to check it in the morning, only to find the system rebooted and is sitting at the network page. This probably means that the TS encountered an error, the machine waited the default 15-minute timeout and then rebooted, WinPE loaded, and you lost everything in the log about the error. The authors suggest that in such a situation, you reset the default time-out for when an error occurs. You can do this by adding a step to your TS that changes the value of the SMSTSErrorDialogTimeout variable. Figure 22.21 shows an example where the value is set to 86,400 seconds (24 hours). Changing the value for this setting should give any administrator adequate time to see the error and collect the logs for review.

TSs can get very long (200 steps are more); if this occurs, the log file rolls over, and you lose valuable information that might be needed for troubleshooting. You are left trying to reproduce the issue and catch log files before they roll over. You can change the parameters of the SMSTS.log file, which are hard-coded by default when WinPE boots. They are set in the WinPE Registry; press the F8 key to open the command window and type regedit.exe. In the Registry editor, navigate to HKLMSoftwareMicrosoftCCMLoggingTaskSequence, which shows you the following values about the logging for SMSTS.log:

LogDirectory=X:WindowsTemp

LogEnabled=1

LogLevel=0

LogMaxHistory=2

LogMaxSize=2097152

These values turn on logging and set the values; the ones you will want to change are LogMaxHistory and LogMaxSize, which modify the number of rollover logs and the size of a log. If you change these in the Registry, they will not take effect. The authors recommend changing the values using the SMSTS.ini file; this text file contains the settings you want for those Registry values. SMSTS.ini is read at WinPE boot time, before any TS runs and before the TS environment is built. The settings are usually the first line in your SMSTS.log file. Changing the values here allows your settings to be in place from the very beginning. The format of the file is very simple, just the settings you want to change:

Click here to view code image

[Logging]
LOGMAXSIZE=5120000
LOGMAXHISTORY=6
DEBUGLOGGING=1

Create a text file named SMSTS.ini, edit the file to include these options using the values you want to set, and save the file. Be sure the file is named SMSTS.ini, as sometimes when creating text files, the file may end up with an extra .txt extension (for example, SMSTS.ini.txt). Once the file is created, copy the file to the following two locations on your ConfigMgr site server:

<ConfigMgr_install_directory>OSDini386

<ConfigMgr_install_directory>OSDinx64

Now navigate to Software Library -> Overview -> Operating Systems -> Boot Images, select the boot image, and choose Update Distribution Points from the ribbon bar or after right-clicking Boot Images to start the process of creating an updated boot image. The process injects SMSTS.ini into the WinPE image and distributes the image to your DPs. If you have set up PXE booting with WDS, the image used when a machine PXE boots is also updated. If using more than one boot image, you must update the others as well. When the log values are working the way you want, you must still collect them. The blog entry at https://blogs.msdn.microsoft.com/steverac/2008/07/15/capturing-logs-during-failed-task-sequence-execution can help automate part of that process. Be aware that no matter how much automation you have, there will still be times when you must collect the files manually.

The SMSTS.log file is not the only log file created or updated during the OSD process. The Setup Windows and ConfigMgr task runs the Windows Setup program, which creates and keeps several logs updated throughout the process. The following logs are some of the ones that may be of importance when looking for solutions to problems:

%SystemRoot%Panthersetuperr.log

%SystemRoot%LogsDISMdism.log

%SystemRoot%LogsCBSCBS.log

%SystemRoot%DebugNetSetup.log

For more information about the Windows Setup logs, see https://support.microsoft.com/help/927521/windows-vista,-windows-7,-windows-server-2008-r2,-windows-8.1,-and-windows-10-setup-log-file-locations.

Once you have a log file, you need to view it. As it is a text file, you can use Notepad, but it will not be formatted for the best viewing. The preferred tool to view all ConfigMgr log files is CMTrace.exe, found in <ConfigMgr_install_directory>Tools. CMTrace was built by the ConfigMgr product team and is updated with each version of ConfigMgr. It is designed to present the ConfigMgr logs in a more readable format, showing the log text, component, date and time, and the thread that wrote the log entry, which is valuable because many ConfigMgr components are multithreaded. You can search up or down the log for information. Errors are highlighted in red and warnings in yellow. You can also choose your own words and colors to highlight those words. The error lookup tool, accessed from the Tools menu or by pressing Ctrl+L, allows you to enter the error code and returns the text message associated with that error.

A very useful but often overlooked feature of CMTrace is its ability to open multiple log files and merge them chronologically. This can be helpful if you need to trace the flow of an object across multiple components. Access the feature by opening CMTrace without any log files open and then select the open folder icon or choose File -> Open to see the list of log files; at the bottom of the page, select the Merge selected files check box to open the files as a single file and then arrange the lines by their date and time values.

IP address helper services are not running.

Ports on the routers or firewalls are not open to allow PXE packets across the network.

DHCP servers are not configured to process PXE boot packets.

Domain Name System (DNS) resolution is not working correctly.

The DHCP address pool is exhausted.

The PXE boot screen on the target system may also contain some valuable information. Figure 22.22 shows the boot screen for a virtual machine.

One often overlooked issue with clients having PXE boot failures is the IP address. A quick look at the PXE boot screen shows whether the client obtained a DHCP IP address. This screen also gives the IP address of the DHCP server it is talking to, its default gateway, the IP address of the WDS server, and the MAC address and GUID of the client system. Notice that it also says that ConfigMgr is looking for a policy. This is important because it determines whether the client is known or unknown to ConfigMgr. This is where the hardware identifier explained in the “Boot Image Command-Line Support” section, earlier in this chapter, comes in to play and allows you to PXE boot or not.

Many PXE issues are related to the network. One item that helps with some network issues is being able to change the default TFTP block and window size. If the default sizes are not working because of custom network changes, you may encounter time-out errors when trying to download the boot image. ConfigMgr now allows you to customize two settings:

TFTP Block Size: This is the size of the data packets sent by the server to the client downloading the file. A larger block size allows the server to send fewer packets, meaning fewer round-trip delays between the server and the client. However, large block sizes lead to fragmented packets, which are unsupported by most PXE client implementations. Change this value by locating the following Registry key on the PXE-enabled DP: HKLMSoftwareMicrosoftSMSDPRamDiskTFTPBlockSize; the default value is 4096 (4K). (If the key does not exist and you need to change the block size, you must create the key.)

TFTP Window Size: TFTP requires an acknowledgment (ACK) packet for each block of data sent. The server does not send the next block until it receives an ACK for the previous block. TFTP windowing is a feature in WDS that allows you to define how many data blocks fill a window. The server sends the data blocks back-to-back until the window fills, and then the client sends an ACK packet. Increasing this window size reduces the number of round-trip delays between the client and server, decreasing the overall time for downloading a boot image. To change this value, locate the following Registry key on the PXE-enabled DP: HKLMSoftwareMicrosoftSMSDPRamDiskTFTPWindowSize; the default value is 1. (If the key does not exist and you need to change the block size, you must create the key.)

The wizard may take several minutes to populate the page of updates, as it must scan the image to get the list of updates needed. This process relies on a working Software Updates installation in ConfigMgr. The wizard uses the synchronized software updates as a baseline to scan against so it knows what updates can be applied. It is key to synchronize the updates for the OS versions of the images being used. The offline servicing process works only for security updates for the OS; Microsoft Office updates are not applied. The wizard has the standard Summary, Progress, and Completion pages as well as two pages for user input:

Choose Updates: The list box in the middle of this page is populated with the updates applicable to the image you selected. How many are listed depends on how long ago the image was last updated. The older the image, the more updates it will need. Beside each update is a check box for you to select or deselect that update. By default all updates are selected. Above the list box are two options: a check box to select or unselect all updates at one time and a dropdown that allows you to choose between x64 and x86 architectures.

Set Schedule: Select the schedule to use to update the image. Choose As soon as possible or pick an exact date and time to use. Two check boxes are checked by default: Continue on error, and Update distribution points with the image. Sometimes an error will occur when trying to apply the update to the image; the Continue on error option allows the process to continue and not stop on that error. The Update distribution points with the image check box allows DPs to be updated with the newly updated image when the process is finished.

The process is fairly simple: The image is copied to a temporary location on the machine running the console, the image is mounted, updates are applied using the DISM tool, the image is saved as it is unmounted, the old image is renamed, and the new image is copied back to its permanent location. The DPs are then updated if the box was checked in the wizard. The entire process is logged in the OfflineServicingMgr.log file located in the <ConfigMgr_install_directory>Logs folder.

OSD continues to be a primary reason for many organizations to implement ConfigMgr. Once set up and configured correctly, ConfigMgr becomes a workhorse that reduces the workload of IT administrators, engineers, and architects while also improving user satisfaction and overall effectiveness of the IT department. With Windows 10 Servicing inside ConfigMgr and the ability to create a streamlined upgrade TS, Microsoft has committed to enhancing OSD even more with ConfigMgr Current Branch, allowing the deployment and overall Windows experience to become as painless as possible.

The next chapter discusses security issues you should consider when implementing System Center Configuration Manager.