NOD32 and Simply Accounting 2009

I have identified a conflict between NOD32 AV Business Edition 3.0.684 and Simply Accounting 2009.

The situation is a Simply Accounting client machine connecting across an internal network using Simply's native connection manager to a shared network folder on a server.

Connectivity is fine for the most part, and a user can work with the files with no problems UNTIL the user backs up the simply files, in this case to the local desktop on the client machine. After the backup successfully(!) completes (yes the backup itself is ALWAYS successful), Simply cannot re-open the database, crashes and reports an error.

After this initial failure, connectivity is unpredictable, opening the database sometimes is successful, and sometimes fails. Only until the below solution is performed does it once again become reliable.

The solution, such as it is, is to completely disable Scan on File Creation in the advanced settings for Real Time file protection system protection settings on the NOD32 install residing on the server.

Strangely, once the above is done, and Simply is opened again on the client machine, (it is always successful once the above is done), if you then turn the Scan on File Creation feature back on in NOD, subsequent attempts to connect with Simply are successful, UNTIL the user tries to backup again! Stranger still, throughout all of this, at any point, I can navigate to the shared network drive to the Simply database files, and perform a copy paste to any local machine, indicating to me the files are NOT locked!

Something about the unique way Simply is creating/modifying the files is triggering NOD to do SOMETHING to block it afterwards...

Can anyone offer an opinion on this, pretty please?

 

I have no immediate help on this, as I'm working through a similar issue... have a customer with WS2003, NOD32 3.0.684, and Simply Accounting 2009 with the data files hosted on the server, running the Simply Database Manager of course.

Customer can't open Simply 2009 from a desktop client running XP and successfully connect to the data unless I disable NOD32's real-time file system protection. Simply's FAQ suggests to allow a bunch of individual EXE and DLL files; I've excluded the entire program folders where these lie, and still no worky.

Just throwing this in just in case someone's resolution might help us both.

 

Make sure that you are excluding the Simply Accounting DB on the server. Also make sure on the clients that, “scan network drives” is unchecked under real-time file system protection. The problem is most likely being caused because the AV on the client side is scanning the files since you stated that you have added exclusions on the server already.

-Cheers

 

This is a rather old thread, but still there is nothing helpful at the ESET site. I have disabled ESET Realtime monitoring on this server (SBS2003 SP2) in order to allow my user to use her Simply Accounting. ESET offers nothing useful and Simply Accounting's KB is no better.

There is a bulletin somewhere about making sure only Internet apps are set to be monitored for web traffic (apparently you can set any app to be monitored in this way) but this is done by default and therefore is no help.

If ESET has anything a bit more helpful than "disable network drive scanning" ( I do this anyway ), I would apprecaite hearing about it. I am starting to feel a bit nervous recommending ESET when I have so much trouble getting it to play nicely with such a common application.

Here are some questions that seem relevant:

1. Why can't the Web Access protection be managed by the ERA Console?
2. We can exclude files and folders from realtime and on-demand scanning - why not processes? (Other products allow this.)

 

Working at a CPA firm, I have seen this problem with other accounting apps/tax software and AV software. It can be very frustrating to troubleshoot.

AV's use file system drivers to scan all files created, read, executed, etc. and even if you exclude the files from scanning, the files are still read, executed, etc through the file driver, just not scanned. Issue seems to be with some databases anything other than the native Microsoft file system driver causes issues. AND/OR if the accounting app uses common web ports to communicate they get routed to the AV proxy's inside the machine and have the same problem.

After fighting this issue on numerous occasions and setups, I ended up in some instances finding the correct exclusion options to disable completely scanning of certain files, or had to disable the real-time file scanning all together, usually just on the server. If the host, be it a server or workstation is hardened properly you can minimize you reliance on AV, which you could argue should be done anyway, and just schedule weekly full scan or something to fill in the cracks.

 

Thanks, Spiral123, for taking the time to reply.

It's scary, in my opinion, that it could be necessary to disable RT scanning just to accommodate an application - dangerous, in fact. While we take whatever measures we can to harden the server, or reduce as much as possible its attack surface, RT AV scanning is a necessary measure as well.

I don't want to speculate on whether or not the issue is with a poorly designed database engine or a poorly designed RT scanning engine, but it would be nice if one or the other of the software manufacturers would step up and offer some useful assistance, rather than just point fingers at one another, as is so often the case.

Simply Accounting's Knowledge Base suggests uninstalling or disabling the ESET NOD32, as though that was a solution. I could uninstall the Simply Accounting instead, and the problem would also go away that way, but if other apps can play nicely with the NOD32, why not theirs?

A side note: I have several other clients running Simply 2009 on the same server OS: two of them run ESET NOD32 V2.7 and the other runs Symantec Corporate Edition V10.1 - they all work just fine.

C'mon ESET, help us out here!

 

16 months go by, and still nothing from ESET. Am I right in assumin gthat ESET doesn't bother to monitor these? (Sure looks like that!)

 

We'll need to get more information about the issue:
1, does the problem persist after installing EAV 4.0.474?
2, does the problem affect computers with any operating system, ie. Windows XP, Vista, Windows 7?
3, does the problem go away after disabling real-time protection or HTTP checking in the advanced setup?

 

1. Not is a postition yet to upgrade to V 4x. Was hoping to be able to use it as is until I'm satisfied that V 4 isn't worse, or troublesome in some other unrelated way. I don't just install a new version of a server program merely becasue it's made available - I like to mess with it off line first.

