How should I use the information in this article?

You should review the following information and try the various suggestions that might apply.

For suggested combinations that fail, you should use the options presented by Sync'Em to capture diagnostic information.

If you've used all the suggestions that seem to apply and are still unsuccessful, then use the options presented by Sync'Em to create a support ticket and we'll try to help.

"Special" Characters in Passwords

We've seen multiple cases where certain "special" characters will not work in a password (e.g., !?#$~). We know that Sync'Em handles this and have even seen examples where we can access a given account with such a password character, but someone else can't do exactly the same from their system. We assume this has something to do with character-set settings either when using a different browser and/or international OS X and/or Windows Server versions (we mostly test with Safari and Firefox).

If you're having problems and your password includes "special" characters (e.g., !?#$~), you can try changing it (temporarily) to include only alphabetic and number characters (and maybe different "special" characters if they're required by your password policy) to see whether that's the issue.

For org.apache.axis2.AxisFault: Transport error: 401 Error: Unauthorized.

A 401 error indicates that you most likely got connected to an Exchange server, but it would not authorize you with the information provided — i.e., it's not the correct WS Username/WS Password/Windows Domain combination.

You'll need to find the correct WS Username/WS Password/Windows Domain combination to get past a 401 error. If you don't know your Windows Domain, see the FAQ that may help you determine your Windows Domain.

The "Special" Characters in Passwords section, above, may apply.

Some servers are also configured to require the email address as the username (e.g., itsme@mycompany.com).

There's also a smaller possibility that, 'though it got connected to a server, it's still the wrong server for accessing your account via EWS (Exchange Web Services).

Often the easiest/only way to resolve this issue is to ask the Exchange-server Administrator (or service supplier) as suggested in the Asking About EWS (Exchange Web Services) Support section at the bottom of this article.

Athough a 401 error implies that you're hitting a server that's responding, even if you think you've tried all combinations of WS Username/WS Password/Windows Domain that could apply, you should still ask your Exchange-server Administrator (or service supplier) about the Exchange Server Address/URL, just to be sure (since Windows servers can be configured in many different ways).

For org.apache.axis2.AxisFault: Transport error: 403 Error: Forbidden.

A 403 error indicates that the server (IIS security) isn't allowing access to the EWS (Exchange Web Services) URL — i.e., either EWS is not enabled or there's some other sort of security/access restriction (e.g., a single-sign-on mechanism that hides the standard authentication mechanism).

Technically, SyncEm uses Microsoft's interfaces to interact with the Exchange Server via EWS using SOAP requests (e.g., makes SOAP requests to
https://<the-exchange-server-address>/EWS/Exchange.asmx).

Often the easiest/only way to resolve this issue is to ask the Exchange-server Administrator (or service supplier) as suggested in the Asking About EWS (Exchange Web Services) Support section at the bottom of this article.

For org.apache.axis2.AxisFault: Transport error: 404 Error: Not Found.
–or–
org.apache.axis2.AxisFault: <The-Exchange-Server-Address-You-Entered>.

This indicates one or more of the following:

• the Exchange Server Address is incorrect
• only one of the modes for "Only use secure connection" is supported by the server (i.e., either SSL or non-SSL)
• the Exchange Server does not have WS (Web Services) enabled (or access is "silently" denied)

Try both checked and unchecked settings for "Only use secure connection" to see whether one setting avoids the 404 error.

In addition (and possibly in combination) try different Exchange Server Address entries.

If you can access the Exchange server via OWA (Outlook Web Access) you can try getting the Exchange Server Address from the URL that's shown in the web browser's address bar — the server address is the part of the URL between the "//" characters and the next "/" character; e.g., if the URL was https://exchange.mycompany.com/EWS, then the Exchange Server Address would be exchange.mycompany.com and that's what you'd enter in the Sync'Em Exchange Account setup.

There are 3 such addresses you should try for the Exchange Server Address:

• the address from the URL that you're given to access OWA
• if it's different from the URL above, the address from the URL that's shown while at the OWA login page
• the address from the URL that's shown once you're logged in via OWA

