Tag Archives: troubleshooting

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.

I have found error ID 40, with the description “The event logging service encountered an error when attempting to apply one or more policy settings.” is written to the System event log when the Group Policy setting “Specify the maximum log file size (KB)” under “Windows Components/Event Log Service/System” is configured (either enabled and set to a valid size or disabled).

Log Name:      System
Source:        Microsoft-Windows-Eventlog
Date:          2/18/2016 11:44:46 AM
Event ID:      40
Task Category: None
Level:         Error
Keywords:      Service availability
User:          LOCAL SERVICE
Computer:      mycomputer.mydomain.com
Description:
The event logging service encountered an error when attempting to apply one or more policy settings.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Eventlog" Guid="{FC65DDD8-D6EF-4962-83D5-6E5CFE9CE148}" />
    <EventID>40</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000000000020000</Keywords>
    <TimeCreated SystemTime="2016-02-18T17:44:46.789855700Z" />
    <EventRecordID>1837</EventRecordID>
    <Correlation />
    <Execution ProcessID="1140" ThreadID="5600" />
    <Channel>System</Channel>
    <Computer>mycomputer.mydomain.com</Computer>
    <Security UserID="S-1-5-19" />
  </System>
  <UserData>
    <ChannelPolicyApplicationError xmlns="http://manifests.microsoft.com/win/2004/08/windows/eventlog">
      <Error Code="5">
      </Error>
      <ChannelPath>
      </ChannelPath>
    </ChannelPolicyApplicationError>
  </UserData>
</Event>

The same error will appear when the Group Policy setting “Specify the maximum log file size (KB)” is configured under “Windows Components/Event Log Service/Application” or “Windows Components/Event Log Service/Security”.

Unfortunately, the SCM Windows 10 TH2 – Computer GPO (which I like to use as a baseline security GPO) sets the maximum log size for the Application, Security and System logs, and because disabling the setting in a GPO with a lower link order does not prevent the errors from appearing, I have to choose between changing the Microsoft security baseline GPO and living with the errors in the event log. I have decided to modify the GPO and set the three maximum log size settings to Not Configured, and then change the size of the System event log using the command “wevtutil sl System /ms:33554432”, the Application event log with “wevtutil sl Application /ms:33554432” and the Security event log with “wevtutil sl Security /ms:201326592” during the SCCM OSD task sequence.

The outcome is that the logs are configured to their recommended sizes, as specified in the SCM GPO, but GP is not enforcing the log size. I feel like this is an acceptable workaround, as it avoid the errors in the System event logs, sets the logs to the Microsoft-recommended size, and standard users will not be able to change the maximum log size via the Log Properties page.

Over the Thanksgiving weekend, I upgraded one of my computers from Windows 7 to Windows 10 using Windows Update. It had been nagging me to upgrade for awhile and I finally gave in and did it. The upgrade appeared to go smoothly, but when I logged on to Windows 10 for the first time, I realized that I didn’t have any of my settings or files. I checked the Application event log and sure enough, I was logged in with a TEMP profile.

