Moving On…

I’ve not blogged on this site for quite some time, in fact a year now. Logging into the site to post this was a challenge in itself. As probably you can imagine, the blog is now retired. Trying to put aside the time these days for a personal blog is impossible with my other ventures and work.

I have not left the community, far from it, I’ve even recently been reawarded MVP but my endeavours are now solely with Commsverse. 

I do occasionally blog technical content when I can, but that will be on the Commsverse blog. If you are wondering what Commsverse is, well its a Community Tech Conference about Teams. Perhaps you will head over there and attend an event in the future.

For now, though, this blog is now here for archive purposes. I won’t be adding to it or responding to comments on articles anymore.

Thank you for your support over the years here, I’ve enjoyed it. Maybe I will come back to this in the future, who knows.

 

Until then,

Peace Out!

Skype for Business Mobile Autodiscover Gotcha When Moving to Microsoft Teams

On a migration recently we moved a bunch of users from Skype for Business On-Premises to Microsoft Teams Only, leaving behind Enterprise Voice users for the time being.

During this interop period it is required that both EV and Teams users can join Skype for Business meetings hosted by the remaining on-prem users until such time as Teams meetings take over.

After moving several users, reports came in that Teams Only people could not sign in to Skype for Business using the mobile app to join a Skype meeting, but where able to sign-in using the Skype desktop client.

The message received on the mobile client

Troubleshooting the issue with the old Lync Connectivity Analyzer suggested that something wasn’t quite right with the authentication process via the autodiscover web service

Autodiscover: SendRequest(): the URL https://lyncdiscover.commsverse.com/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=commsverse.com?sipuri=John.Smith@commsverse.com couldn’t be connected.  Complete HTTP headers:\r\n Pragma: no-cache

I decided that I would run CLS Logging and trace the authentication, so from a Front End

Start-CsClsLogging -Pools FEPOOLA.commsverse.com -Duration 00.00:02 -Scenario Authentication

I attempted to sign in from mobile to capture some logs.

Searching the logs, top tip to reduce the export size, always specify the URI you are interested in, it makes following the log much, much easier!

Search-CsClsLogging -Pools FEPOOLA.commsverse.com -OutputFilePath c:\temp\mobile.log -Uri "john.smith@commsverse.com" -MatchAny

Opening the log in snooper and following it line by line I found that authentication passed, but the FE could not find the hosting provider for the user.

(0000000001B0CB29)Could not find hosting provider for hosted user. User: john.smith@commsverse.com

So Next step was to check the hosting provider for Skype for Business Online

Get-CsHostingProvider -Identity SkypeforBusinessOnline
Identity                  : SkypeforBusinessOnline
Name                      : SkypeforBusinessOnline
ProxyFqdn                 : sipfed.online.lync.com
VerificationLevel         : UseSourceVerification
Enabled                   : True
EnabledSharedAddressSpace : True
HostsOCSUsers             : True
IsLocal                   : False
AutodiscoverUrl           :

Missing was the Autodiscover URL for Skype Online, so setting that on the hosting provider as follows

Set-CsHostingProvider -Identity SkypeforBusinessOnline -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

Forcing replication of the CMS and then trying to sign in again fixed the issue and Teams Only users are able to sign in to Skype for Business Online using their mobile app successfully.

The reason why the desktop client was unaffected is because it looks up the _Sip SRV DNS record for the access edge location and redirection was happening properly through SIP registration.

So make sure you set the Autodiscover URL in your Hosting Provider for SfB Online if you want mobile sign in for those legacy meetings!

Tranching Users Ready For Your Microsoft Teams Migration

If you are planning on migrating your users from another system, perhaps Skype for Business or indeed a 3rd party system, the question of how to do this gets more complicated to answer as the numbers of users you have to deal with increases.

Consider the scenario where you have a large Skype for Business deployment of tens of thousands of users. There will be a number of users with a persona that can be easily migrated to Teams e.g. chat and meetings. Others will be more complicated and require more thought, voice users for instance.

Doing moves from Skype to Teams using PowerShell is a must, but when you are moving hundreds, or thousands of users in multiple threads and shells to the cloud at scale and speed, how do you keep track of your progress, and more importantly ensure that you are moving the correct users?

The answer invariably means tranching your users offline in some kind of Excel file. To ease the burden of this manual task I have created a simple script to tranche users based on a full export from your Skype for Business deployment.

Step 1 – Export your users to csv files

