willy-goergen 0 Geschrieben 19. Januar 2015 Melden Teilen Geschrieben 19. Januar 2015 (bearbeitet) Ich habe die Tage glaube ich einen kleinen Bock geschossen, als ich die Struktur meines AD angepasst habe. Der Anpassung gingen einigen Überlegungen voraus, wie ich den Betrieb in einer für mich leicht überschaubaren Struktur im AD verwalten kann. Mit dem Ergebnis bin ich auch recht zufrieden. Für mich passt das auch sehr gut und ich denke, dass ich damit eine gute Grundlage habe. Wen es interessiert, für den ist im Anhang die Aufteilung. Das Aber dabei ist, dass ich im Zug der Umstrukturierung auch einige GPOs gelöscht habe, die nun als verwaiste Einträge im "SYSVOL" meine beiden Domaincontroller auftauchen. Es gibt bei den Policy-Leichen keinerlei Bezug mehr zur GPMC oder zum ADSI. Die Dinger hängen da mehr oder weniger nur noch in den Policies herum und ich kann sie nicht mehr löschen. Ich kann die beiden betreffenden Policies nicht löschen, weil die DCs der Meinung sind, ich hätte kein Zugriffsrecht. Als Besitzer der Ordner bin ich nicht eingetragen. Das ist niemand. Wenn ich probiere, Besitz von den Ordnern zu ergreifen, bekomme ich immer wieder die Antwort, dass ich dazu nicht berechtigt wäre, obwohl ich schon mit höchsten Privilegien rangegangen bin. Habt ihr eine Idee, wie ich das wieder wegbekommen kann? Die GPOs werden nicht mehr angwendet und werden von den Clients aus unbekanntem Grund gefiltert. So ganz wohl ist mir dabei aber nicht. Ich hätte die beiden Ordner gerne weg aus dem SYSVOL. bearbeitet 19. Januar 2015 von willy-goergen Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 19. Januar 2015 Melden Teilen Geschrieben 19. Januar 2015 Ich bin mir nicht sicher, was Du meinst. Nicht mehr benötigte GPOs können in der GPMC gelöscht werden. Zitieren Link zu diesem Kommentar
willy-goergen 0 Geschrieben 19. Januar 2015 Autor Melden Teilen Geschrieben 19. Januar 2015 (bearbeitet) Das dachte ich auch. Die GPOs sind im GPMC aber nicht mehr vorhanden. Wenn ich den ADSI-Editor benutze, sind sie das auch nicht. Tatsächlich sind die beiden GPOs aber noch in der SYSVOL bei den Policies vorhanden und ich bekomme sie nicht weg. Denke ich zumindest. An der Zahl habe ich aktuell 13 GPOs. Im SYSVOL befinden sich aber fünfzehn. Mir wäre es nicht aufgefallen, wenn ich nicht mal in das Ergebnis von gpresult auf (m)einem Client geschaut hätte. Das ist fehlerhaft. Ich vermute dass das mit meiner Umstrukturierung zusammenhängt und dass da irgendwas schief gelaufen ist. Bei Bedarf kann ich gerne mal ausführlichere Ergebnisse anhängen. Ich hätte jetzt gehofft, dass vielleicht jemand auf Anhieb weiß, was ich verkehrt gemacht haben könnte, bzw. was da verkehrt gelaufen ist. bearbeitet 19. Januar 2015 von willy-goergen Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 19. Januar 2015 Melden Teilen Geschrieben 19. Januar 2015 Lass die Ordner liegen. Die stören niemanden. Zitieren Link zu diesem Kommentar
willy-goergen 0 Geschrieben 19. Januar 2015 Autor Melden Teilen Geschrieben 19. Januar 2015 (bearbeitet) Bist du dir da sicher, dass ich das ignorieren kann? Ich war mir nicht so sicher, ob das nicht noch Folgen nach sich zieht. Interessanterweise wird die fehlerhafte GPO nur auf meine OU (EDV) angewandt, bzw aus unbekannten Gründen ignoriert. Die darunter liegende OU (Testmaschinen) ist nicht davon betroffen. Irgendwo fand ich das komisch und wollte mal fragen, was ihr davon haltet Die Diagnose der DCs liefert mir ebenfalls einen Fehler. Zumindest hat sie vorhin darauf hingedeutet, dass zumindest einer der beiden einen Fehler hat. Clients die vom "guten" DC die GPO ziehen, sind ok. Clients die vom Backup-DC ziehen, bringen den Fehler. Die Verzeichnisse sind aber im SYSVOL auf beiden DCs vorhanden. Ich werde da irgendwie grad nicht draus schlau... bearbeitet 19. Januar 2015 von willy-goergen Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 19. Januar 2015 Melden Teilen Geschrieben 19. Januar 2015 Ok, ich denke nicht, dass ich verstanden habe, wo Dein Problem liegt. Die Ordner im Sysvol sollten Dir zunächst egal sein. Oder hast Du dort schon was manuell gelöscht? Beschreibe doch bitte nochmal Dein eigentliches Problem. Mit Deinem Bild kann ich im Übrigen nichts anfangen. Welches Problem wird dort illustriert? Zitieren Link zu diesem Kommentar
daabm 1.366 Geschrieben 19. Januar 2015 Melden Teilen Geschrieben 19. Januar 2015 ...und wenn Du schon schreibst, dass GPResult auf den Clients fehlerhaft sei: "Fehlerhaft" ist eine echt detaillierte Fehlerbeschreibung... :thumb2: Zitieren Link zu diesem Kommentar
willy-goergen 0 Geschrieben 19. Januar 2015 Autor Melden Teilen Geschrieben 19. Januar 2015 (bearbeitet) Das eigentliche Problem ist (im Moment) mein Rechner. Folgende herausgefilterte Gruppenrichtlinien werden nicht angewendet. ---------------------------------------------------------------------- Windows 7 SP1 User Verwal Filterung: Nicht angewendet (Unbekannte Ursache) Die GPO gibt es nicht. Die beiden DCDIAGs auf den Domaincontrollern liefen grade ohne Probleme durch. Das hat vor ein paar Stunden noch anders ausgesehen. Vielleicht sollte ich das wirklich ignorieren... ...und wenn Du schon schreibst, dass GPResult auf den Clients fehlerhaft sei: "Fehlerhaft" ist eine echt detaillierte Fehlerbeschreibung... :thumb2: Dann beschreibe bitte konkret, was dir fehlt. :thumb2: bearbeitet 19. Januar 2015 von willy-goergen Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 19. Januar 2015 Melden Teilen Geschrieben 19. Januar 2015 Gib mal gpresult /R ein und poste hier den ganzen Inhalt. Zitieren Link zu diesem Kommentar
willy-goergen 0 Geschrieben 19. Januar 2015 Autor Melden Teilen Geschrieben 19. Januar 2015 Gib mal gpresult /R ein und poste hier den ganzen Inhalt. C:\Users\***m>gpresult /r Betriebssystem Microsoft (R) Windows (R) Gruppenrichtlinienergebnis-Tool v2.0 Copyright (C) Microsoft Corp. 1981-2001 Am 19.01.2015, um 20:34:38 erstellt RSOP-Daten für DOMÄNE\user auf EDV02: Protokollmodus ----------------------------------------------------------- Betriebssystemkonfiguration: Mitglied der Domäne/Arbeitsgruppe Betriebssystemversion: 6.1.7601 Standortname: Nicht zutreffend Zwischengespeichertes Profil:\\***\***\Profile\180\.V2 Lokales Profil: C:\Users\*** Langsame Verbindung? Nein BENUTZEREINSTELLUNGEN ---------------------- CN=***,OU=EDV,OU=Benutzer,DC=***,DC=local Letzte Gruppenrichtlinienanwendung: 19.01.2015, um 20:24:28 Gruppenrichtlinieanwendung von: ***.***.local Schwellenwert für langsame Verbindung:500 kbps Domänenname: *** Domänentyp: Windows 2000 Angewendete Gruppenrichtlinienobjekte -------------------------------------- Windows 7 SP1 User GPO (EDV) Default Domain Policy Folgende herausgefilterte Gruppenrichtlinien werden nicht angewendet. ---------------------------------------------------------------------- Windows 7 SP1 User Verwal Filterung: Nicht angewendet (Unbekannte Ursache) Richtlinien der lokalen Gruppe Filterung: Nicht angewendet (Leer) Der Benutzer ist Mitglied der folgenden Sicherheitsgruppen ---------------------------------------------------------- Domänen-Benutzer Jeder Remoteunterstützungsanbieter Remotedesktopbenutzer Benutzer INTERAKTIV KONSOLENANMELDUNG Authentifizierte Benutzer Diese Organisation LOKAL Mittlere Verbindlichkeitsstufe Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 19. Januar 2015 Melden Teilen Geschrieben 19. Januar 2015 Es gibt übrigens ein eigenes Eventlog für Gruppenrichtlinien. Sieh doch dort mal nach Fehlern. Du kannst auf deinem Client die GPOs vollständig zurücksetzen: http://www.mcseboard.de/topic/182638-local-group-policy-auf-urzustand-zur%C3%BCcksetzen/ Zusätzlich in der Registry noch alles löschen: HKEY_LOCAL_MACHINE\Software\Policies und HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies sowie natürlich im User Bereich. Anschließend gpupdate /force und neu starten. Zitieren Link zu diesem Kommentar
willy-goergen 0 Geschrieben 19. Januar 2015 Autor Melden Teilen Geschrieben 19. Januar 2015 Zusätzlich in der Registry noch alles löschen: HKEY_LOCAL_MACHINE\Software\Policies und HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies sowie natürlich im User Bereich. Anschließend gpupdate /force und neu starten. Fehler hab ich keine gesehen. In Registry würde ich aber auch mal bohren. Habe es die Tage erleben dürfen, als ich auf einem Client mein servergespeichertes Benutzerprofil gelöscht habe. Das hat mir der Rechner richtig übel genommen. Zitieren Link zu diesem Kommentar
Sunny61 807 Geschrieben 19. Januar 2015 Melden Teilen Geschrieben 19. Januar 2015 Wenn der Rechner eh schon Probleme hat, mach ihn neu. Ist die sauberste Angelegenheit. Und immer wieder sehr 'bereinigend'. ;) Zitieren Link zu diesem Kommentar
carnivore 10 Geschrieben 19. Januar 2015 Melden Teilen Geschrieben 19. Januar 2015 Bist du dir da sicher, dass ich das ignorieren kann? Ich war mir nicht so sicher, ob das nicht noch Folgen nach sich zieht. Die Diagnose der DCs liefert mir ebenfalls einen Fehler. Zumindest hat sie vorhin darauf hingedeutet, dass zumindest einer der beiden einen Fehler hat. Clients die vom "guten" DC die GPO ziehen, sind ok. Clients die vom Backup-DC ziehen, bringen den Fehler. Hi, Vergleich doch mal die Größe der PolicyOrdner im Sysvolordner auf deinen DCs, sowie die Policyversionen in der jeweiligen GPT.ini Die File-Versionen vergleich noch mit der Version im AD mit ADSIEdit oder LDP.exe: "CN=Policies,CN=System,DC=<domain>" -> deine Policy -> VersionNumber Wenn es Unterschiede gibt, machst du am einfachsten eine Neuinitialisierung der Filereplikation mit D2 von deinem guten DC aus. http://support.microsoft.com/kb/290762/de Bei nur 2 DCs ist es relativ egal, ob D2 oder D4 Gruß carnivore Zitieren Link zu diesem Kommentar
willy-goergen 0 Geschrieben 20. Januar 2015 Autor Melden Teilen Geschrieben 20. Januar 2015 (bearbeitet) Ich kann ein bisschen Licht in das Dunkel von gestern bringen, auch wenn das jetzt für mich nicht besonders rühmlich ist. - Ich habe die Größe der SYSVOL Ordner auf den beiden DCs verglichen. Die sind absolut identisch. - Mein erster Fehler, den ich gestern gemacht habe, geschah beim Aufruf von "DCDIAG". Die fehlerhafte Ausgabe habe ich bekommen, weil ich DCDIAG in einer Kommandozeile ohne Administratorrechte gestartet habe. - Mein zweiter Fehler war in den SYSVOL-Ordner am DC über die Netzwerkfreigabe zu gehen, um zu probieren die beiden Policies ohne Bezug zu irgendwas (ausgehend von der GUID) und auf die keiner Zugreifen kann, zu löschen. Auf dem normalen Weg über das Windows-Verzeichnis ging das, auch wenn ich mich vorher als Besitzer eintragen musste. Die beiden Policies habe ich vor dem Löschen sicherheitshalber gesichert. Es scheint also mit meinen DCs alles i.O. zu sein. Ich denke mal, dass mein Dienstrechner aus irgendeinem Grund eine alte Policy drin hat, die allerdings herausgefiltert wird und eigentlich nicht mehr existiert. Bei der stichprobenartigen Überprüfung an Rechnern in der Firma, zu denen ich heute kommen musste, ist mir diese Unregelmäßigkeit nicht aufgefallen. So ganz schlau werde ich aber immer noch nicht draus. Ich schau mir auf jeden Fall mal die Eventlogs auf meinem Rechner an, nachdem das eingegrenzt ist. Im Zweifel denke ich aber auch gerade denke, ich kann den kleinen Fehler ignorieren. EDIT: Wo wir aber gerade noch dabei sind. Ich habe heute probiert ein "gpresult" von Rechnern in meiner Domäne zu bekommen. Die Syntax sieht ja meine ich irgendwie so aus: gpresult /r /c <Name Computer> /u <Name User> Wenn ich das mit den entsprechenden Rechten ausführe, klappt das für den Computerteil ganz gut. Aber sobald ein User ins Spiel kommt, wird ein Passwort verlangt. Gebe ich das richtig ein, sagt mir der Rechner, dass eventuell der Nutzername oder das Kennwort falsch sei. Ich habe es dabei mit zwei Varianten probiert. gpresult /r /c computername /u DOMAIN\username und gpresult /r /c computername /u username@domain Beides führte nicht zum Erfolg. Was könnte ich da verkehrt gemacht haben? bearbeitet 20. Januar 2015 von willy-goergen Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.