04.07.2025
1613
10
0Alten host mit SQL Server in neues Netzwerk übernehmen
Hi,
brauche Hilfe bei einem "eigentlich" einfachen Aufgabenstellung aber habe auch keine Lust das ich mir alles zerschieße.
Folgende Situation:
altes System (HyperV als Virtuelle Umgebung)
1 x Windows Server 2016 - Host
1 x VM Windows Server 2016 - DomainController
1 x VM Windows Server 2016 - SQL mit Warenwirtschaft
neues System (HyperV als Virtuelle Umgebung)
1 x Windows Server 2022- Host
1 x VM Windows Server 2022 - DomainController
1 x VM Windows Server 2022 - SQL mit Warenwirtschaft
1 x VM Windows Server 2022 - Daten
Ich möchte nun den alten Host in die neue Umgebung integrieren. Wir wollen auf dem alten HostServer mit einer neuen Warenwirtschaft Test´s durchführen. Der alte DomainController soll nicht mehr laufen sondern nur der Server 2016 SQL mit Warenwirtschaft.
Meine Überlegung ist folgende:
Alten Host ins neue Netzwerk anschließen. IP Adressen anpassen und nicht in die neue domäne einbinden. Der alte Host selber ist in keiner Domäne.
Alten SQL Warenwirtschaft aus der alten Domäne rausholen und dann ???
Soll ich Ihn in die neue Domäne aufnehmen oder Ihn nur in einer Workgroup lassen?
Was wäre der beste Weg?
Danke schon mal im voraus.
frank M
brauche Hilfe bei einem "eigentlich" einfachen Aufgabenstellung aber habe auch keine Lust das ich mir alles zerschieße.
Folgende Situation:
altes System (HyperV als Virtuelle Umgebung)
1 x Windows Server 2016 - Host
1 x VM Windows Server 2016 - DomainController
1 x VM Windows Server 2016 - SQL mit Warenwirtschaft
neues System (HyperV als Virtuelle Umgebung)
1 x Windows Server 2022- Host
1 x VM Windows Server 2022 - DomainController
1 x VM Windows Server 2022 - SQL mit Warenwirtschaft
1 x VM Windows Server 2022 - Daten
Ich möchte nun den alten Host in die neue Umgebung integrieren. Wir wollen auf dem alten HostServer mit einer neuen Warenwirtschaft Test´s durchführen. Der alte DomainController soll nicht mehr laufen sondern nur der Server 2016 SQL mit Warenwirtschaft.
Meine Überlegung ist folgende:
Alten Host ins neue Netzwerk anschließen. IP Adressen anpassen und nicht in die neue domäne einbinden. Der alte Host selber ist in keiner Domäne.
Alten SQL Warenwirtschaft aus der alten Domäne rausholen und dann ???
Soll ich Ihn in die neue Domäne aufnehmen oder Ihn nur in einer Workgroup lassen?
Was wäre der beste Weg?
Danke schon mal im voraus.
frank M
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673692
Url: https://administrator.de/forum/windows-server-sql-warenwirtschaft-673692.html
Ausgedruckt am: 15.07.2025 um 03:07 Uhr
10 Kommentare
Neuester Kommentar
Warum gibts überhaupt eine neue Domäne? Warum wird die alte nicht weiter verwendet?
Zitat von @pomull:
Was wäre der beste Weg?
Das kommt darauf an, wie stark "SQL" in die Domäneninfrastruktur integriert ist.
Oder sollte ich lieber den "alten" Domaincontroller herabstufen?
kann ich den dann ohne Probleme mit dem "aktuellen" Domaincontroller laufen lassen?
kann ich den dann ohne Probleme mit dem "aktuellen" Domaincontroller laufen lassen?
Die große Frage ist, ob die Berechtigungen auf den SQL und die Datenbank über Domänen Benutzern oder lokale SQL Benutzern erfolgt ist. Wenn du ausschließlich Domänen Benutzer verwendet hast, wirst du dich aussperren, wenn der SQL Server die alte Domäne nicht mehr abfragen kann.
PS: Habt ihr auf dem neuen DC eine neue Domäne erstellt oder ist der als zweiter DC in der bestehend Domäne integriert?
PS: Habt ihr auf dem neuen DC eine neue Domäne erstellt oder ist der als zweiter DC in der bestehend Domäne integriert?
SQL
Also wie @wtf-not-again schon sagt, es kommt darauf an. Wie melden sich die ERP Clients an der DB an? Ein DB Benutzer der auf dem SQL anagelegt wurde? Oder Domain Benutzerkonten. Ist die Anmeldung des sa auf dem SQL aktiviert oder nur Domain-Anmeldung?
DC
Hier musst du anfangen mit der Planung. Du schreibst nichts dazu, wie die Domains heißen, heißen die gleich? - ganz schlecht. Wenn die unterschiedliche Domainnamen haben kann man die auch gleichzeitig laufen lassen. Und nein, wenn die gleich heißen kann man nicht einfach beide einschalten, einen demoten und der andere übernimmt wenn die sich nicht kennen.
Wo hast du DHCP eingerichtet, auf beiden DCs?
WaWi
Theoretisch könnte es auch bei der WaWi zu Konflikten kommen, z.B. bei gleichen Hostnamen. Die Lizenz lässt vermutlich auch kein Parallelbetrieb zu, ist die Frage wie die Software das prüft (z.B. Dongle oder so).
Also wie @wtf-not-again schon sagt, es kommt darauf an. Wie melden sich die ERP Clients an der DB an? Ein DB Benutzer der auf dem SQL anagelegt wurde? Oder Domain Benutzerkonten. Ist die Anmeldung des sa auf dem SQL aktiviert oder nur Domain-Anmeldung?
DC
Hier musst du anfangen mit der Planung. Du schreibst nichts dazu, wie die Domains heißen, heißen die gleich? - ganz schlecht. Wenn die unterschiedliche Domainnamen haben kann man die auch gleichzeitig laufen lassen. Und nein, wenn die gleich heißen kann man nicht einfach beide einschalten, einen demoten und der andere übernimmt wenn die sich nicht kennen.
Wo hast du DHCP eingerichtet, auf beiden DCs?
WaWi
Theoretisch könnte es auch bei der WaWi zu Konflikten kommen, z.B. bei gleichen Hostnamen. Die Lizenz lässt vermutlich auch kein Parallelbetrieb zu, ist die Frage wie die Software das prüft (z.B. Dongle oder so).
Zitat von @pomull:
Du meinst also das der SQL danach nicht laufen könnte weil er die Domäne nicht mehr findet?
Firebird und auch MariaDB laufen weiterhin, sofern nicht domänenintegrierte Konten für die Dienste verwendet wurden.
Hi.
2 unterschiedliche Domänen
DHCP nur auf dem neuen DC
Die Clients haben sich mit dem Domänen Benutzerkonto angemeldet.
2 unterschiedliche Domänen
DHCP nur auf dem neuen DC
Die Clients haben sich mit dem Domänen Benutzerkonto angemeldet.
Wie heißt die WaWi? Es geht auch wirklich um MSSQL und nicht um was anderes?
Die große Frage: Funktioniert die Anmeldung der WaWi Clients an den SQLer über Domänenkonten oder beispielsweise über dedizierte Benutzerkonten oder gar nur über ein Konto wie den sa
Die große Frage: Funktioniert die Anmeldung der WaWi Clients an den SQLer über Domänenkonten oder beispielsweise über dedizierte Benutzerkonten oder gar nur über ein Konto wie den sa
Tach,
SQL Server und WaWi laufen wie? AD-Benutzer oder Mixed-Mode und vlt. noch alles unter sa Account?
Im einfachsten Fall hat die WaWi eine Middleware - und nur an einer Stelle wird die Verbindung zum Server hergestellt. Oder jeder Client stellt separat eine Verbindung her.
Was für eine SQL Version hast du? Theoretisch läuft unter 2016 auch noch SQL 2000. Räusper, geht sogar ganz gut.
In die Domäne aufnehmen macht es einfach GPOs, Virenscanner, etc. auf die Maschinen zu verteilen. Sonst hast du einen Mix. VLAN wäre ggf. noch eine Überlegung.
Wenn die WaWi über INI, XML, JSON oder was auch immer konfigurierbar ist und du an die SQL Server Einstellungen ran kommst, sollte sich nichts beißen.
IP oder DNS. Je Nach Vorhaben. Für eine absehbare Zeit als Migrationszwischenschritt wäre auch eine Config via fester IP vollkommen i.O.
Was für Tests wollt ihr duchführen? Wenn man meist den kleinsten gemeinsamen Nenner sich rauspickt, sind UPDATE, INSERT und SELECT Statements alle gleich.
Dan wäre es sogar Denkbar die SQL DB als neue Instanz auf den neuen Server zu migrieren und so zu testen. Klar gibt es bei den Versionen auch gravierende Unterschiede. Ob die nun bei dir viel ausmachen weiß eig. nur der Programmierer der WaWi. Stored Procedurse, Datenbank Trigger oder spezieller Funktionen könnten was aus machen.
Nutzt die WaWi SQL nur als Datenbunker und die Logik erledigt die Anwendungssoftware, so ist die Fallhöhe relativ gering.
Wir hatten vor kurzen auch alt und neu. Nur läuft ERP System unter SuSE Linux mit IBM Informix DB. Da schaut die Integration in Windows Domäne eh etwas anders aus
Tests gehen ggf. nur begrenzt. Wenn die WaWi alte Strukturen bemerkt und munter mit ALTER TABLE Änderungen reinknallt, dann ist max. der Datenbestand zum Testen zu sehen. Der Aufbau würde dann ja schon der neuen Struktur entsprechen.
Eigene Test sind immer so eine Sache und machen hier ggf. wenig Sinn. Was sagt denn der WaWi Hersteller?
Wie soll die Test-Konfig denn genau aussehen? Im Prinzip biegt ihr die WaWi SQL Einstellungen auf den alten Server um! Die neue DB bleibt unbeleckt. Später das ganze dann auf neue umstellen?
Was ist mit den alten Daten? Die müssten ja für eine Migration gesichert werden. Ihr werdet ja nicht bei Null anfangen! Wäre dann keine gute Idee die kaputt gespielten Spieldaten von deinen Test zu nehmen!
Normal sollte doch eine Migration Bestandteil vom Vertrag sein.
Habt ihr die WaWi von der Stange oder extra angepasste Module eingekauft? Extra Workflows für Euer Haus, die es zu testen gilt?
mfg Crusher
SQL Server und WaWi laufen wie? AD-Benutzer oder Mixed-Mode und vlt. noch alles unter sa Account?
Im einfachsten Fall hat die WaWi eine Middleware - und nur an einer Stelle wird die Verbindung zum Server hergestellt. Oder jeder Client stellt separat eine Verbindung her.
Was für eine SQL Version hast du? Theoretisch läuft unter 2016 auch noch SQL 2000. Räusper, geht sogar ganz gut.
In die Domäne aufnehmen macht es einfach GPOs, Virenscanner, etc. auf die Maschinen zu verteilen. Sonst hast du einen Mix. VLAN wäre ggf. noch eine Überlegung.
Wenn die WaWi über INI, XML, JSON oder was auch immer konfigurierbar ist und du an die SQL Server Einstellungen ran kommst, sollte sich nichts beißen.
IP oder DNS. Je Nach Vorhaben. Für eine absehbare Zeit als Migrationszwischenschritt wäre auch eine Config via fester IP vollkommen i.O.
Was für Tests wollt ihr duchführen? Wenn man meist den kleinsten gemeinsamen Nenner sich rauspickt, sind UPDATE, INSERT und SELECT Statements alle gleich.
Dan wäre es sogar Denkbar die SQL DB als neue Instanz auf den neuen Server zu migrieren und so zu testen. Klar gibt es bei den Versionen auch gravierende Unterschiede. Ob die nun bei dir viel ausmachen weiß eig. nur der Programmierer der WaWi. Stored Procedurse, Datenbank Trigger oder spezieller Funktionen könnten was aus machen.
Nutzt die WaWi SQL nur als Datenbunker und die Logik erledigt die Anwendungssoftware, so ist die Fallhöhe relativ gering.
Wir hatten vor kurzen auch alt und neu. Nur läuft ERP System unter SuSE Linux mit IBM Informix DB. Da schaut die Integration in Windows Domäne eh etwas anders aus
Tests gehen ggf. nur begrenzt. Wenn die WaWi alte Strukturen bemerkt und munter mit ALTER TABLE Änderungen reinknallt, dann ist max. der Datenbestand zum Testen zu sehen. Der Aufbau würde dann ja schon der neuen Struktur entsprechen.
Eigene Test sind immer so eine Sache und machen hier ggf. wenig Sinn. Was sagt denn der WaWi Hersteller?
Wie soll die Test-Konfig denn genau aussehen? Im Prinzip biegt ihr die WaWi SQL Einstellungen auf den alten Server um! Die neue DB bleibt unbeleckt. Später das ganze dann auf neue umstellen?
Was ist mit den alten Daten? Die müssten ja für eine Migration gesichert werden. Ihr werdet ja nicht bei Null anfangen! Wäre dann keine gute Idee die kaputt gespielten Spieldaten von deinen Test zu nehmen!
Normal sollte doch eine Migration Bestandteil vom Vertrag sein.
Habt ihr die WaWi von der Stange oder extra angepasste Module eingekauft? Extra Workflows für Euer Haus, die es zu testen gilt?
mfg Crusher
