In case anyone else may have missed the release earlier this month, here are the details surrounding the security vulnerability for any Altiris Agent pre- 6.0.2389 build. Linky here...
http://securityresponse.symantec.com/avcenter/secu...

SYM008-002

February 6, 2008
Symantec Altiris Notification Server Agent Privilege Escalation Vulnerability

Severity: Medium
Remote Access: No
Local Access: Yes
Authentication Required: Yes
Exploit publicly available: No

Overview

A privilege escalation vulnerability in the Symantec Altiris Notification Server Agent has been identified.

Affected Product(s)

Product Version Build Solution(s)
Altiris Notification Server 6.X All 6.0 SP3 R7

Details

The Symantec...

The error message 'Invalid Character in a Base-64 String' recently appeared in the Notification Server error log. This error occurred immediately after attempting to select a database for the Notification Server to connect to, using the Database Setting option as shown below in Figure 1.

Keep reading for our (ever so humble) solution.

No matter how many times the dropdown was clicked to attempt to select a database, a blank dropdown would show, and the 'Invalid Character in a Base-64 String' error showed up in the Notification Server logs, and on this page as well.

Figure 1 - Blank Database Option

...

SQL and Altiris Products! They go together.... (Not singing that song). But they need to be configured correctly, or you can run into the dreaded slow console, or even worse, data loss.

In troubleshooting a slow console, one area you might consider is the I/O channels on the SQL server, specifically the Network Interface Card. One Altiris user recently discovered that his dedicated SQL server was the bottleneck in his management environment.

His SQL server was using 1 NIC to provide all connection to the rest of the world, including connecting to an ISCSI drive array. By only having one NIC for ALL THAT TRAFFIC, the Notification Server was bound to appear slow, since it could not access it's database data as fast as necessary. The problem extended so far as to cause package codebase creation to fail, thus...

Depending on the way you have your SQL database security set up you may end up with stored procedures and other objects having an owner other than dbo. The typical case of this happening is when running the upgrade with an account that is not an SA on the SQL Server.

If unresolved, this naming issue can give you grief. Here's a way to fix it.

This ownership issue will ultimately end up in causing a lot of errors such as the Deployment Console not opening or certain tasks failing. Basically anything that tries to call the stored procedure will fail because the name is wrong. For example: A stored procedure in the DS database called dbo.del_computer may have its name changed during an upgrade to username.del_computer.

To fix this situation run the following SQL script. Change the USERNAME to whatever the owner is for the objects that need to be changed.

DECLARE
 @OldOwner sysname,
 @NewOwner sysname

 SET @OldOwner = 'USERNAME'
 SET @NewOwner = 'dbo'...