Forefront Endpoint Protection (FEP) 2010 and ConfigMgr OSD Task SequenceWritten by Andy
Microsoft’s preferred delivery and management mechanism for the Forefront Endpoint Protection (FEP) 2010 client is apparently ConfigMgr. Deploying the FEP 2010 client to a running ConfigMgr client is relatively painless, but getting the FEP 2010 client installed and up to date as part of an OSD task sequence can be a royal pain.
There are a few potential pitfalls you will need to be aware of and I’ve attempted to list them in the order you’ll likely find them.
Run from Distribution Point
If you want to run your Task Sequence with the “Run from Distribution Point” option, you can forget about using the default ‘Install’ program in the ‘Microsoft Corporation FEP – Deployment 1.0″ package that gets created out of the box – it’s no good for us in this scenario and there are a couple of reasons why not; not least that various well respected Microsoft MVP’s state categorically that it has to be downloaded locally first.
But why? Well, I’m assuming you unticked the ‘Allow users to interact with this program’ option on the ‘Install’ program environment options and then created a new ‘Install Software’ step in your task sequence and found the step is failing in your task sequence…
- Error 2147942401. Result = No FEP 2010 Client installed. This is because the ‘Install’ program makes use of a script called ApplyPolicy.vbs – which if you poke around inside it you will see that it attempts to create a WMI class by writing and compiling (using mofcomp) a file called ‘CCM_ISV.mof’. The creation of this file will fail because the SYSTEM account cannot write into the current working directory – which will be your DP. Contrary to some suggestions out there, changing the ‘Install’ program environment properties to ‘Requires drive letter’ will not help you here, it’s totally a permissions thing and the error will be the same.
There are a a few blog posts kicking around that suggest creating a new install program using just the command line ‘FEPInstall.exe /s /q’. This will work with ‘Run from Distribution Point’, however you end up with a deployed client without a default policy and it is not locked down, therefore I wouldn’t go down this route. You CAN specify a default policy to apply using the /policy switch on the command line, however this would require the full path specified to the policy file otherwise you will get;
- Error 2147156116. Result = No FEP 2010 Client installed. This is because the policy file specified was not found.
You need to hardcode a path or create an install.cmd in the root of the package source to run on your program command line which makes use of the %~dp0 variable internally. e.g:
"%~dp0FEPInstall.exe" /s /q /policy "%~dp0Policies/Default Desktop Policy.xml"
Whilst the above solution certainly works, it is not the best solution as you are straying away from how Microsoft intended you to install the FEP 2010 client using the ApplyPolicy.vbs script. This script does some clever stuff like handling the creation of a WMI class that is needed to house a FEP policy and can pull down any existing policy which may apply to the system being built/refreshed – but I don’t profess to understand it 100%.
My preferred method of installation is to use an install.cmd which first copies down the FEP 2010 client install folder locally to %TEMP% and then runs the correct command line for the install from there;
xcopy "%~dp0*.*" /e/s/y "%TEMP%\FEPInstall\"
cscript.exe Policies\ApplyPolicy.vbs "FEPInstall.exe /s /q "
This is pretty much running the installation as Microsoft intended – but giving us the bonus of being able to use the ‘Run from Distribution Point’ setting on our task sequence advertisement, if we wanted to, without the ApplyPolicy.vbs script encountering permissions issues. You could of course tidy up afterwards by deleting the %TEMP%\FEPInstall folder.
NOTE: I really wish Microsoft would incorporate a ‘Download and Run’ option on a per-task sequence step basis.
Congratulations! You should now be seeing a successful Forefront Endpoint Protection 2010 client install in your task sequence, but there may be more to do…
Initial Updating of the FEP 2010 Client
It is not an unreasonable thing to expect the newly installed FEP 2010 client agent to be up to date as soon as it is deployed, and the client attempts to take care of this itself moment after installation during OSD but it will likely fail and leave the user vulnerable until the issue is resolved either manually or (eventually) by ConfigMgr performing a Software Updates cycle.
I’m assuming you have gone through the usual steps of enabling an auto-approval rule for FEP 2010 definition updates on your WSUS server and that you may also have downloaded and implemented the ‘SoftwareUpdateAutomation.exe’ from the latest Update rollup for FEP? If not, you should – but I won’t go into that right now. You basically want your WSUS server and ConfigMgr servers sorting themselves out with the latest FEP 2010 definition updates at least once a day.
So you have all of that in place, but still you are left with a FEP client that isn’t up to date shortly after build, why? The most likely explanation is;
- Corporate Proxy Rules. Your corporate Internet proxy may not be allowing outbound traffic from non-authenticated users. You will see this in the ‘%windir%\windowsupdate.log’ on the client shortly after installing FEP 2010 as repeated http send request failures.
- FEP 2010 Definition Updates not targeted at build collection. It has always been a hack job getting Software Updates applied to a new system being built – the concept of having to target your Live Updates at collections of existing systems AND ALSO to the collection to which the Task Sequence is pointed at is most annoying. This doesn’t help much anyway during OSD, as you’ll discover.
If the machine that FEP 2010 is installing onto is able to get straight out onto the Internet then it will likely update itself directly from Microsoft, which you will see in the ‘%windir%\windowsupdate.log’ as showing data coming from ’http://download.microsoft.com/…’ in which case all is well. You must consider however that the FEP updates can run to around 130MB, and if you also don’t fancy opening up your Internet proxy to anonymous usage (and you shouldn’t!) then ideally we need our own internal WSUS server/ConfigMgr Software Update Point (SUP) to service the initial FEP request for Definition Updates - but this is frustrating during OSD…
- NO WSUS Server set. Here’s the pig! During an OSD task sequence the ConfigMgr client is in a ‘provisioning mode’ – that is to say, the client agents are not fully enabled. This means that the local Automatic Updates policy has not been fully configured with a local SUP server name and this will cause the FEP 2010 client to resort to trying to go outbound. An ‘Apply Software Updates’ step ran before the FEP 2010 install step temporarily encodes the SUP server name and deploys any Software Updates targeted at the build collection – but from what I have seen this setting doesn’t stick around for the FEP 2010 post-install update to use. If your next thought was to maybe run the FEP 2010 installation and then an ‘Apply Software Updates’ step this still seems to result in the FEP 2010 client generating http send request failures in the Windows Update Agent (windowsupdate.log). The FEP 2010 client did seem to get updated using this method on occasion, but it was very hit and miss.
After a lot of experimenting to generate a consistently successful installation and update, the resolution for me was to change at what point I install the FEP 2010 client during OSD and relying on timing! I kept the installation of the FEP 2010 client away from the main bulk of Software Applications and instead I have the very last two steps of my OSD task sequence to run my custom FEP 2010 client install command and then a ‘Restart Computer’ step without a delay back into the Installed Operating System. This seems to have the desired effect of getting the FEP 2010 client to use the WSUS server as configured by the now active ConfigMgr client.
I have noticed that for this trick to work though, you DO need to have an ‘Install Software Updates’ step in your task sequence.
Latest from Andy
- ConfigMgr 2012 SP1 with MDT 2012 Update 1, UDI Task Sequence and Bitlocker Error 6767
- ConfigMgr 101: Patience dear boy… SMS_SERVER_BOOTSTRAP
- ConfigMGr MPControl.log: Call to HttpSendRequestSync failed for port 443 with status code 403, text: Forbidden
- ATI Catalyst Drivers Installation
- ConfigMgr 2012: 64bit file system redirection bites again…