Deployment and Imaging Group

We have started seeing an issue where when a tech goes to reimage a machine, PXE works fine, the Managed Deployment window comes up, they select the right job and then nothing happens.

The console says it's waiting to get the agent task.

I put a ticket in, but wondered if anyone had run across this as well or had suggestions  We are 7.5 SP1 latest hot fix.

If I reboot the machine and repeat the same process, choosing same job, it works fine the 2nd time.  Some timing issue I wonder of when the job is selected or something?

Here's a snippet from the pectagent.log showing it knows we chose the Win7 64 bit image but then it just sits.  I

    <XmlData><InitialDeploymentEvent><ActionType>Execute Task</ActionType><IntialDeploymentJobTaskGuid>7608d334-b1c1-4b22-b2d2-6823ab8caa81</IntialDeploymentJobTaskGuid><TaskName>Win7 64bit Admin Laptop (Office 2013)</TaskName><TaskDescription></TaskDescription></InitialDeploymentEvent></XmlData>
</body>
</message>

[2015/04/16 08:37:25.251 1244:1248 2] apps\DeploymentClient\PECTAgent\InitialDeployTask.cpp:278 CInitialDeployTask::PostInitialDeployNSE(): calling HttpPost()
[2015/04/16 08:37:25.476 1244:1248 2] apps\DeploymentClient\PECTAgent\InitialDeployTask.cpp:283 CInitialDeployTask::PostInitialDeployNSE(): PostEvent response=Event successfully processed.
[2015/04/16 08:37:25.476 1244:1248 2] common\util\ExecuteCommand.cpp:5311 initializing Client Task Agent

[2015/04/16 08:37:25.476 1244:1248 2] common\util\ExecuteCommand.cpp:5316 Starting Client Task Agent

[2015/04/16 08:37:25.476 1244:1248 2] Entering into RunMessageLoop

Hello Sally,

This might be the known problem with SP HF5 basic inventory DLL

have a try

http://www.symantec.com/docs/TECH227363

Br

Indrek

Our issue is with known clients, not unknown (so far).  We don't have many unknown we image.

Hello Indrek,

We are having the same issue as mentioned in the link you mentioned in our environment but we are running 7.5 SP1 HF3.  Any ideas if this issue is also known in SP1 HF3?  Would this pointfix apply?

Thanks!

Sally,

We are on a recently upgraded 7.1 -> 7.5.1 SP1 HF5 install as well.

We are too having intermittent issues deploying Image Tasks from Initial Deployment.

It happens on Managed and Unknown computers.  Like yours when the Image job is selected nothing happens, can reboot and select same task and it works

I have noticed that if i go tot he console, stop/delete the Imaging job that is stuck at "Waiting for the agent". Then deploy via the console, it will image fine.

I have not opened a ticket yet though.  No amount of waiting time after the Initial Deployment screen comes up seems to help, so I doubt it’s a true timing issue.

Right now we have an approx 60% success rate with the Initial Deployment imaging task running.

I am almost to the point of removing the Initial Deployment screen and making the service desk go deploy the task form the console.

BTW, we have the AeXBasicInventory.dll fix in place and not helping.  The new DLL actually doesnt work as expected anyways.  We are using the HF3 dll in our PXE boot image in place of the HF5 or pointFix version.

Thanks,

Clay

Yours seems much more easily reproduced than mine.  I saw it once, one of our techs saw it once, but when I put a ticket in i was unable to reproduce for support.  I'm not using any different DLLs than what came with the hot fix.

This happens to us as well. In fact its happened this morning on a few machines. Tech selects job from initial deployment, job doesnt run any tasks! If I kill the job and then run the job in the console on that machine then the job kicks off OK.

This happens to us as well on SP1 HF5. It's just a guess, but I believe it is related to the same issue that many of us see where 'boot to production' fails.

I must be one of the lucky.  I haven't seen the boot to prod issue 

We only have this issue with one specific device type.  It fails as soon as it trys to deploy the image.  I do not see anything specific in the logs to explain the issue to find a resolution.  All other unknown computers run through the tasks successfully. 

The GHOSTERR.TXT generates an Error Number: 8027 Message: A GeneralException occurred and scrolling down there is a reference to "A disk error occurred IDE Controller error: Command aborted due to fatal error."  I checked the disk, ran a manufacturer diagnostic, it is fine.

We are running v7.1.8280

The CLIENTIMAGEDEPLOY.LOG has this error, I was not able to find a solution for this error:

[2015/06/17 22:25:54.190 1780:872 0] apps\DeploymentClient\ClientImageDeploy\Tcube_ClientImageDeploy.cpp@134 Child Process returned an error value=60, error=183
[2015/06/17 22:25:54.190 1780:872 2] apps\DeploymentClient\ClientImageDeploy\Tcube_ClientImageDeploy.cpp@1105 Output @errorMessage=Child Process returned an error
[2015/06/17 22:25:54.190 1780:872 2] apps\DeploymentClient\ClientImageDeploy\Tcube_ClientImageDeploy.cpp@1114 Imaging completed. Failure return!!

Tried rebooting the client machine, ran independent tasks, only fails when trying to deploy image, deleted the tasks and client from console. Restarted the server, restarted the client machine, still was not able deploy the image.
 

Hello.  How do you run the job from the console? Are you referring to the PXE window on the client machine or Symantec Management Console?   The first thing that our task does is reboot the machine into PXE x86, then it runs a DiskPart to clean disk 0, then it is suppose to deploy the base image but it fails just as soon as it starts. 

You must be lucky, my 'Boot To' task to go into Production is only 50%-60% dependable. I only use an automated image job for my training rooms, so if a few desktops do not signal back to the NS that the Boot To task completed. I take over the next day (I run the imaging job at night) and run my Application Job. I noted that problem to a Symantec Engineer while working on a DeployAnywhere problem. I hope Symantec takes this problem to heart and try to fix it.

Sally and All,

I think we figured out why some jobs just don't launch after being selected at the Initial Deployment screen, at least for our environment. With a little help from Symantec

Every case we have with this Initial Deployment scenario, we see the exact same issue but with Managed Computers only

Basically when our Service Desk employees come to one of my team member as says the "imaging job did not start", we always jump into the job/task within the console and look at the Task Server details ( not visible by default).

Double click or select the details finger from the task Status page.

Select choose columns, then check mark Task Server. Click OK

You will now have a column to the right on what Task Server the SMP sent the request to.<u1:p></u1:p>

In every case the Task Server listed is not the one in the current Site where the machine is being PXE booted from.  This happens because the last time the particular machine was powered on into the OS it was more than likely in another site and shipped to our location for a rebuild.  The task server registration is stored in the table Inv_Client_Task_Resources form its last check in and the SMP seems to just sends it to the last one it was registered with.<u1:p></u1:p>

When the Initial Deployment job is triggered it attempts to send the task to the previous site server since in while in PXE the pectagent does not attempt to connect to a task server until a job is scheduled.<u1:p></u1:p>

For us to "Fix" this when it occurs, all we have to do is locate the imaging task and stop it, wait for it to show failed in the console, then just right click and Start Now.<u1:p></u1:p>

The SMP then sends it to the correct Task Server and it will start.<u1:p></u1:p>

Not sure why it works this way but we are having to deal with it since we are a major hub site in our company and most if not all of our imaging is from all remote peoples machines.  Our remote sites that do imaging locally never see this because all their machines had already registered with the local Task Server.<u1:p></u1:p>

One way I suggested to Symantec to fix this for our environment is to run a nightly truncate on the Inv_Client_Task_Resources table or some query that would delete the IsActive=0 ones.  Not sure how accurate it will be though<u1:p></u1:p>.

Our tech asked backline and they did not see any issue with it , since it would get repopulated the next time the agent checked into a Task Server but in my tests if the record was removed while the machine was online, tasks could not be pushed until the computers agent was restarted . It would only then repopulate itself into that table.  Manually triggering a Send Basic, Update Config, or Reset Agent did nothing to repopulate it.

We have yet to implement this "fix" but are leaning towards something like it.  Maybe delete all records from that table whose agent has not requested a config update longer than our scheduled time. (4 hours)<u1:p></u1:p>

I hope this explanation helps in all people who are experiencing this, it does for us.<u1:p></u1:p>

Thanks,<u1:p></u1:p>

Clay

thanks for the great write up.  We only have one NS server, no site servers, but I'm sure this will help someone.

That sounded good and thought it might be the answer to my problem. Got a machine this morning that didnt kick off the job - checked the task server and it was the correct one! doh! powered off machine, removed from console, tried again and it worked! pffft!

We started experiencing this problem too with one specific model (HP Revolve G2) on NS 7.1. All other systems are imaging just fine. Verified the disk is fine but as soon as it gets to the task to image it fails. It does not see the hard drive. Verified that the drivers are loaded but still no joy and also sounds like upgrading to 7.5 did not solve the issue. 

Ive just noticed that one of the machines thats not working after menu selection is registering with the Notification server as the task server? Could this be the cause. Our NS is situated in a data centre where no clients are present. I thought each site server would handle its opwn clients! Am I able to remove task service from the NS and not cause any problems ?

Hi JannasTo,

We are experiencing the same issue as you described.  I tried removing Task from the NS and after a few days our downstream task servers could not register.  I am continuing to work with Symantec for a resolution.

Resolved our issue with the G2, it is actually an issue with SSD.  Found this after many hours of searching - https://support.symantec.com/en_US/article.TECH213004.html

jms97,

It's good (and bad) to hear that we are not the only ones having issues...

AltirisJunkie and I have already removed the task server service from all of our CMS and the issue started occuring a few weeks afterwards.  In addition, if a help desk associate was to push a task from the console while this issue is occurring, then the job will show pending in the console (indefinitely), but the resources agent gets the task...

Symantec wants us to remove the task server again on Friday... :\

Hello all,

We are also seeing this issue within our envrionment.  We had this issue under 7.5 and now even after implementing 7.6.

Our issue is very similair, possibly not identical, but same basis.  Initial Deployment rather than Managed.

We boot new machines that have never seen a site server or registered with the console.  We F8 into deployment to proceed into PE.  We get the Initial Deployment menu with our imaging jobs listed, we select a job, the machine registers via the console as PECTAGENT with the correct imaging job scheduled to run, but the job actually never runs.  The job will eventually time out and fail with no user interaction.

I can, at times, find the job in the console, and force it to start now or rerun task, this starts the job all over again, but for some reason takes and images.

Another odd issue is some times when attempting the manual restart I get an error that says "After scoping and filtering no computers are left assigned this task." - Have not looked into that problem yet.

Thanks!

Matthew Rhodes 

one way to fix this is to make sure that all ip ranges are correctly pointly to the task servers. dont let the SMP do it - we had this issue a couple times over the years and it usually related to a machine not getting to the Task server correctly. It also can manifest itself if you put a image on only 1 package server. Then machine trying to deploy would try and pull the image down from the NS instead of the package server. causing long image times also 

for -After scoping and filtering no computers are left assigned this task.- check your resource update times. if they are long it means that the machine is not installing the deployment agent in time for the package to go down. OR it means that the machine has not updated its status in the CMDB