Does the client reboot afterwards or just sit there?  Generally I've seen this happen for one of two reasons.

1.  If job is looking for a specific Automation agent (i.e.  you are in WinPE and it is looking Linux or DOS).  It will continue to do this until it finds the correct automation agent.

2.  If it checks into the DS and finds that there are no jobs assigned to it, it will disconnect and attempt to reboot into the production OS.

The client just sits there.

You indicated you were using PXE.  What environment are you going into (i.e. Linux, WinPE or DOS)?  I'm assuming that the message you are referring to is coming from the agent in the automation client and not in the installed OS (i.e. Windows XP/Vista).

How many licenses do you have and how many are you using? My guess is that you are out of available licenses, but it also depends on if this is a new computer?

I'm going to go with BHAWVER on this one.  It sounds like the automation job is set to do one thing, but PXE is booting into something else - like PXE is booting to DOS, but the job is configured for WINDOWS (winpe) or something of the sort?

Well if it was because the client has booted into eg. WinPe and the job was to run in WinPE, the client would reboot into the PE.

As a side note, try to create a job that runs the first task in LinuxPE and then without a reboot runs a task in WinPE. that should cause the client to reboot between those two tasks. Automation is simply booting to sometyhing else then production.

Check to see if the computer you are trying to image has an OEM recovery partition on it.  Very often, it will try to launch the agent from the F: drive, but when an OEM partition exists, winpe will see the OEM partition as F.  If you watch the boot progress, once in winpe, you should see something like "The local device name is already in use".  

 I ended up having to reconfigure the express share as Z: in my boot images, to get around the issue, and had no problems after that.  Another option, albeit more lengthy, would be to run a disk wipe job in DOS before booting into winpe.  Something like ./wipe.exe -d1.  This will destroy any existing partitions, and should allow the agent to run from the express share, once you boot back into winpe.

Hope this helps.

See the following article as well:

https://www-secure.symantec.com/connect/forums/create-format-hard-drive-job

These are new laptops, however with the original laptop we imaged the original OEM recovery partition we had wiped out. Concerning questions from others, we are using windows XP pro, vista was to much of a hassle, we went through the Vista headache last summer. I checked and we are not out of licenses. Thanks

I've seen in the past some very odd engine behaviour with PXE booting in some environments, where the computer thinks its a different computer_id in production and automation.

The result is that when you drop the job on the computer in production it shuts down, reboots into automation  (by PXE) and then when it checks in with the server it suddenly realises there is no work to do (at least for the computer_id it is now reporting in as) so it closes the connection.

Are you familiar with wireshark? It might be worth looking at the port 402 traffic flowing between the client and server in this process to see what's going on. Even if this isn't your issue, a wireshark trace might help discern the problem if you out of ideas.

You might also try booting the client from a CD or USB stick to get around the PXE boot.....

Kind Regards,
Ian./

Hi Pipta,

Going back a step: could you dump us a screenshot of your "Distribute Disk Image" task?  It might be that something is amiss in the deployment job that we can spot for you.

In this task you would normally specify to use WinPE. I always like to specify exactly here the WinPE envrionment as I often forget what is specified in for the default offering in PXE.

Kind Regards,
Ian./

Have you tried assigning a different job to the machine and seeing if it executes? You could try setting up a pause in the automation environment to see if it runs.

In addition, I've seen this happen if I've modified a job while it is running. As a last ditch effort (especially if running a test automation job works), try this:

Delete/Remove the machine from the job.
Delete the machine account from your DS and create a new one.
Make a copy of the affected job.
Assign the new machine account to the new job.

Mike

is the computer added to the computer list in the DS?

i have had the problem that when the computer is listed already in the deployment server, it will boot in automation and then "connection closed..."

what i usually do is to make sure i delete the computer from the DS, then re-run the job. that usually works for me.