Top operations and management issues for SharePoint Server 2013 hybrid

SharePoint 2013

We are in the process of combining the SharePoint Server 2013 and SharePoint Server 2016 content into a single content set. We appreciate your patience while we reorganize things. See the Applies To tag at the top of each article to find out which version of SharePoint an article applies to.


Applies to: SharePoint Online, SharePoint Server 2013

Topic Last Modified: 2016-12-16

Summary: A list of the top operational areas to monitor when maintaining your SharePoint hybrid.

In this topic, we cover major maintenance areas for a SharePoint hybrid, such as Secure Sockets Layer certificate renewal, directory synchronization maintenance, search smoke testing, and upkeep of the user profile application.

Maintenance takes place over the lifetime of a deployment. This article gives you a checklist of the most common SharePoint hybrid maintenance operations you need to undertake. However, your SharePoint hybrid maintenance plan should also include things like:

Building a framework to help create an operational plan (Ops plan) to sustain your hybrid.

Figuring out best practices for disaster recovery (DR) and DR testing.

Creating documentation to rebuild the SharePoint hybrid from scratch, in case of emergency.

You can make a document that will let you rebuild the SharePoint hybrid from scratch by creating an ordered list of steps from the TechNet articles used for your original build. If your organization has any custom implementations, put those into the logical flow of steps from the articles, too. Also, remember that there are Hybrid worksheets that you can fill in, which will let you record every account and URL you use while you configure the SharePoint hybrid for later reference.
Worksheet: SharePoint hybrid worksheet for a one-way outbound topology

Worksheet: SharePoint hybrid worksheet for a one-way inbound or two-way topology

This list of maintenance tasks will help outline common duties for the upkeep of the SharePoint hybrid. Add these steps to your most current maintenance or Ops documentation.


1. SSL certificates

SharePoint hybrids use SSL certificates in three ways:

User authentication

User authorization

Encrypted communications

Generally speaking, these certificates expire once a year.

There are two SSL certificates involved. One is the STS certificate for the on-premises SharePoint hybrid web application. When you created the SharePoint hybrid, and you chose which of the SharePoint sites would participate in the hybrid, you also created a new STS certificate for this web application and uploaded it to Office 365 for professionals and small businesses. In the Office 365 cloud, Microsoft Azure Active Directory (Azure AD) uses the information from this certificate to trust your on-premises domain so that accounts from the on-premises domain can safely access resources in the cloud.

The second is a wildcard SSL certificate that’s used to help secure the channel between the Office 365 cloud and your on-premises domain. It’s installed on your reverse proxy. This certificate encrypts interactions between the cloud and your premises and also pre-authenticates incoming requests. SharePoint Online (SPO) search queries pass through this channel when users access files that are on-premises. Take note that this SSL certificate is only needed in Inbound SharePoint hybrids – any SharePoint hybrid where SharePoint Online will send a request across the Internet into your organization and ask for files or search results. Outbound hybrids don’t need this second certificate.

Generally speaking, the STS certificate can be a self-signed SSL certificate, or it might be a publicly purchased SSL certificate. The wildcard SSL certificate, which is known as the secure channel certificate in a SharePoint hybrid, is a public SSL certificate. Both self-signed and public certificates are subject to expiration and must be renewed yearly.

This means that when you create or buy your SSL certificates, you should take the following additional steps:

Administrators should note the certificate expiration dates.

Long-term planning should ensure that alerts are sent to the proper people in the week or weeks before certificate expiration (whether by use of System Center Operations Manager alerting, email, or a calendar message).

In case of disaster recovery, these certificates should be stored in a secure share from which they can be downloaded by administrators who may have to rebuild the SharePoint hybrid environment.

To replace the STS certificate, follow the steps in the article Replace the STS certificate for the on-premises environment.


2. The Azure Directory Synchronization (DirSync) accounts

When you configure DirSync via its wizard, you use two accounts. One is an account with access to Office 365, and the other is an account with access to your on-premises domain. These accounts and their passwords have to be valid for the health of the SharePoint hybrid. Failure to update these passwords will lead to broken directory synchronization to the cloud. New passwords for both the account that does directory synchronization from on-premises and the Office 365 global administrator account used during directory synchronization must be updated in the DirSync tool.

This means that during your configuration of DirSync, you should also:

  • Decide whether the global administrative account leveraged by DirSync should allow password expiration. A global administrator for Office 365 must use Azure AD Module for Windows PowerShell to set passwords not to expire. (Also, consider that a password that does not reset periodically may open you up to security risks.)

  • If the account must allow password expiration because of expiration policies or security practices, be aware that the passwords in Office 365 expire regularly. When either the account that connects to on-premises Active Directory or the account connecting to the Office 365 cloud expires, they must be updated in the DirSync wizard. Passwords expire every 90 days.

  • Create a procedure for password changes to these two accounts. It should include opening the DirSync wizard, changing passwords for the accounts, and testing directory synchronization. A test account should be successfully synchronized from the on-premises and into your Office 365 directory.

Only passwords for user accounts that are not synchronized through directory synchronization can be configured to never expire.

Need to know more about the accounts used by the DirSync tool? Take a look at these articles: Use the Configuration Wizard to sync your directories, and Plan for directory synchronization for Office 365Placeholder Link Text

If you need to troubleshoot DirSync, some details are covered in Troubleshooting hybrid environments.


3. Hybrid Search Health

When setting up a hybrid, especially in the early going for a search hybrid solution, it’s important to properly test the output of search results. When you test hybrid Search for combined results, be aware of the following:

  • Make sure the person testing the hybrid search knows the topology of the SharePoint hybrid.

  • Log in as a federated user before testing search.

  • Make certain that the federated user has rights to files in the hybrid location.

  • For ease of testing, use the result block or very specific document titles.

  • When search results are returned, remember to click to open the results.

So why is it important that you know the SharePoint hybrid topology? It’s because you need to test in the same location where the combined search results will appear. In other words, test where you would see results that combine SharePoint Online and on-premises hits to make sure your hybrid search works. Look at it this way: if you have a One-Way Outbound hybrid topology, you have to test your search as a federated user, on-premises. Outbound means that your search is configured to query out of your premises to SharePoint Online and pull back search results. Likewise, Inbound means that your premises will have queries coming in from SharePoint Online. In the case of a Two-Way Hybrid, do testing in the Enterprise Search of both the on-premises and the SharePoint Online properties.


One-Way Inbound One-Way Outbound Two-Way

Test search results on-premises?




Test search results in SharePoint Online?




Be certain that testing is done with a user who is federated with Office 365 and, therefore, part of the SharePoint hybrid experience. This means having a test user who is synchronized from the on-premises domain into Azure AD. The user chosen for testing needs to fulfill these requirements:

  • Have an active license in Office 365.

  • Have permission to files in both on-premises and SharePoint Online.

  • Have a user principal name (UPN) that matches the public DNS domain used by the Office 365 hybrid tenant. For example, if the public domain is, the logon should be

Even if you log on as a federated user, remember that if the user doesn’t have rights to files in both locations, the results will not be combined. So, if is a federated user in a One-Way Outbound but doesn’t have rights to any files in SharePoint Online, her results will contain only on-premises files.

If you are testing search, it may also be beneficial to use a result block in the SharePoint search query rule. Result blocks separate the search results from the hybrid locations (for example, SPO results are separated from on-premises SharePoint Server). If you’re logged in to a hybrid SPO, search results that come from your on-premises will be separated and framed so that they’re easier to find. You can also specify in the query rule that the search results appear at the top of the first page. This will help you do a few things:

  • Assure that hybrid search is working.

  • Help test and benchmark search result performance across the Internet.

  • Test if clicking hyperlinks in search results works as expected no matter where the results come from.

If, for example, you’re doing a One-way Inbound to a line-of-business application for hybrid Business Connectivity Services or Duet, that query will also be affected by general networking and design choices (for example SSL bridging). You should also consider testing and benchmarking these hybrid solutions with and without load to get a feel for result latency.

Remember that no test of hybrid search is complete until you have clicked query results to witness the behavior. The last step in testing, when there is a result, is to click through to files and lists. Do this across the combined search results. You have a different troubleshooting scenario if a single file in the result block doesn’t work than if no file in the result block works. In this way, having a single location at the top of your search results page will help you test and validate hybrid search behavior.

For more information on planning hybrid search, see Plan hybrid federated search for SharePoint Server 2013Plan hybrid search for SharePoint Server 2013.

If you need to troubleshoot your hybrid search, see Troubleshooting hybrid environments.


4. On-premises SharePoint User Profile Application (UPA)

Mismanagement of identities in the on-premises domain or a lack of critical attention to user profiles inside the SharePoint on-premises (from which SharePoint hybrid synchronizes user information) can cause your Office 365 directory to fall out of synch. For example:

  • If you want new accounts that are added to your domain to also use the SharePoint hybrid, you need to make certain the accounts in Active Directory Domain Services (AD DS) have the proper federated UPN.

  • If you remove Replicate Directory Changes rights from the account used to synchronize profiles to SharePoint, the account won’t be able to read AD DS for new or changed information.

  • If your on-premises User Profile Application (UPA) services have been in a stopped state for a while, all the information going to the Office 365 cloud through DirSync will be stale.

Making sure you are aware of user profile and profile synchronization health fits into a more general plan for supervising a SharePoint Server 2013 farm. Two common methods of monitoring come at this problem from a micro and macro focus:

  • Monitoring by setting diagnostic logs through either SharePoint Central Administration or Windows PowerShell, then checking the logs on a schedule.

  • Monitoring using System Center 2012 and Operations Manager with System Center Management Pack for SharePoint Server 2013.

It may be best to combine the two types of monitoring.

SharePoint Administrators can monitor the Unified Logging System (ULS) inside SharePoint for errors that involve the user profile or user profile synchronization. When you keep an eye on Event Viewer and ULS on a regular interval can catch errors before they become disasters. For example, if you discover an issue that seems to happen near the middle of a profile synchronization, you can start a new ULS log with the New-SPLogFile Windows PowerShell cmdlet and start the profile synchronization. The ULS log file name will append with an ”A” to make clear which file is new. Splitting the log will give you a better chance of capturing the complete error.

When an error is found in SharePoint, ULS can send a message about the problem to the trace logging that SharePoint maintains, to Event Viewer, or to the SharePoint Logging database. SharePoint administrators can control how much information is tracked in SharePoint trace logs (or ULS logs), by using Monitoring > Configure Diagnostic Logging in Central Administration, or with Windows PowerShell cmdlets.

You can use Windows PowerShell cmdlets to quickly check and reset the logging level for user profiles before they start a new log, take the error action, and consult ULS logs again.

For a primer on monitoring, particularly around ULS, see: Chapter 3: Monitoring SharePoint 2010 (Real World SharePoint 2010).

You can also set up User Profile Service monitoring using System Center 2012 and Operations Manager with System Center Management Pack for SharePoint Server 2013. It’s a mouthful, I know, but the Management Pack will allow you to monitor both and Project Server 2013. It follows more than just the User Profile Service and can be a comprehensive part of general monitoring on-premises.

By using the Management Pack, you can monitor:

  • User Profile Audience Compilation Failure.

  • User Profile Service Synch Scheduler Failed.

  • Profile Synchronization Configuration Service Is Not Running.

  • Profile Synchronization Service Is Not Running.

  • Profile Synchronization Configuration Service Failed To Connect To SQL Server.

  • Profile Synchronization Service Unexpected Failures.

  • Profile Synchronization Execution Failures.

  • User Profile Service Timer Job Failed.

Click here to download the System Center Management Pack for SharePoint Server 2013 and the accompanying guide.