Deployment Scenarios

As a common point of reference, Microsoft has defined five Windows deployment scenarios. These scenarios cover the gamut of possibilities for deploying Windows in general to any organization; minor variations are possible, and implementation details may vary depending on the tools used or goals of the deployment. OSD handles four of these five scenarios:

• Upgrade: This scenario involves an in-place upgrade of the current OS to a new OS. It preserves user data as well as applications, and is thus (falsely) considered by some as the best choice when moving an organization to a new OS. The downfall is this scenario also preserves misconfigurations, unauthorized software, and any existing malware.
  The Upgrade scenario is not supported by ConfigMgr-in neither OSD nor software distribution-making the choice easy. For OS deployments where a well-managed client infrastructure is important, that is, all environments, the refresh scenario is the preferred and highly recommended choice for upgrading the OS.
• New Computer: The name of this scenario is a little misleading because it can apply to new or old computers and applies to systems brand new out-of-the-box or those that are just being reloaded completely. The distinguishing factor in this scenario is that current user data and applications on a system, whether they exist or not, are ignored. This scenario is often referred to as bare-metal or wipe-and-load because it assumes that nothing on the system is currently valid, and it should be built from scratch or bare-metal.
  This scenario is the easiest to deal with because you do not need to worry about user state; a user's state includes all the data, documents, and configuration of the system and applications that are unique to that user.
• Refresh: This scenario involves installing a fresh, new OS on an existing system while preserving applicable user data and reinstalling authorized applications, in effect refreshing just the OS. This reload can be the result of a variety of reasons:
  • An upgrade such as Windows XP to Windows 7.
  • The current OS installation is broken beyond repair.
  • The OS installation does not meet current standards.
  When a process is in place to rebuild systems quickly with OSD, organizations typically choose to re-image a system after the help desk spends a set amount of time troubleshooting without resolving an issue. This approach provides a way to decrease help desk costs spent on fixing operating systems.
  NOTE:
  These two scenarios sound similar and even have a similar result; however, they are different. Upgrade is literally running setup.exe in the existing OS and allowing Windows setup to upgrade the OS in-place. Refresh involves wiping the disk (not necessarily formatting it) and installing a clean version of Windows.
• Replace: The Replace scenario is similar to the Refresh scenario but involves swapping out or replacing the physical system. Because the user's state lives on the old system, this scenario adds the challenge of moving the user's state and can be both challenging and time-consuming. Rest assured, however, OSD is up to this task and provides you the necessary capabilities to accomplish this.
• OEM: This last scenario is similar to the New Computer scenario in that current user state is not involved. This scenario, however, is explicitly for new systems delivered from the Original Equipment Manufacturer (OEM) or vendor. It involves delivering a seed image to the OEM for their use during the factory's system build process. Because the OEM cannot join a system to your domain or install applications from your internal network, the seed image, when booted, kicks off the rest of the process after the system is physically set up on your internal network to finish the deployment process.
  The advantage to this scenario is your OEM can drop-ship systems directly to your remote offices; the systems can easily be installed by non-IT resources and the deployment process finishes without any intervention. The disadvantage is that you will probably end up maintaining at least two sets of images: one for your in-house scenarios and one for the OEM scenario. Ensuring that the OEM has the latest image is also challenging and a possible disadvantage depending on how often you update your base image and how quickly they begin to use a new image.
  Each vendor may also have varying states of support, procedures, and supplemental tools for this method. Contact them first before pursuing this option for their guidance and recommendations.

Table-1 summarizes the five scenarios.

Name 		Supported 	User State 	System Hardware
Upgrade 	No 		Preserved 	Same
New Computer 	Yes 		Ignored or N/A 	New
Refresh 	Yes 		Restored 	Same
Replace 	Yes 		Restored 	New
OEM 		Yes 		N/A 		New