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
Correct Answer: A
Explanation/Reference:
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 self-signed 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 selfsigned 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:certificatesExportedCert.pfx -Encoding byte -ReadCount 0)) -Password:(Get-Credential).password
