Categories: ExchangeSharePoint

Exchange 2013 integration with SharePoint doesn’t work

The steps to integrate new Microsoft Exchange 2013 with SharePoint 2013 are fairly simple. You just need to follow Microsoft Configure site mailboxes in SharePoint Server 2013 recommendations and you're done. As life turns out it's not always the case.

Problem Description

Generally to integrate Exchange 2013 with SharePoint an Exchange administrator has to run just one command:

.\Configure-EnterprisePartnerApplication.ps1 -ApplicationType Sharepoint -AuthMetadataUrl https://<SP_FQDN>/_layouts/15/metadata/json/1

It looks fairly simple, and looks quite error free

[PS] C:\Program Files\Microsoft\Exchange Server\V15\Scripts>.\Configure-EnterprisePartnerApplication.ps1 -AuthMetaDataUrl https://sharepoint.evotec.pl/_layouts/15/metadata/json/1 -ApplicationType SharePoint

Creating a new session for implicit remoting of "Get-User" command... 
Creating User <SharePointEnterprise-ApplicationAccount> for Partner Application.
Created User <DOMAIN.GLOBAL/GLOBAL/Gliwice/Users-Unsorted/SharePointEnterprise-ApplicationAccount> for Partner Application.

Assigning role <UserApplication> to Application User <DOMAIN.GLOBAL/GLOBAL/Gliwice/Users-Unsorted/SharePointEnterprise-ApplicationAccount>.
Assigning role <LegalHoldApplication> to Application User <DOMAIN.GLOBAL/GLOBAL/Gliwice/Users-Unsorted/SharePointEnterprise-ApplicationAccount>.
Assigning role <Mailbox Search> to Application User <DOMAIN.GLOBAL/GLOBAL/Gliwice/Users-Unsorted/SharePointEnterprise-ApplicationAccount>.
Assigning role <TeamMailboxLifecycleApplication> to Application User <DOMAIN.GLOBAL/GLOBAL/Gliwice/Users-Unsorted/SharePointEnterprise-ApplicationAccount>.
Assigning role <Legal Hold> to Application User <DOMAIN.GLOBAL/GLOBAL/Gliwice/Users-Unsorted/SharePointEnterprise-ApplicationAccount>.

Creating Partner Application <SharePointEnterprise-8b1f06018ad64178ad1f578ea4f346fb> using metadata <https://sharepoint.evotec.pl/_layouts/15/metadata/json/1> with linked account <DOMAIN.GLOBAL/GLOBAL/Gliwice/Users-Unsorted/SharePointEnterprise-ApplicationAccount>.
Created Partner Application <SharePointEnterprise-8b1f06018ad64178ad1f578ea4f346fb>.
THE CONFIGURATION HAS SUCCEEDED.

You can even verify if it registred properly

[PS] C:\Program Files\Microsoft\Exchange Server\V15\Scripts>Get-PartnerApplication

Name                                                        ApplicationIdentifier
----                                                        ---------------------
Exchange Online                                             00000002-0000-0ff1-ce00-000000000000
SharePointEnterprise-8b1f06018ad64178ad1f578ea4f346fb       00000003-0000-0ff1-ce00-000000000000

So while at this moment Exchange administrator is fairly happy there's actually one more thing to verify that most people forget – certificates.

If it's a wrong certificate you will most likely get very general error like below:

And if you run it on the Exchange 2013 server itself (or do the suggested web.config change):

Full text error will look something like this:

Server Error in ‘/Autodiscover' Application.
Could not find any resources appropriate for the specified culture or the neutral culture. Make sure “Microsoft.Exchange.HttpProxy.Strings.resources” was correctly embedded or linked into assembly “Microsoft.Exchange.FrontEndHttpProxy” at compile time, or that all the satellite assemblies required are loadable and fully signed.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Resources.MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure “Microsoft.Exchange.HttpProxy.Strings.resources” was correctly embedded or linked into assembly “Microsoft.Exchange.FrontEndHttpProxy” at compile time, or that all the satellite assemblies required are loadable and fully signed.

Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture.  Make sure “Microsoft.Exchange.HttpProxy.Strings.resources” was correctly embedded or linked into assembly “Microsoft.Exchange.FrontEndHttpProxy” at compile time, or that all the satellite assemblies required are loadable and fully signed.]

System.Resources.ManifestBasedResourceGroveler.HandleResourceStreamMissing(String fileName) +5454890

System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark) +1173

System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark) +809

