Users of practically every supported version of Windows, whether desktop or server, 32 bit or 64 bit, and even the low attack surface Windows Server Core should immediately review Microsoft Security Bulletin MS11-100 and begin testing and deployment of this patch as soon as possible. The patch, covered in KB2638420 addresses four vulnerabilities in the Microsoft .NET Framework, including 1.1 SP1, 2.0 SP2, 3.5 SP1, 3.5.1, and 4. Three of the four were privately reported, while the last one has been publicly disclosed.

In a worst case scenario, an unauthenticated attacker could send a specially crafted request to an unpatched server, and gain elevated privileges which could then execute remote code on the impacted server. Exploiting this vulnerability requires that the attacker be able to register an account on an ASP.NET site, and know an existing username. Of course, when so few follow recommended practices and rename the Administrator account, or use common accounts like Admin, Guest, etc., this doesn’t present too high a bar for any site that allows user registrations.

In all, four separate CVEs are addressed by this update, including:

1. Collisions in HashTable May Cause DoS Vulnerability – CVE-2011-3414
2. Insecure Redirect in .NET Form Authentication Vulnerability – CVE-2011-3415
3. ASP.Net Forms Authentication Bypass Vulnerability – CVE-2011-3416
4. ASP.NET Forms Authentication Ticket Caching Vulnerability – CVE-2011-3417

KB2638420 replaces several earlier patches that were released to address some of these vulnerabilities. The first, involving collisions in HashTable, can lead to a denial of service, which can be just as significant an impact to users as any other kind of attack. Exchange admins running Edge Transport Servers and/or Client  Access Servers exposed to the Internet should be aware of this and deploy this security patch as soon as possible. All Exchange server roles require the .NET Framework 3.5 SP1 and are therefore vulnerable, so all Hub Transport, Unified Messaging, and Mailbox servers should also be patched.

As with all patches, you should test this in your lab environment before deploying to production, and follow your appropriate change control processes, but that does not mean you should wait until after the New Year to start evaluating this patch. Microsoft released it out of band (instead of waiting for the normal patch Tuesday in January) because this does address a publicly disclosed vulnerability, and the combined impact should a server be successfully exploited is so critical. When patching Exchange, apply this patch to your server roles in the following order:

1. Edge Transport
2. Client Access
3. Hub Transport
4. Mailbox
5. Unified Messaging.

Microsoft Releases Critical, Out Of Band Update

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

December’s round of patches from Microsoft includes a patch for Microsoft Exchange 2007 SP2. This vulnerability is rated as a moderate, but I know several C level types who would consider anything that interrupts email as nothing short of a national disaster.

This vulnerability, which may also be discussed in CVE-2010-3937 (under review at the time of this writing,) can be exploited by an authenticated user making a specially crafted RPC call to an Exchange 2007 SP2 server running the mailbox role. Microsoft rates this as a moderate severity. Respectfully, I beg to differ.

Consider the Denial of Service attack for a moment. It is exactly as the name indicates, an attack that denies legitimate access to the service provided. Now consider the number of mission critical processes that depend on your email systems every day. What happens to those processes when the email system is unavailable?

I see this at many of the clients I work with; business processes that depend on email and that require an almost ACID approach, even though that is not really possible with a service that offers store and forward, best effort retry, and that uses the Internet. With smartphones and Blackberries, many companies can maintain a semblance of business as usual even when a site goes offline for hours or days, but if email is down for even a moment, heads can roll.

While this particular attack requires an authenticated user, so too do many others. It is not terribly difficult to convince a user to run software, especially with the number of plugins that combine Outlook with social networking sites. And as companies move their email system to the cloud, outsourcing what is looked at as a utility service on one hand, and as the most important, mission critical system in the company on the other, what many of them do not realise is that the outsource provider may be hosting their email on a system that also hosts mail for dozens of other companies. All of those users are making authenticated calls to the system. Do they meet your patching and antivirus standards?

This vulnerability exists only in Exchange 2007 SP2. Companies that have moved to SP3, or to Exchange 2010, are not at risk, but it is worthwhile to note that in the MS10-106 bulletin, Microsoft states:

“The majority of customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically.”

Show of hands…how many of you automatically patch your Exchange servers? Anyone? Anyone? For those of you who outsource your mail, how many of you know what patch level your provider maintains on the systems hosting your mail? At one previous employer, I did an assessment of the three hosted mail systems and found them to be on three different patch versions… the most recent was over a year out of date.

If you are running Exchange 2007 SP2, I urge you to treat this vulnerability as severe, and patch it as soon as you can test it in your environment. Better still, apply SP3. If you have outsourced your email, contact your provider to confirm what version of Exchange your email is on, and review their patching policies. It’s called due diligence, is a reasonable request, and how they respond may tell you more than the pre-sales guy ever did.

MS10-106 patches DoS vulnerability in Exchange 2007

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The Mail Exchanger (MX) record is part of the Domain Name Server (DNS) system designed to translate human readable domain names into IP addresses.  Much like how Web browsers determine the IP address of web servers via DNS, the MX entry directs incoming mails towards the email server for the associated domain.  On this front, administrators with a more technical interest will want to check out the exhaustive details of the MX record is defined under RFC 1035.

So how does the MX record concern the mail administrator?  Similar to how DNS can be used to implement advanced solutions such as load-balancing or failover hardware, the MX record can also be used to bolster the capability and robustness of your email server.  Obviously, deployment scenarios vary greatly depending on actual requirements and needs; I’ve briefly summarized a list of possible ways that tweaking the inbound MX record can help you better manage your Exchange Server deployment.

1. Third party anti-malware or anti-spam filtering
   This is probably the most common reason of modifying a domain’s MX record these days.  Businesses can quickly and easily offload the hassle (and computational resources required) of filtering spam and other malware by redirecting incoming emails to the service provider of their choice.  This vendor will then perform the necessary filtering before forwarding the “cleaned” e-mails back to the correct email server – sparing businesses the need for new hardware purchases or software licensing.

   Indeed, by specializing in malware or spam detection and with the ability to refine their techniques across all its customers, these cloud-based providers typically achieve much better detection rates versus stand-alone appliances.  And yes, you can easily switch to another provider by simply “throwing the switch” and modifying the MX record accordingly.

2. Transition to new servers
   While upgrading a new mail server is not a situation frequently encountered by administrators, the occasion does arise at times where it simply cannot be avoided.  An example that came to mind would be when Microsoft made the decision to release Exchange 2007 – and Exchange 2010 subsequently – only in 64-bit editions. Organisations with incompatible hardware had no choice but to acquire new hardware in order to use Exchange Server 2007 or Exchange Server 2010.

   The option for transitioning between two versions of Exchange is clearly no longer an option, leaving a time-consuming migration as the only way to move the old data over to the newer machine.  You can read all about the related intricate here.  The key point here though, is that companies can ensure that no emails are lost (or bounce) in the interim by tweaking their MX records to point to the new server before taking the old Exchange Server offline.

3. Load Balancing
   Larger organizations who are concerned about their Exchange infrastructure being overwhelmed by a deluge of emails can also use their MX record to load balance between multiple Exchange Servers deployed Edge Transport Server role.  In fact, this is the recommended way of doing it, as noted by Microsoft TechNet here: “You can load-balance SMTP traffic to your organization between Edge Transport servers by defining more than one mail exchange (MX) resource record with the same priority in the Domain Name System (DNS) database for your mail domain.”

   Note that configuring the same priority for both servers is critical for any form of load balancing to take place.  Moving ahead, consistency between multiple Edge Transport servers can be achieved via the use of cloned configuration scripts.

4. Business Continuity
   The idea behind a secondary MX record is simple; the secondary server is contacted to receive incoming emails should the primary server be too busy.  For businesses with only one Exchange server, the secondary MX entry can be set up as a relay server to store new emails in the event of an outage with the former. Once the email server has been restored, new emails cached by the relay server are forwarded.

   The advantages are simple; no nasty error messages are generated should your Exchange Server go down (or while it is rebooting after installing a patch), and incoming messages are not unnecessarily delayed courtesy of the increasing wait times between each mail delivery attempt.  As you can see, businesses can make use of this method to increase their Exchange Server uptime at minimum cost to themselves.

I’ve merely gone through some of the more common and more useful methods of modifying the MX record today.  As you can imagine, the above techniques work not only for Microsoft Exchange, but can also be useful for other email servers.  One thing for sure, the MX record is an extremely powerful way to manage the “flow” of incoming emails.

4 Ways to Supercharge your Exchange Server using the MX record

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Changing passwords in Exchange 2007 is improved by SP3.

In a move that’s bound to make Exchange 2007 shops happy, Microsoft has released Service Pack 3 (SP3) for the application, which makes it compatible with Windows Server 2008 R2. The development is good news for organizations who may have moved to Server 2008 R2, but are balking at embracing Exchange 2010 because they’re not ready to make the infrastructure changes needed to accommodate the new software.

“We heard you loud and clear that this is enormously important to our Exchange 2007 customers, so we worked quickly to deliver SP3 in order to meet this requirement,” Microsoft General Manager for Exchange Customer Experience Kevin Allison wrote in a Microsoft blog announcing the release of SP3.

Here are six new features incorporated into Exchange 2007 by the service pack.

1. All Exchange 2007 roles are supported on Server 2008 R2. However, upgrade scenarios aren’t supported. So if a computer has been upgraded from Server 2008 to R2, SP3 can’t be installed on that computer; neither can a copy of SP2 be upgraded to SP3. In addition, if a computer has SP3 and Server 2008 installed on it, you can’t upgrade the copy of Server 2008 to R2. According to Microsoft: “To deploy Exchange 2007 SP3 on an Windows Server 2008-based computer, you must first install Windows Server 2008 on a computer that does not have Exchange installed, and then install Exchange 2007 SP3.”
2. Windows 7 management tools are now supported by Exchange 2007. What’s more, on a computer running
   Windows 7, SP3 supports management tools for Exchange 2007 and 2010. As with Server 2008 R2, SP3 won’t support Exchange management tools on a computer with a Windows 7 upgrade. So a new installation of SP3 or an upgrade from SP2 to SP3 won’t work on a computer that’s been upgraded from Vista to Windows 7. Neither will management tools support work when upgrading from  Vista to Windows 7 on a machine which has SP3 already running on it.
3. Resetting passwords has been improved by SP3. Exchange 2007 allows Outlook Web Access users to change their passwords, but they need to log on to the system before they can do so. That’s fine if the user’s password is active. But what if his or her password expires before  a login can be performed to change it? Administrators could address that problem with a Web application called IISADMPWD. With it, users with expired passwords could  be sent to a Web page where they could reset them. The problem now, however, is that Server 2008 doesn’t support IISADMPWD. So users of Exchange 2007 in a Server 2008 environment are caught in a bind if their passwords expire. SP3, though, adds a new feature to the Client Access server role. It detects expired passwords and redirects users to a new change password page. Since some organizations don’t allow passwords to be changed outside their internal network, Microsoft, in its wisdom, has shut that feature off by default. So if you want it, you’ll have to turn it on. You do that by modifying the HLKM\SYSTEM\CurrentControlSet\Services\MSExchange OWA registry subkey and adding a DWORD value–ChangeExpiredPasswordEnabledValue type: REG_DWORDValue data: 1.
4. The search function in Exchange 2007 has been updated with SP3. MSSearch binary files are updated to version 3.1 by the service pack.
5. Another change imposed by SP3 may make upgrading a little more complicated for IT Pros. That’s because it makes some schema changes in the Active Directory for some Unified Messaging mailbox attributes. Classes of Active Directory schema modified by SP3 include:
   msExchExtendedProtectionSPNList msExchPopImapExtendedProtectionPolicy
   msExchSMTPExtendedProtectionPolicy.
   Attribute modifications made by SP3 to Active Directory schema include: msExchExtendedProtectionSPNList
   msExchPopImapExtendedProtectionPolicy
   ms-Exch-SMTP-Extended-Protection-Policy
   ms-Exch-UM-Protected-Voice-Mail-Text
   ms-Exch-UM-Voice-Mail-Text
   ms-Exch-UM-Reset-PIN-Text
   ms-Exch-UM-Fax-Message-Text
   ms-Exch-UM-Enabled-Text
6. The new service pack for Exchange 2007 also adds some more functionality for languages that read from right to left, such as Arabic. In past versions of Exchange, you could use a transport rule to create a disclaimer in a right-to-left language on an Exchange 2007 Hub Transport Server, but when you viewed it in Outlook 2007, its appearance was askew.   SP3 fixes the transport rule so it works properly with Outlook when displaying the right-to-left text.

The new service pack is cumulative. That means you can use it to upgrade from an earlier service pack, like SP1, although Microsoft recommends that users uninstall all interim updates before installing SP3.

After installing SP3, there shouldn’t be much cause to remove it, which is a good thing, since trashing it can be more difficult than setting it up in the first place. According to Microsoft, the only way to  purge the service pack from a computer is to uninstall Exchange 2007 entirely and reinstall an earlier version.

Six new features added to Exchange 2007 by SP3

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

While Service Pack 1 for Exchange Server 2010 captured most of the buzz at Microsoft’s TechEd 2010 conference earlier this month, for many IT departments the news of most interest to them was the Redmond software maker’s announcement about another service pack, one for Exchange Server 2007.

Microsoft told its faithful at the conference that Service Pack 3 for Exchange Server 2007 would be ready at the end of this month. The service pack is needed to make Exchange 2007 compatible with Windows Server 2008 R2.

Windows Server 2008 R2, the server variant of Windows 7 and Microsoft’s only 64-bit only operating system, reached retail shelves in October 2009. When the server software was released to manufacturers in July of that year, however, Microsoft declared the operating system would not be supporting Exchange 2007. That Draconian decision produced ululations from many in the company’s user base, some who believed Microsoft was leveraging Server 2008 to coerce companies to move to its latest mail management application Exchange 2010.

The official word from Microsoft as to why it was choking off Exchange 2007 from Server 2008 was lack of resources. It asserted that it was pulling out all the stops on bringing online Exchange 2010, and it didn’t want to dissipate those efforts on a legacy technology like Exchange 2007. While Server 2008 R2 would support Exchange 2007′s domain controllers, the company said at the time, the mail application itself won’t be supported on the server software. Anyone who wants to upgrade to Server 2008 R2, it added, will have to bite the bullet and move to Exchange 2010.

The announcement to abandon Exchange 2007 users who wanted to upgrade to Server 2008 R2 didn’t surprise pundits, but that didn’t dampen the uproar that ensued. For an IT administrator, stepping up to a new operating system like Server 2008 R2 is challenging enough, but to add to that burden another major upgrade, one to  another email program, was not going to win Microsoft any happy points with info tech stalwarts.

Walking away from legacy products always causes grumbling in a company’s user base so a company like Microsoft must be inured to a certain degree of that kind of grousing. This time, though, they apparently miscalculated just how loud the howls of protest would be and how deep the dissatisfaction would run. Faced with that kind of resistance, Microsoft blinked, although it did give its decision its own inimitable spin. Writing last November in a company blog, Kevin Allison, general manager for Exchange customer experience, noted:

“We always talk about listening to customers and sometimes this is written off by many as ‘marketing speak’. In fact, we do take feedback seriously and no input is more important to our engineering processes than your voice.

“Earlier this year we made a decision in one direction, and due to the feedback we have received on this blog and elsewhere, we have reconsidered. In the coming calendar year we will issue an update for Exchange 2007 enabling full support of Windows Server 2008 R2. We heard from many customers that this was important for streamlining their operations and reducing administrative challenges, so we have changed course and will add R2 support. We are still working through the specifics and will let you know once we have more to share on the timing of this update.

“So, keep the feedback coming. We are listening.”

No doubt, Microsoft’s capitulation brought on a sigh of relief from administrators, but those looking for a quick fix to the situation soon discovered it wasn’t coming. Writing shortly after tossing in the towel on Server 2008 R2 support of Exchange 2007, Allison explained that Microsoft may have miscalculated what kind of wherewithal it needed to make the programs play nice together.

