de-DEen-GB
rss

Granikos Technology Blog

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"
    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
    Teams Meeting Information
     

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
    Test der Teams-Besprechungsdelegierung
    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
    Microsoft Teams - Permissions Error
     
    • Prüfen Sie die Stellvertreterberechtigung, eine direkte Berechtigung auf dem Kalenderordner ist nicht ausreichend
       
  • Prüfung der Exchange Protokolldateien und Exchange Einstellungen
    Microsoft Teams - Connection Error
    • 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

 

 

 

Weiterlesen »

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.

Diagramm Teams Backend Services zu Exchange Server Verbindung

 

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.

    Screenshot Remote Connectivity Analyzer - Teams Kalender Tab Test
  • Prüfen Sie die OAuth-Authentifizierung

 

Links

 

 

 

 

Weiterlesen »

Folge 11

Heute wurde die elfte Folge von Thomas' Tech Talk veröffentlicht.

Das Thema des Talks ist:

  • Exchange Server und das HealthChecker-Skript

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.

 

 

Links

 

Ressourcen

 

Viel Spaß.

 

 

Weiterlesen »

Exchange Server LogoExchange Server und Exchange Online nutzen Aufbewahrungsrichtlinien, um sog. Aufbewahrungstags zu gruppieren. Ein Aufbewahrungstag beschreibt, wie der Exchange Managed Folder Assistant Elemente in einem Postfach oder einem Postfachordner verarbeiten soll, wenn diese automatisch bereinigt oder aufbewahrt werden sollen.

Manchmal zeigen diese Richtlinien ein unerwartetes Verhalten an den Tag. Dieses Verhalten lässt sich nur durch eine Entfernung der Aufbewahrungsinformationen aus dem betroffenen Postfach lösen.

Um zu verstehen, wie man Exchange Aufbewahrungsrichtlinien bereinigt, müssen wir zuerst ein Blick auf die Basics der Aufbewahrung in Exchange Server werfen werfen.

Aufbewahrungstags (Retention Tags)

Es existieren Standard (Default) und Persönliche (Personal) Tags. Diese Tags definieren, was mit einem Objekt passieren soll, ob aufbewahrt, gelöscht oder in das Archiv-Postfach verschoben werden soll.

Standard-Tags greifen immer für das gesamte Postfach, oder, im Fall von Löschrichtlinien, für Standard-Ordner.

 

Aufbewahrungsrichtlinien (Retention Policies)

Alle Richitlinen-Tags, die Sie einer Mailbox zuweisen möchten, werden in einer Aufbewahrungsrichtlinie zusammengefasst. Jedem Postfach kann nur eine Aufbewahrungsrichtlinie zugewiesen werden.

Der folgende Screenshot zeigt die Standard MRM Aufbewahrungsrichtlinien für Benutzer- und Arbitration-Postfächer, ergänzt um zwei Test-Richtlinien.

Screenshot Exchange Management Shell für Get-RetentionPolicy

Wenn Sie mehr über Aufbewahrungsrichtlinien und Richtlinien-Tags erfahren möchten, empfehlen ich einen Blick in die Exchange Dokumentation zu werfen.

 

Bereinigung der Aufbewahrungsrichtlinien in einem Postfach

Was genau wollen wir eigentlich entfernen?

Es geht um

  • Richtlinien-Tags

Zugewiesene Aufbewahrungsrichtlinien zu entfernen ist einfach. Weisen Sie dem Postfach eine andere Richtlinie zu oder setzen Sie den Parameter RententionPolicy auf $null. Damit werden allerdings nicht die persönlichen Tags, die ein Benutzer Postfach-Ordnern zugewiesen hat, entfernt.

Wie wird man nun die persönlichen Tags los? Microsoft hat hierauf eine einfache Antwort:

  • Löschen Sie die Tags aus der Exchange Organisation

Aber was passiert, wenn das zu entfernende Tag von anderen Benutzern in Ihrer Exchange Organisation ebenfalls verwendet wurde? In diesem Fall würde es aus allen Postfächern entfernt.

Mal angenommen, Sie haben eine Lösch-Richtlinie, die aus Compliance-Gründen alles älter 10 Jahre löscht. Sie haben dem Benutzer mit einem persönlichen Tag die Möglichkeit gegeben einzelne Ordner vom Löschen auszunehmen. Wenn Sie nun dieses persönliche Tag aus der Exchange Organisation entfernen, werden Sie ein nicht zu vernachlässigendes Supportaufkommen in Ihrer Hotline generieren. Der Managed Folder Assistant wird E-Mail-Nachrichten (älter 10 Jahre) aus allen Ordnern aller Postfächer löschen, an denen das persönliche Tag gesetzt war. Nicht davon zu sprechen, das sie diese dann wiederherstellen müssen.

 

Die Lösung

Zum Glück ist Hilfe nah. Das Tool RemovePersonalRetentionTag hilft Ihnen bei der selektiven Entferung von Richtlinien-Tags.

 

Mit diesem Tool können Sie eine oder mehrere persönliche Tags von Ordnern eines Postfaches entfernen, ohne diese aus der Exchange Organisation löschen zu müssen.

Dazu gibt es zwei Voraussetzungen. Sie müssen Impersonation-Rechte für das Postfach besitzen, in welchem Sie die Tags entfernen möchten. Wenn sich das Postfach in Exchange Online befindet, muss in einer Exchange Online Umgebung die Basic-Authentifizierung aktiviert sein, da das Tool über Exchange Web Services auf Postfächer zugreift.

  • Wenn Sie alle persönlichen Tags eines Postfaches von den Ordnern entfernen möchten reicht ein:
RemovePersonalRetentionTag.exe -mailbox "user@example.com" -impersonate

 

  • Wenn Sie bestimmte Tags löschen möchten, benötigen Sie die zugehörige RetentionID. Diese erhalten Sie in einer Exchange (Online) Powershell Sessoin mit folgendem Einzeler:
Get-RetentionPolicyTag -Types Personal | Select Name,RetentionId | ft -a

Screenshot Exchange Management Shell

 

  • Löschen Sie einzelne Tags mit:
RemovePersonalRetentionTag.exe -mailbox "user@example.com" -impersonate -retentionid "a7966968-dadf-4df7-ae87-4482686b4634"

 

  • Entfernen Sie mehrere Tags mit:
RemovePersonalRetentionTag.exe -mailbox "user@example.com" -impersonate -retentionid "a7966968-dadf-4df7-ae87-4482686b4634, 414c6a14-3ed5-432e-9edb-c6620a8278f0"

 

Das Tool kann auch dabei helfen, persönliche Tags von Systemordnern, wie zum Beispiel „Yammer“, zu entfernen.

 

 

Weiterlesen »

Photo by Max DeRoin from PexelsDas Blog Cumulative Update für Februar 2021 (CU0221) fasst interessante Themen rund um Cloud SicherheitExchange ServerOffice 365, Microsoft Teams und Azure des Monats Februar 2021 zusammen.

Allgemein

 

Logo Exchange Server 2019Exchange Server

 

Logo Office 365Microsoft 365 | OneDrive | Exchange Online | and more

 

Logo Microsoft TeamsMicrosoft Teams

 

Logo Microsoft AzureMicrosoft Azure

 

Cloud | Cloud Sicherheit

 

Logo Microsoft LearnMicrosoft Training

 

Microsoft Docs | Tech Community | Knowledge Base

 

Logo Skype for BusinessSkype for Business Server | Communications

 

Replay

 

Podcast Empfehlungen

 

Tools

 

 


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

 

Weiterlesen »