Mein Blog ist nun schon relativ lange per HTTPS abrufbar, allerdings war bisher auch immer die ungesicherte HTTP Version verfügbar. Der Hintergrund waren Links die auf http:// verwiesen haben und somit die Verschlüsselung aufgebrochen haben. Auch diverse eingehende Links von anderen Webseiten verweisen auf http://www.frankysweb.de und nicht auf https://www.frankysweb.de. Aus diesem Grund habe ich recht lange gezögert diese Seite ausschließlich per HTTPS erreichbar zu machen.

Ich habe nun aber scheinbar eine funktionierende Lösung gefunden, zumindest waren meine Tests soweit erfolgreich…

Alle Links in der WordPress Datenbank wurden von http auf https umgestellt und mittels HTACCESS gibt es einen 301-Redirect von http auf https. Bisher gab es immer wieder Probleme mit WordPress Plugins die nicht so richtig funktionieren wollten. Damit zusätzlich nicht ständig die Verschlüsselung neu ausgehandelt werden muss, ist auch Keep-Alive aktiviert. Dies hat einen deutlichen Geschwindigkeitsschub bei HTTPS-Verbindungen gebracht.

Auch die Downloads laufen nun via HTTPS. Hier gab es auch immer mal wieder Probleme…

Falls jemand Probleme feststellt, dann bitte eine kurze Mail schicken. Falls dieser Beitrag einfach wieder verschwinden sollte, musste ich wohl ein Backup der Datenbank einspielen. Dieser Beitrag wäre dann nicht im Backup enthalten

Der Beitrag FrankysWeb erzwingt nun HTTPS erschien zuerst auf Frankys Web.

Auf dem Technical Summit 2016 hat Siggi Jagott verraten das es die REST Api auch für lokale (on-premises) Exchange Server geben wird:

• Microsoft Technical Summit 2016 – Endlich zuhause

Markus hat des Artikel gelesen und mich auf einen Kommentar von auf dem Exchange Team Blog aufmerksam gemacht:

On-Premises Architectural Requirements for the REST API

Der Artikel auf dem Exchange Team Blog geht unter anderem darauf ein, dass für die REST Api Exchange 2016 CU3 im Hybrid Modus erforderlich ist. Im Klartext: Keine REST Api ohne Cloud. Dies wird auch auf Nachfrage von Markus in den Kommentaren bestätigt.

Interessanter Zufall: Ich wollte gerade meine Testumgebung auf Exchange 2016 CU4 aktualisieren und bin über das folgende virtuelle Verzeichnis im IIS gestolpert:

Wenn man nun mal unter folgenden Link vorbeischaut, sieht man schnell eine “gewisse Ähnlichkeit”

Get Started with Mail, Calendar, and Contacts REST APIs

Sieht so aus, als wäre die REST Api schon da? Ich habe mir gedacht, ich probiere es einfach mal aus.

Für den Test habe ich ein kleines PowerShell Script benutzt:

$creds = get-credential
$url = "https://outlook.frankysweb.com/api/v2.0/me/messages"
$request = invoke-webrequest $url -Credential $creds
$answer = $request.content | ConvertFrom-Json

Ich habe zuerst die Anmeldeinformationen des Administrators angegeben:

Das Script läuft schon mal fehlerfrei durch:

Und die Antwort sieht vielversprechend aus:

Die Api liefert sogar eine ganze Menge Daten:

So lässt es sich wunderbar durch die Daten browsen:

Zum Vergleich, so sieht das Postfach in OWA aus:

In der Ausgabe der Daten via REST Api sieht man allerdings mehrere Mails, während im OWA Posteingang nur eine Mail zu sehen ist. Mein kleines Script hat sich einfach alle Mails geholt, da ich nicht weiter gefiltert habe, auch die Gesendeten:

Ich habe es mit Exchange 2016 CU3 in der Testumgebung ausprobiert, der noch nie den Hybrid Configuration Wizard, geschweige denn den Hybrid Modus gesehen hat. Die Testumgebung hat nicht mal eine Internetverbindung.

Man könnte also durchaus sagen: Mehr on-premises geht nicht! Trotzdem scheint die REST Api zu funktionieren. Hat man vieleicht keine Pläne die REST Api für lokale Exchange Server zu veröffentlichen, weil sie schon längst da ist?

Mit Exchange 2016 CU4 funktioniert es übrigens auch, andere Versionen konnte ich auf die Schnelle nicht auftreiben.

Ich werde mal etwas weiter spielen und dann einen ausführlicheren Artikel zu dem Thema schreiben.

Der Beitrag Exchange 2016: REST Api für lokale Exchange Server schon verfügbar? erschien zuerst auf Frankys Web.

In diesem Artikel hatte ich bereits geschrieben, dass die neue REST Api auch bereits mit lokalen Exchange 2016 ab CU3 funktioniert. Die REST Api ist eine recht neue Schnittstelle, die zunächst nur in Office 365 bzw. Exchange Online verfügbar war. Stand heute (20.12.2016), konnte ich keine genauen Informationen finden, ob diese Schnittstelle für lokale Installationen supported wird. REST mit ausschließlich lokalen Exchange 2016 Installationen funktioniert aber bereits erstaunlich gut. Mehr dazu in diesem Artikel.

Warum lieber REST als EWS?

Jetzt gibt es also primär zwei Schnittstellen, die für die Anbindung von Tools und Programmen an Exchange Server zur Verfügung stehen:

Exchange Web Services (EWS) und REST Api

Beide Schnittstellen werden über den IIS Webserver auf den Exchange Servern bereit gestellt:

Ebenfalls nutzen beide Schnittstellen das HTTP (bzw HTTPS) Protokoll für die Kommunikation. Die beiden Schnittstellen sind sich also ähnlich, jedoch hat die REST Api einen ganz entscheidenden Vorteil:

Die REST Api ist komplett Plattformunabhängig. Im Gegensatz zu EWS muss für REST keine Bibliothek installiert werden. Um EWS zu nutzen, muss auf dem entsprechenden Rechner die “Echange Web Services Managed API” installiert werden, die EWS Api setzt wiederum .NET Framework voraus und wird nur für Windows Betriebssysteme unterstützt.

Diese Abhängigkeiten gibt es bei REST nicht, denn hier werden einfache HTTP Requests verwendet, die nahezu von jedem beliebigen Gerät oder Programm ausgelöst werden können. Die Antwort auf eine Anfrage via REST Api wird im JSON Format ausgeliefert und ist somit auch für leicht weiterzuverwenden. Der Zugriff auf Exchange Daten (Postfächer, Kalender, Aufgaben, etc) ist via REST also von nahezu jedem Gerät, Programm oder Betriebssystem möglich. Hier liegt der große Vorteil gegenüber EWS.

Hier gibt es nähere Informationen zu REST und JSON:

• https://de.wikipedia.org/wiki/Representational_State_Transfer
• https://de.wikipedia.org/wiki/JavaScript_Object_Notation

Beispiele für den Zugriff auf REST Api

Wie schon erwähnt, ist ein Zugriff auf die REST Api ziemlich einfach möglich, daher gibt es hier ein paar kleine Beispiele:

PowerShell (Windows)

Mit der PowerShell habe ich meine ersten Versuche gestartet. Der folgende Einzeiler genügt um die Mails via REST Api abzurufen:

$restdata = Invoke-RestMethod -Uri "https://mail.frankysweb.de/api/v2.0/me/messages" -Credential (Get-Credential)

Die Variable $restdata enthält nun die Daten die von der Api geliefert wurden.

Auf die Daten im Objekt $restdata lässt sich jetzt einfach zugreifen, hier zum Beispiel die Empfänger:

Oder beispielsweise auch der Zeitpunkt des Empfangs:

Curl (Linux)

Hier mal ein kleines Beispiel mittels Curl auf einem Linux Rechner. Damit die Authentifizierung klappt, musste ich die “Standard Authentifizierung” auf dem “API” Verzeichnis im IIS aktivieren:

Benutzername und Passwort musste ich als Base64 String codieren, den String konnte ich dann zur Authentifizierung nutzen:

echo -n 'user@frankysweb.de:meinPassWort' | base64
curl -X GET -H "Authorization: Basic dXNlckBmcmFua3lzd2ViLmRlOm1laW5QYXNzV29ydA==" -H "Content-Type: application/json" https://mail.frankysweb.de/api/v2.0/me/messages

Curl liefert natürlich erst einmal nur die “Rohdaten” im JSON Format zurück. Mit der Hilfe von Python lassen sich die Rohdaten lesbarer formatieren und beispielsweise als Datei speichern:

curl -X GET -H "Authorization: Basic dXNlckBmcmFua3lzd2ViLmRlOm1laW5QYXNzV29ydA==" -H "Content-Type: application/json" https://mail.frankysweb.de/api/v2.0/me/messages | python3 -m json.tool >> /tmp/rest

So lässt sich der Inhalt schon besser verstehen:

Funktionsweise der REST Api

Die oben genannten Beispiele sind sehr einfach, jedoch ist die REST Api deutlich mächtiger. Zum Beispiel lässt sich schon im Request bestimmen, welche Daten man erhalten möchte. So muss man erst gar nicht viele Daten abrufen, um diese später wieder zu filtern.

Das folgende Beispiel liefert zum Beispiel nur Absender und Betreff von Gesendeten Mails:

$restdata = Invoke-RestMethod -Uri "https://mail.frankysweb.de/api/v2.0/me/MailFolders/sentitems/messages/?`$select=Sender,Subject" -Credential (get-credential)

Die REST Api erlaubt es aber auch Daten zu senden, hier wird zum Beispiel eine Mail gesendet:

