Manage Learn to apply best practices and optimize your operations.

How to secure Exchange Server 2010 post deployment

So you’ve deployed Exchange 2010, but are you confident in its security? If you’re unsure, make certain you’ve checked off these seven items.

Many admins agree that it’s fairly simple to install Exchange Server 2010. However, the installation wizard doesn’t...

walk you through the tasks required to achieve a secure Exchange Server deployment. But you can use the following seven steps as a post-deployment checklist to ensure the security of Exchange Server 2010.

1. Install antivirus software for Exchange 2010

The first thing you should do after deploying Exchange Server 2010 is to make sure you have Exchange-aware antivirus software on each server. Microsoft recommends using Forefront Protection 2010 for Exchange Server but feel free to use any Exchange 2010-aware antivirus product.

2. Deploy a certificate to your Exchange 2010 client access server

Another key security precaution involves deploying an SSL certificate to your client access server (CAS). The CAS is configured to use a self-signed certificate by default. However, self-signed certificates are usually considered inadequate because they are issued by the Exchange server itself and not a trusted certificate authority (CA). Therefore, the certificate’s issuer cannot be verified in the same way it would be if you were using a commercial certificate.

3. Take steps to control spam in Exchange 2010

Ideally, your Exchange organization should be equipped with an edge transport server. The edge transport server is deployed in the perimeter network to control spam while hiding the back-end Exchange organization from the Internet.

That said, although Microsoft highly recommends using an edge transport server, it is often cost-prohibitive for smaller organizations. If you’re not using an edge transport server you must control spam at the hub transport level. One option is to install Exchange’s native antispam agents. To do so, open an Exchange Management Shell (EMS) session and enter the following commands:

Restart-Service MSExchangeTransport

Of course you also have the option to deploy a third-party antispam product.

4. Enable RPC encryption in Exchange 2010

When Microsoft created Exchange Server 2010, one of its main goals was to make the product inherently secure by default. Microsoft implemented a number of security mechanisms, one of which was to automatically use RPC encryption for MAPI connections.

Both Outlook 2007 and Outlook 2010 support RPC encryption, but Outlook 2003 does not. Previously, to make Outlook 2003 work correctly with Exchange 2010, you had to disable RPC encryption through a group policy setting.

The lack of support for RPC encryption in Outlook 2003 must have generated too many support calls, because Microsoft disabled RPC encryption in Exchange Server 2010 SP1. If you want your MAPI sessions encrypted, you must enable RPC encryption manually.

To do so, open the EMS and enter the following command:

Get-RPCClientAccess | Set-RPCClientAccess –EncryptionRequired $True\

Verify that the setting has taken effect using this command:

Get-RPCClientAccess | FL Server, *Version, EncryptionRequired

5. Deploy Information Rights Management in Exchange 2010

It’s easy to think of Exchange Server security as the process of hardening your Exchange servers against attack. While this is certainly part of the process, the ultimate goal is to prevent the tampering or unauthorized disclosure of email messages.

One of the best ways to protect Exchange mail is to enable Information Rights Management (IRM). IRM lets you or your users control what message recipients can do with messages they receive from your organization. For example, you can prevent users from forwarding, modifying, printing, or copying and pasting email messages. You can also use IRM to protect supported file attachments.

6. Configure ActiveSync mailbox policies in Exchange 2010

If you plan on supporting mobile devices in your Exchange Server organization, ActiveSync mailbox policies are essential. You can use them to ensure that mobile devices adhere to your company’s security standards. For example, you can use ActiveSync mailbox policies to enforce password policies, enable or disable specific device hardware and to control whether or not attachments may be downloaded to mobile devices.

One setting that deserves special attention is the Allow Non-Provisionable Devices setting. If you select this option, you allow mobile devices to synchronize with Exchange even if those devices do not support all your ActiveSync Mailbox Policy settings.

It might seem like you should never allow non-provisionable devices, but it’s worth noting that the only mobile devices Microsoft considers fully provisionable are those running Windows Mobile 6.x; even Windows Phone 7 devices are not considered fully provisionable.

7. Run the Exchange Best Practices Analyzer

After you’ve finished securing Exchange 2010, run the Microsoft Exchange Best Practices Analyzer (ExBPA). It will help verify that your Exchange deployment adheres to Microsoft’s best practices as well as alert you to certain security settings that still need to be implemented or adjusted.

Brien Posey
is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.