2. This user has only SBS 2003 and XP Pro systems.

3. It went away today when I disabled RT on the server (disabling it on the client made no difference). However, after re-enabling it on the server, the problem did not return. This doesn't tell us much, as the problem comes and goes anyway.

I wrote to this forum because I found a number of posts online from frustrated users who found that the only way to resolve this issue was to disable (or in some cases, completely uninstall) NOD32 from the server.

I tried some more exclusions on the server, and pushed out some more port and executable firewall exclusions as well. The client will go this way for a while and let me know if the problem returns.

I have other clients using NOD32 V3 and Simply, so I don't think think is necessarily a design issue with NOD32. However, between Simply and ESET, I had hoped that ESET would be at least willing to try to help. I don't expect any help from the Simply folks (they are indeed useless), but at least there's some stuff on their web site.

 

Why would you not update to the latest build of NOD32 ver 4? It's been out for some time and IMHO and experience it's a better version than 3.x I understand the concern we all have for installing the latest build of any software but Eset's ver 4.x software is mature enough at this point so you should have little concern. Be sure to uninstall ver 3 using the uninstall shortcut in the NOD32 Start Menu. Make sure you reboot if not prompted and then use your l/p to download and install version 4. You might be surprised to find these issues your experiencing were fixed some builds and one full version ago... OR perhaps .474 LOL No seriously though you should install 4.0.474 IMHO Do you not install Simply Accounting 200x each year? According to your logic you should still be using Simply Accounting 2002 or something...

To prevent further/future possible compatibility problems with Simply Accounting create an exclusion for it's root directory. *Also I would create an exclusion for it in the "Web access protection" in advanced setup tree.* Antivirus and antispyware-->Web access protection-->HTTP,HTTPS-->Web browsers If you don't find the Simply Accounting .exe listed use add button to point to it and create an entry. Also click the check box untill it's a RED X next to the Simply Accounting entry.

Solid-State

PS I can't remember if ver 3 has exclusion lists for "Web access protection" (NOD's HTTP/s proxy) as version 4 does. I believe Simply Accounting does some of it's server transactions/communications in a web like manor and Nod's HTTP protection/proxy is getting in the way. The exclusion should prevent it from messing with the HTTP traffic in anyway and it should be able to do it's HTTP communications to the DB no problem opening and closing it.

 

I see your logic, and figure the new version may indeed have advantages. However, it's always best to try it on a test bench first, even if it only provides you with a bit of experience in the deployment so you aren't learning on the client's dime.

Have they upgraded the ERA as well? If so, that's another piece that has to be learned.

Maybe I'll use my own NOD32 Bus. license to try it on my own SBS 2008 server - just to see how it all installs.

And yes, we do use the same logic with Simply Accounting. When a client asks if they should upgrade immediately, I always say no - wait until at least one update has been made. In fact, I recently read a bulletin from Simply regarding issues with their 2010 release. A month ago, they promised to fix a number of issues "some time in December". A lot of people were pulling their hair out struggling with the latest and greatest (because it came in the mail - we should install it right away!). Some used a poorly tested release for 2 months before Simply got around to fixing it.

Why would I recommend a new release of something without even seeing it first? (On the other hand, I don't always look at a new release until it's been out for quite a while, which is probably overkill.)

I apprecaite everybody's input, but also wish that ESET would weigh in on some of these discussions. While I do like the product and recommend it to all my clients, I can't say the support or the documentation is all that good.

 

I have NOD32 installed on XP clients and Server 2003 (not SBS) that used Simply 2009, and now Simply 2010.

The Database is served from the Server, and the backups happen to the user's local comptuer (to their My Docs folders), similar to what you're doing.

They've had no problems using it with NOD32 enabled (currently 4.0.467). I even did the 2009 to 2010 upgrades, without doing anything to NOD, and that worked without incident.

I had to perform several backups and restores the other day from DB's both in Simply backups local to the server, Simply backups from the users' backup folder, and off-site backups. Some restores done via Simply, and others by stopping the simply Server, putting restored/current DB files in place, and starting the service again. The whole time going back in and out of Simply 2010 looking for a missing piece of data.

Not once did I have a problems like you're describing. I only tell you all this, becuase I think that's about the most abuse one could do to the Simply DB's without destroying them.

If you have NOD32 running on the SBS server, ensure you follow the Eset KB article on suggested server config. Also check with MS for Server 2003 and SBS-specific exclusion suggestions (for all Anti-Virus packages) and apply them to the server NOD32 config.

That plus ensuring Network drive scanning is turned off on both ends is about the only things I did to that setup (that would affect Simply), and it's been working for a year or more with no complaints about Simply.

BTW the Simply DB problems they had turned out to be human error in the end.

Hope that gives you some help/hope.

 

Thanks for your reply, Techie007...

Firs tof all, I have a number of SBS 2003 networks around town, many of them using Simply. I am having these issues at onle site only.

Thanks for pointing out the article about server configuration - I had no idea it even existed and was not following some of the recomendations. Although I haven't yet upgraded this client to V 4, some of the recommendations still apply.

I'll mess with this a bit further and see what happens. Getting tired of calls every few days, and refuse to permanently disable AV software just becasue of a lack of support from Simply and/or ESET.

Thanks again for all your inputs. I'll have to gather all the information I have accumualted in this and keep it handy. Need to incorporate it all into each installation.

 

Let us know how it goes.