Jump to content

Rumak18

Senior Member
  • Content Count

    543
  • Joined

  • Last visited

Community Reputation

10 Neutral

About Rumak18

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Sorry, will nicht pingelig, aber ich bin es nun mal Die Einstellungen der GPO Settings für NTP werden unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\W32Time\Parameters und HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders angewendet. Nicht unter "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\W32Time\Parameters", wo man anscheinend die Default Werte sieht. Nur der Vollständigkeit halber.
  2. OK. Ich glaube ich hab den Grund gefunden. Der Hyper-V Host hat die INtegrationsdienste "Zeitsynchronisierung" aktiv gehabt. Ich habe den Haken entfernt. Der vorherige Fehler mit "Local CMOS Clock" war eine Folge meiner Ungeduld. Nach einem "w32tm /resync" erhalte ich nun den korrekten Server. Das ging eigentlich aus der ersten Nachricht von dir nicht hervor. Zumindest nicht für mich. Sorry. Und WO schreibt dann die GPO diese Einstellungen in der Registry?
  3. Hi, nein, habe gerade die DGPOs nochmals überprüft. Sie werden laut "gpresult /r" übernommen. Auf dem DC01 (PDC) wird mit "w32tm /monitor" weiterhin die Anzeige wie oben beschrieben gezeigt. Nicht der tatsächlich konfiguriert NTP. Für die Clients sind gar keine GPOs konfiguriert, was die Zeit anbelangt. Ich könnte das Ganze natürlich per Registry manuell anpassen, aber dann halte ich die GPOs für überflüssig. Der PDC hat seiner Registry immer noch den von Windows Server verwendeten "time.windows.com,0x8", trotz GPO. Auffällig nun: "w32tm /query /source" liefert: Local CMOS Clock Das sollte wohl was anderes sein.
  4. Hmmm... aber genau an der Stelle weiß ich nicht weiter...
  5. Hi, wie der Betreff schon sagt...die Zeit in meiner Domäne war von anderen Admins wohl konfiguriert worden mit GPOs, die es teils nicht mehr gibt. Nach einem ordnetlichen Aufräumvorgang habe ich zwar keine Probleme, aber irgendwie habe ich das Gefühl ,dass die Zeit nicht das tut , was sie machen soll. In meiner Domain existieren zwei DCs (PDC: 192.168.168.20 ; DC2: 192.168.168.30) und ich möchte die Sophos Firewall (192.168.168.10) als DNS Server für den PDC konfigurieren. Ich habe gemäß Microsoft Empfehlungen eine GPO für meinen PDC erstellt (WMI Filter etc.) Für den zweiten DC und Clients wurde nichts konfiguriert. Der PDC hat in seiner GPO die folgenden Einstellungen: Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers -> Windows-NTP-Client konfigurieren: NTPSERVER: 192.168.168.10 // Bei dieser Einstellung bin ich nicht sicher, ob und welches FLAG gesetzt werden muss (Es gibt ja 0x1,0x2 aber auch 0x01 , 0x02, 0x09 etc) Type: NTP CrossSiteSyncFlags:2 ResolvePeerBackoffMinutes:15 ResolvePeerBackOffMaxtimes: 7 SpecialPollInterval:3600 EventLogFlags: 0 Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers -> Windows-NTP-Client aktivieren: Aktiv Computer Configuration > Administrative Templates > System > Windows Time Service > Globale Konfigurationseinstellungen: FrequencyCorrectRate 4 HoldPeriod 5 LargePhaseOffset 50000000 MaxAllowedPhaseOffset 300 MaxNegPhaseCorrection 172800 MaxPosPhaseCorrection 172800 PhaseCorrectRate 1 PollAdjustFactor 5 SpikeWatchPeriod 900 UpdateInterval 100 Allgemeine Parameter AnnounceFlags 5 EventLogFlags 2 LocalClockDispersion 10 MaxPollInterval 10 MinPollInterval 6 RequireSecureTimeSyncRequests 0 UtilizeSslTimeData 1 ChainEntryTimeout 16 ChainMaxEntries 128 ChainMaxHostEntries 4 ChainDisable 0 ChainLoggingRate 30 Das Problem mit PDC: Registry: Unter dem Registry Pfad "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters" des PDCS sehe ich auf dem unter dem Registry Schüssel "NTPServer" immer noch "time.windows.com,0x8", obwohl ich durch die GPO ja "192.168.168.10" eingegeben habe. Auch der "Type" steht anstatt auf "NTP" auf "NT5DS". Die GPO für den PDC selber wird aber angewendet, zumindest sagt das "gpresult /r". Werden die Registry Schlüssel per GPO denn nicht aktualisiert? Das Problem auf den Clients oder Mitgliedsservern: Nun habe ich das Problem, dass die "Clients" (Der zweite DC, Server und Desktops) nicht die exakte Zeit haben wie der PDC. Selbst nach einem "w32tm /resync" Befehl nicht. Es sind immer ca. 30 Sekunden Unterschied. Nichts schlimmes, aber das suggeriert mir, dass es nicht funktioniert. Ausserdem erhalte ich auf einem Client mit dem Befehl "w32tm /query /configuration" folgendes: [Konfiguration] EventLogFlags: 2 (Lokal) AnnounceFlags: 10 (Lokal) TimeJumpAuditOffset: 28800 (Lokal) MinPollInterval: 6 (Lokal) MaxPollInterval: 10 (Lokal) MaxNegPhaseCorrection: 4294967295 (Lokal) MaxPosPhaseCorrection: 4294967295 (Lokal) MaxAllowedPhaseOffset: 300 (Lokal) FrequencyCorrectRate: 4 (Lokal) PollAdjustFactor: 5 (Lokal) LargePhaseOffset: 50000000 (Lokal) SpikeWatchPeriod: 900 (Lokal) LocalClockDispersion: 10 (Lokal) HoldPeriod: 5 (Lokal) PhaseCorrectRate: 1 (Lokal) UpdateInterval: 100 (Lokal) [Zeitanbieter] NtpClient (Lokal) DllName: C:\Windows\system32\w32time.dll (Lokal) Enabled: 1 (Lokal) InputProvider: 1 (Lokal) CrossSiteSyncFlags: 2 (Richtlinie) AllowNonstandardModeCombinations: 1 (Lokal) ResolvePeerBackoffMinutes: 15 (Richtlinie) ResolvePeerBackoffMaxTimes: 7 (Richtlinie) CompatibilityFlags: 2147483648 (Lokal) EventLogFlags: 0 (Richtlinie) LargeSampleSkew: 3 (Lokal) SpecialPollInterval: 7200 (Richtlinie) Type: NT5DS (Richtlinie) VMICTimeProvider (Lokal) DllName: C:\Windows\System32\vmictimeprovider.dll (Lokal) Enabled: 1 (Lokal) InputProvider: 1 (Lokal) NtpServer (Lokal) DllName: C:\Windows\system32\w32time.dll (Lokal) Enabled: 0 (Lokal) InputProvider: 0 (Lokal) während mir "w32tm /monitor" auf dem selben Client andere Einstellungen liefert: DC01.int.local *** PDC ***[192.168.168.20:123]: ICMP: 1ms Verzögerung NTP: +0.0000000s Offset von DC01.int.local RefID: 80.84.77.86.rev.sfr.net [86.77.84.80] Stratum: 2 DC02.int.local[192.168.168.30:123]: ICMP: 0ms Verzögerung NTP: -21.1807467s Offset von DC01.int.local RefID: 'VMTP' [0x50544D56] Stratum: 1 [Warnung] Die Reversenamenauflösung ist die beste Möglichkeit. Sie ist ggf. nicht korrekt, da sich das Ref-ID-Feld in Zeitpaketen im Bereich von NTP-Implementierungen unterscheidet und ggf. keine IP-Adressen verwendet. Danke für euere Hilfe!
  6. Ok. Hat so wunderbar geklappt. Computer hinzugefügt und es funktioniert...Danke!
  7. Danke tesso und testperson. Ich gebe Morgen Bescheid , ob es geklappt hat.
  8. Danke. Werde es versuchen. Zur Klarstellung: Es soll der/die betroffene(r) Computer zur Delegierung hinzugefügt werden, obwohl sich der/die Computer nicht in der selben OU befinden wie die GPO?
  9. Sorry... also nochmal verständlicher: Ich habe eine neue Gruppenrichtlinie namens "Benutzer_Administratoren" erstellt. Diese in eine OU (namens Benutzer) verknüpft. In dieser OU befinden sich noch zwei weitere GPOs.
  10. Hi, jetzt muss ich leider noch einen Thread aufmachen. Die AD meiner Vorgänger macht mir ganz schön zu schaffen. Ich habe eine neue Gruppenrichtlinie namens "Benutzer_Administratoren" erstellt. Diese in eine OU (Benutzer) gesetzt mit zwei anderen GPOs verknüpft Die neue GPO soll Netzlaufwerke durch die Benutzerkonfiguration mit der Laufwerkszuordnung mappen. In der OU befinden sich alle Benutzer. Die neue GPO soll allerdings auf nur zwei Benutzer dieser OU angewendet werden, weshalb im Reiter "Delegierung" der GPO diese zwei Benutzer hinzugefügt worden sind. Allerdings kann ich GPUPDATE und Neustarts fahren , so oft ich will. Die GPO wird einfach nicht auf die User angwendet (Ersichtlich mit gpresult /r). Bitte hilft mir mal...
  11. Ja, weiß ich. Ich wüsste aber nicht, was daran an dieser Stelle falsch wäre. Hatte es zuvor ohne Delay versucht und wollte sicher sein, dass nichts im Wege steht.
  12. Hi, ich habe für meine User ein AD Login Script erstellt. Das Script hat folgenden Aufbau: ###### VARIABLEN ###### @ping -n 240 localhost >nul set LOG=c:\mypc\test.txt ###### Pre Run ###### date /t >%LOG% time /t >>%LOG% ###### CHECK ###### net use | findstr /I "\\\\my.domain\\shares" | findstr /I y: if %errorlevel% NEQ 0 (goto CORRECT_Y) else goto ENDE ###### RUN ###### :CORRECT_Y echo "CORRECT" >>%LOG% net use y: /delete /yes >>%LOG% :MOUNT_Z echo "MOUNT" >>%LOG% net use y: \\my.domain\shares >>%LOG% :ENDE echo "ENDE" >>%LOG% exit Das Script liegt unter \\my.domain\SYSVOL\my.domain\scripts\MOUNT_Y_DFS.cmd. Es ist in eine Benutzer Gruppenrichtlinie als Anmeldescript unter Benutzerkonfiguration -->Richtlinien -->Windows-Einstellungen-->Skripts--> Anmelden konfiguriert. Die Berechtigungen für die GPO sind für "Authentifziere Benutzer" konfiguriert. Die jeweilige GPO ist auch korrekt verknüpft und die GPO ist "aktiviert". Das Script soll überprüfen, ob das Y Laufwerk das DFS Share gemountet hat. Das Script läuft manuell durch und schreibt auch das Log. Führe ich allerdings ein Reboot des Rechners durch, während "Y" getrennt wurde, wird nicht mal ein Log geschrieben. Es scheint so, als wenn das Script gar nicht zum Zuge kommt. Mit "gpresult /r" sehe ich allerdings, dass die GPO an sich angewendet wird. Kann mir Jemand beim Debuggen behilflich sein?
  13. Hi, ist zwar etwas verspätet....aber es funktioniert nun irgendwie doch mit den GPO und der MMC Druckserver im Zusammenspiel.
×
×
  • Create New...