Hi,

i saw very slow Driver Package downloads during OSD today with some Dell Notebook Modells in a brand new SCCM 2012 R2 SP1 Environment. It seems the same like in this blog post:

http://henkhoogendoorn.blogspot.de/2015/03/configmgr-2012-r2-osd-slow-at-driver.html

After i "Allow clients to connect anonymously" as the DP Option the download was faster as you can expect over 1 GB Ethernet. So i assume that's an bug in the SCCM 2012 R2 SP1 Release. Maybe you can share your expierience with that part of OSD too.

Thanks.

Michael

• Edited by mknuel Friday, May 29, 2015 7:41 PM

Just because something is slow doesn't make it a bug.

Packages with lots of files are always a bit slower because of the overhead involved in each file.

Have you checked/changed the authPersistNonNTLM IIS setting as described at http://blogs.technet.com/b/configurationmgr/archive/2010/06/03/solution-you-may-experience-slow-performance-when-using-bits-and-kerberos-authentication-on-configmgr-2007-distribution-points.aspx ?

Thanks Jason, you are right to mention the number of files and i will try the option mentioned in the blog.

But only to mention: I had the same driver package for one model (Dell Latitude E7250, arround 800 MB and arround 1000 Files) some days before in the same environment. Difference was: SCCM 2012 R2 CU5 without the option "Allow clients to connect anonymously", and it was fast as the new environment with that option set.

• Edited by mknuel 15 hours 40 minutes ago

Thanks Jason, you are right to mention the number of files and i will try the option mentioned in the blog.

But only to mention: I had the same driver package for one model (Dell Latitude E7250, arround 800 MB and arround 1000 Files) some days before in the same environment. Difference was: SCCM 2012 R2 CU5 without the option "Allow clients to connect anonymously", and it was fast as the new environment with that option set.

• Edited by mknuel Saturday, May 30, 2015 4:05 PM

Hi Michael,

Any chance you can get the driver package size (after import)?

I've just imported the same 600MB folder of drivers into both a 2012 CU1 (build 7958) and a 2012 SP1 (build 8239) server. *edit* When referring to package, I mean the source folder where the files are stored post import.

On CU1: Package was 600MB and had 9 subfolders
On SP1: Package was 16GB and had 79 subfolders

It would seem SP1 is creating a copy of the entire directory for each driver...

Thanks,
Chris

• Edited by c-lockhart 3 hours 3 minutes ago edit

Hi Michael,

Any chance you can get the driver package size (after import)?

I've just imported the same 600MB folder of drivers into both a 2012 CU1 (build 7958) and a 2012 SP1 (build 8239) server. *edit* When referring to package, I mean the source folder where the files are stored post import.

On CU1: Package was 600MB and had 9 subfolders
On SP1: Package was 16GB and had 79 subfolders

It would seem SP1 is creating a copy of the entire directory for each driver...

Thanks,
Chris

• Edited by c-lockhart Thursday, June 18, 2015 4:51 AM edit

I've seen this later issue in production as have others. I've got an open dialogue going with the product group on this as it does cause the driver package download to be greatly extended.

Thanks Jason.

Now it is clear why i'm "suprised" about a 5,2 GB driver package for a Dell Precision Modell after the import in SCCM. Originally this package from Dell has arround 1,3 GB.

• Edited by mknuel Saturday, June 20, 2015 5:37 AM

Jason, any updates on this issue or should we give PSS a call and open up a case? Every driver package I have updated since installing SP1 is exhibiting this same problem. The size of the post-SP1 driver packages are 3 to 4 times the size of the pre-SP1 packages and the number of files is what really blows my mind. My Dell 9020 Win7 driver package went from 1.2GB with 1,600 files to 6.0G with 23,768 files. It takes 45 minutes each for the Prepare and the Download phases to run. I am also fighting a hash error anytime I edit a driver package by either adding or removing a driver after the initial package build. Never had this problem with Pre-SP1. Also adding or removing drivers to the boot images takes so much more time too. Just showing which drivers are currently in the boot image (Driver tab) takes 1 to 2 minutes which used to take just a few seconds. 

• Edited by scarneol Sunday, June 28, 2015 12:39 PM

The Import New Driver Wizard seems to be creating a unique folder for each INF it finds within the source folder location and adding all of the required files for each INF into that folder therefore the size of the package grows by the factor of how many INF files found in the source location. For example, I imported just the audio driver for the Dell 9020 Win7 (x64) which contained 1 folder, 62 files (3 INFs), at a size of 231 MB. After the wizard completed, the package source location had 3 folders, 186 files and a size of 694 MB. You can imagine how many folders are being created for the chipset drivers J. (150 folders at 11.2MB each = 1.68GB just for the Chipset.)

• Edited by scarneol Sunday, June 28, 2015 2:21 PM

The Import New Driver Wizard creates a unique folder for each INF it finds within the source folder location and adds all of the required files for each INF into that folder therefore the size of the package grows by the factor of how many INF files found in the source location. For example, I imported just the audio driver for the Dell 9020 Win7 (x64) which contained 1 folder, 62 files (3 INFs), at a size of 231 MB. After the wizard completed, the package source location had 3 folders, 186 files and a size of 694 MB. You can imagine how many folders are being created for the main chipset driver J. 150 INF files (x86 & x64) causes 150 folders to be created and since each folder contains 151 files (inf & cat), a total of 22,650 files are added to the driver package adding 1.68GB to the package just for the Chipset.

  

• Edited by scarneol 12 hours 46 minutes ago

The Import New Driver Wizard creates a unique folder for each INF it finds within the source folder location and adds all of the required files for each INF into that folder therefore the size of the package grows by the factor of how many INF files found in the source location. For example, I imported just the audio driver for the Dell 9020 Win7 (x64) which contained 1 folder, 62 files (3 INFs), at a size of 231 MB. After the wizard completed, the package source location had 3 folders, 186 files and a size of 694 MB. You can imagine how many folders are being created for the main chipset driver J. 150 INF files (x86 & x64) causes 150 folders to be created and since each folder contains 151 files (inf & cat), a total of 22,650 files are added to the driver package adding 1.68GB to the package just for the Chipset.

  

• Edited by scarneol Tuesday, June 30, 2015 6:59 PM

Workaround:

Delete the release.dat files from the Dell driver cabs before importing and that will shrink the size of the driver package by almost half which is enough to get the package to download much faster during the Task Sequence.

Some other details I observed:

The Import wizard seems to do a checksum on the folder containing the INF and not on the INF itself to determine whether the driver has already been added to the driver store so in many cases, especially with the chipset drivers, the x86 driver is identical to the x64 driver but since Dell places a released.dat file in each folder, the import wizard comes up with a different checksum and adds it again to the store and package even though the driver is the same. Shame on you Microsoft for doing checksums at the folder level to determine whether a driver is unique.  

Thanks, i will try this.

Here are two others things you can do to reduce the size of the driver package.

• Break up the main Chipset driver folder that contains a lot of INF files by placing each driver (INF and CAT) files into their own folder. This will reduce the number of files being imported for the chipset driver from 22650 files to just 300 and reducing the size from 3.3GB to just 22MB. There are all kinds of ways to accomplish this but in our case we use the following PowerShell script for the Optiplex 9020.

$dir = \\UIServer01\ConfigMgrDrivers\Optiplex9020\win7\A07"

Get-ChildItem -Path "$dir\*\Chipset\3664n_A00-00" -Recurse -Filter "*.inf" | % {
    if ($_.DirectoryName -like "*\WIN7"){
        $name = $_.Name
        $shrt = ($name.Split("."))[0]
        $path = $_.DirectoryName
        $newDir = "$path\$shrt"
        New-Item -Path "$newDir\" -ItemType directory
        Move-Item -Path "$($_.DirectoryName)\$shrt.inf" -Destination "$newDir\$shrt.inf" -ErrorAction Inquire
        Move-Item -Path "$($_.DirectoryName)\$shrt.cat" -Destination "$newDir\$shrt.cat" -ErrorAction Inquire

• When the Import wizard reaches the Driver Details phase, sort the drivers by "Class", scroll down to the    MEDIA class and make sure only one of the 3 INF files for the MEDIA class is selected. (HDXADC.INF). Do this for both x64 and x86 architectures and it will reduce the size of the driver package another 800MB.

Most likely your driver folder structure will be different but hopefully this code and concept will help some of you.

Doing all 3 things I mention in this thread has reduced the amount of time to prepare and download the driver package from over 1 hour to under 4 minutes.

  

I'm getting the same Issue.

I am running two servers (during migration). One is SCCM 2012 R2 CU4, the new one is SCCM 2012 R2 SP1

I copied over the original 'Source' driver files to the new server and created the driver packages.

On the R2 CU4 - one of the driver packages is 380MB in size with 689 files.

The same driver package on the R2 SP1 - is 1.21GB in size with 11,655 files!

What used to take seconds at the part of the OSD when it downloads drivers, is now taking for ever.

I cancelled the deployment and ticked the option "allow clients to connect anonymously", and now things are quicker, but due to the size and number files downloading, it's not as quick as the other server...

First, for the driver bloat issue see http://blog.configmgrftw.com/the-trouble-with-tribbles-i-mean-drivers/.

For the enabling anonymous, that's generally not a good idea. Enabling authPersistNonNTLM in IIS is a much better choice as my first post above details.

Hi,

now there is Hotfix available, for that large Driver Packages after the Import in SCCM 2012 R2 SP1:

https://support.microsoft.com/en-us/kb/3084586

• Marked as answer by mknuel 11 minutes ago

Hi,

now there is Hotfix available, for that large Driver Packages after the Import in SCCM 2012 R2 SP1:

https://support.microsoft.com/en-us/kb/3084586

• Marked as answer by mknuel 9 minutes ago