Integrating Exchange 2013 + Lync 2013 for UCS & OWA integration

By Chris Blackburn

Update 7/13/2015 – 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. With some troubleshooting I have it working, and you’ll find updates scattered throughout this article.

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.

Because 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. 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.

Along 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. This means that you don’t have to maintain a separate set of contact from Exchange, which was somewhat frustrating and cumbersome. This will be any admin’s friend in pushing out set groups of contacts ūüôā

OK so enough blabbering, let’s dig in:

First, the foundation of communication between Exchange and Lync 2013 is based on the new Office Web App “OAuth” calls for server-to-server communication. 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. 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.

First let’s get the autodiscover service URI:

get-clientaccessserver | fl fqdn, autodiscoverserviceinternaluri

Fqdn                           :
AutoDiscoverServiceInternalUri :

Also lets take on the Lync side and get the pool FQDN:

PS C:\Users\administrator.COMPANY> Get-Cspool | where-object {$ ‚Äďlike “*UserServer*”} | fl site, fqdn

Site : Site:ConnectUC
Fqdn :

Since we’re using internally signed certificates, we’ll want to try accessing these URLs from both the Lync and Exchange servers, and ensure we can open them via IE without any certificate warnings.

On the Exchange 2013 environment, we link up to Lync:

cd $exscripts
.\Configure-EnterprisePartnerApplication.ps1 ‚ÄďAuthMetadataUrl ‚Äú‚ÄĚ -ApplicationType Lync


Now let’s update Exchange to enable IM!

The process isn’t that different from Exchange 2010, except I’ve noticed that Exchange 2013 holds on to an internal self-signed certificate so we can’t blindly use a wildcard to pipe the certificate like we did before. We need to determine which thumbprint to use by looking at the Subject name and Issuer.

Update 7/13/15 Update – If you don’t have a SAN certificate with your server names,¬†I highly recommend¬†requesting a dedicated certificate from an internal PKI with the subnet name in it. As long as it’s trusted internally by all (Exchange & Lync) servers, it will serve the purpose!

Get-ExchangeCertificate | where-object {$ -like “*iis*” } | fl subject, issuer, services, thumbprint

Subject    :, OU=Connect UC, O=IT, L=Minneapolis, S=MN, C=US
Issuer     : CN=cloud-CIRRUS-CA, DC=cloud, DC=local
Services   : IMAP, POP, IIS, SMTP
Thumbprint : 5FB91CB7AB7677EF45B5C809CF8CB9CFDB31D0A1

Subject    : CN=VL-EXG-01
Issuer     : CN=VL-EXG-01
Services   : IIS, SMTP
Thumbprint : 86F218D2E3AF6D98422F18E1217C101BBC0F000B

Now that we have the thumbprint, and we know our Lync pool FQDN, let’s plug it in.

7/13/2015 Update –¬†I’ve implemented the FREE Kemp¬†virtual LoadMaster for my Lync 2013 May 2015 update and Exchange 2013 CU9¬†servers,¬†but it doesn’t change the process that much. Make sure you have a valid local certificate that’s trusted & everything should work OK.

When we enable Lync IM for Exchange, we only want to target the FRONT END servers. Thanks to Varol for pointing out that Microsoft tells us that IM is “NOT” enabled on the BACK END servers. So we’ve removed the -ShowBackendVirtualDirectories switch.

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingEnabled $true -InstantMessagingType OCS -InstantMessagingCertificateThumbprint 5FB91CB7AB7677EF45B5C809CF8CB9CFDB31D0A1 ‚ÄďInstantMessagingServerName

Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -InstantMessagingEnabled $true ‚ÄďInstantMessagingType OCS

Next, let’s change the OWA web.config information. Use Notepad to open the following files
7/13/2015 Update -You’ll need to reconfigure the web.config with each Cumulative Updates you run!

Notepad ‚ÄúC:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\web.config‚ÄĚ

Under <appSettings> add 2 lines, substituting your Exchange certificate thumbprint (which we already obtained) and the Lync pool name:

<add key=”IMCertificateThumbprint” value=”5FB91CB7AB7677EF45B5C809CF8CB9CFDB31D0A1” />
<add key=”IMServerName” value=”” />

Then recycle the related IIS pool

