Being a Skype and Teams consultant I seem to spend my life talking about why it is important to implement Quality of Service even for cloud systems routed over the internet.
My mantra is simple, if you can do it and it’s going to make an improvement no matter how little the perception may be, then it’s probably better to do it.
Specifically with cloud there is always an argument that QoS implementation is not worth the effort because of the middle carrying network that is the internet. As we all know, the internet cannot perform QoS. So what is the point?
Firstly, this is a wrong assumption, that there is no point. The second incorrect assumption is that Quality of Service is only possible when you’ve implemented Office 365 Express Route.
The reason for my stance on this matter is because I look for different types of communication between different peers. I look at the intended media route over your network and calculate that a certain percentage of media will always be local to your network. With the implementation of Direct Routing, this percentage increases quite significantly.
As a result of these media paths remaining on your controlled network, you can apply traffic treatment policies to prioritise important data packets end to end and both ways. Your network may be geographically large with different types of inter site connections such as MPLS, Point to Point, or managed ethernet. As a result implementing QoS is no small feat. And for this reason alone I get the most push back on why QoS cannot be implemented at a customer. It’s not the technology, its either effort based, or the fact that the networks team have historically used other treatment methods and they don’t want to pivot away from that.
Once we get over the first hurdle on agreeing that it makes sense to deploy QoS for Microsoft Teams because 70% of the media is going to go end to end over the customer LAN, we then start talking about how this can be implemented.
First off LAN and WAN QoS are fundamentally the same, just different networks. And the endpoint for each of those networks may treat QoS differently. The most important thing from my perspective is that the traffic is treated in exactly the same way over each network regardless. Some WAN networks use accelerators and application inspection to classify data packets based on what the device has determined to be the application e.g. Microsoft Teams. The problem is that in order for these devices to determine the application type, they must inspect the data packet. As Teams transmits media in Secure Real Time Media (SRTP) the data payload is encapsulated in an encrypted packet. This means the device has to decrypt the data packet, inspect it, decide what to do with it and then re-encrypt it and send it on. This requires CPU and memory, but more importantly for us, increases latency and packet reordering and jitter. All bad where media quality is concerned. It is for this reason Microsoft do not support deep packet inspection for Microsoft Teams payloads.
The other challenge we have is WAN acceleration and packet reshaping. Network engineers will want to do this because it means that they can squash more data through the available bandwidth that otherwise would be possible. WAN accelerators basically compress the data packet and then send over the network. The problem with compression is that the data packet has already been compressed by the voice codec used in the SDP negotiation between endpoints, for the WAN to compress the packet again, you have double compression. This leads to data bits being lost and entire packets resulting is poor media quality. Again Microsoft do not support or recommend this for Microsoft Teams.
This leaves us with what needs to be done. Microsoft support policy based QoS using DSCP. Nothing new there. The LAN needs to be configured to transmit packets based on their DSCP classification, as does the WAN. Do not try to re-mark data packets between networks, for instance configuring EF for audio on the LAN but AF34 over the WAN. If you do that you are not gaining anything and contradicting the purpose of Quality of Service. Pick the classification and trust the packet end to end.
Microsoft publish their QoS recommended classifications for media types. For Teams, this is EF (46) for audio, AF41 (34) video and AF21 (18) for app sharing. It is an incorrect assumption that you must assign these values to Teams traffic for Quality of Service.
Yes, it would be nice to have, but the reality is often very different. Most enterprises have very strict controls over what type of application can use EF. For instance the most common entry criteria is that the application must have call admission control. Microsoft Teams does not have this ability.
EF is an expensive classification for them in the way that it operates as well as if they have a managed WAN then they are probably paying for a preset static amount of EF bandwidth. This bandwidth is precious to them as other business critical applications could be using this priortisation. If you go ahead and deploy Teams on EF then you could bring down several systems as a result.
The actual reality is that you are aiming for the best classification you can get in the AF band. You want the top classification that no other application is using so the data packet you are transmitting gets the best treatment and prioritisation possible. The net result is the almost the same experience as EF. In some ways it is better because like my last point around EF is expensive, by classifying in AF means you can use the general bandwidth available which would be much higher to your heart is content and get full prioritisation over it for no additional cost to your customer. Its a win win compromise.
Once you have this implemented at the network level, you need some way to mark the data packets accordingly. You do this today using group policy.
Don’t forget that if you are wanting to implement QoS then do it properly, it doesn’t just end with this GPO for Teams.exe. Where will these users be calling? Desk phones? Direct Routing SBCs?
You’ll need to ensure that these devices are configured themselves for QoS otherwise you are only getting QoS on the sending stream from the Teams client and potentially none on the receiving stream. The end result is 50% of the possible experience to each of the users.
You can test whether data packets are being correctly marked by using Wireshark to capture the data packets. You are looking for a UDP stream to the target endpoint on the source port within the media range
But remember, any packet that is destined to be transmitted over the internet will only be priortised on your network, up to your boundary. After that QoS does not come into play and the packet is sent like any other data packet.
The same is said from any inbound data packets from the internet. For instance, you receive a pstn call from Microsoft Phone System. The packet is being transmitted from Microsoft via the internet to your network. It is not prioritised and similarly any markings that were stamped by Microsoft’s media network for DSCP values are stripped by the internet routers. This means the inbound stream has a DSCP value of 0
Therefore, you are effectively only getting 25% of the total streams treated for Quality of Service i.e. Outbound stream client -> your boundary.
Network inefficiencies cannot be hidden from media traffic
If you’re going 100% cloud for calling and meetings, then you really should consider your internet breakout design, capacity and performance. It may be more cost effective to implement local breakouts at sites, rather than purchasing Express Route. But one thing is for sure, in an enterprise organisation, if you want enterprise grade voice quality then you need to guarantee your media quality end to end. Otherwise, there will be times where there are degraded experiences.
Lately, Microsoft have been rolling out meeting settings to the Teams admin portal and one of those settings is an enable Quality of Service markings for real time media.
You would assume that this setting would mark the traffic coming out of the Microsoft network and replace the need for group policy based QoS?
At the time of writing this appears not the case. Perhaps this feature has not yet made it to the client. The setting certainly suggests it should.
However, this setting will presumably apply the recommended DSCP markings to data packets and that could be in breach of your design. In this case, you would still rely on the GPO method.
From the testing I have done at the moment this setting does not actually mark any inbound or outbound data packet to the client.
In any case, when this feature is fully working it still is not going to solve your problems without you putting the effort in to support it. While you can be pretty consistent and controlled for LAN to LAN communication, you need to remember anything going to the cloud or coming from the cloud is not going to benefit from QoS, unless you have Express Route.
Deciding whether you need that or not depends on your usage prediction.
In summary, Quality of Service is still an important element of deploying a cloud voice solution, but you must understand your usage profile to weigh up the reward vs effort to implement. If you’re going 100% cloud then QoS will only play a meaningful role in internal P2P comms. You must focus your efforts in ensuring there is sufficient capacity and performance in your external network to support a good standard of quality albeit uncontrolled. If you want the best experience in this scenario, then Express Route may be a consideration for you, but not necessarily mandatory.
Mark is an Independent Microsoft Teams Consultant with over 15 years experience in Microsoft Technology. Mark is the founder of Commsverse, a dedicated Microsoft Teams conference and former MVP. You can follow him on twitter @UnifiedVale
Today I was doing some prep work for one of my customers who are going to be implementing Direct Routing in the coming weeks. It is the first opportunity that I have had to really put Direct Routing through its paces.
I am fortunate that my lab has a SIP trunk provided by Pure-IP (www.pure-ip.com) so I am able to test real world scenarios as if I am deploying this for my customer.
In my lab I have a Sonus / Ribbon SBC 1000 running Edge version 7.0.2 firmware. This is the base firmware you need in order to configure Direct Routing to a supported level by Ribbon.
Configuring the Pure-IP trunk was simple enough and the guys and girls over there are really an awesome bunch, provisioning me my service within only a few hours. They also provide certified Skype for Business and Microsoft Teams SIP trunking as well as Microsoft Teams Direct Routing as a Service. So you can be sure to receive a compatible service from them. Go and check them out.
Initial testing of the solution was positive I could place inbound and outbound calls without any issues. I even configured extension dialing between Teams and a legacy PBX using the SBC and all worked fine.
However, call transfer from a Teams user to any destination would not work.
When tracing the SBC logs I could see the REFER being sent from Microsoft Teams, but the SBC could not understand what to do with it. In my case it was trying to send the REFER to Pure-IP to handle instead of routing it back to Microsoft Teams.
I spent way too much time in message manipulation rules to try and figure out what needed to be modified and then when I thought all hope was lost I tried something with the thought of “I wonder what this does?”
Turns out that setting the Interop Mode to Office 365 on the SIP Signalling Group to Microsoft Teams makes Transfer work fine
In other testing scenarios i found that I can transfer to the following destinations
- I can transfer a PSTN to Teams call to another Teams user who is also configured for Direct Routing
- I can transfer a PSTN to Teams call to another Teams user who is just configured for Calling Plans and NO Direct Routing
- I can transfer a PSTN to Teams call to another PSTN number
- I can transfer a Teams to Teams call to a PSTN number with a caveat of if the PSTN endpoint rejects the call, the transferee will not be notified and the call will remain on hold until manually disconnected by the transferer.
- If I transfer a PSTN call to another user who is using Skype for Business, then the call is automatically forwarded to their voicemail. It will not ring the endpoint
I’ve bolded the last point because I find this a little perplexing. Firstly I understand that Microsoft do not want to roll Direct Routing to Skype for Business Online because that is not the strategic direction for the cloud. But that is no excuse for interop between cloud systems they own in my opinion.
Many organizations who use SfB Online today will not just big bang migrate to Teams over a night and therefore there are going to be situations where migrated users are going to need to transfer a caller to a user that is potentially still on Skype for Business Online.
By not providing this interop is actually going to make migrations away from Skype for Business Online to Microsoft Teams a lot more complex from a voice perspective than I think its been given credit for.
I hope Microsoft realise this and are able to do something about this. But for now islands will be islands I suppose.
Mark is an Independent Microsoft Teams Consultant with over 15 years experience in Microsoft Technology. Mark is the founder of Commsverse, a dedicated Microsoft Teams conference and former MVP. You can follow him on twitter @UnifiedVale
Microsoft Teams is really taking off now with organizations seriously considering how they can best take advantage of the technology offered by this product.
There is certainly a lot of activity around meeting experiences with various vendors coming to trade shows with their shiny new device for Teams meetings. But being a techie it is easy to get carried away with the technology rather than the functional use of it. That can lead to bad purchases and the technology not meeting the basic business requirements.
It is important that you first define your requirements before going to market and getting test units and involving vendors in pre-sales because you’ll find yourself getting inadvertently led towards a product(s) that might not be what you need.
Starting from the beginning, you need to perform an audit of your meeting rooms. Even if you think you know them, do it again. Yes this may be a large task with seemingly little in return on effort, but trust me you will learn a lot about how your users have been using meeting rooms. This seems a simple task, but the biggest issue you are going to face is gaining access to a room during business hours. After all you cannot walk into the senior executives financial results meeting and whip out your tape measure! But persevere because it is worth it!
As you walk around, you need to measure because you will need to measure the dimensions of the room. This is important because you need to consider how the room may be used. Yes the room may have 4 seats, but how many times have you gone to a meeting in a room too small to accommodate the attendees and it’s standing room only? You need to account for the fact that the room maybe over subscribed, but from a user’s perspective they don’t understand and just expect perfect experience regardless.
You also need to consider what is in the room. A bare room with a table and chairs is going to be problematic where voice quality is concerned. What will happen is that your voice will bounce of all the walls and the microphone will pick that up. There will be a couple of milliseconds of delay between the microphone picking up your actual voice and your reflected voice. The end result is that the people on the other end of the line are going to hear an echo or hollow sound and this can be very distracting for them.
In order to reduce unwanted echo you need to consider the furniture in the room. A well insulated room or rooms with solid walls are more prone to voice reflection than rooms with hollow walls because with hollow walls a portion of sound can disperse through the wall, whereas brick is much denser and is a natural reflector. To combat this consider putting in some plants or other ornaments that can be used to absorb / disperse sound before it is reflected. Ferns are a good plant because they are dense and provide lots of angles to reflect sound back on different vectors. The microphone is similar to radar in that in order to get a response the reflection must travel back on the same vector the sound was transmitted on. If this is disrupted then the microphone will find it harder to pick up the reflected sound. Think of your fern tree as Audio Conferencing Stealth technology! Of course, plants and ornaments are good absorbers, but you can do a little bit with the dedicated furniture as well, using cushioned chairs combined with how you position those chairs for people to sit at can play an important role in reducing echo.
As you go through the audit, you will notice that some devices that you have provided are disconnected, or appear that they haven’t been used in anger for some time. Obviously a key indicator that devices aren’t used are if they are disconnected on the floor, missing or shoved to once side in a pile of mess. If this is the case, then you may want to evaluate if it is worth the investment to replace that room with a Teams device or not. How you determine this is something that you will need to come up with, but perhaps surveying the users in the immediate office on their usage and if they are happy is a good start.
Now that you have completed your audit and you’ve gathered some intelligence on how the rooms are being actively used you need to define your upgrade strategy.
Are you replacing like for like as in the room has a device so therefore it is getting a new device. Or are you going to be more conservative?
To help you need to consider how your user’s habits will change from traditional use of a VoIP system to a unified communication system where their device is the phone and conferencing equipment. You will find that many 3 or 4 person conferences that used to take place in a meeting huddle room for instance will be reduce to almost zero in favour of “at-desk” conferencing where these users remain at their desks and use Teams meetings with their device.
You will also see an increase of unlikely meeting locations due to the fact that Microsoft Teams gives the user’s far more mobility, sitting on steps, grabbing a coffee in the canteen. sitting on the grass outside the office, standing in stairwells etc. you name it, you will find a person there at one stage on a Teams call. A portion of these conversations happening in transient and mobile space would have traditionally been room based conversations.
It could be that you decide small meeting rooms do not get a device, and simply provide users with the appropriate peripheral. It could be that you don’t provide anything at all and classify these rooms as physical meeting presence capability only. Or if you do need to provide a device then choose something that is budget friendly and adequate for the room.
Room types differ from customer to customer, site to site. Typically though you’ll classify them into one of 5 categories
- Think Tank
- Board Room
- Executive Video Conferencing Suite
A pod is a classification we can give to communal areas where there may be screened seating with a desk. Pods typically accommodate 1 to 4 people. These meeting areas are usually in public places and offer limited privacy. As a result, these areas or logical rooms would not receive any telephony or meeting capability. They may include a TV screen for connectivity to a user’s laptop but generally wouldn’t be used for online meeting hosting. Another point to note is that due to no physical boundary like a wall, then it would be disrespectful to other workers in the area for a conference to be in progress in a booth next to them.
If a pod was used as a location to join a conference, then private peripherals (headset) should be used and encouraged.
Huddle rooms are your typical small meeting rooms that contain usually a circular or square desk with limited seating of between 3 and 6 people. The room dimensions may be small some, only 3 x 3m. These rooms are typically used for short duration focused meetings where physical participation is small but the online audience may be of any size.
There are many devices for this type of room, both audio and video devices. You need to decide what service you want to offer as a standard and if any location warrants an upgraded service e.g. huddle rooms close to executive offices for instance will probably need audio and video capability, while standard rooms may just need audio, or in some cases nothing at all.
Whatever device you choose, whether it be a conference device, a phone with speaker or a huddle integrated video system there is one thing that you need to pay particular attention to and that is the microphone capability of the devices you are choosing as a standard. It is often a mistake to assume any device will do but taking the time to understand microphone pickup and operation fields will help you choose the best device for the room and achieve optimum quality of experience.
In this example of a huddle room, we have a circular desk with a device located in the center. This device has an omnidirectional microphone with a 3m maximum pickup range. This microphone is perfect for this type of room because it has complete 360 degree range and that means anyone talking around the table will be equally heard. For huddle rooms seating 5 or 6 people in this configuration a cardioid microphone would not be suitable. The downside of an omnidirectional microphone is because it can pickup sound 3m away in any direction, it is not great at filtering out unwanted sound and this is why it is unsuitable for rooms larger than the huddle classification.
Think Tank is a classification that I give towards meeting rooms that accommodate 10-15 people and is a medium sized room somewhere between 7 x 5 meters. In this room classification we are more likely to find rectangular desking with a TV or smart room device installed at the head of the table. Again thinking about the microphone capability, the configuration would look something like this
For this style of room an omnindirectional microphone would pick up far too much background noise. More people = more sound intentional or otherwise. Also Omnidirectional microphones have very limited range because typically the device can only carry one. Therefore the range is symmetric from that device. Instead we need cardioid microphones. These provide 180 degrees of coverage focused in a particular direction. These microphones allow the device to target specific areas of the room while reducing the background noise from other angles. It also means that the device can carry more than one microphone. Some devices have two, but the common denominator is three cardioid microphones positioned in a triangle for maximum coverage.
Microphones in these devices vary in technology, but the best ones use all three microphones to best represent the sound someone is making. One microphone will be active as the device intelligently works out the source direction where the sound is coming from and shuts off the other two microphones and they place a part in noise cancellation. By having three microphones, these devices can pickup sound from between 4 and 6m in each direction from the device which make it capable of supporting this type of room.
Board rooms are large meeting rooms that can contain anywhere from 15 to 25 people. Typically a long rectangular desk. These rooms are just a bigger version of the think tank rooms so we need to look at extending the microphone capabilities.
In this case we would look at the same or similar device to the one deployed to the Think Tank rooms, but this device should support additional microphones to extend the reach of sound pickup capability. In the above picture we have a central device with 3 cardioid microphones and an extension microphone either side of it. These provide extended coverage and can often increase the reach of the device from 6m to 18m end to end in any direction.
Executive Video Conferencing Suites
These you don’t come across unless you work for a very large organization. These are dedicated rooms that have integrated video and sound capabilities. By this they will have multiple displays, a powerful HD camera and ceiling microphone booms or dedicated microphones per seat
These suites require dedicated equipment. Typically you would involve a vendor to install and then you would provide integration capability to Microsoft Teams through a video interop solution.
There are some curve balls as well. One of the biggest that challenge any refresh program and device selection is the layout of the room. Up to now we have spoken about one dimensional room configurations. They are easy to source devices for. However, for room layouts that are in an open square or U shaped desking, these configurations are a nightmare for conference device selection. Both these configurations by design almost demand a ceiling mounted microphone solution because there is no optimum placement of a ground device.
You could experiment with the configurations available to you with devices that support multiple microphones but this would be trial and error to some degree.
The best idea I can give you is to challenge the room layout to meet the capabilities of the device being installed. If this is not possible, then perhaps you evaluate the effectiveness of the device in that room vs the investment costs, therefore, exclude from any telephony requirement. In most cases layouts in open square or U shaped are geared towards meetings that are physical and have very little to no online requirement, The shape of the room is telling you that the people that use this tend to work together within the same room rather than talking to a bunch of people online.
I hope that this post helps you decide what devices you need and remember tech is brilliant, only when it is fit for purpose, otherwise it is just an expensive ornament.
Mark is an Independent Microsoft Teams Consultant with over 15 years experience in Microsoft Technology. Mark is the founder of Commsverse, a dedicated Microsoft Teams conference and former MVP. You can follow him on twitter @UnifiedVale
By default users added to a Microsoft Teams Team that are external users i.e. guest users have a reduced feature capability set compared to an internal user.
For instance, in peer to peer conversations a guest user can perform a private group chat, but audio and video functionality is not allowed due to license restriction
In a Team the guest user has the ability to chat and collaborate with internal users within the Team and join a Teams Team Meeting with audio and video capability. However, they are not allowed to create a meet now by default.
If you want your guest users to be able to create Teams Team Meetings (Meet Now) then you can do this at tenant level by executing the following PowerShell
Set-CsTeamsGuestMeetingConfiguration -AllowMeetNow $true
Now Guest users will be able to create meet now meetings within a Team
If you want guest users to be able to use audio and video in private chats and private group chats then execute the following PowerShell
Set-CsTeamsGuestCallingConfiguration -AllowPrivateCalling $true
After this setting has applied, Private Calling will be allowed.
Microsoft announced at Inspire this week the release of message translation of chat messages to the recipient’s native tongue.
In order to use this feature, administrators must enable this on your tenant. You can do this using the Messaging Policy. As yet this option does not appear in the Teams Admin Portal, but you can use (SfBO) PowerShell to enable it.
In my example, I am turning this on for the global policy
Set-CsTeamsMessagingPolicy -Identity Global -AllowUserTranslation $true
The policy takes a few minutes to apply, users may be required to log out and back into Teams.Now when a user types in a message the recipients have the option to translate. You can do this by clicking the elypsis on the message and clicking Translate Message
If the language is supported then the translation will work like so:
You’ll notice a little icon appear next to the time on a translated message. If you want to revert the translation, go to the elypsis again and click see original message
Teams automatically translates to the language set for the user in their Teams client. To change this go into the user settings and change the language as needed
Microsoft have released federation capabilities to Microsoft Teams and this has been rolling out to tenants over the world in the past few weeks.
This is a much anticipated feature and one of the most critical differentiators that turned cloud first companies to explore Skype for Business Online rather than Teams for their Unified Communications.
Now that federation is here companies can now consider Microsoft Teams as a viable alternative to Skype for Business Online, or can they?
I have to say I was excited when I heard it was coming, and being part of super TAP for Teams I was able to extensively test this feature out before it landed to TAP and now GA. However, the feature has disappointed me in some areas.
I’ll start with the positive, we can now chat to other Microsoft Teams users from other tenants without fudging it using guest access. We are able to chat, call and place video calls to each other. In the main the process is slick but there are some downfalls.
The two big features that are missing in my opinion are file sharing over federation and multi-party communication.
Currently I can file share, but I have to upload the file I want to share to my OneDrive, then generate a sharing link and then paste that into the chat window for the federated user to download. This only works of course if external sharing is enabled on One Drive for Business.
Perhaps the biggest limitation though is the inability to add more than one person to a federated chat. You only have the ability to perform federated P2P. This is the case if you’ve got a group chat in-progress with several internal users and you want to invite an external user in over federation, you cannot do this. The Teams client will not resolve the federated user’s address and you cannot search externally.
I have also experienced issues while trying to perform chat over federation to Skype for Business Server users. This is supported and you can do this, which is great. However, what I have discovered is that the partner who is an on-premises Skype for Business server user must have Skype for Business Hybrid set up with their tenant and synchronizing their AD Accounts via AzureAD Connect. If Hybrid is not setup, even if the Skype for Business server deployment is enabled for external federation, you as a Teams user, will not be able to communicate with them.
Here is an example of the message you’ll get when the partner has not configured hybrid
However, all is not lost. If the same Skype for Business user tries to send you and IM, you will receive that as a Missed Conversation Message in Outlook.
However, that person’s experience of contacting you is misleading because in Skype for Business you will appear as available due to unified presence, but when they try to IM you they get the following message
If you are a Skype for Business user and you get this experience, this is because the person you are trying to chat to is using Teams.
I have no doubt that federation capabilities will get better as time progresses. I just hope that Microsoft do not see this as a done deal and completed feature just yet. In order for organizations to move completely to Microsoft Teams, especially ones who rely on federated communication need the ability to seamlessly converse with organizations who are running on legacy communication solutions.
This is a quick post to cover an intermittent issue that you may come across when provisioning users in the cloud for Teams Enterprise Voice.
There have been several cases in recent weeks where I have created a user in Office 365, assigned them the appropriate licensing for Teams and Calling Plan and yet the calling app in Teams does not appear.
When you double check your work, you realise that you have done everything correctly, license is correct, you’ve assigned them a number in the SfBOnline control panel, the number is active and when you call it, the call is diverted to the users voicemail.
Even after waiting the obligatory 15 minutes for replication (incidentally I’ve noticed that the recommended wait time in the cloud has quietly increased to a recommended 30 minutes….) the calling app does not load. You try restarting your machine, reinstalling the Teams app, signing in on multiple devices and even the web client and the calling app still fails to load.
OK, you get the drift now of the problem.
The cause is that there appears to be some bug in the back end processes within Office 365 when it comes to provisioning a user’s cloud features. This isn’t limited to cloud only created accounts, but also AzureAD Connect synchronised accounts too. The bug is non discriminate, which means that there is nothing that you can do proactively to ensure that you don’t become affected by it. It is just luck of the draw.
The only way to resolve this is to raise a support ticket with Microsoft Office 365 support and request them to re-provision the user’s identity on their back end. This process takes 12 hours to complete, but can happen sooner. After 12 hours, sign back in with the problem account and the calling app should appear.
When a Team is created in Microsoft Teams, it creates a few object instances, one of them is a SharePoint Team site. This site is used to store all files, wiki’s and OneNote’s in a Team and Channel.
By default, every Microsoft Teams Team member will have “Member” rights to this SharePoint Team site.
Under normal conditions this is perfectly acceptable. However, when you add Guest users to your Microsoft Teams Team, they also get this permission.
In some conditions, you may want a Microsoft Teams Team whereby internal users should be able access and share documents within the Team to collaborate, but you may want to restrict a Guest user to just be able the chat and calling within the Team and protecting your internal data in a blanket approach.
When thinking about use cases, why would you want to do this? The answer is down to your own information security policies and review of the potential risk to data leakage within the Team. You still want them to communicate with your Team, but you don’t want them to collaborate or view documents that could potentially be sensitive to external access. Of course this can be achieved using modern management and using Azure Information Protection with Azure AD Rights Management but for companies adopting Teams today who are as a result going through massive change, sometimes it is hard to put faith into Technology the company doesn’t understand to a level they can confidently back. This may also be hampering the drive to enabling Teams for the organization at the speed the company needs.
The other use case is where guest users need to regularly chat with an internal Team. Federation today cannot be used to chat to more than one person, so multi-party chat with external users can only be done in this manner today. Again, this use case is tied to the overarching data access policy you may have to work with.
If this is the case, there is something you can do to allow Chat between external guests and internal users within a Team, but restrict access to the SharePoint Team site. This is a retrospective change, so before you can start you need to know the name of the Team you need to restrict.
Once this is known, open the SharePoint Teams Site in a browser. Modify the URL to access the hidden user permissions page
Next you will need to open the Team Members group
And delete the Office 365 Group name for the Team, in my case Test
Select the Group and from the actions menu, click to remove.
Now while in the same group add the security principle “Everyone except External Users”
Next go back to the user admin page. Now you want to explicitly remove the Office 365 group from the access permission list.
Now when the guest user tries to access the Files tab in the Team they now get this message
When trying to access the Wiki page
But you can still chat, call and see each other’s presence in the conversation tab because that is handled by Azure Data Tables / Cosmos DB and Exchange
When the internal user tries to share a file to you within the Team, the file is shared and the SharePoint link generated, but the guest user cannot access
and when accessed by the guest user
If the guest tries to share a file to the Team they get this error
Granted not the intended purpose of Teams but it provides some level of restriction for those who need it.
Yesterday (July 12th 2018) Microsoft announced the preview of Microsoft Teams Live Events. Live Events is the Microsoft Teams version of Skype Broadcast Meetings. But while Live Events has some similarities to Broadcast Meetings it is not a direct port over.
Live Events does use the same type of technology, i.e. Skype plus Azure Media Services, Azure Content Delivery Network but the experience of using the feature is much more baked into the Microsoft Teams client than it ever was with Skype for Business.
The limitations that existed with Broadcast Meetings in Skype, exist to some degree in Microsoft Teams, that being support for 10,000 attendees at any one time. Once you start a Live Event you cannot pause it and resume. And you can only share your screen or video or both to begin a Live Event. It seems that we cannot just do an audio only Live Event like a radio show for instance. That being said, the use case for audio only Live Events doesn’t really exist in this context. For those you would need a conferencing service that could support thousands of participants. A Gap in Microsoft Audio Conferencing that still exists today. Oh and by the way the delay between Broadcaster and Attendee is still around 20 seconds, no change there. It’ll never be real time, but then Live Events do not need to be real time, just almost live due to the way they are supposed to be used.
Now on to the MAHOOSIVE news, Live Events supports dial in conferencing participants and presenters!
So if you cannot join the live stream then you can dial in to listen. However, be aware, that if you cough, sneeze or do anything you’re not supposed to do while not being on mute, you will be heard by 10,000 people on the planet! This is a big win for Live Events, but it is not all gravy. While the supported limit for web joined attendees is 10,000 you are still limited (I believe) to a maximum of 80 dial in users as this comes under the limitations of Microsoft Teams meetings capabilities.
Scheduling a Live event is now super simple and can be done from the Teams client, rather than a separate portal. This is done by clicking on schedule a meeting and at the top where it says new meeting, this is now a drop down menu and you can select Live Event
You cannot schedule a Live Event from Outlook as yet.
When scheduling a Live Event, you now have options to select whether the meeting is closed as in restricted audience, open to organization, or public.
By default, the global policy is set to EveryoneInCompany. If you want to enable public join then use the command
Set-CsTeamsMeetingBroadcastPolicy -Identity Global -BroadcastAttendeeVisibilityMode Everyone
The ability to add an encoder via Microsoft Stream so that you can broadcast out to other platforms like Youtube is coming soon and under development
Live transcription services is supposed to make an appearance in Live Events, let’s hope it does, but this feature is not ready yet. However, if you want to make sure your tenant is ready for when it is released then run this command
Set-CsTeamsMeetingBroadcastPolicy -Identity Global -AllowBroadcastTranscription:$True
When you join as a producer, or presenter, you now have a new user experience in Teams. You get a staging area where you can build up your live scene before sending it live, so in a producer role you can work ahead of time to make sure that the scenes are set up and going to present what you expect before affecting the live stream.
You can choose from three scene layouts.
- Content only
- Video only
- Content and Video
The windows on the left of the above screenshot is the staging area where you can build those layouts. While the right is what is live right now.
In Skype Broadcast Meetings we were unable to screen share, only present a powerpoint or video. In Teams we can screen share so that is a HUGE improvement.
You’ll also notice that we have the ability to chat and create a meeting notes OneNote as a presenter. But sadly these don’t come through to the attendees. Being that the attendees can join using the Teams client or web client this seems a little bit of a mistake? I would have liked to have seen that feature there. As the product is in preview, maybe it will arrive before GA, or maybe we will just have to wait a little longer.
As an attendee I can join from the Teams client of the web client and the experience looks the same
Teams desktop client
I have the same controls as an attendee, catch-up, or watch the live stream. The media window is a nested Stream window, so I think the actual stream is being hosted on Microsoft Stream and the Teams client is just embedding a Stream player url into the client.
I have headed over to Microsoft Stream to see if the event can be found on there, but it doesn’t seem to be available to watch live on Stream yet.
I also like the mini call notification window you get as a presenter letting you know what is being shown live currently
Other cool feature is that you can get a live attendee list by looking at the meeting invite in your Teams client
Previously this information was only available post broadcast meeting. The report is still the same as what Skype used to produce though
Interestingly though, it does not show dial-in participants, but then it wouldn’t because the endpoints of a dialin user and a web joiner are completely different technologies.
Post Event, you can go to the meeting invite and click the download link on the video recording to open an azure blob where the MP4 is located and you can right click and save. Or you can click the meeting join button again to view it within the Teams client. Personally, I prefer the latter. However, it would be nice to have a function that says upload to stream so that I do not have to download the MP4 to my machine to upload it back to the cloud and re-encode it.
All in all this is a massive improvement on Broadcast meetings in Skype for Business.
Before using this in anger though, consider your network and audiences. As the stream that each attendee is essentially a video stream at a constant bitrate. This means that if you have 10,000 employees all watching the bonus announcement by your CEO at the same time, you’re going to have 10,000 streams coming over your internet connection. In order to mitigate this impact you could look at eCDN solutions for your network, like Kollective that use a Peer to Peer content sharing where the first client in the network to get a stream, then distributes that stream to other clients on the same network and as that builds, more clients become hosts for other slave machines. This means you reduce your internet reliance to deliver this event quite considerably.
Let’s keep an eye on what else comes to Live Events….
Now that Direct Routing has been released on General Availability worldwide for Microsoft Teams it is a very exciting time for Microsoft Cloud UC. Aside from the obvious benefits of Direct Routing such as migration path, investment stretching and interop with other systems, it does offer some interesting alternatives to Microsoft’s cloud native offering for those that perhaps have budget constraints.
When evaluating cloud licensing offerings for different use cases, one thing that stood out was the Common Area Phone license. It’s £6 per device plus a calling plan. Add this to the cost of a Skype for Business Online certified phone the cost per unit would be quite high for a device that wouldn’t be used that often. The most common Skype common area phone is the Polycom VVX 301 at £100-£120 per unit, add that to the licence cost £6 for the CAP SKU and £9 for the simplest calling plan licence and you have a monthly commitment of £15 per month or £180 per year. Now multiply that by a few hundred that you may have in your business, you realise that this is quite a substantial investment.
If your deploying Direct Routing then you have an alternative option.
Most SBCs that you’ll buy will come with the ability for local SIP registration subject to a nominal licence fee. You can use this feature for your common area phones. Instead of creating a common area phone account in Office 365 and consuming a licence, create a SIP account on the SBC for the device instead. This allows the phone to register directly to the SBC instead of Microsoft Phone System. The benefits of this mean that you now open yourself to the market of standardised SIP devices such as the SNOM D120 which is about £50 per device as you do not need certified Skype for Business or Teams devices for this.
There are some draw backs of course:
- Not being able to search the address book
- Not being able to see a user’s presence
- No HA or DR – SIP registration is to a single SBC only without failover
But when you look at the usage of a common area phone, in most cases, the person that is using it already knows the number they wish to dial. However, you can use Microsoft Phone System features to provide a directory service to these common area phones
Create an Organizational Auto Attendant in Office 365 that is configured to search the company directory by name and use voice recognition. Create a transformation rule on the SBC to transform a speed dial into the OrgAA phone number and route that through your existing Direct Routing SIP trunk to Microsoft. Then when a user needs to find someone, they can dial the speed dial from the common area phone, speak the name of the person they want to contact and the OrgAA will search the GAL and connect you to that person. No need to remember their number and it often takes the same amount of time, or less to do this than using the dialpad to search the GAL from a SfB phone.
Normal PSTN calls can be routed out of the SBC as normal.
But what if a Microsoft Teams user needs to dial a common area phone? Sometimes this is necessary depending on what you are using the CAP for. So, in order for them to be able to search the GAL for the CAP account you create a contact object in your AD and sync it to Office 365 with the phone number of the CAP. Then create a voice routing policy that routes calls to the SBC over the Direct SIP Trunk.
This solution means that you do not need to purchase the Common Area Phone Office 365 licence or a calling plan.