It was noticed after the VM SMP server had been moved that most clients could not register to any task servers.
The SMP logs had a river of the following error (excerpt). Also the agent logs contained a snippet that the maximum number of connections the Task Server policy allowed had been reached.
Symantec Management Platform 7.6 HF3
Description: The handler 'RegisterTaskServer' is failed to process request. Altiris.NS.Exceptions.AeXSecurityException: The caller [WORLDFOODS\BOSSadmin] does not have one or more of the specified permissions on the specified item c74002b6-c7b9-47bb-a5d6-3031af73bb8d
at Altiris.NS.Security.ItemPermission.Demand(Guid entity, Guid permission)
at Altiris.Resource.ResourceDataTable.Load(Guid resourceGuid)
at Altiris.TaskManagement.ClientTask.BaseWeb.RegisterTaskServer.WriteResponse(XmlTextWriter wr)
at Altiris.DotNetLib.Threading.StringBuilderCache.ToXml(Action`1 fu)
at Altiris.TaskManagement.Common.XmlHttp.BaseXmlXmlHttpCallback.WriteResponseRaw(XmlTextWriter xwr)
at Altiris.TaskManagement.Common.XmlHttp.BaseXmlHttpCallback.ProcessRequest(HttpContext context)
There were two major causes. It does not appear to be related to the move.
When the computers were attempting to register-- underneath the hood the store procedure "CtsGetAllRegisteredTaskServers" was being invoked and passed the NS's GUID.
CtsGetAllRegisteredTaskServers is called to obtain the list of active Task Servers and to get theire FQDN information.
CtsGetAllRegisteredTaskServers was only returning the SMP, and not the other two Task Servers. The policy affecting the SMP only allowed for 100 connections (there were 8,000+ computers).
The other two servers were not being returned because CtsGetAllRegisteredTaskServers was joining results to "Inv_Client_Task_Servers" where "IsActive" = 1 but the column for the two Task Servers was 0. The really strange thing was that, in the SMP Console SMP UI shows that the "Task Service" box was checked. So IsActive should have been 1.
Running the following script (which is the SQL from CtsGetAllRegisteredTaskServers) against the database. This SQL provides more information as to what the stored procedure is returning.
Note: Set the GUID in line 2 to that of the GUID assigned to the SMP’s agent.
declare @notificationServerGuid uniqueidentifier
set @notificationServerGuid ='<guid>' -- SMP's agent GUID
DECLARE @majorVersion float
DECLARE @minorVersion int
DECLARE @version varchar(40)
DECLARE @pos int
SET @version =(SELECTTOP 1 VersionFROM DBSchema ORDERBY Id DESC)
-- position of second dot
SET @pos =CHARINDEX('.', @version,CHARINDEX('.', @version )+ 1 )
SET @majorVersion =CAST(SUBSTRING( @version, 1, @pos - 1 )ASfloat)
SET @minorVersion =CAST(SUBSTRING( @version, @pos + 1, 4 )ASint)
Join Inv_Client_Task_Servers cts on cts._ResourceGuid = c.Guid
JOIN [dbo].[ItemClass] AS ic ON ic.[Guid] = ts.[TaskServiceResourceGuid]
WHERE ic.[ClassGuid] ='2ef03107-5954-40ea-b430-cc9f479de2ca'
Whenever an outlying client tried to register the above error was being thrown indicating that user "domain\BOSSadmin" does not have "one or more of the specified permissions.." to c74002b6-c7b9-47bb-a5d6-3031af73bb8d which is the data class Inv_AeX_AC_Identification (which a function invoked by CtsGetAllRegisteredTaskServers uses to get the FQDN)
The strange thing was that the account [domain\BOSSadmin] did not even exist as an imported user.
SOLUTION 1: Since there were only three Task Servers and all of them should be active, I ran the following SQL statement against the database:
update Inv_Client_Task_Servers set IsActive = 1
Created a new user [domain\BOSSadmin] and assigned it to the same Windows domain user.
Added the new account to the "Symantec Administrators" role.
After making the changes all of the computers that we manually forced to reset/register to a task server were assigned one of the two servers and registered successfully.
Subscribing will provide email updates when this Article is updated. Login is required.