In Teil 1 dieser Artikelserie wurde der RMS Server installiert und  in Teil 2 fand die Konfiguration statt. Jetzt folgt die Integration in Exchange 2016.

Zur Erinnerung noch einmal die Umgebung aus Teil 1 und 2:

Umgebung

Die Umgebung in der die Active Directory Rechteverwaltungsdienste installiert werden, sieht wie folgt aus:

Es gibt ein paar Benutzer mit Outlook 2016, einen Domain Controller, 3 Exchange Server (eine DAG), ein File Server für das Quorum und einen Windows Server 2012 R2 der in Teil 1 als Rechteverwaltungsdienste Server installiert wurde.

Das Active Directory hört auf den Namen frankysweb.de, die Benutzer verwenden Windows 10 mit Outlook 2016.

Vorbereitung

Damit die Integration in Exchange 2016 funktioniert, muss das Active Directory Konto der Systemmailbox “FederatedEMail” Mitglied der RMS Admin Gruppe sein. In meinem Fall füge ich das Konto “FederatedEmail” zur Gruppe “SG_RMSAdmins” hinzu:

Anschließend müssen wieder ein paar zusätzliche Berechtigungen vergeben werden. Dazu wird im IIS-Manager auf die Anwendung “certification” geklickt und zur Inhaltsansicht gewechselt:

Für die Datei ServerCertification.asmx können nun die Berechtigungen bearbeitet werden:

Die Gruppe “Exchange Servers” und “FederatedEmail” erhalten “Lesen” und “Lesen und Ausführen” Rechte:

Jetzt sollten die Berechtigungen wie folgt aussehen:

Weiter geht es mit der Integration in Exchange 2016

Integration RMS in Exchange 2016

AD RMS wird innerhalb von Exchange Server als IRM (Information Rights Management) benannt. Daher sind auch die CMDLets und Einstellungen entsprechend mit IRM gekennzeichnet (Get-IRMConfiguration, Set-IRMConfiguration, etc.).

In der Standardeinstellung ist IRM für die ClientAccessServer bereits eingeschaltet, wie an vielen Stellen ist “ClientAccessServer” hier noch ein Überbleibsel aus Exchange 2013, denn ClientAccess und Postfach Rolle, wurden zusammengelegt, sodass es nur noch die Postfachrolle gibt.

Die Lizenzierung, also das Austellen von Lizenzen für Dokumente ist in der Standard Einstellung allerdings deaktiviert:

Mit dem folgenden Befehl lässt sich RMS für den internen Gebrauch einschalten:

Set-IRMConfiguration –InternalLicensingEnabled $true

Hinweis: Hier geht es erst einmal darum RMS intern zu aktivieren. Damit es auch mit externen Empfängern, also Empfängern außerhalb des eigenen Acktive Directory funktioniert, ist noch mehr erforderlich.

Auch für OWA ist RMS (IRM) bereits aktiviert:

Um IRM intern zur Verfügung zu stellen, muss also zunächst nur das “Set-IRMConfiguration”-CMDLet ausgeführt werden, danach lässt sich bereits testen:

Test-IRMConfiguration -Sender <a href="mailto:administrator@frankysweb.com">administrator@frankysweb.com
</a>

Überall ein Erfolg, es kann getestet werden.

Outlook und OWA

Zum Testen erstelle ich eine neue E-Mail in OWA, über die “3 Punkte”-Schaltfläche wird nun die Option “Berechtigungen festlegen” angezeigt. Hier ist nun die “Nur Lesen”-Richtlinie aus Teil 2 sichtbar. Die beiden anderen Richtlinien sind Standard Exchange Richtlinien:

Wenn “Nur Lesen” ausgewählt wird, werden entsprechende Mail Tipps mit den Informationen der Richtlinie angezeigt. Diese wurden ebenfalls in Teil 2 konfiguriert:

Die Mail wird an einen internen Empfänger mit Outlook 2016 verschickt. Beim Öffnen der RMS geschützten Mail, wird zunächst Outlook einmalig für due Nutzung von AD RMS konfiguriert:

Danach kann die Mail gelesen werden, aber die Schaltflächen für “Antworten” und “Weiterleiten” sind ausgegraut, da in der Richtlinie “Nur Lesen” definiert wurde.

Hinweis: Versucht doch mal Kopieren und Einfügen oder ein Bildschirmfoto…

Ich habe dazu ein kleines Video erstellt:

Der Beitrag Active Directory Rechteverwaltungsdienste (RMS) und Exchange 2016 (Teil 3) erschien zuerst auf Franky's Web.

Das Konfigurieren von SCHANNEL Einstellungen für beispielsweise SSL 3.0 und TLS 1.0 ist unter Windows mittels Registry möglich. Bei einer größeren Anzahl von Servern oder Rechnern eignen sich zur Konfiguration allerdings Gruppenrichtlinien besser, ich habe daher entsprechende Vorlagen erstellt, die die Einstellungen an der Registry vornehmen.

Vorwort

Die Gruppenrichtlinien nehmen Änderungen an der Registry auf allen Computern/Servern vor, die die Richtlinie anwenden. Da es hier je nach Umgebung zu Problemen kommen kann, müssen entsprechende Einstellungen sorgsam getestet werden.

Die Änderungen an der Registry durch die GPO bleiben auch nach dem Löschen der GPO bestehen und werden nicht auf die Standardeinstellung zurück geändert. Vorher also ausgiebig testen!

Falls es zu Problemen kommt, liegen dem Download die Standard Registry Werte für Windows Server 2012 R2 und Windows Server 2008 R2 bei. Die .REG Dateien können mit der Registry zusammengeführt werden, um die Standard Einstellungen wiederherzustellen.

Download

Die Vorlagen für die Gruppenrichtlinien können hier runtergeladen werden:

ADM für SSL / TLS / Cipher / Hashes 5.08 KB

Download

Anbei das HowTo für die Erstellung von entsprechenden Gruppenrichtlinien.

Gruppenrichtlinie auf Basis eines ADM-Templates (ALT)

Die klassischen ADM-Templates haben den Vorteil, dass Sie auch mit Windows Server 2003 und Windows XP noch funktionieren. Auch wenn Windows 2003 und Windows XP nicht mehr supported werden, können mit dem ADM Template Einstellungen vorgenommen werden. Hier ist allerdings Vorsicht geboten, da nicht alle Einstellungen von Windows Server 2003 und Windows XP unterstützt werden. Ausführliche Tests sind sehr ratsam. ADM Templates funktionieren auch mit Windows Server 2012 (R2).

Damit das ADM Template eingebunden werden kann, muss zuerst eine neue Gruppenrichtlinie in der Gruppenrichtlinienverwaltung erzeugt werden:

Ein sprechender Name für die zukünftigen Einstellungen ist ratsam:

Nachdem die Gruppenrichtlinie erzeugt wurde, wird sie bearbeitet:

Unter dem Punkt “Computerkonfiguration” / “Administrative Vorlagen” kann mittels Rechtsklick eine Vorlage hinzugefügt werden:

Im folgenden Dialog wird nun die ADM Datei angegeben:

Nach dem Laden des ADM Templates sind neue Unterpunkte mit den jeweiligen Einstellungen sichtbar:

In diesem Beispiel wird SSL 3.0 für Server (IIS-Webserver) und Clients (Internet Explorer) abgeschaltet. Wie bei den meisten Richtlinien muss auch hier genau gelesen werden: Die Einstellung “SSL 3.0 abschalten” muss aktiviert werden, um SSL 3.0 zu deaktivieren:

Der Editor kann geschlossen werden. Damit die Richtlinien etwas schneller geladen werden, sollte in der Gruppenrichtlinienverwaltung noch die “Benutzerkonfigurationseinstellungen” deaktiviert werden:

Zum Schluss noch die neue Gruppenrichtlinie mit einer entsprechenden OU verknüpfen.

Richtlinie auswählen und mit OK bestätigen

Die neue Gruppenrichtlinie ist fertig

Um ein Anwenden der neuen GPU auf einem Testrechner zu erzwingen, kann der folgende Befehl benutzt werden:

gpoupdate /force /target:computer

Zur Kontrolle kann die Registry überprüft werden, ob die entsprechende Einstellung gesetzt wurde:

Zum Schluss muss der Rechner neugestartet werden.

Gruppenrichtlinie auf Basis eines ADMX Templates (NEU)

Die modernere Variante von ADM-Templates sind ADMX-Templates. ADMX Templates funktionieren ab Windows Server 2008.