You can export your users to one csv file by running this command

Get-CsUser | Export-Csv c:\temp\allusers.csv -NoTypeInformation

Alternatively, you can export by whatever chunking condition you want, e.g. users by pool

$pools = Get-CsPool | Where {$_.Service -like "*Registrar*"} | Select Fqdn
ForEach ($pool in $pools){
    Get-CsUser | Where {$_.RegistrarPool -eq $pool.fqdn} | Export-Csv "c:\temp\$($pool.fqdn).csv" -NoTypeInformation
}

Step 2 – Edit the Tranching Script

The default behaviour of the tranching script is to tranche all users that do not have Enterprise Voice Enabled. You can make your own filter by editing the line (31)

$validUsers = $importFile | Where {$_.<column name to filter on> -<condition> <value>}

Step 3 – Run the Script

Run the script from PowerShell to parse the source files extracted in Step 1. The script will ask you the location of those files as an input parameter e.g. c:\temp\.

The script will collect all csv files in that directory and parse them as per your condition filter. By default, it will create csv files in output folders in blocks of 250 users per file. You can then use these files to migrate to Teams using multiple shell windows, users and servers.

If you want to change the number of users per tranche, edit the script and change the following variable

$blockSize = <your number here> default is 250

The script can be found below

 #Tranching Users by Source File

$sourceDir = Read-Host "Please set the working directory of where the Source Files are"

$filesToProcess = Get-Childitem $sourceDir | Where {$_.Extension -eq "csv"}

ForEach ($sourceFile in $filesToProcess){

    Set-Location $sourceDir

    $importFile = Import-Csv $sourceFile.Name

    #create output dir

    $folderName = ($sourceFile.Name).split('.') | Select -First 1

        try{

        New-Item -ItemType Directory -Name $folderName -Force

        }catch{

        }

    Set-Location ".\$($folderName)"

    # Filter users that are not EV enabled

    $validUsers = $importFile | Where {$_.EnterpriseVoiceEnabled -eq $False}

    $countUsers = ($validUsers).count

    Write-Host "There are $($countUsers) users found to be tranched" -ForegroundColor Yellow

    # Set Pagination

    $blockSize = 250

    # Create Tranches

    $startPos = 0

    $counter = 1

        While($startPos -lt $countUsers){

                $validUsers | Select-Object -Skip $startPos -First $blockSize | Export-Csv "MigrationBlock_$($counter).csv" -NoTypeInformation -Force

                $startPos += $blockSize

                $counter++

                Write-Host "Tranching next Block Starting at Row $($startPos)" -ForegroundColor Yellow

    }

}

    Write-Host "Finished Tranching Users" -ForegroundColor Green 

Creating a Cloud Auto Attendant or Cloud Call Queue for both On-Premises and Teams Only Users

With Exchange Unified Messaging being removed from Exchange Online In February 2020 and being already removed from Exchange Server 2019, organizations have to be actively planning a replacement for all Exchange UM Auto Attendants that is currently in use. This guide will explain what is required, how to configure Cloud Auto Attendants and Cloud Call Queues, and how to validate the newly created Cloud Auto Attendant(s) and/or Cloud Call Queue(s).

NOTE: This guide pertains primarily to organizations that are using Skype for Business Server on-premises with Exchange UM, not cloud-only customers.

This guide will be broken down into four main sections:

  • Planning & Prerequisites

  • Setup Process

  • Testing & Validation

  • Clean Up

Planning & Prerequisites

What is happening?

Exchange Online UM is to be turned off in February 2020 and after that, all Auto-Attendants will no longer work. Voicemail services that are currently provided by Exchange UM will be automatically migrated to the new Cloud Voicemail service, however, Auto Attendants need to be manually migrated. The goal of publishing this guide is to make users aware of Exchange Online UM’s impending doom and to push for the need of migrating to the new cloud services to prevent down-time for one’s organization. This guide will take an existing Exchange UM Auto Attendant, remove it from the environment and provide the steps to use a modern Cloud Auto Attendant.

In regards to Cloud Call Queues, there is no major need to migrate to the service if you are wanting to keep all existing users on-premises with Response Groups. Where they become extremely useful is for migrating users to Microsoft Teams as Cloud Call Queues can be used to dial both Microsoft Teams Users and Skype for Business Server/Online users.

Benefits of Cloud Auto Attendants and Cloud Call Queues

This is a cloud built application that works with both on-premises and cloud-based users

  • Useful for organizations not moving to Microsoft Teams over-night and need to retain interop with both on-premises and cloud-based users

  • No need to convert audio files to a single-channel WAV format

          • Audio sounds a lot more crisp due to this

  • If Teams Direct Routing is used, they are free as long as a single Phone System license is added to a Microsoft 365 Tenant.

Which features no longer exist?

A few features no longer exist in Cloud Auto Attendants/Cloud Call Queues that used to exist in Exchange UM Auto Attendants

  • Direct Dialing of E.164 phone numbers (Coming Soon)

  • Direct Dialing of Extensions (Coming Soon)

NOTE: Many other Exchange UM features no longer exist such as Subscriber Access, Fax, and more. These features do not pertain to Auto Attendants but pertain to Exchange UM.

Prerequisites

A few prerequisites need to be addressed before the resource accounts can be created:

Skype for Business Server Software Version

  • Skype for Business Server 2015 – CU8 or Higher (Current Version is CU10 HF1)

  • Skype for Business Server 2019 – Any version (Current Version is CU1 HF1)

Must have hybrid connectivity to Skype for Business Online

  • Includes Azure AD Connect

• Licensing Requirements

  • At least one Phone System license purchased (Included with a E5)

  • Once at least one Phone System license is purchased, free Phone System – Virtual User licenses can be obtained

  • Users must have a Small Business License with Business Voice, Enterprise E1 or E3 with an additional Phone System license, or E5 IF they are cloud based. If on-premises, no additional licensing is required

Must have Microsoft Teams Direct Routing configured or a Cloud Calling Plan

  • Refer to my Deploying Direct Routing for Microsoft Teams guide! – CLICK HERE

Setup Process

Step 1: Create an on-premises resource account

On a Skype for business Front-End Server or a Trusted Application Server, run the following PowerShell cmdlet but with using different variables. The Display Name is How the Auto Attendant or Cloud Call Queue will appear within the Skype for Business Client, the SIP Address is the SIP Address, and the OU is where the account is to be created. Make sure that this created in an OU that is part of the Azure AD Connect Sync Group.

New-CsHybridApplicationEndpoint -DisplayName OH1_RA_AA1 -SipAddress sip:OH1_RA_AA1@msftnettest.co -OU “ou=Resource Accounts,ou=MSFTNET Test,dc=msftnettest,dc=co”

Step 2: Assign a phone number to the resource account

Use the below cmdlet to set the Line URI for this account IF Microsoft Teams Direct Routing is being used. Note that this is not needed if this auto-attendant is a nested auto-attendant in either scenario. Additionally, if the cmdlet prompts and states that the phone number is not unique, the Exchange UM Contact or the response group will need to be deleted or another user account has that phone number assigned. Follow the steps at the end of this guide to remove the ExUmContact.

Set-CsHybridApplicationEndpoint -Identity OH1_RA_AA1@msftnettest.co -LineURI tel:+13305768835

Step 3: Force sync the account to Azure AD (Optional)

To speed up the process of generating the online application instance and not wait up to 30 minutes, the newly created account can be force-synced to Azure AD. On the server that runs Azure AD Connect run the following two PowerShell cmdlets:

  • Import-Module ADSync

  • Start-ADSyncSyncCycle -PolicyType Delta

 

Step 4: Assign a Virtual Phone System License to the Resource Account

Now that the account exists in the cloud, a Phone System – Virtual User license needs to be assigned to the resource account.

1. Login to the Microsoft 365 Admin Center as a Global Administrator at https://portal.office.com

2. Click “Admin”, then “Users”, and then select the newly created Resource Account

3. Click on the “Licenses & Apps” tab, select the Phone System – Virtual User license and then click “Save Changes”

Step 5: Connecting to Skype for Business Online

At the time of writing, on-premises phone numbers cannot be assigned to resource accounts via the Microsoft Teams Admin Center. If a Calling Plan will be used for the AA or CQ, do not use the following steps. This is potentially an upcoming feature, but I am not sure if this will ever come to the admin center. To begin, a connection to Skype for Business Online PowerShell is needed. Follow the below steps setup the necessary prerequisites to connect to SFBO:

1. Install the Microsoft Online Services Sign-in Assistant

2. Install the Skype for Business Online PowerShell Module

3. Enable script support on the local computer by running the below PowerShell command as a local administrator.

  • Set-ExecutionPolicy RemoteSigned