“While we had hoped to add this application/operating system combination quickly, unfortunately adding this support requires code changes to setup in Exchange 2007,” he scribbled. “Therefore, our vehicle for adding this support will be via a third Service Pack for Exchange 2007 in the second half of calendar year 2010.”

The arrival of SP3 for Exchange 2007 will make things easier for administrators, but the process before them will remain complex because Microsoft played the short resources card again and says it will not provide in-place upgrades for servers running under Exchange 2007. And, of course, it recommends that organizations that have not installed Exchange 2007 to skip that iteration of the mail program entirely and go directly to Exchange 2010.

Microsoft set to deliver on Exchange 2007 promise

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In Exchange Server the term “Out of Office” refers to the ability of mailbox users to configure a message to be sent automatically as a reply to new messages that informs the sender that they are not available.  Sometimes this is also referred to as a “vacation message”.

In earlier versions of Exchange Server there were two settings for Out of Office – on or off.  However starting with Exchange Server 2007 and continuing with Exchange Server 2010 there are more options available to mailbox users for Out of Office.

Internal vs External

Unlike previous version of Exchange a mailbox user on Exchange Server 2007 or 2010 who is using Outlook 2007 or above can configure two distinct Out of Office messages.  One message is sent to internal senders, and the other is sent to external senders.

The reasoning for this makes a lot of sense – the information that is included in an internal message might be more personal or sensitive than that which can be included in an external message.  Or alternatively, the mailbox user may wish to have only an internal Out of Office reply and send no external message at all.

Internal messages have three settings:

• Enabling/disabling the message
• Configuring an optional start/finish time for the Out of Office period
• The Out of Office message itself

External messages also have three settings:

• Enabling/disabling the message
• Whether to reply only to senders in the user’s Contacts list
• The Out of Office message itself

Managing Out of Office Settings

Mailbox users on Exchange 2003 or earlier (for example in an Exchange organization that is part of the way through migrating to 2007/2010) only have the single, legacy Out of Office message available to them.

Mailbox users on Exchange 2007/2010 who use Outlook versions prior to Office 2007 are not able to configure the internal and external replies using Outlook, and must instead use Outlook Web Access.

Mailbox users on Exchange 2007/2010 who use Outlook 2007 or later are able to configure the internal and external replies using Outlook, and can also use Outlook Web Access.

The administrator is also able to manage an Exchange 2010 mailbox user’s Out of Office replies using either the Exchange Management Shell or the Exchange Control Panel.

For example, this mailbox user has automatic replies configured.

[PS] C:\>Get-MailboxAutoReplyConfiguration alan.reid

Identity       : exchangeserverpro.local/Users/Alan.Reid
AutoReplyState : Enabled

The administrator can disable the Out of Office setting if required.

[PS] C:\>Set-MailboxAutoReplyConfiguration alan.reid
 -AutoReplyState Disabled

Restricting Out of Office Messages

In some businesses the security policy is to not allow Out of Office messages to be sent outside of the organization.  However this policy may also need to be relaxed for certain trusted partners.

This managed in the Exchange Organization settings for Remote Domains.  By default a single * (asterisk) Remote Domain is configured which permits Out of Office messages.  If the above security policy was in place this can be set to allow no Out of Office messages.

[PS] C:\>Get-RemoteDomain | fl name,*oof*

Name           : Default
AllowedOOFType : None

To permit Out of Office messages for a trusted partner the partner’s domain name is configured as a Remote Domain, and configured to permit external Out of Office messages (this will be enabled by default when the Remote Domain is created).

In summary, Exchange Server 2010 permits total control and flexibility of Out of Office messages for both the mailbox users and the administrators.

Exchange Server 2010 Out of Office

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Exchange Server 2010 ships with eight very useful Powershell scripts that can be used for managing Public Folders.  The scripts perform tasks relating to Public Folder replicas and permissions that are otherwise not easily manageable through the management console or shell.

Each of the scripts is developed for making recursive changes to public folders.  This means that when you target the script at a particular folder, or the root of the public folder tree, it applies the action to all subfolders of that folder.

These scripts only apply to servers running Exchange 2007 or Exchange 2010, you can not specify a server running older versions of Exchange Server.

Managing Public Folder Replicas

These public folder replica scripts are used to manage which servers hold replica data for the public folders.  When a script does not specify a server to run against it will default to the nearest convenient server for the public folder being targeted.

AddReplicaToPFRecursive.ps1 – this script adds a server to the replica list for a public folder and its subfolders.

For example, to add EXCH02 as a replica for all public folders on server EXCH01 starting at the root folder of \\ you would run this command.

AddReplicaToPFRecursive.ps1 –Server EXCH01
 –TopPublicFolder \\ –ServerToAdd EXCH02

RemoveReplicaFromPFRecursive.ps1 – this script will remove a server from the list of replicas for a folder and its subfolders.  A server must have all of its public folder replicas removed before it can be decommissioned.

For example, to remove EXCH02 as a replica for all public folders on EXCH01 starting at the root folder you would run this command.

RemoveReplicaFromPFRecursive.ps1 –Server EXCH01
 –TopPublicFolder \\ –ServerToRemove EXCH02

ReplaceReplicaOnPFRecursive.ps1 – this script replaces a server in the replica list of the public folders with another server.  This is useful when public folders are already replicated to more than one server, and one of those servers is being replaced.

For example, to replace EXCH02 with EXCH03 as a replica for the \Branch folder and all subfolders you would run this command.

ReplaceReplicaOnPFRecursive.ps1 –TopPublicFolder \\Branch
 –ServerToAdd EXCH03 –ServerToRemove EXCH02

MoveAllReplicas.ps1 – this script replaces all of the replicas on one server with the new server specified.  You do not need to target a particular parent folder with this script, it will check the entire public folder tree when making the replacements.  This is useful when you want to move all of the replicas from one server to another at once, whereas the ReplaceReplicaOnPFRecursive.ps1 script allows it to be done in a staged manner.

For example, to move all replicas from EXCH01 to EXCH02 you would run this command.

MoveAllReplicas.ps1 –Server EXCH01 –NewServer EXCH02

Managing Public Folder Client Permissions

These scripts are used to manage the client (or end-user) permissions to public folders.  When a script does not specify a server to run against it will default to the nearest convenient server for the public folder being targeted.

AddUserstoPFRecursive.ps1 – this script grants the specified user permission to a public folder and its subfolders.  You can grant permissions to a user or to a group, as long as they are mail-enabled.

For example, to add John Smith as a Reviewer of the “\Branch” folder and subfolders you would run this command.

AddUsersToPFRecursive.ps1 –TopPublicFolder \\Branch
 –User “johnsmith” –Permissions Reviewer

RemoveUserFromPFRecursive.ps1 – this script revokes the specified user permission to a public folder and its subfolders.

For example, to remove John Smith from the “\\Branch” folder and subfolders you would run this command.

RemoveUserFromPFRecursive.ps1 –TopPublicFolder \\Branch
 –User “johnsmith”

ReplaceUserPermissionOnPFRecursive.ps1 – this script will replace a specified user’s existing permissions on a public folder and all subfolders with a new set of permissions.  This is useful when you want to raise or lower the permissions that a user currently has to a set of public folders.

For example, to change John Smith from being a Reviewer of the \\Branch folder and all subfolders to being a Publishing Editor you would run this command.

ReplaceUserPermissionOnPFRecursive.ps1 –TopPublicFolder
 \\Branch –User “johnsmith” –Permissions PublishingEditor

ReplaceUserWithUserOnPFRecursive.ps1 – this script replaces an existing user’s permissions to a public folder and all subfolders with another user.  This is useful if there has been a staff change and you wish to grant the same access to a new user that the previous user had.

For example, to replace John Smith with Peter Brown as the Publish Editor of the \\Branch public folder and all subfolders you would run this command.

ReplaceUserWithUserOnPFRecursive.ps1 –TopPublicFolder \\Branch
 –UserOld “johnsmith” –UserNew “peterbrown”

8 Useful Public Folder Management Scripts in Exchange Server 2010

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Microsoft released some security patches last month without revealing them to the public. Some of the fixes affected software in mission critical Exchange mail servers.

The patches were hidden in one of Microsoft’s periodic updates issued April 13, namely “Microsoft Security Bulletin MS10-024 – Important: Vulnerabilities in Microsoft Exchange and Windows SMTP Service Could Allow Denial of Service (981832).”

“This security update resolves one publicly disclosed vulnerability and one privately reported vulnerability in Microsoft Exchange and Windows SMTP Service,” Microsoft said in the security bulletin’s executive summary.

“The more severe of these vulnerabilities could allow denial of service if an attacker sent a specially crafted DNS response to a computer running the SMTP service,” it continued. “By default, the SMTP component is not installed on Windows Server 2003, Windows Server 2003 x64 Edition, or Windows XP Professional x64 Edition.

It added: “This security update is rated Important for all supported editions of Microsoft Windows 2000, Windows XP, and Windows Server 2003; 32-bit and x64-based editions of Windows Server 2008; Windows Server 2008 R2 for x64-based Systems; and Microsoft Exchange Server 2003. This security update is rated Moderate for Microsoft Exchange Server 2000.”

The bulletin cited two vulnerabilities targeted by the April 13 patches. In one (CVE-2010-1689), Windows SMTP Service generated DNS queries in the transaction ID field with trivially guessable values. In the other (CVE-2010-1690), the service did not check that the ID value of the DNS response received from the network actually matched the value of the ID field of a corresponding DNS packet previously sent.

What Microsoft didn’t mention in its bulletin was that  it was also patching two serious flaws in Windows SMTP Service and Microsoft Exchange that could be exploited in DNS spoofing and cache poisoning attacks. Both attacks are ways to redirect Internet traffic to or through a black hat site for pernicious purposes.

Microsoft’s omission was discovered by Nicolás Economou, a researcher at Core Security Technologies, a security research firm headquartered in Boston. The company said in a security advisory that Economou discovered two vulnerabilities in Windows SMTP Service and Exchange while routinely reviewing the changes described in MS10-024. Although the vulnerabilities were patched by Microsoft, Economou learned, their existence was not disclosed in the software maker’s bulletin.

Moreover, a unique vulnerability identifier had not been assigned to the flaws. “As a result,” Core noted in its advisory, “the guidance and the assessment of risk derived from reading the vendor’s security bulletin may overlook or misrepresent actual threat scenarios.”

In addition, while researching another vulnerability (CVE-2010-0024), Economou unearthed two more “severe bugs” addressed by the April 13 patches but undisclosed by Microsoft.

“Basic analysis of the vulnerabilities disclosed in this advisory indicates that the threat of DNS spoofing attacks against Windows SMTP Service and Microsoft Exchange or of exploitation of CVE-2010-0024 was underestimated in MS10-024,” Core said in its security advisory.

“An attacker may leverage the two previously undisclosed vulnerabilities fixed by MS10-014 to spoof responses to any DNS query sent by the Windows SMTP Service trivially,” it continued. “DNS response spoofing and cache poisoning attacks are well known to have a variety of security implications with impact beyond just Denial of Service and Information Disclosure as originally stated in MS10-024.”

“As a result,” it added, “the importance of deploying MS10-024 patches may be misrepresented in the vendor’s security bulletin. Organizations using vulnerable packages should consider re-assessing patch deployment priorities in view of the additional information provided in this advisory.”

When Core contacted Microsoft about the undisclosed vulnerabilities and why they weren’t issued vulnerability identifiers, or CVEs, the software maker referred Core to a footnote in MS10-024. The footnote said:

“Severity ratings do not apply to this update because the vulnerabilities discussed in this bulletin do not affect [Microsoft Exchange Server 2007 and 2010]. However, Microsoft recommends that customers of this software apply this update, which includes a defense-in-depth measure that adds additional source port entropy to DNS transactions initiated by the SMTP service.”

Issuing stealth patches is apparently nothing new in the software industry. “This has been going on for many years and the action in and of itself is not a huge conspiracy,” Andrew Storms, director of security operations, recently told CIO magazine.

What is unusual is that Core made its discovery of the omissions public. Apparently, it felt the vulnerabilities it discovered should have received more prominent treatment than an obscure reference in a footnote in Microsoft’s security bulletin. In addition, it seems concerned that Microsoft’s assessment of its patches–especially in light of the importance of the undisclosed flaw fixes–was understated and would mislead system administrators. Without knowledge about the significance of the patches, some administrators may put the fixes on a back burner when they should be on a front one.

Microsoft releases stealth patches for Exchange

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Email is one of the most heavily used communications method which makes your Exchange servers critical to your business.

The health and performance of your Exchange servers should be a top priority, and this means that you must monitor the server performance as part of your routine so that problems can be discovered early and resolved before they begin to make a serious impact.

Here are 5 performance counters to monitor on your Exchange servers today.

1. % Processor Time

This counter shows the amount of time that the CPU is processing a task.  This counter should typically be below 75%, although it may run higher during heavy workloads such as backups.  If the processor time is consistently high you will want to look into which processes are utilizing the CPU the most.

2. Processor Queue Length

When instructions are sent to the CPU they go into a queue to be scheduled for execution.  This counter shows the length of that queue, and should ideally be no higher than 5 for each processor in the server.

When this counter is above the ideal threshold along with a high % Processor Time it indicates that the server workload is too high for the CPU resources available.

3. Memory Available MBytes

This counter shows the amount of memory that is not in use and is available for new tasks or processes, and should be at least 100Mb at all times.

If it drops below that threshold then the server memory is inadequate for the workload, and excessive disk utilization may result due to heavy pagefile use to compensate for the memory shortfall.

4. Memory Pool Paged Bytes

There is no threshold to watch for on this counter; however, it should be monitored for any increases over time which indicates a memory leak may be occurring.

5. Physical Disk Average Disk Queue

This counter should be monitored for each individual volume on the server, not for the total amount.  In general a disk queue of 2 or less is acceptable.  A higher disk queue, especially if it is sustained for a lengthy period, indicates that disk I/O is exceeding the performance capabilities of the disks themselves.

This can be normal during heavy disk operations such as backups, but should always be investigated to verify the cause.  When a high disk queue is noticed the first step is to break down whether it is being caused by read or write operations by inspecting the Disk Read Queue and Disk Write Queue.

A Basic Performance Snapshot

These 5 performance counters give you a very basic snapshot of your Exchange server performance. This is very useful even when no one is reporting any problems with the server, because it is important to have performance benchmarks during “good” times to compare to the times when a problem is reported.

If any of the counters indicate a problem in that area then you can start more comprehensive monitoring of related counters to narrow down the root cause of the issue so that it can be resolved.

5 Performance Counters to Monitor on Your Exchange Servers

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Email is not just for people.  It is also used by other services, applications and devices for a multitude of communication scenarios.

Some examples of this are applications that send email reports to users, such as enterprise backup software; devices that offer email capabilities, such as scan-to-email; and applications that receive and parse email messages, such as job ticketing systems.

With these types of requirements it is very common for an Exchange Server environment to host a lot of non-user mailboxes.  In larger environments this can present some challenges.  Each mailbox requires a corresponding user account, which presents some security risks.

And if not tracked and managed properly the number of mailboxes can grow and result in mailboxes that no one knows about or understands the actual purpose for.  This type of mismanagement will crop up at key times such as when migrating to a new Exchange Server, which makes planning and risk management difficult for the project team.

With all of that in mind here are some tips for maintaining a well managed Exchange Server environment for service and application mailboxes.

Only Use a Mailbox When Necessary

This may seem an obvious statement, but a mailbox is usually only required to receive email, not to send it.  For devices and applications that simply need to send out messages over SMTP there is usually no need to create them a dedicated mailbox.

For Meeting Rooms and Equipment Use Those Mailbox Types

Exchange Server 2007 and 2010 come with a dedicated mailbox type for room and equipment facilities.  Using the correct mailbox type ensures that the room or equipment is shown correctly in address lists and calendar appointments.

