Tag Archives: ConfigMgr 2012

While packaging a few Intel drivers (video driver, USB 3.0, chipset, management engine components, etc.) for our HP laptops, I noticed that each of the driver downloads contained a file named “mup.xml”. This file contains, among other things, information about valid command line switches for the setup.exe installer.

A snippet of the mup.xml file for our video driver is below. Some valid command line switches (which I haven’t fully tested) that appear within the file are:

/v = extract drivers (providing a double-quote encapsulated path is optional)
/s = unattended (silent install)
/? = help
/overwrite = force (install over previous installation)
/report = change the log file location from the default (C:\Intel) by providing double-quote encapsulated path

It seems that using a dash/hyphen in place of the forward slash is also acceptable. Ex.: /silent or -silent are both valid.

The mup.xml file also contains information on non-zero exit codes that may be returned by the installer. So far, I’ve encountered exit code 14, REBOOT_REQUIRED, a few times.

  <executable>
    <executablename>setup.exe</executablename>
  </executable>
  <behaviors>
    <behavior name="freshinstall">
      <vendoroption>
        <optionvalue switch="/" requiresvalue="false">s</optionvalue>
      </vendoroption>
    </behavior>
    <!--Driver Only Package, Installer Doesn't need to support
    <behavior name="driveronly">
      <vendoroption>
         <optionvalue switch="/" requiresvalue="false"></optionvalue>
      </vendoroption>
    </behavior>
      <behavior name="applicationonly">
      <vendoroption>
         <optionvalue switch="/" requiresvalue="false"></optionvalue>
      </vendoroption>
    </behavior>
    -->
    <behavior name="extractdrivers">
      <vendoroption>
        <container>
          <containervalue switch="/" requiresvalue="false" valuedelimiter=" " enclose="&quot;">v</containervalue>
          <optionvalue switch="" requiresvalue="true" valuedelimiter="=" enclose="\&quot;">ExtractDrivers</optionvalue>
        </container>
      </vendoroption>
    </behavior>
    <behavior name="attended" />
    <behavior name="help">
      <vendoroption>
        <optionvalue switch="/" requiresvalue="false">?</optionvalue>
      </vendoroption>
    </behavior>
    <behavior name="unattended">
      <vendoroption>
        <optionvalue switch="/" requiresvalue="false">s</optionvalue>
      </vendoroption>
      <!-- The DUP will Restart the system
      <vendoroption>
        <optionvalue switch="/" requiresvalue="false">b</optionvalue>
      </vendoroption>
      -->
    </behavior>
  </behaviors>
  <parameters>
    <parametermapping name="force">
      <vendoroption>
        <optionvalue switch="/" requiresvalue="false">overwrite</optionvalue>
      </vendoroption>
    </parametermapping>
    <parametermapping name="logfile">
      <vendoroption>
        <optionvalue switch="/" requiresvalue="true" valuedelimiter=" " enclose="&quot;">report</optionvalue>
      </vendoroption>
    </parametermapping>
  </parameters>
  <returncodes>
    <returncodemapping name="REBOOTING_SYSTEM">
      <vendorreturncode>15</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="PASSWORD_REQUIRED">
      <vendorreturncode>2</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="NO_DOWNGRADE">
      <!--Always able to DownGrade, Installer Doesn't need to support-->
      <vendorreturncode>9999</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="REBOOT_UPDATE_PENDING">
      <!--Installer only Reboots Once, Installer Doesn't need to support-->
      <vendorreturncode>9999</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="DEP_SOFT_ERROR">
      <vendorreturncode>7</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="DEP_HARD_ERROR">
      <vendorreturncode>5</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="SUCCESS">
      <vendorreturncode>0</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="ERROR">
      <vendorreturncode>10</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="REBOOT_REQUIRED">
      <vendorreturncode>14</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="ERROR_INSTALL_PLATFORM_UNSUPPORTED">
      <vendorreturncode>3</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="UNKNOWN_OPTION">
      <vendorreturncode>1</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="ERROR">
      <vendorreturncode>9</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="ERROR">
      <vendorreturncode>6</vendorreturncode>
    </returncodemapping>
    <returncodemapping name="ERROR">
      <vendorreturncode>4</vendorreturncode>
    </returncodemapping>
  </returncodes>

So far, I’ve had good luck with the command: setup.exe /s /overwrite.

While working on a new System Center Configuration Manager 1511 server that I was building, I noticed that each of the Component Status logs were returning 0 messages for the previous 1 day. If I set the threshold back to 1 week, I could see events, but they had completely stopped a few days earlier. Something was preventing new logs from being created.

The Component Status logs are found under the Monitoring node, by expanding System Status and then selecting Component Status. The odd thing about this was that the icons and status seemed to be updating correctly, suggesting that the data for the logs was still being collected and processed, but SCCM could not display the logs.

The events written to statmgr.log looked something like this (in part):

*** exec sp_InsContentDistributionStatus N'', N'RTM00405', 0, 72057594038182832, 2361, '02/18/2016 07:04:10.240', N'\\myserver.com\dfs\Packages\Microsoft\Updates\Windows 7 Server 2008 R2 Office 2010 Patch Tuesday Updates 2015\95289d79-38a1-44a3-a2a7-5f54febcb70b', N'95289d79-38a1-44a3-a2a7-5f54febcb70b', N'95289d79-38a1-44a3-a2a7-5f54febcb70b', N'30', N'69', N'';	SMS_STATUS_MANAGER	2/19/2016 10:54:34 AM	4648 (0x1228)
*** [22001][8152][Microsoft][SQL Server Native Client 11.0][SQL Server]String or binary data would be truncated. : sp_InsContentDistributionStatus	SMS_STATUS_MANAGER	2/19/2016 10:54:34 AM	4648 (0x1228)

The corresponding .sql file in Microsoft Configuration Manager\inboxes\statmgr.box\retry\ looked something like this (in part):

exec sp_InsContentDistributionStatus N'', N'RTM00405', 0, 72057594038182832, 2361, '02/18/2016 07:04:10.240', N'\\myserver.com\dfs\Packages\Microsoft\Updates\Windows 7 Server 2008 R2 Office 2010 Patch Tuesday Updates 2015\95289d79-38a1-44a3-a2a7-5f54febcb70b', N'95289d79-38a1-44a3-a2a7-5f54febcb70b', N'95289d79-38a1-44a3-a2a7-5f54febcb70b', N'30', N'69', N'';

As I looked through the .sql files containing the problem transactions, I noticed a pattern appear. Each .sql file contained a stored procedure named “sp_InsContentDistributionStatus”, and each of these stored procedures involved the source path to a Microsoft update in one of my Software Update Deployment Packages.

Nothing about the arguments to the stored procedure looked out of place, and in fact matched very closely to stored procedures that ran successfully once the jam in Microsoft Configuration Manager\inboxes\statmgr.box\retry\ was cleared.

