Like many I was excited to see the mobility client finally released for Lync 2010 but needed to figure out what communication was going where - can't fix what you do not understand.

THE ISSUE

When using mobility, internally or externally, all communication flows from the mobile device to the External Web Services of your pool. The concept is that there is a single point of communication regardless of your network allowing communication to seamlessly move network to network. In order to achieve this, the external services URLs must be reachable internally when a client access port 443.

THE LOAD BALANCER

That requirement was not as daunting as one might think when using a Hardware Load Balancer, in this case it was my KEMP. The key on the KEMP was to have two VIPs created, one for internal communication and one for external communication. The configuration looked something like this:

Internal Web Services VIP
10.10.10.10:443 --> 10.10.10.50:443
10.10.10.10:80 --> 10.10.10.50:80

External Web Services VIP
10.10.10.20:443 --> 10.10.10.50:4443
10.10.10.20:80 --> 10.10.10.50:8080

With this configuration, the port address translation happens on the HLB so the Reverse Proxy or Firewall can send the external traffic unchanged. Internally, the communication is always bound for HTTP/HTTPS and then changed depending on the destination IP.

DATA FLOW

Looking at communication from a phone via cellular and WiFi then looks like so:

Cellular
Phone IP (12.5.5.23) --> Ext AutoDiscover (68.5.12.54:443) --> Ext Web Services URL (68.5.12.54:443) --> HLB (10.10.10.20:443) --> Lync Pool External Web Services (10.10.10.50:4443)

WiFi
Phone IP (10.10.10.100) --> Internal AutoDiscover (10.10.10.10:443) --> Int Web Services (10.10.10.10:443) --> Ext Web Services URL/HLB (10.10.10.20:443) --> Lync Pool External Web Services (10.10.10.50:4443)

As you can see both methods end up going to the external web services which is managed by the KEMP HLB. The only difference is when on the internal WiFi it is able to resolve the internal pool which passes the Mobile URL information back which is the external web services URL. Because the external web services URL resolves internally to the VIP created for the external web services, it is redirected to port 4443.

