Windows 7 / Getting Started

---

Deployment Challenges

Barriers to successfully deploying Windows abound and are often unique to specific environments. Windows Vista added to these with multiple new features such as BitLocker and User Account Control (UAC). The Windows 7 base image size is also greatly increased over Windows XP, adding to overall deployment time and increasing the need for a well-connected environment for general deployment. The next sections discuss some of the more common deployment challenges.

Application Compatibility

Application compatibility is the number-one challenge listed by the various think tanks (including Microsoft itself) when moving to Windows 7. Although this challenge is outside the scope of OSD, its importance cannot be stressed enough. You can perfectly plan and execute a Windows 7 deployment to your organization but if a single critical application, say the CEO's secretary's day-planner application does not run correctly under Windows 7, the success of your entire deployment (and possibly your job) are now in jeopardy.

Microsoft's Application Compatibility Toolkit (ACT) allows you to collect information about the various applications in your environment including a simple inventory as well as run-time diagnostics to identify potential issues-after running this tool, many organizations are quite surprised by not only the number of applications, but also the existence of various applications they have! ACT connects to Microsoft's application compatibility information repository to retrieve and present Microsoft-provided and peer-provided data on application compatibility. Using this data, you can proceed to perform your own application compatibility testing, which ACT can help you track. Finally, ACT is the gateway into remediation of applications when the vendor of the application cannot help for various reasons or you are stuck on using a specific incompatible version of an application.

ACT provides the ability to add fix-ups called shims that change the behavior of Windows itself or instruct Windows to tolerate specific bad behaviors from an application. There are thousands of different shims available; some are specific to an exact application or version and some are generic.

Microsoft provides an entire portal on application compatibility including in-depth information on ACT at http://technet.microsoft.com/en-us/windows/aa905066.aspx.

User Data

Maintaining user data when deploying a new OS is extremely important. Going back to the most important person in any organization, the CEO's secretary, if you somehow do not restore the wallpaper of her grandchildren or lose the data in her day planner, once again your deployment/job may be in jeopardy.

The only time user data is not important is with complete bare-metal scenarios. However, it is quite rare for users in your organization not to have a system with pre-existing data on it unless your organization has managed to centralize all user data using core file services or has forced the responsibility of maintaining user data on the users themselves. In all other cases, users expect Information Technology (IT) to take care of their data. Thankfully, USMT does work almost like magic and is integrated into OSD in ConfigMgr, enabling you to seamlessly maintain user data without having to purchase a wand of your own.

Image Maintenance

An additional major challenge is image maintenance in general. Images are built from reference systems. Reference systems are systems used to build baseline images for deployment to the rest of the systems in your organization. Because hardware differences between a reference system and target deployment systems can cause issues, you must often use multiple reference systems to model your environment and thus create multiple images.

Enabling creation and deployment of this image is what OSD focuses on. However, OSD cannot automate the actual choice or definition of what goes into an image because this is not a technical decision.

A general definition of an image is a single file that stores all the files and information for a specific disk drive volume on a computer system. This file is portable and can be copied or deployed to a destination system. Deploying the image file creates an exact duplicate of the original source volume. This allows you to copy the content of a disk drive volume containing an OS, installed applications, and customizations to multiple other destination systems.

In effect, the image clones the source system and allows rapid deployment of an OS on a large scale. The process of copying the image to multiple machines is much quicker than a native Windows install and requires little manual intervention compared to a full Windows installation that includes applications and other miscellaneous configurations.

Each image is also specific to a specific OS version and edition. Thus if you want to deploy Windows 7 Professional x64, Windows 7 Professional x86, Windows 7 Enterprise x64, Windows XP Professional x32, and Windows Server 2008 R2 x64, you need five separate images.

A prerequisite to the imaging process is performing an inventory of all software and hardware in your organization. This helps you take into account all possible variations-you must know all the possibilities to create the best possible images.

A question often asked is whether to include applications in the image and which ones. Do you include Microsoft Office? Microsoft Silverlight? Antivirus? Questions like these abound and fuel the continuing debate between using a thick or thin image. The distinction between thick and thin images is somewhat subjective, so start with some simplistic definitions:

• Thick image: An image including the OS, OS updates and patches, miscellaneous components, drivers and applications
• Thin image: An image containing the OS with only a minimal set of updates and patches

Conventional wisdom is that a thin image is the better choice-why is this the case? A thin image is easier to maintain; it contains a minimal set of components and thus a smaller set of components that require updates. Like many theories, this sounds great, but reality gets in its way. If you automate creation of the image, updating it on a periodic basis, no matter how frequent, then creating a new image is as simple as added the latest updates (whatever they may be) and initiating the process. This is ultimately a subjective choice and depends upon your organization's goals and practices.

Here are several common or universal goals for deployment images that you should factor into your choice:

• Hardware agnostic: Few organizations can actually standardize on a single hardware system for all their workstations, so this goal should be obvious. What might not be as readily obvious is that it is achievable! The main obstacles to this goal are drivers and the Hardware Abstraction Layer (HAL) in Windows XP. Windows 7 changes the way mass-storage drivers are handled and automatically changes HALs as needed, so these concerns are no longer valid for the newer operating systems.
• Universal: Images should be a baseline for all your deployments; they should contain the greatest common denominator of all the desktop needs in an organization. If not everyone requires a specific application, component, driver, and so on, it should not go into the image-you want to layer it on after deploying the image. This simple but important goal greatly affects your success with OSD. Creating an optimal universal baseline relies on your knowledge of the hardware and software in use and the accuracy of your inventory. Being universal also implies a single base image is used on all hardware models. There are some limitations such as OS editions-Enterprise versus Professional or x86 versus x64-but fewer images means less work and less testing.
• Deployment speed: Although not as important as the previous goals in this section, deployment speed is still valid and becomes important if the network is not as fast as it should be or a WAN is involved. Applications and components included in an image only slightly increase the time it takes to deploy a system, as they are already installed and do not have to be pulled across the network separately. Applications and components layered on after the deployment might increase overall deployment time significantly because they are pulled over the network. Typically, installations include some files not even installed on the system, such as setup.exe or alternate language resource files (in the form of Dynamic Link Libraries or DLLs), which are installed only on systems supporting those languages. This can have a greater impact than first realized.
• Ease of maintenance: In traditional, image-only deployment systems, ease of maintenance is typically the most important factor. Creating and updating images is often an intensive and lengthy manual process. Images created for these systems are typically thinner, to avoid putting in any components that might need updating. This ultimately increases overall deployment time and can increase the complexity of the deployment. ConfigMgr automates creating images, greatly easing this burden and freeing you from making decisions about your images that are based solely on maintaining the images.

An additional consideration is whether you can install an application generically or have its internal unique identifiers stripped. Sysprep does this for Windows, and OSD properly prepares the ConfigMgr client, but you must also think about the applications in the image. Some centrally managed antivirus products have trouble when installed in an image; they customize themselves to the specific system they are installed on and do not behave well when copied to another system as part of an image. This is something to verify with the vendors of the products you plan to incorporate into the image and is an area you should test.

Ultimately, thin versus thick is a moot argument. Every deployment image will probably be somewhere in the middle, and what is right for one organization might not be right for another. Having a thin image, just for the sake of having a thin image, should not be a primary goal. Maintaining images, if it is automated and done correctly in line with the goals above, is a minor concern.