Planning related platform components

In many organizations, Exchange Server 2013 is not the only product that is deployed as part of a greater unified communications and collaborations strategy. Although Microsoft offers a wide range of technologies and products that, together, can fill this need, companies often use other applications.

Describing and understanding these components is another important aspect of your architecture preparation.

How to do it...

First, it's a good idea to start an inventory of what other products and components are tying into your messaging infrastructure. As described earlier, this could go as far as looking at the different networking devices to multi-functional devices e-mailing unauthenticated over SMTP.

Once you have described the different components that are at stake, you should go over each of them and identify the specifics. This means that you will need to review the current configuration and compare that to what's required and what's supported. If there is a gap between what you have today and where you need to be in the future (when deploying Exchange 2013); you need to plan for these changes as well.

In the sections that follow, you'll find some general guidelines around the most common areas of interest which you can use as a reference when looking at each of these components in your deployment.

Firewall and/or reverse proxy

Even though you have a firewall between your Exchange servers internally, they're still required to shield your on-premises environment from the rest of the world. Any firewall these days should be capable of handling Exchange Server traffic. Firewalls, or other networking devices for that matter, can sometimes be challenging. Not because they can become very complex, but because the management of these devices is usually out of the hands of the Exchange admin. Also, unfortunately, the security that manages these devices often has no clue about the Exchange Server design principles or how it interacts with and uses these devices.

In short, all Exchange Server roles should be installed on domain member servers in the LAN, except for the Edge Server role, which needs to be installed in your perimeter network (sometimes also referred to as DMZ).

For securing communications from the outside like Outlook Web App authentication and access, an organization might require the use of a reverse proxy. Have a look at Chapter 5, Configuring External Access for more information on the sense or non-sense of using a reverse proxy.

SMTP gateway/Anti-Spam/Malware/Virus appliance

An SMTP gateway is a usually a separate server or appliance placed LAN or perimeter network (DMZ) and is responsible for transporting e-mail inside and outside of the Exchange Server environment. These last few years, several cloud-based solutions—essentially providing the same functionality—have become more and more popular. So, don't be surprised to find out that this gateway is really a service on the Internet. Even though some gateways can perform additional actions, such as address rewriting or journaling, they are mostly used for their security features, such as anti-spam, anti-malware, and anti-virus.

Ever since Exchange 2007, traffic within the Exchange organization is sent after being encrypted by Transport Layer Security (TLS). By default, if your Exchange Server sends e-mail directly onto the internet, it will always try to use TLS. However, if there's an appliance between your internal and external organization, TLS could break. If you want to make sure TLS encryption is used end-to-end, you need to verify that your gateway supports using it. Alternatively, you could replace the gateway with an Exchange Edge Transport server.

Telephony system or Microsoft Lync Server for voice or unified messaging integration

Since Exchange Server 2007, Microsoft developed the Unified Messaging Server Role in Exchange, which allows for routing and storage of voice messages in your mailbox. Although the separate Unified Messaging Server role as such doesn't exist anymore in Exchange Server 2013, its functionality is largely similar to the unified messaging features from Exchange Server 2010.

Nowadays, IT and telephony systems management is often handled by different teams, which makes communication integration a very difficult thing to achieve sometimes. By integrating voice into your Exchange mailbox, an end user can listen to missed call voice messages, replay voice messages from his mailbox, have voice messages translated to e-mail text in their local language, and so on.

The unified messaging service in Exchange Server 2013 allows for the following:

• Voice mail configuration and integration with existing PBX or Microsoft Lync Server

• Outlook Voice Access (Go through your mailbox by sending voice commands)

• Call answering and call answering rules

• Integration with Microsoft Lync, based on Exchange Autodiscover protocol mechanism

• Play voice messages to another fixed or mobile phone

SharePoint

There was a time when Microsoft actively positioned SharePoint as a replacement of Public Folders. Now, with the new Public Folder architecture, we're not sure if that is still true. However, many companies have adopted SharePoint over the past years and Microsoft continues to improve the functionalities offered by SharePoint and by the integration with other products.

One example of an improved integration between SharePoint and Exchange is Site Mailboxes. Site Mailboxes allow for true collaboration between SharePoint and Exchange, all from within the same client (Outlook). By dragging and dropping e-mails with attachments into a Site Mailbox, the attachment gets stored in SharePoint while the message stays in Exchange.

But as for many good things in life, there's a drawback. To take advantage of Site Mailboxes, you will not only have to deploy Exchange 2013, you'll also need SharePoint 2013.

Faxing solution

The end of Fax has been announced several times before, however up until this very day companies still use and sometimes even rely on sending and receiving faxes to run their business. Exchange 2013 is capable of supporting faxes, but doesn't do a very good job at it. As a matter of fact, for sending and receiving faxes, you will need to use a third-party solution.

There are some pretty good faxing solutions out there. Some are easier to handle than others. Specifically, in the context of Exchange Server 2013 migrations, it is necessary to validate if your faxing application supports Exchange 2013. Maybe there is a new version available, that you need to deploy first. We have seen cases where the faxing solution that was being used didn't exist anymore; the maker decided to stop developing, or even supporting it. If that happens, there aren't many alternatives…. You could move to another product, keep a legacy Exchange server in place for interoperability, or move to a hosted faxing solution. The latter option has gained popularity over the past years, given its flexibility and ease of implementation. It usually only takes setting up a separate namespace for faxes; all the rest happens over SMTP.

Backup and restore

• After going through some high availability, site resilience, and load balancing concepts of Exchange Server 2013 architecture, one might think that taking regular backups is not required anymore. However, even the most redundant, highly available Exchange platform isn't a 100 percent proof against whatever failure that might occur. Therefore, even in Exchange Server 2013, taking backups is necessary.

• Just as with previous Exchange Server editions, Exchange Server 2013 only supports Exchange-aware, Volume Shadow Services (VSS) based backups. Both Microsoft Windows Server backup and Data Protection Manager have support for VSS-based backups, amongst many other backup solution vendors in the market.

• More information on Exchange 2013 backup and restore is detailed in Chapter 9, Performing Backup, Restore, and Disaster Recovery.

Custom developed and other third-party applications

Over the years, many companies bought or developed their own applications on top of Exchange. Depending on which version you are currently running, some of these applications might still use deprecated features. The one that natively comes to mind is WebDAV. Support for WebDAV has already been dropped in Exchange 2010 and is not coming back.

If you are still running Exchange 2003 or Exchange 2007 and have an application that uses WebDAV, you will need to take into account that this application probably needs to be replaced or rewritten. Ideally, you change the application to use one of the two alternatives: Exchange Web Services or the new Outlook Apps model.

Software-based anti-virus

In previous versions of Exchange, anti-virus vendors could be integrated directly with the store process and Exchange databases through the Virus Scanning Application Interface (VSAPI). This allowed anti-virus programs to perform on-access scans or perform periodical scans of an entire database. Unfortunately, a lot of support calls Microsoft received were due to failing or poorly written code, which could lead to a crashing store process or a corrupted database; ultimately leading to possible data loss.

As a result—and probably for a bunch of other reasons as well—Microsoft decided to pull the plug from the VS API. This means that any anti-virus product still using the API will not work in Exchange 2013. These products will have to be rewritten to either use Exchange Web Services, or shift to scanning for threats as part of the transport pipeline which is still fully supported.

There's more...

To fully understand what the impact of the changes in Exchange 2013 on your environment could be, have a look at the following list of items and features that have been discontinued or aren't available just yet in Exchange 2013. The list is available at the following website:

http://technet.microsoft.com/en-us/library/jj619283(v=exchg.150).aspx