Troubleshooting PXE in SCCM OSD Part 1

PXE booting makes deploying OS images much simpler for end user technicians. There is a lot that can go wrong though, especially if you're attempting to run it in a high security, heavily filtered network.

In the next few blog posts I'll cover how to go about troubleshooting PXE errors in OSD.

When a PXE failure occurs it helps to be very precise with the step it failed at. The place at which a PXE build fails can tell us where to investigate.

Some possible causes of error in a PXE build are-

• Workstation BIOS configuration and/or lack of RAM
  
• Duplicate SMBIOS id (typically seen on older hardware)
  
• DHCP Server configuration
  
• Network filters / configuration
  
• WDS service failure
  
• PXE service point failure
  
• Wrong collection membership in SCCM
  
• WDS cached collection membership
  
• Obsolete objects in SCCM
  
• Network drivers for Vista/7 are available, but not for XP
  
• Network drivers are not available for Vista/7
  

On the server side there's one log file that will help you immensely. If you have set up the PXE Service Point on the site server it can be found at

%ProgramFiles%\SMS_CCM\Logs\smspxe.log

Or, if you have configured another server as the PXE Service Point it will be found at

SMS_CCM\Logs\smspxe.log

in the root of the drive SCCM is using.

Using Trace32 to view this log file can give you realtime information on the PXE boot process. However, the first error we'll look at won't even show up in this log.

PXE-E51: No DHCP or proxyDHCP offers were received

The most common PXE error I see is PXE-E51. The first indication that something is wrong is when you see DHCP... and you get more than three or four dots.



The PXE process fails at this point with PXE-E51: No DHCP or proxyDHCP offers were received.



This error basically says that the machine can't obtain an IP address. Possible reasons for this include

1. Your DHCP server isn't working
   
2. If you use DHCP reservations you may have made a mistake entering the MAC address of this machine
   
3. You don't have a DHCP pool set up for this subnet, or the pool has no free addresses
   
4. Your DHCP server is on a different subnet and you haven't set up an IP forwader or DHCP Relay agent
   
5. The network cable or port is broken
   

Most of these problems are easy to check, or are easy for your networking people to check. Once the problem is fixed the PXE boot process works properly in most cases. Assuming your network is configured to allow PXE booting this error normally means one of two things - the cable is faulty or there's no DHCP reservation/the DHCP pool is exhausted.

This error highlights the need for preciseness in the error reports from your technicians. Since there's so much more that can go wrong at this stage, it's nice to have an error which is relatively easy to fix.

Troubleshooting PXE in SCCM OSD Part 2
Troubleshooting PXE in SCCM OSD Part 3
Troubleshooting the TFTP Service

A History of TechEd Europe in Conference Bags Part 2

Barring any last minute volcanoes I'll be at MMS 2011 next month, so I thought I'd have a look back over some past conferences I've been to. This is a continuation of the conference bag retrospective I started here.

TechEd: IT Forum 2007
13-16 November, Barcelona

SCCM 2007, Bitlocker and lots of security stuff made this a great conference. Well, that and the weather. And the food. And the architecture. And....




TechEd EMEA IT Professionals 2008
3-7 November, Barcelona

The last TechEd in Barcelona, and finally I get to the Camp Nou. A Champions League tie against FC Basel which ended 1-1. Messi scored for Barca, I can't remember who scored for Basel.

The talks from the conference are available online at msteched.com, here are some I'd recommend

Windows Security Boundaries by Mark Russinovich
Advanced Operating System Deployment Part 2 (Part 1 seems to be missing)




TechEd EMEA 2009
9-13 November, Berlin

The last European TechEd I attended was sadly the worst. I don't know what happened in the organisation of this event, but it was terrible in comparison to (at least) the five previous TechEds.

The scheduling was bad on two fronts. The first day of the conference was the 20th anniversary of the fall of the Berlin wall. While it was great to be in Berlin for such a historic event it meant hotel rooms were hard to come by and expensive. The scheduling of the talks was poor too - similarly themed talks either clashed or were at different ends of the conference center. Popular talks were put in small rooms and there were a number of hastily arranged repeat talks.

The Messe conference center was nice, but they obviously didn't have enough room. Corridors were packed during transitional periods and some rooms didn't even have four walls. Some of the rooms had a curtain separating the auditorium from the corridor making it difficult to hear the speaker.

Bottled water was no longer available, instead provided by water coolers. Unfortunately there were no cups and they didn't have enough water bottles to supply with the conference bags.

Berlin as a city was great (I'd recommend the currywurst if you're visiting).

It's a pity the conference organisers had a nightmare.

A History of TechEd Europe in Conference Bags Part 1

I'm off to MMS 2011 next month so I thought it would be fun to look back over the Microsoft conferences I've attended in the past. I've dug out the old conference bags from on top of the wardrobe - excuse the dust!

TechEd Europe 2004
29 June - 2 July, Amsterdam

Held in the Amsterdam RAI, this was the first major conference I attended. Some of the key topics covered were the additional security features of XP SP2, Windows ACS (which ended up in SCOM) and running Server 2003 on 64-bit hardware.

Sadly, the conference bag was possibly the worst ever conference bag in the history of conference bags. A bright orange courier bag with a special hook to hold your drum(!). I'm assuming the orange was to help you remember you were in the Netherlands, and the drum... believe it or not, the drum was handed out as part of the keynote. It was fun coming back through customs with this.



TechEd Europe 2005
5 - 8 July, Amsterdam

Again held in the Amsterdam RAI, the big topics in 2005 (for me) were WSUS, LTI and ZTI with BDD and security.

Looking at the bag, it would appear that SQL Server 2005 was a big deal this year. The bag seems a bit conservative compared to 2004!



TechEd: IT Forum 2006
14-17 November, Barcelona

The IT Forum and TechEd events merged in 2006 and TechEd: IT Forum was born. The conference center in Barcelona was excellent, but not quite as good as the RAI in Amsterdam.

I went to a lot of talks about Vista. This was sadly a waste of time thanks to the pain that was/is Volume Licensing 2.0. The original Reduced Functionality Mode in Vista made it impossible for us deploy Vista - we weren't prepared to take the risk that someone's workstation may end up a glorified web browser. Security talks were high on my list again this year - they were not only useful, but helped with the CISSP CPE credits!

A simple check to see if the TPM is enabled

The Deployment Guys have an interesting post on how to check if the TPM chip is enabled and activated as part of a task sequence (see here).

When we deployed Windows 7 we ran into the same problem. Our solution was a bit simpler!

Connecting to root\cimv2\Security\MicrosoftTPM and executing

select * from win32_tpm

will only return a value if the TPM is enabled. This can be added as a condition in your Task Sequence so that your Bitlocker steps only run if the TPM is on.



A note of caution though - this query does not check whether the TPM is activated. It only checks that the TPM is enabled.

Manually update Forefront Endpoint Protection and Client Security

Sometimes in FEP 2010 and FCS you need to force a signature update. There are two ways of doing this. Firstly, Microsoft supply a download of the latest signatures at this link

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

The package you download can update both FCS and FEP 2010.

To manually start the signature update from the client software run

MpCmdRun.exe -SignatureUpdate

In FCS you should therefore run

C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\MpCmdRun.exe -SignatureUpdate

In FEP 2010 you should run

C:\Program Files\Microsoft Security Client\Antimalware\MpCmdRun.exe -SignatureUpdate

On Windows 7 you should run MpCmdRun.exe with elevated privileges or from an elevated command prompt.

Don't forget that because the path to the executable contains spaces you'll need to use quotes if run in a Run Command Line step in a Task Sequence.

Why does this MSI keep reinstalling?

Packaging up applications is one of the key tasks for anyone working with OSD. Creating software packages can be pretty easy, especially if the app is supplied as an MSI. Most of the time it's as simple as running something like

msiexec /i Setup.msi /qb ALLUSERS=1

Occasionally though, you'll run into problems. We had an app that seemed to install successfully. However, each time the app was run, the MSI ran through some checks and appeared to try to repair the app.



After a bit of digging it turned out that the problem was being caused by an advertised shortcut. Each time the app was run, the advertised shortcut kicked off an auto-repair, even though the app was installed successfully. The quick (and probably nasty solution) was to install the app without the advertised shortcut

msiexec /i Setup.msi /qb ALLUSERS=1 DISABLEADVTSHORTCUTS=1

In situations like this it's probably better to return to the vendor and ask for a working MSI, or to use a tool like Orca to discover what is causing the auto-repair to kick in.

XP Mass Storage Drivers on Toshiba Laptops

A common way of installing Mass Storage Drivers for XP is to add a condition in your Task Sequence to query the Model of the machine and apply the relevant driver. The Deployment Guys have a great post on how to do this here.

The basic idea is that you have a step in your task sequence to apply (for example) the Intel(R) PCHM SATA AHCI Controller 4 Port driver.



On the options tab you would have a number of WMI queries which identify the machines that need that driver. In this example you'd probably see things like-

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Satellite Pro L500%"
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Satellite Pro U500%"
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Latitude E5410%"
SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Latitude E4310%"




Unfortunately this type of driver application assumes that there is one chipset per model (in the above example, the Intel HM55 Chipset). This is not always the case. Take the Toshiba Tecra A11.

Some Tecra A11 models have the Intel HM55 chipset. Some have the Intel QM57 chipset. On both models, running the following code would return TRUE-

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "%Tecra A11%"

So, how do you identify the revision of the Tecra and therefore the chipset, in your task sequence? You need to query for the partnumber instead of the model. Toshiba store the partnumber of the laptop in Win32_ComputerSystemProduct. In this case the following code would return true for the Tecra A11 with an HM55 chipset-

SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTSE0E%"




Here are the SELECT statements to use for some of the other Toshiba laptops in the current range.

Toshiba Tecra A11 (Intel HM55 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTSE0E%"

Toshiba Tecra A11 (Intel QM57 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTSE1E%"

Toshiba Tecra M11 (Intel HM55 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTME0E%"

Toshiba Tecra M11 (Intel QM57 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PTME1E%"

Toshiba Portege R700 (Intel HM55 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PT310E%"

Toshiba Portege R700 (Intel QM57 Chipset)
SELECT * From Win32_ComputerSystemProduct WHERE Version LIKE "PT311E%"

So, adding the Toshiba HM55 models to the above example would give us this

Using DISM to fix a broken Windows 7 image

The best way to create your gold image is by running a build and capture in a virtual machine. The reason for this is that you don't get extra drivers hanging about in your image.

One of our team accidentally created a fresh image on real hardware. This image worked fine on most models, but failed on a Toshiba Tecra A11. After a long investigation it turned out that the image contained an old Intel network driver that would not work on the Tecra. Even though we had the new driver in our driver store, the Tecra would always choose the driver in the image. Not having a working network driver during OSD is a bit of a problem!

The solution is to use DISM to remove the drivers from the image*.

First of all, make a copy of your image and work on this copy. Once you've done this you need to mount the image. From an administrative command prompt run the following commands-

mkdir C:\mountfolder

dism /mount-wim /wimfile:yourwimfile.wim /index:1 /mountdir:C:\mountfolder 

Once the image has been mounted, run the following

dism /image:C:\mountfolder /get-drivers 

This should show you all the extra drivers that have been added to your image. The drivers will be listed as oem1.inf, oem2.inf and so on. Here's the sample output from an image I recently had to edit-

Deployment Image Servicing and Management tool

Version: 6.1.7600.16385

Image Version: 6.1.7600.16385

Obtaining list of 3rd party drivers from the driver store...

Driver packages listing:

Published Name : oem0.inf
Original File Name : prnms001.inf
Inbox : No
Class Name : Printer
Provider Name : Microsoft
Date : 21/06/2006
Version : 6.1.7600.16385

Published Name : oem1.inf
Original File Name : prnms001.inf
Inbox : No
Class Name : Printer
Provider Name : Microsoft
Date : 21/06/2006
Version : 6.1.7601.17514

Published Name : oem2.inf
Original File Name : sthda.inf
Inbox : No
Class Name : MEDIA
Provider Name : SigmaTel
Date : 09/08/2005
Version : 5.10.4647.0

Published Name : oem3.inf
Original File Name : sthda64.inf
Inbox : No
Class Name : MEDIA
Provider Name : SigmaTel
Date : 09/08/2005
Version : 5.10.4647.0

Published Name : oem4.inf
Original File Name : b57nd60a.inf
Inbox : No
Class Name : Net
Provider Name : Broadcom
Date : 02/12/2010
Version : 14.4.2.2

Published Name : oem5.inf
Original File Name : k57nd60a.inf
Inbox : No
Class Name : Net
Provider Name : Broadcom
Date : 02/12/2010
Version : 14.4.2.2

The operation completed successfully.

To remove, for example, the Broadcom k57nd60a.inf driver, just run the command

dism /image:C:\mountfolder /remove-driver /driver:oem5.inf 

You should see dism reporting success

Found 1 driver package(s) to remove.
Removing 1 of 1 - oem5.inf: The driver package was successfully removed.
The operation completed successfully.

Once you've removed the drivers you want, unmount the image and commit the changes

dism /unmount-wim /mountdir:C:\mountfolder /commit

And that should be that. Create a new OS install package and test your image. Once you're happy you can use that image instead of the original.

*Of course, the real solution is to recreate the image in a VM, but that's not always practical!