Annoying default settings

I have never quite liked the way Microsoft wants me to use Windows Explorer. The standard settings are quite annoying to me, but I understand why they are as they are on end user versions of Windows. Joe User is stupid, usually more so than you might imagine possible, so it is important to protect him against himself. On a server on the other hand, I would think we should anticipate some minimal knowledge about the file system. A server user should be able to look at a system file without thinking: “Hmm, bootmgr is a file I haven’t seen before. I should probably delete it. And that big windows folder just contains a lot of strange files I never use. I’m deleting some of those too, it will leave more room for pictures of my cat!”. But no, it has the same stupid defaults as the home editions. Because of this, I have had to create a list of all the stuff I have to remember to change whenever I log on to a new server, lest I go insane and maul the next poor user who want’s me to recover the database he “forgot” to back up before the disk crashed. Smilefjes som rekker tunge


Continue reading “Annoying default settings”

Windows VPN with local access


After having to look this up for the n’th time, I decided to document it for my self. If you are using the built in VPN client in Windows to connect to a VPN gateway, for instance your own home firewall for remote access, you have probably noticed that your local internet connection may stop working while you are connected to the VPN. All traffic is tunneled to the remote VPN gateway, which can have a detrimental effect on your internet connection throughput. And if like me, you haven’t bothered to set up the firewall/vpn gateway to allow this in the first place, all local applications will loose internet connectivity while you are connected to the VPN.


To work around this, you have to allow local network access in the VPN connection settings. Microsoft has chosen to call this setting “Use default gateway on remote network”. You will find a similar setting in most VPN clients, but they are usually labeled something like “Allow local access”. anyway, in Windows 7 you will find this setting under Networking, IPv4, Properties, Advanced:


The same setting is available for IPv6

WebDAV max file size and basic authentication

Enable basic Authentication

You may be unable to connect to a WebDAV share because of security constraints. More specifically, unable to use basic authentication to non-ssl shares. This is a very bad thing to do, as it implies sending the password in plain text over the network. Ergo it is disabled by default, but if you absolutely have to use it, this is how you enable it:

Change the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel to 2.

The possible options are:

  • 0 – Basic authentication disabled
  • 1 – Basic authentication enabled for SSL shares only
  • 2 or greater – Basic authentication enabled for SSL shares and for non-SSL shares

Se for details.

Change max file size

You may get the following error when downloading or uploading a large file from a WebDAV share: Error 0x800700DF The file size exceeds the limit allowed and cannot be saved.


The default limit on Windows 7 is 50.000.000 bytes, or 47,68MiB if you will. That’s not very much if you are trying to download a 3GiB iso file or something like that. As the error message hints at, this is a configurable limit. It is defined in the following registry value:


Change it to a value suiting your needs. The maximum value is 4095MiB, or 0xFFFFFFFF.

You should also increase the  FileAttributesLimitInBytes setting a bit. This setting determines how big a directory listing is allowed to be in bytes, which translates to how many files and subfolders you are able to list on screen. If you have directories containing more than 1000 sub-items, the view could be truncated. I have added an extra 0 to the default value.


Event ID 1006 from GroupPolicy


Event 1006 is logged several times each day in the system event log with the message The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description. The details pane lists Invalid Credentials as the error description:



This error is most likely caused by a user session that is logged on to the machine with an expired domain password. The user name event property identifies the user in question. This situation typically arises when users stay logged on to a computer or server for several weeks at the time, long enough for a domain password expiry policy to force a password change. The user is prompted to change the password at the next login, but if the user never logs out, the session keeps running with the old credentials. The same error will occur if the users session is a disconnected or active remote desktop session.


Log out and log back in to trigger the password change dialog. If the password has already been changed on another computer or directly in the directory, just log back in with your new password.

If your own session isn’t the culprit, you can forcibly log out another user using Remote Desktop Services Manager (server only) or Task Manager. Be aware of the fact that this method will exit all programs without saving in the session you log off.

Failed extract of third-party root list from auto update cab


This is an annoying message that shows up in the Event Log on Windows servers and computers and won’t go away. The error was initially caused by a certificate update published by Microsoft at the end of 2010 containing expired root certificates. The error has continued to surface on systems though, so I am starting to wonder if it has more than one cause. One theory is that this happens when an administrator is logged or has an active but disconnected session on the computer while another administrator or some form of automation tries to install updates from Windows Update.

Symptoms and findings

The error is detected in the Application Event Log. On Windows server 2008 it looks like this:


Event 11 from Microsoft-Windows-CAPI2

Or like this:


Event 4017 from CAPI2

On Windows Server 2003:


Event 11 from crypt32


Microsoft has released a fixit that has solved this problem for me on most of the servers I have applied it to: Fix it 50531. See KB 2328240 for details and a manual method. This fixit only works on Windows 2008/7 though, but the manual method should work for older versions as well, provided you substitute “Documents and settings” were it says “Users” in the KB.

The solution is to delete the files in the folders referenced in the KB. You have to check all users and system accounts, unless you know which user ran windows update when the problem first appeared on your system.

Service account profile folder locations:

  • %windir%\ServiceProfiles\[Service Account]\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content
  • %windir%\ServiceProfiles\[Service Account]\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData

User account profile folder locations:

    • C:\Users\[Account]\AppData\LocalLow\Microsoft\CryptnetUrlCache\Content
    • C:\Users\[Account]\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData


    After deleting the files, check back a couple of hours and see if the error resurfaces. If you want to test it immediately, download the “” file from the link in the event and try to install it.

    Update: 20121018

    A colleague of mine has written a small powershell script that seems to do the trick on Win2008R2 servers:

    get-childitem -path 'c:\users' | where-object { $_.psiscontainer -eq $true } | foreach-object {
        $contentfolder  = join-path -path $_.fullname -childpath 'appdata\locallow\microsoft\cryptneturlcache\content\'
        $metadatafolder = join-path -path $_.fullname -childpath 'appdata\locallow\microsoft\cryptneturlcache\metadata'
        if (test-path -path $contentfolder ) { remove-item -path "$contentfolder\*"  -force -verbose }
        if (test-path -path $metadatafolder) { remove-item -path "$metadatafolder\*" -force -verbose }

    This is quicker to implement than the “Fix it” or manual approach, and all our attempts have been successful so far.