goscho 11 Geschrieben 6. Januar 2009 Melden Teilen Geschrieben 6. Januar 2009 Hallo Leute, ich habe folgendes Problem: SBS2k3-Domäne mit Außenstelle über VPN und dortigem W2K8-DC. Der SBS war mal WSUS 2 für das Netz. Nun habe ich einen weiteren Server in der Zentrale und auf diesem WSUS 3 SP1 installiert. Die entsprechende Gruppenrichtlinie, die die Einstellungen für WSUS beinhaltet, habe ich auf dem W2K8-DC angepasst und dort den neuen WSUS eingetragen. In der Zentrale wird diese Richtlinie von allen Clients und Servern gezogen. In der Filiale wird diese nur vom W2k8-DC gezogen. Die dortigen Vista-Clients haben weiterhin die Richlinie mit dem falschen WSUS-Eintrag. Gpupdate bringt keinen Erfolg. Könnt ihr mir einen Tipp geben, wie ich die Änderungen an Gruppenrichtlinien auf die Clients der Filiale bekomme. Zitieren Link zu diesem Kommentar
NorbertFe 2.110 Geschrieben 6. Januar 2009 Melden Teilen Geschrieben 6. Januar 2009 Hallo Leute,ich habe folgendes Problem: SBS2k3-Domäne mit Außenstelle über VPN und dortigem W2K8-DC. Der SBS war mal WSUS 2 für das Netz. Nun habe ich einen weiteren Server in der Zentrale und auf diesem WSUS 3 SP1 installiert. Die entsprechende Gruppenrichtlinie, die die Einstellungen für WSUS beinhaltet, habe ich auf dem W2K8-DC angepasst und dort den neuen WSUS eingetragen. In der Zentrale wird diese Richtlinie von allen Clients und Servern gezogen. In der Filiale wird diese nur vom W2k8-DC gezogen. Die dortigen Vista-Clients haben weiterhin die Richlinie mit dem falschen WSUS-Eintrag. Gpupdate bringt keinen Erfolg. Könnt ihr mir einen Tipp geben, wie ich die Änderungen an Gruppenrichtlinien auf die Clients der Filiale bekomme. Klingt als würden deine PCs in der Filiale die GPOs nicht korrekt übernehmen. Sollte das der Fall sein dürfte im Eventlog was dazu stehen nachdem du ein gpupdate durchgeführt hast. Poste das mal. Ich tippe mal spontan auf slowlink detection. Bye Norbert Zitieren Link zu diesem Kommentar
goscho 11 Geschrieben 7. Januar 2009 Autor Melden Teilen Geschrieben 7. Januar 2009 Klingt als würden deine PCs in der Filiale die GPOs nicht korrekt übernehmen. Sollte das der Fall sein dürfte im Eventlog was dazu stehen nachdem du ein gpupdate durchgeführt hast. Poste das mal. Ich tippe mal spontan auf slowlink detection. Bye Norbert Hallo Norbert, danke, dass du dich noch so spät abends mit solchen Sachen beschäftigst. Ich hätte dir auch gleich geantwortet,doch hatte ich vor meinem Post diesen Client-PC heruntergefahren (remote) und kein WOL dort eingerichtet. Ich hatte mehrfach gpupdate gemacht. Danach sind keine Fehlermeldungen im Ereignislog, sondern nur Infos (Erfolgsmeldungen), dass diverse GPOs angewendet wurden. Nach dem Ausführen von RSOP auf diesem Client habe ich dann gesehen, dass es nicht die aktuellen GPOs sind. Wenn ich im Server-Manager den Richtlinienergebnissatz dieses Clients anzeigen lasse, sehe ich auch, dass es nicht die aktualisierte GPO ist, die der Client zieht. Es handelt sich hierbei um eine SBS-eigene GPO (SBS-Client Computer). Hier ist nichts außer dem WSUS von mir angepasst worden. Wie kann ich es denn testen, von welchem DC dieser Client seine GPOs bekommt? Nach meinem Verständnis müsste das doch egal sein, wenn beide DCs (Zentrale und Filiale) beim Bearbeiten identische GPOs anzeigen, oder doch nicht. SlowLinkDetection vermute ich mal nicht, oder es wird zumindest nicht angezeigt. Zitieren Link zu diesem Kommentar
NorbertFe 2.110 Geschrieben 7. Januar 2009 Melden Teilen Geschrieben 7. Januar 2009 Es handelt sich hierbei um eine SBS-eigene GPO (SBS-Client Computer). Hier ist nichts außer dem WSUS von mir angepasst worden. Haben die SBS GPOs nicht WMI Filter definiert? Bye Norbert Zitieren Link zu diesem Kommentar
goscho 11 Geschrieben 7. Januar 2009 Autor Melden Teilen Geschrieben 7. Januar 2009 Haben die SBS GPOs nicht WMI Filter definiert? Bye Norbert Nein, dass haben nicht alle. Diese (SBS-Client Computer) bspw. hat keinen WMI-Filter definiert. Andere wiederum haben dies schon, z.B. SBS-Windows Vista Richtlinie hat Vista als WMI-Filter definiert. In der Zentrale habe ich XP und Vista und Server, alle haben diese GPO korrekt gezogen. In der Filiale habe ich einen W2K8-DC und diverse Vista (auch einen ohne SP1). Der Server zieht die aktualisierte GPO, die Clients nicht. Edit: Ich bekomme auf den DCs folgenden Fehler beim Ausführen von dcdiag: Starting test: frsevent There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause Group Policy problems. ......................... SBS failed test frsevent Ich finde aber keine Fehler.:confused: Zitieren Link zu diesem Kommentar
NorbertFe 2.110 Geschrieben 7. Januar 2009 Melden Teilen Geschrieben 7. Januar 2009 Nein, dass haben nicht alle. Diese (SBS-Client Computer) bspw. hat keinen WMI-Filter definiert.Andere wiederum haben dies schon, z.B. SBS-Windows Vista Richtlinie hat Vista als WMI-Filter definiert. OK, war mir nicht sicher bei welchen das der Fall ist. Ich finde aber keine Fehler.:confused: Also auf den Clients (Eventlog) taucht keine Fehlermeldung in der Filiale auf? Aber der DC nimmt die geänderte GPO korrekt an? Läuft auf den Client ein Virenscanner, wenn ja welcher? Bye Norbert Zitieren Link zu diesem Kommentar
goscho 11 Geschrieben 8. Januar 2009 Autor Melden Teilen Geschrieben 8. Januar 2009 Also auf den Clients (Eventlog) taucht keine Fehlermeldung in der Filiale auf? Genau so ist das. In Vista gibt es doch die erweiterten Ereignislogs (Anwendungs- und Dienstprotokolle). Dort gibt es einen eigenen Unterpunkt Gruppenrichtlinie. Für einen der Clients der Filiale habe ich das gerade überprüft und dort ist alles korrekt. Er nimmt den Filial-DC, hat somit eine schnelle Verbindung und wendet die SBS-Client Computer Richtlinie an. Leider nur ist dies nicht die aktuelle Version dieser Richtlinie, sondern eine alte. Aber der DC nimmt die geänderte GPO korrekt an? Ja, der DC nimmt die (auf ihm selbst geänderte) Richtlinie korrekt an. Läuft auf den Client ein Virenscanner, wenn ja welcher? Ja, SEP (Symantec Endpoint Protection) Dieser Schutz läuft aber auch auf den Clients der Zentrale, welche die aktualisierte GPO ziehen. Ich vermute einen Zusammenhang mit dem Fehler beim ausführen von DCDIAG auf den DCs, kann diese aber nicht nachvollziehen. Starting test: frsevent There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause Group Policy problems. ......................... SBS failed test frsevent Zitieren Link zu diesem Kommentar
NorbertFe 2.110 Geschrieben 8. Januar 2009 Melden Teilen Geschrieben 8. Januar 2009 Ja, der DC nimmt die (auf ihm selbst geänderte) Richtlinie korrekt an. Die auf dem DC geänderte GPO bekommt auch der andere DC korrekt mit? Ja, SEP (Symantec Endpoint Protection) Dieser Schutz läuft aber auch auf den Clients der Zentrale, welche die aktualisierte GPO ziehen. OK, trotzdem wärs nen Versuch wert. Ich vermute einen Zusammenhang mit dem Fehler beim ausführen von DCDIAG auf den DCs, kann diese aber nicht nachvollziehen. Dann wären aber auf beiden DCs auch Events zu finden die auf ein Nichtfunktionieren hindeuten. Ist das der Fall? Bye Norbert Zitieren Link zu diesem Kommentar
goscho 11 Geschrieben 8. Januar 2009 Autor Melden Teilen Geschrieben 8. Januar 2009 Die auf dem DC geänderte GPO bekommt auch der andere DC korrekt mit? Ja, dieser wendet diese an und es ist auch die richtige Version, mit dem neuen WSUS. OK, trotzdem wärs nen Versuch wert. Habe ich auch getestet, brachte nichts. Dann wären aber auf beiden DCs auch Events zu finden die auf ein Nichtfunktionieren hindeuten. Ist das der Fall? Bye Norbert Folgenden Fehler habe ich auf dem SBS im Protokoll Dateireplikationsdienst (einmal pro Tage): Der Dateireplikationsdienst hat ermittelt, dass ein Replikatstammpfad von "c:\windows\sysvol\domain" in "c:\windows\sysvol\domain" geändert wurde. Falls diese Änderungen absichtlich vorgenommen wurde, muss die Datei NTFRS_CMD_FILE_MOVE_ROOT im neuen Stammpfad neu erstellt werden. Folgendes wurde für diesen Replikatsatz ermittelt: "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" Die Replikat-Stammpfadänderung erfolgt in zwei Schritten, die durch das Erstellen der Datei NTFRS_CMD_FILE_MOVE_ROOT ausgelöst wird. [1] Bei der ersten Abfrage, die in 60 Minuten durchgeführt wird, wird dieser Computer vom Replikatsatz entfernt. [2] Bei der darauf folgenden Abfrage wird der Computer dem Replikatsatz erneut hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst. Nach der Synchronisierung befinden sich alle erforderlichen Dateien am neuen Ort. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie Zitieren Link zu diesem Kommentar
NorbertFe 2.110 Geschrieben 8. Januar 2009 Melden Teilen Geschrieben 8. Januar 2009 Folgenden Fehler habe ich auf dem SBS im Protokoll Dateireplikationsdienst (einmal pro Tage) Hat das Teil auch ne Eventid? ;) Dannn geh mal hierhin: EventID.Net - Troubleshooting information for Windows event logs Bye Norbert 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.