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:
New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName “cn= Microsoft Exchange Server Auth Certificate” -FriendlyName “Microsoft Exchange Server Auth Certificate” -Services smtp
- Do not accept to replace the SMTP certificate when prompted
- Note the thumbprint of the new certificate. Let us assume it is 7A39541F8DF58D4821967DD8F899B27410F7C081
Set-AuthConfig -NewCertificateThumbprint 7A39541F8DF58D4821967DD8F899B27410F7C081 –NewCertificateEffectiveDate $a
- Accept to continue despite the fact that the certificate effective date is not 48 hours into the future
- Set-AuthConfig –PublishCertificate
- Make sure to remove any potential reference to the previous certificate (which might not exist anymore) by doing Set-AuthConfig -ClearPreviousCertificate.
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)