$mail = '
{
  "Message": {
    "Subject": "Test via REST",
    "Body": {
      "ContentType": "Text",
      "Content": "Dies ist ein Test"
    },
    "ToRecipients": [
      {
        "EmailAddress": {
          "Address": "frank@frankysweb.de"
        }
      }
    ]
  },
  "SaveToSentItems": "true"
}
'

invoke-RestMethod -Uri "https://mail.frankysweb.de/api/v2.0/me/sendmail" -Method Post -Body $mail -ContentType "application/json" -Credential (get-credential)

Gleiches gilt natürlich auch für andere Datentypen, wie zum Beispiel Kalendereinträge, Aufgaben und Kontakte. Um einen Einblick in die REST Api zu bekommen, einfach mal in die Dokumentation schauen.

Dokumentation für die REST Api

Die Dokumentation der REST Api findet sich hier:

• Mail API Reference
• Calendar API Reference
• Contacts API Reference
• Notifications API Reference
• User Photo API Reference
• Groups API Reference
• Office 365 Data Extensions (Office 365)
• Outlook Extended Properties
• Synchronize Messages
• Synchronize Folder Hierarchy

Einige Funktionen (zum Beispiel Office 365 Groups / Office 365 Dataextensions) sind nur in Verbindung mit Office 365 möglich.

Anpassungen Sophos UTM Web Application Firewall für REST Api

In diesem Artikel hatte ich die Konfiguration der Sophos UTM Web Application Firewall (WAF) in Verbindung mit Exchange 2016 beschrieben. Als der Artikel entstanden ist, gab es die REST Api in Exchange 2016 on-Premises noch nicht. Basierend auf den genannten Artikel sind nur zwei kleine Anpassungen an der Konfiguration nötig, damit die REST Api auch mit der Sophos UTM Webserver Protection funktioniert.

Im Firewall Profil, werden die folgenden Pfade für das “Exchange Webservices” Profil hinzugefügt:

• /api
• /API

Zusätzlich müssen die folgenden Pfade als Ausnahme für die Regel “Webservices Hardening” definiert werden:

