FAQ on Package Servers: Behavior, Configuration, and Troubleshooting
search cancel

FAQ on Package Servers: Behavior, Configuration, and Troubleshooting

book

Article ID: 150861

calendar_today

Updated On:

Products

IT Management Suite Client Management Suite

Issue/Introduction

This article is a reference for Package Server behavior, configuration, and known troubleshooting scenarios in ITMS 8.x. It covers IIS virtual directory management, package delivery and validation, disk space handling, registry keys that control Package Server behavior, SQL database tables, events, package share creation, primary file storage location, automatic Package Server assignment, token-based authentication, and a set of frequently asked questions.

Note: Details in this article are subject to change as the product is updated. Confirm behavior against the customer's specific release before using this content.

Environment

ITMS 8.7.x, 8.8.x

Resolution

Table of Contents

How Package Server fits into package delivery

A Package Server hosts copies of packages so that Software Delivery agents in a site can download package content locally instead of pulling it from the Notification Server (NS) directly. The NS remains the source of truth for package assignment, policy, and the package snapshot signature. Package Server's job is to keep a synchronized local copy, publish that copy as one or more codebases (UNC and/or HTTP/HTTPS access points), and report its status back to the NS through summary events.

The most common failure points fall into three categories: the local copy diverging from the NS-defined package (staleness, invalid status), the codebase publication step failing (missing shares, IIS misconfiguration, credential issues), and disk or permission constraints on the Package Server host itself. Sections 1.0 through 8.0 below cover each of these in turn.

1.0 — Package Server and IIS

  • If IIS is installed after Package Server, restart the Altiris Agent service before virtual directories for downloaded packages are created. Clicking Refresh Packages in the Package Server UI does not create them in this situation.
  • If IIS is not installed on the Package Server and a non-default download location is specified as a local path on the Package Server, no codebases are sent to the NS for that package. Package Server only creates the default share PkgSvrHost and cannot assume a share exists for a custom local location.
  • Package Server sends an IIS log summary event to the NS every 24 hours; view it in the Events tab of Resource Manager. The Connection Count field shows the number of client connections to a Package Server virtual directory. A client that connects more than once for the same package is not re-counted.

Starting in ITMS 8.5, Package Server changed how it creates and updates IIS virtual directories: it moved from the legacy IIS6-Metabase-compatibility approach to the native IIS API, which reads and writes IIS's applicationhost.config file directly. The logic that decides when a virtual directory needs creating or updating did not change — only the mechanism did.

In an environment with a small number of virtual directories, this has no visible cost. In an environment with thousands of virtual directories — most commonly caused by heavy use of custom package destination locations, where each custom-path package gets its own virtual directory — applicationhost.config grows large enough that IIS spends noticeably longer reading and writing it on each update, on the order of one second per virtual directory rather than milliseconds. Because Package Server must finish updating virtual directories before it queues new downloads with Package Delivery, an extended refresh cycle can also delay or block new package downloads for that window, in addition to elevated CPU usage on the site server (w3wp.exe).

1.1 — Recurring virtual directory creation/update messages

Symptom: The agent log repeatedly reports virtual directories being created or updated.

A fix (ITMS 8.5 pointfix, carried into 8.6 RU1) added a cached list of virtual directories so a refresh is skipped unless one of these applies: a mandatory condition, a user-initiated "Resend all statuses," or a policy change affecting all packages (HTTP/UNC setting change, credential change, or storage location moved).

Verification signal: confirm the fix is active by checking the agent log for the following line:

Skip virtual directories and file shares refresh.

Re-enabling the legacy IIS6-compatibility mode through the UseLegacyIISAPI registry key is available but not recommended for performance. See section 5.4.

2.0 — Package Delivery

2.1 — Updated packages

Each package is stored under its own GUID folder. The package files reside in the cache folder, for example:

C:\Program Files\Altiris\Altiris Agent\Package Delivery\{6C821F5E-5BF4-407F-A6FF-ABB85EEE0418}\cache

When Package Server receives configuration for an updated or changed package, it does the following in order:

  1. Temporarily removes Agent Access Credential (ACC) permissions on the package root folder under cache, leaving only System and Local Administrator rights. Agents using the ACC cannot reconnect during this window.
  2. Scans the files in the package and closes any open files.
  3. Disconnects any agent currently downloading the package; the agent retries at its usual interval.
  4. Downloads the updated package to the Package Server.
  5. Restores ACC permissions to the cache folder.

