olc

Hi, ein "robocopy Quelle ZIEL /L" zeigt die Dateien und Verzeichnisse an, die nicht am Ziel vorhanden sind. Es wird dabei nichts kopiert. Siehe dazu auch "robocopy /?". Viele Grüße olc

Hi carnivore, dann hilft Dir vielleicht auch ein "repadmin /showsig" bzw. "repadmin /showsig *" weiter? Viele Grüße olc

Hi, handelt es sich um 2003er Server oder spätere OS? Unter 2003 registriert der DHCP Client Dienst die Host-A Einträge, ab Vista / 2008 der DNS Client Dienst. Ggf. ist ja der Dienst auf dem Problemsystem deaktiviert worden? Ansonsten fehlt vielleicht der Haken bei "Register this connection's addresses in DNS" in den TCP/IP Einstellungen des DNS Servers. Viele Grüße olc

Hi, einmal anders gefragt: Wofür benötigt Ihr die Information? Das ganze zu exportieren sollte (ohne es getestet zu haben) spätestens mit den AD PS CMDlets ab W7 / 2008 R2 keine große Sache sein. Viele Grüße olc

Hi Gensu, genau - bis Windows Server 2008 R2 benötigst Du zur Freigabe eigener Templates eine Enterprise Version. Ab 2008 R2 kannst Du dann Templates auch in der Standard Version nutzen. Viele Grüße olc

Hi Wolfgang, schau einmal hier hinein: Event Log IDs und zugehörige Texte auslesen ? quick and dirty style - Aktives Verzeichnis Blog - Site Home - TechNet Blogs Ansonsten kannst Du Dir auch das SCOM Management Pack für DFSR herunterladen, aber aus den VBS-Dateien die Events zu exportieren ist recht aufwändig. Viele Grüße olc

Hi, es werden automatisch immer zwei Verbindungsobjekte angelegt. Also ist es wohl eher so, wie ich es oben schon vermutet hatte: Es wurde (von wem auch immer... ;) ) Verbindungsobjekte gelöscht. P.S.: Mit authoriativer "DC" Wiederherstellung meinte ich natürlich das SYSVOL (DFSR). Danke für die Ergänzung, dmetzger. :) Viele Grüße olc

Hi, so richtig verstehe ich das Problem anhand der Beschreibung nicht, aber der im Moment einzig von MS supportete Weg das DFSR SYSVOL neu anzulegen ist ein DCPROMO des DCs oder alternativ das authorative Wiederherstellen eines der DCs. Hast Du irgend etwas an den Connection Obejcts gedreht, etwa versucht "manuell" eine One-Way-Replication einzurichten? Das wäre nicht korrekt und führt zu Problemen. Welcher Virenscanner läuft auf den DCs und in welcher Version / Datum der *.exe? Ist der Scanner DFSR kompatibel? Ich habe solche Merkwürdigkeiten schon gesehen, wenn der Scanner / die Firewall / weitere Filtertreiber nicht korrekt mit DFSR zusammen arbeiten. Viele Grüße olc

Hi, häng einmal ein "-v" mit in die csvde-Kommandozeile - dann sollte das Attribut angezeigt werden, welches Probleme verursacht. Viele Grüße olc

Hi by16ht und willkommen an Board, :) aus meiner Perspektive hast Du einige Probleme mit den "unescape" Zeichen, also den Backslashes. Manchmal nimmst Du zu viele (etwa bei "CN=Mustermann\\, Max...") und manchmal zu wenige (etwa bei "\\server\TSProfiles..."). ;) Versuche es einmal anders: Exportiere Dir einen Beispielbenutzer, den Du mit allen gewünschten Eigenschaften manuell anlegst mit CSVDE und prüfe, an welcher Stelle wie viele "unescapes" genutzt werden. Das kannst Du dann für Deinen Import entsprechend übernehmen. Viele Grüße olc

Hi chris, wenn das Autoenrollment für Computer aktiviert ist (z.B. per GPO) und das Template für die DCs noch immer freigegeben ist, dann sollten die Zertifikate automatisch erneuert werden. Ohne Zusatzinformationen läßt sich das also schwer einschätzen. Wenn Ihr jedoch keine Dienste auf den DCs nutzt, die Zertifikate benötigen (etwa SmartCards, LDAP/S etc.), dann könnt Ihr auch überlegen, keine neuen DC Zertifikate auszurollen. Entfernt dazu die entsprechenden Berechtigungen auf dem DC-Template auf der CA. Viele Grüße olc

