Thanks again everyone for attending the Lightning Talks tonight.
For reference, here is my slide deck if you would like to review it.
Sean
Thanks again everyone for attending the Lightning Talks tonight.
For reference, here is my slide deck if you would like to review it.
Sean
If you’ve moved users from Skype for Business OnPrem to Microsoft Teams, you’ll most likely understand the pain of finding the Hosted Migration Override URL.
Previously, the guidance was to find the URL by browsing to what was (for a time) the legacy Lync/SfB Online Portal. With the deprecation of the portal, you will need to find the URL using PowerShell.
Have I mentioned that I like PowerShell yet? 😉
After doing this one or two (or more) times, I decided to create a function I can include in future scripts and I thought I’d share that with you to make your life a little easier too.
Enjoy and good luck with those migrations!
function GetHostedMigrationOverrideUrl(){
$tenantnameid = Get-CsTenant | select -ExpandProperty identity
$tenantnameid -match “.*DC\=lync(.*)001\,DC=local”
return “https://admin$($Matches%5B1%5D).online.lync.com/HostedMigration/hostedmigrationService.svc”
}
We were recently asked to migrate a customer from Exchange UM Auto Attendant to Microsoft Teams Auto Attendant. The feature they used extensively in Exchange UM was “Dial by Extension”. Now, before you tell me how extension dialing is dead, I assure you their use case was solid and there was no easy way to resolve the business requirements without extension dialing (we could use Dial by Name, but we all now how fun that can be what with a multitude of accents and interesting name pronunciations we encounter in daily life.
Lucky for us, Dial by Extension was recently released to our tenant, so I decided to give it a whirl.
High level thoughts are that, while it works, I think some of the decision making required a little more challenging. Things such as not searching the MsRTCSIP-LineURI attribute for extensions means the migration from Exchange UM Auto Attendant (which did search this field) to Teams Auto Attendant (which doesn’t) is more complex than it needs to be.
Microsoft lists some “Important Notes” which I found to be quite enlightening, as it clearly shows that they either were aware at development time or became aware quickly after release that they’d missed some vital requirements in the deployment of this feature.
Important
Please observe the following:
+<phonenumber>;ext=<extension> or x<extension>.The first point seems perfectly fine on the surface, numbers need to be formatted in a certain way to allow the search function to work as required. What is interesting though, is if you combine that with point 4, which I find frustrating. Why did Microsoft decide to go backwards on this functionality. I cannot fathom why they didn’t include the LineURI attribute we’ve used for years in the search (and don’t even get me started on searching the Mobile Phone Number field for extensions *argh*)
The second point speaks to not supporting assigning the extension in the Teams Admin center. This is because the Dial by Extension is searching “core” AD fields and not the Enterprise Voice fields we usually use. These fields are not exposed in the Teams Admin center, so nah, you can’t assign values there – pretty obvious reason, eh?
In my testing, it did take a while to sync and start working (I left it overnight, so I cannot attest to the exact number of hours before it started working)
Hope this helps shed some light on what’s there and what’s not.
Have you tried to use it yet? I’m keen to hear your thoughts.
More info available here
Microsoft have now enabled the ability for administrators to mark Teams meeting traffic with QoS markings.
This setting can be found in the Teams admin portal (https://admin.teams.microsoft.com/meetings/settings) or by using the PowerShell commandlet Get-CsTeamsMeetingConfiguration.
It looks like this:

