Well, sort of.
Depending on what is happening here in the background, this is not 100% correct.
First off, clearing the SBS Store folder makes no difference to any process at all (other than being able to find files in there more easily). It is historical only, which is why it's 100% safe to clear at any time.
Second, imiging a computer makes no difference to how it responds when in automation, because we're not booting to the production image. It could be a Linux image, Windows image, or simply a big Virus in production, and it makes no difference at all while in automation.
Third, the SBS updates come almost immediately, because they are sent as tasks, so we don't have to wait an hour. The processes involved are not policy based. What IS policy based are updates to WinPE if you have to add drivers or whatever. When you click on a preboot environment and tell it to rebuild, then you have to wait for the PXE server to check in and get the policy update, which by default may take up to an hour. It's actually possibly a bit longer because you also have to wait for the Delta update to run and THEN the PXE server to check in. Or you do it manually.
But again, this is for rebuilding automation environments, which has nothing to do with this. For this, we're talking about SBS files, and those are sent immediately by Task Server.
As for this issue, there are essentially 3 possible reasons a system doesn't boot to production:
- If the task is assigned to the wrong computer. For instance, maybe we THINK the computer is called DougAlways but is really known as MiniNT-5647 in the console. If you assign the task to DougAlways, obviously the MiniNT system is not going to get the task. This is unlikely the scenario here, because the system DOES reboot, but goes the wrong direction.
- "Race to Reboot". This is a scenario in which the computer being rebooted gets instructions to reboot, but the PXE services do NOT get the instructions - fast enough. Literally, this task is actually 2 tasks: one sent to the client, and one sent to the PXE server. If the one sent to the PXE server is slower than the one sent to the client (hence "race"), then the client boots to automation again. A manual reboot once back in WinPE often "resolves" this issue, but not really. It just gets the system back into production, because by the time you manually reboot, the SBS file has arrived and PXE now knows what to do. THIS issue IS resolved in 7.5.
- SBS Replication can cause this. By default, we only send the SBS file with "marching orders" to one SBS server, which may not in fact be the PXE server to which you're rebooting. In this scenario, one PXE server knows what to do, but another does not, and the one that does not happens to be the one to which you're booting. This is ALSO fixed in 7.5. There is a one-off fix for this issue we're working on a KB for.
So, in case anyone else runs into this, please be aware of what is actually happening before you delete the record and hope for perfect results. As an item of note, generally speaking, there's only one reason to delete a record, and that's if you WANT us to treat this as a new computer even though it is not.
Good luck!