PowerShell | Artifact Registry ersetzt PowerShell Gallery

PowerShell-Automatisierung führt Code häufig mit weitreichenden Berechtigungen aus. Trotzdem beziehen viele Administratoren Module weiterhin direkt aus öffentlichen Paketquellen, ohne Herkunft, Abhängigkeiten oder Freigabestatus vor jeder Installation zu prüfen.

Microsoft will diese Vertrauenskette neu ordnen: Eigene PowerShell-Pakete sollen bevorzugt über die Microsoft Artifact Registry, kurz MAR, bereitgestellt werden. Die PowerShell Gallery bleibt erhalten, bekommt für produktive Umgebungen aber eine andere Rolle.

Microsoft hat diese Ausrichtung am 20. Mai 2026 mit der Roadmap für PSResourceGet 1.3 konkretisiert. Aktuell ist Version 1.3.0-preview1 verfügbar. Die stabile Version bleibt zum Stand 18. Juli 2026 bei PSResourceGet 1.2.0.

Die PowerShell Gallery ist ein offenes Community-Repository. Sie bildet weiterhin einen wichtigen Teil des PowerShell-Ökosystems, weil Entwickler dort Module, Skripte und DSC-Ressourcen veröffentlichen können. Dieses offene Modell eignet sich für Suche, Entwicklung und Tests. Für Produktionssysteme fehlt jedoch eine durch das eigene Unternehmen kontrollierte Freigabekette.

Microsoft empfiehlt deshalb eine Trennung zwischen Paketentdeckung und produktiver Nutzung. Administratoren dürfen Pakete weiterhin in der Gallery finden. Vor dem Einsatz im Serverbetrieb, in Automatisierungen oder CI/CD-Pipelines sollen sie geprüft, versioniert und in ein internes Repository übernommen werden. Produktionssysteme beziehen ihre Pakete anschließend nur noch aus dieser kontrollierten Quelle.

Microsoft nennt dafür Azure Artifacts oder eine private Azure Container Registry als mögliche Plattformen. Der offizielle Ablauf sieht eine Prüfung von Herkunft, Signatur, Sicherheitsstatus, Lizenz und Kompatibilität vor. Erst danach wird das Paket in den internen Feed übernommen.

MAR übernimmt innerhalb dieses Modells die Rolle der bevorzugten Quelle für Microsoft-eigene Pakete. Nur Microsoft kann dort offizielle Artefakte veröffentlichen. Damit sinkt das Risiko, ein ähnlich benanntes Paket eines fremden Herausgebers mit einem Microsoft-Modul zu verwechseln.

MAR löst damit ein Herkunftsproblem. Eine interne Prüfung von Versionen, Abhängigkeiten und Änderungen ersetzt die Registry jedoch nicht. Das ursprüngliche Microsoft-Dokument positioniert MAR ausdrücklich als kontrollierte Quelle für Microsoft-eigene Inhalte und die Gallery als Community-Plattform.

PSResourceGet ist der moderne Paketmanager für PowerShell-Module, Skripte und DSC-Ressourcen. Die Preview von Version 1.3 bringt drei Änderungen, die für Administratoren relevant sind:

Das Standard-Repository erhält die URI https://mcr.microsoft.com/, den Status Trusted, die Priorität 40 und den API-Typ ContainerRegistry. Die PowerShell Gallery bleibt mit der Priorität 50 verfügbar. Da kleinere Zahlen bei PSResourceGet eine höhere Priorität besitzen, wird MAR bei einer repositoryübergreifenden Suche zuerst berücksichtigt.

Die Änderung gilt derzeit für eine Vorabversion. Auf produktiven Administrationssystemen solltest du PSResourceGet 1.3.0-preview1 deshalb nicht unkontrolliert verteilen.

