This RoboTech article is dedicated to troubleshooting mobile email delivery issues. We will see first a pure AirWatch server issue and finally pay attention to the consequences of an ActiveSync local problem.
Business cases presented in this article are inspired from one of our largest customers. Part of the solution was designed with them to ease the detection and troubleshooting of their technical issues.
This customer is a large oil & gas company that has worked with GSX for many years before expressing interest in our AirWatch project. Since they have multiple locations in different countries, it was really important for them to understand in real-time, if their employees could fully access the company’s IT resources.
This company is using Office 365 and AirWatch servers to manage and secure their 15,000 devices. Regularly, remote users were opening tickets related to email synchronization or availability through their mobile devices.
First case: Web listener and EAS integration service issue
In this first example, after a first location started to complain, tickets were then opened from multiple places. It seemed like no mobile devices were able to receive any new email.
This situation quickly became an important issue.
The support team started verifying that the impacted users had no issue with their rights to access the messaging and mobile environment. In this case, everything was fine.
After a few other checks, the AirWatch support team was involved and started to check the Active Sync end-point availability. Everything was fine there as well.
Teams then went through each AirWatch server, role, and database to understand their health and what had gone wrong. The issue was identified on the SEG server. Even if the console looked fine, no mobile device was able to access the SEG server.
So what was the root cause? Two separate issues were detected.
The first one impacted the web listener of the SEG server.
After deeper troubleshooting, they understood that the IIS application pool went down, preventing the web listener from functioning properly.
The second issue was related to the EAS integration service that also went down, preventing the connection between the SEG server and the database through the AirWatch API.
Because of that, policies could not be refreshed, also preventing mobiles from getting their new emails.
This case involved a lot of troubleshooting and problematic downtime for all end-users.
Let’s see how to easily detect this issue with GSX.
GSX for AirWatch: how does it help?
As you can see on the first screenshot, the GSX real-time interface provides you with a direct view of the health of any AirWatch server you have as well as any other part of your mobility service.
You can drill down in each server to understand which are the issues.
Looking at this screenshot, you can immediately see that there are issues on the AirWatch Secure Gateway Server. Our interface allows you to immediately identify what is causing the issue.
As we’ve seen earlier, we run multiple tests on the IIS services, providing you with the application pools status and looking at each website and end-point.
You can directly see that the web listener is having problems, preventing any mobile to reach the AirWatch servers and then to synchronize their emails.
Then, it's also pretty quick to see that the EAS service is not running, preventing mobile to synchronize with the servers.
Thanks to GSX, you won’t have to spend time troubleshooting your issues because you'll already have all the information you need in front of you to directly address the root causes.
Let’s now check out a second use case that happened to the same company.
Second case : Troubleshooting local issue with ActiveSync
This time all the opened support tickets came from one single location.
First level steam was involved, checking user’s rights and sending issues to the mobility team. They checked every server, role and database of the AirWatch environment and everything was looking fine.
They then checked the availability of the ActiveSync end-point and everything looked ok. At this point, the messaging team was involved and checked the Office 365 portal for potential messaging issues. They found nothing.
Finally, after extensive research with the local network team, they found out that the ActiveSync end-point was not reachable from that particular location because of new local firewall rules.
This example perfectly illustrates why the GSX Robot Users are so important.
How GSX helps solving the issue
The Robot Users provide you with visibility from the user perspective. Nowadays, most companies have multiple locations and users can be spread all over the world. The difficulty for the mobility administrator team is to be able to run tests from where the users are.
The GSX Robot Users can be deployed easily in any of your locations and use the services as a user.
Here, using the ActiveSync protocol, the Robot Users act exactly like mobile devices users.
Looking at the dashboard alerts, we can immediately see that everything works perfectly in Chicago, almost fine in Los Angeles, however there is a problem in the New York Office.
Like we drill down to servers, it's possible to use Robot Users to look deeply into what is going on at the New York location.
Once again, the Robot User is performing each action as a user would. It is not only connecting to the ActiveSync end-point; it is also opening mailbox, creating an email, a meeting from your phone, looking for the free/busy statuses of the participant, etc.
Each of those actions are reproduced from your different locations.
On top of that, network checks are done to make sure it is not the network that is the root causes of your latency.
As a result, having all the information right under your eyes will drastically cut the time for you to troubleshoot and repair a mobility issue.
In the last RoboTech article, we will address a new business case showing why it is so important to constantly have an overview on the entire messaging infrastructure even when dealing with mobile email user complaints.