Alle Aktivitäten

Ich würde den aus der Domäne nehmen, neu installieren und wieder in die Domäne rein

Seltsam... Was sagt denn Powershell "Test-ComputerSecureChannel -Verbose" ?

Hallo :) ich kenne nur den Artikel Reparieren eines beschädigten Benutzerprofils. Gruß Ingo

Sodale sry das ich mich erst so spät wieder melde. (Frisch aus dem Urlaub ^^) ich habe versucht die entsprechende GPO zu deaktivieren damit einfach die nächste greifen soll, Ergbnis war das dann die nächste GPO genauso hängt wie die erste. Die gpt.ini ist auch von den Rechnern aus sichtbar (bekomme die über den Explorer sofort angezeigt) Das hatte ich auch im verdacht aber wie kann ich das reparieren? weil spontan fällt mir nur ein aus der Domäne raus, Objekt löschen und wieder rein in die Domäne aber das hat leider auch nicht geholfen...

Moment ... redest Du jetzt von SYSVOL Replikation oder von Wins? Erzeug doch mal im Netlogon Verzeichnis eine einfache Textdatei oder einen Ordner ... erscheint die auf dem anderen DC auch? Nimm mal aus beiden Servern die WINS Einträge raus - das AD braucht keinen WINS, sondern einen funktionierenden DNS. Passen die DNS Einträge (Name Server) kannst Du die FQDN der Server auflösen (Ping / NSLookup)? und wie die Kollegen schon gefragt haben .. was sagt das Eventlog?

Moin an Board, so starten wir dann in die kurze, spannende Woche - ich koche Kaffee Allen einen guten Dienstag, bleibt gesund! Hier bedeckt bei 14°C, soll fast den ganzen Tag Regnen bis etwa 17°C

Partner-WINS-Adresse: Server Partner-IP-Adresse: 192.168.xx.x Der Dienst versucht regelmäßig, die Verbindung erneut herzustellen. Weitere Informationen: Fehler: 9036 (Zum Sichern oder Wiederherstellen angehalten) Verbindungs-ID: 3B001673-E3FC-4294-8903-484B8A0B3D23 Replikationsgruppen-ID: 6C7E9F55-2A34-495C-B8CC-7D0F4F712480

Wer Wein trinkt, betet. Wer Wein säuft. sündigt. Lasset uns beten. (Theodor Heuss)

Repadmin hat mit Sysvol nichts zu tun - Repadmin ist nur AD-Sync. DFSR ist dfsutil/dfsdiag oder Powershell. Und natürlich Eventlog "DFS Replication". Verwaiste Server spielen normalerweise keine Rolle, wenn nicht jemand manuell preferred Bridgeheads konfiguriert hat und die DCs in verschiedenen Sites stehen. Was sagt denn das DFSR-Eventlog auf dem neuen Server, der nicht synchronisieren willst, nach einem Neustart von DFSR?

# for hex 0x52e / decimal 1326 : ERROR_LOGON_FAILURE winerror.h # Logon failure: unknown user name or bad password. # 1 matches found for "0x52e" Da ist was mit dem Computerkonto kaputt.

hallo, hier mal der Link zu den Produktnutzungsbestimmungen seitens Micrsoft. https://www.microsoft.com/licensing/terms/de-DE/product/changes/OVOVS bei datum hab ich das aktuelle genommen, rein lizenzrechtlich müsste man ja immer das Datum im Pulldown selektieren, an dem man die Lizezen gekauft hat, also um super sauber zu sein. Aber in diesem Fall ist es ja nicht relevant. Ich denke alle stimmen zu, dass man beim Lizenzieren, wenn man keine WIN-SVR vorher hatte, die Server Lizenz benötigt und in den PURs steht ja dann drin, dass man auch relevante User/Device-CALs für den legalen Zugriff benötigt. (Mischen ja erlaubt!) Setzt man auf diesen WIN-SVR einen SQL-SVR on top, Lizernzierung im Modus SVR SQL-CAL Benötigt man auch relevante SQL-CALs ( Diese braucht man aber nie, wenn der SQL-SVR nach CORES lizenziert wird!) Erläuterung seitens MS zu SQL > https://www.microsoft.com/de-de/licensing/product-licensing/sql-server Beim WIN-SVR gibt es keine CAL-Ausnahme bei CORE-Lizenzierung. Microsoft ist leider nicht gewillt, Lizenzierung simpel und schriftlich zu erläutern, Oder sie kriegen es einfach nicht hin.... traurig. Aber beim Audit darf man dann heftig zahlen wenn man es falsch macht.... Viele Grüße, Franz

