官术网_书友最值得收藏!

Imaging history

In the beginning there was DOS, and it was good. But then there was a need for more and Windows came into being. At first, it was OK to pop the floppy disks that contained Windows for Workgroups into machines one by one on each computer individually in an enterprise environment. But soon, businesses started asking for things such as configuration settings for deploying Windows en masse.

And so, Unattend.txt and Sysdiff.exe and other fun things were created, where the intrepid NT 3.5 admin could build a machine, tweak it, and run Sysdiff to create a template with which other installations could follow and be identical, more or less. Later, as things progressed, the need was strong for a way to really clone machines!

And so, in the distant past (10+ years ago), the world of imaging and deploying the Windows Client came to be ruled by disk sector duplication deployments. This process was fairly involved, in that a technician would install a copy of Windows XP, patch it, install updated drivers, configure Windows XP's look and feel, install applications, patch the applications and finally configure the applications. After that was done (a process that could take a day or more) it was captured with a tool in a sector-by-sector fashion into a file for later deployment over network or media, again, sector-by-sector. Thus the technician would have an image, for a single model of computer, with a single set of applications.

So imagine an enterprise-level environment with say, 10 models of computers (I've seen some with over 100 models so 10 is a good example) and 1-3 sets of applications installed per model. Now the technician (or now it's most likely technicians at this point) is patching and managing roughly 10-30 images in our conservatively estimated enterprise environment. We didn't even throw 32 bit versus 64 bit into the equation.

So this poses a few problems for deployment projects that may not be readily apparent:

  • Each image is say 15-20 GB in size post-compression. Particularly in computing ages past, maintaining a library of images of this size was a daunting proposition.
  • Each image needs to be updated on a semi-regular basis to take into account service packs, OS patches, application patches, driver updates, and random configuration tweaks requested by management and marketing departments. Not doing so increases the deployment time as all the work of applying updates and patches then occurs at every deployment process instead of once before capture.
  • Each machine had the same globally unique identifier (GUID), because it was in fact a clone of another machine. So when you joined both to the same Windows domain (even with different names) hilarity ensued. Tools were created, such as NewSID and Sysprep's /generalize switch, which helped get around this.

But around 2006, with the release of Windows Vista, things changed. There was a new paradigm in image deployment that would change everything: the Windows Imaging Format (WIM) format. The WIM format is essentially a container for an image. With it, and some tools from the Assessment and Deployment Kit (ADK), one can service the Windows image offline, which allows us to add patches, drivers, and remove components such as games from our image, all without having to install it first on bare-metal hardware.

An example of this would be something like the Deployment Image Servicing and Management (DISM) command (in an elevated command prompt) to remove a hotfix from your running system:

DISM /online /remove-package /packagename:Package_for_KB2868623~31bf3856ad364e35~amd64~~6.1.1.1

Around this same time enters a tool known as BDD. The Business Desktop Deployment (BDD) toolkit was a set of scripts that could be used to customize, configure, and deploy the Windows image in the enterprise environment. BDD 2.5 was released in August 2005, prior to the RTM of Vista.

BDD had several iterations and even had a Microsoft Certified Professional Exam created for one of its versions. These iterations were each an improvement upon the last until finally, in November 2007, the MDT was released.

Fast forward to the present, and MDT 2013 Update 2 is current at the time of writing. At this point, MDT is essentially System Center Configuration Manager (SCCM) "lite". You can backend it with a database, put a web frontend on it, do dynamic actions based on hardware make and model, install previous applications, and much more.

This tool, the MDT, will be the focus of this book. There are other (typically more expensive) solutions out there to be sure, but if one is preparing to perform deployments at scale, MDT should be looked at as it can easily do a lot of manual work and, while it costs nothing, it is supported by Microsoft Support.

主站蜘蛛池模板: 株洲县| 武夷山市| 白城市| 芒康县| 洛南县| 雷州市| 麻阳| 定西市| 彭山县| 安乡县| 北安市| 彩票| 百色市| 自贡市| 怀宁县| 文成县| 贵德县| 密山市| 资中县| 徐汇区| 绥阳县| 浦城县| 会泽县| 云霄县| 自贡市| 富蕴县| 诸城市| 承德市| 德清县| 长泰县| 莱芜市| 庆元县| 南城县| 巴楚县| 宿迁市| 涞源县| 江口县| 霍城县| 正镶白旗| 海宁市| 卢龙县|