Everyone who has had a look at the possibilities of the UCMA SDK for Lync will truly be excited by the options. Software developed on top of Lync (such as our products and custom developments) can either run on a Lync server role (e.g. a Front End server) or on a dedicated UCMA server.

This article describes how to setup a Lync 2010 application server

First of all, there is no Lync 2010 server role that you can define in topology builder. So what to do?

Here’s an overview of the installation and configuration steps:

Base Install of OS

Before we can continue with installing all the fancy UCMA / Lync stuff, we need to make sure that the computer is set up correctly. In my case this means:

a. IP / DNS settings are configured

b. The computer is part of the domain;computer account moved to the right OU

c. All Hotfixes are applied and the patch level is up-to-date

d. Remote Desktop is enabled

e. Virus Scanner is installed

For the virus scanner, it is important to exclude the directories in which you have placed your application files. I’ve seen situations where the virus scanner blocked files and thus caused applications to fail.

Create Trusted Application

It probably helps to spend a few words on the basic concept of trusted applications.

• An Application Pool consist of one or more Trusted Application Computers (discussing a single server pool here)
• A Trusted Application needs to be assigned to a Trusted Application Pool
• A Trusted Application Pool and thus the assigned Trusted Application need to be assigned to a registrar. This is usually a pool and this will be used for the application to perform the action against.

Create the Trusted Application Pool

This can be done either via Lync Management Shell or via Topology Builder. This also described here but I’ll show it as part of the full process.

To do so, you need to have the site id of the site where the pool resides and the trusted application pool will reside with the Get-CsSiteCMDlet. This is what it returns in my case:

Okay, so now we know that the site id is 1

So let’s go ahead and create a trusted application pool named “MyCustomApp” and add my application server to it:

PS C:\Users\administrator.AD>New-CsTrustedApplicationPool -Identity MyCustomApp -Registrar lyncpool01.ad.demo -RequiresReplication $true -Site 1 -ComputerFqdnlyncapp01.ad.demo

WARNING: The following changes must be made in order for the operation to be complete.
Enable-CsTopology must still be run for all changes to take effect.

I don’t run the Enable-CsTopoplogy CMDlet here because one of the following commands requires it as well and thus I do it at the end for all at once.

It depends on your application whether you need the replication of the CMS data to the application server or not. You will need it if you are using auto provisioning. In my case it does. You can also see that the Application Pool is assigned a registrar. This is e.g. used if you perform actions on behalf of users and you are registering as an endpoint in the application

Let’s check the result with the Get-CsTrustedApplicationPool CMDlet:

PS C:\Users\administrator.AD> Get-CsTrustedApplicationPool

You can’t see the computers assigned to that pool. Therefore I check it with the Get-
CsTrustedApplicationComputer CMDlet:

PS C:\Users\administrator.AD> Get-CsTrustedApplicationComputer

I’m sure there are some fancy PS one liners that show everything at once, but usually you don’t have that many trusted applications / pools and computers.

Create the Trusted Application

Okay, it’s there. Next step is to create a trusted application. Each trusted application needs a port to work with. The port needs to be one that is better not used by some other application. To avoid any possible conflicts with applications, the port used here should be above 1024, e.g. 10000.

PS C:\Users\administrator.AD> New-CsTrustedApplication -ApplicationIdMySuperfancyApp -TrustedApplicationPoolFqdnMyCustomApp -Port 10000

WARNING: The following changes must be made in order for the operation to be complete.
Enable-CsTopology must still be run for all changes to take effect.

I gave the application a name that is different from my trusted application pool. This is something you would rarely do in a production environment. I did it to not confuse you with the name. Actually you can pick the FQDN of the application server and assign it as identity to the trusted application pool and the trusted application. This will give you simplicity for the choice of a name, but you still have all these different objects but just with the same name.

In order to have the changes take effect, I’m enabling the topology:

PS C:\Users\administrator.AD> Enable-CsTopology

This is what it looks like in topology builder after enabling the topology:  

One important finding is that Lync Server 2010 needs to have a trusted application even though your application is not leveraging these parts of UCMA. You need it, because otherwise the Front End Server will just refuse to talk to your application server.

Here are some entries from a Lync Logging Tool log that you might have if something is wrong with the trusted application:

Install Lync Components for UCMA

Windows Components

You need to install the necessary Windows components upfront. This can be done via a simple powershell command:

Import-Module Servermanager
Add-WindowsFeature Web-WebServer,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Redirect,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Basic-Auth,Web-Windows-Auth,Web-Client-Auth,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,Web-Scripting-Tools,NET-Framework-Core,RSAT-Web-Server,Telnet-Client

Source:

Lync Deployment Wizard

In order to be able to install a UCMA server, the deployment wizard needs to get installed. This will install Lync Core Components.

1. Install the Visual C++ Redistributable

2. Select the path for the core components

3. Accept the license statement

4. Click on “Install or Update Lync Server System” in the deployment wizard

5. Run step 1-3 one after another.

It is important to assign a certificate. Otherwise the MTLS handshake with the Front End Server will fail. Run Get-CsCertificate CMDlet to verify the certificate.

I recommend checking the Lync Server replication with the “Get-CsManagementReplicationStatus” CMDlet as soon as it indicates “true” for the application server (ideally for all servers, but this is dependent on the status of your overall topology).

If you don’t want to wait until this catches up, you can force the server to start a new synchronization right away by using “Invoke-CsManagementStoreReplication” and look up the changes with the “Get-CsManagementReplicationStatus” CMDlet. If the replication to that application server works, you are all set and your server is ready to host your UCMA application.

[Optional] Install the UCMA 3.0 SDK:

Sometimes you may want to modify some bits of the application or want to have more granular troubleshooting options and thus you need to install the Lync Server 2010 UCMA 3.0 SDK. This can be downloaded here:

http://www.microsoft.com/en-us/download/details.aspx?id=10566

With following the steps above, you should have a solid UCMA server for Lync Server 2010.

By Jürgen Pfeiffer and Rohit Jhangiani 

While troubleshooting push notification failure issues with a client, I found an interesting problem. The client had already configured the SRV record as required (http://blog.ucmadeeasy.com/), and disabled the URL filtering as required (http://support.microsoft.com/kb/2664650), but push notification was still failing with a 504 error code. To take it a step further, we completely disabled all IM filtering just in case. However, we still received a 504 error (server timeout) from the Push service.

As background, the Push Notification Clearing House (PNCH) runs in the office 365 Cloud using Lync Edge servers and dynamic federation. For more information on the three types of federation, refer to the article I wrote here: http://ocsguy.com/2011/04/20/a-few-words-on-federation/.

We were unable to troubleshoot the issue from the Office 365 side, so I decided to reconfigure my company’s Edge server with dynamic federation (it was configured with direct federation) and see if I could find any errors related to the customers configuration.

I began by removing the customer’s domain information from the Federated Domains tab within the Lync Server Control Panel in my Lync environment. Next, I signed into a test account on the customers Lync environment (jsmith@contoso.com) and attempted to IM an account in my environment (kevinp@tailspintoys.com). The IM failed immediately and I began reviewing the UCC API log from my client and the SIP Stack logs from my Edge servers.

It didn’t take long to find the 504 error in the logs, including some useful diagnostic information:

In the“ms-diagnostics” line, we saw “No match for domain in DNS SRV results” followed by the domain name (contoso.com) and the A record usim.us.contoso.com.

The problem lies within the A record the Federation SRV record is using. It doesn’t match the SIP domain.

Now you may be thinking “they are both contoso.com” and if you are, you are not alone! The catch, however, is there is a subdomain in the A record (usim.US.contoso.com) that does not exist in the SIP domain. This causes a failure to match the SIP domain with the SRV record. Since they don’t match, you would have to use Direct Federation instead of Enhanced or Dynamic Federation to federate with this organization. This would seem to be an easy fix, but since Office 365 only supports Dynamic Federation, the fix is a configuration change on the customer side.

To resolve the issue we created a new DNS A record to use for Federation (sip.contoso.com). We also updated the Access Edge certificate to include this name in the SAN field. Once these steps were completed, Push Notification began working on the mobile clients.

Lesson learned: As a best practice, make sure your DNS A records for Federation do not have a subdomain unless your sip domain does as well.

By Kevin Peters

Many organizations that deploy Lync Server 2010 encounter voice quality issues associated with the usage of a client VPN solution in combination with Lync 2010. When users connect to the corporate network using a VPN client, Lync media traffic is sent through the VPN tunnel. This configuration can create additional latency and jitter because media traffic must pass through an additional layer of encryption and decryption. The issue is compounded when the VPN concentrator is busy. Real time media traffic is not prioritized. This means that other network activity, such as a large file transfer, can potentially degrade the call experience of users.

To provide users with the best possible media quality, organizations should deploy a solution that prevents time sensitive real time media (voice/video) from traversing the VPN and simultaneously allows standard corporate network traffic to traverse the VPN.  When considering this solution organizations should know the following:

• All Lync 2010 traffic is encrypted by default. SIP signaling traffic is encrypted using TLS, and all media traffic (audio, video and application sharing) is encrypted using SRTP. Because of this, Lync traffic does not need to be routed through encryption tunnels unless your organization specifically requires dual layer encryption.
• The Edge Server was designed to provide superb media quality to Internet-based users. Because of this, media that relays through the Edge Server is typically more reliable and of higher quality than media, that traverses the corporate client VPN Solution.

Because end users typically require continuous VPN connectivity, it is not feasible for users to disconnect from the VPN before making or receiving Lync calls. The solution is to force Lync traffic around the client VPN, while allowing users to connect to other internal corporate resources. The solution encompasses the following areas:

• Create a split tunnel VPN configuration.
• Revise the Windows Firewall policy or corporate VPN firewall rules.
• Configure specialized DNS entries.

The Problem

Lync Server 2010 utilizes the Interactive Connectivity Establishment (ICE) protocol to establish media sessions between all Lync 2010 endpoints and servers. ICE attempts to establish media sessions between clients using all available ICE candidates on the client at the time of the call. Candidates are a combination of available IPv4 addresses and randomly allocated media ports on the machine with Lync 2010 installed. When a client VPN is connected, it often registers an IP address on a remote access interface on the client PC. Because of this, it is considered a valid IPv4 address; a candidate will be allocated for media connectivity to other clients. This is important because ICE tries candidates in the order shown below. When a media path is validated, the connectivity checks stop and the media is established.

1. UDP Direct- Physical (or virtual RAS) interfaces with IPv4 addresses assigned.

2. UDP NAT- Applies only when two users who are outside the corporate firewall are connected to the Lync infrastructure through the Edge Server. This scenario involves trying connectivity through the reflexive IP addresses for each home user. The reflexive IP address is the public IP address of the home router.

3. UDP Relay- Between two external users or an external user and an internal user. This connectivity is relayed through the public IP address of the Audio/Video Edge service.

4. TCP Relay- The relay address (Audio/Video Edge Server public interface) when connectivity is not available on UDP. TCP Relay is a last resort.

When a Lync 2010 user is connected through VPN and attempts to call an internal Lync 2010 client, or tries to establish a media session with a Lync 2010 Server (Mediation Server, A/V Conferencing Server), the traffic attempts to pass through the VPN interface and is considered a UDP Direct candidate. If this connectivity check succeeds, the media traverses the client VPN solution.

Figure 1. Lync 2010 Call Process through VPN- The Problem

This scenario is a common default configuration issue. The requirements below define a solution that forces Lync client traffic through the Lync Edge Server (UDP Relay candidates).

For more details on how ICE works for all Lync 2010 scenarios, see the Lync 2010 Resource Kit External User Access Chapter.

Solution Configuration

The solution to force VPN traffic through the Edge Servers must allow external Lync clients connected through VPN to do the following:

1. Connect to corporate and external resources (split-tunnel).

2. Resolve external DNS entries for the Lync Edge services, Lync Web Services and Exchange Web Services.

3. Register through the Lync Access Edge service.

4. Block connectivity from VPN connected Lync 2010 clients to all Lync Servers and all internal client subnets through the VPN tunnel. In our example, we used Windows Firewall to block this traffic. You can achieve similar results, however, if your VPN appliance has detailed rules to firewall client VPN traffic.

5.Allow VPN connected clients to establish media through the A/V Edge Server public interface.

Split-Tunnel VPN Policy 

To allow Lync traffic to reach the public IPs of all services, the VPN appliance must be configured to allow a split-tunnel.  A split-tunnel is a VPN connection that allows connections intended for internal resources to traverse the VPN. All other user requests are sent through the internet connection and bypass the corporate network.  For more information on spilt-tunnel VPNs read Split tunneling.

In most split-tunnel VPN scenarios, DNS is provided by an internal DNS server. The server needs to be configured as described in the section later in the article Specialized DNS entries.

Windows Firewall Policy

  

The above rules, used in conjunction with the remaining configurations, allow you to force Lync 2010 traffic to relay through the Edge Server.

As mentioned above, all Windows Firewall configurations shown here are created using the local Windows Firewall Snap-In.

Windows Firewall Policy Configuration Steps

To begin, create a new inbound rule for the Lync application (Communicator.exe).This rule needs to be a  Custom rule. See Figure 2 below.

Figure 4. Default Configuration for Protocol and Ports

Figure 5.VPN subnet defined as the local IP, VPN and corporate subnets defined as remote subnets.

Figure 7.Blocking configured to prevent connections from utilizing VPN based IP address

Specialized DNS Entries

Simple URLs

Just like SIP traffic, you must block all https pool traffic from entering the VPN.  All URLs defined for simple URLs and pool web services (including external web services FQDNs) must return a public IP address routed outside of the VPN tunnel.

Example:

Table 3. Example Simple URL DNS Entries

  

Figure 11.Lync client media bypassing the corporate VPN with windows firewall configuration

Ref Articles:

Information on A/V Edge Ports and Public IP Addresses

OCS 2007 R2: What’s new for Media Traversal?

 By Kevin Peters and Randy Wintle