[yogger]

It is possible to do a BIOS update from inside PE? I'm using Dell Optiplex PC's and Latitude Laptops with the 32 bit programs. I've got logic to test what model it is and check if the BIOS is up to date or not, but when I run the BIOS utility from Dell, I get "Program Access Denied" and "Please make sure you are logged in as an administrator" errors.

[Albuquerque]

I know there are some machines that allow for firmware updates while still within Windows; but I don't exactly know how they work nor do I know if the machines you specified allow such a thing.

For compatibility (and safety) reasons, all the BIOS updates on machines here at my office are done in DOS. I actually ghost down a second tiny partition that contains the necessary scripting to identify the machine type, flash the bios appropriately, and then remove itself completely from disk and erase it's own partition upon the first reboot. We update that second tiny partition whenever we get a new BIOS to put out...

[yogger]

Dell's Bios updaters are 32 bit and run fine from inside windows xp/2k, but gives the error about not being an admin when run from PE. Just hoping someone else had run into that issue and got it working. I do have some backup plans if this doesn't work though.

[Albuquerque]

Interesting note on the Dells, my office uses Optiplex 260/270/280 machines. I might have a look into their offerings to see if it's something I want to integrate into my scripting support...

On another note, is it possible that the BIOS tool is erroring out because it's unable to write a temporary file to disk somewhere? It might gripe about lacking permissions because it cannot write to disk from your PE image. I'm just guessing of course...

This post has been edited by Albuquerque: 26 April 2006 - 09:24 PM

[yogger]

The 260's don't seem to have a 32 bit update util, so you need to do that from dos somehow.

I was originally working on a dos kix script for the ones that can't be updated in windows and use cdshell on the boot cd to switch between pe and dos, but I can't get it stable for whatever reason.

Right now, I'm leaning towards either throwing the BIOS updates into post image (makes me nervous) or making a prompt when someone with admin rights logs in to make them do it (one of our techs should always be working on the machine after post image anyway).

But I have to have this all done next Friday, so it may just wait till the next image at this point.

[ChrisBaksa]

This more a limitation of the manufacture's tools not PE.

I can tell you that HP is working on making the Softpaq's run under PE.
Currently thay have a hard coded dependency on a drive location.

What I have done is put the OS on the host 1st and then run the Flashing tools under the Installed OS. This way my code is common. All the manufactures that I support (HP, IBM, Dell) can flash under Windows 2000, 2003)

Chris

[Albuquerque]

I do it slightly differently than Chris...

All of our workstations use a Ghost image of some sort, depending on model (sysprep for most, a few tablet-specific images.) I use a combination of WSH script, WMI queries and DISKPART to identify if this machine has a current BIOS (use an "answer file" on a centralized server location), and if so: I query for the size of the destination disk, calculate the smallest partition that can be created on that disk (typically ~7mb), create a primary partition that is the entire size of the disk minus that minimum determined size, and then create a second primary partition that is the remainder.

I ghost the workstation OS image into the big primary partition, and I then ghost down a FAT16 "bios fix" image into that remaining tiny portion at the end. I set that second utility partition active and force a reboot. Upon reboot, that utility image does several things:

• Loads all datasets into a ramdrive
  
• Points COMMAND.COM into ramdrive as well
  
• Identifies the hardware. *
  
• Flash the BIOS accordingly
  
• Completely removes the second partition from the disk
  
• Re-sets the first primary partition to be active (bootable)
  
• Reboots into the normal Windows OS

Now, about the asterisk...

To keep my job simple, I wanted this one DOS utility partition to work on every piece of hardware in my organization. And as such, I need to identify (within DOS) which piece of hardware I'm on before I can flash the BIOS. I built an answer using the DOS utility PCISCAN by creating what I call "fingerprint files". Without going into uber detail, you can determine what piece of hardware you're on by what devices (and in what layout or configuration) are in a PCISCAN dump. Once I figure that out, I know what BIOS flash I need to use.

There is obviously a big chunk I've left out, but anyone here should be smart enough to figure out the interim pieces. And if not, then I'm going to say you need to spend the time to figure it out anyway

Oh, and why do I figure the "smallest partiiton size possible?" Because when you delete a 7mb partition from a >20GB drive, the remaining "emtpy" space is so small that Windows doesn't show it in Disk Management. Thus, our end users don't b***h about somehow not using their entire disk

This post has been edited by Albuquerque: 28 April 2006 - 09:16 AM

[yogger]

ChrisBaksa, on Apr 28 2006, 08:05 AM, said:

This more a limitation of the manufacture's tools not PE.

Yeah, thats what it seems like to me, was just hoping someone figured out a work around.

Quote

I can tell you that HP is working on making the Softpaq's run under PE.
Currently thay have a hard coded dependency on a drive location.

If only Dell will do the same.

Quote

What I have done is put the OS on the host 1st and then run the Flashing tools under the Installed OS.

Do you have that run automatically or have someone do it manually?
I've though about doing that, but am afraid to trust my users not to interupt the process and turn their PC's into paperweights.

[Daemonforce]

This is quite a topic. My board is the IS7. For a few days in every year I load up the online update tool and look for a newer BIOS to update with. Funny thing about it:
I have used it in XP Professional SP1 with success.
I have used it in LH Professional PDC03 with success.

Now you ask, why would I flash my BIOS under Longhorn?

This computer is powered by a P4. It does not like the programs that I use on the box with my AMD K6. Luckily, I've never had to flash the BIOS on that box. This computer has a strange driver issue with XP Pro where any tests where the screen size is changed in any way means an instant reboot. Thankfully I've never had such a problem in Longhorn and WinPE.

I did a reinstall of XP Pro yesterday and encountered the same issue. It took me a while to find the right drivers. Before you do any BIOS flashes or anything critical in WinPE, it may be wise to do a video "stress" test to make sure the environment is stable.