Andy Dawson's Blog

The blog of Andy dawson

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

Background

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 *.domain.com, the apps domain should be something along the lines of *.domain-apps.com 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. http://sharepointchick.com/archive/2012/07/29/setting-up-your-app-domain-for-sharepoint-2013.aspx) and of course the TechNet documentation at http://technet.microsoft.com/en-us/library/fp161236(v=office.15).aspx to lead you through the required steps.

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 ‘contoso.com’, our apps domain could be ‘contosoapps.com’ 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:

App URL

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 http://technet.microsoft.com/en-us/library/fp161236(v=office.15).aspx. 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 http://technet.microsoft.com/en-us/library/fp161236(v=office.15).aspx.

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

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

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

Setting SharePoint 2013 User Profile Service Application Permissions Using PowerShell

My last post about the SharePoint 2013 MySite Newsfeed and required additional permissions on the User Profile Service Application dealt with adding the required permissions to the UPSA using the SharePoint 2013 GUI. Alternatively, you can add the required permissions using PowerShell:

#Grab a reference to the User Profile Service Application $serviceapp = Get-SPServiceApplication | where {$_.DisplayName -eq "User Profile Service Application"} #Return the SPObjectSecurity object for the Service Application $security = Get-SPServiceApplication $serviceapp | Get-SPServiceApplicationSecurity #Setup our claim provider $claimprovider = (Get-SPClaimProvider System).ClaimProvider #Specify the required principal $principal = New-SPClaimsPrincipal "Domain\UPSAppAccount" -IdentityType WindowsSamAccountName #Grant the required permissions on the Service Application Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control" Set-SPServiceApplicationSecurity $serviceapp -ObjectSecurity $security

Using PowerShell allows us to add this part of the configuration to a script rather than having a manual step to perform once the PowerShell has completed (as we all know, these additional manual steps tend to get forgotten).

SharePoint 2013 MySite Newsfeed displays "There was a problem retrieving the latest activity. Please try again later"

This is an issue that we've been bumping up against and have seen a number of other users seeing the same problem with SharePoint 2013 implementations.

When looking at the 'Everyone' tab on a user's MySite, the following message is displayed:

There was a problem retrieving the latest activity. Please try again later.

and the following entries appear in the SharePoint logs:

Failure retrieving application ID for User Profile Application Proxy 'User Profile Service Proxy': Microsoft.Office.Server.UserProfiles.UserProfileApplicationNotAvailableException: UserProfileApplicationNotAvailableException_Logging :: UserProfileApplicationProxy.ApplicationProperties ProfilePropertyCache does not have c2d5c86f-e928-4abf-b353-a8ab7809766c     at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_ApplicationProperties()     at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_AppID()           0e49dc9b-d278-1089-b021-6e2138766eae

SPMicrofeedFeedCacheService.GetUserProfile() - UserProfileApplicationProxy not available     0e49dc9b-d278-1089-b021-6e2138766eae

To correct this issue, complete the following steps:

  1. Log onto the SharePoint 2013 Central Administration site as a farm administrator
  2. Navigate to 'Manage Service Applications'
  3. Highlight the User Profile Service Application
  4. Click the 'Permissions' ribbon toolbar button:
    UPSA permissions
  5. Add the account that is used to run the User Profile Service Application and give it full control:
    UPSA connection permissions
  6. Click OK

At this point it is usual to see the following displayed in the 'Everyone' tab of the user's MySite:

Were still collecting the latest news. You may see more if you try again a little later.

It's worth checking the SharePoint logs at this point to see what additional errors may be reported (note that you will see 'We're still collecting the latest news' if no users have posted anything, so create a post to ensure that you have something waiting in the queue). In my case, I saw the following:

System.Data.SqlClient.SqlException (0x80131904): Cannot open database "SP_Content_MySite" requested by the login. The login failed.  Login failed for user 'Domain\UPSApp'.

This can be solved by completing the following steps:

  1. Open the SharePoint 2013 Management Shell by right-clicking and choosing 'run as administrator'
  2. Issue the following PowerShell commands
    $wa = Get-SPWebApplication http://<MySiteURL>
    $wa.GrantAccessToProcessIdentity("domain\UPSApp")

