system administrator guide - netmotion...

Locality AgentWindows® 8Windows® 7

iOS 8 and laterAndroid™ 4 and later

Locality ServerWindows Server® 2008 R2

Windows Server® 2012Windows Server® 2012 R2

System Administrator GuideVersion 3.10

Copyright

© 2011-2015 NetMotion Wireless, Inc. All rights reserved. Licensed Material. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language, in any form by any means, without the written permission of NetMotion Wireless, Inc.

NetMotion Wireless Locality System Administrator Guide Locality Server Version 3.10 Locality Agent Version 3.10 for Windows, iOS, and Android April, 2015

Portions © 2004-2005 Rene Rivera: Boost. All rights reserved. Portions © 1998, 1999, 2000 Thai Open Source Software Center Ltd. and Clark Cooper. All rights reserved. Portions © 2001-2009 Expat maintainers: Expat XML parser. All rights reserved. Portions © 1995-2005 Jean-loup Gailly and Mark Adler: Zlib. All rights reserved. Portions © 2010 John Resig:JQuery. All rights reserved. Portions © 2010 Novatel Wireless, Inc: Novacore SDK. All rights reserved. Portions © 2009 Option Wireless Technology: Option SDK. All rights reserved. Portions © 2010 Qualcomm Incorporated: GOBI SDK. All rights reserved. Portions © 2010 Sierra Wireless, Inc: Sierra SDK. All rights reserved. Portions © 2012 Google, Inc: Android SDK. All rights reserved. Portions © 1999–2013 Developer Express Inc. All rights reserved. Portions © 2000-2013 The Legion Of The Bouncy Castle (http://www.bouncycastle.org). All rights reserved.

Portions © 1995, 2010, Oracle and/or its affiliates. All rights reserved. This product includes software whose copyright is owned by, or licensed from, MySQL AB and Sun Microsystems.

Portions © 2014 Microsoft Corporation: ASP.NET AJAX Control ToolKit, Bing Maps, Visual Studio 2008, Visual Studio 2013, .Net Framework and VC, VC#, Windows Installer XML (WIX). All rights reserved.

All map-related contents of this product are Copyright © 2014 Microsoft Corporation and/or its suppliers, One Microsoft Way, Redmond, WA 98052, USA. All rights reserved.

Map-related contents may be saved, downloaded and printed in order to document and archive location-based data and reports.

Microsoft or Microsoft’s suppliers own the title, copyright, and other intellectual property rights to map-related service and content. Microsoft, Windows, Windows Live, Windows logo, MSN, MSN logo (butterfly), Bing, and other Microsoft products and services may also be either trademarks or registered trademarks of Microsoft in the United States and/or other countries. The names of actual companies and products may be the trademarks of their respective owners. Any rights not expressly granted in this contract are reserved.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org)

Original GDataXML: Copyright (c) 2008 Google Inc Example project and HTML addons: Copyright (c) 2012 Simon Grätzer Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

License (X11/MIT). Portions © 2014 Eli Grey: FileSaver.js and Blob.js Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense,

and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

As noted above, the NetMotion Wireless software contains and is distributed along with software code or products from third parties ("Third Party Software"). NetMotion Wireless has entered into separate agreement(s) securing the ability to distribute or sublicense such Third Party Software in conjunction with the NetMotion Wireless software. Any Third Party Software that is associated with a separate license agreement ("Third Party License") is licensed to you under the terms of that Third Party License. The terms of a Third Party License apply only to the specific software code or product of the named third party and do not extend to any other portion of the software licensed by NetMotion Wireless. Applicable Third Party Licenses are available at:

http://discover.netmotionwireless.com/rs/netmotionwireless/images/NetMotion-Wireless_Locality_Third-Party-License-Agreement.pdf

Trademarks and Patents

NetMotion® is a registered trademark of NetMotion Wireless, Inc. and NetMotion Wireless Locality™ and Locality Cloud™ are trademarks of NetMotion Wireless Inc.

Microsoft®, Windows®, Active Directory®, Internet Explorer®, Windows 7®, Windows 8®, and Windows Server® are registered trademarks of Microsoft Corporation. This product includes software whose copyright is owned by, or licensed from MySQL AB and Sun Microsystems. All other trademarks, trade names or company names referenced herein are used for identification purposes only and are the property of their respective owners.

NetMotion Wireless Locality technology is protected by one or more patents pending.

NetMotion Wireless, Inc., attempts to provide complete and accurate printed and online documentation for our products, however, errors or omissions are possible. Please send comments or suggestions for improving our documentation to [email protected].

8/10/15

NetMotion Wireless, Inc.

701 N 34th Street, Suite 250 Seattle, WA 98103 USA +1.206.691.5500

NetMotion Technical Support

A Technical Note Library and other support resources are available on our web site at www.netmotionwireless.com

http://www.netmotionwireless.com

http://discover.netmotionwireless.com/rs/netmotionwireless/images/NetMotion-Wireless_Locality_Third-Party-License-Agreement.pdf

Table of Contents | i

Table of Contents

Chapter 1Introduction to NetMotion Wireless Locality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Locality Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1How Locality Saves You Money . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2How Locality Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Locality System Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Enhancing Reports with Mobility Analytics Module Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4What’s New in NetMotion Locality Version 3.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4Hardware and Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Locality Agent / Locality Server Software Version Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Locality Server Database Version Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7System Requirements—Small Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7System Requirements—Medium Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8System Requirements—Large Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10System Requirements—Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Locality Agent Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

Locality Terminology and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Chapter 2Locality Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Locality System Architecture—On Premises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21Locality System Architecture—Cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22How Reported Time is Determined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24Locality Agent Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

Supported Third-Party Adapters and GPS Receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25GPS and Location Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Security Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Chapter 3Installing the Locality Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Recommendations for Deploying Locality Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Firewall Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Disabling Antivirus or Anti-Spyware Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Keeping the Windows Server Up to Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28Enabling Required Windows Server Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Installing Locality on Virtual Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29Using Client Authentication to Deploy Locality Securely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

Locality System Deployment Work Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Locality Server Pre-Install Check List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30Locality System Deployment Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Obtaining Locality Server and Agent Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32Installing the Locality Server System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32Locality Configuration Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Running the Configuration Wizard Later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Configuration Wizard: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Configuration Wizard: Create Locality Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Configuration Wizard: Configure Locality Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Configuration Wizard: Update Locality Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Configuration Wizard: Restore Locality Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Configuration Wizard: Add Analytics Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42Configuration Wizard: Enable iOS Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49Configuration Wizard: Configure iOS Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Configuration Wizard: Enable Client Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53Configuration Wizard: Configure Client Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Configuration Wizard: Configure Alerts and Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56Configuration Wizard: Add Locality License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Configuration Wizard: System Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60Configuration Wizard: Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

NetMotion Wireless Locality System Administrator Guide

ii | Table of Contents

Using Shortcuts to Open Locality Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60Upgrading from Locality Server v1.x to Locality Server v3.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Upgrading Your Locality v2.x Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

Upgrading Your Locality v2.x Server—Work Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61Upgrading Your Locality v2.x Server—Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

Changing Your Locality v3.x Server Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63Changing Memory Capacity on the Locality Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64Changing the Size of Your Locality Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

Uninstalling Locality Server Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

Chapter 4Installing Locality Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Considerations when Deploying Locality Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

Planning for Security—Client Authentication and Server Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67Firewall Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

Obtaining Locality Agent Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70Deploying the Locality Agent (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

Deploying Locality Agent Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71Securing Locality Agent Settings, Data, and Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71Deploying Locality Agent with a Remote Broadband Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73Passthrough Rules for Mobility Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76Deploying Locality with Adapters that Require a Locality Filter Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76

Locality Agent Installation Overview (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76Installing the Locality Agent Manually. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77Automating Installation of the Locality Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80Testing a Locality Agent Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

Locality Agent Installation Overview (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92Installing the Locality Agent (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93Configuring the Locality Agent for the First Time (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

Locality Agent Installation Overview (iOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96Installing the Locality Agent (iOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97Enrolling a Device in the Locality Inventory System (iOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

Upgrading Locality Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Upgrading Locality Agent (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Upgrading Network Adapter Firmware on a Locality Agent (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Upgrading Locality Agent (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Uninstalling Locality Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Chapter 5Configuring Locality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Configuring the Locality Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Configuring the Locality Server to Use a Signed Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Configuring Automatic Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Configuring Locality to Send Agent Data to a Syslog Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Configuring Locality Agents (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Specifying a Locality Server Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Adding an Authentication Code for Advanced Client Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Specifying a GPS Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Specifying Auto-Start for Integrated GPS Receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Recommendations for Standalone GPS Receiver Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Configuring Locality to Use a Remote Broadband Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Configuring Locality to Use a Mobile Hotspot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Monitoring Multiple Adapters on the Same Agent Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Configuring Locality Agents (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Configuring Locality Agents (iOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Chapter 6Exploring Locality Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Using the Locality Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Data Analysis Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Selecting Locality Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

General Rules for Selecting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125


Table of Contents | iii

Selecting Locality Map Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Selecting Locality Report Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Bookmarking Views of Locality Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Managing Locality Bookmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Chapter 7Analyzing Network Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Analyzing the Carrier Network Using the Coverage Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Selecting Locality Coverage Map Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Creating a Coverage Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Tracing Connectivity with the Device Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Selecting Locality Device Map Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Creating a Device Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Analyzing Technology Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Understanding Technology Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155Analyzing Adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Analyzing the Effect of Compression on Network Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Chapter 8Analyzing Network Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Key Features of the Network Usage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Reported Data Usage: Locality Versus Your Carrier Bill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Analyzing Network Usage by Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Examining Trends in Network Usage by Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Key benefits of the Carriers Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Analyzing Network Usage by User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Understanding a User’s Network Usage Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Key Benefits of the Users Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Analyzing Low Plan Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Key Benefits of the Low Plan Usage Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Identifying when a Plan Was Last Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Key Benefits of Last Used Plans Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Analyzing Network Usage by Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Key benefits of Application Usage Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Mobility Application Bytes Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Mobility Application Bytes by User Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Understanding Application Data Usage Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Understanding Usage Totals for Mobility and Locality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Chapter 9Analyzing GPS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Key Features of the GPS Metrics Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174Selecting Locality GPS Metrics Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174GPS Feed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

How to Interpret Patterns in the GPS Feed Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177GPS Drops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

How to Interpret Patterns in the GPS Drops Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Chapter 10Examining Dropped Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Analyzing Trends in Dropped Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Analyzing Dropped Connections in Terms of Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Chapter 11Keeping Track of Network Adapter Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Adapter Population . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Adapter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Chapter 12Analyzing Mobile Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Viewing Mobile Diagnostics Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193Viewing Mobile Diagnostics Report Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194


iv | Table of Contents

Chapter 13Managing Locality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Using the Locality Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Logging on to the Locality Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197Changing the Console User Password (Locality Cloud Only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Managing Access to the Locality Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Monitoring Locality System Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Monitoring Locality System Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Monitoring Locality Console User Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Monitoring Mobility Analytics Communication Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203Locality Server Version and Product Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Managing Alerts and Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Creating and Editing Alerts and Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204Viewing Alert History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Viewing System Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206Managing Locality Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Adding and Removing Locality License Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Reviewing the License State of Locality Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Monitoring Agent Device Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Managing Agent Device Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Using Client Authentication to Deploy Locality Securely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Creating Client Authentication Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Distributing Client Authentication Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Editing Client Authentication Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Reviewing Device Provisioning Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Renewing a Signed Client Identity Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Managing the iOS APNS Client Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221Managing Mobile Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Understanding Built-In Mobile Diagnostics Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Adding Custom Mobile Diagnostics Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223Automating Mobile Diagnostics Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Mobility Client Policy Integration with Mobile Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Mobile Diagnostics Agent Compatibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Managing Locality Cloud User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Adding a New Locality Cloud User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Resetting a User Password (Locality Cloud) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Editing a Locality Cloud User Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Deleting a Locality Cloud User Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Changing Your Own Locality Cloud User Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Exporting Coverage Data for Use in GIS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Configuring Coverage Data Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Managing Exported Coverage Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Working with Coverage Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Coverage Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

Managing the Locality Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Reviewing the Status of the Locality Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235About Automatic Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Backing Up the Locality Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Restoring the Locality v3.x Database (Locality Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Changing the Locality Database (Locality Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Data Availability in Maps and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Maintaining the Locality/Mobility Analytics Database Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Moving a Locality Deployment (Locality Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Chapter 14Troubleshooting Locality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Troubleshooting the Locality Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Testing Locality Agent/Server Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Working with Locality System Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Locality Server Status Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Gathering Locality Server Diagnostic Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Troubleshooting the Connection with Mobility Analytics Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246


Table of Contents | v

Troubleshooting the Locality Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Finding Server Addresses and Version Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248Coverage Map: No Data Found in Mapping Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Data Display Anomalies in Device Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249

Troubleshooting the Locality Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Troubleshooting the Locality Agent (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Troubleshooting the Locality Agent (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Troubleshooting the Locality Agent (iOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Locality Agent License Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Configuring Agents to Accept Locality Server Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Locality Agent Status Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Chapter 15Locality Agent Interface Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Locality Agent Interface (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Locality Agent Configuration (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Locality Agent Status (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272Locality Agent Mobile Diagnostics (Windows) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Locality Agent Interface (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275Locality Status and Diagnostics (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276Locality Settings (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278Locality Diagnostics Screen (Android) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Locality Agent Interface (iOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Locality Agent Status (iOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Locality Agent Diagnostics (iOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280Locality Agent Settings (iOS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283


vi | Table of Contents


Chapter 1 - Introduction to NetMotion Wireless Locality | 1

Chapter 1Introduction to NetMotion Wireless Locality

NetMotion Wireless Locality™ is a network performance management system for monitoring the health of your mobile wireless network, and for helping you get the most out of your investment in mobile technology. Using data gathered directly from your mobile devices, Locality shows you what your mobile work force is experiencing out in the field, and what your wireless carriers are providing.

Locality is offered in two configurations, which are both described here:

Locality Server—This is an “on premises” deployment where you install the server software and manage the computer that hosts it.

Locality Cloud—Your deployment and administration are handled by NetMotion Wireless. You administer your users, data and reports just as you would with an on-premises deployment, but NetMotion Wireless handles purchasing, deploying, updating, and managing the physical server. Your Locality server is a “private cloud” deployment so that there is no chance of your data being co-mingled with other customer’s data.

Locality Documentation The following Locality documentation is available:

The Locality server online help covers both server and client components for all supported operating systems. It is web-based and context-sensitive.

The System Administrator Guide (PDF) is available on the NetMotion Wireless Customer Portal; it can be downloaded along with the Locality software. It has the same content as the context-sensitive online help.

For Locality agents running on Windows, online help is installed and available from the Locality application. On Android and iOS devices, the Locality agent app does not include online help.

The Readme is installed with the Locality server and also available on the Customer Portal. It has last-minute information pertinent to this release and a link to Known and Resolved Issues.

You can also find white papers, a Technical Note library, and other resources on the NetMotion Wireless web site:


To open online help from the Locality console

Click Help on any Locality console page or dialog box. Online help will open in your default browser and display a topic that describes the settings and options on that page.

One of the quickest ways to find information is to use the full-text search capability in the help. Search results are ranked by how well the topic matches the search criteria. To find an exact string, enclose it in double quotes (for example, “custom tests”).



2 | Chapter 1 - Introduction to NetMotion Wireless Locality

Microsoft Internet Explorer

Online help for the Locality console is web-based and is implemented using JavaScript. You cannot open Locality console help using Internet Explorer (IE) unless the browser is configured to trust the NetMotion Wireless site, or it is configured to enable web pages with active content. It depends on the level of security you want at your site:

° Adding the NetMotion Wireless site to the Trusted Zone allows active content (including JavaScript) to be available for the Locality documentation but not for the Internet as a whole.

° When you configure IE to enable web pages with active content, the setting applies to all sites.

If your browser cannot display help, you will see a page with instructions on how to change its settings.

How Locality Saves You Money Locality saves your organization money by showing you not only what’s going on in the field, but also what can be improved. The comprehensive reports in Locality help you identify areas where you can cut costs, increase productivity, and streamline operations, as well as troubleshoot problems. Here are just some ideas on how to use the collected data:

Plan and cost management, productivity—Find out whether your mobile worker data plans are under-used and implement plan or policy changes accordingly, or find out how much data is being used over given time periods so that you can establish baselines, track trends, and identify outliers.

Discover the extent to which network problems affect specific applications, forcing mobile workers to lose data and relaunch the program, or identify non-business network use and evaluate its impact on productivity and network performance. See “Analyzing Network Usage” on page 161 for details.

IT/Operations—Evaluate trends in network performance to identify problems resulting from technology, radio hardware, location, or other environmental factors, or evaluate trends and outliers in data usage to identify potential problems or bottlenecks. See “Analyzing Network Performance” on page 139 for details.

Help desk—Locality can help the technician determine whether a wireless network is having localized or widespread problems, get a mobile worker’s location and device details to find out which network, adapters, and firmware versions he or she is using. See “Analyzing the Carrier Network Using the Coverage Map” on page 140 and “Analyzing Network Performance” on page 139 for details.

Locality’s interactive user interface lets you drill into any element and filter on the data you want to see. With the map-based reports you can view the real-time experience of one device, zoomed down to the neighborhood level, then quickly switch to a map that displays the broader experience of your entire mobile work force—such as where signal quality was excellent or very weak over the past month, or where a carrier provided 3G instead of the expected 4G.

Reports help you analyze details or overall trends involving your organization’s data plans, such as what your overall data usage was on a given month, who is about to exceed the plan limits, and who is not using the data plan. The reports also give you at-a-glance insight into who is using which applications on their mobile devices and how much, along with which devices are unused.

How Locality Works The Locality agent is a service that runs in the background on mobile devices. At a regular interval, the agent transmits data to the Locality server via HTTPS. The data includes information such as where the device is located, which carriers are handling its connection, what the current signal quality is, and who is logged on to the device.

Information collected by the Locality agents is sent to the Locality server, which processes the data and then forwards it to the Locality database. Information in the database is then made available for display and analysis in interactive maps and reports in the Locality console. Running as a Windows service, the server also monitors the data feed from other server system components.



For a diagram and quick overview of how the Locality components interact, see “Locality System Architecture—On Premises” on page 21.

Locality System Components NetMotion Wireless Locality consists of two software systems: a server system and an agent that runs on each mobile device. Optionally, if you have deployed Mobility from NetMotion Wireless, Locality can also incorporate data from an existing Mobility Analytics Module.

Locality Server

A Locality system includes the following configuration and management applications:

Locality Agents

The Locality agent can be installed on Windows, Android, and iOS devices:

Server System Component Description

Locality console A web-based application for monitoring your wireless network and helping you identify key issues.

See “Using the Locality Console” on page 197 for more information.

Locality Configuration Wizard (Not available for Locality Cloud) A wizard that runs automatically when you install the Locality server.

See “Locality Configuration Wizard” on page 33 for more information.

Locality database A database that stores Locality configuration settings and the data collected by Locality agents.

See “Managing the Locality Database” on page 234 for more information.

NetMotion Wireless Mobility Analytics Module

(Optional) If you have a Mobility deployment that includes the Mobility Analytics Module, you have access to additional information for understanding how applications and devices are using resources.

See “Enhancing Reports with Mobility Analytics Module Data” on page 4 for more information.

Platform Description

Windows See “Locality Agent Interface (Windows)” on page 267 for an overview. A help system for end users is also available.

Android See “Locality Agent Interface (Android)” on page 275 for an overview. There is no Locality help installed on the device.



Enhancing Reports with Mobility Analytics Module Data

Mobility from NetMotion Wireless includes an optional component for detailed reports called the Mobility Analytics Module. If you are using Mobility v9.5 or later, Locality can use some of the data stored in the reporting database to provide additional information for understanding how applications and devices are using resources on your mobile wireless network.

With information from the Mobility Analytics Module you are able to analyze system usage and activity in greater detail:

Observe mobile worker application usage trends over time Know when peak usage occurs, so you can plan for growth and capacity See which applications are consuming the most resources and where usage could be curtailed See what percentage of the total amount of data for a device was compressed by Mobility

See “Analyzing the Effect of Compression on Network Performance” on page 158 and “Analyzing Network Usage by Applications” on page 169 for information about reports that are added when the Mobility Analytics Module is part of your deployment.

Mobility Analytics Module Version Requirements

To enhance Locality reports with Mobility analytics data, the following software version requirements apply:

Locality server v3.x is compatible with Mobility v9.5 or later Locality server v1.20 to Locality v2.10 is compatible with Mobility v9.0 or later

If you are upgrading Locality v2.x to v3.x and your previous version of Locality incorporated data from Mobility Analytics Module v9.5 or later, you must re-establish the connection between Locality and the Analytics Module after the Locality server is upgraded. See “Configuration Wizard: Add Analytics Data” on page 42 for more information.

What’s New in NetMotion Locality Version 3.10 Locality v3.10 includes these changes and new features:

Syslog support—Locality can send the data it gathers from mobile devices—running on Windows, iOS, or Android—to a syslog server so that you can use your own tools and applications, such as Splunk, to monitor the health of your mobile wireless network.

iOS The following features are supported on iOS mobile devices:

Mobile Diagnostics is a separately licensed module that runs built-in and custom tests on Locality agents to diagnose connectivity and performance issues experienced in the field. To support this feature on the iOS platform, the Locality agent is installed as an app.

For information about setting up Diagnostics in the console, see “Managing Mobile Diagnostics” on page 221; for a description of how this looks on the iOS device, see “Locality Agent Diagnostics (iOS)” on page 280.

You can include iOS information in inventory reports in the Locality console. Mobile Device Management settings are used to allow Locality to collect data from the iOS device using the Apple Push Notification service (APNS). See “Implementing Support for iOS Inventory Reporting” on page 50 for details.

There is no Locality help installed on the device.

Platform Description



There are several types of Locality data you can gather and send to the syslog server:

See “Configuring Locality to Send Agent Data to a Syslog Server” on page 113 for setup information; for tables showing the key/value pairs organized by syslog message type, seethe syslog section in the online help.

Mobile Diagnostics—If your Locality deployment is licensed for Mobile Diagnostics and users run into any issues while using Locality—for example, an application is not working, or there is no network access—they can generate a diagnostic report that will also be available to you in the Locality console. This feature is now available on Android and iOS, in addition to Windows:

° Android and iOS apps—Install the diagnostics app from the Google Play Store or Apple Store and use it to find the likely reason for connectivity issues. Users can see a summary and details for each test, which can also be run in “standalone mode.”

The diagnostic capabilities differ slightly between platforms; see “Mobile Diagnostics Agent Compatibility” on page 226 for more information.

Support for Windows 10—The Locality client is supported on Windows 10 (Pro and Enterprise Editions) for 32- and 64-bit operating systems. Clients running on Windows 10 should connect to a Locality server running v3.0 or later. (The client can connect to a v2.0 server, but v3.0 or later is required for diagnostics reports.)

Upgrading from Windows 7 or Windows 8.x to Windows 10 with Locality installed is not supported. If you plan to upgrade the operating system for any of your Windows devices, first uninstall the client, upgrade the operating system, and then install the Locality client for Windows.

Adapter matrix updates—Support for the following adapters has been added in v3.10:

° Verizon Jetpack MiFi 6620L mobile hotspot° Huawei K5150 USB stick° CradlePoint IBR1100 test pass complete

For a complete list of supported adapters, see Network Adapters and GPS Receiver Matrix. Locality Support Data shortcut for Locality server—If you are working with NetMotion

Wireless Technical Support on a Locality server issue, you may be asked to gather diagnostic information. There is now an easy way to do this from the Start page. See “Gathering Locality Server Diagnostic Information” on page 245 for more information.

Consolidated documentation—Both a locally installed Locality server and Locality Cloud have the same set of documentation; differences are clearly labeled.

Locality Data Description

Alerts Alerts and Messaging is a separately licensed module that enables you to generate alerts and messages based on criteria that you define in the console. You can send these alert criteria to the syslog server.

The alerting system also supports sending alert messages to syslog (in addition to email and SMS), for better integration with enterprise logging and alerting systems.

Device Samples The Locality agent is a service that runs in the background on mobile devices. It transmits data to the Locality server, including its location, which carriers are handling its connection, what the current signal quality is, and who is logged on to the device.

Mobile Diagnostics Mobile Diagnostics is a separately licensed module that runs built-in and custom tests on Locality agents to diagnose connectivity and performance issues experienced in the field.

Mobility Analytics If you are running Mobility and have the Mobility Analytics Module, Locality can provide additional information about the applications running on Locality devices. For example, you can observe mobile worker application usage trends over time and see which applications are consuming the most resources and where usage could be curtailed.


http://www.netmotionwireless.com/support/docs/Locality/matrix/NetMotion-Wireless-Locality_Supported-Network-Adapter-and-GPS-Receivers.pdf

http://www.netmotionwireless.com/support/docs/Locality/310/help/localityhelp.htm?single=1&context=nmwlocalityconsole&topic=syslog


Hardware and Software Requirements The requirements for Locality server versus Locality Cloud are very different, since you do not need to install or manage the server if you have the latter.

System Requirement Details (Locality Server Only)

You must install all Locality server components on a single computer; for best performance the computer should not be running any third-party applications (such as backup software). In general, computers with additional processors or faster processors support greater activity by a larger number of users.

The Locality server software supports a number of deployment sizes. All are installed on a local host, except for Standard, which is installed on a VM:

For agent requirements, see “Locality Agent Requirements” on page 15.

System Requirement Details (Locality Cloud Only)

The Locality Cloud server v3.x enforces client authentication security. It will accept data only from mobile devices running Locality agent v2.x or later. All earlier versions of the Locality agent will be rejected by the server.

To connect with the Locality Cloud server, the Locality agents must be deployed with an authentication code. The code allows the agent to be provisioned with a signed client identification certificate and issued a Locality device license.

For deployment details, see “Installing Locality Agents” on page 67.

Locality Agent / Locality Server Software Version Requirements

Locality server v3.x accepts data only from Locality agents v2.x or later; data from earlier versions of the Locality agent will be rejected by the server. To ensure that unreported data collected by Locality agents is not lost following a server upgrade, all Locality agents should be upgraded to v2.02 or later prior to upgrading Locality server to v3.x.

Agents reporting to Locality Cloud are required to use client authentication in order to connect and send data securely.

Mobile Diagnostics (an optional feature) was introduced in Locality v3.0. Consult the following table for server/agent compatibility details:

Deployment Size Locality Agent Devices For Details...

Small 1-1,500 “System Requirements—Small Deployment” on page 7

Medium 1,501 to 5,000 “System Requirements—Medium Deployment” on page 8

Large 5,001 to 15,000 “System Requirements—Large Deployment” on page 10

Standard 1-15,000 “System Requirements—Virtual Machine” on page 11



Locality Server Database Version Compatibility

(Locality server only) The Locality server v3.x system backup process stores all system data in a single folder (default path: C:\ProgramData\NetMotion Wireless Locality Server\MySQL\data).

The v3.x database backup format is compatible with backups produced by Locality server v2.0 and later.

Due to changes in system architecture, a v1.5x database must be converted to a new format when it is restored on a v3.x server.

° If your Locality v1.5x database backup does not include Mobility analytics data, use the v3.x Locality Configuration Wizard to upgrade your old database to the new v3.x backup format and automatically restore it.

° If your Locality v1.5x database includes Mobility analytics data, do not attempt to restore the Locality v1.5x database backup on Locality v3.x without assistance from NetMotion Wireless Technical Support. Your database restoration process will require some extra steps, which Technical Support will explain to you.

The v3.x system backup format is not backward-compatible with backups produced by Locality server v1.0 through v1.4. If you are running Locality v1.4 or earlier, contact NetMotion Wireless Technical Support for help to determine the best upgrade method for your Locality deployment.

System Requirements—Small Deployment

(Locality server only) A small Locality deployment is intended for deployments with no more than 1,500 Locality agents and 10 simultaneous console users. While the small server deployment model specifies that only one disk is required for all components, a separate hard disk drive is highly recommended for storing the Locality database.

All Locality server components must be installed on a single computer that meets the following minimum requirements:

Item Small Deployment - Required Small Deployment - Recommended

Operating system

U.S. English language version of either:

Windows Server 2008 R2 Enterprise or Standard Edition with SP1 and with .NET Framework 4 and ASP.NET 4 enabled

Windows Server 2012 Datacenter or Standard Edition with .NET Framework 4 and ASP.NET 4.5 enabled

Windows Server 2012 R2 with .NET Framework 4 and ASP.NET 4.5 enabled

Locality server program files must be installed on the Windows system drive.

(same)

CPU Processor speed: 2.2 GHz 2 cores

(same)

Memory 8 GB (same)



System Requirements—Medium Deployment

(Locality server only) A medium Locality deployment is intended for deployments of between 1,501 and 5,000 Locality agents and 10 simultaneous console users.

Disk on host computer

This is the hard drive of the main computer, which includes all operating system files, the Locality server installation, the Locality database, database backup and archive, and transaction logs:

250 GB of free disk space available

This is the hard drive of the main computer, which includes all operating system files, the Locality server installation, the database backup and archive, and transaction logs:


Disk 2 n/a Store the Locality database data files on a separate physical drive on the hosting computer:


Internal network

High availability and quality Gigabit bandwidth

(same)

Browser The Locality console is a 64-bit ASP.NET application running on IIS 7.0 or 7.5. JavaScript is required to operate the console and to view online help. In addition. The Locality console (browser) must be configured to accept and store cookies from the console web address.

Internet Explorer 9, 10, or 11 Firefox 3.6.25 or later Google Chrome, current version

(same)

Internet access If the Locality Server Setup program does not find appropriate versions of IIS Server, IIS Roles, or ASP.NET on the host computer, it attempts to install and enable the missing feature(s). To do so, Setup must have access to the public Microsoft Windows Update Server.

In order to retrieve map images, the Locality console (browser) must have Internet access.

If you want to export Locality console maps in PNG format, the Locality server requires outbound access to http://dev.virtualearth.net/webservices/v1/imageryservice/imageryservice.svc on port 80 in order to retrieve map images.

(same)

(Optional)

Mobility Analytics Module

Locality can connect to your Mobility Analytics Module, if you are using Mobility version 9.50 or later.

(same)

Item Small Deployment - Required Small Deployment - Recommended




Item Medium Deployment Requirements

Operating system U.S. English language version of either:





CPU Processor speed: 2.2 GHz 4 cores

Memory 16 GB

Disk 1 This is the hard drive of the main computer, which includes all operating system files, the Locality server installation, and the database:


Disk 2 A second drive provides redundancy and protects against data loss; it holds the database backup and archive, and transaction logs.


Internal network High availability and quality Gigabit bandwidth

Browser The Locality console is a 64-bit ASP.NET application running on IIS 7.0 or 7.5. JavaScript is required to operate the console and to view online help:

Internet Explorer 9, 10, or 11 (with JavaScript) Firefox 3.6.25 or later (with JavaScript) Google Chrome, current version (with JavaScript) The browser connecting to the Locality console must be

configured to accept and store cookies from the console web address.


The browser connecting to the Locality console must have Internet access to retrieve map images.


If you do not need to do PNG exports, the Locality server does not require direct Internet access.

(Optional)





System Requirements—Large Deployment

(Locality server only) A large Locality deployment is intended for deployments of between 5,001 and 15,000 Locality agents and 10 simultaneous console users.


Item Large Deployment Requirements

Operating system U.S. English language version of either:





CPU Processor speed: 2.8GHz 12 cores

Memory 64 GB

Disk 1 This is the hard drive of the main computer, which includes all operating system files and the Locality server installation:


Disk 2 Store the Locality database data files on a separate physical drive on the hosting computer:

1.5 TB of free disk space available RAID 10

Disk 3 Store the database backup, archive, and transaction logs on a separate physical drive on the hosting computer:


Internal network High availability and quality Gigabit bandwidth


Internet Explorer 9, 10, or 11 (with JavaScript) Firefox 3.6.25 or later (with JavaScript) Google Chrome, current version (with JavaScript) The browser connecting to the Locality console must be

configured to accept and store cookies from the console web address.



System Requirements—Virtual Machine

(Locality server only) You can install and run a standard server deployment on a virtual machine (VM). A standard Locality server running on a VM supports up to 15,000 Locality agents and 10 simultaneous console users.

Our Testing Process

While the majority of our virtual machine testing and guidance focuses on VMware, Locality can run on any virtualization environment that is supported directly by Windows Server (for example Windows Server with Hyper-V), provided it meets the requirements described in this section. We also test in other virtual environments including physical server configurations, alternative virtualization platforms, and cloud platforms such as Amazon’s EC2 environment. It is important that your environment comply with these guidelines: reduced performance in any of these aspects can cause slow server performance as well as unexpected behavior in the system.

NetMotion Wireless tested the performance of a 100, 600, 1500, 5000, and 15,000 user standard server on a host system running VMWare VSphere version 5.5 release 2. The tests took place under the following conditions:

Locality server deployed on an ESXi test system (see the tables in this section for system details)

On VMware ESXi systems supporting up to 5,000 devices, virtual disks were used for database data storage. For Locality server to support over 5,000 mobile devices, the virtualization environment’s host system must use physical disks.

A full client load was simulated, with the server receiving data from agent devices running 24 hours a day. The client samples were generated at an even rate to provide a steady-state load on the Locality server, and data was transmitted by agent devices at 30-minute intervals.

For acceptable Locality performance, we strongly recommend virtual machine configurations that are equivalent to or better than the test configurations we used.





(Optional)



Item Large Deployment Requirements



Virtual Disk Requirements for Supporting Up to 5,000 Devices

If you plan to host the Locality server in a virtualization environment with virtual disks for database data storage, the following IOPS performance guidelines are recommended:

Virtual disks for the Locality database are not recommended for larger deployments.

Virtual Machine Requirements for Supporting up to 5,000 Devices

The following items are required on any virtual machine that hosts a Locality server with up to 5,000 mobile devices sending data to the server:

Supported Devices IOPS Latency

(ms) vCPU RAM (GB)Root Drive Size (GB)

DB Vol Size (GB)

Backup Vol Size (GB)

100 500 avg <10, spike <20

2 6 80 60 90

600 1000 avg <10, spike <20

2 8 80 125 200

1500 1600 avg <10, spike <20

3 12 80 200 300

5000 2100 avg <10, spike <20

4 20 80 600 900

Item ESXi Deployment - Test Environment

Virtualization environment

Locality can run in any virtualization environment that is supported directly by Windows Server.

Testing was done on a host computer running VMWare VSphere version 5.5 release 2.

Operating system





The operating system must reside on the virtual C: system drive.

CPU 4 virtual CPU cores at a speed of 2.8 GHz per CPU.

If you have fewer than 5,000 agents you do not need as many CPU cores; refer to the table in “Virtual Disk Requirements for Supporting Up to 5,000 Devices” on page 12.

Memory For RAM requirements see “Virtual Disk Requirements for Supporting Up to 5,000 Devices” on page 12.

Virtual Disk1 Root drive dedicated to Locality server. The root drive holds the virtual guest’s operating system files and the Locality server installation.

For disk space requirements see “Virtual Disk Requirements for Supporting Up to 5,000 Devices” on page 12.

Virtual Disk 2 A database volume for storing the Locality database data files.




Virtual Machine Requirements for Supporting up to 15,000 Devices

The following table describes the minimum virtual guest configuration required by Locality to support 15,000 mobile devices and 10 simultaneous console users.

Virtual Disk 3 A backup database volume for storing the database backup, archive, and transaction logs.


Internal network



Internet Explorer 9, 10, or 11 (with JavaScript) Firefox 3.6.25 or later (with JavaScript) Google Chrome, current version (with JavaScript) The browser connecting to the Locality console must be configured to accept

and store cookies from the console web address.

Internet access If the Locality Server Setup program does not find appropriate versions of IIS Server, IIS Roles, or ASP.NET on the host virtual machine, it attempts to install and enable the missing feature(s). To do so, Setup must have access to the public Microsoft Windows Update Server.





Virtualization environment

The Locality 15,000-user standard server deployment can run on a host computer running in any virtualization environment that is supported directly by Windows Server and using physical disks in or attached to the hosting computer.

Testing was done on a host computer running VMWare VSphere version 5.5 release 2.

Operating system





The operating system must reside on the virtual C: system drive.

CPU 12 vCPU (virtual CPU cores) at a speed of 2.8 GHz per CPU

Memory 64 GB




Disk1 Root volume—a physical disk in the host computer, dedicated to Locality Server:

1.5 TB of free disk space available

This disk holds the virtual guest operating system files, the Locality server installation, and the Locality database backup and archive.

Disk 2 Virtual disks for the Locality database are not recommended for larger deployments. In addition, store the Locality database data files separate from the Locality database backup and archive:


Internal network



Internet Explorer 9, 10, or 11 (with JavaScript) Firefox 3.6.25 or later (with JavaScript) Google Chrome (with JavaScript) The browser connecting to the Locality console must be configured to accept

and store cookies from the console web address.








Locality Agent Requirements

You can install the Locality agent on mobile devices running on Windows, Android, or iOS.

Requirements for Windows Devices

Item Requirements

Operating system Windows 10 32/64-bit (Pro and Enterprise Editions) with .NET 2.0 enabled

Windows 8.1 32/64-bit (Enterprise or Pro Edition) with .NET 2.0 enabled

Windows 8 32/64-bit (Enterprise or Pro Edition) with .NET 2.0 enabled Windows 7 32/64-bit (Enterprise, Professional, or Ultimate Edition)

Locality server For Locality agent/server software compatibility requirements, see “Locality Agent / Locality Server Software Version Requirements” on page 6.

Disk space 50 MB free disk space available for install 1 GB free disk space available for data files and logs

GPS receiver A GPS receiver is required in order for correlated location data to be available in Locality coverage maps and device maps. (Without a GPS receiver, network performance data is still collected and available within Locality business intelligence reports.)

The GPS receiver must generate TAIP or NMEA 0183-compliant data. The following GPS receiver types are supported:

A stand-alone GPS receiver or a GPS receiver that is integrated in a network adapter. The receiver must communicate via a COM port.

A GPS receiver integrated in a remote broadband adapter that uses a UDP port (for example, a Sierra AirLink trunk modem).

A GPS receiver available on a Windows location sensor.

Network adapter The Locality Network Adapter and GPS Receiver Matrix identifies the adapter, GPS receiver, and connection manager combinations that have been validated in our test lab. See:






Requirements for Android Devices

Requirements for iOS Devices

There are two main features supported on the iOS platform:

Mobile Diagnostics is a separately licensed module that runs built-in and custom tests on Locality agents to diagnose connectivity and performance issues experienced in the field. The Locality agent is installed as an app.

You can include iOS information in inventory reports in the Locality console. Mobile Device Management settings are used to allow Locality to collect data from the iOS device using the Apple Push Notification service (APNS). In terms of what the end user sees on the iOS device, this feature has no interface.

Compatible Third-Party Network Adapters and GPS Receivers

This topic is for Windows users.

The Locality agent uses a number of third-party items, such as the adapter and driver you use for your carrier connection, a GPS receiver (optional), and your connection manager.

Item Requirements

Operating system Android v4 or later

Locality server For Locality agent/server software compatibility requirements, see “Locality Agent / Locality Server Software Version Requirements” on page 6.

Device storage 20 MB of device storage for the app and data files

Screen on To collect signal quality data, the device screen must be on. If the screen is off, only data about technology type and connection state can be collected.

GPS GPS must be enabled in Android settings in order for correlated location data to be available in Locality coverage maps and device maps. (With GPS disabled, network performance data is still collected and available within Locality business intelligence reports.)

Mobile network The device must support mobile (cellular) networking. WiFi-only devices are not supported.

Item Requirements

Operating system iOS 8 or later

Mobile network The device must support mobile (cellular) networking. WiFi-only devices are not supported, with the exception of the Locality agent (Diagnostics) on iOS, which will work on a WiFi-only device.

Mobile Diagnostics Locality server v3.x or later with Mobile Diagnostics licensed and enabled.

Inventory Management

Locality uses web-based inventory enrollment to configure iOS devices to report inventory data. This requires the following:

Locality server v3.x or later with iOS inventory licensed and enabled, and client authentication enabled.

A Safari browser with “private browsing” mode disabled, and JavaScript and cookies enabled.

A configuration profile that includes Mobile Device Management (MDM). To work correctly, no other configuration profile containing MDM can be present on the device.



The Locality Network Adapter and GPS Receiver Matrix identifies the adapter, GPS receiver, and connection manager combinations that have been validated in our test lab:


Keep in mind:

Adapters are supported only in NDIS mode. To get a validated connection manager, a good place to start is the carrier web site. GPS receivers vary in reliability and quality from model to model. Customers are responsible

for the operation and performance of GPS receivers used in their deployment. GPS receivers must use the NMEA 0183 standard or the TAIP protocol. If you are using a non-

standard GPS receiver, it may be necessary to manually set the COM port’s baud rate to a different value; see “Locality Agent Configuration (Windows)” on page 267 for a description of the Serial Connection settings.

Locality Terminology and Definitions The following is a list of terminology and definitions used in Locality.

Term Definition

adapter This is the network adapter used to connect to a carrier network (your mobile broadband network). It may be an internal adapter (in a laptop or an Android phone), or a separate adapter physically connected to the laptop (for example, a USB dongle). Or, it may be a remote broadband adapter that the laptop accesses through the local network (such as a Sierra Wireless AirLink trunk modem).

Business Intelligence

NetMotion Wireless Locality gives you past and current views into network performance and connection information for your mobile deployment. Built-in tools—maps, charts, graphs, and tables—facilitate the analysis of data and enable you to troubleshoot, produce reports, and make more accurate projections.

carrier The company with which you have a wireless data plan and from which you receive your wireless bill. This is your main carrier.

category A set of Locality maps and reports, grouped together to allow console users to answer similar questions. Reports available within a category share choices made in the selection pane; for example, if you make a time range selection in one report, the other reports within the same category also include that selection.

chart A bar chart, pie chart, or scatter plot that displays data obtained from Locality and (optionally) Mobility. Each Locality report contains a collection of charts and tables.

When you make a selection in a report, any values related to it are also shown; in addition, any selection you make carries over to any related reports (those that are in the same category).

Configuration Wizard

After you install a Locality server, this wizard starts automatically and guides you through the remaining steps required for initial configuration. To make changes to the initial Locality server configuration or to update or restore the Locality database, re-run the Configuration Wizard.

coverage map A map showing aggregated carrier network connection performance metrics for all devices in your mobile deployment over a selected period of time (a day, week, or month). These metrics require that the device running the Locality agent have a functioning GPS receiver. Various elements of network connectivity are shown for each map grid.




current carrier Any carrier providing your wireless connection that is different from your normal carrier. The current carrier may or may not be a partner of your main carrier, and some cellular adapters do not return this information.

The Details window in the Coverage Map indicates the current carrier. When viewing Device Map trace details, the presence of a “current carrier”

indicates that the cellular adapter was on an extended or partner network. If the carrier is listed as Unknown, Locality is unable to determine which carrier is carrying the session.

data usage The amount of mobile data traffic handled by a carrier for a particular device.

database The Locality database stores Locality configuration settings and all the data collected by Locality agents. It must be collocated with the other Locality server components.

device The hardware on which the Locality agent software is running.

device map The device map focuses on the route of a device and its connectivity experience over up 24 hours. It is especially useful when you are troubleshooting connectivity problems. These metrics require that the device running the Locality agent have a functioning GPS receiver.

GPS receiver The Global Positioning System consists of 24 orbiting satellites that allow a user with a GPS receiver to pinpoint his or her location. Location information is used in Locality maps.

On Windows systems, the receiver can be an external device, or built into your hardware:

An external GPS receiver is a stand-alone device with a GPS receiver inside that is not integrated with the adapter, usually connected to the Locality agent device using a serial or USB connection, or a Bluetooth connection.

An integrated GPS receiver is integrated internally with an adapter and provides GPS information to the Locality agent.

On Android devices, GPS must be enabled in Android settings in order for correlated location data to be available in Locality maps.

Without GPS, network performance data is still collected and available within Locality business intelligence reports.

grid cell When you look at a coverage map to find out where, for example, your carrier’s signal is strongest or weakest, the actual area indicated by the colored grid cells changes as you zoom in and out. The map always shows a grid of 16 x 16 pixels; at the highest zoom level the size of the grid is 340 x 340 feet.

Locality agent The Locality software running on user devices, which collects network information.

Locality Cloud The Locality server software provided as a cloud-based SaaS (Software as a Service) product. You can contract with NetMotion Wireless to host your Locality server and provide database maintenance. Locality agents installed on your mobile devices will connect securely to the Locality Cloud server and upload collected data. Credentialed employees can log on to the cloud-based Locality console to work with available reports and maps.

Locality console A web-based application in Locality for monitoring your wireless network, helping you identify key issues, and administering the Locality server system. Current Locality console users are shown on the System > Status page.

Locality server The Locality server is the central data gathering point for the Locality system. The server is a .NET application hosted by IIS. It gathers the information transmitted by Locality agents and adds it to the Locality database.

Term Definition



NMEA 0183 protocol

The National Marine Electronics Association (NMEA) 0183 protocol is an industry-standard GPS location data protocol originally developed for the marine industry. Locality can collect and interpret NMEA data for use in maps and charts.

network technology

An implementation of a mobile telecommunications standard.

Examples: UMTS, EDGE, and HSDPA.

report Within each category in the Locality console (for example, Network Usage and Inventory) there is a collection of related reports. A report can be any combination of charts, graphs, and tables.

selections Parameters used to query the Locality database and present results in the form of a Locality report or map. When you make a selection, all of the values related to it are also shown; in addition, any selections you make carry over to reports in the same category.

selection pane An area on the left of each Locality report or map where you make context-sensitive filter selections. You can step back through your selections, or clear them individually.

server The central data gathering point for the Locality system. The server is a .NET application initiated by the Locality server service and hosted by IIS. It gathers the information transmitted by Locality agents and adds it to the Locality database.

signal quality Signal quality is determined by a NetMotion Wireless proprietary process that takes into account multiple variables such as field strength, signal-to-noise ratio, and technology type.

For coverage, Locality calculates signal quality by adding the measured signal quality for each agent sample within a map grid cell, and then displaying a color that represents the average of those samples

TAIP protocol The Trimble ASCII Interface Protocol (TAIP) is a Trimble-specific digital communication protocol used to report GPS location data. Locality can collect and interpret TAIP data for use in maps and charts.

technology generation

A family of technologies for mobile telecommunications.

Examples: 2G, 3G, and 4G.

Term Definition


Chapter 2 - Locality Architecture | 21

Chapter 2Locality Architecture

NetMotion helps you monitor the performance of your mobile wireless network by collecting location-specific data (latitude, longitude, and signal quality) from Locality agents running on mobile devices and enabling you to view it in different ways and report on it.

If you have the Mobility Analytics Module installed at your site, Locality can use Mobility Analytics data to provide additional information for reports about the performance of your mobile wireless network, such as which applications are running and for how long.

This section describes the system architecture of a Locality deployment.

Locality System Architecture—On Premises A Locality deployment includes the Locality server and Locality agents. Here’s a quick overview of how they interact and how they are secured, followed by more detail.


22 | Chapter 2 - Locality Architecture

The Locality system includes the following components:

Locality System Architecture—CloudA Locality Cloud deployment includes the Locality Cloud server and Locality agents. Here’s a quick overview of how they interact and how they are secured, followed by more detail.

Component Description

Locality server The Locality server is a .NET application hosted by IIS. It gathers the information transmitted by Locality agents and adds it to the Locality database.

Locality console The web console is on the same computer as the Locality server.

Business Intelligence The Locality Business Intelligence tools present past and current views into network performance and connection information for your mobile deployment. Built-in tools—maps, charts, graphs, and tables—facilitate the analysis of data and enable you to produce reports, troubleshoot, and make more accurate projections.

Locality database The Locality database stores all the data collected by Locality agents and Locality configuration settings. It is usually stored on a separate drive; see “Hardware and Software Requirements” on page 6 for more deployment details.

Mobility Analytics Module (optional)

Locality customers who also have Mobility and the Mobility Analytics Module (v9.50 or later) can use its analytics data to better understand how applications and devices are using resources on your mobile wireless network. See “Integrating Mobility Analytics Data into Locality Reports” on page 44 for details.

Locality agents The agents periodically transmit system, adapter, and location data to the Locality server.



Item Description

Locality Cloud security enforces mutual authentication and data encryption: all communication between Locality agent and server is managed by the Transport Layer Security (TLS) protocol using x509 certificates (client and server). TLS security ensures message privacy, message integrity, and mutual authentication of agent and server identity.

Locality reporting data: The NetMotion Wireless Cloud team performs all database management services for your Locality Cloud server (data redundancy, regular backups, and so on).

Locality console: Built-in business intelligence tools—maps, charts, graphs, and tables—facilitate the analysis of data from Locality agents and (optionally) the Mobility Analytics Module. The connection between the console and Locality Cloud uses the TLS protocol. Users have role-based access to the console and are required to authenticate using credentials assigned by the Locality administrator.



How Reported Time is Determined Creating accurate and meaningful Locality reports requires that there be a consistent time reference between all Locality agent devices.

All time is transmitted and stored in the Locality database as UTC time. Locality agents use system clock time for date/time information in their own local time zone.

While system time is always available, its accuracy from agent to agent can vary. For this reason, configure Windows devices to use the operating system’s automatic date and time feature, if available, to synchronize all agent system clocks. The Android operating system provides an automatic date and time feature, which is enabled by default.

In the Locality console, the time zone you see in maps and reports is based on the Locality server system clock. For example, if the Locality server is on PST (Pacific Standard Time) and a Locality device is transmitting data from EST (Eastern Standard Time), device traces are displayed in the console in PST (UTC minus 8 hours), not EST (UTC minus 5 hours).

Locality Agent Architecture Data gathered by Locality agents is periodically transmitted to Locality. Keep in mind that Locality collects performance data only from the monitored adapter; data sent over another interface, such as a WiFi adapter, is not counted.

iOS devices do not collect or send network performance data. Once an hour they report device information (such as manufacturer, model, firmware version), which is used in Locality inventory reports.

Here are some examples of the types of data that are gathered on Windows and Android devices:

Locality customers who also have Mobility and the Mobility Analytics Module (v9.50 or later) can use its analytics data to better understand how applications and devices are using resources on your mobile wireless network.

Item Description

Type of Data Gathered Description

System data Device name.

For Android devices, the device name is constructed using this formula: <email address up to the @ sign>-<device model> (for example, mmcamper-VS920 4G).

The adapter that was monitored and the number of bytes it received and transmitted

User name.

For Android devices, the device account name is the user name. For example: [email protected].

If an Android device has more than one account, the user name is determined as follows:

° If a Microsoft Exchange account is present, it is used. ° If no Microsoft Exchange account is present, a Gmail

account is used. ° If there is no Gmail account, a personal account is used

(for example, Hotmail). ° If no email accounts are present, Locality looks at the

profile.



Locality receives these types of requests from the Locality agent:

Supported Third-Party Adapters and GPS Receivers

This information is for Windows devices only.

The Locality agent’s behavior is influenced by many third-party items, such as the adapter and driver used, and the connection manager and version.

In order to experience the full functionality of the Locality coverage and device maps, a GPS receiver must be activated and functional on Locality devices. Locality supports two categories of GPS receivers:

An external GPS receiver connected via serial or USB port, or using Bluetooth An adapter containing an integrated GPS receiver; in some cases the receiver must be unlocked

or enabled through use of the connection manager

A detailed compatibility matrix for Locality is maintained on the NetMotion Wireless web site:


GPS and Location Accuracy

The location accuracy of network performance data shown on the Locality Coverage Map and Device Map depends on the accuracy of the GPS receiver, the antenna, terrain, and environmental conditions. Location readings that do not meet Locality’s minimum accuracy requirements—for example, readings from a user who was in a tunnel or building—are not displayed on Locality maps. For all such “non-located” devices, network performance, connectivity metrics, and usage data is still collected and included in the information displayed in Locality business intelligence reports.

Security Architecture Locality v3.x has client authentication settings that can be enabled to provide Locality agent account management, authentication and secure communication between Locality agent devices and the Locality server without reliance on a VPN. When client authentication is enabled, all communication between Locality agent and server is managed by the Transport Layer Security (TLS) protocol using x509 client certificates. The credential management solution works on all supported Windows, Android, and iOS platforms:

Adapter data The manufacturer, model, and firmware version of the agent’s monitored adapter.

For Android devices, the firmware version Locality reports is actually the baseband version (the version for the WWAN adapter inside the Android device).

Signal quality Network technology

Location-related data GPS data: latitude and longitude

Agent Request Description

Device registration The server registers the device after it is determined to be valid.

License check The agent checks to ensure that it has a valid license.

Data sample messages (Windows and Android only)

Any messages or requests related to the data collected on the agent and transmitted to the Locality server.

Type of Data Gathered Description




Client authentication ensures that only valid, authenticated Locality agents can connect to the Locality server using X509 client certificates. Agents go through a provisioning process to obtain a unique signed client identity certificate that is used by the Locality server to validate the identity of the Locality agent.

Agent authentication can be further secured by restricting the IP addresses from which certificate provisioning is allowed.

By default, Locality agent v3.x is configured to require a trusted server certificate for server authentication. This ensures that the agent connects only to a trusted server:

° If you are deploying a locally-hosted Locality server, a self-signed certificate may suit your security needs. In this case, your Locality agents should be configured to not require a trusted server certificate.

° The use of Certificate Authority-issued server certificates is required for Locality agents connecting to Locality Cloud.

Note: Mobile devices that connect to a Locality server that has client authentication enabled must do the following (client authentication is always enabled on Locality Cloud):

Run Locality agent v2.x or later Be configured to use client authentication Be configured to require a trusted server certificate

For more information see “Planning for Security—Client Authentication and Server Authentication” on page 67.


Chapter 3 - Installing the Locality Server | 27

Chapter 3Installing the Locality Server

This section explains how to prepare the server for NetMotion Wireless Locality installation, and how to install the Locality server on supported hardware platforms.

Locality Cloud users: If you have a NetMotion Wireless Locality Cloud subscription, your Locality server is installed and maintained by the NetMotion Wireless Locality Cloud service team—you can skip this section. To begin collecting data, install Locality agent software on the mobile devices that you want to track. For details, see “Installing Locality Agents” on page 67.

Recommendations for Deploying Locality Server You must install all Locality server components on a single computer. For best performance the computer should not be running any third-party applications (such as backup software). In general, computers with additional processors or faster processors support greater activity by a larger number of users.

Locality v3.x supports a number of deployment sizes, each with distinct system requirements:

For detailed recommendations and system requirements for both the Locality server and the Locality agent, see “Hardware and Software Requirements” on page 6.

Firewall Configuration

The Locality server uses the following TCP ports for communication:

Deployment Type Size Number of Locality Agents

Physical—local host Small 1,500 maximum

Physical—local host Medium 1,501—5,000

Physical—local host Large 5,001—15,000

Virtual Machine (VM) Standard Up to 15,000 maximum

TCP Port Direction Traffic

443 Inbound If the Locality server is configured to enforce client authentication, Locality agents use port 443 for HTTPS traffic with the provisioning gateway.

If the Locality server is not configured to enforce client authentication, Locality agents use port 443 for HTTPS traffic with the sample gateway.


28 | Chapter 3 - Installing the Locality Server

On the computer that hosts the Locality system, the firewall must allow Locality data to flow through these ports.

Windows Firewall: If you install the Locality server on a computer that has the Windows firewall enabled, the Setup program will automatically add firewall rules that open these ports to allow the Locality system to function properly.

Non-Windows Firewall: If the host computer uses something other than the Windows firewall, you must add rules to allow the Locality server to communicate on these ports.

Additionally, when deploying to a server behind the corporate firewall, the ports need to be opened up in that firewall as well.

Disabling Antivirus or Anti-Spyware Software

Security programs on the computer hosting a Locality server can affect communications within your network and slow system performance, especially in terms of CPU usage. Many of these applications are incompatible with the Locality; even an application that appears to be compatible with Locality can become unusable after an automatic update. Do not install any antivirus or anti-spyware products on the computer hosting a Locality server.

Keeping the Windows Server Up to Date

Maintain the security and reliability of the Locality host computer's operating system. Check for and install new Windows Updates as they become available.

4443 Inbound If the Locality server is configured to enforce client authentication, Locality agents use port 4443 for HTTPS traffic with the sample gateway.

5213 Inbound If the Locality server is configured to accept iOS inventory data, Locality agents on iOS devices use port 5213 for HTTPS traffic with the inventory gateway.

2195

2196

Outbound If the Locality server is configured to accept iOS inventory data from iOS mobile devices, it uses port 2195 and 2196 to communicate with the Apple Push Notification service (APNS) and mobile device management (MDM).

1468 Outbound By default, if the Locality server is configured to send syslog messages, it uses port 1468 to communicate with the syslog server.

80 Inbound HTTP traffic for Locality server console access

HTTP traffic for Locality console business intelligence reports and maps

80 Outbound If you want to export Locality console maps in PNG format, the Locality server requires outbound access to http://dev.virtualearth.net/webservices/v1/imageryservice/imageryservice.svc on port 80 in order to retrieve map images.

8080 Inbound HTTPS traffic for Locality server console authentication (automatic redirect)

8083 Inbound HTTPS traffic for Mobility Analytics data integration. The Locality Connect for Mobility web client, which is installed on the Mobility Analytics server, uses this port to connect to the Locality web service on the Locality server.




Enabling Required Windows Server Features

To support the Locality server, your Windows Server must have the following features enabled:

Locality server Setup automatically installs and enables the .NET Framework if it is not already present.

If Setup determines that ASP.NET, IIS Server, or IIS Roles is not enabled, it tries to use the public Microsoft Windows Update Server to obtain software for the missing feature, and then installs and enables it. Locality Setup will fail and exit if your company uses a corporate server to push out Microsoft Windows Updates. If a Setup failure occurs, contact NetMotion Wireless Technical Support for assistance.

If you also have Mobility 9.50 or later and the Mobility Analytics Module installed, Locality can be configured to obtain Mobility data for reports in the console. See “Integrating Mobility Analytics Data into Locality Reports” on page 44 for details.

Installing Locality on Virtual Systems

You can install and run a Locality Standard server (with up to 15,000 Locality agents) on a virtual system running VMware™ ESXi or any virtualization environment that is supported directly by Windows Server (for example Windows Server with Hyper-V). To prepare for installation, see “System Requirements—Virtual Machine” on page 11.

All features and functions of Locality are supported on VMware ESXi and other virtualization environments with the exceptions and capacity limitations listed below.

In the following configuration guidelines, the virtual guest is a running instance of a virtual machine (an emulated physical machine), and the virtual host is a computer running VMware ESXi that hosts virtual guests. These guidelines are for a Locality server that supports 15,000 Locality agents.

To support 15,000 agents, the resource pool containing the virtual guest for Locality must have enough dedicated CPU cycles and memory to guarantee Locality a total of 28 GHz of CPU and 32 GB of memory. Variable CPU capacity and overloaded VMware ESXi hosts cause erratic and unpredictable results.

You must ensure the Locality server has sufficient CPU and memory to service the mobile deployment.

The only supported and tested virtual guest CPU settings are for 10 virtual processors. The physical hardware that VMware ESXi runs on can have more processors available; however, due to scheduling issues, increasing the number of processors used by a single virtual guest can decrease performance.

The lower the average latency on the disks the better performance will be on the Locality server.

Windows Server Version Required Features

Windows Server 2008 R2 Enterprise or Standard Edition with SP1 or later

.NET Framework 4 ASP.NET 4 IIS Server IIS Roles

Windows Server 2012 Datacenter or Standard Edition

.NET Framework 4 ASP.NET 4.5 IIS Server IIS Roles

Windows Server 2012 R2 .NET Framework 4 ASP.NET 4.5 IIS Server IIS Roles



The installation process used to deploy a Locality evaluation server or a Locality server is the same, regardless of whether the target host is a virtual machine or a regular computer system. In either case, follow this procedure: “Installing the Locality Server System” on page 32.

Using Client Authentication to Deploy Locality Securely

Client authentication provides secure communication between the Locality agent and server installation without reliance on a VPN. This security solution works on all supported Windows, Android and iOS platforms for the Locality agent.

The first time an agent communicates with the server it must be provisioned and have a client authentication certificate created for it to use to secure all subsequent communication with the Locality sample gateway.

The general work flow for establishing secure communication between agent and server is described in “Planning for Security—Client Authentication and Server Authentication” on page 67.

Locality System Deployment Work Flow Prior to installing the Locality server, use the “Locality Server Pre-Install Check List” on page 30 to confirm that your Windows server complies with Locality server requirements. Then perform the tasks in the “Locality System Deployment Task List” on page 31.

Locality Server Pre-Install Check List

To successfully install the Locality server, your Windows server must be configured appropriately. Use this check list to confirm that all pre-requisites have been completed:

Completed Requirement See...

Locality server must be installed on a single computer that meets the requirements of your Locality deployment size (small, medium, large, or virtual machines)

“Hardware and Software Requirements” on page 6

Where needed, add firewall rules that allow the Locality system to use required ports.

“Firewall Configuration” on page 27

Do not install any antivirus or anti-spyware products on the computer hosting a Locality server.

“Disabling Antivirus or Anti-Spyware Software” on page 28

Locality server must be installed on a Windows server that has these features enabled:

ASP.NET IIS Server IIS Roles: Web Server and

Application Server

If a required Windows feature is not already enabled, Locality Setup attempts to install and enable it. To do so, Locality Setup requires access to the public Microsoft Windows Update Server to download software for the feature.

“Enabling Required Windows Server Features” on page 29



Locality System Deployment Task List

For your initial on-site Locality system deployment, complete the tasks below in the order listed. If you are upgrading your deployment, the steps are a little different; see “Upgrading Your Locality v2.x Server” on page 61 or “Upgrading from Locality Server v1.x to Locality Server v3.x” on page 61.

Once you enter a Locality license key in the console and set up the Locality agent on your mobile devices, data begins accumulating in the Locality database.

If you also have Mobility 9.50 or later and the Mobility Analytics Module installed, Locality can be configured to obtain Mobility data for reports in the console. See “Integrating Mobility Analytics Data into Locality Reports” on page 44 for details.

Task Procedure See...

1 Complete the pre-install check list “Locality Server Pre-Install Check List” on page 30

2 Download the current Locality software release files

“Obtaining Locality Server and Agent Software” on page 32

3 Install the Locality server and database

“Installing the Locality Server System” on page 32

4 Complete initial server configuration in the Configuration Wizard

“Locality Configuration Wizard” on page 33

5 Add Locality license key(s)

(Skip if you added Locality license keys in task 4)

“Adding License Keys for a New Installation” on page 208

6 Generate client authentication codes for Locality agents

(Skip if you did not enable Client Authentication in task 4)

“Creating Client Authentication Codes” on page 217

7 Deploy the Locality agent on mobile devices

“Deploying the Locality Agent (Windows)” on page 71

“Installing the Locality Agent (Android)” on page 93

“Locality Agent Installation Overview (iOS)” on page 96

8 Add Locality console users “Managing Access to the Locality Console” on page 198

9 Configure alerts and messages

(Skip if you are not licensed for the Locality Alerts and Messages Module)

“Managing Alerts and Messaging” on page 204

10 Configure Mobile Diagnostics custom tests (optional)

(Skip if you are not licensed for the Locality Mobile Diagnostics Module)

“Adding Custom Mobile Diagnostics Tests” on page 223

11 Sending Locality agent data to a syslog server (optional)

“Using Syslog to Manage Locality Agent Data” on page 191



Obtaining Locality Server and Agent Software Locality software downloads are available from the NetMotion Wireless customer portal. If you don’t yet have logon credentials for the customer portal, contact your NetMotion Wireless partner or sales representative.

To obtain Locality software from the NetMotion Wireless customer portal

1. Log on to the NetMotion Wireless customer portal and click the Software Download tab.

2. Download the current Locality software release files. The Locality installation files can be used to perform either an initial product install or a product upgrade. The following files are available:

3. You can also download the Locality software documentation files. The Readme provides a link to Known and Resolved Issues and may contain installation information specific to the current software version. The System Administrator Guide provides detailed information about deploying Locality, including installation and configuration procedures.

Installing the Locality Server System The Locality server setup file is a self-extracting executable file that installs the Locality server and database on a single 64-bit computer.

File Download Type Description

Locality_Server_x64_<version>_Setup EXE Locality server software for Windows Server 2008 and 2012. This executable file performs a Locality server installation or upgrade. The file includes the installer for .NET 4.0, which is required and will be installed automatically if it is not present.

Locality_Agent_<version>_Setup EXE Locality agent software for Windows, 32-bit and 64-bit. This executable file performs a standard (non-silent) Locality agent installation or upgrade.

Locality_Agent_<version>_Setup MSI Locality agent software for Windows, 32-bit and 64-bit. Use this file to perform a silent installation or upgrade.

Locality_Agent_<version> APK Locality agent software for Android devices. Use this file to perform a Locality agent installation or upgrade.

Note: Locality agent for Android is also available from the Google Play™ Store app. For details, see “Installing the Locality Agent (Android)” on page 93.

Locality_Connect_for_Mobility_<version> EXE (Optional) Locality software for Windows Server 2008 and 2012. This executable file is run on the Mobility Analytics Module server to install the Locality Connect for Mobility web client and configure secure communication and data transfer between the Locality server and the Mobility Analytics Module.

The file includes the installer for .NET 4.5, which is required and will be installed automatically if it is not present.



Use the following procedure to install a Locality server system on either a computer or a virtual machine. If your host computer is a VM, see “Installing Locality on Virtual Systems” on page 29 for VM configuration guidelines.

Note: If you are installing Locality server v2.x as an upgrade, go to “Upgrading from Locality Server v1.x to Locality Server v3.x” on page 61.

To install the Locality server

Note: If the Locality Server Setup program does not find appropriate versions of IIS Server, IIS Roles, or ASP.NET on the host computer, it attempts to install and enable the missing feature(s). To do so, Setup must have Internet access to the public Microsoft Windows Update Server. If your company uses a corporate server to push out Microsoft Windows updates, Setup may fail if these features are not available on your corporate update server. Following a failure, Setup will remove the partially installed Locality server software and exit. If a Setup Failure dialog box opens during Setup, contact NetMotion Wireless Technical Support for assistance.

1. On the computer where you want to install Locality, log on with administrator privileges.

2. Download the Locality server software from the NetMotion Wireless customer portal, and then run the self-extracting executable file.

3. If the Microsoft .NET Framework v4.5 is not already present on your Windows Server, Setup must install it. Click Accept to continue.

To complete the .NET installation, you may be prompted to reboot the server. Locality Setup then resumes automatically.

4. Accept the terms of the license agreement and click Next.

5. Setup shows you where Locality server program files will be installed. You cannot change this setting. Locality server program files must be installed on the Windows system drive.

6. Specify the location where Locality should store server database data files. Click Next to continue.

All Locality server components must be installed on the same computer. For best results, do not store Locality database data files on the Locality server system drive or on a network drive. If available, a separate physical drive on the host computer is recommended. For details, see “Hardware and Software Requirements” on page 6.

Folder path recommendations and requirements for Locality database data files:° Do not use a location that is directly off of the root directory (for example, D:\). The path

must specify the drive and folder name where data files are to be stored. ° Folder path length is limited to 150 characters. A path that exceeds this limitation is

automatically truncated to 150 characters.° The folder path may not contain Windows extended characters.

7. Click Install to start the installation process.

8. A window displays the status of the Locality server installation process, showing the progress on each task.

9. At completion, click Finish to exit Setup. You may be prompted to restart your system. If so, click Yes to restart the computer.

10. Setup automatically opens the Locality Configuration Wizard so that you can provide initial configuration settings and set up the Locality database. See “Locality Configuration Wizard” on page 33 for more information.

Locality Configuration Wizard After Setup installs the Locality server, the Locality Configuration Wizard starts automatically and guides you through the remaining steps required for initial configuration. Once you complete the steps in the wizard and install the Locality agent on your devices, the Locality server can accept connections from Locality agents.



To complete initial setup in the Configuration Wizard

1. The wizard detects that you are installing Locality for the first time on the current computer. You are prompted for the fully qualified domain name of the Locality server host. For example: myserver.mysubdomain.mycompany.com. Click Next to continue.

2. Specify the database port and the locations on the disk drive(s) for storing Locality logs, and backup and archive database files. Click Next to continue.

We recommend that you store Locality database logs in the default location so the logs are with the MySQL files (for example: <drive>:\ProgramData\NetMotion Wireless Locality Server\MySQL\Log).

Note: Database maintenance files (archive and backup) must be on the computer hosting the database. A volume on a separate physical drive is recommended. See “Configuration Wizard: Create Locality Database” on page 36 for more information.

3. If you have the Mobility Analytics Module v9.50 installed at your site, Locality can use its data to provide additional information for your reports.

To enable Analytics data integration components on the Locality server, select Enable Mobility Analytics Module and click Next. Otherwise, do not select the check box; click Next to proceed without enabling a connection to Mobility Analytics Module.

You can re-run the wizard later to configure a connection to the Mobility Analytics Module.

See “Configuration Wizard: Add Analytics Data” on page 42 for information about how to include analytics data from Mobility in your Locality reports.

Note: To fully enable this feature, additional configuration is required on the Mobility host; see “Integrating Mobility Analytics Data into Locality Reports” on page 44 for a description of the configuration process.

4. If you want to collect data from iOS mobile devices, you must enable the Locality iOS Inventory component.

See “Configuration Wizard: Enable iOS Inventory” on page 49. Otherwise, select I do not want to enable Locality iOS inventory and click Next. You can re-run the wizard later to enable support for iOS inventory reporting.

Note: If you enable iOS Inventory, client authentication is enabled automatically.

5. For enhanced security, you can enable and configure client authentication. When client authentication is enabled, Locality agents running on Windows, Android, and iOS must all be provisioned with an authentication code required by the Locality server to implement client authentication.

See “Configuration Wizard: Enable Client Authentication” on page 53 for details. Otherwise, select I do not want to enable client authentication and click Next.

6. If client authentication is enabled, it must be configured. See “Configuration Wizard: Configure Client Authentication” on page 55. Click Next.

7. The Locality Alerts and Messaging module enables you to check for certain conditions and send alerts when they occur to designated individuals. If you purchased a license for this module, select Enable Alerts and Messaging Module and then specify an SMTP server account to use for sending alert notifications.

See “Configuration Wizard: Configure Alerts and Messaging” on page 56 for details. Otherwise, click Next to skip this step and proceed. You can re-run the wizard later to enable support for Locality alerts and messaging.

8. Enter your Locality license key now, or enter it later in the Locality console (Locality agents cannot collect data until you add a license). See “Configuration Wizard: Add Locality License” on page 58 for more information. Click Next.

9. The final step in the Configuration Wizard is a test of configured items. In order to test, the wizard starts up Locality system services and web applications and tests communication with them. Click Next.

10. Click Done to close the Configuration Wizard.

11. You can now deploy the Locality agent on your mobile devices. Return to “Locality System Deployment Task List” on page 31 and resume the work flow tasks starting at task 5.



When your Locality system is operational, you can re-run the Configuration Wizard to make configuration changes or to restore the Locality database from a backup; see “Running the Configuration Wizard Later” on page 35.

Running the Configuration Wizard Later

To use the Configuration Wizard, you must be logged onto the host computer with administrator privileges.

When Locality is up and running, you can use the Configuration Wizard to complete any of the following tasks:

Restore a database backup, overwriting the current Locality database (see “Restoring the Locality v3.x Database (Locality Server)” on page 238)

Upgrade the existing Locality 3.x database and update configuration settings after installing a Locality server upgrade (see “Configuration Wizard: Configure Locality Database” on page 38)

Update Locality database and server configuration settings, such as changing the storage location for the database backup and archive folders (see “Configuration Wizard: Configure Locality Database” on page 38)

Enable or disable Mobility analytics data reporting; reset an existing association between the Locality server and a Mobility Analytics server so that a different Mobility server can connect to this Locality server (see “Configuration Wizard: Add Analytics Data” on page 42)

Enable or disable iOS inventory reporting and change the iOS inventory server settings (see “Configuration Wizard: Enable iOS Inventory” on page 49)

Enable or disable client authentication and change configuration settings (see “Configuration Wizard: Enable Client Authentication” on page 53)

Enable or disable alerts and messaging and change settings for SMTP server and message configuration (see “Configuration Wizard: Configure Alerts and Messaging” on page 56)

Configuration Wizard: Introduction

Getting there: From the Start menu, run Locality Configuration.

Enter the fully qualified domain name of the Locality server host. For example: myserver.mysubdomain.mycompany.com.



Click Next to proceed with configuration.

Configuration Wizard: Create Locality Database


The Configuration Wizard makes this page available when it does not detect an existing Locality v2.0 or later database (such as the first time you install Locality and have never collected Locality data before).

Note: Locality supports upgrading from v2.x to v3.x. You can also upgrade from v1.5x to 3.x, provided Locality is not configured to include data from a Mobility Analytics Module. If you want to upgrade a Locality v1.5x server that includes Analytics data, contact NetMotion Technical Support for upgrade assistance.



Use settings on this page to specify the TCP port that Locality uses to communicate with the Locality database. Then, specify locations for database logs, and for the backups, and archives, which are used for automatic database maintenance. When you click Next, the wizard creates a new, empty v3.x database on the Locality server.

You can configure the following options:

Option Description

Port The TCP port for communication between the Locality database and other Locality components.

Default: 3306

Database log folder Location of the Locality database binary and transaction log files, which must be on the computer hosting the database. We recommend that you store Locality logs in the default location so the logs are with the MySQL files (for example: <drive>:\ProgramData\NetMotion Wireless Locality Server\MySQL\Log).

Default: C:\ProgramData\NetMotion Wireless Locality Server\MySQL\Log

Database backup folder

Location of the Locality database backup file, which must be on the computer hosting the database. A volume on a separate physical drive is recommended. See “Managing Backup and Archive Folders (Locality Server)” on page 237 for additional recommendations.

Backups occur automatically, as part of database maintenance. You can also start a database backup in the Locality console (System > Status). See “Backing Up the Locality Database” on page 236 for more information.

Default: C:\ProgramData\NetMotion Wireless Locality Server\Backups



Configuration Wizard: Configure Locality Database


The Configuration Wizard makes this page available when it detects an existing Locality v2.x or later database.

Note: Locality supports upgrading from v2.x to v3.x. You can also upgrade from v1.5x to 3.x, provided Locality is not configured to include data from a Mobility Analytics Module. If you want to upgrade a Locality v1.5x server that includes Analytics data, contact NetMotion Technical Support for upgrade assistance.

Use settings on this page to change the Locality database configuration, assigning a new database port and/or log, backup, and archive folder locations. If the current database settings are correct, click Next to move on to the Update Locality Database panel.


Database archive folder

Location of the Locality database archive, which must be on the computer hosting the database. When a new backup is created, the previous backup is stored here. A volume on a separate physical drive is recommended. See “Managing Backup and Archive Folders (Locality Server)” on page 237 for additional recommendations.

Archiving occurs automatically as part of database maintenance. See “Backing Up the Locality Database” on page 236 for more information.

Default: C:\ProgramData\NetMotion Wireless Locality Server\Archive

Option Description

Option Description

Port The TCP port for communication between the Locality database and other Locality components.

Default: 3306



Configuration Wizard: Update Locality Database


The Configuration Wizard makes this page available when it detects an existing Locality v3.x database.

Database log folder Location of the Locality database binary and transaction log files, which must be on the computer hosting the database. We recommend that you store Locality logs in the default location so the logs are with the MySQL files (for example: <drive>:\ProgramData\NetMotion Wireless Locality Server\MySQL\Log).

Default: C:\ProgramData\NetMotion Wireless Locality Server\MySQL\Log

Database backup folder

Location of the Locality database backup file, which must be on the computer hosting the database. A volume on a separate physical drive is recommended. See “Managing Backup and Archive Folders (Locality Server)” on page 237 for additional recommendations.

Backups occur automatically, as part of database maintenance. You can also start a database backup in the Locality console (System > Status). See “Backing Up the Locality Database” on page 236 for more information.

Default: C:\ProgramData\NetMotion Wireless Locality Server\Backups

Database archive folder

Location of the Locality database archive, which must be on the computer hosting the database. When a new backup is created, the previous backup is stored here. A volume on a separate physical drive is recommended. See “Managing Backup and Archive Folders (Locality Server)” on page 237 for additional recommendations.

Archiving occurs automatically as part of database maintenance. See “Backing Up the Locality Database” on page 236 for more information.

Default: C:\ProgramData\NetMotion Wireless Locality Server\Archive

Option Description



Select from the available options to identify the configuration work flow you want to follow:

Configuration Wizard: Restore Locality Database


To restore all Locality system data using a database backup that you created, use settings on this panel and click Next.

Database Restore Use Cases

Reasons to perform a database restore:

Recovery from database corruption: You are replacing a corrupted Locality database with a backup, in order to restore a working database. See “Recovery from Database Corruption” on page 41.

Migration: You are moving your working Locality server deployment to a new host computer and need to restore the working database on the new host. See “Database Restore during Locality Migration” on page 41.

Option Description

Update your existing Locality database

Click this option when you want Locality to continue using the existing database. Use cases:

To retain the existing database, unchanged, and move on to the Add Analytics Data panel.

When upgrading your Locality v2.x server system. When re-running the Configuration Wizard to add Analytics data,

enable iOS Inventory, or enable client authentication. When you want to update the Locality database configuration as

specified in the Configure Locality Database panel.

When you click Next, Locality applies any necessary updates to the database and proceeds to the next panel.

Restore a backed up database

Click this option if you want to restore a Locality database from a backup, overwriting the existing database. Use cases:

To recover from a corrupted database on the current Locality server system. See “Configuration Wizard: Restore Locality Database” on page 40.

To migrate Locality from one computer to another. For details, see “Moving a Locality Deployment (Locality Server)” on page 240.

To upgrade to Locality server v2.x and continue using the data from your Locality v1.5x system. See “Upgrading from Locality Server v1.x to Locality Server v3.x” on page 61.

When you click Next, Locality opens the Restore Locality Database panel.



Changing the database location: You want to move the Locality database to a new location. See “Changing the Locality Database (Locality Server)” on page 239.

Recovery from Database Corruption

If your Locality installation is already configured to use a Locality v3.x database that is present on the host computer, use the Configuration Wizard to restore a backup of the database. No database configuration is required; the restore operation overwrites the existing database, leaving the Locality database management settings unchanged.

Database Restore during Locality Migration

To change the location of the Locality database on the current server or during migration to a new computer, you must back up your database, uninstall and reinstall Locality, and then restore your database backup. For detailed procedures see:

“Changing the Locality Database (Locality Server)” on page 239 “To keep the Locality server in place and change the deployment size” on page 65



In either of these cases, you will use the Restore Locality Database panel.

You can configure the following option:

Configuration Wizard: Add Analytics Data


This configuration panel is for sites running Mobility Analytics Module v9.50 or later.

If you don’t have Mobility Analytics Module v9.50 or later installed, or if you choose not to combine its data with data collected by Locality agents, click Next to continue on.

If you have Mobility Analytics Module v9.50 or later installed at your site, you can configure Locality to use its data to provide additional information for reports about the performance of your mobile wireless network (see “Enhancing Reports with Mobility Analytics Module Data” on page 4 for more information).

Option Description

Location of the backup to be restored

Location of the Locality database backup folder that you want to restore, which must be on the computer hosting the Locality server. The default location is the folder that you configured for automatic Locality database backups.

If the database backup that you want to restore is not in the default backup location, click Browse to navigate to the folder that does contain the database backup files.

See “Managing Backup and Archive Folders (Locality Server)” on page 237 for additional recommendations.



Select Enable Mobility Analytics Module to enable Analytics data integration components on the Locality server. Additional configuration is required on the Mobility host; see “Integrating Mobility Analytics Data into Locality Reports” on page 44 for a full description of the configuration process.

The following options are available:

Option Description

Enable Mobility Analytics Module

Clear this check box if you don’t have the Mobility Analytics Module installed, or if you do not want Locality reports to combine Mobility Analytics data with data collected by Locality agents.

Select this check box if your site runs Mobility v9.50 or later and you want to incorporate Mobility analytics data in Locality reports. Otherwise, keep the check box unselected and click Next to proceed to the next configuration panel.

When you upgrade a Locality server v2.10 or earlier that was configured to add analytics data, the old settings used to connect Locality with Mobility Analytics Module are discarded. Mobility analytics data that is present in the existing Locality database is preserved. However, to continue to receive Mobility analytics data, you must select Enable Mobility Analytics Module.

Important: If you select Enable Mobility Analytics Module, you must perform additional configuration steps on the computer that hosts the Mobility Analytics Module. See “Integrating Mobility Analytics Data into Locality Reports” on page 44.



Integrating Mobility Analytics Data into Locality Reports

This topic is for sites running Mobility Analytics Module v9.50 or later.

To integrate data from Mobility Analytics Module v9.50 into Locality reports, you must establish a connection between them. How you do this is slightly different, depending on which Locality edition you are running:

Signing certificate (Available when Enable Mobility Analytics Module is selected.)

The wizard automatically generates a new Locality Connect for Mobility signing certificate.

Locality uses a signed certificate to establish a trust relationship between the Locality server and a Locality Connect for Mobility web client installed on the Analytics server.

To open the Certificate tool and view the Locality Connect for Mobility signing certificate information, click View.

Reset (Available when Enable Mobility Analytics Module is selected.)

Click Reset to terminate the existing association between the Locality server and a Mobility Analytics server. The wizard immediately terminates the current connection so that another properly configured Mobility Analytics server will be able to connect to this Locality server.

See “When to Reset a Mobility Analytics Connection” on page 48 for details about using Reset.

Option Description



Note

If you move the Mobility Analytics Module to a new host computer, the connection between the Locality server and the Mobility Analytics Module must be reset. See “When to Reset a Mobility Analytics Connection” on page 48 for more information.

Securing Communication between Locality and Mobility Analytics Module

Locality establishes a trust relationship between the Locality server and the computer hosting your Mobility Analytics Module. Here is a summary of how that communication is secured:

1. (Locality server only) On Locality server v3.x, run the Locality Configuration Wizard to enable the Mobility Analytics Module. See “Configuration Wizard: Add Analytics Data” on page 42 for details. A Mobility Analytics CA signing certificate is generated.

This step is not necessary with Locality Cloud because it is pre-configured to support Mobility Analytics data integration using a Mobility Analytics CA signing certificate.

2. Install Locality Connect for Mobility on the computer hosting your Mobility Analytics Module. In the Configuration Wizard, you will need to provide both Locality and Mobility Analytics Module administrator credentials. See “Setting Up Locality Connect for Mobility” on page 45.

Once the Locality Connect for Mobility web client is installed it performs the following tasks every 30 minutes:

Connects to Locality server to get a list of all Locality agent devices that have reported data in the last half hour.

Queries the Mobility Analytics Module to retrieve application usage and compression data for those devices.

Connects to the Locality server and sends device-specific usage and compression data.

Here is how the signing certificates are used

1. Locality Connect for Mobility web client is installed on the Mobility Analytics Module server. The web client is configured to require a signed Locality Connect for Mobility server certificate, which is used by the client to confirm that it is connecting to a trusted server.

2. During configuration, Locality Connect for Mobility web client connects to your Locality server, which provisions the agent with a signed client identity certificate.

3. The connection to the Locality server is secured using the web client’s signed client identity certificate. The client connects to Locality server and uses the signed client certificate to establish mutual trust. Based on this trust relationship, the agent sends data to the server and the server accepts the data.

Setting Up Locality Connect for Mobility

Locality Connect for Mobility requires .NET Framework 4.5. Locality Connect Setup automatically installs and enables .NET Framework 4.5 if it is not already present on the Mobility Analytics host server.

To install and configure Locality Connect for Mobility

1. (Locality server only) Configure your Locality server so that it can integrate data from the Mobility Analytics Module. See “Configuration Wizard: Add Analytics Data” on page 42 for details.

2. (Locality server only) On the computer that hosts the Locality server, the firewall must allow a web client on the Mobility Analytics server (Locality Connect for Mobility) to connect to the Locality web service on inbound TCP port 8083. For configuration details, see “Firewall Configuration” on page 27.

3. Obtain the Locality Connect for Mobility setup program:

a. Log on to the NetMotion Wireless customer portal and click the Download tab.

b. Download the current Locality Connect for Mobility Setup software (file name: Locality_Connect_for_Mobility_<version>.exe).



4. Copy the file to the computer that hosts your Mobility Analytics Module and then open it.

5. Accept the License Agreement and click Install to start the installation process.

6. A window displays the status of the installation process, showing the progress on each task. At completion, keep the Configure Locality Connect for Mobility check box selected. Click Finish to exit Setup.

7. Setup automatically opens the Locality Connect for Mobility configuration wizard. Click Next to continue.

8. Configure the Locality web service:

a. In the Locality server box, enter the fully qualified domain name (FQDN) for the Locality server. For example: myLocalityserver.mydomain.mycompany.com. By default, the Locality web service listens on port 8083. If you need to assign a different port, add the port number to the FQDN like this: <FQDN>:<port>. For example: myLocalityserver.mydomain.mycompany.com:8087.

b. Click Connect.

c. You are prompted to enter Locality administrator account credentials. Enter them and then click OK.



9. The wizard uses the provided account credentials to connect to the specified Locality server address and obtain a signed Locality Connect for Mobility certificate. The wizard screen refreshes to show information about the certificate:

Click Next.

10. Provide settings to allow the Locality Connect for Mobility web client to communicate with the Mobility Analytics Module:

a. Analytics database port: specify the port used to communicate with the Mobility analytics database.

b. Database administrator password: provide the password for the database administrator account in the Mobility Analytics database (by default, it is the same as the password for the Mobility warehouse). The wizard uses this password to log on as administrator and add a Locality user account and stored procedures to the analytics database.



11. Click Next. The wizard shows a summary of configuration settings and actions completed:

12. Click Finish to exit. At this point, configuration is complete. To verify that Locality and Mobility Analytics are working together, go to Locality console > Status. Scroll down on the Status page to Mobility Analytics:

Important: If you move the Mobility Analytics Module to a new host computer, the connection between the Locality server and the Mobility Analytics Module must be reset. See “When to Reset a Mobility Analytics Connection” on page 48.

When to Reset a Mobility Analytics Connection

There are a couple of situations in which you must reset the Mobility Analytics server association:

If you want Locality to receive data from a different Mobility Analytics server/database, you must remove the existing association with Mobility and configure a connection between Locality and a new Mobility Analytics server.

Locality server only: Reset the Mobility Analytics server association if you move the Locality server to a new host computer.

If you are upgrading Locality server v3.x or later in place, there is no need to reset the connection to Mobility Analytics.

To reset the Mobility Analytics server association (Locality server)

1. On the Locality server, run the Locality Configuration Wizard. Use Next to proceed to the Add Analytics Data page. Click the Reset Analytics Server Association button.

The wizard generates a new Locality Connect for Mobility signing certificate, which terminates the existing secured connection between Locality and Mobility Analytics. The new certificate will be used to secure a connection between the Locality Web Service installed on the Locality server and a Locality Connect for Mobility client installed on a new Mobility Analytics server.

2. Use Next to continue to the end of the wizard, and Finish to exit.



3. To set up a secure connection with a different Mobility Analytics Module, go to the new Mobility server and install Locality Connect for Mobility. Follow the procedure in “Setting Up Locality Connect for Mobility” on page 45.

To reset the Mobility Analytics server association (Locality Cloud)

1. Contact NetMotion Technical Support and request that they terminate the existing connection between Locality Cloud and Mobility Analytics.

You are notified when Locality Cloud is ready to establish a secured connection with a new or relocated Mobility Analytics Module.

2. To connect Locality Cloud to a different Mobility Analytics Module, go to the computer hosting the Mobility Analytics Module and install Locality Connect for Mobility. Follow the procedure in “Setting Up Locality Connect for Mobility” on page 132.

Configuration Wizard: Enable iOS Inventory


If you are licensed to use the Locality Inventory module, Locality server can be configured to collect data from iOS devices and add it to Locality inventory reports. For details, see “Implementing Support for iOS Inventory Reporting” on page 50.

If you choose not to collect iOS inventory data, click I do not want to enable Locality iOS inventory and then click Next.




Implementing Support for iOS Inventory Reporting

If you want Locality to collect iOS inventory from your iOS devices, you must:

Purchase a Locality server license for the Locality Inventory Module. Contact your NetMotion Wireless sales agent for assistance.

Enable iOS inventory reporting. See “Configuration Wizard: Configure iOS Inventory” on page 50 for details.

° Set up a trust relationship between the Locality server, Locality agents on iOS devices, and the Apple Push server (APNS). The Locality Configuration Wizard and Locality Customer Portal will guide you through this process.

Locality server uses the Apple Push service to send your iOS devices requests for inventory data. When requested, the iOS device connects to the Locality server in order to provide current inventory data.

To support iOS inventory reporting, client authentication is enabled automatically on the Locality server.

Note: Client authentication will be enforced for every Locality agent, regardless of platform. To comply, Locality agents on iOS, Android, and Windows devices must all run Locality agent v2.x and must be configured with an authentication code.

For details about setting up client authentication, see “Planning for Security—Client Authentication and Server Authentication” on page 67.

Every Locality agent must provide a valid authentication code to the Locality server in order to establish a trust relationship. APNS requires client authentication to be enabled because only authorized devices are allowed to connect to the iOS inventory gateway.

After the server accepts the authentication code, the agent is directed to the provisioning gateway where it obtains a signed client identity certificate. Subsequently, the certificate is used to secure communication between the server and the agent.

Configuration Wizard: Configure iOS Inventory


Option Description

I do not want to enable Locality iOS Inventory.

Choose this option if you don’t want Locality inventory reports to include inventory information from Locality agents running on iOS devices.

The wizard discards any Locality server APNS certificate and storage settings that may be stored in the current existing or restored database.

I want to enable and configure Locality iOS inventory.

Choose this option if you want Locality to establish or update a secure connection between the Locality iOS inventory gateway and the Apple Push Notification service, using a signed APNS certificate.

When you click Next, the Configure iOS Inventory panel opens so that you can configure and store the APNS certificate needed to permit Locality to send requests for inventory data to Locality agents running on iOS devices.

I want to use the existing Locality iOS Inventory settings

(Available when you use the Configuration Wizard to configure an existing database or restore a database that contains a Locality iOS APNS certificate.)

When you configure an APNS certificate, it is stored in the Locality database. Choose this option if you want to use the stored certificate as is. The wizard will then skip the Configure iOS Inventory panel and go directly to Enable Client Authentication.

This option preserves the APNS certificate and optional certificate storage password that are in the current database, or that were restored from a database backup.



Note: See “Implementing Support for iOS Inventory Reporting” on page 50 for details about adding this feature.

Locality for iOS requires a trust relationship with Apple in order to communicate with Locality agents on iOS mobile devices. Locality maintains inventory of your iOS devices in a secure environment, using Apple Push Notification Service (APNS). Configuration involves setting up a trust relationship between the Locality server, Apple, and the device.

To establish trust, the Locality Configuration Wizard generates a Certificate Signing Request (CSR), which must be signed by NetMotion Wireless and then uploaded to the Apple Push Certificates Portal. In return, Apple provides an Apple Push Notification certificate that allows the Locality server to use Apple Push services to communicate with Locality agents. This APNS certificate must be renewed annually; for renewal details, see “Renewing a PEM File for iOS Inventory Authentication” on page 52.


Option Description

Set iOS certificate backup password

Certificate backup password

Confirm password

(Optional) You can create a certificate backup password to secure your Locality APNS identity.

Specify a certificate backup password.

Re-enter the certificate backup password.

Warning: If you create an iOS certificate password, be sure to keep a record of it. This password is required by the Locality database backup process to allow encryption of the APNS identity. For Locality database restore operations, the password is required to allow decryption of the APNS identity.

CSR (Certificate signing request)

This text is the Locality request for a signed certificate. It is used to obtain trust credentials for APNS certification, as described below.

APNS certificate file name

Specify the file path for the signed APNS certificate file downloaded from Apple.



To configure iOS inventory and obtain trust credentials for APNS certification

Note: During this procedure, you will connect to an Apple site to download an APNS certificate file. Apple does not support Internet Explorer for this process; an alternate browser is required (for example, Google Chrome or Firefox).

1. (Optional) Create and confirm a certificate backup password.

Information about the APNS certificate is stored in the Locality database. This password is used to secure the APNS certificate, which is encrypted when making a database backup. To restore the backup you must provide the password to decrypt the certificate. This password prevents an unauthorized user from restoring the database in order to misuse the APNS certificate. Each time you restore a backup of this Locality database, the Configuration Wizard requires the certificate storage password; if the correct password is not provided, the wizard halts the database restore process.

Warning: Keep a record of this password. If you lose the certificate backup password, it may be impossible to retrieve or change it. Without the password, you will not be able to restore a Locality data backup.

2. Click Copy to place the contents of the CSR field on the clipboard. This text is the Apple certificate signing request.

3. Click the “log on” link to open the NetMotion Wireless customer portal.

4. Log on using your NetMotion Wireless customer portal credentials.

5. On the Products tab, click the Set Up iOS Inventory button.

6. When the Set Up iOS Inventory - CSR Signing Wizard opens, follow the instructions in the wizard:

a. Click Start Sign CSR Process.

b. Provide Certificate Signing Request: Click in the text box and then paste the CSR text that you copied from the Locality Configuration Wizard. Click Next.

c. Download Signed CSR: NetMotion Wireless generates a signed CSR file. Download and save the file to a secure location. Click Next.

d. Create APNS Certificate: You must log on to the Apple Push Certificates portal with your Apple ID.

If necessary, click Create an Apple ID and follow the instructions. Then return to the CSR Signing Wizard.

Click Log on to Apple Push Certificate Portal.

In the portal, click Create a Certificate and accept the terms of use. Then, click Browse to select your CSR file and click Upload. (If you are using Internet Explorer, you may need to manually refresh your browser window to get to the download page.)

Click Download to save the new push certificate (the PEM file that Apple generated) to the Locality server. Then click Sign out and return to the Customer Portal CSR signing wizard.

e. In the signing wizard, click Close Window.

7. Click Logout to exit the Customer Portal.

8. Return to the Configure iOS Inventory page in the Configuration Wizard.

9. Click Browse to select the path and file name where you saved the signed PEM file provided by Apple. For example: C:\temp-APNS\MDM_netmotion wireless inc._Certificate.pem.

Renewing a PEM File for iOS Inventory Authentication

Apple provides an Apple Push Notification certificate that allows the Locality server to use Apple Push services to communicate with Locality agents. This APNS certificate must be renewed annually.

When the Locality APNS certificate’s expiration date draws near, a notification banner displays in the Locality console. To renew the APNS certificate, use the following procedure.



To renew an expiring Apple APNS certificate

1. Open the Locality Configuration Wizard and use the Next button to proceed to the Enable iOS Inventory panel.

2. Select I want to enable and configure Locality iOS inventory and click Next.

3. Go to “To configure iOS inventory and obtain trust credentials for APNS certification” on page 52. Complete steps 1 through 5. Use the following instructions in place of step 6. Then complete steps 7 through 9.

For a renewal, use the following instructions in place of step 6:

When the Set Up iOS Inventory - CSR Signing Wizard opens, follow the instructions in the wizard:

a. Click Start Sign CSR Process.

b. Provide Certificate Signing Request: Click in the text box and then paste the CSR text that you copied from the Locality Configuration Wizard. Click Next.

c. Download Signed CSR: NetMotion Wireless generates a signed CSR file. Download and save the file to a secure location. Click Next.

d. Create APNS Certificate: Log on to the Apple Push Certificates portal with your Apple ID. You must use the same Apple account that was used to create the expiring Locality APNS certificate.

Click Log on to Apple Push Certificate Portal.

The portal lists existing certificates for third-party vendors. To find the expiring Locality APNS certificate, find netmotion wireless, inc. in the Vendor column.

Click Renew to renew the Locality APNS certificate for another year. Then, click Browse to select your CSR file and click Upload. (If you are using Internet Explorer, you may need to manually refresh your browser window to get to the download page.)

Click Download to save the renewed push certificate (the PEM file that Apple generated) to the Locality server. Then click Sign out and return to the Customer Portal CSR signing wizard.

e. In the signing wizard, click Close Window.

4. After completing steps 7 through 9, click Next to move through the remaining panels and close the wizard.

Configuration Wizard: Enable Client Authentication


Client authentication allows you to ensure that only valid, authenticated Locality agents can connect to the Locality server with the use of X509 client certificates.

Note: With client authentication enabled, only properly configured Locality agents v2.x or later will be able to connect and submit data to your Locality v3.x server. All agent devices running Locality v1.x must be updated to v2.x or later. For an overview of Locality client authentication see “Planning for Security—Client Authentication and Server Authentication” on page 67.

If you don’t want to implement advanced security for client/server communication, click I do not want to enable client authentication and click Next.

To implement client authentication

1. Select I want to enable and configure client authentication and click Next.

2. Configure a root CA certificate and, optionally, specify IP address restrictions to secure Locality agent access to the Locality provisioning server. See “Configuration Wizard: Configure Client Authentication” on page 55.

3. Use the Locality console to generate authentication codes for Locality agents. See “Creating Client Authentication Codes” on page 217.

4. Deploy Locality agent v2.x on all Android and Windows mobile devices.



5. Agents on all platforms (Android, iOS, and Windows) must be configured with an authentication code. See “Distributing Client Authentication Codes” on page 219.

6. Every Locality agent must provide a valid authentication code to the Locality provisioning server in order to establish a trust relationship. The provisioning server generates a client x509 certificate based on the certificate signing request sent in by the agent. The server then sends the certificate to the agent and redirects it to the sample server.

Subsequently, the certificate is used to secure communication between the Locality server and the agent.


Option Description

I do not want to enable client authentication

(Unavailable if iOS Inventory is enabled.)

Choose this option if you don’t want to use client authentication to secure communication between Locality agents and the server.

The wizard discards any client authentication settings that may be stored in the current existing or restored database.

I want to enable and configure client authentication

(Always available.)

Choose this option if you want to secure communication between Locality agents and the server or if you want to change your existing client authentication configuration settings.

When you click Next, the Configure Client Authentication panel opens so that you can configure client authentication settings.

Note: The wizard automatically checks whether you have Locality agents running v1.x. If so, it warns you to upgrade these agents to v2.x prior to enabling client authentication.



Configuration Wizard: Configure Client Authentication


For an overview of Locality client authentication see “Planning for Security—Client Authentication and Server Authentication” on page 67.

Locality generates a self-signed CA certificate that is used to sign Locality agent Certificate Signing Requests (CSR) and validate the identity of Locality agents. The Locality provisioning gateway is responsible for processing the agent certificate signing request (CSR) and providing the signed client certificate. The Locality agent must supply a valid authentication code, created by the administrator using the Locality console, when the agent first communicates with the Locality server’s provisioning gateway. The provisioning gateway can be further secured by restricting the IP addresses from which the agent is allowed to provision.


I want to use the existing client authentication configuration

(Available when you use Configuration Wizard to configure an existing database or restore a database that contains client authentication settings).

When you configure client authentication, the settings are stored in the Locality database. Choose this option if you want to use the stored settings as shown. The wizard will then skip the Configure Client Authentication panel and go directly to System Verification.

This option preserves client authentication settings that are in the current database, or that were restored from a database backup.

Option Description

Option Description

Friendly name A descriptive name for the Locality client CA certificate.

New Click New to generate a new client signing certificate.



Configuration Wizard: Configure Alerts and Messaging


If you are licensed to use the Locality Alerts and Messaging module, Locality can generate alerts and messages based on criteria that you define on the System > Alerts page in the Locality console.

Expires The date on which the Client CA certificate expires. Locality console automatically displays a warning banner when there are 30 or fewer days until the certificate expires.

View Click View to see details about the current client signing certificate.

Provisioning gateway IP address restrictions

(Optional) For additional security, you can specify the IP address ranges that agents can use when connecting to the provisioning gateway.

Only IP addresses on this list are accepted by the provisioning gateway when provisioning Locality agents.

Add Opens the Add IP Address Restriction dialog box so you can create an IP address restriction list:

Specific IP address—Add an IP address from which agents can connect to the provisioning gateway.

IP address range—The range of accepted IP addresses to which the connecting computer's IP address is compared.

° Mask or Prefix—Subnet masks (IPv4) used to identify the accepted range of IP addresses that make up a subnet or group of IP addresses on the same network.

For example, to permit access only to devices using the 10. network, use the following settings:

Remove To remove an address entry from the restriction list, select it and click Remove.

Option Description



Use settings on this panel to enable the Alerts and Messaging module and configure the SMTP server email account that Locality will use to send out messages.


Related Information

Define alerts and messages. See “Managing Alerts and Messaging” on page 204.

Option Description

Enable Alerts and Messaging Module

Select this check box if your site is licensed to use the Locality Alerts and Messaging module.

Clear this check box if you did not purchase an Alerts and Messaging module license, or if you want to stop all configured alerts and messaging activity.

Note: SMTP server and message configuration settings are stored in the Locality database.

Options available when Enable Alerts and Messaging Module check box is selected:

Host name or IP address Enter the host name or IP address of the SMTP mail server that will send email alerts to designated recipients.

Port The TCP port for communication with the SMTP server.

User name Provide the logon user name for an email account on the designated SMTP server. Locality will use this account to send email alert messages.

Password / Confirm password Provide the user password for the email account that Locality will use to send alert messages.

Sender’s email address Specify the email address that will appear in the From field of all alert messages.

Send test email to Enter an email address for receiving a test alert. When you click Send, the wizard will use the specified SMTP server and account settings to send an email message to the test email address.



Configuration Wizard: Add Locality License


The Locality License panel is available in the Configuration Wizard only during the initial install of the Locality server. Later, if you are restoring a v3.x database backup, upgrading a Locality server v2.x, or moving the Locality v3.x server to a new host computer, your license already exists in the database. You can manage existing licenses and add new ones from the Locality console (see “Adding and Removing Locality License Keys” on page 208).

If you don’t yet have logon credentials from NetMotion Wireless Sales for the Locality customer portal, or if you are not ready to license Locality yet, select Add the license key later in the Locality console and then click Next. The Locality console provides a full interface to add and manage Locality licenses, as described in “Adding and Removing Locality License Keys” on page 208.

On the Locality License panel, you can configure the following options:

Option Description

Add the license key later in the Locality console

To finish the Configuration Wizard without entering a license key, select this check box. The Locality console is not fully functional, however, until you enter a console license key (in the console, go to System > Licensing). See “Adding and Removing Locality License Keys” on page 208.

Serial number Each Locality server has a unique serial number to which its licenses are keyed.

The serial number is also displayed in the console on the System > About page and on the System > Licensing page.

NetMotion Wireless Licensing Server

Click this link to retrieve your Locality license key. For details, see the licensing procedure that follows this table.

The licensing server is hosted on the Locality customer portal. Portal login credentials can be obtained from NetMotion Wireless Sales.



To add your first license key, complete the following procedure.

To add a Locality license from the Configuration Wizard (new install)

1. Click the NetMotion Wireless Licensing Server link to open the NetMotion Locality customer portal in a browser.

2. Enter your user name and password for portal access.

After logging on, the Locality License page opens.

3. In the License Authentications (Unissued) area, review the licensing information, then click Issue License Keys to generate your license.

4. The resulting license key (a text string) is made available in the License Authentications (Issued) area. It is also sent to the email address associated with your customer portal logon.

5. Copy the license key string to the clipboard (Ctrl+C).

6. Exit the customer portal and return to the Configuration Wizard.

7. Paste the license key string into the License key text box (Ctrl+V) and click Next.

License key Locality product licenses determine which reporting features are available in the console, and permit a set number of Locality agent devices to register with a single Locality server.

The license key is something you obtain from NetMotion Wireless Sales. Product licenses are either time-limited (for product evaluation) or ongoing:

Evaluation—This is an initial, time-limited license that you obtain from NetMotion Wireless. It is limited to a single server and controls the product modules that are available and the number of device licenses that can be issued.

Permanent—A permanent license controls the product modules that are available and is limited to a single server and a given number of devices. It does not expire. Additional permanent device license keys can be added to the server as your Locality agent deployment expands.

Subscription—A subscription license controls the product modules that are available and is limited to a single server and a given number of devices. Payments for software services are collected on a periodic basis.

Note: License keys are case sensitive. If the letters in your entry do not match the case present in the generated license key, an “Invalid license key” error is returned.

For information about adding and removing Locality licenses in the console, see “Managing Locality Licensing” on page 206.

Option Description




8. Complete the system verification step that confirms that the license has been applied, and exit the wizard.

Configuration Wizard: System Verification

The final step in the Configuration Wizard is a test of configured items. In order to test, the wizard starts up Locality system services and web applications and tests communication with them.

Configuration Wizard: Done

The Done panel summarizes the current Locality server settings.

If you are installing the Locality server for the first time and do not have a Locality database that contains data samples, click Done to exit the Configuration Wizard. The wizard remains available in the Start menu. To make changes to the initial Locality server configuration or to update or restore the Locality databases, re-run the Configuration Wizard.

Using Shortcuts to Open Locality Applications After you install the Locality server software, the NetMotion Wireless Locality group on the Start menu contains shortcuts to the following items:

Start Menu Item Description

Locality Configuration The Configuration Wizard allows system administrators to configure database settings, restore and/or update an existing database, and enable a connection to a Mobility Analytics Module database so that analytics data can be pulled into Locality reports.



Upgrading from Locality Server v1.x to Locality Server v3.x Do not attempt to upgrade Locality v1.x to Locality v3.x without assistance from NetMotion Wireless Technical Support.

Due to changes in system architecture, there are various possible scenarios for upgrading Locality v1.x to Locality v3.x. NetMotion Wireless Technical Support will help you to determine the best upgrade method for your Locality deployment. Contact them at [email protected].

Upgrading Your Locality v2.x Server Follow these procedures to upgrade your version 2.x Locality server:

“Upgrading Your Locality v2.x Server—Work Flow” on page 61 “Upgrading Your Locality v2.x Server—Procedure” on page 62

Upgrading Your Locality v2.x Server—Work Flow

To upgrade your existing Locality v2.x system, complete the tasks below in the order listed. If you are installing Locality for the first time, see “Locality System Deployment Work Flow” on page 30 instead.

Locality Console The console has two main functions, which are available from the server console or from a remote console:

Data analysis and reporting Administration and configuration

Authorized users can monitor the performance of your mobile wireless network—working with maps and charts that depict data collected by agent devices.

In addition to working with maps and charts, authorized administrative users can also monitor server status and system logs, and manage database maintenance, client authentication, and system licensing.

Locality Help The Locality server online help covers both server and client components for all supported operating systems. It is web-based and context-sensitive.

Locality Readme The Readme has last-minute information pertinent to this release and a link to Known and Resolved Issues.

Start Menu Item Description


1 Make a Locality v2.x database backup

“Backing Up the Locality Database” on page 236

2 Obtain v3.x license key(s) before upgrading software

“Obtaining v3.x License Keys Before You Upgrade” on page 209

3 Download the current Locality software release files

“Obtaining Locality Server and Agent Software” on page 32

4 Run Setup to install the Locality server as an upgrade

“Upgrading Your Locality v2.x Server—Procedure” on page 62

5 Run the Configuration Wizard to upgrade the database and configure Locality features

“Upgrading Your Locality v2.x Server—Procedure” on page 62



Upgrading Your Locality v2.x Server—Procedure

Do not use this procedure to upgrade a Locality v1.x server. See “Upgrading from Locality Server v1.x to Locality Server v3.x” on page 61. Follow the steps below to upgrade your current Locality v2.x server and database in place.

Before you begin the upgrade, make sure you obtain v3.x license key(s); read “Obtaining v3.x License Keys Before You Upgrade” on page 209 before you proceed.

To upgrade the Locality server and database in place

1. On the computer where the Locality server is installed, log on with administrator privileges.

2. Run the Locality server Setup program, which is a self-extracting executable file.

If the Locality v2.x server is already installed on your computer, the Locality Setup program detects that the product exists and proceeds with an upgrade. The current configuration settings and the Locality database are modified as necessary during an upgrade.


4. Click Install to start the installation process.

5. A window displays the status of the Locality server setup process, showing the progress on each task; some tasks can take quite a while.

6. At completion, click Finish to exit Setup. At this point, Setup performs a system reboot and then automatically opens the Locality Configuration Wizard and updates the Locality database. After the database update completes, the Add Analytics Data page opens.

7. When you upgrade a Locality server v2.10 or earlier that was configured to add Mobility analytics data, the old settings used to connect Locality with Mobility Analytics Module are discarded. Mobility analytics data that is present in the existing Locality database is preserved. However, to continue to receive Mobility analytics data, you must select Enable Mobility Analytics Module and perform additional configuration steps on the computer that hosts the Mobility Analytics Module. See “Integrating Mobility Analytics Data into Locality Reports” on page 44.

8. Click Next to accept default settings and proceed through the wizard to the Configure Alerts and Messaging panel.

The Locality Alerts and Messaging module enables you to check for certain conditions and send alerts when they occur to designated individuals. If your Locality license includes this module, select Enable Alerts and Messaging Module and then specify an SMTP server account to use for sending alert notifications.

6 Configure alerts and messages

(Skip if you are not licensed for the Locality Alerts and Messages Module)

“Managing Alerts and Messaging” on page 204

7 Configure Mobile Diagnostics custom tests (optional)

(Skip if you are not licensed for the Locality Mobile Diagnostics Module)

“Adding Custom Mobile Diagnostics Tests” on page 223

8 Deploy the v3.x Locality agent on mobile devices

(Required to support Mobile Diagnostics)

“Locality Agent Installation Overview (Windows)” on page 76

“Locality Agent Installation Overview (Android)” on page 92

“Locality Agent Installation Overview (iOS)” on page 96




See “Configuration Wizard: Configure Alerts and Messaging” on page 56 for details. Otherwise, click Next to skip this step and proceed. You can re-run the wizard later to enable support for Locality alerts and messaging.

9. During the system verification process, the wizard starts up Locality system services and web applications and tests communication with them.

10. After verification, click Done to close the Configuration Wizard.

If you want to activate the Alerts and Messaging module and Mobile Diagnostics testing and reports module, follow the steps below to obtain and apply v3.x license keys. If not, your system will work with a v2.0 license, but the new features won’t be available.

After completing the server upgrade procedures in this section, you can roll out the Locality agent upgrade to some or all of your mobile workers’ devices. The upgraded Locality server accepts data from some earlier versions of the Locality agent. On Windows devices, the agent software upgrade adds support for mobile diagnostics. To take advantage of the new Mobile Diagnostics feature, upgrade your Windows devices by installing the Locality v3.x agent for Windows.

To unlock the Alerts and Messaging and Mobile Diagnostics modules

1. After completing the server upgrade, log on to the Locality console and go to System > Licensing.

2. Click Get New License Keys to open the NetMotion Wireless customer portal in a browser.

3. Enter your user name and password for portal access. After logging on, the Products page opens.

4. Scroll to the Locality section. The License Authorizations (Unissued) fields are pre-populated with your v3.x module license and server information. Click Issue License Keys to generate your license key.

5. The resulting key is listed in the License Keys (Issued Authorizations) area. Copy the v3.x license key (a long text string).

6. On the Licensing page in the Locality console, click Add License Key, and paste the new license key string into the License key box. Click OK.

7. Log off of the Locality console and then log on again: you will see the new Mobile Diagnostics report tab. New System sub-tabs (Alerts, Alerts History, and Mobile Diagnostics) will also be available.

Changing Your Locality v3.x Server Deployment Each deployment size (small, medium, or large) has its own set of hardware requirements, including a minimum RAM requirement and disk drive requirements. When you change the size of your deployment, you must run the Configuration Wizard to set up the server to use the available resources.

This section identifies ways to change your Locality deployment and continue using your existing database:

I want to... See...

Keep the Locality server in place and add RAM to the host computer

“Changing Memory Capacity on the Locality Server” on page 64

Keep the Locality server in place and change the disk configuration

“Changing the Locality Deployment Size “in Place”” on page 65

Move the Locality server to a new computer and change the deployment size

“Moving a Locality Deployment (Locality Server)” on page 240

Move the Locality database to a new path on the existing server

“Changing the Locality Database (Locality Server)” on page 239

Upgrade the installed Locality server v3.x in place and change the deployment size

“Changing the Locality Deployment Size “in Place”” on page 65



Changing Memory Capacity on the Locality Server

Each deployment size has its own minimum RAM requirement, which constitutes a deployment size threshold.

If you change the amount of RAM on the computer hosting the Locality server, you must re-run the Locality Configuration Wizard to configure the server and the database to work properly with available memory. This is necessary whenever an increase or decrease in hardware memory capacity hits or crosses a RAM deployment size threshold.

RAM deployment size boundaries

To add or remove RAM on the Locality host computer

1. Turn off the host computer.

2. Install additional RAM on your computer.

3. Restart the computer.

4. Run the Locality Configuration Wizard.

5. In the Introduction panel, click Next.

6. In the Configure Locality Database panel, keep the current settings or make any desired changes.

7. Click Next to proceed to the Update Locality Database panel. There, choose Update your existing database and click Next.

The wizard detects the added RAM and reconfigures the server and the database to work properly with available memory.

8. No additional configuration is needed. Click Next to proceed through remaining panels and Done to close the wizard.

Changing the Size of Your Locality Deployment

Each deployment size has its own set of hardware and software requirements, including a minimum RAM requirement.

When you change the size of your deployment, you must run the Locality Configuration Wizard to configure the server and the database to use the increased RAM capacity and disk drives you have added.

You can take two different approaches to increase the capacity of your Locality deployment:

Move the Locality server and database to a new computer that supports a new deployment size. This method results in a brief server outage with minimal data loss. See “Moving a Locality Deployment (Locality Server)” on page 240.

Modify the hardware configuration of the computer that currently hosts the Locality server and database in order to support a new deployment size. This approach requires you to make a Locality database backup, uninstall the Locality server, modify the hardware configuration and

Upgrade the installed Locality server v3.x and move it to a new computer to change the deployment size

“Moving a Locality Deployment (Locality Server)” on page 240

I want to... See...

Deployment size Threshold (minimum RAM)

Small 8 GB

Medium 16 GB

Large 64 GB



then install Locality server and restore the database backup. There will be a server outage beginning when the Locality software is uninstalled and ending when the database is restored. See “Changing the Locality Deployment Size “in Place”” on page 65.

Changing the Locality Deployment Size “in Place”

When you increase or decrease the size of your deployment, you must run the Locality Configuration Wizard to configure the server and the database to use the RAM capacity and disk drives that are now available.

Every operation in this procedure is performed on the computer that hosts your Locality server and database.

Note: This procedure causes a server outage while the Locality software is removed and reinstalled, and the database is restored. Agent data that would normally be received and processed by the server during this interval may be lost.

Try to complete all server changes within a 24-hour period. A typical reconfiguration and reinstall can be completed in much less time.

To keep the Locality server in place and change the deployment size

1. Back up your current Locality database. For details, see “To manually start a Locality database backup” on page 236.

2. Copy the database backup folder to a separate, temporary location outside of the Locality folder structure (for example, C:\LocalityDBbackup). You will restore this database after you reinstall the Locality server.

3. Uninstall the Locality server. See “Uninstalling Locality Server Software” on page 66.

Uninstall gives you the option to keep the system’s database backup. You should click Delete to remove the system’s old database backup and archive folders as they are not needed. The Locality database backup you made in step 2 is stored in a separate, temporary folder; this is the database backup that you will restore.

4. On the host computer, change RAM and disk capacity to meet the specifications for your desired deployment size, as defined in “Hardware and Software Requirements” on page 6.

5. Re-install the Locality server. Run Setup as described in “To install the Locality server” on page 33.

During Setup, you can specify the location where Locality should store Locality database files.

6. When Setup completes, the Configuration Wizard starts automatically.

a. Enter the fully qualified domain name of the Locality server host computer. For example: myserver.mysubdomain.mycompany.com. Click Next.

b. Specify the database port and the locations on the disk drive(s) for storing Locality logs, and backup and archive database files.

c. Click Next. The wizard sets up an empty database, which you will overwrite in step 7.

d. No additional configuration is needed. Accept the default settings and click Next. On the Locality License panel, select Add the license key later in the Locality console. Click Next to proceed through remaining panels and Done to close the wizard.

e. If prompted, restart the computer.

7. Restart the Configuration Wizard and restore the database backup you made in step 1; see “To restore a Locality database backup” on page 238. The data is restored to the database location you specified during Setup.

8. Existing configuration settings for Mobility Analytics Module, iOS Inventory, and client authentication are restored along with the database.

To continue using the settings provided in the restored database, select I want to use the existing <feature> settings and click Next in the remaining wizard configuration panels.

9. Continue through System Verification and then close the Configuration Wizard.



Uninstalling Locality Server Software Use the following procedure to remove Locality server software from a computer.

To remove the Locality server software

1. On the computer where the Locality server software is installed, log on as administrator.

2. Open the Control Panel. Under Programs, click Uninstall a program.

3. Select NetMotion Wireless Locality, and then click Change.

4. In the Locality server Setup program, click Remove to start the Locality server uninstall process.

5. You can keep the current Locality database backup so that you can restore it on another system:

° To preserve a backup of your Locality database that can be restored, choose Keep. Uninstall leaves the current Locality database backup on disk; all Locality program files, other database and archive files, and Locality agent samples are removed.

° If you don’t want to preserve a backup of your Locality database, choose Delete. Uninstall removes all Locality program files, database files, backups, and Locality agent samples.

6. Click Next.

7. Confirm your choices and click Remove.

8. At completion, click Finish to exit Setup.


Chapter 4 - Installing Locality Agents | 67

Chapter 4Installing Locality Agents

This section explains how to install, upgrade, and uninstall Locality agent software on supported hardware platforms.

If you have a NetMotion Wireless Locality Cloud subscription, your Locality server is installed and maintained by the NetMotion Wireless Locality Cloud service team. To begin collecting data, install Locality agent software on the mobile devices that you want to track.

Considerations when Deploying Locality Agents Before deploying Locality agents review the following information:

“Locality Agent / Locality Server Software Version Requirements” on page 6 “Locality Agent Requirements” on page 15 “Hardware and Software Requirements” on page 6 “Planning for Security—Client Authentication and Server Authentication” on page 67 “Firewall Configuration” on page 69

Planning for Security—Client Authentication and Server Authentication

To provide a more secure environment, NetMotion Wireless recommends that you set up client authentication between your Locality agents and the Locality server for the safe transmittal of data. Locality Cloud requires For additional security, Locality agents can be configured to require a trusted server certificate, which is provided by a third-party certificate authority (CA). When these two security features are implemented, Locality agents can authenticate the Locality server, and the server can authenticate each agent device.

For agents reporting to a locally-hosted Locality server behind a corporate firewall, use of client authentication and trusted server certificates is optional. If you choose to use a self-signed server certificate instead of a Certificate Authority-issued server certificate, configure Locality agents to not require a trusted server certificate.

If your Locality server configuration has iOS inventory reporting enabled, then client authentication is required and is automatically enabled.

To enforce mutual trust, by default, Locality agents v2.x or later on Windows, Android, and iOS devices are configured to require a trusted server certificate before sending data.

Agents reporting to Locality Cloud are required to use client authentication in order to connect and send data securely.

How Client Authentication and Server Trust Are Implemented—Overview

What follows is a high-level overview of how client and server trust is implemented. The actions described are listed in progressive order.


68 | Chapter 4 - Installing Locality Agents

Note: Locality Cloud always has client and server authentication enabled. On Android and Windows devices, Locality agents reporting to Locality Cloud should implement mutual trust as described in procedures 3 and 4. iOS devices go through an enrollment process that enables communication between the Locality Cloud and the enrolled device.

1: Client authentication is enabled in Locality

This applies only to Locality server; client authentication is always enabled on Locality Cloud.

1. Use the Configuration Wizard to enable and configure client authentication. Authentication can be further secured by restricting the IP addresses from which certificate provisioning is allowed. See “Configuration Wizard: Enable Client Authentication” on page 53.

2. To implement client authentication, the wizard takes these actions:

a. Starts the Provisioning Gateway, which handles Locality agents’ requests for client certificates and manages the exchange with the Locality agent to establish a trusted relationship.

b. Configures the Sample Gateway to require that agents on Android and Windows devices supply a provisioned client certificate for authentication to the Sample Gateway.

c. Configures the Inventory Gateway to require that iOS devices supply a provisioned client certificate for authentication to the Inventory Gateway.

2: Server authentication is enabled in Locality

Server authentication is always enabled on the Locality server, because TLS (SSL) is always enforced regardless of whether or not client authentication is enabled.

° Locality server: By default, a self-signed certificate is used. If your agents connect to a locally-hosted Locality server, use of a third-party CA-issued server certificate is optional. To enforce server authentication with certificates, you must obtain and bind a third-party CA-issued certificate to your Locality server gateway sites. See “Configuring the Locality Server to Use a Signed Certificate” on page 110.

° Locality Cloud: Supports server authentication, using a CA-issued signed server certificate to support server trust.

3: Server authentication is enabled on Locality agents

Configuring Locality agents to enforce server authentication is optional.

a. Newly installed Locality v3.x agents are configured to require a trusted server certificate for server authentication. The Require trusted server certificate/cert option is on by default.

b. The v3.x Locality agent upgrade process does not change existing Locality agent configuration settings. Following an agent upgrade from v1.x to v3.x, the Require trusted server certificate/cert option must be enabled if you want to enforce server authentication.

c. When an iOS device enrolls in Locality Inventory Management, it receives a trusted server certificate as part of the enrollment process.

4: Client authentication is enabled on Locality agents

a. Client authentication codes are generated in the Locality console. See “Creating Client Authentication Codes” on page 217.

b. Each Locality agent is configured to use one of the authentication codes. See “Distributing Client Authentication Codes” on page 219.

5: Locality agents are provisioned and licensed by Locality

On Windows or Android devices:

a. The installed Locality agent automatically connects to the Locality provisioning gateway server.

b. The device user is prompted to enter a client authentication code.



c. The agent generates a public-private key pair, and gives the server a valid authentication code and a certificate signing request (CSR).

d. The server verifies the authentication code and then provisions the agent with a unique signed client identification certificate. This certificate is stored on the agent device. The server stores a copy of the certificate, which it uses to verify the identity of the agent in future. Thereafter, when the agent connects to Locality, it must provide the certificate to establish secure communication.

e. Once provisioned, the agent is redirected to the Locality sample gateway server. On first connection to the sample gateway, the agent requests and obtains a Locality device license.

f. Once licensed, agents on Windows and Android devices begin collecting sample data and periodically connect to the sample gateway in order to send this data to Locality. Licensed iOS devices periodically receive Apple push notifications that request the device to connect to the iOS Inventory gateway and send device information to Locality for use in Inventory reports.

On iOS devices:

a. Using the Safari web browser and a supplied URL, the user opens the Inventory Enrollment web page that is hosted on the Locality provisioning gateway server.

b. The user enters a client authentication code and taps Enroll.

c. The enrollment process installs a device profile that enables and configures Locality Inventory Management for Apple iOS.

d. The iOS Inventory server deals with iOS enrollment and certificate validation. The server verifies the authentication code and then provisions the agent with a unique signed client identification certificate. This certificate is stored on the agent device. The server stores a copy of the certificate, which it uses to verify the identity of the agent in future. Thereafter, when the iOS device connects to Locality, it must provide the certificate to establish secure communication.

e. Once provisioned, the agent is redirected to the Locality Inventory gateway server, where it obtains a Locality device license for this iOS device.

f. Licensed iOS devices periodically receive Apple push notifications that request the device to connect to the iOS Inventory gateway and send device information to Locality for use in Inventory reports.

After an agent is provisioned and licensed, all communication between Locality agent and server is managed by the Transport Layer Security (TLS) protocol using x509 certificates (client and server). TLS security ensures message privacy, message integrity, and mutual authentication of agent and server identity.

Firewall Configuration

If the Locality agent is behind a corporate firewall on your internal network or there is a local firewall on the agent device, the following ports must be opened for outbound TCP communication with Locality:


443 Outbound Used by Locality agents on Windows and Android mobile devices:

Locality server: If the Locality server is configured to enforce client authentication, Locality agents use port 443 for HTTPS traffic with the provisioning gateway.

If the Locality server is not configured to enforce client authentication, Locality agents use port 443 for HTTPS traffic with the sample gateway.

Locality Cloud: Locality agents use port 443 for HTTPS traffic with the provisioning gateway.



Obtaining Locality Agent Software Locality software downloads for Windows and Android devices are available from the NetMotion Wireless customer portal. If you don’t yet have logon credentials for the customer portal, contact your NetMotion Wireless partner or sales representative.

Note: The Locality agent for iOS is implemented through a Locality-specific device profile rather than an installed app. iOS devices are enrolled through a web page on the Locality server. For details, see “Enrolling a Device in the Locality Inventory System (iOS)” on page 97.

To obtain Locality software and documentation from the NetMotion Wireless customer portal

1. Log on to the NetMotion Wireless customer portal and click the Software Download tab.

2. Download the current Locality agent software release files. The Locality installation files can be used to perform either an initial product install or a product upgrade. The following files are available:

3. You can also download Locality software documentation files. The Readme provides a link to Known and Resolved Issues and may contain installation information specific to the current software version. The System Administrator Guide provides detailed information about deploying and managing Locality agents, including installation and configuration procedures.

4443 Outbound Used by Locality agents on Windows and Android mobile devices:

Locality server: If the Locality server is configured to enforce client authentication, Locality agents use port 4443 for HTTPS traffic with the sample gateway.

Locality Cloud: Locality agents use port 4443 for HTTPS traffic with the sample gateway.

5213 Outbound Used by iOS mobile devices.

Locality agents on iOS devices use port 5213 for HTTPS traffic with the inventory gateway.

80 Outbound Used by iOS mobile devices.

HTTP traffic for iOS mobile devices connecting to the Locality Inventory Enrollment web page.



Locality_agent_<version>_Setup EXE Locality agent software for Windows, 32-bit and 64-bit. This executable file performs a standard (non-silent) Locality agent installation or upgrade.

Locality_agent_<version> MSI Locality agent software for Windows, 32-bit and 64-bit. Use this file to perform a silent installation or upgrade. For details, see “Automating Installation of the Locality Agent” on page 80.

Locality_agent_<version> APK Locality agent software for Android devices. Use this file to perform a Locality agent installation or upgrade.

Note: Locality agent for Android is also available from the Google Play™ Store app. For details, see “Installing the Locality Agent (Android)” on page 93.



Deploying the Locality Agent (Windows) This information is for Windows users. If you are an Android user, see “Installing the Locality

Agent (Android)” on page 93. iOS users, see “Locality Agent Installation Overview (iOS)” on page 96.

To manually install the Locality agent on a Windows laptop or tablet, follow the steps in “Installing the Locality Agent Manually” on page 77. To automate agent installation, see “Automating Installation of the Locality Agent” on page 80. Complete software and hardware requirements are described in “Locality Agent Requirements” on page 15.

Note: You cannot install the Locality agent on a system where the Locality server software is present.

Deploying Locality Agent Software


The Locality installation files can be used to perform either an initial product install or a product upgrade. To obtain the current release of the NetMotion Wireless Locality agent, see “Obtaining Locality Agent Software” on page 70.

Manual installation

You can make the Locality agent Setup file (for example, Locality_agent_3.10_Setup.exe) available on a network share. Users can then copy the Locality agent Setup file to a local drive on the Windows device and run it locally to install the Locality agent on the device.

Warning: Users should never run Locality agent Setup directly from a shared network directory. During installation, all local network devices are stopped and started, which might make network shares go away and disrupt the install process.

For details about running Setup on a Windows laptop or tablet, see “Installing the Locality Agent Manually” on page 77.

Automated installation

If preferred, the Locality agent can be silently installed using the Windows Installer (MSI), with configuration options specified on the command line. You can also distribute a cloned Windows machine image or perform a remote installation procedure. See “Automating Installation of the Locality Agent” on page 80 for more information.

Preventing users from tampering with Locality agent configuration settings and data files

During initial installation of the Locality agent, administrators can lock down the Locality agent configuration settings to prevent users lacking administrator privileges on the local machine from making configuration changes. The agent must be silently installed using the Windows Installer (MSI). Configuration options must be specified on the command line; include this parameter to restrict access to configuration options: RESTRICT_CONFIGURATION=enabled

For details about how the RESTRICT_CONFIGURATION option works, see “Securing Locality Agent Settings, Data, and Configuration Files” on page 71. For information about how to implement this option, see “Performing a Silent Install or Upgrade” on page 80.

Securing Locality Agent Settings, Data, and Configuration Files


By default, the Locality agent Configuration dialog box allows any user to modify basic configuration settings after Setup. However, you can configure the Locality agent application to secure agent settings, data and configuration files.



Initial Locality agent configuration takes place during Setup. At that time, the administrator has the option to deploy the Locality agent with an MSI command line parameter (RESTRICT_CONFIGURATION=ENABLED) that prevents “standard” users from making changes to the installed agent configuration.

This setting cannot be altered via the setup wizard’s user interface and is only available as a command line switch. If the feature is explicitly ENABLED or DISABLED and Setup is unable to apply the permissions, then Setup fails the installation/upgrade process with a corresponding error message.

To gain write access to the Configuration dialog box settings, the user must have elevated administrative privileges for the local machine. By default applications do not get elevated even if the user is in the Administrators group.

To achieve application elevation, the Locality agent application must be started with the Run as administrator option. When an application is Run as administrator, one of two things happens:

1. If the user is in the Administrator group, the user is prompted that the application is requesting elevation and they can respond yes or no.

2. If the user is not in the Administrator group, the user is prompted for credentials of a user that is in the Administrator group. This allows the administrator to run the application when a non-administrator is logged into the machine.

Access restrictions are determined by whether the user is logged on as a standard or administrator user:

Standard user: Any user that does not have elevated administrative privileges for the local machine. The user is not a member of the local Administrator group (directly or inherited through other group membership). The standard user can view Locality configuration settings and copy log files for troubleshooting purposes. Standard users cannot change Locality settings or delete data sample and log files.

Administrator: Any user with elevated administrative privileges for the local machine. The user is a member of the local Administrator group (users directly in the local Administrator group or members of user groups that are members of the local Administrator group). Administrative users can change Locality configuration settings and have read/write/delete access to log and data files.

Implementing Agent Configuration Restrictions


Agent configuration restriction is configurable at Locality install time by deploying the Locality agent with an MSI command line parameter: RESTRICT_CONFIGURATION=ENABLED. For details about what the restrictions do, see “Securing Locality Agent Settings, Data, and Configuration Files” on page 71.

Setup will put the access restrictions in place for the following scenarios:

To restrict non-Administrator users on the local machine from making changes to Locality agent settings, data and configuration files, the Locality agent must be installed by a user with Administrator privileges on the local machine, running the agent MSI file in a command window. For more information, see “Performing a Silent Install or Upgrade” on page 80.

Setup scenarioCommand line parameter value for RESTRICT_CONFIGURATION

ENABLED DISABLED Not present/undefined

Initial installation Restrict access for standard users

Allow access for standard users


Upgrade/Repair Restrict access for standard users


Don’t modify settings



To restrict agent configuration to administrators only

On the local computer, open a command window and install the agent using the RESTRICT_CONFIGURATION=enabled setting. Add other Locality command line parameters as needed. For example:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com RESTRICT_CONFIGURATION=enabled

In this example, the Locality agent is installed with restricted configuration access that permits only users with elevated administrative privileges on the local machine to change the way the agent is configured. Administrators are also allowed to read/write/copy/delete Locality log files and data files. Standard users can read but not change settings in the Locality Configuration dialog box; they can also read and copy log files.

Changing the Configuration on a "Locked" Agent


Initial Locality agent configuration takes place during Setup.

By default, the Locality agent allows any user to change the configuration settings. During initial setup, a Locality system administrator can install the Locality agent with a setting that prevents non-administrative users on the local machine from making changes to Locality agent settings, data, and configuration files. In that case, to gain configuration access you must be a member of the Administrator group on the local machine and you must start the Locality agent as described in the following procedure.

To open the Locality Configuration dialog box with the ability to edit settings

1. On the Start menu of the agent device, point to Programs > NetMotion Wireless Locality.

2. Right-click the Locality application icon and then click Run as administrator.

When you start the Locality agent with the Run as administrator option, if you are not already logged on to Windows as a member of the Administrators group you will be prompted for logon credentials.

3. On the Status tab, click Configuration.

Deploying Locality Agent with a Remote Broadband Adapter


To use the Locality agent with a remote broadband adapter (such as a Sierra Wireless AirLink trunk modem), the agent needs to establish a connection to the adapter.

For most remote broadband devices, if your agent laptops use the Windows firewall for local network security and use Mobility for connectivity to your corporate network, the Locality agent installer automatically adds new rules to the Windows firewall and a passthrough rule to Mobility to



permit communication with the adapter. The communications traffic between the agent and the adapter must stay on the local network rather than going through the VPN tunnel. The resulting communication looks like this:

Because the ports used by mobile hot spots are diverse and unpredictable, the Locality agent installer does not add a Mobility policy rule automatically. You must add the rule yourself. For more information, see “Mobile Hotspot Configuration” on page 75 and “Passthrough Rules for Mobility Clients” on page 76.

If your mobile laptops do not use the Windows firewall and Mobility to secure communication, you must configure the firewall and VPN manually. For details, see the topic below that corresponds to your adapter.

Related Information

“Sierra Wireless AirLink Trunk Modem Configuration” on page 74 “CradlePoint Trunk Modem Configuration” on page 74 “Rocket Trunk Modem Configuration” on page 75 “Mobile Hotspot Configuration” on page 75 “Passthrough Rules for Mobility Clients” on page 76

Sierra Wireless AirLink Trunk Modem Configuration


The Locality agent uses the following UDP ports to communicate with a Sierra Wireless AirLink trunk modem:

On the Locality agent laptop, the firewall must allow Locality data to flow through these ports.

CradlePoint Trunk Modem Configuration


Required UDP Port Traffic

34701 Inbound traffic: Locality listens on this port to receive the NMEA 0183-compliant data stream for GPS monitoring

17339 Outbound traffic: Locality connects to this port to query the WWAN on the adapter



The default configuration for CradlePoint is as follows—these are the ports the Locality agent uses to communicate with the CradlePoint trunk modem:


Rocket Trunk Modem Configuration


The Locality agent uses the following ports to communicate with a Rocket trunk modem:


Mobile Hotspot Configuration

To use the Locality agent with a mobile hotspot device, the agent needs to establish a local connection to the web interface on the device. Your VPN must allow traffic between your Locality agent and the mobile hotspot.

Locality agent uses the following ports to communicate with a mobile hotspot device:


Remote Address/TCP Port Traffic

192.168.0.1:8889 Outbound traffic: Locality connects to this port to receive GPS data

192.168.0.1:443 Outbound traffic: Locality connects to this port to query the WWAN on the adapter

Required Port Traffic

4004 Inbound traffic: Locality listens on this port to receive GPS data

4000 Inbound traffic: Locality listens on this port to query the WWAN on the adapter

Remote Address/TCP Port Required By Traffic

192.168.1.1:80 All devices Outbound traffic: For data collection on all mobile hotspot devices, LocalityService.exe needs access to TCP port 192.168.1.1:80 (the device’s HTTP server).

192.168.1.1:53 Liberate and MiFi 5510

Outbound traffic: On the Liberate and the 5510, data collection also depends on access to UDP port 192.168.1.1:53 (the device’s DNS server).

192.168.1.1:11010 Liberate or MiFi 500 Outbound traffic: To gather GPS data on Liberate or MiFi 500 devices that support GPS over WiFi, LocalityService.exe and any GPS applications need access to TCP port 192.168.1.1:11010.

This port is user configurable. If you changed the default, provide access to port that your mobile hotspot GPS uses.

192.168.1.1:5502 Zing Outbound traffic: To gather GPS data on Zing devices that support GPS over WiFi, LocalityService.exe and any GPS applications need access to TCP port 192.168.1.1:5502.



Passthrough Rules for Mobility Clients


If your deployment includes both Mobility and Locality, Setup automatically adds passthrough rules to allow Locality to use a local network connection to communicate directly with most remote broadband adapters in default configurations. To make sure you have the latest passthrough rules, always use the latest version of the Mobility client.

Mobile Hotspots Require Manual Definition of Passthrough Rules

If your deployment includes Locality and Mobility (or a VPN) running on a laptop that uses a mobile hotspot device, you must manually add a passthrough policy in Mobility that gives Locality local access to the ports used to connect to the hotspot modem’s web interface. Setup cannot add a rule for you automatically because the ports used by hotspot modems are diverse and unpredictable.

Contact NetMotion Wireless Technical Support if you need assistance.

Deploying Locality with Adapters that Require a Locality Filter Driver

This information is for users of Windows 7 or later.

The Locality agent requires special configuration before it can monitor any of the following network adapters:

Any Ericsson network adapter that is embedded on a mobile device: 3507g, 5321gw, 5521gw, c5621

HP hs3121 HSPA+ Mobile Broadband Module (Huawei MU733)

To work with an adapter on this list, Locality requires a special NetMotion Locality filter driver that is not installed by default. The Locality filter driver works with Windows Mobile Broadband (WMB), which is only available on Windows 7 and later.

You can add the required Locality filter driver to a mobile device in either of these ways:

Install the Locality agent with the Locality filter driver: Run Windows Installer (MSI) using the INSTALL_WMB parameter. See “Automating Installation of the Locality Agent” on page 80.

Add the Locality filter driver after completing installation of the Locality agent: Run the nmNdisSetup program that is part of the Locality agent install package, described next.

Warning: Do not install this Locality filter driver unless your device uses one of the adapters listed above: the driver may interfere with other network adapters. If you experience network connectivity issues after installing this Locality filter driver, try uninstalling and re-installing the Locality agent without the Locality filter driver.

To install the Locality filter driver after agent installation on a 32-bit system

1. Open a command prompt and navigate to <Locality_Install_Dir>\wmbNdis\x86. For example:

C:\Program Files\NetMotion Wireless Locality Client\wmbNdis\x86

2. Run nmNdisSetup -i

To install the Locality filter driver after agent installation on a 64-bit system

1. Open a command prompt and navigate to <Locality_Install_Dir>\wmbNdis\x64. For example:

C:\Program Files (x86)\NetMotion Wireless Locality Client\wmbNdis\x64

2. Run nmNdisSetup -i

Locality Agent Installation Overview (Windows) This topic is for Windows users.



Locality agents can send data to a Locality server installed at your site, or report to a Locality Cloud server address made available by your NetMotion Wireless partner or sales representative. For information about agent and server version compatibility, see “Locality Agent / Locality Server Software Version Requirements” on page 6.

Your Locality server should be up and running before you deploy Locality agents. Follow the server installation instructions provided in “Installing the Locality Server System” on page 32.

To deploy the Locality agent on a Windows laptop or tablet, complete these tasks in the order listed:

If you are deploying the Locality agent on a laptop that connects to a remote broadband adapter, such as the Sierra Wireless AirLink trunk modem, complete these additional tasks:

For information about additional configuration options available in the Locality agent, see “Configuring Locality Agents (Windows)” on page 114.

Installing the Locality Agent Manually

This topic is for Windows users. If you are an Android user, see “Installing the Locality Agent (Android)” on page 93. iOS users, see “Enrolling a Device in the Locality Inventory System (iOS)” on page 97.


1 (Optional for Locality server, and required for Locality Cloud) If your Locality server is set to enforce client authentication, generate and securely distribute authentication codes that Locality agents must provide to the server before further communication is permitted.


2 Download the Locality agent software release files

“Obtaining Locality Agent Software” on page 70

3 Confirm that a running Locality server is available and note the server address (the fully qualified domain name).

“Logging on to the Locality Console” on page 197

“Monitoring Locality System Status” on page 200

4 Install the Locality agent “Installing the Locality Agent Manually” on page 77

“Automating Installation of the Locality Agent” on page 80

5 (Optional) On Windows 7 and later, some Locality agents require installation of the NetMotion Locality Filter Driver for Windows Mobile Broadband

“Deploying Locality with Adapters that Require a Locality Filter Driver” on page 76


6 Enable remote broadband adapter support

“Automating Installation of the Locality Agent” on page 80

7 Verify that agent laptop firewall rules are in place or add them manually

“Deploying Locality Agent with a Remote Broadband Adapter” on page 73

8 Verify that VPN passthrough rules are in place or add them manually

“Passthrough Rules for Mobility Clients” on page 76



Use this procedure to manually install Locality agent v3.x as a fresh installation. To automate agent installation, see “Automating Installation of the Locality Agent” on page 80. If you want to upgrade an existing Locality agent to v3.x, see “Upgrading Locality Agent (Windows)” on page 102.

To manually install the Locality agent on a Windows laptop or tablet, you must be logged on to the system with administrator privileges. In addition, you should be ready with the address of the Locality server to which you want the agent to connect. Locality Cloud users will also need the client authentication code provided by their Locality Cloud administrator.

To manually install the Locality agent on a Windows device

1. Copy the Locality agent Setup file to a local drive on the Windows device.


2. From the device where you want to install the Locality agent, run a local copy of the Locality agent setup file. The setup file (for example, Locality_agent_3.10_Setup.exe) is a self-extracting executable file that will extract files and launch Setup on the local drive.

Note: If you are installing on a Windows 10 or Windows 8 device and .NET 2 is not already enabled on the device, you must run the Locality Setup program with elevated privileges. To do so, right-click the Locality agent setup file and choose Run as administrator.


4. Accept the default destination folder for installation of Locality agent files, or choose a different folder. Click Next.

5. In the Server name box, type the fully-qualified domain name of the Locality server to which you want the agent to connect. For example:

° Local-hosted server FQDN: yourlocalserver.yourcompany.com ° Locality Cloud: yourcompanyserver.localitycloud.com

6. The Require a trusted server certificate setting is enabled by default. This security setting ensures that Locality agents can send collected data only to a Locality server that provides a trusted third-party CA server certificate. Change the setting as necessary and click Next:

° Local-hosted server: If the Locality server is hosted locally at your site and configured to use the default self-signed server certificate, you should clear the Require a trusted server certificate check box. If your local Locality server is configured with a third-party CA server certificate, enable Require a trusted server certificate.

° Locality Cloud: Agents reporting to a hosted Locality Cloud server should keep this setting selected, as it provides a way for the agent to confirm that it is connected to a trusted Locality server.

7. For added security, your Locality server may be configured to require a client authentication code. (Locality Cloud is always configured this way.) If so, the Locality agent must be configured with an authentication code generated by the server. You have the option to enter the authentication code during Locality agent setup. Either:

° Click I have an authentication code and enter the code. Type the authentication code you received from the Locality system administrator. The code is not case sensitive and the hyphens are optional. Click Next to continue.

° Click I do not have an authentication code and Next to skip this step and complete setup. When opened, the Locality agent application will prompt for an authentication code if the server requires one.

8. To gather location-related data, Locality must communicate with an active GPS receiver available to the mobile device. Specify whether Locality should automatically start a GPS receiver that is integrated with the network adapter or remote broadband adapter:

° If the mobile device has access to a GPS receiver that is integrated with an adapter, such as an embedded wireless card or remote broadband adapter, select the Auto-start integrated GPS receivers check box.

Enabling this option increases the likelihood that the adapter-based GPS receiver is active, meaning that Locality can collect location information more reliably. When selected,



Locality starts the GPS receiver automatically each time the device running the Locality agent is restarted.

Note: Locality agents that use a remote broadband adapter, such as a Sierra Wireless AirLink trunk modem, should always select this check box.

Click Next to continue.

9. Confirm your choices and click Install.

10. Windows Security may ask for permission to install a series of NetMotion Wireless device drivers. Click Install to allow this.

11. Near the end of the installation process, Setup starts the Locality agent and makes a connection to the specified Locality server. When the installation completes, you are prompted to click Finish to exit Setup.

12. By default, on exit, the Locality agent application opens so that you can see the current status of the agent. On the Status tab:

° Check the Server Last communication time. If it is Never, the Locality agent cannot communicate with the server. To troubleshoot this, see “Locality Agent Cannot Connect (Windows)” on page 251.

° If the Locality server requires an authentication code, a message prompts you to enter the code. Until the code is entered, the agent won’t be allowed to connect to the server to obtain a Locality device license. Without a license, the agent won’t collect data.

Additional Manual Driver Installation May Be Required

Devices that have one of the following embedded network adapters require a special NetMotion Locality filter driver that is not installed by default:

Any Ericsson network adapter that is embedded on a laptop that runs Windows 7 or later Dell DW5565 HSPA+ Mobile Broadband Module (Ericsson c5621) HP hs3121 HSPA+ Mobile Broadband Module (Huawei MU733)

To install this driver, see “Deploying Locality with Adapters that Require a Locality Filter Driver” on page 76.

Enabling Support for a Remote Broadband Adapter

If you installed the Locality agent on a Windows laptop that uses a remote broadband adapter (“trunk modem”) for WWAN connectivity and GPS information, some additional configuration steps are required. Follow the procedure in “Configuring Locality Agents (Windows)” on page 114 to enable remote broadband support on the Locality agent.



Enabling Support for a Mobile Hotspot Device

If you installed the Locality agent on a Windows laptop that uses a mobile hotspot device for WWAN connectivity, some additional configuration steps are required. Follow the procedure in “Configuring Locality to Use a Mobile Hotspot” on page 118.

Automating Installation of the Locality Agent


You can employ one or more of the following methods to automate Locality agent installation and upgrades:

Perform a silent install or upgrade using Windows Installer (MSI). For details, see “Performing a Silent Install or Upgrade” on page 80.

Use an operating system image to deploy the Locality agent. For details, see “Cloning Agent Configuration” on page 89.

Perform a remote installation using PsExec, which is a free utility offered by Microsoft. For details, see “Performing a Remote Installation” on page 90.

Performing a Silent Install or Upgrade


The Locality agent can be silently installed or upgraded using Windows Installer (MSIEXEC), with configuration options specified on the command line.

If the Locality agent is already installed, the Windows Installer recognizes that the product exists and that it should perform an upgrade; all current agent configuration settings are preserved.

Note: When you first install the Locality agent, a reboot may be required. For silent installation, consider using the /norestart option, which prevents the installer from abruptly performing an automatic computer shutdown and reboot at the end of the installation, and preserves unfinished work on the target device. If you do use /norestart, Locality may not be functional until the laptop or tablet is rebooted.

Installation Requirements

Before installing or upgrading the Locality agent software, review “Locality Agent Requirements” on page 15 and confirm that your target devices conform.

To perform a silent installation or upgrade from the command line or from a batch file, the MSIEXEC process must be run with administrator elevated privileges.

Do not host the Locality_agent_<version>.msi file on a network server, since interruptions in connectivity during installation could cause setup problems. The MSI file must be copied to a local drive on the device before running the command to install Locality.

You can perform a remote installation by using PsExec, which is a free utility offered by Microsoft. For details, see “Performing a Remote Installation” on page 90.

To obtain the Locality agent software

From the NetMotion Wireless web site, download the Locality agent software needed to install the product. The following files are available:


Locality_agent_<version> MSI Locality agent software for Windows, 32-bit and 64-bit. Use this file to perform a silent installation or upgrade. The MSIEXEC process must be run with administrator elevated privileges.

Locality_agent_<version>_Setup EXE Locality agent software for Windows, 32-bit and 64-bit. This executable file performs a standard (non-silent) Locality agent installation or upgrade.



Using Windows Installer to Install Locality Agents


The Locality agent can be “silently” installed using Windows Installer (MSI), with Locality-specific configuration options specified on the command line.

Note: To perform a silent install, the Windows Installer (MSI) must be run with elevated administrator privileges.

To see the complete syntax for the Windows Installer, enter MSIEXEC.EXE /? in a command window.

Below are some frequently used Windows Installer (msiexec) configuration options, followed by a list of Locality-specific parameters. For a list of sample commands, see “Automatically Installing Locality Agents—Examples” on page 86.

Locality-Specific Parameters

These are the Locality-specific parameters that can be used with the Windows Installer (msiexec) command:

MSIEXEC Option Description Required

/i <MSI filename> Standard install option for installing, upgrading, or configuring a product.

Yes

/qn Standard option for installing, upgrading, or configuring a product silently with no user interaction and no interface displayed, except for system-invoked prompts such as driver warnings.

Note: Using this option is recommended.

No

/norestart Standard option for preventing automatic reboots during a silent install. If this option is not specified, the installer restarts the computer whenever necessary without displaying any prompt or warning to the user.

Mobility users: During initial install on devices that use a remote broadband adapter (“trunk modem”), the installer adds a new passthrough rule for Mobility, described in “Passthrough Rules for Mobility Clients” on page 76. If you use the /norestart parameter to prevent an automatic reboot, the Locality agent may not be able to detect or communicate with the trunk modem until a reboot occurs.

No

/log <path> Standard option for creating an installation log file. It directs installation output to the specified path. Change <path> to the correct drive letter, directory, and log file name on the local device.

The Locality install automatically creates an installation log (%temp%\msi*.log).

No

Locality Parameter Description

SERVERADDRESS=[<FQDN> | <IP address>]

This parameter is required to perform a new install.

Specify the Locality server using either a fully qualified domain name (for example: myserver.mycompany.com) or an IP address.

If SERVERADDRESS is left blank, the Locality agent software installation terminates immediately after starting.

This is equivalent to Address in the Locality agent.



WWANAUTOENABLEGPS=[1|0]

Default: 0

Set this parameter to 1 for agent devices that use an adapter that has an integrated GPS receiver (such as an integrated mobile broadband adapter, an external mobile broadband adapter, or a remote broadband adapter). This starts the adapter’s integrated GPS receiver automatically.

Set this parameter to 0 for agent devices that use a standalone GPS receiver, such as a USB or Bluetooth GPS receiver.

This parameter is equivalent to Auto-start integrated GPS receivers in the Locality agent.

REQUIRETRUSTEDCERT=[1|0]

Default: 1

Set this parameter to 1 if you want the Locality agent to require a trusted server certificate from a certificate authority (CA). This parameter is equivalent to Require trusted server certificate in the Locality agent.

If your Locality agents connect to a Locality Cloud server, we recommend that they be configured to require a trusted server certificate. The Locality Cloud server will respond with a trusted server certificate from a CA.

(Locality server only) Set this parameter to 0 for a deployment where the Locality server uses a self-signed, untrusted certificate. This was the default setting in Locality v1.x and was equivalent to Allow connections to servers with untrusted certificates in the Locality agent.

By default, a locally hosted Locality server is configured with a self-signed certificate. If you did not take steps to bind a third-party CA server certificate to your Locality server, do not configure your agents to require a trusted certificate.

GPSPORT=COM<port number> Using this parameter forces the Locality agent to use a specific COM port for the GPS receiver, instead of automatically scanning all COM ports.

If GPSPORT is not used, Locality automatically attempts to discover a GPS receiver running on the target agent device by scanning COM ports that use a baud rate of 4800, 9600 and 38400. Locality uses the first GPS receiver that it finds (it can be either integrated on a network adapter or functioning as a stand-alone receiver).

To explicitly specify the COM port used by the GPS receiver, use the format COM<port number>, where <port number> is a positive integer (for example: GPSPORT=COM6).

Caution: No additional validation is performed to make sure that this port is a valid COM port on the target system. Use this parameter only if you are certain of the COM port number for your GPS receiver.

This parameter is equivalent to the Serial connection COM port setting in the Locality agent. Using it will switch the Locality agent’s GPS configuration from Detected automatically to Serial connection.

Note: GPSPORT can be used without setting GPSPORTBAUD. However, if GPSPORTBAUD is used, GPSPORT must be set.




GPSPORTBAUD=<baud rate> Use this parameter with a positive integer number to force the Locality agent to use a specific baud rate for the GPS receiver.

The default setting is 0 (Automatic). The Locality agent automatically looks for a GPS receiver on the specified GPSPORT COM port by scanning the port at standard baud rates (4800, 9600, 38400, 115200, 57600 or 19200).

This parameter is equivalent to the Serial Connection Baud rate setting in the Locality agent.

Note: If GPSPORTBAUD is used, GPSPORT must also be set.

GPSPORTTYPE=<0-3> The GPSPORTTYPE specifies the type of GPS receiver to search for.

0 indicates that the Locality agent should attempt to discover a valid GPS source, which may be a serial port, a remote broadband adapter, or a Windows location sensor.

1 indicates that an explicit serial port has been configured via GPSPORT.

2 indicates that the Locality agent should look specifically for a GPS source from a remote broadband adapter.

3 indicates that the Locality agent should look at Windows location sensors for a GPS source.

Note: If GPSPORT is set, do not set GPSPORTTYPE. The installer will automatically set a value of 1 for GPSPORTTYPE.

This parameter is equivalent to the GPS Receiver setting in the Locality agent. Using it will switch the Locality agent’s GPS receiver configuration from Detected automatically to either Serial connection, Remote Broadband Adapter, or Windows location sensor.

AIRLINKENABLED=[1|0]

Default: 0

Set this parameter to 1 for agents that use a Sierra Wireless AirLink trunk modem and GPS receiver. This is equivalent to selecting Sierra AirLink as the Locality agent’s Remote Broadband Adapter setting.

If no other Sierra Wireless AirLink parameters are specified, the agent attempts to detect the adapter using the default address and password settings built into the adapter.

AIRLINKADDRESS=<address> Replace <address> with a valid IP address (in the format: 123.123.123.123) to search for a Sierra Wireless AirLink trunk modem. If this value is set, AIRLINKENABLED is assumed to be true and the Locality agent will search for an AirLink trunk modem at the specified address instead of searching for the typical adapter default addresses.

Note: This parameter cannot be used by itself: it requires the AIRLINKPASSWORD parameter.

AIRLINKPASSWORD=<string> Replace <string> with the password to use when attempting to communicate with an AirLink trunk modem. The password will be written to the configuration in an encrypted format.

Note: This parameter cannot be used by itself: it requires the AIRLINKADDRESS parameter.




CRADLEPOINTENABLED=[1|0]

Default: 0

Set this parameter to 1 for agents that use a CradlePoint trunk modem and GPS receiver. This is equivalent to selecting CradlePoint as the Locality agent’s Remote Broadband Adapter setting.

If no other CradlePoint parameters are specified, the agent attempts to detect the adapter using the default address, user name, and password settings built into the adapter.

CRADLEPOINTADDRESS=<address> Replace <address> with a valid IP address (in the format: 123.123.123.123) to search for a CradlePoint trunk modem. If this value is set, CRADLEPOINTENABLED is assumed to be true and the Locality agent will search for a CradlePoint trunk modem at the specified address.

Note: By default, the user name for communicating with a CradlePoint trunk modem is admin. If your modem is configured to use a different user name, you must use the CRADELPOINTUSER parameter to specify that user name.

CRADLEPOINTPORT=<port number> Specify the port number to use when communicating with a CradlePoint trunk modem. This parameter is optional; if it is not specified, Locality will use the default port for the device.

CRADLEPOINTUSER=<string> Specify the user name to use when communicating with a CradlePoint trunk modem. This parameter is optional; if it is not specified, Locality will use the default user name, which is admin.

CRADLEPOINTPASSWORD=<string> Specify the password to use when communicating with a CradlePoint trunk modem. This parameter is optional; if it is not specified, Locality will use the default internal password, which is based on the adapter’s MAC address.

If a password is specified it will be written to the configuration in an encrypted format.

ROCKETENABLED=[1|0]

Default: 0

Set this parameter to 1 for agents that use a Utility Rocket trunk modem and GPS receiver. This is equivalent to selecting Rocket as the Locality agent’s Remote Broadband Adapter setting.

AC341PASSWORD=<string> Set this parameter for agents that use a NetGear Aircard 341U that is configured to require a password.

Replace <string> with the password to use when communicating with a NetGear Aircard 341U. The password will be written to the configuration in an encrypted format.

HOTSPOTENABLED=[1|0]

Default: 0

Set this parameter to 1 for agents that use a mobile hotspot device.

Note: This parameter cannot be used by itself, it requires the HOTSPOTADDRESS and HOTSPOTPASSWORD parameters.

HOTSPOTADDRESS=<name or ip address>

Specify the IP address of the device’s HTTP server. This is the address Locality uses to establish a local connection to the web interface on the device. If this value is set, the Locality agent will connect to the web interface at the specified address instead of the default address.

Note: This parameter cannot be used by itself, it requires the HOTSPOTENABLED and HOTSPOTPASSWORD parameters.




HOTSPOTPASSWORD=<string> The password required to log in to the administrator web interface on the hotspot device. This may be different from the WiFi password used to connect to the hotspot for access to the WWAN.

The password will be saved in an encrypted format.

Note: This parameter cannot be used by itself, it requires the HOTSPOTENABLED and HOTSPOTADDRESS parameters.

INSTALL_WMB=1 On devices that use one of the network adapters listed below, the Locality agent requires a special Locality filter driver that is not installed by default. Use this parameter to install the driver on devices that need it.

This parameter is required on Windows 7 (or later) devices that use the following network adapters:

Any embedded Ericsson network adapter Dell DW5565 HSPA+ Mobile Broadband Module (Ericsson

c5621) HP hs3121 HSPA+ Mobile Broadband Module (Huawei

MU733)

Warning: Do not use this installation parameter unless your device uses one of the listed network adapters: the driver may interfere with other network adapters.

AUTHENTICATIONCODE=<code> This setting configures the client authentication code for agents connecting to a Locality server that requires client authentication. Replace <code> with a valid client authentication code in the format “xxxx-xxxx-xxxx”. (It is not necessary to include hyphens when specifying the authentication code.)

NMW_STARTSERVICE=[1|0]

Default: 1

When preparing a machine image for cloning, you must set this parameter to 0. This prevents the Locality service from starting after Setup; instead, the service starts on reboot.

Set this parameter to 1 to have Setup automatically start the Locality service. This is the default setting.




Automatically Installing Locality Agents—Examples

This topic is for Windows users. It applies to both initial installations and upgrades. For a complete description of all Locality-specific command line parameters, see “Using Windows Installer to Install Locality Agents” on page 81.

To specify the address of the Locality server

° Use a valid, fully qualified domain name. In this example, Locality agent v3.x is installed with no user interaction (/qn), and a Setup log file is created:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /log c:\LocalityAgent\msi\install.log /qn SERVERADDRESS=yourlocalityserver.yourcompany.com

To configure the agent to require a trusted server certificate

° The Locality server uses the Transport Layer Security (TLS) protocol to validate its identity to connecting Locality agents, and to secure information that the agents send to it. Validation is done using a signed server certificate. When Require trusted server certificate is enabled, Locality agents that connect to a Locality Cloud server can validate that the server is trusted. The following command requires that the server provide a server certificate signed by a third-party certificate authority:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com REQUIRETRUSTEDCERT=1

If your Locality server is locally hosted, the server defaults to using a self-signed certificate. If a self-signed certificate suits your security needs, Locality agents should be configured to not require a trusted CA server certificate.

Use the following command to configure agents to accept a self-signed certificate:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com REQUIRETRUSTEDCERT=0

RESTRICT_CONFIGURATION=[ENABLED|DISABLED]

Default on initial install: DISABLED

When enabled, this parameter secures the Locality agent configuration settings and the files and folders under ProgramData\NetMotion Wireless Locality Client\.

Only users with elevated administrator privileges for the local machine (users directly in the local Administrator group or members of user groups that are members of the local Administrator group) will be able to modify Locality agent configuration settings and edit, delete, or move files and folders in ProgramData\NetMotion Wireless Locality Client\. “Standard” users that don’t have elevated administrator privileges for the local machine can see settings in the Locality agent Configuration dialog but cannot make changes to them; they can only read or copy files in ProgramData\NetMotion Wireless Locality Client\. For details about how this parameter works, see “Securing Locality Agent Settings, Data, and Configuration Files” on page 71.

This parameter is optional:

If the command line parameter is not detected during initial installation, then installation shall default to DISABLED.

If the command line parameter is not detected during an agent upgrade, then installation shall not alter the existing security settings in place for agent configuration and for Locality files and folders.




To configure the agent to support client authentication

° The Locality Cloud server requires a client authentication code. In this example, the Locality agent is installed with a client authentication code that the server uses to validate that the agent is trustworthy. Once trust is established, the agent is provisioned with a unique, signed client certificate, which the server uses to verify the identity of the agent in future. Whenever the agent connects to the server, it must provide the certificate to establish secure communication.

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourcompanyserver.localitycloud.com REQUIRETRUSTEDCERT=1 AUTHENTICATIONCODE=AHA6-BLO3-MMCT

To configure the agent to use a specific COM port for the GPS receiver

° In this example, the Locality agent is installed with the Serial connection option enabled; the COM port is set to the value specified by GPSPORT and the Baud rate is set to the value specified by GPSPORTBAUD:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com GPSPORT=COM1 GPSPORTBAUD=1200

To install the agent on a computer with an integrated GPS receiver

° If the GPS receiver for a given agent device is integrated with an embedded network adapter, it should be configured to auto-start. In this example, the Locality agent is installed with Auto-start integrated GPS receivers enabled:

msiexec /i c:\LocalityAgent\Locality_agent_3.100.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com WWANAUTOENABLEGPS=1

To configure the agent to connect to the GPS receiver on a remote broadband adapter

° If the GPS receiver for a given agent device is part of the remote broadband adapter, the Locality agent must connect with the adapter in order to get GPS location data. In all of these examples, the Locality agent is installed with Auto-start integrated GPS receivers and Remote broadband adapter enabled.

Sierra Wireless AirLink examples

In the following command the agent is installed and configured to connect to the GPS receiver on a Sierra Wireless AirLink adapter. Because no other parameters are specified, the agent searches for the adapter using the default address and password built into the adapter.

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com WWANAUTOENABLEGPS=1 AIRLINKENABLED=1 GPSPORTTYPE=2

In this example the agent device is configured to connect to a Sierra Wireless AirLink adapter that uses a non-default address and password.

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com WWANAUTOENABLEGPS=1 AIRLINKENABLED=1 AIRLINKADDRESS=123.123.123.123 AIRLINKPASSWORD=aBc123 GPSPORTTYPE=2

CradlePoint examples

In the following command the agent is installed and configured to connect to the GPS receiver on a CradlePoint adapter. Because no other parameters are specified, the agent searches for the adapter using the default user name, IP address, and password built into the adapter.

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com WWANAUTOENABLEGPS=1 CRADLEPOINTENABLED=1 GPSPORTTYPE=2

In this example the agent device is configured to connect to a CradlePoint adapter that uses a non-default address and port. When CRADLEPOINTADDRESS is specified, the user



must also be specified (CRADLEPOINTUSER), and CRADLEPOINTENABLED is assumed to be true.

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com WWANAUTOENABLEGPS=1 CRADLEPOINTADDRESS=123.123.123.123 CRADLEPOINTUSER=<User> CRADLEPOINTPORT=123

Rocket examples

In the following command the agent is installed and configured to connect to the GPS receiver on a Rocket adapter using default settings (there are no custom settings).

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com ROCKETENABLED=1

To configure the agent to look at Windows location sensors for a GPS source

° For devices that have an integrated Windows location sensor, the Locality agent can be configured to look for a GPS receiver on the location sensor. In this example, the Locality agent is installed with GPS receiver set to Windows location sensor:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com GPSPORTTYPE=3

To configure the agent to support use of a mobile hotspot device

° In the following command the agent is installed and configured to use a WiFi connection to a mobile hotspot device for access to the WWAN. All three “HOTSPOT” parameters are required.

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com HOTSPOTENABLED=1 HOTSPOTADDRESS=192.168.1.1 HOTSPOTPASSWORD=aBc123

To install the agent with a required network adapter filter driver

° For devices that use any of the following network adapters, the Locality agent requires a special Locality filter driver that is not installed by default: —Any Ericsson network adapter that is embedded on a mobile device: 3507g, 5321gw, 5521gw, c5621—HP hs3121 HSPA+ Mobile Broadband Module (Huawei MU733)

Warning: Do not use this option unless the target device uses one of the listed adapters: the driver may interfere with other network adapters. If you experience network connectivity issues after installing the Locality filter driver for an adapter that was not listed, try uninstalling and re-installing the Locality agent without the Locality filter driver. See “Deploying Locality with Adapters that Require a Locality Filter Driver” on page 76 for details.

This example uses the INSTALL _WMB parameter to include the extra driver in the Locality agent install:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourcompanyserver.localitycloud.com WWANAUTOENABLEGPS=1 INSTALL_WMB=1

To lock down the agent configuration and restrict configuration to administrators only

° The Locality agent can be configured to prevent non-administrative users on the local machine from making changes to Locality agent settings and to Locality data and configuration files. In this example, the Locality agent is installed with restricted configuration access that allows only users with elevated administrative privileges on the local machine to change the way the agent is configured.

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /qn SERVERADDRESS=yourlocalityserver.yourcompany.com RESTRICT_CONFIGURATION=enabled



Cloning Agent Configuration

You can use an operating system image to deploy the Locality agent. When a deployed machine boots from the image, the Locality service starts automatically, the agent is provisioned with a signed client CA certificate (only if client authentication is enabled), it is re-licensed, and a new device ID is created.

You can use a cloning utility such as Altiris to replicate the configuration of a Locality agent on additional devices. See the cloning utility documentation for details on creating an image.

To prepare a Windows operating system image to deploy the Locality agent

Important! If your server enforces client authentication, your prepared image must use the AUTHENTICATIONCODE and NMW_STARTSERVICE=0 settings (steps 2b and 2e). Step 3 is mandatory; do not reboot the system.

1. Prepare a Windows device with the software and operating system that you want to replicate.

2. Perform a Locality silent install, specifying the configuration options you want to apply:

a. Set the server address: SERVERADDRESS=<FQDN>

Example:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /log c:\LocalityAgent\msi\install.log /qn SERVERADDRESS=yourlocalityserver.yourcompany.com

b. Set the client authentication code: AUTHENTICATIONCODE=<####-####-####>

Example configuring an authentication code for agents connecting to a Locality server that requires client authentication. The NMW_STARTSERVICE parameter must be set to ‘0’, otherwise the authentication code will be used (and destroyed) before the device is imaged:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /log c:\LocalityAgent\msi\install.log /qn SERVERADDRESS=yourlocalityserver.yourcompany.com AUTHENTICATIONCODE=AHA6-BLO3-MMCT NMW_STARTSERVICE=0

c. Specify whether or not to enforce server certificate trust: REQUIRETRUSTEDCERT=[1|0]

Example requiring a server certificate from a certificate authority (CA):

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /log c:\LocalityAgent\msi\install.log /qn SERVERADDRESS=yourlocalityserver.yourcompany.com AUTHENTICATIONCODE=AHA6-BLO3-MMCT REQUIRETRUSTEDCERT=1

d. If the GPS receiver for the Windows device is integrated with an embedded network adapter, it should be configured to auto-start. Specify whether or not to auto-enable GPS: WWANAUTOENABLEGPS=[1|0

Example enabling GPS auto-start:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /log c:\LocalityAgent\msi\install.log /qn SERVERADDRESS=yourlocalityserver.yourcompany.com AUTHENTICATIONCODE=AHA6-BLO3-MMCT REQUIRETRUSTEDCERT=1 WWANAUTOENABLEGPS=1

e. Add additional Locality-specific parameters as necessary.

f. Configure the Locality service to start on reboot but not during installation: NMW_STARTSERVICE=0

Example preventing Setup from starting the NMW service; instead, the service starts when the device is rebooted:

msiexec /i c:\LocalityAgent\Locality_agent_3.10.msi /log c:\LocalityAgent\msi\install.log /qn SERVERADDRESS=yourlocalityserver.yourcompany.com AUTHENTICATIONCODE=AHA6-BLO3-MMCT REQUIRETRUSTEDCERT=1 NMW_STARTSERVICE=0

3. Do not reboot the system.



4. Use a cloning utility such as Altiris to replicate the configuration of the Locality agent on additional devices. See the cloning utility documentation for details on creating an image.

Performing a Remote Installation

When using a remote-management tool to install Locality, copy PsExec.exe to your executable path.

Here is a sample command to install the Locality Agent:

psexec <Target_MachineName> -u <DOMAIN>\<Admin_User> -p <Password> msiexec /norestart /quiet /package "<NetworkPath_OR_LocalPath_to_LocalityMSI>" SERVERADDRESS=<Locality_Server_Address>

The psexec command parameters are listed in the following table. Other parameters can be added to the embedded msiexec command, as explained in “Automating Installation of the Locality Agent” on page 80.

Sample PsExec commands to remotely install or upgrade Locality Agent

To install Locality agents for use with a Locality Cloud server

This command installs and configures the Locality agent to connect securely to a hosted Locality Cloud server. Use a command like this to enable agents to supply a client authentication code to the server and to require a third-party CA signed server certificate. Add parameters to configure GPS and remote broadband settings as needed.

Syntax:

psexec <Target_MachineName> -u <DOMAIN>\<Admin_User> -p <Password> msiexec /norestart /quiet /package "<LocalPath_to_LocalityMSI>" SERVERADDRESS=<FQDN> AUTHENTICATIONCODE="XXXX-XXXX-XXXX" REQUIRETRUSTEDCERT=1 /log <LocalPath_to_upgradeLOGfile>

Example:

psexec.exe \\jbopp-zz5922 -u jbopp-zz5922\LocAdmin -p MyPa$$word! msiexec /norestart /quiet /package "c:\temp\Locality_30\Locality_agent_3.10.msi" SERVERADDRESS=myserver.localitycloud.com AUTHENTICATIONCODE="AHA7-TBK5-MZRD" REQUIRETRUSTEDCERT=1 /log c:\temp\msiUPGRADElog.log

To install Locality for use with a locally-hosted v3.x Locality server (client/server trust is enforced)

This command installs and configures the Locality agent to connect securely to a locally hosted Locality server. Use a command like this to enable agents to supply a client authentication code to the server and to require a third-party CA signed server certificate. Add parameters to configure GPS and remote broadband settings as needed.

PsExec Command Parameter Description

<Target_MachineName> The name of the machine where the Locality client will be installed. Specify the full machine name along with the domain suffix if it is a part of a domain.

<DOMAIN>\<Admin_User> The credentials used to perform the installation. This user needs to have administrative privilege.

<Password> The <Admin_User> user’s password.

<Locality_Server_Address> The fully qualified domain name of the Locality server.

<NetworkPath_OR_LocalPath_to_LocalityMSI> The path to the MSI file. A local path is preferred but a network path works as well if the remote client has access to that path



Syntax:

psexec <Target_MachineName> -u <DOMAIN>\<Admin_User> -p <Password> msiexec /norestart /quiet /package "<LocalPath_to_LocalityMSI>" SERVERADDRESS=<FQDN> AUTHENTICATIONCODE="XXXX-XXXX-XXXX" REQUIRETRUSTEDCERT=1 /log <LocalPath_to_upgradeLOGfile>

Example:

psexec.exe \\jbopp-zz5922 -u jbopp-zz5922\LocAdmin -p MyPa$$word! msiexec /norestart /quiet /package "c:\temp\Locality_30\Locality_agent_3.10.msi" SERVERADDRESS=myserver.mycompany.com AUTHENTICATIONCODE="AHA7-TBK5-MZRD" REQUIRETRUSTEDCERT=1 /log c:\temp\msiUPGRADElog.log

To install Locality agent for use with a locally-hosted v3.x server (client/server trust is not enforced)

For agents reporting to a locally-hosted Locality server behind a corporate firewall, use of client authentication and trusted server certificates is optional. This command installs and configures Locality agent to work with a v3.x server that does not perform client authentication and that does not have a third-party CA signed server certificate. Add parameters to configure GPS and remote broadband settings as needed.

Syntax:

psexec <Target_MachineName> -u <DOMAIN>\<Admin_User> -p <Password> msiexec /norestart /quiet /package "<LocalPath_to_LocalityMSI>" SERVERADDRESS=<FQDN> REQUIRETRUSTEDCERT=0 /log <LocalPath_to_upgradeLOGfile>

Example:

psexec.exe \\jbopp-zz5922 -u jbopp-zz5922\LocAdmin -p MyPa$$word! msiexec /norestart /quiet /package "c:\temp\Locality_30\Locality_agent_3.10.msi" SERVERADDRESS=myserver.mycompany.com REQUIRETRUSTEDCERT=0 /log c:\temp\msiUPGRADElog.log

To upgrade Locality agent from v1.x to v3.x and specify the Locality server address

° This command performs an agent upgrade that specifies the address of the server and keeps all existing configuration settings unchanged. To specify the Locality server address, enter a valid, fully qualified domain name. In this example, a Setup log file is also created.

Syntax:

psexec <Target_MachineName> -u <DOMAIN>\<Admin_User> -p <Password> msiexec /norestart /quiet /package "<LocalPath_to_LocalityMSI>" SERVERADDRESS=<FQDN> /log <LocalPath_to_upgradeLOGfile>

Example:

psexec.exe \\jbopp-zz5922 -u jbopp-zz5922\LocAdmin -p MyPa$$word! msiexec /norestart /quiet /package "c:\temp\Locality_30\Locality_agent_3.10.msi" SERVERADDRESS=myserver.mycompany.com /log c:\temp\msiUPGRADElog.log

To upgrade Locality agent from v1.x to v3.x and enable client authentication

This command performs an agent upgrade that configures the server name and a client authentication code; other configuration settings remain unchanged. (The authentication code is necessary only when the server is configured to require one.)

Syntax:

psexec <Target_MachineName> -u <DOMAIN>\<Admin_User> -p <Password> msiexec /norestart /quiet /package "<LocalPath_to_LocalityMSI>" SERVERADDRESS=<FQDN> AUTHENTICATIONCODE="XXXX-XXXX-XXXX"/log <LocalPath_to_upgradeLOGfile>

Example:

psexec.exe \\jbopp-zz5922 -u jbopp-zz5922\LocAdmin -p MyPa$$word! msiexec /norestart /quiet /package "c:\temp\Locality_30\Locality_agent_3.10.msi" SERVERADDRESS=myserver.mycompany.com AUTHENTICATIONCODE="AHA7-TBK5-MZRD" /log c:\temp\msiUPGRADElog.log



To upgrade Locality agent from v1.x to v3.x and require client and server trust

This command performs an agent upgrade that configures the server name, specifies a client authentication code, and sets the agent to require a third-party CA signed server certificate. Use a command like this if your agents will connect to a Locality Cloud server. It sets up client/server trust requirements but leaves the existing GPS and remote broadband settings on the agent unchanged.

Syntax:

psexec <Target_MachineName> -u <DOMAIN>\<Admin_User> -p <Password> msiexec /norestart /quiet /package "LocalPath_to_LocalityMSI" SERVERADDRESS=<FQDN> AUTHENTICATIONCODE="XXXX-XXXX-XXXX" REQUIRETRUSTEDCERT=1 /log <LocalPath_to_upgradeLOGfile>

Example:

psexec.exe \\jbopp-zz5922 -u jbopp-zz5922\LocAdmin -p MyPa$$word! msiexec /norestart /quiet /package "c:\temp\Locality_30\Locality_agent_3.10.msi" SERVERADDRESS=yourlocalityserver.yourcompany.com AUTHENTICATIONCODE="AHA7-TBK5-MZRD" REQUIRETRUSTEDCERT=1 /log c:\temp\msiUPGRADElog.log

Testing a Locality Agent Connection


The Locality agent automatically connects to the Locality server during Setup and as part of the data collection process. You can test the connection yourself.

To test the connection from the Locality agent to the Locality server

1. Open the Locality agent (Start > NetMotion Wireless Locality > Locality).

2. From the Status tab, click Test server connection.

When Test server communication is clicked, the Locality agent device immediately attempts to communicate with the Locality server. If the communication fails, you will see a message at the top of the Status tab. For example:

3. If you see a communication error message, click the Configuration button to open the Configuration window. Verify that you have specified the right server address and configured the other settings properly. Also verify that your computer’s network connection is working properly. Then return to the Status tab and test server communication again.

Locality Agent Installation Overview (Android) This topic is for Android users.

Locality agents can send data to a Locality server installed at your site, or to a Locality Cloud hosted server made available by your NetMotion Wireless partner or sales representative.




To deploy the Locality agent on an Android device, complete these tasks in the order listed:

Installing the Locality Agent (Android)

This topic is for Android users. If you are a Windows user, see “Deploying the Locality Agent (Windows)” on page 71. iOS users should see “Enrolling a Device in the Locality Inventory System (iOS)” on page 97.

Complete software and hardware requirements are described in “Locality Agent Requirements” on page 15.

Your Locality server should be up and running before you deploy Locality agents. To install the Locality agent on an Android device, use one of the two procedures in this section, and then follow the steps for initial configuration described in “Configuring the Locality Agent for the First Time (Android)” on page 94.

To install the Locality app using the Google Play™ Store app

1. Gather the following information (provided by your Locality system administrator):

° Server Address: This is the fully qualified domain name of the Locality server to which the agent will connect.

° (Locality server) Authentication Code: (Optional) If the Locality server is configured to require client authentication, your system administrator will send you a code.

° (Locality Cloud) Authentication Code: The client authentication code is used by Locality Cloud to confirm that the agent can be trusted.

2. On the Android device, tap Play Store.

3. Search Google Play for “Locality”.

4. In the Apps list, tap Locality.

5. Tap Install.

6. From the permissions list, tap Accept. The Locality app downloads and starts the installation process.

7. When installation completes, tap Open to configure the Locality app for the first time.

8. Follow the procedure in “Configuring the Locality Agent for the First Time (Android)” on page 94 to configure agent settings and device settings so that data can be collected and sent to the Locality server.


1 (Optional for Locality server, and required for Locality Cloud) If your Locality server is set to enforce client authentication, generate and securely distribute authentication codes that Locality agents must provide to the server before further communication is permitted.


“Distributing Client Authentication Codes” on page 219

2 Confirm that a running Locality server is available and note the server address (the fully qualified domain name).

“Logging on to the Locality Console” on page 197

“Monitoring Locality System Status” on page 200

3 Install the Locality agent “Installing the Locality Agent (Android)” on page 93

4 Configure the Locality agent “Configuring the Locality Agent for the First Time (Android)” on page 94



To distribute the Locality agent app by email

Note: To use this installation method, the Android device must be configured to allow installation of apps from unknown sources. Go to Settings > Security > Device Administration and select the Unknown sources check box to allow installation of non-Google Play Store apps.

1. Go to the NetMotion Wireless Customer Portal and download the Android installation file.

2. Attach the .apk file to an email message.

3. Email the message to your Android users with instructions on how to install and configure the Locality app:

a. Open this message with your Android mail client.

b. Tap the file attachment to download the Locality software.

c. If you are prompted to allow installation of non-Google Play Store apps, tap Settings, select the Unknown sources check box, and tap OK to confirm the settings change. Then, return to the mail client and tap the file attachment again.

d. If you use a Gmail account to open the attachment, the installation begins right away. If you are using a different mail client, tap Preview, Next, and then Install.

e. From the permissions list, tap Accept. The Locality app downloads and starts the installation process.

f. When installation completes, tap Open, accept the license agreement, and then tap Next to configure the Locality app for the first time.

g. [Add your configuration instructions here. Be sure to provide the server address (FQDN) and a valid client authentication code.]

See “Configuring the Locality Agent for the First Time (Android)” on page 94 to determine how your users should configure agent settings and device settings so that data can be collected and sent to the Locality server. Incorporate configuration instructions into your email message.

Configuring the Locality Agent for the First Time (Android)

This topic is for Android users.

The initial configurations steps are the same no matter how you installed the Locality agent for Android. There is no help included with the Android app, so it is important to convey this information to users. The section below explains all of the possible options, but your instructions to users should be more specific. See “Sample Message to Android Users Receiving the Locality Agent via Email” on page 96 for an example of the sort of guidance you should give.

To complete initial configuration of the Locality app on an Android device

1. Open the Locality app to configure required Locality app settings.

2. Accept the terms of the end-user license agreement and tap Next.

3. In the Server Address screen, type the fully-qualified domain name (FQDN) of the Locality server to which you want the agent to connect and tap OK.

Example: yourlocalityserver.yourcompany.com

4. Require trusted cert is a security setting ensuring that the Locality agent can send collected data only to a Locality server that provides a trusted third-party CA server certificate. Change the setting as necessary and tap Next:

° Locality Cloud—Agents reporting to a hosted Locality Cloud server should keep this setting enabled; it provides a way for the agent to confirm that it is connected to a trusted Locality server.

° Local-hosted server—If your local Locality server is configured with a third-party CA server certificate, keep Require trusted cert enabled. If the Locality server is configured to use the default self-signed server certificate, you should disable this setting.

5. For added security, your Locality server may be configured to require a client authentication code. (On Locality Cloud this is required.) If so, the Locality agent must be configured with an



authentication code generated by the server. You have the option to enter the authentication code during Locality agent setup. Either:

° Tap I have an authentication code and enter the code. Type the authentication code you received from the Locality system administrator. The code is not case sensitive and the hyphens are optional. Tap Finish to complete setup.

° Tap I do not have an authentication code and Finish to skip this step and complete setup. When opened, the Locality agent application will prompt for an authentication code if the server requires one.

Locality Cloud: Agents reporting to a hosted Locality Cloud server are required to provide an authentication code, which can be entered during the initial setup process or entered later.

6. The Locality agent now connects to the server.

° If the connection succeeds: The Status page displays the date and time when the Locality agent connected to the Locality server. At this point, the agent has received a device license and is permitted to collect and send data samples to Locality server.

° If the connection fails because you did not enter an authentication code during installation or you specified an authentication code that was not recognized by the server: You are prompted to enter the client authentication code. Until the agent can provide a valid code, it remains unlicensed and cannot collect or send data samples to the server. The agent will continue to prompt until you enter a code accepted by the server.

° If a communication error displays: See “Locality Agent Cannot Connect (Android)” on page 255.

7. To show network performance data in coverage maps and device maps, Locality must get location data from an active GPS service. Check Location to see whether GPS is enabled on the device.

If you see GPS is disabled in location settings, tap Edit location settings and enable the standalone GPS provided by the Android device. Then go back to the Locality Status screen and check Location again.

If the GPS is enabled, one of the following status messages displays:

° Known: Indicates that GPS is enabled and the signal is good.

° Searching for GPS location: Locality is currently looking for a GPS signal. ° GPS location status temporarily unavailable: Indicates that GPS is enabled, but the

received GPS signal is not sufficient to report a precise position, or the signal is not available (usually a situation where the GPS receiver is inside or blocked by large buildings outside).

Tap Search for GPS location to manually start a new satellite search. The search lasts up to 10 minutes or until a satellite signal is found.

To troubleshoot GPS availability, see “Locality Agent Not Reporting Location (Android)” on page 256.

8. Initial setup is now complete. You may want to configure battery life settings. For more information, see “Conserving Battery Life (Android)” on page 258.



Sample Message to Android Users Receiving the Locality Agent via Email

The following sample message provides instructions to install the Locality agent app and configure it for use with a Locality Cloud server:

Attached is the NetMotion Wireless Locality agent. Once installed on your Android device, Locality gathers data that helps to monitor what you are experiencing out in the field - what kind of coverage you’re getting, whether there are trends in network performance as a result of technology, radio hardware, location, or other environmental factors, and so on.

Follow these steps to configure the agent to begin collecting data:

1. Tap the file attachment to download the Locality software.

2. If you are prompted to allow installation of non-Google Play Store apps, tap Settings, select the Unknown sources check box, and tap OK to confirm the settings change. Then, return to the mail client and tap the file attachment again.

3. When prompted, tap Package Installer and then Install to proceed with installation.

4. From the permissions list, tap Accept. The Locality app downloads and starts the installation process.

5. When installation completes, tap Open to configure required Locality app settings.

6. Accept the terms of the end-user license agreement and tap Next.

7. In the Server Address screen, type <your server address here> and tap OK.

8. Keep the Require trusted cert check box selected. [Change this instruction as needed.]

9. Tap I have an authentication code and enter <valid authentication code here>. The code is not case sensitive and the hyphens are optional. Tap Finish to complete setup. [The Locality Cloud server requires an authentication code. If your locally-hosted server does not, tell users to tap I do not have an authentication code and Finish.]

10. Under Device Status, check Location to see whether GPS is enabled on the device.

If you see GPS is disabled in location settings, tap Edit location settings and enable the standalone GPS provided by the Android device. Then go back to the app Status screen and check Location again.

11. Initial setup is now complete. [You may want users to configure battery life settings. See “Conserving Battery Life (Android)” on page 258.]

Locality Agent Installation Overview (iOS) This topic is for iOS users. There are two different ways to gather data for the Locality agent

running on iOS—you can use one or both in your deployment:

Diagnostics—If your Locality deployment is licensed for Mobile Diagnostics and users run into any issues while using Locality—for example, an application is not working, or there is no network access—they can generate a diagnostic report that will also be available to you in the Locality console. Install the diagnostics app from the Apple Store and use it to find the likely reason for connectivity issues. Users can see a summary and details for each test, which can also be run in “standalone mode.”

The diagnostic capabilities differ slightly between agent platforms; see “Mobile Diagnostics Agent Compatibility” on page 226 for more information.



Inventory—The Locality agent for iOS requires version 3.x or later Locality server with an Inventory Module license. Inventory management and client authentication must be enabled on the server. Locality agents can send device information to a Locality server installed at your site, or report to a hosted Locality Cloud server made available by your NetMotion Wireless partner or sales representative.


To deploy the Locality agent on an iOS device, complete these tasks:

Installing the Locality Agent (iOS)

This topic is for iOS users.

Your Locality server should be up and running before you deploy Locality agents. To install the Locality agent on an iOS device, follow the procedure below. Complete software and hardware requirements are described in “Locality Agent Requirements” on page 15.

To install the Locality app using the Apple Store

1. Gather the following information (provided by your Locality system administrator):

° Server Address: This is the fully qualified domain name of the Locality server to which the agent will connect.

° (Locality server) Authentication Code: (Optional) If the Locality server is configured to require client authentication, your system administrator will send you a code.

° (Locality Cloud) Authentication Code: (Required) The client authentication code is used by Locality Cloud to confirm that the agent can be trusted.

2. On the iOS device, tap App Store.

3. Search the App Store for “Locality”.

4. In the Apps list, tap Locality.

5. Tap Install.

6. Go to the Settings screen and specify the Locality server to which you want to connect. See “Locality Agent Settings (iOS)” on page 283 for details.

Enrolling a Device in the Locality Inventory System (iOS)

This topic is for iOS users.

The Locality system administrator must provide iOS device users with the web page URL and Locality client authentication code needed to enroll an iOS device in the Locality Inventory system. The URL is in the format https://<yourserver>.locality.com/ios.


1 (Required) Your Locality server must be configured to enforce client authentication.

Generate and securely distribute authentication codes that Locality agents must provide to the server before further communication is permitted.


2 Have users download the app from the Apple Store.

“Installing the Locality Agent (iOS)” on page 97

3 (Optional) Enroll the Locality agent device in the Locality Inventory system.

“Enrolling a Device in the Locality Inventory System (iOS)” on page 97



Inventory enrollment requirements

The inventory enrollment process requires a Safari browser with private browsing mode disabled, and JavaScript and cookies enabled.

To complete the enrollment process, HTTP port 5213 must be open on all routers and firewalls between the iOS device and the Locality iOS gateway server.

Locality installs a configuration profile that includes Mobile Device Management (MDM). To work correctly, no other configuration profile containing MDM can be present on your device.

To enroll an iOS device in Locality Inventory

1. Start the Safari web browser and use the URL provided by your Locality administrator to open the Locality Inventory Enrollment page.

2. On the Locality Inventory Enrollment page, enter the authentication code provided by your Locality administrator and tap Enroll.

3. When the Install Profile page opens, tap Install to download the profile to your device.



4. A warning page displays information about the NetMotion Locality Inventory profile. Tap Install to activate the profile on your device.

5. If prompted to do so, enter your device passcode.

6. If you see the message Profile Installation Failed: Mobile Device Management is already installed go to “To recover following a ‘Mobile Device Management is already installed’ message” on page 101.

7. If you see the message Profile Installation Failed: Profile Failed to Install go to “To recover following a ‘Profile Failed to Install’ message” on page 102.



8. If the profile installed correctly, you will see a confirmation page. Tap Done to return to the Safari browser.

9. Your iOS device is now enrolled and configured to send data to Locality.

Note: You may reach this page prematurely if you interrupt the Locality profile installation process by tapping Cancel or Home. If you did not complete the enrollment process, tap Retry to reattempt enrollment.



To recover following a ‘Mobile Device Management is already installed’ message

If a profile containing Mobile Device Management settings already exists on your iOS device, you will see the following error message:

The existing profile must be removed before you can install the Locality Inventory profile. To do so:

1. Tap OK to close the message and then tap Cancel to stop the Locality enrollment process.

2. A Profile page displays the existing profiles. If you have multiple profiles installed on your device, select the one that contains Mobile Device Management. To discard it, tap Remove.



3. When prompted, tap Remove to proceed or Cancel to keep the existing profile. If you tap Remove, you may have to enter the device passcode; the profile is removed and you are returned to the General page in the iOS Settings app.

4. Start Safari. The following page opens:

5. Tap Retry and begin the enrollment process again.

To recover following a ‘Profile Failed to Install’ message

A Locality agent running on iOS uses port 5213 to reach the inventory gateway. If port 5213 is blocked, the iOS device cannot communicate with the Locality server and you will see the error message Profile Failed to Install. Because external/public WiFi networks may block port 5213, using a cellular network during enrollment is preferred.

If inventory enrollment fails with the Profile Failed to Install message:

1. Turn off WiFi on the iOS device.

2. Connect to a WWAN (cellular) network while you perform the inventory enrollment process.

Following successful enrollment, the device can use either WiFi or WWAN for Internet access.

Upgrading Locality Agents Use the procedures in this section to upgrade Locality agents to v3.x.

Upgrading Locality Agent (Windows)


To manually upgrade the Locality agent on a Windows laptop, you must be logged on to the system with administrator privileges.



Run the Locality agent Setup file (for example, Locality_agent_3.10_Setup.exe) locally on the laptop or tablet where you want to install the new Locality agent. The Setup program recognizes that the Locality agent exists and proceeds with an upgrade. All current configuration settings are preserved during an upgrade.

Upgraded Locality agents that will connect to a Locality server that has client authentication enabled (which is always true for Locality Cloud) must be configured with a client authentication code and with the fully qualified domain name of the Locality server.

Notes

The Locality agent can be silently installed or upgraded using Windows Installer (MSI), with configuration options specified on the command line. See “Automating Installation of the Locality Agent” on page 80 for details.

The Locality client is supported on Windows 10 (Pro and Enterprise Editions) for 32- and 64-bit operating systems. Upgrading from Windows 7 or Windows 8.x to Windows 10 with Locality installed is not supported. If you plan to upgrade the operating system for any of your Windows devices, first uninstall the client, upgrade the operating system, and then install the Locality client for Windows.

To manually upgrade Locality agent to v3.x on a Windows laptop or tablet

1. Copy the Locality agent Setup file to a local drive on the Windows device.


1. On the Windows laptop or tablet where the Locality agent is installed, log on with administrator privileges.

2. Run a local copy of the Locality agent Setup file. The setup file is a self-extracting executable file that will extract files and launch Setup on the local drive.


4. Accept the default destination folder for installation of Locality agent files. Click Next.

5. Click Install to start the upgrade process.

6. A window displays the status of the Locality agent upgrade process.

7. Near the end of the installation process, Setup starts the Locality agent and tries to connect to the Locality server. When the installation completes, you are prompted to click Finish to exit Setup.

8. By default, on exit, the Locality agent application opens.

9. (For agents connecting to a locally-hosted server only) On the Status tab, check the Server Last communication time. If it is Never, the Locality agent cannot communicate with the server. To troubleshoot this, see “Locality Agent Cannot Connect (Windows)” on page 251.

10. Click Configuration to see the current agent settings.

If you are upgrading Locality agent from v1.x to v3.x, make the following configuration changes as needed:

a. In the Server Address box, type the fully-qualified domain name of the Locality server to which you want the agent to connect. For example:

Locality Cloud: yourcompanyserver.localitycloud.com

Local-hosted server FQDN: yourlocalserver.yourcompany.com

b. The Require a trusted server certificate setting ensures that Locality agents can send collected data only to a Locality server that provides a trusted third-party CA server certificate. Change the setting as necessary:

Locality Cloud: Agents reporting to a hosted Locality Cloud server should enable this setting (check box selected), as it provides a way for the agent to confirm that it is connecting to a trusted Locality server.



Local-hosted server: If the Locality server is hosted locally at your site and configured to use the default self-signed server certificate, you should clear the Require a trusted server certificate check box.

If your local Locality server is configured with a third-party CA server certificate, enable Require a trusted server certificate.

c. If needed, make adjustments to the current GPS and Remote Broadband settings.

d. Click OK to save all changes and return to the Status tab.

11. If the Locality server requires a client authentication code, a message prompts you to enter the code. Until the code is provided, the agent won’t be allowed to connect to the server to obtain a Locality device license. Without a license, the agent won’t collect data. If you need an authentication code, contact your system administrator.

To add a client authentication code:

a. Click Enter Code.

b. In the Enter Authentication Code window, type the authentication code you received from the Locality system administrator. The code is not case sensitive and the hyphens are optional. Click OK to return to the Status tab.

12. The agent immediately attempts to connect to the Locality server. If successful, Last communication time updates to show the time that the connection took place. The Locality agent now has a device license and is ready to collect and report data to the server.

Additional Manual Driver Installation May Be Required

Devices that have one of the following embedded network adapters require a special NetMotion Locality filter driver that is not installed by default:

Any Ericsson network adapter that is embedded on a laptop that runs Windows 7 or later Dell DW5565 HSPA+ Mobile Broadband Module (Ericsson c5621) HP hs3121 HSPA+ Mobile Broadband Module (Huawei MU733)

To install this driver, see “Deploying Locality with Adapters that Require a Locality Filter Driver” on page 76.

For information about additional configuration options available in the Locality agent, see “Configuring Locality Agents (Windows)” on page 114.

Upgrading Network Adapter Firmware on a Locality Agent (Windows)

Before upgrading the network adapter firmware on a Locality agent device, always stop the NetMotion Wireless Locality service and then apply the firmware upgrade. After completing the firmware upgrade, restart the Locality service.

To upgrade the network adapter firmware on a Locality agent Windows device

1. Click Windows Logo key + R to open the Run dialog box.

2. In the Open text box, enter services.msc and click OK.



The Services dialog box opens to show a list of all available local services:

3. In the Name column, select NetMotion Wireless Locality.

4. Click Stop to stop the service.

5. Perform the network adapter’s firmware upgrade as directed by your carrier’s upgrade software.

6. When the firmware upgrade is complete, return to the Services dialog box and click Start to restart the NetMotion Wireless Locality service.

Note: If you reboot your computer as part of the firmware upgrade process, the NetMotion Wireless Locality service restarts automatically.

Upgrading Locality Agent (Android)

This topic is for Android users.

When users install a new version of the Locality app, the Install program recognizes that the Locality agent exists and proceeds with an upgrade. All current configuration settings are preserved during an upgrade.

To upgrade the Locality agent on an Android device, use one of the two methods provided here. The method you choose should match the one you used to install Locality initially. For example, if you originally distributed the Locality agent app by email, then distribute the new version of Locality agent by email too.

Upgraded Locality agents that will connect to a Locality server that has client authentication enabled; they must be configured with a client authentication code and with the fully qualified domain name of the Locality server.

Upgrade Using the Google Play Store App

If your users originally installed the Locality agent app from Google Play Store, tell them to use the following procedure to upgrade the Locality agent app:

To upgrade the Locality agent app from Google Play Store

1. Go to Google Play > My Apps and find Locality in the Manual updates list.

2. Tap Locality to install the update. All current configuration settings are preserved during the upgrade.

3. When Locality installation completes, tap Open.

4. To see current settings, tap the Settings button from the action bar or options menu. Make the following configuration changes as needed:

a. Tap server Address and type the fully-qualified domain name of the Locality server to which you want the agent to connect. [Specify the server’s FQDN here.]

For example:





Tap OK.

b. Locality Cloud: Enable Require trusted cert (tap to select the check box).

c. Local-hosted server: [Based on Locality server configuration, direct users to either enable or disable the Require trusted cert setting:

If the Locality server is configured to use the default self-signed server certificate: Clear the Require trusted cert check box.

If the Locality server is configured with a third-party CA server certificate: Select the Require trusted cert check box.]

d. Return to the app Status screen.

5. Local-hosted server: [If your Locality server is configured to require client authentication, add the following instructions.]

A message prompts you to enter a client authentication code:

6. Locality Cloud: A message prompts you to enter a client authentication code:

a. Tap Enter Code.

b. In the Enter Authentication Code window, type: [provide a valid client authentication code here]. (The code is not case sensitive and the hyphens are optional.)

c. Tap OK to return to the app Status screen.

7. The agent immediately attempts to connect to the Locality server. If successful, Last communication time updates to show the time that the connection took place. The Locality agent now has a device license and is ready to collect and report data to the server.

Distribute the Upgrade by Email

If you originally distributed the Locality agent app as an email file attachment, use the following upgrade method:

To distribute the Locality agent upgrade by email

1. Go to the NetMotion Wireless Customer Portal and download the new version of the Android installation file.

2. Attach the .apk file to an email message.

3. Email the message to your Android users with installation instructions such as the following:

To install the attached Locality upgrade:

a. Open this message with your Android mail client.

b. Tap the file attachment to download the Locality software.

c. When prompted, tap Package Installer.

d. Tap OK to replace the application.

e. Tap Install to proceed with installation. All current configuration settings are preserved during the upgrade.

f. When Locality installation completes, tap Open.

To configure the Locality agent:

a. Tap Settings (on the action bar or options menu) to see the current agent settings.

b. Tap server Address and type: [provide the fully-qualified domain name of your Locality server]

c. Tap OK.

d. Locality Cloud: Enable Require trusted cert (tap to select the check box).



e. Local-hosted server: [Provide instructions on how Require trusted cert should be set. If the Locality server is configured to use the default self-signed server certificate, users should clear the Require trusted cert check box.

If your local Locality server is configured with a third-party CA server certificate, users should select the Require trusted cert check box.]

f. Return to the app Status screen.

g. Local-hosted server: [If your Locality server is configured to require client authentication, add the following instructions.]

A message prompts you to enter a client authentication code:

h. Locality Cloud: A message prompts you to enter a client authentication code:

Tap Enter Code.

In the Enter Authentication Code window, type: [provide a valid client authentication code here]. (The code is not case sensitive and the hyphens are optional.)

Tap OK to return to the app Status screen.

i. The agent immediately attempts to connect to the Locality server. If successful, Last communication time updates to show the time that the connection took place. The Locality agent now has a device license and is ready to collect and report data to the server.

Uninstalling Locality Agent Use the following procedures to remove the Locality agent from a Windows computer, Android device, or an Apple device.

To remove the Locality agent from a Windows computer

1. On the computer where the Locality agent is installed, log on as administrator.

2. Open the Control Panel and run Uninstall a program.

3. From the list of installed programs, select NetMotion Wireless Locality.

4. Click Uninstall to remove the Locality agent software.

Note

Simply disabling your adapter in the Windows Device Manager does not stop the Locality agent from attempting to collect and send data to the Locality server.

To remove the Locality agent from an Android device

Note: These steps describe uninstalling the Locality agent on a standard Google Nexus device. The steps on your device may differ somewhat.

1. Navigate to Menu > Settings > Applications > Manage applications. Or, on devices running Android v4.0, go to Settings > Apps.

2. Scroll the list of apps to find Locality.

3. Tap Locality.

4. Tap Uninstall.

To remove the Locality Inventory profile from an Apple device

1. On the iOS device, tap Settings > General > Profile.

2. Tap to open the NetMotion Locality Inventory profile.

3. Tap Remove. Confirm that you want to remove the profile.

4. If prompted, enter the device passcode. The Locality profile is removed from the device.


Chapter 5 - Configuring Locality | 109

Chapter 5Configuring Locality

Most Locality configuration takes place during Setup:

Setup Description

Locality server (Does not apply to Locality Cloud) Setup automatically runs the Locality Configuration Wizard so that you can provide initial configuration settings and set up the Locality database. You also have options to add a Locality license, enable Mobility Analytics data integration with Locality reports, enable iOS inventory reporting, configure client authentication, and configure alerts and messaging.

To make changes to the initial Locality server configuration or to update or restore the Locality database, re-run the Configuration Wizard. See “Configuring the Locality Server” on page 110 and “Locality Configuration Wizard” on page 33 for more information.

Mobility analytics data integration

If you have Mobility Analytics Module v9.50 or later, and want to include analytics data in Locality reports, you must install and configure Locality Connect for Mobility on the server that hosts the Mobility Analytics Module.

Locality agent (Windows)

On the Windows platform, to distribute a pre-configured Locality agent, use one of these options:

The Locality agent can be silently installed using the Windows Installer (MSI), with configuration options specified on the command line. See “Performing a Silent Install or Upgrade” on page 80.

Use an operating system image to deploy the Locality agent. When a deployed machine boots from the image, the Locality service starts automatically, the client is re-licensed, and a new device ID is created. See “Cloning Agent Configuration” on page 89.

Perform a remote installation with PsExec. See “Performing a Remote Installation” on page 90.

To have users manually install and configure the Locality agent:

Make the Locality agent Setup program available on a network share. Tell users to download and run Setup locally to install Locality on their mobile devices. Setup prompts for the information needed to configure the agent. For details about running Setup on a mobile device, see “Installing the Locality Agent Manually” on page 77.

Once a Locality agent is installed, configuration settings (such as the fully-qualified domain name of the Locality server) can be modified by running the agent application to edit settings on the device itself.


110 | Chapter 5 - Configuring Locality

Configuring the Locality Server To modify Locality settings for Locality licenses and client authentication codes, go to the System page in the Locality console.

To access the Locality console

There are several ways to get to the console:

° Start your web browser and enter the name of the Locality server in the address window. For example:

http://mylocalityserver.mycompany.com

Locality server only:

° Open Locality Console on the Start menu or page.° On the computer running the Locality server, open a browser and enter the following URL:

http://localhost

To log on to the Locality console

1. Enter a valid user name and password.

° If using a domain user account, specify the user name as <domain name>\<user name>. ° If using a local account, specify the user name as <host name>\<user name>, and then

click Log On.

2. Based on the logon credentials provided, the server identifies the role assigned to this user and provides access to the console features associated with that role. For more information about user roles, see “Managing Access to the Locality Console” on page 198.

From the console System page you can manage client authentication codes and Locality licenses. See:

“Managing Locality Licensing” on page 206 “Using Client Authentication to Deploy Locality Securely” on page 217

Configuring the Locality Server to Use a Signed Certificate

By default, when Locality is installed on site, a self-signed Transport Layer Security (TLS) server certificate is generated and bound to the Locality server automatically. If this level of security suits your needs, your Locality agents must be configured not to require a CA-signed server certificate:

On Windows devices clear the Require trusted server certificate check box On Android devices clear the Require trusted cert check box

For higher security, you can configure the Locality server to use the Transport Layer Security (TLS) protocol to validate its identity to connecting Locality agents, and to secure information that Locality agents send to it. This is done using a certificate signed by a third-party certificate authority (CA).

Locality agent (Android)

On the Android platform, the Locality agent must be configured manually.

See “Configuring the Locality Agent for the First Time (Android)” on page 94 for more information.

Once a Locality agent is installed, configuration settings (such as the fully qualified domain name of the Locality server) can be modified from the agent application: tap the Settings button from the action bar.

Locality agent (iOS)

On the iOS platform, the Locality agent must be configured manually.

Once a Locality agent is installed, configuration settings (such as the fully qualified domain name of the Locality server) can be modified on the Settings screen. See“Locality Agent Settings (iOS)” on page 283 for details.

Setup Description



To enforce server authentication on a locally-hosted Locality server, use the procedures in this section to install your certificate and to bind it to Locality. After configuring the Locality server to use a signed certificate, instruct mobile workers running the Locality agent to select this check box:

On Windows devices select Require trusted server certificate On Android devices select Require trusted cert

To add a trusted certificate to your certificate store

1. On the computer where the Locality server is installed, start Internet Information Services (IIS) Manager.

2. Select the computer on which the Locality server is installed, and then open Server Certificates.

3. If your Locality server is already part of your domain, it is likely that the certificate you want to use is already available in the certificate store.

° If the certificate is listed, skip to the next procedure (binding the certificate to the Locality console and gateways).

° If the certificate is not in the list, continue to the next step.

4. Copy the trusted certificate file (.pfx) to the computer hosting the Locality server.



5. On the Server Certificates page in IIS, click Import in the Actions list on the right, and then specify the .pfx file that you copied to this computer:

Once the certificate is imported, it appears in the list on the Server Certificates page.

To bind the trusted certificate to the Locality console and gateways

1. In IIS, expand the list of sites, right-click on Locality Console, and then select Edit Bindings from the pop-up menu:

2. Select the HTTPS line and click Edit.

3. In the Edit Site Binding dialog box, select the certificate you want to use from the SSL certificate drop-down list, and then click OK.

4. In the list of sites, right-click Locality iOS Inventory Gateway and edit its bindings just as you did for Locality Console. Repeat for Locality Provisioning Gateway and Locality Sample Gateway.

Warning! Do not bind a trusted certificate to the Locality Licensing site.

Related Information

Creating Client Authentication Codes Configuring Automatic Database Maintenance



Configuring Automatic Database Maintenance

In the event of a system failure, Locality database maintenance functions make it possible to restore all data from a known point. By default, Locality performs a daily backup of the Locality databases at 2:00 AM local server time and (as an added measure of safety) archives the most recent backup.

If you want to change the daily start time for database maintenance, contact NetMotion Wireless Technical Support for assistance.

Configuring Locality to Send Agent Data to a Syslog Server

Locality can send the data it gathers from mobile devices—running on Windows, iOS, or Android—to a syslog server so that you can use your own tools and applications, such as Splunk, to monitor the health of your mobile wireless network. This section describes how to configure Locality for syslog; for tables of key/value pairs, seethe syslog section in the online help.

Getting there: Locality Console > System > Syslog

To configure Locality to send messages to a syslog server

1. Log on to the Locality console as an administrator and go to System > Syslog.

2. Under Syslog Status, click Enable to configure Locality to send messages to a syslog server.

3. The Syslog Configuration section shows the host name and port that Locality uses to communicate with the syslog server. It also lists the syslog message types that it will send.

Click Edit to open the Syslog Configuration dialog and configure these options:

Option Description

Host The IP address or fully-qualified domain name of the syslog server host to which agent data will be sent. The default value is the localhost IP address, 127.0.0.1.

Port By default, the Locality server uses port 1468 to communicate with the syslog server.

Send over TLS Use transport layer security (TLS) to provide a secure connection for the transport of syslog messages.

Require a trusted server certificate when sending over TLS

When Send over TLS is enabled, you can also require a trusted server certificate, which is provided by a third-party certificate authority (CA).


http://www.netmotionwireless.com/support/docs/Locality/310/help/localityhelp.htm?single=1&context=nmwlocalityconsole&topic=syslog


When enabled, Locality agent data is sent to your syslog server throughout the day at regular, short intervals. The interval for Mobility Analytics Module data, if it is part of your Locality deployment, is a little longer (15 minutes).

4. Make sure your firewall is configured to allow syslog traffic. By default, Locality uses TCP port 1468 to communicate with the syslog server.

Configuring Locality Agents (Windows) This topic is for Windows users.

Initial Locality agent configuration takes place during Setup. Subsequently, the Locality agent user interface provides a Locality Configuration dialog box that allows users to see or change current settings.

Note: During initial setup, a Locality system administrator may install the Locality agent with a setting that prevents non-Administrator users on the local machine from making changes to Locality agent settings, data, and configuration files. For information about implementing and managing this restriction, see “Securing Locality Agent Settings, Data, and Configuration Files” on page 71.

Specifying a Locality Server Address


The Locality agent automatically connects to the Locality server address you specified during Setup. To modify this address, use the Locality Configuration dialog box.

To specify a Locality server address

1. Point to Start > Programs > NetMotion Wireless Locality > Locality.

2. Click the Configuration button.

3. In the Address box, enter the fully-qualified domain name of the server to which you want the agent to connect.

4. Click OK.

Specify any combination of the following types of syslog messages to include:

Alerts Alerts and Messaging is a separately licensed module that enables you to generate alerts and messages based on criteria that you define in the console. Choose Alerts to send these criteria to the syslog server.

Device Samples The Locality agent is a service that runs in the background on mobile devices. It transmits data to the Locality server, including its location, which carriers are handling its connection, what the current signal quality is, and who is logged on to the device.

Mobile Diagnostics Mobile Diagnostics is a separately licensed module that runs built-in and custom tests on Locality agents to diagnose connectivity and performance issues experienced in the field.

Mobility Analytics If you are running Mobility and have the Mobility Analytics Module, Locality can provide additional information about the applications running on Locality devices. For example, you can observe mobile worker application usage trends over time and see which applications are consuming the most resources and where usage could be curtailed.

Option Description



Adding an Authentication Code for Advanced Client Security

Locality uses client authentication codes to provision Locality agents with x509 client certificates that are used by the Transport Layer Security (TLS) protocol to manage and secure all communication between Locality agent and server.

On locally-hosted Locality servers, use of client authentication is optional; for Locality Cloud, client authentication is required. See:

“Planning for Security—Client Authentication and Server Authentication” on page 67 “Creating Client Authentication Codes” on page 217 “Distributing Client Authentication Codes” on page 219

Specifying a GPS Receiver


Note: If your mobile device uses a mobile hotspot that has an integrated GPS receiver, see “Configuring Locality to Use a Mobile Hotspot with Integrated GPS” on page 119.

By default, Locality is configured to detect a GPS receiver running on your agent device by scanning COM ports that use a baud rate of 4800, 9600, or 38400. If remote broadband support is enabled, Locality also looks for a GPS receiver on the port the adapter uses. Locality uses the first GPS receiver that it finds (it can be either integrated with a network adapter or function as a stand-alone receiver).

When a GPS receiver is recognized by the Locality agent, its name and communication port are displayed on the Status tab.

You can manually configure Locality to use a specific GPS receiver. This may be necessary if:

Your GPS receiver is not automatically detected because it uses a baud rate other than 4800, 9600 and 38400.

You have multiple GPS receivers on the agent device and Locality is not using the one that you prefer.

You are not getting location data from the current GPS receiver and want to try a different one.

To change your GPS receiver on the Locality agent

1. Point to Start > All Programs > NetMotion Wireless Locality > Locality.


3. Under GPS, the options in the Receiver list box specify what method Locality uses to detect a GPS receiver available to the agent laptop:

Option Description

Detected automatically This option is on by default. To be detected, the GPS receiver must generate TAIP or NMEA 0183-compliant data:

Locality scans COM ports that use a baud rate of 4800, 9600 and 38400.

Locality looks at Windows location sensors for a GPS receiver.

If remote broadband support is enabled, Locality also looks for a GPS receiver on the port the adapter is configured to use.



Specifying Auto-Start for Integrated GPS Receivers


To gather location-related data, Locality must communicate with an active GPS receiver on the agent device. If your preferred GPS receiver is integrated in an adapter, selecting the auto-start option increases the likelihood that the receiver is active, meaning that Locality can collect location information more reliably. When selected, Locality starts the integrated GPS receiver automatically. For more information, see “Using Auto-Start to Keep the GPS Receiver Active (Windows)” on page 253.

To change your Auto-start integrated GPS receivers setting



3. Under GPS, configure Auto-start integrated GPS receivers:

° If your preferred GPS receiver is integrated in an adapter, select this check box.

Note: Locality agents that use a remote broadband adapter, such as a CradlePoint trunk modem, should always select this check box.

° If you want to use your device’s stand-alone GPS receiver (such as a USB or Bluetooth GPS receiver), clear this check box.

Recommendations for Standalone GPS Receiver Configuration


Serial connection Use this option to configure Locality to connect to a specific standalone GPS receiver:

COM port: The port through which the GPS receiver transmits location information to the Locality agent.

You can select the COM port of a detected GPS receiver from the drop-down list.

If your preferred GPS receiver was not detected, specify the COM port it is using, in the format COM#, where # is a positive number.

Baud rate: The default setting (Automatic) can detect standard GPS receivers on the specified COM port, provided the port’s baud rate is 4800, 9600, 19200, 38400, 57600 or 115200.

If you know the baud rate required by your GPS receiver, you can skip the automatic COM port baud rate scan. Select the required rate from the drop-down list.

If your GPS receiver uses a non-standard baud rate, specify the correct COM port baud rate manually.

Note: Stand-alone GPS receivers that use the NMEA 0183 standard or TAIP protocol may require additional configuration. For details, see “Recommendations for Standalone GPS Receiver Configuration” on page 116.

Remote broadband adapter

In most cases the Receiver setting should be left at Detected automatically. If multiple GPS receivers are available on your agent device, Locality uses the first GPS receiver that it detects. You may have to specify the receiver manually to ensure that Locality uses the one you intend.

Windows location sensor Locality looks at Windows location sensors for a GPS receiver.

Option Description



Standalone GPS receivers can use either the NMEA 0183 standard or the TAIP protocol. Locality can collect and interpret both types of data for use in maps and charts:

The National Marine Electronics Association (NMEA) 0183 protocol is an industry standard GPS location data protocol originally developed for the marine industry.

The Trimble ASCII Interface Protocol (TAIP) is a Trimble-specific digital communication protocol used to report GPS location data, usually over a serial COM port.

Configuring Your Standalone GPS Receiver

If your standalone GPS receiver supports both TAIP and NMEA protocols, we recommend that you configure it to use NMEA for highest GPS quality. Though Locality supports TAIP, NMEA provides more precise location data.

If your GPS receiver must use the TAIP protocol, follow these guidelines:

Locality recognizes the following TAIP sentence formats:

Configure the TAIP reporting interval to send data at least once every 5 seconds; otherwise you may see gaps in your GPS trace.

Configuring the Locality Agent to Use a Specific GPS Receiver

By default, Locality attempts to discover a GPS receiver running on your agent device by scanning COM ports that use a standard baud rate. If you are configured to use a remote broadband adapter, Locality looks for a GPS receiver on the UDP or TCP port. Locality uses the first GPS receiver that it finds.

If your standalone GPS receiver is not detected, you can manually configure Locality to use a specified port and baud rate to read GPS location data. See “Specifying a GPS Receiver” on page 115.

Configuring Locality to Use a Remote Broadband Adapter


If the Locality agent laptop uses a supported remote broadband adapter to connect to the WWAN, configure the Locality agent and specify the connection method Locality will use to connect to the modem.

To specify and configure a remote broadband adapter



3. Under Remote Broadband, configure Adapter:

TAIP Sentence Format Locality Notes

Compact Position (CP) CP sentence format provides good location precision.

Position/Velocity Solution (PV) PV provides better precision than CP.

Long Navigation Message (LN) LN provides the best location precision data. If NMEA is not available, NetMotion Wireless recommends that you configure your Trimble receiver to output LN sentences.

Option Description

Disabled The remote broadband Adapter setting is disabled by default. This prevents Locality from searching for a remote broadband adapter and consuming bytes from your data plan in the process.



Important: To use the Locality agent with a remote broadband adapter, the agent needs to establish a connection to the adapter. For details about firewall configuration, see “Deploying Locality Agent with a Remote Broadband Adapter” on page 73.

Configuring Locality to Use a Mobile Hotspot


Note: If your mobile hotspot device has an integrated GPS receiver that you want Locality to detect and use, go to “Configuring Locality to Use a Mobile Hotspot with Integrated GPS” on page 119.

If the Locality agent laptop uses a supported mobile hotspot device to connect to the WWAN, configure the Locality agent and, optionally, specify the connection method Locality will use to connect to the hotspot.

To specify and configure a mobile hotspot



3. Under Remote Broadband, set Adapter to General Mobile Hotspot.

4. In the Address box, enter the IP address of the device’s HTTP server or select (Default - 192.168.1.1) in the drop-down list.

5. For Password, specify the password required to connect to the administrator web interface on the hotspot device. This may be different from the WiFi password used to connect to the hotspot for access to the WWAN.

The password will be saved in an encrypted format.

Sierra AirLink Specifies that the Locality agent makes a local network connection to the AirLink adapter automatically, using the default IP address and password built into the adapter.

If you are using non-default settings, select Custom settings (see below).

CradlePoint Specifies that the Locality agent connects to a CradlePoint mobile router automatically, using the default user name, IP address, and password built into the adapter.


Rocket Specifies that the Locality agent connects to a Utility Rocket mobile router.

General Mobile Hotspot

Specifies that the Locality agent connects to a mobile hotspot device for Internet access. See “Configuring Locality to Use a Mobile Hotspot” on page 118 for details.

Custom settings check box

Select this option if your Sierra AirLink or CradlePoint trunk modem is configured to use non-default settings.

If you select Sierra AirLink as you adapter, you are prompted for the IP address and password necessary for connecting to the AirLink trunk modem. (The user name for communicating with an AirLink trunk modem is user and cannot be changed.)

If you select CradlePoint as your adapter, you are prompted for a user name, address (123.123.123.123 or 123.123.123.123:45), and password.

You must enter a user name (admin is the default, but must still be entered). In the Password drop-down list, selecting default specifies the internal password.

Option Description



6. If your preferred GPS receiver is integrated into the mobile hotspot device, Locality automatically enables it if the Auto-start integrated GPS receivers check box is selected.

Important: Locality requires a network connection in order to communicate with the mobile hotspot over HTTP using its web-based interface. If Mobility (or a VPN) is installed, the Locality agent will need a special passthrough rule. For more information, see “Mobile Hotspot Configuration” on page 75 and “Passthrough Rules for Mobility Clients” on page 76.

Configuring Locality to Use a Mobile Hotspot with Integrated GPS

Use the following procedure to manually configure a Locality agent to detect a mobile hotspot and use its integrated GPS receiver.

To configure a Locality agent to use a mobile hotspot with integrated GPS

1. Point to Start > All Programs > NetMotion Wireless Locality > Locality.


3. In the GPS settings area, configure the following settings:

a. In the Receiver list box, select Serial connection.

b. Use COM port to specify the port through which the GPS receiver transmits location information to the Locality agent.

You can select the COM port of a detected GPS receiver from the drop-down list. If your preferred GPS receiver was not detected, specify the COM port it is using, in the format COM#, where # is a positive number (for example: COM6).

c. Set Baud rate to Automatic. If your GPS receiver uses a non-standard baud rate, specify the correct COM port baud rate manually.

d. Select the Auto-start integrated GPS receivers check box if your preferred GPS receiver is integrated with a mobile hotspot. This increases the likelihood that the GPS receiver on the mobile hotspot is active, meaning that Locality can collect location information more reliably.

4. In the Remote Broadband area, configure the following settings:

a. In the Adapter list box, select General Mobile Hotspot.

b. You are prompted for the IP address and password needed to establish a local connection to the web interface on the hotspot device.

Address: Select the default address from the IP address drop-down list or enter the IP address that your hotspot uses.

Password: Specify the password required to connect to the administrator web interface on the hotspot device. This may be different from the WiFi password used to connect to the hotspot for access to the WWAN. The password will be saved in an encrypted format.

Monitoring Multiple Adapters on the Same Agent Device


In order to increase connectivity options, some users may run a Locality agent device with two monitored adapters on different carrier networks to ensure coverage at all times. In most cases, Locality can report data for both adapters and accurately represent each one in console maps and reports.



On the agent device, the Locality > Status tab shows the status of adapters that Locality currently detects. If Status shows Connected, Locality is collecting data for the adapter.

When multiple adapters are used simultaneously by a single agent device:

Each adapter is monitored and reported separately. In the Locality console:

° Reports show usage and performance data for each adapter-carrier case.° Device maps and coverage maps display as expected. In situations where a device is

running two or more adapters, the device map provides a drop-down list so that you can choose which adapter you want to review in the device trace:



See “Configuring Locality Agents (Windows)” on page 114 for information about unsupported adapter combinations.

Note

In general, Locality cannot support a device that simultaneously uses two adapters made by the same manufacturer or using the same carrier. However, there are exceptions. For instance, Locality supports a device that connects to and uses a Sierra Wireless AirLink trunk modem for WWAN access, and that also runs a Sierra Wireless network adapter embedded in the laptop.

Configuring Locality Agents (Android) Initial Locality agent configuration should occur immediately after Setup. See “Configuring the Locality Agent for the First Time (Android)” on page 94.

The Locality app Settings screen is always available to mobile workers, allowing them to modify configuration settings as needed. For details about settings, see “Locality Settings (Android)” on page 278.

Configuring Locality Agents (iOS) Initial Locality agent configuration should occur immediately after Setup. See “Locality Agent Settings (iOS)” on page 283 for information about the Settings screen.


Chapter 6 - Exploring Locality Data | 123

Chapter 6Exploring Locality Data

As mobile workers go about their business, moving from one location to another over time, their Locality devices are constantly feeding information to the Locality server. The collected data is made visible in the Locality console as maps and reports that give an administrator a graphical depiction of useful information: In a given time period, what path did the user take? What carrier provided connectivity? What technology? How good was the signal quality?

You can customize Locality maps and reports to suit your needs, print them out, or export them for use in reports.

Using the Locality Console The console has two main functions:

Data analysis and reporting Administration and configuration

Within each category (the tabs labeled Network Performance, Network Usage, and so on), the reports are related: a selection made in one carries over to the other reports in the same category.

1. View reports submitted by Locality agents—running on Windows, iOS, and Android—to identify the reason for connectivity and performance issues.

2. Use these 5 data analysis and reporting categories to analyze the performance of your mobile deployment and tailor reports and maps to your analytic needs.

3. Use the maps to see the overall network coverage experienced by mobile devices and detailed trace information for a device over the course of a day.

4. A report can be any combination of charts, graphs, and tables. The Compression – Mobility tab appears only if you have the Mobility Analytics Module installed at your site.

5. The System tab is for administrators:

° See current status for all components° Define alerts and alert messages and view alert history (separately licensed module)° View or export system logs° See your Locality serial number and license information° Manage client authentication codes° Manage Mobile Diagnostics (separately licensed module)° Manage Locality Cloud user accounts


124 | Chapter 6 - Exploring Locality Data

° Export coverage data for use with third-party GIS applications

To access maps and reports in the console, the Locality server must be licensed.

Browser requirements

To use the Locality console, your web browser must be configured to accept cookies from the console web address and JavaScript must be enabled.

Viewing the Coverage Map and Device Map requires Internet access.







http://localhost

To log on to the Locality console, you must be a member of the Locality Administrators group or the Locality Users group. Authenticate using your Locality console logon credentials: the user name and password assigned by your Locality administrator. Authenticate using your Windows logon credentials (Integrated Windows Authentication).

Data Analysis Overview There are several maps and reports that you can use as a starting point for data analysis. Each is designed to help you identify and solve a particular set of problems, with a high-level goal of helping you cut costs, increase productivity, streamline operations, or troubleshoot problems in the field.

To open a map or report in Locality, click a report category tab in the console (any tab except System). Both maps and reports have a data selection pane on the left:

When you open the Coverage Map, data for the current month is displayed. You can enter a location on the left, such as a city, and select a time frame in order to examine network performance at a time and location where your Locality agents have collected data. For details on selecting map data, see “Analyzing the Carrier Network Using the Coverage Map” on page 140.

The device map enables you to explore the connectivity experience of a user running Locality over the course of one day. When you open the Device Map, no data is displayed: you must select a user, device, or phone number, along with a date. For details on selecting map data, see “Tracing Connectivity with the Device Map” on page 148.

By default, reports open with data from the last 30 days. Enter a few parameters (for example, a month or two and a carrier) to narrow your focus. See “Selecting Locality Report Data” on page 128 for details on how to navigate your data.

For details about the granularity of data provided in maps and reports and how long a given level of detail is available, see “Data Availability in Maps and Reports” on page 239.

This report category... Is designed to answer these questions...

Network Performance Over time, what device/adapter combinations are having moderate or severe connectivity issues? What are the technological factors affecting my team in the field? What impact does the technology provided by the carrier(s) have on my team’s work?

See “Analyzing Network Performance” on page 139 for more information.



Selecting Locality Data At a regular interval, devices running the Locality agent transmit data to the Locality server, including device location, the carriers handling its connection, the signal quality, and the user name of the person logged on to the device. The data is collected in the Locality database and can be viewed in interactive maps and reports in the Locality console.

For details about the granularity of data provided in maps and reports and how long a given level of detail is available see “Data Availability in Maps and Reports” on page 239.

General Rules for Selecting Data

There are slightly different methods for narrowing your focus in maps versus reports (charts, graphs, and tables). See “Selecting Locality Coverage Map Data” on page 140 and “Selecting Locality Report Data” on page 128 for details and step-by-step procedures. The rules described here apply to all Locality reports.

Once you make a selection it is applied to the other reports within that report category (all reports on the same tab): for example, if you select the month of July on one report, it will be selected for the other reports that share the same tab.

Network Usage What is the high-level status of my company’s mobile deployment? Where are the bottlenecks? What are the overall trends?

See “Analyzing Network Usage” on page 161 for more information.

GPS Metrics What causes a lack of GPS data for my workers? Is it a device issue, a GPS modem issue, a matter of geographic barriers, or has the worker deliberately disrupted collection of GPS signal data? Which workers had the most GPS drops? What percentage of time was GPS unavailable for a given device or worker?

See “Analyzing GPS Usage” on page 173 for more information.

Dropped Connections Which devices in my deployment are experiencing the most dropped connections? Are they predominately associated with a particular carrier or device manufacturer?

See “Examining Dropped Connections” on page 181 for more information.

Inventory What is the configuration for my Locality agents (device model, network adapter, and so on)? Are there adapters that are not being used? Who has a particular device?

See “Keeping Track of Network Adapter Inventory” on page 189 for more information.

Mobile Diagnostics What is the reason for connectivity and performance issues on Windows devices deployed to my mobile workforce? Are particular devices or network adapters having problems? What is the state of a machine that is experiencing problems?

See “Analyzing Mobile Diagnostics” on page 193 for more information.

This report category... Is designed to answer these questions...



The following table summarizes selection states and things to keep in mind as you work with maps and reports.

Selecting Locality Map Data

Locality includes two maps that show you what’s going on in the field:

The coverage map lets you explore your network—what carriers are used, what the signal quality is like, and which technology is used (for example, 4G or 3G). It displays aggregated data from all Locality agents that transmitted data during the selected time frame.

Selection Pane Description

Filtering data When you select an item in the selection pane Locality shows all data that is related to it. In addition, the selections that you make on any report apply to the other reports on the same tab. See Category selections below.

Tip: Before you have made any selections, nothing is filtered: you see all available data, even though the check boxes for items in the selection pane are cleared.

Calendar Not all of the days in a month contain Locality data.

Dates in blue all contain data. Dates without Locality data are shown in gray.

Making multiple selections

To choose various months in the calendar, click to select the first month. Use Ctrl-left click to select additional months you want to include in your map or report.

To select a week in the calendar, click the small week number on the left. To select an additional week, press Ctrl-left click.

Time range selection When you are working with GPS Metrics reports, you can filter data using a selected time range with hourly granularity (from 1 hour up to 24 hours). For example, to view data for an early work shift, drag the left slider to 7:00:00 AM. Then drag the right slider to 3:00:00 PM.

Use the Calendar control to apply your time range filter to up to 7 days that you want to compare.

Bookmarks When you add a Locality bookmark to a map or report, you are saving a collection of filters through which to look at your data. The filters represent a query of the Locality database; depending on which filters are used, the data can change.

For example, if you create and bookmark a report on July 7 by using a particular time frame and then clicking Last 7 Days, opening the bookmark later will show data relative to the current date, not data for July 1-7.

Category selections There are several Locality report categories: Network Performance, Network Usage, GPS Metrics, Dropped Connections, and Inventory.

When you are working with reports within one of these categories, any selections that you make in one report are reflected in the other reports. For example, Dropped Connections has two reports: any selections you make in Trends will be reflected in Hardware, and vice versa.

The exception to this rule are the two maps: selections made in reports are not carried over to the maps, and vice versa. In addition, selections made in one map do not carry over to the other map.

Data availability For details about the granularity of data provided in maps and reports and how long a given level of detail is available see “Data Availability in Maps and Reports” on page 239.



The device map focuses on the route of a single device and its wireless experience in the course of one day.

The way you select parameters on these maps differs slightly between the two kinds of maps:

To move the selection pane out of the way after you have narrowed your inquiry, click the black triangle in the top left-hand corner.

Notes

Locality maps are best viewed at full-screen size; maximize the browser window. For details about the granularity of data provided in maps and reports and how long a given

level of detail is available, see “Data Availability in Maps and Reports” on page 239.

Changing the Map View

Note: Locality maps are best viewed at full-screen size; maximize the browser window.

After you select a location (in a Coverage Map) or a device (in a Device Map) there are several ways to change your view of the data.

Moving the Map

A map can be scrolled (moved) by left-clicking and dragging it in any direction. You can use any part of a map to drag it, except the trace route (the colored cells containing Locality data).

Changing the Zoom Level

To change the zoom level, there are several options:

Selection For More Information

Time frame “Specifying a Coverage Map Time Frame” on page 142 “Specifying a Device Map Time Frame” on page 150

Location “Specifying a Location in the Coverage Map” on page 142 “Selecting a Time or Location in a Device Map” on page 151

Display options “Specifying a Coverage Map Display Option” on page 142 “Specifying Device Map Display Options” on page 153

Map details “Examining a Single Grid Cell in a Coverage Map” on page 144 “Device Map Trace Details” on page 154

Exporting results “Saving your Selections or Exporting a Coverage Map” on page 146 “Saving your Selections or Exporting a Device Map” on page 154

Changing the map view “Changing the Map View” on page 127

Zoom Method Description

Zoom bar To set a zoom level, use the bar to the right of the selection pane.

Scroll wheel If you have a scroll wheel on your mouse, you can use it to zoom in (rotate the wheel forward) or out (rotate the wheel backward).

Double-click the map

To zero in, one zoom level at a time, double-click the map away from the trace route (when you double-click a colored cell in a device map, a Details window pops up). Double-clicking also re-centers the map to the new location.



Selecting Locality Report Data

The selection pane for Locality reports is similar to the one for the coverage map. Here’s an overview of a typical selection pane in a report. This one is from Dropped Connections > Trends:

For details about the granularity of data provided in maps and reports and how long a given level of detail is available see “Data Availability in Maps and Reports” on page 239.



Selecting Search Parameters from a List

To produce a report about specific devices, users, or data plans (phone numbers), search for the items of interest. If you type an asterisk ( * ) in the selection pane’s search box and then press Enter, Locality shows you the available categories of data by which you can filter the report. Almost all of the reports, for example, include these categories:

Device Phone # User

To create a report about particular users

1. To see the kinds of items that you can include in your report, type an asterisk ( * ) in the selection pane’s search box and then press Enter. In this example (Inventory > Population), there are several kinds of information from which to choose:

2. To see the list of users, select User. With an asterisk in the search box, all users are listed. Select the check box next to the users you want to include in your report. For example:

The charts and tables on the right are immediately updated using your selections.

Selecting a Time Frame in a Report

When you specify a time frame for your report, the charts and tables on the right in your browser window are immediately updated using your selections. The procedure in this section shows you how to select two particular dates for a report; see “Selecting Locality Report Data” on page 128 for an overview of all calendar functions.



To narrow a time frame selection

1. In this example, there is Locality data for several months (all of the ones displayed in blue). To select just May and June, left-click on one of them, and then Ctrl-left-click on the other:

2. You can narrow your selection by choosing particular dates. Click a date in blue; to select another one, press Ctrl-left-click. In this case your report will show data for June 11 and 17:

3. To select individual dates in different months:

a. Click a date in one month; in this example, June 17 is selected.

b. To add May 7 to your selected dates, click the back arrow (<) to move to May, and then Ctrl-left-click May 7.



To double-check which dates are included in your selection, point the cursor to one of the dates:

In the GPS Metrics reports you can also select a range of hours in a day; see “Selecting Locality GPS Metrics Data” on page 174 for more information.

Selecting an ‘Area’ of Report Data

You can isolate the data you want to examine using a combination of the following:

Make choices in the selection pane on the left. Click and drag your mouse pointer over particular data in a report. In bar charts, click on portions of columns.

In the following procedure we will look at a report showing dropped connections, and then zero in on devices that are experiencing a greater than average number of disruptions.

To select an area of report data

1. In the Locality console, click Dropped Connections, and then select Trends.

2. (Optional) In the selection pane on the left, select a time frame (for example, a particular month).

3. The Distribution chart on the left plots the dropped connections of Locality devices.



In this example there are two devices that experiencing the highest number of dropped connections per hour.

4. To zero in on the values for a group of devices, select them by holding down the left mouse button and dragging the pointer. If you make an error, click the cancel icon:

5. To see the values for a single device, move your mouse pointer over it. The device details are shown in a small window:



6. The table on the right is also updated to reflect your selection and can be viewed as a straight or pivot table. (See “Pivot Tables” on page 135 and “Straight Tables” on page 136 for more information.)

To sort by a given column in a straight table, click the column heading. In this manner you can analyze your data and see if you can detect a pattern.

Bar Charts

Some Locality data is presented in the form of bar charts that give you a quick overview. You can use the selection pane to focus in on the data you are interested in; another way to isolate data is to click on a particular column or portion of a column.

The following example describes the Carriers report in the Network Usage category, but its features are common to other reports.

To compare data usage among different carriers

1. In the Locality console, click the Network Usage tab, and then open the Carriers report.

2. In this example, the month of June is selected, along with three carriers—AT&T, Sprint, and Verizon:



3. The resulting bar chart gives a quick, visual overview of how the data usage among the carriers for this particular time frame compares. Apparently the carriers AT&T and Sprint were not used nearly as much as Verizon during the selected time frame:

4. There are other ways to filter results that do not involve the selection pane. For example, to filter results for a single carrier, left-click on it:



5. The pivot table on the right shows you what percentage of the byte usage each carrier handled. Click the View icon to expand or collapse the rows in the table, or to maximize the table:

For more detail—a list of the accounts (phone numbers) associated with each carrier, and what the data usage looks like on a per-device or per-user basis—expand the data. See “Pivot Tables” on page 135 for more information about this kind of table.

6. The Time Trends chart gives you a chance to see the data on an hourly, daily, weekly, or monthly basis:

° If your data selection consists only of data collected within the last 30 days, the Time Trends selector provides options for Hourly, Daily, Weekly, and Monthly views.

° If your data selection includes data collected prior to the last 30 days, the Time Trends selector provides only Weekly and Monthly views.

Pivot Tables

There are two kinds of tables in Locality: expanding tables, described here, and non-expanding tables, described in “Straight Tables” on page 136. Pivot tables summarize data at multiple levels and show the subtotals (where applicable). You cannot sort by the columns in an expanded pivot table (as you can with a straight table), but on some of them you can export your results if you need to do additional data analysis.



In the following pivot table, the adapter usage information (Inventory > Population) can be exported:

To save a view of your data you have these options:

Click the Export icon in the top right of the table and save the data to a CSV, PDF, or XLSX file (a comma-delimited text file, an Adobe Portable document, or a Microsoft Windows Excel document). Some reports to not provide an Export option.

If this is a view that you plan to use again, add a bookmark; see “Bookmarking Views of Locality Data” on page 136 for more information.

Straight Tables

There are two kinds of tables in Locality: expanding tables, described in “Pivot Tables” on page 135, and non-expanding tables, described here.

In a straight table (like Network Performance > Technology Availability > Technology Usage in Deployment), you can sort by any column by single-clicking its heading. As with pivot tables, most results can be exported as a CSV, PDF, or XLSX document if you need to do further data analysis.

Bookmarking Views of Locality Data After you make map or report selections and the data you sought is displayed, use a personal bookmark to save your selection filters and re-use them. In addition, the saved selections apply to all reports within a category (for example, Dropped Connections or Inventory). Bookmarks are shared.

Creating and managing bookmarks is described in “Managing Locality Bookmarks” on page 136.

There are some additional options for saving your view:

A map can be exported and saved in a few different formats, which is useful for distributing and archiving results; see “Saving your Selections or Exporting a Coverage Map” on page 146 or “Saving your Selections or Exporting a Device Map” on page 154.

Reports can be exported in a variety of formats, which is useful if you want to further explore the data using another application.

Managing Locality Bookmarks

Bookmarks are a good way of filtering data in the same way over time. A bookmark for data usage by carrier, for example, could be set up to always show the last 30 days of usage for a particular carrier. Visiting this filtered page once per month enables you to compare similar data.



Click Bookmarks in the upper-right corner of the console. Existing bookmarks are listed by name and identified by the Locality console users who created them and the page to which they apply.

To create and save a bookmark

1. After you make your map or report selections and have arrived at a view into your data that you want to use again later, click Bookmarks in the top-right corner of the Locality console.

Note: In most Locality reports you can make a number of selections and then click Last 7 Days or Last 30 Days in the selection pane to compare current data against recent data. If you bookmark the report while these selections are active, and then open the bookmark two days later, the data in the report will be different. If you bookmark a report that is using a time frame in the past, the data remains static.

2. Enter a meaningful name for your bookmark; for example, Network usage by carrier - Q1 2013. Only alphanumeric characters, spaces, hyphens, and underscores are allowed.

3. (Optional) Add a note about the bookmarked and filtered data. For example, indicate which carriers are included in your filter.

4. Click Save.

To open a saved bookmark

1. Click Bookmarks in the top-right corner of the browser window.

2. Click the name of the bookmark you want to open. There are a few things to keep in mind:

° For bookmarked report selections, the bookmark you select applies to all reports within the same category. For example, if you made selections in Network Usage > Low Plan Usage and saved them to a bookmark, you can open that bookmark and then view reports in Network Usage > Last Used Plans: the same selections and filtering are applied.

° When you open a bookmark, any current selections you made in your map or report are overwritten. In other words, you cannot add the selections in a bookmark to any current data selections.


Chapter 7 - Analyzing Network Performance | 139

Chapter 7Analyzing Network Performance

The Network Performance category provides access to reports that display information about the actual performance of the network to which the Locality agents are connected. These reports enable you to identify whether performance problems are due to carrier infrastructure, network usage, or something else.

By default, the Locality database collects up to 180 days’ worth of data. For details about the granularity of data provided in maps and reports and how long a given level of detail is available see “Data Availability in Maps and Reports” on page 239.

Here is a quick overview of available Network Performance reports:

Network Performance Description

Coverage Map See the overall network coverage experienced by mobile devices, including signal quality and available network technology (3G or 4G, for example). Use this map to identify coverage gaps, understand where network performance is degraded, and find out which network carrier has more consistent coverage in a given area.

See “Analyzing the Carrier Network Using the Coverage Map” on page 140 for more information.

Device Map See detailed trace information for a device over the course of a day, showing signal quality, network technology, and dropped connections. This map is especially useful when troubleshooting connectivity problems.

See “Tracing Connectivity with the Device Map” on page 148 for more information.

Technology Availability See the percentage of data used by all mobile devices, broken down by technology generation (2G, 3G, and so on). You can identify, for example, when mobile workers are using high-bandwidth technologies, and when they are forced to use lower-speed connection technologies.

See “Analyzing Technology Availability” on page 155 for more information.

Technology Trends See trends in monthly, weekly, or daily data use broken down by carrier and network technology. The productivity of mobile workers is affected by the speed of their network connections: seeing the trends in data usage gives you visibility into how well the network is performing.

See “Understanding Technology Trends” on page 155 for more information.


140 | Chapter 7 - Analyzing Network Performance

Analyzing the Carrier Network Using the Coverage Map After you specify the time frame and geographic area you are interested in, the coverage map shows the aggregated information from multiple Locality agents. Choose from three types of information:

Carriers Signal quality by radio type Technology generation and associated network technologies

The coverage map describes the infrastructure of your network—what carriers are used, what the signal quality is like, and the technology that is available (3G versus 4G, for example). In contrast, the device map, described in “Tracing Connectivity with the Device Map” on page 148, focuses on the route of an individual device and its wireless experience.

Notes

Locality maps are best viewed at full-screen size; maximize the browser window. For details about the granularity of data provided in maps and reports and how long a given

level of detail is available, see “Data Availability in Maps and Reports” on page 239.

Selecting Locality Coverage Map Data

The coverage map lets you explore your carrier network—what carriers are used, what the signal quality is like, and which technology is used (3G versus 4G, for example, and what type). It displays aggregated data from all Locality agents that collected data during the selected time frame.

Note: By default, the Locality database collects up to 180 days’ worth of data. For details about the granularity of data provided in maps and reports and how long a given level of detail is available see “Data Availability in Maps and Reports” on page 239.

Adapters Get reports showing adapter manufacturers and models in terms of technology generation.

See “Analyzing Adapters” on page 156 for more information.

Compression - Mobility (Requires Mobility with the Analytics Module) Shows the percentage of data compressed by Mobility for each device in the time specified.

See “Analyzing the Effect of Compression on Network Performance” on page 158 for more information.

Network Performance Description



Every query begins in the selection pane on the left. Here is a quick overview, followed by more detail:



Specifying a Location in the Coverage Map

Focus on the geographic area you are interested in by entering the name of a location (a city, state/province, zip/postal code, or point of interest), and then pressing Enter. The map zooms in to accommodate the location entered.

The map displays the Locality data available for that area; narrow your search by entering a time frame. As you enter locations during a browser session, they are added to a drop-down list.

See “Changing the Map View” on page 127 for other ways to navigate a map (for example, by selecting an area.)

See “Specifying a Coverage Map Time Frame” on page 142 for more information about narrowing your search.

Specifying a Coverage Map Time Frame

By default, a coverage map can display as much as 180 days’ worth of data collected by your Locality agents. Use the Calendar portion of the selection pane to focus on a particular month, week, day, or all available data.

In the following example, the selected time frame is the month of May:

The Locality database is automatically purged throughout each day to ensure that it does not grow too large. This process deletes all records that are more than 180 days old.

See “Data Availability in Maps and Reports” on page 239 for more information.

Specifying a Coverage Map Display Option

You can look at a coverage map for your deployment in terms of three different aspects:

Carrier Signal quality



Technology type (4G, 3G, and so on); when Show technology detail is selected you can view the coverage map in terms of specific technologies (LTE, EDGE, HSPA, and so on)

Carrier

If you have multiple carriers, this option enables you to isolate one and display its coverage, or display them together and allow the colors to blend.

Signal Quality

Select this option to display the average, maximum, or minimum signal quality received in each grid cell on a per-carrier basis. When you are isolating a problem area, it is helpful to open a Details window about a particular grid cell in the map. Signal quality is determined by a NetMotion Wireless proprietary process that takes into account multiple variables such as field strength, signal-to-noise ratio, and network technology. For coverage, Locality calculates signal quality by adding the measured signal quality for each agent sample within a map grid cell, and then displaying the average of those samples.

Network Technology

On a per-carrier basis, you can display your technology generation coverage (for example, 2G versus 3G). To further differentiate the technology, select Show technology detail.



Examining a Single Grid Cell in a Coverage Map

To better understand network performance in an area of the coverage map, look at a single, colored cell. There are two ways to do this, described in more detail in “Coverage Map Grid Cell Details” on page 144:

Place your mouse pointer on a cell—details are shown in the selection pane Left-click on a cell—a Details window opens in the map area that remains open until you close it

Remember that the actual size of the area indicated by a colored grid cell changes as you zoom in and out. A zoom level of 14 and above represents a square of 340 x 340 feet on the ground.

For each carrier (regardless of whether you are displaying carrier coverage, signal quality, or technology generation), the following detail is displayed:

Coverage Map Grid Cell Details

To better understand network performance in the coverage map, look at the details for a single cell. There are a couple of things to note:

The square area indicated by a colored grid cell changes as you zoom in and out. Any grid cell details you have displayed are removed if you change the zoom level for the map

or reposition the map. When Carrier is selected in the Display drop-down list, all applicable data is displayed; when

Signal quality or Technology type is selected, data is filtered by the selected carrier.

Coverage Map Detail Description and Examples

Carrier Examples: AT&T, Sprint, Verizon

Technology Generation Examples: 3G, 3.5G, 4G

Signal quality Indicates the type of signal quality reported by devices in this cell.

Examples:

Average: Excellent Minimum: Fair Maximum: Excellent

Number of samples This is a count of the samples that contributed to the data shown in the coverage map. One or more devices may have contributed samples. For example, if a grid cell indicates 12 samples there are several possible scenarios:

A single device contributed all 12 samples More than one device contributed to the number of samples. For

example, one device contributed 8 samples and another contributed 4 samples.

Twelve different devices were in the cell long enough to each submit a single sample (this is a less likely, but technically feasible, scenario).



To see coverage details in the selection pane on the left, just point to a cell. Grid cell details are displayed in the selection pane:

To show coverage details in a window that is tethered to a particular grid cell, left-click the cell. You can have multiple Details windows open; they will remain tethered as you move them around the map.

To keep the coverage details for a cell on display in the selection pane, right-click the cell. You will see a red push pin; to remove it, right-click it again.

See “Examining a Single Grid Cell in a Coverage Map” on page 144 for more information.

Coverage Map Grid Cell with Overlapping Information

In coverage maps, especially in cities or areas where multiple mobile workers are covering the same routes, information is often overlapped. In Locality, this is a literal overlap (and mixing) of different colors. While the mixing is informative—it’s a quick indication of where overlap occurs—it can also make the map hard to read. This section describes how to work with cells with mixed colors.



In this simple example showing carriers, one grid cell shows coverage detail about two different carriers, AT&T (blue) and Sprint (yellow). To find out what carriers are represented in a grid cell, left-click your mouse pointer on the cell:

Saving your Selections or Exporting a Coverage Map

If the selections you have made in a map are ones that you might re-use, you can save them in a bookmark. Bookmarks are described in “Bookmarking Views of Locality Data” on page 136.

Your coverage map display can also be exported and saved in these formats:

PNG format KML document

There are several applications for displaying KML, including Google Earth, Google Maps, AutoCAD, and ESRI ArcGIS Explorer. The KML document does not show the same map detail that the Locality console shows; it captures just the kind of coverage that you specify (Carrier, Signal quality, and Technology type).

You should have a strategy for exporting maps if you need to archive older results; see “Data Availability in Maps and Reports” on page 239 for more information.

Creating a Coverage Map

When you first open a coverage map in the Locality console, the map is centered on all available data for the last 180 days. If data is collected from Locality agents that are all in the NE of the United States, for example, the map will center itself on that area before you make any changes in the selection pane.



To create a coverage map

1. In the Locality console, click Network Performance.

2. Open the Coverage Map, enter an address or zip code at the top of the selection pane on the left, and then press Enter. You can also pan to a different map area, or zoom; see “Changing the Map View” on page 127 for more information.

Any data filtering that you do in the selection pane is immediately reflected in the data displayed in the map.

3. In the Calendar area, the current month is displayed. To select a different month, click it (only months in blue contain data and can be selected).

For more information about selecting a span of time to include in your map, see “Selecting Locality Coverage Map Data” on page 140.

4. Look at your results and decide whether you want to change the display options; see “Selecting Locality Coverage Map Data” on page 140 for more information.

In this example, Display is set to Carrier, and only AT&T and Sprint are selected:

5. For a quick look at coverage detail for a given (colored) cell in the map, point at it with the mouse. In the map above, the mouse pointer (circled) is resting on a cell with coverage from the carrier Verizon, and the grid cell details are shown on the left.

6. To see details and leave them displayed, left-click on a cell. In the example above, there are two Details windows, one for each of two cells.

7. If a Details window is obscuring your view you can either move it out of the way (the pointer stays anchored to the cell you selected), or close it. For more information on interpreting the information offered in the Details window, see “Examining a Single Grid Cell in a Coverage Map” on page 144.



Tracing Connectivity with the Device Map The device map focuses on the route of a device and its connectivity experience over the course of a day. In contrast, the coverage map, described in “Analyzing the Carrier Network Using the Coverage Map” on page 140, shows the infrastructure of your wireless network—what carriers are used, what the signal quality is like, what technology is used (3G versus 4G, for example), and so on.

The device map is especially useful when you are troubleshooting connectivity problems on a specific mobile device. You can trace the conditions where dropped connections occurred and compare the device to other devices in the same area: is the problem related to specific devices, drivers, antenna systems, or network congestion? If devices are further afield than you expected, do you need to work with your carrier and change your coverage?

Notes

Locality maps are best viewed at full-screen size; maximize the browser window. A device trace route on a Locality device map is only as good as the location information

provided by the active GPS receiver. See “Data Display Anomalies in Device Maps” on page 249 for more information.

The Locality database is automatically purged throughout the day to ensure that it does not get too big. For a table showing the granularity of data provided in maps (and reports) and how long the data is available, see “Data Availability in Maps and Reports” on page 239. Some tips on managing historical data are also included.

If you have a device in your deployment that is shown in reports but cannot be displayed in a map, see “Locality Agent Not Reporting Location (Windows)” on page 252 for troubleshooting information.

Selecting Locality Device Map Data

The device map enables you to explore the connectivity experience of a user running Locality over the course of one day. After you select a device and a day, you can then use time or location (or both) to narrow your focus: pinpoint a time during the day you chose using the selection pane, or click on a point in the trace displayed in the device map—the time in the selection pane shifts to the point you chose.

Note: The Locality database collects up to 180 days of device map data. For details about the granularity of data provided in maps and reports and how long a given level of detail is available see “Data Availability in Maps and Reports” on page 239.



Every search query begins in the selection pane on the left. Here is a quick overview, followed by more detail:



Selecting a Device, User, or Phone Number to Trace

The device map traces the route and connectivity experience of a single user or device running the Locality agent over the course of a day. Search for a certain device, user, or phone number. As you make selections during a browser session, they are added to the Recent drop-down list.

A substring can be used for searching:

win—Returns all records that contain win.

If you select a user who has multiple adapters in his or her device, the adapters are listed in a separate drop-down list so that you can be specific about which one you are interested in. See “Monitoring Multiple Adapters on the Same Agent Device” on page 119 for more information.

Next steps

Select a day—see “Specifying a Device Map Time Frame” on page 150. Pinpoint a time, or select a location on the map—see “Selecting a Time or Location in a Device

Map” on page 151. Focus on signal quality or technology generation (3G or 2G, for example, and what network

technology)—see “Specifying Device Map Display Options” on page 153.

Specifying a Device Map Time Frame

The device map traces the route and connectivity experience of a single user or device running the Locality agent over the course of a day. After you select a subject for the trace (as described in “Selecting a Device, User, or Phone Number to Trace” on page 150), the calendar items (years, months, and days) that contain data relating to the device or user you selected are highlighted in light green.

Choose a month and then a day. In this example, May 15, 2014, is selected.



Next steps

Pinpoint a time, or select a location on the map—see “Selecting a Time or Location in a Device Map” on page 151.

Focus on signal quality or technology generation (3G or 2G, for example, and what network technology)—see “Specifying Device Map Display Options” on page 153.

Selecting a Time or Location in a Device Map

There are essentially two ways to narrow your focus in a device map: by time of day or geography.

Pinpoint a Time of Day

After you select a device, user, or phone number (as described in “Selecting a Device, User, or Phone Number to Trace” on page 150) and a date (as described in “Specifying a Device Map Time Frame” on page 150), you can narrow your focus to a certain time of day.

Below the calendar, the top line represents one day; the span of time during the day that contains Locality data is highlighted in dark blue. The beginning and end points (the green and red markers) automatically bracket the first and last available data for that day.

To move to a certain time in the device map trace, you have several choices:

Left click and drag the large ribbon of hours until the blue bar in the middle is pointing to the time you are interested in (green areas contain data, and gray ones do not; red indicates that the device was disconnected).

Left click and drag the circle in the playback line until you reach the point you are interested in. Play the trace back until you reach the time you want.

Pinpoint a Location

To zero in on a point in your trace in terms of location (rather than time), just click a point in the trace with the left mouse button. A small icon appears that shows both signal quality (on the left) and network technology, regardless of what you selected as your display option. You can now either observe the progress of the device (in the selection pane, play back its movements), or drag the icon to the location in the trace you are interested in.



In this example, the device was experiencing a fair signal quality using EV-DO Rev. A (3G)—the blue in the legend is used in the icon that pinpoints the position of the device in the map.

Sometimes you have to zoom in on a map to tease out the details of a trace. In the example above, the Display is set to Technology type. The trace looks green—which the legend indicates is a network technology of 2G—but the icon marking the current position of the device is orange (3G).

To find out more, zoom in on the device map icon. In this example you see that there were in fact two different network technologies used by the same device at different times of the day. To show trace details in a window that is tethered to a particular point, left-click the trace route. You can have multiple windows open; they will remain tethered as you move them around the map.

For more information about these pop-up windows, see “Device Map Trace Details” on page 154.

Next step:



Focus on signal quality or technology generation (3G or 4G, for example, and what network technology)—see “Specifying Device Map Display Options” on page 153.

Specifying Device Map Display Options

The device map, which traces the route of one device in the course of a given day, can be viewed in terms of signal quality or network technology. No matter how the route is displayed, the icon pinpointing the location of the device on the map indicates both signal quality at that point, and what technology was in use.

A dashed line on a device map indicates that the device was disconnected. If your map is getting too cluttered, or you are not interested in these disconnected periods, clear the Disconnected section check box.

Signal Quality Legend

Signal quality is determined by a NetMotion Wireless proprietary process that takes into account multiple variables such as field strength, signal-to-noise ratio, and technology type, mapping them on a relative scale from 0 to 100. The higher the number, the better the signal.

On Android devices, the screen must be on for the Locality agent to collect signal quality data. If the screen is off, the device map trace shows signal quality as Unknown. The Locality agent for Android provides a Battery life vs data setting that determines to what extent Locality keeps the device screen on. For details see “Conserving Battery Life (Android)” on page 258.

For non-Android devices, a signal quality of Unknown indicates that the adapter for a particular Locality agent is working but has failed to report a signal quality value. This suggests there may be a problem with the adapter or the connection manager and that further troubleshooting is necessary.

Network Technology Type Legend

The legend changes, based on what network technologies are included in the device map you are creating.



Device Map Trace Details

To see complete details about a point in a trace route, left-click it on the map. From this point you can drag the icon along the route in either direction, or press the play button and watch it move. To show trace details in a window that is tethered to a particular point, left-click the device icon. You can have multiple windows open; they will remain tethered as you move them around the map.

When viewing device map trace details, the presence of Current carrier means that the cellular adapter indicated it was on an extended or partner network. If the Current carrier is listed as Unknown Carrier, Locality is unable to determine which carrier is carrying the session. Some cellular adapters do not return this information.

Saving your Selections or Exporting a Device Map

If the selections you have made in a map are ones that you might re-use, you can save them in a bookmark. Bookmarks are described in “Bookmarking Views of Locality Data” on page 136.

Your device map can also be exported and saved in these formats:

PNG format—The image opens in a new browser window in PNG (Portable Network Graphics) format. To save the file, right-click on the image and do the following, depending on your browser:

° Internet Explorer—Select Save Picture As; in the Save Picture dialog you can specify PNG or BMP format.

° Firefox—Select Save Image As; in the Save Image dialog save the image in PNG format. KML document—When you select KML (Keyhole Markup Language) format, you are prompted

to save the file to disk. There are several applications for displaying KML, including Google Earth, Google Maps, AutoCAD, and ESRI ArcGIS Explorer. The KML document does not show the same map detail that the Locality console shows; it captures a trace route that displays either Signal quality or Technology type.

Creating a Device Map

A device map traces the route of a device in the course of a day, and can be viewed in terms of signal quality or network technology.

To create a device map

1. In the Locality console, click Network Performance.

2. Open the Device Map, enter any portion of a device name, user name, or phone number, and then press Enter.



3. Make a selection from the resulting list.

4. Select the date you are interested in; the months in the drop-down list and the dates in black (not dimmed) contain data.

Note: Locality retains reported device GPS location information for 6 months, after which it is purged. You cannot see a device trace that is older than 6 months.

5. Notice that the starting point for the device or user you chose is an icon. This icon displays the following information, which changes in the course of the trace:

° Signal quality on the left° Network technology on the right

You can display the mapped route in terms of either one by making a choice in the Display list, but the location icon for the device you are tracing always shows both.

6. You can narrow your focus in a device map by selecting a time of day or clicking on a point in the route of the device. See “Selecting a Time or Location in a Device Map” on page 151 for more information.

Analyzing Technology Availability Carrier adapters often include receivers for different network technologies. For example, many support both 3G (HSDPA/UMTS) and 2G (EDGE): if the adapter picks up a 3G signal, it will default to using it; if the signal is unavailable or too weak, it will switch to 2G automatically.

The Technology Availability report enables you to see which devices are using various network technologies and to what extent. You can identify, for example, when mobile workers are using high-bandwidth technologies, and when they are forced to use lower-speed connection technologies.

Let’s say you have a mobile worker with an adapter that can use either 3G or 2G signals; the normal usage distribution for this person in the past few months has been roughly 90 percent 3G and 10 percent 2G. But you see a spike in 2G use during a particular month. Here is an approach to analyzing the usage:

Is this a coverage problem, or maybe a problem with the adapter? A useful next step in understanding the data is to open a device map, search for this particular user, and enter a time frame that includes the 2G spike you saw. This will tell you where the spike occurred.

See “Tracing Connectivity with the Device Map” on page 148 for information about tracing an individual device.

Compare the device to others in the same time frame on the Technology Availability report: are the other devices also using 2G instead of 3G? In that case, it may be a matter of coverage.

If the spike is experienced by just one user, then perhaps the adapter is misconfigured or faulty. Use reports in the Inventory category, described in “Keeping Track of Network Adapter Inventory” on page 189, to determine the extent to which a particular adapter manufacturer, model or firmware revision is associated with slow speed connections.

Understanding Technology Trends This report enables you to see data trends by technology generation (for example, 4G, 3G, and 2G) and by network technology (1xRTT, EDGE, and so on). Observing these technology trends lets you gauge how well the network is performing, and the extent to which slow connections are affecting productivity. For example, are your devices using the network technology you expect? If not, is this something to discuss with your carrier, or do you need to invest in new adapters?

Getting there: Network Performance > Technology Trends

Note: To view daily, weekly, or monthly time trends, your Calendar selection must specify at least two days, or two weeks, or two months:

A daily time trends view requires selection of two or more days A weekly time trend view requires selection of two or more weeks A monthly trend view requires selection of two or more months.



In this simple example, 4G usage for AT&T in May and June is displayed:

Move the slider bar at the top to set the granularity you want to display. The chart shows two sharp increases, several weeks apart. To see the amount of data usage at a given point, position your mouse pointer. For example:

Analyzing Adapters Use the Adapters report in the Network Performance category to display adapter manufacturers and models in terms of technology generation. One of the things this report is useful for is identifying the extent to which a particular adapter is associated with slower technologies, and for discovering which manufacturer models are using the slower technology generation.

Technology Availability (in the same category) is a similar report, except that the data is presented in terms of users, phone numbers, and so on.



In the following example, the manufacturer HTC is selected. The chart’s color key shows that a range of technology generations is in use by this manufacturer during the selected time frame.

Sometimes the mekko chart cannot show a usage percentage because it is too small to display. To view percentages for all the technology generations listed in the color key (even those too small to display in a chart), click the Export icon in the top right corner of the chart, and then select Text Document (CSV). Now you see the exact percentages for all of the technology generations:

To find out what adapter models are associated with this manufacturer within the selected time frame, look at the table and pie charts in the bottom half of the screen. The HTC One model uses 4G most of the time, but the other model (HTC6500LVW) is using it roughly half of the time. You might want to do a bit of research: can the difference be attributed to geography? Another possibility is that this was an anomaly for this particular time frame; select a different period and see if the results are still similar.



Analyzing the Effect of Compression on Network Performance If you have the Mobility Analytics Module installed at your site, Locality can use its data to provide additional information for understanding how applications and devices are using resources on your mobile wireless network. Data compression is likely to provide the greatest improvement in throughput over low bandwidth connections or on a congested network. It may not make a significant difference on a higher bandwidth network.

The Compression - Mobility report lets you see how much you are saving, in terms of gigabytes transferred, when your devices are running the Mobility client in addition to the Locality agent. A bar graph displays what percentage of the total amount of data for a device was compressed by Mobility within the time frame specified.

If you do not see the savings or information that you expect, be aware of the following:

When the client setting Compression - On/Off is set to Auto in your Mobility deployment, the speed of the connection is detected, enabling compression when the connection is slow and disabling it when it is fast. This lets the Mobility client optimize throughput as it moves, for example, between a relatively slow WWAN connection and a faster WLAN connection.

There is another Mobility setting that is available when compression is set to Auto: Compression - Interface Speed. This setting determines the maximum connection speed at which data compression will be enabled. For example, if you configure Mobility E to auto compress when an interface is slower than 9600 Kbps, an interface that is faster than that will not show any compression savings in this Locality report.

Some adapters report an interface speed that is incorrect, indicating a faster-than-actual connection. This can sometimes cause Mobility to disable compression.

File type can affect compression. A text file, for example, usually compresses by a factor of two to three, while images in JPG format do not.

In the User bar chart, users are included on a per-domain basis. For example, a user who was logged on to two different domains within the specified time frame is listed twice in this report.

Locality reports only represent compression for data transferred over a WWAN interface, while Mobility reports include additional compression information for data transferred by means of WiFi, wired communication, or any communication on adapters that are not handled by Locality.

To find out what applications this user was running in this time period, select the same user and time frame in the Network Usage > Applications - Mobility report; see “Analyzing Network Usage by Applications” on page 169 for more information.



There is another report available when the Locality server is configured to use data from your Mobility reporting database:

Report Description

Network Usage > Applications - Mobility Analyze end-user application usage patterns. Shows the amount of network traffic (in megabytes) generated by an application.

See “Analyzing Network Usage by Applications” on page 169 for more information.


Chapter 8 - Analyzing Network Usage | 161

Chapter 8Analyzing Network Usage

The Locality system gives you information you can act on regarding how your carrier data networks are used and how much data is being used by users or devices. The historical data helps you map trends and make projections so that you can evaluate and optimize your carrier plans and data usage.

By default, the Locality database collects up to 180 days’ worth of data. For details about the granularity of data provided in maps and reports and how long a given level of detail is available see “Data Availability in Maps and Reports” on page 239.

Getting there: Locality Console >Network Usage.

Here’s a quick overview of available reports:

Network Usage Description

Carriers See how carrier plans are used and what changes in usage have occurred so that you can evaluate whether you need to reallocate your carrier plan usage. Use this report to evaluate usage of each carrier by user, by device, by phone number.

See “Analyzing Network Usage by Carrier” on page 162 for more information.

Users Identify data use patterns by any combination of phone number, user, device, and carrier.

See “Analyzing Network Usage by User” on page 164 for more information.

Low Plan Usage Identify which devices are consistently underused so that you can adjust the associated data plan by grouping it with other light users.

See “Analyzing Low Plan Usage” on page 166 for more information.

Last Used Plans Identify data plans in your mobile deployment that are not being used: they may be candidates for plan termination or redeployment.

See “Identifying when a Plan Was Last Used” on page 168 for more information.

Applications - Mobility (Requires Mobility with the Analytics Module) See what applications mobile workers are using and which ones are consuming the most data on your mobile broadband networks. This enables you to determine whether the application usage is appropriate and whether mobile workers need to change how they are using the data plan.

See “Analyzing Network Usage by Applications” on page 169 for more information.


162 | Chapter 8 - Analyzing Network Usage

Key Features of the Network Usage Reports Use the Network Usage reports to review and analyze overall data usage by carrier, user and application, and identify unused/under-used data plans to reveal opportunities for cost savings. Managers with mobile deployment cost responsibilities will use this information to minimize data plan costs. Network Usage reports show the amount of data actually handled by the adapter being monitored by the Locality agent. Locality does not collect or report data sent and received on other adapters; if a device has a WLAN adapter, for example, the amount of data it sends or receives is not included in these reports.

Report navigation and filtering tools allow rapid focus on critical information, so you can eliminate the extraneous data and quickly focus your attention on just the information you need:

Time frames that contain mobile worker data are visible at a glance. Filters can quickly be set to focus on data of interest:

° Time frame° Carrier° Application (requires Mobility Analytics Module)° Phone number° User° Device

Filters are shared between individual Network Usage reports to shorten the time it takes to accomplish network performance troubleshooting and analysis.

Reported Data Usage: Locality Versus Your Carrier Bill

If you compare data usage amounts on your carrier bill to usage amounts shown in Locality, you may see discrepancies. This is because Locality and your carrier do not measure data usage the same way. Why the difference?

Network usage reports in Locality show the amount of data actually handled by the network adapter used by a Locality agent device—the amount of mobile data traffic sent and received by a specific carrier network adapter.

Carriers charge for data measured in their core network, including any mobile gateways.

Discrepancies are likely to occur during poor wireless network conditions. If data is sent from an adapter on the Locality agent device, but gets lost before the carrier receives it, the carrier will not count it. On the other hand, data sent to the adapter (coming from the Internet) will be counted by the carrier as it passes through the gateway, but if it gets lost before the adapter receives it, it will not be reflected in Locality reports.

Analyzing Network Usage by Carrier Visibility into carrier data usage totals and trends provides fact-based information when choosing carriers or evaluating the potential impact of switching carriers. Use this report to review all carrier network data usage and trends for each active carrier in your mobile deployment.

Getting there: Locality Console, click Network Usage > Carriers.

The Carriers report shows you the amount of data the Locality agents try to send and receive while on a given carrier network. Which carrier plans (phone numbers) are transferring high data volumes? What are the daily peak hours for data usage? Are there any unexpected trends in usage over time?



If you use multiple carriers, it’s important to know how usage is distributed. In this example, the mobile workforce is working with three carriers:

Suppose you expected carrier usage to be distributed more evenly, but instead you see that the majority of bytes of data are sent and received through AT&T. This raises questions: Which plans (phone numbers) are transferring the most amounts of data? Are certain devices attempting to transfer more data than expected? What users are associated with high data usage and what phone numbers and devices are they using?

To understand what contributes to this unexpectedly high data volume, look at the Total Bytes - Detail table on the right in the Carriers report. This pivot table reveals how each carrier network is being used, showing which plans transferred the highest and lowest data volumes, and identifying the mobile devices and mobile workers associated with those accounts. To focus on the high AT&T usage, expand the AT&T row. (See “Pivot Tables” on page 135 for more information about this type of table.)

To gather additional information about the AT&T plan with the highest data usage, click on the phone number, device, or user associated with the plan. The active selections on the Carrier report automatically filter the data in the other Network Usage reports. For example, if you select the name of the user with the highest plan usage and then open the Applications - Mobility report (which requires Mobility with the Analytics Module), the report data will show you which of that user’s applications generated the highest data usage and when those applications were most heavily used.

Other uses for the Carriers report:

Are you working with a carrier that is not used very much? Does it make sense to continue using this carrier? Which plans (phone numbers) use the carrier most? Of those phone numbers, which devices and users transfer the most data? Could these devices and users be switched to one of your other carriers? The Network Usage and Network Performance reports will help you answer these questions.

Do you see an unexpected carrier in the list? Check the Total Bytes - Detail pivot table to determine which devices in your mobile deployment are configured to use a carrier you want to drop.

Examining Trends in Network Usage by Carrier

You can use the Trends charts in the Carriers report to analyze the volume of data handled by your carriers over time.



The month, week, day, and hour trend charts enable you to focus on specific data usage characteristics, such as peak data usage times, and makes it easy to compare data load amongst your carriers.



Key benefits of the Carriers Report

With the Carriers report you can track total data usage trends to inform carrier and data plan choices.

A Technical Manager can take the following actions based on this information:

Reduce the time and improve the accuracy of network capacity forecasts and plans. Eliminate underused carrier plans.

A Business Manager can take the following actions based on this information:

Minimize costs by making fact-based data plan decisions.

Analyzing Network Usage by User Use this report to see the data usage statistics for all of your mobile workers so that you can determine how they use available data plan resources.

The report shows you usage counts (in GB) for users and associated devices and carrier plans (phone numbers). You can identify data use patterns and view trends based on a monthly, weekly and daily basis. Armed with this information, you can make better data plan decisions, and set more effective policies governing mobile equipment and data plan usage.

Getting there: Locality Console > Network Usage > Users.

The Users report enables you to:

Identify the heaviest data users. Understand data usage patterns and trends. Detect unexpected changes in data usage by tracking usage over time.

The Total Bytes pivot table shows at a glance which users are generating the most network traffic.

In the following example, with all selections cleared in the data selection pane, the total data usage of one account (phone number 2065551213) stands out from the rest.

Has the top user always consumed more network resources than others? Let’s find out.

To compare mobile worker data usage over time

1. In the data selection pane, click Reset All.



2. In the search box, enter the name of the user who appears to be using more network resources than others.

3. To see network usage for the first half of 2014, click JAN and then Ctrl-left-click on February through June.

4. To see what resources (devices, phone numbers, and carriers) [email protected] has used to move data, expand the Total Bytes - Details table by clicking the Expand icon: .This gives you a summary of the usage over the months you selected in the calendar:

5. To see how the usage is spread out over the months you selected, slide the bar in the Time Trends chart to Monthly. It’s clear that June 2014 saw much higher than average usage.

About Map Data

In the Total Bytes - Details pivot table, the Map Data column indicates whether the database contains GPS location information that will allow you to see a device trace in the Device Map. A No in the Map Data column can be caused by any these conditions:

The GPS location data was collected more than 6 months ago. Locality retains reported device GPS location information for 6 months, after which it is purged. You cannot see a device trace that is older than 6 months.

The GPS receiver on the device did not provide any location data. See “Locality Agent Not Reporting Location (Windows)” on page 252 for troubleshooting information.

There is no GPS receiver on the device.



For more information about creating a Device Map, see “Selecting Locality Device Map Data” on page 148.

Understanding a User’s Network Usage Trends

The Users report’s Trends charts presents monthly, weekly, and daily trends for a user’s data traffic broken down by network carrier.

Suppose you are looking at the Network Usage > Carrier report and the Total Bytes bar chart shows that Sprint is handling twice the data volume you expected. You want to know which workers are using Sprint plans and who the heaviest data users are.

To analyze how a user is generating the most data usage on a carrier plan

1. Open the Users report and select the carrier of interest in the data selection pane. For this example, select Sprint.

2. The Total Bytes pivot table shows all Sprint users, sorted from highest to lowest data usage. Click the name of the user with the highest usage and then select the Daily - Trends chart.

3. Is this worker complying with appropriate data usage policies?

Do you see spikes in data transfer? Are there certain days of the week (for example, weekends) that show higher than average data usage?

4. To see if there are particular times of day when this worker’s data usage spikes, open the Carrier report and select the Hourly - Trends (Past 30 Days) chart.

Use the Daily and Hourly trends reports to find out when high data traffic occurs. Is there a pattern? Is data traffic occurring during non-work hours?

If you have the Mobility Analytics Module installed at your site and Locality is configured to use its data, you can use the Network Usage > Applications - Mobility report to see which applications are generating the most traffic. See “Analyzing Network Usage by Applications” on page 169.

Key Benefits of the Users Report

The Users report enables you to:

Quickly identify the heaviest data users. Understand data usage patterns and trends. Identify unexpected changes in data usage due to changes in user or application behavior.


Identify the heaviest data users for further investigation.


Establish appropriate application and asset usage policies. Select appropriate data plans.

Analyzing Low Plan Usage Locality can show you whether data plans are underused, so that you identify any service that you should cancel or redeploy to other mobile workers, or identify plans that would be better pooled together. This enables you to make better use of existing assets.

Device names and user names are shown to facilitate communication with the user to determine whether the data plan should be canceled, and corresponding phone numbers and carrier information makes finding and canceling the plan as easy as possible.



Time Trends

The Trends report outlines the usage trends for your users (so you can evaluate existing carrier plans) and for the carriers you use (to see which carriers are used the most).



In this example a user who transferred a small number of bytes is selected (based on the numbers in the Total Bytes - Details report).

At the top of the Time Trends chart, slide the bar to Weekly. The usage in this example is pretty steady until the fourth and fifth weeks, where Verizon use stops completely.



Leaving this same user selected, check the Time Trends chart in the Last Used Plans report: with the slider set to Daily, you can pinpoint when this person last used Verizon as a carrier. (Use drops off steeply on April 20.) Some possible explanations are that this user is on vacation, or the adapter that he was using has been mislaid.

Key Benefits of the Low Plan Usage Report

Use the Low Plan Usage report to:

Identify data plans with the lowest data usage to save money by plan pooling, cancelation or redeployment.

Track data usage by phone number to identify the account on the bill. See data usage trends to avoid canceling data plans that are still needed.


Identify underused accounts and take the following actions to save money:

° Re-distribute equipment ° Pool underused data plans° Cancel or select optimal data plans


Same as Technical Manager. Identify under-used assets and under-performing workers.

Identifying when a Plan Was Last Used The Last Used Plans report identifies data plans within your mobile deployment that may be candidates for plan termination or redeployment to save costs.

The Last Used column identifies when the plan was last used. A “-” in the Last Used column indicates that the adapter is detected, but it has never been used.

Device names and user names are shown to facilitate communication about whether the data plan should be canceled or is still needed, and corresponding phone numbers and carrier information make finding and canceling or reassigning the data plan as easy as possible.

Key Benefits of Last Used Plans Report

Use the Last Used Plans report to:

Identify data plans that have been dormant the longest to save money by pooling, cancelation or redeployment.

Track plans by phone number to identify the account on the bill.


Identify dormant accounts and take the following actions to save money:

° Re-distribute equipment



° Pool unused data plans° Cancel or select optimal data plans


Same as Technical Manager. Identify unused assets and under-performing workers.

Analyzing Network Usage by Applications If you have the Mobility Analytics Module installed at your site, Locality can use its data to provide information to help you understand how applications and devices are using resources on your mobile wireless network. The Mobility Analytics Module is part of Mobility from NetMotion Wireless.

Use the Applications - Mobility report to review and analyze overall data usage for applications used by the mobile workers in your deployment. This report is particularly useful for identifying significant data usage by applications that are not business-related: unauthorized or rogue applications can be identified for possible removal from affected devices.

There is another report available when the Locality server is configured to use data from your Mobility reporting database:

Key benefits of Application Usage Reports

Use the Applications - Mobility report to:

Identify unexpected, unauthorized, or possibly malicious applications, viruses, or worms. Identify applications with the highest data usage. Understand trends in application usage over time. Inform where application usage impacts network performance.


Investigate application usage spikes to identify potential threats or misuse. Remediate or remove malicious applications, viruses, or worms. Using Mobility policy, restrict unauthorized applications to improve network performance and

productivity.


Reduce data plan costs by restricting unauthorized application usage. Monitor non-business related applications. Set appropriate application usage policies.

Mobility Application Bytes Chart

The Mobility Application Bytes chart gives is a visual representation of how much network traffic each application has used over the monitored adapter. System and user applications can be displayed together or separately in order to facilitate troubleshooting.

In this example, only user application usage is displayed.

Report Description

Network Performance > Compression - Mobility

Shows the percentage of data compressed by Mobility for each device in the time specified. Gives you an understanding of the impact of compression over time.

See “Analyzing the Effect of Compression on Network Performance” on page 158 for more information.



In the left navigation bar, select User:

The Mobility Application Bytes chart is updated:

As you make selections in the list of applications, the pivot table on the right is updated. In addition to the gigabytes used, it shows all of the account information (user name, device, phone number).

Analyzing Applications - Mobility Reports: Example

Typically the Applications - Mobility report is used to find the applications responsible for an unexpectedly high amount of traffic, or for traffic that should not be on the mobile network. But you can also use it to find applications that are underused.

In this example, a single month is selected. Comparing the usage totals for two mobile workers with similar duties—insurance adjusters who are working in the field—you notice that the applications run by User2 have a much lower usage total (5.12 GB):



Click User2 in the pivot table to isolate the applications he or she is running. The usage for Microsoft Outlook in the bar chart on the left is about average, but the custom application necessary for insurance work in the field (adjustment_input.exe) is much lower than expected:

For a typical user in your deployment, you know that the two applications should be about equal in terms of gigabytes transferred. Here are some possible explanations:

There is an issue with the application: User2 did not install it correctly, or is unaware that it stopped working.

The mobile device (Device2) has been lost or stolen: the custom application timed out after a certain amount of inactivity, but Outlook continues to run.

To do a bit more analysis, you could change the time frame. Looking at the Trends charts: do other months show the same under use when compared against the usage of mobile workers doing the same work, or is this new?

Another approach would be to open a Device Map, select the same time frame, and enter the device or user name. Assuming that the device has been transmitting location (map) data, you can create a Device Map by specifying the device name and a time frame in the selection pane. The lower usage may be due to insufficient signal strength. See “Tracing Connectivity with the Device Map” on page 148 for more information about device maps.

Before you move to another report category you might want to bookmark your current selections so that you can return to them; see “Managing Locality Bookmarks” on page 136 for more information.

Note: In the User column, Logged off indicates that no user was logged on when the data was transferred; it can also mean that the user selected Switch user in the Start menu of the Windows operating system.

Mobility Application Bytes by User Chart

The Mobility Application Bytes by User table shows you which users are responsible for the most network traffic. To expand the table columns to see additional account information (user name, device, phone number), right-click on a user name and select Expand all.

See “Analyzing Applications - Mobility Reports: Example” on page 170 for an example of how to use the chart and pivot table.

Note: Users are included in the report on a per-domain basis. For example, a user who was logged on to two different domains within the specified time frame is listed twice in this chart.



Understanding Application Data Usage Trends

See monthly, weekly, daily, and hourly trends for a user’s application data traffic broken down by application.



Monitor how mobile workers are using applications on their mobile equipment and the company-paid data plan, and set appropriate usage policies.

Task: Are your users using the applications you expected? Do you see applications in the list that should not be in use on your deployed mobile equipment? Do usage trends show spikes in data transfer, higher usage on one shift versus another, or high data transfer rates for specific users? Use the daily and hourly trends reports to find out when high data traffic occurs. Is there a pattern? Is data traffic occurring during non-work hours? Are their rogue applications generating high data traffic that should be removed from a mobile device.

Understanding Usage Totals for Mobility and Locality The Network Usage reports display the data that is transferred by a mobile device through its adapter. You might expect the data usage numbers to be exactly the same for reports in this category, but they are usually a bit different, as in this example:

There are a few things that contribute to a discrepancy between these numbers. For example:

It is possible for a device running both the Mobility client and the Locality agent to have multiple network interfaces active at the same time. On a device with multiple interfaces, Mobility chooses the fastest and least expensive one (for example, Ethernet is chosen over WiFi, and WiFi is chosen over WWAN). In Mobility, only applications that send data through the mobile VPN tunnel are recorded; any packets that bypass Mobility are counted by Locality but not by Mobility.

If the Locality service is stopped and later restarted, data that is transferred during the time the service is stopped is not recorded by Locality.

Locality reports only represent data transferred over a WWAN interface, while Mobility reports include additional information for data transferred by means of WiFi, wired communication, or any communication on adapters that are not handled by Locality.


Chapter 9 - Analyzing GPS Usage | 173

Chapter 9Analyzing GPS Usage

Locality gives you information you can act on regarding how GPS performs on your workers’ mobile devices. The timeline presentation of data helps you discover trends and make projections so that you can evaluate GPS issues.

Location information is important to a mobile deployment, and managers want to be aware when the following may occur:

Little or no GPS data is reported A GPS device reports location data, but only intermittently

The GPS Metrics category includes reports that help you to determine what caused a lack of GPS data for a user. Is it a device issue, a GPS modem issue, a matter of geographic barriers, or has the user deliberately disrupted collection of GPS signal data?

Here is an overview of the GPS Metrics reports:

Both GPS Metrics reports include time lines with information about when GPS usage occurred on specific mobile devices.

You can select up to 7 days to include in a report and then specify the daily time range of interest; for example the 8 AM to 5 PM shift. Use date range and time frame settings in order to discover usage and performance patterns that reveal the cause of sparse GPS data; use search options to target data related to individual devices, users, or phone numbers.

In the GPS Metrics reports, you can view the last 30 days of data at the following levels of detail: by hour, by day, and by week. For details about the granularity of data provided in maps and reports and how long a given level of detail is available see “Data Availability in Maps and Reports” on page 239.

GPS Metrics Description

GPS Feed See the overall availability of GPS location data reported by mobile devices. The report illustrates what percent of time each mobile device was able to tell Locality where it was.

See “GPS Feed” on page 177 for more information.

GPS Drops See which GPS receivers fail to provide a reliable stream of location data. The report illustrates the number of times each mobile device drops its GPS signal.

See “GPS Drops” on page 178 for more information.


174 | Chapter 9 - Analyzing GPS Usage

Key Features of the GPS Metrics Reports Use the GPS Metrics reports to review and analyze overall GPS data reported by user, device, and phone number, and identify under-reported GPS data caused by device issues, GPS modem issues, or field service workers deliberately turning off the GPS on their mobile devices.

For businesses that employ field service workers, dispatch and workforce optimization software are the predominant field worker applications. GPS is a very critical part of dispatch software.

Information in the GPS Metrics reports will benefit:

Business managers responsible for business-level service level agreements IT/app/mobile support persons responsible for supporting the mobile application and

administering Locality Field service workers using the mobile application in the field

Report navigation and filtering tools allow rapid focus on critical information, so you can eliminate the extraneous data and quickly focus your attention on just the information you need:

Time frames that contain mobile worker data are visible at a glance. Filters can quickly be set to focus on data of interest:

° Time frame° Phone number° User or device

Filters are shared between individual GPS Metrics reports to shorten the time it takes to accomplish GPS troubleshooting and analysis.

Selecting Locality GPS Metrics Data In the GPS Metrics reports, you can view the last 30 days of data at the following levels of detail: by hour, by day, and by week. Within the available 30-day window of data, you can specify a date range and time range in order to discover GPS usage and performance patterns.

When you specify a date/time frame for your report, the tables on the right in your browser window are immediately updated using your selections. The procedures in this section show you how to select multiple dates for a report and how to filter the selected data to show a specific time range within the selected dates; see “Selecting Locality Report Data” on page 128 for an overview of all calendar functions.

To select multiple dates for a report filter

1. In this example, you want to view GPS data for each Wednesday in the last 30 days. The available 30-day window of Locality data spans two months (May and June).

To select individual dates in different months:

a. Click a date in the current month, and then click Ctrl-left-click to select each additional date; in this example, June 4, 11, and 18 are selected.



b. To add May 28 to your selected dates, click the back arrow (<) to move to May, and then Ctrl-left-click May 28.

To double-check which dates are included in your selection, point the cursor to any date:

Use the Calendar control to apply your time range filter to up to 7 days that you want to compare.

GPS Metrics reports provide a Time Range control that enables you to narrow your report data to a specific range of hours in a day.

To select hours for a time range filter

When you are working with GPS Metrics reports, you can filter data using a selected time range with hourly granularity (from 1 hour up to 24 hours).

1. In this example, to view data for a day shift, drag the Time Range left slider to 8:00:00 AM. Then drag the right slider to 5:00:00 PM.



2. To look at this time shift over a 5 day work week, keep your time range settings and select the 5 days that comprise the week:

The GPS Feed results are on the right:

Your time range must be continuous. If you have a shift that spans two days (for example, an 11:00 PM to 7:00 AM shift), set your time range to a full day (12:00:00 AM - 12:00:00 AM), and then ignore the middle section (from 7 AM to 11 PM) for these particular users.



To see the GPS Feed results for a single complete night shift, select both the start and end day in the calendar and set your time range to a full 24 hour day (12:00:00 AM - 12:00:00 AM):

GPS Feed Use the GPS Feed report to identify gaps in GPS data reporting, analyze trends in GPS data collection, and discover whether lack of data is associated with specific users or devices.

The GPS Feed table is sorted initially by the percent of time that a device’s GPS receiver was reporting location during the selected time frame, from least available location data to most available.

How to Interpret Patterns in the GPS Feed Report

The patterns of data in the GPS Metrics reports tell the story of how your GPS devices are performing in the field. Here are illustrations of patterns to look for, and information about probable causes. The legends that accompany each table have information about what these patterns represent.

Patterns in the GPS Feed Report

In the following GPS Feed table, the listed mobile devices are in use during the day shift (8:00 AM to 5:00 PM), and each one consistently exhibits a particular GPS behavior throughout the selected 5 day work week.

By default, the GPS Feed table is sorted by the percent of time that GPS was available during the selected time frame, from least available to most available. The devices listed at the top of the report may deserve your attention.



In the GPS Feed report illustration, rows are labeled with a Pattern Number. The following table contains an explanation for each of the patterns, and identifies possible causes for this type of pattern.

Legend for GPS Feed Data Patterns

GPS Drops Use this report to identify poor GPS performance, and determine which mobile devices are using a GPS receiver model that performs badly in comparison to other receivers in the same environment.

A GPS drop is counted each time the GPS feed goes from location detected to location not detected.

The GPS Drops table is sorted initially by the GPS drop count for each device during the selected time frame, from highest to lowest.

How to Interpret Patterns in the GPS Drops Report

In the following GPS Drops table, the listed mobile devices are in use during the day shift (8:00 AM to 5:00 PM), and each one consistently exhibits a particular GPS behavior throughout the selected 5 day work week.

Pattern Number What the pattern shows...

This device never gets a GPS signal. This is probably a device that is in an office and never gets exposed to a good GPS signal.

Other possibilities:

The device does not have a GPS receiver. The GPS has been disabled or removed. The GPS is broken. On this device, Locality has been disabled.

This device has a very unstable GPS receiver and experiences a lot of GPS drops. Locality appears to be active during the whole shift (8 to 5).

On this device, for long durations during the shift, the GPS is being disabled or unplugged, or Locality is being disabled.

This device has a GPS that is mostly stable, but experiences a moderate amount of drops. This could be a device that travels in mountainous areas or in areas where GPS information is not steadily available.

This device experiences good GPS reception.



In this table, data is sorted by the number of drops occurring during the selected time frame, from highest to lowest number of drops. The devices that top the table experienced the most unstable GPS signal.

A GPS drop is added to the Drop Count each time the GPS feed goes from location detected to location not detected.

In the GPS Drops report illustration, rows are labeled with a Pattern Number. The following table contains an explanation for each of the patterns, and identifies possible causes for this type of pattern.

Legend for GPS Drops Data Patterns

Pattern Number What the pattern shows...

This device has a very unstable GPS receiver and experiences a lot of GPS drops. Locality appears to be active during the whole shift (8 to 5).

Locality may count drops that you can’t see on the timeline. This happens when a drop spans such a short time that it cannot be rendered on the chart’s compressed timeline.

This device has a GPS that is mostly stable, but experiences a moderate amount of drops. This could be a device that travels in mountainous areas or in areas where GPS information is not steadily available.

On this device, for long durations during the shift, the GPS is being disabled or unplugged, or Locality is being disabled.

On the second, third, and fourth days, the shift began with the GPS going from not detected to detected state. Those state changes are not included in the drop count. A GPS drop is added to the Drop Count each time the GPS feed goes from detected to not detected.

This device experiences good GPS reception.

This device never gets a GPS signal. This is probably a device that is in an office and never gets exposed to a good GPS signal.

Other possibilities:

The device does not have a GPS receiver. The GPS has been disabled or removed. The GPS is broken. On this device, Locality has been disabled.


Chapter 10 - Examining Dropped Connections | 181

Chapter 10Examining Dropped Connections

As mobile phone users are aware, many things can interfere with the signal between your mobile device and a cell tower. Changing location or waiting will resolve most of these issues:

Weather—Storms with heavy rainfall and lightning. Tall buildings—Concrete, steel, and other solid construction materials. Terrain—Mountains, hills, and dense foliage. Time of day—When there is a spike in the number of users (for example, during rush hour), cell

tower performance can decrease. Faulty equipment, such as antennae and cables. Network technology—Many networks automatically downgrade connections to older, slower

technologies during peak usage or at the edges of coverage areas.

But there are other factors over which you have more control: Devices and equipment—Adapter performance varies widely by manufacturer, model, and

driver version.

The Dropped Connections reports help you determine which devices in a mobile deployment are experiencing connectivity problems during the last thirty days. The data is presented in terms of dropped connections per hour. You can filter results to try and identify trends or common elements of these problems over time. For example, isolate the devices with the highest frequency of dropped connections and sort them in order of frequency: are most of them using a particular adapter? If the signal quality is excellent, could the time of day explain the dropped connections?

Here is a quick overview of available Dropped Connections reports:

As you work with these reports, you will probably want to ignore devices that are experiencing low or very low rates of dropped connections per hour. For a procedure that includes this step, see “Analyzing Dropped Connections in Terms of Hardware” on page 184.

Analyzing Trends in Dropped Connections Use this report to see the dropped connection statistics for all of your mobile devices so that you can gauge the impact on productivity. For example, you can quickly identify any devices that are dropping connections even when signal quality is very good.

Dropped Connections Description

Trends Chart the frequency of dropped connections. See “Analyzing Trends in Dropped Connections” on page 181 for more information.

Hardware Chart the distribution of adapter manufacturer, model, and driver versions for devices with dropped connections. See “Analyzing Dropped Connections in Terms of Hardware” on page 184 for more information.


182 | Chapter 10 - Examining Dropped Connections

The Locality database retains the last 30 days of data about dropped connections, providing a rolling 30-day data window. As you work with the Dropped Connection Trends report, keep the following in mind:

Both "Last 30 days" and "All" date filters show the most recent 30 days of data.

When looking at the Time Trends chart, dropped connection counts appear in the month in which they occurred; if some data was collected in the previous month and some was collected in the current month, two month columns appear in the chart. You can use this chart view to identify hourly and weekly trends, but it is not as useful for identifying month-to-month trends.

The Distribution chart on the lower left shows the number of dropped connections on a per-device basis. In the following example, one device—Device5—stands out in terms of the frequency at which its connection was dropped:

The Drop Details table in the same report offers more detail on each device:

See “Selecting an ‘Area’ of Report Data” on page 131 for a procedure that uses this chart.

This next example demonstrates how the Trends report can help you identify devices that are experiencing a higher than average number of dropped connections. The steps will show you how to isolate the cause and use the Device Map for time- and location-based troubleshooting.

To identify and troubleshoot devices experiencing dropped connections

1. In June 2014 you received a higher than usual number of reports of dropped connections. In the Locality console, click Dropped Connections.

2. Open the Trends report and click JUN; when you press Enter, the whole month is selected and all available data is displayed. Use the slider bar to set granularity in the Time Trends chart. Because June has only about 3 weeks of data, setting it to Daily will be enough to identify



when the number of drops was especially high. In this example there is a spike in dropped connections on June 12:

3. In the Distribution scatter plot on the left, find out which devices active during this time period experienced the most dropped connections. To do this, move your mouse pointer over the point furthest to the right. The device details are shown in a small window:

4. To isolate possible causes for dropped connections, try these approaches:

° Use the Hardware report to see if a single device or specific adapter model is responsible for an above-average number of dropped connections. See “Analyzing Dropped Connections in Terms of Hardware” on page 184 for more information.

° Create a Device Map by specifying the device name (Device5, in this example) and targeted time frame (6-12-2014) in the selection pane. In this case, the explanation for



the increase in dropped connections is clear: the user was traveling through the Cascade Range, where the terrain accounts for spotty coverage.

For more information about creating a Device map, see “Selecting Locality Device Map Data” on page 148.

Analyzing Dropped Connections in Terms of Hardware The Hardware report shows the frequency of dropped connections by adapter manufacturer, measured in terms of drops per hour. Use this report to get an overview of your adapter population, or to focus on particular hardware. For example:

Identify how many of each adapter model you have across your deployment. Review and compare dropped connection statistics for all your mobile devices to determine whether dropped connections are having an impact on productivity, or use historical data to find device and adapter combinations that are performing well.

Focus on a single adapter or type of adapter to see if it is responsible for an above-average number of dropped connections. Identify the extent to which poor network performance (as measured by the frequency of dropped connections) is being experienced by users of certain adapter hardware manufacturers, models, and firmware revisions.

To compare dropped connection frequency among adapter manufacturers

1. In the Locality console, click Dropped Connections.



2. Open the Hardware report and select all available data (the last 30 days) by clicking All in the calendar area:

The Hours of Frequency by Model bar chart shows you which adapter models were responsible for the most dropped connections. Sometimes the difference is subtle: watch for orange and red segments at the bottom of each bar. Make sure you scroll through all of the adapters in your deployment by dragging the scroll bar at the bottom of the chart.

In this example, there are two adapter models that stand out from the rest. To isolate them, left-click the bars you want to select:



3. To zero in on the columns you selected, click the icon in the upper-right corner of the chart. Now the chart looks like this. To get more details about a portion of a column, rest your mouse pointer on it:

4. On the right you see a visual representation of the number of adapters involved. In the example below, the model Dell Wireless 5620 (EV-DO-HSPA) Mobile Broadband Mini-Card adapter has the highest frequency of dropped connections. Rest your mouse pointer on any pie segment to get more details about the adapter and how many are in your deployment:

To focus on a single adapter model

1. In the Locality console, go to Dropped Connections.

2. Set a time frame in the selection pane.

3. When you search for a higher than average number of dropped connections, you can do so by drop frequency and signal quality, or by adapter:

° To search by drop frequency and signal quality, open the Trends report and select devices experiencing higher dropped connections by clicking and dragging over them in the Distribution chart. See “Selecting an ‘Area’ of Report Data” on page 131 for information on making this type of selection.

° To search by adapter model, open the Hardware report and isolate the models that experienced a higher frequency of dropped connections.



4. In the Hardware report, look at the Manufacturer Details in the lower left:

° Are the higher dropped connections associated with a certain manufacturer? ° Is the higher frequency of dropped connections associated with a certain adapter?

5. To narrow down the adapter information even further, check its firmware. If there is more than one firmware version listed, is it associated with a higher frequency of dropped connections?

Note

The frequency at which connections are dropped is divided into five levels. Each level is represented by one pie in the Number of Adapters by Frequency chart, and the pie contains the top five models based on adapter count. If you have no adapters experiencing a very high number of dropped connections, for example, you see only four pies. For example:


Chapter 11 - Keeping Track of Network Adapter Inventory | 189

Chapter 11Keeping Track of Network Adapter Inventory

The cost per user on carrier data networks is higher than it is on wired networks, so it’s important to keep track of your inventory and protect your investment. The Inventory category includes reports that allow you to see what devices and adapters you have in inventory so that you can plan upgrades and future purchases. You can also use the reports to identify and track down particular accounts, determine which user logged on most recently, and other hardware details.

Inventory reports display the current hardware inventory, not historical data; you cannot specify a time frame in the selection pane. By default, the Locality database collects up to 180 days’ worth of data. For details about the granularity of data provided in maps and reports, and how long a given level of detail is available, see “Data Availability in Maps and Reports” on page 239.

Here is an overview of the Inventory reports:

Adapter Population Use the Inventory > Population report in the Locality console to see your network adapters in terms of manufacturers and models. What percentage of the total population of adapters is from a certain manufacturer? For a given manufacturer, what models are used and what percentage of the total do they represent? To find out if you need to upgrade any of your mobile computers, for example, use this report to see what versions of the adapter model firmware are in use.

Inventory Description

Population Adapter manufacturers sell many different models of network adapters. Use this report to see what percentage of the adapters in your deployment (population) are from a given manufacturer. For each manufacturer, find out what adapter models are used and what percentage of the total for the manufacturer they represent.

See “Adapter Population” on page 189 for more information.

Configuration Display detailed information about the configuration of network adapters as reported by each mobile device. The report is useful for identifying the distribution of adapters and who is using them on what devices.

See “Adapter Configuration” on page 190 for more information.


190 | Chapter 11 - Keeping Track of Network Adapter Inventory

In this example, three manufacturers are selected, samsung, Novatel Wireless, Inc., and Sierra Wireless, Inc.:

The Manufacturer Adapters by Model report at the bottom of the Population report is a mekko chart that gives you a quick visual representation of your selections:

The width of each bar represents the relative number of adapters from a manufacturer; Qualcomm, Inc. is the manufacturer for just over 88.89 percent of the adapters, so its bar takes up about 88.89 percent of the X axis.

Models are represented along the Y axis—each color block is a different model (the key is on the right):

To see complete details about an area of the chart, place your pointer on it and look at the pop-up window; the data matches what is shown in the table.

Adapter Configuration Use the Inventory > Configuration report in the Locality console to see detailed information about the configuration of network adapters as reported by each mobile device. Like the Population report, described in “Adapter Population” on page 189, the Configuration report is useful for identifying the distribution of adapters so you can manage the logistics of purchasing, updating, and retiring equipment. In addition, Configuration offers account information about adapters: for example, what


Chapter 11 - Keeping Track of Network Adapter Inventory | 191

device name and user an adapter is associated with, what the account phone number is, and when it was last used. For a report regarding adapter usage instead, see “Analyzing Network Usage by User” on page 164.

The Adapter Configuration table shows the phone number and adapter identifiers in your adapter population. There is a column for each of the following identifiers:

IMEI—International Mobile Equipment Identity (GSM network) ESN—Electronic Serial Number (CDMA devices) MEI—Mobile Equipment Identity (CDMA devices) IMSI—International Mobile Subscriber Identity

Many adapters have a dual-mode chip that is capable of supporting both GSM and CDMA. For these adapters a combination of identifiers is displayed; for example, see the Gobi adapters in the following table. An adapter with multiple identifiers might also be one that has been switched from one carrier to another.

The Adapter Usage table on the lower-left shows the user-oriented details about an adapter: the phone number, which carrier it uses, device and user names, and the date it was last used. (A “-” in the Last Used column indicates that the adapter is detected, but it has never been used.)

The pie charts on the lower-right present much of the same information visually, for a quick assessment.

As with all reports, you can refine your selection by selecting particular manufacturers or carriers in the selection pane. See “Selecting Locality Report Data” on page 128 for more information.


192 | Chapter 11 - Keeping Track of Network Adapter Inventory


Chapter 12 - Analyzing Mobile Diagnostics | 193

Chapter 12Analyzing Mobile Diagnostics

Mobile Diagnostics is an essential tool for understanding and resolving device issues that users encounter in the field. When they have an issue—for example, an application is not working, or there is no network access—they can press a button in the Locality agent to generate a report. The diagnostic information is available on both the device and in the console: a diagnostics summary quickly identifies the nature of the issue, and the details enable you (or a technical user) to dig deeper.

There are two kinds of diagnostics tests:

Built-in diagnostics tests, described in “Understanding Built-In Mobile Diagnostics Tests” on page 222.

(Optional) Custom tests, described in “Adding Custom Mobile Diagnostics Tests” on page 223.

Information about these tests and Mobile Diagnostics requirements is covered in “Managing Mobile Diagnostics” on page 221.

Viewing Mobile Diagnostics Reports To identify the reason for connectivity and performance issues on devices deployed to your mobile workforce, view the reports submitted by Locality agent users.

Getting there: Locality console > Mobile Diagnostics

As with many other Locality reports, you can filter the data you see:

When you make selections on the left, the list on the right is immediately updated.

Filter By Description

Date You can review and analyze test results reported by mobile devices any time within the previous 30 days. See “Selecting Locality Report Data” on page 128 for a description of how to make various calendar selections.

Diagnostic result When you open the Mobile Diagnostics tab, all available reports sent within the last 30 days are displayed. In addition to narrowing them down by date, you can also filter by result:

Passed—All tests passed. Warning—One or more tests resulted in a warning. Failed—One or more tests failed.


194 | Chapter 12 - Analyzing Mobile Diagnostics

Here is an overview of the list of reports. In this example the administrator has filtered the list so that only warnings and failed tests on a single day are shown:

See “Viewing Mobile Diagnostics Report Details” on page 194 for information about viewing detailed reports.

Viewing Mobile Diagnostics Report Details When a Locality agent user submits a Mobile Diagnostics report, the likely reason for a failure or warning is shown in the list of reports. To get beyond what is probably the root cause for the problem, dig into the report details.

Getting there: Locality console > Mobile Diagnostics > View

In this example, the user was experiencing a slower-than-normal file transfer. Mobile Diagnostics determined that the likely root cause was a weak carrier signal:


Chapter 12 - Analyzing Mobile Diagnostics | 195

Click Show details to see in-depth information. The details are quite extensive—here is just a portion of them:

In the example above, you see that two adapters on the Locality agent device are disconnected, and the one that is functional has a signal strength of only 14. Your advice to the user might be to either move to a location with a stronger signal, or make sure the WiFi adapter is enabled and move closer to an access point.

Here are all of the possible network categories—they do not necessarily appear in the report details in this order:

Preferred default gateway IPv4 interface list Wireless issues detected Detailed interface list IPv4 route table Mobility VPN information (if applicable)


196 | Chapter 12 - Analyzing Mobile Diagnostics


Chapter 13 - Managing Locality | 197

Chapter 13Managing Locality

Once Locality is installed and properly configured for your site, ongoing server management tasks should be minimal. The Locality console System pages (described in this section) provide information about the status of the Locality database, give you access to server event logs, let you manage the console license and device licenses, and configure client authentication. Access to the System pages is restricted to Locality administrators. Non-administrator console users can access console maps and reports, but the System tab is not available.

Locality server administrators can make system changes using the Locality Configuration Wizard. The wizard starts automatically after Setup, or you can make changes later; for more information, see “Running the Configuration Wizard Later” on page 35.

Using the Locality Console The Locality console is a web application that can be accessed from the Locality server or from a remote computer. The console allows authorized users to view reports and maps in order to monitor the health of a mobile wireless network. A select group of administrators are granted access to server settings and status information.

To use the Locality console, your web browser must be configured to accept cookies from the console web address.

Logging on to the Locality Console

To use the Locality console, you must be a member of the host computer’s Locality Administrators group or Locality Users group. The server Administrator account is a member of both Locality groups. See “Managing Access to the Locality Console” on page 198 for details.







http://localhost

To log on to the Locality console

1. Enter a valid user name and password.



198 | Chapter 13 - Managing Locality

° If using a domain user account, specify the user name as <domain name>\<user name>. ° If using a local account, specify the user name as <host name>\<user name>, and then

click Log On.

2. Based on the logon credentials provided, the server identifies the role assigned to this user and provides access to the console features associated with that role.

Note: Locality allows a limited number of console users to be logged on simultaneously. If your logon would exceed the limit, it is not allowed; you will see this message: Maximum number of console users reached.

Changing the Console User Password (Locality Cloud Only)

Only users of the Locality Cloud server have the ability to change a Locality console logon password.

To change your console user password

1. In the Locality Cloud console, click the Change Password link:

2. Enter your old password, enter a new one, and then confirm the new password entry.

3. Click OK to make the password change.

For an alternate method, see “Changing Your Own Locality Cloud User Password” on page 230.

Managing Access to the Locality Console

How access to the Locality console is determined depends on whether you have Locality server installed locally, or are running Locality Cloud.

Locality Server

The permissions required to access the Locality console are determined by membership in the host computer’s Locality Administrators group or Locality Users group, which are created during Locality server Setup.

Members of the Locality Administrators group are assigned the administrator role: they have full configuration rights and access to administrative features in the console.

Members of the Locality Users group are assigned the console user role, which permits access to Locality maps and reports but does not allow these users to see the console System tab or use any of the system administrative settings.

Individual members can be added to either group. If the Locality server’s host is in a domain, you can add a global domain user group to either one so that all members of the domain group have access to the Locality console.

For Locality users in a domain, the Integrated Windows Authentication server is Active Directory. For users who are not in a domain, the authentication server is the Locality server’s host.

Locality Cloud

The permissions required to access the Locality console are determined by membership in the Locality Administrators group or Locality Users group on your Locality Cloud server.

Assigning Groups or Users to a Console Access Role

(Locality server only) Users can access the Locality console provided they belong to the Locality Administrators or the Locality Users group. You can either add individual users to these groups or, if the Locality server’s host is in a domain, you can add a group of users by designating a global domain user group.



You can assign a Locality console access role to a combination of Active Directory (AD) groups and users:

Assigning a role to an AD group makes management a bit simpler: users who are members of a given AD group are permitted to view or modify the items in the Locality console based on their role.

Assigning a role to an individual user makes the administration a bit more complicated. For example, if the user takes on a new position in your organization or leaves, you have to edit the role and either assign it to someone else or remove it.

About the Locality Administrator Group

Members of the Locality Administrators group have full Locality system configuration rights and can also work with Locality reports and maps.

The Locality Administrators group is created automatically during Setup for the Locality server. The server Administrator user is added automatically to the Locality Administrators group.

Users in the Locality Administrators group have full access permissions for the NetMotion Wireless Locality folders (and sub-folders) in the \ProgramData folder.

About the Locality Users Group

Members of the Locality Users group can work with Locality reports and maps. They have no access to the System tab and cannot configure Locality server behavior.

The Locality Users group is created automatically during Setup for the Locality server. The group is used to prevent access to Locality server configuration settings and should not be removed.

The server Administrator user is added automatically to the Locality Users group.

Note

If you make any changes to groups, the system must be rebooted before they can take effect.

To add members to a Locality group

1. On the computer where the Locality console is installed, open the Windows Server Manager application.

2. Navigate to Configuration > Local Users and Groups.

3. In Local Users and Groups, select Groups to display the list of user groups. Open Locality Administrators or Locality Users, and click Add.

4. Click Locations to select the domain whose users you want to add to the open Locality group.

5. In the Enter the object names to select text box, select the users you want to add to the group. In addition to users with local accounts on this server, you can add user accounts and global groups from the local domain (if this host participates in a domain) or from other trusted domains.

6. Click OK to add your selected object names to the group’s Members list.

7. Click OK to save changes to the Members list and close the dialog box.



Console User Sessions

The number of users permitted to log on to the Locality console is determined by your deployment size. To see information about all active user sessions, Locality administrators can go to System > Status in the Locality console. For example:

Monitoring Locality System Status The administrative features used to monitor and maintain Locality are available on the System tab in the Locality console. This system information is not available to members of the Locality Users group.

Getting there: Log on to the Locality console as an administrator and go to System > Status.

The Status page displays health information for Locality system components, including the status of the Locality databases, integration of data obtained from the Mobility Analytics Module (if Mobility Analytics data integration is enabled), disk drive usage, and Locality system backups. It also provides information about active console user sessions.

To monitor the health of the Locality database, refer to “Reviewing the Status of the Locality Database” on page 235.

Monitoring Locality System Health

The Locality console checks for the status of Locality component services and databases every 10 seconds.

Getting there: Log on to the Locality console as an administrator and go to System > Status > System Health.



The system health indicators are as follows:



System Health Indicators for Locality Server

System Health Indicators for Locality Cloud

Monitoring Locality Console User Sessions

To see the list of active console user sessions, log on to the Locality console as an administrator and go to System > Status > Console User Sessions.

If a user session is inactive for more than 30 minutes, the user is automatically logged out of the console and removed from the list.

Item Description

Health indicators Available and running normally—A green icon indicates that this system component is up and running without problems.

System needs attention—A red icon indicates that a specific database or service is not operating normally.

° Go to System > System Logs to see more information about the cause of the failure.

° For help resolving data extract and load failures, contact NetMotion Wireless Technical Support; be prepared to export and send a copy of the system logs.

NA (not applicable)—Indicates that the listed component does not include a database, does not act as a service, or is not enabled, so a health indicator is not applicable.

Data Processor Check Services Console > Locality Data Processor

Check Services Console > NetMotion MySQL 5.6

Data Warehouse Processor

Check Services Console > Locality Data Warehouse


Sample Gateway Check IIS > Application Pools and Sites > Locality Sample Gateway

Client Authentication

Check IIS > Application Pools and Sites > Locality Provisioning Gateway

Licensing Check IIS > Application Pools and Sites > Locality Licensing


Operations Check Services Console > NetMotion MySQL 5.6

iOS Inventory Processor

Check Services Console > Locality MDM Data Processor

iOS Inventory Gateway

Check IIS > Application Pools and Sites > Locality iOS Inventory Gateway

Locality Web Service

Check IIS > Application Pools and Sites > Locality Web Service

Item Description

Health indicators Available and running normally—A green icon indicates that this system component is up and running without problems.

System needs attention—A red icon indicates that a specific database or service is not operating normally.

° Locality Cloud users should contact NetMotion Wireless Technical Support for assistance.

NA (not applicable)—Indicates that the listed component does not include a database or does not act as a service, so a health indicator is not applicable.



If a user does not log out before closing the console, he or she remains listed on the Status page for up to 30 minutes.

Monitoring Mobility Analytics Communication Status

The Locality console monitors the status of communication between the Mobility Analytics Module and Locality. To check current status, log on to the Locality console as an administrator and go to System > Status > Mobility Analytics.

Locality Server Version and Product Information

For information about your NetMotion Wireless Locality software, click the About link in the Locality console page header.

Item Description

User The user logged on to the console.

Logon Timestamp The date and time the user logged on to the Locality console.

Address The IP address of the user who is logged on to the console.

Item Description

Last communication Shows the date and time when the last communication took place between Locality Connect for Mobility and Locality server.

Most recent data Shows the date and time when Locality server received the most recent data from Locality Connect for Mobility.

Item Description

Version The software version number of the NetMotion Wireless Locality server.

Serial Number Each Locality server has a unique serial number to which its licenses are keyed.

IP Address The address of the Locality server.

MySQL Version The version number of the NetMotion MySQL database service. The Locality database stores Locality configuration settings and all the data collected by Locality agents.

Copyright Copyright information for the Locality server software and NetMotion Wireless.

Trademarks and Patents

Trademark and patent information for the Locality server software and NetMotion Wireless.



Managing Alerts and Messaging You can set alerts in the Locality console and determine who is notified when specific events occur; recipients do not need to be logged on to the console in order to get the alerts. You define the condition that generates an alert—the type of alert, when and how often it will be triggered—and create messages that are sent when the event occurs.

The Alerts and Messaging Module is a separately licensed feature that can be added to your Locality server. It must be enabled and configured during Setup, or by opening Locality Configuration on the Start page; see “Configuration Wizard: Configure Alerts and Messaging” on page 56 for more information.

Once you add the license, two pages are added to the System tab:

Alerts—Create alerts and messages Alert History—Alerts that have been triggered in the past six months

Creating and Editing Alerts and Messages

The process for creating a Locality alert and associated message is similar, regardless of the type of alert you want to add. Decide what type of alert to configure, how often to check for the condition you set, and what messages to send by text, email, or both.

Getting there: To define Locality alerts, log on to the Locality console as an administrator and go to System > Alerts > Add. The System tab is not available to members of the Locality Users group.

The configuration parameters are as follows—differences between alert types are noted:

Option Description

Name Specify a unique name that identifies the purpose of the alert. The name is displayed on the Alert History tab.

Type Most alert types are based on data coming from Locality agents; only System Health - Database applies to the Locality server:

Adapter Inactivity Adapter Usage Mobile Diagnostics System Health - Database

For examples showing how to use these alert types, see “Choosing an Alert Type and Frequency—Use Cases” on page 205.

Frequency Specify how often the alert conditions are checked:

Every time (alert recipients are notified whenever conditions are met) Hourly Daily Once

Inactivity (For Adapter Inactivity alerts only) Specify how many days of inactivity are required to trigger this alert.

Threshold (For Adapter Usage alerts only) This alert is based on data collected by Locality agents and is triggered by data usage that is over or under the specified threshold for the specified number of days.



Click Apply to add the alert to the list; to change an alert, click Edit.

Notes

Any alerts that you set up (System > Alerts) are in effect until you remove them from this list: you cannot enable alerts selectively.

Alert recipients normally see only new alerts. But if you change an alert, the first message they receive may contain older information; this is because the alerting frequency (Daily, Hourly, etc.) is reset whenever an alert is updated.

Alert recipients can use standard commands to stop and start text messages. For example, someone who receives both text and email alerts may choose to stop text messages during a trip abroad in order to avoid roaming charges, and then resume them upon returning.

Choosing an Alert Type and Frequency—Use Cases

Here are some guidelines for choosing an alert type and setting the frequency at which alert conditions are checked:

Message The alert notification must have at least one recipient and it can be sent as a phone text, an email message, a syslog message, or any combination of these message types. Select the message types that you want to send.

By default, each alert message contains basic information—the name of the alert and the conditions required to trigger it. You have the option of adding more information; for example, you could include IT contact information in the case of a System Health - Database alert.

To send an alert notification as a syslog message, a syslog server must be specified; see “Configuring Locality to Send Agent Data to a Syslog Server” on page 113 for more information.

Click Test to make sure that you specified valid phone numbers and addresses (test messages are not added to Alert History).

Alert Type Examples

Adapter Inactivity An inactive device—for example, one that has not had any network activity for three consecutive days—might not be functioning properly, or may need to be assigned to another user. If the alert is triggered after several days of inactivity, you probably do not need to set the frequency very high: Daily would be fine.

Adapter Usage Use this type of alert to find out if a device is being used infrequently or too much. A rarely used device (and its data plan) might be put to better use elsewhere. A device that is being used a lot bears more scrutiny: Is it being used appropriately? Should its data plan be upgraded? To avoid a flood of alerts once the data usage threshold is met, you probably do not need to set the frequency very high: Daily would be fine.

Mobile Diagnostics To get an alert whenever a Locality agent user runs Mobile Diagnostics, set the frequency for this alert to Every time. A link in the alert message brings the recipient to the Locality console, where the diagnostic report can be examined in greater detail.

System Health - Database The Locality database stores configuration settings and all the data collected by Locality agents, so its health is crucial to your deployment. A Bad health alert can indicate, for example, that the database does not have enough disk space, or that the warehouse service is not running. For more information about database status, see “Reviewing the Status of the Locality Database” on page 235.

Option Description



Viewing Alert History

Alerts that have been triggered in the past six months are listed in the Locality console. There are several ways to filter the list of alerts. If you received an alert that requires immediate attention, for example, you could set Triggered on to Last 6 hours, and also filter by Alert Type.

Getting there: To view Locality alerts history, log on to the Locality console as an administrator and go to System > Alert History. The System tab is not available to members of the Locality Users group.

Viewing System Logs Getting there: To view system logs, log on to the Locality console as an administrator and go to System > System Logs. The System tab is not available to members of the Locality Users group.

Information about the performance of the Locality server and console is logged to the Locality database. The System Logs page provides access to all messages logged within the last 40 days. Controls are available to filter log data by time interval, log level, specific message text, or by the name of the component or subsystem that logged the error. You can also export the logged data as a CSV file.

The default location for log files is C:\ProgramData\NetMotion Wireless Locality Server.

System logs can be used to troubleshoot problems with your deployment. For details, see “Working with Locality System Logs” on page 243.

Managing Locality Licensing Locality product licenses determine which reporting features are available in the console, and permit a set number of Locality agent devices to register with a single Locality server. Locality licenses may be time-limited.

Getting there: To manage Locality licenses, log on to the Locality console as an administrator and go to System > Licensing. (The System tab is not available to members of the Locality Users group.)

Locality Cloud users: If you are using a hosted Locality Cloud server, NetMotion Wireless Technical Support manages your server license keys. Contact Technical Support to make any server licensing requests. As a Locality console administrator, you will manage agent device licenses issued to your mobile devices.



Locality server users: Locality v3.x requires level 3 license keys. If you upgrade from an earlier version of Locality, your level 1 and level 2 permanent license keys are marked as expired. As part of the upgrade process, you must obtain and add level 3 license keys before you upgrade the Locality server. Later, after you have upgraded, all license management (including adding new licenses) is done in the Locality console.

When you purchase a Locality product license from NetMotion Wireless, it controls these features:

Product licenses are either time-limited (for product evaluation), permanent, or subscription:

Evaluation—This is an initial, time-limited license that you obtain from NetMotion Wireless. It is limited to a single server and controls the product modules that are available and the number of device licenses that can be issued. After the evaluation license expires, the functionality is no longer available.

Permanent—A permanent license controls the product modules that are available and is limited to a single server and a given number of devices. It does not expire. Additional permanent device license keys can be added to the server as your Locality agent deployment expands.

Subscription—A subscription license controls the product modules that are available and is limited to a single hosted server (Locality Cloud) and a given number of devices. Subscription licenses are issued for the term of the subscription.

Access Type Description

Locality console Your Locality server product license provides the following:

Inventory Management: reports to track your mobile devices. Network Performance Management: maps and reports that reveal network

performance, network usage, and dropped connections. GPS Metrics: reports on the GPS feed and GPS drops, to help you to

determine what caused a lack of GPS data for a user and when it occurred.

Your license allows Locality administrators to see information transmitted by Locality agents in the form of maps and/or reports in the Locality console. Until you add a Locality license key, the maps, data analysis, and reporting tabs are not available.

Separately licensed features

The following are separately licensed modules that can be added to your Locality deployment:

Mobile Diagnostics: enables Locality v3.x agents on all platforms to run standard and custom tests. Results are immediately analyzed and the likely root cause is displayed. All results can be viewed on the device in question and by the Locality administrator in the console.

Alerts and Messaging: enables you to set up alerts and notify colleagues about specific Locality events. You determine what will trigger the alert, who to send it to, and how (as a text, an email message, or both).

Locality devices Determines the number of devices running the Locality agent that can be licensed by a Locality server. Once licensed:

Android and Windows devices begin collecting and sending inventory and network performance data to the server.

iOS devices do the following, depending on which of these modules you have installed:

° Are ready to process Diagnostics reports.° Begin sending identifying data to the server for use in Inventory

reports.

Your server may have more than one active device license key, as each one provides additional capacity for a specified number of devices.

In the Locality console, go to System > Licensing to review the license state of Locality components and to manage the allocation of agent device licenses. See “Reviewing the License State of Locality Components” on page 210 for more information.



To add more Locality devices or to allow the Locality server to function beyond the evaluation license expiration date, you must get a new permanent or subscription license from NetMotion Wireless. The next step depends on which edition you have:

Locality server—Add the license(s) using the Locality console. See “Adding and Removing Locality License Keys” on page 208 for more information.

Locality Cloud—Contact NetMotion Technical Support for assistance.

Adding and Removing Locality License Keys

All licenses are keyed to the Locality server serial number.

Locality Cloud administrators: You are responsible only for managing agent device licenses. NetMotion Wireless Technical Support manages the Locality license keys for your Cloud server; contact Technical Support to make any server licensing requests.

Locality server administrators: Before you add license keys, be sure to check the Locality hardware and software requirements to determine whether your system can support the number of Locality agents you expect to deploy. See “Hardware and Software Requirements” on page 6 for a description of the requirements for small, medium, and large Locality deployments. To expand your current deployment, see “Changing the Size of Your Locality Deployment” on page 64.

Adding License Keys for a New Installation

You can add a license key when you first install the Locality server, as described in “Configuration Wizard: Add Locality License” on page 58, but most license management activity occurs in the Locality console.

To add a Locality license key in the Locality Console

1. In the Locality console, go to System > Licensing.

2. Click Get New License Keys to open the NetMotion Wireless customer portal in a browser. If you do not have Internet access, contact NetMotion Wireless Technical Support for assistance.

3. Enter your user name and password for portal access, and then go to the Product Licenses tab.

4. In the License Authorizations (Unissued) area, review the licensing information, then click Issue License Keys to generate your key.

5. The resulting license key (a text string) is made available in the License Keys (Issued Authorizations) area. Copy the license key string to the clipboard (Ctrl+C).

6. Exit the customer portal and return to the System > Licensing page in the Locality console.

7. Click Add License Key and paste the license key string into the License Key text box (Ctrl+V). Click OK.




8. Check the License Keys area to confirm that the license key was added successfully.

9. Some license additions require you to log off of the console and log back on again:

° When you add the first product license key, activate it by logging off. When you log back onto the console, Locality reporting tabs will be available.

° After adding a new product module license key to a running system, log off. When you log back onto the console, addition tabs are available.

° If you add device license keys to increase Locality agent capacity, they take effect instantly. Check the Device License area to confirm that Licenses issued has increased by the correct amount.

Obtaining v3.x License Keys Before You Upgrade

Locality v3.x requires level-3 license keys. It is important to obtain level-3 licenses and add them in the Locality v2.x console: the new licenses are activated when you upgrade the Locality server to v3.x; at the same time, the level-2 licenses will be marked as expired. With level-3 licenses already installed, your Locality agents will not experience any interruption in data transmittal.

Do not click Get New License Keys in the Locality console to retrieve Locality 3.x licenses: follow the steps below instead.

To obtain and retrieve license keys from the Customer Portal

1. Contact your NetMotion Wireless Technical Support if you are entitled to an upgrade. If you need to purchase level-3 licenses, contact your partner or sales representative.

2. Open the NetMotion Wireless customer portal in a browser. If you do not have Internet access, contact NetMotion Wireless Technical Support for assistance.

3. Enter your user name and password for portal access, and then go to the Products tab.

4. In the License Authorizations (Unissued) area, enter your server serial number, and then click Issue License Keys to generate your key.

5. The resulting license key (a text string) is made available in the License Keys (Issued Authorizations) area. Copy the license key string to the clipboard (Ctrl+C).

6. Open the System > Licensing page in the Locality console.

7. Click Add License Key and paste the license key string into the License Key text box (Ctrl+V). Click OK.

Note: License keys are case sensitive. If the letters in your entry do not match the case present in the generated license key, an error is returned.

8. If you have several components, you may have to repeat these steps for each one. Check the License Keys area to confirm that the license key was added successfully.



Note

When level-3 keys are applied to a 2.x server, the Alerts and Messaging module is listed as Module: Unknown; once you upgrade to 3.x it is displayed correctly.

Removing License Keys

Removing a valid license key affects the functionality of your Locality system:

Once a permanent license key is removed, it cannot be added or used again. Removing a valid device license key automatically unlicenses and disables agent devices that

exceed the new total license count, starting with those least recently used. An unlicensed Locality agent device is not able to collect data. Periodically, the unlicensed agent device will contact the server to see if a license is available. If your server requires client authentication codes, then unlicensed agents must be reconfigured with a valid authentication code before they can obtain a device license.

Removing a valid license key that includes Locality reporting modules disables the ability to view maps and reports in the Locality console.

To remove a license key

1. In the Locality console, go to System > Licensing.

2. In the License Keys area, select the check box next to the license key you want to remove.

3. Click Remove License Keys.

Reviewing the License State of Locality Components

The Locality console Licensing page shows information about the Locality modules licensed for your server and about the number of device licenses issued. You can add and remove Locality license keys, review the license state of Locality modules, and manage the allocation of agent device licenses.

Getting there: To view Licensing information, log on to the Locality console as an administrator and go to System > Licensing. The System tab is not available to members of the Locality Users group.

Installation Information

All licenses are keyed to the console serial number, which is displayed here.

License Keys

This area shows the status of all Locality license keys and provides links that allow you to get, add, or remove product license keys (see “Adding and Removing Locality License Keys” on page 208).

The icon next to each license key indicates its status:

If the console has never been licensed, or if the license key that controls access to Locality modules has expired or was removed, console users will not have access to maps and reports. However, if a valid device license key exists, agent data continues to be collected and added to the database; once module licenses are added or renewed, the data becomes viewable.

Icon Description License Key Status

Green Valid.

Yellow Expired. The license time limit has been reached.

Red Invalid. There is a mismatch between the license key and your console serial number. Contact NetMotion Wireless Technical Support.



If a device license key expires, Locality automatically unlicenses and disables agent devices that exceed the new total device licenses issued count, starting with least-used devices. An unlicensed Locality agent device is not able to collect data. An unlicensed agent device will contact the server periodically to see if a device license is available.

Device Licenses

This area summarizes the state of your device licenses.

Devices

The Devices area lists the licensing status of agent devices that have registered with the server and requested a device license. If your server is configured to require client authentication, it also shows the provisioning status of each agent that has contacted the server to obtain a signed client identity certificate. Using this list, you can:

Discover which of your agents are unable to get a signed client identity certificate from the Locality server. For details, see “Reviewing Device Provisioning Status” on page 220.

Manually unlicense agent devices that are no longer in use, so that their licenses are returned to the pool of available device licenses. For details, see “Monitoring Agent Device Status” on page 211.

Monitoring Agent Device Status

To review a list of agent devices that have registered with the server and requested a device license, go to the Licensing page. The following table shows all of the possible columns; see “Changing the Device List View” on page 214 for steps on editing the columns displayed.

Status Description

Licenses issued The total number of agent device licenses that can be assigned to agents. To change this number, see “Adding and Removing Locality License Keys” on page 208.

Licenses used The number of Locality agent devices that have been licensed.

Unlicensed devices The number of agent devices that have become unlicensed, which can occur for any of these reasons:

Android and Windows devices

° The device license key expired° The device license key was removed° The agent device was unlicensed manually by the system

administrator

When a previously unlicensed agent device requests and obtains a device license, the Unlicensed devices count is decremented.

iOS devices

° The device user removed the Locality mobile device management (MDM) profile

° The device has not responded to any Apple Push Notification request for 30 days

If an iOS device is manually unlicensed by removing the MDM profile, the user must go through the inventory enrollment process again to install the Locality MDM profile. See “Enrolling a Device in the Locality Inventory System (iOS)” on page 97.

Available licenses The number of licenses available for use by a device running the Locality agent. This is the total number of licenses issued, minus those that are in use.



Getting there: Locality Console > System > Licensing

To re-sort the list, click a column heading (you can filter by phone number or user, but you cannot sort these columns). To customize the list information, select a filter from one or more of the column drop-down lists, or (in the case of text boxes) enter some or all of the item you want to display.

Column Description

Licensed Identifies the licensed state of a specific device:

The device is currently licensed by the Locality server.

The device is registered but not licensed. The list may include:

° Devices that were licensed by the Locality server but have since been manually unlicensed

° Devices that have requested a license but could not receive one because the server has no licenses available

° iOS devices that submitted an authentication code but did not successfully download a Locality iOS inventory profile. When an inventory enrollment attempt fails, the iOS device is unable to provide Locality with a device name, phone number, and user name; identifying information is missing from the device row. The device is marked as unlicensed. An authentication code was consumed by the enrollment attempt, but a device license was not issued.

Device Name For Windows users, the computer name of an agent device that has registered with the Locality server.

For Android devices, the device name is constructed using this formula: <email address up to the @ sign>-<device model> (for example, mmcamper-VS920 4G).

For iOS devices, the configured name of the device. (The device name is specified using Settings > General > About.)

When filtering by device name, enter all or part of the name; the match is not case-sensitive.



Phone Number(s) The phone number of the network adapter running on the agent device. If there is more than one phone number listed, one or both of the following is true:

The device has been used with more than one network adapter The SIM card in the network adapter or Android device has been

switched

User(s) For Windows users, the logon name of the user that is running the agent device. If there is more than one user listed, than the device has connected and sent data while different users were logged on.

For Android devices, User(s) shows the email account associated with the device. For example: [email protected]

If an Android device has more than one account, the user name is determined as follows:

If a Microsoft Exchange account is present, it is used as the user name.

If no Microsoft Exchange account is present, a Gmail account is used. If there is no Gmail account, Locality uses a personal exchange

account (for example, Hotmail). If no email accounts are present, Locality looks at the profile.

When filtering by user, enter all or part of the name; the match is not case-sensitive.

For iOS devices, this column is empty because iOS does not employ the concept of a user name.

Last Communication Shows date and time when the device last communicated with the Locality server.

Registration Time Initially shows date and time the device first registered with the Locality server in order to obtain a license. The time is updated if the device state changes: device unlicensed, device relicensed, device renamed, or Locality agent upgraded.

Provisioning State If you are using client authentication, Locality agents are provisioned and licensed by the Locality server. The possible states are:

All—Shows Locality agents in all provisioning states. Unknown—The device is not using client authentication or the

provisioning state is not yet updated.

Note: When a device is provisioned, there may be a delay of up to 5 minutes before the provisioning state changes from Unknown to Granted.

Initialized—The agent sent a certificate signing request to the Locality server.

Challenged—The server has requested the Locality agent to provide an authentication code in order to get provisioned.

Certificate Creation Failed—The Locality server was unable to create a signed client identity certificate. Go to the System Logs page to look for information about this error condition.

Granted—The agent was authenticated and granted a license and a signed client identity certificate.

Revoked—The agent was manually unlicensed; the signed client identity certificate is revoked and this agent is untrusted.

Agent Software Version The Locality Agent software version running on the agent device.

Device Platform The operating system on which the Locality Agent software is running.

Column Description



Changing the Device List View

To manage the columns in the Devices list

1. Click the Columns button to open the column editor, which lists additional columns that can be added to the Devices table.

The column editor:

2. To add a column, select it in the column editor list and then drag it to an insertion point on the column header row and drop it. In this example, the column License Change Reason was dragged from the column editor and will be dropped at an insertion point between the User(s) column and the Last Communication column. Arrows identify the insertion point.

3. To remove a column from the Devices table, begin by opening the column editor. Then drag the column’s header and drop it on the column editor.

License Change Reason Displays the license change reason. Options:

Device licensing request—Lists all Locality agents that requested a license from the server.

License key expired—This device is no longer licensed because the Locality server’s license key has expired. When the license on a device expires, the Locality agent displays a banner message indicating that the device is not licensed. Once a new device license key is added for the Locality server, these agents will be able to receive a new license.

Device manually unlicensed—Lists devices that were unlicensed by a Locality system administrator; in this case the signed client identity certificate stored on the agent is also revoked.

License key deleted—The device is no longer licensed because the Locality server’s license key was removed.

Device auto-relicensed—If a device becomes unlicensed for any of the above reasons, but there are additional device licenses available, the Locality server immediately relicenses the device without affecting the licensing state of the agent.

OS Version The operating system version running on the agent device.

Column Description



4. To change the location of any column in the Devices table, drag the column header from its current position in the table header row to a new insertion point in that row and drop it.

Managing Agent Device Licenses

This section explains how agent license status affects Locality data collection, how to export device status information, and how and when to unlicense devices.

How the Agent License Status Affects Data Collection

Locality agent devices register with the Locality server and are licensed on a first-come, first-served basis. For example, if your server has a license for 300 devices, the first 300 Locality agent devices that connect to the server are granted a license that permits them to begin collecting data and transmitting it to the server. Once the 300 licenses are assigned, any additional agent device that requests a license will be refused. You must purchase additional licenses to increase device capacity.

To check the licensing status of a Locality agent

From the console, go to System > Licensing. The Devices area lists the current licensing status (Licensed or Unlicensed) for every agent device that has ever registered with the server and requested a device license.

Device License Status Ability to Collect Locality Data

Licensed Windows and Android devices: A licensed device collects network performance and inventory data continuously and then sends it to the Locality server every 30 minutes.

iOS devices: A licensed device send inventory data to the Locality server once an hour. A Diagnostics-licensed device user can send a report to the Locality server at any time. (If you have users who are running both Mobility and the Locality agent, you can use Mobility policy to automatically run a diagnostic report.)

Unlicensed Windows and Android devices: An unlicensed device cannot collect data. Periodically, the Locality agent will connect to the Locality server and request a license.

iOS devices: An unlicensed device cannot report inventory data. An iOS device becomes unlicensed if:

A Locality administrator manually removes the license The user removes the Locality Mobile Device Management

profile from the device The device does not respond to Apple push notifications for

30 days



Producing an Agent Device License Status Report

Use the following procedure to export all agent device license data to a comma-delimited file (CSV) suitable for use in a spreadsheet program.

To create an agent device License Status report

1. Go to Locality console > System > Licensing.

2. Scroll down to the Devices area, which lists the current licensing status of all agent devices that have registered with the server and requested a device license.

3. Click Export to export data about the licensing state of every Locality agent that has ever registered with the server. The data is provided in a comma-delimited format (CSV).

Note: Data filters applied to the Devices list are ignored by the export process. All licensing data is exported.

4. Load the exported CSV file into a spreadsheet program for further processing and printing.

Reclaiming Unused Agent Device Licenses

When a Locality agent connects to a Locality server for the first time, it automatically registers with the server and requests a device license. If available, the server issues the agent a license.

Locality licensing is based on your number of registered devices, not concurrent connections. On the Licensing page of the Locality console, the Device Licenses area indicates whether individual device licenses are available for distribution, and shows how many licenses are in use and how many are still available for assignment to devices. When the Available license count equals zero, no more new devices can be added to the server.

As devices are taken out of service, they may remain registered and licensed on your server, even though they are no longer in use. Use the following procedure to unlicense devices that you no longer use, in order to return their licenses to the pool of available device licenses. You can also unlicense agent devices that should not have access to the server, in order to prevent them from sending data to the server.

To unlicense an agent device in the Locality console

1. Go to System > Licensing.

2. Scroll down to the Devices area, which lists the current status of all agent devices that have registered with the server and requested a device license.

3. To find an inactive device so that you can recover its device license:

Server device license expired or was removed

If the server’s device license key is removed or expires, there may be more devices registered with the server than there are valid licenses. Licensed devices that exceed the total number of valid licenses are automatically unlicensed, starting with those least recently used.

The unlicensed devices are not allowed to collect or transmit any more data until they are relicensed. However, the data they previously submitted is retained in the Locality database for up to 180 days.

For agent devices that were provisioned with a signed client certificate used for client authentication, the certificate remains valid. An expired device license does not cause the client certificate to be revoked.

If a system administrator purchases and applies additional device licenses through the console, the unlicensed devices can obtain a new license and resume collecting and transmitting Locality data.

Device License Status Ability to Collect Locality Data



° Set the Show filter to Licensed to show all licensed devices.

° To list devices that have been inactive for the longest time, click the Last communication column heading. Devices that have been inactive for significant lengths of time are prime candidates for unlicensing.

° To find a specific device, use the search box. Enter all or part of the device name, phone number, or user name for the device.

4. Select the check box next to each device that you want to unlicense.

5. Click the Unlicense button to unlicense selected devices and restore their licenses to the pool of available licenses.

Notes

Historical data for an unlicensed device remains in the database and can be viewed in reports and maps. See “Data Availability in Maps and Reports” on page 239 for information about how long agent data is retained.

Android and Windows devices only:

An unlicensed device cannot collect data. Periodically, the unlicensed Locality agent will connect to the server and request a license. To prevent relicensing, uninstall Locality agent software on the device.

When you manually unlicense a device, it ceases to collect data. If the agent was provisioned with a signed client identity certificate to support client authentication, that certificate is revoked. To reactivate the device, the agent must be reconfigured to use a valid client authentication code and then go through the provisioning process before it can be relicensed.

iOS devices only:

An unlicensed device cannot send inventory data. To relicense an iOS device that was manually unlicensed, the device must go through the

inventory enrollment process again.

Using Client Authentication to Deploy Locality Securely To provide a more secure environment, NetMotion Wireless recommends that you set up client authentication between your Locality agents and the Locality server for the safe transmittal of data. (With Locality Cloud, client authentication is required and already set up.) Setting up this feature is described in “Planning for Security—Client Authentication and Server Authentication” on page 67.

Getting there: To manage client authentication codes, log on to the Locality console as an administrator and go to System > Client Authentication. The System tab is not available to members of the Locality Users group.

To generate and manage client authentication codes, which are then distributed to individual Locality agents, use the following procedures:

“Creating Client Authentication Codes” on page 217 “Distributing Client Authentication Codes” on page 219 “Editing Client Authentication Codes” on page 219 “Reviewing Device Provisioning Status” on page 220 “Renewing a Signed Client Identity Certificate” on page 221

Creating Client Authentication Codes

Locality authentication codes are created in the Locality console and then distributed to Locality agents for provisioning purposes. This process is used to establish a trust relationship between the Locality server and agent:

a. The agent is configured to send the authentication code and a certificate signing request to the Locality provisioning gateway.

b. Locality uses the code to validate the agent’s authenticity, sends the agent a signed client identity certificate, and then directs the agent to connect to the Locality sample gateway.



c. The agent connects to the sample gateway for the first time, where it proves its authenticity by sharing the signed client identity certificate. The sample gateway responds with a device license. Once licensed, agents on Windows and Android devices begin collecting data.

d. Thereafter, agents on Windows and Android devices periodically connect to the sample gateway in order to send collected data samples. iOS devices periodically receive Apple push notifications that request the device to send device information to Locality for use in Inventory reports. Each time the agent connects, the sample gateway checks the signed client identity certificate to validate client authentication. After authenticating the agent, the server accepts the agent’s data.

To generate client authentication codes

1. Log on to the Locality console as an administrator and go to System > Client Authentication.

2. Click Create New Authentication Code to expose the fields used to issue a new authentication code.

3. Configure the following options:

4. Click Apply to generate the authentication code.

Option Description

Description Provide a meaningful label that identifies this set of authentication codes; extended ASCII characters are not allowed.

Platform To limit use of this authentication code to devices running a specific operating system, select those platforms (Android, iOS, or Windows).

If you do not want to confine use of the authentication code to a single platform, select All.

Valid From The date on which this authentication code becomes valid and available for use. Valid codes will be accepted by the Locality server for provisioning purposes.

Valid To The date on which this authentication code stops being valid; the Locality provisioning gateway ceases to accept the authentication code for provisioning purposes.

The expiration of the authentication code has no impact on Locality agents that used this code for provisioning during the time that it was valid. The signed client identity certificate and the device license that the agent obtained during the provisioning process remain valid until their expiration dates.

If either the certificate or license expires, the agent will cease to be able to send data to the Locality server until it obtains a new certificate or license.

On Android and Windows devices: When the certificate reaches its half-life (six months before the certificate expiration date) the Locality agent automatically attempts to renew it. See “Renewing a Signed Client Identity Certificate” on page 221 for details.

On iOS devices: The signed client identity certificate is not automatically renewed. It expires in 10 years (3650 days).

Issued Specifies the number of agents that can be configured to use this authentication code.

Each time an agent uses the code to become provisioned, the Used count is incremented and the Available count is decremented by 1.



5. The resulting authentication code (a text string) is made available in the Authentication Code column. By default, most of it is hidden. To show the full code, select the Show/Hide Code check box.

6. The next step is to distribute the authentication code and configure Locality agents to use it. See “Distributing Client Authentication Codes” on page 219.

Distributing Client Authentication Codes

Distribution to Windows devices: Use a secure form of delivery to distribute the authentication code text string to Locality agent users. Windows device users are prompted to enter the code manually when installing the Locality agent on their devices.

On Windows devices you have the additional options of using a silent install script, performing a remote install, or cloning an operating system image to deploy a Locality agent that is preconfigured with an authentication code. See “Automating Installation of the Locality Agent” on page 80 for details.

Distribution to Android devices: Use a secure form of delivery to distribute the authentication code text string to Locality agent users. Android device users are prompted to enter the code manually when installing the Locality agent on their devices.

Distribution to iOS devices: Use a secure form of delivery to distribute the authentication code text string and the Inventory Enrollment web page URL to Locality agent users. The URL must use the fully qualified domain name of your server and append /ios. For example: https://yourlocalityserver.yourcompany.com/ios. When iOS device users open the Inventory Enrollment web page, they are prompted to enter the authentication code in order to enroll in Locality Inventory Management. The complete enrollment procedure is available from the Review link on the web page.

Editing Client Authentication Codes

Client authentication codes can be edited to extend or shorten their longevity and to increase or reduce the number of codes issued (this controls the number of times the code can be used).

To edit properties of an existing client authentication code

1. Log on to the Locality console as an administrator and go to System > Client Authentication.



2. In the Authentication Code table, click Edit in the row containing a code you want to edit. This exposes the fields used to modify settings for the authentication code.

3. In the example above, the existing code has expired. This has no impact on devices that already used this code for provisioning; it simply means that the provisioning gateway now rejects this code as invalid.

° To continue using the code for provisioning purposes, edit the Valid To date to extend the time frame in which the code will be accepted by Locality. Also, the Issued value can be increased to allow more devices to use this code.

° To force a code to expire, specify 0 in the Issued field.

Reviewing Device Provisioning Status

Use the Locality console to review and manage the provisioning status of individual agent devices. The provisioning process gives a Locality agent device a secured identity using certificates. If the Locality agent device is not provisioned, it cannot obtain a license. And, if the Locality agent is not licensed, it cannot collect network performance data.

After configuring Locality agent devices with an authentication code, you can monitor the provisioning process to identify which devices succeeded or failed to be provisioned with a signed client identity certificate.

On the console Licensing page, the Devices area lists the provisioning status of agent devices that require a signed client identity certificate from the Locality server.

To review Locality agent provisioning status

1. Go to Locality console > System > Licensing.

2. Scroll down to the Devices area, which lists the current licensing status of all agent devices that have registered with the server and requested a device license.

3. The Provisioning State column identifies the state of the each device. Filter the list to view agents in a specific state; see “Monitoring Agent Device Status” on page 211 for details on each state.



Renewing a Signed Client Identity Certificate

On Windows and Android devices, the signed client identity certificate that the Locality agent receives during the provisioning process is valid for one year (365 days). When the certificate reaches its half-life (six months before the certificate expiration date) the Locality agent automatically attempts to renew it. After connecting to the Locality server to submit samples, the agent requests a new certificate, which is granted by the server.

Note: If an agent device does not connect to the Locality server at any time during the 6-month renewal period, the client identity certificate stored on the device will expire before renewal. In this case, the agent device must be re-configured with a client authentication code; the code is used to re-provision the agent with a new signed client identity certificate.

On iOS devices, the signed client identity certificate that the Locality agent receives during the provisioning process is valid for ten years (3650 days).

Managing the iOS APNS Client Certificate This topic applies to Locality servers that are configured to support iOS inventory reporting.

To support iOS inventory reporting, your Locality server must obtain a valid Apple Push certificate. This certificate allows the Locality server to periodically ask the Apple Push server to direct Locality agents on iOS devices to contact the Locality server so that Locality can get inventory information from the iOS devices.

The Apple Push certificate expires a year after it is issued and must then be renewed. The Locality console begins displaying a reminder 30 days before your Locality server’s Apple Push certificate expires. The reminder appears in a banner at the top of the console System pages and shows the date on which the certificate expires.

If the certificate expires, the Locality server is unable to send requests to the Apple Push server. Consequently, your Locality agents on iOS devices will stop connecting to the Locality server to provide inventory information.

If your Apple Push certificate needs to be renewed, see “Renewing a PEM File for iOS Inventory Authentication” on page 52.

Managing Mobile Diagnostics Mobile Diagnostics is a tool for understanding and helping you address device or connectivity issues that users encounter in the field. When a Locality user runs diagnostics, a series of tests are run and a full report is generated. Mobile Diagnostics immediately analyzes the results and displays what is the likely root cause. All results can be viewed on the device in question and by the Locality administrator in the console.

Getting there: To manage custom tests or disable Mobile Diagnostics, log on to the Locality console as an administrator and go to System > Mobile Diagnostics. (The System tab is not available to members of the Locality Users group.)

There are two kinds of tests—both types are executed when the user runs diagnostics:

Built-in diagnostics tests, described in “Understanding Built-In Mobile Diagnostics Tests” on page 222. These tests are always run.

(Optional) Custom tests, described in “Adding Custom Mobile Diagnostics Tests” on page 223. These are run after the built-in tests and in the order that you determine in the console.

System Requirements

The Mobile Diagnostics Module is a licensed feature that can be added to your Locality deployment. Using the module requires the following:

Version 3.x or later of the Locality server. A feature license for the Locality Mobile Diagnostics Module. Contact your NetMotion Wireless

sales agent for assistance. Locality agent v3.x on your Windows devices; earlier agent versions are not supported.



Information about Mobile Diagnostics reports is covered in “Analyzing Mobile Diagnostics” on page 193.

Note

If you change the setting for Mobile Diagnostics (Enable/Disable), or if you make changes to any custom tests in the Locality console, the changes are not picked up by the Locality agent until it communicates with the Locality server, which occurs within 30 minutes. If you want the change to be applied immediately, have the user go to the Status tab on the Locality agent and then click Test server communication.

Understanding Built-In Mobile Diagnostics Tests

The standard tests that are executed whenever a Locality agent user runs diagnostics are designed to determine basic network functionality. For example, is there a network interface with an adequate signal, is the GPS receiver working properly, and does the user have Internet connectivity? The summary results (pass, warn, or fail) help you understand which area you need to explore in more detail.

“Mobile Diagnostics—Device Tests” on page 222 “Mobile Diagnostics—Internet Tests” on page 223

Mobile Diagnostics—Device Tests

The device tests provide a quick view of the networking state of the Locality agent device and the status of the GPS receiver.

Devices Test Description and Examples

Network Interfaces This set of diagnostic tests determines interface and routing problems that are detected locally on the Locality agent device. The test results are grouped as follows:

WiFi Status WWAN Status Detailed Interface List IPv4 Route Table Mobility VPN information (if applicable)

Examples of test summaries:

Carrier network adapter has no service.WiFi network adapter is connected but has low signal quality.

GPS Receiver This test runs only on Windows devices.

This is an informational diagnostic that indicates the status of the Locality-detected GPS.

Examples:

GPS receiver cannot obtain a satellite fix.GPS is reporting a location, but the accuracy is poor.



Mobile Diagnostics—Internet Tests

These tests detect problems that the Locality device has in reaching the Internet that are caused by external factors.

Adding Custom Mobile Diagnostics Tests

You can create your own Mobile Diagnostics tests and have them run after the built-in tests. When creating custom tests you can use a combination of these approaches:

Create tests to check the accessibility of critical resources.

You may want to have tests that are always executed when users generate diagnostics. For example, if certain network resources are crucial to your users, you can create a custom test that determines whether the resources are accessible. You would need to update the tests whenever resources changed, but otherwise this would be a “set it and forget it” approach.

Add a test temporarily.

Maybe the built-in tests give you all the feedback necessary to diagnose an issue, but what if certain users are having trouble reaching a particular host or web resource? You can create a test that targets those resources. After resolving the issue you may want to delete the test so that it is not included when other, unaffected users run diagnostics.

Arrange Custom Tests in Order of Priority

The custom tests are executed in the order in which you place them, and they are all run after the built-in tests (you cannot run them selectively). It is a good idea to put the broadest ones at the top (for example, can the device ping the main router?), followed by more specific tests (the main router is responding to pings, but can the device reach certain TCP/IP services inside the firewall?).

Internet Test Description and Examples

Captive Portal Detection

Hotspots that redirect your connection until a certain action is performed, such as agreeing to terms, are common in airports, hotels, and coffee shops. This test detects whether the Locality agent has encountered this kind of hotspot (also known as a captive portal).

Examples:

Network activity is being redirected; web browser authentication may be required.Network activity is not blocked.

Mobility VPN This test runs only on Windows devices.

For devices running both the Locality agent and Mobility, this test determines whether Mobility may be causing network access issues.

When Mobility appears to be at fault you could ask the Locality agent user to disconnect Mobility and re-run diagnostics.

Examples:

Mobility cannot communicate with its server.Mobility is disconnected and blocking network traffic.Mobility is using an alternate network interface.

The last example above indicates that Mobility is not using the interface with the highest priority metric and has switched to another one. Some explanations are that there is a network problem on the primary interface, or there is a Mobility policy rule that is blocking it.

Internet Connectivity This diagnostic simply determines whether you have Internet access.

Examples:

The web server name could not be resolved to a network address.Web server responded but ping had data loss.



There are several different types of tests you can create:

Notes

If you make changes to the custom tests in the Locality console, they are not picked up by the Locality agent until it communicates with the Locality server, which occurs within 30 minutes. If you are working with someone on a pressing issue and you want a new or changed test run immediately, have the user go to the Status tab on the Locality agent and click Test server communication, and then run diagnostics.

The maximum number of custom tests you can add is 50.

Test Type Sample Entry and Result

HTTP/HTTPS https://patientDB.yourcompany.com

Tests connectivity to a URL. If the server has a single, known IP address and responds to pings, you can get more a detailed analysis using a Web Resource test.

Name Resolution accounting.yourcompany.com

Determines whether a host name can be resolved to an IP address:

Performing name lookup for host: accounting.yourcompany.comIPv4 Addresses for host: 123.123.111.222

Ping 123.123.123.45

Tests host reachability and response time:

Ping Configuration: Host 123.123.123.45PingCount 20PingTimeoutMs 2000TotalTimeoutMs 10000Pinging 123.123.123.45 with 32 bytes of data:The request timed out.

TCP Connect hr.yourcompany.com:5008

Tests TCP connectivity to a host and port.

Performing TCP/IP connection to host hr.yourcompany.com using port 5008.Could not obtain address information for host. Error=11001 Message=No such host is known.

Traceroute 123.123.123.45

Gathers route information.

Trace Route Configuration:Host 123.123.111.222PingsPerHop 3MaximumHops 30HopTimeoutMs 2000TotalTimeoutMs 1200001 <1 ms <1 ms <1 ms accounting.yourcompany.com [123.123.111.222]

Web Resource http://yourcompany.sharepoint.com - 123.123.123.45

Tests reachability, connectivity, and name resolution for an HTTP/HTTPS server:

Host name resolution to host hr.yourcompany.com succeeded.Ping to host 123.123.123.67 failed.Page Load Result: Pass

If the target server is not configured to respond to pings, or if it is associated with more than one known IP address, use an HTTP/HTTPS test instead.



Automating Mobile Diagnostics Tests

You can start Mobile Diagnostics by running the Locality agent with optional parameters on the command line or in a script, simplifying the process for users.

By default, the Locality agent is located in the following folder:

C:\Program Files (x86)\NetMotion Wireless Locality Client\

Usage:

Locality.exe [options]

Usage examples:

Run diagnostics silently with no system tray or progress window notification for the end user. In addition, include a comment in the report:

Locality.exe -startdiagnostics -diagnosticcomment="Diagnostics launched by automation"

Run diagnostics, notify the end user of progress status, and include a comment in the report:

Locality.exe -startdiagnostics -notify -showprogress -diagnosticcomment="User was informed that diagnostics was launched by automation"

Option Description

-startdiagnostics Launch the built-in and (if applicable) custom Mobile Diagnostics tests configured in the Locality console.

-notify Shows a message in the task bar so that the Locality agent user knows that the tests are in progress. For example:

-showprogress Indicates the progress through the list of tests (some can take a few minutes) and displays the summary of results when the tests complete.

-diagnosticcomment="<text>"

or

-diagnosticcomment "<text>"

Adds a comment, which will be visible in the list of diagnostic reports in the Locality console. For example:

diagnosticcomment="Auto-generated diagnostics from a member of truck fleet 457"



Mobility Client Policy Integration with Mobile Diagnostics

If you have users who are running both NetMotion Wireless Mobility and the Locality agent, you can use a Mobility client policy to run a diagnostic report whenever the Mobility server goes unreachable. The resulting diagnostic report can be viewed on both the user’s device and in the Locality console.

Note: This example specifies the Locality agent running on a 64-bit platform; the default paths for the registry and installation directory are different for a 32-bit operating system.

Mobile Diagnostics Agent Compatibility

Mobile Diagnostics tests can be run on all Locality agent platforms: Windows, Android, and iOS. The diagnostic capabilities differ slightly between platforms. For example, Android and iOS support only built-in GPS devices, so they do not require the GPS query function that Windows does (when GPS is enabled on Android and iOS devices Mobile Diagnostics tests show the location where the test occurred).

Device Tests iOS Android Windows

Network adapter status

Local network (routing table, gateway)

GPS

Mobility connection

Network Tests iOS Android Windows

Internet (DNS, ping, HTTP, etc.)

Captive portal detection

Mobility server pool

Custom Corporate Resources iOS Android Windows

HTTP/HTTPS



Managing Locality Cloud User Accounts Locality Cloud provides self-service user management that allows you to add, remove, or update user accounts on your hosted Locality Cloud console. Use these accounts to:

Give users access to Locality maps and reports. Give administrative users access maps and reports, and to all available Locality Cloud console

management options.

To add, remove, and manage console user accounts, follow the procedures in this section.

Adding a New Locality Cloud User

The System tab is not available to members of the Locality Users group.

To add a new console user

1. Log on to Locality Cloud as an administrator and go to System > User Administration.

2. Click Add to display settings used to create a new console user account.

Name Resolution

Ping (latency)

TCP connect

Traceroute

Web resource

Automate Mobile Diagnostics iOS Android Windows

Use Mobility Policy to automate running Locality Mobile Diagnostics.

Device Tests iOS Android Windows



3. Configure the following options:

4. Click Apply to create the new user account.

5. Locality automatically sends email notification to the user with details about the new account. For example:

6. The added user must log on with the temporary password. When prompted to enter a new password, the user must enter the temporary password again, in addition to the new password, and then Change Password.

Resetting a User Password (Locality Cloud)

To reset a Locality Cloud user password


2. Find the user in the User Administration table and click Reset Password.

Option Description

User Name The name of the person who owns this Locality Cloud user account.

The Windows server that hosts Locality Cloud enforces the following user name restrictions:

A user name cannot be identical to any other user name or group name on the computer that is being administered. The user name can contain up to 20 uppercase characters or lowercase characters, except for the following:

° " / \ [ ] : ; | = , + * ? < > @ ° A user name cannot consist solely of periods (.) or spaces.

Display Name Typically, this is the user’s full name.

Admin Select this check box to give the user administrative privileges in the Locality console. Administrators have full permissions to work with settings on all pages on the System tab.

Email The email address for the user that owns this account. Locality uses this address to communicate account information directly to the user. For example, the console will send email to this address when the account is created or if the account password is reset.



3. In the Reset User Password dialog box, you can either manually enter a new password for the user or you can have Locality generate a new temporary password automatically.

° If you clear the Auto-generate check box and manually define a new user password, Locality sends the user an email about the password change and tells the user to contact the Locality Cloud administrator to obtain the new password. For example:

° If you select the Auto-generate check box, Locality generates a temporary password and emails it to the user with instructions to log on with the temporary password and then change the password when prompted. For example:

When the user logs on with an emailed temporary password, he or she will be prompted to change the password:

The added user must log on with the temporary password. When prompted to enter a new password, the user must enter the temporary password again, in addition to the new password, and then Change Password.

Editing a Locality Cloud User Account

To edit a Locality Cloud user account


2. Find the user in the User Administration table and click Edit to access the user’s account.



Deleting a Locality Cloud User Account

To delete a Locality Cloud user’s account


2. In the User Administration table, select the check box next to one or more users that you want to delete.

3. Click Delete. You are prompted to confirm the delete operation.

Changing Your Own Locality Cloud User Password

Anyone with a Locality Cloud user account can manually change their own password. The Reset password option is available on the Locality Cloud logon page.

To change your Locality Cloud password

1. Open the Locality Cloud URL in a web browser.

2. Enter your current Locality user name.

3. Click Reset password.

4. After confirming that you want to change your password, the Locality server will send you a temporary password needed for the password change process. The logon page refreshes to show New Password and Verify New Password boxes.

5. In the Password box, enter the temporary password that was emailed to you.

6. Enter a new password in both the New Password and Verify New Password boxes.

7. Click Change Password. The new password must conform to password policy requirements enforced by Locality Cloud. If it does not, you are prompted to try again, specifying a longer, more complex password.



Exporting Coverage Data for Use in GIS Applications Getting there: Log on to the Locality console as an administrator and go to System > Coverage Data Export. The System tab is not available unless you are an administrator.

Locality supports geographic information systems (GIS) integration. You can use network data collected by Locality to conduct operational modeling and identify locations where your mission-critical mobile applications are affected. You can export Locality’s detailed geo-tagged signal coverage/quality data as CSV files. This data can be imported into numerous GIS systems such as ESRI (via shape file overlays).

Configuring Coverage Data Export

You can configure Locality to generate a daily CSV file that contains coverage data extracted from your Locality database. For details about the data that is extracted, see “Coverage Data Dictionary” on page 232.

To configure Locality to export coverage data automatically

1. Log on to the Locality console as an administrator and go to System > Coverage Data Export.

2. Under Coverage Data Export Status, click Enable to configure the daily coverage data export process.

When enabled, Locality exports collected coverage data to a file named LocalityExport.<year-month-day>.csv, making periodic updates throughout the day. See “Managing Exported Coverage Data Files” on page 231 for information about working with these files.

3. Locality can retain an exported data file for up to 30 days. Under Exported Files, select how many days Locality should wait before automatically deleting an export file.

Note: Locality’s automatic backup process does not include the exported coverage data files in the backup. The files listed under Exported Files will not be available for Locality’s database restore process.

Managing Exported Coverage Data Files

To view coverage data export status


2. The Active export table shows the current size for today’s export file and the time it was last updated.

Throughout the day, Locality updates the active CSV file with collected coverage data. Shortly after midnight, the previous day’s exported coverage data is finalized and the CSV file is saved in a ZIP file named LocalityExport.<year-month-day>.zip (for example, LocalityExport.2015-04-22.zip).

To download or delete coverage data files




2. All available coverage data .zip files are listed under Exported Files:

Working with Coverage Data

When Locality is configured to export coverage data, it produces a daily CSV formatted file. The exported data consists of geo-tagged data segments that contain fields with coverage data values.

About Data Segments

Each row in the CSV file constitutes a segment, which is a basic block of collected Locality data with the following characteristics:

Segment: A segment represents a continuous period of time during which core network parameters are unchanged.

° Core network parameters: These are network technology and Locality signal quality category (Locality SQ).

° Location: A segment is described by start and end points. If the segment is located, then start and end points also have associated location information. A located segment is represented by a straight line on the map.

Consider the “Weight” of a Segment

The weight of a Locality segment is the number of samples that contributed to the creation of this segment. Every 5 seconds, the Locality agent collects sample data. One or more samples can contribute to the segment.

Suppose that for the same location you have two segments: A and B. In segment A the reported network technology is LTE. In segment B the reported network technology is 3G. Weight will help you decide which segment is more representative for the location.

Coverage Data Dictionary

When Locality is configured to export coverage data, it produces a daily CSV formatted file. Each row in the CSV file represents a data segment that contain fields with identifiers, coverage data values, location information, and sample counts. The following table describes these fields, which are listed in order (first to last) of position within the segment:

Option Description

Name The export file name, which identifies the date on which the coverage data was received by Locality server and added to the CSV file.

Size The size of the zipped export file in megabytes.

Expires The date on which Locality will automatically delete this data file.

Action Click an icon to manually download or delete this data file:

Download the coverage data .zip file.

Delete the coverage data file.

Field Name Data Type Max Length Description

User Name Text 256 User name associated with the device

Device Name Text 64 Device name

Locality UID Text 32 Universal identification code assigned to this device by Locality

Mobility PID Text 32 Permanent identification number assigned to this device by Mobility



IMEI Hex Number 17 International Mobile Equipment Identity (GSM network)

A type of adapter identifier associated with the device.

ESN Integer 8 Electronic Serial Number (CDMA devices)


MEI Hex Number 14 Mobile Equipment Identity (CDMA devices)


Phone Number

Integer 64 Phone number. The phone number data is normalized: dashes and leading + are removed. For example: 2065551234

Start Timestamp

Date Time 19 Start timestamp of the segment

This is a Coordinated Universal Time (UTC) value in format yyyy-mm-dd hh:mm:ss

End Timestamp

Date Time 19 End timestamp of the segment

This is a Coordinated Universal Time (UTC) value in format yyyy-mm-dd hh:mm:ss

Start Latitude

Decimal 11 Start latitude of the segment. For example: 47.654321

Used in combination with the End Latitude, Start Longitude, and End Longitude values to specify the geographic location where the data was collected.

If the value is 0, there was no GPS information available when this signal quality/coverage data was collected.

End Latitude Decimal 11 End latitude of the segment. For example: 47.656789

Used in combination with the Start Latitude, Start Longitude, and End Longitude values to specify the geographic location where the data was collected.


Start Longitude

Decimal 11 Start longitude of the segment. For example: -122.345432

Used in combination with the Start Latitude, End Latitude, and End Longitude values to specify the geographic location where the data was collected.





Managing the Locality Database The Locality database stores all the data collected by Locality agents and Locality configuration settings:

Locality server: During Locality setup, you choose locations for database-related files, and you specify the database port (the default is 3306). To modify the database port and locations for logs and backups, use the Locality Configuration Wizard; see “Changing the Locality Database (Locality Server)” on page 239.

End Longitude

Decimal 11 End longitude of the segment. For example: -122.341234

Used in combination with the Start Latitude, End Latitude, and Start Longitude values to specify the geographic location where the data was collected.


Number of Samples

Integer 3 Number of samples in the segment

Used to determine the weight of the segment. See “Working with Coverage Data” on page 232.

RSSI Integer 4 Received Signal Strength Indication

RSRP Integer 4 Reference Signal Received Power

SINR Integer 4 Signal to Interference plus Noise Ratio

RSRQ Integer 4 Reference Signal Received Quality

Locality SQ Integer 3 Locality Signal Quality

Signal quality is determined by a NetMotion Wireless proprietary process that takes into account multiple variables such as field strength, signal-to-noise ratio, and technology type.

For coverage, Locality calculates signal quality by adding the measured signal quality for each agent sample within a segment.

Locality SQ is represented as a number from 0 - 101. The values are categorized as follows:

Excellent = 81 to 100

Good = 61 to 80

Fair = 41 to 60

Weak = 21 - 40

Very Weak = 1 to 20

No Signal = 0

Unknown = 101

Technology Type

Text 256 Network technology type

Home Carrier

Text 256 Home carrier name

Current Carrier

Text 256 When there are multiple carriers, this is the name of the current one




Locality Cloud: The NetMotion Wireless Cloud Services team performs all database management services for your Cloud server.

To maintain the highest level of operating performance, daily database maintenance is automatically performed and Locality data, licenses, and security certificates are backed up. The maintenance process should be scheduled for a time when Locality system activity is at its lowest (the default is 2:00 AM local server time).

By default, the Locality database retains up to 180 days of data. For details about the granularity of data provided in maps and reports and how long a given level of detail is available see “Data Availability in Maps and Reports” on page 239.

Reviewing the Status of the Locality Database

The Locality console Status page summarizes the status of your Locality database: how much disk space it is using, and what the status is on backups.

Getting there: Log on to the Locality console as an administrator and go to System > Status.

Disk Drive Usage

It’s important to keep an eye on the size of your database: if the remaining disk space is too low, the server will stop accepting data from Locality agents.

System Backup

This section shows the status of the most recent backup of Locality databases. Database backup is a background process, so console users can continue to work with report and map data with no disruption.

Item Description

Disk usage Adequate disk drive space —A green icon indicates that there is adequate space available on the drive.

Insufficient disk drive space—A red icon indicates that there is not enough available disk space for the Locality database.

When database disk space is too low, the server stops accepting data from Locality agents. Locality agents retain existing data and continue to collect new data. Once the server disk space problem is resolved, the server accepts the data that has been accumulating on the Locality agents.

Status Lists the number of gigabytes free, the total size of the drive, and the percentage of available space.

Item Description

Health and status Provides details about current database backup status:

Successful database backup completed at the reported date and time. Typically, the timestamp indicates when the last scheduled maintenance backup completed.

Database backup failed. Check the System Logs tab for error messages detailing the cause of the failure.

A spinning icon indicates that a database backup is in progress. During that time, reports continue to use the existing data set.

A Locality database backup does not yet exist.

Start Backup (Locality server only) To start a database backup immediately, click the Start Backup button.



Once your Locality server and agents are set up and active, there is a short interval before data collected by Locality devices is available in the Locality console. During that time, the console report tabs will show No data available. This is because data collected from Locality agents must be processed before being included in maps and reports.

While a Locality agent is active, it collects data samples every 5 seconds and sends data to the Locality server every 30 minutes:

If the agent enters hibernate or suspend mode during this 30-minute interval, the collected data is held. When the agent resumes activity, it begins a new 30-minute collection interval, then sends all accumulated data (including the data collected prior to hibernation) to the server.

The server then processes the new data. Once processed, the data is made available to Locality maps immediately. Reports are updated with the processed data on an hourly basis.

About Automatic Database Maintenance

In the event of a system failure, Locality database maintenance functions make it possible to restore all data from a known point. By default, Locality performs a daily backup of the Locality databases at 2:00 AM and (as an added measure of safety) archives the most recent backup.

Daily database maintenance includes a combination of the following tasks, depending on how the server is configured:

A full database backup, which includes Locality data, licenses, and security certificates.

For Locality server, the location of database backup and archive folders is set in the Configuration Wizard when you first install, and can be re-configured later using the same wizard. See “Managing Backup and Archive Folders” on page 256.

Database archiving.

For details about the granularity of data provided in maps and reports, and how long a given level of detail is available, see “Data Availability in Maps and Reports” on page 239.

Backing Up the Locality Database

To make sure that you can restore all system data back to a known point in the event of system failure, Locality performs a daily backup of the Locality database, licenses and security certificates, and (as an added measure of safety) archives the most recent backup. During a backup, the existing database is available for use in console maps and reports. New agent data is queued and then added when the database backup process completes.

Locality’s automatic backup process does not include Coverage Data Export files in the system backup. The Coverage Data Export files will not be available for Locality’s database restore process.

Locality Server

See “Restoring the Locality v3.x Database (Locality Server)” on page 238 for information about using your backup.

To manually start a Locality database backup

1. Log on to the Locality console as an administrator.

2. Go to System > Status.

3. Scroll the Status page to show the System Backup section.

4. Click Start Backup.



Managing Backup and Archive Folders (Locality Server)

In a small Locality deployment (with 1,500 Locality agents or fewer), best practices dictate that database-related files be stored on a separate physical drive on the hosting computer.

In a medium or large Locality deployment, database-related files must be stored on a separate physical drive on the hosting computer

When Locality is deployed on a virtual machine, store the Locality database data files on a separate virtual volume on the hosting computer. The database backup, archive, and transaction logs should go onto another separate virtual volume on the hosting computer.

During automatic database maintenance, Locality data, licenses, and security certificates are backed up. By default, the database backup files and the archive files are stored in separate folders on the computer that hosts all Locality server components. To minimize downtime in the event of system failure, store the backup and archive in different volumes on a separate physical drive (or separate drives) on the hosting computer.

The location of database backup and archive folders is set in the Configuration Wizard when you first install, and can be re-configured later using the same wizard. See “Changing the Locality Database (Locality Server)” on page 239.

Use the following guidelines when specifying database backup and archive folders:

Verify that the backup path is a writable location: Locality will be denied access if there is a write permission restriction. In addition, the operating system may have restrictions that prevent a backup from occurring.

Do not use a location that is directly off of the root directory (for example, C:\). Make sure there is enough disk space to cover 1.5 times the anticipated database size; if

archiving is enabled, increase this figure to 2.5 times the anticipated size.

° Database log folder must be on the computer hosting the database. A volume on a separate physical drive is recommended. We recommend that you store Locality logs in the default location so the logs are with the MySQL files (for example: <drive>:\ProgramData\NetMotion Wireless Locality Server\MySQL\Log).

° Database backup folder must be on the computer hosting the database. A volume on a separate physical drive is recommended.

° Database archive folder must be on the computer hosting the database. When a new backup is created, the previous backup is stored here. A volume on a separate physical drive is recommended.



Restoring the Locality v3.x Database (Locality Server)

By default, Locality performs a daily backup and archiving procedure, as described in “Backing Up the Locality Database” on page 236. In the event of a system failure or when you need to move your deployment to new hardware, you can run the Locality Configuration Wizard to restore all system data using the backup Locality created.

Note: Locality’s automatic backup process does not include Data Export files in the system backup. The Data Export files will not be available for Locality’s database restore process.

During the restore process:

The Locality server is offline. Locality agents are not able to send data to the server. Collected data is held by the agents until the server comes back online.

The Locality console is unavailable. The restore process overwrites the current database.

After the restore process:

You cannot see report data that is older than 180 days: By default, Locality’s automatic purge process deletes all database records that are more than 180 days old. This means that if you restore a database that contains data older than 180 days, you will lose the outdated records as the purge proceeds.

To restore a Locality database backup

1. Start the Locality Configuration Wizard.

2. On the Introduction panel, click Next.

3. On the Configure Locality Database panel, accept the defaults or specify new locations for the v3.x logs, backup, and archive files. Click Next.

4. On the Update Locality Database panel, select Restore a backed up database and click Next.

5. On the Restore Locality Database panel, specify the location of the Locality database backup folder that you want to restore; it must be on the computer hosting the Locality server. The default location is the folder that you configured for automatic Locality database backups (for example: D:\ProgramData\NetMotion Wireless Locality Server\Backups).

6. After identifying the location of the database backup you want to restore, click Next to begin the restore process and confirm that you want to overwrite the existing database. The Locality



server and web applications are stopped while the specified database backup is restored, and then they are restarted.

7. When the database restore process is complete, the Configuration Wizard moves on to the Add Analytics Data panel. Existing configuration settings for Mobility Analytics Module, iOS Inventory, Client Authentication, and Alerts and Messaging are restored along with the database, so no additional configuration is needed. Click Next to accept the default settings in the remaining wizard panels, continue through System Verification and click Done to close the wizard.

Changing the Locality Database (Locality Server)

This section describes how to change database settings—the database port and the location of database log, backup, and archive folders—and the location of the database.

To change the Locality database port or file locations

During this procedure the database is unavailable for a brief period. Agent data is queued and added when the database is available again.

1. Run the Locality Configuration Wizard. In the Introduction panel, click Next.

2. (Optional) Change Port to specify a new TCP port number for communication with the Locality database.

3. (Optional) Change one or more of the database folder locations; for guidelines see “Managing Backup and Archive Folders (Locality Server)” on page 237.

4. Click Next.

5. In the Update Locality Database panel, select Update your Locality database.

6. Click Finish to perform the database update and system verification. Or, click Continue to move through the remaining Configuration Wizard panels and perform additional configuration tasks.

To change the Locality database location

The location for the Locality database is set when you install the product. To change it you must back up your database, uninstall and reinstall Locality, and then restore your database backup to a different folder on the same computer.

There is a server outage that begins when the Locality software is uninstalled and ends when the database is restored. During the outage, Locality agents are not able to send data to the server. Collected data is held by the agents until the server comes back online.

See “To keep the Locality server in place and change the deployment size” on page 65. Follow the procedure, skipping step 4.

Data Availability in Maps and Reports

By default, the Locality database collects up to 180 days’ worth of data. The reason for establishing a cut-off is true for all databases: as they grow, performance and availability are diminished, and backup and recovery times lengthen. Locality automatically purges expired data records (older than 180 days) throughout the day to ensure that the Locality database does not grow too large.

The following table shows the granularity of data provided in maps and reports and how long a given level of detail is available. The data retention rates for these items cannot be changed:

Data Format View by Hour View by Day View by Week View by Month

GPS Metrics report Last 30 days Last 30 days Last 30 days Not available

Dropped Connections report

Last 30 days Last 30 days Last 30 days Last 30 days

Mobile Diagnostics report

Mobile Diagnostics report data is not granular. Each report is available for 30 days from the time when it was received by the Locality server.



This table shows retention rates that can be changed. To shorten or extend the period of time for which data is retained for these items, contact NetMotion Wireless Technical Support:

Warning! Increasing data retention beyond the 180 day default may have a severe impact on the performance of your Locality server.

Managing Historical Data

If you have data retention and compliance requirements, you should have a data strategy in place before you reach the 30-day or 180-day mark. There are a few options for saving particular reports and maps:

Export report data in CSV, PNG, or PDF format (most reports can be saved in one or more formats, but not all).

Export map data in KML (Keyhole Markup Language) format or as an image in PNG format. You can configure Locality to generate a daily CSV file that contains detailed geo-tagged signal

coverage/quality data extracted from your Locality database. For details see “Exporting Coverage Data for Use in GIS Applications” on page 231.

Availability of Mobility Analytics Data

When you connect a Mobility Analytics Module to Locality, the oldest Mobility data that will be available to you in Locality reports begins with your Locality installation: in other words, only Mobility data collected after Locality is installed is available.

In a Mobility deployment, daily maintenance is performed automatically on the Analytics Module database to maintain the highest level of operating performance: outdated records are purged from the system, and the database is reorganized and backed up.

The time at which this maintenance occurs is configurable (the default is set to midnight). You may want to schedule the maintenance for a time when Locality system activity is at its lowest.

Locality can only monitor application usage under the following conditions:

° All data is going through the Mobility VPN tunnel back to the Mobility server; in other words, Mobility is not bypassed.

° Each Mobility client is using the same adapter as the one being monitored by Locality.

Maintaining the Locality/Mobility Analytics Database Connection

Locality and Mobility can use a configured database connection in order to integrate data from the Mobility Analytics Module into the Locality database. If you later move your Mobility Analytics Module to another computer, or (in the case of Locality server), you move the Locality server, you must re-establish the connection between Locality and the Analytics Module. See “When to Reset a Mobility Analytics Connection” on page 48.

Moving a Locality Deployment (Locality Server) When you move a Locality deployment to new hardware, you can direct the Configuration Wizard to restore an existing Locality database backup on the new Locality server.

Important configuration requirements:

If you are moving a Locality v3.x server that has client authentication enabled, you must configure the new host computer to use the same fully qualified domain name (FQDN) that the old host computer used. If the old and new server FQDNs do not match, your Locality agents will have to be re-provisioned.

Data Format View by Hour View by Day View by Week View by Month

All other reports Last 30 days 180 days 180 days 180 days

Device Map 180 days 180 days 180 days 180 days

Coverage Map Not available 180 days 180 days 180 days



If you are moving a Locality v3.x server that has Mobility Analytics integration enabled, you must reset the connection between Locality and the Locality Connect for Mobility web client. This involves configuration activity on both the Locality and Mobility servers. See “When to Reset a Mobility Analytics Connection” on page 48 for details.

Locality Move Work Flow

To move your Locality v3.x server deployment to new hardware, you must:

a. Back up the existing Locality database.

b. Copy the backup folder to a location that is available to the new host computer.

c. Turn off the old server.

d. Turn on the new server. Rename the new host computer to the fully qualified domain name (FQDN) used on the old server. The FQDN should stay the same when moving from one host computer to another.

e. Install the Locality v3.x server on the target computer.

f. In the Configuration Wizard, specify the FQDN of the Locality server, which should match the FQDN used by the old Locality server. This allows all previously provisioned Locality agents to continue using their existing settings for server address and client authentication.

g. Run the Configuration Wizard again to restore the database backup on the target computer. If you renamed the target server to match the FQDN of the server that the database came from, Locality agents can begin reporting to the new server. If the old and new server FQDNs do not match, your Locality agents will have to be re-provisioned.

For a list of additional procedures that involve moving or restoring your existing Locality database, see “Changing Your Locality v3.x Server Deployment” on page 63.

To move your Locality v3.x deployment to a new computer

1. Complete the “Locality Server Pre-Install Check List” on page 30 to make sure your new (target) computer is configured properly.

2. On the existing v3.x Locality server, make a database backup. See “To manually start a Locality database backup” on page 236.

3. Make the database backup folder available to your new computer. For example, on your new Locality host you might connect a physical drive that contains this data, or restore a tape backup to the host’s hard drive or to a network drive.

4. Shut down the old Locality server.

When the server is turned off, agent devices will collect and hold data until they are able to connect to the new target server. You should incur minimal agent data loss due to the hardware change.

5. Your Locality agent devices are configured to connect to the IP address or server name that belonged to your old Locality server. Use network management tools to rename the new host computer to the fully qualified domain name (FQDN) used by the old Locality server.

Important: If you are moving a Locality v3.x server that has client authentication enabled, you must configure the new host computer to use the same fully qualified domain name (FQDN) that the old host computer used. If the old and new server FQDNs do not match, your Locality agents will have to be re-provisioned.

6. Install Locality server on the target computer. See “To install the Locality server” on page 33.

7. When Setup completes, the Configuration Wizard starts automatically.

a. Enter the fully qualified domain name (FQDN) of the Locality server host computer as specified in step 5. Click Next.

b. Specify the database port and the locations on the disk drive(s) for storing Locality logs, and backup and archive database files.

c. Click Next. The wizard sets up an empty database, which you will overwrite in step 8.



d. No additional configuration is needed. Accept the default settings and click Next. On the Locality License panel, select Add the license key later in the Locality console. Click Next to proceed through remaining panels and Done to close the wizard.

e. If prompted, restart the computer.

8. Re-run the Configuration Wizard to restore the database backup you made in step 2; see “To restore a Locality database backup” on page 238.

9. Existing configuration settings for Mobility Analytics Module, iOS Inventory, client authentication, and alerts and messaging are restored along with the database.

To continue using the settings provided in the restored database, select I want to use the existing <feature> settings and click Next in the remaining wizard configuration panels.

10. Continue through System Verification and then close the Configuration Wizard. You may be prompted to reboot the system.

To make the new Locality console available to administrators and users

On the new host computer, configure access to the Locality console. See “Assigning Groups or Users to a Console Access Role” on page 198.


Chapter 14 - Troubleshooting Locality | 243

Chapter 14Troubleshooting Locality

If you have trouble installing or using Locality, the information in this section can help you identify and resolve the problem. There are also resources in the Technical Support area of our web site:

www.netmotionwireless.com/support

Troubleshooting the Locality Server Use this section to troubleshoot problems with the Locality server software.

Testing Locality Agent/Server Communication

As part of Locality agent Setup and the data collection process, the Locality agent automatically connects to the Locality server and attempts to communicate. At any time, you can test the communication from the agent to the server yourself.

To test server communication from a Locality agent

1. Open the Locality agent.

2. The Locality agent device immediately attempts to communicate with the Locality server when you do the following:

° Windows: On the Status tab, click the Test server communication button. ° On Android or iOS, tap directly on the last communication time.

3. Communication test results:

° If communication succeeds, the last communication time is updated.° If communication fails, you will see an error message. For example:

Failed to communicate with the Locality server at 4/24/2015 11:49:40 AM. The server name or address could not be resolved.

4. If you see a communication error message, verify that you have specified the right server address and configured the other settings properly. Then test server communication again.

For additional information about communication errors, see “Server Status Messages (All Platforms)” on page 262.

Working with Locality System Logs

Error and information messages about the Locality server and console are stored in the Locality database. You can use them to troubleshoot problems with your deployment.


http://www.netmotionwireless.com/support

244 | Chapter 14 - Troubleshooting Locality

In the Locality console, go to System > System Logs to see messages logged in the last 40 days. Controls are available to filter log data by time interval, log level, specific message text, or by the name of the component/subsystem that logged the error. In the Message column, you can enter a text string to search for messages that contain the string. The Logger column allows you to use a text string to find messages logged by a specific system component.

Select a Timestamp option to limit the message list to a specified time interval. Click Level to select which type of log messages you want to view:

Locality Server Status Messages

The following table shows messages that appear in the Locality console in the form of a banner near the top of the page or a pop-up message:

Log Level Description

All Shows all messages present in the log within the time interval specified in Timestamp.

Error Shows log message generated by error conditions experienced by the Locality server. Examples of this sort of event are a database restore failure due to lack of space on the storage drive, the provisioning gateway receiving an invalid request, or an error getting data from the Analytics database.

Info Shows log messages of broad interest that are not error conditions. Examples of this sort of event are a configuration change, system startup or shutdown, and database maintenance status.

Locality Console Status Message Description

An error occurred communicating with the Locality database. If this is unexpected, contact NetMotion Wireless Technical Support.

After you have made your choices in the selection pane for the Coverage Map or Device Map, the map displaying your selections is rendered. If this takes longer than ten minutes, this message is displayed.

To view this report, Locality must be configured to connect to a Mobility Analytics database.

The report presents data from a Mobility Analytics database. If the Locality server is not configured to connect to an Analytics database, this status message displays.

Your Locality agents require authentication codes.

Your Locality server is configured to require client authentication, so your Locality agents must be configured with client authentication codes.

Locality authentication codes are created in the Locality console and then distributed to Locality agents for provisioning purposes.

Click the “authentication codes” link to open the Client Authentication page. There you can create new authentication codes, which your Locality agents must have to implement client authentication. See “Creating Client Authentication Codes” on page 217.

No connection You may see this error when you try to select data or move to a different report after a period of inactivity. Dismiss the message, log off of the Locality console, and then log on again.

In rare cases, logging back on does not solve this problem. In that case, delete your browser cookies, then log off and log back on.



Gathering Locality Server Diagnostic Information

(Locality server only) If you contact NetMotion Wireless Technical Support, you are sometimes asked to gather diagnostic information about the Locality server. There is a convenient way to do this, described here.

To gather diagnostic information about the Locality server

1. Go to Start > Locality Support Data.

One or more drives are running low on disk space.

If one or more of the drives Locality is using is low on available space, this warning message displays.

On the System > Status page check the Disk Drive Usage to see the state of all Locality disk drives. For example:

Locality is best viewed with a screen resolution of 1280 x 800 or higher.

Locality reports and maps are designed for a resolution of 1280 x 800 or greater; at a lower resolution the information on the screen is not sharp.

The APNS certificate will expire on <date and time>.

This banner begins to appear at the top of console System pages 30 days before your Locality server Apple Push certificate will expire:

Locality server: For certificate renewal information, see “Managing the iOS APNS Client Certificate” on page 221.

Locality Cloud: Contact NetMotion Wireless Technical Support.

Locality Console Status Message Description



2. Specify the items you want to include—typically Technical Support or your Help Desk will offer guidance here.

3. Data is collected from various sources and archived in a .zip file.

4. After you have created and saved the Locality Support Data report, disable Debug Logging to improve performance.

Troubleshooting the Connection with Mobility Analytics Module

If you are using Mobility v9.50 or later with the Mobility Analytics Module, Locality can draw on its data to provide additional information for understanding how applications and devices are using resources on your mobile wireless network. Establishing a connection between Locality and the Mobility Analytics Module is described in “Integrating Mobility Analytics Data into Locality Reports” on page 44.

Upgrading or moving your Locality server or Mobility Analytics Module may break the secure connection between Locality and Mobility Analytics.

Detecting a Locality/Mobility Analytics Connection Failure

1. To check the state of the Mobility Analytics Module’s connection with the Locality server, go to Locality console > System > Status.



2. Under System Health, find Locality Web Service and check Status:

3. Scroll down to check the Mobility Analytics area:

If a Mobility Analytics area is not shown on the Status page, then Analytics data integration is not enabled on the Locality server (Locality web service status shows Not Configured). To add Analytics data:

° Locality server: See “Integrating Mobility Analytics Data into Locality Reports” on page 44. ° Locality Cloud: Contact the Locality Cloud service team for assistance.

Status Meaning

Not Configured The Locality is not configured to add data from a Mobility Analytics Module:

Locality server: You must run the Locality server Configuration Wizard to enable Mobility Analytics data integration; the configuration wizard then starts the Locality web service on the Locality server host computer. See “Setting Up Locality Connect for Mobility” on page 45.

Locality Cloud: Contact NetMotion Technical Support to request that this feature be enabled.

Running On the Locality server, the Locality web service is enabled and running. This service will support communication with a properly configured Locality Connect for Mobility web client that is running on your Mobility Analytics server.

Service is Unavailable The Locality web service is not running on the Locality server. This prevents the Locality Connect for Mobility web client on the Mobility server from sending Analytics data to Locality.

Locality server: You must restart the Locality web service. Check IIS > Application Pools and Sites > Locality Web Service.

Locality Cloud: Contact NetMotion Technical Support to request that the Locality web service be restarted.

Status Meaning

Locality Connect for Mobility is not configured

Locality Connect for Mobility provides a web client that is used to send Mobility analytics data to your Locality server.

Check the following:

On the Mobility analytics server, is the Locality Connect for Mobility web client installed and configured correctly?

Run the Locality Connect for Mobility Setup program to configure a connection to the Locality server. You must also provide a password to the Mobility analytics database on the Mobility host server. The wizard will test the connection to the Locality server and to the Mobility Analytics reporting database.

For details, see “Setting Up Locality Connect for Mobility” on page 45.



Troubleshooting the Locality Console The Locality web console allows you to analyze and report on the performance of your mobile deployment. This section covers browser configuration.

Finding Server Addresses and Version Information

The Locality console System > About page displays version and copyright information about your NetMotion Wireless Locality software. It also displays the Locality server's IP address and serial number.

Mobility analytics (server: <servername>) communication is healthy

The Locality server and the Locality Connect for Mobility web client installed on the Mobility analytics server are communicating successfully. Locality reports contain the most recent analytics data available.

Mobility analytics (server: <servername>) communication is not healthy

The Locality Connect for Mobility web client installed on the Mobility analytics server has not sent data to the Locality server for 3 hours or longer. Locality reports do not contain the most recent analytics data available.


Did you move either Locality or Mobility to a new host computer? If so, the secure connection between your Locality server and the Mobility Analytics Module database must be reset. See “When to Reset a Mobility Analytics Connection” on page 48.

Under System Status, check the status of Locality Web Service. If status is Service is unavailable, the web service must be restarted:

° Locality server: Check IIS > Application Pools and Sites > Locality Web Service.

° Locality Cloud: Contact NetMotion Technical Support.

On the Mobility analytics server, is the Locality Connect for Mobility service running? If not, restart this service.

Is there network connectivity between the Mobility and Locality servers?

Look at the system logs for both servers.

Mobility analytics (server: <servername>) is communicating, but data is not yet current

Locality can report on Mobility analytics data that is up to six months old. Historical data is pulled sequentially from the analytics database, starting with the oldest data and continuing until the most recent data is obtained.

This message indicates that Locality Connect for Mobility is actively retrieving and sending analytics data to the Locality server, but has not finished processing the whole six-month backlog of collected data. Reports that include analytics data will not have current values until all analytics data in the backlog is sent to and processed by Locality server.

Status Meaning



Coverage Map: No Data Found in Mapping Area

When you first open a coverage map (before selecting a location), any parts of the map that contain data are dark green. As you zoom in you may see the following message at the top of the map area:

No data was found in the mapping area within the selected time range.

This happens if you have no carriers or technology types selected in the Display Options area of the selection pane. In other words, the lack of data is not always a result of the selected time range: it could be that no items are selected.

Data Display Anomalies in Device Maps

Many things can interfere with the signal between the GPS receiver and a GPS satellite. For example:

Weather—Storms with heavy rainfall and lightning. Tall buildings—Concrete, steel, and other solid construction materials. Terrain—Mountains, hills, and dense foliage.

External conditions (geology, buildings, weather, and so on) may cause a GPS receiver to produce faulty location information. The performance of GPS receivers and antennas varies widely by manufacturer and model.

Locality attempts to filter out GPS data where the receiver reports that the location data it gathered has low precision. If the receiver indicates that the data is of medium or high precision, Locality accepts the data. But our experience and testing has shown that the quality of GPS receivers varies in terms of reliability, sensitivity, and correct calculation of precision.

Occasionally a device map may show a nonsensical device trace route. For example:

A route extends over a body of water when the device was in fact on land A route tracks parallel to the actual course of the device but is several miles off A route is attributed to a stationary device

The device trace routes you see rendered on Locality device maps are only as good as the NMEA or TAIP data (GPS location information) provided by the active GPS receiver. Stand-alone GPS receivers that use the NMEA 0183 standard or TAIP protocol may require configuration changes to produce high-precision data. For details, see “Recommendations for Standalone GPS Receiver Configuration” on page 116.

If your standalone GPS receiver supports both TAIP and NMEA protocols, we recommend that you configure it to use NMEA for highest GPS quality. Locality supports TAIP, but NMEA is better because it provides more precise location data.

Locality accurately renders the raw location data that is reported by the GPS receiver on the device running the Locality agent. But if the GPS receiver produces data that is imprecise and misleading, the resulting Locality maps will reflect the inaccuracies.

Not all GPS receivers and device antennas perform equally well. Adapters with integrated GPS may do a poor job of interpreting received GPS data; dedicated units tend to be better, especially if they include a quad helix antenna mounted at proper orientation.

“Missing” Device

If data was collected from Locality agents without location data, the reports will show data about those devices, but the Device Map will not. See “Locality Agent Not Reporting Location (Windows)” on page 252 for more details.

“Missing” Map Data

There are a few reports—including Network Usage > Users and Dropped Connections > Trends—that include a column labeled Map Data, which indicates whether the database contains map data (GPS location information) that will allow you to see a device trace in the Device Map. A No in the Map Data column can be caused by any these conditions:



The GPS location data was collected more than 180 days ago. Locality retains reported device GPS location information for 180 days, after which it is purged. You cannot see a device trace that is older than 180 days.

The GPS receiver on the device did not provide any location data. See “Locality Agent Not Reporting Location (Windows)” on page 252 for troubleshooting information.

There is no GPS receiver on the device.

Troubleshooting the Locality Agent NetMotion Wireless Locality provides comparable functionality for Locality agents running on the Windows and Android platforms, and an iOS app that enables you to run Mobile Diagnostics. There are different troubleshooting tools, depending on the sort of issue you encounter:

For issues having to do with the Locality product—for example, having trouble with the connection to the Locality server, or understanding a status message—refer to the topics in this section.

Diagnostics is a tool for understanding and helping you address device or connectivity issues encountered in the field, including ones that do not involve Locality. A series of tests are run on the Locality agent and a full report and probable root cause is shown. All results can be viewed on the device in question and by the Locality administrator in the console. See the following, depending on the agent operating system:

° “Locality Agent Mobile Diagnostics (Windows)” on page 274° “Locality Status and Diagnostics (Android)” on page 276° “Locality Agent Diagnostics (iOS)” on page 280

Collecting Locality Support Data is something a user is usually requested to do when working with NetMotion Wireless Technical Support. See the following, depending on the agent operating system:

° “Collecting and Sending Locality Support Data (Windows)” on page 255° “Collecting and Sending Locality Support Data (Android)” on page 259° “Locality Agent Settings (iOS)” on page 283

Troubleshooting information in this section is organized by platform:

Troubleshooting the Locality Agent (Windows)

The Locality agent Status tab displays information about how the Locality agent is functioning and posts messages indicating any issues with adapters or GPS receivers that have been detected.

If mobile workers experience network problems they can generate a diagnostic report and view the results, which are also available to the Locality administrator. Your Locality server must be licensed for the Mobile Diagnostics feature. See “Analyzing Mobile Diagnostics” on page 193 for more information.

Operating System Reference

“Troubleshooting the Locality Agent (Windows)” on page 250

“Troubleshooting the Locality Agent (Android)” on page 255

“Troubleshooting the Locality Agent (iOS)” on page 260

“Enrolling a Device in the Locality Inventory System (iOS)” on page 97

“To remove the Locality Inventory profile from an Apple device” on page 107

All “Locality Agent License Issues” on page 260

All “Configuring Agents to Accept Locality Server Certificates” on page 261

All “Locality Agent Status Messages” on page 261



The Locality agent uses a number of third-party items, such as the adapter and driver you are using for your carrier connection, a GPS receiver (optional), and a connection manager. For the agent to operate successfully, you must use validated third-party items. For details, see “Compatible Third-Party Network Adapters and GPS Receivers” on page 16.

Related Information

Locality Agent Cannot Connect (Windows)

The Locality agent automatically attempts to connect to the Locality server you specify during Setup or in the agent. If an agent cannot connect, you will see an error (for example, Failed to communicate with the Locality server) on the Locality agent Status tab. This may be a temporary issue. If the problem persists, try the following on the agent device:

Verify that a working network connection is available. Make sure the agent is using the correct address for the Locality server. The Status tab shows

the server address currently in use.

If the address is wrong, click the Configuration button and enter the correct fully qualified domain name or the IP address provided by your administrator in the server Address box. Click OK and then click Test server communication to confirm that the agent can connect to the server. For additional information, see “Server Status Messages (All Platforms)” on page 262.

If a message on the Locality agent Status tab indicates that the certificate authority is invalid or incorrect—for example, Untrusted server certificate (Invalid CA, Name mismatch)—click the Configuration button and clear the Require trusted server certificate setting. Click OK and then click Test server communication to confirm that the agent can connect to the server.

For more information, see “Configuring Agents to Accept Locality Server Certificates” on page 261.

If a message on the Locality agent Status tab indicates that the Locality service is not running, click the Start menu, search for “services” and open the Services program. Right-click the NetMotion Wireless Locality service and select Start or Restart.

Locality Does Not Detect A Network Adapter (Windows)

If Locality does not detect any supported network adapters on your system, the Locality agent Status tab posts this Monitored Adapters message: No adapters found. There are several possible reasons this message, including the following:


“Locality Agent Cannot Connect (Windows)” on page 251

“Locality Does Not Detect A Network Adapter (Windows)” on page 251

“Locality Agent Does Not Detect Trunk Modem (Windows)” on page 252

“Locality Agent Not Reporting Location (Windows)” on page 252

“Troubleshooting ‘No GPS Found’ Status (Windows)” on page 253

“Using Auto-Start to Keep the GPS Receiver Active (Windows)” on page 253

“Locality Agent Not Collecting Data (Windows)” on page 254

“Configuring an Adapter to Run in NDIS Mode (Windows)” on page 254

“Managing Locality Agent Log Files (Windows)” on page 254

“Collecting and Sending Locality Support Data (Windows)” on page 255






Remove and re-insert the adapter while Locality is running

When a network adapter is removed, it disappears from the Monitored Adapters list. A few moments after re-inserting the adapter, it is detected and its name appears on the Status tab.

Suspend/hibernate and resume the computer

Upon first resuming from suspend or hibernate, the network adapter is shown on the Status tab; it disappears momentarily and then reappears after a brief wait. This is expected behavior.

A SIM card is deactivated or missing. The adapter is in airplane mode.

Try the following:

Remove and reinsert your network adapter. Make sure that all drivers for your adapter are correctly installed by verifying that Windows

device manager shows that the adapter is working. Run the adapter connection manager to establish a cellular network connection. Reboot your agent device. Make sure your network adapter is on the list of supported adapters:

http://www.netmotionwireless.com/locality/requirements

For remote broadband adapters, see “Locality Agent Does Not Detect Trunk Modem (Windows)” on page 252.

Locality Agent Does Not Detect Trunk Modem (Windows)

By default, support for remote broadband adapters is disabled. From the Locality agent Status tab, click Configuration to check the configuration settings. For instructions on how to specify and configure a remote broadband adapter on the Locality agent, see “Configuring Locality to Use a Remote Broadband Adapter” on page 117.

If your deployment includes NetMotion Mobility, verify that the appropriate passthrough rules are in place on the Mobility server. See “Passthrough Rules for Mobility Clients” on page 76 for details.

Locality Agent Not Reporting Location (Windows)

If the GPS receiver for a device running the Locality agent is not working properly, everything except location data is still collected and transmitted to the Locality server. This data appears in reports, but—without location data—cannot be included in a Coverage Map or Device Map. For an example of a report that includes all data, with and without map data, see Dropped Connections > Trends.

To confirm that the GPS for a Locality device is working

1. Start the Locality application on the agent device.

2. From the Status tab, check the GPS section to see if Locality has detected the presence of a GPS receiver.

Known—Indicates Locality has detected the GPS receiver, which has a position fix and is able to report location data.

No GPS found—Indicates Locality could not detect a GPS receiver. See “Troubleshooting ‘No GPS Found’ Status (Windows)” on page 253.

Insufficient GPS signal to determine location—Indicates that Locality has detected the GPS receiver, but the received GPS signal is not sufficient to report a precise position, or the signal is not available (usually a situation where the GPS receiver is inside or blocked by large buildings outside).


° GPS receivers—whether integrated, remote, or standalone—must be able to lock onto global positioning satellites in order to report a position. Take your agent device outside,


http://www.netmotionwireless.com/locality/requirements


with the GPS receiver connected and running, and wait for a few minutes to obtain a satellite fix. It may take up to 10 minutes for the receiver to obtain a location fix.

° Locality uses the first GPS receiver that it detects. If multiple GPS receivers are available on your agent device, you may have to specify your preferred GPS receiver manually to ensure that Locality uses the best one available. See “Specifying a GPS Receiver” on page 115 for more information.

Troubleshooting ‘No GPS Found’ Status (Windows)

If the Locality agent Status tab shows No GPS found, Locality could not detect a GPS receiver. Check the following:

If you are using a remote broadband adapter:

Ensure that the laptop firewall is configured to permit traffic on the port(s) you are using for communication with your adapter. If the Status tab displays the following error message, the Locality agent cannot connect to the remote broadband adapter.

To see the default settings for communication with supported adapters, go to “Deploying Locality Agent with a Remote Broadband Adapter” on page 73 and follow the link for your adapter type.

From the Locality agent Status tab, click Configuration to check the configuration settings:

° Verify that Auto-start integrated GPS receivers is selected.° In the Adapter drop-down list, choose your remote broadband adapter. ° If your adapter uses non-default settings (for example, a different port), select Use

custom settings and specify the correct credentials and address/port. To see the default settings for communication with supported adapters, go to “Deploying Locality Agent with a Remote Broadband Adapter” on page 73 and then follow the link for your adapter type.

If you are not using a remote broadband adapter

Make sure you are using an integrated or stand-alone GPS receiver that uses the TAIP or NMEA 0183 protocol. If you are using a non-standard GPS receiver, it may be necessary to manually set the COM port’s baud rate to a different value; see “Locality Agent Configuration (Windows)” on page 267 for a description of the Serial connection setting.

If you have an agent device or adapter with an integrated GPS receiver, you may have to unlock the GPS receiver using the connection manager software or custom software on the device.

If you have an adapter with an integrated GPS receiver, such as a wireless card, you may have to select the auto-start option in the Locality agent configuration dialog box. See “Using Auto-Start to Keep the GPS Receiver Active (Windows)” on page 253 for more information.

You may need to select an alternate GPS receiver. See “Specifying a GPS Receiver” on page 115 for more information.

If you know that your GPS receiver is working but Locality does not find it

Check to see if you are running another application that communicates directly with the GPS COM port. If this is true, either reboot the computer, or stop the application (or disconnect it from the GPS COM port) and wait a few minutes for Locality to rescan and detect the GPS. The Locality rescan or system reboot permits the Locality port sharing service to start, so both Locality and the GPS application will be able to use the same COM port.

Using Auto-Start to Keep the GPS Receiver Active (Windows)

To gather location-related data, Locality must communicate with an active GPS receiver available to the mobile device. The agent has an auto-start setting designed to keep a GPS receiver that is integrated with the network adapter or remote broadband adapter working continuously, meaning that Locality can collect location information more reliably.



The setting Auto-start integrated GPS receivers does not affect stand-alone GPS devices.

Note: Locality agents that use a remote broadband adapter, such as a Sierra Wireless AirLink trunk modem, should always select this check box.

When enabled, Locality starts the adapter’s integrated GPS receiver automatically in these situations:

When the agent device is turned on After suspend/resume After hibernate/resume After the adapter is removed and re-inserted

To change the auto-start setting, follow the procedure in “Specifying Auto-Start for Integrated GPS Receivers” on page 116.

Locality Agent Not Collecting Data (Windows)

Sometimes the Locality agent is unable to collect data due to a conflict in the agent system, such as the following:

Adapter is running in RAS mode when NDIS mode is required. Running the adapter in RAS mode prevents Locality from correlating Locality agent data with Analytics data for the same device. See “Configuring an Adapter to Run in NDIS Mode (Windows)” on page 254 for details on switching modes.

Incompatible connection manager or adapter. The Locality Network Adapter and GPS Receiver Matrix identifies the adapter, GPS receiver, and connection manager combinations that have been validated in our test lab. See “Compatible Third-Party Network Adapters and GPS Receivers” on page 16.

Adapter is detected but Locality cannot collect data from it due to an error.

For more about status information, see “Locality Agent Status Messages” on page 261.

Configuring an Adapter to Run in NDIS Mode (Windows)

Locality does not support adapters running in RAS mode. To ensure the optimal conditions for data collection, the network adapter running on an agent device must operate in NDIS mode.

The connection manager application for your adapter may not identify the connection type as RAS or NDIS mode. The following names are equivalent:

RAS mode = Modem modeNDIS mode = LAN mode

The process used to switch between modes depends on the connection manager that you use. Some connection managers will not let you switch an adapter from RAS mode to NDIS mode while you are connected to the carrier. You have to disconnect the adapter first and then switch the mode and reconnect. The RAS mode option may not become available until you disconnect.

Notes

If you are running in RAS mode, you will see one of the following messages:

“This adapter is configured to run in RAS mode.”“Locality is not compatible with this adapter when configured in RAS mode.”

Connection manager upgrades (or adapter reactivation) can sometimes reset an adapter to RAS mode. In this case, the adapter must be switched back to NDIS mode manually.

Managing Locality Agent Log Files (Windows)

To troubleshoot issues regarding the Locality agent, you may have to increase the amount of information collected in the log files.

To set the level at which logs are collected

1. From the System tab in the Locality agent application, click the Configuration button.



2. From the Locality Configuration dialog box, under Logging, select the Enable verbose logging check box and click OK. The default location for log files on Windows XP is:

C:\Documents and Settings\All Users\Application Data\NetMotion Wireless Locality Client\Logs

For all other operating systems, the default location is:

C:\ProgramData\NetMotion Wireless Locality Client\Logs

Collecting and Sending Locality Support Data (Windows)

When NetMotion Wireless Technical Support is working with end users to resolve an issue with a Locality agent running on Windows, they may be asked to gather some Locality data for them. There is a convenient way to do this, described here—if needed, you can send these instructions to end users.

If you are licensed for Mobile Diagnostics and users run into network issues—for example, an application is not working, or there is no network access—you may want to have them run Mobile Diagnostics instead of (or in addition to) the Support Data report. For details about the built-in and optional custom tests you can run, see “Managing Mobile Diagnostics” on page 221.

To collect system information into an archive

1. In File Explorer, open the folder where the Locality agent is installed. The default location is C:\Program Files (x86)\NetMotion Wireless Locality Client.

2. Run the following batch file: SupportData.bat

3. This script gathers system information about the host computer and the installed Locality agent and adds it to an archive (.zip) file.

4. When processing completes, a File Explorer window opens the folder where the archive file is stored: C:\Users\<user.name>\Documents\LocalitySupportData_<yyymmdd-hhmmss>.zip

5. Send the support data ZIP file to NetMotion Wireless Technical Support.

Troubleshooting the Locality Agent (Android)

The Locality app Status screen displays information about how the Locality agent is functioning and posts messages indicating any issues with server communication or GPS location services. For details, see “Locality Status and Diagnostics (Android)” on page 276.

Related Information

Locality Agent Cannot Connect (Android)

The Locality agent automatically attempts to connect to the Locality server you specify in the agent. If an agent cannot connect, you will see an error (for example, Failed to communicate with the Locality server) on the Locality agent Status screen. Try the following:


“Locality Agent Cannot Connect (Android)” on page 255

“Locality Agent Not Reporting Location (Android)” on page 256

“Locality Agent Not Collecting Data (Android)” on page 257

“Conserving Battery Life (Android)” on page 258

“Collecting and Sending Locality Support Data (Android)” on page 259






Make sure the agent is using the correct address for the Locality server. Open the Locality app; the Status screen shows the server address currently in use.

If the address is wrong, tap Address and enter the correct fully qualified domain name in the server Address box. Tap OK and return to the Status screen. Check Last communication time to confirm that the agent is connected to the server. To force the agent to try to connect with the server, tap Last communication time. For additional information, see “Server Status Messages (All Platforms)” on page 262.

If a message on the Status screen indicates that the server certificate is not trusted, tap Settings. Does your site uses a signed certificate to secure connections to the server? ° If an untrusted server certificate is allowed, clear the Require trusted cert check box.° If your Locality server uses a signed server certificate from a certificate authority (CA),

select the Require trusted cert check box.For more information, see “Configuring Agents to Accept Locality Server Certificates” on page 261.

If a message on the Status screen indicates that the Locality service is not running, you must restart the Android device to enable the Locality service.

Locality Agent Not Reporting Location (Android)

If the GPS on a device running the Locality agent is not enabled or working properly, everything except location data is still collected and transmitted to the Locality server. This data appears in reports, but—without location data—cannot be included in a Coverage Map or Device Map. For an example of a report that includes all data, with and without map data, see Dropped Connections > Trends.

To confirm that the GPS for a Locality device is working

1. Start the Locality application on the agent device.

2. From the Status tab, check the GPS section to see if Locality has detected the presence of a GPS receiver.

Known—Indicates Locality has detected the GPS receiver, which has a position fix and is able to report location data.

No GPS found—Indicates Locality could not detect a GPS receiver. See “Troubleshooting ‘No GPS Found’ Status (Windows)” on page 253.

Insufficient GPS signal to determine location—Indicates that Locality has detected the GPS receiver, but the received GPS signal is not sufficient to report a precise position, or the signal is not available (usually a situation where the GPS receiver is inside or blocked by large buildings outside).


° GPS receivers—whether integrated, remote, or standalone—must be able to lock onto global positioning satellites in order to report a position. Take your agent device outside, with the GPS receiver connected and running, and wait for a few minutes to obtain a satellite fix. It may take up to 10 minutes for the receiver to obtain a location fix.

° Locality uses the first GPS receiver that it detects. If multiple GPS receivers are available on your agent device, you may have to specify your preferred GPS receiver manually to ensure that Locality uses the best one available. See “Specifying a GPS Receiver” on page 115 for more information.



Locality Agent Not Collecting Data (Android)

Sometimes the Locality agent is unable to collect performance data or location data due to agent or Android configuration settings, such as the following:

Conditions that affect data collection... Impact on reports and charts

Locality Battery life vs data settings The Battery life vs data settings determine how Locality uses available GPS and to what extent Locality keeps the device screen on.

The default setting, which is the most conservative, honors the native behavior of the device screen—never forcing the screen to stay on.

When the screen is off:° Locality can collect most network performance

data, but can’t measure signal quality.° Locality stops asking the GPS for location

information. Consequently, performance data collected while the screen is off appears in reports but can’t be shown in maps.

When the screen is on:° Locality collects network performance data,

including signal quality.° Locality requests GPS location information so

collected data can be shown in coverage maps and device maps.

For information about how each setting affects Locality data collection, see “Conserving Battery Life (Android)” on page 258.

Mobile networking is disabled (either manually turned off or the device is set to airplane mode)

Locality can collect only system data from the device (device name, user, manufacturer, model, etc.).

GPS is disabled GPS must be enabled in Android settings in order for correlated location data to be available in Locality coverage maps and device maps.

Without GPS, network performance data is still collected and available within Locality business intelligence reports. See “Locality Agent Not Reporting Location (Android)” on page 256.

Device can’t lock on to the GPS signal When repeated attempts to find GPS fail, the Locality agent automatically reduces the frequency and duration of requests for GPS location in order to conserve battery.

Without GPS data, correlated cellular network performance data can’t be displayed on Locality maps. See “Locality Agent Not Reporting Location (Android)” on page 256.

Device screen is off When the device screen is off, Locality can collect all network performance data except signal quality.

By default, Locality is configured to only request GPS location when the screen is on. In this case, data collected while the screen is off can’t be presented on Locality maps.



Conserving Battery Life (Android)

Getting there: Locality app > Settings

For optimal data collection, the Locality agent needs an active device screen and active GPS service—each of which make demands on the device battery.

To manage the trade-off between preserving battery life and gathering data, use Locality’s Battery life vs data setting. This controls how Locality uses GPS service and to what extent Locality keeps the device screen on.

NetMotion Wireless tested a wide variety of Android devices to assess how the Locality agent impacts battery life. We recommend the following:

For Android handheld devices that are battery powered (not plugged in during the work day), use the default setting (tick 1) for longest battery life.

For Android tablets and for handheld devices that are plugged into a power source, use the setting you prefer.

The Battery life vs data setting lets you choose from four configurations (reading from left to right—tick marks 1 through 4):

Option Result

Tick 1:

Locality will only request GPS when the screen is on.

Locality will not keep the screen on.

This is the default setting. It consumes the least amount of battery life:

When the device screen is off, Locality does not ask for GPS information. Without GPS data, correlated cellular network performance data can’t be displayed on Locality maps.

When the device screen is off, Locality collects most network performance data, but can’t measure signal quality.

Tick 2:

Locality will always request GPS.

Locality will not keep the screen on.

This setting optimizes the collection of location data, which uses battery power. To conserve battery life, Locality does nothing to keep the screen on.

Locality persistently requests location data, which is used to display cellular network performance data on Locality maps.

When the device screen is off, Locality collects most network performance data, but can’t measure signal quality.



Collecting and Sending Locality Support Data (Android)

When NetMotion Wireless Technical Support is working with end users to resolve an issue with a Locality agent running on Android, they may be asked to gather some Locality data for them. There is a convenient way to do this, described here—if needed, you can send these instructions to end users.

If you are licensed for Mobile Diagnostics and users run into network issues—for example, an application is not working, or there is no network access—you may want to have them run Mobile Diagnostics instead of (or in addition to) the Support Data report. For details about the built-in and optional custom tests you can run, see “Managing Mobile Diagnostics” on page 221.

To collect Locality Support Data on an Android device

1. If the Android device is currently connected to a computer via USB cable, disconnect it.

2. In the Locality app, tap the plus sign in the action bar.

3. Tap the Support Data button to ON.

While Locality diagnostics is running, the Locality icon displays in the Android status bar to remind you that Locality is actively saving diagnostic data to Android storage.

4. Run the report as directed by Technical Support. Typically you enable Support Data and run it until your problem reoccurs. Then, return here and tap the Support Data button to OFF.

5. Locality bundles the collected data in a ZIP file, which can then be copied via USB:

a. Connect a USB cable from the Android device to a local computer.

b. Using the computer’s File Explorer, open the Android file system and go to Locality > Support, and then select the file (SupportData_<year>_<month>_<day>_<time>.zip).

c. Copy the ZIP file to the computer.

6. Send the ZIP file to NetMotion Wireless Technical Support.

Tick 3:


Locality will keep the screen on but allow manual screen off.

This setting optimizes the collection of location data. Signal quality data is collected too, unless the user manually turns off the screen.


Locality keeps the screen on (dimly) to support collection of signal quality data. The user can turn off the screen at any time. When the device screen is off, Locality collects most network performance data, but can’t measure signal quality.

Tick 4:


Locality will keep the screen on and prevent manual screen off.

This setting optimizes the collection of both location and signal quality data. Locality requests GPS and also forces the device screen to stay on. This results in the biggest drain on battery life.


Locality forces the screen to stay on at all times, but does not force it to be bright. The user can’t manually turn off the screen.

Keeping the screen on ensures that Locality can collect signal quality data for use in maps and reports.

Note: Keeping the screen on may cause the device touchscreen to remain sensitive to user inputs.

Option Result



Troubleshooting the Locality Agent (iOS)

The Locality app Status screen displays information about how the Locality agent is functioning and posts messages indicating any issues with server communication or GPS location services.

Related Information

Locality Agent Cannot Connect (iOS)

The Locality agent automatically attempts to connect to the Locality server you specify in the agent. If an agent cannot connect, you will see an error (for example, Failed to communicate with the Locality server) on the Locality agent Status screen. Try the following:

Make sure the agent is using the correct address for the Locality server. Open the Locality app; the Status screen shows the server address currently in use.

If the address is wrong, tap Address and enter the correct fully qualified domain name for the Locality server. Tap Done and return to the Status screen. Check Last communication to confirm that the agent is connected to the server. To force the agent to try to connect with the server, tap Last communication. For additional information, see “Server Status Messages (All Platforms)” on page 262.

If a message on the Status screen indicates that the server certificate is not trusted, tap Settings. Does your site uses a signed certificate to secure connections to the server? ° If an untrusted server certificate is allowed, disable Require trusted certificate.° If your Locality server uses a signed server certificate from a certificate authority (CA),

enable Require trusted certificate.For more information, see “Configuring Agents to Accept Locality Server Certificates” on page 261.

Locality Agent License Issues

The first time that the Locality agent is started (for example, after it has been installed on the computer for the first time), you may be alerted that Locality is not licensed. Once the agent has successfully communicated with the Locality server and received a license, the message disappears.

When the number of devices on which Locality agent software is installed exceeds the number of Locality agents for which the server is licensed, devices that can’t obtain a license from the server display the Locality is not licensed on this device message. An unlicensed Locality agent device is not able to collect data. It will contact the server periodically to see if a device license is available.

To increase the server’s device licensing capacity and provide licenses for agents requesting them, do one of the following:

Purchase additional device licenses from NetMotion Wireless:

http://www.netmotionwireless.com Manually unlicense agent devices that are no longer in use, so that their licenses are returned

to the pool of available device licenses. For details, see “Monitoring Agent Device Status” on page 211.


“Locality Agent Cannot Connect (iOS)” on page 260

To run Diagnostics, see “Locality Agent Diagnostics (iOS)” on page 280

To generate support data, see







Configuring Agents to Accept Locality Server Certificates

(Locality server only) By default, Locality uses the Transport Layer Security (TLS) protocol to validate its identity to connecting Locality agents, and to secure information that Locality agents send to it. This is done using a third-party signed server certificate. This kind of certificate may not be present on the agent device and is therefore considered untrusted.

If the user is prompted repeatedly to accept the Locality server certificate, use one of these procedures:

To allow a Locality agent Windows device to use untrusted certificates

1. Open the Locality agent: Start > NetMotion Wireless Locality > Locality.

2. On the Status tab, click Configuration.

3. Clear the Require trusted server certificate check box.

To allow a Locality agent Android device to use untrusted certificates

1. In the Locality app, tap the Settings button from the action bar.

2. Tap to clear the Require trusted cert check box.

If you configured Locality to use a certificate from a certificate authority (CA), as described in “Configuring the Locality Server to Use a Signed Certificate” on page 110, instruct mobile workers running the Locality agent to select this check box:

On Windows devices select Require trusted server certificate On Android devices select Require trusted cert

Locality Agent Status Messages

This section lists status messages that are reported in both the Locality agent log and the Locality agent Status tab.

To check the status of a Locality agent, open the Locality application on the agent device.

The tables in the following sections list and explain common Locality agent status messages, and identify the steps needed to address reported error conditions.



Server Status Messages (All Platforms)

Server status provides information about communication between the Locality agent and Server.

Communication Message Description

Attempted to communicate with the Locality server at <date-time>.

This message is shown if Locality successfully communicated with the configured server previously, but was unsuccessful at the specified data and time. The reason for communication failure could be something like a temporary lack of connection, or a problem with DNS resolution.

Failed to communicate with the Locality server at <date-time>.

This warning is shown if Locality has never successfully communicated with the configured server, or if the reason for communication failure is a condition that needs to be addressed—it is not something temporary.

An authentication code is required to connect to the Locality server.

The Locality agent can’t be licensed unless an authentication code is provided. Without a license, this agent is unable to collect data. Contact your company’s Locality administrator to obtain a valid client authentication code.

The Locality configuration is corrupted or missing.

This message is for Windows users.

The Locality agent is disabled until you reconfigure it:

1. Click the Restore default configuration button provided with the message.

2. In the Locality Configuration dialog box, enter the server name and update your GPS configuration settings as necessary.

3. Click OK.

The agent immediately attempts to connect to the Locality server that you specified.

Locality is not licensed on this device.

Indicates that this device does not have a required device license and therefore cannot collect and send data to the Locality server. Periodically, the agent device will contact the server to see if a license is available.

Normally, the first time a Locality agent connects to the server, it is given a user license from a finite pool of licenses. You will see this message when the server has issued all available licenses to other agents and has no more to give out, or when your evaluation license has expired.

A device may also display this message the first time that the Locality agent is started (for example, after it has been installed on the computer for the first time). Once the agent has successfully communicated with the Locality server and received a license, this message disappears.

The Locality service is not running.


Indicates that the Locality agent is disabled.

Reboot your agent device to restart the service. If this situation persists, the user should contact the system

administrator.

The Collection service is not running.

This message is for Android users.


Restart your Android device to restart the service. If this situation persists, the user should contact the system

administrator.




Attempted to communicate with the Locality server at <date-time>.

This message is shown if Locality successfully communicated with the configured server previously, but was unsuccessful at the specified data and time. The reason for communication failure could be something like a temporary lack of connection, or a problem with DNS resolution.

Failed to communicate with the Locality server at <date-time>.

This warning is shown if Locality has never successfully communicated with the configured server, or if the reason for communication failure is a condition that needs to be addressed—it is not something temporary.

Untrusted server certificate (Invalid CA, Name Mismatch)

The Locality agent configuration is set to require a trusted server certificate from Locality server. The server is not configured with a signed CA server certificate, so it cannot provide the requested certificate.

To remedy this, change the Locality agent configuration: clear the Require trusted server certificate check box.

An authentication code is required to connect to the Locality server.

The Locality agent can’t be licensed unless an authentication code is provided. Without a license, this agent is unable to collect data. Contact your company’s Locality administrator to obtain a valid client authentication code.

The Locality configuration is corrupted or missing.


The Locality agent is disabled until you reconfigure it:

1. Click the Restore default configuration button provided with the message.

2. In the Locality Configuration dialog box, enter the server name and update your GPS configuration settings as necessary.

3. Click OK.

The agent immediately attempts to connect to the Locality server that you specified.

Locality is not licensed on this device.

Indicates that this device does not have a required device license and therefore cannot collect and send data to the Locality server. Periodically, the agent device will contact the server to see if a license is available.

Normally, the first time a Locality agent connects to the server, it is given a user license from a finite pool of licenses. You will see this message when the server has issued all available licenses to other agents and has no more to give out, or when your evaluation license has expired.

A device may also display this message the first time that the Locality agent is started (for example, after it has been installed on the computer for the first time). Once the agent has successfully communicated with the Locality server and received a license, this message disappears.

The Locality service is not running.



Reboot your agent device to restart the service. If this situation persists, contact your company’s Locality

administrator.



Location Status Messages (Android)

Location status messages provide information about how location services are being used.

Monitored Adapters Status Messages (Windows)

Locality reports on the state of all monitored adapters. Status messages alert you to conflicts that are preventing the agent from collecting data. When detected, you’ll be informed about:

The Collection service is not running.

This message is for Android users.


Restart your Android device to restart the service. If this situation persists, the user should contact the system

administrator.

Location Status Message Description

Known The device GPS has a position fix and is able to report location data.

GPS location is temporarily unavailable

The device GPS is enabled, but the received GPS signal is not sufficient to report a precise position, or the signal is not available (usually a situation where the GPS receiver is inside or blocked by large buildings outside).

Tap Search for GPS location to start a new search.

For troubleshooting help, see “Locality Agent Not Reporting Location (Android)” on page 256.

GPS is disabled in location settings

The GPS is not enabled. Tap Edit location settings and enable the GPS provided by the Android device.

Monitored Adapter Message Description

No adapters found. Locality did not detect any supported network adapters on your system.

For remote broadband adapters, see “Locality Agent Does Not Detect Trunk Modem (Windows)” on page 252.

For other types of network adapters, see “Locality Does Not Detect A Network Adapter (Windows)” on page 251.

An authentication error is preventing communication with a remote broadband adapter. Click Configuration and verify that your Locality settings are correct.

The Locality agent cannot connect to the remote broadband adapter (“trunk modem”).

Click Configuration, set Adapter to your remote broadband adapter type. If you are using non-default settings, check to make sure they are correct. See “Configuring Locality to Use a Remote Broadband Adapter” on page 117.

The integrated GPS receiver in this adapter is locked.

If you have a network adapter with an integrated GPS receiver, you may have to unlock the GPS receiver by using the connection manager software or custom software on the agent device.




Locality cannot collect data from your <adapter> adapter while more than one version of the connection manager is running.

This message indicates that one of the following conditions has occurred:

Locality has detected more than one connection manager running for the specified adapter. Data will not be collected until only a single version of the connection manager is running.

You stopped one version of the adapter connection manager and started another. Locality is in the process of switching communication from the initial connection manager API to the current one. Once the switch is made, data collection will resume.

Example: If the device uses a Sierra Wireless network adapter, you may have installed two connection managers that are using different versions of the API:

The AT&T connection manager supplied by the carrier, based on an older version of API.

The Sierra Watch Manager supplied by Sierra Wireless Inc, based on a newer version of the API.

If you run both connection managers simultaneously, this Locality error condition will occur.

Locality is not compatible with the connection manager (<name>) currently being used with your adapter (<adapter>).

Locality is not compatible with the connection manager and adapter named in this message. Install the latest version of the connection manager for your adapter.

An error was encountered reading data from the adapter.

Indicates that there was an error the last time Locality attempted to read data from the adapter; no data was collected. This error may resolve itself the next time Locality attempts to read data from the adapter.

If this situation persists:

Try removing and re-inserting the adapter. Try rebooting your agent device.

A connection manager is blocking Locality from accessing this adapter. Please restart the connection manager.

Locality cannot read the data provided by this adapter. Data will not be collected until you resolve this issue.

Restart the connection manager for this adapter.

This adapter is configured to run in RAS mode.

To collect all necessary data, Locality requires an adapter that runs in NDIS mode.

Open the connection manager for this adapter and change to NDIS mode. See “Configuring an Adapter to Run in NDIS Mode (Windows)” on page 254.

Locality is not compatible with this adapter when configured in RAS mode.

This adapter is configured to run in RAS mode. To collect all usable data, Locality requires that adapters run in NDIS mode.

Open the connection manager for this adapter and change to NDIS mode. See “Configuring an Adapter to Run in NDIS Mode (Windows)” on page 254.

Locality is not compatible with the connection manager (<name>) currently being used with your <mfg-model> adapter.

Locality does not support your adapter in conjunction with the connection manager currently running on your agent device. Data will not be collected until you resolve this issue.

Install the latest version of the connection manager for your adapter.




GPS Receiver Status Messages (Windows)

Adapter monitoring is disabled because Locality has been unable to communicate with the server for more than 30 days.

If Locality is not able to connect to the server for 30 days or more, it automatically goes into a dormant state during which no data is collected. To return to an active state, you must resolve the server communication issue.

If communication fails, confirm that the agent is using correct configuration settings.

If this situation persists, the system administrator should check network connectivity and confirm that the Locality server is running.

GPS Receiver Message Description

Location: Insufficient GPS signal to determine location

Locality detects the GPS receiver, but its signal is not sufficient to report a precise position, or it is not available (this is usually a situation where the GPS receiver is inside or blocked by large buildings outside).

For troubleshooting help, see “Locality Agent Not Reporting Location (Windows)” on page 252.

Location: Known The GPS receiver has a position fix and is able to report location data.

No GPS found Locality could not detect a GPS receiver. For troubleshooting help, see “Locality Agent Not Reporting Location (Windows)” on page 252.

GPS detection is disabled because Locality has been unable to communicate with the server for more than 30 days.

If Locality is not able to connect to the server for 30 days or more, it automatically goes into a dormant state during which no data is collected. To return to an active state, you must resolve the server communication issue.

If communication fails, the system administrator should confirm that the agent is using correct configuration settings.

If this situation persists, the system administrator should check network connectivity and confirm that the Locality server is running.



Chapter 15 - Locality Agent Interface Reference | 267

Chapter 15Locality Agent Interface Reference

This Locality agent reference describes the user interface and settings available when running the agent on the following operating systems: Windows, Android, and iOS. This information is useful when you are helping Locality users troubleshoot an issue and you are not running the agent.

Locality Agent Interface (Windows) This Locality agent reference describes the user interface and settings available when running the NetMotion Wireless Locality agent on a Windows laptop or tablet. Some of these configuration options can be specified during a “silent” install; see “Automating Installation of the Locality Agent” on page 80 for more information.

Locality Agent Configuration (Windows)

Note: During initial setup, a Locality system administrator may deploy the Locality agent with a setting that prevents non-Administrator users on the local machine from making changes to Locality agent settings, data, and configuration files. For information about implementing and managing this restriction, see “Securing Locality Agent Settings, Data, and Configuration Files” on page 71.


268 | Chapter 15 - Locality Agent Interface Reference

Here are the configuration settings that Locality agents users see on Windows:

See the following for details:

“Locality Agent Server Settings” on page 268 “Locality Agent GPS Settings” on page 269 “Locality Agent Remote Broadband Settings” on page 271 “Locality Agent Logging” on page 272

Locality Agent Server Settings

The Server settings specify the address of the Locality server and can be used to require a trusted signed server certificate from the Locality server:

Option Description

Address The fully-qualified domain name of the Locality server to which you want the agent to connect.

Address examples:





Locality Agent GPS Settings

The options in the GPS Receiver list box specify what method Locality uses to detect a GPS receiver available to the agent device. When a GPS receiver is recognized by the Locality agent, its name is displayed on the Status tab.

Require trusted server certificate

Enabled by default.

Locality can employ Transport Layer Security (TLS) using an x509 server certificate to validate its identity to connecting Locality agents.

When to enable this option:

Agents reporting to a hosted Locality Cloud server should enable this option to prevent connections to servers with untrusted server certificates.

Agents reporting to a locally-hosted Locality server behind a corporate firewall typically accept a self-signed server certificate. This kind of certificate will not be present on your computer and is therefore considered untrusted. To allow the Locality agent to accept untrusted server certificates, this option must be disabled (check box cleared).

If the Locality server is configured to use a signed server certificate from a certificate authority (CA), as described in “Configuring the Locality Server to Use a Signed Certificate” on page 110, Locality agent users should enable this option (check box selected).

Option Description

Detected automatically This option is on by default:

Locality scans COM ports that use a baud rate of 4800, 9600 and 38400.

Locality looks at Windows location sensors for a GPS receiver.

If Sierra Wireless AirLink modem support is enabled, Locality also looks for a GPS receiver on UDP port 34701.

To be detected, the GPS receiver must generate TAIP or NMEA 0183-compliant data.

Locality uses the first GPS receiver that it finds. These GPS receiver types are supported:

A stand-alone GPS receiver or a GPS receiver that is integrated in a network adapter. The receiver must communicate via a COM port.

A Windows location sensor that is integrated in the Windows device.

A GPS receiver integrated in a remote broadband adapter (Sierra AirLink trunk modem) that uses a UDP port.

When one of the above GPS receiver types is found by the Locality agent, its name and communication port (if applicable) are displayed on the Status tab.

Option Description



Serial connection If your GPS receiver is not automatically detected, if you have multiple GPS receivers available to the agent device and Locality is not using the one that you prefer, or if you are not getting location data from the current receiver and want to try another, use this option to configure Locality to connect to a specific standalone GPS receiver:

COM port: The port through which the GPS receiver transmits location information to the Locality agent.

You can select the COM port of a detected GPS receiver from the drop-down list.

If your preferred GPS receiver was not detected, specify the COM port it is using, in the format COM#, where # is a positive number.

Baud rate: The default setting (Automatic) can detect standard GPS receivers on the specified COM port, provided the port’s baud rate is 4800, 9600, 19200, 38400, 57600 or 115200.

If you know the baud rate required by your GPS receiver, you can skip the automatic COM port baud rate scan. Select the required rate from the drop-down list.

If your GPS receiver uses a non-standard baud rate, specify the correct COM port baud rate manually.

Note: Stand-alone GPS receivers that use the NMEA 0183 standard or TAIP protocol may require additional configuration. For details, see “Recommendations for Standalone GPS Receiver Configuration” on page 116.

Remote broadband adapter In most cases the Receiver setting should be left at Detected automatically. If multiple GPS receivers are available on your agent device, Locality uses the first GPS receiver that it detects. You may have to specify the receiver manually to ensure that Locality uses the one you intend.

Windows location sensor Forces Locality to use a Windows location sensor for GPS data. If your preferred GPS receiver provides location information through a Windows sensor, select this option.

Auto-start integrated GPS receivers

To gather location-related data, Locality must communicate with an active GPS receiver.

Select this check box if your preferred GPS receiver is integrated with an internal or remote adapter. This increases the likelihood that the adapter-based GPS receiver on an agent device or a remote broadband adapter is active, meaning that Locality can collect location information more reliably.

Do not select this check box if your preferred GPS receiver is a standalone device (such as a USB or Bluetooth GPS receiver) that is connected to your mobile device.

Option Description



Locality Agent Remote Broadband Settings

If the Locality agent laptop uses a supported remote broadband adapter to connect to the WWAN, the settings under Remote Broadband determine whether Locality collects network performance data from the remote broadband adapter and specify what method Locality uses to connect to the modem:

Option Description

Disabled The remote broadband Adapter setting is disabled by default. This prevents Locality from searching for a remote broadband adapter and consuming bytes from your data plan in the process.

CradlePoint Specifies that the Locality agent connects to a CradlePoint mobile router automatically, using the default user name, IP address, and password built into the adapter.


General Mobile Hotspot

Specifies that the Locality agent makes a local connection to a mobile hotspot adapter.

You are prompted for the IP address and password needed to establish a local connection to the web interface on the hotspot device. Select the default address from the Address drop-down list or enter the address that your hotspot uses. The password that you enter will be written to the configuration in an encrypted format.

NetGear AC341U Specifies that the Locality agent connects to a NetGear Aircard 341U adapter.

You are prompted for the password to use when communicating with this adapter. The password will be written to the configuration in an encrypted format.

Rocket Specifies that the Locality agent connects to a Utility Rocket mobile router.

Sierra AirLink Specifies that the Locality agent makes a local network connection to the AirLink adapter automatically, using the default IP address and password built into the adapter.


Custom settings check box

Select this option if your Sierra AirLink or CradlePoint trunk modem is configured to use non-default settings.

If you select Sierra AirLink as you adapter, you are prompted for the IP address and password necessary for connecting to the AirLink trunk modem. (The user name for communicating with an AirLink trunk modem is user and cannot be changed.)

If you select CradlePoint as your adapter, you are prompted for a user name, address (123.123.123.123 or 123.123.123.123:45), and password.

You must enter a user name (admin is the default, but must still be entered). In the Password drop-down list, selecting default specifies the internal password.



Locality Agent Logging

Mobile workers should change the default Logging setting only when directed to do so by the system administrator:

Locality Agent Status (Windows)

You can review the following Locality status information:

Error conditions that need your attention are displayed at the top of the Locality agent Status tab.

Option Description

Enable verbose logging If you have asked Locality agent users to select this option, remember to have them clear it after you finish troubleshooting.

Display Description

Address The Locality server’s fully qualified domain name through which the agent is connected to the server.

Last communication time

The date and time of the last successful transmission from the Locality agent to the Locality server.

If the Locality agent is currently unable to connect and communicate with the server, a status message appears at the top of the Status page. The message indicates when the last communication attempt occurred and the reason for the failure.

If your Locality agent has a valid license and a connection failure occurs, the agent continues to collect Locality data. Once a connection to the server is reestablished the collected data is transmitted.



Note: If your Locality server requires a client authentication code and the agent is not configured to provide it, this popup message displays in the system tray when the Locality agent application is opened:

Test server communication

When the Test server communication button is clicked, the Locality agent device immediately attempts to communicate with the Locality server. If the communication fails, you will see a message. For example:

To troubleshoot server communication issues, see “Locality Agent Cannot Connect (Windows)” on page 251.

GPS The GPS receiver that is being used to collect location information to send to the Locality server.

If No GPS found displays in this box, Locality could not detect a GPS receiver. See “Troubleshooting ‘No GPS Found’ Status (Windows)” on page 253.

Location Indicates whether the GPS receiver is able to report a precise position.

When the GPS receiver is found and the signal is good, the location status shows Known.

If the location status shows Insufficient GPS signal to determine location, Locality detects the GPS receiver, but the received GPS signal is not sufficient to report a precise position, or the signal is not available (usually a situation where the GPS receiver is inside or blocked by large buildings outside).


GPS receivers must be able to lock onto global positioning satellites in order to report a position. Take your computer outside, with the integrated or standalone GPS receiver attached and running, and wait for a few minutes to obtain a satellite fix. It may take up to 10 minutes for the receiver to obtain a location fix.

Locality uses the first GPS receiver that it detects. If multiple GPS receivers are available to your agent device, you may have to specify your preferred GPS receiver manually to ensure that Locality uses the best available receiver. See “Specifying a GPS Receiver” on page 115 for more information.

Monitored Adapters The type of mobile hotspot device or carrier network adapter (make and model) that the Locality agent is monitoring; for example, Novatel Wireless - PC770 VERIZON. If more than one supported adapter is available on your device, they are all listed here.

Status Indicates whether the connection between your device and your carrier is Connected or Disconnected.

The help button on the bottom left in the Locality agent opens context-sensitive help.

Display Description



Locality Agent Mobile Diagnostics (Windows)

If users run into any issues while using Locality—for example, an application is not working, or there is no network access—they can generate a diagnostic report. A summary quickly identifies the probable root cause of the issue; in case a user is doing his own troubleshooting, full details are also available. Additionally, the diagnostic report is available in the Locality console, where the administrator or help desk staff can see the results and help resolve the issue.

The Mobile Diagnostics Module is a separately licensed feature—if the Locality server to which you connect is not licensed for it, you cannot generate any diagnostics.

Diagnostics quick launch: On the Locality agent Start menu, the NetMotion Wireless Locality group contains a Run Mobile Diagnostics shortcut that users can click to start diagnostic tests.

On the Locality agent Diagnostics tab, users can run the diagnostics tests you specify in the Locality console and view reports that contain the results.

Users will click Diagnose network problems to run network connectivity tests. When all tests are completed, results are displayed in the Diagnostic Report window.

The Diagnostics Reports list provides access to all reports that were generated within the last 30 days. Double-click a report to open it in the Diagnostic Report window.

For more information, see “Viewing a Mobile Diagnostics Report” on page 274.

Viewing a Mobile Diagnostics Report

Diagnostics reports generated in the last 30 days are listed on the Diagnostics tab. To see test results, double-click the report. In this example all of the tests passed and a warning was displayed for the network interface test.



Select All tests at the top of this dialog box to see a summary of all the tests that were run. For the full report, click Show details:

Locality Agent Interface (Android) This section describes the status and configuration options available to users running the NetMotion Wireless Locality agent on an Android device.



Locality Status and Diagnostics (Android)

You can review the following Locality status information:

Error conditions that need your attention are displayed at the top of the Status screen.

Display Description

Run diagnostics If your Locality deployment is licensed for Mobile Diagnostics and users run into any issues while using Locality—for example, an application is not working, or there is no network access—they can tap this button to generate a diagnostic report that will also be available to you in the Locality console.

View reports Any Mobile Diagnostics reports generated in the last 30 days are listed here. To see detailed test results, open the report. See “Managing Mobile Diagnostics” on page 221 for more information.


Address examples:

Locality Cloud: yourcompanyserver.localitycloud.com Local-hosted server FQDN: yourlocalserver.yourcompany.com



Last communication time

The date and time of the last successful transmission from the Locality agent to the Locality server.

If communication fails, a status message displays at the top of the Status page. The message indicates when the last communication attempt occurred and the reason for the failure. For example:

To test server communication, tap Last communication time. This causes the Locality agent to reconnect with the Locality server. If communication fails, another status message displays.

To troubleshoot server communication issues, see “Locality Agent Cannot Connect (Android)” on page 255.

Note: If your Locality agent has a valid license and a connection failure occurs, the agent continues to collect Locality data. Once a connection to the server is reestablished the collected data is transmitted.

Mobile network Indicates one of the following states:

Mobile networking is disabled (either manually turned off or the device is set to airplane mode). In this case, Locality can collect only system data from the device (device name, user, manufacturer, model, etc.).

The device is Connected to or Disconnected from your carrier’s mobile network (WWAN). Locality continues to collect WWAN performance data regardless of the connection state. Collected data is held until Locality can make a WWAN or WiFi connection to the server and send the data.

Location Provides the status of the device’s GPS, which is used to collect location information to send to the Locality server.

Indicates whether GPS is able to report a precise position.

Known: Indicates that GPS is enabled and the signal is good. GPS is disabled in location settings: Indicates that GPS is not

enabled. Locality cannot collect location data until GPS is enabled. Tap Edit location settings and enable the GPS on the Android device.

GPS location status temporarily unavailable: Indicates that GPS is enabled, but the received GPS signal is not sufficient to report a precise position, or the signal is not available (usually a situation where the GPS receiver is inside or blocked by large buildings outside).

Tap Search for GPS location to manually start a new satellite search. The search lasts up to 10 minutes or until a satellite signal is found.

To troubleshoot GPS availability, see “Locality Agent Not Reporting Location (Android)” on page 256.

Display Description



Note: If your Locality server requires a client authentication code and the agent is not configured to provide it, the Locality icon appears in the action bar prompting for attention.

Locality Settings (Android)

Getting there: Locality app > Settings icon

Use the following settings to configure the Locality agent:

Server Settings

The Server settings specify the address of the Locality server and can be used to require a trusted signed server certificate from the Locality server:

Option Description


Address examples:

Locality Cloud: yourcompanyserver.localitycloud.com Local-hosted server FQDN:

yourlocalserver.yourcompany.com

Require trusted cert Enabled by default.

Locality can employ Transport Layer Security (TLS) using an x509 server certificate to validate its identity to connecting Locality agents.

Whether you enable this option depends on your deployment:

Agents reporting to a hosted Locality Cloud server should enable this option to prevent connections to servers with untrusted server certificates.

Agents reporting to a locally-hosted Locality server behind a corporate firewall typically accept a self-signed server certificate. This kind of certificate will not be present on your computer and is therefore considered untrusted. To allow the Locality agent to accept untrusted server certificates, this option must be disabled (check box cleared).

If the Locality server is configured to use a signed server certificate from a certificate authority (CA), as described in “Configuring the Locality Server to Use a Signed Certificate” on page 110, Locality agent users should enable this option (check box selected).



Device Settings

On Android devices, the screen must be kept on to collect signal quality data and GPS must be provided in order to collect location data. However, setting Locality to keep the device screen on and to repeatedly search for a GPS signal until one is found consumes battery power and shortens battery life.

By default, Locality is set to request GPS only when the screen is on and to allow the Android device to turn the screen off when the device is not in use.

For Android handheld devices that are battery powered (not plugged in during the work day), we recommend using the default setting (tick 1) for longest battery life.

For Android tablets and for handheld devices that are plugged into a power source, use the setting you prefer. Each successive setting allows collection of more data, but at the expense of battery life.

Tap Battery life vs data to view and set performance settings. Tap any of the four tick marks to see details about how that setting controls use of GPS service and to what extent Locality keeps the device screen on. For information about how each setting affects Locality data collection, see “Conserving Battery Life (Android)” on page 258.

Select the preferred setting and tap OK.

Locality Diagnostics Screen (Android)

Getting there: Locality app > Plus sign icon (“+”)

On the Locality Diagnostics screen, the Support Data button indicates whether the diagnostics tool is OFF or ON. For a detailed procedure, see “Collecting and Sending Locality Support Data (Android)” on page 259.

Locality Agent Interface (iOS) There are two main features supported on the iPhone and iPad:

You can include iOS information in inventory reports in the Locality console. iOS devices are enrolled in Locality Inventory Management by connecting to a hosted Locality Enrollment web page: the user provides a client authentication code and in response a Locality iOS Inventory profile is installed on the device. Mobile Device Management settings are used to allow Locality to collect data from the iOS device using the Apple Push Notification service (APNS). In terms of what the end user sees on the iOS device, this feature has no interface. For details, see “Enrolling a Device in the Locality Inventory System (iOS)” on page 97.

Mobile Diagnostics is a separately licensed module that runs built-in and custom tests on Locality agents to diagnose connectivity and performance issues experienced in the field. To support this feature on the iOS platform, the Locality agent is installed as an app, the interface for which is described in the following sections.



Locality Agent Status (iOS)

The Locality home screen on an iOS device displays a summary of server information.

Locality Agent Diagnostics (iOS)

Mobile Diagnostics runs tests on Locality agents to diagnose connectivity and performance issues experienced in the field. There are built-in tests and, if have added them, custom tests. The diagnostic information is available on both the iOS device and in the console: a summary quickly identifies the nature of the issue, and the details enable you (or a technical user) to dig deeper.



Users should be encouraged to add a comment when they run diagnostics, so that you (the administrator) understand what prompted them to run the test.

Mobile Diagnostics Results

To dig deeper into test results, tap the corresponding name on the main Diagnostics screen. The details offer the technically savvy user (and you, in the Locality console) some clues as to the root cause for an issue. In the following example, it’s clear that connectivity was not completely lost, but



was very weak. The device tests passed, but something is interfering with the connection to the Internet: is the user at the edge of a coverage area? If the connection is cellular, is anything interfering with the signal between thee device and a cell tower?

There are three main categories for diagnostic tests (the Internet test Mobility VPN is available only on the Locality agent for Windows):

Category Test Description

Device Test Network Interfaces This set of diagnostic tests determines interface and routing problems that are detected locally on the Locality agent device. The test results are grouped as follows:

WiFi Status WWAN Status Detailed Interface List IPv4 Route Table

Internet Tests Captive Portal Detection Hotspots that redirect your connection until a certain action is performed, such as agreeing to terms, are common in airports, hotels, and coffee shops. This test detects whether the Locality agent has encountered this kind of hotspot (also known as a captive portal).

For example: Network activity is being redirected; web browser authentication may be required.

Internet Connectivity This diagnostic test simply determines whether you have Internet access.

Custom Tests <name> You can create custom diagnostics tests and have them run after the built-in tests; see “Adding Custom Mobile Diagnostics Tests” on page 223 for more information.



Related Information

For information about analyzing Mobile Diagnostics reports, see “Analyzing Mobile Diagnostics” on page 193.

More information about these tests and Mobile Diagnostics requirements is covered in “Managing Mobile Diagnostics” on page 221.

Locality Agent Settings (iOS)

Locality agent users are unlikely to need to update their settings unless the address for the Locality server changes, or they are working with Technical Support and have been instructed to collect support data. Here is the Settings screen that they see, followed by descriptions:



Locality Agent Settings

Option Description

Server The fully-qualified domain name of the Locality server to which you want the agent to connect.

Address examples:

Locality Cloud: yourcompanyserver.localitycloud.com Local-hosted server FQDN:

yourlocalserver.yourcompany.com

Require trusted certificate When a trusted server certificate is required, Locality uses the Transport Layer Security (TLS) protocol and x509 certificates for the agent-server connection.

Note: A TLS connection is cached for up to ten minutes. This means that if you change the setting for Require Trusted Certificate from Off to On, for example, the agent user will be able to connect to a Locality server that does not have the required certificate. After about ten minutes the same connection will fail (as it should).

Enter standalone mode There are some Mobile Diagnostics tests—basic connectivity and captive portal detection—that you can run even when you are not connected to a Locality server. This is typically a mode that you might use when you first install the agent and before you connect to a Locality server.

Note: Entering this mode deletes any existing diagnostics reports and server information (the Locality server address and, if applicable, the client authentication code).

Generate support data When NetMotion Wireless Technical Support is working with users to resolve an issue with a Locality agent, users may be asked to gather information by tapping this option and sending the results. Tapping this item opens an email message with full details in the body: all the user needs to do is enter are recipient.

Clear event log Clears the events in the current log.

Verbose logging If you have asked Locality agent users to select this option, remember to have them clear it after you finish troubleshooting.

When a red alert appears at the bottom of the Locality agents screens, it indicates that the user must enter an authentication code in order to connect to the Locality server, or that the server address is empty.
