How We Love Broadcom

Deploying operating systems from my experience goes two ways, really simple or a right pain. This posts explains the issues faced when deploying Windows Server 2008 R2 SP1 to hardware with the Broadcom NetXtreme II network card.

I would like to just start by saying I have nothing against Broadcom, I have never come across this issue before when deploying operating systems which made the errors I was experiencing pretty strange and difficult to understand.

So what is the problem? It seems that when you are deploying to a Vista or newer operating system via the source files (Operating System Install Package) and the network card requires a special driver that the task sequence may fail during the Setup Windows and ConfigMgr phase.

When I checked the smsts.log file I was getting an error which led me in totally the wrong direction. I traced the error back to the following line:

Unspecified error (Error: 80004005; Source: Windows)

This error made me look down the network access account route which was strange as literally a minute before I was getting content from the network with no problems at all. This only started happening after the Server 2008 R2 SP1 mini setup. I did however wonder what I was missing, I had a look around and not found anything so I decided to save the log file on the site server so I can look at the log in CMTrace.exe. However, hold on a minute, network not found? I ran IPConfig and saw that I had no IP address. While I had not resolved the issue I had found the root cause.

A bit more digging into information lead me to find information about a problem which existed when using the Broadcom NetXtremeII GigE network card. My specific chipset was the 5709 in this instance. I was amazed to find that due to the nature of the card and the advanced features which were on the hardware was causing my Task Sequence to fail.

When either the Apply Driver Package task or Auto Apply Driver task is included as part of an SCCM 2007 OSD Task Sequence that is deploying an Operating System via an Operating System Install Package (Windows installation source files), the task sequence will automatically generate and/or add to an unattend.xml file specifying for the drivers to be installed during the windowsPE phase.

The problem with installing NIC drivers that are different for WinPE vs. the full Windows OS is that attempting to install such drivers during the windowsPE phase will cause network connectivity in WinPE to stop working and fail. This occurs because the incorrect drives are “reinstalled” while still in WinPE.

Resolution

Now we know that we have a problem with how the driver is applied what can we do to resolve this? First of all it seems these are the affected chipsets on the NetXtremeII:

  • 5706
  • 5708
  • 5709
  • 5716

I can see two ways to easily resolve this issue.

  1. Inject the driver into the install.wim in the source files using Dism.exe, update your distribution points and then off you go, I can see how this would work but I haven’t tried this method to prove this.
  2. This method I did try and it worked! Capture the image on hardware which doesn’t have the affected network card.

Method two works because drivers are injected directly into the driver store in Windows when we apply using a captured images rather than the source code. I tested this after capturing with my Dell PowerEdge R710 with a driver package with the affected driver included and it worked a treat! A really strange error but I hope sharing will make people resolve this issue quickly.

Advertisements

Tags: , , , , , , ,

About Martyn

Martyn is one of the Senior Cloud Architects and DevOps Team Leader at one of the worlds leading Cloud Transformation Specialists Inframon. Martyn is responsible for the architecture of some of the largest Azure deployments in EMEA and is a advisor to a many businesses on their strategies. Martyn is a regular speaker at Microsoft events and community events on Azure and DevOps, giving his insight to a growing number of audiences.

Trackbacks / Pingbacks

  1. Stone H67 Capture Task Sequence | All Things ConfigMgr - January 15, 2013

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: