Friday, June 14, 2013

Optimizing Microsoft Exchange for the Enterprise, Part II: Hub Transport Server and Lync-SharePoint Integration

Exchange Server 2010 is one of the most flexible and robust products in managing the messaging infrastructure of the organization. It includes a considerable number of features that help control the way emails are exchanged within the premises of the company. While the default setup provides a functional setup, it is worth looking at other features to get the most of this product. In this two-part white paper, we explore these features and take a look at how they can be implemented on top of a standard installation of Exchange servers in the organization. Part 1 examines, Optimizing the Mailbox Server Role and Optimizing the Client Access Server (CAS). Part 2 looks at Optimizing the Hub Transport Server, Miscellaneous Features, and Lync- SharePoint Integration.

The Hub Transport Server, which is responsible for the mail flow in the organization, features very specific settings
that allow Exchange administrators to define how e-mail is routed, and also applies on-the-fly policies to
that e-mail. This not only allows the sending and receiving of e-mail from the internal world, but also to and
from the Internet.

Transport rules are the mechanism that allows e-mail to be modified while in transit. This can be applied to a
message that is going through the Hub Transport Server role. Transport rules can be applied based on filters and
conditions, and can be used for multiple purposes.

Apply disclaimers to messages
Prevent certain types of viruses by patterns
Filter confidential information and apply Rights Management Services templates
Track and archive messages that are sent or received from specific users
Redirect inbound or outbound messages for inspection
Prevent communication between specific groups or users

A transport rule is configured through the Exchange Management Console (Organization Configuration->
Hub Transport-> New Transport Rule) or Exchange Management Shell, using the following sample cmdlet
and parameters.

New-TransportRule -Name 'Rule1' -Priority '0' -Enabled $true -from 'user1@contoso.com' -SentTo
'user2@contoso.com' -BlindCopyTo 'executives@contoso.com'

In this instance, e-mail is copied to specific users when user1 sends an e-mail to user2. More complex settings
with appropriate rule priorities can also be set up.

Address lists are a collection of mail objects that can be seen through Outlook clients or OWA when an end-user
selects a recipient. Address lists are populated to end devices through address book policies that are essentially
a collection of address lists. This feature makes it possible to apply filters to generate custom address lists, and
then create address book policies to different user groups in the organization.

While it is possible to use the default settings, an organization would probably need to create different policies,
depending on the way the organization is logically segmented. For instance, an acquisition or merger can occur
and, by default, users will see mail objects from both organizations, even if they are legally independent, and
they don't communicate. By creating custom address lists, these lists will be smaller and will contain only mail
objects that end-users are sending mail to.

It is possible to configure these settings through the Exchange Management Console (Organization Configuration->
Mailbox-> Address Lists tab. Once the Address lists are configured, you can create a policy
through the Address Book Policies tab.

SMTP connectors need to be configured when mail flows to other organizations or the Internet. They allow the
e-mail to be received from the outside world as well. Internal e-mail is also routed through SMTP connectors;
however, these are stored in Active Directory (AD) and cannot be seen from the management console.

Receive connectors

By default, Exchange can receive e-mails from authenticated senders only through default and client connectors.
If an organization needs to receive e-mail from the Internet, it must allow anonymous types of connections to
the Exchange servers.

It is beneficial to create multiple receive connectors and then define more granular authentication methods,
depending on who is sending e-mail to Exchange.

For example, since e-mail coming from the Internet comes from unauthenticated servers, you can define a
smart host or relay agent that receives the e-mail directly from the Internet, and then configure authentication
between that relay agent and your Exchange hub servers. All e-mail from the relay would be redirected to your
Exchange servers, allowing for greater security on internal servers, as no unauthenticated connection is accepted
on Hub servers.

Another reason we can create multiple SMTP receive connectors is because internal devices, such as printers
and faxes, access Exchange often. These devices all have different authentication settings; thus, you can be more

flexible with authentication in connectors and IP filtering. This way, you are preventing unauthenticated users
connecting to your SMTP servers and anonymously sending e-mail.

Send connectors

It is necessary to create send connectors manually, and preferable to choose to send to a smart host in a DMZ
(such as an Edge server or any other SMTP server solution) rather than sending e-mail directly on the Internet
from the Hub server (through DNS).


View the original article here

No comments:

Post a Comment