Um das ADMX-Template einzubinden, wird die Datei SSL_TLS_Settings.admx aus dem ZIP-Archiv in den Ordner C:\Windows\PolicyDefinitions kopiert. Die Datei SSL_TLS_Settings.adml aus dem Unterordner de-DE wird nach C:\Windows\PolicyDefinitions\de-DE kopiert:

Jetzt kann eine neue Gruppenrichtlinie erzeugt werden:

Die Gruppenrichtlinie wird nach dem Anlegen bearbeitet:

Die SCHANNEL Einstellungen finden sich jetzt in der Computerkonfiguration –> Administrative Vorlagen –> SCHANNEL Einstellungen:

Nachdem die entsprechenden Einstellungen vorgenommen wurden, ist der Rest wieder identisch mit ADM-Vorlagen (Benutzerkonfigurationseinstellungen deaktivieren, Richtlinie verknüpfen etc.)

Der Beitrag Gruppenrichtlinie zum Deaktivieren von SSL 3.0 und TLS 1.0 (ADM und ADMX) erschien zuerst auf Franky's Web.

Außerhalb des üblichen Patch Intervalls für Exchange Server hat Microsoft ein Sicherheitsupdate für alle Exchange Server Versionen veröffentlicht, welches mehrere als hoch oder kritisch eingestufte Sicherheitslücken beheben soll.

Anbei der Link zum Security Bulletin:

Microsoft-Sicherheitsbulletin MS16-108

Kurzbeschreibung der Sicherheitslücke:

Dieses Sicherheitsupdate behebt Sicherheitsanfälligkeiten in Microsoft Exchange Server. Die schwerwiegendsten Sicherheitsanfälligkeiten können Remotecodeausführung in einigen in Exchange Server integrierten Oracle Outside In-Bibliotheken ermöglichen, falls Angreifer E-Mails mit einem speziell gestalteten Anhang an einen anfälligen Exchange-Server senden.

Quelle: Microsoft

Hier geht es direkt zum Download des Updates für die jeweiligen Exchange Versionen:

• Security Update For Exchange Server 2016 CU2 (KB3184736)
• Security Update For Exchange Server 2013 CU13 (KB3184736)
• Updaterollup 15 für Exchange Server 2010, Service Pack 3 (KB3184728)
• Updaterollup 21 für Exchange Server 2007 Service Pack 3 (KB3184711)

Bei mir wird das Update gerade installiert, was schon einige Zeit dauert:

Da die Lücke scheinbar durch eine E-Mail ausgenutzt werden kann, sollte das Update zügig installiert werden. Leider ist auf dem Exchange Team Blog bisher keine entsprechende Warnung veröffentlicht worden.

Der Beitrag Kritisches Sicherheitsupdate für alle Exchange Server Versionen (MS16-108) erschien zuerst auf Franky's Web.

In diesem Jahr findet der Microsoft Technical Summit zum dritten Mal statt. Wie auch im letzten Jahr gibt es Vorträge rund um IT-Pro und Developer Themen vom 6.12 bis zum 8.12. in Darmstadt.

Ich freue mich schon auf die beiden Tage (den Workshop Tag lasse ich dieses Jahr ausfallen). Dieses Jahr wird es einen Community Day am 05.12 geben, ich bin sehr gespannt darauf, was mich wohl da erwarten wird.

Auf der MSTS Seite gibt es bereits eine vorläufige Agenda:

https://www.microsoft.com/germany/technical-summit/agenda.aspx

Bisher finde ich folgende Session interessant:

• Mobile Device Management für Android, iOS und Windows 10 mit SCCM
• Desktop Virtualization and Session Remoting: An Independent Insider s View
• Neuigkeiten von Exchange: On-Premises, Hybrid und Online
• IoT on real business scenarios
• Microsoft Bot Framework – eine neue Art der Kommunikation
• System Center Configuration Manager und Microsoft Azure – Better together
• Cybercrime reality und forensic techniques
• Let’s manage a Tesla vehicle with Microsoft solutions!
• Lessons Learned: Einführung von Office 365 in einer bestehenden Infrastruktur

Hier finden sich meine Eindrücke vom Technical Summt 2015. Also, man sieht sich!

Der Beitrag Microsoft Technical Summit 2016 – Man sieht sich! erschien zuerst auf Franky's Web.

Gruppenrichtlinien erleichtern einem Admin das Leben und lassen sich mit wenig Aufwand selbst erstellen. Der Vorteil liegt auf der Hand, mittels Gruppenrichtlinien lassen sich Registry Einstellungen einfach auf viele Rechner verteilen. Im folgenden Artikel gibt es ein kleines HowTo, wie Gruppenrichtlinien mit dem kostenlosen “Old-School”-Tool “ADMX-Migrator” selbst erstellt werden können.

Vorwort

Auch für Exchange Server und Domain Controller habe ich ein paar eigene Gruppenrichtlinien erstellt, da auch hier ein paar Einstellungen über die Registry vorgenommen werden. Hier ein paar Beispiele für Einstellungen in der Registry, die sich wunderbar per GPO konfigurieren lassen:

• Exchange 2010 Quota Cache
• Exchange 2010 Statische RPC Ports
• Domain Controller NTP Zeitsynchronisation

Der Vorteil einer Gruppenrichtlinie für solche Einstellungen? Sobald eine entsprechende Vorlage für die Einstellungen in der Registry erstellt wurde, lässt sich eine Gruppenrichtlinie in unterschiedlichen Umgebungen auf mehreren Servern anwenden. Neue Domain Controller oder neue Exchange Server erhalten automatisch die gleichen Einstellungen wie die vorhandenen.

Die klassischen ADM Templates aus Windows Server 2003 Zeiten (und früher) konnte man mit wenig Aufwand erstellen. Hier ein kleines Beispiel:

ADM war da noch ziemlich selbsterklärend. Mit dem aktuellen Format (ADMX) wird auf eine XML Struktur gesetzt. ADMX Templates sind um einiges flexibler, aber auch etwas komplizierter, wenn man sie mit einem einfachen Editor erstellen will. Hier ein Beispiel für ein ADMX Template mit einer Sprache:

Zugegeben, das Beispiel für die ADMX Vorlage kommt aus einer GUI, und ist keine manuell erstellte Vorlage, trotzdem sieht man auf den ersten Blick, dass die XML Struktur aufwändiger manuell zu Erstellen ist.

Abhilfe schafft ein kleines Tool, welches kostenlos runtergeladen werden kann:

• ADMX-Migrator Download

ADMX Migrator ist ein altes Tool, welches nicht mehr weiter entwickelt wird. Ich nutze es aber trotzdem gerne, einfach aus Gewohnheit:

Falls jemand einen guten Tipp für ein aktuelles Tool hat, freue ich mich über Hinweise in den Kommentaren.

Installation

Die Installation von ADMX-Migrator ist selbsterklärend und ist in ein paar Klicks erledigt, daher nur der Vollständigkeit halber ein paar Screenshots:

Benutzerinformationen eingeben:

Speicherort auswählen:

Die Option “Register after Insallation is complete” kann abgewählt werden, die entsprechende Internetseite gibt es nicht mehr:

Installation abgeschlossen.

Eigene Gruppenrichtlinien (ADMX Templates) erstellen

Um eine Gruppenrichtlinie für ein bestimmtes Programm zu erstellen, muss zuerst rausgefunden werden, wo das Programm seine Einstellungen in der Registry speichert, welche Einstellungen gültig sind und was sie bewirken. Dazu muss das Programm auf einem Testrechner installiert werden und entsprechende Einstellungen in der Registry gesucht werden. Dieser Teil dauert üblicherweise am längsten, da hier häufig “Trial and Error” angesagt ist. Damit man schnell wieder auf die Standard Einstellungen zurückgreifen kann, ist es hilfreich die entsprechenden Schlüssel zu exportieren. So lässt sich der Standard schnell wiederherstellen.

Als Beispiel habe ich mal ein fiktives Programm genommen, welches Einstellungen unter HKEY_CURRENT_USER und HKEY_LOCAL_MACHINE ablegt:

Sobald rausgefunden wurde welche Einstellungen relevant sind, kann mittels ADMX Migrator eine Gruppenrichtlinie erzeugt werden:

Dem neuen Template wird nun ein Name gegeben:

Jetzt kann die erste Kategorie angegeben werden, die erste Kategorie unterhalb des Namens, erstellt einen “Ordner” unter “Administrative Vorlagen”. Auch der Name der Kategorie kann frei gewählt werden, ich nehme in diesem Fall “FW Programm”, damit erkenntlich ist, um welche Einstellungen es sich handelt:

Unterhalb der ersten Kategorie können weitere Kategorien angelegt werden. Ich erstelle eine Kategorie für Benutzer und Computer Einstellungen:

Im Gruppenrichtlinien Editor werden die Kategorien später so dargestellt werden:

Die grobe Struktur steht also schon einmal, jetzt kommen die Einstellungen dran. In diesem Fall möchte in den Wert für “UseWindowsDefault” steuern, also wird auch hier der Schlüsselname und der Name des entsprechendes Werts kopiert:

Die Angaben werden nun für die erste “Policy Setting” benötigt. Da es sich um eine Einstellung unter HKEY_CURRENT_USER handelt, kommt sie in die Kategorie “Benutzer”. In der Policy Setting werden nun die entsprechenden Werte eingesetzt:

Registry Key: Schlüsselname

Registry Value Name: UseWindowsDefault

Class: User (da HKEY_CURRENT_USER)

Unter der Einstellung Values, werden jetzt die Werte definiert:

Enabled Value = Aktiviert = 1

Disabled Value = Deaktiviert = 0

Unter Explain, kann jetzt noch eine aussagekräftige Beschreibung zu der Einstellung hinzugefügt werden:

Im Gruppenrichtlinien Editor sieht es nun so aus:

Mit ADMX-Migrator lassen sich nicht nur DWORDs schalten, sondern auch Textfelder oder DropDown Listen erstellen. Im Prinzip wird hier ganz ähnlich vorgegangen wie bei DWORDS. In nächsten Beispiel gibt es zwei REG_SZ Werte:

Da such diese unter HKEY_CURRENT_USER liegen, kommen die Policy Settings auch wieder unter die Kategorie Benutzer:

Es werden ebenfalls wieder Enabled und Disabled Werte angegeben:

Unter Presentation kann jetzt eine Dropdownlist erzeugt werden:

Zur Dropdownlist werden wieder entsprechende Schlüsselnamen und Schlüsselwerte angegeben, unter dem Punkt ItemList können dann die Einstellungen für die DropDownliste hinzugefügt werden:

In der Itemlist werden nun alle Werte der Dropdownliste und die entsprechenden Werte eingetragen:

Unter Explain wird wieder eine Beschreibung angegeben:

Hier das Ergebnis im Gruppenrichtlinien Editor:

Sobald die Gruppenrichtlinie fertig konfiguriert ist, wird sie gespeichert:

Im Speicherpfad befinden sich nun die ADMX-Datei (enthält die Einstellungen) und ein Ordner mit der jeweiligen Sprachdatei:

Um die eigene Gruppenrichtlinie zu nutzen, müssen die ADMX-Datei sowie der Ordner auf einem Domain Controller in das Verzeichnis c:\Windows\PolicyDefinitions kopiert werden:

Umwandeln von ADM zu ADMX Templates

ADMX-Migrator kann auch alte ADM Templates zu ADMX Templates umwandeln, dazu kann über den Punkt “Generate ADMX from ADM” ein ADM Template geladen werden:

ADMX Migrator wandelt dann die alte ADM Struktur in die ADMX XML Struktur um:

Nach der Umwandlung zum ADMX Format, können Optionen angepasst oder verändert werden:

Sobald die Bearbeitung abgeschlossen ist, kann das ADMX Template gespeichert werden:

ADMX-Migrator erzeugt beim Speichern die Struktur, die auch vom Windows Central Store vorausgesetzt wird:

Auf diese Weise lassen sich recht einfach, alte ADM Templates zu ADMX Templates konvertieren.

Hinweis: Mit Umlauten in den ADM-Templates kommt ADMX-Migrator nicht zurecht, am einfachsten ist es also vor der Konvertierung die Umlaute in den ADM Templates mittels “Suchen/Ersetzen” loszuwerden.

Beispiel ADMX Files

Wie bereits eingangs erwähnt ist ADMX-Migrator ein ziemlich altes Tool und hat einige Schwächen, mittlerweile stürzt es auch mal ganz gerne ab.

Eine Gruppenrichtlinie bestellt allerdings nur aus der ADMX-Datei welche die Einstellungen (Kategorien, Policy Settings) enthält und einer Sprachdatei (ADML), in der Sprachdatei lassen sich entsprechende Übersetzungen definieren. Beide Dateien liegen im XML-Format vor und lassen sich auch mit einem Editor selbst erzeugen.

Microsoft bietet eine Gruppenrichtlinie als Beispiel an, in der die Möglichkeiten verdeutlich werden. Mit ein bisschen Copy/Paste und etwas “Try and Error”, lässt sich die Struktur schnell erlernen.

Hier können die Beispiel Dateien runtergeladen werden:

Group Policy Sample ADMX Files

Eine Testumgebung mit einem Domain Controller und einen Member ist schnell installiert, daher lässt sich mit der Beispielrichtlinie super üben.

Nachteil

Eigene Gruppenrichtlinien “tätowieren” die Registry. Soll heißen, die Registry Werte die mittels eigener Gruppenrichtlinie geändert oder erzeugt wurden, bleiben in der Registry des Computers vorhanden der die Richtlinie angewendet hat. Wenn eine Gruppenrichtlinie gelöscht wird, bleiben die Einstellungen also bestehen. Der Einsatz von eigenen Gruppenrichtlinien ist also mit Vorsicht zu genießen.

Immer daran denken: Löschen einer eigenen Gruppenrichtlinie setzt keine Einstellungen auf Standardwerte zurück, erst das definieren der Standardwerte in der GPO setzt entsprechende Werte. Wenn man denn noch die Standardwerte kennt. Eigene Gruppenrichtlinien sollten also gut dokumentiert werden und die Standardwerte der Registry in einer .REG Datei exportiert werden.

Der Beitrag HowTo: Gruppenrichtlinien selbst erstellen (ADMX) erschien zuerst auf Franky's Web.

Heute ist regulärer Exchange Patch Day und es wurden Updates für Exchange Server 2013 und Exchange Server 2016 veröffentlicht.

Die wichtigsten Neuerungen im Überblick:

• Windows Server 2016 Support für Exchange 2016 CU 3
• .NET Framework 4.6.2 Support für Exchange 2016 und Exchange 2013
• Verbesserungen der Hochverfügbarkeit für Exchange 2016
• Installation der Updates in lokaler Sprache, nicht mehr nur Englisch
• Server-wide.Offline Modus wird erst bei der Installation eingeschaltet

Hier geht es direkt zum Download für Exchange 2016:

Kumulatives Update 3 für Exchange Server 2016 (KB3152589)

Der Link für Exchange 2016 ist derzeit offline, ob es da wohl schon Probleme gab!? :-)

Ich reiche den Link nach sobald der Download verfügbar ist.

Details zu den Updates gibt es auf dem Exchange Team Blog:

https://blogs.technet.microsoft.com/exchange/2016/09/20/released-september-2016-quarterly-exchange-updates/

Außerdem wichtig: In sieben Monaten endet der Support für Exchange Server 2007. Es wird dann keine Updates mehr für Exchange 2007 geben.

Der Beitrag Neue Updates für Exchange Server 2013 / 2016 erschien zuerst auf Franky's Web.

Zertifikatswarnungen nerven, egal von welchem Programm. In diesem Fall warnt eine Remote Desktop Verbindung /RDP) vor einem ungültigen Zertifikat.

Diese Meldung dürfte wohl jeder kennen:

Es handelt sich hier um einen “normalen” Windows Server, also keinen Remote Desktop Host (Terminal Server), RDP ist hier nur für die Administration aktiviert. Windows verwendet in der Standard Konfiguration ein selbstsigniertes Zertifikat:

Da das selbst signierte Zertifikat vom Client nicht akzeptiert wird, erscheint die Warnung wie oben zu sehen.

In meinem Fall handelt es sich um einen Exchange Server, der für seinen Hostnamen schon ein gültiges Zertifikat von einer öffentlichen CA besitzt:

Warum nicht also dieses Zertifikat auch für RDP nutzen und damit die Warnung loswerden? Nein, auf “Nicht erneut fragen” klicken ist keine Option :-)

Natürlich klappt folgende Weg auch mit jedem anderen Zertifikat und auch mit “Nicht-Exchange”-Servern. Woher das Zertifikat stammt, von einer internen PKI oder öffentlichen CA, spielt dabei keine Rolle. Hauptsache der entsprechende Hostname steht auf dem Zertifikat und die Sperrlisten sind erreichbar.

Vorhandenes Zertifikat für RDP nutzen

