Which cmdlet should you run?

You have an Exchange Server 2010 organization. All users connect to their mailbox by using
Microsoft Outlook 2013 and Outlook Web App. All client connections to Exchange Server use the
name mail.contoso.com. You deploy Exchange Server 2013 to the organization, you move all of the
users to Exchange Server 2013, and then you decommission all of the Exchange Server 2010 servers.
The users report that when they open Outlook 2013, they receive a certificate warning message. The
users do not receive a certificate error message or a certificate warning message when they open
Outlook Web App. You need to prevent the certificate warning message from occurring when the
users open Outlook 2013. Which cmdlet should you run?

A.
Set-ClientAccessServer

B.
New-ExchangeCertficiate

C.
New-ClientAccessArray

D.
Import-ExchangeCertificate

Explanation:
UNABLE TO ASSOCIATE SET-CLIENTACCESSSERVER WITH CERTIFICATE ERROR
D LOOKS LIKE A BETTER RESPONSE.
IMPORT THE SSL CERTIFICATE AND THEN ASSIGN IT TO OUTLOOK 2013
Self-signed Certificate
When you install Exchange 2013, a self-signed certificate is automatically configured on the Mailbox
servers. A self-signed certificate is signed by the application that created it. The subject and the
name of the certificate match. The issuer and the subject are defined on the certificate. This selfsigned certificate is used to encrypt communications between the Client Access server and the
Mailbox server. The Client Access server trusts the self-signed certificate on the Mailbox server
automatically, so no third-party certificate is needed on the Mailbox server. When you install
Exchange 2013, a self-signed certificate is also created on the Client Access server.
This self-signed certificate will allow some client protocols to use SSL for their communications.
Exchange
ActiveSync and Outlook Web App can establish an SSL connection by using a self-signed certificate.
Outlook Anywhere won’t work with a self-signed certificate on the Client Access server. Self-signed
certificates must be manually copied to the trusted root certificate store on the client computer or
mobile device. When a client connects to a server over SSL and the server presents a self-signed
certificate, the client will be prompted to verify that the certificate was issued by a trusted authority.
The client must explicitly trust the issuing authority. If the client confirms the trust, then SSL
communications can continue.
Note:

By default, the digital certificate installed on the Mailbox server or servers is a self-signed certificate.
You don’t need to replace the self-signed certificate on the Mailbox servers in your organization with
a trusted third-party certificate. The Client Access server automatically trusts the self-signed
certificate on the Mailbox server and no other configuration is needed for certificates on the Mailbox
server.
Outlook 2013
When connecting to an Exchange server using Outlook 2013 you may encounter an SSL trust error.

This error occurs when the Exchange server is configured with a self-signed SSL certificate.

Outlook makes connections to the Exchange server over HTTPS and therefore must trust the SSL
certificate that is configured on the server, otherwise it will display those error messages to the end
user.
To resolve the issue install a valid SSL certificate on the Exchange server from a trusted certificate
authority.
See Exchange Server 2013 SSL certificates for more details on this as well as step by step
instructions.
A
Set-ClientAccessServer
Use the Set-ClientAccessServer cmdlet to set properties on specified Client Access server objects.
For information about the parameter sets in the Syntax section below, see Syntax.
EXAMPLE 1
This example sets two properties on the Client Access server CAS-01.
Set-ClientAccessServer -Identity “CAS-01” -AutoDiscoverServiceInternalUri
“https://cas01.contoso.com/autodiscover/autodiscover.xml” -AutoDiscoverSiteScope “Mail”
EXAMPLE 2
This example sets two properties on the Client Access server CASMail.
Set-ClientAccessServer -Identity “CASMail” -AutoDiscoverServiceInternalUri
“https://casmail.contoso.com/
autodiscover/autodiscover.xml” -AutoDiscoverSiteScope “Mail”
NOT B
New-ExchangeCertficiate
Not an Exchange 2013 command or any other Exchange version command
NOT C
Exchange 2010 command
Use the New-ClientAccessArray cmdlet to create an object that represents a load balanced array of
Client Access servers within a single Active Directory site.
EXAMPLE 1
This example creates the Client Access server array server.contoso.com.
New-ClientAccessArray -Fqdn server.contoso.com -Site “Redmond” -Name “server.contoso.com”
NOT D
Exchange 2013 command
Use the Import-ExchangeCertificate cmdlet to import a certificate or chain of certificates.
For information about the parameter sets in the Syntax section below, see Syntax.
EXAMPLE 1
This example imports an existing certificate and private key from the PKCS #12 file ExportedCert.pfx.
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\certificates\ExportedCert.pfx Encoding
byte -ReadCount 0)) -Password:(Get-Credential).password