Automating Windows 7 Installation for Desktop and VDI Environments

Automating Windows 7 Installation for Desktop and VDI Environments

Greg Shields

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Introduction to Realtime Publishers  by Don Jones, Series Editor

For several years now, Realtime has produced dozens and dozens of high‐quality books  that just happen to be delivered in electronic format—at no cost to you, the reader. We’ve  made this unique publishing model work through the generous support and cooperation of  our sponsors, who agree to bear each book’s production expenses for the benefit of our  readers.  Although we’ve always offered our publications to you for free, don’t think for a moment  that quality is anything less than our top priority. My job is to make sure that our books are  as good as—and in most cases better than—any printed book that would cost you $40 or  more. Our electronic publishing model offers several advantages over printed books: You  receive chapters literally as fast as our authors produce them (hence the “realtime” aspect  of our model), and we can update chapters to reflect the latest changes in technology.  I want to point out that our books are by no means paid advertisements or white papers.  We’re an independent publishing company, and an important aspect of my job is to make  sure that our authors are free to voice their expertise and opinions without reservation or  restriction. We maintain complete editorial control of our publications, and I’m proud that  we’ve produced so many quality books over the past years.  I want to extend an invitation to visit us at http://nexus.realtimepublishers.com, especially  if you’ve received this publication from a friend or colleague. We have a wide variety of  additional books on a range of topics, and you’re sure to find something that’s of interest to  you—and it won’t cost you a thing. We hope you’ll continue to come to Realtime for your  educational needs far into the future.  Until then, enjoy.  Don Jones 

 

i

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Introduction to Realtime Publishers ................................................................................................................. i  Chapter 1: Installation Fundamentals: Automatically Deploying Windows 7 with Windows  Deployment Services .............................................................................................................................................. 1  Step One: Installing and Configuring Windows Deployment Server ............................................ 2  Stepping Back: What Can You Now Do? .................................................................................................... 3  Step Two: Configuring WDS for Over‐The‐Network Image Deployment .................................... 5  PXE Response Tab .......................................................................................................................................... 6  Boot Tab .............................................................................................................................................................. 7  DHCP Tab ........................................................................................................................................................... 9  Multicast Tab ................................................................................................................................................. 10  Advanced Tab ................................................................................................................................................ 11  Step Three: Deploying Your First Windows 7 Image ........................................................................ 12  Just a Few Steps to Basic Automation ...................................................................................................... 17  Chapter 2: Creating a Universal Image that Installs Everywhere .................................................... 18  Step Four: Dealing with Drivers ................................................................................................................. 19  Unpacking Drivers ....................................................................................................................................... 19  Adding Drivers to Boot Images .............................................................................................................. 23  Step Five: Automating the WinPE Boot Image ..................................................................................... 24  Preparing WSIM ........................................................................................................................................... 25  Locating the Right Questions and Inserting Answers .................................................................. 27  The Remaining Questions and Answers ............................................................................................ 29  Validating, Saving, and Adding the Answer File to WDS ............................................................ 30  Step Six: Automating the Set Up Windows Phase ............................................................................... 31  Time for Applications ..................................................................................................................................... 34  Chapter 3: Techniques in Installing Applications During Windows Deployment ..................... 35  Step Seven: Creating a Master Image with Applications ................................................................. 35 

 

ii

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Invoking Sysprep ......................................................................................................................................... 36  Creating a Capture Image ......................................................................................................................... 37  Capturing the Master Image .................................................................................................................... 39  Stepping Back: Application Delivery Mechanisms ............................................................................. 43  From Thick to Thin ..................................................................................................................................... 45  Thick to Thin: What Do You Need? ...................................................................................................... 45  The Microsoft Deployment Toolkit ...................................................................................................... 46  Coming Up: Folding Your Deployment Infrastructure into the MDT ......................................... 47  Chapter 4: Layering Applications on Top of Deployed Windows Images ..................................... 48  Step Eight: Installing and Preparing the MDT ...................................................................................... 48  Importing an MDT Image ......................................................................................................................... 50  Importing Drivers ........................................................................................................................................ 52  Creating a Task Sequence......................................................................................................................... 53  Updating the Deployment Share ........................................................................................................... 54  Deploying a Basic Desktop with MDT ................................................................................................. 55  Step Nine: Learning Silent Installations and Repackaging ............................................................. 56  Three Ways to Silence Applications .................................................................................................... 58  MSI‐Based Installations ............................................................................................................................ 58  EXE‐Based Installations ............................................................................................................................ 59  Differential‐Based Installations ............................................................................................................. 60  Step Ten: Laying Applications Atop a Windows Image ................................................................... 61  Adding the Application to the MDT ..................................................................................................... 62  Configuring the Application for Deployment .................................................................................. 63  Thin Is Most Definitely In! ............................................................................................................................ 65  Chapter 5: User Virtualization: Tools and Techniques in Preserving User Data ....................... 66  Step Eleven: Preserving User Data ............................................................................................................ 68  Requirement One: Upgrading Windows XP to Windows 7 ....................................................... 69 

 

iii

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Requirement Two: Refreshing a Windows 7 Instance ................................................................ 74  Requirement Three: Moving a User to New Computer Hardware ......................................... 74  Stepping Back: Real User Virtualization ................................................................................................. 77  Encapsulation and Decoupling .............................................................................................................. 78  The Benefits of Decoupling ...................................................................................................................... 78  User Virtualization Goes Beyond OS Deployment .............................................................................. 79  Chapter 6: Automating Application Inventory and Overcoming Incompatibility ..................... 81  Step Twelve: Inventorying Applications and Drivers on the Network ..................................... 82  Installing the MAP and Collecting Inventory ................................................................................... 82  Creating and Using MAP Reports .......................................................................................................... 87  Step Thirteen: Resolving Application Incompatibilities .................................................................. 89  Installing the ACT ........................................................................................................................................ 89  Creating a Data Collection Package ...................................................................................................... 91  Analyzing and Keeping Track of Results ........................................................................................... 93  Fixing Incompatible Applications ......................................................................................................... 94  Solving Incompatibility: Not Hard but Time‐Consuming ................................................................ 98  Chapter 7: Creating a Complete Solution for Automating Windows 7 Installation .................. 99  Stepping Back: Understanding LTI, ZTI, and UDI ............................................................................. 100  Step Fourteen: ZTI with ConfigMgr ........................................................................................................ 101  Integrating ConfigMgr with MDT ........................................................................................................ 101  Adding the State Migration Point ....................................................................................................... 102  Creating an OS Deployment Share ..................................................................................................... 103  Creating a Deployment Task Sequence in ConfigMgr ................................................................ 103  Importing Drivers ...................................................................................................................................... 111  Updating Distribution Points ................................................................................................................ 113  Viewing the Task Sequence and Creating the OS Deployment Advertisement .............. 115  Stepping Back: What Haven’t You Seen? What’s Left? .............................................................. 120 

 

iv

 

Automating Windows 7 Installation for Desktop and VDI Environments 

The Automations Virtually Never Stop ................................................................................................. 121  Chapter 8: Integrating Automated Windows 7 Installation into VDI Environments ............. 122  Step Fifteen: Integrating MDT into VDI Deployment ...................................................................... 123  Creating a Virtual Machine and Deploying an OS ........................................................................ 123  Injecting Drivers and Virtual Tools .................................................................................................... 127  Tuning the Virtual Machine ................................................................................................................... 128  Guidance for Services .......................................................................................................................... 128  Guidance for Additional Configurations and Scripting ......................................................... 131  Tuning Personal Desktops vs. Pooled Desktops ........................................................................... 133  Preparing and Templatizing the Deployed Virtual Machine .................................................. 134  Automating Windows 7 Installation: Start to Finish ....................................................................... 135  Download Additional eBooks from Realtime Nexus! ...................................................................... 135   

 

v

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Copyright Statement © 2011 Realtime Publishers. All rights reserved. This site contains materials that have been created, developed, or commissioned by, and published with the permission of, Realtime Publishers (the “Materials”) and this site and any such Materials are protected by international copyright and trademark laws. THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice and do not represent a commitment on the part of Realtime Publishers or its web site sponsors. In no event shall Realtime Publishers or its web site sponsors be held liable for technical or editorial errors or omissions contained in the Materials, including without limitation, for any direct, indirect, incidental, special, exemplary or consequential damages whatsoever resulting from the use of any information contained in the Materials. The Materials (including but not limited to the text, images, audio, and/or video) may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in whole or in part, except that one copy may be downloaded for your personal, noncommercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice. The Materials may contain trademarks, services marks and logos that are the property of third parties. You are not permitted to use these trademarks, services marks or logos without prior written consent of such third parties. Realtime Publishers and the Realtime Publishers logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners. If you have any questions about these terms, or if you would like information about licensing materials from Realtime Publishers, please contact us via e-mail at [email protected].

 

vi

 

Automating Windows 7 Installation for Desktop and VDI Environments 

