[DE] In diesem Beitrag geht es um ein neues Features für Microsoft Teams, welches im September 2019 ausgerollt wird. Microsoft Teams erhält ab diesem Monat ein sehnsüchtig erwartetes Feature, den “Secondary Ringer”, oder “Sekundärer Rufton” (DE).
Der “Sekundäre Rufton” erlaubt das Klingeln bei einem Anruf auf zwei Geräten. Das ist sehr praktisch, wenn ich das Headset auf dem Schreibtisch liegen habe und mich jemand anruft. So kann ich einstellen, dass es sowohl auf meinem Headset und auf dem Lautsprecher meines PCs klingelt.
Bislang sehe ich bei abgesetztem Headset nur eine visuelle Benachrichtigung für eingehende Anrufe. Somit kommt mit dem “Sekundären Rufton” ein zweites auswählbares Ausgabegerät hinzu.
Quelle: Screenshot Teams Einstellungen \ Geräte \ Sekundärer RuftonSource: Microsoft Teams – Secondary Ringer [Microsoft 365 roadmap update item 51089]
In this post I describe where you can start to get more details (figures!) about the Microsoft (Office) 365 adoption at your company.
There are many different ways to gain insights. But if you rolled out different Office 365 services at your company there’s already quite a lot of valuable data. Where? Well, you know all the admin dashboards in the different Office 365 admin centers, right? So, these dashboards are good start to see what’s adopted but what about a more holistic view?
Of course you, could build a new dashboard in PowerBI by attaching different data sources, Graph API etc. But why not utilizing available tools? Is there any?
Microsoft 365 usage analytics
Yes, there is and it delivers you the following information:
Adoption overview report
Product usage report
Storage used report
Communication report
Collaboration report
Office activation report
Access from anywhere report
Individual service usage reports
Individual service user activity reports
What do have to do for this?
There is not much to do.
Enable Microsoft 365 usage analytics[see link at the bottom]
Navigate and utilize the reports in Microsoft 365 usage analytics[see link at the bottom]
Read the reports
Apply measures to drive adoption in the spaces where it is required
Review monthly
Go back to 3. [infinite loop / continuous [adoption] improvement process –> learning never ends ;-)]
Conclusion, opinion and summary
Before you start to build your own reports you might want to start with what’s available at your fingertips! I had the chance to test and it’s ready within minutes. So, you can view report data. What you finally need to do is to check what information you receive and conclude your next steps to drive adoption in weak areas by adequate measures, e.g. awareness campaign, training/education or other means of communications to drive adoption of Office 365 services within your company (as needed).
Microsoft announced that Yammer and Office profiles will be merged. Until today a user gets provisioned and logs into Yammer. This triggers the “creation” of its Yammer profile which is synced from the user’s Office profile. However, if a user changes values of his/her Yammer profile it is overwritten by the next Office profile sync to Yammer in case the Office profile was changed.
Well, it means that the users’ profiles become one and will based of the Office profile. The Office profile becomes the “master” and sole profile.
So, the profile button in Yammer will disappear soon and than every profile value is based on the Office profile. Single profile instead.
How can you manage the merged Yammer/Office profiles of users?
Due to the fact that there will be only one profile left you’ll need to manage only the users’ Office profiles. Either a user can manage this within set limits on the Office 365 Delve profile page or by contacting your Office 365 administrator and support.
Conclusion, opinion and summary
To sum it up, you’ll manage user attributes via Active Directory. Either in you onpremise AD which is synced via AAD Connect to Azure AD and Office 365. Or in case you are cloud-native user attributes from Azure AD are used.
Depending on how much “self-serving” you allow users could make changes to the profile by using the Delve profile (page).
In a previous post I wrote about how you can migrate Microsoft Teams from one (source) Office 365 tenant to another (target) Office 365 tenant by using third party (3P) tools to ease and automate the migration process. BitTitan is one of the tools which can be used.
BitTitan published a White Paper regarding “Top Migration Considerations for Cross-Tenant Teams Migrations” which you can request and download to avoid typical pitfalls and get awareness on what limitations there might be. You can find the link to request the download of the White Paper at the bottom of this post.
In this post I like to highlight a SIP Trunk Provider Evaluation by the Eastern Management Group. I came across a nice article regarding the evaluation of (some) SIP Trunk Providers which was carried out by the Eastern Management Group.
In this study 29 SIP Trunk Providers were evaluated based on a survey. More than 3.000 IT managers were asked. As far as I could read the focus resides primarily on SIP Trunk Providers in the US and such with global reach.
In case your are about to plan your migration from ISDN to ALL-IP/SIP Trunks or you are considering to consolidate your SIP Trunk connectivity this study might provide you some insights and metrics to get to a decision on which SIP Trunk (Provider) to choose.
However, 29 SIP Trunk Providers are just a few. Depending on where you need a SIP Trunk you might need to research which are available at a certain world region, country and local area. As always on the market there are small and large SIP Trunk providers offering a different feature set for the SIP Trunk Services.
I recommend to take a closer look to what’s offered in detail and what SIP Trunk “architectures” are serviced, e.g. dedicated (physical) link vs. logical link (via existing Internet/MPLS connectivity), encrypted traffic support, clip no screening support, SBC support/compatibility (are there recommended SBCs/IP-PBX by the respective provider?), call authentication/authorization requirements…
In this post I like to quickly inform about the availability of a new Microsoft cloud data center region in Germany. I was about to deploy a new cloud-based session border controller (SBC) and saw that the region “Deutschland, Westen-Mitte” is available on Azure.
Source: Screenshot showing the Azure Portal https://portal.azure.com and creation of a template-based Azure resource group
This post is about LBR – a planned feature – for calling or telephony with Microsoft Teams which might be released and available in Q4 2019.
Location Based Routing (LBR) allows basically to route and control voice calls depending on the location. In my opinion, this is very useful for deployments with roaming users especially regarding emergency calls or call restrictions.
There are some reasons to use LBR for managing and controlling your voice call flows:
Egress calls: Enforce outgoing calls to egress via local PSTN gateway, prevent PSTN toll bypass
Ingress calls: Prevent incoming PSTN calls via a NON-local PSTN gateway
Undefined location: Prevent PSTN calls to and from users in undefined locations
Let me describe a small (fictive) scenario where LBR could help: Erik works for a special machinery engineering company. Still, the company has decentralized PSTN connectivity. Each location and site has a dedicated PSTN link and SBC. Erik is a Teams user including calling capabilities. He’s located and “homed” in Stuttgart, Germany.
Erik travels to another company site. Erik needs to place an (emergency) call while being in another office in Berlin, Germany.
By default this (emergency) call would be routed via Stuttgart to the local emergency service answering point. However, that would be a very bad routing and in case of an emergency were every second counts this is not acceptable.It would be ok if Erik was really in Stuttgart and not Berlin.
By using LBR this (emergency) call would be routed locally and breakout to PSTN via the SBC in Berlin and land at the emergency service answering point in Berlin instead of Stuttgart. If Erik would have to call for emergency in the company site in Hamburg, Germany the call would be routed locally and breakout to PSTN via the SBC in Hamburg as well.
How does LBR work?
Usually you’ll have to define and save some of your network parameters (IP address ranges per site …) to define sites in the phone system. Afterwards you’ll have to define (LBR) voice routing for each site (e.g. LBR policies, voice route/s, policies …) so that calls are routed according to the location requirements and its configuration.
Conclusion, opinion and summary
This is subject to change or might be implemented different to what’s described above. This is just my personal assumption how it might look like. I’ve just assumed that it might be like that because of the approach which can be found in Skype for Business Server.
