For many organizations, the decision to move to Windows 10 is a given. However, the big question is “how” to move to Windows 10.
When deploying an OS image, there are two typical approaches: “in place” or “replace”. Both have merits, but most organizations choose to “replace” in an attempt to standardize (the image, hardware, or both image and hardware).
Once the decision to “replace” has been reached, then what? Many organizations utilize and own System Center Configuration Manager (SCCM) and create deployment task sequences. Experienced Operating Systems Deployment (OSD) engineers will likely recognize the different types of OS images: thin, fat, and hybrid.
A thin image is nothing but the Microsoft OS with only the stock drivers and apps that ship from Microsoft. Thin generally means bare bones in this case. Applications and drivers are always added via additional tasks after the main image file is deployed.
A fat image is an OS image file that contains the OS, all apps, all drivers, and the kitchen sink. Fat generally refers to the size of the file because its going to be big. For old school folks, think “Ghost”.
A hybrid image is generally a mixture of the two previous image methods. Its mostly the stock OS plus a couple of applications that are used universally by an organization (such as .NET or Adobe Reader). Drivers and other applications are added via additional tasks after the main image file is deployed.
The method an OSD engineer will select largely depends on his organization’s needs. Often, I run across customers who are migrating to Windows 10 using the hybrid imaging approach. The hybrid approach is generally the most flexible because tasks can be added or removed to a task sequence very easily. For daily operations where OSD is run a couple times per day, this is a good approach and one I would recommend.
However, for mass OS deployments as a part of a migration project, I always recommend a different approach: go fat. That’s right use your OS deployment tool like “Ghost”. Why? It’s the best way to achieve success. It’s simple, consistent, and fast.
As a migration project progresses, task sequences tend to grow. They start off small but tend to grow larger with complexity. This results in more tasks in a task sequence which equals more points of potential failure. More points of potential failure lead to potential inconsistent image build results. Some systems may have an application or driver installed while other systems may not. And finally depending on the task, such as an application install, large task sequences with numerous tasks always take more time to process.
Conversely, a task sequence with a large OS image file with most (or all) applications already baked into the image will use less tasks, will only take as much time as the image file copy, and will always build the exact same system. Naturally, there are always security applications or drivers that cannot be baked into an image file. In those situations, an additional task may be necessary. Regardless, the result is still a simpler, speedier set of steps and a quicker image build process.
Paul Newton is a Senior Solutions Architect at McGlaun Consulting.