Andy Dawson's Blog

The blog of Andy dawson

SPWakeUp for SharePoint 2016

If you use SharePoint, you’ll know that some mechanism to wake up the hosted sites after the application pools are recycled overnight is very helpful (essential even) for the end user experience.

I’ve compiled a version of SPWakeUp for SharePoint 2016, which can be downloaded from

If you want to compile this for yourself, this is the method I followed to get the above version:

  1. Grab a copy of the source code for SPWakeUp from and unpack it.
  2. Open the solution in Visual Studio (I used Visual Studio 2015) and allow the automatic upgrade.
  3. Replace the reference to the Microsoft.SharePoint.dll in the solution with one pointing to the SharePoint 2016 version. You’ll want to grab a copy from C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\ISAPI on a SharePoint 2016 server.
  4. Modify the target framework for the application. I used 4.6.1 for the build above.
  5. Build either the debug or release version.

Steps Required to Configure WSUS to Distribute Windows 10 Version 1511 Upgrade

Microsoft recently made a hotfix available that patches WSUS on Windows Server 2012 and 2012 R2 to allow Windows 10 upgrade to version 1511. Installing the update is not, however, the only step that is required…

  1. Install the hotfix. This can be downloaded from Ensure that you pick the appropriate hotfix for the version of Windows Server on which you’re running WSUS. Note that if you’re running Windows Server 2012 R2, there’s also a pre-requisite install.
  2. Once the hotfix is installed and you’ve restarted your WSUS server, look in the ‘Products and Classifications’ option under the Classifications tab and ensure that the checkbox for upgrades is selected. This is not selected automatically for you:
    Upgrades Option
    Note that the upgrade files may take quite some time to download to your WSUS server at the next synchronisation.
  3. Add a MIME-Type for ‘.esd application/octet-stream’ in IIS on the WSUS server. To do this:
    Open IIS Manager
    Select the server name
    From the ‘IIS’ area in the centre of IIS Manager, open ‘MIME Types’
    Click ‘Add…’
    Enter the information above:
    Esd MIME Type
    Click OK to close the dialog.
    Note: Without this step, clients will fail to download the upgrade with the following error:
    Installation Failure: Windows failed to install the following update with error 0x8024200D: Upgrade to Windows 10 [SKU], version 1511, 10586.
  4. Approve the Upgrade for the classes of computer in your organisation that you want to be upgraded.

Once all of the above steps are in place, computers that are targeted for the upgrade should have this happen automatically at the next update cycle.

Exchange 2013 Cert Change - Unable to Support the STARTTLS SMTP Verb

I saw a issue recently on an Exchange server after the certificate used to secure SMTP and IIS services was changed as the old certificate was about to expire.

The original default certificate that is self-generated had been replaced with one from a certificate authority. This had been used for several years without issue. The Exchange server is configured in hybrid mode, with incoming e-mail routed through Microsoft’s Exchange Online Protection (EOP) and TLS is configured to be required.

The actions taken were:

  1. Add the new certificate to the certificate store on the Exchange server. This made the new certificate available within the Exchange Admin Center on the server.
  2. Modify the services assigned to the new certificate to bind SMTP and IIS to the new certificate.
  3. Remove the original certificate from the server.
  4. Restart the Microsoft Exchange Transport Service on the server.

At this point, an error was thrown in the Application Event Log on the server and incoming mail from Exchange Online Protection stopped flowing. The error thrown was:

Log Name:      Application
Source:        MSExchangeFrontEndTransport
Date:          04/02/2016 12:17:20
Event ID:      12014
Task Category: TransportService
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      <Exchange Server FQDN>
Microsoft Exchange could not find a certificate that contains the domain name <I><Cert Issuer Details><S><Cert Subject Details> in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector <Receive Connector Name> with a FQDN parameter of <I><Cert Issuer Details><S><Cert Subject Details>. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

I ran the suggested command to ensure that the Exchange Transport Service had access to the certificate key, but this didn’t help.