Teste zuerst, welche Module über MAR verfügbar sind, ob bestehende Installationsskripte den Repository-Namen fest vorgeben und wie sich die neue Priorisierung auf automatische Installationen auswirkt. Ein Skript, das keine Quelle nennt, kann nach einer Änderung der Prioritäten ein Paket aus einem anderen Repository beziehen als zuvor.

„Microsoft Artifact Registry ersetzt PowerShell Gallery" wäre technisch zu weit gefasst. Microsoft beschreibt die Gallery weiter als Community-Repository für Zusammenarbeit und Paketentdeckung.

Der entscheidende Wechsel betrifft die Vertrauensgrenze: Ein öffentlich auffindbares Paket ist noch kein für den Produktivbetrieb freigegebenes Paket. Microsoft empfiehlt, die PowerShell Gallery nicht als direkte Laufzeitabhängigkeit produktiver Systeme zu verwenden. Pakete sollen stattdessen nach einer Prüfung in einen unternehmenseigenen Feed übernommen werden.

Das wird bei Microsoft 365 besonders sichtbar. Die aktuelle Microsoft-Dokumentation verweist für das Microsoft Teams PowerShell-Modul weiterhin auf die PowerShell Gallery. Du kannst deshalb nicht davon ausgehen, dass jedes Microsoft-Modul bereits als installierbare PSResource in MAR vorliegt. Vor einer Umstellung musst du jedes benötigte Modul mit Find-PSResource gegen das Ziel-Repository prüfen.

Für eine Übergangszeit ist ein gemischtes Modell realistisch. Microsoft-eigene Pakete nutzt du aus MAR, wenn sie dort in einem mit PSResourceGet kompatiblen Format verfügbar sind. Andere Pakete holst du aus der Gallery oder von der jeweiligen Herstellerquelle, prüfst sie und überführst sie anschließend in dein internes Freigabe-Repository.

Die verwendete PowerShell-Version 7.6.3 ist dabei nicht die Ursache. Entscheidend ist die installierte Version von Microsoft.PowerShell.PSResourceGet und die unveränderte URI.

Prüfe zuerst den Modulstand:

Eine aktuelle PowerShell-Version bedeutet nicht automatisch, dass PSResourceGet 1.3.0-preview1 aktiv ist. PSResourceGet wird als eigenständiges Modul versioniert und kann in mehreren Versionen parallel installiert sein.

Möchtest du die Preview in einer Testumgebung installieren, kannst du dafür PSResourceGet selbst verwenden:

Öffne anschließend eine neue PowerShell-Sitzung und prüfe erneut die geladene Modulversion.

Mit PSResourceGet 1.3.0-preview1 registrierst du MAR über den neuen Parametersatz:

Der Schalter legt automatisch folgende Werte fest:

Der Parametersatz -MicrosoftArtifactRegistry wurde erst mit PSResourceGet 1.3.0-preview1 eingeführt.

Falls du PSResourceGet 1.2.0 oder eine ältere Version nutzt, registrierst du MAR mit einem eigenen Repository-Namen und dem API-Typ ContainerRegistry:

Die zusätzliche Angabe -ApiVersion ContainerRegistry ist relevant, weil MAR kein klassischer NuGet-v2-Feed ist. PSResourceGet greift über die Container-Registry-Schnittstelle auf die dort veröffentlichten PowerShell-Pakete zu.

Nach der Registrierung solltest du nicht sofort vorhandene Installationsroutinen umstellen. Prüfe zuerst, ob das benötigte Paket gefunden wird:

Bei einer manuellen Registrierung unter dem Namen MAR lautet der Befehl entsprechend:

Erst wenn die Suche eine passende Version liefert, folgt die Installation:

Bei der manuellen Registrierung verwendest du wieder den Namen MAR:

Microsoft dokumentiert die Installation des Az-PowerShell-Moduls aus MAR bereits offiziell. Die Dokumentation weist jedoch auch auf bekannte Fehler bei einzelnen Az-Modulen hin. Schlägt eine Installation trotz korrekter Registrierung fehl, kann die PowerShell Gallery vorübergehend als Ausweichquelle nötig sein.

Solche Fälle zeigen, warum du einen Repository-Wechsel zuerst in einer Testumgebung und mit festgelegten Modulversionen prüfen solltest. Ein automatisches Update ohne Versionseinschränkung kann sonst eine fehlerhafte oder noch nicht getestete Modulversion auf mehrere Systeme verteilen.

Der praktische Nutzen von MAR liegt nicht allein in einem neuen Installationspfad. Die Registry zwingt dazu, Paketquellen wie einen Teil der Software-Lieferkette zu behandeln.

Ein belastbarer Ablauf beginnt bei der Inventarisierung. Erfasse, welche Systeme Module installieren dürfen, welche Repositories erreichbar sind und welche Skripte Pakete während der Laufzeit nachladen.

Danach definierst du eine Freigabekette. Neue Pakete werden geprüft, auf eine festgelegte Version begrenzt und in ein internes Repository übernommen. Produktionsserver erhalten keinen direkten Zugriff auf PSGallery oder andere öffentliche Paketquellen.

Der von Microsoft beschriebene Ablauf besteht aus vier Phasen:

Damit bleibt ein Deployment reproduzierbar. Gleichzeitig verhinderst du, dass ein Paket während einer Störung der PowerShell Gallery oder nach einer ungeprüften Aktualisierung nicht mehr verfügbar ist.

Für Microsoft-Pakete kann MAR die kontrollierte Eingangsquelle bilden. Für Community-Pakete bleibt die Gallery eine mögliche Fundstelle. Die Freigabeentscheidung liegt trotzdem bei deinem Unternehmen.

Bestehende Automatisierung sollte den Repository-Namen und die Modulversion explizit angeben. Ein einfacher Befehl ohne Repository kann durch geänderte Prioritäten künftig eine andere Quelle verwenden als erwartet:

Für ein reproduzierbares Deployment legst du Quelle und Version fest:

Alternativ kannst du die benötigten Ressourcen in einer PSD1-Datei definieren. Damit dokumentierst du Version, Repository und Freigabestatus direkt neben deiner Automatisierung.

Die Versionsnummer im Beispiel musst du an deine geprüfte und freigegebene Version anpassen.

Microsoft ersetzt die PowerShell Gallery nicht. Das Unternehmen verändert die vorgesehene Nutzung der Paketquellen. MAR soll die bevorzugte Herkunft für Microsoft-eigene PowerShell-Pakete werden. Die Gallery bleibt für Community-Inhalte, Entwicklung und Paketentdeckung bestehen. Für produktive Automatisierung empfiehlt Microsoft einen kontrollierten Weg über ein internes Repository.

PSResourceGet 1.3.0-preview1 setzt dieses Modell technisch um, indem MAR als vertrauenswürdiges Repository mit höherer Priorität registriert wird. Parallelisierung bei Installationen und die DSC-v3-Ressource verbessern den Betrieb in größeren Umgebungen. Da es sich noch um eine Preview handelt und nicht jedes benötigte Modul über MAR verfügbar ist, bleibt ein schrittweiser Übergang sinnvoll.

Der gezeigte Registrierungsfehler hat mit dieser Architekturänderung nichts zu tun. In die PowerShell-Konsole wurde ein formatierter Markdown-Link kopiert. Mit einer reinen HTTPS-Adresse und dem passenden Parametersatz funktioniert die Registrierung.

Vor dem produktiven Einsatz solltest du prüfen, welche PSResourceGet-Version aktiv ist, welche Pakete MAR liefert und ob deine Automatisierung Repository sowie Modulversion fest vorgibt. Der wichtigste Schritt ist nicht die Registrierung eines neuen Feeds. Entscheidend ist eine nachvollziehbare Freigabekette, bei der Produktionssysteme keine ungeprüften Pakete aus öffentlichen Quellen installieren.