Eigene Pakete erstellen und verteilen

Eigene Pakete erstellen und verteilen

Eigene Pakete erlauben dir, eigene Installer (MSI oder EXE) hochzuladen und sie genauso an verwaltete Windows-Geräte zu verteilen wie Software aus Chocolatey, Winget, Homebrew oder APT. Sie sind nützlich für Branchenlösungen, herstellereigene Pakete, die nicht in einem öffentlichen Katalog liegen, und interne Builds, die du selbst pflegst.

Nur Windows. Eigene Pakete verteilen MSI- oder EXE-Artefakte und gelten nur für Windows-Agenten. Für plattformübergreifende Verteilung öffentlicher Software verwende die Kataloge Chocolatey, Winget, Homebrew und APT auf einem Konfigurationspaket.

Voraussetzungen

• Die Berechtigung Verwaltung benutzerdefinierter Pakete (custom-packages.manage, erteilt über Gruppen unter Administration → Gruppen) — erforderlich, um eigene Pakete anzulegen, zu bearbeiten, zu veröffentlichen und zu löschen
• Eine oder mehrere MSI- oder EXE-Installer-Dateien
• Mindestens ein online erreichbares Windows-Gerät (mit installiertem Agenten), wenn du Schritte vor dem Veröffentlichen an einem echten Rechner testen möchtest

So funktioniert es

Du öffnest die Seite Neues eigenes Paket unter Konfiguration → Eigene Pakete — ein Wizard, der dich durch den gesamten Ablauf führt. Du legst einen Installer ab und konfigurierst, wie er installiert werden soll. Eine MSI wird im Browser analysiert — Produktcode, Name, Version, Hersteller und öffentliche Installations-Properties werden automatisch extrahiert und füllen das Formular vor. Eine EXE enthält keine zuverlässigen Metadaten, daher gibst du Paket-ID und Versionszeichenfolge selbst an. Während du weiterarbeitest, streamt der Installer als Entwurfs-Version im Hintergrund in den Speicher.

Im Wizard baust du eine Installations-Pipeline aus drei Blocktypen zusammen: Installer ausführen, Datei kopieren und PowerShell-Snippet. Jeder Block lässt sich einzeln gegen ein Online-Windows-Gerät testen, das du oben in der Leiste Live-Test: auswählst — ohne dass etwas dauerhaft festgeschrieben wird. Wenn die Pipeline passt, klickst du auf Veröffentlichen. Es gibt keinen separaten „Erstellen"-Schritt — der eine Submit-Button legt das Paket an, hängt die Version dran und veröffentlicht sie in einem Rutsch.

Schritt 1 — Wizard öffnen

1. Gehe zu Konfiguration → Eigene Pakete.
2. Klicke oben rechts auf Neues eigenes Paket. Der Wizard öffnet sich.

Schritt 2 — Installer ablegen

1. Ziehe deine Installer-Datei auf den Bereich Installer hier ablegen (.msi oder .exe) in der Karte Installer, oder klicke ihn an und wähle die Datei aus.
2. Bei einer MSI analysiert octoja sie direkt im Browser. Unter der Datei-Zeile erscheinen die extrahierten Werte ProductCode, ProductName, Version, Manufacturer und SHA-256. Eine EXE hat solche Metadaten nicht, daher wird nichts extrahiert — Paket-ID und Versionszeichenfolge trägst du in den nächsten Schritten selbst ein.
3. Der Upload startet sofort. Ein Fortschrittsbalken zeigt, wie die Datei in den Speicher streamt, während du weiter ausfüllst. Wenn du den Tab schließen willst, während der Upload läuft, wirst du mit einer Rückfrage gestoppt.

Schritt 3 — Metadaten prüfen und anpassen

Bei einer MSI füllt der Wizard die Karte Metadaten aus dem Installer vor; bei einer EXE trägst du sie selbst ein, und es erscheint ein zusätzliches Feld Version, in dem du die Versionszeichenfolge festlegst, unter der veröffentlicht wird. Passe sie nach Bedarf an:

Schritt 4 — Silent-Argumente setzen

Die Karte Argumente für die unbeaufsichtigte Installation steuert, wie der Installer unbeaufsichtigt läuft. Bei einer MSI füllt octoja das Feld mit /quiet /norestart vor, was für fast jede ordentliche MSI passt; überschreibe das nur, wenn dein Installer eigene MSI-Properties braucht (z. B. LICENSE_KEY=…) oder andere Verbosity-Flags. Bei einer EXE schlägt das Feld /S vor, aber das richtige Silent-Flag hängt vom Installer ab: /S (NSIS), /VERYSILENT /SUPPRESSMSGBOXES (Inno Setup) oder /s (InstallShield). Trage die Flags ein, die dein Installer erwartet, oder lass das Feld nur dann leer, wenn die EXE bereits still installiert.

