Jump to content

Foiler

Members
  • Content Count

    6
  • Joined

  • Last visited

Profile Information

  • Location
    New Zealand
  1. Our next step would be to temporarily change the Eset antivirus to something else eg AVG free .. but unfortunately the end user is now completely fed up and would prefer to have to enter the O365 password frequently than to make any further changes. This project is hence on hold.
  2. Further update .. we still have this problem. Microsoft have been unable to solve this one after 34 emails from them, and countless hours on the phone with shared sessions. Here is what Microsoft have done so far, but the problem persists. 1 Created a new Outlook profile. 2 Re-installed Office with Easy Fix Tool. 3 Cleared cached credentials. 4 Created a new Windows Profile. 5 Ran Autodiscover regkey fix. 6 Disable IPV6 7 Made sure Network is set to Work instead of Public. 8 Deleted OST file. 9 Disable MF
  3. Thank you Marcos .. sensible suggestion to uninstall and test, but I am a bit nervous to do that given that we would have an unprotected workstation for a day or two while waiting for a password prompt, or not. Also not a conclusive test by the nature of the beast unless we uninstalled it permanently. Microsoft have a product called SARA https://support.microsoft.com/en-nz/help/4098558/how-to-scan-outlook-by-using-the-sara-tool and this failed so we could test that with Eset uninstalled. There is some suggestion by Microsoft that port 443 is being interfered with - could Eset possib
  4. A business with only two Windows 7 computers on the network both have the same problem .. Outlook prompts for re-entry of password almost every day. Microsoft support are suggesting we have "network problems". However, this is a very unsophisticated setup, just a simple network and an inexpensive router with default setup. The mail setup is Office 365. The only "network" filtering possible would be the antivirus perhaps? Windows Firewall is disabled. The antivirus is Eset Endpoint Antivirus version 5. Is it possible there is a setting in that which is blocking port 443 or access
  5. A business website uses a cookie to maintain login to that website. One user out of six on the LAN experiences logoffs when using Chrome. Presumably this is due to Eset blocking read or write of the "login" cookie, or perhaps deleting it? All users are on ver 5 Eset Endpoint Antivirus and are getting policy from the RA server. If the user uses Firefox there is no problem, and likewise temporarily disabling Eset (eg for 30 minutes) also alleviates the problem. I have tried the following to no avail: set exclusion by path to the Chrome Cookie folder set proto
×
×
  • Create New...