olc

Hi, damit sind die Group Policy Preference CSEs gemeint, die Du benötigst, um die oben von Dir genannten Einstellungen überhaupt anwenden zu können. :) Download details: Group Policy Preference Client Side Extensions for Windows Vista (KB943729) Die oben genannte Einstellung klingt mir nicht zu exotisch, also würde ich schon vermuten, daß sie in den Office ADMX Dateien vorhanden ist. Schau einmal hier hinein: Download details: 2007 Office system Administrative Template files (ADM, ADMX, ADML) and Office Customization Tool version 2.0 Viele Grüße olc

Hi, Du findest die Einträge im Normalfall in Deiner DNS Zone für die Domäne. Ist es eine deutsche Installation, müßte es soetwas wie "identisch mit übergeordneter Zone" o.ä. heißen. Die Einträge mußt Du dort entfernen. Zusätzlich müssen wahrscheinlich die Schritte aus dem KB-Artikel durchgeführt werden, da offensichtlich noch ein paar andere Dinge nicht ganz sauber sind. ;) Viele Grüße olc

Hi, scheinbar ist mindestens ein falscher Eintrag für die Domäne in der Zone registriert: 169.254.170.14 . Den Eintrag 192.168.10.253 müßtest Du zuordnen, wenn es kein valider DNS Server ist, dann ist dieser Eintrag auch falsch. Du müßtest also diese Einträge entfernen. Zusätzlich schau noch einmal in den oben verlinkten KB-Artikel - er zeigt Dir die Aktionen, die auf dem DNS Server auszuführen sind, um die Fehler zu beheben. Beides zusammen sollte dann hoffentlich die Probleme beseitigen. :) Viele Grüße olc

Hi, wie gesagt, führe einmal ein nslookup auf dem Client aus. Die in diesem Bereich aufgeführten Aktionen solltest Du ggf. durchführen. Siehe dazu auch: How to troubleshoot 7062 errors logged in DNS event log . Viele Grüße olc

Hi, nach einem Lizenzproblem sieht es für mich erst einmal nicht aus - zumindest würde ich von einer anderen Fehlermeldung ausgehen. Poste doch bitte noch ein "nslookup baumaschinenservice.lokal", ausgeführt auf dem betroffenen Client. Interessant wäre hier, ob Du eine saubere Rückmeldung für die Domäne erhältst. Viele Grüße olc

Hi, am besten Du verwendest "PsExec" von Sysinternals, um Dich auf der CMD in den Systemkontext zu bringen: C:\> psexec \\localhost -s cmd Nun stoppst Du den DFSR Dienst: C:\> net stop dfsr Danach navigierst Du in das Verzeichnis C:\System Volume Information\DFSR und benennst das Datenbankverzeichnis um. Danach startest Du den DFSR Dienst neu. Es findet dann automatisch eine nicht autorative Wiederherstellung des DFSR Volumes statt, Du mußt im Normalfall nichts mehr tun, sondern nur die Initialreplikation abwarten. Sollte es dann wider erwarten doch Probleme geben (kann einige Zeit dauern, bis der Vorgang abgeschlossen ist, also keine "Eile"), dann melde Dich einfach. :) Viele Grüße olc

Moin, ok, dann ist erstere Vermutung von mir nicht relevant. Versuche einmal, wie oben angesprochen, die defekte Datenbank auf Laufwerk C: zu löschen (das mußt Du im SYSTEM Kontext tun). Auf jeden Fall mußt Du dabei im Hinterkopf behalten, daß dann für alle Replikationsgruppen dieses Volumes eine nicht autorative Initialreplikation durchgeführt wird. Sind auf C: also noch mehr DFSR replizierte Daten vorhanden, gilt das für diese ebenso. Wie immer macht also ein Backup vor den Aktionen Sinn. ;) Viel Erfolg. :) Gruß olc

...stimmt auffällig. ;) Viele Grüße olc

Hi, wenn Du versuchst der Domäne beizutreten, verwendest Du im entsprechenden Dialog den NetBIOS Namen der Domäne oder den DNS-Namen? Versuch einmal genau das Gegenteil von dem, wie Du es vorher gemacht hast, also etwa "BAUMASCHINENSERVICE" oder "BAUMASCHINENSERVICE.lokal". Viele Grüße olc

Hi, anbei noch die Links zu den CSEs: Download details: Group Policy Preference Client Side Extensions for Windows Vista (KB943729) Download details: Group Policy Preference Client Side Extensions for Windows XP (KB943729) Viele Grüße olc

