###BeginCaseStudy###
Testlet 1
Topic 1, Fabrikam, Inc
Overview
Fabrikam, Inc., is a pharmaceutical company located in Europe. The company has 5,000 users.
The company is finalizing plans to deploy an Exchange Server 2013 organization.
The company has offices in Paris and Amsterdam.
Existing Environment
Active Directory Environment
The network contains an Active Directory domain named fabrikam.com. An Active Directory
site exists for each office.
Network Infrastructure
The roles and location of each server are configured as shown in the following table.

Client computers run either Windows 7 or Windows 8 and have Microsoft Office 2010 installed.
The Paris office uses the 192.168.1.0/24 IP range. The Amsterdam office uses the 192.168.2.0/24 IP range.
The offices connect to each other by using a high-speed, low-latency WAN link. Each office has a 10-Mbps
connection to the Internet.
Planned Exchange Infrastructure
The company plans to deploy five servers that run Exchange Server. The servers will be configured as shown
in the following table.

The company plans to have mailbox databases replicated in database availability groups (DAGs). The mailbox
databases and DAGs will be configured as shown in the following table.

DAG1 will use FS1 as a file share witness. DAG2 will use FS3 as a file share witness.
You plan to create the following networks on each DAG:
A dedicated replication network named DAGNET1
A MAPI network named DAGNET2
All replication traffic will run on DAGNET1. All client connections will run on DAGNET2. Client connections must
never occur on DAGNET1. Replication traffic must only occur on DAGNET2 if DAGNET1 is unavailable.
Each Exchange Server 2013 Mailbox server will be configured to have two network adapters.
The following two mailbox databases will not be replicated as part of the DAGs:
A mailbox database named AccountingDB that is hosted on EX1
A mailbox database named TempStaffDB that is hosted on EX4EDGE1 will have an Edge Subscription configured, with both EX1 and EX2 as targets.
Requirements
Planned Changes
An external consultant reviews the Exchange Server 2013 deployment plan and identifies the following areas of
concern:
The DAGs will not be monitored.
Multiple Edge Transport servers are required to prevent the potential for a single point of failure.
Technical Requirements
Fabrikam must meet the following technical requirements:
Email must be evaluated for SPAM before the email enters the internal network.
Production system patching must minimize downtime to achieve the highest possible service to users.
Users must be able to use the Exchange Control Panel to autonomously join and disjoin their department’s
distribution lists.
Users must be able to access all Internet-facing Exchange Server services by using the names of
mail.fabrikam.com and autodiscover.fabrikam.com.
The company establishes a partnership with another company named A. Datum Corporation. A Datum uses the SMTP suffix adatum.com for all email addresses. Fabrikam plans to exchange sensitive information with A.
Datum and requires that the email messages sent between the two companies be encrypted. The solution must
use Domain Security.
Users in the research and development (R&D) department must be able to view only the mailboxes of the users
in their department from Microsoft Outlook. The users in all of the other departments must be prevented from
viewing the mailboxes of the R&D users from Outlook.
Administrators plan to produce HTML reports that contain information about recent status changes to the
mailbox databases.
Fabrikam is evaluating whether to abort its plan to implement an Exchange Server 2010 Edge Transport server
and to implement a Client Access server in the Paris office instead. The Client Access server will have antispam agents installed.
###EndCaseStudy###

You are testing the planned implementation of Domain Security. You discover that users fail to exchange
domain-secured email messages.
You open the Exchange Management Shell and discover the output shown in the exhibit. (Click the Exhibit
button.)

You need to ensure that users can exchange email messages by using Domain Security.
Which two parameters should you modify by using the Set-SendConnector cmdlet? (Each correct answer
presents part of the solution. Choose two.)

A.
tlsauthlevel

B.
requiretls

C.
ignorestarttls

D.
tlsdomain

E.
domainsecureenabled

F.
smarthostauthmechanism