System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents) +35

System.Resources.ResourceManager.GetString(String name, CultureInfo culture) +572

Microsoft.Exchange.Data.Common.ExchangeResourceManager.GetStringInternal(String name, CultureInfo culture) +92

Microsoft.Exchange.Data.Common.ExchangeResourceManager.GetString(String name, CultureInfo culture) +179

Microsoft.Exchange.Data.Common.LocalizedString.System.IFormattable.ToString(String format, IFormatProvider formatProvider) +204

Microsoft.Exchange.HttpProxy.AuthMetadataHttpHandler.ReportBuilderException(HttpResponse response, AuthMetadataBuilderException ex, Boolean logCallStack, HttpStatusCode httpStatusCode, Nullable`1 overridingError) +1700

Microsoft.Exchange.HttpProxy.AuthMetadataHttpHandler.HandleBuilderExceptions(HttpResponse response, AuthMetadataBuilderException ex) +723

Microsoft.Exchange.HttpProxy.AuthMetadataHttpHandler.InternalProcessRequest(HttpContext context) +579

Microsoft.Exchange.HttpProxy.AuthMetadataHttpHandler.ProcessRequest(HttpContext context) +455

System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +913

System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +165

Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.34248

As you may imagine it doesn't actually tell much information what's going on.

Solution

To fix the error you simply check current certificate

Get-authConfig | fl *Certificate*

CurrentCertificateThumbprint  : 445C52F5D260233FBE7EFD49044749BD72E99C71
PreviousCertificateThumbprint : 
NextCertificateThumbprint     :
NextCertificateEffectiveDate  :

You compare it with proper certificate installed on Exchange server for your OWA or other services

[PS] C:\>Get-ExchangeCertificate | ft Thumbprint, Status, Services -a

Thumbprint                                               Status  Services
----------                                               ------  --------
76F45F21ADB630FA8257EF520297144423253DCD RevocationCheckFailure IMAP, POP
27176174AAC97E11C19CA3079028B7D630E56A10 RevocationCheckFailure IMAP, POP
0EFBA9399F2D1BC978B9761A19002806CC823778                  Valid IIS, SMTP

And then you simply use the Valid Thumbprint

Set-AuthConfig -NewCertificateThumbprint 0efba9399f2d1bc978b9761a19002806cc823778 -NewCertificateEffectiveDate "2015-06-14 14:50"

Confirm
The new certificate effective date is not at least "48" hours in the future and may not be deployed on all necessary servers. 
Do you wish to continue?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Since I wanted it to happen pretty fast I set it 5 minutes ahead, but for larger environments you may want to set something higher into the future. After you confirm the change, you just need one final step

Set-AuthConfig -PublishCertificate

And you're done. When the right time comes, everything should start working now. You can also verify the change did happen and your certificate was replaced

[PS] C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Autodiscover>Get-authConfig | fl *Certificate*

CurrentCertificateThumbprint  : 0efba9399f2d1bc978b9761a19002806cc823778
PreviousCertificateThumbprint : 445C52F5D260233FBE7EFD49044749BD72E99C71
NextCertificateThumbprint     :
NextCertificateEffectiveDate  :

This post was last modified on March 20, 2016 12:24

Przemyslaw Klys

System Architect with over 14 years of experience in the IT field. Skilled, among others, in Active Directory, Microsoft Exchange and Office 365. Profoundly interested in PowerShell. Software geek.

Share
Published by
Przemyslaw Klys

Recent Posts

Upgrade Azure Active Directory Connect fails with unexpected error

Today, I made the decision to upgrade my test environment and update the version of…

2 months ago

Mastering Active Directory Hygiene: Automating Stale Computer Cleanup with CleanupMonster

Have you ever looked at your Active Directory and wondered, "Why do I still have…

3 months ago

Active Directory Replication Summary to your Email or Microsoft Teams

Active Directory replication is a critical process that ensures the consistent and up-to-date state of…

7 months ago

Syncing Global Address List (GAL) to personal contacts and between Office 365 tenants with PowerShell

Hey there! Today, I wanted to introduce you to one of the small but excellent…

12 months ago

Active Directory Health Check using Microsoft Entra Connect Health Service

Active Directory (AD) is crucial in managing identities and resources within an organization. Ensuring its…

1 year ago

Seamless HTML Report Creation: Harness the Power of Markdown with PSWriteHTML PowerShell Module

In today's digital age, the ability to create compelling and informative HTML reports and documents…

1 year ago