Category Archives: Uncategorized

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
The event logging service encountered an error when attempting to apply one or more policy settings.
Event Xml:
<Event xmlns="">
    <Provider Name="Microsoft-Windows-Eventlog" Guid="{FC65DDD8-D6EF-4962-83D5-6E5CFE9CE148}" />
    <TimeCreated SystemTime="2016-02-18T17:44:46.789855700Z" />
    <Correlation />
    <Execution ProcessID="1140" ThreadID="5600" />
    <Security UserID="S-1-5-19" />
    <ChannelPolicyApplicationError xmlns="">
      <Error Code="5">

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.

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).

After the eBay database breach, all users are being asked to change their passwords. However, many people are rightfully complaining that the password reset form prevents them from pasting into the form fields, which makes it difficult to use long, complex passwords. Although, there has also been much criticism of eBay’s password length and complexity requirements being too lax.

Ars Technica has a good article at After the breach: eBay’s flawed password reset leaves much to be desired describing the various flaws.

In changing my own password, I was determined to use a complex password that was the maximum length (20-characters) and to ensure that the password was correctly recorded, I needed to be able to paste that password into the form fields.

Through some experimentation, I found that passwords can be pasted into the form after disabling JavaScript in your browser.

The instructions below are for Chrome on Windows, but this should be similarly possible in other browsers:

  1. Open the JavaScript Console (Ctrl+Shift+J), then click on the gear icon at the top-right to open the Settings dialog box.
  2. In the General area, check the box next to “Disable JavaScript”.
  3. You should now be able to paste into the password input fields (but be mindful of the 20-character limit).
  4. Clear the check from the box next to “Disable JavaScript” and close the Settings dialog box, then close the JavaScript Console.
  5. Submit the form.

If you happen to enter more than 20 characters, the form will be submitted successfully and your password will be successfully changed, but the password will be truncated to the first 20 characters.

For those of you who reluctantly used a less secure password due to the limitations of the form, hopefully this allows you to reset your password again and use a more satisfying password.