NOD32 v4 problems with Offline Files mode

After upgrading my PC from 3.0.672 to 4.0.314 (both Business Editions, installed via push install from ERA) my computer started frequently going into Offline mode (i.e. Offline Files and Folders). I uninstalled 4 and installed 3.0.684, and the problem is gone.

Has anyone else seen this? Any ideas how to fix it?

OS: Windows XP Pro SP2
Applications running during most (all?) occurrences:
- Excel 2007
- Outlook 2007 (Connected to an Exchange 2007 server)
- Firefox 3.01

 

Hopefully someone at ESET can address this issue as we are experiencing exactly the same problem. Good to see we aren't the only one suffering. We have also reverted back to the previous version.

We are running fully updated Windows Server 2003 Servers and XP Pro SP3 clients, using My Documents redirecting to a DFS namespace.

 

Ditto I am experiencing the same issue and I seem to remember that when I had ver 3 installed that I had a proplem with offline files being enabled but not with the redirected folder itself. In other words if I disabled Offline Files it would funtion useably.

Just for some trouble shooting for the guys who look at this...

Both xp and vista are affected.
In fact now that I think about it my xp machine never got upgraded to ver 4 and still had the issue.

Only verified the issue on 32bit ver of NOD32

And I do not use Smart Security only AntiVirus.

 

I have a case open with support. Did either of you uninstall NOD32 version 3 before installing version 4? I just installed version 4 overtop as an upgrade.

 

Hello,
first of all, please narrow it down to the particular module by disabling real time and web protection, one at a time. Let us know which module needs to be disabled for the issue to cease occuring.

 

The same problem here.

The problem effects only machines with offline files enabled in Windows.
It appears on ESET Smart Security version 3 AND 4.

Disabeling modules did not solve the issue!

The problem seems to be in a central part of ESET.

No solution yet

 

Yesterday, I duplicated this problem on a clean install on Windows XP SP3 with version 4.0.417. The switch to offline mode often accompanied opening an item in Outlook 2007.

Uninstalling 4.0.417 and installing 3.0.684 eliminated the problem.

 

Does anyone use Windows DFS?
Could this be the problem?

 

We do use a DFS structure for our network drives, but I don't really think that the client systems treat it much differently than a straight mapped drive. What makes you think the DFS would have any effect on the problem?

 

I don't think so but dfs seems to be handled diffrently in our case sometimes accessing shares thru dfs can take longer time but we don't have share mappings so its difficult to make a fair evaluation for us.

/Göran

 

I posted a thread about this a little over a month ago, the issue was never resolved. Since installing v4 I've had very slow network response on mapped network drives or when browsing by UNC...when disabling the AV on the client side that didn't solve the problem, disabling on server side did however so made an exclusion (it's for the people's offline files) and figured at least the files will be scanned by their PC....this will not do as a permanent solution though.

 

Well, sins the problem seems to be isolated to a few lucky ones (us ).
So what do we have different in our networks?

DFS is a network related service not commonly used. Most companies share the "old" way like W:\MySource while DFS locations look like "\\MyNetwork\root\..." and the exact location/translation of that is done by DFS service. The underlying folder location can change if you are roaming!
Maybe the problem is somewhere in this translation step.

I am not a programmer, but doesn't this make sense?

I hope we can test today with a system not using DFS, so we can be sure.

 

Same issue here. Eset 4 has brought back a bunch of the old problems v3 had, this one included.

Guess i am going to have to roll back to 3.

SBS 2003 x64 with XP Pro Clients.

 

We use DFS both for mapped network drives (drive letter mapped to a DFS UNC path) and for the redirected "My Documents" and Desktop folders (redirected to a DFS UNC path). I have the option to scan network drives turned off. How does ESET determine what is a network drive? Perhaps it is still scanning the redirected "My Documents" and Desktop folders?

 

To be clear, a deployment of 3 did not solve the offline issues (in our case).
We are preparing for a migration form McAfee to ESET.
So we are doing mainly fresh installations.

 

Tested with a clean windows XP SP3 installation with office 2007.

With old stile shares no problem (including My Documents).
Activated DFS, the problem off-line problem starts (but not right away).
There seems to be a connection with Outlook 2007, also.

After opening ALL communication to the servers, to problem starts to be less frequent.
After opening all traffic to and from ports 67 and 68 (DHCP) on all network addresses the problem seems to disappear!
We need to do some further testing, but these results seems to be promising!

 

Are you referring here to creating Exceptions in the Windows Firewall configuration? Ports 67 and 68 in TCP or UDP?

 

I am referring to port 67 and 68 UDP to ALL destinations on ESET firewall, but as it solved the issue in the test environment the real thing seems to be different.

In test with a existing user the problem persisted. So no solution yet

 

We use just NOD32, not ESET Smart Security, so we don't even have the ESET firewall. We use the Windows Firewall on all of our systems to control inbound connections, but we have no outbound software firewall.

 

We've been tracking this issue since V3, and not long ago it seemed to dissapear entirely after updating Windows Updates on the File Server (DFS enabled Windows 2003 Server), it also has Eset NOD 3.0.657 on it and always has, being such a well used server it's not often we are able to update it. Given the server issues others have mentioned, we're in no hurry to update it, either to the latest version 3 or 4.

However, on any clients we install V4 onto, this issue is back and much more pronounced, as with v3 it was intermittent or only affecting a small number of PCs. It's also effective in both Eset NOD and SmartSecurity, so not an issue of SS's Firewall.

Both NOD and SmartSecurity also have a Web Filter, and this can cause problems, it's worth checking it's not set some app as a web browser that shouldn't be. Somtimes I've seen svchost appear in there with a tick.

However, from our research on this problem (including others experiences on these forums), it's more likely something to do with the real-time system protection. If you go into the options for Real-time file system protection and untick "Start Real-time file system protection automatically" and then REBOOT. You won't experience the offline files problem.

However... when the PC reboots, real-time protection will not be running and Eset will alert you, you can then manually start it, doing so does not bring back the offline files issue.

This workaround is ok for IT Personal, or those who you can trust to manually enable it, but very unlikely to be used as a workaround through a client/company.

We and others have made this clear to Eset, who we're told, are monitoring these forums. However, as of 4.0.424 the issue still remains in v4. Hence we are not pushing out v4 to replace v3 installations yet.

Also, in the last two builds of v4, another issue has started that results in a 400 bad request when attempting to load a Sharepoint intranet. Luckily there is a better workaround for this, which is to exclude the url in the Address Management of "HTTP,HTTPS" of web protection (in both NOD and SmartSecurity).

 

Thanks for the info!
We seem to have created a workaround using this information.

The problem seems to be in a combination of folder redirection + DFS + user folders.

We use ESET Smart Security v4.0.314 in policy mode.
What we did is:

Blocked the svchost in the ESET Firewall Policies as Internet browser ​

In "Active Directory Users and Computers" for user accounts:
Change the Home folder settings
from:
Connect Z: to \\mydomain\data\%USERNAME% (DFS reference)
to
Connect Z: to \\nas1\userdata\%USERNAME%
We don't use "Profile path" and "Logon script"​

In "Group Policy Management" "User Configuration"
Change the "Windows Settings"-"Folder Redirection"-"My Documents"
from
Basic - Redirect everyone's folder to the same location" - "Path = \\mydomain\data\%USERNAME%" (DFS reference)
to
Basic - Redirect everyone's folder to the same location" - "Path = \\nas1\userdata\%USERNAME%"​

This is a workaround for our users.

But..... we lose the flexability of DFS for user directories.
For other drivemappings using DFS there seems to be no problem.

In our case there is no need to toggle the "Real-time file system protection", so no user interaction needed.

Unfortunately no response from ESET so far regarding a real solution.

We keep on testing, please post your test results/improvements!

 

Unfortunately the problem returned misteriasly after the weekend on a test machine. We did a reset of the offline cache folder and we were able to work again.
Maybe some old reference in there.

 

This is getting silly now. This has been a problem ESET have been aware of for well over a month now. We have even had two further build since this was reported and still nothing has been done about it. We aren't even getting any reponses from ESET now, I am becoming more and more unimpressed with the level of service we are all receiving. A very reliable product and decent support is slowly going bad. Come on ESET, we are your trusted customers and deserve at least a response.

 

I am having this issue as well along with the 3019 event log spam. Do you guys have the 3019 error as well?

 

Hmmmmm same as me, lots of laptop owners very un-happy grrrrrrrr.


stevef1