This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Packageboot and post-reboot actions?

The context:

My environment uses Bitlocker to protect the data on our laptops. If any changes are made to the boot process while Bitlocker is active, then a key must be entered before the drive can be decrypted and booted. We don't want our users to ever encounter this prompt for a key, but we would like to update the BIOS on their laptops. The solution is to temporarily suspend Bitlocker before a BIOS update is applied and then resume after the machine has rebooted. Suspending/resuming bitlocker is a simple command that can be called within packageboot. I have tested this part, and can verify that the suspend/resume (disable/enable) get run successfully if I wrap them in Preexecution and Postexecution blocks in the xml file.

The problem comes into play when the update requires a reboot. The post-execution in Packageboot never gets called. In my tests I have used the following:

Touch.exe - a simple program that takes 1 parameter and creates it if it doesn't exist, overwriting it if it does.

Exit3010.exe - returns a 3010 exit code, which indicates a success, but with a required reboot.

manage-bde - a Microsoft program that manages the Bitlocker state. -protectors -disable c: turns off monitoring, -protectors -enable c: turns them back on.

packageboot.xml:

<?xml version="1.0" encoding="utf-8"?>

<packageboot version="1.0.0.0" id="dd53b76e-babc-410f-8901-426d0989f5f1">

  <instructions>

    <preexecution>

      <programs>

        <program type="exe" typeaction="runandwait" name="manage-bde.exe" pathtype="simplepath" path="%SYSTEM%" successcode="0" failureaction="stop" enabled="true">-protectors -disable c:</program>

        <program type="exe" typeaction="runandwait" name="touch.exe" successcode="0" failureaction="stop" enabled="true">c:\data\reboot.flag</program>

      </programs>

    </preexecution>

    <execution>

      <programs>

        <program type="exe" typeaction="runandwait" name="exit3010.exe" successcode="0" failureaction="continue" enabled="true">

        </program>

      </programs>

    </execution>

    <postexecution>

      <programs>

        <program type="exe" typeaction="runandwait" name="touch.exe" successcode="0" failureaction="stop" enabled="true">c:\data\hit-post-exec.flag</program>

        <program type="exe" typeaction="runandwait" name="manage-bde.exe" pathtype="simplepath" path="%SYSTEM%" successcode="0" failureaction="stop" enabled="true">-protectors -enable c:</program>

        <program type="exe" typeaction="runandwait" name="touch.exe" successcode="0" failureaction="stop" enabled="true">c:\data\end-post-exec.flag</program>

      </programs>

    </postexecution>

  </instructions>

</packageboot>

When I deliver this via WSUS, I get all the touched flag files before a reboot happens. This means Bitlocker gets turned off, but turned back on before a reboot occurs. Is there anyway to tell Packageboot to run the post-execution steps after a reboot?

If not, my plan is to create another update that triggers on the updated BIOS version and turns Bitlocker back on, but this seems kludgey and would tell users they have another update to install after they've already rebooted. I'd like to avoid that.

Does anyone see a more elegant solution?

Message was edited by: Robert Miller - formatted a but for readability

  • I haven't run into anything in my environment that requires a post-reboot task and I don't think it is possibly directly with package boot. You could however try creating a run once entry in the registry to trigger your task after the update installs and have the update require a reboot.

  • The trick is that I need to have Administrator rights to turn Bitlocker back on, in my case. a RunOnce entry in Vista/Win7 only runs when an administrator logs in, which is rarely the case for my user's computers, so I can't rely on that to enable my data security.

    It looks like in my case, I can write a flag registry entry or file that prompts another 'update' to turn Bitlocker back on, but that is the only option I see for running an elevated action after a reboot using Patch Manager.

  • If you need to run an elevated command, you can use a "runas" program such as Runas Password.  Use that program to execute commands and batch files as another user (you can specify an Administrator account).  Put that in your login script and have the batch file execute with elevated security.  The batch file can check the BIOS level and whether BitLocker is disabled, then have it re-enabled if required.

    Runas Password allows you to create an encrypted file that stores the admin user account, password and command to run.  I use this program heavily to perform commands requiring admin access.  It does not require installation, so you can put it on a network share and call it from a login script.

  • PsExec is a great alternative to runas that doesn't require pre-storing credentials on the end host. However, it's not included with Windows so it would need to be distributed to the end hosts using Patch Manager or other methods.

  • RunAsSpc (RunAs Password) doesn't require that you store credentials either, but it's certainly safer having credentials embedded in an encrypted file rather than having an admin account's credentials in cleartext in a batch file or login script.