Adam DriscollC’est probablement l’une des questions les plus fréquentes à propos de PowerShell Universal. Pourquoi mon script ne fonctionne-t-il pas de la même façon dans PowerShell Universal qu’à une invite PowerShell? Cet article donne du contexte et des étapes pour identifier les problèmes qui peuvent survenir lorsque vos scripts s’exécutent dans la plateforme.
Versions de PowerShell
Vous devez connaître les versions en jeu lorsque vous exécutez des scripts dans PowerShell Universal. Il est facile de sélectionner différentes versions de PowerShell, alors assurez-vous d’exécuter le script dans la version prévue.
Les versions de PowerShell sont listées dans la page Platform > Environments. Lorsque vous mettez à jour PowerShell 7, PowerShell Universal utilise automatiquement celle qui se trouve au chemin par défaut. Il est aussi possible d’installer des versions de PowerShell 7 côte à côte et de configurer PowerShell Universal pour en utiliser plusieurs.
Un problème courant concerne les modules qui ne fonctionnent pas nativement dans PowerShell 7. Dans ce cas, Windows PowerShell Compatibility entre en action. Tout semble fonctionner comme prévu, mais en arrière-plan, de nouveaux processus Windows PowerShell démarrent. Chaque runspace qui utilise le module Windows PowerShell dans l’environnement PowerShell 7 démarre un nouveau processus. Cela peut réduire considérablement les performances.
Environnement intégré
L’environnement intégré est une version du SDK PowerShell 7 intégrée à PowerShell Universal. Il ne change pas lorsque vous mettez à niveau PowerShell sur la machine hôte. Il ne change que lorsqu’une nouvelle version de PowerShell Universal met à niveau la version du SDK PowerShell.
L’environnement intégré est rapide, car il n’a pas besoin de démarrer des processus externes ni de communiquer via un canal RPC. L’inconvénient, c’est qu’il constitue un point de défaillance unique pour tous les scripts, les API et les tableaux de bord, puisqu’ils partagent le même espace de processus. Vous pouvez aussi rencontrer des conflits d’assemblies lorsque vous chargez de nombreux modules qui utilisent des assemblies .NET communes.
C’est souvent le cas de la bibliothèque Newtonsoft.Json. Les scripts qui utilisent des modules intégrés, ou aucun module, sont d’excellents candidats pour l’environnement intégré.
Autorisations et privilèges
Exécuter un script en tant qu’utilisateur local sur une machine peut être très différent d’exécuter un script dans PowerShell Universal lorsqu’il est hébergé comme service ou dans IIS. Vous devez savoir où vos modules sont installés, car PowerShell Universal peut ne pas les découvrir au même endroit.
De plus, si vous hébergez comme service et que le module doit interagir avec le bureau (comme Selenium), vous devrez porter une attention particulière à la configuration du service.
IIS restreint encore davantage l’utilisateur du pool d’applications en limitant les privilèges du compte à l’exécution. Accéder à certains répertoires ou s’élever vers un autre compte peut donc poser problème, même si l’utilisateur est administrateur. Un exemple: New-WebServiceProxy ne fonctionne pas dans IIS, car la cmdlet tente d’écrire des fichiers C# et de les compiler depuis le disque, et le pool d’applications n’a pas ce privilège.
Vous pouvez utiliser la fonctionnalité Terminal de PowerShell Universal pour examiner l’environnement actuellement configuré et voir les différences.
Hôtes personnalisés
PowerShell Universal a deux hôtes personnalisés. Le premier sert à exécuter des scripts comme tâches. Cet hôte offre des fonctions comme l’attente de rétroaction et l’écriture vers différents flux. Le second sert à toutes les autres opérations dans PowerShell Universal. Il n’implémente aucune fonction d’hôte personnalisé à part la journalisation.
Si vous oubliez des paramètres ou demandez une rétroaction à l’utilisateur, avec quelque chose comme Read-Host, dans un hôte qui ne le prend pas en charge, vous recevrez des erreurs. La bonne pratique est d’éviter ce type d’interaction dans PowerShell Universal.
État des runspaces de courte durée
PowerShell Universal utilise des pools de runspaces pour la plupart des fonctions du système. Il crée des runspaces au besoin et les libère lorsqu’ils ne servent plus. Après chaque exécution d’une fonction, comme une API ou un point de terminaison de tableau de bord, l’état du runspace est réinitialisé.
Cela peut affecter les scripts qui utilisent des fonctions de PowerShell comme les sessions ou le remoting. Vous ne pourrez pas réutiliser des sessions d’un appel de point de terminaison à l’autre, sauf si vous activez la fonction persistent runspace.
Processus de longue durée
PowerShell Universal est conçu pour s’exécuter longtemps. Nous nettoyons périodiquement les ressources et recyclons les runspaces après un nombre d’utilisations ou une durée donnés. Certains modules PowerShell ne sont pas bien conçus pour ce type d’environnement d’exécution. Ils s’attendent à s’exécuter dans un processus PowerShell qui invoque un script puis se termine.
Pour contourner ce problème, vous pouvez exécuter les scripts comme tâches dans des processus externes, afin que toutes les ressources soient nettoyées une fois le script terminé. Certains modules comme PowerCLI et dbatools ont des classes .NET statiques qui peuvent conserver un état et consommer de la mémoire même lorsque les runspaces sont libérés et que le garbage collection .NET s’exécute.
IIS peut recycler le processus PowerShell Universal à intervalles, lorsque certains seuils de ressources sont atteints, ou lorsque le serveur n’est pas utilisé.
Gestion des secrets
L’implémentation de gestion des secrets de PowerShell Universal s’appuie sur les modules Microsoft SecretManagement. L’installation par défaut inclut le module principal ainsi que plusieurs modules de coffre.
Tous les coffres inclus par défaut implémentent des mécanismes de stockage propres à l’utilisateur. Si vous changez le compte de service de PowerShell Universal, vous ne pourrez plus accéder aux secrets. Cela signifie aussi que si vous créez des secrets dans votre environnement local avec votre propre utilisateur, PowerShell Universal ne pourra probablement pas y accéder.
Conclusion
Cet article devrait vous donner du contexte pour identifier les problèmes que vous pouvez rencontrer en exécutant des scripts dans PowerShell Universal.
Prêt à construire? Téléchargez PowerShell Universal.