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.

Workflow Manager 1.0 doesn't successfully install on Windows Server 2012 R2 unless VC Redist 11.0 or 12.0 already present

There seems to be an issue installing Workflow Manager 1.0 refresh on Windows Server 2012 R2. Upon completion, when clicking through to configure Workflow Manager, you are informed that neither Service Bus 1.0, nor (obviously) CU1 for Service Bus 1.0 has been installed.

Digging into the event log on the machine in question, this shows that VC Redist 11.0 or greater is required, and this is not installed automatically by the WebPI.

On Windows Server 2012, VC redist 12.0 is installed automatically by WebPI and the installation of Workflow Manager 1.0 Refresh completes successfully.

Obviously the solution is to install VC redist 11.0 or 12.0 before attempting to install Workflow Manager 1.0 refresh on Windows Server 2012 R2.

SharePoint 2013 on Windows Server 2012 R2 Preview and SQL Server 20143 CTP1

Following the recent release of Windows Server 2012 R2 Preview and SQL Server 2014 CTP1, I thought it would be an interesting experiment to see if I could get SharePoint 2013 running on the combination of these two previews. Most of the issues I encountered were around the product installers for SharePoint and the SharePoint pre-requisites:

  1. The SharePoint 2013 prereqinstaller.exe installer would not run and gave the error “This tool does not support the current operating system”.
    Pre-req_error
  2. The SharePoint binary installer would insist that not all of the server features required by SharePoint had been installed.
  3. The SharePoint binary installer failed when installing the oserver.msi file.
    Binary_setup_error
    Followed by:
    Setup_bootstrapper_stopped
    Examination of the setup logs (located at C:\Users\<username>\AppData\Temp\SharePoint Server Setup(<date-time).log) showed the following error:
    ”Error: Failed to install product: C:\MediaLocation\SharePoint2013InstallationMedia\global\oserver.MSI ErrorCode: 1603(0x643).”

SQL Server 2014 CTP1 seemed to install and work fine, although I did experience a couple of crashes during the installation procedure.

The following are workarounds for the issues seen above:

Preparing the server manually instead of using the prereqinstaller.exe involves adding the required server features and then manually installing the SharePoint pre-req files.

To add the required server features, use the following PowerShell commands in an elevated PowerShell prompt:

Import-Module ServerManager

Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,Application-Server,AS-Web-Support,AS-TCP-Port-Sharing,AS-WAS-Support, AS-HTTP-Activation,AS-TCP-Activation,AS-Named-Pipes,AS-Net-Framework,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer

If the server is not connected to the internet, the following PowerShell commands can be used (assuming that the installation media is available on D:\):

Import-Module ServerManager

Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,Application-Server,AS-Web-Support,AS-TCP-Port-Sharing,AS-WAS-Support, AS-HTTP-Activation,AS-TCP-Activation,AS-Named-Pipes,AS-Net-Framework,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer –Source D:\sources\sxs

Scripts are available to download the SharePoint pre-reqs; the one I used is located at http://gallery.technet.microsoft.com/office/Script-to-SharePoint-2013-702e07df

I chose to install each of the pre-reqs manually, however the Windows Server App Fabric installer should be installed using the command line rather than the GUI as I couldn’t successfully get it installed with the options required using the GUI. To install Windows Server App Fabric, open an admin PowerShell console and use the following commands (assuming the installation file is located at c:\downloads):

$file = “c:\downloads\WindowsServerAppFabricSetup_x64.exe”

& $file /i CacheClient”,”CachingService”,”CacheAdmin /gac

Note the locations of the “ marks in the second command line, these should be around the commas.

Once this is installed, the Windows Server AppFabric update (AppFabric1.1-RTM-KB2671763-x64-ENU.exe) can also be installed. For reference, the other pre-reqs that I manually installed were:

  • MicrosoftIdentityExtensions-64.msi
  • setup_msipc_x64.msi
  • sqlncli.msi
  • Synchronization.msi
  • WcfDataServices.msi

In each of the above cases, I accepted the default installation options.

Following the installation of the SharePoint 2013 pre-reqs, the SharePoint 2013 binary installer insisted that not all of the required server features were installed. Shutting the server down and restarting it (sometimes twice) seemed to solve this issue.

To solve the issue experienced during the binary installation of SharePoint 2013, a modification of the oserver.msi file is required. This can be achieved using ‘Orca’. Orca is available as part of the Windows Software Development Kit (SDK) for Windows 8, which can be downloaded from http://msdn.microsoft.com/en-us/library/windows/desktop/hh852363.aspx

Once the SDK is installed, start Orca, then use it to open the oserver.msi file located in the ‘global’ folder of the SharePoint 2013 installation media (taking a backup of the original file first, of course…), then navigate to the ‘InstallExecusteSequence’ table and drop the ‘ArpWrite’ line:

Orca_oserver_msi_modification

Save the file over the original, the start the binary installation in the usual way.

Here’s a shot of SharePoint 2013 working on Windows Server R2 Preview with SQL Server 2014 CTP1:

SP2013_on_2012R2Preview_SQL2014CTP1

Please note, all of the above is done entirely at your own risk and is for testing purposes only. Don’t even think of using it in production…

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