CBAdminLeavitt

From what I recall, in a non-domain environment, is that Windows will try to send its credentials along first and if they match, it will let you in to the share, if not, then brick wall. Here is an example: (Even though all my PCs are Windows 7, this should work with XP as well and 8.1 I believe.) Media Sharing Host (Windows 7, non-domain) My computer (Windows 7 laptop, Non-domain) Roommate Computer (Windows 7, non-domain) Now when I setup the Media Sharing host, it and my laptop have the exact same username and password to log in. So when I shared something from the Media Sharing Host, I was instantly able to map to it from my laptop. Now, I wasn't about to give my roommate my password. So I went to the media sharing host and created an account with the exact same name as the one on his PC, then I let him type in his the password he uses on his PC. After that I added him to the shares and bingo! Zero issues accessing everything that was needed. So applying that here, I believe you should be able to do this: (Please keep in mind I've never tried using windows default authentication this way, so this is a theory and may not work) 1) Create new account on your ERA Server 2) Give that account access to the file share where you are storing your installers (It needs at least READ access to work) 3) Create the exact same account username and password on all client computers, and make it a local administrator. 4) On each client machine, access the Services panel (Start -> Run -> Services.msc) and find the ESET Remote Administrator Agent service. 5) In the Log On Tab, click the dot next to "This Account:" and then specify the new account you created across all machines, then click OK. If the theory and application holds your clients should now be able to access the share, download, and install as instructed by your ERA server. I know this is a lot of work per machine, but it is the only way I personally can think of, to get this working in a WORKGROUP environment. Please keep in mind, I have absolutely ZERO idea if ESET supports this configuration. I have a sneaky suspicion that they likely don't, but it should still work. Hope this helps! Cheers! CB

Not sure if anyone is still watching this forum, but I may have a possible solution to offer. I was getting this exact error: When Kamiran.asia said this, it got me to thinking. 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: hxxp://serverfault.com/questions/135867/how-to-grant-network-access-to-localsystem-account 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!