Blog

Exchange Links – 06/10/11

No Comments » Written on June 10th, 2011 by
Categories: Blog, Exchange
Tags:

We tend to read quite a bit on Exchange; here are some articles you may find useful or informative. If you have suggestions on any other blogs or websites we should be reading please leave a comment.

Creating Distribution Groups Overriding Naming Policy
Distribution Group Naming Policy is a template that, we as Exchange admins, apply to all newly created distribution groups. [...] There will be times in which you want to cerate a distribution group with a particular name, without getting the standard policy applied. You can create new groups or modify existing ones, ignoring the naming policy been configured. Read More @ How Exchange Works

The Conversation Action Settings Folder
If you’re used to using Outlook on Windows, you may never have seen this folder. In fact, you might not have seen it if you are a Win Outlook user, because it’s only present on Exchange 2010 mailboxes. Read More @ Paul’s Down Home Page

Using Room List Distribution Group in Exchange 2010
As the name suggests, “Room List Distribution Group” is a distribution group which has a list of room mailboxes as its members. Why do we need one of these groups, you might ask. In earlier versions of Outlook, if you wanted to search for a room’s availability while setting up a meeting, you needed to add all possible rooms to the meeting request and then use the Scheduling Assistant to view available rooms. [...] In Exchange 2010, if a room list distribution group has been configured, an end user can add just the distribution group, which will list all the meeting rooms and the availability automatically. Read More @ How Exchange Works

Exchange Server 2010 Native Data Protection – Part 1
Exchange Server 2010 brings new features that allow companies to protect their emails without performing any backups. These features introduce the concept known as Exchange Native Data Protection, formerly known as Backup-less Exchange Organization. Read More @ ExchangeInbox.com

 

Tags
Posted in Blog, Exchange

A Note on Clustering Exchange 2010

8 comments Written on November 5th, 2009 by
Categories: Blog, Exchange
Tags: ,

I just had a conversation about how many nodes can fail in a three node DAG and since there was a misconception present I figured I should point out a section of the “Planning For High Availability and Site Resilience” article on TechNet.

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

Tags,
Posted in Blog, Exchange

How To: Create PTR Entries for a Classless Reverse DNS Zone on Windows 2008

1 Comment » Written on November 3rd, 2009 by
Categories: Blog
Tags:

Recently one of my customers moved their office location and in the process moved their Internet connectivity to a T-1. Their provider, Qwest Communications, assigned them a /27 subnet to go along with it and offered to delegate reverse DNS to them. Sounds great, right? Well, there is a problem here; my customer is a Microsoft shop using Windows 2008 for all their public DNS and Windows 2008 DNS does not gracefully handle reverse DNS for classless subnets. This resulted in my customer lacking reverse DNS for their Exchange environment; Since a number of hosts will not accept inbound mail from an IP without reverse DNS this was causing some issues with mail delivery and very much affecting their business.

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!

Tags
Posted in Blog

Implementing Sender Policy Framework (SPF) to Decrease Backscatter

No Comments » Written on October 31st, 2009 by
Categories: Blog
Tags: ,

What is Sender Policy Framework?

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

Tags,
Posted in Blog

Jetstress 2010 (Beta Preview) Released

No Comments » Written on September 1st, 2009 by
Categories: Blog, Exchange
Tags:

Microsoft has released a beta preview of Jetstress that has been updated to take into the new Exchange 2010 mailbox IO profile. Read more at You Had Me At EHLO… and download via Microsoft Exchange Server Jetstress 2010 Beta (64-Bit)

Tags
Posted in Blog, Exchange

New Website

No Comments » Written on August 29th, 2009 by
Categories: Blog, Cohesive Logic
Tags: ,

Welcome to our new website. We’ve spent quite a bit of time on it and hope you enjoy the new layout. Please feel free to contact us if you have any questions about our services.

Tags,
Posted in Blog, Cohesive Logic

Should You Store PSTs On Your File Server?

No Comments » Written on May 4th, 2009 by
Categories: Blog

Do you store PSTs on your file server? This is a fairly common issue that most people either aren’t aware of or don’t care about for some reason. If you ask me it’s A Bad Thing that should be avoided at all costs. Microsoft has a KB article on this and I’ve copied and pasted a few choice sections out of it below…

The .pst files are not meant to be a long-term, continuous-use method of storing messages in an enterprise environment.

Other Behaviors of .pst Files over WAN/LAN Links

  • All operations take longer.
  • Write operations can take approximately four times longer than read operations.
  • Outlook has slower performance than the Exchange Client.

When you store .pst files, shares may stop responding. This behavior may cause several client-side problems, such as causing Outlook to stop responding or freezing desktops on client computers. Queuing in the Server service work queues is what causes this temporary condition. The Server service uses work items, such as a request to extend a .pst file, to handle I/O requests that come in over the network. These work items are queued in the Server service work queues. From there, they are handled by the Server service worker threads. The work items are allocated from a kernel resource that is called the nonpaged pool (NPP). The Server service sends these I/O requests to the disk subsystem. If, for reasons that are mentioned above, the disk subsystem does not respond in time, the incoming I/O requests are queued by using work items in the server work queues. Because these work items are allocated from the NPP, this resource eventually runs out. Running out of NPP causes systems to eventually stop responding and to log event ID 2019.

Consider one more scenario that is not specifically called out in the KB: real world file server performance. If you have 400 users with 1GB PST files located on a single file server what happens when they all come in at 8AM and load up Outlook? Outlook is going to try to load the entire PST at once and your file server is going to be asked to deliver 400GB of data to 400 users simultaneously. Yet again, A Bad Thing. These are obviously make believe numbers but hopefully you get the idea.

Microsoft makes a few recommendations in the KB, all of which are feasible, but I would add a big one that is becoming more popular daily – Archiving. I’ll write another post that covers some archiving options in the coming weeks but until then know that it allows you to move your user’s older and less frequently accessed e-mail to slower, cheaper storage with minimal impact to the user experience. It also allows you to provide a “bottomless mailbox” as far as your users are concerned as they will never hit their quotas if your policies are designed properly.

[ LINK ] to Q297019 – Personal folder files are unsupported over a LAN or over a WAN link

Posted in Blog