There are several components within Exchange 2010 that administrators may not come across unless they are troubleshooting very specific issues, or reading level 400 texts. This is the first post in what may become a series on some of the deeper internal workings of Exchange 2010. In this first post, I want to introduce you to the Transport Dumpster.

The Transport Dumpster is just one of the inner components of Exchange that sits quietly and unobtrusively on a Hub Transport server, helping to protect data in the event a server experiences any type of failure that would otherwise lead to a loss. You may not notice it, but you will be glad it is there, and in certain circumstances, you may want to adjust its default settings.

The Transport Dumpster first appeared with Exchange 2007, and is a queue that can be found on every Hub Transport server that resides in an Active Directory Site that contains a DAG. It helps prevent loss of data sent from the Hub Transport Server to a Database Availability Group when something fails that would result in a lost message. There is one Transport Dumpster per replicated database.

Continue reading Inside Exchange 2010: What is the Transport Dumpster?

Usually Exchange’s error messages are, while concise, informative and tend to point you in the right direction towards resolution, but sometimes an error occurs and the error message generated has little to nothing to do with the actual problem. One such case is with the proxy error 10.

This post will talk about what proxy error 10 usually means and how to fix that, but it will also go over another situation that occurs frequently, causes Outlook to throw the same error, but has little to do with the message.

Continue reading How to Fix Error Code 10

The Internet’s Request For Comment system may be one of the world’s best examples of rule by majority consent, as it is the de facto set of ‘laws’ for how the Internet (and all its associated protocols) works, and is essentially a collection of documents that ask the world ‘what do you think about this?’

With literally thousands of documents in the collection, defining standards, recommendations, best practices, and the occasional joke, anytime you want to know the why behind how something is done, you need look no further than the RFCs. While they are replicated on countless websites, the official repository is found at http://www.rfc-editor.org.

RFCs evolve over time, and earlier RFCs can (and often will) be superseded by newer ones. There are several RFCs that address how our email protocols and the associated DNS records should work, and as an email admin, you should be familiar with the lineage of all the major email RFCs. Even those which have been superseded usually contain useful information, as most new ones define enhancements to a protocol, as opposed to completely replacing it. Over 300 of the RFCs have something to do with email; fortunately you won’t need to know them all unless you want to program a new email application. Below you will find a summary of the seventeen RFCs that email admins should have at least a passing familiarity with, and links to the online documents should you wish to read further. All links will open in a new window/tab.

Continue reading 17 RFCs Every Email Admin should Know About

Exchange 2010 SP1 offers significant capabilities for data storage and retention, all of which can be greatly enhanced by the addition of third party archiving solutions. These solutions can increase mailbox storage to virtually unlimited capacity, provide for search and discovery, reviews for compliance and internal investigations, disaster recover scenarios, and more, all by maintaining a complete record of all messaging that is kept separate from the Exchange infrastructure.

Continue reading 3 Ways to Implement Exchange 2010 Archiving

There have been several articles posted on TheEmailAdmin lately regarding mailbox size (including at least one of those written by myself). There appear to be strong and valid arguments on both sides of the issue; large mailboxes help to support business operations, avoid the need for PSTs, and keep users happy. Smaller mailboxes conserve space, are much quicker to restore in the event of a disaster, and can reduce the likelihood that something from years ago might come back to haunt you. Email archiving solutions are a good compromise, offering users the ability to keep important (to them) emails around forever, while keeping inboxes small.

Continue reading The Microsoft Large Mailbox Vision

In a Microsoft shop running Exchange and Outlook Web Access, you may also be using Microsoft Forefront TMG 2010 to securely publish resources to the Internet. It’s a natural fit to use TMG to make OWA available to your remote users, however the default way to do so leaves a little bit to be desired.  OWA requires users to use an HTTPS connection, and by default it also expects users to type out the full path to the /owa directory. When providing users a bookmark or a link in email, needing to specify the protocol and path is easy. When reading the URL to users over the telephone, it helps to make it as easy as possible.

In this article we will go through the process of publishing OWA to the Internet using TMG by creating a rule that will accept a simple URL (like http://mail.example.com) and redirect it to the proper OWA URL (like https://mail.example.com/owa/) with the protocol and the virtual directory in place.

Continue reading How to publish Outlook Web Access using TMG 2010

This is a blog for email admins, but frequently email admins are called into troubleshoot systems that want to use our email systems to send and/or receive email. One of the more critical services that will want to use our email system, and that can be tricky to troubleshoot, is SharePoint.

Microsoft’s SharePoint server can generate a lot of email. Notifications of group assignments, permissions assignments, workflows, and alerts can all cause SharePoint to send email out, and most companies want this email going through their Exchange or SMTP relay, as opposed to going straight out to the Internet using the IIS SMTP service.

Continue reading 4 Steps in Troubleshooting SharePoint’s outbound SMTP connections

For personal email, I use Gmail. Sure, I run an Exchange server at home, but my ISP is not exactly providing an SLA for business class connectivity on my home account, and I’ve had that Gmail address since the days of the early invite only mode, so there’s a lot of things connected to it. It was while I was checking out the notice of upcoming improvements to their advertising model that I stumbled across something called the Gmail Security Checklist.

This checklist sets 5 steps, with a percentage progress bar, and walks the user through tasks they should take to help secure access to their email. With more and more services using email as the way to communicate information, including statements and password resets, having your email secured is a critical, but for the layperson, daunting task. Gmail makes this as simple as possible, presenting checkboxes to mark tasks complete, links to relevant pages with more information, and using language that a non-technical user can understand and providing guidance along the way. I only wish they put it at the front of the Gmail login page, and then as a banner at the top of the Gmail interface, for it was not something most would stumble upon.

Continue reading 5 Points to the Gmail Security Checklist

If you’ve been using Exchange and Outlook long enough to have used Outlook 2007 or earlier, and you are an email admin, then you’ve probably looked at the SMTP headers of a message to check out where it came from, what servers processed the message, X headers, etc. If you haven’t done that before, there is a wealth of information contained within an email’s header that you can access to glean more information about a message. You can see what servers processed the email from source to destination, the FQDN of the source server, any X headers added by antivirus or SPAM filter systems, and more. Of course, to use this information, you first have to see it.

Continue reading Troubleshooting Email Messages using SMTP Headers

Ask one hundred executives what one piece of equipment they couldn’t live a day without and 97 of them will probably say their Blackberry. That the other three will tell you to ask their assistant to get back to you with an answer notwithstanding, the ‘always available’ access to email offered by Blackberries, iPhones, Androids, Windows Mobile, Symbian, and other smartphone platforms has elevated email from an important business application, to a 24×7 mission critical service, and much like electricity, it is expected to just work. Given the importance of email, and the need to maintain these devices, it is absolutely essential to keep up with the security patches released by the vendors.

Last week, Research in Motion released KB26132, which details a significant security vulnerability in the WebKit rendering engine used by the web browser in Blackberry software version 6.0 and later. This was shown at the Pwn2Own 2011 Contest and has been very publicly disclosed. If a user browses to a malicious or compromised website using their Blackberry, they can encounter an exploit that can lead to remote code execution on their device. Exploiting this is accomplished by using JavaScript contained in a website to exploit the vulnerability in the Blackberry’s  browser. JavaScript is not the source of the vulnerability, but is required to exploit it. Exploiting the vulnerability can not only lead to remote code execution, but this code will have read-write access to data stored within the media storage section of the phone’s built-in memory, or any media card inserted into the phone.

Continue reading Blackberries Need Patching Too