Configuration Manager 2012 and the need of keeping your Driver database lean and clean !

April 14, 2014 at 8:03 pm in CM12, CM12 R2, CM12 SP1, Deployment, Drivers, OSD, sccm, SCCM 2012, sccm 2012 R2, SCCM 2012 R2, SCCM 2012 SP1, sccm RTM, Task Sequence by Kenny Buntinx [MVP]

 

Hi ,

Lately we had an issue on a CM2012 R2  production environment when exporting a “task sequence” from our Acceptance environment and importing that exported “task sequence” into production , and ran into an error where our task sequence import would fail with out of memory message.

The exact message was : “System.OutOfMemoryException , Exception of type ‘System.OutOfMemoryException’ was thrown” as shown in the picture below:

clip_image002

Several people recommended me to increase the WMI memory allocation by doing this : http://anoopcnair.com/2011/05/06/configmgr-sccm-how-to-increase-wmi-default-memory-allocation/ . Anoop links to the “_providerhostquotaconfiguration” class in his article. Anoop’s advice is not uncommon, although supportability of the matter is questionable without PSS/CSS support , it’s a common test/fix giving on PSS/CSS calls related to slow or underperforming console issues.

My advice : DON’T DO THIS BLINDLY or without PSS/CSS support . You’d be crazy doing anything to WMI on a ConfigMgr production environment that you don’t understand the impact off. And if it’s to a component as critical as WMI is to ConfigMgr than you’d better do your homework before implementing it in production.

And this blog post explains what the impact is: http://blogs.technet.com/b/askperf/archive/2008/09/16/memory-and-handle-quotas-in-the-wmi-provider-service.aspx

We increased the WMI memory allocation with PSS support until 8Gb memory (Server having 16 Gb physical memory) , but no luck at all.

A little recap and issue definition:

  1. 1. We created a OSD Task sequence deployment in our acceptance environment.
    2. Once validated , we exported the TS without content (Content is located on a shared UNC storage path) but with dependencies.
    3. We tried to import the exported TS into production, the import fails both trough the GUI and via the powershell cmdlts. The import in production of the exported tasksequence fails with an out of memory error as shown in the screenshot above
    4. We tested both on the Primary site server itself as via remote console –> same result
    5. We have sufficient memory available on the server. I saw that the PowerShell session on the primary site server used up to 1.5Gb ram during the import. (memory was not maxed out (74% used))

Further investigation leads us to the size of the exported Task Sequence , which was about 235 Mb ( without content , go figure ! ) . Probably you would say : “What the hell did you put into that task sequence ????? ”. Well , the customer needs to support 55 different hardware models because of the way they need to buy there hardware. Crazy , I know and the fact is that they know that as well , however they can’t change this purchase behavior.

That being said , they have 55 HW driver packs and they have around 4800 drivers imported in there CM12 Driver DB .

After testing , we discovered that if the imported task sequence is more or less bigger then 135Mb in size , it will fail to import with the error displayed above. Once we lowered the number of drivers being referenced in the driver packages and therefore also in the CM12 driver database itself and the exported TS would be below 135mb in size , the import succeeded. However we could never pinpoint the exact size of the task sequence when it would fail as this was between 135 and 145 Mb.

What I recommend you to do:

  • One of the biggest mistakes customers make is to go the manufacturer website and grab every driver with those so called “enterprise driver packs” that contain drivers for multiple models…. Hell no , mostly the drivers are out dated, full of additional crap…
  • Use common sense and  only import drivers that are applicable to machines in your environment. I do not recommend that drivers are blindly imported into ConfigMgr where there is no actual benefit. This will just cause the database to bloat and the task sequences to become unwieldy. I recommend that any unused drivers/driver packages are removed from ConfigMgr
  • If you have a large number of Manufacturers and models or you run into conflicts, you can apply the driver package based on category or apply a specific package, especially when exporting / importing task sequences .
  • Typically graphic cards , Intel Vpro , Soundcard drivers or custom “hotkey” drivers are “bad” drivers. Those should be installed with applications from the setup.exe or msi.

To give you an idea , we went for a Lenovo C30 desktop model from +_ 400 drivers to 22 drivers. Keep it clean and tight . It will cost you more energy in the beginning , but will save you a lot of time when you need to debug. That’s the message I am trying to give you !

Hope it helps ,

Kenny Buntinx

MVP Enterprise Client Management

Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInPin on Pinterest