Also ich kenne diese Thematik mit verschiedenen Herstellern immer nach dem gleichen Prinzip:
- Du fährst zwar zwei VLANs auf einem Switchport aber nicht beide getagged sondern das Client VLAN untagged und zusätzlich das Telefon VLAN tagged
- Dann richtest Du Dein IP Telefon so ein das es tagged mit dem VLAN der TK kommuniziert
- Am zweiten LAN Port des Telefons kommt untagged das VLAN für den Client an der somit in seinem VLAN kommuniziert und nichts vom Telefon VLAN mitbekommt.
Wir haben wirklich alles richtig gemacht bei der Migration, die Quelle der Probleme lag leider wie so oft komplett wo anders...
Auch wenn ich euch technisch leider nicht wirklich die Ursache erklären kann, die NTDS.dit auf dem Quellserver (das war mal ne Zweiserver Umgebung mit DC + MSX + + + auf der einen Maschine sowie ein TS) wurde mittlerweile eine sauber aufgeteilte Umgebung mit einem reinen Exchange Server, aber das ändert natürlich nichts mehr am Verhalten des alten Exchange.
Ja, mit Eventlog prüfen in allen Unterbereichen hätte es mir auch früher auffallen können, ich wurde stutzig als mir der Quellserver in der Powershell noch Postfächer für die Datenbank angezeigt hat die schon migriert waren und so kam ich dann eben erst auf die Idee mal wieder ins Eventlog zu sehen...
Fehlerbild waren diverse Fehlermeldungen, angefangen bei NTDS (696) NTDSA: Datenbank C:\Windows\NTDS\ntds.dit: Index DRA_USN_index von Tabelle datatable ist beschädigt (0).
Noch detailierter wurde es hier:
Dieses Ereignis enthält Reparaturvorgänge für das Ereignis "1084", das zuvor protokolliert wurde. Diese Meldung deutet auf ein bestimmtes Problem in Bezug auf die Konsistenz der Active Directory-Domänendienste-Datenbank für dieses Replikationsziel hin. Bei der Übernahme von Replikationsänderungen für das folgende Objekt ist ein Datenbankfehler aufgetreten. Die Datenbank enthält nicht erwartete Inhalte, die verhindern, dass die Änderung durchgeführt wird.
Objekt:
CN=Ruiter Tanja,OU=Lehrer,OU=Benutzer,..............
Objekt-GUID:
203ca1ec-0077-4aee-ba28-d3779e42b61a
Quell-DC:
db2753ff-5192-4b96-867e-c998ef49e18e._msdcs...........
Benutzeraktion
Weitere Informationen finden Sie im KB-Artikel 837932 unter "http://support.microsoft.com/?id=837932".Ein Teil der Reparaturvorgänge ist dort aufgelistet.
1. Stellen Sie sicher, dass genügend freier Speicherplatz auf den Volumes vorhanden ist, auf denen die Directory-Datenbank gehostet wird, und wiederholen Sie den Vorgang. Stellen Sie sicher, dass sich die physikalischen Laufwerke, auf denen NTDS.DIT und die Protokolldateien gehostet werden, nicht auf Laufwerke befinden, auf denen NTFS-Komprimierung aktiviert ist. Prüfen Sie, ob Antivirussoftware auf diese Volumes zugreift.
2. Es ist eventuell vorteilhaft, wenn der Sicherheitsbeschreibungspropagierer gezwungen wird, die Objektcontainerherkunft in der Datenbank erneut zu erstellen. Dies kann entsprechend den Anweisungen im KB-Artikel 251343 unter "http://support.microsoft.com/?id=251343"durchgeführt werden.
3. Das Problem kann ggf. auch beim übergeordneten Objekt auf diesem Domänencontroller auftreten. Verschieben Sie das Objekt auf dem Quell-DC zu einem anderen übergeordneten Objekt.
4. Wenn dieser Computer ein globaler Katalog ist und der Fehler in einer der schreibgeschützten Partitionen auftritt, sollten Sie den Computer als globalen Katalog über das Kontrollkästchen "Globaler Katalog" in der Anwendung "Standorte und Dienste" herabstufen. Wenn der Fehler auf einer Anwendungspartition auftritt, können Sie das Hosten der Anwendungspartition auf diesem Replikat beenden. Dies kann mit dem Befehl NTDSUTIL.EXE durchgeführt werden.
5. Beziehen die neueste Version von NTDSUTIL.EXE, indem Sie das neueste Service Pack für dieses Betriebssystem installieren. Stellen Sie sicher, dass das DSRM-Kennwort (Directory Services Restore Mode) bekannt ist, bevor Sie den DSRM-Modus starten. Setzen Sie es andernfalls zurück, bevor Sie das System neu starten.
6. Führen Sie unter einer NT-Eingabeaufforderung im DSRM den Befehl "NTDSUTIL files integrity" aus. Stufen Sie das Replikat herab und überprüfen Sie die Hardware, wenn eine Beschädigung gefunden wurde und andere Replikate vorhanden sind. Stellen Sie das System über eine Sicherung wieder her, und wiederholen Sie diese Verifizierung, wenn keine Replikate vorhanden sind.
7. Führen Sie eine Offlinedefragmentierung mit dem Befehl "NTDSUTIL files compact" aus.
8. Der Befehl "NTDSUTIL semantic database analysis" sollte ebenfalls ausgeführt werden. Wenn Fehler gefunden wurden, können diese mit der Funktion "go fixup" behoben werden. Dies sollte nicht mit der Datenbankwartungsfunktion "ESE repair", die in diesem Fall nicht verwendet werden sollte, verwechselt werden, da dies zu Datenverlust bei der Active Directory-Domänendienste-Datenbank führt.
Wenn keine dieser Aktionen erfolgreich ist und der Replikationsfehler weiterhin auftritt, sollten Sie diesen Domänencontroller herab- und anschließend wieder heraufstufen.
Zusätzliche Daten
Primärer Fehlerwert:
8451 Der Replikationsvorgang ist auf einen Datenbankfehler gestoßen.
Sekundärer Fehlerwert:
-1414 JET_errSecondaryIndexCorrupted, Secondary index is corrupt. The database must be defragmented
Die Lösung war trotz Bauchweh erstaunlich einfach: Server im Verzeichnisdienst Wiederherstellungsmodus starten, mit ESEUTIL die DB defragmentieren und nach einem Neustart und ein paar Minuten warten war das komplette Active Directory endlich wieder sauber und die Exchange Migration lief vollends sauber durch.
Lange Suche - Kurze Lösung: AD Replikation bei Exchange Migrationen im Auge behalten!
Ich glaub es nicht! Fehlersuche in der IT, eine Wissenschaft für sich!
Norbert hat mich in die richtige Richtung geschoben durch seine verdeckten Hinweise Richtung Autodiscover. Nach Tagen der Grübelei und eben seinen Andeutungen habe ich wohl oder über mal das Tracing per Whireshark bemüht und was sahen meine müden Äuglein da: Der Client hat bei meinem User die direkte Kommunikation Richtung Exchange gesucht, nur bei den Sorgenkindern über einen Proxy???
Also in den GPOs gegraben und den Unterschied endlich gefunden: Die User die Probleme machen gehen über einen Proxy, die User die funktionieren.....
Kleine Ursache - große Wirkung!
Jetzt vergrabe ich mich mal in den GPOs und wie ich das beheben kann, die Proxy GPO kommt nämlich noch aus der Server 2003 Zeit und arbeitet im IE Voreinstellungsmodus weswegen ich sie nicht mehr bearbeiten kann....
Ihr werdet es nicht glauben! Es ist wie so oft - richtig gemacht und funktioniert trotzdem erst mal nicht! Nach langem suchen (sitze seit heute Mittag an dem Thema) bin ich gerade über diesen Artikel gestolpert: http://grantcurell.com/2013/12/31/failed-to-retrieve-directory-listing-filezilla-connecting-to-iis-behind-nat/
Da steht etwas zum Haare raufen: Den FTP Dienst nicht im IIS neu starten sondern über die Dienstesteuerung, das ist NICHT das gleiche!
Kaum machte ich es über services.msc.....
Sollte also noch mal jemand suchen, es funktioniert jetzt sauber und ich kann SSL erzwingen womit Klartext der Geschichte angehört :-)
Sachen gibt´s - die gibt´s gar nicht. Nachdem noch mehr nicht löschbare Dateien aufgetaucht sind haben wir den Server mit einem CHKDSK /f mal das Laufwerk C: detailiert prüfen lassen und siehe da - wir können wieder den Besitz übernehmen und die Daten / Ordner löschen. War also das Dateisystem fehlerhaft und nicht der Weg wie es versucht wurde :-)
dataKEKS's post in VLAN - IP-Phone -Client ein Kabel wurde als beste Lösung markiert.