SQL Server In-Place-Upgrade auf 2022: Vorbereitung, Backup, Upgrade und der ODBC-Driver-17-Fehler

Ein In-Place-Upgrade von SQL Server klingt unkompliziert: Setup starten, Instanz auswählen, fertig. In der Praxis gibt es aber regelmäßig Stolperfallen, allen voran ein bekannter Bug rund um den Microsoft ODBC Driver 17 for SQL Server, der das Upgrade mitten im Lauf abwürgt.

In dieser Anleitung zeige ich dir die komplette Vorbereitung für ein sicheres In-Place-Upgrade auf SQL Server 2022: vom Versionscheck über Backup-Strategie und Snapshot bis zum konkreten Fix für den ODBC-Driver-17-Fehler.

Hinweis: 
Diese Anleitung bezieht sich auf den typischen Pfad SQL Server 2016 (SP3) → SQL Server 2022 unter Windows Server 2022. Der direkte Upgrade-Pfad auf SQL 2022 ist möglich von SQL 2012 SP4, 2014 SP3, 2016 SP3, 2017 und 2019. Ältere Versionen brauchen einen Zwischenschritt über eine unterstützte Version.

Lizenz vor Technik prüfen

Bevor du anfängst, kläre die Lizenzsituation. Ohne Software Assurance (SA) auf deinen aktuellen SQL-Lizenzen darfst du diese nicht für SQL Server 2022 verwenden. Du brauchst dann neu gekaufte SQL-2022-Lizenzen.

Achte außerdem auf das Lizenzmodell (Core-based oder Server + CAL) und auf eventuelle Runtime-Lizenzen, die mit Drittanbieter-Software ausgeliefert werden. Solche Runtime-Lizenzen sind oft an eine bestimmte SQL-Version gebunden. Bei eigenmächtigem Upgrade verlierst du dann Lizenz und Hersteller-Support.

Aktuelle SQL-Version ermitteln

Die installierte SSMS-Version sagt nichts über die SQL-Engine-Version aus. In SSMS auf der Instanz verbinden und ausführen:

SELECT
@@SERVERNAME AS Instanz,
SERVERPROPERTY(‚ProductVersion‘) AS ProductVersion,
SERVERPROPERTY(‚ProductLevel‘) AS PatchLevel,
SERVERPROPERTY(‚Edition‘) AS Edition,
SERVERPROPERTY(‚ProductUpdateLevel‘) AS CU;

Die ProductVersion zeigt dir die genaue Engine-Version. SQL Server 2016 fängt mit 13.x an, 2017 mit 14.x, 2019 mit 15.x, und 2022 mit 16.x.

Hersteller-Freigaben einholen

Vor jedem Upgrade in Produktion:

• Prüfen, ob die Anwendungen, die auf der SQL-Instanz arbeiten, offiziell für SQL Server 2022 freigegeben sind
• Bei ERP- und Branchen-Software gilt das besonders strikt: bei nicht freigegebener SQL-Version verlierst du den Hersteller-Support
• Bei Runtime-SQL-Lizenzen vom Hersteller darfst du die SQL-Version oft gar nicht eigenständig wechseln

Diese Freigaben vor dem geplanten Wartungsfenster schriftlich einholen.

Upgrade-Assessment durchführen

Der frühere Data Migration Assistant (DMA) wurde von Microsoft zum 16. Juli 2025 offiziell eingestellt. Der Nachfolger ist die Migration Component in SSMS 21/22.

Installation:

1. SSMS 22 vom Microsoft Download Center herunterladen
2. Im Installer beim Workload-Auswahlbildschirm „Hybrid and Migration“ mit ankreuzen
3. Nach Installation: Objekt-Explorer → Rechtsklick auf die Instanz → „Migrate SQL Server“ → „Upgrade Assessment“

Das Assessment prüft die Datenbanken auf Breaking Changes, Behavior Changes, Deprecated Features und Migration Blocker. Den Report als JSON oder HTML exportieren und vor dem Upgrade durcharbeiten.

Hinweis: 
Wenn dein Assessment veraltete Datentypen (TEXT, NTEXT, IMAGE) oder unqualifizierte Joins meldet: das sind Hinweise, keine Blocker. Funktioniert auch unter SQL 2022 weiter.

VM-Voraussetzungen prüfen

In einer PowerShell als Admin auf dem Server:

Get-Volume | Select-Object DriveLetter, FileSystemLabel, @{N=’Size_GB‘;E={[math]::Round($_.Size/1GB,2)}}, @{N=’Free_GB‘;E={[math]::Round($_.SizeRemaining/1GB,2)}} | Format-Table -AutoSize

Brauchen wirst du:

• Mindestens 10–15 GB frei auf C: für die SQL-2022-Binaries
• Genug Platz für ein Full-Backup aller Datenbanken, idealerweise auf einer separaten Disk

Außerdem auf ausstehende Neustarts prüfen:

