Limiting Call Forwarding and Simultaneous Ringing in Lync 2013

In Lync 2010, users were able to forward calls or setup simultaneous ringing to any number that they were able to call themselves.  This could lead to people forwarding all their calls to a long distance or even international number (assuming their voice policy allowed international calling).  This can lead to increased telephony costs to the company, and there wasn't very much the administrator could do to control this, short of disabling the feature entirely.
A new feature in Lync Server 2013 Enterprise Voice allows administrators to limit where users are able to setup call forwarding/simultaneous ringing.  You'll see the new option at the bottom of the voice policy screen in Lync 2013 Control Panel (as highlighted in red).

The selectable options are:

Route using the call PSTN usages (default) - essentially means to allow users to forward calls to any destination phone number they are allowed to call (the same behaviour as in Lync 2010).  So if a user is allowed to call international numbers, they will be allowed to forward/simultaneous ring international numbers. The option wording here could really use some improvement, because to me it doesn't make much sense as it currently stands.
Route to internal Lync users only - allows call forwarding/simultaneous ringing only to other Lync users within the company.
Route calls using custom PSTN usages -  allows administrators to limit call forwarding/simultaneous ringing to only the PSTN usages defined by the administrator.

When the last option is selected, the Control Panel will display a box where administrators can select the appropriate PSTN usages.  For instance, to limit call forwarding/simultaneous ringing to only local numbers, select a local PSTN usage, as shown below:

Administrators can add multiple usages to allow calls forwarding/simultaneous ringing to any combination of PSTN usages.  Since voice policies can be applied either globally, site-wide or down to the user level, this should allow administrators to grant different policies to any number of users.

This assumes the Enterprise Voice deployment has been designed granular enough to break out local, national and international calling.  If there is only a single catch-all usage for all calls, then this won't work and the Enterprise Voice configuration will have to be re-designed.

Luckily, the Lync Dialing Rule Optimizer (shameless plug) creates usages for local, mobile, national, premium, and international usages, which should be enough for any administrative need.

Unfortunately from the user's perspective, they won't get a notification in the Lync client if they try to forward/simultaneous ring a phone number that is outside the dialing areas allowed by their voice policy.

For example, assume a user's voice policy only allows forwarding/simultaneous ringing to local numbers. If the user sets up simultaneous ringing to a number outside the local dialing area, they won't get any feedback that it isn't allowed by the policy.  When someone phones the user, their Lync devices will ring as usual, but the simultaneous ring number simply won't ring.  This could generate an unnecessary helpdesk call, which could also confuse the helpdesk, if they haven't been made aware of the policy.

Similarily, the user doesn't get any feedback in the Lync client when setting up call forwarding to a number outside the allowed dialing areas.  In this case, calls will simply go straight to Exchange voicemail without attempting to forward.  However, the user will get an email stating the forwarding isn't allowed.  Slightly more helpful, but still likely to generate a helpdesk call.

Curiously, the interface still refers to Office Communicator, but since I'm still running Exchange 2010, maybe this is to be expected.

The situation would be greatly improved if the Lync client would be more informative in this respect.  In my perfect world, there would be no war, global warming would turn Canada into a tropical paradise, gin and tonic would flow freely from taps all around my house, and the Lync client would provide feedback like this when users try to forward to a number that isn't allowed:

A man can dream, can't he?

Either way, the new control administrators have to limit call-forwarding/simulring is a much needed new feature, and I'm glad it made it into Lync 2013.

Least-Cost/Failover Routing in the Lync Dialing Rule Optimizer

The Lync Dialing Rule Optimizer tries to take care of all the Enterprise Voice configuration necessary for all deployments.  On most fronts, it does a pretty good job (IMHO).  One area that has been lacking is the ability to automatically arrange PSTN usages to provide least-cost/failover routing for multi-site Lync deployments. Once an administrator has run the Optimizer for all their sites, they have to manually configure the voice policies to provide least-cost/failover routing.

If you're not familiar with how least-cost/failover routing works in Lync, please refer to my post on the subject in my Lync Enterprise Voice Best Practices series.

With version 9.0 of the Lync Dialing Rule Optimizer, Lync administrators now have the option to create least-cost/failover routing between all sites that have been deployed using the Optimizer (or at least follows the same naming conventions used by the Optimizer).

When the Optimizer-generated script detects multiple Lync sites, it will prompt the user if they want to apply least-cost/failover routing to the voice policy being generated.  If the user allows it, the Optimizer will add PSTN usages for all the other sites to the new voice policies.  This assumes the existing PSTN usages are named with the country abbreviation first, and ends with either Local, National, International etc in any of the languages currently supported by the Optimizer as in the following examples:  UK-Leeds-113-Local, IT-Rome-06-Nazionali.

The output can be best summarized by way of example.  Assume a company has Lync Enterprise Voice deployed in the following locations:

Toronto, Canada

Vancouver, Canada

London, UK

Rome, Italy

Belém, Brazil

After running the Optimizer script against all sites, the PSTN usages for the Toronto International user voice policy would look like this (you might want to sit down for this):

NA-ON-Toronto-416567-Local

NA-BC-Vancouver-604678-Local

NA-ON-Toronto-416567-National

NA-BC-Vancouver-604678-National

NA-ON-Toronto-416567-Premium

NA-BC-Vancouver-604678-Premium

NA-ON-Toronto-416567-Service

UK-London-20-Local

IT-Roma-06-Locali

BR-Belém-91-Local

UK-London-20-Mobile

IT-Roma-06-Cellulari

BR-Belém-91-Celular

UK-London-20-National

IT-Roma-06-Nazionali

BR-Belém-91-Nacional

NA-ON-Toronto-416567-International

NA-BC-Vancouver-604678-International

UK-London-20-International

IT-Roma-06-Internazionali

BR-Belém-91-Internacional

The Optimizer will group PSTN usages from the same country near the top, using the assumption that most of the calls will be made to in-country locations and that the fewer PSTN usages the system needs to evaluate for each call, the better.

The ordering is such that least-cost routing and failover routing will occur.  PSTN usages from other countries will be placed lower in the list while still providing least-cost and failover routing for all calls.  If there are multiple Lync sites out-of-country, the ordering of PSTN usages within the National and International usages will be somewhat random. Administrators should review the PSTN ordering to make sure it suits their needs.

It is assumed that premium numbers can only be dialed from in-country locations, so out-of-country premium PSTN usages are not assigned. Also, only the local service PSTN usage is assigned for similar reasons.

All calls will use the least-cost route where possible. If a route assigned to a specific usage is unavailable, calls will use a route in another site, again keeping the call in-country if possible.

With the inclusion of least-cost/failover routing in the Lync Optimizer, administrators now have a tool that can completely build the Enterprise Voice environment for even the largest enterprise-level Lync deployment.

As always, feedback is greatly appreciated. Let me know if you come across any issues with functionality or scalability as I haven't tested if there is a limit to the number of PSTN usages that can be assigned to a voice policy.

Blocking International Calls to Specific Countries in Lync

A question that often comes up in my travels is that Lync administrators want an easy way to allow users to dial internationally but exclude specific countries for some reason.

This is very easy to accomplish once you understand the ins and outs of regular expressions, and assuming you follow all my best practices regarding number normalization, and Enterprise Voice setup.  To summarize, every number a user enters in Lync should be normalized to E.164 standards, which starts with a + followed by the country code, then the area/city code and finally the local subscriber number.  A Canadian example (country code 1) would be +14165551111.  A UK example (country code 44) would be +442033334444.  If you use the Lync Dialing Rule Optimizer to create your Enterprise Voice configuration, you'll be all set.

When all numbers are normalized to E.164, and you already have separate usages and routes for local, national and international calls, it makes it very easy to design regular expressions that meet any specific criteria required by your business.

Say your company is based in North America, and is required to block international calls to Iran (98) and North Korea (850).  The Lync Dialing Rule Optimizer routing rule for international calls is this:

^\+[2-9]\d{6,14}$

This rule allows any number that doesn't start with a 0 or 1 to be routed out. Only North American countries (US/Canada and some Caribbean countries) use the country code 1.  All other country codes start with the digits 2-9.  So essentially, this rule allows calls to any international destination.

To block calls to Iran and North Korea, modify the rule to look like this (new stuff highlighted in yellow):

^\+(?!98|850)[2-9]\d{6,14}$

This will allow any number starting with 2-9, but excludes numbers that start with 98 or 850 as required.

If you're not in North America and used the Lync Dialing Rule Optimizer to create your Enterprise Voice setup, your international rule looks a little different, because we want to make sure that North American numbers are formatted correctly (as highlighted in blue), while making sure that it does not try to route national numbers as international (using UK +44 as an example, shown in green):

^\+((1[2-9]\d\d[2-9]\d{6})|(?(?!(44))([2-9]\d{6,14})))$

To block calls to Iran and North Korea using this example, modify the rule as follows (new stuff highlighted in yellow again):

^\+((1[2-9]\d\d[2-9]\d{6})|(?(?!(44|98|850))([2-9]\d{6,14})))$

Now, anybody who tries to dial a number in Iran or North Korea will be met with a notice that the call couldn't be completed.

This method is pretty granular as you could create separate routes to block countries selectively or for a specific group of users.  If you want to just block those numbers globally, you can use Unassigned Numbers to provide an announcement to users that those numbers are not allowed to be dialled. The only downside to that method is that you need to know in advance how long phone numbers are in the country you want to block.

Happy Enterprise Voicing everyone!

Localized UK Dialing Rules for the Optimizer

Using data from a number of web sources and some helpful users, I've been able to create customized Lync dialing rules for over 30 countries worldwide and made them available to all via the Lync Dialing Rule Optimizer.  These customized dialing rules account for country-specific dialing patterns for local, national, international, toll-free, mobile, premium and service numbers.