2.2 — Invalid packages

A package shows as invalid in the Package Server UI when any of the following apply:

  • An SWD package specifies a non-default download location that does not exist on the Package Server (for example, X:\folder1).
  • An SWD package specifies a non-default download location that exists but is not shared.
  • There is not enough disk space to download the package to the Package Server.
  • Anonymous access to package codebases is disabled and the configured ACC cannot be applied to the downloaded files — for example, the ACC is an untrusted account.

2.3 — Deletion of unused packages

The setting for when Package Servers delete unused packages is on the Settings tab of the Package Server page. The countdown to remove package files on a Package Server starts only when the package is unassigned from that Package Server, or the package is deleted from the NS database. Both situations stop the package from being sent to the Altiris Agent in the Package Server node of the configuration XML file.

At that point, Package Server updates the PackageStatus.xml file it stores for the package, sets the Status flag to Deleted, and sets the Time flag to the removal time. The package status files are located, on a default install, at:

C:\Program Files\Altiris\Altiris Agent\Package Server Agent\Package Status

At each Package Server refresh, Package Server checks for a Deleted flag in the Package Status files. If the corresponding Time flag has passed the configured duration for deletion of unused packages, Package Server removes the package files.

This local cleanup is one side of package removal. The client separately maintains its own reference to package state in AeXSWDPolicy.xml. Prior to ITMS 8.8.1, when a package was removed by the CleanupExpiredPackages process, its entry was not immediately cleared from AeXSWDPolicy.xml. This could leave a stale client-side reference and cause repeated attempts to interact with a package that no longer existed.

Fixed in 8.8.1: the entry is removed from AeXSWDPolicy.xml immediately when the package is deleted by cleanup, and also when a Quick Delivery or Package Delivery task is configured with "Delete immediately, 0 days," regardless of whether the task succeeded or failed.

Notification Server policy — not the local files in the Package Delivery folder — determines whether a Package Server should hold a package. Manually deleting a package's local files or secure-storage metadata clears only that local copy; if policy still assigns the package to that server, the package is re-requested on the next retry cycle.

Packages sent with urgent priority are tracked separately in:

<Package Server root>\PackageStatus\UrgentList.xml

There is no supported way to remove a single entry from that file — only the file as a whole.

2.4 — Disk space check

The Altiris Agent and Package Server calculate the space requirement for a package download using a registry key on the agent machine:

HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Communications\Package Delivery

Min Disk Free Space (Mbytes)  — default 500

The requirement works out to 500 MB plus 120% of the package size. For example, for a 100 MB package, the agent first checks whether 620 MB of free space is available at the default install location. If not, it checks whether any other drive has that space available and downloads there. If no drive has enough space, the package does not download.

2.5 — Drive overflow

If there is not enough space to download a package to the default install location (typically the C: drive), the Altiris Agent or Package Server downloads the package to the next available drive with the required space.

Package snapshots always remain at the default Altiris Agent install location, even if the associated package is stored on an alternate drive or destination.

Disk quotas behave differently from drive overflow. The disk space check and drive-overflow logic above apply to available free space on a drive. An NTFS disk quota configured on the drive hosting the agent and its packages is a separate condition and does not trigger the same overflow behavior. If a quota is in place and Package Server fills it, Software Delivery has been observed falling back to creating GUID-named folders directly under C:\windows\system32 and downloading there instead — filling the system drive and potentially degrading OS performance — rather than following the drive-overflow path to another drive.

This has been addressed so that Package Delivery fails the download outright if its working folder is not set correctly, instead of falling through to the system32 fallback. One behavior to expect afterward: by design, a failed or incomplete package retriggers a download attempt every minute until it succeeds or is marked invalid, so logs can grow quickly while a quota condition persists. Resolving the quota configuration itself remains the actual fix.

2.6 — Packages stored in non-default locations

When a non-default location is specified for Package Server to download to, and a local path is specified (for example, C:\folder) that does not exist, Package Server creates it when downloading the package. Package Server does not create a share for this package, so a UNC codebase for this package type is not sent to the server — only HTTP is sent.

A non-default location on the Advanced tab when creating an SWD package can be specified as \\%computername%\share, where %computername% is substituted with the local host computer name. Share is a shared folder that must already exist on the hard drive of each Package Server receiving the package.

