I recently had a case where a customer had geographic DDIs assigned to their users, offices, and applications. This customer underwent a digital transformation exercise and decided to obtain non-geo (+44300xxxxxxx) numbers for the business.
Users were assigned a new DDI from the contiguous non-geo range. For offices and applications such as response groups it was decided to forward the relevant geographic number to the non-geo number.
This had the benefit (then) of ensuring their customers could continue using the old numbers they knew to transact business with the company. The new numbers were published on public facing websites and if a contact opts to use these – they would also be able to reach the business.
All was going as well as it could until the customer decided to move to Calling Plans for Microsoft 365. This meant porting their numbers. Unfortunately, they could not move all the numbers at the same time due to different SLAs of the losing carriers.
Say for instance, there is a non-geo number +443000123456 assigned to a Skype for Business Response Group and second number +442081234567 forwards to the non-geo number (+443000123456).
Agents were migrated to Teams Only and a new Call Queue created with a temporary service number. The original non-geo number now forwards to this temporary service number.
The scenario now looks like this:
+442081234567 => +443000123456 => Temporary Phone System service number
On-prem => On-prem => Phone System/Calling Plan
This still worked as expected. You could dial any of the 3 numbers above and reach the Call Queue. +442081234567 was ported to Phone System and that broke a portion of the forwarding as members of the public who were used to dialling +442081234567 got the “number is not in service” message. There were lots of callers. Cue panic.
This is where the New-CsTeamsUnassignedNumberTreatment cmdlet comes into play. As per the description: “Creates a new treatment for how calls to an unassigned number range should be routed. The call can be routed to a user, an application or to an announcement service where a customer message will be played to the caller.” Ah, this is sounds similar to the New-CsUnssignedNumber cmdlet found in Lync Server & Skype for Business Server.
The first example in the Microsoft Docs article seem to be exactly what I needed:
$RAObjectId = (Get-CsOnlineApplicationInstance -Identity aa@contoso.com).ObjectId
New-CsTeamsUnassignedNumberTreatment -Identity MainAA -Pattern “^\+15552223333$” -TargetType ResourceAccount -Target $RAObjectId -TreatmentPriority 1
Substituting the resource account, name, and phone number with the customer’s did the trick.
Calls placed to +442081234567 now routes to the Call Queue as originally intended.