Der Fehler ist behoben. Warum kommt die Korrektur erst nächste Woche an?

Freitag, 15:40. Der Bericht, mit dem die Fachabteilung jeden Montag ihre Wochenzahlen abstimmt, rechnet seit dem letzten Release falsch. Die Ursache ist gefunden, die Korrektur geschrieben und geprüft. Sie hat zehn Minuten gedauert. Die neue Frontend-ACCDE liegt bereit.

Beim Anwender ist sie damit nicht. Das nächste Wartungsfenster der IT ist am Dienstag in einer Woche. Bis dahin arbeitet die Abteilung mit einem Bericht, von dem alle wissen, dass er falsch ist, und rechnet die Summe am Montag mit dem Taschenrechner nach.

Wer eine Access-Anwendung mit einem Frontend auf jedem Arbeitsplatz betreut, kennt diesen Freitag. Die Arbeit ist getan, aber ihr Wert ist noch nicht angekommen. Diese Woche geht verloren, und niemand hat sie verschuldet.

Dieser Beitrag hat zwei Teile. Der erste beschreibt, wie wir das Problem im April 2016 gesehen und gelöst haben. Der zweite ist im Oktober 2026 dazugekommen: was aus diesem ersten Starter geworden ist und warum die schwierigste Frage am Ende nicht die Geschwindigkeit war.

Der Beitrag ist lang, weil der Weg lang war. Wer nur einen Teil sucht, springt direkt hin:

• 2016: was es gab und warum wir einen eigenen Starter geschrieben haben
• 2026: was aus den vier offenen Fragen geworden ist
• Wie die Verteilung nicht selbst zum Einfallstor wird
• Derselbe Freitag mit dem Bootstrapper
• Selbst bauen?

Wer bremst hier eigentlich? Niemand. Für die Entwicklung ist die Sache erledigt. Die Fachabteilung will nur einen Bericht, der stimmt. Für die IT ist die Woche kein Hindernis, sondern Sorgfalt: Jede Änderung an zweihundert Arbeitsplätzen ist ein Risiko, und wenn morgens ein Rechner nicht startet, klingelt bei ihr das Telefon.

Alle drei haben recht. Es passen nur zwei Takte nicht zusammen. Eine Fachanwendung ändert sich wöchentlich, manchmal täglich. Der Weg, auf dem Software auf die Arbeitsplätze kommt, ist für Programme gebaut, die sich ein- oder zweimal im Jahr ändern.

Microsoft empfiehlt für Access-Anwendungen mit mehreren Benutzern ein Backend auf dem Server und ein Frontend, von dem jeder Arbeitsplatz eine eigene Kopie bekommt. Jede neue Fassung muss also auf jeden Arbeitsplatz, und das Frontend hängt an Dingen außerhalb der Datei: an registrierten COM-Komponenten, an ODBC-Treibern und an einem vertrauenswürdigen Speicherort, der je Benutzer und Office-Version eingetragen ist. Office 2016 gibt es seit September 2015, auf vielen Arbeitsplätzen läuft noch Office 2010, und was dort eingetragen ist, gilt für Access 2016 nicht.

MSI und SCCM machen vieles richtig. Ein Paket ist nachvollziehbar, steht im Inventar und lässt sich sauber entfernen; Administratorrechte bleiben bei denen, die dafür verantwortlich sind. Der Configuration Manager bekommt seit Version 1511 vom Dezember 2015 monatliche Updates. Aber ein Paket ist für die Installation eines Produkts gebaut. Eine Anwendung, die sich jede Woche ändert, wird damit zu einem Paket pro Woche.

Anmeldeskript und Versionstabelle, die Wege, die Access-Entwickler sich selbst gebaut haben, lösen jeweils einen Teil. Das Skript kopiert nur bei der Anmeldung, und es scheitert an einer geöffneten Datei. Jede Firma hat die Kollegin in der Buchhaltung, die die Anwendung seit Dienstag nicht geschlossen hat, weil sie sonst alle Filter neu setzen müsste. Die Versionstabelle wiederum zwingt die Anwendung, sich selbst zu ersetzen, während sie läuft. Das ist ungefähr so entspannt, wie den Stuhl zu tauschen, auf dem man gerade sitzt.

