Bandwidth throttling and speed tests, how does it work?

• Bandwidth throttling configuration
  • Bandwidth throttling options
  • Throttling rules
• How the throttling process work
  • The Altiris Agent
  • Speed testing triggers
  • Speed testing operations
  • Throttling when icmp is turned off
• Speed testing parameters
• Registry keys
• Additional information

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:

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:

 

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

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

NS7: Inventory Installed Software Report

As I was playing a bit with NS7 (Or should I say Symantec Management Console) and Inventory I found a new report in the right click menu action of a resource called Installed Software on on the left side of the Resoucemanager.

First thing I did was deploying the Inventory Plug-in and I launched a task to get the inventory. When I then clicked the resource and opened the report it was empty (No result).

So i analyzed the report and it uses the Add/Remove Program information. But...other then Inventory Solution 6.X this information is now collected by the Software Management Framework Agent. This plug in is part of the core Agent.
Only...Software Discovery will run at 02H00...and then my VMWare is/was not running...So for those who are in a hurry on getting some information you need to change the Software Discovery Task schedule to run when you want.

After that this report is displaying some results.

Hardware Independent Imaging with DeployAnywhere

On the juice site I found this article on using DeployAnywhere

Some other (and same) information comes from the KB articles

How to use DeployAnywhere in Deployment Solution to replace the HAL, NIC driver, and mass storage drivers

---

DeployAnywhere works by deleting the existing HAL.dll in a Windows* operating system and deploys a NIC driver and mass storage driver to rebuild the HAL.dll on the first reboot.

Requirements

• Deployment Solution 6.9 SP1
• Any image created with RapiDeploy, Ghost, or ImageX.
• Windows PE Automation Enviroment

Steps to complete

1. Create an image with RapiDeploy, Ghost, or ImageX.
2. Create a Distribute Image task and check Use DeployAnywhere hardware independent imaging in the Configuration section of the task.
3. Check Prepare Using Sysprep.
4. Assign the Image Task with DeployAnywhere settings.

How do I test if the driver database has drivers for a computer?

---

1. Boot to Windows PE* 2.1 network enviroment.
2. Run these commands:
   cd F:\ghost
   ghDplyAw32.exe /target=c:\windows /ddb=F:\DriversDB /eval
3. This will return a failure or success. (If a failure is returned, it will say what driver is needed.)

Important:
The previous task only works if the SmeUtil.sys driver is in the
\Windows\System32\Drivers folder of WinPE. This driver is found in the Ghost folder in your Deployment Share. It can be added to the WinPE automation during the creation or editing process by right-clicking the Drivers folder and selecting Add File.
As an alternative, the SmeUtil.sys driver can be copied by adding the following command to your run script task:
Copy %ALTIRIS_SHARE%\Ghost\SmeUtil.sys %SystemRoot%\
System32\Drivers

NIC and mass storage drivers need to be added to the DeployAnywhere driver database.

---

1. Open the Deployment Console.
2. Click Tools, and then DeployAnywhere Driver Managment.
3. Click on network for NIC drivers and mass storage tab for mass storage drivers, and click Add New Driver.
4. In the New Window Driver window browse to your drivers. In the friendly name box, type a name for the driver you are adding. Check the OS that this driver will be applicable for.

To enable Deploy Anywhere logging with Deployment Server do the following:

---

• Open the applicable Distribute Disk Image job.
• Select 'Use DeployAnywhere hardware independent imaging'.  The 'Advanced' button will become active. (not grey)
• Click on the 'Advanced' button.  In the 'Additional Parameters' box add the '/capturesupportinfo=<path on DS to store the logs>' switch.  E.g. /target=c:\windows /ddb=\driversdb /capturesupportinfo=f:\temp.

When Deploy Anywhere is ran it will output all logs to the directory specified. 

What is the best way to change the IP address of the DS server?

You should check and change the IP address of the DS server in the following places:

• Change your aclient settings over to point to the new IP address (or the server's hostname if possible)
• Stop the Altiris eXpress Server, PXE Config Helper and PXE Manager services
• Change the IP information within these files in the eXpress share:
  • .\default.cfg
  • .\pxe\pxe.ini
  • .\pxe\pxemanager.ini
  • .\pxe\rpc.ini
• Start the Altiris eXpress Server, PXE Manager and PXE Config Helper services (Note the order of start up)
• Change each PXE / Bootworks configuration to point to the new IP address (lmhosts file)

Configuring Package Location on your Package Server

This article shows you how to:

• Change the package location
• Secure the package location

Changing the Package Location

It can be beneficial to select a different location on your Package Servers to save disk space. When the storage location for a package is changed to a custom location, the Package Server: 

• Moves the files from the old location to the new location
• Deletes the old location
• Checks what is to be downloaded

When files are removed from a package, the Package Server deletes them when it refreshes the package. However, removed files are not deleted if the package has a custom location as it cannot determine if the files are part of the package. Example: several packages with the same destination or the custom location contains user files.

Also, as the Package Server is installed on the same drive as the Altiris Agent you can select a different drive when installing the Agent.

This option is on a per package basis. What that means is that each existing package and all new packages would be configured this way. There currently is not a way to globally change the default location of the packages stored on the package server. All packages will continue to have the default location of "%ProgramFiles%\Altiris\Altiris Agent\Package Delivery". The only way to change this location is by removing the Altiris Agent completely, implying the removal of all subagents, then reinstall the agent on the desired drive.

Changing the Package Location

1. In the Altiris Console, click the Configuration tab.
2. 
   Example:
   To change the Altiris Agent package location, in the left pane select Altiris Agent > Altiris Agent Rollout > Altiris Agent Package. In the right pane, click the Package Servers tab, select Package Destination Location on Package Servers and enter a location in the field provided.
3. In the location field, specify a directory path or use system environment variables found on the Package Server. The following are valid paths:
   c:\share\<packagefoldername>
   f:\<packagefoldername>
   \\%COMPUTERNAME%\share\<packagefoldername>
   \\%COMPUTERNAME%\eXpress\<packagefoldername>
   /var/packages/<packagefoldername>

Warning: Ensure you specify a subfolder that is unique to each package in the Package Destination Location on Package Servers field!

If you do not specify a sub-folder, or use the same folder for more than one package, this can create a dangerous situation that could remove the entire destination folder and its contents. It is absolutely imperative that you configure an appropriate sub-folder when performing this task; otherwise the contents of your entire share could be deleted when the package is deleted!

When a package is removed (either by it becoming invalid or by manually clearing the Package Destination Location on Package Servers field) then the entire folder that the package resides in will be deleted, including any other files originally located there that were not part of the package.

Remember, ensure you specify a folder for each package in the Package Destination Location on Package Servers field!

Securing the Package Location

This section shows you how to:

• Secure the package location
• Allow anonymous access to package locations
• Disable location security

The Agent Connectivity Credentials (ACC), in the Global Altiris Agent Settings page, are used by the Package Server to add file-based security to download package files, if so configured.

Note: The Agent Connectivity Credentials used must be a known account on the Notification Server and every Package Server.

To secure files in packages on the Notification Server and Package Servers configure Windows NTFS file permissions. If the user account can’t be validated on a Package Server (for example, non-trusting domain or computer account from another computer), Altiris agents won’t download files from this Package Server.

Using a domain account as the ACC will work if the Altiris agents, Package Servers, and Notification Server exist in the same domain, or a trust exists between the multiple domains in your environment.

If your environment contains multiple domains and no trust exists between these domains, when you specify an ACC, enter a local user account name and not a domain account user name and password. The format for entering the local user account name as the ACC is one of the following:

• .\localuser
• localuser (where localuser is the name of the local computer account)

If you specify a local account as the ACC, we recommend you enable the Create the Agent Connectivity Credential on Package Servers option on the Settings tab of the Package Server page (provided the ACC is not a Domain Controller). This ensures a local account will be created and applied to the downloaded package files on all Package Servers, if it doesn’t already exist on all Package Server computers, on all trusted and non-trusted domains.

The Altiris Agents can use this local account to connect to Package Servers across nontrusted domains when downloading files.

If you specify a local account and the Create the Agent Connectivity Credential on Package Servers. (provided the ACC is not a Domain Controller) option is disabled, the local account needs to already exist on every Package Server. If not, the Package Server can’t apply security to downloaded packages and will not publish codebases as ready to the Notification Server.

Creating the Agent Connectivity Credential on Package Servers

1. In the Altiris Console, select the Configuration tab.
2. In the left pane, navigate to Configuration > Server Settings > Notification Server Infrastructure > Package Servers.
3. In the right pane, click the Settings tab.
4. Select Create the Agent Connectivity Credential on Package Servers (provided the ACC is not a domain account). Selecting this option allows you to enable the following:
   • Re-enable the created local account if it has been locked out.
   • Create the ACC even if the Package Server is also a Domain Controller.

Allow anonymous access to package locations

You can enable all packages downloaded to Package Servers to have anonymous access applied to the directories containing the package files. Anonymous access will also be enabled for the directory security inside IIS for the hosted Package Server packages.

If this feature is disabled the Agent Connectivity Credentials on the Global Altiris Agent Settings page will be used when applying security to the Package Server files. Any HTTP virtual directories mapped to packages on the Package Server will then have Integrated Windows authentication enabled.

All authenticated users are allowed to download through UNC when anonymous access is enabled. For example, if a Package Server in a non-trusted domain has anonymous access enabled on its files and the ACC account the Altiris Agent uses to connect anonymously to the UNC source cannot be authenticated, access with be denied and no download will occur. However, you can download through HTTP from a Package Server, in a non-trusted domain, using anonymous access because the ACC account doesn’t need to be authenticated.

New Registry key for disabling Package Server directory security

A new Package Server registry key, EnableDACLManagement, has been created to allow you to change how a Package Server manages the security on its packages.

By default, a Package Server manages its packages by setting specific permissions on package directories; this includes overriding any custom permissions you may have set on the directories. When this registry key is activated, Package Server will no longer override existing permissions on package directories.

Take care when using this key as incorrect permissions could potentially render the Package Server directories inaccessible to the Package Server and Altiris Agents.

To ensure a fully functional Package Server, full control for Local Administrator and System need to exist on all package directories in addition to any other custom permissions.

Normally, Altiris Agents and other Package Servers access the packages located on the Package Server computer using the Agent Connectivity Credential (ACC), configured on the Notification Server. To ensure they continue to download packages, configure the Everyone or ACC account with read and execute privileges on the package directories. This is required because when the key is activated, Package Server is instructed not to manage permissions, which includes not applying the ACC or Everyone account to the downloaded packages.

Creating the Registry Key

As the registry key does not exist on a default install of the updated Package Server, create the DWORD key, 'EnableDACLManagement' under the following location in the registry—HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Package Server. Before creating the key, stop the Altiris Agent Service and restart when finished.

The registry key can have one of the following settings:

• 0—Ensures that Package Server will not change existing security on package directories.
• 1—Will cause Package Server to function as normal by applying and resetting permissions on package directories.

Altiris Deployment Solution 6.9 SP1 MP1 (Maintenance Pack 1)

What issues have been fixed in Altiris Deployment Solution 6.9 SP1 MP1 (Maintenance Pack 1)?

---

Resolution

The DS 6.9 SP1 MP1 (Maintenance Pack 1) addresses the component issues noted below:

Altiris Client Service (AClient.exe)

The current build of AClient is 6.9.366. It is a cumulative build that includes fixes from all previous builds.

Description	Fixed in Build	Article ID
AClient JPN, FRN, DEU, and CHS localization issue.	6.9.359	44291

Altiris eXpress Server (AXengine.exe)

The current build of AXengine is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description	Fixed in Build	Article ID
MMB S3 Bladeservers not listed in Deployment Solution console	6.9.361	44804

ASDK for DS

The current build of the ASDK for DS is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description	Fixed in Build	Article ID
DNS settings are not reflected on the console using a programmatically created Reconfigure job	6.9.361	44455
Authentication failing using ASDK methods like DeleteComputer() after installing DS 6.9 SP1	6.9.363	44253
''Task_Return_Codes_Table'' dataset is ignored in API calls	6.9.364	41438
CreateJob error in Administrator SDK 1.4, "Error Value cannot be null" when job have Condition set	6.9.364	40878
"Value cannot be null..." when DS security is disabled and code does not include DSCredentialsHeaderValue.	6.9.365	44650
Method failed. Exception: Permission Denied: Deployment Server Role-Based Security is enabled.	6.9.365	44649

Boot Disk Creator (bootwiz.exe)

The current build of the boot disk creator is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description	Fixed in Build	Article ID
Boot Disk Creator unable to add drivers to WinPE using the Have Disk button	6.9.357	44108

DAgent

The current build of the DAgent Default Component is 6.9.366. It is a cumulative build that includes fixes from all previous builds.

Description	Fixed in Build	Article ID
Copy File task using UNC path fails with “The network path was not found.”	6.9.356	44031
DAgent does not retain WINS IP address after post config	6.9.361	44811
Duplicate SPN error when user tries to login to the machine with domain user	6.9.361	44807
DAgent in WinPE occasionally fails to connect to Deployment Server	6.9.366	44898
DAgent can hang if an exception is thrown during startup	6.9.366	44899

Data Manager

The current build of Data Manager is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description	Fixed in Build	Article ID
Exception may be thrown in Axengine if the Web Console is installed	6.9.361	44109

Deployment Server Console (eXpress.exe)

The current build of the Deployment Server Console is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description	Fixed in Build	Article ID
Cannot schedule jobs using Active Directory group authentication.	6.9.361	44235
Error "##wc_last_effective_rights" is displayed when multiple consoles are open	6.9.361	44220

PXE

The current build of PXE is 6.9.365. It is a cumulative build that includes fixes from all previous builds.

Description	Fixed in Build	Article ID
PXE Server fails to send path to pxeboot.bdc when clients boot to WinPE causing ‘Windows failed to start’ error	6.9.362	44281

To apply the maintenance pack do the following:

1) Download the maintenance pack and save to a directory on the Deployment Server.
2) Execute the file and follow the prompts.  
Notes:

