NOD32 v4 problems with Offline Files mode

I am disappointed that whenever I call tech support the wait times are extremely long or no one calls me back to help with this issue. Plus the on-hold music is incredibly annoying. So here I am back on an internet message board trying to get support for an enterprise level product that my company paid for.

 

hi, have you tried to set up eclusions?

a.) %systemroot%\ntfrs folder (include all the sub-folders and files)
b.) Files that have the .log and .dit extension

 

anyway, if your issues persist pls contact me via private message

 

Any progress on this incredibly serious issue? Enterprise customers are being left dead-in-the-water!

 

This seems to work!
Why could not ESET support advise us about this solution?

The exclusion of .log and .dit files were sufficient for our notebooks with DFS shares.

 

I am not running DFS on my server. It's a mapped drive with offline enabled on the laptop. Only nod32 is installed on the laptop.

Really frustrated with this.

 

How can this exclusion have to do with anything? We have no server-side installation, NOD32 is only installed on the clients. What difference would it make to them if .log and .dit files (related to the Active Directory database, physically located on domain controllers and inaccesible by the client machines) were excluded from realtime scanning?

 

I am experiencing the same ESS/NOD32 issue at our University. Setup is the same as others described: ESS or NOD32 V4, My Documents folder redirection, connecting to DFS shares, Offline folders enabled.

The interesting thing I have seen is that the issue happens even with only NOD32 installed, *and* with all antivirus settings disabled (no real-time filesystem protection, no document protection, and no protocol scanning). NOD32 even warns that it's not doing anything to protect the system.

Still(!), Windows will take My Documents off-line, especially under heavier network loads. Uninstall NOD32 (and install another AV product), and the problem goes away.

 

This problem has existed for well over a year now, and hasn't been addressed in the slightest by the Eset development team, despite the fact that an entire major version release came in the meantime.

This needs to be properly addressed, debugged and fixed RIGHT NOW, otherwise enterprise customers will be forced to switch to alternative solutions. I have to say that I've already prepared mine for that unfortunate possibility.

 

I'm not certain it's connected, but I started having problems with Outlook 2007 refusing to collect mail properly (POP3 server). It would hang and display the 'Windows is synchronizing files' message despite offline files being turned off and there being no Exchange involved.
Just in case I'd picked up something nasty, I ran a full scan with NOD32 which got half way through then crashed - I then noticed that Outlook had started working.
I uninstalled NOD32 and stuck on Avast and so far, Outlook has been back to normal.
Pity I'd just renewed my subscription

For info, this was NOD32 AV (not the whole suite) v3 running on XP Pro with all the latest patches. Workgroup, rather than domain, setup.

Steve

 

Re: NOD32 v4 problems with Offline Files mode (possible solution)

Disregard, problem is still there. Thought PM_MODULES had something to do with it, but evidently not. Damn this is frustrating.

 

The exclusion of *.dit and *.log was done on the client side.

 

Please read my post more carefully. I make no reference to server-side scanning other that it isn't done.

 

On my machines here, having Antivirus protection, Anti-Stealth, Self Defense, Protocol Filtering *all* disabled has no effect to resolve the problem. Exclusions will make no difference as there is no scanning taking place at all! Just the fact that NOD32 is installed/running, even with no file scanning whatsoever causes the offline files problem.

I see a new release of NOD32/ESS v4 has come out, but sadly no mention of this issue being fixed in the release notes.

Back to looking at other enterprise AV products I reckon...

 

aaaaaaaaaaaaahhhhhhh same problem here when i upgrade NOD32 V3 to V4 i encounter the problem they could not print to network and disconnect to network.

 

In previous builds to 437, there's a 400 page error when loading a SharePoint Intranet, now in 437, that no longer happens, but instead a user is bombarded by login popups.

Yes this part isn't so much Eset's fault but Microsoft's. When a PC "goes offline" (Windows XP) it treats ALL network connections as offline, so you lose all other mapped drives and printers until you synchronise and are back online (where, thanks to Eset, you then almost instantly go offline, or do as soon as you visit "My Documents"). It's maybe worth mentioning they've improved this a little in Vista (about the only thing), where it won't treat all connections as offline, just any connections to that particular server. Of course if you're a small business with an SBS server, it's likely that's your only server so unlikely to make much difference. It would be far better to be able to evaluate per network resource.

 

Hey guys. Same issue here and this post is the first one I've seen where someone is actually getting closer to a solution....or at least the cause. Before reading this post, my issue was that we had a serious delay in response to opening "My Computer", Windows Explorer, IE, Start Menu and some applications. We too are using DFS and also mapping a personal drive via user profile among a handful of other drives (all are on the DFS root) via login script.

When I saw this post I realized that I have too seen Offline Files mysteriously turn itself on on a few PCs on our network. Out of 600 or so users, we've only seen this on about 5-10 PCs, so I never related this to NOD32 and thought the user turned it on by mistake...or one of our Domain Controllers was acting flaky (we've got one that's running Win2k and was setup by morons years ago.)

