MS-Wing

Nils, ich wollte hier keinen auf den Schlips treten und mir sind die "Best-Practices" natürlich wohl bekannt. Es hätte aber durchaus sein können, das jemand einen laufenden RODC (mir laufenden AD Diensten) schonmal geklont hat und deshalb auch die Auswirkungen kennt. Da ich aber auf Nummer sicher gehen möchte habe ich alle kritischen Dienste eben deaktiviert und dann den Klon vorgenommen. Danke nochmal an alle für die wertvollen Tipps!

Was wird denn im AD genau "zerstört", wenn ein ReadOnly DC (ohne laufende AD, FRS, DFS und DNS Dienste!!!) geklont und dann wieder hochgefahren wird? Jetzt bin ich mal gespannt....

Problem ist bei dieser VM, das sie auf einer Riverbed liegt auf die wir keinen vollen Zugriff haben und ich somit nicht direkt an das vmdk komme. Ich habe in der Zwischenzeit als Trockenübung das ganze Szenario mal virtuell aufgebaut und durchgespielt. Also AD/DNS auf dem ReadOnly DC stoppen, dann klonen nach VHD mit dem Sysinternals-Tool und dann unter Hyper-V wieder hochfahren. Ging reibungslos und downtime des DC waren nicht mal 10 Minuten. Das ganze dann noch weiter beobachtet und auch keine Replikationsfehler gesehen. Also hat die Praxis mein "Gedankenexperiment" bestätigt. :cool:

Der "Read Only" DC soll geklont werden, da es maximal 30 Minuten downtime für den DC in der Lokation geben darf. IP Addresse und Name des DCs müssen gleich bleiben. Deshalb nochmal die Frage: (Siehe oben :wink2: ) Ich kann eure Argumente sehr gut für "normale" DCs (read/write) verstehen und würde dort niemals auf die Idee kommen zu klonen... Aber bei "Read Only" DCs?...... Im absoluten Zweifelsfall könnte ich alle AD relevanten Dienste auf dem DC stoppen, dann den Klon durchführen und diesen Klon wieder hochfahren. Das dürfte ja dann absolut schmerzfrei sein. Zum Thema VMware Server 2.0: Kaum zu glauben, aber dies ist immer noch die aktuelle Virtualisierungslösung auf einem Riverbed Accelerator! Und dort liegt momentan der DC mit entsprechend mieser Performance.

Das beantwortet ja nicht die Frage. Frage ist wie das AD auf mein spezielles Scenario reagiert. (Falls es überhaupt reagiert)

Hallo, ich habe einen Windows Server 2008 R2 Read-Only DC unter VMWare Server 2.0 laufen. Diesen möchte ich gerne 1:1 nach Hyper-V migrieren. Der Plan: Mit Disk2VHD von sysinternals.com zum Hyper-V Server klonen Dann den Klon entsprechend anpassen (VMWare Tools entfernen, Hyper-V Integration services install. etc.) VMWare Server VM herunterfahren Hyper-V VM in das Produktive Netz hängen. Frage: Ist dies OK, oder wird dann das AD darunter leiden? Da es ja "nur" ein Readonly-DC ist, kann der DC ja eigentlich nichts ins AD replizieren, sondern bekommt ja nur replikas des AD. Wie reagieren die beschreibbaren DCs, wenn sie merken das der Read Only DC eine ältere Kopie der Replika als eigentlich erwartet hat? Habe schon entsprechend gegoogelt, aber nix dazu gefunden. Bei beschreibbaren DCs ist das natürlich fatal... Aber bei Read only?.... Was meinen die Experten hier?

Kleines Feedback: Ich habe den Hotfix ausprobiert und er hat an dem Verhalten nichts geändert...

Ja.... Sehr guter Tipp! :) Hätte mich gewundert, wenn der 32bit download fehlt.

Au weia! Das hört sich 100% nach einem brauchbaren Fix an und beschreibt genau das was ich gemessen habe! Interessanterweise gibt es den Hotfix nur für x64. Heisst das die 32bit Versionen von Windows 7 sind nicht betroffen, oder man hat sich nicht die Mühe gemacht es dort zu fixen?

Hallo, wir habe in einer Außenstelle Transparentes Caching von Windows 7 Pro/Ent. per Group Policy eingeschaltet. Danach konnten wir tagsüber hohen WAN-Traffic zum zentralen Fileserver beobachten. Der Traffic war ein- wie ausgehend gleich hoch. Ein Check auf dem Client ergab keine aktiven sichtbaren Dateitransfers (Copy Jobs etc.). Jedoch konnten wir beobachten, das Explorer.Exe den Traffic generierte und es sah so ähnlich aus wie ein Verzeichnisabgleich. Im Packet-Capture sah man viele aufeinanderfolgende Pakete mit den Dateinamen auf dem Remote-Fileserver (ähnlich Dir /s), jedoch wurden die Dateien nicht komplett übertragen, sondern man sah irgendwie nur die Dateinamen. Ferner starker Traffic auf dem C:\windows\csc Verzeichnis. Als wir die Benutzer gebeten haben alle Windows Explorer Fenster zu schließen, hörte der Traffic schlagartig auf. Das kann doch nicht der Sinn von Transparent Caching sein... Sobald also ein Windows Explorer auf dem Client geöffnet war und der Benutzer sich in einem Verzeichnis auf der Netzwerkfreigabe befand (kein kopieren!), wird dieser bidirektionale Traffic erzeugt. Wird der Explorer geschlossen hört dieser Traffic schlagartig auf. Wir haben folgende Monitoring Tools benutzt: Process Monitor für Dateizugriffe, Nirsoft SmartSniff für den Netzwerktraffic. Die Aussenstelle ist mit 2x2MBit über MPLS angebunden. Möglicherweise macht Transparent Caching irgendeinen Checksummenabgleich im Hintergrund für alles mögliche auf dem Remotefileserver, da die Aussenstelle jedoch relativ langsam angebunden ist dauert das ggf. Stunden und somit ist die Leitung ausgelastet? Bei dem Client konnten wir im Durchschnitt ca.2 GB übertragene Daten pro Tag beobachten, welche nur diesem "Abgleich" zuzuschreiben waren. Eigentlich erwarte ich vom Transparent Caching das lediglich die Datei, welche ich zum Lesen öffne lokal gecached wird und nicht im voraus zig Checksummen aller anderen möglichen Dateien, welche sich auch auf der Freigabe befinden. Aber genau so sieht es aus! Wer hat Erklärungen?

- ping -

Habe es wie beschrieben ausprobiert. id 560 und id 567 und id 562 wird jedoch auch beim Anlegen von Verzeichnissen geschrieben. Also wenn man im Explorer ein neuen Ordner anlegt. Nach wie vor klappt es also nicht nur Verzeichnislöschungen aufzuzeichnen. Auszug aus dem Ereignislog beim Anlegen eines Verzeichnisses (man achte auf die Löschen-Attribute !!): Ich wiederhole nochmal: Es wurde ein neuer Ordner angelegt, nicht gelöscht! ID: 560 Geöffnetes Objekt: Objektserver: Security Objekttyp: File Objektname: C:\Folder\Neuer Ordner Handlekennung: 608 Vorgangskennung: {0,644129} Prozesskennung: 1140 Abbilddateiname: C:\WINDOWS\explorer.exe Primärer Benutzername: user Primäre Domäne: mc1 Primäre Anmeldekennung: (0x0,0x8EE5) Clientbenutzername: - Clientdomäne: - Clientanmeldekennung: - Zugriffe: [b]LÖSCHEN [/b] SYNCHRONISIEREN Attribute lesen Rechte: - Beschränkte SID-Anzahl: 0 ID: 567 Objektzugriffsversuch: Objektserver: Security Handlekennung: 608 Objekttyp: File Prozesskennung: 1140 Abbilddateiname: C:\WINDOWS\explorer.exe Zugrifssmaske: [b]LÖSCHEN [/b]

-ping-

Hallo, ist es möglich das Objekt-Auditing so zu konigurieren, so das NUR Verzeichnislöschungen protokolliert werden? Ich habe schon sehr viel Zeit in die Lösung dieses Problem gesteckt, aber Windows hat immer auch Datei-Aktionen mitaufgezeichnet. Wenn man z.B. mit Word eine Datei speichert, wird auch ein Log-Eintrag erzeugt, da auch beim Speichern etwas mit "Delete" gesetzt wird. Hat jemand eine Idee? Bitte diese Idee auch vorher in der Praxis testen, da die eigentlich triviale Aufgabenstellung anscheinend nicht so ohne weiteres lösbar ist. Also nochmal: Nur Verzeichnislöschungen sollen aufgezeichnet werden.

Der neue RDP 7.0 Client für XP scheint nur noch das Tastaturlayout des Remoterechners zu nutzen. Deshalb gibt es dann auch ab und zu dieses \ Problem. Gibt es einen Trick um den RDP Client wieder dazu zu bewegen nur mit dem lokalen Tastaturlayout zu arbeiten? Und das am besten permanent. Also keine Regkeys auf remote Systemen setzen (IgnoreRemoteKeyboardLayout) oder Tastaturlayoutumschaltung (Alt-Shift).