Despite all the bells and whistles around Unified Endpoint Management (UEM), reliable access to the user’s mailbox on the go remains a critical function almost everyone depends on. As such, swift action must be taken as soon as issues such as the one shown below are reported:

There are numerous possibilities for this error to occur.

• Data roaming under Settings -> Cellular -> Cellular Data Options is enabled
• Mail under Settings -> Cellular -> CELLULAR DATA is disabled
• The password is not set for the mailbox within Settings -> Passwords & Accounts (i.e. after changing AD password and Kerberos Constrained Delegation is not setup)

A quick search in VMware Workspace ONE site reveals other possible solutions:

While this post is specifically written based on an environment with Secure Email Gateway (SEG) setup, some of the common areas to review as part of our troubleshooting process should apply even if you don’t have SEG. You may also consult the Mobile Email Management (MEM) Troubleshooting Guide

Before diving deeper, let’s begin by identifying the scope of the issue.

• How many users are affected?
  • A single user who experiences this issue might not require all hands on deck unless of course s/he is a VIP (i.e. C-Level executive.)
• Any specific OS (iOS or Android) and/or version is having the issue?
  • iOS is known to introduce new challenges (or headaches) for admins infrequently.
  • It could also be as ridiculous as having an older version of iOS installed. Updating it may resolve the issue.
• Does it occur only over cellular or Wi-Fi connection? Or both?
  • Did someone forget to pay the cellular bill?

In an environment with SEG setup, here’s the communication flow you should be familiar with (credit again goes to VMware support):

Email policies update on SEG:

1. Admin performs run compliance or SEG requests policies on a defined interval
2. Integration Service sends policy refresh command via Airwatch API to get policy information from the database.
3. The database would run a GET function, and the result of the sprocs would be provided back to Integration Service using another API call.
4. Integration Service then loads the policies in SEG cache.

Device receiving Email:

1. Device requests emails from Web Listener endpoint on SEG
2. Web Listener talks to Integration Service to find out if the device is compliant by email policies
3. If the device is compliant, Web Listener mail request if directed (proxied) to the email server
4. Email server hands over mail response to Web Listener
5. Web Listener hands over mail response to the device

Now that you have a general idea of your battle, here are some common areas to check.

Number 1: Make sure the SEG URL is accessible both internally and externally.

Example: https://mail.public_dns_of_seg.com/microsoft-server-activesync

You should be prompted for username and password. If not, there’s a communication issue that must be addressed.

Number 2: Test mobile email management configuration within the web console.

I’m sharing the details below which I obtained from a ticket opened with VMware Workspace ONE support. As of this writing, there is no KB for this info.

During this Test Connection, six different checks are performed.

Test Connection result from the web to SEG

This check ensures the SEG is accessible from outside the network. While these checks are performed from the AirWatch Console server, they must be valid for all devices connecting to the SEG.

Hostname found

This check confirms that the external hostname specified for the SEG server is resolved to an IP address. A simple variation of this test is to use the command prompt from a computer outside the domain to issue a command and confirm the hostname resolves correctly.

 nslookup <seghost>

SSL Certificate from the web to SEG valid

This check confirms the SSL certificate bound to the SEG server is properly configured. Some common reasons for an occurrence of failure include:

• The SSL certificate has expired
• The SSL certificate does not have proper root/intermediate certificates installed on the server
• The SSL certificate was issued to a different hostname other than what is specified in the configuration
• The CRL of the SEG certificate is not publicly available

Connectivity between AirWatch and SEG

While this connection is only required from the AirWatch CN/DS servers to the SEG server, it can generally be tested from any server outside the domain if the firewall has not specifically restricted traffic to these servers. To confirm access, navigate to the following URL from outside the domain:

https://seghost

The expected result is an IIS flash page for classic SEG and SEG v2 version for v2 SEG.

Test Connection Result from SEG To API

This check ensures the AirWatch API server is accessible from the SEG server. When confirming these checks, all tests should be performed from the SEG server itself. Tests can be performed from other servers as well to corroborate the results if necessary.

Hostname found

This check confirms the hostname specified for the AirWatch API server is resolved to an IP address. A simple variation of this test is to use the command prompt on the SEG server to issue a nslookup <APIhost>.

SSL certificate from SEG to API valid

This check ensures the SSL certificate bound to the API server is properly configured. Some common reasons for this to fail include:

• The SSL certificate has expired
• The SSL certificate does not have proper root/intermediate certificates installed on the server
• The SSL certificate was issued to a different hostname other than what is specified in the configuration
• The CRL of the API server’s certificate is not accessible from the SEG server
• A handshake error has occurred due to incompatible protocols or cipher suites between the API and SEG servers

Connectivity between SEG and AirWatch

This ensures a proper connection can be established between the SEG and AirWatch API.

This requires the SOAP API certificate and root certificate are properly configured on the console (Settings > System > Advanced > API > SOAP API) at the respective OG where MEM is configured) and also installed on the SEG server. This is typically taken care of during the SEG setup process but can be confirmed through Microsoft Management Console for classic SEG. V2 SEG uses REST API.

The expected response is OK.

Number 3: Review Exchange Activesync setting

Is it a new Exchange Activesync connection? By default, each user is limited to 10 mobile partnerships in Exchange under Outlook Web App > Options > Phone > Mobile Phones. So you may just need to delete any stale connection to resolve this connectivity issue.

* Several of my users encountered this error after their mailboxes were migrated from Exchange 2010 to 2016. Upon clearing some of the stale devices from the user’s mailbox and re-pushing the mail profile in the AirWatch console, users were able to re-establish connectivity on their mobile devices.

Is ActiveSync enabled for the user? This is a common mistake made if it’s not enabled by default due to security concerns. You can verify it by running the below in Exchange Management Shell:

Get-CASMailbox -Identity <Username> | Select-Object ActiveSyncEnabled

Believe it or not, I’ve witnessed that simply disabling and re-enabling EAS on the user’s mailbox also resolves the issue.

Number 4: Review IIS log in SEG and Activesync log in Exchange

When the issue occurs, it’s best to have the below in place:

• Enable verbose logging within SEG when the issue occurs.
• Use either Notepad++ or Log Parser Studio for easier log analysis.

Generally, check both the IIS and web listener logs on the SEG servers to help with identifying the root cause. The default locations in the SEG servers should be:

• C:\AirWatch\Logs\EASListener\AW.Eas.Web.Listener.log
• C:\AirWatch\Logs\Services
• IIS Log – E:\inetpub\logs\logfiles\W3SVC1\u_exYYMMDD.log
  • In my case, we found the connection between SEG and Exchange took about 20 minutes before it timed out with a 403 error.

Here’s the logs guide provided by VMware support:

You may also want to review the IIS log in Microsoft Exchange usually located at:

C:\inetpub\logs\LogFiles\Default Web Site\W3SVC1

Number 5: Create Target Logs for a particular user or device

This allows you to create Verbose Web Listener logs for specific users or devices which can be helpful in a large environment and when only a small subset of users are affected.

To start, log onto the SEG and browse to https://localhost/segconsole

* If you happen to access the link above remotely (i.e. https://your_SEG_hostname/segconsole), you will not see the options to enable target logging. Per VMware, this is for security reasons.

In the Targeted Logging screen, select the query from the options EAS Device Identifier and Username. Then, select Start Targeted Logging. Once you reproduce the issue, select Stop Targeted Logging and retrieve the logs located at C:\AirWatch\Logs\EASListener.

Number 6: Check off Include inheritable permissions from this object’s parent of user’s account in Active Directory

I’ve seen this setting being mentioned in various online forums, and my Exchange team attested to the same that users with elevated accounts (i.e. domain admins) may require this box checked for the email to sync. Please note: this setting will stay checked only for up to 15 minutes.

If needed, you may want to enable Exchange ActiveSync Mailbox Logging as well to identify the root cause.

I did try accessing the same feature in /OWA but it’s not always successful. Thus, /ECP is highly preferred.