For more information about these mailbox types check out this three part series on managing Exchange resource mailboxes.

Secure the Mailboxes

When you do create mailboxes for non-user access always set a very strong password, and disable the user object in Active Directory.  When you use the special Room and Equipment mailbox types the account is automatically disabled for you.

The exception to this rule is for applications that need to authenticate with Exchange to function.  This is usually the case with backup products that need an active logon and mailbox to be able to backup the mailbox databases.

Use Descriptive Names and Notes

Two years from now when someone asks “What is this EUK-DRJ-VAR mailbox for?” and there is no one around who knows it is going to cause some headaches and potentially some service downtime if the mailbox is moved or modified.

Always give non-user mailboxes a clear, descriptive name that provides lots of clues as to what it is for.  Each mailbox also has a “Notes” field that can be filled out with as much detail as you like about the purpose of the mailbox.

Keep a Database or Register

Aside from descriptive naming and notes it is wise to keep a separate register of non-user mailboxes for reference over time.  This can provide the maximum detail about the mailboxes and avoid situations in the future where valuable time is wasted investigating mystery mailboxes.

Using just these few simple tips for creating and managing service and application mailboxes will ensure that administrative effort is minimised, services and applications aren’t interrupted unnecessarily, and changes such as migration projects don’t suffer delays.

How to Manage Service and Application Mailboxes in Exchange

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

We are conducting our lives and our businesses in an increasingly mobile world.  We need access to our critical business information from multiple locations and using multiple devices.

These needs often clash with the requirement to keep our data secure.  Exchange Servers are kept behind corporate firewalls which restrict who can access them and how they can connect to their mailboxes.

Secure mobile access to mailboxes on Exchange Servers is typically achieved through one or more of these methods:

• Virtual Private Network (VPN)
• Outlook Anywhere
• Outlook Web App (OWA)
• ActiveSync

Virtual Private Networks

A VPN is a secure communications tunnel established between two endpoints.  These endpoints can be two devices such as routers or firewalls, or can be between a client device such as a laptop and a firewall.

Mobile workers use VPNs to establish LAN-like network access to their corporate network.  This usually means that once connected to the VPN they have access to the same network resources they would be able to access when connected to the LAN from within the business premises.  In more security conscious environments this access is sometimes limited to just the few resources they need, but in a practical sense operates just as if they were on the LAN.

Using VPNs for access to Exchange Server makes sense when there are other needs for VPN access as well, such as access to application servers, file servers, or intranet sites.  Rather than each resource having its own independent access method, the VPN provides an “all in one” access solution.

However sometimes VPNs are not practical.  It is not uncommon for a mobile worker to find they are unable to establish a VPN tunnel because of restrictions on the foreign network they are currently working on.  This is mostly the case for IPSEC and PPTP VPN tunnels.  SSL VPN tunnels usually have no such problems because the SSL/HTTPS port is usually permitted out through firewalls.

Outlook Anywhere

Outlook Anywhere was formerly known as RPC-over-HTTPS, which accurately describes how it works.

The Outlook connection to a mailbox server over RPC is tunnelled through an SSL/HTTPS connection so that it can traverse firewalls, as well as to secure the communications over untrusted networks.

Outlook Anywhere is a good solution for secure access to email alone, but provides no access to other resources on the network that the mobile worker might need.

Outlook Web App

Outlook Web App (OWA), known as Outlook Web Access prior to Exchange Server 2010, provides a web-based interface to Exchange Server mailboxes over an SSL/HTTPS connection.  Because access is available via a web browser this makes it accessible for mobile workers who do not have access to the full Outlook software, such as on a home computer or an internet kiosk.

OWA communications are secured over SSL/HTTPS, however when using untrusted computers such as internet kiosks there is the risk of key loggers or other malicious software being used to compromise account passwords.

Because of this risk it is common to use multi-factor authentication with at least one of those being a biometric or a one-time password generated by a token, so that even if the username and password combination are compromised the account cannot be accessed without the additional authentication item.

ActiveSync

ActiveSync is the name of Microsoft’s technology for connecting devices such as smartphones to Exchange Server mailboxes.

The connection is once again secured over SSL/HTTPS and can be subject to numerous restrictions and security policies designed to mitigate the risk of loss due to theft or loss of the smartphone device (which is fairly high risk given their size and general lack of security features).

Those are the four most common secure remote access methods for Exchange Server mailboxes.  I’ve left out some other access methods such as POP and IMAP. Although these can be used securely they are not very common and don’t provide a full functionality experience with Exchange Server.  For most real world scenarios some or all of the above four methods are the solution for secure remote access.

4 Ways to Access Exchange Server Mailboxes through Firewalls

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The concept of message size limits in email systems dates back to the earliest years when email first became available.  In those days network speeds and server processing power were both much smaller than today’s modern computer networks.  Large emails could saturate the available bandwidth on network connections or overload a server to the point it would crash.

The concept carried forward into modern environments as email became an often overused method of transferring files between parties.  It was not unusual for Exchange Server environments to have multiple configurations in place that queued large email delivery for outside of business hours so that regular daytime email traffic was not slowed down.

Current versions of Exchange Server (2007 and 2010) removed that particular capability, in a nod towards modern networks having bandwidth and server resources far in excess of even just 5 years ago.

So does this mean the concept of message size limits is no longer important?  I helped a customer this week with a problem that demonstrates it is still very important.

The customer’s Exchange server had experienced a crash of the Transport services, which could not start and stay running for longer than a few moments before they would stop again.  The servers logs told me that the Transport services were exceeding their maximum threshold for resource utilisation and were then being stopped as a result.

On closer inspection I noticed that the Exchange servers had no message size limits configured on them.  There was one limit of 200mb specified on the hardware appliance that accepted incoming internet email, but otherwise no limits configured on internal or outgoing email.

My next step was to apply some generous, but still sensible, message size limits on the server.  The next time the Transport services started I was then able to inspect the queue and saw the message that had caused the original crash – a message with a 250mb file attachment.  With the new limits in place this message was rejected by the Transport service instead of trying to process it, and the server was able to be recovered to normal operations.

Exchange Server 2007 and 2010 offer multiple ways to configure message size limits, each of which is appropriate for different scenarios.

The first settings are the Organization limits, which apply to all Transport servers in the organization.  Because of its broad application this setting must be carefully planned so that it suits most usage scenarios in the environment, though it is possible to set more granular exceptions.

Each Transport server can also be configured with its own server-specific limits.  This is more often used on Edge Transport servers which by their nature are individually configured.

Active Directory Site links, which are the connections over which Exchange routes inter-site email, can also have their own message size limits applied.  This is useful if low bandwidth satellite sites exist that need to be restricted to much small sizes to prevent bandwidth saturation.

Each Transport server also has a series of Receive Connectors on it that can be subject to individual limits.  One possible usage scenario here would be scan-to-email devices that need to be permitted to send larger files than would normally be allowed to be sent by regular email users.

Outgoing email size restrictions can also be applied to Send Connectors to allow granular control over which size messages are allowed to go out from the network.  This is useful for when specific partner companies need to be sent larger files than normally allowed out of the network.

Finally it is possible to configure message size limits on a per-group and per-mailbox basis.  For example, the All Staff group can be limited to much smaller attachment sizes than normal so as to encourage more efficient methods of distributing files to staff.  Or specific users might need to be able to receive larger than normal file attachments from an important business application.

Because of the risks that oversized email messages still carry for Exchange Server environments, as I experienced this week, and the complexity of configuration options available in Exchange 2007 and 2010, it is important that size limits be carefully considered and planned for your Exchange server environment.

Are Message Size Limits Still Important in Exchange Server?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

There have been many times in the past when I have started a project for a new customer and discovered that they are not using SSL for their email servers.  Usually after a brief discussion they agree to implement SSL in the new system we are installing for them.

Occasionally they agree but insist on doing it in a less than ideal manner.  And sometimes, although rarely, they decline our advice and continue without SSL.

What is SSL?

