When deploying Windows 7 the Apply Driver Package task fails when the ADK is upgraded to the ADK 10 1607 or newer



Update 2017-08-17

The issue with the Install driver package via running DISM with recurse option feature not working when using Access content directly from a distribution point when needed by the running task sequence is being fixed in ConfigMgr Current Branch 1710. We are also exploring backporting the fix to ConfigMgr Current Branch 1706. No guaranteed, but we do expect it to be part of the first update rollup for ConfigMgr Current Branch 1706 when released.

Update 2017-08-11- Issue discovered with Recurse option when using Access Content Directly From DP

An issue has been discovered in the new Install driver package via running DISM with recurse option feature of the Apply Driver Package task in ConfigMgr Current Branch 1706, but it only occurs if the deployment for the Task Sequence is set to Access content directly from a distribution point when needed by the running task sequence (aka “Run from DP”). When the deployment is set to access content directly from the DP, a backslash is added to the end of the drivers UNC path. When a trailing backslash is combined with quotes around the path, this causes the path not to be found and error 2 will be received.

We are currently investigating fixing the issue either in ConfigMgr Current Branch 1710 or possibly a future hotfix in ConfigMgr Current Branch 1706. We do not expect high impact caused from this issue due to the low use of the deployment option of Access content directly from a distribution point when needed by the running task sequence since it is against recommended best practices to use this option. When using the option Access content directly from a distribution point when needed by the running task sequence, hash verification of the content is not performed. For this reason it is not considered as secure as using one of the other two options where content is downloaded locally to the client PC and hash verification performed.

If you are running into this issue, we recommend that you either move away from using the option to Access content directly from a distribution point when needed by the running task sequence or modify one of the below solutions to work with this option. Please be aware that the below solutions have not been tested nor were written with the to Access content directly from a distribution point when needed by the running task sequence option in mind so they may or may not work.

The text of the article below has been updated below to remove trailing backslashes and adding quotes to paths (except for the /Image switch which just points to the root of a drive and requires a backslash), but the screen shots and downloadable Task Sequences have not been modified. If the downloadable Task Sequences are used, make sure to remove trailing backslashes and include quotes around any paths.

Update 2017-08-01 – Configuration Manager Current Branch 1706 with fix released!

Configuration Manager Current Branch 1706 has been released. ConfigMgr CB 1706 has the solution detailed in this blog built right into the Apply Driver Package task via a new option called Install driver package via running DISM with recurse option. This option works in conjunction with the Do unattend installation of unsigned drivers on versions of Windows where this is allowed so it can be used to either allow unsigned drivers or prohibit unsigned drivers.

You can read more information regarding ConfigMgr CB 1706 at the following link:

Now Available: Update 1706 for System Center Configuration Manager
https://blogs.technet.microsoft.com/enterprisemobility/2017/07/28/now-available-update-1706-for-system-center-configuration-manager/

We strongly recommend any customer running into this issue to upgrade to ConfigMgr CB 1706 and use the new option Install driver package via running DISM with recurse option in the Apply Driver Package task to resolve the issue.

As mentioned in the below blog article, keep in mind that an added benefit to the Install driver package via running DISM with recurse option feature is that the DISM.log now shows the individual drivers being installed. This not only allows you to see what drivers exactly are being installed, but also the result of each driver install. This should make troubleshooting driver installs easier. This use to not be possible with the unattend method because the driver installs were “hidden” within the unattend file and the unattend driver install process. In other words, this method of installing drivers may be beneficial even when not running into the issue described in this blog or when deploying OSes not affected by the issue (e.g. Windows 10).

Update 2017-06-26 – FIX!

Starting with Configuration Manager Technical Preview 1706, the solution in this blog of using the DISM.exe /Add-Driver /Recurse option instead of the /Apply-Unattend option has now been implemented directly in the Apply Driver Package task. The Apply Driver Package task will still default to the /Apply-Unattend option, but a new option has been added to the Apply Driver Package task that allows you to use the /Add-Driver /Recurse option instead. This new option is shown in the below screenshot:

New Apply Driver Package Task

This new option works in conjunction with the option Do unattended installation of unsigned drivers on versions of Windows where this is allowed. This means that you do not need to set the variable OSDAllowUnsignedDriver or worry about any of the related conditions as documented in the blog post. Just check the option if you want to allow unsigned drivers, or leave it unchecked if you do not want to allow unsigned drivers.

This new option in the Apply Driver Package task is expected to be in Configuration Manager Current Branch 1706 when it is released later this year as long as no major problems are found or reported with this new option. Unfortunately due to the large changes necessary in the Apply Driver Package to implement this new option, this option will not be backported to previous versions of Configuration Manager Current Branch and will only be available in Configuration Manager Current Branch 1706 and newer.

Update 2017-06-08 – Root Cause Determined

We have identified root cause as a Windows 7 provider being loaded into DISM not handling sharing violations when accessing the registry. Windows 8.1 and newer has code in it that handle sharing violations when accessing the registry. The sharing violations are more likely to occur the faster a PC is due to the registry being loaded and unloaded more quickly. Because Windows 7 is in extended support and because this issue is not a security issue, a fix will not be made in Windows 7 directly.

As mentioned in the article below, we have seen this issue in ADKs prior to 1607, but we believe the issue became more prevalent with ADK 1607 and newer due to performance enhancements done in DISM in the ADK 1607. This issue is not a bug in DISM or the ADK. Updating to newer ADKs (1703) will not fix the issue as there is nothing to fix in the ADK.

Downgrading the boot image (not the ADK) to something older than 1607 may temporarily fix the issue, but can theoretically still occur, especially as PCs get faster and faster. Also downgrading to older boot images may also run into supportability issues as documented in the following support matrix:

Windows 10 ADK

Because the issue is not in the ADK and because the issue will not be fixed in Windows 7, we are currently exploring ways of possibly fixing the issue in ConfigMgr. This is not a guarantee that a fix will be in ConfigMgr, but we are fully aware of the issue and the impact that it is having on customers. For this reason we are exploring all avenues for a fix.

Symptoms

After installing the ADK 10 1607 on ConfigMgr Current Branch 1602 or newer, the Apply Driver Package task will start failing while installing one of the drivers in the Driver Package. The failure is random and will not occur on the same driver every time. Occasionally the Apply Driver Package task may succeed.

Cause

The issue is currently under investigation by Microsoft. At at high level, ConfigMgr calls DISM to install drivers during the Apply Driver Package task. ConfigMgr can call DISM multiple times during the Apply Driver Package task depending on the Driver Package structure. The problem seems to be caused by DISM trying to load the registry of the offline OS when it has not finishing unloading the registry from a previous driver install registry load. This issue primarily happens on faster PCs with SSD drives, mainly SSD NVME drives, but can occur on any PC.

Looking at the SMSTS.log you will see ConfigMgr calling DISM multiple times (in this case 9 times) to install the drivers:

11-22-2016 18:20:35.106    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:20:37.863    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:20:39.965    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:20:43.238    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:18.742    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:23.704    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:33.332    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:35.256    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:37.138    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

During the last driver install, it fails with the following error:

11-22-2016 18:21:37.138    OSDDriverClient    Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:38.368    OSDDriverClient    Process completed with exit code 2147500037

11-22-2016 18:21:38.368    OSDDriverClient    uExitCode == 0, HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\osddriverclient\sysprepdriverinstaller.cpp,548)

