howto://publish a web farm using TMG 2010-part two

Welcome back. This is the second part of a two-part post on publishing a web farm using TMG. If you missed part one, you might want to review it first, then come back here for the rest. Go ahead, it’s cool, we’ll wait.

Okay, everyone back and ready to go? Great, we’ll pick up where we left off, and publish our newly created web farm. Let’s jump right in. Log on to your TMG server and launch the management console.

1. Browse down to Firewall Policy, right-click it, and choose New, Web Site Publishing Rule…

2. This will launch the Publishing Rule Wizard. Give the rule a descriptive name, and then click Next.

3. Since this rule is going to permit visitors to view our site, we want to choose Allow, and then click Next.

4. Remember, we have a farm of web servers, so here we will select “Publish a server farm of load balanced Web servers” and the click Next. If you jumped ahead to this post because you don’t have a farm, just click the “Publish a single Web site or load balancer” option instead.

5. Since this is our public facing site, and we aren’t delivering any secure content or requiring any credentials, we’ll just use HTTP to connect. Click “Use non-secured…” and then click Next.

6. Next, we need to specify our internal publishing details. For the internal site name, we usually specify the hostname used internally, assuming it can be resolved by DNS or NetBIOS methods. In our case, we’re just going to call it website since no one accesses it directly from the inside network, then we’ll click Next.

7. Here we have the option of using a subfolder, and whether we plan to use the internal name, or forward the original host header from the Internet. Since our web servers are not accessible from the Internet, we have configured the sites to accept our www.example.com host header already, and we want to publish the entire web content, we’ll leave the Path blank, and choose to forward the original name, and then click Next.

8. Here, we specify our shiny new server farm to publish, and choose our affinity method. What we are doing here is deciding how we make sure clients we server connect to the same server for each subsequent request in their session. Cookie-based means we will give them a session cookie (which if they aren’t accepting means they’ll splatter their requests across all servers in the farm) while Source-IP based means that if you have 100 clients coming from the same global NAT, they will ALL hit the same server. Even so, I prefer that method over cookies. Make your choice and then click Next.

9. Here we start the configuration of the host header that we will accept for publishing this site. I always put the full www.example.com name in here, and then go back to add example.com later. That’s important since some users get lazy, while others assume you aren’t requiring the www. Make sure your DNS has a @ record to go along with the www, or better still, make the @ record your A, and www a CNAME for @. Here, just fill in www.example.com and then click Next.

10. Now we need to pick our listener. If you already created one you could select it here, but since this is our first site, we’ll create a web listener for our site by launching a sub-wizard (would that be a wizard’s apprentice?) Click New.

11. Give the listener a name that makes it easy to distinguish, like www.example.com listener, then click Next.

12. Remember this is a public access, anonymous site, so we won’t require SSL. Choose that option, then click Next.

13. Here we will choose our External interface, and the specific external ip.addr we want to use. If you bound multiple ip.addrs to the interface, they would appear in a list here. Choose the one that corresponds to your external DNS record, click Add IP…, then click OK, and then click Next.

14. Anonymous access means no authentication required, so select that from the drop down, and click Next. Without authentication there is no SSO, so just click Next again on that screen.

15. Hit Finish on the wizards’ apprentice, and then click Next. Again, there is no authentication, so there is no delegation. Choose that, and then click Next.

16. We’re getting close, just a few more steps. Yes, I know we are not authenticating, but we still have to designate permitted users. In this case, allowing the world to view your site means choosing the All Users set. Fortunately it is the default, so just click Next.

17. We’ve reached the end, Completing the New Web Publishing Rule Wizard. I like to test my rule at this point to see if anything was missed, so click the Test Rule button in the lower left corner.

This will run through the rule and attempt to access all servers in the farm using the configured options. If all is well, it will look something like this.

Click Close, then click Finish.

18. Right click your new rule, and go to Properties. Click on the Public Name tab, and add example.com. Click OK, and then click OK.

It’s kind of like I’m okay, and you’re okay, so we’re okay, okay?

19. Hit Apply up at the top, and enter your documentation for the win!

And that’s it really. Hit your Internet connection, and test out your new rule. As long as any changes you made to DNS have propagated completely, you should now be viewing your website through your TMG. Yay you! Now, remember what I said last post about our users getting wise and using ping? This video is a documentary on just the sort of situation we want to avoid. Warning, the language is NSFW, so use headphones, or wait until you get home to play this.