These features are URL Filtering (URLF) which is a form of web content filtering and Anti-Malware or Enhanced Malware Protection (AM or EMP) that scans inbound HTTP traffic downloads.

We have an Enterprise Agreement (EA) which covers having the two features  so I expected to find the key in our License portal. No, that’s too obvious. It turns out that I needed to enter our actual Enterprise Agreement key. The first seven digits of the EA needs to be popped in to the TMG server field in the picture above then Ms’ trusts you to enter in the right date your EA expires. That’s it.

Finding this out took quite a bit of time, numerous emails and careful explanation to people what the heck was WPS in TMG. Finally this link from Ms turned up

Had I found this at the start, well, it would have taken two minutes rather than two weeks.

Or the easy to read version:

FX:{f337d96e-45c1-4106-88b1-e417a7703d6b}

Exception has been thrown by the target of an invocation.

Exception type:

System.Reflection.TargetInvocationException

Exception stack trace:

at Microsoft.ManagementConsole.Internal.SnapInMessagePumpProxy.OnThreadException(Object sender, ThreadExceptionEventArgs e)
at System.Windows.Forms.Application.ThreadContext.OnThreadException(Exception t)
at System.Windows.Forms.Application.OnThreadException(Exception t)
at System.Windows.Forms.Control.InvokeMarshaledCallbacks()
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Now The server and console had been working fine for the last six months without issue. Despite no obvious alerts, warnings or errors in any of the Windows event logs or SQL logs/checks the standard fixes won’t work. Somewhat annoying, but having worked with Forefront for a while now, I took my default posture with these types of problems: Blame SQL.

After taking my problem to The Grumpy old DBA for “his”  SQL databases breaking again, he used his mastery of many years to cut and paste the error in to Google. Dominik’s Forefront Security Blog and this link popped up and refers to kb942581, which is a hotfix SQL script.

From the cause blurb on the page: “A server-side SQL stored procedure that the Forefront Client Security dashboard uses incorrectly calculates statistics when the managed computers have not reported to the collection server for more than 30 days.”

Running the script fixed the problem. Oh joy.

There are some fantastic write ups on how Conficker acts: Sneaky tricks, Autorun.inf , working groups , detection methods and resources.

Here’s how Forefront deals with it.

From a USB drive

When Conficker is on a USB drive, Forefront reports it as conficker.x!inf, x being the version, and happily wipes the autorun.inf file on the USB drive. It doesn’t remove the hidden file at detection; a scan has to be run on the USB drive to remove it. Nice and straightforward.

ON the network

When you get Forefront detected Conficker on a machine warning, this is the time you need to be worried. Why is it a worry?

Well gentle reader, this means Conficker was able to infect the machine and Forefront has stepped in to clean it after the fact.

By after the fact, I mean Conficker has attacked the system and dropped it’s dll and AT1.job in to a local folder on the attacked system.

Look in the attacked machine’s System event log, two Event ID 3004, Source FCSAM followed by a Event ID 3005, Source FCSAM have been generated.

Event ID 3004 is Forefront detecting and suspending the file, Event ID 3005 is Forefront removing the file.

IMPORTANT NOTE:

If someone is logged on to the machine Forefront is protecting and Conficker attacks it, the Forefront icon turns in to a red cross. If the user simply ignores this, that is doesn’t click the icon and press smart clean, after ten minutes Forefront removes or quarantines the file.

This means for those ten minutes the AT1.Job file and the .dll are on the attacked system, despite being in a suspended state. By suspended state, the files are still visible.

So how did Conficker get on the machine in the first place?

There are only three ways that can happen:

1)      Conficker was on the machine before you installed Forefront and Forefront detects it on first scan

2)      The patch to protect against Conficker, MS08-086 KB958644, is not installed and Conficker attacks the machine

3)      And the worst, by far, is an administrative account has been used to attempt to install Conficker on the machine

Ignoring the first way and using the deployment tool of your choice to patch your machines for the second way, let’s talk about big bad number three.

Here are some of the scenarios for way number three can occur first:

1)      You have a terrible password policy and the password of a local administrator account is in the guessing file of Conficker

