Transcription

Monitoring the CitrixXenMobile MDMeG Enterprise v6.0

Restricted Rights LegendThe information contained in this document is confidential and subject to change without notice. No part of thisdocument may be reproduced or disclosed to others without the prior permission of eG Innovations Inc. eGInnovations Inc. makes no warranty of any kind with regard to the software and documentation, including, but notlimited to, the implied warranties of merchantability and fitness for a particular purpose.TrademarksMicrosoft Windows, Windows NT, Windows 2003, and Windows 2000 are either registered trademarks or trademarksof Microsoft Corporation in United States and/or other countries.The names of actual companies and products mentioned herein may be the trademarks of their respective owners.Copyright 2014 eG Innovations Inc. All rights reserved.

Table of ContentsINTRODUCTION . 1MONITORING THE XENMOBILE MDM. 32.1The JVM Layer Tests . 42.2The Java Application Server Layer . 52.3The XenMobile Server Layer . 62.3.1License Test . 72.3.2Logs Test. 82.3.3Scheduled Jobs Test . 142.3.4XenMobile Status Test . 172.3.5XenMobile Threads Test . 182.4The XenMobile Device Management Layer . 212.4.1Device Applications Test . 212.4.2Device Actions Test . 232.4.3Device Sessions Test . 262.4.1Devices by Platform Test . 282.4.2Devices Test . 322.4.3Package Deployments Test . 35CONCLUSION . 38

Table of FiguresFigure 1: The Citrix XenMobile Architecture . 1Figure 2.1: The layer model of the XenMobile Device Manager . 3Figure 2.1: The tests mapped to the JVM layer . 5Figure 2.2: The tests mapped to the Java Application Server layer . 6Figure 2.2: The tests mapped to the Operating System layer . 7Figure 2.3: The detailed diagnosis of the repeating jobs measure . 16Figure 2.4: The detailed diagnosis of the running jobs measure . 16Figure 2.5: The detailed diagnosis of the Devices with non-suggested applications measure. 23Figure 2.6: The detailed diagnosis of the Devices with missing required applications measure . 23Figure 2.7: The detailed diagnosis of the Connected devices measure . 28

IntroductionIntroductionCitrix XenMobile is an enterprise mobility management solution that provides administrators with mobile devicemanagement (MDM), mobile application management (MAM) and online file-sharing capabilities. To deliver theseservices to end-users, the XenMobile software suite includes a wide range of components – the Worx homeapplication that allows mobile device users to access their unified corporate app store, the Citrix Netscaler thatauthenticates remote user sessions to the app store and ensures secure access, the XenMobile App Controller thatstores the applications and data sources that can be accessed by users, Citrix ShareFile that enables efficient datasharing and synchronization across users, and the XenMobile Device Manager that protects the corporate networkfrom mobile threats by applying configured mobile usage policies on devices and detecting non-conformances.Figure 1: The Citrix XenMobile ArchitectureSince these components work closely with each other to deliver data and application mobility to end-users, a problemin any one of these components can ripple and affect the performance of the dependent components, thus affectinguser experience with Citrix XenMobile. Naturally therefore, when a mobile device user complains of a slowdown whenaccessing data/applications within the corporate network, help desk very often struggles to figure out where thebottleneck lies – is it with Netscaler? Is it in the App Controller? is it because of the XenMobile Device Manager? or isit owing to Sharefile? This is where eG Enterprise helps! eG Enterprise provides end-to-end monitoring of the CitrixXenMobile infrastructure and precisely pinpoints the source of slowdowns in the XenMobile service offering. The outof-the-box monitors that eG provides for the XenMobile Device Manager, the App Controller, the Citrix Sharefile, andthe Citrix storage zones, periodically check and report the availability, responsiveness, and overall health of each ofthese components. eG’s patented correlation algorithm then automatically discovers how these individual silosinteract with each other, intelligently correlates the performance results collected from these monitors on the basis ofthe discovered dependencies, and thus, accurately isolates the source of slowdowns that a mobile device userexperiences when accessing corporate data/applications from remote locations.1

Monitoring the Quality Virtual DesktopThis document details how eG monitors the XenMobile MDM – i.e., the XenMobile Device Manager – and whatmetrics it collects from the MDM.2

