Freigeben über

Getting Internal Server Error 500 when creating New-CsPartnerApplication for Exchange 2013

  • Artikel

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 (https://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:

Get-AuthConfig

RunspaceId : b7de8683-bd90-4e24-a78f-d6933871cd48

CurrentCertificateThumbprint : A33E4C629AE9553E186F93474E796D598B1F7424

PreviousCertificateThumbprint :

NextCertificateThumbprint :

NextCertificateEffectiveDate :

ServiceName : 00000002-0000-0ff1-ce00-000000000000

Realm :

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:

  1. New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn= Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -Services smtp
    1. Do not accept to replace the SMTP certificate when prompted
  2. Note the thumbprint of the new certificate. Let us assume it is 7A39541F8DF58D4821967DD8F899B27410F7C081
  3. $a=get-date
  4. Set-AuthConfig -NewCertificateThumbprint 7A39541F8DF58D4821967DD8F899B27410F7C081 –NewCertificateEffectiveDate $a
    1. Accept to continue despite the fact that the certificate effective date is not 48 hours into the future
  5. Set-AuthConfig –PublishCertificate
  6. 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) Set-AuthConfig –clearpreviouscertificate, to get it to work in his lab.

Comments

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    January 01, 2003
    Awesome! Worked like a charm Jens, Step one should include -domainname as well :)

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    April 29, 2013
    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.

  • Anonymous
    May 08, 2013
    If you allready have a certificate that contains autodiscover.yourdomain.com as a SAN you can also use this one. Simple start at 3.

  • Anonymous
    September 26, 2014
    Jens has a really good post over on his blog about an issue he faced trying to configure OAuth integration

  • Anonymous
    February 03, 2015
    Yes, anybody with multiple exchange servers should follow Boris' suggestion and not this procedure.

  • Anonymous
    March 31, 2015
    I faced the same issue, and your solution fixed it. Many thanks!

    By the way, I have two Exchange servers, and I typed the New-ExchangeCertificate cmdlet on SERVER1, and finished the steps, then went to SERVER2, and found the same certificate with the same thumbprint installed in the Personal Certificates folder. I didn't need to export/import as mentioned by Boris Lokhvitsky.

  • Anonymous
    August 17, 2015
    Thanks Jens!