Symantec Management Platform (Notification Server)

Hi,

We are seeing the same problems on our clients, not being able to get the client policy from the SMP server. To answer some of the questions asked before:

- Clients and server are on the same version.
- I've increased the Policy Request interval from 2 to 4 hours
- I've increased the Basic Inventory interval from 4 to 8 hours
- Full inventory is set to Monthly (with custom subset of the default selected options)
- Delta inventory is set to Weekly (with custom subset of the default selected options)
 

At the moment we have about 2500 clients connected to the SMP which is a nice server (dual quad core with HT and 32 GB of RAM). It's only using maximum 10% of CPU most of the time and 20% of physical memory (6.5 GB of RAM). So I don't think it's the SMP server HW that's slow.
On SQL part, this is running on SQL 2005 on a seperate box shared with other (smaller) db's in a seperate instance with 6GB of RAM.

What I already did on IIS part to get some extra performance on the SMP box is to split of Altiris/NS/Agent in it's own Application Pool, as well as the ClientTaskServer application. Because of these, the mem usage is now at 20% otherwise it would be even less (13%).

But still, when I access the GetClientPolicies.aspx page for a specific machine GUID, I get the error below.
GetClientPolicies.aspx request:
http://<SMPservername>/Altiris/NS/Agent/GetClientPolicies.aspx?xml=<request configVersion="2" compress="0"><resources><resource required="true" host="true" guid="{799CC8E3-B8C9-4FCB-B278-3C115F8959B8}"/></resources></request>

Resulting error message:
<error number="8004200C" nsVersion="7.1.6851.0">
<![CDATA[The maximum number of client policy requests has been reached]]>
</error>

Any ideas, hints, tips are welcome!!

Ben

Have you tried removing the agent on a problem client and reinstalling using push from the NS?  Does this work for that client?  If so, what about just restarting the client service or similar?

You could try modifying the NS using NSConfigurator to increase the number of concurrent config requests.  The tool is located at C:\Program Files\Altiris\Notification Server\Bin\Tools and you can search for 'maxconcurrent' and then Show MaxConcurrentConfigRequests and change it to something like 50 or 100.  Then restart IIS and see if the errors are resolved.

Hi Mike,

Thanks for the quick feedback.

Removing the agent is a bit impossible as I see this behaviour on a lot of clients. I have not checked all 2500 clients of course, but every single one I checked is unable to get an update of it's configuration.

The nscap queues are handled nicely, no problem there.

I then tried the MaxConcurrentConfigRequests you mentioned and this was on the default 10 connections. I changed that to 100, but this has no improved behaviour as well.

What I do see is that when I recycle the Application Pool that contains the Altiris NS Agent part, the first couple of clients that update their config get it fine. So it seems that after a certain amount of connections (or whatever) the app pool gets saturated or something and then does not handle new requests properly anymore. I can try to set the recycle time to 5 minutes or so, but I can't imagine that this is best practice and it's not a real solution to the problem.