Considering changing to Eset for our clients

I'm currently using Symantec Corporate Edition at all our client sites...approximately 14 or so servers, mostly 2003, some 2000 and around 175 workstations (all XP Pro). Most are running domains/AD, but some are not. I'm close to switching everyone over to Eset, but am starting to get cold feet. Some questions...

The bulk of the servers are running in Terminal Server mode, but most users are local to their server. There are fewer remote users, but their unhindered use of the server is important. Are there any known issues with NOD32 and TS/RDP?

The updating of the client configuration appears to be more tedious than CE and I want to make sure I understand what I'm supposed to be doing. I basically create a XML configuration file using the configuration editor and then this is sent to the workstations using a Task. Correct? Does this always work? My first attempt at changing a simple setting did not show up at the workstation even though the task shows that it finished and the contents of the created XML file looked OK to me.

I'm not seeing a one-to-one match up between what the console shows for a particular workstation's configuration and what I see at the workstation. The structure of all the setting options appears different between the workstation and the RA console so I'm not sure if I'm looking at the right thing or if there's something wrong/broken. For example, at the workstation's advanced settings, Tools, ThreatSense.Net, Advanced setup button, I added a "TPS" file extension to the exclusion filter. When I look at that workstation's configuration via the RA console, I don't see the extension I added.

Does the client's updating from a mirror on the server require manipulating the workstation's settings manually or can this occur automagically during the push install/setup of the client?

--David

 

To answer one of your questions:

If you already have NOD32 installed on your workstations prior to creating a setup package, you will need to point your local workstations to the correct server via the Remote Administration Settings.

If not, you can set all this up when creating the install package, so when you push the install to your workstations, they will already have the mirror information saved and you don't have to do anything else.

I would read through this thread: https://www.wilderssecurity.com/showthread.php?t=138526

It will show you the basics of how all this is done and might answer some of your questions.

HTH

 

In this case, the clients will not have eset already on them so I should be able to include the mirror information during their install.

I started to wade through the tutorial, but it appeared to be for an older version...I don't have a separate mirror program to install and various windows in the products have changed significantly.

 

Yes, you can include the mirror information in the configuration file used for the install.

The basic concept is the same for even the newer versions. If you are looking through version 3, all the settings for this will be under the Setup| Advanced Setup area.
If you purchased the business edition licenses for your network, you will have the option to download the mirrored version to install.
Then, you install the mirrored version of NOD32 on a server or workstation and make sure all other clients are pointed at that.

 

Eset has given me a 30-day 5-machine license for evaluation. I was not given a link to download a msi for a separate mirror program.

I am working through getting the install package configuration like I would want it and am not yet convinced that everything is showing up properly in the client.

In my last test, the install package configuration had 3 entries for exclusion. That tree looks like: Eset SS, Eset NOD32 AV-> Eset Kernel-> Set up-> Exclusions-> my 3 entries.

There is not a similar options tree at the client, I -assume- its the Antivirus and antispyware-> Exclusions, but this is empty. I think the ThreatSense.net exclusion in the package configuration did show up at the client...assuming it wasn't left over after uninstalling my previous tests.

So I'm not yet sure if I'm looking at a bug, with possibly more to come or just don't know what I'm doing or where to look...

--David

 

Hi,

We are/were in a similar situation. Overall our experience had been positive, although not without hickups.

We have about 10 Windows 2003 Std SP1 servers running as Terminal servers a few 2000 boxes (DCs) and 99.9% XP Pro SP2's. As of today we have about 25 win2003 servers & about 125 xp pro clients working on nod32 v3.0

So far best way we found it to implement NOD32 3.0 was to follow this plan:

Remove previous AV client & agent etc... (we were using McAfee ePO 3.6.x)
- tested & used WORKING script using psexec (sysinternals); locate the HKLM\Software\Windows\Currentversion\Uninstall\<AV product> line and copy & paste it as a local admin on a test workstation see if it works. Our script ran pulled that line from the registry and uninstalled then rebooted the local workstations. (Pushed out from a domain admin account to selected wks first.)

Install NOD32 2.0.107 (latest as of 6/29/0 Remote Admin server then console on a Win2003 server.

Download NOD32 v3.0.667 (do NOT install anything prior to that version - you'll have LOTS of hanged file servers!)

Install NO32 on a workstation & on a server. Open the product and configure it with all the base settings - filters scanners, scheduled tasks etc... Make sure you set the Display to "Advanced Mode" Then EXPORT the settings into an XML file.

The number one complaint that we have is that the configuration editor is nothing more than a glorified XML file editor... i.e. it has NO understanding that if you disable the Realtime file scanner you shouldn't be able to edit settings underneath it...

Important that on servers you follow the settings that they point out to you in the KB articles - disable network drive scanning & set Protocol filtering to Applications marked as Internet browsers or email clients etc...

Typical client install

Remove old AV product
Reboot
Clean up temp folders/references in the admin profile for the old product/registry entries HKLM /folders C:\Program Files\xyz etc... - Important since NOD32 may not install with these left around...

Install nod32 - use either RAS console to push a 'clean' app out or do it manually on the workstations. Servers I do by hand... (specially terminal servers.)

On either the RAS console you can select (or group) the workstation and push a configuration (xml) file out - OR import the XML file on the client manually.

The point is that unless you really have to stay away from the Configuration editor...

My opinion of NOD32 is: you pay & get a great anti virus/spyware app. If you want a great management interface & reporting tools etc... buy mcafee/CA or Symantec - and watch the viruses jump around...

David

 

Thanks! Exactly what I needed to know....

--David

 

I would say that start with taking all the defaults - certainly feel free to add a password to the configuration on clients- but don't change many of the scanning options - except for POP3/Outlook add ins etc.. as needed.

Thats kind of been the lesson for us.

 

Some of the pushed setting changes appear to not be reflected at the client until after a reboot. I'm uncertain if the change occurs prior to the reboot, but I believe that it does. Just the GUI doesn't reflect the change.

We moved from CA eTrust 8 (had been with them since Inoculan 4) to Nod32 2.5 and have been pleased. CA had a much better admin GUI, but then again I needed to be CA's admin often. Except for at version upgrade time, I'm never in the Nod32 admin. Unlike CA, Nod just works. Going from version 2.7 to 3.x has been a learning curve. But that's true with any major upgrade of 500+ machines. Overall we are pleased with version 3.0.677.