Exchange 2013: Übernahme der Transport-Regeln (Disclaimer) vom alten Exchange 2007

Problem:
Ich ziehe gerade unseren Exchange 2007 auf den Exchange 2013 um. Dabei muss ich auch die Transport-Regeln wie z.B. Disclaimer und Weiterleitungen migrieren. Im ersten Augenblick dachte ich, die Übernahme muss manuell erfolgen, was einen nicht unerheblichen Zeitaufwand bedeutet hätte - alleine die Disclaimer mit allen Formatierungen wären viel Arbeit gewesen.

Lösung:
Man kann die Transport-Regeln aus dem alten Exchange 2007 exportieren und in den Exchange 2013 importieren.
Folgende Vorgehensweise hierzu:

Exchange 2007
Öffnen Sie die Powershell auf dem alten Exchange 2007 und führen Sie folgenden Befehl für dne Export aus:
Export-TransportRuleCollection -FileName "C:\ExportedRules.xml"

Danach finden Sie eine Datei ExportedRules.xml unter C:\ vor. Diese kopieren Sie auf den Exchange 2013!

Exchange 2013
Vergewissern Sie sich, dass die Datei ExportedRules.xml auf dem Exchange 2013 vorliegt.
Öffnen Sie die Powershell und führen Sie folgende Befehle für den Import der Transport-Regeln durch:
[Byte[]]$Data = Get-Content -Path "C:\ExportedRules.xml" -Encoding Byte -ReadCount 0 
 Import-TransportRuleCollection -FileData $Data

Danach können Sie in der Exchange-Verwaltungswebsite prüfen, ob unter "Nachrichtenfluss" -> "Regeln" alle Transport-Regeln erfolgreich übernommen wurden. Prüfen Sie bitte auch die Funktionsfähigkeit der Regeln.
Bei mir hat das problemlos funktioniert!

Quelle:
MS Technet: Part 2: Step-by-Step Exchange 2007 to 2013 Migration
Microsoft: You cannot migrate transport rules from Exchange Server 2007 to Exchange Server 2013

ActiveDirectory: Sicheres Schema-Update (ADPREP) mittels Replikations-Pause

Vorgehenweise um ein sicheres ActiveDirectroy-Schema-Update durchzuführen

Viele haben bestimmt schon ein ActiveDirectory-Schema-Update durchgeführt, ohne sich der Risiken bewusst zu sein, oder diese zu ignorieren. Ich hatte vor kurzem das erste Mal einen Stromausfall bei einem Schema-Update - glücklicherweise in einer Demo-Umgebung. Das Schema war danach zerstört und hatte sich aber beim Neustart der Server bereits repliziert - ActiveDirectory komplett zerstört, nur noch Fehlermeldungen beim Zugriff auf Objekte!
Um das zu verhindern, habe ich mir eine Anleitung zusammengebaut, in der ich wie folgt vorgehe:

1.) Verzeichnis-Replikation auf dem Schemamaster deaktivieren
2.) ADPREP durchführen
3.) Testen des Zugriffs auf die AD (ActiveDirectory-Benutzer und -Computer)
4.) Verzeichnis-Replikation wieder aktivieren
5.) Test der ActiveDirectory

Dazu gehe ich wie folgt vor:

1.) Schemamaster finden
Dazu verwende ich den Befehl "netdom query fsmo" und schau, welcher DC der Schemamaster ist

2.) Aktuelle Schema-Version ermitteln
Hierzu verwende ich auf dem Schemamaster den Befehl DSQUERY.
Hier ein Beispiel für die Domäne DEMO.LOCAL
dsquery * CN=Schema,CN=Configuration,DC=DEMO,DC=LOCAL -Scope Base -attr objectVersion

Kleiner Tipp, falls es sich um ein Exchange-Schema-Update handelt - mit diesem Befehl kann ich die Exchange-Version des Schemas auslesen:
dsquery * CN=ms-Exch-Schema-Version-Pt,cn=schema,cn=configuration,dc=DEMO,dc=INTERN -scope base -attr rangeUpper


3.) Verzeichnis-Replikation auf dem Schemamaster deaktivieren
Hierzu verwendet ich die den Befehl "repadmin" um die eingehende und ausgehende Replikation zu deaktivieren:
(SCHEMAMASTER-NAME muss angepasst werden)

repadmin /options SCHEMAMASTER-NAME +DISABLE_OUTBOUND_REPL
repadmin /options SCHEMAMASTER-NAME +DISABLE_INBOUND_REPL

Danach findet man im Ereignisprotokoll die Ereignisse 1113 und 1115, die darauf hinweisen, dass eingehende und ausgehende Replikation vom Benutzer deaktiviert wurde (Ereignisprotokoll VERZEICHNISDIENST)


4.) Schema-Update durchführen
Jetzt führt man das Schema-Update durch mittels diesen drei Befehlen:
adprep /forestprep
adprep /domainprep
adprep /rodcprep


Im Ereignis-Protokoll werden die Aktualisierungen auch mit protokolliert:


5.) Prüfen der neuen Schema-Version
Nun kann man mittels DSQUERY-Befehl prüfen, ob die neue Schema-Version vorliegt
dsquery * CN=Schema,CN=Configuration,DC=DEMO,DC=LOCAL -Scope Base -attr objectVersion
Als Test dann man sich mal auf einen anderen DC einloggen und den Befehl ebenfalls durchführen.
Hier wird man sehen, dass die Schema-Version noch die alte Version ist, da die Replikation nicht aktiv ist!

6.) Testzugriff auf die AD auf dem Schemamaster
Öffnen Sie einige AD-Konsolen auf dem gerade aktualisieren Schemamaster und klicken Sie sich durch, ob es zu Fehlermeldungen kommt. Wenn alles in Ordnung ist, dann können Sie die Replikation wieder aktivieren.

7.) Replikation wieder aktivieren und das Schema global aktualisieren

Starten Sie auf dem Schemamaster mittels der nachfolgenden Befehle wieder die ein- und ausgehende Replikation:

repadmin /options SCHEMAMASTER-NAME -DISABLE_OUTBOUND_REPL
repadmin /options SCHEMAMASTER-NAME -DISABLE_INBOUND_REPL


Das Aktivieren der Replikation wird ebenfalls wieder im Ereignisprotokoll angezeigt:



8.) Prüfen der neuen Schema-Version
Starten Sie die Replikation der DCs manuell oder warten Sie den Zyklus ab. Danach prüfen Sie auf allen bestehenden DCs, ob das Schema übernommen wurde mittels des vorherigen DSQUERY-Befehl.

9.) FERTIG!

Damit haben Sie eine risikoarme Schema-Erweiterung durchgeführt und minimieren das Risiko, dass die ActiveDirectory beschädigt wird.

Quellen für die Hilfestellung:
Directory Services: Upgrading AD DS Schema to Windows Server 2016
ANTARY: Active Directory Schema Version herausfinden




Exchange 2013: 451 4.7.0 Temporary server error. PRX5

Problem:
Ab und zu gibt der Exchange 2013 folgenden Fehler beim Empfangen von Mails zurück:
451 4.7.0 Temporary server error. Please try again later. PRX5

Ursache:
Scheinbar gibt es hier DNS-Probleme, wenn der Server seine interne Struktur auflösen will.
Genau habe ich das Problem noch nicht vollständig analysieren können.

Lösung:
Hier gibt es zwei einfache Lösungsansätze:

1.)Anpassen des DNS-Lookups am Exchange
- Öffnen Sie die ECP-WEbsite und navigieren Sie zu "Server" -> "Server" -> "DNS-Lookups"
- Stellen Sie hier explizit die richtige Netzwerkkarte ein, über die der Exchange mit dem LAN verbunden ist (Default: Alle Netzwerkkarten)
- Tragen Sie hier Ihre internen DNS-Server vollständig ein


2.) Eintrag in HOSTS-Datei
- Öffnen Sie die HOSTS-Datei und tragen Sie hier den FQDN und NetBIOS-Namen Ihres Exchange-Servers mit der richtigne IP-Adresse ein


Nach den Änderungen müssen Sie folgende Exchange-Dienste neu starten:
- Microsoft Frontend Transport
- Microsoft Exchange Transport

Erste danach ziehen die neuen Einstellungen.
Ich konnte den Fehler so beheben (bis jetzt zumindest!)

Quelle: support.everycloudtech.com: 451 4.7.0 Temporary server error. Please try again later. PRX5

Exchange: Kostenloses SAN-Zertifikat bei StartSSL für Serverumzug

Problem:
Während meines Exchange-Server-Swings habe ich temporär ein zweites SAN-Zertifikat benötigt und wollte ein öffentliches haben, da sonst die Smartphones über ActiveSync Probleme machen!

Lösung:
Ich habe bei StartSSL ein kostenloses SAN-Zertifikat bekommen. Der Vorteil für mich, gegenüber von Let'sEncrypt", das Zertifikat ist ein Jahr gültig (nicht nur 3 Monate) und ich konnte eine CSR-Anfrage von meinem Exchange "reinkippen".

Nachteil:
Das Zertifikat ist nur ein Jahr gültig und wird von Apple als unsicher eingestuft (Nicht verwunderlich). Der Internet Explorer hat das Zertifikat als valid eingestuft, da hier noch die Root-CA als vertrauenswürdig gilt.

Als temporäres OWA- und SMTP-SAN-Zertifikat hat es für mich gereicht und hat auch super geklappt!

Franky hat hier eine super tolle Anleitung dazu gemacht (Wie immer!!): Frankys Web: Kostenlose SAN-Zertifikate auch bei StartSSL

...und StartSSL findet Ihr hier: StartSSL.com

Exchange 2013: ActiveSync meldet "HTTP 500 response (Internal Server Error)" und das Smartphone "Authentifikation fehlgeschlagen "

Problem:
Beim Versuch ein Smartphone auf einem Exchange 2013 mittels ActíveSync anzubinden habe ich am Gerät selbst ständig den Fehler "Authentifikation fehlgeschlagen".
Beim Testen mittels "Microsoft Remote Connectivity Analyzer" unter https://testconnectivity.microsoft.com/ habe am Ende ein "HTTP 500 response (Internal Server Error)" bekommen.
Eigenartigerweise haben manche Benutzer problemlos funktioniert.

Lösung:
Nach längerer Suche und Analyse bin ich auf einen Microsoft-Artikel gestoßen, der auf ein Rechte-Problem des Benutzer in der ActiveDirectory hinweist. Dabei ist die Vererbung von Rechten in der Benutzer-Sicherheit nicht aktiviert und daher bekommt der Exchange nicht die nötigen Rechte auf das Benutzer-Objekt.

Bitte einmal folgendes überprüfen:
1. Öffnen Sie ActiveDirectory-Benutzer und -Computer.

2. Öffnen Sie das Menü im oberen Bereich der Konsole, und klicken Sie auf Ansicht > Erweiterte Funktionen.

3. Wechseln Sie zum Postfachkonto, klicken Sie mit der rechten Maustaste auf dieses Konto, und klicken Sie anschließend auf Eigenschaften.

4. Klicken Sie auf die Registerkarte Sicherheit.

5. Klicken Sie auf Erweitert.

6. Stellen Sie sicher, dass das Kontrollkästchen für "Vererbbare Berechtigungen des übergeordneten Objektes einschließen" aktiviert ist.

Wenn das NICHT der Fall ist, dann bitte bei einem Benutzer testweise mal umstellen und die Vererbung wieder aktivieren.
Bei mir war das nur bei ehemaligen Domänen-Admins der Fall. Da der Domänen-Admin hier mein Test-Objekt war, ist der Fehler natürlich aufgetreten! Deshalb hat auch alles bei den anderen Benutzern problemlos funktioniert!

Quelle der Lösung:
Microsoft Technet: Exchange ActiveSync hat den Fehler "HTTP 500" zurückgegeben
careexchange.in: Exchange ActiveSync returned an HTTP 500 response (Internal Server Error).

“Die Organisationen stecken Millionen von Dollars in Firewalls und Sicherheitssysteme und verschwenden ihr Geld, da keine dieser Maßnahmen das schwächste Glied der Sicherheitskette berücksichtigt: Die Anwender und Systemadministratoren.”
Kevin Mitnick