Task Server is not registering to itself automatically

Products

IT Management Suite Client Management Suite

Issue/Introduction

Some Task Servers are not registering to themselves but rather they are registering to the SMP or another Task Server. The Task Servers are listing themselves as available Task Servers in the agent logs but they still go to register to the SMP Server (also known as Notification Server or NS) or another Task Server.

Environment

ITMS 8.x

Resolution

The assumption that a Task Server will always automatically register to itself first is incorrect. The Client Task Agent knows nothing about the Task Server plug-in, even if they are both installed on the same computer. So, the Task Server selection algorithm is always used to find the Task Server to assign an agent to.

Here's a few things to remember:

Client Task Agent Registration

In order to run a Task, the Client Task Agent must be registered with a Task Server. When first installed, the agent will request a list of all available Task Servers from the SMP Server. The agent will select a Task Server to register with based on the Task Server selection method it is using. There are 3 different methods and the one that agents will use is configured on the Task Agent Settings policy.

Shares - this involves the agent selecting a Task Server based on their relative load.

Fewest Computers - as the name suggests, the agent will select the Task Server that has the fewest number of already registered clients.

Fastest Connection - the agent will select the Task Server that it has the fastest connection to.

One thing to note is that when the agent receives the Task Server list from the SMP Server, the Task Servers name will always be its Fully Qualified Domain Name. The exceptions to this are when the Task Server is in a workgroup or the 'Preferred NS Host' option is being used and the SMP Server is returned as an available Task Server.

Once registered, the agent will check its Task Server for any new Tasks every 30 mins (by default - this is configurable on the Task Agent Settings policy).

If an agent computer is restarted (rebooted) or the Symantec Management Agent restarted, the Client Task Agent should remain registered with its previous Task Server. This is important for the continuation of Jobs that may have been running when the restart occurred.

Clicking on the Reset Agent button on the agent UI (Task Status tab) will force the agent to drop its current registration and get a new Server List from the SMP Server. The agent will then register with a Task Server from that list which could be a completely different Task Server than before. That will interrupt any running Jobs as the new Task Server will not have a record of the Job that was sent prior to the re-registration.

For example, here are some agent log entries (top entries are the most recent ones) while trying to register to a Task Server. NSserver.domain.com is the SMP server and TaskServer.domain.com is the Task Server that we want to register to:

6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
Attempting to register on Task Server [<TaskServer>.<Domain>.com] over [http].
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
CTaskServerNetCommsConnection::_buildTaskServerUrl(): url: http://<NSserver>.<Domain>.com:80/Altiris/ClientTaskServer
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
CTaskServerNetCommsConnection::_buildTaskServerUrl(): Server: [<NSserver>.<Domain>.com, Http: [80], Https: [443], Use Https: [false]
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
Pending Task Server Registration - initial timeout 15 sec, max timeout 300 sec, max retries 5.
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
Task Server: [<TaskServer>.<Domain>.com], Active: [false], Http: [80], Https: [0], Value: [0], Shares: [100]
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
Task Server: [<NSserver>.<Domain>.com], Active: [false], Http: [80], Https: [443], Value: [0], Shares: [94]
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
Registering with Task Server list:
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
Ordering servers by task server load shares
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
CTaskServerNetCommsConnection::_readServerListDocument(): Task Server: [<NSserver>.<Domain>.com], Http: [80], Https: [443], Active: [false]
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
CTaskServerNetCommsConnection::_readServerListDocument(): Task Server: [<NSserver>.<Domain>.com], Http: [80], Https: [0], Active: [false]
6/14/2018 7:57:52 AM	Client Task Agent	client task agent.dll	7852
CTaskServerNetCommsConnection::_readServerListDocument(): Found [2] servers.

So, here is what is happening:

The Task Server is asking for a list of available Task Servers:

CTaskServerNetCommsConnection::_readServerListDocument(): Found [2] servers.

Then it checks which one has fewest connections/shares:

Ordering servers by task server load shares
Task Server: [<NSserver>.<Domain>.com], Active: [false], Http: [80], Https: [443], Value: [0], Shares: [94]
Task Server: [<TaskServer>.<Domain>.com], Active: [false], Http: [80], Https: [0], Value: [0], Shares: [100]

And then it attempts to connect to the one with the fewest shares, which in this case is <NSserver>.<Domain>.com

In this scenario, the SMP server had only 94 connections/shares at that point of time while the Task Server had 100 connections/shares established. The SMP server was the available one to be selected as it had the fewest connections.

NOTE: Some additional background information on how things works with Client Task Agent is:

Shares Selection Algorithm

Previously, a Client Task Agent would select a Task Server to register with using one of two methods:

select the Task Server with the fewest connected clients, or

select the Task Server that the agent has the fastest connection to.

A third method, which can be referred to as the 'Shares' method has been added Since ITMS 7.1 SP2.

Agents can be configured to use the 'Shares' method by selecting the following option on the Task Agent Settings policy:

"Choose the Task Server relative to the remaining capacity of each server"

With this method, each available Task Server is given a value which equals:

The Maximum Allowed Connections for the Task Server (set in the Task Service Settings policy) less the Number of Current Active Connections (the number current connections is refreshed every 30 seconds).

If this option is selected and a Client Task Agent requests a new Server List from the Notification Server, the list will include this Shares value for each returned Task Server (eg. (Max Allowed Connections = 5000) - (Number of Current Active Connections = 2503) = 2497

The Agent then uses these values to determine which Task Server it will connect to. The selection is still random, however it is designed in such a way that the agent has a higher probability of selecting a Task Server with a higher Shares value.

Failover Logic

If a Client Task Agent (CTA) cannot connect to its registered Task Server, it will enter a Backoff/retry period to ensure that it can either reconnect with its previous Task Server or connect with a new task server after a reasonable period of time. The flow is similar to this:

CTA needs to check in with its Task Server to see if there are any new tasks available.

CTA cannot connect with its Task Server (Task Server is down, there are network issues etc.).

It will immediately back off and attempt to connect again in 2 mins.

If the first retry fails, it will back off again and attempt to connect again in 4 mins.

If that attempt to register fails, the agent will request a new server list from the SMP Server and attempt to register with a Task Server from that list.

If there are no Task Servers available, the CTA will again back off at incrementing intervals (2, 4, 8 mins etc.), requesting a new server list each time. Currently, this will continue for the length of the agent's periodic check interval (ie. the periodic check is the interval at which the Client Task Agent checks for new tasks with its Task Server. By default this is 30 minutes). Then the back off will stop until the agent does another periodic check - then the process begins again. Supposedly what should occur here is that the back off and retry will continue and not stop.

Previously, the time taken for an agent to failover to a new Task Server may have taken 90 to 120 minutes.

Method I:

NOTE: If someone wants to specifically select a Task Server to register to itself, the manual assignment will be the best method and this can be done by following these steps:

Go to Settings>Notification Server>Site Server Settings>Site Servers
Select the desired Site Server
Select "Manually Assigned Agents">New
Select a pre-existing target that contains the Site Server itself or create one
After assigning/creating the desired target, that specified client machines or Task Server will be registering to that Task Server itself

The manual assignment should help to tie the agent to the specific Task Server (but if the agent won't be able to register to this Task Server then it will stay in not-registered state).

Method II:

Another method is from the Site Server and the steps for this are:

Stop the Symantec Management Agent from services.
Delete the key of the server it is connect to in: \HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Communications\Servers ( ex: http:ns-20.example.local:443 )
Restart the Symantec Management Agent in services

Additional Information

KB 150990 "Client Task Agent Connectivity"