Hi, die Images ziehst Du aber, wenn beide DCs gleichzeitig offline sind und würdest diese auch in der Form wiederherstellen oder? Alles andere wäre nicht gut. ;) Verschiebe die entsprechenden Verzeichnisse wieder in die korrekte Struktur innerhalb es SYSVOLs und starte den NETLOGON Dienst neu, das sollte klappen. Warum es nun zu diesem Fehler gekommen ist, ist anhand der Angaben sicher nicht so leicht herauszufinden. Viele Grüße olc

Hi, entschuldige, ist nicht böse gemeint - aber das ist doch ein rein theoretische Diskussion ohne wirkliches Ziel: Du kannst naturgemäß kein Domänen-Konto wieder freischalten, wenn die Domäne für den Client nicht verfügbar ist. Trotzdem möchtest Du eine 24h Sperrung des Kontos, was meines Erachtens auch nicht zielführend ist - beides Zusammen kann also nicht funktionieren. Mit rein technischen Mitteln ist "Sicherheit" nicht zu erreichen, d.h. das Sperren eines Kontos nach 5 Versuchen für 24h ist schlichtweg in den allermeisten Umgebungen weder sinnvoll noch erhöht es tatsächlich das Sicherheitslevel der Umgebung. Worüber sprechen wir hier also? :) Deine Probleme sind in dem Moment behoben, indem Du die 24h Sperrung auf 30 Minuten o.ä. zurückstellst. Viele Grüße olc

Hi ibicis, schaue einmal hier hinein: WMI Isn't Working! D.h. heißt im Umkehrschluß, daß die Fehlermeldung nicht mehr auftritt, wenn Du den Client aus dem Wirkungsbereich der GPO entfernst (etwa über Sicherheitsfilterung)? Ggf. könntest Du einmal ein WBEM Log erzeugen, um auf Fehler zu prüfen: Logging WMI Activity (Windows) Als Test würde ich vielleicht auch noch einmal die GPP CSEs drüberbügeln, vielleicht wird das Problem ja bei einer erneuten Installation der CSEs behoben. BTW: Um welche Einstellung handelt es sich denn konkret, die nicht in den ADM / ADMX Dateien vorhanden ist? Viele Grüße olc

Hi, was für einen Test führst Du denn durch? Liegt ggf. der entsprechende Client oder Benutzer nicht in der korrekten OU? Welche Berechtigungen hast Du gesetzt? Nutzt Du die GPMC zur Bearbeitung der GPOs? Nach Möglichkeit beschreibe bitte noch einmal etwas genauer, was Du genau konfiguriert hast. Sonst wird es schwer mit dem Helfen. Viele Grüße olc

Hi, die Firewall auf Client und Server wurde wie oben angesprochen testweise deaktiviert (egal ob nun Windows Firewall oder Symantec)? Kann man den Server vom Client aus pingen? Viele Grüße olc

Hi, ggf. kannst Du die SRV Einträge manuell anlegen: Volume Activation 2.0 Deployment Guide Wurden dynamische Updates in der DNS Zone deaktiviert oder an den ACLs der DNS Zone herumgeschraubt? Viele Grüße olc

Hallo, ehrlich gesagt finde ich es ein wenig durcheinander, was Du schreibst (nicht böse gemeint :)). Vielleicht fangen wir noch einmal etwas strukturierter an: 1. Stell den primären DNS Eintrag auf dem 2008er DC auf den SBS, am besten entfernst Du für den Moment alle anderen Einträge. Bitte dabei auch unbedingt IPv6 beachten, das ist bei 2008 standardmäßig aktiv und zeigt ebenfalls auch sich selbst, wenn Du es nicht verändert hast. 2. Danach startest Du den 2008er DC am besten einmal neu und wartest vielleicht eine Stunde nach dem Bootvorgang. 3. Dann prüfst Du die Ereignisprotokolle und ggf. die Replikation zwischen den DCs (etwa mittels Repadmin). Wenn es dann immer noch Probleme gibt, melde Dich noch einmal mit entsprechend genauer Fehlerbeschreibung mit Event IDs und ggf. Repadmin Exporten. :) Viele Grüße olc

Hi, zusätzlich teste doch einmal, den primären DNS Server Eintrag auf dem zusätzlichen DC nicht auf sich selbst, sondern auf den SBS zeigen zu lassen. Klappt es dann? Wenn beim DCPROMO des 2008er DCs der primäre Eintrag schon auf sich selbst gesetzt wurde, läufst Du hier sonst in ein "logisches" Problem - von welchem DC soll sich der neue DC die erforderlichen AD-Daten holen, wenn in seiner DNS Zone noch keine SRV Daten (des anderen DCs) stehen? Viele Grüße olc