$pendingReboot = $false
if (Get-ItemProperty „HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending“ -ErrorAction SilentlyContinue) { $pendingReboot = $true }
if (Get-ItemProperty „HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired“ -ErrorAction SilentlyContinue) { $pendingReboot = $true }
if (Get-ItemProperty „HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager“ -Name „PendingFileRenameOperations“ -ErrorAction SilentlyContinue) { $pendingReboot = $true }
Write-Host „Pending Reboot: $pendingReboot“

Bei Pending Reboot: True weigert sich das SQL-Setup zu starten. Vor dem Wartungsfenster einmal sauber durchstarten und nochmal prüfen.

Backup-Strategie: mehrere Ebenen

Für Produktiv-Systeme empfehle ich drei Sicherungsebenen:

1. Aktuelles Backup über das übliche Backup-Tool (z. B. Veeam): Application-Aware Processing aktivieren, damit SQL-konsistent gesichert wird
2. VMware- oder Hyper-V-Snapshot unmittelbar vor dem Upgrade: schnellster Rollback-Anker
3. Native SQL-Backups aller User-DBs und der System-DBs (master, model, msdb) auf eine separate Disk

Für die nativen Backups:

BACKUP DATABASE [DeineDB]
TO DISK = N’G:\Backup-PreUpgrade\DeineDB_PreUpgrade.bak‘
WITH INIT, COMPRESSION, STATS=10;

BACKUP DATABASE [master]
TO DISK = N’G:\Backup-PreUpgrade\master.bak‘
WITH INIT, COMPRESSION;

BACKUP DATABASE [model]
TO DISK = N’G:\Backup-PreUpgrade\model.bak‘
WITH INIT, COMPRESSION;

BACKUP DATABASE [msdb]
TO DISK = N’G:\Backup-PreUpgrade\msdb.bak‘
WITH INIT, COMPRESSION;

Tipp: Eine temporäre VMDK für das Pre-Upgrade-Backup anlegen. Nach erfolgreichem Upgrade und ein paar Tagen stabilem Betrieb kann diese wieder gelöscht werden. So wächst deine bestehende Daten-Disk nicht dauerhaft mit, was unter VMware nachträglich schwer rückgängig zu machen ist.

DBCC CHECKDB vor dem Upgrade

Vor jedem Upgrade die Konsistenz aller User-Datenbanken prüfen:

DBCC CHECKDB WITH NO_INFOMSGS, ALL_ERRORMSGS;

Keine Ausgabe heißt: alles in Ordnung. Findet CHECKDB Fehler, müssen die vor dem Upgrade behoben werden.

Snapshot ziehen – richtig

Direkt vor dem eigentlichen Upgrade:

1. Anwendungen stoppen, die auf SQL zugreifen
2. Aktive Verbindungen prüfen: EXEC sp_who2;  nur SQL-System-Prozesse sollten übrig sein
3. SQL Server Agent stoppen
4. SQL Server-Dienst stoppen (für sauberen Snapshot)
5. Im vSphere oder Hyper-V einen Snapshot anlegen
6. Memory: Nein, Quiesce: Ja
7. Sinnvoller Snapshot-Name mit Datum (z. B. Pre-SQL2022-Upgrade_2026-05-16)
8. SQL Server-Dienste wieder starten

Der Upgrade-Lauf

ISO mounten, setup.exe als Administrator starten, dann:

1. Installation → „Upgrade from a previous version of SQL Server“
2. Product Key: den neuen SQL-2022-Key eingeben (nicht den vorausgefüllten alten Key!)
3. Lizenzart: „Ich habe nur eine SQL Server-Lizenz“ (sofern kein SA)
4. Instanz auswählen
5. Features bleiben automatisch wie vorher
6. Service-Accounts unverändert lassen
7. Upgrade starten

Jetzt kommt die kritische Phase. Genau hier kann der ODBC-Driver-17-Fehler auftauchen.

Der ODBC-Driver-17-Fehler beim Setup

Während des Upgrade-Laufs erscheint folgender Dialog:

Microsoft ODBC Driver 17 for SQL Server
Der Pfad „C:\Windows\Temp\IXP000.TMP\msodbcsql.msi“ wurde nicht gefunden.

Oder kurz danach:

Die Datei „…“ ist kein gültiges Installationspaket für das Produkt
„Microsoft ODBC Driver 17 for SQL Server“.

Das passiert, weil das Setup die ODBC-Driver-MSI aus dem Windows-TEMP-Ordner erneut lesen will, aber die wurde dort schon weggeräumt (Antivirus, Storage-Cleanup oder Drittsoftware). Eine frisch heruntergeladene ODBC-17-MSI von Microsoft hilft auch nicht, weil Windows Installer den exakten Product Code der bereits installierten Version erwartet, eine neuere 17.x hat eine andere GUID und wird abgelehnt.

Wichtig: Den Dialog offen lassen. NICHT auf Abbrechen klicken. Sonst rollt das gesamte Upgrade zurück und du fängst von vorn an.

Schritt 1: Cache-Pfad der originalen MSI finden

Parallel eine PowerShell als Administrator öffnen und folgenden Befehl ausführen:

Get-WmiObject -Class Win32_Product -Filter „Name LIKE ‚%ODBC Driver 17%'“ | Select-Object Name, Version, LocalPackage | Format-List

Der Befehl braucht ein paar Sekunden. Der Output sieht in etwa so aus:

Name : Microsoft ODBC Driver 17 for SQL Server
Version : 17.10.6.1
LocalPackage : C:\Windows\Installer\5b8a2324.msi

Der LocalPackage-Pfad zeigt auf die gecachte Original-MSI mit dem passenden Product Code. Das ist genau die Datei, die das Setup braucht.

Schritt 2: MSI kopieren und umbenennen

Das Setup sucht nach einer Datei mit dem Namen msodbcsql.msi. Die gecachte Version heißt aber zufällig. Also kopieren und umbenennen:

New-Item -ItemType Directory -Path „C:\Temp\ODBC17“ -Force
Copy-Item -Path „C:\Windows\Installer\5b8a2324.msi“ -Destination „C:\Temp\ODBC17\msodbcsql.msi“ -Force

Den Pfad aus LocalPackage natürlich an dein System anpassen.

Schritt 3: Im Setup-Dialog auf die neue MSI zeigen

Zurück im SQL-Setup-Dialog:

1. Auf „Durchsuchen…“ klicken
2. In die Adressleiste oben den Pfad eintippen: C:\Temp\ODBC17
3. Datei msodbcsql.msi auswählen
4. OK

Das Setup verifiziert die MSI, findet den passenden Product Code und läuft weiter. Die Engine-Installation selbst war zu diesem Zeitpunkt meistens schon erfolgreich. Der ODBC-Driver wird nur als letzter Schritt nachgezogen.

Verifikation nach dem Upgrade

Sobald das Setup grün abschließt, in SSMS reconnecten und prüfen:

SELECT @@VERSION;
SELECT name, state_desc, compatibility_level FROM sys.databases;

Erwartung:

• @@VERSION zeigt Microsoft SQL Server 2022 und eine 16.x-Version
• Alle Datenbanken ONLINE
• Compatibility Level deiner User-DBs bleibt unverändert. Das ist Absicht

Compatibility Level NICHT sofort anheben

Auch wenn es verlockend ist: lass den Compatibility Level deiner User-Datenbanken erstmal so wie er war (z. B. 110 oder 130). SQL Server 2022 unterstützt ältere Compat-Levels problemlos.

Der Grund: der neue Cardinality Estimator in höheren Compat-Levels kann unerwartete Performance-Regressionen verursachen. Die Compat-Level-Anhebung machst du später in einem separaten Schritt mit Performance-Monitoring per Query Store. Erst Stabilität, dann Optimierung.

Post-Upgrade-Schritte

— Konsistenzcheck nach Upgrade
DBCC CHECKDB WITH NO_INFOMSGS, ALL_ERRORMSGS;

— Statistiken aktualisieren
EXEC sp_updatestats;

Außerdem:

• Latest Cumulative Update (CU) für SQL Server 2022 einspielen, das Setup installiert üblicherweise nur die RTM-Version (16.0.1000.6)
• SQL Server Agent wieder starten
• Anwendungen hochfahren
• Smoke-Test durch einen Key-User
• Setup-Logs sichern aus C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\Log\

Snapshot zeitnah löschen

VMware- und Hyper-V-Snapshots wachsen mit jedem Schreibvorgang und bremsen die Performance der VM. Spätestens nach 2–3 Tagen stabilem Betrieb den Snapshot löschen. Dein normales Backup-Tool dient ab dann als Rollback-Versicherung.

Fazit

Ein SQL-Server-In-Place-Upgrade ist mit der richtigen Vorbereitung gut beherrschbar. Wichtig sind drei Dinge: saubere Voraussetzungsprüfung (Lizenz, Reboot, Speicherplatz, Hersteller-Freigaben), mehrschichtige Backups (Backup-Tool + Snapshot + native SQL-Backups) und ein klarer Rollback-Plan über den Snapshot.

Der ODBC-Driver-17-Stolperstein während des Setups ist ärgerlich, aber mit dem MSI-aus-dem-Windows-Installer-Cache-Trick schnell behoben. Wenn du den Dialog während des Setups einfach offen lässt, hast du Zeit für den Fix, ohne das ganze Upgrade neu starten zu müssen.

Falls du beim Upgrade auf andere Stolpersteine triffst oder noch eine elegantere Lösung für das ODBC-Problem kennst, schreib mir gerne in den Kommentaren. Ich nehme die Punkte gerne mit in den Artikel auf.