Restoring the soon-to-expire certificate to the certificate store on the server and restarting the Microsoft Exchange Transport Service fixed the error, however the certificate in question was going to expire soon, and the use of expired certificates for TLS to EOP is no longer allowed, so this didn’t really help much.

While digging into the configuration for the receive connector specified in the error thrown, I noticed something interesting. Despite the new certificate being supplied by the same certificate authority as the old one, the issuer specified for the certificate had changed slightly. The subject information was still the same. Sure enough, the properties of the receive connector in question still showed the old certificate details even through Exchange had been configured with the new certificate for SMTP and IIS. The information on the receive connector can be found by issuing the following command:

Get-ReceiveConnector "<Receive Connector Name>" | fl

The property we’re interested in is TlsCertificateName.

To correct the error, the following steps were taken:

  1. Locate the issuer and subject information from the new certificate. This can be done by examining the certificate directly via the certificate store, or using PowerShell, e.g.
    $certs = Get-ExchangeCertificate
    Locate the certificate you want to use. The one we wanted was the first on the list.
  2. Assemble the new issuer and subject information in a suitable format for the Receive Connector configuration. Again this can be done by copying the required text from the certificate information, or using PowerShell, e.g.:
    $certinfo = “<I>” + $certs[0].issuer + “<S>” + $certs[0].subject
  3. Modify the Receive Connector configuration to include the new certificate information assembled above, e.g.:
    Set-ReceiveConnector “<Receive Connector Name>” –TlsCertificateName $certinfo
  4. Restart the Microsoft Exchange Transport Service.
  5. Remove the old certificate from the server.

A quick test of incoming and outgoing mail indicated that everything was flowing as expected.

Deploying FileZilla with Configuration Manager 2012 R2

Some time ago I created an System Center Configuration Manager (SCCM) application to deploy FileZilla for users. Recently I created an updated application that upgraded FileZilla (using the usual ‘uninstall the old version, then install the new version’ method), which gave me an error when the application was upgraded:

Application Upgrade Filaed

Unable to make changes to your software

with the reported error being ‘The software change returned error code 0x87D00325 (-2016410843).

In addition, attempting to uninstall the application using the SCCM Software Center on the client machine gave a ‘Removal Failed’ with the same error details:

FileZilla Removal Failed

Digging through the AppEnforce log file on the client, an error was reported when attempting to uninstall the application as part of the change:

Prepared command line: "C:\Program Files (x86)\FileZilla FTP Client\uninstall.exe" /S
Post install behavior is BasedOnExitCode
Waiting for process 1616 to finish.  Timeout = 120 minutes.
Process 1616 terminated with exitcode: 0
Looking for exit code 0 in exit codes table...
Matched exit code 0 to a Success entry in exit codes table.
Performing detection of app deployment type FileZilla 3.13.0 x86
Discovered application
App enforcement completed (0 seconds) for App DT "FileZilla 3.13.0 x86"

This indicates that the uninstall process completed, but the application was detected as still being installed immediately afterwards. This is due to the way that uninstallation is performed, with the uninstall process triggered by SCCM spawning another process to actually perform the uninstallation, while the original process terminates. This means that the process that SCCM is waiting on to complete, does so almost immediately, while the actual work to perform the uninstallation is on-going, hence the reason that SCCM then detects the application as still present on the client system.

