Registry Values used in WaaS Process for reporting

During the WaaS Process, there are several keys and values that are written to the registry, most are used for reporting and a few are used for scripts to pull info from.  Here is a subset of the keys used.  This will be a typical setup of a computer that ran through the process from start to finish with no issues.
image

I’ll try to update this Post with additional example of the various scenarios as I get time.

Different Parts of the WaaS Process that write values include

  1. Pre-Cache / CompatScan
  2. PreFlight
  3. IPU
  4. Rollback
  5. OSUninstall

Other Keys & Values used but not for reporting.. just for scripts to reference.

Most keys will live in (HKLM\SOFTWARE\WaaS\Build#), however some keys not used for reporting, but for the process to use as triggers & waypoints, are located in other locations.  I tried to note those below.  I’d highly recommend after you run each process, that you look at the registry to see what is going on.  If you want to change any of the locations or names, you’ll need to update the scripts.  Please look through the scripts before you run them, there are defiantly scripts that should be updated for your environment, or you might find some things unexpected after.

So here’s the break down of possible keys / values (More Details in the scripts that create them)

  1. Pre-Cache / CompatScan – Created by TS Steps & InventoryCompatScanResults in the OSD TS Scripts & Tools Package, subfolder InventoryTSData
    1. InventoryCompatScanResults.ps1
      1. CompatScanAttempts – How many times the PreCache CompatScan TS Ran
      2. CompatScanDownloadTime – How long it took to download drivers
      3. CompatScanLastRun – Date / Time of when TS ran
      4. CompatScanReturnCode – Return code of the Compat Scan
      5. CompatScanReturnStatus – Friendly Name of the Return Code
      6. CompatScanRunTime – How long the TS took to run
      7. WaaS_Stage (Options)
        1. Ready_for_Scheduling
        2. Precache_Compat_Scan_Failure
    2. TS Steps:
      1. CompatScanHardBlock – Records Hard Block from Panther Folder
      2. CompatScanVPN – Records if TS was running while on VPN – This is very environment specific, so you’ll need to change this step or remove it.
  2. Pre-Flight (Both Script and TS Steps, depends on situation, they do overlap)
    1. PreFlight-Results.ps1 Script in PreFlight Subfolder
      1. PreFlightAttempts – How many time PreFlight Ran
      2. PreFlightLastRun – Date / Time of when PreFlight ran
      3. PreFlightVersion – Captures the Baseline Version of the PreAssessment Baseline
      4. PreFlightReturnCode – HardBlocker or SoftBlocker or “0”
      5. PreFlightReturnStatus – Compliant or Non_Complaint
    2. TS Steps
      1. PreFlightReturnCode – Softblocker or 0 – Runs if Execution Rules Retry
      2. PreFlightReturnStatus – NonComplaint or Compliant -  Runs if Execution Rules Retry
      3. IPURebootPending – Records if it finds there is a Pending Reboot
  3. In Place Upgrade – Both Scripts & TS Steps
    1. InventoryIPUStartTimeInfo.ps1
      1. IPULastRun – Date / Time of when the IPU TS last Ran
      2. IPUExecutionTypeUser – Did a user trigger it from Software Center?
      3. IPUUserLoggedOn – Was a User logged on?
      4. IPUDeploymentID – Self Explanatory
      5. IPUPackageID – Yeah, this too..
      6. IPUAttempts – How many times has the TS ran?
      7. IPUUserAccount - User that was logged on (Console)
      8. IPUPendingReboot – Is the computer pending a reboot?
      9. WaaS_Stage: Deployment_Started
    2. InventoryIPUFinishTimeResults.ps1
      1. IPUReturnStatus – Records the Friendly name of the Return Code
      2. IPUReturnCode – Records the Return from the Setup Engine
      3. IPURuntime – Overall Time it took to run the entire TS
      4. IPUSetuptime – The Time it took for the Setup Step to run
      5. IPUBuild – Records the Build # of the WIM XXXXX.XXX
      6. IPUFailedAttempts – Captures how many times the process failed.
      7. IPUFailedStepReturnCode – If Failed, records the failed return code
      8. IPUFailedStepName – If Failed, it records the Step Name that it failed on
      9. WaaS_Stage
        1. Deployment_Success
        2. Deployment_Error
    3. TS Steps
      1. IPULastAttemptError – If IPU Ran previously and failed, Main Upgrade TS grabs that information from Registry and places it here to keep for historical reasons
      2. OSUninstall Module – Pre Upgrade
        1. LastOSUpgradeTo (HKLM:\SOFTWARE\WaaS) – Used %SMSTS_BUILD% to determine the OS you’re upgrading to.  Rollback & OSUninstall use this key.
        2. LastOSUpgradeFrom (HKLM:\SOFTWARE\WaaS) – Looks up current Build to determine the OS you’re upgrading from.  Rollback & OSUninstall use this key.
      3. RollBack Module – Pre Upgrade
        1. RollbackTemplate  = “RollBack Template Ran Successfully” – This is recorded by SetupRollBack.cmd if a rollback happens.  We append this into the SetupRollBack.cmd to confirm that it is working.  You should only ever see the RollBackTemplate value if a rollback happens
    4. RollBack
      1. TS Module
        1. RollBackTemplate – See Above
      2. RollBackRecovery.ps1 (Is triggered during a RollBack via Scheduled tasks created in the Rollback PreUpgrade Module
        1. OSRollBackRan (HKLM\SOFTWARE\RollBack) – This key keeps track if the RollBack script has run and what section it last run to pick back up if script is disturbed , will also prevent from rerunning once complete.
        2. RollBackPhase – Captures the Setup Phase where the Upgrade Failed
        3. RollBackLog – Tells folder share location of  where the logs where copied to
        4. WaaS_Stage: Deployment_RollBack
    5. OS Uninstall
      1. TS Module (Pre Upgrade)
        1. LastOSUpgradeTo – See Above
        2. LastOSUpgradeFrom – See Above
      2. OS Uninstall to Previous Build TS
        1. OSUninstall_ExitCode – Gets created if User Cancels or Process Fails
        2. OSUninstall – Sets to the Current build number so it knows what the build number was before it reverts back.  Used in another  script to dynamically report what built it reverted from.  This key is not used for reporting. (HKLM\SOFTWARE\WaaS)
        3. OSUninstall_Date – Date / Time of when it reverted
        4. OSUninstallRan – Used for scripts to know when to run and what section.  This key is not used for reporting. (HKLM\SOFTWARE\WaaS)
      3. OSUninstall_WPF.ps1
        1. OSUninstall_AppIssue – True / False (Did you have an app issue)
        2. OSUninstall_AppName – Name of App from Drop Down
        3. OSUninstall_DeviceIssue – True / False
        4. OSUninstall_DeviceName – Text Box
        5. OSUninstall_EarlierBuild – True / False (Earlier build more stable?)
        6. OSUninstall_AnotherReason – True / False
        7. OSUninstall_TellUsMore – Text Box
        8. OSUninstall_ContactAllowed – True / False
        9. OSUninstall_ContactPerson – Text Box for User Input
        10. OSUninstall_Date – Date \ Time when OS Uninstall Ran
      4. OSUninstall-GetUserName.ps1
        1. OSUninstall_UserAccount – Logged on Console user during Process
      5. OSUninstall-NumberTimes.ps1
        1. OSUninstall_NumberTimes – Records the number of times system reverted

Ok, I think that is all of the registry keys we use during the process.  If you find additional ones that I missed, let me know and I’ll confirm / Deny that we created it. Smile

As you can see, the WaaS 2.0 process has many moving parts and it can be a bit overwhelming how they all fit together.  In a future blog post, I plan to diagram out the Task Sequences, scripts, etc.

More Examples (OSUninstall)
image

GARYTOWN.COM

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.