Earlier this week, I was at one of my customers which has a SharePoint 2013 implementation. They had an issue where following sites was not working anymore. When they clicked the Follow link, they got an error that the site could not be followed.
They have a hybrid implementation with OneDrive for Business and Hybrid Sites setup.
When I looked in the ULS, I saw the following error popping up
FollowedContent.FollowItem:Exception:System.Net.WebException: The remote server returned an error: (401) Unauthorized.
at Microsoft.SharePoint.Client.ClientRequest.ExecuteQueryToServer(ChunkStringBuilder sb)
at Microsoft.Office.Server.UserProfiles.FollowedContentProxy.Execute(String methodName)
at Microsoft.Office.Server.UserProfiles.FollowedContent.DoHybridFollow(String scopeName, FollowedItem item)
at Microsoft.Office.Server.UserProfiles.FollowedContent.FollowItem(FollowedItem item, Boolean isInternal)
Loud and clear… authentication issues.
Microsoft has an excellent resource where they outline the roadmap to implement hybrid features.
Both roadmaps outline the steps which are needed to set up those features. Since OneDrive for Business was working fine, I focused on the Hybrid Sites features and started going through the steps of the roadmap to see if everything was set up correctly.
- Configure Office 365 for SharePoint hybrid – Check!
- Set up SharePoint services for hybrid environments – Check!
- Install the September PU for SharePoint Server 2013 – We were on the December 2016 CU, so … Check!
- Configure S2S authentication from SharePoint Server 2013 to SharePoint Online – Hmmm… I don’t recall doing this in the past.
- Configure hybrid sites features in Central Administration – Check!
Since I was getting authentication issues, and I didn’t recall me doing the S2S authentication configuration step, I figured that this was the cause of the problem.
When you follow the link for that step, you will see that there’s some work to do to set it up. Luckily, Microsoft provided a tool which actually does it for you. It’s called the Hybrid Picker. This simplifies things a bit.
To run this tool, you have to be logged on to one of your on premise SharePoint servers as a farm administrator. Then you go to your Office 365 SharePoint administration portal. On the left navigation, there’s a configure hybrid link. When you follow that link, a page is displayed with some explanation about the hybrid picker. There you can click the Go to Hybrid Picker download Page link. For some tenants, the text for the link will be Hybrid Picker.
When you click that link, you will get a popup where you can start the tool by clicking the click here link.
A download will start. Once it’s completed, you can run it.
From there on, it’s a wizard which steps through the configuration.
The on-premises credentials are default set to the current Windows credentials.
Just fill in your O365 global administrator credentials and click the Validate credentials button. This should give the following result.
Close and Next.
At this point, some checks are done to see if all prerequisites are met.
Offcourse, these should all be green in order to proceed. If they are, click Next.
You need to specify which hybrid features you want to configure. For me, only the OneDrive and Sites features were needed. Apparently, when you check the Hybrid Sites feature, the Hybrid App Launcher and B2B sites are automatically enabled as well.
At this time, the configuration is executed. You will see some PS commands flashing by in the wizard… fingers crossed nothing fails! 🙂
Just wait and sit it out. Eventually, you should see the following:
All green! Cool!
See the note on top… you need to do an IISRESET.
That brings you to the last page in the configuration wizard where you can rate the experience and provide some feedback if you want.
And that’s it. Just don’t forget to do an iisreset.
After doing that, the following sites feature should be working again. In our case, I noticed that for a specific user the issue wasn’t resolved. But this was because that user didn’t have access to O365 at all.
A word of caution though… since this step changes the authentication realm of the on-premise farm, existing cross farm trusts will break, resulting in authentication issues. Microsoft outlines the issue and the fixes for Workflow Manager and provider-hosted apps in the following article:
Site Mailbox Provisioning Issues
This article however doesn’t mention the fact that if you configured site mailboxes in SharePoint 2013 prior to running the hybrid picker, the provisioning of these mailboxes is broken as well!
Well, somehow this seems logical because to configure site mailboxes, you establish a trust between your Exchange Server and your SharePoint farm. So, this trust can be considered a cross-farm trust, right?
This trust between Exchange and SharePoint was made by running the c:\Program Files\Microsoft\Exchange Server\v15\Scripts\Configure-EnterprisePartnerApplication.ps1 script on the Exchange Server. This script accepts 2 parameters:
- ApplicationType : To establish a trust between Exchange and SharePoint, the value for this parameter will be “SharePoint”
- AuthMetadataUrl : the URL of a document that contains the needed metadata for the trust. This url will be “https://<webappurl>:443/_layouts/15/metadata/json/1”
.\Configure-EnterprisePartnerApplication.ps1 –ApplicationType SharePoint –AuthMetadataUrl https://teamsites.westeros.local:443/_layouts/15/metadata/json/1
In the document which is located at the specified URL, the authentication realm is provided.
The authentication realm is the part behind the @ of the issuer in the beginning of the document. When the script is executed, a new partner application is created in Exchange and this realm is inserted as the realm of that partner application.
If you did the site mailbox configuration before you ran the hybrid picker, the registered partner application will have a realm which is different from the one which is provided in the metadata document and you will have authentication issues.
So, to fix the site mailbox provisioning, you have to do 2 things:
- Remove the existing partner application in Exchange using the Remove-PartnerApplication cmdlet
- Register a new partner application using the Configure-EnterprisePartnerApplication.ps1 script.
Once this is done, you can verify if the Realm of the added partner application matches the one from the metadata document.
And that’s it. Good to go!