To get around the issue, we need to wait a period of time after the uninstallation is triggered to allow for completion before allowing SCCM to perform its detection. In order to do this, I’m using the ‘sleep.exe’ program that comes with the Windows 2003 Resource Kit Tools (available at to achieve this.

The items we’ll need to be copied to an appropriate location for deployment are:

  • The FileZilla installer
  • The sleep.exe program
  • A batch file to perform the uninstallation
  • An SCCM application that uses the batch file

The batch file should contain two lines:

"%ProgramFiles%\FileZilla FTP Client\uninstall.exe" /S
Sleep 20

This runs the uninstaller as before, then pauses for 20 seconds to allow the system to catch up. 20 seconds is long enough for our client machines, YMMV.

The SCCM application should then be created as normal:

Manually specify the application information:

Manually specify the application information

Provide a name for the application and optionally a publisher, version etc.:

Provide a name for the application and optionally a publisher, version etc.

Provide appropriate information for the Application Catalog:

Provide appropriate information for the Application Catalog

Click ‘Add…’ to add a Deployment Type to the application:

Click ‘Add…’ to add a Deployment Type to the application

Select ‘Manually specify the deployment type information’:

Select ‘Manually specify the deployment type information’

Provide a deployment type name and optionally administrator comments:

Provide a deployment type name and optionally administrator comments

For the content page of the wizard, specify the content location, for the installation program, specify ‘FileZilla_X.XX.X_win32-setup.exe /S’ and for the uninstall program, specify the batch file that was created previously:

For the content page of the wizard, specify the content location, installation program and uninsatll program

For the detection rules, we used the file version of the ‘filezilla.exe’ program file that gets installed, which seemed to work well:

For the detection rules, use the version of the 'filezilla.exe' file

In addition, if required, supersedence information can be added to the application.

The procedure above provided a robust SCCM application that can be installed and uninstalled without issue and can also be upgraded to a later version without issue. It should be noted that this method works for other applications with the same sort of uninstallation routine, e.g. Notepad++.

DPM 2012 R2 UR7 Known Issue

There’s a known issue with Update Rollup 7 for System Center Data Protection Manager 2012 R2 that stops expired recovery points being removed, thus leading (eventually) to DPM consuming all available disk space attached to it. This leads to messages such as:

DPM does not have sufficient storage space available...



Which mean that new recovery points are not being created and therefore changes are not being backed up.

The fix, which involves replacing the ‘pruneshadowcopiesDpm2010.ps1’ file with a corrected version, can be downloaded from

The procedure is:

  1. Ensure that you are running DPM 2012 R2 UR7 (version 4.2.1338.0) from the ‘About DPM’ menu item under the ‘Action’ menu.
  2. Download the revised pruneshadowcopiesDpm2010.ps1 file from the URL above.
  3. Copy the original file to another location (just in case!)
  4. Replace the original pruneshadowcopiesDpm2010.ps1 with the one downloaded from the URL above. On one of our servers (that was upgraded from 2012 to 2012 R2), this location was C:\Program Files\Microsoft System Center 2012\DPM\DPM\bin and on a new installation, this location was C:\Program Files\Microsoft System Center 2012 R2\DPM\DPM\bin.
  5. Allow the system to run the PowerShell script at midnight (the default time) and the old recovery points should be removed.
  6. You may need to shrink the disk space allocated to the recovery point if DPM has automatically grown the disk space allocated. To to this, for each protection group, right click the protection group and click ‘Modify disk allocation’. Against each entry for the protection group, click ‘shrink’. DPM will calculate the new volume size. Click OK to complete the process.

Note: Repeated small shrink operations cause free space fragmentation, so use with care.

Additional notes: UR7 was re-released to fix this issue, so if you updated your DPM system after August 25th, you should be okay. The original script looks like this:


The modified version looks like this:


Changing the Certificate on ADFS 3.0 and Web Application Proxy (WAP)

As with all systems using certificates for security, there comes a time when the certificate is expiring and needs to be replaced. here’s the procedure for ADFS 3.0 and WAP:

Starting with the ADFS server:

  1. Log onto the ADFS server.
  2. Add the new certificate to the server. Make sure this is added to the personal certificate store for the computer account. I usually do this using the certificates snap-in in MMC.
  3. Find the thumbprint for the new certificate. This can be found by looking at the details for the certificate; the thumbprint is usually at/near the bottom of the list of details for the certificate and consists of 40 hexadecimal characters. Take a copy of the thumbprint and ensure that the spaces are removed, so it’s a 40 character string; you’ll need this in a few moments.
  4. Grant the service account that is running the ‘Active Directory Federation Services’ service read access to the private key. To do this, follow these steps:
    1. Within the certificates snap-in of MMC, right click the certificate, select ‘All Tasks’ and then select ‘Manage Private Keys…’:
      Manage private keys
    2. Click ‘Add…’ to add the user account running the ADFS service on the server and grant read access to that user. Click OK on the permissions dialog to close it.
  5. Launch AD FS Management, expand ‘Service’ within the left pane and click ‘Certificates’:
    AF FS Manager Certificates
  6. Click ‘Set Service Communications Certificate…’ from the actions panel at the right of the screen:
    Set Services Communication Cert
  7. A dialog is shown presenting the available certificates on the server. Select the new certificate that is to be used. If you are unsure of the correct certificate, select each certificate in turn and click the ‘Click here to view certificate properties’ link which is shown and compare the thumbprint with that recorded earlier. Click OK on the dialog once the correct certificate is selected.
  8. If at this point you restart the server or ADFS service and make a connection to ADFS, you will still be presented with the original certificate. The change in the GUI changes the configuration in the ADFS configuration database, but not the certificate bound to HTTP.sys.
  9. To complete the configuration change, the following PowerShell command must be run:
    Set-AdfsSslCertificate –Thumbprint 00112233445566778899aabbccddeeff00112233
    Where 00112233445566778899aabbccddeeff00112233 should be replaced with the thumbprint you found earlier.
  10. Restart the server, or the ADFS service on the server to complete the configuration change.

Additional configuration is required on the WAP server:

  1. Log onto the WAP server.
  2. Add the new certificate to the server. Make sure this is added to the personal certificate store for the computer account.
  3. Run the following PowerShell command to change the certificate:
    Set-WebApplicationProxySslCedrtificate –Thumbprint 0011223344556677889900aabbccddeeff00112233
    Where 00112233445566778899aabbccddeeff00112233 should be replaced with the thumbprint you found earlier.
  4. All of the publishing rules need to be updated with the thumbprint of the new certificate (you created these originally using PowerShell, right?). This can be done by either deleting the old rules and recreating them with the new certificate thumbprint specified, or the rules can be updated with the new thumbprint, for example:
    Get-WebApplicationProxyApplication –Name “WebAppPublishingRuleName” | Set-WebApplicationProxyApplication –ExternalCertificateThumbprint “00112233445566778899aabbccddeeff00112233”
    Where (you guessed it!) 00112233445566778899aabbccddeeff00112233 should be replaced with the thumbprint you found earlier and ‘WebAppPublishingRuleName’ should be replaced with the name of the rule as it is shown in the Remote Access Console.
    I expected the federation publishing rule that was created automatically when WAP was originally configured to be updated for me, but had to manually switch the certificate on that one.
  5. Restart the server, or the ADFS and Web Application Proxy services to complete the configuration.
  6. Test that all of the previously published rules function correctly and provide the new certificate to the computer from which you are making a connection. If you need to check the certificate assigned to a specific publishing rule, the following PowerShell will show all of the properties for the publishing rule:
    Get-WebApplicationProxyApplication –Name “WebAppPublishingRuleName” | fl
    Note that the other parameters shown in the list generated by the above can also be changed (with a few exceptions) using the Set-WebApplicationProxyApplication cmdlet.

DPM 2012 R2 SQL Backups Failing After November 2014 OS Updates

Following the installation of the November 2014 OS updates and the updated DPM agent (to update rollup 4) onto a number of servers, I saw failures when attempting to perform a backup of SQL Server 2012 databases hosted on Windows Server 2012. These manifested as ‘replica is inconsistent’ in the DPM console:

DB Replica Inconsistent

On the affected SQL Server, the following error was appearing in the server event log each time a consistency check was triggered:

Event 4354 - Failed to fire the RequestWriterInfo method

The COM+ Event System failed to fire the RequestWriterInfo method on event class {FAF53CC4-BD73-4E36-83F1-2B23F46E513E} for publisher  and subscriber . The display name of the subscription is "{E6057DCA-9DE3-42FC-9A6E-A057156277B4}". The HRESULT was 80042318.

I tried a number of things to resolve the issue:

  1. Modified the protection group. Initially, the protection group wizard did not show the ‘SQL Server’ option and I could not re-add the SQL Server databases. The agent required an update (again) and following this, I could then re-add the SQL Server databases, however when synchronised, the databases were still reporting ‘replica is inconsistent’.
  2. Removed the protection from the affected server, removed the DPM agent, rebooted, then reinstalled and attached the DPM agent and re-added the SQL Server databases to the protection group. This also had no effect, with the databases still reporting as ‘replica is inconsistent’.
  3. Updated the affected server to SQL Sever 2012 SP2 CU2 as the cumulative update mentioned VSS related fixes. Again this had no effect.

I have a Microsoft support call open at the moment in an effort to determine the root cause of the issue, but have found that removing a specific update appears to resolve the issue. The update in question is KB3000853. KB3000853 is an update rollup for Windows 8, Windows RT and Windows Server 2012 and contains a number of fixes including KB2996928 which is a backup related hotfix that references VSS. My suspicion is that this update is what has caused the issue, but will update this post when I get a final resolution from Microsoft support.


I've had this confirmed as an issue with KB3000853 by the Microsoft engineer I've been working with.
The workaround for the moment is to either change the account that runs the SQL VSS Writer service to the domain admin account (I assume an account that has local admin permissions, but have not tested this so far), or remove KB3000853, at which point the backups start functioning correctly again.
There is currently no confirmed release date for an updated version of KB3000853.

Update 2:

There’s now a revised hotfix to correct the issue experienced above. The steps to correct the issue are:

  1. Install KB3000853.
  2. Install hotfix KB2996928.

This combination corrects the issues on the servers on which I have installed them.

Configuring SharePoint 2013 Apps and Multiple Web Applications on SSL with a Single IP Address


Traditionally the approach to multiple SSL IIS websites hosted on a server involved multiple sites each with its own certificate bound to a single IP address/port combination. If you didn’t mind using non standard SSL ports, then you could use a single IP address on the server, but the experience was not necessarily pleasant for the end user. Assuming you wanted to use the standard SSL port (443), the servers in the farm could potentially consume large numbers of IP addresses, especially is using large numbers of websites and large numbers of web front end servers. This approach also carried over to SharePoint where multiple SSL web applications were to be provisioned.

Using a wildcard SSL certificate allows multiple SSL web applications (IIS websites) to be bound to the same IP address/port combination as long as host headers are used to allow IIS to separate the traffic as it arrives. This could be achieved because IIS uses the same certificate to decrypt traffic no matter what the URL that is being requested (assuming they all conform to the domain named in the wildcard certificate) and the host header then allows IIS to route the traffic appropriately.

With the introduction of SharePoint 2013 apps however, there is a requirement for the use of at least two different SSL certificates on the same server; one (in the case of a wildcard, or more if using individual certificates) for the content web applications and a second for the SharePoint app domain that is to be used (the certificate for the apps domain must be a wildcard certificate). The current recommended configuration is to use a separate apps domain (for example if the main wildcard certificate references *, the apps domain should be something along the lines of * rather than a subdomain of the main domain as a subdomain could lead to cookie attached on other non-SharePoint web based applications in the same domain space).

For some organisations, the proliferation of IP addresses for the traditional approach to SSL is not an issue. For some organisations however, either the number of IP addresses that they have available is limited, or they wish to reduce the administration overhead involved in the use of multiple IP addresses servers hosting SharePoint. Other scenarios also encourage the use of a single IP address on a server, for example the use of Hyper-V replication, where the system can handle the reassignment of the primary IP address of the server on failover, but additional IP addresses require that some automation be put in place to configure the additional IP addresses upon failover.

Note: The following is not a step-by-step set of instructions for configuring apps; there are a number of good blog posts (e.g. and of course the TechNet documentation at to lead you through the required steps. This post also borrows heavily from ‘How To Configure SharePoint 2013 On-Premises Deployments for Apps’ by Chris Whitehead – read that article for more in-depth discussion of the configuration required for SharePoint Apps.

SharePoint Apps Requirements

To configure Apps for SharePoint 2013 using a separate domain (rather than a subdomain) for apps, the following requirements must be met:

  • An App domain needs to be determined. If our main domain is ‘’, our apps domain could be ‘’ for example. If SharePoint is available outside the corporate network and apps will be used, the external domain will need to be purchased.
  • An Apps domain DNS zone and wildcard CNAME entry.
  • An Apps domain wildcard certificate.
  • An App Management Service Application and a Subscription Settings Service Application created, configured and running. Note that both of these Service Applications should be in the same proxy group.
  • App settings should be configured in SharePoint.
  • A ‘Listener’ web application with no host header to receive apps traffic.

It is also assumed the the following are already in place:

  • A functional SharePoint 2013 farm.
  • At least one functional content web application configured to use SSL and host header(s).

Infrastructure Configuration

Each App instance is self-contained with a unique URL in order to enforce isolation and prevent cross domain JavaScript calls through the same-origin policy in Web browsers. The format the the App URL is:


The App domain to be used should be determined based on domains already in use.

Instructions for creating a new DNS zone, the wildcard DNS CNAME entry and a wildcard certificate can be found at As we’re planning to use a single IP address for all web applications and Apps, point the CNAME wildcard entry at either the load balanced IP address (VIP) in use for the content web applications, or the IP address of the SharePoint server (if you’ve only got one).

Farm Configuration

To be able to use Apps within SharePoint 2013, both the App Management Service Application and the Subscription Settings Service Application need to be created, configured and running and the App prefix and URL need to be configured. Instructions for getting these two Service Applications configured and running are again available at

In addition to the Service Application configuration, a ‘Listener’ web application with no host header is required to allow traffic for SharePoint Apps to be routed correctly. Without the ‘Listener’ web application with no host header, assuming all other web applications in the farm are configured to use host headers we have the following scenario:

SP 2013 Farm with Apps - No Listener Web App

[diagram from ‘How To Configure SharePoint 2013 On-Premises Deployments for Apps’]

In the above diagram, the client request for the SharePoint App URL DNS lookup is performed which points to the NLB address for the content web applications and traffic is therefore directed to the farm. The host header requests do not however match any of the web applications configured on the farm so SharePoint doesn’t know how to deal with the request.

We could try configuring SharePoint and IIS so that SharePoint App requests are sent to one of the existing web applications, however when using SSL we cannot bind more than one certificate to the same IIS web site and we cannot have an SSL certificate containing multiple domain wildcards. With non-SSL web applications, SharePoint could, in theory, do some clever routing by using the App Management Service Application to work out which web application hosts the SharePoint App web if one of the existing web applications were configured with no host header (I see another set of experiments on the horizon…).

To get around this issue with SSL traffic, a ‘Listener’ web application needs to be created. This web application should have no host header and therefore acts as a catchall for traffic not matching any of the other host headers configured. Note that if you already have a web application without a host header in SharePoint, you’ll have to recreate it with a host header before SharePoint will allow you to create another one. This results in the following scenario:

SP 2013 Farm with Apps - Listner App Config

[diagram from ‘How To Configure SharePoint 2013 On-Premises Deployments for Apps’]

The client request for the SharePoint App URL DNS lookup is performed which points to the NLB address for the content web applications and traffic is therefore directed to the farm. This time however, there is a ‘Listener’ web application that receives all traffic not bound for the main content web applications and internally the SharePoint HTTP module knows where to direct this traffic by using the App Management Service Application to work out where the SharePoint App web is located.

Note: The account used for the application pool for the ‘Listener’ web application must have rights to all the content databases for all of the web applications to which SharePoint Apps traffic will be routed. You could use the same account/application pool for all content web applications, but I’d recommend granting the rights per web applications as required using the ‘SPWebApplication.GrantAccessToProcessIdentity’ method instead.

As we need to use a different certificate on this ‘Listener’ web application, it used to be the case that it would have to be on its own IP address, however with Windows Server 2012 and 2012 R2, a new feature, Server Name Identity (SNI), was introduced that allows us to get around this limitation. To configure the above scenario using a single server IP address, the following steps need to be completed (note that in my scenario, I’ve deleted the default IIS web site; if it is only bound to port 80, then it should not need to be deleted):

  1. Open IIS Manager on the first of the WFE servers.
  2. Select the first of the content web applications and click ‘Bindings…’ in the actions panel at the right of the screen.
  3. Select the HTTPS binding and click ‘Edit…’
  4. Ensure that the ‘Host name’ field is filled in with the host header and that the ‘Require Server Name Indication’ checkbox is selected.
  5. Ensure that the correct SSL certificate for the URL in the ‘Host name’ field is selected.
  6. Ensure that ‘All Unassigned’ is selected in the ‘IP address’ field.
  7. Click OK to close the binding dialog and close the site bindings dialog.
  8. Repeat the above steps for all of the other content web applications with the exception of the ‘Listener’ web app.
  9. Ensure that the bindings for the ‘Listener’ web application do not have a host header. You will not be able to save the binding details for this web application if ‘Require Server Name Indication’ is selected, so leave it unselected for this web application. Select the Apps domain certificate for this web application.
  10. Start any required IIS SharePoint web applications that are stopped.
  11. Repeat the above steps for all of the other WFE servers.

The result of the steps above is that all of the content web applications with the exception of the ‘Listener’ web application should have a host header, be listening on port 443 on the ‘all unassigned’ IP address, have ‘Require SNI’ selected and have an appropriate certificate bound to the web application. The ‘Listener’ web application should have neither a host header, nor have ‘Require SNI’ selected, be listening on port 443 on the ‘all unassigned’ IP address and have the Apps domain certificate bound to it. This configuration allows:

  • Two wildcard certificates to be used, one for all of the content web applications, the other for the Apps domain bound to the ‘Listener’ web application with all applications listening for traffic on the same IP address/port combination, or
  • Multiple certificates to be bound, one per content web application, plus the Apps domain wildcard to be bound to the ‘Listener’ web application with all applications listening for traffic on the same IP address/port combination, or
  • Some combination of the above.

There are some limitations to using SNI, namely that a few browsers don’t support the feature. At the time of writing, IE on Windows XP (but then, you’re not using Windows XP, are you?) and the Android 2.x default browser don’t seem to support it, as don’t a few more esoteric browsers and libraries. All of the up-to-date browsers seem to work happily with it.

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

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

  RW BUILTIN\Administrators
  RW S-1-5-32-549

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 -

  RW BUILTIN\Administrators

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:
    Note: Details on Security Descriptor Definition Language can be found at
  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:
    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 -

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

  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.

Publishing ADFS using Web Application Proxy behind TMG

During a recent upgrade of ADFS from 2.0 to 3.0, we saw an interesting issue publishing the ADFS 3.0 proxy through TMG 2010.

The ADFS 2.0 proxy was published via TMG using a non-preauthenticating publishing web rule which had worked happily since ADFS was first used. When ADFS 3.0 was installed ad configured, the firewall rule was modified to change the IP address that should be used to direct traffic to the ADFS 3.0 proxy instead of the old ADFS 2.0 proxy. When tested, this generated an error in the browser of the user attempting to access the ADFS proxy to sign into their organisation account:

Error Code 64: Host not available

“The page cannot be displayed. Error Code 64: Host not available”

In addition, the test of the firewall rule fails with the error “Connectivity error. Error details: 64 – The specified network name is no longer available.”

This obviously meant that users could not sign in to access services authenticated using ADFS.

The solution is to use a non-web server publishing rule on TMG to simply forward all traffic to the ADFS proxy/Web Application Proxy, however this requires that a dedicated external IP address is available on TMG, or all applications need to be published using the Web Application Proxy instead of using TMG.