One way to test to see whether WS is enabled is to use your web browser to try to visit the page (replace the "<the-...-access>" portion):
http://<the-exchange-server's-address-you-use-for-OWA-access>/ews/

If you get a login prompt, that likely means that WS is enabled on that Exchange server. If you get a denied directory listing message (or get a login prompt then attempt to login and get denied), that may mean that WS is enabled on that Exchange server but it's denying access to the directory and/or its contents.

Often the easiest/only way to resolve this issue is to ask the Exchange-server Administrator (or service supplier) as suggested in the Asking About EWS (Exchange Web Services) Support section at the bottom of this article.

For org.apache.axis2.AxisFault: Transport error: 440 Error: Login Timeout.

A 440 Timeout error indicates that, while attempting to log in, there was no response from the Exchange server within 30 seconds.

This generally implies that you are finding a server that wants a login. The first thing to do is to try again as it is possible that the server was just very busy and didn't respond quickly enough.

Another thing to try is to reverse the setting of the "Use this Mac's proxy setup" option for the Exchange account.

If this continues, you should ask the Exchange-server Administrator (or service supplier) as suggested in the Asking About EWS (Exchange Web Services) Support section at the bottom of this article.

For org.apache.axis2.AxisFault: Exchange Web Services are not currently
available for this mailbox because it could not determine the Client
Access Services Server to use for the mailbox.

This probably means that Exchange Web Services are either not enabled or that your account does not have access to them, but not always.

You'll need to ask the Exchange-server Administrator (or service supplier) as suggested in the Asking About EWS (Exchange Web Services) Support section at the bottom of this article.

For org.apache.axis2.AxisFault: Connection has been shutdown ...

This indicates that there's a problem with the server's certificate. In most cases the "problem" will be either that the certificate is "self-signed" (i.e., is issued by the organization that runs the server, not a certificate-issuing company) or that the certificate has expired.

Sync'Em provides Exchange Access setup options to accept self-signed and/or expired certificates. First, try enabling the option to accept a self-signed certificate. Next try enabling the option to accept an expired certificate. try enabling both these options.

It's quite common for organizations to use self-signed certificates and, generally, this should not be a concern. It's less common for an organization to use an expired certificate, but it does happen. Again, as long as you're getting connected to your Exchange account, this is generally not a concern. If in doubt about the server's certificate validity, you should ask the Exchange-server admin (or service supplier).

If both options are checked and you're still getting this error, you'll need to ask the Exchange-server Administrator (or service supplier) why you would be getting this error. If they don't know, or say you shouldn't, please use Sync'Em options to capture the diagnostic information and create a support ticket.

For org.apache.axis2.AxisFault: No route to host.

This means that you're Mac's networking setup isn't configured for proper access to the Internet or you're currently not connected or unable to connect to the Internet (e.g., loss of wireless signal and/or network cable unplugged).

Asking About EWS (Exchange Web Services) Support

Because the access to an Exchange server can be affected by many different server and security configuration factors, it may be necessary to ask the Exchange-server admin (or service supplier) how you can access your Exchange server via EWS.

For some setups, this will be the only way to be absolutely sure whether EWS access is available and how to get to it. If you have knowledgeable and accessible support, this is often the easiest/only way to get this information.

We suggest asking the following question:
What is the the Windows domain and the URL that I can use to access the Exchange server via EWS (Exchange Web Services) CAS (Client Access Services) for my Exchange account <give-your-email-address> (note: this is EWA, not OWA, and will likely end with .../EWS/Exchange.asmx)?

One you have the URL, you get the Exchange Server Address from the URL — the server's address is the part part of the URL between the "//" characters and the next "/" character; e.g., if the URL was https://exchange.mycompany.com/EWS, then the Exchange Server Address would be exchange.mycompany.com and that's what you'd enter in the Sync'Em Exchange Account setup.

Important: If the URL you are given is not of the format
https://<Some-Exchange-Server-Address>/EWS/
or
https://<Some-Exchange-Server-Address>/EWS/
then send the URL to us so we can help.