Hi zusammen, hast Du unter Umständen auch folgende Event IDs im Eventlog: 1746, 1659 und 1481? Falls ja, dann ist das beschriebene Problem laut meinen Informationen ein Fehler im Windows Server Code ohne wirklichen Workaround. Derzeit gibt es keinen Hotfix dazu, es wird jedoch soweit ich weiß von MS daran gearbeitet - bleibt also nur auf den Fix zu warten. Sollten die Event IDs nicht auftreten, ist es eher ein anderes Problem. ;) Wenn Du die Domäne nicht mehr benötigst, kannst Du diese ggf. auch "hart" mittels "metadata cleanup" entfernen - dort entfernst Du erst hart den DC und danach direkt die Domäne. Aber Vorsicht: Nach dem Entfernen gibt es keinen Weg zurück, die Child-Domäne ist dann *wirklich* weg. http://technet.microsoft.com/en-us/library/cc731035(WS.10).aspx Viele Grüße olc

Hi, die anderen Punkte des Blogs hast Du ebenfalls durchgearbeitet? Viele Grüße olc

Hi, bezüglich der Homeshare Geschichte schau einmal hier: Hallo? Hier Basisverzeichnis ... Oh, falsch verbunden ... tüt .. tüt .. tüt - Aktives Verzeichnis Blog - Site Home - TechNet Blogs Ergo: Schalte einmal testweise "Always wait for the network [...]" ein. Viele Grüße olc

Hi Norman, genau das ist einer der Kernpunkte bei der Planung von DFSR in Verbindung mit DFSN - es ist schlichtweg nicht dafür vorgesehen (DFSR)... Soll heißen: Daten einsammeln (z.B. für Backups) oder die Datenverteilung (z.B. WDS Freigaben) sind vom Design her sinnvoll für DFSR. Die gleichzeitige Arbeit an gleichen Dokumenten aber an unterschiedlichen Orten sollte im Grunde niemals stattfinden. Und auch das File Locking schützt Dich nicht vor Konflikten - wenn also eine Excel Datei während der Bearbeitung "gesperrt" ist, dann gilt das nur für den einen Server(!). Auf dem anderen Server kann gleichzeitig ebenfalls in der Exdel Datei gearbeitet werden. Das File Locking wird nicht "repliziert", es gilt ausschließlich lokal... Wenn dann die Dateien geschlossen werden, kommt es direkt zum Konflikt oder zum Überschreiben der Dateien. BTW: Das Notepad Problem hättest Du übrigens auch auf einem einzigen Share, nicht nur bei dieser Kombination. ;) Viele Grüße olc

Hi, ein Punkt ist wichtig: Editoren wie Notepad stellen keine "file locks" auf Textdateien. Damit wird bei geöffneten Schedule die Änderung an Datei1 auf Server1 direkt repliziert, auch wenn Datei1 auf Server2 gerade geöffnet ist. Speichert nun der Benutzer auf Server2 die Datei1, ist es ein komplett neuer Schreibvorgang / eine neue Änderung, egal was in der Datei1 von Server1 vorher ankam. Somit würde auch kein Konflikt entstehen - der Konflikt käme lediglich zu stande, wenn der Schedule geschlossen gewesen wäre und auf beiden Seiten Änderungen durchgeführt worden wären. Viele Grüße olc

Hi Norman, wenn es einen Konflikt gibt dann wird dieser auch ein Konfliktevent nach sich ziehen. Ohne genau das Szenario zu kennen, welches Du da beschrieben hast, läßt sich schwer mehr dazu sagen. ;) Vielleicht habt Ihr lediglich auf dem falschen Server geschaut. Ansonsten gilt: - Bei bestehenden Dateien greift das Prinzip "last writer wins". - Wenn eine neue Datei erstellt wird, gewinnt bei einem Konflikt meiner Erinnerung nach die zuerst erstellte Datei. - Ähnlich läuft es ab bei einem Ordner, der jedoch ggf. gemerged wird - je nach Szenario. Office Dateien können sich insofern von Textdateien unterscheiden, als daß z.B. Excel oder Access Dateien im geöffneten Zustand nicht repliziert werden können (file locking). Ansonsten ist es aber im Prinzip das selbe wie bei Textdateien. Viele Grüße olc

