Tag Archives: desktop engineering

This article is intended for systems administrators who use Group Policy/Group Policy Preferences to manage computers in a domain environment.

Among the many challenges faced by Windows desktop engineers, configuring Internet Explorer in a corporate environment to provide a good balance of security and convenience stands out as particularly difficult to get right. I cannot think of any other piece of software that has required more of my time and effort to tailor to our needs than IE. Nor can I think of another application that generates as many non-error-related calls to our help desk. My project this week has been to develop a process for allowing approved ActiveX controls (ie., vetted controls used by business-purpose sites) to be silently installed and enabled by end users without granting sites more rights than needed.

While working on this project, I found that there is a good deal of interplay among multiple Group Policy settings that, once configured, permit standard users to download, install, and enable ActiveX controls so that web sites “just work”. This blog post should help you configure those settings in three steps.

Step 1: Download

The first order of business is to allow a standard user to download the ActiveX control files from sites in the Internet Zone. This can be done by configuring the “Download signed ActiveX controls” and the “Download unsigned ActiveX controls” Group Policy settings in Computer Configuration/Policies/Administrative Templates/Windows Components/Internet Explorer/Internet Control Panel/Security Page/Internet Zone. My understanding is that signed code from trusted publishers is always downloaded silently if the “Download signed ActiveX controls” setting is Enabled and the drop down menu item is set to Enable or Prompt. (It’s not clear to me why signed add-ons from trusted publishers wouldn’t be separately configurable here.) I have set “Download signed ActiveX controls” to Enable, and “Download unsigned ActiveX controls” to Prompt, although the more secure setting would be to Disable downloading unsigned controls.

Step 2: Install

The next order of business is to allow a standard user to install ActiveX controls for specific sites. This can be done by configuring the “Approved Installation Sites for ActiveX controls” setting in Computer Configuration/Policies/Administrative Templates/Windows Components/ActiveX Installer Service.

For each web site, enter the full domain name of the site where the ActiveX control is hosted (wildcards are not allowed) and provide a series of values governing the installation of trusted and signed, signed, and unsigned files, along with exceptions to HTTPS certificate errors. The default series of values is “2,1,0,0”, and I’ll expand on this later in the post. You may need to relax these settings for individual sites depending on whether the control is signed or if the site has HTTPS errors. Enter a detailed comment explaining the rationale for configuring the item (who configured it, when and why), so that you or another administrator can periodically revisit the list and evaluate whether the entries are still necessary and whether the settings are still correct.

A decent amount of thought needs to be given to the significance of the values, which are described more fully at Implementing and Administering the ActiveX Installer Service. The first three numbers in the default setting of “2,1,0,0” will (1) allow an ActiveX control that is signed by a certificate in the Machine or Enterprise Trusted Publishers store to be installed silently, (2) prompt the user before installing an ActiveX control that is signed by a certificate that is not in the Trusted Publisher Store, (3) and not install an unsigned ActiveX control.

For example, if we wish to allow the “Microsoft Update Catalog” ActiveX control to be silently installed when a user visits http://catalog.update.microsoft.com/v7/site/Install.aspx, we can add the domain name “http://catalog.update.microsoft.com” to the list and give it the values “2,1,0,0”. Because this ActiveX control is signed by a certificate in the Machine or Enterprise Trusted Publishers store, the first value “2” allows the silent installation.

If the user encounters an ActiveX control that can be downloaded but is not permitted to be installed silently, the user will receive a Security Warning pop-up window from the ActiveX Installer Service similar to the screen capture below.

Prompting the user for permission to install

Prompting the user for permission to install

In this case, the user encountered a signed ActiveX control that was not signed by a certificate in the Machine or Enterprise Trusted Publishers store. If we want to suppress this prompt so that the control will be installed silently, we would need to change the second number in the series to “2”, as so: “2,2,0,0”.

Step 3: Enable

As conscientious system engineers concerned about removing distractions for our users, we may wish to suppress the “This webpage wants to run the following add-on: ‘<add-on name>’ from ‘<company name>’.” warning/alert that appears in Internet Explorer when a user visits a site that loads an ActiveX control that has been downloaded and installed, but for which the ActiveX control is not yet enabled for the user.