11-22-2016 18:21:38.368    OSDDriverClient    Dism failed with return code -2147467259

11-22-2016 18:21:38.368    OSDDriverClient    AddPnPDriverToStore( pszSource, sTargetSystemDrive, sTargetSystemRoot, wProcessorArchitecture), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\osddriverclient\sysprepdriverinstaller.cpp,658)

11-22-2016 18:21:38.368    OSDDriverClient    Failed to add driver to driver store. Code 0x80004005

11-22-2016 18:21:38.368    OSDDriverClient    InstallDriver( iInstallParams->sContentId, iInstallParams->sSource, iInstallParams->pBootCriticalInfo ), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\osddriverclient\driverinstaller.cpp,557)

11-22-2016 18:21:38.368    OSDDriverClient    ReleaseSource() for C:\_SMSTaskSequence\Packages\C660005F.

11-22-2016 18:21:38.368    OSDDriverClient    reference count 1 for the source C:\_SMSTaskSequence\Packages\C660005F before releasing

11-22-2016 18:21:38.368    OSDDriverClient    Released the resolved source C:\_SMSTaskSequence\Packages\C660005F

11-22-2016 18:21:38.368    OSDDriverClient    pDriverInstaller->InstallDriverPackage( sPackageId, pBootCriticalInfo ), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\osddriverclient\osddriverclient.cpp,380)

11-22-2016 18:21:38.368    OSDDriverClient    Failed to provision driver. Code 0x80004005

11-22-2016 18:21:38.368    OSDDriverClient    Exiting with return code 0x80004005

11-22-2016 18:21:38.384    TSManager    Process completed with exit code 2147500037

11-22-2016 18:21:38.384    TSManager    !--------------------------------------------------------------------------------------------!

11-22-2016 18:21:38.399    TSManager    Failed to run the action: Apply Driver Package.

Unspecified error (Error: 80004005; Source: Windows)

Looking at the DISM.log you will see commands that match the same time frame from the SMSTS.log. In this case we see it attempt to install drivers 9 times:

11-22-2016 18:20:35.000    DISM       DISM.EXE: Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:20:37.000    DISM       DISM.EXE: Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:20:39.000    DISM       DISM.EXE: Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:20:43.000    DISM       DISM.EXE: Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:18.000    DISM       DISM.EXE: Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:23.000    DISM       DISM.EXE: Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:33.000    DISM       DISM.EXE: Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:35.000    DISM       DISM.EXE: Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

11-22-2016 18:21:37.000    DISM       DISM.EXE: Executing command line: "X:\WINDOWS\system32\dism.exe" /image:"C:" /windir:"WINDOWS" /apply-unattend:"C:\_SMSTaskSequence\PkgMgrTemp\drivers.xml" /logpath:"C:\_SMSTaskSequence\PkgMgrTemp\dism.log"

Most of the driver installations will work. However the last one will fail with the following error message:

11-22-2016 18:21:38.000    CBS        Loading offline registry hive: schema.dat, into registry key '{bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/Windows/system32/smi/store/Machine/schema.dat' from path '\\?\C:\Windows\system32\smi\store\Machine\schema.dat'.

11-22-2016 18:21:38.000    CBS        Failed to load offline schema.dat hive from '\\?\C:\Windows\system32\smi\store\Machine\schema.dat' into registry key '{bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/Windows/system32/smi/store/Machine/schema.dat'. [HRESULT = 0x80070020 - ERROR_SHARING_VIOLATION]

11-22-2016 18:21:38.000    CBS        Failed to load SMI schema hive [HRESULT = 0x80070020 - ERROR_SHARING_VIOLATION]
 

11-22-2016 18:21:38.000    CBS        Failed to load offline store from boot directory: '\\?\C:\' and windows directory: '\\?\C:\Windows\' [HRESULT = 0x80070020 - ERROR_SHARING_VIOLATION]

11-22-2016 18:21:38.000    CBS        Failed to initialize store parameters with boot drive: C:\ and windows directory: C:\Windows [HRESULT = 0x80070020 - ERROR_SHARING_VIOLATION]

11-22-2016 18:21:38.000    DISM       DISM Package Manager: PID=2232 Failed initializing the session - CDISMPackageManager::RefreshInstanceAndLock(hr:0x80070020)

11-22-2016 18:21:38.000    DISM       DISM Package Manager: PID=2232 Failed doing internal initialization - CDISMPackageManager::Initialize(hr:0x80070020)

11-22-2016 18:21:38.000    DISM       DISM Provider Store: PID=2232 Failed to call Initialize method on IDismServicingProvider Interface - CDISMProviderStore::Internal_LoadProvider(hr:0x80070020)

11-22-2016 18:21:38.000    DISM       DISM Provider Store: PID=2232 Failed to Load the provider: C:\_SMSTaskSequence\PkgMgrTemp\5329B70A-F697-49DD-98B7-63628584B5C7\CbsProvider.dll. - CDISMProviderStore::Internal_GetProvider(hr:0x80070020)

Please note the main error message is 0x80070020 ERROR_SHARING_VIOLATION. You may also see some access denied error messages in the DISM.log such as the following error message:

11-22-2016 18:21:38.000    CBS        Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/Users/default/ntuser.dat, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]

This is actually normal and non-fatal. Is it not relevant to this issue. If you inspect the other successful driver installs you will see similar non-fatal access denied errors.

This issue is actually not new to the ADK 10 1607 and has been seen with previous versions of the ADK and ConfigMgr. In previous versions of the ADK and ConfigMgr the issue was very rare and was mainly seen only when customers were performing modifications in WinPE that increased performance during the Task Sequence. The following blog article details one such method:

Reducing Windows Deployment time using Power Management

https://blogs.technet.microsoft.com/deploymentguys/2015/03/26/reducing-windows-deployment-time-using-power-management/

If you are doing any modifications such as the one from the above blog article we recommend temporarily disabling these modifications to resolve the issue.

We believe that the issue has become more prevalent with the ADK 10 1607 due to possible performance optimizations done in the ADK, DISM, ConfigMgr, or any combination of the three. Most reports on the issue also seem to indicate that the issue is mainly with Windows 7. However we do not think that the issue is specific to Windows 7 as we have seen the issue occur in other versions of Windows besides Windows 7. We believe the issue may just be more prone to occur with Windows 7 installations due to the higher amount of drivers needed for Windows 7. After further investigation we believe this issue is indeed only limited to Windows 7. We previously thought we had seen this issue in versions of Windows other than Windows 7 but we have gone back and verified all reported instances and they are all Windows 7. We believe we know the root cause as to why this is happening in Windows 7 but we are still investigating.

The issue is still under investigation though so full root cause is not currently known. Please see update at the beginning of the article for root cause.

Resolution

