

Get-clientaccessserver | fl fqdn, autodiscoverserviceinternaluriĪlso lets take on the Lync side and get the pool FQDN: An internal CA is fine (we’re using this in our test environment), third party is even better, but the self-signed will not be able to communicate because it’s missing the necessary subject names.įirst let’s get the autodiscover service URI: As part of the installation of Lync 2013 you had to install SSL certificates to start the services, however for Exchange you’ll want to make sure you’re not using the self-signed certificates. This will be any admin’s friend in pushing out set groups of contacts 🙂įirst, the foundation of communication between Exchange and Lync 2013 is based on the new Office Web App “OAuth” calls for server-to-server communication. This means that you don’t have to maintain a separate set of contact from Exchange, which was somewhat frustrating and cumbersome. That was half the battle in 2010, because if you didn’t have the correct version of the patches, or didn’t install them in the right order, things would fail.Īlong with OWA integration, Lync now supports a Unified Contact Store (UCS), which was somewhat hinted to in 2010 but didn’t come to fruition until 2013. I had previously written an article on how to integrate Exchange/Lync 2010 for IM capability via OWA, and now that Exchange/Lync 2013 have been released, Microsoft has maintained the compatibility but thankfully with an easier-to-achieve process.īecause of the Unified Communications Managed API (UCMA) 4.0 requirement on Exchange 2013 for the integrated UM role, both platforms have a similar set of prerequisite requirement. With some troubleshooting I have it working, and you’ll find updates scattered throughout this article.

Set-OrganizationConfig -MapiHttpEnabled $trueĪnd do the test from the outside of your company with this:Īutodiscover works with 4 methods, so it should be the or "autodiscover" record in public dns.Update – Two and half years after the original post and finally some updates! I have had a chance to fully patch my environment to the latest updates for Exchange and Lync 2013. Get-MapiVirtualDirectory | Set-MapiVirtualDirectory –ExternalURL Get-OutlookAnywhere | Set-OutlookAnywhere –ExternalHostname –ExternalClientsRequireSsl $true Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –ExternalURL To make sure that all internals and externals url are good do the following, change the url to the one in your company: Get-OabVirtualDirectory | Set-OabVirtualDirectory –ExternalURL

Please Check and be sure that the certificate in the Front end is the same certificate that uses the Back end, in IIS for the exchange site (Default) on all exchange servers. Yes, When you select the change of the certificate usually makes the change in the front end of the ECP in IIS.
