The Symantec Management Agent (aka Altiris Agent) is unable to download a package because it is failing to receive the package snapshot file. The logs show:
PackageDownload Download Snapshot failed: Failed to create NS Client component. Error number: 46. Error description: Permission denied (70)
PackageDelivery Error while downloading package: Failed to create NS Client component. Error number: 46. Error description: Permission denied (70)
Error 1:
Download Snapshot failed: Failed to create NS Client component. Error
number: 46. Error description: Permission denied (70)
----------------------------------------------------------------------------
Date: 12/11/2019 2:40:41 PM, Tick Count: 1966091312 (22.18:08:11.3120000), Size: 371 B
Process: AeXNSAgent.exe (9408), Thread ID: 8444, Module:
AeXPackageDelivery.dll
Priority: 1, Source: PackageDownload
Error 2:
Error while downloading package: Failed to create NS Client component. Error number: 46.
Error description: Permission denied
----------------------------------------------------------------------------
Date: 12/11/2019 2:40:41 PM, Tick Count: 1966091312 (22.18:08:11.3120000), Size: 373 B
Process: AeXNSAgent.exe (9408), Thread ID: 8444, Module:
AeXPackageDelivery.dll
Priority: 1, Source: PackageDelivery
Error 3:
Error while downloading package: No server found
----------------------------------------------------------------------------
Date: 12/11/2019 2:40:41 PM, Tick Count: 1966091312 (22.18:08:11.3120000), Size: 296 B
Process: AeXNSAgent.exe (9408), Thread ID: 8444, Module:
AeXPackageDelivery.dll
Priority: 1, Source: PackageDelivery
ITMS 8.x
In many cases the Altiris Agent is attempting to download the package from a package server.
We have seen issues when a package server agent is running on Windows XP SP2 or even Windows 2003 Server SP1. The COM permissions for the anonymous user account have been reduced causing the agent to fail because it cannot activate the Altiris.AeXNSClient object.
Individual Package Servers are affected, not the whole network. With EnableDACLManagement Disabled ( set to "0" - see 157828 "Package Refresh Resetting Security Credentials on Package Destination Folders") the Settings on the Altiris Agent folder are still being modified to have needed permissions removed. For Computer\Users the Read & Execute permissions are being set to "This Folder only".
The problem arises when someone removes the Read & Execute permissions to the "Altiris Agent" folder on the Package Server. Then IIS just can't access the Agent COM object in order to provide the snapshot.xml to the caller.
In this particular situation, a new package server was been setup. The client machine on that package server was trying to download the package from the NS itself. The NS had the Package Service installed.
The call to GetPackageInfo.aspx is always done to the NS:
https://NSserver.domain.com:443/altiris/NS/Agent/GetPackageInfo.aspx?...
Right after that, the call to the snapshot is done:
https://NSserver.domain.com/Altiris/PS/getpackagesnapshot.asp?...
This call to the snapshot is a pure package server call (asp page and PS share path are in use) it is done also to the NS machine, so the Notification Server has a separate Package Server installed on the same machine.
This is not a quite supported scenario (package server on an NS), and even a performance degrading approach since the package server on NS will duplicate all packages, consuming double disk space, it will also consume processing resources, decreasing the NS speed.
As for the described problem: The attempt to receive the snapshot is done to the package server-owned ASP page which tries to create a COM object of SMA, in order to get the package details and return the snapshot. This is done through VBScript in "GetPackageSnapshot.asp" script and this attempt failed.
the actual fail is on the "NS" side and the new package server is playing as a "client" in this game. The error is actually on the NS from its package server portion since the package service was installed.
You can reproduce this issue easily by removing IUSR from DCOM, but since DCOM is set by PS automatically, we suspect there could be something else in play, like global policies or some other security tools. Better to compare & check all permissions in DCOM for the "Altiris Agent" record.
Verify where the Altiris Agent is attempting to download the package from. In most cases, the Altiris Agent is attempting to download from a package server. On the source location (i.e. Package Server), verify that the Internet Guest Account (IUSR _<server name>) has the proper COM permissions. This account must have Launch and Activate permissions.
In some instances, you will also need to modify the security permission on the following folder: Program Files\Altiris\Altiris Agent\Package Server Agent. To give the Network Service user modify rights.
Check the Advanced Security permissions on the ..\Program Files\Altiris\Altiris Agent Folder. Computer\Users should be Read and Execute and apply to "This folder, subfolders, and files." If it is only "This folder only" change to included subfolders and files, and then repermission all subfolders by checking "Replace all child object permission entries .... " and then select OK.
NOTE: To fix the current problem on multiple package servers,
Script task contains this cmd line:
for /f "tokens=2,*" %%a in ('reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\Altiris Agent" /V InstallDir ^|findstr /ri "REG_SZ"') do icacls "%%b" /grant *S-1-5-32-545:(RX)
The safest way to fix this issue if the NS has the package service installed is to remove the Package service from the Notification Server machine, in that case, stand-alone PS-es will receive the NS codebase and download directly from Notification Server.
If for some reason you can't remove the package service on the NS, consider the following: