Windows-Package-Manager
Out of the Box
Veröffentlicht in Ausgabe 10/2022 - PRAXIS
Möchte ein Windows-Nutzer ein einfaches Programm wie beispielsweise 7-Zip, GreenShot oder Notepad++ auf seinem Rechner installieren, muss er die Installer (EXE oder MSI) aus dem Internet herunterladen, die Installation starten und den grafischen Assistenten durchklicken, obwohl in der Regel jedes Mal die gleichen Angaben gemacht werden. Alle genannten Programme unterstützen eine unbeaufsichtigte Installation, doch kaum jemand hat die Parameter sofort parat, und es dauert länger, diese nachzuschlagen als den Installer durchzuklicken. Um Applikationen auf dem neusten Stand zu halten, installieren Sie in der Regel einfach eine neuere Version. Manche Programme wie Notepad++ oder KeePass weisen den Nutzer zwar darauf hin, dass eine aktualisierte Version verfügbar ist, das Herunterladen und Installieren muss er jedoch manuell erledigen.
Alternativen zu dieser "Einzelfallbetreuung" gibt es schon lange. Für mobile Endgeräte haben sich spätestens seit der Vorstellung des iPhone herstellereigene App-Stores als Standard etabliert. Apple bietet ein ähnliches Konzept auch für sein Desktop-Betriebssystem macOS an. Und auch Microsoft hat mit dem Microsoft-Store eine zentrale Plattform zum Installieren und Aktualisieren von Anwendungen geschaffen. Allerdings erfreut sich die Plattform bei den Softwareanbietern nicht ähnlich großer Beliebtheit wie Apples AppStore oder Google Play. Die Gründe dafür sind vielfältig, führen jedoch im Endeffekt dazu, dass auch Windows-Endbenutzer beim Bezug von Software eher zurückhaltend gegenüber dem Microsoft-Store sind.
Praktische Repositories
Einen grafischen Store zum Auffinden und Installieren von Anwendungen aus einem Katalog finden Sie mittlerweile auch bei den meisten Linux-Distributionen, die für den Desktopeinsatz bestimmt sind: SuSE Tumbleweed, Ubuntu, ElementaryOS und andere. Darüber können beispielsweise kostenpflichtige Softwaretitel erworben werden. Für die große Masse an Open-Source- und Freeware-Anwendungen sowie betriebssystemnaher Tools setzt Linux seit Jahrzehnten erfolgreich auf ein anderes Konzept – textbasierte Package-Manager, die auf eine erweiterbare Liste von Repositories zugreifen, um Anwendungen und Bibliotheken aufzufinden, die Abhängigkeiten zwischen ihnen zu bestimmen und letztendlich Installationen, Deinstallationen und Aktualisierungen zu ermöglichen. Die in den Repositories gelisteten Pakete folgen jeweils einem bestimmten, von Distribution zu Distribution unterschiedlichem Format.
Möchte ein Windows-Nutzer ein einfaches Programm wie beispielsweise 7-Zip, GreenShot oder Notepad++ auf seinem Rechner installieren, muss er die Installer (EXE oder MSI) aus dem Internet herunterladen, die Installation starten und den grafischen Assistenten durchklicken, obwohl in der Regel jedes Mal die gleichen Angaben gemacht werden. Alle genannten Programme unterstützen eine unbeaufsichtigte Installation, doch kaum jemand hat die Parameter sofort parat, und es dauert länger, diese nachzuschlagen als den Installer durchzuklicken. Um Applikationen auf dem neusten Stand zu halten, installieren Sie in der Regel einfach eine neuere Version. Manche Programme wie Notepad++ oder KeePass weisen den Nutzer zwar darauf hin, dass eine aktualisierte Version verfügbar ist, das Herunterladen und Installieren muss er jedoch manuell erledigen.
Alternativen zu dieser "Einzelfallbetreuung" gibt es schon lange. Für mobile Endgeräte haben sich spätestens seit der Vorstellung des iPhone herstellereigene App-Stores als Standard etabliert. Apple bietet ein ähnliches Konzept auch für sein Desktop-Betriebssystem macOS an. Und auch Microsoft hat mit dem Microsoft-Store eine zentrale Plattform zum Installieren und Aktualisieren von Anwendungen geschaffen. Allerdings erfreut sich die Plattform bei den Softwareanbietern nicht ähnlich großer Beliebtheit wie Apples AppStore oder Google Play. Die Gründe dafür sind vielfältig, führen jedoch im Endeffekt dazu, dass auch Windows-Endbenutzer beim Bezug von Software eher zurückhaltend gegenüber dem Microsoft-Store sind.
Praktische Repositories
Einen grafischen Store zum Auffinden und Installieren von Anwendungen aus einem Katalog finden Sie mittlerweile auch bei den meisten Linux-Distributionen, die für den Desktopeinsatz bestimmt sind: SuSE Tumbleweed, Ubuntu, ElementaryOS und andere. Darüber können beispielsweise kostenpflichtige Softwaretitel erworben werden. Für die große Masse an Open-Source- und Freeware-Anwendungen sowie betriebssystemnaher Tools setzt Linux seit Jahrzehnten erfolgreich auf ein anderes Konzept – textbasierte Package-Manager, die auf eine erweiterbare Liste von Repositories zugreifen, um Anwendungen und Bibliotheken aufzufinden, die Abhängigkeiten zwischen ihnen zu bestimmen und letztendlich Installationen, Deinstallationen und Aktualisierungen zu ermöglichen. Die in den Repositories gelisteten Pakete folgen jeweils einem bestimmten, von Distribution zu Distribution unterschiedlichem Format.
Gepflegt werden die Repositories auf drei Arten:
- Maintainer einer Distribution pflegen Repositories, die sie bei der Auslieferung ihrer Distribution bereits vorinstallieren. Hier sind die meisten systemnahen Tools und Bibliotheken zu finden, doch auch Anwendungsprogramme werden mitunter in die Mainstream-Repositories aufgenommen, um die Vielseitigkeit der eigenen Distribution zu steigern. Dabei stehen die Maintainer mit ihrem guten Namen für die Qualität und gegenseitige Kompatibilität der angebotenen Pakete, was einen hohen Aufwand beim Testen neuer Versionen bedeutet.
- Softwarehersteller, die Anwendungen für Linux entwickeln, darunter auch Microsoft, bieten oft eigene Repositories an, die ausschließlich Produkte des jeweiligen Herstellers beinhalten. Sind allgemeine Bibliotheken als Abhängigkeiten gefragt, müssen sie aus einem anderen auf dem gleichen System registrierten Repository bezogen werden können. In solchen herstellereigenen Repositories sind in der Regel die aktuellsten Versionen der Produkte zu finden, aber die Kompatibilität der angebotenen Pakete zu einzelnen Distributionen und Versionen kann schwanken.
- Manchmal passiert es, dass ein Teil der Mainstream-Ausstattung von den Maintainern einer Distribution aufgegeben wird, obwohl die dort enthaltene Software noch bei Endnutzern im Einsatz ist oder andere Produkte diese als Voraussetzung benötigen. Dies führt dazu, dass Projekte oder "Special Interest Groups" innerhalb der Community entstehen, um diese Pakete weiter zu pflegen und sie im Rahmen eines eigenen Repositories anzubieten.
Diese auf den ersten Blick komplexe Architektur führt zu einer sehr befriedigenden User-Experience: Mit einigen wenigen Befehlen können Sie nach verfügbaren Paketen suchen, diese installieren oder deinstallieren. Dabei berücksichtigt der Package-Manager die Abhängigkeiten der gewünschten Applikation und installiert sie bei Bedarf mit oder bricht die Installation ab, falls Sie mit der Installation oder dem Update eines der erforderlichen Pakete nicht einverstanden sind. Die Befehlssyntax ist bei den verschiedenen Pack-age-Managern zwar nicht identisch, die Logik dahinter jedoch sehr ähnlich, was Administratoren ermöglicht, sich bei einem Wechsel der verwendeten Distribution schnell in der neuen Package-Landschaft zurechtzufinden.
Eine ähnliche Benutzererfahrung, die nebenbei auch das Skripten komplexer Installationen erlaubt, wünschen sich viele Windows-Administratoren seit vielen Jahren. Im Laufe der Zeit haben sich einige Entwickler-Communities an die Aufgabe gewagt, einen vollwertigen Package-Manager für Windows bereitzustellen. Drei dieser Projekte verdienen dabei besondere Erwähnung:
- Chocolatey [1] kann auf eine mehr als zehnjährige Entwicklungsgeschichte zurückblicken und hat sich zum De-facto-Standard für die kommandozeilenbasierte Paketverwaltung unter Windows entwickelt.
- Scoop [2] verfolgt den Ansatz, Installationen im Benutzerkontext (und somit auch im Benutzerprofil) zu ermöglichen und die Pakete möglichst voneinander zu isolieren. Das schränkt die Auswahl der verfügbaren Anwendungen naturgemäß etwas ein, erweitert aber gleichzeitig die potenzielle Benutzerbasis.
- AppGet von Keivan Beigi [3] war ursprünglich angetreten, sowohl technische Herausforderungen der Paketverwaltung unter Windows zu lösen als auch organisatorische Hürden der Paketprüfung und -freigabe zu überwinden. Anfang 2020 äußerte Microsoft die Absicht, den Autor und sein Produkt zu übernehmen, entschied sich jedoch noch im selben Jahr dagegen. Die Ideen, die AppGet zugrundeliegen, bildeten indes die Grundlage für ein eigenes Open-Source-Projekt von Microsoft: WinGet [4]. Nach einem medialen Aufschrei in der Community gab Microsoft zu [5], die Ideen von AppGet direkt verwendet zu haben.
Der Klassiker: Chocolatey
Chocolatey wurde 2011 von Rob Reynolds entwickelt; inzwischen arbeitet ein ganzes Team an dem Produkt. Die ursprüngliche Idee bestand darin, die Funktionalität von NuGet (Installieren und Einbinden von Komponenten in Softwareprojekte) auf ganze Anwendungspakete auszuweiten und damit auf die Bedürfnisse der Endbenutzer und Systemadministratoren einzugehen. Der Name "Chocolatey" ist eine kulinarische Analogie zu "NuGet" (Nougat), wie die Webseite des Unternehmens berichtet. Das Programm "choco", das sämtliche Funktionen von Chocolatey abbildet, wird selbst als NuGet-Paket ausgeliefert.
Der Einstieg in Chocolatey in dessen Community Edition ist maximal einfach. Sie können das Produkt auf allen Windows-Versionen ab Server 2003 und Windows 7 in 32 und 64 Bit installieren, sofern das .NET Framework 4 vorhanden ist. Die Installationswebsite präsentiert dafür neben Setuphinweisen einen PowerShell-Einzeiler, der ein Skript herunterlädt und ausführt:
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtoco-bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
Dieses "install.ps1"-Skript wiederum lädt das NuGet-Paket herunter und installiert die Programmkomponenten in die dafür vorgesehenen Pfade. Letztere liegen allerdings, anders als von Microsoft vorgesehen, in "%ProgramData%" statt in "%ProgramFiles%". Für Organisationen, die bereits Ansible, Chef oder Puppet im Einsatz haben, bietet die Chocolatey-Website auch entsprechende Playbook-Definitionen. Diese setzen allerdings voraus, dass Sie bereits ein internes NuGet-Repository eingerichtet und das Chocolatey-Paket in dieses hochgeladen haben.
Sobald Chocolatey installiert ist, haben Sie Zugriff auf das Community-Repository, in dem sich mehrere Tausend Pakete für verschiedene Anwendungen befinden. Sie können das Repository mit
choco search <Teil des Paketnamens> durchsuchen und ein gewünschtes Paket mittels choco install <Paketname> auf Ihrem System installieren. Werden dafür administrative Rechte benötigt, muss der aufrufende Account über entsprechende Berechtigungen verfügen und je nach Konfiguration auch die UAC-Abfrage bestätigt werden.Eine durch Chocolatey installierte Anwendung können Sie mit c
hoco upgrade <Paketname> auf die neuste im Repository verfügbare Version bringen oder mit choco uninstall <Paketname> von Ihrem System entfernen.Das Repository dahiner ist entscheidend
Repositories tragen maßgeblich zum Erfolg eines Package-Managers bei, denn nur ein volles und aktuelles Repository garantiert das aus Linux gewohnte Nutzererlebnis beim Auffinden und Installieren von Paketen. Ein schlecht gepflegtes Repository ist nicht nur unattraktiv, sondern kann auch die Systeme seiner Nutzer gefährden, indem die dort aktuelle Version eines Paketes in Wirklichkeit bereits lange veraltet ist.
Das Community-Repository von Chocolatey beinhaltet mehrere Tausend Pakete, und einige Chocolatey-Nutzer bestücken ihre Systeme ausschließlich daraus. Allerdings unterliegen die Pakete im Community-Repository keiner wirklichen Qualitätskontrolle. Es ist also durchaus möglich, dass jemand in böser Absicht ein Paket veröffentlicht, das den Namen einer populären Anwendung trägt und bei der Installation Schaden auf den Zielsystemen anrichtet. Dieser Umstand wurde auch von Keivan Beigi in seinem Post [3] kritisiert. Wenn Sie also ausschließlich vertrauenswürdige Quellen für Ihre Installationen verwenden möchten, müssen Sie ein eigenes Repository einrichten. Die Möglichkeiten dafür sind in [6] beschrieben und reichen von einer einfachen UNC-Freigabe bis zu kommerziellen Produkten wie Artifactory Pro.
Sie können Pakete aus einem öffentlichen Repository in Ihr eigenes übernehmen ("internalisieren"), wenn Sie der Quelle vertrauen. Die Anleitung dazu ist in der Chocolatey-Dokumentation enthalten. Je nach Edition stehen Ihnen hierfür verschiedene Hilfsmittel zur Verfügung, aber auch die Community-Edition unterstützt das manuelle Internalisieren von Packages, die aus externen Repositories stammen. Ebenso unterstützen alle Editionen von Chocolatey das gleichzeitige Ansprechen mehrerer Repositories. Sie können also eine komplexere Repository-Landschaft aufbauen, beispielsweise indem einzelne Abteilungen ihre eigenen Repositories pflegen, und diese der gesamten Organisation zur Verfügung stellen.
Für Anspruchsvolle: Lizenzierte Chocolatey-Editionen
Die Community-Edition von Chocolatey beinhaltet bereits alles Notwendige, um Pakete auf Windows-Systemen zu installieren und aktuell zu halten. Doch Chocolatey kann noch viel mehr. Die zusätzlichen Funktionen sind in den beiden lizenzpflichtigen Editionen enthalten.
Der große Vorteil der Pro-Edition liegt in der automatischen Synchronisierung der Pakete, die via Chocolatey und mit anderen Mitteln installiert werden. So können Sie bereits vor Einführung von Chocolatey eingerichtete Systeme in die Verwaltung durch Chocolatey aufnehmen. Ferner bringt die Pro-Edition einige zusätzliche PowerShell-Funktionen mit, um die Paketierung weiter zu verbessern. Eine weitere nützliche Funktion der lizenzierten Edition ist die Antimalware-Integration. Hier können Sie zwischen Ihrer bereits installierten Virenschutzsoftware oder einem Upload zu VirusTotal wählen. Es können auch beide Varianten gleichzeitig eingesetzt werden.
Die Königsklasse der Paketverwaltung von Chocolatey ist "Chocolatey for Business" (C4B). Diese beinhaltet neben zahlreichen Features der Installations-Engine einen zentralen Managementserver, mit dem Sie beispielsweise verfolgen können, welche Maschinen ein Paket erfolgreich installiert haben und welche nicht. Die zentrale Managementinfrastruktur können Sie in Ihrem Rechenzentrum oder in Azure installieren, wo Chocolatey sie als vorgefertigten Azure Service anbietet.
Chocolatey und AppLocker
Wie bereits erwähnt, installiert das Chocolatey-Paket die ausführbaren Dateien in "%ProgramData%". Mit den AppLocker-Standardregeln wäre "choco.exe" daher nicht ausführbar, da sich das Programm in einem nicht zugelassenen Pfad befindet. Sie müssen dafür also eine Ausnahme oder eine explizite Erlaubnisregel für Chocolatey in Ihre AppLocker-Konfiguration aufnehmen.
Eine weitere Eigenart von Chocolatey, die Sie im Kontext von AppLocker beachten müssen, ist das sogenannte Shimming. Bei der Installation von Chocolatey wird dessen Installationspfad korrekt in die "%PATH%"-Umgebungsvariable des Systems aufgenommen. Nicht jeder Installer eines Chocolatey-Pakets tut dies. Damit jedes von Chocolatey installierte Programm durch den Aufruf seines Namens zuverlässig gestartet werden kann, erzeugt Chocolatey im eigenen Installationsverzeichnis eine gleichnamige ausführbare Datei, die den Input direkt an das "echte" Programm leitet und den Output aus diesem erhält und an den Aufrufenden zurückgibt. Diese Dateien sind natürlich nicht digital signiert und dem System nicht im Voraus bekannt. Sie werden also vermutlich ebenfalls durch AppLocker blockiert, wenn Sie nicht das gesamte Chocolatey-Verzeichnis zur Ausführung freigegeben haben. Übrigens: Die Shims werden bei der Deinstallation von Paketen nicht entfernt.
Ab Build 1607 an Bord: WinGet
Seit 2021 bietet Microsoft mit WinGet einen eigenen Pack-age-Manager für die Kommandozeile an. Anders als bei Chocolatey ist die Installationsvoraussetzung für dieses Werkzeug die Fähigkeit des Betriebssystems, Apps aus dem Microsoft-Store zu installieren. Deshalb ist WinGet auf Windows 10 erst ab Build 1607 installierbar, Windows Server 2019 und älter bleiben jedoch komplett außen vor. Erst auf Server 2022 lässt sich WinGet theoretisch installieren (dies wurde beispielsweise von Andreas Nick in [7] beschrieben), wird dort jedoch nicht offiziell unterstützt.
Auf den aktuellen Builds von Windows 10 und 11 ist WinGet bereits vorinstalliert. Damit haben Sie Zugriff auf zwei Repositories: "winget" und "msstore". Aus dem zweiten Repository kann WinGet die Apps in der gleichen Manier herunterladen und installieren, wie die grafische Microsoft-Store-App. Das erste Repository beinhaltet diverse Programme, die in unterschiedlichen Formaten vorliegen. Das können MSI-Installer oder MSIX-Pakete sein, fertige Store-Apps oder Skripte.
Ein WinGet-Paket wird durch ein YAML-Manifest repräsentiert, das eine oder mehrere Dateien umfassen kann. Wird ein Paket beispielsweise in mehreren Sprachen angeboten, besteht sein Manifest aus mindestens vier Dateien: "version", "installer", "default locale" und eine "additional locale"-Datei pro unterstützte Sprache. Ein fertiges Manifest können Sie per Pull Request in GitHub an das Community-Repository "microsoft/winget-pkgs" übermitteln. Der Pull Request löst einen Validierungsprozess aus, nach dessen Abschluss Ihr Paket freigegeben wird und durch die WinGet-Instanzen aller mit dem Internet verbundenen Windows-Nutzer gefunden und installiert werden kann. Dieser Prozess unterscheidet sich grundlegend von der Einreichung von Apps im Microsoft-Store, wofür ein dedizierter Entwicklervertrag notwendig ist und deutlich strengere Inhaltsrichtlinien einzuhalten sind.
Die Befehlsstruktur von WinGet weist zunächst eine große Ähnlichkeit zu der von Chocolatey auf. Das überrascht wenig, denn beide Package-Manager orientieren sich an den Linux-Vorbildern und streben an, Umsteigern aus der Linux-Administration eine möglichst gewohnte Benutzererfahrung zu bieten. Über den Grundfunktionsumfang hinaus unterscheiden sich die Funktionen von WinGet und Chocolatey allerdings erheblich, was sich auch im Befehlssatz leicht erkennen lässt.
Private Repositories betreiben
WinGet verfolgt (wie bereits AppGet) eine andere Philosophie als Chocolatey, was die Verteilung der binären Installationsquellen angeht. Während ein Chocolatey-Paket stets die Installationsdateien beinhaltet, ist das Artefakt in einem WinGet-Repository meistens nur ein Manifest, das den Downloadpfad für die Installationsquellen sowie die Anweisungen für die Installation beinhaltet.
Microsoft bietet eine Anleitung und Beispielcode [8], mit dem Sie ein privates WinGet-Repository in Form einer Azure-Ressource erzeugen können. Die so erzeugte REST-API ist dokumentiert und kann auch auf einem On-Premises-Webserver implementiert werden. Es existieren einige Community-Projekte, die dies ermöglichen, doch bisher hat es keines zur Produktionsreife geschafft. Wollen Sie also ein privates Repository für WinGet bereitstellen, ist Azure im Augenblick Ihre beste Wahl.
PowerShell-Unterstützung
So schön die "alte" Kommandozeile in Windows auch ist, erwarten inzwischen viele Windows-Admins, das System ihrer Wahl auch über die PowerShell bedienen zu können. Wie groß das Interesse an dieser Funktionalität in der Chocolatey-Nutzergemeinde ist, zeigt der Erfolg von "Foil" [9]. Dieses Modul von Ethan Bergstrom ist ein Wrapper für das choco-Kommandozeilenprogramm, der mithilfe der "Crescendo"-Technologie von Microsoft erzeugt wurde. Obwohl das Modul vom Autor zum Zeitpunkt der Entstehung dieses Artikels noch als "Version 0.1.0" eingestuft wird, ist diese Version seit ihrer Veröffentlichung im September 2021 fast fünf Millionen Mal heruntergeladen worden.
Eine weitere Kategorie von PowerShell-Artefakten, die sich einer großen Beliebtheit erfreuen, sind Chcolatey-basierende DSC-Ressourcen. Diese erlauben Administratoren, sowohl ihre Chocolatey-Installation als auch die mittels Chocolatey installierten Pakete verbindlich aktuell zu halten. Hier gibt es sowohl offizielle Ressourcen von Chocolatey selbst als auch Community-Entwicklungen, die sechsstellige Download-Zahlen aufweisen.
In seinem Inneren ist Chocolatey noch viel stärker mit der PowerShell verwoben, bieten PowerShell-Befehle doch die Grundlage für die Installation von Chocolatey-Paketen. Und auch für das Erstellen von Paketen existiert eine große Fülle von PowerShell-Modulen und -Skripten.
Deutlich schwächer ausgeprägt ist die PowerShell-Unterstützung für das Verwalten von Paketen mit WinGet, obgleich es sich dabei um ein Microsoft-Produkt handelt. Die höchsten Downloadzahlen in der PowerShell-Gallery weisen bisher zwei Projekte auf, die ebenfalls aus der Feder von Ethan Bergstrom stammen – der Crescendo-Wrapper "Cobalt" und das darauf basierende Modul "WinGet".
Dass bisher keine DSC-Ressourcen vorgelegt wurden, könnte daran liegen, dass WinGet faktisch Clients vorbehalten ist, während in der Regel Server per DSC konfiguriert und verwaltet werden. Und auch für das Erstellen von WinGet-Manifesten bietet Microsoft bisher nur ein Kommandozeilen-Tool "winget-create" [10], nicht jedoch ein PowerShell-Modul an.
Link-Codes
[1] Chocolatey: https://chocolatey.org/
[2] Scoop: https://scoop.sh/
[3] Ankündigung von AppGet: https://keivan.io/appget-what-chocolatey-wasnt/
[4] WinGet in Docs: https://docs.microsoft.com/de-DE/windows/package-manager/
[5] Microsoft über WinGet und AppGet: https://devblogs.microsoft.com/commandline/winget-install-learning/
[6] Eigene Repositories für Chocolatey: https://docs.chocolatey.org/en-us/features/host-packages/
[7] WinGet auf Server 2022: https://www.andreasnick.com/112-install-winget-and-appinstaller-on-windows-server-2022.html/
[8] Microsoft: Private WinGet-Ressource: https://github.com/microsoft/winget-cli-restsource/
[9] GitHub-Repository von Foil: https://github.com/ethanbergstrom/Foil
[10] Winget-Create: https://github.com/microsoft/winget-create/
Fazit
Wenn Sie ein vollwertiges Paketmanagement unter Windows etablieren möchten, haben Sie heutzutage de facto die Wahl zwischen Chocolatey und dem Microsoft-eigenen WinGet. Falls Sie den Anwendungspark auf Ihren Servern verwalten möchten, sind Sie mit Chocolatey deutlich besser bedient, benötigen jedoch ein eigenes Repository und ein Verfahren zur Qualitätssicherung der Pakete. WinGet hingegen wird Ihren Clients Zugriff auf von Microsoft geprüfte Repositories eröffnen und kann bei Bedarf auch ein privates Repository ansprechen, das Sie allerdings mit erheblichem Aufwand selbst bauen müssen. Falls Sie den Lifecycle der Pakete über Ihre gesamte Infrastruktur hinweg verfolgen möchten, ist "Chocolatey for Business" die beste Wahl.
(dr)