I did some Googling and formulated a course of action to restore most of the missing log entries until I had time to troubleshoot the root cause.

  1. Open an elevated command prompt to the \statmgr.box\retry\ location. For example, on my server, where I have installed SCCM to the D: drive, the directory is located at:
    D:\Program Files\Microsoft Configuration Manager\inboxes\statmgr.box\retry\
    You’ll probably find dozens, if not hundreds of .sql files in this location.
  2. Sort the files by date in descending order, to see the oldest at the bottom of the list, using the command:
    dir /o:-d
    This file contains the query that is blocking later transactions.
  3. Open the SCCM server’s statmgr.log in cmtrace.exe and leave it open. On my server, this file is located at:
    D:\Program Files\Microsoft Configuration Manager\Logs\statmgr.log
  4. Search the log for the file name of oldest .sql server in the \retry\ directory. Depending on how long the problem has existed you may or may not find entries around the failure to submit the transaction.
  5. Move the oldest .sql file from the \retry\ directory into another location. This file will not be processed, and as such will result in some data loss, but it will allow you to proceed.
  6. Start the Configuration Manager Service Manager, expand Components, and then query, stop, query, start the SMS_STATUS_MANAGER component.
    You should see activity in the statmgr.log as it begins to process the failed transactions, but it should be able to successfully process the transactions that were queued up behind the problem query.
  7. Monitor the statmgr.log for failures. If another back-logged .sql file contains an invalid query, the statmgr.log will report the failure, and you will be able to capture both the events surrounding the failure and the .sql file containing the failed transaction for analysis.
  8. Repeat the process of moving each failed .sql file out of the \retry\ directory, then restarting the SMS_STATUS_MANAGER component until all of the back-logged .sql files have been processed.

As a first step to attempt to resolve the problem, I deleted the Software Update Deployment Package and then rebuilt it from the source path. The .sql files did not build up in Microsoft Configuration Manager\inboxes\statmgr.box\retry\, and the problem where the component status messages stopped being display did not recur. So, unfortunately, I seem to have fixed the problem by going straight to the nuclear option, and missed out on any opportunity for finding the root cause. While I don’t have an explanation about why the stored procedure errored out, I’m posting this description of my experience in hopes of helping others. If you can explain the cause of the problem, please do post a comment.

A resource for troubleshooting System Center Configuration Manager (Current Branch) and System Center 2012 Configuration Manager Task Sequence failures through analysis of errors reported in the smsts.log file.

When an SCCM task sequence fails, errors are written to the smsts.log file. Sometimes the error is descriptive and it’s possible to quickly identify the cause of the failure. But often the error is logged as “Unspecified error (Error: 80004005; Source: Windows)”, which requires further investigation. In this post, I’ve assembled a few errors that I’ve personally encountered, along with my analysis of the cause. It’s my hope that this post can help other ConfigMgr administrators find resolutions to their problems.

Error reported in smstslog:

Invoking App Management SDK to evaluate app polices	InstallApplication
Process completed with exit code 2147500037	TSManager
!--------------------------------------------------------------------------------------------!
Failed to run the action: VP Windows 10 Default File Association. 
Unspecified error (Error: 80004005; Source: Windows)

Failed for reason:

There is a logical error or typo in the detection method. Note that in this error, the non-zero exit code line immediately follows the “… evaluate app policies” line. It suggests that the error is not with the application itself but with the data about the application.

The application may install successfully, but the detection rule cannot be evaluated successfully because it is illogical or invalid.

For example, if a registry key/value is used as the rule, the rule might be misconfigured to look for a key at “HKLM\SOFTWARE\VedderPrice\Windows 10 Default File Associations” in the HKLM hive, instead of “SOFTWARE\VedderPrice\Windows 10 Default File Associations” in the HKLM hive. (Note the extra HKLM at the beginning of the path.)

Resolution:

Edit the Detection Method for the application to correct an invalid rule.

Error reported in smsts.log:

Retrieving Application Policy Mapping:
m_mapAppPolicies.find(sAppName) != m_mapAppPolicies.end(), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\installapplication\dautils.cpp,478)
App policy for 'Microsoft User Experience Virtualization (UE-V) 2.1 SP1 Generator' not received. Make sure the application is marked for dynamic app install
Policy download failed, hr=0x80004005
daUtil.DownloadPolicies(), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\installapplication\dainstaller.cpp,296)
Successfully cleared App model names from TS env.
daInstaller.Execute(), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\installapplication\main.cpp,260)
Process completed with exit code 2147500037
!--------------------------------------------------------------------------------------------!
Failed to run the action: Install Secondary Applications.
Unspecified error (Error: 80004005; Source: Windows)

Failed for reason:

The application in SCCM was not marked for dynamic app install, but is being installed as part of a dynamic variable list during the task sequence (the “Install applications according to dynamic variable list” option is selected in the Install Application step).

Resolution:

Edit the application’s properties and check the box labeled “Allow this application to be installed from the Installation Application task sequence action without being deployed”.

Error reported in smsts.log:

Installation job completed with exit code 0x00000000
Execution status received: 4 (Application failed to install )
Installation failed.

Failed for reason:

The application installer (in our case, the wrapper.vbs) did not error out, but the detection method could not confirm that the application installed successfully.

This is most commonly caused by a mismatch between detection method and what is actually happening during the installation. Typically, the application is installed successfully (hence the exit code 0) but the detection method is incorrectly configured (for example, there is a typo in the file path or registry key used as the detection rule).

Resolution:

Correct the detection method.

Error reported in smsts.log (on 2012 RTM/SP1 clients):

Installation job completed with exit code 0x00000000
Execution status received: 24 (Application download failed )
Installation failed.

Also (on 2012 R2 CU1 clients):

Installation job completed with exit code 0x00000000
Execution status received: 24 (Application download failed )
App install failed.

Failed for reason:

If the computer is not joined to the domain, an application may fail to download unless the Deployment Type has, under the Content tab, the Deployment option for “Select the deployment option to use when a client is within a slow or unreliable network boundary, or when the client uses a fallback source location for content.” is set to “Download content from distribution point and run locally”. If the computer is not joined to the domain, it will fail to download content if the Deployment option for slow or unreliable network boundary is set to “Do not download content”. Confirm that the OU structure exists for the computer being imaged, that the Network Service Account has rights to create computers in the destination OU, and that the computer is being added to the appropriate destination OU.

The cache may be full. Check the CAS.log and look for the entries:

----- CacheManager: Even if all currently inactive cached content was removed there would not be enough space available for the request.
Not enough space in Cache

“If a new package that must be downloaded would cause the folder to exceed the maximum size, and if the folder cannot be purged to make sufficient space available, the package download fails, and the program or application will not run.”
– https://technet.microsoft.com/en-us/library/gg699356.aspx

The Software Updates step will download hotfixes to the cache, even if those files exceeds the size limit of the cache. However, if a step later in the task sequence attempts to download content to the cache, which is now full or even over-full, the download will fail with “Not enough space in Cache”.

The cache may not have sufficient space for the application. Check the CAS.log and look for the entries:

Cache Size is too small for requested content
CreateContentRequest failed

In the CAS.log, you should see the URL of the failing application in the lines immediately above the errors. If you have access to the Right-Click Tools in the SCCM Admin Console, choosing the “Change Client Cache Size” option will display the current cache size and allow you to change it.

