VBScript-Abschaffung: Prüfleitfaden für VBA und interne Tools

Zusammenfassung

Mit „internen Tools“ ist in diesem Artikel nicht nur von Excel-Makros oder .vbs-Dateien die Rede. Gemeint sind auch GPO-Anmeldeskripte, in der Aufgabenplanung registrierte Aufgaben, per Intune verteilte Skripte und VBScript-Custom-Actions in MSI-Paketen. Auch wenn Sie sich nicht erinnern, selbst VBScript geschrieben zu haben, sind Sie betroffen, sobald in einem dieser Bereiche .vbs verborgen ist.

Stand April 2026 hat Microsoft öffentlich eine stufenweise Abschaffung von VBScript angekündigt: In Windows 11 Version 24H2 ist es zunächst als Feature on Demand standardmäßig aktiviert, in der nächsten Stufe standardmäßig deaktiviert, und in der letzten Stufe soll es aus einer künftigen Windows-Version entfernt werden. Das eigentlich Wichtige jetzt ist also nicht das „vollständige Umschreiben“, sondern zunächst „sichtbar zu machen, wo VBScript-Abhängigkeiten bestehen“.

Zum Zeitpunkt sind keine festen Termine veröffentlicht. In Microsofts Hinweisen für VBA wird Phase 2 (standardmäßige Deaktivierung des FOD) mit „etwa 2026–2027“ angegeben, Phase 3 (Entfernung) mit „TBD (noch offen)“. Das heißt: Man kann bei diesem Thema nicht vom Datum her rückrechnen, „bis wann es erledigt sein muss“. Mit zunehmender Verbreitung von Geräten mit Windows 11 24H2 und neuer rückt die Frist näher — unter dieser Annahme sollte zumindest die Bestandsaufnahme vorgezogen werden.

Bei VBA und Excel-Makros gibt es im Kern zwei praktische Fragestellungen. Die eine sind Fälle, in denen .vbs extern ausgeführt wird, die andere sind Verweise auf VBScript-artige Bibliotheken wie VBScript.RegExp. Für Letzteres gilt: Ab Office Version 2508 (Build 19127.20154) ist die Klasse RegExp standardmäßig in der VBE enthalten, wodurch sich zumindest ein Teil der RegExp-Abhängigkeit leichter migrieren lässt. In gemischten Umgebungen, in denen ältere Office-Clients verbleiben, kann jedoch dasselbe VBA auf manchen Geräten laufen und auf anderen nicht.

Was die Migration schwierig macht, ist weniger VBScript selbst als „das Drumherum im Betrieb“. Ersetzen Sie beispielsweise den Aufruf von powershell.exe aus Excel heraus, scheitert das im Produktivbetrieb, sobald es an den Regeln zur Reduzierung der Angriffsfläche „Erstellung untergeordneter Prozesse durch Office-Anwendungen blockieren“ oder „Win32-API-Aufrufe aus Office-Makros blockieren“, an AppLocker, App Control for Business, der PowerShell-Ausführungsrichtlinie, der Signaturverwaltung oder der Makrokontrolle für Dateien mit Mark of the Web (MOTW) hängen bleibt. Der Migrationsplan sollte deshalb nicht nur die Codeumstellung umfassen, sondern auch Richtlinien, Signierung und Protokollauswertung.

Der kürzeste Weg ist Bestandsaufnahme → statische Erkennung → Erfassung von Ausführungsprotokollen → Auswahl der Ersatztechnologie → Test → stufenweises Rollout. Dieser Artikel ordnet die Praxis in dieser Reihenfolge.

Der in diesem Artikel gezeigte Code ist zudem als lauffähiges, testbares Beispielpaket (PowerShell-Audit-Skripte, Ersatzbeispiele, Referenzcode für VBA und Office Scripts, Pester-Tests) auf GitHub veröffentlicht.

vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide - komurasoft-blog-samples (GitHub)

Mini-Glossar der Begriffe

In den folgenden Abschnitten tauchen laufend Abkürzungen aus dem Bereich der Windows-Sicherheitsfunktionen auf. Wer sich diese vorab merkt, liest den Rest leichter.

Was sich ändert

Zuerst sollte man festhalten: Diesmal geht es nicht darum, dass „VBA abgeschafft wird“. Was Microsoft veröffentlicht hat, ist ausschließlich die stufenweise Abschaffung von VBScript; die Auswirkung auf VBA-Projekte konzentriert sich hauptsächlich auf die Ausführung externer .vbs-Dateien und auf Verweise auf VBScript-Bibliotheken. Auch der Microsoft 365 Developer Blog nennt die .vbs-Ausführung aus VBA und die Nutzung von VBScript.RegExp als die repräsentativen Auswirkungsbereiche.

