As part of the “ConfigMgr Driver Management: The Novel” blog postings (see http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx for the first part) and in various presentations I mentioned that most of the challenges with driver management in ConfigMgr stemmed from the way drivers are imported into the ConfigMgr driver store: duplicate drivers are ignored, so they don’t get put into the specified categories or packages. That’s where the PowerShell scripts came in: when a duplicate is encountered, the scripts take care of putting that existing driver into the right category and packages.
Well, the ConfigMgr team has made available a hotfix that changes the driver import behavior in the console, handling duplicates differently than before. Depending on the driver scenario that you are using, this might be the solution that you need.
The hotfix is available for download from http://support.microsoft.com/kb/2213600. It requires ConfigMgr SP2 (no dependency on R2 or R3, but it works fine with either), and should be installed on the site server and any machine running the admin console. (Interestingly, this fix is provided as an MSI instead of the more typical EXE-based fix.)
Once the hotfix is installed, you’ll notice a change in behavior: You’ll never see the console complain about a duplicate driver. It will always say that the drivers were imported successfully, even if they were already present. But how does it handle the scenarios that I had discussed? Let’s review them:
* Scenario #1: “Auto Apply Drivers” without categories (“total chaos”). This scenario is unaffected.
* Scenario #2: “Auto Apply Drivers” with driver categories. Unfortunately, this one still doesn’t work quite as expected: If you specify an additional category on a subsequent import, expecting that category to be added to the existing category list, that doesn’t happen. Instead, the existing categories are replaced with the specified category. (I’m trying to follow up on this one to see why this is the case.)
* Scenario #3: “Apply Driver Package” with model-specific packages. The fix does work well for this scenario: Duplicates drivers aren’t ignored any more, they are added to the specified driver package. So this becomes a very simple scenario (and you don’t need to use the “unique file” import workaround, which ends up bloating the driver store).
* Scenario #3J, “Johan’s Method” using driver packages without importing drivers at all. This scenario is unaffected.
So if you use model-specific driver packages and import all your drivers into the driver store, you will want to try out this fix to see if it makes things simpler for you. For the other scenarios, you probably don’t need this fix.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.
As part of the “ConfigMgr Driver Management: The Novel” blog postings (see http://blogs.technet.com/b/mniehaus/archive/2010/04/29/configmgr-2007-driver-management-the-novel-part-1.aspx for the first part) and in various presentations I mentioned that most of the challenges with driver management in ConfigMgr stemmed from the way drivers are imported into the ConfigMgr driver store: duplicate drivers are ignored, so they don’t get put into the specified categories or packages. That’s where the PowerShell scripts came in: when a duplicate is encountered, the scripts take care of putting that existing driver into the right category and packages.
Well, the ConfigMgr team has made available a hotfix that changes the driver import behavior in the console, handling duplicates differently than before. Depending on the driver scenario that you are using, this might be the solution that you need.
The hotfix is available for download from http://support.microsoft.com/kb/2213600. It requires ConfigMgr SP2 (no dependency on R2 or R3, but it works fine with either), and should be installed on the site server and any machine running the admin console. (Interestingly, this fix is provided as an MSI instead of the more typical EXE-based fix.)
Once the hotfix is installed, you’ll notice a change in behavior: You’ll never see the console complain about a duplicate driver. It will always say that the drivers were imported successfully, even if they were already present. But how does it handle the scenarios that I had discussed? Let’s review them:
* Scenario #1: “Auto Apply Drivers” without categories (“total chaos”). This scenario is unaffected.
* Scenario #2: “Auto Apply Drivers” with driver categories. Unfortunately, this one still doesn’t work quite as expected: If you specify an additional category on a subsequent import, expecting that category to be added to the existing category list, that doesn’t happen. Instead, the existing categories are replaced with the specified category. (I’m trying to follow up on this one to see why this is the case.)
* Scenario #3: “Apply Driver Package” with model-specific packages. The fix does work well for this scenario: Duplicates drivers aren’t ignored any more, they are added to the specified driver package. So this becomes a very simple scenario (and you don’t need to use the “unique file” import workaround, which ends up bloating the driver store).
* Scenario #3J, “Johan’s Method” using driver packages without importing drivers at all. This scenario is unaffected.
So if you use model-specific driver packages and import all your drivers into the driver store, you will want to try out this fix to see if it makes things simpler for you. For the other scenarios, you probably don’t need this fix.
via > http://blogs.technet.com/b/mniehaus/archive/2010/10/15/configmgr-driver-management-a-new-development.aspx
Share this post
Link to post
Share on other sites