FEP 2010 is implemented as both an extension to System Center Configuration Manager and as a management pack for System Center Operations Manager, which provide enterprise management experience, and a common client (agent) that provides protection on managed machines. That means that if you have System Center Configuration Manager, or System Center Operations Manager installed, then all you have to do is to install the extensions for Configuration Manager, or import the FEP 2010 Security MP into your existing Operations Manager infrastructure in order to add Endpoint Protection functionality.
FEP 2010 has two major System Center components - an add-on for System Center Configuration Manager 2007 (“ConfigMgr”), and one for System Center Operations Manager 2007 (“OpsMgr”). Each FEP component leverages the unique capabilities of the associated management product. Due to differences in the capabilities of ConfigMgr and OpsMgr, each FEP component delivers different functionality.
The FEP extension for ConfigMgr provides deployment, monitoring, reporting, and policy management functionality for FEP, from directly within the ConfigMgr console. The OpsMgr MP provides monitoring and alerting from within the OpsMgr console.
FEP gives you a choice of two ways to manage policy. First, if you have ConfigMgr deployed and the FEP 2010 product installed, then you can use the FEP node in the ConfigMgr console to author policies. ConfigMgr (via its Software Distribution feature) will deploy the policies for you to the monitored FEP agents. However, if you prefer, or if you do not have ConfigMgr deployed (such as when you are only using the OpsMgr MP), you can use Group Policy to author and distribute policy.
The following chart will help you decide between using ConfigMgr or Group Policy for policy management.
You should consider managing FEP policy with ConfigMgr if…
You should consider managing FEP policy with Group Policy if…
If you ultimately choose to manage policy with ConfigMgr, then you will find that the experience is very straightforward. New policies you create are all based off of a template- you choose a group of settings organized by goal, e.g. “protect domain controllers” or “minimize performance impact to desktops”, etc., and the new policy will contain settings optimized for that goal. You can edit the settings as you wish, and to deploy the policy, simply bind it to a ConfigMgr collection. Only one policy will be in effect for any collection at any given time.
The remainder of this article will describe the experience of using group policy to manage FEP policy.
FEP contains a set of tools for helping to manage FEP policy with group policy. These tools include:
At the simplest level, all you need to do to manage FEP policy with group policy is to install the ADMX into your admin tools workstation, create and link a GPO, and edit the FEP policy settings in the GPO, using Group Policy Editor.
However, there are some more advanced scenarios that you might want to think about.
In this scenario, let’s assume that you want to deploy optimized settings to your servers. For instance, let’s say that you want domain controllers to get a policy that will cause the least performance impact on the domain controller role, and you want Exchange servers to get a policy that will minimize performance impact on Exchange, etc. Let’s further assume that some of your servers might host more than one role.
There are two ways to go about doing this, and how you choose to do this completely depends on how you prefer to do policy targeting in group policy.
If you strongly organize your machines into OUs or security groups, then you might just want to create one policy per role and link it to the appropriate OU, or use security filtering in group policy management console (GPMC) to restrict the policy only to the target group. This essentially allows you to specify the target machines individually.
In this case, all you need to do is to create a GPO, link (and filter, if applicable) it appropriately, and then use the FEP group policy tool to import the correct role-specific settings into that GPO.
Here’s a hint- if you have a set of servers that have multiple roles, then you can use the FEP GP tool to import each of the policies into the same GPO. Import the policies in order from lowest precedence to highest precedence, and make sure that you only have the “clear existing FEP settings before import” checkbox checked when you import the first policy. For example, if you have machines that are combination DC + DNS + DHCP servers, then import the following four policies: FEP Default Server policy, FEP DHCP Server policy, FEP DNS Server policy, FEP Domain Controller policy. The “clear settings” box should only be checked when you import the default policy. This will import and merge all the settings into a single GPO.
If you prefer a more dynamic targeting approach, then you can have group policy layer your policies for you. In this case, you simply create one GPO for the FEP default server policy, and one GPO for each server role. Set the default server policy at lowest precedence. Link all the policies to the domain, and use WMI filtering on each of the policies. For instance, you can restrict the default server policy to servers only by filtering on the ProductType property in the WMI Win32_OperatingSystem class: http://msdn.microsoft.com/en-us/library/aa394239(VS.85).aspx. ProductType is also useful for identifying and filtering domain controllers.
For other roles on Windows Server 2008 and Windows Server 2008 R2, you can use the properties in the Win32_ServerFeature class to identify and filter by role: http://msdn.microsoft.com/en-us/library/cc280268(VS.85).aspx. This works well for built-in roles like IIS and File Server.
For Windows Server 2003 machines, and for roles that aren’t part of Windows, you can use the Win32_Service class to look for services that indicate role presence, e.g. the MSSQLSERVER service identifies SQL machines.
After you have created a WMI filter for each policy and linked your policy to the domain, then group policy will automatically deploy the appropriate settings to each computer. It’s important to ensure that you use GPMC to prioritize the policies correctly so that defaults or lower priority role settings don’t overwrite higher priority role settings.
This is a very easy scenario. Once you have authored a policy using GPEDIT, if you are happy with the settings and want to deploy the same settings to non-domain-joined servers, then you can use the FEP group policy tool to export the settings you like to a FEP policy XML file, and then you can script the application of that policy.
The export process varies slightly depending on how you handle multiple roles.
If you merge your roles together into single GPOs (as in scenario 1.1 above), then you can simply use the FEP group policy tool to export FEP settings from that GPO.
If you use policy layering (as in scenario 1.2 above), then you should identify a domain joined server with the same set of roles, which has already had your policies applied, and use the FEP GP tool to export the settings from the local group policy object on that server.
There are two ways to apply FEP policy with script. First, you can provide the path to the policy file as a parameter during installation of the agent MSI package. Second, you can use the ConfigSecurityPolicy.exe tool to apply a FEP policy at any point. These topics are covered in the FEP documentation.
This scenario is also very easy. Simply create GPOs on the “target” domain matching those on the “source” domain, and ensure that they are linked and/or WMI filtered correctly. Then use the FEP group policy tool to export the settings from each GPO in the source domain, and use the tool again to import the appropriate settings into the correct GPO on the target domain.
Eric Fitzgerald, Senior Program Manager