Exchange 2013 Partner Applications and Error 2008

Posted on 2 CommentsPosted in Exchange Server, Lync Server, OAuth, Skype for Business Server

When Exchange Server 2013 is configured to connect to Lync / Skype for Business Server one of the steps is to create a partner application. When this is first run the partner application stores the certificate presented by Lync Server in the Active Directory configuration partition. If the certificate changes on the Lync Server then the Exchange Server will start to alert about this every 15 minutes with the following warning: MSExchange OAuth and Event ID 2008.

SNAGHTML31fc566d

To fix this error we need to update the Active Directory configuration where the metadata info is kept (CN=LyncEnterprise-guid,CN=Partner Applications,CN=Auth Configuration,CN=Exchange Organization Name,CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=domain,DC=co,DC=uk)

To do this you need to start Exchange Management Shell on Exchange 2013 and remove the Lync partner application. Immediately after you have done this you can create the partner application again. The cmdlets for this are as follows:

is the same as you used when you first created the partner application. This is as follows:

  1. In the Exchange Management Shell confirm you have one Lync partner application with Get-PartnerApplication | FL
  2. In the Exchange Management Shell run Remove-PartnerApplication Lync* and then confirm that you want to do this.
  3. In the Exchange Management Shell, change directory to the Exchange scripts folder with cd $exscripts
  4. Then run the script to configure a new partner application. An example would be .\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl ‘https://lyncSrv.domain.co.uk/metadata/json/1’ -ApplicationType Lync where the URL points to the Lync server and contains a valid name for the certificate on the Lync Server.

This should return the following and report that the configuration has succeeded.

SNAGHTML32094ac5

Your 2008 repeating errors in the Event Viewer will now be gone.

Exchange Online Free/Busy Issues with OAuth Authentication

Posted on Leave a commentPosted in 2010, 2013, EWS, exchange, exchange online, Free/Busy, OAuth, Office 365

Update: 10 Dec 2014: It is reported that this issue is fixed in CU7 for Exchange Server 2013

OAuth authentication is a new server to server authentication model available in Exchange 2013 SP1 and later and Exchange Online (Office 365). With OAuth enabled and Exchange hybrid in place and where you have multiple endpoints of Exchange Server on-premises and those on-premises Exchange Servers are different versions then you might have issues getting Exchange Online to On-Premises free/busy lookups to work.

Here is the scenario:

Company with Exchange 2010 servers in multiple internet connected sites, going hybrid to Exchange Online.

Exchange Online tenant created and hybrid mode put in place between Exchange Online and Exchange Server 2013 on-premises. In the site where the Exchange 2013 hybrid servers are located there are Exchange 2010 SP3 servers. As hybrid mode was set up with SP1, OAuth was enabled.

Exchange 2010 in the remote sites is configured with an ExternalURL for EWS. Therefore a free/busy lookup from an Office 365 user to a mailbox in one of these remote sites goes direct to the EWS endpoint on Exchange 2010 – it is not proxied via the 2013 hybrid server.

With OAuth enabled this configuration will fail as Exchange Online will use OAuth to authenticate to Exchange 2010 on-premises and fail. The IIS logs will contain entries such as this:

2014-07-22 19:39:34 10.100.28.73 POST /ews/exchange.asmx – 443 – 10.100.28.220 ASProxy/CrossForest/EmailDomain//15.00.0985.008 401 0 0 0

Where the 401 indicates authentication failed and the path ASProxy/CrossForest/EmailDomain indicating OAuth in use. There will be no entries in the IIS log for the Federation Org type of authentication.

If the EWS connection for free/busy goes via the 2013 hybrid server (ExternalURL for the remote site is null) then the free/busy lookup works, or if the OAuth connector in Exchange Online is disabled (Get-IntraOrganizationConnector | Set-IntraOrganizationConnector -Enabled $false from Exchange Online remote PowerShell session) and EWS lookup for free/busy goes direct to the remote Exchange 2010 server then free/busy lookups work.

So if you want OAuth and direct EWS connections to remote sites for free/busy you need Exchange 2013 at those remote sites. If you want to have Exchange 2013 hybrid servers only at your primary site (for mail flow) and OAuth as well (for eDiscovery cross-forest) then you need to proxy your EWS free/busy requests via the Exchange 2013 hybrid server.

This is a known issue in Exchange and may be fixed in the future.