Now that the prerequisites are now satisfied, it is time to connect to Skype for Business Online. There are differences in this process depending on how a global administrator account is configured. Run the commands below that option that matches how authentication is setup for the account:

Option 1: The Account does not have Multi-Factor Authentication Configured

  • Import-Module SkypeOnlineConnector

  • $userCredential = Get-Credential

  • $sfbSession = New-CsOnlineSession –Credential $userCredential

  • Import-PSSession $sfbSession

Option 2: The Account has Multi-Factor Authentication Configured

  • Import-Module SkypeOnlineConnector

  • $sfbSession – New-CsOnline Session

  • Import-PSSession $ sfbSession

 

Step 6: Assign a Teams Direct Routing or hybrid number to the Resource Account

If an on-premises phone number is being used for the newly created account, run the following PowerShell cmdlet to assign the on-premises phone number:

Set-CsOnlineApplicationInstance -Identity OH1_RA_AA1@msftnettest.co -OnpremPhoneNumber +13305768835

NOTE: The Application Instance can take up to 24 hours to be created! Use the Get-CsOnlineApplicationInstance cmdlet to see if Microsoft 365 has created the instance or not.

Step 7: Create a Cloud Auto-Attendant or Cloud Call Queue

Now that things are good to go from a resource account perspective, an auto-attendant or cloud call queue can be created. This guide will not cover the specifics of each, but when creating each, select the newly created resource account as show below:

Testing & Validation

With the Cloud Auto-Attendant(s) or Cloud Call Queue(s) created, functionality can be tested.

Call into each Auto Attendant and verify that:

  • Any custom greeting(s)/automated messages play

  • Voice commands work (If enabled)

  • All menu options are pronounced correctly and can be reached

  • Business hours work (If applicable)

Call into each Call Queue and verify that:

  • Any custom greeting(s)/automated messages play

  • The selected routing method works correctly

  • All members on-premises and in the cloud are able to be reached

  • Business hours work (If applicable)

Clean Up – Exchange UM

This section really only applies to organizations that have Skype for Business Server and have just created a replacement for their Exchange UM Auto-Attendant. The following steps need to be taken to remove the Exchange UM Contact in Skype for Business Server and remove the former AA from Exchange Server. This step has to be completed first if the same phone number is being reused or last if a new phone number is being used.

Step 1: Remove the Exchange UM Contact

On a Skype for business Front-End Server or a Trusted Application Server, run the following PowerShell cmdlets but by using different variables. First we need to identify the SIP address of the Exchange UM Contact that we wish to remove by using Get-CsExUmContact cmdlet. Once the SIP address has been identified, fill that in on the below cmdlet

Remove-CsExUmContact -Identity sip:OldExchangeUMAddress@msftnettest.co

Step 2: Remove the Auto Attendant from Exchange Online

In the Exchange Online Admin Center, click Unified Messaging > The UM Dial Plan > Single Click the AA you wish to remove > Click the Trash Can > Confirm the Removal. Note that this step is optional

Clean Up – Response Groups

This section only applies to organizations that moved from a Response Group to a Cloud Call Queue. Remove the RGS Workflow, the Queue, and the Group from the Skype or Business CSCP Control Panel. This step has to be completed first if the same phone number is being reused or last if a new phone number is being used.

Special Thank You!

I want to give a special thank you to anynode for giving me a license to use their SBC for this guide. Be sure to check out their amazing product at https://www.anynode.de/

Feel free to reach out to by commenting below or via twitter @EricMarsi if you have any questions!

Data Inaccuracy Blocks Voice Deployments with Microsoft Teams

Time and time again I come across the same old issue when customers want to use Skype for Business or Microsoft Teams for voice and they want to retire their old PBXs. That is data quality issues!

The same can be said for customers who are green and want to “light up” calling in Teams from their existing Office 365 data.

What data am I talking about? Well, the most important piece of data is the telephone number. This should be simple, but often it is not. You’d be surprised that although the end user of that phone number knows it, the majority of the systems and administration staff (IT, HR etc.) don’t.

Typically, there will be several directories used as the data source, we have AD, HR databases, PBX phonebooks, Printed Cards, or books on walls, people’s personal contacts, post-it notes. The list goes on. Yet when you look at all these data points you’ll realise that the number for Mary Smith is different across these data sources.

You see, in the PBX and VoIP world, the phone number is not personal to the user assigned it. The number is personal to the device the user is using. Think of it as a tenant and landlord situation. The mortgage company (in this case the PBX) deals with the landlord to make sure that they keep on paying their bill (the phone), while the tenant (the end user) lives in the house. Tenants change, as do people using the phone, but the landlord doesn’t tell the mortgage company because they don’t care, its information they do not need to keep the system running as designed.

What usually happens in organistions is that when a user moves, the next person just takes on the phone and number on the desk. There probably won’t even be a IT ticket for it, just the Manager saying, ah yes, use that phone.

As time goes by, change by change the data that was once accurate drifts more into irrelevance. Fundamentally, the system works, but when you come to the point of moving away from it, then you realise how much of a pickle you have found yourself in.

If you are moving to another VoIP system, then of course, it’s easier, but still trash in, trash out if you do not address the data issue. However, with a Unified Communications platform that ties a user to several communication identities e.g. E-Mail, SIP Address, Phone Number in one platform, it is absolutely necessary that you know that each of these identities is accurate for that user.

Take a situation I found myself in many times. The customer supplies the data file from their HR database of users to migrate. They affirm to me that this is the most up to date, most accurate data source to base a migration off. We analyse the VoIP system to find the relationships between the stations, set up hunt groups, shared Line appearances, team call groups etc all ready to go, and then we enable the users we believe are the owners of that number for Teams / Skype. Job done, lets all go back to the hotel for some Pizza!

The following day feeling all positive and enthusiastic because the night before went so well, we get to site. 9:45am, there is a service ticket, I am not receiving calls. 9:50am Why am I getting John’s calls, I am Matt? 09:51am Why are some phones randomly ringing together in the office?

All of a sudden we are hauled into a crisis meeting and hastily roll back the migration. The customer labels the migration a failure and offloads on to us.

The reality is quite different, the migration was a success, the process and steps worked end to end. The problem of course was the data that was supplied into the process at the beginning.

Experience has taught me that pre-project / migration data cleansing is absolutely necessary. A lot of companies will not factor that in to their migration project and when asked will be very resistant to remediation. But if it is not done, then moving to Teams will be a very poor experience.

To fix the problem, you must first understand how it has been created in the first place. Here are some of the most common factors that I have come across

  • User leaves and service ticket as part of the off-boarding process is not assigned to telecoms for decomissioning of the station assigned to the user
  • User moves within same department and number change happens without IT involvement
  • Issue with the execution of the off-boarding process where the telecoms admin does not update the station profile
  • There is no relation to users in the PBX configuration for a station by design because admins don’t want the problem of maintaining relationships to names
  • AD admins when disabling the account for (x time to infinity) do not remove the number from the telephone attributes in the object

Moving to Unified Communications enforces change to these processes and they must be enforced otherwise the business will grind to a halt. With Teams et al you cannot simply get around a miss assignment of a number, because the system will route the call straight back to the person who has been assigned that in the UC platform, regardless of any external factor that disagrees with it.

How do you fix these as a project?

Well, you have three choices that you can make with your customer

  1. The best solution is to remediate the problems at source and give you a good start of migration success. This will involve surveying the users and asking them to confirm their phone number to you. Once confirmed, you’ll need to update the source systems, but AD will be the most important one as that is what Teams will use moving forward
  2. Fix forward and move with a dataset that you collectively agree based on business analysis is the most accurate knowing that their will be problems and having a process in place to resolve those
  3. Implement green field and give as many users as the business can sustain new phone numbers and manage through change and awareness.

All options require you to keep at least AD up to date. Giving new phone numbers to users is not as taboo as people make it out to be. It can be managed if it is known ahead of migration. Some may have to keep their number, but if 80% of users could function with new numbers with no business operation impact, your migration complexity has just reduced to 20%. This means that the customer can start taking advantage of Teams for voice quicker whilst the complex scenarios are worked on.

I have run successful migrations in the past where number change has been managed through advanced communications and instructions with a clear date where the old number will cease to operate. One technique is to get the user to record a voicemail greeting to say on this date my number will change to.. as well as email footer updates etc. Its not that hard and it is more convenient to the user than IT trying to ensure quality through compromised data and getting it wrong.

Once decided on the model, ensure that operationally you fix the processes to ensure that AD is updated with MACD changes. Teams / Skype contact cards will use phone numbers (including mobile) that are extracted from the telephone attributes on the user’s object. These are synced to AzureAD and any inaccuracies will also be present there.

My closing statement here is that enabling Teams voice is really easy as long as you embrace and face the problem of data quality head on before you plan migrations. If you ignore it or dismiss it’s importance, then believe me you will feel pain at a level you have never experienced before. Untangling spaghetti is hard enough, it’s even harder when it is boiling hot!

 

Proximity Join Fails with Microsoft Teams

I was demoing Microsoft Teams Meeting Rooms Proximity Join yesterday and came across a couple of nuanced behaviours that effect the ability to utilise this feature.

The first issue was that even with bluetooth beaconing enabled, the Teams client wouldn’t find the room when pre-joining the Teams meeting.

The problem was that post enabling the bluetooth beaconing feature you should restart the MTR device as just enabling it in the back end admin settings is not enough.

The second issue that prevented proximity join derives from organiser presence. If you are in a presence state of Do Not Disturb, this prevents proximity join from working. The fix here of course, is to reset, or change your presence state to another setting and then proximity join will work.

Very short post, but these are simple fixes that at the start of a meeting can make you panic.

 

Microsoft Teams Gets Behind Commsverse

Last week I had a Teams Call from Laurie Pottmeyer, Senior Program Manager for Microsoft Teams. It seems that the Microsoft Teams Product Group had heard about Commsverse and wanted to know how they could help.

After a good chat the plan was revealed and whilst I cannot disclose the finer details of the conversation, what I can say, with huge pride and humility is that Microsoft Teams has fully committed to supporting Commsverse!

This exciting news means that we can now unveil Microsoft and in particular Microsoft Teams itself as an official technology sponsor for Commsverse 2020!

How cool is that?

We still can’t quite believe it and we are honoured to be able to carry this logo in support of our event!

But what does this mean for our potential attendees and sponsors?

For our sponsors, they now have the backing and support of the technology provider in the same event and this endorsement goes a long way to validating Commsverse as a relevant and important event on the calendar.

For our attendees, having the Microsoft Teams Product Group’s support and sponsorship means that we will have some exciting news to share with you soon. We are working closely with PG on securing a few names to come over and present at Commsverse. Some names that may be very familiar to you…

Having Product Group members at Commsverse gives you a unique opportunity that normally only happens on USA soil to get up close and personal with the people that actually own Teams and have meaningful conversations that could help your move to Teams and you could even influence future development of Teams!

If you’re not going to Ignite, then Commsverse could be the alternative event for you. As we are small and focused, we give you unparalleled access and time to these people that you would struggle to get at larger expo events. This could be incredibly valuable to you.

At this stage we are excited to announce that Laurie Pottmeyer will be in attendance at Commsverse 2020!

Laurie Pottmeyer

Senior Program Manager, Microsoft Teams, Microsoft Corp

https://www.linkedin.com/in/lauriepottmeyer/

More Teams Product Group Members will hopefully be in attendance, once we have secured their time we will announce them!

Remember, we only have 350 tickets in total and they are selling. Our current count is close to 300 left and these will soon sell out. You can register for your ticket www.commsverse.com/registration now.

Swagit.io – The Live Audience Raffle Site

I am pleased to announce that Swagit.io has formally launched! What is Swagit? It is a Live Audience Raffle site. It has been created for user groups, breakout sessions or other meet-up events where the organiser, or presenter would like to give away prizes, or as we like to call it, Swag!

Swagit replaces the need to hand out raffle tickets to run your live draws, instead competitors simply use their internet connected device to connect to Swagit and enter a raffle.

So how does this work? Well we have designed it so that it really takes less that 10 seconds to join. The best bit is that we don’t collect any personal information, we don’t need your email address, a username or any other personal information from anyone and it is totally FREE to use.

If you want to run a prize draw / raffle, simply add swagit.io/go to the end of your PowerPoint session to open a brand new raffle draw.

Your competitors / audience can now join your raffle by either browsing to swagit.io and entering the PIN number on the homepage, or directly browse to the draw using the custom URL e.g. swagit.io/1198 or whatever the PIN number is for your draw.

They will be prompted to enter their name. This name can be any name they want. They can choose to enter their own name, or a pseudo name. The point is that it will be unique per draw. If there are two Hannah’s in the room, the second Hannah will have a number appended to her name e.g. Hannah2 automatically.

Your participants will then show up on your screen. When you are ready, press start draw.

 

The draw will take place choosing a random competitor from the list. The winner will be shown on your screen and the screen of the winner