While Microsoft investigates the issue, we are providing some workarounds that resolves the issue. Two workarounds still use Driver Packages while the last workaround use the Auto Apply Drivers task. At a high level, the three workarounds work as follows:

  1. Workaround 1 attempts to first use the Apply Driver Package task. If it fails, then it tries to install drivers again but this time by using DISM directly and using a different DISM command line that does not run into the issue. The DISM command line uses the driver content already downloaded by the Apply Driver Package. This workaround resolves the problem by only having to initiate one registry load/unload during the DISM driver injection process.
      
  2. Workaround 2 does not use the Apply Driver Package at all. Instead it uses the Download Package Content task to first download the Driver Package to a specified directory and then using more or less the same command line from Workaround 1, it installs the drivers. This workaround also resolves the problem by only having to initiate one registry load/unload during the DISM driver injection process. Since the Download Package Content task is only available with ConfigMgr Current Branch, this workaround cannot be used with older versions of ConfigMgr (ConfigMgr 2012 SP2/R2 SP1 or ConfigMgr 2007).
      
  3. Workaround 3 uses the Auto Apply Driver Package task but limits the drivers to be installed to only those in the Driver Package for the specific model PC. The limiting is accomplished via a driver category that is unique to the drivers in a specific Driver Package. This workaround resolves the problem because the time between DISM drive injections is greater because the driver has to be downloaded in between driver injections. This gives DISM more time to finish the registry loads/unloads. Please note that it is theoretically still possible to hit the issue using the workaround although the chances of it occurring are greatly diminished.

Pros and cons of each workaround are detailed at the end of the article.

Follow the instructions below for the workaround you wish to use. You can go directly to each workaround by clicking on the link to the workaround above. You can also download an exported Task Sequence that has the steps for Workaround 1 and Workaround 2. The exported Task Sequence can then be imported into an environment to simplify setting up the workaround.

 

Workaround #1 – Retry driver install via manual DISM command if Apply Driver Package task fails

Please note that the below instructions are for one individual Apply Driver Package task. You will need to repeat the process for each individual Apply Driver Package task (usually specific to a model PC) that you have in the Task Sequence. The below screenshots use a Surface Pro 3 as an example model PC:

  1. In the ConfigMgr console, right click on the affected Task Sequence and choose Edit.

     

    ADP1-1

     

  2. Click on the Apply Driver Package task.
     

    ADP1-2
      
  3. In the Apply Driver Package task, click on the Options tab, and then select Continue on Error.

     

    ADP1-3

     

  4. Immediately after the Apply Driver Package task, add a new Group by going to the Add menu and selecting New Group.

     

    ADP1-4

     

  5. Click on the newly created Group. In the Name: field, give it the name Retry if Failed (this can actually be any name of your choosing).
     

    ADP1-5
      
  6. On the Retry if Failed group, click on the Options tab, then click on the Add Condition menu and select Task Sequence Variable.
     

    ADP1-6
      
  7. In the Task Sequence Variable condition box enter in the following values:

     

    Variable:

    _SMSTSLastActionSucceeded

     

    Condition:

    equals

     

    Value:

    false

     

    Click on the OK button.
     

    ADP1-7
     

    ADP1-7a
      
  8. Under the Retry if Failed group, add a Set Task Sequence Variable task by going to the Add menu and selecting General –> Set Task Sequence Variable.

     

    ADP1-8

     

  9. Click on the newly created Set Task Sequence Variable task and then configure as follows:

     

    Name:

    Set Whether Or Not To Allow Unsigned Drivers

     

    Task Sequence Variable:

    OSDAllowUnsignedDriver

     

    Value:

    Set to true to allow installation of unsigned drivers. Set to false to not allow installation of unsigned drivers.
     

    true

    ADP1-9t
     

    false

    ADP1-9f
      
  10. Immediately after the Set Whether Or Not To Allow Unsigned Drivers task and under the Retry if Failed group, add a Run Command Line task by going to the Add menu and selecting General –> Run Command Line.

     

    ADP1-10

     

  11. Click on the newly created Run Command Line task and then configure as follows:

     

    Name:

    Install Drivers via DISM Recurse - No Unsigned

     

    Command line:

    DISM.exe /Image:%OSDTargetSystemDrive%\ /Add-Driver /Driver:"%_SMSTSPackageCacheLocation<Driver_Package_ID>%" /Recurse /logpath:"%_SMSTSLogPath%\dism.log"

     

    Replace the value <Driver_Package_ID> with the Driver Package ID of the Driver Package being specified in Step 2. Do not include the brackets (<>). For example %_SMSTSPackageCacheLocationC6200030%.
     

    ADP1-11
     

    The Driver Package ID of the Driver Package can be obtained clicking on the Driver Packages node in the ConfigMgr console and inspecting the Package ID column (add this column if it is not visible).
     

    ADP1-11a
      
  12. In the Install Drivers via DISM Recurse - No Unsigned task, click on the Options tab, then click on the Add Condition menu and select Task Sequence Variable.
     

    ADP1-12
      
  13. In the Task Sequence Variable condition box enter in the following values:

     

    Variable:

    OSDAllowUnsignedDriver

     

    Condition:

    equals

     

    Value:

    false

     

    Click on the OK button.
     

    ADP1-13
     

    ADP1-13a
      
  14. While still under the Options tab of the Install Drivers via DISM Recurse - No Unsigned task, add in 50 as an additional success code (do not remove 0 or 3010). Error code 50 is returned when DISM tries to install a driver that is not signed and the /forceunsigned switch is not used. The error is not fatal and DISM will continue to install additional drivers.
     

    ADP1-14
      
  15. Immediately after the Install Drivers via DISM Recurse - No Unsigned task and under the Retry if Failed group, add a second Run Command Line task by going to the Add menu and selecting General - - > Run Command Line.

     

    ADP1-15

     

  16. Click on the newly created Run Command Line task and then configure as follows:

     

    Name:

    Install Drivers via DISM Recurse - Allow Unsigned

     

    Command line:

    DISM.exe /Image:%OSDTargetSystemDrive%\ /Add-Driver /Driver:"%_SMSTSPackageCacheLocation<Driver_Package_ID>%" /Recurse /forceunsigned /logpath:"%_SMSTSLogPath%\dism.log"

     

    Replace the value <Driver_Package_ID> with the Driver Package ID of the Driver Package being specified in Step 2. Do not include the brackets (<>). For example %_SMSTSPackageCacheLocationC6200030%.
     

    ADP1-16
     

    The Driver Package ID of the Driver Package can be obtained clicking on the Driver Packages node in the ConfigMgr console and inspecting the Package ID column (add this column if it is not visible).
     

    ADP1-16a
      
  17. In the Install Drivers via DISM Recurse - Allow Unsigned task, click on the Options tab, then click on the Add Condition menu and select Task Sequence Variable.
     

    ADP1-17
      
  18. In the Task Sequence Variable condition box enter in the following values:

     

    Variable:

    OSDAllowUnsignedDriver

     

    Condition:

    equals

     

    Value:

    true
     

    Click on the OK button.
     

    ADP1-18
     

    ADP1-18a
      
  19. Click on the OK or Apply button to save the Task Sequence.
     

    ADP1-19
      
  20. Repeat steps 1-19 for any additional Apply Driver Package tasks.

 

