MAILSCAPE von Enow erleichtert die Echtzeit-Überwachung Ihrer Exchange-Systeme, inklusive Exchange Online (Office 365), und stellt alle wichtigen Informationen in einer zentralen Dashboard-Übersicht dar. Zusätzlich überwacht Mailscape alle relevanten Sekundärsysteme (Domänen-Controller und andere Mail-Server).

Mit der intuitiven Dashboard-Technologie ist der aktuelle Status der Messaging-Umgebung auf einen Blick sichtbar. In Kombination mit FORESITE, UNISCOPE und COMPASS können Sie Ihre gesamten Messaging- und Collaboration-Umgebungen in einem zentralen Dashboard überwachen.

In den folgenden zwei Videos wird gezeigt, wie MAILSCAPE dabei hilft Ihre Exchange Umgebung zu überwachen und bei der Fehlersuche zu unterstützen.

1. Überwachung und Test der E-Mail Kommunikation mit externen Systemen

2. Proaktive Überwachung einer Database Availability Group (DAG)

Kostenloser 21-Tage Test und weitere Informationen: http://www.granikos.eu/de/Mailscape

Troubleshooting von Kalender-Stellvertretungen und kalenderbasiertem Präsenzstatus

Im ersten Teil der Serie haben ich einen Überblick über das Zusammenspiel der Teams Backend Services mit lokalen Exchange Organisationen vorstellt. Der zweite Teil der Serie beschreibt, wie die Teams Backend Services die lokale Exchange Organisation per AutoDiscover finden und welche Möglichkeiten Sie haben, um Fehlerquellen zu isolieren, sollte es bei diesem Prozess und dem Zugriff der Kalender-App zu Problemen kommen.

Dieser dritte Teil befasst sich mit Kalender-Stellvertretungen für Teams-Meetings und dem kalenderbasierten Präsenzstatus.

Zum Themenkomplex möglicher Verbindungsprobleme zwischen den Microsoft Backend Services und Exchange Server finden Sie zusätzliche Information in der Microsoft Online Dokumentation.

Troubleshooting Microsoft Teams und Kalender-Stellvertretungen

Der Microsoft Teams Client stellt Ihnen nur den persönlichen Kalender zur Verfügung, um Besprechungen oder Live-Meetings zu planen. Wenn ein Stellvertreter eine Team-Besprechung in meinem Namen in meinem Kalender erstellen soll, muss diese Besprechung über Outlook für Desktop geplant werden. Die Planung einer neuen Teams-Besprechung ist nur möglich, wenn das Microsoft Teams AddIn im Outlook Client des Stellvertreters geladen ist.

Eine weitere wichtige Voraussetzung ist, dass die Stellvertreterberechtigung über den Outlook-Einrichtungsassistenten für Stellvertretungen erfolgt ist. Eine direkte Berechtigung auf dem Postfachordner Kalender ist nicht ausreichend.

Die Erstellung einer neuen Teams-Besprechung durch einen Stellvertreter in Outlook mit einem Postfach in der lokalen Exchange Organisation nutzt ebenfalls den Exchange Web Services Endpunkt.

Hierbei werden folgende Schritte durchlaufen:

1. Der Stellvertreter wechselt im eigenen Outlook-Client auf den Kalender des Managers und klickt in der sog. Ribbon-Bar auf "Neue Teams-Besprechung"
   
    
2. Das Teams Addin verbindet stellt eine Verbindung mit den Teams Backend Services her und fordert die Stellvertreterberechtigung des Manager-Postfaches an
    
3. Die Teams Backend Services ermitteln per AutoDiscover V2-Abfrage die EWS-URL
    
4. Die Teams Backend Services stellen eine OAuth authentifizierte Verbindung zum virtuellen Verzeichnis /EWS her
    
5. Die Teams Backend Services senden eine GetDelegate-SOAP-Anfrage für das Teams Meeting im Manager-Postfach
    
6. Exchange Server antwortet mit einer Liste der Stellvertreter und den zugehörigen Berechtigungen
    
7. Die Teams Backend Services antworten dem Teams AddIn mit den Informationen für das neue Teams-Meeting
   
    

Kommt es zu Problemen bei der Erstellung einer neuen Teams-Besprechungseinladung als Stellvertreter, können Sie folgende Punkte prüfen:

