Hope This Helps

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

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