2)      Conficker successfully attacks a machine left logged in as a local Admin with no AV

3)      Someone with administrator rights plugs in a infected USB in to the machine without antivirus (or the antivirus is horribly out of date)

So having Forefront installed on all machines and up to date is step one. Step two is user education on USB sticks. Step three is an awareness campaign to all of your IT admins. Since you’re using Forefront, Active Directory should be in use as well. If you don’t have money for smarter tools just use software deployment GPO’s to install Forefront and then use WSUS to push out the updates.

So now that I’ve taught you to suck eggs, here are some suggestions to actually help.

Group policy objects (GPO) can aid find Conficker infected machines First enable audit policies (Computer Configuration – Windows Settings – Security Settings – Local Policies – Audit Policies), with the most important being Audit account login events. Set this to success and failure.

With this GPO enabled and applied, when the next machine reports being attacked by Conficker connect to the machines Security event log and filter by Event ID 680. This ID deals with which account login in to the machine and from which machine.

What we want is the 680 successes as our number one priority, as this means Conficker has an account that can connect to the system. The 680 failures still tell which machines are attacking and can be add to the clean up task.

There a number of log parsing tools and scripts out there to automate finding the 680 event id on multiple systems, pick your favourite and use that.

The two pieces of information we are interested in are Logon Account and Source Workstation within the 680 event id. These two wonderful fields tell us which account and which computer successful attacked the machine.

Stating the obvious, run a cleaning tool Ms tool or any one of these or format and rebuild the computer only after taking a copy of the event logs. The more important part is the user account. In a number of companies, every machine has the same local administrator account. If this is a poor password, it is time to change it. Script out a password change for all machines, plenty of examples on how to do this are online.

He got rather concerned about the happy Forefront icon sitting in the system tray of Citrix desktops. If a user decided to kick off a Forefront scan, the Citrix server would ramp up its use of memory and RAM. Not a good thing on busy Citrix server apparently.

I offered to lock down what user could do, but Michael quickly jumped in to the registry and cut out these keys on his farm.

REM Remove User GUI Run Key for Citrix

REG DELETE “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” /V “Microsoft Forefront Client Security Antimalware Service” /F

REM Delete Forefront from AllUsers StartMenu

rmdel c:\docume~1\alluse~1\startm~1\programs\micros~1 /q /s

He’s happy, and the Citrix users are blissfully unaware Forefront is watching their every move….

Had a Forefront client that displayed the annoying* orange alert icon. The system was refusing to get the current Forefront definitions update with a 0×80080005.

A quick search of the web got me no-where.  Back to proper troubleshooting.

Check services (Automatic Updates & Background Intelligent Transfer Service) and WindowsUpdate.log details are the best starting points for these types of errors, so:

%systemroot%\WindowsUpdate.log

2009-07-21                         07:31:23:852           13400           3490            COMAPI      FATAL: Unable to initiate asynchronous search, hr=80080005

2009-07-21                         08:30:53:161           1924              2984            Misc                Logging initialized (build: 7.0.6000.374, tz: +0700)

2009-07-21                         08:30:53:161           1924              2984            Misc                = Process: C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\MpCmdRun.exe

2009-07-21                         08:30:53:161           1924              2984            Misc                = Module: C:\WINNT\system32\wuapi.dll

2009-07-21                         08:30:53:161           1924              2984            COMAPI      ————-

2009-07-21                         08:30:53:161           1924              2984            COMAPI      — START –  COMAPI: Search [ClientId = Microsoft Forefront Client Security]

2009-07-21                         08:30:53:161           1924              2984            COMAPI      ———

2009-07-21                         08:31:23:162           1924              2984            COMAPI      FATAL: Unable to connect to the service (hr=80080005)

2009-07-21                         08:31:23:162           1924              2984            COMAPI      WARNING: Unable to establish connection to the service. (hr=80080005)

2009-07-21                         08:31:23:162           1924              2984            COMAPI        – WARNING: Exit code = 0×80080005

2009-07-21                         08:31:23:162           1924              2984            COMAPI      ———

2009-07-21                         08:31:23:162           1924              2984            COMAPI      –  END  –  COMAPI: Search [ClientId = <NULL>]

2009-07-21                         08:31:23:162           1924              2984            COMAPI      ————-

2009-07-21                         08:31:23:162           1924              2984            COMAPI      FATAL: Unable to initiate asynchronous search, hr=80080005

Not much help, either.

SC Query BITS

SC Query Wuauserv

SERVICE_NAME: wuauserv

DISPLAY_NAME: Automatic Updates

TYPE                                                        : 20  WIN32_SHARE_PROCESS

STATE                                                     : 3  STOP_PENDING

(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))

WIN32_EXIT_CODE                      : 0 (0×0)

SERVICE_EXIT_CODE                    : 0 (0×0)

CHECKPOINT                                     : 0×2

WAIT_HINT                                        : 0×7530

Well that would be the problem, the service has hung; Reboot time.

After the reboot completed, Forefront gets the latest update and the world is a happier place.

*It’s annoying as it means I have to look at the problem

I remembered that FCS Nerds’ Craig Wiands had done a great post on it, so it dug it out and kicked of a simple batch script. Boom – redirected all the  clients before the kettle had boiled!

Find Craig’s guide here

“C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\mpcmdrun.exe” -Scan -scantype 1

Forces an immediate quick scan.

“C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\mpcmdrun.exe” -Scan -scantype 2

Forces an immediate full scan.

Niffy, eh?

When I get in to work and have a number of Forefront generated alerts, I drop the machine names from the alerts in to a text file.
Using Psexec I can then kick of scans of all these machines just to make sure they are clean

Psexec @alerted.txt “C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\mpcmdrun.exe” -Scan -scantype 1

Psexec will go through the list, machine by machine, however, only once it has completed the scan on the machine.
For the more serious alerts I prefer to run a full scan

Psexec @majoralert.txt “C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\mpcmdrun.exe” -Scan -scantype 2

Running a full scan PSexec on 20 normal machines could take hours this way!

NOTE: Running a full scan on a PC won’t make any friends. It will mostly like generate help desk calls on why their PC is suddenly running slowly. You may want to send an email to the user in question before hand – or not you, BOFH, you

On the full scans, I occasionally dump out some of the logs just to have a history file for ammo from the angry user. Forefront does produce a link with alert email, which points to a pretty SQL reporting page, but I still like the raw data.

Psexec @majoralert.txt “C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\mpcmdrun.exe” –getfiles

This, annoyingly, drops the file on the remote machine, so I then have to bring the files to my local machine:

Robocopy “\\machinename\Documents and Settings\All Users\Application Data\Microsoft\Microsoft Forefront\Client Security\Client\Antimalware\Support” c:\dumps\machinename *.*

Here’s a much nicer guide, with pictures, from retrieving and working with the Forefront client log files here.

Should you want to run this a schedule task to kick off a full scan create the task with this undocumented command:

“C:\Program Files\Microsoft Forefront\Client Security\Client\Antimalware\mpcmdrun.exe” -Scan -RestrictPrivileges -scantype 2

I got the call, called up the customer and politely pointed out the Internet was full of Bad Stuff™ and it’s a good idea NOT to uninstall, especially as it broke IT policy doing so.

The conversation went a bit “odd” .

He knew better than any of us and bluntly informed me he never goes to bad sites or opens unknown attachments, thus he was safe. He didn’t need it at home and he sure didn’t need it at work. Especially as “we” used it to spy on him.

Er. Right. Okay then.

Moving along quickly. As he had local admin rights on the box, I started to look at changing registry keys to blocking the further uninstalling Forefront. Yaniv Feldman came to my rescue with a new blog posting on exactly how to do this saving quite a bit of time for me.

http://blogs.microsoft.co.il/blogs/yanivf/archive/2009/01/09/temper-protection-in-forefront-client-security.aspx

Sadly, Yaniv offers no suggestions on managing paranoia.

After building a lab or two and talks with Ms (thanks Lee!) I discovered the new client build, 1.5.1958.0 KB956280 fixes the problem. Have deployed it to a number of previous problem sites and DPM is behaving itself nicely.

As a note the previous version 1.5.1955.0 KB952265 didn’t fix this issues on our production or my lab environments. Weird!