However, true localized dialing rules have been out of reach for countries other than those in North America until now.  For all non-North American countries, I have been forced to create generic dialing patterns for local numbers simply because I don't have access to any source of local dialing rule data.  This isn't generally a problem because most local dialing rules are different enough from other patterns that conflicts are rare.  For example,  a local dialing rule for a country might specify that the number start with digits 2-9 and are between 5 and 6 digits in length.  As long as there aren't any other dialing patterns in that country that use that same pattern (ie national, international, mobile, service, toll-free or premium), there won't be a problem.  I try to make sure that is the case for all dialing rules created for the Optimizer, but it is sometimes difficult.

The United Kingdom has more than 60 different local dialing rules. Local numbers can be 4 to 8 digits in length and area codes have from 2 to 5 digits. Some 41 area codes have mixed length numbers where some numbers have a total 10 digits and others have only 9. In some area codes the local number cannot begin with certain digits, or certain digits will not come into use for many decades.  The generic UK local dialing rule used by the Optimizer tries to account for all these in a single regular expression, but obviously some generalizations had to be made.

Enter Ian Galpin of the UK.  Ian has made it a personal mission to ensure that the UK has a complete set of dialing rules written as regular expressions.   Over the past year, he's helped me ensure the regex for UK dialing rules are correct.  He's also created a localized set of dialing rules for every area code in the UK as an XML file along with a list of all the area codes used in the UK.  He's done this to help various telephony vendors create the appropriate rulesets for PBX deployments. I've been able to incorporate that into the Lync Dialing Rule Optimizer, so that UK users now have true customized local dialing rules for Lync that will differ depending on which area code you select in the Optimizer.

I've modified the Optimizer code to be able to use local dialing rules for other countries if available.  If anybody can point me to a similar source as provided by Ian for other countries, it would be greatly appreciated.

Lync 2013 is Code-Complete

For those who haven't heard through Twitter or other channels, Lync 2013 is code-complete, with a general availability target of first quarter 2013 as part of the Office 2013 suite.  It isn't clear from the announcement, but this is for the Lync 2013 CLIENT, not server.  Since Exchange 2013 and Sharepoint 2013 have been announced, I'm sure we'll be hearing about Lync Server 2013 achieving the same milestone fairly soon.

UPDATE: Well, confusion reigned among some of the MVP mailing lists.  While some were saying the Lync 2013 announcement was for the client, others were saying it was for the server.  Seeing how all the other servers in the "suite" have been announced, I think its safe to say that Lync Server 2013 is part of it.

Lync Branch Site Options and Recommendations

A large-scale Lync deployment typically consists of at least one central site that contains either a Standard or Enterprise Edition pool and one or more branch sites that don't warrant having a full-blown Lync deployment, but still need local voice connectivity in case of a WAN outage.

You have 4 options when considering what to deploy at a branch site:

1. Survivable Branch Appliance (SBA) - an all-in-one solution that consists of a PSTN gateway with the appropriate interface required for connectivity to the PSTN and a "Lync-Lite" installation that has only the Lync registrar and mediation server roles.
2. Survivable Branch Server (SBS) - A "Lync-lite" installation containing the Lync registrar and mediation server roles.
3. A PSTN gateway and a standalone Lync mediation server
4. A full-blown Lync deployment (typically Standard Edition)

Microsoft doesn't give much guidance as to which option is right other than saying that an SBA is appropriate for branches up to 1000 users, an SBS or 2 SBAs is good for 2000 users, and anything beyond that should be a Standard Edition Server.

What a lot of people don't realize is that there is more to consider than simple user counts.  Let's start by looking at where an SBA is appropriate, and where it isn't.

Survivable Branch Appliance

As noted earlier, a Survivable Branch Appliance is an appliance that contains a PSTN gateway along with a small Windows Server 2008 R2 deployment with the Lync registrar and mediation server roles. SBAs are purchased from vendors such as NET, Audiocodes, Dialogic, or Ferrari, among others. An SBA is paired with a central site that has a full-blown Lync deployment and is designed to be dropped into an office that doesn't have much local IT support.

Lync clients are homed on an SBA, and will register/login directly against it. PSTN calls are routed through the mediation server role and onto the PSTN gateway component of the SBA.

While clients register against the SBA, their contact list is still homed on the central Lync deployment.  Also, all conferencing features and response group functionality is provided by the central Lync deployment.  So, if the WAN link between the central site goes down, clients will lose their personal contact list, the ability to do multiparty web/video conferencing and any response groups whose phone numbers terminate on the SBA won't work.  This is beautifully illustrated by VOIPNorm on his blog post on the topic.  What DOES work is one-to-one IMs/telephone calls, PSTN calling, searching for contacts and any other features that don't require the full Lync deployment's involvement.  Again, see the blog post by VOIPNorm for full details.

When to Use a SBA and When Not To

Use an SBA when you your site meets the following criteria:

