MS-SQL Server 2014 Express: Nach Einrichtung einer neuen Domäne, sind ein Teil der DB nicht erreichbar
Hallo zusammen,
da unsere DomänenController den Geist aufgegeben hat und in einem schleichenden Prozess alle Sicherungen unbrauchbar gemacht haben, habe ich einen neuen DC mit neuer Domäne auf MS Windows Server 2019 Essential aufgestellt.
Die Domänenanmeldungen aller Benutzer und Gruppen läuft. Aber ein großes Problem mit den MS SQL-Servern (auf einer anderen Maschine).
Der neue MS WIN 2019 hat im Moment nur die DC und DNS Rolle.
Der bestehende MS WIN 20018 R2 hat zwei Instanzen MS SQL 2014 Express laufen. Die Dienste zu den MS SQL laufen. Verbindung mit SQL Server Management Studio ist auch problemlos möglich. Die Datenbanken werden angezeigt, aber nur bei einigen (5) der insgesamt 17 Datenbanken ist eine Detailansicht und Verbindung möglich. Beim Versuch die fehlerhaften auszuklappen kommt die Fehlermeldung "Der Zugriff auf die xxx-Datenbank ist nicht möglich. (Object Explorer)" bei "Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.DatabaseNavigableItem.get_CanGetChildren()
bei Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.NavigableItem.RequestChildren(IGetChildrenRequest request)
bei Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.ExplorerHierarchyNode.BuildChildren(WaitHandle quitEvent)"
Was ich nicht verstehe, dass eben doch ein paar der Datenbanken problemlos laufen. Auch mit den jeweiligen MS Access Anwendungen sind die entsprechenden Datenbanken von den Clients zu erreichen, die fehlerhaften natürlich nicht.
Sieht nach einem Rechteproblem aus, nur an welcher Stelle setze ich an? Was kann ich prüfen, wie komme ich an detailliertere Fehlermeldungen?
Besten Dank im Voraus für eure Unterstützung!
LG Uwe
da unsere DomänenController den Geist aufgegeben hat und in einem schleichenden Prozess alle Sicherungen unbrauchbar gemacht haben, habe ich einen neuen DC mit neuer Domäne auf MS Windows Server 2019 Essential aufgestellt.
Die Domänenanmeldungen aller Benutzer und Gruppen läuft. Aber ein großes Problem mit den MS SQL-Servern (auf einer anderen Maschine).
Der neue MS WIN 2019 hat im Moment nur die DC und DNS Rolle.
Der bestehende MS WIN 20018 R2 hat zwei Instanzen MS SQL 2014 Express laufen. Die Dienste zu den MS SQL laufen. Verbindung mit SQL Server Management Studio ist auch problemlos möglich. Die Datenbanken werden angezeigt, aber nur bei einigen (5) der insgesamt 17 Datenbanken ist eine Detailansicht und Verbindung möglich. Beim Versuch die fehlerhaften auszuklappen kommt die Fehlermeldung "Der Zugriff auf die xxx-Datenbank ist nicht möglich. (Object Explorer)" bei "Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.DatabaseNavigableItem.get_CanGetChildren()
bei Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.NavigableItem.RequestChildren(IGetChildrenRequest request)
bei Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.ExplorerHierarchyNode.BuildChildren(WaitHandle quitEvent)"
Was ich nicht verstehe, dass eben doch ein paar der Datenbanken problemlos laufen. Auch mit den jeweiligen MS Access Anwendungen sind die entsprechenden Datenbanken von den Clients zu erreichen, die fehlerhaften natürlich nicht.
Sieht nach einem Rechteproblem aus, nur an welcher Stelle setze ich an? Was kann ich prüfen, wie komme ich an detailliertere Fehlermeldungen?
Besten Dank im Voraus für eure Unterstützung!
LG Uwe
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: 414791
Url: https://administrator.de/forum/ms-sql-server-2014-express-nach-einrichtung-einer-neuen-domaene-sind-ein-teil-der-db-nicht-erreichbar-414791.html
Ausgedruckt am: 17.05.2025 um 10:05 Uhr
16 Kommentare
Neuester Kommentar
Moin,
du musst den Usern/Gruppen aus der neuen Domäne Rechte auf die DBs und die Instanzen geben falls ihr Windows-Auth verwendet.
lg,
Slainte
du musst den Usern/Gruppen aus der neuen Domäne Rechte auf die DBs und die Instanzen geben falls ihr Windows-Auth verwendet.
lg,
Slainte
Moin,
Plural? Es sind Euch gleich mehrere schleichend abgeraucht?
Deshalb sollte man seine Backups auch regelmäßig testen.
Wirklich eine komplett neue? Schlechte Idee.
Vermutlich ist Folgendes passiert: Die Rechte auf die nicht laufenden DBs sind explizite Zugriffsrechte auf NTFS-Ebene bzw. unter Nutzung des AD. Dann sind dort die SIDs der Nutzer, die berechtigt sind, eingetragen. Nun sind aber die SIDs in der Domain RIDs. D. h. ein Teil der SID eines AD-Objekts ist die SID der Domain, der dieses Objekt angehört. Jetzt hast Du eine neue Domain aufgesetzt. Damit ändert sich die SID der Domain und damit auch alle SIDs der User, selbst wenn sie gleich heißen. Wenn das so ist, dann sind die DBs nicht fehlerhaft, sondern arbeiten wie entworfen. Es wäre ja auch fatal, wenn man einfach einen anderen DC einem Netz unterschieben könnte und dann auf die DBs Zugriff bekäme.
hth
Erik
Plural? Es sind Euch gleich mehrere schleichend abgeraucht?
in einem schleichenden Prozess alle Sicherungen unbrauchbar gemacht haben,
Deshalb sollte man seine Backups auch regelmäßig testen.
habe ich einen neuen DC mit neuer Domäne auf MS Windows Server 2019 Essential aufgestellt.
Wirklich eine komplett neue? Schlechte Idee.
Sieht nach einem Rechteproblem aus, nur an welcher Stelle setze ich an? Was kann ich prüfen, wie komme ich an detailliertere Fehlermeldungen?
Vermutlich ist Folgendes passiert: Die Rechte auf die nicht laufenden DBs sind explizite Zugriffsrechte auf NTFS-Ebene bzw. unter Nutzung des AD. Dann sind dort die SIDs der Nutzer, die berechtigt sind, eingetragen. Nun sind aber die SIDs in der Domain RIDs. D. h. ein Teil der SID eines AD-Objekts ist die SID der Domain, der dieses Objekt angehört. Jetzt hast Du eine neue Domain aufgesetzt. Damit ändert sich die SID der Domain und damit auch alle SIDs der User, selbst wenn sie gleich heißen. Wenn das so ist, dann sind die DBs nicht fehlerhaft, sondern arbeiten wie entworfen. Es wäre ja auch fatal, wenn man einfach einen anderen DC einem Netz unterschieben könnte und dann auf die DBs Zugriff bekäme.
hth
Erik
Hallo Erik,
Plural? Es sind Euch gleich mehrere schleichend abgeraucht?
Deshalb sollte man seine Backups auch regelmäßig testen.
Ja, wie gesagt: es war eher ein schleichender Prozess. So nach und nach ging es "bergab" und solange das Netz noch einigermaßen stabil war, gab es ja kein Problem. Und Chef meinte, dass ich mich um "wichtige" Sachen kümmern musste - nur nicht um die Domain. Ich bin leider nur "Teilzeit-Admin"
Wirklich eine komplett neue? Schlechte Idee.
Hmm, ich hielt es für die bessere Lösung. Nun ist es leider zu spät(?). Den "alten" Zentyal DC hab ich ja noch als VM, nur nicht mehr aktiv im Netz. Ist damit noch irgendwas zu retten? Zuletzt lief hiermit aber die AD Benutzerverwaltung nicht mehr. Daher der "Schnitt" um eine neue, saubere Domain aufzusetzen.
Vermutlich ist Folgendes passiert: Die Rechte auf die nicht laufenden DBs sind explizite Zugriffsrechte auf NTFS-Ebene bzw. unter Nutzung des AD. Dann sind dort die SIDs der Nutzer, die berechtigt sind, eingetragen. Nun sind aber die SIDs in der Domain RIDs. D. h. ein Teil der SID eines AD-Objekts ist die SID der Domain, der dieses Objekt angehört. Jetzt hast Du eine neue Domain aufgesetzt. Damit ändert sich die SID der Domain und damit auch alle SIDs der User, selbst wenn sie gleich heißen. Wenn das so ist, dann sind die DBs nicht fehlerhaft, sondern arbeiten wie entworfen. Es wäre ja auch fatal, wenn man einfach einen anderen DC einem Netz unterschieben könnte und dann auf die DBs Zugriff bekäme.
OK, Zugriff auf alle Dateien habe ich ja. Der SQL-Server läuft ja auch. Nur das merkwürdige, dass ein Teil der DB aufrufbar sind, andere wiederum nicht - obwohl scheinbar gleich konfiguriert.
Danke.
LG, Uwe
da unsere DomänenController
Plural? Es sind Euch gleich mehrere schleichend abgeraucht?
in einem schleichenden Prozess alle Sicherungen unbrauchbar gemacht haben,
Deshalb sollte man seine Backups auch regelmäßig testen.
Ja, wie gesagt: es war eher ein schleichender Prozess. So nach und nach ging es "bergab" und solange das Netz noch einigermaßen stabil war, gab es ja kein Problem. Und Chef meinte, dass ich mich um "wichtige" Sachen kümmern musste - nur nicht um die Domain. Ich bin leider nur "Teilzeit-Admin"
habe ich einen neuen DC mit neuer Domäne auf MS Windows Server 2019 Essential aufgestellt.
Wirklich eine komplett neue? Schlechte Idee.
Hmm, ich hielt es für die bessere Lösung. Nun ist es leider zu spät(?). Den "alten" Zentyal DC hab ich ja noch als VM, nur nicht mehr aktiv im Netz. Ist damit noch irgendwas zu retten? Zuletzt lief hiermit aber die AD Benutzerverwaltung nicht mehr. Daher der "Schnitt" um eine neue, saubere Domain aufzusetzen.
Sieht nach einem Rechteproblem aus, nur an welcher Stelle setze ich an? Was kann ich prüfen, wie komme ich an detailliertere Fehlermeldungen?
Vermutlich ist Folgendes passiert: Die Rechte auf die nicht laufenden DBs sind explizite Zugriffsrechte auf NTFS-Ebene bzw. unter Nutzung des AD. Dann sind dort die SIDs der Nutzer, die berechtigt sind, eingetragen. Nun sind aber die SIDs in der Domain RIDs. D. h. ein Teil der SID eines AD-Objekts ist die SID der Domain, der dieses Objekt angehört. Jetzt hast Du eine neue Domain aufgesetzt. Damit ändert sich die SID der Domain und damit auch alle SIDs der User, selbst wenn sie gleich heißen. Wenn das so ist, dann sind die DBs nicht fehlerhaft, sondern arbeiten wie entworfen. Es wäre ja auch fatal, wenn man einfach einen anderen DC einem Netz unterschieben könnte und dann auf die DBs Zugriff bekäme.
OK, Zugriff auf alle Dateien habe ich ja. Der SQL-Server läuft ja auch. Nur das merkwürdige, dass ein Teil der DB aufrufbar sind, andere wiederum nicht - obwohl scheinbar gleich konfiguriert.
Danke.
LG, Uwe
Hallo Slainte,
Ja, es wird Windows Authentifizierung verwendet. Nur funktioniert die Eigenschaft der jeweiligen DB auch nicht, so dass ich dort Rechte ändern könnte.
Danke!
LG, Uwe
du musst den Usern/Gruppen aus der neuen Domäne Rechte auf die DBs und die Instanzen geben falls ihr Windows-Auth verwendet.
Ja, es wird Windows Authentifizierung verwendet. Nur funktioniert die Eigenschaft der jeweiligen DB auch nicht, so dass ich dort Rechte ändern könnte.
"Der Zugriff auf die xxx-Datenbank ist nicht möglich. (ObjectExplorer)"
" bei Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.DatabaseNavigableItem.get_CanGetChildren()
bei Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.NavigableItem.RequestChildren(IGetChildrenRequest request)
bei Microsoft.SqlServer.Management.UI.VSIntegration.ObjectExplorer.ExplorerHierarchyNode.BuildChildren(WaitHandle quitEvent)" Danke!
LG, Uwe
Steht dann dazu was im Eventlog oder im Log des SQL Servers?
Moin
Dann überprüfst du die Berechtigungen in den einzelnen Datenbanken und passt diese entsprechend an.
Zitat von @Uwe-Mu:
Hallo Slainte,
Ja, es wird Windows Authentifizierung verwendet. Nur funktioniert die Eigenschaft der jeweiligen DB auch nicht, so dass ich dort Rechte ändern könnte.
Stell in der SQL-Server-Instanz in den Eigenschaften unter Sicherheit auf "SQL-Server und Windowsauthentifizierung-Modus" um.Hallo Slainte,
du musst den Usern/Gruppen aus der neuen Domäne Rechte auf die DBs und die Instanzen geben falls ihr Windows-Auth verwendet.
Ja, es wird Windows Authentifizierung verwendet. Nur funktioniert die Eigenschaft der jeweiligen DB auch nicht, so dass ich dort Rechte ändern könnte.
Dann überprüfst du die Berechtigungen in den einzelnen Datenbanken und passt diese entsprechend an.
Hallo Slainte,
letzte Meldung im Log ist, dass alle DB gestartet wurden:
Der letzte Fehler im Ereignisprotokoll ist von gestern, dass der SQL-Server ein Backup einer dieser DB nicht durchführen konnte.
LG, Uwe
letzte Meldung im Log ist, dass alle DB gestartet wurden:
2019-02-07 10:12:54.54 spid51 Starting up database 'C*C'.
2019-02-07 10:40:38.97 spid51 Starting up database 'C*Q'.
2019-02-07 10:40:41.29 spid51 Starting up database 'E***eb'.
2019-02-07 10:40:42.71 spid51 Starting up database 'M***ft'.
2019-02-07 10:40:44.73 spid51 Starting up database 'Pe***l'.
2019-02-07 10:40:47.37 spid51 Starting up database 'P***A'.
2019-02-07 10:40:50.09 spid51 Starting up database 'Ver***'. Der letzte Fehler im Ereignisprotokoll ist von gestern, dass der SQL-Server ein Backup einer dieser DB nicht durchführen konnte.
LG, Uwe
Moin,
Na super. Das ist so, als sagte ich zu meiner Autowerkstatt: Kümmern Sie sich um die wichtigen Sachen, also nicht um Motor und Bremsen.
Naja, die Konfiguration der DB hat ja nicht unbedingt was mit den Zugriffsrechten zu tun. Ich vermute mal, dass die, die laufen, nicht auf das AD zurückgreifen, während die, auf die kein Zugriff mehr besteht, die zentrale Benutzerverwaltung bemühen. Was zu tun ist, siehe Antwort von @goscho.
Liebe Grüße
Erik
Zitat von @Uwe-Mu:
Ja, wie gesagt: es war eher ein schleichender Prozess. So nach und nach ging es "bergab" und solange das Netz noch einigermaßen stabil war, gab es ja kein Problem. Und Chef meinte, dass ich mich um "wichtige" Sachen kümmern musste - nur nicht um die Domain. Ich bin leider nur "Teilzeit-Admin"
Ja, wie gesagt: es war eher ein schleichender Prozess. So nach und nach ging es "bergab" und solange das Netz noch einigermaßen stabil war, gab es ja kein Problem. Und Chef meinte, dass ich mich um "wichtige" Sachen kümmern musste - nur nicht um die Domain. Ich bin leider nur "Teilzeit-Admin"
Na super. Das ist so, als sagte ich zu meiner Autowerkstatt: Kümmern Sie sich um die wichtigen Sachen, also nicht um Motor und Bremsen.
OK, Zugriff auf alle Dateien habe ich ja. Der SQL-Server läuft ja auch. Nur das merkwürdige, dass ein Teil der DB aufrufbar sind, andere wiederum nicht - obwohl scheinbar gleich konfiguriert.
Naja, die Konfiguration der DB hat ja nicht unbedingt was mit den Zugriffsrechten zu tun. Ich vermute mal, dass die, die laufen, nicht auf das AD zurückgreifen, während die, auf die kein Zugriff mehr besteht, die zentrale Benutzerverwaltung bemühen. Was zu tun ist, siehe Antwort von @goscho.
Liebe Grüße
Erik
Hallo Erik, hallo goscho,
danke erstmal für die Unterstützung.
Ich habe das versucht auf SQL-Auth umzustellen. Also im SQL Server MgrStudio die Instanz, Eigenschaften, Sicherheit die Server-Auth.modus von Windows-Auth auf SQL Serv. und Windows-Auth. umgestellt; dann OK. Dann kommen diese Fehler:
Packe ich an der falschen Stelle an oder gibt es eine andere Möglichkeit?
LG, Uwe
danke erstmal für die Unterstützung.
Ich habe das versucht auf SQL-Auth umzustellen. Also im SQL Server MgrStudio die Instanz, Eigenschaften, Sicherheit die Server-Auth.modus von Windows-Auth auf SQL Serv. und Windows-Auth. umgestellt; dann OK. Dann kommen diese Fehler:
Fehler bei Ändern für Server 'E***1\MSSQL2014A'. (Microsoft.SqlServer.Smo) Ausnahme beim Ausführen einer Transact-SQL-Anweisung oder eines Transact-SQL-Batches. (Microsoft.SqlServer.ConnectionInfo)Die EXECUTE-Berechtigung wurde für das xp_instance_regwrite-Objekt, mssqlsystemresource-Datenbank, sys-Schema, verweigert. (.Net SqlClient Data Provider)Packe ich an der falschen Stelle an oder gibt es eine andere Möglichkeit?
LG, Uwe
Moin,
guck Dir mal die Rechte auf der Dateiebenen an. Ich fürchte, Du als Admin hast noch nicht einmal mehr Rechte an diesen Dateien und deshalb wird Dir der Zugriff verweigert. Wie oben schon erklärt: Auch der Admin und auch der Admin "Administrator" hat eine neue SID, die nicht mit der übereinstimmt, die die Rechte hat.
hth
Erik
guck Dir mal die Rechte auf der Dateiebenen an. Ich fürchte, Du als Admin hast noch nicht einmal mehr Rechte an diesen Dateien und deshalb wird Dir der Zugriff verweigert. Wie oben schon erklärt: Auch der Admin und auch der Admin "Administrator" hat eine neue SID, die nicht mit der übereinstimmt, die die Rechte hat.
hth
Erik
Zitat von @Uwe-Mu:
Schau mal, was meine Google-Suche zu diesem Fehler ergab:Die EXECUTE-Berechtigung wurde für das xp_instance_regwrite-Objekt, mssqlsystemresource-Datenbank, sys-Schema, verweigert. (.Net SqlClient Data Provider)The EXECUTE permission was denied on the object ‘xp_prop_oledb_provider’, database ‘mssqlsystemresource’
Das ist natürlich ein Berechtigungsproblem. Mach aber Sicherungen, bevor du solche Maßnahmen ergreifst!
Hallo goscho,
danke für den Tipp. So wie im Beispiel funktionierte es leider nicht. Wiederum die fehlenden Berechtigungen. Mit den Suchwörtern bin ich aber dann auf diesen Artikel gestoßen:
Hiermit komme ich zumindest erstmal in die Eigenschaften und versuche jetzt die Benutzer neu und vernünftig zuzuordnen. Ich berichte, wenn es Fortschritte gibt.
Nichtsdestotrotz habe ich zusätzlich einen externen IT'ler kontaktiert, der sich diese Misere auch nochmal angucken will - muss mein Chef dann wohl etwas tiefer ins Portemonnaie greifen.
Danke erstmal euch allen.
Gruß, Uwe
danke für den Tipp. So wie im Beispiel funktionierte es leider nicht. Wiederum die fehlenden Berechtigungen. Mit den Suchwörtern bin ich aber dann auf diesen Artikel gestoßen:
Hiermit komme ich zumindest erstmal in die Eigenschaften und versuche jetzt die Benutzer neu und vernünftig zuzuordnen. Ich berichte, wenn es Fortschritte gibt.
Nichtsdestotrotz habe ich zusätzlich einen externen IT'ler kontaktiert, der sich diese Misere auch nochmal angucken will - muss mein Chef dann wohl etwas tiefer ins Portemonnaie greifen.
Danke erstmal euch allen.
Gruß, Uwe
Moin,
Das kommt davon, wenn man den Admin daran hindert, die Domain zu warten.
Liebe Grüße
Erik
Das kommt davon, wenn man den Admin daran hindert, die Domain zu warten.
Liebe Grüße
Erik
Und wenn dann auch noch der SQL-Server nur über die Windows-Auth konfiguriert wurde, wird es noch schlimmer.
PS: Hast du nicht geschrieben, dass es die alte Domäne noch gibt. Wenn dort der SQL-Server noch funktioniert, dann dort die Authentifizierung umstellen und anschließend die Datenbanken erneut sichern und im neuen SQL-Server zurückspielen.
Ich hoffe, du bekommst es hin. Daumendrückend
PS: Hast du nicht geschrieben, dass es die alte Domäne noch gibt. Wenn dort der SQL-Server noch funktioniert, dann dort die Authentifizierung umstellen und anschließend die Datenbanken erneut sichern und im neuen SQL-Server zurückspielen.
Ich hoffe, du bekommst es hin. Daumendrückend
Das kommt davon, wenn man den Admin daran hindert, die Domain zu warten.
Und wenn dann auch noch der SQL-Server nur über die Windows-Auth konfiguriert wurde, wird es noch schlimmer.Muss - glaub ich - nicht unbedingt schlimmer sein. Nur schwieriger an Berechtigungen zu kommen, was manche (und mein Vorgänger wahrscheinlich) ja auch als Sicherheitsfaktor so einbauen.
PS: Hast du nicht geschrieben, dass es die alte Domäne noch gibt. Wenn dort der SQL-Server noch funktioniert, dann dort die Authentifizierung umstellen und anschließend die Datenbanken erneut sichern und im neuen SQL-Server zurückspielen.
Die alte Domäne gibt es eigentlich nicht mehr. Ich habe tägliche Backups vom Server mit den SQLs und auch vom (Zentyal-) DC. Nur die verstanden sich eben zum Schluss absolut gar nicht mehr. Auch die restlichen User kamen nicht mehr zur Domänenanmeldung, ....
Ich hoffe, du bekommst es hin. Daumendrückend
Falls das gleich mit dem o.g. Schema nicht funktioniert, versuche ich auf einer VM oder anderer Hardware den alten (SQL-)Server mit alter Domain nochmal anzuschalten und diese auf zusätzlich SQL-Auth umzustellen. Und danach der Transfer auf einen neuen SQL-Server .....
Es mangelt im Moment an geeigneter Hardware, der den Server nochmal abbilden könnte.
Ich bin zuversichtlich, dass das spätestens am Wochenende wieder läuft ....
... Bericht folgt auf jeden Fall.
Guten Morgen zusammen,
aktueller Stand:
Die Freigabe bzw. die Rechteanpassung auf dem ursprünglichen SQL-Server in der neuen Domäne habe ich nicht hinbekommen.
Meine Lösung war es letztendlich den letzten, lauffähigen Server in eine gekapselte VM zu restoren. Hier habe ich die DBs auf Windows- und zusätzlich SQL-Authentifizierung umgestellt und exportiert.
Diese Backup-DBs auf dem neuen Server (MSWin 2019 und SQL 2016) importiert.
Anmeldung der User an den SQL-Server funktioniert, lediglich ein paar Rechte muss ich noch anpassen, dann sollte alles wieder laufen.
Danke euch nochmals fürs Zuhören und die Unterstützung. Hat auf jeden Fall geholfen diesen Weg zu finden, wenn es vielleicht auch nicht ganz so lief wie gehofft.
Gruß, Uwe
aktueller Stand:
Die Freigabe bzw. die Rechteanpassung auf dem ursprünglichen SQL-Server in der neuen Domäne habe ich nicht hinbekommen.
Meine Lösung war es letztendlich den letzten, lauffähigen Server in eine gekapselte VM zu restoren. Hier habe ich die DBs auf Windows- und zusätzlich SQL-Authentifizierung umgestellt und exportiert.
Diese Backup-DBs auf dem neuen Server (MSWin 2019 und SQL 2016) importiert.
Anmeldung der User an den SQL-Server funktioniert, lediglich ein paar Rechte muss ich noch anpassen, dann sollte alles wieder laufen.
Danke euch nochmals fürs Zuhören und die Unterstützung. Hat auf jeden Fall geholfen diesen Weg zu finden, wenn es vielleicht auch nicht ganz so lief wie gehofft.
Gruß, Uwe
