Exam Ref 70-695 Deploying Windows Devices and Enterprise Apps (2015)
Chapter 4. Create and maintain desktop images
After you deploy your deployment infrastructure, you will spend much of your time creating and maintaining images for your client computers. As the administrator, you must understand your imaging options and project requirements so that you can create images to meet or exceed the requirements. To maximize the effectiveness of your images, you need to spend time planning your image strategy before you begin capturing, deploying, and updating images.
Objectives in this chapter:
Objective 4.1: Plan images
Objective 4.2: Capture images
Objective 4.3: Maintain images
Objective 4.1: Plan images
Previous chapters covered the operating system deployment (OSD) infrastructure, the types of deployment, and many of the technologies you use during a deployment project. In this objective, the focus is on the planning aspects of OSD. The most successful deployment projects combine qualified people, the necessary technologies, good execution, time, and money. However, what is sometimes overlooked is the planning. In addition to overall project management, you need technical planning long before you begin installing or configuring anything.
This objective covers how to:
Consider design implications of thin, thick, and hybrid images
Consider design implications of WDS image types
Consider design implications of image format (VHD or WIM)
Consider design implications of number of images based on operating system or hardware platform, drivers, and operating features
Considering design implications of thin, thick, and hybrid images
Now that you have a good understanding of implementing an OSD infrastructure, Lite-Touch installment deployments (LTI), and Zero-Touch installment (ZTI) deployments, you can start planning for your desktop images. There are three primary types of images that you should consider: thin, thick, and hybrid. Your choice of image will be based on the OSD components and types of hardware and software you have and the deployment requirements that usually come from the project.
Thin images
Thin images are the smallest of the available images because they usually do not contain anything except the Windows operating system. If you decide to use thin images, try to minimize the add-ons to the image such as software and customizations. The smaller, the better. There are several characteristics about thin images that you should be familiar with:
Thin images deploy over the network faster than thick images or hybrid images. There are a few common situations when minimizing the network usage is critical:
Deployments run on the production network, and you need to image regularly during business hours. In this case, starting several image deployments at one time could have an impact on the network, depending on how robust the network is.
Your network is outdated or running close to maximum capacity. If your network is already struggling to keep up with demand, adding image deployments to it will probably create serious congestion problems and degrade the user experience.
Your OSD infrastructure requires you to deploy images over a wide-area network (WAN). Although deploying operating system images over a WAN is something to try to avoid, sometimes this is unavoidable in the real world. By using thin images, you can minimize the overall degradation of the WAN for those times when you need to deploy images over it.
Thin images require the most postdeployment work. After a thin image is deployed, you’ve really only installed the base operating system. For users to be productive, they need much more than that. They need applications. Often, they need many applications. They also need security software such as antivirus software and antimalware software. If you use thin images, consider the ramifications of postdeployment tasks. Your goal should be to automate the postdeployment tasks to reduce the administrative overhead of deployment.
Thin images might be vulnerable immediately after deployment because they don’t have any added software and might not have the security protection they need. Until the security software is installed, they can be vulnerable to attack. When using thin images, take this vulnerability into account and consider pushing the security software as the first task after deployment. Technically, as you begin adding software, you are moving your thin image to a hybrid image, which is discussed later in this objective.
Thin images can take up less disk space, but don’t jump to any conclusions with that phrase. Although it is true that the image file types take up less room on a disk, there really isn’t much, if any, disk space savings. You still have to store all the applications on disks, so what you’ve done is separate your disk storage into two parts—one part contains the image, and the other part contains everything else, including the applications. So be wary of claims about thin images using less disk space.
Thick images
Thick images are the largest of the three kinds of images. Think of thick images as the opposite of thin images. Thin images are small. Thick images are large. You build a thick image to contain everything that is needed in an image: the base operating system, the applications, and all customizations. Look at the characteristics of thick images:
Thick images take longer to deploy over the network. In addition, each deployment requires more bandwidth than a thin image or a hybrid image deployment.
Thick images require little or no postdeployment work. Although having no postdeployment work is a good thing, there are some trade-offs. For example, thick images often contain applications that some users or departments don’t use. Some licensed software might have to be purchased for users who never even use the software just because it is automatically installed with the thick image.
Thick images require more predeployment work. Because thick images have more customizations and all the applications, the predeployment image-testing process takes longer.
Thick images are usually too large to fit on media. If you plan to perform media deployments by booting to a DVD or similar media, thick images likely won’t work due to the size of the thick image.
Hybrid images
As you are probably thinking, hybrid images can be described as somewhere between thin images and thick images. They aren’t small. They aren’t large. A hybrid image is very popular because it often meets deployment requirements without the complexity of thin images or the rigidity of thick images. Hybrid images have the following characteristics:
Hybrid images typically contain the operating system, drivers, a few customizations, and the core applications that all employees use. For example, you would install antivirus software, antimalware software, and Microsoft Office 2013. You might also add other applications that the entire company relies on such as Microsoft Lync. For specialty applications such as engineering applications, you would not add them to your hybrid image. Instead, you would deliver those by using Microsoft Application Virtualization (App-V), Group Policy, or another application distribution system.
Organizations that have used thick images but want to move to thin images can use a hybrid image as a stepping-stone. Sometimes, switching from thick images to thin images is too big a leap in a single project. Hybrid images enable you to get a feel for thinner images and ultimately enable you to figure out whether your organization can take advantage of a thin image.
Hybrid images represent a balanced approach to imaging. For many IT administrators, hybrid images are also the most attainable image, often due to limitations in the OSD infrastructure or time constraints.
The Venn diagram shown in Figure 4-1 represents a visual picture of how the different image types relate to each other. On the left are thick images, which often have all your applications. On the right are thin images, which usually do not have any applications. In the middle, the hybrid image has characteristics of thick and thin images.
FIGURE 4-1 Venn diagram of image types
Now that you have a good idea of the characteristics of the image types, you can figure out which image is best suited for your environment. Although you should strive for a single image type and a single image, it isn’t easily achieved. Exceptions, politics, outdated hardware, and other factors always play into your design, so don’t be surprised if you end up with a few different images with each image being used for a particular use case. The diagram in Figure 4-2 shows a simple decision tree to help you quickly see the type of image that best suits your organization.
FIGURE 4-2 Image type flowchart
Considering design implications of WDS image types
Chapter 2, “Implement a Lite-Touch deployment,” defined the four image types you can use in Windows Deployment Services (WDS): boot images, install images, capture images, and discover images. This section focuses more on the design implications and some of the factors that you need to consider before you move forward with a deployment project.
Design implications of boot images
When you think about boot images, it will often be about the operational aspects of boot images that were discussed in previous chapters: creating boot images and using boot images. Although there aren’t many design implications specific to boot images, there are a few design questions to answer concerning boot images:
How many boot images do you need? First, you must determine whether you intend to deploy x86-based computers and x64-based computers. If you do, you must determine whether either of them will require special drivers. If not, you can use a single boot image. If so, you might need more than one boot image.
Do you need any custom boot images? A custom boot image is the boot.wim file from the Windows media plus one or more of the following:
Optional components Optional components are included as part of the Windows Assessment and Deployment Kit (ADK). You can add the components by using the Dism.exe command.
Language packs You can add specific language support to Windows PE by using the Dism.exe command.
Applications or scripts You can add applications or scripts such as startup scripts to your Windows PE image. You can even have your applications launch as part of the Windows PE startup sequence.
Drivers You can add drivers needed at boot-up such as mass storage drivers or network card drivers.
Which optional components do you need to have in the boot images? There are a number of optional components that you can add based on your specific requirements. The following list contains a few of the most used components:
WinPE-HTA This component provides HTML support for WinPE. You can use HTML to build a custom application such as a deployment graphical user interface (GUI).
WinPE-PowerShell This component provides limited Windows PowerShell support inside of WinPE. Note that remote Windows PowerShell is not functional.
WinPE-MDAC This component is needed to establish connectivity to a database. This is helpful when building automation into your deployment process.
More Info: Optional Components Reference
To see a complete list of optional components and understand how to work with them in detail, see the Optional Components Reference page at http://technet.microsoft.com/en-us/library/hh824926.aspx.
Design implications of install images
Install images are the most complex image type. This topic focuses on the design implications of WDS install images and discusses related topics, such as the number of images you should have, in an upcoming section of this chapter. Design implications of install images are limited to the following areas:
Organizing your install images If you manage a high-security environment or a large enterprise environment, you might have a large number of images. Often, you’ll have images for multiple versions of a client operating system, images for multiple versions of a server-based operating system, and images for specific departments. Managing all those images is cumbersome. By using image groups in WDS, you can bring some organization to the images, as shown in Figure 4-3. Image groups organize your images and make it easy for you to grant permissions to multiple images at one time by applying permissions to the image group. In addition, image groups reduce storage usage because they use shared file resources across the image group, which gives you storage performance similar to Single Instance Store (SIS).
FIGURE 4-3 WDS console
Securing your install images For this information, see the “Restricting who can receive images” section in Chapter 2. That section discusses prestaging computers, permissions, and other security enhancements.
Design implications of capture images
You don’t need to think about too much when considering capture images. The concept is very straightforward. Even so, you should be familiar with a couple of factors:
You must determine which capture images you need. If you plan to capture 32-bit computers, you need a 32-bit boot image and a 32-bit capture image. If you plan to capture 64-bit computers, you can use a 32-bit or a 64-bit boot image and a 32-bit or a 64-bit capture image. Often, you can even use just the 32-bit images unless each platform has unique requirements such as custom drivers. Thus, when designing your OSD solution, you should perform a discovery of the existing environment so that you can factor it into your design.
You need to come up with a standard naming convention for your images. This especially applies to boot images and capture images. When you boot to PXE, you are presented with a list of all boot and capture images that are available to you. To avoid confusion, capture images need to be easily distinguishable from standard boot images so that you can select the correct image when you boot to PXE.
Design implications of discover images
Like capture images, discover images are customized boot images. From a design perspective, familiarize yourself with the following concepts:
You need to use discover images when you have computers that can’t boot to PXE. As part of your discovery process, find out whether all the computers can boot to PXE. If not, plan for discover images.
If your design calls for multiple WDS servers, you might want to use a discover image to ensure that a specific WDS server is used. For example, imagine that you work for a company that has an engineering team and a sales team. You use a WDS server for the engineering team and a separate WDS server for the sales team. You can use an engineering-specific discover image when you deploy images to engineering computers and a sales-specific discover image when you deploy images to sales computers.
Considering design implications of image format (VHD or WIM)
As part of your initial design, determine whether you will use .wim files, .vhd files, or both. This section discusses the characteristics of both image formats and the typical use cases for each one.
VHD image characteristics
When you create images for deployment, you can choose to use .vhd files or .wim files. Microsoft introduced the ability for computers to boot to a .vhd file with Windows 7 and Windows Server 2008 R2. Alongside that, WDS was updated to support using .vhd files for images. Although not in widespread use, there are some valid use cases and characteristics that you should be familiar with:
Using .vhd images enables you to set up a computer easily for booting into different operating systems. You could have one .vhd image that runs Windows 8.1 and another that runs Windows Server 2012 R2. Without .vhd images, you would have to partition your hard drive for dual booting.
Deploying a .vhd image to a computer involves just a single file: the .vhd file. This simplifies the deployment and backups.
A .vhd file is portable. It can be used on multiple hardware platforms for testing or recoverability.
In Windows Server 2012, a new virtual hard disk format was released. It uses .vhdx files, which are compatible with Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2.
WIM image characteristics
The Microsoft Windows Imaging (WIM) file format was introduced with Windows Vista. Since then, it has been used as the default image file format for Windows operating system media. A .wim file is also the default file format used when you capture an image in WDS. From a design consideration standpoint, the only consideration is whether your requirements can be met using .wim files. For most use cases, .wim files will meet all your needs. However, .vhd or .vhdx files might be worthy of consideration if you have specific requirements such as dual booting, portability, or reusing a single image on multiple physical computers.
Considering design implications of creating and maintaining multiple images based on operating system or hardware platform, drivers, and operating features
The number of images that will be used in an environment depends strongly on the environment. There will typically be a minimum of two images: one for 32-bit computers and one for 64-bit computers. Additional images might be necessary for additional support for applications. One primary use case for having multiple images is that you need at least one image for the operating system you are deploying. In many organizations, there are multiple versions of client computer and server-based operating systems. It is not uncommon to find organizations that still run some computers on Windows XP while they are migrating to Windows 8.1. On the server side, the move to the latest operating system is usually slower than on the client computing side. It is common to find organizations that have some servers running Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. On the server side, you might not need an installation image for every operating system, especially if only a couple of servers are running one of the operating systems.
Exam Tip
The system architectures are critical in creating and deploying images. Remember that a 32-bit image can be deployed to a 64-bit computer. However, a 64-bit image cannot be deployed to a 32-bit computer.
Another consideration that could affect the number of images depends on whether Microsoft BitLocker will be used during the deployment. To use BitLocker during the deployment process, the computer hardware must have a Trusted Platform Module (TPM). A TPM is a hardware feature, and all your computers might not have it.
Depending on the image type you select, device drivers could affect the number of images that are needed too. Some drivers might interfere with each other and must be thoroughly tested together. When using thick images, drivers that can cause conflicts might need to be installed in separate images or on demand.
Furthermore, the use case of the deployment might require the use of a specific image strategy. As discussed earlier in this chapter, there are three image types: thick, thin, and hybrid. A smaller deployment environment might favor thick images, where the administrative time necessary to configure applications after the deployment would not be needed. In a large environment, however, thin images can speed up the deployment process. Users can then select or specify which applications they need to install for their workload. With that in mind, if a thick image is used in a large organization, you would need to install all applications in the image. The IT department would receive the applications that the Sales department uses, and Sales department users would receive the IT applications. This might not be desirable, especially with certain application licensing models that require a license for each installed computer. However, when using a hybrid image, you can install the core applications that all users need, and the individual department applications can be installed after the operating system deployment. This also avoids conflicts that can arise if two applications are not compatible on the same computer.
As a good practice, try to minimize the total number of images. The more images are in use, the more maintenance and upkeep is required. This also increases the margin for an administrative error maintaining the images. However, a downside of using a single image for each architecture type is that if a problem arises in the image, it could affect all computers in the environment. For example, if a driver update is corrupt, or incompatible with other drivers, not only does it affect the current deployment, it would affect any refresh that would be needed. Therefore, another recommendation is to keep previous versions of image files. This is especially true if a new image file is created for a new hardware platform.
More Info: Choosing a Deployment Strategy
For more information about choosing a deployment strategy, see the article at http://technet.microsoft.com/en-us/library/dd919185%28v=ws.10%29.aspx.
Thought experiment: Windows 8.1 deployment at Tailspin Toys
Tailspin Toys has one office. The company has approximately 800 client computers, half of which are portable computers. The company has a large development group that develops applications for toy stores. The group uses 11 development tools, and all the developers have multiple computers to support their development efforts.
The company plans to upgrade all client computers to Windows 8.1. In addition, the company is planning to reduce the total number of computers by limiting each employee to a single computer. You plan to use the existing Configuration Manager, WDS, and Microsoft Deployment Toolkit (MDT) technologies to assist the company in meeting the requirements. To help you assess your knowledge, answer the following questions:
1. Should you try to use a single install image across the company?
2. To allow the developers to test their applications across multiple operating systems on a single computer, what should you do?
3. Should the development computers be imaged with a thin, thick, or hybrid image?
Objective summary
A thin image is the smallest image type. It often doesn’t contain anything except the operating system.
A thick image is the largest image type. It often contains all the applications in an environment. It takes longer to deploy over the network but often requires less postdeployment work than other image types.
A hybrid image is a cross between a thin image and a thick image. It often contains the operating system and a core set of applications such as Microsoft Office and security software.
You can use a single 32-bit boot image for 32-bit and 64-bit computers. However, a 64-bit boot image is only valid for 64-bit computers.
You can use WDS image groups to organize your install images. By doing so, you can reduce your image storage space requirements while organizing images based on platform, operating system, or security requirements.
You can use the .vhd format or the .wim format for your install images. The .wim format is the most widely used and the default image file format.
A number of considerations factor into your image strategy. Using 32-bit and 64-bit computers, BitLocker, and multiple versions of an operating system can increase the total number of images you need to create, maintain, and deploy.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. You are planning an image strategy for client computers. You must ensure that users have basic operating system functionality immediately following the imaging process. You also need to minimize the image file size. What should you do? (Choose two. Each correct answer represents part of a complete solution.)
A. Use a thin image.
B. Use a thick image.
C. Use a hybrid image.
D. Use a VHD-based thin image.
2. You are planning to deploy 100 training computers that run Windows 8.1. A default installation of Windows 8.1 must be deployed to them. What should you do in WDS?
A. Use the install.wim file from the Windows 8.1 media as an install image.
B. Use the boot.wim file from the Windows 8.1 media as an install image.
C. Use the install.wim file from the Windows 8.1 media as a boot image.
D. Use the boot.wim file from the Windows 8.1 media as a boot image.
3. You are planning a new deployment project with Configuration Manager. The project calls for a deployment of Windows 8.1 (32-bit) and Windows Server 2012 R2. You have portable computers and desktop computers for Windows 8.1 and a single server model for Windows Server 2012 R2. You need to minimize the total number of install images. How many install images should you use?
A. 1
B. 2
C. 3
D. 4
4. You are planning a new deployment project with Configuration Manager. The project calls for a deployment of Windows 8.1 (64-bit). You must also deploy a licensed application to about half of the employees. You must ensure that licensing costs are minimized, and you want to minimize the total number of images. What should you do? (Choose two. Each answer represents a complete solution.)
A. Use a thick image and package the application for postdeployment.
B. Use a thin image and package the application for postdeployment.
C. Use a hybrid image and package the application for postdeployment.
D. Use a thick image and create a filter for the employees who need the licensed application.
5. You are planning a new deployment project with WDS. The project calls for a deployment of Windows 8.1 and Windows Server 2012 R2. You must perform the following deployment tasks as part of the project:
Deploy Windows Server 2012 R2 based on the installation media.
Customize Windows 8.1, which is currently installed on a reference computer, and then create an install image from the reference computer.
Deploy Windows 8.1 to some kiosk computers that are not capable of booting to PXE.
Which of the following WDS image types will you need on your WDS server? (Choose all that apply.)
A. Boot
B. Capture
C. Discover
D. Install
Objective 4.2: Create images
You can create images by using WDS, MDT, or Configuration Manager. The method you use to capture an image is a preference that often depends on the tools you have available.
This objective covers how to:
Prepare the operating system for capture
Create capture images by using WDS
Capture an image to an existing or new WIM file
Capture an operating system image by using Configuration Manager
Preparing the operating system for capture
Chapter 2 discussed some preparation for capturing an image in WDS. This section expands on that information by adding Configuration Manager to the mix. In Configuration Manager, there are two primary methods of preparing an operating system for capture:
Automated configuration
Manual configuration
An automated configuration provides the ability to configure a reference operating system without any manual steps by an administrator. When using an automated configuration method, you create task sequences that deploy software applications, drivers, packages, and any other aspect that must be part of the image. These task sequences can then be reused and customized to create additional images, without the need to re-create a task sequence or configure a new reference computer. However, automated configurations can initially take a long time to create and test. Changes in the requirements for an image can also increase the administrative effort and time required to re-create or reconfigure the task sequences for a new image. Another method of automated configuration could use answer files.
More Info: Using Answer Files
For more information about using answer files, see the “Create and manage answer files” section in Chapter 2.
A manual configuration does not require the additional time to create or test task sequences and enables administrators to set up one computer as a reference computer, just as they would for a user in the organization. This is a faster method of initially creating the first reference computer, but it’s a more error-prone approach because of the manual configuration process. In a manual configuration, an administrator configures settings and installs applications manually. Configuring a reference computer manually requires verification and testing, so not much time is saved over an automated configuration. One major drawback to the manual configuration is that you have to configure settings and install applications on each reference computer. If you have many reference computers, the manual configuration option will cost you extra time.
After you choose a configuration method and perform the desired configuration, prepare the reference computer for capture by using the System Preparation Tool (Sysprep). Chapter 2 discussed the different configuration passes of an answer file that Sysprep uses. The passes of an answer file are:
windowsPE
offlineServicing
generalize
specialize
auditSystem
auditUser
oobeSystem
The generalize pass is specifically used to prepare a computer to be captured as a reference image. As the name implies, the generalize pass of the answer file, and of Sysprep, removes machine-specific information from an operating system, such as the security identifier and some drivers, and enables the image to be used on different computers.
To generalize a computer, Sysprep must be run. Sysprep has both a command line and graphical user interface (GUI). (The command-line interface [CLI] method was discussed in Chapter 2.) To use the GUI, run Sysprep.exe. In Windows Server 2012 R2, sysprep.exe is in the %SYSTEMDRIVE%\Windows\System32\Sysprep folder. To use Sysprep on a different computer, copy the Sysprep folder contents to the desired computer.
After running Sysprep.exe, the System Preparation Tool 3.14 window appears, as shown in Figure 4-4.
FIGURE 4-4 System Preparation Tool 3.14
Figure 4-4 shows Sysprep configured to enter the System Out-Of-Box Experience (OOBE), generalize the system, and then reboot. Alternatively, Sysprep can also be configured in audit mode or to shut down the computer instead of restarting, as shown in Figure 4-5.
FIGURE 4-5 System Preparation Tool 3.14
After the Sysprep process has completed, the reference computer is ready to be captured by using the desired method.
More Info: Sysprep (System Preparation) Overview
For more information about Sysprep, see the article at http://technet.microsoft.com/en-us/library/hh825209.aspx.
Creating capture images by using WDS
Chapter 2 discussed capture images and how to add them to a WDS server by using the GUI. After a capture image has been added to the server, reference computers can boot that image, and then a capture of the reference computer can begin. If the reference computer has been through Sysprep with the generalize pass, any computer that is deployed with the captured image will have an identical operating system configuration but will still perform Windows Setup each time. The Windows Setup process could be fully automated, depending on the deployment method.
More Info: Create an Install, Capture, or Discover Image
For more information about creating a capture image, see the article at http://technet.microsoft.com/en-us/library/cc730837%28v=ws.10%29.aspx.
An alternate method of creating a capture image is to use the WDSutil command. WDSutil is a utility you can use to manage a WDS server. For example, to create a new capture image, run the following command, as shown in Figure 4-6, from an elevated command prompt:
WDSUtil /new-captureimage /image:"Boot" /architecture:x64 /destinationimage
/filepath:E:\Shares\Capture.wim /Name:"New Capture Image"
FIGURE 4-6 WDSutil example
In the WDSutil command and in Figure 4-6, “Boot” is the name of the existing boot image from which the capture image is being created. The architecture is set to 64-bit (x64), and the destination file path of the new capture image is E:\Shares\Capture.wim. The name of the new image is “New Capture Image.” The WDSutil utility requires all the parameters in the example.
Capturing an image to an existing or new WIM file
Before you capture an image from a reference computer, make sure that Dynamic Host Configuration Protocol (DHCP) is already running, PXE is running, and a valid boot and capture image is available in WDS.
To capture an image to WDS, perform the following high-level steps:
1. Prepare a computer with an operating system, applications, and customizations. This computer will be known as the reference computer.
2. Use Sysprep to generalize the operating system of the reference computer by running the Sysprep /generalize /oobe command, as shown in Figure 4-7.
FIGURE 4-7 Sysprep command running
This step is required to capture the image with a WDS capture image. After the command completes, the computer will automatically shut down. If desired, you can use the /reboot switch in the command to reboot automatically after completion.
3. Start the reference computer and press F12 while the computer is starting up. Pressing F12 during startup is required with a default installation of WDS, but you can update the settings so that it isn’t required. By pressing F12 during the startup, the computer boots to PXE. You can configure the computer’s boot order to use the network first, and then you can press Enter to boot to PXE, as shown in Figure 4-8.
FIGURE 4-8 Initial network boot of a VM
4. When you boot to PXE, you are presented with a list of operating systems. The list comes from the available images in WDS. Select the capture image, as shown in Figure 4-9, and then press Enter.
FIGURE 4-9 Windows Boot Manager
5. After booting to a capture image, the WDS Image Capture Wizard launches to begin the capture process, as shown in Figure 4-10. Click Next to continue.
FIGURE 4-10 WDS Image Capture Wizard
6. On the Directory To Capture page, select the volume you want to capture in the drop-down menu, as shown in Figure 4-11. Enter a name and a description before clicking Next. In some cases, you might not see a volume to capture. The most common reason for not seeing it is that the Sysprep /generalize command was not run on it. You can troubleshoot the issue to find out the problem. From the Directory To Capture page, press Shift+F10 to open a Windows PE command prompt. From there, you can check whether the volume you want to capture is available. To do that, run the diskpart command. From the DISKPART prompt, run the list vol command to view the available volumes. In some cases, a storage driver might be needed.
FIGURE 4-11 WDS Image Capture Wizard, selecting the directory to capture
7. On the New Image Location page, select the location to store the image. This can be your local hard drive if it has enough room. It can also be a portable hard drive or a shared folder on the network. To automate the upload of the captured image to WDS, select Upload Image To A Windows Deployment Services Server (Optional). Type the WDS server name, click Connect, and then select the desired image group name. A completed New Image Location page is shown in Figure 4-12. Click Next to continue.
FIGURE 4-12 WDS Image Capture Wizard, selecting the new image location
The capture process can take a long time, depending on the reference computer’s performance and network characteristics such as the latency and bandwidth. During the process, the capture task progress bar appears. When it’s complete, you see a message notifying you that the image was created successfully, as shown in Figure 4-13. Click Finish to complete the process.
FIGURE 4-13 WDS Image Capture Wizard, finishing the process
After the operation completes, check the Install Images folder in WDS to ensure that the image appears, as shown in Figure 4-14.
FIGURE 4-14 WDS console
Capturing an operating system image by using Configuration Manager
If your environment has System Center Configuration Manager, you can also use it to capture reference computers. Configuration Manager uses task sequences to capture images. To build a computer and then capture it in Configuration Manager, perform the following steps.
1. Create a new task sequence from the Operating System folder of the software library. For this example, the Build And Capture A Reference Operating System Image template is used, as shown in Figure 4-15. This performs an automated build of the reference computer with a few applications and then captures it. After selecting the Build And Capture A Reference Operating System Image template, click Next.
FIGURE 4-15 Create Task Sequence Wizard, Create New Task Sequence page
2. On the Task Sequence Information page, shown in Figure 4-16, type a name for the task sequence, such as CaptureSequence. Specify the boot image that will be used as part of the sequence. The boot image must already exist in Configuration Manager for it to appear in the wizard. Click Next.
FIGURE 4-16 Create Task Sequence Wizard, Task Sequence Information page
3. On the Install Windows page, shown in Figure 4-17, choose the install image to use. You can use a custom image that has already been configured or the base install image that can be customized further in the task sequence. The image file must already exist in Configuration Manager for it to appear in the list. Specify any other desired information and then click Next.
FIGURE 4-17 Create Task Sequence Wizard, Install Windows page
4. Specify the workgroup or domain to join, as shown in Figure 4-18. If you specify a domain, you must also specify the organizational unit (OU) and domain account to use.
FIGURE 4-18 Create Task Sequence Wizard, Configure Network page
5. Select the default package to install the Configuration Manager client on the target computer and image, as shown in Figure 4-19. By default, the Configuration Manager Client Package is selected. You can select another package that has been added in ConfigMgr instead.
FIGURE 4-19 Create Task Sequence Wizard, Install Configuration Manager page
6. Choose which action to take for updates that have been assigned to the computer, as shown in Figure 4-20. The available options are:
Install Mandatory Software Updates.
Install All Software Updates.
Do Not Install Any Software Updates.
FIGURE 4-20 Create Task Sequence Wizard, Include Updates page
Select the desired action and then click Next.
7. By using a task sequence, you can also install software that has been added in Configuration Manager, as shown in Figure 4-21. Adding software by using the task sequence can increase the time to configure the reference computer initially. However, by doing so, you can save much time later, when an upgrade or modification is necessary. Add the desired software and then click Next.
FIGURE 4-21 Create Task Sequence Wizard, Install Applications page
8. The System Preparation page appears, as shown in Figure 4-22. System preparation is not necessary for this example, so click Next to continue.
FIGURE 4-22 Create Task Sequence Wizard, System Preparation page
Exam Tip
System preparation is only necessary when deploying operating systems prior to Windows Vista. Beginning with Windows Vista, the necessary version of Sysprep is included with the operating system files. Therefore, this screen is used only when deploying Windows XP or Windows Server 2003.
9. The Image Properties page, shown in Figure 4-23, contains metadata for use and reference by the administrator who is managing the images. Define the desired values for the Created By, Version, and Description fields and then click Next.
FIGURE 4-23 Create Task Sequence Wizard, Image Properties page
10. On the Capture Image page, shown in Figure 4-24, specify the path to save the image and the user account to use for access to the path.
FIGURE 4-24 Create Task Sequence Wizard, Capture Image page
11. The Summary page displays all the configured settings, as shown in Figure 4-25. If all the settings look correct, click Next to create the task sequence.
FIGURE 4-25 Create Task Sequence Wizard, Summary page
After you click Next, the task sequence will be created, as shown in Figure 4-26. It will then be available to run on target computers to install the defined image, customize any settings, and capture it.
FIGURE 4-26 Create Task Sequence Wizard, Completion page
After the task sequence has been created, it can be deployed to collections.
Microsoft Virtual Academy: System Center Configuration Manager
The Microsoft Virtual Academy offers free training, which is delivered by industry experts. For this exam, System Center Configuration Manager plays a big role. If you haven’t had a chance to use it, take a look at the overview of the System Center 2012 Configuration Manager course on Microsoft Virtual Academy. It covers a number of relevant features for the exam and lasts a little bit longer than an hour. It is available at http://www.microsoftvirtualacademy.com/training-courses/overview-and-infrastructure-changes-in-sccm-2012.
Thought experiment: Windows build and capture project at Tailspin Toys
You are a client systems engineer for Tailspin Toys. The company uses Configuration Manager and WDS to automate its client computer deployments. You are working on a new deployment project that has the following requirements:
Deploy a new reference computer with several applications and then capture the reference computer to an install image.
Automate as many of the tasks as possible.
To help you assess your knowledge, answer the following questions:
1. Should you use Configuration Manager or WDS to deploy the new reference computer? Why?
2. You are about to capture a reference computer, but you run into an error. How can you troubleshoot from Windows PE?
3. Upon booting to PXE, you see several images. Only one of them is listed as a capture image. How do you explain this?
Objective summary
A reference computer can be prepared manually or automated. An automated build often includes applications and other customizations that you would perform manually in a manual preparation scenario.
Manually configuring reference computers can be error prone and isn’t scalable.
Automated configurations can take a long time to develop initially but are customizable and upgradable.
Sysprep can be used from the command line or the GUI to prepare a reference computer. The command line is the most common usage.
Generalizing a reference computer enables the image to be deployed to other computers. If you don’t generalize a reference computer, most of the deployment tools will not capture the computer.
WDS capture images are used to create an install image from a reference computer.
ConfigMgr task sequences can be used to deploy an image and capture an image. You can do the tasks separately or as part of one task sequence.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which operating system component is removed during the generalize pass of Sysprep?
A. Default user profile
B. Security identifier
C. User applications
D. Application metadata
2. You want to ensure that Office 2013 is part of a new build and capture task sequence. What should you do before creating the task sequence?
A. Add Office 2013 to the boot image in the task sequence.
B. Create a new package for Office 2013.
C. Create a new application for Office 2013.
D. Create a Windows Sideloading key.
3. Which of the following must you preconfigure in ConfigMgr to create a task sequence for deployment? (Choose two. Each correct answer provides part of a complete solution.)
A. Windows install image
B. Windows capture image
C. Windows boot image
D. Windows VHD-based capture image
4. Which operating system began bundling system preparation files with the operating system?
A. Windows XP
B. Windows Server 2003
C. Windows Vista
D. Windows 7
5. When using ConfigMgr, where is the captured image stored?
A. Network path
B. Local path
C. ConfigMgr repository
D. WDS repository
Objective 4.3: Maintain images
Managing a successful deployment architecture over an extended period of time requires regular maintenance to ensure its effectiveness. The first image you put into production will be relative at that moment, but over time things need to be added, removed, and updated. So far, this book has reviewed technologies such as WDS, MDT, and Configuration Manager. These applications provide ways of simplifying regular maintenance tasks. Objective 4.3 explores the Deployment Image Servicing and Management (DISM) tool.
This objective covers how to:
Update images by using DISM
Apply updates, drivers, settings, and files to online and offline images
Apply service packs to images
Manage embedded applications
Updating images by using DISM
DISM is a command-line tool that was designed to service Windows images. You can use this tool to manage Windows Imaging files (.wim) or virtual hard disks (.vhd or .vhdx). DISM provides management capabilities for both online and offline images. There are two methods for servicing an image by using DISM.
Servicing online images This task involves the manipulation of a running operating system by using the DISM tool. Some available actions include:
Adding language packs
Enabling or disabling Windows features
Retrieving installed drivers and packages
Servicing offline images This task involves the manipulation of a Windows image file or virtual hard disk. In most scenarios, offline servicing involves mounting the image by using DISM. From there, you manipulate the image and commit your changes. Some available actions include:
Adding and removing drivers
Adding and removing Windows features
Adding and removing language packs
Applying Windows updates
Applying configuration settings by using unattend.xml
The DISM tool provides a number of benefits:
DISM is compatible with Windows 7, Windows 8, and Windows 8.1. Previous tools, such as ImageX, were deprecated with the introduction of Windows 8.
DISM comes preinstalled with Windows 8.1 and Windows Server 2012 R2. This makes it easily accessible.
DISM is a command-line tool. This gives you the flexibility to automate simple maintenance tasks such as applying Windows updates.
Before using DISM, you must meet a few prerequisites. First, become familiar with the list of compatible operating systems. The DISM tool is supported across the following operating systems:
Windows PE 3.0, Windows PE 4.0, and Windows PE 5.0
Windows 7, Windows 8, and Windows 8.1
Windows Server 2008 SP2 and Windows Server 2008 R2
Windows Server 2012 and Windows Server 2012 R2
You need a reliable build environment for creating and managing your images by using DISM. This should include the reference computer that you plan to use for capturing images and a stable administrative system for servicing your images. DISM has been around since Windows Vista and now comes preinstalled with Windows 8 and Windows 8.1, but the latest release is also available through the Windows Assessment and Deployment Kit (Windows ADK). Keep in mind that older versions of the DISM tool are not compatible with newer Windows versions. For example, the version of DISM that was released to service Windows 7 images will not work with Windows 8 images. Alternatively, you can download and install the Windows ADK, which includes the latest DISM binary and associated files.
You must also know how to run DISM. This command-line tool requires elevated privileges to run commands successfully, so start by opening an elevated command prompt. Running the tool is as simple as running Dism.exe /option. Many of the DISM tasks can be performed with Windows PowerShell. These can be run using an elevated Windows PowerShell prompt.
In the following example, you take the install.wim file from the Sources folder of the Windows 8.1 installation media and retrieve the image file details, as shown in Figure 4-27.
FIGURE 4-27 Elevated command prompt, DISM Get-ImageInfo
From an elevated command prompt, run the following command:
Dism.exe /Get-ImageInfo /ImageFile:C:\test\images\install.wim
The output of this command provides the following details:
DISM version The version number for the DISM tool. If you need to work with an older operating system, you might need to reference this version number to know whether the operating system and DISM are compatible.
Index number The index number for the corresponding Windows image. DISM enables you to embed multiple images in a single file.
Name The name associated with the Windows image.
Description The description that was given to the image.
Size The actual file size of the Windows image in an uncompressed state.
From an elevated Windows PowerShell prompt, you can get the same results using the Get-WindowsImage -ImagePath C:\test\images\install.wim command, as shown in Figure 4-28.
FIGURE 4-28 Elevated Windows PowerShell prompt showing image info
More Info: What is DISM?
For more information about the basics of DISM and compatibility, see http://technet.microsoft.com/en-us/library/hh825236.aspx.
Applying updates, drivers, settings, and files to online and offline images
Previous chapters covered the various methods for capturing a reference image. This objective focuses on servicing existing Windows images. The actions taken to service an image do not depend on how or when the image was created. DISM can be used with any supported .wim, .vhd, or .vhdx file.
Applying updates
Applying the latest Windows updates to an image is a relatively easy action. There are numerous ways to achieve the result, some easier than others. DISM handles the update task in four fundamental steps. As you progress through this objective, notice that these steps share a common framework for handling the majority of the servicing needs. The steps include:
Mounting the image
Applying the desired Windows updates
Committing the changes
Unmounting the image
Before proceeding, become familiar with the following prerequisites:
The Windows image file (.wim) must be saved to a local directory.
You need an empty folder with enough free space to mount the image.
You need a folder with the software updates that need to be applied.
In the following example, a series of updates is applied to an offline Windows 8.1 image, using the steps previously outlined. Before making any changes, first retrieve a list of the installed packages.
1. From an elevated command prompt, run the following command to mount the Windows image file, as shown in Figure 4-29:
Dism.exe /Mount-Image /ImageFile:C:\test\images\install.wim /Index:1
/MountDir:C:\test\offline
FIGURE 4-29 Elevated command prompt, DISM Mount-Image command
The same action can be accomplished through Windows PowerShell by using the Mount-WindowsImage cmdlet:
Mount-WindowsImage –ImagePath C:\test\images\install.wim –Index 1 –Path C:\test
\offline
2. Run the following command to see all the packages currently installed in the image.
The list will be in chronological order, starting with the oldest package first, as shown in Figure 4-30. The applied update is at the bottom of the list.
Dism.exe /Image:C:\test\offline /Get-Packages /Format:Table
FIGURE 4-30 Elevated command prompt, DISM Get-Packages command
The same action can be accomplished through Windows PowerShell, using the Get-WindowsPackage cmdlet:
Get-WindowsPackage –Path C:\test\offline
Both of these commands can also be used with online images to review current package inventory.
The preceding output indicates which updates have already been applied and the associated time stamp. Now you apply the update.
3. Run the following command to apply the desired Windows update, as shown in Figure 4-31:
Dism.exe /image:C:\test\offline /Add-Package /PackagePath:C:\test\updates
\Windows8.1-KB2994897-x64.msu
FIGURE 4-31 Elevated command prompt, DISM Add Package command
The same action can be accomplished by using the Add-WindowsPackage cmdlet in Windows PowerShell:
Add-WindowsPackage –Path C:\test\offline –PackagePath C:\test\updates
\Windows8.1-KB2994897-x64.msu
4. Run the following command to commit the changes to the image, as shown in Figure 4-32:
Dism.exe /Commit-Image /MountDir:C:\test\offline
FIGURE 4-32 Elevated command prompt, DISM Commit-Image command
The same action can be accomplished by using the Save-WindowsImage cmdlet in Windows PowerShell:
Save-WindowsImage –Path C:\test\offline
5. Run the Get-Packages command again (as in Step 2) to confirm that the installed update is listed in the table with a matching time stamp.
6. Run the following command to dismount the updated image, as shown in Figure 4-33. Note that /Unmount-Image requires you to include the commit action or discard any changes that weren’t previously committed.
Dism.exe /Unmount-Image /MountDir:C:\test\offline /Commit
FIGURE 4-33 Elevated command prompt, DISM Unmount-Image command
7. The same action can be accomplished through Windows PowerShell by using the Dismount-WindowsImage cmdlet:
Dismount-WindowsImage –Path C:\test\offline -Save
The preceding steps outlined the procedure for applying a single update or, possibly, a handful of updates if you don’t mind rerunning the same command a few times. For bulk changes, you should create a Windows PowerShell script to automate repetitive steps.
More Info: Applying Windows Updates by Using a Windows PowerShell Script
For more information about applying Windows updates in bulk, along with a sample script, see http://blogs.technet.com/b/configmgrdogs/archive/2012/02/15/applying-windows-updates-to-a-base-wim-using-dism-and-powershell.aspx.
You can remove packages from images by using Remove-Package DISM, as shown in Figure 4-34. Alternatively, you can use the Remove-WindowsPackage Windows PowerShell cmdlet.
FIGURE 4-34 Elevated command prompt, DISM /Remove-Package command
More Info: Additional Package Servicing Commands
For more information about servicing packages, see http://technet.microsoft.com/en-us/library/hh825265.aspx.
Applying drivers
Device drivers are another fundamental piece when managing images. The process for applying device drivers uses the same framework as described when applying Windows updates. However, drivers gain an advantage when it comes to bulk imports due to a recursive switch.
The prerequisites for this procedure are that:
The Windows image file (.wim) must be saved to a local directory.
An empty directory must be available to mount the image.
You need a folder with the device drivers that need to be applied.
An adequate amount of free disk space must be available on the system that you will be mounting the image on.
In the following example, you add a series of network drivers to the same offline image. Before making any changes, first retrieve a list of the installed drivers.
1. From an elevated command prompt, mount the Windows image file:
Dism.exe /Mount-Image /ImageFile:C:\test\images\install.wim /Index:1
/MountDir:C:\test\offline
2. Run the following command to retrieve a list of currently installed device drivers, as shown in Figure 4-35:
Dism.exe /Image:C:\test\offline /Get-Drivers
FIGURE 4-35 Elevated command prompt, DISM Get-Drivers command
The same action can be accomplished through Windows PowerShell by using the Get-WindowsDriver cmdlet:
Get-WindowsDriver –Path C:\test\offline
Both commands can also be used with online images to review current device driver inventory.
The output indicates what device drivers have already been applied with their associated time stamp. Now you apply the drivers.
Run the following command to add the desired device drivers, as shown in Figure 4-36. Note that you are using the /ForceUnsigned switch to ensure that any unsigned drivers are also added. This switch is not necessary if you are adding signed drivers.
Dism.exe /Image:C:\test\offline /Add-Driver /Driver:C:\test\drivers\ /recurse
/ForceUnsigned
FIGURE 4-36 Elevated command prompt, DISM Add-Driver command
The same action can be accomplished by using the Add-WindowsDriver cmdlet in Windows PowerShell:
Add-WindowsDriver –Path C:\test\offline –Driver C:\test\drivers\ -Recurse
This is a good opportunity to rerun the DISM command with Get-Drivers to confirm that the device drivers are listed and have a matching time stamp.
1. Run the following command to commit the changes:
Dism.exe /Commit-Image /MountDir:C:\test\offline
2. Run the following command to unmount the image, as shown in Figure 4-37:
Dism.exe /Unmount-Image /MountDir:C:\test\offline /Commit
FIGURE 4-37 Elevated command prompt, DISM Remove-Driver command
Similar to working with packages, you can also remove a device driver, if necessary, by using DISM Remove-Driver or the Remove-WindowsDriver Windows PowerShell cmdlet.
More Info: Additional Driver Servicing Commands
For more information about servicing drivers, see http://technet.microsoft.com/en-us/library/hh825070.aspx.
Applying settings
Up to this point, you have explored the processes for mounting an image, applying packages and drivers, saving those changes, and dismounting the image. You can run each of the commands manually or add it to a script to help automate routine maintenance. Another option is to implement an answer file that provides options for an unattended installation. An answer file is an XML-based file that contains setting definitions and values to use during Windows Setup. In the case of DISM, you would use the offlineServicing pass, which runs during Windows Setup. During this pass, any settings defined in the answer file will be triggered automatically. This can include tasks such as installing packages, software updates, and device drivers.
Applying an answer file to your image can reduce the overhead incurred with manually applying changes. Using this solution offers a few key benefits:
Simplicity With this configuration, drivers can be added on the fly, without the need to update the image and reseed it to your deployment architecture.
Speed Uploading new drivers to their source location makes them immediately available to any new image deployments.
Consistency Using the same answer file in all your images ensures that all deployments are consistent with the desired configuration.
You can create an answer file by using the Windows System Image Manager (Windows SIM), which is included as part of the Windows ADK. This tool ensures that the answer file is formatted properly based on the operating system, and it includes a built-in error checker. In the following example, you see two sections of a sample answer file, demonstrating the solution for package and driver management.
Real World: Managing Device Drivers with an Answer File
I worked in an environment that used DISM and local USB media for regular image deployments. The USB drives were limited on storage, so image size was an important factor for the deployments. In this environment, the customer had to support a variety of computer models from multiple vendors. At one point, we had driver support for 16 hardware models. It was apparent that using the DISM Add-Driver command to inject all 16 models would not work. This was when a properly formatted answer file came in handy. I set up a centralized network share with each hardware model and then pointed the answer file to the share. This approach prevented unnecessary image bloat and gave the customer the flexibility to update the drivers in an easy way.
Managing packages in an answer file is straightforward. First, create a distribution share.
1. Open Windows System Image Manager.
2. In the Distribution Share pane, right-click an empty area and then click Create Distribution Share.
3. Type the path to the share and then click Open. Three folders are created in the distribution share as part of this process.
4. Next, populate the Packages folder with the packages (.cab files) you want to include in the image.
5. In the Windows SIM console, right-click the Packages folder and then click Add To Answer File.
The package details and share location will be imported into the answer file.
The XML code for package servicing looks similar to the example shown in Figure 4-38.
FIGURE 4-38 Unattend.xml, servicing pass, packages
Adding a driver source location to the answer file is another quick addition. Follow these steps:
1. Open Windows System Image Manager.
2. In the Windows Image pane, expand Components and then add the following component to pass 2 – offline servicing:
amd64_Microsoft-Windows-PnpCustomizationsNonWinPE_6.3.9600.16384_neutral
3. In the main window, as shown in Figure 4-39, right-click the new component and then click Insert New PathAndCredentials. Fill in the appropriate fields.
FIGURE 4-39 Windows System Image Manager, PnP Customization, Drivers
The XML code for driver servicing looks similar to the example shown in Figure 4-40.
FIGURE 4-40 Unattend.xml, servicing pass, drivers
After creating a working answer file, you can use DISM to apply the settings to the image. Applying an answer file in this way will only apply the offlineServicing configuration pass and any included packages.
The following example applies the newly created unattend.xml to the Windows 8.1 image. The same fundamentals about mounting the image, committing the changes, and then dismounting apply in this scenario.
1. From an elevated command prompt, mount the Windows image file:
Dism.exe /Mount-Image /ImageFile:C:\test\images\install.wim /Index:1 /MountDir:C
:\test\offline
2. Run the following command to apply the unattend.xml answer file to the image, as shown in Figure 4-41:
Dism.exe /Image:C:\test\offline /Apply-Unattend:C:\test\answerfile\unattend.xml
FIGURE 4-41 Elevated command prompt, DISM /Apply-Unattend command
The same action can be accomplished through Windows PowerShell, using the Use-WindowsUnattend cmdlet:
Use-WindowsUnattend –Image C:\test\offline –UnattendPath C:\test\answerfile
\unattend.xml
3. Run the following command to commit the changes:
Dism.exe /Commit-Image /MountDir:C:\test\offline
4. Run the following command to unmount the image:
Dism.exe /Unmount-Image /MountDir:C:\test\offline /Commit
With the answer file applied, the image now references the settings that have been defined. To make changes to an applied answer file, reapply the updated file through another mount/unmount session.
More Info: Learn More about Windows SIM and Answer Files
For more information about Windows System Image Manager, see http://technet.microsoft.com/en-us/library/cc766347(v=ws.10).aspx.
Applying files
Earlier in this section, you explored mounting a WIM file by using DISM. The mount action requires you to define an empty mount folder. After the image is mounted to that folder, the file system is accessible for additional servicing. At this point, manipulating files and folders is a very simple task. In various scenarios, servicing files and folders can be useful. Some examples include:
Creating a task-specific directory structure This could include something as simple as a folder at the root path, called XYZ Setup. Files necessary for your image deployment could then be saved to this directory, ensuring their availability during the image sequence. You can then use an answer file to call those files.
Embedding an answer file This enables you to use the other sections of an answer file to simplify your deployment further. Items such as partitioning a disk drive or configuring a time zone could be set with the answer file.
Real World: Managing Files and Folders by Using DISM
During an early deployment of Windows 7, I had a customer that was heavily dispersed geographically and lacked a reliable way of mirroring its central network share to all its remote offices. This made it difficult to use network share points for retrieving image content such as packages. In this scenario, we decided that storing the basic setup scripts and applications in a directory at the root of the image was a suitable solution. This made the image size larger but gave the customer an all-in-one solution. The deployment team was able to image computers in offices with very poor connectivity. The imaging was performed offline with media and without access to ConfigMgr, WDS, or MDT. The only activity that required connectivity was joining the Active Directory Domain Services domain. To accomplish this, I created a setup folder at the root of the image, stored all the necessary components there, and used the RunSynchronous command in their answer file to execute a series of scripts that handled the setup and cleanup procedures.
In the following example, a Windows 8.1 image is mounted and then a custom answer file is applied along with a script to clean up the unattend.xml after the image completes. The cleanup routine is captured using the SetupComplete.cmd file. After Windows is installed, but before the logon screen appears, Windows Setup searches for the SetupComplete.cmd file in the %WINDIR%\Setup\Scripts directory. If the file is found, it will run automatically, using local system privileges. The actions are recorded in the Setupact.log file.
1. From an elevated command prompt, mount the Windows image file:
Dism.exe /Mount-Image /ImageFile:C:\test\images\install.wim /Index:1
/MountDir:C:\test\offline
2. Open File Explorer and navigate to the mounted image directory structure. Proceed to the Sysprep folder (C:\test\offline\Windows\System32\Sysprep).
3. Copy a working copy of the unattend.xml into the Sysprep folder.
4. Navigate to the Setup folder (C:\test\offline\Windows\Setup).
5. Create a folder named Scripts.
6. Create a text file named SetupComplete.cmd within the Scripts folder.
7. Open the text file, type the following two lines, as shown in Figure 4-42, and then save the changes:
del /q /f c:\windows\system32\sysprep\unattend.xml
del /q /f c:\windows\panther\unattend.xml
FIGURE 4-42 SetupComplete.cmd, unattend.xml file cleanup
8. Run the following command to commit the changes:
Dism.exe /Commit-Image /MountDir:C:\test\offline
9. Run the following command to unmount your image:
Dism.exe /Unmount-Image /MountDir:C:\test\offline /Commit
With these changes applied, this image now references the embedded answer file during deployment. After the image deployment completes, the SetupComplete script runs and removes the answer file. Most content within an answer file is viewable in plaintext, so removing the file is a good security practice.
Applying service packs to images
Major content updates such as service packs and update rollups can put a snag in your image deployment process. When it is time to include these updates in your image, you can take a few directions. DISM offers a solution for servicing existing images, enabling you to install these major content updates without rebuilding from scratch.
First, understand the files incorporated with the update that you need to apply. The following example uses Windows 8.1 Update 1 (also known as KB 2919355), which incorporates a rollup of all the updates released between Windows 8.1 RTM and Windows 8.1 Update 1. This update is also required to receive future updates from Microsoft. The Knowledge Base article for this update indicates that Update 1 consists of a series of Microsoft update files (.msu) that must be installed in a particular order.
Retrieve the associated update files and prepare a workspace for updating the existing image. These updates are installed in sequence and then reviewed using the Get-Packages command.
1. Download the necessary update files and store them in a directory titled Update1.
2. From an elevated command prompt, mount the Windows image file:
Dism.exe /Mount-Image /ImageFile:C:\test\images\install.wim
3. Use the DISM Add-Package command to add the updates in the C:\test\updates folder:
Dism.exe /image:C:\test\offline /Add-Package /PackagePath:C:\test\updatesReview
the list of install packages and validate:
Dism.exe /Image:C:\test\offline /Get-Packages /Format:Table
4. Run the following command to commit the changes:
Dism.exe /Commit-Image /MountDir:C:\test\offline
5. Run the following command to unmount the image:
Dism.exe /Unmount-Image /MountDir:C:\test\offline /Commit
With the image updated, a few additional steps need to be completed. The image needs to be installed on a reference computer and booted to complete the first-boot initialization pass associated with Update 1. Going through this process helps you in the following areas:
Complete initial patch startup Without booting the image, you see that subsequent deployments have delays at startup while the system initializes.
Cleanup files Update content can quickly become outdated or replaced by future rollups. Cleaning these files up after installation can save hard-drive space and reduce the image footprint.
Validating and testing Booting the image gives you an opportunity to verify that the updates were installed successfully and that Windows is reporting the proper version.
After applying the image, boot your reference computer into audit mode by pressing Ctrl+Shift+F3 at the OOBE screen during the initial boot process.
In audit mode, allow Windows to finish initializing and then confirm that the updates are installed properly.
1. Run the following command to report current installed packages:
Dism.exe /Online /Get-Packages
After the updates are confirmed, clean up the image.
2. Run the following command to clean up any remaining components:
Dism.exe /Cleanup-Image /Online /StartComponentCleanup /ResetBase
/StartComponentCleanup Cleans up component stores and reclaims space.
/ResetBase Removes all superseded versions of every component in the component store.
At this stage, you are ready to recapture the image. To do this, run Sysprep first and then boot into Windows PE to begin the capture process.
1. Prepare the system by using the following command:
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown
2. Boot the computer by using a Windows PE boot image. This is necessary to capture the image.
3. Run the following command to capture the image:
Dism.exe /Capture-Image /ImageFile:"\\networkshare\share\images\updated_install
.wim" /CaptureDir:C: /Name:"Windows 8.1 Enterprise Update 1"
The same action can be accomplished by using the New-WindowsImage cmdlet in Windows PowerShell:
New-WindowsImage –ImagePath "\\networkshare\share\images\updated_install
.wim" –CapturePath C:\ -Name "Windows 8.1 Enterprise Update 1"
The updated image is saved to the network path you provided. From there, you can reapply any answer files, packages, or drivers. Note that this updating scenario is only one example, but generally, any large-scale changes should be validated on a reference computer and recaptured to ensure a working baseline.
More Info: Learn More about Capturing Images by Using DISM
For more information about capturing images with DISM, see http://technet.microsoft.com/en-us/library/hh825072.aspx.
Managing embedded applications
Application management is a suitable topic to address now that you are more familiar with the capabilities of DISM. A variety of techniques for servicing a Windows image have been covered, most of which can be used to manage embedded applications. These are some of the available options that have been reviewed:
Mount an image and use the DISM Add-Package command to apply updates to embedded Windows applications. This requires a compatible .cab or .msu package and is limited to Windows applications.
Mount an image and apply an answer file that installs or updates applications. The answer file can be used to run commands or execute a script that updates the target applications.
Mount an image and modify the application through file and folder access. This is more ideal for configuration-based files such as .ini files.
Mount an image and incorporate the SetupComplete script, which can be used to install or update applications after an image deployment.
A topic not yet addressed in detail is Windows features. DISM is tightly integrated with the Windows Feature component, enabling you to service feature changes in online and offline images. DISM provides options for displaying all available Windows features, displaying status (enabled or disabled), and allowing you to enable or disable them.
The following example reviews the available servicing options related to Windows features. The focus is on retrieving a list of available features and enabling the Telnet client in Windows 8.1, using online servicing options. You can use these same steps for an offline image by using the corresponding options.
1. Run the following command to retrieve a list of all available Windows features, as shown in Figure 4-43. The output provides Feature Name and State (enabled or disabled).
Dism.exe /Online /Get-Features
FIGURE 4-43 Elevated command prompt, DISM Get-Features command
The same action can be accomplished by using the Get-WindowsOptionalFeature cmdlet in Windows PowerShell:
Get-WindowsOptionalFeature -Online
2. Run the following command to retrieve more information about the Telnet client, as shown in Figure 4-44:
Dism.exe /Online /Get-FeatureInfo /FeatureName:TelnetClient
FIGURE 4-44 Elevated command prompt, DISM Get-FeatureInfo command
The same action can be accomplished by using the Get-WindowsOptionalFeature cmdlet in Windows PowerShell:
Get-WindowsOptionalFeature –Online –FeatureName TelnetClient
3. Run the following command to enable the Telnet client, where /All enables all parent features, as shown in Figure 4-45:
Dism.exe /Online /Enable-Feature /FeatureName:TelentClient /All
FIGURE 4-45 Elevated command prompt, DISM Enable-Feature command
The same action can be accomplished by using the Enable-WindowsOptionalFeature cmdlet in Windows PowerShell:
Enable-WindowsOptionalFeature –Online –FeatureName TelnetClient –All
You can service an offline image to enable or disable specific features by mounting the image and applying the desired changes. Alternatively, you can incorporate these changes by using an answer file.
1. Open Windows System Image Manager.
2. Under Windows Image in the left pane, expand Packages > Foundation.
3. Right-click Microsoft-Windows-Foundation-Package and then click Add To Answer File.
4. Select the new component in the main window, as shown in Figure 4-46. Toggle the appropriate features for your deployment to their proper state and save your changes.
FIGURE 4-46 Windows System Image Manager, Foundation, Windows Features
More Info: Enable or Disable Windows Features by Using DISM
For more information about enabling or disabling features, see http://technet.microsoft.com/en-us/library/hh824822.aspx.
Thought experiment: Maintaining and updating images at Tailspin Toys
Tailspin Toys has hired you to help update a series of Windows images. This is a small organization of 150 employees in a single office. Tailspin Toys has a mixed environment and supports both a Windows 7 image and a Windows 8.1 image. The team has asked you to implement a maintenance solution to assist with monthly image updates.
You need to prepare an updated image that can be serviced more easily. To help you plan better for the project, answer the following questions:
1. The system administrator at Tailspin Toys has manually injected dozens of drivers into the Windows images, many of which are now outdated. Which method can you use to uninstall the drivers?
2. The Windows 7 image is lacking Service Pack 1, but the image has very little customization. How would you go about providing an updated Windows 7 image that includes Service Pack 1?
3. Tailspin Toys needs a solution that allows it to update drivers and packages without regularly updating its Windows image. What addition can you make to the images to alleviate the need to update the image regularly?
Objective summary
DISM supports adding and removing Windows features.
Adding and removing Windows features can be performed with online and offline images.
Unattended answer files can be implemented to enable and disable the appropriate Windows features.
Windows updates and device drivers are serviceable products that can be applied to offline images by using DISM.
DISM can retrieve applied updates and drivers from offline and online images.
An unattended answer file can be applied to an offline image to simplify package and driver updates.
Windows images mounted with DISM can be manipulated at a file and folder level.
Major content updates and patch rollups can be implemented using DISM.
Audit mode is a preproduction environment that enables an administrator to customize an image and validate changes.
DISM can be used to capture a reference computer and save the image to a local or remote location by using the Capture-Image command.
DISM requires elevated permissions to run.
Many of the DISM commands have a Windows PowerShell alternative.
Objective review
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
1. Which of the following file types does DISM support for online and offline servicing? (Choose all that apply.)
A. WIM
B. VHD
C. VHDX
D. ISO
2. You need to apply the latest Windows updates to an existing install image. Which of the following sequences of tasks should you use?
A. Mount the image, apply the updates, unmount the image, and commit the changes.
B. Mount the image, apply the updates, commit the changes, and unmount the image.
C. Apply the updates, mount the image, commit the changes, and unmount the image.
D. Apply the updates, mount the image, unmount the image, and commit the changes.
3. Which pass of Windows Setup does DISM use to install device drivers to an image?
A. specialize
B. offlineServicing
C. windowsPE
D. generalize
Answers
This section contains the solutions to the thought experiments and answers to the lesson review questions in this chapter.
Objective 4.1
Thought experiment
1. You should always try to minimize the total number of images when requirements allow. Often, moving to a single image for client computers and a single image for servers is an optimal scenario for administrators. Based on the scenario of just having to deploy Windows 8.1, you should try to use a single install image. You can deploy the development tools after the install image.
2. You can use VHD-based install images for the developers. This would enable them to boot to multiple versions of Windows as part of their testing. A VHD-based install image enables simplified booting of different operating systems on the same hardware.
3. Thick images are definitely out because you wouldn’t want your development apps on all the client computers. If you just used a dedicated developer image, a thick image would be good, as long as you were okay with having multiple Windows 8.1 images for different situations. However, a hybrid image might be the best approach. The scenario didn’t call out any need to minimize the image size and didn’t mention any existing issues with the WAN or storage space. A hybrid image enables users to attain core functionality immediately following the image process. Office 2013 is often included in a hybrid image along with the core security software. A thin image would also meet the requirements, but users would have to wait longer to attain functionality after the deployment process completes.
Objective review
1. Correct answers: A and D
A. Correct: The users need basic operating system functionality only. A thin image will give them the functionality they need while minimizing the image file size.
B. Incorrect: A thick image will give users the basic operating system functionality they need, but the image size will not be minimized, which is a requirement.
C. Incorrect: A hybrid image will give users the basic operating system functionality they need, but the image size, although smaller than a thick image, will not be minimized.
D. Correct: A VHD-based thin image will meet the requirements of giving users basic operating system functionality and minimizing the image file size.
2. Correct answer: A
A. Correct: To deploy a default installation of Windows 8.1, you should use the install.wim file from the Windows 8.1 media as an install image.
B. Incorrect: The boot.wim file is a boot image and cannot be used to install Windows 8.1.
C. Incorrect: The install.wim file is an install image and cannot be used for booting.
D. Incorrect: The boot.wim file is a boot image and cannot be used to install Windows 8.1.
3. Correct answer: B
A. Incorrect: You need an install image for Windows 8.1 and an install image for Windows Server 2012 R2. Thus, you need a minimum of two images. You do not need to have more than one install image for Windows 8.1 for different models or drivers because you can handle those without requiring another image.
B. Correct: At least two images are required. Because the question calls for minimizing the total number of images, you should use two images. You need one image to install Windows 8.1 and another to install Windows Server 2012 R2.
C. Incorrect: Three images are more than you need. You need an install image for Windows 8.1 and an install image for Windows Server 2012 R2. Thus, you need a minimum of two images. You do not need to have more than one install image for Windows 8.1 for different models or drivers because you can handle those without requiring another image.
D. Incorrect: Four images are more than you need. You need an install image for Windows 8.1 and an install image for Windows Server 2012 R2. Thus, you need a minimum of two images. You do not need to have more than one install image for Windows 8.1 for different models or drivers because you can handle those without requiring another image.
4. Correct answers: B and C
A. Incorrect: If you are using a thick image, you don’t need to package the application after deployment. The question calls for minimizing license costs; using a thick image doesn’t meet that requirement.
B. Correct: A thin image meets the requirements as long as the application is packaged after deployment.
C. Correct: A hybrid image meets the requirements as long as the application is packaged after deployment. You should add the common applications the entire company uses to the hybrid image and package the other applications for deployment outside of the image.
D. Incorrect: A thick image goes against the requirement to minimize license costs. A filter won’t help in this situation.
5. Correct answers: A, B, C, and D
A. Correct: To perform a capture or an installation, you need a boot image.
B. Correct: To meet the requirement of using the reference computer’s operating system, you need a capture image so that you can capture the reference computer and use it as an install image.
C. Correct: The kiosk computers can’t boot to PXE, so you need a discover image to deploy install images to them.
D. Correct: You need an install image to deploy Windows. The requirements call for a Windows Server 2012 R2 deployment and a Windows 8.1 deployment to kiosk computers.
Objective 4.2
Thought experiment
1. You should use Configuration Manager because it will meet the requirement to automate as many of the tasks as possible. By using the Build And Capture A Reference Operating System Image template, you can automate the deployment of the reference computer and the capture in a single task sequence.
2. From WindowsPE, you can press Shift+F10 to open a command prompt. From there, you will have access to several troubleshooting tools, including tools such as DiskPart.
3. When you boot to PXE, you see all the boot images available to you on the server. This includes standard boot images and capture images. The only way to differentiate between boot images and capture images is by the name that you give each image when you create it. It is important to give your images descriptive names to ensure that you are using the appropriate image type and image in a given situation.
Objective review
1. Correct answer: B
A. Incorrect: The default user profile remains after Sysprep.
B. Correct: Sysprep removes the computer’s security identifier (SID).
C. Incorrect: User applications remain after Sysprep.
D. Incorrect: Application metadata remain after Sysprep.
2. Correct answer: C
A. Incorrect: A boot image is not used for installing an operating system, so Office 2013, if it will be put into an image, should go in an install image.
B. Incorrect: The task sequence requires an application, not a package.
C. Correct: The task sequence enables you to add any preconfigured application as part of your build.
D. Incorrect: A Windows Sideloading key is not used for adding applications to an automated build. It is used for sideloading apps.
3. Correct answers: A and C
A. Correct: To deploy an operating system in Configuration Manager, you need a boot image (to boot from) and an install image.
B. Incorrect: A capture image is used for capturing an image, not for deploying an image.
C. Correct: To deploy an operating system in Configuration Manager, you need a boot image (to boot from) and an install image.
D. Incorrect: A capture image is used for capturing an image, not for deploying an image.
4. Correct answer: C
A. Incorrect: Windows XP did not include the bundled system preparation files.
B. Incorrect: Windows Server 2003 did not include the bundled system preparation files.
C. Correct: Windows Vista is the first operating system to have the bundled system preparation files.
D. Incorrect: Although Windows 7 bundled system preparation files, it wasn’t the first Windows operating system to do so. That was Vista.
5. Correct answer: A
A. Correct: You must use a network path for the captured image.
B. Incorrect: A local path isn’t valid for storing a captured image.
C. Incorrect: A ConfigMgr repository isn’t valid for storing a captured image.
D. Incorrect: A WDS repository isn’t valid for storing a captured image from ConfigMgr.
Objective 4.3
Thought experiment
1. You should retrieve a list of the currently applied drivers by using the DISM /Get-Drivers command. Identify the outdated drivers and then use the DISM /Remove-Drivers command to uninstall them. Then, add new drivers by using the DISM /Add-Driver command.
2. Because the image has very little customization, you could use the updated installation media to create a new image. Alternatively, you could deploy the image to a reference computer, install Service Pack 1, and then capture the reference computer to update the image.
3. To avoid updating the image regularly, you can create an answer file and add it to the image. By assigning a distribution share and driver share and using the offline servicing pass, you can update drivers and packages without updating the image.
Objective review
1. Correct answers: A, B, C, and D
A. Correct: DISM supports .wim files.
B. Correct: DISM supports .vhd files.
C. Correct: DISM supports .vhdx files.
D. Correct: DISM supports .iso files.
2. Correct answer: B
A. Incorrect: You have to commit the changes to the image before you unmount it; otherwise, your changes will be lost.
B. Correct: This is the correct order: mount, apply, commit, and then unmount. If you don’t follow the correct order, your changes will be lost.
C. Incorrect: You can’t apply updates if the image isn’t mounted. You must mount the image before applying the updates.
D. Incorrect: You can’t apply updates if the image isn’t mounted. You must mount the image before applying the updates. In addition, you have to commit the changes before you unmount the image.
3. Correct answer: B
A. Incorrect: The specialize pass is when machine-specific information is added to an image, but it isn’t used for installing device drivers.
B. Correct: The offlineServicing pass is used for offline servicing of an image, including the installation of drivers.
C. Incorrect: The windowsPE pass is used to configure Windows PE settings and isn’t part of installing device drivers into the image.
D. Incorrect: The generalize pass is used to remove machine-specific information from a reference computer before capturing it for use as an install image.