The following PowerShell scripts have been published by our Exchange and Office 365 experts to the technical community at TechNet Gallery. Please use the GitHub repositories to report issues or to file feature requests.

General

• GlobalFunctions Module
  A module to provide centralized logging capabilities. This script is a *must have* for other Exchange 2013/2016/2019 modules if mentioned in the notes section of the script.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/210/globalfunctions-shared-powershell-library
  • PowerShell Gallery: https://www.powershellgallery.com/packages/GlobalFunctions

Office 365

• Test Office 365 Domain Availability
  Using this script you can test the domain availability in Office 365 and Azure AD.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/296/test-office-365-domain-availability 
  • Github: https://github.com/Apoc70/Test-DomainAvailability 
     
• Test thumbnailPhoto for Azure AD guest users
  Using this script you can update the default guest user profile photo.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/1708/set-thumbnailphoto-for-azure-ad-guest-users 
  • Github: https://github.com/Apoc70/Set-GuestUserPhoto 

Exchange Server 2013 / 2016 / 2019

• Exchange Environment Report v2
  This script creates an HTML report showing the following information about an Exchange 2019, 2016, 2013, 2010, and, to a lesser extent, 2007 and 2003 environment.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/1718/exchange-environment-report-v2
  • Github: https://github.com/Apoc70/Get-ExchangeEnvironmentReport
     
• Report for enabled client protocols
  This script gathers a list of enabled users for a selected Exchange Server client protocol.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/1815/report-for-enabled-client-protocols
  • Github: https://github.com/Apoc70/Get-EnabledProtocolReport
     
• Export delegate and SMTP forwarding information for Exchange (Online) mailboxes
  PowerShell script to export mailbox delegates, SMTP forwarding inbox rules, and mailbox SMTP forwarding information or compliance auditing.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/1693/export-mailbox-delegates-and-smtp-forwarding-information
  • Github: https://github.com/Apoc70/Get-DelegatesAndForwardingRules
     
• Manage Master Category List for Shared Mailboxes and Teams
  C# solution to export/import/copy the master category list to other users/shared mailboxes or even Microsoft Teams calendar.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/1423/manage-master-category-list-for-shared-mailboxes-and-teams
  • Github: https://github.com/Apoc70/MailboxCategoryListManager
     
• Create a new Room Mailbox with Security Groups
  A script to create a new room mailbox with associated full access and/or send-as security groups.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/337/create-a-new-room-mailbox-with-security-groups
  • Github: https://github.com/Apoc70/New-RoomMailbox
     
• Export all user mailbox permissions
  This script exports all mailbox folder permissions for mailboxes of the type UserMailbox. This is useful for documentation purposes prior to migration.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/219/export-all-user-mailbox-folder-permissions 
  • Github: https://github.com/Apoc70/Get-MailboxPermissionReport 
     
• Remove Out-Of-Office rules from user mailbox
  This script searches for OOF rules created by users using the Outlook rule-tab in the OOF assistant and deletes existing OOF rules.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/328/remove-out-of-office-rules-from-user-mailbox 
  • Github: https://github.com/Apoc70/Manage-OOF-Settings 
     
• Add resized user photos automatically
  This script supports resizing of user photos and storing the resized images in Active Directory, Exchange On-Premises, or Exchange Online.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/307/add-resized-user-photos-automatically 
  • Github: https://github.com/Apoc70/Set-UserPictures 
     
• Parse email messages content for further processing
  This script fetches emails from a given monitoring mailbox by searching email messages for a given subject string.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/322/parse-mailcontent 
  • Github: https://github.com/Apoc70/Parse-MailContent 
     
• Update OWA vDir config across multiple servers
  This script checks multiple Exchange Server 2013 OWA web.config files for the existence of IMCertificateThumbprint and IMServerName XML nodes required for Skype for Business OWA integration.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/301/update-owa-vdir-webconfig-across-multiple-exchange-servers 
  • Github: https://github.com/Apoc70/Set-OwaIMSettings 
     
• Remove Orphaned HealthMailbox and SystemMailbox Accounts from MESO Container
  This script removes Active Directory objects for HealthMailboxes or SystemMailboxes in the Microsoft Exchange System Objects (MESO) container that do not have a homeMDB attribute set.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/297/remove-orphaned-healthmailbox-and-systemmailbox-accounts-from-meso-container 
  • Github: https://github.com/Apoc70/Remove-OrphanedMailboxAccounts 
     
• Connect to Exchange Server 2013+ using remote PowerShell
  This script connects to a dedicated or a randomly selected Exchange Server using remote Powershell.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/293/connect-to-exchange-server 
  • Github: https://github.com/Apoc70/Connect-ToExchange 
     
• Create Exchange internal/external Url based certificate requests
  This script helps to create certificate requests (CSR) based on hostnames used for internal and external URLs of Exchange Server virtual directories.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/290/create-exchange-internalexternal-url-based-certificate-requests 
  • Github: https://github.com/Apoc70/Create-CertificateRequest  
     
• Export Messages from Transport Queue
  Script to suspend and export messages from a transport queue.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/282/export-messages-from-message-queue 
  • Github: https://github.com/Apoc70/Export-MessageQueue  
     
• Simple import of multiple PST files for a single user
  A script to simplify the import of multiple PST files for a single user.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/234/simple-import-of-multiple-pst-files-for-a-single-user
  • Github: https://github.com/Apoc70/Start-MailboxImport
     
• Create a new Team Mailbox with Security Groups
  A script to create a new shared mailbox with associated full access or send-as security groups.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/239/create-a-new-team-mailbox-with-security-groups
  • Github: https://github.com/Apoc70/New-TeamMailbox
     
• Find and remove corrupt HealthMailboxes
  Script to find and remove or disable Exchange Server 2013 HealthMailboxes
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/212/find-and-remove-corrupt-healthmailboxes
  • Github: https://github.com/Apoc70/Fix-HealthMailboxes
     
• Change IIS Log File Settings
  Script to configure IIS log file location and other log file settings, especially for Exchange Server 2013/2016
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/220/change-iis-log-file-settings
  • Github: https://github.com/Apoc70/Set-Webserver
     
• Purge Exchange Server 2013/2016/2019 and IIS Log Files
  Script to purge Exchange Server 2013/2016/2019 and IIS log file remotely from a managing or job server
  • Blog: https://www.granikos.eu/de/justcantgetenough/PostId/208/purge-exchange-server-and-iis-log-files
  • Github: https://github.com/Apoc70/Purge-LogFiles
     
• Send emails for Transport Agent and Transport Rule testing
  A script for sending a defined number of emails of a certain type having a specific attachment for the testing of Transport Agents and Transport Rules
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/215/send-test-emails-to-validate-transport-rules-or-transport-agents
  • Github: https://github.com/Apoc70/Send-TestMail
     
• Copy a receive connector from one Exchange 2013 Server to multiple Exchange Servers
  Script to copy a configured Exchange Server 2013/2016/2019 receive connector from a source server to additional Exchange 2013/2016/2019 servers.
  • Github: https://github.com/Apoc70/Copy-ReceiveConnector
     
• Add remote IP-address ranges to an existing receive connector
  Add remote IP address ranges to an Exchange Server 2013/2016/2019 receive connector.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/222/add-remote-ip-address-ranges-to-a-receive-connector
  • Github: https://github.com/Apoc70/Add-ReceiveConnectorIpAddress
     
• Copy anti-virus pattern to Exchange 2010/Exchange 2013 servers
  Script to copy anti-virus pattern files from a given source location to multiple Exchange 2010/Exchange 2013 servers
  • Github: https://github.com/Apoc70/Copy-AntiVirusPattern
     
• Gather Exchange Configuration Data
  Script to gather Exchange Org configuration data and export the configuration as text/CSV files
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/287/gather-exchange-configuration-data
  • Github: https://github.com/Apoc70/Get-ExchangeOrganizationDetails 
     
• Create a scheduled task for Exchange Server 2013+
  This script adds a new scheduled task for an Exchange Server 2013+ environment in a new task scheduler group "Exchange".
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/218/create-a-scheduled-task-for-exchange-server-2013
  • Github: https://github.com/Apoc70/New-ScheduledExchangeTask 
     
• Fetch all remote SMTP servers from Exchange receive connector logs
  This scripts fetches remote SMTP servers by searching the Exchange receive connector logs for the EHLO string.
  • Blog: -
  • Github: https://github.com/Apoc70/Get-RemoteSmtpServers
     
• Clear Private Flag on Mailbox Messages
  C# Executable to clear an item's private flag after migrating public folder content to a shared mailbox.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/303/clear-private-flag-on-mailbox-messages
  • Github: https://github.com/Apoc70/RemovePrivateFlag 
     
• Set Mailbox Item Private Flag
  C# Executable to set an item's private flag after migrating public folder content to a shared mailbox from a legacy mailbox system.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/379/set-mailbox-item-private-flag
  • Github: https://github.com/Apoc70/SetPrivateFlag 

Exchange Server 2007/2010

• Fetch recently created public folders
  This script gathers all public folders created during the last X days and exports the gathered data to a CSV file
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/304/fetch-recently-created-public-folders
  • Github: https://github.com/Apoc70/Get-NewPublicFolders
     
• Remove orphaned users and groups from legacy public folder ACLs
  Cleanup legacy public folder ACLs by removing orphaned other unproperly configured accounts
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/263/clean-legacy-public-folder-acl
  • Github: https://github.com/Apoc70/Clean-PublicFolderACL
     
• Exchange 2010 Public Folder Replication Report (UTF8 support)
  An updated version of the script originally posted by Mike Walker to support public folder with non-ASCII characters
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/211/exchange-public-folder-replication-report
  • Github: https://github.com/Apoc70/Get-PublicFolderReplicationReport
  • Original Post at TechNet Gallery: https://gallery.technet.microsoft.com/office/Exchange-2010-Public-944df6ee
     
• Add multiple legacy public folder replicas recursively
  Script to get more control of adding legacy public folder replicas recursively
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/217/add-multiple-legacy-public-folder-replicas-recursively
  • Github: https://github.com/Apoc70/Add-PFReplica

Other Stuff

• Convert Word documents using PowerShell
  This script converts Word compatible documents to a selected format utilizing the Word SaveAs function. Each file is converted by a single dedicated Word COM instance.
  • Blog: https://www.granikos.eu/en/justcantgetenough/PostId/353/convert-word-documents-using-powershell
  • Github: https://github.com/Apoc70/Convert-WordDocument

Please send comments, wishes, and ideas to support@granikos.eu.

Enjoy!

Need assistance with your Exchange Server Organization? You plan to upgrade your Exchange Server Organization? You plan to migrate to Office 365? Contact us: info@granikos.eu

Updates

Update 2020-10-05: Fetch all remote SMTP servers from Exchange receive connector logs added
Update 2020-05-25: TechNet Gallery links removed due to end of TechNet Gallery in mid-2020
Update 2020-02-07: Report for enabled client protocols, Exchange Environment Report - v2, Set thumbnailPhoto for AzureAD guest users added
Update 2019-05-07: Export mailbox delegates and SMTP forwarding information added
Update 2018-09-04: Add remote IP-address ranges to a receive connector added
Update 2018-06-16: Manage Master Category List for Shared Mailboxes and Teams added
Update 2018-04-29: Convert Word documents using PowerShell and Set Mailbox Item Private Flag added
Update 2018-01-24: Create a new Room Mailbox with Security Groups added
Update 2017-11-11: Export all user mailbox permissions added
Update 2017-09-22: Remove Out-Of-Office rules from user mailbox added
Update 2017-05-20: Parse email messages content for further processing and Update OWA vDir config across multiple servers added
Update 2017-03-18: Fetch recently created public folders and Clear Private Flag on Mailbox Messages added
Update 2017-02-22: Remove Orphaned HealthMailbox and SystemMailbox Accounts from MESO Container added
Update 2017-02-17: Test Office 365 Domain Availability added
Update 2017-02-13: Connect to Exchange Server 2013+ using remote PowerShell added
Update 2017-02-07: Create Exchange internal/external Url based certificate requests, Create a scheduled task for Exchange Server 2013 added
Update 2017-01-24: Gather Exchange Configuration Data added
Update 2017-01-05: Export Messages from Transport Queue added
Update 2016-11-29: Clean legacy public folder ACL added, Scripts categorized
Update 2016-11-28: Add multiple legacy public folder replicas added
Update 2016-08-18: Simple import of multiple PST files for a single user added
Update 2016-07-28: Change IIS Log File settings Github Url added, Create a new Team Mailbox with Security Groups added
Update 2016-06-04: GlobalFunctions added
Update 2015-06-18: Copy-ReceiveConnector updated
Update 2015-06-01: Exchange 2010 Public Folder Replication Report (UTF8 support)
Update 2015-05-21: Copy anti-virus pattern to Exchange 2010/Exchange 2013 servers added
Update 2014-12-10: Copy a receive connector from one Exchange Server to multiple Exchange Servers added

Exchange Server 2019 ist die aktuelle Version der E-Mail-Messaging Plattform für die Installation in der lokalten IT-Infrastruktur (aka On-Premises). Als lokale Infrastruktur gilt auch die Nutzung von Exchange Server 2019 auf virtualisiserten Serversystemen in Microsoft Azure. Bei Microsoft handelt sich, technisch gesehen, nur um ein ausgelagertes Rechenzentrum. Als wirkliche Alternative zu einem eigenen Betrieb von Exchange Server 2019 steht Ihnen Exchange Online, als Bestandteil des Software-as-a-Service Angebotes von Office 365, zur Verfügung.

Der Betrieb von Exchange Server 2019, die hybride Verbindung zwischen einer lokalen Exchange Organisation und Exchange Online oder die alleinige Nutzung von Exchange Online erfordern eine detaillierte Planung und Vorbereitung. 

Auf dieser Seite finden Sie die wichtigsten Referenz-Links zu Online Ressourcen von Microsoft und anderen Quellen, um das für Sie richtige Exchange Produkt zu installieren, einzurichten und zu betreiben.

Planung einer Exchange Organisation

Wie einleitend schon ausgeführt, kann Exchange grundsätzlich in vier unterschiedlichen Architekturmodellen betrieben werden, die ihre ganz individuellen Vor- und Nachteile bieten. Diese sind:

• Exchange Online (SaaS)
  Hierbei wird Exchange als integraler Bestandteile des SaaS-Angebotes von Office 365 verwendet. Sie nutzen  hierbei immer die aktuellste Version von Exchange Server.
   
• Exchange Hybrid
  Hierbei werden eine lokale Exchange Organisation und Exchange Online parallel betrieben und sind bidirektional miteinander verbunden. Beide Umgebungen können mit der jeweils anderen Umgebung kommunizieren und auf Inhalte.
   
• Exchange Server in Azure (IaaS)
  Hier agiert Azure als Erweiterung Ihrer internen IT-Infrastruktur. Sie betreiben in Azure virtuelle Serversysteme und betreiben dort Exchange Server Systeme. Diese Systeme können auch in einer Hybrid-Anbindung mit Exchange Online betrieben werden. 
   
• Exchange On-Premises
  Dies entspricht einer klassischen Exchange Organisation mit Exchange Server Systemen, die Sie auf Ihren eigenen Serversystemen, virtualisiert oder physikalisch, betreiben.

IT-Responsibility	Exchange Online	Exchange Hybrid	Azure IaaS	On-Premises
Data Governance und Rechtemanagement
Client Endpunkte
Benutzerkonten- und Zugriffsverwaltung
Identitäten und Active Directory Infrastruktur
Netzwerk
Applikationen
Betriebssystem
Physikalische Host-Systeme
Physikalisches Netzwerk
Physikalische Rechenzentren

 = kontrolliert durch Microsoft
 = kontrolliert durch Kunden

• Exchange Server-Unterstützbarkeitsmatrix
• Exchange Server build numbers and release dates
• Exchange-Processor Query Tool: PowerShell Edition
• Exchange Server 2016 Role Requirements Calculator
• Processor Query Tool v1.1
• Outlook license requirements for Exchange features
• Modern public folder deployment best practices

Installation

• Exchange Server 2019 Installationsvoraussetzungen
  Unterstützt sind immer jeweils das aktuelle CU und die beiden vorherigen CUs)
  • Übersicht der Voraussetzungen
  • Visual C++ Redistributable Packages for Visual Studio 2013
  • Microsoft .NET Framework 4.7.2 (Offline-Installer) (RTM, CU1, CU2, CU3)
  • Microsoft .NET Framework 4.8 (Offline-Installer) (CU2 +)
  • Microsoft Unified Communications Managed API 
    • Bestandteil des Exchange Server 2019 Installationsmediums

• Exchange Server 2016 Installationsvoraussetzungen
  Unterstützt sind immer jeweils das aktuelle CU und die beiden vorherigen CUs)
   
  • Übersicht der Voraussetzungen
  • Visual C++ Redistributable for Visual Studio 2012
  • Visual C++ Redistributable Packages for Visual Studio 2013
  • 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 installation of the .NET Framework 4.7 
  • Microsoft .NET Framework 4.7.1 (Offline Installer) (CU8, CU9, CI10, CU11, CU12)
  • Microsoft .NET Framework 4.7.2 (Offline-Installer) (CU11, CU12, CU13, CU14)
  • Microsoft .NET Framework 4.8 (Offline-Installer) (CU13 +)
  • Microsoft Unified Communications Managed API 4.0, Core Runtime 64-bit
    • Exchange Server 2019 ISO beinhaltet einen angepassten UCMA-Installer
       

Betrieb

Der Betrieb und die vollständige Verwaltung von Exchange Server erfordern die Verwendung der Exchange Management Shell (EMS). Mit Hilfe des browserbasierten Exchange Admin Center (EAC) können Sie Gelegenheitsaufgaben durchführen. Dies gilt für Exchange Server 2019 ebenso wie für Exchange Online.

• Exchange PowerShell auf Microsoft Docs
• Exchange Online PowerShell Modul mit MFA (Click-to-Run Installation, erfordert für den ausführenden Rechner eine direkte Verbindung ins Internet)
• Sammlung an PowerShell-Skripten für Exchange Server und Exchange Online
• Exchange Server 2019 - Das Handbuch für Administratoren
   
• Exchange Berechtigungen
• Exchange Empfängerobjekte
• Clients und mobile Geräte
• Nachrichtenfluss und Transport-Pipeline
• E-Mail-Adressen und Adressbücher
• Hohe Verfügbarkeit und Ausfallsicherheit

Exchange Online

• Exchange Online Protection IP Addresses

Hybrid Betrieb

• Exchange Hybrid Deployments
• Hybrid Deployment Procedures

Administration

• Add-Ins
  • Specify the administrators and users who can install and manage add-ins for Outlook
  • Add-ins for Outlook in Exchange Online
  • Manage deployment of Office 365 add-ins in the Microsoft 365 admin center

Präsentationen

Migrationswege zu Exchange Server 2019

Exchange Server 2019 MetaCache Datenbank und BIgFunnel

Viel Spaß mit Exchange Server 2019 und Exchange Online.

Sie benötigen Hilfe bei der Planung und Installation Ihrer Exchange Server Installation? Sie haben Fragen über Ihre bestehende Exchange Server Infrastruktur und möchten Exchange Online implementieren? Kontaktieren Sie uns per E-Mail info@granikos.eu oder besuchen Sie unsere Webseite http://www.granikos.eu

Am 19. November traf sich die Exchange User Group in einem Microsoft Teams Meeting. 

Die Themen waren

• Exchange Server vNEXT - Thomas Stensitzki
  • Was erwartet uns mit der nächsten Version von Exchange Server?
• Änderungen in der Exchange User Group - Evgenij Smirnov / Thomas Stensitzki
  • Nicht nur ein neues Logo, auch der Scope der EXUSG ändert sich
• Exchange Server & Outlook Cabaret - Evgenij Smirnov / Thomas Stensitzki
  • Exchange Server und Outlook Worst Practices  

Die Exchange User Group erweitert ihren Fokus von Berlin auf den deutschsprachigen Raum. Meetups werden, wie bisher, in Berlin abgehalten. Die Planung ist, in der Zukunft hybride Meetups abzuhalten. Weitere Details hierzu gibt es dann auf der Homepage der Exchange User Group.

Dies ist die Präsentation zu Exchange Server vNEXT und den Änderung in der Exchange User Group.

Links

• Präsentation
• Homepage der Exchange User Group
• Exchange User Group bei Twitter

Was bedeutet Exchange Server Hybrid?

Eine lokale Exchange Organisation eines Unternehmens kann mit Exchange Online, einer der Kernbestandteile von Microsoft 365, verbunden werden. Diese Verbindung erfolgt durch die sog. Hybrid-Konfiguration und ist eine besondere Vertrauensstellung zwischen zwei technisch getrennten Exchange Umgebungen.

Diese besondere Vertrauensstellung zwischen der lokalen Exchange Organisation und Exchange Online ist notwendig, damit E-Mail- und System-Nachrichten, die zwischen beiden Umgebungen unsgetauscht werden, als interne E-Mail-Nachrichten erkannt und verarbeitet werden. Nur so ist es möglich, die korrekte Funktion aller Exchange Komponenten, unabhängig vom Bereitstellungsort der Benutzerpostfächer, zu gewährleisten.

Welche Vorteile ein Exchange Hybrid-Betrieb für die Exchange Umgebung in Ihrem Unternehmen hat, erfahren Sie in diesem Microsoft Docs Artikel.

Das folgende Schaubild verdeutlicht die Hybrid-Konfiguration und die besondere Vertrauensstellung (gepunktete grüne Linie).

Eine Exchange Hybrid-Konfiguration richten Sie mit Hilfe des Hybrid Confguration Wizard (HCW) ein. Während der HCW-Einrichtung müssen Sie sich für eine der zur Verfügung stehenden Möglichkeiten für den Hybrid-Betrieb entscheiden.

Welche Optionen für den Hybrid-Betrieb gibt es?

Für den Hybrid-Betrieb einer lokalen Exchange Organisation mit Exchange Online gibt es mehrere Möglichkeiten. Wir unterscheiden zwei grundlegende Betriebsvarianten, den klassischen und den modernen Hybrid-Betrieb. Für diese beiden Varianten stehen je bis zu drei Betriebsmodi zur Verfügung.

Das folgende Schaubild verdeutlich die unterschiedlichen Betriebsmodi für die beiden Betriebsvarianten einer Hybrid-Konfiguration.

Nun stellt sich automatisch die Frage, welchen Betriebsmodus soll ich für Hybrid-Konfiguration meiner Exchange Organisation verwenden?

Schauen wir uns zuerst an, welche technischen Voraussetzungen die beiden Betriebsvarianten haben.

Klassischer Hybrid-Betrieb

Der klassische Hybrid-Betrieb erfordert, dass interne Exchange Server aus dem Internet über das Protokoll HTTPS erreichbar sind. Über diese Verbindung erfolgt die Kommunikation von Exchange Online zur internen Exchange Organisation für Hybrid-Funktionen. Damit einher geht die Anforderung für eine aus dem Internet erreichbare IP-Adresse und die Verwendung eines offiziellen TLS-Zertifkates.

Moderner Hybrid-Betrieb

Der moderne Hybrid-Betrieb erfordert keinerlei eingehende HTTPS-Verbindung von Exchange Online zur internen Exchange Organisation. 

Die Verbindung zwischen der lokalen Exchange Organisation und Exchange Online erfolgt über den Exchange Hybrid Agent. Die Software für den Exchange Hybrid Agent ist als Dienst auf einem Server installiert und verbindet sich über eine ausgehende HTTPS-Verbindung mit Exchange Online. Die Konfiguration durch den HCW steuert hierbei das Verhalten von Exchange Online. Mit Blick auf den Hybrid-Betrieb von Exchange ist dies die bevorzugte und schnellste Betriebsvariante, da keinerlei zusätzliche Komponenten für eingehende HTTPS-Verbindungen benötigt werden. Wenn Ihr Unternehmen jedoch Microsoft Teams verwenden möchte und weiterhin Postfächer von Teams-Anwendern auf lokalen Exchange Servern betrieben werden sollen, können Sie diese Betriebsvariante nicht nutzen. Microsoft Teams unterstützt für dieses Betriebsszenario nur den klassischen Hybrid-Betrieb.

Klassicher und Moderner Hybrid-Betrieb

• Beide Betriebsvarianten benötigen für den hybriden Nachrichtenfluss ein- und ausgehende SMTP-Verbindungen zwischen der lokalen Exchange Organisation und Exchange Online.
   
• Beide Betriebsvarianten erfordern ausgehende HTTPS-Verbindungen zu Exchange Online von den internen Exchange Server Systemen.

Für welches Betriebs- und Migrationsszenario passen die fünf Betriebsmodi?

		Vollwertige, klassische Hybrid-Konfiguration mit direkter Veröffentlichung der Exchange Organisation ins Internet (SMTP/HTTPS) Dauerhafter Hybrid-Betrieb Postfächer On-Premises und in Exchange Online
		Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online Temporärer Hybrid-Betrieb über wenige Monate Ziel: Migration aller Postfächer zu Exchange Online
		Hybrid-Konfiguration, inkl. Azure AD Connect Express Setup, zum einmaligen Verschieben aller Postfächer zu Exchange Online Temporärer Hybrid-Betrieb über wenige Tage oder Wochen Ziel: Migration aller Postfächer zu Exchange Online
		Vollwertige, klassische Hybrid-Konfiguration für neue Konfigurationen mit Hilfe des Exchange Hybrid-Agenten, jedoch mit Funktionseinschränken Dauerhafter Hybrid-Betrieb Postfächer On-Premises und in Exchange Online
		Hybrid-Konfiguration, inkl. Azure AD Connect, zum einmaligen Verschieben aller Postfächer zu Exchange Online mit Hilfe des Exchange Hybrid-Agenten Temporärer Hybrid-Betrieb über wenige Monate MIgration aller Postfächer zu Exchange Online

Herausforderungen

Die Implementierung eines Hybrid-Betriebes stellt Ihr Unternehmen vor technische Herausforderungen. Daher muss die Einrichtung des hybriden Exchange Betriebes gut geplant werden.

Für den klassischen Hybrid-Betrieb benötigen Sie externe IP-Adressen für die beiden Protokolle HTTPS und SMTP, während für den modernen Hybrid-Betrieb nur eine IP-Adresse für das Protokoll SMTP benötigt wird. Ebenso benötigen Sie TLS-Zertifikate. Für den Nachrichtenfluss zwischen der lokalen Exchange Organisation und Exchange Online empfehle ich, ein separates TLS-Zertifikat zu verwenden, das nicht für das E-Mail-Internet-Gateway verwendet wird. 

Die Absicherung der internen Exchange Server vor direkten Zugriffen aus dem Internet hat höchste Priorität. Sichern Sie den E-Mail-Nachrichtenfluss der hybriden Verbindung zwischen der lokalen Exchange Organisation und Exchange Online mit Exchange Edge-Servern ab. Der HTTPS-Zugriff zu den internen Exchange Server von Exchange Online wird über Reverse-Proxies abgesichert.

Bei einem dauerhaften Hybrid-Betrieb ist die lokale Exchange Organisation für die Verwaltung der zu Exchange Online verschobenen Exchange-Objekte zuständig. Im Zusammenspiel mit dem lokalen Active Directory bleibt sie die Source of Authority (SOA). Aus diesem Grund benötigen Sie mindestens einen verbleibenden lokalen Exchange Server, der als sog. Koexistenz-Server betrieben wird. Hierzu sollten Sie einen System mit Exchange Server 2016 oder Exchange Server 2019 verwenden.

Fazit

Mit einer Auswahl von zwei Betriebsvarianten und insgesamt fünf Betriebsmodi fällt es nicht leicht, die passende Wahl zu treffen. Die wichtigste Frage, die Sie sich zuerst stellen müssen ist, wie soll die Bereitstellung von Exchange Funktionen in Zukunft für das Unternehmen aussehen und welche Anforderungen hat das Unternehmen im Hinblick auf die Absicherung von E-Mail-Nachrichten? Sind Anwender-Postfächer in der lokalen Exchange Organisation bereitgestellt und in Ihrem Unternehmen soll Microsoft Teams genutzt werden, so ist die klassische Voll-Hybrid-Variante die einzige Option.

Die größte Flexibilität erreichen Sie mit dem klassischen Hybrid-Betrieb, jedoch ist dies auch die Variante mit den meisten Anforderungen zur Einrichtung und den dauerhaften Betrieb.

Mit dem modernen Hybrid-Betrieb erreichen Sie schnell eine Hybrid-Konfiguration und können zügig Postfächer zu Exchange Online migrieren. Bei Nutzung von Microsoft Teams und Anwender-Postfächern in der lokalen Exchange Organisation ist dies jedoch keine Option. 

Links

• Exchange Server Hybridbereitstellungen
• Voraussetzungen für die Hybridbereitstellung
• Einschränkungen für den Exchange Hybrid Agent
• Tech Talk 3: Exchange Hybrid (Video)

Viel Spaß mit einem sicheren Exchange Online.

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

Exchange Server besteht aus zwei Kernkomponenten. Zum einen ist es die Bereitstellung von Postfächern, mit all den benötigten Client-Zugriffsprotokollen und Postfach-Funktionen. Die zweite Komponente ist der Nachrichtenfluss, also der Empfang, die Verarbeitung und der Versand von E-Mail-Nachrichten.

Was sich so einfach und trivial anhört, ist ein zentraler und komplexer Baustein in der Exchange Architektur. In diesem Artikel versuche ich ein wenig Licht ins Dunkel des Exchange Nachrichtenflusses zu bringen. Lassen Sie uns mit einem kurzen Rückblick auf die Exchange Server Architektur beginnen.

Die Exchange Server Architektur

Wer sich den Nachrichtenfluss von Exchange Server anschaut, muss sich immer den Funktionsaufbau eines Exchange Servers und die empfohlene Implementierung im Rahmen der Preferred Architecture (PA) in Erinnerung rufen. In der PA wird Exchange Server immer in einer Konfiguration aus mehreren Exchange Servern, die als Datenbankverfügbarkeitsgruppe (DAG) zusammengefasst sind, betrieben. Hierdurch wird eine hochverfügbare Bereitstellung von Postfachfunktionen und Nachrichtentransport erreicht.

Jeder Exchange Server besteht aus einer Frontend- und Backend-Komponente. Eingehende Verbindungen von Drittsystemen erfolgen immer über die Exchange Frontend-Komponenten. Die Kommunikation mit den Backend-Komponenten erfolgt im Regelfall nur Exchange-intern.

Das folgende Diagramm zeigt den schematischen Aufbau der Verbindungen in einer DAG.

Die Konfigurationen für den Nachrichtenfluss unterteilen sich in organisationsweite und serverbezogene Einstellungen. Die organisationsweiten Einstellungen gelten, wie der Name es schon sagt, für die gesamte Exchange Organisation, ganz unabhängig davon wie viele Exchange Server oder  DAGs Sie betreiben. Ob und wie ein Exchange Server diese Einstellungen verarbeiten kann, hängt von der Produktversion ab. Diese Einstellungen sind vollständig in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Sendekonnektoren.

Serverbezogene Einstellungen wirken sich nur für ein bestimmtes Serversystem aus. Diese Einstellungen werden hauptsächlich ebenfalls in der Konfigurationspartition des Active Directory gespeichert. Ein Beispiel für den Nachrichtenfluss sind die Konfigurationen der Empfangskonnektoren. Einige wenige Einstellungen werden jedoch auch in der lokalen Systemregistrierung gespeichert.

Für den sicheren und stabilen Betrieb von Exchange Server ist eine funktionierende Active Directory Replikation unerlässlich. Hierzu gehört auch eine korrekte Konfiguration der Active Directory Sites. Sie ist gerade in größeren Exchange Organisationen unerlässlich.

Ebenso wichtig ist die korrekte und einheitliche Konfiguration der TLS-Einstellungen auf allen Exchange Servern. Ohne solch eine Konfiguration ist nicht sichergestellt, dass verschlüsselte Verbindungen durch die Empfangs- und Sendekonnektoren aufgebaut werden können. Exchange Server vertraut hier auf die Konfiguration des lokalen Windows Server Betriebssystems und die Bereitstellung gültiger TLS-Zertifikate.

Kommen wir nun zum eigentlichen Thema, dem Exchange Nachrichtenfluss und beginnen mit dem Empfang von E-Mail-Nachrichten.

Der Empfang von Nachrichten

Exchange Server nehmen eingehende E-Mail-Nachrichten über unterschiedliche Wege entgegen. Der bekannteste Weg ist der Empfang über das Protokoll SMTP. Ein Exchange Server unterscheidet hierbei drei unterschiedliche Quelltypen. Im Frontend-Transport erfolgt die Annahme von Verbindungen anderer Server über den Standard TCP-Port 25. Zu den Servern, die sich über diesen Standard SMTP-Port verbinden, zählen:

• Externe E-Mail-Server fremder E-Mail-Domänen, die E-Mail-Nachrichten über das Internet an Ihren Exchange Server senden
• Interne Applikationsserver, die E-Mail-Nachrichten an interne und externe Empfänger senden und einen Exchange Server als sog. Relay-Server verwenden
• Andere interne Exchange Server anderer Produktversionen oder Exchange Server, die in anderen Active Directory Sites platziert sind

Diese Verbindungen erfolgen über den Default Frontend Konnektor, der in seiner Standardkonfiguration nur Nachrichten, die an bekannte Empfänger eigener Domänen entgegennimmt. Die Zustellung von Applikationsnachrichten an externe Empfänger erfordert die Erstellung eines separaten Frontend-Empfangskonnektor.

Zusätzlich zu den Empfangskonnektoren stehen zwei weitere Wege über das lokale Dateisystem des Exchange Servers zur Verfügung, das Pickup- und Replay-Verzeichnis. Beide Verzeichnisse werden vom Backend-Transportdienst, den Sie aus früheren Exchange Versionen sicher noch als Hub-Transport kennen, permanent überwacht und sobald eine Datei dort abgelegt ist, wird sie aufgenommen und verarbeitet. Das Pickup-Verzeichnis dient der Ablage von neuen E-Mail-Nachrichten durch Applikationen. Das Replay-Verzeichnis können Sie nutzen, um Nachrichten, die Sie aus einer Warteschlange exportiert und entfernt haben, erneut in die Verarbeitung zu übergeben.

Zum Schutz vor unberechtigten Verbindungen verwendet Exchange Server unterschiedliche Formen der Authentifizierung. Ergänzend verfügen die Eingangswege über eine Header-Firewall, mit der unberechtigte Informationen aus einer E-Mail-Nachricht herausgefiltert werden.

Der Frontend-Transport verfügt über keine komplexe Business-Logik. Daher ist es wichtig, das Zusammenspiel zwischen Frontend-Transport und Transportdiensten im Backend zu verstehen und sich immer wieder in Erinnerung zu rufen, wenn es zu Problemen kommt. Der Empfangskonnektor im Frontend-Transport nimmt die Verbindung entgegen und führt die Authentifizierung durch. Anschließend wird eine Proxyverbindung zum Transportdienst per TCP-Port 2525 aufgebaut. Hierbei entscheidet nun die Konfiguration Ihrer Exchange Umgebung darüber, wie diese Proxyverbindung erfolgt. Bei einem Einzelserverbetrieb erfolgt die Verbindung zum Transportdienst des gleichen Servers. In einer DAG-Konfiguration wählt der Frontend-Transport den Transportdienst des DAG-Mitgliedservers aus, auf dem in diesem Moment die Datenbankkopie mit dem Postfach des Empfängers aktiv eingebunden ist.

Das folgende Diagramm zeigt das Zusammenspiel zwischen Frontend und Backend beim Empfang von Nachrichten per SMTP.

Beim Empfang einer Nachricht per SMTP versucht Exchange Server die Nachricht ausfallsicher entgegenzunehmen. Zu diesem Zweck erstellt Exchange Server eine Kopie der empfangenen Nachricht und speichert sie als Schattenkopie im Transportdienst eines anderen Exchange Servers. Erst nach dem erfolgreichen Speichern der Schattenkopie und der Speicherung in der lokalen Warteschlange des Backend-Transportdienstes, meldet der empfangende Exchange Server dem sendenden Server eine OK-Meldung.

Auf einem Exchange Server können mehrere Empfangskonnektoren für den gleichen Port konfiguriert werden. Wenn Sie weitere Konnektoren für den gleichen Port erstellen, müssen Sie festlegen, wie Exchange Server einen Konnektor auswählen soll. Am einfachsten ist hier die Konfiguration der IP-Adressen des absendenden Systems als Remote IP-Adresse am Konnektor.

Im Backend des Exchange Servers befinden sich zwei Transportdienste. Der wichtigste Dienst ist der Transportdienst, den manche von Ihnen sicher noch als Hub-Transport aus älteren Versionen von Exchange Server kennen. Diesen Dienst schauen wir uns im nächsten Abschnitt einmal genauer an. Der zweite Dienst ist der Postfachtransportdienst. Dieser Dienst hat die Aufgabe, eingehende Nachrichten in Postfächern lokal eingebundener Datenbanken zu speichern und Nachrichten, die versendet werden sollen, aus Postfächern lokaler Datenbanken zu lesen und zur weiteren Verarbeitung an den Transportdienst zu übermitteln. Diesen Dienst beschreibe ich in einem zukünftigen Artikel.

Der einfach erscheinende Empfang einer E-Mail-Nachricht ist, aus Gründen der Nachrichtensicherheit und zum Schutz vor dem Ausfall eines Systems, eine komplexe Aufgabe. Nach dem Empfang der Nachricht muss sie verarbeitet werden.

Die Verarbeitung von Nachrichten

Die gesamte Verarbeitung von E-Mail-Nachrichten erfolgt im Transportdienst und ist Warteschlangen-basiert, mit der Betonung auf „Warte“. Eine empfangene E-Mail-Nachricht wird in der Submission-Warteschlange gespeichert und wartet dort darauf, zur sog. Kategorisierung aufgegriffen zu werden. In der Categorizer-Komponente erfolgt die Hauptarbeit des Transportdienstes. Zu den Aufgaben gehören:

• Auflösung der Empfängeradressen
• Entscheidung über das Routing der Nachricht, auf Basis der in diesem Moment geltenden Topologie-Informationen
• Konvertierung des Nachrichteninhaltes
• Aufteilung der Nachricht in weitere Nachrichten
  • Aufteilung der Nachricht an mehrere Empfänger
  • Auflösung der Empfänger einer adressierten Verteilerliste
• Paketierung der Nachricht oder Nachrichten zur Zustellung
• Erstellung von Delivery Status Notifications (DSN)

Nach der Verarbeitung im Categorizer ist die Nachricht bereit zur weiteren Zustellung und wird hierzu in einer passenden Warteschlange gespeichert. Der Transportdienst legt für jedes Zustellungsziel eine separate Warteschlange an. Dies ist der Grund, warum Sie immer eine unterschiedliche Anzahl an Warteschlangen auf einem Exchange Server sehen. Die Warteschlangen gliedern sich in unterschiedliche Kategorien:

• Lokale Zustellung an eine aktive Postfachdatenbankkopie, die das Postfach des Empfängers beinhaltet
• Remote Zustellung an eine aktive Postfachdatenbankkopie in der gleichen DAG, die das Postfach des Empfängers beinhaltet
• Remote Zustellung an einen beliebigen Mitgliedsserver einer anderen DAG zur weiteren Zustellung an Postfächer in dieser DAG
• Zustellung an einen konfigurierten Exchange Server eines Sendekonnektors eines Zieladressraumes
• Zustellung an Remote-Domänen über einen definierten Smarthost
• Zustellung an Remote-Domänen mit DNS-basierter MX-Auflösung für die Ziel-Domäne

Zur Speicherung der Warteschlangen verwendet der Transportdienst auf jedem Exchange Server eine eigene Datenbank. In dieser Datenbank werden alle Nachrichten mit ihrem jeweiligen Verarbeitungs- und Zustellungsstatus gespeichert. Der Transportdienst kümmert sich eigenständig um den Funktionsstatus der Datenbank. Kommt es zu einem nicht behebbaren Fehler, wir eine komplett neue Datenbank erstellt und die korrupte Datenbank in einen neuen Ordner verschoben.

Das folgende Schaubild zeigt die Hauptkomponenten zur Verarbeitung von E-Mail-Nachrichten im Exchange Transportdienst.

Leider steht uns für die aktuelle Version Exchange Server kein detailliertes Diagramm des Transportdienstes offiziell zur Verfügung. Im Microsoft Download Center steht das Diagramm von Exchange Server 2010 zur Verfügung und bietet einen guten konzeptionellen Überblick über den Transportdienst. Achten Sie auf die Unterschiede zu modernen Exchange Server Versionen.

Das Routing von Nachrichten

Anwender leben in der Illusion, dass die Zustellung von E-Mail-Nachrichten eine einfache Sache ist und haben meist kein Verständnis für eine verzögerte Zustellung von Nachrichten. In Zeiten von Gigabit-Leitungen und schier unerschöpflicher Computer-Ressourcen hat man sich daran gewöhnt, dass Nachrichten nahezu in Echtzeit übertragen werden.

Einen wesentlichen Beitrag zu einer schnellen und fehlerfreien Verarbeitung leistet das korrekte Routing einer E-Mail-Nachricht. Damit eine Nachricht von Exchange Server fehlerfrei verarbeitet und zugestellt werden kann, ist eine fehlerfreie Active Directory Gesamtstruktur unerlässlich. Die im Exchange Transportdienst aktiven Routing-Agenten arbeiten mit den Informationen, die im Active Directory gespeichert sind. Dies sind u.a.:

• Adressen von Exchange Empfängerobjekten
  • Inkonsistente, fehlerhafte Einträge und identische Einträge an mehreren Objekten sind eine häufige Fehlerquelle
  • Verwaiste Objekte von E-Mail-aktivierten Öffentlichen Ordner gehören ebenso zu den Fehlerquellen
• Konfiguration der Exchange Organisation
  • Verwaiste Server- und Konnektoreinstellungen durch nicht korrekt durchgeführte Deinstallationen können zu Fehlern und Verzögerungen beim Routing führen
• Active Directory Site-Konfiguration
  • Eine fehlerhafte Konfiguration der AD-Sites kann zu Fehlern bei der Zustellung und bei der Nutzung von Schattenkopien führen

Beim Routing einer Nachricht spielt auch die Nachrichtengröße eine Rolle. Exchange zieht mehrere Konfigurationen zu maximalen Nachrichtengröße in Betracht, um so zu bewerten, ob die Nachricht auch wirklich zugestellt werden kann. Kann eine Nachricht nicht zugestellt werden, erhält der Absender einen sog. Non-Delivery Report (NDR). Der Transportdienst betrachtet für die Ermittlung der erlaubten Nachrichtengröße die Konfigurationen auf Organisationsebene, die aller Sende- und Empfangskonnektoren der internen Verbindungsstrecke und die Einstellungen des Zielpostfaches.

Der Versand von Nachrichten

Sendekonnektoren arbeiten die Nachrichten in den Warteschlangen ab und versuchen das jeweilige Zielsystem mit den Konnektoreinstellungen zu erreichen. Eine korrekte DNS-Namensauflösung ist der Schlüssel zu einer fehlerfreifunktionierenden Exchange Infrastruktur. Die interne Namensauflösung ist selten eine Fehlerquelle. Anderes sieht es aus, wenn es um die DNS-Auflösung externer Domänen geht. Stellen Sie sicher, dass Ihre Exchange Server auch externe Domänen effizient und sicher auflösen können, um einen fehlerfreien Nachrichtenfluss mit externen Empfängern zu gewährleisten.

Kommt es beim Versuch einer Zustellung zu einem Fehler, wird der Fehler in der Warteschlange festgehalten. Im Regelfall erkennen Sie Zustellfehler am Anwachsen einer oder mehrerer Warteschlangen. Die Überwachung der Warteschlangengröße ist unerlässlich für einen stabilen Betrieb der Exchange Organisation.

Bedenken Sie, dass die Datenbank des Transportdienstes im Installationspfad eines Exchange Servers platziert ist. Wenn Ihre Exchange Server eine hohe Anzahl von Nachrichten verarbeiten muss, sollten Sie die Datenbank auf einem separaten und ausreichend dimensionierten Laufwerk platzieren.

Zusammenfassung

Der Exchange Server Nachrichtenfluss ist, wenn man unter die Motorhaube schaut, ein komplexes Gebilde. Mit einem richtig konfigurierten Active Directory sind keine Probleme beim Betrieb von Exchange Server zu erwarten. Die Herausforderungen für den Exchange Nachrichtenfluss beginnen mit der Anpassung der Exchange Konfiguration.

Gerade im Hinblick auf die Konfiguration von zusätzlichen Empfangskonnektoren müssen Sie sich immer fragen, ob Sie einen neuen Konnektor wirklich benötigen. Das Troubleshooting des Exchange Nachrichtenflusses ist nicht schwierig, jedoch zeitaufwendig. Gerade in Exchange Umgebungen, die seit einigen Jahren betrieben werden und mehrere Exchange Versionen gesehen haben, besteht ein Risiko, dass veraltete Einträge in der Konfigurationspartition den Betrieb stören. Gleiches gilt für die Exchange Empfängerobjekte. Eine regelmäßige Pflege vermeidet Störungen im Nachrichtenfluss.

Der tägliche Betrieb Ihrer Exchange Organisation wird durch ein proaktives Monitoring, in dem nicht nur der Nachrichtenfluss überwacht wird, einfacher. Neben der Überwachung der Warteschlangen, empfehle ich auch die Überwachung der Transportdienste selbst. Exchange Server verfügt mit der Funktion der Managed Availability zwar über eine integrierte Monitoring Lösung mit automatischen Recovery-Aktionen, jedoch möchten Sie sicher nicht von automatisch neustartenden Diensten überrascht werden.

Links

• Microsoft Exchange Server 2010 Transport Server Role Architecture Diagrams
• Message size and recipient limits in Exchange Server
• DNS and Report Types
• Exchange 2016 + 2019 Mail Flow with Ports

Viel Spaß mit Exchange Server.

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.