Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.
X
Aside

Back to basics – Understanding Unattend.xml automation in Windows 7

Johan has a nice blog post over his blog I just noticed today, it’s back from October, so shame on me for not reading it until now Smile.  Here is a snippet and you can read the rest of the post here.

First
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.

Second
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…

Aside

Automating Windows 7 Installation for Desktop and VDI Environments

Full Article and download is linked here.

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.

Aside

Optimizing Windows 7 Images For Use In VDI

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.

Read the entire post here.

“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.”

image

Aside

Direct Access – SCCM – Managing internet clients

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).”

Read more here.

Aside

Customizing Default Users Profile Using CopyProfile In Unattend.xml

Here is a great post over on TechNet by Jeff Hugh on how to properly use the CopyProfile feature:

http://blogs.technet.com/b/askcore/archive/2010/07/19/customizing-default-users-profile-using-copyprofile.aspx

This is a great read and covers both ConfigMgr and MDT usage. 

Aside

Building a Bootable Windows 7 VHD from “install.wim”

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!

http://technet.microsoft.com/en-us/windows/dd758779.aspx

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.

Aside

Free Microsoft Books For Download

Aside

Migrating User Files from Windows 2000 to Windows 7 Using the W2KMigUser Script

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.

Aside

Configuration Manager 2007 R2/SP2 Driver Management

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 Drivers

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.

Pros:

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

Cons:

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:

image

Other main focus points you will want to be concerned with:

image

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. 

Pros:

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

Cons:

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.

Pros:

1) Advantages of PNP detection along with the control over drivers by using driver packages when needed

Cons:

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. 

image

image

image

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.

image

image

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.

image

image

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:

image

Next we get into the specific models that I want to inject specific video drivers:

image

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:

image

image

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.

-Chris

Aside

Compatibility Pack for SMS 2003 SP3 that adds Windows 7 and Windows Server 2008 R2 as supported clients

“We recognize that Windows 7 is an opportunity for organizations to reduce their costs, improve security, and improve productivity. Windows 7 helps achieve these goals. However, organizations do not maximize the return on investment of Windows 7 without modern infrastructure to support it.

We want organizations to benefit from the latest platform’s features. To achieve these goals, we want to help organizations migrate to our latest management platform. To do this, we have released a compatibility pack that adds Windows 7 and Windows Server 2008 R2 as supported clients in Microsoft Systems Management Server (SMS) 2003 Service Pack 3 (SP3). This compatibility pack helps SMS 2003 SP3 users migrate their software to Configuration Manager 2007 while realizing immediate benefits from their Windows 7 investment.”

Hotfix available here:

http://support.microsoft.com/kb/974014