• Up to 1000 users (2000 if you use 2 SBAs)
• Have a T1/E1 or analog connection to the PSTN
• Won't miss conferencing or response group functionality during a WAN outage
• Have limited IT staff on site

Don't use an SBA if your site meets any of these criteria:

• Does a lot of conferencing and has a slow/expensive WAN pipe to the central site.  Conferencing services come from the central pool, so this can be a strain on WAN resources.
• Requires high availability for conferencing features and/or Response Group services
• Use a SIP trunk for PSTN connectivity, unless the SBA can be configured as a SIP gateway and doesn't have PSTN interfaces you don't need (they aren't cheap)

Survivable Branch Server

A Survivable Branch Server (SBS) has the same capabilities as an SBA, but without the PSTN gateway component.  It isn't something that you purchase from a vendor.  It's simply a "Lync-lite" server you define in the topology and install yourself on a regular Windows Server 2008 R2 (or Windows Server 2012 for Lync 2013) server.  Like the SBA, it only has the Lync registrar and mediation server roles.

Incidentally,  you won't see an option to define an SBS in the Lync topoology.  Your only option is an SBA.  Since the functionality of the Lync portion of the SBA is identical for an SBS, it doesn't need to be defined separately. Lync doesn't care if the PSTN gateway is part of the same chassis as in an SBA or a separate component as with an SBS.

When to Use a SBS and When Not To

Use an SBS when your site meets the following criteria:

• Have up to 2000 users
• Have the local infrastructure to support a full-blown Windows Server deployment (either VM or physical server)
• Have a SIP trunk connection to a Lync-certified SIP provider, or you already have a standalone PSTN gateway
• Won't miss conferencing or response group functionality during a WAN outage
• Have at least some local IT staff

Don't use an SBS if your site meets any of these criteria:

• Does a lot of conferencing and has a slow/expensive WAN pipe to your central site. Conferencing services come from the central pool, so this can be a strain on WAN resources.
• Requires high availability for conferencing features and/or Response Group services
• Have either a T1/E1 or analog service for PSTN access. You would still need to purchase a PSTN gateway, and would probably be better served by using an SBA (unless either of the above 2 points apply)

PSTN Gateway and Mediation Server

This option is an interesting one in that I've not seen it "in the wild".  A site with just a mediation server role is entirely dependent on the WAN link to the central site. If the WAN goes down, then so do your clients. You need the infrastructure to support a Windows installation, something many small branch sites don't have.  If you have a SIP trunk connection, you may not need a PSTN gateway at all.  Conversely, you may not require a mediation server if you use media bypass to send client audio traffic directly from the client to the PSTN gateway.

When to Use this Option and When Not To

Use a PSTN Gateway/mediation server when your site meets the following criteria:

• You have a 100% reliable WAN connection to your central site or your users will be OK with no functionality in the event of an outage

Don't use a PSTN Gateway/mediation server if your site meets the following criteria:

• Your WAN isn't reliable

Standard Edition Deployment 

Sometimes, you will need a full-blown Lync deployment at your branch site.  With even just a Standard Edition server, local clients will get all the functionality Lync has to offer, so WAN outages won't be a big issue.

When to Use this Option

Use a Standard Edition server when your site meets one or more of the following criteria:

• You have more than 2000 users in a site
• Your WAN link reliability is low
• Your users do a lot of conferencing with each other
• You need local Response Group functionality

Hopefully, this post will give you some better guidance as to what branch role to deploy at your sites. If you have any questions or comments, please let me know. By the way, the above is relevant for both Lync 2010 and Lync 2013.

What's New in Lync 2013

With the recent announcement about Lync 2013 (previously known in beta circles as Lync 15), I'm sure everyone is interested in what's new. Lync 2013 doesn't re-invent the wheel when compared to Lync 2010.  Lync 2013 builds on the features introduced in Lync 2010 in a way that makes Lync 2013 a compelling upgrade. Here is a quick rundown of the new features (note this is information from the beta product so things may change before its final release):

Roles

There has been significant role consolidation in Lync 2013.  There is no longer a separate server role for monitoring and archiving.  Each front-end server communicates directly with the monitoring and/or archiving database, eliminating the need for a separate monitoring/archiving server.

You can no longer install the A/V conferencing server role separately.  It is now always co-located with the front-end role.

Directors are now an optional role, which is kind of funny because I've always treated them as optional myself.

DR/High Availability Options

Lync 2010 introduced the concept of a backup registrar.  When a user's home pool becomes unavailable, the client can automatically register with a pre-defined backup pool.  This maintains basic voice availability, but the client loses conferencing capabilities, and the user's contact list is unavailable.  In Lync 2013, users will maintain nearly all functionality in the event of a failed pool.  This is made possible because all user data is now replicated between all Lync servers in the enterprise.  Every server maintains multiple copies of the user database, so there is almost no reduction in service availability.  I say "almost" because Response Groups are still not highly available (something that was sorely missed in Lync 2010).  So, should you suffer a failure on your home pool that hosts response groups, those response groups will not be available.

Each front-end server stores a complete copy of all the databases stored in the SQL back-end, so if the back-end SQL database server is unavailable, the front-end will still function.

Also, Lync 2013 supports SQL mirroring on the back-end databases.  This can reduce hardware costs typically associated with the older clustering options in SQL (separate shared storage). 

Enterprise Voice

In Lync 2010, if you had multiple mediation servers connecting to the same PSTN gateway or SIP trunk, you had to fake the Topology Builder out by creating multiple DNS A records pointing to the same IP.  Lync 2013 now supports M-N trunk routing.  This allows you to have multiple trunks to different gateways, and a gateway to have multiple trunks to different Mediation Servers.

Lync 2013 includes support for inter-trunk routing. This feature allows Lync to act as an intermediary between two or more different phone systems.  For example, Lync can accept calls from one PBX, and pass the call through to another PBX. This can be very useful in larger environments and allows Lync to be the backbone of a corporate telephone network.

In Lync 2010, you could use trunk translation rules to modify the CALLED phone number before passing it to the next hop.  However, you couldn't make any changes to the CALLING number (ie the person making the telephone call).  Lync 2013 now allows you to make changes to both the called and calling number.  This is very useful when the PSTN provider does not accept E.164 formatted phone numbers. For example, in North America, many PSTN providers do not accept the country code 1 as part of the number and only accepts 10-digit numbers.  In the past, an external gateway would have to do the necessary manipulation, but with Lync 2013, all the number manipulation can be done in Lync.

There are also several other new Enterprise Voice related enhancements. Delegates can setup simultaneous ringing to their mobile devices for incoming calls to their manager. When a user has setup simultaneous ringing to a mobile phone, and the device is turned off or out of range, Lync 2013 can determine that an incoming call was immediately routed to voicemail, and disconnect that endpoint so the call can continue to ring other endpoints. Caller ID presentation allows administrators to modify the Caller ID format in a much more scalable way than in Lync 2010, which only allowed Caller ID changes based on the route. 

Response Groups

Not much has changed here, but you can configure Response Group Managers and Administrators, allowing you to delegate Response Group tasks to other users.  If this seems familiar, its because that feature was in OCS 2007 R2, but was removed from Lync 2010 for some reason.

Integration with Lync Online

You can now create hybrid deployments with a mix of on-premises and Lync Online servers (similar to Exchange 2010).  This means that you can have some users running "in the cloud" and some users on traditional on-premises servers.  Microsoft calls this "hybrid voice".  You can also have all your users running in Lync Online and make calls via an on-premises PSTN gateway. This means you can allow Lync Online users to dial legacy PBX extensions, or make calls via a traditional PSTN connection (T1/E1 or similar) in situations where SIP trunking isn't desirable or an option.  Media bypass will work in this situation, so a user's media stream won't be hairpinned through the Lync Online service when making phone calls from an office running a local PSTN gateway. 

Mobility

Mobile clients will finally get the featureset people have been asking for.  Mobile clients will be able to make audio and video calls from their mobile device using either a mobile data connection or wi-fi. I have no idea if this will be available at launch or sometime after.  There isn't a Lync 2013 mobile client available yet that I've seen, but there are definite signs around mobile A/V in some updated Powershell commands like Get-CSMobilityPolicy. I saw an early demo of Lync 2013 on a tablet running Windows 8, and it pretty much guaranteed I'll be buying a Windows 8 tablet when it comes out.  Lync on a tablet was just THAT cool. 

Persistent Chat

Persistent chat (or group chat), is now a full-fledged Lync service, unlike older versions which was really just tacked on (and quite poorly, in my opinion).  You now define servers in the Topology Builder as with other roles, and the persistent chat features are included in the base Lync 2013 client (no separate client required).

Other New Features

Other features that don't fall into the above categories include:

• Full A/V capabilities on the Lync Web App client
• Full IPv6 support
• VDI plugin - allows full A/V support in virtual desktop environments
• H.264 SVC codec support
• Skype federation support

There are a lot of other small enhancements that go a long way towards improving the overall product or enhancing usability.  If I were to go into detail here on all of them, it would become a very long post.  I will do future deep-dives into some of the specific improvements at a later time.

Get the preview here.
Technet documentation.

Useful Lync Powershell Scripts

I find myself having to create and use the same Lync Powershell scripts over and over again, so I thought I'd compile a list of some of the ones I've created for others.  It will get updated as time goes on.

Enjoy, and suggest others in the Comments.

Finding all the people who have a telephone number set in Lync
Get-CsUser -Filter {LineURI -ne $NULL} | FT Name, LineURI

Change SIP domain for all users

$UserList = Get-CsUser 

foreach ($User in $UserList)

{

   $oldAddress = $User.SipAddress

   $newAddress = $oldAddress -replace "@olddomain.com", "@newdomain.com"

   Set-CsUser -Identity $User.Identity -SipAddress $newAddress

}

Setting the AD office phone number to the TelURI for all users
#Only need to add the AD Powershell instance once
Add-WindowsFeature RSAT-AD-Powershell
Import-Module ActiveDirectory

$users = Get-CSUser

Foreach ($user in $users)
{
   $Tel = $user.LineURI
   $Tel = $Tel.Replace("tel:", "")
   If ($Tel -ne "")
   {
      Set-ADUser -Identity $user.SAMAccountName -OfficePhone $Tel
   }
}

Enable All Users in a Group for Lync Enterprise Voice
#Uses existing office number in AD for Enterprise Voice
Import-Module ActiveDirectory

$Users = Get-ADGroupMember lync_group

ForEach ($User in $Users)
{
    Enable-CsUser $User.SamAccountName -RegistrarPool LYNCPOOLNAME -SipAddressType EmailAddress
    $OfficePhone = (Get-CSADUser $User.SamAccountName).Phone
    $OfficePhone = $OfficePhone -replace "\D", ""
    Set-CSUser $User.SamAccountName -EnterpriseVoiceEnabled:$TRUE -LineURI "tel:+$OfficePhone"
}

Move All OCS Users Homed on a Specific Pool to Lync
Also sets conferencing policy and external access policy to automatic, rather than the legacy migrated OCS policies.  Replace items in bold with your environmental specifics.

get-csuser -OnOfficeCommunicationServer | Where {$_.HomeServer -eq "CN=LC Services,CN=Microsoft,CN=OCSPOOLNAME,CN=Pools,CN=RTC Service,CN=Services,CN=Configuration,DC=contoso,DC=com"} | Move-CsLegacyUser -Target LYNCPOOLFQDN -ExcludeConferencingPolicy -ExcludeExternalAccessPolicy -Confirm:$FALSE

Count How Many Users are on OCS and Lync
(Get-CsUser -OnOfficeCommunicationServer).Count
(Get-CsUser -OnLyncServer).Count

Get a List of All Lync-Enabled Users Along with Selected AD Properties
#Asked by a commenter. Harder than it initially looked....

$ErrorActionPreference = 'SilentlyContinue'
Import-Module ActiveDirectory
$Output = @()

Foreach ($LyncUser in Get-CSUser -ResultSize Unlimited)
{
$ADUser = Get-ADUser -Identity $LyncUser.SAMAccountName -Properties Department, Title, Mail
$Output += New-Object PSObject -Property @{DisplayName=$LyncUser.DisplayName; Department=$ADUser.Department; Title=$ADUser.Title; SAMAccountName=$ADUser.sAMAccountName; Mail=$ADUser.Mail; SIPAddress=$LyncUser.SIPAddress; LineURI=$LyncUser.LineURI; EVEnabled=$LyncUser.EnterpriseVoiceEnabled}
}

$Output | Export-CSV -Path .\Output.csv
$Output | FT DisplayName, Title, Department, SAMAccountName, Mail, SIPAddress, EVEnabled

Create Lync Network Sites and Subnets using Info from AD Sites & Services
http://ucken.blogspot.ca/2013/04/automatically-creating-lync-sites-and.html

Add Enterprise Voice Users to an AD Group
Foreach ($User in get-csuser -filter {EnterpriseVoiceEnabled -eq $TRUE})
{Add-ADGroupMember -Identity -Members $User.SamAccountName}

Enable All Users in an AD Group for Lync EV/Exchange UM
#Takes the office number from AD, assuming its formatted correctly, extracts the last 4 digits to use
#as the extension (for dialin conferencing), and uses it for the LineURI and extension for UM.

Import-Module ActiveDirectory

#Import Exchange Powershell
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://EXCHANGESERVERFQDN/PowerShell/ -Authentication Kerberos
Import-PSSession $Session

$Users = Get-ADGroupMember TARGETADGROUP

ForEach ($User in $Users)
{
    Enable-CsUser $User.SamAccountName -RegistrarPool LYNCSERVERFQDN -SipAddressType EmailAddress
    $EmailAddress = Get-CSADUser $User.SamAccountName).WindowsEmailAddress
    $OfficePhone = (Get-CSADUser $User.SamAccountName).Phone
    $OfficeExt = $OfficePhone.Substring($OfficePhone.Length - 4)
    $OfficePhone = $OfficePhone -replace "\D", ""
    $OfficePhone = $OfficePhone + ";ext=" + $OfficeExt
    Set-CSUser $User.SamAccountName -LineURI "tel:+$OfficePhone"
    Set-CSUser $User.SamAccountName -EnterpriseVoiceEnabled:$TRUE
    Enable-UMMailbox $User.SamAccountName -UMMailboxPolicy "UMPOLICYNAME" -SIPResourceIdentifier $EmailAddress -Extension $OfficeExt
}