C:\Windows\System32\Inetsrv\Appcmd.exe recycle apppool¬† /”MSExchangeOWAAppPool”

Then over on the Lync side, we have a few commands to run in order to integrate with Exchange.

First, we create a Partner Application:

New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl

7/13/2015 Update – With Lync 2013 May 2015 update and Exchange 2013 CU9 update¬†I didn’t actually find my environment start working until I¬†ran the commands below to clear out the existing pools. I was actually able to LEAVE THEM REMOVED and then IM worked.

Get-CsTrustedApplicationPool | Remove-CsTrustedApplicationPool

Get-CsTrustedApplication | Remove-CsTrustedApplication


Using the Lync 2013 Centralized Logging Tool I discovered some SIPPROXY_E_CONNECTION_UNKNOWN_SERVER entries from my Exchange server, despite my Trusted Applications being for the NLB VIP DNS record. This tells us¬†the calls are made directly from the Exchange server hosting the OWA session. And even when I logged into OWA using the server FQDN (that wasn’t a Subject Name in my Certificate and threw a certificate error) IM still worked.

I’m going to keep an eye on this to see if maybe the New-CsPartnerApplication alone facilitates connectivity to Exchange.

7/13/2015 Update – If IM still¬†doesn’t work, use the commands above to remove them!! Next we create our trusted application pool/application. We’ll want to use the individual server names themselves (and make sure we have the corresponding SSL certificate in the web.config with a subject name matching the server FQDN).

New-CsTrustedApplicationPool -Identity -Registrar -Site ConnectUC -RequiresReplication $False

New-CsTrustedApplication -ApplicationId OutlookWebAccess -TrustedApplicationPoolFqdn -Port 5199


Next, we can enable our User accounts in Lync

If all went successfully, let’s log into OWA and click to Sign in to IM

And success!

43 Comments Leave a comment

  1. HI

    Let me start by saying Great tutorial.

    I have followed this step-by step, and everything went fine untill i tried to login to OWA i am now getting this error

    HTTP Error 500.19 – Internal Server Error

    Error Code : 0x8007000d

    Config error : Configuration file is not well known XML

    Config file : \\?\C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa\web.config

    Requested URL : https://.com:444/owa/

    Config Source :



    173: <add key=‚ÄĚIMServerName‚ÄĚ value=‚ÄĚ

    Wonder if you know what i have done wrong.
    OS : Server 2008 R2
    Exch : 2013
    Lync : 2013
    Browser : IE, Firefox and Chrome


    • It appears the copy and paste from the article may not have played well, because of the unicode character differences.
      Try replacing all of the quotation marks and brackets around the code, and resave then try again.

  2. Excellent post … followed it in my Exchange 2013 and Lync 2013 lab and all works perfectly. Nice one!

  3. Has Exchange CU1 changed how this works? I followed this great guide and everything worked fine. Then after upgrading Exchange 2013 to CU1, Lync no longer shows in the OWA web page. Just quickly flashes up the box and then its gone. Tried removing the intergration and tried installing that again and still no joy. (Yes I did check the web.config as I read it was overwritten on a CU1 upgrade)
    As this setup I done was still recent, I decided to do a brand new install from the CU1 version and when trying to follow this guide it spits out “A parameter cannot be found that matches parameter name ‘ShowBackEndVirtualDirectories'” So I assume this “-ShowBackEndVirtualDirectories” is now no longer used.
    I read someone where that to get Lync to intergrate now you must also use a new command , but the blog that said that did not say what the command was…

    Any ideas anyone on how to get this to work again?
    Or maybe Chris can update this site with the new procedure for Exchange CU1?

    Many thanks

    • I’m not sure if something changed in CU1 or CU2, but the configuration of the OWA virtual directories is not consistent with Microsoft’s recommendations. The “Get-OwaVirtualDirectory -ShowBackEndVirtualDirectories -Server [server] | Where { $_.WebSite -eq ‚ÄėExchange Back End‚Äô } | Set-OwaVirtualDirectory” cmdlet enables IM integration only on the OWA back-end virtual directory; per Microsoft (, “There is no need to enable instant messaging for the virtual directories on your backend servers. In fact, it is recommended that you do not enable instant messaging on your backend servers”. The correct cmdlet is “Get-OwaVirtualDirectory -Server [server] | Set-OwaVirtualDirectory”, which will only apply the changes to the front-end virtual directory. After making this change in our environment, we were able to get Lync-OWA integration working again. Hope this helps.

  4. Actually needed to use the command “Get-OwaVirtualDirectory | Set-OwaVirtualDirectory ‚ÄďInstantMessagingEnabled
    $True -InstantMessagingType OCS” and Lync in OWA working now in CU1..

  5. This worked wonderfully with a few exceptions,

    1) Look out for those quotes (“), copying and pasting the part for the owa config from the site won’t work because of the formatting, so change this


    Notice the subtle differences in the way the quotes look.

    2)Ignore the create application command

    New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl

    Not sure if its a version thing, but i’m on the most updated version of Lync 2013 as of this writing and it didnt work.

    Other than that the guide is spot on and works great..looking for to more =D

    Does anyone know if i can get one for sharepoint 2013 and lync 2013 integration guide?

    • Chris Blackburn May 31, 2013 at 1:51 pm Reply

      Raymond, this was written right after RTM and with CU updates it requires the base install first so it shouldn’t be any different. Are you getting an error of a command missing or does it fail with a more specific error?
      Still working on the Exchange/Sharepoint integration guide, specifically focusing on integration for eDiscovery!

  6. Thanx for this tutorial. And thanx Graham Cooper for the update!

  7. Thanks for the great post. I just have 1 question;

    It’s unclear of the exchange side should be done against the CAS role or Mailbox roll. This might sound like a silly question, but everything I have read says that the CAS doesn’t do a whole lot of work and all rendering is done at the mailbox. However, autodiscover (used in the process above) is on the CAS. The cert that I got back from get-exchangecert is for the mailbox role, and the only server that seems to have web.config is the mailbox.

    So I’m confused as to which server each of the exchange commanders should be run on. And in the same, the lync app pools should point to cas or the mailbox?

    Every post I read on the subject seems to assume that the user knows this and doesn’t really spell it out.

    Thanks in advance for any help.

  8. Chris Blackburn May 31, 2013 at 1:37 pm Reply

    David – the location of the OWA virtual directory is on the CAS server, so you’ll want to point to either that server name OR to the DNS name you have your load balanced VIP setup on.

    Same concept for the configuration in Lync: since we are setting up a trusted application against OWA, you’ll want to point to either that server name OR to the DNS name you have your load balanced VIP setup on.

    Great question – hope this makes sense!

  9. The problem is that when you setup a separate CAS server the web.config is not where you say it is.

    It is not in C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\

    That only contains the following folders:

    The actual Web.config is in C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\

    This means that this configuration might not work when you break things out into separate CAS and Mailbox roles. It certainly does not work with this and a DAG. I have built and rebuilt this about 5 times and still get a failure when singing into IM from OWA 2013.

    Any thoughts in this? Microsoft does not seem to have anything on configuring this with a DAG and Load balanced CAS servers…

    • Hi Sean,

      When you setup the Trusted Application Pool, instead of using the name of your single Exchange server did you use the CAS array FQDN? Lync will try and pass the request to the CAS array, and if you point it to the DNS name of your CAS array, it should be able to communicate to the respective backend with the remaining configuration changes made.
      Thanks for the update on the config with the separate Front/Backend roles. I need to expand out my lab to give this a shot ūüôā

  10. Marius M√łnsted July 18, 2013 at 7:10 am Reply


    The last commands, new-cstrustedapplicationpool -identity xxxx

    we use a hardware loadbalancer witch has its dns name but not an active directory object. i get error “Machine xxx from the topolgy you are publishing was not found i AD and wil result in erros during enable-cstopology …etc..”

    what should we do? just make a AD object of xxxx?

    • Hi Marius,

      The rule of thumb for HLBs would be to enter in the DNS name of your CAS array (like

      If you want to manually add your HLB into the topology, go under Trusted Application Servers and add a Single Computer Pool. Since the HLB is the pool itself, there’s no need to have a Multiple Computer Pool unless you want to add in each Exchange server. I was able to add in a dummy server name with no problems. Just be sure the entry exists in DNS and you should be fine.

  11. Marius M√łnsted July 18, 2013 at 11:47 pm Reply

    Thank you for a well written article, one of few good ones!

    I used my internal dns name of the HLB and enabling cs-topology gave no error so I guess it’s ok. I’m migrating a multi tenant Exchange 2007 to 2013 at the same time so no users reside on 2013 yet so I can’t check OWA if your tourturial has worked for me yet.

    Since we use Ex2013 we don’t have a CAS array, just the HLB, thats why I used the DNS name.

  12. Very nice and great Article.

  13. in regards to this command:
    ew-CsTrustedApplicationPool -Identity -Registrar -Site ConnectUC -RequiresReplication $False

    what do we put for ConnectUC?? what does this mean??

    • You’ll want to substitute the values in -Identity for your Exchange server/CAS array, -Registrar for your Lync Front End pool, and -Site for your Lync site name. To get your Lync site name use the command Get-CsSite

      • Was there a reply to the statement from Sean Kalinch

        “This means that this configuration might not work when you break things out into separate CAS and Mailbox roles. It certainly does not work with this and a DAG. I have built and rebuilt this about 5 times and still get a failure when signing into IM from OWA 2013.”

        we are experiencing problems with two Dags where we are not seeing any presence in OWA. any suggestions on what to check.

        • Bob take a look at this Technet article for guidance:

          Since every environment is different, the best I can advise is reviewing your commands with the following guidance:

        • The Outlook Web App pool must be the same name that appears in the Subject Name and Subject Alternative Name (SAN) fields of the certificate that provides access to Outlook Web App
        • The Lync Server 2013 pool must be the fully qualified domain name that will host the new trusted application pool
        • If both of those fail, you would want to run a Lync Logging session and determine what log files are being thrown that prevent the connection.

  • George Roubchinsky April 2, 2014 at 8:55 am Reply

    People, I have done this exactly integration more
    than 20-30 times on all versions of both, 2010 and 2013, and look:

    now, I am deadly, completely stuck on clean setup of Exchange Server 2013 SERVICE PACK 1. Lync Server is 2013 CU5. The commands test-CsEx* are Ok. UM integration is all Ok. CsPartnerApplication, CsTrustedApplication[Pool/Application/Computer] – ALL entities are there. On Exchange side: I have CAS collocated with MBX, Web.Config is Ok, Get/Set-OwaVirtualDirectory is Ok, Get/Set-OwaMailboxPolicy is Ok. Certificates are both mutually Ok, for sure otherwise UM/VoiceMail would not work as well.

    ALL other Lync+Exchange integration works fine.
    Did not use UCS too much but at least all the
    Pre-Req’s are fine.

    And I have NO ANY (AT ALL) messages in Event Log on Exchange Server 2013 SP1, none of those “112” messages as well. No error messages on either Exchange and Lync.

    Any advise??

    • Hi George, If you’re not seeing anything in the error logs (which you may have to adjust to Maximum for Unified Messaging) on the Exchange side, the best next steps are to perform some Lync tracing to see which error messages you might be encountering. There’s some great blogs on Lync logging but by far my favorite is the Lync 2013 Centralised Logging Tool. Check it out and see what might be coming back!

  • George Roubchinsky April 3, 2014 at 5:13 am Reply

    Hi Chris.

    OK, I have 1 new: On Exchange Server 2013 SP1 yes
    I DO see Event Log message with Event ID 112, Exchange tells by this message that “IM Endpoint was initialized correctly” or something close to.

    So yes I see 112 message, and as said on Lync Server side I checked I have UCS is working fine, and ALL of the cmdlets Test-CsEx* such as for instance
    Test-CsEx-CsExStorageConnectivity work fine, and at the end I have UM integration working fine, for external users as well.

    So EXTREMELY suspicious on Exchange Server 2013 SP1. Because IF I would have any bit wrong with my certificates or anything wrong on LYNC Server side with Partner Application, Trusted Application Pool and Trusted Application – I would 10 times find it by those Test-… commands, UM VoiceMail scenarios etc.

    Sure I know how to trace ūüôā Decent LYNC
    logging – as usual textual SIP trace (Snooper) brings no any bit of something useful: IM-OWA integration is just not in SIP trace, SIP shows everything is fine.

    Finally I did implement it multiple times with not 100% of equal conditions except (and this DOES ring a bell, correct?) Service Pack 1 for Exchange Server 2013. I don’t think I could so easily forget something on Exchange side such as Web.Config etc., because did it before a lot… I mean OwaVirtualDirectory, OwaMailboxPolicy etc.

    Now checked with Wireshark! I only can see three transactions on TLSv2 and none of the other traffic between Front-End and CAS (filtered by IP addresses), the packets are: “TLS Client Hello”, “TLS Server Hello” and “TLS Encrypted Handshake Message”, but no data in packet body is readable somehow. And these three messages I am not sure how to interprete, I am not so “low-level” strong in all below SIP protocol, so not sure is there errors or not, but it says TLSv2 “hello” back and forth and “handshake” at least. No more relevant packets at all, only these 3.

    So big major hmmm… Anybody really did it on SP1 and Lync Server 2013 CU5, exactly in this combination and with decent split namespaces? (== all the servers and AD uses namespace.intranet.local and all the rest is public as usual, SIP Domain etc., About AutoDiscover, LyncDiscover etc. – goes without saying, ALL scenarious are tested including Lync Mobile, the IM-OWA is the only one from ALL scenarios which does not work, while it did before SP1.


  • I have 2 CAS and 2 Mailbox Servers of exchange 2013.
    One Frontend and one Edge for Lync.
    I tried all the steps written but IM is not enabled on OWa it gives the following error.

    “There is a problem with IM. Please try again later. If problem continues, please contact your helpdesk.”

    Please suggest

    • Make sure you do not perform the Set-OwaVirtualDirectory configuration on your Backend directories. I have updated the guide to account for this guidance!

  • Ok everything went smoothly above except for this command on the lync server:

    New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl

    Ok our autodiscover for exchange 2013 is lets say. But if I go in IE to that URL tacking on /autodiscover/metadata/json/1 there is no website there on exchange 2013’s IIS. So if you try to plug this command into powershell on the Lync 2013 server you get an 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: (404) Not Found.”

  • Hi,

    Followed all the steps everything went fine except the
    New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl
    command. At the end of the i can’t see the lync status and IM on the owa are not working.

    *** I can see the result of my commands in the lync control panel/topology.However the status .for the mail server and owa are N/A. Is it normal?

    Is there a way to debug the whole process?

    Any advise?

    Thank you

  • Test Lab Guide (with modifications): Configure an Integrated Exchange 2013, Lync 2013 and SharePoint 2013 Test Lab | A random blog from a sysadmin
  • Hi.
    I installed CU9 for Exchange 2013 (no issues with upgrade) but I’m unable to get the Lync integration working again. I’ve re-added the required lines to the web.config file but no luck. I’ve gone as far as removing and re-creating the components on Lync 2013 servers, but even that didn’t help.
    Have you upgraded your servers yet & have you had any issues?

    • I’ve updated the article to account for the Lync and Exchange server updates. The biggest thing I encountered was around removing the Trusted Application / Trusted Application Pool settings. It didn’t like it when I used my NLB VIP DNS entry since it couldn’t resolve back to the object in Active Directory.

      • Hi, I’m in the same boat. After CU9 update lost IM. I’m not using the NLB VIP Ip, Just two pools with “PRI” and “DR”. that was the same pre CU9 too. Just cant seem to get it to talk. I did try removing all together and re-publishing lync topology. recycled the pools etc still no luck. Did you have any luck Rob?

        • Craig did you happen to fix your XML configuration files after the update? This is a common issue (and one that that S4B 2015 fixes from what I’ve been told)

  • Hi Chris,

    Thanks for a great article. I’ve got Exchange 2013 CU 11 DAG deployment with Skype for Business. And it works 100% :).

  • Do you know why I would be receiving the error “IM Certificate with thumbprint could not be found”

    The certificate is imported (including private key) into all Exchange and Lync servers.

    I have edited the web.config file on the mailbox servers and verified the correct syntax.

    I’ve ran the set-virtualdirectory cmdlet to add this thumbprint, enable instant messaging, and set OCS.

    I’ve used the same exact settings in our dev environment and it worked fine.

  • Useful Lync resources – Henry Yang's Blog
  • Leave a Reply to Ettienne Cancel reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.