Windows Home Server 2011 Backup of UEFI/GPT Windows 8.1

Since upgrading to Windows 8.1 at home, I’ve had issues with backing up the computer using my Home Server (not that I helped by introducing a GPT disk and a UEFI rig at the same time…). The symptoms were that the client backup process appeared stuck at 1% progress for a long time before eventually failing.

I finally got a bit of time to look at the machines in question over the weekend and here are the issues that appeared to be causing problems for which I needed to find solutions:

  • The PC is a UEFI machine.
  • The PC uses a GPT hard disk.
  • A VSS error was appearing in the event log on the PC being backed up.
  • A CAPI2 error was appearing in the event log on the PC being backed up.

The first two issues were dealt with quickly by a hotfix for Home Server 2011: http://support.microsoft.com/kb/2781272. Note that the same issue also affects Windows Storage Server 2008 R2 Essentials and Windows Small Business Server 2011 Essentials. More information for these platforms can be found at http://support.microsoft.com/kb/2781278

The VSS error manifests as the event 8194 appearing in the event log of the PC that the backup attempt is run on:

VSS Error 8194

Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback interface. hr = 0x80070005, Access is denied.
. This is often caused by incorrect security settings in either the writer or requestor process.

Examination of the binary data for event 8194 indicates that ‘NT AUTHORITY\NETWORK SERVICE’ is account receiving the access denied error:

VSS Error Binary Data

Event 8194 is caused by the inability of one or more VSS system writers to communicate with the backup application VSS requesting process via the COM calls exposed in the IVssWriterCallback interface. The issue is not caused by a functional error in the backup application, but rather is a security issue caused by the selected VSS writers running as a service under the ‘Network Service’ (or ‘Local Service’) account, not the Local System or Administrator account. By default, in order for a Windows service to perform a COM activation it must be running as Local System or as a member of the Administrators group.

There are two ways to fix this issue; either change the account under which the erroring VSS writers are running from Network Service to Local System (at which point the service will be running with higher privileges than was originally designed), or add the Network Service account to the list of default COM activation permissions allowing this user account to activate the IVssWrtierCallback interface. This latter option is the preferred one to use and can be performed by completing the following steps:

  1. Run dcomcnfg to open the Component Services dialog.
  2. Expand Component Services, then Computers and then right-click on My Computer and select Properties:
    Component Services
  3. Select the COM Security tab and click the Edit Default… button in the Access Permissions area at the top of the dialog.
  4. Click Add and enter Network Service as the account to be added.
  5. Click OK and ensure that only the Local Access checkbox is selected.
  6. Click OK to close the Access Permission dialog, then clock OK to close the My Computer Properties dialog.
  7. Close the Component Services Dialog and restart the computer to apply the changes. Event 8194 should not longer appear in the event log for the Home Server backup.

The CAPI2 error manifests as the event 513 appearing in the event log of the PC that the backup attempt is run on:

CAPI2 Error 513

Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.
Details: AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer Discovery Protocol.
System Error:
Access is denied.
.

The Microsoft Link-Layer Discovery Protocol binary is located at C:\Windows\System32\drivers\mslldp.sys. During the backup process, the VSS process running under the Network Service account calls cryptcatsvc!CSystemWriter::AddLegacyDriverFiles(), which enumerates all the driver records in Service Control Manager database and tries opening each one of them. The function fails on the MSLLDP record with an ‘Access Denied’ error.

The mslldp.sys configuration registry key is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsLldp and the binary security descriptor for the record is located at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsLldp\Security.

