Electron auf Windows Terminal Server: Die „Schatten-Installations“-Falle vermeiden

Das Erstellen von Electron-Anwendungen ist oft eine nahtlose Erfahrung – bis man auf Unternehmensumgebungen trifft. Während Electron Einzelnutzer-Desktop-Deployments hervorragend handhabt, wird es kompliziert, wenn Ihre Kunden Windows Terminal Server (oder Remote Desktop Services) nutzen.

In unserem Unternehmen stießen wir kürzlich auf ein kritisches Problem, bei dem sich unsere Anwendung in diesen Mehrbenutzerumgebungen unvorhersehbar verhielt. Wir sahen uns mit einem „Split-Brain“-Szenario konfrontiert, bei dem Benutzer trotz Eingreifen des Administrators unterschiedliche Versionen der Software ausführten.

Wenn Sie eine Electron-App für Unternehmenskunden entwickeln, hilft Ihnen dieser Leitfaden, Electron auf Windows Terminal Server korrekt zu konfigurieren, um die „Schatten-Installations“-Falle zu vermeiden.

Die Umgebung: Einzelnutzer vs. Terminal Server

Um das Problem zu verstehen, müssen wir uns zunächst ansehen, wie unsere Kunden die Software nutzen:

1. Standard-Laptops: Der Benutzer hat die volle Kontrolle (oft Admin-Rechte). Er installiert die Software, erhält Update-Benachrichtigungen und klickt auf „Update“. Die Software patcht sich selbst und alle sind zufrieden.
2. Windows Terminal Server: Dies ist üblich in Anwaltskanzleien, Krankenhäusern und sicherheitsbewussten Unternehmen.

• Benutzer loggen sich remote auf einem zentralen Server ein.
• Admins installieren Software systemweit (meist in C:\Program Files).
• Benutzer (Nicht-Admins) führen die Software lediglich aus. Sie sollten nicht in der Lage sein, die Kern-Anwendungsdateien zu verändern.

Im Terminal-Server-Szenario muss die „Single Source of Truth“ die systemweite Installation sein, die von der IT-Abteilung verwaltet wird.

Das Problem: Der Electron-Updater ist „zu schlau“

Das Problem tritt auf, wenn Sie ein Update ausliefern. Standardmäßig sind viele Electron-Update-Konfigurationen (speziell electron-updater) darauf ausgelegt, widerstandsfähig zu sein. Sie wollen, dass der Nutzer die neueste Version hat, egal was passiert.

Hier ist die Fehlerkette, die wir beobachtet haben:

1. Wir lieferten ein Update aus.
2. Der Benutzer (auf einem Terminal Server, ohne Admin-Rechte) sah das Banner „Update verfügbar“.
3. Der Benutzer klickte auf Installieren.
4. Der Updater versuchte, nach C:\Program Files zu schreiben. Zugriff verweigert.
5. Der Fallback: Anstatt fehlzuschlagen, dachte der Updater: „Okay, ich kann nicht in den Systemordner schreiben, also installiere ich diese neue Version speziell für diesen Benutzer in dessen AppData-Ordner.“

Das Ergebnis: Split-Brain-Installationen

Sobald dieser Fallback eintritt, haben Sie eine Schatten-Installation.

• System-Pfad: C:\Program Files\IhreApp (Version 1.0, kontrolliert vom Admin)
• Benutzer-Pfad: C:\Users\MaxMustermann\AppData\Local\IhreApp (Version 1.1, kontrolliert vom Benutzer)

Windows priorisiert oft die benutzerlokale Version. Wenn der Admin nun die systemweite Version auf 1.2 aktualisiert, sieht der Benutzer dies niemals. Er steckt fest und startet für immer seine lokale „Schatten“-Kopie der Version 1.1. Der Admin verliert die Kontrolle und der Benutzer sitzt auf einer nicht gewarteten Insel fest.

Die Lösung: Systemweite Installationen erzwingen

Um Electron auf Windows Terminal Server zu reparieren, müssen Sie dieses Fallback-Verhalten deaktivieren. Sie müssen dem Installer sagen: „Wenn du nicht systemweit als Admin installieren kannst, installiere gar nicht.“

Wir nutzen electron-builder. Die Lösung liegt im Wechsel vom standardmäßigen „One-Click“-Installer zu einem strikt konfigurierten NSIS-Target.

Schritt 1: package.json aktualisieren

Ändern Sie Ihre Build-Konfiguration, um perMachine-Installationen zu erzwingen und oneClick zu deaktivieren.

"build": {
  "win": {
    "target": "nsis"
  },
  "nsis": {
    "oneClick": false,
    "perMachine": true,
    "allowElevation": true,
  }
}

Warum das funktioniert:

• oneClick: false: Dies deaktiviert die stille Installation, die oft standardmäßig auf AppData zugreift. Es erzwingt einen Setup-Assistenten.
• perMachine: true: Dies setzt den Standard-Installationspfad auf C:\Program Files und erfordert eine Rechteerweiterung durch die Benutzerkontensteuerung (UAC), um zu installieren.
• allowElevation: true: Erlaubt dem Installer, nach Admin-Rechten zu fragen.

Mit dieser Konfiguration wird ein Standardbenutzer, der versucht ein Update durchzuführen, nach einem Admin-Passwort gefragt. Da er keines hat, bricht das Update ab. Dies ist das korrekte Verhalten für einen Terminal Server. Der Benutzer bleibt auf der alten Version, bis der IT-Admin das Update für alle durchführt.

Das Aufräumen: Umgang mit „Zombies“

Die Implementierung des obigen Fixes verhindert zukünftige Schattenkopien. Sie entfernt jedoch nicht die bestehenden.

Wenn Sie bereits Benutzer mit Schattenkopien in deren AppData haben, hilft die bloße Installation der neuen systemweiten Version nicht. Deren Verknüpfungen zeigen wahrscheinlich immer noch auf die lokale AppData-Version.

Die Bereinigungsstrategie

Wir haben versucht, einen Bereinigungsprozess innerhalb der App zu skripten (z. B. „Beim Start auf AppData-Version prüfen und selbst zerstören“), fanden dies jedoch aufgrund von Dateisperren und Berechtigungsproblemen unzuverlässig.

Die zuverlässigste Lösung für betroffene Kunden ist eine manuelle oder skriptbasierte Bereinigung durch deren IT-Abteilung:

1. Verzeichnis löschen: Entfernen Sie den Anwendungsordner aus C:\Users\<benutzername>\AppData\Local\IhreApp.
2. Verknüpfungen reparieren: Dies ist der Schritt, den die meisten vergessen. Die Verknüpfung auf dem Desktop oder im Startmenü zeigt möglicherweise immer noch auf den gelöschten AppData-Pfad. Diese Verknüpfungen müssen gelöscht oder aktualisiert werden, damit sie auf die ausführbare Datei in C:\Program Files zeigen.

Zusammenfassung

Beim Deployment von Electron auf Windows Terminal Server können Sie sich nicht auf Standardverhalten verlassen, das für persönliche Laptops gedacht ist.

1. Risiko erkennen: Nicht-Admin-Benutzer, die die App updaten, erzeugen unmanagebare Schattenkopien.
2. NSIS konfigurieren: Nutzen Sie perMachine: true und oneClick: false im electron-builder, um systemweite Installationen zu erzwingen.
3. Erwartungen managen: Stellen Sie sicher, dass Ihre Anwendung kommuniziert, dass Updates auf diesen Systemen in der Verantwortung des Administrators liegen.

Indem Sie systemweite Installationen strikt erzwingen, geben Sie die Kontrolle an die IT-Admins zurück und gewährleisten eine konsistente, reproduzierbare Umgebung für alle Ihre Benutzer.