SSL stands for Secure Socket Layer and is an encryption protocol that secures communications between two parties over insecure networks such as the internet.  Although still commonly referred to as SSL its new name is actually TLS (Transport Layer Security) which more accurately describes its role of securing communications at the Transport layer of the OSI model (eg, the TCP protocol).

In an SSL/TLS secured communication the two parties (e.g. a web server and a web browser) agree on how to secure the connection they are establishing.The server sends the client its public encryption key (sometimes known as an SSL certificate) which the client then verifies against its own list of trusted certification authorities.  Once it has verified the key the client will generate a random number, encrypt it with the server’s public key, and send it to the server.  The public key encryption ensures that only the server can read the random number.

Contrary to popular assumption it is not the server’s public key (or SSL certificate) that is used for the encrypted connection, rather it is only used to secure the initial exchange of the random number.  The random number is then used to encrypt and decrypt the actual connection traffic.

Why is SSL important for Exchange Servers?

Exchange servers come with useful remote access features such as Outlook Web Access, Outlook Anywhere, and ActiveSync.  These features allow your users to access their email from any location with an internet connection by using a web browser, their laptop, or a mobile device such as a smartphone.

This convenience carries with it some security risks, the most obvious being the risk of password credentials being compromised.

Operating any of these remote access services without SSL means that the connection, including password credentials, occurs over an unsecured HTTP connection.  HTTP is the protocol that most websites use.  It is fast, stable, and works through just about any firewall.  But HTTP has no built in security.  Every bit of data sent over HTTP is unencrypted, so when passwords are sent over HTTP they are sent “in the clear”, vulnerable to network sniffers.

Because so much of this remote access occurs from untrusted locations such as free wireless hotspots, it is critical that SSL be used to protect this traffic.

Recommendations for using SSL

Here are some recommendations for using SSL to secure your Exchange server’s remote access features.

• Make it mandatory, not optional.  If you enable SSL but also still allow unencrypted HTTP you make it possible for an unwitting user to connect over the insecure method.
• Use it internally as well as externally.  It is tempting to allow non-SSL connections from locations within your own corporate network but this is still risky.  Some security professionals consider all network segments to be untrusted.
• Use a commercial Certificate Authority instead of a private one.  You may be tempted to save money on SSL certificates by installing a private CA and issuing your own, but this causes more headaches than it is worth.  Your private CA will not be trusted by devices such as smartphones or non-corporate computers, and will result in SSL warning messages that confuse users and can make some applications refuse to connect at all.  Because the SSL warning messages are also often found with phishing sites like fake banking sites it is not a good idea to get your users used to ignoring them.

The Importance of SSL for Exchange Servers

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Some Exchange Server 2007 and Exchange Server 2010 roles require Internet Information Services (IIS) to function.   On these servers Exchange will install a series of IIS virtual directories.  In this post I will describe the Exchange Server virtual directories and their purpose.

/owa – This is the directory for OWA (Outlook Web Access on Exchange 2007, and now called Outlook Web App on Exchange 2010), which is the web browser version of Outlook that is usually accessed by remote workers.  The /owa directory is for access to Exchange 2007 or 2010 mailboxes.

/Public – This is the directory used by OWA users when accessing any Public Folders in the organization.

/Exchweb – This directory is used for OWA access for Exchange 2003 or 2000 users but is not usually accessed directly by the end user.  The OWA session will automatically refer the connect to this virtual directory when necessary.

/Exchange – This directory is again used for OWA access.  When an Exchange 2003 or 2000 mailbox user access the /Exchange virtual directory they are proxied to their mailbox.  For Exchange 2007 or 2010 mailbox users they are redirected to the /owa directory for their mailbox access.

This is useful during the transition from legacy Exchange versions to 2007 or 2010, because users can continue to connect to the /Exchange directory and the result will always be that they connect to their mailbox, as long as the server does not run the Mailbox Server role.  In other words, the /Exchange directory only works for legacy mailbox users if the server is a dedicated Client Access Server (though it can also contain the Hub Transport Server role without a problem)./Exadmin – this directory is for administrative purposes only.  Normal users cannot access this directory.

/Microsoft-Server-ActiveSync – this directory is for ActiveSync clients to connect to mailboxes.  These are typically mobile phones or smart phones that have an ActiveSync-compatible email application.

/OAB – this directory publishes the Offline Address Book for clients running Outlook 2007 and above.  Earlier versions of Outlook download the OAB from Public Folders instead.

/Autodiscover – this directory publishes Autodiscover information.  Clients running Outlook 2007 and above, and some ActiveSync clients, can query Autodiscover for a user’s mailbox configuration and automatically set up the mail profile without the end user needing to enter details such as server names.

/EWS – this directory publishes Exchange Web Services, a new programming API that makes Exchange data available to third party applications.

/Rpc and /RpcWithCert – these directories are for Outlook Anywhere, which was formerly known as RPC-over-HTTPS.  As the name suggests, this allowed Outlook clients to make an RPC connection to the Exchange server over an SSL encrypted tunnel from anywhere, making it possible for staff on the road to continue using Outlook without interruption.

/UnifiedMessaging – this directory allows access to Unified Messaging Web Services.  Unified Messaging is Exchange Server’s telephony integration, with features such as voicemail, auto attendants, and Outlook Voice Access.  This virtual directory allows the integration of Outlook and OWA with Unified Messaging for features such as voice mailbox PIN resets and playing voicemail messages within OWA.

/PowerShell – this directory, appearing only in Exchange 2010, allows remote management sessions from the Exchange Management Shell.

/ecp – this directory, again new to Exchange 2010, publishes a self-service control panel for administrators and users.  A broad range of administrative tasks can be delegated to power users and made accessible through the Exchange Control Panel, such as creating new distribution groups and managing SMTP addresses for mailbox users.  Normal users can also access self-service options such as updating their personal information.

Overview of Exchange Server Virtual Directories

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Microsoft Exchange Server has used Connectors in various ways for many different product versions to date.  Exchange Server 2007 and Exchange Server 2010 both use the same types of Connectors in their organizations.

Even in simple organizations some people become confused by the variety of Connectors and their purposes.  Here is an explanation of each type of Connector for Exchange Server 2007 and 2010.

Send Connectors

Send Connectors are responsible for sending email to servers outside of the organization.  This might also include Edge Transport Servers, which are non-domain member servers usually located in a secure DMZ for sending and receiving internet email.

Send Connectors can be configured in a number of different ways.  The typical Send Connector for an organization sends all outbound email to a smart host or uses DNS to route the mail directly to the receiving party.

More specific Send Connectors can be used to send email destined for particular domains to different servers.  One example would be a Send Connector that routes email across a secure VPN to a partner domain rather than go via the internet.  Another example would be a Send Connector that has a larger message size limit than the default one, permitting very large files to be sent to partners or customers.

Send Connectors can be configured with authentication requirements when sending to a smart host, but when sending via DNS lookup have no authentication options to configure.  However, Exchange Server will honour the receiving server’s security or authentication requirements (such as TLS encryption) where possible.

Receive Connectors

Receive Connectors are responsible for receiving incoming email sent to a Transport server.  This includes mail sent from Mailbox Servers, POP3 and IMAP clients, and other hosts or applications sending via SMTP.

By default a Hub Transport server is configured with two Receive Connectors – one for clients (POP3 and IMAP) and one for SMTP.  Both are configured as secure by default and should be kept that way if possible.

Other common uses of Receive Connectors are for secure relays within an organization.  This is typically for devices such as scanners that scan to email, or application servers that send SMTP notifications.

Receive Connectors can be configured with a broad range of security options, such as restricting to certain IP addresses or subnets, requiring certain authentication methods, or by limiting connecting servers to only certain actions (eg only sending to internal addresses, allowing override of sender spoof checks, or allow override of size limits).

It is important not to expose unsecured Receive Connectors to the internet as this may cause the server to be exploited as an open relay.

Linked Connectors

A Linked Connector is a relationship between a Receive Connector and Send Connector that overrides the normal routing topology.  The common use of Linked Connectors is to route mail off to a smart host to perform spam and virus checks before it is sent on within the organization.

