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 (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. Beim Ablegen einer MSI werden das Paket und eine Entwurfs-Version sofort angelegt, und der Installer streamt im Hintergrund in den Speicher, während du weiterarbeitest. Eine EXE wartet auf dich: Trage Paket-ID und Version ein und klicke dann auf Entwurf erstellen & hochladen, um denselben Hintergrund-Upload zu starten.

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 — noch vor dem Veröffentlichen. Diese Tests führen echte Änderungen auf dem Gerät aus. Wenn die Pipeline passt, klickst du auf Veröffentlichen. Das Paket und seine Entwurfs-Version existieren zu diesem Zeitpunkt bereits — Veröffentlichen schreibt daher alles, was du konfiguriert hast, auf die Version und markiert sie als veröffentlicht.

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

Prüfe die im Uploadbereich angezeigte maximale Dateigröße deiner Instanz. Sie gilt für den Installer und jede Begleitdatei einzeln. Zu große Dateien werden vor dem Upload abgewiesen; wähle eine kleinere Datei, statt denselben Upload erneut zu versuchen.

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. Bei einer MSI startet der Upload sofort — ein Fortschrittsbalken zeigt, wie die Datei in den Speicher streamt, während du weiter ausfüllst. Bei einer EXE füllst du zuerst Paket-ID und Version aus und klickst dann auf Entwurf erstellen & hochladen, um ihn zu starten. Wenn du den Tab schließen willst, während ein 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 legt fest, wie octoja das Paket bei einer ausdrücklich gestarteten Deinstallation entfernt. Das Aufheben der Zuweisung oder Ändern der passenden Regeln beendet die weitere Verteilung, entfernt aber nicht die installierte App. Für eine dauerhafte Entfernung prüfst du zuerst alle zutreffenden Konfigurationspakete und entfernst oder begrenzt deren Softwarezuweisungen; sonst kann die App erneut installiert werden. Deinstalliere sie anschließend auf dem Gerät über Software installieren → Custom — siehe Software auf einem einzelnen Gerät installieren oder deinstallieren. Bei einer MSI wird die Deinstallationsmethode automatisch eingerichtet: octoja verwendet den erkannten MSI-ProductCode, den die Karte schreibgeschützt zeigt. 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, die du im Wizard anlegst, sind einfache Textfelder. 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. Die Zone bleibt deaktiviert, bis die Entwurfs-Version existiert, denn Begleitdateien hängen an ihr — leg also zuerst den Haupt-Installer ab. Danach streamt jede Begleitdatei 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 — das reicht bereits für einen Installer, der nur mit den konfigurierten Silent-Argumenten laufen soll. Ü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 zeigt nur Windows-Geräte — 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, Installations-Schritte und Deinstallations-Einstellungen 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. Änderungen durch Tests auf dem Gerät bleiben bestehen.

Schritt 11 — Die veröffentlichte Version testweise ausrollen (optional)

Tests einzelner Schritte im Wizard prüfen jeden Block für sich. Um die gesamte Pipeline von Anfang bis Ende zu prüfen, bevor du das Paket jemandem zuweist, nutze die Karte Test-Deployment auf der Detailseite des Pakets. Sie erscheint, sobald die Version veröffentlicht ist:

1. Öffne die Version auf der Detailseite des eigenen Pakets.
2. Wähl ein Zielgerät aus der Online-Geräteauswahl.
3. Trag die Parameter ein, die die Version erwartet — Pflichtparameter sind mit einem Sternchen markiert.
4. Klick auf Test-Deployment starten. Die vollständige Installations-Pipeline läuft ad hoc auf diesem einen Gerät, und Ausgabe anzeigen zeigt, was zurückkam.

Es wird keine Softwarezuweisung angelegt. Die Installation und ihre Änderungen bleiben aber auf dem Testgerät bestehen. Bei einer Entwurfs-Version ist die Karte ausgegraut, mit dem Hinweis, dass eine veröffentlichte Version nötig ist — vor dem Veröffentlichen sind die Tests einzelner Schritte im Wizard der richtige Weg.

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.

Willst du eine bestehende Version ändern statt eine neue anzulegen, klick auf der Detailseite daneben auf Bearbeiten. Der Wizard öffnet sich auf dieser Version, sodass du Silent-Argumente, Parameter, Begleitdateien, Installations-Pipeline und Deinstallations-Methode anpassen kannst. Die Installer-Datei und die Versionszeichenfolge bleiben unverändert — für eine neue Datei lädst du stattdessen eine neue Version hoch. Bei einer bereits veröffentlichten Version heißt die Schaltfläche Erneut veröffentlichen.

Paket an Geräte ausrollen

Auch eigene Windows-Pakete installiert octoja über Chocolatey. Fehlt es auf dem Gerät, versucht der Agent zuerst die Installation über WinGet: Bei der Standardquelle muss das Gerät https://cdn.winget.microsoft.com/cache und den Installer unter https://github.com/chocolatey/choco/releases/download/ erreichen. Schlägt das fehl oder ist WinGet nicht verfügbar, lädt der Agent https://community.chocolatey.org/install.ps1; das Skript fragt https://community.chocolatey.org/api/v2/Packages() ab und lädt das Chocolatey-Paket unter https://community.chocolatey.org/api/v2/package/chocolatey/<Version> herunter.

Erlaube ausgehendes HTTPS (TCP 443) vom verwalteten Gerät zu diesen Zielen einschließlich Weiterleitungen. Bei einer anderen WinGet-Quelle prüfe ihre Adresse mit winget source list. Für den Download deines hochgeladenen Installers gelten weitere Ziele.

Sobald eine Version veröffentlicht ist, fügst du das eigene Paket einem Konfigurationspaket hinzu:

1. Öffne das Konfigurationspaket und wechsle in den Tab Software.
2. Klicke auf Software hinzufügen.
3. Stell die Quellenauswahl im Dialog auf Eigene um — sie steht neben Chocolatey, Homebrew, winget und APT.
4. Wähl dein Paket, setz die beiden Felder aus der Tabelle unten und klick auf Zum Paket hinzufügen.

Eigene Pakete nutzen dieselben Zuweisungsregeln und denselben Verteilungszeitplan wie alles andere im Tab Software, und beim nächsten Agent-Sync wird die Version auf den passenden Windows-Geräten installiert. Den vollständigen Ablauf zeigt Software auf Geräte verteilen; die Feldsemantik erklärt So funktioniert die Software-Bereitstellung.

Tipps

• Neueste 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 deshalb setzt das erneute Veröffentlichen einer älteren Version jede Zuweisung zurück, die auf Neueste steht
• 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
• Parameter-Werte werden so gespeichert, wie du sie einträgst, und bleiben für jeden lesbar, der die Berechtigung Verwaltung benutzerdefinierter Pakete hat oder das Konfigurationspaket bearbeitet, das sie liefert. Behandle einen Parameter als Konfiguration, nicht als Tresor, und leg langlebige Zugangsdaten in einem dafür gebauten Secrets-Store ab
• 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 über die Agent-Verbindung online sind und auf denen deine Gruppen dir die Softwareverwaltung erlauben. Stell sicher, dass der Agent läuft, dass er sich seit dem Öffnen der Seite verbunden hat und dass du die Geräteaktion Softwareverwaltung dafür besitzt. Die Auswahl Zielgerät auf der Karte Test-Deployment ist genauso gefiltert.

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.

FAQ

Werden Änderungen nach einem Test automatisch entfernt?

Nein. Sowohl Auf Gerät testen im Wizard als auch Test-Deployment starten führen echte Installationsschritte aus. Installierte Programme, kopierte Dateien, Verknüpfungen und Änderungen durch Skripte bleiben bestehen. Auch Entwurf verwerfen macht diese Änderungen auf dem Gerät nicht rückgängig.

Deinstalliere die Testinstallation anschließend über den vorgesehenen Deinstallationsweg und bereinige zusätzliche Änderungen deiner eigenen Schritte. Die möglichen Wege beschreibt Software auf einem einzelnen Gerät installieren oder deinstallieren.

Stehen Paketparameter auch im Deinstallationsskript zur Verfügung?

Nein. Die Parameter der Zuweisung werden nur für die Installation bereitgestellt. Verlasse dich bei der Deinstallation nicht auf $env:OCTOJA_PARAM_<NAME>, {PLACEHOLDER}-Ersetzungen oder den Installationshelfer Resolve-Params.

Nutze möglichst den MSI-Produktcode oder den dokumentierten Deinstallationsbefehl des Herstellers. Ein eigenes Deinstallationsskript muss benötigte Werte selbst zuverlässig ermitteln. Prüfe Zielpfade vor Löschoperationen ausdrücklich und teste Installation und Deinstallation auf einem Testgerät, bevor du das Paket verteilst.

Wird %USERPROFILE% in einem Paketparameter automatisch aufgelöst?

Nein. Paketparameter sind Textwerte; die Ersetzung von {PARAMETER} wertet darin enthaltene Windows-Umgebungsvariablen nicht zusätzlich aus. Ob ein übergebener Text anschließend aufgelöst wird, hängt vom aufgerufenen Installer oder Skript ab.

Ermittle benötigte Pfade ausdrücklich im Skript und prüfe den Ausführungskontext. $env:USERPROFILE gehört zum ausführenden Konto: Unter Alle Benutzer ist das das Systemkonto, nicht der angemeldete Benutzer. Ein anderer Kontext allein macht aus einem Textparameter noch keinen aufgelösten Pfad.

Warum fragt die Direktinstallation am Gerät meine Paketparameter nicht ab?

Der Software-Dialog am Gerät erfasst keine Werte für eigene Paketparameter und übernimmt auch keine Werte aus einer Konfigurationspaket-Zuweisung. Füge das eigene Paket für kundenspezifische Werte im Tab Software des Konfigurationspakets hinzu und fülle dort Parameter aus.

Beschränke das Konfigurationspaket auf die vorgesehenen Geräte des Kunden und teste die Installation zuerst auf einem Gerät. Hinterlege keinen Kundentoken als Standardwert eines gemeinsam genutzten Pakets, um die fehlende Abfrage zu umgehen.

Kann ich eine Voraussetzung vor dem Download des Installers prüfen?

Ja. Setze ein PowerShell-Snippet vor Installer ausführen. Die Installer-Datei wird erst in ihrem Schritt heruntergeladen, nicht vor dem ersten Snippet. Lass das Snippet normal enden, um fortzufahren. Brich bei fehlender Voraussetzung mit throw ab und deaktiviere für diesen Schritt das Fortsetzen bei Fehlern. Verwende exit 0 nicht für „mit dem nächsten Schritt weitermachen“: Die Snippets laufen in einem gemeinsamen Skript.

Der Abbruch zählt als fehlgeschlagene Installation, nicht als erfolgreiches Überspringen. Teste beide Fälle vor dem Ausrollen auf einem Testgerät. Frühere Schritte und das Ausführungsskript des Pakets können bereits heruntergeladen oder ausgeführt worden sein.