Brian Rubarts' UC-blog

Remove Lync Server

leave a comment »

<Tip of the hat to Randy Wintle>

I ran into an issue removing an old server from a Lync Topology.  The error message when publishing the topology was:

Error: An error occurred: “System.InvalidOperationException” “Cannot publish topology changes. Conferences still exist on one or more deleted services.”

The solution:

  1. Use the Get-CsConferenceDirectory command in the Lync Management Shell to find the conference directory on the pool you want to delete.  There will be a number in the Identity field, and that’s what you need for the next command.
  2. Use the Remove-CsConferenceDirectory -Identity (number from above) -Force command.  If you don’t use the force parameter, it will give you an error if the directory isn’t empty.  You will be prompted to confirm your choice whether you use Force or not.  Simply enter a Y or A to finish executing the command.

Now you can publish the topology that deletes the server.  



Written by rubartsunifiedcommunications

July 25, 2012 at 3:54 pm

Posted in Uncategorized

Catapult Systems’ Conference Migration for Lync Solution Accelerator

leave a comment »

Soma Madhdhipatla (, a team member at Catapult Systems, has developed a utility that will migrate existing scheduled conference calls from third-party conference solutions (Webex, GotoMeeting, AT&T, etc.) over to Lync Server 2010.

Here is what it does:

  1. Read & identify users’ Exchange Server 2010 mailboxes to identify conferences/meetings which need to be migrated to Lync Server 2010 Online Meetings (including recurring meetings)
  2. Create Lync Online Meetings on behalf of meeting organizers
  3. Update the calendar item in the organizer’s mailbox with the Lync conference info
  4. Send updated meeting info (with new Lync conference data) to invitees

Whenever an organization decides to replace their existing conference service, tools such as this one will help to mitigate the impact upon the user community during the move.

Written by rubartsunifiedcommunications

July 16, 2012 at 9:40 pm

Posted in Uncategorized

Microsoft SIP Processing Language

leave a comment »

Sometimes you might like to modify the way that SIP messages are processed on Lync servers.  Microsoft SIP Processing Language (MSPL) allows you to do just that.  You can write a MSPL “message filter” to filter and route/reroute messages in Lync Server 2010 applications.

(HT: Ken Lasko for a really good example of using this feature to route calls that would fail without it)

What kinds of things can you do to a SIP message with MSPL?  Here is a short list of some of the capabilities:

AddHeader – Adds a header to the current SIP message

Fork – Creates a forked copy of the current message with its request URI field set to the supplied URI string.

Respond – Generates a SIP response to the current request message with the supplied status code and reason phrase

Proxy Request/Response – Proxies the current SIP request or response.

There are numerous values and parameters that can be queried, returned, etc. for the purposes of matching or filtering just the messages that you are looking for.  A full list of MSPL built-in functions can be found here.

Check out the  additional references below.


MSPL Scripting Reference:

Ken’s UC Blog:                    

Written by rubartsunifiedcommunications

April 7, 2012 at 3:29 pm

Posted in Uncategorized

Tagged with , ,

Lync Recording Options

leave a comment »

HT to Greg Tate, with additional reference here.

If you already have engaged audio in the conversation, you can use the Alt key to pull up the Menu bar and choose whether you record Audio, Video, IM, or Shared (Program, Desktop, etc.) Content.

Written by rubartsunifiedcommunications

March 30, 2012 at 4:32 pm

Posted in Uncategorized

Lync Mobility Introduction

leave a comment »

Mobile Services for Lync are provided by three components which must be installed.  They are:

  1. Microsoft Lync Server 2010 Mobility Service –  Provides IM/Presence and Lync contacts on mobile devices.  Install this on every Front End Server in each pool that will support mobile devices.
  2. Microsoft Lync Server 2010 Autodiscover Service Enables mobile devices to locate internal and external web service URLs, and the URL for the new Mobility Service. Auto-discovery uses lyncdiscoverinternal for users inside the network, and lyncdiscover for users outside the network (at each SIP domain). It supports both HTTP and HTTPS.  Install on every Front End Server and on every Director in each pool.
  3. Microsoft Lync Server 2010 Push Notification Service    You don’t install this.  It is a cloud-based service in the Lync Online datacenter. Inactive Lync mobile clients on Apple iOS or Windows Phone cannot respond to new events such as an IM invite, etc., because these devices don’t support the apps running in the background.  The Mobility Service uses the the cloud-based Push Notification Service to either send a notice to the Apple Push Notification Service (APNS), or to the Microsoft Push Notification Service (MPNS), which then forwards it to the mobile phone.

To get you started, here is a short list of things to know:

  • You need to update your Lync FE and Dir servers to at least here.
  • You can download the Word doc guide for Lync Mobility here, and it’s a pretty quick read.
  • You’re going to need to: Add some internal and external DNS records, Update internal and external certificates with the new FQDNs, Install the Mobility and AutoDiscover services on the FE and Dir servers, Update some firewall rules to permit new ports, and Set up federation with the push notification service


Technet –

MSUnified (good summary reference) –

Written by rubartsunifiedcommunications

March 28, 2012 at 11:09 pm

Posted in Uncategorized

Enhanced 911 for Lync Demystified

leave a comment »

Enhanced 911 is not merely 911.  If your employees never travel, and if they only use desktop phones for calling, then you can route your regular-old 911 calls to a land line or circuit that is already registered at a physical address.  This is incredibly simple to implement…but you will send emergency responders to the wrong place if your users move around and they use the Lync client on their computer to place and receive calls.  E911 solves that problem by ensuring that the full (and current) location information for the caller is passed along with 911 call.  Microsoft Lync Server 2010 supports E911 through the combination of Location Information Service, Locations Policies, a Lync-certified E911 provider, a Voice Route, and a PSTN Usage.  There are several good references available online, and I will list them at the end of this post, but I thought I would start with a Broad Overview of E911 in Lync

In a nutshell, Lync needs the following questions answered:

  1. What are your organization’s locations–including their official physical addresses?
  2. How will I know which location a user is currently at?
  3. What number will someone dial when they want to make an emergency call?
  4. Where do I route that call?
  5. When I send that call to the emergency responder, do I need to conference someone else into the call, and if so, should they only be able to hear, or should they be able to “barge into” the call?

The first question is answered by populating the CsLis database.  The best manner to do that depends on some other things, so let’s skimp on this point for now, but suffice it to say that you will need to gather the physical addresses for all of your locations, you will have to format the addresses in the proper way–where each address component is a separate element, and you will ultimately need to validate the addresses using a Lync Management Shell command Test-CsLisCivicAddress.

The second question is answered thusly:

You basically have three choices.  You can use the Wireless Access Point, if connected via Wi-Fi; you can use LLDP-MED and the switch/switch port, if connected via Ethernet; or you can use IP subnet.  Yes, you can combine methods to meet your requirements.  Lync users who take advantage of the client as a soft-phone on their laptops, however, won’t be able to use LLDP-MED without help from a special device.  Ergo, for your wireless users, WAP will be fine.  For desktop phones, LLDP-MED and switch port information will be fine.  Many times, though, the thing that is easiest to use for all users across the board is simply IP subnet.

The third question is answered in the Location Policy, where you can specify an emergency number of dial mask.

The fourth question is partially answered in two places.  In the Location Policy, you can specify the PSTN Usage for emergency calls by users with that particular policy, and of course you can apply the PSTN Usage to one or more Voice Routes to designate the PSTN Gateway(s) available for those emergency calls.

The fifth question is also answered in the Location Policy by selecting conferencing, and whether that conference will be One Way or Two Way.

Now, let’s move onto the E911 providers.

There are currently two certified E911 providers listed on Microsoft’s site: Level 3 Communications and 911 Enable.  911 ETC has a service that will work with Lync, too, and they are currently working on getting their service certified.  They don’t offer an on-premise gateway as an option like 911 Enable does, but they claim to offer significant cost savings on a comparable solution.  The best-known player in the E911 business is RedSky.  Whether they are a sailor’s delight or not, they have an impressive set of tools ans solutions, and lots of reference-able customers in government and education.  What they don’t, have, however is what Level 3 offers.  Level 3 offers integrated E911 services in their SIP trunk, which can be accessed over the Internet or a dedicated link.  It offers an affordable, relatively straightforward design, and easy-to-implement solution.

The process (which can be found here):

Phase of Deployment Steps RBAC Role(s) Required Documentation
Configure Voice Routes
  1. Create a new PSTN usage record. This is the same name that is used for the PSTN Usage setting in the Location Policy.
  2. Create a new voice route using the PSTN usage record created in the previous step and point to the SIP trunk.
  3. Optionally, create a local route for calls that are not handled by the emergency services provider’s SIP Trunk.
CSVoiceAdmin Configure an E9-1-1 Voice Route
Create Location Policies and assign them to users and subnets
  1. Review the global Location Policy
  2. Create a Location Policy with a tagged scope.
    Tagged scope means that the Location Policy can be assigned to either a user or a network site.
  3. Assign the Location Policy to Network Sites
  4. Add the appropriate subnets to the network site.
  5. (optionally) Assign the location policy to user policies.
CSVoiceAdminCSLocationAdmin (except for creating Location Policies) Create Location PoliciesAdd a Location Policy to a Network Site

Associate Subnets with Network Sites for E9-1-1

Configure the Location Database
  1. Populate the database with a mapping of network elements to locations.
  2. Configure the connection to the emergency services provider.
  3. Validate the addresses with the emergency services provider.
  4. Publish the updated database.
CSVoiceAdminCSLocationAdmin Configure the Location Database
Configure Advanced Features (Optional)
  1. Configure the URL for the SNMP application.
  2. Configure the URL for the location of the Secondary Location Information Service.
CSVoiceAdmin Configure an SNMP ApplicationConfigure a Secondary Location Information Service

Nagging Details (HT: Jason Black)

This article would hardly be worth writing if I didn’t include some of the little details that you would ordinarily not know about, or that you will easily forget…and will create hours of fun for you during the install:

  1. By default, the Global Trunk Group does not send PIDIFLO. This isn’t an issue if you aren’t using the global trunk for E911, but if you are, it would prevent the actual location info from being sent to the provider. Resolution: “Set-CsTrunkConfiguration -Identity Global –EnablePIDIFLOSupport $True
  2. Whenever you make changes to CsLis Sites or Subnets or whatever, you will need to Publish-CsLisConfiguration.
  3. Analog devices, lingering MOC clients, and other phones which come through a media gateway obviously cannot use Lync’s Location Information Services.  You will have to set up those numbers with your provider (or in another system, or one one of those special devices, or somesuch.

Further References on this topic worth taking a look at:

Written by rubartsunifiedcommunications

March 28, 2012 at 10:14 pm

Blocking US Premium Rate Telephone Numbers (900 Numbers) in Lync Server

with 3 comments

Let’s say that your company wants to prohibit dialing 900-numbers by its employees and visitors.  The official name for numbers in this NPA within the North American Numbering Plan is “Premium-Rate Telephone Numbers”.

Traditionally, you would use Telephony Class of Service to accomplish this goal.  With Lync Server 2010, that would entail you making sure that 1-900-xxx-xxxx is not included in any Route with an associated PSTN Usage that is applied to the Voice Policies applied to any users which you wish to prohibit dialing this number.  Then, if a user without a PSTN Usage associated with a Route that has a Match Expression that includes 900xxxxxxx, then the caller would receive a Fast Busy signal, and receive a notification in the Lync client that the number is not valid.    That meets the requirement to prohibit access to the numbers, but it is kind of a clunky administrative response to a bad call attempt.
A more elegant and flexible way of accomplishing the organization’s goal, however, might be to use an Unassigned Number Range and an Unassigned Number Announcement.
To do this, simply create number ranges for numbers that you wish to prohibit.  Then, assign an announcement to the range(s), and you are in business.
Benefits of this approach:
  • Customizable Announcement which can either be a file or Text-to-Speech
  • Customizable call forwarding action after the announcement is played
  • A Monitoring Server CDR entry for the call so that you will know exactly which number the employee/visitor actually tried to call

Step 1. (Optional) Make Sure You Can Normalize 900 Numbers.

If you don’t already have a Normalization Rule in the Dial plan to cover these
numbers, then you can use this:

MATCH EXPRESSION:                   ^1?(900|976)([2-9]\d{2}\d{4})$

If you already have a sufficient rule, then skip this step.

Step 2. Create Announcement

New-CsAnnouncement -Parent  -Name “Announce_USPremiumeRateNumbers” -TextToSpeechPrompt “We are sorry, but the Premium Rate Number you dialed is prohibited.  If you need to reach this number, please notify your manager.  Thank you.” -Language “en-US”

Step 3. Create Unassigned Number range(s)

New-CsUnassignedNumber -Identity “Range_USPremiumRate_900” -NumberRangeStart “+19000000000” -NumberRangeEnd “+19009999999” –AnnouncementService -AnnouncementName  “Announce_USPremiumRateNumbers”


One of your additional options in the New-CsAnnouncement command is to add a SIP Address to forward the call to after the announcement has been played.  If you have an Operator or Receptionist Response Group Workflow configured, then use its SIP address to send the call to.

For all practical purposes, you could start the number range at +1900200000 instead of +19000000000, since in the NANP, only 2-9 are valid first digits in the Nxx.

You might notice that my Normalization Rule match expression includes 976.  Technically, 976 is not in use in the NANP, but premium numbers used to exist in that range, and it never hurts to block something that has no current legitimate use.

Written by rubartsunifiedcommunications

August 4, 2011 at 5:14 am