The original article is here – https://hayesjupe.wordpress.com/sccm-osd-driver-best-practices/
read here more on https://hayesjupe.wordpress.com/sccm-2012-osd-driver-good-practice/
Driver types
Drivers can very broadly be split into two
categories:
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.
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.
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…. oooooo 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…..
get a make/model in and proceed to go the manufacturer website and grab every
driver…. oooooo 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)
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
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)
called “DRVSource” (or similar)
2) Copy all your original drivers into a folder
structure under this directory such as
structure under this directory such as
- DRVSource
- DRVSourceDellOptiPlex.745Win7.x64Gfx
- DRVSourceDellOptiPlex.745Win7.x64Audio
- DRVSourceHPN7700Win8.x64Gfx
- DRVSourceIntelWin7.x64Chipset
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 DRVSourceDellOptiPlex.745Win7.x64
and create a category called “Dell.Optiplex.745.Win7.x64″
model/OS combo at a time – creating a category for them as part of
the process. e.g. Import everything from DRVSourceDellOptiPlex.745Win7.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.sccm2012psource$DRV.Dell.Optiplex.745.Win7.x64
location, using your naming convention…
e.g.sccm2012psource$DRV.Dell.Optiplex.745.Win7.x64
5) Repeat until you have all the drivers you
want imported
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
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
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
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
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…
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 ooooooing arse
clowns!
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….
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!
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
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 ooooooing junk that’s hard to
manage deployment for. Even for the bigger manufacturers, stick to machines
that are intended for corporate environments
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 ooooooing 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.
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.
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)
(Based on Windows 7)
SCCM 2012 RTM/SP1 installations use Windows PE
4.x (Based on Windows 8)
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
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”
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
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
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.
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.
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.
– 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
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.
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.
