CCMEXEC.COM – System Center blog

CCMEXEC.COM – by Jörgen Nilsson

Browsing Posts tagged FEP 2010

I wrote a post a while back on how to install the SCCM 2007 Admin Console including R3 and required hotfixes:

In that post i also promised to write a post on how to install the SCCM 2007 Admin Console + R3 + FEP.
It turned out to be a bit of a challenge as the FEP installation is either 32 or 64 bit depending on the operating system you install the admin console on. After a re-write here is the updated script, I used the RTM version of FEP and included the Update Rollup 1 in the script, so if you are using the updated media remove the part in the script and the folder for the KB.

The script has been tested on Windows 7 32 & 64 bit, the SCCM console will be installed to “C:\program Files\Configuration Manager 2007″ or “C:\program files(x86)\Configuration Manager 2007″ depending on the operating system architecture.

To implement it the following steps are needed:

  1. Download the ZIP-file containing the script and folder structure: Adminconsole_sp2_r3
  2. Unzip the files and folder to a catalog which will be used as source folder.
  3. Copy the necessary source files to the different directories from the original media:
    adminconsooleinstall_FEP1 Tip: you can skip the “WAIK” folder in the Configuration Manager 2007 Sp2 source files, then you will save a lot of disk space.
  4. As the FEP files and updates are both 32 and 64 bits the FEP_Console folder is divided in a 32 and 64 bit folder:
  5. The same goes for the FEP Update rollup 1 update, although they are not named the same and can be placed int the same folder. The update can be downloaded here:
  6. adminconsooleinstall_FEP5When all the source files are copied to their correct location, create a package using the folder created earlier with folder containing the “Install_FEP.vbs” as source folder.
  7. On the “Reporting” tab for the newly created package enter the below information, as the hotfix for SCCM 2007 R3 restarts many services including SMS Agent Host the script will generate a .MIF file which is the only way of reporting back that the installation was successful:
  8. Distribute the content to the DP’s
  9. Create a new program with the following command line “cscript.exe fep_install.vbs”
  10. Then advertise the program to a test collection and verify that everything is working as expected.

I hope it will be useful!

In Forefront Endpoint protection 2010 there is no possibility to password protect the uninstallation of the FEP client. This makes it possible for instance for local admins to remove the FEP Client.
I started testing to advertise the FEP client to the “Locally Removed” collection where the client will end up if the FEP client is uninstalled. At least that was what I thought…

The above statement is true if you install the FEP client using the Package/program and advertisement in SCCM if you deploy the FEP client using for instance an OSD task sequence, or manually the client is added to the “Not Targeted” collection instead.

Note: And if you wonder the installation and the uninstall of the FEP client triggers a SCCM hardware inventory on the client immediately, to speed up the process of reporting an updated inventory to the SCCM server.

So, I solved it using the following setup in SCCM, including a standard exclusion collection as the customer asked for the possibility to exclude certain computers from FEP.

I have created two sub-collections for my Microsoft FEP collection:

-FEP – Install

-FEP – Exclusion


The following query is used for the FEP – Install Collection:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.ResourceId not in (select distinct SMS_R_System.ResourceId from  SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "Microsoft Forefront Endpoint Protection") and SMS_R_System.ResourceId not in (select distinct SMS_R_System.ResourceId from  SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS_64 on SMS_G_System_ADD_REMOVE_PROGRAMS_64.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName = "Microsoft Forefront Endpoint Protection") and SMS_R_System.Active = 1 and SMS_R_System.ResourceId not in (select ResourceID from SMS_CM_RES_COLL_02000087)

When you import the query change the SMS_CM_RES_COLL_02000087 in the query to reflect the CollectionID of the FEP-Exclusion collection in your environment.

The query includes:

  • Only active clients
  • Coputers where Microsoft Forefront Endpoint Protection client is not installed, both x86 and x64
  • Computers that are not members of the FEP-Exclusion collection.

You can limit the FEP-Install collection to for instance “All Windows Workstation and Professional Systems” if you don’t want to include servers.

Then I advertise the Microsoft FEP client package using the package/program included in the installation of FEP and advertise it with the following settings:


Then the installation will rerun even if the FEP client is removed and added back more than once.

I hope this is useful to more than me.

After 4 weeks’ vacation I started working again and the first thing I planned to do was to implement the new feature in FEP 2010 Update Rollup 1 for automating approval of FEP 2010 definition updates in SCCM instead of doing it separately in WSUS on the SCCM server as many of us do today.

UPDATE:! ——————————————————
A new version of the SoftwareUpdateAutomationtool.exe has been released it can be downloaded here:
When using this updated tool the challenges with the original version has been solved, the command line below in the .cmd file using the new version used should be:
“e:\program files (x86)\Microsoft Configuration Manager\AdminUI\bin\SoftwareUpdateAutomation.exe” /AssignmentName FEP2010SignatureUpdates /PackageName FEP2010Signature

The rest of this article is still valid.


I found that the documentation was not that clear and that included using a Scheduled task which I cannot simply use when we have Status Filter Rules in SCCM which is so cool ;-)

The guide on Technet describes how to create the necessary Software Update packages and copy the softwareupdateautomation.exe file to the correct location so I will not go into detail about that. You can find the installation instructions here:

This is what I ended up doing to get it to work:

1. Follow the instructions on the Technet article until it is time to create the Schedule task.

2. Then copy the softwareupdateautomation.exe as described to the correct location(it must be executed from the AdminUI\Bin directory:
%ProgramFiles%\Microsoft Configuration Manager\AdminUI\bin, if the computer is a 32-bit operating system.
%ProgramFiles(x86)%\Microsoft Configuration Manager\AdminUI\bin, if the computer is a 64-bit operating system.

3. Then I created a simple .cmd file which I placed in a directory on the SCCM Primary Site server, E:\sccmtools.
I run all my status filter rules script from the same location. It is really easy to test that the command line works, just execute it with Admin privileges and check the SoftwareUpdateAutomation.log file for status information. The log file can be found here:

4. The following command was the one I used in the .cmd file, replace the AssignmentName and PackaegName to reflect your environment:

"e:\program files (x86)\Microsoft Configuration Manager\AdminUI\bin\SoftwareUpdateAutomation.exe" /AssignmentName FEP2010SignatureUpdates /PackageName FEP2010Signature /UpdateFilter "articleid='2461484' AND IsSuperseded=0 AND IsEnabled=1 AND IsExpired=0" /refreshdp

5. Then I created a Status filter rule on the Primary SCCM Site Server which looks like this:


6. Using this status filter rule the SoftwareUpdateAutomation.exe will be triggered each time the WSUS Sync Manager reports that synchronization is completed. No schedule task needed!

7. Change your FEP policies to use the new update option below and you are good to go:


The command line took a while to get to work as the documentation is not correct on the Technet webpage as I am writing this at least.
Also the help information for the softwareupdateautomation.exe tool states that /refreshdp is default true but it is not so /refreshdp must be used.
I strongly recommend reading this article with some other known errors.