Also manchmal ist es ja wie verhext, vorgestern mochte sich die Exchange 2010 Management Shell nicht verbinden, heute möchte die Exchange 2013 Shell nicht mehr…

Beim Start erscheint die folgende Fehlermeldung:

New-PSSession : [fwex1.frankysweb.local] Beim Verbinden mit dem Remoteserver „fwex1.frankysweb.local“ ist folgender
Fehler aufgetreten: Zugriff verweigert Weitere Informationen finden Sie im Hilfethema „about_Remote_Troubleshooting“.
In Zeile:1 Zeichen:1

Warum das jetzt plötzlich auftritt? Keine Ahnung, aber es gibt eine einfache Lösung:

Im IIS-Manager unter der Default Website gibt es das virtuelle Verzeichnis „PowerShell“. In den erweiterten Einstellungen muss der physikalische Pfad angepasst werden:

Der Physikalische Pfad muss wie folgt lauten:

C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell

Dann muss der IIS mittels „iisreset“ neugestartet werden.

Und schon verbindet sich auch die Exchange Management Shell wieder

Mal sehn ob morgen die Exchange 2016 Shell streikt…

Der Beitrag Exchange 2013: Exchange Management Shell verbindet sich nicht (Zugriff verweigert) erschien zuerst auf Franky's Web.

Holger ist ein merkwürdiger Fehler bei der Installation von Exchange 2016 auf Windows Server 2012 R2 untergekommen. Direkt beim Starten von Setup.exe erscheint folgende Fehlermeldung:

Diese App kann auf dem PC nicht ausgeführt werden Wenden Sie sich an den Softwareherausgeber, um eine geeignete Version für Ihren PC zu finden.

Gut, das wäre dann wohl Microsoft, das macht es einfacher :-D Wer jetzt allerdings keine Lust hat, sich an Microsoft zu wenden, der kann weiterlesen.

Im Ordner C:\ExchangeSetupLogs werden Setup Logs geschrieben, dort findet sich dann der entscheidene Hinweis:

[10.11.2015 10:30:59.0714] [0] Der Registrierungsschlüssel „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\V15\Setup“ wurde nicht gefunden.

Stimmt, den Schlüssel gibt es nicht:

Es wäre ja auch zu einfach wenn das Setup.exe den Schlüssel einfach anlegt, dafür ist es ja ein Setup, dass scheint aber nicht der Fall zu sein. Dann wird der Schlüssel mit dem Namen „Setup“ eben manuell erstellt:

Jetzt startet auch Setup.exe wieder

Der Inhalt des Schlüssel sieht nach der Installation übrigens so aus:

Falls da also während der Installation noch mal irgendwo eine App nicht starten will ;-)

Der Beitrag Exchange 2016: Diese App kann auf dem PC nicht ausgeführt werden erschien zuerst auf Franky's Web.

Auf dem Exchange Team Blog sind 2 lesenswerte Artikel zur Exchange 2016 Koexistenz in Verbindung mit Exchange 2010 und Exchange 2013 veröffentlicht worden. Die vier Artikel sind unter folgendem Links erreichbar:

http://blogs.technet.com/b/exchange/archive/2015/10/26/client-connectivity-in-an-exchange-2016-coexistence-environment-with-exchange-2010.aspx

http://blogs.technet.com/b/exchange/archive/2015/10/28/client-connectivity-in-an-exchange-2016-coexistence-environment-with-exchange-2013.aspx

http://blogs.technet.com/b/exchange/archive/2015/10/30/client-connectivity-in-an-exchange-2016-coexistence-environment-with-mixed-exchange-versions.aspx

http://blogs.technet.com/b/exchange/archive/2015/10/22/exchange-2016-coexistence-with-kerberos-authentication.aspx

Die Artikel behandeln das Thema Koexistenz sehr ausführlich.

Derzeit arbeite ich an einem Artikel der die  Migration von Exchange 2010 zu Exchange 2016 behandelt. Da waren die Infos aus den oben genannten Artikeln Gold wert. (Howto wird bald veröffentlicht)

Der Beitrag Exchange 2016: Infos zur Koexistenz erschien zuerst auf Franky's Web.

Das Gewinnspiel zum 5 Jährigen Geburtstag endet am 5.11.2015, wer also noch eins der 5 Bücher gewinnen möchte, kann noch an der Verlosung teilnehmen:

https://www.frankysweb.de/frankysweb-hat-geburtstag-es-gibt-was-zu-gewinnen/

Auch der Exchange Reporter 3.0 steht schon in den Startlöchern und wird bald veröffentlicht. Zur Veröffentlichung wird es auch wieder eine kleine Verlosung geben.

An dieser Stelle möchte ich mich auch für die vielen netten Mails mit Glückwünschen und Lob bedanken, mit so viel Rückmeldung und Teilnahme habe ich ehrlich gesagt gar nicht gerechnet. Vielen Dank also an alle die ein paar nette Worte gefunden haben, welche mich ermutigen diesen Blog weiterzuführen.

Ich arbeite jetzt noch etwas weiter an dem Artikel „Migration von Exchange 2010 zu Exchange 2016“, welchen ich euch auch schnellstmöglich zur Verfügung stellen möchte.

Euch allen einen schönes Restwochenende,

Frank

Der Beitrag Gewinnspiel endet bald, jetzt noch mitmachen erschien zuerst auf Franky's Web.

Wer noch nicht darüber nachgedacht hat, seine SHA1 Zertifikate gegen SHA256 (auch SHA2 genannt) zu tauschen, sollte nicht mehr all zu viel Zeit ins Land ziehen lassen.

Microsoft hat angekündigt SHA1 Zertifikate ab Juni 2016 nicht mehr zu unterstützen und damit zu blocken. Ein entsprechender Eintrag findet sich hier:

http://blogs.windows.com/msedgedev/2015/11/04/sha-1-deprecation-update/

Auch Mozilla hat für Firefox ein entsprechenden Vorgehen bereits angekündigt:

https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/

Ebenso wie Google für Chrome:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2-R4XziFc7A/YO0ZSrX_X4wJ

Konkret geht es hier um SHA1 als Signaturhashalgorithmus:

Ab Januar 2016 wird der Internet Explorer ´mit SHA1 signierte Zertifikate bereits mit einer Zertifikatswarnung versehen. Bisher war angedacht SHA1 ab dem Januar 2017 nicht mehr zu unterstützen. Dieses Datum wurde jetzt auf Juni 2016 vorgezogen. Grund hierfür ist das SHA1 signierte Zertifikate schon seit langer Zeit als unsicher anzusehen sind:

https://sites.google.com/site/itstheshappening/

Und mit seit langer Zeit meine ich, sehr lange: (Der Artikel ist aus dem Jahre 2005)

http://www.heise.de/newsticker/meldung/Kryptoverfahren-SHA-1-geknackt-135372.html

Die meisten öffentlichen CAs stellen bereits nur noch SHA2 Zertifikate aus. Oft bieten die öffentlichen CAs auch an, bestehende SHA1 Zertifikate kostenlos auszutauschen. Besonders einfach geht das bei Zertifikaten die über den Reseller PSW bezogen wurden. Hier muss nur die Bestellnummer und ein neuer CSR eingereicht werden und schon bekommt man ein neues Zertifikat:

https://www.psw-group.de/ssl-zertifikate/austausch/

Bei den CAs direkt ist es etwas aufwändiger, aber ebenso möglich:

• Geotrust oder RapidSSL Zertifikat erneuern
• Thawte Zertifikat erneuern
• Symantec oder VeriSign erneuern

Auch Zertifikate die von einer internen Zertifizierungsstelle ausgestellt wurden, sind davon betroffen. Damit eine Windows CA SHA2 Zertifikate ausstellen kann, muss in den meisten Fällen nur der Signaturhashalgorithmus umgestellt werden. Wie das geht habe ich hier beschrieben:

https://www.frankysweb.de/migration-stammzertifizierungsstelle-sha1-zu-sha256-hashalgorithmus/

Übrigens: Auch meine Seite ist verschlüsselt erreichbar (natürlich bereits mit SHA2)

Ein weiterer wichtiger Hinweis zum Schluss:

