Monthly Archives: May 2010
The reverse proxy installation can be confusing if you have never done it before. In this scenario I will be standing up a new server to replace my ISA 2006 SP1 Server. I will create all of the rules from scratch and walk through the installation.
The most important part of this reverse proxy setup is the networking configuration. It is recommended to have at least two network interfaces on the TMG server, in my case we have a network card in the DMZ with public IP addresses and one on the internal network. Depending on your actual network configuration this could be different.
An important thing to note is that in windows you can have multiple network interfaces on different networks, but not multiple default gateways. Because of this, we need to choose an adapter with the default gateway, and one without any gateway, using manual routes to get to internal resources. In most scenarios it would be ideal to assign the default gateway to your internet facing NIC, this is because it is impossible to enter manual routes for all possible internet traffic. The internal or DMZ NIC typically has no gateway, but we will assign persistent routes for the internal networks.
In my case, the NIC is directly on the internal network, so servers can communicate directly on the same subnet with no routing needed. However, I will show you how to configure these routes for another internal network to simulate the need to route. In an edge server configuration you will need routes for the desktops as well as servers, so it is important to know how to do it.
In my situation, the address spaces involved will be as follows:
Server LAN: 10.117.117.0
Desktop LAN: 10.1.2.0
DMZ: Public IP addresses
Because my TMG server has a NIC directly on the 10.117.117.0 network I do not need a route for that network, but in order to talk to the 10.1.2.0 network, I will need persistent routes. To see the route setup on your server:
Open a command prompt as administrator
Type Route Print and hit enter
Your output should resemble something like the picture above. Note the 10.117.117.0 network has routes directly on that link, and the default gateway is set to our public interface.
To add a route to the 10.1.2.0 network type the following at the command prompt and hit enter:
route add –p 10.1.2.0 MASK 255.255.255.0 10.117.117.2
Where 10.117.117.2 is the router on your network.
If you see OK! after you hit enter, the command took succesfully.
This means any requests for that network are in the route table, and are to go to 10.117.117.2, which will happen via the 10.117.117.106 interface, or our Internal interface.
This is a fairly basic network configuration, in most environments it will be more complex and involve more subnets. However hopefully this gives you a good idea of how to setup the network in your environments.
Before I get started, the diagram below will show the basic environment as it relates to the reverse proxy and my OCS Pool.
Update the server with the latest patch levels, and then launch the TMG Install. You will get a screen prompting you to Perform Updates, Run the Preparation Tool, or Run Installation Wizard.
Select Run Preparation Wizard. This Wizard will add the server role required for TMG to operate on the server. As you click through the installer you will have to choose a type of installation, choose Forefront TMG services and management for a complete install.
Let the wizard run, it will install all roles and services needed. When completed you will be presented with a screen that shows Success or Failure, Click Finish and Launch the TMG Installation Wizard.
The installation wizard will have a few defaults to accept, and then you will be asked to choose your internal network ranges. Choose Add, then choose Add Adapter. Select the Internal network interface on the server. If you previously entered persistent routes you will notice those subnets show up as being associated with that adapter as well.
Hit OK twice and your window should look something like this:
The address ranges should reflect your DMZ adapter address and any internal networks you will be routing to.
Hit Next twice to acknowledge the services that will be restarted during the install. The next page will notify you that forefront will create rules to allow domain traffic to domain controllers listed
If this information looks correct, hit Next, then Install and let the installation complete.
The installation will take some time to complete, but once it is done you should see this screen, click Finish to launch the configuration wizard.
The initial configuration wizard will then launch. Note: You can import ISA 2006 XML configuration files to this if you do not wish to recreate your rules. I am going to start from scratch however to show the whole configuration process.
Run the wizard to configure network settings. This setup is an Edge Firewall configuration. Choose Edge and click next.
Choose your internal network adapter to be associated with the LAN. You may also enter routes here, I am not sure if this makes the previous routes entered not needed, but I will do more testing and update the blog if that changes.
The next step is to define Deployment Options which chooses your license information, and update settings. I will not cover that in this post.
Once you launch the TMG Console, you will notice a somewhat familiar interface with a whole lot of new features.
OCS Website Publishing Rules
Before starting with any OCS rules you should import the public certificates for your OCS Web Farm.
You should have a standard SSL certificate with a common name that matches the External Web Farm FQDN you specified during setup, or that name should reside on a UCC certificate. Either way, you must import that certificate into the Local Computer store with a valid Private Key before it can be used with ISA.
To do so, open the certificates MMC.
Right click on the Personal certificates store and choose All Tasks –> Import
Hit Next, then Finish. Your certificate should now be ready for use with ISA.
For OCS, we are simply concerned with Firewall Policies, there are a lot more features to TMG 2010, which I hope to cover at a later date.
Select Firewall Policies, and choose Publish Web Sites from the tasks pane on the right
Hit Next, for the path enter /* to allow all traffic to the pool for the various services.
Choose the radio for Specified IP Addresses on the forefront TMG Computer in the selected network.
Select the IP address that will your web farm FQDN dns A record points to, and choose Add so it shows in the selected IP addresses column.
Highlight the IP address and choose Select Certificate…
The next page will show you the valid certificates installed to the local computer personal store on your server. Choose the certificate for your OCS web Components and choose select.
Hit Next twice, choose Finish to complete the listener configuration, you will be brought back to the web site publishing wizard with the new listener selected.
Hit Next, for authentication delegation choose No Delegation, but client may authenticate directly.
Make sure you hit Apply to actually commit the rule.
Now that this rule has been configured and you have an external DNS A record pointing to your External Web Farm FQDN, your users should be able to access the OCS web components remotely.
In the next post I will outline configuring TMG 2010 for Communicator Web Access.
So the title of this post sounds kind of crazy, and you may be asking yourself, WHY???
Well, internally we have two networks and two separate forests connected over a gigabit fiber link. These locations are in two separate buildings in the city. One is in our office, and one is in our hosted data center.
Without diving too deep into our network setup, the point is, we have a SQL server in our office that is currently being decommissioned, and it holds the OCS R2 Enterprise Pool backend. In our data center, we have a very nice SQL 2008 server to move all the databases to.
To sum things up, this does indeed work, at least in our situation. It is important to note that it is not supported nor recommended as I have only tested basic functionality, and done no performance testing. Also, we have a full two way trust between these forests, so permissions were not an issue.
In the end, we decided not to do it because we rely too heavily on OCS as our complete UC platform, and did not want to risk any performance issues.
If this is something you absolutely must do, it does in fact work.
I do not have any details on the exact cause of the issue at this point, but I recently did an OCS 2007 R2 deployment on Server 2008 R2. We followed the general instructions located on TechNet to install the OCS services on 2008 R2, but ran into an issue when performing user moves from LCS to OCS.
Not a lot of information in the errors, but pointed to a connectivity issue between the LCS server and the new OCS server.
The fix for this issue is to install the admin tools on a 2003 Server, once the admin tools were installed on a 2003 sever in the environment, the moves were successful. I am working on finding the exact cause, but I am betting it is related to the bullet item for admin tool compatibility issues listed on the 2008 R2 support page. Will update when I have more information.