NOD32 v4 problems with Offline Files mode

[elangeland]

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

[benjsmyth]

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.

[beatified]

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.

[elangeland]

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.

[Marcos]

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.

[BennoHofschreuder]

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 >:(

[elangeland]

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.

[BennoHofschreuder]

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

[elangeland]

-{ Quote: "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?

[goran_larsson]

-{ Quote: "Does anyone use Windows DFS?
Could this be 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

[cavaliersa]

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.

[BennoHofschreuder]

-{ Quote: "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?" }-

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.

[weeksgroove]

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.

[elangeland]

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?

[BennoHofschreuder]

-{ Quote: "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." }-

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.

[BennoHofschreuder]

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!

[elangeland]

-{ Quote: "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!
" }-

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

[BennoHofschreuder]

-{ Quote: "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 >:(

[elangeland]

-{ Quote: "I am referring to port 67 and 68 UDP to ALL destinations on ESET firewall" }-

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.

[AJStevens]

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).

[BennoHofschreuder]

-{ Quote: "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! :thumb:
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.:argh:
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!

[BennoHofschreuder]

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.

[benjsmyth]

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.

[thespamcenter]

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

[stevef1]

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


stevef1

[thespamcenter]

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.

[kanalQko]

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

[kanalQko]

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

[mkuntic]

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

[BennoHofschreuder]

-{ Quote: "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" }-

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.

[thespamcenter]

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.

[mkuntic]

-{ Quote: "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." }-
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?

[otagobrent]

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.

[mkuntic]

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.

[sclg]

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

[otagobrent]

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

[BennoHofschreuder]

-{ Quote: "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?" }-
The exclusion of *.dit and *.log was done on the client side.

[mkuntic]

-{ Quote: "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.

[otagobrent]

-{ Quote: "The exclusion of *.dit and *.log was done on the client side." }-

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...

[VSSC support]

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.

[AJStevens]

-{ Quote: "...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 [4.0.437.0] the issue still remains in v4. Hence we are not pushing out v4 to replace v3 installations yet..." }-

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.

-{ Quote: "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." }-

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.

[clutch]

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.

[BennoHofschreuder]

-{ Quote: "Please read my post more carefully. I make no reference to server-side scanning other that it isn't done." }-
According to ESET the latest version of ESET products solves the issue (v4.0.437).
We will start testing immediately.

[clutch]

-{ Quote: "According to ESET the latest version of ESET products solve 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.

[BennoHofschreuder]

-{ Quote: "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 :argh:

[clutch]

-{ Quote: "Version v4.0.437 does NOT solve the issue :argh:" }-

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.

[clutch]

-{ Quote: "The exclusion of *.dit and *.log was done on the client side." }-

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

[mkuntic]

-{ Quote: "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).

[clutch]

-{ Quote: "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.

[MarkHarre]

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

[El Pollo Diablo]

Same problem here. NOD32v4 + DFS + Offline files = folders going offline all the time. The same folders accessed via a direct share, no problem.
I had the same thing in v3, but disabling optimized scanning in the options removed the problem, while having a limited impact on performance in my context. No such luck with v4, even disabling all the protection modules doesn't prevent the problem.
Our contract expires in august, between that and the other problems I'm seeing or reading about with v4 I'm really not sure we're going to renew it.

[mkuntic]

The problems don't pose that much of a problem per se - bugs have and always will exist in software - but the apparent blatant year-long disregard for them by the developers is quite discouraging.
-{ Quote: "I had the same thing in v3, but disabling optimized scanning in the options removed the problem" }-
This does absolutely nothing, as well (in v3).

[mkuntic]

Are we going to live to see this fixed?

[otagobrent]

Our vendor here has a support call into ESET which is two months old. Both have stopped giving any information on the case.

[otagobrent]

Question for the forum: ESET has not resolved the Offline files issue. From the posts, the problem has existed well over a year, across major versions. I am unable to install the software in our environment, and have been using another product. Our renewal for NOD32/ESS arrived today, and the renewal cost is 300% (3x) what I paid originally for the license last year. Should I renew?

[mkuntic]

-{ Quote: "Question for the forum: ESET has not resolved the Offline files issue. From the posts, the problem has existed well over a year, across major versions. I am unable to install the software in our environment, and have been using another product. Our renewal for NOD32/ESS arrived today, and the renewal cost is 300% (3x) what I paid originally for the license last year. Should I renew?" }-
N o .

[caster]

running version 4.0.417 we are now experiencing this issue. What version of nod32 antivirus is not affected by this? NOD32 worked flawless in the one year I ran it but since upgrading to 3/4 I have seen this issue. I am actually starting to test kaparsky internally.

[thespamcenter]

Hey figure it's time for the usual monthly update to ask is there any resolution in the works for this problem? I am tired of calling tech support everyday because your on-hold music is terrible... I guess it does it's job well :argh:

When my IT friends ask me about which AV to get the answer is not nod32 for the enterprise.

[Proximm]

I waiting for any suggestion how to resolve this problem with offline folders + DFS in AD. I exchange a several mails with eset supprt without any solution. I'm dissapointed.

[mkuntic]

Thank God Microsoft Security Essentials is coming soon...

[Matt_C_UK]

Just rolled out NOD32 v4.0.437.0 to our buisness with no knowledge of this issue and now stumped!

We bought via a reseller who are a support company in thier own right, so they have escalated it to NOD. Lets see what happens.

Only solution.....switch offline files off....:o

[Proximm]

hey guys. Try to disable webclient service :>

[mkuntic]

Please someone verify that this bug still hasn't been fixed in 3.0.694.

[WayneP]

For everyone still having an issue with this, please see the information in the Knowledgebase article found below:

How do I resolve conflicts between my ESET security product and DFS Replication on Windows Server 2003 R2?:

http://kb.eset.com/esetkb/index?page=content&id=SOLN590

[mkuntic]

The suggestion by the MS KB article to disable scanning of DFS-replicated folders would pretty much negate the usefulness of the antivirus engine altogether. Since users have redirected MyDocs/AppData/Desktop folders on DFS paths pretty much EVERYTHING they open and run would not be scanned.

[PhoenixUA]

v4.0.467 released
Could somebody test the problem with new version?

[El Pollo Diablo]

I've just been testing v4.0.467 and what a huge surprise, the problem is still here.
This problem plus the joke of a workaround proposed by WayneP (DFS replication isn't even used for offline files on client computers) plus the various other problems with v4 especially on Windows 7, well, that does it for me : Eset has just lost my company account.

[mkuntic]

Goodbye. It's been fun while it lasted.

[otagobrent]

Did this problem ever get resolved with ESET/Nod32? It's been a long time since anyone has posted anything with regards to the DFS/Offline-files issue. I'm wondering if the problem has been resolved, or did people just give up trying to get it fixed by ESET?

[elangeland]

I have given up on ESET. We are presently migrating to Kaspersky Anti-Virus.

[BennoHofschreuder]

We are stuck until out renewal.
Versino 4.2 is out now, we did not test for DFS yet, but we have given up hope....