Client Management Suite

Before the Altiris knowledge base was moved over to SymWISE there was an article #50744 that covered some performance issues with a stored procedure that is called when you add computers to the Agent Install Page in the CMS 7 console. I've tracked the article down in SymWISE and you can find it here. What causes the Agent Install Page to take ages to load is the entries that get written into the evt_aex_push_status table that contain data on the status of pushes to computers. Each time you add a computer to the grid the sproc runs to get any historical data about previous pushes to that computer; after awhile the table has many records in it and the Agent Install Page will take several minutes to load and in severe cases it can even begin to exceed the default IIS hard timeout and fail to load at all.

Solution

The solution as outlined in the SymWISE article is to truncate the table (remove all records). It's important to note that we're using TRUNCATE and not DELETE. If you want some clarification between the two you can check here. The basics of TRUNCATE is that the removal of the records is not written into the transaction logs and is faster. From my own testing I've found that this not only fixes the Windows side of the Altiris Agent Push screen but also the ULM (unix/linux/mac) side of the grid as well. 

Every time your page gets slow you can launch SQL Server Management Studio and login to an account with the proper access and perform the truncate table command, this isn't an optimal solution to the problem. In my first 'band-aid' solution to this problem I created a stored procedure that will truncate this table, mainly so I didn't have to type the table name every time. The code below will create a stored procedure you can execute to truncate the table:

USE Symantec_CMDB
	SET ANSI_NULLS ON
	SET QUOTED_IDENTIFIER ON
	GO
	CREATE PROCEDURE [dbo].[usp_TruncAgentTbl] --feel free to rename the stored procedure here
	AS
	SET NOCOUNT ON
	TRUNCATE TABLE Evt_AeX_Push_Status

This solution existed in my environment for about a month or so when one of the techs IM'd me to let me know that the Agent Install Page was starting to get sluggish again. Quickly realizing that I didn't want to own this problem and be responsible for "putting out the fire" every time the page was slow, I set out to setup a Workflow that would allow the technicians to fix the problem themselves.

The workflow is pretty straightforward, it's a Webform project with 3 components (excluding start/end). First I drug out a form builder component and added 2 buttons "Fix" and "Cancel". I then linked "Fix" to a stored procedure execution component that I generated using an integration library with my SQL server (remember I created the SPROC earlier). I then added one final form builder component on the successful execution of the sproc to tell the technicians that the task has been completed. If the page becomes slow now a technician can visit a URL and click the Fix button and have the table truncated and they never have to worry about whether or not I'm around to fix it. I've included a screenshot of the overview of the Webform project, see below:

I also went ahead and attached my workflow project, be sure you replace my "annotation" component with an execute stored procedure component that you can generate through an integration library with your SQL server.