This webpage wants to run the following add-on

This webpage wants to run the following add-on

To silently enable a specific ActiveX control for a specific domain for the current user, we can use Group Policy Preferences to create a registry value under HKCU with the Class ID (CLSID) of the add-on and the domain name where it is allowed to run. Be sure to enter a detailed comment explaining the rationale for configuring the item. The Class ID can be found via the Manage Add-ons dialog box (which means that the add-on will at least need to be downloaded).

For example, if we intend to allow the “Microsoft Update Catalog” ActiveX Control to be silently enabled to run on microsoft.com or any subdomain of microsoft.com, we may create the following registry key:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\{5AE58FCF-6F6A-49B2-B064-02492C66E3F4}\iexplore\AllowedDomains\microsoft.com]

If we intend to allow the ActiveX Control to run on any site, we would create a key named “*” (an asterisk) in place of the domain name, for example:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\{5AE58FCF-6F6A-49B2-B064-02492C66E3F4}\iexplore\AllowedDomains\*]

That’s all there is to it. When a user encounters a site that requires an approved ActiveX control, the control will be downloaded, installed, and enabled in the background.

How can I enable an add-on and prevent users from disabling it?

The Group Policy setting “Add-on List”, available in both the User Configuration and Computer Configuration, accepts a CLSID and a numerical value indicating how the add-on should be handled. A 0 (zero) indicates that the add-on should be disabled and users should be prevented from enabling it. A 1 (one) indicates that the add-on should be enabled and users should be prevented from disabling it. A 2 (two) indicates that the add-on should be enabled and users should be permitted to enable and disable the add-on through the Manage Add-ons dialog box.

However, in my experience, configuring an add-on with a value of 2 does not automatically enable the add-on for users, and they will see the yellow bar asking them if they want to enable or disable it when they open IE. I can’t quite see the use case for the value of 2.

The (User) setting is found at User Configuration\Administrative Templates\Windows Components\Internet Explorer\Security Features\Add-on Management. The registry keys for add-ons configured via the “Add-on List” setting in the User Configuration, named by CLSID, can be found as subkeys under:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Ext\CLSID]

How do I get more information about an add-on?

The details of each downloaded or installed add-on can be viewed using the Manage Add-ons dialog box in IE. Locate the add-on in the list and click the More Information link to view the Class ID as well as other information. For example, the details of the Microsoft Update Catalog control referenced throughout this post look like this:

Name: Microsoft Update Catalog
Publisher: Microsoft Corporation
Type: ActiveX Control
Architecture: 64-bit
Version: 7.4.7057.249
File date: ‎Thursday, ‎June ‎20, ‎2013, ‏‎10:56 AM
Date last accessed: ‎Today, ‎April ‎16, ‎2015, ‏‎3 minutes ago
Class ID: {5AE58FCF-6F6A-49B2-B064-02492C66E3F4}
Use count: 8
Block count: 30
File: MicrosoftUpdateCatalogWebControl.dll
Folder: C:\Windows\System32

How do I get information about the ActiveX control file itself?

The binary file itself will be referenced in the HTML of the page that requires or installs the control. My preferred method of finding the binary is to use the DOM Explorer in IE’s F12 Developer Tools to view the rendered HTML of the page where the control is installed, and the search for the string “codebase”.

If we look at the HTML of the page at http://catalog.update.microsoft.com/v7/site/Install.aspx, we can find an OBJECT tag that contains the CODEBASE attribute which contains a relative path to a .cab file that is the control. As of this writing, the path is “ClientControl/en/x86/MuCatalogWebControl.cab?1429300094107#version=9.0.1268.0”. To find the absolute path to the .cab file, so that we can download it and inspect it, we need to join the URL of the page up to the last folder with the contents of the CODEBASE attribute, like so:

http://catalog.update.microsoft.com/v7/site/ClientControl/en/x86/MuCatalogWebControl.cab?1429300094107#version=9.0.1268.0

Entering that URL in a browser will allow you to download the file and look at it. In the case of a digitally signed file, viewing the Properties of the file will reveal a Digital Signatures tab with more details about the signer and the certificate. An ActiveX control can be a .cab, a .dll, or a .ocx file.

So why don’t I need to enable the Adobe Flash ActiveX control in this way?

According to the MSDN blog post Controlling ActiveX in Internet Explorer, certain controls are exempt from requiring user approval to be enabled, including Adobe Flash. You can find the Class IDs for these pre-approved controls at:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved]

As an alternative to the GPP HKCU registry method of approving ActiveX controls described above, an administrator could create a Class ID subkey under the PreApproved registry key to pre-approve the ActiveX control for all users of the computer on all web sites. Setting such a subkey still permits the user to Disable and Enable the add-on through the Manage Add-ons dialog box.

For example, if we intend to approve the “Microsoft Update Catalog” ActiveX control to run on any site, we would create the following HKLM key, for example, during operating system deployment:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved\{5AE58FCF-6F6A-49B2-B064-02492C66E3F4}]

Using Trusted Sites

It is also possible to use the Trusted Sites zone as the mechanism for controlling installation policy for ActiveX controls. This can be done by configuring the “Establish ActiveX installation policy for sites in Trusted zones” setting in Computer Configuration/Policies/Administrative Templates/Windows Components/ActiveX Installer Service. The same options for trusted/signed, signed, and unsigned controls as well as exceptions for HTTPS errors exist in this setting, but they apply to any site in the Trusted Sites zone. Consider this carefully – once this setting is enabled and configured, any site in the Trusted Sites zone will be allowed to silently install ActiveX controls, even those sites that you may not wish to do so, and exceptions for signed/unsigned controls and HTTPS errors will be applied to all sites. This setting therefore offers far less granularity than configuring each site individually using the “Approved Installation Sites for ActiveX controls” setting described above.

You may need to disable unwanted ActiveX controls installed from these sites via GP by Class ID.

Sites can be added to the Trusted Sites zone via the “Site to Zone Assignment List” setting in User Configuration/Policies/Windows Components/Internet Explorer/Internet Control Panel/Security Page.

Microsoft’s recommendations

The Deployment Guy’s Enterprise Management of ActiveX Controls using ActiveX Installer Service blog post on TechNet describes some recommendations, including to install ActiveX controls only from reputable organizations, deploy commonly used ActiveX controls through your organization’s software deployment system rather than allowing controls to be installed automatically via the ActiveX Installer Service, and using only HTTPS hosted controls. These are excellent suggestions, but it’s not likely that your organization can follow all of these recommendations all of the time.

Troubleshooting

If ActiveX Filtering is enabled, IE prevents ActiveX controls from running on all web sites, except for those sites that have been added to the per-site exception list by the user. In IE11, if ActiveX filtering is enabled, a blue circle with a slash through it will appear on the right-hand side of the address bar.

See the MSDN blog post ActiveX Filtering for Consumers for an explanation of ActiveX Filtering.

If ActiveX Filtering is enabled via Group Policy, per-site exceptions can be created by a standard user by clicking on the blue circle with a slash through it in the address bar. Sites that have been added to the per-site exception list will be saved as registry values to the key at:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Safety\ActiveXFilterExceptions]

If Enhanced Protected Mode is enabled, add-ons must be compatible with Enhanced Protected Mode in order to run without user intervention.

Internet Explorer's Enhanced Protected Mode

Internet Explorer’s Enhanced Protected Mode

As with ActiveX Filtering, it is possible to populate a per-site exception list for Enhanced Protected Mode. Sites that have been added to the exception list by clicking the “Run control” button in the alert box will be saved as registry values to the key at:

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\TabProcConfig]

The Data for the values is a bit confusing, but the blog post How Internet Explorer Enhanced Protected Mode (EPM) is enabled under different configurations begins to explain the settings.

I recommend reading the MSDN blog post Understanding Enhanced Protected Mode, which is a pretty technical explanation of the subject, noting the differences in its implementation between Windows 7 and Windows 8.

ActiveX control blocking

Internet Explorer 8 through 11 includes a feature called out-of-date ActiveX control blocking, which is another candidate for configuration through Group Policy. If left unconfigured, scary looking security warnings may be displayed to users stating that certain controls are out of date.

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.