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:

clip_image002

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)

clip_image003

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.clip_image005

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. clip_image007In 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

clip_image009Within 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.

clip_image011

c. clip_image012SIP 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. clip_image014The SIP Federated Providers tab is where you setup Public IM Connectivity to networks like Skype and Exchange Online as well as others.

e. clip_image016Lastly 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.

Advertisements

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 24×7, 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:LyncSynthTest1@yoursipdomain.com –SecondTestUserSipUri sip:LyncSynthTest2@yoursipdomain.com

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!

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:

 

image

 

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.

New Lync Server Updates are now available and it appears Microsoft has dropped the Month/Year naming convention instead just using the version code. 

The Lync Server Cumulative Updates 8308.815 are available here

I have reliably been using IIS ARR as a low cost replacement for ISA/TMG (Free with Windows Server!) for some time now however I recently had a customer that had provisioned Windows Server 2012R2 so I decided to use IIS ARR 3.0 instead of 2.5 which is what I have always used for previous installations. 

There is some good information online and I have always followed this NextHop post which has served me well. 

On the surface, IIS ARR 3.0 looks identical to 2.5 however, I ran into many challenges with rules not processing as you might expect under 2.5.  After much trial and tribulation I ended up deleting all my rules and starting from scratch and coming up with a different configuration combining some lessons learned from Lync MVP Richard Brynteson and his post

I thought I would share this here so I can reference it and perhaps help a few folks along the way.

Start with a fresh installation of Windows Server 2012 R2 and install IIS from Server Manager.  In this case I had a single NIC server that was both domain joined and on the corporate network.  Windows Firewall is enabled and the External Firewall was configured to allow both ports TCP 80 and 443 inbound in a 1:1 NAT configuration.

Download the Microsoft Web Platform Installer (currently 5.0) and search for IIS ARR 3.0.  Select it and install it. 

The open IIS Manager and the fun begins!

Initial Setup

You will need to make the following modification to the IIS Application Pool for the default web site which will force the application pool not to shut down after idle minutes.  Change the highlighted value to 0 shown below.

image

You will need to provision an SSL certificate from a public provider that will contain all the URLs required for Lync, Office Web App and potentially Exchange Server OWA if required.  I will assume that readers understand what these URLs are and will not get into those into too much detail nor the process of provisioning the certificate here.

Bind this certificate in IIS like you would any other secure website.  Choose the Default Web Site and select Bindings in the action tab on the right.  Click on Add and add a binding for Port 443.  Select the certificate you provisioned and installed on this server.

image

Next we can start building out the Server Farms.  In the IIS manager if you installed IIS ARR correctly you will see “Server Farms” as a new option in the left pane. 

You want to highlight it and right click and select New Server Farm.

Lets start with creating the Lync Autodiscover farm that will handle requests for Lync Autodiscovery to work. 

image

Click next and configure the settings as follows adding in the FQDN of the internal Lync Front End Server or Enterprise FE Pool that will handle this request.  Be sure to change the options as shown below as required by Lync.

image

Click Finish.  You will be prompted to create IIS re-write rules which you want to say Yes to.  We will address these a bit later.

Create another Server Farm for each External Web Service you need to publish.  If you have two pools you are publishing for you will need to create two farms in the same way as above.

Create a Server Farm for Office Web Apps in the same way as above except we use the default Port 80 and 443 for the Office Web App server.  If you have a pool of Office Web App Servers you can add each server in a single farm.

The results will look something like this when done.

image

Server Farm Settings

image

For each server farm you created click on the server farm and make the following changes to highlighted items:

1.  Disable Caching for each farm.

2.  Change the timeout values to 600 seconds in the Proxy settings. (This alleviates sign outs on the mobile clients especially with Android devices.

3.  Lastly under Routing rules deselect the Use SSL Offloading option.  If you fail to do this you will not see the URL Rewrite rules created.

URL re-write rules

Select the IIS Server name and double click the URL Rewrite option highlighted.

image

You will be presented with a total of two rules for every server farm you created.  So if you created 4 server farms, you will see 8 rules created.  Delete all the rules that do NOT end in _SSL. 

Office Web App URL Rewrite

Open the Office Web App rule that was created.  The names will match the server farm names.  Confi
gure it in the following way:

image

Use the regular expression pattern ((?:^en-us/|^hosting/|^m/|^o/|^oh/|^op/|^p/|^we/|^wv/|^x/).*) where shown.

Lync AutoDiscover

Configure the autodiscover rule, you are using the regular expression pattern of (.*) but then adding the condition {HTTP_HOST} matches the pattern of all the sip domains Lync Server is responsible for.  So if you had three domains, called contoso.com, acme.com and tailspin.com you can list them in separate lines or simply create them in one rule as follows:

lyncdiscover.contoso.com|lyncdiscover.acme.com|lyncdiscover.tailspin.com

image

Lync External Web Services

For each front end pool you must create a URL rewrite that corresponds to the server farm created in the first part of this setup.

This time you will need to add two conditions

{HTTPS} matches the pattern ON since we want to support HTTPS only in the Lync Web Service requests

and

{HTTPS_HOST} matches the pattern of your external web service URL along with all the other Lync Simple URLS required for your Front-End Pool.  In this case I have:

LyncWebExt01.contoso.com|meet.contoso.com|dialin.contoso.com|

meet.acme.com|dialin.acme.com|meet.tailspin.com|dialin.tailspin.com

image

Repeat this for all other farms substituting the main web service URL for the unique URL for each pool.  You can leave the other names in the list as they would only trigger if the previous rule is skipped in the event the first server pool is down for example.

Some Notes:

1. IIS ARR rules are order dependent and will run from top down until a condition is met.  By default once a rule is triggered the execution of rules will cease.

2. I find after making changes I do an IIS RESET /restart to speed up the process of changes taking effect. 

3. You can turn off Server Farms or disable servers within a farm if you are testing rules out and need to troubleshoot your settings.  This helps the second guessing on which rule is doing the processing.

4. If you use a multi NIC server you will still need to designate the NIC facing the Public internet as the default gateway and use Persistent Routes to the internally connected NIC.

5. This can be done to a domain joined machine or a non-domain joined machine.  If using a non-domain joined machine you will need to use a host file to resolve the names of the servers in each of the farms you create.  You will likely need to do this for a multi-NIC machine that uses DNS configuration pointing to Public DNS.

  • Update for Standard or Enterprise Edition server (Front End Servers and Edge Servers)
    2937310 – August 2014 Cumulative Update 5.0.8308.733 for Lync Server 2013 (Front End Server and Edge Server)
  • Update for Unified Communications Managed API 4.0, Core Runtime 64-bit
    2937311 – August 2014 Cumulative Update 5.0.8308.733 for Lync Server 2013, Unified Communications Managed API 4.0 Runtime
  • Update for Web Components server
    2937297 – August 2014 Cumulative Update 5.0.8308.733 for Lync Server 2013, web components server
  • Update for Core Components
    2937305 – August 2014 Cumulative Update 5.0.8308.733 for Lync Server 2013, core components
  • Update for Administrative Tools
    2967486 – August 2014 Cumulative Update 5.0.8308.733 for Lync Server 2013, Administrative Tools
  • Update for Web Conferencing server
    2937314 – August 2014 Cumulative Update 5.0.8308.733 for Lync Server 2013, Web Conferencing Server
  • Update for Windows Fabric
    2967486 – August 2014 Cumulative Update 5.0.8308.733 for Lync Server 2013
The cumulative updates resolves the following issues:
  • 2976568 – Address book delta files are not generated in a Lync Server 2013 Enterprise Edition environment
  • 2967626 – Error “creating procedure RtcResetAbAttributes” when you run “Install-CsDatabase” for rtcab database in Lync Server 2013
  • 2967629 – Significant bandwidth usage increase by SIP traffic in a Lync Server 2013 environment
  • 2967630 – Callee receives a missed call notification after answering a call on an IP telephone in a Lync Server 2013 environment
  • 2979931 – Error “I can’t find the meeting with that number” when PSTN user dials in to conference in Lync Server 2013 environment
  • 2978444 – Update for Lync Server 2013 to disable Lync Web App users’ ability to upload and show PPT in online meetings
  • 2976906 – Incorrect time zone is displayed when you create a meeting by using Web Scheduler in a Lync Server 2013 environment
  • 2967623 – Error “This content cannot be displayed” or blank webpage when you click a dial-in URL in a Lync Server 2013 environment
  • 2967624 – HD video stutters in a Lync Server 2013 based video conference in Lync 2013
  • 2967628 – Telephone numbers are missing in a contact card in a Lync Server 2013-based Lync mobile client
  • 2967621 – Error 404 when Lync phones sign in to Lync Server 2013 front-end servers during SBS failure recovery
  • 2967631 – Error “”DistributionGroupAddress” and “AgentsByUri” must be set.” when you migrate the RG service to Lync Server 2013
  • 2983199 – “Limited functionality is available due to outage” in Lync client when Lync Server 2013 replication queue is full

You will need to have the following pre-requisites installed:

MSO (KB2727096), MSORES (KB2817624), IDCRL (KB2817626), and Lynchelp (KB2817678).  These have likely been previously installed.

 

Client

Version

KB

Download

Lync 2013 Client 32-bit

15.0.4605.1003

2880474

Download

Lync 2013 Client 64-bit

15.0.4605.1003

2880474

Download