Large Scale Extension Dialing in Lync

I was recently working a pretty large Enterprise Voice deployment that had more than a hundred sites located around the world. Every site used DIDs for their users phone numbers, but wanted to be able to reach every other site using a 3-digit site code, plus the last 4 digits of the user's phone number (total 7 digits). This would be pretty easy except for the following wrinkle: they wanted people within any one site to be able to dial just the last 4-digits of other people within that site, rather than the 7-digit "global" extension or full DID. To complicate matters, multiple sites had overlaps with the last 4 digits of their numbers.

Unfortunately, this meant that every single site would require their own dedicated Lync dial plan, with only one rule that is different from the other sites. Management of these sites can be a nightmare, especially when you consider what has to happen when a new site gets added. Not only do you have to add the other sites extension normalization rule to the new site, but every other site has to have their dial plans updated with the new site's extension normalization rule. With many sites, this can become difficult to manage.

Thankfully, Powershell can take a daunting task such as this and make it much easier. I've developed a process to manage large numbers of extension ranges that is scalable and easy to replicate at other sites. Of course, this being me, the core of it is based around Lync Optimizer generated rulesets, and the associated scripts assume you follow the same naming convention. So, without further ado....

For this particular company, I decided on a naming convention for 7-digit extension normalization rules that follow the format CountryID-StateProv-City-7Ext0x (eg. US-TX-Dallas-7Ext01, US-TX-Dallas-7Ext02 etc). 4-digit extension rules for specific sites use the format CountryID-StateProv-City-4Ext0x (eg. US-TX-Dallas-4Ext01).  Every site's dial plan would end up with a large number of 7Ext normalization rules, and a single 4Ext normalization rule specific to that site.

I kept a repository of 7-digit extension dialing rules for all sites, organized alphabetically in a manually created dialplan called ZZ-ExtensionList. This dialplan was only used for the scripts I used later to populate new site lists.

Each site used the Lync Dialing Rule Optimizer to generate rulesets for each site. I used the Extensions entry page to generate the local site's 7Ext0x normalization rule.  For this particular company, since we were using a 3-digit site code and the last 4-digits of the user's DID, the extension entry page looked something like this:

For the above example, the 3-digit site code is 350, and user's phone numbers are in the range +442055662000 to +442055662099.  The # of Ext Digits in DID field tells the Optimizer that only the last 4 digits of the 7-digit extension is actually part of the DID.

I ran the Optimizer generated script against the deployment as per usual, which generated the standard ruleset for the given site. Once complete, I opened the ZZ-ExtensionList dial plan and added the newly generated 7Ext0x rule(s) to the list, making sure to maintain alphabetical order.

I then ran the custom script AddExtensionsToDP.ps1 (see below) with the switch -DialPlan set to the name of the newly added dialplan (ie .\AddExtensionsToDP.ps1 -DialPlan UK-London) This script does two things. First, it adds all the extension dialing rules from ZZ-ExtensionList into the new dialplan. Secondly, it modifies the 7Ext0x rule(s) specific to the new site into a 4Ext0x rule(s). So, for the above example:

Original Pattern/Translation: ^350(20\d{2})$          -->    +44205566$1
New Pattern/Translation:       ^(?:350)?(20\d{2})$  -->    +44205566$1

The new pattern allows users within the site to either dial 20xx or 35020xx for other users within the site.

AddExtensionsToDP.ps1

# This script adds all the extension normalization rules from ZZ-ExtensionList to the selected dialplan # Assumes you've already generated the new dialplan via the Lync Optimizer (www.ucdialplans.com) # Then run UpdateNormRules.ps1 to add the new normalization rule to every other site [CmdletBinding(SupportsShouldProcess = $True)] param( [parameter(ValueFromPipeline = $false, ValueFromPipelineByPropertyName = $true, Mandatory = $true)] [string]$Dialplan ) $NormRuleList = Get-CSVoiceNormalizationRule | Where {$_.Identity -like 'Tag:ZZ-ExtensionList/*' -and $_.Identity -notlike "Tag:ZZ-ExtensionList/$DialPlan-7Ext*"} | Sort-Object Priority ForEach ($NormRule in $NormRuleList) { New-CSVoiceNormalizationRule -Parent $DialPlan -Name $NormRule.Name -Description $NormRule.Description -Pattern $NormRule.Pattern -Translation $NormRule.Translation -Priority $NormRule.Priority -IsInternalExtension:$TRUE } # Replace the 7Ext rule for the target site with its own custom Ext rule $7ExtRules = Get-CsVoiceNormalizationRule | Where {$_.Identity -like "Tag:$DialPlan/$DialPlan-7Ext*"} | Sort-Object Priority -Descending ForEach($7ExtRule in $7ExtRules) { $RuleName = $7ExtRule.Name $NewRuleName = $RuleName -replace "7Ext", "4Ext" $NormPattern = $7ExtRule.Pattern $NewNormPattern = $NormPattern -replace "\^(\d{3})", '^(?:$1)?' New-CSVoiceNormalizationRule -Parent $DialPlan -Name $NewRuleName -Description $7ExtRule.Description -Pattern $NewNormPattern -Translation $7ExtRule.Translation -Priority 0 -IsInternalExtension:$TRUE Remove-CSVoiceNormalizationRule $DialPlan/$RuleName }

Once that script was done, then I ran the UpdateNormRules.ps1 script (shown below) with the -NormRuleBase switch to specify the name of the dial plan created at the beginning. (ie. .\UpdateNormRules.ps1 -NormRuleBase UK-London). This script adds the normalization rules for the new site to all the other site-specific dialplans, in the proper alphabetical order.

UpdateNormRules.ps1

# This script is designed to be run after implementing a new dialplan for a site. # It will insert any extension normalization rule for that site into the dialplan for every other site in alphabetical order # Prior to running this script, insert the new normalization rule(s) in the ZZ-ExtensionList dialplan in the appropriate order. Make sure you name the rule(s) as per the following: # 2-Letter countrycode-State/Prov-City-7Ext0# (where # starts at 1), ie US-TX-Dallas-7Ext01 # # This script will copy the normalization rule to every other dialplan in the same order [CmdletBinding(SupportsShouldProcess = $True)] param( [parameter(ValueFromPipeline = $false, ValueFromPipelineByPropertyName = $true, Mandatory = $true)] [string]$NormRuleBase ) # Find the priority of the first norm rule we want to insert $NormRuleListRev = Get-CSVoiceNormalizationRule | Where {$_.Identity -like "Tag:ZZ-ExtensionList/$NormRuleBase*"} | Sort-Object Priority -Descending ForEach ($NormRulePriority in $NormRuleListRev) { $BasePriority = $NormRulePriority.Priority } $NormRulePrior = (Get-CSVoiceNormalizationRule | Where {$_.Identity -like "Tag:ZZ-ExtensionList/*" -and $_.Priority -eq $BasePriority-1}).Name $NormRulePriorPrefix = $NormRulePrior.substring(0,$NormRulePrior.LastIndexOfAny("-")) $NormRulePriorSuffix = $NormRulePrior.substring($NormRulePrior.Length-5,5) $NormRulePrior = $NormRulePriorPrefix + "*" + $NormRulePriorSuffix $DPList = Get-CsDialPlan | Where {$_.Identity -like '*-*' -and $_.Identity -ne 'Tag:ZZ-ExtensionList' -and $_.Identity -ne "Tag:$NormRuleBase" -and $_.Identity -notlike 'Service:*'} Foreach ($DP in $DPList) { $DPName = $DP.Identity $Priority = (Get-CSVoiceNormalizationRule | Where {$_.Identity -like "$DPName/$NormRulePrior"}).Priority + 1 Write-Host $DP.Identity $Priority If ($Priority -ne $NULL) { ForEach ($NormRule in $NormRuleListRev) { New-CsVoiceNormalizationRule -Name $NormRule.Name -Parent $DPName -Description $NormRule.Description -Pattern $NormRule.Pattern -Translation $NormRule.Translation -IsInternalExtension:$TRUE -Priority $Priority } } }

Once complete, the new site had all the existing site-level extension normalization rules for every other site, and all existing sites also had the new site's extension normalization rule inserted into their dial plans. This ensured that all sites could dial any other site using their site code and extension.

So, to summarize the workflow:

1. Manually create an empty dialplan called ZZ-ExtensionList
2. Generate a Lync Optimizer dialplan for your selected area, populating the Extensions using the appropriate format for your deployment. Make sure the Suffix is set to 7Ext01 (and 02 etc).
3. Run the Lync Optimizer generated ruleset against your deployment.
4. Copy the -7Ext0x rule(s) to the ZZ-ExtensionList dialplan ensuring proper alphabetical order.
5. Run the AddExtensionsToDP.ps1 script to add all the extension rules in ZZ-ExtensionList to the new dialplan.
6. Run the UpdateNormRules.ps1 to update all other dial plans with the newly created extension normalization rule.
7. Repeat steps 2-6 as necessary.

Rinse and repeat for each new dial plan you want to add to your environment. This process along with the attached scripts should make managing large dial plans much simpler. As always, be cautious when running these scripts, as I can't be responsible for any issues this causes.  Always make a backup of your existing Lync EV environment before running these or any scripts provided by strange people who pretend they look like David Hasselhoff.

Out of the Gutter: The Ken Lasko Story, Part 3, Part II

One day in the late 1990's, I got a call from an old co-worker from my Microsoft days asking me if I wanted to help out on a 3-month long consulting job for the provincial government managing their Microsoft Mail 3.5 system. I told him that I've never even HEARD of MS-Mail, let alone know anything about it. He assured me that I'd be able to figure it out and strongly suggested that I give it a try. Since the pay I would get in three months was going to be as much as I was making at my current job in a year, I jumped at it.

So began my consulting career.

Working with this was as dirty as this package implies.

I started work with a third guy we both knew from Microsoft support and got a crash course in MS-Mail. Since there wasn't
all that much to it, it didn't take long. MS-Mail was a collection of "post offices" that worked more or less completely independently of any other post office.  There was no central management console, so you'd have to connect to each post office individually to do any maintenance or troubleshooting. The provincial government had more than 220 post offices in their deployment, so management was a nightmare. Since there was no central management to speak of, there was no way we could tell there was a problem unless we went and signed into every single post office to check the status of mail delivery, GAL synchronization and that sort of thing. Since that wasn't feasible, we operated in reactive mode, where we would wait for someone to call in to report an issue. We would then log into the affected post office, fix the issue and continue on.  We got pretty good at it, so our contract kept getting extended more and more.

The job proved to be both time-consuming and monotonous. We decided to figure out a way to make our job easier so we could free up time for web-surfing and game playing. My counterpart worked on developing a Windows service that would collect all the pertinent information from each post office and put it into a central repository.  I worked on a web-based front-end that would show us near real-time information from each post office.  Problems would be highlighted in red, and we got it to the point that you could just click on the red counter, and it would initiate the typically required fix for that issue.

After many months of development, we were at the point where we would show up to work, bring up the webpage, and quickly deal with any issues by literally clicking on a red button to trigger the required fixes on any number of post offices. Call volumes dropped dramatically, and we both realized we were sitting on a goldmine. We could have become rich if it weren't for an annoying software development from Microsoft called Exchange Server.

The provincial government had decided to start moving to Exchange Server 5.5 in 1999.  While we weren't directly involved in the design of the environment, we had our hands deep in the support and migration away from MS Mail. By the time the 21st century had arrived (well, not technically since it was still 2000), we were both pretty adept at working with Exchange Server 5.5.  Eventually, support moved to a central call centre far north of where we lived and our services were no longer needed. So 2.5 years after I left my previous job for that short, high-paying, 3-month consulting gig, I was looking for another job.

The same person who got me on the MS-Mail gig introduced me to the right people at what was then Software Spectrum, and I started work as a consultant. Soon after, Software Spectrum sold their consulting business to Buchanan Associates (now Buchanan Technologies). I primarily consulted on Active Directory and Exchange projects, and had my hand in quite a few of them over the years. I got to work in some pretty fun places, especially Bermuda, where I was on a Citrix and Exchange gig with our IBM partner for several months.

In 2007, my boss at the time said that he wanted me to become the company expert in Office Communications Server (OCS).  The first thing I said was "OK. What's OCS?". The second thing I said after I found out what OCS did was "You want me to be the instant messaging expert???" At the time, Exchange had flirted with including some IM capabilities, but it was never used by many in the corporate world.  IM was seen as something used by kids.  I had images of "OMG Ponies!!!" and "LOL" and thought my boss was trying to make me quit my job.

When I dug in deeper into OCS, I saw there was some telephony integration capabilities and became intrigued, mostly because I had no idea how you could use your computer to make telephone calls. When Office Communications Server 2007 R2 came out, we jumped aboard in a big way and moved a chunk of our users over to it for all their telephony.  OCS, and then Lync became my sole focus, and I moved entirely away from Exchange and AD consulting.

My first go at the Optimizer was a VBScript HTA program.

Around 2010, I thought it might be a good idea to start blogging some of the things I couldn't find answers for about Lync. At the time, I thought I was late to the blogging party. My first post was in fact titled "Late to the Party".  I also began work on a locally run version of what would become the Lync Dialing Rule Optimizer to deal with the odd local vs. long distance conundrum that exists in North America.

Fast-forward five years, and my blog is quite heavily read, I've spoken at numerous events and the Lync Optimizer now supports 100 countries. I became the Lync Practice Manager for Buchanan Technologies and was overseeing how we deliver Lync to our customers. I always felt that Buchanan took care of me, and made sure I was happy in my career. Life was busy, but good.

But along came David Tucker from Event Zero, riding in on a white stallion with the promise of greater things. After much whining and dining, I finally decided to make the jump from Buchanan Technologies, a consulting company with 500 people worldwide, where I spent 15 years of my life to the Event Zero team.

If you don't know Event Zero and their phenomenal Dossier product line, you really should check it out. The best way I can describe it is "Lync Monitoring Reports on 'roids, but without the rage". It extends the not-so-real-time, slow to respond, frustrating, and hard to use reports that comes with Lync, into something that provides real-time, useful and easy-to-get-to reports on all aspects of Lync activity. There are also numerous other add-ons that can really make your Lync deployment work better for you.

I've been brought on to help drive Event Zero Dossier deployments, and ensure clients are getting the most out of their Lync deployments through effective reporting.

For me to leave my Buchanan Technologies "family" after 15 years, you know that I must have seen something special in Event Zero, and no, it wasn't the fact that Dave loves to cuddle on cold winter nights (which don't happen often in Australia).

My big career switch made me somewhat nostalgic, which led me to doing this series. There weren't nearly as many explosions or top-secret espionage capers as I would have hoped to have achieved at this point in my life, but there is still time.  Maybe the next chapter in this series will deliver on that....

Until then......adios!

Out of the Gutter: The Ken Lasko Story, Part 3, Part I

Part 3, Part I - Tech Support Hijinks

In the spring of '94, I went to a local job fair to look for a summer job that was different than working at the 1 hour photo lab as I had done previous summers. After browsing a while, and leaving my resume at a few places, I came across the Microsoft booth. They were looking for technical support people for their Canadian office. I felt this was the perfect opportunity for me. I figured with my TA experience, I would be a shoe-in for the job. I excitedly explained all this to the people manning the booth, and I must have made a good enough impression, because in April of 1994, I got hired to work at Microsoft as a technical support engineer.

I was thrilled to get the opportunity to work for such a big company. When I got the job, I was told that I would be supporting MS Word 6.0. Having never used Word 6.0 before (I had always used WordPerfect), I was concerned. So, I did what any self-respecting computer guy in the 90's did, I found a copy of Windows and Word 6.0 on the still young Internet, installed these not-so-legal copies on my computer and gave myself a crash course in Word 6.0.

I saw variations of this pose from my managers all too often.

I didn't think I was ready by the time I started my first day at MS. Thankfully, instead of supporting Word, I was assigned to support MS-DOS 6.2. Having lots of experience with MS-DOS, I was relieved. For the next while, I supported MS-DOS 6.2, which consisted mostly of editing people's CONFIG.SYS and AUTOEXEC.BAT files so they could free up enough memory to run whatever program they needed. Keep in mind, there was no such thing as remote desktop back then. All this was done by coaching the user over the phone. Slow and time-consuming work to be sure, but I enjoyed the atmosphere. I had some great bosses and co-workers at the time, and the workplace was fun and lighthearted. You could often see other guys on calls popping up over their cubicle walls waving at one another. I moved around a lot, even while tethered to a desktop PC with an audio headset.  I would stand on my desk, lie on the floor, or wander as far from my cubicle as my headset cable (or was it a leash?) would allow.

As with most tech support jobs, it involved a lot of sitting.  At lunch, you'd go down to the cafeteria, eat and sit some more, then go back and sit at a desk again.  To keep fit during the summer, I decided to try rollerblading. Having never rollerbladed before, I strapped them on in the office and rolled around the cubicle farms to learn the basics. Soon afterwards, there was a "No Rollerblading" policy instituted, which may be my only legacy from those days.  Rather than spend my lunch hour sitting in the cafeteria, I would go out and rollerblade as far away as I could go in 30 minutes, turn around and head back. I'd grab a shower, which sometimes wouldn't "take" on some of those hot days, and I'd sweat my way through the next few calls.

I had so many CD-ROMs that I used a bunch of old ones as a Halloween
costume.  Meet CD-MAN!!!

I made sure I took full advantage of the employee purchase program, which allowed you to buy pretty much anything from Microsoft's catalog at greatly reduced prices. I ordered copies of just about every CD-ROM based product MS had at the time, including things like Encarta, Cinemania, World of Flight, even Julia Child's cooking guide at 1/10th the cost of retail. I recall an offer where you could buy Visual C++ for $50, and it would come with a SCSI CD-ROM drive, complete with SCSI interface card. I used the CD-ROM drive and SCSI card, but tossed the rest.


When fall of 1994 came around, my contract was extended. I decided to delay my final university year to continue working at Microsoft, since it was too good an opportunity to pass up. Over time, I got assigned to the Windows 3.1 queue, then the Windows for Workgroups 3.11 queue, where I got my first taste of working with TCP/IP (a nightmare at the time). We got introduced to early builds of "Chicago", which would become Windows 95, the biggest consumer OS play Microsoft had done up until then. I remember copying weekly builds onto 15 or more 1.44 MB floppy disks to install on my computer at home. It was pretty neat to see the progression of features and stability as time moved on.

All the OS support guys underwent extensive training on Windows 95 in preparation for what we
thought was going to be a very busy time when it was first released to the public. I can remember the excitement building as the release date inched closer. We once got involved in the media blitz by going to a local computer tradeshow where we offered to install betas of Windows 95 on any customer-facing PC that was available in a vendor's booth. At the time, IBM was pushing OS/2 Warp as an alternative to Windows 95, and IBM people were walking around doing the same thing. I remember installing Windows 95 on one PC at a vendor booth, while an IBM guy installed Warp on a PC beside it in a sort of geeky showdown. A small crowd gathered to watch as Windows 95 smoothly installed and worked flawlessly, while the poor IBM guy was sweating through issue after issue. I don't know if he ever got it going.

On the day Windows 95 finally released, I was sitting in my cubicle waiting for the onslaught of

Even the Hoff loved Windows 95

calls. We heard about the lines at stores snaking out the doors. At lunch we went out and marvelled at the sight of so many people buying Windows 95. I've never seen it before or since. Back at work, we twiddled our thumbs. The calls were trickling in at a slow rate, but most of us sat idle. We were all wondering if Windows 95 was so stable and easy to use, that nobody was having issues. At around 5pm, as people got home and presumably started installing Windows 95 in excitement, the call volume went up dramatically. Within 30 minutes, we went from idle to full tilt with long wait times for the large number of users waiting in the queues. We churned through the issues day after day, but it wasn't too long before call counts settled into a new level of "normal call volumes".

With fall of 1995 approaching, I debated whether to stay at Microsoft of return to university to finish my final semester. I didn't see the point since I felt that I had started a good career at Microsoft, and all I would get is a piece of paper. I confided to my boss, who had the absolute best advice ever: "What's 4 months out of the rest of your life?"  So, with that, I went back to university and got my bachelors degree. While I was at school, my MS boss was wonderful in that he let me work the queues the odd day or weekend, even though I was sure they didn't really need me.

When I finally finished university, I returned full-time to Microsoft, but I felt that something was different. I had my university degree, but here I was still doing the same technical support I was doing before. I needed a change, plus the commute was starting to wear on me.

In the spring of 1996, I decided to take a job as a "sales engineer" for a PC card company based out

of the my home city. If you were around laptops back then, things like built-in modems and network cards just weren't an option. You had to use credit card sized packages called PCMCIA cards (or simply 'PC Cards') to get these functions. Laptops of the era usually had 2 or more of these slots. Need a modem? Go buy a PCMCIA modem card. Need a network card? Buy a PCMCIA network card. Our company had an edge in that we had the world's first combination network/modem card. These playing-card sized devices had an interesting playing card-based motif that definitely caught people's attention.

My job was to travel the US and Canada helping the salespeople with the technical aspects of their PCMCIA cards. For a 20-something guy, this was a sweet gig. I got to go to some pretty cool places across the continent with some fun people. This company also had a 3-port networking hub dongle that you could use to create a simple ad-hoc network with other laptops. You could daisy-chain these things together to add more laptops to your network. Our favourite thing to do was to throw network cables between the seats on an airplane so we could play multiplayer Quake during cross-country trips.

I was at this particular job for a few years, when a chance call from an old colleague from my Microsoft days turned my career into another direction that led directly to where I am today.

Continue reading the dramatic conclusion - "You want me to be the expert on WHAT????"