ERA 6: Software Install fails

[satellite360 0]

Attempting to install Endpoint Security on clients by direct package URL.  The URL is set to file://ServerName/Path/ees_nt64_enu.msi which works fine when run directly from a client but fails with the following error when run from ERA:

2015-04-13 03:34:41 Error: CSystemConnectorModule [Thread 102c]: Software installation failed: GetFile: Source path 'file://ServerName/Path/ees_nt64_enu.msi' does not exist

 

Grateful if someone could let me know what I am doing wrong.  Thanks.

[Marcos 5,468]

Please provide us with step-by-step instructions of what you did. Currently custom repositories are not supported so you should install agent via a push install which would subsequently download an Endpoint installer from ESET's server unless a proxy server is configured and the msi installer is cached.

[satellite360 0]

Please provide us with step-by-step instructions of what you did. Currently custom repositories are not supported so you should install agent via a push install which would subsequently download an Endpoint installer from ESET's server unless a proxy server is configured and the msi installer is cached.

I followed section 6.1.3.1 (Client Task Wizard) of the ERA User Guide.  I know the task is set up correctly as it executes on the target clients but fails with the same error on all machines.  If installation from a local file is not supported i guess that explains the problem although it would be helpful if the option was marked as unavailable in ERA if that is the case.

[Mahlon 0]

I have the same problem. GetFile: Source path 'file://ServerName/Path/ees_nt64_enu.msi' does not exist

 

I prefer to use the "Install by direct package URL" option, as not all pc's are connected to the internet and I would also like to save bandwidth for pc's that are connected to the internet.

[Marcos 5,468]

Please post a screen shot of the URI you've entered.

[emam 0]

Source: hxxp://help.eset.com/era_admin/62/en-US/agent_live_installer.htm

 

If you want to deploy ERA Agent using Agent Live Installer from your local shared folder without ESET Repository Download Server, follow these steps:

1. Edit the EraAgentOnlineInstaller.bat file (Windows) or EraAgentOnlineInstaller.sh script (Linux and Mac).

2. Change lines 28 and 30 to point to the correct local download files. For example:

3. Use your own URL (instead of the one shown below):

4. Edit line 80 to replace " ^& packageLocation ^& "

with !url!

5. Save the file.

Edited September 10, 2015 by emam

[burhan 0]

Dear all,

 

Remote agent deployment by editing liveinstaller.bat file works fine. 

 

But we are unable to remotely deploy endpoint security msi file by using custom repository option available in software task option.

 

We tried by deploying msi by giving path file://\\server\admin\ees_nt64.msi ..It gives error 5 Access denied.

 

We tried by deploying msi by giving path hxxp://server/ees_nt64.msi. It gives http error get 403.

 

Is custom repository in ERA 6.2 is really working?

[Marcos 5,468]

Custom repositories are not supported, however, I see that you were referring to a local URI. "file://\\server\admin\ees_nt64.msi" should work, however, the currently logged user must have read permissions for that share.

[burhan 0]

Dear sir,

 

Currently logged user is having full rights on that share and the share is easily accessible via windows explorer and also downloadable via internet explorer on clients side. Then, why eset agent is unable to download the said by local URL file://\\server\admin\ees_nt64.msi. 

 

What more permission is required for eset to download the said setup?

[HSW 9]

Dear sir,

 

Currently logged user is having full rights on that share and the share is easily accessible via windows explorer and also downloadable via internet explorer on clients side. Then, why eset agent is unable to download the said by local URL file://\\server\admin\ees_nt64.msi. 

 

What more permission is required for eset to download the said setup?

 

Example to install with cmd or vbs, permition of the Network path: read + run // when you deploy the msi with GPO than think about permisions for Domain Computers!

 

c:\windows\system32\msiexec.exe /i MSI_FILE INSTALLED_BY_ERA=1 APPDIR=C:\Eset\ /log c:\Eset\V6_install.log /passive /norestart

[Binh 0]

Hi,

 

I have the same issue: "boost::filesystem::status: (0x5) Access is denied"

 

From client, I can access share folder and run the installation package in shared folder.

 

Have you got any solution?

 

Thanks,

[kamiran.asia 5]

Same problem in Ver 6.2 ..

 

We test by

file://\\server\eset\ees_nt32_enu.msi  --- faild with error  "boost::filesystem::status: (0x5) Access is denied"

file://c:\eset\ees_nt32_enu.msi  Works

hxxp://server:3128/ees_nt32_enu.msi( We copy msi file to apache httpdoc forlder and change some setting in it,s config ) works

 

So the problem is just with share resources.

 

Any solutions ?

Edited October 18, 2015 by kamiran.asia

[kamiran.asia 5]

We do many tests and we find that when Agent is runing as system account it can not access shared resources !

But when we chage the log on settings in services and set the log on for administrator it can access the MSI file from file://\\server\eset\ees_nt32_enu.msi .

 

is it a bug ? it is not normal , We test this problem in one network , Any Idea ?

[kamiran.asia 5]

We record this problem in a Virtual Network so dear moderators can see and find it better.

We also send a ticket to ESET Me Support about this problem but no answer is recived yet :

 

hxxp://www.kamiran.asia/uploads/support/Shared-MSI-Problem.html

[CBAdminLeavitt 0]

Not sure if anyone is still watching this forum, but I may have a possible solution to offer.

 

I was getting this exact error: 

 

Hi,

 

I have the same issue: "boost::filesystem::status: (0x5) Access is denied"

 

From client, I can access share folder and run the installation package in shared folder.

 

Have you got any solution?

 

Thanks,

 

When Kamiran.asia said this, it got me to thinking. 

 

We do many tests and we find that when Agent is runing as system account it can not access shared resources !

But when we chage the log on settings in services and set the log on for administrator it can access the MSI file from file://\\server\eset\ees_nt32_enu.msi .

 

is it a bug ? it is not normal , We test this problem in one network , Any Idea ?

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!

[kamiran.asia 5]

We have this problem in workgroup invirement and in workgroup we do not have "Domain Computers" ,

 

The problem is Local system accounts can not access shared folders even when they are accessible with every one with full permisions.

 

ESET Agent is uning Local system account and local system account can not access share folder in another machine. So we must use domian or we must set a account for every client's agent !

 

Any Idea in workgroup networks ?

[CBAdminLeavitt 0]

We have this problem in workgroup invirement and in workgroup we do not have "Domain Computers" ,

 

The problem is Local system accounts can not access shared folders even when they are accessible with every one with full permisions.

 

ESET Agent is uning Local system account and local system account can not access share folder in another machine. So we must use domian or we must set a account for every client's agent !

 

Any Idea in workgroup networks ?

 

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

[kamiran.asia 5]

thanks dear CBAdminLeavitt .

 

Yes As you said if we set Agent to use an account it will access the share foldres but forexamle you have 30 system in Workgroup you must do it one by one or you must use ESET Repository.

 

We think that may be ESET Agent can use Network service account to solve this problem while it is installing the service.

 

So manualyy solitions will solve the permision error as you said.

[MarkoneTT 0]

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!

 

 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.

Edited May 20, 2016 by MarkoneTT