the UC Guys

Federation the Sequel

By Dino Caputo and Kevin Kieller, Partners at enableUC

Federation, or business to business collaboration, can significantly improve your interactions with key partners and suppliers. We have written previously that federation is a “game changer” and suggested that the Microsoft combined tools may create an ecosystem that delivers voice to over a billion connected users.

With Lync federation, you can connect with people outside your organization as easily as you can with people inside your organization. And once connected, you can communicate via instant messaging, voice, video or content sharing. Plus you see presence status for both internal and external contacts; noting that you can control what information you share with a particular external or internal contact by right clicking on the contact and selecting “Change Privacy Relationship”. You are given several granular choices that share no, limited or complete presence, contact and location information:

Federation is fantastic but how do you setup federation for your organization?

A pre-requisite for enabling federation is to deploy a Lync Edge Server. The Edge Server role in Lync enables external users who are not logged into your organization’s internal network, including authenticated and anonymous remote users, federated partners (including XMPP partners), mobile clients and users of public instant messaging (IM) services, to communicate with other users in your organization using Lync Server. The Lync Edge Server is deployed in the network DMZ and provides secure external access into your Lync environment.

Setting up A Lync Edge Server

Total Planning Time: 1 – 14 days (small company to Enterprise)

Total Execution Time: < 2 hours – 1 day (small to Enterprise)

1. Planning for the Edge Server(s) – Estimated Time to complete: 1 day (small company) up to 14 days (larger more complex organization)

The planning phase will likely take the longest in your quest for Lync Federation capabilities as it requires you to gather information about your network and make decisions about things like standing up the Edge Server in your Perimeter (DMZ) network, obtaining public and internal certificates, making firewall rule changes, possible load balancing requirements and publishing DNS records.

For the smaller company looking to deploy a Lync Edge Server, with the proper guidance, this might take only a day to plan and map out the logistics. Larger companies will take longer, simply because each of the items to consider are generally managed by different groups. Larger organizations may also want to provide multiple Edge servers for scale and high availability. Plan for at least two weeks of elapsed time to meet with all the appropriate groups, educate them on the requirements and to schedule and execute the required changes. This timing may vary depending on the complexity of your company and the availability of the various groups. For more information on planning for your Lync Edge infrastructure see http://technet.microsoft.com/en-us/library/gg399048.aspx.

Once you have gone through all the planning, educated the appropriate teams on the requirements and have the appropriate server(s) in place and ready to go!

2. Topology Builder – Add the Lync Edge Server to the Topology, Enable Federation and Publish the Topology. Estimated Time – 10 minutes to complete

Everything in Lync Server must first be created in the Lync Topology Builder - See http://technet.microsoft.com/en-us/library/gg398788.aspx As its name suggests, this is where you will define and build your Lync environment. Assuming you have already deployed a Lync Front End Server and are already using other features of Lync you would have already used the Topology Builder. In just a few minutes, you will create the Edge Server, defining all the carefully planned out information from the previous step. Here you will enable Federation for your Lync Deployment as shown. Once you publish your Topology you are ready to export the Edge configuration and install the Lync bits on your Edge Server(s)

3. Run the Lync Setup on each Edge Server. Estimated Time – 30-60 minutes to complete

Assuming your Public Certificate provider can turn around a certificate request immediately this process generally takes 30-60 minutes from start to finish.

Lync 2013 Deployment Wizard - This process actually installs Lync and the related required binaries that make Lync work.

Federating with a New Organization

Total Bureaucracy Time: 0 – unlimited minutes (small company to Enterprise)

Total Execution Time: 5 – 10 minutes

Given your Lync Edge Server is running you now need to configure options in order to allow users to federate with users from other companies running Lync.

In large organizations, the bureaucracy associated with approving a federation request can greatly exceed the technical time needed to execute the configuration change. Often this is the case because some individuals do not understand the security and user control options built into Lync.

Assuming you have approval to federate with a new domain, follow the process below to enable the required configuration:

1. From the Lync Control panel, which is a Silverlight browser based application, you need to review and set a number of configuration options as appropriate. Estimated Time – 5-10 minutes to complete

a. In the Lync Control Panel, External Access Policy Tab enable the required functionality. Here we enabling Federation, Remote user access and Public IM access at the Global Level. This can also be done at Site or User level.

b. Access Edge Configuration

Within the Access Edge Configuration you can specify whether or not you want to use “Open Federation” – Open Federation allows for automatic discovery of your Lync Edge server assuming you have published your external DNS records as per previous article. If Enable Partner Domain Discover is not checked then on the next tab “SIP Federated Domains” you will need to explicitly define all the domains you wish to federate with.

c. SIP Federated Domains – list of allowed or blocked domains – even though we previously specified open federation you can still list allowed domains here for a greater degree of “Trust” in terms of built in throttling protection that the Lync Edge has available to it.

d. The SIP Federated Providers tab is where you setup Public IM Connectivity to networks like Skype and Exchange Online as well as others.

e. Lastly the XMPP tab allows setup for XMPP based networks like Jabber or GoogleTalk

That completes the federation configuration. Users will now be able to federate!

Federation and remote access are both extremely powerful features provided by Lync that greatly improve communication efficiency at most organizations. If you have not already planned to deploy a Lync Edge server and enable federation, we would suggest you expand your plans.

Lync Real Time Monitoring

How can you proactively be alerted to problems in your Lync infrastructure?

How can you proactively be alerted to problems in your Lync infrastructure?

I work with many customers that don't have the luxury of using Microsoft System Center Operations Manager (SCOM) to monitor Lync Server. While I view and recommend SCOM as the preferred way to monitor Lync Server, I recognize that not every customer can make the investment required to do this.

If you have deployed Lync Server 2013 and are also using SCOM to monitor other Microsoft products, please refer to the TechNet article Configuring Lync Server to Work With System Center Operations Manager to get started on using SCOM to monitor your Lync deployment.

What about the rest of us?
So what about the rest of us that don't use SCOM and want to monitor Lync Server 2013? There are a several third-party solutions that can also provide monitoring for Lync Server: Solarwinds Performance Monitoring and Management offers an on premise alternative to SCOM, while Unify2 PowerMon for Microsoft Lync offers a cloud-based monitoring solution for Lync.

Similar to SCOM, Solarwinds offers a more traditional, robust health and proactive monitoring solution with the ability to monitor both the server and application health of your Lync deployment, as well as provide for some customizations in the alerting mechanism. Since it is an on-premises solution, it does require some planning and a dedicated server, potentially also including the use of an existing SQL Server depending on the size of your deployment.

Unify2 PowerMon is a cloud-based solution allowing you to proactively monitor without having to do any complicated server deployments, making it a compelling offering for organizations wanting to save on server footprint and those looking to get monitoring started very quickly. Unify2 offers a free version, called Powermon Standard, which will monitor all aspects of a Lync deployment for up to a single Lync pool. A paid version supports larger deployments and also allows for outbound PSTN call testing.

Lync Synthetic Transactions: Doing your own Lync Monitoring
Lync Server provides a number of PowerShell cmdlets that will allow administrators to validate specific Lync functionality using something called Synthetic Transactions.

But What the heck is a Synthetic Transaction? Imagine having the ability to have someone accessing your Lync environment 24x7, continually trying out all the features available, and giving you a "thumbs up" that all is okay or telling you there is a problem with a feature. Lync Synthetic Transactions allow you to do this--all without having to hire someone whose only job is to test Lync functionality for you all day and night long.

Lync Server 2013 currently provides 51 "Test" cmdlets that are available for administrators to 'simulate' Lync functionality as frequently as you want for your Lync deployment. You can have a look at the full list on TechNet here. Scroll down to the cmdlets that start with 'Test-Cs'.

Okay great, now what?
By configuring a couple of test users, you can run these 'Synthetic Transactions' simulating what real Lync users might do during the course of a day. If you automate these tests, you could script an alert to be sent out in the event one or more tests fail, for example.

So let's have a look at what you need to do to set this up:

Create your Test Users
Create two test accounts, say "LyncSynthTest1" and "LyncSynthTest2" in Active Directory and disable them. These accounts don't need to be enabled in Active Directory for you to take advantage of Synthetic Transactions. Your security folks will like that.

Enable them for Lync
Next, enable the created test user accounts for Lync in the Lync Control Panel or by using the Lync Server Management Shell. You should grant these users all the available Lync functionality you presently use today. For example, enable them for Enterprise Voice (DID optional but recommended if you want to test certain PSTN calling capabilities), Remote Access and Conferencing if you want to be able to test these Lync functions.

Configure the accounts for Synthetic Transactions in Lync
We will now configure these accounts in Lync. Lync Server allows you to predefine the test accounts that are generally required for the Test cmdlets so that you don't have to always specify users when running Lync Synthetic Transaction tests. This is documented here.

Putting it all together you might run something like this:

New-CsHealthMonitoringConfiguration –Identity MyLyncServer –FirstTestUserSipUri sip:[email protected] –SecondTestUserSipUri sip:[email protected]

Let's Start Testing
Now that we have defined our Health Monitoring Configuration, we can start testing. Let's test out Presence on the front-end Pool LyncSE1.mydomain.com by running the following cmdlet in a Lync Management Shell:

PS C:\Users\administrator> Test-CsPresence -TargetFqdn LyncSe1.mydomain.com

Target Fqdn : LyncSe1.mydomain.com

Result : Success

Latency : 00:00:00.0631549

Error Message :

Diagnosis :

This should yield a "Success" as shown above, indicating that presence is working between the test users you configured. To see more information about the test, run it again using the -verbose switch to get more details.

SCOM Does Synthetic Transactions too
System Center Operations Manager (SCOM) provides a management pack for Lync Server as well as an optional role called the "Watcher Node" (No this isn't the Keanu Reeves movie from 2000...) The Watcher Node is what SCOM uses to execute the Lync Synthetic Transactions and report back to it for alerting.

Monitor Away
Lync Synthetic monitoring can be a very powerful feature to use in your environment in order to alert you as soon as there is a problem. By coupling cmdlets with alerting mechanisms you can very easily deploy your own proactive monitoring solution or supplement an existing monitoring solution you are already running.

Whether you use SCOM, a third-party tool or "roll your own" solution, I can't stress enough how important it is to be proactive in your approach to managing and operating your Lync Server infrastructure - so monitor away!

SIP485 Ambiguous Error with Exchange UM when using SIP Trunking… How to use a main line phone number with extensions to avoid this.

There is a well known issue when using an E.164 dialplan in Lync Server that includes the extension portion the dial string (such as +14165551212;ext=1000) and assigning that to an Exchange UM AutoAttendant.  If you are using a provider that sends the full E.164 number that includes the + sign in the SIP Invite, Lync will not apply any normalization rules on this inbound call, assuming that you created a normalization rule that takes the 10 digit inbound number and adds the “;ext=” portion of the string to ensure uniqueness in the phone number.  This is well documented here by Ken Lasko at http://ucken.blogspot.ca/2011/05/enterprise-voice-best-practices-in-lync.html as well as some possible workarounds. 

In a pure SIP Trunking environment most certified providers will send the full E.164 number though to the Lync Server meaning you would need to use an MSPL script or add a gateway to do the manipulation required to allow this scenario to work.  I don’t like either of these workarounds in a SIP Trunking scenario because they add complexity and cost in the case of adding a gateway.  In Canada while working with ThinkTel I found a much better way to address this scenario.  It works like this. 

Lets assume you have a Lync deployment with Exchange Unified Messaging and you have a requirement to enable all users for Enterprise Voice but don’t want to utilize Direct Inward Dial numbers (DID) for all users.  Rather, you want to have a single main office number and have the Exchange UM Auto Attendant answer the call with a Speech Enabled Auto Attendant that can ask the caller whom they want to speak with.  The caller speaks the name and the call is transferred to the Lync user that does not have a DID.  In order to make this work in a scenario where you don’t have DIDs assigned to the user you must use E.164 numbers with extensions for a couple of reasons.  You need to maintain a unique number per user in Lync but at the same time advertise the single main line number for that group of users.  (Note, you might be thinking you can do this using Trunk level settings to overwrite the CallerID which would work for a single trunk.  But if you were supporting multiple locations over a single trunk then this breaks down.

So what you will need to do standardize on a single Main Line number, say +14165551212 and then assign that number to all your users including an extension.  So for Tom Jones, you would apply the LineUri or tel:+14165551212:ext=1005.  When Tom makes an outbound call the number that is shown is only the first part of main number of the office which is exactly what you want. 

So how do we get Exchange UM to answer the call now without the nasty SIP485 errors?   Ask your provider to do a CNF or Calling Number Forward for your main number of 4165551212 to another DID.  In this case use +14165551213 for example.  Assign this number to the Exchange UM AA that will answer the main office calls.  When  callers call 4165551212 number it will be forwarded unbeknownst to the caller to the other DID number allowing Lync Server to route the call over to the Exchange UM AA. 

This allows you to use a single number per main office and assign it to the Lync Users with a unique extension all while letting Exchange UM do its thing and answer the call.  The following diagram illustrates the call flow:

 

 

You can setup this scenario as many times as you need.  For example, one per office location you are supporting of this.

Please note that while works very well using ThinkTel, it may be an option for all SIPT providers.  Its best to discuss this scenario with them during your planning phase.