Unable to access local drive(s)


On a Windows 2008 or 2008 R2 server administrators are unable to browse the contents of local drives while logged on to the server either directly at the console or via remote desktop. Access to the same drive using a network share works fine. UAC is turned on, and the local administrators group have full control access to the drive(s) in question. You get an “Access denied” error in Windows Explorer even when running in an elevated process (administrator mode).

The problem also affects Windows Vista and 7.


If you try to access the drive using a program other than Windows Explorer, you can access the drive as long as the program is running in an elevated session. The problem seems to affect Windows Explorer alone, but I am not sure about that. What I have been able to establish though, is that it only affects users who are members of the local “Administrators” group. If a user has explicit access or access through another group, everything works as expected.

I detected the problem while migrating files and permissions from an old 2003 server to a new one running 2008 R2, and I think it is related to the local “Users” group not being granted access to the drive. Not denied, just removed from the root acl on the drive.


  • Add explicit access to the drive for the administrative users that need access
  • Turn off UAC (not recommended)
  • Create a new group called Local_Admin_Access or something like that, add the local administrators group as a member, and give the new group full control of the drive.
  • Give the local group “Interactive” full control of the drive. This grants access to any user who have local logon permissions and are currently logged on to the server.

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 “authrootstl.cab” 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.

    Korrigere windowsupdate


    Innimellom når man installerer en ny w2k8 server blir det en konflikt i Windows update etter at man har kjørt den første gang. Lignende feil kan også oppstå senere.


    Feilen gjenkjennes ved å se etter følgende:
    • Eventid 4385 fra Servicing i systemloggen:

    • Ikke mulig å kjøre windows update, for eksempel alle updates feiler.
    • maskinen kommer med en popup ved pålogging som sier ”Unable to download updates from windowsupdate” eller noe i den dur.
    • Hver gang du logger på får du beskjed om at du må restarte for å aktivere oppdateringer, selv om du nettopp har restartet.
    • Maskinen går i en boot loop, der den bare kommer til ”Applying updates, stage x av 3” (Se fix 2 for denne)


    For å korrigere dette kjøres Microsoft Fixit nr 50202 (ligger på http://support.microsoft.com/kb/971058 ). Pass på å hake av aggressive options når den starter opp. Samme fix kan brukes på klienter om nødvendig, og den løser de fleste windows update relaterte problemer. Fixen krever omstart av maskinen.
    Sjekk at ting virker ved å kjøre manuell windows update etterpå.


    Dersom man ikke korrigerer problemet og fortsetter å installere programmer, kan man ende opp med en maskin som nekter å starte. Den booter til ”Windows is applying updates, stage x of 3”, står der en stund, og så restarter maskinen. Den går altså i en loop.
    For å korrigere denne feilen må man boote fra installasjonsmedia, velge Repair my computer, åpne ett konsollvindu og endre navn på filen [Drive]:\windows\winsxs\pending.xml. (Drive varierer, men er ofte D)
    Etter omstart får man boote igjen, men windows update er pooched. Utfør fix1 for å korrigere.