Microsoft Office 365 Beta Features - IT Solutions - IT Solution

Microsoft Office 365 Beta Features

Microsoft Corporation

Published: November 2010

Legal Information

Information in this document, including URL and other Internet Web site references, is subject to

change without notice. Unless otherwise noted, the companies, organizations, products, domain

names, e-mail addresses, logos, people, places, and events depicted in examples herein are

fictitious. No association with any real company, organization, product, domain name, e-mail

address, logo, person, place, or event is intended or should be inferred. Complying with all

applicable copyright laws is the responsibility of the user. Without limiting the rights under

copyright, no part of this document may be reproduced, stored in or introduced into a retrieval

system, or transmitted in any form or by any means (electronic, mechanical, photocopying,

recording, or otherwise), or for any purpose, without the express written permission of Microsoft

Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual

property rights covering subject matter in this document. Except as expressly provided in any

written license agreement from Microsoft, the furnishing of this document does not give you any

license to these patents, trademarks, copyrights, or other intellectual property.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft, Forefront, and Windows PowerShell are trademarks of the Microsoft group of

companies.

All other trademarks are property of their respective owners.

3


Known Issues

Overview of Complex FOPE Mail Flow Scenarios

Fully Hosted Scenario

Shared Address Space with On-Premises Relay Scenario

Internal Mail Flow Scenario

Outbound Smart Host Scenario

Inbound Safe Listing Scenario

Regulated Partner with Forced TLS Scenario

Enforcing and Removing FOPE Connector Associations

Viewing Information About the FOPE Connectors

4

Table of Contents


Microsoft Office 365 Beta Features ................................................................................................. 1

5

Known Issues

Following are known issues with the Microsoft® Forefront® Online Protection for Exchange

Microsoft Office 365 Beta.

Policy Quarantine is Exposed as a Policy Option but User Account Management is Restricted for Office 365 Beta Administrators In the Office 365 beta, hosted Exchange administrators cannot create and manage FOPE

Administration Center user accounts. Without this functionality the messages in user’s quarantine

cannot be accessed, reviewed or released. This affects all Office 365 Beta administrators who

create or are migrated with a Policy Rule with the Action set to Quarantine AND who are

configured for service under any Hosted Exchange reseller.

Workaround

Office 365 Beta administrators will have to escalate to their support team to have the support

person create the FOPE Administration Center user so that the messages can be accessed,

reviewed or released.

Wildcard Domain Certificate Validation Fails if no Domain is Specified in the Outbound Pool to Exchange If you use wildcard domain validation when creating a connector then domain certificate validation

fails when there is no domain specified in the outbound pool for Exchange.

Workaround

You can create a certificate with CN (common name) that lists all subdomains for domain

validation instead of using wildcards.

You only need to use this workaround if you find it important to use Recipient Domain

Certification with wildcard certificate match without following the Outbound Smart Host Scenario.

This connector setting is something that will not be created for all domains but only for routing to

certain domains.

6

Wildcard in TLS Domain Only Matches1 Level of Subdomains The wildcard matching in a TLS domain specified in Connectors match only the first sublevel. For

example, a connector created as *.domain.com will match sub.domain.com but not

eu.sub.domain.com.

Workaround

You can specify the appropriate domain through the connector UI. For example, if you want it to

match eu.sub.domain.com you can define the tls domain in connector as *.sub.domain.com. For

more information, see Overview of Complex FOPE Mail Flow Scenarios.

Outbound Connector Fails When Recipient Domain is Greater than 232 Characters When mail that matches the defined connector settings is destined to recipients who have a

domain name greater than 232 characters in length, the mail is not delivered. If you try to send

an email to a recipient email address that is longer than 232 characters, and you have an

outbound connector that applies to the recipient, then the email is not delivered.

Workaround

When you work with an organization whose domain name has more than 232 characters, you

must not create outbound connectors that target those domains.

Mail Rejected With a 450 Level Temporary Rejection Message If an inbound connector specifies that mail be delivered via TLS but the sender is not sending

over an appropriate TLS channel, mail is rejected with a 450 level temporary rejection. However,

the detailed reason of TLS failure is not available for troubleshooting. Although the return code

doesn’t give the actual reason of failed TLS connection, the reason is because the recipient has

not sent mail over an appropriate TLS channel.

Workaround

When you create an inbound connector which specifies that mail must be sent via TLS, you must

communicate to organizations that send mail to you what TLS restrictions you have set and

require that they send mail accordingly.

7

Some Mail Does not Have Connector Settings Applied and Headers do Not Match Expected Sender Domain When the recipient belongs to a virtual domain then the connector settings you expect to be

applied (based on the parent domain) are not applied. Also, when the sender belongs to a virtual

domain then connector setting will be applied based on the parent domain even though the policy

settings are applied based on the virtual domains. Furthermore, if you are inspecting headers you

may notice that they don’t match the expected sender domain.

Workaround

Connectors and virtual domains are not recommended to be used together. You should not

implement connectors when you have senders or recipients that belong to virtual domains.


When you have subscribed to the Microsoft Office 365 Beta cloud hosting service, you are

automatically provisioned with the Microsoft® Forefront® Online Protection for Exchange (FOPE)

email protection service. There are several mail flow scenarios that you can implement, and your

configuration options for FOPE vary depending upon the scenario.

Fully hosted scenario—Email flows exclusively through the cloud (Internet), without any

interaction with on-premises servers. For more information, see Fully Hosted Scenario.

Shared address space with on-premises relay scenario—Email is hosted partially in the cloud

(Internet) and partially on-premises, and mail flow is controlled on-premises. For more

information, see Shared Address Space with On-Premises Relay Scenario.

Internal mail flow scenario—Both the sender and the recipients are within the same

organization, and the organization has mailboxes both in the cloud and on-premises. However,

unlike the previous scenario, not all mail is controlled by the on-premises mail server. In this

scenario, email is sent between the cloud and the on-premises server without being sent to the

Internet and FOPE skips all filtering operations. For more information, see Internal Mail Flow

Scenario.

Outbound smart host scenario—FOPE acts as a smart host, redirecting outbound mail to an

