Die Unterschiede zwischen Windows PowerShell 5.1 und PowerShell 7 ── Ein praktischer Leitfaden zur Migration interner Skripte

„Wenn ich PowerShell 7 auf dem Server installiere, brechen dann unsere aktuellen Skripte?“ „Ist es ein Problem, bei 5.1 zu bleiben?“ ── Diese Fragen bekommen wir zunehmend von Kunden gestellt, die interne Betriebsskripte pflegen. Das PowerShell, das standardmäßig mit Windows kommt (5.1), und das PowerShell 7, das Sie separat installieren. Weil die Namen gleich lauten, wird oft angenommen, „ein Upgrade ersetzt es“ ── in Wirklichkeit sind es separate Produkte, die nebeneinander existieren.

Führen Sie 7 ein, ohne dieses Verhältnis richtig zu verstehen, stoßen Sie auf eines von zwei Dingen: „wir haben es installiert und nichts hat sich geändert (die Aufgaben laufen weiterhin unter 5.1)“ oder umgekehrt „wir haben migriert, und unsere japanischsprachige Dateiverarbeitung erzeugt plötzlich Zeichensalat“. Letzteres ist ein Vorfall, der besonders in japanischsprachigen Umgebungen auftritt, und seine Ursache liegt im Unterschied der Standardzeichenkodierung.

Dieser Artikel richtet sich an IT- und Betriebsverantwortliche, die interne Skripte betreuen. Er ordnet das Verhältnis und die Unterschiede zwischen 5.1 und 7 von Grund auf und stellt das Vorgehen für eine tatsächliche Migration mit Entscheidungstabelle dar.

1. Zunächst das Ergebnis

• Windows PowerShell 5.1 und PowerShell 7 sind separate Produkte, die nebeneinander koexistieren. 5.1 ist in Windows enthalten und auf dem .NET Framework aufgebaut; 7 wird separat installiert und ist auf .NET aufgebaut. Die Installation von 7 entfernt 5.1 nicht.¹²
• Microsoft fügt 5.1 keine neuen Funktionen mehr hinzu. Der Support für 5.1 ist an den Lebenszyklus von Windows selbst gebunden, und die Hauptlinie der Entwicklung ist 7. Neue Skripte sollten gegen 7 geschrieben werden.¹³
• Die ausführbaren Dateien unterscheiden sich. 5.1 ist powershell.exe, 7 ist pwsh.exe. Solange Sie die Startbefehle in der Aufgabenplanung und andernorts nicht umschreiben, laufen bestehende Mechanismen weiterhin unter 5.1.⁴⁵
• Die Standardzeichenkodierungen unterscheiden sich. Bei 5.1 variieren sie je Cmdlet (Out-File ist UTF-16LE, Get-Content ist ANSI usw.); bei 7 ist es einheitlich UTF-8 ohne BOM. Das ist die erste Falle, in die man bei einer Migration in einer japanischsprachigen Umgebung tritt.⁶
• Für Module, die unter 7 nicht laufen, gibt es eine Windows-Kompatibilitätsfunktion. Import-Module -UseWindowsPowerShell lädt sie in einen Hintergrundprozess unter 5.1 und macht sie über Remoting nutzbar ── zurückgeliefert werden jedoch serialisierte Objekte, deren Methoden sich nicht aufrufen lassen.⁷
• Legen Sie mit #Requires -Version und $PSVersionTable im Code fest, unter welcher Version ein Skript laufen soll. Das verhindert vor der Ausführung den Zwischenfall, unter einer nicht vorgesehenen Version zu laufen und still zu brechen.⁸⁹
• Migrieren Sie stufenweise: Bestandsaufnahme → Testlauf unter 7 → Startbefehle aktualisieren. Installieren Sie 7 über MSI oder winget, und legen Sie im Voraus fest, wie Updates verteilt werden (etwa über Microsoft Update).⁵²⁴

2. Wie verhalten sich 5.1 und 7 zueinander ── Koexistenz statt Ablösung

Zunächst das Gesamtbild in einer Tabelle.

7 ersetzt 5.1 nicht, sondern wird in ein anderes Verzeichnis installiert und läuft nebeneinander. Modulspeicherorte (PSModulePath), Profile und Ereignisprotokolle werden allesamt getrennt verwaltet, und da der PSModulePath von 7 auch die Modulpfade von 5.1 einschließt, lassen sich die meisten bestehenden Module aus 7 heraus laden.⁵²

Mit diesen beiden Zeilen können Sie jederzeit prüfen, „wo Sie sich befinden“. $PSVersionTable ist eine automatische Variable, die die Versionsinformationen von PowerShell enthält.⁹

# Prüfen, in welchem PowerShell Sie sich gerade befinden
$PSVersionTable.PSVersion   # 5.1.x bedeutet Windows PowerShell, 7.x bedeutet PowerShell 7
$PSVersionTable.PSEdition   # Desktop = Windows PowerShell / Core = PowerShell 7

Die offizielle Positionierung ist ebenso eindeutig. Windows PowerShell ist die mit Windows gebündelte Edition; Microsoft aktualisiert sie nicht mit neuen Funktionen, und ihr Support ist an die genutzte Windows-Version gebunden. PowerShell (die 7er-Linie) hingegen ist auf dem neuen .NET aufgebaut, und jedes Release erhält einen Supportzeitraum entsprechend der Supportrichtlinie des zugrunde liegenden .NET.¹³ 5.1 wird nicht morgen verschwinden, aber die praktische Schlussfolgerung lautet, dass die Grundlage für „das, was Sie ab jetzt schreiben“ und „das, was Sie lange nutzen werden“, 7 sein sollte.

3. Die erste Falle ── Unterschiede bei der Standardkodierung und Zeichensalat

Der häufigste Migrationsstolperstein in japanischsprachigen Umgebungen ist Zeichensalat. Die Ursache ist eindeutig: Die Standardzeichenkodierungen unterscheiden sich zwischen den beiden.⁶

# Dieselbe eine Zeile erzeugt unter 5.1 und 7 Dateien mit unterschiedlicher Byte-Folge
'こんにちは' | Out-File -FilePath C:\temp\hello.txt
# Unter 5.1 ausgeführt → eine UTF-16LE-Datei (mit BOM)
# Unter 7 ausgeführt   → eine UTF-8-Datei ohne BOM

Das bedeutet in der Praxis zweierlei.

Erstens: Dateibasierte Integrationen, die von Shift_JIS ausgehen, können in dem Moment, in dem Sie auf 7 umsteigen, sowohl beim Lesen als auch beim Schreiben Zeichensalat erzeugen. Get-Content von 5.1 liest eine Datei ohne BOM als ANSI (in japanischsprachigen Umgebungen Shift_JIS), während 7 sie als UTF-8 liest. Die Abhilfe besteht darin, -Encoding bei jeder Datei-Ein-/Ausgabe ausdrücklich anzugeben. Unter 7 lassen sich Codepage-Nummern (-Encoding 932) oder registrierte Namen angeben, und ab 7.4 steht zudem der Wert ansi zur Verfügung.⁶ Konkrete Techniken für die CSV-Verarbeitung sind in dem gleichzeitig veröffentlichten Artikel „Excel- und CSV-Geschäftsprozesse mit PowerShell automatisieren“ zusammengetragen.

Zweitens: das Speicherformat der Skriptdatei selbst. Liest 5.1 ein Skript mit Sonderzeichen in Kommentaren, das als UTF-8 ohne BOM gespeichert wurde, interpretiert es dies fälschlich als ANSI, was zu Zeichensalat oder Syntaxfehlern führt. Folgen Sie der Empfehlung der offiziellen Dokumentation und speichern Sie Skripte mit Nicht-ASCII-Zeichen als UTF-8 mit BOM, dann werden sie unter 5.1 und 7 gleichermaßen korrekt interpretiert.⁶

4. Kompatibilität ── Was nicht mehr funktioniert und wie leistungsfähig die Windows-Kompatibilitätsfunktion wirklich ist

4.1. Was nicht mehr funktioniert

7 kann viele bestehende Module unverändert laden,⁵ aber manche lassen sich nicht laden. Hier die offiziell genannten typischen Fälle.

