Issues when upgrading from 7.0 Release Candidates to the 7.0 Final Release version

The following issues contained in this table cell are only applicable when upgrading from 7.0 versions. These issues do not apply to upgrades from 6.x versions.  

Customizations made to Monitor Server Settings and the Remote Monitor Server Settings are not preserved

After upgrading you must update Monitor Server Purging Maintenance Settings and Remote Monitor Settings. These settings are not migrated.

You can export custom policy and agent settings before upgrading

Some items may be lost when upgrading from 7.0 Release Candidate versions. It is possible to preserve custom items (including monitor policies, server settings, and Remote Monitoring Server settings). To preserve custom items, you can export them to .XML files before you upgrade, and then import the .XML files following the upgrade. 

To restore console elements, you import them from the appropriate .XML files. Console elements are identified by their GUIDs. Elements in the imported .XML file overwrite existing elements that have a matching GUID. Any elements in the .XML file that do not have matching GUIDs in the console are added as new items.

Note: You need the Import XML privilege to import .XML files. By default, only the Notification Server administrator role has this privilege.

Note: This functionality is only supported for 7.x to 7.x upgrades. This task is not supported when migrating from Monitor Solution 6.x to Monitor Solution 7.x.

To save a console element as an .XML file:

1. In the left pane, click the tree node that you want to save.
2. Right-click, and then click Export.
3. In the Destination File for Exported XML dialog box, specify the XML file name and location, and then click Save.

To restore a console element from an .XML file:

1. In the left pane, select the folder to which you want to restore the element.
2. Right-click, and then click Import.
3. In the Choose the XML File to Import dialog box, select the appropriate XML file.
4. If you want to prevent any changes from being made to the imported element, check Open as read-only.
5. Click Open.

Run once ASAP requires manual modification of Agent Upgrade package to work

This issue only occurs in the following scenario:

• You migrated from a Monitor 7.0 Release Candidate version to the Monitor 7.0 Final version.
• You uninstalled the Monitor Solution 7.0 Release Candidate version, then you installed the Monitor Solution 7.0 Final version, and then you reconfigured the database.
• You installed a Monitor Solution 7.0 Release Candidate version of the Monitor Agent, and you clicked the Run once asap option in the rollout policy.

For agents to be installed using the "Run Once ASAP" feature, you must manually modify the agent package. This notifies the Altiris Agent that a newer version of the Monitor Agent package is available.

To workaround this issue by manually modifying Monitor Agent Packages:

1. On the Notification Server computer, navigate to the directory where the package is located:
   C:\Program Files\Altiris\Notification Server\NSCap\bin\Win32\X86
   C:\Program Files\Altiris\Notification Server\NSCap\bin\Win64\x64
   C:\Program Files\Altiris\Notification Server\NSCap\Bin\Unix\Monitor\Linux
2. Create a blank .txt file in the folder.
3. Update the package's distribution points. 
4. Enable the upgrade policy.

102758

An import of 6.x items after an import of 7.0 items always overwrites

Following installation of Monitor Solution 7.0, if you first import 6.x monitor data and then you import a 7.0 Monitor Pack, then you have the option to enable or disable the overwrite existing items option.

However, if you first import a 7.0 Monitor Pack and then import 6.x monitor data, you do not have the option to enable or disable, and 7.0 Monitor items are automatically overwritten with 6.x.

Therefore, we recommend that when migrating from 6.x to 7.0, following the installation of Monitor Solution 7.0, first import your 6.x data and then import 7.0 Monitor Packs. You then have the flexibility to choose if you want to overwrite the existing items.

Referenced items are migrated

When migrating Monitor Solution 6.x items to Monitor Solution 7.0, modified items (such as policies, metrics, rules, and new monitor packs) are all migrated. If an item has not been modified, but the item is referenced by another item that has been modified, then the referenced item is also migrated.

For example, if you modified a rule, but not a metric that the rule references, then both the metric and the rule are migrated.

Monitor Server Purging Maintenance Settings are not migrated

Monitor Server Purging Maintenance Settings are not migrated from versions 6.x to version 7.0.

Collections that  are assigned to 6.x monitor policies are not migrated to filters in 7.0 monitor policies

If a specific collection is assigned to a 6.x monitor policy, the specified collection is not migrated to 7.0. This includes the following:

• All Linux Computers
• All Linux Computers (glibc2.2)
• All Linux Computers (glibc2.3)
• All Linux Computers (glibc2.4)
• All Linux Computers (kernel 2.4)
• All Linux Computers (kernel 2.6)
• All Linux Computers requiring Monitor Agent upgrade
• All Linux Computers requiring Package Server Agent Uninstall
• All Linux Computers requiring Package Server Agent Upgrade
• All UNIX and Linux Computers requiring Altiris Agent Upgrade
• All UNIX and Linux computers with Altiris Agent version less than 6.2 installed
• All UNIX and Linux computers with Monitor Agent installed
• All UNIX and Linux Computers with NS 6 Altiris Agent
• All UNIX Computers
• ESX Server Computers requiring Altiris Agent Upgrade
• HP-UX 11  (PA-RISC)
• HP-UX 11i (IA64)
• HP-UX 11i (PA-RISC)
• HP-UX Computers requiring Altiris Agent Upgrade
• Linux Computers requiring Altiris Agent Upgrade
• Red Hat 7.2
• Red Hat 7.3
• Red Hat 8.0
• Red Hat 9.0
• Red Hat Enterprise Linux AS 2.1
• Red Hat Enterprise Linux ES 2.1
• Red Hat Enterprise Linux WS 2.1
• Solaris  7 (SPARC)
• Solaris  8 (SPARC)
• All Solaris (SPARC) Computers
• All Solaris (SPARC) Computers requiring Package Server Agent Uninstall
• All Solaris (SPARC) Computers requiring Package Server Agent Upgrade
• All Solaris (x86) Computers
• All Solaris (x86) Computers requiring Package Server Agent Uninstall
• All Solaris (x86) Computers requiring Package Server Agent Upgrade
• All Solaris Computers
• All Solaris Computers requiring Monitor Agent installation
• All Solaris Computers requiring Monitor Agent upgrade
• All Solaris Computers with Monitor Agent installed
• SUSE  8.0
• SUSE  8.1
• SUSE  8.2
• SUSE  9.0
• SUSE  9.1
• SUSE  9.2
• SUSE  9.3
• SUSE 10.0
• SUSE 10.0 (x86_64)
• SUSE 10.1
• SUSE 10.1 (x86_64)
• SUSE Linux Enterprise Server  8
• All AIX Computers
• All AIX Computers requiring Monitor Agent installation
• All AIX Computers requiring Monitor Agent upgrade
• All AIX Computers requiring Package Server Agent Uninstall
• All AIX Computers requiring Package Server Agent Upgrade
• All AIX Computers with Monitor Agent installed
• All HP-UX (IA64) Computers
• All HP-UX (PA-RISC) Computers
• All HP-UX Computers
• All HP-UX Computers requiring Monitor Agent installation
• All HP-UX Computers requiring Monitor Agent upgrade
• All HP-UX Computers requiring Package Server Agent Uninstall
• All HP-UX Computers requiring Package Server Agent Upgrade
• All HP-UX Computers with Monitor Agent installed
• AIX Computers requiring Altiris Agent Upgrade
• All 32-bit Windows 2003 Servers
• All 32-bit Windows 2008 Servers
• All 32-bit Windows Desktop Computers
• All 32-bit Windows Mobile
• All 32-bit Windows Servers
• All 32-bit Windows Vista Computer
• All 32-bit Windows Workstations
• All 32-bit Windows XP Computers
• All 64-bit Windows 2003 Servers
• All 64-bit Windows 2008 Servers
• All 64-bit Windows Desktop Computers
• All 64-bit Windows Mobile
• All 64-bit Windows Servers
• All 64-bit Windows Vista Computers
• All 64-bit Windows Workstations
• All 64-bit Windows XP Computers
• All Clients With No Additional Agents
• All Non-Primary Package Servers
• All Windows 95 Computers
• All Windows 98 Computers
• All Windows 9x Computers (95, 98, Me)
• All Windows Computers requiring Monitor Agent upgrade
• All Windows Me Computers
• All Windows NT Servers
• All Windows NT Workstations

Custom collections associated with custom Monitor packs are not updated

Issues with migrating Monitor tasks/actions from 6.x to 7.0

The Generate SNMP Trap task and the Create Incident task are not imported from 6.x to 7.0 because they are not supported on version 7.0.

The Generate NT Event task is supported on version 7.0; however, settings made to this task are not preserved. Settings made to previously created Generate NT Event tasks are moved to the parameters field on 7.0. The following data appears: Altiris Monitor Solution for Event Source, 1 for Category, and 1000 for Event ID.

Issues with migrating custom Command metrics from 6.x to 7.0

When migrating  customized Command metrics, the metric's search patterns are not migrated correctly.
The search patterns must be manually adjusted after migration from 6.x to 7.0.

Known Issue when Upgrading Windows Monitor Agents

When a windows Monitor Agent is upgraded, it may be possible that the file that the Monitor Agent uses to write to the system event log is in use by Windows. If this occurs, then the file will not be upgraded until the next restart. The new file will be placed in the Monitor Agent's directory and will have a temporary (.tmp) file name. The operating system will not be automatically restarted, but Windows may prompt the user that a restart is necessary. If upgrading from BEIM to DMC, the agent upgrade will not be complete until a restart has occurred.

Issues with upgrading Agents when Notification Server is a new computer

When upgrading to a new Notification Server computer, there are issues with agent communications. After completing a data import, upgrading the Altiris Agent on client computers is unavailable. Although the 6.x client computers are displayed in the filter (Windows/Linux computers requiring Altiris Agent Upgrade), when the upgrade policy is applied, the upgrade fails.

The issues occur because the previous version of the Altiris Agent attempts to connect to the previous 6.x Notification Server computer instead of the new 7.0 Notification Server computer. Therefore, the 6.x agent is unaware that an upgrade policy to the 7.0 version is made available.

To workaround this issue you must manually redirect the 6.x agent to communicate with the new 7.0 Notification Server computer before you migrate to version 7.0:

1. In the Altiris 6.x Console, on the Configuration tab, click Roll out Altiris Agent > Roll out Altiris Agent Configuration.
2. In all the required policies (for example, All Desktop Computers, All Package Servers, All Unix Computers, etc.) on the Advanced Settings tab, enable the check box for Specify an alternate URL for the Altiris Agent to use to access the Notification Server.
3. Specify the server name and the URL of the new 7.0 Notification Server computer.
4. Refresh the Agent configuration on the client computers. 
5. Upgrade to version 7.0.

Monitor Solution 7.0 cannot be hosted on a Windows Server 2008 

Currently, the Symantec Management Platform, which Monitor Solution is installed on, does not yet support Windows Server 2008 as a host; this support will be added in a future release.

The Monitor Agent plug-in supports Windows 64-bit platforms  

The Monitor Agent includes 64-bit support for both Windows 2003 and Windows 2008 as a managed device.

You may need to install sysstat on your monitored Linux computers   

You must install sysstat on your targeted Linux computers to use the following monitor policies:

• Processor
• Disk I/O
• Memory

If you install the Remote Monitoring Server on a dedicated computer, the PPA agent and the Credential Manager are required

If you install the Remote Monitoring Server on a dedicated computer, the PPA agent and the Credential Manager are required.

Network Discovery found devices may not be listed in the targeted filters of the default agentless policy

Agentless monitor policies target filters of computers and devices. By default, the target only included unmanaged devices running Windows 2003 or 2008. When computers are discovered, the local operating system is a property of that computer resource. If during discovery, a computer's operating system cannot be determined, an operating system specific filter will not recognize that computer.

This is a possible cause if an agentless monitor policy is not running on a computer as expected.
Note: The operating system version is correctly discovered for target computers that have SNMP enabled.

Activated Monitor Policies web part only shows policies that the Monitor Agent has activated

A Monitor Agent must first activate a monitor policy before it is displayed in the Activated Monitor Policies web part of the Monitoring and Alerting home page. If you have enabled a monitor policy but it is not yet displayed in the web part, this may be the cause because the web part is populated from inventory data that is received from the agent.

Purging Log Event and Sys Log data

Both Log Event and Sys Log data purging is controlled with the single String metric data purging schedule.
To schedule string metric data purging:

1. In the Symantec Management Console, on the Home menu, click Monitoring and Alerting.
2. In the left pane, click Monitoring and Alerting > Monitor > Settings > Monitor Server Settings.
3. On the Monitor Server Settings page, click the Purge Maintenance tab.
4. Under Non-numeric Data, set the value for String metric data.
5. On the Monitor Server Settings page, click Save changes.

The Poll Metric on Demand task cannot poll agent-based metrics on a computer that does not have the Monitor Agent

The Poll Metric on Demand task can poll two different types of metrics: agent-based and agentless.It is supported on two different types of targets: with and without Monitor Agent.

If the Poll Metric on Demand Task is executed on an agentless target (the client computer without the Monitor Agent installed on it), then it can only poll agentless metrics on the client computer. Agent-based metrics are not polled on an agentless client computer as agent-based metrics require the Monitor Agent to run.

A failed heartbeat may not raise an alert if the Check for Heartbeats interval is less than the Send Heartbeat interval with zero retry attempts

If you configure the Monitor Server Setting's > Heartbeat tab's > Retry attempts value to "0" and the Check for heartbeats every interval to be less than or equal to the Monitor Agent Configuration Setting's  Send heartbeat every interval, then a failed heartbeat may not raise an alert in the Event Console due to network latency. In this case, a Monitor Agent may appear to occasionally go down only to come right back up again. However, the uptime data will not be affected in this case.

There are time drifting issues when monitoring heartbeats on Linux computers that are hosted on VMware

When monitoring Heartbeats on Linux computers that are hosted on VMware, there are issues with time drifting.
This issue can cause heartbeats to be received by Notification Server after a very long delay and an alert to be raised in the Event Console.
To avoid issues with unnecessary alerts in the Event Console, make sure that your heartbeat time settings are synchronized to account for possible time drifting.

Alert Severity from Timed rules is always "Informational"

Alerts that are generated by timed rules always have an Informational severity level. Even if you change the severity of the alert in the Event Console, the next time the alert is received the severity is reset to Informational. 

HTTP metrics do not support virtual hosts

The HTTP metric cannot be used with virtual hosting. The HTTP metric only supports the use of the current hostname of a physical computer that reports basic inventory to the Notification Server computer. 

There is a specific setup required to enable Smart Metrics using SNMP  

To enable Smart Metrics using SNMP:

• The SNMP service must be installed on the monitored computer.
• The community name must be configured in the SNMP service on the monitored computer. The community name must match the community string in the SNMP protocol settings for your connection profile.
• SNMP packets must be accepted from any host in the SNMP properties on the monitored computer.

If two WMI metrics are configured to parse the same command output and they both have different polling intervals, these metrics will read data with the lowest polling interval. The WMI metrics combine into a similar query for optimization. The query runs at the lowest interval setting.

When "Altiris" log type is selected, the Log Event metric only supports Windows platforms

When the "Altiris" log type is selected, the Log Event metric uses the Notification Server log file as source. This type of log is supported for Windows platforms only.

The reports “Alert History” and “Most Active Hosts” are located in the Event Console Reports folder 

The 6.x reports:

• Alert History by Monitor Agent
• Alerts Over Last 'N' Days
• Monitor Agents with Most Alerts

Are now replaced with:

• Alert History
• Most Active Hosts

These reports are located under the Event Console Reports folder on the Monitoring and Alerting portal page.

There is a delay in the Computers Lists for the Real-time and Historical Performance Viewers 

Computers are not populated in the Computers List for the Historical and Performance Viewers until data is received from the target computer by Notification Server.

Issues with agentless monitoring  

• If you first discover a computer, and then change either its computer name or its IP address, then attempting to monitor that device will fail.  
• It is possible that an agentless monitoring policy will not stop monitoring, even after the policy is disabled. 
• The Remote Monitoring Server cannot be installed on 64-bit platforms; therefore, agentless monitoring cannot be performed from a 64-bit computer. 
• In the Event Console, the Remote Monitoring Server will be shown as the source of an alert, even if the alert is raised by a monitored agentless resource.
• The monitored computer must be specifically set-up to enable SNMP agentless metrics:

1. The SNMP service must be installed on the monitored computer.
2. The community name must be configured in the SNMP service on the monitored computer. The community name should match the community string in the connection profile SNMP protocol settings. (From the Symantec Management Console, click Settings > All Settings > Solution Settings > Protocol Management > Manage Connection Profiles).  
3. The monitored computer's SNMP properties must be configured to accept SNMP packets from any host.

Unmanaged computers are not applied to agentless monitor policies when using filters

If a discovered computer is unmanaged (does not have the Altiris Agent installed), then it cannot be applied to agentless monitor policies with a filter. There is an issue that prevents the unmanaged computers from being targeted correctly, even if the computer is discovered and is contained in a filter.

To apply unmanaged computers to agentless monitor policies, you must manually add the computers using the resource selector. Managed computers are unaffected and can be added to agentless monitor policies using the filter.

Agentless monitoring is not available for targets that have been discovered through an Active Directory Import 

You cannot apply agentless monitor policies to targets that have been discovered through an Active Directory Import. To work around this issue, use a Network Discovery or a WINS import instead of an Active Directory Import. 

All resource types are displayed in the Computer List drop-down list when you are creating an agentless monitor policy 

When building a custom target for an agentless monitor policy, when the drop-down list (Computer list) is selected, additional resources that are not computers are also displayed.

To work around this issue, open the Select computers utility instead of using the Computer list dropdown list. The Select Computers page only displays computers. 

When the Remote Monitoring Server computer’s password is about to expire, agentless monitoring is unavailable

When a Remote Monitoring Server computer has either of the following:

• A password has expired or is within 14 days of expiration
  
• The option for a user to change the password on first start has been enabled

Then the PPA agent/plug-in is unable to connect through WMI. In this case, the Remote Monitoring Server is then unavailable because the Remote Monitoring Server depends on the PPA agent/plug-in for communications.
To work around this issue you must ensure that the Remote Monitoring Server computer’s password does not come within 14 days of expiration. If the password does expire, then resetting the password resolves the issue until the next time the password comes within 14 days of expiration.
As a possible means of prevention, you can set the Remote Monitoring Server computer’s Windows password to never expire.

Cannot import a monitor policy that contains a folder within it

You cannot import a monitor policy that contains a folder within it. The folder is shown as a  monitor policy in the import interface. The interface does not let you schedule the import or allow you to attempt the import.
To work around this issue, you must remove the folder from the policy.

Known Issue when Exporting a monitor pack to Windows Vista and Windows Server 2008 when IE Protected Mode is On  

When all of the following are true:

• You are exporting a monitor pack to a Windows Vista or a Windows Server 2008 computer
• Internet Explorer protected mode is set to ON
• The Symantec Management Console is open

Then the monitor pack's .XML file is copied to the \temp\ folder instead of the intended path. In this case, completing the import process from this location would fail. You must copy the .XML file manually to the correct location first.

The Process Control task only supports 32-bit systems 

At this time, Monitor Solution 7.0 does not support the controlling of 64-bit Windows processes.

The SysLog Task Settings page includes an “Indentation” field that is not supported  

The Indentation feature for Syslog Task settings is not supported in this release. Please ignore the Indentation field when creating SysLog tasks.

A Timed Rule's initialization interval range cannot be adjusted to less than 5ms

In this release you cannot set the initialization interval of a timed rule to be less than 5ms.

Error Messages not displayed when a user attempts to perform a restricted operation

If you attempted to modify a restricted metric or attempt to add a restricted rule to a policy, an error message is supposed to be displayed that informs you that you cannot do this operation; however, the error message is not displayed at this time. 

Agentless Smart WMI Metrics do not work on Windows 2000 Server target computers 

Agentless Smart WMI Metrics do not work on Windows 2000 Server target computers.

Log Event metric supports ANSI-only

The Log event metrics supports ANSI-only log files. When parsing, the Log event metric assumes a Windows Latin-1 encoding.

If characters that require UTF-8 encoding (for example, when using non-English languages) are contained within either a Log Event metric or within the log, then the metric fails.

The Log Event metric fails to open client side Altiris log files

The Log Event metric is only capable of parsing Notification Server’s a.log file and, therefore, can only monitor the local Notification Server computer’s log. The Log Event Metric fails to open Altiris log files on remote client computers that contain the Monitor Agent.

ASP.NET metric enters retry state when ASP.NET is installed but not registered 

This issue occurs when ASP.NET is installed but not registered. To work around the issue, register ASP.NET by running the following command on the target computer:

aspnet_regiis.exe -i  

Known Issues with reports

• Reports are run first using default parameters. To receive reports with adjusted parameters, wait until the default parameter graph is displayed, change the parameters, and then run the report again.  
• After drilling down into a report's details, you cannot change parameters and see new graph results. To return to the initial view of the report, right-click the report in the left pane, and click Open.

A Monitor Solution report’s customized view is not preserved after the report refreshes

After customizing the view of a Monitor Solution report, once the report is refreshed the customizations to the view are lost and the default view is displayed.

Agent uptime via Heartbeat report not reporting the correct uptime percentage after crash  

For the "Agent uptime via Heartbeat" reports to accurately reflect uptime, the Monitor Agent service must be started again after a critical system crash. If the agent is not started again, this period will be erroneously reported as uptime instead of downtime. If you receive an alert that an agent heartbeat has failed, make sure that there is connectivity from the Altiris Agent to Notification Server, and make sure that the Monitor Agent service is running on the monitored computer.

Issues with IIS Memory Performance Report  

When viewing the IIS Memory Performance report, some metrics are not displayed, and an exception is logged in the NS log.

The following metrics are not displayed:

• Internet Information Services Global - File Cache Flushes (Avg)
• Internet Information Services Global - File Cache Flushes (Max)
• Internet Information Services Global - File Cache Hits % (Avg)
• Internet Information Services Global - File Cache Hits % (Max)
• Page Reads per Second (Avg)
• Page Reads per Second (Max)

To work around this issue, either view these metrics in the Table View of the report or view them from within in the Historical Performance Viewer.

Issues with Disk Paging Activity Report

The Disk Paging Activity report displays incomplete data when it is viewed in the Chart View.
To work around this issue and view all data values, use the Grid View to display this report.

The Monitored Resources by OS Web part may not work

Monitor Solution 7.0 includes a Web part called Monitored Resources by OS. If you add the Monitored Resources by OS Web part to the Monitoring and Alerting home page, there is a good possibility that the Web part will not function.

You must reconnect the Real-time Performance Viewer if metric data becomes unavailable

When using the Real-time Performance Viewer, if a metric becomes unavailable and then becomes available again, updated data is not displayed. The viewer continues to display the data value that was last received before the metric became unavailable. The Real-time Performance Viewer must be re-connected to the target computer  before updated data is reflected in the viewer.

The Real-time Performance Viewer displays default data when invalid credentials are used with HTTP and ICMP metrics  

When you launch the Real-time Performance Viewer on a device where you are monitoring HTTP metrics or ICMP (Ping) metrics, and the credentials that are used to get those metrics are invalid, then default data is displayed for those metrics. This behavior could falsely give the impression that the metrics are responsive.
Load Time, Response Time, Page Size, Hops, and Response time requests display -1.
CRC requests display NULL.
Status or other types of requests do not display a value. 

The Real-time Performance Viewer fails from Windows 2000 and Windows 2003 servers that are using French regional settings

When run from a Windows 2000 Server or a Windows 2003 Server with French regional settings, the Real-time Performance Viewer stops reporting data after approximately 2 to 3 minutes. An error message reports a disconnection with the Monitor Agent and the viewer does not re-attempt to connect to the agent.
If you are using the viewer to monitor Windows target computers, an exception error is written into the Notification Server Log when the Monitor Agent loses connection.
If you are using the viewer to monitor Unix target computers, the Notification Server Log does not report any errors.

When Using the Historical Performance Viewer, the  value displayed at the mouse pointer may not update 

This issue is known to occur when the chart area of the Historical Performance Viewer does not have the current curser focus, for example when the "refresh" button has been clicked. To work around this issue, click the mouse curser within the chart, and then hover the mouse curser over the desired data point. 

Historical Performance Viewer's Sort feature doesn't work correctly

The Sort feature in the Historical Performance Viewer is not working correctly in this release.