Symantec Management Platform 7.0 SP1 Hotfix 2 Release Notes

Article:TECH41426  |  Created: 2009-02-12  |  Updated: 2009-05-28  |  Article URL
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


What do I need to know about the Symantec Management Platform 7.0 SP1 Hotfix 2?



Known Issues in this Release

Resolved Issues in this Release


This document contains information about the issues that were resolved in the SMP 7.0 SP1 Hot Fix 2. To see the issues that were resolved in the SMP 7.0 SP1 Hot Fix 1, see SMP 7.0 SP1 Hot Fix 1 Release Notes.

Known Issues in this Release

The known issues in this release are fully described in the Symantec Management Platform 7.0 SP1 Release Notes.

Resolved Issues in this Release

Task Server


Resolved Issue

Defect ID
The Task Server Install and Upgrade polices should be disabled by default

During a migration from Task Server 6.0 to Task Server 7.0 SP2, remote task servers were being uninstalled and left in that state until user-intervention. To resolve this specific issue, the scope of the filter used for Task Server uninstall has been narrowed so that the correct computers are targeted.


Web Controls


Resolved Issue

Defect ID

GridControl not releasing memory during refresh

GridControl had a memory leak issue only when UseInternalGridCallback property was set to false. This is because in this scenario, the GridControl uses a callback to bring down an entirely new CA grid on each refresh, without telling CA to dispose of its resources before triggering the refresh callback. The change was a 1 line change to tell the ca grid to dispose its resources before the callback takes place. Memory usage when UseInteralGridCallback == false is now more of a flat line rather than a constantly increasing amount.


Symantec Installation Manager


Resolved Issue

Defect ID
Unable to upgrade to HF2 after installing HF1 and SMS with rtm product listing

SIM was originally coded to require dependent products to explicitly call out the fact they are compatible with a newer version of a product by adding a dependency (with the same group ID) to the new product. We have changed the design now to assume that superseding packages are always backwardly compatible and satisfy the requirements met by the old dependency.


Cancel button on uninstall prompt for dependent items does NOT cancel the uninstallation

When the user chooses to uninstall s/he may be presented with a dialog explaining that with that particular selection additional components will also be uninstalled. However, if the user chooses the Cancel button on this dialog, the uninstall proceeds anyway.

Uninstall of the solutions fails in case when Solution contains several packages. (also addresses uninstall issues with Add/Remove Programs)

The productconfiguration.UnconfigureProduct web service was being used incorrectly, allowing more than one unconfiguration operation execute at the same time. A change was made to ensure that SIM will not allow a subsequent unconfiguration to occur until after the previous one has completed. (We poll configuration status and wait for a completion status before we continue now, using the same polling model as configuration) 2nd Reason: We were setting the HKLM\SOFTWARE\Altiris\Aim\InstallInProgress registry value to 0 during an uninstall causing exceptions because AeXConfig checks this registry value before it performs any work. Changes have been made in PerformInstall.RepairProducts(), PerformInstall.InstallProducts(), and PerformInstall.UninstallSingleProduct() to ensure that the value is only set once prior to these operations, and once after they have completed, to ensure that this value remains set to 1 while SIM operations are in progress.
Problems uninstalling SP1 HF1

Fixed problems in SIM code with uninstalling the Platform itself when the HF1 was applied. Services were still running in some cases when they shouldn't have been which was the root cause of the service shutdown and reboot notifications reported in this bug.

Repair of Platform hangs at 26% on 33 of 61 components

The repair of the platform is now disabled when updates to it are installed.

CMS "repair" stumbles on altiris_discoverytasks_7_0_x86.msi's present

Suppressed reboots during repair. Changed repair initiated from the UI to only repair missing or older files. Repairs due uninstall of updates still perform a full repair that replaces the files from the previous revision level.

DMC build 7.0.27 throwing "Fatal Exception" message while installation

Occurs infrequently, but crashes install when it does. Removed conn.Close(); statements inside of a Using block inside SQLAuth.




Resolved Issue

Defect ID

Implement Connection Profile Caching

Caching with a timeout was added to the connection profile manager. This means that when a connection profile is retrieved with its associated credentials, it is cached in the profile manager for a specific amount of time (defaulted to 300 seconds). When the connection profile is accessed, the timestamp of the retrieval of the CP (connection profile) is checked and, if it has expired, the CP is retrieved again from the database. If not, the cached CP is retrieved from memory.

The Symbol protocol plugin requires an active session to communicate and to receive command instructions. If a session is lost, all subsequent commands will fail to execute and will return and error.

From Symbol SDK documentation - In order to properly manage its network resources, the controller firmware will automatically terminate client connections that have been idle for some predetermined amount of time. This cleansing mechanism provides key resource preservation capabilities in the TCP environment. Without it, connections associated with clients that were abruptly terminated would simply accumulate undetected and use up precious controller network and memory resources.  PPA has been modified to avoid this situation and keep the connection open.


A WSMAN session can “hang” if targeted device does not respond to a TCP or HTTP request. In particular this can happen with the Network Discovery process if one or more devices are not responding.

No server response to requests due to environmental and system issues such as a slow network or incorrect connection parameters. Adjustments to how PPA handles the connection resolve this issue.


Event Console


Resolved Issue

Defect ID

Purge policy needs to exclude unresolved Monitor alerts

The current purging architecture allows unresolved alerts to be purged. In the case of Monitor Solution, if an alert that is unresolved is purged, it leaves the agent in a triggered state because Monitor Solution relies on a Notification Server Message indicating a resolution so agents can be reset. When an unresolved alert is purged(deleted), Monitor Solution does not get the message so the agent remains triggered and will not send another alert. On the server, Event Console displays the health as normal because the alert was deleted. The fix adds restraints to the Purge logic to prevent the purging of any unresolved Monitor Solution alerts. This does not apply to SNMP traps. The caveat is that the user needs to respond to every alert, manually or automatically, before the Monitor Solution alert can be purged.

There is huge memory usage of Event Reciever service during receiving WS- MAN heartbeat events

High volume alert flow was causing memory usage to rise and stay up until the alert volume droped (allowing garbage collection to catch up). We added an interface to the alert object to allow it to be disposed more efficiently. We also added a call to the garbage collector on a timer (when alerts are being received).

Condition "Time of day" is not working for 'Forwarding' and 'Tasks' rules

Alert Forward Rules and Alert Task Rules with Time of Day conditions were evaluating incorrectly due to a UTC timestamp comparison against local server time. The alert is now converted to local server time prior to Forward/Task rule evaluation.

EventEngine/EventReceiver services running out of memory

On Notification Servers with several thousand or more managed resources, the ResourceKey table grows very large. An Event Console query was not constrained to reduce the result set to a manageable size. The stored procedure was altered to include a where clause limiting the result set to needed rows. Impacted Regions: The EventEngine.exe and EventReceiver.exe Event Console services both use this query to match alerts to resources as well as evaluate alert rules.


Network Discovery


Resolved Issue

Defect ID

"Data Can Not Be Loaded" error when adding SNMP Device Classification

When we added a new table field in HF1, we missed modifying one of the existing stored proceedures that references this table. This caused any attemped modification on our Device Classification page to fail.


Correlation fails when servers with an existing Altiris Agent is discovered

The correlation logic was changed so existing devices can be correlated.


Monitor Core


Resolved Issue

Defect ID

Several previously localized strings are showing in English in version 7.0.3018

25% of the strings were not translated due to a string submission issue. This has been corrected.

Health event propagation from Monitor metric file to the user interface is excessive

Monitor alerts are individually sent to the Notification Server using NSE. This proved to be inefficient during scalability testing. Now the alerts are sent to the server in Bulk to improve performance.

On-demand status polls are getting dropped

There was a synchronization bug where OnDemand requests would not properly prioritize metric polls, causing metrics to not get polled and evaluated when expected. This was exposed during OnDemand scalability testing.

NT event templates trigger on any appearing NT event even if it does not fall under this template

During migration from 6x to 7.0, the NT Event metric would be set with the wrong data type. This would cause any NT Event to be processed and cause a rule to trigger during rule evaluation, rather than only NT Events that satisfied the rule criteria. The correct data type is now being set.


Legacy ID


Article URL

Terms of use for this information are found in Legal Notices