Artykuł

Integracja Exchange 2013 z SharePoint nie działa

Integracja Microsoft Exchange 2013 z SharePoint 2013 na pierwszy rzut oka wydaje się dość prosta. Postępuj według instrukcji znajdującej się Configure site mailboxes in SharePoint Server 2013 i wszystko gotowe. Jak to jednak często bywa, nie zawsze jest tak łatwo.

Opis problemu

Do przeprowadzenia integracji Exchange 2013 z SharePoint administrator Exchange musi uruchomić tylko jedno polecenie:

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

Wygląda to dość prosto i nie wyświetlają się żadne błędy:

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

Możesz nawet sprawdzić poprawność wykonania integracji wpisując:

[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

W tym momencie administrator Exchange ma już prawie wszystko gotowe. Zostaje jeszcze do sprawdzenia tylko jedna rzecz, o której wielu ludzi zapomina, a mianowicie…certyfikaty.

Jeśli certyfikat jest niepoprawny, to prawdopodobnie zobaczysz błąd podobny do tego:

SharePoint-2013-IntegrationWithExchange2013-Error1

A jeśli wykonasz sprawdzenie bezpośrednio z serwera Exchange 2013 (lub wprowadzisz sugerowaną zmianę dla konfiguracji w pliku web.config) otrzymasz dużo bardziej obszerny kod błędu:

SharePoint-2013-IntegrationWithExchange2013-Error2

Pełny treść błędu wyglądać mniej więcej tak:

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, Dictionary2 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, Nullable1 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

Niestety nie mówi on zbyt wiele o tym, co się dzieje i jak to naprawić.

Rozwiązanie

By naprawić ten błąd wystarczy po prostu sprawdzić aktualny certyfikat:

Get-authConfig | fl *Certificate*

CurrentCertificateThumbprint  : 445C52F5D260233FBE7EFD49044749BD72E99C71
PreviousCertificateThumbprint : 
NextCertificateThumbprint     :
NextCertificateEffectiveDate  :

A następnie porównać ten certyfikat z zainstalowanym certyfikatem dla usług dostępnych na serwerze Exchange (OWA, ECP itp.)

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

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

By w kolejnym kroku ustawić prawidłowy „odcisk palca” certyfikatu, tak by był on identyczny z dostępnym na serwerze.

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

Jednym z parametrów komendy jest data obowiązywania certyfikatu. Chcąc zakończyć proces szybko i sprawnie ustawienie certyfikatu na 5 minut do przodu powinno wystarczyć. Przy większych środowiskach nalezy ustawić większy czas zwłoki.

Po uruchomieniu komendy nalezy wykonać ostatni krok i opublikować nowy certyfikat:

Set-AuthConfig -PublishCertificate

I to wszystko. Kiedy nadejdzie ustawiony moment obowiązywania certyfikatu wszystko powinno zaczać działać.

By zweryfikować finalnie czy certyfikat został podmieniony należy wykonać następującą komendę powershellową:

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

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

This is a unique website which will require a more modern browser to work! Please upgrade today!