<link rel="stylesheet" id="gtranslate-style-css" href="https://websetnet.b-cdn.net/wp-content/plugins/gtranslate/gtranslate-style24.css" type="text/css" media="all">

Apply Driver Package task fails when the ADK is upgrade to ADK 10 1607

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. This issue only seems to happen on faster PCs with SSD drives, mainly SSD NVME drives.

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:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:20:37.863 OSDDriverClient Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:20:39.965 OSDDriverClient Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:20:43.238 OSDDriverClient Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:18.742 OSDDriverClient Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:23.704 OSDDriverClient Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:33.332 OSDDriverClient Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:35.256 OSDDriverClient Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:37.138 OSDDriverClient Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

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

11-22-2016 18:21:37.138 OSDDriverClient Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.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_releasesmsclientosdeploymentosddriverclientsysprepdriverinstaller.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_releasesmsclientosdeploymentosddriverclientsysprepdriverinstaller.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_releasesmsclientosdeploymentosddriverclientdriverinstaller.cpp,557)
11-22-2016 18:21:38.368 OSDDriverClient ReleaseSource() for C:_SMSTaskSequencePackagesC660005F.
11-22-2016 18:21:38.368 OSDDriverClient reference count 1 for the source C:_SMSTaskSequencePackagesC660005F before releasing
11-22-2016 18:21:38.368 OSDDriverClient Released the resolved source C:_SMSTaskSequencePackagesC660005F
11-22-2016 18:21:38.368 OSDDriverClient pDriverInstaller->InstallDriverPackage( sPackageId, pBootCriticalInfo ), HRESULT=80004005 (e:nts_sccm_releasesmsclientosdeploymentosddriverclientosddriverclient.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:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:20:37.000 DISM DISM.EXE: Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:20:39.000 DISM DISM.EXE: Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:20:43.000 DISM DISM.EXE: Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:18.000 DISM DISM.EXE: Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:23.000 DISM DISM.EXE: Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:33.000 DISM DISM.EXE: Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:35.000 DISM DISM.EXE: Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.log”

11-22-2016 18:21:37.000 DISM DISM.EXE: Executing command line: “X:WINDOWSsystem32dism.exe” /image:”C:” /windir:”WINDOWS” /apply-unattend:”C:_SMSTaskSequencePkgMgrTempdrivers.xml” /logpath:”C:_SMSTaskSequencePkgMgrTempdism.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:Windowssystem32smistoreMachineschema.dat’.
11-22-2016 18:21:38.000 CBS Failed to load offline schema.dat hive from ‘?C:Windowssystem32smistoreMachineschema.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:_SMSTaskSequencePkgMgrTemp5329B70A-F697-49DD-98B7-63628584B5C7CbsProvider.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.

The issue is still under investigation though so full root cause is not currently known.

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.
  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.

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.

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

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

    1-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).
    1-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.
    1-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.
    1-7
    1-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.

    1-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
    1-9t
    false
    1-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.

    1-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%.
    1-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).
    1-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.
    1-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.
    1-13
    1-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.
    1-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.

    1-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%.
    1-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).
    1-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.
    1-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.
    1-18
    1-18a
  19. Click on the OK or Apply button to save the Task Sequence.
    1-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 installs 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, 10-11, 14, 19-20
    • Never allow unsigned drivers – Follow steps 1-7, 15-16, 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.
    2-1
  2. Click on the Apply Driver Package task.
    2-2
  3. In the Apply Driver Package task, click on the Options tab, and then select Disable this step.
    2-3
  4. In the Apply Driver Package task, under the Options tab copy and make note of any conditions that are in that task.
    2-4
    2-4a
  5. Immediately after the Apply Driver Package task, add a new Group by going to the Add menu and selecting New Group.
    2-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).
    2-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.
    2-7
    2-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.
    2-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
    2-9t
    false
    2-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.

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

    2-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.

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

    %_SMSTSMDataPath%Drivers
    2-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.

    2-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
    2-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.
    2-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
    2-17
    2-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.
    2-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
    2-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
    2-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.
    2-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
    2-22
    2-22a
  23. Click on the OK or Apply button to save the Task Sequence.
    2-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, 14-15, 18, 23-24
    • Never allow unsigned drivers – Follow steps 1-7, 10-13, 19-20, 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

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.

Frank Rojas
Senior Support Escalation Engineer

Source

Leave a Comment