Symantec Management Platform (Notification Server)

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 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. Not as the product is currently designed.  Task is required for certain background actions on the server and is fully integrated in to the client.  At this time, there is no way to remove Task completely and it is definitely required for many internal functions even if you personally 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.  In 7.0, however, you can not prevent it at all.  For more information on this, read the best practices section below.
3. In part, yes.  In SMP 7.1, 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 also must remain on the NS. You can remove Task Server manually by running the MSI for the product, but doing so will break the NS and is not supported.
4. For an answer to this question, read the best practices section below.
5. Task Client-Server communication is moderately intense and can significantly impact overall performance on the NS.  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 have no more than 500. The main impact is with the Object Host Service, which can take up significant ammounts 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 at this time. It can be done, but since Symantec doesn't support the use of Aliases, the Task Site Servers themselves must be outside the DMZ. See HOWTO60757 for more information.

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 5000 clients if it is scaled appropriately, and that those requirements for scaling are very modest (ex. not using XP, but not requiring multi-core systems either).

There are three possible scenarios for managing Task Server communications:

1. (Figure 1, below). 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. (Figure 2, below.) 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 their own data-centers and it may be perfectly reasonable to place Task Servers there.
3. (Figure 3, below.) Put Task Servers in every location that you have a Package Server.  This scenario is demanded by Deployment Solution versions previous to 7.2. Due to constraints listed below in communication between the Task Servers and the NS, this is not recommended. However, since Deployment Solution requires a Task Server in every location you may perform Imaging (again, prior to 7.2) this may be a requirement.

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 multple 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 "fail over" 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 sever resides (see figue 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.
• Remember that in DS 7.0 and 7.1, each Site Server from which you want to perform imaging tasks must be a Package Server and a Task Server.  In DS 7.2 this will change, but in 7.0-7.1, this necessitates the design outlined in figure 3.
• 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 (eg, 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 for 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 very 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 equates 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 XP and Windows 7 both have limitations that may cause problems for managing more than 10 clients at a time for Task and Package.  This is the difference between Server and Client classed systems.  Be careful when you deploy Task onto Client systems and test it thoroughly so you understand those limitations and expectations for performance.  It is a relatively common scenario to use XP or Windows 7 for smaller sites, especially those with less than 10 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.  Unfortunately, at this time, that setting works poorly.  Some changes are being made in SMP 7.1 SP2 (due late 2012) that should improve this setting.  As a general rule, though, if you manage your sites well this should not be an issue except in very large multi-task-server/site environments.
• In SMP version 7.1, Task Server installations on 2008 R2 are broken out-of-the-box. This is a known limitation. The ClientTask subfolder under Altiris in IIS must be assigned to use the Classic App Pool instead of the Default App Pool in order to work correctly.