Tools Exchange Server 2013 Lead image: © Alessandro Russo, 123RF.com
© Alessandro Russo, 123RF.com
 

Changes in Exchange Server 2013

New Clothes

Exchange Server 2013 sees Microsoft complete the latest version of its groupware solution. In this article, we introduce new features in the server and reveal which features have been eliminated. By Thomas Joos

During the installation of Exchange Server 2013 [1], you will notice that the new server offers far fewer options. Microsoft has dumped the Hub Transport and Unified Messaging server roles. The functions of these two roles are handled by the Mailbox server and the Client Access server in the new version.

Email transport in Exchange Server 2013 is handled by three services: the Front End Transport Service (FET), the Hub Transport Service (HT), and the Mailbox Transport Service (MT), which now belong to the Mailbox server role. The transport services are also responsible for implementing the improved transport rules (Figure 1). The latter go by the name of Data Loss Prevention (DLP) and are designed to prevent sensitive data from leaving the corporate network. Also, Exchange Server 2013 integrates an antivirus scanner. The servers scan all incoming and outgoing email for viruses. Companies that rely on third-party antivirus scanners can disable this feature, of course.

The new transport rules help harden Exchange Server 2013.
Figure 1: The new transport rules help harden Exchange Server 2013.

Although Exchange Server 2013 can generally be installed in existing organizations with Exchange Server 2007/2010, you will need SP3 for Exchange Server 2010 and a hot fix for Exchange Server 2007. Older versions such as Exchange Server 2000/2003 cannot be run with Exchange Server 2012.

Public folder databases no longer exist in the familiar form in Exchange Server 2013, but, of course, public folders are still available. Shared content is now published via special mailboxes, which are in turn secured by database availability groups (DAGs) to improve availability. These groups are still available in the new version. Public folders are thus mapped in Exchange Server 2013 to a mailbox in the mailbox database. To use public folders, create a mailbox for public folders and then put the public folders in this mailbox.

Exchange Admin Center

Management of the Exchange infrastructure is increasingly taking place in advanced and web-based Exchange Admin Centers (EACs). There is still the Exchange Management Shell, which is now based on PowerShell 3.0. The Exchange Management Console no longer exists in Exchange Server 2013. After installation, the EAC is accessible on https://<Servername>/ecp (Figure 2). You also have the option of connecting Office 365 to this console. In the new version, communication of Outlook and Exchange uses HTTP(S); MAPI is no longer used. For this reason, only Outlook 2007/2010 and 2013 can connect to Exchange Server 2013. Older versions (e.g., Outlook 2000/2003) are no longer supported.

Management of Exchange Server 2013 is web based.
Figure 2: Management of Exchange Server 2013 is web based.

DAGs already exist in Exchange Server 2010. They required Windows Server 2008/2008 R2 Enterprise/Datacenter as the operating system. Because the Standard/Datacenter editions are identical in Windows Server 2012, and there is no Enterprise edition, DAGs can also be used with Windows Server 2012 Standard edition. DAGs are also part of the of Exchange Server 2013 Standard edition.

Microsoft has also improved the process of moving mailboxes to Exchange Server 2013. You can move more mailboxes at the same time and also move email notifications. In case of problems, you can re-run the wizard, and mailboxes can be prioritized. You also have the option of keeping access locked after the move until you have reviewed the results.

Installing Exchange Server 2013

To install Exchange Server 2013, you will need the following items on the server:

You need to install these preconditions manually, but you can leave everything else to the Exchange Installation Wizard.

The new version is only available as a 64-bit system. Although the domain must be based on domain controllers, which can run 32-bit versions of Windows Server 2003, Microsoft recommends also installing the domain controllers as 64-bit systems. Microsoft recommends at least 8GB free memory for mailbox servers and at least 4GB for Client Access servers. You cannot install Exchange on a Core server; you need a full installation of Windows Server 2008 R2 or preferably Windows Server 2012. You can also install the Exchange Server 2013 management tools on workstations with Windows 7/8.

Before installing Exchange Server 2013, it makes sense to install the Remote Server Administration Tools for Active Directory on the Exchange server via Server Manager. Then, launch the Active Directory Schema snap-in and open a connection to schema master by pressing the right mouse button. Like each new Exchange version, Exchange Server 2013 also extends the schema.

For a clean installation of Exchange Server 2013, enter the command:

setup /prepareAd /IAcceptExchangeServerLicenseTerms/OrganizationName: <organization name>

so that the wizard can extend the Active Directory schema. Besides schema extensions, these commands create a new OU with the appropriate security groups. The command setup /PrepareAllDomains prepares all domains in the forest for Exchange.

