Integrating ConfigMgr 2007 and ForeFront Endpoint Protection 2010
The integration between ConfigMgr 2007 and ForeFront Endpoint Protection 2010 (FEP) has been a topic of interest lately in ConfigMgr circles so figured it would be worth spending a bit of time going through the installation and integration process. In addition, we will also spend some time digging a bit deeper into some areas to see how this all works behind the scenes.
The first step is to install FEP. Before proceeding it’s important to do a couple of things. First, verify prerequisites are in place. There aren’t that many prerequisites unique to FEP but there are a few, listed below.
Hotfix 2271736
SQL Agent
SQL Analysis Services
SQL Integration Services
ForeFront rollup 1 - https://support.microsoft.com/kb/2551095
Note: While not strictly a prerequisite having this rollup is important to facilitate updating FEP clients from ConfigMgr Software Update
Points. As such, it is strongly recommended that you implement it. The update rollup will be applied at the end of FEP installation.
Second, decide which site FEP needs to be installed on. Does it need to go on all sites or is installation at the Central site alone sufficient? Most of the additions that are available for ConfigMgr 2007 (hotfixes, R2/R3, etc.) do need to go on all site servers. This is because they either update existing product binaries or offer functional changes to the product that require updating all sites in the hierarchy. This is NOT the case for FEP. FEP does add additional functionality but the mechanisms to provide that functionality simply make use of existing ConfigMgr components – there aren’t even any custom hardware inventory extensions! That said, there is no technical reason why FEP integration needs to be installed anywhere other than the Central site, particularly in environments with centralized administration of patching and other deployments. If you want to install it at child sites as well then it’s OK to do so but bear in mind that the installation will create other system components – such as packages, collections, advertisements, etc. – so installing it on multiple sites will result in items being duplicated. Also note that it’s possible to install FEP on only a single primary child site – so if you have a hierarchy where some primaries support workstations systems and other support server systems – and you only want FEP for servers – then there is no need to install it on anything other than the server specific child sites. A note in this configuration though is that if you do this, status reports and information needed by reporting will only roll up to that primary site and won’t be visible at the central level.
FEP Installation
OK, enough about that – time to get FEP installed. In this case it will be installed at the central site (Note: The wizard shots below are actually from my primary child site for demo purposes since FEP is already installed at my central). So, looking at what is available on the install media we find the standard x64 and x86 binaries. We will install the x64 version since the server hosting ConfigMgr is an x64 system. If you have 32-bit servers in your environment where you want the FEP agent installed, don’t worry - the installer package that deploys the FEP agent will properly detect the target platform and apply the correct agent.
Before getting started, shut down the ConfigMgr console and related items and then, from the x64 folder, launch serversetup.exe.
This brings up the ForeFront Endpoint Protection 2010 setup wizard. Type in an Organization name and click Next.
Accept the license terms and click Next.
Choose the type of installation of interest. If FEP is being installed just at the central site and reporting is also installed on the central site (SSRS reporting, not ConfigMgr classic reporting) then selecting Advanced Topology is likely the choice you want and the option chosen for the example. The wizard steps from here may differ depending on which installation options are selected. Once selected, click Next.
These settings are automatically selected as a part of the wizard. Ensure these settings are as you like. If not either disable here or go back in the wizard to select other installation options. For this example, these choices are fine so click Next.
Confirm the database name is as you like – note that the FEP database name inherits the site code for the site. Once ready, click Next.
The options here allow configuration of the FEP reporting database settings along with pointing to the SSRS URL Configure as needed and click Next. Depending on the credentials being used you may get a warning popup.
Choose whether to use Microsoft Update to keep FEP up to date. Note that this option allows keeping the FEP Server components up to date – not the client components. Also choose whether to join the Customer Experience Improvement Program. Once ready, click Next.
Choose whether to join the Microsoft Spynet program and, if so, what level of membership. Once ready, click Next.
Note: Choices on this screen don’t impact functionality of FEP at all.
Review installation location information along with disk space information and adjust as needed. Once ready, click Next.
The prerequisite checker runs to validate all required precursor components are available. Any missing components will be flagged here. Correct any problems until all components show green and then click Next.
Review the summary screen and then click Next to proceed with the installation.
Note: Once complete with the initial installation it is strongly recommended to stop and install FEP Update Rollup 1
FEP Rollup 1 Installation
Before exploring the FEP installation let’s proceed with the installation of FEP Rollup 1. Before we start the installation process for FEP Rollup 1, we have a prerequisite that needs to be installed. This prerequisite only applies if you have FEP Reporting installed. You can get the prerequisite and FEP Rollup 1 from the following URL’s.
FEP Rollup 1 Reporting Prerequisite Update - https://support.microsoft.com/default.aspx?scid=kb;EN-US;2554364
FEP Rollup 1 - https://support.microsoft.com/kb/2551095
Let’s start with the reporting update – KB2554364. To install simply launch the application after download. This will bring up a wizard as shown. There are no configuration choices needed in the wizard so simply click next all the way through and allow the installation to complete.
OK, on to Rollup 1. Download the rollup and run the downloaded file. This will prompt you to supply a path to extract the contents of the update. Once extracted, open the folder with the extracted content to reveal three separate updates that must be applied – one for FEP Extensions, one for FEP Reporting and one for the FEP console additions. Simply run through the executable in each of the folders as shown. At the end, FEP Rollup 1 is installed.
Note: If the prerequisite update is not installed first, the FEP Rollup 1 Reporting update will not find required files and will fail.
FEP Installation Walk-Through
OK, installation is done. Let’s take a look and see what changes have been made to ConfigMgr as a result.
File System
FEP is installed in c:\program files\Microsoft ForeFront. There are several folders here
\Client – is the location for the software that will be used to deploy the FEP agent to ConfigMgr clients.
AmUninstall.vbs – This VBScript is used to uninstall the FEP Agent software if needed and is called by the FEP Uninstall program in the FEP
Deployment Package.
FEPInstall.exe – This executable installs the FEP agent software on targeted ConfigMgr client systems. The installation of FEP is not called directly
but as part of the ApplyPolicy.vbs script.
\Client\Policy – is the location containing a script and policy templates for updating or installing the FEP agent.
ApplyPolicy.vbs – This VBScript is used for two things – applying FEP policy to existing FEP clients or installing the FEP client software. Which action
the script takes is determined by how the script is executed. When called without any command line values, the script simply applies FEP policy. If
called with command line values, the script installs the FEP client.
Default Desktop Policy.xml – This file defines the policy settings applied to default desktop systems.
Default Server Policy.xml – This file defines the policy settings applied to default server systems.
\Forefront Endpoint Protection – is the location for the software that drives the ForeFront engine on the ConfigMgr server. This folder also contains various reports available as part of FEP.
\Policy Templates – is the location for various policy templates that are optimized for various server workloads, such as DHCP, DNS, OpsMgr, Hyper-V, etc. These templates may be imported into the FEP node in the ConfigMgr console and deployed to appropriate systems.
\RemediationScripts – is the location for the VBScript used for scanning and definition updating.
AmRemediation.vbs – Depending on the command line supplied (–ScanType 1, –ScanType 2 or –SignatureUpdate), this script is used to trigger a full
or quick scan on FEP agents or to cause FEP agents to download the latest definition updates.
Client Agents
There are no additional client agents introduced by FEP. FEP makes use of existing ConfigMgr functionality only!
Collections
FEP integration adds a number of collections. These collections, driven by hardware inventory and DCM data, are used to keep track of the state of FEP operations in the environment as follows:
Definition Status – Tracks the status of FEP Definitions for systems, whether up to date, between 1-3 days old, between 4-7 days old or older than a
week.
Deployment Status – Tracks the status of FEP agent deployment to systems – whether Succeeded (for desktop or server), failed, or pending.
Collections here also track whether the FEP agent has been locally removed, where the FEP agent is out of date and needing an update or systems
where the FEP agent software could not be assigned which includes systems discovered but not installed with a ConfigMgr client.
Operations – Tracks one-off operations that take place against FEP client agents. Operations include triggering quick scans, full scans and
antimalware definition updates. FEP adds right-click options for systems in collections that are used to trigger such scans. Selecting a right-click
option for a system causes a new collection to be added as shown below. In addition, an advertisement is created that will carry out the selected
action against collection members.
Policy Distribution Status – Tracks the distribution of FEP policy in the environment, whether successful, pending or failed.
Protection Status – Tracks the Protection Status of systems in the environment, whether healthy, not reporting or services that are disabled.
Security Status – Tracks the security status for FEP agents in the environment, whether a full scan is required, the system is infected, recent malware
activity has been detected or a restart is required.
When reviewing the collections added one might immediately notice that all collections are locked (except those under Operations which are generated ‘on the fly’ and highlighted below) and that the lock is in place even at the central site. Don’t panic, nothing is wrong – FEP collections being locked in this manner is intended. The reason is simple; collection membership drives the dashboard view in the FEP node (discussed later) so ensuring these collections aren’t tampered with is crucial.
The reasoning behind the collections being locked has already been discussed – but what if you want to understand exactly how the collections are built and what criteria are used for defining such collections? The first question to answer is whether these collections are built based on direct membership rules or are based on query results. This information can be obtained by reviewing the properties of the collection, even if locked. A quick review reveals that ALL FEP collections other than those for Operations, highlighted above and created ‘on the fly’, are query based and are scheduled to update every hour.
Whoa – every hour? Isn’t that a bit excessive? Typically, yes but in this case it’s important to know quickly what the status of FEP is in an environment so that any malware issues or issues preventing malware protection are detected quickly.
If you look closely at the collection properties you might also note (in ConfigMgr R3 environments) that these FEP collections aren’t configured to use fast collection updating. My best guess as to why this is the case is due to the fact that not all ConfigMgr customers have R3 deployed in their environments yet may still want to use FEP integration. To ensure compatibility, the fast collection updating option was not enabled on collections.
OK, so what about the detail behind how these collections are populated? To get that we need to understand the detail of the queries used to populate these collections. In this case, simply looking through the console isn’t enough. Because the collections are locked it’s not possible to edit the collection query (and in many cases wouldn’t be helpful anyway – as you will see shortly), so it’s time to dive into SQL. Before doing so – a disclaimer. It is not supported to edit SQL in any way, shape or form. Doing so could render damaging changes to your environment and the information shown here is for educational purposes only!
There are two key tables to look at in SQL. The first is the Collections table. This table will detail the collection names along with the associated collection ID’s as shown. For the example we will review the collection query for the Out of Date collection which is CollectionID 44.
From here we look in the Collection_Rules_SQL table for CollectionID 44. In this table we find the queries running behind the scenes to populate the membership of a given collection. There is both a WQL version of the query and a SQL version. Typically, the WQL and SQL queries are very similar since WQL and SQL are very similar languages. In this case and several other cases throughout the FEP collections (but not all), the WQL query is essentially a placeholder that does no filtering of collection membership while the SQL query is the driver for determining collection membership.
Packages
There are three packages added to ConfigMgr that help drive FEP operations
Microsoft Corporation FEP – Deployment 1.0
The purpose of this package is to deploy the FEP agent to ConfigMgr clients in the environment. There are two programs defined for the package – an install program and an uninstall program. The install program causes the FEP agent to be installed on ConfigMgr clients and any other malware product to be removed. The Uninstall program causes the FEP client to be removed. There is no default advertisement created for this package. Administrators should determine which systems should be targeted to receive agent deployments and create advertisements accordingly.
Microsoft Corporation FEP – Operations 1.0
The purpose of this package is to handle ongoing operations for the FEP agent. Such operations include performing a full and quick system scan as well as updating FEP definitions. There are programs created for each action. There are no default advertisements created for this package. Administrators are able to create advertisements manually or use the right-click options available for individual systems or groups of systems in the collections (shown earlier) to trigger advertisement creation automatically.
Microsoft Corporation FEP – Policies 1.0
The purpose of this package is to manage ongoing policy deployment for the environment. This includes deployment of any defined policies in the environment. The configuration shown is the default policy list – as additional policies are added in the FEP node, additional programs are created to manage their distribution. In addition, there are several default advertisements created to cause default policies to be made available to clients.
Note: Programs created in this node should not be changed manually. All updates should be controlled by the system as changes are made to policies in the FEP node.
Advertisements
Advertisements must be created before any of the created packages will take action on clients. A quick look at the advertisements node of the console will show two FEP folders created for organization purposes but the only default FEP advertisements created are those to enable deploying default FEP policies in the environment, as shown. Other advertisements must be created separately. FEP Operations advertisements are created by using the right-click option on collection members while deployment advertisements must be created manually and collections targeted appropriately.
Software Updates
Like any other component, the FEP Agent needs to be kept up to date with definition updates. There are several ways to do that as we will see shortly but in a ConfigMgr environment, most administrators will want to use ConfigMgr itself to deploy updates to the FEP agent. This is easily done by simply choosing to include Definitions in the SUP Classification settings and ForeFront Endpoint Protection 2010 in the SUP Product settings. From there, simply perform a manual or scheduled synchronization of updates and the FEP definition updates will be made available for deployment. In the software updates node, review the ForeFront endpoint protection 2010 definitions and you should see only a single definition bundle that has a green indicator showing it is available for deployment. Create a deployment and deployment package that will make this update available to appropriate clients as shown.
From here it’s a matter of keeping the definitions up to date on a regular basis by performing routine synchronization of updates and configuring the SoftwareUpdateAutomation tool.
Synchronization Schedule
FEP 2010 definition updates release 3 times per day – even though this is the case it is recommended to set the Software Update synchronization cycle to only run once per day. Manual synchronizations followed by manual execution of the SoftwareUpdateAutomation tool can be done if needed in between.
SoftwareUpdateAutomation Tool
The softwareupdateautomation tool is a utility provided to help ease administrative load of keeping definition updates up to date. The tool is configured as a scheduled task and ideally should be configured to run after the ConfigMgr software update sync is complete.
To install the tool, download and install it from https://technet.microsoft.com/en-us/library/hh297450.aspx.
One note about my experience installing this tool - the command line arguments have information enclosed in quotes (“). It may be that you need to apply hotfix 951246 in order for the scheduled task to complete successfully.
The finalized installation should look similar to the following.
A note here about the arguments passed to the command line. Make sure you configure the command line as it is documented in https://technet.microsoft.com/en-us/library/hh297450.aspx which includes reference to the /UpdateFilter switch and also the /RefreshDP switch. Failure to include these switches may result in incorrect behavior as documented in https://blogs.msdn.com/b/minfangl/archive/2011/07/21/fep-2010-definition-update-automation-tools-issues-workarounds-and-best-practice.aspx. An example of the command line used in the demo environment is as follows.
“%ProgramFiles(x86)%\Microsoft Configuration Manager\Adminui\bin\SoftwareUpdateAutomation.exe” /AssignmentName DeployFEPUpdates /PackageName FEPDefUpdates /RefreshDP /UpdateFilter “ArticleId=2461484 AND IsSuperseded=0 AND IsEnabled=1 AND IsExpired=0”
Desired Configuration Management
The installation of FEP adds a number of Configuration Items and Baselines to DCM that is used to evaluate the status of various FEP components. This information is used as criteria for collection membership and more. Where assigned, evaluations are configured to happen hourly by default.
ForeFront Endpoint Protection Node
We will return to this node for detailed discussion shortly – for now, just note that it was added as part of FEP installation.
ForeFront Reporting
In addition to other components, FEP installation also results in reports being added to the environment. These reports require SQL Server Reporting Services but are not accessible via the typical ConfigMgr reporting node. To access the FEP reports use the Reports node inside the FEP console node. Alternatively, access the reports directly from SQL Reporting Services web page as shown. Note the path to the FEP reports on the SQL Reporting Services web page.
By default only three reports are added but there are a good deal more that are available in the FEP install folder. These reports are stored as .RDL files and are specifically located in Microsoft ForeFront\ForeFront Endpoint Protection\Reports\Reports\AMReports as shown
These reports are actually already imported into the report database but hidden from view. If you open the report server URL (/reports">https://<ReportServerName>/reports and the select Details view you will see them all.
If you want to make these visible in the default page just open the properties of the report – or manage them – the way to do this will be slightly different based on the version of SSRS in use – and select to unhide them from the list.
SQL Databases
FEP installs two new databases to support operations. The first, FEPDB_<sitecode> is for FEP server operations. The second, FEPDW_<sitecode> is the data warehouse.
Exploring ForeFront Endpoint Protection 2010
ForeFront is installed and we have verified all of the pieces are in place – now time to review the ForeFront component itself, see what default configurations are available and how it might be customized. Let’s start with the dashboard view.
As mentioned earlier, the dashboard view is the nerve center for understanding the current state of ForeFtont. At a glance the dashboard shows the current deployment status of FEP agents, the security status of the environment, which agents have outdated definitions and whether FEP policy has been distributed to agents. In addition, the ForeFront DCM Baseline values are visible along with their last evaluation state. The dashboard stays up to date as collections update and new information comes in. If you want to force the dashboard to refresh simply right-click on the ForeFront Endpoint Protection main node and select Run Operational Statistics Update.
Taking a look at the ForeFront Endpoint Protection node specifically we see three configuration options – Policies, Alerts and Reports. The Policies node is where most of the action is for FEP. By default two policies are configured for the environment – one for desktop systems and one for server systems. It’s possible to create a new policy template from scratch or import a policy template to match a system workload you might have in place. It’s also possible to set the order of policy precedence which allows administrators to configure which policies should be evaluated at a higher priority. Right-clicking on the Policies node reveals the options.
We will review the settings available in a policy shortly – it’s up to the the administrator whether to use the default policy templates, create totally custom policy templates or import policy templates. One thing to note – it is not possible to change anything in the default policy settings. It is possible to copy a default policy to a custom version that can be edited. To demonstrate the policy settings and also to show the policy templates available for import we will import a policy geared to Hyper-V servers and then walk through the available settings.
The Hyper-V policy is imported. This results in an additional program being added to the FEP Policies package but no advertisement has yet been created. Right-clicking on the imported policy shows an option to assign the policy (Note: Default policies cannot be assigned as they are already associated with default FEP deployed server and workstation FEP collections). This will result in the policy being associated to a collection which would cause an FEP Policy advertisement to be created. We won’t assign the policy but will instead select properties to review available settings.
The properties window opens up to the General tab. This tab shows the policy name, a description of the policy, any collections where the policy has been assigned and policy version, creation date last modified information, etc.
The Antimalware tab provides options allowing administrators to configured scheduled scans, default actions, real-time protection options, excluded files and locations, excluded file types, excluded processes, advanced options, override information and settings regarding Microsoft Spynet. These various screens with available configuration options are shown below.
The updates tab allows administrators to configure how definition updates for the FEP agent are delivered. With FEP Rollup 1 administrators are able to use native ConfigMgr as described earlier but also have the choice to use WSUS directly, use Microsoft Updates or even a file share.
The last node, Windows Firewall, allows administrators to configure various Windows Firewall settings if desired.
The Alerts node allows administrators to configure notifications when certain malware events take place. The vehicle for notifications is email. Email settings are configured from the right-click menu of the main alerts node.
There are four alert categories – only one the Malware Outbreak Alert option has a default alert configured. Note the default alert is shown in the graphic below. Also show is the right-click menu option available for all other alert settings that may be created if needed.
The last node, reporting, has already been discussed.
Summary
That’s about it – setting up and configuring FEP integration for ConfigMgr 2007 is not difficult and brings another layer of value to the investment you have already made in ConfigMgr. We will take a look at the integration of FEP into ConfigMgr 2012 in a future discussion.
Two final notes – if you are looking for FEP related logs they are located under the Programs Data folder on Windows 2008 systems. In addition, if you are using OpsMgr and would like to monitor FEP, there is a management pack available.
Comments
Anonymous
October 26, 2011
Hi Steve, re: 'FEP 2010 definition updates release 3 times per day – even though this is the case it is recommended to set the Software Update synchronization cycle to only run once per day.' Could you pls explain why that is? CheersAnonymous
August 24, 2012
That's because you don't want to overwhelm your Central site server with flood of status messages several times a day from all the client in the your SCCM hierarchy. Keep in mind that all clients are essentially managed by your Central site server.Anonymous
February 01, 2013
Hello all,if we integrate the MDT 2012 Update 1 into SCCM 2007 SP2 R3, will there be the chance for official Windows 8 os deployment support via the integrated MDT task sequences? www.reportingsoftware.info/.../reporting-software-the-gray-matter-behind-the-conceptAnonymous
February 04, 2013
ConfigMgr 2007 does not support deployment of Windows 8 at all, regardless of MDTAnonymous
March 19, 2014
Do all of the FEP statusreporting flow through the site server to the central server or does FEP data flow directly to the central server?