[Editor's Note: This eBook was downloaded from Realtime Nexus—The Digital Library for IT  Professionals. All leading technology eBooks and guides from Realtime Publishers can be found at  http://nexus.realtimepublishers.com.]   

Chapter 1: Installation Fundamentals:  Automatically Deploying Windows 7 with  Windows Deployment Services  You’ve just been handed a new project to migrate your desktops to Windows 7.  Congratulations! That’s a big job; one that’s sure to make you look good to your peers and  your bosses—if you get it right.  Among IT projects, none so dramatically impacts users than a desktop operating system  (OS) upgrade. With it, users get new icons and a new desktop look and feel, not to mention  a few new ways of accomplishing their daily tasks. That’s something they can see, feel, and  touch. Completing an upgrade project successfully means doing so without a major  interruption to the flow of your users’ workday.  In contrast, doing a poor job means leaving a bad taste in the mouth of your business. That  bad taste makes down‐the‐road upgrades that much more difficult to get approved. If your  company can’t see value in an OS upgrade—or if they see more pain than value—you’ll  surely be stuck at this OS version for far longer than you want. And businesses have long,  long memories.  That’s why this book exists. Although installing Windows the manual way requires as few  as seven clicks and a bit of time, that manual method is rife with pain and trouble. Fully  automating the installation of Windows 7 requires a bit more up‐front effort, but the result  is a more seamless process—that just works. Better yet, that same process will continue to  benefit you for years to come, creating a platform for quickly refreshing computers  whenever necessary. All you need is a project plan to get you started and a cookbook of  step‐by‐step solutions to finish the job. You’ll get exactly that in these pages.  In the next few chapters, I’ll show you the steps required to automate Windows 7  installation, click‐by‐click. But we won’t stop there. I’ll dig deep into the ways in which that  automated installation will fundamentally change how you do IT. You’ll learn exactly how  to automate Windows for an OS migration project, whether from Windows XP or Windows  Vista. You’ll even discover the steps to wrap your automated installation into a VDI  infrastructure, enabling hosted virtual desktops to be provisioned automatically and on‐ demand. More importantly, you’ll learn tips and tricks for layering the Windows OS,  enabling you to fix common IT problems by simply rebuilding the user’s computer—all the  while maintaining their applications and user profile information. 

 

1

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Best, you’ll learn how to do all of this using Microsoft’s no‐cost deployment solutions.  Admittedly, these solutions might not be the slickest ones around, but they’re free. In  addition, they are overloaded with an alphabet soup of three‐ and four‐character acronyms  whose complexity makes them a “why bother” for many IT pros. But wade through the silly  acronyms and the overly‐complicated Microsoft documentation, and underneath it all is a  powerful automated deployment solution. I’ll help you navigate, showing you which  features to use and which to avoid.  Keep this guide handy. In it are the step‐by‐step instructions you’ll find yourself turning  back to again and again as you fully automate one of the most time‐consuming parts of your  job: Windows 7 installation. 

Step One: Installing and Configuring Windows Deployment Server  Many authors might begin this discussion by explaining the complex file format Microsoft  uses for Windows deployment. That format is called Windows Imaging (WIM) format. Like  the GHO files from Symantec Ghost’s days of yore, WIM files are those that contain your  Windows 7 images.  That’s really about all you need to know right now. I could spend pages talking about the  intricacies of how it works (and actually will a bit later). But it’s my belief that  understanding WIM’s format is less important at first than knowing what to do with it.  Thus, Step One in your exploration of automatically deploying Windows 7 starts by  installing Microsoft’s solution for actually deploying Windows 7. That solution is called  Windows Deployment Services. Commonly shortened to just WDS, it is available as an  installable role inside Windows Server 2008 R2.  Note  WDS is also available in Windows Server 2003 and Windows Server 2008,  but those versions don’t include the capabilities you’ll really want. Thus, this  book’s server side will focus exclusively on Windows Server 2008 R2.  Installing the WDS role is a very simple process that you complete in Server Manager. Start  by right‐clicking Roles to add the Windows Deployment Services role. Installing this role  also installs two role services: Deployment Server and Transport Server. Both of these role  services are required for WDS to function. 

 

2

Automating Windows 7 Installation for Desktop and VDI Environments 

 

Once the WDS role is installed, you will complete an initial configuration to get started. Do  so by right‐clicking the server in the WDS console, and selecting Configure Server. The  Configure Server wizard will query you for information in three areas:  •

Remote installation folder location. Your image files obviously need a storage  location. These files will be large, measuring in the tens of gigabytes, and you’ll  eventually have more than one of them. For this first area, provide a path to a  sufficiently‐large local folder where you will be storing your image files. This path  should not be the system partition. 

•

PXE server initial settings. Although it is possible to start a Windows 7 image  deployment by booting the computer from a DVD or USB drive, you get the best  automation by booting computers via the Preboot eXecution Environment (PXE).  This “pixie booting” enables computers to automatically download an image from  the network as they boot. Transferring Windows 7 images over the network can  have a big impact on network performance (a topic I’ll discuss in a minute), so for  now, select the Do not respond to any client computers option. Don’t worry, we’ll be  changing this option shortly. 

•

Add Image Wizard. The third query asks whether you want to add images to this  server now. In this first chapter, I’ll be showing you how to deploy default images  that are right off the Windows media. Automating the customization of these images  won’t happen just yet. That comes later. For this first example, you’ll install only the  default configuration of Windows 7—just like what you get after a manual install  from the DVD. 

To get started, select the Add images to the server now check box, and click Finish. You’ll be  prompted for a file path. Insert your copy of the Windows 7 DVD into the drive, and supply  the right path. The Add Image Wizard will ask you to create an image group. Do so, giving  that group a friendly name. One or more images will be added to your server, depending on  which version of the Windows 7 media you have. This process can take a few minutes, so  grab a cup of coffee and meet me back here in 10. 

Stepping Back: What Can You Now Do?  So what can you do now? Right now, not much. What you’ve achieved at this point is the  very beginning of your image deployment system. Remember your Ghost Server? On that  server, you would create multicasting sessions to deploy images you specified to clients  you connect. You’re doing much the same here, except Microsoft’s “Ghost Server” is  accessed through the WDS console in Administrative Tools.  Figure 1.1 shows an example of what you might be seeing at this point. There, five install  images have been uploaded to the server from the Windows 7 DVD media. Each image  corresponds to one of the editions of Windows 7. The steps up to this point have uploaded  another image as well. This image is called a boot image, and it is found in Figure 1.1’s Boot  Images folder. 

 

3

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 1.1: The WDS console.  WDS uses two types of images to install Windows. The boot image has nothing to do with  the OS you’ll eventually install onto that computer. Rather, it is a miniature version of  Windows called the Windows Preinstallation Environment (WinPE). You need WinPE just  to boot the computer to which you’ll eventually deploy an image. As it boots the computer,  WinPE also loads other niceties, such as a lightweight Windows GUI for interacting with  that computer. A network stack is also loaded, so you can conveniently transfer images  over your LAN. WinPE is actually a tiny version of Windows, so some (though far from all)  of your usual Windows commands will work with it. I’ll talk more about WinPE later, but  for now, be aware that the boot image is what starts this ball rolling.  The real juice with WDS comes in its install images, found in the Install Images folder in the  console. You’ve just uploaded a set of install images right off the Windows 7 media. Yours  might have a few less or more than mine, depending on where you got your media. One of  these install images and a boot image is all you need to start automatically deploying  Windows. Really.  Note  It’s at this point where I should highlight how Microsoft’s overly‐complicated  documentation can really confuse people. Reading it, you might discover that  Microsoft wants you to PXE your machine to WDS using an Unattend.XML file  built from WSIM in the WAIK after pre‐staging your GUID inside the ADUC.  Oh, and don’t forget MDT (formerly BDD!), who’s Deployment Workbench  wraps around all this ridiculousness.  My response: Hooey. In attempting to define everything, Microsoft has  inadvertently confused everything. Bear with me in this book because I  intend to bootstrap you through those same services but without all the  confusing alphabet soup. 

 

4

 

Automating Windows 7 Installation for Desktop and VDI Environments 

So obviously that right‐off‐the‐DVD image isn’t terribly customized for your environment.  All by itself, your computer won’t have Office installed. It won’t have any special drive  partitioning. Any customizations you normally add to your “golden image” won’t be on it.  All those things are the topic in Chapter 2.  Before you start customizing your image, you need to know how to actually deploy an  image. That’s what we’re about to do in step two. 

Step Two: Configuring WDS for Over‐The‐Network Image Deployment  I mentioned before that one mechanism to boot a computer is by using a DVD or USB hard  drive. You can start that process by right‐clicking a boot image, and selecting Create  Discover Image (and then perform another dance of multiple steps I won’t get into). The  problem is that the manual method of booting computers is a process you don’t want to do.  It’s not terribly automatic. So the much more exciting solution is to use PXE and your  network. Before you start, however, check out this sidebar for an important warning about  WDS and network bandwidth consumption.  A Warning about Over­the­Network Image Deployment  Kicking off an over‐the‐network image deployment is a lot like turning on a  fire hose of data through your network. Not properly segregated, that data  hose can severely bog down entire sections of your LAN. For example,  turning it on in a non‐segregated network of a dozen computers can  essentially shut down the network for everyone else until the installation is  complete. Multicast domains can protect you from this situation, but they’ll  need to be specifically configured on your networking equipment.  If you intend to use over‐the‐network image deployment, you might start by  splitting off a little network subnet just for use in deploying computers. That  subnet might include your WDS server and a few network connections for  computers who need imaging. That way, you can learn about WDS’ traffic and  effects on your network equipment before you stage it throughout the rest of  your network.  Let’s get your WDS server ready for deploying default images across the network. Doing so  requires two network services: PXE, which we’ve already discussed, and DHCP. PXE  handles the very first bootstrapping step for the computer, directing it to the WDS server  where it can find its boot image. DHCP is used to give those PXE clients an address and  route them to the WDS server.  I’ll show you a fairly open example of how to configure the two, and let you lock it down  later as you see fit. Start this process by right‐clicking your server name in the WDS  console, and selecting Properties. If you’ve done everything correctly, you should see nine  tabs in the resulting properties screen. You’ll need to make changes in five of the tabs to get  started. 

 

5

 

Automating Windows 7 Installation for Desktop and VDI Environments 

PXE Response Tab  The first tab where configuration is required is PXE Response, seen here in Figure 1.2. Any  computer whose boot order has been configured to boot first from a network card will  attempt to find a PXE server every time it boots. Obviously, this means that every time that  computer starts, it will essentially be looking for a new OS vis‐à‐vis WDS. This is an OK  thing, based on some other configurations you’ll make shortly. But, as you can imagine, the  default setting is for WDS to not respond to client computers. 

  Figure 1.2: The PXE Response tab.  To begin listening for PXE clients, change this setting to Respond to all client computers  (known and unknown). By setting the configuration in this way, any PXE client that  attempts to connect to WDS will be heard and receive a response. 

 

6

Automating Windows 7 Installation for Desktop and VDI Environments 

 

Notice also that Require administrator approval for unknown computers has been selected.  Using WDS alone, administrator approval is a necessary evil because this action provides  the mechanism to name new computers as their OS is installed. If you don’t select this  check box, computers will be given a default name that is based on the username of the  individual who hits F12 and starts the installation. Virtually all of us use a special naming  convention for our computers. So naming all your computers after yourself isn’t a great  solution.  Note  Be aware that there’s a missing piece in WDS’ installation that causes this  naming process to fail unless you make a small change to your Active  Directory (AD) permissions. The problem exists because the process to name  that computer and add its account token into AD happens using the server’s  AD authentication token and not your user token. You’ll need to make this  small change to enable the correct permissions: In Active Directory Users  and Computers, right‐click the domain, and then select Delegate Control.  Change the object type to include computers, and add the computer object of  the WDS server into the dialog box. Click Next. When prompted, select Create  a custom task to delegate. Select Only the following objects in the folder. Next,  select the Computer Objects check box, then Create selected objects in this  folder. Click Next. In the Permissions box, select Write all Properties, and  click Finish. 

Boot Tab  As you can imagine, setting the previous tab to listen for every PXE boot could be a bad  thing. “Connect every computer to WDS as it boots? Greg, are you nuts?”  Quite the opposite, my friends. You can still listen for every client but allow most of them to  continue on through the regular boot process by forcing the user to hit the F12 key when  the user is ready for an OS installation. You can setup this configuration on the Boot tab  (see Figure 1.3). Notice that known and unknown clients are separated out, with each class  of client being given one of three different options. 

 

7

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 1.3: The Boot tab.  Hitting F12 presents a great way to automate. Think of how this might work: You recognize  that a computer needs rebuilding. That computer’s BIOS is already configured to boot first  from its network card. Assuming that a transmission is ready for approval, all you need to  do from the client is reboot and hit F12 to start the process. Every other computer passes  by this situation after a few seconds on their way to a standard boot.  You’ll also see in this figure that it is possible to specify a default boot image. This setting is  optional for now, as you should at this point only have a single boot image (for at least one  processor architecture) if not more. If you have more than one for each architecture,  consider selecting one as the default. 

 

8

Automating Windows 7 Installation for Desktop and VDI Environments 

 

DHCP Tab  On the third tab of interest, you begin the process of setting up DHCP services (see Figure  1.4). The verbiage on this tab is a bit confusing. Allow me to translate. There are in fact  three scenarios that can exist between WDS and DHCP:  •

WDS and DHCP are on the same subnet but on different servers. This setup is  the most‐likely case. It is also the easiest, as there is nothing additional that you  need to do. You can move to the next step. 

•

WDS and DHCP are on the same server. If your DHCP server is also your WDS  server, select both of the offered check boxes. Move on. 

•

WDS and DHCP are on different servers on different subnets. This setup  involves the most work. Select none of the check boxes. Then, in the DHCP console of  your DHCP server, view the properties of each relevant DHCP scope. There, select  the check boxes to enable scope options 66 and 67. You’ll need to enter the fully‐ qualified domain name of your WDS server in the String Value box for option 66.  Enter the name of your boot image into option 67. This name is typically boot.wim,  although you can double‐check the file name by viewing the properties of the boot  image on the General tab. 

  Figure 1.4: The DHCP tab.   

9

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Multicast Tab  The Multicast tab (see Figure 1.5) has two sections you’ll need to review. At the top, you  can set the network addresses you’ll use when multicasting. These addresses can either  source from a static range or be distributed through DHCP. Depending on how your  network is configured, these addresses may be different than the default settings. Consult  your network settings (or your network administrator!) for your specific addresses. 

  Figure 1.5: The Multicast tab.  The bottom section can be very important for speeding up the transmission of images to  multiple clients at once. You can obviously imagine that some Windows computers are  faster than others. Maybe they have faster processors or disks, or they’ve got a better  connection to the LAN. One historical limitation of multicast is that its transmissions are  always limited to the slowest member of the group.  That limitation hasn’t changed. But what has changed is the ability to break apart a  multicast transfer into multiple smaller transfers when slow machines cause slowdowns. In  the Transfer Settings box, you can separate those clients. More multicast transmissions  obviously means simultaneously duplicating that aforementioned fire hose of data. So be  careful before you make any changes because you can really turn on the faucet here. 

 

10

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Advanced Tab  Finally is the Advanced tab (see Figure 1.6). If you’re using a Microsoft DHCP server, you’ll  need to click the radio button to Authorize this Windows Deployment Services server in  DHCP. You can also specify a domain controller (as opposed to having WDS discover a local  one), although doing so isn’t common. 

  Figure 1.6: The Advanced tab. 

 

11

Automating Windows 7 Installation for Desktop and VDI Environments 

 

Step Three: Deploying Your First Windows 7 Image  You’re now ready to deploy your first Windows 7 image over the network. Start this  process by right‐clicking Multicast Transmissions in the WDS console, and selecting Create  Multicast Transmission. You’ll have three areas to address:  •

Transmission name. Each transmission requires its own name. Clients will use this  name to identify which transmission they want to follow. Give the transmission a  friendly name, and continue. 

•

Image selection. Your second selection will identify which image you want to  transfer. Each image group contains one or more images. Select the one you’re ready  to deploy. 

•

Multicast type. Creating a multicast transmission only prepares it for clients. Once  that transmission is prepared, it will sit in waiting for those clients based on the  behaviors you set. As Figure 1.7 shows, you’ve got options. You can instruct the  transmission to begin after a certain number of clients or amount of time passes. A  much more powerful alternative is to simply tell the transmission to begin when the  first client connects. Subsequent clients will join later, picking up the data at  whatever point it is at, and finishing up where necessary. I particularly like this  setting, as it gives me the most flexibility for starting transmissions and joining  clients a bit later. 

  Figure 1.7: Multicast Type.   

12

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Finishing the wizard sets the multicast transmission to a Waiting status until the Multicast  Type conditions are met. Now, ready a computer that needs an OS. Set its network boot  order in the BIOS to boot from its NIC first. Then boot it, and hit F12 when prompted. If  you’ve done everything correctly, the computer will boot and pause as it awaits approval  for its pending OS installation request. Figure 1.8 shows how the boot screen will appear as  the client waits. Note that this computer’s pending request ID is set to 1. 

  Figure 1.8: Awaiting administrator approval.  That same pending request ID number will be displayed in the WDS console under Pending  Devices (see Figure 1.9). To approve the request and name the computer, right‐click the  appropriate request ID and choose Name and Approve. Enter a name for the computer into  the resulting dialog box, and click OK. The installation will begin. 

  Figure 1.9: Pending Devices. 

 

13

 

Automating Windows 7 Installation for Desktop and VDI Environments 

The client will download its boot image from the WDS server and present you with a screen  that looks similar to Figure 1.10. As you can imagine, at this point you don’t have full  automation just yet. You’ll learn about those steps in future chapters. But what you do have  is a mini‐setup screen for Windows 7. Figure 1.10 shows that the mini‐setup screen needs a  Locale and Keyboard as well as credentials to connect to the WDS server (in my case,  wdsserver.company.pri). 

  Figure 1.10: The boot image’s setup screen.  Entering those credentials brings you to Figure 1.11, where your selection of OS edition can  be made. You should note an interesting behavior here. When you created the original  multicast transmission, you identified an edition for distribution, yet on this screen you’re  allowed to choose any edition in the image group. That edition selection will become  important down the road as you add automation pieces. 

 

14

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 1.11: Selecting an edition.  This wizard’s final screen (not shown here) provides a location to configure any disk  partitions that will be used by this computer. Moving on from this screen begins the  installation.  Monitoring the status of installations occurs back in the WDS console, where useful  instrumentation data is presented for each client: name, IP address, time connected, status  (as percent complete), and even CPU, memory, and network utilization statistics. I’ve  scrolled Figure 1.12 a bit to the left to show some of its more interesting columns. This date  is useful for identifying when one or more slow clients needs to be disconnected or  reverted to its own multicast transmission. You can do so by right‐clicking any running  transmission, and selecting Disconnect or Bypass multicast. 

 

15

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 1.12: Client instrumentation for an active multicast transmission.  Give your installation a few minutes to complete. As with a manual installation, the  installation process will reboot the computer a few times and offer a few pop‐up status  screens. Once the installation is again ready for user input, you’ll be presented with the  post‐installation configuration screen called Set Up Windows (see Figure 1.13). 

  Figure 1.13: The Set Up Windows screen.  You’ve seen the next set of screens before. They’re pretty much the same configuration  screens you see when you install Windows manually: setting a username and password,  accepting the license agreement, configuring Windows Update, and setting the time and  time zone.   

16

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Just a Few Steps to Basic Automation  You’ve complete the few steps required to achieve basic automation, and there are just a  few more to get you to even greater levels of automation. This first chapter has hopefully  demystified some of the steps required to start automating the installation of Windows 7  with Microsoft’s tools. If a default installation from the Windows 7 DVD media is all you’re  looking for, you can stop here and begin deploying clients.  But most of us would probably like just a few more of these processes taken off our plate.  We don’t want to deal with answering questions during WinPE’s initial boot. We probably  don’t want to answer questions at the post‐installation configuration screen either. If we  have drivers that aren’t part of the Windows DVD media, we want them added to our  installation. And, most importantly, we want our initial installation to start with a set of  applications like Microsoft Office and others.  All of these are valid requirements as well as completely feasible automations that you can  add with just a bit more work. And all of these are topics explored in Chapter 2. 

 

17

Automating Windows 7 Installation for Desktop and VDI Environments 

 

Chapter 2: Creating a Universal Image that  Installs Everywhere  As you complete the steps from the previous chapter, you’re absolutely ready to start  deploying Windows 7 images. They’re not terribly customized images yet, but they’ll work.  Once deployed to desktops, these images will look almost exactly like the generic Windows  7 installation you would install directly from the DVD media.  There’s nothing wrong with a generic image, especially considering that many of us have  used the walk‐around‐the‐office‐DVD‐in‐hand approach for years. But there’s also nothing  particularly automated about them. Worse yet, these images aren’t truly universal. If the  computers to which you’re targeting the images need a set of drivers that aren’t on the DVD  media, they might not work properly. Let’s think for a minute about what this solution  lacks:  •

Driver injection. Windows 7 comes with a massive stack of drivers right inside its  DVD media and through Windows Update. But computers today often need their  own custom drivers over and above the defaults. Our solution doesn’t yet have a  way to inject those custom drivers into our images. 

•

Automating the WinPE phase. Remember that deploying an image requires a boot  image as well as an install image. Currently, our boot image asks us a set of  questions we’d prefer not to answer, things like locale, keyboard, username and  password to deployment server, operating system (OS) to install, and disk  partitions. Real automation means answering these questions beforehand and  letting our solution do the work. 

•

Automating the set up Windows phase. Even after answering all of WinPE’s  questions, there’s still a full second set of questions required by the Windows  installation itself. The Set Up Windows wizard asks for a username and password,  accept the license agreement, configuration settings for Windows Update, identify  network settings, and set the time and time zone settings. We also want these  questions answered beforehand, so we can zip past this manual step. 

Thus, our solution is indeed still incomplete. It hasn’t evolved yet to using a universal  image, one that can install everywhere. Nor is it fully automated so that it takes care of the  heavy lifting on our behalf. 

 

18

 

Automating Windows 7 Installation for Desktop and VDI Environments 

There’s good news: It is possible with today’s Windows 7 deployment technologies to add  these three capabilities with not much extra effort. I’ll show you how to do just that in this  chapter. As with the previous chapter, I’ll be supplying you with a receipt to get started. I’ll  then point out a few places where you can explore on your own for even greater  automation. Let’s begin with the drivers. 

Step Four: Dealing with Drivers  Windows Deployment Server (WDS) got a very nice new feature in Windows Server 2008  R2. That new feature takes most of the pain out of automatically injecting drivers into a  deployment. Navigate over to the WDS console in Server Manager, and scroll down to its  Drivers node. Here you can add sets of drivers, called Driver Packages, to your WDS server.  Those Driver Packages contain the drivers that a computer might want. Remember Plug  and Play? Windows’ Plug and Play supplies the automation framework for installing these  drivers inside a Windows deployment.  Plug and Play: Awesome for Windows Installations  During Windows installation, the real power of Microsoft’s Plug and Play  shines. You already know that Plug and Play is the service that watches for  new hardware to be connected. When it detects new hardware, it matches  the hardware component’s characteristics to the drivers available. When it  finds a match, the correct driver is automatically installed, making the  hardware ready for use.  Although you’re used to seeing its actions when you plug in a new device,  Plug and Play is also in action during the install process. During install,  Windows invokes Plug and Play to detect the installation hardware. The  correct drivers are then installed if they’re available. If they’re not, Windows  uses a generic driver when one is available.  In the end, what you need is a mechanism to make custom drivers available  during the install. If they’re available, Windows will take care of the rest.  Drive Packages enable you to make custom drivers available during install. Once created  and added to WDS, Plug and Play will find and install the custom drivers as the OS  deployment begins. 

Unpacking Drivers  The hard part here is getting drivers into a format that WDS can use. WDS cannot work  with drivers that are packaged into .EXE or .MSI files. Drivers need to be extracted from  their .EXE or .MSI file so that WDS can find each driver’s .INF file. 

 

19

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Remember how most drivers, when they’re fully unpacked, arrive with some combination  of .SYS, .CAT and .INF files? You can consider the .INF file to be a kind of instruction manual  for installing the driver. It is the .INF file, usually one for each driver, that WDS needs to  find. It needs the other files as well, but consider the .INF as your starting place. Everything  else WDS needs is usually found in the same location.  As you can imagine, locating the .INF can be difficult. Finding it is sometimes a game of  educated guessing. Sometimes drivers arrive with their .INF files already extracted. Other  times, they are packaged into a .CAB or .ZIP file. Your mileage will vary, with each driver  being a little different.  Unpacking the VMware Tools’ Drivers  Don’t worry if this unpacking process is a bit confusing the first time around.  Most of us are used to using install files to automate everything after we  double‐click. Unfortunately, that double‐click doesn’t work for this specific  need. Let me step you through a quick example that can illustrate one  mechanism to locate the files you need.  If you’re following along using VMware Workstation as your lab  environment, you know that VMware’s custom drivers are found in the  VMware Tools. Every OS that runs inside VMware Workstation needs its  VMware Tools installed if it’s to work properly. For Windows, those tools are  found in the file C:\Program Files (x86)\VMware\VMware  Workstation\windows.iso.  Mount that ISO using a tool such as Virtual Clone Drive, and take a look at its  contents. Inside are two .MSI files that contain the VMware Tools’ drivers:  VMware Tools.msi and VMware Tools64.msi. You want the contents of these  files. You can extract them to a folder by running an administrative install  using the command:  msiexec /a VMware Tools64.msi 

Doing so will launch a mini‐setup that asks for a location to store the  unpacked drivers. Store them somewhere they can be later accessed by WDS.  You’ll use these drivers in the next step.  Caution: Although this process makes for a great example, don’t use this  process to install the VMware Tools on production computers. VMware  strongly recommends installing the tools through their usual mechanisms  inside VMware Workstation.  Once you’ve unpacked drivers, you can add the entire folder’s worth of them in one fell  swoop by right‐clicking Drivers in the WDS console, and choosing Add Driver Package.  Figure 2.1 shows the screen that appears. You can select either a single .INF file or tell WDS  to search a folder for every driver package it finds. I’ve chosen the second option because  it’s easier and adds everything at once. 

 

20

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 2.1: Driver package location.  The wizard’s second page provides a place to select the drivers to add from the set WDS  has found (see Figure 2.2). Some of these you won’t want. For those, you have two options:  clear the check box to prevent a driver’s package from being loaded to WDS, or double‐click  the driver and change its status to Disabled if you want it loaded but not enabled for  deployment. Double‐clicking individual drivers also gives you more details about that  driver, its files, and other characteristics. 

 

21

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 2.2: Available driver packages.  Click through the remaining wizard pages and add the drivers to the default DriverGroup1  to complete the wizard. DriverGroup1 is the default group that can be used by all  computers as an installation is deployed. Thus, right out of the box any driver that is  contained in DriverGroup1 will automatically be available for any deployment to any  computer.  You might at this point want to add to DriverGroup1 the set of drivers you know your  desktops will need. Once added, try a test installation to see whether those drivers are  successfully installed during a deployment. You’ll be able to tell by logging into a desktop as  Administrator after deploying an OS. Once there, check the list of drivers in Device  Manager. You’ve done everything correctly if the right drivers appear. 

 

22

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Note  Although this tool is great when drivers are perfectly matched to computers,  you might experience the situation where drivers conflict with each other.  For example, drivers from one hardware type might be very close to those of  another. As a result, the wrong set of drivers can be installed by WDS.  In this case, you’ll need to configure WDS driver groups in combination with  filters. WDS’ filters restrict driver installations to certain hardware  characteristics such as manufacturer, BIOS vendor, UUIS, OS version, and so  on. They provide a way to target specific sets of drivers to specific sets of  hardware.  Configuring these filters is out of scope for this book; you can get more  information about them at http://technet.microsoft.com/en‐ us/library/dd348456(WS.10).aspx. 

Adding Drivers to Boot Images  Up to now, I’ve showed you only the steps to add drivers to install images. If your hardware  will not function with the generic drivers included in WinPE, you’ll need to add custom  drivers to your boot image as well. This process is slightly different than with install  images. The boot image process requires specifically adding drivers into the boot image  rather than just making them available.  Before you start, driver packages for boot images must first be added into the Drivers node  using the method I’ve already explained. Once added, inject them into a boot image by  right‐clicking the boot image, and choosing Add Driver Packages to Image. This selection  brings up a multi‐screen wizard for selecting the appropriate driver packages. Figure 2.3  shows the most important page in that wizard.  This page locates driver packages based on the search terms you set in the Search box. The  settings in Figure 2.3 are the defaults for my standard x64 boot image. Adjust your search  terms, then click Search for Packages to reveal the results at the bottom. Select the check  boxes for the appropriate drivers, and complete the wizard to add them to the boot image. 

 

23

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 2.3: Add Driver Packages to Boot Image Wizard.  Note  Although adding driver packages to boot images is easy, removing them is  less so. Thus, it is recommended that you make a backup copy of the image  before making any changes. Otherwise, a wrongly‐placed driver can corrupt  the boot image. 

Step Five: Automating the WinPE Boot Image  With the right set of custom drivers, your images can now be made universal. That makes  you ready for the next step in constructing your deployment solution: automating  responses to the set of questions asked by WinPE prior to starting an OS deployment.  These questions relate to locale, keyboard, the username and password WinPE needs to  download an install image, OS and edition, and disk partitions. 

 

24

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Things get a little more challenging in this step. First, you’ll need to learn two more of the  acronyms in the Microsoft deployment alphabet soup: WAIK and WSIM. The WAIK is the  Windows Automated Installation toolKit. Among many other deployment‐related tools, the  WAIK is the home of the Windows System Image Manager (WSIM). Your first job is to locate  the Windows 7 version of the WAIK (they are versioned by OS). For this book, download  and install the WAIK to your WDS server.  Once installed, launch WSIM. WSIM provides a workbench for creating unattended  installation files. Figure 2.4 shows what WSIM looks like after completing some of the  preparations I’ll explain next. As you’ll immediately note, it’s a pretty busy interface. I’ll  walk through each of its panes in the next section. 

  Figure 2.4: An example WSIM interface.  First a little background on what you’re about to create. The files WSIM generates provide  the “answers” to the “questions” you’ll want to eliminate from your automated installation.  You’ll in fact use WSIM twice to do this. For its first run‐through, you’ll be answering the  questions WinPE asks during its portion of the installation. For the second—which I’ll  explain in Step Six—you’ll follow up with an additional set of answers that will be used by  the Windows installation itself. 

Preparing WSIM  To get started with WSIM, create a Distribution Share. For our purposes, create a folder  called C:\DistroShare on your WDS server. Then, in WSIM, right‐click Select a Distribution  Share | Create Distribution Share. Navigate to C:\DistroShare, and click Open to set this as  your share. 

 

25

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Your next action will be to export an install image from WDS to the share. This image is  needed so that WSIM can analyze it to discover the questions that might need answering.  Right‐click an install image that you plan to eventually deploy (yes, that’s an install image  and not a boot image), and choose Export Image. This will be the image that you later plan  to deploy to your desktops. I’ll be choosing the Windows 7 ENTERPRISE edition image for  mine. Export that image to C:\DistroShare and give it a name. Then, back in WSIM, right‐ click Select a Windows image or catalog file | Select Windows Image, then choose the .WIM  image you just exported.  You’ll be immediately prompted with the error message you see in Figure 2.5. This is OK  because you haven’t yet created a catalog file that is associated with this image. Create that  catalog by clicking Yes. This catalog file takes a few minutes to generate as WSIM analyzes  the image for all the possible questions that could be asked. Once it is complete, you’ll be  able to pick and choose from the questions it discovers and answer those of interest. 

  Figure 2.5: Cannot find a valid catalog file.  Figure 2.6 shows what the Windows Image pane will resemble once this process has  completed. You’ll see that a very large number of questions are available to be answered,  many of which are difficult to understand and all of which have cryptic names. Many  questions have sub‐categories of further questions. 

  Figure 2.6: WSIM’s Windows Image pane.   

26

 

Automating Windows 7 Installation for Desktop and VDI Environments 

You might spend quite a bit of time here simply finding the questions of interest. Many of  these are intended only for the activities in Step Six. Others are intended for what we’re  doing here with WinPE in Step Five. To be honest, this process is mostly a guess‐and‐test  activity. I’ll help get you started with the minimum you’ll need to fully automate this step.  Later, you can add more answers as you see fit and desire more customization.  Before you can begin working with questions, you’ll need to create an answer file. You’ll  eventually add this .XML file into WDS. Create it by right‐clicking Create or open an answer  file | New Answer File in the Answer File pane (see Figure 2.7). 

  Figure 2.7: An answer file.  Note  Every answer file has seven numbered sections. These seven sections  correspond to the seven “passes” of the Windows installation, starting with  windowsPE and finishing with oobeSystem (OOBE stands for Out‐Of‐Box  Experience). For Step Five in our process, we’ll be working only with  questions that relate to Pass 1. 

Locating the Right Questions and Inserting Answers  At this point, you’ll need to locate the questions you want and insert whatever answers  make sense for your Windows 7 deployment. I’ll kick off this process by explaining how to  answer one question in detail. Then, in the next section I’ll follow up with a table of the  remaining questions and their answers. Remember that I am using the x64 installation of  Windows 7. Questions for x64 installations begin in WSIM with amd64. If you will be  installing the x86 version, look for those that start with x86.  The first question you want to answer relates to the regional language to be used by the  installation. In the Windows Image pane, navigate to amd64_Microsoft­Windows­ International­Core­WinPE_{version}_neutral where {version} is whatever version number  you see. Right‐click this element, and select Add Setting to Pass 1 windowsPE (see Figure  2.8). 

 

27

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 2.8: Adding a setting to Pass 1 windowsPE.  Doing so adds the question to your answer file. Once added, you’ll then answer it in WSIM’s  upper‐right pane. That pane’s title will always be the name of the question you’ve currently  selected in the Answer File pane. Figure 2.9 shows both panes with the question  highlighted that I’ve just selected. 

  Figure 2.9: Answering a question.  If your language choice is United States English, the correct answer for this question is en­ us. Enter this value into each of the boxes except for LayeredDriver under settings in the  upper‐right pane.  Note  You wouldn’t necessarily know this by looking, but LayeredDriver is only  used by Japanese and Korean keyboards. I bring up this point to highlight  how much research, guessing, and testing you’ll be doing when you attempt  to customize. So, yes, what you’re thinking is correct: This isn’t easy. Keep  following along, and I’ll at least get you started.  Also notice in Figure 2.9 that amd64_Microsoft­Windows­International­Core­ WinPE_{version}_neutral has another question below it in the subfolder marked  SetupUILanguage. You’ll want to answer that question as well. Click to view  SetupUILanguage, and enter en­us again next to UILanguage in the upper‐right pane. 

 

28

 

Automating Windows 7 Installation for Desktop and VDI Environments 

The Remaining Questions and Answers  You have now completed answering the first question. Table 2.1 provides all the questions  and answers. For each, I’ll explain the question as well as possible corresponding answers.  Remember that these answers are for my environment as I’ve been building it in this book.  Thus, yours might be slightly different. Locate and answer each of these before moving on.  Windows Image Pane (Question) 

Upper­Right Pane  (Answer) 

Explanation 

amd64_Microsoft‐Windows‐ International‐Core‐ WinPE_{version}_neutral 

InputLocale = en‐us  SystemLocale = en‐us  UILanguage = en‐us  UILanguageFallback = en‐us  UserLocale = en‐us 

This item configures the  WinPE language to US English. 

amd64_Microsoft‐Windows‐ International‐Core‐ WinPE_{version}_neutral\  SetupUILanguage 

UILanguage = en‐us

amd64_Microsoft‐Windows‐ Setup_{version}_neutral\  WindowsDeploymentServices\  Login\Credentials 

Domain  Username  Password 

Enter the domain, username,  and password of the user who  connects to your WDS share  (the same user as in Chapter 1,  Figure 1.10). 

amd64_Microsoft‐Windows‐ Setup_{version}_neutral\Disk  Configuration\Disk 

DiskID = 0

This item begins working with  the first disk in the computer. 

amd64_Microsoft‐Windows‐ Setup_{version}_neutral\Disk  Configuration\Disk\Create  Partitions\CreatePartition 

Extend = true  Order = 1  Type = Primary 

This item creates a single  primary disk to install  Windows. 

amd64_Microsoft‐Windows‐ Setup_{version}_neutral\Disk  Configuration\Disk\Modify  Partitions\ModifyPartition 

Active = true  Format = NTFS  Label = Windows  Letter = C  Order = 1  PartitionID = 1 

This item modifies that  partition to create the C: drive  as the first NTFS drive and  partition. 

amd64_Microsoft‐Windows‐ Setup_{version}_neutral\  WindowsDeploymentServices\  ImageSelection\InstallTo 

DiskID = 0

This item installs Windows to  the disk and volume created in  the rows above. 

amd64_Microsoft‐Windows‐ Setup_{version}_neutral\  WindowsDeploymentServices\  ImageSelection\InstallImage 

Filename  ImageGroup 

PartitionID = 1 

 

See the note below. 

ImageName 

Table 2.1: Step Five’s remaining questions and answers.   

29

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Note  The InstallImage question is a special case. If you want complete automation,  enter the filename, Image Group, and Image Name of the image you want to  deploy from WDS. You can get this information by reviewing the properties  of the image in WDS. In my case, the filename will be install.wim, the  ImageGroup will be Windows 7 Default, and the ImageName will be Windows  7 ENTERPRISE.  If you do not enter values, you will be given the option to select an image at  the time of installation. Thus, there’s a tradeoff between full automation and  being able to choose an image at every OS deployment. Remove the question  entirely from the answer file if you won’t be supplying answers. 

Validating, Saving, and Adding the Answer File to WDS  The hard part is done! Three easy steps are next: validating the answer file, saving it, and  finally entering it into WDS. The first step is validation. Run a validation by selecting Tools |  Validate Answer File.  Your answer file should validate with no warnings or errors. If one exists, WSIM will tell  you what needs to be fixed. For example, Figure 2.10 shows the error message you would  see if your DiskID item under Disk was missing a value. Fix any errors and re‐run the  validation again until it reports No warnings or errors. 

  Figure 2.10: A validation error.  Save the answer file to the C:\RemoteInstall folder on the WDS server by selecting File |  Save Answer File. Because this answer file will be located under the Client tab in WDS, let’s  name this file unattend_x64_client.xml.  Answer files for WinPE are configured on a per WDS server basis and not a per boot image  basis. Thus, a single answer file will be used for all deployments of a particular architecture  (x86, ia64, or x64) for the entire WDS server. You can attach answer files you just created  by navigating back to the WDS console, and right‐clicking the server name | Properties.  Under the client tab (see Figure 2.11), select the Enable unattended installation check box,  and click Browse next to the correct architecture (x64 in my case). Provide the path to the  unattend_x64_client.xml file, and click OK. 

 

30

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 2.11: Adding the unattended installation file to WDS.  At this point, you might want to re‐run another OS deployment, just to see how the  installation has now automated its first steps. As you’ll discover, you won’t be asked any  questions until you get to the Set Up Windows wizard after the installation completes.  Fixing that is a job for Step Six. 

Step Six: Automating the Set Up Windows Phase  Getting rid of that pesky Set Up Windows wizard requires one more step in fully  automating the installation. By combining this step, what we accomplished in Step Five,  and the driver work in Step Four, you’ve fulfilled this chapter’s goal of creating a universal  Windows image that installs anywhere. 

 

31

 

Automating Windows 7 Installation for Desktop and VDI Environments 

You already know that WSIM provides you an almost‐too‐much‐to‐handle list of possible  questions and answers that customize your Windows installation. At this point, however,  what you want is that universal image that installs everywhere with no added effort. This  step will show you the few additional questions and answers WSIM can manage in order to  eliminate the Set Up Windows wizard. Any further customization I’ll leave to your own  curiosity. You can spend literally days tweaking unattend files in WSIM to get the process  just right.  Getting through Set Up Windows means addressing four areas: Setting the time zone,  accepting the EULA, setting up the network location, and creating a local administrator and  password. Each of these steps can be pre‐answered through the same WSIM tool you’ve  already experienced in Step Five. Different here is where you’ll attach that file once created.  Rather than attaching it to the Clients tab for the WDS server, you get to apply your  unattend file directly to the image you plan to deploy.  Rather than go through the process again for using WSIM, let me give you a second table of  questions and answers that you’ll need. As in Step Five, use WSIM to create an unattend file  with these questions and whatever answers make sense for your environment. However,  there is one important difference. For Step Six, you’ll be adding your questions and answers  to different passes in the installation process, specifically Pass 4 and Pass 7, rather than  Pass 1. Table 2.2 includes the correct passes to get you going. Remember that, as before,  these answers are for my environment as I’ve been building it. Yours might be slightly  different.  Windows Image Pane  (Question) 

Upper­Right Pane  (Answer) 

Explanation 

amd64_Microsoft‐Windows‐Shell‐ Setup_{version}_neutral (Pass 4) 

ComputerName =  %MACHINENAME%  TimeZone 

Setting ComputerName to  %MACHINENAME% will  pass through the name you  set in WDSs Name and  Approve. Set TimeZone to  your correct time zone, such  as Mountain Standard  Time. 1

amd64_Microsoft‐Windows‐ International‐ Core_{version}_neutral  (Pass 7) 

InputLocale = en‐us SystemLocale = en‐us  UILanguage = en‐us  UserLocale = en‐us 

This item configures the  Windows language to US  English. 

 

                                                         1

 

 See technet.microsoft.com/en‐us/library/cc749073(WS.10).aspx for a list of applicable time zone strings. 

32

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Windows Image Pane  (Question) 

Upper­Right Pane  (Answer) 

Explanation 

amd64_Microsoft‐Windows‐Shell‐ Setup_{version}_neutral\ oobe  (Pass 4) 

HideEULAPage = true HideWirelessSetupIn OOBE  = true  NetworkLocation = work  ProtectYourPC = 1 

Hides the EULA and  wireless setup screens, sets  the network location to  work, and enables  Automatic Updates. 

amd64_Microsoft‐Windows‐Shell‐ Setup_{version}_neutral\  UserAccounts\LocalAccounts\  LocalAccount  (Pass 7) 

DisplayName = LocalAdmin Group = Administrators  Name = LocalAdmin 

This item adds a local  administrator account  named LocalAdmin. 

amd64_Microsoft‐Windows‐Shell‐ Setup_{version}_neutral\  UserAccounts\LocalAccounts\  LocalAccount\Password  (Pass 7) 

Value = {Password}

This item configures the  password for the  administrator account  created earlier. 

Table 2.2: WSIM questions and answers for Step Six.  As before, validate this file and save it to complete this step. I’ll name my file  C:\RemoteInstall\unattend_w7_enterprise.xml as this file corresponds specifically to the  Windows 7 ENTERPRISE deployment in WDS.  Note  I mentioned that you could add customization. One place to do so is in the  subfolders of amd64_Microsoft­Windows­Shell­Setup_{version}_neutral. You  can either further personalize your installation by answering their questions,  or remove them from the file by right‐clicking each, and choosing Delete.  Be aware that your validation may display a set of yellow warnings if these  subfolder items are not populated with information or not removed from the  unattend file. So plan on either answering them or deleting them so that  validation completes successfully.  As in Step Five, the final part of Step Six is to attach this file to its correct location inside  WDS. To do so, navigate to the WDS console in Server Manager, then go to Install Images  and find the install image for the unattend file you just created. Right‐click that install  image, and view its properties.  You’ll see a check box at the bottom of the properties window (see Figure 2.12). Select this  check box, and click Select File. Provide the path to the unattend_w7_enterprise.xml file,  and click OK. 

 

33

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 2.12: An image’s properties.  You’re done! At this point, re‐run your installation one more time and amaze yourself with  a Windows 7 OS that fully deploys without additional input. 

Time for Applications  In two chapters, we’ve started with little more than the manual installation of Windows  and added six steps of automation. You now know how to extend the basic image to  virtually any kind of hardware through drivers and Plug and Play. You also know how to  automate the WinPE and Set Up Windows portions of the installation so that you can kick  off a deployment and come back to a CONTROL+ALT+DELETE screen.  Yet there are still a few things that remain ominously missing at this point. The first and  most obvious of these are those pesky applications. A Windows computer isn’t terribly  useful for users if they’ve got no applications to run on that computer. That will be the topic  for the next chapter. In it, I’ll show you different approaches for getting applications onto  computers, some of which might surprise you.   

34

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Chapter 3: Techniques in Installing  Applications During Windows Deployment  Chapter 2 covered the first six steps in creating a fully‐automated and universal Windows 7  image. With those six steps, you’re ready to start deploying Windows with fully‐automated  ease. However, you can probably imagine that there’s an important piece of this  deployment that’s still missing: the applications.  In this chapter, I’ll discuss two very different techniques that you can use to install  applications onto Windows 7 desktops during a deployment. I’ll start by explaining the  thick approach, and will then begin the dive into a discussion of the layered approach.  The thick approach is probably similar to how you’ve been handling applications. Using the  thick approach, you create one or more master images that contain the operating system  (OS) along with any applications you want deployed. Once created and configured to your  liking, this master image is captured back to your WDS server and later redeployed to  computers around your network. The approach is called thick because the images grow  large as applications and configurations are added.  The thick approach with master images has long been used because it is easy to  comprehend. Simply create an image, make any configuration changes, install and  configure applications, and finally capture that image back to the deployment server.  Although the approach requires extra steps, it is easy to visualize what the user will get  when the captured image is redeployed: If you created it on the master image, the user will  get it.  

Step Seven: Creating a Master Image with Applications  The creation of a master image starts with the deployment of a basic image to a master  computer. This master computer will be the location where you will perform the image  customization work. Deploy that basic image using the process you learned in the previous  two chapters.  Once the image is deployed to the master computer, make the changes you want eventually  deployed to users. In addition to installing applications, you might want to set a few of their  initial configurations to make things easy. You might also want to install any licenses that  can be legally replicated throughout your network. Remember that any change you make  on this master image will be copied to every other computer when the image is later  deployed. 

 

35

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Audit Mode  Windows Vista and Windows 7 now include a special configuration “mode”  called Audit Mode. Although you can absolutely make changes to your master  computer without using Audit Mode, this special mode enables a set of  protections for master images during this customization process.  Using Audit Mode is optional and out of scope for this book. For more  information, see http://technet.microsoft.com/en‐ us/library/dd799305(WS.10).aspx.  In my sample master image, I deployed a copy of Windows 7 using our process thus far and  then installed Microsoft Office. For grins, I also changed the theme and configured the  power settings for the computer. For our sample solution, these simple changes represent  the only custom configurations I’ll set in my master image. 

Invoking Sysprep  You’ll need to Sysprep the computer as the very last step in this customization process. A  Sysprep must be completed to prepare the computer for being deployed, as it completes a  process called generalization. The generalization process eliminates all the data on the OS  instance that links it to the hardware on which it was installed. By generalizing, you can  later redeploy this image to other hardware.  Older versions of Sysprep were quite painful to use. Luckily, it has gotten quite a bit easier  in Windows 7 to complete this task. Sysprep is now available directly on every Windows 7  instance. To launch Sysprep, run the command  C:\Windows\System32\sysprep\sysprep.exe 

Running sysprep.exe will bring forward the dialog box you see in Figure 3.1. 

  Figure 3.1: The System Preparation Tool dialog box.   

36

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Note in Figure 3.1 that the System Cleanup Action is set to Enter System Out­of­Box  Experience (OOBE), and that the Generalize check box is selected. These two settings revert  the computer back to a point where the Set Up Windows wizard will be displayed upon the  next reboot. This action puts the computer into the correct position for deployment. That is  the same position we experienced with our basic image in the previous chapters. You’ll also  note that I’ve configured the Shutdown Options to Shutdown the computer once it has  completed generalizing. This is important for the next part of this process.  Note  Pre‐staging the computer into this mode means that our original unattend  files—those we worked on in the previous chapter—should still work in  customizing and automatically deploying this computer in the same way as  our basic image.  You should still be able to use your original unattend files, even against this  customized image. Just make sure that you re‐attach them to the new image  back in WDS after capturing the image in the next step. 

Creating a Capture Image  To deploy this image, you’ve first got to capture it to your WDS server. Capturing that  image requires the use of a special boot image I’ll call a capture image. This capture image  boots the computer to WinPE just like a boot image. But instead of handing off to an install  image, the capture image instead gathers the computer’s data into a master image.  Let’s create that capture image. Go to your WDS server, and click Boot Images. Right‐click a  boot image, and choose Create Capture Image. You’ll be presented with the Create Capture  Image Wizard just like you see in Figure 3.2. Give the capture image a name and description  as well as a storage path. You’ll notice that I’m storing my capture image with the boot  image in C:\RemoteInstall\Boot\x64\Images. Click Next to create the image, which will take  a few minutes to complete. 

 

37

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 3.2: The Create Capture Image Wizard.  After the image has been created, you’ll be presented with a Task Progress screen (not  shown here). There will be an Add image to the Windows Deployment Server now check box.  Select that box, and click Finish. This step adds the just‐created capture image back to the  WDS server, enabling the capture image to be deployed over the network just like we’ve  been doing with every image so far.  Run through the resulting Add Image Wizard to add the new capture image back to WDS.  Figure 3.3 shows how I’ve given this image a name of Microsoft Windows Capture (x64).  Completing this wizard and adding the image takes a few minutes once again, but as a  result, you’ll be able to capture a master computer’s image in the same way that you deploy  an image—over the network! 

 

38

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 3.3: The Add Image Wizard. 

Capturing the Master Image  That was the hard part. Your last task in this step is to capture the image you’ve just  generalized and made ready for deployment. At this point, the master computer should be  powered down if you configured Sysprep per the instructions. Sysprep needs it to remain  powered down so that its power‐back‐on‐into‐Set‐Up‐Windows state is captured by the  capture image.  You’ll do that now, but be terrifically careful with this step. Power on the powered‐down  master computer and connect it to your WDS server via PXE boot. You must make sure not  to power on the computer into its Windows installation. Quickly power it back down if you  have any problems with PXE. Assuming you’re successful with the PXE boot, you’re ready  to capture its image. 

 

39

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Note  There’s another important change to be made here first. Remember back in  Chapter 2 when we attached the unattend_x64_client.xml unattend file to our  WDS server? That unattend file boots computers and immediately begins  deploying our basic Windows 7 boot image. You don’t want to deploy an  image at this point, you want to capture one. So, the unattend file needs to  disappear for a while.  To ensure that you boot to the correct image, right‐click to view the  properties of the WDS server, and select the Client tab. Clear the Enable  unattended installation check box. You can re‐select the check box after  you’ve completed the capture.  If you’ve done everything correctly, your master computer will boot to a  screen similar to the following image. There, you’ll want to select the capture  image to start the capture process. Be very careful with this process, as  booting back to Windows may require needing to re‐Sysprep and shut down  the computer before trying again. 

  Don’t forget to select the Enable unattended installation check box once  you’ve completed your capture. That returns your WDS server back to its  normal operation for automatically deploying images.  The next set of steps is a manual process; however, this is OK because you’ll be doing them  relatively rarely. After booting with the capture image, you’ll see an initial welcome screen.  Click Next to see the Directory to Capture screen, similar to Figure 3.4.  Anyone think it’s funny they call this the directory to capture? Sorry, I digress… 

 

40

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 3.4: Directory to Capture.  The drop‐down box on this screen is exceptionally important. In it should be the volume of  the computer you’ll want to capture back to WDS. You can see in my example that C:\ is the  volume I’m interested in capturing. If you do not see a volume here, your Sysprep did not  complete successfully. If you don’t see a volume, log out of the capture mode before  attempting any other action, power on the computer back to its installed OS, manually  answer the Set Up Windows questions, make any necessary changes, and re‐Sysprep the  computer before starting this process again.  In Figure 3.4 are also Image name and Image description boxes. These are intended for the  name and description of the image as will be seen in WDS. I’ve named mine to show that  this image is comprised of my basic Windows 7 ENTERPRISE image plus Microsoft Office.  Click Next to continue.  The next screen, shown in Figure 3.5, identifies where you want to store the install image.  Be aware that this New Image Location screen behaves a little strangely. Follow along  closely because I experienced some problems the first few runs through. 

 

41

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 3.5: New Image Location.  Remember how creating a capture image required two steps? In the first step, the image  was created, then it was uploaded to the WDS server. This rather‐confusing window needs  to accomplish both of those tasks. Problem is that you don’t necessarily want to store your  image on the master computer; you want to store it on your WDS server.  It’s here where things get tricky. Click Browse in the Name and location box to browse to  the Images folder on your WDS server. For me, the correction location was  \\wdsserver\c$\RemoteInstall\Images\Windows 7 Default. There, give the image a name,  which in my case was Windows7_Office.wim. You will be prompted to enter credentials to  make this connection.  After completing this step, select the Upload image to a Windows Deployment Services server  (optional) check box. Enter the name of your WDS server under Server name, and click  Connect. You will be prompted again for credentials. After successfully authenticating to  your WDS server, a list of image groups will appear under Image Group name. Select the  correct image group, and click Next to continue. 

 

42

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Note  I’ve seen some very strange behavior at this configuration screen. Namely,  that the authentication session used to connect to the WDS server’s disk  could not be shared by the WDS server connection. To get around this odd  limitation, I used the server name for the disk connection and its IP address  for the WDS connection.  You might experience different results. If your connection attempt results in  an error message, consider using my dual name and IP address trick to  connect.  You’re done! The capture process should begin. Capturing an image takes a bit longer than  deploying one, so plan on quite a few minutes passing. Also, as with image deployments, be  conscious about the large amount of network traffic that an image capture can generate. At  its conclusion, you should find your newly‐created image in the WDS console. Consider  performing a test deployment to see how well it works and whether your configurations  deploy correctly.  Your configuration should not have affected many of the questions and answers in your  unattend file. If you have configured a specific image to be deployed in your Client file,  you’ll want to change its name and filename. The other settings should remain effective and  should correctly answer the questions required by this custom image’s Set Up Windows  prompt. If you’ve done everything correctly, you should be able to deploy your custom  images using exactly the same process as your basic images from Chapters 1 and 2. 

Stepping Back: Application Delivery Mechanisms  Step Seven seems pretty involved, particularly when you pair it with the realization that  every little change to a Windows image will require a deployment, a configuration change,  and a capture. That’s a lot of steps when you consider how often changes can be necessary.  An interesting thing about the Windows XP‐to‐Windows 7 upgrade in comparison with  previous OS upgrades are the new mechanisms now available to actually deliver  applications to users. Before I get into any step‐by‐step processes, I want to step back a  minute and really focus on the concept of application delivery. Remember back not too  many years ago when we didn’t have many options for delivering applications. For most of  us, when a user needed an application, we arrived at their desk with a DVD and installed it  locally. 

 

43

Automating Windows 7 Installation for Desktop and VDI Environments 

 

That “DVD” application delivery mechanism suited us well for many years, but over time,  we grew tired of needing to show up at every desk after every request. It is at that point  where other application delivery mechanisms grew compelling:  •

Group Policy Objects (GPOs) began delivering applications through our Active  Directory (AD) infrastructure. 

•

Application management solutions like System Center Configuration Manager,  System Center Essentials, and others from third parties gained widespread use. 

•

Application virtualization solutions like Microsoft’s App‐V, among other third‐party  solutions, can now stream an application through what can only be called a glorified  file copy. 

These nifty solutions enable us to evolve towards a kind of layered approach in managing  our desktops—and, indeed, our desktop images. Rather than installing applications and  other customizations directly into images—the thick approach—smart administrators  know that a thin approach is a lot more manageable.  With the thin approach, deployed images remain relatively basic, containing few  applications that are directly installed into the image. Pairing down the image to a  configuration that is as simple as possible reduces the need for updates over time. Instead,  applications are installed (layered!) on top of the basic image using one of the other  mechanisms discussed in the previous bulleted list. You’ll obviously have a bit more setup  in constructing that layering infrastructure, but the result will be a much cleaner and more  elegant solution. More importantly, after the up‐front work is complete, your day‐to‐day  operations became far, far easier.  Figure 3.6 shows a graphical representation of this layering that I first created for TechNet  Magazine back in December 2009 2 . In it, take a look at the Core Operating System and its  Drivers. These elements, which we worked on in Chapter 2, are only part of the giant stack  that makes up every desktop. 

                                                        

2

 

 http://technet.microsoft.com/en‐us/magazine/ee835710.aspx 

44

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 3.6: Layering Windows OS deployment.  I’ll spend some time with the other elements in this stack in other chapters. For now,  however, I want to continue the conversation by talking more about the layer marked  Applications. 

From Thick to Thin  Think about how the thin approach will dramatically change your management of desktop  images. Let’s compare “thin” with “thick”: How many desktop images do you have today?  Ten? Dozens? Hundreds? You’ve needed each of those desktop images because they’re  slightly different in composition. One may have Office 2010 on it, while another still holds  Office 2007 or even 2003. Even others may be different only in their drivers.  We fixed the driver problem in the previous chapter. There, we used WDS’ Drivers node to  create a pool of drivers that any deployment can pull from when Plug and Play finds a  hardware match. Accomplishing this means we can now get rid of every image that’s only  different because of its driver composition.  This chapter’s goal is to get you started down the road of eliminating the rest of your  images. Those images exist because their application composition is different. This chapter  won’t yet give you the complete solution, but it starts the discussion. Actually getting to  that thin nirvana will take many of the remaining chapters. 

Thick to Thin: What Do You Need?  Think about the only real way to get to this single‐image nirvana: Stopping the practice of  installing applications and customizations directly inside the image. That’s kind of a neat  thought, yes? If I deploy an image that doesn’t contain applications—or that contains only  the applications I want everywhere—I can then layer on top of that image everything else  during subsequent steps. 

 

45

 

Automating Windows 7 Installation for Desktop and VDI Environments 

What would I need to do this?  1. I need some mechanism to automatically install applications to desktops after  they’re deployed.  2. I need some mechanism for identifying which applications should be installed onto  which desktops.  3. It would be nice to have another way to inventory applications on my existing  desktops and hold that information in reserve. I could then use it to redeploy the  correct applications after the desktop is upgraded.  4. I need a way to repackage those applications so that they can be installed via this  magical automatic installation system. As with the Windows installation, fully‐ automated application installation needs to ask no questions during an installation.  It needs to start, finish, and be done.  5. I need to recognize that the applications themselves are only part of the job. Along  with applications, most users have data that needs to be transferred with the  application. Users don’t like it when their data isn’t available after their computer is  upgraded, and the manual steps to make that data available are painful for them and  us. As a result, any upgrade project should probably automatically manage my user  data as well.  That’s a pretty tall order of features. And you’re right in thinking that we’ll need to add  capabilities into our automated solution if we’re to get there.  What’s great is that you can actually fulfill these needs using Microsoft’s free solutions. You  can also fulfill these needs using for‐cost solutions. As I mentioned in Chapter 1, although  Microsoft’s no‐cost solutions might not be the slickest ones around, they’re free.  If your deployment project is small, low in complexity, or suffers under a really small  budget, Microsoft’s no‐cost solutions integrate perfectly to create most of this single‐image  nirvana. If you’ve got a few more bucks, use them to expand that solution to include some  of the costlier bits—either from Microsoft or third parties. Those additional spendy bits  bring greater administrative control, more reporting, and better granularity in the actions  they perform. 

The Microsoft Deployment Toolkit  But this book is all about the free tools, so that’s where we’ll focus. I’m sure there are plenty  of third‐party solution salespeople who’ll be happy to explain how their products make all  of this simpler.  Once you’ve implemented what I’ve told you in Steps One through Seven, you have  everything you need to create a fully‐automated and universal system for deploying  Windows 7. You can actually put down this book and start deploying Windows with  success. In fact, if your upgrade project is really small, these seven steps are probably all  that you need. 

 

46

 

Automating Windows 7 Installation for Desktop and VDI Environments 

If your upgrade project is more than really small, the steps to this point probably don’t  fulfill your needs. You’ve got to be pretty curious at this point how to get to this layered  approach for applications, user data, and other customizations. Even if you’re small, after  going through that painful deploy, reconfigure, and capture process a few more times, this  layered concept will probably become compelling.  Unfortunately, we’ve pretty much come to the end of the capabilities that we can squeeze out  of WDS alone. In order to take that next step in evolving our solution towards real  automation, we need to layer another of Microsoft’s acronyms (and applications) on top of  WDS. That new acronym and application is called the MDT or the Microsoft Deployment  Toolkit.  If you’ve been around the block for any period of time, you know that Microsoft’s  deployment tools have for years been…well…awful. They worked, but they were very  technology focused in the capabilities they presented. What the world has really wanted is  a more process‐focused solution; one that could truly automate all the usual workflows  that make up an upgrade project: user data collection, application inventory, application  compatibility checking, application installation, and user data injection—all those “other”  tasks that had for so long not been there in RIS, WDS, and the other tools alone. What the  world wanted was a way to create sequences of the tasks that go on in an upgrade project.  Those sequences would be codified instructions that automatically did all those nifty things  on behalf of the administrator. What a neat idea, eh? Well, Microsoft listened, and the MDT  was born. 

Coming Up: Folding Your Deployment Infrastructure into the MDT  The next chapter will start our exploration into the MDT. As you’ll discover, the MDT  arrives as a kind of procedural wrapper around all the technologies that we’ve already  explored to this point. You won’t necessarily be throwing away anything you’ve already  learned. In fact, by navigating your learning in this way, you’re particularly prepared to do  well with the MDT’s task sequence method of deploying Windows desktops.  The next chapter continues the conversation on techniques in installing applications,  focusing on the ways in which the MDT streamlines the process and moves you towards a  more layered approach. I’ll start by helping you get the MDT installed and initially  configured. Then, I’ll show you the steps you’ll need to implement to incorporate  application installations within your Windows deployment.  You also know that applications aren’t everything. Applications by themselves are only of  limited assistance. You also need to return user data back to a computer after it’s been  upgraded. Following Chapter 4, I’ll continue by discussing the all‐important topic of user  data and show how the MDT will assist in preserving that data during an upgrade. 

 

47

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Chapter 4: Layering Applications on Top of  Deployed Windows Images  The previous chapter offered a half‐chapter of step‐by‐step Automating Windows 7  Installation content. In that chapter, you learned about Step Seven of the deployment  process: where you can customize your basic Windows 7 images—those right off the DVD  media—through the deploy‐modify‐capture method commonly called the thick approach. I  mentioned that at the conclusion of Step Seven you’re absolutely ready to begin deploying  images. Step Seven and those prior give you everything you need to be successful in  deploying Windows 7 using that thick approach. Rejoice!  Yet the second half of Chapter 3 focused less on the step‐by‐step; it was dedicated towards  pointing you in the direction of a new and arguably smarter approach: the thin approach.  Using the thin approach, applications, customizations, and user data are not configured  directly on the image; instead, those changes are layered on top of a basic image. They’re  deployed using other tools. One tool that is commonly used (at least among Microsoft’s no‐ cost options) is the Microsoft Deployment Toolkit (MDT).  This chapter will reposition your Windows 7 deployment solution inside the framework of  the MDT to gain added flexibility in deployment. Yes, we’ll for a minute lose some of the  automations that we’ve worked so hard to implement; but we’ll replace them with a much  more capable interface for the real needs of our project. And don’t worry, I’ll help you add  those customizations back by the book’s conclusion.  In this chapter, you’ll learn how to install and initially configure the MDT, how to deploy an  image, and how to link applications to that deployed image. At its conclusion, you’ll see why  the thin approach can be far superior to its thick alternative in dealing with applications.  Time for an applications diet. 

Step Eight: Installing and Preparing the MDT  As of this writing, the MDT’s current version is MDT 2010 Update 1. Thus, start this step by  locating and downloading this version from Microsoft’s Web site. Install it to your WDS  server. You’ll find that the MDT installation is exceptionally simple, requiring only a few  very basic questions to get started. 

 

48

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Note  The MDT requires the WAIK for its installation, which you already installed  to the WDS server back in Step Five.  Once installed, your first step will be in creating a deployment share. It is within this  deployment share where much of your work will be stored. You’ll find yourself here during  most of your MDT administration. Right‐click the Deployment Share link, and choose New  Deployment Share to begin. Six questions are asked as part of the New Deployment Share  Wizard. You’ll need to provide a path, share name, and descriptive name for the location on  disk where deployment data will be stored. I’ll use the location C:\DeploymentShare.  You’ll also be asked three questions regarding whether you want the MDT to confirm  whether an image should be captured (see Figure 4.1), whether you want users to set a  local administrator password during deployment, and whether you want users to enter a  product key. Accept the defaults for each of these questions to begin. 

  Figure 4.1: Allow image capture.  Completing this task creates the deployment share in the workbench. Figure 4.2 shows an  example of how the workbench will look. You’ll notice that the deployment share comes  equipped with a few additional components that weren’t available in WDS, such as the  Applications, Packages, and Task Sequences nodes. As I mentioned in the previous chapter,  MDT wraps around the knowledge you’ve already gained at this point. Using MDT, you’ll be  able to create useful task sequences that better define the characteristics of images as  they’re deployed to desktops.   

 

49

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 4.2: The Deployment Workbench. 

Importing an MDT Image  But before we get there, let’s get the MDT up to a level of capability we’ve already  accomplished with WDS. You’ll be happy to know that this won’t take much effort. Start by  right‐clicking Operating Systems, and choosing Import Operating System.  We’ve already created a set of images that the MDT can import. These images are located  on our WDS server; we now just need to make them available in the MDT. Do so by  selecting Custom image file in the OS Type window (see Figure 4.3). Click Next, and enter a  path to the image’s .WIM file. If you’ve been following along, I will be uploading the custom  image we created in Chapter 2 called Windows 7 ENTERPRISE + Office. That image is  located in C:\RemoteInstall\Images\Windows 7 Default.   

 

50

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 4.3: OS Type.  I didn’t select the Windows Deployment Services images option because there appears to be  an issue with this option in the current MDT version. Part of that issue relates to the need  to import Windows 7 setup files with the custom image. In the end, choosing the Custom  image file route made everything work just fine.  Figure 4.4 shows the screen you’ll see next if you select Custom image file in Figure 4.3. At  this screen, select the second option to Copy Windows Vista, Windows Server 2008, or later  setup files from the specified path. Enter Setup source directory path to the Windows 7 DVD  media, and click Next. Failure to complete this task may generate an error message as you  attempt to deploy an OS image in a later step. Click through the remaining screens in the  wizard to import this image. 

 

51

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 4.4: Specify OS files. 

Importing Drivers  After uploading an image, you’ll want to upload the set of custom drivers you collected for  WDS in the previous chapter. Do so by right‐clicking Out­of­Box Drivers, and selecting  Upload Drivers. The wizard, seen in Figure 4.5, will ask for the folder where the drivers are  stored. You created this folder in Step Four in Chapter 2. 

  Figure 4.5: Specify directory for the Import Driver Wizard.   

 

52

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Note  If you’re following along at home and using VMware Tools device drivers, be  aware that these drivers don’t function in WinPE. There is a way around this,  however: View the properties of your deployment share and look at the  Windows PE x86/x64 Components tabs. For now, set their selection profiles to  Nothing to prevent a WinPE boot failure.  Pay attention to the WinPE configurations in this screen. It is here where  drivers from your Out‐of‐Box Drivers node are injected into WinPE. Even if  you’re not using VMware Workstation, you’ll want to specifically tailor your  driver selections here so that inappropriate drivers aren’t injected into  WinPE. 

Creating a Task Sequence  Next, you need to create a task sequence for deploying a Windows image. This task  sequence adds the MDT’s useful workflow components into a deployment. You will create a  basic task sequence at this point and add to it in a later step.  Right‐Click Task Sequences, and choose a New Task Sequence to start the New Task  Sequence wizard. This wizard starts the creation of a task sequence by asking six questions:  The task sequence’s name, the template, OS, and product key to use, the name and  organization of the user as well as the Internet Explorer home page, and finally the local  administrator password.  Most of these settings should be self‐explanatory with the exception of the Select Template  page (see Figure 4.6). There, you’ll find seven task sequence templates to choose from. The  sequence you’ll want to create is a standard OS deployment. What we’re doing is not  performing a capture. We’re not replacing a client. We don’t intend to upgrade, but instead  deploy a fresh OS that assumes no existing user data. Therefore, select the Standard Client  Task Sequence, and complete the rest of the screens in the wizard. 

  Figure 4.6: Selecting a Task Sequence template. 

 

53

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Take a minute and peruse the properties of the task sequence you just created. Under the  Task Sequence tab, you’ll notice the impressive list of tasks (see Figure 4.7) that can be  customized as part of this sequence. I’ll return to these in a minute, but spend some time  familiarizing yourself with what you’ll soon be able to do. 

  Figure 4.7: The Task Sequence tab. 

Updating the Deployment Share  Next up is updating the deployment share. Among other things, this activity links the MDT  to WDS. The linkage requires two parts: First, right‐click your deployment share and view  its properties. Under the General tab, select the Enable multicast for this deployment share  (requires Windows Server 2008 Windows Deployment Services) check box, then click OK.  Next, right‐click your deployment share again, this time choosing Update Deployment Share.  This process updates the MDT’s needed configuration files and creates the necessary boot  images that you’ll use shortly. Accept its default values, and complete the wizard. This  process will take an extended period of time. 

 

54

 

Automating Windows 7 Installation for Desktop and VDI Environments 

The section action is to replace WDS’ original boot images with those that the MDT just  created. Don’t worry; they’re much nicer than the boot.wim that we’ve been using! Disable  any boot images currently on your WDS server by right‐clicking the image, and selecting  Disable. Then right‐click Boot Images, and choose Add Boot Image. The boot image can be  found in C:\DeploymentShare\Boot\LiteTouchPE_x64.wim if your deployment share is in  the same location.  Note  If in Chapter 2’s Step Five you configured your WinPE unattend file to point  towards a specific Filename, ImageGroup, and ImageName, now would be a  good time to remove those settings. 

Deploying a Basic Desktop with MDT  After completing the previous steps, you’re ready to deploy your first desktop with the  MDT. PXE boot that desktop just like you’ve been doing up until this point. Notice as its  booting that you are now booting from the MDT’s LiteTouchPE_x64.wim rather than WDS’  boot.wim file.  Once booted, you’ll be greeted with a very different desktop and a welcome screen than  what you saw with WDS. This new welcome screen comes equipped with quite a few more  options than in WDS (see Figure 4.8). Click the very large button marked Run the  Deployment Wizard to install a new Operating System, then enter appropriate credentials in  the resulting screen. 

  Figure 4.8: The Welcome Windows Deployment screen. 

 

55

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Now things begin to get very, very interesting. That task sequence we created just a minute  ago can be selected inside this wizard. In fact, any task sequence is now available for  selection. If you select a task sequence (see Figure 4.9, in my case Windows 7 ENTERPRISE +  Office) and continue through the wizard, you’ll be asked common questions like the  computer name, domain joining information, whether you want to restore user data  (new!), language, time zone, BitLocker configuration (also new!), and other preferences. 

  Figure 4.9: Select a task sequence.  You’ll even be asked if you want to use this deployment as a capture rather than a  deployment. All of these options are available in the same task sequence. Complete the  series of wizard pages and the deployment will begin.  It is important to recognize that although task sequences are all managed inside the MDT,  WDS continues to handle all the deployment responsibilities. That means WDS remains  responsible for your PXE boot infrastructure and all network transport requirements for  deploying images. You will, however, begin working with images now inside the MDT. 

Step Nine: Learning Silent Installations and Repackaging  One of the areas where the MDT truly shines is in its ability to layer applications on top of  an existing OS image. If you recall the second half of Chapter 2, this layering of applications  allows you to create a relatively thin OS image. That thin image has few configurations.  Thus, it has little in terms of regular maintenance needs, alleviating you from the need to  deploy, modify, and recapture the image with each change.  Applications are layered into images by adding them into the MDT’s Applications node. If  you right‐click that node, and choose New Application, you’ll be greeted with a wizard for  adding such an application. Figure 4.10 shows an example of the three types of applications  that can be added: those with source files, those without source files or located elsewhere  on the network, and application bundles (which are collections of applications). 

 

56

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 4.10: New Application Wizard  The second of these selections comes in especially handy if you have already generated a  stockpile of applications that have been repackaged to run silently. This repackaging process  is fundamentally important to application layering, and represents the biggest hurdle most  IT organizations have in making the thick‐to‐thin jump. Why? The process to repackage  applications can be complex, and is in many ways a bit of an art form.  The issue goes a bit like this: Remember how we reconfigured our images back in the early  steps of this book so that they would function without prompting for questions? By using  unattend files, we were able to answer those questions prior to a deployment, allowing the  deployment to continue through without prompting. The same holds true with thin‐ deployed applications. These applications need to be repackaged so that they operate  silently; essentially, so that they do not ask any of the normal questions an application  would ask when it is installed.  Let me give you a short primer that will get you started with repackaging your applications.  This isn’t a step‐by‐step process because every application is a little bit different. You’ll  need to do some sleuthing and more than a bit of detective work to accomplish this task  correctly. Once you learn the basics, you will be ready for Step Ten, in which I’ll show you  how to incorporate one silenced application—WinZip—into a task sequence. 

 

57

Automating Windows 7 Installation for Desktop and VDI Environments 

 

Three Ways to Silence Applications  Let me help you with the science behind the art. There are three common ways in which  software is typically installed to a computer:  •

MSI­based installations. These installations, all of which have an .MSI extension,  leverage the built‐in Windows Installer Service to complete their task. They share  this commonality, so they tend to be the easiest to repackage. 

•

EXE­based installations. A software installation with an .EXE extension typically  uses its own built‐in mechanism for installing itself. With a set of potential tools to  create these files, there are an equal set of ways to silence them. With these, you’ll  find yourself needing a little sleuthing to discover their secrets for silence. 

•

Differential­based installations. When neither of the other two mechanisms work  for an installation, tools are available that can snapshot the configuration of a  computer before and after an installation to determine which files and registry keys  changed. 

For the first two installation types, the solution for repackaging is in finding their silent  switches. These switches, such as /silent, /s, or /v /qn for example, instruct either the built‐ in installation code or the Windows Installer Service to install the package without  prompting the user. For the third mechanism, special tools are required. We’ll discuss all  three in the following sections. 

MSI‐Based Installations  MSI installations are generally the easiest to repackage to run silently. Every MSI  installation uses the Windows Installer Service. Thus, every MSI installation tends to have  similar silent switches that install the package silently.  Generally, all MSI‐based installations use the msiexec.exe command to invoke their  installation. The general syntax looks a bit like this:  msiexec.exe /qb‐ /l* {logfile.txt} /i {setup.msi} {NAME=Value} 

In the code, each switch instructs the Windows Installer Service to accomplish a different  task associated with the installation. Table 4.1 explains the job of each switch.  Switch

Description

msiexec.exe

Invoke the Windows Installer Service

/qb-

Use a basic user interface with no (modal) dialog boxes

/l* {logfile.txt}

Log all information about the installation to logfile.txt

/i {setup.msi}

Install the setup.msi application (as opposed to repairing or uninstalling it, which use different switches)

{NAME=Value}

[Optional] Set the NAME setting to the configured Value

Table 4.1: Common msiexec.exe switches. 

 

58

 

Automating Windows 7 Installation for Desktop and VDI Environments 

{NAME=Value] at the bottom of Table 4.1 requires additional explanation. Customizations  for MSI‐based installations are stored in a database‐like format. Thus, settings that  customize the installation for your environment—such as installation location, post‐ installation reboot suppressing, or other elements—can be set at the time of installation.  With MSI installs, these are typically completed in one of two ways—either by setting  individual values at the command line or by using a transform file. Transform files are used  when the number of customizations is large, as it allows individual customizations to be  wrapped into a single file. For example to install a version WinZip, you might use a  command similar to:  msiexec /qb‐ /l* logfile.txt /i WinZip.msi SERIALNUMBER={value} REBOOT=SUPRESS 

In this example, the WinZip.msi file is launched with two customizations. The first inputs  the serial number as it installs the software. The second instructs the installer not to reboot  the machine after the installation.  If a transform file were available for this same installation, it would change the installation  to resemble the following:  msiexec /qb‐ /l* logfile.txt /i WinZip.msi TRANSFORMS={transform.mst} 

The hardest part about repackaging MSI files can be in finding the right customization  settings for the command line. MSI interrogation tools are available to do this, and some  application vendors provide tools for generating your own transform files. The “art” in this  process is in determining what they are and how to use them.  Note  One very good way to find this information is to check out the Web site  www.appdeploy.com. This location includes a clearinghouse of many  common installations and their customization options. 

EXE‐Based Installations  EXE‐based installs can be more difficult than MSI‐based installations because each EXE‐ based install has its own built‐in mechanisms for repackaging for silent installation.  Sleuthing to find the appropriate switches is much of the “art” of software packaging.  The easiest place to start is by simply attempting to run the software installation with the  /? switch. This switch—as well as /help, ­­help, and others—can often display a dialog box  that presents the proper switches to be used for silent installation. Other common switches  that are known to work are /s and /s /v/qb. These switches are used by some of the  common enterprise packaging solutions for silent installation. 

 

59

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Note  There is no common schema among EXE‐based installations, so other  switches can also be configured to run the package silently, such as /q:a /r:n,  /silent, /passive, /quiet. The clearinghouse at www.appdeploy.com as well as  on the Web site of the application’s vendor can provide information about  EXE packages.  Another commonly used tactic is wrapping an EXE installation around an MSI file. Here,  when double‐clicked, the EXE file actually launches an MSI installation inside itself. With  these sorts of installations, the use of the /a switch can sometimes assist with extracting  the MSI file from its host EXE.  Try this process with the /a switch: From a command prompt, run  setup.exe /a 

This launches what is called an administrative installation of the software. Often, this  administrative installation can prompt you through the installation as if you were installing  it on a computer. Instead of actually installing the package, it results in an unpacked MSI  file that has been preconfigured with your stated customizations. That MSI file can then be  launched silently using the techniques discussed earlier.  A second tactic to unpack the MSI file is to double‐click the EXE file and allow it to unpack  itself. When the first screen of the installation presents itself, leave the screen open and  look in the computer’s %TEMP% folder. Often, you’ll find the MSI file you’re looking for in  that location. 

Differential‐Based Installations  Last is the situation where no matter of sleuthing can determine how to directly convert  the software’s installation to silent mode. Such is often the case when the software’s  developer didn’t include the necessary code to make it run silent. In these cases, the  optimal solution for repackaging this software is through what I’ll call a differential­based  installation or diff.  In a diff, a special piece of software is used that snapshots a computer. The computer used  for these snapshots should be relatively free of configurations. It should include the same  OS on which you eventually intend to deploy the software. It should also contain the  minimum amount of software necessary to install the piece of software you intend to  repackage. 

 

60

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Two snapshots are created. The first captures each file, folder, and registry key present on  that system. Once the first snapshot has completed, the software to be repackaged is then  installed to the computer. After installing the software, a second snapshot is taken. The diff  tool then scans the two snapshots to look for changes to files, folders, and the registry.  Changes are presented to the administrator through a tree‐like interface that allows you to  selectively remove any extraneous findings (these can be common). Once removed, the  remainder is then repackaged into a new MSI file that automatically runs silently.  Software Is Really Just Files and Registry Keys  At its core, a software installation is little more than a process that copies a  set of files and folders to a target system, adds, updates, or removes a set of  registry keys. Sometimes drivers are registered, but at the end of the day, a  software installation isn’t much more than a file copy and a registry change.  Professional installers may include additional functionality that streamlines  this process, but in the background, these are the main two steps used to  install virtually all pieces of software.  Thus, if you merely watch to see which files and registry keys have changed,  you’re probably going to capture what the software installation program  actually accomplished. Just repackage those changes, and you’ve got your  silent installation.  Many diff tools are exceptionally expensive and are parts of enterprise‐class software  distribution platforms. These expensive software packages can be too costly for the small  IT shop. One long‐standing and no‐cost solution still available today is the software tool  called WinINSTALL LE (found at http://www.scalable.com/wininstall‐le). This tool should  be installed onto a clean reference computer. Once installed, run WinINSTALL LE’s Discover  menu item to begin the snapshot/installation/re‐snapshot process. 

Step Ten: Laying Applications Atop a Windows Image  Though the information in Step Nine only scrapes the surface of the dark art of software  packaging, it serves as a starting point moving towards the thin approach to application  installations. Out of each of the steps in this book so far, Step Nine will probably take you  the longest to comprehend. So don’t get too discouraged if you don’t understand its  processes at first. I didn’t.  In Step Ten, I want to show you the step‐by‐step processes you can use to layer an  application—once silenced—into a Windows image. Be aware that you may not want to do  this with every application. Those applications that you anticipate every user needing, such  as Microsoft Office and/or other common applications, may be better managed by being  directly installed (using the thick approach) onto the image. The decision about how to  deliver an application will depend on your environment’s individual needs. 

 

61

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Let’s assume that for Step Ten, I have already repackaged the WinZip application using the  diff method from Step Nine. Using that method, I have an installation that runs silently.  When invoked, its MSI installation automatically installs the WinZip application onto a  Windows desktop. Rather than applying it directly to the image, I want to layer WinZip only  for those users who need it. This application currently resides in my IT share found at  \\wdsserver\ITApplications\WinZip. 

Adding the Application to the MDT  Back in the MDT, right‐click the Applications node, and choose New Application. Just like in  Figure 4.10, I’ll choose Application without source files or elsewhere on the network because  I don’t want to import the application directly into the MDT.  Figure 4.11 shows the next screen in this wizard where I’m prompted for the publisher,  application name, version, and language of the application. This information is useful when  the time comes to deploy the application. Thus, although the four selections are optional,  consider filling them in. 

  Figure 4.11: Application details.  The wizard’s next screen, which Figure 4.12 shows, provides a location to enter the full  path to the packaged application’s executable along with a working directory. This path  must be accessible by the user whose account will be used for deploying the OS image.  Ensure that appropriate permissions are applied to the share and NTFS permissions. Click  through the remaining screens to complete the wizard.   

 

62

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 4.12: Command details. 

Configuring the Application for Deployment  Two methods are available for adding the application to the OS deployment. It is possible to  select one or more applications during the deployment activity. This occurs while you  answer the questions inside the MDT task sequence. Every application that has been added  to the MDT server’s Application’s node will be available for installation in this screen.  You can see in Figure 4.13 that check boxes are available for installing the WinZip  application. Other applications that have been added to the MDT, such as Company App  ABC, are also available for installation in this wizard page. Select the check box next to the  applications to be installed, and continue through the wizard. Applications are installed in  the State Restore phase of the MDT task sequence. 

  Figure 4.13: Select one or more applications to install.  Applications needn’t necessarily be optional activities inside a task sequence. In fact, full  automation means not making these options inside the deployment. As with many  customizations inside the MDT, you can direct those actions right inside the MDT task  sequence. 

 

63

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Figure 4.14 shows the task sequence for the Windows 7 ENTERPRISE + Office image that  we’ve been working with in this chapter. In the State Restore phase, you can see the Install  Applications task. I have selected to Install a single application in this task, with the  application set to Nico Mak Computing WinZip 11. Notice how this is subtly different than  the alternative, which installs multiple applications based on decisions made inside the  deployment wizard. Installing additional applications happens by clicking Add | General |  Install Application in the task sequence. 

  Figure 4.14: Installing applications in a task sequence. 

 

64

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Note  Although not to the level of a dedicated application deployment solution, the  MDT’s granular management of applications is fairly rich. For example, you  can define collections of applications to be deployed together by creating an  application bundle.  You can also ensure that strings of applications that have dependencies on  each other—such as when a line‐of‐business application requires Microsoft  office—are installed in order. This is accomplished through the  Dependencies tab inside the properties of the application.  More detail about accomplishing these tasks is out of scope of this chapter,  but you can learn more by exploring the options under the Applications tab  to familiarize yourself with what capabilities the MDT provides. 

Thin Is Most Definitely In!  Chapters 3 and 4 have hopefully expanded your knowledge and your expectations in terms  of what an automated Windows 7 installation solution should look like. Such a solution  should absolutely be able to deploy Windows 7 images. But a smart solution—one that  really and truly augments the business process of IT—should also be able to layer in those  extra bits.  And yet applications aren’t the only thing that such a solution needs to handle. We haven’t  even gotten to the arguably more important scenarios surrounding the protection of user  data. The only way your Windows 7 upgrade project will be considered a success is if you  can protect that data and ensure it arrives back on users’ upgraded computers. Even the  smallest amount of missing data creates stress and negative attitudes that cause upgrade  projects to failure.  That’s why the next chapter is all about user data. You’ll find that the thin approach works  very well here. The MDT in combination with Microsoft User State Migration Tool (USMT— yet another acronym!) will enable you to layer user state data over the top of a deployed  OS.  You’ll also probably recognize that our shift from WDS to the MDT has removed a few of  the automations that we so carefully built in the previous three chapters. That’s OK. We  gain critical granularity in the process, but a holistic solution needs to include those  automations to be fully complete. Over the next few chapters, we’ll be adding those  automations back in. The final chapter will then be a wrap‐up, consolidating everything  into a final and fully‐workable solution. 

 

65

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Chapter 5: User Virtualization: Tools and  Techniques in Preserving User Data  We’re getting ever closer to that full solution for automating Windows 7 installation. To  this point, you’ve learned about the image deployment process. You’ve experienced how to  create your own universal images. You’ve even discovered how to layer applications into  those images, a process that converts an administratively‐challenging thick image into a  much‐cleaner thin image.  But, if you recall back in Chapter 3, the many layers of a complete Windows instance  (shown again in Figure 5.1) aren’t complete with just the applications. Layering over the  top of those applications are specific configuration changes and even user personality  information that you’ll need to incorporate for success. 

  Figure 5.1: Layering Windows OS deployment.  In short, if your users don’t find all their data on their new Windows 7 computer, they’re  not going to care about all its nifty new features. That data is to them more important than  any new operating system (OS). Without it, your Windows 7 deployment project will not  succeed. 

 

66

 

Automating Windows 7 Installation for Desktop and VDI Environments 

It’s for this reason that this chapter focuses on the all‐important facet of user data.  Interestingly, locating that user data, offloading it to temporary storage, then injecting it  back into an upgraded or replacement computer aren’t terribly easy activities. If you’ve  ever been responsible for manually locating a user’s data that’s strewn around their  computer, you know this pain. We’ve all sat in that seat at some point in our careers; I’d  prefer not to have to again.  That’s why automation of this user data preservation is important. You want an automated  solution that takes care of these steps for you. A highly‐successful tool will automate the  processes to such a degree that you’ll be able to abstract the user data from the individual  computer. That same tool will create a kind of virtualization of the data, removing the  direct ties between user data and specific machines.  I’ll be spending the majority of my time in this chapter talking about the tools inside the  Microsoft Deployment Toolkit (MDT) that can accomplish this task. The MDT 2010 Update  1 comes equipped with Microsoft’s (here comes another acronym!) USMT, or User State  Migration Toolkit. Although nowhere near a perfect solution, the USMT does a fairly good  job of collecting and later injecting the right data. It is also extensible. You can adjust its  behaviors should your users or their applications store data in other areas that aren’t part  of its default collection pass.  You should, however, be aware that the MDT and USMT combo only represents one  approach towards virtualizing user data. In fact, by default (as you’ll learn in the sidebar),  USMT does not capture everything. I’ll talk about other approaches towards the end of this  chapter that you might consider if your Windows 7 deployment requires more capabilities.  What Does the USMT Collect by Default?  The USMT indeed can’t know every file and registry setting for every  application in existence. It can, however, know what it needs to migrate for  most Microsoft applications and even many from third parties. It can also  make educated guesses about data that must be captured based on  commonly‐accepted coding practices. If your applications follow those  accepted practices, there’s a good chance that their data will get collected  right out of the box. For the rest, you’re going to need to customize USMT’s  behaviors.  Three files, found in the \USMT subfolder of your deployment share, are the  primary means for telling USMT what it needs to collect. Those three files are  MigUser.xml, MigApp.xml, and MigDocs.xml. As you can imagine, MigUser.xml  contains commands for migrating user folders, files, and file types;  MigApp.xml focuses on migrating application settings; and MigDocs.xml deals  with user folders and files throughout the system. 

 

67

Automating Windows 7 Installation for Desktop and VDI Environments 

   

Right out of the box, USMT will gather common user folders, such as My  Documents, My Video, My Music, My Pictures, Desktop files, Start menu  items, Quick Launch settings, and Favorites. It will gather information out of  specific user profiles as well as the All Users or Public profile (depending on  the OS). It will even gather user settings, such as Accessibility settings, EFS  files, Favorites, Fonts, ODBC settings, among others.  An extensive list of files to migrate is managed by file extension. Everything  from .CSV, to .DOC*, to TXT, and many others are captured right out of the  box. You can modify the MigUser.xml file to extend this list to other files that  your needs require, or you can create your own custom XML files that  augment the defaults. Microsoft provides extensive documentation regarding  the settings that are captured at http://technet.microsoft.com/en‐ us/library/dd560801(WS.10).aspx. 

Step Eleven: Preserving User Data  Let’s begin by exploring the options the MDT has available for your Windows 7 deployment  project. I’m going to guess that your project probably has three requirements. I’ll assume  that for the first, you want to implement an automated process to upgrade Windows XP  computers to Windows 7. As part of that upgrade, you want to save as much of the existing  user data that you can.  I’ll also assume that your second and third requirements are fairly similar. Both come into  play after the upgrade. For the second, you’ll need another automated process for  refreshing a Windows 7 computer with a new Windows 7 image. This process means you  can quickly bring a failed computer back to a known‐good state.  There is a third use case. Sometimes users want new computers, or you need to deploy  them new hardware. Thus, your third requirement will be a process to replace a user’s  computer hardware while keeping their user data.  We already have a completely‐functional image that we can use for all three of these  requirements. That image is the one called Windows 7 ENTERPRISE + Office, and it’s the  same image I’ve been using for the past few chapters. We’ll use that image for the examples  in this chapter as well.  Take a look at Figure 5.2 where I’ve again brought up the default Standard Client Task  Sequence. This is in fact the very same Task Sequence that we started using upon installing  the MDT. In Figure 5.2, you can see the Capture User State task highlighted. This task  invokes the ZTIUserState.wsf script during the relevant part of the installation. 

 

68

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 5.2: Capture User State.  What’s interesting about this script is that we’ve yet to see it get invoked, even though it is  a part of the sequence. That’s because, as configured in the default sequence, the Capture  User State task will not invoke when an installation is started via the boot‐from‐PXE  method we’ve used to this point. Instead, there’s a completely different method that you’ll  need to use if you want to invoke the script and gather user data during an upgrade. That  method I’ll talk about in the following section. 

Requirement One: Upgrading Windows XP to Windows 7  Consider the situation where you’re ready to upgrade a user’s computer. When that  happens, you’re probably going to be somewhere physically close to that computer. Maybe  you’ve brought it back to a central IT room where you’re performing the upgrade. Or  perhaps you’ve travelled to their desk to help them through it. For this and other reasons,  an image deployment that involves user data preservation starts not from a PXE boot but  instead from a running instance of the OS itself. In this case, that OS will be Windows XP. 

 

69

 

Automating Windows 7 Installation for Desktop and VDI Environments 

To kick off a deployment that preserves user data, don’t boot the machine to PXE. Instead,  run the command  \\{serverName}\deploymentshare$\scripts\LiteTouch.vbs 

from inside the running OS. This command is installed by the MDT installation to the  deployment share’s scripts folder. It launches a Windows Deployment Wizard screen  similar to what you see in Figure 5.3. You’ll notice that the same Windows 7 ENTERPRISE +  Office task sequence we’ve been working with is available for deployment. 

  Figure 5.3: Running the LiteTouch.vbs script on Windows XP.  After you click Next, the next page in the wizard (see Figure 5.4) is new as well. You’ll see in  this page that two options are available for deploying the image: Refresh this computer and  Upgrade this computer. You’ll also notice that only the Refresh this computer option can be  selected. Recall that there is no direct upgrade path from Windows XP to Windows 7. Thus,  you can’t kick off a traditional upgrade and get the new OS (although you could if the  original OS were Windows Vista). 

 

70

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 5.4: Choose a migration type.  That means that every Windows XP to Windows 7 upgrade is in fact a fresh installation. As  a fresh installation, you’ll need to ensure that you’re preserving the user data because it  will be formatted by the installation. Select the Refresh this computer option, and click Next  to advance to the next page.  The next three pages provide locations to change the computer name (if you wish), join the  computer to a domain or workgroup, and specify where to save data and settings. Figure  5.5 shows an example of this third screen. Of the two options that actually save user  settings, choose the first if you want to store the captured user data on the computer  during the refresh. Choose the second if you want it transferred to a file share somewhere  on your network. 

  Figure 5.5: Specify where to save data and settings. 

 

71

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Both options have merit. In the first, you’ll reduce the level of network traffic necessary to  complete the upgrade. In the second, you’ll create an off‐computer copy of the user’s  information should you experience a problem with the deployment. But, in doing so, you’ll  increase the amount of time required to deploy as well as the network consumption.  Your concerns about mid‐deployment issues are absolutely warranted. Sometimes OS  upgrades just don’t complete perfectly, and there’s nothing more heart‐wrenching than  having to look back at the user after a failure and say, “Oops.”  That’s why the very next page in this wizard provides the option to create a complete  computer backup prior to the deployment (see Figure 5.6). This complete computer backup  is intended to be used in an emergency should something go wrong. As with the previous  page, you can store that backup locally (if space permits) or send it to a remote location.  Remember that this full computer backup will be many orders of magnitude larger in size  than just the user data. So storing it somewhere else can have a big impact on storage as  well as network consumption. 

  Figure 5.6: Specify where to save a complete computer backup.  After the page that Figure 5.6 shows, you’ll see another series of wizard pages (not shown).  Those pages ask the same questions you’ve seen in other deployments so far: language,  time, currency, keyboard layout, time zone, and applications to install. The second‐to‐last  wizard page will ask for credentials used in connecting to network shares, followed by a  Ready to begin page. Click Begin to start the capture, deployment, and user data injection  process.  The script will capture the user state information to the location you identified in Figure  5.5. Figure 5.7 shows the installation progress bar that keeps you advised on the status.  When data collection is complete, the computer will reboot into WinPE, install the image,  and ultimately inject the collected user data from its storage location.   

72

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 5.7: Capturing user state.  You’ll know that everything has completed successfully if you see the final screen, which  looks like Figure 5.8. This screen shows that no errors or warnings were reported during  the installation. That’s a good thing. 

  Figure 5.8: Deployment summary.  Customization Resources  I mentioned earlier that you can customize the data the USMT will collect.  What I didn’t mention is that customization isn’t a trivial task and will  require sleuthing in terms of what data you actually want—files, registry  keys, and so on. Once you know what you want, you’ll need to encode that  information into the USMT’s XML files.  These tasks are not easy nor can I explain them in the space I have available.  Thus, the specifics of this aspect of customization are best left to Microsoft’s  Web site. Two URLs provide sample XML code you can borrow to modify  USMT’s configuration files. Information on including files and settings can be  found at http://technet.microsoft.com/en‐ us/library/dd560778(WS.10).aspx. Information on excluding files and  settings can be found at http://technet.microsoft.com/en‐ us/library/dd560762(WS.10).aspx. Both of these locations offer example  code to create a custom.xml file that works with the default MigApp.xml,  MigUser.xml, and MigDocs.xml files. The combination of these files will  control what data is preserved between OS installations.  Numerous third‐party solutions also exist that do a much slicker job of this  customization. It is in fact these customizations that present the strongest  case towards looking to third parties for better capabilities. 

 

73

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Requirement Two: Refreshing a Windows 7 Instance  With the information in the previous section, you have what you need to truly start  upgrading Windows XP and Vista machines to Windows 7. But that only finishes the  immediate project; what you really want is a Windows 7 deployment solution that  continues to benefit you over the long term.  That’s why your second requirement is refreshing an existing Windows 7 instance. In this  situation, a user’s computer does not need to be upgraded. Instead, their instance of  Windows 7 just needs a quick rebuild. In completing that rebuild, all the same applications  and user data must be injected back onto the computer after the rebuild completes. You  essentially want them to walk away and come back to a functioning computer.  You can use the same process to accomplish this that you did with the first requirement.  Again, instead of booting to PXE, kick off the  \\{serverName}\deploymentshare$\scripts\LiteTouch.vbs script inside the running  Windows 7 OS. As before, this script will ask you a series of questions that are similar to  those I discussed in the previous section. Once the questions are answered, the user data  capture will begin, followed by the image deployment, and concluding with the user data  injection. You’ll know you’ve done everything correctly when you see a Deployment  Summary screen similar to Figure 5.8. 

Requirement Three: Moving a User to New Computer Hardware  As you can imagine, the steps involved with the first two requirements are more or less the  same. Their only difference is their starting OS. In them, you’ll be kicking off the script from  within the running OS instance, answering its questions, and then allowing it to complete  the process—all on the same computer.  But there sometimes comes the need to move a user to a completely new set of computer  hardware. Perhaps your company is going through a hardware refresh, replacing older  hardware with new. Or maybe the user’s computer is experiencing problems and needs a  hardware replacement. In either of these cases, you don’t want to deploy another image to  the same hardware. Instead, you want to capture the user data and then inject it to a  completely different computer. Accomplishing this task requires two Task Sequences, one of  which you haven’t seen or created yet.  To begin, you’ll need to create that brand‐new task sequence. This time, you’ll be creating a  Standard Client Replace Task Sequence, as Figure 5.9 shows. This task sequence is  somewhat different from any that we’ve used so far because it does not actually deploy an  image to a computer. There also aren’t many settings to configure as part of this sequence.  I’ll name mine Windows 7 Replacement.   

 

74

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 5.9: Standard Client Replace Task Sequence.  Figure 5.10 shows the default tasks that are created as part of the default Standard Client  Replace Task Sequence. If you look very closely, you’ll notice that none of the typical image  deployment tasks are part of this sequence. In fact, the PreInstall and Install phases are  both essentially empty, containing only the Next Phase task. 

  Figure 5.10: Tasks in the Replace Task Sequence.  A replace task sequence is used to capture user data off an existing computer and send it to  a remote server for storage. Remember in Figure 5.5 where you were given the option for  storing user data either locally or remotely? In this sequence, you’ll be forced to store the  data remotely so that it can later be accessed by the new computer. 

 

75

 

Automating Windows 7 Installation for Desktop and VDI Environments 

As with the other steps, you will begin this process at a running instance of the OS. Also,  just like the other steps, the process begins by launching the  \\{serverName}\deploymentshare$\scripts\LiteTouch.vbs script. This time, however,  select the Windows 7 Replacement sequence you see in Figure 5.11. 

  Figure 5.11: Selecting a task sequence.  As I mentioned earlier, the only option available now (see Figure 5.12) is to specify a  location somewhere on the network. I’ve created a share called \\wdsserver\userdata, so  I’ll store mine in the gshields subfolder of this path. Obviously, make sure that you’re  setting your permissions appropriately so that the user whose credentials the installation  is using has appropriate access. A replacement sequence also gives you the ability to create  a complete computer backup, although that backup must be transferred to somewhere on  the network. I’ll skip that backup for now. Lastly, provide a set of credentials and the user  state capture will begin.   

 

76

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 5.12: Specify a location for user data.  Restoring this information to another computer happens in much the same way as the  steps in the second requirement. The only difference here will be the need to point the task  sequence back to the remote location for the user data. Be aware that the computer will  reboot back into WinPE for a very short time after the state capture is complete. 

Stepping Back: Real User Virtualization  You’re probably wondering at this point why this chapter’s title starts with the term User  Virtualization. That’s because this concept of layering user data and configuration  information on top of an OS represents a kind of virtualization. Remember that  virtualization at its most basic represents the abstraction of one layer of resources from  another. In server virtualization, you’re abstracting the server from its physical resources.  Application virtualization abstracts applications from their underlying OS. In this concept  of user virtualization, user data is abstracted from applications and OSs altogether.  I wrote about this concept of user virtualization in a recent book, The Shortcut Guide to User  Workspace Management, which you can download for free from  http://nexus.realtimepublishers.com/sguwm.php. In that guide, I talked about some of the  fantastic benefits one could get out of fully and completely abstracting the user’s  workspace from the rest of the OS. 

 

77

 

Automating Windows 7 Installation for Desktop and VDI Environments 

What’s important to recognize here is that the MDT doesn’t get you there fully and  completely. The MDT is more of a point solution that’s used for a specific problem. Smart  organizations recognize that virtualizing the user’s workspace presents very compelling  administrative benefits for ongoing operations—even after the upgrade or when users  don’t necessarily need new OSs.  Let me quote a section from Chapter 1 of that book, to tease you towards external solutions  that are always on and always managing user data. These always‐on solutions create user  virtualization by allowing users to seamlessly move across OSs, computer instances, and  even OS delivery infrastructures. The solutions are available today, and the future state  they present is something I think every IT professional would love to have in their own  data center. 

Encapsulation and Decoupling  With this understanding in mind, let’s assume that through the use of one or more  software products, it becomes possible to logically encapsulate these layers. This  process of encapsulation creates hard lines between the user workspace and the  applications and OS it customizes. It does the same thing between applications and  the OS, as well as between the OS and the hardware on which it rests.  Without this logical encapsulation in place, managing that computer is a very  difficult thing to do. Without some automated software deployment or application  virtualization solution, adding a new piece of software means I have to manually  touch each and every computer. Updating a piece of software requires a lengthy  uninstallation‐followed‐by‐reinstallation process. Lacking solutions like these,  working with OSs and applications in any form is both difficult and time consuming.  The same holds true at the user workspace layer as well. User data is natively stored  within a Windows user profile, with that profile containing all the customizations  that elevate a freshly‐installed Windows OS into something that’s personalized for  each user. Lacking logical encapsulation at this layer, moving that user data between  different computers becomes challenging to the point of absurdity. If you’ve ever  spent four hours trying to upgrade a single user’s computer from one OS to another,  you know this pain. 

The Benefits of Decoupling  Now, envision an environment where each of these layers has been fully  encapsulated. Such an environment would see a full decoupling of each layer from  the others. Here, for example, a hard line would exist between the user’s workspace  and their applications. The user’s workspace would be independent from the OS as  well as its hardware. 

 

78

 

Automating Windows 7 Installation for Desktop and VDI Environments 

In such an environment, that user’s workspace would immediately become fully  mobile. This becomes possible because that workspace is no longer directly reliant  on the layers below it. Because the decoupled workspace now exists in its own  independent and isolated layer, that layer can trivially move between different  computer instances. Such an environment would gain some very interesting benefits  to administration.  For example, consider the change that is represented in Figure 1.2. Here, the user  workspace has been decoupled from its OS and installed applications. With the  aforementioned encapsulation in place, it becomes possible to swap out the  underlying OS along with its applications. 

  Figure 1.2: Decoupling the user’s workspace enables it to work atop new  computer instances.  This process sounds vaguely similar to the manual steps I went through to locate the  user’s information, copy to an offline location, and merge it back with the upgraded  OS. However, different with a User Workspace Management solution is the logic that  fully automates these steps. 

User Virtualization Goes Beyond OS Deployment  It is my hope that you take two important points away from reading this chapter.  Obviously, the first point relates to the steps you can implement today to add user data  capture and injection into an MDT task sequence. If your needs relate solely to a Windows  upgrade, the MDT and the USMT can perform most of what you need.  For the rest of us, the second take‐away relates to the need for pervasive user virtualization  and/or user workspace management in our desktop environments. By elevating what we  know we can do through tools like the USMT into always‐on solutions, we can create a  future‐state where users get their settings at every desktop, at anytime, anywhere, no  matter what the delivery mechanism. That future state makes users very happy. It also  makes us very happy because it opens up the ability for IT to make underlying changes  without impacting users in the slightest. If you haven’t taken a look at the user  virtualization solutions out on the market, they’re a game changer for even small  environment needs. 

 

79

 

Automating Windows 7 Installation for Desktop and VDI Environments 

That said, this book still has a few topics to cover to round out the complete solution for  Windows 7 deployment. Next up is the recognition that many applications simply won’t  function atop Windows 7. Windows Vista and Windows 7 both enjoy a much more secure  kernel architecture that protect them from many of Windows XP’s nefarious attacks. At the  same time, that more‐secure architecture eliminates the functionality from many poorly‐ coded applications.  In the next chapter, I’ll show you Microsoft’s free tools for inventorying your environment.  I’ll also show you the tools Microsoft provides for helping you get through the application  compatibility part of this story. Lastly, I’ll show you smart ways that you can “punt” on  some applications so that those with conflict don’t need to delay your Windows 7 upgrade. 

 

80

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Chapter 6: Automating Application  Inventory and Overcoming Incompatibility  Step Eleven, covered in the previous chapter, really concludes the “deployment” activities  in Windows 7 deployment. By navigating through the first eleven steps, you know how to  create and deploy images. You’ve seen how to layer applications on top of those images  during deployment. You’ve also learned tricks you’ll need to preserve important user data  between old and new OS instances.  Congratulations! You’re ready to start deploying!  Or are you? If you’ve been around the IT industry for long, you know that every OS upgrade  is never as simple as it seems. Although deploying OSs is pretty easy, making sure  applications work with that OS often isn’t. Here’s a chilling statement: Many of your  applications that run just fine on Windows XP won’t automatically run on Windows 7. Yikes.  You should already know some of the reasons that this is the case. Windows Vista and  Windows 7 arrive with significant changes to their security model. These two OSs no longer  grant applications and drivers direct access to the OS’s most‐secure kernel code. The new  security model along with a host of other updates make Windows Vista and Windows 7  significantly more secure than Windows XP. Significantly.  Unfortunately, those changes also mean many older applications—those that abused  Windows XP’s overly‐open and inviting nature—aren’t going to work automatically. Some  will require configuration adjustments. Others will need software “shims.” Even others  won’t work at all.  Thankfully, Microsoft knows about the problem. To assist, they’ve created two tools (along  with accompanying acronyms) that inventory your network and apply known fixes that’ll  make many applications work again. The first of these tools is called the Microsoft  Assessment and Planning Toolkit (called the MAP). A simple tool, the MAP collects a list of  applications and drivers on your network. With its data, you can identify the applications  on your network and a list of drivers your computers will need. The second and more  powerful tool is the Microsoft Application Compatibility Toolkit (aka the ACT), which assists  in identifying and fixing incompatible applications. 

 

81

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Step Twelve: Inventorying Applications and Drivers on the Network  Step Twelve begins with the installation of the MAP. With it, I’ll show you how to gather a  report of the software that’s installed on computers around your network. With that  information in hand, I’ll point you to Microsoft’s Windows 7 Compatibility Center. This site  is an online clearinghouse of applications and their compatibility status. You can compare  the software in your report to those in the Compatibility Center to see which will work and  which won’t.  But that’s not all the MAP is good for. Remember back in Step Four (and again in Step  Eight) where I showed you how drivers can be automatically injected into images as they’re  deployed? Wouldn’t it be useful to know exactly which drivers your computers will need?  The MAP can also collect that information for you, if you know where to look. 

Installing the MAP and Collecting Inventory  Begin by downloading the MAP from Microsoft’s Web site and installing it to the WDS  server we’ve been using throughout this book. Using the MAP requires first installing a  copy of Microsoft Office 2007 SP2 as well as the .NET Framework. The MAP will  automatically install a copy of SQL Server Express to the computer as it begins its  installation. Once installed, you’ll be asked to create a new inventory database just like you  see in Figure 6.1. I’ve named my database MyInventory. 

  Figure 6.1: Creating a new MAP database.  Figure 6.2 shows what the MAP’s console will look like after installation. You should  immediately notice that the MAP has far more capabilities than simply searching your  network for installed software. Other assessments are available that help determine  Windows Server roles that have been installed on servers, where SQL server components  have been deployed, and even where virtual machines might be hiding on your network. 

 

82

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 6.2: The MAP console.  Inventorying the software in your environment starts by clicking the Inventory and  Assessment Wizard link you see in the right pane of Figure 6.2. Clicking this link brings  forward a wizard that you’ll use to configure the types of inventory to be collected.  Windows, Linux, VMware, Exchange Server, and SQL Server computers are all options for  inventorying. I’ll be using only the Windows‐based computers scenario in this chapter, as  this scenario provides the information I’ll need for a Windows 7 upgrade.  The wizard’s second page (seen in Figure 6.3) shows the multitude of methods the MAP  will use in discovering computers to inventory. My computers are all members of an Active  Directory (AD) domain, so I can select the first and second check boxes to find them. Other  computers not on the domain can be discovered via IP ranges, by entering in computer  names manually, or via a text file.   

 

83

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 6.3: Selecting methods to discover computers.  Subsequent wizard pages provide locations to enter AD credentials, to restrict inventory to  specific organizational units (OUs), and to add domains or workgroups if they are  discovered by the tool. The page titled All Computers Credentials allows you to enter in a  list of possible credentials the tool can use in attempting to inventory discovered  computers.  It is within the All Computers Credentials and Credentials Order pages where the MAP truly  shines. You can see in Figure 6.4 that I have entered credentials for two different domains:  COMPANY and SPECIALIZED. Additional workgroups or specific computer credentials can  be added as well. Doing so will give the inventory process plenty of username and  password options as it authenticates to discovered computers.   

 

84

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 6.4: Setting an order of credentials.  Click Finish to complete the wizard and begin the discovery and inventory process. Be  aware that this process can take a considerable quantity of time, particularly if your scope  is large. Version 5.0 of the MAP, the version used in this example, is reported to discover  and inventory as many as 100,000 computers. Gathering information from that quantity of  computers, as you can imagine, is going to take a while.  Note  The MAP’s inventory process uses WMI queries to gather its information.  Ensure that the Remote Administration firewall exception has been enabled  on any computers that will be queried by the MAP.  Figure 6.5 shows a report on the products the MAP found in my network. You can see that  the Adobe Reader 9.4.0 was discovered on two computers. A set of three Apple applications  was found on another two, as well as an entire list of software from all sorts of vendors.  This screen inside the report is relatively static, giving you little more than a view of the  software that the MAP has found inside your network.   

 

85

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 6.5: Product inventory results.  A much more useful representation of the data found by the MAP can be created by clicking  the Windows 7 Readiness link in Figure 6.5’s left pane. The resulting Windows 7 Readiness  summary provides high‐level information about the computers found in the discovery and  inventory process. You can learn in this screen how many computers have hardware that is  powerful enough to support Windows 7. You can also learn how many drivers your  computers will need and which of those drivers are included on the Windows 7 DVD.  Figure 6.6 shows a snippet of the summary screen. That screen tells me I’ll need to locate  manufacturer drivers for 61 of the 194 drivers my computers say they need. 

  Figure 6.6: Device compatibility summary. 

 

86

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Creating and Using MAP Reports  There’s a link (not shown) on the right pane of this Windows 7 Readiness Summary Results  page that’s labeled Generate Report/Proposal. Click that link to generate a report. Then  click View | Saved Reports and Proposals to bring forward an Explorer window. In this  window, you’ll find a Microsoft Word document that contains useful project planning  information about your Windows 7 readiness.  You’ll find even more useful information in the accompanying Excel spreadsheet. Inside  that spreadsheet is detailed information about each inventoried computer, its hardware  configuration, and any installed software and drivers.  Figure 6.7 shows one of the tabs in that spreadsheet. In it you can see that at least one  computer on my network reports it will need the Realtek High Definition Audio driver.  Happily, that driver is available on the Windows 7 DVD media, so I don’t need to worry  about it. Another computer reports it needs the Realtek PCIe GBE Family Controller, which  isn’t on the Windows 7 media. I’ll need to locate that driver from its manufacturer’s Web  site and add it to my Out‐of‐Box Drivers node in my MDT Deployment Share. 

  Figure 6.7: A MAP report’s Excel spreadsheet.  By reviewing the drivers inside this Excel spreadsheet, I now know which drivers I’ll need  to make available in MDT so that my images will deploy correctly. This report all by itself  gives me the data I need to ensure my deployment goes as smoothly as possible. 

 

87

 

Automating Windows 7 Installation for Desktop and VDI Environments 

A second tab on this Excel spreadsheet gives me a punch list for tracking down the  compatibility status of applications that are installed on my computers. That tab, labeled  Discovered Applications, lists each application, its version number, and the number of  instances found on the network during the last inventory pass.  I mentioned at the beginning of this step that Microsoft has created an online clearinghouse  of application compatibility status information. That clearinghouse is called the Windows 7  Compatibility Center. Navigate to  http://www.microsoft.com/windows/compatibility/windows‐7/en‐us/default.aspx to  check out its constantly‐updated list.  Figure 6.8 shows the results of going to the site and running a search on Adobe reader. I  already know from my MAP report that I have two copies of Adobe Acrobat 9.4.0 in my  network. Running this search tells me that Adobe Reader version 9 is compatible with  Windows 7. It also tells me that version 8 compatibility requires an action, specifically a  free upgrade. That’s useful information. 

  Figure 6.8: The Windows 7 Compatibility Center.  Combining the information provided by this Web site with the information in my MAP  report, I can quickly identify which applications will work and which won’t. For some, I  may learn that they’ll require a patch or some other special configuration to function. 

 

88

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Step Thirteen: Resolving Application Incompatibilities  I told you that two tools are necessary to fill out Windows 7’s application compatibility  story. The second of these two tools is the Application Compatibility Toolkit (ACT). While  the MAP is a simple tool that gathers a relatively simple set of information, the ACT is a  robust solution for locating and applying fixes to applications that otherwise won’t work.  That said, using the ACT isn’t nearly as simple as the MAP. You can’t just install it and  immediately run an inventory. Rather than using WMI to query computers for their  contents, the ACT gathers its information through the use of an agent. That agent allows the  ACT to gather a greater level of detail than MAP can get with its WMI approach. Although  great for data collection, this agent isn’t exactly trivial to install. It must be deployed and  launched through an external software delivery mechanism. That mechanism can be a  logon script, Group Policy Software Installation, or even System Center Configuration  Manager. You can even double‐click and invoke the agent manually on any computers you  want to inventory. Launching that agent through any of these means will gather the data on  the system and transfer it to a file share that you designate on your network. For Step  Thirteen, I’ll show you how to set up the ACT, gather information from agents, and use that  information to locate fixes for known‐incompatible applications.  Note  In the interest of space, I’ll assume that you know how the steps necessary to  automatically deploy a piece of software through one of the aforementioned  tools. Should you need assistance, consult Microsoft’s deployment guide with  the ACT that walks you through the process. 

Installing the ACT  Start by downloading the MAP from Microsoft’s Web site. In my case, I’ll be using the MAP  version 5.6. Install it to the server we’ve been using throughout this book, and launch its  Application Compatibility Manager to begin the initial configuration.  Note  If you’re using the ACT on the same server where you installed the MAP,  you’ll need to perform one step prior to launching the Application  Compatibility Manager. Navigate to C:\SQLEXPRESS and double‐click the  installation file you find. Doing so will launch the SQL Server setup wizard.  You’ll need to install an additional SQL Server instance for the ACT to use.  Click through the wizard screens and create a new named instance. In my  case, I’ll name that instance ACT. You’ll use that instance in the following  steps.  Three information pieces are required to initially configure the ACT (see Figure 6.9). You’ll  need a SQL Server database instance to store its information. You’ll also need a file share  with plenty of storage space, which will be used for collecting agent log files. Lastly, you’ll  need an account that is used for the ACT Log Processing Service.     

89

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 6.9: The ACT Configuration Wizard.  The ACT Configuration Wizard will step you through setting up these three pieces. This will  be your primary server for collecting and processing log files as well as viewing reports, so  you’ll want to use the ACT’s Enterprise configuration when prompted.  Configuring the ACT database requires a somewhat confusing wizard page (see Figure  6.10). Clicking the drop‐down box should provide a list of local SQL Server Express  instances (see the earlier note for an extra step if you’re using the same server where the  MAP is installed). Select the instance you want, and click Connect (not shown) to connect.  Then enter a database name, and click Create to create that database. I’ve named my  database MyActDatabase. 

  Figure 6.10: Configuring the ACT database.   

90

 

Automating Windows 7 Installation for Desktop and VDI Environments 

In a following screen, you’ll be asked for your share path and name. Be aware that the  Domain Computers group must be given write access to this location. The configuration  wizard’s final screen will ask for account credentials for the ACT Log Processing service.  You may select either Local System or a domain user account.  You’ll notice as the ACT launches that there’s not much to see at first. Figure 6.11 shows  ACT’s Collect view. It is in this view where Data Collection Packages are configured and  generated. Those packages are essentially a software installation in .MSI format that  installs silently. Inside the package is the necessary logic that will evaluate computers,  gather data, and report back application and compatibility information to the file share. 

  Figure 6.11: The ACT’s console. 

Creating a Data Collection Package  Creating a Data Collection Package begins by double‐clicking the white space inside the  ACT’s right pane. Doing so brings forward a wizard screen similar to what you see in Figure  6.12. Each package’s .MSI file can be installed by double‐clicking it on a candidate system or  by distributing it through a software delivery system. For this example, I’ll create a package  and simply double‐click it on my WDS server, \\wdsserver. 

 

91

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 6.12: Creating a Data Collection Package.  I’ve named this package Verify Windows 7 App Compat, as you can see in Figure 6.12. I’ve  also set the package to begin monitoring application usage as soon as possible after  installation. The package has a duration of 10 minutes and will output its data to the ACT’s  log location. When you click Advanced, you will see a secondary screen that allows you to  enable or disable any of the three compatibility evaluators: inventory collector, User  account control compatibility evaluator, or Windows compatibility evaluators.  Choose File | Save and Create Data Collection Package to complete this step and ready the  package for deployment. This process creates that .MSI file in the location you specify. Once  created, double‐click that .MSI file on any computer to begin collection, or deploy it through  your software deployment solution.  This ACT Thing Seems Hard  You might be asking why this process seems somewhat more complicated  than the MAP’s inventory process. Recall that although WMI can be remotely  queried over the network, it can only provide a limited set of data about  installed applications. Some applications may not be exposed properly or  completely within WMI. Thus, some of your applications simply won’t be in  the MAP’s list.  The ACT is intended to scale to thousands of computers. It is also designed to  collect and report on other data, with that reporting to occur over a  distributed amount of time to prevent abusing your file share. For all of these  reasons, Microsoft uses an installable “agent” to accomplish these tasks. In  the end, it is more work to get the data you need, but the data you’ll get will  be of much higher quality. 

 

92

 

Automating Windows 7 Installation for Desktop and VDI Environments 

After letting the agent run for 10 minutes or so, you should begin seeing data in the log  location’s \Processed folder. When you do, return to the ACT and take a look at its Analyze  view. Within the Analyze view, you’ll find information about the applications the agents  have found on your computers. 

Analyzing and Keeping Track of Results  Now, here’s where the exciting part happens. While in that view, click Send and Receive.  Clicking this button shares your application information with Microsoft, while at the same  time downloading Microsoft’s corresponding compatibility information. You’ll have an  opportunity to see what data is sent to Microsoft before sending (it isn’t much, but you’ll  want to confirm this sharing with your corporate security policies).  Once the synchronization is complete, the ACT’s report will update to include information  collected from the IT community about your applications. You can see in Figure 6.13 that  the community has rated most of the applications on my \\wdsserver computer fairly well,  with a slightly lesser rating for Microsoft Visual Studio .NET and the Microsoft SQL Server  Browser. You should know that although the software seen in Figure 6.13 is all Microsoft  software, this report will provide information on other software as well. 

  Figure 6.13: The Windows 7 Application Report after synchronizing.  You can safely assume that information gathered in this report is equivalent to what you  would be seeing on Microsoft’s Windows 7 Compatibility Center Web site. That’s a good  thing. What it means is that the ACT’s Application Compatibility Manager is a kind of  workflow management solution for keeping track of all your applications. As you click  through its settings, you’ll notice that you can set your own assessment of each application  as well as its deployment status, category, and priority. You can also document issues with  applications and corresponding solutions. Figure 6.14 shows an issue with the Office  Diagnostics Service conflicting with a custom application once upgraded to Windows 7.   

93

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 6.14: Documenting an issue with an application.  Note  The ACT is useful for more than verifying compatibility with Windows 7. It  can also be used for verifying compatibility with Microsoft updates prior to  deploying them with WSUS. 

Fixing Incompatible Applications  All of this setup merely gets you to the point where you can begin analyzing and tracking  your applications for incompatibility. ACT also provides a set of tools for actually fixing  incompatible applications. One tool that you’ll use in modifying applications to help them  run is the ACT’s Compatibility Administrator. Inside the Compatibility Administrator are  more than 6500 known applications along with their accompanying fixes.  Two versions of the Compatibility Administrator are available, one each for 32‐bit and 64‐ bit applications. In either, click the Applications node to expand the list of known  applications. As you’ll quickly find, fixes are available for many known applications, such as  the HP Web Jetadmin application that Figure 6.15 shows. There you can see that the  VistaRTMVersionLie fix can resolve an issue with the HPWJAUpdateService.exe file.   

 

94

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 6.15: Compatibility Administrator.  Although this information is useful if your applications are in the list, many applications  won’t be available. Any custom and uncommon applications your company uses aren’t  likely to be present.  For applications not in the list, you’ll need to test which compatibility fixes might resolve  the problem. Built into the ACT are more than 360 compatibility fixes (sometimes called  shims) that can be integrated into an application to return it to functionality. These fixes, a  list of which can be seen in Figure 6.16, resolve issues with User Account Control,  permissions, file virtualization and repathing, and numerous others.   

 

95

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 6.16: The ACT’s compatibility fixes.  What Fixes Do What?  With 360 possible compatibility fixes to choose from, how do you know  where to start? Good question, because the answer isn’t immediately  obvious. Check out the TechNet Web site at  http://technet.microsoft.com/en‐us/library/cc722305(WS.10).aspx. In this  location, you’ll find descriptions of each fix, along with symptoms that  suggest when the fix might be applied.  Even with the symptoms and fix descriptions on this Web site, finding the fix  that actually works will be a guess‐and‐check exercise. Problematic  applications will require substantial work to see which fix (if any) will work.  The ACT exists to create a singular database where discovered fixes can be  logged so that you can measure your progress over time and document your  findings.  To run tests against applications, you’ll want to install the Compatibility Administrator to a  reference computer that is running Windows 7. On that computer, install the application  and verify that it is incompatible. Take careful note of exactly how that application is failing  as well as error messages it gives or other notable behaviors.  To test a fix, create a Custom Database in the Compatibility Administrator on the Windows  7 computer. Right‐click that database, and create a new Application Fix. Doing so will  launch the Create new Application Fix wizard. 

 

96

 

Automating Windows 7 Installation for Desktop and VDI Environments 

In this wizard, you’ll be asked for information about the application, including its program  file location. You’ll also assign potential fixes to the application. Using this wizard enables  you to tag applications with potential fixes until you find the correct set that works. Figure  6.17 shows one of the wizard’s pages where compatibility fixes are tagged to an  application. You can click Test Run to test the execution of that application after fixes are  applied. The goal here is to verify whether assigned fixes indeed resolve an incompatibility. 

  Figure 6.17: Tagging a compatibility fix to an application.  Note  One easy starting point is to try setting the Compatibility Mode for the  application to Windows XP. This Compatibility Mode automatically adds a  series of adjustments to the application’s execution space that may quickly  solve the incompatibility. If an adjustment to the Compatibility Mode does  not resolve the problem, trying out specific fixes should be your next step.  After configuring the fix, save it to a location on the computer. The file will have an .SDB  extension. Then right‐click the custom database and choose Install to install the fix. Once  installed, try re‐launching the application to see whether the incompatibility is resolved. If  not, iterate through the previous steps until you locate the set of fixes that work with your  application. Make sure to right‐click the custom database, and choose Uninstall to remove  the fix before adding a new fix. 

 

97

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Once you’ve discovered the correct set of fixes your application needs, you’ll want to  deploy those fixes along with the deployment of your application. That deployment will be  different based on how you deploy applications. You can do so by including the  compatibility fix database in your deployed image, distributing it via a software  distribution system, or including it in a logon script by calling the sdbinst.exe file. Each of  these options is explained in greater detail in the Microsoft TechNet article at  http://technet.microsoft.com/en‐us/library/cc794691(WS.10).aspx. 

Solving Incompatibility: Not Hard but Time‐Consuming  Reading through this chapter, you’re probably thinking to yourself, “This seems like a lot of  work.” In all honesty, it is. Not all applications work well atop Windows 7, although that  number is growing every day as vendors realize the need to update their code. There will  always, however, be a set of applications that will never run just right. For those, tools like  the MAP and particularly the ACT give you a mechanism to track down and potentially  resolve their incompatibilities. Getting those fixes just right will take a bit of effort.  In just thirteen steps, you’ve been introduced to nearly all the pieces you need to be  successful with your Windows 7 deployment. You can now deploy images with the  assurance that user data and now applications will run successfully atop the new OS.  What you’re likely still looking for is a way to pull all these steps together into a cohesive  solution. You’re nearly there. If you’ve been following along as we’ve been building this  solution together, you’ve already got most of the pieces connected that you need to fully  automate the solution. Taking that last step and completing the solution is the topic for the  next chapter.   

 

98

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Chapter 7: Creating a Complete Solution  for Automating Windows 7 Installation  You should by now recognize this book’s pattern of introducing new technologies and  approaches into the Windows deployment story. That story involves plenty of layers, each  of which builds on the infrastructure of the layer below. It started in Chapter 1 with the  very basics of deploying images—and weren’t those basics, indeed! The images back then  weren’t even customized. They were little more than the default configuration you get by  Next, Next, Finishing your way through a manual installation.  The next chapters then led you through greater customization and introduced additional  automations. By now, you’ve learned how to create single images that deploy everywhere.  You’ve automated the installation of drivers, applications, and user state information.  You’ve also discovered the MDT, and how its Task Sequences are the glue that ties your  automations together.  Throughout this book, I’ve shown you how Microsoft’s free solutions can accomplish  necessary deployment tasks. Those free tools get you pretty far. Using them, you can kick  off a relatively‐automated Windows installation with little effort and good results.  Yet even with substantial automation in place, there’s always an underlying desire to fully  automate everything. A complete solution for automating Windows 7 installation should  take you out of the picture entirely. That solution should be able to upgrade or refresh  computers without needing to touch them at all. This topic, the zero‐touch approach, is the  final layer that creates your complete solution. Just like each of the previous chapters,  getting there requires leaning on the infrastructure you’ve built up to this point.  There is, however, one downside: Taking that final step requires a new piece of software  that isn’t free. Getting to the complete solution, at least with today’s options, requires  assistance from Microsoft’s System Center Configuration Manager (or ConfigMgr for short).  ConfigMgr isn’t free, but it is valuable in ways that go beyond desktop deployment. If this  book’s exploration of automations for Windows installation excites you, then ConfigMgr’s  many automations for Windows management will excite you even more. It’s a fantastic  administrative tool with a long history, bringing much to the table in addition to OS  deployment. 

 

99

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Before it can deploy operating systems (OSs), ConfigMgr must be installed. Its agents must  also be distributed to your desktops. Doing so requires an exercise in design work and  more than a few initial configurations. Those initial steps by themselves are a big topic. So  in the interests of space, this chapter will assume you’ve already completed the setup  activities. If you need assistance, numerous books and guides exist that’ll get you started.  As I begin this chapter, I’ll assume you’ve already completed the installation of ConfigMgr  and have deployed its agents to the computers on your network.  Resource  ConfigMgr’s initial installation and agent deployment can be exceedingly  complex activities. If you’re looking for a little help, Alberto Ortega has  written an excellent blog post that I use when building new ConfigMgr  servers on Windows Server 2008 R2. Found at  http://blogs.southworks.net/aortega/2009/09/16/deploy‐sccm‐2007‐sp2‐ rc‐on‐windows‐server‐2008‐r2/, this post does an excellent job of  documenting the exact steps that will complete ConfigMgr’s initial  installation and agent distribution. 

Stepping Back: Understanding LTI, ZTI, and UDI  Before we get started, let’s spend a minute understanding why ConfigMgr is necessary for  full automation. In short, it’s the ConfigMgr agent that’s needed. Microsoft’s acronym‐filled  MDT documentation refers to three deployment approaches. These they refer to as LTI,  ZTI, and UDI. These three acronyms reference Microsoft’s Light­Touch Installation, Zero­ Touch Installation, and User­Driven Installation approaches.  MDT alone supports only the LTI approach. That’s because the “Light” in Light‐Touch  Installation refers to the fact that some of its activities must be accomplished at the desktop.  You’ve seen this in previous chapters where someone at the desktop is needed to launch a  PXE boot or run the LiteTouch.vbs script.  But this chapter’s goal is full automation. Getting there means not having to physically be  present at any desktop for an installation. That said, even if it’s not you in person, kicking  off that installation requires something to exist at the desktop. That’s why ConfigMgr, and  specifically its agent, is a requirement. The ConfigMgr agent is that something at the  desktop. Being installed there, the agent is perfectly positioned to facilitate an OS upgrade  or refresh, resulting in a ZTI.  Note  Although I won’t be discussing it in this chapter, ConfigMgr is similarly well‐ positioned to handle the extra steps necessary for users to initiate their own  deployment. This approach represents Microsoft’s UDI, and is an added  capability you can layer on top of what you learn in this chapter. 

 

100

 

Automating Windows 7 Installation for Desktop and VDI Environments 

For the ZTI installation approach to work, that ConfigMgr agent must be present at every  desktop. As you can imagine, this means that you won’t be using ZTI for fresh installs. A  fresh install starts with an empty hard drive, which means no ConfigMgr agent is present  on the machine. Thus, this chapter will focus on the processes used to upgrade an existing  machine (one that already contains an agent) as well as refreshing one with a clean OS. 

Step Fourteen: ZTI with ConfigMgr  As I mentioned, getting to complete automation with Microsoft’s tools requires the  assistance of a ConfigMgr agent. Among its other tasks, this agent must be present to  receive the signal from the ConfigMgr server that an installation package has been  advertised and is ready for distribution.  I’ve built my ConfigMgr server on a new computer named \\sccm. Although I’m using a  different computer here for ConfigMgr, be aware that there are no technical limitations that  prevent you from collocating ConfigMgr with WDS and MDT. If you do intend these services  to coexist, make sure to use the full version of SQL Server and not SQL Server Express for  all your deployment services. That’s because ConfigMgr requires a full version of SQL  Server to function.  Upon completing the initial installation of ConfigMgr, my server shows a set of systems  with installed and functioning agents. I know this because the Client column in Figure 7.1  shows Yes for each of the computers shown. 

  Figure 7.1: Three computers, each with a ConfigMgr agent.  A few configurations must be set before you start deploying OSs. These configurations go  above and beyond the typical ConfigMgr installation. They integrate ConfigMgr with your  existing MDT infrastructure. They add a State Migration Point, which will be used in storing  user state information during upgrades. Finally, they create a folder and file share  ConfigMgr will use to store package information. 

Integrating ConfigMgr with MDT  First up is integrating your ConfigMgr console with MDT. Start by installing the ConfigMgr  console to your MDT server. The console is available on the ConfigMgr media by clicking  the Install Configuration Manager 2007 SP2 link. Once launched, choose to Install or  upgrade an administrator console.   

101

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Without launching the console after its installation, select the Configure ConfigMgr  Integration link under Microsoft Deployment Toolkit in the Start menu. You’ll be prompted  for a Site server name and Site code. These will correspond to your ConfigMgr site and site  server. Now you can launch the ConfigMgr console, and right‐click Computer Management |  Operating System Deployment | Task Sequences. If you see a selection titled Create  Microsoft Deployment Task Sequence, you’ve got a successful integration. 

Adding the State Migration Point  Your next task is to add the State Migration Point role to the ConfigMgr server. Navigate to  Site Management |  | Site Settings | Site System, then right‐click the link for your  ConfigMgr server, and choose New Roles. You’ll be greeted with a screen that’s similar to  Figure 7.2. 

  Figure 7.2: New Site Role Wizard.  This first role assignment is to the ConfigMgr server itself, so you need only click Next to  continue. At the next screen (not shown) choose to add the State migration point role, and  click Next. The screen that follows (see Figure 7.3) sets the location for storing user state  information as well as settings for the deletion policy and whether to enable restore‐only  mode. Click the upper‐right yellow star, and enter a folder path to your storage location. As  you can see in Figure 7.3, I’ve chosen C:\ConfigMgrUserState as my path, and limited the  number of clients and minimum free space. Click through the wizard’s remaining pages to  finish the installation. 

 

102

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.3: Configuring the state migration point. 

Creating an OS Deployment Share  The next preparation step is easy. OS deployment with ConfigMgr requires a folder and  associated share to store package information. On my server, I created a folder called  C:\OSDPackages and shared it as \\sccm\OSDPackages with appropriate permissions. Do  the same on your server, as you’ll be adding data to subfolders of that share in a moment. 

Creating a Deployment Task Sequence in ConfigMgr  Most IT professionals don’t realize that WDS and MDT aren’t even necessary to deploy OSs  with ConfigMgr. That said, there’s a reason this book delays ConfigMgr until its second‐to‐ last chapter: Getting here requires understanding the underlying infrastructure first. You’ve  developed that understanding through the previous chapters. You now know how WinPE  functions. You’ve also created at least one image that can be deployed. You’ve gathered a  list of drivers and applications that need installation with the deployment, and you’re  familiar with the complexities of user state migration.  By first knowing each of these tasks, your efforts in working with ConfigMgr are eased  because ConfigMgr itself is a complex application. It needs to be, in part because of how it  can scale from just a few computers to tens of thousands. Having built your MDT and other  infrastructures before now enables you to leverage that experience within ConfigMgr. In  fact, thanks to the MDT‐to‐ConfigMgr integration you just completed, the Create Microsoft  Deployment Task Sequence menu item is about to become your best friend. 

 

103

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Right‐click Task Sequences in ConfigMgr, and select Create Microsoft Deployment Task  Sequence. What appears is a lengthy wizard that requires numerous settings to complete.  The first time you run this wizard, you’ll be creating many of the items it asks for in its  pages. You’ll be able to reuse many of those items during subsequent uses of the wizard.  You can consider the Client Task Sequence template (see Figure 7.4) to be the core  template for many ZTI deployments. This template will scan for applications and user state,  offload user state information, rebuild the computer, reinstall applications, and ultimately  replace user state information onto the upgraded or refreshed computer. Select this  template in this screen. 

  Figure 7.4: Choosing a template.  In the next screen, (not shown) enter a Task Sequence name and any comments. Then fill  out the Details page with information about your domain and Windows settings (see Figure  7.5). If your organization uses volume license keys for desktops, you can enter that license  key into the provided blank. 

 

104

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.5: Providing template details.  Figure 7.6 defines how the Task Sequence might be used. A ConfigMgr Task Sequence can  be used for deploying images or deploying and subsequently capturing an image. We  already have an image to use that was captured back in an earlier chapter, so we won’t  need to use this image for a later capture. Thus, configure the screen as you see it in Figure  7.6. 

  Figure 7.6: Specifying template capture settings. 

 

105

 

Automating Windows 7 Installation for Desktop and VDI Environments 

You’ll find Microsoft’s wizard verbiage to get a little confusing in the next series of screens.  The first is seen in Figure 7.7 where the wizard asks for a boot image. Know that the boot  image used by ConfigMgr is slightly different than the one used by WDS and MDT during  previous examples. 

  Figure 7.7: Specifying a boot image.  This alternate boot image is configured with extra code that facilitates its integration with  ConfigMgr. Thus, you won’t be using the same boot image you used in previous chapters.  Here, select the Specify an existing boot image package option, and click Browse. Two  ConfigMgr boot images should be automatically available, one each for x86 and x64. In this  example, I’ll use the x86 boot image.  Another point of confusion with this wizard is in its next screen (see Figure 7.8) where  MDT files package information is required. This package is a collection of scripts and other  data from the MDT that is used by ConfigMgr for deploying an OS. This is a new ConfigMgr  instance as well as the first execution of the Microsoft Deployment Task Sequence, so the  MDT files package does not exist. Thus, it must be created. To do so, select the second radio  button and provide a UNC path to a subfolder of your choice within the OS deployment  package share created earlier in this chapter. For my environment, I’ll use  \\sccm\OSDPackages\MDTFiles. 

 

106

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.8: Providing an MDT package.  This location will be populated with information from MDT after the wizard is complete  and the Task Sequence is generated. In later Task Sequences, you may simply reference an  existing ConfigMgr package through the top radio button.  In the following screen (not shown) you will be asked for name, version, language,  manufacturer, and comment information for the package that will eventually be created  that includes this data. A name is required at minimum; however, the other information  will be useful down the road for identifying the characteristics of this package. In my  environment I’ll name the package MDTFiles.  One of the biggest benefits of layering ConfigMgr atop an existing MDT instance is that  you’ve already built the OS image you intend to deploy. You’ll see multiple options in Figure  7.9 for creating or specifying the OS image to be deployed. Choosing the first option will  select an image that has already been converted into a ConfigMgr package.   

 

107

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.9: Specifying an OS image.  You haven’t created that package yet, so choose to Create a new OS image. In doing so, enter  the path to the image’s WIM file that you created in a previous chapter. You’ll see in Figure  7.10 that I have selected Windows7_Office.wim, which is the WIM file created earlier that  currently resides on the WDS server. I’m also providing a path to new subfolder of the  ConfigMgr OS deployment package share. Doing this copies the WIM file to the new location  once the wizard is complete. It at the same time reconfigures the WIM file into a ConfigMgr  package for deployment.  In the next screen (not shown), you’ll be asked for name, version, and comment  information. As with the MDT package, enter as much detail as possible in these blanks to  assist with later identification.  Note  During later uses of this tool, you can select to Specify an existing OS image  instead. This will direct you to the list of packages currently installed on the  ConfigMgr server.  In order for ConfigMgr to manage the client after deployment, it will need to add a  ConfigMgr agent to the image as the OS is deployed. That ConfigMgr agent is part of its own  package. (Notice how everything that is to be deployed in ConfigMgr must be encapsulated  into a ConfigMgr package?) As this is a fresh installation of ConfigMgr, that Client Package  does not yet exist.  If yours does, you may choose the top radio button option in Figure 7.10, click Browse, and  locate the Client Package you’ve already created. If yours does not, select the second radio  button, and click Next to continue. 

 

108

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.10: Determining which client package to use.  As with the other packages so far, a USMT package must also be created. This USMT  package collects the USMT code from the location in the upper path box and copies it to the  path in the lower box (see Figure 7.11). The upper path should be automatically filled in for  you as this location is supplied from the WAIK. As with the other packages, the lower path  will be a subfolder of your choice within the OS deployment package share. The screen that  follows (not shown) will ask for the usual package characteristics: name, version, language,  manufacturer, and comments.   

 

109

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.11: Specifying a USMT package.  One final package is required for Task Sequences that deploy Windows 7 computers. This  package, called the Settings Package, includes a set of configurable settings that define how  the OS is deployed as well as the behavior of the installation. Choose at this time to create a  new one, as one has not yet been created (see Figure 7.12). Give it a subfolder path to your  OS deployment share, and (not shown) provide name, version, language, manufacturer, and  comment information. 

  Figure 7.12: Creating a settings package.   

110

 

Automating Windows 7 Installation for Desktop and VDI Environments 

You may click through the remaining screens, choosing the defaults to complete the  Microsoft Deployment Task Sequence creation. Notice that no Sysprep package is required  because this Task Sequence deploys Windows 7, an OS that natively includes the needed  Sysprep code.  Once you’ve completed the wizard, the process to create the Task Sequence will take a  period of time. This process transfers a large quantity of data from various locations to  your OS deployment share.  Note  Once the creation is complete, spend a minute reviewing the contents of the  OS deployment share. You’ll find that a number of subfolders have been  created, with some containing information that will be used during the  installation.  This data collection is stored in file format so that it can be modified or  otherwise customized to change the behaviors of the installation or the OS  that is delivered. Although this topic is out of scope for this chapter, know  that you can edit any of the configurations found in this share to modify the  behavior of the installation. As you’ll discover later, any changes here must  be uploaded to a distribution point to be used. 

Importing Drivers  ConfigMgr handles driver injection using the same plug‐and‐play approach seen with WDS  and MDT. Thus, the driver store you created during the previous chapters can be  automatically imported into ConfigMgr. Do this now by right‐clicking the Drivers node, and  choosing Import.  If you’ve been following along throughout this guide, you probably have a folder of drivers  on your WDS server in a subfolder of the C:\RemoteInstall folder. Mine is  at\\wdsserver\REMINST\Stores\Drivers. You can see in Figure 7.13 that the wizard can  interrogate drivers within a stated path and its subfolders to automatically import those  drivers into ConfigMgr. 

 

111

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.13: Importing drivers.  Once imported, drivers can be added (not shown) to categories for filtering. This prevents  similar‐looking drivers from accidentally being installed onto incorrect equipment. It also  prevents drivers from one OS from being inadvertently added to another, which can cause  conflicts. Be particularly careful with your drivers, as driver mismatches will cause  problems with OS deployment.  Note  In fact, a driver problem that warrants additional attention is caused by  drivers used for networking. The WinPE instance used by ConfigMgr requires  a functioning network driver so that its installation can communicate with  the ConfigMgr server to download images.  If you are following along using VMware Workstation, you may have  difficulties with the VMXNET driver used by some versions of VMware  Workstation. One workaround is to alter the driver used by your Windows  XP desktops by adding the line ethernet0.virtualDev = "e1000" to your VM’s  VMX file. This line forces the virtual machine to use the more‐common Intel  e1000 NIC driver, which must be subsequently downloaded from the  Internet and installed to the Windows XP desktop.  Drivers must be added to at least one driver package and distributed to distribution points  before they can be used by computers during deployment. Figure 7.14 shows how the set of  drivers specified in Figure 7.13 have been gathered into a package and sent to the  ConfigMgr distribution points. 

 

112

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.14: Adding drivers to packages.  The next screen (not shown) provides a location to add drivers to boot images. If candidate  desktops require non‐native drivers to boot properly into WinPE, make sure to add them to  the correct boot image or the boot and/or deployment process will fail. Click through to  finish the wizard. 

Updating Distribution Points  At this point, you have the data you need to begin your first deployment. The next step is to  add each of the newly‐created packages to a ConfigMgr distribution point. This distribution  point is different than the file share in which you’ve been storing data up until now. It is the  location agents will query for package data.  Separating your working file share from the “production” distribution point allows you to  work with the data in your file share, only updating it to the distribution point when it is  ready for deployment. Distribution points are not updated through any of the previous  wizards. You’ll need to manage them separately. The process to accomplish this task is the  same for all packages. I’ll show you how to complete this step with one package, then point  you towards the series of packages that require attention.  Start by clicking the Packages node. Right‐click any of the recently‐created packages in the  middle pane, and choose Manage Distribution Points. Click Next, then choose to Copy the  package to new distribution points. Figure 7.15 shows an example of the distribution  points where package data can be uploaded. Select one, and click Next to update that  distribution point with the new software.   

 

113

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.15: Selecting distribution points.  Note  Remember that you can at any point alter the data that is stored within your  OS deployment share; however, when you do make changes to that data, the  distribution point must always be updated with a new copy of the data. This  can be done by selecting the package, and choosing to Update distribution  points.  At this point, you can copy the remaining packages to the distribution point. This will be  the MDT Files package, Settings package, USMT package, Microsoft Configuration Manager  Client Upgrade package, Boot image package, Driver package, and the Windows7_Office  Operating System Image package.  Note  Some of these packages are not found under the Packages node. They will be  found elsewhere in the Computer Management hierarchy.  One caution is important as you update distribution points with new data. Be aware that  the process to copy packages to distribution points takes time. Although smaller packages  will be updated almost immediately, larger packages such as your OS images will take  much longer. You should not begin advertising packages until they have completed their  installation to distribution points. 

 

114

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Figure 7.16 shows how to verify installation status by navigating to System Status | Package  Status. Notice here that the Windows7_Office 1.0 en‐US package has been targeted to one  distribution point but has not completed its installation there. This Package Status view  will help you ensure that ConfigMgr has completed its transfer of data to the distribution  points prior to creating an advertisement. 

  Figure 7.16: Package status. 

Viewing the Task Sequence and Creating the OS Deployment Advertisement  You’re nearly ready for deployment. Prior to creating the advertisement that announces  the availability of the OS upgrade, you might want to review the Task Sequence created in  the earlier step. Navigate to Task Sequences, right‐click, and choose to Edit the Task  Sequence you just created.  You’ll immediately see the incredible number of steps that are automatically generated as  part of the Task Sequence. One of those steps, the Apply Operating System Image step, is  shown in Figure 7.17. In this step, the captured image is selected to be deployed as part of  the Task Sequence. 

 

115

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.17: Task Sequence.  You can at this point adjust any of the characteristics of this Task Sequence as well as add  steps by clicking the upper‐left Add button. By default, this Task Sequence will  automatically install the selected image to a targeted computer after gathering user state  information. It will restore that user state information to the new computer once the  installation is complete. Considering the very large number of steps and possible outcomes  that exist in this sequence, I’ll leave the exploration to you for how you will customize your  Task Sequences.  Note  Remember that ConfigMgr is an application installation solution in addition  to its job in deploying OSs. Thus, it can install applications on top of managed  systems once those applications have been packaged. That packaging process  is similar to what was discussed in Chapter 3.  You’ll notice that there is a step titled Install Software, which is one  mechanism that can be used to install packaged software during an OS  deployment.  You’re now ready to deploy an OS. Start that process by right‐clicking the Task Sequence,  and choosing Advertise. Doing so will bring forward the New Advertisement Wizard,  similar to Figure 7.18. In this wizard you’ll schedule the Task Sequence you want to deploy  and connect it to a collection of computers that will be upgraded.  That collection of computers is seen in Figure 7.18. The actual process to create and  populate collections is out of scope for this chapter; however, notice that I have created a  collection called XPtoW7 Computer that contains only my test computer.   

116

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.18: New Advertisement Wizard.  All advertisements run on a schedule. Notice in Figure 7.19 that the advertisement has a  start time but is also configured with a mandatory assignment to begin as soon as possible.  In ConfigMgr parlance, “as soon as possible” can sometimes involve a large amount of time,  so be prepared for a short delay even after the advertisement is created. 

  Figure 7.19: Scheduling the advertisement. 

 

117

 

Automating Windows 7 Installation for Desktop and VDI Environments 

This is a test environment, so you will also want to select the Ignore maintenance windows  when running program and Allow system restart outside maintenance windows check boxes.  Lastly, because you may rerun this package later, consider setting the Program rerun  behavior to Always rerun program. Click Next to continue.  Next up is the Distribution Points page (see Figure 7.20) with only a few settings. Set the  bottom radio button to instruct the client to gather its data directly from a distribution  point rather than downloading the content. An OS deployment will wipe a system disk; this  setting prevents the situation where downloaded data is deleted by the Task Sequence. You  may also select the two bottom check boxes to ensure that any available distribution point  is used. 

  Figure 7.20: Specifying distribution point settings.  The next five screens of the New Advertisement Wizard are not shown, as most  deployments use their defaults. Continue through the wizard to create the advertisement.  If you’ve done everything correctly, a balloon notice will appear on desktops after a few  minutes (but sometimes as much as an hour later) after the advertisement is created.  Clicking that balloon notice will bring forward the Program Countdown Status message  that Figure 7.21 shows. This notice alerts the users that their computers are about to be  upgraded, and provides a 5‐minute countdown timer prior to beginning the OS  deployment. 

 

118

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.21: The Program Countdown Status balloon.  As with the MDT, a set of pre‐installation activities must occur on the client before it boots  into WinPE for the actual OS installation. Figure 7.22 shows the Installation Progress bar  that shows which steps in the Task Sequence are in progress. 

  Figure 7.22: The Installation Progress bar.  Once the pre‐installation activities are complete, the computer will reboot directly into  WinPE to begin the installation. ConfigMgr uses a different background screen to denote its  version of WinPE. You can see an example of that screen in Figure 7.23. If you’ve done  everything correctly, the OS will install and eventually return control back to the user with  the new OS. Viola! You’ve completed your first zero‐touch deployment of an OS! 

 

119

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 7.23: The WinPE Phase. 

Stepping Back: What Haven’t You Seen? What’s Left?  Getting this far with the zero‐touch deployment approach is an accomplishment all by  itself. The multitude of components required to get this far requires no small effort in  designing and integrating a range of technologies. Congratulations!  In fact, this simple example is only a small portion of what ConfigMgr brings to the table in  terms of OS deployment. This walk‐through represents barely the simplest of installation  use cases, and it is written to get you started down the path of even greater automation.  Once you understand the basics, you become well‐prepared for adding to that knowledge  with additional automations, many of which you only gain through your ConfigMgr  infrastructure.  ConfigMgr itself comes equipped with a significantly‐greater level of intelligence about the  software that is deployed and managed in your environment. However, most of its  functionality works best only when your IT processes subscribe to using it for pretty much  everything. That means coordinating the packaging efforts of your deployed software,  updates, OSs, and even desired configurations. By centralizing all facets of Windows  configuration control within a ConfigMgr infrastructure, you gain a configuration  management database that becomes useful for even greater levels of automation. 

 

120

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Consider additional capabilities that might come through centralizing control in this  manner. For example, software installation can be slipstreamed into OS deployments. As  ConfigMgr is as much a software installation solution as an OS deployment solution, it  stands to reason that any software package created for installation can be automatically  added to an image as well. Adding a bit of extra intelligence to your Task Sequences, it  becomes possible for your deployment sequences to query computers for installed  application packages with the goal of automatically reinstalling those packages after an  upgrade.  ConfigMgr also includes support for PXE booting desktops for image deployment, similar to  how WDS and MDT use the same technology. ConfigMgr includes a PXE service point role  that can handle deployment of WinPE to PXE clients for a streamlined LTI experience.  A third deployment approach is also possible with ConfigMgr that transfers control to users  entirely. The UDI approach gives individual users the ability to refresh their computers on  their own and without IT involvement. With instrumentation for reinstalling appropriate  applications and migrating user data, the UDI approach enables users to fix their own  problems without requiring intervention by IT. 

The Automations Virtually Never Stop  This chapter has intended to serve as the capstone for this book’s discovery on automating  Windows deployment. However, the conversation isn’t done. The title of this book asserts  that it is a definitive guide for desktop and VDI environments, but we haven’t gotten to the  virtual world just yet—I purposely decided to hold on that discussion, giving you the  opportunity first to understand fully the Windows deployment process. With that  information firmly in hand, this book’s final chapter concludes with a look at how this  information can be directly translated into the desktop virtualization world. In the next  chapter, I’ll show you how the information you’ve learned so far will bring a significant  assist should you take the road of virtualizing your desktops.  You’ll be happy you’ve stuck around this long. The information in the last chapter is not to  be missed. 

 

121

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Chapter 8: Integrating Automated  Windows 7 Installation into VDI  Environments  When is a desktop not really a desktop? When it’s a virtual desktop, of course!  From the user’s perspective, a virtual instance of Windows 7 might look the same as a  physical instance. But you’re an IT professional. You’re aware of all the extra forces  working behind the scenes that are required to make that virtual instance happen.  Virtualization, presentation, transport protocols, automated deployment, and snapshotting  all comprise the virtual desktop administrator’s toolkit for deploying even the most basic  Windows 7 instance.  Complicating this process even more is the multitude of desktop virtualization solutions on  the market today. VMware View, Citrix XenDesktop, and Microsoft Remote Desktop  Virtualization Host represent three of the major players. They’re not the only ones.  “Smaller” alternatives like Quest, Wanova, MokaFive, NComputing, and others now release  their own solutions that create a Virtual Desktop Infrastructure or VDI.  When it comes to Windows 7 itself, however, there is good news. What you’ve learned so  far in this guide directly assists in creating virtual machines inside a VDI infrastructure,  notwithstanding which vendor writes the software. No matter whose technology connects  your users to VMs, the processes you now know for configuring Windows remain relatively  the same. That knowledge makes my life easier as this book’s author. It also makes your life  easier if you’ve been following along throughout its pages.  That’s why this chapter won’t delve too deeply into the specifics behind each VDI platform.  The exact clicks required to build a desktop template in Citrix XenDesktop are quite  different than those inside VMware View. That same series of clicks will surely change  within each product as they evolve over time. So, I’ll leave the specifics to the vendor  documentation.  Rather than focusing on the VDI products, this final chapter focuses on Windows itself. The  reason? Windows 7, as you know, is designed to be an “everything for everyone” operating  system (OS). Far from a single‐purpose OS, Windows 7 can just as easily be a home desktop  for one individual as a virtual business desktop for another. The difference is in the tuning. 

 

122

 

Automating Windows 7 Installation for Desktop and VDI Environments 

In this chapter, I’ll share with you the high‐level process you’ll use in preparing Windows 7  for VDI deployment. As you can imagine, many of these tuning suggestions remove the  “extra” bits of Windows that contribute to its resource use. With VDI, many copies of  Windows operate simultaneously on the same server. Thus, the task of eliminating  unnecessary services and processes must be done to guarantee overall performance.  Finally, going down the virtual route adds the potential for a big win. Namely, VDI rewards  smart administration. The smarter you are in tuning your Windows instances, the better  they will perform in aggregate. The more resources you conserve inside each individual  desktop leaves more available for others. Smarter administration in VDI means squeezing  more desktops on fewer servers while still preserving each user’s experience. In the end,  with greater density, you’ll get more out of less. 

Step Fifteen: Integrating MDT into VDI Deployment  With that introduction, let’s step back into Windows 7 deployment, but this time focus on  virtual deployment. We begin by bouncing back to our old friend the MDT. You might at  this point be thinking, “Wait a minute. We’re moving backwards from ConfigMgr to MDT?”  Absolutely. Although the extra functionality delivered by ConfigMgr was necessary in the  previous chapter’s zero‐touch installation scenario, you can use MDT (at no cost!) as your  customization platform for VDI deployment.  One of VDI’s biggest differences is in how the resulting WIM image ultimately gets  deployed. Thus far, the WIM files we’ve created were designed to be deployed to physical  desktops. Deploying to virtual desktops uses a different set of steps. Replacing the physical  desktop’s hard disk is a virtual hard disk. For VMware VDI, that virtual disk file is a VMDK.  Microsoft and Citrix use a VHD file. Combined with that VMDK or VHD file are others that  describe the configuration of the virtual machine itself, such as its memory configuration or  number of processors. All are necessary to describe the characteristics of the virtual  machine. 

Creating a Virtual Machine and Deploying an OS  I mentioned earlier that different VDI platforms use different mechanisms for managing  their virtual machines. This chapter will attempt to stay as product‐neutral as possible, so  I’ll keep things simple by sticking with Microsoft’s Hyper‐V R2 platform. If you’re familiar  with how to create and work with virtual machines, you should be able to easily translate  what you see here into your platform of choice.  Creating a new virtual machine with Hyper‐V starts in the Hyper‐V Manager by clicking  New | Virtual Machine (see Figure 8.1). In the resulting wizard, follow through its steps to  create a new virtual machine somewhere on the Hyper‐V server. Although most VDI  deployments leverage SANs for production deployments, our interest at this point is only in  learning to deploy a WIM file’s contents to a virtual disk.   

 

123

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 8.1: Creating a new virtual machine.  Windows 7 virtual machines tend not to require as much RAM as is commonly installed to  physical machines. Although Windows 7 can operate in as little as 512MB of RAM, real‐ world best practices suggest a starting point of 1536MB of RAM. One great fact about  virtual machines is that you can always adjust that quantity up or down later if you see  performance problems or unused resources.  Connect the virtual machine to an existing virtual network and create a virtual hard disk  when prompted. The final screen in the wizard (see Figure 8.2) discusses the options  available for deploying an OS to this newly‐created virtual machine. Take a look at the  radio button at the bottom of the screen that you may not have noticed before. That radio  button enables you to install an OS from a network‐based installation server. 

 

124

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 8.2: Installation options.  Recall that our entire series of activities to this point has created the very network‐based  installation server this radio button references. By selecting this radio button, you are  effectively PXE booting the virtual desktop and connecting it to your WDS server to receive  an OS image.  Before booting the virtual machine, however, right‐click the powered‐down computer and  view its settings. Look for its BIOS settings, similar to what you see in Figure 8.3. You’ll see  that the virtual machine has been configured to boot from its legacy network adapter. This  legacy network adapter is a special network adapter that’s used by Hyper‐V just to get the  machine started during its initial configuration. Being “legacy,” it is by no means high  performance; however, it does include the necessary code to integrate with your WDS  server. 

 

125

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 8.3: Boot from legacy network adapter.  Note  Microsoft recommends the use of the network adapter and not the legacy  network adapter when a machine (server or desktop) is in production. The  reason is that the network adapter enjoys a set of performance and other  optimizations not available on the legacy network adapter. You’ll eventually  switch to the “regular” adapter after installing Hyper‐V’s Integration  Components.  Other hypervisors use a similar series of virtual adapters and drivers. For  example, VMware View requires virtual machines to use VMware’s e1000  network card driver to connect to a WDS server, but suggests later switching  to their VMXNET3 driver once provisioned.  Connect to the virtual machine, and power it on. You should quickly spot a familiar screen  (see Figure 8.4) if the Hyper‐V host’s virtual network successfully communicates with the  WDS server. In that screen, you’ll see that the virtual machine is ready for a network  service boot. Hitting the F12 button at this point will connect the virtual machine to the  WDS server for an OS deployment.   

 

126

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 8.4: PXE booting the virtual machine. 

Injecting Drivers and Virtual Tools  Voila! You’re successfully deploying a Windows 7 image to a virtual machine! Not much to  it, eh? In reality, this book’s previous chapters have led you through most of the work in  automating this deployment process. If you do nothing else at this point, you have, at the  very least, created your first Windows 7 virtual machine atop Hyper‐V.  Yet, as you know, there’s always more to the story. You will need to add Hyper‐V’s drivers  and virtual machine tools to your MDT driver store. You’ve done this before with the  VMware Workstation drivers in Chapter 2. Hyper‐V’s drivers and tools are called the  Hyper‐V Integration Components and are located on any Hyper‐V server in the ISO file at  C:\Windows\System32\vmguest.ISO. Mount this ISO to a drive letter to get at its contents,  then unpack the drivers from their installation files within. Add them to MDT’s driver store  once you’ve gained access to the drivers themselves.  Note  Another common tactic to install a VDI platform’s virtual tools to desktops  uses an MDT application. You learned how to do this in Chapter 4 by creating  and deploying a silenced installation during the OS deployment process. The  only difference here is that the application being deployed is a collection of  drivers (among other software). Using an MDT application replaces some of  the need for driver injection by directly automating the installation of the VDI  platform’s virtual tools. 

 

127

Automating Windows 7 Installation for Desktop and VDI Environments 

 

Tuning the Virtual Machine  With drivers ready to go, your next step will be to tune Windows 7 for use with VDI. These  tuning activities typically involve shutting down unnecessary services and processes with  the goal of streamlining Windows for best performance as a virtual machine.  In the early days of VDI, this process involved quite a bit of guess‐and‐check work. Today,  however, most VDI vendors have developed a set of guidance documents to assist.  Although each vendor releases its own documentation, you’ll find a fairly significant  overlap in what they suggest you should do. I’ll introduce you to three of these documents  that are available as of the time of this writing, then summarize some of what they suggest  in what remains of this chapter. Those three documents are:  •

VMware View Optimization Guide for Windows 7 

•

Deploying Microsoft Windows 7 Virtual Desktops with VMware View 

•

Citrix Windows 7 Optimization Guide for Desktop Virtualization  Note  Tuning guidance is always a moving target as our industry learns new tips  and tricks. Thus, I am purposely not providing direct links to these  documents, as they will evolve over time and potentially change locations.  You should be able to search for their titles using your favorite Web browser. 

Guidance for Services  Your first step in tuning Windows 7 starts by disabling the services that don’t make sense  within a VDI deployment. Unlike Windows XP, where nearly every service was enabled by  default, Windows 7 does a better job of turning on only those services that it absolutely  needs. That said, the default installation of Windows 7 still enables services that can be  safely disabled when they aren’t absolutely necessary.  Disabling these services also stops any associated processing, which has an effect on  overall VDI environment performance. Collected from the three documents listed earlier,  consider the following services as a starting list for those you might want to disable on your  VDI virtual machines: 

 

•

Background Intelligent Transfer Service (BITS). Some applications and services  require BITS for functionality; test before removing 

•

BitLocker Drive Encryption Service. BitLocker is not recommended for use within  many VDI architectures 

•

Block Level Backup Engine Service, Microsoft Software Shadow Copy Provider,  System Restore, Volume Shadow Copy Service, Windows Backup. Used for  protecting local data, which is unnecessary in a layered environment where data is  stored off the desktop and issues are most often resolved by recreating the desktop 

•

Desktop Window Manager Session Manager. Enables Windows Aero, which will  improve performance if disabled 

128

Automating Windows 7 Installation for Desktop and VDI Environments 

 

 

•

Disk Defragmenter. Disk defragmentation will have a significant impact on  performance; pooled desktops are typically destroyed and re‐created often enough  that fragmentation does not create significant performance issues 

•

Diagnostic Policy Service, Windows Error Reporting Service. Used for  troubleshooting and problem detection; less useful in a VDI environment where a  common solution is to destroy and re‐create the provisioned desktop 

•

Function Discovery Resource Publication. Publishes computer information on  the network, which may not be necessary for enterprise deployments 

•

Home Group Listener, Home Group Provider. Home groups are unnecessary in  enterprise deployments 

•

Indexing Service. Used for indexing local data, which is unnecessary in a layered  environment where data is stored off the desktop 

•

IP Helper. Disable when IPv6 is not used 

•

Microsoft iSCSI Initiator Service. VDI desktops typically do not use local iSCSI  disks 

•

Offline Files. Used for storing copies of network files, which is a use case not found  in most online VDI deployments 

•

Secure Socket Tunneling Protocol Service. Used for VPN connectivity, which is  not commonly a part of a VDI architecture 

•

Security Center. This service notifies users when security‐related configurations  are modified, which may be unnecessary in a fully‐managed VDI architecture 

•

SSDP Discovery, UPnP Host Service. UPnP devices are not commonly attached to  VDI virtual machines 

•

Superfetch. Used for caching commonly‐used applications; less useful in a VDI  environment where provisioned desktops are routinely destroyed and re‐created 

•

Tablet PC Input Service. Tablet PCs are not commonly attached to VDI virtual  machines 

•

Themes. This service adds personalization to the desktop experience but at the cost  of added resource utilization 

•

Windows Defender, Windows Firewall. Some environments elect not to install  anti‐malware or host‐based firewall software to VDI desktops due to their  extremely short lifespan 

•

Windows Media Center Receiver Service, Windows Media Center Scheduler  Service, Windows Media Player Sharing Service. Windows Media Center and  Windows Media Player are not commonly used on VDI virtual machines 

•

Windows Search. Used in searching for data, which is unnecessary in a layered  environment where data is stored off the desktop 

129

Automating Windows 7 Installation for Desktop and VDI Environments 

  •

Windows Update. Virtual machine images are typically based on clones of a core  image; when updates are ready for deployment, typically the core image is updated  with clones regenerated thereafter; updates are typically not installed directly to  cloned images 

•

WLAN AutoConfig, WWAN AutoConfig. Used for wireless LAN and mobile  broadband configuration; not a common configuration with VDI virtual machines 

Disabling these services can be accomplished via many mechanisms. Both Group Policy and  Local Policies are two mechanisms to control configuration while desktops are in  operation. Services can also be configured during OS installation by adding custom tasks to  an MDT task sequence. These custom tasks, in this case the Run Command Line task,  configures services by invoking the Windows sc command with appropriate options.  Service configuration obviously requires a functioning OS, thus they are typically disabled  late in the task sequence after the core installation is complete. Figure 8.5 shows how the  Run Command Line task might be added to a standard client task sequence in the MDT.  There, the task has been added to the Custom Tasks step, which itself is a component of the  State Restore step, by selecting Add | General | Run Command Line and entering the  following text into the Command line field:  sc config wuauserv start= disabled 

  Figure 8.5: A custom task to disable a service. 

 

130

 

Automating Windows 7 Installation for Desktop and VDI Environments 

The contents of the Command line field in Figure 8.5 show that the sc command has been  configured to set the startup value to disabled for the wuauserv (Windows Update) service.  Similarly‐structured command lines can be used to modify the configuration of other  services.  Guidance for Additional Configurations and Scripting  Services aren’t the only configurations that require tuning. The guides noted earlier suggest  other configurations in which resource‐intensive activities such as full window dragging,  font smoothing, and cursor blink are disabled. These other configurations can be set  through registry manipulations, the use of native commands, or even Group Policy or Local  Policies. Often, Loopback Policy Processing is used to apply user‐specific settings to  organizational units (OUs) that contain the VDI desktops’ computer objects.  In the interests of space, I’ll direct you to each document rather than reprinting their  guidance here. That said, implementing some of these configurations at the time of  installation is another area where the MDT’s task sequences can assist. One way to invoke a  series of changes all at once is through the use of scripts.  Recall that the MDT’s Run Command Line task can invoke any executable or script that is  natively supported by Windows 7. This support means that batch files, VBScripts, and (with  a little extra effort) even PowerShell scripts can be used to make configuration changes.  Figure 8.6 shows a second Run Command Line task that’s been added to the Custom Scripts  step. That task runs a custom VBScript script named DisableCursorBlink.wsf by invoking  the cscript.exe script host. The contents of the VBScript itself are unimportant for this  discussion. As long as those contents correctly accomplish the task without generating an  error or prompting the user, the script will execute correctly. 

 

131

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 8.6: Incorporating a script into a task sequence.  More important for this discussion is where you’ll store those scripts once created. For  scripts to be delivered and invoked on desktops during installation, they need to be stored  in the %SCRIPTROOT% folder. This folder is found on the MDT server, typically in the  \Scripts subfolder of your deployment share.  A view of the Options tab can be seen in Figure 8.7. For particularly complex scripting  needs, this tab provides a location to determine the success codes for a script as well as set  conditions for when a script must be run. The success codes 0 and 3010 are inserted by  default. A success code of 0 generally means that the script executed successfully, with a  success code of 3010 generally representing a successful execution with the need for a  reboot. Additional codes can be added in the field if your custom script is configured to  supply them as it exits.   

 

132

 

Automating Windows 7 Installation for Desktop and VDI Environments 

  Figure 8.7: Adding success codes and conditionals.  Also seen in the lower‐right of Figure 8.7 is an area where conditional statements can be  added to determine whether a script should be run. Scripts are only run when conditionals  in this box resolve to True. 

Tuning Personal Desktops vs. Pooled Desktops  It is worth stating again that this configuration tuning process is important for Windows 7  to function best within your selected VDI platform. You’ll find, however, that which  configurations you’ll want to tune are impacted heavily by the methods in which Windows  7 will be deployed to users. Two common methods are through the use of what are  generally called personal desktops and pooled desktops.  Different vendors refer to personal and pooled desktops by different names. From a  general perspective, however, the personal desktops approach refers to delivering the  exact same desktop instance to each user each time. That desktop is considered the user’s  personal one with no other user having access to it. This approach is most similar to  physical desktop deployment, where a one‐to‐one mapping exists between each user and  their assigned desktop. 

 

133

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Pooled desktops are quite different. A pooled desktop is one that has been generalized and  added to a pool with others that are similarly configured. As a user logs in, that user is  assigned the next available desktop in the pool. As a result, they are never guaranteed to  get the same desktop every time, and in fact rarely do. When well‐engineered, this practice  adds a significant amount of flexibility to VDI deployments, as desktops can be easily  destroyed and re‐created when problems occur.  To enable this flexibility, pooled desktops are typically configured using a layered  approach. They also commonly make use of desktop clones, which are low‐volume  snapshots from a central, core image that contain only changes. Their core OS is installed  with very basic settings and core configurations. Applications and user state information is  then layered over the top as the desktop is provisioned to the user.  When well‐engineered and well‐optimized, pooled desktops tend to enjoy a much lower  cost of ownership than do personal desktops. Pooled desktops tend to enjoy a higher  density than personal desktops. They can be much more easily destroyed and re‐created  because they are based on clones from a core image. These tactics can significantly reduce  the storage costs associated with VDI while increasing its user density. As a result, many of  the tuning suggestions you will find tend to relate to the pooled desktop architecture. If you  intend to deploy personal desktops, you might want to enable more personalization  elements. Doing so will mean leaving a greater number of services and processes enabled. 

Preparing and Templatizing the Deployed Virtual Machine  Desktops that will be used for VDI deployments are generally cloned (in pooled  environments) or directly copied (in personal environments) from the reference virtual  machine. Most VDI solutions first require converting the virtual machine into a template  prior to deployment. This conversion process is a protective measure that restricts the  virtual machine to be used only as a source for replication.  No matter which desktop approach you plan to use, reference virtual machines must be  generalized prior to replication. Depending on your VDI solution, the generalization  process will use the native SysPrep utility or a vendor‐supplied utility. Notwithstanding,  both SysPrep and the vendor‐supplied tools achieve the same goal of removing system  personality elements such as name, IP address, and SID, among others. Vendor‐supplied  tools will typically add configurations that prepare the virtual machine for VDI distribution. 

 

134

 

Automating Windows 7 Installation for Desktop and VDI Environments 

Automating Windows 7 Installation: Start to Finish  And now we finally navigate to the end of this story. Starting with the very basics of OS  installation, you’ve now experienced the vast majority of tools and techniques that layer on  top of each other to create full automation. Yet even as this story concludes, it merely  scratches the surface of the in‐the‐field tips and tricks that other deployment pros have  learned. Regardless of whether they are specialized task sequences, scripts to add to them,  or other nifty tips and tricks, all of these further automate this process while making your  life easier.  Best of luck with your Windows 7 deployment project. With the foundations firmly  grasped, you’re well prepared to be successful in upgrading your environment to  Microsoft’s newest desktop OS.   

Download Additional eBooks from Realtime Nexus!  Realtime Nexus—The Digital Library provides world‐class expert resources that IT  professionals depend on to learn about the newest technologies. If you found this eBook to  be informative, we encourage you to download more of our industry‐leading technology  eBooks and video guides at Realtime Nexus. Please visit  http://nexus.realtimepublishers.com.     

 

135