We'd love to hear about it! Click here to go to the product suggestion community
Due to a really annoying limitation of the security VM, where I couldn't change a basic network settings without redeploying the VM (and therefore all of our previously deployed guest VM agents), I have had to deploy a new security VM using the latest deployment tool.
After completing deployment, I find the new VM has a password on the public share, which has broken our existing agent deployment method, of a startup script.
Can someone tell me how we are now supposed to deploy the agent, as group policy does not account for providing credentials for a share, when running a program from a share.
Support aren't really providing much in the way of answers, leaving our environment completely unprotected.
Hi Cory IT
Let me check this with my team and someone shall get back to you on this.
Could you please confirm few things here:
How are you trying to deploy the agents? In case you are trying to re-deploy the agents via remote tools, then please check "Deploy software via remote deployment tools" in the article. Also, I would request you to PM me the case number you have registered with Support so that I can take a look.
In reply to Shweta:
To add to the above query, installing the Guest Agent regularly via group policy is not part of the intended design. Once the guest agent is installed once it should update itself. You can take a copy of the guest agent and put it at the location with a non-password protected share. Install once using Group Policy from there and then let the GVMs update by themselves from that point onwards.
Historically, we simply have a GPO that ran a startup script, running the installer directly from the public share of the SVM.
We want to continue in this fashion as it has been working without issue, but as the public share is now password protected, it does not work.
Support have advised me that it is best practice to install directly from the public share, as the installer gets updated with the SVM, which makes perfect sense and is what I want to do.
It looks like now though, if this is what we want to do and via GPO, we have to have a far more involved script that uses mapped drives to work around the credential issue.
What we want to do, is tell the GPO to simply run the following script:
\\FLX-CL-FS01\System\Installation Packages\Sophos\SVE-Guest-Installer.exe SVMIPAddress=10.0.0.30 /install /passive
Why has the new version of the SVM deployment tool, secured the public share with a password? Surely that means it is no longer "public"?
In reply to Cory IT:
I have checked this with our team here and it seems that the public share does not require a password - only the logs share. This article lists out the supported deployment methods. Let us know if you have any further concerns
That used to be the case yes, but in the latest deployment tool, you are prompted to enter a password for the public share during deployment.
When I then try to access the public share via its UNC path, I am prompted for those credentials "sophospublic" and the password entered during deployment.
Unless I enter that password, I cannot access the share.
I would not expect the public share to require a password, as that's surely the whole point of it being public?It has broken our existing working deployment method.
In that scenario, I would request you to open a support case as it might require further investigation. Please PM me the case details once done.
I did already (will PM the case no. to you), but the suggestions on how to work around this are mixed and don't really make sense to me.
Thank you for providing the case number, I have reached out to the concerned team and they will be following up with you in this case. Please DM me if you face any challenges.