We use McAfee VirusScan Enterprise 7.1.0 on our network, along with the McAfee ProtectionPilot centralized management tool. The ProtectionPilot console typically notifies us when the client software is out of date, but I've found that sometimes the console doesn't detect update failures. Is there an easy way to determine whether a client machine's VirusScan software has been updated?
Periodically checking to make sure that your antivirus-management system is updating machines as it should be is always a good idea. (Ethan Wilansky discusses a similar situation involving Symantec Norton Antivirus in "Identifying Software's Presence and Configuration Details," May 2005, InstantDoc ID 45820.)
McAfee VirusScan Enterprise 7.1.0 stores current antivirus definitions (aka DAT files) in the szVirDefVer entry (type REG_SZ) of the HKEY_LOCAL_MACHINE\SOFTWARE\NetworkAssociates\TVD\VirusScanEnterprise\CurrentVersion registry subkey. The WshShell object provides the RegRead method, which you can use to explore registry entries, but the method works only on the local system.
To retrieve registry data from a remote system, you can use the Windows Management Instrumentation (WMI) StdRegProv class. Listing 1, GetDATVersion1.vbs, shows a simple script that uses WMI to retrieve the szVirDefVer value from the computer that you specify on the command line when you run the script.
The code at callout A in Listing 1 connects to the StdRegProv class on the specified computer. If the WMI connection fails, the script displays an error message and exits. The code at callout B uses the GetStringValue( ) method to retrieve the szVirDefVer value from the appropriate registry subkey and stores the registry data in the DATVersion variable.
If you want a technique that doesn't involve so much code, you might want to use the Penton.Reg-Object object. (I document this object's use in the article "Registry Reading and Writing Made Simple, Part 1," October 2005, InstantDoc ID 47540.) This object is easier to use than the WMI StdRegProv method and lets you write code that's shorter and easier to read. To use the Penton.RegObject object, you must register the RegObject.wsc file. (See "Registry Reading and Writing Made Simple, Part 2," November 2005, InstantDoc ID 47736, for information about how to register and unregister the component on your computer.) Note that if you work in a restricted security environment that doesn't let you install script components, the Penton.RegObject object might not be a viable option. In such situations, use the script in Listing 1.
Listing 2, GetDATVersion2.vbs, performs the same job as GetDATVersion1.vbs in Listing 1 but uses the Penton.RegObject object. (The script GetDATVersion3.js contains the equivalent JScript code and appears in Web Listing 1. You can find all these scripts on the Windows Scripting Solutions Web site. Go to http://www.windowsitpro.com/windowsscripting, enter 49042 in the InstantDoc ID text box, then click the 49042.zip hotlink.) The code at callout A in Listing 2 creates the Penton.RegObject object, connects to the computer, and aborts the script with an error message if the connection fails. The code at callout B uses the Penton.RegObject object's ReadValue( ) method to retrieve the szVirDefVer value from the registry. The Read-Value( ) method returns 0 when this action is successful. The code at callout C retrieves the data by reading the Penton.RegObject object's Result property.
You can use any of these three scripts (keeping in mind the Reg-Object.wsc dependency of GetDATVersion2.vbs and GetDATVersion2.js) in conjunction with a shell script (i.e., batch file) to retrieve the DAT file versions for multiple computers. Cmd .exe's For command simplifies the process. Listing 3, GetDATVersions .cmd, illustrates the technique. For this script to work, you must create a text file, computers.txt, that contains the computer names. List one computer name per line, and place the file in the same directory as GetDATVersion1.vbs and GetDATVersions.cmd. Figure 1 shows a sample computers.txt file. GetDATVersions.cmd reads computers.txt by using the For /f command and passes each line as a command-line argument to GetDATVersion1.vbs. Note that GetDATVersions.cmd uses the CScript //Nologo command to run GetDATVersion1.vbs, in case WScript is the default host. (The //Nologo command suppresses the Windows Script Host—WSH—copyright message.) If you want to redirect the GetDATVersions.cmd output to another file, the script can create a tab-delimited text file. For example, the command
GetDATVersions > DATVersions.tsv
creates a text file named DATVersions.tsv, which you can import into a spreadsheet application for easy viewing.
If the script fails to connect to remote Windows XP Service Pack 2 (SP2) systems, Windows Firewall might be blocking the connection. You can either disable the firewall or configure it to pass WMI connections. See the Microsoft article "Connecting Through Windows Firewall" (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmisdk/wmi/connecting_through_windows_firewall.asp) for information about how to allow the connections.