Fejlfinding af scriptproblemer i PowerShell Universal

Det er nok et af de spørgsmål, der oftest stilles om PowerShell Universal. Hvorfor virker mit script ikke på samme måde i PowerShell Universal, som det gør i en PowerShell-prompt? Indlægget giver noget kontekst og trin, du kan tage, så du lettere kan finde problemer, der kan opstå, når du kører dine scripts på platformen.

PowerShell-versioner

Du skal være opmærksom på, hvilke versioner der er i spil, når du kører scripts i PowerShell Universal. Det er let at vælge forskellige versioner af PowerShell, så sørg for, at du kører scriptet i den version, du forventer.

PowerShell-versionerne står på siden Platform > Environments. Når du opdaterer PowerShell 7, bruger PowerShell Universal automatisk den, der ligger på standardstien. Det er også muligt at installere PowerShell 7-versioner side om side og konfigurere PowerShell Universal til at bruge flere versioner.

Et udbredt problem her er moduler, der ikke fungerer direkte i PowerShell 7. Når det er tilfældet, træder Windows PowerShell Compatibility i kraft. Det ser ud til at virke som forventet, men i baggrunden startes nye Windows PowerShell-processer. Hver runspace, der bruger Windows PowerShell-modulet i PowerShell 7-miljøet, starter en ny proces. Det kan sænke ydeevnen betydeligt.

Integreret miljø

Det integrerede miljø er en version af PowerShell 7 SDK, der er bygget ind i PowerShell Universal. Det ændrer sig ikke, når du opgraderer PowerShell på værtsmaskinen. Det ændrer sig kun, når en ny version af PowerShell Universal opgraderer versionen af PowerShell SDK.

Det integrerede miljø er hurtigt, fordi det ikke kræver, at eksterne processer startes, eller at der kommunikeres over en RPC-kanal. Ulempen ved det integrerede miljø er, at det er et enkelt fejlpunkt for alle scripts, API’er og dashboards, fordi de deler det samme procesrum. Det betyder også, at du kan løbe ind i assembly-konflikter, når du indlæser mange moduler, der bruger de samme .NET-assemblies.

Det er ofte tilfældet for biblioteket Newtonsoft.Json. Scripts, der bruger indbyggede moduler eller slet ingen moduler, er gode kandidater til det integrerede miljø.

Tilladelser og rettigheder

At køre et script som lokal bruger på en maskine kan være vidt forskelligt fra at køre et script i PowerShell Universal, når det hostes som en tjeneste eller i IIS. Du skal vide, hvor dine moduler er installeret, for PowerShell Universal finder dem måske ikke det samme sted.

Hvis du desuden hoster som en tjeneste, og modulet skal interagere med skrivebordet (som Selenium), skal du være ekstra omhyggelig, når du konfigurerer tjenesten.

IIS begrænser programpuljens bruger endnu mere ved at indskrænke de rettigheder, kontoen har under kørslen. Det betyder, at adgang til visse mapper eller rettighedsforhøjelse til en anden brugerkonto kan give problemer, selv om brugeren er administrator. Et eksempel er, at New-WebServiceProxy ikke virker i IIS, fordi cmdlet’en forsøger at skrive C#-filer og kompilere dem fra disken, og programpuljen ikke har den rettighed.

Du kan bruge funktionen Terminal i PowerShell Universal til at undersøge det miljø, du har konfigureret, og se, hvad forskellene er.

Brugerdefinerede hosts

PowerShell Universal har to brugerdefinerede hosts. Den første bruges, når scripts køres som jobs. Den host har funktioner som at vente på feedback og skrive til forskellige streams. Den anden bruges til alle andre handlinger i PowerShell Universal. Den implementerer ingen brugerdefinerede host-funktioner ud over logning.

Hvis du glemmer parametre eller beder brugeren om feedback med noget i retning af Read-Host i en host, der ikke understøtter det, får du fejl. Det er god praksis at undgå den slags interaktion, når du arbejder i PowerShell Universal.

Kortlivet runspace-tilstand

PowerShell Universal bruger runspace-puljer til det meste af funktionaliteten i systemet. Den opretter runspaces, når der er brug for dem, og fjerner dem, når der ikke længere er brug for dem. Efter hver kørsel af en funktion, for eksempel et API- eller dashboard-endpoint, nulstilles runspace-tilstanden.

Det kan påvirke scripts, der bruger PowerShell-funktioner som sessions eller remoting. Du kan ikke bruge sessions på tværs af endpoint-kald, medmindre du aktiverer funktionen vedvarende runspace.

Langvarig proces

PowerShell Universal er designet til at køre i lang tid. Vi rydder op i ressourcer med jævne mellemrum og udskifter runspaces efter et bestemt antal anvendelser eller efter et stykke tid. Nogle PowerShell-moduler er ikke særlig godt designet til den slags kørselsmiljø. De forventer at køre i en PowerShell-proces, der starter et script og derefter afsluttes.

For at omgå problemet kan du køre scripts som jobs i eksterne processer, så alle ressourcer ryddes op, når scriptet er færdigt. Visse moduler som PowerCLI og dbatools har statiske .NET-klasser, der kan bevare tilstand og bruge hukommelse, selv når runspaces er frigivet, og .NET-garbage collection er kørt.

IIS kan levere genbrugsfunktioner, der genstarter PowerShell Universal-processen med intervaller, når bestemte ressourceforbrugsgrænser nås, eller når serveren ikke er i brug.

Hemmelighedsstyring

Implementeringen af hemmelighedsstyring i PowerShell Universal bygger på modulerne Microsoft SecretManagement. Standardinstallationen indeholder kernemodulet sammen med flere vault-moduler.

Alle de vaults, der følger med som standard, implementerer brugerspecifikke lagringsmekanismer. Hvis du skifter brugerkontoen for PowerShell Universal-tjenesten, kan du ikke længere tilgå hemmelighederne. Det betyder også, at hvis du opretter hemmeligheder i dit lokale miljø som din egen bruger, er det sandsynligt, at PowerShell Universal ikke kan tilgå de hemmeligheder.

Konklusion

Forhåbentlig har indlægget givet noget kontekst, så du lettere kan finde problemer, du måtte have med at køre scripts i PowerShell Universal.

Klar til at bygge? Hent PowerShell Universal.