Microsoft Surface 3 User Manual

Published: December 2014

Surface Pro 3

Deployment and Administration Guide

Version 1.0

Surface is a trademark of Microsoft Corporation.

Computrace is a trademark of Absolute Software Corporation

Reader is a trademark of Adobe Systems Incorporated

Java is a trademark of Oracle Corporation

This document is provided “as-is.” Information in this document, including URL and other Internet website references, may change without notice.

Contents

PART I – DEPLOYMENT OVERVIEW

Chapter 1 – Overview ................................................................................................................................................ 9

Purpose of This Guide ............................................................................................................................................ 9

Audience ................................................................................................................................................................ 9

How This Guide is Organized ............................................................................................................................... 10

Document Conventions ....................................................................................................................................... 11

What’s Not in This Guide ..................................................................................................................................... 11

Chapter 2 – Deployment Introduction .................................................................................................................... 12

Deployment Concepts .......................................................................................................................................... 12

Deployment and Imaging ................................................................................................................................ 12

Sysprep and Generalization ............................................................................................................................. 13

Image Servicing ................................................................................................................................................ 14

Licensing .......................................................................................................................................................... 15

Deployment Types ........................................................................................................................................... 16

Deployment Tools ................................................................................................................................................ 17

Factors and Considerations ............................................................................................................................. 17

Third Party Tools .............................................................................................................................................. 18

Microsoft Tools ................................................................................................................................................ 18

Microsoft Deployment Toolkit ............................................................................................................................. 22

The Deployment Workbench .......................................................................................................................... 22

Deployment Shares ......................................................................................................................................... 23

Windows Deployment Wizard ......................................................................................................................... 25

Driver Management ........................................................................................................................................ 26

Application Management ................................................................................................................................ 26

Package Management ..................................................................................................................................... 27

Task Sequences ................................................................................................................................................ 28

Considerations for Images ................................................................................................................................... 29

The Single Image Goal ..................................................................................................................................... 29

Using a Virtual Machine as a Reference System ............................................................................................. 30

Selecting Applications for the Base Image ...................................................................................................... 30

Planning for Deployment ..................................................................................................................................... 31

Laboratory Testing ........................................................................................................................................... 31

Pilot Deployments ........................................................................................................................................... 32

Staggered Deployments .................................................................................................................................. 33

“White Glove” Delivery ................................................................................................................................... 33

PART II – DEPLOYMENT STEP-BY-STEP

Chapter 3 – Manual Deployment with MDT............................................................................................................ 36

Installing Deployment Tools................................................................................................................................. 37

Windows Assessment and Deployment Kit ..................................................................................................... 37

Microsoft Deployment Toolkit ........................................................................................................................ 39

Windows Deployment Services ....................................................................................................................... 41

Creating a Deployment Share .............................................................................................................................. 45

Importing an Operating System ...................................................................................................................... 48

Importing Drivers ............................................................................................................................................. 50

Creating the Task Sequence ............................................................................................................................ 58

Preparing Boot Media .......................................................................................................................................... 61

Generating Boot Media ................................................................................................................................... 61

Importing Boot Media into WDS ..................................................................................................................... 62

Deploying the Basic Scenario ............................................................................................................................... 63

Booting from the Network .............................................................................................................................. 63

Windows Deployment Wizard ......................................................................................................................... 65

Chapter 4 – Reference Deployment with MDT ....................................................................................................... 68

Configuring Deployment Share Rules .................................................................................................................. 70

Configuring Windows Deployment Wizard Rules ........................................................................................... 71

Configuring Boot Media Rules ......................................................................................................................... 74

Creating a Reference Deployment Task Sequence .............................................................................................. 75

Enabling Windows Updates ............................................................................................................................. 76

Deploying to the Reference System ..................................................................................................................... 77

Customizations to the Reference Image .............................................................................................................. 80

Customizing the Wallpaper ............................................................................................................................. 80

Customizing the Default User Account Picture ............................................................................................... 81

Customizing Windows Store Apps ................................................................................................................... 83

Customizing the Start Screen .......................................................................................................................... 86

Creating a Capture Task Sequence....................................................................................................................... 88

Creating an Image from the Reference System ................................................................................................... 90

Testing the Image ................................................................................................................................................. 92

Importing the Captured Image ........................................................................................................................ 92

Creating the Test Deployment Task Sequence ................................................................................................ 92

Deploying the Captured Image ........................................................................................................................ 95

Chapter 5 – Automated Deployment with MDT...................................................................................................... 96

Disabling WDS PXE Boot ...................................................................................................................................... 97

Creating the Production Deployment Share ........................................................................................................ 98

Customizing Rules for Automation .................................................................................................................. 98

Customizing Task Sequence Selection by Model........................................................................................... 100

Importing the Custom Image ............................................................................................................................. 103

Importing Drivers ............................................................................................................................................... 104

Importing Applications ....................................................................................................................................... 104

Importing Adobe Reader ............................................................................................................................... 105

Importing Oracle Java .................................................................................................................................... 106

Importing Microsoft Office ............................................................................................................................ 107

Creating the Production Deployment Task Sequence ....................................................................................... 112

Testing the Production Deployment .................................................................................................................. 114

Creating the Offline Deployment Share ............................................................................................................. 115

Linking the Deployment Shares ..................................................................................................................... 116

Preparing a USB Stick for Boot ...................................................................................................................... 119

Generating Offline Media Files ...................................................................................................................... 120

Configuring Offline Media Rules .................................................................................................................... 121

Finalizing the Offline Media ........................................................................................................................... 123

Deploying from Offline Media ........................................................................................................................... 124

Chapter 6 – Automated Deployment with SCCM .................................................................................................. 126

Integrating MDT with SCCM............................................................................................................................... 128

Importing Surface Pro 3 Drivers ......................................................................................................................... 129

Importing the Drivers for the Boot Image ..................................................................................................... 129

Importing the Drivers for Windows 8.1 ......................................................................................................... 133

Importing the Operating System Image ............................................................................................................. 135

Creating the Deployment Task Sequence .......................................................................................................... 136

Specifying Drivers to Use in the Deployment Task Sequence ....................................................................... 140

Specifying the CopyProfile setting in the Answer Profile .............................................................................. 141

Deploying the Operating System Task Sequence to the Client .......................................................................... 143

Updating Distribution Point Components ..................................................................................................... 143

Deploying to Existing SCCM Clients ............................................................................................................... 143

Deploying to New or Unknown Computers .................................................................................................. 148

PART III – ADMINISTRATION

Chapter 7 – Administration Overview ................................................................................................................... 153

Management Tools ............................................................................................................................................ 153

System Center Configuration Manager ......................................................................................................... 153

Windows Intune ............................................................................................................................................ 154

Group Policy .................................................................................................................................................. 154

Features ............................................................................................................................................................. 154

Firmware ........................................................................................................................................................ 154

Asset Tagging ................................................................................................................................................. 154

BitLocker Encryption ...................................................................................................................................... 155

Computrace Persistence ................................................................................................................................ 155

Miracast Wireless Display .............................................................................................................................. 155

Accessories ......................................................................................................................................................... 155

Surface Pen .................................................................................................................................................... 155

