Clients and/or servers are not communicating with the Notification server, and are not showing active in the NS Console. How do we troubleshoot this?
The main problems I have with Task Server involves configuration, and remarkably, most of the communication issues are related to this. So, for this discussion / KB, we'll talk about the configuration from the top (NS) down. At each component, we'll also discuss some simple things to look for or check for.
For the sake of troubleshooting and using this document, I will refer to the following location as the TS Root: In the NS 6.0 console, Configuration\Notification Server Infrastructure\Task Server.
To troubleshoot, configure, and do just about anything except send tasks, you should use the NS 6.0 console. Most people using TS have the 6.5 console installed, and are likely using it. It's organization is nice, but I've found that the 6.0 console has everything in one place, and for troubleshooting, it's simply easier.
1) Install, Organize, and Configure the Task Servers
First, recognize that the NS should not manage more than about 500 TS clients. If that much. I would generally recommend 0 if possible, though it's completely reasonable to support a small number if that fits your environment. Remember that each TS client is, by default, communicating with it's TS every 5 minutes for basic updates, and sending updates during an install ever 10 seconds. So, for 4000 clients:
5x60 = 300 4000/300 = 13 client updates per second. If you are pushing a package to all of them, you increase that 30 fold.
The net translation is that I've had network adminstrators literally choke off the Notification Server, and that was the NS's that were still functioning.
Second, using the same logic as above, be sure to configure enough Task Servers for your envirionment. In general, people have utilized their Package Servers for this. This is a "default" in NS7, but in NS6 this has to be chosen.There are 4 requirements to be met to get a task server installed:
Meeting these three requirements will place the Task Server agent on the selected client systems. NOTE: Your NS will automatically get the server agent and does not need to be added to these collections.
Third, the task servers need to be organized under the Task Servers policy page. This is a highly important step that is often skipped by users who do not understand the product.
Technically, you can skip this step and TS will run. It just wont run well. Without configuring this page, your clients will "pick" which TS to report to, generally resorting to the one that answers a ping request fastest, and you'll get cross-country communication. It happens all the time, because the auto-selection feature does not work reliably. In theory this process should select the closest server based on subnet and ping results, but what we've found is, in fact, the opposite. The other unfortunate feature of the TS clients is that they remember their "chosen" configuration forever. Translation: Once they choose a server, they don't choose again. So, if on Friday, when the client was pushed, the local server was busy, but a remote server was available because they had shut down for the day from another time zone, all the clients will connect to that one, and REMAIN connected to that one into perpetuity.
Unless you configure this policy page. So it's a good idea to simply do this, out of the gate.
NOTE: There is no way to use Site Maintenance for this step in NS6. NS7 is integrated with Sites, but not NS6. The best way is to create a collection or collections for each location. Add the collections into this page using the yellow asterisk *. Once added, highlight each collection, click the blue + and add at least one task server to each. A task server may be assigned to more than one collection. Remember to include your Notification Server as one of these, IF you intend on using it. Many will NOT include their notification server, simply to offload all of this traffic completely.
If you have done this correctly, each collection will show an active (blue) computer(s) under it, indicating the associate Task Server is connected and active. In this application alone we have similarities with DS in that you can see the active and inactive state of systems in near real-time. If not, see step 3 below.
NOTE: There is a bug (at least there was) on this page where no scroll bar was included. After adding several collections (around 20 or 25) the screen will fill, and you'll have to arrow up and down to get through them. I never see the bug because I don't have that many collections to populate it with.
2) Install the client agents Once you have the servers configured, you're ready to roll out the clients. This should not be done prior to the servers, because the clients remember their connections and must reboot to get the "new" connections from the NS.Technically, not all of the TS agents need to be installed, but for general use, they should all be selected. Only NOT select a client installation if the customer knows for a fact they will not be using it. The problem is that the various task types don't always tell you which version must be installed, and troubleshooting that later can be a pain. So, enable the following policies to their default collection:
If you have these agents installed, and if you have previously configured the servers in step 1 above, then when you highlight a server, several agents will show as reporting to it, and these agents will be the "correct" agents for that server (not from another collection/location). If not, see steps 3 and 4 below.
3. Troubleshooting Server Connectivity/Installation issuesThe very first thing to check is the process described in step 1 above. About 50% of troubleshooting comes down to the fact that something was missed in the original configuration. For instance, forgetting to put a server in both the Task Servers and approved task servers collection, or failing to configure the Task Servers policy page, or even forgetting to enable the Task Server agent. Methodically check through the configuration to see how things are built first, then move on to actual troubleshooting. If you are confident things on the NS look good, the following are things to look at, and not necessarily in this order. (Generally, I'll launch Computer Management, so I can manipulate services, check logs, and look at IIS in a single window)
Once you have the server functional, it should check-in to the NS and should show BLUE on the Task Server policy page you configured. Then you should continue on to Client troubleshooting below:4) Troubleshooting Client Connectivity/Installation issues
Generally, I've seen very little actual Client issues, and would recommend you check the servers first. However, here are the things to check for the clients: