Kör PowerShell Script

<img style="”float:" right;” src="”https://www.recastsoftware.com/wp-content/uploads/2021/10/Recast-Logo-Dark_Horizontal.svg”" alt="&quot;Bild&quot;" height="”43″" width="”150″">

Kör PowerShell Script

Detta steg är nyare och drog mycket tunga lyft från körkommandoradssteget. Tidigare var du tvungen att ringa powershell.exe och sedan en fil eller kommando, nu kan vi direkt ringa ett skript eller bädda in ett skript.

MS Docs

MS Docs: https://docs.microsoft.com/en-us/mem/configmgr/osd/understand/task-sequence-steps#BKMK_RunPowerShellScript

PowerShell:

Viktig filsökväg: c: WindowsTEMPSMSTSPowerShellScripts (se till att detta är uteslutet från dina AV -regler)

Även detta steg dokumenteras mycket bra på dokumentsidan, men jag kommer att fortsätta att ge exempel på hur det används.
Saker att notera, de inbäddade skriptfunktionen, medan det är super trevligt att inte behöva associera ett steg med ett paket, finns det fortfarande goda skäl att INTE bädda in ett manus som storleken på manuset, eller hur det används.

  • Storlek, vanligtvis om manuset blir mycket över 100 rader, bäddar jag inte in. Ju längre skript och fler skript du bäddar in kan få din TS -policy att bli för stor och bryta saker. Kolla in den här informationen om idéer om hur du håller din TS Policy -storlek mindre. Mer information om MS Docs
  • Organisation. Låt oss säga att du använder samma powershell -skript på flera platser i en eller flera uppgiftssekvenser, om du bäddar in skriptet måste du se till att du uppdaterar varje plats, medan om du refererar till ett skript behöver du bara uppdatera det enda skriptet i källan, och alla steg som bygger på den uppdateras nu.
    Det är saker du måste tänka på när du utnyttjar detta kraftfulla steg.

Steginställningar

Paket med PowerShell -skript:

Kör PowerShell Script Image 1

Detta är den grundläggande funktionen i steget när det släpptes första gången, pekar på ett skript i ett paket och du är klar. Eftersom de har lagt till ytterligare alternativ, vilket är bra, men det här är fortfarande en mycket viktig del. Kom ihåg att ställa in PowerShell -körningspolicyn för att kringgå, såvida du inte har signerat den. I exemplet ovan är detta ett steg som jag använder i många uppgiftssekvenser för att samla ytterligare objekt, liknande MDT Gather, men utan att integrera MDT. Mer information om detta exempel hittar du här: https://garytown.com/so-long-mdt-native-cm-for-me
Eftersom jag använder det på flera ställen behåller jag det som ett skript, så eftersom jag behöver uppdatera skriptet för att samla ytterligare objekt uppdaterar det alla mina uppgiftsföljder.

Inbäddat PowerShell -skript:
Kör PowerShell Script Image 2

Att kunna bädda in ett manus är super praktiskt, och jag har gått över till att göra detta när det är vettigt. Jag började gå överbord och fann att det inte var vettigt att bädda in allt, som i exemplet ovan. Det är trevligt att bädda in skript eftersom du inte längre behöver oroa dig för att distribuera innehåll. Säg att du har hittat en bugg i ditt skript, en snabb ändring av skriptet i TS, och du kan testa igen snabbt mot att ändra skriptet i ett paket, uppdatera DP: erna och sedan köra TS igen.

Parametrar:
Kör PowerShell Script Image 3

Om du använder ett skript i ett paket eller om du bäddar in skriptet kan du använda parametrar. Exemplet ovan är ett inbäddat skript som jag använder för att kopiera loggar till en server. Platsen är i en parameter, och jag kan till och med utnyttja uppgiftssekvensvariabler i parametrarna (%SMSTS_Build% & %ComputerName%) för att mata in i skriptet. Du kan se hur kraftfullt detta kan vara, eftersom du sedan kan använda samma skript i olika uppgiftssekvenser för olika ändamål genom att mata in skriptparametrarna.

<div class="”IMPORTANT" alert alert-important”><h5>VIKTIG</h5><p><p>När du använder parametrar, använd inte &quot;dubbla&quot; citattecken, använd &quot;enkla&quot; citattecken, du kommer att få problem. Osäker exakt när det ändrades, men det gjorde det.</p>
</p></div>

PowerShell -körningspolicy:
Kör PowerShell Script Image 4

Jag tar mig inte tid att skriva under mina skript och jag har aldrig blivit uppmanad till det, så jag stör mig inte, jag lägger alltid till det på bypass för att göra mitt liv enkelt. Mer information om MS Docs

Utgång till uppgiftssekvensvariabel:
Kör PowerShell Script Image 5
Oavsett vilken information som returneras från kommandot placeras i variabeln. I exemplet ovan kör jag ett enkelt powershell -kommando (i ett inbäddat skript) som kommer att mata ut systemets språk till en variabel. Jag använder detta i min uppgraderingsuppgiftssekvens för att ta tag i språkpaketinformationen, så att jag kan använda den igen efter uppgraderingen.

Time-out (minuter):
Detta är en skyddsåtgärd för att skydda din aktivitetssekvens från en löpande process. Ibland hänger ett kommando du kör, även med mycket testning, och självklart kommer du att vilja felsöka det och lösa problemet, men på samma gång, om du kör en på plats uppgradering, är steget ganska obetydlig för den övergripande processen, du vill att den ska fortsätta och inte hänga din TS och misslyckas.

Kör detta steg som följande konto:
Uppgiftssekvensen körs som systemkontot, om du får uppgiftsekvensen att nå ut till några nätverkssystem, såvida inte säkerheten är konfigurerad på ett mycket osäkert sätt, kommer uppgiftssekvensen inte att ha behörighet att aktivera dina mål . Du måste ange ett konto som har rätten att göra det du behöver. Se till att du funderar lite på att använda den här funktionen, följ metoden med minst privilegier. I exemplet ovan kör jag ConfigMgr powershell -kommandon och gör filkopior, så kontot jag använder måste ha behörigheter i både CM -konsolen och i filsystemet där jag kopierar filer.
Kör PowerShell Script Image 6

Fliken Alternativ

Kör PowerShell Script Image 7
Framgångskoderna är förbefolkade med 0 (inte med 3010 som kommandoradssteget kör)

Demo

Inbäddat skript i aktion:
Steg: Inbäddat skript: start -sömn -s 15000
Kör PowerShell Script Image 8
När du kör:
Kör PowerShell Script Image 9
När du kör det steget som har ett inbäddat skript bygger det PowerShell -skriptet i c: WindowsTEMPSMSTSPowerShellScripts, som visas i bilden ovan. Observera, jag använde Task Sequence Debugger för att enkelt gå igenom uppgiftssekvensen.

Vanliga misslyckanden

  • Skriptfel
    • Att testa ett skript i en TS är mycket viktigt, eftersom hur ett PowerShell -skript fungerar när du bygger det i din redaktör, jämfört med att köra skriptet i en TS kan vara ganska annorlunda. Du kan lägga mycket försök och fel på att testa skript som bygger på olika TS -varianter.
  • WinPE
    • Som standard stöder inte Windows PE i ConfigMgr PowerShell, du måste lägga till flera valfria komponenter för att stödja dina skript, och baserat på vad du gör behöver du ytterligare saker. Kontrollera Windows PE PowerShell Support -sidan om hur du lägger till krav på din WinPE -startbild för att stödja PowerShell.
  • Paketproblem
    • Se till att du har kallat filerna med rätt namn och sökvägar för att matcha vad som finns i dina paket.
    • Innehållet i paketet uppdaterades inte innan du körde ditt test.

Användbara tips

När jag skapar PowerShell -skript för att använda i en uppgiftssekvens testar och utvecklar jag vanligtvis från en pausad uppgiftssekvensmiljö. Jag pausar en uppgiftssekvens, startar ISE och testar, testar, testar. När jag väl fått utmatningen från det manus jag vill ha kör jag det i Task Sequence -processen och ser vad som händer, men att kunna felsöka ett PowerShell -skript i uppgiftssekvensmiljön kan spara mycket tid.

Mer information

Om Recast Software
1 av 3 organisationer som använder Microsoft Configuration Manager förlitar sig på Right Click Tools för att visa sårbarheter och åtgärda snabbare än någonsin tidigare.
Ladda ner gratis verktyg
Begär pris

Se hur Right Click Tools förändrar hur system hanteras.

Öka produktiviteten direkt med vår begränsade, kostnadsfria Community Edition.

Kom igång med Right Click Tools idag:

Dela detta:

Support

  • Detta fält används för valideringsändamål och ska lämnas oförändrat.

Kontakt

  • Detta fält används för valideringsändamål och ska lämnas oförändrat.

Genom att skicka in detta formulär förstår du att Recast Software kan behandla dina uppgifter enligt beskrivningen i Recast Software Integritetspolicy.

sv_SESwedish