The official blog of the Microsoft System Center Configuration Manager Product Group
With the integration of Endpoint Protection into System Center 2012 Configuration Manager, it’s easy to get your clients rapidly protected from malware, and managed by System Center 2012 Endpoint Protection as part of the operating system deployment (OSD) process. Here, I’m going to cover the steps you should use as best practices for installing the Endpoint Protection client and definitions as part of an OSD task sequence. The steps hare are an optimized way to assure clients can get definitions during the task sequence, and in a way that minimizes any potential bandwidth impact of the Endpoint Protection client downloading the 60+ MB engine and definition payload over the WAN.
As a general recommendation, it’s also important that you keep your images up to date with offline servicing of your images so you minimize the number of updates you have to apply as part of your task sequence (if you use that step to apply updates). That’s not directly related to the process for deploying the Endpoint Protection client and definitions outlined here, since that’s done independent of the apply software updates steps, it’s just a general guidance point to optimize operating system deployment performance.
At a high level, this process covers targeting the client settings policy to the collection for managing Endpoint Protection, creating and updating (with a script and a scheduled task) a source folder for definitions, building packages and programs for the Endpoint Protection client and definitions, then adding those as task sequence steps to your OSD process. I’m assuming that you have some knowledge of OSD generally, so I’m not going to cover OSD in much depth, focusing primarily on the pieces for integrating Endpoint Protection optimally into your task sequence, as well as some process guidance on keeping definitions up to date.
The Endpoint Protection client can be installed and managed, or just managed via client settings. If the client gets a policy to install the Endpoint Protection client, and the client already exists, then it will simply start managing the existing Endpoint Protection client. By installing the Endpoint Protection client as a package after the Configuration Manager client installation step in the task sequence, the Endpoint Protection client will be installed prior to the client receiving client settings policy to install it. So when the client gets the client settings policy later, it will become managed, but not reinstalled. To make a long story short, for clients running the task sequence, it doesn’t really matter if you target them with the Endpoint Protection installation or manage-only policy—the client will already be installed by the task sequence by the time the client gets policy, and it will simply become managed at that point.
Since we are going to use packages and programs to deliver the initial definitions during OSD, we need to first create a source for those definitions and have it update it automatically. The reason we recommend this approach as opposed to using the software updates step available in the task sequence, is that allows you to just update definitions, and it doesn’t require all updates available to be scanned against and applied. Since we’re simply launching a binary with the latest definitions, your client doesn’t have to run a compliance scan for updates, which makes for a faster way to update your Endpoint Protection definitions immediately after you install the client. There’s nothing preventing you from using the apply software updates step in conjunction with a package, but to expedite the delivery of definitions to occur as soon as the Endpoint Protection client is installed, using this package process is the way to go. Also, using this process, along with the command line and AM policy settings referenced later, assures that definitions are installed as part of a package, and not downloaded over the WAN by your client.
The first step is creating your definition update source, which will serve as your Configuration Manager package source. You can create that source on any path accessible to your Configuration Manager site- server, and then use the script process documented here, or full script example here, to download the definitions into your defined paths. Obviously, you will need to modify the scripts to map the paths you choose to use as your package source. You can also use this process to stage your initial Network Inspection System (NIS) definition updates as outlined in the link. These can be in the same folder as definitions—you just need to separate folders for 32 and 64 bit flavors of both EP and NIS definitions.
To automate the script, you can simply run it as a scheduled task on the server hosting your definition source, as frequently as once a day to get the latest definition files. We don’t recommend that you synch more than once a day as this will put unnecessary strain on your content distribution system, and to service OSD that’s frequent enough. The client will get any updated definitions through your standard definition-deployment process post-OSD.
After we have the definition source and automated update process squared away, the next step is to go ahead and create the packages that we will use in the task sequence to deploy the client. In Software Library, under Application Management | Packages, choose to Create Package. The first package we need to create is for the Endpoint Protection client. You can get the client, SCEPInstall.exe, from the Client folder in your Configuration Manager site-server installation folder, and copy it over to wherever you want to source this package from. You will also need a simple CMD file (step 1 below) and a base antimalware policy XML file as we’re going to call that with SCEPInstall.exe /policy, so 1) the desired policies can be configured at install time (through any modifications you choose to do to the policy file), and 2) so we can set DisableUpdateOnStartupWithoutEngine, which is required to assure clients get their definitions from the next step in the task sequence, not as a download from an alternative source. Let’s walk through the steps:
Next, we need to create the package to deploy the definition updates. Similar to the steps above, launch the wizard, name the package and browse to the source location (use the root of the folder that has folders for both the 32 and 64 bit definition binaries), and then choose standard program. Here, we will need to create separate programs (4 total), with one each for definitions (mpam-fe.exe), and Network Inspection System (NIS) (nis_full.exe), for both 32 and 64 bit. There are no switches required for these binaries. Also, set the package to run normal, whether or not a user is logged on, and run with administrative rights. Leave the requirements page as is, and finish the wizard.
With both packages now created, you’ll want to schedule the definition package to update distribution points on a schedule. Go to package properties, and under data source, select update distribution points on a schedule (no more than once a day), and align that schedule with the scheduled task you have running to update definition files into the source directory. Now you have both packages you need to add to your task sequence.
I’m assuming that you already have an OS image created to use, and possibly a task sequence, so I’m not going to go step-by-step here. The steps are pretty simple: just take the packages you created for the Endpoint Protection client and definition updates in the previous step, and through task sequence editing, add them, via General, as Install Package actions. The order for these packages should be client, definition, and then NIS definition update. After you’ve confirmed dependent files for these packages, as well as your base image and boot wim have been distributed to the appropriate distribution points, you’re ready to go ahead and validate everything by launching the OS deployment on a test client. After completing the task sequence, you should see in the full OS a working Endpoint Protection client showing green, and under the update tab on the Endpoint Protection client UI, you will see the latest definition applied. From this point forward, definitions will be distributed either through the Auto Deployment Rules you’ve created (using the Software Update Management feature), or through the Endpoint Protection client pulling definitions from the source order you’ve defined in an antimalware policy.
Getting the Endpoint Protection client deployed as part of your operating system deployment is an important part of securing your systems. Delivering the Endpoint Protection client and definitions in the task sequence as packages, is a great way to deliver antimalware services rapidly during OS provisioning, and to do so in a way that minimizes bandwidth impact. Hopefully it’s clear how to best achieve that from what I’ve provided here.
This posting is provided "AS IS" with no warranties, and confers no rights.
I see what you are saying but I want to make sure I am following you correctly? Need additional explaining.
Is there a new set of standalone tools for AD / GPO management or are we supposed to continue using the 2010 tools (www.microsoft.com/.../details.aspx)?
This works great!
The computers are coming out with FEP fully updated.
But some deployments are coming out with with "EP Deployment State: Unmanaged" in the console.
Any ideas on this?
Sorry, JBennett, I haven't looked at comments here in a while. Are you setting client settings for Endpoint Protection to Install or Manage per the steps in this blog? If so, is unmanaged a temporary state or stuck in that state for X hours/days (and if stuck, for how long)?
I'm trying to implement scepinstall.exe /s /q /NoSigsUpdateAtInitialExp /policy %~dp0EPAMPolicy2.xml to stop our EP clients from hitting the web. Unfortunately, it appears the EPAMPolicy2.xml file attachment is broken, which is a show stopper.
I've searched for an explanation of the Endpoint Policy xml file settings without luck, or I'd simple insert the DisableUpdateOnStartupWithoutEngine in the appropriate location of an exported policy.
Will this package work if we convert it to an MSI Application using the Package Conversion Manager
When we use the given command-line we get error "The Policy <Location of the XML> was not found or could not be validated. Please verify that the policy name and location are correct and then run the wizard again." Policy lies at the location but still the same error.