Welcome to TechNet Blogs Sign in | Join | Help

Scanning reparse points

Next in our series: how to enable scanning of reparse points, also known as junctions, or mount points.

 

(For more information about what exactly reparse points, junctions and mount points are, see http://msdn.microsoft.com/en-us/library/aa365006(VS.85).aspx and http://msdn.microsoft.com/en-us/library/aa365503(VS.85).aspx)  

 

Out of box, FCS does not scan reparse points. However, there is a registry key that you can add to your environment to control this behavior. As in the first post of this series (http://blogs.technet.com/clientsecurity/archive/2010/01/29/scanning-removable-drives.aspx), you must use either an ADM file via Group Policy or a .reg file to add the key.

 

Some important notes about this setting:

·         The FCS custom scan interface honors this setting. That is, if you have added this key, and have it set to 1 (or the setting is missing), then the custom scan interface does not even display the mount points.

 

·         You should test this setting before deploying it in your organization. It is possible to have junctions that link back to themselves – in a circular fashion. If you have such in your environment, you may see scans that never finish, or never complete successfully, after enabling this setting.

 

The key name is DisableReparsePointScanning, and has two possible settings:

 

·         Missing or 1: Reparse points are not included in full scans.

·         0 (zero): Reparse points are included in full scans.

 

For the ADM file, start Notepad, and then copy and paste the following text into the Notepad file:

 

CLASS MACHINE

CATEGORY !!FCSCategory

              POLICY !!ReparsePointScanning_Name

                     KEYNAME "SOFTWARE\Policies\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Scan"

                     EXPLAIN !!ReparsePointScanning_Explain

                     ;; Note that instead of disabling a disable we flip-flop the logic to make it proactive

                     VALUENAME DisableReparsePointScanning

                       VALUEON NUMERIC 0

                       VALUEOFF NUMERIC 1

               END POLICY

END CATEGORY

 

 

[strings]

FCSCategory="Microsoft FCS Reparse Point Scanning"

ReparsePointScanning_Name="Enable reparse point scanning"

ReparsePointScanning_Explain="This setting instructs the FCS antimalware client to scan reparse points 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 ReparsePoint.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 DisableReparsePointScanning 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]

"DisableReparsePointScanning"=dword:0
Posted by kimborly | 0 Comments

Scanning removable drives

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:

 

CLASS MACHINE

CATEGORY !!FCSCategory

              POLICY !!RemovableDriveScanning_Name

                     KEYNAME "SOFTWARE\Policies\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Scan"

                     EXPLAIN !!RemovableDriveScanning_Explain

                     ;; Note that instead of disabling a disable we flip-flop the logic to make it proactive

                     VALUENAME DisableRemovableDriveScanning

                       VALUEON NUMERIC 0

                       VALUEOFF NUMERIC 1

               END POLICY

END CATEGORY

 

 

[strings]

FCSCategory="Microsoft FCS Scan Override"

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]

"DisableRemovableDriveScanning"=dword:0

Posted by kimborly | 0 Comments

Ever wonder what's in a definition update?

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

Happy reading!

Posted by kimborly | 3 Comments

FCS KB 976668 and 976669 fail to install on Windows 2000 when the installation is run as Local System

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 SCCM)

 

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.

 

 

Posted by kimborly | 2 Comments

Setting the Collection server during WSUS deployment

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:

  1. Associate the client computer to a WSUS server via WSUS policy, details here
  2. Create and deploy policy from the management server, details here
      a. All Client Security policies contain two registry keys: MOMServerName and MOMGroupName
      b. These values are set in the registry on the management server when the Configuration Wizard is run on the Management console. They are read and added to each policy during policy creation on the management server.
  3. Apply policy to clients; this can be either normally via AD policy or local policy imported with fcslocalpolicytool (tool found on CD media)
      a. When policy is applied, the local computer receives the MOMServerName and MOMGroupName described in #2a above.
  4. Approve the 1725.0 package described in KB976669 in WSUS

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

Posted by craigw | 0 Comments

Logparsing FCS to find files that were infected

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!!

Posted by kimborly | 0 Comments

New Update Available

 
Greetings! Yesterday we released a new hotfix  - this hotfix provides the following benefits:
 
  • Adds support for running the FCS client on Windows Server 2008 R2 Core
  • Addresses a few issues you may have experienced with Forefront Client Security when running FCS on Windows Server 2008 R2 or Windows 7
  • Addresses issues found on other operating systems supported by FCS
To see the fixes included in this hotfix, and to obtain the hotfix, see Microsoft Knowledge Base article 976668 (http://support.microsoft.com/kb/976668).
 
There is also a revised installation package available for new installations of the FCS client. This update is only available via Window Server Update Services (WSUS). For information about the new installation package, see Microsoft Knowledge Base article 976669 (http://support.microsoft.com/kb/976669).
 
Thanks!
Posted by kimborly | 2 Comments

FCSv1: In place OS upgrades from Win2k8 Core to Win2k8 R2 Core has an upgrade issue

Issue:  

Upgrade or uninstallation of Forefront Client Security (FCS) v1 is not possible, after an in place upgrade of Windows Server 2008 Core to Windows Server 2008 R2 Core.

 

Cause: 

The Antimalware MSI’s used to install the AM engine for FCS use an application installer known as DFXAPP.   The version of the installer used in the original FCS media and in subsequent updates to the AM MSI (QFE2, QFE4, QFE5, QFE6) has a hard coded version block that prevents this installer from running on Windows 7 and Windows Server 2008 R2.    In most cases, there is an application compatibility ‘shim ‘ that works around this issue and allows the installation to succeed.   However, this application compatibility infrastructure is not installed or supported on Windows Server 2008 R2 Core  - and an installation error happens.

 

The scenario of concern is if:

 

·         A customer has already installed FCSv1 on Windows Server 2008 Core;

·         Then upgrades the operating system to Windows Server 2008 R2 Core,

 

The following is the result:

 

·         You cannot uninstall FCSv1.  (due to the lack of the DFXAPP infrastructure)

·         You cannot upgrade the Antimalware QFE to future release.   This because the upgrade occurs by performing an uninstall of the current Antimalware QFE. (again due to the lack of the DFXAPP infrastructure)

 

 

The specific error seen in the Antimalware log (FCSAM.log):

 

MSI (s) (CC:E0) [20:43:51:595]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI18B5.tmp, Entrypoint: ProcessDriverPackages Action start 20:43:51: MsiProcessDrivers.

DIFXAPP: ENTER: ProcessDriverPackages()

DIFXAPP: ERROR - The operating system you are running on is not supported. Only Windows 2000, Windows XP, Windows Server 2003 and Windows codenamed Longhorn are supported.

 

Solution:

There are several workarounds that exist, but are very time consuming and error prone.   We are working to create a simpler workaround that can be distributed to affected customers.  If you find yourself in this situation, please open a case with your CSS representative via http://support.microsoft.com

 

Forefront Client Security v1.0 on Windows 7 and Windows Server 2008 R2

Greetings!

 

You may have seen this by now, but I wanted to reiterate here:

 

Forefront Client Security (FCS) v1.0 is fully supported on Windows 7 and Windows Server 2008 R2 as of August 31, 2009. 

 

With the release of new updates available through Windows Server Update Services (WSUS) or Microsoft Update, you'll be able to extend the protection of FCS v1.0 on Windows 7 and Windows Server 2008 R2 systems and incorporate security in their infrastructure upgrade plans.  More information on updates needed for this support is provided in a knowledge base article here.

 

FCS v1.0 will be supported on all of the following versions of Windows 7:  Windows 7 Business, Enterprise, Home, and Ultimate.  FCS v1.0 will also be supported on Windows Server 2008 R2 Standard Server and Windows Server 2008 R2 Enterprise Server installation.  For a full list of supported platforms, please visit http://technet.microsoft.com/en-us/library/bb404245.aspx

 

Windows Server 2008 R2 Server Core installation is not supported at this time. However, it is planned to be supported with future updates.

Posted by kimborly | 0 Comments
Filed under:

Client Security slow logon issue

After installing the most recent antimalware update (KB971026), some Client Security customers have reported that their managed Windows XP SP2 and SP3 clients take longer to logon after a reboot. Our support and sustained engineering teams have researched this issue and wanted to provide additional information and workarounds.

Cause

During the initialization of the antimalware service, FCS does the following:

1. Loads the kernel-mode mini-filter(mpfilter.sys) and starts filtering

2. Sets up communication port

3. Creates Engine configuration <-- delay occurs here

4. Creates On-Access worker threads

The problem arises when there is a delay in Step#3. In this situation the mini-filter begins filtering file I/O requests but there are no On-Access worker threads available yet to service the scanning requests. We have found that these delays typically come from network-based file exclusions being set via the Advanced Policy tab in the Client Security management console.

policy_Exclusions

The delays occurs when the client receives the UNC paths (e.g. \\server\share) and they are converted to a device name that the mini-filter uses. During this conversion the FCS client accesses the path in the exclusion. Slow or ACCESS_DENIED responses to these network requests increases the time in Step#3 above and causes delays before the mini-filter requests can be handled (Step#4).

The result is that the file I/O in other processes, including those responsible for logon like Winlogon.exe, is queued until all the network requests for exclusions complete or for the duration of the mini-filter timeout. This issue became more visible in the most recent antimalware update (KB971026) because the mini-filter timeout was increased.

Workarounds

While Microsoft determines the long term solution to this problem, there is a recommended workaround: eliminate network-based file exclusions.

In most causes these exclusions were created to address the issue described in KB939361. This issue can now be corrected by using the DisableScanningNetworkFiles policy setting described in KB971026. Therefore, if you implement the DisableScanningNetworkFiles, you should be able to remove any network-based file exclusions from your Client Security policy settings (screenshot above). This should eliminate the device conversion delay and allow logons to complete in a more timely manner.

 

We will update this blog when more information about this issue is available.

Thanks,
Craig Wiand
Forefront Escalation Engineer

Posted by craigw | 0 Comments

TechEd 2009

Hey folks – we’ve got an exciting line up of sessions about FCS and Stirling that you will want to add to your TechEd schedule – come see the product group talk about our new exciting features!

I’ve listed all the sessions available for all Forefront products below. Come visit us at the product booths for more details, and to speak with the product group members!

Session number

Session title

Scheduled speakers

SIA204

Security Management and Protection: What's in Microsoft Forefront Client Security Version 2

Bashar Kachachi and Neha Sharma

SIA318

Protection: Next Generation of Messaging and Collaboration Protection

Mitch Hall and Mike Chan

SIA319

Protection: Targeting Spam with Forefront

John Gargiulo and Terry Zink

SIA321

Security Management: Integrated Enterprise Security with Microsoft Forefront Code Name "Stirling"

Chris Sfanos and Eric Fitzgerald

SIA01-TLC

Next Generation Messaging and Collaboration Protection Drilldown

Mike Chan/Mitch Hall/Terry Zink/John Gargiulo

SIA02-TLC

Advanced Deployment of Microsoft Forefront Code Name "Stirling"

Chris Sfanos and Neha Sharma

 

We’ve also got Hands on Labs (HOL) available for you to work with the Forefront products while you are at TechEd:

HOL number

HOL title

SIA11-HOL

Overview of Microsoft Forefront Code Name "Stirling" (Beta)

SIA12-HOL

Overview of Microsoft Forefront Unified Access Gateway

SIA13-HOL

Protecting Microsoft Exchange Server 2007 Against Malware and Spam with the Next Generation of Microsoft Forefront Security for Exchange Server (Beta)

SIA14-HOL

Protecting Against Malware and Inappropriate Content with the Next Generation of Microsoft Forefront Security for SharePoint (Beta)

 

Hope to see you there!

Posted by kimborly | 2 Comments

FCSNerds at it again...

Hello folks!

I'm happy to share with you another wonderful post from our friends over at the FCS CSS Support team (FCSNerds). CraigW just posted some directions on how to slipstream a Client Security engine update into your SCCM or script-based initial Client Security client deployment, so that you are deploying the most up to date engine.

Take a look: http://blogs.technet.com/fcsnerds/archive/2009/04/01/slipstreaming-a-client-security-client-installation.aspx.

Happy reading and deploying!

 

 

Posted by kimborly | 0 Comments

More resources.....

Hello FCS experts!

 

I'd like to introduce you to Kurt Falde's blog. Kurt is a CSS Security Engineer, and has some fantastic info, tips and tricks for FCS use and support.

 

Take a look - I think you'll find some great information....

 

Thanks!

Posted by kimborly | 1 Comments

Tamper protection from the Security Wizard

Howdy everyone! Just wanted to post a quick Yay!! For Yaniv! – Yaniv once again has posted some great information about enhancing your Client Security environment. Please take a minute to read his post (http://blogs.microsoft.co.il/blogs/yanivf/archive/2009/01/09/temper-protection-in-forefront-client-security.aspx).

 

In his words:

"Every Anti-Virus has a mechanism called tamper protection that helps administrator keep users from mishandling there antivirus settings and services. Forefront Client Security only offers basic control over what the user can or cannot do with the FCS Client Console on his client machine. What the FCS System doesn’t provide is a built-in mechanism to protect FCS services from being stopped or prevent FCS from being removed by the user…."

Go read the rest of his post. Really. You’ll like it. And you’ll be glad you did.

Posted by kimborly | 0 Comments

Client pods…..

The FCS Nerds have a great blog post describing how to relocate an FCS client to a new management group, or “pod”.

You can find the post here. Happy reading!

Posted by kimborly | 2 Comments
More Posts Next page »
 
Page view tracker