The winner and the prize draw organiser should keep their windows open until the verification code has been visually checked by the organiser / presenter to ensure that the correct person is claiming your prize.

Other participants will be notified that they haven’t won and can exit the draw.

Important as a participant you must remain in the draw with the screen open until the draw has completed. Closing your browser, or clicking the close button prior to the completion of the draw will remove you from it and you will never win! You’ve got to be in it, to win it!

Please feel free to use this in your own events and meet-ups, or see it in action at Commsverse 2020 

 

 

Microsoft Teams Media with Privacy Boundaries

Recently there was a discussion between myself and a few fellow colleagues about how media is treated by Microsoft based on the client and tenant location. This came about as a result of an Ignite session delivered by Korneel Bullens over the use of Transport Relays with Microsoft Teams media. It caused quite the debate…

The issue we debated was the bullet point “EU tenants use Transport Relay in EU and US” as a result of EU privacy laws. Searching the wide open internet revealed no clarification, or supporting evidence relating to this specific scenario, which contributed towards trying to get to the bottom of issue.

Our understanding, as per current documentation on docs.microsoft.com is that a transport relay closest to the client’s geographical public IP address is chosen where possible.

What is seemingly missing from this statement are the words “feasibly and legally” possible, according to the statement in the above slide extract.

So now consider your organisation has global presence, especially in APAC regions, but you have an EU tenant. What does this mean for your media paths for APAC users?

On the face of it seems that their media path is going to take a significant path across the internet for calls.

Well, after testing the answer is, it depends…

First, let’s take Teams meetings. A Teams meeting is spun up in the region that the first joiner is located. If this person happens to be in APAC, then the Teams meeting and MCU will be located in the APAC region e.g. Hong Kong, Singapore etc.

The behaviour now depends on your outbound security settings on the corporate firewall, and taking some assumptions about internet breakout.

If the APAC users break out of the corporate network in APAC, their client will have an APAC geo-ip. In an unrestricted deployment where the Teams client can use high ports to connect to media, the Teams client will connect directly to the media processor closest to the conferencing server. In the scenario above, this is great news for APAC users, because they are not using transport relays and therefore, are able to connect directly to the B2BUA (MP).

However, where this falls apart is when APAC users join a conference that was started by someone in EMEA, or NORAM. In the unrestricted deployment, media will be connected over the internet between the corporate APAC Internet IP and the  Media Processor in EMEA for instance. This opens up lots of potential for media issues traversing unmanaged internet routers and links.

In a restricted deployment, the Teams client would be blocked from connecting to high ports, instead being allowed only to establish media using Transport Relays. This is the current recommended deployment model from Microsoft and their Office 365 IP and URL ranges (Rule ID 11) only recommends UDP is open on 3478-3481. When this is enforced, the Teams client must connect to a transport relay to proxy its media to either the media processor, or to the SBC in the case of a PSTN call.

This is where the potential issue lies. If we have an APAC hosted conference, then in this mode according to the slide at the top of this page, the APAC users would relay their media by via a server in EMEA which would then relay that to the media processor in APAC. Not an ideal media route and we start to have conflict between an organisation that has stricter controls on outbound connections and the technology we are trying to implement.

Before we conclude this scenario, let’s now understand how PSTN calls behave in the same situation.

In a non-media bypass scenario and in an unrestricted deployment, the Teams client will connect to the Media Processor that is closest to the terminating SBC and not to the client. In APAC, it is likely that the SBC will be located in the same region as the APAC user, again this appears optimised.

However, if the APAC user is making an international call, and the organisation has deployed least cost routing, regulation permitting, international calls would be placed using SBCs in distant regions. In the unrestricted model, the APAC Teams client would connect to the Media Processor in EMEA for European international calls and NORAM for North American Calls etc. Similar to the way that conferencing works.

In a restricted deployment where transport relays are enforced, or media bypass has been enabled on the SBC, the above slide suggests that media would be relayed from APAC to EMEA and back to APAC for PSTN calls if media bypass was not possible.

Putting this to the test. I deployed a virtual machine in an AWS datacenter in Singapore. I wanted to be sure to be using a network that was not owned by Microsoft and conducted several tests.

The first test was a PSTN call to an international number based in EMEA with no restrictions. The below is a trace route of the media flow.

We can see that media is connected between the APAC client and the Media Processor on high ports. When IP tracing the IP 52.122.162.21 it returns a location of Dublin, Ireland.

