You find the English version of this post at ENow's ESE Blog: Exchange Monitoring: What is Exchange Mail Flow   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. ...

Als IT-Berater sieht man manchmal Dinge, die es eigentlich gar nicht geben darf. In diesem Fall geht es um das eine Exchange Server 2016 Installation auf einem Windows Server 2019 Betriebssystem. Diese Kombination ist nicht unterstützt. Die Exchange Server Unterstützungsmatrix gibt hier eine klare Antwort. Aber der Reihe nach.   Das aktuelle System Gefunden wurde diese nicht unterstützte Kombination, als der Kunde eine Aktualisierung von Exchange Server 2016 CU12 auf CU19 durchführen wollte. Das System selbst ist als Koexistenz-Server für eine Active Directory Umgebung mit hybriden Identitäten in Nutzung. Zusätzloich wird das System für den hybriden Nachrichtenfluss zwischen einer lokalen Lotus Notes Umgebung und als SMTP-Relay für interne Applikationen und Multifunktionsgeräte verwendet. Da Exchange Server 2016 CU12 auf diesem System bereits seit Mitte 2019 in Betrieb ist, habe ich keine Gedanken daran verschwendet, mir die lokale Betriebssystemversion genauer anzuschauen. Der Fokus lag auf der Installation der Voraussetzungen für Exchange Server 2016 CU19.  Bei der Ausführung der Installatiin von CU19 per Kommandozeile wurde das Problem sichtbar. Die Installationsroutine teile zum Abschluss der Prüfungen der Installationsvoraussetzungen mit, das das lokale Betriebssystem eine nicht unterstützte Version ist. Ein genauer Blick ...

Services of third-party software solutions often interfere with installing a new Exchange Server cumulative update, because these services have a file lock active.  To avoid any issues when installing a CU, or having the prerequisites check fail due to open files, you simply stop the Windows services and ensure that those services do not restart automatically. Especially monitoring solutions that use some kind of watchdog service are a candidate that you must disable for installing an Exchange Server CU. The following two PowerShell examples help you to prepare the Windows services for installing an Exchange Server CU.   Prepare for CU installation In preparation for the installation of an Exchange Server cumulative update, you can use the following PowerShell commands. # Disable and stop services or just stop services # Add other services as needed # Set SMEX service to manual and stop services Get-Service -Name 'ScanMail*' | Set-Service -StartupType Manual Get-Service -Name 'ScanMail*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force # Stop SMEX SQL Express instance Get-Service -Name 'MSSQL*' | ?{$_.Status -eq 'Running'} | Stop-Service -Force # Disable and stop ENow monitoring services Get-Service 'ENow*' | Set-Service -StartupType Disabled Get-Service 'ENow*' | ?{$_.Status -eq 'Running'} ...

You sometimes need some (or even many) test user objects in Active Directory. This script helps you create any number of test users in your Active Directory domain, which you can easily enable for on-premises or remote mailboxes afterward.   The Script # Number of user accounts to create $UserCount = 5 $RandomPassword = $true $DefaultPassword = 'Pa55w.rd' # User name prefix # New user object will be named TestUser1, TestUser2, ... $TestUserPrefix = 'TestUser' # User object properties $GivenName = 'Test' $Surname = 'User' $Company = 'Varunagroup' $JobTitle = @('Junior Consultant','Senior Consultant','Technical Consultant','Business Consultant') $PreferredLanguage = 'de-DE' # Name of the new organizational unit for test user object $TestOU = 'Test User' # Target OU path where the script creates the new OU $TargetOU = 'OU=IT,dc=varunagroup,dc=de' # Import Active Directory PowerShell Module Import-Module -Name ActiveDirectory # Build OU Path $UserOUPath = ("OU={0},{1}" -f $TestOU, $TargetOU) # Check if OU exists $OUExists = $false try { $OUExists = [adsi]::Exists("LDAP://$UserOUPath") } catch { $OUExists =$true } if(-not $OUExists) { # Create new organizational unit for test users New-ADOrganizationalUnit -Name $TestOU -Path $TargetOU -ProtectedFromAccidentalDeletion:$false -Confirm:$false } else { Write-Warning ('OU {0} exists please delete the OU and user ...