OSD Phases

The phases of OSD line up with any good project management philosophy; you may have different names for them, but the principals remain the same. In addition, depending on your personal style or your organization's environment, the OSD process may be formal with much rigor and documentation, informal with handwritten notes and napkin doodles, or somewhere in between. The next sections discuss the phases you should use with OSD.

Planning

Like any complex endeavor, planning plays a key role in the success or failure of OSD. Planning for OSD involves defining the who, what, and when of Windows deployment for your organization-consider this the requirements gathering phase. The answers to these questions can guide how you go about technically implementing the process and making it work.

Who: Who are you deploying Windows to or for? Is it your entire organization or just a subset? Who will be initiating the deployment to each of these systems? Will it be your end users, field technicians, you, or someone else?
What: What OS are you deploying? What version and edition? Will different users or systems get different versions or editions? What applications do you want to deploy with the OS? Will this be different for different user or system roles? Are there other customizations that you need to make to the OS or applications? To which hardware models are you deploying the OS?
When: When are you going to deploy? Is there a deadline that you must meet? Are you going to deploy during the day or after hours?
Other: Do you care about user data? How do you handle updating Windows and other software in your organization? What other desktop standards exist in your organization that must be part of deploying Windows?

These questions and their answers can guide all your efforts; the answers are the blueprint for your Windows rollout. Depending upon your organization, you may not be able to answer all these questions yourself, and it may take a considerable amount of time to gain consensus from the key players. Knowing the answers ahead of time can save you work or rework down the line.

Preparation

When you understand the requirements for your deployment, you can set about gathering the needed resources, importing them into ConfigMgr, and performing any necessary ConfigMgr configuration or hierarchy modification to meet those requirements. Necessary resources include OS source media, application source files, drivers, configuration scripts, test systems, and storage space. Many of these resources including the OS source files, drivers, and applications must be imported into ConfigMgr for use in OSD-the import of both OS source files and drivers is covered in the "Operating System Installers" and "Drivers" sections of this tutorial.

Based upon the physical nature of your organization, you may need to add site systems. For example, smaller sites that normally would not require a site system for normal ConfigMgr operations such as inventory and software distribution may need to have one added to support PXE, the larger OS image files used by OSD, or the transient storage of user data. Alternatively, site systems may already exist at these locations and simply need these roles enabled-the "Site System Roles" section discusses the two supplementary OSD roles and installing them.

Creation

The core of the OSD process is putting all the requirements in place to deploy Windows. It involves stringing the various OSD building blocks (see the "OSD Building Blocks" section for complete details) into an ordered structure that meets your defined requirements. This is often an iterative process, involving building a basic structure, testing, adding to the basic structure, testing again, and so on. As requirements change (or are revealed), the iterative process will continue even after you implement OSD into production.

Testing

This self-explanatory step is often over-looked and rarely given the time or attention that it deserves. So many different permutations and factors exist even in smaller and simpler environments that you can probably never test all of them; however, not properly and thoroughly testing as many as you can will result in poor results and lost data. In general, you should test against every scenario and model of hardware possible in your organization.

Much like a proper software development lifecycle, testing should account for most of your time when developing new task sequences. Although much of this time is watching progress bars, you will never actually know if your design work will result in the wanted outcome of a properly deployed Windows instance without it.

Productionization

Productionization is not a word in the dictionary, but it captures the essence of this last phase: rolling out your hard work into production and making Windows deployment an activity your desktop technicians and users no longer dread. If you have done your due diligence, properly gathered and accounted for all of the requirements, and tested everything possible, you are ready to put that work into motion.