Video Screencast Help

Altiris 7.1 - Task does not run until agent is reset

Created: 26 Sep 2013 • Updated: 26 Sep 2013 | 12 comments


I've created an image deployment job which contains a final task that joins the client to the domain.  The job runs successfully i.e. reboots to PXE, erases the HDD, deploys the image and boots back into production but the last join domain task will not run until the agent is reset on the client.

When the agent is reset the client still has the same guid but switches task servers, which seems to kick in the join domain task.

If I dont reset the agent the task is never run.  If I run a manual join domain quick task it works without resetting the agent.

I have tried recapturing my image via altris and recreating my deployment job but this hasn't fixed the problem.

Any help would be greatly appreciated


Operating Systems:

Comments 12 CommentsJump to latest comment

HighTower's picture

I moved this thread to the Deployment Solution forum.

Jesse A. Gonzales's picture

In your job, you're probably missing a crucial step. This task is called Update Client Configuration. Whenever you have a task following a reboot out of automation into production, you will need to add this task before continuing with any other tasks. What this task will do is it will send the agent information about which operating system is currently running. (Production vs preboot).

So, try adding the task in between the reboot and the join domain task...

davamac's picture


I will try adding and update configuration task between the reboot and join domain task as you suggest and let you know how it goes...

davamac's picture


The Update Client Configuration task did not run automatically.  I still had to manually reset the agent on the client before this task would run.  I'm wondering if its something to do with the fact that we have our NS and a Site Server in the same location.  The NS is set to only manage 100 clients, but when I image a PC it automatically connects to the NS as its task server instead of the Site Server.  restting the agent switches it to the Site server and the join domain task runs.


Gavin Sanish's picture

Hi Davamac

-If you want to remove the old guid
-You have to try taking the image with the Sysprep
-Sysprep will remove all the system informations and it will also remove the guid.
-So when you try to deploy it will get a new guid for every computer.
-So your job must be when trying to image
1. Prepare for image capture
2.Create image
3.Reboot to production

In that you can add the erase disk and all.




G. Gavin Sanish

T : +91 9884877206
MKOKA's picture

Hello Davamac,

As I see that you already have the Symantec Management Agent installed, its always good to follow the article #

As mentioned in this we have two methods.

  1. The Altiris Agent must be completely removed and then re-applied post-imaging1, or
  2. The GUID for the Altiris Agent must be removed and the Altiris Agent must be prevented from communicating with the Notification Server prior to the computer being renamed.

Yes Sysprep should do the necessary thing as well, however I had come across this recently, so we use the Apply system configuration task separately as a different task, after the image deployment. However this could be a workaround.

davamac's picture


I logged a call with symantec for this issue and after many hours of trial and error they recommended this solution.  

Currently my NS and site server are alocated to a single site with multiple subnets.  Symantec created a new site under site management and added my site server to it.  They then removed the subnet my client was on from the original site and asigned it to the new site.  This removed the subnet from the NS and assigned it to the site server only.

Now when I deploy an image to my client the image job runs and once rebooted to production the job continues on and runs the join domain task correctly.

I know this workaround works but I still dont understand why i cant have and NS and site server in the same site servicing the same subnets.


fabian.szalatnay's picture

Hi davamac

This is a known problem. After rebooting, the altiris client could connect to another task server. This leads to a broken job sequence because the job status will not be "exchanged" between task servers. So the client does not know where to continue.

This means, you have to make sure that the client always connects to the same task server to continue its jobs.

There are various approaches to achieve this

  • use option "choose TS relative to the remaining capacity of each server" and configure your TS to accept "unequal" amount of clients (limit your NS to accept only 100 clients, therefore your clients will always connect to the "other" TS which accepts 2000 or 5000)
  • use manual assignment of TS while deploying Operating System (using filters)
  • use fake sites like Symantec support did

Good luck


Klim_Belchev's picture

How/where do you configure TS to accept "unequal" amount of clients?

HighTower's picture

Settings > Notification Server > Site Settings
Site Management > Settings > Task Service > Settings

From there I would clone the policy and disable the original.

I made three new policies for my org:

1.  Notification Server only - I set max clients to 100 computers, 5 minutes, 5 minutes
2.  Core Site Servers - 5000 computers, 5 minutes, 1 minute  (these are real servers in my fast datacenters)
3.  Remote Site Servers - 1000 computers, 5 minutes, 1 minute

Of course you'll have to create filters to organize your Task Servers so you can apply the policy to them.  Make sure that you don't have multiple policies applying to the same servers.

Also, make sure you spend the time to fully construct your organization's Sites.

fabian.szalatnay's picture

There you have it, like HighTower wrote...
Good Luck.

Thomas Baird's picture

I should note several things that have changed recently.  You should probably call in to talk to a Task specialist.

First, if a task is running, a recent (relatively speaking) rollup made it so you'll get the same task server and the job should not then "fail" because you're on a different task server.  Basically, we look for an active job/task, and if so, we give you back the same one you were connected to before, even if YOU have physically moved.

I don't remember what rollup this was in, but I think it was V4 or V5.  That means you'd have to be on 7.1 MP1.1.

Also, I should note that setting up Task Server on the NS to only service 100 clients is "old school".  I know, because I wrote that recommendation up years ago.  But post SP2, the Task Team enabled you to remove Task from the NS completely - and I recommend that.  However, when I say "remove" I mean you do so in the Site Settings screen, you do NOT remove Object Host.  After doing so, the clients will ONLY connect to site servers, for the NS will not be given out as a possible Task Server to clients - even to the NS.

This completely removes the need to "limit" the policy for the NS and saves having to duplicate that policy.

Anyway, just a few thoughts.  We don't get many of the failed task calls now.

PS>  We're working on another failure point that is NOT fixed.  We want to get the GUID into the agent while still in automation - we have it - so it doesn't have to check in and ask for it's GUID.  This will both speed things up in prodution ( a little) and will prevent the very rare duplicate GUID issue / new GUID issues we've seen when booting back to production.  Again - NOT DONE yet.  No ETA either.  Sorry.

Thomas Baird
Enthusiast for making things better!