Jump to content

Akcent

Newbie
  • Content Count

    48
  • Joined

  • Last visited

Community Reputation

10 Neutral

About Akcent

  • Rank
    Newbie

Recent Profile Visitors

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

  1. ja habe ich und es fühlt sich alles etwas flotter an. Habe auch die Info bekommen, daß Server-Eye beim Herunterfahren aktiv ist.
  2. Habe gestern mal 2 Server auf Windows 2019 aktualisiert und immer noch den gleichen Effekt. Das Herunterfahren von einem Server hat dabei über 30min gedauert.
  3. ich denke es liegt in der Tat an den Updates. Mich hat nur gewundert, daß der Bildschirm da so extrem lange stehen bleibt.
  4. was meinst Du mit "was sind das für Server? Und was mit sauber migrieren? Eine Neuinstallation?
  5. hmm ... habe hier zwar 2019er Lizenzen (aus dem ActionPack), kann die aber nicht ohne Datenverlust und alles neu zu installieren als Update drüber installieren. Mein ISO gibt mit nur die Auswahl "nichts behalten" Die 2016er liefen eigentlich immer sehr gut. das hast Du jetzt ironisch gemeint
  6. Hallo, habe einen Windows 2016 als VM unter einem 2016er Hyper-V laufen. Wenn ich den Server neustarten oder herunterfahren möchte bleibt dieser ewig bei diesen Bild hängen Auf dem Server läuft eine Video Management-Software go1984 und Server-Eye als RMM Virenschutz = G DATA Kennt das jemand und hat gg. eine Abhilfe / Lösung? Gruß, Herry
  7. Ich haben den gleichen Fehler wie @santoooom Es gab mal zwei DC's Server01 und Server03 Der Server03 wurde wie schon oben aus der AD entfernt. Es ist auch nicht mehr im AD drin. Habe ich mal mit diesem Check überprüft https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup Dennoch habe ich 4012 Fehler in der DFS Ereignisanzeige. Der DFS-Replikationsdienst hat die Replikation für den Ordner unter dem folgenden lokalen Pfad "C:\Windows\SYSVOL\domain" beendet. Dieser Server wurde von anderen Partnern für 420 Tage getrennt. Dadurch wird die im Parameter "MaxOfflineTimeInDays" zulässige Dauer überschritten (60). Aus diesem Grund geht der DFS-Replikationsdienst davon aus, dass diese Daten veraltet sind, und dieser Ordner wird vom Server erst nach Korrektur dieses Fehlers wieder repliziert. Verwenden Sie zum Fortsetzen der Replikation dieses Ordners das DFS-Verwaltungs-Snap-Ins zum Entfernen dieses Servers aus der Replikationsgruppe, und fügen Sie ihn dann der Gruppe erneut zu. Dadurch führt der Server einen ersten Synchronisierungstask aus, wodurch die veralteten Daten durch aktuelle Daten der Mitglieder der Replikationsgruppe ersetzt werden. Weitere Informationen: Fehler: 9061 (Der replizierte Ordner war zu lange offline.) Name des replizierten Ordners: SYSVOL Share ID des replizierten Ordners: 7ED04525-2E13-4728-AFAE-D611E5718E2B Replikationsgruppenname: Domain System Volume ID der Replikationsgruppe: 251E226C-6D91-4D70-88D4-CBF9A221F958 Mitglieds-ID: F102CF27-5552-4F44-B347-91C700F5A4F3 Deinen Weg @vanGraham habe ich auch geprüft, aber da gibt es nur den einen, letzte DC Gibt es noch eine andere Stelle, die man überprüfen kann? Update 13:00 Uhr: Habe diesen Artikel gefunden https://www.mcbsys.com/blog/2018/12/dfsr-error-4012-on-stand-alone-domain-controller/ Bis jetzt sind die Fehler weg. Gruß, Herry //abgetrennt von hier: https://www.mcseboard.de/topic/203023-dfsr-fehler-4012-dfs-replikation/ Beitrag aus 2015
  8. ja auch diese 2.GPO und die kommt auch an auf den PCs die ich mir eben mal angeschaut habe das gleiche Fehlerbild beim Resync. Uhrzeiten bei allen unterschiedlich 1 PC passt 1 PC 8 geht min vor 1 PC 4 geht min vor
  9. Wir haben nur einen DC Habe ich gemacht und auch wie tesso vorgeschlagen hat den Client neu gestartet und ein neues Sync angestoßen. Ergebnis: C:\>w32tm /resync Befehl zum erneuten Synchronisieren wird an den lokalen Computer gesendet. Der Computer wurde nicht synchronisiert, da keine Zeitdaten verfügbar waren. Dieser Client geht 5min vor
  10. Hi Norbert. da sieht das so aus: Ich befürchte, daß hier der Haken noch raus muß.
  11. Hallo, zufällig ist uns aufgefallen, daß die Clients in unserem Netzwerk unterschiedliche Zeiten haben. Wir haben einen DC (als Hyper-V VM) und 10 phy. Windows 10 Clients (1909) Die GPO wurde überprüft und gemäß einer Empfehlung von @NorbertFe überprüft / gesetzt. Diese greifen auch, aber die Clients haben unterschiedliche Zeiten (Delta 2 - 5 Min) Überprüft man auf den Clients per w32tm /query /source bekommt man nicht den DC (PDC Emulator) als Quelle zurück sondern Local CMOS Clock Hat dazu ggf. jemand ein Idee warum die Clients nicht alle die gleiche Uhrzeit haben? Gruß, Herry
  12. hatte doch geschrieben, daß ich gpupdate bereits gemacht und nun auch gpresult funktioniert Den Link zu den GPO's hatte ich doch schon 1:1 übernommen :-( oh .... Danke @tesso
  13. WOW .... da war in der Tat das WMI defekt. Habe zuerst mit diesen Befehlen geprüft winmgmt /verifyrepository winmgmt /salvagerepository Beide gaben alles OK zurück. Dann habe ich den WMI Deinst beendet und das Reposity Verzeichnis umbenannt Danach mit Winmgmt /resetrepository zurück gesetzt. PC neu gestartet und gpupdate /force und gpresult /h c:\temp\r.html Und nun kam kein Fehler und der Bericht wird auch erzeigt. Auch über die Gruppenrichtlinienverwaltung kann nun ein Bericht erzeugt werden und hier sieht man auch das die GPO für die Zeiteintsellung angewendet wurde. Klasse und Danke Norbert. Das Problem mit der unterschiedlichen Zeit habe ich aber immer noch (auch nach Restart des Zeit-Dienstes) w32tm /query /status Sprungindikator: 3(nicht synchronisiert) Stratum: 0 (nicht angegeben) Präzision: -23 (119.209ns pro Tick) Stammverzögerung: 0.0000000s Stammabweichung: 0.0000000s Referenz-ID: 0x00000000 (nicht angegeben) Letzte erfolgr. Synchronisierungszeit: nicht angegeben Quelle: Local CMOS Clock Abrufintervall: 10 (1024s)
×
×
  • Create New...