At this point, the newsfeed should be up and running successfully:

Functional everyone newsfeed

CRM 2011 Fetch-Based Reports Fail with 'rsProcessingAborted'

I recently saw a CRM 2011 instance which had had and issue with SQL Reporting Services. To correct the issues with the Reporting Services server, which was separate to the CRM 2011 server, SQL Reporting Services has been completely reinstalled on the server. Following this action, there were a few steps that needed taking to get reports working again in CRM.

  • The CRM reporting services extensions needed to be reinstalled and patched on the Reporting Services server.
  • The CRM reports needed republishing to the Reporting Services server. This was achieved by running the following command:
    PublishReports.exe <CRMOrganisationName>
    Note: The PublishReports.exe tool can be found in C:\Program Files\Microsoft Dynamics CRM\Tools folder on the CRM server.
    Note: The <CRM OrganisationName> is displayed under 'Organizations' in the Microsoft Dynamics CRM Deployment Manager.

Once both these steps were taken, some of the reports still didn't work, especially reports that had been generated using CRM's report wizard. The error reported on the report display page was:

Report render failure. Error: An error has occurred during report processing. (rsProcessingAborted)

Kerberos had been setup correctly for the CRM server and had been checked (see KB2590774 but note that the account for which SPNs are set should also be trusted for delegation).

Examination of the CRM logs showed the following errors:

System.ServiceModel.EndpointNotFoundException: Could not connect to net.tcp://CRMServer/CrmSandboxSdkListener-w3wp. The connection attempt lasted for a time span of 00:00:21.0185095. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond XXX.XXX.XXX.XXX:808.

System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond XXX.XXX.XXX.XXX:808 ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: An unexpected error occurred. ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: Could not connect to net.tcp://CRMServer/CrmSandboxSdkListener-w3wp. The connection attempt lasted for a time span of 00:00:21.0185095. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond XXX.XXX.XXX.XXX:808.  ---> Microsoft.Crm.Reporting.DataExtensionShim.Common.ReportExecutionException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond XXX.XXX.XXX.XXX:808

By default, a firewall rule named 'Windows Communication Foundation Net.TCP Listener Adapter (TCP-In)' on port 808 is available on Windows, but is not activated by the CRM installation. For fetch-based reports to work correctly when Reporting Services in installed on a different server to CRM, this firewall rule needs to be enabled on the CRM server.

SharePoint 2010 Service Application Communication Scheme

The default communication scheme for many of the SharePoint 2010 Service Applications is ‘http’ (i.e. unsecured). This can be changed easily in the GUI by selecting the service application and clicking the ‘publish’ ribbon button:

Service Application publish ribbon toolbar button

It should however be noted that a number of Service Application communication schemes run by default over https and cannot be modified, these are:

  • Application Discovery and Load Balancer Service Application
  • Search Administration Web Service
  • Secure Store Service Application
  • Security Token Service Application

The communication scheme of a few Service Applications cannot be inspected using the GUI (and the publish ribbon button remains greyed out when they are selected):

  • SharePoint Server ASP.NET Session State Service
  • SharePoint Session State Service Application
  • WSS_UsageApplication

Modifying the communication scheme of all of the Service Applications can be time consuming and can be error prone, especially when using SharePoint 2010 Enterprise and the Office Web Applications with all of the Service Applications available configured for use. With this in mind, the following PowerShell will change the communication scheme of all of the Service Applications where it is possible to do so to https:

1 # This script sets the communication scheme of all Service Applications to be https instead of http 2 # Note that the communication scheme for a number of Service Applications cannot be changed 3 4 # Grab a list of the Farm's Service Applications 5 $ServiceApps = Get-SpServiceApplication | Sort-Object TypeName 6 7 # Iterate through the Service Applications 8 foreach ($ServiceApp in $ServiceApps) 9 { 10 if (($ServiceApp.TypeName -ne "Application Discovery and Load Balancer Service Application") ` 11 -and ($ServiceApp.TypeName -ne "Search Administration Web Service Application") ` 12 -and ($ServiceApp.TypeName -ne "Security Token Service Application") ` 13 -and ($ServiceApp.TypeName -ne "Secure Store Service Application") ` 14 -and ($ServiceApp.TypeName -ne "SharePoint Server ASP.NET Session State Service") ` 15 -and ($ServiceApp.TypeName -ne "State Service") ` 16 -and ($ServiceApp.TypeName -ne "Usage and Health Data Collection Service Application")) 17 { 18 # We can modify the communication scheme 19 Write-Host "Current communication shceme for" $ServiceApp.DisplayName ":" $ServiceApp.DefaultEndpoint.Name 20 if (($ServiceApp.DefaultEndpoint.Name -eq "https") -or ($ServiceApp.DefaultEndpoint.Name -eq "secure")) 21 { 22 Write-Host "Service Application already using https, skipping" -ForegroundColor Red 23 } else { 24 # Change the communication scheme to https 25 26 27 if ($ServiceApp.TypeName -eq "PowerPoint Service Application") { 28 # PowerPoint Service Application has "fast" instead of "http" and "secure" instead of "https" 29 $SAEhttps = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "secure"} 30 } else { 31 $SAEhttps = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "https"} 32 } 33 Write-Host "Setting Service Application communication scheme to https" -ForegroundColor Green 34 $ServiceApp.DefaultEndpoint = $SAEhttps 35 $ServiceApp.Update() 36 } 37 Write-Host "`n" 38 } 39 }

To reverse these changes, and set the communication scheme of all Service Applications for which it is possible to modify the communication scheme, the following PowerShell can be used:

1 # This script sets the communication scheme of all Service Applications to be http instead of https 2 # Note that the communication scheme for a number of Service Applications cannot be changed 3 4 # Grab a list of the Farm's Service Applications 5 $ServiceApps = Get-SpServiceApplication | Sort-Object TypeName 6 7 # Iterate through the Service Applications 8 foreach ($ServiceApp in $ServiceApps) 9 { 10 if (($ServiceApp.TypeName -ne "Application Discovery and Load Balancer Service Application") ` 11 -and ($ServiceApp.TypeName -ne "Search Administration Web Service Application") ` 12 -and ($ServiceApp.TypeName -ne "Security Token Service Application") ` 13 -and ($ServiceApp.TypeName -ne "Secure Store Service Application") ` 14 -and ($ServiceApp.TypeName -ne "SharePoint Server ASP.NET Session State Service") ` 15 -and ($ServiceApp.TypeName -ne "State Service") ` 16 -and ($ServiceApp.TypeName -ne "Usage and Health Data Collection Service Application")) 17 { 18 # We can modify the communication scheme 19 Write-Host "Current communication shceme for" $ServiceApp.DisplayName ":" $ServiceApp.DefaultEndpoint.Name 20 if (($ServiceApp.DefaultEndpoint.Name -eq "http") -or ($ServiceApp.DefaultEndpoint.Name -eq "") -or ($ServiceApp.DefaultEndpoint.Name -eq "fast")) 21 { 22 Write-Host "Service Application already using http, skipping" -ForegroundColor Red 23 } else { 24 # Change the communication scheme to https 25 if ($ServiceApp.TypeName -eq "Visio Graphics Service Application") 26 { 27 # Visio Graphics Service Application has "" instead of "http" (equivalent to "default" in the GUI) 28 $SAEhttp = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq ""} 29 } elseif ($ServiceApp.TypeName -eq "PowerPoint Service Application") { 30 # PowerPoint Service Application has "fast" instead of "http" and "secure" instead of "https" 31 $SAEhttp = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "fast"} 32 } else { 33 $SAEhttp = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "http"} 34 } 35 Write-Host "Setting Service Application communication scheme to http" -ForegroundColor Green 36 $ServiceApp.DefaultEndpoint = $SAEhttp 37 $ServiceApp.Update() 38 } 39 Write-Host "`n" 40 } 41 }

Note that an IISRESET will be required on all servers in the farm once either of the above PowerShell scripts has been run to complete the modification of the communication scheme.

Publishing Access Services Database to SharePoint 2010 gives ‘&lt;URL&gt; did not respond…’

While building a portion of our demo SharePoint 2010 farm, I encountered an error when publishing an Access 2010 database to a SharePoint 2010 Access Services site.