• Nicht mehr mitgelieferte Module: PSWorkflow/PSWorkflowUtility (Workflows), PSScheduledJob, die ISE-Module, Microsoft.PowerShell.LocalAccounts und andere sind nicht in 7 enthalten.⁴
• Snap-Ins: Snap-Ins, das alte Erweiterungsformat vor den Modulen, werden in 7 nicht unterstützt.⁴
• Code, der eng an das .NET Framework gebunden ist: Da das zugrunde liegende .NET bei 7 ein anderes ist, können sich Skripte, die .NET-Methoden direkt aufrufen, anders verhalten.⁵⁴
• Kleine Verhaltensänderungen: Export-Csv gibt standardmäßig keine #TYPE-Zeile mehr aus, und Group-Object liefert Gruppen nun sortiert zurück ── Änderungen, die Skripte betreffen, die von der Ausgabe abhängen.⁴

Es gibt auch Inkompatibilität in der anderen Richtung. Skripte, die in 7 hinzugekommene Syntax und Funktionen nutzen ── den ternären Operator, ForEach-Object -Parallel und so weiter ── laufen nicht unter 5.1.⁵ Sie müssen also skriptweise entscheiden, ob Sie es „so schreiben, dass es unter beiden läuft“ oder „festlegen, unter welchem es läuft“.

Der Unterstützungsstatus der Microsoft-eigenen Module lässt sich auf der offiziellen Seite zur Modulkompatibilität nachschlagen.¹⁰

4.2. Wie die Windows-Kompatibilitätsfunktion (-UseWindowsPowerShell) funktioniert und wo ihre Grenzen liegen

7 verfügt über eine Windows-Kompatibilitätsfunktion für Module, die nur unter 5.1 laufen.

# Ein Modul, das 7 nicht unterstützt, über die Kompatibilitätsfunktion laden (Beispiel aus der offiziellen Dokumentation)
Import-Module -Name ScheduledTasks -UseWindowsPowerShell

Der Mechanismus ist eine Anwendung von Remoting. Im Hintergrund startet ein Prozess von Windows PowerShell 5.1, das Modul wird in eine Sitzung namens WinPSCompatSession geladen, und auf der 7-Seite wird ein durch implizites Remoting erzeugtes Proxymodul importiert. 5.1-exklusive Module unter System32 werden auch bei Angabe des Namens oder automatischer Befehlserkennung implizit über diesen Mechanismus geladen.⁷

Das ist praktisch, aber wer es ohne Verständnis der Einschränkungen nutzt, erlebt stilles Versagen. Die offiziell festgehaltenen Einschränkungen lauten:⁷

• Ausgetauscht werden serialisierte Werte, keine lebenden Objekte. Sie können keine Methoden der zurückgelieferten Objekte aufrufen; es kommt nur ein Schnappschuss der Eigenschaften bei Ihnen an.
• Es funktioniert nur auf dem lokalen Windows-System und erfordert Windows PowerShell 5.1.
• Alle über die Kompatibilitätsfunktion geladenen Module teilen sich einen einzigen Runspace (einen einzigen 5.1-Prozess).
• Manche Module (darunter PSScheduledJob) werden standardmäßig zurückgewiesen.

Verarbeitungsschritte wie „eine Methode auf dem abgerufenen Ergebnis aufrufen“ oder „mitten in der Pipeline werden lebende Objekte benötigt“ funktionieren über die Kompatibilitätsfunktion schlicht nicht. In diesem Fall lässt sich zwar auch die gesamte Pipeline auf der 5.1-Seite ausführen, sodass nur das Endergebnis zurückkommt,⁷ doch aus praktischer Erfahrung ist es einfacher zu pflegen, wenn es kompliziert würde, nur diesen Teil auf 5.1 zu belassen.

5. Defensiv schreiben ── #Requires und Versionsverzweigung

Während einer Migrationsphase entsteht zwangsläufig ein Zustand, in dem „wir nicht wissen, unter welcher Version es laufen wird“. Unter einer nicht vorgesehenen Version zu laufen und mittendrin zu brechen ist das schlechteste Ergebnis, also bauen Sie Absicherungen direkt ins Skript ein.

Schreiben Sie eine #Requires-Anweisung, und PowerShell verweigert das Skript vor der Ausführung auf jeder Version, die die Bedingung nicht erfüllt.⁸

#Requires -Version 7.0
# Dieses Skript ist nur für 7 (es nutzt ForEach-Object -Parallel und Ähnliches).
# Wird es mit powershell.exe (5.1) gestartet, läuft ab hier gar nichts mehr

Umgekehrt schreiben Sie #Requires -PSEdition Desktop in Skripte, die nur unter 5.1 laufen sollen. Desktop ist der Editionsname für die 5.1-Linie, Core für die 7er-Linie.⁸⁹

Möchten Sie in einem Skript, das unter beiden läuft, nur einen Teil des Verhaltens ändern, verzweigen Sie zur Laufzeit anhand von $PSVersionTable.⁹

# In einem Skript, das 5.1 und 7 gleichermaßen unterstützt, nur die versionsabhängige Verarbeitung verzweigen
if ($PSVersionTable.PSVersion.Major -ge 6) {
    $enc = 932            # 7: Shift_JIS lässt sich per Codepage-Nummer angeben
} else {
    $enc = 'Default'      # 5.1: Default = die ANSI-Codepage des Systems
}
Get-Content -LiteralPath $path -Encoding $enc

Wichtig ist, diese Festlegung nicht erst „nach Abschluss der Migration“ einzubauen, sondern bereits „zum Zeitpunkt der Bestandsaufnahme“. Schon eine einzige #Requires-Zeile macht für jeden sofort erkennbar, zu welcher Welt dieses Skript gehört.

6. So gehen Sie bei der Migration vor ── Von der Bestandsaufnahme bis zur Aktualisierung der Aufgabenplanung

Eine tatsächliche Migration läuft in folgender Reihenfolge ab. Eine Umstellung in einem großen Schritt lädt Zwischenfälle geradezu ein, deshalb ist stufenweise Migration die Regel.

Schritt 1: Bestandsaufnahme. Durchsuchen Sie Skriptordner und die Aufgabenplanung nach laufenden .ps1-Dateien und Startbefehlen.

# Die Aufgabenplanung nach Aufgaben durchsuchen, die PowerShell starten
Get-ScheduledTask | ForEach-Object {
    foreach ($action in $_.Actions) {
        # Sowohl ausführbare Datei als auch Argumente prüfen, um auch indirekte Starts wie cmd.exe /c powershell ... zu erfassen
        if ("$($action.Execute) $($action.Arguments)" -match 'powershell|pwsh') {
            [pscustomobject]@{
                TaskPath  = $_.TaskPath        # Aufgabennamen sind nur innerhalb eines Ordners eindeutig, daher auch den Pfad festhalten
                TaskName  = $_.TaskName
                Execute   = $action.Execute    # powershell.exe oder pwsh.exe
                Arguments = $action.Arguments
            }
        }
    }
} | Export-Csv -Path .\ps-tasks.csv -NoTypeInformation -Encoding UTF8

Schritt 2: 7 installieren. Installieren Sie über das MSI-Paket (geeignet für die Verteilung über Softwareverteilungswerkzeuge) oder mit winget.⁵²

# Installation mit winget. Updates laufen dann ebenfalls über winget upgrade auf demselben Weg
winget install --id Microsoft.PowerShell --source winget

Legen Sie auch den Update-Betrieb im Voraus fest. Das MSI ab 7.2 bietet eine Option, Updates über Microsoft Update zu beziehen (standardmäßig aktiviert), wodurch es sich in den regulären Update-Fluss über WSUS oder ein Konfigurationsverwaltungswerkzeug einreihen lässt.⁴ Am problematischsten ist es, wilde Installationen unbeachtet zu lassen, sodass veraltete 7er-Versionen bestehen bleiben.

Schritt 3: Testlauf unter 7. Führen Sie jedes bestandsaufgenommene Skript mit pwsh aus und prüfen Sie, ob es funktioniert und ob die Ausgabedateien Zeichensalat enthalten. Da 7 mit 5.1 koexistiert, können Sie testen, ohne die Produktionsaufgaben zu stoppen ── das ist der Vorteil des Nebeneinander-Designs.² Kommt es zu Fehlern, grenzen Sie die Kompatibilitätsprobleme aus Kapitel 4 ein (Module, .NET-APIs, Verhaltensänderungen).

Schritt 4: Festlegen, unter welcher Version es laufen soll. Ergänzen Sie bei den getesteten Skripten #Requires -Version 7.0, bei denen, die bei 5.1 bleiben, #Requires -PSEdition Desktop (Kapitel 5).

Schritt 5: Startbefehle aktualisieren. Schreiben Sie die Aktionen der Aufgabenplanung um. Vergessen Sie das, entsteht „wir dachten, wir hätten auf 7 migriert, aber es läuft weiterhin unter 5.1“.

# Vorher (läuft unter 5.1):
#   powershell.exe -NoProfile -ExecutionPolicy RemoteSigned -File C:\scripts\daily-report.ps1
# Nachher (läuft unter 7):
#   "C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -File C:\scripts\daily-report.ps1

Beachten Sie, dass sich bei pwsh.exe der erste positionelle Parameter von -Command auf -File geändert hat. Wird ein Aufruf, der powershell.exe -Command "..." entspricht, mechanisch ersetzt, ändert sich dessen Interpretation. Geben Sie daher stets ausdrücklich -File bzw. -Command an.⁴

Zur Handhabung von Ausführungsrichtlinie und Skriptsignatur siehe den gleichzeitig veröffentlichten Artikel „PowerShell-Ausführungsrichtlinie und Skriptsignatur“; zur Entscheidung über die Migration von Batchdateien (.bat) siehe „Sollten Sie Batchdateien auf PowerShell migrieren?“.

7. Bewährte Praxis (Entscheidungstabelle)

8. Zusammenfassung

• 5.1 und 7 sind separate Produkte, die nebeneinander koexistieren. Die Installation von 7 beschädigt bestehende Mechanismen nicht ── umgekehrt migriert aber auch nichts, solange Sie die Startbefehle nicht ändern.
• 5.1 befindet sich im Erhaltungsmodus: keine neuen Funktionen, Support an Windows selbst gebunden. 7 ist die Hauptlinie der Entwicklung. Schreiben Sie Neues gegen 7.
• Die größte Falle in japanischsprachigen Umgebungen ist der Unterschied bei der Standardkodierung (5.1 variiert, 7 ist UTF-8 ohne BOM). Verhindern Sie dies durch ausdrückliches -Encoding bei der Ein-/Ausgabe und durch Speichern der Skripte als UTF-8 mit BOM.
• Module, die unter 7 nicht laufen, lassen sich mit der Windows-Kompatibilitätsfunktion retten, allerdings mit der Einschränkung, dass nur serialisierte Werte zurückkommen. Reicht das nicht aus, belassen Sie nur die betroffene Verarbeitung auf 5.1.
• Legen Sie mit #Requires und $PSVersionTable im Code fest, unter welcher Version ein Skript läuft, und stoppen Sie die Ausführung auf einer nicht vorgesehenen Version.
• Migrieren Sie stufenweise: Bestandsaufnahme → 7 installieren (MSI/winget) → Testlauf → #Requires ergänzen → Startbefehle der Aufgabenplanung aktualisieren.

Verwandte Artikel

• PowerShell-Befehlsgrundlagen ── Die zuerst zu lernenden Operationen und ihre sichere Anwendung
• PowerShell-Skripte in der Praxis ── Protokollauswertung, Archivierung und Reporting sicher automatisieren
• Excel- und CSV-Geschäftsprozesse mit PowerShell automatisieren ── Praktische Rezepte für Auswertung, Abgleich und Berichtsausgabe
• Auf die Abschaffung von VBScript vorbereitet sein: Ein Prüfleitfaden für VBA und interne Werkzeuge
• Checkliste vor der Migration vom .NET Framework zu .NET
• Sollten Sie Batchdateien auf PowerShell migrieren?

Verwandte Beratungsbereiche

Die KomuraSoft LLC übernimmt die Bestandsaufnahme interner Skriptbestände sowie Planung und Durchführung der stufenweisen Migration auf PowerShell 7, die Abgrenzung von Verarbeitungsschritten, die von 5.1-exklusiven Modulen abhängen, und die Untersuchung von Störungen wie „nach der Migration trat Zeichensalat auf“ oder „es funktioniert nicht mehr“.

• Migration und Nutzung vorhandener Ressourcen
• Modernisierung & Wartung von Windows-Umgebungen
• Technische Beratung & Designüberprüfung
• Kontakt

Referenzlinks

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.

Was unterscheidet Windows PowerShell 5.1 von PowerShell 7?

Es handelt sich um separate Produkte. 5.1 ist in Windows enthalten und läuft auf dem .NET Framework; Microsoft fügt keine neuen Funktionen mehr hinzu, und der Support folgt dem Lebenszyklus von Windows selbst. 7 ist ein separat installiertes Produkt, das auf .NET (früher .NET Core) läuft, und bildet die Hauptlinie der Entwicklung. 7 ersetzt 5.1 nicht: Es wird in ein anderes Verzeichnis installiert und existiert nebeneinander, und die ausführbaren Dateien unterscheiden sich als powershell.exe und pwsh.exe.

Beschädigt die Installation von PowerShell 7 meine bestehenden 5.1-Skripte?

Nein. 7 wird in einem anderen Verzeichnis installiert (standardmäßig Program Files\PowerShell\7), und Modulspeicherorte sowie Profile werden getrennt von 5.1 verwaltet. Bestehende Mechanismen, die powershell.exe starten, etwa Einträge in der Aufgabenplanung, laufen wie bisher unter 5.1 weiter. Gerade deshalb sollten Sie die Kehrseite beachten: Die Installation von 7 migriert von sich aus gar nichts, und jedes Skript, das unter 7 laufen soll, benötigt einen ausdrücklich auf pwsh.exe umgestellten Startbefehl.

Warum entsteht bei meinem bestehenden Skript unter PowerShell 7 Zeichensalat?

Weil sich die Standardzeichenkodierung geändert hat. Bei 5.1 unterscheiden sich die Standards je Cmdlet (Out-File ist UTF-16LE, Get-Content ist ANSI usw.), während 7 einheitlich UTF-8 ohne BOM verwendet. In japanischsprachigen Umgebungen setzt viel dateibasierte Integration Shift_JIS voraus, sodass die Migration mit den Standardwerten sowohl beim Lesen als auch beim Schreiben Zeichensalat verursachen kann. Zwei Maßnahmen verhindern fast alles: -Encoding bei jeder Datei-Ein-/Ausgabe ausdrücklich angeben und Skripte, die selbst Nicht-ASCII-Zeichen enthalten, als UTF-8 mit BOM speichern.

Was soll ich mit Modulen tun, die unter PowerShell 7 nicht funktionieren?

Prüfen Sie zunächst, ob sie funktionieren, wenn Sie sie unter 7 einfach mit Import-Module laden. Falls nicht, lädt die Windows-Kompatibilitätsfunktion (Import-Module -UseWindowsPowerShell) das Modul in einen Hintergrundprozess unter 5.1 und macht es über Remoting von 7 aus nutzbar. Dabei gibt es Einschränkungen: Zurückgeliefert werden serialisierte Objekte, deren Methoden sich nicht aufrufen lassen, und es funktioniert nur auf dem lokalen Windows-System. Für Verarbeitungsschritte, die an diese Einschränkungen stoßen, ist die realistische Antwort, nicht zu erzwingen ── lassen Sie nur diesen Teil auf 5.1.

Wie sollte ich interne Skripte von 5.1 auf 7 migrieren?

Gehen Sie stufenweise vor statt in einem großen Schritt umzustellen. Beginnen Sie mit einer Bestandsaufnahme der .ps1-Dateien in der Aufgabenplanung und in Ihren Skriptordnern, und testen Sie jedes davon unter 7 (pwsh), um zu prüfen, ob es funktioniert. Ergänzen Sie bei den erfolgreichen Skripten #Requires -Version 7 und aktualisieren Sie den Startbefehl der Aufgabenplanung von powershell.exe auf pwsh.exe. Erzwingen Sie nichts, was nur unter 5.1 läuft ── lassen Sie es unverändert, nachdem Sie ausdrücklich festgehalten haben, unter welcher Version es laufen soll. Installieren Sie 7 selbst über MSI oder winget, und legen Sie gleichzeitig fest, wie Updates verteilt 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.