Password protected BIOS shouldn't be an issue - that should only apply when you're trying to ENTER the BIOS, not when you're trying to flash it.
BIOS updates done remotely are always something I feel "so-so" about, as I've very much gotten used to the "must clear CMOS after the flash"-method of thinking, as I've seen way too many issues if people don't reset the CMOS. But that's personal preference.
So - first question is "where's the BIOS being installed"? I've not had to update DELL BIOS's in years (and am too tired to look it up at the moment), but this pretty much boils down to one of three options traditionally:
1 - Able to be done in Windows
2 - Requires MS-DOS of some sort
3 - Requires a SPECIFIC boot-floppy / OS.
For option 1 - Now - if it's possible to be done through Windows, this should be a doddle ... you should be able to wrap the installer / script it - same as any old package, and be done with it (though I'd expect a reboot would be required).
For option 2 - if this stuff works in the MS-DOS environment, you COULD actually abuse OSD for this. As a matter of fact, this is EXACTLY what the "CUSTOM OSD SCRIPT" option is for ... you boot in to a MS-DOS environment, execute your BIOS flash remotely (which hopefully doesn't require input, or things get really interesting) ... and reboot the client when it's done.
Though this requires your devices booting to PXE first of all, obviously, otherwise you're not going to get very far here
For option 3 - this gets more interesting ... you COULD create your own bootable floppy and add it to the PXE-boot menu ... this is possible, but requires a fair bit of work. But - even if it is, you better make sure you script your equivalent of an AUTOEXEC.BAT to run the flashing automatically.
The only (or main) concern here is how do you keep your users from doing something as naff as turning their devices off / rebooting them in the middle of a BIOS-flash.
To be perfectly honest - it's one of the biggest reasons why I'm AGAINST remote BIOS flashes.
Normally, most shops tend to make sure that the BIOS-upgrade is part of the OSD'ing process of a machine - that way the box is in the hands of trusted (I'd hope ) techs and unexpected incidents should be down to a controlled minimum (with competent people being able to reset / salvage the BIOS in a "worst case scenario" without overly disrupting things.
LANDesk EMEA Technical Lead
i was finally able to create a batch file and call back to the exe with a -nopause command line switch.