• Funktioniert die Teams Kalender-App für das Manager- und Stellvertreter-Postfach fehlerfrei?
   
• Test Sie die Stellvertreterberechtigung mit Hilfe des Remote Connectivity Analyzers
  
  https://go.granikos.eu/2OgCDWe
   
• Führen Sie eine manuelle GetDelegate-Abfrage mit Hilfe eines SOAP-Client, z.B. SOAPe, durch
  • Nehmen Sie wieder Fiddler zu Hilfe, um weitere Informationen des http-Protokolls zu erfassen
     
• Sie erhalten eine Teams Fehlermeldung
  
   
  • Prüfen Sie die Stellvertreterberechtigung, eine direkte Berechtigung auf dem Kalenderordner ist nicht ausreichend
     
• Prüfung der Exchange Protokolldateien und Exchange Einstellungen
  
  • Ist die GetDelegate-Anfrage in den EWS-Protokolldateien vorhanden?
  • Prüfung der IIS Frontend- und EWS-Proxy-Protokolle
  • Prüfung der PartnerApplication-Konfiguration

Eine weitere Fehlerquelle für den Zugriff auf Exchange Server Endpunkte sind Zugriffsfilterungen auf Basis des User Agent Strings. Wenn Sie Layer 7 Netzwerkgeräte einsetzen, die solche Filterungen durchführen, konfigurieren Sie diese für Bypass.

Im zweiten Teil der Artikelserie haben Sie die detaillierten Schritte für die Fehlersuche in den Exchange Server Protokolldateien kennengelernt. Nutzen Sie für das Troubleshooting der Kalenderstellvertretungen die gleiche Vorgehensweise.

Troubleshooting Microsoft Teams und kalenderbasierter Präsenzstatus

Microsoft Teams kann den Präsenzstatus auf Basis von Kalenderinformationen im persönlichen Postfach auf „In einer Besprechung“ setzen. Bei der Nutzung eines lokalen Exchange Server Postfaches sind dieser Funktionen jedoch Grenzen gesetzt.

Der Microsoft Teams Client fragt den Präsenzstatus alle sechs Minuten beim Präsenzdienst im Teams Backend ab. Eine Exchange Kalenderabfrage kann in zwei unterschiedlichen Modi erfolgen:

• Pull-Modus, Abfrage der Kalenderinformationen im 1h-Intervall
• Push-Modus, Abonnement-basierte Abfrage

Im Zusammenspiel mit Exchange Server ist nur der Pull-Modus unterstützt.

Im Gegensatz zu den bisher beschriebenen Zugriffsarten, erfolgt der Zugriff durch den Präsenzdienst per REST-Protokoll statt. Hierbei werden folgende Schritt durchlaufen:

1. Die Teams Backend Services ermitteln per AutoDiscover V2-Abfrage die REST-URL
2. Die Teams Backend Services stellen eine OAuth authentifizierte Verbindung zum virtuellen Verzeichnis /api her
3. Die Teams Backenend Services versuchen ein Abonnement einzurichten
   1. Hierbei kommt es zu einem RPC-Endpunkt nicht gefunden Fehler
4. Die Teams Backend Services führen als Fallback eine normale Kalenderabfrage durch und geben die Informationen an den Präsenzdienst weiter

Die Möglichkeiten zur Fehleranalyse gleichen auch hier den Möglichkeiten, die Sie bereits bei AutoDiscover und dem Kalenderzugriff kennengelernt haben:

• Ist die richtige API-URL in der AutoDiscover Antwort enthalten und auf dem Internet erreichbar?
  • Hier hilft Ihnen wieder einmal Fiddler
     
• Prüfen die web.config des Frontend REST-Verzeichnisses, wenn Sie die kumulativen Updates für Exchange Server von Dezember 2020 noch nicht installiert haben
  • In der web.config muss das Attribut maxQueryStringLength ergänz werden.

$exinstall\FrontEnd\HttpProxy\rest\web.config

<httpRuntime maxRequestLength="2097151" maxUrlLength="2048" maxQueryStringLength="4096" requestPathInvalidCharacters="<,>,*,%,\,?" requestValidationMode="2.0" />

• Prüfung der IIS Frontend- und REST-Proxy-Protokolle
• Prüfung der REST-Protokolle

