A test case for troubleshooting group policy application – Event ID 1085 and 7016

Craig here again. Let’s take a look at a specific flavor of 1085 event, and its equivalent on Vista/2008, event 7016. The 1085 would show up in the Application log on XP/2003. The 7016 would show up in the Group Policy operational log on Vista/2008 (Event Viewer\Applications and Services Logs\Microsoft\Windows\Group Policy\Operational).

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1085
Date: 7/29/2008
Time: 11:03:23 AM
User: NT AUTHORITY\SYSTEM
Computer: M1
Description:
The Group Policy client-side extension Internet Explorer Zonemapping failed to
execute. Please look for any errors reported earlier by that extension.

Log Name: Microsoft-Windows-GroupPolicy/Operational
Source: Microsoft-Windows-GroupPolicy
Date: 7/29/2008 11:39:53 AM
Event ID: 7016
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: M7.contoso.com
Description:
Completed Internet Explorer Zonemapping Extension Processing in 31 milliseconds.
Event Xml:
<Event xmlns="https://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-GroupPolicy"
Guid="{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}" />
<EventID>7016</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>2</Opcode>
<Keywords>0x4000000000000000</Keywords>
<TimeCreated SystemTime="2008-07-29T15:39:53.866Z" />
<EventRecordID>6128</EventRecordID>
<Correlation ActivityID="{917B65C2-7289-4E9C-8CE0-2364319F6D66}" />
<Execution ProcessID="1092" ThreadID="2332" />
<Channel>Microsoft-Windows-GroupPolicy/Operational</Channel>
<Computer>M7.contoso.com</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="CSEElaspedTimeInMilliSeconds">31</Data>
<Data Name="ErrorCode">87</Data>
<Data Name="CSEExtensionName">Internet Explorer Zonemapping</Data>
<Data Name="CSEExtensionId">{4CFB60C1-FAA6-47F1-89AA-0B18730C9FD3}</Data>
</EventData>
</Event>

The 1085 event doesn’t give us the error code. In Vista/2008, the error code shows up on the Details tab of the 7016 event.

To view the error code on XP/2003, we need to enable Userenv logging (KB article 221833). Once you’ve enabled Userenv logging and run gpupdate /force, take a look at the %windir%\debug\usermode\userenv.log.

If you do a CTRL+F ( Edit | Find) in Notepad for the text string ProcessGPOList: Extension Internet Explorer Zonemapping returned you’ll jump down to the interesting part.

ProcessGPOList: Extension Internet Explorer Zonemapping returned 0x57.

A little Notepad trivia for you – you can view the current line number or go to a different one by using CTRL+G (Edit | Go To…), but that only works if you have Word Wrap disabled (Format | Word Wrap).

The 0x in 0x57 tell us it is a hexadecimal number. 57 hex equals 87 decimal. So the return code in the Userenv.log on XP/2003 is really the same as the error code in the 7016 on Vista/2008. The 7016 is just giving it to us in decimal instead of hex. To map the 0x57 (81) to an error string, we can download Err.exe. Err will accept the decorated hex (0x57) or decimal (81) as input. You can also pull these up on the Win32 Error Codes page on MSDN.

C:\err 0x57
# for hex 0x57 / decimal 87 :
XNS_INTERNAL_ERROR bugcodes.h
MSG_E_BAD_DEFAULT_CA_XCHG_CSP certlog.mc
# Certificate Services could not use the default provider for
# encryption keys. %1
LLC_STATUS_INADEQUATE_LINKS dlcapi.h
NMERR_FRAME_HAS_NO_CAPTURE netmon.h
ERROR_INVALID_PARAMETER winerror.h
# The parameter is incorrect.
LDAP_FILTER_ERROR winldap.h
# 6 matches found for "0x57"

Ok, so we’ve got an invalid parameter somewhere. Let’s go ahead and first find the Group Policy object (GPO) that is causing the pain. On Vista/2008, it is as easy as looking on the General tab of the 4016 event that will come right before the 7016 error event. In the example below, the admin has deviated from best practices, so instead of a helpful name such as Site to Zone Assignment List GPO, it is named something less informative.

On XP/2003 we don’t have this nice 4016 event to tell us the name of the offending GPO. But almost as easily we can use Rsop.msc to find it. You can use Rsop.msc to find it on Vista/2008 too, but the 4016 is easier.

You can also double-click on Site to Zone Assignment List and see the GPO name on the Precedence tab.

So we know the offending GPO, and we can actually look at what it is trying to use right here in Rsop.msc by viewing the Setting tab and clicking Show.

And there is our problem - 192.168.* is not a valid value. Instead you could use 192.168.*.*.

Examples of invalid values:

192.168.*
https://*
https://contoso.*.com

Examples of valid values:

www.contoso.com
https://*.contoso.com
*://*.contoso.com
https://*.contoso.co.uk
192.168.*.*

At this point you would fire up the Group Policy Management Console (Gpmc.msc) or Active Directory Users & Computers (Dsa.msc) and make the appropriate edit to the Site to Zone Assignment List policy in the offending GPO. Site to Zone Assignment List is located under User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page. It is also possible you configured this in local policy, in which case you would edit it by running the Group Policy Object Editor (Gpedit.msc) on the local machine.

And that pretty much wraps it up. An event 1085 or 7016 error referencing the Internet Explorer Zonemapping client-side extension with error code 0x57 (81) can be caused by an invalid value in the Site to Zone Assignment List policy setting. But there are a few other details that may be interesting.

We saw the invalid value is visible in Rsop.msc and of course in the policy itself, but there are a few other places it shows up, namely the registry, the Userenv.log (XP/2003), the Gpsvc.log (Vista/2008), and finally the registry.pol file.

It is interesting to note that even when we are getting 1085 or 7016 errors, the invalid values will be set successfully in the registry and the Userenv.log/Gpsvc.log will reflect that.

Userenv logging has been documented for a long time in KB article 221833, but it is a bit harder to find information on GPSVC logging that is new to Vista/2008. This is mainly because the Group Policy operational log has vastly improved the ability to troubleshoot Group Policy issues without needing to view additional debug logging. But if you are curious, you can enable GPSVC logging via the registry.

Value Path: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics
Value Name: GPSvcDebugLevel
Value Type: REG_DWORD
Value Data: 30002 (hex)

Output: %windir%\debug\usermode\gpsvc.log

In this situation, both the Userenv.log and Gpsvc.log will show us the same information with regards to the values that are configured in the Site to Zone Assignment List policy. Just do a search on the text string ListBox_Support_ZoneMapKey. Here you can see that even though the 192.168.* value is invalid; it gets set in the registry successfully.

GPSVC(444.91c) 17:03:40:02 SetRegistryValue: ListBox_Support_ZoneMapKey => 1 [OK]
GPSVC(444.91c) 17:03:40:02 SetRegistryValue: 192.168.* => 1 [OK]

The value is written to the following registry location:

HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey

The registry.pol file in the GPO in Sysvol is the last place you could see those values. You can use Regview.exe to view the contents of a registry.pol file. It is a free download as part of the 2003 Resource Kit Tools, but it is also included by default now in Vista and 2008.

C:\>regview C:\WINDOWS\SYSVOL\domain\Policies\{144AF1E5-05FE-4C6D-8CB6-CBB945F23C85}\User\registry.pol

KeyName: Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings
ValueName: ListBox_Support_ZoneMapKey
ValueType: REG_DWORD
Value: 0x00000001

KeyName: Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey
ValueName: 192.168.*
ValueType: REG_SZ
Value: 1

- Craig Landis