You should preferably perform the schema extensions directly on the schema master. To find out which machine this is, type:

dsquery server -hasfsmo schema

In some cases, a schema extension error with the number 8224 appears  – this is especially true of virtual servers. The problem is due to TCP Chimney Offload and Receive-Side Scaling because the functions here are computed for the CPU, not the network card. You can resolve the problem by disabling the two functions; you can do this at the command line with the following commands:

netsh int tcp set global rss=disabled
netsh int tcp set global chimney=disabled

The command netsh int tcp show global shows you the status.

Configuring Email Delivery and Reception

Reception and delivery of email is composed of different areas. After the install, you initially cannot receive and send email with Exchange Server. You first need to configure some settings in the Exchange Admin Center. Note that Microsoft has revised the nested structure of the old Exchange Management Console and integrated the necessary commands in a common area: By default Email Reception – Exchange initially only accepts email for domains defined in the mail flow | accepted domains feature (Figure 3).

You can manage the email flow centrally in the Exchange Management Console Message Flow feature.
Figure 3: You can manage the email flow centrally in the Exchange Management Console Message Flow feature.

For an Exchange Server to be able to accept email, you must create a Receive Connector and configure it to accept email from sending servers. You will find Receive Connectors in mail flow | receive connectors. By default, Exchange sets up some connectors.

For Exchange Server to be able to deliver email internally, the email address must exist in the Email attribute for the organization. To discover which email addresses the server distributes to the users, go to the email address policies tab in the mail flow section. You can create mailboxes for users via the recipient | mailboxes feature. At this point, you can also set up new user accounts in Active Directory.

For Exchange to be able to send email externally, you must at least create a Send Connector. You will find this configuration in the mail flow section send connectors tab. After the installation, you still do not have a Send Connector.

SMTPDiag is an important diagnostic tool for mail flow that you can download from the Microsoft website [5] free of charge. With this tool, you can diagnose problems with SMTP delivery at the command line and thus test the Send Connectors on the server. The installation files for SMTPDiag contain a detailed Word document that explains its use.

The tool checks whether an email can be delivered via SMTP. The command form is:

smtpdiag <sender address> <target address>

The tool then verifies that the server can deliver the mail via DNS resolution and gives you detailed reports in case of problems. You can see from the output whether the server accepts connections and then specifically troubleshoot the appropriate servers.

You can test the connection between your Exchange organization and the Internet via the Microsoft site [6]. The tool is used to test connections for Outlook, smartphones, or Office 365. After selecting the desired test, enter the data for the Exchange Server you want to test and the user data with which you will be opening the connection. The tool then tests the connection and indicates whether the configuration works (Figure 4).

Microsoft helps you diagnose connections.
Figure 4: Microsoft helps you diagnose connections.

Exchange Server 2013 and Sharepoint Server 2013

Companies that use Sharepoint 2013 can use Sharepoint for improved browsing of mailboxes and public folders in Exchange Server 2013. The new Exchange Server uses a completely new search interface to do this. Email messages that users in Sharepoint 2013 find on servers with Exchange Server 2013 can be exported to PST files. Exchange will also integrate with Fast Search Server. The new Exchange version can also connect to domains based on Windows Server 2003; you do not necessarily need Windows Server 2012. Although you can install Exchange Server 2013 on domain controllers, Microsoft does not recommend doing so. After installing Exchange, you cannot, however, promote the server to a domain controller or demote a domain controller once Exchange is in place.

Microsoft has also released Exchange Server 2013 for virtualization [7], which is ideally suited to Hyper-V in Windows Server 2012, but Windows Server 2008 R2 is also supported.

Has-Beens

Outlook 2003 and associated connectors are no longer available in Exchange Server 2013. These can, therefore, no longer be used. If Exchange finds this kind of connection, it sends all email received via a specific Receive Connector to the linked connector, regardless of the other rules. A connection like this always has priority. The connection is handled by the Exchange Management Shell. For linked connectors, other connectors and rules are always disabled. Therefore, before using Exchange Server 2012, you must remove these connectors.

Also, managed folders are no longer available. Their functions are now integrated into the retention policies. If you enable anti-spam filters on mailbox servers, you can only manage them in the Exchange Management Shell. The Hub Transport and Unified Messaging server roles are no longer available. These functions are handled by the Mailbox server and Client Access server. The MMC-based management console is a thing of the past. Management now either takes place via the Exchange Management Shell or the web-based administration console instead.

Microsoft has greatly simplified management of databases, connected smartphones and tablets, and quotas for mailboxes with fewer menus and no nested structures. The new Exchange version no longer supports access to shared mailboxes of other users, moderation of distribution lists, S/MIME, and modifications to the reading pane in the Outlook Web App. Additionally, Microsoft has removed many tools such as the Best Practices Analyzer. The tools only support Exchange Server 2010. Besides the Analyzer, Microsoft has also done away with the Log Viewer and other applications from the toolbox.

Outlook Web App

Microsoft has revamped the Outlook Web App interface for users. It is now oriented on Outlook 2013. Once synchronized, users can work offline with Outlook Web App 2013. Also new is the integration of apps for Outlook Web App (OWA). It lets users extend the interface to include new features. OWA 2013 works best with Firefox as of version 14, Chrome as of Version 18, and Internet Explorer as of Version 10. Microsoft has also optimized the new interface for touch operation (Figure 5). The calendar and contacts views are also improved.

Microsoft has adapted the Outlook Web App to reflect current design strategy.
Figure 5: Microsoft has adapted the Outlook Web App to reflect current design strategy.

Modifying Exchange Certificates

Exchange Server 2013, like its predecessors, relies on SSL-secured connections and encryption. For this reason, each Exchange Server requires its own server certificate. During the installation, each Exchange Server issues a self-signed certificate. The problem with this approach is that no client trusts this CA, which leads to certificate error messages. A solution to the problem is either to rely on an internal certification authority on the basis of the Active Directory Certificate Services or to use a third-party certificate. Clients that are members of the same Active Directory forest automatically trust internal certification authorities. If you use a third-party certification authority, you must manually add the CA certificate to your Trusted Root Certification Authorities if it is not yet known.

In Exchange Server 2013, you can manage server certificates directly in the web-based Exchange Admin Center. To assign a certificate to the server, click on servers in the Exchange Admin Center and then press certificates. Each Exchange Server in the organization needs its own certificate. To install a new certificate, first click on the plus sign. The wizard creates a certificate request, which you either request via the Active Directory Certificate Services or via the third party's web front end.

In the first step of the wizard, type in the display name for the certificate in the console. On the next page, you can specify that you also want to connect child domains with the same certificate. Then, select the server on which you want to save the certificate request (Figure 6).

Using SSL certificates to harden Exchange.
Figure 6: Using SSL certificates to harden Exchange.

In the wizard, enter the name of the domain via which the server will be accessed externally or internally. The wizard then shows you which domains are listed for access in the certificate. Note that the name with which you access the server from the Internet is stored as the common name. Otherwise, clients accessing the server from the Internet see an error message because the name of the certificate does not match the URL for access. This point is especially important for using Outlook Anywhere. If you see a certificate error in Outlook Web App, you can confirm this without any effect, but Outlook refuses to connect with this type of error. On the next page, enter the data for the certificate and your organization and then save the request as a text file. You can then use this file to request the certificate.

In the next step, open the web front end for the certificate issuer. If you are working with the Active Directory Certificate Services, you can access it on https://<servername>/certsrv. Next, select the option Submit a certificate request using a base64-encoded CMC or PKCS #10 file or a renewal request using a base64-encoded PKCS #7 file.

In the next window, enter the complete text of the *.req file that you created in the Saved Request field. To do this, open the file in Notepad and copy the complete text to the clipboard by pressing Ctrl+A then Ctrl+C; then, use Ctrl+V to paste it into the field. Select Web Server as the Certificate Template and then press Submit.

Next, download the certificate as a *.cer file and save it on the server. Then, go back to the Exchange Admin Center and click on servers | certificates. Click on the certificate in the console and then press Finish. At this point, you can enter the path to the *.cer file, and complete the operation. The certificate should now appear as Valid.

For this to happen, the certification authority from which the certificate comes must be listed in the Trusted Root Certification Authorities on the Exchange Server. If you work with the Active Directory Certificate Services, the Exchange server installs the certificate for the trust relationship automatically via Group Policy. The root CA certificate must be deposited on the Exchange Server, so that the Exchange server will trust this CA certificate.

Conclusions

Exchange Server 2013 has many new features that are not just upgrades from Exchange Server 2007/2010. Microsoft has not managed to include long-awaited changes, such as the integration of databases in SQL Server. Management is somewhat easier, however, if the web interface is not quite as convenient as the legacy, proven Exchange Management Console. Integration of antivirus protection is nice, although any company that uses Exchange today already has a mailbox scanner. The new transport rules are, above all, a security feature.

Office 365 can connect to Exchange Server 2010 just as easily as to Exchange Server 2013. From my point of view, the changes do not justify upgrading from Exchange Server 2007/2010. Only companies migrating from some other system to Exchange should use the new version. Exchange 2013 is a little faster in comparison; it optimally supports Windows Server 2012 and cooperates better with Sharepoint, but do not expect revolutionary changes.