SecurityCacheMaximumTrusteesPerItem setting gets maxed out frequently
|Article:TECH41616|||||Created: 2009-03-10|||||Updated: 2009-07-28|||||Article URL http://www.symantec.com/docs/TECH41616|
Because of heavy Software Portal use, the Coresettings.config "SecurityCacheMaximumTrusteesPerItem" setting gets maxed out frequently. This causes the Altiris Console to become unusable until the value is increased. See KB 20372. Is there was a more permanent fix for this?
NS 6.0 Sp3 R9
A Security Trustee is created for each user that longs into the Software Portal. Heavy portal use can quickly cause the number of Security Trustees to exceed the SecurityCacheMaximumTrusteesPerItem setting in the Coresettings.config file. Setting the SecurityCacheMaximumTrusteesPerItem high can relieve this issue, although as the number of entries in the table grow, it can cause performance issues in generating the console pages.
Increasing SecurityCacheMaximumTrusteesPerItem to a managable level is always the best option, although if it seems to cause a performance issue, then cleaning up the security trustees so that the only entries contained in the database are those that are actually being used is an alternative. Unassociated security trustees created by Software Portal usage can be removed using the attached stored procedure. Please note that this option is supplied as-is, and issues with it cannot be handled through Symantec support. As this process directly removes security entries from multiple tables in the database, always back up the database in case unwanted results happen.
What the stored procedure does:
When a user logs into the Software Portal, the users SID is looked up in the usersettings table in the database. If it doesn’t exist, it adds it. It then looks up the Software Portal domain\name item in the Item table. If it doesn’t exist, it creates it and then creates an entry in the securitytrustee table for the user.
The sql script creates a stored procedure called spdelSWPortalUsers. When it runs it will scan for any SecurityTrustees that are the parent of ONLY the domain\name software portal item entry in the item table. These SecurityTrustees that are no longer associated with any other item can safely be removed.
The stored procedure removes the guid for the domain\name software portal item and the SecurityTrustee guid from the database. If the user logs into the portal AGAIN the user's SID is looked up in the usersettings table. It should already exist. The process then looks up the domain\name item in the item table. Since it doesn’t exist it will create a new entry in the item table and a new security trustee entry in the securitytrustee table.
It is possible to orphan a securitytrustee guid with this process. If the user logs into the portal and before the user makes any selections the spdelSWPortalUser stored procedure is ran, the securitytrustee guid and the domain/user item for the user will be deleted. As the user makes portal selections, a new securitytrustee guid is created and associated with the software portal packages but it will NOT have a user\domian software portal item associated with it. The software portal still works normal from the user's standpoint. Once the user runs the task and the software portal items deleted through the software portal purge mechanism, the securitytrustee will remain without any associated items. These orphaned securitytrustees won’t be deleted through this process.
If the user logs back in to the portal, a new domain/user Software Portal item is created and reassociated with the securitytrustee guid however.
Once this query has successfully ran, run the "Select count(*) from securitytrustee" and compare the results with the SecurityCacheMaximumTrusteesPerItem Coresettings.config setting. You should be able to adjust this setting downward. This should improve console performance.Attached also is a Notification Policy that would send an email notification when the SecurityCacheMaximumTrusteesPerItem setting value is close to the number of Security Trustees in the database. It will need to be modified and tested to accommodate your requirements.
If you find you need to do this on a regular basis, a SQL task to execute this stored procedure can be created to run on a regular basis (exec spdelSWPortalusers). Run it at a time and day that users are unlikley to access the portal.
Article URL http://www.symantec.com/docs/TECH41616