In many instances in our enterprise we have had issues with system accounts being able to perform tasks on the network, so we use some read only service accounts for those specific purposes. Now in this circumstance, it is not very practical for wide scale deployments to change the service account on every agent installation So I did a search and found this article:
The summation is that when a service is using the "Local System" account, it is browsing the network using the Computer's AD account, and not the currently logged in user account. So in that context, the ""boost::filesystem::status: (0x5) Access is denied" is technically by design. The computer account itself does not have access to my folder share. From there I went to my server and added "Domain Computers" with read only access and BAM, installation task succeeded!
I now have a local folder that hosts all of my installers and is accessible via this path file://\\servername\ESET_INSTALLERS\eset.msi, when I setup my install tasks. The folder has Domain Users and Domain Computers with read only Share and File access. No issues after that!
Hope this helps.
P.S.
I'm on Server version 6.2.171.0 w/ Web Console version of 6.2.155.0.
Cheers and good luck!
THANK YOU VERY MUCH.
I did not know the exact behaviour of Local Account network task related. Your solution is clear and perfect in a domain environment.
Thank you again for taking the time to share your experience.
ERA 6: Software Install fails
in ESET PROTECT On-prem (Remote Management)
Posted · Edited by MarkoneTT
THANK YOU VERY MUCH.
I did not know the exact behaviour of Local Account network task related. Your solution is clear and perfect in a domain environment.
Thank you again for taking the time to share your experience.