Best Practice: Managing Task Server Communications in 8.x

ITMS 8.x

There are several questions and scenarios involved in managing Task Server communications, including:

1. Can we prevent Client-Task communication completely?  What if we don't want to use Task at all?
2. Can we prevent communication with the NS (Notification Server)?
3. Can we remove the Task Server from the NS?
4. What are the best practices for configuring Site Servers?
5. What are the performance impacts of Task on the NS?  On-Site Servers?
6. Can we modify the ports that we bind on?
7. Can we use Task Server in a DMZ or with Aliases?

This article will answer these questions in two ways: First, it will give a short answer to each question listed above, and second, it will give some best practices for managing Task Server communications.

Answers to common questions (above)

1. No.  Task is required for certain background actions on the server and is fully integrated into the client.  There is no way to remove Task completely as it is required for many internal functions even if you never use it.
2. In part, yes.  As of SMP 7.1, you can prevent clients from using the NS as their Task Server, but you cannot fully prevent Task communications on the NS.  
3. In part, yes.  You can use Site Management to remove the Task Service from the NS, which will stop agents from registering with the NS (see #2 above). However, this will not actually remove Task Server from the NS because it is required for many background actions (see answer #1).  Task Management (as opposed to Task Server) is an installed solution and part of the SMP. It must remain on the NS.
4. For an answer to this question, read the best practices section below.
5. Task Client-Server communication is moderately intense and could significantly impact the overall performance of the NS. In newer versions, this has less impact.  On-Site Servers, the impact is much less.  This is why a Site Server is recommended because it supports about 5,000 clients. On an NS it is recommended that you configure it to have no more than 100. The main impact is with the Object Host Service, which can take up significant amounts of RAM as it does its work.  Clients communicate actively and frequently when tasks are running (every 30 minutes even if nothing is happening at all), so be cautious.  This can be adjusted to reduce load, but it is still not recommended.
6. Yes, in the Task Service Settings (Settings>Notification Server>Site Server Settings>Task Service) you can modify the ports that are used by Task.
7. No, this is not supported (see the further comments below). It can be done, but since Symantec doesn't support the use of Aliases, the Task Site Servers themselves must be outside the DMZ.
   1. NOTE:  The releases of ITMS starting with version 7.5, we will partially support this scenario but is limited with Tasks, and Tasks are "technically" not supported in the cloud/DMZ  These releases are designed to be used in the Cloud (CEM or Cloud-Enabled Management), using DMZ's.  It will also allow computers to communicate through the Internet and get policies and packages.  However, the Task "tickle" will not work - the clients will have to check in to get their tasks, which is why Task is not "supported" even though they'll work.  The problem is that the check-in interval may have to be shortened, which could cause load problems, etc., so again, it won’t be supported.

NOTE: It is important to remember the information in #3 above. Symantec does not support removing Task functionality from your environment--especially from the NS. Doing this will always cause problems. This has been well documented, so please ignore any advice to the contrary.

Best Practices

The key to managing Task Server communications is to reduce as much traffic to the NS as possible using Task.  Listed below are a few good ways to do that, as well as some general tips for managing the Task environment.

Symantec recommends that you create a site for the NS that contains only the Class C subnet of the NS.  According to site rules, in this scenario, the NS is limited to supporting no more than 254 clients (the max for a class C range). Additionally, since the NS is generally on a server backplane, it is often the case that either the servers are not managed or there are simply very few systems on that particular subnet.

Symantec recommends that you carefully create sites for each of your Task Servers.  Remember that a Task Server can support between 5000 and 15000 clients (depending on version) if it is scaled appropriately and that those requirements for scaling are very modest.

There are three possible scenarios for managing Task Server communications:

1. Site definitions can and should include multiple subnets and can include the same subnet as the NS. This is not a problem.  They might pick up clients from the NS's subnet, but the NS will not pick up clients from the others.  Frequently, Task Server users will have their Site Servers created along with the NS in a single location (ex. a server room), where this kind of scenario may be required.  As long as bandwidth is good from the clients to the Site Servers, this is a perfectly acceptable solution.  
2. Place Task Servers closer to your clients. This is used by companies with larger remote environments (ex. major offices in the US, Europe, S. America, and Japan).  Each major office may have its own data centers and it may be perfectly reasonable to place Task Servers there.
3. Put Task Servers in every location that you have a Package Server. 

Obviously, as with Package Servers, you can assign multiple Task Servers to each site.  This is not represented in the figures below and is not managed like Package Servers with Constrained or unconstrained servers.  For load balancing in these scenarios, the setting under Task Agent Settings for "When multiple task servers are available at a site" is important.

Symantec also recommends that you run a task to re-assign task clients on a regular basis, such as weekly or monthly--depending on how mobile your environment is or how much provisioning you're doing. Task clients do not automatically re-assign themselves to the closest or lowest-load task server.  A slight modification to this was made in SMP 7.1 where now they will re-check every 24 hours, but this method is not very reliable.  They may also reassign themselves after a delayed time of not being able to connect to their assigned task server..  A simple task to "Reset Task Agent" sent to all clients can keep load balancing fresh, and mobile users assigned appropriately.  

Both the 24-hour re-check and running this task is important to remember when adding new Task Servers, for otherwise, they will not automatically pick up new clients.  Additionally, since the NS is the "failover" for task agents, so doing this can "pull" clients off the NS.

Additional Considerations

• When building a site, you can NOT exclude the subnet in which the server resides (see figure 1, above).  In figure 1, the subnet for the NS and the 3 Site Servers is shared in all 4 site definitions.  If you try to exclude the subnet for the Site Server, it will be automatically added back.
• Each Task Server communicates with the Notification Server every 5 minutes by default, or as configured in the Task Service settings.  If you have many Task Servers (e.g., over 100) this can cause an additional load on the NS. You can reduce this setting significantly to reduce this load. The Task to NS communication is a fail-over mechanism if the default tickle ports are not working.  If the tickle ports are blocked, any modification to this setting could significantly reduce task responsiveness and possibly cause task failures due to time-outs.
• Each Client communicates with its Task Server every 30 minutes by default, or as configured in the Task Agent settings.  Thus, for 500 systems (max recommended for the NS), this equates to 16 pings/minute. This may not seem like much, but it's still a very real load especially if it is added to the increased load when actually performing tasks.  For Site Servers, 5000 clients equate to 166 pings/minute or several each second, which is why you need decent server-classed systems for larger sites.  This setting can also be reduced, but 30 minutes is a reduced rate already and probably should not be reduced much more unless you're confident the Tickle ports are working reliably well.
• Windows 10 has limitations that may cause problems for managing more than 20 clients at a time for Task and Package (concurrent connection limit).  This is the difference between Server and Client classed systems.  Be careful when you deploy Tasks onto Client systems and test them thoroughly so you understand those limitations and expectations for performance.  It is a relatively common scenario to use Windows 10 for smaller sites, especially those with less than 20 users.
• There is an option in the Task Servers Settings page that will limit the number of clients that can connect to a Task Server.  We recommend cloning this policy and creating two new policies.
  • One policy targets only the NS, limits the maximum number of computers to manage to 100 (the lowest it will accept) and unchecks the Allow maximum computers to be exceeded.
  • The other policy targets all task servers except the NS and may be left as default or as desired.
  • Enable the clones and disable the default policy.
• If you decide to use Manually Assigned Agents to restrict clients to a certain task server (not recommended), remember that this setting affects ALL of the services on that site server, including Package services, not just Tasks, so be very cautious.  (For instance, if you used this on a Task Server with Package Services, and a client then moves to another location, packages will be pulled from the remote server.)