• /api/*
• /API/*

Weitere Anpassungen sind nicht nötig.

Fazit

Die REST Api funktioniert schon erstaunlich gut. Leider kenne ich bisher nicht den Hintergrund, warum diese Schnittstelle bisher nicht für lokale Exchange Installationen offiziell bekannt gemacht wurde. Wahrscheinlich wird es noch Änderungen an der Schnittstelle geben, daher sollten besser noch keine produktiven Anwendungen für die REST Schnittstelle angepasst werden. Zum Ausprobieren in der Testumgebung ist es aber sehr gut geeignet.

Der Beitrag Exchange Server 2016 REST Api erschien zuerst auf Frankys Web.

Heute wurde ein neues Update für die Sophos UTM veröffentlicht, eigentlich sind es sogar zwei Updates:

Die beiden Updates können hier runtergeladen werden:

http://ftp.astaro.de/UTM/v9/up2date/

Hier einmal die Release Notes:

Fix [NUTM-2392]: [AWS] Allow the user to select the security group to port during conversion
Fix [NUTM-5327]: [AWS] Confd object missing after instance recovery in HA scenario
Fix [NUTM-5339]: [AWS] [RESTD] allow unauthenticated access from localhost
Fix [NUTM-5466]: [AWS] ssh disabled – No connection to stack instances
Fix [NUTM-5882]: [AWS] Logging & Reporting overview does not show any information
Fix [NUTM-5901]: [AWS] [RESTD] Improve webadmin UI and documentation
Fix [NUTM-5981]: [AWS] Conversion feature always converts to BYOL
Fix [NUTM-6013]: [AWS] Fix communication issue with S3
Fix [NUTM-5110]: [Access & Identity] Since version 9.404 L2TP with Android doesn’t work
Fix [NUTM-5562]: [Access & Identity] UTM to UTM RED Tunnel doesn’t work anymore after only TLS 1.2 is allowed
Fix [NUTM-5674]: [Access & Identity] REDs offline after HA takeover – ‚RED is not bound to this system, disabling device‘
Fix [NUTM-5840]: [Access & Identity] 3G to WAN failover on RED15/RED50 does not work
Fix [NUTM-5661]: [Basesystem] quagga security update (CVE-2016-1245)
Fix [NUTM-5701]: [Basesystem] named fails to start after invalid host record
Fix [NUTM-5779]: [Basesystem] bind security update (CVE-2016-8864)
Fix [NUTM-5769]: [Confd] Configd error Datatype.pm line 319
Fix [NUTM-5787]: [Confd] Bridge can’t be converted back to ethernet if only red interfaces are used
Fix [NUTM-5997]: [Localization] Japanese translation error if using a string longer than 64 bytes as common_name
Fix [NUTM-5533]: [Network] ‚Block invalid packets‘ option doesn’t block invalid packets
Fix [NUTM-5595]: [Network] SIP Helper behavior clarification in ‚Any‘ expectation mode
Fix [NUTM-5513]: [Reporting] RRD reporting doesn’t show the warnings and alerts of the slave nodes in cluster setups
Fix [NUTM-5655]: [Reporting] Wrong count on websecvisits data
Fix [NUTM-5792]: [WAF] WAF coredump’ed after regular session cleanup
Fix [NUTM-5856]: [WAF] Special characters are encoded when HTML rewrite is enabled
Fix [NUTM-5075]: [WebAdmin] User test is not working with LDAP special characters in Base DN
Fix [NUTM-5317]: [WebAdmin] Persistent cookie for user portal working only once
Fix [NUTM-5761]: [WebAdmin] Translation in Webadmin is not consistent (web protection)
Fix [NUTM-5811]: [WebAdmin] Misleading default QoS interface downlink/uplink values
Fix [NUTM-5888]: [WebAdmin] Since v9.408 Authentication Server test fails after first creation
Fix [NUTM-5963]: [Web] Sandstorm not delivering Emails files from „Scan Pending“ state
Fix [NUTM-5303]: [WiFi] Characters in Hotspot terms of use not encoded correctly
Fix [NUTM-5876]: [WiFi] User field is blank on login at Hotspot with voucher
Fix [NUTM-6128]: [WiFi] FollowUp-NUTM-5303 – Characters in Hotspot terms of use not encoded correctly

Und die Release Notes für das kleinere Update:

Previous 9.409 Up2Date could fail to apply on UTMs that were installed with 9.406 or older

Ich habe es bisher nicht hinbekommen das vorherige Update auf meiner virtuellen UTM zu installieren. Auch dieses Update lässt sich bei mir nicht fehlerfrei installieren. Nach dem Update fehlen virtuelle Netzwerkkarten und neue Netzwerkkarten werden nicht erkannt (VMware ESXi). Ich habe daher meine UTM mit der aktuellen Version neu installiert. Bisher läuft das aktuelle Update mit der Neuinstallation.

Vor dem Update einer virtuellen UTM sollte also ein Snapshot erzeugt werden, damit im Fehlerfall schnell wieder eine lauffähige Konfiguration wiederhergestellt werden kann.

Der Beitrag Neues Update für Sophos UTM 9.4 erschien zuerst auf Frankys Web.

Ich wünsche euch allen fröhliche Weihnachten. Bleibt gesund und habt ein paar schöne Tage mit euren Liebsten.

Denkt euch, ich habe das Christkind gesehen!
Es kam aus dem Walde,
das Mützchen voll Schnee,
mit rotgefrorenem Näschen.
Die kleinen Hände taten ihm weh,
denn es trug einen Sack, der war gar schwer,
schleppte und polterte hinter ihm her.

Was drin war, möchtet ihr wissen?
Ihre Naseweise,ihr Schelmenpack –
denkt ihr, er wäre offen der Sack?
Zugebunden bis oben hin!
Doch war gewiss etwas Schönes drin!
Es roch so nach Äpfeln und Nüssen!

(Anna Richter)

Ich find den Bär so knuffelig, hat jemand eine Idee wo man genau DEN Bär kaufen kann? Das wäre doch ein nettes Maskottchen

Der Beitrag Fröhliche Weihnachten erschien zuerst auf Frankys Web.

RPCoverHTTP, besser bekannt als Outlook Anywhere wurde mit Exchange Server 2003 eingeführt. RPCoverHTTP wird genutzt, um Outlook ohne VPN an Exchange Server anzubinden, allerdings war es nicht immer problemlos umzusetzen oder zu implementieren.

Im Wesentlichen werden bei RPCoverHTTP die Remote Procedure Calls über das http Protokoll getunnelt um RPC über das Internet zu transportieren. Die unterschiedlichen Protokolle (RPC und http), sorgten dabei für ein paar Probleme. http ist ein Halb-Duplex Protokoll, wohingegen RPC ein Voll-Duplex Protokoll ist, welches synchrone eingehende und ausgehende Verbindung voraussetzt. Outlook nutzt daher zwei http Verbindungen, eine für eingehende Daten (RPC_IN_DATA) und eine für ausgehende Daten (RPC_OUT_DATA). Diese beiden http-Verbindungen eines Clients mussten Firewalls und Loadbalancer immer zum gleichen Zielserver leiten (Session Affinity), da sonst keine Verbindung zu Stande kam. Manche Firewalls und Loadbalancer bekommen das heute leider noch nicht ordentlich auf die Reihe.

Das nächste Problem betrifft die modernen Firewalls, die das zugrundeliegende Protokoll genauer analysieren um Angriffe abzuwehren. Diese Firewalls fanden im http Protokoll plötzlich nicht nur die http Kommandos (get, head ,put, post), sondern eben Remote Procedure Calls und kappten die Verbindung wegen Protokollanomalien oder filterten die Verbindung entsprechend. Das Resultat war meistens keine Verbindung mit Exchange via Outlook Anywhere.

Mit Exchange dem Service Pack 1 für Exchange 2013 wurde das MAPIoverHTTP Protokoll eingeführt. MAPIoverHTTP kommt im Gegensatz zu RPCoverHTTP ohne Remote Procedure Calls aus, welches die oben genannten Nachteile eliminiert. Da auch alle aktuellen Outlook Versionen MAPIoverHTTP unterstützten, könnte man darüber nachdenken das klassische Outlook Anywhere (RPCoverHTTP) abzuschalten und nur noch das moderne Outlook Anywhere (MAPIoverHTTP) zu benutzen. Die Firewall Regeln könnten wieder enger gezogen werden und auch die Loadbalancer müssen keine Session Affinity mehr beachten.

Hier eine Übersicht der Clients die MAPIoverHTTP unterstützen:

Quelle: Microsoft Technet

Im Bild aus dem Technet Artikel ist allerdings ein kleiner Fehler: Outlook 2007 wird von Exchange 2016 überhaupt nicht unterstützt, egal mit welchem Protokoll. Die Mac Versionen bleiben hier außen vor, denn Outlook für Apples Betriebssystem nutzt die EWS Schnittstelle und ist nicht von RPCoverHTTP oder MAPIoverHTTP abhängig.

Leider kann man RPCoverHTTP nicht getrennt von MAPIoverHTTP ein- oder ausschalten. MAPIoverHTTP lässt sich beispielsweise bei Exchange 2013 und Exchange 2016 ein- und abschalten. RPCoverHTTP ist immer aktiv und lässt sich nicht ohne weiteres abschalten. Vielleicht wird diese Funktion ja noch mit einem CU nachgereicht.

Wer aber nur noch Outlook Versionen einsetzt die MAPIoverHTTP verstehen, könnte aber das Regelwerk an seiner Firewall wieder deutlich enger ziehen. An einer Sophos UTM Web Protection sind beispielsweise viel weniger Ausnahmen nötig. Ich konnte das Regelwerk soweit zusammen stampfen, dass nur noch eine Ausnahme für “Statisches URL Hardening” übrig bleibt:

Bei einer neuen Exchange Organisation, könnte man ebenfalls drüber nachdenken, ob RPCoverHTTP noch benötigt wird. Ein kompletter Artikel für die Konfiguration der UTM ohne RPCoverHTTP folgt noch.

Wie seht ihr das Thema? Lieber MAPIoverHTTP? Lieber RPCoverHTTP? Oder beides?

Der Beitrag Exchange 2016: Wird RPCoverHTTP noch benötigt? erschien zuerst auf Frankys Web.

Das Thema Active Directory habe ich hier in letzter Zeit etwas vernachlässigt, daher kommt hier zum mal wieder ein leichter Einstieg in das Thema.

Vorwort

In diesem Artikel geht um die Installation eines neuen Active Directory auf der grünen Wiese. In dieser Testumgebung gibt es bisher nur einen Server der zum Domain Controller hochgestuft werden soll und somit eine neue Gesamtstruktur bereit stellt. Auf dem Server ist Windows Server 2016 installiert und natürlich alle zum Zeitpunkt verfügbaren Updates.

Vorbereitung

Die Vorbereitungen sind schnell erledigt. Der Server muss mit einem entsprechenden Hostnamen konfiguriert sein und über eine fest vergebene IP-Adresse verfügen. In meinem Fall wähle ich den Hostnamen FWDC1

Als IP Adresse vergebe ich die 172.16.100.11

Gateway und mindestens ein DNS Server sollten ebenfalls angegeben werden. Das waren im Prinzip schon alle nötigen Vorbereitungen.

Active Directory Rolle installieren

Damit ein neues Active Directory installiert werden kann, muss zunächst die Rolle “Active Directory-Domänendienste” installiert werden:

Die erforderlichen Features für die Rolle werden ebenfalls installiert:

Die restlichen Abfragen können alle mit “Weiter” bestätigt werden

Zum Schluss wird noch eine Zusammenfassung angezeigt

Nach der Installation der Binärdaten kann der Server zum Domain Controller hoch gestuft und somit das Active Directory installiert werden:

Domain Controller hochstufen

Falls das vorherige Fenster des Assistenten schon geschlossen wurde, ist der Assistent für das Heraufstufen zum Domain Controller auch im Server Manager verfügbar:

Wer sich auf einer grünen Wiese befindet, kann den Namen für das Active Directory frei vergeben. Mittlerweile werden Namen wie firma.local in neuen Umgebungen nicht mehr verwendet. Besser wäre hier ein Name wie ad.firma.de. Trotzdem können auch weiterhin Namen wie firma.local oder firma.intern verwendet werden. Der Stammdomainname darf allerdings nicht einteilig sein. “Firma” oder “Intern” geht also nicht.

Ich wähle als Name ad.frankysweb.com:

Der folgende Dialog lässt sich etwas Zeit, wenn keine DNS-Delegierung erstellt werden kann, bei dem ersten Domain Controller und öffentlichen DNS-Servern ist dies völlig normal. In diesem Fall versucht dieser Server nun eine DNS-Delegierung für ad.frankysweb.com in der Zone frankysweb.com anzulegen. Da frankysweb.com von einem Nameserver im Internet gehostet wird und nicht von diesem Server aktualisiert werden kann, läuft die Erstellung der Delegierung in einen TimeOut.

Im Normalfall wird eine Delegierung vom öffentlichen DNS zum internen DNS nicht benötigt und man würde kaum den zukünftigen DC per Port 53 (DNS) im Internet erreichbar machen wollen.

Gesamtstruktur- und Domänenfunktionsebene können bei einer neuen Umgebung auf “Server 2016” gestellt werden. In diesem Fall werden alle Active Directory Features verfügbar, es lässt sich allerdings kein Server mehr zum DC hochstufen, der nicht mindestens Server 2016 als Betriebssystem verwendet.

Das Kennwort für die Wiederherstellungsmodus SICHER verwahren.

Im darauf folgenden Dialog wird auch ein entsprechender Hinweis angezeigt, dass keine Delegierung erstellt werden konnte:

Der NetBIOS Name “AD” ist doch ganz schön, kurz, knackig, einprägsam. Der erste Teil des Stammdomainnamens wird per Default zum NetBIOS Namen der Domain. In meinem Fall ist das “AD”. Hier lässt sich der NetBIOS Name aber auch anpassen:

Gut, AD mag jedem Admin etwas sagen, den Benutzern allerdings nicht, denkbar wäre auch der Firmenname als NetBIOS Name.

Aus dem NetBIOS Namen ergeben sich später auch die Benutzernamen, zum Beispiel “AD\frank”. Als NetBIOS Name lässt sich hier auch “frankysweb” eintragen. Der Benutzername wäre dann “frankysweb\frank” oder “frank@ad.frankysweb.com”.

Die Speicherpfade können normalerweise so belassen werden:

Zum Schluss noch eine Zusammenfassung vor dem Heraufstufen

Nette Zugabe: Der Assistent zeigt auch direkt den PowerShell Befehl für das Heraufstufen an. Für neue Domain Controller ist dies ganz praktisch.

Aufgrund der DNS-Delegierung dauert auch die Voraussetzungsüberprüfung etwas, die beiden Warnungen sind normal.

Nach dem Klick auf “Installieren” wird der Server zum Domain Controller heraufgestuft und startet neu.

Nach dem Neustart sind noch ein paar kleine Nacharbeiten nötig.

Nacharbeiten

Der neue Domain Controller ist jetzt bereits funktionsfähig, allerdings sind noch ein paar kleine Nacharbeiten zu erledigen die gerne vergessen werden.

Hier noch einmal das Beispiel für den Benutzernamen (wie oben beschrieben):

Nachdem der Domain Controller installiert wurde, muss noch eine Reverse Lookup Zone erstellt werden:

Die Optionen können soweit übernommen werden, es handelt sich um eine primäre Zone:

Die Zone soll auf alle DCs dieser Domain repliziert werden:

Als Typ IPv4:

Hier muss nur das Subnetz angegeben werden:

Es werden nur sichere dynamische Updates erlaubt, das heißt es dürfen nur Domain Computer ihre eigenen DNS Records aktualisieren.

Nachdem die Reverse Lookup Zone angelegt wurde, wird auf dem Host-A Eintrag des Domain Controllers der Haken bei “Entsprechenden Zeigereintrag aktualisieren” aktiviert:

Das Setzen des Häkchens erzeugt dann einen PTR für den DC in der Reverse Lookup Zone:

Nachdem die Reverse Lookup Zone angelegt wurde, muss noch das Subnetz für den Active Directory Standort anleget werden, dies wird auch gerne vergessen:

Auch hier wird das entsprechende oder die entsprechenden Subnetze angegeben für die Domain Controller an diesem Standort zuständig sind. In meinem Fall ist das nur 172.16.100.0/24

Somit haben wir einen Active Directory Standort mit einem Domain Controller für das Subnetz 172.16.100.0/24

Es ist übrigens eine gute Idee alle Organisationeinheiten vor versehentlichem Löschen zu schützen, das ist mit einem kleinen Powershell Befehl erledigt und kann nicht schaden:

Get-ADOrganizationalUnit -filter * -Properties ProtectedFromAccidentalDeletion | where {$_.ProtectedFromAccidentalDeletion -eq $false} | Set-ADOrganizationalUnit -ProtectedFromAccidentalDeletion $true

Eine wichtige Sache noch zum Schluss: Die Uhrzeit!

Die Uhrzeit im Active Directory ist nach wie vor extrem wichtig. Daher sollte ein Domain Controller mit einem Zeitserver synchronisiert werden. In dieser Umgebung gibt es bisher nur einen Domain Controller, daher stellt sich hier nicht die Frage welcher DC mit einer externen Zeitquelle synchronisiert werden muss. Wenn es mehr als einen DC in der Domain gibt: Der DC mit der FSMO Rolle “PDC” wird mit einer Zeitquelle synchronisiert:

Um einen NTP Server auf dem PDC einzustellen genügen die folgenden beiden Befehle:

w32tm /config /manualpeerlist:ptbtime1.ptb.de /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time

Die Nacharbeiten sind soweit abgeschlossen und das Active Directory ist grundlegend benutzbar. Da das Active Directory allerdings in den meisten Firmen eine, wenn nicht sogar die, Kernkomponente ist, ist es ratsam mindestens zwei Domain Controller zu installieren.

Die Installation eines zweiten Domain Controllers folgt im nächsten Artikel.

Der Beitrag Server 2016: Active Directory Installation (Teil 1) erschien zuerst auf Frankys Web.

Und schon ist das Jahr 2016 vorbei. Frohes Neues!

FrankysWeb hat 2016 sogar einen kleinen Rekord geschafft. Die Besucherzahlen sind bisher jedes Jahr gestiegen, 2016 ist die Besucherzahl allerdings erstmals auf über 1 Millionen Besucher pro Jahr gestiegen. Ich bin mal gespannt ob sich diese Zahl 2017 halten oder am Besten sogar weiter steigern lässt.

Ein Artikel aus 2015 ist dieses Jahr auf Platz 1 mit den meisten Besuchern:

• Exchange 2010 und Outlook 2016 – Autodiscover

Der Artikel hat es auf fast 54000 Besucher gebracht, dicht gefolgt mit knapp 52000 Besuchern von:

• Windows FileServer vor Ransomware / Crypto Locker schützen

Platz 3 geht mit knapp 50000 Besuchern an:

• Exchange 2016: Installation auf Windows Server 2012 R2

Der Rest teilt sich auf die anderen Beiträge auf. Knapp 600 Artikel gibt es hier mittlerweile. Die meisten Downloads gehen nach wie vor an den Exchange Reporter: über 13000 mal wurde das Script runtergeladen. 2017 wird es auch mal wieder ein Update geben.

Für das Jahr 2017 habe ich auch schon ein paar Ideen, mal schauen was sich davon umsetzen lässt. Verraten wird aber noch nichts.

Für die erste Exchange User Group OWL im Jahr 2017 laufen übrigens die schon Anmeldungen, bei Interesse also schnell anmelden:

• https://www.frankysweb.de/eugo/

Und auch unsere Partnercommunity die Exchange User Group Berlin wird 2017 aktiv sein:

• http://exusg.de/veranstaltungen/terminplanung-2017/

Der Termin im Q2 ist bei mir schon im Kalender vorgemerkt.

In diesem Sinne: “Tschüss 2016, Willkommen 2017”

Der Beitrag Frohes Neues! erschien zuerst auf Frankys Web.

Vorwort

Im ersten Teil dieses Artikels wurde ein neues Active Directory installiert. Bisher gibt es allerdings nur einen Domain Controller. Um das Active Directory bei Ausfall einen Servers trotzdem verfügbar zu halten, sollten pro Domäne mindestens zwei Domain Controller installiert werden.

In diesem Artikel wird der zweite Domain Controller installiert und konfiguriert.

Vorbereitung

Die Vorbereitungen sind, wie auch beim ersten Domain Controller, schnell erledigt. Es wird wieder ein sprechender Hostname vergeben, in diesem Fall FWDC2:

Auch eine statische IP-Adresse wird wieder benötigt. Als DNS-Server wird diesmal der schon installierte Domain Controller angegeben:

Zum Schluss wird der Server als Mitglied in das vorhandene Active Directory hinzugefügt:

Das waren schon alle Vorbereitungen für den zweiten Domain Controller.

Active Directory Rolle installieren

Wie auch beim ersten Domain Controller, muss zunächst die Active Directory Rolle installiert werden. Die Vorgehensweise ist bei allen Domain Controllern identisch und wurde bereits im ersten Teil beschrieben, daher spare ich mir hier die Details.

Sobald die Rolle installiert ist, kann der Server zum Domain Controller heraufgestuft werden:

Zweiten Domain Controller hochstufen

Zum Hochstufen des zweiten Domain Controllers wird die Option “Domänencontroller zu einer vorhandenen Domäne hinzufügen” ausgewählt. Da der Server bereits Mitglied des Active Directory ist, muss bei “Domäne” nicht weiter ausgewählt werden. Wichtig ist, das an dem Server ein Domain Administrator angemeldet ist, sonst fehlen die entsprechenden Rechte zum hochstufen eines DCs.

Anhand der IP-Adresse wird nun das Subnetz und der dazugehörige Active Directory Standort ermittelt (wie in Teil 1 angelegt). Das Kennwort wieder sicher verwahren:

Auch hier erscheint wieder der Hinweis, dass keine Delegierung für den DNS Server erstellt werden kann, wie bereits erwähnt, ist dieses normal:

Im nächsten Dialog kann angegeben werden, von welchem Domain Controller die initiale Replikation stattfinden soll. Wenn es bereits mehrere Domain Controller gibt, oder der erste Domain Controller in einem neuen Standort installiert wird, kann hier ein DC angegeben werden, der am besten geeignet ist (Schnellste Verbindung, geringste Auslastung, etc):

Die Pfade für die Installation werden im Normalfall so belassen:

Jetzt wird wieder eine Zusammenfassung der Einstellungen angezeigt und es gibt wieder die Möglichkeit, die Einstellungen als Script zu speichern:

Mit einem Klick auf Installieren wird der Server zum Domain Controller hochgestuft und die initiale Replikation durchgeführt:

Der Server wird automatisch neugestartet:

Sobald der Neustart durchgeführt wurde, steht der neue Domain Controller zur Verfügung, aber auch hier gibt es wieder ein paar Nacharbeiten.

Nacharbeiten

Zunächst wieder das Thema mit der Uhrzeit. Der erste Domain Controller, bzw der Domain Controller mit der Masterrolle PDC, wird mit einer externen Zeitquelle synchronisiert. Im ersten Artikel ist dies ein NTP Server aus dem Internet. Alle anderen Domain Controller in dieser Domain, können nun die Zeit über den PDC synchronisieren.

Mit den folgenden Befehlen lässt sich dies konfigurieren (der Parameter heißt wirklich “domhier”, es wird keine Name eingetragen, einfach so übernehmen):

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time

Eigentlich ist die Sache mit der Uhrzeit ganz einfach: PDC mit externer Zeitquelle synchronisieren, alle weiteren DCs der Domain mit PDC synchronisieren, Clients bekommen ihre Zeit von den Domain Controllern. Leider wird oft die Synchronisation mit einer externen Zeitquelle vergessen.

Jeder DNS Server sollte über mindestens zwei Weiterleitungen verfügen, hier dient als Beispiel der Router und Google DNS als Ziele für den DNS Forward. Hier wird aber NICHT ein anderer Domain Controller angegeben.

Der Hintergrund ist folgender: Alle DNS Anfragen die dieser DNS Server nicht direkt beantworten kann, wird er an die Adressen weiterleiten, die als Weiterleitung konfiguriert sind, daher werden hier normalerweise öffentliche DNS Server eingetragen. Ein anderer Domain Controller wird die Anfrage ebenfalls nicht beantworten können und müsste sie ebenfalls weiterleiten, es macht also im Normalfall keinen Sinn, hier einen anderen DC anzugeben:

Damit veraltete DNS Einträge auch nach gewisser Zeit gelöscht werden, sollte ebenfalls die “Alterung” aktiviert werden:

Gleiches gilt auch für die Reverse Lookup Zone:

Damit veraltete Einträge gelöscht werden, muss dazu auf den DNS-Servern der “Aufräumvorgang” aktiviert werden:

Zu guter Letzt noch eine Einstellung die den ersten Domain Controller betrifft. Der zweite Domain Controller wird als primärer DNS Server eingestellt, die Loopback Adresse als sekundärer DNS Server:

Auch dem zweiten Domain Controller sollten die Einstellungen bereits passen.

Somit läuft das Active Directory auf zwei Domain Controllern und ist gegen den Ausfall eines einzelnen Servers abgesichert. Ein ordentliches Backup muss selbstverständlich trotzdem eingerichtet werden.

Der Beitrag Server 2016: Active Directory Installation (Teil 2) erschien zuerst auf Frankys Web.

Vorwort

Der folgende Artikel beschreibt eine Möglichkeit mit der Active Directory Benutzer eine Passwortänderung auf einer Website durchführen können. Dafür wird das Windows Feature “Web Access für Remote Desktop” etwas zweckentfremdet. Eine komplette Installation und Konfiguration der Remote Desktop Dienste ist dafür nicht erforderlich.

Hinweis: Der hier beschriebene Weg eignet sich nur dazu das bekannte Active Directory Passwort zu ändern. Ein Zurücksetzen eines vergessenen Passwortes ist hiermit nicht möglich.

Die Passwort Änderung mittels Website ist für Benutzer interessant, die an Rechnern arbeiten, die nicht Mitglied des Active Directory sind.

Vorbereitung

Als Vorbereitung reicht ein installierter Server mit Windows Server 2016 oder Windows Server 2012 R2 aus. Der Server muss Mitglied des Active Directory sein und über die aktuellen Windows Updates verfügen.

Installation Web Access für Remote Desktop

Auf dem vorbereiteten Server kann nun via Server Manager die Rolle “Remotedesktopdienste” hinzugefügt werden:

Es müssen keine bestimmten Features hinzugefügt werden. Entsprechende Abhängigkeiten werden automatisch installiert. Daher kann hier einfach auf “Weiter” geklickt werden:

Als Rollendienst wird nur “Web Access für Remotedesktop” benötigt:

An dieser Stelle werden nun alle Abhängigkeiten für den Rollendienst “Web Access für Remotedesktop” hinzugefügt:

Die Rollendienste für den IIS Webserver können ebenfalls so belassen werden:

Nach der Zusammenfassung können die Rollen installiert werden:

Sobald die Rollen installiert wird, kann die Konfiguration beginnen.

Konfiguration

Damit man sich die URL für Passwortänderungen später einfacher merken kann, wird zunächst ein Alias für den Server im DNS angelegt. Ich hab als Beispiel den Alias “password” gewählt und lasse ihn auf den Server zeigen:

Im IIS Manager auf dem Server gibt es nun unter der “Default Web Site” die Anwendung “RDWeb”, darunter findet sich die Anwendung “Pages”. Die Anwendung “Pages” wird ausgewählt und die “Anwendungseinstellungen” geöffnet:

In den Anwendungseinstellungen muss nun die Einstellung “PasswordChangeEnabled” auf den Wert “true” geändert werden:

Jetzt kann bereits die Passwortänderung getestet werden. Das Portal zu Passwortänderung ist unter der folgenden URL erreichbar:

• https://localhost/RDWeb/Pages/de-DE/password.aspx

oder in meinem Fall (wie im DNS eingetragen):

• https://password.ad.frankysweb.com/RDWeb/Pages/de-DE/password.aspx

Die Seite sieht nun wie folgt aus:

Da aber die URL noch recht umständlich ist, wird noch eine Umleitung von der Default Web Site eingerichtet. Dazu wird im IIS Manager die “Default Web Site” ausgewählt und “HTTP-Umleitung” ausgewählt:

Als Ziel wird nun die URL des Portals eingetragen und die folgenden Einstellungen ausgewählt:

Wichtig: Als Umleitungsziel nicht die “localhost”-Url eingeben! In meinem Fall ist das Weiterleitungsziel https://password.ad.frankysweb.com/RDWeb/Pages/de-DE/password.aspx.

Die Umleitung sorgt dafür das Aufrufe für https://password.ad.frankysweb.com an das Passwortportal weitergeleitet werden:

Benutzer können nun mit ihrem Browser einfach die entsprechende URL aufrufen (https://password.ad.frankysweb.com) und ihr Passwort ändern. Allerdings sieht die Seite für ein Portal zu Passwortänderung noch ein bisschen merkwürdig aus. Mit ein paar Anpassungen lässt sich aber auch das beheben.

Anpassungen

Mit ein paar kleinen Anpassungen sieht die Seite eher wie ein Portal zu Passwort Änderung aus. In der folgenden Datei habe ich diese Strings angepasst:

• C:\Windows\Web\RDWeb\Pages\de-DE\RDWAStrings.xml
• PageTitle: Passwort ändern
• HeadingRDWA: Passwort ändern
• HeadingApplicationName: Portal zur Passwortänderung

Zusätzlich habe ich noch in der folgenden Datei einen String angepasst:

C:\Windows\Web\RDWeb\Pages\de-DE\password.aspx

• L_CompanyName_Text: Passwort ändern

Jetzt noch Logo der Seite austauschen, zum Beispiel gegen ein Schloss:

• C:\Windows\Web\RDWeb\Pages\images\logo_02.png (48×48 Pixel)

Jetzt sieht das Passwort Portal auch für den Benutzer ansprechend aus:

Mit ein paar weiteren Anpassungen geht es auch noch etwas schlichter oder angepasst an die Coporate Identity:

Bevor das Portal auf die Benutzer losgelassen wird, sollte noch ein entsprechendes SSL Zertifikat hinterlegt werden.

Benutzer müssen allerdings auch rechtzeitig informiert werden, damit Sie ihr Passwort ändern, dies könnte man per Mail erledigen. Ein entsprechender Artikel dazu folgt.

Der Beitrag Active Directory: Passwortänderung mittels Webseite erschien zuerst auf Frankys Web.

In diesem Artikel hatte ich bereits beschrieben, wie eine Webseite eingerichtet werden kann, auf der Benutzer ihr Passwort ändern können. Gerade Benutzer die mit einem Rechner arbeiten der nicht Mitglied des Active Directory ist, stellt die Passwortänderung oft ein Problem dar.

Mittels der Webseite haben diese Benutzer nun die Möglichkeit ihr Passwort rechtzeitig zu ändern. Allerdings müssen die Benutzer auch informiert werden, wenn das Passwort in naher Zukunft abläuft. Die einfachste Möglichkeit ist wohl eine Mail zu dem Benutzer zu schicken, so können auch externe Benutzer erreicht werden.

Um Benutzern rechtzeitig an die Passwortänderung zu erinnern, habe ich ein kleines PowerShell Script erstellt. Das Script kann hier runtergeladen werden:

PasswordReminder 1.03 KB

Download

Das Script muss natürlich noch etwas an die jeweilige Umgebung angepasst werden. Im wesentlichen müssen nur die Zeilen 1 – 32 an die eigenen Bedürfnisse angepasst werden:

Zeile 2 enthält die Anzahl der Tage nachdem ein Passwort geändert werden muss. In Zeile 3 wird festgelegt wie viele Tage vor Ablauf des Passwortes der Benutzer informiert werden soll.

Die Zeilen 6 – 8 enthalten die Angaben zum Mail Server über den die E-Mails versendet werden sollen.

Zeile 14 – 29 enthält den Text der Mail der dem Benutzer zugesendet wird. Folgende Variablen können benutzt werden:

• $GivenName: Vorname des AD Benutzers
• $Surname: Nachname des AD Benutzers
• $DaysBeforePasswordchange: Anzahl Tage bis zur Passwort Änderung
• $PasswoordExpireDate: Datum an dem das Passwort abläuft

Das Script benötigt die PowerShell CMDLets für das Active Directory (Get-ADUser). Die E-Mail wird im HTML Format an die E-Mail Adresse verschickt die dem Benutzer im Active Directory zugeordnet ist.

Der Beitrag Active Directory: Mail wenn Passwort abläuft erschien zuerst auf Frankys Web.

Wichtige Information für alle EUGO Teilnehmer. Wir mussten den Veranstaltungsort wechseln. Wir treffen uns wie gehabt am 10.02.2017 um 19:30 Uhr, allerdings nun in den Räumlichkeiten der “Habichtshöhe” in Bielefeld:

Allegro Habichtshöhe in Bielefeld

Bodelschwinghstr. 79
33604 Bielefeld

Link: Google Maps

Link: Website Allegro Habichtshöhe

Die ICS Datei wurde entsprechend aktualisiert und wir werden noch einen Newsletter verschicken. Die aktuelle ICS Datei gibt es hier:

https://www.frankysweb.de/eugo/

Wir nehmen natürlich auch weitere Anmeldungen entgegen und freuen uns schon auf das nächste Treffen.

Der Beitrag EUGO: Veranstaltungsort verschoben erschien zuerst auf Frankys Web.

Meine letzten Beiträge zum Thema Active Directory haben eine wichtige Frage zu Tage gefördert:

Wie soll das neue Active Directory heißen?

In diesem Artikel habe ich folgende Aussage getätigt:

Wer sich auf einer grünen Wiese befindet, kann den Namen für das Active Directory frei vergeben. Mittlerweile werden Namen wie firma.local in neuen Umgebungen nicht mehr verwendet. Besser wäre hier ein Name wie ad.firma.de. Trotzdem können auch weiterhin Namen wie firma.local oder firma.intern verwendet werden. Der Stammdomainname darf allerdings nicht einteilig sein. “Firma” oder “Intern” geht also nicht.

Nach diversen Mails und einem Kommentar habe ich festgestellt, dass ich diese Aussage vielleicht auch begründen sollte. Daher nun dieser Artikel. Eines möchte ich schon mal vorwegnehmen: Niemand muss sein vorhandenes Active Directory umbenennen oder nun zwingend neu installieren.

Wer allerdings ein nagelneues Active Directory installiert, der sollte sich, neben dem Design, auch über den Namen Gedanken machen.

Um genau zu sein, muss man sich über zwei Namen Gedanken machen: Den NetBIOS Namen und den DNS-Namen (FQDN) der neuen Umgebung. Dass eine Domain innerhalb des Active Directory zwei Namen trägt, wird bei der Installation deutlich. Bei der Installation eines neuen Active Directory wird zunächst der FQDN abgefragt:

In einem der folgenden Dialoge dann der NetBIOS Name:

Bei der Wahl der entsprechenden Namen, muss man sich zunächst einmal an die Konvention halten. Die folgenden Vorgaben gelten für den FQDN:

• maximal 255 Zeichen (kompletter FQDN)
• nur Groß/Kleinbuchstaben / Zahlen
• als Sonderzeichen ist nur “-“ (Bindestrich) zugelassen
• maximal 63 Zeichen pro Name

Für den NetBIOS Namen gilt:

• 15 Zeichen

zwar sind einige wenige Sonderzeichen erlaubt, aber es sollte darauf verzichtet werden und nur Buchstaben und Zahlen verwendet werden.

NetBIOS Name und FQDN sind von einander unabhängig und können/dürfen von einander abweichen. Des weiteren darf der FQDN nicht einteilig sein. Der FQDN darf also nicht .local oder .de lauten. Der FQDN muss mindestens aus zwei Teilen bestehen (frankysweb.local oder frankysweb.de). Einteilge Domainnamen werden von diversen Diensten nicht mehr unterstützt, bekanntestes Beispiel ist Exchange.

Soweit erst einmal zu den technischen Anforderungen. Zurück zur eigentlichen Frage, warum sollte ein neues Active Directory nicht einfach firma.local, firma.intern oder firma.lan heißen?

1. Top Level Domains (TLD) werden seit geraumer Zeit in allen erdenklichen Variationen verkauft. Die klassischen Top Level Domains wie .de und .com wurden mit immer exotischeren TLDs ergänzt, so ist denkbar das irgendwann auch .intern oder .local verkauft wird und als offizielle TLD geführt wird. Das würde unweigerlich Probleme bei der Namensauflösung geben.
2. Für nicht offizielle TLDs stellen öffentliche Zertifizierungsstellen keine SSL-Zertifikate aus, wer also interne Server mit einem Zertifikat einer öffentlichen CA ausstatten will, muss unweigerlich einen gültigen Namen verwenden. Ein offizielles Zertifikat für intranet.firma.local wird keine öffentliche CA ausstellen.
3. Der Active Directory Name soll eindeutig sein. Ein Zusammenschluss von zwei Firmen mit gleichen AD-Namen (Bsp. ad.local) wird Schmerzen verursachen, selbst wenn nur eine VPN Verbindung implementiert werden soll.

Bedenkt man das ein Active Directory über sehr lange Zeit genutzt wird und ein Umbenennen (wenn überhaupt möglich) oder eine Neuinstallation nur mit großen Aufwand möglich ist, dann sollten diese Punkte nicht vernachlässigt werden. Denn wer kann schon sagen welche TLDs in den nächsten 5 oder 10 Jahren registriert werden?

Die meisten Firmen haben eh schon eine Domain registriert, daher macht es Sinn auf dieser Domain aufzubauen. FrankysWeb dient als Beispiel. Ich habe die Domain frankysweb.de registriert, somit ist schon einmal sichergestellt, dass es keine zweite Domain gibt, die ebenfalls frankysweb.de heißt. Für diese öffentliche Domain an Zertifikate zu kommen ist auch kein Problem, denn sie ist ja offiziell registriert.

Der FQDN für das Active Directory könnte also beispielsweise ad.frankysweb.de lauten. Als NetBIOS Name könnte wiederum “frankysweb” genutzt werden. Die Benutzer könnten sich mit “frankysweb\benutzername” oder mit “benutzername@ad.frankysweb.de” anmelden. Rechnernamen lauten beispielsweise server1.ad.frankysweb.de. Sieht doch ganz hübsch aus und geht den oben genannten Problemen aus dem Weg.

Der FQDN den Active Directorys sollte übrigens nicht gleich des registrierten Domain Namens sein. In meinem Fall sollte das AD also nicht frankysweb.de heißen, dieser Name für das AD würde DNS-Splitbrain erzwingen und macht mehr Probleme als es löst.

Hier gibt es einen sehr alten MSDN Artikel zu diesem Thema, der aber immer noch gültig ist:

Best Practice Active Directory Design for Managing Windows Networks

Darin heißt es:

As a best practice use DNS names registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name, or if your organization merges with, acquires, or is acquired by other company that uses the same DNS names then the two infrastructures can never interact with one another.

Add a prefix that is not currently in use to the registered DNS name to create a new subordinate name. For example, if your DNS root name were contoso.com then you should create an Active Directory forest root domain name such as concorp.contoso.com, where the namespace concorp.contoso.com is not already in use on the network. This new branch of the namespace will be dedicated to Active Directory and Windows 2000 and can easily be integrated with the existing DNS implementation.

Die Empfehlungen sind also keineswegs neu.

Der Beitrag Active Directory: Wie soll das neue Active Directory heißen? erschien zuerst auf Frankys Web.

Outlook hat mich heute darauf hingewiesen, dass es gerne Updates installieren möchte:

Nach einem Klick auf “Jetzt aktualisieren” wurde allerdings nur der folgende Hinweis angezeigt:

Das hat leider nicht geklappt.

Leider konnte Office nicht installiert werden. Stellen Sie bitte sicher das eine Internetverbindung besteht, und versuchen Sie dann die Installation erneut.

Fehlercode: 30180-26

Die Windows Ereignisanzeige brachte leider kein Licht ins Dunkel. Ich hatte solche Probleme allerdings schon häufiger in Verbindung mit Proxies. In meinem Fall setze ich den Proxy der Sophos UTM (Web Protection) ein.

Im Log der UTM bin ich dann auf folgenden Eintrag gestoßen:

utm httpproxy[25807]: id=“0001″ severity=“info“ sys=“SecureWeb“ sub=“http“ name=“http access“ action=“pass“ method=“HEAD“ srcip=“XX“ dstip=“104.124.129.26″ user=““ group=““ ad_domain=““ statuscode=“301″ cached=“0″ profile=“REF_HttProContaInterNetwo (Internal)“ filteraction=“REF_DefaultHTTPCFFAction (Default content filter action)“ size=“0″ request=“0xe202d000″ url=“http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60/Office/Data/16.0.7571.2075/stream.x86.x-none.dat“ referer=““ error=““ authtime=“0″ dnstime=“48457″ cattime=“74″ avscantime=“0″ fullreqtime=“97848″ device=“0″ auth=“0″ ua=“OfficeClickToRun“ exceptions=“av,sandbox,ssl,fileextension,size“ category=“9998″ reputation=“unverified“ categoryname=“Uncategorized“

Zwar wurde die Verbindung nicht geblockt, aber scheinbar liegt trotzdem irgendein ein Problem vor.

Die Sophos UTM Web Protection bringt bereits eine Ausnahme für Windows Updates mit:

Diese Ausnahme habe ich um den folgenden Eintrag erweitert:

http://officecdn.microsoft.com

Nachdem die Regel gespeichert wurde, lies sich das Update installieren.

Ob gegebenenfalls noch weitere URLs in die Ausnahme aufgenommen werden müssen, konnte ich nicht feststellen. Wahrscheinlich helfen derartige Ausnahmen auch Problemen mit den Updates bei anderen Firewalls.

Falls das automatische Update nicht funktioniert, lassen sich die Updates auch manuell runterladen und installieren. Hier gibt es eine Übersicht der Office Updates:

Office Updates

In meinem Fall war es KB3127988 für Outlook 2016 welches ich zunächst nicht automatisch installieren konnte. Das Update kann hier direkt runtergeladen werden:

December 6, 2016, update for Outlook 2016 (KB3127988)

Der Beitrag Office Update und Sophos UTM: Fehlercode 30180-26 erschien zuerst auf Frankys Web.

Vorwort

Die Zertifizierungsstelle Let’s Encrypt bietet schon seit Längerem kostenlose Zertifikate an. Im Dezember 2015 hatte ich bereits einen Artikel zu dem Thema geschrieben, allerdings funktionierte zu dem Zeitpunkt der Windows Client noch nicht zuverlässig, sodass ein Umweg über einen Linux Rechner nötig war.

Jetzt ist mittlerweile etwas über ein Jahr vergangen und ich habe einen neuen Versuch gestartet.

Testumgebung

Die Testumgebung ist denkbar einfach aufgebaut. Es gibt nur zwei Windows Server 2016 die über einen Router mit dem Internet verbunden sind:

Einer der beiden Server ist Domain Controller, auf dem anderen ist Exchange 2016 CU4 installiert. Auf dem Router sind zwei Portweiterleitungen eingerichtet. Port 80 (http) und Port 443 (https) werden auf den Exchange Server weitergeleitet.

Exchange nutzt intern sowie extern den Hostnamen mail.frankysweb.de. Autodisover wird mit den Namen autodiscover.frankysweb.de veröffentlicht. Interne und externe URLs sind gleich konfiguriert.

Exchange ist bereits vollständig konfiguriert, daher behandelt dieser Artikel nur den Let’s Encrypt Teil. Ich brauche also ein Zertifikat mit zwei DNS Namen von Let’s Encrypt: mail.frankysweb.de und autodiscover.frankysweb.de

Zertifikat von Let’s Encrypt anfordern

Es gibt mittlerweile eine ganze Reihe von Clients mit denen Zertifikate von Let’s Encrypt angefordert werden können. Ich habe mich für den ACMESharp Client entschieden, da er sich per PowerShell nutzen lässt.

Das Anfordern der Zertifikate passiert auf dem Exchange Server. Damit die Validierung durchgeführt werden kann, müssen die Let’s Encrypt Server den Exchange Server unter den angeforderten Namen per Port 80 (HTTP) erreichen können.

Zuerst muss daher der ACMESharp Client installiert werden. Die Installation ist dank PSGallery einfach und kann direkt aus der PowerShell erfolgen. Dazu wird eine PowerShell als Administrator gestartet:

Die Installation des ACMESharp Clients kann nun mit dem folgenden Befehl durchgeführt werden:

Install-Module -Name ACMESharp -AllowClobber

Nun kann das Modul geladen werden und ein neuer Speicher für die Let’s Encrypt Zertifikate angelegt werden:

Import-Module ACMESharp
Initialize-ACMEVault

Jetzt kann die Registrierung bei Let’s Encrypt durchgeführt werden, dazu ist nur die Angabe einer E-Mail Adresse nötig:

New-ACMERegistration -Contacts mailto:admin@frankysweb.de -AcceptTos

Nach der Registrierung kann das Zertifikat und die Validierung der Domain Namen vorbereitet werden. Ich möchte ein Zertifikat mit zwei Domainnamen (mail.frankysweb.de und autodiscover.frankysweb.de) haben. Die Validierung der Namen soll via HTTP stattfinden:

New-ACMEIdentifier -Dns mail.frankysweb.de -Alias dns1
New-ACMEIdentifier -Dns autodiscover.frankysweb.de -Alias dns2
Complete-ACMEChallenge dns1 -ChallengeType http-01 -Handler iis -HandlerParameters @{ WebSiteRef = 'Default Web Site' }
Complete-ACMEChallenge dns2 -ChallengeType http-01 -Handler iis -HandlerParameters @{ WebSiteRef = 'Default Web Site' }

Hinweis: Der Parameter “-ChallengeType http-01” weist Let’s Encrypt an, die Domain Namen mail.frankysweb.de und autodiscover.frankysweb.de per HTTP Protokoll zu prüfen. Dazu bauen die Let’s Encrypt Server eine HTTP Verbindung zu diesen beiden Namen auf und versuchen pro Domain Name jeweils eine Datei abzurufen.

Damit sichergestellt ist, dass die autodisover.frankysweb.de und mail.frankysweb.de mir gehören, wird Let’s Encrypt eine HTTP Verbindung zu meinem Exchange Server aufbauen und diese URLs zu:

• http://autodiscover.frankysweb.de/.well-known/acme-challange/<Zeichenfolge>
• http://mail.frankysweb.de/.well-known/acme-challange/<Zeichenfolge>

Das entsprechende Verzeichnis lässt sich auch im IIS einsehen:

Allerdings akzeptiert die Default Website eines Exchange Servers im Normalfall keine HTTP Verbindungen auf Port 80, daher muss “SSL erforderlich” für das Verzeichnis “.well-known” abgeschaltet werden. Auch das ist per PowerShell schnell erledigt (oder auch mit dem IIS Manager):

Set-WebConfigurationProperty -Location "Default Web Site/.well-known" -Filter 'system.webserver/security/access' -name "sslFlags" -Value None

Sofern der Router nun Port 80 auf den Exchange Server weiterleitet und die DNS-Einträge für autodiscover.frankysweb.de und mail.frankysweb.de auf die WAN IP-Adresse des Routers zeigen, kann die Validierung durchgeführt werden:

Submit-ACMEChallenge dns1 -ChallengeType http-01
Submit-ACMEChallenge dns2 -ChallengeType http-01

Die Validierung hat nun den Status “Pending” haben. Nach kurzer Zeit sollte die Validierung erfolgt sein und den Status “Valid” bekommen. Der Status der Validierung lässt sich mit den folgenden Befehlen prüfen:

Update-ACMEIdentifier dns1
Update-ACMEIdentifier dns2

Sobald die Validierung erfolgt ist, kann das Zertifikat angefordert werden:

New-ACMECertificate dns1 -Generate -AlternativeIdentifierRefs dns1,dns2 -Alias multiNameCert
Submit-ACMECertificate multiNameCert
Update-ACMECertificate multiNameCert

Jetzt befindet sich das Zertifikat bereits im Let’s Encrypt Speicher, aber noch nicht im Windows Zertifikatsspeicher, daher wird es zunächst einmal aus dem Let’s Encrypt Speicher exportiert:

Get-ACMECertificate multiNameCert -ExportPkcs12 "D:\Zertifikat\cert1.pfx" -CertificatePassword <a href="mailto:'P@ssW0rd'">'P@ssW0rd'
</a>

Nach dem Exportieren ist das Zertifikat als PFX-Datei im entsprechenden Ordner gespeichert:

Jetzt kann es in den Windows Zertifikatspeicher importiert werden:

$password = ConvertTo-SecureString -String "P@ssW0rd" -Force –AsPlainText
Get-ChildItem -Path "D:\Zertifikat\cert1.pfx" | Import-PfxCertificate -CertStoreLocation cert:\localMachine\my –Exportable -Password $password

Jetzt muss das frische Zertifikat nur noch dem Exchange Server zugewiesen werden:

Add-PSSnapin *exchange*
Enable-ExchangeCertificate -Thumbprint "8ABEDEFDDCF0C82AFDE4E3FE3E80819FBE643AFD" -Services POP,IMAP,SMTP,IIS

Das war auch schon alles. Zertifikat angefordert und eingebunden:

Fazit

In meiner Testumgebung hat es wunderbar funktioniert, der Client macht was er soll und das auch komplett via PowerShell.

Let’s Encrypt stellt nur Zertifikate mit 3 Monaten Laufzeit aus, daher ist alle 3 Monate der Austausch der Zertifikate fällig. Mir war es daher wichtig das sich der komplette Prozess mit der PowerShell abbilden lässt. Denn so lässt sich auch der Austausch der Zertifikate komplett automatisieren. Dazu wird es noch entsprechende Beiträge geben.

Ausblick

Vielleicht kennt jemand dieses kleine Script von mir noch?

Exchange Certificate Assistent

Der bekommt mal ein Update…

Der Beitrag Exchange 2016: Kostenlose Zertifikate von Let’s Encrypt erschien zuerst auf Frankys Web.

Die DNS-Namen der konfigurierten URLs der virtuellen Exchange Verzeichnisse sind für das SSL-Zertifikat relevant. Die entsprechenden DNS-Namen müssen auf dem Zertifikat als SAN (Subject Alternate Name) vorhanden sein.

Dieses kleine Script listet alle konfigurierten DNS-Namen der Exchange 2016 Server auf. Somit lässt sich das Zertifikat entsprechend beantragen und ausstellen.

$AllExchangeServers = Get-ExchangeServer
foreach ($ExchangeServer in $AllExchangeServers)
{
 [array]$CertNames += (Get-ClientAccessService -Identity $ExchangeServer.Name).AutoDiscoverServiceInternalUri.Host
 [array]$CertNames += (Get-OutlookAnywhere -Server $ExchangeServer).Internalhostname.Hostnamestring
 [array]$CertNames += (Get-OutlookAnywhere -Server $ExchangeServer).ExternalHostname.Hostnamestring
 [array]$CertNames += (Get-MapiVirtualDirectory -Server $ExchangeServer).Internalurl.Host
 [array]$CertNames += (Get-MapiVirtualDirectory -Server $ExchangeServer).ExternalUrl.Host
 [array]$CertNames += (Get-OabVirtualDirectory -Server $ExchangeServer).Internalurl.Host
 [array]$CertNames += (Get-OabVirtualDirectory -Server $ExchangeServer).ExternalUrl.Host
 [array]$CertNames += (Get-ActiveSyncVirtualDirectory -Server $ExchangeServer).Internalurl.Host
 [array]$CertNames += (Get-ActiveSyncVirtualDirectory -Server $ExchangeServer).ExternalUrl.Host
 [array]$CertNames += (Get-WebServicesVirtualDirectory -Server $ExchangeServer).Internalurl.Host
 [array]$CertNames += (Get-WebServicesVirtualDirectory -Server $ExchangeServer).ExternalUrl.Host
 [array]$CertNames += (Get-EcpVirtualDirectory -Server $ExchangeServer).Internalurl.Host
 [array]$CertNames += (Get-EcpVirtualDirectory -Server $ExchangeServer).ExternalUrl.Host
 [array]$CertNames += (Get-OwaVirtualDirectory -Server $ExchangeServer).Internalurl.Host
 [array]$CertNames += (Get-OwaVirtualDirectory -Server $ExchangeServer).ExternalUrl.Host
}
$CertNames | select –Unique

Mit kleinen Anpassungen kann das Script auch verwendet werden, um Abweichungen der konfigurierten Hostnamen zu ermitteln.

Die Variable $CertNames enthält alle konfigurierten Hostnamen der Exchange Server. Diese DNS-Namen können dann für das Zertifikat verwendet werden.

Der Beitrag Exchange 2016: DNS-Namen für Zertifikate ermitteln (Quick & Dirty) erschien zuerst auf Frankys Web.

Mit der Hilfe von Gruppenrichtlinien oder der Registry lassen sich Schaltflächen, Funktionen oder Schaltflächen Gruppen deaktivieren. Dieses kleine Beispiel zeigt, wie der Microsoft Store in Outlook abgeschaltet werden kann.

Um bestimmte Schaltflächen oder Menüs abzuschalten werden diese beiden Komponenten benötigt:

• Office 2016 Administrative Template files (ADMX/ADML)
• Office 2016 Help Files: Office Fluent User Interface Control Identifiers

Der erste Download enthält Gruppenrichtlinieneinstellungen für Office 2016. Der zweite Download enthält Excel Dateien mit allen verfügbaren Schaltflächen / Gruppen und deren IDs.

Jede Schaltfläche in Outlook hat neben einen Namen auch eine ID. Name und ID stehen in den Excel Listen der Office 2016 Help Files.

Die Schwierigkeit ist daher die richtige ID zu finden. Der “Store”-Button aus diesem Beispiel heißt “OfficeExtensionsAppStore” (outlookexplorercontrols.xlsx) und hat die ID 16243:

Sobald man die richtigen IDs gefunden hat, lässt sich eine neue Gruppenrichtlinie erstellen.

Die Dateien aus dem Order ADMX der Office 2016 Administrative Templates müssen auf einem Domain Controller in den Ordner C:\Windows\PolicyDefinitions kopiert werden.

In einer Gruppenrichtlinie lässt sich jetzt die Option “Befehlsleisten-Schaltflächen und Menüelemente deaktivieren” aktivieren und die entsprechenden IDs angeben:

Nachdem die Gruppenrichtlinie angewendet wurde, ist die Schaltfläche “Store” ausgegraut. Auf diese Weise lassen sich nahezu alle Outlook Funktionen abschalten.

Man könnte zum Beispiel Benutzer daran hindern E-Mails zu drucken oder Anhänge an eine Mail anzuhängen. Anwendungsfälle gibt es sicherlich genug.

Kleiner Tipp: Ein Outlook in Englischer Sprache hilft ungemein beim Suchen der jeweiligen IDs.

Die Einstellungen können auch direkt in der Registry vorgenommen werden. In diesem Beispiel werden zwei Schaltflächen abgeschaltet:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\16.0\outlook\disabledcmdbaritemslist]
"TCID1"="16243"
"TCID2"="16373"

Die Zeichenfolge TCID wird dabei immer um eins erhöht. Natürlich lassen sich auf diesem Weg auch Word, Excel, PowerPoint usw. anpassen. Gruppenrichtlinien Templates und Help Files gibt es auch für ältere Office Versionen:

• Office 2013 Help Files: Office Fluent User Interface Control Identifiers
• Office 2010 Help Files: Office Fluent User Interface Control Identifiers
• Office 2013 Administrative Template files (ADMX/ADML)
• Office 2010 Administrative Template files (ADM, ADMX/ADML)

Der Beitrag Outlook 2016: Schaltflächen / Funktionen deaktivieren erschien zuerst auf Frankys Web.

Ich habe oft keine Lust lange Filter in der PowerShell für große Datenmengen einzutippen. Ich habe mir daher angewöhnt die Daten nachträglich zu filtern. Das PowerShell CMDLet “Out-GridView” erleichtert dieses Vorgehen ungemein.

Mit “Out-GridView” lassen sich Daten in Tabellenform darstellen und unterschiedlich sortieren. Gerade wenn man sich schnell einen Überblick verschaffen will, ist diese Funktion hilfreich.

So bekommt man zum Beispiel einen schnellen Überblick über die Exchange Postfachgrößen.

Get-Mailbox | Get-MailboxStatistics | select displayname,*size* | Out-GridView

Mit einem Klick auf die Spalte “TotalItemSize” wird die Tabelle nach den größten Postfächern sortiert:

Möchte man danach schnell die Tabelle nach “Gelöschten Elementen” sortieren, reicht ein Klick auf “TotalDeletedItemSize”. So muss kein neuer Befehl in der PowerShell eingegeben werden.

Auch die Darstellung größerer Datenmengen mit vielen Spalten ist kein Problem, da die Reihenfolge der Spalten nachträglich angepasst werden kann. Ebenfalls könne Spalten nachträglich ausgeblendet werden.

Zum Beispiel liefert der folgende Befehl ziemlich detaillierte Daten zu den Postfachstatistiken:

Get-Mailbox -resultsize unlimited | Get-MailboxStatistics | select * | Out-GridView

Durch das Sortieren und Ausblenden von Spalten lassen sich auch diese Daten wieder übersichtlich darstellen:

Durch Filter lassen sich diese Daten dann weiter einschränken:

Auch für die Message Tracking Logs funktioniert das wunderbar. So müssen keine langen Befehle mehr eingegeben werden, sondern man kann sich einfach die Daten später entsprechend zurecht legen.

Der folgende Befehl liefert zum Beispiel alle Mails der letzten 24 Stunden:

Get-MessageTrackingLog -start (get-date).adddays(-1) | select * | Out-GridView

Durch das Ausblenden von Spalten und Kriterien lässt sich diese Datenflut aber einfach darstellen:

Auch CSV-Dateien lassen sich auf die Weise schnell betrachten. Die Message Tracking GUI nutzt ebenfalls “Out-Gridview” für die Darstellung der Daten. Ebenfalls sehr praktisch in Verbindung mit “get-aduser”.

Vielleicht hilft es ja jemanden weiter…

Kleiner Tipp: Alle Message Tracking Logs der letzten 5 Jahre, oder die 5 GB CSV Datei, würde ich jetzt nicht unbedingt mit “Out-GridView” darstellen. Hier muss entsprechend gefiltert werden.

Der Beitrag PowerShell: Out-GridView für die Darstellung von Daten erschien zuerst auf Frankys Web.

Um die URLs und Hostnamen eines Exchange 2016 Servers festzulegen, kann das folgende Script benutzt werden:

#Hostname für Exchange Webservices, OWA, Outlook Anywhere, Active Sync:
$OutlookHostname = "outlook.frankysweb.de"
#Hostname für Autodiscover:
$AutodiscoverHostname = "autodiscover.frankysweb.de"

#OWA
$owa = "https://" + "$OutlookHostname" + "/owa"
write-host "OWA URL:" $owa
Get-OwaVirtualDirectory -Server $env:computername | Set-OwaVirtualDirectory -internalurl $owa -externalurl $owa -wa 0

#ECP
$ecp = "https://" + "$OutlookHostname" + "/ecp"
write-host "ECP URL:" $ecp
Get-EcpVirtualDirectory -server $env:computername| Set-EcpVirtualDirectory -internalurl $ecp -externalurl $ecp

#EWS
$ews = "https://" + "$OutlookHostname" + "/EWS/Exchange.asmx"
write-host "EWS URL:" $ews
Get-WebServicesVirtualDirectory -server $env:computername | Set-WebServicesVirtualDirectory -internalurl $ews -externalurl $ews -confirm:$false -force

#ActiveSync
$eas = "https://" + "$OutlookHostname" + "/Microsoft-Server-ActiveSync"
write-host "ActiveSync URL:" $eas
Get-ActiveSyncVirtualDirectory -Server $env:computername  | Set-ActiveSyncVirtualDirectory -internalurl $eas -externalurl $eas

#OfflineAdressbuch
$oab = "https://" + "$OutlookHostname" + "/OAB"
write-host "OAB URL:" $oab
Get-OabVirtualDirectory -Server $env:computername | Set-OabVirtualDirectory -internalurl $oab -externalurl $oab

#MAPIoverHTTP
$mapi = "https://" + "$OutlookHostname" + "/mapi"
write-host "MAPI URL:" $mapi
Get-MapiVirtualDirectory -Server $env:computername| Set-MapiVirtualDirectory -externalurl $mapi -internalurl $mapi

#Outlook Anywhere (RPCoverhTTP)
write-host "OA Hostname:" $OutlookHostname
Get-OutlookAnywhere -Server $env:computername| Set-OutlookAnywhere -externalhostname $OutlookHostname -internalhostname $OutlookHostname -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate' -wa 0

#Autodiscover SCP
$autodiscover = "https://" + "$AutodiscoverHostname" + "/Autodiscover/Autodiscover.xml"
write-host "Autodiscover URL:" $autodiscover
Get-ClientAccessService $env:computername | Set-ClientAccessService -AutoDiscoverServiceInternalUri $autodiscover

Nachdem Zeile 2 und Zeile 4 angepasst wurden, kann das Script auf jedem Exchange 2016 Server ausgeführt werden, der die Einstellungen erhalten soll. Um das Script auszuführen, kann es in eine .PS1 Datei kopiert werden, die dann mit der Exchange Management Shell ausgeführt wird:

Das Script konfiguriert interne und externe URL, bzw. internen und externen Hostnamen identisch.

Danach können die Zertifikate mit den Hostnamen konfiguriert werden, die in Zeile 2 und Zeile 4 angegeben wurden. Ob alle Exchange Server die korrekten URLs haben, lässt sich mit dem Script aus diesem Artikel prüfen:

Exchange 2016: DNS-Namen für Zertifikate ermitteln (Quick & Dirty)

Der Beitrag Exchange 2016: URLs und Hostnamen per PowerShell konfigurieren erschien zuerst auf Frankys Web.

Leider ist auf die Exchange 2010 Shell keinen Verlass, wenn man herausfinden möchte, welches Patchlevel der Exchange Server hat, so liefert die Exchange Shell immer das Build 123.4 zurück:

In der Exchange 2010 Shell wird also nur das letzte Service Pack für Exchange 2010 angezeigt (SP3), nicht aber die Update Rollup Pakete:

Eine bessere Methode um die Build Nummer und damit auch den Patchlevel zu ermitteln, ist es die Dateiversion von exsetup.exe mit der Liste der Exchange Build Nummern zu vergleichen. Exsetup.exe hat immer die Version des letzten installierten Update Pakets.

Um an die Build Nummer der Datei exsetup.exe zu gelangen, kann der folgende Befehl verwendet werden.

Get-Command Exsetup.exe | ForEach {$_.FileversionInfo}

Die Dateiversion liefert dann die Exchange Build Nummer:

Um herauszufinden welches Patchlevel der Exchange Server hat, kann nun auf den folgenden Seiten nachgeschaut werden:

• Exchange 2016 und Exchange 2013 Build Nummern
• Exchange 2010 und  Exchange 2007 Build Nummern

In gezeigten Fall handelt es sich um Exchange Server 2010 UR 16:

(Ja, hier hat sich jemand verschrieben, es müsste 14.3.339.0 heißen, nicht 13.3.339.0)

Der Befehl lässt sich auch etwas erweitern und in eine Schleife packen, so lassen sich gleich alle Exchange Server prüfen:

$ExchangeServers = Get-ExchangeServer | Sort Name
ForEach  ($ExchangeServer in $ExchangeServers)
{
 Invoke-Command -ComputerName $ExchangeServer.Name -ScriptBlock {Get-Command  Exsetup.exe | ForEach {$_.FileversionInfo}}
}

Der Befehl funktioniert mit allen Exchange Server Versionen. Exchange 2016 zeigt bisher allerdings das korrekte Build in der Shell an:

Hier handelt es sich um Exchange 2016 CU 4:

Der Beitrag Exchange Server PatchLevel ermitteln erschien zuerst auf Frankys Web.