Notes:

  1. In our testing of the workaround we saw certain problematic drivers where the INF file of the driver refers to files that do not exist in the driver source files. This causes an error code of 2 to be returned by DISM for those driver installs. Although ultimately DISM sees this as a non-fatal error and continues to install additional drivers, it can cause the Run Command Line tasks from steps 15 or 20 to report as failed even though all non-problematic drivers installed successfully. To correct this issue, you can do one of following three things:
      
    • Under the Options tab of the Run Command Line tasks in steps 15 and 20, add 2 as a success code in the Success codes: text box. Do not remove any other success codes that are already in the Success codes: text box. See step 18 for additional details on adding additional success codes to the Success codes: text box. 
    • Remove the problematic driver(s) from the Driver Package. The problematic driver can be identified by looking at what driver install failed (specifically error code 2) in the DISM.log.

    • Under the Options tab of the Run Command Line tasks from steps 15 and 20, check the option Continue on Error. This method is not recommended though since this could potentially hide other errors that may occur.
       
  2. Steps 8 and 9 can be eliminated by setting the value of the variable OSDAllowUnsignedDriver via other methods such as Collection or Object variables.
      
  3. If installation of unsigned drivers is either always desired or never desired, then some steps can be eliminated. To eliminate unneeded steps, only follow the below steps:

    • Always allow unsigned drivers – Follow steps 1-7, 15-16, 19-20
    • Never allow unsigned drivers – Follow steps 1-7, 10-11, 14, 19-20

 

Workaround #2 – Download Driver Package via Download Package Content task and then install drivers via a manual DISM command

Please note that the below instructions are for one individual Apply Driver Package task. You will need to repeat the process for each individual Apply Driver Package task (usually specific to a model PC) that you have in the Task Sequence. The below screenshots use a Surface Pro 3 as an example model PC:

  1. In the ConfigMgr console, right click on the affected Task Sequence and choose Edit.

     

    ADP2-1
      
  2. Click on the Apply Driver Package task.
      

    ADP2-2
      
  3. In the Apply Driver Package task, click on the Options tab, and then select Disable this step.

      

    ADP2-3
      
  4. In the Apply Driver Package task, under the Options tab copy and make note of any conditions that are in that task.
      

    ADP2-4
     

    ADP2-4a
      
  5. Immediately after the Apply Driver Package task, add a new Group by going to the Add menu and selecting New Group.

     

    ADP2-5
      
  6. Click on the newly created Group. In the Name: field, give it the name Install Drivers for Model x. Replace Model x with the model PC that you are installing drivers for (this name can actually be any name of your choosing).
     

    ADP2-6
       
  7. On the Install Drivers for Model x group, click on the Options tab. Copy back any conditions that were notated in Step 4.
     

    ADP2-7
     

    ADP2-7a
      
  8. Under the Install Drivers for Model x group, add a Set Task Sequence Variable task by going to the Add menu and selecting General - - > Set Task Sequence Variable.

     

    ADP2-8
      
  9. Click on the newly created Set Task Sequence Variable task and then configure as follows:

     

    Name:

    Set Whether Or Not To Allow Unsigned Drivers

     

    Task Sequence Variable:

    OSDAllowUnsignedDriver

     

    Value:

    Set to true to allow installation of unsigned drivers. Set to false to not allow installation of unsigned drivers.
     

    true

    ADP2-9t
      

    false

    ADP2-9f
      
  10. Under the Install Drivers for Model x group, add a Download Package Content task by going to the Add menu and selecting Software - - > Download Package Content.

     

    ADP2-10

     

  11. In the Download Package Content task, click on the yellow starburst icon.

     

    ADP2-11

     

  12. In the Select a package window, locate and click on the Driver Package for the model PC and then click on OK. Please note that all Driver Packages will be under the Root folder. The custom folders under the Driver Packages node are not preserved in this selection window.

     

    ADP2-12
     

    ADP2-12a
     

  13. In the Download Package Content task, click on the option Custom Path: and then enter in the following value:



    %_SMSTSMDataPath%\Drivers
     

    ADP2-13
     

  14. Immediately after the Download Package Content task and under the Install Drivers for Model x group, add a Run Command Line task by going to the Add menu and selecting General - - > Run Command Line.

     

    ADP2-14
     

  15. Click on the newly created Run Command Line task and then configure as follows:

     

    Name:

    Install Drivers via DISM Recurse - No Unsigned

     

    Command line:

    DISM.exe /Image:%OSDTargetSystemDrive%\ /Add-Driver /Driver:"%_SMSTSMDataPath%\Drivers" /Recurse /logpath:"%_SMSTSLogPath%\dism.log"
     

    ADP2-15
     

  16. In the Install Drivers via DISM Recurse - No Unsigned task, click on the Options tab, then click on the Add Condition menu and select Task Sequence Variable.
     

    ADP2-16
      
  17. In the Task Sequence Variable condition box enter in the following values:

     

    Variable:

    OSDAllowUnsignedDriver

     

    Condition:

    equals

     

    Value:

    false

     

    Click on the OK button
     

    ADP2-17
     

    ADP2-17a
      
  18. While still under the Options tab of the Install Drivers via DISM Recurse - No Unsigned task, add in 50 as an additional success code (do not remove 0 or 3010). Error code 50 is returned when DISM tries to install a driver that is not signed and the /forceunsigned switch is not used. The error is not fatal and DISM will continue to install additional drivers.
     

    ADP2-18
      
  19. Immediately after the Install Drivers via DISM Recurse - No Unsigned task and under the Install Drivers for Model x group, add a second Run Command Line task by going to the Add menu and selecting General - - > Run Command Line
     

    ADP2-19
     

  20. Click on the newly created Run Command Line task and then configure as follows:

     

    Name:

    Install Drivers via DISM Recurse - Allow Unsigned

     

    Command line:

    DISM.exe /Image:%OSDTargetSystemDrive%\ /Add-Driver /Driver:"%_SMSTSMDataPath%\Drivers" /Recurse /forceunsigned /logpath:"%_SMSTSLogPath%\dism.log"
     

    ADP2-20
     

  21. In the Install Drivers via DISM Recurse - Allow Unsigned task, click on the Options tab, then click on the Add Condition menu and select Task Sequence Variable.
     

    ADP2-21
      
  22. In the Task Sequence Variable condition box enter in the following values:

     

    Variable:

    OSDAllowUnsignedDriver

     

    Condition:

    equals

     

    Value:

    true

     

    Click on the OK button
     

    ADP2-22
     

    ADP2-22a
      
  23. Click on the OK or Apply button to save the Task Sequence.
     

    ADP2-23
      
  24. Repeat steps 1-23 for any additional Apply Driver Package tasks

Notes:

  1. In our testing of the workaround we saw certain problematic drivers where the INF file of the driver refers to files that do not exist in the driver source files. This causes an error code of 2 to be returned by DISM for those driver installs. Although ultimately DISM sees this as a non-fatal error and continues to install additional drivers, it can cause the Run Command Line tasks from steps 11 or 16 to report as failed even though all non-problematic drivers installed successfully. To correct this issue, you can do one of following three things:
      
    • Under the Options tab of the Run Command Line tasks in steps 11 and 16, add 2 as a success code in the Success codes: text box. Do not remove any other success codes that are already in the Success codes: text box. See step 18 for additional details on adding additional success codes to the Success codes: text box. 
    • Remove the problematic driver(s) from the Driver Package. The problematic driver can be identified by looking at what driver installs failed (specifically error code 2) in the DISM.log.

    • Under the Options tab of the Run Command Line tasks from steps 11 and 16, check the option Continue on Error. This method is not recommended though since this could potentially hide other errors that may occur.
       
  2. Steps 8 and 9 can be eliminated by setting the value of the variable OSDAllowUnsignedDriver via other methods such as Collection or Object variables.
      
  3. If installation of unsigned drivers is either always desired or never desired, then some steps can be eliminated. To eliminate unneeded steps, only follow the below steps:
      
    • Always allow unsigned drivers – Follow steps 1-7, 10-13, 19-20, 18, 23-24
    • Never allow unsigned drivers – Follow steps 1-7, 10-15, 23-24

 

Workaround #3 – Auto Apply Drivers task which only installs drivers from a specific Driver Package based on Driver Categories

Coming soon

 

Pros and Cons of each workaround:

Workaround #1

Pros

  1. Attempts to use the Apply Driver Package task first. If it succeeds, then the workaround never kicks in.

Cons

  1. Needs manually setting of the Driver Package ID in the DISM command lines found in the Run Command Line tasks.
  2. Could potentially take longer to run since it first attempts to use the Apply Driver Package task. If the Apply Driver Package task fails, then some of the time spent running the task will have been wasted. Some of the time running the task however is still useful (i.e. downloading of Driver Package content).

Workaround #2

Pros

  1. May be faster since it never attempts the Apply Driver Package, therefore no time is wasted on a failure.
  2. Does not need any modifications to the DISM command lines found in the Run Command Line tasks.

Cons

  1. Never attempts to use the out of box Apply Driver Package task.
  2. Needs transfer of conditions from the Apply Driver Package task to the Install Driver group.
  3. Has more overall steps
  4. Since the Download Package Content task is only available with ConfigMgr Current Branch, this workaround cannot be used with older versions of ConfigMgr (ConfigMgr 2012 SP2/R2 SP1 or ConfigMgr 2007).
  5. Cannot be used with stand-alone media since stand-alone media does not support the Download Package Content task:

    Create stand-alone media with System Center Configuration Manager

Workaround #3

Pros

  1. Only drivers of hardware that is actually detected on the device is added to the offline OS driver store.

Cons

  1. Could potentially still run into the issue if some of the driver downloads are small.
  2. Pro #1 listed above may be a con if admin wants to force all drivers in the Driver Package to be added to the offline OS driver store. This could be used to account for hardware that is not currently connected to the device but may be connected later (i.e. printers).
  3. Never attempts to use the out of box Apply Driver Package task.
  4. May take longer in certain scenarios since a hardware scan needs to take place on the device and the appropriate drivers located via a query to the MP.
  5. Cannot be used with stand-alone media since stand-alone media does not support the Auto Apply Drivers task:

    Create stand-alone media with System Center Configuration Manager

Frank Rojas

Senior Support Escalation Engineer

This post is provided "AS IS" with no warranties, and confers no rights. The solution is not officially supported. Any support provided by Microsoft regarding this solution may be limited. Microsoft does not guarantee the solution will work in all environments and/or scenarios.


