Forefront Client Security Support Blog

Ever wonder about what FCS clients are actually downloading when they update?   Have you clicked on “File Information” option in WSUS or downloaded a package from the Microsoft Update catalog, seen a long list of update files, and questioned what they were?

For answers to these questions and more see:  http://support.microsoft.com/?id=977939

Thanks,
Craig Wiand
Microsoft Forefront Escalation Engineer

Back in October, the Forefront Client Security product team made an announcement that WSUS 3.0 on 64bit OS would be a supported scenario and to not install the Distribution component on 64bit Operating systems.

"Also, we are announcing support for definition distribution via WSUS 3.0 installed on an x64-based platform. To support this configuration, the FCS distribution component must not be installed on the x64-based WSUS 3.0 server, as WSUS 3.0 does not require the installation of the FCS distribution component. Existing FCS documentation will be updated accordingly"

http://blogs.technet.com/clientsecurity/archive/2008/10/20/sccm-and-wsus-announcements.aspx

This announcement and WSUS 2.0 officially reaching end of life and no longer being supported have generated numerous questions on the distribution component. Is it still required to be installed on 32bit Operating systems now that all installs of FCS are on WSUS 3.0 or later? I wanted to take a minute and explain the purpose of the distribution component and if it is still required.

Forefront Client Security v1 was designed to take advantage of the WSUS 2.0 infrastructure to distribute the FCS anti-malware client and signature updates. The one drawback to this design was that WSUS 2.0 only synchronized updates once a day. With a goal of publishing definition updates approximately every 8 hours at a minimum, there needed to be a method of having WSUS 2.0 checking for updates multiple times a day. If nothing was done to change the synchronization behavior of WSUS 2.0, a FCS anti-malware client using that WSUS server for updates may not have the latest definition updates which would leave it at an increased risk of infection.

The Distribution component was released with Forefront Client Security v1 and was designed to address the issue of synchronizing updates multiple times in one day on WSUS 2.0. In addition, the Distribution component accomplished the three following tasks:

• Adds the Forefront Client Security product to the list of products synchronized
• Adds Definition Updates to the category of updates synchronized
• Creates an Auto-Approve rule for “All Computer” for Definition Updates

