KNOWN ISSUE: Application Control service appears to be causing slow boot-up times and sometimes causing services to timeout

Article:TECH42139  |  Created: 2009-05-21  |  Updated: 2009-07-30  |  Article URL http://www.symantec.com/docs/TECH42139
NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.
Article Type
Technical Solution


Issue



After the Altiris Application Control (ACS) Agent gets installed onto a system, several of the services fail to start.  The microsoft system event logs record "The service did not respond to the start or control request in a timely fashion" which ends up being 30 seconds.

Additionaly Additionally system appears to take a lot longer to boot and in some cases the system appears to run much slower.

The issue is confirmed by the fact that disabling other serivces services has slow boot issues and only after "Altiris Application Control" service is disabled does booting return to normal. 

The ACS.log will contain several warrning warning like...
Process TotalProcessing timespan exceeded for Process <process id> 

The Agent.log will contain even more informational messages like...
Unable to update ClientItemRequest <item guid>. Error 5 (The database file is locked):


Environment



Altiris Application Control Soltuion 6.1 and 6.1 sp1

Cause



A local Client Item database kept on all ACS systems is used to store all filters, actions, and inventory collections that need to be used by the ACS agent.  The Notification Server maintains the master of all these items.  When a new ACS policy is created, the policy references any number of these filters, actions, and inventory collections.  After the policy is downloaded by the Altiris Agent, the ACS sub-agent sees the list of filters, actions, and inventory collections with its policy, it marks an interest in those items.  All items marked with an interest must be downloaded from the NS server and stored in the local client item database. 

The occurs when this process gets locked up at the same time that the same items are trying to be utilized by the ACS agent to monitor applications.  With a small number of items that must be maintained this does not present an issue at all; however as the number of items grows or the size of the synchronized inventory collections becomes very large, then the chances of locking occurring increase considerably.

Once locking of this local client item database begins is causes delays in the monitoring process which in the end put delays on services starting up and a overall slower bootup.

Solution



In most cases the issue can be resolved by going over the ACS implementation and looking for the ways to decrease number and size of items that need to be replicated to the local client item DB.

Client items that must replicate are determined because they are used within Application Control Policies.  This makes looking through all of the enabled ACS policies very important to try to identify places where the number of filters could be decreased or find an Inventory collection that might be too large.

Look for redundant filters within the same part of the policy.  That  is see if one of the filters being used is actually a sub-set of another filter being used.  Example "Executables in Windows Directories" is a sub-set of "Executables in Windows Directories (All executable types)" which itself is a sub-set of  "Default File Specification (All executable types)".

Look for inventory collections being used in a ACS policy that include a very large number of File resources within that collection.  This is typically caused by a broader number of files that have been scanned and placed into a collection (either automatically through a reference policy or through manually into a security rating collection) because the scan policy had been configured to not only scan executable type files, it was also configured to find every type of file and thus the resulting inventory collection ends up in the thousands.  Because ACS only monitors executing processes, the inventory collection used by any policy should only include files that are executable files.  In the end this should only be files that ultimately use the "Program File Executables" filter.  As such the resulting collections should be in the hundreds of files and not thousands of files. 

Look to see if the use of one filter may take the place of other multiple filters.  Sometime file inventory filters are overlooked.  For example one of the file inventory filters is "Present in Signed Security Catalog" which are files that have been digitally signed.  In most implementation this one simple filter can be used in the place of several filters that where targeting applications that are signed and therefor already known to be trustable.  Although not all applications are signed, using this filter will eliminate the need to target so many.  This is also a good filter to use to exclude for the file inventory scan process. 

Finally implementation is the use of  ketch all policies can really help decrease the number of policies and its filters.    Most ACS policies are configured so that once an application is found to be applicable to the policy, that that application should not process any other ACS policies.  This would include the likely hood of having ACS policies that have no action, but still stop processing the remaining ACS policies.  This makes it easy to build a type of a sifting process where known and trusted application can be targeted in earlier policies and then having a "Ketch All" ACS policy that will be ready to apply an action to any application that was not otherwise applicable.  A typical "Ketch  All" ACS policy would have a high priority (like 99), would be marked to run at stage 2 (after the process and its parent process have already been evaluated), and would target all applications but with an exclusion of Local System and Service Applications (to be on the safe side).  The action would then be to either Remove Administrative Rights or Deny Execution depending on the level of your security implementation.  As a note, a ketch all to deny execution makes for a really secure environment, but requires a more comprehensive list of filters to target wanted applications so that the desired applications don't inadvertently become blocked.  Remove Administrative Rights on the other hand only forces an application to run without administrative capability thus keeping any application in check.  This then only requires a higher ACS policy that will be applicable to just applications that really need administrative rights for which there are a lot fewer of.  Once you have the ketch all policy, any new undesired application that is introduced will not only not need to be targeted specifically, but will still be trapped because it does not meet any of the other ACS policies. 

The Microsoft KB 922918 to increase the default timeout value for the service control manager. http://support.microsoft.com/kb/922918
Following the KB will double (30000 to 60000 milliseconds) the amount of time that the Application Control Service has to allow the service applications to finish despite being held up by the locking issue. 

In some cases the number of filters needed in a specific implementation has been limited as much as possible due to the implementation requirements.  As such Symantec is also working on this issue to better handle the client item management to avoid this locking issue even with a higher number of client items. 

Please subscribe to this KB as it will be updated as more information become available about this issue and possible resolutions.


Supplemental Materials

SourceDEFECT
ValueOEM 47256
DescriptionLogged in OEM (Altiris - Partner Product) database

Legacy ID



47256


Article URL http://www.symantec.com/docs/TECH42139


Terms of use for this information are found in Legal Notices