ePo v2.5 - shedloads of headaches

[AuntieEPO]

OK, here we go

Were running ePo 2.5 on a Win2k server.

Now then, the main problem is simply that the enforcement of policies seems completely random and inconsistent.

An example,

we have 2 XP machines, both of which HAD version 4.5 of VScan. Now, straight from the kick off there was no policy for any version of virus scan available in the policies pane for each of these computers. We successfully installed the agent however.

Meaning any polices we tried to enforce were not picked up by these machines.

We added them to a seperate site of thier own.

After much searching through the NAI support we discovered that 4.5.1 sp1 was required for XP management via ePo. Fair enough, we downloaded 4.5.1 sp1 , added it to the repository and applied it to both machines via a force install policy.....NOTHING HAPPENED. STILL no policy available in the details pane.

We repeated the above after manually removing Vscan from both machines. STILL unable to apply an install of both 4.5 and 4.5.1.

So we installed 4.5.1 sp1 manually on one of the machines, and 4.5 manually on another, sent the agent no problems as usual, STILL no policy available to each machine. The agent has determined that the machine has VScan (looking in the properties tab confims this) but there is NO POLICY available in the policy tab ---WHY!!!!!

Inevitably we are therefore uable to apply any policies to either machine - we tried to force an uninstall of 4.5 from the machine we manually loaded with 4.5 and then force an install of 4.5.1 on it. The agent simply does not pick up policies for Vscan for either machine.

We were under the illusion that this was an XP problem only, and then low and behold it begins to affect an NT machine running 4.5. This time, whilst being able to configure a policy for this machine, the policy simply was not being enforced for Vscan, again, the agent simply was not picking any Vscan policies up..WE ARE UNABLE TO UNINSTALL Vscan from this machine via ePo.

Curently we have deleted all agent and Vscan software from both XP machines and are unable to install agents on these machines.

we are also unable to run scheduled tasks on most machines, as I have described in my post in the previous thread (epo tasks).

BRING BACK MCON!

 

[AVChap]

Might be a corrupted ePO installation. Would be better if you can re-install the ePO server and check the installation logs for any problems. You don't have to re-deploy the agents. Also, check if you have the latest version/patches for ePO. Latest is version 2.5.1.

Check out the FAQ in this forum if that's not helpful.

AVChap

 

[AuntieEPO]

It appears that your advice has been spot on. Thanks.

I find it quite unbelieveable that this was the cause of the problems, and when I read your post in reply I was very sceptical, but went along with it nonetheless, now virtually all of the problems I was experiencing have disappeared, with the slight excpetion of scheduling tasks which sometimes still fail to run.

Is the fact that - at least in some cases - eP0 will not function correctly unless it has been service packed a known issue ?

Surely if it is, then it is the responsibilty of McAfee to package epO together with its service pack. I find it quite pathetic that epO v2.5 doesnt actually work unless it has been upgraded to v 2.5.1.....

 

[AVChap]

Actually, ePO 2.5 will run just fine without SP1. Most of the changes in SP1 deal with the use of ThreatScan (another product which uses ePO) and some minor hotfixes. Although it would be better if it were installed so as to minimize minor complications. The readme file has a list of the fixes included.

Hope this helps.

AVChap

 

[AuntieEPO]

Yeah ta

At present everything is working well so im happy.

Here's one for you though...

One of the NT4 Workstation machines we have has just been introduced to EpO, it already had Vscan 4.5 on it, and after sending the agent to it we applied policies to uninstall 4.5 and install 4.5.1 sp1 which worked fine. The properties pane for this machine shows 4.5.1.

However, if we run a report on "all AV installations" this machine comes up twice, as having an installation of 4.5.1 AND of 4.5 !?

Any ideas? You cannot actually see the phantom 4.5 in add/ remove programs, yet there is a directory on the C:\ drive. Should I just delete this directory?

The user of this machine also gets a vshwin32.exe application error every time he starts up his machine - something to do with the two intsallations I presume? Nothing actually appears in the event log to identify this error....

 

[AVChap]

What do you mean there's a directory in C:\? Was 4.5 installed on a non-default directory? If so, check the task manager if this is still being invoked. If not, best to just move the files and see if the problem with VSHWIN32.EXE goes away.

As for the ePO double entry, I believe this has been reported to NAI and they're doing something, probably a hotfix. Check with your sales person on this.

Hope this helps.

AVChap

 

[AuntieEPO]

As we thought, on a number of NT machines there is now a C:\program files\....\Virusscan directory, which we assumed was the default and is the one which holds 4.5.1, aswell as a C:\program files\....\VirusScan NT directory which holds 4.5.0.

However, there is one curious case where, 4.5.1 is in the Virusscan NT directory, and 4.5.0 is in the VirusScan directory...whats happened there i dont know.

All of these cases are on NT4 machines, there are no such problems on XP/2000 machines.

All machines are manageable through EpO, and only the one machine seems to experience the application error...which suggests the cause is not the dual installation ?

 

[AuntieEPO]

Any ideas where I can find the cause/solution to the application error, we are now experiencing the error on two NT machines.

Ive checked the NAI.COM support, and a similar error with virus scan help was described, and the solution was unknown.

The error is a vshwin32.exe application error stating "The instruction at 0x00402000 referenced memory at 0x00000000. The memory could not be read."

This happens every time the machine boots up.

 

[AuntieEPO]

More seriously,

we are now experiencing update problems.

Nothing really to do with ePo, as the tasks are running properly. The fact is that, on a number of NT machines, the DAT update only goes as far as 4196/10th Apr, each time an update is run we then get told that this DAT file is the latest available version...clearly it isnt.

Further investigation revealed that, the directory which our clients point to for updates includes both a "delta.ini" file and an "update.ini" file.

Now then, the delta ini file is up to date, stating DAT version 4212/15th Jul as the current one. HOWEVER, the update ini file is referencing 4196 as the most recent DAT file.

We moved the out of date update ini file an no machine was able to do an attempted update as this file was missing, so it appears every client requires this file in order to do DAT updates. The weird thing is that, all of our XP and 2000 machines, along with two NT machines, update sucessfully to 4212 - EVEN THOUGH THE UPDATE INI FILE IS OUT OF DATE - but the rest of our NT machines do not update and get stuck on 4196.

ANY IDEAS AT ALL???!!!

The way we recieve DAT updates is our Internet server downloads the updates from the NAI ftp site, and a copy is placed in a shared directory to which all of our clients point.

Ive looked on the NAI ftp site and discovered that there is in fact an update ini file which makes refernce to 4212. This means that, basically our server goes to the NAI site and downloads the correct dat files etc, along with an updated delta ini file each time there is a new one available (every week) yet it is not downloading an updated update ini file and hasnt done since april 10th.

How does this work? when the server connects to the NAI site, how does it know what to download and why does it not get the update ini file - and how do we make sure it WILL download the new update ini file each week ?!!

Keeping you busy with all our problems arent we !

Cheers for any help.....

 

[AVDude]

Hi

Are you using NetShield to pull down the new dats?

Cheers
AVDude

 

[AuntieEPO]

How do you mean?

Our internet server is running netshield 4.5, we've scheduled the autoupdate task from within the netshield console to conect to ftp:\nai.com\...

its an n4 server

 

[AVChap]

In order for you to download UPDATE.INI using NetShield, you'd have to install a hotfix (HF 14 I believe). You can get this from Technical Support.

Now another option is to use the Mirror Task in VS 4.51. This will create a mirror of the NAI FTP site to ANY folder on your network. You may need to do some housecleaning every few weeks but this makes sure you have the latest UPDATE.INI file for VS to use during updates.

Hope this helps.

AVChap

 

[AVDude]

AVChap is right, thats why I asked.

Another way to do it is to create a small bat file to pull down everything from the NAI ftp.
In this bat file you could include a delete option on all files in the share, so you dont need to do any housecleaning every few weeks.

I have a few examlpes if you need any help with it.

Cheers
AVDude

 

[AuntieEPO]

Cheers for all your advice guys.

Updating works fine now since i manually donloaded a recent update ini file to our network share. We recently had a server die and as a result many users were a few weeks out of date in terms of DAT, so I think this is the reason they had difficulties updating.

Have you any idea where i can find out the cause/solution to the vshwin32.exe error i described in an earlier post?

one machine contiually gets this error at logon, but there is nothing in the event log or on the mcafee website so were pretty clueless as to whats happening.

Cheers again.

 

[Zelk]

Check the C:\EPOAgent\AgentDB\Event dir for lingering .evt files. Look for NAIFFFF.evt especially.If so down load filemon from Systernals.com

http://www.systernals.com/ntw2k/source/filemon.shtml.

Run the filemon while vshwin32.exe is hanging. If the report shows a continual unable to open NAIFFFF.evt the problem stems from ePo alerts. Go to the ePo server-- reports--Alerts. You can select do not filter alerts or at least uncheck alerts for starting and stopping of services.

 

[Zelk]

UPDATE!!!
For the vshwin32 using 99% of the CPU(this can also make the McAfee Splash Screen hang)Do your selfes a favor here. This is caused by a bug that there is no fix for! There is a work around and it is very simple. It is caused by alerting in ePO. Log into the ePO database as admin (or you wont see the tabs). Where you see report queries and alerts click on alerts. The default install selects a boat load of filters. Simply select do not filter. You will be hearing more about this from your ESAM. The actual fix may not be out until ePO 3!!
The problem is very difficult to troubleshoot and almost un-reproducable. It can apear about 15 time a day on a 5000 node network.

 

[Guest_imported]

AVDude, I am having problems with automatically downloading the update.ini file.

Do you think you can give me a hand with the .bat file you were talking about?

 

[AVChap]

Try this script/batch file:

lcd \update
open ftp.nai.com
anonymous
customer@acme.com
cd /virusdefs/4.x
binary
mget *
bye

Using this, all the files in the directory are copied.

HTH.

AVChap

 

[AVDude]

Hi

Here's the one I use

Create a bat file called xftp.bat with the following content

md c:\datupd
c:
cd \datupd
ftp -s:c:\datupd\datupd.ftp ftp.nai.com

Make the bat file call on the file called datupd.ftp with the following content

anonymous
download@customer.com
cd pub
cd antivirus
cd datfiles
cd 4.x
hash
bin
promt
mget *.upd
mget *.ini
mget *.zip
mget *.exe
close

If you need any other files like .tar just add in another mget.



Cheers
AVDude

 

[Guest_imported]

Just wondering AVChap/Dude, where can I get the hotfix for Netshield cos we have the same problem with Netshield downloading only delta.ini and not update.ini

Any help would be appreciated.
Cheers
Feng