Before moving over to the "real stuff", where we walk you through the installation of Exchange Server 2013, we will dedicate this chapter to planning, which might make it the least technical chapter in this book. Considering the fact that Exchange is not only an e-mail system but often the cornerstone for all other unified communication applications in a company, detailed planning is a very important aspect of an Exchange Server 2013 implementation project.
In this chapter, we will cover:
Gathering the business requirements
Sizing Exchange 2013
Preparing for Exchange 2013
Designing storage for Exchange
Understanding Active Directory and DNS dependencies
Planning related platform components
When thinking and talking about the design phase elements that come into play in an Exchange 2013 project, people immediately refer to features, such as Outlook Web App, anti-spam, backup, mobile device synchronization. However, other important aspects of the design phase thinking about topics like availability, supportability, and interoperability with third party applications.
Without going into too much detail here, we can safely state that Exchange 2013 has been built with high availability in mind. Although this was probably the case for Exchange 2007 and 2010 too, a lot of the features that safeguard availability have either been updated or completely overhauled to drive this goal. Features and enhancements, such as the new database design, continued usage of the Database Availability Group (DAG), PowerShell, and the new Exchange Admin Center (EAC), to name just a few, are living proof of that. Then there's also the addition of Managed Availability which is designed to take action when things go wrong. All these features are designed to keep the Exchange services up and running as much as possible. To quote Microsoft "things break, but the (end user) experience does not".
Although it might seem a bit odd at first, we'd like to include the new management paradigm of Exchange 2013 as part of the planning phase. The new features in PowerShell v3, but mostly the new EAC, drive a change in how Exchange 2013 can be managed. The shift from the traditional console-based administration to a more web-based management will also require rethinking on how your company can or should deal with this. It definitely opens up a whole new world of opportunities!
Once you have an idea about how your future Exchange Server topology should look like, you can start investigating the system requirements from both a hardware and software perspective. Virtualization is also an option here.
If you are already familiar with Exchange Server 2007 or 2010, transitioning your platform to the latest Exchange Server 2013 should not be that complex after all, except for maybe migrating public folders which can be a bit challenging.
As is the case with every Exchange Server version before, Exchange 2013 also requires an Active Directory Schema upgrade. Although this action is far less scary than what it used to be, a lot of companies still require some time to plan and implement these changes.
Besides the Exchange Server installation itself, other components you should integrate in your planning phase are your networking devices including the firewall, reverse proxy, SMTP gateways, and maybe load balancers. Also now is a good time to take a look at your backup infrastructure and anti-malware solutions.
Lastly, another important aspect of your planning phase will be to decide between an on-premises Exchange 2013 infrastructure, Exchange Online in Office 365, or maybe even a hybrid scenario.
As described in the introduction, there are different things that come into play when designing an Exchange 2013 Infrastructure. This topic will guide you through the process of gathering different business requirements that should help you design and plan for Exchange 2013.
To complete the following steps, you need to identify the different stake holders in your organization. They will be able to help you get the right information you need to get going with your design.
Before diving into the technicalities, let's stop for a moment and have a look at how you can help your company define the business requirements. Part of this process, but focused mainly on how to design for (high) availability, is also described in Chapter 6, Implementing and Managing High Availability.
A good point to start is by asking yourself (or the people capable of answering them) the following questions:
How is the system going to be used? That is, what clients will be connecting to the environment?
Do I need to provide external access to my clients? That is, are they required to connect over the internet or should clients only be able to connect from within the corporate network?
Are there any regulatory requirements towards security or data retention?
What does my support organization look like? Is there a team dedicated to Exchange? Is there a helpdesk? Who is responsible for what?
Next, ask yourself if and what issues you are trying to solve. Maybe your company is looking to move to Exchange Server 2013 to solve a specific business problem? If so, start by outlining how you could solve that problem without going into too much detail. The idea is that you should end up with a list of Exchange features that you need to incorporate into your final design.
Lastly, in order to be able to size the environment properly, you should ask the following questions:
What is the mailbox size limit?
Are other limits defined? For instance, ask for the maximum message size.
You should also gather statistics on the usage of your current system, including the following:
The amount of messages sent per day, per user
The average message size
The total amount of users, including plans for future growth (if any)
Tip
In some cases you'll find that companies don't really enforce a mailbox size or other size limits. In such cases, it's a good idea to propose a size limit yourself. Trying to design for unlimited mailbox sizes is not only very hard, but it's also a recipe for disaster unless your company is operationally mature enough to deal with it.
Proper sizing information for Exchange 2013 was released only a few months after the release of the product. The lengthy blog post and many formulae that the guidance incorporates clearly shows that sizing Exchange 2013 isn't something to take lightly.
In order to properly size your Exchange 2013 environment, you'll need to know the key usage statistics described in the previous topic. They will serve as the basis for your sizing exercise.
To us, it's trivial to have the key figures representing the current system's usage. Without these figures, sizing for Exchange 2013 will become very hard. In fact, all that you would be doing is guessing what your future design should look like. The result will be that you will either underestimate the requirements or overshoot them. Maybe if you're lucky, you'll be spot on. But to be honest, we haven't seen that happen very often.
In short, it all starts with determining your Mailbox profiles. A mailbox profile is a logical unit to identify a certain load for a specific mailbox. This load is based on the overall size of the mailbox, the number of messages being sent and received on a daily basis, as well as the average size of the mail item itself.
In the many Exchange design exercises we've done since Exchange 5.5—we like to classify them in different categories, named Bronze, Silver, Gold, and Platinum—the Exchange 2013 Server Role Requirements Calculator talks about different "Tiers".
A great tool to help you identify the different mailbox profiles in your existing Exchange (2003, 2007) environment is the Exchange Profile Analyzer, available for download from the following website:
http://www.microsoft.com/en-us/download/details.aspx?id=10559&
Alternatively, Exchange's message tracking logs could help you out as well. You could work some magic with a little help from PowerShell or have a look at the following article by Exchange MVP Paul Cunningham. In this article, he explains how you can get daily message statistics from the Message Tracking Logs using Logs Parser. The article is available at the following website:
http://exchangeserverpro.com/daily-email-traffic-message-tracking-log-parser/
Generating these statistics from the message tracking logs is fairly easy, however in order to get an accurate number, you need access to historical info as well. The more data you have, the better!
Once you have determined the different mailbox profiles, it is time to start making some calculations. Although Microsoft has done an excellent job in explaining how to size Exchange 2013 through the article in the following website, you would probably want to use the Exchange 2013 Server Role Requirements Calculator tool. This tool is an excel-based spreadsheet that will do the calculations for you using the information you put into it.
Nonetheless, we strongly recommend reading Microsoft's article as it will provide you with a better understanding of where some of the numbers come from. Many will try comparing the results from the tool with Exchange 2010 but, honestly, you shouldn't. The architecture between both versions is so different that comparing them would be like comparing apples and oranges.
You can find Microsoft's article describing the entire process in more detail on the following webpage:
Given the great detail of the information from the article, us explaining how to perform them would be waste of paper. However, we did want to give some basic information to get you going with the calculator.
The first sheet, the Input tab, is where you should enter your requirements for your Exchange server deployment. This is the information the tool will use to calculate the sizing requirements. Amongst others things, this information contains the mailbox profile information and architectural information, such as whether you are deploying Exchange in a virtualized environment and/or you are installing multi-role servers. The following screenshot shows the general information the Role Requirements Calculator will ask you for:
By clicking on the red triangle on each field, you will be given more information about what the tool is expecting or referring to. Usually the field's names are descriptive enough and self-explanatory. However, the part with regards to the high availability requirements can sometimes seem a little confusing.
Consider the following scenario:
A company has a total of 10.000 mailboxes, all located in a single site. After a first (manual) draft of our sizing, we've calculated that we will need at least 4 servers to store mailboxes and have room for high availability. Not only should the environment be able to withstand a single database failure, but also an entire datacenter failure. Also, the database copies in the second datacenter should not be used automatically. However, if the business decided to switch over to the second datacenter, it should also be able to withstand a single database failure.
This information teaches us that each datacenter should have at least two database copies, allowing for a single database failure per datacenter. Because the secondary datacenter should not be activated automatically, the databases in that location should be blocked from activation.
Given that all users are located in a single site, we're actually deploying an Active/Passive scenario. In the real world, this could be the case if you have a primary datacenter and also a secondary one that is solely used for disaster recovery purposes. The latter is sometimes also referred to as a DR-site.
Assuming we would deploy physical multi-role servers, the input for the calculator would look something like this screenshot:
Next, you need to provide the tool with information on mailbox profiles including the maximum required mailbox size, amount of messages received per mailbox per day, and the retention requirements. This is shown in the following screenshot:
Tip
As described earlier, you could define different tiers of users which allow you to define different requirements for different types of users.
The rest of the information on the page is pretty self-descriptive and it shouldn't be too hard to enter or select the correct information except maybe for the part about the Log Replication Configuration. This is shown in the following screenshot:
The input from here is used to calculate the bandwidth requirements. In order to do this, the calculator needs to know the amount of logs generated each hour. Without having a live deployment that you could reference to, it's pretty hard to estimate what numbers to enter here.
Luckily, Microsoft has released a tool called the Exchange Client Bandwidth Calculator which operates in a similar way to the Role Requirements Calculator, by entering the details of your clients it will calculate the required bandwidth and predict the usage pattern in 24 hours. To help you with the Role Requirements Calculator, it also contains a table which displays the information you can use to enter in the Log Replication Configuration. This is shown in the following screenshot:
Once you're done entering the information in the Input Sheet, the calculator will automatically generate the results in the other sheets.
The Role Requirements sheet provides you with information on each of the servers, such as the amount of RAM and disk space needed, as well as a calculation of the CPU utilization. If your CPU utilization is too high, you can go back to the Input Sheet and change the CPU information. In such case, you basically have two options, either you buy a CPU that is more powerful or you add more servers to the environment.
This sort of described another widely used approach to sizing Exchange, which is, trial & error. You start by entering information in the Input Sheet, based on what you think the design should look like. Then you go through the other sheets to see if the requirements are feasible. If not, you go back to the input field and change the parameters, such as the amount of servers, disk sizes, or CPU configurations. You keep on doing that until the calculated requirements satisfy your expectations. While this approach might also be effective, we find it to be little efficient. A better approach would be to make the calculations by hand and using the tool to validate and refine them if needed.
The Distribution Sheet contains information on how to layout your database copies throughout your environment. When taking a look at the sheet using the input from earlier, you will see the following screenshot:
Because of the requirement that the second datacenter needs to be able to take on the entire load of primary datacenter and because it should be able to withstand the failure of a single database copy, we actually need to mirror the architecture from the primary datacenter.
Have a look at Chapter 6, Implementing and Managing High Availability for more information how high availability affects the Exchange 2013 design and ultimately also what you need to input into the Role Requirements Calculator.
Once you have decided on the topology and know how many servers you are going to deploy, it's time to prepare the introduction of Exchange 2013.
As part of this task, you will need the required permissions in Active Directory (Enterprise Admin) and for the servers on which you plan to install Exchange (local Admin).
Before installing an Exchange Server 2013 in your network, it would be a good practice to go through some of the key requirements and limitations, avoiding unforeseen surprises during the actual implementation.
Exchange 2013 can only coexist when it's running at least Cumulative Update 1 and only in the following situations.
Coexistence with Exchange 2007 is supported when all the Exchange 2007 servers in the Exchange organization are running Service Pack 3 Update Rollup 10.
Coexistence with Exchange 2010 is supported when all Exchange 2010 servers in the organization are running at least Service Pack 3. Given the availability of Rollup Update 1, going for that is recommended.
Tip
Although you could argue that it's technically possible to coexist, Exchange setup will check that all Exchange 2010 servers in the organization are running at least Service Pack 3. If not, setup will stop and throw a warning. Unfortunately, it does not check the presence of Update Rollup 10 for Exchange 2007. So make absolutely sure that you have deployed it correctly to all your Exchange 2007 servers.
Transitioning from older versions of Exchange Server (2003, 2000, 5.5) is not supported, at least not within the same Exchange organization. If you are still running one of these legacy versions of Exchange, you have to perform a double-hop migration. This means that you have to upgrade your Exchange organization to Exchange 2007 or 2010 first, before you're able to move to Exchange 2013.
Another possibility is to start an Exchange Server 2013 platform from scratch in a new Active Directory forest and use an export/import or cross-forest migration approach to migrate user's mailbox data. Actually, there are only very limited use cases for this approach. Usually this technique is used in situations where multiple AD forests are consolidated into a new one or when a company has decided to create a dedicated resource forest in which Exchange will be installed.
The following table lists the minimum hardware requirements for your Exchange Server 2013 infrastructure. However, keep in mind that you should have defined more specific requirements during the sizing exercise!
For additional information regarding storage in Exchange 2013, have a look at the following Microsoft TechNet website:
http://technet.microsoft.com/en-us/library/ee832792(v=exchg.150).aspx
In this topic, we will discuss both Windows Server edition requirements as well as Exchange Server 2013 editions.
The following table lists the supported Windows Server operating system versions for Exchange Server 2013:
The following table lists the existing Exchange Server 2013 server editions:
|
Exchange Server 2013 edition |
Remarks |
|---|---|
|
Standard Edition |
|
|
Enterprise Edition |
|
Although there is technically no difference between the two versions, some features are only supported in the Enterprise edition. To find out more about what features are supported in each edition, have a look at the following website:
Note
Exchange Server Editions are defined by the product key; there is no technical difference between the Standard or Enterprise edition. Upgrading from trial to Standard or Enterprise is supported. Upgrading from Standard to Enterprise is also supported and it only requires entering a new Exchange Server license key. However, downgrading from Enterprise Edition to Standard Edition is not possible. If you need to do this, you would have to install a new Exchange Server in the same organization enter a Standard Edition license key. Then you will have to move all mailboxes and content, after which you can decommission the Enterprise Edition server.
Planning your Exchange infrastructure is a very important step in the overall process of implementing or migrating. Planning starts by knowing the differences between the Exchange Server 2013 editions. You should also know what edition of Windows you should use to deploy Exchange on. Even though there are shortcuts that can change one Windows edition into another (for example, from Standard to Enterprise), it's not recommended and probably not supported either. So it's important that you get it right from the start.
We already talked about storage environments and how they relate to the new Exchange Server 2013 architecture possibilities.
Due to the optimized and redesigned mailbox store architecture, the Input/Output Operations per Second (IOPS) required for running your Exchange environment decreased dramatically, which lead to possible redesign of your storage infrastructure, or at least consideration of it.
To complete the following steps outlined, make sure to review and understand storage-related terminology. Also, now would be a good time to check whether virtualization is a requirement or an option. Many companies already have some sort of storage solution they want to re-use, but that doesn't necessarily mean it's the best fit for your Exchange environment.
As it is impossible to give you a complete overview of all supported Exchange Server storage vendors, we decided to give you a bullet list of storage considerations in the Exchange Server 2013 context. These guidelines can help you evaluating the right storage solution.
Exchange Server 2013 supports about any type of storage architecture, including Direct Attached Storage (DAS) or Storage Area Network (SAN)—iSCSI or Fiber Channel based.
Only block-level storage is supported. This means that you can use NAS/SAN storage as long as it's either a direct drive mapping or an iSCSI LUN. NFS nor virtual disks stored on an NFS volume, that present block-level storage to Exchange are supported.
All currently existing physical disk types are supported for Exchange Server 2013, ranging from SATA, SAS, and Fiber Channel to SSD disks. Key things to watch out for are disk rotation speed and size. Disks with 5400 RPM are considered too slow in performance, so we don't suggest using these in production environments. Any 7200 RPM or 10,000 RPM disk should score well in both sizing and performance.
Of course, 15,000 RPM disks are also an option. However when it comes to comparing cost versus benefits, they might not be the best fit.
Exchange 2013 supports multiple RAID levels, depending on the usage. They are as follows:
RAID 1/10 are recommended for system partition and log files.
RAID 1/5/10 are recommended for database files volumes.
RAID 1/5/10 are recommended for database log files volumes, although RAID 0 gives better performance, but no redundancy on storage level.
JBOD (disk set without RAID) which is also supported for both database and log files volumes. It should only be considered in a high availability architecture, having three or more database copies!
Exchange 2013 supports databases up to 2 TB. There is no one-size-fits-all approach. Generally though, it's recommended to keep database sizes to a size which your environment can handle. This is mainly a best practice out of backup/restore and RTO perspective. Imagine needing to perform a restore of a 2 TB Exchange database, when you only have it stored on tape….
It is impossible to give you a single answer on how to size and design your Exchange 2013 storage environment. Besides the guidelines we just read, the key on which to base your sizing are IOPS calculations. IOPS is commonly used to reference the performance storage devices, such as hard drives, solid state drives, and SANs.
Microsoft has made tremendous updates to the Exchange database design, resulting in a serious decrease of the required amount of disk IOPS. This is a good thing because disks are growing larger in disk size, but the IOPS they can handle have remained pretty steady over time. So the ideal goal is knowing your Exchange user profile, corresponding IOPS needed, and verifying what IOPS can be delivered by your storage platform.
For each Exchange Server edition since 2003, the Exchange product team provided a Mailbox Server Role Requirements Calculator, which could help with determining the storage requirements so you could match the correct solutions to it. Since the beginning of May 2013 (about 8 months after Exchange 2013 release date though), the calculator for Exchange Server 2013 is (finally) available.
The Exchange 2013 calculator can be downloaded from Microsoft through the following website:
Besides the Microsoft calculator, a lot of storage vendors also provide tools and whitepapers which describe to you best practices, calculated scenarios, and recommended sizing based on their own storage solutions.
To streamline the process of calculating, Microsoft created the Exchange 2010 Solution Reviewed Program (ESRP)—Storage 3.0, which is a toolset of testing parameters (JetStress tests) and documentation guidelines that storage vendors can use for getting their storage solution certified for Exchange Server. This program has recently been upgraded to reflect Exchange 2013 sizing as well.
All information on the ESRP and the different vendor's results can be found at the following website:
The last thing you would want to do is put a storage system into production that doesn't meet the bar when it comes to the amount of IOPS. Storage vendors sometimes try to hide weaknesses or make their solution look better by tweaking some of the numbers or even the results from different tests. Therefore, you should always validate that the solution you chose meets the required amount of IOPS.
A good way to do this is to use the JetStress utility that Microsoft provides. As a matter of fact, running JetStress is also a requirement if you want your storage solution to be fully supported by Microsoft. This doesn't mean they will help you set up the solution, but in case of problems, support might ask for proof that it meets the requirements of your environment.
Because typical JetStress tests can take a while, people often skip them. You shouldn't.
Neil Johnson, a MCS Consultant based in the UK, has created the JetStress field guide for Exchange 2013 which has been released only recently. It is the starting point to understand what JetStress does and how to use it to validate your storage for Exchange 2013.
You can download the guide from the following webpage:
The way JetStress works is that it will simulate the typical load generated by an Exchange server, based on what parameters you provide to it. It will then monitor the transactions and based on that, return a Pass or Fail for configuring along with additional information that can help you understand why it passed or failed.
While running the JetStress tests, it's also a good idea to simulate a failure in your storage system. If you are using a RAID array, you might want to see what the impact of a rebuild would be on the result of JetStress. If you're running JetStress in a virtualized environment, don't wait until off-business hours to run the test, do it during the day to have more reliable results. After all, you will be running Exchange during business hours, won't you?
As mentioned during the introduction, Exchange 2013—like its predecessors—depends heavily on Active Directory (AD) and Domain Name System (DNS). If AD or DNS is not functioning correctly, your Exchange 2013 platform on top of that won't either.
For the following steps and information outlined, we assume you already have an Exchange Server infrastructure in place, meaning you are already using Active Directory (and DNS). Nevertheless, we want to draw your attention to some AD and DNS requirements and changes that are happening as part of your Exchange 2013 platform implementation.
Even if you are not using Exchange in your environment yet, the following items will be of interest to you.
We are not going to explain you how to set up your Active Directory domain controllers from scratch; we assume you already have that running. What's more important is knowing what the different system requirements for your Active Directory infrastructure are; just to be sure it is according to the Exchange 2013 requirements.
Let us start by giving an overview of the supported Operating System versions for each of the necessary AD components. The following information can also be found on TechNet. The following is the website for TechNet:
http://technet.microsoft.com/en-us/library/aa996719(v=exchg.150).aspx
Just as with the Active Directory bits of your environment, having a healthy DNS infrastructure is a vital part in your Exchange Server 2013 platform preparation work. While we could again assume this is already all in place and available, we would like to draw your attention to some DNS specifics and best practices.
One of the most recurring questions when designing Exchange (and Active Directory as well, if you will) infrastructure is, How should I decide on defining my DNS namepace? A short answer to this is, "There is no single best solution for this".
It depends on different parameters. The first question is whether you are using a split-DNS configuration or not? Now what does this mean? In most organizations, the internal Active Directory domain name will differ from the public internet domain name (for example, company.local and company.com). A split-DNS configuration means you will be using the same DNS namespace for your internal network as for your external. Back in the early days, when Active Directory had just come to life, Microsoft used to recommend using a different namespace internally and externally in the Active Directory design guides. Nowadays, it's just the opposite! There are various reasons for this, mainly to simplify the integration between different internal and external resources.
As a side note, we'd like to mention that maintaining a split-DNS setup, requires some additional overhead in the area of managing DNS entries in your DNS namespace. Let's take Outlook Web App as an example. Both URLs (internal and external) could potentially have the same name. Let's say it is set to https://owa.company.com/owa.
In your internal DNS namespace company.com, you will create a hostname entry which refers to the internal IP address(es) of your Client Access Server.
In the external DNS namespace, also company.com, you will create a hostname entry which refers to the public IP address of your firewall.
It has already been mentioned before that Exchange is highly dependent on DNS. Although no changes are required to your DNS infrastructure as such, it might be a good practice to verify that everything runs well before performing the Exchange 2013 installation.
As with a lot of applications and Windows components, your primary source for troubleshooting is the Event Viewer. Although this is also true for DNS, when using Server 2012 the DNS event entries are integrated into the DNS management console itself. In case of major issues with your DNS infrastructure, one might want to activate Debugging logging, which can be achieved as follows:
Open the DNS console on one of your DNS Servers
In the console, select your DNS server
Right-click on Properties and select Debug Logging
Check Log packets for debugging
As this is only to be used for detailed troubleshooting, do not forget to turn the checkbox off again when the issue has been resolved.
Without unwrapping all details of how DNS is operating, the following table will help you in verifying and troubleshooting your DNS name resolution mechanism:
When the Active Directory Server roles and OS versions we just saw have been verified, check your Active Directory replication and DNS replication to make sure it is working correctly as well. Again, Active Directory and DNS are the foundation for your Exchange 2013 installation!
Active Directory replication can be checked using the tool repadmin.exe, which is automatically installed on Server 2008 R2 and 2012 as part of the Remote Server Administration Tools for AD (RSAT-ADDS):
Open a command prompt with elevated rights. To do this, right-click on the command prompt icon and select Run as Administrator. If prompted by User Account Control (UAC), click on Yes.
repadmin /replsummaryThis will give you a summary of the replication status. If no fails/errors are shown, your Active Directory domain controllers are all in sync and replication is working fine, for example:
C:\Users\Administrator > repadmin /replsummary Replication Summary Start Time : 2013-07-06 18:09:26 Beginning Data Collection for replication summary, this may take a while: … Source DSA largest delta fails/total%% error Destination DSA largest delta fails/total%% error C:\Users\Administrator
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