Examining the security descriptor for mslldp using AccessChk (part of the SysInternals suite, available at http://technet.microsoft.com/en-us/sysinternals/bb664922) gives the following result (note: your security descriptor may differ from the permissions below):

C:\>accesschk.exe -c mslldp

Accesschk v5.2 – Reports effective permissions for securable objects
Copyright (C) 2006-2014 Mark Russinovich
Sysinternals – www.sysinternals.com

mslldp
  RW NT AUTHORITY\SYSTEM
  RW BUILTIN\Administrators
  RW S-1-5-32-549
  R  NT SERVICE\NlaSvc

Checking the access rights of another driver in the same location gives the following result:

C:\>accesschk.exe -c mspclock

Accesschk v5.2 – Reports effective permissions for securable objects
Copyright (C) 2006-2014 Mark Russinovich
Sysinternals – www.sysinternals.com

mspclock
  RW NT AUTHORITY\SYSTEM
  RW BUILTIN\Administrators
  R  NT AUTHORITY\INTERACTIVE
  R  NT AUTHORITY\SERVICE

In the case of mslldp.sys, there is no entry for ‘NT AUTHORITY\SERVICE’, therefore no service account will have access to the mslldp driver, hence the error.

To correct this issue, complete the following steps:

  1. From an elevated command prompt, run
    sc sdshow mslldp
    You should receive the following output, or something similar:
    D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
    Note: Details on Security Descriptor Definition Language can be found at http://msdn.microsoft.com/en-us/library/windows/desktop/aa379567(v=vs.85).aspx
  2. Add the ‘NT AUTHORITY\SERVICE’ entry immediately before the S::(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD) entry and use this with the sdset option, for example using the output from the sdshow option above, this would be:
    sc sdset MSLLDP D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SO)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
    Note: The above should all be on a single line when entering/pasting it; do not include line breaks in the command. It’s also important to use the output you receive from the command rather than that which I got as yours may be different.
  3. Check the access permissions again with:
    accesschk.exe -c mslldp
    You should now see a list of permissions that includes ‘NT AUTHORITY\SERVICE’:
    C:\>accesschk.exe -c mslldp
  4. Accesschk v5.2 – Reports effective permissions for securable objects
    Copyright (C) 2006-2014 Mark Russinovich
    Sysinternals – www.sysinternals.com

    mslldp
      RW NT AUTHORITY\SYSTEM
      RW BUILTIN\Administrators
      RW S-1-5-32-549
      R  NT SERVICE\NlaSvc
      R  NT AUTHORITY\SERVICE

  5. Now that the ‘NT AUTHORIT\SERVICE’ permission has been added, Network Service should be able to access the mslldp.sys driver file.

Following the above fixes, my computer is now being successfully backed up using Home Server 2011.

CRM 2011 Update Rollup 6 (and beyond) timeout

On an instance of CRM 2011 that was being patched to Update Rollup 6 prior to patching to Update Rollup 8, the following error occurred:

System.Exception: Action Microsoft.Crm.Setup.Common.Update.DBUpdateAction failed. —> System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

The error was displayed as both a dialog on screen, and within the log file, KB2600640.log located at %APPDATA%\Microsoft\MSCRM\Logs

The solution was to raise the timeout that CRM applied for OLEDB connections from the original 30 seconds by creating two new registry keys at HKLM\SOFTWARE\Microsoft\MSCRM:

OLEDBTimeout (DWORD), value 86400 (decimal)
ExtendedTimeout (DWORD), value 1000000 (decimal)

Then restart the CRM application pool within IIS.

Once the new settings were in place, the upgrade proceeded normally.

Changing CRM 2011 URL after installation

Modifying the URL used for CRM 2011 after installation can be achieved using the following steps:

  • Update the IIS bindings for the CRM 2011 website on the server running CRM to the new value you want to use
    • Open IIS Manager
    • Select the Microsoft Dynamics CRM website
    • Click ‘Bindings’ in the action panel at the right of the screen
    • Select the binding to modify
    • Click ‘Edit’ and modify the host name and port to the new value.
    • Close the dialog and IIS Manager.
  • Update the ServerURL registry entry with the new URL you want to use. The registry entry can be found at KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM. Note that the key value should be of the form http(s)://<New URL>:<Port Number>/MSCRMServices
  • Modify the global settings for CRM from within the Microsoft Dynamics CRM Deployment Manager*:
    • Start the Microsoft Dynamics CRM Deployment Manager
    • Right-click on the ‘Microsoft Dynamics CRM’ entry at the top of the left pane of the window shown
    • Click ‘Properties’
    • Select the ‘Web Address’ tab on the dialog which is shown
    • Modify the addresses shown appropriately. Note that if the binding type is modified from HTTP to HTTPS you will need to install the appropriate certificate into IIS as well.
    • Click OK to close the dialog and close Microsoft Dynamics CRM Deployment Manager
  • Restart the Microsoft Dynamics CRM Asynchronous Processing Service, or restart the server

* Note: This step replaces the use of the Microsoft CRM Deployment Configuration Tool used to make these changes for CRM 4.0.

System Center Operations Manager Database Location

System Center Operations Manager doesn’t seem to provide an easy way (correct me if I’m wrong here) to find out what database server and database name it is using. Should you ever need to find out, log onto your Management Server, start regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup and examine the DatabaseServerName and DatabaseName entries.