Surface Ethernet Adapter .............................................................................................................................. 155

Surface Pro 3 Docking Station ....................................................................................................................... 156

Surface Pro Type Cover ................................................................................................................................. 156

User Serviceability ......................................................................................................................................... 156

Business Support Channels ............................................................................................................................ 156

Chapter 8 – Administration Scenarios ................................................................................................................... 157

Asset Tagging ..................................................................................................................................................... 157

BitLocker Encryption .......................................................................................................................................... 157

Enabling PIN Authentication on Surface Pro 3 .............................................................................................. 158

Encrypting During MDT Deployment ............................................................................................................ 158

Pen Pairing ......................................................................................................................................................... 159

Migrating User Data ........................................................................................................................................... 160

Migrating Data in Replace Scenarios ............................................................................................................. 160

Migrating Data in Refresh Scenarios ............................................................................................................. 162

System Tracking ................................................................................................................................................. 163

Deploying Computrace with MDT ................................................................................................................. 163

PART IV – APPENDIX

References ............................................................................................................................................................ 165

PART I

DEPLOYMENT

OVERVIEW

Chapter 1 – Overview

Purpose of This Guide

This guide was constructed to show you best practices for deploying Windows to Surface Pro 3 devices. This may sound like a simple enough statement, but due to the vast number of scenarios and concepts, deployment can be quite complex. This guide is organized in a way that minimizes the learning curve for you to understand how to deploy Windows to the Surface Pro 3 devices to your organization. It presents step-by-step procedures that provide essential building blocks for successive chapters. Therefore, it is a good idea to read the chapters in order.

The deployment concepts discussed in this guide are valid for all Windows computers, but specifically targets scenarios for Surface Pro 3 devices.

You’ll see many screenshots in this document, but in an effort to keep the document as short as possible, some images

for basic options are described, but not shown.

Audience

This guide is intended for IT Professionals (IT Pros) that are responsible for managing and conducting rollouts of Windows devices within an organization. This guide is written specifically to account for scenarios that are typically experienced by organizations of all sizes, since many of the deployment concepts are not specific to organization size. However, there are some scenarios, tips, and other guidance that is likely to be experienced specifically by a small or medium business (SMB), or by a large business (enterprise). When the guidance differs by organization size, this is specifically called out in this guide. This guide does not assume specific software is available only to a specific size organization. For example, it does not assume only a large enterprise uses System Center.

If you have deployed Windows using a 3rd-party tool (a.k.a non-Microsoft tool), this guide provides a comprehensive

introduction into best practices for deploying Windows to Microsoft Surface Pro 3 devices. As you’ll learn, the best

practice for deployments of all sizes is to use the free Microsoft Deployment Toolkit (MDT). New users and experience deployment professionals alike will gain insights from reading this guide. The Microsoft Deployment Toolkit is explored in more detail in the Microsoft Deployment Toolkit section of Chapter 2 and is featured throughout the step-by-step guidance in Part II of this guide.

Although the Microsoft Deployment Toolkit is the primary technology used throughout this guide, it is used in conjunction with other Microsoft technologies as part of the overall solution. For example, in Chapter 6: Automated

Deployment with SCCM, the Microsoft Deployment Toolkit is integrated with Microsoft System Center Configuration

Management to leverage the functionality of both tools.

For administrators who are experienced with Windows deployment and the Microsoft Deployment Toolkit, specific information is provided that addresses many of the key tasks for Surface Pro 3 and Windows deployment. To help identify the locations where these concepts are discussed, a brief list has been provided here:

 Application Deployment – Chapter 5  Windows Updates – Chapter 4, Chapter 5, and Chapter 6  Surface Pro 3 Firmware – Chapter 5, Chapter 6, and Chapter 7

 BitLocker Encryption – Chapter 8  Asset Tagging – Chapter 8  Network Boot – Chapter 3, Chapter 4, Chapter 5, Chapter 6, and Chapter 8  Deployment Planning – Chapter 2  Offline Deployment – Chapter 5  System Tracking – Chapter 8  Surface Pro 3 Features – Chapter 7  Windows Store Apps – Chapter 4  Surface Pro 3 Administration – Chapter 7 and Chapter 8

How This Guide is Organized

This guide is organized in a series of parts and chapters that present increasingly complex concepts that build upon each other. Therefore, it is recommended to read this document in sequential order. Even if you are familiar with deployment concepts, there are some important tips you’ll learn along the way.

This guide is organized as follows:

 PART I: DEPLOYMENT OVERVIEW

o Chapter 1: Overview – This chapter. o Chapter 2: Deployment Introduction – Outlines basic concepts and terms needed as a prerequisite for

performing the step-by-step walkthroughs shown in Part II. Experienced deployment professionals may be able to skip this chapter, but novice deployment professionals should read this chapter.

 PART II: DEPLOYMENT STEP-BY-STEP

o Chapter 3: Manual Deployment with MDT - Provides a walkthrough of a basic, standalone deployment

of the operating system. This is a manual deployment because it provides no automation, thereby forcing the user to enter required setup data throughout the process. The resulting operating system contains no applications or configuration, so these will need to be installed or configured on each computer.

o Chapter 4: Reference Deployment with MDT – Builds upon the manual deployment scenario, but starts

to introduce some automation. User interaction required during deployment is less than the manual deployment, but more than a fully automated deployment. This scenario is used to prepare a reference system and create an image for use in Chapter 5 and Chapter 6. Deployment of the image to a test computer is also covered, but this test computer contains no drivers or applications.

o Chapter 5: Automated Deployment with MDT– Builds upon the reference deployment scenario with

additional automation, requiring minimal user interaction during deployment. This scenario uses the image created in Chapter 4 and also deploys applications and drivers. The resulting operating system is ready for use when the deployment completes. This scenario also addresses both online deployment for network joined systems and offline deployment for systems without network connectivity.

o Chapter 6: Automated Deployment with SCCM – Adds System Center Configuration Manager and

support for zero-touch installation (ZTI) to produce an automated deployment requiring no interaction from the user. This scenario uses the image created in Chapter 4 and includes applications and drivers that are managed by System Center Configuration Manager. The resulting operating system is complete

with applications and drivers, is configured for central management through SCCM, and is ready for use by the end user.

 PART III: ADMINISTRATION

o Chapter 7: Administration Overview – Describes Surface Pro 3 administration and concepts. o Chapter 8: Surface Pro 3 Administration Scenarios – Outlines Surface Pro 3 administration by showing

how to manage these settings and features:

 Asset Tagging  BitLocker Encryption  Pen Pairing  User Data Migration  System Tracking

 PART IV: APPENDIX

Document Conventions

The conventions used in this document are as follows:

 Bold text – Indicates a literal name of an object on a screen, such as a button, link, option, or menu.  Italicized text – Indicates the first time a term is used.  Monospace text – Indicates code or script that can be copied/pasted and used in your environment.  Ctrl+F – Indicates the Ctrl and F keys are pressed simultaneously.  FileSave – Indicates a series of menu clicks.  Note – Indicates some additional information or considerations for a concept, option, or configuration.  Caution – Indicates special warning or tip to consider that may adversely affect your computer.

What’s Not in This Guide