Large, complex organizations can make use of Linked Connectors to check emails that are sent from potentially insecure segments of the network before they are allowed to be routed throughout the organization.

Foreign Connectors

Foreign Connectors use a drop folder in the file system to route email to servers or applications that do not use SMTP.  These are commonly found with enterprise faxing applications.  Email messages that match the criteria of the Foreign Connector are dropped as individual files into a folder where they are picked up by the third party application for the next stage of their processing.

Routing Group Connectors

Routing Group Connectors are carried over from versions of Exchange prior to 2007.  The concept of a Routing Group no longer exists in Exchange Server 2007 and 2010, instead Exchange uses the Active Directory Site topology for message routing.

However, the Routing Group Connector is still available in Exchange Server 2007 and 2010 for co-existence scenarios with legacy Exchange versions, and handle routing of email messages between the different server versions.  Once an organization has no more legacy Exchange servers in the organization the last Routing Group Connectors are removed.

Understanding Exchange Server Connectors

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Exchange Server 2007 introduced new terminology for describing the domain names that it will accept email for, and what it will do with that email.  This is referred to in Exchange Server 2007 as Accepted Domains.

In Microsoft’s own words, “an accepted domain is any Simple Mail Transfer Protocol (SMTP) namespace for which a Microsoft Exchange organization sends or receives e-mail.”

Accepted Domains fall into one of 3 categories – Authoritative, Internal Relay, and External Relay.  Any given namespace that is an Accepted Domain can be only one of those three types.

Authoritative Domains

Authoritative Domains are those for which an Exchange organization hosts mailboxes that have email addresses that use that domain.

For example, a company named Contoso Pty Ltd may own the domain name contoso.com and use email addresses of name@contoso.com.  The Exchange organization would be configured to consider contoso.com an Authoritative Domain.

An organization can have more than one Authoritative Domain configured.  Using Contoso Pty Ltd as an example again, they may have a second brand name of Contoso Services and use the contososervices.com domain name in marketing materials.  In this case the Exchange organization would be configured with both contoso.com and contososervices.com as Authoritative Domains.

Internal Relay Domains

Internal Relay domains are those for which an Exchange organization hosts some, but not all of the mailboxes that use that domain.  This scenario is sometimes also referred to as a “shared SMTP namespace”.

Internal Relay domains are common when two companies have merged but are yet to consolidate their Exchange environment into a single organization.  When they have a need for consistent email addressing across both Exchange environments Internal Relay domains are the solution.

When an Accepted Domain is configured as Internal Relay it tells the Exchange organization to accept mail for that domain, but if no recipient in that organization has that email address then it looks to the list of Send Connectors to determine where to send it next.

For example, if Contoso Pty Ltd and Northwind Traders formed a new company Contoso Traders with a new domain name of contosotraders.com, then each existing Exchange organization is configured with two items to share the SMTP namespace:

• An Internal Relay domain of contosotraders.com
• A Send Connector for the namespace contosotraders.com that sends email for unknown recipients to the other Exchange organization

External Relay Domains

External Relay domains are those for which an Exchange organization will accept email, but hosts no mailboxes for that domain.  This scenario might occur when one organization is acting as an ISP for other organizations, or offering services such as email content filtering.

External Relay domains are used when one Exchange organization is accepting email from the internet for a non-authoritative domain name, and then forwarding it on to the authoritative Exchange organization.  This is usually performed at the Edge Transport Server to keep email for non-authoritative domains from entering the corporate network.  For this to occur the Edge Transport Server is configured with two items:

• An External Relay domain
• A Send Connector for the namespace that sends the emails to the authoritative Exchange organization

In these scenarios it is also common for the Edge Transport Server to be used as an outbound email relay, or smart host, for the authoritative Exchange organization.

Summary

For most Exchange organizations the Authoritative Domain type is the only one used, however it is important for email administrators to understand the full capabilities of Accepted Domains as explained above.

Understanding Exchange Server Accepted Domains

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Certificates and encryption utilizing them play a critical role in modern systems and network security. Even if none of your email users has a client certificate in their email application, and they’re not using PKI for a VPN connection, they’re using certificates in more than a couple of places on a Windows network with Active Directory and Microsoft Exchange. You say, “Clemmer, I know all this, so what?”

Certificate Import Wizard

As I discovered recently, the need to renew certificates only once every year, two years, or more, can make for some hair-pulling troubleshooting with turnover with IT departments often shorter than that time period and likely sparse internal documentation for the many “set it and forget it” configuration components of the CA infrastructure.

Managing certificates can be relatively easy or could be (or become) rather difficult depending on how you go about it and how far you leverage the tools available to assist or automate things. Lack of user understanding for this very technical topic, along with frequent confusion on the part of new administrators as well as complex and dry documentation can all contribute to problems. Another area of confusion is the many places that certificates can be integrated and the different roles of certificates in your infrastructure.

Your Active Directory domain is going to require Microsoft certificate services provided by at least one Microsoft Certification Authority running on a server, often a domain controller. You can configure a Certification Authority (CA) numerous ways, and they can have various roles. Best practices define a number of design specifics that are generally well documented in Microsoft’s training materials and on TechNet. An Enterprise CA requires Active Directory and can be used to “issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions), authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS), and logging on to a Windows Server 2003 family domain using a smart card.” CAs can publish certificates to Active Directory (AD) for users and computers as well. A number of CA policy, certificate templates, domain security policy, and AD security settings must be set correctly for certificates to be published automatically.

Email and Microsoft Exchange specifically can leverage certificates in several ways, with internal transport certificates, self-signed certificates, SMTP TLS certificates, and more. Check out this Certificate Use in Exchange Server 2007 on the various uses of certificates in Exchange Server. Certificates are used to encrypt LDAP communication as well, although Exchange normally uses self-signed certificates to encrypt LDAP communication between its ADAM instance (at the Edge Transport) and internal Active Directory servers. Most email admins are aware of the use of certificates in Web SSL traffic, and with Exchange SSL is used to communicate between various Web clients and Client Access servers. Even ActiveSync users that connect to Exchange use SSL certificates to encrypt their sessions.

In almost all cases where the communication traverses an unsecured, partially secure, or untrusted partner network, you will likely want to use a third party, external X.509 CA. When communication is with internal resources, but perhaps ones that are remote, an internal enterprise CA may be preferable due to cost. This leads us back to some points made at the beginning of this post, that an internal CA is a CA that you must manage. Clients and computers will need certificates, and those certificates will expire after a year or two. Servers and applications will also be issued some of these certificates, and they too will need renewal when the time comes. You say “Clemmer, I’ll just increase the key size and set the certificate expiration to five years.” That may delay the renewal effort, certainly–but it won’t eliminate the effort–only delay it. Cracking private keys for certificates with large key sizes isn’t much of a concern today, but with the continuing increase in computing power who it to say that a standard sized private key can’t be cracked four years from now? Consider too that some keys will need to be re-created when new server services appear, and your choice when upgrading services, applications, and operating systems will be to either migrate the certificates you have, or regenerate all of them. Will you really be running the same systems in five years?

I found the solution to my curious problem with certificate renewal in our two-level domain hierarchy in this TechNet article. It’s worth a read if you are expanding your Windows network or designing an improved domain structure.

Microsoft Certification Authority, Certificates, Your AD forest, and More

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

When planning an Exchange Server 2007 project with customers the question of Public Folders always comes up.  One of the scenarios in which Public Folders are discussed is by customers who do not currently use Public Folders, and who want to know whether they need to use them with Exchange Server 2007.

The question relates to the topic of Free/Busy information, which is the data from mailbox users’ calendars that lets others see their availability when trying to schedule meetings in Outlook.

Exchange 2003 stores Free/Busy information in the Public Folder database for all mailbox users, whereas Exchange Server 2007 introduced a new feature called the Availability Service to replace that functionality.  The Availability Service runs on the Client Access Server role.

The Availability Service does not store Free/Busy data, rather it retrieves it on request directly from the mailbox in question.  This is in contrast to Exchange 2003 which stored the data in a special Public Folder.  The data was published to the Public Folder by the Outlook client itself, and so it was not always completely up to date.

