Hope This Helps

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

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

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

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

Problem:
Das Verschieben von Postfächern vom Exchange 2007 auf den Exchange 2013 (CU14) funktioniert plötzlich nicht mehr oder es dauert extrem lange!

Lösung:
Nach einiger Suche habe ich herausgefunden, dass der "Exchange Context Index" auf dem Exchange 2013 "Failure" anzeigt.
Das kann man einfach prüfen mit dem folgenden Powershell-Befehl:

Get-MailboxDatabaseCopyStatus

Hier muss bei jeder angezeigten Datenbank ganz hinten der Status "ContentIndex State" auf "Healthy" stehen.
Wenn das nicht der Fall ist und hier steht "Failed", dann ist der Indexer fehlerhaft und daher können die Postfächer nicht mehr verschoben werden.

Warum ist der Status so und wie bringt man nun den Indexer wieder "online"?
Der Grund hierfür hat mich etwas beschäftigt und ich bin auch einen MS-Eintrag gestoßen, in dem der Fehler beschrieben wird und dass eine spezielle ActiveDirectory-Gruppe noch nötig ist, damit der Crawler-Service richtig funktioniert:
Microsoft: Content Index status of all or most of the mailbox databases in the environment shows "Failed"
Ich bin dann nach der Microsoft-Vorgabe vorgegangen:

1.) Erstellen Sie eine universelle Sicherheitsgruppe namens "ContentSubmitters" in der ActiveDirectory
2.) Geben Sie folgenden Benutzer auf diese Gruppe "Vollzugriff": Administratoren, Netzwerkdienst
3.) Beenden Sie die folgenden Exchange-Dienste: "Microsoft Exchange Search" und "Microsoft Exchange Search Host Controller"
4.) Ich habe die Gruppe dann noch in die OU "Exchange Security Groups" verschoben, damit sie mir keiner wegen Unwissenheit löscht und ich auch noch später weiß, dass diese zum Exchange gehört!

Nach einigen Minuten war der "ContentIndex State" auf dem Status "Healthy" und ich konnte wieder Postfächer problemlos verschieben! Sollte das immer noch nicht funktionieren, dann bitte nochmals beide Dienste stoppen und den "Content Index data"-Ordner auf dem Exchange-Server löschen. Diesen finden Sie mit einer GUID als Verzeichnis im Pfad der EDB-Datenbank.

Warum Microsoft diese Prozedur nicht bei den Installationsvorgaben aufführt, ist für mich ein Rätsel!?! Vroallem habe ich den Fehler im Zusammenhang mit CU1 gefunden. Ich ahbe CU14 installiert!

Quellen für Lösungsfindung:
ril3y: Exchange 2013 Content Index failure causes stalled Mailbox Migration
Microsoft: Content Index status of all or most of the mailbox databases in the environment shows "Failed"

Ich habe hier eine schöne Übersicht gefunden, welche Dienste (OWA, ECP, ActiveSync etc.) bei einer Koexistenz Exchange 2007/2010 mit einem Exchange 2013 wie behandelt wird (Proxy oder Redirect):


Quelle:
VANHYBRID.COM: Exchange 2013 interoperability with legacy Exchange versions