Monitoring the XenMobile MDM ServerMonitoring the XenMobile MDMServerXenMobile MDM (also known as the XenMobile Device Manager (XDM)) is the MDM component within CitrixXenMobile, which runs on an Apache Tomcat web server configured as a Windows service and relies on Javasoftware (Java virtual Machine). It provides role-based management, configuration and security of corporate anduser-owned devices. Using this tool, IT can manage mobile devices, set mobile policies and compliance rules, gainvisibility to the mobile network, provide control over mobile apps and data, and shield the network from mobilethreats. IT can blacklist or whitelist apps, detect devices that are jailbroken or out of compliance and block theirActiveSync email access and do a full or selective wipe of a device that is lost, stolen or out of compliance. Thisimplies that the non-availability of the XenMobile MDM, even for a few minutes, or a temporary slowdown in itsoperations, can have grave consequences! Without the XenMobile MDM, mobile devices will not be able to registerwith XenMobile; registered devices will not be able to download latest policies. This in turn can expose theenvironment to serious mobile threats – for instance, access by unauthorized devices and usage of blacklistedapplications will go undetected; confidential information may travel beyond authorized boundaries increasing thepossibilities of abuse. To keep such intrusions at bay and to ensure a secure mobile experience for users,administrators need to keep an eye on the availability and overall health of the XenMobile MDM, proactively detectpotential problem conditions, and initiate measures to avert them.To enable administrators to achieve this, eG Enterprise provides the XenMobile MDM monitoring model.Figure 2.1: The layer model of the XenMobile Device ManagerEach layer of this model is mapped to a wide variety of tests that primarily use MDM’s web services API to pull3

Monitoring the XenMobile MDM Serverout a wealth of performance information related to the XenMobile MDM. To access the API, the eG agent has to beconfigured with ‘Administrator’ rights to the XenMobile MDM server.Using the metrics collected from the API, administrators can ascertain the following: Is the XenMobile MDM server available over the network? Is the Tomcat server hosting the XenMobile MDM operating at its peak capacity? Are any JVM threads being blocked? Exactly, which thread is blocking and which line of code couldhave caused the block? Is the XenMobile MDM server online? Has the server experienced any error events recently? What type of errors are these? Does the server have adequate user/device licenses? Are scheduled jobs running as per schedule on the XenMobile MDM server? What is the current device load on the server? Does the server’s thread pool have adequate threads tohandle this load? How many devices are currently managed by the server? Which of these devices host blacklisted applications? Do all managed devices contain all required applications? Which applications are missing on whichdevices? Has the MDM server detected any jail-broken, perimeter-breaching, out-of-compliant, or passcodenon-compliant devices? If so, which devices are they? Has the MDM server triggered any automated actions on any device? Which of these actions are stillpending on these devices and why? Which devices are currently disconnected from the server? Have any package deployments failed?The sections that follow will take you on a layer-by-layer tour of the XenMobile MDM monitoring model. However,since the tests associated with the Operating System, Network, Application Processes, and Windows Service layershave been already dealt with in detail in the Monitoring Unix and Windows Servers document, this chapter will focuson the other layers only.2.1 The JVM Layer TestsErratic usage of the JVM memory heap, blocked JVM threads, and resource-intensive JVM threads can adverselyimpact the performance of the XenMobile MDM server that overlays the JVM. To capture such JVM-relatedabnormalities proactively, administrators can use the tests mapped to the JVM layer.4

Monitoring the XenMobile MDM ServerFigure 2.1: The tests mapped to the JVM layerSince the tests mapped to this layer have already been discussed elaborately in the Monitoring Java Applicationsdocument, let us proceed to the next layer.2.2 The Java Application Server LayerAs stated earlier, XenMobile MDM runs on an Apache Tomcat server. Since the availability and performance of theMDM server relies on the health of its Tomcat foundation, the tests mapped to this layer monitor and report onTomcat health.5

Monitoring the XenMobile MDM ServerFigure 2.2: The tests mapped to the Java Application Server layerSince the tests mapped to this layer have already been discussed elaborately in the Monitoring Application Serversdocument, let us proceed to the next layer.2.3 The XenMobile Server LayerUsing the tests mapped to this layer, administrators can understand: The current status of the XenMobile MDM server License usage and requirements Status of scheduled jobs Adequacy of XenMobile threads Errors/warnings captured by XenMobile logs6

