Integrating Exchange 2013 + Lync 2013 for UCS & OWA integration

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                           : VL-EXG-01.company.local
AutoDiscoverServiceInternalUri : https://autodiscover.company.local/Autodiscover/Autodiscover.xml

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

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

Site : Site:ConnectUC
Fqdn : lyncpool.company.local

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 “https://lyncpool.company.local/metadata/json/1” -ApplicationType Lync

iisreset

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 {$_.services -like “*iis*” } | fl subject, issuer, services, thumbprint

Subject    : CN=mailtest.connectuc.com, 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 lyncpool.company.local

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=”lyncpool.company.local” />

Then recycle the related IIS pool

C:\Windows\System32\Inetsrv\Appcmd.exe recycle apppool  /apppool.name:”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 https://autodiscover.company.local/autodiscover/metadata/json/1

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

Enable-CSTopology

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 vl-exg-01.company.local -Registrar lyncpool.company.local -Site ConnectUC -RequiresReplication $False

New-CsTrustedApplication -ApplicationId OutlookWebAccess -TrustedApplicationPoolFqdn vl-exg-01.company.local -Port 5199

Enable-CSTopology

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!

Chris Blackburn

Learn More →

43 thoughts on “Integrating Exchange 2013 + Lync 2013 for UCS & OWA integration

  1. Ettienne December 10, 2012 at 4:09 am

    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 :

    171:

    172:

    173: <add key=”IMServerName” value=”

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

    Thanks

    Reply
    1. Chris Blackburn January 26, 2013 at 4:13 pm

      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.

      Reply
  2. Stu January 13, 2013 at 1:40 pm

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

    Reply
  3. Graham Cooper April 13, 2013 at 7:26 am

    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

    Reply
    1. Varol July 18, 2013 at 3:40 pm

      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 (http://technet.microsoft.com/en-us/library/jj688055.aspx), “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.

      Reply
      1. Chris Blackburn July 28, 2013 at 10:37 pm

        Great feedback Varol – I’ve updated the article to remove the back end “where” variable.

        Reply
  4. Graham Cooper April 13, 2013 at 12:31 pm

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

    Reply
  5. Raymond Brooks May 8, 2013 at 12:36 pm

    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

    to

    Notice the subtle differences in the way the quotes look.

    2)Ignore the create application command

    New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl https://autodiscover.company.local/autodiscover/metadata/json/1

    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?

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

      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!

      Reply
  6. Rogier May 9, 2013 at 2:16 pm

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

    Reply
  7. David Tucker May 27, 2013 at 4:33 am

    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.

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

    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!

    Reply
  9. Sean Kalinich July 2, 2013 at 1:35 pm

    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:
    15.0.516.30
    Bin
    Current2

    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…

    Reply
    1. Chris Blackburn July 18, 2013 at 8:21 am

      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 🙂

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

    Hi,

    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?

    Reply
    1. Chris Blackburn July 18, 2013 at 8:14 am

      Hi Marius,

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

      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.

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

    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.

    Reply
  12. Jcharlery October 25, 2013 at 9:21 am

    Very nice and great Article.

    Reply
  13. Carlos January 17, 2014 at 2:32 pm

    in regards to this command:
    ew-CsTrustedApplicationPool -Identity vl-exg-01.company.local -Registrar lyncpool.company.local -Site ConnectUC -RequiresReplication $False

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

    Reply
    1. Chris Blackburn January 24, 2014 at 10:58 am

      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

      Reply
      1. bob brown March 12, 2014 at 4:40 am

        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.

        Reply
        1. Chris Blackburn March 12, 2014 at 3:06 pm

          Bob take a look at this Technet article for guidance:
          http://technet.microsoft.com/en-us/library/jj688055.aspx
          Since every environment is different, the best I can advise is reviewing your commands with the following guidance:

        2. 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
        3. The Lync Server 2013 pool must be the fully qualified domain name that will host the new trusted application pool
        4. 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.

          Reply
  1. Bob Brown March 19, 2014 at 10:52 am

    Already been through that several times.certs look ok also. My problem isnt that we CANT sign in to OWA, we can. Our problem is we dont get any presence status (Greyed out). Ive ran both test-CsExUMConnectivity and Test-CsUnifiedContactStore, we get successful results. Everything looks fine double,triple checked However, I dont see any 112 in event logs or see anything in the folder C:\Program Files\Microsoft\Exchange server\V15\Logging\OWA\InstantMessagingin the event logs.
    I was just hoping you would have some suggestions on what to check next.

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

    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??

    Reply
    1. Chris Blackburn April 2, 2014 at 8:38 pm

      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!

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

    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., @company.com). 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.

    George

    Reply
  • Anees Ur Rehman April 11, 2014 at 5:19 am

    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

    Reply
    1. Chris Blackburn July 13, 2015 at 9:54 am

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

      Reply
  • kjstech November 25, 2014 at 3:25 pm

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

    New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl https://autodiscover.company.local/autodiscover/metadata/json/1

    Ok our autodiscover for exchange 2013 is email.domain.com 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.”

    Reply
    1. Chris Blackburn February 17, 2015 at 4:03 pm

      So I found your post on the Technet blog and it eluded to the fact that you have an Exchange 2007 & Exchange 2013 server:
      https://social.technet.microsoft.com/Forums/office/en-US/ca3fa8c2-e23c-4d92-a4f6-65ede3d04021/cannot-complete-lync2013-integration-because-autodiscovermetadatajson1-does-not-exist?forum=lyncdeploy

      You CAN have both servers with the same URLs, however in a coexistance scenario you’ll need to have Client Access operations handled by Exchange 2013. If you have Client Access resolving to Exchange 2007, it has no means of knowing anything about calls from Lync 2013. Or, on the Lync 2013 servers, hardcode your autodiscover URL in the HOSTS file to point to your Exchange 2013 servers. That should help get past this.

      Reply
  • Steve April 2, 2015 at 10:47 am

    Hi,

    Followed all the steps everything went fine except the
    New-CsPartnerApplication -identity Exchange -ApplicationTrustLevel Full -MetadataUrl https://autodiscover.company.local/autodiscover/metadata/json/1
    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

    Reply
    1. Chris Blackburn June 17, 2015 at 1:53 pm

      This may be in part due to certificates and it causing the Powershell to bug out.
      Check out this blog that has some trial and error based on my original posts!
      https://sysadminblogger.wordpress.com/tag/get-cspartnerapplication/

      Reply
  • Rob R July 6, 2015 at 7:55 am

    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?
    Thanks.

    Reply
    1. Chris Blackburn July 13, 2015 at 9:53 am

      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.

      Reply
      1. Craig Stevens August 16, 2015 at 4:55 pm

        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?

        Reply
        1. Chris Blackburn October 28, 2015 at 4:13 pm

          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)

          Reply
  • Billy Hietbrink March 2, 2016 at 4:47 am

    Hi Chris,

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

    Reply
    1. Chris Blackburn March 15, 2016 at 4:36 pm

      Glad its working for you! 🙂

      Reply
  • Josh March 14, 2016 at 8:05 am

    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.

    Reply
    1. Chris Blackburn March 15, 2016 at 4:38 pm

      Is this using a public-issued cert or internal CA? If it’s internal, do you have the root certificates in place?

      Reply
      1. Josh March 24, 2016 at 6:30 am

        It’s an internal CA. The certificate is installed on all Exchange servers and the Lync server.

        Reply
  • Useful Lync resources – Henry Yang's Blog April 14, 2016 at 10:47 pm

    […] Integrating Exchange 2013 + Lync 2013 for UCS & OWA integration […]

    Reply
  • Leave a Reply

    Your email address will not be published. Required fields are marked *

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

    css.php