Tag Archives: Group Policy

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.

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.