Wenn dein Installer Werte braucht, die sich pro Gerät oder pro Zuweisung unterscheiden, modelliere sie lieber als Parameter, statt sie hier hart hineinzuschreiben — siehe Schritt 6.

Schritt 5 — Festlegen, wie das Paket deinstalliert wird

Die Karte Deinstallation sagt octoja, wie das Paket entfernt wird, falls seine Zuweisung einmal aufgehoben wird. Bei einer MSI läuft das automatisch — octoja deinstalliert über den erkannten MSI-ProductCode, und die Karte zeigt ihn schreibgeschützt an. Eine EXE hat keinen Produktcode, daher wählst du eine Methode:

Schritt 6 — Parameter hinzufügen (optional)

Öffentliche Properties, die in einer MSI gefunden wurden, erscheinen in der Karte Parameter als Vorschläge mit einem kleinen +-Badge. Klick auf einen Vorschlag macht ihn zu einem echten Parameter. Eine EXE hat keine Properties, die vorgeschlagen werden könnten, daher fügst du dort jeden Parameter von Hand hinzu. In beiden Fällen kannst du über Parameter hinzufügen eigene Schlüssel definieren (z. B. OCTOJA_URL, LICENSE_KEY).

Parameter können einfache Strings oder als Secret markiert sein (maskiertes Eingabefeld). Der Wert, den du hier eintippst, wird live an die Tests einzelner Schritte weitergegeben, damit {PLATZHALTER}-Ersetzungen gegen das aktuell getestete Setup aufgelöst werden. Bei der Verteilung wird derselbe Parameter aus der Zuweisung auf dem Konfigurationspaket befüllt.

Schritt 7 — Begleitdateien anhängen (optional)

Wenn die Installation zusätzliche Artefakte braucht — Konfigurationsdateien, Lizenz-Blobs, Zertifikate, MSI-Transforms — leg sie auf der Drop-Zone Begleitdateien ab. Jede Begleitdatei streamt parallel zum Haupt-Installer in den Speicher und zeigt einen eigenen Fortschrittsbalken. Anschließend kannst du jede Begleitdatei aus einem Datei kopieren-Schritt in der Installations-Pipeline referenzieren.

Schritt 8 — Installations-Pipeline bauen

Die Karte Installations-Pipeline ist der Kern des Wizards. Standardmäßig enthält sie einen einzigen Installer ausführen-Schritt — was bereits ausreicht, wenn du einen Installer einfach mit den konfigurierten Silent-Argumenten ausführen willst. Über Schritt hinzufügen erweiterst du die Pipeline. Die drei Blocktypen sind:

Über den Griff links an jedem Schritt kannst du die Reihenfolge per Drag&Drop ändern. Die Schritte laufen auf dem Agenten von oben nach unten.

Schritt 9 — Einzelne Schritte am Live-Gerät testen

Die Leiste Live-Test: oben im Wizard enthält eine Geräteauswahl, die Windows-Geräte zeigt, die aktuell über die Agent-Verbindung erreichbar sind. Wähl eines aus — der Picker ist auf windows gefiltert — und jede Schritt-Karte in der Pipeline bietet eine Aktion Auf Gerät testen. Jeder Test führt diesen einzelnen Schritt ad hoc auf dem gewählten Gerät aus. Es gibt eine Auswahl Ausführen als für System (LocalSystem) vs. die angemeldete Benutzersitzung, und die Befehlsausgabe kommt direkt zurück, damit du Exit-Codes und stdout/stderr siehst, bevor du die Version festschreibst.

Tests einzelner Schritte funktionieren, sobald der Haupt-Installer hochgeladen ist. Du musst dafür noch nicht veröffentlichen.

Schritt 10 — Veröffentlichen

Wenn die Pipeline passt, klick auf Veröffentlichen unten rechts in der Aktionsleiste. Der Wizard:

1. Speichert die Paket-Metadaten.
2. Persistiert Silent-Argumente, Parameter und Installations-Schritte auf der Version.
3. Markiert die Version als Veröffentlicht.
4. Springt zur Detailseite des eigenen Pakets.

Falls du es dir vorher anders überlegst, klick auf der linken Seite der Aktionsleiste auf Entwurf verwerfen. octoja löscht das angefangene Paket und den teilweisen Upload — es bleibt nichts zurück.

Spätere Versionen nachschieben

Klicke auf der Detailseite eines eigenen Pakets auf Neue Version hochladen, um den Wizard im Modus Neue Version zu öffnen. Die Metadaten bleiben gesperrt (die Paket-ID ist Teil des Speicherpfads); du legst nur einen neuen Installer ab, justierst Silent-Argumente, Parameter, Begleitdateien und Pipeline und klickst Veröffentlichen. octoja behält jede je hochgeladene Version — du kannst später eine andere veröffentlichen (Rollback) oder nicht mehr benötigte Versionen über die Detailseite löschen.

Paket an Geräte ausrollen

Sobald eine Version veröffentlicht ist, kann das eigene Paket im Tab Software eines beliebigen Konfigurationspakets ausgewählt werden — neben Chocolatey-, Winget-, Homebrew- und APT-Einträgen. Füge es dort hinzu, leg die Zuweisungsregeln und den Verteilungszeitplan am Konfigurationspaket fest, und beim nächsten Agent-Sync wird es auf den passenden Windows-Geräten installiert. Den vollständigen Ablauf zeigt Software auf Geräte verteilen; die Feldsemantik findest du in der Referenz für Software-Deployments.

Tipps

• Aktuell ist immer die zuletzt veröffentlichte Version — octoja vergleicht keine Versions-Strings, daher zählt eine nach 2025.10.1 veröffentlichte 2025.9.9 als neuer. Der Version-String (aus einer MSI erkannt oder für eine EXE eingetippt) ist ein Etikett für Menschen. Denk daran, wenn du Hotfixes aus älteren Branches veröffentlichst — und genau deshalb funktioniert der Rollback über das erneute Veröffentlichen einer älteren Version
• Halte die Paket-ID stabil — Zuweisungen in Konfigurationspaketen referenzieren eigene Pakete per ID, und Umbenennen würde jede Zuweisung verwaisen. Der Wizard sperrt die ID nach Entwurfs-Anlage genau deshalb
• Markiere sensible Werte als Secret-Parameter, damit das Eingabefeld maskiert ist. Der Wert wird trotzdem gespeichert und ist für jeden mit der Berechtigung Verwaltung benutzerdefinierter Pakete sichtbar — das ist UI-Hygiene, keine Verschlüsselung. Nutze für echte Geheimnisse einen Secrets-Store, falls du einen hast
• Der PowerShell-Block ist ein Notausgang. Wenn du ihn bei jedem Paket brauchst, ist die Kombination aus Installer ausführen und Datei kopieren wahrscheinlich die passendere Lösung

Fehlerbehebung

Der Upload bleibt für immer bei „Wird hochgeladen". Der Upload streamt im Hintergrund; wenn er nie abschließt, hat der Browser-Tab vermutlich die Netzwerkverbindung verloren. Lade die Seite neu und leg die Datei erneut ab. Fehlgeschlagene Uploads verbrauchen keinen Speicher.

Der Bereich Installer hier ablegen verweigert die Datei. Nur MSI- und EXE-Installer werden akzeptiert. ZIP und andere Archivformate werden nicht unterstützt — verpacke sie zuerst in eine MSI oder EXE, oder bilde die Installations-Logik über einen PowerShell-Snippet-Schritt ab.

Die Schaltfläche Veröffentlichen bleibt deaktiviert. Veröffentlichen wird erst freigegeben, wenn der Haupt-Installer-Upload abgeschlossen ist, alle Begleitdatei-Uploads abgeschlossen sind, das Feld Name nicht leer ist und keine andere Mutation läuft. Achte auf die Badges neben jeder Dateizeile — alles, was noch einen Upload-Spinner zeigt, blockiert den Submit.

Der Live-Test-Picker ist leer. Der Picker zeigt nur Windows-Geräte, die aktuell über die Agent-Verbindung online sind. Stell sicher, dass der Agent läuft und sich seit dem Öffnen der Seite verbunden hat.

Eine veröffentlichte Version wird von Agenten nicht abgeholt. Der Agent wendet Konfigurationspaket-Änderungen erst beim nächsten Sync-Zyklus an. Warte auf den nächsten Zyklus, oder stelle den Verteilungszeitplan des Konfigurationspakets auf ein engeres Intervall, wenn die Änderung schneller ankommen soll.