Um dem Remotedesktopdienst ein neues Zertifikat zuzuweisen, wird der Thumbprint des neuen Zertifikats benötigt. Das Zertifikat muss sich im Zertifikatsspeicher des Computers befinden.

Die Thumbprints der vorhandenen Zertifikate lassen sich mit dem folgenden Befehl anzeigen:

Get-ChildItem -Path cert:/LocalMachine/My

Die Ausgabe sieht dann in etwa so aus:

Der Thumbprint des entsprechenden Zertifikats kann jetzt genutzt werden, um dem Remotedesktopdienst das Zertifikat zuzuweisen:

$TSpath = (Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash="5C526C2AB97D100249B411EA11566D55846B5ED3"}

Bei den beiden Befehlen oben, muss nur der Thumbprint entsprechend ausgetauscht werden. Die Ausgabe sollte wie folgt aussehen:

Hinweis: Die PowerShell muss als Administrator ausgeführt werden.

Das war schon alles. Das neue Zertifikat wird bei der nächsten RDP Verbindung genutzt und die Zertifikatswarnung ist verschwunden.

Standard Zertifikat für RDP nutzen

Die Änderung lässt sich auch wieder Rückgängig machen, hier kann einfach das alte selbstsignierte Zertifikat wieder zugewiesen werden.

Das Standardzertifikat wird im Zertifikatsspeicher des Computers im Ordner “Remote Desktop” gespeichert. Mit dem folgenden Befehl kann der Thumbprint ermittelt werden:

Get-ChildItem -Path "cert:/LocalMachine/Remote Desktop"

Jetzt kann wieder das Original Zertifikat zugewiesen werden (Thumbprint im zweiten Befehl austauschen):

$TSpath = (Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash="7E3044CDB0E5CF038D421E3E001F8DFE632E4A1D"}

Bei der nächsten RDP Verbindung wird wieder das Original Zertifikat verwendet.

Der Beitrag Tipp: Zertifikat für RDP austauschen erschien zuerst auf Franky's Web.

DANKE

Leute das ging schnell. Am 28.07. hatten Andi und Ich uns das erste Mal getroffen um über eine Möglichkeit der Kooperation zu sprechen. Dabei ist die Idee zur Exchange User Group OWL entstanden. Kaum zwei Monate später hat das erste Treffen der EUGO stattgefunden.

Zuerst möchten Andi und Ich uns herzlich bei allen Teilnehmern bedanken, wir haben im Vorfeld nicht mit so einer guten Resonanz und Teilnehmeranzahl gerechnet. Wenn wir ehrlich sein sollen: Unser Ziel war es, nicht alleine im Hotel zur Spitze zu sitzen.

Ein großes Dankeschön geht auch an Jan Schenk, Dennis Gassen und Mathias Schmidt von Microsoft Deutschland. Microsoft hat jedem Teilnehmer ein kühles Getränk und eine Pizza spendiert. Also Daumen hoch für Microsoft.

Auch an das Team vom Hotel zur Spitze geht ein großes Dankeschön für den reibungslosen Ablauf.

Hier gibt es ein Bild von unserem ersten Treffen:

18 Personen waren zum ersten Treffen gekommen und wir haben uns bis ca. 00:30 Uhr angeregt unterhalten.Alles in allem ein gelungener Abend wie ich finde.

Wie geht es weiter?

Aufgrund des positiven Feedbacks und der hohen Teilnehmerzahl bei unserem ersten Treffen, werden Andi und ich am Ball bleiben und weitere Treffen organisieren. Wir werden uns in den nächsten Tagen dazu Gedanken machen, wie und wann das nächste Treffen stattfinden soll. Entsprechende Updates gibt es dann natürlich hier und auf Andis Blog.

Wie im Bild zu erkennen ist, haben wir 2 Tische belegt, was wie ich finde nicht ganz ideal war, denn so gab es im Prinzip zwei Gruppen und der Austausch wurde dadurch etwas schwieriger. Dies uns ein paar andere Themen, werden wir für das nächste Treffen angehen.

Feedback, Kritik, Anregungen und Wünsche nehmen wir gerne per Mail oder als Kommentar an.

Wann geht es weiter?

Aus den Gesprächen haben wir mitgenommen, dass wir eine gewisse Regelmäßigkeit für EUGO Treffen umsetzen sollten. Der Großteil hat sich für vierteljährliche Termine ausgesprochen. Ich halte das ebenfalls für eine gute Idee, daher werden wir das nächste Treffen wohl Anfang nächstes Jahr organisieren. Einen entsprechenden Termin und den Stand der Planungen geben wir rechtzeitig bekannt. Wir hoffen natürlich darauf möglichst viele Teilnehmer wiederzusehen selbstverständlich sind auch neue Gesichter herzlich willkommen.

Der Beitrag EUGO: Das erste Treffen hat statt gefunden erschien zuerst auf Franky's Web.

Zum Auftakt der Ignite in Atlanta hat Microsoft Windows Server 2016 freigegeben. Bisher lässt sich das neue Server Betriebssystem allerdings nur als Demoversion (Evaluierungsversion) runterladen:

Windows Server 2016 Evaluation

Die Evaluationsversion ist 5 GB groß und steht auch in deutscher Sprache zur Verfügung. Stand heute ist noch keine Version im MSDN verfügbar. Ich denke es wird aber nicht mehr lange dauern.

Zu Kaufen gibt es Windows Server 2016 ab Oktober.

Informationen zu den Neuigkeiten von Windows Server 2016 gibt es hier:

https://www.microsoft.com/en-us/cloud-platform/windows-server

Hier gibt es Informationen zu den Systemanforderungen:

https://technet.microsoft.com/windows-server-docs/get-started/system-requirements–and-installation

Hinweis: Die Evaluierungsversionen sind nur zum Testen und Ausprobieren gedacht, nicht für den Produktivbetrieb.

Ich fange schon einmal an zu testen, daher gibt es schon ein paar Screenshots zur Installation:

Windows Server 2016 wird es in 3 Editionen geben:

• Standard
• Datacenter
• Essentials (maximal 25 Benutzer)

Nach der Installation ist Server 2016 auf den Ersten Blick nicht von Windows 10 zu unterscheiden:

Nach dem Anmelden erscheint der altbekannte Server Manager:

Updates gibt es auch schon:

Während ich also meine Test-VM Update, gibt es ein paar Informationen zu den Editionen, hier die Funktionsunterschiede:

Ein bisschen Schade finde ich, dass die neuen Storage Features nur in der Datacenter Edition verfügbar sind.

Wichtig zu Wissen:Das Lizenzmodell ändert sich mit Windows Server 2016. Ab jetzt müssen CPU-Cores lizensiert werden:

CPUs mit mehr als 8 Kernen benötigen extra Lizenzen:

Die neuen Features werde ich demnächst detaillierter vorstellen. Ich installiere dazu erst einmal eine kleine Testumgebung, das wird also etwas dauern. Exchange Server 2016 CU3 wird ebenfalls auf Server 2016 unterstützt, das probiere ich wohl mal als Erstes aus.

Der Beitrag Windows Server 2016 verfügbar! erschien zuerst auf Franky's Web.

Windows Defender ist auf Windows Server 2016 per Default aktiviert. Da Exchange Server einige Ausschlüsse vom Virenscanner benötigt, müssen diese entsprechend auch in Windows Defender hinterlegt werden. Gleiches gilt für Virenscanner anderer Hersteller.

Auf dem Exchange Team Blog findet sich dazu folgender Hinweis:

Windows Defender is on by default in Windows Server 2016. Attention to malware settings is particularly important with Exchange to avoid long processing times during installation and upgrade, as well as unexpected performance issues. The Exchange team recommends the Exchange installation and setup log folders be excluded from scanning in Windows Defender and other Anti-Virus software. Exchange noderunner processes should also be excluded from Windows Defender.

Quelle: Exchange Team Blog

Im Technet sind die Ausschlüsse für Exchange 2016 hier dokumentiert:

• Running Windows antivirus software on Exchange 2016 servers

Die Liste ist allerdings lang, daher hat Exchange MVP Paul Cunningham ein Script veröffentlicht, welches die Ordner, Prozesse und Dateitypen übersichtlich in 3 Dateien einsortiert. Das Script gibt es hier zum Download:

Generate Antivirus Exclusions for Exchange 2013 and 2016 Servers

Virenscanner Ausschlüsse per Script ermitteln

Nachdem Paul’s Script auf dem Exchange Server mittels Exchange Management Shell ausgeführt wurde, finden sich die 3 Dateien im Ordner des Scripts:

Das Script selbst, erzeugt nur den Hinweis “Done” als Ausgabe:

In den 3 Dateien sind jetzt alle Ausnahmen für Exchange Server enthalten. Hier als Beispiel die Dateitypen:

Alle Ausschlüsse (Dateitypen, Pfade und Prozesse) müssen jetzt im Virenscanner ausgeschlossen werden. Wie das funktioniert ist bei jedem Virenscanner unterschiedlich. Für Windows Defender ist das einfach:

Ausschlüsse zu Windows Defender hinzufügen

Wie eingangs bereits erwähnt ist Windows Defender auf Windows Server 2016 standardmäßig aktiviert. Da sich Windows Defender aber mit der PowerShell konfigurieren lässt, geht es besonders schnell die Ausschlüsse zu konfigurieren. Das folgende kleine Script verwendet die 3 Dateien von “Get-Exchange2016AVExclusions.ps1” und fügt die Ausschlüsse hinzu:

[array]$ExcludeExtensions = (Import-Csv .\*extensions.txt -Header Extension).Extension
Set-MpPreference -ExclusionExtension $ExcludeExtensions

[array]$ExcludePaths = (Import-Csv .\*paths.txt -Header Paths).Paths
Set-MpPreference -ExclusionPath $ExcludePaths

[array]$ExcludeProcesses = (Import-Csv .\*paths.txt -Header Processes ).Processes
Set-MpPreference -ExclusionProcess $ExcludeProcesses

write-host "Exluded extensions: " -foregroundcolor green
Get-MpPreference | fl ExclusionExtension
write-host "Exluded pathes: " -foregroundcolor green
Get-MpPreference | fl ExclusionPath
write-host "Exluded processes: " -foregroundcolor green
Get-MpPreference | fl ExclusionProcess

Das Script kann einfach als .PS1 Datei im gleichen Verzeichnis wie “Get-Exchange2016AVExclusions.ps1” gespeichert werden und danach als Administrator ausgeführt werden:

Fertig. :-)

Der Beitrag Exchange 2016: Virenscanner Ausschlüsse (Script für Windows Defender) erschien zuerst auf Franky's Web.

Dieses Howto beschreibt die Installation von Exchange 2016 auf Windows Server 2016.

Active Directory Konto anlegen

Windows Server 2016 setzt auf einer striktere Benutzertrennung. Es ist daher nicht ratsam den Exchange Server mit dem Benutzer “Administrator” zu installieren, sondern es sollte ein administrativer Benutzer angelegt werden, der die Exchange Installation durchführt. Es handelt sich dabei nicht um ein Dienstkonto, mit dem die Exchange Dienst gestartet werden.

Die folgenden Rechte sind erforderlich für das Konto, dass die Exchange Installation durchführt:

• Domänen-Admins
• Organisations-Admins
• Schema-Admins

Hinweis: Die Gruppe “Schema-Admins” ist nur erforderlich, wenn das Schema während der Exchange Installation erweitert wird. Das Schema lässt sich auch separat vor der Exchange Installation mit einem anderen Benutzer erweitern.

Voraussetzungen installieren

Die erforderlichen Windows Features und Rollen können am Einfachsten per PowerShell installiert werden:

Install-WindowsFeature NET-WCF-HTTP-Activation45, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

Hinweis: Die PowerShell muss als mit administrativen Rechten ausgeführt werden:

Nach der Installation der Windows Features, muss noch die UCMA Runtime 4 installiert werden:

Unified Communications Managed API 4.0 Runtime

Windows Server konfigurieren

Vor der Exchange Server Installation sollte temporär Windows Defender abgeschaltet werden. Es kann sonst zu einer längeren Installationszeit und anderen Problemen kommen:

Nach der Exchange Installation wird Windows Defender entsprechend konfiguriert und wieder eingeschaltet.

Allgemeine Empfehlung für Exchange Server: Die Größe der Auslagerungsdatei sollte fest auf die Größe des Arbeitsspeichers plus 10 MB eingestellt werden. Bei 10 GB RAM (10240 MB + 10 MB) macht das eine feste Größe der Auslagerungsdatei von 10250 MB:

Wenn der Exchange Server 32 GB oder mehr RAM hat, gilt als maximale Größe 32778 MB für die Auslagerungsdatei. Bei 64 GB RAM bleibt es also bei 32778 MB.

Desweitern sollte aus Performance Gründen folgende Zuordnung von Laufwerken ratsam:

• Laufwerk C:\ für die Windows Installation
• Laufwerk D:\ Auslagerungsdatei
• Laufwerk E:\ Exchange Installation
• Laufwerk F:\ Datenbank
• Laufwerk G:\ Logfiles der Datenbank

Bei mehreren Datenbanken bietet sich an Datenbank und Logfiles in Ordner zu Mounten, damit nicht die Laufwerksbuchstaben ausgehen.

In virtuellen Umgebungen können zusätzlich mehrere SCSI Controller genutzt werden:

• SCSI Controller 1 für C:, D: und E:
• SCSI Controller 2 für F:
• SCSI Controller 3 für G:

Exchange Server Installation

Nachdem das Betriebssystem vorbereitet wurde, kann Exchange Server 2016 installiert werden. Ab Exchange 2016 CU3 wird Windows Server 2016 unterstützt. Das CU3 eignet sich auch für die Installation und kann hier runtergeladen werden:

Kumulatives Update 3 für Exchange Server 2016 (KB3152589)

Die Exchange Installation ist dann unspektakulär, daher kommentiere ich nur an den relevanten Stellen:

Im Anschluss an die Lizenzbedingungen empfiehlt es sich “Empfohlene Einstellungen nicht verwenden” zu wählen, da sonst im weiteren Verlauf Einstellungen nicht verfügbar sind:

Exchange 2016 hat nur noch eine Rolle (Postfachrolle), abgesehen von der Edge Transport Rolle:

Nach der Auswahl der Postfachrolle, kann das Installationsverzeichnis angepasst werden. Wie oben beschrieben, sollte das Installationsverzeichnis auf einer separaten Partition oder Festplatte liegen:

Jetzt kann der Name der Exchange Organisation angegeben werden:

Sofern alle Voraussetzungen erfüllt sind, erscheint nur die Warnung, dass das Active Directory Schema erweitert wird, sofern es nicht vorher durchgeführt wurde.

Nach Abschluss der Installation kann der Windows Defender konfiguriert werden.

Windows Defender konfigurieren

Windows Defender ist auf Windows Server 2016 per Default aktiviert. Da Exchange Server einige Ausschlüsse vom Virenscanner benötigt, müssen diese entsprechend auch in Windows Defender hinterlegt werden. Gleiches gilt für Virenscanner anderer Hersteller.

Auf dem Exchange Team Blog findet sich dazu folgender Hinweis:

Windows Defender is on by default in Windows Server 2016. Attention to malware settings is particularly important with Exchange to avoid long processing times during installation and upgrade, as well as unexpected performance issues. The Exchange team recommends the Exchange installation and setup log folders be excluded from scanning in Windows Defender and other Anti-Virus software. Exchange noderunner processes should also be excluded from Windows Defender.

Quelle: Exchange Team Blog

Im Technet sind die Ausschlüsse für Exchange 2016 hier dokumentiert:

• Running Windows antivirus software on Exchange 2016 servers

Die Liste ist allerdings lang, daher hat Exchange MVP Paul Cunningham ein Script veröffentlicht, welches die Ordner, Prozesse und Dateitypen übersichtlich in 3 Dateien einsortiert. Das Script gibt es hier zum Download:

Generate Antivirus Exclusions for Exchange 2013 and 2016 Servers

Damit nicht alle Ausschlüsse manuell in Windows Defender eintragen werden müssen, habe ich hier ein entsprechendes Script erstellt, welches die Dateien von Paul’s Script benutzt und die Ausschlüsse per PowerShell zu Windows Defender hinzufügt:

Exchange 2016: Virenscanner Ausschlüsse (Script für Windows Defender)

Nachdem die Ausnahmen eingetragen wurden, kann Windows Defender wieder aktiviert werden.

Der Beitrag HowTo: Installation Exchange 2016 auf Windows Server 2016 erschien zuerst auf Franky's Web.

Die folgenden Fragen zum Noderunner Prozess bzw. Aussagen habe ich jetzt schon öfter in der ein oder anderen Form per Mail erhalten:

Noderunner.exe verbraucht fast den ganzen Arbeitsspeicher und hat fast immer 100 % CPU Last, was kann ich da machen?

Hier schon etwas verzweifelter:

Vom ersten Tag an hat der noderunner Ressourcen gefressen wir irre und ich weiß nicht warum.

Um ein bisschen Licht ins Dunkel zu bringen:

Noderunner.exe gehört zur Suchengine (FAST) von Exchange. Eingeführt wurde FAST mit Exchange 2013. Es handelt sich hierbei um die gleiche Suchengine die auch in SharePoint Server zum Einsatz kommt.

Im Normalfall verhält sich der Noderunner Prozess relativ ruhig. Hier zum Beispiel einmal ein aktueller Screenshot von meinem Exchange Server:

Allerdings gibt es Situationen, in denen der Noderunner Prozess aus dem Ruder läuft, die häufigste Ursache, die ich bisher gesehen habe, war ein oder mehrere defekte Suchindexe für die Postfachdatenbanken.

Der Status des Indexes lässt sich mit folgendem Befehl überprüfen:

Get-MailboxDatabaseCopyStatus

Falls der Index defekt ist, hilft es den Indes neu zu erstellen. Hier habe ich beschrieben, wie das funktioniert:

• Exchange 2013/2016: Index neu erstellen

Allerdings muss der Index natürlich neu aufgebaut werden, wenn er wie im Artikel beschrieben gelöscht wurde. Die Fast Engine muss also wieder alle Mails / Elemente der Datenbank indexieren, was wiederum zu erhöhter Last führt.

Ebenfalls ist bei einer Exchange Migration mit erhöhter Last zu rechnen, wenn Postfächer in neue Datenbanken verschoben werden. Auch in diesem Fall wird der Index neu aufgebaut. Das CU3 für Exchange 2016 bringt hier einige Verbesserungen bezüglich des Indexes:

The local search instance reads data from a database copy on the local server, also known as “Read from Passive”. As a result of this change, passive HA copy search instances no longer need to coordinate with their active counterparts in order to perform index updates.

Quelle: https://blogs.technet.microsoft.com/exchange/2016/09/20/released-september-2016-quarterly-exchange-updates/

Normalerweise ist die Fast Engine mit dem Indexieren eine ganze Weile beschäftigt, die Zeit die benötigt wird, hängt von der Größe der Datenbank und der darin enthaltenen Postfächer und Mails / Elemente ab. Geduld ist hier eine Tugend. Irgendwann ist der Index aufgebaut und der Noderunner Prozess bewegt sich wieder in geregelten Bahnen.

Bei knapp bemessenen Systemen kann Noderunner allerdings deutlich auf die Exchange Performance drücken, in diesem Fall lässt sich der Arbeitsspeicher für den Prozess begrenzen. In der folgenden CONFIG-Datei lässt sich der Maximalwert für Noderunner festlegen:

• %ExchangeInstallPath%Bin\Search\Ceres\Runtime\1.0\noderunner.exe.config

Hier kann ein entsprechender Wert in MB eingetragen werden. Dieser Wert gilt pro Noderunner Prozess. Zu wenig Arbeitsspeicher ist hier allerdings nicht sinnvoll, man kann sich vorstellen warum.

Der Beitrag Exchange 2016: Noderunner.exe hoher Speicherverbrauch und CPU Last erschien zuerst auf Franky's Web.

Die Ignite ist zu Ende und es sind bereits einige Aufzeichnungen der Konferenz zum Thema Exchange Server und Office 365 online gestellt worden. Hier eine Übersicht mit den entsprechenden Youtube Links:

• Unplug with the Microsoft Outlook experts
• Dive deeper into what’s new and what’s coming in Outlook on the web
• Discover Office 365 Groups – overview, what’s new and roadmap
• Learn about advancements in Office 365 Advanced Threat Protection
• Connect your business critical applications to Outlook and Groups
• Discover what’s new and what’s coming for Office Delve
• Design your Exchange infrastructure right (or consider moving to Office 365)
• Protect your business and empower your users with cloud Identity and Access Management
• Discover what’s new with Microsoft Exchange Public Folders
• Debate the top 10 reasons not to move your Exchange on-premises mailboxes to Exchange Online
• Discover modern support in Outlook for Exchange Online
• Unplug with the experts on Exchange Server and Exchange Online
• Move from Exchange 2007 to Modern Exchange
• Meet twin sons of different mothers – Exchange Engineers and Exchange MVPs
• Unplug with the experts on Microsoft Exchange Top Issues
• Peer behind the curtain – how Microsoft runs Exchange Online
• Explore the ultimate field guide to Microsoft Office 365 Groups
• Investigate tools and techniques for Exchange Performance Troubleshooting
• Understand how Microsoft protects you against Spoof, Phish, Malware, and Spam emails
• Manage Microsoft Office 365 Groups
• Build intelligent line-of-business applications leveraging the Outlook REST APIs
• Discover whats new in Active Directory Federation and domain services in Windows Server 2016
• Deliver management and security at scale to Office 365 with Azure Active Directory
• Throw away your DMZ – Azure Active Directory Application Proxy deep-dive
• Plan performance and bandwidth for Microsoft Office 365
• Run Microsoft Exchange Hybrid for the long haul
• Migrate to Exchange Online via Exchange Hybrid
• Deploy Microsoft Exchange Server 2016
• Understand the Microsoft Exchange Server 2016 Architecture
• Cert Exam Prep: Exam 70-345: Designing and Deploying Microsoft Exchange Server 2016
• Overcome network performance blockers for Office 365 Deployments
• Experience Scott Schnoll’s Exchange tips and tricks – LIVE
• Dive deeper into what’s new and what’s coming in Outlook mobile
• Fight back with advancements in Office 365 Advanced Threat Protection
• Discover what’s new and what’s coming for Microsoft Outlook

Ich finde es sind wieder einige interessante Sessions dabei. Ich heb mir das für verregnete Herbstabende auf. Die kommen bestimmt bald…

Der Beitrag Ignite 2016: Übersicht der Exchange und Office 365 Sessions erschien zuerst auf Franky's Web.

Heute hatte ich mal wieder einen Windows Server der sich nicht mehr per VSS sichern lies. Das Erstellen einen VSS Snapshots brach mit der folgenden Fehlermeldung ab:

Volumeschattenkopie-Dienstfehler: Beim Aufrufen von Routine "ConvertStringSidToSid(S-1-5-21-1629892529-1905228445-1032730592-4125.bak)" ist ein unerwarteter Fehler aufgetreten. hr = 0x80070539, Die Struktur der Sicherheitskennung ist unzulässig.
. 

Vorgang:
   OnIdentify-Ereignis
   Generatordaten werden gesammelt

Kontext:
   Ausführungskontext: Shadow Copy Optimization Writer
   Generatorklassen-ID: {4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f}
   Generatorname: Shadow Copy Optimization Writer
   Generatorinstanz-ID: {99b5bc19-d05b-4b74-9b9a-861f5ad10afa}

Die Fehlermeldung wurde mit der Event ID 8193 und Anwendungsereignisprotokoll generiert:

Die Ursache ist hier ein temporäres bzw. defektes Benutzerprofil gewesen. Um den Fehler zu beheben muss nur das defekte Benutzerprofil aus der Registry gelöscht werden:

Unter dem Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList findet sich das Profil, welches in der Fehlermeldung angemeckert wird. Da es sich hier eh um ein defektes Profil handelt, kann es gelöscht werden, wer auf Nummer sicher gehen will, kann den Schlüssel vorher exportieren:

Nachdem das der Schlüsselt gelöscht wurde, liefen auch die VSS Sicherungen wieder problemlos:

Der Beitrag VSS: Backup schlägt mit Fehlermeldung ConvertStringSidToSid fehl erschien zuerst auf Franky's Web.

Mit dem Windows Server 2016 hat Microsoft den Nano Server eingeführt. Nano Server haben keine GUI und sind noch reduzierter als Server Core Installationen. Nano Server werden nur remote verwaltet und entsprechende Images müssen zunächst erstellt werden. Für Hyper-V ist es recht einfach, da hier direkt VHD Dateien erzeugt werden können.

Es funktioniert allerdings auch mit VMware vSphere und ESXi. In diesem HowTo geht es darum einen Nano Server unter ESXi 6 laufen zu lassen.

Damit das Nano Server Image erstellt werden kann, ist eine GUI Installation von Windows Server 2016 erforderlich (Build Server). Dies kann ebenfalls eine VM sein.

Vorbereitung