Für die praktische Priorisierung lässt sich diese Tabelle gut als Entscheidungshilfe nutzen.

Diese Priorisierung ist eine praktische Einschätzung auf Basis des Windows-seitigen VBScript-Abschaffungsplans, der offiziellen Erkennungsstrategie sowie der Spezifikationen von ASR/AppLocker/App Control.

Bei RegExp liegt der Fall etwas anders. Ab Office Version 2508 ist die Klasse RegExp standardmäßig in der VBE enthalten, sodass sich speziell für RegExp-Anwendungsfälle „ein Teil der VBScript-Abhängigkeit durch ein Office-Update auflösen lässt“. Das löst sich jedoch nicht automatisch in Organisationen mit älterem Office, langsamen Update-Kanälen, gemischten Umgebungen oder veralteten Geräte-Images. Wichtig ist, sowohl „das Office-Update“ als auch „die Windows-seitige Stufenumstellung“ in das Register aufzunehmen.

Vorgehen bei der Bestandsaufnahme

Eine Bestandsaufnahme allein über die Dateinamensuche reicht nicht aus. Es empfiehlt sich, mindestens die folgenden zehn Gesichtspunkte je Vorhaben, je Tool und je Geschäftsprozess als Spalten zu führen.

• ① Methode zur Erkennung von VBScript-Abhängigkeiten Dateisuche, Codeanalyse und Protokollanalyse getrennt dokumentieren.
• ② Nutzung von CreateObject / GetObject / Execute / ExecuteGlobal usw. innerhalb von VBA Die Abhängigkeit versteckt sich in Zeichenketten, weshalb die statische Suche leicht Lücken lässt.
• ③ Aufruf externer Skripte aus Excel-Makros WScript.Shell, die Funktion Shell, wscript.exe / cscript.exe sowie .vbs / .js / .ps1 getrennt erfassen.
• ④ Skriptabhängigkeiten interner Batch-Jobs und Tools Aufgabenplanung, GPO, Intune, Betriebsskripte auf Freigabeordnern und Installationsprogramme einschließen.
• ⑤ Sicherheit, Berechtigungen, Signierung, Richtlinien AppLocker, App Control for Business, ASR, PowerShell-Ausführungsrichtlinie, digitale Signaturen, Notwendigkeit von Administratorrechten.
• ⑥ Vergleich von Ersatztechnologie und Migrationskosten Native VBA, PowerShell, .NET/VSTO, Office Scripts und Power Automate gegenüberstellen.
• ⑦ Testplan Unit-, Integrations-, Abnahmetests und erneute Tests nach Anwendung der Richtlinien getrennt planen.
• ⑧ Betriebsverfahren und Rollback Klar dokumentieren, was zurückgesetzt werden muss, um wiederherzustellen, und wie weit automatisiert wird.
• ⑨ Kompatibilität und Leistung Unterschiede zwischen Office-Versionen, 32/64-Bit, Gerätleistung, Protokollierungslast, Timeouts von Cloudflows.
• ⑩ Beispielhafte Migrations-Fallstudie Ein repräsentatives Beispiel vorbereiten, das sich zur Erklärung im Betrieb eignet.

Von diesen zehn Punkten werden insbesondere GPO, Aufgabenplanung, per Intune verteilte Skripte, MSI-Custom-Actions sowie die Erkennung über Sysmon/AppLocker/App Control in Microsofts offizieller Anleitung ausdrücklich als Schwerpunktbereiche genannt.

Der Gesamtablauf der Migration bleibt konsistent, wenn man ihn wie in der Abbildung durchdenkt.

flowchart TD
    A[Bestandsaufnahme] --> B{Art der Abhängigkeit}
    B -->|Externe .vbs-Ausführung| C[Ersatz durch PowerShell oder natives VBA]
    B -->|VBScript.RegExp| D[Konsolidierung auf das eingebaute RegExp ab Office 2508+]
    B -->|GPO / Aufgabe / MSI| E[Zentral verwaltete Einstellungen und verteilte Artefakte korrigieren]
    B -->|Unbekannt / verborgene Abhängigkeit| F[Ausführungsprotokolle via Sysmon / AppLocker / App Control erfassen]
    C --> G[Unit-Test]
    D --> G
    E --> H[Integrationstest]
    F --> H
    H --> I[Pilotbetrieb im Überwachungsmodus]
    I --> J[Stufenweise Deaktivierung des VBScript-FOD]