Hi ibicis und willkommen an Board, :) unter Umständen ist der WMI Provider beschädigt - vielleicht kannst Du einmal in den Eventlogs schauen, ob Du noch andere Fehlermeldungen in diese Richtung findest? Ggf. kann man die WMI Namepsaces / Provider neu aufbauen, aber das sollte immer erst der "letzte Schritt" sein, wenn man keine andere Lösung findet. BTW: Wie genau wendet Du den Registry Eintrag an? Manuell per Startup Script oder GPP? Falls ja, wären vielleicht die Office ADM / ADMX Templates eine gute Alternative (würde sicher nicht die Fehlermeldung in den Eventlogs beseitigen, äre aber grunsätzlich "sauberer")? Viele Grüße olc

Hallo svo, offensichtlich wurde eine Wiederherstellung von FRS gefahren oder es wurden Konflikte bei der Replikation (etwa duch Löschen von Daten und dem Wiederherstellen) hervorgerufen. Ich würde vermuten, daß da auf einem der DCs der Umgebung doch etwas mehr gelaufen ist, als nur eine Sicherung anzulegen. Oder die Backup Applikation machte Probleme. Welche Backup Software hast Du im Einsatz? Wie ist der aktuelle Status? Gibt es konkrete Probleme oder ist das SYSVOL nun wieder korrekt aufgebaut und freigegeben? Viele Grüße olc

Hallo, beim Austauschen von Festplatten eines Systems werden die GUIDs der Platte geändert. Da DFSR mit der Datenbank dieses Volumes / der Volumes dieser Platte fest verdrahtet ist, wird im Normalfall eine Initialreplikation nach einem Datenbank Rebuilt ausgeführt werden. Wenn Du aber die beiden Platten sozusagen "parallel" ausgetauscht hast, läufst Du in ein "Henne / Ei" Problem - denn es ist kein autorisierender Partner vorhanden, von dem die SYSVOL Daten gezogen werden könnten. Zumindest wäre das meine Vermutung, warum es zu dem Problem gekommen sein könnte. Vielleicht versuchst Du es einmal mit einer autorativen Wiederherstellung des SYSVOL mittels WBADMIN? Wenn der Fehler nur auf einem System geloggt wird, könntest Du die DFSR Datenbank auf diesem System unterhalb von "C:\System Volume Information\DFSR" löschen, um damit noch einmal die Initialreplikation auszulösen. Der Partner ist dabei dann nicht autorativ, d.h. die Änderungen im SYSVOL auf diesem DC werden dann von dem anderen DC überschrieben. Viele Grüße olc

...womit jedoch nicht die Erstellung der Benutzer erledigt wird. Der TO hatte deshalb auch geschrieben, daß das Hinzufügen der Benutzer nach der Erstellung in die entsprechenden Gruppen kein Problem darstellt. Ich gehe davon aus, daß damit eingeschränkte Gruppen gemeint waren. Viele Grüße olc

Hi, schau Dir einmal die Group Policy Preferences an: Manage Registry, Passwords, Printers, More with Group Policy Preferences Beachte beim Thema "Benutzer anlegen" / Kennwort ändern jedoch den folgenden Hinweis: Group Policy Team Blog : Passwords in Group Policy Preferences (updated) Ansonsten tut es auch eine simple Batchdatei mit dem Befehl "net user /add" als Startup Script für die Computer. Das Kennwortproblem bleibt dabei jedoch das selbe. Viele Grüße olc

Hallo und willkommen an Board, :) hast Du denn schon ein Scriptbeispiel, an dem wir ansetzen können? Ein komplettes Script wird hier wahrscheinlich niemand schreiben, dafür bezahlt man sonst meist Dienstleister. ;) Viele Grüße olc

Hi Sebastian, soweit ich mich erinnere, sollte das kein Problem darstellen. In jedem Subnetz gibt es einen Masterbrowser, der diese Rolle übernimmt. Dieser ändert sich dann von Zeit zu Zeit, wenn der aktuelle Masterbrowser nicht erreichbar ist. Du kannst das Übernehmen der Masterbrowserrolle theoretisch deaktivieren - die Frage ist jedoch, warum Du das überhaupt tun solltest? Hast Du denn irgendwelche Probleme? MS Windows NT Browser Viele Grüße olc