Showing posts with label Powershell. Show all posts
Showing posts with label Powershell. Show all posts

Monday, March 9, 2020

"Have you tried turning it off and back on again?" for MS Teams

One of the most powerful tools in a support professional's arsenal is the tried-tested-and-true method of restarting a computer to resolve strange issues. I can't tell you how many times this fixed the oddest issues over the years. Why does it work? You might as well ask where socks go once placed in the clothes dryer.

I'm excited/sad to report that the same method works in Microsoft Teams to resolve strange issues that defy explanation. I'm not talking about client-side issues. I'm talking about issues at the Office 365 end of things. How does that work when there are no administrator-accessible servers to restart? You simply toggle the relevant setting off and back on again.

We use Direct Routing for our PSTN services, and for the most part it works great. In the past few weeks, I've had some of our users experience strange issues with telephony in Teams.
  1. A few users were unable to receive any PSTN calls. Troubleshooting at the SBC would show 487 Request Terminated - Phone number not found.
  2. Another user's outbound PSTN calls were showing as Anonymous/Private. There weren't any caller ID policies being applied that would account for the behaviour.
For each of those issues, I verified that things were indeed setup properly in Teams via PowerShell. Get-CsOnlineUser showed that their LineURI and OnpremLineURI settings were correct, and Enterprise Voice was enabled. Get-CsOnlineVoiceUser showed they were all licensed, PSTNConnectivity was OnPremises and their Number was correct.

In short, there was nothing on the Teams side of things that indicated an issue. I decided to try the "Have you turned it off and back on again?" trick, which consisted of:
Set-CsUser -Identity UserID@contoso.com -EnterpriseVoiceEnabled:$FALSE
Set-CsUser -Identity UserID@contoso.com -EnterpriseVoiceEnabled:$TRUE

I waited patiently all of 10 seconds between commands. I then instructed the users to log off and back onto Teams. Lo and behold, in each case, the problem went away.

Yeah, I know. I don't get it either, but whatever...it works.

Sunday, February 9, 2020

Migrating SfB Enterprise Voice Configs to MS Teams

I'm flyyyyyyiiiing through the cloud.....get it? Cloud? Teams is in the cloud. Got it? Good.

The UCDialplans.com Winter of Code continues at a torrid pace!

Hot on the heels of the MS Teams EV Backup/Restore scripts is another script that I can't believe someone hasn't already cooked up.

Say that you have a well-oiled Skype for Business Enterprise Voice deployment that you carefully cultivated over the years into a perfectly tuned beast. You're considering migrating to Teams, but aren't terribly enthusiastic about having to recreate all that magic in Teams.

Well, worry no more! I've created a script that will copy all of your Skype for Business Enterprise Voice settings into MS Teams. It will handle the following:
  • SfB dialplans into Teams dialplans (along with all normalization rules, of course)
  • SfB PSTN usages into Teams PSTN usages
  • SfB voice routes into Teams voice routes
  • SfB voice policies into Teams voice routing policies
  • SfB trunk translation rules into Teams translation rules
  • SfB PSTN gateways into Teams PSTN gateways
Most of this is completely automatic, except for the PSTN gateway part. Teams PSTN gateways have to be publicly accessible via FQDN, and that FQDN's domain name has to be registered in the O365 tenant. Chances are pretty good that the SfB PSTN gateways won't conform to those requirements. The script will first look for an existing Teams gateway that matches each SfB gateway. If one isn't found, the user will be prompted to do one of the following:
  • match the SfB gateway to an existing Teams gateway with a different FQDN
  • create a new Teams gateway with the same FQDN as the SfB gateway (only works if the SfB gateway already meets the Teams FQDN requirements)
  • create an entirely new Teams gateway
  • don't match the SfB gateway
All this is presented to the user in a straightforward menu. Once all the selections are complete, the selected matches are shown before erasing any existing Teams EV configs and migrating the SfB EV configuration:

The usual trained monkeys will then migrate all the SfB EV settings to Teams, with a few caveats:
  • Since Teams doesn't have "sites", site-level SfB dialplans will be converted to user-level dialplans
  • Same deal with site-level voice policies
  • If there are duplicate translation rules, they will be merged into one, but translation rules with the same name, but different patterns/translations will be changed to include the PSTN gateway name to avoid conflicts.
If all goes well, the script should progress like this:

If you want to see more details around how the secret sauce is made, run the script with the -Verbose switch:


Once complete, your SfB Enterprise Voice config should be completely migrated to Teams. Check things over to be sure. If you elected to create Teams PSTN gateways, you will have to revisit them using Set-CsOnlinePSTNGateway to make sure they're configured correctly. 

Hopefully, this script will help make your transition to Teams that much simpler!

To get the script, go on over to my Github page to get the latest version. If you experience any issues, you can create an bug report through there.

https://github.com/kenlasko/SfBEV2TeamsEV


Tuesday, February 4, 2020

Backing up and restoring Teams Enterprise Voice configs

In the cloud....get it?

Whenever I made changes to a Skype for Business Enterprise Voice configuration, either via a UCDialplans.com script or manually, I got into the habit of making a backup of the Enterprise Voice configuration. Skype for Business made this easy with an option directly in the UI that allowed you to backup and, more importantly, restore. I've made use of both options on more occasions than I can think of.

In the MS Teams world, there are a few scripts out there that help you backup your Teams Enterprise Voice configuration as part of a larger backup of the entire environment. However, I haven't found one that will let you restore that backup. Now there is!

I've published two PowerShell scripts that allow you to backup and then restore an MS Teams Enterprise Voice configuration in a few minutes. Slide on over to my Github page for the latest version.

https://github.com/kenlasko/BackupRestoreTeamsEV



BackupRestoreTeamsEV

PowerShell scripts that allow you to easily backup and restore your Microsoft Teams Enterprise Voice configuration

Getting Started

Download the scripts onto your local Windows machine where you normally connect to your MS Teams tenant.

Prerequisites

Requires that you have the Office 365 PowerShell module installed, and that you have a Microsoft Teams Enterprise Voice configuration that you are interested in backing up/restoring. You may have to set your execution policy to unrestricted to run this script:
Set-ExecutionPolicy Unrestricted

Running a backup

Simply run .\Backup-TeamsEV.ps1 from a PowerShell prompt. If you are not already connected to your Teams tenant, the script will prompt for authentication. If your admin account is not a @tenantname.onmicrosoft.com account, then you should use the -OverrideAdminDomain switch.

Restoring a backup

Run .\Restore-TeamsEV.ps1 with the path to the backup file to restore. If you are not already connected to your Teams tenant, the script will prompt for authentication. If your admin account is not a @tenantname.onmicrosoft.com account, then you should use the -OverrideAdminDomain switch.
By default, the script will clean out any existing config, including dialplans, voice routes, voice routing policies, PSTN usages and translation rules. You can override this behaviour by using the -KeepExisting switch.

Wednesday, May 22, 2019

Useful Teams PowerShell Commands

Back in the day, I compiled a shortish list of Lync/Skype for Business PowerShell commands that did some reasonably useful stuff. With my shift to Teams, I figure now is a good time to start compiling a list of semi-useful PowerShell scripts for Teams. I will add to this list as I think of them.

Getting Started

For now, there are TWO PowerShell modules for Teams-related tasks. Both require at least PowerShell version 5.x (run $PSVersionTable.PSVersion to check):

Skype for Business Online PS Module

The OG. You install it via https://www.microsoft.com/en-us/download/details.aspx?id=39366. You typically connect to your tenant via some variation of the below:
$s = New-CsOnlineSession -Credential (Get-Credential)
Import-PSSession $s -AllowClobber

Teams PowerShell module

To install, simply run the following in an elevated PowerShell prompt:
Install-Module -Name MicrosoftTeams -Repository PSGallery      

You then connect to your Teams tenant by running:
Connect-MicrosoftTeams

You will be prompted for admin credentials. Enter those, and you'll be all set!

Count All Teams Users in your Tenant (Teams PS)

There isn't a direct way to count every Teams user across your tenant. However, you can get a list of users in a specific team. Thanks to PowerShell pipelining, you can string multiple commands together to get the desired result.
(Get-Team | Get-TeamUser | Sort-Object User -Unique).Count
If you want to exclude external accounts who you've granted guest access to Teams, modify the command accordingly:
(Get-Team | Get-TeamUser | Where {$_.User -notlike "*#EXT#*"} | Sort-Object User -Unique).Count
You can get a count of all Skype for Business (on-prem) and Teams users, excluding duplicates by running this from a Skype for Business PS prompt:

$SfBUsers = (Get-CsUser).SipAddress -Replace "sip:", "" 
Connect-MicrosoftTeams 
$TeamsUsers = (Get-Team | Get-TeamUser | Where {$_.User -notlike "*#EXT#*"} | Sort-Object User -Unique).User 
$CombinedUsers = $SfBUsers + $TeamsUsers | Sort-Object -Unique
$CombinedUsers.Count

List All Cloud Auto-Attendants and Associated Numbers (Skype PS)

Can't get a list of just the AA phone number from Get-CsAutoAttendant. You have to parse the resource account list for this.
$AAList = Get-CsAutoAttendant
New-Item -Path AAPhoneNum.csv -Value "Name,PhoneNumber`r`n" -Force | Out-Null
ForEach ($AA in $AAList) {
ForEach ($AppInstance in $AA.ApplicationInstances) {
$AAName = $AA.Name
$AppPhoneNum = (Get-CsOnlineApplicationInstance -Identity $AppInstance).PhoneNumber
Write-Host "$AAName  $AppPhoneNum"
Add-Content -Path AAPhoneNum.csv -Value "$AAName,$AppPhoneNum"
}
}

Thursday, February 21, 2019

Can You Install an SDN Listener in a SfB CCE Environment?

As part of my job at Nectar Corp, I'm always looking at ways to get call detail information from various Microsoft-based UC telephony components. It's easy to get a wealth of detail from an on-prem deployment of Skype for Business, using either direct access to the SfB monitoring databases (for historical info) or via the Skype for Business SDN dialog listeners (for realtime call data).  As mentioned in my recent blog post, the same cannot be said for Office 365 UC workloads such as SfB Online and Teams.

Nectar has a tool that relies on knowing when a call starts and stops in realtime so we can gather information from various network components as the call is happening. Nectar uses the SfB SDN interface for this realtime info. Since both SfBO and Teams lack ANY sort of call data API, we have to resort to other methods to learn about realtime calls.

A Nectar customer has deployed several Skype for Business Cloud Connector Edition (CCE) instances to provide on-prem PSTN call routing for SfB Online users. CCE is the precursor of Teams Direct Routing, and it does essentially the same thing but in a WAAAAAAY more complex manner. It consists of several pre-packaged VMs running a vastly slimmed down Skype for Business environment.

We were in discussions with the customer to see if there was any way we could get realtime call info from the CCE instances, by installing the Microsoft SDN Dialog Listener on any of the CCE VMs. Nobody seemed to know for certain, so I elected to setup a CCE instance of my own to run some tests. The question I was trying to answer was:

Can you get call data out of a CCE instance using the MS SDN Listener service??? 

TL;DR:  No.

I had built myself a fancy new work PC at home that I figured would be ideal for this test. I put in 32GB of RAM so I could spin up VMs as needed for my tests, and this would be an excellent test OR SO I THOUGHT!

My first hurdle was that I needed a virtual machine host that would host the VMs required for CCE. In other words, I needed to run VMs from within a VM.
Just like the movie, except much more boring.
CCE only supports Windows 2012 R2 as the VM host OS, so I started with that as my VM host for my VMs, but it blocked me from installing the Hyper-V components, since it was already a VM. A bit of research showed that I could use Windows Server 2019, which had no such limitation. I spun up my Hyper-V host VM, gave it 24 GB of RAM, all the processor cores I had, and off I went.

...OR SO I THOUGHT (AGAIN). I ran into issues right off the bat when installing the CCE components, where most of the CCE PowerShell commands were available. Thanks to a workaround from Shawn Harry, I was soon off to the races and installing CCE.

...BUT NO! FOILED AGAIN!!! There are a number of steps to deploy a CCE instance, most of which require running various CCE PowerShell commands. One of these commands performed a hardware check to make sure the Hyper-V host had enough resources to run the required VMs. I was rudely informed that my super-awesome, brand-new workstation PC did not have enough memory, processor cores or disk space to run CCE.

Keanu is sad, and so am I
Time to implement my hacker skilz.

The big red, failure message that PowerShell spit out at me helpfully included the path to the script that did the hardware check:

C:\Program Files\WindowsPowerShell\Modules\CloudConnector\Internal\MtCommon.ps1

A quick review of that script, and a few edits to the $logicalProcessorsCount, TotalPhysicalMemory, FreePhysicalMemory, and FreeDiskSize variables and the script was convinced that I had a super-server with 999999999999 MB of memory, diskspace and processor cores.

With a few more tweaks here and there, I was finally able to get a full Skype for Business Cloud Connector Edition instance running in my modest home lab. Since the CCE environment consists of several standard Windows VMs, I was able to login to them and attempt to install the SDN Listener on what I hoped would be possible candidates: the CMS or the Mediation VM.

Neither of those were running as a full front-end server, but I still held out hope. The CMS VM was running the Centralized Logging Service Agent, File Transfer Agent and Master/Replica Replicator Agents. The Mediation VM was running the Centralized Logging Service Agent, Mediation service and Replica Replicator Agents.

I attempted to install the SDN Listener on both those VMs and got the following message:

And there you go. The answer to a question that nobody else was looking for. No, you can't run SDN on any CCE VM role.

Hope you're happy @ucomsgeek.

Monday, October 1, 2018

Run PowerShell Core in Docker on Raspberry Pi

I've recently started playing around with the latest Raspberry Pi 3 B+ along with a PoE HAT, which is an amazing little piece of kit. I've been trying to offload a bunch of workloads that are currently being served by an aging Windows 10 PC whose primary role is a media PC. This very same PC used to run Windows Media Center on Windows XP, before I turned to XBMC/Kodi and then Plex. It's well over a decade old, but still going strong. Although, now that I think of it, the only thing that's probably still original is the case, since I've replaced the motherboard, videocard, disk drives, and power supply over the years.

Since I've worked with Docker in the past (most recently with a failed attempt to move the Skype Optimizer to a Docker container), I thought I'd try running Docker on the Raspberry Pi.

My home networking setup in the basement furnace room. My Raspberry Pi is circled in red.
I've been pretty successful in getting things working efficiently on Docker.  At the time of writing this post, I've got the following Docker containers running on my little Pi:
  • Traefik - an easy-to-use reverse proxy solution so that I can access the different container UIs by using https://containername.ucdialplans.com, instead of http://192.168.1.x:somerandomport. It also simplifies certificate management, since I only have to do it once in Traefik with a wildcard cert, rather than on every container.
  • Portainer - a GUI for container management, so I don't have to remember specific commands
  • Pihole - a DNS blackhole for ads. Blocks ads for all devices on my internal network. Tidbit: its currently blocking almost 50% of my total DNS queries!
  • Radarr/Sonarr/Jackett - *cough cough* media management
  • Unifi Controller - manages my amazing-how-did-I-live-before-this wifi infrastructure
  • NOIP - publishes my ever-changing public IP address to Noip.com.
  • PowerShellPi - Runs PowerShell scripts
It was the last one that took me the most work to get going. While there are several published PowerShell Docker containers for Linux, there didn't seem to be any that would work with the ARM processors inside the Raspberry Pi. 

After much trial-and-error (story of my life), I finally managed to build a working Docker image that works with the Raspberry Pi. I used some of the bits from this TechNet blog to get the right commands, but had to make some modifications for it to work on the latest Raspberry Pi version. 