ClickOnce, seit 2005 Teil des .NET Framework 2.0, hat fast genau die Idee, die wir suchen: signierte Manifeste, Installation je Benutzer ohne Administratorrechte, Prüfung beim Start, und die vorige Fassung bleibt erhalten. Aber ClickOnce verteilt .NET-Anwendungen, und für Änderungen an der Systemkonfiguration verweist Microsoft auf den Windows Installer.

Mitgenommen haben wir drei Dinge: Was auf einem Arbeitsplatz läuft, muss bekannt sein. Die Aktualisierung gehört vor den Start der Anwendung, nicht in sie hinein. Herausgeben und Installieren sind getrennte Schritte.

Daraus ist unser Starter entstanden, ein kleines Programm zwischen der Verknüpfung auf dem Desktop und Access. Wer die Anwendung öffnen will, startet den Starter, nicht die ACCDE. Access startet nicht mehr sich selbst.

Bei jedem Aufruf liest der Starter eine Konfigurationsdatei, die neben ihm liegt. Sie nennt den Freigabeordner, den lokalen Ordner und die Dateien der Anwendung, jede mit Zeitstempel und Aktion: nur kopieren, mit regsvr32 oder mit regasm registrieren. Ist eine Datei auf der Freigabe neuer als im lokalen Protokoll, kopiert und registriert er sie. Danach öffnet er die lokale Kopie. Mit /GUI öffnet er die Oberfläche, in der die Konfiguration gepflegt wird.

An der IT führt das nicht vorbei. Sie legt fest, aus welchem Ordner ausgeliefert wird und wer dort schreiben darf, und verteilt den Starter einmal. Der Herausgeber legt geprüfte Fassungen in diesen Ordner. Der Starter erledigt innerhalb dieses Rahmens, was sich bei jedem Start wiederholt.

Für den Freitag heißt das: Um 15:50 liegt die Korrektur im Freigabeordner, und am Montag arbeitet die Fachabteilung mit ihr. Der Taschenrechner bleibt in der Schublade.

Der Starter verkürzt die Woche auf ein Wochenende. Vier Fragen beantwortet er nicht.

• Komponenten brauchen Administratorrechte. regsvr32 schreibt in den Teil der Registrierung, der allen Benutzern gehört. Jede Fassung mit neuen Komponenten bleibt damit ein Fall für die IT.
• Ein Zeitstempel ist kein Herkunftsnachweis. Der Starter übernimmt, was auf der Freigabe neuer ist. Wir vertrauen der Freigabe, weil sie im internen Netz liegt. Genau diese Annahme stellen John Kindervag mit dem Zero-Trust-Modell bei Forrester (2010) und Google mit BeyondCorp (2014) in Frage.
• Überschreiben ist kein Rückweg. Ist die neue Fassung fehlerhaft, führt der Weg zurück über eine Kopie von Hand.
• Der vertrauenswürdige Speicherort bleibt Handarbeit, per Gruppenrichtlinie oder von Hand, je Office-Version.

Eine Verteilung ist erst fertig, wenn sie auch mit einer misslungenen Fassung umgehen kann. So weit sind wir im April 2016 noch nicht.

Ab hier Stand Oktober 2026.

Der Starter aus dem ersten Teil war bei Kunden bis 2025 im Einsatz, zuletzt gepflegt 2021 in Version 1.1. Bei zwei Großunternehmen laufen Teile davon noch heute. Sein Nachfolger ist nicht durch Flicken entstanden, denn mit den vier Fragen hat sich die Aufgabe selbst verschoben. 2016 ging es darum, dass eine neue Datei rechtzeitig ankommt. Heute geht es darum, dass jedes Release kontrolliert, nachprüfbar und auch im Fehlerfall beherrschbar bleibt.

Daraus sind zwei Programme geworden: der Bootstrapper, der Starter auf jedem Arbeitsplatz, und der Bootstrapper Manager, in dem der Herausgeber beschreibt, was der Starter ausliefert. Die vier Fragen und drei, die unterwegs dazugekommen sind, beantworten sie so:

Der Starter schreibt nur in die Ordner des Benutzers und unter HKEY_CURRENT_USER; erhöhte Rechte fordert er nie an. Auch ODBC-Treiber, Datenquellen und eine eigene .NET-Runtime installiert er je Benutzer und zählt, welche Anwendung sie braucht. Was wirklich Administratorrechte braucht, bleibt bei der IT: systemweite Treiber, die Access Runtime, Registrierungen für den ganzen Rechner. Fehlt davon etwas, meldet der Starter es mit einem Fehlercode, und zu jedem Code gibt es eine Hilfeseite mit Ursache und Lösung.

Der Starter überschreibt nichts mehr. Jede Version bekommt im Profil des Anwenders einen eigenen Ordner, die laufende bleibt unberührt. Die Kollegin in der Buchhaltung darf ihre alte Kopie also weiter offen haben; sie bekommt die neue beim nächsten Start. Welche Datei und welcher Registrierungswert bei wem installiert ist, ist für jeden Anwender erfasst.

Ist ein Release fehlerhaft, gibt es zwei Wege zurück. Wer sofort weiterarbeiten muss, startet die vorige Version aus dem Einstellungsfenster. Und der Herausgeber veröffentlicht die vorige Fassung neu und zieht die fehlerhafte ausdrücklich zurück (/publish /withdraw). Beim nächsten Start sind alle wieder auf der vorigen Fassung.

2016 stand die Beschreibung einer Fassung in einer XML-Datei, gepflegt in der Oberfläche des Starters. Heute ist sie eine Projektdatei, und der Herausgeber bearbeitet sie im Bootstrapper Manager, einer Access-Anwendung, die mit dem Office SDK installiert wird. Auf eigenen Seiten legt er fest, welche Dateien wohin kommen, welche Verknüpfungen, Registrierungswerte, Dateitypen und Bedingungen dazugehören und was am Ende startet.

• Prüfen lässt den Starter selbst die Projektdatei bewerten, nach denselben Regeln, nach denen er später beim Anwender arbeitet, und führt zu dem Feld, in dem ein Problem zu beheben ist.
• Vorschau zeigt das Fenster, das Anwender während der Installation sehen. Probelauf zeigt für jede Datei, wohin sie installiert würde, ohne etwas zu ändern.
• MSI erstellen baut das Paket, mit dem die IT Starter und Projektdatei einmal verteilt, per Gruppenrichtlinie, Intune oder Configuration Manager. Ein neues Paket braucht es erst, wenn sich Starter oder Projektdatei ändern.
• Übernehmen macht aus der Konfiguration des Starters aus dem ersten Teil eine Projektdatei. SQL-Verbindungen und Kennwörter lässt es bewusst weg: Sie gehören nicht in eine Datei, die auf jeden Arbeitsplatz kopiert wird.

Damit wären die vier Fragen beantwortet. Unterwegs ist aber eine fünfte aufgetaucht, und sie wiegt schwerer als alle vier zusammen.

Freitag, 15:50: Sie legen die Korrektur in den Freigabeordner, und am Montag haben zweihundert Arbeitsplätze sie übernommen, ohne dass jemand einen Finger gerührt hat. Genau dafür ist der Starter da. Und genau das macht ihn für andere interessant: Wer ihm eine falsche Datei unterschiebt, erreicht mit einem Schritt alle Arbeitsplätze, und ein Fehler verbreitet sich so schnell wie eine Korrektur. Wie verhindern wir also, dass das Werkzeug für schnelle Verteilung selbst zur Schwachstelle wird?

Im Oktober 2026 haben wir den Starter dafür gegen den CWE-Katalog von MITRE geprüft, die gemeinsame Liste bekannter Klassen von Softwareschwächen. Aussagen über den alten Starter stützen sich auf seinen erhaltenen Code von 2021.

Der alte Starter übernahm alles, was auf der Freigabe neuer war. Neuer heißt aber nicht echt: Eine Kollegin legt eine ungeprüfte Datei nach, ein Synchronisationsprogramm hinterlässt eine halbe Kopie, ein Angreifer mit Schreibrecht tauscht eine Bibliothek aus. Heute gehört zu jedem Release eine Liste aller Dateien mit Größe und SHA-256, signiert mit dem Lieferschlüssel des Herausgebers. Der Starter prüft jede Datei vor dem Kopieren und noch einmal an der Kopie, bevor irgendetwas sie öffnet. Passt etwas nicht, installiert er nichts, und die bisherige Version startet.

Eine gültige Signatur sagt dann zweierlei: Diese Dateien stammen von dem, der den Lieferschlüssel hält (Authentizität), und sie sind seitdem unverändert (Integrität). Sie sagt nicht, ob dieser Herausgeber das Release ausliefern durfte; das entscheidet die IT, indem sie festlegt, welcher Schlüssel in der Projektdatei steht und wer in den Quellordner schreiben darf (Autorisierung). Sie sagt nicht, ob der Bericht richtig rechnet (Korrektheit); dafür gibt es Test, Probelauf und den Weg zurück. Und sie sagt nichts über die Sicherheit des Codes der Anwendung selbst; dafür bleibt ihr Herausgeber verantwortlich.

Zwei Grenzen gehören dazu. Ohne Lieferschlüssel prüft der Starter nur, ob die Dateien zur Liste passen, nicht, wer sie geschrieben hat; ohne Liste installiert er, was geliefert wurde, so wie 2016. Die Prüfung der Projektdatei weist darauf hin, verbietet es aber nicht, damit bestehende Auslieferungen weiterlaufen. Und mit dem Schlüssel kann jedes Programm signieren, das unter dem Konto des Herausgebers läuft. Dieses Konto sollte deshalb nur zum Veröffentlichen dienen.

Die Prüfung hat in unserer eigenen Fassung 3.2 zwei Schwachstellen gefunden. Beide behebt 3.3.0.

Bibliotheken aus dem falschen Ordner. Seit ein USB-Stick ein vorgesehener Startort ist, wurde eine alte Gewohnheit von Windows zum Risiko: Programme suchen Bibliotheken zuerst im eigenen Ordner. Bis 3.2 tat das auch der Starter. Auf einem Stick oder einer Freigabe, die andere beschreiben können, wäre eine dort abgelegte, passend benannte DLL in den Prozess des Anwenders geladen worden. 3.3.0 lädt Windows-Bibliotheken nur noch aus dem Systemordner; die Abnahme jeder Fassung legt echte Windows-Bibliotheken neben den Starter und zählt, ob eine davon geladen wird.

Ein Ordnername, der keiner ist. Aus dem Produktschlüssel entstehen die Ordnernamen beim Anwender. Bis 3.2 nahm der Starter dort auch . und .. an, die den eigenen Ordner oder das Profil darüber bezeichnet hätten. Seit 3.3.0 folgt der Produktschlüssel einer strengen Zeichenregel.

Gefunden hat beide unsere eigene Prüfung. Das ist die angenehmere Reihenfolge.

• Eine alte Fassung mit bekannter Lücke kommt zurück auf die Freigabe. Signiert ist sie ja. Mit Lieferschlüssel installiert der Starter seit 2.2.4 nie eine niedrigere Version als die höchste, die der Benutzer je hatte, es sei denn, eine signierte Rücknahme nennt genau diese. Grenze: Ein neuer Benutzer oder PC installiert die ältere signierte Fassung.
• regsvr32 führt zum Registrieren Code aus der DLL aus, auf jedem Arbeitsplatz. Heute kommt die Registrierung als Daten (registration.json) unter HKEY_CURRENT_USER, und Programme starten mit festem Pfad, ohne Shell und ohne Suche über PATH. Grenze: Aktionen, etwa ein Treiberinstaller, kommen direkt aus dem Quellordner; die Signatur deckt sie nicht ab.
• Die Konfiguration schreibt, wohin sie will. Heute liegen Ziele nur in den Ordnern des Benutzers, und die Pfade der Lieferliste führen nicht aus der Version hinaus. Grenze: Vertrauensanker ist der Ordner des Starters mit der Projektdatei; er gehört per MSI nach Program Files, wo Anwender nicht schreiben.
• Ein Kennwort steht lesbar in der Konfiguration, beim alten Starter nur Base64-kodiert. Heute weist die Prüfung INI-Einträge ab, die wie Kennwörter aussehen, das Protokoll enthält keine Verbindungswerte, und die Übernahme lässt Kennwörter weg. Grenze: Was die Anwendung selbst speichert, verantwortet ihr Herausgeber.
• Der vertrauenswürdige Speicherort ist zu weit gefasst. Heute wird nur der Anwendungsordner des Benutzers eingetragen; verbietet eine Richtlinie das, startet der Starter nicht, statt sie zu umgehen. Grenze: Dann entscheidet die IT.
• Ein Abbruch hinterlässt alte und neue Dateien gemischt. Heute läuft jede Installation als Transaktion mit Journal; nach einem Stromausfall nimmt der Starter sie beim nächsten Start zurück. Grenze: Zwei Starter desselben Benutzers, die im selben Moment installieren, stimmen sich nicht ab.
• Die Lieferung ist nicht erreichbar oder lässt sich nicht prüfen. Heute startet die zuletzt funktionierende Version, und jeder Fall hat einen eigenen Code. Grenze: Der Anwender sieht keine Meldung, nur Protokoll und Diagnose zeigen es.

So oder so ähnlich passiert es überall: Am Freitag um 15:50 ist Version 3.2.1 signiert freigegeben. Am Samstag legt eine Kollegin eine korrigierte Berichtsvorlage direkt in den Quellordner, ohne neu zu veröffentlichen. Gut gemeint, schnell erledigt, nicht signiert.

Montag, 7:30: Die Datei passt nicht zur signierten Liste. Der Starter installiert nichts, startet die installierte 3.2.0 und vermerkt im Protokoll Code 51. Niemand arbeitet mit einem Gemisch aus zwei Versionen, aber auch niemand mit der Korrektur vom Freitag. Die Anwendungsbetreuung sieht den Code in der Diagnose, der Herausgeber prüft die Datei und veröffentlicht neu.

Mittwoch: 3.2.1 läuft überall, signiert und unverändert, und rechnet in einem selten genutzten Bericht falsch. Diesen Fehler erkennt keine Signatur, denn die Datei ist genau die freigegebene. Wer betroffen ist, startet 3.2.0 aus dem Einstellungsfenster; der Herausgeber legt 3.2.0 erneut in den Quellordner und zieht 3.2.1 mit /publish /withdraw 3.2.1 zurück. Ob zurückgegangen wird, entscheidet ein Mensch. Der Starter sorgt dafür, dass der Weg sicher ist.

Die Aufteilung der Zuständigkeiten von 2016 gilt weiter, und heute ist sie Teil des Schutzes: Jeder Teil darf weniger. Der Bootstrapper Manager hat keine eigenen Regeln, ob eine Projektdatei gültig ist, entscheidet der Starter. Der Herausgeber hält den Lieferschlüssel, aber welcher Schlüssel gilt, steht in der Projektdatei, die die IT verteilt. Ein gestohlener Schlüssel ohne Schreibrecht auf den Quellordner ist deshalb so wenig wert wie ein Schreibrecht ohne Schlüssel; die Ausnahme sind die Aktionen.

So sieht der Weg eines Release heute aus, von der Vorbereitung bis zum Start oder zur Rücknahme:

Darum ist der Kern des Bootstrapper nicht das Kopieren von Dateien. Kopieren konnte schon der Starter von 2016. Der Kern ist ein kontrollierter Lebenszyklus der Auslieferung, in dem Herkunft, Rechte, Fehler und der Weg zurück von Anfang an Teil der Architektur sind.

Zurück zur Fachabteilung und ihrem Bericht, diesmal mit dem Bootstrapper. Angenommen, Ihre Access-Anwendung hat zweihundert Anwender, Releases kommen mehrmals im Monat, und die IT hat feste Wartungsfenster.

Einmal, vor dem ersten Release. Sie legen das Projekt im Bootstrapper Manager an, tragen Quellordner, Dateien und Startziel ein, prüfen es, machen einen Probelauf und erstellen das MSI. Ihren Lieferschlüssel erzeugen Sie einmal und tragen seinen öffentlichen Teil ins Projekt ein. Die IT verteilt das Paket in einem ihrer Wartungsfenster und legt fest, wer in den Quellordner schreiben darf. Danach wartet kein Release mehr auf ein Wartungsfenster, nur noch ein neuer Starter oder eine neue Projektdatei.

