Jump to content

andrew

Members
  • Gesamte Inhalte

    495
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von andrew

  1. Ok, dann hat sich die Sache mit dem VMI Filter erledigt. Gut, dann suche ich nach anderen Lösungen. Erste Vorschläge habe ich bereits von Jan erhalten, danke vielmal.
  2. Hi all Pilotprojekt: Ziel, fixe Arbeitsstationen durch Notebooks austauschen/ ersetzen. Dazu haben wir nun einige Testbenutzer bestimmt, welch auch bereits als Test mit einem NB im Geschäft bzw. auch zu Hause und oder unterwegs arbeiten. Dabei habe ich z.B. folgende Situation bemerkt: Verhalten der NBs im Geschäft (Anmeldung an der Domain) Bei uns haben wir viele Dinge automatisiert, so auch das Verhalten des Windows 10 Autostarts. Startet im Geschäft Jemand das Notebook (NB), meldet sich im Geschäft an der Domäne an, startet danach z.B. auf allen Client Systemen per Autostartmenü im Windows 10 Outlook und der Windows Explorer. Verhalten der NBs unterwegs (extern) Startet Jemand sein NB ausserhalb des Geschäftes, z.B. zu Hause am Schreibtisch, merkt das NB nicht, dass es nicht mehr mit der Domain verbunden ist und startet wie im Geschäft automatisch gemäss zwischengespeicherten GPO Einstellung, lokal das Outlook automatisch und auch den Microsoft Edge. Das finde ich etwas störend, weil unsere Benutzer sollen gemäss aktuell konfigurierten Sicherheitseinstellungen mit dem NB nicht im Internet surfen können (und kann dies auch nicht), ausser vielleicht der einen oder anderen Ausnahme Webseite wie z.B. der VMware View Webseite (falls Jemand z.B. anstatt VMware View Client sich per Webbrowser im Homeoffice einloggen will) oder irgend einer Viedeokonferenz URL wie MS Teams oder so. Auf Grund dessen finde ich es auch etwas störend, dass dann wie im Geschäft automatisch das Outlook gestartet wird, obwohl es ja gar keine Verbindung zum Exchange im Geschäft hat, der Webbrowser wird automatisch gestartet, obwohl ein User sowieso nicht im Internet surfen kann, dies, weil eine GPO unter anderen diese Einstellungen so vorgibt. Ich dachte mir, wenn überhaupt automatisiert irgend etwas starten soll - von unterwegs, zu Hause bzw. einfach ausserhalb des Geschäftes, dann wäre es aus meiner Sicht sinnvoller, wenn was "brauchbares" per Windows 10 Startmenü gestartet würde wie z.B. den VMware View Client. Denn die Benutzerinnen und Benutzer sollen vom Homeoffice aus oder unterwegs per VMware View Client sich in das Homeoffice einwählen. GPO per VMI Filter filtern Meine Idee wäre, dass man einen WMI Filter erstellt, welcher prüft, ob der Domain Controller bzw. die Domain erreichbar ist oder nicht. Wenn der DC NICHT erreichbar wäre, würde dann die GPO X ziehen. Diese GPO hätte dann z.B. die Einstellung konfiguriert, lösche die Icons (Verknüpfungen) Outlook und Microsoft Edge aus dem Pfad %appdata%\Microsoft\Windows\Start Menu\Programs\Startup und kopiert stattdessen die Verknüpfung des VMware VIEW Clients in diesen Pfad und oder man belässt die Sache mit dem automatischen starten des VMware View Clients. Noch kurz eine Ergänzung von mir. Die Sache mit dem VMI Filter würde ich darum sinnvoll und cool finden weil, es A wohl die einfachste Lösung wäre, und B zum Verwalten von uns Admins am einfachsten wäre. Man würde sofort in der Gruppenrichtlinienverwaltung sehen, dass die GPO X nun mit einem WMI Filter verknüpft ist und hätte von daher eine übersichtliche Lösung - so finde ich dies zumindest. cheers Andrew
  3. Noch ergänzend: Es stellte sich nun heute heraus, dass es NICHT notwendig ist, eine zusätzliche GPO mit der Ordnerumleitung für z.B. Desktop, Dokumente und Favoriten zu erstellen. Da wie erwähnt ja bereits eine GPO vorhanden ist, in welcher die sogenannten Shell Folders via Registry konfiguriert sind und für die soeben, genannten Objekte ein UNC Pfad auf den Fileserver hinterlegt ist (Umleitung zeigt jeweils in das Home Verzeichnis der User), welches wiederum bei den Aussendienst Mitarbeitern Offline zur Verfügung gestellt wird. Was aber nun gewünscht ist, dass ich via zusätzliche GPO nur eine Ordnerumleitung aktiviere für den Ordner AppData\Roaming. Da bestimmte Programme hier Ihre Konfiguration abspeichern, wäre diese dann auch stets immer verfügbar, egal, wo man sich anmeldet. Kurz: wir hätten dann also folgende Situation - keine Roaming Profilles mehr - würden weiterhin die bereits vorhandene Konfig via GPO gelöst (Shell Folders) nutzen - und neu in Kombination mit den Shell Folders noch eine GPO, welche eine Ordnerumleitung für den Ordner %AppData%\Roaming beinhaltet. Mit dieser Konfiguration sollten wir auf einem guten Weg sein, zukünftig auch ohne servergespeicherte Profile arbeiten zu können.
  4. Danke daabm, dass Du nochmals einen Input geliefert hast. Frage: Habe nun Probleme beim Einrichten der Ordnerumleitung. Diese wird beim Benutzer zwar gezogen, jedoch stellte ich fest, dass noch eine vererbte GPO, welche unter anderem die Einstellung Shell Folders via Registry zieht und mir nun "reinfunkt". Kontrolliere ich nun via rechte Maustaste z.B. beim Ordner Desktop, so zeigt dort der UNC Pfad nicht dort hin, wo ich in der Folder Redirection GPO definiert habe, sondern er zeigt auf den UNC Pfad, welche von einer vererbten GPO kommt, welche via Registry die Shell Folders konfiguriert. Ich teste übrigens in der produktiven Umgebung, habe eine Test OU gemacht und meinen Test Benutzer dort hinein gepflanzt. Durch dieses Vorgehen werden aber auch zig GPOs vererbt und vom Benutzer gezogen. Soll ich dieses Problem in einem separaten Beitrag hier auf der Webseite veröffentlichen oder hat gleich Jemand eine Idee? Sheiss Shell Folders (Registry Einträge)
  5. OK, das sind hilfreiche Ansätze/ Inputs. Werde ich gerne so mal überdenken und weitere Abklärungen vornehmen. Cheers Andrew
  6. Eine VDI Umgebung haben wir bereits Diese wird im Moment, hauptsächlich für das Homeoffice den Usern zur Verfügung gestellt. Mobiles arbeiten wird bei uns vorangetrieben. Wie am Anfang des Beitrags geschildert, sind wir dabei, neue Notebooks mit dem neuesten Windows 10 20H2 zu installieren, um diese dann unseren Aussendienst Mitarbeitern zur Verfügung stellen zu können. Gut, wir könnten nun den Weg einschlagen, dass wir halt den Aussendienst Mitarbeitern nur ein naktes Windows 10 Tablet zur Verfügung stellen - mit einem View Client drauf installiert Und: wenn Sie extern beim Kunden sind, müssen Sie dann halt hoffen, dass Sie stets eine mobile Datenverbindung haben, damit Sie sich auch auf die Viev Verbindung verbinden können und somit Zugriff auf ALLE Geschäfts relevanten Daten hätten. Was aber, wenn der Standort eines Kunden eine schlechte, mobile Datenanbindung bietet und es unserem Aussendienst Mitarbeiter NICHT möglich ist, eine Verbindung zu unserem Homeoffice Umgebung aufzubauen?
  7. Meine Situation, für welche ich Lösungen suche betreffen nicht mich als Privatperson, sondern schildern eine Situation in meiner Firma mit rund 130 Mitarbeitern. Das einfach mal so zur Klarstellung Die Frage ist daher nicht, was der moderne Mensch will/ braucht, sondern was die Firma, in welcher man arbeitet konkret für Datenschutz Richtlinien hat, ob z.B. versicherte Daten in "irgend" eine Cloud "abwandern" dürfen oder nicht, usw. Und wenn wir schon dabei sind: Nein, dürfen Sie klar nicht! Daher sind wir in der internen ICT auch selber zuständig für die Datenhaltung So, nun habe ich mehrheitlich Ratschläge gehört/ gelesen, was man heute, hier und jetzt nicht mehr nutzt bzw. darüber diskutiert, ob Roaming Profiles noch state of the Art sind oder doch nicht. Ihr wisst nun auch, dass die Synchronisation von Benutzer/ Geschäfts Daten in unserer Umgebung nicht in Clouds gespeichert werden dürfen! Windows Bordmittel interessieren mich. Ich meine, unseren Aussendienst Mitarbeiter arbeiten seit Jahren mit den bekannten, ebenfalls Steinzeit mässigen Offline Files. Na und? solange die Technik funktioniert, interessiert es mich eigentlich nicht gross, ob die Technik veraltet ist oder nicht. Aber ja, klar, ich bin offen für neues, an dem soll es nicht scheitern Der Nachfolger der alten Offline Synchronisation seit Minimum Windows 7 ist ja, sind ja die so genannten Workfolders. Ob diese Technik besser ist? ich meine, was macht eine Firma wie wir, wenn man die Benutzerdaten/ Geschäfts Daten nicht in eine Cloud synchronisieren darf? Ich glaube kaum, dass wir weltweit die einzigen sind, welche mit dieser Situation irgendwie klar kommen müssen Wer bietet noch mehr/ andere Vorschläge oder noch besser, versteht die Problematik, vor welcher ich nun stehe?
  8. Also auf die Roaming Profiles verzichten zu können, wäre generell eigentlich auch kein Problem. Wäre .... Nur frage ich mich gerade, wie der Zugriff auf Ihre Benutzerdaten bei unseren Aussendienst Mitarbeitern funktionieren wird/ würde, wenn wir denen das Roaming Profile aufheben und Sie nur noch via Ordnerumleitung arbeiten würden? Denn wenn Sie ausser Haus gehen, also einen externen Einsatz haben, nehmen Sie Ihr NB mit und müssen z.B. Zugriff auf Laufwerke haben (Offline Synchronisation) und natürlich auf Ihre Benutzerdaten haben. Die Benutzer hätten dann jedoch nur Zugriff auf Ihre Benutzerdaten und Laufwerke, wenn man die Ordnerumleitung im Zusammenspiel mit Offline verfügbar machen von Dateien arbeitet, seht Ihr das auch so wie ich :-)? Aber Achtung - Homeoffice Umgebung Problematik und zwischengespeicherte Dateien Melde sich jetzt nun ein solcher Benutzer auf der VMware View Umgebung (kurz: Homeoffice Umgebung) an und wir hätten die klassische Ordnerumleitung im Einsatz, ohne Roaming Profiles, so würden ja dann die Benutzer Dateien (welche in der Ordnerumleitung konfiguriert sind) auch Offline auf den virtuellen Maschinen in der Homeoffice Umgebung lokal auf den virtuellen 10 PCs zwischengespeichert, was natürlich dann nicht so sexy wäre - so finde ich?! Wie könnte man dieser Problematik entgegen wirken?
  9. Danke für den Link in Bezug Abkürzungen. Diese Seite kannte ich bis heute noch gar nicht OT = Off Topic = Beitrag gehört nicht zum Thema, nicht zu verwechseln mit oT („ohne Text“) Ok, sein Kommentar sagt also aus, dass sein Input keinen direkten Zusammenhang hat mit dem Thema, sprich, mit meiner Problemstellung? All right, wieder was gelernt
  10. Guten Morgen Nobbyaushb Danke für deine Rückmeldung. Mir sagt leider der Begriff OT nichts. Kannst Du hierzu ein paar Details mehr schreiben? Wenn ich das verstanden habe, verstehe ich dann wohl auch den Rest, wo Du noch geschrieben hast cheers Andrew
  11. Ciao Daabm Aha, ein alter Hase was die IT angeht Guckst Du mal, habe fast zeitgleich wie Du schon wieder geantwortet
  12. Freue mich über jeden Kommentar Darum, hallo Norbert, freut mich. Wenn Ihr schon lange keine Roaming Profiles mehr einsetzt, kennt Ihr demnach auch keine Probleme mit den neuen Appx Packages (Windows 10 APPs), richtig - auch nicht, als Ihr von Windows Version x auf Windows Version y gewechselt habt? Danke auch Dir testperson für den rückwirkenden Input. Ok, je nach Umfeld macht es natürlich Sinn, sich für oder gegen Roaming Profiles auszusprechen. Wie es der Name schon sagt, sind Roaming Profiles ursprünglich entwickelt worden, damit das Benutzer Profil mit dem User mitwandert, also ganz nach dem Motto: Egal, an welcher Kiste ich mich einlogge, ob physisch oder virtuell, ich als Benutzer finde stets mein Benutzerprofil vor Nun, die Frage ist, ob sich dieses Szenario genau so auch ohne Roaming Profiles und nur mit der Ordnerumleitung umsetzen lässt? Auch ich bin schon länger in der IT und bin der Meinung, mich noch zu erinnern, als die Ordnerumleitung aufgekommen ist, dass man diese oft z.B. benutzt hat, um gewisse Dinge aus dem Benutzerprofil ausschliessen zu können wie eben z.B. der Desktop, die klasischen BN Profil bezogenen Ordner wie Favoriten, Dokumente, Eigene Dateien und wie Sie alle heissen. Beispielsweise ist es ja so, dass bestimmte Programme oder Konfigurationen meines Wissens - je nach je auch im Pfad %AppData% gespeichert werden, welcher sich, wenn notwendig, auch per GPO umgeleitet werden könnte - z.B. auf einen Fileserver. Jedoch denke ich, müsste man da vorsichtig damit umgehen und genau analysieren, was und wie viel im Pfad %AppData% von der Anwendung x abgespeichert wird oder würde (Thema: Datenspeicher, anwachsen des %AppData% und wenn mehrere Benutzer, bald mal eine Vervielfachung des Datenvolumes, welches in Anspruch genommen wird oder würde). Nachmals zu meinem Problem: Wenn ich z.B. innerhalb 2 physikalischen PCs, welche beide mit dem neusten Windows 10 20H2 ausgestattet sind mich hin und her an und wieder abmelde, so habe ich in beiden Fällen die APP Windows Rechner und die APP Sticky Notes. Wenn ich aber diesen Artikel hier lese https://www.gruppenrichtlinien.de/artikel/unbrauchbar-und-kaputt-roaming-user-profiles-serverbasierte-profile dürfte so wie ich das gelesen habe, nach dem bekannten Author NICHT funktionieren?! So beschreibt er es auf jeden Fall Mein Test hat aber zumindest mit der neusten Windows 10 H20 Version das Gegenteil gezeigt?! Trotzdem ist mein Problem noch immer nicht gelöst, denn wie ich geschrieben habe ergibt sich dann das Problem, wenn ich mit meinem Testbenutzer Test mich dann z.B. auf die VMware View Umgebung verbinde, sprich, aus einem Windows 10 1803 Pool eine Kiste erhalte. Genau das ist das Hauptproblem - leider und genau hierfür suche ich noch immer eine Lösung, denn wenn ich mir nun überlege, 2 APPs müssen nun funktionieren - auf diese Weise oder ob ich nun einfach schnell für ca. 130 User einfach das Roaming Profile aufhebe, nur weil es angeblich Probleme gibt im Zusammenhang mit Roaming Profiles und den neuen Windows 10 APPs, da Ihr Speicherpfad eben lokal ist? Ja, man sieht, so schnell einfach mal für 130 User das Roaming Profile aufheben, nur damit dann aktuell die 2 APPs auf jede Art und weise beim Einloggen immer verfügbar sind - glaube, das steht in keinem Verhältnis zueinander Obwohl ich sicher zugeben muss, dass die Apps in Zukunft nicht weniger werden, im Gegenteil, die APPs werden immer mehr und mehr und ja, die Sache muss man wirklich hinterfragen - also eben, auch das Benutzen von Roaming Profiles. Aber eben, das hilft mir jetzt auch nicht weiter :-(
  13. Danke für die rasche Antwort: Gegenfrage: Habt Ihr in eurem Betrieb Roaming Profiles auf Grund der Tatsache, dass Windows APPs immer mehr im Fokus stehen, abgeschaffen Und: Arbeitet Ihr somit nur noch mit der Ordnerumleitung und wenn ja, habt Ihr auch eine VMware View Umgebung, für welche Ihr eure Benutzer so im (Home Office) arbeiten lässt? funktioniert es so besser? Habe diesen Artikel hier https://www.gruppenrichtlinien.de/artikel/unbrauchbar-und-kaputt-roaming-user-profiles-serverbasierte-profile gelesen. War sehr spannend Und: Trotzdem muss ich festhalten, dass mir nicht bewusst ist, dass bei meinen Test (via Roaming Profile auf Win10 1803 anmelden, wieder abmelden, auf Win10 20H2 anmelden, wieder abmelden) irgendwas vom Benutzer Roaming Profile Test einen Defekt erlitt?! Des Weiteren gibt es weitere Punkte, welche sich NICHT mit den Erklärungen im Artikel decken! Die Frage ist, mit welcher Version hat der bekannte Author getestet, sehe ich nirgends (oder habe ich es übersehen?)
  14. Hallo zusammen Wir haben aktuell als OS (auf physikalischen Geräten wie auch virtuell) als Windows 10 Image die Version 1803 im Einsatz. Im Einsatz sind auch sind sogenannte, servergespeicherte Profile im Zusammenspiel mit der Ordnerumleitung (z.B. Desktop, Ordner Dokumente). %AppData% ist lokal, sprich, wird NICHT via Ordnerumleitung auf den Fileserver umgeleitet. Nun wollen wir erste Testgeräte mit Windows 10 20H2 für einen kleinen Benutzerkreis zum Testen vorbereiten und stellte dabei folgendes Problem fest: Anmeldung zuerst auf neuem Win10 20H2 Test 01: Der Testbenutzer Test hat Zugriff auf ALLE Apps,. 2 APPs sind dabei besonders im Fokus und wichtig, nämlich die APP Windows Rechner und die APP Kurznotizen (Sticky Notes) Test 02 (B): Melde ich mich nun mit dem Testbenutzer Test anschliessend gleich auf einem OS Win10 20H2 an, nachdem ich zuvor wie geschildert unter Win10 1803 mit dem gleichen Benutzerprofil noch Zugriff auf die 2 APPs hatte, habe ich nun im neuen Win10 20 H2 KEINE Windows Rechner APP und keine APP Kurznotizen. Anmeldung auf einem "alten" Win10 1803 Test 01: Melde ich mich mit diesem Testbenutzer Test anschliessend z.B. auf einer virtuellen Maschine an (z.B. auf die VMware View Umgebung), so werden die APP Windows Rechner und die APP Sticky Notes NICHT angezeigt. Test 02 (A): Verfahre ich in umgekehrter Richtung, sprich, melde mich mich zuerst mit meinem Testbenutzer Test das erste Mal auf einem "alten" Windows 10 1803 an, habe ich Zugriff auf die APP Windows Rechner und auf die APP Sticky Notes. Fazit Wenn ich mich zuerst auf einem "alten" Windows 10 1803 anmelde und erst danach auf einem neuen Windows 20H2, so habe ich in beiden Fällen Zugriff auf die beiden, wichtigen APPs Windows Rechner und Sticky Notes. Verfahre ich in umgekehrter Reihenfolge, sprich, ich melde mich zuerst mit einem Benutzerprofil auf dem neuen Windows 10 20H2 an und erst danach auf dem "alten" Windows 10 1803, so habe ich bei der zweiten Anmeldung KEINE der beiden genannten APPs im Startmenü, kann Sie nicht manuell aufrufen und oder Sie werden auch via Windows Suche NICHT gefunden! Frage Wie bringe ich es fertig, damit in jedem Fall, also in jeder Situation einem Benutzer auch auf dem alten Windows 10 1803 in seinem Benutzerprofil die beiden APPs Windows Rechner und Sticky Notes zur Verfügung stehen? cheers Andrew
  15. Danke daabm Es lag tatsächlich an der Firewall, konkret an der NAT Regel (SNAT > Masquerade). In der Original Source war mein DC nicht drin, dafür in der Original Destination, was natürlich so falsch ist. Da ist mir tatsächlich beim Erstellen der SNAT Regel ein Fehler unterlaufen und ich bemerkte Ihn nicht bzw. im Live Log der Firewall war die Kommunikation via UDP Port 123 ausgehend von der Quell IP (mein DC) als grün markiert (rot markiert = FW blockt). Tja, von dieser Tatsache habe ich mich die ganze Zeit irritieren/leiten lassen - dies, obwohl, so wie sich soeben herausgestellt hat, die SNAT Regel falsch war, sehr strange ... Aber daabm, du hast mir soeben dazu gebracht, die FW Geschichte erneut zu überprüfen, danke für den HInweis. Nun funktioniert die Sache, siehe anbei ein Auszug. Daabm, aus welcher Zeile hat Du denn herausgelesen, dass die Kommunikation meines DC nach aussen irgendwie in Bezug Synchronisierung nicht funktioniert? Das würde mich jetzt am meisten interessieren, denn diese Zeilen habe ich ja auch durchgelesen. Ist es möglicherweise die Zeile mit dem Text in Win2K detect mode, stage 1 ? C:\Windows\system32>w32tm /query /status Leap Indicator: 0(no warning) Stratum: 2 (secondary reference - syncd by (S)NTP) Precision: -6 (15.625ms per tick) Root Delay: 0.0094304s Root Dispersion: 36.9215913s ReferenceId: 0xC3B01ACE (source IP: 195.176.26.206) Last Successful Sync Time: 28.12.2020 16:50:58 Source: ntp.metas.ch,0x8 Poll Interval: 6 (64s) C:\Windows\system32>w32tm /stripchart /computer:ntp.metas.ch Tracking ntp.metas.ch [195.176.26.206:123]. The current time is 28.12.2020 16:51:51. 16:51:51, d:+00.0107409s o:+19.8887989s [ | @] 16:51:53, d:+00.0113208s o:+19.5302154s [ | @] 16:51:56, d:+00.0111091s o:+19.1798081s [ | @] 16:51:58, d:+00.0111767s o:+18.8348276s [ | @] 16:52:00, d:+00.0105858s o:+18.4957864s [ | @] 16:52:03, d:+00.0110392s o:+18.1638129s [ | @] 16:52:05, d:+00.0108543s o:+17.8367589s [ | @] ^C C:\Windows\system32> NoerbertFe, nun wo klar ist, woran es lag, noch ergänzend zu deinem Kommentar: Ja, da steht nun auch tatsächlich die Event-ID 35 drin mit dem Text The time service is now synchronizing the system time with the time source ntp.metas.ch,0x8 (ntp.m|0x8|0.0.0.0:123->195.176.26.206:123).
  16. 20:23 Uhr Event ID 139 (The time service has started advertising as a time source.) 20:23 Uhr Event ID 143 (The time service has started advertising as a good time source.)
  17. Ja, habe nur einen DC. im Eventlog stammen die letzten Einträge von 13:47 Uhr, als ich den Zeitdienst gestoppt und oder w32tm/ resync /rediscover oder ähnliches durchgeführt habe. Es sind zwei verschiedene Event IDs zu sehen: - 139 (The time service has started advertising as a time source.) - 143 (The time service has started advertising as a good time source) Das LOG vom Service w32time sagt da schon etwas mehr. Zur Erinnerung, mein DC soll sich mit dem NTP Server ntp.metas.ch synchronisieren. Auf der Firewall ist auch nur als Ziel dieser Alias hinterlegt Und: Die Firewall lässt ausgehend den UDP Port 123 zu. Das Loging für den w32time Service habe ich mit diesem Befehl aktiviert: w32tm /debug /enable /file:c:\sys\ntp.log /entries:0-300 /size:1024000 Das ist ein Teilauszug aus dem LOG ------------------------------ 153397 18:10:50.8425280s - ---------- Log File Opened ----------------- 153397 18:11:02.7534820s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:11:02.7536059s - ListeningThread -- response heard from 192.168.14.134:123 <- 192.168.14.135:123 153397 18:11:02.7536643s - /-- NTP Packet: 153397 18:11:02.7536699s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:11:02.7536779s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:11:02.7536837s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:11:02.7536972s - | RootDelay: 0x0000.0014s - 0.000305176s; RootDispersion: 0x0010.0000s - 16s 153397 18:11:02.7537154s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:11:02.7537250s - | ReferenceTimestamp: 0xE3934C24F0E3292F - 13253566116940966200ns - 153397 18:08:36.9409662s 153397 18:11:02.7537395s - | OriginateTimestamp: 0xE3934C76BFC7093E - 13253566198749130800ns - 153397 18:09:58.7491308s 153397 18:11:02.7537542s - | ReceiveTimestamp: 0xE3934C24EC121EE6 - 13253566116922151500ns - 153397 18:08:36.9221515s 153397 18:11:02.7537699s - | TransmitTimestamp: 0xE3934C64ED0C2FB9 - 13253566180925967200ns - 153397 18:09:40.9259672s 153397 18:11:02.7537868s - >-- Non-packet info: 153397 18:11:02.7537947s - | DestinationTimestamp: 153397 18:11:02.7538014s - 0xE3934CB6C0EBE744153397 18:11:02.7538080s - - 13253566262753599600ns153397 18:11:02.7538150s - - 153397 18:11:02.7535996s 153397 18:11:02.7538239s - | RoundtripDelay: 653100ns (0s) 153397 18:11:02.7538359s - | LocalClockOffset: -81827305800ns - 1:21.827305800s 153397 18:11:02.7538544s - \-- 153397 18:11:02.7693674s - Computing server signature: OLD:FALSE, RID:000004A0, format:0x1 153397 18:11:02.7700370s - ExpectedDelay:10531 ActualDelay:6333 (FILETIME units) 153397 18:11:02.7700576s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.134:123 153397 18:11:11.5330802s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:11:11.5332557s - ListeningThread -- response heard from 192.168.14.129:123 <- 192.168.14.135:123 153397 18:11:11.5332874s - /-- NTP Packet: 153397 18:11:11.5332968s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:11:11.5333047s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:11:11.5333106s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:11:11.5333230s - | RootDelay: 0x0000.0012s - 0.000274658s; RootDispersion: 0x0010.0000s - 16s 153397 18:11:11.5333373s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:11:11.5333467s - | ReferenceTimestamp: 0xE3934C2DB8CEEFBC - 13253566125721907600ns - 153397 18:08:45.7219076s 153397 18:11:11.5333611s - | OriginateTimestamp: 0xE3934C7F848C8FC5 - 13253566207517769800ns - 153397 18:10:07.5177698s 153397 18:11:11.5333758s - | ReceiveTimestamp: 0xE3934C2DB0E44B6E - 13253566125690983500ns - 153397 18:08:45.6909835s 153397 18:11:11.5333916s - | TransmitTimestamp: 0xE3934C6DB4B691F7 - 13253566189705910800ns - 153397 18:09:49.7059108s 153397 18:11:11.5334085s - >-- Non-packet info: 153397 18:11:11.5334164s - | DestinationTimestamp: 153397 18:11:11.5334230s - 0xE3934CBF88832335153397 18:11:11.5334296s - - 13253566271533251000ns153397 18:11:11.5334365s - - 153397 18:11:11.5332510s 153397 18:11:11.5334454s - | RoundtripDelay: 553900ns (0s) 153397 18:11:11.5334574s - | LocalClockOffset: -81827063200ns - 1:21.827063200s 153397 18:11:11.5334734s - \-- 153397 18:11:11.5334949s - Computing server signature: OLD:FALSE, RID:00000454, format:0x1 153397 18:11:11.5341826s - ExpectedDelay:6444 ActualDelay:6476 (FILETIME units) 153397 18:11:11.5342026s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.129:123 153397 18:11:27.9478824s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:11:27.9479534s - ListeningThread -- response heard from 192.168.14.130:123 <- 192.168.14.135:123 153397 18:11:27.9480874s - /-- NTP Packet: 153397 18:11:27.9480932s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:11:27.9481012s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:11:27.9481071s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:11:27.9481197s - | RootDelay: 0x0000.0022s - 0.000518799s; RootDispersion: 0x0010.0000s - 16s 153397 18:11:27.9481339s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:11:27.9481433s - | ReferenceTimestamp: 0xE3934C3E1CA18F31 - 13253566142111840200ns - 153397 18:09:02.1118402s 153397 18:11:27.9481577s - | OriginateTimestamp: 0xE3934C8FEE9FDCA9 - 13253566223932126800ns - 153397 18:10:23.9321268s 153397 18:11:27.9481724s - | ReceiveTimestamp: 0xE3934C3E18CAAD37 - 13253566142096842600ns - 153397 18:09:02.0968426s 153397 18:11:27.9481882s - | TransmitTimestamp: 0xE3934C7E1CA1B0BF - 13253566206111842200ns - 153397 18:10:06.1118422s 153397 18:11:27.9482052s - >-- Non-packet info: 153397 18:11:27.9482132s - | DestinationTimestamp: 153397 18:11:27.9482198s - 0xE3934CCFF2ACD83A153397 18:11:27.9482264s - - 13253566287947949900ns153397 18:11:27.9482334s - - 153397 18:11:27.9479499s 153397 18:11:27.9482422s - | RoundtripDelay: 823500ns (0s) 153397 18:11:27.9482543s - | LocalClockOffset: -81835695900ns - 1:21.835695900s 153397 18:11:27.9482704s - \-- 153397 18:11:27.9482992s - Computing server signature: OLD:FALSE, RID:00000453, format:0x1 153397 18:11:27.9490315s - ExpectedDelay:6455 ActualDelay:6804 (FILETIME units) 153397 18:11:27.9490517s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.130:123 153397 18:11:31.2640767s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:11:31.2641364s - ListeningThread -- response heard from 192.168.14.132:123 <- 192.168.14.135:123 153397 18:11:31.2641584s - /-- NTP Packet: 153397 18:11:31.2641632s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:11:31.2641713s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:11:31.2641772s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:11:31.2641896s - | RootDelay: 0x0000.008Cs - 0.00213623s; RootDispersion: 0x0010.0000s - 16s 153397 18:11:31.2642039s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:11:31.2642133s - | ReferenceTimestamp: 0xE3934C405BBFE2D9 - 13253566144358396700ns - 153397 18:09:04.3583967s 153397 18:11:31.2642277s - | OriginateTimestamp: 0xE3934C922E479C76 - 13253566226180780200ns - 153397 18:10:26.1807802s 153397 18:11:31.2642424s - | ReceiveTimestamp: 0xE3934C405AED45E9 - 13253566144355183000ns - 153397 18:09:04.3551830s 153397 18:11:31.2642582s - | TransmitTimestamp: 0xE3934C816FB7C279 - 13253566209436397700ns - 153397 18:10:09.4363977s 153397 18:11:31.2642750s - >-- Non-packet info: 153397 18:11:31.2642830s - | DestinationTimestamp: 153397 18:11:31.2642895s - 0xE3934CD3439E36B7153397 18:11:31.2642961s - - 13253566291264132900ns153397 18:11:31.2643031s - - 153397 18:11:31.2641329s 153397 18:11:31.2643119s - | RoundtripDelay: 2138000ns (0s) 153397 18:11:31.2643240s - | LocalClockOffset: -81826666200ns - 1:21.826666200s 153397 18:11:31.2643400s - \-- 153397 18:11:31.2643710s - Computing server signature: OLD:FALSE, RID:0000046F, format:0x1 153397 18:11:31.2650821s - ExpectedDelay:6537 ActualDelay:6713 (FILETIME units) 153397 18:11:31.2651024s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.132:123 153397 18:11:48.8654215s - W32TmServiceMain: timeout 153397 18:11:48.8654696s - ** NTP sample vector is empty. 153397 18:11:48.8654824s - No new NTP sample is available. 153397 18:11:48.8655057s - W32TmServiceMain: waiting 64.000s 153397 18:11:54.5847369s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:11:54.5847991s - ListeningThread -- response heard from 192.168.14.131:123 <- 192.168.14.135:123 153397 18:11:54.5849239s - /-- NTP Packet: 153397 18:11:54.5849293s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:11:54.5849374s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:11:54.5849433s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:11:54.5849560s - | RootDelay: 0x0000.000Cs - 0.000183105s; RootDispersion: 0x0010.0000s - 16s 153397 18:11:54.5849702s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:11:54.5849797s - | ReferenceTimestamp: 0xE3934C58C07814E4 - 13253566168751832300ns - 153397 18:09:28.7518323s 153397 18:11:54.5849942s - | OriginateTimestamp: 0xE3934CAA933DB7F1 - 13253566250575160500ns - 153397 18:10:50.5751605s 153397 18:11:54.5850089s - | ReceiveTimestamp: 0xE3934C58BE11FF06 - 13253566168742462100ns - 153397 18:09:28.7424621s 153397 18:11:54.5850246s - | TransmitTimestamp: 0xE3934C98C0782250 - 13253566232751833100ns - 153397 18:10:32.7518331s 153397 18:11:54.5850415s - >-- Non-packet info: 153397 18:11:54.5850494s - | DestinationTimestamp: 153397 18:11:54.5850561s - 0xE3934CEA95B52A18153397 18:11:54.5850627s - - 13253566314584795600ns153397 18:11:54.5850696s - - 153397 18:11:54.5847956s 153397 18:11:54.5850784s - | RoundtripDelay: 264100ns (0s) 153397 18:11:54.5850905s - | LocalClockOffset: -81832830400ns - 1:21.832830400s 153397 18:11:54.5851065s - \-- 153397 18:11:54.5851352s - Computing server signature: OLD:FALSE, RID:00000452, format:0x1 153397 18:11:54.5858004s - ExpectedDelay:6581 ActualDelay:6143 (FILETIME units) 153397 18:11:54.5858203s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.131:123 153397 18:12:06.7689559s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:12:06.7690204s - ListeningThread -- response heard from 192.168.14.134:123 <- 192.168.14.135:123 153397 18:12:06.7690424s - /-- NTP Packet: 153397 18:12:06.7690471s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:12:06.7690551s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:12:06.7690610s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:12:06.7690735s - | RootDelay: 0x0000.0010s - 0.000244141s; RootDispersion: 0x0010.0000s - 16s 153397 18:12:06.7690877s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:12:06.7690972s - | ReferenceTimestamp: 0xE3934C64F108D30D - 13253566180941540900ns - 153397 18:09:40.9415409s 153397 18:12:06.7691116s - | OriginateTimestamp: 0xE3934CB6C5393FBC - 13253566262770404800ns - 153397 18:11:02.7704048s 153397 18:12:06.7691263s - | ReceiveTimestamp: 0xE3934C64F169DD13 - 13253566180943021600ns - 153397 18:09:40.9430216s 153397 18:12:06.7691420s - | TransmitTimestamp: 0xE3934CA4F108E581 - 13253566244941542000ns - 153397 18:10:44.9415420s 153397 18:12:06.7691588s - >-- Non-packet info: 153397 18:12:06.7691667s - | DestinationTimestamp: 153397 18:12:06.7691732s - 0xE3934CF6C4DE4C51153397 18:12:06.7691799s - - 13253566326769017000ns153397 18:12:06.7691868s - - 153397 18:12:06.7690170s 153397 18:12:06.7691957s - | RoundtripDelay: 91800ns (0s) 153397 18:12:06.7692077s - | LocalClockOffset: -81827429100ns - 1:21.827429100s 153397 18:12:06.7692238s - \-- 153397 18:12:06.7692540s - Computing server signature: OLD:FALSE, RID:000004A0, format:0x1 153397 18:12:06.7699391s - ExpectedDelay:6553 ActualDelay:6367 (FILETIME units) 153397 18:12:06.7699594s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.134:123 153397 18:12:15.5488850s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:12:15.5489459s - ListeningThread -- response heard from 192.168.14.129:123 <- 192.168.14.135:123 153397 18:12:15.5489683s - /-- NTP Packet: 153397 18:12:15.5489734s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:12:15.5489815s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:12:15.5489873s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:12:15.5490004s - | RootDelay: 0x0000.0012s - 0.000274658s; RootDispersion: 0x0010.0000s - 16s 153397 18:12:15.5490147s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:12:15.5490241s - | ReferenceTimestamp: 0xE3934C6DB8C172FC - 13253566189721701800ns - 153397 18:09:49.7217018s 153397 18:12:15.5490386s - | OriginateTimestamp: 0xE3934CBF88BD0EE9 - 13253566271534134800ns - 153397 18:11:11.5341348s 153397 18:12:15.5490533s - | ReceiveTimestamp: 0xE3934C6DB51D43DD - 13253566189707477800ns - 153397 18:09:49.7074778s 153397 18:12:15.5490691s - | TransmitTimestamp: 0xE3934CADB8C1A3A3 - 13253566253721704700ns - 153397 18:10:53.7217047s 153397 18:12:15.5490861s - >-- Non-packet info: 153397 18:12:15.5490940s - | DestinationTimestamp: 153397 18:12:15.5491006s - 0xE3934CFF8C877D37153397 18:12:15.5491072s - - 13253566335548942400ns153397 18:12:15.5491141s - - 153397 18:12:15.5489424s 153397 18:12:15.5491230s - | RoundtripDelay: 580700ns (0s) 153397 18:12:15.5491350s - | LocalClockOffset: -81826947300ns - 1:21.826947300s 153397 18:12:15.5491510s - \-- 153397 18:12:15.5491834s - Computing server signature: OLD:FALSE, RID:00000454, format:0x1 153397 18:12:15.5499514s - ExpectedDelay:6255 ActualDelay:7171 (FILETIME units) 153397 18:12:15.5499731s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.129:123 153397 18:12:31.9642845s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:12:31.9643539s - ListeningThread -- response heard from 192.168.14.130:123 <- 192.168.14.135:123 153397 18:12:31.9643762s - /-- NTP Packet: 153397 18:12:31.9643810s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:12:31.9643890s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:12:31.9643948s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:12:31.9644072s - | RootDelay: 0x0000.0022s - 0.000518799s; RootDispersion: 0x0010.0000s - 16s 153397 18:12:31.9644214s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:12:31.9644308s - | ReferenceTimestamp: 0xE3934C7E20C8FAB0 - 13253566206128066700ns - 153397 18:10:06.1280667s 153397 18:12:31.9644453s - | OriginateTimestamp: 0xE3934CCFF2EDB7FE - 13253566287948939800ns - 153397 18:11:27.9489398s 153397 18:12:31.9644600s - | ReceiveTimestamp: 0xE3934C7E1D105766 - 13253566206113530600ns - 153397 18:10:06.1135306s 153397 18:12:31.9644758s - | TransmitTimestamp: 0xE3934CBE20C91C3E - 13253566270128068700ns - 153397 18:11:10.1280687s 153397 18:12:31.9644928s - >-- Non-packet info: 153397 18:12:31.9645007s - | DestinationTimestamp: 153397 18:12:31.9645073s - 0xE3934D0FF6DFACA3153397 18:12:31.9645139s - - 13253566351964350500ns153397 18:12:31.9645208s - - 153397 18:12:31.9643505s 153397 18:12:31.9645297s - | RoundtripDelay: 872600ns (0s) 153397 18:12:31.9645417s - | LocalClockOffset: -81835845500ns - 1:21.835845500s 153397 18:12:31.9645578s - \-- 153397 18:12:31.9645886s - Computing server signature: OLD:FALSE, RID:00000453, format:0x1 153397 18:12:31.9653012s - ExpectedDelay:6560 ActualDelay:6621 (FILETIME units) 153397 18:12:31.9653212s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.130:123 153397 18:12:35.2650600s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:12:35.2651255s - ListeningThread -- response heard from 192.168.14.132:123 <- 192.168.14.135:123 153397 18:12:35.2651477s - /-- NTP Packet: 153397 18:12:35.2651524s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:12:35.2651605s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:12:35.2651663s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:12:35.2651786s - | RootDelay: 0x0000.0023s - 0.000534058s; RootDispersion: 0x0010.0000s - 16s 153397 18:12:35.2651930s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:12:35.2652025s - | ReferenceTimestamp: 0xE3934C816FF88AC0 - 13253566209437386200ns - 153397 18:10:09.4373862s 153397 18:12:35.2652169s - | OriginateTimestamp: 0xE3934CD343D854C0 - 13253566291265019700ns - 153397 18:11:31.2650197s 153397 18:12:35.2652316s - | ReceiveTimestamp: 0xE3934C817014E493 - 13253566209437818800ns - 153397 18:10:09.4378188s 153397 18:12:35.2652474s - | TransmitTimestamp: 0xE3934CC16FF899DA - 13253566273437387100ns - 153397 18:11:13.4373871s 153397 18:12:35.2652642s - >-- Non-packet info: 153397 18:12:35.2652721s - | DestinationTimestamp: 153397 18:12:35.2652787s - 0xE3934D1343DF0761153397 18:12:35.2652901s - - 13253566355265121900ns153397 18:12:35.2652972s - - 153397 18:12:35.2651219s 153397 18:12:35.2653061s - | RoundtripDelay: 533900ns (0s) 153397 18:12:35.2653181s - | LocalClockOffset: -81827467800ns - 1:21.827467800s 153397 18:12:35.2653342s - \-- 153397 18:12:35.2655204s - Computing server signature: OLD:FALSE, RID:0000046F, format:0x1 153397 18:12:35.2662066s - ExpectedDelay:6719 ActualDelay:6510 (FILETIME units) 153397 18:12:35.2662267s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.132:123 153397 18:12:52.8755075s - W32TmServiceMain: timeout 153397 18:12:52.8755499s - ** NTP sample vector is empty. 153397 18:12:52.8755625s - No new NTP sample is available. 153397 18:12:52.8755796s - W32TmServiceMain: waiting 64.000s 153397 18:12:58.5997616s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:12:58.5998297s - ListeningThread -- response heard from 192.168.14.131:123 <- 192.168.14.135:123 153397 18:12:58.5998516s - /-- NTP Packet: 153397 18:12:58.5998566s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:12:58.5998646s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:12:58.5998705s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:12:58.5998828s - | RootDelay: 0x0000.000Cs - 0.000183105s; RootDispersion: 0x0010.0000s - 16s 153397 18:12:58.5998972s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:12:58.5999066s - | ReferenceTimestamp: 0xE3934C98C45067F7 - 13253566232766851900ns - 153397 18:10:32.7668519s 153397 18:12:58.5999209s - | OriginateTimestamp: 0xE3934CEA95F63C31 - 13253566314585788500ns - 153397 18:11:54.5857885s 153397 18:12:58.5999356s - | ReceiveTimestamp: 0xE3934C98C0DC2458 - 13253566232753359100ns - 153397 18:10:32.7533591s 153397 18:12:58.5999514s - | TransmitTimestamp: 0xE3934CD8C4507710 - 13253566296766852800ns - 153397 18:11:36.7668528s 153397 18:12:58.5999684s - >-- Non-packet info: 153397 18:12:58.5999763s - | DestinationTimestamp: 153397 18:12:58.5999829s - 0xE3934D2A998E35B8153397 18:12:58.5999895s - - 13253566378599826200ns153397 18:12:58.5999965s - - 153397 18:12:58.5998262s 153397 18:12:58.6000053s - | RoundtripDelay: 544000ns (0s) 153397 18:12:58.6000173s - | LocalClockOffset: -81832701400ns - 1:21.832701400s 153397 18:12:58.6000334s - \-- 153397 18:12:58.6000639s - Computing server signature: OLD:FALSE, RID:00000452, format:0x1 153397 18:12:58.6082815s - ExpectedDelay:6667 ActualDelay:81741 (FILETIME units) 153397 18:12:58.6083040s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.131:123 153397 18:13:10.7846997s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:13:10.7847909s - ListeningThread -- response heard from 192.168.14.134:123 <- 192.168.14.135:123 153397 18:13:10.7848137s - /-- NTP Packet: 153397 18:13:10.7848186s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:13:10.7848267s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:13:10.7848326s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:13:10.7848457s - | RootDelay: 0x0000.0010s - 0.000244141s; RootDispersion: 0x0010.0000s - 16s 153397 18:13:10.7848600s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:13:10.7848696s - | ReferenceTimestamp: 0xE3934CA4F0F18F23 - 13253566244941185900ns - 153397 18:10:44.9411859s 153397 18:13:10.7848841s - | OriginateTimestamp: 0xE3934CF6C518746B - 13253566326769904400ns - 153397 18:12:06.7699044s 153397 18:13:10.7848988s - | ReceiveTimestamp: 0xE3934CA4F165B3B8 - 13253566244942958100ns - 153397 18:10:44.9429581s 153397 18:13:10.7849146s - | TransmitTimestamp: 0xE3934CE4F50A350D - 13253566308957187000ns - 153397 18:11:48.9571870s 153397 18:13:10.7849314s - >-- Non-packet info: 153397 18:13:10.7849394s - | DestinationTimestamp: 153397 18:13:10.7849460s - 0xE3934D36C8E7CEB0153397 18:13:10.7849526s - - 13253566390784787100ns153397 18:13:10.7849596s - - 153397 18:13:10.7847871s 153397 18:13:10.7849684s - | RoundtripDelay: 653800ns (0s) 153397 18:13:10.7849804s - | LocalClockOffset: -81827273200ns - 1:21.827273200s 153397 18:13:10.7849965s - \-- 153397 18:13:10.7850314s - Computing server signature: OLD:FALSE, RID:000004A0, format:0x1 153397 18:13:10.7941633s - ExpectedDelay:12000 ActualDelay:90441 (FILETIME units) 153397 18:13:10.7942108s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.134:123 153397 18:13:19.5645143s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:13:19.5645867s - ListeningThread -- response heard from 192.168.14.129:123 <- 192.168.14.135:123 153397 18:13:19.5646089s - /-- NTP Packet: 153397 18:13:19.5646138s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:13:19.5646218s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:13:19.5646277s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:13:19.5646405s - | RootDelay: 0x0000.0012s - 0.000274658s; RootDispersion: 0x0010.0000s - 16s 153397 18:13:19.5646547s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:13:19.5646642s - | ReferenceTimestamp: 0xE3934CADC0DF901D - 13253566253753411300ns - 153397 18:10:53.7534113s 153397 18:13:19.5646788s - | OriginateTimestamp: 0xE3934CFF8CBFEF6E - 13253566335549803700ns - 153397 18:12:15.5498037s 153397 18:13:19.5646935s - | ReceiveTimestamp: 0xE3934CADB92513B5 - 13253566253723222000ns - 153397 18:10:53.7232220s 153397 18:13:19.5647093s - | TransmitTimestamp: 0xE3934CEDBCC7233F - 13253566317737413600ns - 153397 18:11:57.7374136s 153397 18:13:19.5647262s - >-- Non-packet info: 153397 18:13:19.5647341s - | DestinationTimestamp: 153397 18:13:19.5647407s - 0xE3934D3F9088864B153397 18:13:19.5647473s - - 13253566399564583200ns153397 18:13:19.5647543s - - 153397 18:13:19.5645832s 153397 18:13:19.5647631s - | RoundtripDelay: 587900ns (0s) 153397 18:13:19.5647751s - | LocalClockOffset: -81826875600ns - 1:21.826875600s 153397 18:13:19.5647912s - \-- 153397 18:13:19.5648224s - Computing server signature: OLD:FALSE, RID:00000454, format:0x1 153397 18:13:19.5733128s - ExpectedDelay:12000 ActualDelay:84328 (FILETIME units) 153397 18:13:19.5733473s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.129:123 153397 18:13:35.9806144s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:13:35.9806857s - ListeningThread -- response heard from 192.168.14.130:123 <- 192.168.14.135:123 153397 18:13:35.9807078s - /-- NTP Packet: 153397 18:13:35.9807128s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:13:35.9807208s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:13:35.9807266s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:13:35.9807393s - | RootDelay: 0x0000.0022s - 0.000518799s; RootDispersion: 0x0010.0000s - 16s 153397 18:13:35.9807535s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:13:35.9807629s - | ReferenceTimestamp: 0xE3934CBE2902A4F5 - 13253566270160196600ns - 153397 18:11:10.1601966s 153397 18:13:35.9807775s - | OriginateTimestamp: 0xE3934D0FF719F2F0 - 13253566351965239700ns - 153397 18:12:31.9652397s 153397 18:13:35.9807922s - | ReceiveTimestamp: 0xE3934CBE212C9306 - 13253566270129586400ns - 153397 18:11:10.1295864s 153397 18:13:35.9808080s - | TransmitTimestamp: 0xE3934CFE24EA330F - 13253566334144198600ns - 153397 18:12:14.1441986s 153397 18:13:35.9808248s - >-- Non-packet info: 153397 18:13:35.9808326s - | DestinationTimestamp: 153397 18:13:35.9808393s - 0xE3934D4FFB0DFD18153397 18:13:35.9808459s - - 13253566415980682200ns153397 18:13:35.9808529s - - 153397 18:13:35.9806822s 153397 18:13:35.9808618s - | RoundtripDelay: 830300ns (0s) 153397 18:13:35.9808738s - | LocalClockOffset: -81836068400ns - 1:21.836068400s 153397 18:13:35.9808899s - \-- 153397 18:13:35.9809213s - Computing server signature: OLD:FALSE, RID:00000453, format:0x1 153397 18:13:35.9837619s - ExpectedDelay:12000 ActualDelay:27870 (FILETIME units) 153397 18:13:35.9837845s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.130:123 153397 18:13:39.2657973s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:13:39.2658667s - ListeningThread -- response heard from 192.168.14.132:123 <- 192.168.14.135:123 153397 18:13:39.2658885s - /-- NTP Packet: 153397 18:13:39.2658932s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:13:39.2659013s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:13:39.2659071s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:13:39.2659195s - | RootDelay: 0x0000.001Fs - 0.000473022s; RootDispersion: 0x0010.0000s - 16s 153397 18:13:39.2659339s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:13:39.2659433s - | ReferenceTimestamp: 0xE3934CC170269164 - 13253566273438088500ns - 153397 18:11:13.4380885s 153397 18:13:39.2659576s - | OriginateTimestamp: 0xE3934D134424A92C - 13253566355266184400ns - 153397 18:12:35.2661844s 153397 18:13:39.2659723s - | ReceiveTimestamp: 0xE3934CC1705D4702 - 13253566273438923300ns - 153397 18:11:13.4389233s 153397 18:13:39.2659880s - | TransmitTimestamp: 0xE3934D0170269ED0 - 13253566337438089300ns - 153397 18:12:17.4380893s 153397 18:13:39.2660049s - >-- Non-packet info: 153397 18:13:39.2660128s - | DestinationTimestamp: 153397 18:13:39.2660193s - 0xE3934D53440F9AA7153397 18:13:39.2660259s - - 13253566419265863100ns153397 18:13:39.2660329s - - 153397 18:13:39.2658631s 153397 18:13:39.2660417s - | RoundtripDelay: 512700ns (0s) 153397 18:13:39.2660537s - | LocalClockOffset: -81827517400ns - 1:21.827517400s 153397 18:13:39.2660698s - \-- 153397 18:13:39.2661009s - Computing server signature: OLD:FALSE, RID:0000046F, format:0x1 153397 18:13:39.2668130s - ExpectedDelay:12000 ActualDelay:6713 (FILETIME units) 153397 18:13:39.2668333s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.132:123 153397 18:13:56.8896051s - W32TmServiceMain: timeout 153397 18:13:56.8896594s - ** NTP sample vector is empty. 153397 18:13:56.8896718s - No new NTP sample is available. 153397 18:13:56.8896898s - W32TmServiceMain: waiting 64.000s 153397 18:14:02.6127602s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:14:02.6128589s - ListeningThread -- response heard from 192.168.14.131:123 <- 192.168.14.135:123 153397 18:14:02.6128829s - /-- NTP Packet: 153397 18:14:02.6128879s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:14:02.6128960s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:14:02.6129018s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:14:02.6129141s - | RootDelay: 0x0000.000Cs - 0.000183105s; RootDispersion: 0x0010.0000s - 16s 153397 18:14:02.6129283s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:14:02.6129378s - | ReferenceTimestamp: 0xE3934CD8C7A22F6A - 13253566296779818500ns - 153397 18:11:36.7798185s 153397 18:14:02.6129524s - | OriginateTimestamp: 0xE3934D2A99C92578 - 13253566378600725500ns - 153397 18:12:58.6007255s 153397 18:14:02.6129670s - | ReceiveTimestamp: 0xE3934CD8C69B3728 - 13253566296775805900ns - 153397 18:11:36.7758059s 153397 18:14:02.6129827s - | TransmitTimestamp: 0xE3934D18C7A23CD6 - 13253566360779819300ns - 153397 18:12:40.7798193s 153397 18:14:02.6129996s - >-- Non-packet info: 153397 18:14:02.6130075s - | DestinationTimestamp: 153397 18:14:02.6130141s - 0xE3934D6A9CE40852153397 18:14:02.6130206s - - 13253566442612854500ns153397 18:14:02.6130276s - - 153397 18:14:02.6128545s 153397 18:14:02.6130365s - | RoundtripDelay: 8115600ns (0s) 153397 18:14:02.6130485s - | LocalClockOffset: -81828977400ns - 1:21.828977400s 153397 18:14:02.6130646s - \-- 153397 18:14:02.6130943s - Computing server signature: OLD:FALSE, RID:00000452, format:0x1 153397 18:14:02.6221835s - ExpectedDelay:12000 ActualDelay:90585 (FILETIME units) 153397 18:14:02.6222058s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.131:123 153397 18:14:14.7895293s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:14:14.7895849s - ListeningThread -- response heard from 192.168.14.134:123 <- 192.168.14.135:123 153397 18:14:14.7896073s - /-- NTP Packet: 153397 18:14:14.7896118s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:14:14.7896198s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:14:14.7896256s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:14:14.7896380s - | RootDelay: 0x0000.0010s - 0.000244141s; RootDispersion: 0x0010.0000s - 16s 153397 18:14:14.7896522s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:14:14.7896616s - | ReferenceTimestamp: 0xE3934CE4F64E4A0F - 13253566308962132100ns - 153397 18:11:48.9621321s 153397 18:14:14.7896760s - | OriginateTimestamp: 0xE3934D36C9461B6D - 13253566390786226000ns - 153397 18:13:10.7862260s 153397 18:14:14.7896907s - | ReceiveTimestamp: 0xE3934CE4F79E492B - 13253566308967259000ns - 153397 18:11:48.9672590s 153397 18:14:14.7897064s - | TransmitTimestamp: 0xE3934D24F64E5AD6 - 13253566372962133100ns - 153397 18:12:52.9621331s 153397 18:14:14.7897233s - >-- Non-packet info: 153397 18:14:14.7897312s - | DestinationTimestamp: 153397 18:14:14.7897378s - 0xE3934D76CA2201B2153397 18:14:14.7897444s - - 13253566454789581400ns153397 18:14:14.7897514s - - 153397 18:14:14.7895814s 153397 18:14:14.7897602s - | RoundtripDelay: 8481300ns (0s) 153397 18:14:14.7897722s - | LocalClockOffset: -81823207600ns - 1:21.823207600s 153397 18:14:14.7897883s - \-- 153397 18:14:14.7898173s - Computing server signature: OLD:FALSE, RID:000004A0, format:0x1 153397 18:14:14.7955655s - ExpectedDelay:12000 ActualDelay:56950 (FILETIME units) 153397 18:14:14.7955880s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.134:123 153397 18:14:23.5803321s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:14:23.5803986s - ListeningThread -- response heard from 192.168.14.129:123 <- 192.168.14.135:123 153397 18:14:23.5804205s - /-- NTP Packet: 153397 18:14:23.5804254s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:14:23.5804335s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:14:23.5804393s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:14:23.5804516s - | RootDelay: 0x0000.0012s - 0.000274658s; RootDispersion: 0x0010.0000s - 16s 153397 18:14:23.5804659s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:14:23.5804753s - | ReferenceTimestamp: 0xE3934CEDC0D22E35 - 13253566317753207100ns - 153397 18:11:57.7532071s 153397 18:14:23.5804897s - | OriginateTimestamp: 0xE3934D3F90E68280 - 13253566399566017300ns - 153397 18:13:19.5660173s 153397 18:14:23.5805043s - | ReceiveTimestamp: 0xE3934CEDBF240090 - 13253566317746643100ns - 153397 18:11:57.7466431s 153397 18:14:23.5805201s - | TransmitTimestamp: 0xE3934D2DC0D2531E - 13253566381753209300ns - 153397 18:13:01.7532093s 153397 18:14:23.5805369s - >-- Non-packet info: 153397 18:14:23.5805448s - | DestinationTimestamp: 153397 18:14:23.5805514s - 0xE3934D7F9494C7A2153397 18:14:23.5805580s - - 13253566463580395200ns153397 18:14:23.5805650s - - 153397 18:14:23.5803952s 153397 18:14:23.5805739s - | RoundtripDelay: 7811700ns (0s) 153397 18:14:23.5805859s - | LocalClockOffset: -81823280000ns - 1:21.823280000s 153397 18:14:23.5806020s - \-- 153397 18:14:23.5807312s - Computing server signature: OLD:FALSE, RID:00000454, format:0x1 153397 18:14:23.5814641s - ExpectedDelay:12000 ActualDelay:6956 (FILETIME units) 153397 18:14:23.5814842s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.129:123 153397 18:14:39.9968946s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:14:39.9969634s - ListeningThread -- response heard from 192.168.14.130:123 <- 192.168.14.135:123 153397 18:14:39.9969857s - /-- NTP Packet: 153397 18:14:39.9969906s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:14:39.9969986s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:14:39.9970044s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:14:39.9970168s - | RootDelay: 0x0000.0022s - 0.000518799s; RootDispersion: 0x0010.0000s - 16s 153397 18:14:39.9970311s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:14:39.9970406s - | ReferenceTimestamp: 0xE3934CFE290D844D - 13253566334160362500ns - 153397 18:12:14.1603625s 153397 18:14:39.9970551s - | OriginateTimestamp: 0xE3934D4FFB6BF444 - 13253566415982116000ns - 153397 18:13:35.9821160s 153397 18:14:39.9970699s - | ReceiveTimestamp: 0xE3934CFE25DBAC63 - 13253566334147883200ns - 153397 18:12:14.1478832s 153397 18:14:39.9970857s - | TransmitTimestamp: 0xE3934D3E290DA42D - 13253566398160364400ns - 153397 18:13:18.1603644s 153397 18:14:39.9971026s - >-- Non-packet info: 153397 18:14:39.9971105s - | DestinationTimestamp: 153397 18:14:39.9971171s - 0xE3934D8FFF38C395153397 18:14:39.9971237s - - 13253566479996959900ns153397 18:14:39.9971307s - - 153397 18:14:39.9969599s 153397 18:14:39.9971395s - | RoundtripDelay: 2362700ns (0s) 153397 18:14:39.9971516s - | LocalClockOffset: -81835414100ns - 1:21.835414100s 153397 18:14:39.9971677s - \-- 153397 18:14:39.9971986s - Computing server signature: OLD:FALSE, RID:00000453, format:0x1 153397 18:14:40.0036308s - ExpectedDelay:12000 ActualDelay:63752 (FILETIME units) 153397 18:14:40.0036556s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.130:123 153397 18:14:43.2661656s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:14:43.2662344s - ListeningThread -- response heard from 192.168.14.132:123 <- 192.168.14.135:123 153397 18:14:43.2662565s - /-- NTP Packet: 153397 18:14:43.2662614s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:14:43.2662694s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:14:43.2662753s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:14:43.2662877s - | RootDelay: 0x0000.0001s - 1.52588e-005s; RootDispersion: 0x0010.0000s - 16s 153397 18:14:43.2663025s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:14:43.2663120s - | ReferenceTimestamp: 0xE3934D01703D17B8 - 13253566337438432200ns - 153397 18:12:17.4384322s 153397 18:14:43.2663264s - | OriginateTimestamp: 0xE3934D53446D810C - 13253566419267295900ns - 153397 18:13:39.2672959s 153397 18:14:43.2663410s - | ReceiveTimestamp: 0xE3934D017085EDEB - 13253566337439543600ns - 153397 18:12:17.4395436s 153397 18:14:43.2663568s - | TransmitTimestamp: 0xE3934D41703D2A2C - 13253566401438433300ns - 153397 18:13:21.4384333s 153397 18:14:43.2663737s - >-- Non-packet info: 153397 18:14:43.2663816s - | DestinationTimestamp: 153397 18:14:43.2663882s - 0xE3934D934427B3A3153397 18:14:43.2663948s - - 13253566483266230800ns153397 18:14:43.2664018s - - 153397 18:14:43.2662308s 153397 18:14:43.2664106s - | RoundtripDelay: 45200ns (0s) 153397 18:14:43.2664226s - | LocalClockOffset: -81827774900ns - 1:21.827774900s 153397 18:14:43.2664386s - \-- 153397 18:14:43.2664699s - Computing server signature: OLD:FALSE, RID:0000046F, format:0x1 153397 18:14:43.2671760s - ExpectedDelay:12000 ActualDelay:6661 (FILETIME units) 153397 18:14:43.2671963s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.132:123 153397 18:15:00.9050075s - W32TmServiceMain: timeout 153397 18:15:00.9050580s - ** NTP sample vector is empty. 153397 18:15:00.9050705s - No new NTP sample is available. 153397 18:15:00.9050885s - W32TmServiceMain: waiting 64.000s 153397 18:15:06.6204473s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:15:06.6205118s - ListeningThread -- response heard from 192.168.14.131:123 <- 192.168.14.135:123 153397 18:15:06.6205340s - /-- NTP Packet: 153397 18:15:06.6205385s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:15:06.6205465s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:15:06.6205523s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:15:06.6205647s - | RootDelay: 0x0000.000Cs - 0.000183105s; RootDispersion: 0x0010.0000s - 16s 153397 18:15:06.6205791s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:15:06.6205885s - | ReferenceTimestamp: 0xE3934D18CD682A8B - 13253566360802370700ns - 153397 18:12:40.8023707s 153397 18:15:06.6206031s - | OriginateTimestamp: 0xE3934D6A9D4211F3 - 13253566442614289400ns - 153397 18:14:02.6142894s 153397 18:15:06.6206178s - | ReceiveTimestamp: 0xE3934D18CA275254 - 13253566360789662500ns - 153397 18:12:40.7896625s 153397 18:15:06.6206335s - | TransmitTimestamp: 0xE3934D58C9913978 - 13253566424787372200ns - 153397 18:13:44.7873722s 153397 18:15:06.6206503s - >-- Non-packet info: 153397 18:15:06.6206582s - | DestinationTimestamp: 153397 18:15:06.6206648s - 0xE3934DAA9ED9A1C7153397 18:15:06.6206714s - - 13253566506620508300ns153397 18:15:06.6206784s - - 153397 18:15:06.6205083s 153397 18:15:06.6206872s - | RoundtripDelay: 8509200ns (0s) 153397 18:15:06.6206993s - | LocalClockOffset: -81828881500ns - 1:21.828881500s 153397 18:15:06.6207154s - \-- 153397 18:15:06.6207435s - Computing server signature: OLD:FALSE, RID:00000452, format:0x1 153397 18:15:06.6213333s - ExpectedDelay:12000 ActualDelay:5579 (FILETIME units) 153397 18:15:06.6213531s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.131:123 153397 18:15:18.7896127s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:15:18.7896775s - ListeningThread -- response heard from 192.168.14.134:123 <- 192.168.14.135:123 153397 18:15:18.7896994s - /-- NTP Packet: 153397 18:15:18.7897041s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:15:18.7897122s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:15:18.7897180s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:15:18.7897302s - | RootDelay: 0x0000.0010s - 0.000244141s; RootDispersion: 0x0010.0000s - 16s 153397 18:15:18.7897446s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:15:18.7897540s - | ReferenceTimestamp: 0xE3934D24FA6D0EF7 - 13253566372978226600ns - 153397 18:12:52.9782266s 153397 18:15:18.7897685s - | OriginateTimestamp: 0xE3934D76CA7FC689 - 13253566454791012200ns - 153397 18:14:14.7910122s 153397 18:15:18.7897832s - | ReceiveTimestamp: 0xE3934D24F7F8DCF6 - 13253566372968641100ns - 153397 18:12:52.9686411s 153397 18:15:18.7897989s - | TransmitTimestamp: 0xE3934D64F65492FF - 13253566436962228000ns - 153397 18:13:56.9622280s 153397 18:15:18.7898158s - >-- Non-packet info: 153397 18:15:18.7898237s - | DestinationTimestamp: 153397 18:15:18.7898303s - 0xE3934DB6CA281197153397 18:15:18.7898368s - - 13253566518789673900ns153397 18:15:18.7898438s - - 153397 18:15:18.7896739s 153397 18:15:18.7898526s - | RoundtripDelay: 5074800ns (0s) 153397 18:15:18.7898647s - | LocalClockOffset: -81824908500ns - 1:21.824908500s 153397 18:15:18.7898808s - \-- 153397 18:15:18.7899094s - Computing server signature: OLD:FALSE, RID:000004A0, format:0x1 153397 18:15:18.7972446s - ExpectedDelay:12000 ActualDelay:72878 (FILETIME units) 153397 18:15:18.7972675s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.134:123 153397 18:15:27.5960721s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:15:27.5961348s - ListeningThread -- response heard from 192.168.14.129:123 <- 192.168.14.135:123 153397 18:15:27.5961569s - /-- NTP Packet: 153397 18:15:27.5961616s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:15:27.5961696s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:15:27.5961754s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:15:27.5961879s - | RootDelay: 0x0000.0000s - unspecified; RootDispersion: 0x0010.0000s - 16s 153397 18:15:27.5962010s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:15:27.5962105s - | ReferenceTimestamp: 0xE3934D2DC4DD3275 - 13253566381769000200ns - 153397 18:13:01.7690002s 153397 18:15:27.5962248s - | OriginateTimestamp: 0xE3934D7F94F90108 - 13253566463581924500ns - 153397 18:14:23.5819245s 153397 18:15:27.5962395s - | ReceiveTimestamp: 0xE3934D2DC1370F60 - 13253566381754746400ns - 153397 18:13:01.7547464s 153397 18:15:27.5962553s - | TransmitTimestamp: 0xE3934D6DC4DD590C - 13253566445769002500ns - 153397 18:14:05.7690025s 153397 18:15:27.5962721s - >-- Non-packet info: 153397 18:15:27.5962800s - | DestinationTimestamp: 153397 18:15:27.5962865s - 0xE3934DBF989C0F95153397 18:15:27.5962931s - - 13253566527596131300ns153397 18:15:27.5963001s - - 153397 18:15:27.5961313s 153397 18:15:27.5963089s - | RoundtripDelay: -49300ns (0s) 153397 18:15:27.5963209s - | LocalClockOffset: -81827153400ns - 1:21.827153400s 153397 18:15:27.5963370s - \-- 153397 18:15:27.5963653s - Computing server signature: OLD:FALSE, RID:00000454, format:0x1 153397 18:15:27.6011775s - ExpectedDelay:12000 ActualDelay:47754 (FILETIME units) 153397 18:15:27.6012002s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.129:123 153397 18:15:42.0676671s - RPC Caller is IT-NetX\Administrator (S-1-5-21-2493131093-3148882283-627738068-500) 153397 18:15:42.0677174s - RPC Call Attribute is local=1, kernel=0, session=0, authentication=6, protocol=2, OpNum=6 153397 18:15:42.0677520s - RPC Call - Query Status 153397 18:15:44.0134120s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:15:44.0134808s - ListeningThread -- response heard from 192.168.14.130:123 <- 192.168.14.135:123 153397 18:15:44.0135027s - /-- NTP Packet: 153397 18:15:44.0135075s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:15:44.0135155s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:15:44.0135212s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:15:44.0135342s - | RootDelay: 0x0000.0022s - 0.000518799s; RootDispersion: 0x0010.0000s - 16s 153397 18:15:44.0135483s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:15:44.0135578s - | ReferenceTimestamp: 0xE3934D3E2D3764F1 - 13253566398176626500ns - 153397 18:13:18.1766265s 153397 18:15:44.0135722s - | OriginateTimestamp: 0xE3934D8FFF96B40C - 13253566479998393300ns - 153397 18:14:39.9983933s 153397 18:15:44.0135869s - | ReceiveTimestamp: 0xE3934D3E2AE52589 - 13253566398167559000ns - 153397 18:13:18.1675590s 153397 18:15:44.0136026s - | TransmitTimestamp: 0xE3934D7E2D37882C - 13253566462176628600ns - 153397 18:14:22.1766286s 153397 18:15:44.0136194s - >-- Non-packet info: 153397 18:15:44.0136273s - | DestinationTimestamp: 153397 18:15:44.0136338s - 0xE3934DD003733F92153397 18:15:44.0136404s - - 13253566544013477300ns153397 18:15:44.0136472s - - 153397 18:15:44.0134773s 153397 18:15:44.0136560s - | RoundtripDelay: 6014400ns (0s) 153397 18:15:44.0136680s - | LocalClockOffset: -81833841500ns - 1:21.833841500s 153397 18:15:44.0136840s - \-- 153397 18:15:44.0137394s - Computing server signature: OLD:FALSE, RID:00000453, format:0x1 153397 18:15:44.0176846s - ExpectedDelay:12000 ActualDelay:38944 (FILETIME units) 153397 18:15:44.0177075s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.130:123 153397 18:15:44.6096535s - RPC Caller is IT-NetX\Administrator (S-1-5-21-2493131093-3148882283-627738068-500) 153397 18:15:44.6096941s - RPC Call Attribute is local=1, kernel=0, session=0, authentication=6, protocol=2, OpNum=0 153397 18:15:44.6097242s - RPC Call - Rediscover 153397 18:15:44.6097385s - W32TmServiceMain: Network Topology Change (RPC) 153397 18:15:44.6097512s - TimeProvCommand([NtpClient], TPC_NetTopoChange) called. 153397 18:15:44.6097886s - NtpProvider: Network Topology Change 153397 18:15:44.6098701s - Peers reset: p-p:1 a-p:1 a-x:0 153397 18:15:44.6100988s - NtpProvider: Created 2 sockets (0 listen-only): [::]:123<0x0>, 0.0.0.0:123<0x0> 153397 18:15:44.6101368s - StartListeningThread completed! 153397 18:15:44.6101526s - PeerPollingThread: waiting 360.259s 153397 18:15:44.6101756s - StartPeerPollingThread completed! 153397 18:15:44.6101893s - TimeProvCommand([NtpServer], TPC_NetTopoChange) called. 153397 18:15:44.6101924s - PeerPollingThread: PeerListUpdated 153397 18:15:44.6102052s - W32TmServiceMain: waiting 20.295s 153397 18:15:44.6102174s - PeerPollingThread: waiting 360.258s 153397 18:15:44.6102248s - W32TmServiceMain: ********** Time Slip Notification ********** 153397 18:15:44.6102866s - ClockDispln TimeSlip:TimeSlip LastUTC:4919584 SetUnsync: LI:0 S:1 RDl:0 RDs:100000000 TSF:0x0 153397 18:15:44.6104115s - TimeProvCommand([NtpClient], TPC_TimeJumped) called. 153397 18:15:44.6104351s - TimeProvCommand([NtpServer], TPC_TimeJumped) called. 153397 18:15:44.6104467s - PeerPollingThread: PeerListUpdated 153397 18:15:44.6104556s - W32TmServiceMain: waiting i16.000s (64.000s) 153397 18:15:44.6104600s - ClockDispln: we're a reliable time service with no time source: LS: 0, TN: 864000000000, WAIT: 86400000 153397 18:15:44.6104700s - Resolving manual peer: ntp.metas.ch,0x8 153397 18:15:44.6281133s - Create new peer associations: #1 153397 18:15:44.6281514s - Association: (Local) 0.0.0.0:123 => 195.176.26.206:123 (Remote) 153397 18:15:44.6281720s - Created reachability group: ( 153397 18:15:44.6281847s - 195.176.26.206:123, 153397 18:15:44.6281955s - ) 153397 18:15:44.6282312s - PollIntervalChange(): clear: host 0 = max 15 153397 18:15:44.6282342s - PeerPollingThread: PeerListUpdated 153397 18:15:44.6282572s - PeerPollingThread: waiting 0.000s 153397 18:15:44.6282963s - Reachability: Attempting to contact peer ntp.metas.ch,0x8 (ntp.m|0x8|0.0.0.0:123->195.176.26.206:123). 153397 18:15:44.6282969s - PeerPollingThread: WaitTimeout 153397 18:15:44.6283130s - Polling peer ntp.metas.ch,0x8 (ntp.m|0x8|0.0.0.0:123->195.176.26.206:123) 153397 18:15:44.6283278s - Sending packet to ntp.metas.ch,0x8 (ntp.m|0x8|0.0.0.0:123->195.176.26.206:123) in Win2K detect mode, stage 1. 153397 18:15:44.6283599s - PeerPollingThread: waiting forever 153397 18:15:44.6284263s - PollIntervalChange(ntp.metas.ch,0x8 (ntp.m|0x8|0.0.0.0:123->195.176.26.206:123)): reclamp: 15 -> 6 (min=4, max=15, sys=6) 153397 18:15:44.6284437s - Peer poll: Max:64.0000000s Cur:00.0000000s 153397 18:15:44.6284593s - PeerPollingThread: waiting 64.000s 153397 18:15:47.2667268s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123) 153397 18:15:47.2667834s - ListeningThread -- response heard from 192.168.14.132:123 <- 192.168.14.135:123 153397 18:15:47.2668058s - /-- NTP Packet: 153397 18:15:47.2668104s - | LeapIndicator: 0 - no warning; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0x1B 153397 18:15:47.2668184s - | Stratum: 2 - secondary reference (syncd by (S)NTP) 153397 18:15:47.2668242s - | Poll Interval: 6 - 64s; Precision: -23 - 119.209ns per tick 153397 18:15:47.2668364s - | RootDelay: 0x0000.0001s - 1.52588e-005s; RootDispersion: 0x0010.0000s - 16s 153397 18:15:47.2668512s - | ReferenceClockIdentifier: 0xC0A80E87 - source IP: 192.168.14.135 153397 18:15:47.2668606s - | ReferenceTimestamp: 0xE3934D4170611772 - 13253566401438981500ns - 153397 18:13:21.4389815s 153397 18:15:47.2668750s - | OriginateTimestamp: 0xE3934D934485AE2A - 13253566483267664800ns - 153397 18:14:43.2676648s 153397 18:15:47.2668897s - | ReceiveTimestamp: 0xE3934D41709C403D - 13253566401439884200ns - 153397 18:13:21.4398842s 153397 18:15:47.2669055s - | TransmitTimestamp: 0xE3934D8170612839 - 13253566465438982500ns - 153397 18:14:25.4389825s 153397 18:15:47.2669224s - >-- Non-packet info: 153397 18:15:47.2669303s - | DestinationTimestamp: 153397 18:15:47.2669369s - 0xE3934DD3444BAE54153397 18:15:47.2669435s - - 13253566547266779800ns153397 18:15:47.2669505s - - 153397 18:15:47.2667798s 153397 18:15:47.2669593s - | RoundtripDelay: 16700ns (0s) 153397 18:15:47.2669713s - | LocalClockOffset: -81827788900ns - 1:21.827788900s 153397 18:15:47.2669873s - \-- 153397 18:15:47.2670159s - Computing server signature: OLD:FALSE, RID:0000046F, format:0x1 153397 18:15:47.2677690s - ExpectedDelay:12000 ActualDelay:6753 (FILETIME units) 153397 18:15:47.2677895s - TransmitResponse: sent 0.0.0.0:123(192.168.14.135:123)->192.168.14.132:123 153397 18:16:00.5998501s - W32TmServiceMain: timeout 153397 18:16:00.5998972s - Sample Prepared at 132535665605998910 for peer ntp.metas.ch,0x8 (ntp.m|0x8|0.0.0.0:123->195.176.26.206:123) 153397 18:16:00.5999103s - ** NTP sample vector is empty. 153397 18:16:00.5999211s - No new NTP sample is available. 153397 18:16:00.5999446s - W32TmServiceMain: waiting 64.000s --------------------------------
  18. Nein, ist nicht aktiviert (habe ich bei der Eröffnung auch irgendwo erwähnt). Wenn aktiviert, würde die Ausgabe via w32tm /query /status anders aussehen (NICHT: Local CMOS Clock). Auch das habe ich schon mehrmals gemacht (ebenfalls im Post von mir schon erwähnt worden). Ja leider meistens, meistens ist eben nicht immer und ich gehöre anscheinend zu der Minderheit, wo das leider NICHT geholfen hat :-( Norbert, kennst Du das Gefühl: Du weisst, eigentlich stimmt der Eintrag, aber wie in meinem Fall funktioniert auf Biegen und Brechen der Sync zwischen meinem einzigen DC in der Domain und der externen NTP Quelle ntp.metas.ch (ist auch ein Pool) einfach nicht. Ok, wie weiter? Mal was neues ausprobieren? Genau dieser Device bin ich gefolgt Dachte, man hat ja die Möglichkeit, mehrere NTP Einträge in der GPO einzutragen was sogar dringend empfohlen wird, wenn es sich beim FQDN nicht um einen Pool handelt (denn ein solcher beinhaltet ja schon zig NTP Hosts in der Farm). Tja, aber eben, wenn was nicht geht wie bei mir, habe ich halt aus Testzwecken noch andere NTP Alias in der GPO eingetragen, geholfen hat es jedoch auch nicht :-(
  19. @cj_berlin Danke für die Inputs. LOG ist aktiviert. - Öffne ich das LOG und scrolle an das End, ist das erste wo mir auffällt: Die LOGIN Zeit ist etwas mehr als 1 Stunde verzögert? - Mittlerweile sind 3 verschiedene NTP Pools in der GPO hinterlegt time.cyberlink.ch,0x8', 'ch.pool.ntp.org,0x8', 'ntp.metas.ch,0x8 (aber jeweils ohne Komma zwischen den FQDNs. Ob hier 0x8 der richtige Wert ist, oder 0x1 oder sonst was, wiess ich nicht. - Die GPO Einstellungen sind tatsächlich in der Registry korrekt - unter HKLM\SOFTWARE\Policies\Microsoft\W32Time\ - PhaseCorrectRate war in der GPO wie auch in der Registry mit dem Wert 1 gesetzt und nun von mir auf 7 geändert - das LOG zeigt z.B. bei allen NTP Pools folgende Zeile (von Beginn reclamp an) und da weiss ich nicht genau, ob das was gutes oder was schlechtes verheisst? 153397 13:12:37.8877616s - PollIntervalChange(ch.pool.ntp.org,0x8 (ntp.m|0x8|0.0.0.0:123->162.159.200.1:123)): reclamp: 15 -> 6 (min=4, max=15, sys=6) Dazu kann ich nur sagen, dass ich beim Rechechieren im Internet sicher 2 Posts gefunden habe, welche auch Synchronisierungsprobleme in Bezug NTP Server hatten und da kam unteranderem die Zeile bzw. die Werte reclamp: 15 -> 6 (min=4, max=15, sys=6) auch vor, insofern müsste ich nun deuten, dass das nichts gutes verheisst? Als ich in der GPO die NTP Pools erweitert habe und z.B. den Pool time.cyberlink.ch,0x8 ergänzt habe, aber in der Firewall als Ziel diesen FQDN noch nicht freigeschaltet hatte, stand im LOG: NtpClient has not received response from server time.cyberlink.ch,0x8 Als ich den FQDN dann in der Firewall auch noch hinzufügte, erschien diese Meldung nicht mehr, was somit bedeutet, dass die externe NTP Quelle kontaktiert werden kann. Du wolltest noch die allgemeinen Einstellungen in meiner GPO? siehe Anhang (Bild) @Sunny61 Danke auch Dir für die Inputs. Den Link von Dir habe ich durchgelesen Und: Was Du meinst ist wohl das Announceflags, dessen Wert von 10 auf 5 geändert werden sollte. Habe ich gemacht. Doch Leider zeigt bei mir w32tm /query /status noch immer Source: Local CMOS Clock an :-( NTP Security Bin während meiner Analyse, warum und wieso mein DC noch immer nicht sich mit einer externen NTP Quelle synchronisieren will, auf diesen interessanten Artikel hier gestossen. Nur so am Rande erwähnt https://www.tec-bite.ch/wie-man-ntp-richtig-benutzt-und-warum-das-fuer-die-security-wichtig-ist-teil-1/
  20. Hi all Wende mich an euch, weil ich meiner Ansicht nach ein sehr "spezielles Phänomen" festgestellt habe und wirklich bis jetzt keine Lösung hierfür fand. Als ich auf meinem Windows 10 NB arbeitete, merkte ich plötzlich, dass die Systemzeit ziemlich massiv zur "richtigen" Zeit auf meinem Smartphone abwich (rund 10 Minuten) und begann natürlich dann mit der Analyse (Fehlersuche) und merkte bald folgendes: Problem In meiner virtualisierten Umgebung auf Hyper-V basierend, existieren zwei Hyper-V Hosts, wobei zurzeit alle VMs zurzeit nur auf einem Hyper-V Host laufen. Unteranderem auch 1 DC auf Server 2016 Std. Der DC mit Server 2016 zeigt beim Befehl w32tm /query /status bei der zweitletzten Zeile folgendes an: Source: Local CMOS Clock anstatt den externen NTP Server ntp.metas.ch, welchen ich in der GPO auf die OU Domain Controllers verlinkt habe. Die GPO Einstellungen werden aus meiner Sicht einfach NICHT angewendet, zumindest werden die entsprechenden Registry Einträge NICHT aktualisiert, was ich sehr komisch finde und für mich nicht nachvollziehbar ist. Denn die GPO habe ich mit einem WMI Filter wie weiter unten im Beitrag zu lesen, gemäss Artikel erstellt und mit der GPO verlinkt habe. Den WMI Befehl habe ich via CMD mit dem Befehl wbemtest auf seine Richtigkeit überprüft und die Ausgabe des WMI Befehls ergab den Hostnamen des DCs. Bemerkung zu ntp.metas.ch Der Alias ntp.metas.ch müsste gemäss Betreiber Webseite https://www.metas.ch/metas/de/home/fabe/zeit-und-frequenz/time-dissemination.html gültig sein und funktionieren. Ein Ping auf ntp.metas.ch bestätigt zumindest, dass der Server erreichbar ist, ob der Dienst dann auch funktioniert, sagt PING natürlich nicht Die GPO mit den NTP Einstellungen habe ich so eingerichtet wie unter folgender URL ersichtlich https://www.windowspro.de/wolfgang-sommergut/zeiteinstellungen-windows-domaenen-ueber-ntp-konfigurieren Wie in diesem Artikel erwähnt, habe ich in den VM Einstellungen die Zeit Synchronisation mit dem Hyper-V Host deaktiviert, sprich, den Hacken rausgenommen. Fazit - Meiner Ansicht nach lässt meine Sophos XG Firewall den ausgehenden NTP Verkehr auf Port 123 zu. - w32tm /query /configuration zeigt mir auch sehr deutlich, dass die Einstellungen der GPO, welche auf den DC wirken, konfiguriert wurden - GPO Einstellungen werden angewendet, dies belegt z.B. das Tool rsop.msc - GPO Einstellungen werden angewendet, dies belegt z.B. GPMC.MSC, der Punkt Group Policy Results - Registry HKLM\System\CurrentControlSet\Services\W32Time\Parameters "reagiert auf Änderungen". Wenn ich nämlich den w32time Dienst de-registriere und wieder neu registriere, werden die Einstellungen des w32time Dienstes zürückgesetzt und somit ändert sich z.B. die Einstellung NtpSErver auf time.windows.com,0x8 (im Pfad HKLM\System\CurrentControlSet\Services\W32Time\Parameters). Auch ändert sich die Einstellung Type auf NT5DS im Pfad HKLM\System\CurrentControlSet\Services\W32Time\Parameters Somit müsste ja das Gegenteil auch passieren, wenn gpupdate /force ausführe und danach gpresult /r /scope Computer wird mir angezeigt, dass die GPO mit der NTP Konfiguration auf den virtuellen DC angewendet wird. Aber eben, drücke ich in der geöffneten Registry dann auf aktualisieren, werden nicht wie erwartet, wieder die zuvor gesetzten Default Werte überschrieben, sondern es passiert genau gar nichts, sprich, die GPO Einstellungen werden in Bezug Registry NICHT verändert. Die Einstellungen im Pfad HKLM\System\CurrentControlSet\Services\W32Time\Parameters bleiben somit auf den zürückgesetzen Werten, warum? Was läuft da Schief? Was ich besonders nicht verstehe sind zwei Dinge: - offensichtlich werden die Konfigurationen in der GPO auf den DC angewendet (siehe Fazit), jedoch interessiert dies die Registry nicht oder suche ich ständig im falschen Pfad? ich prüfe stehts die Einstellungen unter HKLM\System\CurrentControlSet\Services\W32Time\Parameters - Die Ausgabe im DOS müsste doch den FQDN ntp.metas.ch ausgeben, lautet aber w32tm /query /status Source: Local CMOS Clock Dass die Ausgabe Source: Locak CMOS Clock ausgibt, ist für mich höchstens erklärbar, dass die Registry ja die falschen Werte hinterlegt hat, Aber: Wenn ich von Hand, "manuell" die Werte so setze, wie Sie oben in der URL von Wolfgang Sommergut beschrieben wird, auch dann zeigt der DC noch immer die falsche Zeit an, obwohl die aktuelle Zeitabweichung zurzeit rund 3 Minuten sind. Aus meiner Sicht müsste doch diese Zeitabweichung durch die GPO möglich sein? Ich hatte irgendwie von früher noch im Kopf, wenn die Zeitabweichung "zu gross" ist, dass dann effektiv die Zeit auf diese Art und Weise nicht "berichtigt" werden kann, darum habe ich die Zeit des DCs "etwas korrigiert", damit die Abweichung nicht derart hoch ist - zur "richtigen" Zeit (z.B. auf dem Smartphone) Aber eben, auch dieser "Trick" hat nicht geholfen, bin ratlos :-(
  21. cool, spannender Input. Danke hierfür. Werde mal nächste Woche wieder einen Blick in die GPO werfen und nochmals kurz die Sache neu aufrollen bzw. prüfen ;)
  22. ok, danke für die rasche Rückmeldung. Werde es Morgen kurz testen und eine Rückmeldung geben ;)
  23. Im angegebenen MS Link von mir ist ja ein Beispiel zum Punkt RoamingProfileLocation Das Beispiel sieht so aus "${roaming_app_data}\\edge-profile" Schlüsselt man also die Variable ${roaming_app_data} auf, so ist der Dateipfad dieser Variable gemäss dem MS Link "${roaming_app_data}\\edge-profile"https://docs.microsoft.com/de-de/DeployEdge/edge-learnmore-create-user-directory-vars für die soeben, genannte Variable ${roaming_app_data} Der Ordner für servergespeicherte Anwendungsdaten für den aktuellen Benutzer. Beispiel: C:\Users\Administrator\AppData\Roaming Man soll also für die Konfiguration RoamingProfileLocation in der GPO einen Pfad angeben, welcher sich aus einer Variable zusammensetzt, welche wiederum auf ein lokales Verzeichnis zeigt? Was ist da dran Roaming mässig bzw. nochmals: ich wiederhole mich, wie schon im Eröffnungsblog geschrieben: Unter Roaming verstehe ich ein zentraler Speicherort, verstehe nicht, wie oder wo die Favoriten dann zentral abgespeichert werden, denn wenn ich mich ja dann auf Maschine X und Maschine Y verbinde, will ich nach wie vor die gleichen Favoriten und das geht ja bekanntlich nur, wenn die Favoriten von einem zentralen Ort geholt werden, darum verstehe ich dieses Prinzip hier mit den Variablen, welche ALLE auf einen lokalen Pfad zeigen, nicht wirklich, Du etwa schon, Testperson?
  24. Hi all Ziel Die Favoriten von MS Edge Chromium zentral abspeichern. Z.B. mit Hilfe der GPO Einstellung RoamingProfileLocation. Problem Wir haben servergespeicherte Profile und haben unteranderem eine GPO konfiguriert, welche diverse Ordner wie AppData, LocalAppData usw. ausschliesst. Die GPO, welche Verzeichnisse aus servergespeicherten Profilen ausschliesst ist unter Benutzerkonfiguration\Richtlinien\Administrative Vorlagen\System\Benutzerprofile. Seit wir zusätzliche Verzeichnisse hinzugefügt haben AppData\Local;AppData\LocalLow;AppData, (damit nicht von irgendwelchen Programmen auf dem Fileserver zusätzliche, unnötige Dateien abgespeichert werden und Speicherplatz fressen) haben wir mit den Favoriten Probleme. Die Favoritenleiste beinhaltet nicht mehr alle Favoriten, selber erstellte Favoriten (nebst denen, welche wir automatisiert zur Verfügung stellen, fehlen, wenn Jemand im Homeoffice arbeitet => VMware Maschine wird immer komplett frisch aufgesetzt und dem Benutzer zur Verfügung gestellt, Ordner bzw. dessen Inhalt in AppData,LocalAppData usw. sind somit immer nach dem Abmelden eines Benutzers wider gelöscht. Als ich mir die neuen GPO Einstellung der neuen Version MS Edge Chromium Stable 87 studiert habe, stellte ich fest, dass es eine MS Edge Konfigurationsmöglichkeit via GPO gibt, der Punkt heisst RoamingProfileLocation und so vom Namen her dachte ich, dass dies genau die Lösung sein könnte. Wenn ich aber die Microsoft Online Doku https://docs.microsoft.com/en-us/deployedge/microsoft-edge-policies#roamingprofilelocation lese betreffend diesem Punkt, werde ich nicht schlau, im Gegenteil, nur verwirrt. Warum? Weil alle möglichen Parameter (Variablen), welche man in der GPO verwenden kann, immer auf lokale Ordnerpfade zeigen. Z.B. C:\Users\Administrator\Document Ehm, der Name der Einstellung heisst doch RoamingProfileLocation und unter Roaming verstehe ich eher ein zentraler Speicherort auf einem Server in der Forma \\Servername\Share. Hat Jemand diese Einstellung schon gebraucht und weiss, wie die Sache funktioniert bzw. zu konfigurieren ist oder verstehe ich diese Einstellung innerhalb der EDGE GPO irgendwie komplett falsch?
×
×
  • Neu erstellen...