So as expected, the Media Processor closest to the SBC was selected and the APAC client uses the internet to transport media from the client edge to the Media Processor in Ireland.

Now the same scenario, but with high ports blocked and the client forced to use transport relays. If the slide above is correct, the IP of the transport relay should also return either an EMEA, or US geo-ip.

Performing an IP trace on 52.114.13.37 resolves a location of Singapore!!

This seems to discredit the interpretation of the slide that caused the debate, but then neither of us attended it and we’re probably missing a lot of context. The reality is that the IP address is just the Azure Edge IP that the client connects to. The actual server can be anywhere inside Azure. We just don’t know and neither should be be concerned about it. The point is that media path is optimised. What happens inside Azure is outside your control and if there were problems, you’re backed by a financial SLA by Microsoft.

The same experience is found for meetings as well during the tests. For EMEA conferences, APAC users in a restricted deployment connected media via the Singapore relay server and EMEA users connected to an EMEA transport relay for an APAC conference.

Why is this better or worse than just allowing unrestricted connectivity to Microsoft?

The key difference in all scenarios is that a transport relay is selected based on the connecting client’s public IP address and not the closest media processor to the termination point (conference mcu or sbc). This ultimately means that the media path between the connecting client and Microsoft Azure Edge is always optimal and shortest possible. The relay server will then relay that media to the conference server, or SBC using the Azure global network as opposed to the wild internet, which in most circumstances will offer a greater experience to everyone in the meeting or call.

It is also highly recommended to enforce relay if you’re deploying hosted Direct Routing as with or without media bypass you are always going to ensure that the closest relay point to the client / site is chosen and you leverage the Azure network to optimise the media between the relay and the hosted SBC.

Example:

APAC Client —> Internet —> Azure APAC —> APAC Transport Relay —> EMEA Media Processor —> EMEA Azure —> Internet —> Hosted SBC —> PSTN

as opposed to

APAC Client —> Internet ——————————> Azure EMEA —-> EMEA Media Processor —-> Internet —-> Hosted SBC —> PSTN

In summary, the transport relay may or may not be in the EU or US as per the slide. The important design factor here is that by enforcing relay, you are optimising your media paths to take the shortest hop across the internet to the Microsoft network as possible in all scenarios and that is a good thing!

 

 

Microsoft Teams Meet Now Is Here

Microsoft have released another feature to Microsoft Teams that has been available in Skype for Business for many years, Meet Now!

Meet Now is a feature that allows you to start a meeting on-demand, without having to schedule it in advance. In Skype for Business, personally I never really used this feature, simply because I could start a conversation with someone, and then add another person into that conversation using drag and drop, thus making it a conference, or meeting.

However, with Teams, perhaps this feature could be more needed than it ever was in Skype for Business. Teams lacks the ability to drag and drop people into on going conversations that would then make a meeting. Instead it is invite based.

The biggest use case I can see for this feature is from Teams Meeting Room devices, or Teams conference phones where you’re in a room discussing a topic and need external support from multiple parties. Here, Meet Now is a significant and welcome feature!

With a Teams meeting, the organiser would then have the meeting controls to dial people in to the meeting from the PSTN (subject to audio conferencing license, or calling plan), as well as also being able to ping a meeting join link to others via chat to say “Join now”.

There are situations however, where you need to be selective in this features use. If all participants in the meeting are already using Teams for meetings, or Teams Only mode, then when you invite them to your meeting, they will join via the toast notification they’ll receive. But, if a participant is using Skype for Business then meet now is not going to currently work for them.

This is due to the current fact that currently, Skype for Business clients are not compatible clients to connect to a Teams meeting. When invited, the Skype for Business user may get an invite, and if they click accept, meeting join will fail. They have no other means to join that conference, because they don’t know the meeting join link. In most cases, Teams would simply let you know that it could not invite this person.

This leaves you as an organiser with three options to choose from

  1. Do you try and dial the Skype for Business user into the meeting using their PSTN phone number? This could be a disadvantage, especially if you are screen sharing, or expecting the Skype user to contribute
  2. Do you copy the meeting join information to your clipboard, open a separate chat to the Skype user and paste the join Information? This will allow the Skype user to join via the web client
  3. Should you have used scheduled meetings instead of Meet Now? and simply carry on with the meeting without the Skype person?

As more and more organisations start to move to Teams, this feature will grow. For now at least, in my opinion, you should be selective of its use.

%d bloggers like this: