Your browser (Internet Explorer 6) is out of date. It has known security flaws and may not display all features of this and other websites. Learn how to update your browser.
X
Aside

ConfigMgr: Trouble Importing Windows 8/8.1 Drivers on Server 2008 R2

Recently had an issue while configuring some drivers for a client. I was unable to import any Windows 8/8.1 drivers into the site. Upon importing drivers through a script or through the console you will receive "driver is not applicable to any supported platforms"

image

Turns out it’s a known issue and there is a KB:

http://support.microsoft.com/kb/3025419

Installing the following hotfix resolved the issue for me.

http://support.microsoft.com/kb/2837108

After installing the hotfix and rebooting, I was able to import the Windows 8/8.1 drivers successfully.

Aside

The Drivers Saga continues – How to Master Drivers in ConfigMgr 2012

Johan Arwidmark has a nice new post on driver management. Always a fun topic to discuss.

Read the full post here.

A new chapter in the driver’s saga has been written; this time it will teach you how to master drivers in ConfigMgr 2012

Background story:

Since the release of ConfigMgr 2007 I have recommended taking control of your drivers, using a method known as "Total Control" as opposed to the default "Total Chaos" method in ConfigMgr. In the previous guide one of the options described was to create driver packages in ConfigMgr 2007, without even importing the drivers. This method was actually possibly because of a bug in ConfigMgr 2007 (I like to call it a feature, but never mind). I really liked that method because it was super-quick and easy to both setup and maintain, not to mention that I didn’t have to store the drivers twice on the server and got an easy-to-read folder structure instead of the {guid} named folders ConfigMgr 2007 generated.

But guess what, in ConfigMgr 2012 Microsoft fixed the bug, which rendered the above method impossible. In ConfigMgr 2012 you really have to import the drivers, whether you like it or not. The change in ConfigMgr 2012 also prevents you from migrating existing driver packages from ConfigMgr 2007 (If they were created without importing the drivers). Luckily, if you did follow the previous guide, you already have a perfect driver structure, and in this post you learn how to use the exact same structure for ConfigMgr 2012…..

Aside

Lenovo releases driver packs for ConfigMgr

Looks like Lenovo has finally surrendered to peer pressure 🙂

Driver "packs" can now be found on their website, under the Enterprise Management category.

Read Rod’s full post here.

Aside

HP Driver Packages

Johan Arwidmark blogged about an awesome item that shows up in HP SoftPaq Download Manager now. In either SDM or on the HP driver site, you can now find driver packages for current generation models.

Read Johan’s post here.

Aside

MDT 2012 Driver Managemant, by Martin Schumacher

Johan Arwidmark posted a link on MDT 2012 Driver Management.

There is lot of information regarding driver management in MDT, but there is this one gray area which I would like to lite touch on

When implementing MDT in mixed environments you can have a situation when:

  • You are experiencing driver conflicts
  • Grouping computers using MAKE and MODEL attributes is difficult and impractical

These two points sound familiar? Read on!

Read Martin’s full post here.

Aside

ConfigMgr-Update Driver Source Paths SQL Query

CAUTION: Editing the Database directly is unsupported.  Proceed at your own risk. 

 

In addition to my previous post, in which I used a script to update the driver paths, you can also do this via SQL.

 

The following command will let you preview the changes you are about to make:

 

image

 

image

 

The following command will execute the changes.

 

image

 

image

 

Change Driver Pkg Source Path

Aside

ConfigMgr–Automating The PreLoadPkgOnSite Tool Script

Credit to Greg Ramsey for writing the script.

 

In addition to this post, be sure to read John Marcum’s blog post:

 

Packages Will Not Uncompress After Using Preloadpkgonsite.exe

 

After upgrading a few servers at a client site, we had to reinstall the Secondary Sites. Surprisingly we didn’t want to resend 400+ packages across the WAN to the remote sites.  The PCK files were still sitting on the server from the previous installation.

 

After reading John’s post and chatting with Greg Ramsey, I decided to use his script.  I had a few issues initially and Greg being the awesome guy he is helped me sort them out.

 

One VERY important thing to note is that you have to send at LEAST one package to the remote site before you can preload content, not sure why that is the case, but John saw the same thing.  After sending one package, the preload tool works great.

 

Once you have the script, you’ll need to make sure the paths are correct for your environment and it’s pointing to the correct server.

 

Make sure the connection string is pointing to the right server and site code.

 

image

 

Make sure the SMSPKG folder paths are correct.

 

image

 

Make sure the output path is correct as well.

 

image

 

