Enabling Lync and Skype for Business for Integration with Exchange 2013/2016.
I want to call your attention to an issue with Lync and Exchange Open Standards for Authentication (called oath from here forward). I have discovered a few things about Oauth, That might be a topic of confusion for many.
It will be very common for most to jump right into articles such as the following.
In addition, there are several modes you can install Oauth. You can focus on Server to Server, Cross Premise, and On premise partner. This leaves open the possibility of going down all kinds of fox holes. Therefore, I am going to try to layout the simple steps you are trying to accomplish when you do a Lync to Exchange Integration.
So when it comes to Oauth and Lync with Exchange, we are basically connecting two Enterprise applications. We are not connecting Autodiscover, EWS and other virtual directories, like we are doing with an Office 365 Integration. Therefore, Test-Oauthconnectivity. Will not work the same way.
If you have a concern or do not understand this, please compare the two articles in this paragraph. Notice, The Exchange online integration makes use of the Test-OauthConnectivity article. Notice the Lync/Exchange Oauth Article does not.
The bottom line is test-OauthConnectivity is not the way to test to verify that Lync and Exchange are correctly using Oauth correctly. I present below, the basis for doing the Lync Exchange Integration.
The Lync/Exchange Integration Is a partner application authentication. What this means to me, is the two applications have objects in AD that clear the servers to be able to talk to one another. This is independent of the IIS virtual Directories. The confusion is due to the Office 365 integration or Hybridization is becoming popular. The documentation is very similar, and many documents speak of Oauth and Integration. Test-OauthConnectivity -EWS is the one of the common items you will see. However, you won’t see it in any Lync documentation where exchange is concerned.
I think Lync and Exchange communication is more simple then the Office 365 Integration.
Here is the basic documentation for performing the SFB/Exchange integration . You don’t see anything about test-OauthConfiguration. However, you will see something here:
Finally some light of day. What it says is
“For the Test-OAuthConnectivity cmdlet to succeed for other partner applications, you first need to create the partner application by using the
Basically you don’t use the command to test OAUTH if you have not generated the Partner Applications. Once you have created the partner Applications, You wont need Test-Oauth, because for OAuth to work, the Enterprise Applications will need to succeed to be created. They wont be created broken.
So… This leaves us with no way to test. Well That is not exactly true.
Pre-Integration testing of Lync and Exchange
So before you begin the Procedure for Lync and Exchange to integrate, All you need to do is set the Oauth Certificate on both EX and SFB servers. They both will have a URL that becomes active, once the Certificates have been set correctly, and the virtual directories have become operational. These Two URL’s become your evidence of configuration succeeding, going into the Oauth Integration.
These URL’s are literal substitutions for use by the opposing servers. You can see on the Lync side, the Lync application looks to the Exchange URL, as a direct value for the Json token it needs to authenticate:
Remember, the URL must work before you use it in a command. Now the second Enterprise application, From Exchange to Lync:
I have some other articles on Oauth Which you may find helpful. Pease stay awhile and look around:
- Blank Oauth Token Issuer
- Easy Way to See if Lync and Exchange Oauth is working
- How to Fix Oauth if it is broken
- Setup Lync UM integration, Including Oauth
The last link above really goes into elements of a Full setup. But the goal is to get to steps 13 and 14, which is to get the JSON urls working. Once those are working you can execute your enterprise application commands, like the screen shots above, or the steps I provide at the end of the article. However, you must first verify the URL for your Oath is working. Just put it into a browser as follows:
Finally, Run your command on the Exchange and Lync or Skype for Business servers:
- Configure-EnterprisePartnerApplication.ps1 –AuthMetadataUrl “https://lyncFEpool.domain.com/metadata/json/1” -ApplicationType Lync
- Remove-EnterprisePartnerApplication.ps1 –AuthMetadataUrl “https://lyncFEpool.domain.com/metadata/json/1” -ApplicationType Lync
As long as you stay with configure or remove, you wont need anything else. Back out of the configuration and start over with configure, if you made any mistake.
Skype For Business
- Get-CsCertificate –Type OauthIssuer
- Set-CsPartnerApplication -Identity Microsoft.Exchange -ApplicationTrustLevel Full –MetadataUrl https://mail..domain.com/autodiscover/metadata/json/1
- New-CsPartnerApplication -identity Microsoft.Exchange -ApplicationTrustLevel Full -MetadataUrl https://mail.domain.com/autodiscover/metadata/json/1
With Skype for business, there are a few eventualities, but essentially as long as the commands succeed, you will be in business.
One Last Thing
One Last thing. If for some reason you find that the Exchange or Lync Oauth token does not work when you try to use the URL for the Json token, the consensus is the only thing you can really do to repair this (It should not ever be broken, perhaps you need to re cert the Oauth Cert), is to repair the virtual Directories. I have a Friend who is an Exchange Engineer, who has a great blog where this is laid our here. John Alec Dixon is a better Exchange Engineer then I ever was a Lync Engineer. He found the issue. The Front end Virtual Directory path. Its not something we cross check often. Yes this can be incorrect.
In addition, You should check this article out if you need to repair your virtual Directories:
Finally one point which provoked this article. I had one case in my life, where the Oath URL did not work. Non of the above was applicable to fixing it. This turned out to be a simple patch mismatch. There is no warning, or event which will tell you this. You just get a 404 IE error. The fix
a. Launch IIS Manager
b. Expand Default Web Site
c. Select Autodiscover vDir
d. Click Advanced Settings under Manage Application
e. Change physical path to:
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\Autodiscover
I hope this helps