Installing a TMG Enterprise Management Server and Migrating and Existing Standalone Array: Part 1
This is my current scenario: there are two existing servers in a stand-alone array – TMG01 and TMG02, and over in a DR site there is a new server (TMG03) that is in the process of being built. To comply with DR, all 3 servers must have their configurations up to date, however there is no direct communication allowed between the two DMZs, so simply adding to the new server as an array member is not possible.
Fortunately, IPSec is allowed between each DMZ and the management DMZ so the plan is to configure IPSec between a new Enterprise Management Server in the Management DMZ (we”ll call it EMS01) and each of the three TMG servers.
More notes on Threat Management Gateway Arrays
Get the NICs right first
In this case I came to a project after the initial installation of the array and there was no dedicated intra-array network installed. I added a new NIC to each VM and configured the IP addressing, VLANs and routing, but could not get the intra-array network to ping, let alone talk to each other. So the lesson here is to set up the servers with their NICs before you install TMG – Microsoft recommend a dedicated intra-array network and every bit of experience I have with TMG arrays confirms that.
Get the NIC Binding order right
This is simple, the order I have found to work is:
- Intra-array Network
- Private/Internal Network
- Public/External Network
Some people recommend the Private/Internal network first, then the Intra-array, but I have found that this order works better (anyone able to dispute this or give me a reason why it should be the other way?). The key thing is that the External Network (which should be your default Gateway) is last in the binding order, which brings me to the next point…
Get the gateway and routing right
- Default Gateway: The only NIC with a Default Gateway set should be the Public/External NIC
- DNS: The only NIC with DNS configured should be your Private/Internal NIC
- Register in DNS: The only NIC registering in DNS should be the Private/Internal NIC
- Client for Microsoft Networks: Only enabled on the Private/Internal NIC
- File and Print Sharing for Microsoft Networks: Only enabled on the Private/Internal NIC
- NetBIOS over TCP/IP: Only enabled on the Private/Internal NIC
Add any static and persistant routes required and make sure you can access those networks before installing TMG. This allows you to get the routing right without the complication of TMG rules and firewalls.
Then, and only then, install TMG 🙂
Configuring SSTP VPN connections to Threat Management Gateway 2010
SSTP or SSL VPN connections are great for people working on client sites or behind very restrictive firewalls – they only require HTTPS (port 443) to be open to be able to connect. Unfortunately, you need to be running Windows 7 or Server 2008 (or newer) in order to make use of them. Threat Management Gateway 2010 is one option for an SSL VPN endpoint.
SSTP VPN Requirements
- Clients must be Windows 7/Server 2008 or newer
- Certificate – either commercial or an internal Certificate Authority
- Published CRL – SSTP clients check for the Certificate Revocation List of the CA
- If you already have an SSL listener (e.g. for Exchange publishing rules) then you need a dedicated IP address for the SSTP connection
Remote Installation of SCOM 2007 R2 Agent on Threat Management Gateway Servers
Getting a SCOM 2007 R2 SCOM agent on TMG is a useful way of monitoring TMG, especially with the SCOM TMG Management Pack – it’s not exactly “out-of-the-box” functionality though, with many sources I’ve read simply stating that it can’t be done. There are some half-working solutions I’ve seen, but nothing that worked for me.
The process involves simply opening the correct ports and protocols between the TMG servers and the SCOM management servers, which after a few attempts watching the live logs, I found.
In-depth: Installing and Configuring Threat Management Gateway 2010 in a Network Load Balanced Array
In this post I will be installing a TMG Array as a “back firewall” behind a hardware firewall. The Array will consist of two virtual servers, TMG01 and TMG02 which each have 3 NICs. One NIC will be dedicated to the LAN network, accessible internally. One NIC will be dedicated to the DMZ network, accessible to the outside world on a static mapped IP. The third NIC will be a dedicated intra-array communications NIC as per Microsoft’s recommendation.
Both TMG servers will be domain joined – there are several reasons for this, not least of which is that we require integrated authentication for the proxy clients.
The array will be a Network Load Balanced proxy server for all LAN clients to access the internet; it will provide content caching and malware protection. It will also reverse proxy Outlook Web Access, ActiveSync, Outlook Anywhere, SharePoint and some internal static HTTP resources. It will also provide SSL VPN (SSTP) access for remote clients, but that will be the subject of a later post.
Installing Exchange 2010 Edge Server with Forefront Protection for Exchange (FPE) and Threat Management Gateway (TMG) – Part 1
I am mid-migration, in a co-existence setup with Exchange 2010, 2007 and 2003. So far the roles installed for Exchange 2010 are CAS, Hub and Mailbox on a single server. Into this mix I need to introduce an Edge Server, with message hygiene in the form of Forefront Protection for Exchange (FPE) and Threat Management Gateway (TMG) as a reverse proxy to publish OWA, ActiveSync et-al.
Since Edge, FPE and TMG can now all exist on a single 64-bit server, I will start with a clean installation of Windows Server 2008 R2, up to date with all the latest hot fixes. The server itself is nothing too spectacular, for testing purposes it has 2 virtual CPUs and 2GB RAM. It does need 2 NICs, one on the internal LAN and one on the DMZ. Since the DMZ is behind a hardware firewall, an external IP address has been mapped to the servers DMZ NIC. The server is named EDGE01.
Microsoft Forefront Client Security Setup Wizard fails on “Install Collection Server Component”
If you see the following cryptic errors when trying to install FCS, then the chances are you need to install the .Net Framework 1.1 AND SP1.
[06/04/2010 10:47:11] Task (Install Collection Server Component) The following process failed. Process: C:\Windows\system32\msiexec.exe Exit code: 1603 Number of tasks completed: [06/04/2010 10:47:12]