Wie auch bei den Kalenderstellvertretungen , sind auch beim Präsenzstatus Zugriffsfilterungen auf Basis des User Agent Strings eine Fehlerquelle. Wenn Sie Layer 7 Netzwerkgeräte einsetzen, um Zugriffe auf den REST-Endpunkt zu filtern, so konfigurieren Sie diese für Bypass oder entfernen diese aus dem Zugriffspfad.

Links

• SOAPe Client bei GitHub
• Troubleshooting Microsoft Teams and Exchange Server interaction issues
• Exchange Server Build Numbers and Release Dates

• Teil 1 - Wie interagieren Microsoft Teams und Exchange Server?
• Teil 2 - Troubleshooting der Kalender-App
• Teil 3 - Troubleshooting von Kalenderstellvertretungen und kalenderbasiertem Präsenzstatus

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.

Microsoft Teams Backend Services

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.

Übersicht Kalenderzugriff

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:

• Konfiguration von Azure AD Connect mit aktivierter Option Exchange Hybrid
• Synchronisation aller Postfachnutzer der lokalen Exchange Organisation zu Azure AD
• Erreichbarkeit der lokalen Exchange Organisation aus dem Internet
• Einsatz von Exchange Server 2019 oder 2016 mit aktuellem kumulativem Update
• Konfiguration des Exchange Namensraums in der externen DNS-Zone
• Konfiguration der AutoDiscover-Endpunkte für die primären E-Mail-Domänen in der externen DNS-Zone
• Konfiguration der klassischen Exchange Hybridkonfiguration mit Hilfe des Hybrid Configuration Wizard

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.

Links

• Anforderungen zum Erstellen und Anzeigen von Besprechungen für lokal gehostete Postfächer

• Teil 1 - Wie interagieren Microsoft Teams und Exchange Server?
• Teil 2 - Troubleshooting der Kalender-App
• Teil 3 - Troubleshooting von Kalenderstellvertretungen und kalenderbasiertem Präsenzstatus

Viel Spaß mit Microsoft Teams und Exchange Server.

Troubleshooting der Kalender-App

Teams Backend AutoDiscover

Die Teams Backend Services nutzen AutoDiscover Version 2, um das Exchange Anwender-Postfach im Auftrag eines Teams-Clients zu finden. Dieser AutoDiscover V2 Aufruf ist aus Performancegründen ein anonymer Aufruf, um möglichst schnell die Exchange Ziel-URL für das gesuchte Postfach zu ermitteln. Wie bereits im ersten Teil erwähnt, wird erfolgt zuerst immer eine Abfrage gegen den AutoDiscover-Endpunkt von Exchange Online durchgeführt. Sollte sich das Postfach nicht in Exchange Online befinden, erhalten die Backend Services in einer Redirect-Antwort die Zieladresse der lokalen Exchange Organisation, um eine erneute AutoDiscover-Abfrage durchzuführen.

Hierbei werden folgende Schritte durchlaufen:

1. Die Teams Backend Services fragen den Exchange Online AutoDiscover-Endpunkt per AutoDiscover V2 JSON-Abfrage nach der URL für das EWS-Protokoll
   https://outlook.office365.com/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=EWS
    
2. Exchange Online prüft den Empfängertyp (RecipientType) der angefragten E-Mail-Adresse und gibt für den gefundenen Empfängertyp folgende Antworten:
   1. RecipientType: Mailbox
      https://outlook.office365.com/EWS/Exchange.asmx
      
      Das Postfach ist ein Exchange Online Postfach, somit sind keine weiteren Schritte notwendig.
      Die Teams Backend Services haben die notwendige Information, um auf das Postfach und den Kalender zuzugreifen.
       
   2. RecipientType: MailUser
      Exchange Online ermittelt den AutoDiscover-Endpunkt auf Basis des Attributes ExternalEmailAddress, in diesem Beispiel autodiscover.varunagroup.de
       
3. Exchange Online antwortet mit einem HTTP 302 Redirect zu autodiscover.varunagroup.de
    
4. Die Teams Backend Services fragen per AutoDiscover V2 JSON-Abfrage nach der URL für das Protokoll EWS
   https://autodiscover.varunagroup.de/autodiscover/autodiscover.json?Email=John.Doe@varunagroup.de&Protocol=EWS
    
5. On-Premises Exchange Server antwortet mit einer externen EWS URL eines virtuellen Exchange Web Services Verzeichnisses
   Beispiel: {"Protocol":"EWS","Url":"https://mail.varunagroup.de/EWS/Exchange.asmx"}
    
6. Die Teams Backend Services nutzen diese URL, um eine Verbindung zur On-Premises Exchange Organisation aufzubauen

Aber was passiert, nachdem die Teams Backend Services die URL für den Zugriff auf das lokale Postfach ermittelt haben? Es werden folgende Schritte durchgeführt:

• Zugriff auf die ermittelte EWS-URL der lokalen Exchange Organisation und Durchführung einer OAuth-Authentifizierung
• Die Teams Backend Service senden eine EWS-Kalenderanfrage an den EWS-Endpunkt
• Die Exchange Web Services antworten mit den Kalenderinformationen des Anwenderpostfaches
• Die Teams Backend Services geben die Kalenderdaten an die Kalender-App zur Nutzung im Teams-Client weiter

Wie Sie sehen, ist der Zugriff auf den Kalender eines Benutzerpostfaches in einer lokalen Exchange Organisation komplex. Hierbei kann es auch zu Fehlern kommen.

Wie können Sie nun für den AutoDiscover-Prozess und den Kalenderzugriff eine Fehleranalyse durchführen? Fangen wir mit AutoDiscover an.

Troubleshooting AutoDiscover

Da alle AutoDiscover- und weiteren Zugriffe aus den Teams Backend Services heraus erfolgen, sind Troubleshooting-Schritte auf dem lokalen Teams-Client nicht hilfreich.

AutoDiscover V2 ist ein anonymer Zugriff und ermöglicht so einen einfachen Selbsttest. Dies hilft Ihnen als IT-Administrator, um den Zugriff für ein Benutzerkonto zu prüfen, bei dem es zu einem Fehlverhalten kommt. Prüfen Sie das AutoDiscover Verhalten per PowerShell oder mit Hilfe eines Browsers.

Test per PowerShell

Invoke-RestMethod -Uri 'https://outlook.office365.com/autodiscover/autodiscover.json?Email= John.Doe@varunagroup.de&Protocol=EWS'

Invoke-RestMethod -Uri 'https://outlook.office365.com/autodiscover/autodiscover.json?Email= John.Doe@varunagroup.de&Protocol=REST'

Test per Browser

https://outlook.office365.com/autodiscover/autodiscover.json?Email=john.doe@varunagroup.de&Protocol=EWS
https://outlook.office365.com/autodiscover/autodiscover.json?Email=john.doe@varunagroup.de&Protocol=REST

Führen Sie zur erweiterten Fehleranalyse bei der Ausführung der HTTPS-Abfragen einen Fiddler-Trace durch. Der Trace hilft Ihnen, weitere mögliche Fehlerquellen zu identifizieren.

Kommt es bei der Ermittlung der AutoDiscover Informationen zu einem Fehler, bedeutet dies nicht automatisch, dass ein Problem vorliegt. Prüfen Sie folgende Punkte:

• Die Ausführung der Abfrage wird mit einer Zeitüberschreitung abgebrochen
  • Ist der HTTPS-Zugriff auf die Ihre Exchange Organisation auf den Remote -IP-Adressbereiche von Microsoft 365 eingeschränkt?
  • Haben die Exchange Server ein Performance-Problem und können nicht zeitnah antworten?
     
• Sie erhalten eine „User Not Found“-Meldung als Antwort
  • Ist das Benutzerkonto von der Azure AD Connect Synchronisierung ausgenommen und existiert nicht als „Mail User“-Objekt in Exchange Online?
     
• Die Antwort liefert eine nicht erwartete EWS oder REST URL
  • Das Anwenderpostfach ist ein lokales Postfach, als Antwort erhalten Sie aber
    https://outlook.office365.com/EWS/Exchange.asmx
    
    Der Anwender verfügt über ein zusätzliches Postfach in Exchange Online.
    Lösen Sie die Postfach-Situation auf.
     
  • Sie erhalten eine URL, die wie einer interne URL aussieht
    https://exch01.varunagroup.local/EWS/Exchange.asmx
    
    Das ExternalUrl-Attribut ist nicht auf allen Exchange Servern konfiguriert.
  • Sie nutzen gebundene Namensräume und das Anwenderpostfach ist in der AD-Site EMEA, sie erhalten aber die URL einer anderen AD-Site
    https://mail.apac.varunagroup.de/EWS/Exchange.asmx
    Erwartete URL: https://mail.emea.varunagroup.de/EWS/Exchange.asmx
    
    AutoDiscover V2 ist erst mit den kumulativen Updates von März 2021 "AD-Site aware". Ohne dieses Update für Exchange Server 2016 und 2019 antwortet AutoDiscover V2 mit eine zufällig gewählten URL.
     
• Die Namensauflösung für die Zieldomäne schlägt fehl
  • Es existiert kein DNS-Eintrag für AutoDiscover

Die nächsten Schritte zur Identifikation von Verbindungsproblemen führen uns schon zu den lokalen Exchange Servern. Mit einem lokalen Netzwerk-Trace können Sie feststellen, ob es zu TLS-Handshake Fehlern kommt. Bedenken Sie, dass Ihre Exchange Server System korrekt für TLS 1.2 konfiguriert sein müssen.

Gibt es keine Fehler beim TLS-Handshake, gilt es nun die Protokolldateien der Exchange Server zu prüfen. Die Prüfung der Protokolldateien ist auf den lokalen Exchange Servern erfordert mehrere Schritte. Je nach Größe Ihrer lokalen Exchange Organisation ist diese Prüfung beliebig komplex.

Das folgende Diagramm zeigt die beteiligten Exchange Server Komponenten eines einzelnen Exchange Servers für eingehende Verbindungen der Teams Backend Services zum Exchange Web Services Endpunkt.

Eine eingehende HTTPS-Verbindung wird durch die Frontend-Komponente eines Exchange Servers angenommen und anschließend als Proxy-Verbindung zu dem Exchange Server weiterverbunden, auf dem im Moment des Zugriffes die Postfachdatenbank mit dem Anwender-Postfach aktiv eingebunden ist. Prüfen Sie zuerst in IIS-Protokolldateien, ob die Verbindung durch die Internet Information Service angenommen wurde. Überprüfen Sie anschließend die Frontend- oder Backend-Protokolldateien des angesprochenen Exchange-Endpunktes, also AutoDiscover, EWS oder REST.

Zum Themenkomplex möglicher Verbindungsprobleme zwischen den Microsoft Backend Services und Exchange Server finden Sie zusätzliche Information in der Microsoft Online Dokumentation.

Troubleshooting Kalender-App

Nachdem Sie nun wissen, wie Sie den Fehlern im AutoDiscover-Prozess begegnen, ist es Zeit, einen Blick auf die Kalender-App zu werfen.

Wenn der Zugriff auf AutoDiscover fehlerfrei funktioniert, ist die Wahrscheinlichkeit groß, dass auch der Zugriff auf die Exchange Web Services funktioniert und damit auch die Kalender-App im Teams Client des angemeldeten Anwenderkontos.

Sollte der Kalender im Teams-Client nicht angezeigt werden, prüfen Sie folgende Punkte:

• Kann die per AutoDiscover ermittelte EWS-URL in der externen DNS-Zone der Domäne aufgelöst werden und ist sie aus dem Internet per HTTPS erreichbar?
  • Rufen Sie die Ziel-URL in einem Browser auf und führen Sie eine Fiddler-Trace durch
    Der EWS Endpunkt muss mit einem HTTP-Statuscode 401 antworten
     
• Prüfen Sie den Teams Kalenderzugriff mit Hilfe des Remote Connectivity Analyzer.
  
  
  • http://bit.ly/TeamsCalTest
     
• Prüfen Sie die OAuth-Authentifizierung
  • Hier hilft Ihnen das PowerShell Cmdlet Test-OAuthConnectivity
  • Prüfen Sie auch die ServicePrincipalNames, IntraOrganization- und AuthServer-Einstellungen

Links

• Exchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using It
• My user has a mailbox both on-premises and in Exchange Online. Help!
• Configure OAuth authentication between Exchange and Exchange Online organizations

• Teil 1 - Wie interagieren Microsoft Teams und Exchange Server?
• Teil 2 - Troubleshooting der Kalender-App
• Teil 3 - Troubleshooting von Kalenderstellvertretungen und kalenderbasiertem Präsenzstatus

Mit der neuen Version von Uniscope, dem Lync Management Tool von ENow, stehen neue Reports zur Verfügung.

21-Tage Test-Version und mehr über Uniscope für Lync erfahren: http://www.granikos.eu/de/Uniscope

Die nachfolgenden Links dienen als Link-Liste für das Troubleshooting und Planung von On-Premises Exchange Installationen und Exchange Hybrid Umgebungen. Ebenso finden sich Links für die Installationsvoraussetzungen von Exchange Server und anderer Tools in der Übersicht.

Microsoft 365 ist ein Clouddienst von Microsoft und lebt von Ihrem Feedback und Ihren Ideen. Microsoft hat sich entschieden, UserVoice nicht mehr zu verwenden und zu einer anderen Plattform zu wechseln. Nutzen Sie bis dahin die Tech Community, um Ihr Feedback mitzuteilen.

Granikos Links

• Thomas' Tech Talk - Übersicht - techtalk.granikos.eu
• Was ist Office 365?
• Einstieg in Microsoft 365

Exchange Server

PowerShell 

• Exchange PowerShell bei Microsoft Docs
• How to Use the New Exchange Online V2 PowerShell Module

Troubleshooting