on-premises server that applies additional processing before delivering mail to its final

destination. However, incoming mail goes straight to the Exchange Online servers without

passing through an on-premises server. You may want to consider this option for your

organization if you have an on-premises application or other compliance solution you use to filter

8

outgoing mail and you also want the benefits of FOPE edge, virus, policy, and spam filtering. For

more information, see Outbound Smart Host Scenario.

Inbound safe listing scenario—Email is sent inbound through FOPE to Microsoft Exchange

Online from a trusted organization. In this scenario, FOPE is configured to skip IP address

filtering on inbound mail sent from IP addresses specified in a safe list. You can also configure

FOPE to skip policy and spam filtering. For more information, see Inbound Safe Listing Scenario.

Regulated partner with forced TLS scenario—Forced inbound and outbound transport layer

security (TLS) is used to secure all routing channels with business regulated partners. For more

information, see Regulated Partner with Forced TLS Scenario.

If you are acting as a reseller partner where your organization acts as an intermediate

gateway for all mail flow between your customers, for inbound and outbound mail both

within and outside their organizations, it is recommended that you contact Microsoft

Technical Support to configure the Microsoft Exchange Online service.

The following topics describe these scenarios in further detail. After reading the overview

information, proceed to the procedures that provide the customizable configuration options

available for the inbound and outbound FOPE connectors that drive these complex mail flow

scenarios (aside from the fully hosted scenario, which does not use the FOPE connectors).

For all cross-premises scenarios that use the FOPE connectors, Exchange Server 2010

SP1 or higher is required.

To view a video that describes the FOPE complex mail flow scenarios, see Overview of

FOPE Complex Mail Flow Scenarios.

Related Topics Fully Hosted Scenario








Known Issues

Tip:

Important:

Tip:

http://go.microsoft.com/fwlink/?LinkID=149248

http://go.microsoft.com/fwlink/?LinkId=205601


9

Fully Hosted Scenario

Using a fully hosted scenario with Forefront Online Protection for Exchange (FOPE) refers to

when all of your organization’s mailboxes are hosted exclusively through Microsoft Exchange

Online cloud services. The fully hosted scenario consists of Exchange Online being provisioned

with FOPE, which provides edge, virus, policy, and spam filtering protection for your mailboxes.

Inbound and Outbound Email When receiving inbound email or sending outbound email, the fully hosted scenario is as follows:

In this example, Contoso has purchased Exchange Online, which is provisioned with FOPE for

email protection. All email for Contoso is fully hosted in the Exchange Online cloud service and is

protected by FOPE.

10

When email is sent inbound to Contoso from an external Internet source, it is passed to FOPE,

which performs various inbound filtering operations on the message: edge filtering (Forefront

DNS block list, envelope filtering, and directory based edge blocking), virus scanning, policy

enforcement, and spam filtering. If the email passes inspection, it is delivered to the specified

recipients hosted in Exchange Online. If the email fails inspection, FOPE performs actions on the

message depending upon the inbound configuration settings. You can view information about

what actions FOPE has taken by looking at the mail delivery traffic reports. For more information,

see Reports Overview in the FOPE User Guide.

When email is sent outbound from Contoso to an external Internet source, it is passed to FOPE,

which performs various outbound filtering operations on the message: edge filtering, virus

scanning, policy enforcement, and spam filtering. If the email passes inspection, it is delivered to