List All Remote PowerShell Sessions On A Machine
Get-WSManInstance -ComputerName COMPUTERNAME -ResourceURI Shell -Enumerate | FT Owner, ClientIP, State

Lync Dialing Rule Optimizer Gets Optimized

It was recently brought to my attention that some of the normalization rules created by the Lync Dialing Rule Optimizer in certain cases were not being used by the Lync client.  Specifically, the issue only arises if you select the option for the Optimizer to create 7-digit local dialing rules (only available for North America dialing rules).  The 7-digit rules are simply never used.  If you enter a 7-digit number that should be normalized to a 11-digit E.164 North American phone number, it doesn't happen.  Interestingly, if you use the Lync Voice Routing Test Case applet in the Lync Control Panel, you'll see that it normalizes just fine.

I did some testing of my own, and found out that the first part of the 7-digit rules were causing the Lync client to ignore the entire rule.  The first part of each 7-digit normalization rule is this cryptic piece of regex:

(?=^\d{7}$)  

This bit of regex says that whatever number is entered has to be a total of 7 digits long. The rest of the regular expression dictates the allowable first 2 or 3 digits for that particular area code.  At the time, this was the only way I could think of to ensure the total number of digits entered was exactly 7.

I put the question to Microsoft, who acknowledged that the server and the client can use different criteria for evaluating the validity of regular expressions.  It may be fixed in a future patch, but rather than waiting, I went about figuring out how to ensure 7-digit numbers without that bit of cryptic regex at the beginning.

