Im Februar 2019 erscheint mein Buch Exchange Server 2019 - Das Handbuch für Administratoren im Rheinwerk Verlag.
In diesem Handbuch gebe ich Ihnen Empfehlungen zur Implementierung einer Exchange Server 2019 Plattform. Diese Empfehlungen basieren auf meiner langjährigen Erfahrung als Berater im Bereich Exchange Server, Exchange Online und Office 365.
Aus dem Inhalt:
Ich wünsche Ihnen schon jetzt viel Spaß mit Exchange Server 2019.
Buchcover © Rheinwerk Verlag
In der heutigen Zeit ist die skriptbasierte Verwaltung von Server-Softwarelösungen aus der Arbeitswelt von Administratoren nicht mehr wegzudenken. Immer mehr Produkte und cloudbasierte Dienste lassen sich nur per PowerShell und individuelle Skripte sinnvoll administrieren. Gerade Office 365 ist hier ein unrühmliches Beispiel, da jeder Dienst über eine individuelle PowerShell-Schnittstelle verfügt.
Dieser Umstand hat zur Folge, dass Sie als Administrator oft Skripte zur Verwaltung komplexer Umgebungen einsetzen müssen, die Sie nicht selbst geschrieben haben. Die Skripte werden entweder von externen Dienstleister programmiert oder einfach aus dem Internet heruntergeladen. Hierbei implementiert jedes Skript, im Idealfall, eine eigene Protokollierung der ausgeführten Aktionen.
Die PowerShell-Skripte sind in den meisten Fällen für die individuelle Ausführung durch einen Administrator konzipiert und weniger für die regelmäßige und vollautomatische Ausführung. Als Administrator möchten Sie sich aber um wichtiger Dinge kümmern, als z.B. die Anlage von Benutzerkonten im Active Directory, die E-Mail-Aktivierung von Konten oder die Erstellung von SharePoint Team-Sites.
Sie stehen u.a. vor folgenden Problemen:
Sie kommen mit der Nutzung der Windows Bordmitteln, wie dem Task Scheduler, schon recht weit. Aber Sie werden mir zustimmen, dass dieses Tool nicht gerade die bequemste Art ist, um PowerShell-Skripte sinnvoll und sicher zu automatisieren.
Ein Lösung für dieses Dilemma ist die Nutzung einer Softwarelösung, die uns ein Trennung zwischen dem ausführenden Skript-Kontext und dem Kontext des Anwenders, der ein Skript startet, bietet. Mit einem Rollen- und Berechtigungssystem kann ein Skript, in Abhängigkeit der Rollenzuweisung, unterschiedlich ausgeführt werden.
WIr benötigen also ein Lösung, die uns folgende Funktionen bietet:
Mit ScriptRunner steht eine professionelle Softwarelösung zur Verfügung, die uns all diese Möglichkeiten bietet. ScriptRunner ist ein sehr umfangreiches und leistungsfähiges Produkt zur PowerShell-Automatisierung. Aus meiner Sicht ist das Sicherheitskonzept, das für die Delegierung der Skript-Ausführungen eingesetzt wird, einer der Hauptgründe für das Produkt.
Das folgende Schaubild vereutlicht die Isoliserung von ScriptRunner für die sichere Ausführung von PowerShell-Skripten.
Grafik © ScriptRunner
Die einzelnen Schritte sind:
Die Automatisierung und die wiederkehrende Ausführung führt zu einer Reduzierung der Betriebsrisiken und minimiert kostenintensive manuelle Nacharbeiten. Dies gelingt durch die hohe Reproduzierbarkeit der immer gleichen Aufgaben (Stichwort: Erstellung von Benutzern mit unterschiedlichen Attributen, je nach Fachabteilung). Durch ein Zonenmodell und die strikte Trennung der Ausführungsberechtigungen (Anwender, Automatisiserungsdienst, Skript-Credentials) erreichen Sie ein Maximum an Betriebssicherheit.
Mit solch einer Aufteilung können Sie die Ausführung von Skripten nicht nur an das Helpdesk-Team delegieren, sondern sogar an DV-Ansprechpartner in Fachabtielungen. Die Weboberfläche ist intuitiv bedienbar und führt den Anwender sucher durch alle konfigurierten Eingabe- und Auwahlschritte.
Ab Q1 2019 werden Sie speziell für Exchange Server, Exchange Online und Office 365 entwickelte Skripte zur Nutzung mit ScriptRunner in diesem Blog finden.
Viel Spaß bei der Automatisierung!
Manchmal ist es notwendig, das Offline Adressbuch (OAB) für den Outlook E-Mail Client manuell herunterzuladen.
Kommt es beim Herunterladen des OAB zu einem Fehler, in diesem Fall 0x80200051, wird durch den First-Line Support gerne zwischen dem Online- und dem Cached-Modus von Outlook hin und her gewechselt. Leider behebt dieses Vorgehen den Fehler nicht.
Nach dem erneuten Aktivieren des Cached-Modus, muss das OAB vollständig neu heruntergeladen werden. Leider ist im Outlook-Diaglog zum manuellen Download des OAB die Checkbox "Änderungen seit der letzten Übermittlung herunterladen" standardmäßig aktiv. Diese Option muss abgewählt werden, um einen vollständigen Download es OAB durchführen zu lassen.
Mit dieser Download-Einstellung kommt es nicht mehr zu einem Fehler.
Viel Spaß mit Outlook.
Software-Lösungen, die einen TLS verschlüsselten Kommunikationskanal aufbauen möchten, benötigen Zugriff auf den privaten Schlüssel des zuverwendenden SSL Zertifkates im lokalen Zertifkatsspeicher des Servers. In den meisten Fällen installiert die Software ein selbstsigniertes Zertifkat und konfiguriert für dieses Zertifikat die korrekten Berechtigungen.
Bei der externen Kommunikation ist es aber häufig gewünscht, ein offiziell ausgestelltes SSL/TLS Zertifikat zu verwenden.
Die nachfolgenden Schritte beschreiben die Konfiguration der Lese-Berechtigung für das E-Mail Security Gateway NoSpamProxy. In diesem besonderen Fall verwendet die Software kein reguläres Dienstkonto, sondern sog. virtuelle Dienstkonten. Diese Konten ermöglichen eine erhöhte Sicherheit beim Ausführen von Windows-Diensten.
Öffnen Sie den lokalen Zertikatsspeicher mit Hilfe des MMC Snap-Ins.
Wählen Sie das gewünschte Zertifkat aus und öffnen Sie mit einem Rechts-Klick auf dem Zertifkat das Kontextmenü.
Wählen Sie Manage Private Keys, um die Berechtigungen für den privaten Schlüssel zu verwalten.
Klicken Sie auf Add und fügen Sie die gewünschten Konten hinzu. In diesem Beispiel ist es notwendig, das lokale Computersystem als Lokation auszuwählen und nicht die Active Directory Domäne. Virtuelle Dienstkonten erforden das Prefix NT Service.
Für NoSpamProxy benötigen die folgenden Konten Lese-Zugriff:
NT Service\NetatworkMailGatewayIntranetRole NT Service\NetatworkMailGatewayManagementService NT Service\NetatworkMailGatewayGatewayRole NT Service\NetatworkMailGatewayPrivilegedService
Klicken Sie anschließend auf Check Names, um die eingegebenen Bentuzerkonten zu prüfen.
Bei korrekter Auflösung werden die Anzeigename der Dienstkonten im Fenster angezeigt. Klicken Sie anschließend auf OK.
Setzen Sie für alle hinzugefügten Dienstkonten die Lese-Berechtigung und klicken Sie anschließend OK.
Um Anschluß kann das nun korrekt konfigurierte Zertifkat durch NoSpamProxy für den Aufbau von TLS Verbindungen verwendet werden.
Die NoSpamProxy Gateway-Rolle benötigt für mehrere Funktionen Zugriff ins Internet. Dieser Zugriff kann sowohl direkt, als auch über einen klassischen Proxy erfolgen. Zu den Funktionen gehört u.a. der Webservice-Zugriff auf De-Mail.
Die Proxy-Konfiguration erfolgt direkt in der Konfigurationsdatei des Gateway-Service. Diese Anpassung muss auf jedem Server mit installierter Gateway-Rolle durchgeführt werden.
Für die Konfiguration eines Proxy-Servers wird in der Konfigurationsdatei ein zusätzlicher Xml-Node hinzugefügt.
Das nachfolgende Beispiel bezieht sich auf NoSpamProxy 11.1.179.0
NetatworkMailGatewayRole.exe.config vor der Anpassung
<?xml version="1.0" encoding="utf-8"?> <configuration> <runtime> <gcServer enabled="true" /> <generatePublisherEvidence enabled="false" /> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" /> </dependentAssembly> </assemblyBinding> </runtime> </configuration>
NetatworkMailGatewayRole.exe.config mit konfiguriertem Proxy-Server
<?xml version="1.0" encoding="utf-8"?> <configuration> <runtime> <gcServer enabled="true" /> <generatePublisherEvidence enabled="false" /> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-3.0.1.0" newVersion="3.0.1.0" /> </dependentAssembly> </assemblyBinding> </runtime> <system.net> <defaultProxy> <proxy usesystemdefault="true" proxyaddress="http://10.29.10.11:8080" bypassonlocal="true" /> </defaultProxy> </system.net> </configuration>
Bei der Installation eines Updates von NoSpamProxy wird die Datei NetatworkMailGatewayRole.exe.config überschrieben.
Dies bedeutet, dass nach die Konfiguration eines Proxy-Servers nach erfolgreicher Installation des Updates wieder eingetragen werden muss.