Some of the advantages of the Availability Service over the Public Folder publishing method are:

• Makes Free/Busy data sharing available in a more granular fashion for end users (e.g., can choose to just show whether they are free or not, or also show details of the meetings they have planned, etc)
• Simplifies cross-Forest sharing of Free/Busy data by making it directly accessible between organizations, instead of the legacy method of synchronizing Free/Busy data with the Inter-Org Replication Tool
• Exposes Free/Busy data via Exchange Web Services so that it can be accessed by other programs via APIs

The main dependency of the Availability Service is that it can only be accessed by Outlook 2007 and later clients.  Outlook 2003 and earlier have no ability to query the Availability Service.  This leads to some confusion for customers, especially during a migration project when both Exchange 2003 and 2007 co-exist in the organization.Consider an organization that is in the process of migrating to Exchange Server 2007 and so has mailbox users on both 2003 and 2007 mailbox servers.  Access to Free/Busy data will be achieved in the following ways:

• Regardless of the Outlook version, any Exchange 2003 mailbox user will publish Free/Busy data to the Public Folders
• Regardless of the server version, any Outlook 2003 or earlier client will publish Free/Busy data to the Public Folders, and read Free/Busy data from the Public Folders
• Outlook 2007 clients on Exchange 2007 mailbox servers will query the Availability Service for Free/Busy data
• The Availability Service retrieves Free/Busy data directly from Exchange 2007 mailboxes, and from Public Folders for Exchange 2003 mailboxes

What this usually boils down to for customers, when planning for the stage that they are running only Exchange 2007 servers, are these simple rules:

• If you have any Outlook 2003 or earlier clients, you will still need Public Folders for Free/Busy information
• If all your clients are Outlook 2007 or later, you do not need to retain Public Folders for Free/Busy information

It may seem a trivial issue, but being able to remove Public Folders completely makes the environment that little bit easier to deploy and administer.  At the very least it is one less database to backup on the server.

Exchange Server 2007 Availability Service Explained

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Let’s be clear about this before we go any further – yes you could use these techniques to spy on your staff, and yes at face value it may seem as though these techniques serve no purpose other than to spy on staff.  But the reality is that what I’m about to describe can be used quite legitimately within a business for purposes other than outright spying.

There are two features of Exchange Server 2007 that can be used for this – Journaling and Transport Rules.

Exchange Server 2007 Journaling

The best way to think of Journaling is that it is a way to make a copy of emails that match certain sender or recipient conditions.  Typically this is done for regulatory compliance purposes, such as a legal requirement to retain copies of all email received by a government department for Freedom of Information purposes.

When an email is “journaled” it is simply copied to another mailbox.  Basic Journaling will copy all emails sent to and from recipients on a mailbox database to a specified journal mailbox, whereas Premium Journaling allows some more granular control such as per-recipient journaling rules, but the concept remains essentially the same.

A genuine application of Premium Journaling might be to journal all emails sent to or from a customer service email address so that all such communications are kept on record.

Exchange Server 2007 Transport Rules

Transport Rules can be used to achieve the same outcome as Journaling however they have a lot more features available and offer much more granularity.  For example you can use Transport Rules to add disclaimers to emails in Exchange, or block confidential emails.

You can also use Transport Rules as a kind of internal email filtering for inappropriate content.  This would be useful for policing acceptable usage policies.  By configuring a Transport Rule that detects certain words and blind copies any such email to a HR mailbox for inspection an organization might detect and avoid harassment issues within the organization.Similar rules could be configured to detect certain words that refer to trade secrets or confidential information to try and detect anyone discussing those topics with outside parties.

Less ethical uses might include use of Transport Rules to find out who is emailing recruitment firms looking for a new job, or who is discussing romance, religion, or other private matters.

The Email Administrator’s Dilemna

Although the title of this post was designed to be slightly tongue in cheek, the reality is that email administrators can be put into some tough situations by the availability of these features.

Just about any email server product has had the ability to tell from log files who emailed who and at what time, but usually doesn’t include any of the actual email content (sometimes the subject line is logged).  This is for two main reasons – firstly we really don’t care what is in the email itself, we’re only interested in whether or not it got delivered, and secondly logging all of the email content would take up a lot of disk space.

Journaling has been a feature of Exchange Server prior to the 2007 version, but Transport Rules are new to Exchange 2007.  These features can mean a few tricky situations for email administrators to be aware of.

Firstly there are the legal considerations, such as whether the availability of the feature compels you to employ it to protect staff, for example from email harassment.  Another legal consideration is whether the use of these features will result in email administrators being dragged into any legal matters that might spawn from email communications.  From personal experience this is a very real possibility.

Secondly there are the ethical considerations.  If you as the email administrator are directed by a superior to configure a Transport Rule that would effectively spy on an individual within the organization you might be enabling harassment or bullying to take place, which could land you in some hot water if you go along with it.  Again from personal experience this can happen, but usually if the request is from HR or an Internal Audit department it is clearly okay.

So there you have it, two useful and powerful features of Exchange Server 2007 that can be used for a variety of good and evil purposes.  Make sure you understand each feature, its capabilities and limitations, and always consider the legal and ethical implications of the actions you take with them.

How to Spy on Your Staff with Exchange Server 2007

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Within an organization there is often communication that occurs between staff that should remain confidential and kept within the business only.  However any time confidential information is placed in an email there is the risk that someone will accidentally send the information outside of the business.

Exchange Server 2007 and Outlook 2007 use a feature called Message Classification to prevent this accidental information leakage from occurring.

What are Message Classifications?

A message classification is simply metadata added to an email message that describes the intended use or audience of the message.  Message classifications can be created or customized to suit any type of business with any type of classification need.

When combined with Exchange Server 2007 Transport Rules message classifications can be used to enforce email policies such as the forwarding of confidential information.

Enabling Message Classifications

Although it it possible to create your own message classifications, Exchange Server 2007 ships with several default classifications that will suit most businesses.  These message classifications must be exported to an XML file and distributed to clients.Run the Export-OutlookClassification.ps1 script from C:\Program Files\Microsoft\Exchange Server\Scripts.

[PS] C:\>.\Export-OutlookClassification.ps1 > c:\msgclass.xml

The file must now be placed somewhere for the client PC’s to access it.  Although a network share can be used it is more reliable to distribute the file to the local hard drive of each computer.

Next, create the following registry keys to reference the classifications file.

[HKCU\Software\Microsoft\Office\12.0\Common\Policy]
"AdminClassificationPath"="c:\\admin\\msgclass.xml"
"EnableClassifications"=dword:00000001
"TrustClassifications"=dword:00000001

When Outlook 2007 is next launched by the end user they will have access to the message classifications when composing new messages.

Creating Transport Rules

With message classifications in use it is now possible to configure Transport Rules to protect confidential emails from being sent outside of the company.  Launch the Exchange Management Console and navigate to Organization Configuration/Hub Transport.  Click on the Transport Rules tab and then start a new Transport Rule.

Give the rule a meaningful name, for example “Block Outbound Confidential Emails”.

Set the conditions for email sent outside the organization and classified as “Company Confidential”.

Configure the rule action to send a bounce message to the original sender with a message that makes it clear to them why the message was blocked.  Don’t forget to also configure the rule actions to drop the message as well.

If there is any reason for an exception, such as allowing the CEO to send confidential emails to outside partners, you can configure it as well.  Otherwise just complete the Transport Rule wizard.

Testing the Transport Rule

You can test the new Transport Rule by simply sending any email classified as “Company Confidential” to an outside email address.  The Exchange server will return an error message to the sender.

Limitations of Message Classifications

The important thing to note here is that message classifications require some implementation effort, must be deliberately used by end users when sending emails, and only prevent accidental exposure of confidential information.  For example, a user who receives a classified message is free to remove that classification when they forward the email to an outside recipient.  Of course, such deliberate acts are almost impossible to guard against anyway.  Still, message classifications provided a decent option for enforcing email policies.

How to Protect Confidential Emails with Exchange Server 2007

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators