Lync – Exchange 2010 SP1 OWA integration

I just realized I am missing something from my Lync lab deployment: Lync – Exchange 2010 SP1 OWA integration. I will begin by installing the required prerequisites on my Client Access server.

First, I will download and install “OCS 2007 R2 Web Service Provider” http://www.microsoft.com/downloads/details.aspx?familyid=CA107AB1-63C8-4C6A-816D-17961393D2B8&displaylang=en

 The files will be unpacked here:

Let’s now install the files in the required order:

1. vcredist_x64.exe
2. UcmaRedist.msi
3. CWAOWASSP.msi

Time for “Unified Communications Managed API 2.0 Redist (64 Bit) Hotfix KB 2282949” http://www.microsoft.com/download/en/details.aspx?id=7557

…and "OCS 2007 R2 Web Service Provider Hotfix KB 981256" http://www.microsoft.com/download/en/details.aspx?id=797

At this point, just to be sure I have not missed anything, I will run Windows Updates before proceed further. But of course – Visual C++ update…

Now I can proceed with configuration of OWA virtual directory integration. First I need to obtain the thumbprint of my Exchange certificate by running “Get-ExchangeCertificate | fl” form Exchange Management Shell:

 

I will get the Identity of my OWA with the command"Get-OwaVirtualDirectory | fl"

…and use it to construct my command:

Set-OwaVirtualDirectory -Identity "EX\owa (Default Web Site)" -InstantMessagingCertificateThumbprint 8F9D12B0B143689DD34D55B04CB063A418124FA3 -InstantMessagingServerName fe.lynclog.com -InstantMessagingType OCS -InstantMessagingEnabled $True"

Where “EX\owa (Default Web Site)” is the Identity I obtained from the previous command, the Thumbprint is from “Get-ExchangeCertificate | fl” and “fe1.lynclog.com” is my Lync Standard Edition Server.

Lastly, I will restart the IIS with “iisreset” command.

Now, when I run “Get-OwaVirtualDirectory | fl”, the required parameters are set:

Time for Lync Server configuration.  From Lync Management Shell let’s get the SiteId:

…and construct my command to create Trusted Application Pool – “New-CsTrustedApplicationPool -Identity ex.lynclog.com -Registrar fe1.lynclog.com -Site 1 -RequiresReplication $False”

As instructed, I will run “Enable-CsTopology”

Next step – to create New trusted Application. The command will be “New-CsTrustedApplication -ApplicationId ExOwaAccess -TrustedApplicationPoolFqdn ex.lynclog.com -Port 3800” where ApplicationId is a just a name, TrustedApplicationPoolFqdn is the FQDN of the CAS server and Port – an unused port. Lastly, “Enable-CsTopology” as required.

…and test our setup:

CWA support for mobile devices - Lync 2010

It is Friday (half day) again and I can go back my playground. I have been waiting for Lync Mobile Client quietly for some time and today my patience ran out. I know that deploying CWA (Communicator Web Access) will not give me reach experience but, it least, some IM connectivity when away from the commuter.

Since this is greenfield Lync installation (OCS or R2 have never been present), the AD Schema was not prepped for OCS. I will do it now. My OS of choice is Windows Server 2008 R1 SP1 standard edition. Dues to the fact that “Microsoft Office Communications Server R2, Core components” and “Microsoft Office Communications Server R2, Microsoft Unified Communications Managed API 2.0 Core Redist 64-bit” will be installed, I cannot use any server where Lync bits are already installed.

Since we will ONLY have one virtual web server, I think any web server that exist in the environment could do. However, a careful evaluation of IP addresses and used ports must be done beforehand.

As first step I will download Communications Server 2007 R2 Core Components Runtime package from this link: http://www.microsoft.com/download/en/details.aspx?id=4070 and install it in my Domain Controller (which is also a Schema Master).

The components are now installed in “C:\Core Components Runtime Runtime Package”.

I will use “ldifde” tool to prep the schema for OCS. The command in this case will be:
ldifde -i -v -k -s DC1 -f schema.ldf -c DC=X “DC=lynclog,DC=com”.

***Note that if you are logged as different user, you must use the “-b” parameter in format:
ldifde –i –v –k –s DC1 –f schema.ldf –c DC=X “DC=contoso,DC=com” –b Administrator contoso password

More information can be found here: http://technet.microsoft.com/en-us/library/dd441329(office.13).aspx

In Command Prompt I will navigate to C:\Core Components Runtime Runtime Package and run the above command.

Strangely, I received an error and since couldn’t find any reference on Internet, decided to modify “schema.ldf” file where I replaced every instance of “DC=X” with “DC=lynclog,DC=com” and now my command looked like this: “ldifde -i -v -k -s DC1 -f schema.ldf”. The command ran sucessfuly this time. Go figure…

Because I must use LcsCmd.exe to proceed further, I will install sqlncli_x64.msi, vcredist_x64.exe, and ocscore.msi (in this order), located in C:\Core Components Runtime Runtime Package.


I need also .NET and so, I will run servermanagercmd -install Net-Framework Net-Framework-Core Net-Win-CFAC Net-HTTP-Activation NET-HTTP-Activation WAS WAS-Process-Model WAS-Net-Environment WAS-Config-ApIs

LcsCmd.exe is now located in C:\Program Files\Common Files\Microsoft Office Communications Server 2007 R2.

Time to run LcsCmd.exe /forest /action:forestprep and LcsCmd.exe /domain /action:domainprep

***Because I am done with the Domain Controller, it is safe to remove the core components.

It is now imperative to run Lync Server Deployment Wizard and run the Schema Prep again.

Even thou I don’t have (yet) any OCS servers in this environment, I will “Merge” the topology at this point.

Darn, I forgot to install the Backward Component Module located in the installation media.

Now “Merge” complete successfully.

Moving now to our CWA server – first the prereqs. I will run “Import-Module ServerManager” from Powershell and then “Add-WindowsFeature web-windows-auth,web-digest-auth,web-basic-auth,web-mgmt-compat,web-mgmt-console,web-common-http,web-ISAPI-ext,web-ISAPI-filter,web-request-monitor,web-http-redirect,web-http-logging” and of course – “servermanagercmd -install Net-Framework Net-Framework-Core Net-Win-CFAC Net-HTTP-Activation NET-HTTP-Activation WAS WAS-Process-Model WAS-Net-Environment WAS-Config-ApIs”

The CWA role Deployment guide can be found here: http://technet.microsoft.com/en-us/library/dd441267(office.13).aspx

***I already requested and imported Public Certificate from StartCom – steps which will not be described here.

I must create an account at this point…

…and of course – set it in AD to “password never expire”.

Next step – Create virtual server.

***I must be careful to select a port number that is not in use from any other application that could be already installed on this box.

Lastly – Publish the URL’s

***Install the required updates:http://go.microsoft.com/fwlink/?LinkID=202639

Now I will Merge the topology again and check if my CWA server is present.

Indeed, my server is now shown In the Legacy Trusted Application Servers list and I will publish the Topology at this point.

Next I will restart the Lync server services from Lync Management Shell:

Stop-CSWindowsService –Verbose
Start-CSWindowsService –Verbose

Time to test my CWA deployment:

Lync Phone Edition and third party Root CA Authority

As a Network Administrator, I often check variety of server and application logs to verify the health of the environment. Today I‘ve noticed that the Aastra 6725ip phone in my office (connecting to my home lab's Lync deployment via public internet) never updated the firmware to the latest – “4.0.7577.250”. Strange indeed… 

Now I remembered that the phone never downloaded the Address Book either. Why would that be? I have deployed reverse proxy with certificate from StartSSL, which is included in the Root CA Authority of Windows OS. The functionality was verified and external users could successfully connect to a meeting organized by lynclog.com user.

Quick reference to the TechNet article revealed the sad truth – while StartSSL is present on Root CA store of Windows, it is not in Lync Phone Edition.

Now what?!? Looks like the certificate I use on TMG provides only half of the functionality… or does it? If you think of it, my internal Domain Root CA is not presented in the Phone Edition store either, and yet a phone connected to the LAN works. This is, because according the article, “First, the device searches for Active Directory Domain Services (AD DS) objects of the category certificationAuthority. If the search returns any objects, the device uses the attribute caCertificate. That attribute is assumed to hold the certificate, and the device installs the certificate.

The root CA certificate must be published in the caCertificate for Lync Phone Edition.”

So, what if I use “certutil -f -dspublish RootCA” and publish the StartSSL Root CA in my pKIEnrollmentService store? The assumption is that AFTER I connect a device for first time on a LAN network and sign in, all certificates in the Domain Certificate Authority will be downloaded to the device (including StartSSL Root CA) and later, when I take the device on Public Internet, as long as it is not reset to “factory defaults”, where the Certificate Store will be restored to original state, the phone will trust my Reverse Proxy and it should download updates, address book etc. Needless to say, my lab Exchange server also uses StartSSL for OWA service and so, this integration should function as well.

One way to find out - I have already downloaded StartSSL Root CA to my domain controller...

 …and will use the above command to publish it.

As we can see, the certificate was added. I should expect to find it in the phone edition store after resetting it and sign in again.

After some digging through the SELog, I found the following line:

For now, I will “assume success” as well and take the device to my office tomorrow to examine the result. Also, a quick look at just joined to lynclog.com domain workstation shows that StartCon (StartSSL) Root CA is present in the local Trusted Root Certification Authorities i.e. downloaded automatically along with the Domain Root CA.

As usual, this example is for testing purposes only. A caution and careful consideration is necessary if/when the Administrator decides to push third party Root CA via Active Directory Certificate Services.

07/13/2011 Update:

As a Proof Of Concept – it worked as expected. The phone, looged over Internet, did promptly update the firmware and rebooted. HOWEVER, this method should not be used in production environment. To me it looks like Phone Edition Update is an image based and firmware upgrade replaces everything (including the local Certificate Store) thus rendering our exercise above inapplicable in production environment.