Anpassade handlingsskript

<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″">

Windows uppgraderade anpassade åtgärdskript

Med Custom Action Scripts kan du köra ytterligare kommandon under installationsprogrammet i Windows. Microsoft gav dig i princip möjligheten att injicera dina egna kommandon i installationsprocessen. Windows 10 Setup -motorn har flera krokar på olika punkter som når ut, kontrollerar specifika platser och ringer skript om de finns. Microsoft har dokumenterat dem ganska bra nedan, men avsikten med det här inlägget kommer att vara att gå lite djupare, visa dem i handling, visa hur du kan skapa dem och sedan visa loggarna när de blir uppringda.

MS Docs

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-setup-enable-custom-actions

Om du använder inbyggda Windows -uppgraderingsfunktioner, "Funktionsuppdateringar" och inte utnyttjar en uppgiftssekvens för att göra dina anpassningar, behöver du andra metoder för att utlösa åtgärder, som att inaktivera tjänster eller säkerhetsprodukter under dina uppgraderingar. Det betyder att du måste förstadiera filerna i förväg och utnyttja en uppgiftssekvens eller ett paket, så att när uppgraderingen går kommer dessa filer att finnas där installationsmotorn kan utnyttja.

Typiska skäl för att använda anpassade åtgärdskript

  • Inaktivera tjänster eller AV innan du startar Downlevel Stage
  • Utlöser en tredjepartskryptering före bypass
  • Fixa vissa program efter uppgradering
    • För oss hade vi flera appar som krävde att filer registrerades om eller körde reparationsmetoden på MSI-installationsprogrammet.
    • När detta händer föreslår jag också att du arbetar med dessa leverantörer för att få dem att uppdatera sina appar för att överleva en uppgradering, eller leta efter en annan programvara.
  • Tillämpa några anpassningar
    • Låsskärm, bakgrundsbilder, användarprofilbilder etc.
  • Kör Setup Diag
  • Kopiera loggar
  • Återställ CM -klienten efter en rollback eller OSUninstall (när du använder en uppgiftssekvens för att uppgradera)

Vid denna tidpunkt antar jag att du läser MS Docs och känner till grunderna:

  • Namn av skriptfilerna (och tillhörande felkoder vid fel)

    • preinstall.cmd | 0XC19001e2
    • precommit.cmd | 0XC19001e3
    • postuninstall.cmd |
    • failure.cmd | 0XC19001e4
    • success.cmd |
  • Platser var filerna ska placeras

    • %windir%System32updaterun
      • Dessa skript kommer att fortsätta från uppgradering till uppgradering (permanent)
    • %windir%System32updaterunonce
      • Dessa skript kommer att tas bort efter uppgraderingen (tillfälligt)

I det här inlägget kommer vi att skapa var och en av dessa filer och gå igenom Windows Setup med hjälp av dem.

<div class="”TIP" alert alert-tip”><h5>DRICKS</h5><p><p>Medan Scripts Windows Setup -samtal är enkla batchfiler kan du använda dessa batchfiler för att anropa mer komplexa PowerShell -script</p>
</p></div>

Exempel

I det här exemplet har jag en "applikation" i CM som kör ett powershell-skript som skapar anpassade åtgärdskript eller kopierar färdiga skript på plats för att användas i Feature Update-processen.

Skript på högsta nivå kallas: "CreateCustomActionScripts.ps1", det kommer att generera ett av vart och ett av skripten i både en kör- och runonce -mapp, som märker registret med en tidsstämpel när skriptet körs. Detta hjälper dig att förstå när skripten körs. Skriptet kommer också att kontrollera innehållet i den mapp det finns i, och om det hittar ett skript kopieras det till rätt plats.

Applikationens innehåll

CustomActionScripts 02

Resultat av installationen av anpassade åtgärdskript

Programmet märker registret med en version av skriptet, skapar anpassade åtgärdskript, skapar anpassningsfiler i ProgramDataWaaS och loggar allt
CustomActionScripts 03
CustomActionScripts 03a

Skript för programinnehåll finns på GitHub

Demo

Grundläggande demo som visar loggar

SetupAct.log = C: windowsPanthersetupact.log (Post Upgrade Location)
Förinstallationsskriptet kördes tidigt i processen innan installationsmotorn gjorde mycket.
CustomActionScripts 04
Maskinen avslutar arbetet i fasen, tog cirka 20 minuter på min virtuella dator, sedan pausar den och väntar på att slutanvändaren ska godkänna omstarten.
CustomActionScripts 07
CustomActionScripts 01
När omstarten har godkänts körs förkommandoskriptet innan maskinen faktiskt startas om. Från dessa loggar kan du se att från det ögonblick jag klickade på Starta om var det 39 sekunder, under vilken tid det finns mycket logg.
CustomActionScripts 05
CustomActionScripts 06

För närvarande ser vi inte mycket för de anpassade åtgärdskripten förrän i slutet, varken framgång eller misslyckande.

CustomActionScripts 08

Så det är ett enkelt exempel som visar när de körs och hur de dyker upp i setupact.loggen

För nästa demo, låt oss sparka upp ett meddelande och få skripten att göra något mer än att skriva till registret.

PreCommit -kontroller - Skapa ett fel

I den här demon kommer jag att skapa en kontroll före flygningen som kommer att göra fel i uppgraderingen om den matchar en regel vi skapar i förinstallationsskriptet.
Här visas Software Center som visar resultaten av funktionsuppdateringen och felkoden. 0xC19001E2 avser ett problem med preinstall.cmd

CustomActionScripts 09