Super danke!! Dann mach ich mal ran

Hallo @lizenzdoc kannst Du dazu mal ein Microsoft Dokument verlinken? Beim offiziellen Microsoft Lizenz Guide von SQL Server steht von Windows Server Cals nix drin.

Moin, verwaiste Server kannst Du entfernen, und vielleicht repariert es auch die Replikation

Vielleicht kann mir doch nochmal jemand einen Tip geben: Nach dem, was repadmin ausgespuckt hat, funktioniert der Sync zu dem neu aufgesetzten Server ja scheinbar. Das das Sysvol wird offenbar nicht synchronisiert. Ich hab jetzt nachgesehen und der Server hält alle Rollen: C:\Windows\system32>netdom query fsmo Schemamaster WSERV2019.DOMÄNE.local Domänennamen-Master WSERV2019.DOMÄNE.local PDC WSERV2019.DOMÄNE.local RID-Pool-Manager WSERV2019.DOMÄNE.local Infrastrukturmaster WSERV2019.DOMÄNE.local Der Befehl wurde ausgeführt. Die Domänenfunktionsebene kann ich jetzt nicht heraufstufen, weil noch verwaiste Server vorhanden sind. DIe kann ich doch aber gefahrlos aus der Domäne entfernen, ohne das die AD Funktionen beeinträchtigt werden ? Klar, ich muss sie aus DNS etc entfernen, ich habe gerade einfach nur Angst, dass das AD nach so einer Aktion nicht mehr funktioniert. Der Befehl: dfsrmig.exe /GETMIGRATIONSTATE spuckt aus, dass alle Domänencontrolller erfolgreich zum Status ("ENTFERNT") migriert wurden.

Moin, wenn schon 20 x 2019er WIN-USER-CALs vorhanden sind und der neue(zusätzliche ) WIN SVR ( auf dem der SQL-SVR laufen soll) nur 2019 sein soll, dann brauchst du keine weiteren 2019er WIN-User-CALs! Weil > 1 2019er WIN-USER-CAL erlaubt innerhalb deines Firmennetzwerk dem User auf alle! 2019er WIN-SVR (oder älter) zuzugreifen! erst wenn Du dich für die Nutzung von WIN-SVR 2025 entscheidest, müssen alle WIN-USER-CALs, die auch nun auf den 2025er zugreifen durch neue 2025er WIN-CALs ersetzt werden. Wenn der SQL-SVR auf einem WIN-SVR läuft, müssen die Zugriffe auch immer mit WIN-CALs lizenziert sein, Wenn auf Linux, dann ja nicht ! Grüße, Franz

Genau das war ja die Frage und daher kam auch die Empfehlung auf Linux zu installieren. ;)

Irgendwann möchte er die anderen Server auch auf 2025 aktualisieren. Dann kann er jetzt schon anfangen uns CAL's kaufen. Oder bei der Ursprünglichen Idee bleiben und auf Server 2019 installieren.

Nicht, wenn er wie oben gefragt auf win2025 installieren wollte.

Er hat die Windows Sever CAL ja schon, da der SQL Server nicht der einzige Windows Server ist.

Der Benutzer nutzt Dienste des Servers, und wenn es nur der Netzwerkstack ist. Deshalb die Erfordernis einer CAL.

Ergibt absolut keinen Sinn. Denn wozu brauch ich ne Server CAL wenn ich mich nicht mal am Server selbst anmelden kann und nur der Port 1433 überhaupt erreichbar ist? Aber bei Microsoft mag das so sein. Dann kann für dich @magicpeter nur die Empfehlung sein den SQL Server auf einer Linux Büchse zu installieren. Somit fallen deine 20 Server CALs schon mal weg.

Ja. Es ist "Client Access", nicht "Network Access".

Sobald die erste Windows Server 2025 Lizenz da ist, lässt sich ja auch der Host auf Server 2025 upgraden oder mit Server 2025 neu aufsetzen, sofern die Hardware für Windows Server 2025 freigegeben ist.

Interesant finde ich eher die Frage: Werden die Server CALs benötigt wenn die Benutzer sich nur am SQL Server anmelden?