Thomas Stensitzki is a leading technology consultant focusing on the Microsoft messaging and collaboration technologies and the owner of Granikos GmbH & Co. KG.
He is an MVP for Office Apps & Services since 2018.
Thomas is an MCT Regional Lead for Germany and delivers Microsoft Learning training courses for Office 365, Microsoft Teams, and Exchange Server.
He holds Master certifications as Microsoft Certified Solutions Master Messaging and as Microsoft Certified Master for Exchange Server 2010. His experience makes him a subject matter expert for any messaging topic related to Microsoft Exchange, Exchange Online, Office 365, and Hybrid configurations.
Podcast #MVPbuzzChat with Thomas Stensitzki
Follow Thomas on LinkedIn or Twitter
His sessions: https://sessionize.com/thomas-stensitzki
MVP Blog: https://blogs.msmvps.com/thomastechtalk Personal blog: http://justcantgetenough.granikos.eu Personal website: http://www.stensitzki.de Thomas' Tech Talk: youtube.com/ThomasStensitzki
Contact Thomas at thomas@mcsmemail.de
Eine wichtige Komponente von Microsoft Teams ist die Kalender-Applikation. Die Aufgabe dieser Applikation ist die Anzeige des persönlichen Kalenders aus dem persönlichen Postfach und die Erstellung von neuen Teams-Besprechungen oder Live-Ereignissen. Die Kalender-App können Sie über die App-Leiste aufrufen.
Damit der persönliche Kalender in Microsoft Teams angezeigt werden kann, müssen die Teams Backend Services auf das Anwender-Postfach zugreifen. Dieser Zugriff ist für Postfächer, die in Exchange Online gehostet sind, kein Problem, da hier die erforderlichen Zugriffswege und -berechtigungen Basisbestandteil von Microsoft 365 sind.
Um den Zugriff auf Postfächer, die in einer lokalen Exchange Organisation bereitgestellt werden, zu gewährleisten, müssen bestimmte Voraussetzungen erfüllt werden. Diese technischen Voraussetzungen bringen eine zusätzliche Komplexität in den täglichen Betrieb, die ihre ganz eigenen Herausforderungen für das Troubleshooting hat. Als IT-Administrator müssen Sie die einzelnen Komponenten und das Zusammenspiel zwischen den Komponenten kennen, um Fehlern effizient zu begegnen.
In diesem ersten Artikel einer dreiteiligen Artikelserie, liegt der Fokus auf den technischen Komponenten und den Anforderungen für das reibungslose Zusammenspiel, um lokale Exchange Postfächer für Microsoft Teams verfügbar zu machen. Die beiden folgenden Artikel zeigen Ihnen die Möglichkeiten und Werkzeuge für ein Troubleshooting.
Im Gegensatz zu anderen Software-Clients, die auf ein Exchange Postfach zugreifen, erfolgt der Kalenderzugriff bei Microsoft Teams nicht durch den jeweiligen Teams Client selbst, sondern clientunabhängig durch die sog. Teams Backend Services. Der Clientzugriff auf andere Microsoft 365 Dienste, wie z.B. SharePoint Online oder OneNote erfolgt durch die Clients direkt.
Das folgende Diagramm verdeutlicht, wie der Zugriff der einzelnen Teams Client-Varianten auf die Teams Services.
Quelle: Microsoft
Für den Zugriff auf den persönlichen Kalender eines Exchange Postfaches sind die rot markierten Komponenten wichtig. Die im Diagramm als simpler Strich gezeichnete Verbindung zwischen den Teams Backend Services und Exchange hat es in sich.
Bei Start des Teams Clients fragt der Client den Kalender für den Anwender bei den Teams Backend Services ab. Basis für diese Anfrage ist die primäre E-Mail-Adresse des angemeldeten Benutzerkontos, in unserem Beispiel die Adresse John.Doe@varunagroup.de.
Im ersten Schritt führen die Teams Backend Services eine AutoDiscover V2 Abfrage bei Exchange Online durch (1). Die Abfrage gegen die Adresse outlook.office365.com erfolgt immer, da die Teams Backend Services davon ausgehen, dass Exchange Online die notwendigen Informationen für den Kalenderzugriff auf das Postfach von John Doe zur Verfügung stellen kann.
Da sich das Postfach in diesem Beispiel in einer lokalen Exchange Organisation befindet, antwortet Exchange Online mit einem HTTP 302 Redirect Response, der die Ziel-Url für die On-Premises AutoDiscover-Abfrage enthält. Durch diesen Response werden die Teams Backend Services nun aufgefordert, die lokale Exchange Organisation eigenständig per AutoDiscover V2 auf Basis zu kontaktieren.
Die Teams Backend Services versuchen in Schritt (2), den AutoDiscover-Endpunkt über den DNS-Namen der HTTP 302 Antwort zu erreichen und eine HTTPS-Verbindung aufzubauen. Der Zugriff auf den AutoDiscover Endpunkt erfolgt über eine anonyme AutoDiscover V2 Verbindung. Als Antwort erhalten die Teams Backend Services die externen URL-Informationen der lokalen Exchange Organisation. Dies sind die Informationen, die als ExternalUrl-Attribute für die virtuellen Exchange Server EWS-Verzeichnisse konfiguriert sind.
Erst in Schritt (3) erfolgt der authentifizierte Zugriff auf das Exchange Postfach. Die vorherigen Zugriffe wurden aus Performancegründen anonym durchgeführt. Als Authentifizierungsmethode wird nun OAuth verwendet. Wenn die Teams Backend Services den Endpunkt der Exchange Web Services erreichen und sich per OAuth authentifizieren können, werden die Kalenderinformationen gelesen und für den anfragenden Teams-Client aufbereitet und bereitgestellt.
Dies ist der Moment, in dem der Teams-Client das Icon der Kalender-App darstellt, damit der Anwender auf den Kalender zugreifen kann.
Damit dieses Zusammenspiel der Komponenten fehlerfrei funktionieren kann, müssen folgenden Voraussetzungen erfüllt sein:
Mit einer hybriden Exchange-Konfiguration, die diese Voraussetzungen erfüllt, funktioniert die Nutzung lokaler Postfächer mit Microsoft Teams.
Exchange Server ist eine sehr tolerante Server Applikation, die in ganz unterschiedlichen Konfigurationen betrieben werden kann. Individuelle Abweichungen einer Standardimplementierung von Exchange Server und einer hybriden Verbindung mit Microsoft 365 führen zu Fehlern bei der Nutzung von Microsoft Teams mit lokalen Benutzerpostfächern.
In den nächsten beiden Artikeln der Serie schauen wir uns den direkten Kalenderzugriff und den Stellvertreterzugriff genauer an, ebenso die möglichen Fehlerquellen und die Fehleranalyse.
Viel Spaß mit Microsoft Teams und Exchange Server.
Das Blog Cumulative Update für März 2021 (CU0321) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Microsoft Teams und Azure des Monats März 2021 zusammen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Microsoft 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.
Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop. Bis dahin, werfen Sie doch einen Blick in das Microsoft Exchange Server 2019: Das Handbuch für Administratoren.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu
Die Dienste von Microsoft 365 machen es Anwender leicht, sich mit Ihrer beruflichen E-Mail-Adresse anzumelden. Anwender werden regelrecht dazu verführt, eine für sie interessante Lösung auszuprobieren.
Lösungen wie Microsoft Teams, Power BI und andere benötigen für ihre Funktion Azure AD und damit einen Microsoft 365 Mandanten. Wenn sich nun ein Anwender mit einer beruflichen E-Mail-Adresse bei einer ausgewählten Lösung anmeldet, ob die E-Mail-Domäne bereits eine, existierenden Mandaten zugeordnet ist. Ist dies der Fall, erfolgt die Authentifizierung und weitere Nutzung auf Basis der Einstellungen des entsprechenden Mandanten.
Was aber passiert, wenn die E-Mail-Domäne keinem Mandanten zugeordnet ist?
In diesem Fall erstellt Microsoft 365 einen sog. Schattenmandanten, dem die E-Mail-Domäne des Anwender als Schattendomäne zugeordnet wird. Hierzu erhält der Anwender kein Feedback, da die Nutzung der ausgewählten Lösung im Vordergrund steht.
Das Problem einer Schattendomäne trifft Sie, als Administrator eines Microsoft 365 Mandanten erst dann, wenn Sie diese Domäne einem regulär aktiviertem Mandanten hinzufügen möchten. Oder wenn Sie dies als Berater für einen Ihrer Kunden durchführen möchten. In diesem Fall führt Sie der Einrichtungsassistent des Microsoft 365 Admin Centers zu einem Übernahmeprozess der Domäne per E-Mail.
In diesem Prozess kann aus ganz unterschiedlichen Gründen zu Problemen kommen. Einfacher ist es, die Schattendomäne mit Hilfe von PowerShell zu übernehmen. Hierzu benötigen Sie das MSOnline-PowerShell Modul und Zugriff auf die DNS-Verwaltung der betroffenen Domäne.
Führend Sie folgenden Schritte durch.
# Falls nicht installiert Install-Module -Name MSOnline # Falls installiert Update-Module MSOnline -Force # Anmeldung am Microsoft 365 Mandanten als globaler Administrator Connect-MSOnline # Hinzufügen der Schattendomäne (Beispiel varunagroup.de) New-MSOLDomain -Name varunagroup.de # Prüfung des Domain Status der nicht verifizierten Domäne Get-MSOLDomain # Abfrage des Wertes zur Überprüfung per TXT-Eintrag Get-MSOLDomainVerificationDns -DomainName varunagroup.de -Mode DnsTxtRecord
Als Ausgabe erhalten Sie die Informationen für einen TXT-Eintrag in der Form MS=xxxxxxx. Dieser Wert muss in der DNS-Verwaltung als namenloser TXT-Eintrag für die Schattendomäne eingetragen werden. Geben Sie den DNS-Servern ein paar Minuten Zeit, um die Änderung zu übernehmen.
Führen Sie nun in der gleichen PowerShell-Session die Überprüfung des TXT-Eintrages durch. Wichtig ist hierbei der zusätzliche Parameter ForceTakeOver.
# Überprüfung des DNS-Eintrages und Übernahme der Domäne Confirm-MSOLDomain -DomainName varunagroup.de -ForceTakeover Force # Prüfung des Domain-Status Get-MSOLDomain
Die Prüfung kann einen Moment Zeit in Anspruch nehmen. Der Status der neuen Domäne muss von Unverified zu Verfied wechseln.
Damit haben Sie eine Schattendomäne übernommen und zu einem bestehenden Mandanten hinzugefügt.
Viel Spaß mit Microsoft 365!
Zur HAFNIUM Sicherheitslücke in Exchange Server stehen Informationen auf zahlreichen Seiten zur Verfügung.
Dieser Post dient der Sammlung von Links zu diesem Thema.
Wenn Sie einen Link vermissen, senden Sie mir gerne eine E-Mail an Exchange2019@Exchange-Doktor.de
Update 2021-03-17: Guidance for responders: Investigating and remediating on-premises Exchange Server vulnerabilities hinzugefügt
Heute wurde die elfte Folge von Thomas' Tech Talk veröffentlicht.
Das Thema des Talks ist:
Das PowerShell-Skript HealthChecker.ps1 hilft Ihnen bei der korrekten Konfiguration des Serversystems, auf dem Sie eine Exchange Server Installation betreiben. Nutzen Sie dieses Skript nach der Installation und Basiseinrichtung des Servers.
Die Aufgabe des Skriptes ist es nicht, Exchange Server richtig zu konfigurieren, sondern Empfehlungen für die Konfiguration der Betriebssystemkomponenten wie Netzwerk-Adapter, Page File, C++ Bibliotheken, CPU oder den Arbeitsspeicher zu geben. Wenn Sie die vom Skript empfohlenen Einstellungen umsetzen, erhöhen Sie die Betriebssicherheit und Stabilität des Exchange Server Systems.
In diesem Tech Talk zeige ich Ihnen, wie hilfreich und einfach dieses Skript ist.
<!--cke_bookmark_408E--><!--cke_bookmark_104E-->
Viel Spaß.