- All affected files are backed up.  An uninstall is added to Add/Remove programs in the Control Panel.

- Fixes are applied for installed components ONLY. If, for example, the ASDK is not installed, the ASDK fix will not be applied.  If the ASDK is installed later simply rerun the maintenance pack and the file(s) will be updated.
- The maintenance pack can be installed silently by using the /S switch.

-  In order for the maintenance pack to resolve the PXE and Webconsole issues documented above it is necessary to run the maintenance pack on all remote PXE/Webconsole servers. 

This can be done by following the steps below:

1) Install Aclient/Dagent on all remote PXE/Webconsole servers
2) Create a Distribute Software job. Use "DS_69_SP1_MP1.exe" with the /S switch.
3) Assign the job to the remote PXE/Webconsole servers
4) The maintenance pack will update the remote PXE/Webconsole servers
5) Remove Aclient/Dagent on all remote PXE/Webconsole) server

Patch Management Upgrade Validator

This tool examines the Notification Server database to determine if are any issues that require addressing before an upgrade can occur. In "Analyze" mode, the tool makes no attempt to remediate issues and makes no modifications to the database.

The tool restricts its reporting to the internal state of the Notification Server and Patch Management solution. The results do not contain any information identifying vulnerabilities in individual machines or groups of machines.

Download the latest Validator tool HERE.

It's safe for PM 6.1 and 6.2 to be used and fix any reported errors

How to view codebases returned to the Altiris Agent through getpackageinfo.aspx request

Answer

When the Altiris Agent is required to download a package it will request the appropriate codebases from the Notification Server through getpackageinfo.aspx. The information returned from getpackageinfo.aspx is ultimately stored as the package.xml on the client computer under 'Program Files\Altiris\Altiris Agent\Software Delivery\<package GUID>'.

For example, a client computer will show the following in the logs during the getpackageinfo.aspx request (when trace logging is enabled on the client computer):

Date: Nov 08 14:23:41:011
Source: AeXNetworkTransport
Description: GET:
url=http://ns-03/Altiris/NS/Agent/GetPackageInfo.aspx?xml=<request resource="{89782D60-FFA1-487A-B4BA-38E909ABB6DF}" version="1" type="codebases" compress="1" totalTime="0">
<packages>
<package guid="{8661D7F2-039B-4418-9A0A-70A9C7445F9C}"/>
</packages>
<addresses>
<address ip="192.168.0.104"/>
</addresses>
</request>

The IIS logs on the server record the following:

2005-11-08 21:23:41 192.168.0.104 GET /Altiris/NS/Agent/GetPackageInfo.aspx xml=%3Crequest%20resource=%22%7B89782D60-FFA1-487A-B4BA-38E909ABB6DF%7D%22%20version=%221%22%20type=%22codebases%22%20compress=%221%22%20totalTime=%220%22%3E%0A%3Cpackages%3E%0A%09%3Cpackage%20guid=%22%7B8661D7F2-039B-4418-9A0A-70A9C7445F9C%7D%22%2F%3E%0A%3C%2Fpackages%3E%0A%3Caddresses%3E%0A%09%3Caddress%20ip=%22192.168.0.104%22%2F%3E%0A%3C%2Faddresses%3E%0A%3C%2Frequest%3E%0A 80 - 192.168.0.104 - 200 0 0

To view the codebases in your browser, take the IIS log entry and make the following changes:

1. Replace the space between getpackageinfo.aspx and XML with a question mark.
2. Remove the section referring to compress=%221%22 (highlighted in red below).
3. Complete the URL by adding 'http://server_name' at the beginning of the line.

Before:

/Altiris/NS/Agent/GetPackageInfo.aspx xml=%3Crequest%20resource=%22%7B89782D60-FFA1-487A-B4BA-38E909ABB6DF%7D%22%20version=%221%22%20type=%22codebases%22%20compress=%221%22%20totalTime=%220%22%3E%0A%3Cpackages%3E%0A%09%3Cpackage%20guid=%22%7B8661D7F2-039B-4418-9A0A-70A9C7445F9C%7D%22%2F%3E%0A%3C%2Fpackages%3E%0A%3Caddresses%3E%0A%09%3Caddress%20ip=%22192.168.0.104%22%2F%3E%0A%3C%2Faddresses%3E%0A%3C%2Frequest%3E%0A

After:

http://server_name/Altiris/NS/Agent/GetPackageInfo.aspx?xml=%3Crequest%20resource=%22%7B89782D60-FFA1-487A-B4BA-38E909ABB6DF%7D%22%20version=%221%22%20type=%22codebases%22%20%20totalTime=%220%22%3E%0A%3Cpackages%3E%0A%09%3Cpackage%20guid=%22%7B8661D7F2-039B-4418-9A0A-70A9C7445F9C%7D%22%2F%3E%0A%3C%2Fpackages%3E%0A%3Caddresses%3E%0A%09%3Caddress%20ip=%22192.168.0.104%22%2F%3E%0A%3C%2Faddresses%3E%0A%3C%2Frequest%3E%0A

Another solution from AKB#1070 (modify IP address and Package Guid as needed):

http://<notification server>/ALTIRIS/NS/Agent/GetPackageInfo.aspx?xml=<request resource="{1675E076-73CA-4CDD-BAD8-7130435F447E}" version="1" type="codebases"><packages><package guid="{01B54EB5-3679-4C73-9E10-E169D5A5EC59}"/></packages><addresses><address ip="10.50.104.82"/></addresses></request>

DAgent synchronizes the system clock when the option is not enabled

Problem/Symptoms

Even when the option to synchronize time with the Deployment Server is not checked, the DAgent will still synchronize time with the Deployment Server.

In WinPE 2.1 automation, the DAgent sets the hardware clock to a time that is not synchronized with the Deployment Server.

---

Cause

The cause is currently being investigated by Symantec

---

Resolution

A resolution is currently being investigated.  A possible workaround until this is resolved is to use AClient instead of DAgent.

How to preform a hard disk wipe using the Ghost utility called GDisk.

When reallocating hardware from one person to another, it is often important to ensure that none of the old data from the hard disk can be retrieved, even after deploying a new imaging to the computer.

The GDisk utility (one of the Ghost tools shipped with Deployment Solution 6.9 SP1) is a multipurpose disk management utility that includes a secure disk wiping feature. GDisk’s secure disk wiping feature wipes data according to the U.S. Department of Defense (DoD) 5220.22-M standard. According to this standard, the following group of operations is performed six times:

• All addressable locations on the hard disk are overwritten with 0x35.

• All addressable locations on the hard disk are overwritten with 0xCA.

• All addressable locations on the hard disk are overwritten with a pseudorandom character.

• All addressable locations on the hard disk are verified in hardware using the Verify Sectors command to the disk.

Running GDisk to Securely Wipe a Disk

GDisk can be run from a DOS (GDisk.exe), WinPE (GDisk32.exe or GDisk64.exe), or Linux (Gdisk) pre-boot operating system using the following syntax:

gdisk disk /diskwipe /dodwipe

The following table explains the GDisk command-line elements.

Element	Description
gdisk	The Gdisk executable used, such as GDisk.exe (for DOS) or GDisk32.exe (for WinPE).
disk	The physical disk to be wiped. Replace disk with a number between 1 and 128.
/diskwipe	Instructs GDisk to perform a disk wipe.
/dodwipe	Instructs GDisk to perform the required wipes meeting the DoD standards.

Example: gdisk.exe 1 /diskwipe /dodwipe

This command runs the DOS version of GDisk and wipes the first drive using the DoD standards.

Sample Symantec wipe disk jobs ships with Deployment Solution and can be found in the Samples job folder.

How to discover missing drivers for DeployAnywhere.

To determine if your DeployAnywhere database has the drivers needed for a particular computer, start the computer in question using WinPE and run the following DeployAnywhere command:

ghdplyAw32.exe /target=c:\Windows /ddb=DriversDB /eval

If a mass storage or NIC driver is missing, a list of the missing drivers is displayed on the screen and are also stored in a text file named ghDplyAw.txt.

This discovery process can be automated using a Deployment Run Script task (configured for WinPE) using the following in a Deployment Run Script task:

cd \Ghost

ghdplyAw32.exe /target=c:\Windows /ddb=\DriversDB /eval

Important: The previous task only works if the SmeUtil.sys driver is in the \Windows\System32\Drivers folder of WinPE. This driver is found in the Ghost folder in your Deployment Share. It can be added to the WinPE automation during the creation or editing process by right-clicking the Drivers folder and selecting

Add File.

As an alternative, the SmeUtil.sys driver can be copied by adding the following command to your run script task:

Copy %ALTIRIS_SHARE%\Ghost\SmeUtil.sys %SystemRoot%\

System32\Drivers

Download Snapshot failed: HTTP error: 404 Not Found (-2147209951) when attempting to download packages

Problem/Symptoms

When attempting to download a package through an IIS-enabled Package server, the following error messages are seen in the Altiris Logs:
Priority: 1
Date: 9/18/2008 2:03:18 PM
Tick Count: 26759250
Host Name: ------
Process: AeXNSAgent.exe (4744)
Thread ID: 1648
Module: AexPackageDelivery.dll
Source: PackageDownload
Description: Download Snapshot failed: HTTP error: 404 Not Found (-2147209951)

and

Priority: 1
Date: 9/18/2008 2:03:18 PM
Tick Count: 26759250
Host Name: ------
Process: AeXNSAgent.exe (4744)
Thread ID: 1648
Module: AexPackageDelivery.dll
Source: PackageDelivery
Description: Error while downloading package: HTTP error: 404 Not Found (-2147209951)

---

Environment

Notification Server 6.0 SP3 R7

IIS-enabled Package Server

---

Cause

In This case, the client computers were unable to generate their package snapshots becuase Active Server Pages were not enabled in IIS on the package server.

---

Resolution

To resolve this, we:

1) Checked the snapshot file in the GUID Folder on the Client and found that it was unable to generate a snapshot.

2) We checked the IIS logs on the Package Server, and found that the client was receiving 404 errors when it was attempting to generate its snapshot.

3) We Enabled Active Server Pages in the IIS Manager on the Package Server, and the client was then able to generate its snapshots. This is found in the IIS Manager under 'Web Service Extensions' in the main menu tree.

Altiris licensing technical FAQ

Applies To

• Inventory for Windows 6.0, 6.1
• Notification Server 6.0
• Patch Management 6.1, 6.2
• Software Delivery

---

Question

How does Altiris licensing work for Notification Server based products?

---

Answer

Overview

This article discusses licensing for each of the Altiris Notification Server based solutions:

• How a license is consumed.
• What happens when the license count is exceeded.
• What happens when a time limited (demo/install) license expires.
• What happens when the Automatic Upgrade Protection (AUP) expires.
• How to recover a solution license (retirement vs. deletion).
• Anomalies in expected functionality.

Inventory Solution for Windows

• License consumption—A license is consumed after the Notification Server has received the first posted software inventory data from a managed computer. A license is not consumed from the existence of the inventory solution agent on a managed computer. A license is not consumed by the "basic inventory" function of the Altiris Agent.
• License count exceeded—Inventory from licensed nodes will continue to be processed. Incoming inventory data from unlicensed nodes is discarded.
• License expiration (only applicable to Trial or otherwise temporary licenses)—Agent rollouts will still occur without a problem. All new incoming inventory data is discarded. Inventory reports will throw a license error.
• AUP expiration—All functions will continue normally. However, if newer versions of the solution are installed, they will not function.
• License recovery—As of Inventory Solution 6.1 SP2, setting the status of the computer to anything but Active will release a license.  In prior versions, only Retired, Return to Lessor, and Disposed computers will free up a license. Deletion of the computer resource record will also release a license.
  NOTE:  Inventory Solution specific data on Retired, Return to Lessor and Disposed computers will be purged as part of a background process that runs each night.

Software Delivery Solution for Windows

• License consumption—A license is consumed the first time a managed computer requests a software delivery task. The prerequisites for this event would be the assignment (via the Notification Server console) of a software delivery task to a managed node that has the Software Delivery Solution agent installed. A license is not consumed from the existence of the Software Delivery Solution agent and/or the Task Synchronization agent on a managed computer.
• License count exceeded—All agents that attempt to obtain Software Delivery Tasks beyond the allowed node count will stop receiving the task details in their client policy files.
• License expiration (only applicable to Trial or otherwise temporary licenses)—Agent rollouts will still occur without a problem. Software Delivery jobs will be no longer be advertised to clients, including newer schedules for existing tasks.
• AUP expiration—All functions will continue normally. However, if newer versions of the solution are installed, they will not function.
• License recovery—Retired computers will not release a license.
  • Computers can be deleted to release a license
  • For unmanaged computers, the event deletion in Data Purging for Software Delivery can be used to clear out old records and free up licenses. This will not work for systems actively using Software Delivery Solution.

Patch Management Solution for Windows

• License consumption—A license is reserved the first time a managed node posts the results of an inventory rule scan to the Notification Server or requests a software update package. A license is not consumed from the existence of the Software Update, Inventory Rule, and/or the Package agent on a managed computer.
• License count exceeded—All agents will stop receiving new software update policies. The Notification Server will refuse to download new (the pmimport.cab file) patch management data from the Altiris Web site. Newly posted Inventory Rule scanning data will be silently discarded by the Notification Server.
• License expiration (only applicable to Trial or otherwise temporary licenses)—Software Update Agent rollouts will still occur without a problem. Inventory Rule scanning and Software update tasks will be no longer be advertised to clients, including newer schedules for existing tasks. The Notification Server will refuse to download new (the pmimport.cab file) Patch Management data from the Altiris Web site.
• AUP expiration—Pre-existing software bulletins will be available for enablement and deployment of their related software updates. The Notification Server will no longer be able to download updated versions of the PMImport.cab file. Software update policies and inventory rule scans will continue to function. However, it will not be possible to obtain updates for new bulletins and their corresponding inventory rules due to the inability to update the pmimport.cab. If a newer version of the solution is installed, it will not function.
• License recovery—Retired computers will not release a license. Computers must be deleted to release a license.

Notification Server 6.0 SP3 R9 Release Notes

Release Notes for Altiris® Notification Server™ 6.0 SP3 R9

Installation and Configuration

Fixes in this Release

Known Issues

Additional Documentation

Installation and Configuration

Rollup 9 (R9) for Notification Server 6.0 is a rollup of fixes to the core product since the release of Service Pack 3. It includes R1 (KB22690), R2 (KB23784), R3 (KB25133), R4 (KB27859), R5 (KB31946), R6 (KB34317), R7(KB35803), and R8(KB39159)

Note: We do not recommend uninstalling R9 as it contains essential fixes. If you experience problems after the installation, please contact Altiris Support Services at www.altiris.com/Support.

Prerequisite Software

Notification Server 6.0 SP3 (build 6.0.6074)

Installing Rollup 9 (R9) for Notification Server 6.0 SP3

Download Altiris_NS_6_0_SP3_KB39160.exe from the following location:

http://www.solutionsam.com/solutions/6_0/Altiris_NS_6_0_SP3_KB39160.exe

Run Altiris_NS_6_0_SP3_39160.exe on the Notification Server.

Note: R9 includes an updated version of the Altiris Agent. After installing R9 onto the Notification Server, the Altiris Agent package will be updated. The upgrade policy is located in the Configuration tab of the Altiris Console under Configuration > Altiris Agent > Altiris Agent Rollout.

Fixes in this Release

The following issues were resolved in this release. For additional information regarding a fixed issue, click on the Article ID link.

Fixed Issues

https://kb.altiris.com/article.asp?article=39160&p=1

Known Issues

• If Helpdesk Solution is installed on the Notification Server, install R9, then go to KB43862 and follow the additional steps in the resolution section of that article.
• If IT Analytics is installed on the same computer as the Notification Server, wait to install R9 until after a new release of IT Analytics. R9 causes the current version of IT Analytics to stop working correctly. See article 40366.
• "PackageDownload Download Snapshot failed: Failed to create NS Client component. Error number: 46. Error description: Permission denied". See article 1751 for the workaround.

If a Package is deleted on the server and clients still have the packages, the events generated from the packages will cause ItemNotFoundException errors.

Question

If a Package is deleted on the Notification Server and clients still have the packages, the events generated from the packages will cause ItemNotFoundException errors.

Answer

The default setting for deletion for all SWD packages on the local client machine is 7 days.  If the Package is deleted on the server and clients still have the packages, the events generated from the packages will cause ItemNotFoundException errors.

The 7 days begins from the time the client no longer sees the package in the Client Configuration XML sent from the server.

As such, this is the best practices for retiring/deleting packages:
1. Disable all tasks associated with the package (if a task is enabled, and a client has that task, the 7 days will not start until that task is gone or removed).
2. Tasks can be deleted very quickly since an updated Client policy XML will stop any events for that task from being generated.
3. 7 days after the tasks were disabled/deleted, delete the package.

How to use Ghost 'Hot Imaging' to create images while the computer is running

Question

How do you use Ghost "Hot Imaging" to create an image while the computer is running?

Hot imaging is the ability to create an image of a computer while the computer is running the production operating system. For example, with Ghost hot imaging, you can create an image of Windows XP while you are logged on and using Windows XP.

While the image is being created, you can continue to work in the production operating system, but any file changes made after the imaging process is started, will not be captured in the image.

---

Answer

Hot images are created by running Ghost in the production operating system. This can be accomplished from a command prompt or from a Deployment Server Run Script task.

(Important: When using the hot imaging feature of Ghost, you cannot save the image being created to the same partition that is being captured in the image. Hot Imaging has been disabled for all Server operating systems.)

Sample Deployment Run Script Task:

REM Map a drive

net use z: \\Provo\express

REM Run Ghost to capture image

Z:\Ghost\Ghost32.exe -clone,MODE=create,SRC=1,DST=Z:%COMPNAME%.gho -sure

Important: The only spaces in the preceding script are located before a dash. Do not put spaces after the commas.

The following information explains the command-line switches used in the sample script:

Command or Switch	Description
Z:\Ghost\Ghost32.exe	The path and name of the Ghost program being used.
-clone, MODE=create,SRC=1,	Create an image of drive 1.
DST=Z: COMPNAME%.gho	Create the image on the Z: drive. The variable of %COMPNAME% will be replaced with the name of the computer being imaged. The path used to store the image cannot be the same partition that is being captured.
-sure	Eliminates the need to manually confirm the creation of the image.

(Important: Configure the task to run in the production environment using the Security Context of either Specific user or Run script in console user session. The account used, must have rights to create the image on the destination server.)

Deployment Solution 6.9 SP1 uncompressed WinPE preboot images

Question

What do I need to know about using uncompressed WinPE preboot images in Deployment Solution™ 6.9 SP1?

Answer

In some cases, choosing the option in the Boot Disk Creator to create an uncompressed WinPE preboot image produces a preboot image that does not connect to the Deployment server and does not perform jobs.
The default option is to create a compressed WinPE preboot image. You must explicitly select that you want to create an uncompressed WinPE boot image. If you manually changed this option to produce an uncompressed image and if that image boots into WinPE but does not connect or respond to the Deployment server, use the compressed option instead.

When upgrading to DS6.9SP1 then check if the compression is selected when (re)creating the WINPE. Maybe it would be a good idea to recreate you (old) WINPE boot file.

Thx David and Stephane

Fix Available: Cannot schedule jobs using Active Directory group authentication on Deployment Solution 6.9 SP1

Problem/Symptoms

Active Directory (AD) users that are imported into the Deployment Server database via Active Directory Groups do not have rights to schedule jobs.

Steps to reproduce:

1. Add an AD group to Deployment Solution.  Assign the group the 'Administrator' right to the console.  
2. Do not add the specific AD user.
3. Login as a user that from the AD Group.
4. Attempt to schedule a job.
5. The right to schedule a job is not available.

Note: If the 'Evaluate Rights' button is viewed the rights for the specific AD group will evaluate successfully (as though they have the rights).

---

Resolution

Symantec has created a hotfix to resolve this issue.  Follow the steps below to install the fix:

1) Shutdown all Deployment Server consoles.
2) Stop the 'Altiris Express Server' service.
3) In the Deployment Server directory (E.g. C:\Program Files\Altiris\eXpress\Deployment Server) rename express.exe to express.lic.
4) Download the updated 'Express.exe' to the the Deployment Server directory.
5) Open the 'Product Licensing Utility' and use 'express.lic' from the Deployment Server directory to license the new  express.exe file.
6) Start the 'Altiris Express Server' service.

Note: The express.exe included in this KB is the same express.exe used in KB 44220.

Deployment Solution 6.9 SP1 supported platforms and system requirements

Question
What platforms are supported by Deployment Solution 6.9 SP1?

More info on the supported platforms can be found here

DS 6.9 SP1 features

Introduction

Deployment Solution 6.9 SP1 software helps reduce the cost of deploying and managing servers, desktops, notebooks, and thin clients from a centralized location in your environment. It's an easy-to-use, automated deployment solution that offers OS deployment, configuration, PC personality migration, and software deployment across different hardware platforms and OS types. In SP1, we added support for Microsoft Windows Vista and Windows Server 2008, including running 32-bit applications on 64-bit platforms (WoW support).

The following are features of this release BUT still in BETA so not confirmed:

• Enhanced Vista 2008 management
• Updated WinPE installers
• Added that Deployment Solution now runs on Windows 2008 servers
• Added support for 64-bit servers (Wow 64)
• Added support for disabling and enabling NICs (network interface card)
• Added SQL 2008 support
• Added that DAgent now supports remote control
• Added that DAgent is now the default agent for Windows clients
• Added support for UNC imaging
• Added a sample job for upgrading AClient to DAgent
• Enhanced rip and replace to specify the jobs that are replayed
• Enhanced user rights
  • View only the computers and jobs that you have the rights to manage
  • Limit access to master return codes

How to check the status (active, retired , etc) of a machine?

1. You change/view the status of a computer under Altiris Console, click the Resources tab > Resources > Defaults.

2. Import the attached report into the reports tab or create your own using SQL like the following. that can help to identify retired machines.
Run it against Altiris database. ( replace 'retired' to the status you want to check).

SELECT     i1.Name AS Asset, rt.Name AS [resource type], i2.Name AS
Status, i1.Guid
FROM         ResourceAssociation ra INNER JOIN
                      Item i1 ON i1.Guid = ra.ParentResourceGuid INNER
JOIN
                      Item i2 ON i2.Guid = ra.ChildResourceGuid INNER
JOIN
                      ItemResource ir ON ra.ParentResourceGuid = ir.Guid
INNER JOIN
                      ResourceType rt ON rt.Guid = ir.ResourceTypeGuid
WHERE     (ra.ResourceAssociationTypeGuid =
'3028166F-C0D6-41D8-9CB7-F64852E0FD01') AND (i2.Name LIKE 'retired')

After running AD Import, new computers don't appear under active collections or OU collections

Problem/Symptoms

AD Import is not importing all computers. Some computers were added about four or five weeks ago in the Network.
The Altiris Agent was installed on the new computers. Then, those new computers were added in the AD domain.
AD Import (Full Import) is run but the new computers are not being imported into Notification Server via AD Import.

The Altiris Log Viewer does show that the AD Import found those computers when Trace was enabled in the Log Viewer.
However, these computers are not being populated into the OUs collections or All Computers collection.

---

Environment

Notification Server 6.0.6074 SP3 + R*
Active Directory Connector 6.1.842
AD Connector Hotfix 3 (KB34704)

---

Cause

Verified the status for those machines. The computer names were used in the past and then retired. These client machines were built over the last few months but the names were previously used sometime last year then decommissioned.  Their Purging maintenance is set to 1 month and to Retire only.
The computer names are being re-used.  The GUID is then created based on the name and domain so they are the same as the previous retired computer names.

---

Resolution

Find the computer in a report or in the Altiris Console by clicking the Resources tab > Resources > Defaults.
Right-click the row the computer is listed on, click Set Asset Status, and select the wanted status. (In this case it was changed from "Retired" to "Active".)

As well, you can create your own report to identify what computers are set to Retired. See Article ID: 24473 "How to check the status (active, retired , etc) of a machine?" as example.

Beta II CMS Installation Error on PCANYWhere

Error 1603 on PCAnyWhere during installation of Beta Refresh II

You need to do 2 things

1) create a Group Policy when on a domain or a Local Policy on a standalone:

Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies (if there isn't one, create one), Right Pane, Double-click Enforcement, change bottom radio button to All users except local administrators

2) Run then MS KB 925336

If you are NOT on a Domain and use Local Policy then this is the regkey to check:

Open HKLM\Software\Policies\Microsoft\windows\safer\codeidentifiers and see if there is a DWord entry called "PolicyScope". If it's not there, create it, and set the value to 1.

Thx to Beta Forum thread : Beta Forum

HP SoftPaq Download Manager

HP SoftPaq Download Manager provides a simple, powerful way to download software updates for the HP client PC models in your environment. HP SDM can significantly reduce the amount of time it takes to locate and download updates. SoftPaqs can be downloaded in as few as three easy steps from a single user interface after initial setup.
Easy to use
Locating files is a snap using HP SoftPaq Download Manager. Simply select the desired models, operating systems and languages, then click Find Available SoftPaqs. All available softpaqs matching the selected criteria will be displayed in a friendly interface. Next, check the updates you wish to download, then click the Download button.

Download here : HP Download Manager

Collections cannot be deleted because Notification Server believes they are being referenced by an item

---

Collections cannot be deleted because the Notification Server believes that they are being referenced by at least one item; however, when the dependency page is opened there are no items listed.

---

Cause

The collections were being referenced by orphaned polices. These items were not being displayed in the dependency page, as they were not visible within the Altiris Console even though they did not have the hidden attribute assigned to them.

---

Resolution

1. Enter the collection guid into following query, as it will find all ParentItemGuid's associated with that collection.
   SELECT ParentItemGuid FROM ItemReference WHERE ChildItemGuid = 'CollectionGuid'
2. Enter all ParentItemGuid's (normally just two) into the following query, as this will tell you their names and descriptions. One should be a folder and the other a policy.
   SELECT [Guid],[Name],[Description] FROM Item WHERE [Guid] IN ('parentitemguid',parentitemguid')
3. Grab the GUID of the policy and use it with the findtreeitem.exe (attached) as this will tell you where in the console that item can be found. These orphan items will most likely not be visible in the console when you check, confirming that you can delete them.
4. Enter policy GUID into delete script creation query and run it.
5. Copy the created delete script to new window and run it.
6. Run the creation query again. If it returns a "delete from" row, then perform step 5 again, and then step 6. If no "delete from" row is displayed, the item has been deleted and you should be able to delete the collection now.