Alle Aktivitäten

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?

Is zwar schon ne Weile her, der Post: Auf meinen Windows Server 2025 gibt wmic immer noch.

Genau, Das müsstest Du evtl. von "Microsoft Windows" auf "Microsoft UEFI CA" umstellen.

Wie startest du die VM? Secure Boot aktiviert? Wenn ja, was steht unter "Sicherheit" -> "Sicherer Start" -> "Vorlage"

Ich bekomme diese Fehlermeldung. The signed Image`s has not alowed (DB) Die Frage, ist das denn grundsätzlich möglich? Mit dem Image hatte ich aber schon eine Server (Blech) aufgesetzt. Ich bekomme diese Fehlermeldung.

Hallo, "gelingt mir einfach nicht" ist wenig aussagekräftig. Was hast du denn schon versucht, was für Fehler treten auf?

Hallo, es gelingt mir einfach nicht. Die oben genannte OS auf dem HyperV zu installieren. Windows Server Datacenter 2019, Patchlevel ist aktuell. Geht das nicht?

Alles klar. Danke euch.