Linda B. wrote: We recently replaced Norton Antivirus 8.0 with McAfee 8.0 on all of our Windows 2000 workstations and we also have Novell ZENworks (the latest version installed). At one of our offices we have been experiencing problems with McAfee - when users try to launch an application through the Novell App Launcher the CPU usage goes up to 100%, and the culprit is naldesk.exe.
We installed the latest Novell Client, we cleared the nalcache we put naldesk.exe in the low risk group on McAfee, and we scanned for spyware/viruses on these computers, but nothing seems to help.
Once the users freeze they have to do a manual reboot. We did not have this problem when we were using Norton.
Do you know any way we can resolve this problem?
Anyone out there got some advice for Linda? Let us know.
You may want to try adding naldesk.exe to the Exclusion list for on access scans. This option can be found under the On-Access Scan properties --> Detection tab --> Exclusion button at the bottom of that page.
Make sure that you don't scan outgoing files and network path (scan only incoming files!) on the workstation with McAfee. Do you have Patch 10 for VirusScan 8.0i installed? You can try to exclude the path c:\nalcache.
When I try to reproduce your problem, I have only a short time 100% CPU usage from NALDESK.EXE when I scan outgoing and network path. But we use Mixed ZENworks 3.22 and ZENworks 4 without a ZENworks Agent.
I hope this helps.
If ALL your network PCs and Servers are protected by anti-viruses,
and your PCs are not the fastest ones (PIII or worse),
I would suggest you disable virus scanning on Read accesses (on slow PCs),
and only let the anti-virus hunt for viruses on Write accesses.
If I'm not wrong, the first operation a virus has to do to install
itself is to write to the disk.
So the first line of defense is to control Write access.
The Read access protection is the second line of defense,
AND the one which slow your PCs the most!
If you really want to know why your PCs are slow,
without disabling your anti-virus features,
you will have to use SysInternals FILEMON, REGMON and PROCEXP tools
to find the culprit.
Besides all that, IMHO, I find the new version 8.0 of McAfee too "fat",
in comparison to version 7.x. I will keep version 7.x active until our PCs
get replaced with faster ones.
We experienced similar problems with certain applications. These were mostly
JAVA based such as ConsoleOne. We discovered that the On-Access Scan was
scanning all scripts as the application launched.
We added the folders where the scripts are located to the exclusion
list and set it to not scan on Read. Now these applications launch quicker and
CPU usage remains normal.
We use VirusScan Enterprise 7.0 by McAfee, and it seems to do well. I'm not sure if this has anything to do with Linda's issue, but I was wondering how they have McAfee configured for updates. Since there are new DATs released daily, having all the workstations going to the net to grab those updates could be causing problems. We download the updates to a server, and have McAfee configured on the workstations to look to that internal server for updates, instead of going out to the internet.
We are running McAfee 8i (patch 11) on Windows 2000, and are not seeing that problem. The only Novell-related exclusion we have is the zfdinvscanner.exe (the zenworks inventory scanner- Mcafee was slowing it down quite a bit).
One quick test is to run this from the command line:
net stop mcshield
and then try opening the NAL window- just to make sure that it is Mcafee that is causing the problem.
You said you were on the latest version of the Novell Client, but what about the ZENworks Agent? I would update Mcafee to patch 11 and check on the ZENworks Agent version (we are on 184.108.40.206204).
We have McAfee Enterprise Ed Ver 7.10 for workstations
McAfee for NetWare ver 4.62
We have one (1) server go out to McAfee every hour.
We then have all the other servers staggered by 5-minute intervals to look at "our" McAfee server that received the updates/DAT files.
We have one workstation configured to look every hour at our McAfee server and ftp down the patch/DAT file and place it on our ZENworks Server. And then we use the ZENworks workstation scheduler (not user) to randomly distribute the data files every two (2) hours.
The reason we have two separate calls to McAfee is that the NetWare patch/dat files are a little different in their packaging than the Windows files from McAfee. All other workstations are disabled from going out to auto update from McAfee. This helps reduce network traffic and also we have found that if a machine does get infected with a virus that disables McAfee then it never gets updated. By using ZENworks to push out the updates we know that they are getting the McAfee updates unless the user turns off the ZENworks workstation scheduler, which most cannot do.
In response to Michel Py, I'd like to strongly advise against turning off
scanning on read access with any virus scanner. While in many cases you're
correct in saying a virus will generally first be downloaded or copied onto
the local machine, this is not always the case. The best example of where
this does not occur is with USB memory sticks. If you turn scanning on read
access off, any virus on a USB memory stick (which is an untrusted medium
that has probably hopped between numerous unprotected machines before yours)
will execute on your machines without VirusScan raising an eyebrow.
Likewise, if a virus is copied onto a machine while VirusScan is disabled,
or when the virus definitions are out of date, the infection may not be
picked up in the future unless a full scan is done.
In actuality, it is scanning on write access that is optional, while
scanning on read access should always be turned on. With scanning on write
turned off, a virus may not be detected the instant it is downloaded or
copied onto your machine, but it will be detected the instant anything tries
to read it, preventing it from being executed. In most cases simply opening
the containing folder or clicking on the file will cause it to be detected,
as explorer opens many files to read additional information from them, such
as checking for icons in executables. Trying to copy an infected file from a
protected machine will also trigger the scan, preventing infected files from
being passed around on protected machines, even if a file isn't necessarily
detected the instant it is downloaded.
It is also worth noting that if you have scanning on network drives turned
off, infected files on remote shares and the like can be executed without
obstruction. If performance is a concern when it comes to specific network
drives, it might be best to set exclusions to prevent scanning of trusted
network drives, while leaving scanning of all other network drives on. I'd
recommend anyone setting virus scanning policies for a corporate environment
use the eicar test string to verify the effectiveness of their settings.
It would also be good to exclude c:\nalcache from being scanned.
We did see an issue that had similar characteristics in our environment and it did appear that McAfee was the culprit. After extensive hair pulling, it turned out it wasn't related to McAfee, but the Lotus Notes client (specifically the R6 release levels) and the version of the ZENworks SP applied to the Novell server.
We were at ZENworks 3.2 without any SP installed on the server. As a process we went to ZfD SP-3 on the servers, Novell Client 4.90 SP-2 with PSP-D, and Lotus Notes 6.5.4 to resolve our issue.
Also, since you referenced this is just happening at one of your locations, ensure your ZENworks server at that location has the proper patches applied.
Not sure if it's related, but figured I'd pass it along just in case it helps you retain your hair line!
As long-time users of Mcafee, we have seen that script blocking has been a problem with v 8.0 or better.
Turn it off and try again...
Yes, use the latest patch on Mcafee and exclusion of files as mentioned by others in this article.
However, if we know through testing that installing this application will pound the workstation with McAfee Activity, we will run a pre-distribution script to turn off McAfee components in the application object itself... or Application Dependency object.
"Distribution Options | Distributions Scripts | Run before Distribution"
net stop "McAfee Framework Service" (- if you have the ePO services)
net stop "Network Associates McShield"
net stop "Network Associates Task Manager"
(Don't forget the script engine)
And then start them again with the "Run Options | Launch Script | Run after Termination" if the application doesn't require a reboot.
net start "McAfee Framework Service"
net start "Network Associates McShield"
net start "Network Associates Task Manager"
Henry C. Hernandez
I think that I may have an answer for you. Try excluding all .cab files from being scanned. I've noticed that McAfee peaks the processor when scanning these types of files. Now keep in mind, this may open up some level of exposure if a virus attacks the .cab files. However, a properly configured "On Access Scanner" should stop that from happening.
Stephen E. Goss
Sounds like McAfee is working constantly by scanning files. You can change what direction your virus scanner scans "writing to disk" and "reading from disk."
I take it that you are using Enterprise ver.8. Go to the "On-Access Scanner" properties and go to "All Processes and then go to the "Detection" tab and deselect when reading from disk and make sure that "On network drives is deselected also.
If you are using ePolicy to manage the AV software, you can change it so everybody gets the new settings. If it still has high CPU usage, then you have some software conflict that needs to be checked into. First step is to do a clean image load or install and without Norton AV even being installed and install McAfee AV and see if you still have the problems with high CPU Usage. - Good Luck!
We had the same problem here after the installation of McAfee 8.0i, but not with all applications. Turned out to be the scanning of "archive" files like .chm, .jar and .zip that stalled the installation process. By Unselecting in Mcconsole the option to scan archive files the applications were distributed nicely without McAfee utilizing 99% of the processor capacity.
You'll need to exclude the naldesk.exe in McAfee.
In the past we had a problem like yours. Try this:
In the registry on the client PC, add:
No value is actually needed when you create this key, it just must be present. This registry key will not affect the way applications are executed or force run.
It will only work with ZENworks IR5 or later.
McAfee by default sets the "System Utilization during scanning" value to
100% in the properties of the client.
This value is easy to locate in the properties.
Norton\Symantec antivirus clients are set to zero % (called low) by default.
This value is a little tricky to find in Symantec. It is a Throttling option
under the advanced properties when a scheduled client scan is created.
This is could be the cause, hope it helps.
A lot of advice is to exclude certain files or file types from being
scanned. We refuse to let archive files and *.exe files (of any program) go
unscanned as this can become a cesspool of trouble. With McAfee version
7.x, we found that a simple reinstall fixed the problem. Then we recently
went to version 8.0i. The machines that we fixed by reinstalling, did not
get the problem listed.
I realize that reinstalling is not considered a fix by many, but then
excluding file types from being scanned is not a fix either. A reinstall
does fix the problem, excluding only hides the problem and opens avenues of
infection. For us, we choose security.
Thank you for this opportunity to see other solutions to similar problems.
I have found that on occasion McAfee will behave like this if it cannot
properly scan a file. It will sit there in a loop trying to scan the
same file every second or so and choke.
The first thing i would do is look at the log file by going to the virus
scan console --> then on-access scanner --> then reports and click on
Look for any file it is continuously scanning, verify you know what it
is trying to scan, and if it is known exclude the file/directory through
ePolicy Orchestrator. and see if that does that trick.
Hope that helps you out.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.