After a good amount of research, work, and testing, I was able to figure out a way to ensure 7 digits in a much simpler way.  At the same time, I got a bit of regex schooling by Dan Berry of Acrodex. He told me I had way too many brackets in my regular expressions, so with his prompting, I was able to reduce the number of brackets by quite a bit.  He also gave me some other ideas for reducing the length and complexity of my regular expressions. 

The end result is a much shorter and more robust set of regular expressions for all the North American local dialing rules.  For example, one ruleset for Toronto, ON used to be 820 characters long.  With the new optimizations, the character count is down to 621.  This reduction can result in fewer rules, especially in larger cities. 

If you've previously used the Optimizer to create your rulesets for 7-digit dialing, I recommend you apply the updated rules.  If you subscribe to the monthly email rule update, then you'll get the updated ruleset starting next month.  If you come across any issues with the new rules, please let me know.

Holiday Sets for Lync Response Groups

If you use Lync Response Groups, you have probably noticed the lack of any built-in holiday definitions for any country. Setting these up yourself is a labour intensive and very boring process using Powershell. I figure I'd take the time to publish the commands necessary to setup the default holidays for both US and Canada.

First, copy and paste the holiday definitions into the Lync Management Shell as shown below.  If the dates and/or actual holidays are incorrect for your site, go ahead and change them.