This guide focuses on a variety of scenarios for Windows deployments. However, this guide assumes you already have knowledge of these specific areas of administration and IT:

 Windows Networking  Windows Server  Windows Firewall  Hyper-V  System Center Configuration Manager

Chapter 2 – Deployment Introduction

Deployment Concepts

This section discusses the concepts you’ll need to gain an overall understanding of the deployment process for the Windows operating system and the tools available to your organization. Please read this section before continuing with the rest of this deployment guide.

Deployment and Imaging

The simplest way to transfer an operating system onto a single computer is known as installation. Installation simply refers to running a setup application supplied with the original media and following the prompts on the screen. For one computer (or a small number of computers), this can be an ideal way to upgrade a computer’s operating system, or for single bare metal machines. The setup application prompts for basic information to be manually entered and once the default environment is prepared, the system can be manually customized with applications, drivers, and settings.

As the number of computers in your organization increases, it becomes less efficient (or even impossible) to install an operating system on all computers by using a setup application. It becomes essential to employ methods of installation that not only reduce the time and effort, but standardize the resulting systems. For more than one computer, you need an efficient process to distribute the operating system and configuration to each, a process known as deployment.

The simplest method of deploying to multiple computers is cloning, whereby the process of installation and configuration is performed on a single computer and the disk drive is mirrored to the other computers. This produces multiple identical computers. One key problem with this approach is that you need to physically remove the storage media, such as the hard drive(s), connect them to the system you are cloning, clone the drive, then reinstall the devices. Another is that the hardware configuration of the computers must be identical. Even minor variations in hardware can result in a computer that will not boot or function as intended.

These limitations are addressed by the process of imaging. Imaging works similar to cloning in that the target computer contains the source computer’s files, but rather than directly transferring all files to the destination disk, the configuration of the source disk is stored as a data file. Because this file represents an exact copy of the source, it is known as an image. The image file can be transferred, or distributed, through a variety of means including removable media (USB hard drive), optical disks (DVD, BluRay, etc.), or over standard network connectivity.

The first step in an image-based deployment is configuring the computer that is used as the source environment for generating an image to be deployed. This source environment is often referred to as the reference system. Once the reference system is configured, it is stored as an image file through a process known as capturing an image. The process of capturing an image cannot be performed while files are in use, so before capturing can begin, you must boot the reference computer to an alternative operating system. The device that contains the alternative operating system is known as the boot media.

Note: The image created from the reference system is commonly known as the reference image or base image. This image serves as the core configuration on which the environment for every deployed computer is built.

Boot media can reside on removable storage (such as a USB stick or optical media), but can also be located on your network. If you use your network as boot media (also known as PXE boot), your computer’s network card must support

the Preboot Execution Environment (PXE) standard. The Surface Pro 3 supports PXE boot through the docking station or Surface Ethernet Adapter. Your reference computer is likely to boot to the hard disk first, so you often need to change the boot order in the system firmware to boot to the boot media containing the alternative operating system. Most computers, including Surface Pro 3, provide a boot menu that enables a device to be selected at startup. Details of how you select your boot media on Surface Pro 3 are shown in Chapter 3.

Once an image file is created, it is stored on local or network storage so that it can later be transferred, or deployed, to the destination computers. This step also involves the alternative operating system provided by boot media, but is effectively the reverse of a capture step, whereby the data in the image file is read and then written to the disk on the new computer.

Sysprep and Generalization

The result of both the imaging and cloning procedures is a set of virtually identical computers. While in many ways you

want the destination computers to be identical to the reference computer, you don’t want everything to be identical. For example, you don’t want the same computer identification and possibly the license/product keys (depending on the

type of license) on multiple computers.

The Windows operating system maintains an identifier which enables each Windows computer to appear as a unique and individual computer when connected to the network. This Security Identifier, or SID, if identical between two systems can produce conflicts with networking software. This is similar to the way you cannot have two computers with the same IP address on the same network. A notable example of software that conflicts with an environment with identical SIDs is Windows Server Update Services (WSUS).

Another scenario where a destination computer and reference computer differ is where there is a variation or change in the hardware configuration. This variation can be a small change, such as using a discrete graphics card rather than the onboard graphics card, or it can be two completely different models of computer where almost every device differs. Drivers from the reference computer could cause conflicts in the destination computer or even result in the computer being unable to boot.

Since a captured image will be identical to the reference system (including SID and licensing data), this data must be removed before it can be deployed. The solution is to use the System Preparation Tool (Sysprep), which is a utility designed to assist with deployment and creation of images. Sysprep works in conjunction with Windows Setup to reset an existing Windows environment to a state in which this information can be regenerated for each new system to which the environment is deployed. This process is known as Generalization. When Sysprep runs, it removes the undesired configuration and information from the system, then reboots to a phase of Windows Setup known as Windows Welcome or the Out of Box Experience (OOBE).

Note: If you don’t run Sysprep, the system is not considered unique, and therefore is not compliant with Microsoft support policy.

The purpose of the OOBE is to present the user with the same welcome screen and prompts as he/she would experience during a typical Windows installation/setup. As expected, the OOBE experience prompts for basic information like computer name, workgroup or domain, and product key.

In some cases you want your users to experience OOBE. An example is those cases where the domain or workgroup of the deployed computers may vary, or where the product key will change for each computer and will require it to be

entered manually. Another example is the pairing wizard for the Surface Pen for Surface Pro 3, which is covered in more

Sector-Based Images

File-Based Images

 Not Serviceable  By drive  Destructive  Not Flexible

 Serviceable  By partition  Non-Destructive  Flexible

detail in the Pen Pairing section of Chapter 8.

In other cases, many of the answers to question prompts are known in advance and are therefore predetermined. In these cases Windows Setup can be configured to supply these predetermined answers to avoid prompting the user. Answers to the setup questions are stored in an Answer File. In addition to supplying answers for the prompts which are presented by the OOBE experience, a wide variety of additional settings are available which instruct Windows Setup to perform additional tasks or to alter its behavior. A complete reference of the available settings for an answer file and Windows Setup is linked in the References section of the Appendix.

Image Servicing

Some 3rd-party imaging tools capture images by reading each sector of the storage media and creating an exact duplicate of the storage media. This type of image is referred to as a sector-based image. Sector-based images have two disadvantages: lack of granularity and poor serviceability.

When a sector-based image is applied to a system, it overwrites the configuration of the storage media that includes partitioning, file systems, etc. As such, it is impossible to apply only part of the image or to apply the image in a way that is non-destructive to the files that reside on the storage media.

As sector-based images lack the ability to distinguish between individual files within the image, they are also difficult to modify, or service, after creation. To explore the files within a sector-based image, a mounting solution is required that emulates a hardware device and presents the data to the operating system sector-by-sector. Due to this level of complexity required for sector-based images to access the files within an image, making modifications or alterations to the files within an image is often less efficient than deploying that image to a system, modifying it, then recapturing.

On the other hand, file-based images, such as those created in the Windows Imaging format (WIM), are not subject to the limitations of sector-based images. File-based images are captured at the file system level and thus are aware of the individual files within them. They can be thought of as a large ZIP or archive file in which all of the files for the environment are stored. They can be deployed to an existing file system without destruction of the data in that file system, which is beneficial for migration scenarios where preservation of user data is required.

