it means the client has been assigned a task, and the server is waiting for the client to 'pick it up' or execute the task, and return a status.

This could mean that you have a client that is not registered to a particular site server.

The Client Task Agent, once it has successfully registered, maintains an open TCP/IP connection to be able to receive new tasks almost immediately.  However, if that connect is closed for some reason, then the agent, by default, is set to "check-in" every 15 minutes for available tasks... 

 I tried to use aex-cta refresh to get it to happen, and it never did
the specific usage scenario is using a task to deploy software to an individual Mac.
Further development and testing will probably be put on hold until CMS SP2 is released

You can also try "aex-cta ts" to see if the client is actually connected to the task server as the moment.
If not, you can try "aex-cta register" to manually force registration with the task server.
Once the client is connected, it should pick up new tasks almost momentarily.

I am having the same problem with jobs/tasks failing but anything via policy runs fine.

I had an old DNS entry and the clients were trying to connect to another machine instead of the task server. Still cannot deploy files using the 'copy file' job/task and heard Deployment server 6.9 is a much better solution so I'm looking into that now. Created a script (xcopy) for a temporary solution to deploy files until everything is working.

TCPView is a good tool to see where the clients are trying to connect.

Joseph,

Combing through your posts it seems we have a lot of similar issues, as this too affects us too on a regular basis.  What is your setup like?  We have around 8k clients and 4 task servers for them.

"With regards to your issue and our remote session,
Please change the Site Server Settings for the Notification Server to register no more than 500 computers.
This will lower the load on the IIS of the Notification Server and will increase the performance of the console."

I assume its aimd at the NS...

E

In our case we deployed 4 Task Servers so we would be well under the 2500 threshold for managed clients per task server.  You are correct Eugene that the NS should be limited to 500 task clients max.

Tasks won't run on a client if you are outside any defined maintenance windows.  Some of the task scheduling interfaces allow you to ignore maintenance windows but not all.

For anyone experiencing this I'd reccommend you check if you have any maintenance windows defined and remove them for testing purposes.  You should also check that the clients you have targetted are showing up as registered to a specific task server (both from the agent and from the SMP console)

One thing i have found - the "Waiting for the agent to get the task" status is reflected on the NS until the task exits on the target.  Whether that be via timeout, or expected completion.

i.e.  If your command line isn't 100% it will continue showing this as the status until the task's timeout is reached.

Easy way to rule out your infrastructure - execute something REALLY simple!  i.e.  a sample task.

At that point if that has worked, you will know it is your task.  And as said above - blockouts WILL impede.

Maintenance windows are definitely not the issue in my case.  We do not utilize them.

I have attempted simple tasks as well (things like Task Agent tickles) and they fail as well.  It seems to happen with no rhyme or reason.

One thing that has seemed to help is enabling anonymous access on the ClientTaskServer and TaskManagement directories in IIS.  This is described in KB articles 47572 and 50365.  50365 Indicates the 401 errors behavior is being tracked as a bug.