KNOWN ISSUE: Task Server doesn't always follow Site Server definitions well when assigning Site Servers to Clients.

Article:TECH140237  |  Created: 2010-09-17  |  Updated: 2010-12-09  |  Article URL
Article Type
Technical Solution


In short, what we expect a client to be assigned isn't always happening.

Here's what should be happening when a client connects to the NS and requests a Task Server:

  1. The NS scans to see if a computer is "manually assigned" to a task server.  If so, that will be the task server returned to the client and the process is done.
  2. Failing that, the NS scans to see if a computer is assigned to a site via Site Definition (subnets).  If so, any/all of the servers in the site should be returned to the Client.  The client will need to pick one of them per the rules assigned (i.e. fastest connection or least connections).
  3. Failing that, the NS begins a round-robin selection of Site Servers - including just about any site server available.  These are distributed literally round-robin each request.
  4. Failing that, the NS will hand out itself as the Task Server.


What appears to be happening in some cases, not all, follows:

  1. The manually assigned computer may be ignored, resorting to any server in the site instead.  Sometimes this means any EXCEPT the one manually assigned.
  2. Subnets are ignored and the clients are sent either the round-robin or NS response.  Sometimes, the fully functional Site Server will have no clients attached at all.
  3. Clients will report as correctly connecting to the Task Server, though will not receive Tasks unless Manually Assigned to a Server.


Being Researched:  The reality is there are likely several issues that Development is aware of and seeking to find a resolution for.


The best suggestion we have at this time is to manually assign agents.  This seems to be reliable for most of our clients.

It should be noted that MOST customers don't see this issue so it's safe to guess that many site servers might work just fine.

It also seems that only having one subnet to a Site Server seems to work pretty well.


Finally, relative to the first solution suggested, what several customers are doing is making filters based on subnets, then assigning these to the sites as manually assignments.  This makes the clients just as flexible as the normal site/subnet definitions, but gets around the limitation.


Oh, and remember to send a Reset Agent task once changes have been made so the client will request a new server.

Article URL

Terms of use for this information are found in Legal Notices