I'm using this base image to build other images that run simple scripts on a schedule. For example, I've got one that checks my public IP, and updates an Azure DNS record when it changes. It does the same thing as the NOIP one, but its something that's fully under my control.

For those who are interested, the base image is available on https://hub.docker.com under kenlasko/powershellpi. The DockerFile used to build this image is shown below (since I haven't figured out how to display it on Docker Hub yet).

# PowerShell on Raspberry Pi
#
# Version 1.0

FROM raspbian/stretch

LABEL maintainer="Ken.Lasko@gmail.com"

RUN sudo apt-get update
# Install libraries necessary for PowerShell
RUN sudo apt-get install --no-install-recommends -y libunwind8 libicu57 libcurl4-openssl-dev cron
# Get the latest released PS module
RUN wget https://github.com/PowerShell/PowerShell/releases/download/v6.0.4/powershell-6.0.4-linux-arm32.tar.gz
# Make PowerShell directory and install PS module
RUN mkdir ~/powershell && tar -xvf ./powershell-6.0.4-linux-arm32.tar.gz -C ~/powershell && sudo ln -s ~/powershell/pwsh /usr/bin/pwsh && sudo ln -s ~/powershell/pwsh /usr/local/bin/powershell
# Remove install files after completion
RUN sudo rm -rf /var/lib/apt/lists && rm powershell-6.0.4-linux-arm32.tar.gz
# Install PS modules (Azure auth and DNS modules shown as examples)
#RUN ~/powershell/pwsh -Command Install-Module -Name AzureRM.Profile.Netcore -Force && ~/powershell/pwsh -Command Install-Module -Name AzureRM.Dns.Netcore -Force


My next move is to get a few more Raspberry Pis to create a Docker Swarm to automatically load-balance my containers, just like a wee little datacenter!

This is for you, Pat!

Tuesday, September 18, 2018

Skype Optimizer JSON Interface Now Available

For people who like to have more control over how dial rules are implemented but want to leverage my vast database of worldwide dial rules, I have implemented a JSON interface for the Skype Optimizer.

The interface will return all the dial rules for a given country in JSON format, which can then be used in your own scripts or application. 

To access the API, you simply construct the URL to correspond to the correct representation for the desired country. The base URL for the JSON interface starts with:

https://www.ucdialplans.com/queryapi/

You then add specific options as query strings. For NANPA countries like US, Canada and many Caribbean countries, use the following:
Query String
Data Value
Required?
countrycode
1
Yes
npa
3-digit integer
Yes
nxx
3-digit integer
Yes
natscope
national/uscan/all
No (defaults to national)
sevendigit
yes/no;1/0;true/false
No (defaults to no)
apikey
16-character alphanumeric
Yes

For an example location in Chicago, where we want to treat both US and Canada numbers as national numbers, use the following:
https://www.ucdialplans.com/queryapi/?countrycode=1&npa=312&nxx=226&natscope=uscan&apikey=yourapikeyhere

For any other country, the available query strings are as follows:
Query String
Data Value
Required?
countrycode
1-3 digit integer value
Yes
areacode
1-6 digit integer value
Most countries
carriercode
1-3 digit integer valueSome countries
apikey
16-character alphanumeric
Yes

For example, to return the dial rules for London, UK use the following URL:
https://www.ucdialplans.com/queryapi/?countrycode=44&areacode=20&apikey=yourapikeyhere
The results will look something like this, when you parse it through a JSON formatter:

One way to use this data is in your own personal PowerShell script. Below is an example that will pull down the dial rules for 312-226 in Chicago:
$DialPlan = "https://www.ucdialplans.com/queryapi/?countrycode=1&npa=312&nxx=226&apikey=abc1234567890xyz"
$JSON = Invoke-RestMethod -Method Get -Uri $DialPlan
Once you've got the JSON data, you can return specific elements simply by "following the path", as it were:
PS C:\> $JSON.data.routes

local         : {@{pattern=^\+1((872([^01]\d\d))|(847([^01]\d\d))...
tollfree      : @{pattern=^\+18(00|8\d|77|66|55|44|33|22)\d{7}$}premium       : @{pattern=^\+1(900|976)[2-9]\d{6}$}national      : @{pattern=^\+1(?!(24[26]|26[48]|284|345|441|473|649|664|721|[67]58|767|784|8[024]9|86[89]|876|900|976))                [2-9]\d\d[2-9]\d{6}$}international : @{pattern=^\+((1(?!(900|976))[2-9]\d\d[2-9]\d{6})|([2-9]\d{6,14}))}service       : @{pattern=^\+?([2-9]11)$}

You can get as specific as you want:
PS C:\> $JSON.data.normrules.national.pattern^1?([2-9]\d\d[2-9]\d{6})\d*(\D+\d+)?$PS C:\> $JSON.data.routes.international.pattern^\+((1(?!(900|976))[2-9]\d\d[2-9]\d{6})|([2-9]\d{6,14}))
For elements that could have multiple values, such as local routes, you have to write it a little bit differently (note the square brackets):
PS C:\> $JSON.data.routes.local[0].pattern^\+1((872([^01]\d\d))|(847([^01]\d\d))|(815(20[^189]|21[^1378]|22[01348]|23[067]|24[125]|25[02458]|26[^2469]|27[^035]|28[07]|29[0345]|30[^39]|31[03478]|32[^39]|33[^2569]|34[^0]|35[^089]|36[1346]|37[^5689]|38[23568]|40[^026]|41[^149]|42[^089....
You must also include a valid API key. For testing purposes, I've created a demo API key that anybody can use.
abc1234567890xyz
The output will be obfuscated to deter abuse, but is otherwise valid JSON.  Please give it a try, and if you feel there is a place for this in your company or application, please contact me through the usual channels.

The APIs have been documented on SwaggerHub, where you can check them out and even run tests to see what the output looks like.

I have to give thanks to longtime SfB/Teams MVP Jonathan McKinney for pushing me to do this, and to help test it along the way. Beers are inbound!

Thursday, February 12, 2015

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



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



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.

Monday, April 1, 2013

Automatically Creating Lync Sites and Subnets using AD Sites

To use call admission control or location-based routing in Lync, one of the first steps is to define all the sites and subnets used in the company and to assign the sites to network regions.  In larger companies, this can be a tedious process if this information is not stored in a central, easily accessible location.

One place where network site/subnet information can sometimes be centrally found is within Active Directory itself.  Active Directory and other applications such as Exchange uses site/subnet information to determine where to direct clients for authentication services (among other things).  Ideally, every site and subnet should be defined using the Active Directory Sites and Services snap-in.  If the Active Directory administrator has diligently defined all the sites/subnets, this information can be easily parsed and used in Lync.

I've created a short script that will automate the creation of network sites and subnets using the information stored in AD Sites and Services.  Again, this script is only useful if all the sites/subnets have been defined in AD.  Thanks to Greig Sheridan who fixed the script to deal with AD site names that have characters that are invalid for Lync site names (such as underscore).

Copy the below script into a .PS1 file on a Lync server and run it.  As always, be careful and test this in a lab first.  I can't be responsible for any damage this script will cause.


The script will first check to see if a Lync network region already exists. If so, it will select the first one it sees as the base for all the subnets.  If one doesn't exist, it will create one using the first Lync site as the base. If need be, you can define additional network sites later.

The script will then create all the sites/subnets based on information from AD. All the sites will be assigned to the one network region selected according to the rules in the previous paragraph. Since there is no way for the script to know which site belongs to which region, this will have to be done manually if multiple Lync network regions exist.

IMPORTANT: The script will also create the required subnets for all the Lync edge A/V public IP addresses with a 32-bit subnet mask as per the requirements for call admission control.  You will have to manually assign these subnets to the sites where you deployed the edge servers.

While this script doesn't try to do everything associated with setting up call admission control, it does go a long way towards automating a good chunk of the process. A future revision of the Lync Optimizer will hopefully close the loop and help completely automate the work required to setup location-based routing.

As a final side note, one thing I don't understand is why Lync can't leverage AD Sites & Services for this information directly.  Exchange versions since 2007 have used AD Sites & Services for mail routing, so its not like it hasn't been done before.  Maybe a future version of Lync will add this functionality.  Until then, this script should help those who have well-defined site/subnet information in Active Directory.

Wednesday, July 11, 2012

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


Thursday, May 3, 2012

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



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



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!


Tuesday, September 14, 2010

Configuring Location Services in Lync Server 2010 - Part 2

In my last post, I talked about how to configure Lync Server 2010 to allow users to enter their detailed location in Lync 2010 for use during a call to E.911 emergency services.  Today, I will talk about how to create and manage a central location database, and how to link the location information with your users.

Giving users the ability to manually input their location is important, especially when they are outside the office. However, when inside your corporate network, requiring all your users to input their specific location is an unnecessary burden, not to mention the inevitable errors that can delay emergency services.  Lync Server 2010 allows administrators to create a database of locations that map to your internal network topology. 

Location information can be set as high level as an entire internal network subnet, or can be as granular as individual switch ports.  Lync Server 2010 allows you to link locations to the following:
  • IP subnet via Set-CSLISSubnet
  • Wireless access point (basic service set identifier (BSSID)) via Set-CSLISWirelessAccessPoint
  • Switch (either MAC or IP address) via Set-CSLISSwitch
  • Switch port (switch MAC or IP address and port ID) via Set-CSLISPort
When you create a location database entry using the above Powershell commands, you can also enter all the location-specific information you have available. Hopefully, you have all the information you need in a CSV file that you can manipulate and import, saving you the tedium of manual entry. One thing to note is to make sure you DON'T publish any VPN subnets in your database. Since users who VPN in could be physically anywhere, you don't want to have their location be set to the office when they're really at home.  When a user is at home, they will have to enter their location information manually, as described in yesterday's post.

Once you've populated the location information database, you should validate it against the Master Street Address Guide (MSAG) maintained by your E911 call routing provider.  Microsoft has partnered with a few E911 routing providers in the US: 911 Enable and Intrado, with more to follow.  I understand that there will also be some E911 routing providers in Canada at some point as well.  If you don't have a E911 provider, you can skip these steps and continue on to publishing.

You setup your connection to your E911 provider using the following command:
$pwd = Read-Host –AsSecureString <password>
Set-CsLisServiceProvider -ServiceProviderName <Name> -ValidationServiceUrl <ProviderURL> -CertFileName <ProviderCert> -Password $pwd
Once setup, you can validate your addresses via the following command:
Get-CsLisCivicAddress | Test-CsLisCivicAddress –UpdateValidationStatus
You can also test addresses individually using Test-CSLisCivicAddress by itself.

Once you've validated your addresses (assuming you have a E911 provider), you have to publish the database:
Publish-CSLisConfiguration
If you successfully validated your addresses, your users' location will be automatically set when they are in a supported location (and can't be changed). 

If you are outside the US and can't validate your addresses against a MSAG provider, your users will see the following when they click on Set your Location:

The Suggested Location is populated from the Location Database information.  When a user selects the Suggested Location, they are brought to the same location information entry screen as when the user is outside a corporate network, except the address information is already populated. 
 
The user just has to type in a Location Name that is shown to other users.  The next time the user is at this location, the location will be automatically set.

For the location to be auto-populated, the civic addresses entered have to be validated against a MSAG.  If you're outside the USA, you won't be able to do this. 

An UNSUPPORTED way to gain the same auto-location setting capabilities for non-US installations is to directly edit the dbo.CivicAddresses table in your LIS database using SQL Management Tools and change the MSAGValid field from False to True on all your civic addresses.  If you're running Lync Standard Edition, install the SQL Server 2008 R2 Express Management Tools, or use SQL Management Tools from another SQL server. Keep in mind that this is UNSUPPORTED, and I can't be liable for any issues that arise. If you're unfamiliar with SQL, its best to leave things alone.

UPDATE:  The January 2011 Rollup 1 for Lync 2010 includes an update that removes the requirement for addresses to be validated against a MSAG. 

This post is meant as a basic overview of how to enable location services in Lync Server 2010.  If you want more detailed information on specific aspects of how to perform location or E911 tasks, please refer to the help documents contained with the Lync Server 2010 RC eval.

Monday, September 13, 2010

Configuring Location Services in Lync Server 2010 - Part 1

What is Lync Server 2010, you may ask?  If you haven't seen it mentioned anywhere else yet, then I guess I'm the first to let you know that CS "14" is now officially known as Microsoft Lync Server 2010.  The client is simply known as Lync 2010.  I'm not all that crazy about the name yet, but hopefully it will grow on me. If you want to try it out, the release candidate is now publically available from here.  You really should put it in a lab, but I've been running it in a limited production environment for several months now with very few issues. Its a very solid product. Now on to our regularly scheduled posting....

One important feature added to Lync Server 2010 is support for E.911.  E.911 (or Enhanced 911) is the next-generation of 911 emergency services in North America.  It provides location information for non-landline-based telephone numbers, like mobile phones and IP phones. 

The three most important things to note about E.911 is the same three things you need to worry about with real estate:  location, location, location.  Due to the inherent mobility of Lync users, it is critical that the telephony solution provide some manner of ensuring users can be automatically located in the event of a 911 emergency call. 

Lync Server 2010 provides several ways to ensure locatability (is that a word?).  The simplest method is to allow or force users to enter their location information at login to Lync.  By default, this feature is turned off in Lync Server 2010 RC, but you can enable it by typing the following command:
Set-CSLocationPolicy -Identity Global -EnhancedEmergencyServicesEnabled:$TRUE -LocationRequired:Yes
The default Location Policy is called Global, but you can create new site-level or user-level location policies if required by your deployment.

EnhancedEmergencyServicesEnabled enables the location features in Lync Server 2010. This must be set to $TRUE for anything else to work.

LocationRequired can be set to No (Don't prompt for location), Yes (prompt for location, but allow user to ignore) and Disclaimer (prompt for location and don't allow user to ignore).  If LocationRequired is set to Yes, users will see Set Your Location when they log into Lync for the first time at an unrecognized location:

If LocationRequired is set to Disclaimer, users will see the following:

If they dismiss the prompt, a message like this will pop-up:
The message can be changed by using the command Set-CsEnhancedEmergencyServiceDisclaimer.  The current documentation says that when using the Disclaimer option, users will not be able to make non-emergency calls if they ignore the prompt, but in the Release Candidate I was still able to make calls. 

When they type in a location name such as Home, a dialog box will pop up with additional address information:

To make this information available to emergency services, you have to make a few more modifications to the location policy using Set-CSLocationPolicy:
Set-CSLocationPolicy Global -EmergencyDialString "911" - EmergencyDialMask "112" -PSTNUsage "Emergency"
EmergencyDialString is the number that will be treated as being an emergency call. The call SIP data will include the user's location. This is 911 in North America.

EmergencyDialMask is an alternate number that will be converted to EmergencyDialString for the location profile. In this case, 112 (emergency dial number for many countries) would be converted to 911 and treated as an emergency call.

PSTNUsage is the Phone Usage that will be used to route the emergency call. In this example, I used "Emergency", which is a Phone Usage I created that contains a route for 911 calls. 

With this enabled, your users will be able to input their own specific location information so that emergency services can easily find them if they call 911.  The nice thing about it is that if a user goes to several locations and properly enters their address information, Lync will recognize those locations and will select it automatically the next time they are at that location. 

However, since this particular solution depends on users inputting their location information correctly, it isn't ideal for a corporate setting.  My next blog posting will detail how administrators can assign locations to users based on information stored in a central database.

Until then,
Cheers!
Ken