We going to use PowerShell to move users – but there’s quite a bit to consider when migrating, key to which is understanding the driver of the cloud adoption
pro list cloud adoption
- Cost – companies can make a considerable savings in TCO , this is a big driver , migration paths are often designed to end when the next big contract is due to be signed for the vendor – though sometime especially when you analyse the costs it can be that the client is paying more – cloud is not cheap and you have to be wary of how things are billed
- New functionality – the pandemic has only served to poor gasoline on the fire that was pre-pandemic cloud adoption ,the web stack is literally the coal face WebRTC and just the way teams does that job of searching and allowing the user to become his own web 2.0 knowledge base by searching through meetings and screen shares and documents all through the same interface means that the way your data is stored is more organic and of course not tied into your laptop, companies with a high emo intel understand that teams helps its users by allowing them to find their own answers which is only empowered by the way teams collaborates with the users
Cons list Cloud adoption
- Teams URI need to have a unique e164 number pattern – this means that every number on teams is uniquely dialable , that might not sound like a limitation but back in the day of Enterprise PBX deployment you could have an internal number that wasn’t part of the dial plan but that presented an external phone number mask that was contained within the dial plan to the trunk which would be accepted by the provider- so to put this right ? you must upgrade your DDI lines to remove these internal partitions -though these can be difficult to detect
- There are plenty of enterprise functionality which may not map in the cloud such as functionality in the analogue space, forwarding calls direct from the AA
- because of the URI requirement this means that PBX 4 digit dialing or any custom schemes that the user were used to – will no longer work
- in the MS world a line URI must have an AD account for it to work, so lines that don’t have associated users or AD accounts can’t be migrated
Pre migration check list
Interworking from the cloud perspective is realised by number plans and proxy sets, which select where you want the call to go
Interworking from the IP PBX perspective it is realised by number plans that use SIP trunking to the SBC and MS integration
Hybrid platforms mean that the act of migration becomes moving the line from enterprise to cloud and then cleaning the PBX
A PBX DDI and a Cloud telephony URI can’t exist in the same systems, so if you got a DDI line of 1111 and a Line URI of 1111 the architecture can’t route the call
The pre migration test list
- Check the site hybrid functionality – make inbound and outbound calls via cisco and make inbound and outbound calls via teams, test call forwards in both systems any analogue dependencies and IVR functionality don’t make any assumptions it will help to understand the dial plan
- check the PRI count how are the numbers delivered into the architecture
- Dump the IP PBX dial plan into excel – capture MAC addresses if you need to reverse any lines out of the migration – don’t delete what you don’t want to hide it
- Dump the corporate or replicated AD into Azure AD and get it into a form that doesn’t kill any LDAP replication and put it as a tab in the worksheet
- Hide elements you can’t migrate because of the functionality for teams the main ones tend to be phones in kitchens because chef doesn’t own a computer etc
- make sure that we a number is not internal for example, check to see if the extension fits the dial plan – test ones you think are internal
- check that the prefix groups in Audiocodes routing manager match the PBX ranges to migrate, this can also help detect internal extensions
- track shared lines in the PBX
- build your teams spreadsheet incrementally by hand which you will use to PowerShell to the cloud
Direct Media and Local media Optimisation
Direct media is where an e1 is terminated in an SBC that the enterprise manages. LMO is streaming media direct to an internal interface of an SBC, so you don’t have to stream over the internet. the following deployment topologies build the signaling and, media paths so you can build to understanding LMO
This should be in its own blog but i am going to attach it here, its key to understand the flows
Teams’ client talks to team’s client signalling
In this scenario the REST protocol signals the teams Microsoft cloud

teams to team’s client media
Its down to ICE to handle the media fixup

It’s the firewall and ICE’s job is to get the media in the best way possible between clients and it may use functions within the Office 365 network such as transport relays (media processors) if there is no direct path
Teams’ client to SBC signalling
endpoint generates the rest request and teams converts to an SIP invite and sends to the SBC

TEC to SBC media path without bypass

typically, the media can go through teams, but that isn’t the optimal path which would be between the client and the SBC

it’s quicker to go directly from the client to the SBC or centre media directly from the card to the SBC so in this case what we can do is enable something called media bypass now we’d pass bypass came out about a year ago it was just to basically a tick box in the configuration of the SBC you just said turn on media bypass and then teams will try to set up the call so the media will go directly from the client and straight across to the SBC
Media uses Silk codec ICE carried this media as well (Opus has been deprecated)
Client external to the SBC without media bypass
Without media bypass the signalling and media go from team’s client ot the SBC just like the TEC to SBC path

Client external to SBC with media bypass

client local to SBC without media bypass (m800 with PRI )

this stresses the firewall since we can see we are proxying through the client, also if the client is on the same LAN segment as the gateway the traffic is not optimal
Client local to SBC with media bypass (m800 with PRI)

you would hope that with media bypass the client would stream media direct to the SBC
but one of the limitations of ICE lite was that the SBC could only have one IP address which in this case is external facing toward the PRI interface
this meant that the media had to exit and re-enter the firewall

Local media optimisation solves this
it’s an enhanced media bypass, it uses Lis and LBR data to have location information
new sip headers include information about the user location
“external” or “internal ” in terms of the corporate network
this gives us smart call handling with more flexible topologies
you can still set up media bypass without LMO
prerequisite for LMO
configure sites and networks in teams using PowerShell new-CsTenantNetworkSubnet to define network subnets and assign them to network sites. Each internal subnet may only be associated with one site. Tenant network subnet is used for Location Based Routing.
New-CsTenantNetworkSubnet [-Tenant <System.Guid>] [-Description <String>] -NetworkSiteID <String> -MaskBits <Int32> [-Identity] <XdsGlobalRelativeIdentity> [-InMemory] [-Force] [-WhatIf] [-Confirm] [<CommonParameters>]
for example New-CsTenantNetworkSubnet -subnetID 192.168.0.1 -mask bits 24 -siteid london once its set up it can give you significant advantages
Local client use ‘internal’ header for media
client is sitting on the same LAN as the SBC

so, with the flag internal or external, site information and trusted Ip address, this means that the sbc can work with the client
the media flows through the SBC on an internal sip interface to the external SIP interface and out to the cloud
we are not constrained by ICE Lite which means we only have 1 ip for media, and we do not hairpin the firewall
client is external to the SBC with LMO

but codecs come to play here, the implication being that the SBC has got to transcode between G711 and SILK

but if you were an internal user you don’t have to transcode because the SBC will assign you to the G711 group and doesn’t have to transcode
Cisco hybrid site testing
find an IPC session and get it registered look in the PBX for test description and check inbound and outbound routing for the IPPBX side of the house and teams
check on the way the PRI or the SIP trunk is delivering calls into the site
so this site looks like a typical M800 / E1 gateway deployment with local media optimisation

4 connections in this implementation of teams, to the regional SBC (x2) to the MS voice proxy for teams (x2)
Inbound PRI call Cisco in Nuevo Laredo
Let make a check that the PRI is delivered by syslog to the M800 GW on VR01

to save my mobile cost i took advantage of the following feature SIP that is you can use a diversion header for a unregistered device
PRI Voice testing in VOIP environments trick
Pick a legacy site with a E1 termination and create a custom route pattern to carry your number for example

then use a called party transformation for the number you want to target via the e1 call

then you can choose any extension in the partition or associated CSS

but against the line

then all you have to do is exploit the VOIP dial plan by dialing the forwarded extension over VOIP dial plan

and then you would generate the trace above
Site PRI testing results
investigating the inbound call

This PRI is sending 4 digits – can it send 9999 if you bust the dial plan you get to hear the local provider, but does it hit the gateway first? i don’t think so since if you scan the syslog for a CUCM event there is nothing
some interesting things to test would be the main number for the CTI which is on which in this case we can use to test dtmf as well

These extra events where to the Microsoft voice proxy HRD

but then finally we end up on the Voicemail Unity call handler

so here’s another thing a forwarded line to the call centre

there was quite a lot of delay so i wonder if it’s hunting out the HRD again only 1 way to find out
Cisco Hybrid points
- The CLI is different for when you present the outbound call to the SBC vs a VOIP call to the enterprise
- The call tries the HRD SBC before routing to the local gateway for an inbound call
- if you blow the prefix group or trunk DDI the operator cuts in
- we can immediately start to build a map of numbers that we can’t migrate because of forwards
Cisco Enterprise AD teams Migration data
The act of migration from enterprise to cloud is an exercise in data manipulation, IP-PBX feature migration, power shell pipeline , Teams administration , IP PBX cleanup and then teams site verification
The three things you need to migrate a site
- The DDI lines to be migrated so they can be written as a line URI
- The data has to be Azure AD ready, specifically MS needs an email address for the domain of the DDI user which is used as a UPN
- A voice Policy
There are others but they are more about setting up tenants and cloud instances
Definitions
A User Principal Name (UPN) is an attribute that is an internet communication standard for user accounts. A UPN consists of a UPN prefix (the user account name) and a UPN suffix (a DNS domain name). The prefix joins the suffix using the “@” symbol. For example, [email protected]. A UPN must be unique among all security principal objects within a directory forest.
The line Uniform Resource Identifier (URI) must be specified using the E. 164 format and use the “TEL:” prefix.
A voice routing policy is a container for PSTN usage records. You create and manage voice routing policies by going to Voice > Voice routing policies in the Microsoft Teams admin center or by using Windows PowerShell. … Users will automatically get the global policy unless you create and assign a custom policy
Prefix Groups make routing management and Dial Plan management easier, more efficient, and more convenient for telephony network operators. The feature also makes it possible to import an existing customer’s Dial Plan into the ARM using the northbound REST API.
Every routing rule can have dozens of prefixes. Grouping prefixes and then associating groups with routing rules reduces visual complexity and allows for more effective management. Prefix Groups save operators from repeatedly having to add prefixes to rules.
Once defined, the Prefix Group comprising multiple prefixes is associated with a routing rule
for example, an enterprise has distributed offices, the following can be defined: If a caller calls from source prefix x, the call is sent from SBC 1; if a caller calls from source prefix 2, the call is sent from SBC 2.
To develop a customer-specific Dial Plan into an ARM Prefix Group, the REST API is available.
PBX dump
If the PBX has a web interface select copy and highlight and paste special into excel as plain text, you will end up with the below

it also is worth understanding the translations that get us here from the PBX where the voice trunk number is normalised to the PBX dial plan

it’s also worth knowing how unity connection connects into the site

it’s worth putting this routing in the excel spreadsheet as different tabs
there must have been a translation pattern from when the e1 migrated so there must be a translation for a prefix group

and look if we do that

change the query to check the other range

Please automate me Building the list
This is where we need to manipulate that data
Frustratingly there is no import excel type module like here by default and i dont want to risk my pipeline since i only have just got my MS to connect so i guess i need to build more into my excel or strip out the data to a file system
if you do all the descovery you will end up with something like this

| PBX dump | name phrase /DDI | string |
| PBX dedupe | DDI | string |
| CTI | DDI | |
| Translation profile | DDI range | string |
| Mask / Range | DDI by mask | string |
| Power BI | UPN ,UID | String |
| Clues / AD | DDI | String |
| Prefix | DDI range | string |
so to create an engine to work out the eligibility purely on the basis of a string search task -hmm
Putting the pre migration check list to the test in Sao Palo
lets fine tune this list and put it to the test , i have to finish of the migration of a site in Sao Palo – it did have two physical sites fronted by a cisco voice gateway with a PRI interface , but they then split the site in the cloud / teams and deployed an m800 gateway
checking the ARM network map Architecture

The site has mulitple voice connections
The site has multiple voice connections , jsut like where i had joberg with one SIP trunk and one PRI split accross the gateways
| la-br-1673-saopaulo-audc-vr01 | VIP VOIP PRI 1_la-br-1673-saopaulo-audc-vr01_VoIPPeer VIP VOIP PRI 2_la-br-1673-saopaulo-audc-vr01_VoIPPeer |
| la-br-1673-saopaulo-audc-vr02 | Embratel PRI_la-br-1673-saopaulo-audc-vr02_VoIPPeer |
Voice connections vr01

Voice connections vr02

Logical configuration both sites
| Site ID | RNX | Nos Range | Voice Policy | Site IP subnets | PSTN usage gateway | hostname m800 | migrated status | |
| Sao Palo site 1 | 1673 | 425 | +551121090701 to +551121092298 | 1673-Sao Paulo-Users | yes | 1673-Sao Paulo-Usage | la-br-1673-saopaulo-audc-vr01 la-br-1673-saopaulo-audc-vr02 | Yes |
| Sao Palo site 2 | 373 | 424 | +551121092010 to +551121092117 | None | none | none | none | no |
Prefix groups in ARM

from the prefix group it looks like 3 ranges has been configured where some how we get to extension 2300 on a new addon to the range
+55112109[0700-0799]# for RNX 425 site 1673
+55112109[2000-2099]# for RNX 424 site 373
The financial prefix group looks like the best place to be since it covers all the ranges
Sao Palo Site 2 analysis
They have split the site logically but it share a continous range , but lumping 373 into 1673 might be a bit of a management head ache , but is possible , as log as thier is no duplicated extensions in the
so i am curious when it was on a cisco controlled PRI how did the cucm manage that ?
CUCM translation pattern config

site 373 ranges

site 1673 ranges


sanity check the ranges
\+.551121092[2-3]XX any extension starting 22 or 23 belongs to site 1
\+.551121092[0-1]XX any extension starting 20 or 21 belongs to site 2
Site 2 id 373 test device Cisco

so lets sanity check the 1st pre migration check list which was to test for hybrid working
site 2 id 373 test device TEC