Package Server does not create shares, except the primary share PkgSvrHostC$. If the specified folder does not exist or is not shared, Package Server does not download the package and sets its status to invalid. If the shared folder exists, Package Server sends UNC codebases to the NS for this UNC alternate download location.

Custom destination locations must be unique per package. The "Use custom package destination location on package servers" setting — whether applied per-package or through Global MDP Settings — must point to a distinct folder for every package or task that uses it, including generic shared paths such as C:\Temp. If two or more packages share the same custom destination, their file snapshots can overlap: cleanup or deletion of one package can remove files that another package's snapshot still references, while Package Server continues reporting the second package as Ready, because it has no way to detect that the underlying files are gone. This is the most common cause of a package showing Ready with missing files, or appearing deleted immediately after finishing a download.

2.7 — Package access

The Altiris Agent cannot download a package by UNC from a Package Server on a non-trusted domain; this produces an Access Denied error.

Package Service setting: Allow anonymous access to package codebases. Anonymous access effectively means all authenticated users are allowed when downloading by UNC. Even if a Package Server in a non-trusted domain has anonymous access enabled on its files, if the ACC account the Altiris Agent uses to connect anonymously to the UNC source cannot be authenticated, access is denied and no download occurs.

When downloading by HTTP from a Package Server in a non-trusted domain using anonymous access, the download occurs with no access issues.

3.0 — Package Server related SQL database tables

Table

Description

SWDPackageCodebase

Lists all NS and Package Server codebases for hosted packages. A NULL Source column indicates an NS codebase; otherwise the value is the GUID of a Package Server.

SWDPackage

Details of an SWD package, including versions. When a package changes, a new row is added for the same PackageId (GUID); the row with _Latest = 1 is the current version.

SWDPackageServer

Details of which packages are assigned to which Package Server, and the status of each.

Evt_AeX_Package_Server_Package_Event

Download status events posted by Package Server. See section 4.0.

RM_ResourcePackageService

Resource association table. The GUID column is the parent resource GUID; the child GUID is the package server resource. A Deleted value of 1 means the package service has been selected for uninstall.

4.0 — Events sent by Package Server

Package Server generates events under the following conditions:

Scenario

Event sequence

New package downloaded

Start – Initial → New Package → Codebase enabled → End – Complete

Existing package updated

Start – Refresh → Updated Package → Codebase enabled → End – Complete

Valid package becomes invalid

Start – Refresh → Updated Package → Invalid Package → End – Invalid

Invalid package recovers to valid

Codebase enabled → End – Recover → End – Complete

New package that becomes invalid

Start – Initial → New Package → Invalid Package → End – Invalid

ACC cannot be authenticated on the Package Server

Codebase Disabled summary event, sent for each package hosted on the Package Server, with an error message

Credentials recover (ACC goes from unauthenticated to authenticated)

Codebase enabled summary event, sent for each package hosted on the Package Server

If a Package Server sends a summary event containing a package version older than what the NS has recorded, the NS disables the codebase for that package. The codebase status is set to Stale codebase in the database.

Package Status and Summary events report the size of each package and whether the package is managed locally or externally to the NS. This is communicated with an IsManaged flag in the summary event, indicating whether the package server owns the package. This lets packages be defined on Package Servers rather than on the NS.

5.0 — Package Server registry keys

5.1 — Package Servers download only from NS

The NS core setting Package Servers download only from NS only is enabled in NS core settings. Behavior depends on whether sites are defined:

Site configuration

Effect when the setting is enabled

No sites defined

Active — Package Servers only receive the NS as a download source.

Sites defined

Not active — treated as disabled.

5.2 — NoPACLockdown

Controls whether Package Server secures packages using the configured Package Access Credentials (PAC, now called ACC) or allows anonymous access.

HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Package Server\NoPACLockdown

Value

Meaning

1

Package Server does not lock down packages using ACC; it gives everyone access.

0

Package Server locks down packages using ACC.

5.3 — EnableDACLManagement

Controls how Package Server manages security on its packages. By default, Package Server sets specific permissions on package directories, overriding any custom permissions that have been set. When this key is enabled, Package Server no longer overrides existing permissions on package directories.

Use this key with care — incorrect permissions can render Package Server directories inaccessible to Package Server and Altiris Agents. To keep a Package Server fully functional, Full Control for the Local Administrator and System must exist on all package directories, in addition to any other custom permissions.

