Awesome post over Keith Combs blog on Technet.
Windows 7: Best of Deployment Compilation
By Jeremy Chapman
I like all types of music and with almost any successful musician there comes a time when they take their best tracks and create a “Best of” album. This is not only great for people who want all of their music in one place, but also for the people new to that musician. Now you might argue that all this goes away with online music services, but I’d argue that sometimes the level of selection there gets daunting. At this point you’re also probably wondering what this all has to do with Windows 7 deployment, well… after more than a year post general availability and two years since I’ve been writing and reviewing content, it’s time to sift through that huge potential playlist and cut the Windows 7: Best of Deployment Compilation.
If you are new to the Windows deployment game or are stuck in the spooky world of drive-cloning with older sector-based processes, this should help you get started. If you’ve seen it and have the concert T-shirts from our TechEd tours, then you can probably skip ahead. We’ll start out with the basic concepts then go deeper into the how-to guides.
If your goal is to very quickly have a nice fully automated Windows 7 setup, including drivers, application etc. – This article is not for you. If that’s your goal, you should download the free Microsoft Deployment Toolkit (MDT) 2010, and use that as your deployment solution.
That being said, if you rather is a hardcore geek who wants to build everything yourself from scratch, instead of using the standard tools that Microsoft recommends, this article will help you create your own answer files to automate the core Windows 7 setup.
This is also your chance to challenge the 20+ people strong deployment team at Microsoft, showing them that you are better building deployment solutions than they are. Why use a standard solution that 300.000 other people on this planet are already using when you can re-invent what they have done and build it your self.
So here is the text to get in touch with your inner deployment geek…
Installing Windows 7 isn’t just about migrations. It’s about daily management. It’s about rapid deployment to fix problems. It’s about provisioning virtual desktops in a VDI infrastructure. With today’s technologies for user virtualization and application virtualization, fixing some IT problems can be fastest accomplished by simply rebuilding the computer. For all of these reasons, the outwardly simple process of installing Windows grows to become a much more critical activity than ever before. Installing Windows through automated means is even more important. That’s why this book exists. While installing Windows the manual way requires as few as seven clicks and a bit of time, fully automating its installation requires quite a bit more effort. You need a project plan to get you started and a cookbook of step-by-step solutions to finish the job.
In Automating Windows 7 Installation for Desktop and VDI Environments, you’ll deep dive into the steps required to automate Windows 7 installation. But you won’t stop there. You’ll dig deep into the ways in which that automated installation will fundamentally change how you do IT. You’ll learn exactly how to automate Windows for an OS migration project, whether from Windows XP or Windows Vista. You’ll discover the steps to wrap your automated installation into a VDI infrastructure, enabling virtual desktops to be provisioned automatically and on-demand. You’ll learn the tips and tricks for layering the Windows OS, enabling you to fix common IT problems by simply rebuilding the user’s computer – all while maintaining their applications and profile information and without needing to resort to roaming profiles.
Keep this book handy. You will find yourself turning back to it again and again as you fully automate one of the most time-consuming parts of your job: Windows 7 Installation.
Great post over on The Deployment Guys blog that talks about a VDI Optimizer tool that creates a VBScript that can be used to customize Vista and above images for use in a VDI environment.
“One of our MCS deployment guys in the UK – Jonathan Bennett (you may know Jonathan as the author of the autoit tools and GImageX) has developed a tool for configuring Windows 7/Windows Vista/Server 2008 images for use in a VDI environment. The tool called VDI Optimizer outputs a VBScript (based on the selections you make in the GUI interface), which can then be used to apply performance and configuration settings to images that will be deployed via VDI platforms – this is particularly useful if you are using MDT 2010 for your image engineering process as the VBScript can bolted into the task sequence using a Run Command Line task.”
Steve Rachui has another nice post on Direct Access over on his MSDN blog.
“Do you have internet based clients that you want to manage? Does the idea of switching to SCCM native mode to manage those client make you nervous? Do you have Windows 2008 R2 servers in your environment and are the internet systems you want to manage running Windows 7 (Enterprise or Ultimate) or Windows Server 2008 R2? If you said yes to all of these questions then you might just be interested in taking a look at Direct Access (DA).”
Here is a great post over on TechNet by Jeff Hugh on how to properly use the CopyProfile feature:
This is a great read and covers both ConfigMgr and MDT usage.
Here is a video showing you how to build a bootable Windows 7 VHD from the Windows 7 install.wim using diskpart.exe and imagex.exe. Very cool stuff!
About this Video
This command line demonstration explains how to build a bootable Windows 7 VHD image from a Windows 7 "install.wim" file using diskpart.exe and imagex.exe. The demonstration continues with an explanation of how to configure the boot entry using bcdedit.exe and explains the limitations of VHD Boot. See the Windows 7 VHD Overview page for more information about this technology.
Here’s a bunch of free books for download. Very Cool!
- Free eBook: Moving to Microsoft Visual Studio 2010 (DRAFT Preview)
- Free eBook: Moving to Microsoft Visual Studio 2010 (DRAFT Preview II)
- Code for “Moving to Microsoft Visual Studio 2010” DRAFT eBooks
- Free eBook: Introducing Microsoft SQL Server 2008 R2
- Free eBook: Programming Windows Phone 7 Series (DRAFT Preview) (by Charles Petrol)
- Free eBook: Own Your Future: Update Your Skills with Resources and Career Ideas from Microsoft
- Free eBook: Understanding Microsoft Virtualization Solutions (Second Edition)
- Free eBook: First Look Microsoft Office 2010
- Free eBook: Windows 7 troubleshooting tips
- Free eBook: Introducing Windows Server 2008 R2
- Free eBook: Deploying Windows 7, Essential Guidance
The Microsoft® Deployment Toolkit (MDT) 2010 and the Windows® User State Migration Tool (USMT) version 4.0 do not support migration from the Windows 2000 operating system to Windows 7. The scripts that accompany this white paper—named Windows 2000 Migrate User (W2KMigUser)—provide a simple solution for migrating users’ files from Windows 2000 to Windows 7. They are samples that you can use as-is or extend as necessary. Microsoft designed these scripts to work during the State Restore Phase of a MDT 2010 task sequence. W2KMigUser backs up users’ group memberships and files from their Windows 2000 profile folders. In Windows 7, W2KMigUser can restore users’ group memberships, re-create their profile folders, and restore their files. Additionally, the script can capture and re-create any local accounts that have profile folders. Of course, you can control the accounts, groups, profile folders, and files that you want to back up and restore. W2KMigUser can use a network share or removable media as a backup store, but the script does not secure that store.
Read more and download here.
The post will cover the most common methods that I know of for driver management in ConfigMgr. For once I won’t be talking about MDT integration!
Auto-Apply consists of importing all your drivers into ConfigMgr and then utilizing the “Auto-Apply Drivers” step in a Task Sequence, this step will match PNP ids and inject the drivers that match the detected ID’s. You can limit selections by utilizing “Categories” or you can simply just let it have free reign on your driver database. The only step i’ve had to work with on this TS step is the “Install only the best matched compatible drivers” vs “Install all compatible drivers.” I had a few models that wouldn’t install all drivers unless I used “Install all compatible drivers.” The biggest problem with this method is that it will grab the newest compatible driver, so if you just imported the latest greatest for a new model you have, many of those drivers will work for older models and will be used for those models even if you don’t want them to be.
1) Quick, easy
2) Don’t have to know what specific drivers you need, provided there is a matching driver, your device will be installed correctly, that works great for some people
3) Matches drivers based upon PNP
1) Sub-devices can be missed sometimes
2) No control over what drivers are being put where, you have some control with “Categories”, but not the degree of control some people like, it will grab the newest/greatest driver it can find that matches your device
3) Matches drivers based upon PNP 🙂
Step in the TS this method focus’s around:
Other main focus points you will want to be concerned with:
Using Driver Packages
This is commonly known as the “control freak” method. When using this method you typically want to control the specific drivers going to each model. Usually this is driven by a Task Sequence step with a WMI query to match up the Model. The major issue with this is that ConfigMgr won’t let you import duplicate drivers, and if you are using common manufactures, 50-80% of your drivers could be same for every model. So what you end up doing is creating driver packages in ConfigMgr, but not actually importing the drivers, you instead put the in the driver package source files and then distribute those to the Distribution Points, thus allowing you full control over what drivers are in the package. This leads to a bit more maintenance since you have to work with the drivers from a folder perspective and you mostly maintain them outside of ConfigMgr. You would still import NIC and Mass Storage drivers (for XP) as you would need those imported ideally to inject them into your boot images, although you could inject them into the wim yourself if you really wanted to. This method works great when you have to be concerned with certain versions of drivers going to certain models, a great example for us is we need our video drivers to be Certified by Solidworks, to get support, we need to ensure the machines are using a correct Certified driver. The problem with the new unified drivers is that the newest version that i need for my new laptop also happens to work for my 2 year old workstation class machine, however that newest driver isn’t Solidworks Certified. Again the theme of this method is control.
This is the method i have personally used up to this point, I now use the 3rd method which i’ll talk about in a bit.
1) Complete control over what is going where
2) Control! x2
3) Injects all drivers in that package, anything in that package is available to the OS
1) Can’t easily import duplicate drivers
2) More administrative overheard
3) Not typically managing most of the drivers from with ConfigMgr
4) You will have the same drivers in multiple packages, taking up more space, possible concern for some
Hybrid of Auto-Apply and Driver Packages
After reading this post by Keith Garner, I got to thinking about how I could do something similar in ConfigMgr. When i really sat down to think about it, the only drivers that really mattered to us was controlling the video drivers. So I decided, why couldn’t i do PNP for everything but the video drivers. Even more on that, unless it’s a machine running Solidworks, i really don’t care what video drivers are installed. So I basically ended up with this structure:
-Common Drivers (Will use PNP)
-Common Video Drivers (Will use PNP)
-Specific Video Drivers (one package for each model requiring a specific video driver)
I imported all my common drivers into ConfigMgr, imported all my video drivers, then seperated them out into common drivers and the specific drivers. I then created all the driver packages i needed for each model that required a specific video driver and added the required driver to the package. I made use of “Categories” to control what was being used for PNP detection.
1) Advantages of PNP detection along with the control over drivers by using driver packages when needed
2) Takes a little configuration and setup
The first section in my Driver Management part of my Task Sequence is for Windows XP Mass Storage drivers, I do a WMI query for the deviceID and then inject the appropriate MSD, this allows me to not have MSD in my other packages and I can have a single driver package for all MSD’s and then just inject when appropriate.
Next, I do a Auto Apply driver step that injects all my Common Drivers, I have these all under a Category called “Common”, this would be audio, modem, card readers, anything that isn’t a video/display device.
Next I have a section for Video Drivers, the driver(s) I want to control in my case. First we inject any Common Video Drivers for models I don’t care about. Just get the best video driver available installed for me.
This is driven by a WMI Model query on the backend for all the models I don’t care about, notice I use “LIKE” statements to get around HP’s funky part #’s:
Next we get into the specific models that I want to inject specific video drivers:
Here we are using a Driver Package for each TS step with a WMI query on the backend, this Driver Package contains the Certified driver that I need for that model:
That’s it! That is how i now manage my drivers, I feel this to be the most effective method for our environment.
Hope this helps or inspires someone else.