NorbertFe

Der Name des Servers ist egal. Deswegen schreibt man auch den nicht ins Zertifikat. Dann hättest du den Fehler schon gesehen. Scp anfragen geht per get-clientaccessservice

Wenn man natürlich den kurzen Namen ins Zertifikat popelt ist es irgendwie fast immer ohne Fehler. Hätte man ein öffentliches Zertifikat genommen, wäre einem der Fehler sofort aufgefallen. Wieder was gelernt im Testlabor. ;)

War das mal ne SBS Installation? oder ist das ne blanke Neuinstallation?

Versuch mal auf einem der Clients: https://www.tecchannel.de/a/windows-zeitdienst-reparieren,2033008

Oder! Wie du siehst. Was steht denn im Eventlog des PDC Emulators?

Vielleicht schaust du ja erstmal, was deine primäre Zeitquelle (der PDC Emulator) so ausspuckt? Wenn der nicht die korrekte Zeit verteilt, dann brauchst am Client nicht suchen, denn dann suchst du an der falschen Stelle.

Interessant wäre aber eher: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\W32Time\Parameters

Ja und wo aus der registry? Stell dir vor, da gibts mehr als eine Stelle. Und wenn dir das klar ist, muss das noch lange nicht so rüberkommen im Forum. Falls in der policy oben dein dc drin stehen sollte ist das total egal, weil der Name sowieso nicht verwendet wird wenn auf nt5ds konfiguriert wird.

Muss man bei dir jetzt jedes mal nachfragen ob das der Client oder der Server ist? Kommentarlos Screenshots reinzukopieren, wird dir nicht helfen. Schau halt ins eventlog. Wenn du Hilfe erwartest, solltest du etwas ausführlicher werden.

Falsch gedacht. am Client sollte das aber nicht kommen. Der syncht normalerweise mit einem dc. Prüfe mal, wie deine Zeitsync konfiguriert ist.

Und warum? Am Client?

Naja jetzt wo man im Home Office Zeit hat sich mit den wichtigen Fragen zu beschäftigen...

Dazu gehört auch ein vernünftiges Zertifikat. ;) Ja klar.

Für ein Exchangezertifikat? Bisschen überkandidelt oder? Kauf dir ein Zertifikat oder nutze Lets Encrypt. Eine CA hat auf einem DC nichts zu suchen und für ein Zertifikat installiert man keine CA (auf dem DC). Bye Norbert

Damit kann man aber nicht langsam verschieben. ;)

Moin, https://www.heise.de/newsticker/meldung/YouTube-reduziert-Videoaufloesung-in-Europa-4686819.html

Genau. Denn der AdminSDHolder ist ein Prozess und kein User. Du sollst nur schauen, ob der User mit oder ohne aktivierter Vererbung konfiguriert ist.

Die wenigsten die sich dafür interessieren sind eben Entwickler ;)

Naja gibts im Zweifel ne Backpfeife ;) Wenn man das konfigurieren könnte, dass keine Simpelst Kennworte möglich sind, wäre das auch meine Empfehlung. Leider sind damit aber eben "12345678900987654321" Kennworte möglich. Und ja User ticken leider so. Bye Norbert

Dann geh doch mal zu Microsoft Update und schau welche Updates dir dort angeboten werden.

https://docs.microsoft.com/de-de/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory

Ist das der Fall? AdminSDHolder vermutlich. Sind oder waren die mal in einer geschützten Gruppe? Falls ja dann aktivier die Vererbung auf dem Konto wieder. Falls die da noch drin stecken, wird die sich aber immer wieder deaktivieren. Also Lösung dauerhafter Natur dann den Nutzer aus diesen Gruppen entfernen.

So, ich hab das mal eben auf meinem 2019er KMS für dich getestet. Für 2016 und 2010 gilt das hier: https://social.technet.microsoft.com/Forums/de-DE/6d936558-c894-4967-b39a-56ace3baebbd/office-2010-per-kms-aktivieren-auf-server-2016?forum=office_14de

Und welchen Fehler gibts dazu? Ich kann mir das schwer vorstellen, dass das nicht gehen soll, wenn es sich bei beidem um Produkte im Support handelt.

Du bist also jetzt schon _ohne_ DIenstleistungen über dem "sollte" Budget und arbeitest vermutlich gratis? Was vermutest du denn, wie lange du für die Konfiguration und Anbindung usw. benötigst?