Jonathan Puddle

We’ve been testing our first install of Server 2008 R2 this month, it will be replacing an aging webserver running Server 2003. IIS 7.5 brings with it a few new things, the most notable is a new interface. Less noticeable at first, is the lack of an SMTP server. Sometimes you need a quick and dirty SMTP server for delivering email from websites, and the Windows SMTP server is great for this. Coupled with the use of a smarthost for relaying, it can cover a lot of basic needs very well. Server 2008 R2 DOES actually include an SMTP server, but to access it you must install the SMTP components in the Server Manager, and then open up the IIS 6 manager (old school style), which allows you to manage the SMTP server.

Now, strangely, the first few times I tried to access the IIS 6 manager, it wouldn’t open. I received an error stating the wait operation had timed out. I checked everything I could, there was nothing useful in the event log… so eventually I removed IIS completely and then slowely re-added it piece by piece. Now everything works fine… though this morning I found the entire SMTP configuration had reset to default, so there may be something still a little wonky here.

I ran across another odd quirk, which seems to be default behaviour in IIS since 5.1, but I’m surprised that I’ve never encountered it before. The problem arose when we found Windows Authentication just wasn’t working when we set a hostname. Without a hostname it would work, but with a hostname we just kept getting prompted for authentication over and over again. The event log revealed a login failure with the status code 0xC000006D. A quick Google search turned up this document which explains it: http://support.microsoft.com/kb/896861

So we disabled the DNS check, and now the sites all work fine. Strange things… but this is why you test.

While in Toronto recently, we rebuilt our terminal server cluster taking advantage of a new VMWare host server. We had 2 physical servers for our TS cluster before, linked up with Microsoft’s NLB (Network Load Balancing). We provisioned 3 new VMs (we’ve got lots of headroom, so we can pass that to our users), and went about setting up the NLB service to cluster them. We quickly ran into some odd behaviour, so I’m going to list a couple of things to be aware of.

• NLB can run in unicast or multicast mode. Each method has drawbacks and benefits, but if you’re running VMs then you’ll essentially HAVE to use multicast. This is due to the way unicast load balancing works, by establishing virtual MAC addresses for the adapters. When all of these adapters are virtual, your switches can get freaked out and won’t resolve traffic properly. Using multicast lets you get around this problem.
• Changing between unicast and multicast can cause all manner of problems. If you’ve had your cluster set up for unicast, and you want to change it to multicast, make sure to remove the host IP (the one IP that all members of the cluster have in common) from the IP address mappings, BEFORE you change to multicast mode. Otherwise you’ll get IP conflicts and your network adapters will disable themselves.
• When using multicast, you may run into problems getting your terminal services cluster onto the internet. Not all firewalls can handle the routing of multicast packets; we use pfsense, and it does not handle multicast traffic. Clients who try to connect from outside the LAN to the terminal server cluster behind the firewall don’t get anywhere, the connection just times out. This is because the firewall is dropping the multicast packets that are used to communicate with the TS cluster. To get around this, we just configured the firewall to send non-LAN clients to one specific member of the cluster; it’s not ideal, but it does the trick until pfsense bakes in the support for multicast traffic.