Time to update one of the most popular articles on this site for SCCM 2012 (SP1 as at time of writing)…. some parts are the same as the old article.. but there are some fairly major changes in how 2012 allows drivers to be used – and I’ve expanded on some important bits.
The original article is here – https://hayesjupe.wordpress.com/sccm-osd-driver-best-practices/
Driver types
Drivers can very broadly be split into two categories:
- Good Drivers: Drivers which come in an inf/sys/cat format and can be installed on systems easily
- Bad Drivers: Drivers which come with a setup program and must be installed (common examples are laptop Bluetooth drivers)
It is very important that the driver type is correctly identified. Many drivers come in an .exe format, but can be extracted to expose the inf/sys/cat files. Whenever working with drivers, you should always try and install everything possible as a “good” driver.
Driver import methodologies
In SCCM 2012, there is now only one real method of importing “good drivers”, which is importing the drivers into the database…. however, there are still a couple of options when it comes to allocating these drivers in task sequences.
Which drivers ?
One of the biggest mistakes I see is clients who get a make/model in and proceed to go the manufacturer website and grab every driver…. fuck no – this will leave you with a bloated mess of a driver database. Often the manufacturer drivers are out of date, full of bloat and just generally crap…..
I suggest:
- Identify drivers that are common for many makes and models, such as
- Intel Nic (proset)
- Intel chipset
- Intel integrated gfx (primarily for laptops)
- Intel Sol and HECI
- Intel mass storage (RST)
- Broadcom network
- Nvidia and ATI gfx
- Grab all these drivers from the original manufacturer website (i.e. Intel, Broadcom, etc)
- Create a driver package for these drivers and use auto-apply for the time being
- Run your SOE build on the make/model of hardware – open device manager, see what’s missing
- Go to the manufacturer website and grab what is missing (but again, if you can find the original reference driver from the source, get that instead…. they are newer and better 99% of the time)
- in all cases, try to just take the directory with the inf/sys/cat files…. not all the other rubbish
Making sure you have the correct drivers
Ok, so you have a Windows 7 or Windows 8 (I’m going to assume that no-one is still using XP and that anyone that went to vista has been laughed out of the business….) build with a few exclamation marks in device manager…. you have found drivers by going to manufacturer site or searching on the Hardware ID (or PNP ID) – this is handy when devices come up with un-helpful descriptions (as so many of them do)
- Download the driver, and unpack/extract so you have the drivers in the inf/sys/cat format (the “good” format)
- Note: this is another time where you may find drivers from the original manufacturer website are better than the HP/Dell/Lenovo/fujitsu etc.
- In device manager, try and update the driver by pointing in to the specific directory the driver is unpacked too
- If it works – woohoo…. copy that driver into your package source location ready to be imported
- If it doesn’t work – you’ve got the wrong driver, go back and try a different driver
- On rare occasions, the driver may be correct, but will only install when implemented via setup/install…. this can be because of dependant devices or because the .inf doesn’t contain a matching PNPID… (and somehow – I’ve never bothered to try and work out how – the setup process gets around this) – editing the inf with the correct PNPID can get around this, but you have to be sure that its the right driver. Probably not such a good idea to try this is you are relatively new to this process – and as I said, it is rare….
Driver import and package process
The most common mistake I see here is people that copy their drivers into a location such as C:\Temp – import them, then delete them. This causes all types of shit – don’t do it. SCCM wants the original source files to still be there…. so
1) Under your package source, create a directory called “DRVSource” (or similar)
2) Copy all your original drivers into a folder structure under this directory such as
- DRVSource
- DRVSource\Dell\OptiPlex.745\Win7.x64\Gfx
- DRVSource\Dell\OptiPlex.745\Win7.x64\Audio
- DRVSource\HP\N7700\Win8.x64\Gfx
- DRVSource\Intel\Win7.x64\Chipset
3) Import your drivers into the database, one model/OS combo at a time – creating a category for them as part of the process. e.g. Import everything from DRVSource\Dell\OptiPlex.745\Win7.x64 and create a category called “Dell.Optiplex.745.Win7.x64”
4) Create the package in your package source location, using your naming convention… e.g. \\sccm2012\psource$\DRV.Dell.Optiplex.745.Win7.x64
5) Repeat until you have all the drivers you want imported
6) Add packages to DP and distribute
7) This is where it diverges a little…..
7a) If you have a small number of makes and models…. say anywhere under 50, you can probably just use “auto apply drivers” in your task sequence
7b) if you have a large number of makes and models or you run into conflicts, you can apply the driver package based on category or apply a specific package
- Create an “apply driver package” after the existing “auto apply drivers” step (which you can now disable or delete)
- Select the appropriate driver package
- Get the model name from the desired make/model machine by using “WMIC CSProduct Get Name”
- In the options tab, enter a task sequence variable of model equals
- In the case of some models, there are long rambling characters in the model string. E.g. HP Elitebook 590 WRERTYG67
- In this case, use a WMI query instead such as Select * from Win32_computersystem where model like “%HP Elitebook 590%”
- Repeat for each of your models
For places that do have large numbers of makes and models – the most important thing is to avoid driver bloat – it will make your driver database difficult to manage…. so
1) Try and use reference drivers from the real source manufacturer (e.g. Intel) where possible – this will give you better coverage of more makes/models with less drivers
*edit 2/5/2013 * – This was fantastically illustrated today for me at a client who uses Lenovo desktops….. below is a screenshot of the ahem… “enterprise management” driver download for SCCM for ThinkCentre 92’s…
1.5GB ! 1.5GB of drivers…. you fucking arse clowns!
Drivers, actually rerquired for a Thinkcentre 92, Intel chipset, gfx, network, mass storage, usb 3, mei, sol.. (all from intel site) then a couple of ones from the actual lenovo page… grand total size… approx 60mb….
Just felt like adding this bit in to show the amount of waste and bloat you will have if you use the shitty driver packs from lenovo/dell/hp…. whoever they employ to make these driver packs has pretty clearly never used SCCM in their life!
2) Do not, ever, dump the entire set of drivers from the manufacturers website – do an install and only grab the ones that are missing
3) Try to stick with more mainstream hardware if possible…. I don’t love any of the major OEM’s, they all have their faults….. but some of the more fringe players make some fucking junk that’s hard to manage deployment for. Even for the bigger manufacturers, stick to machines that are intended for corporate environments
“Bad driver” package process
“Bad Drivers” are just another application which must installed, similar to acrobat 27.4 patch 4 update 3 (or whatever todays version is) or office 2013. Standard packaging processes should be followed for these applications.
Adding boot image drivers
Boot image drivers are injected in Windows PE and provide local disk and network access; which are required to initiate a build process.
SCCM 2007 SP2 installations use Windows PE 3.x (Based on Windows 7)
SCCM 2012 RTM/SP1 installations use Windows PE 4.x (Based on Windows 8)
1) Identify the network and mass storage driver required for your version of Windows PE and your hardware model
- Remember, this is not the same driver as the OS you are installing, it’s the driver required for the version of windows PE your using in your boot image
2) Import the driver into the SCCM driver database, with a category of “Windows PE boot drivers”
3) Go into the properties of the appropriate boot image, go to the “Windows PE” tab and add the appropriate drivers
4) Click on ok, then accept the message which will re-compile and distribute your updated boot images
Updating drivers
When updating drivers that are in the database, its has a couple more steps compared to using the package-without-import method I preferred in 2007.
- Test the updated driver on as many models as you can
- Take note of any driver packages the “old” driver is used in
- Delete the “old” driver from the database
- Delete the “old” files from the DRVSource directory
- Place the new files in the DRVSource directory
- Import
- Add the driver to the relevant driver packages if required
- Update the DPs
Server builds
More and more we are being asked to create task sequences for en-masse server builds – so an employee of mine reminded me that an extra line or two on this might be good.
Server builds are a little different for drivers – as generally places want all the additional tools installed as well (e.g. on HP servers, there is a plethora of additional tools/utilities for server management) – where as on workstations it should remain as lean as possible.
So – with that said, I going to assume that if your doing server builds in SCCM, that you have at least a bit of experience in both server builds and SCCM
I recommend using basic drivers to get you through to an OS – this will generally be RAID drivers and network drivers – after that, run HPSUM.exe in silent mode to catch all additional drivers, but also firmware’s and tools/utilities. HPSum is available in the HP PSP’s (proliant support packs) – and do make life easier. I assume Dell and IBM have an equivalent – but quite frankly, anywhere we deal with that has mass server deployment needs is a HP shop for server hardware.
No comments:
Post a Comment