28 February 2009

Deployment Solution 6.9 SP1 will not install into NS 6.0 Console

Installation of the Deployment Solution tab in the NS 6.0 Console never completes.

In some instances the Event log will have the following in the Application Log;

     Error 1718. File FileName was rejected by digital signature policy.


Environment

Deployment Solution 6.9 SP1, (6.9.355 & 6.9.365)

Notification Server 6.0 Console

Windows Server 2003 (all versions)


Cause

Known issue in Windows Server 2003 (all versions) covered in Microsoft KnowledgeBase article #925336.

This problem occurs if the Windows Installer process has insufficient contiguous virtual memory to verify that the .msi package or the .msp package is correctly signed.


Resolution

Hotfix is available from Microsoft at:

http://support.microsoft.com/kb/925336

26 February 2009

Where is Juice???

Juice has got a new look and feel….you want to know more for then click here

25 February 2009

About installing the Altiris Agent

For information and a listing of the available installation parameters for the Altiris Agent Installatio Program, see Altiris Knowledgebase article 27958 or click here.


For information on the Login Script installation process, see Altiris Knowledgebase article 28226 or click here.

For information on the Active Directory Policies installation process, see Altiris Knowledgebase article
27956 or click here.

20 February 2009

Detailed Agent logging

Whenever you want more details to be logged to the NS agent log file you can add a registry key at the following location :
HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Event Logging\LogFile

Add Severity as DWORD

The following values are used:
Error = 1, Warning = 2, Informational = 4, Trace = 8, Verbose = 16

So if you enable all the value is 31, if you enable Err, War, Inf then the value is 7

Maxfiles and MaxSize as DWORD will limit size and files

Hotfix for Sequential Tasks

A hotfix has been developed and tested to resolve this issue.  The hotfix can be found here.  The hotfix upgrades the Task Synchronization Agent and updates the collection assigned to the Task Synchronization Agent Upgrade Task to incorporate the version change.

NOTE!  If you've previously installed a version of the hot fix prior to 2/18/2009 you will need to uninstall the previous version of the hot fix from Add/Remove Programs before reapplying with this newer version.

To apply the hotfix, simply run the attached EXE on the Notification Server (located in the right-hand pane).  Note that processing will be paused during the application of the hotfix.  It is recommended to either log directly on the Notification Server or use the /console switch if using Remote Desktop.

To finish the fix, use the Task Synchronization Agent Upgrade policy to roll out the new version of the Task Synchronization Agent.

  1. In the Altiris Console, browse to View > Solutions > Software Delivery > browse through Configuration > Task Synchronization Agent.
  2. Right-click on the Task Synchronization Agent Upgrade task and choose Enable (if not so already).
  3. If an upgrade has occurred previously, please set a schedule to roll out the new Agent as the option for Run as Soon as the Computer is Notified only ever runs once, regardless of changes in version.

Remote Altiris Agent Diagnostics for NS7

This new tool (see below) is now supporting the NS7 Agent.

GREAT tool, a must have as an Altiris Admin

10 February 2009

Bandwidth throttling and speed tests, how does it work?

Bandwidth Throttling configuration:

Bandwidth throttling is configured on the NS Web admin console at 'Configuration > Altiris Agent > Altiris Agent Configuration' each of the four agent tasks, on the General tab under the Bandwidth/Throttling settings section.

Bandwidth throttling options:
  1. Never throttle.
  2. Enable throttling when connection speed is below <dropdown box>:
    • 500 bytes/sec
    • 1 KB/sec
    • 2 KB/sec
    • 4 KB/sec
    • 10 KB/sec
    • 20 KB/sec
    • 50 KB/sec (default)
    • 100 KB/sec
    • 256 KB/sec
    • 512 KB/sec
    • 1 MB/sec
  3. Throttle regardless of connection speed.
  4. Use the server’s time for throttling settings (none configured by default).

Once bandwidth throttling has been configured, and the throttling configurations have been passed to the Altiris Agent machines, the Altiris Agent uses ICMP (ping) packets to perform the network connection speed tests. This is detailed below in the section Speed Testing Parameters. The returned speed test value is cached for a period of 6 hours.

When there is a scheduled package download task, the Altiris Agent either retrieves the cached connection speed value or it will initiate a new network speed test, and the results will be cached for 6 hours. Once the 6-hour cache expires, the Altiris Agent will request another speed test profile once an advertisement execution or package download begins (see Speed Testing Triggers and Speed Testing Operations below).

Throttling Rules:

When the Altiris Agent is asked to throttle, there are two throttling rules that can be configured:

  1. Relative throttling—This is a user defined percentage of available bandwidth, and it is measure in 0–100 percent.
  2. Absolute throttling—This is a user defined maximum allowed throughput when throttling is enabled; it is measured in bytes per second.
How the throttling process works:
The Altiris Agent:
  1. Sets wait times and buffer sizes that most closely meet the target download speed of the configured relative or absolute throttle rule before starting the package download.
  2. Requests a segment of data from the source.
  3. Receives the data and then waits a specified period of time.
  4. Monitors the download and adjusts to meet the configured throughput.
  5. Requires no additional speed testing.
Speed Testing Triggers:

When the Altiris Agent is instructed to perform a speed test by its configuration policy there are four triggers that can initiate the speed test:

  1. Each Software Delivery task can have a 'Download and run…' option (Advanced tab and 'Download and Execute Options') which determines the location of the file for execution, whether from a server or locally, depending on the available speed.
  2. In the Altiris Agent configuration there is an option Default minimum connection speed to run SWD Packages to test minimum throughput before execution.
  3. In the Altiris Agent configuration there is the same Download and run… option as in the Software Delivery Task, but when applied via the Altiris Agent configuration, it is a global setting which then applies to all tasks.
  4. In the Altiris Agent configuration there is download throttling when the download occurs. This method has two modes of operation: Relative throttling which is a percent of available bandwidth, and Absolute throttling which is simply a value for the throughput allowed.
Speed test operations:

Speed Tests are Directed Against Servers in the Following Manner:

  1. Items 1, 3, and 4 above in Speed Testing Triggers (only with Relative throttling) are tests against the download location.
  2. Item 2 above in Speed Testing Triggers is against the Notification Server, or any Item where the Altiris Agent cannot determine another server to test against will be evaluated against the Notification Server.
  3. Item 4 (with Absolute throttling) does not need a speed test.

Note! Speed testing does not mean packets go on the wire every time one of these decision points is reached. Review the speed test details below under Speed Testing Parameters. Whether it is for a package download or an advertisement execution, the speed testing process is the same.

Speed testing begins with the FQDN name for the server being targeted based on the codebase and the speed is discovered and set; the NetBIOS name is not tested but it set to the same speed. If the FQDN test fails then the NetBIOS name is tested, and the speed is discovered and set.

Bandwidth Throttling when ICMP is turned off:

There are several throttle settings and parameters that need to be understood when ICMP traffic is disabled on the network. Activation of throttling by the Altiris Agent is based on the following options:

  1. Throttle regardless of connection speed, or
  2. Enable throttling when connection speed is below <dropdown box>.

If ICMP traffic is disabled on the network, the option Throttle regardless of connection speed should be selected. If the option Enable throttling when connection speed is below… is selected when ICMP traffic has been disabled, by default throttling is set to 1 KB/sec because the connection speed cannot be verified.

So, threshold settings that are 1 KB/sec or above are always throttled, and the setting of 500 bytes/sec is never throttled.

The configurable values for throttling threshold are:

  • 500 bytes/sec
  • 1 KB/sec
  • 2 KB/sec
  • 4 KB/sec
  • 10 KB/sec
  • 20 KB/sec
  • 50 KB/sec (default)
  • 100 KB/sec
  • 256 KB/sec
  • 512 KB/sec
  • 1 MB/sec

Once the throttling options are selected then the throttling limits come into effect. Again, these limits are:

  1. Relative throttling — This is a user defined percentage of available bandwidth, and it is measure in 0–100 percent.
  2. Absolute throttling — This is a user defined maximum allowed throughput when throttling is enabled; it is measured in bytes per second.

When ICMP traffic is disabled on the network there is no need to initiate speed testing and Absolute throttling is the better choice. The bandwidth limit is already known and the Altiris Agent will throttle to that limit. If Relative throttling is selected, it will still act as an absolute limit as defaults to the option of 1 KB/sec.

Since network throughput is so critical, different Altiris Agent collections should be created based on network throughput. Altiris Agent machines can then be customized based on customized connectivity configurations.

Speed Testing Parameters:

Speed testing is a result of the Altiris Agent pinging the FQDN name for a server being targeted based on the defined codebase, and the speed is discovered and cached; the NetBIOS name is not tested but it set to the same speed. If the FQDN test fails then the NetBIOS name is tested, and the speed is discovered and set.

If the codebase request is to a server that has not been profiled for a connection speed before then a speed test is initiated.

Packets used: Five 1-byte packets and then thirty 400-byte packets. (Note: Older operating systems will only use five 400-byte packets.)

Registry keys:

HKLM\SOFTWARE\Altiris\Communications\MaxServersToCheck (default 6, valid range is 1–100).</I">

            Description: Maximum numbers of servers to check

Values: If over 100 or under 0 then is set to 100; a value of 0 is set to 6

HKLM\SOFTWARE\Altiris\Communications\ IP Expiry (mins) (default 360, valid range is 1–10,080)</I">

Description: Number of minutes before connectivity to a Host is retested

Values: If over 10,080 or under 0 then is set to10080; a value of 0 is set to 1.
HKLM\SOFTWARE\Altiris\Communications\SPEED Expiry(mins) (default 360) 

Additional information

See AKB #39368 for additional information on Speed Testing.

NS7 RC2 Getting started

To start with the RC2 please download the Symantec Instalation Manager from the beta portal and the product Listing that goes with the RC2. The sources then will be downloaded as required.

When you start playing with the new RC2 downloaded from the BETA site then don't forget to enable the  "Altiris Agent for Windows - Upgrade" policy to get started, otherwise you are working with an old agent on the NS SERVER only, the agents get deployed ok. (This is because the agent is installed during the base install during the setup)

If you have installed Inventory Solution with Application Metering Solution then the Inventory Solution Pug in is enabled by default. (this is new). The "Application Metering Plug-in for Windows Install" if selected in the Enable Management Features screen during install is NOT enabled by default.

Get the Software Discovery policy enabled on a suitable time is working on VMWare (mine is turned off during night).. The policy runs on Sun and Wed at 02H00 AM...This policy is responsable to populate the Add/Remove Program Table that is used in the Installed software Report.

A full inventory is enabled by default and will run at 18H00 every Monday

(Updated) Remote Altiris Agent Diagnostics

“Remote Altiris Agent Diagnostics” allows you to connect into a remotely Altiris Agent managed machine to view all the configurations and troubleshoot without having to RDP into the machine to look at the Agent UI.

Many times a user is already logged onto the machine and so you cannot run any Altiris processes to move the agent along or troubleshoot. This application allows you to remotely run Configuration Requests, send Basic Inventory, Run a SWD program, stop and start the Altiris service, delete the Patch IAD file, view NSI files, delete Inventory files and randomization registry keys (a way to force cleanbeforerun and run now), change Logging settings, as well as run a command line remotely so you can run things like “AexPatchUtil.exe /Xa” to start the patch cycle.

You can see all the settings that the Agent UI does locally, except remotely – SWD, Patch, Agent Details, etc. It also has a Log Viewer and you can filter the log entries.

Download the attached application here. Just enter the DNS name of the remote machine and hit enter.

You need to run the executable locally on a x86 Windows OS, use an admin account on the remote client (can use 'Run As'), and the remote registry service needs to be started on host and remote machine. In order to use the Update Config Request, Send Basic Inventory, and Run Program you need the NS Agent installed locally.

Note: This is tool is not supported by Altiris Support. If you have problems or comments please use this KB to send feedback.

Updates:
Ver. 1.0.14 - Add the ability to except command line. Now you can run "Remote Altiris Agent Diagnostics.exe" ComputerName for this utility to automatically launch and connect to the ComputerName. Usage can be to add right-click menu to the NS Console.
Ver. 1.0.15 - Added "Resend Package Status" and "Refresh Packages" functionality to the Tools menu for Package Servers.
Ver. 1.0.15 - Changed "Remote Execution" to pull options from an INI file for easy distribution and repetition. Example INI in attached zip file.
Ver. 1.0.16 - Added "Reboot Required" and "Patch Cycle In Progress" date to the Software Uupdates tab.
Ver. 1.0.17 - Software Update fixes
Ver. 1.0.18 - Added Task Manager functionality - list and end remote processes
Ver. 1.0.19 - Added Package Server tab
Ver. 1.0.20 - Fix bug in SWD "Package ID" value and Task Manager "Memory" column sort fix
Ver. 1.1.1 - Added ability to connect to remote machine managed by the NS 7 Altiris Agent and not just NS 6 Agent.

Ver. 1.1.2 - Fix bug in End Process function on Task Manager
Ver. 1.1.3 - Added ability to Enable or Disable Bandwidth throttling on Tools tab
- Added ability to Hide Superseded Software Updates
- Added ability to double-click Source Location path to open in browser or explorer on Package Server and SWD tabs
- Added Download History and Source Location info on Package Server tab
Ver. 1.1.4 - Decreased the Package Server tab load time
Ver. 1.1.5 - Added "Hide Disabled" checkbox to Package Server tab

Please add yourself as a subscriber so you receive notifications when this tool has been updated.

Here are some screenshots:

imageimage

06 February 2009

How to prevent duplicate ResourceGuids from being forwarded to Reporting Notification Servers?

You have implemented our Duplicate Guid Diagnostic toolset on your Forwarding Notification Servers, however, you have noticed that your Reporting NS's are suffering from this scenario too.  How can this be prevented?


Answer

In order to prevent duplicate ResourceGuids from being forwarded to a Reporting NS, you should exclude our "Possible Duplicate Guids" collections from your Inventory Forwarding collection.

If a Reporting NS already has a duplicate ResourceGuid issue, then make sure you delete them after implementing the above step, so that only unique ResourceGuids will exist on a Reporting NS.

Shared Guid Diagnostics Guide (aka Duplicate Guid Kit)

What is a shared agent guid, and how can I correct the problem?


Answer

Definition

A Shared Altiris Agent Guid is a configuration problem that causes mismatched inventory data, and prevents accurate management and event-message storage of managed computers by the Altiris Notification Server.  The Altiris Agent Guid is the primary mechanism by which the Altiris Notification Server uniquely identifies each resource record in the NS database.  In this situation, we are concerned with computer resource records.  There are several potential causes of shared guids.  They all originate from circumvention of the normal agent deployment process, or external changes to the agent's configuration.  The end result is that two or more managed computers each claim to be the sole owner of the Agent Guid (which is supposed to be globally unique). 

Known causes

OS Imaging:  By default, the Notification Server will generate a new Guid upon the first request from a brand new Altiris Agent.  The Altiris Agent then stores its assigned Guid in the registry for Windows, and on the file-system for the Linux, Unix and Macintosh platforms.  Shared Guids can be caused by imaging a workstation that already has an Altiris Agent installed.  Each restored copy of the workstation will have the same assigned Guid.  This issue exists in all imaging solutions, with the exception of Deployment Server (DS) version 6.5 or better.  The best solution is to schedule the Altiris Agent to install immediately after restoring an image  (This can be done as a DS job).  An alternate solution is to always remember to delete the guid from the workstation prior to imaging (error prone).

Software Packaging: This cause is less likely to occur, but simple software repackaging tools will include the Altiris Agent's registry or file location of the guid as part of the software package.  Activity by the Altiris Agent can fool the packaging tool into thinking that the Guid belongs to the package.  Deploying the bad software package overwrites the good guid with the one from the capture station.  To avoid this problem, don't install the Altiris Agent on the workstation used for snapshoting the original software installation job.

Resolution

The purpose of this document is to demonstrate how to use the Notification Server’s shared GUID diagnostics kit to successfully identify and remove computers within the Notification Server database. The attached MS Word document contains screenshots for additional clarity (it is now considered out-of-date, and is merely provided for historical reference).

Installation

You can install the diagnostics kit by following the steps below. This utility contains several collections, a report, a package to remove the shared guids, and platform specific tasks. These items are all created in a Shared Guid Diagnostics v6.04 folder that is created by the import.

Note: Altiris NS Agent version 1508 or later is required for this to work.

  1. Download the xml file attached to this article and save it to a location on  the Notification Server
  2. Find a location to install this utility. For this example we will create a folder called “Diagnostics” within the Tasks folder.
  3. Highlight the folder that you created. Right-click and choose Import.
  4. You will be prompted to choose the file to import. Choose the Shared Guid Diagnostics v6.05.xml file.
  5. Once the file has been imported into the Notification Server database, you should see the following structure:

 image

  1. Enable each applicable Reset Guid Task.  It's only neccessary to enable the task for platforms that exist in your environment.

Possible Duplicate Guids

  • These collections will query the Notification Server database for all computers that have reported a change in their GUID in the past seven days. Computers in this collection are used by the associated task to reset the Guid on the client computers.
    Note: After fixing shared GUIDs in the database, there is a possibility that some computers will still show up here. This collection is checking to see if the computer record has been changed in the last seven days, not if it has been fixed. To retrieve an accurate report, use the GUIDs Shared between 2 or more computers report or view the Machines that have run the Reset Guid Task collection.

Machines that have run the Reset Guid Task.

  • This collection will display any computers that have run a reset guid task, giving you a report of the machines that have completed the fix.  Keep in mind that this report can not be 100% accurate due to the problem that is being addressed by the reset guid tasks.

GUIDs Shared between 2 or more computers.

  • Analyzes computers that have been sharing the same GUID, this is recognized when frequent name changes are occuring on a specific NS computer record. Once the duplicate GUID has been cleaned up, you will see the results in this report.  This report doesn't distinguish by platform, and will also include un-managed computer records.  By design, collections can not include unmanaged computers. 

Reset Guid Tasks

  • These packages are responsible for running the appropriate task on the computers that are sharing the guid.  On the Windows platform, it will use a built-in utility to strip out the Altiris Agent's guid from the registry.  There are multiple places that the guid can be stored, depending upon if the DS Aclient is also present, and or older versions of the Altiris Agent have ever been used.
    • For the Windows platform, the following command is used:  AeXAgentUtil.exe /resetguid
    • For Unix, Linux, and Macintosh computers, the file containing the guid is deleted, and the Altiris Agent is restarted as a background process.  The agent restart is neccessary to flush the GUID from memory.
  • A new Guid is created by the Notification Server after the Altiris Agent sends the computer name and domain to the Notification Server. For each shared guid, one of the computers will retain ownership of the computer resource record, the remaining computers will be assigned new guids (and thus new NS computer resource records).
Permissions

By default, when this package in imported, the owner of the folder and items will be null. The administrative role will have access to this utility, but if permissions are to be set, you should set the ownership by doing the following:

  1. Right-click on the main folder
  2. Choose Properties
  3. Choose the Security Tab
  4. Choose the Take Ownership button.

Uninstall
To completely remove the Duplicate Diagnostic utility from your system, you should follow the steps below. Delete the following objects through the NS console (right-click > Delete).
1. Reset Guid tasks (3).
2. Possible Shared Guid collections (3)
3. Machines that have run the Reset Guid task collection
4. Guids shared between 2 or more computers report
5. The Reset Guid Agent Package.  (You must first delete each "program" by clicking the delete button on the Programs tab of the package).


Version Notes

  • 6.04 -> 6.05:  Updated the accuracy of the report to avoid false positives to match the upgraded collections.  Now both the report and the collections must have at least 3 name/domain changes in 7 days before being considering suspect.  This facilities the standard practice of changing the computer name and attaching to a domain.
    Corrected the software advertisement guids used in the "Computers that have run the Reset Guid task". 

Troubleshooting

Problem: After running this tool, computers have been removed from my static collections

Answer:
The attached report "Computers with Duplicate GUIDs and their old collection memberships.xml" can be used to help identify what collections were affected. Altiris Administrators will have to add the computers back to the collections they were removed from. Thank you to Altiris customer Vince Fanelli for creating this report.


Problem:
My collection is not updating with any computers, and I know there are shared GUIDs in the database.

Answer:
By default, the Collection will update on the automatic schedule for collections. You can change the time the update will happen by changing the “Automatic Collection Updating”.


Problem:
My collection still shows a list of computers after the scheduled task has had time to run. Why are there still computers in the Possible Duplicate GUIDs collection?

Answer:
This collection will report a list of computers that have changed their GUIDs in the last month. If the task has run successfully on these computers, then these computers should not update the GUID again. You will have to wait for a month before the computers will be removed from this collection. To accurately determine if there are any remaining computers that are reporting a duplicate, the report GUIDs shared between 2 or more computers should be used.


Problem:

I have run the Reset Guid task for all computers. Now the GUIDs shared between 2 or more computers report is showing a number of computers if the Number of days to report on is set to a high number like 100. Are there still sahred GUIDs in the database?

Answer:
  No. This report will check the database for computers that have shared this GUID at some point in time (default setting is seven days). You will need to watch the results of this report to ensure there no new activity. You will see machines show up in this report if they report back to the Notification server with a GUID used by another computer. The computer will then take over the GUID and the next time the other computer checks in, it will repeat the process.

 

Links :

MS Word Doc: https://kb.altiris.com/utility/getfile.asp?rid=3577&aid=3848

Report : https://kb.altiris.com/utility/getfile.asp?rid=3589&aid=3848

Report : https://kb.altiris.com/utility/getfile.asp?rid=4914&aid=3848

03 February 2009

Scripted OS install stops at a blinking cursor / blank screen

After assigning a scripted OS install job to a machine the client runs the prepare production partition part of the task then reboots to a blink cursor / blank screen


Cause

There is a reboot required after setting up the partition for the scripted install task.  The machine is supposed to reboot back in to an automated environment and continue to copy down the files and start the install.  When it can not boot back in to a automation environment it boot to the empty production partition which has no boot information leaving the user viewing a blinking cursor / blank screen


Resolution

Find out why the machine did not boot back to an automation environment.  This could be cause by any of the following.

  • PXE/Network boot was not set as the top priority in the BIOS (only applicable if using pxe)
  • The client connected to a rogue PXE server and was instruction to boot to production
  • The automation media (boot CD/USB) was removed from the machine after rebooting