File-based images can also be edited directly using tools for servicing the image. For example, an existing file-based image that is configured for a specific make and model of computer can have the drivers and files required for another computer injected or inserted into the image so that it can be deployed to a platform for which it was not originally intended. Another example is where Windows Updates can be applied to a Windows image to ensure that the deployed computer is fully up-to-date.

Table 2.1 outlines the benefits of the different types of image technologies.

Table 2.1: Benefits of Imaging Technologies.

Licensing

An important consideration when deploying the Windows operating system is how licensing will be managed for the deployed devices. There are four standard solutions for the management of licenses and each has implications for the deployment process. These four solutions, described in the following sections, are:

 Single license key  Multiple Activation Key (MAK)  Key Management Service (KMS)  Active Directory-Based Activation (ADBA)

Single License Key

Single license keys are available in several varieties, including Original Equipment Manufacturer (OEM), retail or Fully Packaged Product (FPP), and retail upgrade. In a deployment scenario where the devices are licensed through OEM or FPP channels, the license key will need to be manually entered on each computer individually to properly facilitate activation. Some computers can have operating system product keys embedded into the system firmware through OEM Activation 3.0 (OA 3.0). This includes the product key supplied with the Windows 8.1 Professional installation included with the Surface Pro 3. The order of precedence for product key activation is:

1. Answer file

2. OA 3.0 product key in the system firmware

3. Product key prompt

As such, in order to ensure the OA 3.0 key is used in a deployment to the Surface Pro 3, no answer key should be specified in an answer file or included in the image.

Multiple Activation Key (MAK)

For organizations with Volume Licensing agreements, there are three methods managing licenses. The first is Multiple Activation Key (MAK), which is a license key that can be used on more than one computer, though it must be activated on each. To deploy Windows with a MAK, include the key in the deployment task sequence or specify they key with the answer file. For more information about task sequences, see the Task Sequences section in this chapter.

Key Management Services (KMS)

Another method of managing volume licenses is Key Management Services (KMS). With KMS, an organization maintains a server that manages activation of the clients and communicates the activation data back to Microsoft. To deploy Windows using KMS, no key is required during deployment. Volume License versions of the Windows Client are preconfigured as KMS clients and will attempt to discover a KMS host if no other qualifying license is discovered.

Note: The deployment of images in organizations with Volume Licensing agreements for Windows 8.1 Professional is governed by the Reimaging Rights conferred with that Volume Licensing agreement. This agreement enables reimaging from volume license media to devices with preinstalled versions of the same product. For example, an organization with a pre-existing Windows 8.1 Professional image created from volume license media can deploy that image to the Surface Pro 3 licensed for Windows 8.1 Professional using the license for Windows 8.1 Professional (OEM) included with the system. These rights apply only to the same edition and version of Windows. For example, a Windows 8.1 Enterprise image cannot be used with a Windows 8.1 Professional license. It is recommended to use Volume License Media for deployment to Surface Pro 3.

Active Directory-Based Activation (ADBA)

Beginning with Windows 8, a new activation method was introduced that allows activation through an Active Directory domain. This method enables central activation and management of licensing without requiring the infrastructure necessary for KMS. Active Directory-Based Activation is managed through the Volume License Activation and Management Tool (VAMT), a component of the Windows Assessment and Deployment Kit (Windows ADK) covered in the Microsoft Tools section later in this chapter.

Deployment Types

A deployment can be categorized by the amount of interaction required of a user during the deployment process. The three types of deployment are:

 High-Touch Installation  Lite-Touch Installation  Zero-Touch Installation

It is possible to deploy using more than one deployment type. For example, to deploy to a new computer which is not configured for a management solution or internal network, some level of interaction is required to cause the system to initiate the deployment process, though the process of deployment could be entirely automated as a zero-touch deployment. Each deployment type is discussed in the following sections.

High-Touch Installation

High-touch deployments are characterized by a large degree of user interaction during deployment. A typical high-touch deployment requires the user to perform each separate task manually, often from the command-line. Usually drivers, applications, and customization are all performed manually by the user as well, often on each deployed system. Hightouch deployments are rarely used in scenarios with multiple computers due to the inefficiency and time involved.

Note: A sub-category of high-touch deployment is full-touch installation, a term that is usually used to describe installation from the original installation media and manual installation of applications and drivers.

Lite-Touch Installation

Lite-touch installation (LTI) is a deployment strategy that requires a user to manage and monitor the deployment process, but eliminates many of the repetitive steps and processes, which increases the efficiency of the deployment. The user is often required to boot to the deployment media and to answer basic questions such as the name of the computer and to join a workgroup or domain, but the environment is pre-configured with applications and drivers

which eliminates the need for separate installation or configuration. The deployment can be fully automated but still have to be manually initiated. The Microsoft Deployment Toolkit (MDT) is the recommended tool for LTI deployments. The scenarios covered in Chapter 3, Chapter 4, and Chapter 5 are all lite-touch deployments.

Zero-Touch Installation

In a zero-touch installation (ZTI) deployment there is no human interaction on the client computer. The deployment is performed entirely from the deployment server. Zero-touch deployments usually require a refresh or migration scenario, where the target computers can be instructed to initiate the deployment and utilizes a management solution like System Center Configuration Manager. Zero-touch deployment is covered in Chapter 6.

Deployment Tools

There are many factors to consider when selecting the deployment tools you will use in your organization. This section outlines those tools and helps you understand the factors and considerations to make the appropriate decision for your deployments.

Factors and Considerations

When selecting deployment tools and technologies for application in your organization and environment, there are several factors which bear consideration:

 Ease of use  Serviceability  Scalability  Automation  Compatibility  Price

Ease of use

Ease of use must be seen from two perspectives: the experience of the user or team setting up the infrastructure and the individual or team doing the deployment.

Investing in some automation may initially take some time and require specialized skills, but will make device deployment easier, faster and more consistent in the long run for those actually doing the deployment.

Serviceability

Serviceability was briefly covered earlier in this chapter. Using a file-based imaging technology makes it possible to service the image, whereas sector-based technologies does not. Serviceability ensures the ability to modify an image to keep software updates current, as well as the ability to modify components such as drivers and applications to address new platforms and scenarios. Sector-based imaging by contrast often requires that an image be deployed to a reference machine, manually updated or modified, and then re-captured whenever updates or changes are required.

Scalability

Scalability refers to the ability to use your selected technologies for deployment as your organization grows or you rollout to larger parts of your company. A solution which supports network deployment is a must for scalability.

For larger deployments, there are additional scalability considerations, such as:

 Selecting technologies that maximize performance by minimizing network traffic  Do the technologies cover multiple scenarios, such as:

o Deployment to field or disconnected workers o Distribution across sites or subnets o Bring Your Own Device (BYOD) scenarios o Virtual Desktop Infrastructure (VDI) scenarios

Automation

Automation refers to the ability of a deployment task to be performed without human interaction. Some key considerations in determining the level of automation provided by a deployment tool are:

 Minimizing time and effort required to configure and deploy to your organization.  Ability to reduce repetitive tasks, such as application installation, user data migration, etc.  Ability to configure using graphical, on-screen wizards, instead of complex command-lines. The more complex

and manual a process is, the more the possibility exists that errors will be introduced.

Compatibility

A key requirement of any deployment technology is the compatibility of the solution with the hardware and operating systems in your environment. For example, some deployment tools lack the ability to deploy to latest generation hardware due to changes in the way that storage and firmware are managed. For example, Surface Pro 3 is a UEFI 2.3.1 class 3 device, so many older technologies may not be compatible.

Price

The cost of a deployment solution is an important consideration. You may have some deployment solutions already implemented or licensed in your environment. For example, Windows Deployment Services is a feature included with Windows Server or you may have System Center Configuration Manager already implemented as a management solution. Some of the technologies discussed in this guide, such as Microsoft Deployment Toolkit and Windows Automated Deployment Kit are available at no charge.

Third Party Tools

This guide is written to highlight Microsoft technologies, but it is possible to use some third-party tools and technologies to deploy Surface Pro 3 devices. While this guide is unable to address specific third-party tools, there are two factors to consider:

1. Many third-party tools use sector-based imaging, which makes servicing and automation difficult or impossible.

2. Some third-party tools simply serve as a wrapper around Microsoft tools and technologies. These third-party

tools may leverage boot media provided by Microsoft tools, or employ a mounting solution for servicing sectorbased images, but use Microsoft technologies to do so.

Microsoft Tools

There are many deployment tools and technologies provided by Microsoft for Windows deployment. These tools provide a variety of solutions that range in complexity and functionality. Some tools are very specific utilities designed

to perform only a single task, others are complete solutions that can perform every step of a deployment. Most of the

Tool/Technology

Purpose

Windows System Image Manager (Windows SIM)

Creates and verifies answer files

Deployment Image and Servicing and Management (DISM)

Services and modifies images and environments

tools can be integrated into a complete solution accessed through a single interface, providing a combination of functionality and ease of administration. More details about these tools and solutions are provided in the following sections.

Windows Deployment Services

Included with Windows Server, Windows Deployment Services (WDS) is a solution for the network distribution of images and boot media. WDS provides support for PXE booting which helps to eliminate the need for physical boot media when performing lite-touch deployments. It also natively supports the deployment of images in the file-based Windows Imaging Format (WIM), which is common to all modern Microsoft deployment solutions.

WDS supports management of drivers and the creation of images and can serve as a powerful deployment solution by itself, but works best when combined with the Microsoft Deployment Toolkit covered later in this chapter to provide additional capacity for automation and customization during the deployment process. The version of WDS included with Windows Server 2012 or newer is required for support of UEFI 2.3.1 devices like Surface Pro 3.

Note: For smaller environments without access to Windows Server, the cost of implementing Windows Server to use WDS may be prohibitive. However, Microsoft Deployment Toolkit (MDT) is available at no cost and will operate on a client computer. Even if you are using Windows Server, installing MDT on a client computer can reduce workload by enabling the deployment storage location to be hosted by a Windows client while still supporting the network boot capability of WDS. MDT is described in more detail later in this section.

Windows Assessment and Deployment Kit

The Windows Assessment and Deployment Kit (Windows ADK) is a collection of several tools and utilities that perform specific tasks required during different parts of a deployment. If you are familiar with the Windows Automated Installation Kit (Windows AIK), the Windows ADK is the replacement toolset for Windows 8 and newer operating systems. When downloading the Windows ADK, it is important to ensure that you are downloading the latest update because prior versions of the Windows ADK may not work on later operating systems. Most of this tools are command line only, and are used behind the scenes by other tools such as the Microsoft Deployment Toolkit (MDT).

Inside the Windows ADK there are several components, each described in subsequent sections:

 Windows System Image Manager (Windows SIM)  Deployment Image and Servicing and Management (DISM)  Windows Preinstallation Environment (WinPE)  User State Migration Tool (USMT)  Volume Activation Management Tool (VAMT)

Table 2.2 summarizes the purpose of each Windows ADK tool.

Windows Preinstallation Environment (WinPE)

Alternate boot operating system used to perform deployments and imaging

User State Migration Tool (USMT)

Migrates user data from one environment to another

Volume Activation Management Tool (VAMT)

Centrally manages Microsoft licenses and activation

Application Compatibility Toolkit (ACT)

Mitigates application incompatibilities

Table 2.2: Windows ADK Tools.

Note: The Application Compatibility Toolkit is a powerful tool used to provide compatibility fixes, or shims, to resolve

application compatibility issues. Although it is included in the Windows ADK, it is not covered in this guide.

The Windows Assessment and Deployment Kit can be downloaded from the Microsoft Download Center by following this link:

http://go.microsoft.com/fwlink/?LinkId=293840

Windows System Image Manager

The Windows System Image Manager (Windows SIM) is the utility that creates and manages the answer files used with Sysprep and Windows Setup. Answer files are stored in an XML format, so it is possible to manually edit these files. However, using WISM to manage answer files ensures the resulting file is built from settings confirmed to be valid for the target operating system. Using the Windows SIM helps to ward against human error when performing a deployment with configurations set by the answer file.

Deployment Image Servicing and Management

The Deployment Image Servicing and Management tool (DISM) is one of the most important tools included with the Windows ADK. It is used to mount and service Windows images and replaces the previous imaging solution called ImageX. ImageX was used by the Windows AIK in Windows 7 and Windows Vista. DISM is a command-line utility that supports file and package management in images and can be used to apply updates, drivers, apps, and other configurations to an image. DISM has the ability to service an operating system environment while it is currently running on a computer, or an offline image.

Even with third party tools where servicing is supported, management of a Windows image is typically performed with DISM. DISM is also commonly used in system maintenance and repair. In Windows 8 and later versions of Windows, the DISM utility replaces the deprecated System File Checker (SFC) to verify and repair Windows core operating system files. DISM is also commonly used to add or remove Windows features.

Windows Preinstallation Environment

The Windows Preinstallation Environment (WinPE) is the alternative operating system executed on the boot media used by Windows Deployment Services, the Microsoft Deployment Toolkit, System Center Configuration Manager, and several third party deployment solutions. As a minimalistic environment based on the kernel of the Windows operating system, WinPE supports the same drivers and many of the same commands as the operating system being deployed. This ensures compatibility with the destination computers and provides a highly configurable environment which is able

to meet a wide variety of tasks. Windows PE is runs exclusively from RAM to make sure no files are locked in the disk to which we are deploying a new Operating System.

User State Migration Tool

The User State Migration Tool (USMT) is a command line utility that is used to back up and restore user-specific data and settings. USMT includes two processes, ScanState and LoadState. ScanState is used to backup user settings, either to the network, an external device, or locally on the system in a way that will be preserved through a file-based image deployment using Microsoft tools. LoadState is then used in the deployed operating system to restore the user data and settings for a seamless transition to the new computer.

Volume Activation Management Tool

The Volume Activation Management Tool (VAMT) collects activation data for large deployments by serving as a central relay for communication with the Windows activation servers. It also provides a secure central management solution for product keys and inventory and monitoring services for licensing and activation. VAMT also facilitates management of licensing through Active Directory-Based Activation (ADBA).

System Center Configuration Manager

One of the most feature-rich solutions for the deployment and management of computers within an organization is Microsoft System Center Configuration Manager, also known as SCCM. This enterprise tool serves not only as a utility for facilitating operating system deployment, but also for managing active systems across an enterprise. SCCM enables the deployment of applications, management of updates, and complex reporting of the environment. SCCM is capable of managing not only Windows computers, but also those running non-Microsoft operating systems and mobile devices.

SCCM enables package and update management, so not only can a new environment be pushed to client computers such as Surface Pro 3, but also driver and firmware updates. See Chapter 6 for more information about driver and firmware deployment for Surface Pro 3 scenarios.

SCCM also supports a fully-automated, zero-touch deployment scenario. As a management solution, it is able to seamlessly initiate deployment in a refresh scenario and perform the distribution of the environment without any user interaction. SCCM integrates with the Microsoft Deployment Toolkit integration (see next section for more information), to enable even more functionality, such as support for User Driven Installation (UDI). UDI is a framework that enables an IT department to create a custom deployment wizard to guide users through a specific installation or customization task.

Microsoft Deployment Toolkit

Each of the tools and technologies discussed thus far enable some deployment functionality, but the Microsoft Deployment Toolkit (MDT) pulls all those technologies together, acting as a wrapper to consolidate the configuration and unify the deployment experience.

Note: Early versions of the Microsoft Deployment Toolkit were known as Business Desktop Deployment, or BDD.

The Microsoft Deployment Toolkit is a highly scalable deployment solution. It can be used in deployments for small and medium sized businesses (SMB), or large enterprises alike. MDT can handle small deployments where no servers are available and the deployment files are hosted on a user’s workstation. Likewise, MDT can be used for distributed deployments to multiple sites and thousands of computers across data centers, networks, and domains.

MDT is also highly automated, with an extensive set of preconfigured scripts and a process for scripting each step of a

Tool/Technology

Serviceability

Scalability

Automation

Compatibility

Price

WDS









Included with Windows Server

Windows ADK







No cost

SCCM



May have additional cost

MDT







No cost

Explanation

SCCM and MDT offer the greatest serviceability

SCCM and MDT offer the greatest scalability

SCCM and MDT offer the greatest automation

SCCM and MDT offer the greatest compatibility

MDT and Windows ADK are available at no cost.

deployment through task sequences. Task sequences are series of steps, where each step is performed by a command or script that advances the deployment process. It even lends this automation to the serviceability of the images it manages. It automates the management of drivers, applications, and packages to regulate updates and changes to the image for the easiest maintenance of images and the greatest adaptability to new requirements and situations.

Note: Regardless of your business size or scenario, MDT is the recommended solution for Windows deployment. If your organization uses SCCM or WDS, MDT can be easily integrated without interfering with existing configurations to provide the additional functionality and automation. For organizations already using SCCM as a management and deployment solution, MDT extends the deployment functionality by providing wizards, scripts, templates, and a customizable User Driven Installation (UDI) solution. For environments with WDS, MDT adds the ability to automate image creation and servicing, management of applications during deployment, and greatly reduces the amount of manual labor required to perform simple and regular imaging tasks.

Table 2.3 represents the factors for each of the Microsoft deployment solutions and the ranking within each on a scale of 1 to 5.

Table 2.3: Comparison of Microsoft Deployment Solutions.

Microsoft Deployment Toolkit

As you learned in the Deployment Tools section earlier in this chapter, the recommended solution for Windows deployment for any size organization is the Microsoft Deployment Toolkit (MDT). With its capacity for scalability, MDT is the right tool for the job because it enables you to manage a single image for multiple configurations of hardware and software. Therefore, it is capable of meeting the requirements of any type of deployment. This section gives an overview of the components in MDT and the concepts you’ll need to understand before taking a hands-on tour of MDT in Chapter 3.

The Deployment Workbench

The main user interface in MDT is known as the Deployment Workbench. The Deployment Workbench is presented as a snap-in for Microsoft Management Console (MMC). MMC is a familiar interface that IT Pros are likely to be familiar with, as it is used for other often used tools, such as Disk Management, Services, Event Viewer, and more.

Caution: The first item under the Deployment Workbench is the Information Center, where you will find the documentation for MDT, a getting started guide, and a list of components. It is not recommended to update MDT from the list of components because the incorrect version of the components may be installed. To ensure the latest tools are available to MDT, ensure that the latest version of the Windows ADK is installed.

Deployment Shares

A deployment share is a collection of the major components of MDT which are configured together as a collective unit. It can contain images, applications, drivers, task sequences, boot media, configuration files, and any other deployment component required. A deployment share is essentially a network share in which these components are located. It is hosted as a standard network share and secured through the same permissions and settings as any other folder shared on the network.

After having installed MDT and opening the Deployment Workbench, the Deployment Shares section will be empty, so you’ll need to connect to an existing deployment share or create a new deployment share. When creating a deployment share there are several considerations, as follows:

 Isolation  Scope  Performance  Security

Note: It is important to remember that it is possible to have more than one deployment share, and in many cases it is ideal to have at least two for the reasons outlined in this section. The number of deployment shares that are used in any given environment can vary, but it is common to have more than one.

Isolation

One of the most important reasons to have more than one deployment share is isolation. There are two primary reasons to isolate one deployment share from another:

 The two deployment shares utilize different, incompatible configurations.  Scenarios where deployment shares require different security and permissions.

One common scenario that reflects the need for multiple deployment shares is when one deployment share is configured for a laboratory or testing environment. This deployment share is configured with permissions that permit full access to IT pros and does not contain organizational information such as instructions for the joining of the domain. It is used to prepare base images, test deployment configurations, settings, and applications, and to develop solutions which can be deployed to production deployment shares. Production shares are used to deploy images that are configured to join the domain, permissions are much more restricted, and the deployment solutions may be more automated.

Scope

An important question to ask when considering the number and purpose of separate deployment shares is what those shares are intended to address. In some cases, the scope of a deployment project may be all-encompassing, so the

deployment share must be capable of deploying to an entire organization. In other cases, deployment shares may be only a limited deployment desired for a handful of users or a new set of hardware.

Consider the scenario where a fully developed and implemented solution is available for deploying notebooks and desktops in the organization, but where a handful of Surface Pro 3 devices are being purchased for select users. With these new devices comes the need to ensure that as they reach end users they are configured with select settings required in the organization, but which reflect the new device capabilities, such as touch and Windows 8.1. In this case, you may need to develop a deployment share specific to this new task and initiative.

If you create a new deployment share, you don’t necessarily need to create new images and configure the deployment

from scratch. If you already have images, applications, driver packs, and packages configured, a new deployment share can use those by either copying or linking. This prevents needing to recreate the wheel for your deployments.

It would also be possible to copy the all-encompassing corporate share to a separate server and configured as a new deployment share in which the images, applications, and any other components can be edited, modified, or even removed without disturbing the production share. In this way, an existing corporate image can be quickly modified to apply to new systems without affecting a critical production share.

Performance

