Client Access Server Role

Mailscape Functionality Help > Client Access Server Role

Common Issues

Possible Solutions

OWA status resu

Skipped – The test was unable to test the internal URL of this virtual directory. This occurred because the internal URL property is not set. 

 

 

 

Skipped – The test was unable to log on Outlook Web Access because of authentication failure.

 

 

 

Failure – The test was unable to log on to Outlook Web Access because the SSL certificate did not validate

 

 

 

 

 

 

 

 

 

 

Failure – The test cannot proceed because the test URL is not secure, and because the authentication method that is supported by the virtual directory (FBA) will result in mailbox credentials being transmitted across the network in plain text.

 

 

 

 

 

 

 

 

 

Run the following cmdlet from your Exchange Management Shell: 

Get-OWAVirtualDirectory | fl Identity, *URL*

If the output of the InternalURL and ExternalURL is $NULL or Blank you should set this options according to your infrastructure, for example if the server name is MAIL1 and you usemail.domain.com to access OWA, you should set the Internal and ExternalURL as mail.domain.com.

 

Mailscape periodically needs to run the following CMDlet to reset the test credentials for the OWA health check: Test-OwaConnectivity -ResetTestAccountCredentials -MailboxServer <MAILBOX_SERVER_NAME>

 

Check the exchange certificate implemented into the Client Access Servers, this certificate must have all the names of your exchange environment, this mean, all the CAS servers, HUB transport, UM servers, Mailboxes and the virtual name of your solution i.e, mail.domain.com

Use a SAN certificate with all the names, you can use the certificate from Digicert.com or Godaddy.com

You must have your IIS Virtual Directories pointing to the right name of you servers, this is done by setting the InternalURL and ExternalURL from all the OWA, OAB, Exchange Web Services, Active Sync, Unified Messaging and Autodiscover. To see if you have it or not, run the following cmdlet: Get-OWAVirtualDirectory | fl Identity, *URL*

 

By default when you install Exchange 2007/2010, it generates a self-signed certificate to be used with OWA and ActiveSync (this does not apply to Outlook Anywhere). The username/password information will be sent through the network in plaintext format and any network monitor tool can sniff that out and see the username/password. That is why Exchange has a self-signed certificate and all of the test cmdlets are made to be used at a higher level of security.  Please review the following Microsoft articles:

http://technet.microsoft.com/en-us/library/bb400931(EXCHG.80).aspx

http://technet.microsoft.com/en-us/library/aa998849(EXCHG.80).aspx

http://technet.microsoft.com/en-us/library/aa998359(EXCHG.80).aspx

 

 

 

ActiveSync status resul

Failure – The underlying connection was closed: Could not establish trust relationship for the SSL/TLS  secure channel. Inner error [System.Security.Authentication.AuthenticationException]: The remote certificate is invalid According to the validation procedure. 

This problem happens when your certificate used in Client Access Server is expired you don’t trust to the root CA that issued this certificate. To check it open up your certificate from Internet Explorer or MMC and check if it is expired or if your server knows the root CA.  Please efer to the following URL to check the Root CA http://www.isaserver.org/img/upl/exchangekit/importrootca/importrootca.htm  

Outlook Anywhere status result 

 

1013 Error – When contacting https://webmail.yourdomain.com/EWS/Exchagne.asmx received the error The request failed with HTTP status 401: Unauthorized.

AS Service Error – [EXPR] –Error when contacting the AS service ashttps://webmail1.yourdomain.com/EWS/Exchange/asmx. The elapsed time was 15 milliseconds

We would suggest taking a look at the following KB article as a possible work around to the 1013 error:http://support.microsoft.com/default.aspx?scid=kb;en-us;896861.  

 

<<back to Mailscape Functionality Help