OSD: Forcing a reboot
In this post I will talk about the method I use to force a reboot at the end of a ZTI task sequence; when running from OSD. This solution was put together with input from Richard Smith a fellow Deployment Guy and also with help from Avanade/Accenture - Chris Bird, Jonathan Goulding, Chris Urwin and Steven Westwell. We developed this to help us enable BitLocker as part of an OSD deployment. I'll post the scripts and steps for doing that a little later. This post covers some of the ground work that made enabling BitLocker possible, there is a whole lot more around drive partitioning - but that is for another post.
So why would we need a special way to force a reboot of a ZTI/OSD build? During the build process any reboots requested by the task sequence or applications, such as BitLocker install, are suppressed. Take a look in the log file of a build and you'll see the occasional entry saying that OSD has suppressed a reboot. You may have other things that you need a reboot for at the end of your build process.
It is important to point out that this forced reboot only occurs at the end of the OSD process. We can not force a reboot during that process and have OSD carry on.
OSD Process Overview
Before we can start writing scripts it is important to cover off what happens when the OSD process runs in a deployed OS. After an OS has been deployed and mini-setup has run the system reboots. On reboot OSD deployment (Zerotouch Installation) starts before the system has reached a logon prompt/the desktop. So OSD never actually logons to the desktop - it all happens prior to the GINA being displayed. Next time you do an OSD build watch it carefully at the end. OSD ends and you are presented with the CTRL+ALT+DEL prompt - this is the first time the OS will have reached this stage.
So knowing this how do we force our reboot? Well we have to logon of course!
The reboot process.
You may want to grab the sample scripts (see the link at the end) to follow through them as I discuss this process.
Forcing the reboot is a two stage process;
- Logon to the desktop
- run a script/cmd to reboot.
I set the system up to auto logon as part of the ZTI task list - this means I can take advantage of BDD environment variables to get the local administrator username and password. The other thing I must think about is am I going to run a script at logon or a command? If I am going to run a script then I need to grab these and place them in a directory structure outside c:\minint. Remember c:\minint gets deleted once OSD completes. The script, z-OSDPart1.wsf does these tasks. Firstly it copies down any scripts we'll need later to c:\OSDTemp. Then SetAutoRun function sets up the autologon keys and configures the runonce key to call the next script, z-OSDPart2.vbs
Once the OSD task sequence completes the system will now autologon and run the z-OSDPart2.vbs script. This second script can be quite simple (as in this example) or more complex. When I post on getting BitLocker working well see an example. So z-OSDPart2 clears out the autologon entries and issues a reboot. Note that when this runs, because it is running as a runonce command, z-OSDPart2 runs before the desktop can fully establish itself. So you will see the logon start to happen and then the machine will restart. This is a bit of a hidden bonus as anyone walking past the machine at this point will not get the chance to access the desktop while it is logged on as administrator - depending on what you have z-OSDPart2 do of course.
So your OSD machine should now have restarted and be back at a logon prompt.
When I post about getting Bitlocker working we'll actually have it logon again and do some more tasks. Remember that once OSD has completed you no longer have access to the scripts and environment variables so any tasks you get it to do must be self contained.
The sample scripts are linked below. Once you have them you will need to drop them into the distribution scripts directory and then update all your deployment point scripts directories (don't forget the ones on your SMS servers as well) so you can use them. Also because z-OSDPart1 referances z-OSDPart2 if you change the name of the second script you will need to change it in the first one as well.
This post was contributed by Richard Trusson a Senior Consultant with Microsoft Services, UK.
