Category: Tech
Speaking at abtis IT Symposium 2019
Soon, I’ll get a chance to speak at the abtis IT Symposium in Pforzheim (11/10/2019). The event and speakers cover different topics about the “digital future readiness” (DE: “Bereit für die digitale Zukunft”).
I’ll talk about getting rid of legacy PBX infrastructure and legacy telephony services by embracing modern communication and collaboration with Microsoft Teams as an hub for modern teamwork. Telephony is just one of many features, although it’s very important for our daily business. My session “Vom Festnetztelefon zur integrierten Microsoft Telefonie” is about telephony with Microsoft Teams. I’ll describe which options you have to migrate your telephony workloads partially or completely to Teams and how it the user experience looks like.
Additional Ressources
SFB Online external access settings move to Teams Admin Center
I received a change notification via the Microsoft 365 Admin Center. It says that the Skype for Business Online external access settings are retired.
In other words external access will vanish in the SFBO Admin Center. So, the external access settings can only be managed within the Teams Admin Center or via PowerShell.
In the Teams Admin Center you find the external access settings as follows: Org-wide settings\External access”
Conclusion, opinion and summary
I welcome this change because if you modify external access settings in SFBO or Teams Admin Center it’s reflected, so there’s no need to have two settings pages in different Admin Centers plus PowerShell.
Additional resources
Microsoft Office 2013 Client Connectivity to Office 365 ends
In this post I like to inform you about and upcoming change regarding Office 365 client connectivity. Microsoft announced this already in the past and reminds admins via the Office 365 admin center about the upcoming change.
This might be subject to change anytime so please monitor your Office 365 message center to stay informed about this if it is relevant for your client infrastructure.
Based on the Office 365 ProPlus – Updates page (see link below)
Starting October 13, 2020, it will be necessary to have Office 365 ProPlus or Office perpetual in mainstream support to connect to Office 365 services.
What does this mean?
I.e. Office 2013 client connections to Office 365 (SharePoint Online, Exchange Online, OneDrive for Business …) will run out of support and won’t be supported after 13. October 2020. Office 2016/2019 connections are supported till October 2023. That’s why you should plan and migrate towards Office 365 Pro Plus/Office 2016/Office 2019 to be able keep your Office client connectivity to Microsoft Office 365.
Conclusion, opinion and summary
I recommend to plan, test and execute your Office client upgrade journey to a support Microsoft Office before the above supportability deadline in case your clients run Office 2013.
Additional resources
Anrufe in Microsoft Teams klingeln bald auch auf zweitem Gerät
[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.
Zusätzliche Ressourcen
- Microsoft Teams – Secondary Ringer [Microsoft 365 roadmap update item 51089]
Merger of Yammer and Office profile in Office 365
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.
What does this mean for my users?
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).
Additional resources
BitTitan White Paper – Migrate Microsoft Teams Tenant-to-Tenant
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.
Additional resources
Location Based Routing (LBR) in Microsoft Teams
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.
Why LBR?
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.
Additional resources
- Microsoft Teams – Location Based Routing [Microsoft 365 Roadmap item ID 24180]
- Plan for Location-Based Routing in Skype for Business