That sets the data flow as we want, now the only thing left is the configuration of the KEMP HLB which requires the setup using cookies for persistence (again referencing Dave Howe's article here).

CONFIGURING THE HLB

The KEMP configuration for Lync is fairly easy with the setting below. You will need your external certificate so that is can be loaded into the HLB (public and private key) as it will need to decrypt and re-encrypt the communication. An example configuration would be:

Basic Properties
Service Type: HTTP/HTTPS
L7 Transparency: Disabled
Real Server Check Parameters: Optional but recommended
Service Nickname: Lync Web Servers -4443
Persistence Options
Mode: Active Cookie
Timeout: 3 Days (the length of an inactive Push Session before it times out)
Cookie Name: MS-WSMAN
Scheduling Method: resource based (adaptive)
Idle Connection Timeout: 0
Use Address for SNAT: Unchecked

SSL Properties
SSL Acceleration: Enabled and Reencrypt checked
Certificates: Load the external web services certificate here
Rewrite rules: None
Client Certificates: No Client Certificates required

Advanced Properties
Content Switching: Disabled
HTTP Headre Modifications: None
Port Following: No Port Selected
Enable Caching: Unchecked
Enable Compression: Unchecked
Detect Malicious Requests: Unchecked
Add Header to Request:
Not Available Server:
Not Available Redirection Handling:
Default Gateway:

COMPLETE

Assuming there are physical servers that the VIP is pointing to (again redirecting to port 4443 and 8080) communication should now flow. As key a reminder, make sure the external web services URL resolves internally to the external HLB VIP configured above and you are good.

Native Microsoft Mobility for Lync 2010 Is Here!

The mobility features of Lync have been sorely missed since Lync 2010 was release last November but Microsoft has made HUGE strides in their recent release. There are a few pre-requisites which we will cover as well as some gotchas to look out for. As of today the Windows Phone client (Mango required) is available in the Marketplace but the Apple iOS and Android clients have yet to appear. There should also be a Nokia client but I do not have a method to test so unfortunately I have nothing to report there.

Server Requirements

Before mobility can be configured the current Lync environment requires CU4 to already be installed. If this has not been done, first things first. There are also a few configuration requirements that must be met which while it didn't matter without mobility, now it does. Those include:

The Front-end pool internal web FQDN must be different from the external (even if you are using split-DNS)
HLBs may need to be updated changing their persistence to cookie-based and certificates installed to support SNAT
IIS Dynamic Content Compression is needed on the Directors and Front-End servers in order to install the mobility BITS

Once that is complete there is a mobility download that must be grabbed and server-based PowerShell commands that are run on a Front-End Server in the environment. The configuration includes updating DNS, requesting and installing new certificates, configuring ports etc. so let's begin.

Mobility Configuration

CONFIGURING MOBILITY PORTS

The first task completed when configuring mobility is running two PowerShell commands to configure the ports mobility will use inside and outside. Setting the ports will also 'inform; the bootstrapper process that mobility should be installed and configured. To set your ports simply launch Lync Server Management Shell (LSMS) and type:

Set-CsWebServer –Identity lspoolname.domain.com –McxSipPrimaryListeningPort 5086
Set-CsWebServer –Identity lspoolname.domain.com –McxSipExternalListeningPort 5087
Enable-CsTopology

You can see the internal listening port has been set at 5086 with the external ports set to 5087. The enable command sets the changes into the topology and the Lync environment is now aware that mobility should be there. The above two Set-CsWebServer commands with the MCX values will only work if CU4 is installed.

IIS CONFIGURATION

If the IID Dynamic Content Compression was not already added (listed as a pre-requisite above) now is the time to complete the process as without it setup will fail. If your base operating system for your Lync Front-End/Director server is Windows Server 2008, use the following command:

[from a command prompt] ServerManagerCMD.exe –Install Web-Dyn-Compression

If the base operating system for your Lync Front-End/Director server is Windows Server 2008 R2, use the following command:

[from PowerShell] Import-Module ServerManager; Add-WindowsFeature Web-Server, Web-Dyn-Compression

DNS CONFIGURATION

New DNS names have been established for the AutoDiscover process (think Exchange AutoDiscover). The new feature removes the need for you to configure the explicit server settings on the mobile clients (very nice). There are up to three different records that must be created, two of which are on the inside DNS. Two of the three records are CNAME DNS records while the third (required if split-DNS) is an 'A" record.

Internal DNS create CNAME record lyncdiscoverinternal and point it to the internal web services 'A' record
External DNS create CNSME record lyncdiscover and point it to the external web services 'A' record
Internal DNS (if using split-DNS) create 'A' record for your external web services name and configure it to the external IP

INSTALLATION OF THE MOBILITY BITS

The installation of the BITS is completed by downloading the new MSI, placing it in the expected folders, and running bootstrapper.

To begin, download the MSI at Microsoft's download center here. Save the MSI locally to each Front-End and Director server in the path C:\ProgramData\Microsoft\Lync Server\Deployment\cache\4.0.7577.0\setup. This is the location of the cached Lync 2010 installers. Once the MSI is in the correct path, launch LSMS and run C:\Program Files\Microsoft Lync Server 2010\Deployment\Bootstrapper.exe (NOTE: the path C:\Program Files\Microsoft Lync Server 2010\ may be different in your deployment based off of where Lync was installed)

Bootstrapper will detect the configuration/setting of the mobility ports and install the mobility BITS on the required servers.

Assuming push notifications are desired on the iOS and Windows Phone platforms, enter the following after the installation is complete (from LSMS):

Set-CsPushNotificationConfiguration -EnableApplePushNotificationService $true -EnableMicrosoftPushNotificationService $true
New-CsHostingProvider –Identity "LyncOnline" –Enabled $True –ProxyFqdn "sipfed.online.lync.com" –VerificationLevel UseSourceVerification
New-CsAllowedDomain –Identity "push.lync.com"

CERTIFICATES

Because there are new names internally and externally new SANs are required on both the internal and external certificates. The simplest way to request a new certificate is using the Lync Deployment application on a Front-End server (one per pool). The server has the ability to create both the internal and external certificates using the GUI. If you are in a multi-server pool I recommend having three separate certificates on the pool - one unique to each Front-End and the other two used on each Front-End (same certificate).

If you already have the Server Default certificate unique to the Front-End server (it will have the pool name, server name, and most likely 'sip'), then the next step is running the wizard again and ONLY selecting Web Services Internal. Running the wizard will include all known names for all supported SIP domains - this includes the internal web services FQDN as the CN and meet, dialin, lyncdiscoverinternal, and your lyncadmin name as SANs. If you use an external certificate provider, that certificate request can be sent off for processing.

Next launch the certificate wizard again this time making sure only Web Services External is selected, offline certificate is selected, and mark as exportable is checked. The results for the external certificate request will be a certificate with the external web services FQDN as the CN and meet, dialin, and lyncdiscover as SANs. Once the certificate has been processed externally you have two options. If you are using a Reverse Proxy where the certificate is required or a HLB, export the certificate from the server and import into the appropriate location. Assuming you are using an internal CA, you would then have the option to re-request an internal certificate for the external web services role. If you are NAT'ing directly to a single server (no HLB but a single point of failure) then you may leave the certificate as is.

RESTART POOL/DIRECTOR SERVERS AND TEST

Once the configuration is complete, reboot the various servers and validate that there are no unexpected errors in the Lync logs in the Event Viewer. Once the servers are back online, assuming all is well launch LSMS and run the following command (replacing your two test users with appropriate names and accounts):

Test-CsMcxP2PIM -TargetFqdn lspoolname.domain.com -SenderSipAddress sip:user1@domain.com -SenderCredential "domain\user1" -ReceiverSipAddress sip:user2@domain.com -ReceiverCredential "domain\user2"

The result of the test should look like:

TargetUri : https://internalwebservicesname.domain.com:443/mcx
TargetFqdn : lspoolname.domain.com
Result : Success
Latency : 00:00:00
Error :
Diagnosis :

Lync Mobility on WiFi with a KEMP LB