In large enterprises, the performance of deployment is a crucial consideration. A deployment share improperly located or configured can result in extended downtime which can translate to work stoppage or loss of productivity. As deployment shares operate over the network, the same performance factors which affect standard file sharing and network communication also apply to deployments through MDT. The same solutions also apply.

For example, in a data center environment for Virtual Desktop Infrastructure (VDI), high performance network connectivity is common to meet the highly demanding nature of the systems in the environment. It would make logical sense in this scenario to ensure that the Deployment Share for those virtual environments was located in the data center for optimum performance. However, even if you have a data center deployment share, it may be better to create a separate deployment share for computers that are in another building or location. The bottom line is that you need to consider the performance of your network in relation to the location of the deployment shares.

Note: Some VDI solutions, such as System Center Virtual Machine Manager, include the ability to manage the creation or replacement of virtual machines.

There may also be scenarios in which offline media is the ideal solution, as MDT is fully capable of generating USB or optical media for physical distribution. Workers who operate remotely from home or contract workers who travel from site-to-site are two examples of where this might apply. Deployment with offline media is covered in the step-by-step process in Chapter 5.

Security

As mentioned before when discussing isolation, security is another important facet in determining how deployment shares should be configured. Beyond the simple concept of a fully open deployment share for system administrators working on the deployment project and another for production users with fully configured security, there are also scenarios where multiple shares can be utilized to provide granular security for targeted deployments.

For example, an organization could operate a deployment share which is available full time to one select set of users who might have the need to refresh their systems at will, but only a limited configuration for deployment is available.

Another deployment share could be used to provide a full-featured deployment across the organization, but is secured so that it is only available to the IT department. Even a third share could be configured with another select deployment configuration and made available only to select groups or users to help facilitate a staggered deployment.

Windows Deployment Wizard

The Windows Deployment Wizard, also known as simply the deployment wizard, is the user interface through which MDT is presented on client or target systems. It can be launched directly through network access to the deployment share or it is the interface presented when launching MDT boot media. The deployment wizard is used to select

between task sequences to run on the client system and to provide any user interaction that wasn’t automated to

complete the deployment process. For example, the deployment wizard can request a computer name or to select between time zones. It can also prompt whether to generate a backup of the computer before deploying the new operating system and whether to encrypt the environment during deployment. An example of a deployment wizard prompt is shown in Figure 2.1.

Figure 2.1. Windows Deployment Wizard Showing Prompt.

The experience provided by the deployment wizard is controlled by a selected task sequence and a configuration file, named customsettings.ini. Customsettings.ini contains settings for technician prompts and supplied answers. For example, automating the process of joining to a domain during deployment can be configured in customsettings.ini. Editing and configuring the customsettings.ini file is shown in Chapter 4 and Chapter 5.

Connectivity to the deployment share is secured by Windows credentials to the network share. When the deployment wizard launches, it will prompt the technician for user credentials each time it is run. However, it is possible to prevent being prompted each time by storing credentials in a configuration file, named bootstrap.ini.

Driver Management

As the Microsoft Deployment Toolkit is able to manage drivers independently of the operating system image, there is a separate section for Drivers in each deployment share. In some scenarios, like a share designed only to deploy to one make and model of computer, you can simply place the available drivers in this section and MDT will automatically select the most up to date applicable drivers for use at the time of deployment.

Note: It is not recommended to leave the drivers section of the deployment share unorganized. Even for a single make and model of computer, different drivers may be required for different environments, such as Windows PE and Windows 8.1. It is always recommended to organize drivers by make/model and operating system.

A deployment share might be used to deploy to many makes and models of computers, or the drivers for a make and model might have incompatibilities with the boot environment. It is recommended to organize your drivers into folders, based on make/model of computer, then by operating system. Within the Drivers section of the deployment workbench folders can be created in which to organize the available drivers and Selection Profiles can be created that target these folders under certain conditions, such as the use of a specific Task Sequence or when certain variables are met.

Selection Profiles are governed by simple configuration files in which a set of components can be selected and identified. Through them the process of selecting application sets, driver sets, and packages can be greatly simplified and automated.

For more details about downloading and configuring Surface Pro 3 drivers and firmware, see Chapter 3 and Chapter 6.

Application Management

Similar to the way drivers are managed, MDT can manage the deployment of applications separate from the operating system image. In order to allow MDT to manage an application, the installation files must first be brought into the deployment share by selecting New Application and specifying the installation files and the commands which apply to the installer. It is also possible to deploy files which are located outside the deployment share, such as if an application installer repository already exists on the network. This is covered in more detail in the Importing Applications section of

Chapter 5.

As outlined in the Considerations for Images section later in this chapter, it is highly recommended to allow MDT to manage as many applications as possible. The reference image should contain only the applications that will never change because they cannot be easily altered after the image is created. For example, you would not build an image with the latest version of Adobe Flash or Oracle Java required for browsing an internal site, because when deploying to another set of computers in the future, you may discover newer versions of those frameworks have become available. When the applications are managed by MDT, you can simply add the updated applications and remove the outdated ones to ensure the latest versions are deployed.

MDT also supports post-deployment only task sequences that facilitate application deployment and operating system configuration. Through these task sequences, the operating system is not re-deployed, but applications can be installed on systems which did not originally receive them. MDT is not a full-fledged application deployment solution as it does not provide management of the deployed systems or applications. For that you would need to implement System Center Configuration Manager. With that said, MDT does support applications to be installed in a base image. Whether this type of configuration is in the best interest of your environment is dependent on the applications in your organization.

Note: MDT provides full support for the management and sideloading of Windows Store apps (APPX). Sideloading is the process of installing modern apps without downloading from the Windows Store. Chapter 4 shows how to manage Windows Store apps with your Windows deployments.

Package Management

Note: The MDT deployment share package management section is, perhaps surprisingly, not provided for management of application packages. Application management is performed by the applications section of the deployment share.

The package management section of a deployment share is provided for management of files provided in the Windows Update Standalone Installer format, .MSU. This can include Windows Updates, language packs, and features such as Remote Server Administration Tools (RSAT) or Internet Explorer. For management of Windows Updates, there are four potential solutions:

1. Windows Update

2. Windows Server Update Service (WSUS)

3. MDT package management

4. Up-to-date images

The least complex method for update management is to allow updates to be provided directly through Windows Update to each computer. This ensures that each environment will receive the full set of applicable updates and management of the process is not required. Though the management effort is reduced when using Windows Update directly on the client computer, the update traffic for each computer is separate and can tax internet connectivity. Downloading updates at the end of the deployment will also increase the deployment time and may require several reboots.

Windows Server Update Services (WSUS) is a feature of Windows Server that provides central management for updates in your organization. This method is recommended in most environments as it provides benefit not only for computers during deployment, but ongoing maintenance. The default deployment process through MDT includes steps that will ensure that updates are applied. Although WSUS aggregates Windows Update traffic on the local network, each computer will still seek to individually communicate with the WSUS server, which does increase demand on the network.

An alternative is to use the package management functionality supplied by MDT to inject the updates into the reference image at the time of deployment. This includes the update packages in the image when it is transferred to the target computer(s) and therefore reduces network traffic. Upon booting of the image the offline injected packages are processed and installed.

The enhance performance, you may want to avoid the installation of offline packages. Instead, the updates can be installed and incorporated into the image by allowing the update process to run and then capturing the image along with updates. This avoids the installation process for each update package, eliminating the time required to run each installation, and reduces network traffic by eliminating duplicate files.

MDT can also be used to manage packages that contain features or packs. Through the selection profile functionality available in MDT, these packages can be targeted to specific computers. An example usage would be to deploy Remote Server Administration Tools (RSAT) for system administrators.

Task Sequences

One of the key mechanisms by which actions are performed by MDT are task sequences. Task sequences are a series of steps that together comprise the actions performed in a deployment and the conditions that control which steps are performed. MDT provides nine out-of-the-box task sequence templates to get you started with task sequences. They are:

 Sysprep and Capture – Task sequences created by this template begins with a reference system, prepares it for

deployment, captures an image, and writes it to the deployment share.

 Standard Client Task Sequence – This template creates a task sequence that includes the default steps for

deploying a Windows client operating system to a new computer or system.

 Standard Client Replace Task Sequence – Task sequences generated from this template are for preparing an

existing operating system for replacement.

 Custom Task Sequence – This template is used to generate a blank task sequence that can be customized.  Litetouch OEM Task Sequence – This template is used by system manufacturers to place an operating system on

a computer for distribution to customers.

 Standard Server Task Sequence – This template is used to create a task sequence for deploying Windows

Server.

 Post OS Installation Task Sequence – Task sequences created from this template can be used to performing any

required task after the operating system is installed. For example, task sequences created from this template can be used to install applications from the deployment share to an already existing Windows environment.

 Deploy to VHD Client Task Sequence – Task sequences created from this template can be used to deploy a

Windows client to a computer using boot to VHD.

 Deploy to VHD Server Task Sequence – Task sequences created from this template can be used to deploy a

Windows Server to a computer using boot to VHD.

Task sequences provide pre-configured processes for deployment tasks that can be controlled or run from the deployment wizard. They can be configured to be manual (allowing the technician to control the process through the supplied prompts and choices), or automated (where the answers to prompts or choices are pre-selected in the task sequence). Task sequences enable the deployment wizard to be configured to prompt the technician for only the essential information, thereby minimizing effort.

Task sequences are often configured to address specific goals or scenarios required during deployment. Here are some examples that show how separate task sequences can be created for each department to address the requirements of that department specifically. The examples below illustrate how it is possible to control the deployment wizard through task sequences to present only preselected options during deployment. Task sequences are shown in more detail in

Chapter 3, Chapter 4, and Chapter 5.

 Financial Department Task Sequence

o Image: Windows 7 Enterprise, required for compatibility with a custom developed application

o Applications: A pre-selected set of applications including Office, accounting software, and the custom

developed application

o Drivers: Drivers are provided for multiple makes/models o BitLocker: Encryption enabled during deployment and enforced by group policy

 Design Department Task Sequence

o Image: Windows 8.1 Update Enterprise o Applications: A choice of available applications including Office and various options for graphics

software

o Drivers: Drivers are provided for multiple makes/models o BitLocker: Encryption is optional during this task sequence

 Sales Department Task Sequence (Surface Pro 3)

o Image: Windows 8.1 Update Enterprise o Applications: A pre-selected set of applications including Office o Drives: A selection profile in which only Surface Pro 3 drivers are available to avoid conflict o BitLocker: Encryption enabled during deployment

Considerations for Images

Creation of the images for use in your deployment environment is one of the most critical tasks for a successful deployment. The configuration of the base image will apply to every machine on which it is deployed. This section discusses best practices for image creation.

The Single Image Goal

In the traditional industry-standard approach for imaging technologies was to create one image for each combination of hardware and software. Even for a single computer make/model in an organization, this can result in a dozen or more images for each possible combination of software. For a dozen computer makes/models, the number of images can climb to well over one hundred. As the number of images increases, so too does the demand on the administrators who manage those images and the infrastructure on which the images reside.

In response to these increasing demands, a solution to increase the efficiency of image management and to help reduce the duplication of tasks was needed. The solution was file-based imaging. Through file-based imaging, a single image can be produced that can be modified to fit multiple scenarios or requirements. For example, for a single computer make/model, a single image can be used with offline servicing and automated application installation to eliminate the need for separate images for each combination of software.

With a deployment solution also supporting automated management of drivers, the need for multiple images can be reduced even further. In an ideal scenario, the use of automated management for applications and drivers can allow an entire organization with varied hardware makes/models and installed applications to be served by a single image. This ideal scenario is commonly known as the single image goal.

Note: This automated management of applications and drivers is provided by the Microsoft Deployment Toolkit (MDT).

To accomplish the single image goal, the image must be configured to be as basic as possible. Only components which are used in all computers and configurations in the organization should be included. The ideal, universal single image is

actually included on the original installation media (either OEM or volume license media) for the operating system. This image file name is install.wim, and is sometimes referred to as the vanilla image.

Although the vanilla install.wim image is the ideal single image, there are a variety of reasons why an organization might elect to create a customized image, such as:

 Customizations only available through Sysprep and image creation

For example: Customization of the local default user profile can only be performed by using Sysprep and an answer file configured with the CopyProfile setting. This instructs Windows Setup to copy the configuration of the Administrator profile to the default user profile before resetting the Administrator profile.

 Deployments of limited scope

For example: If tasked with deploying only to Surface Pro 3 devices with an identical set of applications as quickly as possible, creating a fully-customized image complete with drivers and applications may be quicker than automating application installation.

 Incompatibility with automated installation

For example: Applications that feature only an installation wizard but do not support installation via the command line cannot be deployed outside an image.

 Policy requirements

For example: If an organization’s policy is in place that requires all systems be protected and secured by a third party product, it may be required that this product be included in a custom image to ensure those requirements are met.

Using a Virtual Machine as a Reference System

Though the process of creating a system image includes running Sysprep with the Generalize option (which is designed to remove system specific information and configuration from the image to facilitate deployment to disparate hardware), there are often components which are not compatible with the Generalize process which ultimately interfere with deployment to different hardware. One of the most notable examples are graphics drivers and their associated controlling software. The basic .inf drivers that are stored in the Windows folder are removed by the Generalize step, but components like the NVIDIA Control Panel and AMD Catalyst Control Center are not always reliably removed as they are installed not as drivers, but applications.

To avoid such issues, the best practice is to create images from a reference system which is virtual. Virtual environments are greatly simplified when contrasted against physical systems and do not require any complex drivers which have application style components. There are many virtualization solutions available, and any will work as a platform for image creation. The solution included with Windows Server 2008 and newer is Hyper-V, which is also included with Windows 8 Professional or Enterprise and newer Windows clients.

Note: Images are not compatible across architectures or firmware types. For example, an image of a 64 bit (x86-64) environment cannot be deployed to a 32 bit (x86) environment.

Selecting Applications for the Base Image

Another consideration when planning images is which applications to include in the base image. As described with the single image goal, the ideal configuration for an environment to be captured is as few applications and drivers as possible. With that said, there are certainly times when an application does need to be installed in the base image. For

+ 136 hidden pages