I ran into an interesting problem this weekend.  I noticed that a lot of email was being returned as non-deliverable from my Exchange 2010 server.  Many domains, specifically AOL and some of the major ISPs require that the domains they communicate have mail servers with reverse zone lookups, meaning that their name “mail.domain.com” for example, resolves to a specific IP.  Well, my MX record does reverse resolve to the correct IP, however that IP wasn’t the IP address that my server was communicating from.

My infrastructure goes through a firewall.  It used to be Microsoft ISA Server, but recently I have been trying the new Forefront Threat Management Gateway.  One of the nice things is TMG is supported on Windows 2008 and R2, and can be virtualized as well.  I built mine on Windows 2008 R2, which appears to be part of my identity problem, at least as far as other domains are concerned.

Normally on a network card that has multiple IP addresses assigned to it, the first IP listed will be the one that is used for communication.  In the case of Windows 2008 (and R2), it actually changes to use the lowest IP address (number-wise).  So if my IP ends with 12, and another one ends with 14, even though 14 might be listed first, it will always use 12.  From what I understand and without getting into too much detail, there is something called strong and weak host models.  It’s hardcore networking, so if you want, you can read more here and here.

Microsoft recognized this as an issue and released a hotfix for Windows 2008 SP2 and Vista SP2, but the hotfix doesn’t cover R2.  Basically this hotfix adds a parmeter called SkipAsSource which can be set per interface via NETSH.  After you install this hotfix, you can create IP version 4 (IPv4) addresses or IP version 6 (IPv6) addresses by using the netsh command together with the new “skipassource” flag. By using this flag, the added new addresses are not used for outgoing packets unless explicitly set for use by outgoing packets. Therefore, these IP addresses will not be registered on the DNS servers.  This also induces the behavior as you knew it in Windows 2003.

Now, since I am running R2, this really didn’t help me, but a slight change in configuration in TMG did.  In the Networking configuration inside TMG, I have a rule for anything accessing the Internet.  I can control from here what IP is used to talk to the Internet; this would be the IP address that my mail server would be seen as through Network Address Translation (NAT) on its way to the interwebs.

You can configure the NAT rule to use any or all of your externally routable IP addresses.  Problem resolved!

UPDATE (11/13/2010):

Thanks to Nick for the update.  A hotfix is now available for Windows 2008 R2.  You can find more information here.

I noticed tonight that my domain controller’s clock had creeped ahead by about 15 minutes.  Inconsistent time, especially time that differs between servers, clients, and a domain controller can throw applications like Exchange, who depend upon Active Directory for information, for a loop. 

In Windows 2008 R2 (and Windows 7), the /setsntp and /querysntp switches of NET TIME are deprecated.  W32TM.exe provides similar functionality that NET TIME provided when it came to configuring domain controllers as a primary time source.

W32TM is not terribly intuitive, but I did get enough information to get my Windows 2008 R2 domain controller updated and again updating the time of the resources in my domain.

If you are wondering how to set this up – here are a few steps to help you out.

1. Use W32TM to configure the peer list and then update the configuration.  In this case, I am using a “set” of public servers to get my time information.  From a command prompt, type (on a single line):

w32tm /config /manualpeerlist:”server 0.north-america.pool.ntp.org”,0×8 /syncfromflags:MANUAL /reliable:yes /update

2. I’m not entirely sure that this is required, but we’ll restart the Windows Time Service for good measure.  From a command prompt, type:

net stop w32time

then restart the service:

net start w32time

3. Then we’ll initiate the time resynchronization and rediscovery of the peer list time sources that we specified in Step #1.  From a command prompt, type:

w32tm /resync /rediscover

There.  You should be all set.  If you want to update the time on a client (or a server) ahead of the regular interval at which is checks with a domain controller for the correct time, you can go to a command prompt and type:

net time /domain<domain name> /set /yes 

This will force an update of the time on the current system from your local domain.

This week I was in Las Vegas for the Exchange Connections Conference.  Traveling usually isn’t too much of a hindrance anymore of the availability of a wireless Internet connection just about everywhere you go.  The only downfall is that most public places, particularly hotels, tend to provide Internet access but block non-HTTP traffic in a lot of cases.  For VPN users, this can be a problem and prevent you from accessing the resources that would normal require you to be connected directly to your corporate network.

With Windows 2008, the Routing and Remote Access service can now be used as a means for providing access via VPN to corporate resources.  Since SSL is a common protocol and just as common as it’s HTTP counterpart, it is usually accessible.

I spent a couple of hours tonight working on creating a SSL VPN solution for my network.  I did get it up and running and wanted to provide some of the resources that helped make this process a lot easier. 

The IT Consulting Blog had a good amount of information that got me through some of the pitfalls.

This IT Technology Blog helped a lot when it came to troubleshooting.

I was able to get connected and everything is working great – but – one thing I did have problems with was when the SSTP Client in Windows 7 connects to the VPN Server, it has to make contact with the Certificate Revocation List to check and make sure that the certificate used for the VPN communication hasn’t been revoked.  I am using ISA which may or may not add a layer of complexity, but I did have to disable the CRL check.  At first, I thought the registry edit that disabled that was made on the VPN server, but in fact, it is actually made on the client machine.  You probably don’t want to disable CRL in a production environment – so just keep that in mind.

Microsoft has a section in this article that talks about the registry key required to disable or enable the CRL check.

Finally, Tom Shinder, one of the great ISA experts out there wrote a series on implementing a Windows 2008 VPN behind ISA infrastructure.  This walks you through the entire process from start to finish.  You can find that three part series here.