Next we want to run the createpreloadbat.ps1 script in powershell.

 

image

 

You will end up with a preloadpck.bat in the output path and you will see the script spit out all the PCK’s it found.

 

image

 

image

 

Next if you run the preloadpck.bat, you will see it update the database. You will see it make the connection to the database and it will let you know if there are any issues.  (in this example screenshot the packages are already distributed)

 

Again, remember you have to send at least one package ahead of time (pick a small one), otherwise you’ll see a rights error.

 

image

 

Finally you can add your DP to the package using the copy packages wizard or CloneDp or whatever you want to use. When the DP receives the request for the package it will use the local PCK instead of requesting a new one.

 

Enjoy!

 

Download here: PreLoadPkgOnSite

Aside

Finding and adding only the correct device driver to the Boot image

Michael Petersen has a nice new post up on the CoreTech Blog that is something I talk repeatedly about with clients.  Only injecting the drivers you NEED, instead of needlessly injecting drivers until you get a working boot image. 

Read the full post here.

It seems to me, people tend to add way to many drivers to their boot images, which in some cases make WinPE unstable, and subsequent make the Deployment fail. It also makes it near impossible to figure out which driver versions/types are actually included, as that info is kind of limited from within the Boot Image node itself …

What I do, is find the exact drivers needed for my WinPE environment to work on the specific model(s), and add only those drivers.. If I Can boot WinPE, and gain access to the network (IPCONFIG) and hard disk (DISKPART – list disk), I do not update my boot image, even if I choose to add a new NIC to the deployed OS itself!

In this example I will use a DELL latitude E6320, because this particular machine has a network driver not already included in WinPE.

The first thing to do is go into the device manager and check which driver the network card is using. I usually do this from the Win7 preloaded OS that comes with the machine (you know! before reinstalling). If this is not an option, you can do something similar from within WinPE using DrvLoad.exe, and wmic, but more about that in a later post!!

…..

Aside

Category is incorrectly overwritten when you import the same driver on to a System Center Configuration Manager 2007 SP2 site server

Read the original post here.

Scenario 1
  • You have a Microsoft System Center Configuration Manager 2007 Service Pack 2 (SP2) site server.
  • You install hotfix 2213600 on the site server.
  • You use the Import New Driver Wizard to import a set of drivers on to the site server. You specify a category and a driver package in the wizard.
  • You import the same set of drivers again. You specify a different category and a different driver package in the wizard.

In this scenario, the original category is incorrectly overwritten on each driver, and only the second specified category is set on each driver.

Scenario 2
  • You have a System Center Configuration Manager 2007 SP2 site server.
  • You install hotfix 2213600 on the site server.
  • You have a folder under the Drivers on the site server.
  • You use the Import New Driver Wizard to import a set of drivers to the folder on the site server. You specify a driver package in the wizard.
  • You import the same set of drivers to the folder again. You specify a different driver package in the wizard.

In this scenario, the wizard does not import the set of drivers to the second driver package.

Aside

ConfigMgr 2007 Driver Management Revisited (Again)

Michael Niehaus has a new post on ConfigMgr Driver Management. 

Read the original post here.

After MMS 2010, I had posted a series of blog postings talking about different mechanisms for managing drivers with ConfigMgr 2007.  You can read through that at http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx.

Then a hotfix was released that changed the way ConfigMgr 2007 handled duplicate drivers when importing.  I talked about that in the post at http://blogs.technet.com/b/mniehaus/archive/2010/10/15/configmgr-driver-management-a-new-development.aspx.  One point called out in that posting:  driver categories would be overwritten when a duplicate driver was imported specifying a different category.  That made the “Added Predictability” model described in the first posting very difficult to implement (without using something like the PowerShell script I posted in the first series).

Now, there is a new development:  Another hotfix that affects driver importing:

Category is incorrectly overwritten when you import the same driver on to a System Center Configuration Manager 2007 SP2 site server
http://support.microsoft.com/kb/2513499

From the title, you can probably guess what it fixes:  Now, when importing duplicate drivers, if you specify a different category, it will be added to the list of categories instead of overwriting the list that is already there.  As a result, the “Added Predictability” model is fairly simple to implement (without the need for scripting).  Look at this basic scenario:

  • Download all the drivers for a Dell Latitude E6410 and import those, specifying a category of “Latitude E6410”.
  • Download all the drivers for a Dell Latitude E6510 and import those, specifying a category of “Latitude E6510”.

Without the hotfix, all the common drivers would end up with a category of “Latitude E6510”.  With the hotfix, they would have both categories specified.