2016 Holidays

$NewYear = New-CsRgsHoliday -Name "New Year's Day 2016" -StartDate "1/1/2016" -EndDate "1/3/2016" $MLK = New-CsRgsHoliday -Name "Martin Luther King Jr. Day 2016" -StartDate "1/18/2016" -EndDate "1/19/2016" $Fam = New-CsRgsHoliday -Name "Family Day 2016" -StartDate "2/15/2016" -EndDate "2/16/2016" $Pres = New-CsRgsHoliday -Name "Presidents Day 2016" -StartDate "2/15/2016" -EndDate "2/16/2016" $GoodFri = New-CsRgsHoliday -Name "Good Friday 2016" -StartDate "3/25/2016" -EndDate "3/26/2016" $EastMon = New-CsRgsHoliday -Name "Easter Monday 2016" -StartDate "3/28/2016" -EndDate "3/28/2016" $Victoria = New-CsRgsHoliday -Name "Victoria Day 2016" -StartDate "5/23/2016" -EndDate "5/24/2016" $Memorial = New-CsRgsHoliday -Name "Memorial Day 2016" -StartDate "5/30/2016" -EndDate "5/31/2016" $CADay = New-CsRgsHoliday -Name "Canada Day 2016" -StartDate "7/1/2016" -EndDate "7/2/2016" $USDay = New-CsRgsHoliday -Name "US Independence Day 2016" -StartDate "7/4/2016" -EndDate "7/5/2016" $Civic = New-CsRgsHoliday -Name "CA Civic Holiday 2016" -StartDate "8/1/2016" -EndDate "8/2/2016" $Labour = New-CsRgsHoliday -Name "Labour Day 2016" -StartDate "9/5/2016" -EndDate "9/6/2016" $Columbus = New-CsRgsHoliday -Name "Columbus Day 2016" -StartDate "10/10/2016" -EndDate "10/11/2016" $CA_Thanks = New-CsRgsHoliday -Name "CA Thanksgiving 2016" -StartDate "10/10/2016" -EndDate "10/11/2016" $Veterans = New-CsRgsHoliday -Name "Rememberance/Veterans Day 2016" -StartDate "11/11/2016" -EndDate "11/13/2016" $US_Thanks = New-CsRgsHoliday -Name "US Thanksgiving 2016" -StartDate "11/24/2016" -EndDate "11/25/2016" $Christmas = New-CsRgsHoliday -Name "Christmas 2016" -StartDate "12/25/2016" -EndDate "12/27/2016" $Boxing = New-CsRgsHoliday -Name "CA Boxing Day 2016" -StartDate "12/27/2016" -EndDate "12/28/2016"

Then run this Powershell command to create the holiday set. Replace YOURPOOLFQDNHERE with the actual name of the Standard or Enterprise Edition pool you want to create the holiday set. If your company has different holidays (ie Banks/government in Canada get Easter Monday off), add them to the holiday list (ie $EastMon)

For US
New-CsRgsHolidaySet -Parent "ApplicationServer:YOURPOOLFQDNHERE" -Name "2016 US Holidays" -HolidayList ($NewYear, $MLK, $Presidents, $GoodFri, $Memorial, $USDay, $Labour, $Columbus, $Veterans, $US_Thanks, $Christmas)

For Canada
New-CsRgsHolidaySet -Parent "ApplicationServer:YOURPOOLFQDNHERE" -Name "2016 CA Holidays" -HolidayList ($NewYear, $Fam, $GoodFri, $Victoria, $CADay, $Civic, $Labour, $CA_Thanks, $Christmas, $Boxing)

2017 Holidays

$NewYear = New-CsRgsHoliday -Name "New Year's Day 2017" -StartDate "1/1/2017" -EndDate "1/3/2017" $MLK = New-CsRgsHoliday -Name "Martin Luther King Jr. Day 2017" -StartDate "1/16/2017" -EndDate "1/17/2017" $Fam = New-CsRgsHoliday -Name "Family Day 2017" -StartDate "2/20/2017" -EndDate "2/21/2017" $Pres = New-CsRgsHoliday -Name "Presidents Day 2017" -StartDate "2/20/2017" -EndDate "2/21/2017" $GoodFri = New-CsRgsHoliday -Name "Good Friday 2017" -StartDate "4/14/2017" -EndDate "4/15/2017" $EastMon = New-CsRgsHoliday -Name "Easter Monday 2017" -StartDate "4/17/2017" -EndDate "4/18/2017" $Victoria = New-CsRgsHoliday -Name "Victoria Day 2017" -StartDate "5/22/2017" -EndDate "5/23/2017" $Memorial = New-CsRgsHoliday -Name "Memorial Day 2017" -StartDate "5/29/2017" -EndDate "5/30/2017" $CADay = New-CsRgsHoliday -Name "Canada Day 2017" -StartDate "7/1/2017" -EndDate "7/2/2017" $USDay = New-CsRgsHoliday -Name "US Independence Day 2017" -StartDate "7/4/2017" -EndDate "7/5/2017" $Civic = New-CsRgsHoliday -Name "CA Civic Holiday 2017" -StartDate "8/7/2017" -EndDate "8/8/2017" $Labour = New-CsRgsHoliday -Name "Labour Day 2017" -StartDate "9/4/2017" -EndDate "9/5/2017" $Columbus = New-CsRgsHoliday -Name "Columbus Day 2017" -StartDate "10/9/2017" -EndDate "10/10/2017" $CA_Thanks = New-CsRgsHoliday -Name "CA Thanksgiving 2017" -StartDate "10/9/2017" -EndDate "10/10/2017" $Veterans = New-CsRgsHoliday -Name "Rememberance/Veterans Day 2017" -StartDate "11/11/2017" -EndDate "11/13/2017" $US_Thanks = New-CsRgsHoliday -Name "US Thanksgiving 2017" -StartDate "11/23/2017" -EndDate "11/24/2017" $Christmas = New-CsRgsHoliday -Name "Christmas 2017" -StartDate "12/25/2017" -EndDate "12/26/2017" $Boxing = New-CsRgsHoliday -Name "CA Boxing Day 2017" -StartDate "12/26/2017" -EndDate "12/27/2017"

Then run this Powershell command to create the holiday set. Replace YOURPOOLFQDNHERE with the actual name of the Standard or Enterprise Edition pool you want to create the holiday set. If your company has different holidays (ie Banks/government in Canada get Easter Monday off), add them to the holiday list (ie $EastMon)

For US
New-CsRgsHolidaySet -Parent "ApplicationServer:YOURPOOLFQDNHERE" -Name "2017 US Holidays" -HolidayList ($NewYear, $MLK, $Presidents, $GoodFri, $Memorial, $USDay, $Labour, $Columbus, $Veterans, $US_Thanks, $Christmas)

For Canada
New-CsRgsHolidaySet -Parent "ApplicationServer:YOURPOOLFQDNHERE" -Name "2017 CA Holidays" -HolidayList ($NewYear, $Fam, $GoodFri, $Victoria, $CADay, $Civic, $Labour, $CA_Thanks, $Christmas, $Boxing)

Enjoy!