MDT: Installing Windows 7 Updates as Packages

This is a really nice feature that MDT has allowing for all updates to be installed during the initial windows setup process. The problem is that certain updates will not install and cause the Install Updates function to fail, thereby halting the build. You will see the message Windows could not apply unattend settings during pass [offlineServicing]. The only way to resolve this is to remove the updates that caused it to halt.

The best way to locate the updates causing the problem is to create a structured package group. The way I setup my company's was to create the following structure:

1. Windows 7 Updates
1. Pre-Image Updates
1. Non-Security Updates
1. 2009
2. 2011
3. 2012
4. 2013
2. Optional Updates
3. Security Updates
1. 2010
2. 2011
3. 2012
2. Post-Image Updates
1. Non-Security Updates
2. Optional Updates
3. Security Updates

This gives an easy, sorted structure for the updates, which also allows you to find and remove those updates no longer needed after a service pack is installed. Plus, it allows you to activate/deactivate smaller sets of updates through the selection profile, thereby making narrowing down to the bad updates much easier. You might wonder where I got this structure. I use Windows Updates Downloader to download all of my windows updates and it uses this structure  I can verify that it works out great. This also allowed me to more easily find those updates that caused the build to crash during the offline installation. As far as associating them with a task sequence, all you have to do is check-mark each folder to be included in the selection profile, allowing all of the folders to be installed under a single task sequence. 

As far as the list of updates I found to halt the build of Windows 7 64-Bit with SP1, here it is:

• KB2496898
• KB2533552
• KB2604521
• KB2726535

Once I removed these updates, the offline update worked flawless. I did not bother trying to get these updates back in the system. I allow WSUS to install them.

Read More

ERROR, application GUID not found in application list

If your MDT build give the above error at the end of a build, the issue is more than likely caused by a residual GUID left over in another application's dependencies, in which the dependency was deleted.

To fix this, you will have to edit the Applications.xml file within the control folder. I highly suggest opening this file up with XML Editor 2007. It makes editing an XML a snap. Once you have the XML editor open, do a ctrl+F and type in the GUID from the error screen. Click Find Next.

Once it finds the GUID, it will expand the element as shown here:

You now click on the Dependency folder associated with this GUID and delete it. Be sure to search again for the same GUID as it might be in multiple locations as shown here:

You do the same thing to delete this GUID out. I also did the same from the second error listed above.

NOTE: Make sure you backup the Applications.xml file before editing it!

Read More

Multiple Naming Schemas in the customsettings.ini file

It is nothing new that you can setup MDT or SCCM to automatically create the computer name via the customsettings.ini file. This is a sample I used from a forum on the net:

[ByLaptopType]

Subsection=Laptop-%IsLaptop%

[ByDesktopType]

Subsection=Desktop-%IsDesktop%

[Laptop-True]

OSDComputerName=LT%SerialNumber%

[Desktop-True]

OSDComputerName=DT%SerialNumber%

The problem comes when you also have a SQL database that custom names the computers too. In the scenario I work in, we normally name our computers DT%SERIAL% or LT%SERIAL%. There are exceptions such as our shared and training systems that have unique names I defined in the SQL database. The OSDComputerName variable is first come, first serve. The first thing to put a value in it will be the only value it will accept. Therefore, you will need to rearrange the setup of the Priority field. For my scenario, I re-sequenced the Priority field to first query the SQL server and then do the ByLatopType and ByDesktopType. If it is one of our unique systems being imaged, the value in the SQL database gets assigned first and then the standard name is read in the ByLatopType and ByDesktopType, but can't be written over the SQL injected value. 

This was the original setup of the Priority field:

Priority=ByLaptopType, ByDesktopType, CSettings, CPackages, CApps, CAdmins, CRoles, Default

This is the rearranged setup that works perfectly:

Priority=CSettings, CPackages, CApps, CAdmins, CRoles, ByLaptopType, ByDesktopType, Default

Read More