Following my first article “XenMobile: Monitoring part 1”, here after the Part 2.
XenMobile server
XenMobile server generates and stores logs on local storage that you can also export to a systems log (syslogs) server. You can configure log settings to specify size constraints, log level, or you can create custom loggers to filter specific events. You can look at XenMobile server logs from the XenMobile console at any time. You can also export information in the logs via the syslog server to your production Splunk logging servers.
The following list describes the different types of log files available in XenMobile:
Debug log file: Contains debug level information about core web services of XenMobile, including error messages and server-related actions.
Message format:
<date> <timestamp> <loglevel> <class name (including the package)> – <id> <log message>
- where <id> is a unique identifier like sessionID.
- where <log message> is the message supplied by the application.
Admin audit log file – Contains audit information about activity on the XenMobile console.
Note: The same format is used for both admin audit and user audit logs.
Message format:
With the exception of required Date and Timestamp values, all other attributes are optional. Optional fields are represented with ” ” in the message.
<date> <timestamp> “<username/id>” “<sessionid>” “<deviceid>” “<clientip>” “<action>” “<status>”
“<application name>” “<app user id>” “<user agent>” “<details>”
The following table lists the available admin audit log events:
| Admin Audit Log Messages | |
|---|---|
| Event | Status |
|
Login |
success/failure |
|
Logout |
success/failure |
|
Get admin |
success/failure |
|
Update admin |
success/failure |
|
Get application |
success/failure |
|
Add application |
success/failure |
|
Update application |
success/failure |
|
Delete application |
success/failure |
|
Bind application |
success/failure |
|
Unbind application |
success/failure |
|
Disable application |
success/failure |
|
Enable application |
success/failure |
|
Get category |
success/failure |
|
Add category |
success/failure |
|
Update category |
success/failure |
|
Delete category |
success/failure |
|
Add certificate |
success/failure |
|
Delete certificate |
success/failure |
|
Active certificate |
success/failure |
|
Self-sign certificate |
success/failure |
|
CSR certificate |
success/failure |
|
Export certificate |
success/failure |
|
Delete certificate chain |
success/failure |
|
Add certificate chain |
success/failure |
|
Get connector |
success/failure |
|
Add connector |
success/failure |
|
Delete connector |
success/failure |
|
Update connector |
success/failure |
|
Get device |
success/failure |
|
Lock device |
success/failure |
|
Unlock device |
success/failure |
|
Wipe device |
success/failure |
|
Unwipe device |
success/failure |
|
Delete device |
success/failure |
|
Get role |
success/failure |
|
Add role |
success/failure |
|
Update role |
success/failure |
|
Delete role |
success/failure |
|
Bind role |
success/failure |
|
Unbind role |
success/failure |
|
Update config settings |
success/failure |
|
Update workflow email |
success/failure |
|
Add workflow |
success/failure |
|
Delete workflow |
success/failure |
|
Add Active Directory |
success/failure |
|
Update Active Directory |
success/failure |
|
Add masteruserlist |
success/failure |
|
Update masteruserlist |
success/failure |
|
Update DNS |
success/failure |
|
Update Network |
success/failure |
|
Update log server |
success/failure |
|
Transfer log from log server |
success/failure |
|
Update syslog |
success/failure |
|
Update receiver updates |
success/failure |
|
Update time server |
success/failure |
|
Update trust |
success/failure |
|
Add service record |
success/failure |
|
Update service record |
success/failure |
|
Update receiver email |
success/failure |
|
Upload patch |
success/failure |
|
Import snapshot |
success/failure |
|
Fetch app store app details |
success/failure |
|
Update MDM |
success/failure |
|
Delete MDM |
success/failure |
|
Add HDX |
success/failure |
|
Update HDX |
success/failure |
|
Delete HDX |
success/failure |
|
Add Branding |
success/failure |
|
Delete Branding |
success/failure |
|
Update SSL offload |
success/failure |
|
Add account property |
success/failure |
|
Delete account property |
success/failure |
|
Update account property |
success/failure |
|
Add beacon |
success/failure |
User audit log file: Contains information related to the user activity from enrolled devices.
Note: The same format is used for both user audit and admin audit logs.
Message format:
With the exception of required Date and Timestamp values, all other attributes are optional. Optional fields are represented with ” ” in the message. For example,
<date> <timestamp> ” <username/id>” “<sessionid>” “<deviceid>” “<clientip>” “<action>” “<status>” ” <application name>” “<app user id>” “<user agent>” “<details>”
The following table lists the available user audit log events:
| User Audit Log Messages | |
|---|---|
| Event | Status |
|
Login |
success/failure |
|
Session time-out |
success/failure |
|
Subscribe |
success/failure |
|
Unsubscribe |
success/failure |
|
Pre-launch |
success/failure |
|
AGEE SSO |
success/failure |
|
SAML Token for ShareFile |
success/failure |
|
Device registration |
success/failure |
|
Device check |
lock/wipe |
|
Device update |
success/failure |
|
Token refresh |
success/failure |
|
Secret saved |
success/failure |
|
Secret retrieved |
success/failure |
|
User initiated change password |
success/failure |
|
Mobile client download |
success/failure |
|
Logout |
success/failure |
|
Discovery Service |
success/failure |
|
Endpoint Service |
success/failure |
| MDM Functions | |
|---|---|
|
REGHIVE |
success/failure |
|
Cab inventory |
success/failure |
|
Cab |
success/failure |
|
Cab auto install |
success/failure |
|
Cab shell install |
success/failure |
|
Cab create folder |
success/failure |
|
Cab file get |
success/failure |
|
File create folder |
success/failure |
|
File get |
success/failure |
|
File sent |
success/failure |
|
Script create folder |
success/failure |
|
Script get |
success/failure |
|
Script sent |
success/failure |
|
Script shell execution |
success/failure |
|
Script auto execution |
success/failure |
|
APK inventory |
success/failure |
|
APK |
success/failure |
|
APK shell install |
success/failure |
|
APK auto install |
success/failure |
|
APK create folder |
success/failure |
|
APK file get |
success/failure |
|
APK App |
success/failure |
|
EXT App |
success/failure |
|
List get |
success/failure |
|
List sent |
success/failure |
|
Locate device |
success/failure |
|
CFG |
success/failure |
|
Unlock |
success/failure |
|
SharePoint wipe |
success/failure |
|
SharePoint Configuration |
success/failure |
|
Remove profile |
success/failure |
|
Remove application |
success/failure |
|
Remove unmanaged application |
success/failure |
|
Remove unmanaged profile |
success/failure |
|
IPA App |
success/failure |
|
EXT App |
success/failure |
|
Apply redemption code |
success/failure |
|
Apply settings |
success/failure |
|
Enable tracking device |
success/failure |
|
App management policy |
success/failure |
|
SD card wipe |
success/failure |
|
Encrypted email attachment |
success/failure |
|
Branding |
success/failure |
|
Secure browser |
success/failure |
|
Container browser |
success/failure |
|
Container unlock |
success/failure |
|
Container password reset |
success/failure |
|
AG client auth creds |
success/failure |
NetScaler also monitors the XenMobile web service state, which is configured with intelligent monitoring probes to simulate HTTP requests to each XenMobile server cluster node. The probes determine whether the service is online and then respond based on the response received. In the event that a node does not respond as expected, NetScaler marks the server as down. In addition, NetScaler takes the node out of the load-balancing pool and logs the event for use in generating alerts through the NetScaler monitoring solution.
You can also use standard hypervisor monitoring tools to monitor the XenMobile virtual machines and to provide relevant alerts regarding CPU, memory, and storage utilization metrics.
SQL Server and database
SQL Server and database performance directly affects XenMobile services. The XenMobile instance requires access to the database at all times and goes offline (for example, stops responding) in the event of an outage to the SQL infrastructure. The XenMobile console may continue to function for a while following any disk space issues with SQL Server. To ensure maximum database uptime and adequate performance for the XenMobile workload, you should proactively monitor the state of your SQL Servers following Microsoft recommendations. Additionally, you should adjust resource allocation for CPU, memory, and storage to guarantee service level agreements as your XenMobile environment continues to grow.
Those first 2 parts provide you theoretical information, in the next part, I will try to explain you how to implement those on your environment with some more screenshot.
Stay Tuned!
