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. Continue reading The Importance of SSL for Exchange Servers

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). Continue reading Overview of Exchange Server Virtual Directories

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.

Continue reading Understanding Exchange Server Connectors

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. Continue reading Understanding Exchange Server Accepted Domains

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.

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

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. Continue reading Exchange Server 2007 Availability Service Explained

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. Continue reading How to Spy on Your Staff with Exchange Server 2007

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. Continue reading How to Protect Confidential Emails with Exchange Server 2007

Exchange Server 2007 provides the capability to append a text disclaimer to any email message.  This capability is provided by the Transport Rules feature of the Hub Transport Server.  Email disclaimers are required by some businesses to notify recipients of such matters as copyright, confidentiality, or liability of a sent email.

Transport Rules are configured to perform certain actions on any email message that matches the criteria of the rule.  For example a Transport Rule can be configured to blind copy all emails sent to a certain person to another person.   For email disclaimers the Transport Rule is simply configured to append the text disclaimer to any message sent to an external recipient by using these steps. Continue reading How to Configure Email Disclaimers in Exchange Server 2007

Microsoft Exchange Server 2007 ships with some useful tools for testing the health of the different server roles.

These tools come in the form of PowerShell cmdlets that can be executed from the Exchange Management Shell.

The tools are very handy both during implementation of new Exchange systems as well as when investigating faults.

General Tests

Test-ServiceHealth – tests the health of the Exchange services on the server and lets you know if any required services for the installed roles are not running.

Test-SystemHealth – this is the command line version of the Exchange Best Practices Analyzer, and will alert you to any error conditions or configurations that deviate from best practices.

Test-Path – this is not strictly an Exchange test.  Test-Path is useful when building scripts and is used to verify the existing of an element such as a file, folder, or registry key, returning a simple True/False answer.

Client Access Server

Several of the Client Access Server tests utilise a system-managed test mailbox which you must first create by running the new-TestCasConnectivityUser.ps1 script from C:\Program Files\Microsoft\Exchange Server\Scripts.

Incorrect Client Access Server configuration can cause a wide range of problems within an Exchange Server 2007 organization so these tests are essential during any Exchange implementation. Continue reading Testing Exchange Server Health with PowerShell