FAQ on Package Servers
Article ID: 150861
Updated On:
Products
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
2.1 - Updated Packages
Below is what occurs when Package Server receives configuration about an updated/changed package.
(Agents using the ACC will be unable to reconnect).
2. The files in the package are scanned and all open files are closed.
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
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.
4.0 - Events sent by Package Server
Below is a list of Package server events that will be generated under certain conditions.
- Start - Initial
- New Package
- Codebase enabled
- End - Complete
- Start - Refresh
- Updated Package
- Codebase enabled
- End - Complete
- Start - refresh
- Updated package
- Invalid Package
- End - Invalid
- Codebase enabled
- End - Recover
- End - Complete
- Start - Initial
- New Package
- Invalid Package
- End - Invalid.
- Codebase Disabled summary event sent for each package hosted on the PS (with an error message)
- 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
- 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.1 - Package Servers download only from NS only
5.2 - NoPACLockdown
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.
Site Server Settings page > Package Service Settings page > Setting ‘Allow anonymous access to package codebases’
-
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
or
http://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 150359 “Configuring Primary File Storage Location for Package Servers Post-ITMS 8.0"
11.0 - Automatic Package Server AssignmentAutomatic 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 150360 "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} |
|
"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"/> |
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
Answer.
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.
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"
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
Feedback
