Installation of Exchange Server 2010 2.

Installation of Exchange Server 2010 2.

Recommended Settings for

Microsoft Exchange Server 2010

AUTHORS:

Martin Pavlis

Microsoft MVP, IT Senior Consultant, KPCS CZ, s.r.o.

Miroslav Knotek

Microsoft MVP, IT Senior Consultant, KPCS CZ, s.r.o.

www.microsoft.cz/exchange/2010

1

Table of Contents

1

2

3

4

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Installation of Exchange Server 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Entering the Product Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Set-up and confi guration of databases for mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

4.1 Set-up of a new database for mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.2 Database

4.3 Transfer of mailboxes between Exchange databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5 Domain names and working with them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

5.1 Accepted domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.2 Automatic settings for SMTP addresses for mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5.3 Manual settings for SMTP addresses for mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

6 Send/receive settings for e-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

6.1 Sending e-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

7

6.2 Receiving e-mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Settings for anti-spam functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

7.1 Terms for use of anti-spam functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7.2 Connection

7.3 Sender

7.4 Recipient

7.5 SenderID fi ltering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.6 Content

7.7 Select tips for optimizing anti-spam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8 Certifi cates and working with them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

9 Confi guration of Client Access Server role services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

9.1 Autodiscover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

9.2 Outlook Web App (OWA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

9.3 Exchange ActiveSync Confi guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

9.4 Outlook Anywhere Confi guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

10 New, select features for Exchange 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

10.1 MailTips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

10.2 Image settings for Exchange mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

10.3 Compatibility settings for Microsoft Offi ce Outlook 2003 clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

10.4 Import/Export data from/to PST fi les . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

10.5 Microsoft Exchange Best Practices Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

10.6 Microsoft Exchange Remote Connectivity Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

11 High availability for Microsoft Exchange Server 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

11.1 Database Availability Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

11.2 Network load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

12 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

1. Introduction

Microsoft Exchange Server 2010 is almost ready for implementation in the production environment immediately after its installation. However, a number of further confi gurational interventions are necessary on the part of the administrator so that the Exchange environment can meet our expectations for a quality mail server that helps increase the productivity of its users. The aim of this article is to describe recommended steps for the basic settings for Exchange Server 2010. The majority of steps described hereafter can successfully be used on any other Exchange installation in any company – i.e. it’s not important how many Exchange servers you have: the recommendations are universal. So in this document there is defi nitely something for the Exchange admin in a small company, as well as for the administrator managing a highly-available environment. For those persons interested in settings for high accessibility the document includes a special section devoted specifi cally to that issue.

2. Installation of Exchange Server 2010

Installation of Exchange Server 2010 is relatively simple and is thus not described in this document. However on the

Microsoft web-page there is a whole range of very powerful tutorials. This is not just a Help section for Exchange as in the past, but also a very high-quality, interactive tool that will guide you step-by-step through the installation of

Exchange in your environment.

Exchange Server Deployment Assistant

»

This is the most modern on-line tool from the Microsoft shop. It generates a „procedure“ based on several questions that you are asked as part of a step-by-step process and thus fulfi ll necessary conditions for installation of Exchange Server 2010 and subsequently also the installation of Exchange.

Link: http://technet.microsoft.com/en-us/exdeploy2010/default.aspx

»

Help Exchange Server 2010, installation section

»

MSTV.cz – video with commentary in the Czech language,„Exchange Server 2010 – Role Installation“

»

Link: http://technet.microsoft.com/en-us/library/dd351084.aspx

Link: http://www.mstv.cz/it/videos/275/Exchange-Server-2010---instalace-roli-a-emulatoru-WM

Introduction

3

3. Entering the Product Key

Following the installation of Exchange Server 2010 the server is still not licensed. This allows for using installations, for example, on provisional/test servers. The trial version runs outs 120 days after the installation date. Such servers always run in the Standard edition and service support from Microsoft cannot be requested in such cases. If you have in your organization’s Exchange servers that do not have Product Keys inserted, a list of all Exchange 2010 servers that are not licensed along with the number of days until the trial version expires will be displayed upon starting the

Exchange Management Console. If the trial period has already expired then a warning for each server of this sort will be displayed.

Figure 1: List of Non-licensed Servers

We insert the Product Key using the following steps:

1.

2.

3.

Exchange Management Console (hereafter EMC): Server Confi guration section

We select the server for which the Product Key has not been entered (it has a different icon)

We launch the wizard for entering the Product Key and type in the license number

Figure 2: Entering the Product Key

After completing the wizard process it will be necessary to restart the Microsoft Exchange Information Store service.

Depending on the Product Key entered, the server edition will either be changed to Standard Edition or to Enterprise

Edition and all necessary settings will be updated.

4

Entering the Product Key

4. Set-up and confi guration of databases for mailboxes

Immediately after installing Exchange Server in the role of Mailbox Server we have at our disposal (on the server) one database for all mailboxes. Whether we also have a database for public folders depends on whether or not we selected support for clients older than Outlook 2007 or not during the installation process. If we did, then the database for Public Folders is essential – older clients need it for their operations. In the Standard Edition we can set up 5 databases for our mailboxes; in the Enterprise Edition up to 100. The databases have no strictly-set size (as they did for Exchange Server 2003 and older editions). We set up databases according to the following rules:

We need to unify many mailboxes with the same settings (i.e. mailbox size) – each database has its own features and these are automatically applied to all mailboxes in the database

Having several databases offers the option of saving them on various disks, thus optimizing capacity and data security

In case a database is damaged, then the whole company doesn’t stop working, just the portion whose mailboxes were in the given database

It is recommended that databases not exceed a certain sensible size given needs for subsequent administration, back-up, etc. It is certainly better to have more, smaller databases than one huge one that it will be problematic to do anything with. For example, take the situation where we would want to restore the database from back-up copies – 50GB can be recalled (restored) quicker and simpler than, say, 500 GB.

There are many different recommendations and it fundamentally holds true that admins for Exchange for the most part work based on their own experience or they are limited by their servers‘ hardware capabilities. If you would like to move forward based on recommendations from Microsoft, I recommend using the following Excel application that will help you with database construction and partitioning.

• Exchange 2010 Mailbox Server Role Requirements Calculator

»

Link: http://msexchangeteam.com/fi les/12/attachments/entry453145.aspx

4.1 Set-up of a new database for mailboxes

We set up a new database for mailboxes using the following steps:

1.

2.

EMC: Organization Confi guration -> Mailbox -> New Mailbox Database

In the wizard we fi ll in the database name (starting with this version the name must be unique to the entire

Exchange organization), the Mailbox server on which the database will be located, location of the database and transaction logs on the disk

Figure 3: Setting up a new database for mailboxes

Set-up and confi guration of databases for mailboxes

5

4.2 Database confi guration for mailboxes

We confi gure databases for mailboxes based on the following steps:

1. EMC: Organization Confi guration -> Mailbox -> we select a database whose settings we wish to defi ne and then

2.

3. we call up its features

On the Maintenance tab we select a time for database maintenance such that the chosen timing is not the same as that for back-up or virus scans

On the Limits tab we set the desired limits for the mailboxes to be located in this database. Additionally, we also provide settings for how long the database will keep deleted items in the Dumpster – from where users can themselves renew them (in the Outlook program this is „Renew deleted items“)

6

Figure 4: Database confi guration for mailboxes

Set-up and confi guration of databases for mailboxes

4.3 Transfer of mailboxes between Exchange databases

After creating the desired database it is possible to freely move user mailboxes between databases and thus optimize their distribution across the entire organization. Since the introduction of Exchange Server 2010 this can be done, thanks to online data transfer, during working hours. The mailbox is available for the entire duration of the transfer.

Once the transfer is complete, the user is asked only to restart the Microsoft Offi ce Outlook application.

1.

2.

3.

EMC: Recipient Confi guration -> Mailbox -> We mark the mailbox that we wish to move and launch the „New

Local Move Request“ wizard

We select the database to which the mailbox is to be transferred and decide whether or not to transfer it, even if it might contain damaged data (stop transfer/move or do not transfer damaged items)

In the section, Recipient Confi guration -> Move Request we can watch the status of transferred mailboxes

Figure 5: Transfer of mailboxes

Set-up and confi guration of databases for mailboxes

7

5. Domain names and working with them

As soon as we have our databases prepared and our mailboxes allocated to them, it is necessary to think about sending and receiving e-mails. Because the Exchange server accepts everything that anyone on the internet attempts to send it (!) via SMTP protocol, it is necessary to limit mail receipt only to the domains that we wish to use in the company.

5.1 Accepted domains

We use the following steps to set domains from which the Exchange Server will accept emails:

1. EMC: Organization Confi guration -> Hub Transport -> Accepted Domains -> launch „New Accepted Domain“

2. wizard

Enter the domain name and choose whether the e-mails will end up on the Exchange server or whether they will be moved to another mail server (internally – internal relay, or externally – external relay)

Figure 6: Accepted domains

We can add as many domains as our company owns (without limitation) – in the case of several domains, e-mails for all of them will be accepted (received).

8

Domain names and working with them

5.2 Automatic settings for SMTP addresses for mailboxes

So that we do not have to manually set an SMTP alias (mail address) for each mailbox, we can automate their creation with the help of address policies applied to mailboxes, which automatically create needed addresses for them. To set addresses that should be apply to our mailboxes, we use the following steps:

1. EMC: Organization Confi guration -> Hub Transport -> E-mail Address Policies -> launch the „New E-mail Address

2.

3.

Policy“ wizard

We select the mailboxes we wish to apply this policy to. We can fi lter mailboxes based on specifi c attributes, organizational unit, or Active Directory domain that the user is located in

Then we choose which addresses we wish to apply to the mailbox. The wizard will help us select the most common type of addresses and domains that we had defi ned earlier in the organization’s Exchange. Several addresses can be applied to the mailbox; however, one is indicated as the primary address – the user can receive mail to all addresses but can only send from the one marked as primary („Set at Reply“)

Domain names and working with them

Figure 7: E-mail Address Policy

9

5.3 Manual settings for SMTP addresses for mailboxes

When managing addresses for mailboxes it can happen that it will be necessary to set-up an address different from the one listed in the address policies – an exception. We create exceptions using the following steps:

1.

2.

EMC: Recipient Confi guration -> Mailbox -> We mark the mailbox, for which we wish to set up a special address and we call up its features

On the „E-mail Addresses“ tab we fi rst, in the lower part, shut off apply centralized policies, and then we add, delete or make any other edits to addresses as desired

Figure 8: Manual entry of e-mail addresses

Don’t forget to add to one mailbox a poster alias for each domain that you own – this address is used in situations, where for example an external subject wishes to inform you that your mail server was put on a black list, etc. This address is thus important and should be monitored.

10

Domain names and working with them

6. Send/receive settings for e-mail

So that we can send and receive e-mail within the organization’s Exchange, it is necessary to implement several settings.

6.1 Sending e-mail

In order to send e-mail it is necessary that one or more connectors (Send Connector) exist in the company. Provided the role, Edge, is installed in the organization’s Exchange, it is not necessary to establish the connectors – this will happen automatically, they only need be confi gured. Provided no Exchange with the Edge role is found in the organization, then it is essential to create this connector manually. We use the following steps to create a connector for sending e-mail:

1. EMC: Organization Confi guration -> Hub Transport -> Send Connectors and here we launch the „New Send

2.

3.

4.

Connector“ wizard

We name the connector, select its defi nitions (Internet) and on another monitor we set the domains to which this connector will send e-mail. Provided we are going to use this connector to send mail to the entire internet, we type a * (star) symbol in the SMTP section.

We confi gure settings for how Exchange will look for the target server (most likely using DNS)

In the fi nal step we choose which Exchange server in our organization will, thanks to this connector, send e-mail to the internet. Should we choose several servers, the one most suitable for sending will be used (the least number of messages sent between servers)

Figure 9: New Send connector

Provided there are several Exchange servers in your organization that can send e-mails, then there can also be several connectors. Their priority is determined by the weight (cost) – the lower the number, the higher the priority.

This way you can achieve a structure, where – when the primary server responsible for sending e-mail is not available

– mail will automatically be sent via another server.

It is always necessary to provide proper settings for connectors once they are created. Otherwise we risk the refusal of e-mails by anti-spam fi lters. We set up our connectors for sending e-mail using the following steps:

1.

2.

EMC: Organization Confi guration -> Hub Transport -> Send Connectors and here we call up their features

On the tab „General“ we turn on SMTP logging (should we be interested in this – I recommend it) and then we enter the name that Exchange will announce when delivering e-mail via this connector, possibly the maximum size of received e-mail

Send/receive settings for e-mail

11

Figure 10: Send connector settings

Entering the right name is key for the proper functioning of sending e-mail. The name listed here must agree with the one that is returned us upon resolution by the DNS PTR record. As an example, I list here the address

88.86.110.159, from which we can see the outgoing SMTP communication. This IP address has a DNS PTR record

„email.exchange4u.cz“ attached to it, i.e. exactly the same name that I have listed for the connector. Should the two names not agree, then a problem arises. This is one that is often assessed by anti-spam tools as a potential problem (threat) and thus mails from your server will then, more often than not, end up in anti-spam quarantines.

A typical example is the situation, where the service name of the connection provider is assigned to the IP address.

Don’t forget that while you can buy a DNS name and it belongs to you, your IP address is always leased from the connection provider. Thus they must, at your request, create a DNS PTR record per your specifi cations.

6.2 Receiving e-mail

In order to properly receive e-mail it is fi rst necessary to create a DNS MX record (entry) in each DNS zone, for which you wish to receive mail. This must be directed to the Exchange that is published – it has an open SMTP connection to the internet. Receive connectors handle receipt of e-mail in Exchange. These are set up on each server. We set up connectors for receiving e-mail using the following steps:

1.

2.

EMC: Server Confi guration -> Hub Transport -> in the upper part we mark/indicate the server that receives mail

(messages) from the internet, and then in the lower part we select the connector features that we wish to set-up/ defi ne

If we don’t have POP/IMAP clients that use SMTP for sending mail, we can delete the „Client XXX“ connector

12

Send/receive settings for e-mail

3.

4.

On the „General“ tab we once again enter the DNS PTR record name, under which the Exchange can be seen from the internet and eventually confi gure settings for communications logging options and for limiting the maximum size of e-mails received

In order to receive messages from the internet it is necessary to turn on „Anonymous Users“ on the „Permission

Groups“ tab

Figure 11: Receive connector settings

Recommended settings for the DNS zone and Exchange Server:

Zone kpcs.cz

kpcs.cz

kpcs.cz

kpcs.cz

Type

A

MX

TXT

SRV

Name

Email

Value

88.86.110.159

email.exchange4u.cz

v=spf1 ip4:88.86.110.159 mx mx:email.exchange4u.cz ~all

1 1 443 email.exchange4u.cz

_autodiscover._tcp.

From the table above you can see that

E-mails are meant to be sent based on an MX record/entry to the SMTP server „email.exchange4u.cz“ address

Anti-spam protection, SenderID, is set up such that e-mails from the „kpcs.cz“ domain can only be sent by the

88.86.110.159 IP address and the server name, email.exchange4u.cz. You can fi nd out more on the link below, where there is a wizard for creating this entry: http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

Clients, who support automatic confi guration using Autodiscover (Outlook 2007 SP1 and higher, Windows Mobile

6.1 and higher) can download needed client confi gurations on the „email.exchange4u.cz“ server

Send/receive settings for e-mail

13

7. Settings for anti-spam functions

Microsoft Exchange Server 2010 contains a wide array of anti-spam functions. Proper settings for these technologies provide organizations of all sizes a very powerful tool for fi ghting against unwanted mail. This in turn is refl ected in the higher work productivity of e-mail users.

7.1 Terms for use of anti-spam functions

Protection against unwanted mail is divided according to means of functioning into individual anti-spam agents.

Each agent has its own unique settings. Each anti-spam agent can also be – regardless of the status of other agents

– turned on or off. Anti-spam agents are automatically installed in the original settings only as part of the optional role, Edge. Should this role be missing in the organization’s Exchange, additional installation of the agents on the server in the Hub Transport role is both possible and supported using the following steps:

1.

2.

3.

4.

We log on to the Hub Transport server

Start -> Programs -> Microsoft Exchange Server 2010 -> Exchange Management Shell (EMS)

We launch the command, Install-AntispamAgents.ps1

We restart „Microsoft Exchange Transport“ services

7.2 Connection fi ltering

This means of protection is based on the credibility of the IP address of the server sending e-mail. Confi guration (setup) consists of the following steps:

7.2.1 Confi guration of IP addresses for internal SMTP servers

In case there are other internal SMTP servers in front of the Exchange server that has Connection fi ltering or a Sender ID agent installed, it is necessary to list the IP address(es) of these servers in the confi gurations:

1. EMC (Exchange Management Console): Organization Confi guration -> Hub Transport -> Global Settings ->

Transport Settings -> Message Delivery

Figure 12: Confi guration of internal SMTP servers

14

Settings for anti-spam functions

7.2.2 RBL Confi guration (real-time block list)

On the internet there are a number of paid and unpaid services that keep records of trustworthy and risky IP addresses as concerns sending spam. This server can ask our Exchange Server to verify the IP address of an incoming

SMTP connection. It is recommended that you choose 2-3 providers with a strong reputation and guaranteed SLAs.

Provided the number of queries does not exceed 300.000 daily, it is possible for the initial settings to utilize the commonly-used RBL, zen.spamhaus.org.

We implement our own settings as follows:

• In the EMC: Organization Confi guration -> Hub Transport -> Anti-Spam -> IP Block List Providers according to the following Figure:

Figure 13: RBL Settings

7.2.3 IP Allow List Confi guration

To decrease the risk of blocked e-mail and in the case that, for example, a business partner’s mail server would end up on some RBL, it is recommended that you add the IP addresses of key partners‘ SMTP servers to your IP allow list per the following instructions:

EMC: Server Confi guration -> Hub transport -> ServerName -> Anti-spam -> IP Allow List

Figure 14: IP Allow List Confi guration

Settings for anti-spam functions

15

7.2.4 Sender Reputation Service

This IP address control has two data sources:

Using MU/WSUS we obtain an up-to-date list of IP addresses and their reputations based on data from Hotmail services

The server creates its own IP assessment based on average SCL reports received from this IP address, monitoring anomalies within the SMTP relay, etc.

We can confi gure how restrictively to maintain this protection and for how long to block an IP address with a bad reputation. Because free mails, for example, tend to have a relatively high SCL, we recommend confi guring this type of protection at a minimally restrictive level at fi rst and block the IP address for just 4 hours. If everything is OK, you can slowly try gradually increased restriction in your settings.

Figure 15: Sender Reputation Settings

7.3 Sender fi ltering

This protection is based on testing sender e-mail addresses listed in the message header. Provided I want to globally ban receipt of e-mail messages from specifi c e-mail addresses or from entire domains, I can list them here:

• EMC: Organization Confi guration -> Hub transport -> Anti-spam -> Sender Filtering

At a minimum it is recommended to fi lter messages that have no sender address listed at all.

16

Settings for anti-spam functions

Figure 16: Sender Filtering Confi guration

7.4 Recipient fi ltering

This protection is based on testing the e-mail addresses of recipients listed in the message header. Provided it is desired to ban receipt of messages from the internet for specifi c internal user addresses, they can be listed here:

• EMC: Organization Confi guration -> Hub transport -> Anti-spam -> Recipient Filtering

Here a very important option is the “Block messages sent to recipients not listed in the Global Address List”.

Spammers often tend to attempt to send mail to existing domains but not to non-existing e-mail addresses. Of course Exchange server does not deliver such messages; however, their processing unnecessarily burdens the server, including responsibilities for sending NDR. A solution for this is the monitoring of existing e-mail addresses prior to actual acceptance (receipt) of the message. We will decidedly confi gure this option.

Figure 17: Blocking messages from non-existent addresses

Settings for anti-spam functions

17

7.5 SenderID fi ltering

Sender ID fi ltering checks the SMTP server’s outgoing IP address against the list of approved IP addresses for sending in the sender’s domain. These addresses are optionally published in the DNS using so-called Sender ID TXT records.

Should it be discovered that an e-mail has been sent from an unauthorized IP address, then this is likely to be unwanted mail (spam) and two things can be done:

Refuse (not recommended)

Delete (not recommended)

Mark (fl ag) and disable as part of content fi ltering and a resulting SCL score

Figure 18: Confi guring reactions for Sender ID control

7.6 Content fi ltering

Filtering based on message content is a very important part of protection against unwanted mail. An advanced algorithm attempts to assess the likelihood of whether the message is a correctly-addressed mail or spam based on detected, characteristic signs of unwanted mail or known spam campaigns based on Spam Confi dence Level (SCL) numbers. SCL = 0 means a correctly-addressed message, SCL = 9 on the contrary indicates almost a 100% likelihood that the message was unwanted. Then administrators for individual SCL levels defi ne what steps must be taken. They can choose from the following possibilities:

Delete message without NDR

Refuse the message

Put the message in quarantine

Deliver the mail to the user, but to the special folder, „Junk E-mail“

7.6.1 Action settings

According to practical experience the following list of actions is most advantageous for the majority of companies. It is listed according to recommended SCLs.

Delete message without NDR – SCL = 9

Refuse the message – SCL = 7, 8

Deliver the mail to the user, but to the special folder, „Junk E-Mail” – SCL = 4, 5, 6

It is not recommended to use quarantine, should it not be absolutely necessary. Using quarantine signifi cantly burdens the system administrator with maintenance of the quarantine mailbox, which needs to be continually monitored and also cleaned out.

18

Settings for anti-spam functions

We confi gure the fi rst two actions in the EMC: Organization Confi guration -> Hub transport -> Anti-spam ->

Content Filtering.

Figure 19: Reaction to content fi ltering according to SCL

We confi gure the SCL for delivery to the Unwanted Mail folder using an EMS command:

Set-OrganizationConfi g -SCLJunkThreshold 4

7.6.2 Confi guration of allowed and blocked words

Using the custom words settings it is possible to decrease dramatically the number of false-positive (mistakenly blocked correct messages). Each organization should think this through based on their business activities and defi ne commonly used, allowed words. For a company selling offi cial stamps these could be: stamp, stamps, order form, etc.

Provided a word in the e-mail message is authorized, the SCL is automatically set to the 0 value. On the other hand, provided the message contains a blocked word, the SCL will be set to the 9 value.

We confi gure everything in the EMC: Organization Confi guration -> Hub transport -> Anti-spam -> Content

Filtering -> Custom Words

Settings for anti-spam functions

Figure 20: Defi nition of allowed words

19

7.6.3 Specifi cation of exceptions for concrete users

In case of need I can also confi gure a list of mail recipients, for whom content fi ltering will be fully ignored.

Figure 21: Exceptions for content fi ltering

7.6.4 Confi guration of own NDR text for message refusal

An interesting option is also confi guration of one’s own text for NDR, which is sent to the sender when a mail is refused based on content.

We confi gure our own text using an EMS command:

Set-ContentFilterConfi g -RejectionResponse „Based on its content this message was qualifi ed as spam“

7.7 Select tips for optimizing anti-spam

In the previous chapters we have described basic anti-spam confi gurations, which must almost always be implemented. In the fi nal part we focus on expanded settings that can help us use, to a maximum degree, all advantages that Exchange 2010 anti-spam affords.

7.7.1 Premium Anti-spam

Provided the company has Exchange Enterprise CAL or Forefront Protection 2010 for Exchange Server available for its users, it can use so-called Premium Anti-spam, which contains the following benefi ts:

Daily update of the IMF content fi lter (standard = only 1x every 14 days)

IP reputation update several times daily

Spam campaign update several times daily

20

Settings for anti-spam functions

How do I turn off premium anti-spam? In the EMC we will fi nd a section called Server Confi guration -> Hub transport -> ServerName command for the context menu: Enable Anti-spam Updates. We continue according to the

Figure below.

Figure 22: Premium Anti-spam Activation

7.7.2 SafeList Aggregation

Users of the Outlook Web Access or the Microsoft Offi ce Outlook interfaces have the option of creating lists of Safe

Senders. The client then always delivers messages from these addresses directly to the Inbox. So as I user I have the option of signifi cantly infl uencing which messages will go to my Inbox and which will not. It is also important to explain that Safe Senders for User A need not necessarily be Safe Senders for User B.

Contrary to earlier versions of Exchange Server 2010 these lists from user mailboxes are published in Active Directory and thus subsequently in the organization’s Exchange thanks to automatic help from Mailbox Assistant.

7.7.3 Individual SCL action settings for a specifi c mailbox

In some cases confi guration of different SCL parameters for a given mailbox will be required. Not only is this possible, but we can even turn on and off different types of fi ltering for a specifi c user. Confi guration is done exclusively via EMS. Here we give two examples:

Set-mailbox ID „Miroslav Knotek“ –SCLRejectEnabled $false –SCLQuarantineEnabled $false –SCLDeleteEnabled

$false – no message for Miroslav Knotek will be deleted, refused nor sent to quarantine

Set-mailbox ID „Miroslav Knotek“ –SCLRejectThreshold 5

– messages for Miroslav Knotek will be refused from SCL = 5

7.7.4 Whitelisting domains or sender addresses

If I want to skip content fi ltering for users or entire domains, I can confi gure these settings using EMS commands

Set-contentfi lterconfi g -BypassedSenderDomains microsoft.com

Set-contentfi lterconfi g -BypassedSenders [email protected]

Settings for anti-spam functions

21

8. Certifi cates and working with them

Each Exchange Server 2010 has a certifi cate immediately after installation that has been entered during the installation process. This certifi cate includes a proper name and is issued for a period of 5 years, yet it is a so-called

SelfSigned certifi cate. In practice this means that no one will trust such a certifi cate, because they do not know the certifi cation authority that issued it (nor is that even possible, for it was Exchange Server itself). Thanks to this however, neither Microsoft Offi ce Outlook nor the majority of clients via ActiveSync will be able to communicate properly with this Exchange Server. Thus in the majority of cases it is necessary to issue a new certifi cate – either from a commercial and trustworthy certifi cation authority or from an internal authority.

A certifi cate must fulfi ll the following three criteria:

It must be valid (certifi cates are issued for a specifi c period, i.e. 1 year)

The name shown on the certifi cate must agree with the name the client calls up

The Certifi cation Authority issuing the certifi cate must be trustworthy for the client

It’s mainly with this last point that you will come across many problems. Provided you issue, for example, a certifi cate from your own, internal Certifi cation Authority, you must be prepared for the fact that you will have to import the certifi cate (from the Certifi cation Authority) to each machine that will communicate with Exchange. For Windows clients, who are domain members, this can be done simply using Group Policy. For other clients this will be more diffi cult...

On most mobile devices this will work, but it needs to be done manually and is relatively tedious work, specifi cally in cases where your company has dozens, hundreds or thousands of different devices. In such a case I would recommend that you instead buy a certifi cate from a commercial or recognized Certifi cation Authority that the client will recognize. This means that as Exchange Server administrator I should fi rst consider which mobile clients we will run in the company and verify for each device which Certifi cation Authority they support and only afterwards purchase certifi cates at a Certifi cation Authority that, if at all possible, is supported by all clients. Personally I have had good experience with the Certifi cation Authority, Thawte. It is supported by almost all devices and its prices for annual certifi cates are acceptable for Czech businesses (i.e.

http://www.exchange4u.cz/digitalni-certifi katy.asp – prices are around 5000,- CZK for 1 year ).

Let’s go back, however, to creating the request for a certifi cate. We can do this using:

1. EMC: Server Confi guration -> we select the server we wish to work with and we launch the „New Exchange

2.

Certifi cate“ wizard

In this wonderful help tool we enter the name of the new certifi cate; we decide whether it will be a wildcard certifi cate and then in the section „Exchange Confi guration“ we enter the name that our Exchange Server will use for individual services (one of the names must be the primary one – most often this is the FQDN for the given server)

22

Certifi cates and working with them

Figure 23: Request for new Exchange certifi cate

3.

4.

5.

We fi ll in information about our company; we save the request to disk and then send it to the Certifi cation

Authority

As soon as the Certifi cation Authority approves the request, they will send us the fi nal certifi cate, which we will associate with the request form in the Exchange console clicking on the request and the option „Complete

Pending Request“

Provided everything went OK, the certifi cate is now ready for implementation. Using the „Assign Services to

Certifi cate“ option, we associate the certifi cate with Exchange services. Among other things a name is confi gured for the services: one they will respond to according the settings given in the previous wizard.

Certifi cates and working with them

23

9. Confi guration of Client Access Server role services

9.1 Autodiscover

Autodiscover was the last piece of the various Exchange technologies puzzle to fall into place. Though it is only the newest clients that support it, it is something that we were always missing. On client machines Autodiscover ensures that the entire device is confi gured such that it works properly with Exchange Server once e-mail addresses and pass words have been entered. So the necessity of knowing information about the infrastructure and client settings falls to the wayside. It is suffi cient just to remember your own e-mail and password. Autodiscover monitors itself repeatedly and in the event of comprehensive changes in your Exchange infrastructure (i.e. during migrations) it takes care of the repeated and proper client reconfi guration.

How Autodiscover works:

1. The client takes the domain from the e-mail address – i.e. that which is behind the „@“ (the „at“ sign). So if my

2.

3.

4. mail address is [email protected]

, I know that it will thereafter work with the „kpcs.cz“ domain

Through a DNS resolution it will attempt to fi nd an Autodiscover record. This can have three forms: a. b.

A kpcs.cz domain record

A „autodiscover“ record in the „kpcs.cz“ zone. That is, „autodiscover.kpcs.cz“ c. SRV „_autodiscover“ record

As soon as it is able to resolve one of the three options to an IP address (that is once the record exists), the client opens an HTTP connection on the Exchange Server to a virtual path „<server name>/autodiscover/autodiscover.xml“.

For essential client authentication by the server it receives an XML fi le that the web service created based on a request from the client. The client then confi gures the ActiveSync service itself using the XML fi le.

The Autodiscover service is not self-confi guring. The confi gurations that it sends the client are taken from those of other relevant services. Despite this it is essential to check what Autodiscover returns back to clients, because otherwise clients will not be able to fi nd certain services and they will not function properly. We do this using the

Outlook client: a. b.

On the main Windows desktop next to the system clock, we right click the Outlook icon while holding down the CTRL key and we select the „Test E-mail AutoConfi guration“ option

We enter the e-mail address and password

24

Figure 24: Test E-mail AutoConfi guration

Confi guration of Client Access Server role services

We verify that the addresses on which clients are provided individual services are OK and valid. In cases where we fi nd errors it is necessary to repair them for the given service.

9.2 Outlook Web App (OWA)

Outlook Web App is an interface adapted for web browsers, and now not only for Internet Explorer but for others. It is thus ideal for access at a moment when the user cannot use his/her own computer (i.e. when they’re on vacation).

For the OWA’s proper functioning it is necessary to implement several confi gurational steps.

1. EMC: Server Confi guration -> Client Access -> we thus indicate the server we wish to work with and select the

2.

„Outlook Web App“ tab, on which we call up the OWA virtual directory features

On the tab „General“ we enter the name that will be used for both internal and external access – provided we have earlier run the certifi cate issue wizard and its subsequent implementation in the system, the names will be confi gured according to this wizard

3.

4.

On the „Authentication“ tab we select the desired type of authentication

We can eventually confi gure the desired behavior of the OWA on further tabs (i.e. behavior regime for access from a public or private computer (Public access to attachments only using WebReady, Private access to everything), etc.)

Figure 25: OWA Confi guration

Should you require simplifi ed access to the OWA for your users, so that they do not have to diffi cultly enter the following address: https://email.exchange4u.cz/owa mohli psát pouze http://email.exchange4u.cz, follow the recommendations on this page: http://technet.microsoft.com/en-us/library/aa998359.aspx

Confi guration of Client Access Server role services

25

9.3 Exchange ActiveSync Confi guration

In addition to data synchronization – typically for e-mail, contacts and calendars – ActiveSync can synchronize them to clients and others, mainly security confi gurations. This is a very important component of ActiveSync – today a large amount of very sensitive data are located in mailboxes and it is fully essential to ensure that these data cannot be misused simply because someone steals your mobile phone. A typical and oft-used example is that of password policy – that is, how long a phone should wait to lock itself after a period of inactivity, what password it should require of the client, and – provided it’s supported by the machine – also how many attempts a user has to enter the right password prior to the machine’s restarting and return to its factory settings (i.e. actual deletion). Provided the client also supports servers for data storage (i.e. various micro/mini SD cards), we can – thanks to policies – even force the encryption of this data. In such cases a thief cannot access any data simply by theft and transfer of the data card.

For the proper and desired functioning of mobile client synchronization with Exchange Server using ActiveSync it is necessary to set up policies, whose confi guration will be applied to clients:

1.

2.

Organization Confi guration -> Client Access -> „Exchange ActiveSync Mailbox Policies“ tab

We choose the „default“ policy, or we set up a new one and change its features according to requirements (of course there can be several policies in Exchange Server and it is no problem to apply different policies to different users so as to ensure needed confi gurations across all clients)

Figure 26: ActiveSync Policy

Other interesting options include WiFi blocking, Bluetooth, or internal cameras/videocams. The option of blocking access to data services during periods when the client is using roaming is also very useful. In this way you can avoid unpleasant surprises in the form of high phone bills after spending time abroad. I would only allow myself to point out that the majority of the options mentioned in this paragraph require an extended license, an Enterprise CAL license, for the client.

You can learn more about ActiveSync here: http://technet.microsoft.com/cs-cz/ee958098.aspx.

26

Confi guration of Client Access Server role services

9.4 Outlook Anywhere Confi guration

When we want our clients to have their Outlook communicate with the Exchange server from anywhere using communications packaged into HTTPS, it is necessary to enable Outlook Anywhere. We achieve this by doing the following:

1.

2.

3.

We check if we have the „RPC over HTTP“ component installed on our server.

EMC: Server Confi guration -> Client Access -> we indicate the server we want to work with and we call up the

„Enable Outlook Anywhere“ wizard

In this we fi ll in the name via which this service will be available on the internet

Figure 27: Turning on Outlook Anywhere

Watch out for the client authentication option. In the case you use Basic authentication you do have 100% certainty of its functioning; however, the client will always (!) be asked for its password when using Outlook Anywhere without the possibility of saving it. Should you opt for authentication using NTLM, it is possible to save the password to the client and the user will not be repeatedly asked for it. However, careful, NTLM authentication cannot get past many network elements and therefore it’s possible that it will not work everywhere.

Confi guration of Client Access Server role services

27

10. New, select features for Exchange 2010

Certain new features of Exchange 2010 will not fi t in this document; however, we have selected two that have been very warmly received by users.

10.1 102,647 MailTips

MailTips are various tips that notify users during the message writing process that the message – provided they send it to a given address – will be delivered with a delay or not at all, etc. It is a help tool that attempts to decrease the overall number of messages and limit certain types of errors. You typically value information that the owner of the mailbox to whom you plan to send a mail is on vacation or that it directs the message outside the organization.

There are many possibilities, I have just mentioned here the ones I, myself, use. We confi gure these using EMS:

Set-OrganizationConfi g -MailTipsLargeAudienceThreshold 25

Set-OrganizationConfi g -MailTipsExternalRecipientsTipsEnabled $true

Set-OrganizationConfi g -MailTipsMailboxSourcedTipsEnabled $true

Set-OrganizationConfi g -MailTipsGroupMetricsEnabled $true

Set-MailboxServer <servername> -GroupMetricsGenerationEnabled $true

Set-MailboxServer <servername> -GroupMetricsGenerationTime 03:00

Figure 28: MailTips

10.2 Image settings for Exchange mailboxes

If you use Microsoft Offi ce Outlook 2010 clients and higher, you can use the option of recording images to Active

Directory for each user/mailbox that will subsequently be displayed to all users on the client. The only condition is that the image cannot be larger than 10KB and must be in JPG format. We import images to Active Directory using a command in Exchange Management Shell as follows:

1. EMS: Import-RecipientDataProperty -Identity “Martin Pavlis” -Picture -FileData ([Byte[]]$(Get-Content -path “C:\1.

Photo\Pavlis.jpg” -Encoding Byte -ReadCount 0))

Figure 29: Image in Outlook 2010

Messages are subsequently displayed to users in GAL as well as in other places.

28

New, select features for Exchange 2010

10.3 Compatibility settings for Microsoft Offi ce Outlook 2003 clients

If you use Microsoft Offi ce Outlook 2003 clients, you can encounter problems where these clients are not able to communicate with Exchange Server 2010. The reason for this is that the CAS server immediately after installation requires encrypted MAPI/RPC communications between Exchange and clients. Older clients do not usually have this turned on. Should you encounter this problem, there are essentially two ways how to solve it:

1.

2.

In all Outlook 2003 applications it is necessary to confi gure MAPI/RPC communication in the encryption profi le.

Either manually or forced for clients (ideally prior to actual migration) using Group Policy

Turn off forced MAPI/RCP encryption for Exchange Server, with CAS roles using EMS: Set-RpcClientAccess

–identity <servername> –EncryptionRequired $false

Figure 30: Outlook RPC Encrypted

10.4 Import/Export data from/to PST fi les

This very historic means of data migration is still very popular; not only with us but a number of administrators also like it very much. Among its positive aspects are that mailbox content is exported to PST fi les and transferred to a completely new environment – most often to a new Active Directory, to the organization’s new Exchange, thus allowing for the „green fi eld“ construction of Exchange – throw away everything that existed until now and begin again. Attention – only e-mails are transported in PST (fi les) and most mailbox features are lost (visuals, formatting and confi gurations, rules, etc.). Using PST fi les you literally transfer items in the mailbox, and only those, nothing more. Provided these limitations don’t bother you and you’re in a situation, where export/import via PST is exactly what you want, then proceed as follows.

Either directly on the server, or via the admin workstation (it must be built on x64 architecture and be a member of a domain where Exchange Server 2010 is located) we run the installation as follows:

• Powershell 2.0.NETFramework 3.51

New, select features for Exchange 2010

29

Offi ce Outlook 2010 64bit

Exchange Server 2010 administrative tools (we launch server installer and select just Management Tools)

Now you need to log on to Exchange Server as someone, who has full rights for the organization’s Exchange

(typically this is the Administrator) and rights for import/export delegation to authorized individuals or groups. Here

I would like to emphasize after installation no one has this right and this despite the fact that Exchange Server 2010 adheres strictly to role assignments (using Role Base Access Control), without these rights you cannot go further.

New-ManagementRoleAssignment –Role “Mailbox Import Export” –User “<username>”

New-ManagementRoleAssignment –Role “Mailbox Import Export” –Group “<usergroup>”

In the fi rst example we delegated import/export rights to one specifi c account, in the second case to an entire group.

Now as soon as we log on to the administrator station using the account to which we assigned needed rights in the previous step, we can begin within Powershell to use the CMDlets “import-mailbox” and “export-mailbox”.

Figure 31: Export Mailbox

An advantage within Exchange Server 2010 is that we can launch the „Exchange Management Console”, where after right-clicking the mouse we see options for calling up the graphic wizard via import and export. In this way the entire activity becomes very simple.

30

New, select features for Exchange 2010

10.5 Microsoft Exchange Best Practices Analyzer

Because Exchange Server is dependent on a whole range of other services (i.e. DNS and Active Directory) it is recommended that when monitoring the Exchange environment the administrator not just control its services, but rather implement a comprehensive check of the whole environment. For exactly these purposes we can fi nd the

„Exchange Best Practices Analyzer“ tool directly in the EMC. This tool is able to download updated tests from the internet after each start-up. It subsequently reviews the whole company infrastructure and in cases of discrepancies offer recommended solutions.

Figure 32: Exchange Best Practices Analyzer

I recommend running this tool roughly once a month to monitor the entire Exchange infrastructure, including related services.

New, select features for Exchange 2010

31

10.6 Microsoft Exchange Remote Connectivity Analyzer

As soon as you have confi gured everything in your organization’s Exchange per the above-mentioned steps, you certainly want to be sure that access to your Exchange servers published to the internet will work properly and as you had envisioned. For precisely this purpose Microsoft created an on-line tool that is able to test all important features from the internet – i.e. DNS, SMTP, Outlook Anywhere, Exchange ActiveSync, etc. This is a wonderful tool!

Figure 33: Exchange Remote Connectivity Analyzer

You can fi nd this tool on the following address: https://www.testexchangeconnectivity.com.

32

New, select features for Exchange 2010

11. High availability for Microsoft Exchange Server 2010

If you’re afraid that your company might accrue fi nancial losses due to lack of access to your mail systems due to an

Exchange Server system failure, then it is certainly time to think about ensuring high availability. This fi eld can very easily be split into two segments – high availability of data saved on Exchange databases and high availability at the network level, where client transfers/transactions are directed to the best/most accessible server. In both cases it holds true that you will need several servers – a minimum scenario counts on two servers; in extensive networks for most companies this can be as many as dozens of servers.

11.1 Database Availability Group

Data in Exchange Server are saved to/in databases, which are looked after by servers with pre-installed Mailbox roles.

These servers can be clustered in groups, in which it’s possible to ensure a replica of data on all group members. This group is called a Database Availability Group (DAG). In order to be able to add Exchange servers to the DAG, we have to meet the following conditions:

The Windows operating system must be the Enterprise edition, or eventually Datacenter – this is due to the need for DAG co-operation with the Windows Failover Cluster service, which is only included in these editions

Exchange Server can be the Standard version (this is an important new development!), provided it’s enough for you to work with fi ve databases

It is further recommended that Exchange Servers in the DAG have two network interfaces – one network for communication with clients and another for data synchronization

In the DAG it is only possible to replicate data from the Mailbox database; it is not possible via DAG to replicate data in the Public Folder databases

It’s very simple to set up a DAG:

1. EMC: Organization Confi guration -> Mailbox -> Database Availability Group tab

Figure 34: Database Availability Group

High availability for Microsoft Exchange Server 2010

33

2. Here we select the command „New Database Availability Group and enter the features of the new DAG:

2.1 DAG Name – this is the name that will be used to manage the DAG and thus it must be unique for your network (similar to the case of Exchange servers). After you set up the DAG a computer account in Active

Directory is created bearing this name.

2.2 Server (and fi le), that will be used as a witness – provided you have further HUB servers in your network, it as a witness will automatically use certain ones of those and it is not necessary to fi ll in any information. If you don’t have such servers in your network, it will be necessary to choose any available Windows server. On this server you must fi rst create and share a folder that the DAG can use. You will fi nd the exact guidelines here: http://technet.microsoft.com/en-us/library/dd298065.aspx

Figure 35: Setting up a new DAG

In this way the DAG with its features is created in the organization’s Exchange, but physically nothing has happened yet. So you still have time to consider whether you might want to change certain DAG features so that it fully suits your needs:

• It is standard that data in the DAG are replicated among Exchange servers using a TCP (protocol) on the 64327 port. This port is automatically allowed to pass through the built-in Windows Firewall during the addition of servers to the DAG. If you want you can change this port; however, it is necessary afterwards to manually enable the port in Windows Firewall. You can make the change using the following EMS command:

»

Set-DatabaseAvailabilityGroup -Identity DAG -ReplicationPort 12345

34

High availability for Microsoft Exchange Server 2010

• In order to function the DAG needs not only a name, but also an IP address. Because you don’t have the option to change this IP address in the EMC and because it will not suit everyone that the IP address is automatically selected from the DHCP server, you can set the address to a specifi c, static value. For this purpose implement the following EMS command:

»

Set-DatabaseAvailabilityGroup -Identity DAG -DatabaseAvailabilityGroupIPAddresses 10.0.0.1

As soon as you have fi nished editing the DAG features, you can begin adding individual Mailbox servers to the DAG.

Use the following steps:

1.

2.

3.

EMC: Organization Confi guration -> Mailbox -> Database Availability Group tab

Call the command „Manage Database Availability Group Membership“

Using the „Add“ button we put all relevant Mailbox servers in the DAG

Figure 36: Adding servers to a DAG

4. Only at the moment when we click on the „Manage“ button is the DAG physically set up and individual servers are added to it. The wizard is very intelligent and is able to handle the majority of essential requests on the part of the Mailbox server by itself. For example, it monitors whether the proper edition of the system is being used, whether the Windows Failover Cluster component is installed on the requested Mailbox server – if not it will install it by itself – and a whole array of other steps. It is common for completion of this step to take several tens of seconds for each Mailbox server.

High availability for Microsoft Exchange Server 2010

35

Figure 37: Completion of DAG set-up

5. Now we have created the DAG and we can look back at its features and at which Mailbox servers are currently members of the DAG. In the lower part we have the option to make further changes, i.e. in the network area

(i.e. on which network data between Mailbox servers will be replicated and on which network Exchange will communicate with clients)

36

High availability for Microsoft Exchange Server 2010

Figure 38: DAG features

6. At this moment we can begin to ensure data replication for individual databases within the DAG. This is a database feature, therefore you must follow the following steps:

6.1 EMC: Organization Confi guration -> Mailbox -> Database Management tab

6.2 We indicate the database that we wish to replicate to a further Mailbox server and we call it up using the

„Add Mailbox Database Copy“ command

6.3 While running the wizard we select which Mailbox servers will replicate this database

High availability for Microsoft Exchange Server 2010

37

Figure 39: Creating a database replica within the DAG

7. As soon as we complete the wizard for adding database replicas, we have the option in the tools management to follow, which servers are currently replicating the given database, and which servers hold the active replica

(mounted – the one currently being used), which servers have further replicas and what the status of these replicas are (healthy, initializing, failed, etc.). For better orientation individual situations are highlighted using different colors (green, red, etc.). We can obtain the same information also in the EMS using the command: Get-

MailboxDatabaseCopyStatus –identity DAG

38

High availability for Microsoft Exchange Server 2010

Figure 40: Replication status within the DAG

8.

9.

After marking a specifi c database in the EMC it is possible, in the lower part of the console, to implement database Failover – that is a manual change for which server in the DAG will hold the active replica

Similarly you can also implement Failover for an entire server – at this moment all active databases on the chosen server will activate on other servers within the DAG

Figure 41: Active work with database replicas in the DAG

In the DAG it is of course possible to confi gure a whole range of further functions that can be useful in certain situations. For further resources look here: http://technet.microsoft.com/en-us/library/dd638215.aspx.

High availability for Microsoft Exchange Server 2010

39

11.2 Network load balancing

In case you decided to ensure high availability for Exchange at the data level using databases in DAG, it is likely that you will wish to ensure high availability at the network level. I would remind you that in Exchange Server 2010 the client never communicates directly with the database server, but always via the Client Access Server (CAS). So it is thus necessary to ensure high availability for this role through the installation of at least two CAS servers and then sort out the load balancing of protocols through which clients will communicate with the CAS servers. These are protocols such as RPC, HTTP, IMAP, POP, etc.

Hardware Load Balancer – should you not wish to sort out the matter of protocol distribution using software, you can look for a partner solution on the load balancer hardware level. There is a whole range of partner solutions such as (BIGIP) from F5, or Barracuda. You have to use hardware-based load balancing (!) in cases where there will only be two Exchange servers in your organization. A simple rule applies here – in cases where a server is a member of a DAG, you cannot run Network Load Balancing, included directly in the Windows system, on it. This is important mainly for smaller solutions involving two Exchange servers – here you must plan on the purchase of other equipment that support hardware-based load balancing.

Microsoft Network Load Balancing – this technology, which is part of all Windows Server editions, can ensure the creation of network clusters; that is, a situation, where many servers have a common IP and MAC address. This solution cannot be used on servers that are part of a DAG (!).

Whatever technology you choose for high network availability it is important to plan on confi guration of proper protocol load balancing (i.e. RPC, HTTP, IMAP, POP, etc.) for individual CAS servers. Here too there is a wide array of options – i.e. direct everything to one CAS (provided it’s available), then only in case of unavailability direct communications to a different CAS server; or it is possible to balance communications evenly. This now all depends on your specifi c requirements.

12. Conclusion

In this document I attempted to include all essential information on what needs to be confi gured immediately after installation of Exchange Server 2010 so that everything will work to your satisfaction. Even though it’s not possible to mention everything, I hope that this document will help at least with basic confi guration/set-up – for further investigation of individual options you will have to look in Exchange resources.

Links:

Exchange 2010 Technet resources ( http://technet.microsoft.com/en-us/library/bb124558.aspx

)

Web Exchange 2010 www.microsoft.cz/exchange/2010

40

Conclusion

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project