Client Security slow logon issue

craigw — Thu, 13 Aug 2009 19:43:31 GMT

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.

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

Changes to FCS Client WSUS Installation package

craigw — Sat, 06 Oct 2007 01:12:00 GMT

Using WSUS is likely the easiest and most popular way to deploy the FCS client to computers. As described in the deployment guide, after deploying FCS policy and approving the package Client Update for Microsoft Forefront Client Security (1.0.1703.0) on your WSUS 2.0 or 3.0 server, the FCS client is downloaded and installed on the machine according to your company’s Windows Update policy.

The FCS package has the ability to detect the language of the machine contacting the WSUS server and install the same FCS language; for example if you have a French Vista machine you will receive French FCS, or a Japanese Windows Server 2003 server you will receive Japanese FCS. This works great for the languages that FCS was localized to, but what about the other Windows languages?

The FCS team received great feedback from its customers using non-FCS localized Windows languages who also wanted to take advantage of the easy deployment through WSUS. In response to that feedback, the FCS team has made changes to the FCS client WSUS installation package to support installing English FCS on those machines running a non-FCS localized Windows language (for example Swedish, Russian, or Finnish). The exceptions to this are Arabic and Hebrew; the package will not be offered to those because of known issues with the FCS client on those bi-directional languages.

Support for WSUS FCS client deployment for these additional languages should be a great benefit for customers in many parts of the world. Additional technical documentation on the update will be provided in future TechNet documentation or a knowledge base article, and will include:

· WSUS deployment still requires that FCS policy is already deployed

· For non-FCS localized Windows languages, the new installation package does not automatically install the required KB914882 update on x86 Windows XP SP2. Therefore, prior to WSUS deployment you must deploy the correct OS language version of update (found in the \client directory of the FCS CD media) to XP machines. No additional work is required for other operating systems.

Re-approval Required

The original client installation package was changed to include detection for these additional languages. During this process, a new update package was released and the old package was expired. For this reason, you may notice on your WSUS server that the previous update package is either no longer shown or shows as expired (depending on your view). You may also see the current package is shown as “Not Approved”. This is because the Forefront Client Security distribution server role creates an auto-approval rule for the Definition Updates WSUS classification; however the client installation package has a classification of Updates. Therefore, when the new package is downloaded it will not be automatically approved unless your WSUS administrator has created an auto-approval rule for Updates as well. This should not affect FCS definition updates and can be easily returned to its previous state by manually approving the new package Client Update for Microsoft Forefront Client Security (1.0.1703.0) on your WSUS 2.0 or 3.0 server (dated Wednesday, October 03, 2007).

Best of luck and happy deployments.

Craig Wiand
Microsoft Forefront Client Security Support

Forefront Client Security Team Blog : Client Security Agent

Client Security slow logon issue

Changes to FCS Client WSUS Installation package

Re-approval Required