Altiris Agents and other Package Servers normally access packages on the Package Server computer using the Agent Connectivity Credential (ACC) configured on the NS. To ensure they continue to download packages after this key is enabled, configure the Everyone or ACC account with Read and Execute privileges on the package directories — because with the key active, Package Server does not apply the ACC or Everyone account to downloaded packages.

This key does not exist on a default install. Create a DWORD value under:

HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Package Server\EnableDACLManagement

Stop the Altiris Agent service before creating the key, and restart it when finished.

Value

Meaning

0

Package Server does not change existing security on package directories.

1

Package Server functions as normal, applying and resetting permissions on package directories.

5.4 — Virtual directory refresh timing

Under:

HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Package Server

  • IISVirtualDirectoriesRefreshInterval — minutes between full virtual directory refreshes; default 1440 (24 hours).
  • LastPackageRefreshTime — timestamp of the last full refresh; used with the interval above to decide whether a policy change should trigger a full refresh.
  • AgentExecInterval (sec) — agent execution interval; also a factor in refresh timing.
  • UseLegacyIISAPI — DWORD; a value greater than 0 switches Package Server back to the legacy IIS6-Metabase-compatibility approach for virtual directory management. The administrator must ensure IIS6-compatibility features are installed, since Package Server no longer checks for them automatically. Testing has shown this setting slows the refresh process rather than improving it, so it is not recommended as a general remediation. See section 1.0.

5.5 — Package download retry and backoff

Under:

HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Communications\Package Delivery

  • Retry delay (mins) — initial delay before a retry; default 3 minutes if not set, capped at 60 minutes if configured higher. Doubles on each subsequent retry.
  • Maximum retry delay (mins) — cap on the doubling above; default 2 hours if not set, capped at 1 day if configured.
  • Maximum download attempts — capped at 100; once exceeded, package status changes from RETRYING to INVALID.
  • Maximum download attempt time (mins) — capped at two weeks; same effect as the attempts cap once exceeded.

Retry counters reset on Altiris Agent service restart. Separately from per-package retry, if Notification Server returns no codebases at all for a request — server busy, server paused, or package not ready — the delay before the agent's next codebase request doubles, up to a 2-hour cap, and resets to the 3-minute minimum once codebases are received successfully again.

6.0 — Package Server settings

Site Server Settings > Package Service Settings > Allow anonymous access to package codebases.

Selecting this option grants anonymous "everyone" access to the Windows directories containing package files on Package Servers, and enables anonymous access for directory security in IIS for hosted Package Server packages.

If this option is disabled, the Agent Connectivity Credentials (ACC) specified in Global Altiris Agent Settings on the NS are used to secure the package server files. Likewise, HTTP virtual directories mapped to packages on the Package Server have anonymous access disabled and Integrated Windows Authentication enabled, so agents connecting for HTTP downloads are challenged to supply their ACC credentials.

The ACC must be a known account on the Notification Server and every Package Server. If the account cannot be validated on a Package Server — for example, a non-trusting domain, or a computer account from another computer — Altiris agents cannot download files from that Package Server. Package Server files can be secured with the ACC only if every Package Server recognizes the account specified.

Setting: Create the Agent Connectivity Credential on Package Servers (provided the ACC is not a Domain Controller).

In an environment where Package Servers span domains without a trust between them, a local computer account can be set as the ACC instead of a domain account. The local computer account must be a local administrator on the Notification Server machine, since this account updates distribution points on packages; it does not need to be an admin account on the Package Servers.

Enter the local user account as .\localuser or localuser, where localuser is the name of the local computer account. Do not enter the NS machine name as a prefix.

When specifying a local account as the ACC, use it together with Create the Agent Connectivity Credential on Package Servers. Enabling this option ensures that if the account does not already exist on all Package Server computers across trusted and untrusted domains, it is created locally and applied to the downloaded package files on each Package Server.

If a local account is specified as the ACC and this option is disabled, the local account must already exist on every Package Server. If it does not, that Package Server cannot apply security to downloaded packages and does not publish codebases as ready to the Notification Server.

Note: The ACC depends on certain operating-system configurations. Out-of-box OS configurations are recommended, since they reflect how the product was tested; deviations require extensive testing and verification. Known dependent configurations: (1) Security Policy > Local Policies > User Rights Assignment > Access this computer from the network must be enabled and include the ACC account. (2) The NetLogon service must be enabled and set to automatic startup.

7.0 — Package snapshot generation

A package snapshot is an XML manifest listing the files in the package location, along with their size, modified date, and SHA256 file hash. Package Server generates one snapshot XML per package, named <package_guid>.xml, stored at:

C:\ProgramData\Symantec\SMP\Snapshots

Each snapshot XML change updates the package version stored in the SWDPackage.PackageVersion column, and triggers regeneration of the snapshot XML signature. The NS signs the snapshot; the signature is stored in a separate file, <package_guid>.sig, in the same Snapshots folder. The GetPackageSnapshot.aspx response returns the signature file as a string, used for package integrity checks on the agent side.

8.0 — Package share creation

Package shares are created at the NS to support two consumers:

  • Package Servers downloading package contents.
  • The Software Delivery component of NS Agents downloading package contents directly, in environments without Package Server agents.

The NS creates both IIS and UNC shares where possible. Shares are created only for local, UNC, and URL package types, and are then transformed into codebases — the URI used as the actual download access point. Codebases are persisted in the SWDPackageCodebase table.

8.1 — Shares of local packages

For each local package, Package Server creates a UNC share named NSSWD_<packageGuid>, giving a full UNC codebase of \\NS_HOST\NSSWD_<packageGuid>. For each local package, an IIS virtual directory is either created, or — in roughly 99% of cases — an existing pkggroup virtual directory (below) is reused. Virtual directories are created under the /Altiris/PackageShare application.

8.2 — IIS package group shares (pkggroup)

To minimize the number of virtual directories created in IIS, a virtual directory points to the parent directory of the package location rather than the package location itself. For example, if a package location is:

C:\xxx\parent\A

the virtual directory (VD) is created pointing at C:\xxx\parent. If a second package is created at:

C:\xxx\parent\B

a separate VD is not created, because one pointing to C:\xxx\parent already exists. The common virtual directory name is pkggroup_<md5>, where <md5> is the MD5 hash of the parent folder. The generated codebases keep the correct paths, for example:

http://NS/Altiris/PackageShare/pkggroup_<md5>/A

http://NS/Altiris/PackageShare/pkggroup_<md5>/B

These resolve to C:\xxx\parent\A and C:\xxx\parent\B respectively.

Group shares cannot be created if the package location resides in any of the following restricted OS special folders:

  • Desktop, Internet Explorer (desktop icon), Start Menu\Programs, My Computer\Control Panel, My Computer\Printers, My Documents
  • %user name%\Favorites, Start Menu\Programs\Startup, %user name%\Recent, %user name%\SendTo, %desktop%\Recycle Bin, %user name%\Start Menu
  • My Computer, Network Neighborhood (My Network Places), %user name%\nethood, windows\fonts
  • All Users\Start Menu, All Users\Start Menu\Programs, All Users\Startup, All Users\Desktop, %user name%\Application Data, %user name%\PrintHood
  • %user name%\Local Settings\Application Data (non-roaming), non-localized startup and common startup folders, All Users\Application Data
  • C:\Program Files, C:\Program Files\My Pictures, C:\Program Files\Common (and the x86-on-RISC equivalents), USERPROFILE and its System32/CD Burning subpath
  • All Users\Templates, All Users\Documents, All Users and per-user Start Menu\Programs\Administrative Tools
  • Network and Dial-up Connections, All Users\My Music, All Users\My Pictures, All Users\My Video, the localized resource directory, links to All Users OEM apps, and Computers Near Me (workgroup membership)

8.3 — PackageGroupRoot (7.5 SP1 and higher)

The automatic parent-folder grouping in section 8.2 happens without configuration. For finer control, the PackageGroupRoot property lets a package explicitly declare a shared root folder, so multiple packages nested several levels deep under that root — not just direct siblings — consolidate onto a single IIS virtual directory and a single UNC share, rather than one per distinct parent folder. The codebase for each package is then the shared virtual directory path plus the package's location relative to the group root.

This property is consumed only during a package refresh, and applies only to local and UNC package types. It has no effect if the package's location is not a subfolder of the configured PackageGroupRoot, and it cannot be set on OS special folders or root drive letters (C:\, F:\, and similar).

For large sets of pre-existing ungrouped packages that already share a common root — a common scenario after upgrading a solution that manages thousands of packages, such as Patch Management or Software Library — the SWDSupport.RearrangePackageSharesForPackagesUnderFolder() API can register a candidate root location in bulk. The actual rearrangement then happens on the next non-post-upgrade package refresh for any package still located under that root.

8.4 — Shares of UNC packages

For a UNC package, the UNC share is not created at the NS host, because it either already exists (a UNC path pointing to a local physical drive at the NS that is already shared) or is a location on a remote machine.

The IIS virtual directory /Altiris/PackageShare/<packageGuid> is created, pointing to the package's UNC location. Either the ACC or the Distribution Point Credential (NS Console > Settings > All Settings > Notification Server Settings > Distribution Point Credential tab > "use these credentials") is set for the VD to access the UNC location. The resulting IIS codebase looks like http://ns/Altiris/PackageShare/<packageGuid>.

8.5 — Shares of URL packages

The IIS share for a URL package already exists — it is not created. The codebase looks exactly like the IIS share. If the virtual directory points to a UNC location (PackageItem.Directory is a UNC path), a UNC codebase is added as well.

8.6 — Share deletion

Each time a package refresh detects that a package has changed location, the old UNC share is deleted. Unused IIS shares are detected and deleted only during the package refresh task.

The Package Refresh task is an SMP scheduled task, running once a day by default, that performs a package refresh for every package in the system. This approach has two drawbacks worth flagging for engineers troubleshooting large environments: to some extent, the NS "auto-accepts" any package content as valid, and at 100,000 packages the refresh can take hours, during which the AexSvc process actively consumes disk I/O. For this reason, solutions should not rely on the Package Refresh task alone and should trigger a manual Distribution Points Update when a package's folder contents change deliberately. Two Package Refresh tasks do not run in parallel.

9.0 — Primary file storage location

Starting in ITMS 8.0, the primary file storage location for a Package Server can be changed on the Notification Server Package Service Settings page. Because this setting can be specified per Package Server, it gives the flexibility to manage different file storage locations on different Package Servers. This is an expensive operation not intended for daily use — treat it as an initial infrastructure setup step.

See "Configuring Primary File Storage Location for Package Servers Post-ITMS 8.x."

10.0 — Automatic Package Server assignment

Automatic Package Server assignment assigns packages to sites as required, to distribute the package to every party assigned to download it. It also supports removing those assignments automatically after they go unused for a configured number of days.

See KB "Automatic Package Server Assignment."

11.0 — Token-based authentication

ITMS 8.7.3 introduced token-based authentication as an alternative to ACC credentials.

Note: See "Using ITMS with Token-Based Authentication" 

12.0 — Package validation files and retry logic

Each package tracked by an agent is described by three metadata files, separate from the package binaries:

File

Purpose

package.xml

Contains the package GUID, the source public key of the package owner, and the codebase(s) to download from. Since 7.5, this file is transferred over an encrypted channel and stored in the agent's secure storage rather than in plain form on disk.

snapshot.xml

The file/folder manifest: file names, sizes, last-modified times, and SHA256 hashes. Immutable once received by the agent; its integrity is checked against the package owner's public key and a signed hash delivered by the Content-Signature HTTP header, or through snapdata.xml for UNC-sourced packages.

snapdata.xml

Carries the snapshot's signature plus additional local tracking information used by the Package Delivery framework.

12.1 — File validation on Windows agents

  • If the file does not exist locally, it is downloaded.
  • If it exists and matches the size and timestamp recorded in the snapshot, it is considered current and is not re-downloaded.
  • If the size matches but the modified date differs by more than a 2-second tolerance, the file is re-downloaded from the beginning.
  • If the local file is smaller than the remote copy, the download resumes from the next byte.

12.2 — File validation on Unix, Linux, and Mac agents

Validation differs slightly from Windows: a modified-time mismatch, or a local file larger than the snapshot specifies, triggers a full re-download. A local file smaller than the snapshot is re-downloaded in full if it is under 64 bytes; otherwise, the last 32 bytes are discarded and the download resumes from that point.

12.3 — Retry and backoff

Package download retry timing is governed by the registry keys in section 5.5. Two behaviors are worth calling out specifically:

  • Exceeding either the maximum attempts or maximum attempt-time setting changes a package's status from RETRYING to INVALID, rather than continuing to retry indefinitely.
  • Download queue position is based on priority, then delay, then size: packages not currently in a delay period are ordered first by priority (high to low), then by delay (low to high — fewer prior retries goes first), then by size (smallest first). A package preempted by a higher-priority package restarts immediately once the higher-priority download completes, without incurring the normal retry delay, since a preemption is not treated as a failed attempt.

13.0 — How GetPackageInfo resolves download locations

When an agent or Package Server needs a package, it calls GetPackageInfo.aspx on the Notification Server, which returns a list of download locations (codebases). Resolution logic differs slightly depending on whether the requester is a Software Delivery agent (a "codebases" request) or a Package Server (a "packageServers" request), but both follow the same general pattern:

  1. Manual assignment is checked first. If the requesting resource is manually assigned to a specific Package Server or a site, codebases from that assignment take priority over anything else.
  2. If sites are defined and the requester's IP address falls within one, Package Servers serving that site are checked first. If none are found there, the request falls back to the NS's own site, then to the NS itself.
  3. If no sites are defined, the fallback order is: Package Servers in the same subnet as the requester, then any available Package Server, then the NS.

Timeout handling: once the agent's cumulative download-attempt time — tracked and reported to the NS with each request — exceeds the configured maximum, the requester's IP address is replaced with the NS server's own IP for that lookup. This biases the result toward Package Servers near the NS, rather than jumping straight to NS codebases.

Revoked Package Servers are never returned, even if they are otherwise ready and would normally be a match.

Replicated packages: if no download locations are found at all and the requested package is eligible for item replication, the agent is redirected to the source NS instead of receiving an empty result. This redirect is honored only for requests from a Package Server in the same site as the NS.

Two core settings affect this behavior directly: PkgSvrDwonloadFromNSOnly (section 5.1) forces Package Servers to only ever receive the NS as a source when no sites are defined, and the per-package automatic-assignment setting determines whether GetPackageInfo fires off automatic site assignment on a background thread when a request comes back empty.

14.0 — Questions and answers

14.1 — How do I know which package relates to which virtual directory in IIS?

Double-click the package in the Package Server UI to see its details. The PackageID field contains the package's unique GUID, which matches the virtual directory name, for example:

Default Web Site\Altiris\PS{GUID.EN_US}

14.2 — How do I check the package codebases that Package Server sends to the NS?

  1. Add a path value to the following registry key: Capture Events Folder, under HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Transport. Any path works — for example, C:\CopyEvents. The folder is created if it does not exist. Any events sent by the agent or Package Server are copied to this folder in addition to being sent to the NS, so the contents can be reviewed directly.
  2. Restart the Altiris Agent service, then go to the Package Server UI and click Resend Package Status.
  3. Open the new event in the CopyEvents folder.
  4. Check the codebase links for both package and snapshot. Each hosted package has a UNC codebase link and an HTTP(S) codebase link.

The codebase types configured on the Package Service Settings page on the NS control whether UNC, HTTP, and HTTPS codebases are published. By default, UNC and HTTP publishing are enabled.

Example HTTP codebase (non-default port):

<Codebase href="http://PSName:8080/Altiris/PS/{GUID.EN_US}"

  snapshot="http://PSName:8080/Altiris/PS/getpackagesnapshot.asp"/>

Example HTTPS codebase (SSL defined):

<Codebase href="https://PSName/Altiris/PS/{GUID.EN_US}"

  snapshot="https://PSName/Altiris/PS/getpackagesnapshot.asp"/>

Example UNC codebase:

<Codebase href="file://PSName/PkgSvrHostC$/{GUID.EN_US}/cache"

  snapshot="file://PSName/PkgSvrHostC$/{GUID.EN_US}/snapshot.xml"/>

14.3 — How do I check the security type (anonymous or Windows-authenticated) on package virtual directories?

IIS 6: 

  1. Select the GUID virtual directory representing the package.
  2. Right-click Properties, then select the Directory Security tab.
  3. Click Edit under Authentication and Access Control.
  4. If Allow anonymous access to package codebases is enabled on the NS, Enable Anonymous access and Windows authenticated should both be selected. If it is disabled, Enable Anonymous access should be cleared and Integrated Windows Authentication should be selected.

IIS 7: 

  1. Select the GUID virtual directory representing the package.
  2. In the right pane, select Authentication.
  3. The same logic applies as IIS 6 above. The IIS 7 UI shows each type — Anonymous Authentication and Windows Authentication — as enabled or disabled.

14.4 — What are the package source types?

Package location uniquely identifies where package contents reside. Package files can be in the following location types:

Type

Description

Local

Located in a directory on the fixed disk drive at the NS host — not on a network-mapped drive.

UNC

Any valid UNC location, either on the NS or another machine.

URL

The Package.Location property holds a valid IIS URL. In the 7.0 SMP release this type is largely redundant, because the virtual directory path points either to the local path at the NS or to a UNC path. The virtual directory's physical location is stored in PackageItem.PackageDirectory for URL-type packages. A URL package type can typically be replaced by either Local or UNC.

Empty

A package with no files. PackageItem.Location can be empty.

External

All other package types are managed and maintained at the NS — created there, with contents monitored by the NS. An External package is created and managed at the Package Server instead.

14.5 — What is the NS package refresh schedule?

The process of revising (snapshotting) package contents is called Package Refresh, or Distribution Points Update. This process: updates package assignment to Package Servers (in the Automatic Assignment case), creates UNC and IIS shares at the NS as access points to the package folder for agents, and creates the package snapshot manifest.

Package Distribution Points Update is required after the package owner (a solution or customer) changes the package folder contents. Otherwise, the package generally stops being distributable to agents.

14.6 — Is a UNC location supported for a Package Server repository? Can a NAS device be used as the destination?

A UNC location is not currently supported for the Package Server repository, because Package Server uses the System account to create folders and other items it needs. The System account does not have privileges to use UNC network locations, so UNC locations cannot currently be used for file repositories.

14.7 — Where can I confirm the client policy value for package cleanup?

The Client Config policy shows a line similar to the following:

<PackageServer pkgSvrDwonloadFromNSOnly="0" pkgSvrCleanup="10080" publishUNC="true"

  publishHTTP="true" publishHTTPS="false" allowAnonAccess="true" createACC="false"

  reenableACC="false" createACCOnDC="false" accExpiryWarning="30"

  allowAllFixedDrives="true" excludeSystemDrive="true"/>

14.8 — Does Package Server run a CRC check before pushing files to clients?

Package Delivery uses file and block hashes rather than a CRC. Hashes cover the same integrity need a CRC addresses, including detecting corruption during transfer, and provide better protection than CRC — SHA256 hashes are used.

Package Server does not check hashes before pushing files, since IIS performs the push. Package Server does perform periodic hash checks when it validates packages.

14.9 — Does Package Server create UNC shares for packages with a custom location?

Package Server does not create UNC shares for packages with a custom location, or for locally managed (External) packages. This is intentional: creating or sharing a location just because it was specified in the SMP risks affecting a system folder or user-specific folder, which could break the system or introduce a security exposure.

To work around this restriction, the whole working folder for Package Server can be changed so all packages are stored separately from the core agent, and Package Server treats this location as the default — removing the need to change every package individually. See "Configuring Primary File Storage Location for Package Servers Post-ITMS 8.x"

If a custom-location package already has a UNC path, that path is provided as a codebase:

  • A custom location such as F:\CUSTOM_PATH does not generate a codebase; nothing is published as a UNC codebase.
  • A custom location such as \\%COMPUTERNAME%\CUSTOM_PATH is published as a UNC codebase without any path generation, but is still not shared — only published.

15.0 — General troubleshooting

15.1 — Agent cannot download package snapshot by HTTP on a Package Server running IIS 7

Symptom: The Altiris Agent cannot download package snapshots by HTTP from a Package Server running IIS 7.

Signal: The agent log shows:

AeXPackageDelivery.dll Download Snapshot failed: Invalid XML returned by the server (-2147467259)

AeXNSAgent.exe

Root cause: ASP (Active Server Pages) is not enabled in the IIS 7 Web Server role on the Package Server.

Resolution: Edit the Web Server role on the Package Server and install the ASP feature.

Note: The source content does not include a verification step for this scenario. Recommended addition: confirm the package snapshot downloads successfully after installing ASP, and confirm the -2147467259 error no longer appears in the agent log.

Additional Information

Package Server creating shares on every disk (except system)

Package Servers Attempting to Download to a Drive that does not exist

Retiring package server that was originally hosting image captured packages

Powered by Wolken Software