Sophos installation fails

HI Paul, 

Could you provide more information about the product you are using On-premise endpoint or Cloud based Endpoint ?

Could you also share your License info via Private message to let us check from our end. 

Also please provide a Copy  of the Script and Check the connectivity to the Shared Drive . 

Thanks and Regards

Aditya Patel | Network and Security Engineer.

Hi, 

we are using an On-premise end point. However this server is not on clients premises. We use this server to manage all our clients' endpoints remotely. We are using Sophos Enterprise Console 5.3.1. Connectivity to server is ok. 

Is there any way to get license info from the console? What script do you mean?

Hello Paul Ditrih,

What script do you mean?
guess Aditya Patel is referring to the setup.vbs you've mentioned. Question is, how exactly do you install? When installing from the CID (either with Protect Computers or an equivalent method which simply starts the setup.exe) there's no setup.vbs involved. If you create a package with the Deployment Packager tool a setup.vbs is included as the RunProgram for the self-extracting installer.

license info
not relevant here for on-premise, license credentials (the ones you use in the Update Manager configuration) would do.

Christian

HI CHristian, 

regarding the setup.vbs - We have installation file created by deployment utility. The installation itself is silent. So, we run the file - no more interaction. However what happens is that we get error during installation saying that the setup.vbs does not exist. 

I am not aware of any license credentials for update manager configuration. 

Miroslav

Hello Miroslav,

license credentials for update manager configuration
in SEC's Update managers view, Configure update manager, tab Sources there's usually Sophos as source. You configure this when completing the initial installation and if everything works never touch it again. Anyway, that's not the issue here.

The Deployment Packager uses 7zip and instructs it to ExecuteFile setup.vbs, 7zip's sfx module unpacks to a subdirectory in the user's (or SYSTEM's - depending on by whom the package is executed) %TEMP% and then calls Windows to "open" setup.vbs. The file is there as you say (otherwise 7zip should have complained if it can't write) so why WScript apparently can't find it evades me for the moment. Could you please post the exact error [you are getting] from Windows Host Script (perhaps a screenshot)?

Maybe Process Monitor can give some insight.  

Christian

Hello Christian,

I had a look at processes - initially, i can really see 7zip module running, then it disappears and nothing else happens. In temp folder, no log file is present. This happens on one PC. The other PCs are coming up with the error as follows:

Hello Miroslav,

it's not setup.vbs which isn't found but the error occurs in its line 37, this is usually the line where it runs setup.exe.
Just a wild guess - from the error pop-up it looks like the username has a blank in it ('NTS user') and it seems that wshShell.run sees the path unquoted. Do you use the same user on all PCs (those where it works and where it fails)?

Christian 

Good morning Christian, 

on the computer from the screen shot + other two - changing the username to one without space in it worked. However, we did install it also on Win 7 computer with user that has space in the name and it was OK. Therefore, i believe there is something different to Win 10 and how it handles your scripts comparing to Win 7.  

Regarding the PC (Win 10) with no report on the installation failure - user name is as well "XXX yyy". More likely, the issue is the same. However, regarding this - we can't go and change user profile name as it would include profile paths causing many applications having issues with it. Is there any other solution how to go around this? 

Good morning Christian, 

on the computer from the screen shot + other two - changing the username to one without space in it worked. However, we did install it also on Win 7 computer with user that has space in the name and it was OK. Therefore, i believe there is something different to Win 10 and how it handles your scripts comparing to Win 7.  

Regarding the PC (Win 10) with no report on the installation failure - user name is as well "XXX yyy". More likely, the issue is the same. However, regarding this - we can't go and change user profile name as it would include profile paths causing many applications having issues with it. Is there any other solution how to go around this? 

Hello Miroslav,

Win 10 and how it handles your scripts comparing to Win 7
it's not my script, I'm not Sophos [:)]. Perhaps Microsoft made some changes to the FileSystemObject, can't say as I don't have windows 10 (and actually I'm too lazy to fathom MS's implementation). 
There are two ways to deal with this situation. Please note that it's a one-time action anyway as the package and the user path is only needed for the initial install. Either temporarily add an administrator user without a blank or use psexec.exe to  run the package in the SYSTEM context. Maybe someone from Sophos reads this and requests a change for the Deployment Packager.

Christian