Le module de compatibilité Windows vous donne accès à une fonctionnalité Windows PowerShell non disponible dans PowerShell Core. Cependant, l'utilisation de cette fonctionnalité nécessitera une certaine attention aux détails.
Lorsque Microsoft a lancé Windows PowerShell en 2006, la version 1.0 comptait 137 cmdlets dans l'installation de base. Chaque version ultérieure jusqu'à la version 5.1 de 2016 a été ajoutée au nombre d'applets de commande, qui se chiffrait par milliers lorsque vous comptiez les add-ons provenant des couches réseau et de stockage de Microsoft, des rôles et fonctionnalités Windows Server, de la galerie PowerShell et d'autres tiers.
La première version de PowerShell Core, 6.0, a connu une réduction significative des fonctionnalités avec un peu plus de 400 applets de commande compatibles, contre environ 1 500 lors de l'installation de base de Windows PowerShell 5.1. Les administrateurs Windows essayant de contourner cette limitation ont constaté qu'ils ne pouvaient pas exécuter la majorité des applets de commande Windows PowerShell en raison des différences sous-jacentes .NET Framework entre Windows PowerShell et PowerShell Core.
Sommaire
Pourquoi certaines applets de commande ne fonctionnent pas dans PowerShell Core
Un module Windows PowerShell s'exécute sous PowerShell Core si l'une des conditions suivantes est remplie:
- C'est un module basé sur un script qui n'utilise pas de commandes qui ne sont pas présentes dans PowerShell Core;
- Il existe un module de base XML de définition CMDlet – tel que NetAdapter – qui utilise le modèle d’information commun pour effectuer ses tâches; ou
- Le module a été compilé pour fonctionner avec. NET Core.
PowerShell Core 6.1 autorise la propriété PSEdition, illustrée à la figure 1, aux modules de ModuleInfoGrouping renvoyés par la commande suivante:
Obtenir le module – ListeDisponible
La figure 1 illustre la propriété PSEdition qui renvoie Core, Desk ou les deux pour les modules PowerShell Core 6 et Windows PowerShell 5.1. La valeur de base signifie que cela fonctionne sur PowerShell Core et la valeur de Desk indique qu'il s'exécute sur Windows PowerShell.
PowerShell Core 6.1 et versions ultérieures ajoutent automatiquement le dossier Module Windows PowerShell – Modules C: WINDOWS system32 Windows PowerShell v1.0 – au chemin modulaire.
En regardant de plus près, la figure 1 présente le module ThreadJob dans PowerShell Core, y compris l'étiquette du bureau. En effet, Get-Module ne teste pas si le module est en cours d'exécution sur PowerShell Core. Il s'appuie sur une entrée du manifeste de module (fichier .psd1).
CompatiblePSEditions = @ ("Core")
CompatiblePSEditions = @ (& # 39; Desktop & # 39;, & # 39; Core & # 39;)
Si l'entrée CompatiblePSEditions n'est pas présente, Get-Module signale l'entrée avec une entrée de bureau.
Une autre particularité est que Get-Module ignorera les modules des dossiers principaux non-PowerShell qui ne signalent pas de PSEdition contenant la valeur Core. La figure 1 montre que le module BitLocker possède une PSEdision Core, Desk, mais que le module BITStransfer ne figure pas dans la liste. Vous devez utiliser le paramètre SkipEditionCheck pour afficher les modules qui ne sont pas compatibles avec PowerShell Core.
Si vous essayez d'importer un module qui n'est pas pris en charge par PowerShell Core, vous obtenez une erreur:
Import-Module-bit transfert
Module d'importation: Module C: WINDOWS system32 Modules Windows PowerShell v1.0 bit transfer transfer transfer.psd1 & # 39; ne prend pas en charge l’édition PowerShell d’aujourd’hui. Les éditions prises en charge sont "Desktop". Utilisez & # 39; Import-Module -ShipEditionCheck & # 39; ignorer la compatibilité de ce module.
Si vous utilisez le paramètre SkipEditionCheck, une autre erreur se produit:
Module d'importation de transfert de bits – ShipEditionCheck
Module d'importation: le chargement du type & # 39; System.Management.Automation.PSSnapIn & # 39; a échoué de la collection & # 39; System.Management.Automation, Version = 6.2.0.0, Culture = neutre, PublicKeyToken = 31bf3856ad364e35 & # 39;.
Si vous souhaitez utiliser PowerShell Core avec un module non compilé, cet écart crée un problème.
Entrez le module de compatibilité Windows
Fin 2018, l'équipe PowerShell a lancé le module de compatibilité Windows pour permettre aux modules Windows PowerShell de fonctionner dans PowerShell Core. Il est un peu ironique qu'une technologie ait été développée à l'origine. Pour Windows, un pack de compatibilité est maintenant nécessaire, mais le travail est fait.
Vous pouvez trouver le module de compatibilité Windows dans la galerie PowerShell. La description du module mérite d’être citée: "Ce module contient des outils de compatibilité qui permettent aux sessions PowerShell Core d’appeler des commandes disponibles uniquement dans Windows PowerShell. Ces outils vous aident à rechercher les modules disponibles, à importer les modules par le biais de mandataires et à utiliser le module autant que nécessaire. ils étaient natifs de PowerShell Core. "
Le module crée une session de télévision PowerShell à partir de la session PowerShell Core vers un point de terminaison point distant Windows PowerShell. Vous pouvez ensuite importer des modules pour la session de télévision. Cela crée des fonctions de proxy pour les cmdlets que vous pouvez appeler localement dans la session PowerShell Core, qui utiliseront la cmdlet Windows PowerShell via le point distant. Il s’agit effectivement d’une suppression implicite de PowerShell Core vers Windows PowerShell avec certaines commandes vous permettant de gérer votre session.
Installer le module de compatibilité Windows
Vous installez le module de compatibilité Windows directement à partir de la galerie PowerShell.
Nom du module d'installation WindowsCompatibility
Vous verrez un message indiquant que la galerie est incertaine – c'est une galerie publique, donc c'est correct – comme le montre la figure 2.
Répondez O à la requête et l'installation se poursuivra.
Lors de l'utilisation du paramètre Scope avec le module Installer, les règles suivantes s'appliquent:
- AllUsers installe le module pour $ env: Program Files PowerShell Modules;
- CurrentUser installe le module sur $ home Documents Modules PowerShell;
- Sans portée définie pour une session PowerShell augmentée, la portée sera standard pour AllUsers. Dans les sessions PowerShell non élevées dans les versions 2.0.0 et supérieures de PowerShellGet, la portée est CurrentUser. Pour les sessions PowerShell non surélevées des versions 1.6.7 et antérieures de PowerShellGet, l'étendue n'est pas définie et le module d'installation échoue.
PowerShell 6.2.0 utilise PowerShellGet 2.1.2 et PowerShell 6.1.3 utilise la version 1.6.7. Vous observerez différents comportements en fonction de la version de PowerShell. Par conséquent, utilisez toujours le paramètre Scope pour dicter l'emplacement du module.
Utilisation du module de compatibilité Windows
Le module de compatibilité Windows contient les fonctionnalités suivantes: Add-WindowsPSModulePath (également un alias tel que Add-WinPSModulePath), Add-WinFunction, Compare-WinModule, Copy-WinModule, Get-WinModule, Import-WinModule, Initialize-WinSession et Invoke-WinCommand.
La cmdlet Add-WindowsPSModulePath ajoute Windows PowerShell PSModulePath à votre PowerShell Core PSModulePath existant.
PowerShell 6.1 et versions ultérieures ajoutent déjà des modules PowerShell standard à PSModulePath. Vous ne devez donc utiliser cette fonctionnalité que si vous avez besoin d'autres éléments du chemin du module Windows PowerShell. Il est préférable d’ajouter des chemins au chemin du module PowerShell Core lorsque vous en avez besoin, plutôt que d’ajouter un complément à tous les chemins Windows PowerShell.
Les commandes du module de compatibilité Windows dépendent de l'activation du contrôle à distance PowerShell, qui utilise le service Windows Remote Management (WinRM). C'est le cas par défaut sous Windows Server 2012 et versions ultérieures, mais pas sous les versions client de Windows ou les versions antérieures de Windows Server. Si le contrôle à distance n'est pas activé, un message s'affichera:
Get-WinModule
New-PSSession: [localhost] La connexion au serveur distant localhost a échoué avec le message d'erreur suivant: Le client ne peut pas se connecter à la destination spécifiée dans la demande.
Pour configurer le contrôle à distance, exécutez Enable-PSRemoting à partir d'une session Windows PowerShell élevée. Vous pouvez avoir un problème, en particulier sur les postes de travail clients, si l’une de vos connexions réseau a une catégorie de réseau public. Vérifiez auprès de Get-NetConnectionProfile et définissez-le comme privé avec Set-NetConnectionProfile.
Get-WinModule renvoie une liste des modules disponibles à partir de la session de compatibilité. La cmdlet renvoie les modules de C: WINDOWS system32 Les modules Windows PowerShell v1.0 et les modules C: Program Files de Windows PowerShell, mais les modules déjà existants dans PowerShell Core, tels que PackageManagement et PowerShellGet, n'apparaissent pas à partir de ces derniers.
La rapidité pèse sur les fonctionnalités étendues
Vous constaterez peut-être que le module Get-WinModule ou certaines des autres fonctionnalités du module de compatibilité Windows vont ralentir à cause du téléviseur. Essayez de comparer Get-Module -ListAvailability sur une session de suppression de Windows PowerShell sur un ordinateur distant.
Une autre raison de cette faiblesse est que Get-WinModule appelle Initialize-WinSession – comme d’autres fonctionnalités du module – pour créer la session de télévision. Cette session est persistante jusqu'à ce que vous la supprimiez ou fermiez PowerShell afin que la création ajoute une surcharge. La session d'accès distant est visible pour les cmdlets PSSession et sera appelée quelque chose comme wincompat-localhost-
Compare-WinModule est un autre moyen d'examiner les modules disponibles via la session de compatibilité. Le message d'aide de la cmdlet indique qu'il "comparera le jeu de modules de cette version de PowerShell à ceux disponibles dans la session de compatibilité".
La figure 3 montre comment Compare-WinModule affiche les modules de la session de compatibilité qui ne sont pas présents dans la session PowerShell Core, même s'il existe une seule différence de version. Faites attention aux résultats de cette applet de commande car les informations peuvent être assez subtiles.
Copy-WinModule ajoute des fonctionnalités de Windows PowerShell à PowerShell Core en copiant des modules de la session de compatibilité pouvant être utilisés directement dans PowerShell Core. Ces modules sont par défaut copiés dans le dossier $ Home / Documents / PowerShell / Modules, mais vous pouvez le remplacer par le paramètre Destination. Si le module existe déjà dans la destination, il n'est pas copié.
Faites attention à utiliser Copy-WinModule. Je préfère quitter le module et y accéder via la session de compatibilité. Si le module fonctionne avec PowerShell Core, vous pouvez y accéder directement dans la session PowerShell Core sans avoir à copier.
Fonctionne avec le module Active Directory
Pour importer le module Windows PowerShell Active Directory dans la session PowerShell Core, utilisez la commande suivante:
Répertoire actif Import-WinModule
Lors de l'examen du module dans la session PowerShell Core, vous trouverez un ensemble de fonctionnalités, une par cmdlet, dans le module:
Get-Command -Module ActiveDirectory
Pour creuser dans les fonctionnalités, entrez cette commande:
Fonction Get-ChildItem-path: Get-ADUser | Liste de format *
La sortie montre que la fonctionnalité est une fonctionnalité de proxy qui effectue une suppression implicite de la session Windows PowerShell. La fonctionnalité de proxy est uniquement disponible dans la session PowerShell Core.
Vous utilisez la fonction proxy de la même manière que la cmdlet illustrée à la figure 4.
La seule chose qui révèle que ce n'est pas l'applet de commande d'origine est la propriété RunSpaceId de l'objet renvoyé.
Bien que ce soit un moyen intelligent d’accéder aux fonctionnalités Windows PowerShell avec PowerShell Core, tenez compte de quelques points. Tout d'abord, en passant par une session de télévision implicite, les objets inertes ou désérialisés sont renvoyés, ce qui peut ne pas poser de problème la plupart du temps, mais doit être noté.
Ensuite, vous ne pouvez pas exécuter les outils de l'interface graphique via la session de contrôle à distance, standard pour toutes les sessions horaires distantes. De plus, comme il utilise WinRM, il ne fonctionne que de Windows à Windows en raison des restrictions actuelles de WinRM sur Mac et Linux. Vous devez également utiliser PowerShell Core 6.1 ou une version ultérieure.
Le module Active Directory de Windows 10 1809, Windows Server 1809 et Windows Server 2019 ou version ultérieure s'exécute directement dans PowerShell Core, mais si vous essayez d'accéder à la propriété ProtectedFromAccidentalDeletion, vous obtenez une erreur. Si vous utilisez le module via le module de compatibilité Windows, il n'y aura pas d'erreur car l'accès se fait via Windows PowerShell.
La dernière commande du module, Invoke-WinCommand, exécute un script sur la session de rejet de compatibilité. Il s’agit bien de la commande Invoke, mais elle est limitée à l’utilisation de la session de compatibilité.
Après vous être connecté à une session Windows PowerShell, exécutez la commande suivante pour renvoyer la version:
Invoke-WinCommand -ScriptBlock {$ PSVersionTable}
Lorsque vous fermez la session PowerShell Core, vous perdez les fonctionnalités de proxy et la session de télévision. Il peut être disponible en tant que session hors ligne.
Commentaires
Laisser un commentaire