C:\> IsAdvancedFormat.exe
Enumerate all detect all Advanced Format Drives.
Enumerator: IDE Found: Maxtor 6L160M0
  Physical sector size is 512 bytes.
Enumerator: IDE Found: Maxtor 6L160M0
  Physical sector size is 512 bytes.
Enumerator: IDE Found: WDC WD10EADS-11M2B2
  Emulated sector size is 512 bytes.
  Physical sector size is 4096 bytes.
C:\> @echo %ErrorLevel%
42

Combining WIM files December 16, 2010

Posted by keithga in Uncategorized.
4 comments

I was at a customer site during the past few weeks, and the customer asked about merging WIM files. This company was a Lenovo shop, and they had three main platforms in their inventory, the Thinkpad T410, T410s, and the X201.

For technical reasons that I won’t get into here, we decided to create several Model Specific Fat images that could be deployed using SCCM as-is without loading additional Drivers. Unfortunately, when done we had about 8 images, including two base images that contained their common application suite, but did not contain any extra drivers.

When done we had the following x64 images:

• WIN7ENTX64.base.wim
• WIN7ENTX64.t410.wim
• WIN7ENTX64.t410s.wim
• WIN7ENTX64.x201.wim

Each wim was about 4-6 GB in size, all totaled about 21GB for x64.

WIM files

WIM files are containers that store other files, similar to the way that a *.zip file or a *.cab file stores other files. Microsoft Windows also provides the ability to “mount” Wim files into an existing File Folder, allowing one to Add/Delete/Modify files in the wim.  This causes problems since modifications of the WIM file can cause fragmentation, just like *.vhd files. Windows gets around this by supplying the imagex.exe /export command. This command will allow the administrator to move the content from one WIM file to another WIM file, and in doing so the new wim file will be de-fragmented!

We can use this imagex.exe /export command to move the contents of one Wim file *into* an existing wim file, the cool thing for us is that ImageX.exe will also check to see if the file already exists in the wim file, and will not add the file in order to save space!

Example

In the example case above with the three Lenovo machines and a base image, I decided to start with the base image, and to inject the three other platforms into the base *.wim image:

Imagex.exe /export WIN7ENTX64.t410.wim *   WIN7ENTX64.base.wim “WIN7ENTX64.DDrive.t410″

Imagex.exe /export WIN7ENTX64.t410s.wim * WIN7ENTX64.base.wim “WIN7ENTX64.DDrive.t410s”

Imagex.exe /export WIN7ENTX64.x201.wim * WIN7ENTX64.base.wim “WIN7ENTX64.DDrive.x201″

When I was finished the Base.wim file had increased in size by only 1.5GB, much better than trying to distribute 4 separate *.wim files totalling 20GB

-Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

User Tiles in the Domain October 8, 2010

Posted by Micah Rowland in Uncategorized.
3 comments

In a previous post, I described a solution for handling user account tiles for local accounts. A reader recently emailed me inquiring about user tiles for domain users and I realized that I had failed to cover how Windows 7 handles this and how an IT department could leverage this functionality.

For those of you who have read the previous post, you’ll remember that Windows 7 (and Vista) stores the usertile picture that is displayed on login and on the start menu in the registry buried in the SAM hive. This article assumes you have read the previous one and will only briefly reiterate key points as necessary.

For domain accounts, the story is slightly different. Domain account usertiles are not in fact stored in the registry but in a much more accessible location, C:\ProgramData\Microsoft\User Account Pictures\ . If only local accounts were so easy. But don’t worry, we’ll still have a fun time. The usertile files for each user are saved as DOMAIN+username.dat. For example, John Doe at Contoso would be stored as CONTOSO+jdoe.dat. The contents of this dat file will look very familiar to any of you who have looked at local usertiles in the registry. In fact, the hex data stored in this file is EXACTLY the same as how it would be stored in the registry.

So lets get our plan of attack:

1. Login to a domain account. Any will do.
2. Set our usertile the old fashioned way.
3. Retrieve the generated dat file.
4. Use it!

WAY SIMPLER THAN LOCAL ACCOUNTS!

Let’s take the following scenario posed by one reader. Contoso would like users in each of 5 departments to have a department specific usertile. First we login using a domain account (for our example John Doe will do) and set its usertile to the first department’s desired tile. We then copy the C:\ProgramData\Microsoft\User Account Pictures\CONTOSO+jdoe.dat file to a holding area and rename it to departmentname.dat. We then repeat for the remaining 4 departments. Now that we have the proper dat files we can leverage them in a few different ways. Most users will go the route of the logon script: Check for group membership to ascertain the department of the user (or read an Active Directory attribute) and copy the proper department dat file into the local computer’s User Account Picture directory. We could also preload our OS deployment with a set of all user files for all members of the domain (probably only a good idea in an organization with a small number of users). Using a logon script will ensure that the proper department icon is used, even if a user changes it, though placing a complementing logoff script would be prudent to prevent any non-compliance.

Whatever way you cut it, it’s pretty much up to you at this point. Bon Appétit!

Introduction June 23, 2010

Posted by Micah Rowland in Uncategorized.
3 comments

My name is Micah Rowland and I have been added to the Xtreme Deployment consulting group as an expert in automation and reverse engineering. As we all know, some of the tasks that customers ask of us to accomplish during the MDT process are very simple to do manually, but in the background, are tricky to nail down when we go to automate the same processes.  In my posts, I hope to reveal undocumented aspects to the Windows operating system and show how to develop automation around these processes. Let’s get started!

Assign Drivers to Computer Makes and Models March 11, 2010

Posted by keithga in Uncategorized.
9 comments

Speaking of Make and Models… one of the things I’ve been experimenting with lately is mixing driver management styles (grouping by Make+Model vs PnPID).

 

 

Make/Model Match

Historically, if you had different hardware platforms, and you wanted to install drivers on each type, you would create separate packages for each Make and Model. Then you could query the Make and Model information from the BIOS to determine which package to install.

 

 

For example here are four Make+Model examples:

Make	Model
Dell	D630
Dell	D830
HP	DC7800
HP	DC7900

The disadvantage of this method is that you have to update the driver packages when new Models come along, and it’s also possible that you might keep multiple instances of the same driver package across many Make and Model repositories. 

 

 

 

PnP-ID Match

With MDT, ZTIDrivers.wsf was designed to do things in a different manner. Instead of downloading drivers and grouping them based on Make/Model, you would import the driver directly into MDT, MDT would parse the driver package, and MDT would install the driver package on the machine if the Plug and Play ID matched.

 

 

For example, Windows might search for Plug and Play ID’s that look like:

 

PCI\VEN_1099&DEV_0242&SUBSYS_02429005&REV_01
PCI\VEN_1099&DEV_0242&SUBSYS_02429005
PCI\VEN_1099&DEV_0242&CC_010401
PCI\VEN_1099&DEV_0242&CC_0104
PCI\VEN_1099&DEV_0242&REV_01
PCI\VEN_1099&DEV_0242
PCI\VEN_1099&CC_010401
PCI\VEN_1099&CC_0104
PCI\VEN_1099
PCI\CC_010401
PCI\CC_0104

 

 

 

Generally this system works better than copying based on Make and Model except for a few points:

• You must import the drivers in a correct fashion so MDT can parse the INF files, and so each driver package is a seperate entry (more on importing drivers later…)
• Some PC Makers only certify (support?) a subset of driver versions, so it is possible that MDT may give Windows the latest non-certified version of a driver.
• There also may be compatibility problems with specific drivers. When placed on some other platforms. (However IMHO, if a driver *can* be installed on a machine, but crashes the machine, then that is a bug of the driver).

 

Hybrid Make-Model + PnPID Match Solution

For my MDT environments, I don’t want to place all drivers into Make/Model groupings by default, since I loose the advantages of ZTIDrivers.wsf where it copy by PnPID. For example, I have the drivers for my Dell D620 integrated now, but it’s good to know that I probably have good coverage for any D820′s out there since they share mostly the same components.

 

