So beheben Sie den PowerShell-Install-Module-Fehler: Download von URI nicht möglich

Wenn Sie also versuchen, Module aus der PowerShell Gallery unter älteren Windows-Systemen (wie Windows 8.1 oder Server 2012 R2) zu installieren, sind Sie wahrscheinlich schon einmal auf die Fehlermeldung „Download von URI nicht möglich“ gestoßen. Das ist gar nicht so selten, da ältere PowerShell-Versionen standardmäßig veraltete Protokolle – SSL 3.0 oder TLS 1.0 – verwenden, die Microsoft für diese Repositories nicht mehr unterstützt. Sie erhalten außerdem Fehlermeldungen, dass NuGet nicht gefunden wurde, und möglicherweise sogar einen TLS-Fehler in der Ereignisanzeige (Ereignis-ID 36874), der auf Probleme mit der Verschlüsselungssuite hinweist. Kurz gesagt: PowerShell versucht, über veraltete Protokolle eine Verbindung herzustellen, und der Server verweigert dies – kein Wunder, dass es nicht reibungslos verläuft.

Um dieses Problem zu umgehen, müssen Sie PowerShell zwingen, TLS 1.2 zu verwenden, den aktuellen Standard. Hier ist eine relativ einfache Anleitung. Wenn Ihre PowerShell-Version recht alt ist (<= 5.1.14xx), aktualisieren Sie sie zuerst, da ältere Versionen diese Schritte möglicherweise nicht korrekt ausführen. Falls Sie dennoch nicht weiterkommen, folgen Sie diesen Schritten – korrekt ausgeführt, verwendet PowerShell TLS 1.2 und Sie können Module problemlos installieren.

So beheben Sie den Fehler „Download von URI nicht möglich“ durch Erzwingen von TLS 1.2

Überprüfen Sie Ihre PowerShell-Version

  • Öffnen Sie PowerShell und führen Sie folgenden Befehl aus:host | select-object Version
  • Wenn Ihre Version älter als 5.1.14xx ist, sollten Sie PowerShell aktualisieren; eine neuere Version ist für diesen Fix definitiv besser.

Die Kenntnis Ihrer Version ist hilfreich, da ältere PowerShell-Versionen standardmäßig SSL 3.0 oder TLS 1.0 verwenden, die als veraltet gelten und von den Microsoft-Repositories blockiert werden.

Überprüfen Sie, welche Protokolle PowerShell verwendet.

  • Laufen:[Net. ServicePointManager]::SecurityProtocol
  • Hier werden Protokolle wie beispielsweise TLS aufgelistet Ssl3, Tls. Wenn Sie TLS oder TLS11 sehen, liegt ein Problem vor.

Bei manchen Konfigurationen sieht man möglicherweise TLS 1.0 oder sogar SSL3, was nicht mehr unterstützt wird. Kein Wunder, dass Verbindungen fehlschlagen.

PowerShell so konfigurieren, dass TLS 1.2 verwendet wird

  • Führen Sie diesen Befehl aus:[Net. ServicePointManager]::SecurityProtocol = [Net. SecurityProtocolType]::Tls12
  • Dies zwingt PowerShell, für alle nachfolgenden HTTPS-Anfragen TLS 1.2 auszuhandeln. Funktioniert in den meisten Konfigurationen einwandfrei.
  • Hinweis: Gelegentlich müssen Sie dies möglicherweise bei jedem Öffnen einer neuen Sitzung ausführen, es sei denn, Sie fügen es Ihrem Profilskript hinzu.

TLS 1.2 als Standard im. NET Framework festlegen (optional, aber empfohlen)

  • Dieser Schritt stellt sicher, dass PowerShell standardmäßig TLS 1.2 für alle. NET-Anwendungen, einschließlich PowerShell selbst, verwendet. Es handelt sich um eine Änderung in der Registrierung.
  • Führen Sie diese Befehle in PowerShell aus (als Administrator):
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
  • Diese Änderungen an den Registrierungsschlüsseln aktivieren starke Kryptografie, einschließlich TLS 1.2, sowohl bei 64-Bit- als auch bei 32-Bit-Installationen des. NET Frameworks.
  • PowerShell neu starten

    • Schließen Sie PowerShell und öffnen Sie es erneut, um die Änderungen anzuwenden.Überprüfen Sie anschließend die Protokolle erneut:[Net. ServicePointManager]::SecurityProtocol
    • Sie sollten ein sehen Tls, Tls11, Tls12, was bedeutet, dass TLS 1.2 aktiviert und einsatzbereit ist.

    Versuchen Sie nun, Ihre Module erneut zu installieren Install-Module -Name ExchangeOnlineManagement -Force -Scope AllUsers. Wenn alles korrekt eingerichtet ist, sollten die Fehler verschwinden und die Module problemlos heruntergeladen werden.

    Ehrlich gesagt ist das Ganze etwas seltsam, da Windows es unnötig kompliziert macht, veraltete Protokolle abzuschaffen. Auf manchen Rechnern ist dafür ein Neustart oder ein erneuter Start von PowerShell nötig, aber sobald die Einstellungen vorgenommen sind, bleiben sie in der Regel erhalten. Im Grunde geht es darum, PowerShell anzuweisen, die alten Protokolle nicht mehr zu verwenden und stattdessen TLS 1.2 zu nutzen, das sicher und unterstützt ist – ganz einfach, oder?

    Zusammenfassung

    • Überprüfen Sie Ihre PowerShell-Version und aktualisieren Sie diese gegebenenfalls.
    • Verwenden Sie diese Funktion [Net. ServicePointManager]::SecurityProtocol, um zu sehen, was aktiv ist.
    • PowerShell zur Verwendung von TLS 1.2 zwingen[Net. ServicePointManager]::SecurityProtocol = [Net. SecurityProtocolType]::Tls12
    • Um zukünftige Probleme zu vermeiden, sollte eine starke Verschlüsselung in der Registry eingerichtet werden.
    • Starten Sie PowerShell neu und versuchen Sie die Modulinstallation erneut.

    Zusammenfassung

    Diese ganze TLS-Sache ist echt nervig, besonders bei älteren Windows-Versionen. Aber sobald die Protokolle richtig konfiguriert sind, sollte die Installation von Modulen aus der PowerShell Gallery kinderleicht sein. Es ist zwar etwas ärgerlich, dass Microsoft diese veralteten Standardeinstellungen verwendet, aber immerhin hast du gelernt, damit umzugehen, ohne dir die Haare zu raufen. Hoffentlich hilft das jemandem, stundenlangen Frust zu vermeiden.