If cache size is the issue, consider rebuilding the WIM via a Build and Capture task sequence, but increasing the cache size via the SMSCACHESIZE parameter in the “Setup Windows and ConfigMgr” step to set the cache size. It more recent versions of the SCCM client, the SMSCACHESIZE parameter can be used in the “Setup Windows and ConfigMgr” step in an OSD task sequence to redefine the cache size.

I have also attempted to resolve this error via an Update Content on the Deployment Type, even though the application in question has not been modified since it was working successfully a few days prior. The Update Content action increments the version/revision, which may be what resolves the problem.

I would also confirm that the Boundaries look OK.

In one case, the application’s file files appeared to be successfully downloaded, and the DataTransferService.log file showed that the DTS job completed successfully a few minutes before the error appeared in smsts.log. My best guess was that the content was downloaded successfully but the task sequence engine wasn’t informed of this, although later experimentation with using a Package instead of an Application confirmed that Trend Micro OfficeScan was preventing the downloaded files from being hashed by the task sequencer. It is my hypothesis that Trend Micro OfficeScan may also have been responsible for the failure to complete the Application download, although this isn’t proven out in the logs. We revised our exclusion rules to prevent Trend from scanning the folders SCCM uses to download content.

It may be caused by the network not being ready when the TS resumes after a restart. Using a VBScript to pause TS execution for a minute or two after each restart is a proven workaround. Also, see this hotfix from December, 2014, for System Center 2012 R2 Configuration Manager: Applications may not be downloaded in System Center 2012 R2 Configuration Manager

To apply this hotfix, you must have Cumulative Update 3 for System Center 2012 R2 Configuration Manager installed.

This hotfix has been incorporated into SCCM 2012 R2 CU4 (and presumably later service packs): Description of Cumulative Update 4 for System Center 2012 R2 Configuration Manager

Resolution:

The resolution will vary based upon the actual cause, but I would recommend looking at the SMSTSAssignmentsDownloadInterval and SMSTSAssignmentsDownloadRetry task sequence variables available in System Center 2012 Configuration Manager SP1 and later. See: Task Sequence Built-in Variables in Configuration Manager

If you are still encountering this problem, I would suggest temporarily disabling your anti-virus, or creating exclusions to prevent scanning of the task sequence content download locations, and retesting.

Error reported in smsts.log:

unknown host (gethostbyname failed)
hr, HRESULT=80072ee7 (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,8738)
sending with winhttp failed; 80072ee7
Will retry in 6 second(s)
Retrying...

Failed for reason:

The NIC driver is not available to the OS, or no network can be found by the OS.

The OS may not have picked up the NIC driver during the Apply Driver Package step.

If the TS can be caught during the error, hitting F8 and then running ipconfig should return no active network adapters, confirming that there is no network.

If ipconfig does return a network, pinging the Distribution Point results in a host not found message.

Resolution:

Confirm that the proper network adapter driver is injected into the full Operating System before the task sequence reboots into the full OS.

Error reported in smsts.log:

Waiting for job status notification...
Retrying: 1 attempt
Waiting for job status notification...
Retrying: 2 attempt
Waiting for job status notification...
Retrying: 3 attempt
nRetryVal != 0, HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\installapplication\installapplication.cpp,1164)
Exhausted retry attempts. Giving up.
WaitforJobCompletion(spAppMgmtSDK, m_guidPolicyEvalJobID, ulPolicyEvalTimeout, nPolicyEvalRetryAttempts), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\installapplication\installapplication.cpp,986)
Step 2 out of 2 complete
Install application action failed: '<the application name goes here>'. Error Code 0x80004005
<skipping over some entries here>
Install Static Applications failed, hr=0x80004005
Process completed with exit code 2147500037

Failed for reason:

Unknown.

Resolution:

Unfortunately, I don’t have a resolution for this particular failure.

Error reported in smsts.log:

Installation job completed with exit code 0x00000000
Execution status received: 3 (Application is available for installation )
Installation failed.
Install application action failed: 'Hotfix for Microsoft Windows (KB2617858)'. Error Code 0x80004005
Sending error status message
Set authenticator in transport
Install application action cannot continue. ContinueOnErrorFlag is set to false.
Process completed with exit code 2147500037
!--------------------------------------------------------------------------------------------!
Failed to run the action: Hotfix for MS Windows (KB2617858) (Windows7). Unspecified error (Error: 80004005; Source: Windows)

Failed for reason:

Unknown. A few moments before the execution status 3, there is a line “NotifyProgress received: 4 (Application failed to install )”, indicating that the detection method did not find the application had installed.

We use a VBScript wrapper to provide a consistent method of packaging all of our applications. It appears that the application is failing when it is run from C:\Windows\ccmcache\, but the error response does not appear to be coming from the wrapper.vbs but a more generic error code from wscript (eg, some sort of invalid syntax).

In one case, the problem was resolved by deleting the content for this deployment type from a remote distribution point and redistributing it from the primary SCCM server.

Resolution:

I can only hypothesize that the exit code is coming from wscript.exe due to a logical error in the VBScript.

Error reported in smsts.log:

Installation job completed with exit code 0x00000000
Execution status received: 0 (No application state information is available )
Installation failed.
Install Dynamic application action failed to install application: 'PowerPivot for Excel'. Error Code 0x80004005
Sending error status message
Set authenticator in transport
Install Dynamic application action cannot continue. ContinueOnErrorFlag is set to false.
Process completed with exit code 2147500037
!--------------------------------------------------------------------------------------------!
Failed to run the action: Install Secondary Applications. Unspecified error (Error: 80004005; Source: Windows)

Failed for reason:

Unknown. In our task sequence, the Install Secondary Applications step installs any number of applications using Dynamic Variables, and this “Execution status received: 0 (No application state information is available )” error has only been seen when evaluating already installed applications in this way. The error has appeared for multiple different applications over time, and in each case, the application encountering the error is already installed on the machines, suggesting that the applications themselves are not at issue. The detection method should be detecting that the applications already exist, but it appears that the client cannot even determine the detection method.

Entries earlier in the smsts.log will contain entries similar to:

NotifyProgress received: 0 (No application state information is available )
CAppMgmtSDK::GetEvaluationState ScopeId_2247E2EC-D4AB-4C75-931D-572C34C9E802/RequiredApplication_1a5ff570-4bf6-4fa8-b9cf-d679aaa9e9da.4 = Unknown

Resolution:

None. This error appears to be caused by the task sequencer’s inability to determine or apply the detection rule for an application.

Error reported in smsts.log:

Installation job completed with exit code 0x80730017
Execution status received: 0 (No application state information is available )
Installation failed.
Step 2 out of 2 complete
Install application action failed: 'VP LocaleSelector HTA'. Error Code 0x80004005
Sending error status message
Set authenticator in transport
Install application action cannot continue. ContinueOnErrorFlag is set to false.
Process completed with exit code 2147500037
!--------------------------------------------------------------------------------------------!
Failed to run the action: VP LocaleSelector HTA. Unspecified error (Error: 80004005; Source: Windows)

Failed for reason:

Unknown. It appears to be due to the task sequencer being unable to determine the detection rule for the application, as the application was already installed on the computer.

Entries earlier in the smsts.log appear normal and contain entries similar to:

NotifyProgress received: 1 (Application is installed successfully )	InstallApplication	1/2/2013 2:10:11 AM	2100 (0x0834)
CAppMgmtSDK::GetEvaluationState ScopeId_2247E2EC-D4AB-4C75-931D-572C34C9E802/RequiredApplication_6db08c1f-74b8-4649-94a1-2ba389ad0b91.3 = Enforced

And then seconds later:

NotifyProgress received: 0 (No application state information is available )	InstallApplication	1/2/2013 2:10:27 AM	2100 (0x0834)
CAppMgmtSDK::GetEvaluationState ScopeId_2247E2EC-D4AB-4C75-931D-572C34C9E802/RequiredApplication_6db08c1f-74b8-4649-94a1-2ba389ad0b91.3 = Unknown

Resolution:

None. This error appears to be caused by the task sequencer’s inability to determine or apply the detection rule for an application.

Error reported in smsts.log:

Policy Evaluation failed, hr=0x87d00440
Install application action failed: 'Workshare Professional 7 (2012.09.17)'. Error Code 0x87d00440
Install application action cannot continue. ContinueOnErrorFlag is set to false.
Install Static Applications failed, hr=0x87d00440
Process completed with exit code 2278556736
!--------------------------------------------------------------------------------------------!
Failed to run the action: Workshare Professional 7 (2012.9.17). Expected policy documents are incomplete or missing. (Error: 87D00440; Source: CCM)

Failed for reason:

Unknown. Entries earlier in smsts.log indicate that the application was detected as already existing:

NotifyProgress received: 1 (Application is installed successfully )

Resolution:

None.

Error reported in smsts.log:

NotifyProgress received: 16 (Application failed to evaluate )
...
NotifyProgress received: 0 (No application state information is available )
...
Policy Evaluation failed, hr=0x80004005
Install application action failed: 'VP Wallpaper and User Account Image (Windows 7)'. Error Code 0x80004005
Install application action cannot continue. ContinueOnErrorFlag is set to false.
Install Static Applications failed, hr=0x80004005
!--------------------------------------------------------------------------------------------!
Failed to run the action: VP Theme and User Account Image. Unspecified error (Error: 80004005; Source: Windows)

Failed for reason:

Unknown. This seems to be a policy evaluation problem.

Resolution:

None.

Error reported in smsts.log (SP1 client):

CAppMgmtSDK::GetEvaluationState ScopeId_2247E2EC-D4AB-4C75-931D-572C34C9E802/RequiredApplication_ce05eb75-c269-4f90-9546-72eab1d69c21.13 = Unknown
NotifyError received
NotifyError processed
Received job completion notification from DCM Agent
GetAppMgmtSDKInterface successful
Policy Evaluation failed, hr=0x87d00267
Setting TSEnv variable 'SMSTSAppPolicyEvaluationJobID__ScopeId_2247E2EC-D4AB-4C75-931D-572C34C9E802/Application_ce05eb75-c269-4f90-9546-72eab1d69c21'=''
...
Install application action failed: 'VP Wallpaper and User Account Image (Windows 7)'. Error Code 0x87d00267
...
Install Static Applications failed, hr=0x87d00267
Process completed with exit code 2278556263
!--------------------------------------------------------------------------------------------!
Failed to run the action: VP Theme and User Account Image. Download failed (Error: 87D00267; Source: CCM)

Failed for reason:

Unknown. This seems to happen when a network connectivity problem causes a content download problem. This error has typically occurred on the first Install Application step in the task sequence immediately after a computer restart.

This is also occurring on install dynamic variable applications, in which event the smsts.log reads similar to:

Install Dynamic application action failed to install application: 'Canon Scanner DR2580C and Capture Perfect 3.0'. Error Code 0x87d00267

This thread implicates the network switch (turning on PortFast resolves the problem), but it also seems to be caused by certain SSD drives: https://social.technet.microsoft.com/Forums/en-US/221bcfe8-4c1e-4766-be5b-fbf54fe0e66c/specific-model-suddenly-fails-on-any-application-install-packages-work-fine?forum=configmanagerosd

Resolution:

An effective workaround is to add a Run Command Line step that executes a VBScript from a package that simply calls Wscript.Sleep to create two-minute pauses after each Restart Computer step that occurs before an Install Application step to allow the network time to come up after a reboot. I experimented with shortening the pause to 1 minute and heard reports that the computers were failing again, so I increased the pause back to 2 minutes and the problem disappeared completely.

With SCCM 2012 R2, new task sequence variables are introduced that may overcome this problem by allowing the task sequence to retry to download files or policy instead of quickly giving up and failing the step.

See: https://social.technet.microsoft.com/Forums/en-US/54458340-e50d-4144-af0d-33c768861e97/osd-ts-fails-during-package-download-sendwinhttprequest-failed-80072ee2?forum=configmanagerosd

See: Task Sequence Built-in Variables in Configuration Manager

Error reported in smsts.log (SP1 client):

pNext != NULL, HRESULT=80004005 (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,1972)
reply has no message header marker
DoRequest (sReply, true), HRESULT=80004005 (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,5868)
Failed to get client identity (80004005)
ClientIdentity.RequestClientIdentity (), HRESULT=80004005 (e:\nts_sccm_release\sms\client\tasksequence\tsmbootstrap\tsmediawizardcontrol.cpp,1072)
failed to request for client
Exiting TSMediaWizardControl::GetPolicy.

Failed for reason:

Uncertain. The Task Sequence fails immediately after entering the Task Sequence Wizard password, before the available Task Sequences are displayed. The Task Sequence Wizard reports:

Failed to Run Task Sequence
An error occurred while retrieving policy for this computer  (0x80004005). For more information, contact your system administrator or helpdesk operator.

I’ve read that in the majority of cases, it is due to an incorrectly set BIOS clock. In my experience, this has always been the case.

Resolution:

Enter the BIOS and set the system clock to the correct date and time.

Error reported in smsts.log (SP1 client):

==============================[ OSDDiskPart.exe ]==============================
Command line: "osddiskpart.exe"
Succeeded loading resource DLL 'X:\sms\bin\x64\1033\TSRES.DLL'
FALSE, HRESULT=80070490 (e:\nts_sccm_release\sms\framework\tscore\diskutils.cpp,1372)
Invalid disk number specified: 0
CDisk::GetDiskSize(oDisk.getIndex(), cbDiskSize), HRESULT=80070490 (e:\nts_sccm_release\sms\client\osdeployment\osddiskpart\main.cpp,717)
LoadDiskConfiguration(oDisk), HRESULT=80070490 (e:\nts_sccm_release\sms\client\osdeployment\osddiskpart\main.cpp,1229)
Invalid configuration specified.  Please ensure that the task sequence is properly configured.
OSDDiskPart.exe failed: 0x80070490
Process completed with exit code 2147943568
!--------------------------------------------------------------------------------------------!
Failed to run the action: Format and Partition Disk. Element not found. (Error: 80070490; Source: Windows)

You will also find a number of these lines throughout smsts.log:

Volume D:\ is not a fixed hard drive
Volume X:\ is not a fixed hard drive

This error will appear immediately after starting the OSD task sequence.

Failed for reason:

Missing hard drive.

Resolution:

Add a hard drive to the computer.

Error reported in smsts.log:

No Env variable with specified basename APP and suffix '01' is found. No applications installed.
CheckForBaseVarsInTSEnv(), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\installapplication\dainstaller.cpp,233)
daInstaller.Execute(), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\installapplication\main.cpp,260)
Process completed with exit code 2147500037
!--------------------------------------------------------------------------------------------!
Failed to run the action: Install Applications. Unspecified error (Error: 80004005; Source: Windows)

Failed for reason:

The Install Application step is failing to install applications from a dynamic variable list because the list does not contain any variables, even though it’s silly that the step would fail for this reason.

Resolution:

The workaround/resolution is to create a condition on the Install Application step that allows it to run only if the first application task sequence variable is set. For example, in our environment, the basename (or prefix) is “APP” and the suffix (the numbers) begin with “01”, so the task sequence variable “APP01” will exist if at least one application is in the dynamic variable list. Our Install Application step, then, contains a condition to only run if the task sequence variable “APP01” exists.

Error reported in smsts.log:

CAppMgmtSDK::GetEvaluationState ScopeId_2247E2EC-D4AB-4C75-931D-572C34C9E802/RequiredApplication_2070c4eb-02e4-4b40-9917-6952b8322448.3 = AvailableForEnforcement

<em><exactly 6 hours pass></em>

Waiting for job status notification...
AppMgmtSDK handler is invalid. Trying to reconnect...
Failed to Reconnect to existing job, hr=0x87d00215
Reconnect Job request failed, hr=0x87d00215
Step 2 out of 2 complete
Install application action failed: 'Citrix Receiver Enterprise 3.4'. Error Code 0x87d00215
Sending error status message
Set authenticator in transport
Install application action cannot continue. ContinueOnErrorFlag is set to false.
Install Static Applications failed, hr=0x87d00215
Process completed with exit code 2278556181
!--------------------------------------------------------------------------------------------!
Failed to run the action: Citrix Receiver Enterprise 3.4 (Windows 7). Item not found (Error: 87D00215; Source: CCM)

Failed for reason:

The application being installed kills the task sequence engine, leading to a 6 hour pause in the task sequence before it eventually times out after six hours and exits. More precisely, in our case, the Citrix Receiver Enterprise 3.4 installer first uninstalls Receiver 3.2, and during the uninstall process the task sequence engine process is killed.

The Install Application step fails after 6 hours exactly.

The application being installed does, in fact, successfully install according to 1) the Application event logged by our wrapper VBScript, 2) the application appears in Programs and Features, and 3) the application’s own About dialog box, which contains the correct version. In the case of Citrix Receiver Enterprise 3.4, it installs successfully in approximately 3 minutes.

The “Item not found” part of the error is misleading, as it seems to suggest that the content was not available, but it is.

Resolution:

We were not able to resolve this problem, but worked around the problem by pushing out Citrix Receiver Enterprise 3.4 as a required deployment outside of the task sequence.

Error reported in smsts.log:

'IsSrkAuthCompatible' failed (2150105106)
Tpm does not have compatible SRK
uStatus == 0, HRESULT=80280007 (e:\nts_sccm_release\sms\framework\tscore\tpm.cpp,548)
'IsEndorsementKeyPairPresent' failed (2150105095)
Tpm does not have EK pair
Initial TPM state: 4
(dwTpmState & Tpm::State_Enabled) != 0, HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\bitlocker\bitlocker.cpp,434)
TPM cannot be enabled without physical presence
InitializeTpm(), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\bitlocker\bitlocker.cpp,1284)
ConfigureKeyProtection( keyMode, pwdMode, pszStartupKeyVolume ), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\bitlocker\bitlocker.cpp,1489)
pBitLocker->Enable( argInfo.keyMode, argInfo.passwordMode, argInfo.sStartupKeyVolume, argInfo.bWait ), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\bitlocker\main.cpp,382)
Process completed with exit code 2147500037
!--------------------------------------------------------------------------------------------!
Failed to run the action: Enable BitLocker (Laptops Only). Unspecified error (Error: 80004005; Source: Windows)

Failed for reason:

The BIOS is not correctly configured for BitLocker.

Resolution:

BitLocker is tricky to get right, but the first step is to enable the TPM in the BIOS.

Error reported in smsts.log:

Installation of updates started
Waiting for installation job to complete
Notification received, that updates installation has failed
Received job completion notification from Updates Deployment Agent 
One or more updates failed to install, hr=0x87d00656
Process completed with exit code 2278557270
!--------------------------------------------------------------------------------------------!
Failed to run the action: Install Software Updates. Updates handler was unable to continue due to some generic internal error (Error: 87D00656; Source: CCM)

Failed for reason:

Unknown. A small percentage of computers will fail to run Software Updates each month in the days after they are made available to them and they run our maintenance task sequence. Given enough attempts, the computers will eventually succeed in installing Software Updates.

Resolution:

None. If we put enough Install Software Updates steps (with a condition to Continue on Error) and reboots in between, most of the computers will successfully install the updates.

Error reported in smsts.log:

(Actually, no error is reported, but the task sequence fails to resume after a non-TS aware reboot immediately following a TS-aware reboot during the Install Software Updates step. The following typo-filled lines are written to smsts.log immediately after the second reboot.)

Failed to set log directory. Some execution history may be lost. The system cannot find the file specified. (Error: 80070002; Source: Windows)
Executing task sequence
Task Sequence environment not found.
Attempting to get active request.
Failed to create instance if Software Execution Request Managerr. 0x80070005
Waiting for ccmexec process to start.
Failed to create instance if Software Execution Request Managerr. 0x80070005
Waiting for ccmexec process to start.
GetActiveRequest failed with error code 0x87d01012
GetActiveRequest failed. 0x87D01012.
ReleaseActiveRequest failed. 0x87d01012.

Failed for reason:

One or more updates is causing a second reboot during the task sequence. The task sequence engine is not anticipating this reboot, and so does not set aside the data required to resume the task sequence after the reboot.

This is a known issue with the way Software Updates are installed during a task sequence. See the KB article:

Task sequence fails in Configuration Manager if software updates require multiple restarts

Resolution:

“You can avoid this issue in System Center 2012 Configuration Manager Service Pack 2 and System Center 2012 R2 Configuration Manager Service Pack 1 by using the new Retry option in the Install Updates task sequence step.”
–https://support.microsoft.com/en-us/kb/2894518

Error reported in smsts.log:

VerifyContentHash: Hash algorithm is 32780
Cannot open source file c:\_smstasksequence\packages\rtm00307\citrix receiver and plug-ins\de\wince\cesh3\icasetup.sh3.cab, Win32 Error = 32
Failed to hash file, Win32 error = 32
Hash could not be matched for the downloded content. Original ContentHash = 3A97E3916B3E2C0C6C5447637754A5DC3A674B9BC3D9F2CC703F320F4B62050B, Downloaded ContentHash = 
Failed to resolve the source for SMS PKGID=RTM00307, hr=0x80091007
The user tries to release a source directory C:\_SMSTaskSequence\Packages\RTM00307 that is either already released or we have not connected to it
Install Software failed, hr=0x80091007
Process completed with exit code 2148077575
!--------------------------------------------------------------------------------------------!
Failed to run the action: Citrix XenApp 6.5 (Package). 
The hash value is not correct. (Error: 80091007; Source: Windows)

Failed for reason:

We use Trend Micro OfficeScan as our antivirus solution. The OfficeScan real-time scanning was holding the file open, preventing the task sequencer from hashing the file to determine that it had been successfully downloaded. This caused the Package to fail and therefore the task sequence to fail. Uninstalling OfficeScan resolved the problem.

Error 32 translates to ERROR_SHARING_VIOLATION – The process cannot access the file because it is being used by another process.

This thread implicates Trend OfficeScan specifically in file-not-hashing problems: https://social.technet.microsoft.com/Forums/en-US/1fa16900-4f41-4b4c-9d40-a27ae266d5c8/media-creation-fails-with-the-hash-value-is-not-correct-and-cannot-open-source-file?forum=configmanagerosd

Error 0x80091007 in smsts.log could also be due to a problem calculating the original content hash, due to problems with the source files, so check for hidden files and that annoying thumbs.db (also, reportedly, with binary replication of the package).

To search for the error code, one needs to convert the integer to a hex value (33 = 0x00000020). See: Win32 Error Codes

Resolution:

Temporarily disable anti-virus or any other software that would be scanning files as they are downloaded to the computer, to avoid conflicts with the task sequence engine verifying the integrity of the downloaded files.

This is just a quick post on creating a operating system-based collection query rule for Windows 10 in SCCM 2012. In preparation for the release of Windows 10, I have been working on an OSD task sequence that applies the Windows 10 Enterprise Insider Preview and creating collections in SCCM. There are a number of different ways to construct an operating system-based collection, but one method works more quickly than an alternative.

As you know, the System Center Configuration Manager client reports back details of the workstation or server environment to the SCCM management point, including information about the operating system. This information can be used to populate device collections through WQL queries of information in the SCCM database. But similar, if not equivalent, information is collected through different processes by the client, resulting in the SCCM primary site server potentially having incomplete details of a device. This is particularly evident when looking for details about a workstation computer shortly after it has completed an OSD task sequence.

After a Hardware Inventory cycle is run, SCCM will have access to the Operating System.Caption value, which will be, for the Windows 10 Insider Preview, “Microsoft Windows 10 Enterprise Insider Preview”. This query can be made more general by using the LIKE operator and then wrapping the search term in percent symbols: %Windows 10 Enterprise%.

But, if you want to be able to add computers to a collection before a Hardware Inventory cycle is run, you can use System Resource.Operating System Name and Version, which will be, for the Windows 10 Insider Preview, “Microsoft Windows NT Workstation 10.0”. This can be made more general by using LIKE operator and wrapping the search term in percent symbols: %Windows NT Workstation 10%.

The Query Statement that I am using to populate my collection of Windows 10 workstations is:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.OperatingSystemNameandVersion like "%Microsoft Windows NT Workstation 10%"

This SMS_R_System.OperatingSystemNameandVersion query is useful because it is able to locate computers in SCCM within a few minutes after they have been reimaged, before the client has run a Hardware Inventory cycle. My hunch is that the operating system name and version are being sent to the management point as part of a Heartbeat Discovery that happens soon after the computer finishes the OSD task sequence. I’ll check the logs to confirm this.

Late in 2014, I ran into a problem installing Microsoft .NET Framework 3.5 on Windows 8.1 Enterprise with Update (x64) through an SCCM 2012 R2 Build and Capture task sequence.

I was following Microsoft’s instructions at Installing the .NET Framework 3.5 on Windows 8 or 8.1 to first copy the sources\sxs directory from the Windows 8.1 ISO to the C: drive of the reference computer via a package and then enable .NET Framework 3.5 by using the Deployment Image Servicing and Management (DISM) command-line:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:C:\DVD\sources\sxs

This process had worked in the past to successfully enable .NET Framework 3.5 during the Build and Capture task sequence, but when I ran the same Build and Capture task sequence a few months later, the Run Command Line step that executes the DISM command failed. The package that copied the sources\sxs directory was still able to successfully copy the files, but according to the logs, the DISM command couldn’t find files that it needed.

The DISM.log file contained some really unexpected entries, like:

Encountered an unknown option "featurename" with value "NetFx3"
Encountered an unknown option "source" with value "C:\DVD\sources\sxs"

I was using the command line exactly as specified by Microsoft, albeit with a different path to the source files. How could DISM not know the FeatureName and Source options?

When the task sequence failed, the following entries were written to smsts.log:

ProgramName = 'DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:C:\DVD\sources\sxs'	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
SwdAction = '0001'	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
Set command line: Run command line	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
Working dir 'not set'	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
Executing command line: Run command line	InstallSoftware	10/29/2014 10:16:51 AM	1976 (0x07B8)
Process completed with exit code 2148468767	InstallSoftware	10/29/2014 10:17:18 AM	1976 (0x07B8)
Command line returned 2148468767	InstallSoftware	10/29/2014 10:17:18 AM	1976 (0x07B8)
Process completed with exit code 2148468767	TSManager	10/29/2014 10:17:18 AM	2804 (0x0AF4)
!--------------------------------------------------------------------------------------------!	TSManager	10/29/2014 10:17:18 AM	2804 (0x0AF4)
Failed to run the action: Install .NET Framework 3.5 (from \sources\sxs\). 
Unknown error (Error: 800F081F; Source: Unknown)	TSManager	10/29/2014 10:17:18 AM	2804 (0x0AF4)

I also found the following errors in DISM.log:

2014-10-29 10:17:17, Info                  DISM   DISM Package Manager: PID=2600 TID=2084  Error in operation: source for package or file not found, ResolveSource() unsuccessful. (CBS HRESULT=0x800f081f) - CCbsConUIHandler::Error
2014-10-29 10:17:17, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 Failed finalizing changes. - CDISMPackageManager::Internal_Finalize(hr:0x800f081f)
2014-10-29 10:17:17, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 The source files could not be found; their location must be specified using the /source option to restore the feature. - GetCbsErrorMsg
2014-10-29 10:17:17, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 Failed processing package changes with session options - CDISMPackageManager::ProcessChangesWithOptions(hr:0x800f081f)
2014-10-29 10:17:17, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 Failed ProcessChanges. - CPackageManagerCLIHandler::Private_ProcessFeatureChange(hr:0x800f081f)
2014-10-29 10:17:18, Error                 DISM   DISM Package Manager: PID=2600 TID=1588 Failed while processing command enable-feature. - CPackageManagerCLIHandler::ExecuteCmdLine(hr:0x800f081f)

I had not changed the sources\sxs package in this time. The only change that I made between the command working a few months earlier and it now failing was to apply Software Updates to the Windows 8.1 install.wim file using offline servicing, but it didn’t occur to me that this would cause the problem.

Some Googling turned up an informative post at http://www.aidanfinn.com/?p=13351, where two Microsoft hotfixes, KB2966826 and KB2966828, were identified as the cause of the DISM failures.

KB2966826 MS14-046: Description of the security update for the .NET Framework 3.5 in Windows 8.1 and Windows Server 2012 R2: August 12, 2014

KB2966828 MS14-046: Description of the security update for the .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2: August 12, 2014

Because there seems to not be a built-in method within SCCM of removing software updates from an image file (although it can be done through DISM), I chose to start from the beginning:

  1. generate a new operating system image from the install.wim file in the Windows 8.1 ISO
  2. schedule offline updates to patch the install.wim file, but uncheck the boxes for those two hotfixes
  3. install .NET Framework 3.5 by running the install.wim file through a Build and Capture task sequence (putting the Install Software Updates step after the .NET Framework 3.5 installation)

I ran my Build and Capture task sequence using the new WIM that did not have KB2966826 or KB2966828 installed, and .NET Framework 3.5 installed successfully.

Because the KB2966826 and KB2966828 hotfixes are still available to the reference computer during the Build and Capture task sequence, they are installed through a typical Install Software Updates step that occurs after the .NET Framework 3.5 steps. The resulting WIM is fully patched and ready for use in an OSD task sequence.

Note that there is now a KB article addressing this problem, and a hotfix to remove the hotfixes from systems where they are not required: Update for the .NET Framework 3.5 on Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2. However, I still follow the steps above to build my reference computers.

It may be helpful to check the registry to determine which versions of .NET Framework are installed. I have found two Microsoft articles dealing with this issue. The first, How to determine which versions and service pack levels of the Microsoft .NET Framework are installed, does not identify registry values for versions 4.5.1 or 4.5.2. The second, How to: Determine Which .NET Framework Versions Are Installed, identifies registry values for determining which version of .NET Framework 4.5 and later is installed, and offers a different method of determining the version(s) of .NET Framework 1 – 4.

Microsoft Security Update for Windows 7 for x64-based Systems (KB2984976), titled RDP 8.0 update for restricted administration on Windows 7 or Windows Server 2008 R2 and released on October 14, 2014, as one of that month’s Patch Tuesday updates, appears to cause multiple restarts when applied during the Install Software Updates step within a System Center Configuration Manager Task Sequence. The second restart is not controlled by the Task Sequence engine and causes the engine to be unable to resume the Task Sequence when the computer comes back up after the second restart. The Task Sequence therefore fails to complete.

This behavior is a known issue with software updates that require multiple restarts, as documented in KB2894518, titled Task sequence fails in Configuration Manager if software updates require multiple restarts. Microsoft’s recommendation in KB2894518 is to deploy those updates that require multiple restarts outside of a Task Sequence.

If your patching procedure is to deploy Software Updates and other application updates during a maintenance Task Sequence and a hotfix is applied during the Install Software Updates step that causes multiple restarts, then the Task Sequence fails and potentially causes computers to go unpatched until they next run the Task Sequence. Therefore, it is important to quickly identify problematic hotfixes and deploy them outside of the Install Software Updates step in the Task Sequence.

When the Task Sequence fails due to a hotfix forcing multiple restarts, the TSManager component writes the following entries to smsts.log:

Failed to restore logs from cache. Execution history may be lost.	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Task Sequence Manager executing as service main thread	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Environment scope successfully created: Global\{51A016B6-F0DE-4752-B97C-54E6F386A912}	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Environment scope successfully created: Global\{BA3A3900-CA6D-4ac1-8C28-5073AFC22B03}	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Failed to locate the local data path. The files needed to resume the task sequence are missing.  This could be because the task sequence finished while in Windows PE.  Please check the largest available partition for SMSTSLog\smsts.log file for more information.
The system cannot find the file specified. (Error: 80070002; Source: Windows)	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Task Sequence Manager could not initialize Task Sequence Environment. code 80070002	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Task sequence execution failed with error code 80070002	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)
Cleaning Up.	TSManager	10/17/2014 2:21:52 AM	2644 (0x0A54)

The exact language of the entries will vary based on the version of SCCM, with the above coming from SCCM 2012 R2.

A method of determining the culprit

Until I can figure out how to tell whether an update is going to schedule its own restart by observing some property of the hotfix itself, I’m left using a time-consuming process of elimination to determine which hotfix is responsible for the second restart during a Task Sequence.

In our environment, we run updates through SCCM on both our 64-bit Windows 7 workstations and our Windows Server 2008 R2 servers, and sometimes these two platforms receive different updates. When the Task Sequence failure occurs on only one platform, the first thing I do is to look at the hotfixes that are not applied to both platforms.

This month, fourteen hotfixes that require a reboot are installed on our workstations during the Task Sequence. Below are the entries written to the Setup log in Event Viewer on a Windows 7 workstation, where a second reboot occurred. Items followed by an asterisk “*” also appear in the Setup log in Event Viewer on a Windows Server 2008 R2 server, where a second reboot did not occur.

A reboot is necessary before package KB2984972 can be changed to the Installed state. *
A reboot is necessary before package KB2972100 can be changed to the Installed state. *
A reboot is necessary before package KB3001554 can be changed to the Installed state.
A reboot is necessary before package KB2977292 can be changed to the Installed state. *
A reboot is necessary before package KB3000061 can be changed to the Installed state. *
A reboot is necessary before package KB3000988 can be changed to the Installed state. *
A reboot is necessary before package KB3000869 can be changed to the Installed state. *
A reboot is necessary before package KB2949927 can be changed to the Installed state. *
A reboot is necessary before package KB2968294 can be changed to the Installed state. *
A reboot is necessary before package KB2952664 can be changed to the Installed state.
A reboot is necessary before package KB2984976 can be changed to the Installed state.
A reboot is necessary before package KB2987107 can be changed to the Installed state. *
A reboot is necessary before package KB2979570 can be changed to the Installed state. *
A reboot is necessary before package KB2994023 can be changed to the Installed state. *

The process of elimination begins, then, with those hotfixes that were installed on the workstations but not on the servers. Thankfully, in our environment this is just three hotfixes:

To work through the suspect hotfixes, I set up a VMware virtual machine that was patched up to September 9, 2014. I created a snapshot of this test computer and then ran the maintenance Task Sequence on it to confirm that the Task Sequence abruptly ended during the Install Software Updates step.

Next, I selected one of the hotfixes to eliminate. My first choice was KB2952664 because it has a long and troubled history and seems to not be necessary in our enterprise environment. Even this month, it seems to be problematic, as it was released on October 14, then re-released on October 16. See the InfoWorld article Windows 7 patch KB 2952664 fails with error 80242016 for more on the struggles Microsoft has had with this hotfix. I removed KB2952664 from the Software Update Group deployed to the test computer, reverted to my snapshot and ran the maintenance Task Sequence again. It still ended abruptly, so KB2952664 was not the culprit.

Without re-adding KB2952664 to the Software Update Group, I removed KB2984976 from the Software Update Group. The KB2984976 hotfix deals with RDP and shares files in common with the last hotfix to require multiple restarts, KB2965788 (which was the subject of a similar blog post that I wrote about this problem back in June). Microsoft has now included KB2965788 among those hotfixes listed in KB2894518.

I reverted to my snapshot again and with KB2984976 unavailable to my test computer, the Task Sequence was able to proceed through the Install Software Updates step, indicating that KB2984976 is responsible for the multiple restarts among the October Patch Tuesday updates.

If anyone has a better method of identifying whether a hotfix is going to schedule a restart that is not controlled by SCCM, please post a comment. I would love to find a faster way, possibly by looking at how these hotfixes schedule the restart differently than most updates.

The October 2014 Patch Tuesday updates did not go smoothly for Microsoft:
http://www.infoworld.com/article/2834535/security/four-more-botched-black-tuesday-patches-kb-3000061-kb-2984972-kb-2949927-and-kb-2995388.html
http://www.infoworld.com/article/2834930/security/microsoft-yanks-botched-patch-kb-2949927-re-issues-kb-2952664.html

Microsoft Security Update for Windows 7 for x64-based Systems (KB2965788), which was released on June 10, 2014, as one of that month’s Patch Tuesday updates and titled MS14-030: Description of the security update for Remote Desktop Security Release for Windows: June 10, 2014, appears to cause multiple restarts when applied during the Install Software Updates step within a System Center Configuration Manager Task Sequence. The second restart is not controlled by the Task Sequence engine and causes the engine to be unable to resume the Task Sequence when the computer comes back up after the second restart. The Task Sequence therefore fails to complete.

This behavior is a known issue with software updates that require multiple restarts, as documented in KB2894518, titled Task sequence fails in Configuration Manager if software updates require multiple restarts.

At my firm, we deploy Software Updates and other application updates during a maintenance Task Sequence. When the Task Sequence fails to complete after the Install Software Updates step, the TSManager component writes the following entries to smsts.log:

Failed to restore logs from cache. Execution history may be lost.
...
Failed to locate the local data path. The files needed to resume the task sequence are missing.  This could be because the task sequence finished while in Windows PE.  Please check the largest available partition for SMSTSLog\smsts.log file for more information.
The system cannot find the file specified. (Error: 80070002; Source: Windows)
Task Sequence Manager could not initialize Task Sequence Environment. code 80070002
Task sequence execution failed with error code 80070002
...
Error executing Task Sequence Manager service. Code 0x80070002
MP name must be set in an environment variable
Non fatal error 0x80004005 in sending task sequence execution status message to MP
Successfully finalized logs to SMS client log directory from C:\Windows\CCM\Logs

Microsoft’s recommendation in KB2894518 is to deploy updates that require multiple restarts outside of a Task Sequence. If you choose to deploy hotfix KB2965788 as a traditional package or an application using a required deployment, it can be downloaded from Security Update for Windows 7 for x64-based Systems (KB2965788).

I was running into a problem with the installation of Microsoft .NET Framework 4.5.2 during an SCCM 2012 SP1 build and capture Task Sequence, both in Windows 7 and Windows 8.1, wherein the installer was running but the log files were not being created.

I was using the Application model in SCCM and executing the offline installer executable with the command line “NDP452-KB2901907-x86-x64-AllOS-ENU.exe /q /norestart” through a VBScript wrapper script.

When the application failed during the task sequence, the error in smsts.log read, in part:

Execution status received: 4 (Application failed to install )
Installation failed.
...
Install application action failed: 'Microsoft .NET Framework 4.5.2'. Error Code 0x80004005
...
Install Static Applications failed, hr=0x80004005
Process completed with exit code 2147500037
!--------------------------------------------------------------------------------------------!
Failed to run the action: Microsoft .NET Framework 4.5.2. 
Unspecified error (Error: 80004005; Source: Windows)

If I ran my installation wrapper script from the ccmcache subdirectory while logged on as the local administrator account, the .NET Framework 4.5.2 installation ran successfully.

According to the MSDN page .NET Framework Deployment Guide for Administrators, log files are written to “%temp%\Microsoft .NET Framework 4.5*.txt” and “%temp%\Microsoft .NET Framework 4.5*.html”, but neither of these logs existed on my Windows 7 and Windows 8.1 systems after the installation failed.

However, a log file at C:\Windows\Temp\dd_NDP452-KB2901907-x86-x64-AllOS-ENU_decompression_log.txt caught my eye. The contents of this decompression log read:

[5/22/2014, 16:42:35] === Logging started: 2014/05/22 16:42:35 ===
[5/22/2014, 16:42:35] Executable: C:\Windows\ccmcache\1\NDP452-KB2901907-x86-x64-AllOS-ENU.exe v4.5.51209.34209
[5/22/2014, 16:42:35] --- logging level: standard ---
[5/22/2014, 16:42:35] Successfully bound to the ClusApi.dll
[5/22/2014, 16:42:35] Error 0x80070424: Failed to open the current cluster
[5/22/2014, 16:42:35] Cluster drive map: ''
[5/22/2014, 16:42:35] Considering drive: 'A:\'...
[5/22/2014, 16:42:36] Drive 'A:\' is rejected because of the unknown or unsuitable drive type
[5/22/2014, 16:42:36] Considering drive: 'C:\'...
[5/22/2014, 16:42:36] Considering drive: 'D:\'...
[5/22/2014, 16:42:36] Drive 'D:\' is rejected because of the unknown or unsuitable drive type
[5/22/2014, 16:42:36] Drive 'C:\' has been selected as the largest fixed drive
[5/22/2014, 16:42:36] Directory 'C:\26169df5670339bdf66775485ff857\' has been selected for file extraction
[5/22/2014, 16:42:36] Extracting files to: C:\26169df5670339bdf66775485ff857\
[5/22/2014, 16:42:36] Error 0x80004005: Failed to extract all files out of box container #0.
[5/22/2014, 16:42:36] Error 0x80004005: Failed to extract
[5/22/2014, 16:42:36] Exiting with result code: 0x80004005
[5/22/2014, 16:42:36] === Logging stopped: 2014/05/22 16:42:36 ===

I Googled the rather generic error messages from the decompression log a little bit and didn’t find anything helpful, although I did find some recommendations to 1) extract the file using 7-Zip and then run the setup.exe, which I did not want to do, or 2) use the traditional Package/Program method, which I considered. On the day that I was going to give up on the Application model and just create a Package, I did a little more Googling on installing .NET Framework 4.5 through an SCCM task sequence and found a thread on the Technet forums that describes the problem exactly and gives a working solution:

.NET 4.5.1 Install only works when running on a UI session
http://social.technet.microsoft.com/Forums/en-US/4808233e-1410-4305-a8d1-0e88f3a6fdc8/net-451-install-only-works-when-running-on-a-ui-session?forum=configmanagerapps

The resolution described in the thread is to edit the properties of the Deployment Type to enabled “Run installation and uninstall program as 32-bit process on 64-bit clients.” (This setting is found on the Programs tab.) I modified the Deployment Type properties to run the installer as a 32-bit process and indeed it did install successfully during the task sequence.

For the Detection Rule, I chose to use a registry setting must exist:

HKLM\SOFTWARE\Classes\Installer\Products\6414876250E69FF3395387C6C7F05BEB\ProductName = Microsoft .NET Framework 4.5.2

Using the registry to determine the installed version of .NET Framework is rather tricky, but for versions of .NET Framework 4.5 and later, see How to: Determine Which .NET Framework Versions Are Installed.

Best of luck.

P.S. I expect, but will have to validate, that this method of running the installer as a 32-bit process might help with other applications that fail to install during a task sequence but run successfully via Software Center or Application Catalog when a user is logged on.