The error which was shown was ‘<URL> did not respond. Either the server does not exist, Microsoft Access Services are not enabled on the server, or the server is using an older version of Microsoft Access Services which is not compatible with Access 2010’:

Access Services Publish Error

After checking that the Access Services farm and web application features were enabled, and that the enterprise features were enabled on the site collection to which I was attempting to publish the Access database (all were fine), I looked in the server application logs on the WFE servers in the demo farm, and on one of the farm servers saw the error ‘There is no default Access Services Application Proxy’:

Event Viewer Error

Checking the Service Application Associations (Central Administration –> Application Management –> Configure service application associations) showed that the Access Database Service proxy was not associated with the default proxy group:

Proxy Associations

After adding the Access Database Service proxy to the default group, publishing the Access database to SharePoint proceeded without a hitch.

In our case, the proxy not being associated with the default proxy group was due to us using PowerShell to configure the Access Service Application. If you do the same, check whether the proxy has been associated with the default group (or whatever proxy group you want it associated with).

Renaming the PerformancePoint Service Application database in SharePoint 2010

When creating the PerformancePoint Service Application, there is no way to control the name of the database that is created, not even when using PowerShell to create the Service Application. The database that gets created is in the form

<Service Application Name>_GUID

which for some reason a good many DBAs are not too keen on!

The database can however be renamed by following these steps:

  • Stop the PerformancePoint service on all SharePoint servers in the farm that are running the service using the ‘services on servers’ area of Central Administration:
    Stopping the PerformancePoint Service
  • Rename the database and log file – there are two ways of completing this; I prefer the second option of the two outlined below as it completely renames all of the references to the database, but it is a more involved process:
    1. Open SQL Server Management Studio on the SQL Server for the farm.
      Select the PerformancePoint Service Application database and then click again to allow renaming:
      Rename PerformancePoint DB in GUI
      Rename the database to match the naming convention you wish to use for farm databases. Note that this only renames the database friendly name as shown in SQL Server Management Studio and not the file names or the logical database and log file names.
    2. Alternatively:
      Open SQL Server Management Studio on the SQL Server for the farm.
      If you wish to, you can change the recovery mode of the PerformancePoint database to ‘simple’; this saves having to backup and restore a log file as well as the database file.
      Backup the PerformancePoint database created during the Service Application creation process.
      Restore the PerformancePoint database from the backup completed to a new database name which matches the naming convention you wish to use for farm databases. Note that the default naming convention for the log files on restore appends ‘_1’ to the database name to form the log file name; you may wish to change this to ‘_log’ to match the other log files that the database server hosts. The backup and restore will change the filenames used for the databases and the display name shown in SQL Server Management Studio, but not the logical database names. To change the logical database names, first find the logical names of the database and log for the database you wish to change; you can find this information either by taking note of the original database name when it was created, or from the ‘files’ section of the database properties screen within SQL Server Management Studio:
      Database Logical Names
      Execute the following two SQL queries:

      ALTER DATABASE <new PerformancePoint database name> MODIFY FILE (NAME="<original logical database name>", NEWNAME="<new PerformancePoint database name>")

      ALTER DATABASE <new PerformancePoint database name> MODIFY FILE (NAME="<original logical log file name>", NEWNAME="<new PerformancePoint database name>_log")

      If you changed the database recovery mode to ‘simple’, change it back to ‘full’.
  • On one of the SharePoint servers in the farm, open an instance of the SharePoint 2010 Management Shell, ensuring that it is run as administrator and issue the following PowerShell Commands:

    $newdatabasename = "<new PerformancePoint database name>"
    Set-SPPerformancePointServiceApplication -Identity "<name of the PerformancePoint Service Application>" -SettingsDatabase $newdatabasename
  • Restart the PerformancePoint service on the servers in the farm it was running on originally.
  • Delete the original PerformancePoint database that was created during the Service Application creation from SQL Server Management Studio.

Installation of CRM 4.0; ASP.NET 2.0 not installed and the Asynchronous Service fails to start

The above two errors hit me recently while I was trying to get a CRM 4.0 development environment installed for some upcoming work.

The first error shows up when the CRM 4.0 installer is checking the server configuration of the computer on which it is being installed as one of the final steps before installation commences. I checked that .NET 2.0 was installed and patched (it was) and that I had run the correct aspnet_regiis command to install ASP.NET 2.0 and update the scriptmaps (I had). As I’d patched the server completely, the server now had .NET 4 installed and following a bit if research, it appears that for CRM 4.0 installation, this interferes with the detection of ASP.NET 2.0. There’s a good walkthrough of the workaround, which involves adding a new ISAPI filter at the root of the websites listed in IIS manager, at http://www.powerobjects.com/blog/2010/08/14/ms-dynamics-crm-installation-asp-net-2-0-is-not-installed/

For the record, in this instance I was using Windows Server 2003 R2 x86 for the CRM server and Windows Server 2003 R2 x64 for the SQL server.

Following the above error, I also saw an issue at the very end of the installation, whereby the CRM Asynchronous Service failed to start. The error shown in the dialogue was

“Action Microsoft.Crm.Setup.Common.RegisterAsyncServiceAction failed. An exception occurred during the Commit phase of the installation. This exception will be ignored and installation will continue. However, the application might not function correctly after installation is complete. Time out has expired and the operation has not been completed.”

In addition, the following was recorded in the crm40svrSetup.log file located at C:\Document and Settings\<user name>\Application Data\Microsoft\MSCRM\Logs

12:10:24|  Error| System.Exception: Action Microsoft.Crm.Setup.Common.RegisterAsyncServiceAction failed. ---> System.Configuration.Install.InstallException: An exception occurred during the Commit phase of the installation. This exception will be ignored and installation will continue. However, the application might not function correctly after installation is complete. ---> System.ServiceProcess.TimeoutException: Time out has expired and the operation has not been completed.
   at System.ServiceProcess.ServiceController.WaitForStatus(ServiceControllerStatus desiredStatus, TimeSpan timeout)
   at Microsoft.Crm.ExtendedServiceInstaller.StartService(Object sender, InstallEventArgs e)
   at System.Configuration.Install.InstallEventHandler.Invoke(Object sender, InstallEventArgs e)
   at System.Configuration.Install.Installer.OnCommitted(IDictionary savedState)
   at System.Configuration.Install.Installer.Commit(IDictionary savedState)
   --- End of inner exception stack trace ---
   at System.Configuration.Install.Installer.Commit(IDictionary savedState)
   at System.Configuration.Install.AssemblyInstaller.Commit(IDictionary savedState)
   at Microsoft.Crm.Setup.Common.RegisterAsyncServiceAction.Do(IDictionary parameters)
   at Microsoft.Crm.Setup.Common.Action.ExecuteAction(Action action, IDictionary parameters, Boolean undo)
   --- End of inner exception stack trace ---, Error, RetryCancel, Option1

I also noticed that on the SQL server, the following error was reported:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' on SQL server

This indicated a possible issue with Kerberos and following a bit of investigation, this turned out to be the case. Microsoft have very helpfully supplied a walkthrough for correcting the issue at http://support.microsoft.com/kb/921393 (although personally I find using ADSIEdit far easier than SetSPN; ADSIEdit can be installed on Windows Server 2003 R2 from the \Support\Tools folder of the installation media).

Once the correct SPNs were in place, the CRM Asynchronous Service started successfully.

Manually removing a SQL Reporting Services instance from a scale out deployment

If you need to remove an instance of SQL Reporting Services from a scale out deployment, but for some reason cannot contact the instance you wish to remove (e.g. the computer has failed or been rebuilt without removing it from the scale out deployment first) you can do this manually from one of the other computers in the scale out deployment by following these steps:

  • To list the announced report servers currently in the database:
    RSKeyMgmt –l
  • This will provide you with a list in the format
    MachineName\Instance - <GUID of the instance>
    Note the GUID of the instance you wish to remove
  • To remove the instance of SQL Reporting Services:
    RSKeyMgmt –r <GUID of the instance noted above>
  • You will be asked to confirm that you wish delete the key you have entered.

Note that RSKeyMgmt.exe is located in C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\ on a 64-bit SQL 2008 Reporting Services instance.