FAQ on Package Servers
search cancel

FAQ on Package Servers

book

Article ID: 150861

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

Note: The following information is provided as a reference. Due to the constant improvements in our products, some of the details shown below may change without notice.
The following article is divided into different topics. Some will describe behavior and some will provide Q&A regarding the process used.

Table of Content:
1.0 - Package Server and IIS
2.0 - Package Delivery
         2.1 - Updated Packages
         2.2 - Invalid Packages
         2.3 - Deletion of Unused Packages
         2.4 - Disk Space Check
         2.5 - Drive Overflow
         2.6 - Packages stored in non-default locations
         2.7 - Package Access
3.0 - Package Server related SQL database tables
4.0 - Events sent by Package Server
5.0 - Package Server Registry Keys
         5.1 - Package Servers download only from NS only
         5.2 - NoPACLockdown
         5.3 - EnableDACLManagement
6.0 - Package Server and IIS 7
7.0 - Package Server Settings
8.0 - Package Snapshot Generation
9.0 - Package Share Creation
10.0 - Primary File Storage Location
11.0 - Automatic Package Server Assignment
12.0 - Questions and Answers
13.0 - Useful References

Environment

ITMS 8.x

Resolution

1.0 - Package Server and IIS

If installing IIS after installing PS, the user must restart the Altiris Agent service before Virtual Directories for downloaded package server packages will be created. Clicking on the refresh packages button inside the Package Server UI will not create them in this situation.
If IIS is not installed on the Package Server and you specify to download to a non-default location which is a local path on the package server, then no codebases will be sent to the NS for this package at all. This is because the package server does not create shares other than the default share PkgSvrHost, and cannot assume that one has been created for this custom location.
The Package Server sends an IIS log Summary Event to the server every 24 hours, you can find this information inside the Events tab of Resource Manager. The connection Count field shows the number of client connections to a PS Virtual Directory, however, if the same client connects more than once for the same package it will not re-count this.
2.0 - Package Delivery

2.1 - Updated Packages
Below is an example of where a particular package is stored. Each package is stored underneath its own GUID folder.  The actual package files reside inside the cache folder.
C:\Program Files\Altiris\Altiris Agent\Package Delivery{6C821F5E-5BF4-407F-A6FF-ABB85EEE0418}\cache

Below is what occurs when Package Server receives configuration about an updated/changed package.
1. The Agent Access Credentials (ACC) on the package root folder under 'cache' will be temporarily removed so only System and Local Administrator rights remain.
(Agents using the ACC will be unable to reconnect).
2. The files in the package are scanned and all open files are closed.
3. Any Agents that are currently downloading the package will be disconnected from the download and will retry at the usual interval.
4. The updated Package is downloaded to the Package Server.
5. The ACC is restored to the 'cache' folder
 
2.2 - Invalid Packages
What causes a package to show as invalid inside the Package Server UI?
- Creating an SWD Package and specifying a non-default download location that does not exist on the PS (i.e. X:\folder1)
- Creating an SWD Package and Specifying a non-default download location that exists but is not shared.
- If there is not enough disk space to download packages to the Package Server
- Anonymous access to package codebases setting has been disabled and the specified ACC cannot be applied to the downloaded files i.e. ACC is an untrusted account.

2.3 - Deletion of Unused Packages
The setting for when Package Servers should delete unused packages exists on the Settings tab of the Package Server page.
The count down to remove package files on a Package Server will only begin when either; the package is unassigned from the Package Server, or the package is deleted from the NS database. Both of these situations result in the package no longer being sent down to the Altiris Agent in the Package Server node of the configuration XML file.
Once this occurs the Package Server updates the PackageStatus.xml file that it stores for each package and sets the ‘Status’ flag to ‘Deleted’ and the ‘Time’ flag to that of when it was removed from the configuration file.
The package status files are located (on a default install) at the following location on the Package Server machine -
C:\Program Files\Altiris\Altiris Agent\Package Server Agent\Package Status
At each Package Server refresh, the Package Server will check for a Deleted flag inside all the Package Status files and if the corresponding Time flag has passed the duration configured for deletion of unused packages, then the package files will be removed.

2.4 - 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.

2.5 - 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.
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.

2.6 - Packages stored in non-default locations
When specifying a non-default location for the package server to download to, if a local path is specified i.e. C:\folder and the folder does not exist then the package server will create it when downloading the package.
A share for this package will not be created, so, therefore, a UNC codebase for this type of package will not be sent to the server, only HTTP will be sent.
Specifying a non-default location on the Advanced tab when creating an SWD Package The location can be \\%computername%\share
%compuername% is substituted for the name of the localhost computer name.  ‘Share’ is a shared folder that already exists on the hard drive of each Package Server receiving the package.
Package Server does not create shares, (except the primary share PkgSvrHostC$) so if the folder specified does not exist or is not shared, the PS will not download the package and will set the status to invalid. If the shared folder does exist then the Package Server will send UNC codebases to the NS for this UNC alternate download location.

2.7 - Package Access
The Altiris Agent cannot download a package via UNC from a Package Server on a non-trusted domain. An ‘Access Denied’ error occurs.
Package Service Setting - 'Allow anonymous access to package codebases'
Anonymous access effectively means all authenticated users are allowed when downloading via UNC.  Even if a Package Server in a non-trusted domain has anonymous access enabled on its files, if the ACC account that the Altiris Agent uses to connect anonymously to the UNC source cannot be authenticated, then access with be denied and no download will occur.
When attempting to download via HTTP from a Package Server in a non-trusted domain using anonymous access, the download should occur with no access issues.

3.0 - Package Server related SQL database tables

SWDPackageCodebase - This table lists all NS and Package Server codebases for hosted packages. If the Source Column is ‘NULL’ this is an NS codebase, otherwise, it will be the GUID of a Package Server.
SWDPackage -  Shows details of an SWD Package, versions, etc. When the package changes it adds a new column to this table for the same PackageId (GUID). The one with the _Latest =1 value is the most current.
SWDPackageServer - Show details of what packages are assigned to which package server, and the status of these packages
Evt_AeX_Package_Server_Package_Event - Download status events posted by Package Server (more details on events below)
RM_ResourcePackageService - the guid column is the parent resource guid inside the resource association table. The child guid is that of the package server resource. If the ‘Deleted’ column is set to ‘1’ this means the package service has been selected for uninstall.

4.0 - Events sent by Package Server

Below is a list of Package server events that will be generated under certain conditions.
 A new package is downloaded
  • Start - Initial
  • New Package
  • Codebase enabled
  • End - Complete
The existing package that gets updated
  • Start - Refresh
  • Updated Package
  • Codebase enabled
  • End - Complete
A valid package that becomes invalid
  • Start - refresh
  • Updated package
  • Invalid Package
  • End - Invalid
An invalid package that recovers and turns to valid
  • Codebase enabled
  • End - Recover
  • End - Complete
A new package that becomes invalid
  • Start - Initial
  • New Package
  • Invalid Package
  • End - Invalid.
Agent Access Credentials (ACC) cannot be authenticated on the Package Server
  • Codebase Disabled summary event sent for each package hosted on the PS (with an error message)
Recovered credentials
Where the state goes from an ACC that cannot be authenticated to one that can
  • Codebase enabled summary event sent for each package hosted on the PS
  • If the Package Server sends a summary event, which contains the package version that is older than what the NS has recorded for the package, then the NS should disable the codebase for the package. Codebase "Status" should be 'Stale codebase" in the database
Summary Events
  • The summary event type has been changed from ‘CompleteSummary’ in 6.0 Sp3 to ‘Summary’ in NS 7.0. The logic for sending summary events has not changed between releases, only the event type.
  • Package Status and Summary events report the size of each package as well as whether the package is managed locally (externally for NS). This is communicated using an ‘IsManaged’ flag reported to NS inside the summary event that indicates whether a specific package is owned by the package server. This is a new feature introduced in 7.0 which allows packages to be defined on package servers and not on the NS box.
5.0 - Package Server Registry Keys

5.1 - Package Servers download only from NS only
The NS Core Setting option ‘Package Servers download only from NS only’ is enabled inside the core settings of the NS. The following behavior applies:
When there are no sites defined:
- If the setting is enabled, the functionality is activated and package servers should only receive the NS as a download source.
When sites have been defined:
- If the setting is enabled, the functionality will not be activated, treat as disabled.

5.2 - NoPACLockdown
Registry Key ‘NoPACLockdown’ determines whether PS will secure packages using the Package Access Credentials given, or apply for anonymous access
Reg key under - HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Package Server\NoPACLockdown
This value has the following meaning:
- 1 The package server will not lock down packages using the Package Access Credentials (PAC) now called (ACC in NS SP3). Instead, it will give everyone access
- 0 The package server will lock down packages using the ACC.
 
5.3 - EnableDACLManagement
A Package Server registry key, ‘EnableDACLManagement’, has been created to allow the user to change how a Package Server manages the security of 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.
Care should be taken 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 the Local Administrator and System needs 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.
As the registry key does not exist on a default install of the updated Package Server, a DWORD key must be created 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.

6.0 - Package Server and IIS 7

Package Server is unable to host its packages within IIS 7 unless the IIS 6.0 Compatibility Tools are installed as part of the Web Service role configuration.
There are a few other services that need to be enabled for the Package server to fully function, they are outlined below.
1. Go to Start > Administrative Tools > Server Manager
2. Select ‘Web Server (IIS)’ in the left-hand tree
3. Inside the right-hand pane click the link ‘Add Role Services’
4. Select Application Development > ASP (ticked)
5. Select Security > Windows Authentication (ticked)
6. Select Management Tools > IIS 6 Management Compatibility (all subfolders ticked)
7. Click the ‘Install’ button inside the popup dialog

7.0 - Package Server Settings

Site Server Settings page > Package Service Settings page > Setting ‘Allow anonymous access to package codebases’
Select this option and all packages downloaded to Package Servers will have anonymous ‘everyone’ access added to the windows 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 option is disabled then the Agent Connectivity Credentials (ACC) specified inside the Global Altiris Agent Settings page on the NS will be used to secure the package server package files. Likewise, any HTTP virtual directories that are mapped to packages on the Package Server will have anonymous access disabled and will have Integrated Windows Authentication enabled, such that agents connecting for HTTP downloads will be challenged to supply their ACC credentials.
The ACC used must be a known account on the Notification Server and every Package Server.  If the user account can’t be validated on a Package Server (such as a non-trusting domain or a computer account from another computer) then no Altiris agents will be able to download files from this Package Server.  You can only secure the files on the Package Servers to use the Agent Connectivity Credential if ALL the Package Servers are going to recognize the account that you specify.
Setting -  ‘Create the Agent Connectivity Credential on Package Servers (provided the ACC is not a Domain Controller)’
When a customer environment contains Package Servers in different domains, and a trust does not exist between these domains, a local computer account can be set as the ACC, rather than a domain account. The local computer account must be a local administrator on the Notification Server machine as this account will be used for updating distribution points on packages. It is not required to be an admin account on the Package Servers.
 The format for entering the local user account name as the ACC within the Global Agent Settings page can be either .\localuser or local user  (where the local user is the name of the local computer account ( Ensure you DO NOT enter the NS machine name as a prefix)
When specifying a local account as the Agent Connectivity Credential is it best used in conjunction when the option “Create the Agent Connectivity Credential on Package Servers. (provided the ACC is not a Domain Controller)”.   Enabling this option ensures that if this account does not exist on all Package Server computers across all trusted and untrusted domains, it will be created locally and applied to the downloaded package files on each of the Package Servers.
If a local account is specified as the ACC and the following the above-highlighted option is disabled, then the local account set as the ACC will already need to exist on every Package Server.  If the account does not already exist then the Package Server will not be able to apply security to downloaded packages and will not publish codebases as ready to the Notification Server.
 
Note: There are dependent configurations from the Operating System that the ACC requires to fully function.  The out-of-box configurations from OS install are highly recommended as it is how the product was tested against.  Any deviations outside of that will require extensive testing and verification.  Some known dependent configurations are listed below.
 
1. Security Policy > Local Policies > User Rights Assignment > Access this computer from the network. - Must be ENABLED and includes the ACC Account
2. NetLogon Service - Must be ENABLED and set to automatic startup
 
8.0 - Package Snapshot Generation
  • The package snapshot is an XML Manifest listing the files located in the package location along with their properties

    • Size
    • Modified Date
    • SHA256 file Hash
  • per each package 1 snapshot XML is generated with the name <package_guid>.xml

  • Snapshot XMLs are stored in the C:\ProgramData\Symantec\SMP\Snapshots

  • Each snapshot XML change results in updating of package version which is stored in the SWDPackage.[Package Version] column

  • Each snapshot XML change leads to regeneration of the snapshot XML SIGNATURE. NS signs snapshot, but the signature itself is stored in a separate file <package_guid>.sig under C:\ProgramData\Symantec\SMP\Snapshots.
    The signature file is returned as a string by the GetPackageSnapshot.aspx response for Package integrity check purposes on the agent side.

9.0 - Package Shares Creation

Package shares need to be created at NS for

  • Package servers to download package contents
  • Software Delivery piece of the NS Agents to download package contents - in the environments without PS agents are allowed to download packages directly from NS

NS wants to keep as many shares as possible, that's why it creates both IIS and UNC shares. The shares are only created for the following package types: local, UNC and URL. The shares are then transformed to codebases. "Codebase" is the URI that is the de-facto access point being used for downloading the package contents.  The difference between "share" and "codebase" will become obvious below. The codebases are persisted to the SWDPackageCodebase table.

Shares of Local Packages

  • For each local package, a UNC share called NSSWD_<packageGuid> is created. Thus the full UNC codebase will be \\NS_HOST\NSSWD_<packageGuid>
  • For each local package an IIS Virtual Directory is created OR (99% of cases) the existing pkggroup (read below) virtual directory is reused. The virtual directories are created under the/Altiris/PackageShare application.

IIS Legacy package shares

In the releases, before 7,1 SP2 each package had a separate virtual directory located under /Altiris.PackageShare and name equal to the package guid and pointing to the package location.

IIS Package Group shares (pkggroup)

To minimize the number of virtual directories created at IIS it was decided to create virtual directories pointing to the PARENT directory of the package location, ie If the package location of a package is

C:\xxx\parent\A

then Virtual Directory (VD) is created pointing at C:\xxx\parent. When the 2nd package is created with a location at

C:\xxx\parent\B

a separate VD is NOT created, because another one pointing to C:\xxx\parent already exists. The common virtual directory name is constructed as pkggroup_<md5> where <md5> is the md5 hash of the PARENT FOLDER of the package location. The generated codebases though have the correct paths like http://NS/Altiris/PackageShare/pkggroup_<md5>/A orhttp://NS/Altiris/PackageShare/pkggroup_<md5>/B  leading to C:\xxx\parent\A and C:\xxx\parent\B correspondingly.

Restrictions: the group shares cannot be created if the package location resides in ANY of the "special OS folder". The list of the restricted  folders are the following:

        /// Desktop
        /// Internet Explorer (icon on desktop)
        /// 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       
        /// MYDOCUMENTS 
        /// "My Music" folder
        /// "My Videos" folder        
        /// %user name%\Desktop        
        /// 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\Applicaiton Data (non roaming)        
        /// non localized startup        
        /// non localized common startup 
        /// All Users\Application Data 
        ///  C:\Program Files        
        /// C:\Program Files\My Pictures  
        /// USERPROFILE        
        ///  x86 system directory on RISC        
        /// x86 C:\Program Files on RISC        
        /// C:\Program Files\Common        
        /// x86 Program Files\Common on RISC       
        /// All Users\Templates
        /// All Users\Documents        
        /// All Users\Start Menu\Programs\Administrative Tools  
        /// %user name%\Start Menu\Programs\Administrative Tools
        /// Network and Dial-up Connections        
        /// All Users\My Music             
        /// All Users\My Pictures        
        /// All Users\My Video 
        /// Localized Resource Direcotry        
        /// Links to All Users OEM specific apps        
        /// USERPROFILE\Local Settings\Application Data\Microsoft\CD Burning
        /// Computers Near Me (computered from Workgroup membership)

Shares of UNC Packages

  • For the UNC package, the UNC share is NOT created at the NS host, because it either exists a priori  (unc pointing to local physical drive at NS) or it is a location at a remote machine.
  • The IIS virtual directory /Altiris/PackageShare/<packageGuid> is created pointing to the package unc location. Either the ACC or  Distribution Point Credentials   (NS Console-> Settings->All Settings-> Notification Server Settings -> Distribution Point Credential tab -> "use these credentials" radio button) are set for the VD to access the UNC location. The IIS codebase(s) then look like http://ns/Altiris/PackageShare/<packageGuid>

Shares of URL Packages

  • The share at IIS exists a priori - it is NOT created. The codebase looks exactly as the IIS share.
  •  If the Virtual Directory points to the UNC location  (PackageItem.Directory is a UNC ) then  the UNC codebase is added as well

Shares Deletion

  • Each time it is detected that package has changed its location during package refresh the OLD  UNC share is deleted
  • The unused IIS shares are detected and deleted ONLY during the package refresh task.
    • Package Refresh Task- this is an SMP scheduled task running once a day by default and doing package refresh for EACH PACKAGE IN THE SYSTEM. The obvious drawbacks of such an approach are

      • To some extent, this is a major security breach, because NS "auto accepts" ANY package content to be alright. At the moment it is impossible to fix this conceptual problem without a breaking change, however, we highly encourage the solutions NOT TO RELY on the Package Refresh task and execute manual Distribution Points Update for packages that undergo conscious package folder contents change.
      • When having 100000 packages in the system it takes HOURS to perform this task. All this period HDD is actively consumed by the AexSvc process.
      • Two Package refresh task does not run in parallel

 10.0 - Primary File Storage Location

On the Notification Server Package Service Settings page it is possible (starting 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 the 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 daily. It is rather for the initial infrastructure setup.

Please refer to KB INFO3595 “Configuring Primary File Storage Location for Package Servers Post-ITMS 8.0"

11.0 - Automatic Package Server Assignment

Automatic package server assignment aims to assign packages to sites as required in order to distribute the package to all parties which are assigned the package to download. It also adds support to have these assignments removed automatically after they have not been used for a specified number of days.

Please refer to KB INFO3595 "Automatic Package Server Assignment"

12.0 - Questions and Answers

Question 1: How to know which package relates to which Virtual Directory inside IIS?

Answer: Once the package has been delivered to your Package Server, double-click on it within the Package Server UI to see more details.

The 'PackageID' field will contain the unique GUID for the Package.

This corresponds to the virtual directory which is named with the same GUID.

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

Question 2. How to check the Package codebases that the Package Server is sending up to the NS?

Answer:

1. Add a path value to the following registry key 'Capture Events Folder' - location HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent\Transport

Any path can be added i.e. C:\CopyEvents It will create the folder if it does not exist. The purpose being that any events sent by the Agent or PS will be copied to the specified folder as well as sent to the NS, such that the user can view the contents of the event.

2. Reset the Agent Service and then Go to the Package Server UI and click the 'Resend Package Status' button

3. Check the CopyEvents folder and open the new event within

4. Check the codebase links (both package and snapshot). There will be a UNC codebase link and an HTTP(S) codebase link for each package that the PS is hosting.

Note: Keep in mind that the codebase types specified within the Package Service Settings page on the NS will control whether UNC and HTTP, HTTPS codebases are published or not.

- By default publishing, UNC and HTTP are turned on.

Example HTTP Codebase (Non-default port) -

 

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

Example HTTPS Codebase SSL defined -

 

 Example UNC codebase -

 

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

Question 3. How to check the security type ( anonymous or windows authenticated) that is placed on package virtual directories?

Answer.

Within IIS 6 -

1. Select the GUID virtual directory representing the package

2. Right-click Properties > directory security tab

3. Click on the 'Edit' button for the 'Authentication and Access Control' option.

4. Depending on what has been set for the PS Security settings on the NS

- If 'Allow Anonymous access to package codebases' is enabled on the NS, the following should be tick selected - "Enable Anonymous access"  and 'Windows authenticated' should be ticked.

- If 'Allow Anonymous access to package codebases' is disabled - the 'Enable Anonymous access' tick box should be unticked and "Integrated Windows Authentication" should be ticked selected.


Within IIS 7-

1. Select the GUID virtual directory representing the package

2. On the right pane select 'Authentication'

- The same applies as per the above IIS 6 descriptions of the anonymous and window authentication settings.

- The UI in IIS 7 will either be state enabled or disabled for the below types.

* Anonymous Authentication

* Windows Authentication

 

Question 4. What are the Package Source Types?

Answer.

Package location uniquely identifies the package contents location. Package files can be located in several different location types:

LocalLocal (to the Notification Server). The package contents are located in a directory on the FIXED disk drive at the NS host, NOT on a network mapped drive.

UNC
UNC location. Any valid UNC location - either on NS or any other machine - is accepted.

URL
The Package.Location property of a package item will hold a valid IIS URL. In 7.0 SMP release, this type is rather useless because the virtual directory path anyway points either to

  • the Local path at NS

  • Some UNC path
    The virtual directory PHYSICAL location must be then stored in the PackageItem.PackageDirectory property for Url-type packages. As one can see the URL package type can easily be replaced by either Local or UNC package.

Empty
A package with no files. Not sure who this type may be important for. PackageItem.Location property can be empty

External
All the previously mentioned package types are "managed" and "maintained" at NS. Namely, they are created at NS and their contents are "monitored" by NS. The external package type is created and managed at the Package Server.

 

Question 5. What is the NS.Package Refresh schedule?

Answer.

The process of "revising" (snapshotting) the package contents is called "Package Refresh" or "Distribution Points Update". This process does the following basic things:
  • Updates Package assignment to Package servers (Automatic Assignment case)

  • Creates UNC and IIS shares at NS as access points to the package folder for the agents

  • Creates "Package Snapshot" - the manifest listing

Package Distribution Points Update (DPU) is a MUST HAVE process after the package "owner" party (solution, customer, etc) changes the package folder contents. Otherwise, the package most probably stops being distributable to the agents


Question 6. Do we support a UNC location for a Package Server repository?  Can a NAS device be used for the destination UNC location?

Answer.

We are currently unable to use the UNC location for the Package Server repository due to the Package Server using the System account for creating folders and the rest of the items needed on the Package Server. The system account does not have privileges to use UNC network locations, so currently, UNC locations cannot be used for file repositories.

Question 7. If I need to check that the client policy on my package server has the proper value for package clean up, wherein this policy I can find this reference?

Answer.

You should see something like the following in the Client Config policy:

<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"/>

 

Question 8. Is the package server running a CRC (Cyclic Redundancy Check) before pushing the files to the clients?

Answer.

Our Package Delivery uses hashes of files (and blocks now). The hashes cover more security needs for us, including detection of corruptions while the transfer, which is CRC checks usually used for.
In other words, we use better than the CRC method -  SHA256 hashes.

The package Server does not check hashes before pushing since that’s IIS who “pushes” the files. But the Package Server does periodic hash checks when it validates the packages.

 

Question 9. Does the package server create UNC shares for packages with a custom location?

Answer.

The PS does not create UNC shares for packages with the custom location specified or locally managed packages (external). The reason was not to change or share any location on the machine just because someone specified it on the SMP since it could have been some system folder or user-specific folder and sharing it or restricting access to it could break the system or lead to a security breach.

Nevertheless, to mitigate that restriction we have implemented the possibility to change the whole Working folder for Package Server so that all the packages could be stored separately from the Core agent and PS will treat this location as a default. In that case no need to change every package separately. Detailed instructions are here: 

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

http://www.symantec.com/connect/articles/how-store-package-server-repository-aside-sma-smp-80

One more thing to note, if such (custom location) packages have already a UNC path inside, then this path is provided as a codebase.

Means:

  • If the custom location is: like “F:\CUSTOM_PATH” then the codebase is not generated and nothing will be published as UNC codebase.
  • If the custom location is like \\%COMPUTERNAME%\CUSTOM_PATH then this location is published as UNC codebase without any path generation (but still no sharing is done, only publishing).

Our Package Delivery uses hashes of files (and blocks now). The hashes cover more security needs for us, including detection of corruptions while the transfer, which is CRC checks usually used for.

General Troubleshooting:

Problem 1: Altiris Agent is unable to download package snapshots from a Package Server via HTTP that has IIS 7.

Error in Agent log: AeXPackageDelivery.dll Download Snapshot failed: Invalid XML returned by the server (-2147467259) AeXNSAgent.exe

Cause: ASP (Active Server Pages) have not been enabled inside the IIS 7 web services role on the Package Server

Solution: Edit the web services role on the package server and install ASP