Frontend verteilen ohne Adminrechte: woran es am Montag nach dem Release hakt

„Wie verteile ich mein Frontend?“ Die Frage taucht in den Access-Foren seit Jahren immer wieder auf, und die Antworten heißen Batch-Datei, Versionstabelle und Handarbeit. Sie funktionieren. Meistens.

Bis zu dem Montag, an dem kurz nach acht der erste Anruf kommt: „Bei mir geht nichts auf.“ Das Release vom Freitag läuft an drei Arbeitsplätzen nicht und an allen anderen schon. Wenn Ihnen das bekannt vorkommt, sind Sie in guter Gesellschaft.

Microsoft empfiehlt, eine Access-Anwendung für mehrere Benutzer aufzuteilen: die Daten im Backend auf dem Server, Formulare, Berichte und Code im Frontend. Von diesem Frontend bekommt jeder Anwender eine eigene Kopie auf seinen PC. Das ist richtig so, denn ein von allen gemeinsam geöffnetes Frontend ist langsamer und anfälliger für Beschädigungen.

Die Kehrseite: Jedes Release muss auf jeden PC. Bei zehn Anwendern ist das eine Mail mit Anhang. Bei zweihundert ist es ein Projekt.

Wer vor dem ersten Verteilen gezögert hat, weil unklar war, was dabei alles schiefgehen kann, hat nichts falsch gemacht. Die Schwierigkeit liegt im Verfahren, nicht bei Ihnen.

Das Frontend per Mail oder von Hand kopieren. Das funktioniert, solange alle mitmachen. Wer die alte Kopie noch geöffnet hat, behält sie, und wer welche Version hat, weiß nach dem dritten Release niemand mehr genau.

Eine Batch-Datei hinter der Desktop-Verknüpfung, die bei jedem Start das Frontend vom Netzlaufwerk kopiert. Einfach und beliebt. Wo Gruppenrichtlinien Skripte sperren, darf am Arbeitsplatz aber niemand BAT- oder CMD-Dateien ausführen, manchmal nicht einmal, wer die Anwendung entwickelt, und ein Programm installieren schon gar nicht. Scheitert das Skript, kann sich sein Fenster schließen, bevor jemand die Meldung liest. Zu sehen ist dann nur, dass nichts startet.

Eine Versionsprüfung im Frontend, die beim Start eine Versionstabelle im Backend vergleicht und die eigene Kopie austauscht. Elegant, aber jede Anwendung braucht dafür eigenen Code, und der Austausch gelingt nur, wenn das Frontend geschlossen ist. Ändert das Release auch die Datenstruktur, wird der schleichende Umstieg riskant.

• Die alte Kopie ist noch geöffnet. Der Austausch scheitert oder trifft eine Datei, die gerade benutzt wird.
• Die Bitbreite passt nicht. Steuerelemente und Komponenten, die Access lädt, brauchen dieselbe Bitbreite wie Office. Ist eine Komponente nur für 32 Bit registriert, scheitert sie auf einem PC mit 64-Bit-Office, und umgekehrt.
• Der Ordner ist kein vertrauenswürdiger Speicherort. Dann führt Access den Code der Anwendung nicht ohne Weiteres aus. Vertrauenswürdige Speicherorte stehen in der Registrierung jedes Benutzers; sie reisen nicht mit der Datei mit.

Dazu kommen ODBC-Treiber, Datenquellen und die .NET-Runtime, die die Anwendung braucht. Dafür sind meist Administratorrechte nötig, also ein Ticket bei der IT, für jedes Release.

Aus diesen Erfahrungen ergibt sich eine kurze Liste. Eine Verteilung, nach der der Montag ruhig bleibt,

• installiert je Benutzer und braucht keine Administratorrechte;
• legt jede Version in einen eigenen Ordner und überschreibt nie die laufende;
• erkennt die Bitbreite von Office und registriert die passenden Komponenten;
• richtet den vertrauenswürdigen Speicherort selbst ein;
• hält fest, was sie installiert hat, und nimmt alles zurück, wenn ein Schritt scheitert;
• startet die installierte Version, wenn das Netzlaufwerk gerade nicht erreichbar ist;
• nimmt nur Releases an, die wirklich vom Herausgeber stammen.

Genau diese Liste war die Vorgabe für den Bootstrapper. Die IT verteilt einmal den Starter, als signiertes MSI-Paket. Danach legen Sie jedes Release nur noch in den Quellordner. Beim nächsten Start installiert der Starter es in das Profil des Anwenders, registriert, was die Anwendung braucht, und öffnet sie.

Der Starter ist für beide Bitbreiten angelegt: eine einzige EXE-Datei, die erkennt, ob Access mit 32 oder 64 Bit läuft, und die passenden Komponenten registriert. Er arbeitet mit Microsoft Access aus Microsoft 365 unter Windows 11. Rechner mit Windows 10 und Rechner, auf denen AppLocker oder Windows Defender Application Control Programme im Benutzerprofil einschränken, unterstützt das aktuelle Release nicht. Access-Anwendungen sind sein Kern; jedes andere Programm startet er auf dieselbe Weise.

Geht ein Release schief, bleibt die vorige Version installiert und lässt sich aus dem Einstellungsfenster starten. Ihre Anwender arbeiten weiter, während Sie korrigieren.

Und der Montag? Der Kaffee hat eine gute Chance, warm zu bleiben.

Welche Konfigurationen im aktuellen Release freigegeben sind und wo die Grenzen liegen, steht offen auf der Produktseite.

Verteilen Sie ein Access-Frontend heute per Skript, Mail oder Versionstabelle an mehr als eine Handvoll Arbeitsplätze? Dann ist der erste Schritt ein Blick auf Ihre Umgebung: Bitbreite von Office, die Komponenten der Anwendung, die Richtlinien auf den Arbeitsplätzen. Danach wissen Sie, ob der Bootstrapper dort läuft und was die IT einmal einrichten muss. Zum Einsatz verpflichtet das nicht.

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