59cobalt

Offensichtlich filtert irgendetwas den Verbindungsaufbau zwischen den beiden Hosts. Deaktiviere mal die Firewall auf beiden Servern. Wenn der Verbindungsaufbau danach immer noch nicht funktioniert, filtert die ASA. Funktioniert der Verbindungsaufbau, aktiviere als nächstes die Windows-Firewall auf dem Zielserver. Funktioniert ein erneuter Verbindungsaufbau danach nicht mehr, filtert diese Firewall. Danach wiederholst du dasselbe mit der Firewall auf dem Quellserver.

Funktioniert "telnet 10.17.x.x 3389"? Was gibt "tracetecp 10.17.x.x:3389 -n" aus?

Ob man SCVMM kaufen sollte oder nicht hängt von der konkreten Umgebung ab. Bei einem Standalone-Hypervisor mit HBA beispielsweise halte ich das für völligen Overkill. Man kann auch preiswerter konvertieren. VMware Converter wurde ja schon erwähnt. Von Sysintern^WMicrosoft gibt es für P2V Disk2vhd. VMware VMs kann man auch manuell V2V migrieren, indem man die VMDK-Dateien nach VHD konvertiert (z.B. mit WinImage, die Testversion genügt dafür) und dann im Hyper-V eine neue VM mit entsprechenden Parametern erstellt. Dabei muss man allerdings darauf achten, dass in der VMware VM ein Device als primary IDE master angeschlossen ist (CD-Laufwerk genügt dafür). Andernfalls kann man das System nicht von der konvertierten VHD booten, weil der Treiber für den IDE-Controller fehlt.

Das Problem existiert nur bei diesem einen Client, nicht bei allen anderen, korrekt? Die Firewall ist auf Client und DCs deaktiviert bzw. auf durchlässig geschaltet? Wie sieht die IP-Konfiguration (ipconfig /all) des Clients und eines DCs aus? Führe auf dem Client mal "ping 192.168.202.8" und/oder "nslookup IRGENDEINNAME 192.168.202.8" aus und schau dir dabei den entsprechenden Traffic mit Wireshark oder MS Network Monitor auf Client und DC an. Kommen die Requests nicht beim DC an, oder die Antworten nicht beim Client? Ist die VM auf dem Hypervisor am richtigen vSwitch angeschlossen? Wird auf dem Hypervisor Netzwerkverkehr gefiltert? Sind im Netzwerk VLANs konfiguriert? Ist die VM im richtigen VLAN?

Wenn du die Frustration deiner User maximieren willst: sei restriktiv.

Verwendung der Domänenhierarchie für die Synchronisation ist im Regelfall die bessere Wahl, aus mehreren Gründen: - funktioniert out-of-the-box - man muss nichts zusätzlich konfigurieren, und kann daher auch nicht vergessen, etwas zu konfigurieren - wenn nicht alle Systeme virtualisiert sind und ihre Zeit vom Hypervisor beziehen, muss man zwei Synchronisationsmechanismen verwalten - ist die Domäne über mehrere Standorte verteilt, versuchen die Clients zunächst erst mal die Synchronisation mit einem lokalen Domänencontroller, und erst wenn das nicht möglich ist mit einem off-Site DC

Was genau ist das "nicht Schlaue", das man im Eventviewer sieht? Was gibt dcdiag aus? Verwendest du FRS- oder DFS-Replikation? Wenn du DFS-Replikation verwendest, und sich rausstellt, dass du das reparieren musst: Restoring and Rebuilding SYSVOL: Active Directory BTDT. Macht keinen Spaß.

Restoring and Rebuilding SYSVOL: Active Directory

Weil in Windows-Domänen die Zeitsynchronisation normalerweise über die Domänenhierarchie läuft, und davon ausgeht, dass die zentrale Zeitquelle der Inhaber der FSMO-Rolle "PDC Emulator" ist.

Du kannst mit "w32tm /query ..." den Status der Synchronisation überprüfen (Peers, Offset, letzte erfolgreiche Synchronisation, ...). Generell empfehle ich, die Systemzeit entweder per NTP oder über die Integration Services mit dem Hypervisor zu synchronisieren. Andernfalls hat man gern mal das Problem, dass die per NTP synchronisierte Zeit gleich wieder übersteuert wird. Wenn du dich für NTP entscheidest, wähle das Synchronisationsintervall nicht zu groß. Ist der Offset erst mal zu groß, funktioniert die Re-Synchronisation nicht mehr. Die Einstellungen für Intervall, max. Abweichung, etc. machst du per Gruppenrichtlinie. Wenn die Systemuhr immer noch Drift zeigt, kannst du dort auch Einstellungen zur Korrektur des Drifts vornehmen.