So, here is what I've found out so far....(sorry that some of this is redundant to some of your previous posts...I copied my text below from another post. I'm lazy.)

When I pushed out version 4.0.417 from the RAC, I did not manually uninstall ver. 3 from my clients. I let the automated installation from the RAC perform the installation over the top of ver. 3. This, I thought was the original cause of my issue.

Moving forward in troubleshooting, I first uninstalled NOD32, rebooted (twice after reading a post in this forum) and reinstalled. This did nothing for my issue. In fact, reinstalling and the issue would soon (not immediately) come back.....it may take several hours or the next day for the issues to resurface.

I then noticed that I could make this symptom disappear by disconnecting all my network drives. When I reconnected them (via login script), the symptom would return. So I then tried to disconnect each of the drives one at a time to figure out which one was giving me trouble. I noticed that our Personal drives (mapped not in the login script, but in the Active Directory user profile) was mapped using a different method than the other mapped drives that I receive via login script. We are using DFS, which if you haven't used DFS drives before, you map drives as \\domain name\share rather than \\servername\share. I noticed that our personal drives were mapping the drive via the short name of our domain \\domain\share. Just for kicks, I changed my drive mapping to use the FQDN (\\domain.com\share) and rebooted. To my surprise, my symptoms went away and have stayed away. This looks similar to what you did BennoHofschreuder with mapping your drives to the NAS name rather than the DFS root.
So to move forward, I ensured that any mapped drive, whether the personal drive in the user account's profile or a drive mapped via a login script used the FQDN rather than our short name.

I then opened up a case with ESET to ask them why this happened, why DFS had anything to do with it and what was causing it...because it was very strange that using the short name versus the FQDN in a drive mapping shouldn't really have any bearing, as long of the names are resolved by DNS. Reproducing the issue, ESET had me check several settings on both my WinXP clients and on the Win2k and Win2k3 servers, most, if not all you have mentioned above. They had me turn off scanning of Network Drives, omit certain Windows files (however not the latest ones that kanalQko mentions) and folders and turn off Email scanning...just to name a few. These solutions did not resolve my issue.

Their next step was for me to install Wireshark and start accessing network shares, sending ESET the Wireshark log afterwards. I have not completed this step yet. (Anyone else want to try that?)

Since then, changing the network drive mappings has fixed my issue on most clients, but I'm noticing that this issue is a two headed beast. Some people are not having anymore issues since I changed our drive mapping scheme. But others are still having issues. If someone is still experiencing an 8-10 sec. delay in opening up explorer or applications, I can uninstall NOD32, reboot, manually delete any residual files/folders/Registry entries (per ESET manual uninstall instructions), reboot a 2nd time, then push out ver. 4 (4.0.424) and the user doesn't experience anymore issues.

This post prob. doesn't help much, but I wanted to let you know that you are not the only one having this issue. I will try and collect some packets from a workstation that is still having this issue and get it sent off to ESET. Maybe that info. will help them come up with a solution for this issue.

 

According to ESET the latest version of ESET products solves the issue (v4.0.437).
We will start testing immediately.

 

Where did you run across this information? If you got it from the ESET website, can you post the URL?

I download v 4.0.437 last week and have started to deploy it on a case-by-case basis, with fingers crossed. Although I didn't see any mention of this version fixing this issue in the list of fixes.

 

Version v4.0.437 does NOT solve the issue

 

Wow...that was a quick turnaround. I'll see if I can grab a PC still having this issue and grab some packets with Wireshark. Hopefully ESET can do something with that.

My organization implemented DFS when we had several (~20) servers that didn't individually have enough disk space to host all our files. This was before my time. Since then, all but one of us has argued to ditch DFS since we consolidated servers considerably and have plenty of disk space on our SAN. This may be the cherry on the cake to finally get us to bail on it.

I originally opposed DFS, but I have recently had to create a new DFS root so that we can migrate all our old DFS files over to. I do have to admit though, It's been pretty flexible. I wouldn't have this flexibility of linking folders if we were not using DFS and linking directly to server shares.

 

BennoHofschreuder...are these exclusions still fixing your problem? I know it's not really a fix, but I guess it's better than nothing.

 

The exclusions, naturally, do absolutely nothing in regards to this problem (yes, I've even tested it, but using pure logic is enough to arrive to such a conclusion).

 

I originally gave it the ol' raised eyebrow myself, but never saw an "official" post that it wasn't working. Thanks for the confirmation.

 

We also have this problem. I have tried upgrading to the latest version (4.0.437) and excluding *.dit and *.log but it hasn't fixed the issue. Our configuration is windows XP Pro workstations. Windows 2003 server + DFS shares. Offline folders randomly go offline. i have also tried disabling antivirus on the server (NOD32 v2.7) but that also didn't help. Disappointed as I saw this problem with earlier versions of NOD32. I am afraid that if there is no fix or workaround to this problem that I will be moving our organization to another product. Shame because I loved version 2.7

any other suggestions much appreciated.

regards,
Mark Harre
Euram Bank