jscheffelmaer

Thx fizban, I figured that out right before seeing your message. I was able to backup the build.xml file in the control folder. It is actually possible to create the build, you just can't click on the build node again. You can then go modify/update the files manually. But would be nice to have a new release soon.

Has anyone gotten the BDD 2007 Beta to work with XP SP2 yet? Silly question I know but we want to use the same tools for both deployments until full upgrade. I am able to add the Operating System fine under the workbench, but as soon as I create a new "build" under the build node, my MMC crashes and won't let me view the build node anymore. To resolve it I have to remove the Operating System XP SP2 associated with that build therefore breaking its link. I was told that this Beta release should support XP as well.

If I understand you correctly you want to get the manufacturer's model-string from WMI and that would then serve as a pointer to a list of drivers... Well, the problem with this idea is that the model-string will not garantee what HAL and or drivers the deployed machine will need, because at least in our environment we have a number of pc's with the same model-string but house quite different hardware. I'd rather get a list of hardware in the deployed-machine by using a utility like pci32.exe of devcon. Hmm, that is quite interesting as I have never run across the same model number with different hardware (Edit: Sorry, meant with corporate purchases, not custom builds such as home). Did you find this to be true using the win32_computersystem.model property or another property? It is true it does not tell you what HAL it is to run, but you can include the HAL in the database for that model detected and return that back tot the script. Unfortunately it would not be automated from the get-go, but someone would be admin'ing and updating with each new hardware that enters the environment. I wouldn't call this necessarily a bad thing though. =) Try doing a query of the property I listed above on random spots of your inventory and see what you find. The only time I have seen it be an issue is with custom built hardware unfortunately, but IBM/DELL/HP return quite reliable values.

So why not have a database of your supported hardware by WMI model. And that databse holds the key to drivers/hal/vendor specific software, etc? This way you can also control if you allow non-standard hardware from being built with your build code with one variable ALLOW_UNSUPPORTED_HARDWARE = False as a constant in the code. This would allow you complete control over all drivers and software. In fact, it is how we do it today =)