Novell Home

Distributing McAfee Updates

Novell Cool Solutions: Trench

Digg This - Slashdot This

Posted: 8 Jul 2003
 

Virus ProtectionThe problem of how best to provide McAfee Virus Scan updates to users is a constant concern to a large percentage of our readers. ZENworks for Desktops provides some powerful tools that system administrators can use in a variety of ways to fight off new viruses as soon as the antidote is available, and it's flat-out astonishing how creative you guys can get in attacking this problem.

As with anything else you read on this site, if you've got something to add, we want to hear about it.

For more information on NAI's McAfee virus protection, check out this site.

If you'd like to see solutions for other Virus Protection products, see this article.



Tips Published Previously

More Ideas

Ideas involving ZENworks for Servers

Q&A About this Article



Rick Hellewell's Ideas

Virus ProtectionOK, I read the McAfee tip #5. The tip is similar to how I do it, but mine works network-wide (at least on my part of the tree), on the servers and workstations. And once it is set up, I don't have to mess with it!

Assumptions:

  • McAFee Netshield running on all servers
  • McAfee Virus Scan on all workstations

Steps:

  1. Set up one server running Netshield (SERVER1) as your "McAfee DAT file master" by configuring it to receive FTP updates from the FTP.NAI.COM site once an hour (mine is set for hourly at 11 minutes past the hour). This is done through the NetShield console.
  2. Set up the other servers running Netshield to check for updates only from SERVER1 once an hour (such as setting SERVER2, SERVER2, SERVER3 at 22, 33, 44 minutes past the hour respectively).
  3. Set up an ZEN Application object for all workstations/users (either one will work) that always copies the DAT files from SERVER1's DAT file directory (default is SYS:\MCAFEE\NETWORK ASSOCIATES\NETSHIELD directory) onto the user/workstations directory (default is C:\PROGRAM FILES\NETWORK ASSOCIATES\VIRUSSCAN, I believe). Force this application object to run every time the user logs in. In the files section of the object, each file is set to 'copy always'.

Here's what happens:

  1. McAfee puts an update on their FTP site at 1300 hours
  2. At 13:11, SERVER1 checks the FTP site for an update, finds it, downloads it, and installs it. SERVER1 is updated. (If there is no update, then SERVER1 continues on merrily.)
  3. At 13:33, SERVER2 checks with SERVER1, finds an update, transfers a copy, installs it. SERVER2 is now up-to-date. (No update? Fine, SERVER2 will check back again the next hour.)
  4. Step #3 repeats for the other servers

In the meantime, a user logs in at a workstation at 13:44 (or even the next day). ZEN will run the DAT Update application I set up above, and copies the latest DAT files from SERVER1 (which always has the latest) to the workstation. Voila, the workstation is updated.

With this method, the servers are updated within an hour of the release of the DAT update (even in the middle of the night), the workstations are updated at their next login (usually daily, or even more often).

I go a step further. I also have ZEN application object copy the VSH file (contains the VirusScan settings) from a secure location on the network (only network admins have rights to this location). This file contains all the default settings I want the workstations to have. That way, the user can't permanently disable/change their VirusScan settings. I even password-protect the master VSH file so the user can't change the settings. (I create the settings on my workstation, then copy the VSH file to the secure location.)

My users and the servers are protected from viruses. Automatically. I don't have to do a thing to ensure that the latest DAT files are on my part of the network. Works great!

Another Idea from Rick Posted May 24, 2000

Here's another idea using the SDATxxxx.ExE files, along with some additional switches info.

Two parts to this one:

  1. Add this command to your login script

    SET LOGINNAME="%LOGIN_NAME%"

    Make sure there are no spaces on either side of the "=" sign. You can use any system parameter you like, although LOGIN_NAME (8 char user name) works just fine.

  2. Create an application object that points to the location of your SDATxxxx.EXE file. Set the Command Line Parameters to

    /s /logfile .\"%LOGINNAME%".LOG

    These switches are

    • /s = silent mode, nothing on screen, no user prompts
    • /logfile = name of the log file (the double-quote characters are necessary if you use a parameter like FULL_NAME, which will give you a "Fred Smith" value).

The LOGFILE parameter is important: I've noticed that in a large network, some users may lock up on this application because the several instances of the SDAT program are trying to update the LOG file at the same time. One or more workstations may lock up if this happens. Using the /logfile parameter will use file called "Fred Smith.log", which will be unique for each user, so you don't get the potential for a lockup. And the bonus is that you will know who has installed the update (and when).

When new SDAT's are released, just copy the new one into your distribution directory. And if you rename the new SDATxxxx.EXE (the 'xxxx' is for the revision level of the DAT files) to something like DATUP.EXE, you won't have to keep changing the Application Object.

One advantage of using SDAT is that it will only update the workstation if it's needed. If the workstation is already current, no files need to be copied (useful for remote sites).

I also use another similar application object to distribute the "EXTRA.DAT" files (also an SDAT kind of file) that pop up between the weekly DAT updates.

Enjoy your site!

If you have any questions you may contact Rick where he is good-naturedly sweating in 102-degree heat at rhellewell@cityofsacramento.org

Casper Pedersen's Idea

Virus ProtectionNow I've seen some different suggestions on how to update all the PC's in a network with new Virus Def. files (DAT'S), when they are using NAI.

I have found out that the easiest way to do it is to use the copy option in NAI's; copy the DAT-*.ZIP to a location on a fileserver.

In the VirusScan console select the "Automatic DAT update" and in the "Select Transfer Mode" select "Copy from...". In the "Select a Computer and directory" type \\SERVER\PATH - it should work if the loggedin user have [RF] to the location where the update files are located.

This is a much more easy way to update the PC's.

If you have questions you may contact Casper at cp@kck.dk

Dean Jorges' Idea

Virus ProtectionKudos also to Dean's compadres, Gary Klaiss and Jeff McCaslin, who helped him pull this off on 2200 workstations.

About updating McAfee 4.0.x to 4.5 with ZENworks. The trick is getting Vshinit.vxd and Vsheild.vxd removed before your snAppShot installs the new version (4.5).

  • Shoot a snAppShot of a complete un-install of McAfee 4.0.x.
  • Then shoot a snAppShot of a completely fresh install of 4.5, making sure you have a web browser installed before the 4.5 installation.
  • Next force run both apps and run once, order the icons Uninstall=2 and the install=1. Force them both to reboot always.
  • Make a system requirement on the install, applications, browse to the uninstall application, select it with the Application is Installed option.

    Whoever is associated with this will login. Install is set to run first, but since uninstall hasn't run, install won't run because of the requirements we set. Then uninstall is set to run second, it will install itself and reboot. Now when they login install will force run and reboot. They will log back in with an updated McAfee to 4.5... Bang!

    ZENworks is most my life and McAfee has been the rest of it for a week. Here are the directions I sent along with the AOT and fil to all my local offices. Maybe they'll help someone...

    If you have questions you may contact Dean at DJorges@BDO.Com

    Eric Fairbanks' Idea

    Virus ProtectionAs many of us are aware, macro viruses that attack MS Office 97 are becoming more and more prevalent. One of the first things that many of these macro viruses try to do is turn off the Office 97 macro virus detection capabilities. What I've done is create an Application Object that turns these settings back on everytime a user logs into the network. While this won't stop the macro virus from turning off the macro virus detection capabilities at the time of infection, it will turn the detection back on the next time that workstation logs into the network.

    Download Eric's AOT and AXT.

    If you have any questions you may contact Eric at ERIC.FAIRBANKS@netl.doe.gov

    Aaron Miles' Idea

    Virus ProtectionHowdy. Regarding the Mcafee DAT update reports. I have just done this with the Novell Workstation Scheduler. What I do is:

    1. Create a directory on the fileserver (f:\apps\superdat) and download the superdat from Mcafee (sdat4063.exe for example).
    2. Rename it to Superdat.exe (just for simplicity sake).
    3. I then create (on a workstation) a workstation event (c:\novell\client32\wmsched.exe) to run the superdat from the fileserver with the following command line options (/f /silent). This basically does not disturb the user of the presence of the event.
    4. Once I have the event working on the workstation (i.e run manually to see its effectiveness) I then enter the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Novell\ Workstation Manager\Scheduler) to change the LAST_RUN option to all zero's (when you see it you will know what I mean).
    5. I then export the registry key for the event
      (HKEY_LOCAL_MACHINE\SOFTWARE\Novell\ Workstation Manager\Scheduler)
      and create a run-once forced NAL for that key to the workstations.

    Voila! (Hopefully) every machine will now get the NAL which will ask the machines (when they can - I.E logged in) to update McAfee via their Superdat file. Hope this helps at least one person :-)

    If you have questions you may contact Aaron at aaron@image.net.au

    Kenneth Franklin's Ideas

    Virus ProtectionI was just reading Tommy Carter's Mcafee update tip and thought I would share mine since it seems to be a little easier.

    Instead of updating the DATs and engine separately as they are released I chose to go with the SuperDAT utility which updates both everytime. Once you download the SuperDAT executable there is no need to snAppShot anything. You simply copy the executable out to your distribution directory and create an application that will run the executable with the command line switches /s, /f and /reboot. This will force the update in silent mode and reboot automatically.

    It works wonderful for us and takes only about 5 minutes from the time I download the SuperDAT to get it live on the network. I got the switches from Mcafee tech support after about 4 or 5 tries. They apparently don't like to give them out and they are not documented anywhere.

    I have a few more tips related to Mcafee that allows me to run it daily on every machine on the network INVISIBLY to the user so they can't stop it or even see it. The results of ALL the clients are recorded to a master logfile that I can view at anytime and see the USER and PC that is infected if any. Here goes:

    Installing McAfee 4.03 or 4.02 with ZENworks

    1. Install the application on a PC with the -r switch and configure as you like. This will record your options to c:\windows\setup.iss for later use.
    2. Copy the install executable (or all files contained therein) out to your distribution directory and move the setup.iss file you created to the same directory as setup.exe.
    3. Create a simple application that simply runs the setup executable.
    4. Modify the applications command-line parameters to read - /s. This will install the application silently and use the options you recorded earlier.

    For reference, the switches I know of for McAfee 4.0x install are:

    /s - silent mode
    /r - reboots when complete
    -r - records install settings to c:\windows\setup.iss

    Installing SuperDAT Updates

    1. Copy the install executable out to your distribution directory.
    2. Create a simple application that simply runs the setup executable.
    3. Modify the applications command-line parameters to read - /s /f. This will install the update invisibly and force a reboot.
    4. Make sure you set the application object never to reboot.

    For reference, the switches I know of for SuperDAT updates are:

    /s - silent mode
    /r - reboots when complete
    /f - forces the install (usually required)
    /p - displays prompts

    For reference, the switches I know of for Scan32.exe are:

    /nosplash - disable splash screen when Scan32 is launched
    /autoscan - begins scanning immediately
    /autoexit - exits the program when scanning is complete

    Running and monitoring your McAfee Anti-Virus software

    Here's the fun part! This next section explains how to run it daily on every machine on the network INVISIBLY to the user so they can't stop it or even see it. The results of ALL the clients can be recorded to a master logfile that can be viewed at any time to see the location and status of viruses.

    To make Scan32 run at scheduled times and close automatically:

    Note: I make the assumption you are using User Policy Packages or at least have the capability.

    1. For the user or group of users you want to for the scan on (ideally everyone) add a new policy called Scan32 or whatever to their User Policy Package.
    2. Go to the details of the Scan32 policy and schedule it as you like. I run mine daily.
    3. Go to the details of the Scan32 policy and add this action: Name: C:\Program Files\Network Associates\McAfee VirusScan\scan32.exe

    Parameters: /nosplash /autoscan /autoexit

    To make the program invisible to the users (prevents cancellation) and record to a master logfile:

    1. Add these two entries to the [Scan Options] section of your DEFAULT.VSC file in C:\Program Files\Network Associates\McAfee VirusScan\:

      UIType=2
      szTaskName=
    2. Continue editing the DEFAULT.VSC file.
    3. Change the szLogFileName= entry to a path that all users can write to on the network. I use SYS:PUBLIC. (szLogFileName=\\SRV1\SYS\PUBLIC\VSCLOG.TXT)
    4. Distribute this file as you like so that it overwrites the users DEFAULT.VSC file. I distribute mine with every SuperDAT update just to be safe.

    This works GREAT and is all made possible by ZENworks! Using this method I can keep my DATs updated with MINIMAL effort and eliminate viruses before they cause any real damage. It's interesting to watch a virus propagate through a department before the scheduler kicks in and wipes it out! Hope this helps someone.

    If you have any questions you may contact Kenneth at FranklinK@grandcasinos.com

    Ron Reece's Idea

    Virus ProtectionI have read all of the suggested ways to update McAfee VShield from the Cool Solutions readers, and I have one more suggestion to add. It's a combo approach between ZEN and McAfee's distribution methods.

    Our problem was the previous install base of the Vshield product was inconsistent at best. The directory structures used were different depending on the tech that installed the product on the PC. Once we started using ZEN, it seemed to be the logical approach to standardizing the installation, and keeping up with the frequent DAT updates. Unfortunately, the removal of the old installation was a bit sticky. ZEN could remove the files and reg and .ini files, but I could not find a way to get the app to shut down to deliver the new product. Then McAfee came out with the silent installation of the 4.x scan engine, and in roughly the same time frame, the Superdat. Problem resolved.

    I built three application objects: the first object calls the Superdat in silent mode, the second the Vshield engine setup in silent mode, and the third copied the Default.vsh file with the preferences pre-configured for the workstations.

    There was an additional key element to the process, the EXIST.EXE contributed to Cool Solutions by Anders Gustafsson, found at http://www.novell.com/coolsolutions/tools/1067.html.

    I used the pre-script in the Superdat object to check for the existence of VSHWIN32.exe in the directory structure that I wanted. If it did not exist, the Vshield quiet install was called from the script, and the Superdat was verified out of the end of the Vshield quiet install. At the end of the Superdat, the configuration preferences would be copied with the 3rd app object.

    Sounds kind of complicated, doesn't it? It really isn't. Here's the .AXT, and the script for each.

    If you have any questions you may contact Ron at RonR@mclaren.org

    Craig Bennett's Idea

    Norton Antivirus Definition Updates

    Virus ProtectionThere seems to be a lot of Q&A's about updating McAfee definitions, but none about Norton AV. I don't know if that is because McAfee is harder to update, or that nobody uses NAV, but we use NAV so here is how I do it.

    1. Create a force run, run once application and associate it with everyone.
    2. In the Distribution tab, give it a version stamp of the date in ANSI format (YYYY-MM-DD). This allows us to use the same object over and over for each update.
    3. Add the following line to the Run after distribution script.

      @s:\NAVDEF\0124i32.exe /extract /q "C:\Program Files\Common Files\Symantec Shared\VirusDefs\Incoming"

    This works for both Windows 95 and Windows NT. When new definitions come out we just need to put the new definion in S:\NAVDEF and update the version stamp and the filename in the run after distribution script.

    If you have any questions you may contact Craig at theclyde@mindless.com

    Scott Peucker's Idea

    Virus ProtectionIn addition to Ujjain Kumar's tip on updating McAfee's DAT files, you can make a NAL snAppShot of this process and distribute this to your users. We have been using this method for a year or so. When we rolled out version 4.0.3 of VirusScan via a snAppShot, I just included this configuration step in the snAppShot.

    If you have any questions you may contact Scott at Scott.Peucker@dsto.defence.gov.au

    Greg Mermuys' Idea

    Virus ProtectionAwhile ago you published this in the Q&A: Heads Up from a Cool (anonymous) reader: I was testing McAfee Antivirus deployment. It took me a couple of hours to figure out that the Antivirus was stopping my NALexplorer from running. The McAfee properties of scanning files when the run option is turned on will prevent the NALexplorer from running.

    You can test it yourself. Just go to a machine that not working and go into McAfee Antivirus properties and unselect detect-on-run option. You will notice that things work the way they used to.

    I ran into this myself with McAfee 4.0.x but still wanted to scan all other programs when run instead of disabling the whole thing. These are the exe files that are launched when NAL or Naldesk are launched. I put these files in the 'exclude' tab of the system scan. NAL and Naldesk will now load without locking the system.

    I put in seven entries into the 'exclude' table...
    1. z:\public\nal.exe
    2. z:\public\nalstart.exe
    3. z:\public\nalwin32.exe
    4. z:\public\naldesk.exe
    5. z:\public\nalexpld.exe
    6. c:\novell\client32\nalwin32.exe
    7. c:\novell\client32\naldesk.exe

    This will keep the system from locking no matter where you load NAL or Naldesk from (ie: server or workstation). Also keeps your workstation a bit more secure from those pesky viruses. (This is in a Win9x environment with McAfee 4.0.5 and ZEN 1.1)

    If you have any questions you may contact Greg at GMermuys@scgw.sc.hollandc.pe.ca

    Louis van Belle's Idea

    (Note: There was an error in the original posting. The corrected loginscript line is below.)

    Virus ProtectionTip for update McAfee using Super Dats: put this line in your loginscript:

    #\\servername\sys\{directory}sdatxxxx.exe /Silent /reboot

    When you login to your network the update will be installed. When installed, your PC will automatically reboot. On the second login, the Sdat .exe will check, but not install again.

    This will work with Win9x, and NT. Using these updates you always have the latest engine installed.

    If you have any questions you may contact Louis at louis.van.belle@kooijman.nl

    Zaheer Hasan's Idea

    Zaheer Hasan, MCSE MCNE

    Virus ProtectionAfter working for a few months I have created a single snAppShot of McAfee 450. It will uninstall and install a SINGLE SNAPPSHOT of the new version of McAfee. I have pushed out this snAppShot to almost 1000 users with NO ERRORS. Still working to push it out to another 1200 users.

    Protocol For A Single snAppShot to Install McAfee v4.5.0 and Uninstall Older Versions

    1. Find a PC with McAfee v4.0.x already installed.
    2. Install the new McAfee on top of the older version.
    3. Reboot.

    Creating snAppShot I (to uninstall McAfee v4.0.x)

    1. Run Snapshot.exe (name it: Uninstall McAfee v40x)
    2. Go to => start=> add/remove programs
    3. Remove McAfee VirusScan ( This will remove the older McAfee version)
    4. Reboot the computer.

    End of snAppShot I

    For snAppShot II you will need another PC. In my case I created an image of my PC which allowed me to have a fresh image every time I created a new Snapshot. Here you will uninstall the older version of McAfee manually and create a snAppShot to Install McAfee v4.5.0.

    Creating snAppShot II (to install McAfee v450)

    1. Run Snapshot.exe (name it: Install McAfee v450)
    2. Install McAfee v4.5.0
    3. Reboot

    End of snAppShot II

    You have now created two snAppShots, one that will uninstall McAfee v4.0.x and the other that will install McAfee v4.5.0. Now we need to combine the two snAppShots into a single snAppShot.

    Creating a Single snAppShot to Uninstall McAfee 4.0x and installing McAfee v4.5.0.

    1. Run Snapshot.exe
    2. Run snAppShot I (Uninstall McAfee v40x)
    3. Reboot
    4. Run snAppShot II (Install McAfee v450)
    5. Reboot
    6. Run Sdat4079
    7. Reboot
    8. Modify VirusScan console to do AutoUpdate
    9. Modify Vshield System Scan for Detection, Alert, Report, and Exclusion
    10. Run the AutoUpdate
    11. Reboot

    Now you have created a single snAppShot that will not only uninstall and install McAfee VirusScan, but will also modify Console for the future updates and Vshield for the removal of extensions. Now you no longer have to visit each workstation to update. The McAfee updating of all workstations can be done with a single snAppShot, error free.

    Download Zaheer's AOT.

    McAfee v4.5.0 Instructions

    Wherever there is an xxx, replace it with the first 3-letter code of your office (i.e. xxxnwprd in New York NYKNWPRD)

    Create the Application Objects

    McAfee 4 5 0 =>
    \\xxxnwprd\sys1\utlity\snapshot\McAfee 4 5 0\McAfee 4 5 0.aot

    Modify the McAfee 4 5 0 Application Object

    Identification:
    Run Application once = Checked

    Distribution:
    Option: Reboot: Always = Checked
    Don't Prompt = checked

    Reporting log Events to a file = checked
    Path = \\xxnwprd\sys1\utility\logs\McAfee 4 5 0.log
    Event to report = check all boxes

    System Requirements:
    Add => operating System
    Windows Platform is = windows 95/98

    Application Files
    Modify 3 files:
    SHFOLDER.DLL
    Selected item(s) options:
    item will: copy if does not exist

    SHLWAPI.DLL
    Selected item(s) options:
    item will: copy if does not exist

    WININET.DLL
    Selected item(s) options:
    item will: copy if does not exist

    Macros:
    Change the following:
    SOURCE_PATH \\xxnwprd\sys1\utility\snapshot\McAfee 4 5 0

    DONE.

    PS: this will work if you are running older versions.

    If you have any questions you may contact Zaheer at Zhasan@bdo.com

    Adam Kuhn's Idea

    Here's some more on McAfee VScan/VShield 4.5.0. The Cool Solutions article on Office2K distribution was the tip-off for me. The newest corporate McAfee program uses Microsoft Installer technology. And, just like the Microsoft Office Configuration Wizard, McAfee has its own "Installation Designer." You have to download it from their site.

    One of the best features of the McAfee Installation Designer is that you can create a new VScan45.MSI file and update it with the latest DAT file. Thus, whether you push out the program using Microsoft Installer, or as a snAppShot, you can probably avoid an extra step of updating and rebooting because you just pushed out 6 month old DAT files. You can push out a snAppShot with today's DAT files!

    Keep an eye on all of these programs using MSI files. The new RightFax client also uses them.

    Hope this helps folks out there.

    Update from Adam Kuhn:

    I've received a few queries regarding my McAfee Installation Designer post. A lot of folks want to try it, but they can't find it! Here's how: You will need a NAI "Grant Number" that you get when you buy the corporate agreement. That will get you past the login at https://secure.nai.com/us/forms/downloads/upgrades/login.asp

    When you are in, the file MID110L.Zip is at the bottom of the list. That's the file you need.

    If you have any questions you may contact Adam at akuhn@eei.org

    Joe Howard's Idea

    This may be a FYI to anyone using ZEN heavily and running 95/98 Clients with McAfee installed.

    Beware the "scan all files" setting with McAfee. My 'antivirus' guy recently changed the VShield setting to scan all files in the default.vsh file and pushed these settings out accross the company. Next day lots of users were hanging on login.

    Not knowing about the settings push we started troubleshooting, tracked the hang to NALDESK.EXE and then continued troubleshooting.

    The login hangs didn't happen to everyone, so we started un-associating apps and relogging on to find the offending app.

    It could be cleared up doing this, but wasn't consistent. Disabling McAfee cured any problem, then we discovered the McAfee settings changes that had been made.

    Bottom line - drop the "Scan all files" setting and NALEXPLD and NALDESK goes back to running normally.

    If you have any questions you may contact Joe at jrhoward@idc.com

    Joppe de Leeuw's Idea

    Tip for updating/upgrading McAfee VirusScan 403a via application object.

    ZEN 2.0, NAL 3.0, Novell Client 4.6 SP1

    Sdat<version>.exe needs local admin rights or system account to install itself on workstations. Suppose users don't have local admin rights? Then you can run sdat<version>.exe via an application object "as secure system user", but.. that only works if you associate workstation objects to the application object. If you don't have the possibility to associate workstation objects to your application object, then you can do this:

    Application Object:

    1. Distribute sdat<version>.exe (rename it to setup.exe) to C:\Program Files\Network Associates\ Virusscan\ (Force Run, versionstamp).
    2. Run C:\Program Files\Network Assiocates\ Virusscan\setup.exe "as secure system user" with option -s (silent mode) as command line parameter.

    If you receive a new sdat, just copy it to the distribution-server, rename it to setup.exe and change the versionstamp of the object.

    This way sdat<version>.exe (renamed and copied as setup.exe) will run locally on the workstations under the system account in silent mode immediately after the copy-action via the same Application Object.

    If you have any questions you may contact Joppe at Joppe.de.Leeuw@ingbank.com

    Jens-Peter Brand's Idea

    McAfee and Updating DAT-Files

    I read the article #5 and those from Rick Hellewell and Casper Pederson. We use a way of distributing the actual DAT-files to the (NT-)workstations, that is a bit different:

    We set up the workstation to get updates from a local server (as described in article #5) but to initiate the update we use the login script.

    1. Make sure you have the following files in your SYS:PUBLIC directory:

      MCUPDATE.EXE, MCKRNL32.DLL, MCUTIL.DLL, SHUTIL.DLL and SHLWAPI.DLL.

      They can all be found in your McAfee (or NAI) directory. SHLWAPI.DLL can be found C:\WINNT\SYSTEM32.

    2. Insert the following line into your login script:

      #SERVER/SYS:PUBLIC\mcupdate.exe task update

    Now you can use the login script to be sure all useres have the most current version of the DAT-files located on your server.

    If you combine this solution with one of the described above to distribute a snapshot that contains the settings for AutoUpdate from a local server you will have a 'virus-secure' environment.

    If you have any questions feel free to contact me at jens-peter.brand@sbi-online.de

    Stephen Driscoll's Idea

    McAfee Updating Audit.

    Virus ProtectionI was reading with interest about updating McAfee 4.5 Dat files using ZEN.

    The one important part I needed was still missing, I needed an accurate audit of Windows 95 Computer names and the versions of Dat files installed.

    I have found a way to do this by using ZFD2, an application running the Superdat update, with a post Launch script, and a little help from REGREAD.

    In the script I have:

    REGREAD "HKLM,SYSTEM\CurrentControlSet\ Control\ComputerName\ ComputerName,ComputerName"
    set computer ="%99"

    REGREAD "HKLM,SOFTWARE\Network Associates\TVD\ Shared Components\VirusScan Engine\4.0.xx,szDatVersion"
    set vdatver = "%99"

    REGREAD "HKLM,SOFTWARE\Network Associates\TVD\ Shared Components\VirusScan Engine\4.0.xx,szEngineVer"
    set vengver = "%99"

    #sdat.bat

    ..and a batch file sdat.bat with:

    echo "%computer%","%vdatver","%vengver%" >>vscan.log

    What comes out is a simple comma delimited file that I can import into MS Access and print reports from.

    Never under estimate the Power of REGREAD.

    If you have any questions you may contact Stephen at s.driscoll@fnc.co.uk

    Kelly Clemmensen's Idea

    Virus ProtectionCool Solution for distributing the McAfee Scan Engine and Dat Update (SuperDat)

    When we first started distributing the sdat file we had just added a line to the login script that would run the superdat update. The problems we faced with this scenario were:
    • The superdat update would run every time the user logged into the network.
    • Remote users were being affected because the update would try and run across the modem line when they log in.
    • Updates would fail because two users were trying to access the log file at the same time.

    Our company has twelve NetWare 5 servers under twelve different contexts. Mondays are designated as the superdat update day. My routine was this: every Friday night I would un-comment the line that executed the sdat update so when users logged in Monday their McAfee dat files were updated. Monday night before I went home I would comment out the line that ran the sdat update from the login script. As you can imagine this can be time consuming and boring. Out of frustration I was forced to explore new ways of automating this task.

    My solution involves User Policy packages. I had already created a user policy package to import my workstations into NDS and run the Netware Application Launcher. As you know, there can only be one user policy package associated with each user.

    So I added an action to the policy package I already had.

    1. Open Netware Administrator
    2. Locate an existing or create a new User Policy Package. Right click on it and then click details
    3. The first tab "Policies" there will be a handful of predefined actions. Click the "Add Action" button.
    4. Under "Create Scheduled Action" give your action a name. I named mine "McAfee update". Then click create.
    5. Now your list of actions includes the one you've just created. Double-click your newly created action.
    6. The first tab is "Policy Schedule". My default event is set to User Login. I changed this to "Weekly" then specified the day and time period I wanted this action to run. I put in a 3-hour window. Click the "Advanced Settings" button. Change to the fault tab. The field "What do you want to occur if the action could not run?" I changed to "Retry every minute". Everything else I left default. Click OK.
    7. Next click the "actions" tab. Click the "add" button. At this screen you need to specify the superdat filename.

      Note - When copying the superdat file to the distribution directory on my file server I would change the name to superdat.exe so I wouldn't have to modify my action every time I downloaded a new sdat from McAfee.

    8. Use the browse button to locate the file. Fill in the Working Directory field. Under parameters I put the switches "/s /f" (

      Note: I could have also used a switch to specify the name of the log file. Sometimes when two users are updating their dat files at exactly the same time, the update would fail because the log file was locked. This is why I changed "Retry every minute" on the fault tab under advanced settings. That way I could keep one log listing all the users who ran the update instead of a log for each user. I then take that one log and rename it to the date of the update to keep as reference. The next time the McAfee updates run it will generate a new log.

      Next I changed the Priority to "Above Normal". Click OK. Click OK again. You're done with creating your action. Make sure there is a check mark next to the new action.

    Remember: This action randomly dispatches the McAfee update. If you%92ve specified a 3 hour window for this action to run, wait all 3 hours before troubleshooting why your update doesn%92t work. I specified Monday%92s between 9am and 12pm. Every fifteen minutes I would check the scandat log and I would find that another user had been updated. The log is appended to every time a user runs the update.

    If you have any questions you may contact Kelly at kellyclemmensen@attitude.com

    Magnus Ullberg's Idea NEW

    Virus ProtectionAutomatic McAfee dat-file distribution and update

    Assumptions:

    • You have multiple locations with a local server.
    • G-drive is mapped to vol\apps on the local server at each location.
    • McAfee is installed on every workstation.

    Stage 1 - Distribute the files

    1. Download the newest dat-file from McAfee's website and save it as g:\mcafee.dat\current.exe.
    2. Modify the files named "Servers.x" to have the names of your servers in them. The reason you have multiple files is if you want to have the files copied to more than one server at a time.
    3. Run dist.cmd on a NT Workstation or server that has Perl installed on it. (You can download it from http://www.activeperl.com/)
    4. When the copy is done you will have some new files called "results.x" with the results of the copies, check those to make sure that all copies went well.

    Stage 2 - The appobjects

    1. Open the file AppObjects.xls in Excel and modify the values if needed.
    2. Create a new file with Notepad and copy and paste the information from the last 3 worksheets in the Excel document to that file.
    3. Save the file and double click on it. (look at appobjects.cmd to see a example)

    Some notes:

    You can use both the AppObjects.xls and distribute.pl file in other situations too. Use your imagination... :)

    I've included a small perl-script I wrote to download the dat-files as soon as they are updated. The script is meant to be run on a Linux box, probably using Cron. The script will e-mail you and let you know when the new files have been downloaded. Please make sure you modify the e-mail adress and path in the script.

    Download the zip file.

    If you have any questions you may contact Magnus at UllbergM@abcbank.com

    Erich Burnett

    This will work for W2K, NT, and W9x clients. Here's how I update the virus definitions on machines. I download the latest xxxdat.exe file and save it as 1.fil in the directory I use as the "Source Path" for a ZENworks application object I've got set up named "Download dat file" - which does exactly that - it copies the *.fil file to the client's hard drive (root of c:\) and names it dat.exe. Another application object I've got setup, called "Run dat update", is ordered (#2) to run after the "Download dat file" (ordered #1). This is a simple app object that is set to run "c:\dat.exe" with a parameter of "/s". Both of these app objects are set to force run and run once. When I download a new dat file, I copy it to the source path and change the version numbers on the two application objects and the next time the user logs in, boom, dat files are updated.

    If you have any questions you may contact Erich at eburnett@stelco.org

    Ryan Maizel

    Like so many others I see in your article, I use the McAfee SuperDat update files to keep things running. Although my method isn't as automated as some others, it does have the advantage of being able to maintain the version number with minimal effort. Ok, here's what I do:

    1. Setup the Application object to run the SuperDat using Macros. It looks like this:

      "%SOURCE_PATH%\sdat%DAT_VERSION%.exe"

      This allows me to change the location of distribution, and Dat version easily. %SOURCE_PATH% is obviously the location of the dat update; this can be drive-path or UNC. %DAT_VERSION% is just the four-digit version of the SuperDat file (McAfee's numbering system). I setup the app to force-run for all users, but also to RUN ONCE so that I save on startup time.
    2. Here's where I save some additional time. I setup the DAT_VERSION Macro to pull from the App Version Stamp like this:

      DAT_VERSION=%*;App:Version String%

      This way, all I need to do when I download a new file is change the App Version Stamp to match the new McAfee Version Number and it runs on its own!

    Updated on 18 Feb 2002: In my suggestion about using SuperDat files but maintaining the McAfee version number, I overlooked a difference between ZEN2 and ZfD3 that would cause the app not to work. In my suggestion, I said to add the following Macro:

    DAT_VERSION = %*;App:Version String%

    Unfortunately, the App:Version String attribute is no longer used in ZfD3 and later. For disconnected support the attribute was changed. The correct Macro if you're using ZfD3 should be:

    DAT_VERSION = %*;zenappDisconnectedVersionNumber%

    I'm sure that will help a few people!

    If you have any questions you may contact Ryan at Ryan@RepublicDrug.com

    Jim Trotter

    The following is how I distribute McAfee DAT file updates to 1500+ workstations. My environment is NW4.2, ZfD2. I'm behind a firewall that will not let me auto-connect to the McAfee web site, I can only do that manually with a browser.

    Each week I download the DAT files and SDATxxxx.exe files from McAfee. I change the name of the SDATxxxx.exe to DATUPDT.EXE and place it on a central "distribution" server. Using a combination of the CRON.NLM and TOOLBOX.NLM, the "distribution" server runs a .ncf file that distributes the new SDAT (disguised as datupdt.exe) to all my servers. In each location I have an application object assigned to the workstation objects, set as "Forced Run", with the -s -f switches, that runs everytime the workstation logs in.

    This way all my workstations get the updated DAT files. In the case of an emergency, I can always run the .ncf distribution file manually.

    I update my servers' DAT files by pointing the other servers to my "distribution" server and allowing them to autoupdate from this "distribution" server.

    If you have any questions you may contact Jim at Jim.A.Trotter@usdoj.gov

    Juan Flores

    Our steps of updating McAfee DAT TAbles to workstations.

    1. First, we create an application object, that is UNC to the specified file. We call it sdat.exe. It also has Force Run checked.
    2. Then under hte Environment tab, there is a command line of /s in the field.
    3. On the Distribution Stamp, we enter the DAT Tables version (ex. 4164).
    4. Under Associations, we added a group called Nal, and set the option to Force Run.
    5. In the login script, we have a line that states ex. @\\servername/sys:public\nal : /h. By doing this, no one sees the application launcher and it will then unload when all applications are pushed down to the clients.

    This works well -- everything is UNC and there are no batch files or mapped drives. Just be sure that all users are in the Nal group. I modified our new user template so each new user is in the Nal group by default.

    Whenever a new table is out, simply copy the new table to the path source, and modify the distribution stamp.

    Mike Berneathy

    To send out McAfee updates I created a batch file on every desktop to access a folder called F:\main\apps\VUD\sdat.exe.

    Then, before I upload the McAfee updates to the school sites, I rename the update file to sdat.exe, no matter what the real name of the file is. Then I send out an e-mail telling users to double-click on the batch file icon and they are automatically updated. I receive "Mail Opened" info from GroupWise telling me if they received and opened my e-mail. If they're not sure whether they've already updated, they can double-click the icon and McAfee will tell them if they have the latest files.

    Doug Heinsdorf, CNA5

    I have some answers to some of the issues raised so far in this article.

  • Prior to running the NAL shell (versus explorer.exe) make sure the OS image has the VShield icon "disabled" in the system tray. Besides the 5 or so key files we know VirusScan must be setup to ignore (Zen stuff), having this systray icon running will cause trouble. This is done by: VShield in systray, properties, system scan, tick show icon in taskbar.
  • In addition, but not a necessity, the VirusScan Console icon in systray can be removed in similar fashion.
  • I read one post about a user losing all his VirusScan configurations after the SnAppShot, or at some point post deployment of the VirusScan AppObj. I have gone through this at various levels, the cause was creating the SnAppShot with ZEN v1.1 (starter pack, but that's irrelevant) then deploying after upgrading to Zen2. For school Admins, the upgrade to Zen2 will also break MS Encarta2000 AppObj's.
  • Finally (for now), for NalShell users experiencing choppy Windows startup and shutdown sounds, I have elected to remove the Startup and Shutdown sounds from the default 98SE sound scheme. It appears VirusScan is getting too much of the CPU cycles from our Optiplex GX110's i815E chepset's integrated sound processing. Also I have noticed this in some SB64AWE ISA Optiplex's.
  • Here's an additional tidbit: Added 8 Nov 2001

    I took a SnAppShot of a VirusScan 4.51 install - I tweak and adjust everything on the client side as usual. Upon pushing the new App Object (which has worked well in the past) the client workstations were all hanging with an Invalid Page Fault - Explore.exe and IExplore causing the error in module <unknown>. There seemed to be no simple fix for this and the workstation became useless, thus requiring a re-image (Drive Image Pro 4.0).

    What had occurred is in the VirusScan App Object the reference system had OutLook Express (5.5sp2) configured and thus functional. On the workstations receiving the VirusScan push, the OE wizard had not been run, and a registry poke (App Object) had plugged in a setting into Internet Explorer to call a web based e-mail client when the user selected "Tools, Mail and News, Read Mail" instead of OE.

    So a new App Object was created for VirusScan without E-Mail scan configured. I assume any virulent attachment from the web based e-mail client will be caught with VirusScan's "Download Scan". Just something to look out for.

    If you have any questions you may contact Doug at dheinsdo@apscc.org

    Lee Kasner

    I have been reading the McAfee tips with interest since we just were given a license for it and I was tasked with distributing it on 200+ PCs at two sites. Installation was easy with a snAppShot. For updates, I wrote a quick Visual Basic program that FTPs to McAfee's site and checks for updates. Using the cool ActiveX controls Novell provides for free, I can access the application object within the VB program. I check the version McAfee has with the version number of my application object. If it is newer, the program downloads it, copies it to my other site's server, and then updates the version number and command line of the application object with the new SDAT name. Since it is set to force run, the new version number will assure that it is automatically pushed to the client PCs. Since I have the VB program running on a scheduler, it is totally automated so I do not have to do a thing and all the PCs get updated.

    If you have any questions you may contact Lee at lkasner@helenellis.org

    Alasthair Saunders

    As per many other tips - I create an application object to run the appropriate sdatXXXX.exe file with the /s switch. However as users require more than normal user rights to the workststation to actually complete the update, I add the following cacls commands to the "Run after" distribution script of the same application object:

    • #cacls "c:\program files\Network Associates" /e /p users:f /t
    • #cacls "c:\program files\Common Files\Network Associates" /e /p users:f /t

    Full rights may be a bit excessive but it guarantees the update can take place.

    Hope this helps someone.

    Xavier Zinn

    Here is another way to update McAfee. This works on W2k, NT4.0 and Win95.

    Firstly, to upgrade/install McAfee Vscan 451 from 4.02 and 4.03a I did the following. I created an object called VSCAN451. I used the manual option when the screen comes up after you select application object (ConsoleOne). Once the object is created, I put the following path under applications on the Run Options tab.

    \\servername\path\setup.

    The parameters used were:
    /qn+ /Lev c:\mcaffe45.log /i

    I got these parameters off the Microsoft web site. These apply to all MSI's.

    The parameters stand for the following:

    • qn+ -- you get a dialog box at the end of the installation.
    • Lev -- log file, everything, verbose, path to log file
    • i -- is for install

    Even if installation fails the log file is created.

    McAfee vscan 451 is an MSI so I didn't bother making an AOT since it works fine the way it is. It checks to see if there are any older versions of itself on the workstation along with other virus apps, unistalls them and installs the new version all without prompting. It works fine. (Make sure you don't have any apps that use WINAPP32 directory. It will uninstall everything in this directory, because Solomon anti-virus uses this directory and it is one of the apps it checks for. In this case uninstall first.)

    I added the OU and set the app to force run. Since it is an MSI it will install every time the user logs in so I created some logic for the application. Here is is.

    HKEY_LOCAL_MACHINE\SOFTWARE\ Network Associates\TVD\VirusScan does not exist.

    The app will only install if this key does not exist. If it's there it won't do anything.

    For the dat file, I did essentially the same thing. I created an object the same way as for VSCAN, with the path to the sdat.exe. I truncated the name just to sdat and used the numbers as the version number.

    The parameters to the object are /silent /reboot /prompt.

    At a dos prompt if you do sdat /? you get these parameters and their meaning.

    This object is also set to force run and the OU is associated to it. The sdat file is smart enough to know if the version on the workstation is the most recent so I don't have to put in a logic statement.

    It took a while to get it to work with all the switches but it is setup and works fine. All I need to do now is update the sdat in the proper directories and I use Appassi for that. It works fine also.

    Isak Rytz Zadik

    Since I'm a Kix - fan, I wrote an Update-script in KIX ( http://www.kixtart.org/ ) which runs on every logon.

    The first step is to determine if there is a newer version available. My solution is to read the

    HKLM\Software\Network Associates\TVD\Shared Components\Virusscan
    Engine\4.0.xx\szDatVersion

    and compare the value to the

    "DATVersion" row in update.ini located at the Mcafee Virusscan 4.5.1 Mirror Location.

    If the Datversion number in update.ini is Newer than the installed one, I also read FileName in update.ini and receive sdatxxxx.exe (xxxx=currentdatver)

    I finally start the SDAT update with /Silent

    With this solution I can update the virusscan using SDATS, with the update running only if there's a newer version available.

    Tony O'Connell

    I setup FTP on my NetWare applications server and copy all the current updates to a folder off vol1:<root> called McUpdate. This solution does not appear to work using any other directory name or set up as a sub-directory. Each week I copy the latest updates from the 4.x directory (we use 4.5.x) as an image site. Our NT servers, NetWare servers, Windows 98 client and NT clients all have their update location pointing to the DNS name of the service. In our case, ftp://ftp.mcupdate.<corporate-domain-intranet>. The clients are configured to update every Tuesday and the servers every Monday. We like some delay built in to test each update manually. It is entirely invisible to the end user.

    To ensure that all the clients would point to the correct location, I configured the Update part of the McAfee Console on my workstation and then exported that part of the registry. I then created a simple application object using a batch file I called vshield.bat and delivered the registry hack using NAL. The batch file is as follows (2 lines):

    @echo off
    "c:\program files\network associates\virusscan\msi_inst.exe" /import \\pjinwapps01\vol1\apps\vshield.ini /restart

    This works great and is extremely reliable. I haven't implemented the auto-image update to McAfee's site due to firewall limitations.

    If you have any questions you may contact Tony at Tony_O'Connell@papajohns.com

    Don Kurfurst

    I have been reading the suggestions and tips for distributing McAfee updates for a while now. While all of the tips were very good, none of them did exactly what I wanted to do. I wanted to check from a central location to see if any new Virus signature updates were available, and if so distribute them to my desktops via ZENworks. My desktops are comprised of Microsoft Windows 95, NT and 2000 and all have different versions of McAfee running. I wanted an application object created and set to force run once when a new update was found.

    OK this is what I did. First I used several tools such as WinBatch, ZENworks Application Tool Kit and a program called AutoFTP to accomplish my goals. The first part of this was to setup AutoFTP on a system locked in my computer room. AutoFTP is an FTP program that can be scheduled to automatically check for files on an FTP site and download any that are new based on the criteria you set. I set AutoFTP to look for these files on McAfee's FTP site:

    • Autoupg.zip
    • SDat-*.exe
    • and Dat-*.zip

    I then have it check every hour to see if there is an update. AutoFTP will connect to McAfee and check the file sizes and compare them to the files I already have saved locally. If the files are newer, then they will be downloaded. If not they are skipped and it waits for the next scheduled cycle and starts all over.

    The next part was the tough part. If there is an update how can I tell, and then distribute it? This is where WinBatch comes in. I created a small program that gets called after the AutoFTP process runs. The WinBatch program (which I named Compareini.exe) opens an FTP session to McAfee's site, downloads a file from McAfee called Update.ini, then compares a version string within the Update.ini file to a copy stored locally called update.bak. If the version string is the same, the program ends. If the version string is different then several things will take place.
    1. First a copy is made of the Update.ini and overwrites the old update.bak (for future comparison).
    2. Second, the version string of the new file is written to the Application Version Number value in an AXT file called Superdat.axt (see the end of this tip for the Superdat.axt).
    3. Next the files that were downloaded from AutoFTP are unzipped to their proper directories that I set up, and the program composes an e-mail message stating that there is a new version of virus signatures available. The e-mail reports what the new version is and what the previous version was, and is sent to my e-mail address and pager.
    4. Now comes the best part of all, the WinBatch program now calls 4 separate applications from the ZENworks Application Tool Kit.
      1. The first call is Apperase. Apperase erases the previous version of my application object (which I call SuperDat) which distributes the McAfee superdat.exe executable. (You will see what I am talking about further down.)
      2. The second call is Aotxport. Aotxport compiles an ?AXT? file that was preconfigured with the run once, availability option set for spread time to be 120 minutes, and has the version set to the same version number that was parsed in the update.ini (see the end of this tip for my AXT file), into an AOT file called SuperDat.aot.
      3. The third call is Appcreate. Appcreate creates the ?SuperDat? application object in the container I specified from the compiled SuperDat.aot
      4. The last is the best part; this is where the WinBatch program calls AppAssoc. AppAssoc associates the newly created SuperDat application object to the parent container that all users are under, and sets the application object to a force run and to be available thru the application launcher.

    In the end (and in about 20 seconds), I have checked for virus signature updates, downloaded the updates, sent e-mail about the updates, deleted the old application object, compiled a new application object and set the version and run once option. I've also created a new application object in my tree and associated the object to all users and forced it to run with a spread time of 120 minutes to ease network congestion. This, by the way, is all done using the silent install switch of the superdat.exe and I am also writing log files out to a central location for each user which keeps track of the install's success or failure.

    This method has worked flawlessly and works across all Windows versions. Not only does this update the virus signatures but also the engine as well. If any one would like more detailed information and or would like me to customize my process for your environment please contact me at don.kurfurst@fitchratings.com

    SuperDat.axt
    AXT_FILE 3.1

    [Application Name]
    Value=McAfee Superdat

    [Application Caption]
    Value=McAfee Anti-Virus Superdat

    [Application Description]
    File=DESC4823.TXT

    [Application Path]
    Value=o:\avftp\sdat\setup.exe

    [Application Flags]
    Flag=Run Once
    Flag=Never Prompt Reboot
    Flag=Launch Hidden
    Flag=Force Reboot

    [Application Parameters]
    Value= /silent /logfile o:\apptrack\superdat\%vaxuser%.txt

    [Application Platform]
    Flag=Windows 95
    Flag=Windows NT
    [Application Schedule]
    Type=Day Mask
    Day=Monday
    Day=Tuesday
    Day=Wednesday
    Day=Thursday
    Day=Friday
    Start Date=2001/11/5
    Stop Date=2004/11/5
    Start Time=7:30
    Stop Time=19:00
    Spread Time=7200
    Timezone=18000

    [Text File Add End]
    Flag=No Reboot Needed
    File=o:\APPTRACK\Superdat.LOG
    String=%LOGIN_NAME%,%P_STATION%,%MONTH%/%DAY%/%YEAR%,%HOURS%:%MINUTE%

    [Filter OS Version]
    Type=Windows NT
    Major Version=-1
    Minor Version=-1
    Revision Version=-1
    Flag=Greater Than or Equal

    [Filter OS Version]
    Type=Windows 95
    Major Version=-1
    Minor Version=-1
    Revision Version=-1
    Flag=Greater Than or Equal

    [Application Version]
    Value=4180

    [Application Icon Order]
    Value=0

    [Application Association Flags]
    Flag=Launcher

    [Application Version Number]
    Value=4180

    If you have any questions you may contact Don at don.kurfurst@fitchratings.com

    Shaun Pond

    I've read through the suggestions for keeing McAfee up to date, and my suggestion is the following:

    1. Create an app object that copies SUPERDAT.EXE from a specified location (usually a local server) if it's newer than the copy on your machine.
    2. Then run SUPERDAT.EXE /q /f on your local machine.

    Angus Scott-Fleming

    I've done just what Shaun Pond suggests with a batch file that uses a freeware file-age-comparison tool to check whether the local copy of SuperDAT (on the user's C:) drive is newer than the network copy. If so, it copies the network copy to the user's workstation and executes it with the /silent /reboot /logfile switches. It also checks for newer network copies of McAfee's ExtraDAT.EXE EXTRA.DAT distribution tool. I execute this batch file on every login.

    Robert Lavigne

    Here at TORONTO HYDRO in Canada we do all of our updates via ZENworks. What happens is the user logs in every morning and ZEN will check for a new version of the .DAT file. The only thing is that the .DAT file changes all the time. So what we do is:

    1. We keep the one .DAT file on a public server that everyone can get to.
    2. We download the updated .DAT file whenever there is a new one.
    3. Rename it to a common name we used to create all the AOTs for all the contexts.

    And all we have to do is change the guid number in the AOT configurations to let ZENworks know there's a new update and to automatically push it the next time the user logs in.

    If you have any questions you may contact Robert at rlavigne@torontohydro.com

    Juergen Seifert

    I know McAfee changes the installation with every version. The Management Console from McAfee is not useful and the ePolicy Orcestra is to big. With the unattended Installation I cannot change the attribute from the Client.

    I desire a Vscan.adm file for administration of the Vscan Client for NT.

    The Installation Designer from McAfee is clunker.

    Any ideas for Juergen? Let us know.

    Soren Troensegaard

    Amazing how a simple question like -How To Distribute McAfee- can go on for such a long time. Lucky Me - I live in Denmark, where a Danish distributer/reseller has created two programs that will do the job for you.

    And what exactly is it I would like to be done?

    1. Automatic download of newest .dat files
    2. Automatic download of newest Engine updates
    3. Automatic distribution of .dat & engine updates.

    All this should be done WITHOUT any intervention from the administrator.

    The solution is done with two programs -- FTPUPDAT and NETUP32. FTPUPDAT runs on a Windows PC and is scheduled to check for new .dat and Engine files at a given Interval. If new files are found (compared with the distribution dir), they are downloaded and extracted to the location of the distribution directory (NetUp32). After successful download and extract, an SMTP message is sent to whomever you want.

    At my office, I have entered NetUp32 into the login script. When activated, NetUp32 checks the users .dat and engine version against the versions in the distribution directory. If updated files are available, they are installed onto the workstation. NetUp32 disables and enables Vshield automatically. The user does not even know it happened. Another nice feature about the program: NetUp32 will copy the local Vshield logfile to a central place. Hence: If the user had a Virus, and forgot to tell you about it, it will show up in the central log.

    What's the catch - where can I get this? Well as I mentioned above, the program is developed by a Danish McAfee distributor/reseller. The programmer's name is Steen Pedersen, and the program is given FREE of charge to their customers. I asked them today about it, to see if it could be made available. Sorry, only to their own customers. Normally they don't sell Netup32 as a standalone product, but I am sure that if enough people had an interest in this, it would be possible. If you are interested, send an e-mail to support@mcafee.dk, and ask for a price. I have informed them that I would write this, so they should be prepared :-)

    Dave Grasso

    We borrowed from some of the ideas already posted and appreciate the forum for sharing ideas that others can use and/or build upon.

    For our 4.5.1 Mcafee approach, we set up a PC that checks the McAfee site for updates hourly and uses the site "mirror" feature. When an update is downloaded, the Netshield and PC portions are copied up to our "distribution server," as well as to some remote sites' servers which we support. The PC was used because we needed to have passive FTP through our firewall and Netshield did not provide that in this version.

    Our local file servers have Netshield configured to look at this distribution server hourly and they update themselves if newer files are available. We staggered the installation so that all the servers would not be trying to update themselves simultaneously and to give us time to react if there was a problem with the update itself.

    For the PCs, we used McAfee's MSI creation tool to create an MSI configured with the applicable security settings (we password protect the desktop software) and to look at the distribution server randomly throughout each hour. We then used ZENworks to distribute this package, using the /s switch to silently install the software during the week. We also implemented a registry change to disable the splash screen from appearing during the update.

    The 4.5.1 package allows us to also configure the software to upgrade the engine if one is available. I believe this had to be a separate task in previous versions. We used the reporting feature of ZENworks to log installation errors so that we can easily identify and track down those PCs which appear to be having a problem with the installation.

    Like a previously posted tip, we update/upgrade hundreds of PCs and quite a few file servers within two hours of a release without anybody's intervention. We do not have an abnormal load placed on the server when an update arrives or is distributed and many times, the update is complete before we even get notice of the virus existence. The beauty is that with ZENworks and the MSI, our users do not even notice the updates happen and we no longer have to worry about it.

    Richard Brynteson

    After reading other suggestions, I thought I would share how we are updating our DAT files.

    We have one server at our central location that is setup as the main distribution server (Windows 2000 Server).

    We purchased a copy of WS_FTP. We setup NWFTPD on each of our Novell file servers to allow anonymous login to the dat file location and reject all other logins (for security reasons), except one that will copy the files to the server.

    [Note: See TID 2950579 to learn about Setting Up FTP Proxy using "WS_FTP"]

    We then point our main server at McAfee's DAT location and download the DAT's each night. Then using WS_FTP sync utility, we sync our main server FTP site with the Novell FTP servers each night.

    Since we wanted to keep our ZEN images simple and did not want to create one for each school, we point McAfee to update from a local FTP server called VIRUSUPDATE.

    We then used ZENworks to push out a host file to the workstations in each building to point to their correct server.

    This kept our workstations up-to-date. We then used the built-in McAfee utility to point our NetWare servers back at our main FTP server for updates. This kept our servers up to date.

    We have been using this for about three years now and it has been working great.

    We improved our Virus Updating productivity when we recently purchased McAfee's ePO that allows for custom reporting and centralized management of McAfee products. Very nice.

    If you have any questions you may contact Richard at richard_brynteson@rdale.k12.mn.us

    Deyan Stoykov

    If you execute mcupdate.exe with the /quiet switch, then the update is performed silently, without displaying the informational dialog window that can be disruptive to the users. If you set it to run in non-interactive or secure system mode, then nothing is displayed, however the mcupdate.exe process remains active, waiting for someone to click the "OK" button (update itself goes fine).

    We are also using the Mirror utility that comes with VirusScan 4.51 to download the new definitions and engine files automatically on a regular basis and put them into a folder on the server. Netshield on the servers and VirusScan on workstations that don't have the Novell Client installed can be updated from that location as well (via FTP). Some manipulation of the update.ini can be required sometimes (particularly the lines beginning with FilePath), however it can be automated by a Perl script set to execute automatically after each successful update.


    Ideas Involving ZENworks for Servers

    Jimmy Benson's Idea

    I'm a Network Administrator for a school system, so we need anti-virus protection, but not at the cost of leaving the system open for end user configuration. I recently setup Network Associates/McAfee's anti-virus program version 4.50. I originally began wanting to distribute the application via "silent install," but discovered I couldn't get all the options I wanted. Here's how I setup our school system, and it works GREAT!

    I used ZENworks to create a snAppShot of the installation, and all the configuration settings I wanted in place, including

    • Anti-virus configuration passwords
    • Where the client needed to obtain updates,
    • What was to happen when viruses were found on workstations, etc.

    When I installed the application I also only allowed "Administrator" equivalent users on the NT Workstation to change configuration settings within the anti-virus program when provided the correct password.

    After setting up all the schedules and client configurations, I went into the Control Panel and disabled the Virus Scan Console from starting so that students would not see those configuration settings or the Virus Scan console in the system tray on the workstation. So when students login they do not even receive the menu to enter a password for a configuration change. All they can see is what version the anti-virus is, what the latest files scanned are, and what signature update the client is running.

    I then distributed this application, and now every day the anti-virus client on the workstation goes out to the server it's been directed to and receives the updates, if there are any, and updates itself. This whole process takes less than 20 seconds so there's not a strain on the network with traffic when the update time arrives each day. This was setup during the snAppShot under the update scheduler.

    Also, I included a schedule for scanning the workstation on a daily basis, so every day at 11:00 a.m., after receiving the latest signature update at 10:00 a.m., it scans the workstation with the latest signature update! This has worked excellent for us, and we have had no problems with it.

    If we need an immediate dispersal of a signature update, then I turn back to ZENworks, where I have another application setup that is on "Force Run" to manually go into the "Network Associates" directory and replace the necessary files to update the scanner! I agree, this isn't the best method of updating by far, but it works in emergency situations.

    I also use ZENworks for Servers to disperse the signature updates to all seven of our servers that need the update. So as you can see, if the anti-virus client has the right configurations, it's pretty much a "Sit back and watch it work" scenario.

    Here's an overview of how I use ZENworks for Servers to aid in the update process. I run what I call a "CONSOLE" workstation in our office which runs McAfee's "BackWeb" product that I setup to automatically look for updates out on the web from Network Associates.

    When I see a new update come through, I download it and then place it on my "Distributor" server so it can distribute the files via ZfS. Then I go into ConsoleOne and setup the distribution to happen overnight if possible, unless the signature update contains an emergency virus signature update. In which case I go ahead and setup ZfS to distribute or "Run" immediately. When possible, however, I let it run at 2:00 in the morning, and then the next day the client will go out to the directory and update with the new signature files that ZfS placed there for me during the middle of the night.

    Totally automated! Also, on a side note, I place all my signature updates in the public directory in a zenworks\nai\updates directory, so that no special file rights need to be setup.

    If you have any questions you may contact Jimmy at JBenson@wclark.k12.in.us



    Q&A About this Article

    Q: Cheryl C.

    Cheryl C. wrote: I would like to be able to update McAfee dat files to one server then have that server administer the latest dat files to the rest of my 16 servers. Is this possible?

    A: Phil Norman

    Virus ProtectionIn response to your question about updating McAfee dat files on servers. We use a series of batches (ncf's) to do this on 26 servers, utilizing the cron.nlm and toolbox.nlm. The first thing would be to create a central location that you extract the dat files to. Then from that location have cron.nlm on each server run the ncf to copy the files using toolbox.nlm at various times based upon your infrastructure requirements. The Scripts can be very easy and straight forward.

    (VSCANUPD.NCF)
    load toolbox
    auth load sys:system/tboxauth.dat /m
    unload netshld
    delay 1000
    cp server/vol2:central\dat\*.* sys:McAfee\netshld\ /q
    load sys:McAfee\netshld\netshld /CPUHigh=50
    auth tree /d
    unload toolbox
    (CRONTAB) file
    # McAfee netshield update
    4 5 * * 1-5 vscanupd.ncf

    You will want to look at the various switches available in the toolbox to create the tboxauth.dat file and you will need to have a single login account that will need rights to the locations of the files but the documentation with toolbox seems to explain it pretty well.

    A: Anders Gustafsson

    Virus ProtectionTo Cheryl C: Yes, definitely, there are several possibilities:




    • Use ZENworks for Servers to distribute the files.
    • If you run ArcServe, you can schedule a nightly copy of files from server to server.
    • Use a combination of CRON and TOOLBOX (available from support.novell.com) or TaskMaster from Avanti-Tech to schedule a copy.

    A: James Kuhlman

    Virus ProtectionI have a simpler solution to Cheryl C.'s question.

    This function is built into NetShield for NetWare. You can define auto updates in the NetShield console.

    1. Open NetShield Console and select the server you want to 'source' DAT file updates. Once logged in select the to "Automatic DAT Update", select properties and check the "Provide update to other servers" box.
    2. In NetShield Console, connect to the server you want to receive updates, click the "Accept update from other local servers", check "Only accept update from trusted server" and browse to the server that you set to provide updates in step one. You can do this for multiple local or remote servers.
    3. Then hit the "Schedule" button and set schedule for update.

    There is no need to unload and reload NetShield with this procedure, the DAT is automatically reloaded when the scheduled upgrade takes place.

    A server can be set to both provide updates and to download from a different, trusted source. We were able to "segment" our server updates by setting a single server at multi-server WAN sites and then by offsetting the update schedule have all other servers at that site pull their update from the first server update.

    If you have an open internet connection you can pull updates directly from the McAfee FTP site. However, we haven't found this to be very reliable. I just update the primary source server and let NetShield AutoUpdate take care of the rest!

    If you have any questions you may contact James at jkuhlman@paa.pilot-ind.com


    Q: Sharon Millership

    I have just been reading your tips on installing the latest versions of McAfee/Dr Solomons VirusScan, which is particularly relevant to our site as we have just gone through this exact process. I may have missed something on your web site, but no-one seems to be mentioning snAppShot at all.

    All we did to install the superdat was run snAppShot, install the upgrade WITHOUT rebooting when prompted, and then force this to run once through ZEN ensuring that all PCs get updated.

    This ran pretty cleanly as Application Explorer was running with hardly any disruption to the user. Again we set the application object to not reboot on distribution. We found that the user could then carry on working fine in most cases, and that on the next normal reboot the version numbers would show up correctly with the new versions in the systray for the VirusScan.

    Occasionally if we were using a download scan for internet we would have problems running Netscape and it was necessary to reboot in these cases. Also - check your autoexec.bat file if you are scanning DOS on bootup as it seems to take a reboot to sort the dat files out completely and there is a line in the autoexec.bat which may prompt the user with an error until one reboot has taken place - we remmed out the pause on error line in the autoexec and distribute dthis out through the snAppShot.

    This has worked pretty well for us.

    For new extra.dat files we run a dos batch file on login to copy it to the workstation location. One thing to note which is not clear from the Network Associates web site is that you need to append extra.dat files together until the next major software release takes care of them. For example - there was an updated extra.dat for the lovebug virus which found 5 new viruses. A couple of weeks later there was an updated extra.dat for the latest Melissa virus which found 2 additional viruses. It is no good overwriting the first one with the second as this will then find only 2 additional viruses, not 7.

    We have been appending the 2 files together - they are just simple text files and we are then sure we are getting all 7 on bootup. Network Associates are probably addressing this within their engine updates, but just to be sure your extra.dat is picking up all the latest stuff this is what we have found is best to do.

    We have had more problems trying to globally change the settings within Virusscan to change what we are scanning e.g "Program Files" instead of "All Files" and so on. I would be interested if anyone has managed to do this as we have manually exported the correct registry keys and reimported them into other PCs but whatever we so we cannot change the other PCs settings without setting them manually. We are speaking to Network Associates about this but I would be interested to see any suggestions.

    A: Marcus Cooper

    This is in response to Sharon Millership's question about rolling out setting changes to Virus Scan 4.5 clients.

    Set up your machine correctly, and then run
    MSI_INST /EXPORT BACKUP.INI
    to save the settings.

    Then run
    MSI_INST /IMPORT BACKUP.INI /RESTART
    to import the settings on another machine and restart VS.

    Only problem is that you appear to need to be an administrator on the machine, so I created a policy and had it run as the system.

    It worked, which was nice.

    If you have any questions you may contact Marcus at MC@lgc.co.uk


    Q: Paul Welte

    We've been using the ZENworks starter pack and have replaced the shell on our Windows 95 workstations. When a user logs-in, he gets only the apps we assign. This is good. However, since Explorer is no longer the Windows shell, items in the startup tray (such as McAfee VirusScan) do not get executed. This is bad.

    We are now trying to use system policies associated with users and workstations. This retains Explorer as the Windows shell and allows us to run NALWIN32 via System Policies->ZAK Policies->Windows->Load.

    Here's my problem:

    If I enable System Policies->System->Restriction->Run only allowed Windows applications, I still cannot get McAfee VirusScan to execute. I've added "c:\program files\ network associates\ McAfee Virusscan\vshwin32.exe" to the List of allowed Applications. At login, the policy takes effect, but I get a restriction error saying 'This operation has been cancelled due to restrictions in effect on this computer'.

    How can I lockout undesired user-initiated program executions and still automatically run the ones required?

    A: Ron Reece

    About Paul Welte's question: In response to this, I would look to some other issue if VShield is, in fact, not running. Use the ctrl-alt-del key combo to display the programs running on your device. VSHWIN32 should be one of the listed items. If it is not I would suggest reviewing some of the restriction policies. We have been running NAL as the shell for nearly 2 years in our facilities, and have not had any issues with VShield or the updates.



    Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

    © 2014 Novell