Hi, schau doch auch einmal in die "Reiseberichte" von "Deploy and Win" hinein, da bekommst Du vielleicht einige Anregungen: Microsoft - Deploy & Win In jedem Fall nützt Euch Windows 7 genau dann etwas, wenn Ihr von den neuen Funktionen gebrauch macht. Und damit meine ich nicht nur die gesteigerte Produktivität aufgrund überarbeiteter Oberflächen, sondern auch die Dienste wie Direct Access, Branch Cache usw. Der Sicherheitsfaktor ist definitiv auch ein Thema - ab Vista hat sich da eine Menge getan. Außerdem integrieren sich die neuen Systeme besser in das Produktportfolio von MS. Dazu müssen dann aber natürlich auch die angrenzenden Dienste aktualisiert werden. Viele Grüße olc

Hi, mh, wo genau möchtest Du jetzt genau einen Fehler einbauen, bei einer Kommandozeile mit vorgegebenen Beispiel und 3 Parametern? dsadd group <GroupDN> -samid<SAMName> -secgrp {yes|no} -scope {l|g|u} Viel mehr als: dsadd group CN=meineGruppe,OU=meineOU,DC=meineDomain,DC=tld -samid meineGruppe -secgrp yes -scope g wird dabei wohl nicht heraus kommen oder? ;) Wobei ich den "sAMAccountName" (samid) nicht manuell vergeben würde, sondern über den CN (also die Agabe des DN) regeln würde, um Differenzen zu vermeiden: dsadd group CN=meineGruppe,OU=meineOU,DC=meineDomain,DC=tld -secgrp yes -scope g Warum testest Du das nicht einfach? Sag jetzt bitte nicht, Du hättest keine Testumgebung... ;) Viele Grüße olc

...es gibt sogar ein "dsadd group /?". ;) Schau auch einmal auf folgender Technet Seite, die die Suchmaschine meiner Wahl als ersten Link ausspuckte: Dsadd group Im Kern also das, was Du oben selbst geschrieben hast... Viele Grüße olc

Hi einstein, ja - vermutlich jagst Du einem Phantom nach. :) a) Im RSOP werden die FGPPs nicht angezeigt - dort landet nur die Passwortrichtlinie auf Domänenebene. Daher das "dsget" Kommando mit "-effectivepso". b) Der Dialog hat sich (leider) nicht verändert, selbst wenn FGPPs angewendet werden. D.h. es werden noch Anforderungen angezeigt, die auf Domänenebene verlinkt sind. Die FGPPs erzeugen keinen anderen Dialog. Daher solltst Du ausschließlich prüfen, ob (zum Beispiel bei einer Angabe von mindestens 10 Zeichen für ein Kennwort in der angewendeten FGPP) der Benutzer weniger als 10 Zeichen angeben kann. Ich denke, daß dies nicht der Fall sein wird - also die FGPPs greifen. Viele Grüße olc

Hi Martin, ja, das ist korrekt. Neue DCs nutzen den "alten" Verzeichnisnamen. In der DFS®-Manegement Konsole solltest Du in den Replikationsgruppen unter "Sysvol" den neuen DC auch sehen. Meintest Du das mit "Replikationsgruppe des DFS" Viele Grüße olc

Hi einstein, noch mal ganz langsam: Überprüfst Du die Kennwortrichtlinie etwa mittels RSOP anstatt direkt den Benutzer das Kennwort ändern zu lassen? Da es sich bei den FGPP nicht um GPOs handelt, werden diese auch nicht im RSOP angezeigt. Also schau noch einmal auf meine letzten Fragen, bevor wir hier überhaupt weiter raten. Ganz speziell meine Frage von oben: "...der Benutzer selbst führt die Kennwortänderung durch und nicht der Administrator in AD Users&Computers?" Der Domain NC Export ist nicht allzu wichtig, im Moment von daher mußt Du Dich nicht weiter darum bemühen... P.S.: BTW: RSOP.MSC ist nicht mehr aktuell und sollte nicht mehr genutzt werden. Schau Dir auf 2008 R2 / W7 Systemen einmal "gpresult /h report.html" an. Viele Grüße olc

Hi, wenn Du die Updates per WSUS verteilst, sollte das Deaktivieren der Funktion auf dem Client meines Wissens keine Probleme bereiten. Die Updates sollten dann weiterhin am Client ankommen. Viele Grüße olc

Auch ich bin schockiert und schließe mich meinen Vorrednern an: Mein herzliches Beileid.