Freitag, 15:40. Die Korrektur ist fertig. Sie legen das Release in den Quellordner und signieren es mit /publish. Um 15:50 ist es freigegeben, ohne Ticket, ohne neues Paket, ohne Wartungsfenster.

Montag, 7:30. Wer die Anwendung öffnet, sieht kurz das Fenster des Starters, während die neue Version in einen eigenen Ordner installiert wird. Dann öffnet sich die Anwendung mit dem richtigen Bericht, und der Taschenrechner bleibt in der Schublade. Die Kollegin in der Buchhaltung hat ihre alte Kopie noch offen und stört damit niemanden. Wer im Homeoffice ohne Verbindung zur Freigabe arbeitet, startet die installierte Version und bekommt das Release beim nächsten Start mit Verbindung.

Das sehen Ihre Anwender beim ersten Start einer neuen Version, danach öffnet sich die Anwendung. Vorschau aus dem Bootstrapper Manager mit Beispieldaten.

Donnerstag, ein Anruf: „Bei mir startet die Anwendung nicht.“ Statt eines Besuchs öffnet die Anwendungsbetreuung mit dem Anwender das Einstellungsfenster (/settings). Dort steht, ob die Anwendung starten kann und welche Versionen installiert sind. Der Fehlercode führt zu einer Seite mit Ursache und Lösung. Fehlt etwas, das der Starter selbst installieren darf, holt /repair es nach. Fehlt etwas, das Administratorrechte braucht, zum Beispiel ein systemweiter ODBC-Treiber, sagt der Code, was die IT bereitstellen muss.

Fertig geschrieben, freigegeben, beim Anwender angekommen: Zwischen dem ersten und dem dritten Zustand liegt keine Woche Handarbeit mehr, sondern der nächste Start. Die IT hat dafür keine Kontrolle abgegeben. Sie bestimmt, aus welchem Ordner ausgeliefert wird, wer dort schreiben darf und welcher Schlüssel gilt. Der Starter liefert Ihre Anwendung aus, er baut sie nicht; gebaut wird sie zum Beispiel mit dem Office SDK. Was er an Ihren Arbeitsplätzen voraussetzt, steht vollständig in der Dokumentation.

Den ersten Starter schon: Er war ein kleines Programm, und ein erfahrener Access-Entwickler schreibt so etwas. Aufwendig ist alles, was danach kam: Registrierung je Benutzer in der richtigen Bitness, die Transaktion mit Rücknahme auch nach einem Stromausfall, gezählte gemeinsame Komponenten, Signaturen mit Schutz vor zurückgespielten Fassungen, Fehlercodes mit eigener Hilfeseite, ein MSI für die IT und eine Sicherheitsprüfung, die auch in der eigenen Fassung etwas findet. Diese Liste ist das, was zehn Jahre Betrieb aus einem kleinen Programm gemacht haben, und jeder Punkt darauf muss gepflegt werden.

Ihre Access-Anwendung hat einige Dutzend oder einige hundert Anwender, Releases kommen mehrmals im Monat, und jede Auslieferung bedeutet Abstimmung, Kopieren und Nachsehen an einzelnen Arbeitsplätzen? Was würde es Ihnen bringen, wenn die IT den Rahmen einmal einrichtet und jedes weitere freigegebene Release beim nächsten Start ankommt, mit nachprüfbarer Herkunft und einem Weg zurück?

Wenn Sie eine ähnliche Umgebung haben, prüfen wir gern gemeinsam, ob der Bootstrapper passt, welche Voraussetzungen Ihre Arbeitsplätze brauchen und wie groß eine Einführung wäre.

Bootstrapper: Leistungsumfang, Voraussetzungen und Gesprächstermin · Lieber gleich sprechen

Weiterlesen: Frontend verteilen ohne Adminrechte zeigt, woran es am Montag nach einem Release an einzelnen PCs hakt. Die Geschichte des Office SDK erzählt, woher die Releases kommen, die der Starter verteilt.