GSX for AirWatch connects at each server remotely and look at every critical role to test and retrieve critical statistics.  

AirWatch specific services monitoring 

Each AirWatch role delivers specific services that are tested from a Windows services perspective: 

► Device tunnel, interrogator, log manager queue services 
► Tunnel servers 
► Log Manager, Master and MEG queue services 
► Messaging services 
► EAS Integration 
► Mobile Access Gateway 
► Alert, bulk import services 
► Device scheduler 
Etc. 

Each service is monitored in real-time and is provided with some alerts in case of failure. The second important aspects of each AirWatch role is to be able to access to the different consoles and critical URL end-points. 

AirWatch web consoles monitoring 

To do so, GSX tests each connection, at all times:  

► Web console availability 
► Admin console 
► Open enrollments 
► My device 
► Device management 
► Self service 
► MDM enrollments 
► MSMQ queue monitoring 
► SEG Console and console management 
► Microsoft ActiveSync 
► Content / Default (MAG server) 
Etc. 

The access to these end-points and consoles is highly critical. In fact, each action an AirWatch administrator can do has to be done through end-points and consoles.  

To make sure no problem will occur with the web consoles, it is extremely important to constantly monitor the health of the IIS servers they are using. And that’s another key point of GSX.  

AirWatch IIS monitoring  

Each IIS servers have their application pools monitored:  

► ASP.net Application restarts 
► ASP.net Application running 
► ASP.net Worker process restarts 

Each critical IIS statistics are collected to provide with a view on the health and usage of this critical part:  

► Connection attempts per second 
► Get Request per second 
► Post Request per second 
► Application restarts  
► Worker process restarts 

Basically, between the health of the IIS and the real availability of the end-point, the entire environment of the web console is constantly monitored.  

AirWatch system monitoring 

Finally, on top of all these particular tests and counters, each server and each role first go through a basic check of their system counters:  

► CPU 
► RAM 
► Disk IO 
► Disk Space 
► Network IO 

These system counters can give precious information on the health of the infrastructure when they are combined with the specifics tests and statistics for AirWatch service delivery. 

To finish with the in-depth server monitoring, it is really important to consider the AirWatch database as a specific object. 

AirWatch database monitoring 

Based on SQL, the database needs specifics monitoring to check its health, retrieve all usage and health critical statistics.  

To do so, GSX connects remotely with SQL queries to the database and first collects specific AirWatch statistics:  

► Enrolled users 
► Certificate details 
► AirWatch version 
► Compromised devices 

As well as critical real-time information on its health:  

► Transaction log file size, Index Rebuild and Data file size drive 
► SQL server Job History, Page Life expectancy and disk queuing 
► Buffer Hit Ratio and Average Wait time 
► Lazy writes per second and Number of Deadlocks 
► Active Transaction and Users Connections 
► Page reads per second and Page writes per second 

It is very important to manage the health of the SQL database because any performance issue can impact any user trying to synchronize its mobile.  

So we’ve just seen that an in-depth monitoring of every services and critical statistics of each role is critical. But it is not enough to ensure your end-user satisfaction. 

That is why GSX for AirWatch also directly monitors the end-user experience from any location you want to test through the GSX Robot Users. 

Capture the true end-user experience 

For those who are new to GSX and would like to learn more about what a GSX Robot User is, a quick check of our blog describing how Robot Users work could be helpful.

To sum up, a Robot User is a piece of software that you install on any workstation or window VM and that will use the service you want to test exactly as a user would. 

By acting as a user, it measures the availability and performance of each service from an end-user perspective. 

The Robot Users are installed in multiple remote locations and emulate a mobile device that:  

► Opens mailbox and sends email 
► Proceeds to free/busy lookups 
► Creates meetings, folders, email and tasks 
► Resolves a user and performs a search on its mailbox 
► Downloads an attachment from an email 

The Robot Users use your entire mobile infrastructure, measure the time each action takes, and alert you in case of failure or performance problem. 

As a result, you'll know any potential issue before actual users start to complain. 

On top of that, our Robots perform network checks and retrieve critical information that will help you to understand the network's impact on end-user experience:
  
► One way latency and round trip time 
► DNS resolution time 
► TraceRoute with number of hops and latency 
► Packet loss 

Network statistics are critical to understand if the network has an impact on the end-user experience.  

They also allow the mobile team to understand the impacts of any network change on the mobile end-user experience.  

Thanks to the Robot Users, GSX provides you with information about the end-user experience delivered through AirWatch and collaboration infrastructure. 

In order to understand a bit better how all of that is helping your mobility team and the overall IT management to manage the service quality delivered to end-user we recommend you to read the next RoboTech article dealing with real uses cases we faced with our customers.