Blog - Title

August, 2008

  • Event Logging policy settings in Windows Server 2008 and Vista

     Mike here again. Today I’m focusing on policy settings for the Event Logging Service.

    For clarity, these settings control the Event Logging service; the service responsible for capturing and writing events throughout Windows. These policy settings do not affect the Event Viewer application.

    These are some powerful policy settings that allow you to configure five settings for Application, Security, Setup, and System event logs. These categories and their policy settings are located under Computer Configuration\Policies\Administrative Templates\Windows Components\Event Log Service.

    The Log File Path policy setting, when enabled, allows you to provide a specific location where the Event Log service writes its log file. You must provided path and filename when relocating where Windows writes the log file.

    Next is the Maximum Log file size policy. When enabled, this policy allows you to specify the maximum size of the event log. It supports sizes between one megabyte and two terabytes and uses one-kilobyte increments.


    Figure 1 Event Log Service Policy Settings

    The next two policy settings are related. The Event Logging service uses the Retain old events and Backup log automatically when full policy settings when the event log reaches the maximum file size (defaults to 20 MB or the value specified in the Maximum Log size policy setting). With the Retain Old Events policy setting enabled, the Event Logging service stops writing new events to the event log when the log file reaches or exceeds the maximum value and you lose all new events. With this policy setting disabled, new events overwrite old events. When you enabling the Backup log automatically when full and the Retain old events policy settings, the Event Log service closes the current event log, renames it, and then creates a new log. The Backup log automatically when full policy setting works only when you enable Retain old events policy setting.


    Figure 2 Maximum Log Size Policy Setting

    The last setting and one that I think is the most beneficial is the Log Access setting. Enabling this setting allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log. You enter the security descriptor using Security Definition Description Language (SDDL), which is document on MSDN( Also, my esteemed colleague Jim provides a two-part blog series about SDDL ( and

    Finally, I should mention that these new policy settings have precedence over the older Windows Server 2003 and Windows XP security policy setting that manage Event Logs. Both settings can exist in the same Group Policy object and apply only to the respective operating systems for the policy setting.


    These new policy settings for the Event Logging service provide more flexibility and control from earlier versions. Using Group Policy to control where event logs are written, how large they can grow, how they are preserved, and who can manage them are key to change control and security auditing. You can implement these policy settings in your existing Group Policy objects and they will not affect operating systems earlier than Windows Vista.

    - Mike Stephens

  • 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
    Computer: M1
    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
    User: SYSTEM
    Completed Internet Explorer Zonemapping Extension Processing in 31 milliseconds.
    Event Xml:
    <Event xmlns="">
    <Provider Name="Microsoft-Windows-GroupPolicy"
    Guid="{aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}" />
    <TimeCreated SystemTime="2008-07-29T15:39:53.866Z" />
    <Correlation ActivityID="{917B65C2-7289-4E9C-8CE0-2364319F6D66}" />
    <Execution ProcessID="1092" ThreadID="2332" />
    <Security UserID="S-1-5-18" />
    <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>

    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
    # 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:


    Examples of valid values:

    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

  • Removable Storage, Group Policy and Windows Server 2008 and Windows Vista

    “I don’t want my users copying data to removable drives. How can I prevent this?”

    Mike here again to answer this common question asked to our team. Removable drives are widespread. Current mobile devices can now store up to 8 GB of data on a micro-SD card, which is no bigger than your thumb nail. Eight gigabytes is a huge amount of data and it could be your company’s Intellectual Property (IP) going out the door. There is a need to protect your company’s sensitive information from being transferred to removable storage devices; Group Policy in Windows Server 2008 and Windows Vista can help you.

    You can control access to six removable storage categories (actually seven but the seventh category controls access to ALL removable storage devices). These categories include CD and DVD, Floppy Drives, Removable Disks, Tape Drives, and WPD devices.


    Figure 1 Removable Storage Policy Settings

    Today’s computers usually do not included a floppy drives because the amount of data that fits on a floppy disk seems trivial in the age of one terabyte drives—regardless, you can restrict access to floppy drives, which includes USB floppy drives. Removable drives included classic USB thumb drives. WPD devices include media players, cell phones, CE devices, and some auxiliary displays. There is a custom category that allows you to identify the unique identifier of a device and control access of that device based on the unique ID.

    Each device category provides two types of access control—deny read and deny write. These policy settings apply to Windows Vista or later (to included Windows Server 2008) and can co-exist in GPOs applying to clients earlier than Windows Vista; however these older operating systems ignore the policy settings.

    You can find these policies under the Removable Storage Access category, under User or Computer Configuration\Policies\System\Removable Storage Access

    These policy settings change the security descriptor on the removable objects. Changing the security descriptor requires a computer reboot. Window's does not reboot the computer when the policy changes these security descriptors. However, Removable Storage provides a policy setting to which you can enable to force a reboot. Enable the Time (in seconds) to force reboot policy setting and provided value (in seconds) for which Windows waits before rebooting the computer to apply the new security descriptors for removal drives.


    Figure 2 Removable Storage Reboot Policy

    So, keep your Intellectual Property secure by controlling access to removable storage devices. Delegate write permissions to a limited user set, or limit removable storage write access to a single workstation. You can do your part to keep your company's sensitive data where it belongs.

    - Mike Stephens

  • What is the purpose of the 'Deleted' folder in DFSR?

    Hi, Ned again – and surprisingly, talking about DFSR!

    From time to time a customer will ask us about the Deleted folder in a Distributed File System Replication (DFSR) content set. It never seems to have anything in it. Not to mention we have a folder called ConflictAndDeleted and there definitely are deleted files in there.


    So what gives?

    The Deleted folder only comes into regular use when the option 'Move deleted files to Conflict and Deleted folder' is unchecked under Advanced for a given replicated folder membership in DFSMGMT.MSC, like below:


    When this is unchecked, a deleted file is no longer copied into ConflictAndDeleted, nor is the ConflictAndDeletedmanifest.xml file updated. Instead, the file on a downstream partner is temporarily moved into the Deleted folder while the DFSR database and USN are updated, then deleted directly from that folder.

    Unless that checkbox was turned off and a massive quantity of deletes was processed, it's unlikely you will ever see files in that folder for more than a moment. But we do have a way to see things happening on the file system faster than a speeding bullet – Process Monitor.

    If we run Process monitor on a downstream server and configure our filter to ‘path -> begins with -> the replicated folder’ we can see what goes on under the hood with minimal chaff.


    Then we can just delete a file on an upstream server. Here’s what happens when I delete ‘Readme.doc’ on the upstream server and the deletion request reaches my downstream partner:


    That’s kinda chaffy to read, so let’s cut to the important parts:

    1. The file e:\datarf\readme.doc is moved to e:\datarf\dfsrprivate\deleted\ReadMe.doc-{AC759213-00AF-4578-9C6E-EA0764FDC9AC}-v141560

    Perfmon Log entry:

    "2:57:15.5042328 PM","Dfsr.exe","2260","SetRenameInformationFile","E:\DataRF\ReadMe.doc", "SUCCESS","ReplaceIfExists: True, FileName: E:\DataRF\DfsrPrivate\Deleted\ReadMe.doc-{AC759213-00AF-4578-9C6E-EA0764FDC9AC}-v141560"

    (Do you remember from previous blog posts what the long GUID refers to? It’s the server that originated the deletion. The file is being mangled here with GUID and version because this is what would have been written into ConflictAndDeleted to maintain uniqueness.)

    2. Then the file is deleted

    Perfmon Log entry:

    "2:57:15.5056190 PM","Dfsr.exe","2260","SetDispositionInformationFile", "E:\DataRF\DfsrPrivate\Deleted\ReadMe.doc-{AC759213-00AF-4578-9C6E-EA0764FDC9AC}-v141560","SUCCESS","Delete: True"

    In case you’re curious, the Deleted folder cannot be… deleted. If you do so, the DFSR service will simply add it back in the next it’s restarted.

    So we covered a bit of DFSR and a bit of Process Monitor. I hope you found this interesting. Perhaps in the comments section someone wants to take a guess at what the Installing folder is for?

    - Ned Pyle

  • Saving money and power with Group Policy

    Ned here again. A few months ago Mark Aggar, Pat Stemen, and Michael Walsh wrote an excellent TechNet Magazine article on using group policy to save power. This article gives specific examples as well as fully documents all 35 power management settings covered in Vista. I wanted to make sure our ASKDS readers hadn't missed this:

    Sustainable Computing Conserving Energy with Group Policy

    There are also links to some excellent additional resources included that cover energy efficiency improvements in Vista; make sure to follow them once you finish reading. For example, from the Windows Vista Energy Conservation 'Financial Impact' section, if we calculate (at July 2006 US average energy cost of $0.0931USD per kWh) power savings for just enforcing Sleep settings on PC's:

    Annual Per-PC Power Cost Savings Using Sleep (Typical Pentium 4 PC with 17-inch CRT)
    760.14 kWh x $0.0931 = $70.77

    Annual Per-PC Power Cost Savings Using Sleep (Typical Pentium 4 PC with 17-inch LCD)
    597.52 kWh x $0.0931 = $55.63

    If you had only 1000 PC's you'd be saving $70,700USD annually. Not to mention that energy costs have climbed significantly since this whitepaper was created (in fact Electric Power Monthly currently puts them at $0.1044USD year to date 2008). The power draw of more advanced chipsets is always on the increase, naturally.

    And not only is power conservation good for your hardware and your bottom line, but it helps your fellow citizens and your planet.

    - Ned Pyle

  • MCS Talks Infrastructure Architecture

    Ned here again. Adam Shepherd (one of our esteemed UK MS Consulting colleagues) wanted us to let everyone know that there is a new Directory Services Core Infrastructure presentation coming soon. You will need to register for this and it will be delivered August 21, 2008. It specifically goes into the new DS features offered in Win2008 and how they should make life better in your environment. This is technical, so bring your thinking caps. And no need for your checkbook, this is free.

    UK MCS blog (linked to post) 

    Direct registration on Technet for the event

    (And apologies for the short posting drought; there was a quantum vacation singularity - plenty more to come soon).

    - Ned Pyle

  • Network Properties in a hurry

    Hi. Jim from DS here again to show you how to quickly access the properties of your network interface cards via a custom desktop shortcut. In my previous blog post I put together a lovely “at a glance” reference to launching administrative and system tools from the command line and START – RUN. In Windows server 2008 and Windows Vista you might have noticed that it does require several extra mouse clicks to access the network properties dialog.

    I recently overheard a colleague of mine raise his voice in anger, and while simultaneously shaking his fist at the sky he cried out “Why must I click four thousand times to get to this interface!?” I realized that NCPA.CPL may not be as easy to remember for others as it is for me. This (coupled with my colleague’s meltdown) compelled me to compose a quick blog on making a custom shortcut to access the network properties window.

    On the desktop of your Windows Server 2008 or Windows Vista machine right click – NEWShortcut:


    image image

    Type the path to NCPA.CPL and click next.




    Type a name for the shortcut.


    Click Finish.

    You will now have a shortcut on the desktop which will take you directly to the network properties applet. Now you may change the icon which is currently the default for a .CPL file to an icon of your desiring.

    Right Click on the new shortcut and select Properties.


    Click on the Change Icon button.









    This desktop shortcut can be readily deployed via group policy preferences to whichever servers or workstations you like. Please see the following blog post in regard to Group Policy Preferences -

    The shortcuts can be created for any administrative interface you or your IT department access frequently.

    - Jim Tierney