One of the steps in creating OAuth integration between Lync Server 2013 and Exchange Server 2013 is to create a New-CsPartnerApplication on Lync 2013 referencing the OAuth metadata document from Exchange 2013 (http://technet.microsoft.com/en-us/library/jj688151.aspx):
New-CsPartnerApplication -Identity Exchange -ApplicationTrustLevel Full -MetadataUrl "https://autodiscover.litwareinc.com/autodiscover/metadata/json/1"
When running this cmdlet you might get the error "New-CsPartnerApplication: Cannot bind parameter 'MetadataUrl' to the target. Exception setting "MetadataUrl": "The metadata document could not be downloaded from the URL in the MetadataUrl parameter or downloaded data is not a valid metadata document, error: The remote server returned an error: (500) Internal Server Error."
When you look in the IIS log on the CAS server you will see a corresponding entry similar to this "2012-11-20 14:03:57 192.168.200.40 GET /autodiscover/metadata/json/1 - 443 - 192.168.200.35 - 500 0 0 265".
I have seen this in a couple of cases and the common root cause has been that the "Microsoft Exchange Server Auth Certificate" has been missing from Local Computer\Personal certificate store.
The "Microsoft Exchange Server Auth Certificate" certificate is used by the OAuth implementation on Exchange 2013. You can see it referenced in the output of Get-AuthConfig:
RunspaceId : b7de8683-bd90-4e24-a78f-d6933871cd48
CurrentCertificateThumbprint : A33E4C629AE9553E186F93474E796D598B1F7424
ServiceName : 00000002-0000-0ff1-ce00-000000000000
Name : Auth Configuration
The certificate with CurrentcertificateThumbprint needs to be listed, when you do Get-ExchangeCertificate on the Exchange 2013 servers. If it is not, there you will see the problem with Internal Server Error.
The fix is to create a new "Microsoft Exchange Server Auth Certificate" by using the following sequence of cmdlets In EMS on the MBX server:
Remember to do iisreset on both CAS and MBX servers. Then finally, you can try to re-issue the New-CsPartnerApplication cmdlet.
Update: Jan 15. 2013: Matt reported that he had to add a step, 6) Set-AuthConfig –clearpreviouscertificate, to get it to work in his lab.
I had an Exchange 2013 All-In-One server. The OS drives failed and I had to rebuild it. The database drives were all in tact and OK.
After the rebuild, I tried to integrate Lync and received this error. When I try to create the cert as specified in step 1, I receive the following:
New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $True -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -Services smtp
A special Rpc error occurs on server EXCHANGE2013: You must specify at least one valid fully qualified domain name
(FQDN) for either the Subject or the DomainName parameter.
+ CategoryInfo : InvalidArgument: (:) [New-ExchangeCertificate], InvalidOperationException
+ FullyQualifiedErrorId : 59ABB4F7,Microsoft.Exchange.Management.SystemConfigurationTasks.NewExchangeCertificate
+ PSComputerName : exchange2013.domain.local
Not sure how to get past this.
Jens>You could try specifying -DomainName parameter to be the fqdn of the server.
If you allready have a certificate that contains autodiscover.yourdomain.com as a SAN you can also use this one. Simple start at 3.
I encountered the same problem, I did follow your steps but still cannot make it work. When browse the virtual directory of "Autodiscover" site on Exchange server IIS manager, I notice that there is no "metadata/json" folder. Is it the problem? How can I fix it? Thanks
Jens>You won't see that folder in IIS, that's by design.
Most of us have multiple Exchange servers in the organization. Note that when you perform step 4 with Set-AuthConfig, it replaces the thumbprint in the AuthConfig with the thumbprint of the newly installed certificate. This is expected, but since AuthConfig seems to be a global configuration setting, this will lead to a mismatch between the thumbprint in AuthConfig and the thumbprint of the Exchange Server Auth certificate on all other Exchange servers, which is even a bigger problem.
In this case, in order to fix the issue with the missing Exchange Server Auth certificate, instead of generating the new certificate, it's better to export the certificate from one of the other servers and import onto the server where it is missing. This will ensure that the same certificate with the same thumbprint is used on all Exchange servers, and that the same thumbprint also matches the AuthConfig settings.
Awesome! Worked like a charm Jens,
Step one should include -domainname as well :)
Yes, anybody with multiple exchange servers should follow Boris' suggestion and not this procedure.