Für Umgebungen, in denen die Abbildung nicht angezeigt wird, hier drei Zeilen zur Zusammenfassung:

1. Die bei der Bestandsaufnahme gefundenen Abhängigkeiten in vier Kategorien einteilen: externe .vbs-Ausführung / VBScript.RegExp / zentral verwaltete Einstellungen (GPO, Aufgaben, MSI) / unbekannt
2. Für jede Kategorie die Ersatztechnologie festlegen, den Unit-Test durchlaufen lassen und anschließend in den Integrationstest überführen
3. Im Überwachungsmodus als Pilot ausrollen und, wenn keine Probleme auftreten, das VBScript-FOD stufenweise deaktivieren

Mit dieser Reihenfolge lässt sich der typische Rückschlag „erst umgeschrieben, dann später an GPO oder ASR gescheitert“ deutlich reduzieren.

Praktische Erkennung und Codebeispiele

Dateisuche und Erfassung der Konfiguration

Microsofts Erkennungsanleitung empfiehlt, .vbs rekursiv zu durchsuchen und dabei Pfade mit klarem Verwendungszweck zu priorisieren — C:\Users, C:\ProgramData, C:\Scripts und Ähnliches —, sowie GPO, Aufgabenplanung, per Intune verteilte Skripte und MSI-Pakete auf separaten Wegen zu prüfen. Die Überwachung von vbscript.dll über Sysmon ist wirksam, doch die Image-Load-Überwachung erzeugt ein hohes Protokollvolumen und eine hohe Betriebslast, weshalb sie zunächst in einem kleinen Pilotprojekt validiert werden sollte.

# Skriptabhängigkeiten auf Geräten und Freigabeordnern grob durchsuchen
$paths = @("C:\Users", "C:\ProgramData", "C:\Scripts")
$patterns = @(
  'wscript\.exe',
  'cscript\.exe',
  '\.vbs(\s|$)',
  'VBScript\.RegExp',
  'WScript\.Shell',
  'CreateObject\("VBScript\.RegExp"\)',
  'ExecuteGlobal'
)

$hits = foreach ($path in $paths) {
  if (Test-Path $path) {
    Get-ChildItem -Path $path -Recurse -File `
      -Include *.vbs,*.ps1,*.bat,*.cmd,*.wsf,*.hta,*.txt `
      -ErrorAction SilentlyContinue |
      Select-String -Pattern $patterns -AllMatches |
      Select-Object Path, LineNumber, Line
  }
}

$hits | Export-Csv .\vbscript-dependency-hits.csv -NoTypeInformation -Encoding UTF8

Als Nächstes wird die Aufgabenplanung durchsucht. Bei internen Tools ist häufiger als in Dateien wscript.exe / cscript.exe / .vbs in den Aufgabendefinitionen selbst verborgen.

# VBScript-Aufrufe aus der Aufgabenplanung extrahieren
Get-ScheduledTask | ForEach-Object {
  foreach ($a in $_.Actions) {
    if ($a.Execute -match 'wscript|cscript|mshta' -or $a.Arguments -match '\.vbs\b') {
      [pscustomobject]@{
        TaskName  = $_.TaskName
        TaskPath  = $_.TaskPath
        Execute   = $a.Execute
        Arguments = $a.Arguments
      }
    }
  }
} | Export-Csv .\task-vbscript-dependencies.csv -NoTypeInformation -Encoding UTF8

VBA-Code-Analyse

Auf der VBA-Seite reicht ein Blick auf die Verweise allein nicht aus. CreateObject und GetObject können COM-Objekte über eine Zeichenkette starten, sodass eine Abhängigkeit bestehen kann, ohne dass in den Verweisen etwas auftaucht. Auch Microsofts VBA-/Office-Dokumentation beschreibt CreateObject als grundlegendes Mittel zum Erzeugen von COM-Objekten, und auch FileSystemObject und Scripting.Dictionary werden auf diese Weise genutzt. Um ein VBA-Projekt programmgesteuert zu lesen, ist zudem „Zugriff auf das VBA-Projektobjektmodell vertrauen“ erforderlich.

' Voraussetzungen:
'  - Im Trust Center "Zugriff auf das VBA-Projektobjektmodell vertrauen" aktivieren
'  - Geschützte Projekte erfordern separat einen Quellcode-Export oder eine Rücksprache mit dem Verantwortlichen
Sub ScanProjectForVbScriptRisks()

    Dim comp As Object
    Dim cm As Object
    Dim ws As Worksheet
    Dim nextRow As Long
    Dim patterns As Variant
    Dim p As Variant
    Dim i As Long
    Dim lineText As String

    patterns = Array( _
        "CreateObject(""VBScript.RegExp"")", _
        "VBScript.RegExp", _
        "WScript.Shell", _
        "Shell(", _
        ".vbs", _
        "wscript.exe", _
        "cscript.exe", _
        "ExecuteGlobal", _
        "Execute(" _
    )

    Set ws = ThisWorkbook.Worksheets.Add
    ws.Range("A1:D1").Value = Array("Module", "Line", "Pattern", "Code")
    nextRow = 2

    For Each comp In ThisWorkbook.VBProject.VBComponents
        Set cm = comp.CodeModule

        For i = 1 To cm.CountOfLines
            lineText = cm.Lines(i, 1)
            For Each p In patterns
                If InStr(1, lineText, CStr(p), vbTextCompare) > 0 Then
                    ws.Cells(nextRow, 1).Value = comp.Name
                    ws.Cells(nextRow, 2).Value = i
                    ws.Cells(nextRow, 3).Value = p
                    ws.Cells(nextRow, 4).Value = lineText
                    nextRow = nextRow + 1
                End If
            Next p
        Next i
    Next comp

    ws.Columns.AutoFit
    MsgBox "Scan finished: " & (nextRow - 2) & " hits"

End Sub

Dieser Scan erfasst mindestens CreateObject("VBScript.RegExp"), WScript.Shell, Shell(, .vbs und ExecuteGlobal. Besonders die zeichenkettenbasierte Ausführung über Execute / ExecuteGlobal ist ein Nährboden für übersehene Abhängigkeiten, da Ziel und ausgeführter Code dynamisch zusammengesetzt werden.

Protokollanalyse

In der Phase der Ausführungsprotokoll-Auswertung ist die Kombination aus Sysmon + AppLocker/App Control wirkungsvoll. Sysmon lässt sich über Event ID 7 verfolgen, wenn vbscript.dll geladen wird, und AppLocker macht Erlaubnis-/Überwachungsereignisse für Skripte und MSI-Pakete in der Ereignisanzeige sichtbar. Läuft App Control for Business im Überwachungsmodus, werden Skripte und MSI-Pakete im Protokoll AppLocker\MSI and Script erfasst.

# Sysmon: Prozesse ermitteln, die vbscript.dll geladen haben
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 2000 |
  Where-Object { $_.Id -eq 7 -and $_.Message -match 'vbscript\.dll' } |
  Select-Object TimeCreated, MachineName, Message

# AppLocker / App Control: Überwachungsprotokolle zu Skripten und MSI-Paketen prüfen
Get-WinEvent -LogName "Microsoft-Windows-AppLocker/MSI and Script" -MaxEvents 2000 |
  Where-Object { $_.Id -in 8005, 8006 } |
  Select-Object TimeCreated, Id, Message

Wichtig ist hierbei, nicht nur die „es läuft“-Protokolle zu sammeln, sondern auch die Protokolle, die zeigen, dass es „im Überwachungsmodus gestoppt worden wäre“. Die Überwachungsereignisse von AppLocker und der Überwachungsmodus von App Control eignen sich gut für die Sicherheitsprüfung vor einer Blockierung im Produktivbetrieb.

Minimalbeispiele für den Ersatz

Für eine Verarbeitung, die im Wesentlichen ein externes .vbs aufruft, um eine CSV-Datei zu schreiben, ist der Ersatz durch natives VBA der kürzeste Weg.

Sub ExportCsvNativeVba()

    Dim f As Integer
    Dim outPath As String

    outPath = ThisWorkbook.Path & "\out.csv"
    f = FreeFile

    Open outPath For Output As #f
    Print #f, "Code,Name"
    Print #f, "1001,Tokyo"
    Print #f, "1002,Osaka"
    Close #f

    MsgBox "CSV exported: " & outPath

End Sub

Muss aus Excel heraus externe Verarbeitung aufgerufen werden, die das Betriebssystem, Freigabeordner, AD, Installationsprogramme oder Protokollerfassung einschließt, ist der Umstieg auf PowerShell realistischer. Microsoft empfiehlt PowerShell als Ersatz für VBScript, und auf der PowerShell-Seite gibt es offizielle Verfahren für Ausführungsrichtlinie, Signierung und Authenticode-Prüfung. Zu beachten ist, dass VBAs Shell standardmäßig asynchron arbeitet; wo eine Reihenfolge eingehalten werden muss, ist separat ein Ablaufdesign oder eine Wartelogik erforderlich.

Sub RunModernPs()

    Dim cmd As String
    cmd = "powershell.exe -NoProfile -File """ & ThisWorkbook.Path & "\Normalize.ps1""" & _
          " -InputFile """ & ThisWorkbook.Path & "\in.csv""" & _
          " -OutputFile """ & ThisWorkbook.Path & "\out.csv"""

    Shell cmd, vbNormalFocus

End Sub

param(
  [string]$InputFile,
  [string]$OutputFile
)

Import-Csv $InputFile |
  Sort-Object Code |
  Export-Csv $OutputFile -NoTypeInformation -Encoding UTF8

# Signatur anbringen und prüfen
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\Normalize.ps1 -Certificate $cert
Get-AuthenticodeSignature -FilePath .\Normalize.ps1

Läuft die Excel-Verarbeitung vollständig innerhalb der Arbeitsmappe ab — Formatierung, Aggregation, Umwandlung —, sind auch Office Scripts eine starke Option. Office Scripts sind für Excel ausgelegt und eignen sich für cloudbasierte, plattformübergreifende Nutzung sowie die Anbindung an Power Automate.

function main(workbook: ExcelScript.Workbook) {
  const sheet = workbook.getActiveWorksheet();
  const used = sheet.getUsedRange();
  used.getFormat().autofitColumns();

  const tables = workbook.getTables();
  if (tables.length > 0) {
    tables[0].getSort().apply([{ key: 0, ascending: true }], true);
  }
}

Auswahl der Ersatztechnologie

Die Ersatztechnologie sollte nicht danach ausgewählt werden, „womit man schreiben kann“, sondern danach, welchen Verantwortungsbereich sie übernehmen soll. PowerShell liegt näher bei Windows, Dateien, Aufgaben und Installationsprogrammen; natives VBA liegt näher am Inneren von Office; Office Scripts liegen näher an der Verarbeitung innerhalb der Excel-Arbeitsmappe; VSTO/.NET liegt näher an tiefer Desktop-Integration; Power Automate liegt näher an der Orchestrierung. Die folgende Tabelle ist eine praktische Einschätzung auf Basis der offiziell veröffentlichten Eigenschaften der einzelnen Ansätze. Die Aufwandsangaben sind grobe Richtwerte des Autors.

Als Maßstab für den Aufwand gilt: Er bezieht sich auf die Migration eines einzelnen Tools (ein Makro oder ein Skript). Niedrig bedeutet einige Tage, mittel einige Wochen, hoch ein bis mehrere Monate. Bei zehn betroffenen Tools summiert sich das entsprechend.

Die Auswahlrichtlinie lässt sich noch etwas anschaulicher darstellen:

flowchart TD
    A[Gefundene VBScript-Abhängigkeit] --> B{Läuft vollständig innerhalb der Excel-Arbeitsmappe ab?}
    B -->|Ja| C[Natives VBA]
    B -->|Ja, und Freigabe/Cloud wichtig| D[Office Scripts]
    B -->|Nein| E{Berührt Betriebssystem, Dateien, Aufgaben, AD?}
    E -->|Ja| F[PowerShell]
    E -->|Nein| G{Aufwendige UI-Integration oder langlebiges Add-in?}
    G -->|Ja| H[.NET / VSTO]
    G -->|Ausgelöst durch Ablauf oder Freigabe| I[Power Automate]

Auch das lässt sich in drei Zeilen zusammenfassen:

1. Läuft es vollständig innerhalb der Excel-Arbeitsmappe ab, natives VBA verwenden. Stehen Freigabe oder Cloud-Ausführung im Vordergrund, Office Scripts.
2. Berührt es das Betriebssystem, Dateien, Aufgaben oder AD, PowerShell verwenden.
3. Bei aufwendiger UI-Integration oder langlebigen Add-ins .NET / VSTO; bei Auslösung durch einen Ablauf oder mit Fokus auf Freigaben Power Automate.

Nur zu RegExp noch eine Ergänzung: In einer Umgebung, in der ausschließlich Office Version 2508 oder neuer vorhanden ist, ist die Konsolidierung auf Dim re As RegExp / Set re = New RegExp recht wirkungsvoll. Bleibt jedoch auch nur ein Gerät mit älterem Office übrig, stößt dieser Code an die Kompilierkompatibilitätsgrenze. In gemischten Umgebungen sollte vorab entschieden werden, ob die Migrationsstrategie „neue Syntax“, „alte Syntax“ oder „verzweigender Wrapper“ lautet.

Test und Betrieb

Testplan

Bei einer VBScript-Migration reicht ein Unit-Test allein nicht aus. Ohne einen erneuten Test unter produktionsnahen Bedingungen mit aktiven Sicherheitsrichtlinien stoppt das ersetzende PowerShell- oder .NET-Skript aus einem ganz anderen Grund. Auch Microsofts Unterlagen behandeln PowerShell-Ausführungsrichtlinie, AppLocker, den Überwachungsmodus von App Control, ASR und die Makrokontrolle für MOTW-gekennzeichnete Dateien als jeweils eigenständige Regeln.

Besonders leicht übersehen werden diese Punkte:

• Ein Ersatz, bei dem Excel PowerShell startet, kann an der ASR-Regel „Erstellung untergeordneter Prozesse durch Office-Anwendungen blockieren“ scheitern.
• Bleiben VBA-Deklarationen oder API-Aufrufe bestehen, kann das an der ASR-Regel „Win32-API-Aufrufe aus Office-Makros blockieren“ scheitern.
• Über Download oder E-Mail-Anhang verteilte Test-.xlsm-/.ps1-Dateien verhalten sich je nach MOTW- und Signaturstatus unterschiedlich.
• Die Kombination aus Office Scripts und Power Automate ist praktisch, doch bei großen CSV-Dateien oder sehr vielen Zellen müssen Timeouts und Datenübertragungsgrenzen berücksichtigt werden.
• Die Image-Load-Überwachung von Sysmon ist nützlich, erzeugt aber, unbedacht auf das ganze Unternehmen ausgeweitet, schnell ein hohes Protokollvolumen.

Checkliste für den Migrationsablauf

• Statisch nach .vbs, wscript.exe, cscript.exe, VBScript.RegExp, WScript.Shell, Shell(, ExecuteGlobal gesucht
• GPO, Aufgabenplanung, Intune, Betrieb über Freigabeordner und MSI-Pakete separat erfasst
• Office-Version und Update-Kanal in einem Register erfasst und den Bestand unter 2508 ermittelt
• Ersatztechnologie unter „natives VBA / PowerShell / .NET / Office Scripts / Power Automate“ festgelegt
• Signaturrichtlinie und Verteilungsstrategie für Zertifikate festgelegt
• Auswirkungen von AppLocker / App Control / ASR / Ausführungsrichtlinie getestet
• Überwachungsprotokolle in einer Pilotabteilung erfasst
• Rollback-Verfahren dokumentiert
• Vor der Deaktivierung des VBScript-FOD den Nachweis „nicht mehr verwendet“ hinterlegt

Risiken und Gegenmaßnahmen

Die Gegenmaßnahmen in dieser Tabelle übertragen die in Microsofts offiziellen Unterlagen genannten Designeinschränkungen in den internen Betrieb.

Rollback bedeutet mehr als nur „den Code zurücksetzen“. Mindestens sollten die Wiederherstellung früherer Versionen der verteilten Artefakte, das Zurücksetzen der Richtlinien, der Spielraum zur erneuten Aktivierung der optionalen Funktion und die fortgesetzte Protokollerfassung als Einheit betrachtet werden. Solange VBScript noch als FOD existiert, lässt es sich gemäß den Hinweisen zu Phase 2 als optionale Funktion wieder aktivieren; ist es in Phase 3 entfernt, entfällt dieser Ausweg.

Beispielhafte Migrations-Fallstudie

Als typisches Beispiel dient das monatliche Summenmakro der Buchhaltungsabteilung. Aktuell startet das Excel-Makro über WScript.Shell das Skript cleanup.vbs, prüft nach der CSV-Formatierung Codes mit VBScript.RegExp und schreibt das Ergebnis abschließend in einen Freigabeordner. Dieser Aufbau ist von der VBScript-Abschaffung unmittelbar betroffen, und selbst eine einfache Portierung auf PowerShell bleibt leicht erneut an ASR oder der Signaturverwaltung hängen.

Damit sich das Thema überhaupt in einer Vorlage begründen lässt, werden hier zur Veranschaulichung angenommene Zahlen aufgeführt. Die tatsächlichen Werte ergeben sich aus der Bestandsaufnahme, aber in dieser Detailtiefe lässt sich der Text direkt als Grundlage für einen Zeitplan verwenden.

Dass die Dauer länger ist als der Aufwand, liegt an der Monatsverarbeitung. Auch wenn der Unit-Test an einem Tag abgeschlossen ist, lässt sich „stimmt das Ergebnis mit dem Vormonat überein“ erst nach einem Monatsabschluss überprüfen. Bei Tools mit Jahresverarbeitung verlängert sich diese Wartezeit noch weiter. Rechnen Sie bei der Planung nicht vom Aufwand her, sondern vom Zeitpunkt, zu dem sich die Ergebnisse tatsächlich überprüfen lassen.

In diesem Fall ist es richtig, die Aufgabe aufzuteilen. Prüfungen, Formatierungen und Aggregationen, die innerhalb von Excel abgeschlossen sind, wandern zu nativem VBA oder dem eingebauten RegExp ab Office 2508+. Dateiumwandlung und Ein-/Ausgabe über Freigabeordner wandern zu PowerShell. Wenn der Auslöser „eine Datei ist eingetroffen“ oder „täglich zu einer festen Zeit“ ist, wandert das zu Power Automate. So lässt sich die Verantwortung entwirren, die zuvor in ein einzelnes .vbs gepresst war.

Ein Beispiel für die Struktur nach der Migration:

• Excel-Makro: Eingabeprüfung, Bildschirmsteuerung, benutzerorientierte Meldungen
• PowerShell: CSV-Normalisierung, Ein-/Ausgabe über den Freigabeordner, Protokollausgabe
• Signaturverwaltung: Authenticode-Signatur für die PowerShell-Skripte
• Sicherheit: AppLocker/App Control vorab im Überwachungsmodus prüfen, Notwendigkeit von ASR-Ausnahmen entscheiden
• Künftige Erweiterung: Standardverarbeitung innerhalb von Excel schrittweise zu Office Scripts migrieren

Der Vorteil dieses Vorgehens liegt darin, die Abhängigkeit von der VBScript-Laufzeit früh loszulösen, ohne alles auf einmal neu bauen zu müssen. RegExp wird über das Office-Update abgefangen, Betriebsskripte wandern zu PowerShell, der Geschäftsablauf zu Power Automate — teilt man so nach Verantwortungsbereich auf, verkleinert sich auch der Ausfallradius.

Referenzlinks

• Das vollständige Beispielcode-Paket dieses Artikels (PowerShell-Audit-Skripte und Pester-Tests) https://github.com/gomurin0428/komurasoft-blog-samples/tree/main/vbscript-deprecation-vba-excel-macro-internal-tools-audit-guide

Die offiziellen Unterlagen liest man am besten in dieser Reihenfolge:

• VBScript deprecation: Timelines and next steps Ausgangspunkt, um die Gesamt-Roadmap und die Bedeutung der einzelnen Phasen zu klären.
• VBScript deprecation: Detection strategies for Windows Praktische Erkennungsanleitung, die Sysmon, GPO, Aufgabenplanung, Intune und MSI-Custom-Actions einschließt.
• Prepare your VBA projects for VBScript deprecation in Windows Aus VBA-Sicht am wichtigsten. Erläutert die eingebaute RegExp-Klasse, den Umgang mit Office 2508 und neuer sowie eine Kompatibilitätstabelle.
• Office Scripts und VBA-Makros im Vergleich Hilft bei der Entscheidung, ob Excel-zentrierte Verarbeitung zu Office Scripts wandern sollte.
• about_Execution_Policies / about_Signing / Set-AuthenticodeSignature / Get-AuthenticodeSignature Das Basispaket für Signaturverwaltung und Ausführungsrichtlinie bei einer PowerShell-Migration.
• Using Event Viewer with AppLocker / Use audit events to create App Control policy rules / App Control for Business zur Durchsetzung von Skripten Notwendig, um Design des Überwachungsmodus, Ereigniserfassung und das Durchsetzungsverhalten für Skripte zu verstehen.
• Referenz zu den Regeln zur Reduzierung der Angriffsfläche Zur Prüfung der Blockierregeln rund um Office-Unterprozesse, Win32-APIs und den heruntergeladenen Ausführungsschutz für JS/VBS.
• Makros aus dem Internet werden in Office standardmäßig blockiert Pflichtlektüre, um MOTW-Probleme bei Testverteilung und Produktivrollout zu verstehen.

Als unterstützende Tools kommen in der Praxis vor allem diese zum Einsatz:

• Sysmon Die Grundlage für die Überwachung des Ladens von vbscript.dll und die Erfassung prozessbezogener Ereignisse.
• Sysmon-Konfigurationsvorlagen auf GitHub sysmon-config von SwiftOnSecurity ist eine hochwertige Startvorlage, sysmon-modular von Olaf Hartong ist modular aufgebaut und bietet einen betriebsfreundlichen Ausgangspunkt.
• oletools / olevba Eignet sich, um VBA-Quellcode aus Office-Dateien zu extrahieren und bei der Erkennung verdächtiger Schlüsselwörter und automatisch startender Makros zu unterstützen.

Als Fazit: Die Vorbereitung auf die Abschaffung von VBScript reicht nicht aus, wenn man nur „VBScript sucht und durch PowerShell ersetzt“. Office-Updates, Codeanalyse, Betriebskonfiguration, Signierung, ASR/AppLocker/App Control und Abnahmetests in einem einzigen Register zu verwalten ist der schnellste, zuverlässigste Weg. Bereiche, die sich wie RegExp durch ein Office-Update retten lassen, sollten frühzeitig gerettet werden; Bereiche, die wie .vbs-Ausführung oder Abhängigkeiten von GPO/Aufgaben/MSI leicht an der Windows-seitigen Stufenumstellung scheitern, sollten vorrangig abgekoppelt werden.

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wann wird VBScript abgeschafft?

Stand April 2026 hat Microsoft eine stufenweise Abschaffung von VBScript öffentlich angekündigt. In Windows 11 Version 24H2 ist es zunächst als Feature on Demand (FOD) standardmäßig aktiviert, in der nächsten Stufe standardmäßig deaktiviert, und in der letzten Stufe soll es aus einer künftigen Windows-Version entfernt werden. Das eigentlich Wichtige jetzt ist also nicht das vollständige Umschreiben, sondern zunächst sichtbar zu machen, wo VBScript-Abhängigkeiten bestehen. Solange VBScript noch als FOD existiert, lässt es sich als optionale Funktion wieder aktivieren; nach der Entfernung entfällt dieser Ausweg.

Bedeutet die Abschaffung von VBScript, dass auch VBA und Excel-Makros nicht mehr funktionieren?

Nein, hier geht es nicht darum, dass VBA abgeschafft wird. Microsoft hat ausschließlich die stufenweise Abschaffung von VBScript angekündigt; die Auswirkung auf VBA-Projekte konzentriert sich hauptsächlich auf die Ausführung externer .vbs-Dateien und auf Verweise auf VBScript-Bibliotheken wie VBScript.RegExp. Verarbeitungen, die aus VBA/Excel heraus direkt .vbs ausführen, laufen ab der Umstellung ein hohes Risiko zu stoppen und sollten vorrangig identifiziert werden. GPO-Anmeldeskripte, Aufgabenplanung, per Intune verteilte Skripte und VBScript-Custom-Actions in MSI-Paketen sind ebenfalls Schwerpunktbereiche, in denen leicht ein Ausfall in der Breite entsteht.

Was sollte man als Ersatz für VBScript verwenden?

Die Wahl der Ersatztechnologie richtet sich nicht danach, „womit man schreiben kann“, sondern danach, welchen Verantwortungsbereich sie übernehmen soll. Für Verarbeitungen, die das Betriebssystem, Dateien, Freigabeordner, AD, Aufgaben oder Installationsprogramme berühren, ist das von Microsoft empfohlene PowerShell die erste Wahl, mit offiziellen Verfahren für Signierung und Ausführungsrichtlinien. Für Zellbearbeitung und Berichte, die vollständig innerhalb einer Excel-Arbeitsmappe ablaufen, eignet sich natives VBA; wer Cloud-Ausführung oder eine Anbindung an Power Automate priorisiert, greift zu Office Scripts; für tiefe Desktop-Integration oder langlebige interne Add-ins kommen .NET/VSTO infrage; für zeitgesteuerte Ausführung oder Freigabeprozesse ist Power Automate ein Kandidat. Nach der Umstellung muss geprüft werden, ob ASR oder AppLocker sie nicht blockieren — die Tests müssen also auch die Richtlinien einschließen.

Was ist zu tun, wenn in VBA VBScript.RegExp verwendet wird?

Ab Office Version 2508 (Build 19127.20154) ist die Klasse RegExp standardmäßig in der VBE enthalten, sodass sich zumindest für RegExp-Anwendungsfälle ein Teil der VBScript-Abhängigkeit durch ein Office-Update auflösen lässt. In gemischten Umgebungen, in denen noch ältere Office-Clients im Einsatz sind, kann jedoch dasselbe VBA auf manchen Geräten laufen und auf anderen nicht. Bleibt auch nur ein einziges Gerät mit einer Version unter 2508 übrig, stößt die neue Syntax an eine Kompilierkompatibilitätsgrenze. Deshalb sollten Office-Version und Update-Kanal in einem Register erfasst werden, um den verbleibenden Bestand zu kennen, und die Migrationsstrategie sollte vorab zwischen „neuer Syntax“, „alter Syntax“ und „verzweigendem Wrapper“ entschieden werden.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.