Based on demand I have updated both the PatchAutomation [1] and ZeroDayPatch [2]downloads with a few additional features that allow the user to better control which bulletins are handle and how to invoke the tools.

Here are the new feature command line details:

/config=<file path>
    Reads the file at the provided path and parses each line for com-
    -mand line options. Here is a sample config file content:
      /severity=critical
      /custom-sp=CWoC_GetAllBulletins
      /vendor=google
      /dryrun
      /debug

/custom-sp=<sp_name>
    This option allows the user to specify a custom stored procedure to
    be called during the execution. The stored procedure may be present
    on the database (if not the automate will return with no errors) and
    must contains the following columns that are used and needed:
      * _resourceguid [Software bulletin guid]
      * released [Software bulletin release date]
      * bulletin [Bulletin...

Best Practices articles of Symantec Software Management 7.1

Symantec Software Management 7.1 Best Practices, Part 1
 
https://www-secure.symantec.com/connect/articles/symantec-software-management-71-best-practices-part-1
 

Symantec Software Management 7.1 Best Practices, Part 2
 
https://www-secure.symantec.com/connect/articles/symantec-software-management-71-best-practices-part-2
 

 
Symantec Software Management 7.1 Best Practices, Part 3
 
https://www-secure.symantec.com/connect/articles/symantec-software-...

I have a customer that has some problems with one of three child servers, with some serious memory consumption there going from 2 GiB for TaskManagement, ~2.5GiB for AeXSvc and anything above that (sometimes 5GiB+) for the Altiris-NS-Agent.

This is causing some serious troubles obviously, as the CPU are all clogged up (95~100% on 24 real cores). So first we reduced the overall impact by limiting the number of CPU's the process is allowed to on (using advanced setting and processor affinity mask).

And then we took a few dumps to see how the memory gets up to 4GiB or more...

I'll detail the WinDbg commands (and how to load mscorewks via sos.dll) but here's the over view running DumpHeap -stat at various stages.

Note! Here are the field names used below in order, Memory address, object count, total size, object type. The listing is sorted by size ascending. So the interesting data is at the end.

...

Update! Added the Dataclass and Filters top level items as they also needed fixing. Also I added a reference to my original SP1 to SP2 upgrade post, with steps for fixing the issue [1].

####

I attended an upgrade for a customer installing MP1.1 on 4 servers in hierarchy (1 parent, 3 children). We had some minor problems when we got started but nothing major:

• 2 servers (including the parent) did not have the MP1.1 upgrade option because SMP 7.1 SP2 was not appearing as installed in SIM. We just ran the upgrade as a new installation.
• The parent configuration went much to fast to be healthy. In effect it did not install most of the products, so we ran the "aexconfig /configureall" manually and this fixed the environment
• One role had been granted undesired rights (inherited from the hidden parent folder)  on main console locations: "Reports", "Console menu", "Settings"...