Endpoint Protection

Immediately after I upgraded our Corp Ed server from v7.5 to v10.0.0.359 clients randomly started to miss their virus definition updates. I've crawled through all the support pages and run numerous tests without coming to any conclusive solution. So, I'm hoping for some helpful hints from the forum. Here is what I've got:

(1) Win 2k w/ SAV Corp Ed v 10.0.0.359
(43) XP SP2 clients w/ Corp Ed v10.0.0.359
(67) XP SP2 clients w/ Corp Ed 9.0.0.338
(6) XP SP2 clients w/ Corp Ed 8.0.0.9374

The server has the latest definitions, 5/5/09 rev3.
(2) v10 clients have it too
(3) v9 clients have it too
(3) v8 clients have it too

Other clients have a mix of definitions. But the most troubling part is that ---
(19) v10 clients
(32) v9 clients
(0) v8 clients
... are more than 30 days overdue

All clients communicate with the Server, without fail. So blocked TCP or UDP ports are not the cause.
The SAV client software works, I've checked a handful of computers personally.
All clients have nearly identical software on them from the image we use for workstations.

Clients are spread across multiple remote sites, some are updating fine while others (in the very same room) are not.

I tried to upgrade one client with the Symantec System Center ClientRemote Install. It upgraded the software from v9 to v10 but broke the Outlook plug-in on that workstation and still has not updated the definition file. With such a poor result I hesitate to try this on another workstation.

I've been tinkering with another client, in a virtual machine, that is more than 5 months overdue for definitions and running SAV v9. Try as I might I cannot get this test machine to properly update its virus definitions from the server. All diagnostic tests come back successful. I try to force the definition to be downloaded to the client but it doesn't take. Instead I see an error that the definition file is corrupt.

After following the instructions for a manual repair ...
http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2002102209110448?Open&docid=2002080708594148&nsf=ent-security.nsf&view=854fa02b4f5013678825731a007d06af
... my test machine now has the proper virus definitions. But I dread doing this process on 50+ workstations, one-at-a-time.

So, given that all client workstations are identical, what would cause some machines to be able to download and process the updates while others cannot?

Jason
 

Well maybe your main server has a bad definition that is getting pushed out. There is a process to clean a bad definition for the main server, but you have to call in to make a case and our tech help can get you through that. Another question from me though is when did you upgrade your main server to v10.0.0.359. Was this a while ago? You are talking about clients that are 5+ months out of date. So did the bad defs only start happening after the upgrade or were outdated before the upgrade?

Hi Grant,

Thank you for the follow up. The clients which are 5+ months out of date have a fresh install of v10 on them within the last few months. So clearly they just have the defs that came with the original software and have never updated with the server. So part of the problem is that I might be barking up the wrong tree.

I've been poking at the problem more and have settled on a potential solution. Here are the steps I've taken on two test machines with successful results:

=============

Add new GRC.DAT
 - copied from \\servername\VPHOME

Add Cert (for v10 clients only)
 - copied from \\servername\VPHOME\pki\roots

Turn off Simple File Sharing
 - via Tools menu in Explorer, Folder Options -> View -> uncheck Simple File Sharing

Turn on exceptions for File and Print sharing in XP Firewall
 - Open XP Firewall, Exceptions tab, check File and Printer Sharing

Add holes for SAV to XP firewall
 - Used these three command line options to open up UDP and TCP ports so as to cover all versions of SAV
netsh firewall set portopening protocol=tcp port=2967 mode=enable name=SAVtcp2967 scope=custom addresses=10.1.1.1/255.255.255.255
netsh firewall set portopening protocol=udp port=2967 mode=enable name=SAVudp2967 scope=custom addresses=10.1.1.1/255.255.255.255
netsh firewall set portopening protocol=udp port=2968 mode=enable name=SAVudp2968 scope=custom addresses=10.1.1.1/255.255.255.255

=============

After following each of those steps I reboot the workstation. After it comes back up I force a virus def update from the parent server's SSC console. Then all appears good.

Now here's one final problem... the clients are not pulling the virus def from the parent server. Instead they're heading out to Symantec for the def. Is this because the parent's LiveUpdate is configured pull the latest def from Symantec? How can I make the client pull the virus def from the parent?

Thanks,
Jason

On the Symantec System Center Console
Click on the server group where the clients get the updates. Check the Liveupdate settings there.

Their are two reasons for the old virus definitions.
1. the clients is unable to communicate with the server to get the update using port 2967.
To check the communication please follow the steps.
* On the server machine.
- open command prompt
- type telnet <client name> 2967 and press enter.
- it should open a blank command prompt window.
- if it is not working you need to open the port 2967 on the server or firewall or client
* On the client machine.
- open command prompt
- type telnet <server name> 2967 and press enter.
- it should open a blank command prompt window.
- if it is not working you need to open the port 2967 on the server or firewall or client.
- click on start and run.
- compare the root certificate on the server(\\<server>\vphome\pki\roots) and the cline(c:\program files\Symantec Antivirus\pki\roots.

2. The old virus definition is corrupted.
- stop symantec antivirus services.
- stop symantec antivirus Definition watcher.
- delete old virus defs(yyyymmdd.xxx) from "C:\Program Files\Common Files\Symantec Shared\VirusDefs"
- empty "C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads" folder
- delete all <number>.product.inventory and <number>.setting files from "C:\Documents and Settings\All
Users\Application Data\Symantec\LiveUpdate" folder.
- empty "C:\Documents and Settings\All Users\Application Data\Symantec\Symantec AntiVirus Corporate
Edition\7.5\I2_LDVP.VDB" folder.
- go to "C:\Documents and Settings\All Users\Application Data\Symantec\Symantec AntiVirus Corporate Edition\7.5\ delete *.vdb or *.xdb files not folders.
- start the symantec service.
- start the symantec antivirus definition watcher.
- run a liveupdate..

Just to clarify my testing environment in the hopes it will result in a suitable solution, I am using SAV Corp Ed v9 on the client and v10 on the server.

I tried the recommendations by SameerU:
I cannot use telnet to test the client as v9 uses UDP communications, not TCP.
Deleting all the files, as directed above, results in SAV not starting properly and throwing errors into the log file.

I checked the settings suggested by mon_rarilo:
My server group gets its updates from the Symantec Liveupdate Server.
The clients controlled by the primary server are set to get their updates from the parent.

The most recent result of my testing is the client will not pick up the definition updates from the parent. It will also not update by itself as I had previously seen in a different round of testing using the same methods. The inconsistency is baffling. I can reset the virtual machine to a snapshot and run the same test steps but get different results each time. Most frustrating.

At this point I have a group policy that forces the XP Firewall settings and a script that copies the GRC.DAT and certificate from the server to the client. The GRC.DAT is processed and removed from the folder. The certificate doesn't affect my test environment because I'm using v9 of the client software which does not use a secure certificate at all. With the group policy and script I'm able to get the client configured properly but the live update doesn't happen. When I force the live update from the server onto the client, the client immediately starts the live update process but goes to the Symantec Server and not the parent server as indicated in the settings in the SSC.

I'll continue testing but more recommendations could help alleviate the stress over here.

Thanks,
Jason