In response to a recent question via this blog, I’d like to explain a setting for antimalware scanning in Forefront Client Security that you can configure via a registry key.
FCS scans removable drives at certain times. When you insert a removable drive, the boot sector of that drive is scanned. After that, when you access a file on a removable drive, it's scanned. When you run a full scan, removable drives are not scanned.
There is a registry key that can control this, however. You can change/add the registry key with either a .reg file or via a custom ADM, as described in the More Information section of KB 971026 (http://support.microsoft.com/default.aspx/kb/971026).
The registry key that must be changed is the Forefront Client Security policy key. The key name is DisableRemovableDriveScanning, and has two possible settings:
· Missing or 1: removable drives are not included in full scans
· 0 (zero): removable drives are scanned in full scans
Permissions on this key prevent direct editing, so you must use one of the two methods described in the KB article referenced above.
For the ADM file, start Notepad, and then copy and paste the following text into the Notepad file:
KEYNAME "SOFTWARE\Policies\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Scan"
;; Note that instead of disabling a disable we flip-flop the logic to make it proactive
VALUEON NUMERIC 0
VALUEOFF NUMERIC 1
FCSCategory="Microsoft Forefront Client Security"
RemovableDriveScanning_Name="Enabling removable drive scanning"
RemovableDriveScanning_Explain="This setting instructs the FCS antimalware client to scan removable drives during full scans"
Save the file as an ADM file, making sure to choose All files *.* as the file type (the KB suggests saving it with the KB ID number – for this one, you could use RemovableDrive.ADM as the file name), and then use Group Policy to deploy the new setting, as described in Option 1, step 2, in the KB article.
If you want to deploy the DisableRemovableDriveScanning key via a .reg file, follow the steps described in Option 2 in the KB article, substituting the following registry information for step 4:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Scan]
And what the various files in the update do? And what the different types of udpates are?
If you're reading this, I bet you have. And our friends over on the CSS team have authored a KB article (977939) that answers all those questions. You can find the article here: http://support.microsoft.com/?id=977939
We’re tracking an issue where the latest FCS antimalware client update won’t install on Windows 2000 when the installation is run as Local System (i.e. Automatic Updates installing at 3am).
When this issue occurs, the update uninstalls the previous version of the antimalware client, and then tries to install the new version and fails, leaving the system without the antimalware service.
Workarounds are to decline the updates (976669 is the FCS slipstream client) and make sure that the previous FCS antimalware updates are approved (971026 and original FCS client), or run the install interactively as a logged on user.
Again, this only affects Windows 2000 when the updates are installing non-interactively as the Local System account (via Microsoft Update, WSUS, SMS, or Configuration Manager)
As an interim fix, we’re working to change the detection logic on Microsoft Update and WSUS so that the update isn’t offered to Windows 2000 systems, and will post an update when we have a more permanent fix to the problem.
Last month in the Client Security blog the Forefront Client Security team announced the availability of a revised installation package, which is available via WSUS. More information about the new installation package is found in Microsoft Knowledge Base article 976669. In that article I wrote a section called WSUS Applicability Logic, which briefly discusses how and when the new package is installed. The English version of the article contains the following:
The policy contains certain registry values which are used in applicability. Additionally, when clientsetup.exe runs the settings will determine the Collection server to which the client reports.
The second sentence above has generated some additional questions, so let me provide a bit more detail.
The new update package referenced in KB976669 is a slipstream installation; it contains the latest updates for the Forefront Client Security client so that new agents do not need to be installed, and then subsequently updated. If you have existing Client Security clients, just apply the updates referenced in KB97669, for example KB976668. If you are not installing new clients through WSUS and you would like to create a slipstream installation, use the steps in our previous blog entry with these same updates. If you use WSUS to install new clients, the steps are:
When the client computer does its next Automatic Updates detection cycle (frequency defined in #1 above) it will deem the deployment package as "Applicable", as described in the KB. It will then either notify, download and notify, or download and schedule the package to be installed (again, behavior set via the policy set in #1 above).
When the package installation is triggered, clientsetup.exe runs with zero command line switches. In the absence of /CG & /MS switches, clientsetup.exe will look in the registry for MOMServerName and MOMGroupName, which were set via policy. clientsetup.exe then uses those values, instead of the switches, to configure the new MOM agent to send information to the correct Collection server, specified in MOMServerName.
Note: the registry keys are only read by clientsetup.exe. Changing the policy by re-running the configuration wizard and redeploying policy does not redirect clients to report to a new Collection server. To do this you must choose one of the steps described in this blog entry.
Thanks, Craig Wiand Forefront Escalation Engineer
Happy New Year!
Kurt Falde, one of our CSS Support Engineers, posted a great blog post about how to parse FCS logs to discover the names of the infected files.
The post can be found on Kurt's blog, Stuff n Things (http://blogs.technet.com/kfalde/archive/2009/12/22/logparsing-fcs-to-find-files-that-were-infected.aspx).
Happy reading, and thanks Kurt!!