Die Ankündigung SHA1 nicht mehr zu unterstützen bezieht sich auf die Webserver bzw TLS Zertifikate, nicht auf die Zertifikate der Zertifizierungsstellen selbst. Die Root-CAs dürfen weiterhin mit SHA1 signiert sein. Hier auch am Beispiel GeoTrust zu sehen:

Der Beitrag SHA1 Zertifikate werden früher als bisher angekündigt geblockt erschien zuerst auf Franky's Web.

So, nachdem bis gestern die Möglichkeit bestand an dem Gewinnspiel für eines der 5 Microsoft Press Bücher teilzunehmen, stehen heute die Gewinner fest.

Ich möchte mich aber noch einmal ganz herzlich für die vielen Glückwünsche und die netten Mails bedanken. Ich habe mich wirklich sehr gefreut.

Aber nun zu den Gewinnern:

• Je ein Exemplar von „Exchange Server 2013 – Das Handbuch“ geht an: Alexander und Hendrik

• Je ein Exemplar von „Windows Server 2012 – Ratgeber für Administratoren“ geht an: Ulrich und Gökhan

• Das Buch „Scripting mit Windows PowerShell 3.0 – Der Workshop“ geht an: Thomas

Herzlichen Glückwunsch. Ich habe euch gerade eine Mail geschrieben, sobald ich die Versandadresse habe, gehen die Bücher zur Post.

Der Beitrag Gewinnspiel vorbei! Gewinner stehen fest! erschien zuerst auf Franky's Web.

Hier mal wieder ein kleines Script aus der Reihe Quick & Dirty. Wer HP Blade Enclosures einsetzt und schnell und ohne viel Aufwand eine Übersicht haben möchte, welche Blades in welchen Enclosures stecken, für den könnte das nachfolgende Script nützlich sein.

Das Script fragt alle eingetragenen Blade Enclosures ab und listet die Blades je Enclosure auf (getestet mit C7000 G3). Dabei wird die iLO IP, Modell und Seriennummer, sowie Name und Bay des Blades aufgenommen und per Mail verschickt.

Wer möchte kann das Script auch leicht abwandeln und sich eine CSV Datei oder ähnliches mit den Daten bauen lassen.

Hier nun aber das Script, einfach die ersten 5 Zeilen entsprechend abändern und via PowerShell ausführen:

$SMTPServer = "smtp.frankysweb.local"
$from = "hp@frankysweb.de"
$to = "frank@frankysweb.de"
$subject = "Blades"
[array]$bladeenclosures = "enc01.frankysweb.local","enc02.frankysweb.local","enc03.frankysweb.local"

Hier kann das Script runtergeladen werden:

Get-HPBEInformations 0.94 KB

Download

Das Script ruft die Daten via XML vom Onboard Administrator ab, daher werden keine weiteren SnpIns für die PowerShell benötigt.

HP bietet allerdings auch für spezielle PowerShell Module an, mit denen die Server sogar konfiguriert werden können:

http://www8.hp.com/us/en/products/server-software/product-detail.html?oid=5440657#!tab=features

Auch der Exchange Reporter besitzt ein Modul welches Daten zu HP Servern liefern kann. Lieder fehlt es mir an Hardware von anderen Herstellern, sonst könnte man das ggf. noch erweitern.

Der Beitrag Quick & Dirty: HP C7000 Blade Enclosure per PowerShell inventarisieren erschien zuerst auf Franky's Web.

Vorwort

Exchange 2016 liegt seit dem 01.10 in der finalen Version vor. Viele werden Exchange 2013 übersprungen haben, und derzeit noch Exchange 2010 einsetzen, für diejenigen ist es an der Zeit die Migration zu Exchange 2016 zu planen. Exchange 2016 wird die letzte Version sein, zu der sich von Exchange 2010 direkt migrieren lässt.

Diese Anleitung beschreibt die Migration von Exchange 2010 zu Exchange 2016 und soll einen Überblick über die notwendigen Schritte verschaffen und ist daher bewusst einfach gehalten. Zertifikate und auch der Namespace sollen übernommen werden, denn man muss das Rad ja nicht ständig neu erfinden.

Diese Anleitung wird aus 3 Teilen bestehen, im ersten Teil wird die Migration vorbereitet, im zweiten Teil werden die Postfächer und die Öffentlichen Ordner migriert und im dritten Teil wird aufgeräumt.

Eins noch vorweg: Dies ist keine allgemein gültige Migrationsanleitung, die sich auf jede Exchange 2010 Organisation anwenden lässt. Die Implementierungsmöglichkeiten bei Exchange 2010 waren sehr vielfältig, daher sollte man sich vor der Migration seine Exchange Infrastruktur möglichst 1-zu-1 in einer Testumgebung abbilden um die Migration zu testen.

Umgebung

Die Testumgebung besteht aus 3 Windows Server 2012 R2. Ein Domain Controller, ein Exchange 2010 Server und ein Exchange 2016 Server:

Exchange 2010 und Exchange 2016 sind bereits installiert.

Damit die Koexistenz und damit auch die Migration unterstützt wird, muss Exchange 2010 Service Pack 3 und das Update Rollup 11 installiert sein. Die Downloads für das Service Pack 3 und Update Rollup 11 finden sich hier:

• Exchange 2010 SP3 Download
• Exchange 2010 UR 11 Download

Die Exchange 2016 Installation in einer bestehenden Exchange 2010 Organisation, unterscheidet sich nicht von der Installation in einer frischen Umgebung. Nur die Frage nach dem Organisationnamen entfällt. Ich spare mir daher die Installation von Exchange 2016 zu beschreiben, denn das habe ich bereits hier getan:

https://www.frankysweb.de/exchange-2016-installation-auf-windows-server-2012-r2/

Exchange 2010 ist auf die folgenden URLs konfiguriert:

• Servername: EX2010.frankysweb.local
• Outlook (CAS-Array): outlook-int.frankysweb.de
• OWA, EWS, ActiveSync, OAB: outlook.frankysweb.de
• Outlook Anywhere: outlook.frankysweb.de
• Autodiscover: autodiscover.frankysweb.de

Exchange 2016 soll die folgenden URLs benutzen:

• Servername: EX2016.frankysweb.local
• Outlook: outlook.frankysweb.de
• OWA, EWS, ActiveSync OAB: outlook.frankysweb.de
• Outlook Anywhere: outlook.frankysweb.de
• Autodiscover: autodiscover.frankysweb.de

Exchange 2016 soll also die gleichen URLs benutzen wie Exchange 2010, so brauchen sich die Benutzer nicht umgewöhnen.

Vorbereitung

Wie bereits erwähnt ist Exchange 2016 bereits installiert, aber noch nicht konfiguriert. Daher werden zunächst die URLs konfiguriert, am einfachsten passiert das mittels Exchange Management Shell:

$servername = "EX2016"
$internalhostname = "outlook.frankysweb.de"
$externalhostname = "outlook.frankysweb.de"
$autodiscoverhostname = "autodiscover.frankysweb.de"
 
$owainturl = "https://" + "$internalhostname" + "/owa"
$owaexturl = "https://" + "$externalhostname" + "/owa"
$ecpinturl = "https://" + "$internalhostname" + "/ecp"
$ecpexturl = "https://" + "$externalhostname" + "/ecp"
$ewsinturl = "https://" + "$internalhostname" + "/EWS/Exchange.asmx"
$ewsexturl = "https://" + "$externalhostname" + "/EWS/Exchange.asmx"
$easinturl = "https://" + "$internalhostname" + "/Microsoft-Server-ActiveSync"
$easexturl = "https://" + "$externalhostname" + "/Microsoft-Server-ActiveSync"
$oabinturl = "https://" + "$internalhostname" + "/OAB"
$oabexturl = "https://" + "$externalhostname" + "/OAB"
$mapiinturl = "https://" + "$internalhostname" + "/mapi"
$mapiexturl = "https://" + "$externalhostname" + "/mapi"
$aduri = "https://" + "$autodiscoverhostname" + "/Autodiscover/Autodiscover.xml"
 