I’ve seen some MDT implementations that totally throw away the ZTIDrivers.wsf PnPID style in favor of maintaining a manual mapping of drivers to Make+Model. However, I do concede, that there are some drivers out there that “… do not play nicely with others…”, and need to be quarantined somehow, and according to a make+model works well.

 

Create a Folder Structure in MDT Workbench:

Common     Audio     Networking         Intel         Marvel     Storage     Video Dell     Common         Audio         Networking         Storage     D620 Hewlett-Packard     Common     DC7800         Audio         Networking         Storage WinPE

 

 

 

Then in your CustomSettings.ini file, you can add the following: 

DriverGroups001=Common

DriverGroups002=%Make%\Common

DriverGroups003=%Make%\%Model%

DriverSelectionProfile=Nothing

(Note that DriverSelectionProfile=nothing is required if using DriverGroups).

%Make% and %Model% will be auto-expanded in the customsettings.ini file with the Make and Model values from the system BIOS.

• If you have a driver that will work for all Makes and Models, then place it under \Common.
• If you have a driver that is only supported for a single Manufacturer, then place it under \%Make%\Common.
• If you have a driver that only works on a specific Make and Model, then place it under \%Make%\%Model%.

This should allow you to use generic drivers by default, moving drivers to specific makes and models when required.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Water Water everywhere… January 7, 2010

Posted by keithga in Uncategorized.
comments closed

I was walking in through the Lobby of Microsoft building 18 yesterday, and someone came in to tell the receptionist that there was a burst water main leaking in the building. Unfortunately, this is a normal occurrence in Microsoft Building 18. And has happened every year since 2007, and typically localized arround the Microsoft Deployment Toolkit team members.

Luckily, this year, we found most Team Members, and we were disconnecting machines from power before the flood waters came. And were also able to get critical machines out before the moving crews came to cart the equipment out to an undisclosed location during repairs.

For example, here is what the office of Mike Niehaus looked like yesterday.

His entire office is now completely bare, and cleaning crews are doing their thing.

It’s been a crazy start to 2010! Hopefully things will calm down and I’ll start posting more soon.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

How to Know You are Using Scripts from MDT 2010 November 17, 2009

Posted by tmintner in Uncategorized.
add a comment

We’ve had a few emails over the last few weeks where certain variables or actions in the task sequence in MDT 2010 were either not functioning at all or were not behaving as expected.  After looking at the log files, it was pretty clear that a mixture of MDT 2008 boot images were being used with MDT 2010.  So how can you tell if you are using a MDT 2010 boot image?  The easiest way to tell is to look in the bdd.log file.  IN MDT 2010 we added a version line to each of the scripts that are run so if in the first 15 or so lines of the BDD.LOG you do not see this: Microsoft Deployment Toolkit version: 5.0.1641.0 , then your boot images are probably running scripts from MDT 2008.

 

To fix this you would, right click on the DeploymentShare and choose Update.  Then you would choose Completely regenerate the boot images as shown below:

 

Now that your boot images are updated you will either need to burn new CDs or re-import the boot images into WDS

 

- Tim Mintner

Validation: Passing the MDT 2008 Certification Exam November 12, 2009

Posted by keithga in Uncategorized.
add a comment

Took the Microsoft Deployment Toolkit 2008 Certification exam today.

I passed!!!

I’ve been an in-depth Microsoft technical guy for 14 years now, yet I’ve never gotten around to actually taking any Certification test before.

And I figured that since I was on the Dev team for MDT 2008, I’d start with 070-635 (Microsoft Deployment Toolkit 2008, Desktop Deployment). I took the test cold, no studying.

It was kind of weird going back and taking the test for MDT 2008. There have been two product releases since then, MDT 2008 Update 1 and MDT 2010. And I’ve been working on Windows 7/MDT 2010 components now for about a full year.

I’d take some more exams, but I had to pay for this one out of my own pocket. Perhaps in the new year.

Tim Mintner mentioned once that he took this test as well. Which wasn’t really fair, since he helped write the questions. :^)

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

NT SERVICE\TrustedInstaller:(F)
BUILTIN\Administrators:(RX)
NT AUTHORITY\SYSTEM:(RX)
BUILTIN\Users:(RX)