Hope This Helps

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

Problem:
Szenario: Windows Server 2008 R2 aktuell gepatcht - Exchange 2013 CU14 installiert

Beim Versuch auf die Powershell zuzugreifen, wird folgender Fehler mehrfach ausgegeben:

VERBOSE: Connecting to exchange2013. New-PSSession : [exchange2013] Connecting to remote server exchange2013 failed with the following error message : [ClientAccessServer=exchange2013,BackEndServer=exchange2013,RequestId=fd9724cd-19fb-4842-b30d-c9c4b976119f,TimeStamp =2016-03-24 18:55:58] [FailureCategory=Cafe-SendFailure] For more information, see the about_Remote_Troubleshooting He lp topic. At line:1 char:1 + New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Microsoft CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException + FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed

Lösung:
Nach etwas Recherche war mir klar, dass es mit dem SSL-Zertifikat von Exchange zu tun haben muss.

1. Lösungsansatz:
Bitte prüfen Sie im IIS-Manager ob sowohl bei der "Default Web Site" und der "Exchange Back End" unter "Bindungen" -> HTTPS das richtige (oder überhaupt ein gültiges) SSL-Zertifikat zugewiesen ist. Eventuell bei der Powershell-Website unter "Exchange Back End" auch mal bei den "SSL-Einstellungen" den Haken bei "SSL erforderlich" entfernen - somit wird das SSL-Zertifikat ignoriert und man kann prüfen, ob dann die Powershell-Verbindung funktioniert.

2. Lösungsansatz (Fehler bei mir):
Nachdem das Zertifikat in Ordnung war, musste ich nach einem anderem Fehler suchen.
Fündig würde ich im Ereignisprotokoll hier habe ich folgenden Eintrag gefunden:

Schannel - Event-ID: 36885
Bei der Nachfrage der Clientauthentifizierung sendet dieser Server eine Liste vertrauenswürdiger Zertifizierungsstellen an den Client. Der Client verwendet diese Liste, um ein Clientzertifikat auszuwählen, das für den Server vertrauenswürdig ist. Momentan vertraut dieser Server sehr vielen Zertifizierungsstellen, sodass die Liste zu lang ist. Die Liste wurde abgeschnitten. Der Administrator dieses Computer sollte die für Clientauthentifizierung vertrauenswürdigen Zertifizierungsstellen überprüfen und diejenigen entfernen, die nicht unbedingt als vertrauenswürdig eingestuft werden müssen.

Mit dieser Meldung habe ich mittels Zertifikats-MMC ein mal die "Vertrauenswürdigen Stammzertifikatsstellen überprüft" und hier 299(!!) Zertifikate gefunden, die Großteils mir überhaupt nicht bekannt waren. Eine weitere Suche im Netz hat folgenden Microsoft-Artikel hervorgebracht: Microsoft: SSL/TLS communication problems after you install KB931125
Hier wird beschrieben, dass so etwas auftreten kann, nach der Installation des Updates KB931125.
Die Lsöung im Artikel habe ich wie folgt durchgeführt:

1.) Öffnen Sie den Registry-Editor (regedit.exe)
2.) Navigieren Sie zu folgendem Pfad: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
3.) Exportieren Sie diesen Pfad sicherheitshalber und löschen Sie Ihn danach!

Danach hatte ich nur noch ca. 20 Zertifikate in den vertrauenswürdigen Stammzertifikatsstellen und meine Powershell und alle HTTPS-Seiten auf meinem Exchange 2013 liesen sich problemlos öffnen!

Quelle der Lösungsfindung:
blackseals.net: Liste der vertrauenswürdigen Stamm-Zertifizierungsstellen ist zu lang
Microsoft: SSL/TLS communication problems after you install KB931125

Problem:
Nach der Installation des Exchange 2013 habe ich mich an der ECP-Webiste (Exchange Admin Center) als Administrator angemeldet und gleich den Fehler "403 - Seite nicht gefunden" angezeigt bekommen.
Wir haben eine Koexistenz mit einem Exchange 2007!

Lösung:
Das Problem besteht, solange das Administrator-Postfach, mit dem ich mich anmelde, noch auf dem "alten" Exchange 2007 befindet. Sobald man das Postfach auf den Exchange 2013 verschoben hat, funktioniert die Website problemlos.

Lösung 1:
Verschieben Sie das Postfach mittels Powershell auf den neuen Server (Cmdlet "New-MoveRequest")

Lösung 2:
Sie kopieren Ihren bestehenden Administrator in der ActiveDirectory und erstellen für diesen ein Postfach auf dem neuen Exchange 2013 über die Powershell (Cmdlet "New-Mailbox")

Lösung 3 (So habe ich es gelöst):
Sie greifen auf die ECP-Website mit einem modifizierten Link zu, der den Zugriff ermöglicht

https://exchange2013-name/ecp?ExchClientVer=14

Wobei Sie hier noch den richtigen Namen Ihres Exchange 2013-Servers eintragen müssen!

Quelle für Lösungsfindung:
Microsoft Blog: ECP and E-Discovery when having coexistence : Exchange 2013-2010-2007
IT-Feed: Exchange 2013 – Anmeldung an Adminseite schlägt mit 403-Fehler fehl

Problem:
Wenn wir neue Computer in die AD aufnehmen und diese nicht in die richtige OU Verschieben, dann wirken die ganzen GPOs nicht auf den jeweiligen Rechner (Software, Einstellungen, Admins etc.). Ich wollte eine Benachrichtigung beim Anmelden bekommen, wenn der Computer sich noch in der Default-OU befindet. Da die OU "Computers" keine GPOS zulässt, wollte ich neue Computer in einer eigenen OU Erstellen und hier eine Inital-GPO wirken lassen mit Benachrichtigungstext beim Anmelden.


Lösung:
Die Voraussetzungen für die nachstehende Lösung ist eine Domänenlevel mindestens "Windows Server 2003".

Folgende Vorgehensweise um die neue Default-OU für Computer zu erstellen:

1.) Erstellen Sie eine neue OU (z.B. "NewComputers") und schützen Sie diese vor unabsichtlichen Löschen!

2.) Geben Sie auf einem DC folgenden Befehl in einer CMD mit Admin-Rechten ein:
redircmp OU=NewComputers,DC=domain,dc=tld
(z.B. in der Domäne demo.local würde der Befehl wie folgt heißen: redircmp OU=NewComputers,DC=demo,dc=local)

3.) Testen der neuen Einstellung, in dem man einen Computer der Domäne hinzufügt!


Quelle:IT Pro Central: How to define an OU as default location for new Computer objects

Problem:
Bei meiner Exchange-Installation wollte ich auf einem Server 2008R2 mittels Powershell alle nötigen Features hinzufügen. Dabei ist mir die Routine immer bei der Installation "NET-HTTP-Activation" auf den Fehler 0x800f081f gelaufen.


Lösung:
Nach einigem Probieren bin ich auf einen Eintrag im Internet gestoßen, wie man das .NetFX3 manuell installieren kann.
Hierzu bitte eine Installations-DVD in das Laufwerk legen (hier E:) und den folgenden Befehl als Administrator starten:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:E:\sources\sxs

Wobei Source: eventuell angepasst werden muss, je nachdem wo das Laufwerk gemountet ist.

Danach ließ sich die die NET-HTTP-Activation problemlos per Powershell installieren.