Check the site hybrid functionality – make inbound and outbound calls via cisco and make inbound and outbound calls via teams , test call forwards in both systems any analogue dependencies and IVR functionality dont make any assumptions it will help to understand the dial plan
A genius
inbound call testing site id 373

in bound calls got this number cant be recognised
Site 2 id 373 test endpoint TEC
Neither inbound or outbound worked mainly because the normalisations seemed incorrect outbound calls where being prefixed by 0021 and was dropping the + (if you look in the invite below)

inbound calls got number not in service
Outbound call testing TEC
this worked ok dialing the full e164 pattern within Brazil
Things get interesting
So the site migration check list through up some interesting , that when we put a line in that second range we are hitting an outbound destination manipulation profile that doesnt support e164
outbound dialling from cisco prefixed a +55 which is an easier fix
let break down the teams inbound call
whats puzzling about this is that the site 1 / 1673 / 425 which works perfectly for TEC (id/rnx)
site 2 /373 /422 doesnt and we hit the number not in service annoucement for Cat
The inbound call gets this number in not in service for caterpillar , and this sugests that the pattern may be in CUCM , we see the voice mail kick in on the sdp which i guess is the steve bergstrom voice , but cucms kicking in to say that the number doesnt exist
the outbound call is picking up this prefix 0021 instead of a plus when it tries +44

this is what the invite looks like

spot of ARM testing
turns out there is the following manipulations

turns out we could update the table as to whether a site is CBLC or financial
so wheres my prefix come from

so anything that starts with a plus gets prefixed with the 021
when i tested with my mobile

so it should hit the first pattern but its taking the 4th as you can see in the first SIP header

so can i get the 021 from the other normlisation

so this normalsation doesnt append but when we test it

The final part of the mystery
there must be a link between the prefix group and the manipulation – which purely depends what digits you put out there
the tale of two routing rules


LA-BR-1673-Sao-Paulo-Financial
SOURCE
Prefix Groups:
Ⓖ LA-BR-1673-Sao-Paulo-Financial
DESTINATION
ADVANCED
Notify when activated:
false
Prioritize call:
false
Registered users:
false
Request type:
Call
Privacy policy:
Transparent
CALL TRIGGER
Initial:
true
Refer:
true
3xx:
true
Broken connection:
true
Fax rerouting:
trueACTIONS
ROUTING
Method:
Sequence
ACTION
Priority: 1
VIP VOIP PRI 2 (la-br-1673-saopaulo-audc-vr01) , Src Man.: LA-BR-1673-Sao-Paulo-Financial-Outbound Source ( From, PAI, PPI ) Dst Man.: LA-BR-1673-Sao-Paulo-Financial-Outbound Destination
Priority: 2
VIP VOIP PRI 1 (la-br-1673-saopaulo-audc-vr01) , Src Man.: LA-BR-1673-Sao-Paulo-Financial-Outbound Source ( From, PAI, PPI ) Dst Man.: LA-BR-1673-Sao-Paulo-Financial-Outbound Destination
drag_indicatorLA-BR-1673-Sao-Paulo-CBLC
LA-BR-1673-Sao-Paulo-CBLC
CONDITIONS
SOURCE
Prefix Groups:
Ⓖ LA-BR-1673-Sao-Paulo-CBLC
DESTINATION
ADVANCED
Notify when activated:
false
Prioritize call:
false
Registered users:
false
Request type:
Call
Privacy policy:
Transparent
CALL TRIGGER
Initial:
true
Refer:
true
3xx:
true
Broken connection:
true
Fax rerouting:
trueACTIONS
ROUTING
Method:
Sequence
ACTION
Priority: 1
Embratel PRI (la-br-1673-saopaulo-audc-vr02) , Src Man.: LA-BR-1673-Sao-Paulo-CBLC-Outbound Source ( From, PAI, PPI ) Dst Man.: LA-BR-1673-Sao-Paulo-CBLC-Outbound Destination
calling restrictions enforced by outbound destination CLBC
what i am hitting is the CLBC translations which for that circuit uses 021 as the trunk access code to dial the e164 pattern
if you dial a number in brazil as the +55 it works but it wouldnt be good to offer , but it was nice to get a connected call
it basically looks like that this call center is not enabled for TEC e164 dialling so we just got to make that work in the outbound and inbound manipulations for CLBC to see how close we can get
Conclusion maybe a week later……..
The list that the lcon gave had users from rnx 424 site 1673 which had already been migrated so that really put the cat amongst the pigeons , but the extension range for these already migrtated users was right for 1673. Inbound and outbound teams calling worked for the site and restrictions where enforced the only thing that didnt work was international outbound but the outbound manipulations where built to just enforce brasil outbounf no where else






























































































