Disable Forefront Endpoint Protection 2010 Desktop Alerts

There's an overview of deploying the client here

A couple of things to check for any software distribution troubleshooting:

• Look at the c:\windows\system32\ccm\logs\execmgr.log on the client. This is the log that tracks package installs
• Are the clients actually in a collection to receive the package?
• Is the advertisement mandatory? If you just set a start date with no mandatory installation date, the package will not run

You'll need the second NIC in a different subnet in order for Windows routing to be happy. Then, TMG NATs between the internal subnet, and the external subnet (using the Edge layout anyway).

To push all traffic through the TMG box, point clients to it as the default gateway. It's likely to be a fairly major change to how the network works at the moment, so have a rollback strategy.

In order to do this most easily (but with a significant change), switch the current D.G. to a different subnet (say, a 10.x subnet so it's nice and visually differentiated), plug the other TMG adapter into that subnet, and allow that subnet to be considered external by TMG (i.e. do not include it as an "internal" network) - that way, anything not in the currently-defined Internal IP range will be considered potentially hostile. (Or at least External; TMG doesn't trust Internal networks implicitly).

The 10.x network essentially becomes a DMZ of sorts - your router (I assume is currently NATting to the ISP) can forward incoming requests to the external interface on the TMG box, and TMG firewall policy will control all traffic into and out of the 192.168.1.x network.

For ease of migration, if you go with that, the internal interface of TMG should assume the old IP of the router, i.e. the already-configured-on-clients default gateway.

For advanced Web use, i.e. authentication if required, configure WPAD to give clients explicit knowledge of the proxy.

Alternatively, leave everything as it is, ignore the second NIC, and use TMG as an explicit web proxy, configured either as http://tmg:8080 on clients, or through WPAD. It won't do whole-network content filtering, but it will at least do web traffic scanning in that configuration, and allow you time to get more familiar with it before embarking on the Massive Outage Path.

Better still, test your intended setup using a lab or virtual machines.

Just a thought.

Edit: One more very, very general tip: At some point, you're going to be tempted to create a rule that says "Allow anything anywhere anytime". If you do succumb to that temptation, make sure you exclude the Local Host network from it, so that at least TMG is still performing some local packet filtering to defend itself from nasty internal/external clients. (NAT tends to take care of most incoming traffic from outside, but there's always external misconfiguration to worry about).

If you want TMG to be able to connect to, or be connected to by, something, System Policy is where to do that. And as another-nother tip, if you don't allow any incoming connections to TMG other than RDP, you'll basically* be able to ignore* most* security updates* that are released*. Which is nice for the uptime. Plus! NIS gets updates when MSRC release bulletins, so there's an additional level of protection there too. Just don't get complacent.

' * - don't do this.