Monitoring the XenMobile MDM ServerFigure 2.2: The tests mapped to the Operating System layer2.3.1License TestTo track and control every device/user connecting to the corporate network, the XenMobile MDM should ideallypossess a license per user/device. If adequate licenses are not available, then new users and devices will gounmanaged by XenMobile MDM, thus increasing the risk of unauthorized accesses. Likewise, if the MDM license is notrenewed in time, administrators will not be able to use the services of the XenMobile MDM server continuously, whichwill again expose the corporate network to malicious attacks. To avoid this, administrators can use the License test.This test tracks the license usage of the XenMobile MDM and also determines when the MDM license is likely toexpire. In the process, it reports the following: Is the XenMobile MDM running out of licenses? If so, administrators can quickly arrange to purchaseadditional licenses to deal with the additional user/device load on their network. Is the MDM license up for renewal? If so, administrators can work towards extending the license sothat MDM continues to manage devices/users.PurposeTracks the license usage of the XenMobile MDM and also determines when the MDM license islikely to expireTarget of thetestA Citrix XenMobile MDMAgentdeploying thetestAn internal agentConfigurableparameters forthe test1.TEST PERIOD - How often should the test be executed2.HOST - The host for which the test is to be configured.3.LOGIN URL – This refers to the URL of the login page of the XenMobile Device Managerconsole. By default, eG Enterprise auto-discovers this URL. This is why, the LOGIN URL isset to none by default.4.USERNAME and PASSWORD – Specify the credentials of a XenMobile Device Managerweb console user with the Administrator role.5.CONFIRM PASSWORD – Confirm the PASSWORD by retyping it here.6.SSL – Indicate whether/not the XenMobile MDM server is SSL-enabled. By default, this flagis set to No.7

Monitoring the XenMobile MDM ServerOutputs of thetestMeasurementsmade by thetestOne set of results for the XenMobile MDM server being monitoredMeasurementUnitMeasurementLicenses used:Indicates the numberlicenses currently used.InterpretationNumberofTotal licenses purchased:NumberIndicates total number oflicensesheldbytheXenMobile MDM.Percentage of licensesused:PercentA value close to 100% indicates that theMDM is rapidly running out of licenses. In thiscase, to ensure the uninterrupted usage ofthe XenMobile MDM, you will have topurchase additional licenses.DaysA very low value for this measure indicatesthat the license is nearing expiry. You mayhave to request for a license extension if youwant to continue using the XenMobile MDMsolution.Indicates the percentage oflicenses utilized.License expires in:Indicates the number of daysby which the license willexpire.2.3.2Logs TestTo enable administrators to quickly capture errors/warnings encountered by the XenMobile MDM server,administrators can use the Logs test. This test scans the MDM logs for errors/warnings of configured patterns andreports the number of entries in the log that match the configured patterns. Detailed metrics provided by the testalso provides detailed message descriptions, so as to ease troubleshooting and hasten problem resolution.PurposeScans the MDM logs for errors/warnings of configured patterns and reports the number ofentries in the log that match the configured patternsTarget of thetestA Citrix XenMobile MDM serverAgentdeployingtestAn internal agentthe8

Monitoring the XenMobile MDM ServerConfigurableparameters forthe test1.TEST PERIOD - How often should the test be executed2.HOST - The host for which the test is to be configured.3.PORT – The port at which the server onitored.Foreg.,D:\zdm\logs\errorlog. Multiple log file paths can be provided as a comma-separated list eg., D:\zdm\logs\errorlog,D:\zdm\logs\warnlog.Also, instead of a specific log file path, the path to the directory containing log files can beprovided - eg., D:\zdm\logs. This ensures that eG Enterprise monitors the most recent logfiles in the specified directory. Specific log file name patterns can also be specified. Forexample, to monitor the latest log files with names containing the strings 'error' and 'warn',the parameter specification can be, D:\zdm\logs\*error*,D:\zdm\logs\*warn*. Here, '*'indicates leading/trailing characters (as the case may be). In this case, the eG agent firstenumerates all the log files in the specified path that match the given pattern, and thenpicks only the latest log file from the result set for efollowingformat:[email protected] or pattern. Here, Name represents the display name of the path beingconfigured. Accordingly, the parameter specification for the 'error' and 'warn' examplediscussed above can be: [email protected] D:\zdm\logs\*error*,[email protected]:\zdm\logs\*warn*. Inthis case, the display names 'error' and 'warn' will alone be displayed as descriptors of thistest.Note:If your ALERTFILE specification consists of file patterns that include wildcardcharacters (eg., D:\zdm\logs\*error*,D:\zdm\logs\*warn*), then such configurationswill only be supported in the ANSI format, and not the UTF format.Every time this test is executed, the eG agent verifies the following: Whether any changes have occurred in the size and/or timestamp of the log filesthat were monitoring during the last measurement period; Whether any new log files (that match the ALERTFILE specification) have beennewly added since the last measurement period;If a few lines have been added to a log file that was monitored previously, then the eGagent monitors the additions to that log file, and then proceeds to monitor newer log files(if any). If an older log file has been overwritten, then, the eG agent monitors this log filecompletely, and then proceeds to monitor the newer log files (if any).9

Monitoring the XenMobile MDM Server5.SEARCHPATTERN - Enter the specific patterns of alerts to be monitored. The patternshould be in the following format: PatternName : Pattern , where PatternName isthe pattern name that will be displayed in the monitor interface and Pattern is anexpression of the form - *expr* or expr or *expr or expr*, etc. A leading '*' signifies anynumber of leading characters, while a trailing '*' signifies any number of trailing characters.For example, say you specify error:error-* in the SEARCHPATTERN text box. Thisindicates that "error" is the pattern name to be displayed in the monitor interface. "error-*"indicates that the test will monitor only those lines in the alert log which start with theterm "error-".A single pattern may also be of the form e1 e2, where signifies an OR condition. Thatis, the PatternName is matched if either e1 is true or e2 is true.Multiple search patterns can be specified as a comma-separated list. For lineIf the ALERTFILE specification is of the format [email protected], then the descriptor forthis test in the eG monitor interface will be of the format: Name:PatternName. On theother hand, if the ALERTFILE specification consists only of a comma-separated list of logfile paths, then the descriptors will be of the format: LogFilePath:PatternName.If you want all the messages in a log file to be monitored, then your specification wouldbe: PatternName :*.6.LINES - Specify two numbers in the format x:y. This means that when a line in the alert filematches a particular pattern, then x lines before the matched line and y lines after thematched line will be reported in the detailed diagnosis output (in addition to the matchedline). The default value here is 0:0. Multiple entries can be provided as a comma-separatedlist.If you give 1:1 as the value for LINES, then this value will be applied to all the patternsspecified in the SEARCHPATTERN field. If you give 0:0,1:1,2:1 as the value for LINESand if the corresponding value in the SEARCHPATTERN filed is like error:error*,offline:*offline*,online:*online then:0:0 will be applied to error:error-* pattern1:1 will be applied to offline:*offline* pattern2:1 will be applied to online:*online pattern10

Monitoring the XenMobile MDM Server7.EXCLUDEPATTERN - Provide a comma-separated list of patterns to be excluded frommonitoring in the EXCLUDEPATTERN text box. For example *critical*, *exception*. Bydefault, this parameter is set to 'none'.8.UNIQUEMATCH - By default, the UNIQUEMATCH parameter is set to FALSE, indicatingthat, by default, the test checks every line in the log file for the existence of each of theconfigured SEARCHPATTERNS. By setting this parameter to TRUE, you can instruct thetest to ignore a line and move to the next as soon as a match for one of the configuredpatterns is found in that line. For example, assume that Pattern1:*fatal*,Pattern2:*error* isthe SEARCHPATTERN that has been configured. If UNIQUEMATCH is set to FALSE,then the test will read every line in the log file completely to check for the existence ofmessages embedding the strings 'fatal' and 'error'. If both the patterns are detected in thesame line, then the number of matches will be incremented by 2. On the other hand, ifUNIQUEMATCH is set to TRUE, then the test will read a line only until a match for one ofthe configured patterns is found and not both. This means that even if the strings 'fatal' and'error' follow one another in the same line, the test will consider only the first match and notthe next. The match count in this case will therefore be incremented by only 1.9.ROTATINGFILE - This flag governs the display of descriptors for this test in the eGmonitoring console.If this flag is set to true and the ALERTFILE text box contains the full path to a specific(log/text) file, then, the descriptors of this test will be displayed in the following format:Directory containing monitored file: SearchPattern . For instance, if the ALERTFILEparameter is set to c:\zdm\logs\syslog.txt, and ROTATINGFILE is set to true, then, yourdescriptor will be of the following format: c:\zdm\logs: SearchPattern . On the otherhand, if the ROTATINGFILE flag had been set to false, then the descriptors will be of thefollowing format: FileName : SearchPattern - i.e., syslog.txt: SearchPattern in thecase of the example above.If this flag is set to true and the ALERTFILE parameter is set to the directory containinglog files, then, the descriptors of this test will be displayed in the format:Configured directory path: SearchPattern . For instance, if the ALERTFILE parameter isset to c:\zdm\logs, and ROTATINGFILE is set to true, then, your descriptor will be:c:\zdm\logs: SearchPattern . On the other hand, if the ROTATINGFILE parameter hadbeen set to false, then the descriptors will be of the following format:Configured directory: SearchPattern - i.e., logs: SearchPattern in the case of theexample above.If this flag is set to true and the ALERTFILE parameter is set to a specific file pattern,then, the descriptors of this test will be of the following format: FilePattern : SearchPattern . For instance, if the ALERTFILE parameter is set toc:\zdm\logs\*sys*, and ROTATINGFILE is set to true, then, your descriptor will be:*sys*: SearchPattern . In this case, the descriptor format will not change even if theROTATINGFILE flag status is changed.11

Monitoring the XenMobile MDM Server10. CASESENSITIVE - This flag is set to No by default. This indicates that the test functions ina 'case-insensitive' manner by default. This implies that, by default, the test ignores thecase of your ALERTFILE and SEARCHPATTERN specifications. If this flag is set to Yes onthe other hand, then the test will function in a 'case-sensitive' manner. In this casetherefore, for the test to work, even the case of your ALERTFILE and SEARCHPATTERNspecifications should match with the actuals.11. ROLLOVERFILE - By default, this flag is set to false. Set this flag to true if you want thetest to support the 'roll over' capability of the specified ALERTFILE. A roll over typicallyoccurs when the timestamp of a file changes or when the log file size crosses a predetermined threshold. When a log file rolls over, the errors/warnings that pre-exist in thatfile will be automatically copied to a new file, and all errors/warnings that are capturedsubsequently will be logged in the original/old file. For instance, say, errors and warningswere originally logged to a file named error log. When a roll over occurs, the content of thefile error log will be copied to a file named error log.1, and all new errors/warnings will belogged in error log. In such a scenario, since the ROLLOVERFILE flag is set to false bydefault, the test by default scans only error log.1 for new log entries and ignores error log.On the other hand, if the flag is set to true, then the test will scan both error log anderror log.1 for new entries.If you want this test to support the 'roll over' capability described above, the followingconditions need to be fulfilled: The ALERTFILE parameter has to be configured only with the name and/or pathof one/more alert files. File patterns or directory specifications should not bespecified in the ALERTFILE text box. The roll over file name should be of the format: “ ALERTFILE .1”, and this filemust be in the same directory as the ALERTFILE.12. OVERWRITTENFILE - By default, this flag is set to false. Set this flag to true if log files donot 'roll over' in your environment, but get overwritten instead. In such environmentstypically, new error/warning messages that are captured will be written into the log file thatpre-exists and will replace the original contents of that log file; unlike when 'roll over' isenabled, no new log files are created for new entries in this case. If theOVERWRITTENFILE flag is set to true, then the test will scan the new entries in the log filefor matching patterns. However, if the flag is set to false, then the test will ignore the newentries.13. ENCODEFORMAT – By default, this is set to none, indicating that no encoding formatapplies by default. However, if the test has to use a specific encoding format for readingfrom the specified ALERTFILE , then you will have to provide a valid encoding format here- eg., UTF-8, UTF-16, etc. Where multiple log files are being monitored, you will have toprovide a comma-separated list of encoding formats – one each for every log file monitored.Make sure that your encoding format specification follows the same sequence as yourALERTFILE specification. In other words, the first encoding format should apply to the firstalert file, and so on. For instance, say that your alertfile specification is as follows:D:\logs\report.log,E:\logs\error.log, C:\logs\warn log. Assume that while UTF-8 needs to beused for reading from report.log , UTF-16 is to be used for reading from warn log . Noencoding format need be applied to error.log. In this case, your ENCODEFORMATspecification will be: UTF-8,none,UTF-16.12

Monitoring the XenMobile MDM Server14. USEUTF8 - If UTF-8 encoding is to be used for reading the specified log file, then, set theUSEUTF8 flag to true. By default, this flag is set to false. If multiple log files are beingmonitored, then, for each file, you will have to indicate whether UTF-8 encoding is to beused for reading that file or not. For instance, assume that the ALERTFILE parameter is setto warn.log Now, to instruct the testto use UTF-8 encoding for reading the 'errors' log file and not to use the UTF-8 encodingwhile reading the 'warnings' log file, your USEUTF8 setting should be as follows: true,false.Note that the number of values provided against the USEUTF8 parameter shouldbe equal to the number of log files being monitored. Also, note that if theALERTFILE being monitored has BOM, then the test will automatically use UTF-8encoding to read that file, even if the USEUTF8 flag is set to false.Note:If your ALERTFILE specification consists of file patterns that include wildcardcharacters (eg d:\zdm\logs\*error*,d:\zdm\logs\*warn*), then the files that matchsuch patterns will only support the ANSI format, and not the UTF format, even if theUTF-8 parameter is set to true for su

Monitoring the XenMobile MDM Server 3 Monitoring the XenMobile MDM Server XenMobile MDM (also known as the XenMobile Device Manager (XDM)) is the MDM component within Citrix XenMobile, which runs on an Apache Tomcat web server configured as a Windows service and relies on Java