Configuring Primary File Storage Location for Package Servers Post-ITMS 8.0


Article ID: 150359


Updated On:


Management Platform (Formerly known as Notification Server)



On the Notification Server Package Service Settings page it is possible (starting ITMS 8.0) to change the primary file storage location for Package Server. Since this settings policy can be specified for single Package Server, this feature gives a flexibility to manage different file storages on different Package Servers. Just keep in mind that this is an expensive operation and is not intended to be used on daily basis. It is rather for initial infrastructure setup.


ITMS 8.x


How it works?

By default the File storage location is "<SMA install folder>\Package Delivery". This could bring some difficulties on some large environments, where system drive is used to be much smaller than drives dedicated to storage purposes. Moving the whole SMA (Symantec Management Agent) installation to the storage drives is also not usable in some cases. For that purposes it is now possible to have SMA installation and Package Server packages storage on different drives.

When the custom location is specified on NS side, the PS receives the policy with the new custom path ("windowsLocation" element. By default it contain the "hint": "_default_"). This triggers the "relocation" of currently downloaded packages by Package Server. While the relocation process also happen the "consolidation" of packages spread to the "rotated" drives. This means all packages which were stored to the different drives (because of "Allow usage of all fixed drives..." was turned on) will be moved to the newly specified location as well to the single new drive.

The relocation itself is performed in a safe mode: the Junction Point links (soft-link) will be created pointing from new location to the old one, then files will be copied\moved to the new location, replacing the Junction Points. If by some reason the package can't be copied (shared, locked, disk out of space etc.), this package will be skipped leaving Junction Point link to the legacy location. After relocation attempt is finished, all the packages will be available from the new location. The packages failed to relocate will remain in legacy location, but for 3rd parties they will be as they are in new location already. Package Server will be then attempting to copy/move such packages on next relocation retry. By default there are three retries with 15 minutes interval. This could be configured by registry entries:

HKLM\SOFTWARE\Altiris\Altiris Agent\Package Server\Package Storage Relocation Maximum Attempts  - (REG_DWORD) The maximum retries number allowed to perform.
HKLM\SOFTWARE\Altiris\Altiris Agent\Package Server\Package Storage Relocation Interval (min)   - (REG_DWORD) The interval between relocation retries.



In case of errors while relocation, there should be next entries:

HKLM\SOFTWARE\Altiris\Altiris Agent\Package Server\Package Storage Last Relocation  - (REG_SZ) When last relocation attempt happened.
HKLM\SOFTWARE\Altiris\Altiris Agent\Package Server\Package Storage Relocation Attempts Done  - (REG_DWORD) How many attempts was already performed.

Overall state of relocation is stored in:

HKLM\SOFTWARE\Altiris\Altiris Agent\Package Server\Package Storage Relocation State  - (REG_DWORD) State flags according to the last attempt.


State values are:

Not applicable




Need retry


Maximum Retry attempts is reached




Aborted due to no free space on disk


Aborted due to drive not having a fixed media


Aborted due to path being under known system folder


Aborted due to file system not NTFS or ReFS


New path arrived


The "New path arrived" value can be set along with other state values (e.g. 0x00000012 means new path is arrived and relocation need retry).

Thanks for the Junction Points the functionality of Package Server is not affected by relocation failures and clients can safely download the package files of any package.


Things to check before applying new location for packages:

  1. The new drive has fixed media; for example, a hard disk drive or flash drive.

  2. The new drive has enough space for all packages from current location + packages stored on different drives due to "Allow usage of all fixed drives..." feature.

  3. The new location is not a "Windows Known" folder or sub-path of a "Known" folder. Package Server will not relocate files to Windows Known Folders like: FOLDERID_Windows, FOLDERID_ProgramFiles (x86 including), FOLDERID_ProgramData, FOLDERID_UserProfiles.

  4. Windows has own limitations for path length which could be contained inside the Junction Point structure. The overall Unicode path to final files with filenames should not be longer than 8184 characters (Max Reparse Data Buffer size minus service information will be 16368 bytes).

If any of the conditions above is not fulfilled, the Package Server will not start the packages relocation process.

The relocation process actions sequence:

  1. Package Server stop all current downloads, and delete shares and virtual directories in order to avoid files to be locked by new download processes by clients.

  2. Perform checks listed above.

  3. Create target path and create the Junction Point links to the current package storage location.

  4. Copy the package to the new location with a temporary name like: "{PACKAGEGUID.EN_US}-tmp".

  5. Update the "snapdata.xml" file with new "path".

  6. If copy was successful, then:

    1. If package files are on the "rotated drive", then copy them to new location as well.

    2. Remove the Junction Point.

    3. Rename the package folder to the original name.

  7. Repeat steps 3 - 6 for all packages.

  8. If the relocation has some failures - schedule the retry for those packages.

  9. Create the new shares and virtual directories for new location.

  10. Resume package download if any.

Currently applied path where Package Server is working at the moment is displayed at the bottom of PS UI:

In case the relocation is failed to move all the files and need a retry, it is possible to trigger the relocation attempt by hand. The link "Retry Package Relocation" will appear in the Package Server tasks list:

Manually triggered relocations do not affect the maximum relocation number. The "maximum number" and "attempts done" are affected only by automatic retries.


Status of the relocation is also visible from SMA alerts.


On each relocation attempt (automatic and manual) the "AeX AC Package Location Status" inventory event is sent.

This event contain next fields:


Field index


Storage path


String path where relocation attempt was targeted to.

Total size of the volume


Integer (size in Mbytes)

Free size of the volume


Integer (size in Mbytes)

Size used by PS on this volume


Integer (size in Mbytes)

Last relocation attempt datetime



Last relocation status


Same values as described for "Package Storage Relocation State" in the table above.

Those values should be stored into a new dataclass on server side, participate in the reporting and be visible under inventory fields in Resource Manager. For now this is under development by Server side and not accessible yet.



Other references can be found here:
How to store Package Server repository aside from SMA in SMP 8.0

or in the attached document "PS Relocation.pdf"



1593443884282__PS Relocation.pdf get_app