Explanation:
Domain Security
Domain Security is a feature of Exchange Server (both 2010 and 2013) that can secure SMTP traffic between
two Exchange organizations.
It is implemented on server level, and it works without configuring any options on user (sender or recipient)
side. Domain Security uses mutual TLS authentication to provide session-based authentication and encryption.
Mutual TLS authentication is different from TLS as it’s usually implemented. Usually, when you implement TLS,
client will verify the server certificate, and authenticate the server, before establishing a connection.
With mutual TLS authentication, each server verifies the connection with the other server by validating a
certificate that’s provided by that other server, so clients are not included at all.
We establish secure SMTP channel between two Exchange Servers, usually over the Internet.
Clients, Outlook and Outlook Web App, will be aware that Domain Security is established.
Green icon with check mark will be shown on each messages exchanged between servers on which Domain
Security is implemented.
Set-SendConnector
Use the Set-SendConnector cmdlet to modify a Send connector.
EXAMPLE 1
This example makes the following configuration changes to the Send connector named Contoso.com Send
Connector:
Sets the maximum message size limit to 10 MB.
Changes the connection inactivity time-out to 15 minutes.
Set-SendConnector “Contoso.com Send Connector” -MaxMessageSize 10MB -ConnectionInactivityTimeOut
00:15:00
PARAMETERS
Requiretls
The RequireTLS parameter specifies whether all messages sent through this connector must be transmitted
using TLS. The default value is $false.
Domainsecureenabled
The DomainSecureEnabled parameter is part of the process to enable mutual Transport Layer Security (TLS)
authentication for the domains serviced by this Send connector. Mutual TLS authentication functions correctly
only when the following conditions are met:
The value of the DomainSecureEnabled parameter must be $true.
The value of the DNSRoutingEnabled parameter must be $true.
The value of the IgnoreStartTLS parameter must be $false.
The wildcard character (*) is not supported in domains that are configured for mutual TLS authentication. The
same domain must also be defined on the corresponding Receive connector and in the
TLSReceiveDomainSecureList attribute of the transport configuration.
The default value for the DomainSecureEnabled parameter is $false for the following types of Send connectors:
All Send connectors defined in the Transport service on a Mailbox server.
User-created Send connectors defined on an Edge server.
The default value for the DomainSecureEnabled parameter is $true for default Send connectors defined on an
Edge server.
NOT TLSAUTHLEVEL
The TlsAuthLevel parameter specifies the TLS authentication level that is used for outbound TLS connections
established by this Send connector. Valid values are:
EncryptionOnly: TLS is used only to encrypt the communication channel. No certificate authentication is
performed.
CertificateValidation: TLS is used to encrypt the channel and certificate chain validation and revocation lists
checks are performed.
DomainValidation: In addition to channel encryption and certificate validation, the Send connector also verifies
that the FQDN of the target certificate matches the domain specified in the TlsDomain parameter. If no domain
is specified in the TlsDomain parameter, the FQDN on the certificate is compared with the recipient’s domain.
You can’t specify a value for this parameter if the IgnoreSTARTTLS parameter is set to $true, or if the
RequireTLS parameter is set to $false.
NOT ignorestarttls
The IgnoreSTARTTLS parameter specifies whether to ignore the StartTLS option offered by a remote sending
server.
This parameter is used with remote domains. This parameter must be set to $false if the RequireTLSparameter is set to $true. Valid values for this parameter are $true or $false.
NOT tlsdomain The TlsDomain parameter specifies the domain name that the Send connector uses to verify
the FQDN of the target certificate when establishing a TLS secured connection.
This parameter is used only if the TlsAuthLevel parameter is set to DomainValidation.
A value for this parameter is required if:
The TLSAuthLevel parameter is set to DomainValidation.
The DNSRoutingEnabled parameter is set to $false (smart host Send connector).
NOT smarthostauthmechanism
The SmartHostAuthMechanism parameter specifies the smart host authentication mechanism to use for
authentication with a remote server.
Use this parameter only when a smart host is configured and the DNSRoutingEnabled parameter is set to
$false.
Valid values are None, BasicAuth, BasicAuthRequireTLS, ExchangeServer, and ExternalAuthoritative.
All values are mutually exclusive. If you select BasicAuth or BasicAuthRequireTLS, you must use the
AuthenticationCredential parameter to specify the authentication credential.
TLS Functionality and Related Terminology: Exchange 2013 Help