I'm having a problem sometimes with Lenovo computers that have Realtek 8167 NICs onboard. What happens is that I'm able to complete some but not all of the Task Sequence. If I recall correctly, after installing the ConfigMgr client SCCM reboots the computer to complete the task sequence. After this point, suddenly the NIC no longer works, even though it is present in the boot image and on a driver package. The error that I see in the log file is "No valid network adapter found." It seems like this problem doesn't always occur, although we just imaged a few comps with this NIC and every one had the same error. The task sequence apply drivers step is set to "Install only the best matched compatible drivers." I'm a little reluctant to use the other setting (all compatible drivers) because this is the right driver for this model computer. Is there a log file or somewhere where I can perhaps see more detail on what might be happening? Has anyone else run into a similar problem? Thank you for your help!

It's better to use a driver package instead. Then you have control on which driver are used. In this case you probably don't have the right nic driver.

I did a little more troubleshooting and this is what I've discovered: The driver in question shows up as Realtek PCI GBE Family Controller version 7.37.1229.2010 This driver was already imported in both the 32-bit and 64-bit versions, and is in a driver package that is on a distribution point. There was another 32-bit copy of this driver imported into SCCM, with the same version, that wasn't in a package on a distribution point. I'm not sure how I can have multiple copies of the same version in SCCM (shouldn't SCCM have refused to import a duplicate driver?), but I can't see anything that indicates that they are different. I put the package on a distribution point. I reimported the drivers from Lenovo's site for this model, and SCCM found that everything had already been imported except for a 64-bit version of this driver. However, the 64-bit version is the same version number as the already imported 64-bit driver (7.37.1229.2010). Is it normal to have multiple copies of the same versioned driver? Even the version date is the same.

What I ended up doing was creating a driver package with just this specific driver and adding it in a step before the general auto-detect drivers step of the task sequence. I wish that I could find out why this driver doesn't get picked up automatically in the usual auto-detect step, but I have no idea how to figure that out.

many vendors are unfortunately rather poor on creating correct driver and inf files for the driver and therefore it isn't always that the pnp detection finds the best driver. The best way to apply driver is with driver packages.

Patissiere, It is not the best practice to "Auto Detect" or "Apply Device Drivers". The best way to do this is create a driver package with the hardware specific drivers and use a WMI query in the options tab of the "Apply Drivers Package" to install specific drivers. Here is how I do mine : Create a new drivers folder, import the hardware specific folder and rename it for that model. Create a driver package. Distribute that package. In the OS Task Sequence create a "Apply driver package". Choose the driver package you just created, MAKE SURE you check the "Do unaattended installation of unsigned drivers on versions of Windows where this is allowed" (maybe this is your problem and why the NIC driver isnt installing). Goto the option Tab and add a condition "Query WMI" and in the box copy the following : select * from win32_computersystem where model like "0401%" Except te "0401%" will equal your system. You can get the model either off the little sticker on the case or with the OS booted open a command prompt as admin and type the following : wmic computersystem get model Should see atleast 2 lines, first line saying model, second line, in my case currently, will show the model number 5049D4U. Hope this helps.

Thank you all for your help. I didn't realize that it wasn't a best practice to auto detect -- sadly, that's a feature of SCCM that I really liked. But I guess that it's not reliable when vendors don't make their driver inf files the best (I just had a problem with another driver due to this). From here on out I'll use driver packages and WMI queries. Thank you again.