Loggen visar att det körde förinstallationsskriptet och fick en utgångskod på 253, vilket är utgångskoden som mitt anpassade skript skapar när den upptäcker ett program som inte uppfyller de krav jag har ställt. Eftersom förinstallationsskriptet returnerar en kod som inte är noll, berättar det för installationsmotorn att det var ett problem och installationsmotorn börjar misslyckas med uppgraderingen innan den verkligen startade.
CustomActionScripts 10
Eftersom uppgraderingen misslyckas kallar det mitt anpassade fail.cmd -skript, som jag för närvarande inte har gjort något annat än att skriva en registerpost för att bekräfta att den kördes när den sa att den gjorde det, vilket matchar perfekt med setupact.log .
CustomActionScripts 11
CustomActionScripts 13
Dessutom, en annan stor funktion i Windows 10 20H2, det utlöser automatiskt SetupDiag när ett fel inträffar. Det fångar till XML och till registret. Här är en sammanfattning av registret.
CustomActionScripts 12
Mer information om SetupDiag och hur den fungerar och vad den fångar finns i Dokument

Information om framgångsskript och utnyttjande av anpassningar

Denna demo kommer att utnyttja success.cmd -filen, inget för snyggt, men ett bra exempel på vad som kan göras.
Precis som med de andra anpassade action -skripten kommer jag att få success.cmd att utlösa ett powershell -skript som kommer att göra det tunga. Jag har också det göra ett par andra saker.

<div class="”NOTE" alert alert-note”><h5>NOTERA</h5><p><p>Filen Success.cmd körs inte från den plats du placerade den (C:WindowsSystem32Update), installationsmotorn gör en kopia i C:WindowsSetupScriptsupdate, vilket är anledningen till att den körs där.</p>
</p></div>

CustomActionScripts 18
CustomActionScripts 17

Här är de anpassade åtgärdskripten och innehållet i filen success.cmd. Jag använder ett "program" för att utlösa ett skript för att lägga till filerna på rätt platser.
CustomActionScripts 14

Success.cmd ställer in vissa behörigheter att konfigurera ersättning av låsskärm och bakgrundsbilder och kallar sedan två olika powershell -skript.

I skripten ställer vi in några registervärden, byter ut låsskärmsbilden och bakgrundsbilder och kör setupdiag.exe för skojs skull för att få några mätvärden.

Jag har mina skript skriva till en anpassad logg (c: ProgramDataWaaSCustomActions.log) så jag vet exakt när mina skript kördes och vad de gjorde. Varje skript använder ett annat "komponent" -namn för att kunna hålla reda på vilket skript som skriver till loggfilen.
CustomActionScripts 15

Success.cmd -filen jag har, utlöser två olika powershell -filer, Success.ps1 och SuccessSetupDiag.ps1, som båda skriver till den loggen med olika "komponent" -namn.

  • SuccessSetupDiag.ps1 (Utlöst av Success.cmd, men övervakas inte, Success.cmd fortsätter)

    • Övervakar skapandet av windows.old, en gång skapat, utlöser SetupDiag.exe för att samla in resultat och lägger till dem i registret: HKLMSOFTWAREWAAS%BUILDNUMBER%
  • Framgång. Ps1 (Utlöst av Success.cmd och Success.cmd väntar på returkod)

    • Ändrar registervärden för att anpassa användarupplevelse
    • Kopierar låsskärmsbild från iscensatt område (ProgramDataWaaS) till Windows -plats
    • Kopierar bakgrundsbild från iscensatt område till Windows -plats
    • Kopierar användarprofilbilderna (standard företagslogotyp) från iscensatt område till Windows -plats
    • Eventuella ytterligare anpassningar jag skulle vilja göra, skulle jag lägga till här

Loggen ovan visar utdata från de två skript som körs.
Resultaten i registret efter en framgångsrik uppgradering. Varje skript som kördes har jag taggat registret för att säkerställa att det kördes, och vid det tillfället som det kördes.
CustomActionScripts 19
SetupDiag -resultaten:
CustomActionScripts 20

Efter uppgraderingen, som förväntat, har "Kör" -mappen migrerats till det nya operativsystemet som ska användas för nästa funktionsuppdatering och "RunOnce" -mappen är borta
CustomActionScripts 16

Diagram

CustomActionScripts 21

  • Förinstallera sprang efter att ha laddat ner DU: erna, vilket tog 10 till 15 minuter på mina virtuella datorer, om du inaktiverar dynamiska uppdateringar kommer PreInstall att köras mycket snabbt efter att uppgraderingen startat.
  • Förbindelse sprang strax efter att jag klickade på "Starta om". I grund och botten gick Feature Upgrade genom den inledande fasen, kom till en punkt där det meddelar (eller begär) användaren om en omstart, sedan en gång godkänd, eller fortsätter automatiskt, den slutliga fasen i fasen, inklusive PreCommit.
  • Framgång sprang nästan i slutet av hela processen. Det var bara ett par minuter mellan tiden den körde och den tid som jag presenterades med skrivbordets inloggningsskärm.

PostUninstall.cmd

Detta körs när en användare utnyttjar "gå tillbaka"-funktionen. Det kommer att finnas flera överlappande objekt mellan en" Avinstallera "och en" återställning ", loggar kommer att vara på samma plats, och det är faktiskt samma loggfil för båda. Men systemet är smart nog att veta skillnaden och kör antingen failure.cmd eller PostUninstall.cmd

Loggarna finns här: $WINDOWS. ~ BTSourcesRollback

I början av loggen visar den Initiating rollback/uninstall, för att bekräfta att du är på rätt plats.
CustomActionScripts 22

Mot slutet visar det att den körde PostUninstall.cmd -filen.
CustomActionScripts 23

Håll ögonen öppna

  • Det här inlägget är ännu inte klart, har fortfarande planer på att lägga till information om failure.cmd och postuninstall.cmd med demos.

Referenser

Community Blog Links

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:

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