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.

Media Bypass - Lync 2010

Since I will keep expanding my lab Lync deployment with Enterprise Voice (I plan to test few new products, as for example – Ferrari Electronics' PCI certified Lync Gateway), now is a good time to configure and test Media Bypass functionality. MB is an awesome feature and I am excited of the fact that is now included. As an “old school” LCS/OCS guy, the bare thought of virtualizing anything that touches RTP makes me itch, but… this is another story…

Configuration of Media Bypass is described here: http://technet.microsoft.com/en-us/library/gg413028.aspx. I will simply follow the steps and later run some traces to verify the functionality.

As described, we have two options – to “force” (via Global settings) “always bypass” which I find not such a good idea, especially if our environment consist of multiple regions and sites where the WAN and inter-site links could be impacted at any time. Instead, I will use “sites and region configuration” option.

Next, I will enable Media Bypass on my only (as of this moment) Trunk.

…and of course, Commit the changes.

***It is important to understand the following statement:

 “If you have already optionally configured call admission control (CAC), another advanced Enterprise Voice feature, note that the bandwidth reservation performed by call admission control does not apply to any calls for which media bypass is employed. The verification of whether to employ media bypass is performed first, and if media bypass is employed, call admission control is not used for the call; only if the media bypass check fails is the check performed for call admission control. The two features are thus mutually exclusive for any particular call that is routed to the PSTN. This is the logic because media bypass assumes that bandwidth constraints do not exist between the media endpoints on a call; media bypass cannot be performed on links with restricted bandwidth. As a result, one of the following will apply to a PSTN call: a) media bypasses the Mediation Server, and call admission control does not reserve bandwidth for the call; or b) call admission control applies bandwidth reservation to the call, and media is processed by the Mediation Server involved in the call”.

Simply said – do not enable Media Bypass if you intend to utilize Call Admission Control due to a slow or unreliable WAN links because if MB is enabled, CAC will not be respected.

Now gets a little tricky. We must associate each subnet on our network with a specific network site. First, I will define at least one Network Site:

Next, I will use Control Panel to define one subnet in my environment:

 …and another with Lync Server Management Shell:

 

Quick check of my Site properties shows that the subnets are now associated with this site.

Now I should expect Media Bypass to work or, should I? Fact is – Lync clients receive such information via in band provisioning and so, in order to test immediately, I will log off and login back to Lync from a client on 10.8.0.0 subnet.

There are several ways to verify if MB works. As Jens Trier Rasmussen described in this post: http://blogs.technet.com/b/jenstr/archive/2011/04/14/media-bypass.aspx, I could check my Monitoring server for Call Information or use Snooper or… run Wireshark and see if RTP will flow between my Audiocodes Mediant 800MSBG and my PC (Lync client).

Indeed, it worked as expected.