This is a repost of an article that I think people need to follow. I am ask a lot of times what the best way to image a computer. I have share the stage with Jeremy Chapman at Tech•Ed taking about this and referenced this content before, so now i adding it to my blog.
I have learned much of what I know but talking with the folks at Microsoft when it come to Imaging using the free tools an now Jeremy (the product manager) has started a group of articles to help other understand the process.
Improving Your Image: Sector-Based, File-Based, and Simper - What Makes the Most Sense?
By Jeremy Chapman, Senior Product Manager, Microsoft Corporate
After spending a few weeks on the road speaking at Tech•Ed and other events, I was struck by the fact that many IT pros haven't used any of the Microsoft tools for imaging and deployment. All in all, it seemed as though half of the room at my sessions had never seen or heard everything about file-based imaging and tools like ImageX and the Microsoft Deployment Toolkit or System Center Configuration Manager. The other half may have heard about the tools, but had never used them.
I get a lot of feedback from people that we are "selling" the Microsoft tools for imaging when we should be talking about the sector-based ones that people are using for Windows XP now. This is interesting feedback because the tools we are talking about-the Windows Automated Installation Kit, the Microsoft Deployment Toolkit, etc.-are free to download and use. In any regard, I have spent a lot of time with people who are using heavily-scripted solutions and thick sector-based images for their Windows XP environments. Some organizations even get down to one or two Windows XP managed images by customizing Hardware Abstraction Layer (HAL)-swapping with sysprep.inf-a practice that Microsoft hasn't supported, but one that is well known in the deployment community.
So what is the right way to do this? What are the pros and cans of each scenario? What is it that makes the sector-based solutions so attractive? These questions boil down to a couple of factors:
1. Image size - network bandwidth consumed + multicast support
2. Hardware coverage
3. Speed to lay down the image
4. Ease of use and familiarity - especially if you have to have a UI
5. Ease of creation - automating daily/weekly/monthly builds
6. Post-creation image management
All of these factors (and others) contribute to the decision about which tool(s) to use for imaging and deployment.
Then there is the question about when to use the System Preparation (Sysprep) Tool. In November, Mark Russinovich discussed in his blog the use of sysprep.inf or sysprep.exe. While his blog post referenced the fact that duplicate SIDs do not cause the issues they were once thought to cause, this made many question the use of the Sysprep tool overall. For those who hadn't been using Sysprep, their decision appeared to be validated. This sparked a lively philosophical debate among extremely knowledgeable individuals in our internal and MVP deployment communities that was very fun to watch and participate in. The fact is, however, that Sysprep is a necessary tool for imaging and deploying Windows client operating systems. Mark even clarified this in the April 29th Springboard Series Virtual Roundtable on Windows 7 Deployment and noted this in his blog:
"Note that Sysprep resets other machine-specific state that, if duplicated, can cause problems for certain applications like Windows Server Update Services (WSUS), so Microsoft's support policy will still require cloned systems to be made unique with Sysprep."
Based on these recent events, and a general desire in the IT pro community to know the pros and cons of file-based and sector-based imaging, I am going to help the Springboard Series with a series of blog posts on the topic of sector-based imaging versus file-based imaging. I hope to answer the question I pose in the title "Sector-Based, File-Based, and Sysprep. What Makes the Most Sense?" No combination is perfect or applies to all scenarios, but if you've had questions about which you should be using, keep checking the Springboard Series blog or sign up for automatic updates on new blog posts via RSS.