Symantec Management Platform (Notification Server)

"Cannot write to directory: 0x80070005 [Access is denied] \\PackageServer\patch_managment$\9739d871-0255-6185-ec83-2b0bf837ec6a","CreateTargetDir","AeXNSAgent.exe","1568"

is just a warning (blue)

But followed with the collection of red:

"Operation 'Get File' failed. 
Protocol: http 
Port: 80 
Path: /Altiris/PackageShare/pkggroup_bn6hvett2iyfrrzszwmpztq4upzbb5iz/MSNS18-04-QP81-4093121/%7B2609043b-74de-44cb-adfd-1aee71af6a9e%7D/windows8.1-kb4093121-x64.msu 
Http status: 200 
Secure: No 
Error type: Local error 
Error result: 0x80070005 
Error code: 0 
Error note: HttpRequest::OpenReceiveFile create tagget dir error 
Error message: Access is denied","NetworkOperation","AeXNSAgent.exe","1568"

"08.06.2018 10:35:52","Download Package failed: Access is denied (-2147024891)","PackageDownload","AeXNSAgent.exe","1568"

"08.06.2018 10:35:52","Error while downloading package: Access is denied (0x80070005)","PackageDelivery","AeXNSAgent.exe","1568"

Don't loss your time with other following errors, the source, all the cause not identified, of this problem is the default security creation the created folder to receive the package

Il you try to open the folder the GUID of the package in the Packager server 'Patch managment' folder, all others are OK. But this one provide an error if try to open :

You don't currently have permission to access this folder.

Of course, you can "Continue", and get access, this empty folder... You can also after that try to delete it, same result...

If you see this type of error on other version Altiris platform thanks to share in there. We don't understand "Why" !

Try 

http://www.symantec.com/docs/TECH228994

no more better result

We plan to try this other one

http://www.symantec.com/docs/TECH235460

Will see

If someone can explain me how to upload image we are able to read ? I upload a 3154x945 image, and the connect platform reduce it to "not enough" !

Here the images

Here the recommands from Symantec support, thanks Matthew,

1) Run the Import Patch Data for Windows (PMImport) task while the source server is available, also enabling the "Automatically revise Software Update policies..." option enabled
2) Run the Check Software Update Package Integrity task on the source NS and then the production NS to fix broken source locations
3) If packages now have proper source locations but still do not exist on the production NS you will need to recreate packages for their bulletins

 

So the correct process is the one describe in there

http://www.symantec.com/docs/TECH204095

associated the one http://www.symantec.com/docs/TECH235460

apply correctly the TECH204095 and get back the package folder creation correctly not error, we do not use ACC or PDC, reusing the Application credential all parts.

• Change registry (HKLM/SOFTWARE/Altiris/Altiris Agent/Package Server/EnableDACLManagement=Dword:0)
• icacls * /t /reset  (from cmd in admin mode, on the package repository)

No need to iisreset, to make it works (package services into SMB not using IIS).

The “proxy” error was in final removed by removing any proxy settings into Altiris console “Notification Server Settings / Proxy: Do not use”

That is crazy !

Because I don’t get any updated policy update on the site server/package service agent, when changing this proxy settings. Of course, NS not any more able to access the Internet…

But WHY those site servers are they using this proxy settings to get their package from the notification server himself ? That is amazing !

Is it something new added with the CEM (cloud) feature ? Or was it by design from Start ?

I can believe in some situations, with the cache option, this can be useful to use a proxy internally to get download package, with a reducing traffic from Datacenter where the NS is, but mainly, Proxy is used to access Internet !

Why not separating the settings ?

Explicit provide a proxy settings for site servers, instead of a global one, same for NS access Internet and Site package services to get access NS packages (using http/https, of course, SMB/UNC do not use the proxy, and happy, this allow most installations are working)

We don’t really need to deactivate http/https, but was an attempt to force UNC, in fact another issue. See next, the process I do not test to deactivate http provided from Support escalation.

For your information, the support escalation provide the following process to deactivate the http/https ! (as NSconfig not any more with) But I do test it.

- In the Notification Server, browse to C:\ProgramData\Symantec\SMP\Settings
- Make a copy of the 'CoreSettings' file (Highlight the file name > Ctrl C > Ctrl V in the same folder)
- Open Coresettings.config file as an administrator using notepad or notepad ++
- Scroll down to 'GetPackage Info Settings'

- The below three entries should be found there.
  <customSetting key="GenerateNSUNCPackageCodebases" type="local" value="1" />
  <customSetting key="GenerateNSHTTPPackageCodebases" type="local" value="1" />
  <customSetting key="GenerateNSHTTPSPackageCodebases" type="local" value="1" />

- Change the HTTP and HTTPS entries to 0 value. UNC entry value should be left as 1.
- Click save
- Please ensure the changes made get saved in the 'coresettings.config' file.
- Once changes made have been verified in the file, please test and advise if this forces UNC for NS to distribute packages to package servers.

If someone apply this one above, thanks to share the result !