The following information is provided as a reference to help to understand how the Symantec Management Agent (Altiris Agent) Download process works. More information can be found at the bottom of this article under "Additional Information".
ITMS 8.x
When the Altiris Agent (current name is Symantec Management Agent) begins the download of a package it first profiles the speed of the package sources returned to it through a GetPackageinfo request to see which source it considers to be the fastest.
If the HTTP and UNC speed profiled for a target source is the same, then the Altiris Agent will first choose to download via HTTP as a preference.
If the download fails, an error is recorded against the HTTP source from which the download failed and the Altiris Agent will go into a waiting to retry download state.
The Altiris Agent will attempt to retry the download of packages at the following incremented intervals - 3 minutes, 6 minutes, 12, 24, 48, 96, 120 and then every 2 hours until the package download completes successfully.
If a package is in a waiting to retry download state and the Altiris Agent succeeds to download a portion of the package, then the download retry interval will be reset and any further failures for the package will cause a retry after 3 minutes.
When the Altiris Agent selects a source for download it takes into account the amount of errors recorded against an available source and then decreases the speed as outlined below.
1 error = 95% of profiled speed
2 errors = 90% of profiled speed
3 errors = 75% of profiled speed
4 errors = 60% of profiled speed
5 errors = 35% of profiled speed
6 errors = 10% of profiled speed
More than 7 errors = 0% of the profiled speed.
Note: Errors will continue to be stacked until a maximum of 20 errors are recorded, however the source is considered invalid after 7 errors.
Once the error is recorded against a source it will be kept for 150 minutes and then removed.
An example of the above speed reduction would be; if the profiled speed for a source (either HTTP or UNC) is 10MByte/s, and there is one error recorded against it, then it would be considered as having a speed of 9.50 MByte/s.
The actual speed at which the package will be transferred to the client machine is not decreased. The decrease of server speed is an internal calculation that the Altiris Agent performs, when making the choice of which server source is the most desirable.
Below is an example of how the Altiris Agent uses speed reduction to pick a server source:
- Server 1 has a profiled speed of 10Mbyte/s with 5 errors
- Server 2 has a profiled speed of 5Mbyte/s with 1 error.
The Altiris Agent makes it choice based on which is the highest profiled speed after error deductions on the speed have been calculated.
The source that would be chosen by the Altiris Agent is Server 2 as it has a reduced speed of 4.75 MByte/s and Server 1 has been reduced to the lower speed of 3.50 MByte/s.
1 - Server source speed and error expiry defaults:
The speed of a server source is kept for 6 hours by default as per the below registry key value:
HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Communications\Speed Expiry (mins)
The errors recorded against a server source are kept for 2.5 hour by default as per the below registry key value:
HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Communications\Error Expiry (mins)
2 - Bandwidth Throttling:
By default the agent will download packages at the full connection speed. Bandwidth throttling is turned on via the Targeted Agent Settings policies > Downloads tab.
Bandwidth Throttling limits the speed to either a hard limit in Kbyte/s or as a percentage of the total connection speed to a particular source. When a percentage value is entered this means that once the agent has profiled the speed to the Package Server sources returned to it, that it will download at the specified percentage of the profiled speed to the chosen source.
i.e. If 10% was specified and the speed to a Package Server is profiled at 10MB/s it will download the package at 1MB/s
Within the Agent Settings > Download tab, the following setting is enabled by default 'Only throttle if bandwidth is below 50 Kybtes'. For ease of testing you should disable this setting so that the agent will always bandwidth throttle regardless of the current connection speed.
When testing bandwidth throttling from the agent side you should always have trace logging enabled, as the transfer rates are recorded in trace level logging, example log message below, where a value of 10 Kbyte/s has been chosen.
BandwidthManager AeXNetComms.dll Transferred 262.144 KBytes in 26.234 seconds at 9.992 KBytes/s |
The transfer rate may not always be to the exact rate specified, however it should be very close.
Within the Altiris Agent UI on the left hand pane there is an Options window, option - 'Enable Bandwidth Control'. When this is enabled the agent will throttle the download of packages as configured. However if the option is disabled the agent will ignore any throttling settings configured for it. This option can be toggled mid way through a current package download, if desired.
3 - Disk Space Check:
The Altiris Agent and Package Server calculate the space requirement for package download based on a couple of things. There is a registry key called 'Min Disk Free Space (Mbytes)' at the following location on the Agent machine.
HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Communications\Package Delivery
This key is set to 500MB by default. It works out to be 500MB+120% of the package size. So for example, if the package is 100Mb in size, it first checks to see whether there is 620MB of free space available at the default install location, if there is not it will check whether any other drive has this space available and download there, if no other drive has this space then it will not download the package.
4 - Drive Overflow:
The Altiris Agent and Package Server have a package download drive overflow method. If there is not enough space to download a package to the default install location (eg, C drive) then the Altiris Agent or Package Server will download the package to the next available drive with the required space.
5 - Package Snapshots:
If Package Server packages are stored on an alternate drive or an alternate download destination, the package snapshots for these packages always remain at the default Altiris Agent install location.
6 - Package Access for downloads:
When the Altiris Agent downloads a package it uses the Agent Connectivity Credential (ACC) to connect if challenged. The ACC is specified within the Global Agent settings page > Authentication tab
By default the ACC is set to the Application Identity account (NS Installer account). Since the SMP installer account is usually an account with a high level of rights such as a domain admin, best practice is to change this to a low level user account.
Downloads via HTTP - The Altiris Agent first connects anonymously, then if the request is challenged due to IIS being locked down at the source, it will try again using the Agent Access Credentials (ACC).
Downloads via UNC - The Altiris Agent first connects using the computer account, if that fails it will connect using the ACC, and if that fails it will try to use the logged on user credentials.
7 - Checkpoint Recovery
When the agent is downloading a package the process can sometimes be interrupted due to many different reasons. At this time the agent will cache the portion of the package it has already downloaded. The agent will enter a waiting to retry download state and attempt the download again after a short period of wait time. The agent will pick up the download where it left off, using the cached portion of the downloaded files.
Note: Packages which are downloaded via Package Multicast do not utilize checkpoint recovery, i.e If a multicast package download is interrupted mid way through, it will pick up the download from the beginning when it retries.
8 - GetPackageInfo Global backoff
Package Delivery has backoff logic specifically for errors encountered when visiting GetPackageinfo.aspx. When either the Agent or Package Server has an error getting packageinfo it will backoff starting at 3 minutes and doubling. During the backoff duration, no Package Info requests can occur, so it is a global backoff.
Existing code means if a package fails to download sources there is a global backoff time which gets set and no packages can get sources during that period. If a package tries to get sources and cannot because of this global backoff it will now utilize the 'delayed' concept - rather than incrementing its retry count and doubling its individual package delay, it will leave the retry count alone, and schedule itself to retry immediately after the backoff completes. Otherwise the existing behaviour is mostly maintained. The one exception is that if a specific package fails to get sources and its current delay is not already a long time, it will be scheduled to be at least 1 minute after the current global backoff time.
This 1 minute is to ensure that other packages which get delayed by the global backoff get first chance at download sources, before that other package potentially causes yet another global backoff.
Even in the case that that 1 minute is insufficient to get many packages started, that failing package will be experiencing exponential increase in its back off, while other packages will be only limited by the global back off delay.