AKB# 50744 covers a problem where the Altiris Agent install page loads very slowly. This symptom occurs regardless of how you access the page (Actions> Agents/Plug-ins> Push Altiris Agent) or (Settings> Agents/Plug-ins> Altiris Agent). In my environment I started seeing upwards of seven often 10 minute load times for the push screen, unacceptable by any standard. The KB talks about a stored procedure that is used to help populate the data in the grid on the install page. The article goes on to explain that in testing this SPROC was taking approximately  5 minutes to run, similar to the times I was seeing.

The article then discusses the evt_aex_agent_push_status table, this is where information about computers you add to the grid to install the agent to is stored. I found on my installation of SMP 7 SP4 that this table was named evt_aex_push_status with the word ‘agent’ removed. There are 2 solutions to this issue, the one prescribed in the KB article is the faster of the two.

1.) Truncate the evt_aex_agent_push_status or evt_aex_push_status table. This clears the data from the table and the SPROC should complete in seconds rather than minutes which translates directly into a much faster load time in the console. It is important to note the use of truncate here and not delete. ‘Deletes’ in SQL Server are logged and so running a delete against a table with a lot of records isn’t advisable (unless you have all day). Secondly, and perhaps more importantly, a truncate can be rolled back.

2.) If you wait the painful 5-10 minutes for the Agent push screen to load, clear all computers out of both the Windows and (more importantly) the ULM (unix linux mac) push tab. It seems as though ULM computers cause this more than windows devices.

The reason for this post is to add the following code that you can use to create a stored procedure (SPROC) of your own to truncate the aex push data table. Paste the following code into SSMS or your tool of choice.

USE Symantec_CMDB
CREATE PROCEDURE [dbo].[usp_TruncateAeXPushStatus]
TRUNCATE table Evt_AeX_Push_Status

This will create a SPROC called ‘usp_TruncateAeXPushStatus’ that you can then execute to truncate your push status table in the event that this should happen again. The SPROC might be overkill since you are typing ‘exec usp_truncateaexpushstatus’ instead of ‘truncate table evt_aex_push_status’ but hey, I saved you from typing some underscores.

Keep in mind you have to have the proper permissions to truncate tables and this also fixed another issue I was having where it was taking five minutes or more just to add a ULM computer on that screen.

I recently had the displeasure of getting a 0x7E blue screen while trying to deploy our WinXP SP3 HI image to a couple of HP-Compaq NX6125 laptops. We use HIIS from Altrinsic Solutions and I thought perhaps that HIIS was trying to inject a HAL that was incorrect so I went into the driver management screen and ended up trying 3 different HAL files, none of which worked. After contacting Altrinsic support they were happy to share some information related to the 0x7E issue.

0x7E has a few root causes, mine happened to be that my HI image was built in VMWare running on an Intel processor and I was trying to send the image over to an AMD based machine. The technical details are as follows:

  • DS 6.9 SP3
  • Windows Server 2003 Std. SP2 (x86)
  • HIIS

The fix is pretty straightforward as long as you’re comfortable with REGEDIT.

  1. Open Image Explorer on the DS and within the image navigate to C:\WINDOWS\SYSTEM32\CONFIG.
  2. Find the file named “SYSTEM”, it has no extension. This is a registry hive.
  3. Right click the file and choose extract and send it out to the desktop of the DS. Do not close Image Explorer, you will need to replace this file later.
  4. Launch REGEDIT on the DS and select HKEY_LOCAL_MACHINE and go to File> Load Hive, browse to the desktop and select the SYSTEM file you exported from the image in the previous step.
  5. A dialog box will prompt you to name the hive, I used “temp”. Once you load the hive, expand the HKEY_LOCAL_MACHINE and then expand your TEMP hive.
  6. Under the temp hive, find the “Select” folder and click once on it. In the right pane of regedit you should see some keys with their values such as: Current, Default, Failed, and LastKnownGood. What you are looking for is the value of “Current,; mine was 1.
  7. The value of Current is going to relate to which “CurrentControlSet” folder you need to open. Since my value for Current was 1, I opened the CurrentControlSet001 folder. Expand the CurrentControlSet00Y (where Y is the value for “Current” in the previous step) folder and then expand Services.
  8. Scroll down through the list of Services until you find “intelppm” and single click it. In the right pane you see several items, one of which should be “Start”. In my case, the value of Start was (1) which means the Intel driver is enabled; this was my problem.
  9. Double click on the Start value and change it from 1 to 4 (leaving Hexadecimal selected). Once that is complete, collapse the TEMP hive and go to File> Unload Hive and confirm you wish to unload it.
  10. Close regedit and then drag the SYSTEM file from the desktop of the DS (the one we just made a change to) over into the C:\WINDOWS\SYSTEM32\CONFIG directory within your image using image explorer and confirm your wish to overwrite the current SYSTEM file. Finally, close down Image Explorer and retry your image job.

What this does is disable the Intel PPM driver from loading during startup. My image deployed perfectly after this change was made.

One important thing to note: When you deploy this adjusted image to an Intel based machine, the registry value we changed will be flipped back to 1 or the keys/values will be recreated so that everything functions properly. There is NO need to create deploy jobs both processors.

That wraps up this post and I hope that I’ve given you enough information to fix your issue. Another cause of the 0x7E BSOD is if you are attempting to use a HAL file collected from XP SP2 on an image that is SP3, you sometimes run into issues there. If you haven’t checked out HIIS, give the demo a try.

More Content Soon!

February 17, 2009

I will be publishing more content very soon out to The Juice. I will be sure and link to it from here. Thank you to everyone who has contacted me regarding #3 for the Hardware Independent Imaging article, it is on the way soon!

Busy Busy Busy!

October 16, 2008

Have been so busy lately with work and things we are doing there. Binding macs to the domain, gathering advanced inventory of them through Inventory tasks from the notification server. I have the 3rd piece of the imaging series as well as another article for updating the ProcessorDesc.ini file to add descriptions for newer processors.

Should have these articles to the juice in the next week… so sorry for the long delay on the imaging article.

In other news, I have passed my Notification System Foundation exam with a 96% 🙂

This Altiris Juice article that I’ve written details the differences between using “model_num” and “prod_name” when doing hardware independent imaging. You can view the post here. Be sure to read dfrancis’s comment at the end of the story, very interesting.

I have started a 3 part series on the Altiris Juice website that cover building a master image. You can find part 1 here. You can find part 2 here. Part 3 is finished but has not been uploaded or published on the site. More to follow!

My article covering the installation of the NS and DS agents for Macintosh has been posted on The Juice. Here is an excerpt

“Macintosh information for Altiris is a little sparse and I’ve often been left in the cold with questions. Hopefully this article will help guide those who are trying to get Macs to show up in the Deployment Console.”

You can read the rest of the article here.