One of the things I like to use with Windows 7 sysprep/mini-setup type builds is a post build configuration script called setupcomplete.cmd. This was put in specifically (by MS) to run post build/install script to handle any non-out of the box configurations you may want on the desktops.
The process for using this script is simple. After the last boot in the Windows mini-setup process Windows will check for the existence of %WINDIR%\Setup\Scripts\SetupComplete.cmd. If it's found the script is executed. If not, the installation “continues”, which really means you are a second or two away from seeing the “CTRL-ALT-DEL to begin” screen. Here is the quick MS definition of this on TechNet.
While you can simply turn this CMD into your entire post build script, and have it run all your commands in one place, I generally will use it to call other scripts or executables that I keep in its root directory. This allows me to ‘keep it simple’ for any troubleshooting later on that may not be done by me. In either case, the script is a great place to handle specific configurations for the desktops that MS may have not given you a good way to deal with.
Sounds great? It is, but there are a few limitations with this process.
First off, SetupComplete.cmd will only run one time. You can’t configure it to complete some tasks, reboot the machine and then resume the script. If you need a reboot in your automated post build scripts you will have to setup an auto login for the next reboot and execute the script at a run once location (or via some other process).
The SetupComplete runs under the system authority, so this is NOT an auto login scenario where it will run when autologin takes place or when the first user logs on. This means your script (if it takes a long time to complete) will be running “behind” the ‘CTRL-ALT-DEL to begin’ screen.
So why is the previous issue important? If you are using this in VDI environments and have a setupcomplete.cmd that takes more than 20 or 30 seconds or so to finish, you run into a situation where the View or XDA agents may start and push you into the pool and available before your script completes. It doesn’t happen often, but be aware.
Typical things that the Setupcomplete.cmd is used for?
Calling the slmgr.vbs to activate Windows 7 or reset the CMID in certain cloning scenarios.
If all machines are joined to the default Computers Container in Sysprep/unattend.xml you can use a post config script to MOVE the machine to a different OU (this is sometimes done based on computer name/organizational naming convention)
I have seen some people run a secondary script off the setupcomplete.cmd to configure firewall settings and even add programs. Not sure why you would do this here when it can be done in a GPO (which I favor).
And of course you can use it to delete the unattend.xml answer file or any other files you think need to be “cleaned up” before the users get access to the machine.
SetupComplete is a SIMPLE way to do any post build configs. I would recommend that if you can’t get it done in a GPO or a task needs to be complete before the user logs in the first time, give this a shot.