Get-OwaVirtualDirectory -Server $servername | Set-OwaVirtualDirectory -internalurl $owainturl -externalurl $owaexturl
Get-EcpVirtualDirectory -server $servername | Set-EcpVirtualDirectory -internalurl $ecpinturl -externalurl $ecpexturl
Get-WebServicesVirtualDirectory -server $servername | Set-WebServicesVirtualDirectory -internalurl $ewsinturl -externalurl $ewsexturl
Get-ActiveSyncVirtualDirectory -Server $servername  | Set-ActiveSyncVirtualDirectory -internalurl $easinturl -externalurl $easexturl
Get-OabVirtualDirectory -Server $servername | Set-OabVirtualDirectory -internalurl $oabinturl -externalurl $oabexturl
Get-MapiVirtualDirectory -Server $servername | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl
Get-OutlookAnywhere -Server $servername | Set-OutlookAnywhere -externalhostname $externalhostname -internalhostname $internalhostname -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate'
Get-ClientAccessService $servername | Set-ClientAccessService -AutoDiscoverServiceInternalUri $aduri

Jetzt muss die Authentifizierung für Outlook Anywhere von Exchange 2016 an Exchange 2010 angepasst werden:

Zuerst prüfen, welche Authentifizierung Exchange 2010 verwendet:

Die gleiche Authentifizierungsmethode wird dann auch für Exchange 2016 eingestellt:

Auch die Art der Anmeldung an OWA und ECP muss gleich konfiguriert werden

Da ich die URLs nicht verändere kann ich das vorhandene Zertifikat des Exchange 2010 Servers weiterverwenden:

Das ist natürlich nur sinnvoll, wenn das Zertifikat noch eine ausreichend lange Restlaufzeit hat und auch mit SHA256 signiert wurde. Das Zertifikat kann dann einfach vom Exchange 2010 Server exportiert werden und auf dem Exchange 2016 Server wieder importiert werden:

Dann noch den Diensten zuordnen

Aber auch ein neues Zertifikat ist nicht das Problem. Ein neues Zertifikat kann entweder von einer internen CA oder von einer öffentlichen CA ausgestellt werden. Der Prozess unterscheidet sich dabei nicht von Exchange 2013:

• Anleitung für öffentliche CA
• Anleitung Zertifikat mit interner CA

Als nächsten kann Exchange 2016 zum Sendeconnector hinzugefügt werden, damit über Exchange 2016 auch Mails versendet werden können:

Bei der Exchange 2016 Installation wird ein neues Offline Adressbuch erzeugt, welches der Exchange 2016 Datenbank noch zugewiesen werden muss:

Die Grundkonfiguration ist damit bereits abgeschlossen.

Jetzt ein Testpostfach in die Exchange 2016 Datenbank verschoben werden:

Testpostfach auswählen

Namen vergeben und die Exchange 2016 Datenbank auswählen

Dann die Postfachverschiebung abschließen:

Jetzt ein bisschen warten bis die Postfachverschiebung abgeschlossen ist:

Sobald das Postfach Verschoben wurde, erscheint wieder die berüchtigte Meldung, wenn Outlook zum Zeitpunkt der Postfachverschiebung geöffnet war:

Der Microsoft Exchange-Administrator hat eine Änderung durchgeführt, die einen Neustart von Outlook erfordert

Um die Verbindung zu testen ohne gleich alle Clients umzustellen, können wir den DNS Server umgehen und folgende Einträge in der HOSTS-Datei unter c:\Windows\System32\drivers\etc hinzufügen:

• 172.168.100.102 outlook.frankysweb.de
• 172.16.100.102 autodiscover.frankysweb.de

Wobei 172.16.100.102 die IP meines Exchange 2016 Servers ist. Der Eintrag in der HOSTS-Datei dienst natürlich nur zum Test und wird nach erfolgreichem Test wieder entfernt.

Nachdem Outlook neugestartet wurde, sollte es jetzt mit Exchange 2016 verbunden sein:

Hier kann man schon erkennen, dass nun MAPIoverHTTP genutzt wird, welches das neue Standardprotokoll für Exchange 2016 ist.

Hinweis: Wer Outlook 2010 als Client nutzt, muss darauf achten das folgendes Update installiert ist:

• https://support.microsoft.com/en-us/kb/2878264

Erst das Update liefert Support für MAPIoverHTTP für Outlook 2010.

Und auch Autodiscover sollte nun die Exchange 2016 Einstellungen liefern:

Jetzt können die üblichen Tests durchgeführt werden, E-Mail Empfang intern, E-Mail Empfang extern, E-Mail Versand intern, E-Mail Versand extern und alles was man noch so machen möchte.

Hier bietet sich nun ein ausführlicher Test an, auch mit mehreren Testpostfächern. Wichtig ist auch daran zu denken, dass Exchange nicht nur Mailserver spielt, auch Kalender, Raumbuchungen, Abwesenheitsassistent usw. sollte getestet werden. Ebenfalls nicht vergessen den Zugriff von extern zu testen (ActiveSync, Outlook Anywhere).

WICHTIG: Unbedingt auch testen, ob der Zugriff möglich ist, wenn das Postfach noch nicht auf Exchange 2016 verschoben wurde, also ein bestehendes Exchange 2010 Postfach raussuchen und HOSTS-Datei entsprechend wie oben beschrieben ändern. Dieser Zugriff muss für die weitere Migration möglich sein.

HINWEIS: Wenn öffentliche Ordner genutzt werden, sollte bei den Tests aufgefallen sein, das von einem Exchange 2016 Postfach nicht auf Exchange 2010 Öffentliche Ordner zugegriffen werden kann. Im zweiten Teil dieser Anleitung, wird der Zugriff entsprechend eingerichtet.

Der Beitrag Migration von Exchange 2010 zu Exchange 2016 (Teil 1) erschien zuerst auf Franky's Web.

Hier ist der zweite Teil der Migration von Exchange 2010 zu Exchange 2016. Der erste Teil findet sich hier:

Migration von Exchange 2010 zu Exchange 2016 Teil 1

In diesem Artikel werden die öffentlichen Ordner und die Postfächer migriert. Die Migration der Öffentlichen Ordner kann nur mit Downtime erfolgen, daher erst lesen, dann planen :-)

Update: Reihenfolge der Screenshots korrigiert

Vorbereitung Migration Öffentliche Ordner

Wie schon in Teil 1 erwähnt, ist bisher kein Zugriff von einem Exchange 2016 Postfach auf die Öffentlichen Ordner von Exchange 2010 möglich. Wer keine Öffentlichen Ordner unter Exchange 2010 einsetzt, kann sich diesen Teil sparen und ab „Exchange 2016 als Proxy für Exchange 2010“ weiterlesen.

Auf dem Exchange 2010 Server sind Öffentliche Ordner eingerichtet, die migriert werden müssen, hier ein Beispiel:

Der Exchange 2010 Benutzer Frank kann auf die Öffentlichen Ordner unter Exchange 2010 zugreifen:

Der Benutzer Hans mit einem Exchange 2016 Postfach allerdings nicht:

Damit Exchange 2016 Benutzer auf die Öffentlichen Ordner zugreifen können, wird eine ProxyMailbox benötigt. Die ProxyMailbox für öffentliche Ordner sollte am besten in einer separaten Datenbank gespeichert sein. Die ProxyMailbox ist im Prinzip ein ganz normales Postfach, es kann per Shell oder GUI angelegt werden. Hier der schnell Weg über die Shell (der letzte Befehl muss via Shell ausgeführt werden):

Neue Datenbank für die ProxyMailbox anlegen:

New-MailboxDatabase -Server FWEX2010 -Name PFProxyDatabase -IsExcludedFromProvisioning $true

ProxyMailbox in der neuen Datenbank anlegen:

New-Mailbox -Name PFProxyMailbox1 -Database PFProxyDatabase -UserPrincipalName PFProxyMailbox1@frankysweb.local

ProxyMailbox aus dem Adressbuch ausblenden:

Set-Mailbox -Identity PFProxyMailbox1 -HiddenFromAddressListsEnabled $true

Nachdem Datenbank und ProxyMailbox erzeugt wurden, kann der Zugriff eingeschaltet werden. Dazu muss folgender Befehl auf dem Exchange 2016 Server ausgeführt werden:

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFProxyMailbox1

Kurz warten, dann tauchen auch die Exchange 2010 Öffentlichen Ordner bei Exchange 2016 Benutzern auf:

