Jump to content

File Security 4.5 to 6.3 | Buggy & current "workaround"


Recommended Posts

This confirmed bug is definitely an issue with migrating from 4.5 to 6.3 --

"You cannot upgrade from EFSW 4.5 to EFSW 6.x using the ERA “software install task” because the upgrade will fail due to a necessary restart."


I've tried to use the "uninstall task" to remove 4.5 first, but that fails as well.  So I can't upgrade and I can't uninstall to reinstall.  There's also no rip and replace for file security. 


What's worked so far --

1) Push the upgrade anyway, knowing it will fail.  The upgrade actually UNINSTALLS the product.

2) Reboot after the failed "upgrade" aka UNINSTALL.

3) Push a new install task for file security 6.3, which will then work.

4) Log onto each server and make sure all components are running - some fail to work (on about 25% of my test servers I had to click enable on a component to get it started...)  ** I have attached a picture of the components that fail to start on some file security servers; rebooting the server doesn't work, you have to manually click enable **


I hope these file security bugs are all fixed in 6.4.X.  I have 200+ servers and the idea of having to logon to each one to hold ESETs hand would be daunting. 


I've seen upgrades UNINSTALL ESET products before.  It's the reason why I'm afraid to upgrade ESET once it's installed.  Every time I post about this or contact support I feel like I'm told this can't be and that I must be crazy.


You need to start using the rip and replace technology for installation/upgrade.  Or you need to revisit your installation/upgrade procedures. 


I constantly tell people on our IT staff once you get ESET installed don't touch it, don't even breath on it.  It might randomly fail and require you to run ESETUninstaller.exe in safe mode for a clean install to work and fix it.


In contrast the ESET rip and replace app works FLAWLESSLY.  Why can't your products use the rip and replace code?  Whoever wrote rip and replace actually knows what they are doing, because it works.


Link to comment
Share on other sites

  • Administrators

What operating system do you use? Protocol filtering is enabled by default only on Windows Server 2012. As for failing upgrade, I'm sure this has been carefully tested and other users haven't reported any such issue either. If you are able to reproduce it, we could check install logs and try to pinpoint the issue.

Link to comment
Share on other sites

It is Windows 2012 R2 and it only happens on about 25% of installs.  I have 250+ servers.  I think what's happening is no one is taking the time to tell ESET anything because the response they get is "it's been tested and it works for us..."

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...