de-DEen-GB
 
rss

Granikos Technology Blog

Exchange Server 2019. Das Handbuch für Administratoren.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:

  • Exchange Server 2019 - Versionen, Funktionsumfang und Neuerungen
  • Bare Metal, virtualisiert, in der Cloud oder integriert in Office 365: Was ist die richtige Basis für Ihre Konfiguration?
  • Planung: Migration, Lizenzen, Berechtigungen
  • Installation und Konfiguration
  • Administration: Exchange Administrative Center, PowerShell und RBAC
  • Betrieb: Wartungsszenarien, Sicherheit, CALs
  • Exchange und Compliance: Rights Management, Data Leakage Prevention, Legal Hold
  • Exchange Worst Practices
  • Checklisten 

 

  • ISBN-10: 3836256436
  • ISBN-13: 978-3836256438

 

Links

 

Ich wünsche Ihnen schon jetzt viel Spaß mit Exchange Server 2019.

 

Buchcover © Rheinwerk Verlag

 

Weiterlesen »

PowerShellIn 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. 

Das Problem

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:

  • Wie können Sie die Ausführung der PowerShell-Skripte automatisieren?
  • Wie können Sie die Eingabe benötigter Skript-Parameter sinnvoll mit einer Automatisierung kombinieren?
  • Wie können Sie die unterschiedlichen Skript-Anmeldeinformationen sicher verwalten?
  • Wie können Sie die Ausführung der PowerShell-Skripte delegieren?
  • Wie können Sie alle Ausführungen der Skripte einheitlich und auditfähig protokollieren?

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. 

  

Die Lösung

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:

  • Einfache und sichere Konfiguration von Benutzerkonten zur Skriptausführung, je nach Zielsystem
    • Active Directory
    • SharePoint Server
    • Exchange Server
    • Office 365 mit seinen unterschiedlichen Workloads
    • usw.
  • Einfache Automatisierung von PowerShell-Skriten
    • Zeitplänen 
    • individuelle externe Trigger, z.B. PRTG 
    • manueller Start
  • Rollenbasierte Delegierung von Skript-Konfigurationen
    • Helpdesk- und Support-Mitarbeiter (intern/exterm)
    • Regionale Administrator-Teams
    • IT-affine MIttarbeiter, z.B. DV-Ansprechpartner
  • Einheitliche und auditfähige Protokollierung aller Aktivitäten, der zugriffsberechtigten Personen und der Skripte
  • Eingehende und Ausgehende Schnittstellen mit anderen Softwarelösungen
    • dynamischen Auswahl von Skript-Parametern
    • Start von PowerShell-Skripten in Abhängikeit von externen Parameter
  • Webbasiertes Interface zur intuitiven Ausführung von delegierten Aufgaben
  • Minimierung des Sicherheitsrisikos
    • keine Installtion von PowerShell-Module auf den Arbeitsplätzen-PCs

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.

Sichere PowerShell Delegierung

Grafik © ScriptRunner

Die einzelnen Schritte sind:

  1. Administratoren und DevOps entwickeln PowerShell-Skripte für die Nutzung mit ScriptRunner
  2. ScriptRunner-Administratoren implementieren die Skripte und konfigurieren die Nutzergruppen
  3. Anwender können PowerSkripte entsprechend ihrer Rollenzugehötigkeit ausführen
  4. ScriptRunner führt die Scripte mit individuellen Anmeldeninformationen gegen lokale Systemen oder Cloud-Ressourcen aus
  5. Die Skript-Ergebnisse werden von ScriptRunner erfasst und protokolliert

 

Die Vorteile

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.

 

Links

 

Viel Spaß bei der Automatisierung!

 

 

Weiterlesen »
On Januar 5, 2018
432 Views

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.

Fehlermeldung OAB Download

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.


Download Einstellungen Offline Adressbuch

Mit dieser Download-Einstellung kommt es nicht mehr zu einem Fehler.

Viel Spaß mit Outlook.

 

Weiterlesen »

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.

Schritt für Schritt Anleitung

Schritt 1

Öffnen Sie den lokalen Zertikatsspeicher mit Hilfe des MMC Snap-Ins.

 

Schritt 2

Wählen Sie das gewünschte Zertifkat aus und öffnen Sie mit einem Rechts-Klick auf dem Zertifkat das Kontextmenü.

Kontextmenü SSL Zertifikat

Wählen Sie Manage Private Keys, um die Berechtigungen für den privaten Schlüssel zu verwalten.

 

Schritt 3

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

Virtuelle Dienstkonten hinzufügen

Klicken Sie anschließend auf Check Names, um die eingegebenen Bentuzerkonten zu prüfen.

 

Schritt 4

Bei korrekter Auflösung werden die Anzeigename der Dienstkonten im Fenster angezeigt. Klicken Sie anschließend auf OK

Aufgelöste virtuelle Dienstkonten

 

Schritt 5

Setzen Sie für alle hinzugefügten Dienstkonten die Lese-Berechtigung und klicken Sie anschließend OK.

Setzen der Lese-Berechtigung

Um Anschluß kann das nun korrekt konfigurierte Zertifkat durch NoSpamProxy für den Aufbau von TLS Verbindungen verwendet werden.

Link

 

 

Weiterlesen »
On Januar 12, 2017
1276 Views

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.

  • Dateipfad (Beispiel): E:\Program Files\Net at Work Mail Gateway\Gateway Role
  • Dateiname: NetatworkMailGatewayRole.exe.config

Für die Konfiguration eines Proxy-Servers wird in der Konfigurationsdatei ein zusätzlicher Xml-Node hinzugefügt.

  1. Stoppen der NoSpamProxy Gateway-Rolle über die NoSpamProxy Managementkonsole
  2. Erstellen einer Kopie der Konfigurationsdatei
  3. Anpassen der Konfigurationsdatei
  4. Starten der NoSpamProxy Gateway-Rolle über die NoSpamProxy Managementkonsole

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>

 

Hinweis

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.

Links

 

 

Weiterlesen »