Exchange 2016 als Proxy für Exchange 2010

Jetzt werden die DNS-Einträge auf Exchange 2016 umgestellt, wie schon im ersten Teil erwähnt, betrifft es ab hier alle Clients. Aktuell verweisen die DNS Einträge noch auf Exchange 2010 (172.16.100.101):

Das CAS-Array mit dem Namen outlook-int bleibt bestehen, denn Exchange 2016 dient als Proxy für Postfächer die auf Exchange 2010 laufen. Die Verbindung wird also via outlook.frankysweb.de von Exchange 2016 und dann weitergeleitet an outlook-int.frankysweb.de, wenn das Postfach noch auf den Exchange 2010 Server liegt.

Die DNS Einträge werden wie folgt geändert:

outlook.frankysweb.de und autodiscover.frankysweb.de verweisen jetzt auf die Exchange 2016 IP. Die Änderungen an der HOSTS-Datei an den Test Clients können rückgängig gemacht werden.

Wer Outlook Anywhere und/oder ActiveSync nutzt muss jetzt seine Firewall anpassen. Je nachdem wie Exchange 2010 im Internet erreichbar war (NAT, ReverseProxy), muss jetzt auf Exchange 2016 umgestellt werden. Wer nur NAT nutzt, also Exchange 2010 direkt per Portforward im Internet erreichbar gemacht hat, muss nur die Destination IP auf die Exchange 2016 IP ändern. Das Vorgehen hängt natürlich vom eingesetzten Produkt/Weg ab.

Ab hier sollten wir ein bisschen Zeit ins Land ziehen lassen, bis alle Clients die DNS Änderung mitbekommen haben. Mal einen Tag die Füße hochlegen, kann auch nicht schaden:

Nachdem etwas Zeit vergangen ist, sollte die Outlook Verbindung von Exchange 2016 Benutzern (Testbenutzer aus Teil 1) so aussehen:

Benutzer Hans nutzt MAPIoverHTTP mit Exchange 2016, wohingegen Benutzer Frank MAPI mit Exchange 2010 nutzt:

Wenn Benutzer Frank OWA aufruft, bekommt er die neue Anmeldemaske:

Und wird nach der Anmeldung an Exchange 2010 OWA verwiesen:

Migration der Postfächer

Jetzt ist es an der Zeit die Postfächer zu verschieben. Die Migration der Postfächer ist der einfachste Teil. Wie auch schon für das Testpostfach wird ein neuer Migrationsbatch angelegt:

Jetzt werden alle Postfächer ausgewählt die zu Exchange 2016 migriert werden sollen, mit Ausnahme der ProxyMailbox für Öffentliche Ordner, diese bleibt auf dem Exchange 2010 Server:

Im nächsten Dialog einfach wieder die Exchange 2016 Datenbank auswählen

Abschließend kann der Migrationsbatch gestartet werden:

Je nach Anzahl der Benutzer und des Zeitfensters muss hier jeder selbst entscheiden, wie viele Benutzer innerhalb eines Batches abgearbeitet werden sollen.

Der Status des Migrationsbatches lässt über den Punkt „Details anzeigen“ einsehen:

Wenn alle Postfächer des Migrationsbatches verschoben sind, sieht es wie folgt aus:

Sobald das Postfach zu Exchange 2016 verschoben wurde, erhalten die Benutzer die Nachricht das Outlook neugestartet werden muss

Nach dem Neustart ist Outlook mit Exchange 2016 verbunden.

So können nun nach und nach alle Postfächer verschoben werden, Die Benutzer werden nur einmalig aufgefordert Outlook neu zu starten. Ich denke das ist auch am Tag verkraftbar. Wer das umschubsen der Benutzer lieber in die Nacht verlagern möchte, kann die Option „Batch manuell abschließen“ anwählen, dann können die Postfächer am Tag migriert werden, und Nachts lässt man schnell ein kleines Script laufen und finalisiert die Postfächer.

Migration Öffentlicher Ordner

Wenn alle Postfächer verschoben wurden, kann mit der Migration der Öffentlichen Ordner gestartet werden. Wer keine Öffentlichen Ordner nutzt, kann diesen Teil überspringen und geduldig auf Teil 3 warten.

Für die Migration der Öffentlichen Ordner, werden die „Public Folder Migration Scripts“ benötigt, die Scripte können hier runtergeladen werden:

Microsoft Exchange 2013 Public Folders Migration Scripts

Jetzt nicht über „Microsoft Exchange 2013 Public Folder Migration Scripts“ wundern, die Scripte sind ebenfalls für Exchange 2016 gültig.

Die 4 Dateien werden auf dem Exchange 2010 Server abgelegt, hier im Beispiel in C:\PFMigration

Jetzt werden die folgenden 3 Befehle auf dem Exchange 2010 Server ausgeführt um die vorhandene Struktur, Anzahl der Elemente und Berechtigungen zu sichern:

Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml
Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml
Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml

Die 3 Befehle erzeugen diese 3 Dateien:

Hinweis: Ein Backshlash „\“ im Namen des Öffentlichen Ordners wird nicht unterstützt, Ordner mit Backshlash im Namen müssen vor der Migration umbenannt werden. Mit dem folgenden Befehl lassen sich entsprechende Ordner finden:

Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name -like "*\*"} | Format-List Name, Identity

Wichtig ist ebenfalls, dass es keine anderen Migrationsversuche der Öffentlichen Ordner gab, in meiner Testumgebung bin ich mir an dieser Stelle sicher und überspringe die Steps zur Prüfung. Wer sich nicht ganz sicher ist, sollte das entsprechende Vorgehen hier nachlesen.

Auch an dieser Stelle möchte ich darauf hinweisen: Diese Anleitung zeigt nur die Vorgehensweise, ist aber nicht allgemein gültig. Wer nur wenige Öffentliche Ordner hat, kann weitermachen, wer viele Öffentliche Ordner hat und / oder viel Datenvolumen, sollte die neue Öffentliche Ordner Struktur planen.

Ich gehe an dieser Stelle davon aus, dass es nur wenige Öffentliche Ordner gibt und dien Datenmenge überschaubar ist (max. 20 GB, was in den meisten Fällen zu einer PFMailbox führt)

Also werden jetzt die nötigen CSV Dateien für die Migration mit Hilfe der Scripte erstellt:

.\Export-PublicFolderStatistics.ps1 FolderToSizeMap.csv fwex2010.frankysweb.local

Als nächstes wird das Mapping von Öffentlichen Ordner zur Öffentlichen Ordner Mailbox erstellt:

.\PublicFolderToMailboxMapGenerator.ps1 21474836480 .\FolderToSizeMap.csv FolderToMailBoxMap.csv

Hinweis: 21474836480 entspricht 20 GB in Bytes und bedeutet an dieser Stelle, das eine Öffentliche Ordner Mailbox max. 20 GB groß sein soll.

Da ich nur eine Postfach für Öffentliche Ordner benutzen möchte, erzeuge ich jetzt das entsprechende Postfach auf dem Exchange 2016 Server:

New-Mailbox -PublicFolder Mailbox1 -HoldForMigration:$true

Jetzt kann der Migrationsbatch für die Öffentlichen Ordner angelegt und gestartet werden:

New-MigrationBatch -Name PFMigration -SourcePublicFolderDatabase (Get-PublicFolderDatabase -Server FWEX2010) -CSVData (Get-Content \\fwex2010\C$\PFMigration\FolderToMailBoxMap.csv -Encoding Byte) -NotificationEmails administrator@frankysweb.de
Start-MigrationBatch PFMigration

Der Status der Migration lässt sich über die Shell oder über EAC überprüfen:

Get-MigrationBatch

Jetzt heißt es warten bis der Migratonsbatch fertig ist und den Status „Synchronisiert“ hat:

Für die nächsten Schritte ist ein Wartungsfenster nötig, denn der Zugriff auf die Öffentlichen Ordner, wird nicht möglich sein. Outlook wird eine entsprechende Nachricht anzeigen:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

Set-OrganizationConfig -PublicFoldersEnabled Remote
Complete-MigrationBatch PFMigration

Jetzt abwarten, bis der Migrationbatch abgeschlossen ist:

Sobald der Migrationsbatch abgeschlossen ist, kann getestet werden ob alles geklappt hat. Der Test kann mit einem Testbenutzer durchgeführt werden, in diesem Fall der Benutzer Frank:

set-mailbox frank -DefaultPublicFolderMailbox Mailbox1

Benutzer Frank kann jetzt den Zugriff auf die Öffentlichen Ordner testen:

Wenn alles soweit gut aussieht, können die Öffentlichen Ordner wieder für alle Benutzer freigegeben werden, dazu wird der folgende Befehl auf dem Exchange 2016 Server ausgeführt:

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false

Danach wird dann dieser Befehl auf dem Exchange 2010 Server ausgeführt:

Set-OrganizationConfig -PublicFolderMigrationComplete:$true

Und zu guter Letzt noch dieser Befehl auf dem Exchange 2016 Server:

Set-OrganizationConfig -PublicFoldersEnabled Local

Zugegeben, die Migration der Öffentlichen Ordner ist kompliziert und erfordert Downtime, aber wenn man das ein paar Mal gemacht hat… Wichtig ist hier die Planung, wie groß sollen die Postfächer für Öffentliche Ordner sein, wie viele Postfächer möchte ich anlegen, wie viel Wachstum wird es geben, usw. Auch die Downtime sollte gut geplant werden und ein entsprechend langes Wartungsfenster kommuniziert werden.

Ab hier liegen also Postfächer und Öffentliche Ordner auf Exchange 2016. Jetzt ist es an der Zeit (wenn erforderlich) die MX Records und Geräte wie Drucker, Scanner, andere Server die Mails verschicken auf Exchange 2016 umzustellen.

Im nächsten und letzten Teil wird dann aufgeräumt und Exchange 2010 deinstalliert.

Der Beitrag Migration von Exchange 2010 zu Exchange 2016 (Teil 2) erschien zuerst auf Franky's Web.

Hier ist der dritte und letzte Teil der Migration von Exchange 2010 zu Exchange 2016. Teil 1 und Teil 2 finden sich hier:

• Migration von Exchange 2010 zu Exchange 2016 Teil 1
• Migration von Exchange 2010 zu Exchange 2016 Teil 2

In diesem Teil wird aufgeräumt und Exchange 2010 deinstalliert.

Entfernen der Exchange 2010 Datenbanken

Damit Exchange 2010 später sauber deinstalliert werden kann, müssen zunächst die Datenbanken gelöscht werden, dazu sind aber erst noch ein paar Kleinigkeiten erforderlich.

Zuerst wird die Öffentliche Ordner Proxy Mailbox abgeschaltet, dazu wird der folgende Befehl auf dem Exchange 2016 Server verwendet:

Set-OrganizationConfig -RemotePublicFolderMailboxes:$NULL

Jetzt kann die Öffentliche Ordner Datenbank auf dem Exchange 2010 Server gelöscht werden, das geht wohl am schnellsten per Konsole:

Die Datenbankdateien müssen manuell gelöscht werden, da ich aber später einfach die ganze VM lösche, spare ich es mir:

Auf dem gleichen Weg, kann auch die PFProxyDatabase welche das Proxy Postfach enthält gelöscht werden:

Und auch die alte Mailbox Datenbank:

Nachdem alle Exchange 2010 Datenbanken gelöscht sind, sieht es dann so aus:

Wenn wir schon beim Löschen sind, kann auch gleich das alte Offlineadressbuch gelöscht werden, hier aber nicht das falsche erwischen:

Das Offlineadressbuch bei dem Exchange 2010 der „Server für die Generierung“ ist, kann gelöscht werden.

Das Exchange 2016 OAB (wird mit Hinweis Ex2013 angezeigt) bleibt bestehen:

Sendeconnector anpassen

Der Exchange 2010 Server ist noch Quellserver des Sendeconnectors, auch hier lässt sich der alte Server leicht per Konsole aus der Konfiguration entfernen:

Nur noch der Exchange 2016 Server ist Quellserver des Sendeconnectors

DNS aufräumen

Der DNS Eintrag für das CAS-Array kann nun auch entfernt werden

Ebenso wie das CAS-Array selbst:

Exchange 2010 deinstallieren

Jetzt kann Exchange 2010 deinstalliert werden:

Alle Rollen und auch die Verwaltungstools abwählen:

Genauso ordentlich wie sich Exchange 2010 installieren ließ, lässt er sich auch wieder deinstallieren:

Exakt 4 Minuten später ist Exchange 2010 Geschichte :-)

Zu guter Letzt, Server aus der AD nehmen und neustarten

Computerkonto aus dem AD löschen

Die Warnung bestätigen:

Fertig. Ja, wirklich, alles fertig.

Soll ich noch einen Nachruf schreiben!?

Ich mochte Exchange 2010 wirklich, bin fast ein bisschen traurig, wenn jetzt alle zu Exchange 2016 migrieren. Gefühlt würde ich den Anteil an Exchange 2010 Installationen höher einschätzen, als Exchange 2013 Installationen. Exchange 2013 und den holprigen Start lassen wir jetzt mal aus, ich hoffe das Exchange 2016 ein würdiger Nachfolger wird. Bisher sieht es auf jeden Fall ganz gut aus.

Rest in Peace Exchange 2010!

Der Beitrag Migration von Exchange 2010 zu Exchange 2016 (Teil 3) erschien zuerst auf Franky's Web.

Damit die Artikelserie „Migration von Exchange 2010 zu Exchange 2016“ besser auffindbar und in der richtigen Reihenfolge ist, hier die direkten Links:

• Migration von Exchange 2010 zu Exchange 2016 Teil 1
• Migration von Exchange 2010 zu Exchange 2016 Teil 2
• Migration von Exchange 2010 zu Exchange 2016 Teil 3

Bitte darauf achten, dass dies nur ein Weg der Migration ist. In meinem Fall behalte ich den Namespace und das Zertifikat bei. Leicht abgewandelt funktioniert es natürlich auch mit einem neuen Namespace und/oder anderem Zertifikat. Auch größere Umgebungen lassen sich auf diese Weise migrieren, natürlich auch mit einer größeren Anzahl Servern.

An dieser Stelle möchte ich auch noch ein paar Tipps bzw. Denkanstöße geben:

• Die Öffentliche Ordner Migration erfordert Downtime, sprich es kann nicht auf die öffentlichen Ordner zugegriffen werden, dieses Zeitfenster will geplant werden
• Wer viele Öffentliche Ordner einsetzt, sollte sich über die folgenden Punkte Gedanken machen:
  • Wie viele Öffentliche Ordner Postfächer werden benötigt
  • Wie viele Öffentliche Ordner Proxy Postfächer werden benötigt
  • Wie hoch ist die Änderungsrate an den Öffentlichen Ordnern (bestimmt maßgeblich die Zeit für die Downtime)
• Welche Anwendungen greifen auf Exchange Server zu
  • Sind alle Anwendungen kompatibel? (Archivsystem, Virenschutz, Backup, etc…)
  • Gibt es noch alte Outlook Versionen oder Software, die MapiCDO nutzt?
• Welche Geräte oder Systeme verschicken Mails über Exchange?
  • Wird ein Relay Connector benötigt?
• Während der Migration der Postfächer und Öffentlichen Ordner werden viele Logs geschrieben, Speicherplatz entsprechend einplanen
• ReFS oder NTFS als Dateisystem?
  • ReFS vs. NTFS Teil 1
  • ReFS vs. NTFS Teil 2
  • ReFS vs. NTFS Teil 3
• Hardwareanforderungen
  • Exchange Server Role Requirements Calculator

Viele nützliche Ressourcen liefert auch der Exchange Server Deployment Assistant, hier lohnt sich ebenfalls die Migration durch zu spielen:

Exchange Server Deployment Assistant

Natürlich lässt sich die Migration in vielen Umgebungen nur schwer testen, dennoch sollte die Migration wenn möglich in einer Testumgebung „ausprobiert“ werden.

Wer bisher noch keine Berührungspunkte mit Exchange 2013 / Exchange 2016 hatte, sollte vorher etwas Hands-On Erfahrung sammeln.

Viel Erfolg, Fragen, Anregungen, Kritik wie immer gerne als Mail oder Kommentar.

Der Beitrag Howto: Migration von Exchange 2010 zu Exchange 2016 erschien zuerst auf Franky's Web.

Der Microsoft Technical Summit 2015 in Darmstadt ist seit gestern zu Ende. Hier mein persönliches Fazit

Wie auch im letzten Jahr gab es einige spannende Vorträge, bei denen Teils tiefgehende Infos und Einblick in Microsoft Technologien gegeben wurden. Die Location fand ich persönlich besser wie im letzten Jahr und ich glaube dieses Mal sind alle satt geworden ;-)

Auch in den einzelnen Vorträgen ging es nicht mehr ganz so eng zu. Das war in Berlin doch deutlich schlimmer. Sehr gelungen fand ich den Vortrag von Haiko Hertes über PowerShell 4 und PowerShell 5.

Ich hoffe Haiko ist jetzt nicht böse über das Foto, er hat seine Slides übrigens auf seinem Blog hochgeladen und ich nehme mal an das sein kompletter Vortrag, wie auch die anderen Vorträge, auf der Technical Summit Website verfügbar sind. Sobald alle Sessions verfügbar sind, erfahrt ihr es hier.

Die Übersicht über die kostenlosen Angebote von Microsoft fand ich ganz nützlich:

Ich hab es mal eingescannt und hier zum Download bereit gestellt:

Übersicht kostenlose Angebote 622.63 KB

Download

Einziger Wehrmutstropfen war für mich der Workshop Tag, das war leider für mich zu wenig Workshop und zu viel Vortrag. Allerdings haben die vielen konstruktiven Gespräche, während des Summits und auch danach, diesen kleinen Wehmutstropfen mehr als ausgeglichen.

Ich bin nächstes Jahr auf jeden Fall wieder mit dabei und freu mich schon jetzt darauf. Viele Grüße an dieser Stelle an die vielen Leute die ich kennen gelernt hab.

Also bis zum nächsten Jahr.

Der Beitrag Microsoft Technical Summit 2015 – Ein Fazit erschien zuerst auf Franky's Web.

Manche Anwendungen oder Geräte benötigen ein Anonymes Relay um Mails verschicken zu können. Hierbei muss allerdings zwischen internem Relay und externen Relay unterschieden werden. Das interne Relay, also das anonyme Senden von Mails an die von Exchange akzeptierten Domains, funktioniert Out-of-the-Box:

Das Externe Relay, also das verschicken von Mails an externe Benutzer, ohne Authentifizierung allerdings nicht:

Das anonyme externe Relay, ist auch immer mit Vorsicht zu betrachten, denn bei falscher Konfiguration kann Exchange hier schnell als SPAM-Schleuder missbraucht werden. Es gilt daher die Connectoren entsprechend einzuschränken und nur bestimmte IPs zuzulassen, nicht aber ganze Subnetze oder noch schlimmer „Jeden“.

Wie aber schon eingangs erwähnt, gibt es durchaus Anwendungen, wie Ticketsysteme oder CRMs, die  Mails an externe Empfänger schicken müssen, sich aber nicht authentifizieren können. Um diesen Anwendungen oder Geräten den Mailversand zu erlauben, kann ein neuer Empfangsconnector angelegt werden:

Die Einstellungen im nächsten Dialog können übernommen werden

In den Einstellungen der „Remotenetzwerkeinstellungen“ müssen jetzt alle IP-Adressen hinzugefügt werden, für die das anonyme externe Relay erlaubt werden soll:

Es macht hier Sinn nur einzelne IPs anzugeben, die diese Funktionalität wirklich benötigen, ganze Subnetze sollten hier nicht angegeben werden, es sei denn es ist unbedingt erforderlich (Servernetz, Management Netz oder ähnliches).

Nach einem Klick auf „Fertigstellen“ ist der Connector angelegt:

Damit der Connector anonyme Mails annimmt, müssen die Sicherheitseinstellungen entsprechend geändert werden:

Damit nun aber auch Mails zu externen Empfängern versendet werden können, müssen noch entsprechende Berichtigungen für den neuen Connector vergeben werden. Am schnellsten funktioniert dies per Exchange Management Shell:

Get-ReceiveConnector "Anonymes Relay FWEX2016" | Add-ADPermission -User "NT-Autorität\Anonymous-Anmeldung" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Beim zweiten Befehl gibt es einen kleinen Stolperstein:

• Bei deutschen Servern heißt es „NT-Autorität\Anonymous-Anmeldung“
• Bei englischen Servern heißt es „NT AUTHORITY\ANONYMOUS LOGON“

Der Connector ist jetzt aktiv und nimmt von den entsprechend freigeschalteten IPs (siehe Remotenetzwerkeinstellungen) anonym Mails entgegen. Bei Systemen die ein hohes Mailaufkommen produzieren oder sehr große Mails versenden, müssen gegeben falls noch weitere Parameter verändert werden:

Set-ReceiveConnector -identity "Anonymes Relay FWEX2016" -TarpitInterval 00:00:00
Set-ReceiveConnector -identity "Anonymes Relay FWEX2016" -ConnectionTimeout 00:30:00
Set-ReceiveConnector -identity "Anonymes Relay FWEX2016" -ConnectionInactivityTimeout 00:20:00
Set-ReceiveConnector -identity "Anonymes Relay FWEX2016" -MaxAcknowledgementDelay 00:00:00
Set-ReceiveConnector -identity "Anonymes Relay FWEX2016" -MaxInboundConnection 10000
Set-ReceiveConnector -identity "Anonymes Relay FWEX2016" -MaxInboundConnectionPerSource unlimited

Und zu guter Letzt noch ein wichtiger Hinweis:

Wer sich in folgender Umgebung wiederfindet, darf auf keinen Fall die interne IP Adresse des Routers in den Remotenetzwerkeinstellungen des Connectors hinterlegen:

MX-Record zeigt auf WAN IP des Routers, Router forwarded Port 25 (SMTP) per NAT an den Exchange Server. In diesem Fall sieht der Exchange Server nur die interne Router IP als Source IP. Wenn nun die interne Router IP zum Connector hinzugefügt wird, ist das ein Open Relay und somit sehr schnell eine SPAM-Schleuder.

Der Beitrag Exchange 2016: Anonymes Relay erlauben (5.7.54 Unable to Relay) erschien zuerst auf Franky's Web.

Alle Vorträge des Microsoft Technical Summit 2015 sind online verfügbar. Die Videos können auch direkt runtergeladen werden:

http://www.microsoft.com/germany/technical-summit/nachlese-2015.aspx

Zu den meisten Vorträgen sind auch die Präsentationen verfügbar. Wer also den MSTS verpasst hat, oder sich die Tracks noch einmal anschauen möchte, hat jetzt die Gelegenheit dazu.

Der Beitrag Microsoft Technical Summit 2015: Vorträge sind verfügbar erschien zuerst auf Franky's Web.

Ich liebe die PowerShell, aber mit dem Syntax Highlighting kann ich micht nicht so wirklich anfreunden, da finde ich die Farben schlecht gewählt, oder es liegt an meinen Augen, kann auch sein:

Aber mal ehrlich, grau oder hellgrün auf dunkelblauem Hintergrund? Für mich eine „etwas“ schwierige Farbwahl.Man könnte jetzt den Hintergrund ändern, allerdings wird es dadurch nicht wirklich besser:

Das Syntaxhighlighting wird von einem PowerShell Module mit dem Namen PSReadline übernommen, wer also auf die Hervorhebung mit den Farben verzichten kann, der kann einfach das Modul entladen:

Remove-Module PSReadline

Das ist doch gleich viel besser. Allerdings wird das Modul direkt wieder geladen, wenn PowerShell geschlossen und wieder geöffnet wird. Um zu verhindern das PSReadline direkt bei Start der PowerShell geladen wird, kann das Verzeichnis des Moduls gelöscht oder zur Sicherheit an eine andere Stelle verschoben werden. Das Modul befindet sich unter folgendem Pfad:

C:\Program Files\WindowsPowerShell\Modules

Ich habe mir das Verzeichniss PSReadline einfach an einen anderen Ort kopiert, so kann ich es wieder einfügen, sollte ich es doch einmal brauchen.

Der Beitrag PowerShell 5: Syntaxhighligthing abschalten erschien zuerst auf Franky's Web.

Böse Mails kommen in den besten Familien vor. Mal ist es ein Virus, oder eine Mail die so nicht hätte abgeschickt werden sollen.

Exchange Server bietet die Möglichkeit Mails aus Postfächern zu löschen. Gerade bei SPAM oder Virenwellen, kann es sehr nützlich sein, zu wissen wie es geht. Dieser Artikel trifft auf Exchange 2010, 2013 und 2016 zu.

Hier mal ein kleines Beispiel:

Hans hat eine „böse Mail“ bekommen die nun aus seinem Postfach gelöscht werden soll

Um die Mail zu löschen, muss als Erstes die entsprechende Berechtigung vergeben werden, in diesem Fall bekommt der Benutzer „Administrator“ die Rechte Postfächer zu importieren und exportieren, dieses Recht umfasst auch das Löschen von Mails innerhalb des Postfachs.

New-ManagementRoleAssignment -Name "Import Export Mailbox Adminstrator" -User "Administrator" -Role "Mailbox Import Export"

Alternativ lässt sich auch eine Universelle Gruppe aus dem Active Directory angeben, so müssen andere Benutzer nur der entsprechenden AD Gruppe zugeordnet werden:

New-ManagementRoleAssignment -Name "Import Export Mailbox Users" -SecurityGroup "Exchange Mailbox Import Export" -Role "Mailbox Import Export"

Nachdem das Recht zugewiesen wurde, muss die Exchange Managemet Shell einmal neu gestartet werden, da sonst das CMDLet „Search-Mailbox“ nicht zur Verfügung steht.

Jetzt kann die „Böse Mail“ gelöscht werden:

get-mailbox hans | search-mailbox -SearchQuery "böse mail" -DeleteContent

Der Screenshot oben stammt von Exchange 2016, hier wird eine kleine Warnung angezeigt, dass nur 10000 Elemente pro Postfach geliefert werden, Exchange 2010 bringt diese Warnung nicht.

Die Mail verschwindet kurze Zeit später aus dem Postfach von Hans:

Bei einer SPAM- oder Virenmail die an viele Postfächer geschickt wurde, können auch gleich alle Postfächer durchsucht werden.

In diesem Beispiel werden alle Postfächer nach einer Mail mit dem Betreff „Test“ gelöscht:

get-mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery "subject:'test'" -DeleteContent

Die Such lässt sich natürlich auch noch weiter verfeinern. Hier zum Beispiel alle Postfächer in der Datenbank „DB2016“ von administrator@frankysweb.de mit dem Betreff „Test“:

get-mailbox -Database DB2016 -ResultSize unlimited | Search-Mailbox -SearchQuery "subject:'test' -and from:'administrator@frankysweb.de'" -DeleteContent

Wer auf Nummer sicher gehen will und die Mails nicht sofort löschen will, kann sich auch die Ergebnisse der Suche erst einmal anzeigen lassen:

get-mailbox hans | search-mailbox -SearchQuery "test" -LogOnly -TargetFolder Suche -TargetMailbox administrator -LogLevel FULL

Mit dem Befehl werden die Suchergebnisse im Postfach des Benutzers „Adminsistrator“ im Ordner „Suche“ gespeichert. Im Anhang der Mail findet sich eine CSV-Datei mit den entsprechenden Ergebnissen:

Mit Excel lässt sich die CSV-Datei dann auswerten und gegebenenfalls Parameter der Suche entsprechend anpassen

Der Beitrag Exchange: Mails aus Postfächern löschen erschien zuerst auf Franky's Web.

Ich war auf der Suche nach einem Werkzeug für die Verwaltung und Automatisierung von Active Directory und Exchange, hängen geblieben bin ich bei Softerra Adaxes, welches ich aktuell etwas ausführlicher teste. Daher hier mal ein paar Eindrücke.

Zunächst mal ein paar Screenshots aus der Installation:

Hier muss ein Konto für den Dienst hinterlegt werden, das Konto benötigt Schreibrechte auf dem Computerkonto auf dem Adaxes isntalliert wird. Die genaue Konfiguration wird aber entsprechend angezeigt.

Die restlichen Schritte gehen einfach von der Hand:

Die Installation war schon mal einfach. Es folgt die Basiskonfiguration, dazu wird die Adaxes Verwaltungskonsole gestartet:

In der Verwaltungskonsole muss zunächst die Verbindung mit dem Adaxes Dienst hergestellt werden:

Der Dienst kann mit dem Benutzer verbunden werden, der bei der Installation angegeben wurde. Für das Active Directory habe ich einen anderen Benutzer angelegt, wenn der Benutzer aus der Installation aber entsprechende Rechte im AD hat, funktioniert es auch:

Als nächstes kann ein Mailserver hinterlegt werden, dazu Rechtsklick auf den Server, dann auf Eigenschaften klicken:

Auf dem Reiter E-Mail Einstellungen kann jetzt der Mail Server angegeben werden:

In der Standardkonfiguration ist Adaxes jetzt bereits einsatzbereit, die Webschnittstelle für Administratoren kann geöffnet werden:

Auf der übersichtlichen Startseite lassen sich jetzt bereits diverse Aktionen durchführen:

Für den ersten Test, erstelle ich einen neuen Benutzer

Das funktioniert schon einmal ziemlich gut:

Dem Benutzer fzoechling kann entweder direkt beim Erstellen oder auch nachträglich ein Exchange Postfach zugewiesen werden:

Das funktioniert sogar schon mit Exchange 2016 (natürlich auch mit den Vorgängerversionen):

Postfach wird angelegt, alles gut:

Jetzt ist allerdings das Erstellen von Benutzern und Postfächern auch ohne Adaxes keine große Kunst. Die Möglichkeiten mit Adaxes sind allerdings sehr vielfältig, vieles ist sogar schon vorkonfiguriert. Hier zum Beispiel werden Benutzer per Mail darüber informiert, wenn das Kennwort bald abläuft. Die Aufgabe muss nur noch aktiviert werden:

Mit einem kleinen Client ist es sogar möglich, Benutzer ihr Passwort selbst vor der Windows Anmeldung zurücksetzen zu lassen:

Alternativ auch mal das löschen eines Benutzers der das Unternehmen verlässt, hier spart man sich viel manuelle Arbeit:

Was mir wirklich gut gefällt ist, dass eigene Befehle angelegt werden können und da innerhalb eines Befehls PowerShell Scripte ausgeführt werden können, sind die Möglichkeiten nahezu unbegrenzt:

Des weiteren lässt sich auch das Aussehen der Webkonsolen lässt sich ebenfalls den eigenen Vorstellungen anpassen:

Adaxes macht auf mich einen sehr guten Eindruck, die Möglichkeit Rollen zu definieren um zum Beispiel dem Helpdesk bestimmte Tätigkeiten übernehmen zu lassen finde ich klasse. Auch die Möglichkeit eigene Tasks / Workflows zu erstellen ist sehr hilfreich. So lässt es sich recht einfach realisieren, dass nach der Anlage eines Benutzers auch bestimmte Gruppen automatisch zugeordnet werden, oder eine Willkommens E-Mail erstellt wird, mit ein bisschen Einarbeitung ist das schnell gemacht.

Wer Lust hat Adaxes zu testen bekommt hier eine Trial Version die 30 Tage lang uneingeschränkt läuft:

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

Der Beitrag Active Directory und Exchange Automatisierung mit Softerra Adaxes erschien zuerst auf Franky's Web.

Franky’s Web macht mit bei „Wer wird bester Tech IT-Blog 2015“ von Dice:

Ihr könnt abstimmen wer gewinnen soll, für eure Teilnahme habt ihr die Chance auf einen 25 EUR Amazon Gutschein:

Unter allen Teilnehmern des Votings verlosen wir einen 25 € Amazon-Gutschein. Wenn Sie an der Verlosung teilnehmen möchten, geben Sie bitte in unserer Kommentarfunktion unten Ihre Mailadresse und eine kurze Nachricht ein. (Ihr E-Mail Adresse ist nicht für andere Personen sichtbar und Ihre Angaben werden ausschließlich für die Verlosung verwendet.) Der Gewinner wird per E-Mail benachrichtigt.

Qeulle: Dice

Hier geht es zur Abstimmung:

http://de.dice.com/nachrichten/bester-tech-it-blog-2015-voting/

Damit Ihr auch einen kleinen Anreiz habt für mich zu stimmen, verlose ich unter allen die mir einen Screenshot von Ihrer Stimme per Mail schicken das Buch „Microsoft Windows Server 2012 R2 – Das Handbuch“:

Mitmachen könnte sich also für euch gleich doppelt lohnen. :-) Die Abstimmung läuft noch bis zum 06.01.2016.

Der Beitrag Bester IT-Blog 2015? Helft mit und gewinnt! erschien zuerst auf Franky's Web.

Heute wurden neue Updates für Exchange Server 2007, 2010 und 2013 veröffentlicht. Hier geht es direkt zum Download:

• Exchange 2007 Service Pack 3 Update Rollup 18 Download
• Exchange 2010 Service Pack 3 Update Rollup 12 Download
• Exchange 2013 Kumulatives Update 11 Download

Erste Updates für Exchange Server 2016 wird es mit dem nächsten Patchday in 3 Monaten geben.

Eine Liste mit den behobenen Problemen findet sich hier:

• Exchange 2007 Service Pack 3 Update Rollup 18
• Exchange 2010 Service Pack 3 Update Rollup 12
• Exchange 2013 Kumulatives Update 11

Da es in der Vergangenheit schon öfter vorgekommen ist, dass Updates auf Grund von Problemen zurückgezogen wurden, empfiehlt es sich mit der Installation noch etwas zu warten.

Der Beitrag Neue Updates für Exchange Server verfügbar erschien zuerst auf Franky's Web.

Seit einigen Tagen befindet sich die neue CA „Let’s Encrypt“ in der öffentlichen Beta Phase. Ziel von Let’s Encrypt ist es,auf einfache Weise SSL Zertifikate auszustellen. Die Zertifikate sind obendrein auch noch kostenlos.

Die CA wird bereits durch die meisten Browser unterstützt, da die Let’s Encrypt CA durch Identrust signiert wurde (Cross Signing).

Auch wenn es sich aktuell um eine Beta Phase handelt lassen sich die Zertifikate bereits für Exchange Testumgebungen nutzen, allerdings ist es aktuell noch etwas umständlich in Verbindung mit Exchange Server. Es gibt zwar einen Windows Client, aber der wollte auf meinem Testsystem nicht wirklich laufen. Wahrscheinlich muss noch ein bisschen Zeit ins Land ziehen, damit die Programme reifen können.

Da die Windows Clients noch nicht soweit sind, habe für diesen Test eine Ubuntu Server VM mit installiertem LAMP Stack benutzt. Der LAMP Stack ist eigentlich nicht erforderlich, aber ich hatte gerade nichts anderes zur Hand :-)

Für meinen Test verwende ich meine Domain frankysweb.com. Ich möchte für meinen Exchange Server ein Zertifikat ausgestellt bekommen, welches die folgenden DNS-Namen enthält:

• outlook.frankysweb.com
• autodiscover.frankysweb.com

Also ein klassisches SAN-Zertifikat mit zwei DNS-Namen.

Let’s Encrypt funktioniert etwas anders, als eine gewöhnliche CA. Bei den meisten CAs gibt es ein Webportal bei dem eine Zertifikatsanforderung (CSR) eingereicht werden muss. Bei Let’s Encrypt erledigt das ein Client. Daher benötigen wir zuerst den Client. Mit dem folgenden Befehl wird der Client aus dem GIT Repository runtergeladen:

git clone https://github.com/letsencrypt/letsencrypt

Sobald der Download fertiggestellt ist, kann in das Verzeichnis „letsencrypt“ gewechselt werden. In dem Verzeichnis befindet sich der Client.

Zunächst kann der Client mit dem Parameter –help aufgerufen werden, es werden dann noch fehlende Abhängigkeiten installiert:

An dieser Stellt haben wir jetzt also den Let’s Encrypt Client und alle Abhängigkeiten. Es gibt allerdings in diesem Fall ein paar Besonderheiten:

Der PC oder Server der das Zertifikat anfordert, muss unter den angeforderten Domainnamen per Port 80 aus dem Internet erreichbar sein. So wird durch Let’s Encrypt sichergestellt, dass man auch im Besitz der Domain ist, für die das Zertifikat angefordert wird (Domain Validation). Andere CAs schicken meist eine E-Mail mit einem Link an eine E-Mail Adresse wie postmaster@domain.de. Bei Let’s Encrypt übernimmt diese Funktion der Client.

Da auf meinem Testserver bereits ein Apache Server auf Port 80 hört, muss der Apache zunächst beendet werden, damit Port 80 für den Let’s Encrypt Client frei wird.

sudo service apache2 stop

Damit der Testserver unter dem Domain Namen autodiscover,frankysweb.com und outlook.frankysweb.com erreichbar ist, habe ich bei meinem Hoster die beiden Subdomains angelegt und auf meine WAN IP zeigen lassen:

An der Firewall habe ich dann Port 80 per DNAT auf meinen Testserver weitergeleitet.

Hinweis: Port 80 wird nur für die Anforderung benötigt, danach kann der Port wieder geschlossen werden.

Somit ist der Let’s Encrypt Client erreichbar und das Zertifikat kann angefordert werden:

/letsencrypt-auto certonly --standalone -d outlook.frankysweb.com -d autodiscover.frankysweb.com

Für Benachrichtigungen muss nur eine E-Mail Adresse angegeben werden:

und dann denn Terms of Service zugestimmt werden:

Nachdem das Zertifikat ausgestellt wurde, wird es Ordner /etc/letsencrypt/live/<DomainName> gespeichert:

Auf das /live Verzeichnis hat normalerweise nur der Benutzer root Zugriff, also mit folgendem Befehl als root Benutzer anmelden:

su -

Jetzt kann in das entsprechende Verzeichnis gewechselt werden. Dort finden sich jetzt unter anderem der Private Key (privkey.pem) und das Zertifikat (cert.pem):

Mit Zertifikaten im PEM Format kann Windows jedoch erst einmal wenig anfangen. Also wird das Zertifikat und der Private Key in das PKCS Format umgewandelt:

openssl pkcs12 -export -in cert.pem -inkey privkey.pem -out frankyweb.p12

Das Zertifikat kann jetzt am besten in das Home Verzeichnis kopiert werden, dann lässt sich einfach per WinSCP oder ähnlichem darauf zugreifen, ohne das die Berechtigungen für /etc/letsencrypt/live angepasst werden müssen.

cp frankyweb.p12 /home/frank/frankysweb.p12

Die .p12 Datei kann nun auf den Exchange Server übertragen werden. Am Einfachsten funktioniert das wohl per WinSCP:

Jetzt kann das Zertifikat importiert werden. Dazu kann eine MMC mit dem „Zertifikate“ SnapIn (lokaler Computer)geladen werden:

Hier kann nun die .P12 Datei importiert werden:

Ein Blick auf der Zertifikat bestätigt, das es gültig ist. Aktuell werden Zertifikate mit 3 Monaten Laufzeit ausgestellt:

Beide DNS-Namen sind enthalten:

IdenTrust (DST Root CA X3) hat die Let’s Encrypt Authority X1 signiert, daher ist dieses Zertifikat auf den meisten Browsern und Geräten gültig:

Jetzt noch dem neuen Zertifikat die Exchange Dienste zuweisen:

Fertig:

Das Zertifikat ist erst einmal 3 Monate gültig. Eine Erneuerung funktioniert ebenfalls über den Let’s Encrypt Client. Mal sehen ob nach der Beta Phase auch längere Laufzeiten möglich sind. Es wird sich bestimmt noch viel tun.

Zum produktiven Einsatz ist es noch nicht gedacht, aber für die eigenen Tests und Spielerein, warum nicht!?

Und vor allem: Kostenlose SAN-Zertifikate einfach per Windows Client anfordern und ggf. noch den IIS gleich mit konfigurieren lassen? Das wäre doch zu schön um wahr zu sein, oder? Genau so ist es aber von Let’s Encrypt vorgesehen. Es bleibt spannend.

Der Beitrag Let’s Encrypt: Kostenlose Zertifikate für Exchange Server erschien zuerst auf Franky's Web.