Using IM and Presence in Exchange Server 2010 OWA against a Lync Server 2013 Front End Pool

Hi Everyone

it's been a while since I published a post and the absence from posting has had me itching to write something up again. I have had plenty to write about just not enough time :), I know world smallest violin is playing!

Well, I finally had a spare hour or two to knock up a post about a scenario I was looking at recently for a customer. We are looking at rolling out Lync Server 2013 in the near future but we still have some people running a Windows XP SP2 desktop. A large majority of the fleet is Windows 7, but still quite a number are on XP SP2 and hence they cannot use the Lync full client except with either a OCS client or OWA. My customer elected to go OWA as an IM n P client for their XP desktops, and have been using it for a while. Anyways, we have been looking at whether we can roll out a Lync Server 2013 back end before we make any changes to both the remaining Windows XP SP2 desktops and the Exchange Server 2010 email system.

So I set about labbing up that scenario to see what happened and my basic testing forms the basis of this blog. I started off with Jeff Schertz's blog on Exchange and Lync integration found here https://blog.schertz.name/2010/11/lync-and-exchange-im-integration/. It's another great article from Jeff detailing how to get OWA IM n P up and running pretty quickly. So have a good look at that blog as it has the majority of steps I needed to perform to get things working.

Getting Started

So I setup a pretty basic lab, I had a single Exchange Server 2010 running SP2 (I didn't install any Rollups which you should definitely do in production) ex01.contoso.org, and a single Lync Server 2013 Standard Edition Server se01.contoso.org (on Windows Server 2012). I also had a Domain Controller running Windows Server 2012 and my certification authority. I installed Exchange and Lync and got those individual products up and running and work as silo'd applications.

Exchange Certificate for IIS, SMTP

One thing to note was that when I first deployed my Exchange Server I switched over from the self signed certificate to a certificate issued by my CA. When I did this I used the Exchange Management shell command below to create the certificate request for Exchange:

New-ExchangeCertificate -FriendlyName "Exchange 2010 Certificate" -IncludeServerFQDN -DomainName mail.contoso.org,autodiscover.contoso.org,webmail.contoso.org,ex01.contoso.org,mail.contoso.com -GenerateRequest -PrivateKeyExportable $true

I then use the request text generated by the above command to request a new certificate for EX01. Once requested I downloaded the resulting certificate to EX01's C:\ drive. The next step was to assign the downloaded certificate to the Exchange Server using the command:

Import-ExchangeCertificate -server 'EX01' -FileData ([Byte[]]$(Get-Content -Path c:\ex01.cer -Encoding byte -ReadCount 0)) 

I then assigned the resulting certificate to the Exchange IIS and SMTP services using the command:

Enable-ExchangeCertificate -Server 'EX01' -Services 'IIS, SMTP' -Thumbprint 'E9027888AE27F01310BEA7325FCB1018146EF0E9'

NOTE: The Enable-ExchangeCertificate step is not required to do for Lync OWA integration. You can request and create a certificate explicitly for use for the IM integration.

The important thing to note here was that these steps created a certificate issued by my Windows CA that had a "Subject" and "Common Name" which ended up as mail.contoso.org. I used the Exchange cmdlets as I had the commands all wrapped up in my cheat sheet of build steps and didn't think anything more of it, I knew I was asking for all those SANs as I often configure the use of mail.contoso.com for publishing Exchange services through a reverse proxy. My thinking was it wouldn't hurt having those domain names in my certificate, requested in that order. The resulting certificate shown below:

Figure 1 - My Exchange certificate with a CN and subject of mail.contoso.org

 

Configure UCMA and OCS SSP on EX01

The next step was to take the lead from Jeff's article and install the UCMA and the OCS Web Service Provider (CWAOWASSPMain.msi and associated patches). I pretty much followed Jeff to the letter here. Everything seemed to be going along quite smoothly.

I next had to configure the OWA virtual directory to enable OCS integration from within OWA. As Jeff's article recommends you first find the appropriate certificate and get it's thumb print and then execute the following command:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingType OCS -InstantMessagingEnabled:$true –InstantMessagingCertificateThumbprint <insert your certificate thumbprint here> -InstantMessagingServerName se01.contoso.org

If you have deployed a certificate explicitly for OWA IM integration you will select the thumbprint for that certificate in the above command (you determine the certificate thumbprint using the Get-ExchangeCertificate cmdlet in Exchange Management shell).

I then performed an IISReset on the EX01 server and moved onto the next step in the process.

 

Creating the Trusted Application in the Lync Server 2013 topology

At this point it is expected that the Lync and Exchange integration in OWA won't be working as we haven't yet created a Trusted Application in Lync. For interest sake I turned on Lync logging to see what was logged against the IMAndPresence scenario. This was performed with the commands:

cd "c:\program files\common files\Microsoft Lync Server 2013\clsagent"
clscontroller.exe -start -pools se01.contoso.org -scenario IMAndPresence

TIP: It is worth putting the above commands in a batch file to save on your Lync Server, as you'll be using this command pretty regularly when troubleshooting IM and SIP issues.

I next logged into OWA to see the result of pointing Exchange at the Lync Server 2013 (expecting a failure). As expected, the OWA failed to sign in to Lync.

Figure 2 - Signing into OWA using cathm found that OWA could not sign in against Lync.

So I needed to proceed with the Lync Trusted Application setup for my ex01.contoso.org server. There are a couple of ways of creating a Trusted Application from within Lync, you can do it with Topology Builder or with the Lync Management Shell. I prefer using Powershell as I am a believer in the saying that "Real men don't click they use Powershell" so I created the Trusted Application for Exchange OWA using the following commands:

New-CsTrustedApplicationPool -Identity ex01.contoso.org -Registrar se01.contoso.org -Site Sydney -RequiresReplication $False

New-CsTrustedApplication -ApplicationId ExchangeOWA -TrustedApplicationPoolFqdn ex01.contoso.org -Port 5059

Enable-CSTopology -v

Is it all working now?

So at this point I should be ready to rock and roll. So I attempted to sign in to OWA to confirm. I can see the donut in OWA attempting a Lync signin, looks like I am cooking with gas!

Figure 3 - Looks like it is working.

But d'oh, no dice it isn't and OWA tells me still no ability to sign in!

Figure 4 - Nope, OWA to Lync no worky

 

So where to now?

I am wondering whether or not Exchange 2010 integrates properly with Lync Server 2013, which I thought was a slight possibility. But best make sure, I can check the Event Logs and see what clscontroller.exe has come up with.

So the first step is have a look at the event logs on SE01. What is there that is red. I don't see too much in the "Lync Server" event log, mostly information events and a few unrelated Warnings. Nothing much there.

Next have a look at the Application and System logs. In the System log I notice a number of SCHANNEL alerts which are generally related to TLS issues. This peeks my interest.

Figure 5 - Schannel errors in the System log of my Lync Server.

Unfortunately that error doesn't tell me a lot, and as I know the certs on my SE01 and EX01 box will be trusted (both in the same domain, using Windows CA on the DC, definitely trusted) I was a little stumped about what's next. Perhaps the clscontroller.exe logs might help.

CLSController.exe Logs

I stopped the CLSController logging against the SE01 pool using the following command (its worth putting these commands into a batch file as well so you have a IM logging on and IM logging off command):

cd "c:\program files\common files\Microsoft Lync Server 2013\clsagent"
clscontroller.exe -stop -pools se01.contoso.org -scenario IMAndPresence

I then used Powershell to retrieve what was collected for the IMAndPresence scenario during that activity. THis was performed in the Lync Management Shell using the command:

Search-CsClsLogging -Pools se01.contoso.org -LogLevel Verbose -Components S4,SipStack -OutputFilePath c:\srm\logfile.txt

I then fired up the resulting logfile.txt in Snooper. I am using the Lync 2013 Debugging tools version of snooper to have a look at this resulting logfile. I scrolled down a few pages in Snooper but didn't immediately see any red, so I thought i'd search for .152 the last octet of the Exchange Server's IP address. This filtered out the results of logfile.txt and returned a lot more interesting stuff in red in the log file (which was at the bottom of the file).

Figure 6 - TLS related errors found in the snooper log.

Well the CLSController logs nailed it for me. You beauty. As you can see from the snooper details the fqdn of mail.contoso.org was being used by the EX01.contoso.org server to connect to my Lync Server 2013 standard edition box. As my trusted application in Lync had been configured as EX01.contoso.org, Lync was complaining that it didn't know about this rogue application trying to connect to it and hence was rejecting the sign in attempts.

So Exchange was using the Subject/Common Name in it's certificate as the client name when attempting a connection to SE01. This name was used in the TLS certificate exchange and SE01 checked this FQDN against it's list of known trusted applications and things broke down.

How to Fix it?

So I went back and fixed up my certificate used by IIS on EX01 to have a subject/common name of ex01.contoso.org. I still had subject alternate name values issued as well that I could use for services like autodiscover and external mail access but had EX01 right up front as the CN. I then assigned this new certificate to the IIS and SMTP services using the Enable-ExchangeCertificate cmdlet. I then performed an IISReset on ex01.contoso.org and attempted to sign in to OWA again.

Voila, it worked a treat. Not being an Exchange guru I am going to need to get my very esteemed colleague Greg to comment on the recommended CN/SAN approach for Exchange in a future post.

If you are going to deploy a dedicated certificate for OWA IM integration then you could use the Exchange command (NOTE: don't assign the certificate that is created to Exchange certificates):

New-ExchangeCertificate -FriendlyName "Exchange 2010 OWA IM Certificate" -IncludeServerFQDN -DomainName ex01.contoso.org -GenerateRequest -PrivateKeyExportable $true 

The good news though is that it appears with some tweaking we can get Exchange Server 2010 and Lync Server 2013 OWA IM and Presence integration working! (Yes I know I should have been using a Lync Server 2013 client, I have a 2010 client in my 2008 R2 SOE image, mental note to fix that :)).

A big thanks again to Jeff Schertz for his great integration blog (not to mention all the other fantastic Lync blogs he has done!).

Happy Lync'ing

Steve