Operating System Deployment and Endpoint Protection Client Installation

[Yvette O'Meally]

First published on CloudBlogs on Apr, 12 2012

7/12/2013 - Creating the Task Sequence With Endpoint Protection Packages section was updated.

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.

Client Settings Policy for Endpoint Protection

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.

Definition Update Source

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.

Configuring Packages

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:

1. Create a simple .CMD file with the scepinstall.exe and required switches called:  scepinstall.exe /s /q /NoSigsUpdateAtInitialExp /policy %~dp0EPAMPolicy2.xml
2. This .CMD file will be what we call in the command line when we build the program next.  Here’s what each switch means:
   1. /s = silent setup.
   2. /q = silent extraction of the setup files
   3. /NoSigsUpdateAtInitialExp = No definition updates as part of the installation.  This is done so that you can assure that the installer doesn’t reach out to a remote source like Windows Update to get the initial definition and engine update.  Definitions are delivered as their own package in the next task sequence step from the distribution point, which reduces potential WAN impact.  Note:  The AM policy settings for DisableUpdateOnStartupWithoutEngine is also required, otherwise clients will also try to update definitions from a remote source at service startup.
   4. /policy=applies the specified AM policy file at install.
   5. %~dp0EPAMPolicy2.xml = assures that the policy file is called from the local path when referenced by SCEPInstall.  The /policy switch requires a specific path, and this string assures that a local path is called (the same path used for your Endpoint Protection client package).
3. Create a source folder for the package and copy SCEPInstall.exe, the attached AM policy (modified to your preferences), and the .CMD file created in step 1 to it.
4. In the Create Package and Program wizard, name your package, and select “This package contains source files”, and browse to the location where you placed the .CMD file  to select that file as the command line to run (either as a local source or UNC).  On the next page, choose standard program.
5. On the standard program page, name your program, and then again browse to the location where you’re hosting the CMD file.
6. Set the package to run normal, whether or not a user is logged on, and run with administrative rights.
7. Leave the requirements page as is, and finish the wizard.

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.

Creating the Task Sequence with Endpoint Protection Packages

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.

Update Note: If the Endpoint Protection client is embedded in the OS image then delete from the image, the following registry keys that are unique to the machine that was used for developing the image during SYSPREP process.

1. HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft AntimalwareInstallTime
2. HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft AntimalwareScanLastScanRun
3. HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft AntimalwareScanLastScanType
4. HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft AntimalwareScanLastQuickScanID
5. HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft AntimalwareScanLastFullScanID
6. HKEY_LOCAL_MACHINESOFTWAREMicrosoftRemovalToolsMRTGUID

Wrapping Up

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.

-- Jason Githens

This posting is provided "AS IS" with no warranties, and confers no rights.

EPAMPolicy2.xml