From “Witness Server Requirements”
DAGs with an odd number of members do not use a witness server. All DAGs with an even number of members will use a witness server. The witness server can be any computer running Windows Server.

What does this mean? You need to have node majority within the DAG; if you have a three server DAG and two fail you only have one left and therefore don’t have majority. If you want to sustain two failures in a DAG then you need to design your DAG with four nodes and use a witness server.

When you add/remove a server from the DAG (note that a node failing does not count) the addition or removal of a witness server happens automatically. You can either specify a directory (The witness server cannot be a member of the DAG) or by automatically selecting a 2010 Hub Transport server in the site that does not have the Mailbox role installed.

Questions are welcome in the comments, a link to the TechNet article is below.

Planning for High Availability and Site Resilience: Exchange 2010 Help

I eventually tracked down the source of the problem to the method used by Qwest, delegating out a small portion of the classful zone to my customer’s name servers and entering CNAMEs for all the individual IPs. This is not an uncommon solution and when using anything but Windows DNS it is quite easy to accommodate.

Let me lay out the basic scenario I encountered first and then I’ll tell you how to solve this problem.

Note: All IPs and domain names have been changed to protect the innocent.

Public IPs assigned to my customer: 192.168.0.192 – 192.168.0.223

Name servers my customer uses: ns1.customer.com & ns2.customer.com

Public IP that my customer’s Exchange environment uses for outbound mail: 192.168.0.194

What was happening here was that when Qwest delegated rDNS for 192.168.0.194, they told remote servers they should be looking for 194.192-223.0.168.192.in-addr.arpa. The initial and obvious solution is to simply create a reverse DNS zone in Windows DNS for 192-223.0.168.192.in-addr.arpa and create PTR records, right? Not so fast there… You can create the reverse zone easily but you can’t create PTR records in the correct format unfortunately.

Hence the quite simple solution: dnscmd

After you’ve created the zone, simply launch an elevated command prompt (Start -> Right Click on Command Prompt -> Run As Administrator) and use the following syntax to add PTR records manually.

dnscmd <dns server> /recordadd <full zone name – 192-223.0.168.192.in-addr.arpa as an example> <last octet of IP – e.g. 194 for 192.168.0.194> 10 PTR <appropriate fqdn>

So in my customer’s case I used the below command to create a PTR entry for mail.customer.com located at 192.168.0.194:

dnscmd custns1 /recordadd 192-223.0.168.192.in-addr.arpa 194 10 PTR mail.customer.com.

You should then be good to go!

Sender Policy Framework (SPF) is an attempt to control forged e-mail. SPF is not directly about stopping spam – junk email. It is about giving domain owners a way to say which mail sources are legitimate for their domain and which ones aren’t. While not all spam is forged, virtually all forgeries are spam. SPF is not anti-spam in the same way that flour is not food: it is part of the solution.

SPF was created in 2003 to help close loopholes in email delivery systems that allow spammers to “spoof” or steal your email address to send hundreds, thousands or even millions of emails illicitly.

SPF is a protocol developed by a group of motivated volunteers, joined by a mutual desire to improve the operation of the internet. It is not a commercial product offered by a for-profit corporation. The SPF protocol is being adopted by a growing number of domain hosts and Internet Service Providers (ISPs), and, as in any technology evolution, there will be some bumps on the road, but Azaleos is here to help along the way.

What does SPF actually do?

Suppose a spammer forges your e-mail address (you@yourorganization.com ) and tries to spam hundreds of thousands of addresses from somewhere other than your mail server. Without SPF in place you are sure to get hundreds if not thousands of Non-Delivery Reports (NDRs) delivered to your mailbox as SMTP lacks any built-in authentication mechanism and it’s easy to pretend to be someone you’re not.

When SPF is in place and operational, the spammer’s message is still sent  from your e-mail address, but remote mail servers now have a way to verify whether or not the spammer’s e-mail server is allowed to send e-mail from your e-mail address.

If your organization says they recognize the sending IP addresses, it passes, and you can assume the sender is who they say they are. If the message fails SPF tests, it’s a forgery and the message is silently dropped without an NDR being generated.

How do I implement SPF for my domain?

First, if you have an existing SPF record (or if you don’t know if you have an existing SPF record), go to the SPF validation wizard located at http://www.kitterman.com/spf/validate.html and enter the domain name part of your e-mail address (everything to the right of the @ symbol) into the topmost box and click on “Get SPF Record (if any)“. That will tell you if your domain already has an SPF record and if its syntax is correct.

If you don’t have an SPF record or you want to work on changing yours, great! The wizard located at http://old.openspf.org/wizard.html is the place to go. It will help you develop the SPF record properly.

Once you have a draft SPF record from the wizard located at http://old.openspf.org/wizard.html you will want to review it and see if what you ended up with makes sense. Take a look at the SPF record syntax located at http://www.openspf.org/SPF_Record_Syntax to get a better understanding of what your record means. Go back to the SPF validation wizard located at http://www.kitterman.com/spf/validate.html and put the domain part of your e-mail address in the domain part of the second test and your draft record in the SPF record part (do not enclose it in quotes, just the record) and then click on “Check SPF Record”. This will tell you if the syntax of your draft record is correct. You can also use the third test in the SPF validation wizard to experiment with different IP addresses your mail might come from with different records and see that you get the results you expect. The first two tests can tell you if the syntax of your record is correct. This is the only one that can tell you if the content of the record is right for your e-mail sending architecture.

Once you have convinced yourself that your record is ready to be published or updated, you publish as a record of type TXT in your domain’s public DNS. How this is done varies considerably from provider to provider. If you don’t know how, you will need to contact your DNS provider. If you don’t know who that is, it is probably the domain registrar that you registered the domain with. If you can’t figure out who it is, we can help you figure it out.

Some text courtesy openspf.org, licensed under Creative Commons CC BY-SA 2.5

With so many options available, it’s important for businesses to understand the differences. With an honest look at the appliance, software and SaaS-based approaches, this free guide will help you choose the best email security solution for your business.

Click here to download your FREE guide.

Good security isn’t just good practice, its good business. This is why Cohesive Logic has joined forces with MessageLabs to provide industry-leading protection with email spam and virus filtering services.

For more information about MessageLabs spam and virus filtering services in general, please see our Message Hygiene Services page. If you have any additional questions or would like to start a free trial please don’t hesitate to contact us.