I Googled this a bit, thinking that perhaps it has happened to a few other people who could point me to a quick resolution, but it didn’t seem to be a common problem. Also, the proposed fixes (like running sfc /scannow didn’t strike me as being very promising.

So I open the Local Users and Groups manager (lusrmgr.msc) and checked the group membership of my account. I found that it was a member of the Administrators group and a HomeUsers group, but not a member of the Users group. I checked a Windows 10 computer that I had built from the 10240 build ISO as a clean install and didn’t find a HomeUsers group at all. Back on the problem computer, I added my broken account to the Users group, restarted, and logged in. This time, Windows took my account through the typical first-run setup stuff and then loaded the correct profile, with all of my settings and files from Windows 7 intact.

So, if you run into the problem where an account on a recently upgraded Windows 10 computer is missing settings and files, check the group membership. If the account is not a member of the Users group, you will not be able to log in properly. Add the account to that group, logout and then log back in. Your problem should be fixed

Today I learned that Microsoft Edge on Windows 10 does work with an Enterprise Mode Site List after all. I had been trying in vain for weeks (off and on) to get it to redirect into Internet Explorer those sites that I had configured to do so through the Enterprise Mode Site List XML file. As far as I could tell, I was correctly using the Group Policy setting “Allows you to configure the Enterprise Site list”, providing a valid UNC path to the sites.xml file on our DFS. No matter how I configured the contents of the file, Edge simply would not perform the redirection. The redirection would work flawlessly if I configured the Group Policy setting “Sends all intranet traffic over to Internet Explorer”, but I didn’t want to open all of our intranet sites in IE, and there were plenty of Internet sites that I wanted to open in IE.

Internet Explorer 11 on Windows 7 had been successfully retrieving the sites.xml file via a UNC path, rather than an URL, for months. Furthermore, Internet Explorer 11 on Windows 10 was able to retrieve the file via UNC path. Running short of new things to try, on a whim, I copied the sites.xml file to a web server and provided the path in the Group Policy setting as an HTTP address, and lo and behold, Edge happily loaded the file and redirected users to Internet Explorer.

To be sure I wasn’t making up the ability to use a UNC path, I checked the TechNet article Use Enterprise Mode to improve compatibility, which is part of the Microsoft Edge – Deployment Guide for IT Pros. It clearly states that the SiteList value at HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\MicrosoftEdge\Main\EnterpriseMode accepts a UNC path, and this is what was being created by my Group Policy setting. However, the Group Policy setting’s field, into which you enter the path, asks for a URL. So, perhaps the TechNet document is wrong. Maybe the editor simply copied and pasted from the IE11 article Turn on Enterprise Mode and use a site list, and did not validate those instructions for Microsoft Edge.

Anyway, I hope that this post helps other systems administrators who may find themselves in the same situation, but I also wish that Microsoft would address this inconsistency between Edge and IE. A UNC path on our DFS (which is something within my control) is far easier for me to administer than a file on a web server (which is outside of my control).

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.

Update 8/12/2015: I’ve determined that the problem is due to my attempts at creating a custom Windows.UI.Logon.pri file to display a logon screen background image. Neither the utility nor the PowerShell script referenced below create a Windows.UI.Logon.pri file that is acceptable to Windows. In the meantime, I’ve decided to just eliminate the “Hero” wallpaper in favor of a solid color.

I’ve encountered a problem with Windows 10 Enterprise with Cumulative Update for Windows 10: August 5, 2015 (KB3081424) applied, where the secure logon screen is completely black instead of displaying the Ctrl+Alt+Delete message, clock, background wallpaper, etc.

Prior to KB3081424, I experienced a different problem at the Ctrl+Alt+Delete screen, where the lock screen wallpaper configured via Group Policy was not applied and the background was instead a solid blue color.

In both cases, the behavior was/is only evident when the registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DisableCAD is set to 0 (enforcing the Ctrl+Alt+Del screen). Deleting the DisableCAD value avoids the problem, however, it also removes the benefit of the secure logon screen.

When the computer is locked (for example, by hitting Ctrl+Alt+Del and selecting the Lock option) and the screen goes black, the following event is written to the Application event log:

Log Name:      Application
Source:        Application Error
Date:          8/7/2015 5:06:41 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      mycomputer.mydomain.com
Description:
Faulting application name: LogonUI.exe, version: 10.0.10240.16384, time stamp: 0x559f398c
Faulting module name: Windows.UI.Xaml.dll, version: 10.0.10240.16412, time stamp: 0x55b9a054
Exception code: 0xc000027b
Fault offset: 0x0000000000494ab9
Faulting process id: 0x1fdc
Faulting application start time: 0x01d0d15d56f2c0bf
Faulting application path: C:\WINDOWS\system32\LogonUI.exe
Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
Report Id: 351d24a4-a031-4135-b595-334baef2ba99
Faulting package full name: 
Faulting package-relative application ID:

Watching the LogonUI.exe process with Sysinternals Procmon shows that the process crashes when the computer is locked, causing the screen to go black. Hitting the Ctrl+Alt+Del key combination at the black screen launches a new LogonUI.exe process, the wallpaper image loads, and I’m taken to the logon page where I can enter my username and password and log on.

The problem exists on physical hardware as well as in a VMware Workstation 11 virtual machine, so I’m confident that it is not a driver-related issue. The only other particular thing about my setup is that I’m generating my own Windows.UI.Logon.pri wallpaper file using the utility discussed at: http://www.askvg.com/how-to-change-or-disable-login-screen-background-image-in-windows-10/ (although revisiting this page now indicates that .pri file generated by the utility may be responsible for lock screen problems).

I’ll test with the default wallpaper image, and with my desired wallpaper image repacked using the PowerShell script at: http://pastebin.com/aMBrHRwd .

Even if the Windows.UI.Logon.pri is the cause of the LogonUI.exe crashes, a bad file seems like something that the LogonUI process should tolerate.

I posted the problem to Microsoft’s Windows Feedback on 8/10/2015. A Google search turned up a few other people who have had problems at the lock screen, and there are a number of reports of similar problems going back a few versions of Windows.

I recently worked with Microsoft to resolve a problem in our Windows 8.1 environment where Group Policy Preference Drive Mappings to shares on the DFS were failing when users logged in immediately after a computer restart. Through the use of procmon boot logging, we were able to identify that the ApplySettingsTemplateCatalog.exe process, which is part of UE-V 2.1 and which is triggered at computer startup by the Microsoft\UE-V\Template Auto Update scheduled task, was attempting to access the DFS soon after the Offline Files service started and before the network was initialized. Offline Files recognized that the DFS was not available and transitioned the DFS root to offline mode. If a user logged on before Offline Files re-evaluated the DFS root two minutes later, the drive mappings would fail, along with any other attempts to access locations on the DFS.

To work around this problem, we added a one minute delay to the “at startup” trigger on the Template Auto Update task. The task therefore does not attempt to access a location on the DFS before the network is ready, and consequently Offline Files does not step in and take the DFS offline.

Some background on our environment and observations of the problem

Our users’ home drives are specified in each user’s account in AD. The home drive is connected to a path on the DFS and is assigned to drive letter H.

The Documents folder is redirected into the user’s home drive on the DFS via Group Policy and is automatically made available offline.

GPP drive mappings to shares on the DFS fail when users log on after a computer restart.

GPP drive mappings to non-DFS locations (shares on various servers) are always successful.

The Offline Files/Operational event log contains “Path disconnected” (Event ID 9) entries to the DFS root and the parent directory of the user’s home drive during boot and logon when the drive mappings fail. The log contains “Path reconnected” (Event ID 10) entries to the DFS root and the parent directory of the user’s home drive shortly after logon.

When the drive mappings fail, if File Explorer is opened immediately after logon, only the redirected Documents folder and the UE-V SettingsPackages folders are visible in the user’s home drive. Navigating into the Documents folder and highlighting a file shows the state as “Offline status: Offline (not connected).” in the details pane of File Explorer. This indicates that Offline Files has transitioned the path to “Auto offline mode”. After a few moments, the rest of the folders in the user’s home drive will appear in File Explorer and the state of the files in the Documents folder will change to “Online”.

If Offline Files is disabled via Group Policy, or if the CSC kernel driver is disabled via a registry value, the drive mappings are always successful.

If the CSC is re-initialized by creating the FormatDatabase registry value and rebooting the computer, the user is able to log in with successful drive mappings.

Obscuring the cause

As is often the case, I could have arrived at the cause more quickly if I had let the facts tell their story.

In the beginning of my troubleshooting, I ruled out a network problem by running a few Wireshark captures that showed that the computer was not attempting any network connections to the DFS when the drive mappings failed. This took a few hours, but was fun and informative, so it wasn’t a waste of time by any means.

I also spent considerable time making changes to the Offline Files settings in Group Policy, the GPP drive map options, and the user’s home drive, and testing the effects of these changes. I gained quite a bit of new understanding in these areas, but was, in hindsight, off base.

I would occasionally see that the HOMESHARE environment variable was missing, and that the HOMEDRIVE and HOMEPATH variables had incorrect values. This, too, was a very interesting observation that did not get me any closer to the cause of the problem.

The Offline Files Operational log entries, when matched up chronologically against the System log events, would have shown that the DFS was being transitioned offline before the network was up, but I was distracted by all of the user-specific elements involved. The problem was occurring much earlier in the startup process than I realized.

Procmon illuminates the root cause

At Microsoft’s suggestion, I enabled boot logging in procmon and captured the events during computer startup. With this new source of information available, I finally got around to looking at what was happening on the computer at the time that Offline Files was transitioning the DFS to offline mode.

The critical piece of the puzzle, I believe, was that we were locating our UE-V Template Catalog directory on the DFS as well. It was this path that was being evaluated on boot – not any path to do with the users’ home drives or the redirected Documents folder. When UE-V attempted to access the Template Catalog path before the network was initialized by way of the Template Auto Update scheduled task, Offline Files properly transitioned the DFS to offline mode. Offline Files transitioned the DFS back to online two minutes later, but by this time, the user had already logged on and the GPP drive mappings had already failed.

Closing thoughts

It seems to me that this problem would occur with some frequency, as it may be reproduced in what I imagine to be a pretty typical corporate environment:

  1. hardware capable of starting up the Client Side Caching kernel driver and running the Template Auto Update scheduled task before the network is available
  2. Offline Files enabled (it is enabled by default)
  3. user home drives located on the DFS at a path like \\domain\dfsroot\users\%username%
  4. Documents folder redirected to a location on the DFS like \\domain\dfsroot\users\%username%\documents
  5. UE-V Template Catalog directory located on the DFS at a path like \\domain\dfsroot\data
  6. GPP drive maps to shares on the DFS at paths like \\domain\dfsroot\public_documents

In this completely reasonable scenario, two pretty amazing Microsoft technologies, at their default settings, fail to work well together and cause the failure of a third technology.

The Microsoft support engineer handling this case also explained why the HOMESHARE variable was occasionally not set:

The HOMESHARE environment variable is set by the profile service while a user is logging in and has a home drive specified on their account. This will be set upon successful mapping of the home drive. If that is not mapped successfully then it is not set and HOMEDRIVE and HOMEPATH are set to c:\ and \USERS\<username> respectively. This is just a symptom of the root being taken offline earlier and maybe for a user that hasn’t logged onto the machine and cached any information yet with the root being offline. Also with the root being offline, the user’s home drive may map successfully, but other mapped drives that map into the DFS Namespace can fail.

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.

A problem arises in Citrix when Internet Explorer (iexplore.exe) is specified as a launch method for a file type in OpenText eDOCS DM and the full path to the executable is not specified.

For example, assume that Microsoft Visio Viewer 2010 or Visio Viewer 2013 is installed on a Citrix server and Internet Explorer is set as the launch method in Library Maintenance for opening Visio VSD files. In this scenario, when a user double-clicks a Visio document in DM Extensions Explorer, Internet Explorer is launched to open the document, but the user receives a “file not found” message and the document does not open. The problem only occurs when the launch method’s location field in Library Maintenance contains only the “iexplore.exe” value and not the full path to “C:\Program Files\Internet Explorer\iexplore.exe” (for 64-bit IE 10+).

The problem appears to be due to the presence of another “iexplore.exe” executable that is part of Citrix XenApp 6.5 and is located in “C:\Program Files (x86)\Citrix\system32\iexplore.exe”. The Citrix “iexplore.exe” executable is necessary for content redirection. The resolution is to modify the launch method in Library Maintenance for the file type in question (ex. the application handling VSD files) by browsing to the 64-bit version of iexplore.exe at “C:\Program Files\Internet Explorer\iexplore.exe”.

My best technical explanation for this problem, based solely on observing the behavior, is that in the absence of a full path in the launch method location field, eDOCS DM will search the system folders for an executable with a name that matches that in the location field. In the case of a system with Citrix XenApp 6.5 installed, the iexplore.exe executable that DM finds and chooses to use is “C:\Program Files (x86)\Citrix\system32\iexplore.exe”. When a user double-clicks on a file that is to be opened using iexplore.exe, DM launches “C:\Program Files (x86)\Citrix\system32\iexplore.exe” and passes the file path as an argument, which is a legitimate way of opening a VSD file in IE. When the Citrix iexplore.exe process starts up, it realizes that it is not needed, so it calls the Windows version of iexplore.exe and passes along the argument, and then the Citrix iexplore.exe process quits. In order to clean up files from the Temp directory, DM watches the processes that it starts. DM watches for the Citrix iexplore.exe process to end, and when it does, DM deletes the document from the DM Temp location. By the time that the Windows version of iexplore.exe is ready to open the file, the file no longer exists. So, the user gets a “file not found” message instead of the document.

Using Process Explorer, it’s possible to observe the dm.exe process deleting the document from the DM Temp location moments after it is created.

Unfortunately, OpenText itself provides the bad advice that causes this problem. See Knowledge Center article number 32382552 (free registration necessary):

In Document Management, eDOCS Edition (eDOCS DM), how can you set up the Microsoft Visio 2010 Viewer application to work within DM?

The Visio 2010 Viewer application included with Microsoft Office 2010 uses Microsoft Internet Explorer to open Visio documents. To allow the Viewer application to function within DM, create a launch method as follows:

Location = IEXPLORE.EXE
Command Line Parameters = -nohome %FULLPATH
Integration = No Integration

There are no DDE Settings intended.
Please note this configuration only allows viewing Visio documents.

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=32382552&objAction=ArticleView&viewType=1

Note that if the launch method’s location value is not configured correctly, such that the executable handling the file type cannot be located at the path specified, then the “No valid launch method” message is displayed when the user double-clicks a file in DM Extensions Explorer. When configuring the launch method to use the full path, our systems administrators received this “No valid launch method” message when they copied and pasted the path into the location field, but successfully resolved the problem by browsing to the executable at “C:\Program Files\Internet Explorer\iexplore.exe”.

While we have chosen to use the 64-bit version of iexplore.exe in our launch method, either of the IE executables can be used to open a VSD file when launched from a command line:

“C:\Program Files\Internet Explorer\iexplore.exe” -nohome “C:\DM\test_601\DMS\SAN_FRANCISCO-#17907-v1-Test_Visio.VSD”
or
“C:\Program Files (x86)\Internet Explorer\iexplore.exe” -nohome “C:\DM\test_601\DMS\SAN_FRANCISCO-#17907-v1-Test_Visio.VSD”

However, I have not tested whether the 32-bit version of iexplore.exe works as a launch method for systems with Internet Explorer 10+.