• SSL Server Test 
• SSL/TLS Server Test 
• ROCA Vulnerability Test Suite
• MX Toolbox
• Message Header Analyzer (https://aka.ms/mha)
• Remote Connectivity Analyzer
• Exchange Server 2013, 2016, and 2019 Build Numbers (with Cumulative Updates)
• Log Parser Studio Report Collection - Troubleshooting Exchange 2013 Performance
• How can you download a hotfix without contacting Microsoft?
• Repair failed installations of Exchange Cumulative and Security updates

Planung

• Exchange Server-Unterstützbarkeitsmatrix
• Exchange Server build numbers and release dates
• Exchange-Processor Query Tool: PowerShell Edition
• Processor Query Tool v1.1
• Exchange Hybrid Configuration Wizard v17
• Additional endpoints not included in the Office 365 IP Address and URL Web service
• Outlook license requirements for Exchange features
• Modern public folder deployment best practices
• UN/LOCODE
• UN/LOCODE (DE)

Installation

• Exchange Server 2019 - Installationsvoraussetzungen
  • Übersicht der Voraussetzungen
  • Visual C++ Redistributable for Visual Studio 2012
  • Visual C++ Redistributable Packages for Visual Studio 2013
    • Most recent C++ Redistributable Downloads
  • Microsoft .NET Framework 4.7.2 (Offline-Installer) (bis CU3)
  • Microsoft .NET Framework 4.8 (Offline-Installer)  (CU4 und neuer)
  • Microsoft Unified Communications Managed API 
    • Bestandteil des Exchange Server 2019 Installationsmediums
      [EXCHANGEISO]\UCMARedist
       
• ​Exchange Server 2016 - Installationsvoraussetzungen
  • Übersicht der Voraussetzungen
  • Visual C++ Redistributable for Visual Studio 2012
  • Visual C++ Redistributable Packages for Visual Studio 2013
    • Most recent C++ Redistributable Downloads
  • Microsoft .NET Framework 4.5.2 (Offline-Installer)
  • Microsoft .NET Framework 4.6.1 (Offline Installer) (CU2 - CU7)
    • Hotfix-Rollup 3146715 für.NET Framework 4.6 und 4.6.1 in Windows (Windows Server 2012R2)
  • How to temporarily block the installation of the .NET Framework 4.7 
  • Microsoft .NET Framework 4.7.1 (Offline Installer) (Exchange Server 2016 CU8 - CU11)
  • Microsoft .NET Framework 4.7.2 (Offline-Installer) (CU11 - CU13)
  • Microsoft .NET Framework 4.8 (Offline-Installer) (CU13 und neuer)
  • Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
     

Migration

• Exchange Resource Forest and Office 365 – Part I 
• Best practices for public folder preparation before migrations

Microsoft 365

Allgemein

• Service Trust Portal
• URLs und IP-Adressbereiche von Office 365
• Exchange Online Protection IP Addresses
• Office 365 Network Onboarding tool
• Table of Language Culture Names, Codes, and ISO Values
• Microsoft Online Services Sign-In Assistant for IT Professionals RTW
• Office 365 Datacenter Map
• ADFS Open Source Tools 
• Microsoft Teams IT Architecture and Telephony Solutions Posters (PDF/Visio)
• Microsoft Cloud IT Architecture Resources (PDF/Visio)

Azure AD Connect

• Topologies for Azure AD Connect
• Azure AD Connect: Version Release History
• Azure AD Connect prerequisites and hardware requirements
• Download Microsoft Azure Active Directory Connect

Planung

• Office 365 Network Performance Tool
• Network planning and performance tuning for Office 365
• Office 365 Network Connectivity Principles
• Network Assessment Tool Plus
• Office 365 ROI Calculator
• Verfügbarkeit Tenant-Name
• Erstellung der Office Deployment Tool (ODT) XML-Datei 

Troubleshooting

• Microsoft 365 Network Connectivity Health
• Remote Connectivity Analyzer
• Support- und Wiederherstellungs-Assistenten für Office 365
• Create DNS records at Strato for Office 365 

Administration

• Manage who can create Office 365 Groups
• Azure AD Connect Communications Test 
• TLS 1.0/1.1 Deprecation Report
• Microsoft 365 DSC

Microsoft Teams

• Links zu Microsoft Teams finden Sie immer aktuell unter dem Tag Microsoft Teams: https://www.granikos.eu/de/Blog/Tag/microsoft-teams 
• SWOOP Benchmark Report (Video)

OneDrive for Business

• OneDrive for Business – Fixing credential issues

Device Management

• How-To: Windows AutoPilot Deployment Program
• Windows AutoPilot - Manually registering devices

Azure

• Azure Portal
• Azure 101
• Azure Account Portal
• Azure Rights Management Administration Tool
• Azure Architecture Center
• Azure Active Directory Module
• Interactive Azure Platform Overview
• Operations Management Suite (OMS) SDK

Visio

• Microsoft Integration and Visio Stencils

SQL Server

• Download des aktuellsten SQL Server 2014 CU - Service Pack 2 Branch
• Download des aktuellsten SQL Server 2014 CU - Service Pack 3 Branch
• Download des aktuellsten SQL Server 2016 CU - Service Pack 2 Branch
• Download des aktuellen SQL Server 2017 CU Branch
• Download der aktuellen Version des SQL Server Management Studios (SSMS)

Allgemein

• Microsoft .NET Framework Repair Tool
• HTML Cleaner
• Regular Expressions - iHateRegEx

Windows Server

• Windows Admin Center - Übersicht
• Windows Admin Center - Download 

Securing Active Directory

• Best Practices for Securing Active Directory
  • Events to Monitor

Tools

• Mailscape 365
  Aktive Überwachung von Microsoft 365 Endpunkten und der Cloud-Anwendererfahrung für Ihre Mitarbeiter
   
• ShareGate Apricot
  Reporting und Management Lösung für Microsoft Teams und Office 365-Gruppen
   
• ScriptRunner
  Software zur professionellen PowerShell Automatisierung
   
• AdminDroid
  Detailliertes Reporting und Controlling Ihres Microsoft 365 Tenants
   

Feedback

• Tech Community
• Office 365 UserVoice
• Azure Feedback

Mailscape 365 - Überwachung von Hybrid Exchange und Office 365: Viele Unternehmen verwenden eine lokale Exchange Organisation und Exchange Online in einer Hybrid-Konfiguration, um die Anforderungen ihrer Mitarbeiter zu erfüllen. Der Betrieb einer hybriden Exchange Organisation seine ganz eigenen Herausforderungen für das Monitoring der Dienstverfügbarkeiten. Beginnen Sie noch heute einen unverbindlichen 14-Tage Test von Mailscape 365.

2021-06-02: Verwaiste Links zur TechNet Gallery entfernt oder aktualisiert
2021-05-27: Skype for Business entfernt, Visio hinzugefügt
2021-03-29: Network Status Health hinzugefügt
2021-03-11: Entfernung der UserVoice-Verlinkungen
2021-03-10: Repair failed installations of Exchange Cumulative and Security updates hinzugefügt