Server 2008 unattended W Drivers?

[lundrog]

Is it possible to build a unattended 2008 that looks for drives in a OEM driver path like you could with previous versions of windows?

Thanks

[fizban2]

Is it possible to build a unattended 2008 that looks for drives in a OEM driver path like you could with previous versions of windows?

Thanks

the preferrable path woudl be to inject your drivers using PEimg into the WIM file you will be using

check out the WAIK at microsoft downloads

[ChrisBaksa]

Is it possible to build a unattended 2008 that looks for drives in a OEM driver path like you could with previous versions of windows?

Thanks

the preferrable path woudl be to inject your drivers using PEimg into the WIM file you will be using

check out the WAIK at microsoft downloads

Preferable. Maybe... But not very effecient or manageable.

In a large Enterprise firm, It is much easier to keep the drivers seperate (out of the WIM) and copy them when needed.

Most of us have a process to copy only the necessary drivers based on teh Hardware.

This will allow your Gold image to remain unmodified thus saving larger ammounts of data having to be copied to remote locations (across the WAN)

Driver versioning is easier and the WAN traffic is reduced to the drivers that changed not the entire WIM.

The cost of the process is an addition reboot as you prep the host to use the newly copied drivers.

Chris

[fizban2]

Is it possible to build a unattended 2008 that looks for drives in a OEM driver path like you could with previous versions of windows?

Thanks

the preferrable path woudl be to inject your drivers using PEimg into the WIM file you will be using

check out the WAIK at microsoft downloads

Preferable. Maybe... But not very effecient or manageable.

In a large Enterprise firm, It is much easier to keep the drivers seperate (out of the WIM) and copy them when needed.

Most of us have a process to copy only the necessary drivers based on teh Hardware.

This will allow your Gold image to remain unmodified thus saving larger ammounts of data having to be copied to remote locations (across the WAN)

Driver versioning is easier and the WAN traffic is reduced to the drivers that changed not the entire WIM.

The cost of the process is an addition reboot as you prep the host to use the newly copied drivers.

Chris

i like to think it is efficent single image to to run every model of server that i manage around the globe, and since there is compression on the wim you save space vs have them on a share someplace, that share is going to have to replicate or copy so bw savings are minimal but that is another chance for errors in communication or transfer. hopefully i don't sound like an arse, just letting you know what we do currently, using a standard wim file with all drivers inject for the model servers we support (6 currently, all from HP) that build is replicated along with applications and and anything else needed globally via dfs to 43 different locations where we have sms server. from there the build can be run through WDS on any PXE bootable server. the build currently gets sequenced through the microsoft deployment toolset so we have mutliple install roles availabe depending on when the server roles will be. i have one build here in HQ that is our master or "gold" image that when we need add new drivers or replace old driver i open the wim update/remove drivers, then set back in the dfs share. through the power of dfsr, we replicate the bits that change and now have updated images. just the way i go about managing our image. it works great for our situation and i thought i would share what we have done with it!

[ChrisBaksa]

i like to think it is efficent single image to to run every model of server that i manage around the globe, and since there is compression on the wim you save space vs have them on a share someplace, that share is going to have to replicate or copy so bw savings are minimal but that is another chance for errors in communication or transfer. hopefully i don't sound like an arse, just letting you know what we do currently, using a standard wim file with all drivers inject for the model servers we support (6 currently, all from HP) that build is replicated along with applications and and anything else needed globally via dfs to 43 different locations where we have sms server. from there the build can be run through WDS on any PXE bootable server. the build currently gets sequenced through the microsoft deployment toolset so we have mutliple install roles availabe depending on when the server roles will be. i have one build here in HQ that is our master or "gold" image that when we need add new drivers or replace old driver i open the wim update/remove drivers, then set back in the dfs share. through the power of dfsr, we replicate the bits that change and now have updated images. just the way i go about managing our image. it works great for our situation and i thought i would share what we have done with it!

I'm not doubting your setup. However my change control process would not play nice with this.

We have a weekly sync schedule where my changes are synced to about 40 distribution points around the world from a master location in the States.

The Wan Traffic generated by the WIM files to Europe/Tokyo/India is very large in that model.

And thats just the WIM files, The application packages also get synced during that process.

My design is to leave the WIM files unchanged (for the most part). This reduces the need for those large transfers.

My front end will have choices for the roles and the XML file will be dynamically built based on the selections (stored in a DB for one click rebuilds)

If you think about it, the Master image really only needs to be able to access the disk. Everything else is a plug and play discovery of drivers.

By keeping the drivers seperate in a file structure, I have the ability to copy only what I need. Nothing more.

Syncs are much smaller and faster and I have the ability to version the drivers by hardware model.

I have run into instances where one driver crossed Manufacturer platforms and was incompatable eventho it was the same model/partnumber.

Thinking outside the box... the driver file structure I maintain also servers for other applications. P2V, V2P, BareMetal restore, etc...

By pointing these apps/processes at the file structure, they can use the same production drivers in their discovery.

This way I know exactly what driver is certified by me to be used in our environment.

My 2003 Build support 49 models of hardware across 5 manufacturers. The 2008 build will start out supporting about 5 models.

Chris

[fizban2]

Chris,

do you not use dfs? that would make you bw usage go way down, since DFSR is R2 allows for just the changes to be repilicated to you sites?

[ChrisBaksa]

Chris,

do you not use dfs? that would make you bw usage go way down, since DFSR is R2 allows for just the changes to be repilicated to you sites?

No.

We wrote a syncronization tool that much more powerfull than dfs.

We do have DFS integrated in the firm. But the the OS builds work in a very controlled manner.

Development, Stageing and Production locations globally.

A bad package could blow up a traders box and loos the firm money.

Very tight change management.

Chris

[fizban2]

very cool chris

well lundrog,

you have 2 different paths here you can take, also some very good insite into what will be needed to unattend your build!