Comments (71)

  1. Stephen says:

    Frank,
    These workarounds may work but they aren’t pretty. Ant Idea when we can expect a fix for this issue?

    1. Frank Rojas says:

      At this point the issue is still under investigation so it’s too early to give timelines regarding any fixes. The workarounds are not that complex and if you decide on either always allowing unsigned or never allowing unsigned, it results in only a max of 2 more tasks per model PC. There are actually also some benefits to the workarounds vs. out of box tasks such as seeing the installation of each individual driver vs. being hidden in XML files.

      1. Stephen says:

        Frank You are the greatest. Only a Microsoft engineer can show the benefits of a bug with no root cause and no resolution on the horizon….Seriously though, thanks for this article. I used apply drivers for all but one model. For some reason I the Dell 7470 USB 3.0 drivers aren’t installing for me with auto apply. I went with the second work around and striped it down to 2 steps, package download and dism. So far so good.

  2. Darin says:

    Frank,
    Thank you for finally documenting this. I too have seen this happen on a rare occasion over the last couple years with multiple versions on WinPE. We never nailed it done, and it almost always worked by restarting the Task Sequence. After switching to the 1607 boot media, we found it extremely repeatable on a couple server models. Therefore I was forced to find a workaround, and use a method extremely similar to your Method #2, except I use a standard “Run Command Line” action to download the driver package first and therefore can be used with older versions of Config manager.

    From the Procmon traces I ran, I personally think the culprit is osddriverclient.exe, and not DISM.exe. osddriverclient.exe appears to be making some api calls which create a handle to the offline registry prior to launching DISM.exe, it’s that handle that is not being cleaned up in time in some cases.

    Feel free to reach out if you or an engineer want to chat more about the details of the testing I did. Looking forward to a good fix for this as well, and would be happy to confirm it in our lab for you.

    Darin

    1. Frank Rojas says:

      Thanks for the info. One of the difficulties we have had is that attaching any type of debugging tools slows down the process enough where it no longer occurs. However we were able to finally get a ProcMon so we are taking a look at that now.

  3. Jim Webb says:

    It’s important to note that in order for the “Download Package Content” option to work, the deployment of the task sequence has to be configured to “Download content locally…” instead of “Access content directly..”.

    1. Frank Rojas says:

      That is correct. Download Package Content is a conflicting method to Access content directly (they are exact opposites) so using Access content directly is not supported when using Download Package Content in a Task Sequence. There is actually a DCR to change the behavior in a future version of ConfigMgr to disable Access content directly if a Task Sequence has the Download Package Content task in it. Additionally it is against recommended best practices to use the option Access content directly and considered less secure since no hash checking is done when using Access content directly.

  4. Thomas P says:

    Thanks for a great article!

    I tested Workaround 3 for the computer model that did not work with the Apply Driver Package step in my invironment (HP Elite Desk 800 G2 SFF). The end result was unfortunately not as desired. Auto Apply step worked but suddenly did not install 3 drivers which otherwise have worked excellently via the Apply Driver Pack step.

    Will test if it works better with Workaround 1 or 2, but hope for a solution soon. Otherwise, one is forced to return to the “copy in an old DISM file during the OSD” just like when ADK 1511 came and nothing worked.

  5. Thomas P says:

    I can confirm that Workaround 2 works and if you don’t need all the Unsigned/SignedDriver stuff it will just add 1 group and 2 steps.

    If you are thinking about a quick fix and about trying Workaround 3, don’t! That one got me i truble and I wouldn’t recomend it. Some drivers were missing after deployment with Workaround 3.

  6. Mihkel Soomere says:

    One more workaround: copy powercfg.exe from full OS and use it to throttle CPU to minimum possible frequency during Apply Driver Package step.

    1. Frank Rojas says:

      We actually used this workaround with a few customers and confirmed it did fix the problem sometimes if you set the power plan as Energy Saver. However on some faster PCs it still did not fix the problem. We thought about documenting this workaround but the combination of not always fixing the problem and having to add PowerCfg.exe did not make it the most ideal workaround.

  7. Baard Hermansen says:

    Has this been seen without upgrading ADK? That is, when installing the ADK 1607 as part of a new CB site installation?

    1. Frank Rojas says:

      Yes we have seen this prior to ADK 1607 but as mentioned in the article, it was a much rarer occurrence and only really seen when admins were trying to do performance improvements to the Task Sequence using PowerCfg.exe.

      1. Frank – Just encountered this problem and I am using powercfg. These are none SSD drives. Disabled the powercfg step and all is good on this occasion.

  8. Flash says:

    On Workaround #2, are you sure these are correct?
    ◦Always allow unsigned drivers – Follow steps 1-7, 10-13, 14-15, 18, 23-24
    ◦Never allow unsigned drivers – Follow steps 1-7, 10-13, 19-20, 23-24
    It seems to me you’d want to follow steps 14,15 if you never allow unsigned drivers. Maybe my misunderstanding.
    Also, do I even need the OSDAllowUnsignedDriver variable if I never want to allow unsigned drivers?

    Thanks,

    1. Frank Rojas says:

      Yes I apologize I got the steps to follow reversed for both Workaround #1 and Workaround #2. I have corrected it now. You only need the variable OSDAllowUnsignedDriver if you want to switch between allowing and not allowing unsigned drivers. If you know you always want one or the other, then no you do not need to use the variable OSDAllowUnsignedDriver (which is why you can skip of the steps that set and use this variable).

  9. Peipei says:

    Thanks, Frank,
    We have this issue as well after upgrade to new version.
    Do you have any update from MS so far?

    1. Frank Rojas says:

      No update yet. We are still investigating. Investigation may take a few more weeks. We will update everyone with what we find and potential fixes once we have them.

      1. Ariendg says:

        Any news on a permanent fix for this? 🙂
        I would like to keep using the 1607 WinPE/ADK.

        1. Frank Rojas says:

          No. When we have news we will post it here. We are getting at the real root cause of this issue and as it currently stands, it will probably be a while before we have further updates.

          1. Yavor says:

            Hello Frank,
            I had the same issue and when I read the comments I have released that the power plans in WinPE are causing the issue as well.
            In WinPE I set power plan to “High Performance” to be able to save time applying the Operation System faster.
            This was advised from OS gurus and it really save time.
            When I have removed the step that apply “High Performance” plan the issue does not happen anymore.

          2. Frank Rojas says:

            Good to hear. You can technically still use the High Performance plan. You just have to slow it down while the Apply Driver Package task runs, and then speed it back up after the Apply Driver Package task. You can do this using one of the following two commands as a Run Command Line task before the Apply Driver Package:

            Balanced: PowerCfg.exe /s 381b4222-f694-41f0-9685-ff5bb260df2e
            Power Saver: PowerCfg.exe /s a1841308-3541-4fab-bc81-f71556f20b4a

            We actually used this solution to resolve some customers when we first started to investigate the issue.

          3. Hazza says:

            Hi Frank,

            Any update on a perm fix for this issue?

            Thanks

          4. Frank Rojas says:

            No. Please see my reply to Peipei on 1/10 and Ariendg on 1/17.

  10. Thanks Frank!
    Also to note, ‘Auto Apply Drivers’ will not work with stand-alone media deployments.

    1. Frank Rojas says:

      Thank you Brandon. Yes you are correct. The Auto Apply Drivers task is not supported with stand-alone media so you would not be able to use Workaround #3 with stand-alone media.

  11. Flash says:

    When using PXE boot, workaround #2 works fine. However, when I create standalone media (for USB boot) using the same OSD task sequence for use in a standalone environment, the driver packages are not loading. Any idea why this would be?

    1. Frank Rojas says:

      I need to check if the Download Package Content task is supported with stand-alone media. Since stand-alone media is designed to be used “off network”, the Download Package Content task may not be supported with stand-alone media. You will probably need to use Workaround #1 instead for stand-alone media.

      1. Frank Rojas says:

        I just found the docs that says that Download Package Content task is not supported for stand-alone media:

        https://docs.microsoft.com/en-us/sccm/osd/deploy-use/create-stand-alone-media

        You will need to use Workaround #1 for stand-alone media.

        1. Matthew says:

          Clearly you’re right, the Download Package Content step does not work with stand-alone media. But I think maybe it should. Is this something we could see added in a future version of SCCM?

          1. Frank Rojas says:

            You can request features like this over at the ConfigMgr UserVoice page. The more users you to get to vote up a feature, the more attention it will get and the more likely it will be implemented

            https://configurationmanager.uservoice.com/forums/300492-ideas

  12. Chris Gibson says:

    I’m getting a 0x0000002 task sequence error right after the downloading package content. Have you seen this before?

    1. Frank Rojas says:

      Error 2 is File Not Found. With the minimal amount of information you provided I have no idea why you are receiving this error message.

  13. Wolfgang Gürtl says:

    Downgrade the WinPE dism-subsystem to 1511 “before Apply driver Package”. This worked for me very well.

    1. Frank Rojas says:

      Downgrading to WinPE 10 1511 or for that matter, just the DISM in WinPE 10 1511, does not guarantee that the issue won’t still occur. Yes this is a solution that can be used, but it will not always work.

    2. Ben says:

      How do you Downgrade the WinPE dism-subsystem to 1511 “before Apply driver Package”.

      1. Frank Rojas says:

        You can’t downgrade the WinPE DISM to 1511 while in 1607 (or I should rephrase that there is not a supported way to do so). If you want to use the 1511 DISM then just use 1511 boot images.

  14. etsmi says:

    Still no update to this problem..? Sad to do a workaround for 5 different customer sccm environments with insane amounts of computer models..

    1. Frank Rojas says:

      No, and there probably will not be for at least several months. Since the core issue is in Windows 7, and Windows 7 is in extended support, the root cause of the issue is not going to be fixed since it is not a security issue. We are looking at ways to mitigate the issue via ConfigMgr, but it may require major code rewrite. Windows 10 does not have the issue so if you have not started to take a look at migrating to Windows 10, this may be a good time to start looking at that option. Windows 7 is less than 3 years from end of life and it’s never too early to start looking at migrating to newer versions of Windows.

      1. sebus says:

        I have this issue ONLY for a single Dell model – Optiplex 3040. Any other model works fine!

      2. Afraskai says:

        Hi MS Team,

        did you find the reason for this issue? Ist really a pain, the workarounds dont work in some cases (e.g. Dell Optiplex 7010). We want to migrate to Windows 10 but many Applications like Catia, EE Apps and more are not ready for Windows 10. So we still need to deploy Windows 7.

        You wrote: “The problem seems to be caused by DISM trying to load the registry of the offline OS when it has not finishing unloading the registry from a previous driver install registry load. This issue only seems to happen on faster PCs with SSD drives, mainly SSD NVME drives….”

        Why can Windows 10 handle fast Computer better than Windows 7?! IMHO there must be something wrong with DISM…

        Regards

        1. Frank Rojas says:

          The problem has been identified as an issue in Windows 7 which has been subsequently fixed in Windows 8.1 and Windows 10. It’s not a problem with DISM but instead a problem with a Windows 7 provider that gets loaded into DISM. Because Windows 7 is in extended support and this is not a security issue, the root cause of the problem will not be fixed in Windows 7. However we are currently exploring of other possibilities of fixing the issue. Due to the nature of the issue and it being a problem in Windows 7, if a fix is made available for the issue, it is not going to be any time soon. The solution in this blog post should work regardless of model PC. If you are having problems with a specific model PC, I would recommend you open a case to get it investigated. I would also push you 3rd party vendors to add Windows 10 compatibility to their applications as Windows 7 end of life is only 3 years away.

  15. Oz says:

    Excellent documentation on the workaround.

  16. Zevot says:

    I took out the high performance hack in PE but still had some models that would fail so I also implemented workaround #3. This worked for most models but there are too many cons to this method that prevent critical drivers from being installed on some models. What seems to have worked for me is to do the Auto Apply Driver step for a specific model, and then the next step be Apply Driver Package for the same model. For whatever reason this seems to work each time, so far. We’ll see if it continues to work…

  17. David says:

    Hi!
    I don’t really get this issue, is everybody using the default boot images? Boot image (x64) & (x86) ? After upgrading I will still be using my old win 7 boot images for my win 7 Task Sequences and create new win 10 boot images for my win 10 task sequences. It must be the new DISM inside the boot image that causes the issue? Right ? Is it not supported to use old custom boot images in new version of configmgr? What am i missing ?

    1. Frank Rojas says:

      You don’t have to use WinPE boot images that match the OS as long as you are deploying an image, so most admins just use the latest boot images. This allows for simplification of boot images to the point that in most instances, you only need two boot images – one for x64 and one for x86.

      Also DISM/ADK is not the root cause. There is actually not an issue with DISM/ADK and the problem is with a provider that gets loaded into DISM by Windows 7. In other words the problem is with Windows 7, not DISM or the ADK.

  18. Vince says:

    Frank,
    Thank you for the excellent documentation on this! I was having issues with some HP EliteDesk 800 drivers failing to install via the Apply Driver Package step and could not figure out which driver was causing the issue, or if it was even an issue with a specific driver installation at all! I used workaround #1 and it is working perfectly. It now installs the remaining drivers needed and the task sequence finishes successfully. Great article.

  19. Atamidos says:

    Has this been confirmed as fixed in the ADK 1703 boot WIM?

    1. Frank Rojas says:

      The problem is not in DISM/ADK so there is nothing to fix in DISM/ADK. In other words any fix will not be in DISM/ADK. The problem is with a provider that gets loaded into DISM by Windows 7 so the issue is in Windows 7.

      1. David W says:

        If that is true, why was this issue not seen in ADK versions prior to 1607?

        1. Frank Rojas says:

          It was seen in versions of the ADK prior to 1607. We first had this issue reported 2 years ago. This is explained in the article:

          This issue is actually not new to the ADK 10 1607 and has been seen with previous versions of the ADK and ConfigMgr. In previous versions of the ADK and ConfigMgr the issue was very rare and was mainly seen only when customers were performing modifications in WinPE that increased performance during the Task Sequence. The following blog article details one such method:

          Reducing Windows Deployment time using Power Management
          https://blogs.technet.microsoft.com/deploymentguys/2015/03/26/reducing-windows-deployment-time-using-power-management/

          If you are doing any modifications such as the one from the above blog article we recommend temporarily disabling these modifications to resolve the issue.

          We believe that the issue is more prevalent in ADK 1607 and newer due to performance enhancements done in those ADKs. We are not going to fault the ADK for performance enhancements or any type modifications in the ADK that improves performance when the actual bug lies in Windows 7.

    2. BS says:

      have seen the same problem with ADK1703

      1. Frank Rojas says:

        The problem is not in DISM/ADK. Upgrading the ADK, whether it is 1703 or any future version, is not going to fix the problem. The problem is with a provider that gets loaded into DISM by Windows 7.

  20. Rick says:

    Frank,
    Thanks for the workarounds. We really appreciate the well written article explaining the problem and offering solid solutions. We have implemented workaround #2 on systems configured with NVMe drives. This solution also provides an easier reading smsts.log during driver installs. Workaround #2 also appears to be more efficient than Apply Driver Package. Are we losing anything by not using Apply Driver Package? we are considering replacing Apply Driver Package with Workaround #2 on all of our driver installs in OSD.
    My next question, what is the possibility of changing the SCCM product under the hood: change the “Apply Driver Package” action to use the workaround /recurse method replacing the current built-in load-apply-unload-repeat method?

    1. Frank Rojas says:

      I cannot share anything definite right now, but my advise to you right now is to not make the changes you are considering making at this time and to instead stay tuned…

      1. Frank Rojas says:

        Oh and to answer your question, not you are not really losing anything by replacing the Apply Driver Package task.

        1. Rick says:

          Frank,
          Thanks for the rapid response!

          1. Rick says:

            Frank,
            Good news and not-so-good news. The good news: Workaround 2 solved our problem with the NVMe drive equipped systems. The not-so-good news: We are now getting policy errors when initializing OSD (See example from smsts.log below). The error occurs when evaluating unknown computers collection deployments. Rather than getting the wizard window that displays available task sequences, we get the 8007000e error message

            I know, we have too many package references in our task sequences and we are targeting two large task sequences to the unknown computers collections. Prior to implementing Workaround 2, we were not getting the policy error detailed below. After workaround #2 the errors started. We were able to validate when we delete the “download package content” actions from the TS and re-enable the Apply Driver Package actions the errors go away.

            We are about to open a case with MS premier support. Thought I would run this by you first to see if you can make a correlation or suggestions to avoid the issue. For the time being, we are back to Workaround #1.

            The interesting piece is that “Apply Driver Package” and “Download Package Content” appear to do the same thing when it comes to downloading drivers to hard drive, however “Download package content” appears to handle CM policy differently.

            Error from SMSTS.log:

            Reply is too big. (16786430, 16777216 TSMBootstrap 6/20/2017 7:59:22 PM 1208 (0x04B8)
            CLibSMSMessageWinHttpTransport::Send: URL: SM-CABU-CMPSSW1.swna.wdpr.disney.com:80 GET /SMS_MP/.sms_pol?OC023089-OC0002EC-6F6BCC28.1_00 TSMBootstrap 6/20/2017 7:59:22 PM 1208 (0x04B8)
            Request was successful. TSMBootstrap 6/20/2017 7:59:24 PM 1208 (0x04B8)
            nContentLength <= nReplySize, HRESULT=8007000e (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,9169) TSMBootstrap 6/20/2017 7:59:24 PM 1208 (0x04B8)
            Reply is too big. (16786430, 16777216 TSMBootstrap 6/20/2017 7:59:24 PM 1208 (0x04B8)
            CLibSMSMessageWinHttpTransport::Send: URL: SM-CABU-CMPSSW1.swna.wdpr.disney.com:80 GET /SMS_MP/.sms_pol?OC023089-OC0002EC-6F6BCC28.1_00 TSMBootstrap 6/20/2017 7:59:24 PM 1208 (0x04B8)
            Request was successful. TSMBootstrap 6/20/2017 7:59:25 PM 1208 (0x04B8)
            nContentLength <= nReplySize, HRESULT=8007000e (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,9169) TSMBootstrap 6/20/2017 7:59:25 PM 1208 (0x04B8)
            Reply is too big. (16786430, 16777216 TSMBootstrap 6/20/2017 7:59:25 PM 1208 (0x04B8)
            CLibSMSMessageWinHttpTransport::Send: URL: SM-CABU-CMPSSW1.swna.wdpr.disney.com:80 GET /SMS_MP/.sms_pol?OC023089-OC0002EC-6F6BCC28.1_00 TSMBootstrap 6/20/2017 7:59:25 PM 1208 (0x04B8)
            Request was successful. TSMBootstrap 6/20/2017 7:59:27 PM 1208 (0x04B8)
            nContentLength <= nReplySize, HRESULT=8007000e (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,9169) TSMBootstrap 6/20/2017 7:59:27 PM 1208 (0x04B8)
            Reply is too big. (16786430, 16777216 TSMBootstrap 6/20/2017 7:59:27 PM 1208 (0x04B8)
            CLibSMSMessageWinHttpTransport::Send: URL: SM-CABU-CMPSSW1.swna.wdpr.disney.com:80 GET /SMS_MP/.sms_pol?OC023089-OC0002EC-6F6BCC28.1_00 TSMBootstrap 6/20/2017 7:59:27 PM 1208 (0x04B8)
            Request was successful. TSMBootstrap 6/20/2017 7:59:28 PM 1208 (0x04B8)
            nContentLength <= nReplySize, HRESULT=8007000e (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,9169) TSMBootstrap 6/20/2017 7:59:28 PM 1208 (0x04B8)
            Reply is too big. (16786430, 16777216 TSMBootstrap 6/20/2017 7:59:28 PM 1208 (0x04B8)
            hr, HRESULT=8007000e (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,4893) TSMBootstrap 6/20/2017 7:59:28 PM 1208 (0x04B8)
            oPolicy.RequestPolicy((GetPolicyFlags() & POLICY_SECURE) != 0, (GetPolicyFlags() & POLICY_COMPRESS) != 0), HRESULT=8007000e (e:\qfe\nts\sms\framework\tscore\tspolicy.cpp,2207) TSMBootstrap 6/20/2017 7:59:28 PM 1208 (0x04B8)
            Failed to download policy OC023089-OC0002EC-6F6BCC28 (Code 0x8007000e). TSMBootstrap 6/20/2017 7:59:28 PM 1208 (0x04B8)

          2. Frank Rojas says:

            Yeah that is a problem with too much policy but not really related to this issue. My advise is to either cut down the amount of deployments to the PC (start off with cutting down the amount of software updates targeted to the PC by pruning out unneeded updates) or try Workaround #1.

        2. Alenat says:

          With Workaround #2 we are losing standalone media functionality as far as I understood. Correct?

  21. Kristian Baggerød says:

    We are facing this issue with lots of models using ADK 1607 and ADK 1703. We have to use ADK 1511 bootimages to get apply driver
    step working for Our Windows 7 deployments. So why do this work perfectly with ADK 1511? We have upgraded to SCCM 1702 and ADK 1703, but now we cannot edit out ADK 1511 bootimages. We considered downgrading to ADK 1511 (again!), but ADK 1511 is not supported With SCCM 1702. But maybe it will “work” ? -_-

    1. Frank Rojas says:

      If you read through the blog, and in particular the update at the top of the article from 2017-06-08, you will understand the root cause and why this is not an issue in the ADK but instead an issue with Windows 7. You will also see that we have customers run into the issue in prior ADKs including 1511. I understand that you did not run into the issue with the ADK 1511, but that does not mean that others did not run into the issue with the ADK 1511. It all comes down to system performance. If the system is fast enough and tweaks are put into place to make the systems even faster, you can potentially hit the issue regardless of the ADK.

      If you also read the update from 2017-06-26, you will also see that the workaround documented in this blog has now been implemented directly into the Apply Driver Package task starting with ConfigMgr Current Branch 1706. ConfigMgr Current Branch 1706 is currently under final testing and is expected to be released soon. Once released, I recommend upgrading to 1706 so you get the new Recurse feature in the Apply Driver Package task. Checking this option for your Windows 7 deployments should fix the issue regardless of what ADK is installed.

  22. scerazy says:

    Sadly CB 1706 gives me error when using “Install driver package via running DISM with recurse” option:

    Command line: “osddriverclient.exe” /install:SP1001B3 /unsigned:false /recurse:true
    FALSE, HRESULT=80070057 (e:\nts_sccm_release\sms\client\osdeployment\osddriverclient\osddriverclient.cpp,197)
    Argument 3 is invalid.
    ParseArguments( argc, argv, eDriverOperation, sPackageId, pBootCriticalInfo, bAllowUnsigned, bBestMatch ), HRESULT=80070057 (e:\nts_sccm_release\sms\client\osdeployment\osddriverclient\osddriverclient.cpp,341)
    Failed to pass arguments. Code 0x80070057

    1. Frank Rojas says:

      Sounds like you didn’t update your boot images. The older pre-CB 1706 binaries are being used in the boot image. Since this option is new in ConfigMgr Current Branch 1706, you need to make sure you update your boot images on DPs to get the latest 1706 binaries into the boot image. The older binaries are not recognizing the “3rd” (/recurse) argument because that option was not available with the older binaries. It is only available in the newer 1706 binaries.

      1. Jordan says:

        I am experiencing this same issue after upgrading from SCCM 1702 to SCCM 1706. I just update my distribution points with the newly generated Windows PE Boot image that was created during the upgrade. Before I was using the Windows 10, 1607 ADK Boot Image (Even thought the version showed it was ADK 1703…)

        I’ll report back on if it worked or not.

        1. Jordan B says:

          Update:

          Using the new boot images worked! Thank the lord.

          1. Benny says:

            After SCCM Update from 1702 to 1706 I have the same issue…. I’m using a customized boot image with the version 10.0.15063.0 and I’m getting the same error during apply driver on a windows 10 1703 machine.

            Do I have to use the new Boot Images created during the upgrade or is it enough to deploy these boot images to all distribution points? My customized Boot Image which I created before the update has the same Version like the new generated boot images. The only difference is that the new boot images are listed with a Client Version (5.00.8498.1008) in the Config Manager console.

          2. Frank Rojas says:

            You need to update any boot image on the DPs after the upgrade is done, especially custom boot images. This will get the updated binaries into the boot image that contains the new recurse feature.

  23. chris brunner says:

    Dear Frank,
    and thanks for all the information given on this page and your efforts.
    However, our organisation is heavily affected from that “bug” and so we were eagerly waiting for the 1706 SCCM relase;
    just to discover that there is another bug coming up. ( Access content directly from a distribution point when needed by the running task sequence )
    Since we are relying on that method for several reasons and any of the workarounds would be pretty hard to implement due to our amount of TaskSequences and
    driver packages, I am kindly asking you to urge the responsible teams wherever possible to get that fixed on short term.
    Honestly, I can’t imagine that a simple trailing “\” can be so hard to be fixed. 😉

    Thanks for your help and
    best regards,
    Christian

    1. Frank Rojas says:

      Thank you Christian for the feedback. I can confirm that a fix has been made for the next version of ConfigMgr (ConfigMgr Current Branch 1710). Unfortunately it is not as easy as just changing code to remove the trailing backslash. However small the code change is, it has the potential of causing unexpected results in other areas of the product. I have seen similar other “small code changes” cause much bigger problems than what the original code fix was meant to fix. Any code change needs to go through code review and extensive testing. All of this proper testing with these types of changes and fixes takes place in between ConfigMgr versions. Due to the timelines involved with hotfixes, much less testing takes place which always makes them risky to produce and release. With that said we are currently exploring backporting the fix to ConfigMgr Current Branch 1706, but cannot guarantee that it will be. Even if it is backported, it won’t be until the first rollup which is probably at least 2 months down the line. Also I highly encourage you to move away from using Access content directly from a distribution point as it is considered much less secure than using Downloading content as needed by Task Sequence. When content is downloaded locally, hash verification are performed that ensures that content has not be tampered with or corrupted. Hash verification does not occur with using Access content directly from DP.

Skip to main content