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 2010 has similar capabilities to Exchange Server 2007 when it comes to adding disclaimers to emails sent by end users.

However two improvements have been made in Exchange Server 2010 – the ability to use HTML to format the text, and the ability to insert Active Directory attributes into the text.

These new capabilities make it very easy to add a standardised email signature and disclaimer to all emails sent in the organization.

For this to work the desired Active Directory attributes need to be populated on the user account objects.  Attributes that would commonly be used in email signatures include the person’s name, job title, phone number, and street address.

You can view and edit these attributes in the properties of the mailbox or user account.

When the user accounts are populated with the necessary attributes you can proceed with the creation of the Transport Rule that will add the signature and disclaimer. Continue reading How to Add Automatic Email Signatures and Disclaimers with Exchange 2010

Microsoft Exchange Server 2010 is now available but some businesses will be wondering whether the upgrade is worth it.  Many of the new features of Exchange 2010 can only be used with Outlook 2010, which is several months away from being released.

So if the new features can’t be used, should businesses wait to deploy Exchange 2010?  The new features of Exchange 2010 can be broken down into two categories.

Back-End Exchange 2010 Features

A lot of the attractive new features of Exchange 2010 are in the back-end.  This means that the features or improvements are server-side as opposed to client-side, and can be taken advantage of immediately.

These features include better high availability features to improve the reliability and resilience of the Exchange environment, and database performance improvements that lower the storage costs of deploying Exchange 2010.

A business can immediately take advantage of these features by deploying Exchange 2010 in their organization.  However they should also consider any reasons not to deploy Exchange 2010, and instead may consider deploying Exchange 2007 instead, or staying on Exchange 2007 if they are already there.

The reason for not moving to Exchange 2010 will mostly come down to the compatibility of third party integrated products, such as enterprise mobile messaging, backup, archiving, and email security.  Not all vendors for these products have updated their software to be compatible, and so if those systems are critical to the business then an Exchange 2010 deployment may not be appropriate.

Exchange 2010 also removed some legacy application programming interfaces in favour of the new Exchange Web Services that was introduced with Exchange 2007.  Again if a business has legacy Exchange-integrated applications that rely on those interfaces then an upgrade would be unwise until the legacy apps are themselves upgraded or replaced.

Client-Side Exchange 2010 Features

For all the back-end improvements it is the front-end, or the Outlook client by wich most people will judge Exchange server.

Although Exchange 2010 has many new client-side features such as Mail Tips, archiving, and the Exchange Control Panel for self-service administration, these are mostly only available when the end user has Outlook 2010.

Not being able to take immediate advantage of new client-side features may undermine the business case to move to Exchange 2010.   However if an Exchange upgrade must be performed (eg, the version the business is currently on is 2003 or earlier, which are either already unsupported or about to become unsupported) then it makes sense to consider the latest available version. Continue reading Exchange 2010 Worth It Without Office?

In a recent post I discussed the various factors that must be considered when planning an Exchange database design.

For Exchange Server 2003 and 2007 the layout and naming of databases played an important role in the ease of administration as well as the balancing of database load.  If Help Desk staff randomly chose a database to host a given mailbox it could easily lead to unbalanced servers and result in poor performance of the Exchange back end.

Fortunately Exchange Server 2010 makes this a lot simpler thanks to several improvements and new features.

Database Performance Improvements

An immediate improvement in Exchange 2010 is the database performance, when viewed in the context of disk IOPS (Inputs/Outputs per Second) required to perform certain operations.  Simply put, a given operation in Exchange 2010 (let’s say a user sorting their 10,000 item inbox by name instead of date) generates far less read/write load on the disks that store that mailbox database.

The benefit of this is an increase in the potential mailbox density per database.  You can fit more mailboxes into a single database, and that database can be much bigger than in previous versions of Exchange (up to 2 terabytes instead of prior recommended maximums of 100 gigabytes).

Fewer databases leaves fewer choices for Help Desk administrators when creating new mailboxes, which is a good thing.

Mailbox Load Balancing

A new feature of Exchange Server 2010 is the mailbox provisioning load balancer.  This acts as an automatic distributor of new mailboxes between mailbox databases in the organization. Continue reading Exchange Server 2010 Simplifies Mailbox Database Design

The Register published an article describing the removal of Single Instance Storage (SIS) from the Exchange Server 2010 database engine.  The comments on the article were largely critical of the change, declaring it a backward step in Exchange storage efficiency.

