Pre Made Windows Screen
Building and maintaining corporate desktop images is a core IT task, but it doesn’t have to be overwhelming. Here are some ways to streamline the process.
Mitch Tulloch
Most large organizations have hundreds of desktop images they have created and use for deployment. There are a number of reasons why a single organization would create so many images. Often it’s due to factors beyond anyone’s control, like changes in platforms and hardware configurations. The lack of a standardized image engineering methodology can also lead to image proliferation.
Then there’s internal politics—competing IT fiefdoms demanding control over what gets deployed on their systems. Some other considerations may be unavoidable, like the specific requirements of high-security environments. Whatever the cause, maintaining a massive library of corporate desktop images can be difficult, time-consuming and expensive. How can you mitigate the problem?
The Single-Image Goal
There’s no one-size-fits-all solution and there are many tradeoffs to consider. However, new features in Windows 7 and enhancements in Microsoft Deployment Toolkit (MDT) 2010 and System Center Configuration Manager (SCCM) 2007 R2 simplify the task of building, maintaining and deploying numerous Windows images. Choose your strategy for building and maintaining Windows 7 images based on the business needs, budget, hardware and level of IT sophistication of your organization. There are also a number of common “gotchas” to watch out for and to avoid.
The Windows Imaging (WIM) file-based disk image format first introduced in Windows Vista, has made the goal of a single corporate desktop image more attainable. The new Deployment Image Servicing and Management (DISM) tool introduced in Windows 7 simplifies maintaining images by letting you service them offline. This can greatly decrease the time required to update a stale image. For example, you can use DISM to quickly add software updates and packages, add or remove Windows features, and add third-party INF-based device drivers to an existing image.
While the Windows Automated Installation Kit (WAIK) for Windows 7 includes tools for manually building and maintaining images, the new features and enhancements found in MDT 2010 make your job easier. The new Sysprep and Capture task sequence lets you capture an image of an existing, fully customized reference computer on your network. MDT 2010 Windows PowerShell support also lets you write your own scripts to automate the task of building and maintaining reference images. You can organize your OSes, drivers, packages and applications by creating custom folders in the Deployment Workbench folder hierarchy. You can then use Selection Profiles to control which drivers and packages you’ll inject into your boot images and deploy using your task sequences.
These improvements virtually eliminate the technical requirements for creating multiple images. You only need to create additional images for specific business reasons. Now most organizations will only need a single corporate desktop image per architecture—one for deploying x86 Windows and one for deploying x64 Windows.
The ultimate goal is to have a single image that’s easy to maintain, will install on any corporate-supported hardware, will work for users in any region of the world, and will provide the desktop, applications and customizations they need in order to perform their jobs. Before you can move your organization toward this particular version of utopia, however, you’ll need to consider whether your desktop images should be thick, thin or hybrid.
Thick Images
Using thick images is the “all-in” approach to desktop images. The traditional way of building a thick image is to install Windows on a reference computer. Then install all the drivers you’ll need, all the applications your users will need, the latest software updates, customize everything, and then use Sysprep to generalize the image. You then capture and deploy the image to users’ computers using MDT, SCCM or custom in-house deployment tools.
“In building an image, careful consideration needs to be made on how the image will ultimately be deployed, ” says Jeff Stokes, a premier field engineer at Microsoft who has been active in Windows 7 and Windows Server 2008 R2 deployments with MDT 2010.
For example, one problem with thick images is that they tend to be big—sometimes too large to fit on a single DVD if you’re doing media-based deployments. They can be so big as to consume valuable bandwidth when deploying over the network. Some users may also end up with software they don’t need, which is confusing. Unused applications must also be licensed on each computer installed, which can quickly drive up your costs. Thick images may also become outdated quickly, especially if you’re trying to ensure your images are always fully patched. Testing thick images is also more time-consuming because of the complexity of additional components they contain.
In any event, image size is often an issue with thick images. “You may want to consider creating custom multi-image WIM files as it can lead to large space savings and reduce the number of task sequences for deployment. See my blog post for more information, ” says Michael Murgolo, a senior consultant with Microsoft Consulting Services.
Thin Images
Thin images are the “ante-up” approach. You keep everything at a minimum for simplicity. A thin image may include only boot-critical drivers, a service pack if available, and a few essential customizations and nothing else. The ultimate thin image is the install.wim file from your Windows 7 product media.
When you deploy thin images, you’re basically deploying only the OS. This means you have to deliver additional components like software updates and applications separately outside of the OS image. Doing things this way means additional infrastructure.
For example, you can use Windows Software Update Services (WSUS) to deploy software updates and Group Policy Software Installation to deploy applications. For larger environments, use SCCM for packaging and distributing applications and software updates to users. Organizations choosing to deploy virtualized applications to end users using Microsoft Application Virtualization (App-V) or letting users run RemoteApp programs using Remote Desktop Services are also good candidates for thin images.
While you can distribute software updates soon after deployment using Windows Software Update Services (WSUS) instead of building them into your images, this is not a good idea. It leaves open a brief window of vulnerability during which your deployed computers are less secure. A better approach is to add all available software updates to your base image when you build the image. That way, when you deploy your base image to your target computers, they’re secure from the start.
If you’re using MDT to build your base image, add WSUSServer=http://wsus_server_name to the CustomSettings.ini file for your deployment share. You can then use MDT to deploy a fully updated version of Windows to your reference computer, Sysprep the reference computer and capture its image, and upload the captured image to your deployment share. MDT makes all this easy by letting you automate the entire process.
