Latitude E5420 - Broadcom 57xx network card issues during SCCM OSD

Question

I apologize if this question has already been posted to the community, the search function was down, and I did not see any similar posts in the first 10 pages or so of threads.

I'm having an issue when deploying Windows 7 x64 with SP1 on the Dell Latitude E5420. The issues arises in both the Windows Installer Package and Windows Captured Installer (wim file) methods, but in different locations. Neither of these issues exist with 32 bit installations.

Windows Installer Package: (From original Windows installation Source.)

The Broadcom network card stops functioning shortly after the applying device drivers phase, and causes the system to fail shortly after the setup windows and configuration manager phase starts, specifically the second half part that installs the files needed for configuration manager. Since the network connection is lost, the system aborts with an 0x80007002 (file not found) error message.

What I think is happening from monitoring files and driver locations during different tests.

System boots into Windows PE 3.1 x64

1. Formats and sets up drive.

2. During the driver scan, SCCM picks up both the driver imbedded in WinPE 3.1 x64 and that applied using an Auto Apply Driver and category list. The driver installed into WinPE has varied from no drive at all, other than the embedded monolithic driver, version 10.85.0.0 (same one as Windows PE) 10.100.4.0 (same driver used by Windows), and (15.0.0.21) the latest version. All with no success. This may be an issue that the driver is not truly plug and play. I'm not sure and probably need to contact Broadcom for more information on how the x86 and x64 drivers differ in how Windows setup.exe program handles them.

3. I have extracted the contents of install.wim from the Windows 7 SP1 x64 DVD and determined that the embedded Broadcom 57xx driver is the 10.100.4.0 version. Have pointed SCCM to this file and injected it into the Windows PE x64 environment, but no success.

4. I have injected the install.wim file with multiple version of the driver, again ranging from 10.85.0.0, 10.100.4.0, and 12.0.0.2, 14.4.2.2, 14.4.2.4, and 15.0.0.21. In each case, I modified my WinPE environment to reflect the same driver as I was using in the install.wim file.

In all cases, the network card does not initialize until after the system reboots, however, the needed files for SCCM client installation at the end of setup.exe will fail because the network connection is lost.

Note: I have used both the AutoApply Drivers and Install Driver Package methods and familiar with the differences and where to use them. AutoApply drivers has always used a targeted category with only the specific drivers being tested included. In both cases, necessary general drives are also included, but have been the same in all tests.

Windows Captured Installer (wim file)

This method completes the setup windows and configuration phase just fine. However, the lack of network connection causes the Apply Network Settings phase to fail as the network connection is not valid, probably for a similar reason as above. Again, upon reboot, the system has network connection again and functions correctly. Similar as above tested with multiple version of the driver.

I'm not sure if most of this is related to issues with the Broadcom network driver and hardware. I have read a lot about issues with Broadcom network cards not being able to be installed during the running of Windows setup.exe phase, and have even used customized unattend.xml files to attempt to inject drivers for a two-tier network device like these cards.

DELL-Warren B · Answer

This doesn't sound like an issue with WinPE since you are getting to the Apply Driver phase. I would focus on the driver packages that are being applied or the drivers that are available to Auto-Apply. I would look for extraneous 32-bit drivers that may be available to Auto-Apply or are in your 64-bit driver package.

Are you using the Dell Driver CAB for the E5420? It has the driver files prepped for consumption by ConfigMgr.

en.community.dell.com/.../latitude-e5420-windows-7-driver-cab.aspx

tdanzer · Answer

I'm using the Dell Driver CAB for the E5420 (A05), and I have applied different variants with respect to the networking drivers. I keep a base and then test variant. I have used both the Auto Apply and Driver Package methods within SCCM deployment with multiple tests of different versions of the driver. I also have categories setup, so I'm able to adjust things for the Auto Apply drivers phase fairly quickly during testing The consistent problem is that the network driver requires a system reboot to function correctly, even if the driver used in WinPE x64 matches the driver in Windows 7 x64 SP1.

Also, not sure why this is only impacting 64 bit installs, they pull the same set of drivers, mind the correct versions for each format, so 64 with 64 and 32 with 32.

Something I have not tried, and would be interested in hearing from the community. Is there a way to modify the Windows installer in such a way that you could force a reboot prior to the installing of the SCCM client without causing an access denied error (0x80040005) within SCCM task sequences?

Feel free to go pretty technical on things too, I'm comfortable with pretty advanced Windows installation methods, driver installations, and things of that nature.

justinmglc · Answer

I'm actually having the same problem, but with a HP 6530b which has the Broadcom NIC in it. Did you ever find a solution?

I thought about forcing a reboot (somewhere) in the task sequence, but there's nowhere really to put a reboot in prior to it failing. Unless we do a reboot after Applying Device Drivers, but it doesn't fail there - it fails halfway through installing Windows, as you said.

Bit annoying.

tdanzer · Answer

I have unfortunately been unable to find a resolution to this problem. I have been in contact with Broadcom, and they suggested removing their drivers from WinPE, however, testing has yielded the same results. The most recent driver, 15.2.0.5b works on older OptiPlex 745 series systems. There seems to be small differences in how the driver applies to 57xx series vs the NetXtreme Gigabit version.

I have thought about modifying the offline install.wim file of Windows 7 x64 SP1 to remove all Broadcom drivers and then only apply the ones that I want, but I'm uncertain if this will work. Imaging results showed that the latest driver is being applied during Windows setup. So I know that part functions correctly within SCCM and Windows setup.exe.

At this point, I am just using a USB key with full media and applying everything that way. Not the most glamorous solution, but it gets the job done. I had to design a special task sequence making sure that I had the drivers apply as driver packages and not an auto apply drivers step, since I cannot use driver categories during a full offline installation.

justinmglc · Answer

Hi,

Thanks for that. We have way too many devices with Broadcom cards to use full media, not to mention that our images are pretty fat.

I've also just discovered that some Marvel Yukon cards do the same thing. The NIC will stop working shortly after the finialisation of Windows installation, thus causing the task sequence to fail.

I'm going to keep seeing if I can find a solution.

Very frustrating, I'm sure there must be more people having this problem somewhere.

justinmglc · Answer

Hey,

We got a bit further with this. After reading the following:

blogs.technet.com/.../nic-devices-that-require-a-special-driver-for-winpe-may-cause-a-configmgr-task-sequence-to-fail-if-a-vista-or-newer-os-is-being-deployed-via-an-operating-system-install-package.aspx

and

allthingsconfigmgr.wordpress.com/.../how-we-love-broadcom

I tried injecting the drivers right into the install.wim - with no luck. I didn't try with the capturing of the image from a machine that didn't have the card, but by my understanding one of our custom images that was also failing was definitely captured on a device without the Broadcom card.

I also noticed that, on top of that, some of our devices with Marvel Yukon NICs had the same issue. Perhaps they are related in the NIC world.

The solution?

HP has a tool that you can use where you specify a list of machines that you use, and it will download all the drivers for that machine. It then builds a database. You dump all those drivers on a network share, run the utility, and it will install the drivers automatically. The key to this is disabling the 'Apply Device Drivers' step, and then running that utility after Windows has installed, as part of the rest of your install application steps in the task sequence. This means that instead of injecting the drivers into the install (or custom) image, it'll install them to Windows.

I'm not sure if DELL has a similar tool, but it'd be worth a look?

Good luck..!

Dustin Hedges · Answer

The way I get around these Network driver issues is I actually create a "Common Network" drivers package (with corresponding Category) and all of my network drivers are actually imported into SCCM. I then do a Auto Apply Drivers step immediately after the "Apply Network Settings" step.

This will then inject the appropriate network driver and be ready for use right away, without having to use a software installer. This step is ran for all systems, regardless of model or OS. Just lets the OS pick the right driver to get things moving along.

-Dustin

Enterprise Client

Latitude E5420 - Broadcom 57xx network card issues during SCCM OSD

Was this post helpful?