Damit das Nano Server Image erstellt werden kann, müssen zunächst ein paar Vorbereitungen erledigt werden. Dafür wird als Erstes das Verzeichnis „NanoServer“ von der Installations DVD auf die lokale Festplatte des Build Servers kopiert. Ich kopiere das komplette Verzeichnis nach C:\

Damit später die VMware Treiber integriert werden können, wird ein leeres Verzeichnis mit dem Namen „VMware-Drivers“ im Verzeichnis „c:\NanoServer“ erstellt. Hier landen später die Treiber für SCSI-Controller und Netzwerkkarte:

Im weiteren Verlauf wird das Tool WinImage benötigt. WinImage kann hier als Testversion runtergeladen werden:

http://www.winimage.com/download.htm

Die Installation von WinImage ist selbsterklärend.

Weiter geht es mit den VMware Treibern.

Treiber aus VMware Tools extrahieren

Die benötigen Treiber sind bereits in den VMware Tools Image enthalten. Die VMware Tools können also einfach an den Build Server gemountet werden:

Alternativ lasen sich die aktuellen VMware Tools direkt von der VMware Website runterladen:

https://my.vmware.com/de/group/vmware/details?downloadGroup=VMTOOLS1009&productId=577

Auf welchen Weg die VMware Tools zum Build Server kommen spielt letztens Endes keine Rolle, die VMware Tools müssen nur entpackt, aber nicht installiert werden. Das Entpacken geschieht mit folgendem Befehl:

.\setup64.exe /a /p C:\NanoServer\VMware_Tools_Extracted

Im Dialog muss dann noch einmal das Verzeichnis angegeben werden. Ich wähle hier das Verzeichnis „VMware_Tools_Extracted“ aus:

Nachdem die Tools entpackt wurden, sollte sich entsprechender Inhalt im Verzeichnis finden lassen:

Die Treiber für den Nano Server können jetzt in das Verzeichnis „VMware-Drivers“ kopiert werden. Die relevanten Treiber habe ich schon rausgesucht. Wer die Pfade wie oben beschrieben benutzt hat, kann einfach die folgenden Befehle ausführen:

Copy-Item -Path "C:\NanoServer\VMware_Tools_Extracted\VMware\VMware Tools\VMware\Drivers\vmxnet3\NDIS6\*" -Destination C:\NanoServer\VMware-Drivers -Recurse

Copy-Item -Path „C:\NanoServer\VMware_Tools_Extracted\VMware\VMware Tools\VMware\Drivers\memctl\*“ -Destination C:\NanoServer\VMware-Drivers -Recurse Copy-Item -Path „C:\NanoServer\VMware_Tools_Extracted\VMware\VMware Tools\VMware\Drivers\pvscsi\*“ -Destination C:\NanoServer\VMware-Drivers -Recurse Copy-Item -Path „C:\NanoServer\VMware_Tools_Extracted\VMware\VMware Tools\VMware\Drivers\video_wddm\*“ -Destination C:\NanoServer\VMware-Drivers -Recurse Copy-Item -Path „C:\NanoServer\VMware_Tools_Extracted\VMware\VMware Tools\VMware\Drivers\vmci\device\*“ -Destination C:\NanoServer\VMware-Drivers -Recurse

Jetzt befinden sich die Treiber die für Nano Server benötigt werden unter C;\NanoServer\VMware-Drivers:

Nano Server VHD erstellen

Da der NanoServerImageCreator nicht direkt VMDK Dateien erstellen kann, wird zunächst eine VHD erstellt. Damit ein Nano Server Image erstellt werden kann, müssen zunächst die PowerShell Module importiert werden:

Import-Module .\NanoServerImageGenerator.psd1

Jetzt kann auch schon das Image erstellt werden:

New-NanoServerImage -MediaPath D: -TargetPath .\NanoServer1.vhd -ComputerName "NanoServer1" -EnableRemoteManagementPort -DriverPath "C:\NanoServer\VMware-Drivers" -DeploymentType Host -Edition Standard

Zusätzlich muss noch das Administrator Passwort angegeben werden:

Jetzt läuft der Prozess los und baut ein Nano Server Image:

Das Image enthält noch keine Rollen, wer direkt Rollen mit installieren möchte, kann die entsprechend schon angeben. Wenn der Prozess abgeschlossen ist, liegt das die VHD Datei vor:

VHD zu VMDK konvertieren

Damit VMware etwas mit dem Nano Server anfangen kann, muss die VHD-Datei in das VMDK Format umgewandelt werden. Für diesen Zweck wurde WinImage installiert. Hier kann unter dem Menüpunkt „Disk“ der Punkt „Convert Virtual Hard Disk image“ ausgewählt werden:

Dann wird die NanoServer.vhd angegeben:

„Create Fixes Size…“ wird so belassen:

Im nächsten Schritt wird das Image als NanoServer.vmdk abgespeichert:

Ein letzten Schritt noch einmal mit OK bestätigen und schon ist aus dem VHD eine VMDK geworden:

Hinweis: Das VMDK Format beinhaltet immer 2 Dateien: –flat enthält die Daten, die andere Datei ist eine Beschreibungsdatei.

VM erstellen

Jetzt haben wir alles zusammen was benötigt wird um eine VM auf dem ESXi Host zu erstellen. Das Erstellen der VM erledige ich mit dem vSphere Client. Mit dem WebClient stehe ich immer noch auf Kriegsfuß. Ich kommentiere mal nur die relevanten Stellen:

Bitte merken auf welchem Datastore die VM angelegt wurde, hier muss später noch das VMDK hochgeladen werden:

Anzahl CPU und RAM je nach belieben:

Als Netzwerkkarte kann VMXNET 3 ausgewählt werden, da die Treiber integriert wurden:

der SCSI Controller spielt an dieser Stelle keine Rolle, da zunächst keine Virtual Disk erstellt werden und somit auch kein SCSI Controller vorhanden ist:

Es werden keine Festplatten erstellt:

Die VM ist erstellt. Jetzt können die beiden VMDK Dateien in den Datastore hochgeladen werden:

Wichtig: Beide .VMDK Dateien müssen in den Datastore hochgeladen werden. Nur eine VMDK wird im Datatorebrowser angezeigt:

VMDK zur VM hinzufügen

Nachdem die VMDKs in den Datastore hochgeladen wurden, kann eine Festplatte zugeordnet werden. Dazu die Eigenschaften der VM öffnen und „Hinzufügen“ wählen:

„Festplatte“ auswählen:

„Vorhandene Festplatte“ auswählen:

Entsprechendes VMDK angeben:

Festplatte als IDE Disk einbinden:

Konfiguration abschließen.

Jetzt kann die VM gestartet werden. Nach dem der Nano Server hochgefahren ist, kann die restliche Konfiguration erledigt werden:

Die IP Adresse kann zum Beispiel vergeben werden. Hier zeigt sich auch das die Treiber erfolgreich integriert wurden, denn die VMXNET 3 Karte wird erkannt:

Hinweis: Der ESX zeigt an das die VMware Tools nicht installiert sind:

Das ist auch korrekt, denn es wurden nur die Treiber integriert, aber nicht der VMware Tools Dienst installiert. Derzeit scheint das auch nicht möglich zu sein. Ich denke hier wird VMware in Zukunft eine angepasste Version der VMware Tools anbieten. Zumindest hoffe ich das.

Es folgen in nächster Zeit weitere Artikel zum Thema Nano Server (Verwaltung, Rollen, etc).

Der Beitrag Windows Nano Server und VMware ESXi erschien zuerst auf Franky's Web.

Seit diesem Monat verteilt Microsoft auch Windows Updates, ähnlich wie bei Exchange Server, als Update Rollup.

In Update Rollups werden mehrere Updates zusammengefasst. Dies hat zum einen den Vorteil das nicht zig einzelne Updates installiert werden müssen, sondern deutlich weniger. Der Nachteil ist allerdings, dass sich bestimmte Updates nicht mehr einzeln abwählen oder deinstallieren lassen. In wie weit es hier zu Problemen kommen kann, bleibt abzuwarten.

In diesem Artikel finden sich entsprechende Hintergrundinformationen zu der geänderten Update Strategie:

https://blogs.technet.microsoft.com/windowsitpro/2016/08/15/further-simplifying-servicing-model-for-windows-7-and-windows-8-1/

Gerade bei Exchange Servern durften einzelne Updates nicht installiert werden. Zum Beispiel gab es in der Vergangenheit Probleme mit .NET 4.6.1 auf Exchange Servern. Aus diesem Grund finde ich es etwas hinderlich, wenn nicht mehr direkt erkenntlich ist, welche Updates im Update Rollup enthalten sind. Hier wird die Zukunft zeigen, ob es vermehrt zu Problemen kommt.

Der Beitrag Microsoft verteilt jetzt auch Windows Updates als Update Rollup erschien zuerst auf Franky's Web.

Die Ransomware DXXD greift offenbar Windows Server direkt an. DXXD verschlüsselt wie auch andere Ransomware Dateien und hängt an die verschlüsselte Datei die Endung .dxxd an.

Bisher ging ein Angriff auf Windows Server meistens von einem infizierten Client aus, der dann Dateien auf Netzlaufwerken verschlüsselt hat. Im Forum von Bleeping Computer wird allerdings vermutet das Brute Force Attacken auf den RDP Dienst durchgeführt werden um die Server direkt zu infizieren.

Ob tatsächlich RDP verwendet wird, ist derzeit noch unklar. Ich nehme es aber trotzdem mal zum Anlass darauf hinzuweisen, dass RDP nicht direkt im Internet erreichbar sein darf. Ich kenne da leider so Einige, die ein simples Portforward benutzen um schnell auf Server zugreifen zu können.

Deutlich besser wäre es ein VPN zu konfigurieren, das unterstützt selbst der billigste Router und ist immer noch besser als RDP direkt im Internet erreichbar zu machen. Und nein: den Port von 3389 auf irgendetwas anderes zu ändern macht keinen Unterschied.

Auch eine Richtlinie, die Accounts nach einer bestimmten Anzahl von falschen Kennwörtern sperrt, ist keine gute Idee. Im schlimmsten Fall betrifft das bei einer Brute Force Attacke ziemlich viele Konten, die alle gesperrt sind.

Deutlich besser: VPN mit 2 Faktor Authentifizierung. Das ist zumindest meine Meinung zu dem Thema. RDP ist eine angenehme Sache um Server innerhalb des eigenen Netzwerks zu verwalten, aber nicht geeignet für die Fernwartung aus dem Internet. Es kommt doch auch niemand auf die Idee, seine Management Schnittstellen (vSphere, iLO, DRAC etc.) direkt aus dem Internet erreichbar zu machen. Oder doch? Fühlt sich jemand angesprochen? Wenn ja, solche Schnittstellen im Internet zu finden, ist ähnlich einfach wie diese Webseite zu finden, einfach mal hier „iLO“ oder „vSphere“ als Suchbegriff eingeben: https://www.shodan.io

Egal, ich schweife ab. RDP also nicht im Internet erreichbar machen. Punkt. Selbst im internen Netzwerk sollte RDP nicht für jeden erreichbar sein, sondern entsprechend eingeschränkt werden. Mit der Windows Firewall ist das schnell gemacht, entsprechende Regel suchen:

Und im Reiter „Bereich“ ein Subnetz, Range oder IPs angeben, die RDP nutzen dürfen:

Auch wichtig: Das kleine Häkchen hier bitte nicht entfernen:

Und für die Windows Firewall gilt immer folgendes:

Immer!

Der Beitrag DXXD: Ransomware greift Windows Server offenbar direkt an erschien zuerst auf Franky's Web.

Seit heute ist Windows Server 2016 auch im MSDN Abo verfügbar:

Windows Server 2016 war bzw. ist ja bereits als Eval Version verfügbar. Die Demo läuft allerdings „nur“ 180 Tage. Jetzt gibt es Windows Server 2016 auch im MSDN mit entsprechenden Produktschlüsseln die nicht zeitlich begrenzt sind.

Darauf habe ich gewartet, jetzt steht ein Update der eigenen kleinen Umgebung an. Exchange 2016 ist ebenfalls supported für Windows Server 2016.

Scheinbar bin ich allerdings nicht der Einzige der es mitbekommen hat:

Eine Installationsanleitung für Exchange 2016 auf Windows Server 2016 habe ich bereits hier veröffentlicht.

Der Beitrag Windows Server 2016 im MSDN verfügbar erschien zuerst auf Franky's Web.

Um eine Exchange Datenbank zu löschen ist etwas mehr nötig, als nur die Benutzerpostfächer in eine neue Datenbank zu verschieben. Exchange Datenbanken enthlaten auch Systempostfächer, die nicht im EAC angezeigt werden.

Beim Versuch eine Exchange Datenbank zu löschen bzw zu entfernen kommt es dann zu folgender Fehlermeldung:

This mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, public folder mailboxes or arbitration mailboxes, Audit mailboxes. To get a list of all mailboxes in this database, run the command Get-Mailbox -Database <Database ID>. To get a list of all mailbox plans in this database, run the command Get-MailboxPlan. To get a list of archive mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -Archive. To get a list of all public folder mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -PublicFolder. To get a list of all arbitration mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -Arbitration. To get a list of all Audit mailboxes in this database, run the command Get-Mailbox -Database <Database ID> -AuditLog.

Wie schon eingangs erwähnt, handelt es sich hier um Systempostfächer. Via Exchange Management Shell sind die Postfächer sichtbar und müssen ebenfalls in eine andere Datenbank verschoben werden:

Die Monitoring Postfächer (HealthMailbox) können mit folgendem Befehl in eine andere Datenbank verschoben werden:

Get-Mailbox -Database FWDB1 -monitoring | New-MoveRequest –TargetDatabase FWDB

Nachdem alle Monitoring Postfächer verschoben wurden, kann geprüft werden ob noch weitere Systempostfächer in der zu entfernenden Datenbank vorhanden sind:

get-mailbox -Database fwdb1 -Monitoring 
get-mailbox -Database fwdb1 -AuditLog 
get-mailbox -Database fwdb1 -Archive 
get-mailbox -Database fwdb1 -RemoteArchive 
get-mailbox -Database fwdb1 -PublicFolder 
get-mailbox -Database fwdb1 -Arbitration 
get-mailbox -Database fwdb1 -AuxAuditLog 
get-mailbox -Database fwdb1 -GroupMailbox

Wenn noch weitere Postfächer vorhanden sind, können die ebenfalls mit einem MoveRequest verschoben werden. Der Status der Moverequest lässt sich mit folgendem Befehl prüfen:

Get-MoveRequest | Get-MoveRequestStatistics

Sobald alle Moverequest den Status „Completed“ haben, können die Moverequest mit dem folgenden Befehl entfernt werden:

Get-MoveRequest | Remove-MoveRequest

Jetzt kann die Datenbank entfernt werden:

Get-MailboxDatabase FWDB1 | Remove-MailboxDatabase

Die Datenbank Dateien werden dabei nicht gelöscht und müssen manuell gelöscht werden.

Der Beitrag Exchange 2016: Datenbank entfernen / löschen erschien zuerst auf Franky's Web.

Gerade habe ich einen neuen Exchange 2016 CU3 in meine Exchange Organisation installiert. Nach der Konfiguration konnte Outlook 2016 allerdings keine Verbindung herstellen, sondern fragte nach Anmeldeinformationen:

Die erste Vermutung war dass irgendetwas mit Autodiscover nicht stimmt und ich eventuell vergessen hatte eine URL richtig zu konfigurieren. Ein kurzer Test der Autodisover Konfiguration war allerdings erfolgreich:

Offensichtlich hatte ich ein Authentifizierungsproblem, daher bin ich die Einstellungen der virtuellen Verzeichnisse des Exchange Servers durchgegangen. Das MAPI Verzeichnis (für MAPIoverHTTP) war dabei mein erster Anlaufpunkt, denn über dieses Viertuelle Verzeichnis baut Outlook 2016 die Verbindung per Default zu Exchange 2016 auf.

Bei meiner Recherche ist mir aufgefallen, dass in meinem Fall keine Authentifizierungsmethode für das MAPI Verzeichnis aktiviert war:

Normalerweise sind hier per Standardeinstellung „NTLM“ und „Aushandlung“ aktiviert, so wie im nächsten Screenshot zu erkennen:

Nachdem ich die beiden Authentifizierungsmethoden aktiviert hatte, funktionierte auch die Outlook Verbindung problemlos.

Kleine Anmerkung: Der neue Exchange Server wurde auf Windows Server 2016 installiert, da ich gerade angefangen habe von Windows 2012 R2 zu Server 2016 zu migrieren. Möglicherweise liegt hier noch ein Bug mit Exchange 2016 auf Windows Server 2016 vor. Bei einer Neuinstallation von Exchange 2016 (erster Server in der Organisation) konnte ich dieses Problem bisher nicht nachvollziehen.

Der Beitrag Neuer Exchange 2016 Server – Outlook fragt nach Anmeldeinformationen erschien zuerst auf Franky's Web.