Deployment Solution

I'm having difficulty loading WinPE preboot drivers for my PXE environment. The model PC is a Dell Latitude E6420 with an Intel 82579LM Gigabit Ethernet Controller. I have tried to follow the advice given in this similar thread carefully:

https://www-secure.symantec.com/connect/forums/unable-load-preboot-automation-drivers

I've attempted adding the drivers using both the SMC and the BDC - I'm sticking with the BDC, as that way seems to "work" better than the console. I have downloaded the latest Vista drivers for the 82579LM from the Dell website, both 32 and 64-bit. I've also tried drivers from Intel. The BDC reports that the drivers have been added successfully, but after I recreate my preboot environments, my boot into WinPE still fails with the message:

Restarting DHCP client service: retry 1...

Restarting DHCP client service: retry 2...

After importing my drivers using the BDC, I can see them located at C:\Program Files\Altiris\Altiris Agent\Agents\Deployment\Task Handler\bootwiz\Platforms\Winpe2\x86\Drivers\CUSTOM\Drivers; there's an E1c6032 folder there.

In automation, however, when I browse to X:\Windows\System32\DriverStore\FileRepository, I do not see the INF file for my driver. If I load the Vista driver from USB flash drive, however, using the drvload command, the driver works and I get an IP address. Where do I go from here?

One thing that concerns me - in my attempt to load the correct driver, I may have added a few drivers that don't work as well. I'd like to remove those just to make sure they aren't getting in the way. In my folder:

 C:\Program Files\Altiris\Altiris Agent\Agents\Deployment\Task Handler\bootwiz\Platforms\Winpe2\x86\Drivers\CUSTOM\Drivers

I have the following subfolders:

E1c6032 (Vista driver)
E1c6232 (Windows 7 driver)

I don't know if the E1c6232 driver is contributing to my problem, but I know I just added it and it doesn't work. If I delete that folder, will that remove the driver after I recreate my preboot environments? If not, how do I get rid of it?

Thanks all!

I should add - when I look for my drivers in the Symantec Management Console, I don't see my newly added drivers, either. In fact, I don't see very many WINPE network boot drivers at all. See the attached pic; those are ALL the WINPE drivers I see. All others are Linux. That doesn't seem right, does it?

Dustin,

This indicates there is an issue really present as we see the other thread also mentioned about the same and  we are investigating on this.

In the Console as you mentioned you have very few WinPE drivers and others are for Linux , that is really doesn't seem right , as in DS 7.1 default driver database for BDC has around 198 drivers (both Linux and WinPE) please check if you have those many.

About the deletion of the drivers from BDC , At present it is not possible to delete the driver form the BDC driver database , By deleting the folder from the mentioned location will not really delete the driver.

You can help us debugging this , please provide the bootwiz.log (From :NS_Console\Deployment\Task handler\Bootwiz)

Dustin,

Can you also provide the driver.

I had this problem with Dell Latitude E6520 laptops w/ 82579LM NIC. The drivers would show in the physical folder location but not in the NS, as you described. My solution is as follows:

1) Download OLD Intel PRO Gigabit drivers - v16.0 - for Vista

• We download the Vista version because DS7.1 boots a WinPE2 environment. Windows 7 drivers mostly support WinPE3 and WinPE3.1 (Windows 7 SP1)
• Later Intel driver packages do not support WinPE2
• Intel forum discussion on this issue

2) Load the drivers into your Preboot DriverDB and rebuild the PXE image

After loading every driver I can think of, the v16.0 worked. I also noticed that Dell posted a WinPE Driver Pack for the E6520 yesterday (7/27/2011). There may be one for your model. You may have luck with that, as I haven't had a chance to test it. Let me know how it goes.  Thanks

Dustin,

Thanks for the log file and driver.

As i have already mentioned there is no way by which you can delete the preboot drivers, i wounder why the drivers from your preboot database has been removed !

Just to confirm if it is a UI issue can you check the driver list at :

<NS_Server>\NSCap\bin\Win32\X86\Deployment\Temp\Drivers\prebootlist.xml

Also verify the drives directory at : <NS_Server>\Deployment\Task Handler\bootwiz\Platforms\Winpe2\x86\Drivers\std\Drivers and for x64 <NS_Server>\Deployment\Task Handler\bootwiz\Platforms\Winpe2\x64\Drivers\std\Drivers which has a default 40 and 36 driver directories (shipped by Symantec)

f these are intact then all default drivers are present but there is some problem with the Driver managers UI.

Dustin,

I checked in my default installed DS 7.1 in the Driver manager Preboot console it has around 24 windows drivers and rest linux drivers.

I have several comments...

1) You can add drivers either through the console UI of the bootiwz UI.  If you use the bootiz UI, and if you have multiple task servers, then you must either add them to bootiw on the main SMP server (and they should then replicate to the other task servers from there - after some period of time of course - nothing is instant in SMP), or you must add the drivers to bootiw on all task servers.  From the SMP console UI you can add multiple drivers at once, but the bootwiz UI is limited to one driver at a time.

2) You CAN delete bootwiz drivers, but there is no UI for this.  Just do as you mentioned, and find the driver in the bootwiz\platforms\winpe2\x86\drivers\custom\drivers (and/or x64), and delete the directory for each driver you want to delete.  Each driver is stored in a separate directory.  Note the same comment about multiple task servers as in #1 above also applies.  I think that the delete will also replicate to the other task servers, but its fairly easy to delete the driver on all task servers as well.

3) There is a bug in bootwiz that has been fixed for the nexst release, that causes the driver list in the SMP console to be empty in certain cases.  This is caused by a driver that has its vendor and device id information in the driver .inf file, in a format that bootwiz is not designed to be able to parse.  This is generally for drivers that are not PCI bus based, such as USB based drivers.  Once such a driver is added to bootwiz, then when it prepares the driver list to be displayed (in the prebootlist.xml file), this driver causes an XML tag to be missing from the file which makes the XML invalid, and then the XML parser in teh console cannot read the XML driver list properly, and it comes up empty.

This only affects the driver list output in the SMP console, and does not affect the driver list in the bootwiz UI itself.

It also does nto affect whether the drivers are added to the boot images or not either - the drivers will still be added to the boot images properly.

4) This is also a bug in bootwiz that has also been fixed for the next releae, that sometimes causes not all of the drivers to be listed properly in the UI.  This affects the SMP conosole output, and may also affect the bootwiz UI as well.  But this also does not affect the boot images - all the drivers are still added to the boot image properly.

5) I have looked at your bootwiz.log, and I can see the many operations that you have performed.  Its not that difficult to figure out if you want to look at it as well.  I can see that you added a whole bunch of drivers through the console UI, and some from the bootwiz UI.  Many of the drivers appear (from their file names) to be duplicates, but just stored in separate directories, probably for each different system type that you have.  I can see that in many cases when a duplicate driver was added, that a low-level directory move operation failed, with error 78.  To add a driver, the driver is passed to one of Microsoft's WAIK tools (peimg.exe) to add the driver to a temporary staging area.  If that is successful, then the driver directory that was added is moved to the bootwiz "custom" folder, so it can be used for all boot images.  It is this move operation that is failing.  It may be failing because there is already a directory by that name from an earlier driver add operation for the same driver, but I haven't seen this happen before myself.

The odd thing is that later on when a boot image is created, these same drivers that had a low-level directory move failure when they were added, again fail to be copied into your boot image as well, and again because of a low-level file copy operation.  This is odd becuase you would think that if the driver was not added properly, then it would not be there to cause a problem when the boot image is created later on.

It almost seems as though there is some sort of directory corruption for some of these drivers, but I'd rather blame the software than blame a corrupt disk.

What I would do, is go to the custom drivers folder on the disk, and clean it up by removing any directories that don't look good.  Each driver directory should have at least a .inf file, a .sys file, a .cat file (which is probably not needed), as well as a .txt file (which bootwiz creates when the driver was added).  Thes could be other files as well, such as .dll files, but not all drivers have or need these.  If you find a driver that doesn't have these minimum files, I would delete it.

I also checked my list (DS 7.1) and I have 32 (I have added a few custom) WinPE2 drivers and the rest are linux drivers.

Hmm, for some reason I got unsubscribed to my own post, so I didn't see any of these responses coming in. I will do as you suggest on Monday, when I'm in the office next. Thanks!

Well, this is scary. I just had a preboot drivers issue not too long ago. I hope this isn't going to become a regular occurrence.

https://www-secure.symantec.com/connect/ko/forums/ds71-all-my-windows-preboot-drivers-are-gone

Drivers and bootwiz.log are attached. Thanks!

Attachment(s)

BootWiz.log_.txt   2.61 MB 1 version

Intel825xx.zip   644 KB 1 version

Hi, ive the issue, that my DirverDB list in the webconsole shows nothing.
i was looking for the prebootlist.xml file in the temp Folder but both is missing.
<NS_Server>\NSCap\bin\Win32\X86\Deployment\Temp\Drivers\prebootlist.xml
I cant add any Driver to the Dep.Anywhere DB and i cant add to the preboot section.
Has anyone an idea, how i can recreate the xml file?? It's important.. Thanks!

Greetings Sebastian

Sorry - I don't have time to test this right now. Has anyone else tried this, and can anyone verify that it works? I will try it ASAP, but not sure when that will be. Given how many people are having problems with this NIC, it would be nice if someone could chime in one way or another.

The newest drivers were out, so I installed them.  I have not had any issues with the 990 or E6420's thus far.

I may be lucky that it was after the newest driver dropped that I did the NS install......

readzzz - Which specific drivers did you install for the E6420's that are working for you? I don't see any new ones listed on the Dell website. Thanks

A support call into Symantec fixed my Intel 82579LM NIC issue. The problem was, after upgrading to MR1, I was unable to recreate any PXE boot images. I was still using the ones from prior to the upgrade. Bootwiz.exe just simply failed to kick off when trying to Recreate an existing boot config, or by trying to create a new one. (I think I mentioned either in this thread or another that I had very few Windows PXE boot drivers listed in the console, only Linux ones. The upgrade fixed that issue, but never recreated my boot configurations.)

The support engineer had me stop SBS services, then delete the files located at \\sbsserver\Deployment\Task Handler\SBS\SBSStore, then restart PXE services. I had nearly 3,000 files in that directory. After starting the services back up, the *-client.sbs, *-image.sbs, and initalPXEConfigPath.sbs files were all recreated, and doing a Recreate boot configuration ran bootwiz.exe like it was supposed to. After that, it was only a matter of waiting for Bootwiz to finish.

Now I can finally get down to the task of getting this laptop imaged!

Unfortunately, now I'm running into a problem where the Broadcom wireless makes the DeployAnywhere process fail. If it's not one thing with DS 7.1, it's another, and that's why I say this product is NOT ready for prime time. I'm going to try a repair or re-install of DS 7.1 MR1 and hopefully that fixes my NEW problem.

DeployAnywhere works, when it works. When it doesn't work, though, it fails miserably. And I have a sneaking suspicion that I spend more time diagnosing DeployAnywhere problems than I did with my old DS 6.9 scripted method of FIRMing in every single driver after the image was laid down. It would be hard to come up with concrete statistics with this, but based on the amount of support tickets I've had opened with Symantec solely on DeployAnywhere issues, I wouldn't be surprised if it were true.