Before I discuss this further it helps to go back in time a little and understand what SIS is and how it came to be a part of Exchange Server.

Exchange Server Single Instance Storage

The essence of SIS is the storage of a single copy of data that is shared among different users or computers.  In the case of Exchange Server this meant a single copy of an email or file attachment is kept in the mailbox database, and then any user who received that item accesses it via a pointer to that one single instance of the item.

SIS was introduced in the Exchange Server product line in version 4.0 back in 1996.  Back then disk storage was very expensive compared to today’s prices.  Disks were much larger in physical size, smaller in capacity, and slower in performance.  Under those conditions SIS made a lot of sense to reduce the overall size of mailbox databases.

SIS remained a part of the Exchange database engine right up to Exchange Server 2007.  However in this time the price of disk storage has greatly reduced.  The database engine itself had also been improved and between Exchange Server 2003 and 2007 saw as much as a 70% decrease in IOPS (Inputs/Outputs per Second) requirements, meaning more users and larger databases could be stored on fewer disks. Continue reading Does the Removal of Single Instance Storage Mean Less Efficient Exchange Servers?

Free ebook is good primer on Exchange Server 2010.

Thinking of moving to Exchange 2010? You might want to take a look at a free electronic volume recently released by Red Gate Books.

The 188-page PDF book, Exchange 2010–A Practical Approach, is written by Jaap Wesselius, a senior Exchange consultant with DM Consultants, based in Amsterdam.

The most important change in the new version of Exchange Server, according to Wesselius, is the Database Availability Group.

“This will allow you to create multiple copies of an Exchange Server database within your organization, and you are no longer bound to a specific site (like in Exchange Server 2007), but can now stretch across multiple sites,” he writes.

Another change cited by the consultant is the creation of a new Continuous Availability technology to replace Cluster Continuous Replication and Stand-by Continuous Replication.

Some system administrators will welcome another difference highlighted by Wesselius. Windows Server fall-over clustering has been scrapped in the final release of Exchange 2010 and its components are now managed through the Exchange Management Console or Exchange Management Shell.

Continue reading Free ebook on Exchange 10 released

In my recent post I examined the question of whether Exchange Server 2010’s new replication and retention features could mean an organization no longer needed to back up their Exchange servers.

One reader emailed me to suggest that avoiding backups would be unwise, citing the example of potential corruption within the database that might replicate to all copies within the Database Availability Group and cause loss of data.

The scenario is one that definitely needs to be considered.  Although Exchange Server 2010 includes application intelligence to detect and handle some database corruption scenarios, there still exists the possibility of logical corruption leading to data loss.

Fortunately the solution to this problem is already included in the DAG feature of Exchange Server 2010.

If you are already familiar with Exchange Server 2007 Standby Continuous Replication then you already understand the concept of replay lag time.  Replay lag time is a configurable setting on each database copy within a DAG that delays the replay of a transaction log into that database replica.  A database copy with a replay lag time of more than zero is referred to as a lagged copy.

For example, within a DAG there may be 3 servers hosting replicas of Database 1.  Two of the servers are located in a primary data center, and the third server is located at a secondary data center.

The servers at the primary data center are configured with a replay lag time of zero, meaning the passive copy of the database is kept up to date with the latest transaction log information in near real-time.  A failure of one server permits seamless failover to the second server and continued email operation for the business. Continue reading What if You Never Backed Up Your Exchange Server Again? (Part 2)

Imagine for a moment that you never had to back up your Exchange servers again.  Sounds crazy right?  Well with Exchange Server 2010, it may not be as crazy as you think.

In a recent post I described the killer new High Availability feature of Exchange Server 2010 – the Database Availability Group (or DAG for short).

A DAG is an Organization-level object that allows a database to have several passive replicas on other servers (DAG members).  When a DAG is configured it permits individual mailbox databases to failover to passive instances should any problem with the active database arise.

The nature of DAGs means that they can be deployed to protect from failures at almost any layer of the Exchange infrastructure.  DAGs can protect from anything from a single failed server hard disk to an entire data center failure as long as the DAG is architected accordingly.

How this relates to backups is simply this – if a database is protected from all failure scenarios by the DAG, why would you need to back it up at all?  Let’s take a closer look at this question. Continue reading What if You Never Backed Up Your Exchange Server Again?