the Internet (as per directive by the mail exchanger record (MX record) where it will reach the

specified recipients. If the email fails inspection, FOPE performs actions on the message

depending upon the outbound configuration settings.

When mail is sent from one member of an organization to another member within the

same organization, where both are using the Microsoft Office 365 Beta service to host

their mailboxes in the cloud, the mail is not filtered by FOPE. Instead, the mail receives

virus filtering provided by Forefront Protection 2010 for Exchange Server (FPE) running

on the Exchange Online data center servers.


Using a shared address space with on-premises relay scenario with Forefront Online Protection

for Exchange (FOPE) refers to when email is hosted partially in the cloud (Internet) and partially

on-premises, and mail flow is controlled on-premises. You can use this scenario when you are

using the Microsoft Office 365 Beta service to host at least some of your organization’s mailboxes

in the cloud.

The shared address space with on-premises relay scenario consists of Microsoft Exchange

Online being provisioned with FOPE. You must configure FOPE connectors to control how mail is

routed within the various available mail flow scenarios (inbound, outbound, and intra-

organizational). You must also configure on-premises Exchange server settings and Exchange

Online data center server settings in order to successfully implement this scenario. This topic

provides diagrams that show how the mail flow scenarios work, followed by the configuration

procedures.

Tip: To view a video that describes this scenario and demonstrates the configuration steps for the

FOPE connectors, see Shared Address Space With On-Premises Relay Scenario.

Note:


11

Inbound Email When receiving inbound email in the cloud, the shared address space with on-premises relay

scenario is as follows:

12

In this example, Contoso has an on-premises solution for email. After purchasing Exchange

Online with FOPE as part of the Office 365 Beta service, Contoso migrates some email to the

cloud (Exchange Online). However, given the highly confidential nature of some of their email

(like the legal department), Contoso decides to leave this email on-premises, thereby enabling

them to maintain greater control over their mail flow, while continuing to take advantage of their

existing on-premises infrastructure. The relationship between the on-premises solution and FOPE

is configured through MX records on the on-premises side, and connectors on the FOPE side.

In such a scenario, when email is sent inbound from an external Internet source to a Contoso

user whose mail is hosted in the Office 365 Beta cloud hosting service, it is delivered on-premises

as per directive by the MX record. The on-premises protection solution, such as Forefront

Protection 2010 for Exchange Server (FPE), performs its functions, like virus scanning, custom

filtering, or archiving. Through an address rewrite, the on-premises protection solution then

redirects the email to FOPE where inbound policy and spam filtering operations are performed on

the message. If the email passes inspection, it is delivered to the specified recipients hosted in

Exchange Online. If the email fails inspection, FOPE performs actions on the message depending

upon the inbound configuration settings.

Outbound email When sending outbound email from the cloud, the shared address space with on-premises relay

scenario is as follows:

13

In this example, an email is sent outbound from a Contoso cloud user to an external Internet

address. Exchange Online sends the mail to FOPE, which performs outbound filtering operations

on the message. FOPE then sends the email to the on-premises server, which performs its own

custom processing on the message before delivering it.

14

Intra-Organizational Email When dealing with intra-organizational (both the sender and the recipients are Office 365 Beta

service customers within the same organization) email, the shared address space with on-

premises relay scenario is as follows:

15

In this example, an email is sent from an on-premises Contoso user to a Contoso user whose

mail is hosted in the Office 365 Betacloud hosting service. The on-premises mailbox sends the

email outbound where custom processing is performed by the on-premises protection solution.

The email is then sent to FOPE, which skips filtering operations, because it is intra-organizational

mail and therefore the custom processing performed by the on-premises protection solution is

considered sufficient. FOPE then delivers the mail to Exchange Online where it can be accessed

by the Contoso cloud user.

In this scenario, the IP address space is securely locked down to only receive email from

the on-premises server, and TLS can be configured so that the email is safe in transit

across the cloud (and also when the reverse occurs, when Exchange Online sends mail

to the on-premises mailboxes).

Configuring a Shared Address Space with On-Premises Relay Scenario To configure a shared address space with on-premises relay scenario, you must configure the

on-premises Exchange server settings, then the Exchange Online data center server settings,

and finally the inbound and outbound FOPE connectors. For more information about how to

perform these configuration steps, see the following topics:

1. Configuring the On-Premises Exchange Server Settings for a Shared Address Space with

On-Premises Relay Scenario

2. Configuring the Exchange Online Settings for a Shared Address Space with On-Premises

Relay Scenario

3. Configuring the FOPE Connectors for a Shared Address Space with On-Premises Relay

Scenario

Configuring the On-Premises Exchange Server Settings for a Shared Address Space with On-Premises Relay Scenario

To successfully implement a shared address space with on-premises relay scenario (for more

information, see Shared Address Space with On-Premises Relay Scenario), you must configure

several on-premises Exchange server settings.

1. Consult the following documentation to see if you need to install and configure Microsoft

Windows PowerShell™ on your on-premises Exchange server: Install and Configure

Windows PowerShell.

Note:



16

2. On the on-premises Exchange server, open the Exchange Management Shell where you can

enter Windows PowerShell commands to configure settings for the on-premises Exchange

server. For more information about accessing and entering Windows PowerShell commands

in the Exchange Management Shell, see Exchange Management Shell Basics.

3. Create a send connector that routes mail destined to your hosted domain towards FOPE. In

this example, the hosted domain is service.contoso.com.

New-sendconnector -Name to-fope -AddressSpaces service.contoso.com -RequireTls $true -

TlsAuthLevel DomainValidation -TlsDomain mail.messaging.microsoft.com

4. Create remote domains that instruct your on-premises server how to treat mail to and from

your hosted domain:

New-RemoteDomain service.contoso.com –DomainName service.contoso.com

New-RemoteDomain contoso.com –DomainName contoso.com

5. Configure the remote domains. These settings instruct your server to treat mail between your

on-premises and hosted domain the same way as mail between two users contained within

your on-premises server, providing a seamless experience for end users:

Set-RemoteDomain service.contoso.com –TrustedMailInboundEnabled $true –

TrustedMailOutboundEnabled $true

Set-RemoteDomain contoso.com –TrustedMailInboundEnabled $true

6. Configure your receive connectors to accept advanced TLS protocols from FOPE:

Set-ReceiveConnector Default –TlsDomainCapabilities

mail.messaging.microsoft.com:AcceptOorgProtocol

7. Record the subject of the certificate your organization uses to authenticate TLS during SMTP

sessions. You will need this value for multiple configuration steps later on. For this example,

we will use a certificate with the subject certificate.contoso.com.

Get-ExchangeCertificate

To continue your configuration of the shared address space with on-premises relay scenario,

move on to the next topic, Configuring the Exchange Online Settings for a Shared Address Space

with On-Premises Relay Scenario.

Related Topics Configuring the Exchange Online Settings for a Shared Address Space with On-Premises Relay

Scenario

Configuring the FOPE Connectors for a Shared Address Space with On-Premises Relay

Scenario


17

Configuring the Exchange Online Settings for a Shared Address Space with On-Premises Relay Scenario

To successfully implement a shared address space with on-premises relay scenario (for more

information, see Shared Address Space with On-Premises Relay Scenario), you must create and

configure remote domains that instruct the Exchange Online data center servers how to interact

with the on-premises mail servers. To accomplish this, on the data center server, you must

access Windows PowerShell where you can create and configure remote domains by entering

Windows PowerShell commands. To learn how to install and configure Windows PowerShell and

connect to the service, see Use Windows PowerShell.

In the following sample commands, contoso.com is the domain name for the on-premises

Exchange server.

1. Configure your accepted domain for your on-premises domain:

Set–Accepteddomain contoso.com –DomainType InternalRelay –OutboundOnly $true

Ensure that as part of provisioning your Exchange Online mailboxes you have

created the shared domain in Exchange Online so that when your cloud mailbox

users send mail it appears to come from contoso.com rather than

service.contoso.com. If you have not provisioned the shared domain, to learn how,

see Manage domains and domain properties.

2. Create a remote domain that instructs the Exchange Online data center servers how to treat

mail being sent to your on-premises domain:

New-remotedomain –Name contoso.com –DomainName contoso.com

3. Create a remote domain that instructs your Exchange Online data center servers how to treat

mail arriving from your on-premises domain. Set the DomainName to be the subject of your

on-premises certificate:

New-remotedomain –Name certificate.contoso.com –DomainName certificate.contoso.com

certificate.contoso.com is the value that was returned when you ran the Get-

ExchangeCertificate command in Configuring the On-Premises Exchange Server

Settings for a Shared Address Space with On-Premises Relay Scenario.

4. Configure the remote domain from step 3. These settings instruct the data center servers to

treat mail between your on-premises server and hosted domain the same way as mail

between two users contained within your hosted domain, providing a seamless experience

for end users:

Set-remotedomain certificate.contoso.com –TrustedMailInboundEnabled $true

Note:

Tip:



18

5. Configure each remote domain in the data center. These settings instruct the data center

servers to mark outbound mail so that your on-premises servers will route the mail correctly.

For example, for the contoso.com remote domain, enter the following command:

Set-remotedomain contoso.com –TrustedMailOutboundEnabled $true

For more information about using Windows PowerShell commands to configure remote domains,

see Remote Domains.

To complete your configuration of the shared address space with on-premises relay scenario,

move on to the next topic, Configuring the FOPE Connectors for a Shared Address Space with

On-Premises Relay Scenario.

Related Topics Configuring the FOPE Connectors for a Shared Address Space with On-Premises Relay

Scenario

Configuring the On-Premises Exchange Server Settings for a Shared Address Space with On-

Premises Relay Scenario

Configuring the FOPE Connectors for a Shared Address Space with On-Premises Relay Scenario

When using FOPE in a shared address space with on-premises relay scenario (for more

information, see Shared Address Space with On-Premises Relay Scenario), the relationship

between the on-premises solution and FOPE is managed with connectors, which you must

configure in the FOPE Administration Center. The following procedures show how to configure

company-wide inbound and outbound connectors in a manner that covers all shared address

space with on-premises relay scenarios (inbound, outbound, and intra-organizational). You must

configure two separate inbound connectors, one that covers inbound mail sent from an external

organization, and another that covers mail sent from within your organization (intra-

organizational). You must also configure an outbound connector.

1. Sign in to the FOPE Administration Center:

a. From your Web browser, go to the Administration Center sign in page:

http://admin.messaging.microsoft.com

b. Type your user name and password, and then click Sign in.

2. In the FOPE Administration Center, click the Administration tab, and then click the

Company tab.

To Configure a FOPE Inbound Connector for a Shared Address Space with On-Premises Relay Scenario (External Mail)


http://admin.messaging.microsoft.com/

19

3. In the Internet endpoint connection settings section, for the Inbound Connectors,

click Add. The Add inbound Connector dialog box opens. The following image shows

inbound connector settings for the shared address space with on-premises relay scenario

when mail is sent inbound to your organization from an external organization.

20

4. In the Name field, enter a descriptive name for the inbound connector.

21

5. In the Description field, enter additional descriptive information about the inbound

connector.

6. Select the Apply this Connector to messages from any source domain check box.

This populates the Source domains field with the *.* wildcard characters, signifying that

this inbound connector will be applied to all domains from which FOPE receives email.

7. In the Source IP addresses field, enter the IP address or addresses for the on-premises

servers (for example, 358.985.57.5). You can use wildcards and Classless Inter-Domain

Routing (CIDR) ranges. Multiple IP addresses must be separated by a comma.

8. Using the check box, specify to Reject messages not originating from these source

IP addresses.

9. In the Message Security section, you can select one of two authentication options:

Opportunistic TLS or Forced TLS.

Selecting Forced TLS enables you to enforce on-premises customers to use a transport

layer security (TLS) connection when sending email to Office 365 Betaservice users

hosted in the cloud. In this scenario, if the connection is not TLS-based, FOPE rejects the

email message. When using this option, you can check Certificate matches domain

and then enter the domain name of the organization with which you want to establish a

secure channel (for example, certificate.contoso.com).

When selecting Opportunistic TLS, FOPE attempts a TLS connection but automatically

rolls over to a SMTP connection if the sending email server is not configured to use TLS.

For more detailed information about using TLS in FOPE, see Transport Layer Security

(TLS).

Warning:

If you are using FOPE as your mail filtering service for your on-premises mail, do

not configure Forced TLS because it may cause mail to be rejected due to

transient TLS failures.

10. In the Internet traffic: Filtering settings section, using the check boxes, you can specify

to skip several filtering operations. For example, you might skip these filtering operations

if you feel that your on-premises protection solution has already adequately performed

these functions and you do not want to double filter your mail.

Skip IP Connection Filtering—Indicates whether to skip IP connection filtering on

inbound emails. This option is not functional for this scenario.

Skip Spam Filtering—Indicates whether to skip spam filtering on inbound emails.

Skip Policy Filtering—Indicates whether to skip policy filtering on inbound emails.

11. Click Save.

The connector is now listed under Inbound Connectors. You can click Edit to change the

configuration settings for this connector.

To apply this connector configuration to your entire company or for specific domains in your

company, or to remove this connector, see Enforcing and Removing FOPE Connector

Associations.

22


Company tab.


click Add. The Add inbound Connector dialog box opens. The following image shows

inbound connector settings for the shared address space with on-premises relay scenario

when mail sent from within your organization (intra-organizational).

To Configure a FOPE Inbound Connector for a Shared Address Space with On-Premises Relay Scenario (Intra-Organizational Mail)

23



connector.

5. In the Source Domains field, enter the domain name for the on-premises server (for

example, contoso.com).

6. In the Source IP addresses field, enter the IP address or addresses for the on-premises

24





Associations.


Company tab.

2. In the Internet endpoint connection settings section, for the Outbound Connectors,

click Add. The Add outbound Connector dialog box opens. The following image shows

outbound connector settings for the shared address space with on-premises relay sample

scenarios.

To Configure a FOPE Outbound Connector for a Shared Address Space with On-Premises Relay Scenario

25

3. In the Name field, enter a descriptive name for the outbound connector.

4. In the Description field, enter additional descriptive information about the outbound

connector.

26

5. Click Apply this Connector to messages that are sent to all destination domains.

This populates the Destination domains field with the *.* wildcard characters, signifying

that this outbound connector will be applied to all domains to which FOPE sends email.

6. Select the Deliver all messages to the following destination check box, and then

specify one of the following options:

IP address—Specify FOPE to route email to a single IP address (for example, the IP

address of the Contoso on-premises email server).

FQDN—Specify the fully qualified domain name to which FOPE should send email

(for example, contoso.com). This should be the DNS entry specified in the MX

record.

Mail Server Multi-SMTP Profiles—Using the drop-down list, select an outbound

profile if you have previously created one. Outbound multi-SMTP profiles enable you

to deliver mail to multiple mail servers in your network by using round-robin load

balancing.

Outbound multi-SMTP profiles work in the same manner, and can be created in a

similar way, as inbound multi-SMTP profiles. For more information, see Inbound

Multi-SMTP Profiles.

7. In the Message Security section, select The certificate domain matches the following

and enter the subject name of the on-premises Exchange certificate (for example,

certificate.contoso.com).

Tip:



Settings for a Shared Address Space with On-Premises Relay Scenario.

Optionally, you can select Opportunistic TLS (FOPE attempts a TLS connection, but

automatically rolls over to a SMTP connection if the receiving email server is not

configured to use TLS) or one of several TLS Certificate Options:

Validation against self-signed certificate—Created within your organization, this

certificate is used to encrypt the channel.

The issuing CA is in the list of trusted CAs—Validates that the recipient certificate

is issued by an authorized certificate authority. For example, it validates that the

certificate is not expired, and that it is authentic.

The certificate domain matches the recipient domain—This takes The issuing

CA is in the list of trusted CAs option one step further by also validating that the

subject alternative name on the certificate matches the recipient domain name. This

option is not functional for this scenario.

The certificate domain matches the following—This takes The issuing CA is in

the list of trusted CAs option one step further by also validating that the subject

alternative name matches what you enter in the text box. This is the recommended

option.

8. Click Save.

27

The connector is now listed under Outbound Connectors. You can click Edit to change the




Associations.

Related Topics Configuring the On-Premises Exchange Server Settings for a Shared Address Space with On-

Premises Relay Scenario

Configuring the Exchange Online Settings for a Shared Address Space with On-Premises Relay

Scenario


An internal mail flow scenario is one where email is hosted in the cloud (in Microsoft Exchange

Online) and in on-premises servers, and both the sender and the recipients are within the same

organization. In this scenario, email is sent between the cloud and on-premises servers without

being sent to the Internet, and FOPE skips all filtering operations.

From an architectural standpoint, this scenario is similar to the Shared Address Space with On-

Premises Relay Scenario intra-organizational scenario, except in this case not all mail is

controlled by the on-premises solution.


FOPE connector, see Internal Mail Flow Scenario.

The following diagram shows a sample internal mail flow scenario where mail is sent from an on-

premises contoso.com user to a service.contoso.com user whose mail is hosted in the Office 365

Beta cloud hosting service.


28

In this scenario, when the on-premises mailbox sends the email outbound there is custom

processing that is performed by the on-premises server. The email is then sent to FOPE, which

skips filtering operations as specified by the inbound connector configuration. FOPE then delivers

the mail to Microsoft Exchange Online where it can be accessed by a user at

service.contoso.com.

29

Configuring the Internal Mail Flow Scenario To configure the internal mail flow scenario, you must first configure the on-premises Exchange

server settings, then the Exchange Online data center server settings, and finally the inbound

FOPE connector. For more information about how to perform these configuration steps, see the

following topics:

1. Configuring the On-Premises Exchange Server Settings for an Internal Mail Flow Scenario

2. Configuring the Exchange Online Settings for an Internal Mail Flow Scenario

3. Configuring the FOPE Connector for an Internal Mail Flow Scenario

Configuring the On-Premises Exchange Server Settings for an Internal Mail Flow Scenario

To successfully implement an Internal mail flow scenario (for more information, see Internal Mail

Flow Scenario), you must configure several on-premises Exchange server settings.

1. Consult the following documentation to see if you need to install and configure Windows

PowerShell on your on-premises Exchange server: Install and Configure Windows

PowerShell.

2. On the on-premises Exchange server, open the Exchange Management Shell where you can

enter Windows PowerShell commands to configure settings for the on-premises Exchange

server. For more information about accessing and entering Windows PowerShell commands

in the Exchange Management Shell, see Exchange Management Shell Basics.

3. Create a send connector that routes mail destined to your hosted domain towards FOPE. In

this example, the hosted domain is service.contoso.com.

New-sendconnector -Name to-fope -AddressSpaces service.contoso.com -RequireTls $true -

TlsAuthLevel DomainValidation -TlsDomain mail.messaging.microsoft.com

4. Create remote domains that instruct your on-premises server how to treat mail to and from

your hosted domain:

New-RemoteDomain service.contoso.com –DomainName service.contoso.com

New-RemoteDomain contoso.com –DomainName contoso.com

5. Configure the remote domains. These settings instruct your server to treat mail between your

on-premises and hosted domain the same way as mail between two users contained within

your on-premises server, providing a seamless experience for end users:

Set-RemoteDomain service.contoso.com –TrustedMailInboundEnabled $true –

TrustedMailOutboundEnabled $true

Set-RemoteDomain contoso.com –TrustedMailInboundEnabled $true

6. Configure your receive connectors to accept advanced TLS protocols from FOPE:




30

Set-ReceiveConnector Default –TlsDomainCapabilities

mail.messaging.microsoft.com:AcceptOorgProtocol

7. Record the subject of the certificate your organization uses to authenticate TLS during SMTP

sessions. You will need this value for multiple configuration steps later on. For this example,

we will use a certificate with the subject certificate.contoso.com.

Get-ExchangeCertificate

The next step in configuring the internal mail control scenario is move onto the next topic,

Configuring the Exchange Online Settings for an Internal Mail Flow Scenario.

Related Topics Internal Mail Flow Scenario

Configuring the Exchange Online Settings for an Internal Mail Flow Scenario

Configuring the FOPE Connector for an Internal Mail Flow Scenario


To successfully implement an internal mail flow scenario (for more information, see Internal Mail

Flow Scenario) for mail between your on-premises servers and hosted email, you must create

remote domains on the Microsoft Exchange Online data center. To do this, you must use

Windows PowerShell. To learn how to install and configure Windows PowerShell and connect to

the service, see Use Windows PowerShell.

In the following sample commands, contoso.com is the domain name for the on-premises

Exchange server.

1. Configure your accepted domain for your on-premises domain:

Set–Accepteddomain contoso.com –DomainType InternalRelay –OutboundOnly $true

Ensure that as part of provisioning your Exchange Online mailboxes you have

created the shared domain in Exchange Online so that when your cloud mailbox

users send mail it appears to come from contoso.com rather than

service.contoso.com. If you have not provisioned the shared domain, to learn how,

see Manage domains and domain properties.

2. Create a remote domain that instructs the Exchange Online data center servers how to treat

mail to your on-premises domain:

New-remotedomain –Name contoso.com –DomainName contoso.com

Note:



31

3. Create a remote domain that instructs your Exchange Online data center servers how to treat

mail from your on-premises domain. Set the DomainName to be the subject of your on-

premises certificate:

New-remotedomain –Name certificate.contoso.com –DomainName certificate.contoso.com



Settings for an Internal Mail Flow Scenario.

4. Configure the remote domain from step 3. These settings instruct the data center servers to

treat mail between your on-premises server and hosted domain the same way as mail

between two users contained within your hosted domain, providing a seamless experience

for end users:

Set-remotedomain certificate.contoso.com –TrustedMailInboundEnabled $true

5. Configure the remote domain from step 2 to mark outbound mail so that your on-premises

servers will route the mail correctly. For example, for the contoso.com remote domain, enter

the following command:

Set-remotedomain contoso.com –TrustedMailOutboundEnabled $true

The next step in configuring your internal mail flow scenario is to move on to the topic,


For more information about using Windows PowerShell commands to configure remote domains,

see Remote Domains.





When using FOPE in an internal mail flow scenario, the relationship between the on-premises

solution and FOPE is managed with the inbound FOPE connector, which you must configure in

the FOPE Administration Center. The following procedure shows how to configure an inbound

connector for the internal mail flow scenario. You do not need to configure an outbound connector

for this scenario.

Tip:

To Configure a FOPE Inbound Connector in an Internal Mail Flow Scenario


32






Company tab.


click Add. The Add inbound Connector dialog box opens.

The following image shows inbound connector settings for the internal mail flow sample

scenario.


34



connector.

6. In the Source Domains field, enter the domain name for the on-premises server (for

example, contoso.com).

7. In the Source IP addresses field, enter the IP addresses or addresses for the on-

premises servers. For example (358.985.57.5). You can use wildcards and Classless

Inter-Domain Routing (CIDR) ranges. Multiple IP addresses must be separated by a

comma.



Selecting Forced TLS enables you to enforce on-premises servers to use a transport

layer security (TLS) connection when sending email to Office 365 Betaservice users

hosted in the cloud. When using this option, you can check Certificate matches domain

and then enter the domain name of the organization with which you want to establish a

secure channel.

When selecting Opportunistic TLS, FOPE attempts a TLS connection, but automatically



(TLS).

Warning:

If you are using FOPE as your mail filtering service for your on-premises mail, do

not configure Forced TLS because it may cause mail to be rejected due to

transient TLS failures.

9. In the Internet traffic: Filtering settings section, select the following check boxes.

Skip IP Connection Filtering—Indicates that you want to skip IP connection filtering

on inbound emails.

Skip Spam Filtering—Indicates that you want to skip spam filtering on inbound

emails. This might result in your organization receiving spam mail if the on-premises

server sends spam mail.

Skip Policy Filtering—Indicates that you want to skip policy filtering on inbound

emails.

10. Click Save.




35


A smart host is a redirecting host server that acts as an intermediate gateway before sending

messages to their final destination. Organizations can set up a scenario where Forefront Online

Protection for Exchange (FOPE) directs all or part of their outbound mail to flow through an on-

premises server that applies additional processing before delivering mail to its final destination. In

this scenario, FOPE is acting as the smart host. An organization might want to do this when they

have an on-premises appliance or other compliance solution, and they also want the benefits of

FOPE edge, virus, policy, and spam filtering.

In this scenario, Contoso has set up a smart host that receives mail from their Microsoft

Exchange Online mail host. Mail travels through the FOPE service to their on-premises server for

further processing prior to delivery to the final destination.


FOPE connector, see Outbound Smart Host Scenario.

Outbound Mail Flow When using FOPE as a smart host that redirects outbound mail to an on-premises server, the

mail flow is as follows:


36

With this scenario, mail flowing from Contoso’s Exchange Online organization first passes

through the FOPE service. Acting as a smart host, FOPE redirects mail to the on-premises server

where additional processing is applied. And then, it is delivered to the Internet.

37

Configuring an Outbound Smart Host In order to configure an outbound smart host, you must create an outbound FOPE connector to

your organization. In this scenario, Contoso is using FOPE as a smart host to redirect outbound

mail through an on-premises server prior to delivery to the Internet.






Company tab.


click Add. The Add outbound Connector dialog box opens.

The following image shows outbound connector settings for the outbound smart host mail

flow sample scenario.

To configure a FOPE outbound connector for an outbound smart host mail flow scenario


38



connector.

39

6. Click Apply this Connector to messages that are sent to all destination domains.

This populates the Destination domains field with the *.* wildcard characters, signifying

that this outbound connector will be applied to all domains to which FOPE sends email.


specify one of the following options:

IP address—Specify FOPE to route email to a single IP address (for example, the IP

address of the Contoso on-premises email server).

FQDN—Specify the fully qualified domain name to which FOPE should send email

(for example, contoso.com). This should be the DNS entry specified in the MX

record.

Mail Server Multi-SMTP Profiles—Using the drop-down list, select the outbound

profile, for example outboundprofile. Outbound multi-SMTP profiles enable you to

deliver mail to multiple mail servers in your network by using round-robin load

balancing.

Outbound multi-SMTP profiles work in the same manner, and can be created in a

similar way, as inbound multi-SMTP profiles. For more information, see Inbound

Multi-SMTP Profiles.

8. In the Message Security section, you can select Opportunistic TLS (FOPE attempts a

TLS connection, but automatically rolls over to a SMTP connection if the receiving email

server is not configured to use TLS) or one of several TLS Certificate Options:

Validation against self-signed certificate—Created within an organization, this


The issuing CA is in the list of trusted CAs—Validates that the recipient certificate


certificate is not expired, and that it is authentic.



subject alternative name on the certificate matches the recipient domain name.



alternative name matches what you enter in the text box.

9. Click Save.





Associations.

40


Organizations can set up a mail flow channel with partners by configuring their inbound mail

routing using Forefront Online Protection for Exchange (FOPE) connectors. You can add a

partner organization’s IP addresses to a ―safe list‖ and mail coming from those specified IP

addresses can be configured to skip FOPE’s spam and policy filters. By adding a partner to a

safe list, you bypass FOPE’s IP filtering service. When you configure their IP address and domain

name with an inbound connector, this ensures that mail from that organization passes through

FOPE IP filtering, even if a partner’s IP address appears on the FOPE block list. Mail that has a

high spam rating that originates from the partner will still be blocked unless you configure the

connector to skip spam filtering as well. Mail that conforms to a policy rule will be blocked as well,

unless you configure the connector to skip policy filtering.

In this scenario, contoso.com added fabrikam.com to their safe list using an inbound connector.

Contoso hosts their mail using Microsoft Exchange Online. The mail passes through FOPE

unfiltered to the Contoso mailboxes.

You can implement this enforcement scenario using an on-premises mail hosting system, a

cross-premises system, or a fully cloud-hosted system. Each system must be provisioned with

FOPE. You can use this architecture when you are using the Microsoft Office 365 Beta service to

host at least some of your organization’s mailboxes in the cloud.


FOPE connector, see Inbound Safe Listing Scenario.

Safe Listing Mail Flow When receiving inbound mail from the safe-listed partner, the architecture is as follows:


41

With this scenario, mail flowing from fabrikam.com’s safe-listed gateway to contoso.com passes

through FOPE without being filtered by FOPE’s edge filtering.

Configuring FOPE Connectors in a Safe-Listing Scenario In order to configure safe listing you must create an inbound connector that specifies the

organization you want to add to a safe list. Following are the settings required for the sample

scenario above. Contoso.com has added fabrikam.com to their safe list using an inbound

connector.





To configure a FOPE inbound connector in a safe-listing flow scenario


42


Company tab.



The following image shows inbound connector settings for the safe-listing mail flow

sample scenario.

43



44

connector.

6. In the Source Domains field, enter the domain name for the organization you want to

add to the safe list (for example, fabrikam.com).

7. In the Source IP addresses field, enter the IP addresses or addresses for the

organization you want to add to the safe list. For example (10.255.255.255). You can use

wildcards and Classless Inter-Domain Routing (CIDR) ranges. Multiple IP addresses

must be separated by a comma.

8. Optionally, you can select the Reject messages not originating from these source IP

addresses check box. This ensures that any mail originating from the source domain

specified in the connector only comes from the source IP address specified in the

connector, which prevents domain name spoofing. If you do not select the Reject

messages not originating from these source IP addresses check box, then the

following two conditions apply.

Mail that comes from the specified IP address will have connector settings applied

(such as Skip Spam Filtering, Skip Policy Filtering and inbound TLS setting).

Mail that comes from an IP address other than the one specified in the connector will

not have any of this connector’s settings applied.



Selecting Forced TLS enables you to force on-premises safe-listed partners to use a

transport layer security (TLS) connection when sending email to Office 365 Betaservice

users hosted in the cloud. In this scenario, if the connection is not TLS-based, FOPE

rejects the email message. When using this option, you can check Certificate matches

domain and then enter the domain name of the organization with which you want to

establish a secure channel (for example, fabrikam.com).

When selecting Opportunistic TLS, FOPE attempts a TLS connection, but automatically



(TLS).

10. In the Internet traffic: Filtering settings section, using the check boxes, you can specify

to skip several filtering operations. If you specify to skip these filters, even mail with a

high spam score, from the safe-listed organization will be permitted.

Skip IP Connection Filtering—Indicates whether to skip IP connection filtering on

inbound emails. Checking this box does nothing in this scenario.

Skip Spam Filtering—Indicates whether to skip spam filtering on inbound emails.

This might result in your organization receiving spam mail if the partner sends spam

mail.

Skip Policy Filtering—Indicates whether to skip policy filtering on inbound emails.

11. Click Save.



45



Associations.


Organizations can set up a secure mail flow channel with trusted partners by configuring their

mail routing using Forefront Online Protection for Exchange (FOPE) connectors. Some business

partners might require an organization to communicate over TLS or sign in using a third-party

validated certificate. Using FOPE connectors, you can configure both forced inbound and

outbound Transport Layer Security (TLS) using self-signed or CA-validated certificates. TLS is a

cryptographic protocol that provides security for communications over the Internet. For more

detailed information about using TLS in FOPE, see Transport Layer Security (TLS).

In this scenario, contoso.com has set up a secure mail routing channel with fabrikambank.com.

Contoso uses a Microsoft Exchange Online cloud-hosted mail solution to host their mailboxes.

When they exchange mail with Fabrikam Bank, the mail is secure through TLS encryption in both

directions.

You can implement this enforcement scenario for mailboxes that use the Microsoft Office 365

Beta service to host your organization’s mailboxes in the cloud.


FOPE connectors, see Regulated Partner With Forced TLS Scenario.

Bi-Directional Mail Flow When receiving inbound or outbound mail in the cloud, the regulated partner architecture is as

follows:


46

With this scenario, mail flowing between Contoso’s Exchange Online organization and Fabrikam

are transferred over a secure wire using forced inbound and outbound TLS. Furthermore, all mail

between the two organizations is validated using a CA certificate.

Configuring a Regulated Partner To configure a regulated partner relationship, you must create inbound and outbound FOPE

connectors.






Company tab.

To configure a FOPE inbound connector for a regulated partner


47



The following image shows inbound connector settings for the regulated partner with

forced TLS sample scenario.

48



49

connector.

6. In the Source Domains text box enter the domain name of the organization for which

you want to establish a secure channel, for example fabrikambank.com.

7. In the Source IP addresses field, enter the IP address or addresses for the partner. For

example (358.985.57.5). You can use wildcards and Classless Inter-Domain Routing

(CIDR) ranges. Multiple IP addresses must be separated by a comma.

8. Using the check box, specify to Reject messages not originating from these source

IP addresses.

9. In the Message Security section, select Forced TLS.


(TLS).

10. Click Save.





Associations.


Company tab.


click Add. The Add outbound Connector dialog box opens.

The following image shows outbound connector settings for the regulated partner with

forced TLS sample scenario.

To configure a FOPE outbound connector in a regulated partner scenario

50



connector.

51

5. In the Destination domains text box enter the domain name for the organization with

which you want to establish a secure channel.


specify FQDN, Here you specify the fully qualified domain name to which FOPE should

send email (for example, fabrikambank.com). This should be the DNS entry specified in

the MX record.

7. In the Message Security section, you can select one of several TLS Certificate

Options:

Validation against self-signed certificate—Created within an organization, this


The issuing CA is in the list of trusted Cas—Validates that the recipient certificate


certificate is not expired and that it is authentic.



subject alternative name on the certificate matches the recipient domain name.



alternative name on the certificate matches what you entered in the text box.

8. Click Save.





Associations.


After configuring the Forefront Online Protection for Exchange (FOPE) connectors for use in a

complex mail flow scenario, in order for them to be functional, you must enforce (associate) them

at the company or domain level. You can remove this association at any time; however, once a

connector is in use at the domain level, it cannot be removed at the company level without first

being removed at the domain level.

Related Topics Enforcing FOPE Connector Associations

Conflicts When Enforcing a Connector Association

52

Removing Connector Associations


Enforcing FOPE Connector Associations

You can enforce Forefront Online Protection for Exchange (FOPE) connector associations at the

company level (for all domains) or for specific domains. You can enforce multiple inbound and

outbound connectors as long as they do not conflict with each other.


Company tab.

2. In the Internet endpoint connection settings section, to apply a connector

configuration for all domains within your company, next to the connector name, click

Enforce.

3. In the Enforce Inbound Connector or Enforce Outbound Connector dialog box, select

the check box confirming that you want to associate this connector with all the domains in

your company, and then click OK.


Domains tab.

2. Select the domain for which you want to enforce the FOPE connector.

3. In the Internet endpoint connection settings section, next to Inbound Connectors or

Outbound Connectors, click Select.

4. In the Select Inbound Connector or Select Outbound Connector dialog box, using the

Name drop-down list, select the connector that you want to enforce with the domain.

5. Review the connector details to confirm that the connector configuration settings are

correct, and then click Save.

Related Topics Conflicts When Enforcing a Connector Association


To enforce a FOPE connector at the company level

To enforce a FOPE connector for a specific domain

53

Conflicts When Enforcing a Connector Association

If there is a conflict between Forefront Online Protection for Exchange (FOPE) connectors, for

example if two inbound connectors specify the same source domain, then they cannot be

enforced (associated) with a company or domain. In this scenario, when trying to enforce a

connector, you will receive an error message with a link to more information. When you click the

results link, the Scope validation report opens providing more specific information about the

nature of the conflict.




You can remove a Forefront Online Protection for Exchange (FOPE) connector association at any

time; however, if a connector is in use (enforced) with a domain, it cannot be removed at the

company level without first being removed at the domain level.


Domains tab.

2. Select a domain for which you want to remove the FOPE connector.

3. In the Internet endpoint connection settings section, next to the connector name, click

Remove, and then click OK to confirm that you want to remove the connector for this

domain.

4. Repeat steps 2 and 3 if you want to remove the FOPE connector from additional

domains.

5. After you have removed all domain-level connector associations, if you want to remove

the connector for all company-wide associations, click the Company tab.

6. In the Internet endpoint connection settings section, next to the connector name, click

Remove, and then click OK to confirm that you want to remove the connector for this

company.


To remove a FOPE connector

54


You view information about FOPE connectors the same way you view information about other

items in the FOPE Admin Center. You can view connector information in reports, using the My

Reports tab, you can trace connector activity by viewing the Message Trace Summary page,

and you view connector activity in audit trails by viewing the Audit Trails sub tab on the Tools

tab.

Viewing Connector Reports On the My Reports tab, you can view saved reports or create new reports for your connectors.

The connector reports render in normal FOPE reports in a Connectors section. For information

about how to create, modify or delete a report, see Create, Modify, or Delete a Report.

When you view a report that shows inbound and outbound traffic, FOPE also reports on the

connector traffic.

When inbound or outbound connectors are applied to email traffic, hyperlinked numbers will

appear in the report in the Connectors section under Applied or Rejected. To view more

information about the connector settings that were applied to those emails and to see a detailed

report, click the hyperlinked number in the report. The detailed report that appears provides the

following information:

Log Time—The time that the connector was applied to the email.

Sender Address—The address of the sender of the email.

Recipient Address—The address of the intended recipient of the email

Connector ID—The unique ID of the connector that was assigned when it was created.

Connector Settings—A description of the connector settings.

Viewing Connector Trace Activity You can trace connector activity using the FOPE tracing feature found on the Tools tab in the

Admin Center. For information about how to run a message trace, see Run a Message Trace.

By following the instructions to trace a message, you can view results for traced messages in the

Results pane of the Tools tab. When you click the Details… link next to a traced message you

will see the message trace summary for that email. On the Message Trace Summary page, the

results for the message trace appear, including a column that reports the Connector Results for

that traced message. The image below shows the connector results for a traced message. The

results report the Type, Name and ID Number of the connector that was applied to the message.

55

Viewing Audit Trails To view audit trail information for connectors, you use the Audit Trail sub tab on the Tools Tab in

the FOPE Admin Center. For information about how to view an audit trail, see View the Audit

Trail.

Information about connectors that are applied to messages appear in the audit trail along with all

other traffic reporting. The following information will appear in the audit trail for messages where a

connector setting was applied:

User E-mail—The user e-mail for the message that had a connector applied.

Domain—The domain in which the connector is in force.

Activity—The name and ID number of the connector that was applied to a message.

Date and Time—The date and time when the connector enforcement took place.

Microsoft Office 365 Beta Features - IT Solutions - IT Solution

Documents

Transcript of Microsoft Office 365 Beta Features - IT Solutions - IT Solution