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).

Ich konnte es an mehreren Rechnern mit XP SP3 und IE6 nachstellen. Vielleicht ist bei Dir Ordneransicht für FTP nicht aktiviert. Oder IE7?

Tja, das ist auch die normale Vorgehensweise. Aber was um aller Welt hat Microsoft da verbrochen? Hier ein VMWare Workstation Screen Capture von dem ganzen Spuk: http://www.sendspace.com/file/skeczw

Hallo, mir ist folgende "Anomalie" im Internet Explorer aufgefallen: Eine direkte FTP-Verbindung zu einem FTP-Server soll mittels IE 6.0 soll aufgebaut werden. Ich gebe also in der Adressleite ein (Beispiel): ftp://ftp.server.com Achtung, jetzt wird es komisch: Gebe ich den abschließenden / ein (ohne mit Return zu bestätigen!!!), baut der IE6 Browser schon mit dem User "anonymous" ohne Passwort eine FTP Verbindung auf.... Dies kann mit Netzwerksniffern überprüft werden. Wie kommt er auf die Idee die Verbindung schon zu initiieren, ohne das ich mit Return ausgelöst habe?... :confused: Lösche ich den / aus der Zeile und gebe ihn dann erneut ein, wird wieder die Verbindung mit anonymous aufgebaut... Wird dann mit Return bestätigt, werden weitere 2 anonymous Anmeldungen gesendet... Wieso 2 Anon-Anmeldungen? Ich habe doch nur einmal Return gedrückt.... Muss man alles nicht verstehen, oder? Ein automatisches Auslösen passiert auch, wenn man die Adress Zeile dann weiter editiert und Username:Passwort@ hinzufügt. Auch hier wird wieder automatisch ausgelöst (nach dem @), obwohl vom Benutzer nicht mit Return bestätigt wurde. Und es wird noch komischer: Editiert man nun nur das Passwort in der FTP-Adresszeile, dann wird für jeden zweiten Tastenanschlag im Passwort die Anmeldung zum FTP Server gesendet. FTP Server die nach einer bestimmten Anzahl von Fehlversuchen den User sperren machen dann dem Servicedesk besonders Freude! Das ist so abartig, das ihr es einfach selber mal mit einem Sniffer testen müsst! Kann man dieses "merkwürdige" Verhalten irgendwo abschalten, so das sich der IE wie alle sonst üblichen Browser verhält und die FTP Anfragen erst dann sendet, wenn der User mit Return die Adresszeile bestätigt? Update: Wenn "Ordneransicht für FTP-Sites aktivieren" nicht aktiviert ist, dann ist dieses Verhalten nicht zu beobachten. Hat jemand trotzdem eine Erklärung hierfür?

Habe ein ähnliches Problem: 10:20:45 Änderungen im Ordner "Posteingang" auf dem Server werden synchronisiert 10:20:45 Download von Server "meinserver.domain.com" 10:20:45 Fehler bei der Synchronisierung des Ordners. 10:20:45 [80040119-501-80040119-560] 10:20:45 Ein Client-Vorgang ist fehlgeschlagen. Die Synchronisation findet jedoch korrekt statt. Es stören bloss die Einträge unter "Synchronisierungsprobleme". Exakt jede halbe Stunde kommt diese Meldung in den Sync-Probleme Ordner. Ich möchte auf den Cached Mode nicht verzichten. Ferner habe ich auch schon das komplette Outlook 2007 Profil vom Client gelöscht inklusive der .OST-Datei. Alles neu angelegt und der Fehler kommt wieder. Recherchen im Internet führten alle zu der "Lösung" das Profil und OST zu löschen, was aber in meinem Fall keine Wirkung zeigt.

Hallo, auf der Seite: Lohnspiegel.de - Geld verdienen, Lohn und GehaltUmfrage kann mann einen einen anonymen Gehaltscheck durchführen lassen. Wäre super, wenn viele sich beteiligen, damit der Check entsprechend genauer wird. Mann muss keinerlei persönliche Daten hinterlegen und es wird auch keine Mail-Adresse abgefragt. Die Auswertung kommt sofort nach dem Ausfüllen des Fragebogens. Super Sache!

Hallo, an alle die in größeren Firmen arbeiten: Wie groß setzt Ihr die Quota für die Home-Verzeichnisse? Es wäre auch interessant zu wissen wieviel Homeverzeichnisse insgesamt auf dem Server sind und welcher Plattenplatz dafür reserviert wurde. Brauche ein paar Argumente das 5 GB pro User doch etwas viel ist bei ca. 700 Benutzern :D

Hallo, ich habe testweise mal auf unsere Admin-PC-OU folgende Gruppenrichtlinie gebunden: "Auf diesen Computer vom Netzwerk aus zugreifen" -> Domänen Admins Also nur Benutzer die Domänen Admins sind können Shares auf unseren PC's sehen und nutzen. Die Policy hat aber einen unvorhergesehenen Nebeneffekt: Remotedesktopverbindungen zu unseren Servern funktionieren nun nicht mehr von den Admin PC's aus. Es kommt eine Fehlermeldung das die Verbindung nicht hergestellt werden kann. Nochmal zum Klarstellung: Die Policy ist auf den Admin-Stations aktiv und NICHT auf den Servern... Ich habe die Policy von den Admin Stations wieder entfernt und gpupdate /force gemacht. Prompt ging es wieder. Die einzige Erklärung die wir haben ist, das die RDP Verbindung wieder eine Rückverbindung zum Client PC initiiert (IPSEC Handshaking) und das dies durch die lokale Policy fehlschlägt und somit die Verbindung nicht weiter aufgebaut wird. Hat einer von Euch eine Idee wie man das Problem beseitigt, oder mit welchen Credentials diese Rückverbindung erfolgt? Dann würde man nämlich einfach die Credentials mit in die Policy packen und dann sollte es gehen. Update: Konnte das Problem nun einkreisen und es hat auch damit zu tun das IPSEC auf den Admin Stations eingeschaltet ist (client only).

Hallo, es geht mal wieder ans eingemachte... Ist es möglich unter Windows Server 2003 die Länge von Pfadnamen künstlich zu beschränken. Also z.B. anstatt 255 Zeichen nur 230 Zeichen z.B.? Das ganz soll auch so wirksam sein, das Clients die sich ein Share von dem Server gemappt haben auch nicht lange Dateinamen (länger als 230 Zeichen) anlegen können. Hintergrund: VMWare VCB. VCB kann die Laufwerke eines laufenden Servers in einen Mountpunkt einhägen um somit Dateien LAN-Free zu sichern. Durch das Einhängen des Laufwerks wird der Pfad verlängert, was zur Folge hat das Dateien die tief im Fileserverbaum hängen zwar noch sichtbar sind, aber nicht mehr geöffnet werden können (auf dem VCP Proxy). Somit ist auch die Sicherung dieser Dateien über VCB nicht möglich. Scheint sich noch keiner von VMWare so gross Gedanken darüber gemacht zu haben. Aber dafür gibt es ja uns :p Wie siehts aus? Vorschläge?

Ja, das ist mir auch schon aufgefallen. Ich denke da hat jemand bei MS geschlafen. Es macht absolut keinen Sinn, das die lokale "Druck-Operatoren" Gruppe nicht in die ACL eines Druckers per Standard eingetragen wird (auf Mitgliedsservern). Die "Druck-Operatoren" dürfen noch nicht einmal den Druckdienst neu starten, geschweige denn einen neuen lokalen Druckerport erstellen.... Diese Links helfen etwas: http://www.jsifaq.com/SF/Tips/Tip.aspx?id=0202 kb259574 Start/Stop von Diensten für bestimmte Gruppen Ich denke es bleibt einem nichts anderes übrig als die Hauptbenutzer Gruppe zu nutzen :cry:

Hmm... aber laut dem Microsoft KB Artikel soll der DnsAvoidRegisterRecords Regkey genau das verhindern. Und das tut er auch. Habe es gerade getestet. Ich habe einen der Satelliten-DCs (die diesen Regkey gesetzt haben) neugestartet und die ungewollten DNS Records sind wie gewünscht nicht aufgetaucht. Ist doch genau das was wir wollen, oder? :cool: Microsoft nennt diese Records: "generic (non-site-specific) domain controller locator DNS records"