Home » Articles posted by Mark Vale

Author Archives: Mark Vale

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


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



    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


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



    Write-Host "Finished Tranching Users" -ForegroundColor Green 

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


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 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 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.


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.

UC Summit 2020 by UC Today

Yesterday I had the pleasure of speaking with Rob Scott, Chief Publisher of UC Today, an online magazine and news website that focuses on the Unified Communications Industry about UC Summit.

UC Summit is a new online and virtual conference that UC Today are organising which is targeting technology buyers from end user customer organisations.

The aim of UC Summit is to provide a free, on-demand virtual expo where vendors from all over the UC technosphere will converge to pitch their solution to a captive audience, completely online in a video on-demand conference.

UC Summit will also be showcasing advocates from all over the UC industry, including Microsoft MVPs and community experts to deliver high value, technical content in sessions that compliment their technology expertise.

We are pleased to announce that the Commsverse team will be presenting at UC Summit on Microsoft Teams. More information will be posted later. But we are hugely excited by this opportunity and that another great UC conference is emerging which shows the demand and excitement around modern unified communications.

UC Summit will begin on the 20th January 2020. If you’d like to join in with all the free learning, please visit www.ucsummit.com today and register for your pass today!

Success! You're on the list.
%d bloggers like this: