234 votesStarted · 66 comments · Sophos Central » Endpoint Protection · Flag idea as inappropriate… · Admin →
Jon, it is really frustrating that the first comment of sophos for the idea "offline installer" is - "it's not a offline installer".
It's the same if the moderator of a dancing show says "we listen to music, but we dont't dance here".
Your clarify absolutely dont sounds like what - we customers and partners - meant with the title of this idea.
An installation package with additional parameter for the existing installer for a cache location is really not what a offline installer does and on other side it's already possible to install from cache location (see the link two posts before).
An offline installer provides a graphical gui where computers can be selected or imported (via Windows Network Discovery, Active Directory Import, IP-Range, csv file) and so on. Then the "install button" is pressed and the machines are deployed. If a machine was not reachable while first attempt the installer try again for x times after elapsed time of x in between. - thats an offline installer. Tell this to your developers.
Btw, it's absolutly okay to receive actual policies via internet, but after! first time installation. At! first time installation they should be that from the time the installation was created (meaning of offline). If not sure, make an selection for this question in the gui.
A 4 minute search shows who already can do clean remote installs:
Indeed it was hard to find someone who cant do it - except sophos.
I really can't understand why the compared high priced sophos can't do...
And of course, the list above are our daily competitors.
You make the selling hard for us...
Meanwhile almost one a half years are passed and still no "real" offline installer. We are not interested in caches and workarrounds, just provide a real usable remote installation utility like all the others have.
How long should we wait.... additional 2 years?...
And of course - this is a mess... "offline install" while we have to copy all files manually - Really? - Come on make a program that does this and starts setup.exe afterwards. How hard this can be for development experts?...
If you are not able to do so, contact us, give us 8tsd euro and wi will do it for you within a month ^^
..and... the install should try the setup more times not only one time. As for example if the devices are not powered on at planned setup time. So it should for eg. try again for x times or for x hours/days or every x hours
In addition to this deployment software, i would suggest to integrate optional parameters (like the old depyloyment packager had) may just to fill in, to determine the target groups the new device and/or user should be placed into
i strongly agree! So much needed.
To get this Request better found via search, i post this keywords in comments:
Deployment Packager, Deployment Tool, Remote Installation, Remote Deployment, Remote Installer, Endpoint Deployment, Server Deployment
I can agree with that. A remote installer is needed. It should be capable of installing Endpoint/Server/Intercept Protection within targeting single ip, ip-ranges and of course Active Directory paths. For better usability it should be possible that the software when AD-Computers are targetet and the agent is not installed, that it tries multiple configurable times. For eg. if not installed try to install and if error try again every 2 hours.
What we will do:
Allow XG software installer to run on XG hardware appliances, after removing current partitions (same option as UTM9)
What we are not planning:
We will not allow software install to run trivially on a system currently installed with XG.
We will not make any effort to support on-system wireless, on software installs.
The system will not report itself in any way as an XG appliance, inside the OS.
Im bought some SG105 Rev2 Hardware. Give it a memory update. So know i tried to install XG Home Edition 17.5xx no problem, install success with hardware edition download. But i have no chance to register it for private use... what a mess..
Can support this feature. Outgoing TLS to specific domains is a needed feature. Also already built in at competitor products. Alltrough, incoming domain sepecifica are already there, so just change a few lines in the exim.conf file to support this, nothing great developement needed.
Can support this. A vote for german language from our side.
Can support this. Please add special characters.
That is same request as already here... you should vote there...:
Unintelligible for me that it is'nt already implemented since years. Without this it is impossible blocking or allowing special ports to special destinations. Its impossible to handle hundrets of single entries that change every second day. No way, this wildcard (which is already a feature on other vendors since years) is truly needed.
This feature was implemented in XG Firewall