Deployment and Imaging Group

Since going to 7.5 we've been having an issue with image deployments occaisonally timing out on the Boot To Production task. By turning on additional logging on the task server we have been able to track this down to the new 'Registration Period' security feature. The default registration period is five minutes. On slower hardware, it often takes longer than five minutes to complete mini-setup after image deployment. What happens when this occurs is that the task server a) stops trying to tickle the production agent to resume running tasks and b) resets the task queue for the machine. This causes no further tasks from your deploy job to run and the job fails 60 minutes later (by default) when the Boot To Production task times out with the error: 'The task timed out on the Task Server while waiting for the agent to pick it up.' The solution to this issue is, of course, to increase the Registration Period on the Boot To task to a more suitable period (we chose 30 minutes).

Personally I would classify this as a bug, since it seems to me that when the task queue is cleared the current task should immediately fail with an error stating the registration period lapsed. This would point people directly toward the cause of the issue rather than making them wonder why their jobs are mysteriously timing out even though they can run new tasks on the machine successfully during the timeout period.

Thanks for this, I have passed it to the team and will have them take a look.

David

Any updates on this?  We saw this a lot when we first implimented SP1, but it has subsided but still see it occationally.  Haven't tried increasing registration time yet so not sure if that is our issue or not right now

We also experience same issue, we change registration time to 60 min, then 15min, it been very consistency.I think there is a bug in this?

It's definitely still an existing bug. Increasing the registration period seems to decrease the frequency with which it occurs but it still happens. Advice in other threads has included updating to the latest hotfix, then deleting your "boot to" tasks and recreating them. We tried that and it didn't seem to change anything.

Happening here as well, we are in 7.6 hf1. Boot to Production fails, we have the registration time out set to 60. looking at the logs

Registration attempt from Host=[KEC221D-E009], MAC=[88-51-FB-56-93-4A], IP=[10.1.100.154], Domain=[WORKGROUP], User=[]allowed by policy 'e93ff016-87b0-41d4-8516-fed918ade1a8'

Processed registration from Host=[KEC221D-E009], MAC=[88-51-FB-56-93-4A], IP=[10.1.100.154], Domain=[WORKGROUP], User=[] with ID 861e6862-6060-404d-9d51-967355f17ac7 updated in registration queue.

Then there is nothing else, as far as successful message of registration. So we have the job jail out to let it continue the process the following tasks. It is frusterating our IT Team where they want to move away from the product and go with SCCM.

Just run a Script Task in place of the Boot To Production task.

all the script need to have in it is :  

wpeutil reboot
exit 0

Since we upgraded from 7.1 -> 7.5 we encountered same issue, but now use the wpeutil reboot command as workaround.

Thanks,

Clay

Great tip, Thanks. Works great,

J

Will the wpeutil command allow the desktop to boot directly to the hard drive if the boot order is set to:

1. NIC with PXE enabled

2. hdd

3. cd/dvd

I have inconsistencies with the "Boot To' task in my imaging job. Seems like the boot to task does not inform NS that is has ran successfully, now move on to he next step in the imaging job.

Found out this morning it does change the boot environment like the 'Boot To' task causes. I need that change because I utilize pxe to image desktops, if the boot environment does not change from pxe to production my desktops will always boot to pxe instead of the disk drive as forced by Boot To Production. FYI, I notice that my task for Boot To PXE never fails, only Boot To Production.

I'm having a similar problem as well, has anyone found a resolution?

I have even tried to use a Script Task in place of the Boot To Production task.

shutdown /r

still doesn't work consistently

I recently found out from Symantec that they are working on the'Boot To' task issue.

I also found out at the same time that Altiris 7.x has not been good with chaining jobs in a single parent job; but Altiris 6.9 did this all the time. I have inconsistent issues with an imaging job where the (1)deploy image task runs, (2)reboot (by script), (3)run an job to update applications (Flash, adobe reader, etc). Number 3 will be inconsistent, half the time it runs as it shoul, other times it sits "Waiting for the Agent to receive the Task".

Guess i need our staff to image computers, then run step 3 manually.

Yeah we see this especially when it does an update config and policies start to come into play, when policies start checking for things while my job is still trying to run tasks the tasks tend to take a back seat and sometimes just sit there and do nothing, eventually causing them to timeout.

One thing I have done is change the timeout on the task to 30 minutes or less by exporting the xml then editing it and importing it back in, and make sure it's in a sub job that is set so that it does not fail the job if a task fails.

I would like to try this out; exporting/editing the .xml file. Could you go into detail of what exactly you are doing and where this .xml file is?