Bootstrapper · für Herausgeber von Access-Anwendungen und die IT
Access-Frontend ohne Administratorrechte verteilen
Sie legen das Release einmal in den Quellordner – beim nächsten Start ist es auf jedem PC. Ohne Ticket bei der IT, ohne Administratorrechte, mit Rücknahme bei Fehlern.
Die IT verteilt nur den Starter, und das einmal: als signiertes MSI-Paket. Er installiert jedes Release in das Profil des Anwenders, registriert, was die Anwendung braucht, und erfasst jede Datei, die er installiert.
- Release im Ordner
- Starter
- Jeder PC
Sie legen das Release einmal in den Quellordner. Beim nächsten Start installiert es der Starter in das Profil jedes Anwenders.
Ausgangslage
Das Release ist fertig. Jetzt muss es auf jeden PC.
Microsoft empfiehlt, dass jeder Anwender mit einer eigenen Kopie des Frontends arbeitet – des Teils der Access-Anwendung mit Formularen, Berichten und Code, der auf die gemeinsamen Daten zugreift. Das ist die richtige Aufteilung. Sie bedeutet aber: Bei jedem Release ist die Kopie auf jedem PC auszutauschen – meist von Hand, mit einem Anmeldeskript oder mit einer selbst gebauten Versionsprüfung: eine Versionstabelle im Backend und ein paar Zeilen VBA, die beim Start das neue Frontend herüberkopieren. Das funktioniert, solange nichts schiefgeht.
- Nach dem Austausch startet die Anwendung nicht bei jedem – und jeder Fehlstart wird ein Supportfall. Bei einem Anwender war die alte Kopie beim Austausch geöffnet. Beim nächsten sind die Komponenten in der falschen Variante (32 oder 64 Bit) registriert. Beim dritten liegt der Ordner an keinem vertrauenswürdigen Speicherort, also führt Access den Code der Anwendung nicht aus.
- Wer hat welche Version? Beim Kopieren von Hand oder per Anmeldeskript weiß das niemand genau: Aufgezeichnet wird nicht, was wo installiert wurde. Ein fehlerhaftes Release lässt sich deshalb auch nicht einfach zurücknehmen.
- Für jedes Release warten Sie auf die IT und auf Administratorrechte. Nicht zuletzt wegen der ODBC-Treiber, Datenquellen und der .NET-Runtime, die die Anwendung braucht.
Warum nicht MSI oder ClickOnce?
Je Benutzer wie ClickOnce, nachvollziehbar wie MSI
Das ist die erste Frage der IT – und eine berechtigte. Ein Windows-Installer-Paket ist nachvollziehbar, zentral verteilbar und sauber zu entfernen. Es braucht nach Angaben von Microsoft aber Administratorberechtigungen (Quelle), also ist jedes Release ein neues Paket. ClickOnce installiert je Benutzer und ohne Administratorrechte, veröffentlicht aber .NET-Anwendungen und Office-Lösungen – keine Access-Anwendungen.
Der Starter übernimmt von ClickOnce die Installation je Benutzer ohne Administratorrechte und von Windows Installer die Aufzeichnung jeder Datei, die Rücknahme bei Fehlern und das Entfernen über "Apps". Vergleich mit MSI, ClickOnce, Web Platform Installer und Anmeldeskripten
Mit dem Starter
Fehler im Release? Ihre Anwender arbeiten weiter.
Ein Release für 200 Anwender heißt: es einmal in den Quellordner legen. Wer die Anwendung danach öffnet, arbeitet mit dem neuen – und die vorige Version bleibt daneben installiert.
Quellordner
- Release 1.4.0
Sie legen es einmal ab.
nächster Start · jeder Schritt protokolliert
Profil des Anwenders
- 1.4.0 – startet ab jetzt
- 1.3.0 – bleibt installiert
Jede Version hat ihren eigenen Ordner. Die laufende wird nie überschrieben.
Schlägt ein Schritt fehl, wird alles zurückgenommen
Fehler im Release
- 1.3.0 aus dem Einstellungsfenster starten
bis das korrigierte Release bereitliegt
- Die alte Kopie ist in der Buchhaltung noch offen? Kein Problem: Das neue Release kommt in einen eigenen Ordner.
- Freigabe weg, Arbeit geht weiter. Die installierte Version startet, das Update wartet bis zum nächsten Start.
- Wer hat welche Version? Die aus dem Quellordner: Jeder Start prüft ihn, bevor sich die Anwendung öffnet. Für jeden Anwender ist jede installierte Datei und jeder Registrierungswert erfasst.
So kommt ein Release zu Ihren Anwendern
Das nächste Release erzeugt kein Ticket bei der IT. Die Arbeit verteilt sich auf drei Schritte, und der zweite wiederholt sich nicht.
- Release einmal beschreiben
- IT verteilt den Starter einmal
- Jeder Start übernimmt das Release
Das Release einmal beschreiben
Welche Dateien, welche Registrierungswerte, welche Verknüpfungen und was gestartet wird: Das steht in der Projektdatei, gepflegt im Bootstrapper Manager. Tragen Sie dort auch Ihren Lieferschlüssel ein, nimmt der Starter nur Releases mit Ihrer gültigen Signatur an. Jedes weitere Release legen Sie nur noch in den Quellordner oder die Freigabe.
Die IT verteilt den Starter einmal – nie wieder wegen eines neuen Release
Aus Projektdatei und Starter entsteht ein signiertes Windows-Installer-Paket für Gruppenrichtlinie, Intune oder Configuration Manager. Ein neues Paket braucht es nur, wenn sich der Starter oder die Projektdatei ändert.
Jeder Start übernimmt das Release als Transaktion
Beim Start prüft der Starter den Quellordner und die Voraussetzungen. Registriert wird, was die Anwendung braucht: Komponenten passend zum installierten Office, ODBC-Treiber, Datenquellen, die .NET-Runtime und der vertrauenswürdige Speicherort. Geht der PC mitten in der Installation aus, wird sie spätestens beim nächsten Start zurückgenommen. Der Starter schreibt nur in die Ordner des Anwenders und in dessen Teil der Registrierung – Administratorrechte braucht er nie.
Die Projektdatei pflegen, ohne JSON zu schreiben
Im Bootstrapper Manager (früher Starter-Konfigurator), einer Access-Anwendung für Herausgeber, tragen Sie Dateien, Verknüpfungen und Bedingungen ein wie in ein Formular, sehen das Fenster des Starters in der Vorschau, machen einen Probelauf und erzeugen das MSI-Paket. Ob die Projektdatei gültig ist, beurteilt der Starter selbst – der Bootstrapper Manager zeigt jedes Problem mit dem Teil der Datei, den es betrifft.
Der Bootstrapper Manager wird mit dem Office SDK installiert; seine Oberfläche folgt der Sprache von Office: Deutsch, Englisch oder Slowenisch. Zum Benutzerhandbuch
Stand und Grenzen
Passt der Starter zu Ihrer Umgebung?
Freigegeben
Er passt, wenn Ihre Anwender mit Windows 11 und Microsoft Access aus Microsoft 365 arbeiten, in 32 oder 64 Bit, und das Release in einem Ordner oder auf einer Freigabe liegt. Prüfen Sie vorher diese Punkte:
- Windows 10, AppLocker oder Windows Defender Application Control: Rechner mit Windows 10 und Rechner, die Programme im Benutzerprofil einschränken, unterstützt dieses Release nicht.
- Was Administratorrechte braucht, stellt weiter die IT bereit: systemweite Treiber, die Access Runtime oder computerweite Registrierungen. Der Starter prüft sie und meldet, was fehlt.
- Releases über HTTP oder HTTPS holt der Starter nicht; die Quelle ist ein Ordner oder eine Freigabe.
- Gebaut wird woanders: Der Starter verteilt Releases, er erzeugt sie nicht. Die Anwendung selbst entsteht zum Beispiel mit dem Office SDK.
- Immer nur ein Start: Zwei Starter desselben Benutzers, die gleichzeitig installieren, stimmen sich nicht ab.
- Die Signatur eines Release deckt die Programme nicht ab, die als Aktionen ausgeführt werden.
Ihr Einstieg – je nach Aufgabe
Jeder im Team fängt woanders an: der Herausgeber bei der Projektdatei, die IT beim Paket, der Anwendungsadministrator bei der Diagnose.
- Herausgeber: eine Anwendung ausliefernProjektdatei aus Vorlagen anlegen, Quellordner und Startziel eintragen, prüfen und ausprobieren – für eine Access-Anwendung oder jedes andere Programm.
- IT: den Starter per MSI verteilenEinmal als signiertes Paket – und genau nachlesen, was der Starter auf einem Rechner schreibt.
- Anwendungsadministrator: Fehler behebenDiagnose, frühere Versionen, Reparatur – und zu jedem Fehlercode eine Seite mit Ursache und Lösung.
Sie wollen wissen, was der Starter umfasst und was Ihre Umgebung dafür mitbringen muss? Funktionen, Voraussetzungen und Grenzen stehen vollständig auf der Produktseite.
Zur Produktseite