With the release of WSUS 3.0 the ability to configure how often the server synchronizes the available updates (http://technet.microsoft.com/en-us/library/cc708616(WS.10).aspx) was included in the product. This removes the key reason for the distribution component. It can still be used but is no longer required on WSUS 3.0 or later to keep the server up-to-date.

When deploying WSUS 3.0 or later if you do not install the Distribution component you will need to accomplish the following tasks to receive the FCS Product and Anti-malware definition updates:

· Change the synchronization frequency to greater than once daily

· Add Forefront Client Security to the list of products to synchronize

http://technet.microsoft.com/en-us/library/cc708616(WS.10).aspx

· Add Definition Updates to the classifications of updates to be synchronized

· Create the Auto-Approval for the FCS and definition Updates.

* Because of Eula's On Client updates you may still have to manually approve certain non-definition updates.

http://technet.microsoft.com/en-us/library/cc708474(WS.10).aspx

Thanks and have a great Day,

Chris Norman
Senior Support Engineer

Yesterday Microsoft released KB971026 which is an update to the FCS Antimalware engine.  This update installs successfully without issues.  However, after this update is applied, the initial FCS Client package called "Client Update for Microsoft Forefront Client Security (1.0.1703.0)" on the WSUS server would then be offered to the system.  If the Client Update for Microsoft Forefront Client Security (1.0.1703.0) package attempted to install, it would fail as there is already a later version of the FCS Antimalware engine on the system.  The Client Update for Microsoft Forefront Client Security (1.0.1703.0) package would then be continually offered and continually fail to install.

This issue has been resolved with an update to the metadata for the Client Update for Microsoft Forefront Client Security (1.0.1703.0) package.  There was never an issue with KB971026, it did however expose an issue with the Client Update for Microsoft Forefront Client Security (1.0.1703.0) package.

In order to apply this fix. Please perform the following -

1.  Customers will need to sync their WSUS servers to get the updated metadata.

2.  The affected systems will need to have a detection cycle run on the clients in order for the package to stop continually being offered.  Please note that the detection cycle will happen automatically within 24 hours or less depending on the automatic updates settings for detection frequency that are set via the policy.

If you have any questions, please feel free to post them.

Thanks,

Shain Wray

Security Technical Lead

A catch-up scan is a scan that is initiated because a regularly scheduled Forefront Client Security antimalware scan was missed.  Usually these scheduled scans are missed because the computer was turned off at the scheduled time.  The FCS documentation at http://technet.microsoft.com/en-us/library/bb418896.aspx states:

Scheduled malware scans enable you to choose the time of day when the Client Security agent on each managed computer begins a scan. This enables you to select a time that is likely to have minimal impact on users. You can also configure whether a scheduled scan is a full scan or a quick scan. If a client computer is offline for two consecutive scheduled scans, Client Security starts a scan the next time someone logs on to the computer. For more information, see Configuring scheduled and interval malware scans.

To expand on this, scans can be scheduled to run either daily or weekly and either full or quick scans.  If there is no scheduled scan configured, there will be no catch-up scan run.  If the scheduled scan is configured for daily, then after two days of being missed the next time the antimalware service starts, after a short delay of about ten to twenty minutes, the missed scheduled scan will be run.  The scan type will be based upon the scan type of the scheduled scan:  if a full scan is scheduled the catch-up scan will be a full, if the scheduled scan is a quick scan the catch-up scan will also be a quick.  If the scan is configured for weekly, then after missing the scan two consecutive weeks the next time the antimalware service starts, after a short delay of about ten minutes, the missed scheduled scan will be run.  The number scans missed(two) before the catch-up scan is invoked is non-configurable.

In the current version, the Forefront Client Security antimalware client differentiates scans initiated through the UI from scans initiated through the command line of scheduled tasks.  Scans invoked through the antimalware UI do not count as “scheduled” and cannot can be used to avoid catch-up scans.  The only exception to this is if a computer has never run a scheduled scan; this helps prevent prevent newly installed clients from running a catch-up scan when they receive policy.

If you miss a scheduled scan and want to run your own catch-up scan so it will run at a convenient time, you should invoke the scan through the command line:

“%programfiles%\Microsoft Forefront\Client Security\Client\antimalware\mpcmdrun.exe” –Scan

Additionally, catch-up scans are only applicable to scans that are scheduled for a particular time, they do not apply to interval-based scans as shown below

An interval scan is essentially just a timer that starts roughly when the service starts.  If the computer is rebooted, the service is restarted, or the scan interval changes the timer is reset.

By default catch-up scans will be enabled. If you do not wish to run catch-up scans you may use an ADM file and set the following registry key  HKEY_LOCAL_MACHINE\ SOFTWARE\Policies\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Scan – DisableCatchUpScan .  You can cut-and-paste the below example into a text file and rename it to an ADM to test this:

CLASS MACHINE
CATEGORY !!FCSCategory
          POLICY !!CatchUp_Name
                   KEYNAME "SOFTWARE\Policies\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Scan"

                   EXPLAIN !!CatchUp_Explain
                   VALUENAME DisableCatchupScan
                     VALUEON NUMERIC 1
                     VALUEOFF NUMERIC 0
          END POLICY
END CATEGORY
[strings]
FCSCategory="Microsoft FCS Scan Override"
CatchUp_Name="Disable Catch-up Scan"
CatchUp_Explain="This setting instructs the FCS antimalware client not to re-attempt a missed scan"

Thanks,
Craig Wiand
Microsoft Forefront Escalation Engineer

During evaluation of the Forefront Client Security antimalware protection many customers will review the information provided by independent antimalware testers such as

• http://www.av-test.org/
• http://www.virusbtn.com/
• http://www.av-comparatives.org/

(When reading these sites, note that Microsoft’s Forefront Client Security and OneCare products use the same malware protection engine and definitions)

Other customers may want to test FCS detection capabilities against their own private malware library. Doing this with a large library can present somewhat of a challenge because the user interface can becoming quite filled and slow to respond when filled with thousands of entries. Alternatively, you might try to examine the event log for 3004 events(real-time protection detected threats) and/or 1006 events (scan detected threats).

The problem with both the user interface and the event log query is that FCS will consolidate threats of the same type into a single infection report. Therefore, if you have 5,000 sample files but only 4,500 are unique (e.g. you have multiple EICARs or multiple RBOTs.gens) then you will get a maximum of 4,000 detection events or items in the UI. Why does FCS do this aggregation? It is done because in a typical “real-world environment” administrators will act on malware as a whole rather than have different actions for different instances, components, or files of a malware threat. It also ensures removal is done properly and threats are not only partially addressed.

To illustrate this behavior, I used a single copy of EICAR and nine of the different SpyCar samples in a test with FCS. So although I have 10 total files, FCS shows the following:

Notice that FCS says that only 2 items were detected. To a casual reviewer unfamiliar with the FCS behavior described above this would leave the impression that FCS only detected 20% of the files. While it is easy to understand what is happening in this trivial example, it is more difficult in a larger library.

By investigating the detection further, and scrolling down, we can see that the files for each threat are listed as resources:

This is also true of the event log entries:

Log Name: System
Source: FCSAM
Date: 4/15/2009 3:36:21 PM
Event ID: 1006
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: computer.microsoft.com
Description:

Microsoft Forefront Client Security scan has detected spyware or other potentially unwanted software.

For more information please see the following:

http://go.microsoft.com/fwlink/?linkid=37020&name=Tool:Win32/SpycarTestSuite&threatid=17424

Scan ID: {FF8CDDEA-1CE8-4644-97FB-55C5C36329C9}
Scan Type: AntiMalware
Scan Parameters: Custom Scan
User: DOMAIN\craigw
Name: Tool:Win32/SpycarTestSuite
ID: 17424
Severity: Severe
Category: Tool
Path Found: file:C:\fcstest\IE-SetSearchPage.exe;file:C:\fcstest\IE-SetHomePage.exe;file:C:\fcstest\IE-KillAdvancedTab.exe;file:C:\fcstest\IE-HomePageLock.exe;file:C:\fcstest\HKLM_RunOnceEx.exe;file:C:\fcstest\HKLM_RunOnce.exe; file:C:\fcstest\HKLM_Run.exe;file:C:\fcstest\HKCU_Run.exe;file:C:\fcstest\AlterHostsFile.exe
Detection Type: Concrete

So to properly determine the number of files (not different threats) you would need to find each detection and count the number of file based resources associated with it. This is clearly a challenging undertaking for a large malware library. It can be helped somewhat by leveraging the MpLog-xxx-xxx.log file found in the %ALLUSERSPROFILE%\Application Data\microsoft\Microsoft Forefront\Client Security\Client\Antimalware\Support directory. It will list the total number of threats found, and then the count of resources for each threat:

Product Version: 1.5.1958.0
Engine Version: 1.1.4502.0
AS Signature Version: 1.55.1678.0
AV Signature Version: 1.55.1678.0
************************************************************
Begin Resource Scan
Scan ID:{FF8CDDEA-1CE8-4644-97FB-55C5C36329C9}
Scan Source:1
Start Time:Wed Apr 15 2009 15:35:30
End Time:Wed Apr 15 2009 15:36:21
Explicit resource to scan
Resource Schema:folder
Resource Path:@S-1-5-21-124525095-708259637-1543119021-1851\C:\fcstest\
Threat Count:2

Threat Name:Tool:Win32/SpycarTestSuite
ID:17424\
Severity:5
Number of Resources:9
Resource Schema:file
Resource Path:C:\fcstest\IE-SetSearchPage.exe
SigSeq:37829992017238
Resource Schema:file
Resource Path:C:\fcstest\IE-SetHomePage.exe
SigSeq:37827904169718
Resource Schema:file
Resource Path:C:\fcstest\IE-KillAdvancedTab.exe
SigSeq:37829556567249
Resource Schema:file
Resource Path:C:\fcstest\IE-HomePageLock.exe
SigSeq:37827406791016
Resource Schema:file
Resource Path:C:\fcstest\HKLM_RunOnceEx.exe
SigSeq:37828071703283
Resource Schema:file
Resource Path:C:\fcstest\HKLM_RunOnce.exe
SigSeq:37829705680185
Resource Schema:file
Resource Path:C:\fcstest\HKLM_Run.exe
SigSeq:37827006632665
Resource Schema:file
Resource Path:C:\fcstest\HKCU_Run.exe
SigSeq:37825853825063
Resource Schema:file
Resource Path:C:\fcstest\AlterHostsFile.exe
SigSeq:37826058080799

Threat Name:Virus:DOS/EICAR_Test_File
ID:2147519003
Severity:5
Number of Resources:1
Resource Schema:file
Resource Path:C:\fcstest\eicar.com
SigSeq:5866324352432
End Scan
************************************************************

When we sum up the detected resources we see that FCS did indeed detect all 10 files.

Another testing approach would be to set all of the default actions to remove via the FCS client Tools > Options UI:

Then stop the FCS service(net stop FCSAM), copy the malware library to the machine, restart the FCS service(net start FCSAM), run a custom scan of the folder, and then choose to Apply Actions in the detection dialog. This should remove all the threats and resources detected. If any threats remain in the folder after the action has completed that would indicate that either there was no detection or there was a failure to remove them. Failures would be reflected in both the UI and the event log.

If you find malware that FCS does not detect or detects but has problems removing, please submit it through the Microsoft Malware Protection Center portal.

Thanks,
Craig Wiand
Microsoft Forefront Escalation Engineer

As I mentioned in my previous blog posting, there have been several updates to the FCS antimalware client since its release. Through traditional deployment methods you will install the release to manufacturing components(RTM) of the FCS client which has no updates and extremely limited detection capabilities. At installation, the client has the base 1.0.0.0 antimalware definitions. Immediately after the installation it will use the Windows Update API(WUA) to attempt to download the current definitions from either your WSUS server or Microsoft Update(whichever it is configured for). During the next Automatic Updates cycle it will download the latest antimalware update(currently KB956280) and install it.

At the time this posting was made Microsoft has not published an updated FCS client package to WSUS (although it is being considered) or revised the CD media available for download. Therefore, if you choose to deploy the FCS client via WSUS or the CD it will go through the above RTM installation and then subsequent update.

If you are doing a manual, scripted, or SCCM/SMS/similar style of deployment then you can update the antimalware client installation package to install the latest version, instead of the RTM. You can do this through the following steps:

1. Determine the latest version of the antimalware client. This link points to the KB article http://go.microsoft.com/fwlink/?LinkId=125926 for that version

(above the article number is 956280)

2. Visit the Microsoft Update catalog and query for “Forefront Client Security” http://catalog.update.microsoft.com/v7/site/Search.aspx?q=forefront%20client%20security

3. Add the appropriate language of the KB from Step #1 to your basket and download (both x86 and x64 will be included).

4. Extract the contents from the update package

• Open a command prompt
• Change directory to the download location
• Run the executable with a /extract switch for each package:
  >all-fcsam-kb956280-x64-enu_1dfb1029721f86ea98674400ffcb5cba629d0bc8.exe /extract
• In the dialog presented, enter a temporary directory

5. Locate the mp_ambits.msi file in the temporary directory extracted contents

6. Copy the entire client directory from the CD media (including the MSI files, KB914882 installers, and the x64 subdirectory) to the deployment location(typically a file share)

7. Replace the mp_ambits.msi in the deployment location with the extracted copies of both x86 and x64 in their respective \client and \client\x64 directories

Using this method will deploy a slipstreamed FCS antimalware client; however, that client will still have the base 1.0.0.0 definitions and invoke a WUA download of definitions at installation completion. This download cannot be prevented in the current version of the FCS product. If you were scripting an installation and did not wish this WUA download to occur, you might disable network connectivity or temporarily stop the Automatic Updates service and use a standalone definition update installation. The standalone definition installers are also available from the Microsoft Update catalog website shown in the screenshot above as well as through links off of the MMPC portal and KB938202.

Thanks,
Craig Wiand
Forefront Client Security Escalation Engineer

On or about December 9^th, Microsoft Malware Protection Center included new information in the FCS definitions to ‘clean' the file ‘user32.dll' in the system32 and system32\dllcache folders which may have been modified at some earlier time by the Marioforever malware.  Most of these infections occurred in May/June 2008.  In those cases, signature updates were provided to quarantine/remove the actual malicious code (executables) from affected machines.  However, the malware also modified part of the user32.dll file (a core Windows file) which will now be successfully restored by FCS.

 A side effect of this is that FCS may now detect certain components which it may not have detected previously, though the malware has been disabled since it was originally detected.

Important things to note:

• This is only applicable to FCS customers who were previously exposed to the Marioforever malware, and then subsequently cleaned.
• This is not a re-infection.

Thanks,

Faron

Security Technical Lead

During the course of your FCS deployment it may be necessary to redirect an FCS client from one FCS collection server to another.  Common reasons why an admin would do this include moving the machines from a test server to a production server or load balancing machines across down-level installations of an Enterprise Manager deployment.  Note: if you are migrating FCS topologies which involves changing the collection server name then you should follow the steps in the collection server topology migration guide.

After reading the FCS deployment guide, it is easy to fall into the misconception that you can simply deploy new policy to that computer and it will automatically see the server name change and begin reporting to the new server.  Unfortunately this is not the case.  As summarized here:

In standard Client Security deployment, Client Security agents are deployed to target managed computers by creating and deploying a Client Security policy. This policy writes the names of the Client Security collection server and the Client Security Management group to the target computers. The computers then download the Client Security agent from the distribution server, and they install it with the configuration information from the Client Security policy. This results in the target computers reporting to the Client Security Management group that created the Client Security policy.

The key aspect of this is that the management group and collection server names are only read during installation time.  Deploying new policy will change these registry keys but it will not change the configuration of the MOM agent, which is responsible for sending data to the collection server.  Therefore, to redirect the FCS client we must modify the configuration of the MOM agent.

There are several ways to do this, each having their advantages and disadvantages.  Your choice will likely depend on the number of clients being redirected and the configuration of those clients.  Note that special care should be used on a FCS collection server or a MOM 2005 management server, in most cases it is inappropriate to script the MOM agent to those machines and one should manually run clientsetup.exe.  Additionally, reconfiguring the MOM agent requires administrative rights and scripts shown below will require an elevated command prompt.

Add/Remove Programs (Uninstall or change a program)

Perhaps the most straightforward way to modify the MOM agent configuration is by going into Add/Remove Programs locating Microsoft Operations Manager 2005 Agent and choosing Change.  Click, Next on the welcome screen and then choose the Modify option.  What you do next will depend on the nature of the redirection, specifically the question you should be asking is “Does the name of the management group differ between these installations?” 

If the group name will be the same then you would want to choose the “Modify Management Group” and then change the Management server name field to be the new FCS collection server(yes this is a mix of FCS and MOM terminology)

If you are load balancing across down-level installations or moving from test to production then it is possible that the management group names will differ.  In this case, you will want to run the installation wizard twice.  The first time choose “Add a new management group” and enter the new management group name and the new collection server name.  The second time you should choose the “Remove management group” option and ensure that old management group is chosen in the dropdown list.   In effect, you are momentarily reporting to both installations.  This is the basic guidance presented in the MOM 2005 documentation.

In all the installation options during the wizard you should choose a port of 1270, an Agent Control Level of Full, and a MOM agent action account of LocalSystem.  These setting are what FCS clientsetup.exe uses.

Since this activity will modify/reinstall the MOM agent on the client after the agent has been redirected a service dependency on WMI must be recreated to ensure proper functioning of the MOM agent.  To recreate this service dependency enter the following from a command prompt which sets it and then restarts the MOM service: sc config mom depend= rpcSs/eventLog/winmgmt & net stop mom & net start mom (note the space after the equal sign in necessary).

Advantages

·         Changes made through UI wizards; no scripting required

·         No gap in data reporting

·         Does not require access to FCS CD media

·         Works with multi-homed agents

Disadvantages

·         Extremely time consuming and prone to error for a large number of clients

·         Requires familiarity with the previous and new management server and group names

Command line invocation of the MOM agent

As mentioned above if you have a large number of clients using Add/Remove can be cumbersome.  Luckily, the MOMAgent.msi file has documented command line parameters.  You can use the command line installation options in exactly the same way that you would use the wizards.  Additionally, since the MOM agent is already on the machine, we can invoke it using its local MSI package without requiring a copy of the FCS CD media, this is done using a GUID passed to MsiExec.exe.

If the management group will remain the same and only the server name is different you would use the ModifyConfigGroup operation like(bolded parameters should be changed to match your environment):

MsiExec.exe /I{F692770D-0E27-4D3F-8386-F04C6F434040} /norestart /qn /l*v "C:\MOMReinstall.log" CONFIG_GROUP=" SameManagementGroup "
CONFIG_GROUP_OPERATION="ModifyConfigGroup" MANAGEMENT_SERVER="newserver.corp.com" AM_CONTROL="Full" REQUIRE_AUTH_COMMN=1 REINSTALL="ALL"

If the new server the client will report to has a different management group name you would use an AddConfigGroup operation and then a RemoveConfigGroup operation:

MsiExec.exe /I{F692770D-0E27-4D3F-8386-F04C6F434040} /norestart /qn /l*v "C:\MOMAdd.log" CONFIG_GROUP="NewManagementGroup" CONFIG_GROUP_OPERATION="AddConfigGroup" MANAGEMENT_SERVER="newserver.corp.com" AM_CONTROL="Full" REQUIRE_AUTH_COMMN=1 REINSTALL="ALL"

MsiExec.exe /I{F692770D-0E27-4D3F-8386-F04C6F434040} /norestart /qn /l*v "C:\MOMRemove.log" CONFIG_GROUP="OldManagementGroup" CONFIG_GROUP_OPERATION="RemoveConfigGroup" MANAGEMENT_SERVER="oldserver.corp.com" AM_CONTROL="Full" REQUIRE_AUTH_COMMN=1 REINSTALL="ALL"

Since this activity will modify/reinstall the MOM agent on the client after the change has been made a service dependency on WMI must be recreated to ensure proper functioning of the MOM agent.  To recreate this service dependency use the following from a command prompt which sets it and then restarts the MOM service: sc config mom depend= rpcSs/eventLog/winmgmt & net stop mom & net start mom (note the space after the equal sign in necessary).

Advantages

·         Can be automated and widely deployed to change a large number of clients

·         No gap in data reporting

·         Does not require access to FCS CD media

·         Works with multi-homed agents

Disadvantages

·         Requires some scripting or batch file creation

·         Requires a method of deploying the command line invocations

·         Requires familiarity with the previous and new management server and group names

Removing the FCS MOM agent and rerunning clientsetup.exe

As you may have seen from the first option, you can remove the MOM agent by going into Add/Remove Programs, locate Microsoft Operations Manager 2005 Agent, and choosing Change.  Click, Next on the welcome screen and then choose the “Remove management group” option and ensure that old management group is chosen in the dropdown list.  The machine now has no agent.  Then you can use the FCS CD media and run \client\clientsetup.exe (or \client\x64\clientsetup.exe if x64 platform).  Rerunning clientsetup.exe will cause clientsetup.exe to read the new policy settings which contain the new MOM server and group name and it will install a new MOM agent appropriately.  If you do not have FCS policy deployed you can call clientsetup.exe /MS newserver.corp.com /CG NewManagementGroup

Since clientsetup.exe is used to install the MOM agent it will properly set a service dependency on WMI without additional steps.

Advantages

·         Changes made through UI wizards and commands; no scripting required

·         Typically does not require familiarity with the previous and new management server and group names

·         Works with multi-homed agents

Disadvantages

·         Requires access to FCS CD media

·         Gap in reporting between uninstallation and reinstallation

·         Maybe time consuming for a large number of clients

Removing the entire MOM agent and rerunning WSUS deployment

Basically this is the similar to the above, in that the MOM agent is removed.  If you are looking to push this out you can combine it with the command line option like:

MsiExec.exe /qn /x{F692770D-0E27-4D3F-8386-F04C6F434040}

Then instead of manually installing the FCS agent from the media you can approve it on your WSUS/Distribution server and allow it to be redeployed automatically.  The detection logic of the FCS deployment package checks for the presence of all three client components(antimalware, security assessment, and MOM agents).  Since the MOM agent will be missing it will redeploy the package and reinstall only the MOM agent using the new settings deployed via policy.  For more information on how to configure WSUS client deployment see the FCS deployment guide.

Note that you can force automatic detection and installation by configuring the FCS client installation package with a WSUS deadline for a date in the past and then, after uninstalling the MOM agent, do a “wuauclt /detectnow” from the command line.  This should force a detection cycle and the deadline should cause the package to be installed immediately.

Since clientsetup.exe is used to install the MOM agent it will properly set a service dependency on WMI without additional steps.

This technique should not be used with a multi-home MOM agent(an agent also reporting to a traditional MOM 2005 infrastructure).  As described above, it requires that the MOM agent is completely removed to meet the WSUS deployment logic.  After the command above uninstalls the entire MOM agent, the FCS client is reinstalled but not the traditional MOM configuration.

Advantages

·         Typically does not require familiarity with the previous and new management server and group names

·         Can be automated and widely deployed to change a large number of clients

·         Does not require access to FCS CD media

Disadvantages

·         Should not be used with multi-homed agents

·         Gap in reporting between uninstallation and reinstallation

·         Requires some scripting or batch file creation

·         Requires a method of deploying the command line invocations

Multi-homing via MOM Administration console Install/Uninstall Agent Wizard

Built into MOM 2005 is a Install/Uninstall Agent Wizard.  This wizard can be invoked as either the server action account or a user account and it will try to remotely install or uninstall a MOM agent for the management group and server from which the wizard is run.  The wizard and steps are documented in the MOM Deployment Guide.  The steps are:

1.    From a MOM admin console in the new deployment, run the Install Agent Wizard to add the new client machine(s).  Upon success the machine will be multi-homed to both installations.

2.    From a MOM admin console in the old deployment, run the Uninstall Agent Wizard to remove the client machine(s). 

On the surface this looks like the easiest and most desirable method, but in reality probably has the highest failure rate.  Reasons for this include:

·         The installation wizard is server->client, therefore if any firewalls exist over the MOM/SMB/RPC ports this will fail.  The required firewall configuration it enable this is described in:

The Microsoft Operations Manager 2005 agent does not install on computers that are running Windows XP with Service Pack 2 (SP2) and Windows Server 2003 with Service Pack 1 (SP1)

http://support.microsoft.com/default.aspx?scid=kb;EN-US;885726

·         Using the wizards requires that the machines be online at the time the wizard(or the resulting computer discovery action) is run to use a specified account

·         An account must be used in both wizards with admin permissions on the client, usually this means all domains are trusted

Advantages

·         Typically does not require familiarity with the previous and new management server and group names

·         Can be automated and widely deployed to change a large number of clients

·         Does not require access to FCS CD media

·         No gap in data reporting

·         No scripting required

Disadvantages

·         Error prone and potentially problematic to implement

·         May require changes to the firewall configuration of the client machines

Since this activity will modify/reinstall the MOM agent on the client after the change has been made a service dependency on WMI must be recreated to ensure proper functioning of the MOM agent.  To recreate this service dependency use the following from a command prompt which sets it and then restarts the MOM service: sc config mom depend= rpcSs/eventLog/winmgmt & net stop mom & net start mom (note the space after the equal sign in necessary).

Thanks,
Craig Wiand
Forefront Client Security Escalation Engineer

Are you suspecting an Infection in your network?

If you suspect an Infection in your network and if you could find the infected file please upload the sample to the link https://www.microsoft.com/security/portal/submit.aspx

Only one file can be submitted at one time and the size of that file is limited to 10 megabytes. Compress the file and password protect the file with the password "infected" (without quotes).           

If you want to submit more than one file for analysis, please compress the files into a single archive and password protect the files with the password "infected" (without quotes).

In the comments field please provide any information about the Infection.

Microsoft Malware Protection Center will send you the results of the analysis on the submission.

 FCS customers please contact Microsoft Customer Service and Support to raise an incident and follow the below steps.

You can also try these steps,

·         Run a Full Scan in the infected machine with the recent signature updates.

·         Try to isolate the machine from the network to avoid spreading the infection.

Are you facing an issue while installing Forefront Client Security?

Check the Prerequisites

·         http://technet.microsoft.com/en-us/library/bb404270.aspx

If you still experience issues after reviewing the Prerequisites, please contact Microsoft Customer Service and Support to raise an incident and follow the below steps

Server installation issues: Gather and provide the engineer with the topology you are attempting to install and computer and account information (see deployment guides)

Example:

Collect the failed setup log from the below location and share it with the Engineer who is contacting you

For Server role installation:

<Install drive>\Program files\Microsoft Forefront\Client Security\Server\Logs\Server_date.log

For Client installation:

%Program Files%\Microsoft Forefront\Client Security\Client\Logs

If your Forefront Clients are not getting the signature updates

Please execute the CSS Sec MPS report from the Link in the distribution Server http://www.codeplex.com/SECTools/Release/ProjectReleases.aspx?ReleaseId=15744

(If it’s a Single server topology run it in the FCS Server)

Also execute the CSS Sec MPS report from the Link in a client machine http://www.codeplex.com/SECTools/Release/ProjectReleases.aspx?ReleaseId=15744

and when Microsoft Engineer has contacted you request him/her for the Workspace to upload the output of the MPS Report.

For other Issues faced in Forefront Client Security

Execute the CSS Sec MPS report from the Link

http://www.codeplex.com/SECTools/Release/ProjectReleases.aspx?ReleaseId=15744

·         Run this in all the Forefront Client Security Server Roles.

·         If it’s a Single Server topology execute this in FCS Server.

·         To Run this Script you need to login with Administrator ID.

·         This Script will not take more than 5 to 15 minutes.

·         This Script is transparent and utilizes less processor time and memory.

·         Gather and provide the engineer with the topology you are attempting to install along with computer and account information (See Deployment Guides)

When Microsoft Engineer has contacted you request him/her for the Workspace to upload the output of the MPS Report.

What will the CSSSEC MPS Report log from your machine?

Information on IIS:

IIS Anonymous (IUSR) User Information

IIS Metadata and Module Information (MBSchema.xml, MetaBase.xml, sysinfo xml).

IIS Configurations and logs.

Windows update related Information:

WinHTTP Proxy Settings.

BITS (Service and Queued job Status)

Missing Security update Information.

FCS Information:

FCS Anti malware support Logs.

FCS Security State Assessment Information.

FCS Account Information.

FCS Client setup files.

FCS Database Information.

Profile settings of FCS Console.

Checks the Status for Forefront client dependency services.

MOM and reporting Services Information:

MOM Management Pack Information.

MOM *.mc8 Log Files.

MOM Configuration (Onepoint database size and permissions, System Center Reporting database Size and Permissions)

SQL reporting Services Information and logs.

Other Information:

Dcom Information.

Event Logs (Application, System and Security Event logs)

Schedule task Information.

Version of Windows OS.

Version and Symbol Information of Executables.

NTFS Information

Group Policy Information.

Disk Quota Information.

MS Office Information.

Hardware Information of the Local machine.

ISA Server Information.

Security center Configuration (Anti Virus, Firewall, Automatic Updates)

For More Information please read the readme file from the link: http://www.codeplex.com/SECTools/Release/ProjectReleases.aspx?ReleaseId=15744

Thanks

Swami

CSS Security Team

On a system running the FCS Client, you may run into the event listed below which occurs on the local system and may cause an Alert to fire on the FCS Console.

This issue can occur when the client system has had a Real-time protection Security Agent de-selected in the FCS Client UI.

For example, if you do the following and restart the system or restart the Microsoft Forefront Client Security AntiMalware Service you will receive the event.

1.  Go to Tools/Options in the FCS Client UI
2.  Uncheck any of the security agents under "Use real-time protection"
3.  Restart the AM service or reboot the system

The following event is logged -

Event Type: Error
Event Source: FCSAMRtp
Event Category: None
Event ID: 3002
Date:  9/20/2008
Time:  7:00:38 PM
User:  N/A
Computer: FCS Client
Description:
Microsoft Forefront Client Security Real-Time Protection agent has encountered an error and failed.
  User: Domain\administrator
  Agent: Application Execution
  Error Code: 0x8007139f
  Error description: The group or resource is not in the correct state to perform the requested operation.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

This error can be ignored if one of the Security Agents provided by Real-time protection have been intentionally disabled.

Thanks and please post any comments or questions.

Shain Wray

Security Technical Lead 

The Forefront Client Security team announced the release of Service Pack 1(SP1) last month.  As described in the announcement SP1 is a server-only update.  As this is a departure from what many folks are used to it causes a little confusion about which updates apply to which machines and how to be “up-to-date”.  In the below I have links to KB articles to learn more information about the updates, however all of the FCS updates referenced below are available from either Microsoft Update or deployment through WSUS.

SP1

It is important to understand that SP1 is essentially:

·         an aggregation of the existing FCS server component fixes into a single deployment package that received more testing and is easier to deploy than would be the individual fixes;

·         changes required to allow FCS server components to operate properly on Windows 2008 server;

·         a correction to a policy deployment issue not significant enough to warrant a released fix.

(note:  FCS SP1 does not contain any additional MOM 2005 fixes)

If you are deploying FCS server components to a Windows 2008 server then you will need to follow the instructions in the deployment guide for installing the release binaries and then applying SP1.  If you are deploying to a new Windows 2003 server we recommend that you deploy using SP1 bits.  If you have an existing Windows 2003 server deployment we recommend that you test SP1 in your lab and deploy it upon the successful completion of that testing.  Since this testing may not complete immediately, the FCS team has allowed the Sp0 fixes to remain available on the Microsoft Update website in case they are needed in the interim.

I specifically used the words FCS server components in conjunction with SP1; but what about all your FCS clients, what about an update for them?  The FCS client consists of three components: antimalware agent, security state assessment agent, and the MOM agent.  Taking each of these individually:

Mom

The MOM agent that FCS installs is the MOM 2005 SP1 agent.  Any fixes for the MOM agent would come from the MOM product team here at Microsoft.  To date, support has not seen many FCS-related problems with the MOM agent.  Occasionally a customer will run into the hibernation issue, but the problems caused by them are usually transient and have not warranted discussion of a broader release.

Security State Assessment

There have been both feature additions and problems found affect the SSA client which was shipped with FCS RTM.  However, those changes were all made to the object processor and manifest which are both included in the SSA definitions.  Therefore, if you have the latest SSA definition set your SSA client is up-to-date with Microsoft’s releases.

Antimalware

There have been several updates to the FCS antimalware client.  These antimalware releases have been published to the Microsoft Update website and a knowledge base article has been written detailing the nature of the changes in each revision.  Each of these releases are full (all binaries redistributed) and cumulative.  Therefore, if you move to the latest update you will have all of the current fixes.  The released versions are listed below:

In an effort to make finding the latest build easier we have created an FWLink (currently points to KB956280) which we will keep pointed to the latest build.  This FWLink was also added to the FCS SP1 article to make it more discoverable.

It is important to understand that these fixes update components of the antimalware agent, which are the vehicles that the antimalware engine uses for protection (the antimalware service, the UI, and the kernel mode mini-filter).  These packages do not contain definition or engine updates.  Each version of the FCS v1 antimalware client should be able to consume the engine and definitions created by the Microsoft Malware Protection Center(MMPC).  For optimal malware protection we recommend installing the latest antimalware client update and definition updates.

Thanks,
Craig Wiand
Forefront Client Security Escalation Engineer

The CSS Security Support Team will be posting to this blog to inform FCS customers about common support issues seen in the field.  If you have a topic you would like to see covered, please post a comment and we will attempt to address it.

Thanks,

CSS Security Support Team

All information provided here is in regards to Forefront Client Security 1.0.  There are no guarantees on the information provided.

During the FCS install process, the default setting for the Collection Database (aka OnePoint DB) and the Reporting Database (aka SystemCenterReporting DB) are incorrectly set.  From here on forward we will refer to them by the DB name, not the role name for FCS.  SystemCenterReporting DB should be the larger of the two because it will contain the historical data, hence the table below under Database Sizing.   By default, the OnePoint DB only maintains 72 hours worth of client data, while the SystemCenterReporting DB holds 395 days worth of data, so it is easy to see why the SystemCenterReporting DB needs to be larger.

Note – The max allowed size for the OnePoint DB is 30gb.  The SystemCenterReporting DB does not have a specific limitation on size.  Autogrow is not supported for the OnePoint DB and the SystemCenterReporting DB.  This also includes their respective Transaction logs

It is recommended that once FCS is installed, the SystemCenterReporting DB Data Retention is reduced to a lower number, unless it is needed to have that many days of historical data.   To reduce the number of days, see KB887016.  More details on Data Retention is located in the Troubleshooting Section.

1.       OnePoint DB and SystemCenterReporting DB sizing

a.       The following table(also located here) gives the details –

1.       OnePoint DB transaction log file sizing

a.       OnePoint DB transaction log file size generally needs to only be about 1/3 the size of the OnePoint DB itself.  For example, a 30gb OnePoint DB would need a 10gb OnePoint transaction log file size.

2.       SystemCenterReporting DB transaction log file sizing

a.       The scheduled task called SystemCenterDTSPackageTask copies data from the OnePoint DB to the SystemCenterReporting DB after the data is 72 hours or older.

b.      The SystemCenterReporting DB transaction log file is used in the data transfer and needs to be approximately 5x (based on real world example) the size of the OnePoint DB.  For example, if your OnePoint DB is 16gb in size, then the SystemCenterReporting DB transaction log file size needs to be 5x this or 80gb.

c.       Why does the transaction log need to be so much bigger than the DB.  See KB110139 for all details, but here is the snippet that explains why –

"For a narrow row, the amount of log space consumed for a particular UPDATE , DELETE or INSERT could be ten times the data space consumed. For wider rows, the amount of log space consumed will be proportionately less. Log space consumption is an unavoidable consequence of providing transactional integrity."

You notice we stated 5x above and the KB says could be 10x.  This is a value judgement, it is possible to hit 10x, but 5x is more reasonable.  The transaction log size does vary depending on the amount data, so the size may still need to be increased over the 5x suggestion.

3.       Autogrow

a.       It is not supported that Autogrow is set for the transaction logs for these DB’s.  Autogrow is not supported on either the DB or Transaction log.  This is due to a limitation in MOM 2005, not with the FCS product.

                                                               i.      However, if you are trying to recover from a large Reporting DB size due to the Data Retention number that is set, you may need to temporarily enable Autogrow on the transaction log for the Reporting DB.  See the Data Retention information in the Troubleshooting Section below for more details.

Due to the transactional intensity of MOM\SQL with FCS, just having enough disk space is not the only item to consider.

1.       Based on real world estimates, you will need a separate spindle for each DB and transaction log or you will need to span across multiple spindles to have the speed, efficiency and redundancy that is recommended. Depending on the size of the DB, a RAID set or SAN is recommended.  The table below is recommendations that we have come up with based on support cases with FCS customers and based on the largest numbers provided in the table above for DB sizing.  Note, these are recommendations not absolutes.  Depending on the hardware that is in use, more spindles or less spindles may be needed.  This number of spindles below is in addition to the spindle that the operating system is installed on.

Note: With 250 or less machines it is recommended to use 4 spindles.  However, if 4 spindles are not available, then 1 or 2 spindles can be used.  When using 1 or 2 spindles, DB performance will be impacted.  It is recommended when using 2 spindles to put the OnePoint DB and associated Transaction Log on one spindle and the SystemCenterReporting DB and associated Transaction log onto the other spindle.

1.       DTS job failures

a.       SQL Agent or Scheduled Task permissions

                                                               i.      Verify the service that SQL Agent runs under has permissions to the DB that the DTS job is running against

                                                             ii.      Verify that the Schedule Task is configured to use an account that has permissions to the DB that the DTS job is running against

b.      Database or Transaction log file size

                                                               i.      Check the Event logs, you should have an event about the job failing at a certain Step and it will give the specific DB or Transaction Log that ran out of space.

                                                             ii.      Once determined what item does not have enough size, grow that item to a larger size.

                                                            iii.      This can be worked around by setting autogrow, but that is not supported for the OnePoint or SystemCenterReporting DB’s.  When Autogrow is set, SQL stops processing while it grows the DB or Transaction log which can cause other performance issues and potential data loss.

2.       Data Retention issues

a.       To change the data retention for the SystemCenterReporting DB, see KB887016

b.      This is useful when there is not enough disk space to retain the default 395 days worth of data in the SystemCenterReporting DB.

c.       It can also improve performance when looking at historical information as the SQL stored procedures that are being called are not parsing 395 days worth of data.

d.      Unless 395 days worth of retained data is needed, it is recommended that the customer lower the data retention number when related to MOM running in conjunction with FCS.

3.       Reducing DB sizes

a.       As stated above, you can reduce the SystemCenterReporting DB size by reducing the Data Retention.

b.      However, if the SystemCenterReporting DB grows very large and the SCDWGroomJob fails then changing the Data Retention may not be a feasible method to resolve the issue.  This is because the SCDWGroomJob may timeout or fill up the transaction log due to the amount of data being groomed out.  There is a script that might be able to help.  It reduces the number of retention days by 5 and runs the groom job, this cycles through until the number of days you have specified is reached.  This is detailed in the Appendix.

c.       A similar issue can happen with the OnePoint DB.  The problem is when the scheduled task called SystemCenterDTSPackageTask fails to run and copy data from the OnePoint DB to the SystemCenterReporting DB.  The OnePoint DB grows large and can run out of space.

d.      You can work around the issues with both the OnePoint and SystemCenterReporting DB by following the information below.  When doing this, the customer will lose data, so be sure to explain this to the customer.

e.      For the OnePoint DB see Reducing large DB size in the Appendix below.

f.        There is another method that can be used for the SystemCenterReporting DB,  see this Blog entry for more details.  This is a more manual method than the script provided below.

How to shrink large Databases

SystemCenterReporting DB

There are times when the SCDWGroomJob may fail due to the SystemCenterReporting DB Transaction log filling up and/or running out of physical disk space or other reasons.  This generally occurs when the SCDWGroomJob has been failing for some other reasons and now there is more than the typical 1 day to groom out of the SystemCenterReporting DB.  The problem can also occur when you are trying to reduce the amount of days for Data Retention that you want the SystemCenterReporting DB to maintain.  The script below can be run against the SystemCenterReporting DB to reduce the amount of data that is stored and therefore reduce the size.  Here are the steps –

1.       Disable the following SQL jobs

a.       SCDWGroomJob

b.      Microsoft Forefront Client Security

c.       MOMX Partitioning and Grooming

2.       Confirm there are no open transactions to the SystemCenterReporting DB

DBCC OpenTran

3.       If there are any open transactions, wait until they are finished

4.       Make sure the Backup\Recovery Mode for the DB is set to Simple

5.       Change SQL to max degree = 1

exec sp_configure 'max degree', 1

reconfigure with override

go

6.       Now run the SQL query to reduce the size of the DB.  Note that the following settings must be changed before running this.

set @daysdiff

set @dayskeep

@daysdiff is the number of days it will prune each time, we recommend trying 5 to start with this, if this timesout or fill the disk with the Transaction Log, then lower it.

@dayskeep is the number of days you want to keep for Data Retention.  Generally 90 days is enough but it depends on the requirements for the environment.

Here is the SQL query to run -

Declare @tempdays int

Declare @daysdiff int

Declare @dayskeep int

set @daysdiff = x

set @dayskeep = xxx

Groom_Again:

select @tempdays = datediff(dd, min(timestored), getdate()) from sdkeventview

set @tempdays = @tempdays - 1

set @tempdays = @tempdays - @daysdiff

select @tempdays

IF (@tempdays < @dayskeep)

BEGIN

select 'Finished Grooming'

return

END

select 'start grooming in a new loop'

select @tempdays

IF (@tempdays > 120)

BEGIN

Exec p_updategroomdays 'SC_AlertFact_Table', @tempdays

Exec p_updategroomdays 'SC_AlertHistoryFact_Table', @tempdays

Exec p_updategroomdays 'SC_AlertToEventFact_Table', @tempdays

Exec p_updategroomdays 'SC_EventFact_Table', @tempdays

Exec p_updategroomdays 'SC_EventParameterFact_Table', @tempdays

Exec p_updategroomdays 'SC_SampledNumericDataFact_Table', @tempdays

END

exec dbo.p_GroomDatawarehouseTables

select getdate()

DBCC opentran

goto Groom_Again

OnePoint DB

There are times when the OnePoint DB when used with FCS will grow dramatically due to large number of events coming from various clients. This is usually due a missing FCS override for something like VNC or Dameware that is used in the environment and the FCS agent flags and sends an Event 3004 to the MOM server over and over for each client. This causes the Event tables in the OnePoint DB to grow to millions of rows rapidly and usually triggers the Event Flood Detection Alert.  Corresponding with the Event Flood Detection Alert, the Event Rule called Run Flood Detection will be changed so that the Auto-Approve Pending Computers will be set to False.  Once the flooding Events are mitigated, the Run Flood Detection Event Rule will need to be changed back to True, otherwise systems that get the FCS client package will not be automatically approved in MOM going forward.

Note - using the following procedures will remove data from the OnePoint DB and the
data will not be recoverable unless a backup is taken of the OnePoint DB.

Method

There are multiple things that need to be done. Here is a summary, with details to
follow.

Summary

1.       Identify the offending client or clients and mitigate the issue, whether an overrride needs to be implemented for something like Dameware or the system is being reinfected due to missing security updates, poor user awareness and so on.

2.       After the floods of events to the MOM server have been mitigated, then the events need to be cleaned out the Event Tables in the OnePoint DB. If the policy in the specific environment requires that data to be retained, then backup the OnePoint DB so that events could be extracted at a later data.  Data loss will occur if there is no backup, but in general, this is being done because nothing is processing and the data is effectively useless at this point.

3.       After cleaning out the various Event Tables, check the TimeDTSLastRan entry in the Report Settings table and confirm it is not more than a couple of days old. If it is, then set it to the current day.

4.       Next, run the SystemCenterDTSPackageTask in Scheduled Tasks and confirm that it completes successfully.

5.       Fix the Run Flood Detection Event Rule.

6.       At that point, everything should be running as expected.

Detailed Steps

Stop the MOM service before performing any of the following steps. This way there is no contention with the MOM agents trying to upload events and causing these queries to take a very long time.

1.       Confirm what event is filling up the Event tables by running the following SQL query against the OnePoint DB.

select eventno, count(*) as total

from eventview

group by eventno

order by total desc

2.       Based on the event, use the filter in the MOM Operators console to see what systems are throwing those events and the details of the event.  As an example, the event may be a 3004 and due to TightVNC being flagged. If the item being flagged as malware is something that is used in your environment then set an override in the FCS Policy for the malware name that is being flagged, in this example it would be RemoteControl:Win32\TightVNC.  There are many different types of scenarios and the mitigation may be straight forward as this one is, or not.  It may require a call into Microsoft Product Support if the way to mitigate the problem is not clear.

3.       Now reduce the size of the OnePoint DB by reducing the size of the Event tables.  Run the following SQL query to determine which Event tables have the largest number of rows. In FCS, it is usually about 3-5 tables total that start with Event_XX where XX is the number of the table.

SET NOCOUNT ON

CREATE TABLE #TBLSize

(Tblname varchar(80),

TblRows int,

TblReserved varchar(80),

TblData varchar(80),

TblIndex_Size varchar(80),

TblUnused varchar(80))

DECLARE @DBname varchar(80)

DECLARE @tablename varchar(80)

SELECT @DBname = DB_NAME(DB_ID())

PRINT 'User Table size Report for (Server / Database): ' + @@ServerName + ' / ' +

@DBName

PRINT ''

PRINT 'By Size Descending'

DECLARE TblName_cursor CURSOR FOR

SELECT NAME

FROM sysobjects

WHERE xType = 'U'

OPEN TblName_cursor

FETCH NEXT FROM TblName_cursor

INTO @tablename

WHILE @@FETCH_STATUS = 0

BEGIN

INSERT INTO #tblSize(Tblname, TblRows, TblReserved, TblData, TblIndex_Size, TblUnused)

EXEC Sp_SpaceUsed @tablename

-- Get the next author.

FETCH NEXT FROM TblName_cursor

INTO @tablename

END

CLOSE TblName_cursor

DEALLOCATE TblName_cursor

SELECT CAST(Tblname as Varchar(30)) 'Table',

CAST(TblRows as Varchar(14)) 'Row Count',

CAST(LEFT(TblReserved, CHARINDEX(' KB', TblReserved)) as int) 'Total Space (KB)',

CAST(TblData as Varchar(14)) 'Data Space',

CAST(TblIndex_Size as Varchar(14)) 'Index Space',

CAST(TblUnused as Varchar(14)) 'Unused Space'

FROM #tblSize

Order by 'Total Space (KB)' Desc

DROP TABLE #TblSize

4.       The above will indicate which Event_XX tables have any data in them. Use the information about what Event_XX tables have data in them and plug it into the following SQL query which truncates the tables so they will be empty after the script runs.

Remember, this will cause the loss of any data in the OnePoint DB regarding events.

exec dbo.MOMXDropEventFKs XX

truncate table event_XX

exec MOMXRecreateEventFKs XX

truncate table eventparam_XX

truncate table eventconsolidated_XX

Remember XX is the number listed, so if the TableSize query in step 3 shows Event_08 as being very large, then the SQL query would look like such -

exec dbo.MOMXDropEventFKs 08

truncate table event_08

exec MOMXRecreateEventFKs 08

truncate table eventparam_08

truncate table eventconsolidated_08

The script above needs to be run for each Event_XX table that is listed as having any data in it.  If there are any Event_XX tables that have data left in them, then there is potential for data correlation errors in the OnePoint DB as related tables will have different information.

5.       Now check the TimeDTSLastRan to make sure it has a date of the last few days. Run the following SQL query -

select timedtslastran from reportingsettings

6.        If it is more than a few days ago, then run the following SQL query to set it to today –

update reportingsettings

set timedtslastran ='YYYY-MM-DD'

Where YYYY is the four digit year, MM is the month and DD is the day.

7.       Confirm that the table was updated using the following SQL query -

select timedtslastran from reportingsettings

8.        Now run the SystemCenterDTSPackageTask in Scheduled Tasks and confirm it completes successfully.  It will show a 0x0 in the Scheduled Tasks UI if successful. This scheduled task can take many hours to run.

9.       Fix up the Run Flood Detection Rule so that computers will be Auto-approved again using the following steps.

a.       Open the MOM Administrator Console

b.      In the Tree, Expand to Management Packs\Rule Groups\Microsoft Forefront Client Security\Server Behaviors\Event Rules

c.       Double-Click on the Run Flood Detection rule listed on the right windows.

d.      Click on the Responses Tab

e.      Highlight the script listed in the box and click Edit

f.        Under Script Parameters, double click on Auto-Approve Pending Computers

g.       Change the value from false to true.

h.      Click OK

i.         Click OK again

10.   Now it should be resolved.

Please post any comments or questions.

Thanks,

Shain Wray

Security Technical Lead