Configuring Primary File Storage Location for Package Servers Post-ITMS 8.x
search cancel

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

book

Article ID: 150359

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

Overview

On the Notification Server Package Service Settings page it is possible (starting ITMS 8.0) to change the primary file storage location for the Package Server. Since this settings policy can be specified for a single Package Server, this feature gives 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.

Environment

ITMS 8.x

Resolution

How it works

By default, the File storage location is "<SMA install folder>\Package Delivery". This could bring some difficulties to 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 purpose, it is now possible to have SMA installation and Package Server packages storage on different drives.

When the custom location is specified on the NS side, the PS receives the policy with the new custom path ("windowsLocation" element. By default it contains the "hint": "_default_"). This triggers the "relocation" of currently downloaded packages by the Package Server. While the relocation process also happens the "consolidation" of packages spreads to the "rotated" drives. This means all packages which were stored on the different drives (because "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 the new location to the old one, then files will be copied\moved to the new location, replacing the Junction Points. If for some reason the package can't be copied (shared, locked, disk out of space, etc.), this package will be skipped leaving the Junction Point link to the legacy location. After the relocation attempt is finished, all the packages will be available from the new location. The packages that failed to relocate will remain in the legacy location, but for 3rd parties, they will be as they are in the new location already. The Package Server will then attempt to copy/move such packages on the next relocation retry. By default, there are three retries with 15 minutes intervals. 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 were already performed.

                         
The 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

0x00000000

Success

0x00000001

Need retry

0x00000002

Maximum Retry attempts are reached

0x00000004

Aborted

0x00000008

Aborted due to no free space on disk

0x00000020

Aborted due to drive not having a fixed media

0x00000030

Aborted due to path being under known system folder

0x00000040

Aborted due to file system not NTFS or ReFS

0x00000050

New path arrived

0x00000100

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

Thanks to the Junction Points the functionality of the 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 the current location + packages stored on different drives due to the "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 its 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 package's relocation process.

The relocation process actions sequence:

  1. Package Server stops all current downloads and deletes shares and virtual directories in order to avoid files being locked by new download processes by clients.

  2. Perform checks listed above.

  3. Create a 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 a new "path".

  6. If the copy was successful, then:

    1. If package files are on the "rotated drive", then copy them to the 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 the new location.

  10. Resume package download if any.

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

In case the relocation has failed to move all the files and needs 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.

 

The 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 contains the following fields:

Description

Field index

Value

Storage path

c0

String path where relocation attempt was targeted to.

Total size of the volume

c1

Integer (size in Mbytes)

Free size of the volume

c2

Integer (size in Mbytes)

Size used by PS on this volume

c3

Integer (size in Mbytes)

Last relocation attempt datetime

c4

Datetime

Last relocation status

c5

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.

 

Note:

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"

 

Attachments

1593443884282__PS Relocation.pdf get_app
Powered by Wolken Software