Some mail server networking best practices

I was reminded this week about the importance of some good best practices when handling the networking portion of a mail server. While a server or exchange administrator will do a great job handling all of the best practices of configuring the software itself, it is not uncommon for the networking portion to be overlooked. Here is a summary of a couple of networking or firewall related best practices…

  • Your Mail Server should be NAT’ed to an IP address different than your general internet traffic. This ensures that malicious activity taking place on your general internet traffic, or an infected pc, or even a guest system does not impact your ability to send email. If I guest laptop on your wireless network has a virus and is sending out spam, it might result in your IP address being blacklisted, and it will cascade onto your mail server. With a public IP address dedicated to your mail server, you can be assured that if you’re blacklisted, it is because of traffic through your mail server, and not from another source.
  • Block outbound port 25 from everything except your mail server. In general, the only device that should be sending mail outside of your network is your mail server, and if another device needs to send email, such as your MFP or other device, it should relay off your mail server, and not send out directly.
  • If you are using some form of hosted inbound spam or mail filtering, such as MXLogic or Reflexion, you should source IP filter your inbound port 25 traffic, or better yet, consider using an alternate port. If you don’t lock this down, it permits people to bypass your hosted mail hosting, and directly send spam to your mail server.
  • Ensure that your firewall has application aware protection in place for SMTP traffic, however if you have an older Cisco PIX firewall and an Exchange mail server, consider turning FIXUP off for SMTP since there is a long history of documented problems.
  • Be on the lookout for a mail administrator who assigns a public IP address on their mail server directly, thereby bypassing the firewall or other edge protection. If they really want to dual home the mail server, have them place it on a DMZ instead.



Microsoft Server 2008 SP-2 Enterprise DCPromo

3d human with big negative symbolYesterday I experienced an interesting problem when attempting to run DCPROMO on a new Server 2008 Enterprise SP-2 to promote a server to become a domain controller in a Server 2000/2003 environment. Every time I ran DCPROMO on the 2008 box, it kept errorring out stating that I first needed to run ADPREP. However, I had already run it on the 2003 AD Server:

To install a domain controller into this Active Directory forest, you must first perpare the forest using “adprep/forestprep”. The Adprep utility is available on the Windows Server 2008 installation media in the Windows\sources\adprep folder

I’ve upgraded many domains from 2000 and 2003 to a 2008 domain, and don’t recall running into this problem before.

As a toubleshooting steps:

  • I knew that you must upgrade all Server 2000 domain controllers to at least SP-2 or apply a specific hotfix. A quick double-check of our 2000 box showed that we were at SP-4 and tha patch was unneeded.
  • I also decided to verify the forst and domain functional levels, which were also set to 2000 native.
  • Since we were still failing, a quick knowledgebase check did not reveal anything, and this new 2008 server was going to be replacing our 2000 server, I decided to simply remove any problem with the 2000 box from the equation. I double checked that it was not holding any FSMO roles, or any other AD integrated services which existed only on that box (DNS, DHCP, IAS, CA, etc)
  • After demoting the 2000 server, I also upgraded the forset and domain functional level to 2003 native, but this also did not resolve the problem.
  • I began to run a series of DSUtil commands to check the DNS and overall domain and everything cameback successfull… except when I ran the utility on the 2008 server. But since the utlity came back fine on the 2003 box, I assumed there must be something wrong onthe 2008 box itself.
  • I double checked that all patches were applied to the 2003 and 2008 boxes
  • I then researched the issue more widely on the internet via Google. A couple of things came up which were misses, but probable causes for other networks, so I’ll list them here:
    • In multi-domain forests, be sure to prep both the forest and domain controllers
    • Make sure you run adprep on the box which contains your Schema Master FSMO
    • Make sure you have proper DNS connectivity both ways on current and additional domain controller (add static entries for forward lookups as needed)
    • Ensure DNS is Active Directory aware (yes, you can install in non-aware environments but have to manually create the DNS entries, which can cause problems with an automated DC promo).
    • Make sure you disable third party firewalls

The last entry caught my eye and while we were not running any firewalls or anti-virus on the server yet, in 2008 SP-2 after installing the server the next automatic step was to enable the Windows Firewall. How you would assume that DCPromo would know about and could create the proper holes in the firewall to permit DCPromo to work, but apparently it does not. At least not in SP-2. So disable Windows Firewall while performing the DCPromo and it completes without problem. Then reable as you see fit. I don’t recall this problem or a need to do this in pre-SP-2 2008 server DCPromo’s, nor is it listed under any Microsoft documentation for performing a DCPromo, so it sounds like another excellent undocumented feature.


Powered by

Up ↑