Mobility Services Platform 3.1 User`s Guide

Transcription

Mobility Services Platform 3.1
User’s Guide
Mobility Services Platform 3.1
User’s Guide
72E-100158-04
Revision B
January 2008
© 2007 by Motorola, Inc. All rights reserved.
No part of this publication may be reproduced or used in any form, or by any electrical or mechanical
means, without permission in writing from Motorola. This includes electronic or mechanical means, such
as photocopying, recording, or information storage and retrieval systems. The material in this manual is
subject to change without notice.
The software is provided strictly on an “as is” basis. All software, including firmware, furnished to the User
is on a licensed basis. Motorola grants to the User a non-transferable and non-exclusive license to use
each software or firmware program delivered hereunder (licensed program). Except as noted below, such
license may not be assigned, sublicensed, or otherwise transferred by the User without prior written
consent of Motorola. No right to copy a licensed program in whole or in part is granted, except as
permitted under copyright law. The User shall not modify, merge, or incorporate any form or portion of a
licensed program with other program material, create a derivative work from a licensed program, or use a
licensed program in a network without written permission from Motorola. The User agrees to maintain
Motorola’s copyright notice on the licensed programs delivered hereunder, and to include the same on
any authorized copies it makes, in whole or in part. The User agrees not to decompile, disassemble,
decode, or reverse engineer any licensed program delivered to the User or any portion thereof.
Motorola reserves the right to make changes to any software or product to improve reliability, function, or
design.
Motorola does not assume any product liability arising out of, or in connection with, the application or use
of any product, circuit, or application described herein.
No license is granted, either expressly or by implication, estoppel, or otherwise under any Motorola, Inc.,
intellectual property rights. An implied license only exists for equipment, circuits, and subsystems
contained in Motorola products.
MOTOROLA and the Stylized M Logo and Symbol and the Symbol logo are registered in the US Patent &
Trademark Office. All other product or service names are the property of their respective owners.
Motorola, Inc.
One Motorola Plaza
Holtsville, New York 11742-1300
http://www.symbol.com
iii
Table of Contents
About This Guide ...............................................................................................ix
Related Documents ........................................................................................................................................ ix
Service Information ......................................................................................................................................... ix
Chapter 1 What is the Mobility Services Platform............................................1
MSP Editions .................................................................................................................................................. 1
Staging ................................................................................................................................................... 1
Provisioning............................................................................................................................................ 2
Security Features of MSP ............................................................................................................................... 3
Components of MSP....................................................................................................................................... 3
MSP 3 Server ......................................................................................................................................... 3
MSP Client ............................................................................................................................................. 3
Relay Servers......................................................................................................................................... 4
AirBEAM Package Builder...................................................................................................................... 4
Internet Explorer/MSP 3 Console UI ...................................................................................................... 4
Network Overview........................................................................................................................................... 4
Chapter 2 Your Enterprise and MSP Objects ...................................................7
Understanding Your Enterprise....................................................................................................................... 7
Scalability ............................................................................................................................................... 8
Network Topology and Connectivity ....................................................................................................... 8
Security .................................................................................................................................................. 9
Relay Server Communication .................................................................................................. 9
MSP 3 Console UI User Authentication, Role, and Scope ......................................................10
Network Naming/Addressing and Accessibility......................................................................................10
User Access to MSP 3 Console UI..........................................................................................10
MSP 3 Server Access to Relay Server....................................................................................10
Mobile Device Access to Relay Server ...................................................................................11
Identifying Key Enterprise Objects .................................................................................................................11
User(s)...................................................................................................................................................11
User Roles ..............................................................................................................................11
iv
MSP 3.1 User’s Guide
User Access Prefixes ..............................................................................................................12
Network Settings ...................................................................................................................................13
Relay Server(s) .....................................................................................................................................13
Sites ......................................................................................................................................................13
Installing and Configuring Server(s)...............................................................................................................15
Relay Server(s) .....................................................................................................................................15
MSP 3 Server(s)....................................................................................................................................15
Creating MSP Objects ...................................................................................................................................15
MSP Object Overview ...........................................................................................................................15
MSP Object Naming ..............................................................................................................................16
MSP Enterprise Objects ........................................................................................................................16
Network Settings Objects ........................................................................................................17
Relay Server Objects ..............................................................................................................17
Site Objects.............................................................................................................................18
User Objects ...........................................................................................................................18
SMS Carrier Objects ...............................................................................................................18
MSP Content Objects ............................................................................................................................18
Packages ................................................................................................................................19
Settings Objects ......................................................................................................................20
Message Set Objects ..............................................................................................................20
Bundle Objects........................................................................................................................21
Staging Objects .....................................................................................................................................21
Staging Profile Objects............................................................................................................22
Staging Options Within Staging Objects .................................................................................23
SMS Device Objects ...............................................................................................................24
Provisioning Objects..............................................................................................................................25
Condition Objects....................................................................................................................25
Provisioning Policy Objects .....................................................................................................26
Chapter 3 Performing Staging .........................................................................27
Staging Methods ............................................................................................................................................28
Barcode-Based Staging.........................................................................................................................28
How Barcode-Based Staging Works .......................................................................................28
How to use Barcode-Based Staging .......................................................................................29
On Demand (Electronic) Staging...........................................................................................................31
How On Demand (Electronic) Staging Works .........................................................................31
How to use On Demand (Electronic) Staging..........................................................................32
SMS Staging .........................................................................................................................................34
How SMS Staging Works ........................................................................................................34
How to use SMS Staging ........................................................................................................35
Viewing and Reporting on Staging Status......................................................................................................36
Legacy Staging ..............................................................................................................................................36
Legacy Staging Prerequisites................................................................................................................37
Legacy Staging Process........................................................................................................................37
Chapter 4 Performing Provisioning.................................................................39
Provisioning Operation...................................................................................................................................39
How Provisioning Works........................................................................................................................39
Policy Activation and Deactivation ..........................................................................................40
Policy Types............................................................................................................................40
Policy Applicability...................................................................................................................40
Policy Compliance...................................................................................................................40
Job Initiation ............................................................................................................................41
Readiness Conditions .............................................................................................................41
Job Execution and State .........................................................................................................41
Job Progress ...........................................................................................................................42
How to use Provisioning ........................................................................................................................42
Table of Contents v
Policy Activation ......................................................................................................................42
Policy Types............................................................................................................................43
Policy Applicability...................................................................................................................43
Viewing and Reporting on Provisioning Status ..............................................................................................43
Compliant Status ...................................................................................................................................43
Not-Compliant Status ............................................................................................................................43
Policy Details.........................................................................................................................................44
Chapter 5 Using MSP Control Modules ..........................................................45
Purpose .........................................................................................................................................................45
Control Module Types ....................................................................................................................................45
One-Time Action Control Modules ........................................................................................................45
Repetitive Action Control Modules ........................................................................................................46
Readiness Control Module ....................................................................................................................46
Configurable Action Control Modules ....................................................................................................47
Server Control Modules.........................................................................................................................48
MSP 3.1 Control Modules ..............................................................................................................................49
GetAdapters ..........................................................................................................................................49
GetAdapters Device Attributes ................................................................................................49
GetCabInventory ...................................................................................................................................50
GetCabInventory Device Attributes .........................................................................................50
AutoSiteAssign ......................................................................................................................................50
AutoSiteAssign Device Attributes............................................................................................51
LockAndWipe ........................................................................................................................................52
LockAndWipe Scenario Actions ..............................................................................................52
LockAndWipe Device Attributes ..............................................................................................56
RemoteUI and RemoteControl.......................................................................................................................56
Overview ...............................................................................................................................................56
RemoteUI vs. RemoteControl................................................................................................................57
RemoteUI and RemoteControl Changes from MSP 3.0 to MSP 3.1 .....................................................57
Mutual Exclusivity of Packages .............................................................................................................58
Using RemoteUI with MSP Stage..........................................................................................................58
Using RemoteUI with MSP Provision ....................................................................................................59
Using RemoteControl with MSP Provision ............................................................................................59
Dealing with Device IP Addresses.........................................................................................................60
Dealing with Device Contactability ........................................................................................................60
Launching RemoteUI Manually via a Web Browser ..............................................................................61
Launching RemoteUI via the MSP 3 Console UI...................................................................................61
Device Attributes used by the RemoteUI and RemoteControl...............................................................62
One to One NAT .....................................................................................................................63
One to Many NAT ...................................................................................................................64
Chapter 6 Other MSP Features and Operations .............................................67
Importing and Exporting .................................................................................................................................67
Transferring Packages To or From MSP 3 Servers...............................................................................67
Transferring Objects Between MSP 3 Servers ......................................................................................68
Using CSV Files for Bulk Object Creation .............................................................................................70
Backup and Restore ......................................................................................................................................71
Automated .............................................................................................................................................71
Manual...................................................................................................................................................72
Asset Management ........................................................................................................................................72
Site-based Management .......................................................................................................................73
MSP 3 Sites ............................................................................................................................73
Site Assignment in MSP 3.......................................................................................................74
Staging the Device for use at a Production Site ......................................................................74
Pushing a Production Site Bundle as Content ........................................................................75
Using the Automatic Site Assignment Control Module ............................................................75
vi
Manual Site Assignment .........................................................................................................76
Status Module ................................................................................................................................................77
Viewing Device Status...........................................................................................................................77
Viewing Relay Server Status .................................................................................................................77
Security ..........................................................................................................................................................78
Using HTTPS with MSP 3 ..............................................................................................................................78
Obtaining a SSL Certificate for the Server.............................................................................................78
Installing Your IIS SSL Certificate on Microsoft IIS 5.x / 6.x ..................................................................78
Enabling SSL Web Access for MSP 3 Console UI ................................................................................81
Example File for Redirecting HTTP to HTTPS Access ..........................................................................83
Example File for Redirecting HTTP to HTTPS Access ..........................................................................84
MSP Administration Program.........................................................................................................................84
Description ............................................................................................................................................84
Program Overview.................................................................................................................................84
Installation ...............................................................................................................................84
Backup/Restore.......................................................................................................................85
DB Maintenance......................................................................................................................85
Configuration...........................................................................................................................85
Logging ...................................................................................................................................85
High Availability Configuration of MSP Server 3.1.1 ......................................................................................85
Requirements and Installation ...............................................................................................................85
Switching to the Secondary MSP Web Application and Services PC......................................86
Troubleshooting .............................................................................................................................................86
Performance Monitoring ........................................................................................................................86
Using Windows Error Logging ...............................................................................................................86
Using Staging Logs ...............................................................................................................................87
Device-side Staging Logs......................................................................................................................87
MSP Services........................................................................................................................................87
Appendix A Reference Information .................................................................89
Using Condition Objects ................................................................................................................................89
Adapter condition ..................................................................................................................................90
AdapterTime condition...........................................................................................................................91
Connectivity condition ...........................................................................................................................91
Confirm condition ..................................................................................................................................91
Power condition.....................................................................................................................................91
Time condition .......................................................................................................................................92
Universal condition ................................................................................................................................92
Using Setting Objects ....................................................................................................................................93
Agent.30 ................................................................................................................................................93
Agent.AirBEAM .....................................................................................................................................93
Attribute .................................................................................................................................................93
Certificate ..............................................................................................................................................93
Clock.TimeZone ....................................................................................................................................94
Control.AutoSiteAssign .........................................................................................................................94
Control.LockAndWipe............................................................................................................................94
Network.WLAN.FusionPublic ................................................................................................................94
Network.WLAN.Legacy .........................................................................................................................94
Network.WWAN.GPRS .........................................................................................................................94
UCA.......................................................................................................................................................95
FTP Server Reference ...................................................................................................................................96
Configuring FileZilla for use as Relay Server ........................................................................................96
Configuring Windows IIS FTP Server as Relay Server .........................................................................97
Setting up FTP Server.............................................................................................................97
Configuring the FTP Server ....................................................................................................97
Using WS-2000 FTP Server as Relay Server........................................................................................97
Secure FTP Support ......................................................................................................................................98
Enabling FTPS Support ..........................................................................................................99
Table of Contents vii
Troubleshooting...................................................................................................................................100
Error code .............................................................................................................................100
Error causes..........................................................................................................................100
Server Certificate Installation ................................................................................................101
Staging certificates................................................................................................................101
Filezilla Secure FTP Configuration ......................................................................................................102
Creating a self-signed server certificate ................................................................................103
Converting self-signed certificate to DER format...................................................................105
Opening Ports on MSP 3 Server..................................................................................................................105
MSP 3 Client Error Codes............................................................................................................................106
Device WT4090 Keyboard Anomalies .........................................................................................................108
Listing of SMS Carriers Domains .................................................................................................................108
Glossary ..........................................................................................................109
viii MSP 3.1 User’s Guide
About This Guide
The MSP 3.1 User’s Guide provides general instructions for the use of the Mobility
Services Platform software product version 3.1. Newer versions of this document may be
available at http://support.symbol.com/support/product/softwaredownloads.do.
Related Documents
•
•
•
•
•
MSP 3.1 Installation Guide, p/n 72E-100159
MSP 3.1 Release Notes, p/n 72E-100160
AirBEAM Package Builder Product Reference Guide, p/n 72E-55769-01
AirBEAM Package Builder Version 2.x Addendum
Help text is available from the MSP 3 Console UI via two methods: by hovering the
mouse pointer over certain input fields of the screen and by clicking the “?” button.
Service Information
If you have a problem with your software, contact Motorola Enterprise Mobility support for
your region. Contact information is available at: http://www.symbol.com/contactsupport.
When contacting Enterprise Mobility support, please have the following information
available:
• Serial number of the software
• Model number or product name
• Software type and version number
• Software license information
Motorola responds to calls by email, telephone or fax within the time limits set forth in
support agreements.
If you purchased your Enterprise Mobility business product from a Motorola business
partner, contact that business partner for support.
x MSP 3.1 User’s Guide
Chapter 1 What is the Mobility Services Platform
Motorola’s Mobility Services Platform 3 (MSP 3) is a scalable software solution that
provides a single point of control for managing large numbers of Mobile Devices within an
your Enterprise.
MSP 3 consists of a server-based software product called the MSP 3 Server and a set of
device-resident software components collectively called the MSP Client that enable the
management of Mobile Devices.
Used together, these software components allow you to perform the following tasks:
•
•
Staging – Staging is the configuration of and installation of software onto Mobile
Devices by manual request by a Mobile Device User.
Provisioning – Provisioning is the configuration of and installation of software onto
Mobile Devices remotely under the control of the MSP Server.
MSP 3 is a 3-tier management system that always manages Mobile Devices indirectly
through one or more intermediary Relay Servers (FTP Servers) located within your
Enterprise. This layered architecture makes it possible for MSP 3 to be configured to
manage large numbers of Mobile Devices from a central point, using a single MSP 3
Server.
MSP Editions
MSP 3 is available in two editions: MSP 3 Stage Edition and MSP 3 Provision Edition.
MSP 3 Provision Edition contains all the features of MSP 3 Stage Edition plus the
features of Provisioning. MSP 3 Stage Edition can be upgraded to MSP 3 Provision
Edition through the use of a license key that enables the use of the Provisioning features.
Staging
Staging is the configuration of and installation of software onto Mobile Devices by manual
request by a Mobile Device User. Staging allows Mobile Devices to be quickly and
efficiently prepared for use within your Enterprise by configuring Settings to enable
2 MSP 3.1 User’s Guide
network connectivity and then using that connectivity to perform additional configuration
and software installation.
Staging is most commonly performed before initial use when devices are “fresh out of the
box”. Staging is supported using a variety of methods such as by scanning barcodes, by
pulling a Profile from a Profile Server, or by pushing Profiles via SMS messages sent to a
WWAN-enabled Mobile Device.
It is important to understand that Staging is an operation must be initiated by a Mobile
Device User and hence always requires the attendance of such a User. Staging is
sometimes referred to as a “pull” operation since the Mobile Device User explicitly
requests that configuration and software be “pulled” from a Relay Server by applying a
pre-defined Staging Profile.
MSP 3 Stage Edition includes only the Staging function. All Mobile Devices listed as
supported by MSP 3 Stage Edition are capable of supporting all the Staging features of
MSP 3 Stage Edition. However, if a Mobile Device does not ship with a suitably recent
Staging Client pre-installed, then some Staging features may not be available on that
device when it is “fresh out of the box”. Such devices can be updated to a suitable
Staging Client, using the Legacy Staging Process, after which they will support all the
Staging features.
MSP 3.1 provides Staging via the following methods:
•
•
•
Barcodes – Barcodes are generated from a Staging Profile and printed via the MSP 3
Console UI. The barcodes are scanned by the device, the Profile is extracted, and
the device is Staged according to the Profile.
On Demand – A PC is used to launch a special Web page from the MSP 3 Console
UI. This Web page hosts an ActiveX Object that receives Profiles from the MSP
Server and “serves them up” to Mobile Devices. A Mobile Device contacts the Profile
Server on the PC, acquires a Profile, and is Staged according to the Profile. Mobile
Devices can connect to the PC via:
• A Microsoft ActiveSync™ connection to the PC, via which the PC can be reached
by the Staging Client.
• A exisiting Wired or Wireless connection, via which the PC can be reached by
the Staging Client.
• A well-known wireless connection, that is automatically established by the
Staging Client.
SMS messages – Staging commands can be sent to a WWAN-enabled Mobile
Device encoded within a sequence of SMS messages. The SMS Staging Client on
the device intercepts these messages, extracts the Profile, and the device is Staged
according to the Profile.
Provisioning
Provisioning is the configuration of and installation of software onto Mobile Devices
remotely under the control of the MSP Server. Provisioning is a powerful method to
ensure that all Mobile Devices have the configuration and software that are necessary for
their proper operation on an ongoing basis. Provisioning in MSP 3 is performed based
on Policies that determine what configuration and software belongs on which Mobile
Devices and when updates should be performed.
Provisioning can be configured to be automatic or manual, but it is important to
understand that Provisioning is performed by the MSP Server under the control of the
MSP 3 Console UI and hence does not require the attendance of a Mobile Device User.
What is the Mobility Services Platform 3
Provisioning is sometimes referred to as a “push” operation since configuration and
software are “pushed” by the MSP Server to Mobile Devices via a Relay Server.
MSP 3 Provision Edition includes both the Staging and Provisioning functions. All Mobile
Devices listed as supported by MSP 3 Provision Edition are capable of supporting all the
Provisioning features of MSP 3 Provision Edition. However, if a Mobile Device does not
ship with a suitably recent MSP Client pre-installed, then some Staging and Provisioning
features may not be available on that device when it is “fresh out of the box”. Such
devices can be updated to a suitable MSP Client, using the Legacy Staging Process,
after which they will support all the Staging features. It is also important to note that
Mobile Devices do not ship with the Provisioning features activated. The Provisioning
features of MSP 3 Provision Edition must be activated for a device by Staging an
“enable” Package.
Security Features of MSP
MSP provides the ability to partially or completely disable Mobile Devices that may pose
a security threat to your Enterprise. A device can be “locked down”, which prevents a
Mobile Device User from interacting with the User Interface on the device and hence from
accessing any data on the device or accessing the network using the device. A device
can also be “wiped” which erases some or all of the configuration, software, or data on
the device.
Components of MSP
The following are components of the Mobility Services Platform version 3.1.
MSP 3 Server
The MSP 3 Server is software application that is installed on a Windows Server 2003 or
Windows XP Professional computer 1 . The majority of the functionality of MSP is
implemented within this component.
MSP Client
The MSP 3 Client is a set of software components that come pre-installed on certain
Motorola Mobile Devices. The MSP 3 Client performs Staging and Provisioning functions
on Mobile Devices. Supported Mobile Devices that do not have the MSP 3 Client preinstalled on them can be upgraded via the Legacy Staging Process.
For information about the specific Mobile Devices supported by MSP 3, see the MSP 3
Device Compliance List 2 .
Begin at the following link: Software Downloads on Motorola Support Central
Then click the links titled “Mobility Software” and “Mobility Services Platform”.
Then locate the version of MSP you are interested in and click the appropriate link in
the “Software Downloads” section (e.g. “Mobility Services Platform (MSP) 3.1”).
1
See the MSP 3.1 Software Installation Guide for specifications on which versions of Windows are
supported for MSP 3.
2
The MSP 3 Device Compliance list is provided for convenience only and is not intended to be
comprehensive or complete. The release notes for the Mobile Device firmware release should be consulted
for the definitive statement on MSP 3 compliance.
Then click the appropriate link for the MSP 3 Compliance List (e.g. “MSP 3.1 Device
Compliance List”).
Note that Mobile Devices that do not come with the MSP 3 Client pre-installed will not
have full Staging functionality when they are “fresh out of the box”. Such devices can be
updated to have full Staging functionality by upgrading them to the appropriate MSP 3
Client using the Legacy Staging Process.
Relay Servers
To manage large numbers of devices, MSP uses intermediate servers called Relay
Servers, which run either the FTP or secure FTP (FTPS) protocol. Any computer or
device that can function as an FTP or secure FTP Server can be used as a Relay Server
so long as it complies with the relevant RFCs, as documented later in this document.
No FTP Server software is included with MSP 3. But FTP Server software can be
installed as part of Windows IIS or obtained from a variety of sources. At least one Relay
Server must be installed somewhere within the Enterprise in order for MSP 3 to be used.
AirBEAM Package Builder
When software is delivered to a device, it must be contained in a “Package” file. Package
files are created using the AirBEAM Package Builder program that is included and
installed as part of MSP.
Internet Explorer/MSP 3 Console UI
You use a Web Browser to access MSP 3 Server console functions. Web Browsers that
have been tested and supported with MSP include Microsoft Internet Explorer™ versions
6 and 7.
Network Overview
The figure on the next page illustrates the components that would be present in a typical
Enterprise network in which MSP 3 is deployed. Although this represents a typical
network, there are many variations possible:
•
•
MSP 3 Stage Edition
• The requirements to run MSP 3 Stage Edition are relatively lightweight and
therefore it could be installed on a laptop running Windows XP.
• At least one Relay Server (FTP or FTPS Server) is required to use MSP 3. A
Relay Server can be run on the same computer as the MSP 3 Server software, if
desired.
• A Web Browser is required to access the MSP 3 Console UI. A Web Browser
can be run on the same compute as the MSP 3 Server software, if desired.
• Based on the above, MSP 3 Stage Edition could be installed on a laptop
computer and configured to achieve a self-contained, fully mobile Staging
solution.
MSP 3 Provision Edition
• The requirements to run MSP 3 Provision Edition are more intensive and
therefore it should generally be installed on a server running Windows 2003
Server.
What is the Mobility Services Platform 5
•
•
•
• At least one Relay Server (FTP or FTPS Server) is required to use MSP 3. A
Relay Server can be run on the same computer as the MSP 3 Server software, if
desired.
• A Web Browser is required to access the MSP 3 Console UI. A Web Browser
can be run on the same compute as the MSP 3 Server software, if desired.
• Based on the above, MSP 3 Provision Edition should generally be installed on a
dedicated server to provide a robust and reliable Provisioning solution.
MSP 3 can be installed to run in a VMWARE environment, where Windows is running
in a virtual PC on any Operating System supported by VMWARE.
In MSP 3, Sites are optional, but can often greatly improve manageability when
Mobile Devices are used at multiple locations within the Enterprise.
MSP 3 requires TCP/IP-based network connectivity between the MSP Server, Relay
Servers, and Mobile Devices within the Enterprise. Possible types of connectivity to
Mobile Devices include Wireless LAN, Wireless WAN, and Microsoft ActiveSync™.
MSP 3 Server
MSP 3 Console UI via Web
Enterprise network
Relay Server
MSP Client
Relay Server
Site A
MSP Client
Site B
Chapter 2 Your Enterprise and MSP Objects
Understanding Your Enterprise
The most important thing to do BEFORE installing or using MSP 3 is to understand how
your Enterprise will be managed and how MSP 3 will manage the Mobile Devices within
your. The following figure identifies some of the places within the Enterprise that should
be considered and the questions that should be asked as part of the planning process for
an MSP 3 deployment.
The following sections provide additional detail to guide your thinking when assessing
your Enterprise and planning for your MSP 3 deployment.
Scalability
MSP 3 has been tested with varying configurations from small numbers of Mobile
Devices to very large numbers likely to exceed that found in most Enterprises. This
testing has demonstrated that MSP 3 can perform acceptably even when installed on
modest server hardware, such as that described in the MSP 3.1 Software Installation
Guide.
MSP 3 requires at least one Relay Server, which could be running on the same computer
as MSP or could be running on an external computer. Depending on the characteristics
of the Enterprise to be managed, it may be necessary or advisable to have multiple
external Relay Servers running on computers distributed throughout the Enterprise. The
ability of MSP 3 to scale to support the requirements of any given Enterprise is highly
variable, depending on the exact servers deployed and the connectivity between them.
To help provide a basis for comparison and estimation, the following specific MSP 3
configurations have been tested:
•
•
•
5,000 mobile devices when used with a single Relay Server running on the same
server hardware as MSP
5,000 mobile devices when used with 12 Relay Servers running on external server
hardware
100,000 mobile devices when used with 1,000 Relay Servers running on external
server hardware
Note: The above ratings are based on scalability testing performed under lab conditions on
servers that comply with recommended minimum hardware guidelines. These ratings
should be used as guidelines only. Depending on the exact nature of the Enterprise
being managed, the actual network organization, and the hardware capabilities of the
server(s) being used, actual achievable scalability will vary.
Network Topology and Connectivity
The locations at which Mobile Devices will be used within the Enterprise need to be
identified, along with the kinds of device usage expected at each location. The
connectivity that will be available to devices at various locations should be considered to
determine how best to configure an MSP 3 system to manage the devices.
Every device to be Staged or Provisioned by MSP will REQUIRE connectivity to a Relay
Server during the times when it is actually being Staged or Provisioned. This is generally
accomplished by using one or more device network adapters to provide access to one or
more networks.
In WLAN environments, connectivity to a private local area network is typically expected
to be nearly continuous. In WWAN environments, connectivity to a public or private
network may be sporadically available and/or intentionally restricted based on cost and/or
bandwidth issues. If cradles are used, connectivity to a private local area network will be
available only during periods when the device is in the cradle.
Your Enterprise and MSP Objects 9
Regardless of the type of connectivity used to provide the device with access to a
network from a particular location, the connectivity from that network to the Relay Server
that will be used to manage devices at that location must be considered. For example, a
retail store might have only a very low bandwidth connection to the central headquarters.
In such a case, having devices at the store contact a Relay Server at the central
headquarters, over that slow link, might be a poor choice.
Relay Servers can be located anywhere within the Enterprise as needed to meet the
needs of devices and to compensate for any connectivity issues or limitations that may
exist. In many cases, locating a Relay Server at a remote site may be the best way to
avoid unnecessary traffic over slow links. In other cases, regional Relay Servers might be
used to manage multiple locations that share higher bandwidth regional networks. In
other cases, wide area connectivity may be adequate to allow fully centralized
management.
It should also be understood that MSP 3 is a 3-tier system. An MSP 3 Server talks to one
or more Relay Servers and Mobile Devices also talk to those Relay Servers. This means
that MSP 3 Servers and Relay Servers need to be located in places where connectivity is
suitable for the communications they will interchange. As circumstances warrant, a Relay
Server can be located as near or far from its managing MSP 3 Server and as near or far
from the devices it is managing.
Security
Depending on the organization of the Enterprise and its network topology and
implementation, security requirements may vary. If the Enterprise network in which MSP
3, the Relay Servers, and the Mobile Devices will operate is inherently and consistently
secure, then there may be little need to consider security aspects when deploying MSP 3.
If, however, some segments or connections within the Enterprise network are less
secure, then it may be necessary to consider adjust the deployment MSP 3 to
compensate. The following sections explain some ways in which a deployment of MSP 3
might need to consider such security aspects.
Relay Server Communication
All management communications between MSP 3 Servers and Mobile Devices is
accomplished via one or more Relay Servers. Depending on where Relay Servers are
located within the Enterprise, some traffic may need to travel over less secure segments
of the Enterprise network.
MSP 3 supports either standard (non-secure) FTP or secure FTP (FTPS) for
communications between MSP 3 Servers and Relay Servers and between Relay Servers
and Mobile Devices. The primary difference between these two protocols is that secure
FTP encrypts both authentication and data traffic, thus securing it from unauthorized
access. In addition, secure FTP can help ensure that MSP 3 Servers and Mobile
Devices only talk to authentic Relay Servers, thus helping prevent “man in the middle”
attacks.
If all wired and wireless networks within the Enterprise are intrinsically secure, then
standard (non-secure) FTP may be perfectly acceptable. If, however, some segments of
the Enterprise network are not adequately secure, then secure FTP can help ensure that
MSP traffic is not compromised when traveling over these less secure segments.
MSP 3 Console UI User Authentication, Role, and Scope
The MSP 3 Console UI has User authentication to control who is allowed to access the
console and what they are allowed to do, based on their assigned role and scope. The
MSP 3 Console UI can be accessed via the HTTP protocol or, for added security, can be
accessed via the HTTPS protocol.
If all wired and wireless networks within the Enterprise are intrinsically secure, then HTTP
access may be perfectly acceptable. If, however, some segments of the Enterprise
network are not adequately secure, then HTTPS access can be used to help ensure that
MSP 3 Console UI traffic is not compromised when traveling over these less secure
segments. Detailed guidance on how to configure MSP 3 for HTTPS access is included
later in this document.
If HTTPS access is not possible or practical to configure and some Users need to access
the MSP 3 Console UI over a less secure network segment, then the User should be
required to first establish a secure connection (such as a VPN), thus allowing HTTP to be
used without compromising any MSP 3 Console UI traffic sent over the less secure
segment.
Network Naming/Addressing and Accessibility
Since the MSP 3 system consists of 3 tiers, the tiers must be connected together for
proper operation. The necessary connections are made using network names and/or
addresses.
Some networks may use static IP addressing and hence experience little change in
network addresses over time. Some networks may use dynamic addressing and hence
may be subject to periodic changes in network addresses. Some networks may use
naming (e.g. DNS, WINS) to provide indirection and hence allow the network to adapt
more easily to changes in the underlying network addresses due to dynamic addressing.
Some networks may also use Network Address Translation (NAT) to extend or
“compartmentalize” the Enterprise network address space. Some networks may also
utilize firewalls to limit certain kinds and directions or traffic. NATs and firewalls could
have implications on where servers are located with the Enterprise and/or how they are
addressed.
Names or addresses are needed to connect together MSP 3 system components in the
following ways:
User Access to MSP 3 Console UI
Since the MSP 3 Console UI is accessed via a Web Browser, Users will need to know the
network name or address of each MSP 3 Server they will access in order to direct their
Web Browser to the proper URL. Frequently, Users will create “shortcuts” within their
Web Browser to simplify repeated accesses to commonly used pages. If dynamic
addressing is used without naming, such shortcuts will become invalid if there is a
change to a referenced MSP 3 Server address. In such a case, the User would need to
manually update any affected shortcuts.
MSP 3 Server Access to Relay Server
Each MSP 3 Server needs to access one or more Relay Servers via the FTP or secure
FTP protocol. An MSP Relay Server Object must be created within MSP that specifies
the “Public” name or address of the Relay Server, which is the one that MSP 3 will use to
access that Relay Server.
If an address is used, the address must be contactable from the location where the MSP
3 Server resides, despite any NATs or firewalls. In the event that the address of a Relay
Server changes, the corresponding MSP 3 Relay Server Object will need to be modified
to match the new address.
Mobile Device Access to Relay Server
Each Mobile Device needs to access exactly one Relay Server whenever Staging or
Provisioning is performed. For Staging, the information about the Relay Server is
obtained from the Staging Profile. For Provisioning, the information about the Relay
Server must have been configured by a prior Staging or Provisioning operation.
In addition to the “Public” name or address defined for use by MSP 3, an MSP 3 Relay
Server Object must also specify a “Private” name or address of the Relay Server, which
is the one that Mobile Devices will use to access that Relay Server. The “Public” and
“Private” name or address might be the same or different depending on the situation (e.g.
NAT, etc.).
If an address is used, the address must be contactable from the location where the
Mobile Device resides, despite any NATs or firewalls. In the event that the “Private”
address of a Relay Server changes, the corresponding MSP 3 Relay Server Object will
need to be modified to match. Once the Relay Server Object has been updated, the new
Relay Server Settings will need to be delivered to all affected Mobile Devices. If the
Relay Server is not contactable at the old address being used by a Mobile Device, then
Provisioning cannot be used to update the Relay Server address and the device may
need to be Staged to perform the update. This could be avoided by updating the Relay
Server Settings to all Mobile Devices; if possible, before the address of the Relay Server
itself is actually changed.
Identifying Key Enterprise Objects
User(s)
Once the nature of the Enterprise is understood, it should be possible to identify the
various Users who will be using the MSP 3 Console UI in order to manage the Enterprise.
Each of the Users will be identified by a User ID and will have permissions to perform
various tasks based upon the User Role assigned to them. The available User Roles are
described in the following subsections.
User Roles
Administrator User
MSP Administrator is responsible for installing, managing, and maintaining MSP systems
within the Enterprise.
This role involves the following activities:
•
•
Install MSP on appropriate system(s)
Configure MSP to define the Site(s) and external server(s) to be used.
•
•
•
•
•
•
•
•
Perform backups and restores of MSP
Upgrade MSP to new versions as available
Define and maintain the User database on MSP
Define and manage the list of Users that are allowed to use MSP 3 Console UI
Define and manage the roles assigned to Users of MSP
Maintain User passwords and administrator password(s) of MSP
View or change MSP configuration or performance Settings
Administer Sites, Relay Servers, and Users
Operations User
Operations Admin can administer Staging and Provisioning operations, including:
•
•
•
Administer Settings, Packages, Message Sets, Bundles, Profiles, Conditions,
Policies, and Packages
Administer Device Attributes and Values
Control, activate, deactivate, restart, and troubleshoot Policies
Provisioning Only User
A User with the Provisioning role privileges has the rights to view the status of
Provisioning operations, including:
•
•
•
•
View Compliance summary and detail screens for Policies whose Object Names start
with an associated Policy prefix assigned to the User
View detail screens for Sites whose Object Names start with an associated Site prefix
assigned to the User
View detail screens for Devices associated with Sites whose Object Names start with
an associated Site prefix assigned to the User
Launch RemoteUI or RemoteControl from Device Detail pages for Devices
associated with Sites whose Object Names start with an associated Site prefix
assigned to the User
Staging Only User
A User with the Staging privileges has the rights to perform Staging operations, including:
•
•
•
•
Print or save barcode sheet PDF files for selected Profiles whose Object Names start
with an associated Profile prefix assigned to the User
Launch an On Demand Profile Server to serve up selected Profiles whose Object
Names start with an associated Profile prefix assigned to the User
Select target Sites from a list of Sites whose Object Names start with an associated
Site prefix assigned to the User
Select target Profiles from a list of Profiles whose Object Names start with an
associated Profile prefix assigned to the User
User Access Prefixes
In addition to a User Role, each User may also be given access to various Objects within
the MSP 3 Console UI. This is achieved by specifying a User Access Prefix for one of
more types of Objects. A User will be allowed to access only those Objects of a given
type whose Object Name begins with the User Access Prefix specified for that type of
Object for that User. For example, is the User Access Prefix for Sites for a given User
were “US.West”, then that User would be allowed to access a Site Object whose name
was “US.West.CA.Store107” but would not be allowed to access a Site Object whose
name was “US.East.NY.Store301”. The types of Objects for which User Access Prefixes
can be specified for a User include:
•
•
•
•
•
•
•
•
•
Bundles
Conditions
Messages
Packages
Policies
Profiles
Relay Servers
Settings
Sites
Network Settings
various Network Settings that will be used at various locations throughout the Enterprise.
For example, some locations may use WLAN networks; other locations might use
cradles, etc. Even locations that use the same type of network may use different
Network Settings (e.g. two locations may both use WLAN networks but have different
ESSIDs and/or require different encryption keys).
Identifying and recording information about the Network Settings that will be used
throughout the Enterprise will help to provide an indication of the complexity of the
Enterprise. And the Network Settings recorded will later need to be used to create MSP
3 Network Settings Objects that will be used to capture and apply those Settings to
devices.
Relay Server(s)
various Relay Server(s) that will be used throughout the Enterprise. Every MSP 3 system
requires at least one Relay Server, but some systems may have many Relay Servers,
depending on the scale and organization of the Enterprise network.
Identifying and recording information about the Relay Server(s) that will be used
throughout the Enterprise will help to provide an indication of the complexity of the
Enterprise. And the information recorded about the Relay Server(s) will later need to be
used to create MSP 3 Relay Server Objects.
Sites
Once the nature of the Enterprise and how it will be managed by MSP 3 is understood,
the various Sites within the Enterprise should be identified. It is important to note that
Sites are an OPTIONAL feature of MSP 3. An MSP 3 system CAN be configured that
does NOT use Sites. But in MOST cases, identifying, defining, and using Sites will result
in a system that is simpler to use and understand.
In MSP 3, a Site is a location at which Mobile Devices will be used. A Site may be a
Staging Site (a location where devices will be Staged) and/or a Production Site (a
location where Mobile Devices are used for non-Staging purposes, which may or may not
include Provisioning).
A Site should be identified when any of the following criteria are met:
•
Network Settings Vary by Location
In some cases, Network Settings will vary by location and Sites can be a great way to
track and manage these Settings. For example, if Staging centers use different
WLAN Settings than retail stores, then it likely makes sense to define Staging Sites
for the Staging centers and Production Sites for the retail stores.
This is even more important if the different Staging centers and/or different retail
stores use different Network Settings from each other. While it IS possible to
manage such varying Network Settings without using Sites, it would be much more
difficult and time consuming to do so.
Over time, as the Enterprise network changes, consolidation or differentiation of
Network Settings may occur across various locations. Rather than tracking down
every Object that might reference a specific Network Settings, it is much easier to
change the Network Settings assigned to the Site defined for a location. Then all
references to that Site will automatically use the new Network Settings.
•
Relay Server Settings Vary by Location
Depending on how the Enterprise network is organized, there may need to be
multiple Relay Servers to support the various locations. Sites can be a great way to
track and manage the assignment of Relay Servers to locations.
Over time, as an Enterprise evolves, Relay Servers may need to be changed or
added and locations may need to be changed to use different Relay Servers. Rather
than tracking down every Object that might reference a specific Relay Server, it is
much easier to change the Relay Server assigned to the Site defined for a location.
Then all references to that Site will automatically use the new Relay Server.
•
Device Tracking by Location
Often, the locations where devices are used within the Enterprise have important
contextual meaning and it is advantageous to leverage knowledge of the location
when managing the devices. Sites can be a great way to identify the locations of
devices.
In addition, Sites can be used to capture auxiliary information about the locations and
administrators associated with locations within the Enterprise. By defining a Site for each
location, relevant information about each location can be centralized and managed. If
any information about a Site changes later, the Site can be modified accordingly.
Key information to capture when identifying Sites should include:
•
•
•
•
•
•
Network Settings that will be used at the Site
Relay Server that will be accessed from the Site
Name or Designation of the Site
Address Information for the Site
Time Zone of the Site
Contact Information for the Site Administrator
Installing and Configuring Server(s)
Relay Server(s)
Once all the MSP Sites have been identified, the Relay Server(s) that will be used need
to be installed and configured for use at their appropriate locations within the Enterprise.
Relay Server(s) hardware should be selected to meet the needs of the expected number
of devices they will be used to manage and should be located to best balance the
connectivity both to their managed devices and to their managing MSP 3 Server(s).
Relay Server(s) must comply with RFCs 959 and 3659 for standard (non-Secure) FTP
and RFC 4217 for Secure FTP.
As Relay Servers are installed, the names or addresses of those servers (see section
above on Network Naming/Addressing and Accessibility) will need to be identified and
recorded. If NATs are used, it may be necessary to identify two different addresses for
each Relay Server.
Each Relay Server needs to have an account created for access by MSP and Mobile
Devices. This account must be granted all privileges (read, write, and delete) to a folder
that should be dedicated for use by MSP. The Username and password of each account
need to be recorded. And the path from the root of each account to the folder dedicated
for use by MSP 3 needs to be recorded.
Information recorded while installing and configuring Relay Servers will later be needed
to create MSP 3 Relay Server Object(s) within the MSP 3 Server(s) that will access them.
MSP 3 Server(s)
Once the Relay Server(s) that will be used are installed and configured, the appropriate
MSP 3 Servers need to be installed at their appropriate locations within the Enterprise.
MSP 3 Server(s) hardware should be selected to meet the needs of the scale of devices
they will manage and should be located to best utilize the connectivity to the Relay
Servers they will manage. MSP 3 Staging Edition could be run on a laptop computer with
Windows XP Professional with Service Pack 2. MSP 3 Provision Edition should generally
be run on a suitable server with Windows 2003 Server.
As the MSP 3 Server software is installed on various servers, the names or addresses of
those servers (see section above on Network Naming/Addressing and Accessibility) will
need to be identified and recorded. MSP 3 Server names or addresses will need to be
entered into the Web Browsers of Users accessing the MSP 3 Console UI(s) of those
server(s).
Creating MSP Objects
MSP Object Overview
Objects in MSP 3 are used to define how MSP 3 will operate. There are many types of
Objects in MSP 3, so to make describing them easier, they are organized into categories.
The primary Object categories in MSP 3 are Enterprise Objects, Content Objects,
Staging Objects, and Provisioning Objects. The various types of Objects in MSP 3 will be
discussed in more detail by category in the following sections.
MSP Object Naming
Objects in MSP 3 are created and managed using the MSP 3 Console UI. Every Object
must have a name and Object Names are generally limited to Letters, Digits,
underscores, and dots.
When used in some Object Names, dots are used to indicate hierarchy. For example,
Site Object Names such as US.West.CA.SJ and US.West.CA.SF indicate that the Sites
should be organized into a tree-based hierarchy. The use of the above Sites would
create logical “regions” and “sub-regions” called, us, west, and ca. Additional Sites would
be located within the tree based on their names.
“Dotted names” can also be used to control the access to Objects by Users. Different
Users in MSP 3 can have their scope of access controlled by specifying one or more
User Access Prefixes in the User Object that defines that User’s credentials and
capabilities. User Access Prefixes are defined by Object Type and limit each User to
have access only to Objects whose name begins with the User Access Prefix specified
for that type of Object for that User.
For example, if the Site User Access Prefix for a User were US.West, then that User only
be able to access Sites (and devices assigned to Sites) whose Object Names start with
US.West, thus assigning geographical access scope to the User. While the above
example shows using Site naming for both Site hierarchy and for access scoping, this is
not mandatory. For example, a pair of Bundle Objects might be called Shipping.Bundle1
and Shipping.Bundle2, thus enabling access scope based on User function (Shipping)
totally independently of the type of scoping used for Sites.
Every Object must have a name that uniquely identifies it from all other Objects of the
same type. Objects of different types can have the same name, and this is sometimes
desirable if the Objects are interrelated. For example, a Bundle Object might have the
name Deploy.MyApplication and a Provisioning Policy Object that references that Bundle
might have the same name. By using such an approach, it may be easier to see that the
Objects, although of different types, are closely related. Such a naming approach can
also help organize access control since the same User Access Prefix can be used for
several types of related Object for a given User.
MSP Enterprise Objects
The following Enterprise Objects should generally be created and applied to configure
each MSP 3 Server to prepare it to support the Enterprise, or a portion thereof. Note that
while Enterprise Objects can be added or modified at any time, for maintenance
purposes, most Enterprise Objects would typically be created by a User with the Admin
User Role soon after an MSP 3 Server is installed.
Enterprise Objects can be created in any order, except for when one type of Object
references another, in which case the referenced Object must be created before the
referencing Object can be created. The different types of Enterprise Objects are
presented below in the order they would normally need to be created in order to ensure
that referenced Objects exist before they are needed.
The following figure illustrates the types of Enterprise Objects and identifies both which
types of Objects can reference other types of Objects and provides some guidelines on
how they match up to real-world entities within the Enterprise.
Network Settings Objects
Network Settings Objects are a special case of Settings Objects, which are, strictly
speaking, Content Objects not Enterprise Objects. But since Network Settings Objects
are commonly referenced by Site Objects, they generally need to be one of the first types
of Objects created. So, for the purposes of this discussion, we will consider Network
Settings Objects that are referenced by Site Objects to be “honorary” Enterprise Objects.
For each unique combination of Network Settings in use at one or more locations within
the Enterprise, a separate Network Settings Object should be created. Note that if
multiple MSP 3 Servers will be used, it may make sense to apply some or all of the same
Network Settings Objects to more than one MSP 3 Server. Whether or not this makes
sense depends on how Network Settings are used within Enterprise.
In MSP 3.0, Network Settings Objects could only be created and edited using the MSP
3.0 Object Builder utility, not directly using the MSP 3.0 Console UI. Beginning with MSP
3.1, Network Settings Objects are created and edited from the Settings sub-tab of the
Library tab of the MSP 3 Console UI. Consequently, the MSP Object Builder utility will no
longer be provided or supported from MSP 3.1 onwards.
Relay Server Objects
For each unique Relay Server that will be managed by a given MSP 3 Server, a separate
Relay Server Object should be created. In MSP 3, Relay Server Objects are created and
edited from the Relay Servers sub-tab of the Admin tab of the MSP 3 Console UI.
Note that if multiple MSP 3 Servers will be used, it is generally NOT RECOMMENDED to
share the same Relay Server Objects with more than one MSP 3 Server. This is
because only one MSP 3 Server should be interacting with a specific Relay Server at one
time. If more than one MSP 3 Server was trying to access the same Relay Server at the
same time, conflicts would result, leading to unpredictable operation.
When defining a Relay Server Object, the key attributes that determine uniqueness are
the “Public” and “Private” names or addresses, the usernames and passwords, and the
folder path. Only one active MSP 3 Server should be defined to use any one
combination of values for these key attributes. Any differences in ANY of these key
attributes results in a unique Relay Server. It is therefore possible for multiple MSP 3
Servers to “share” a given FTP or FTPS Server, as long as the Relay Server Objects are
defined to use “parallel” accounts or folders to keep the traffic for different MSP 3 Servers
segregated.
Site Objects
For each unique Site that will be managed by a given MSP 3 Server, a separate Site
Object should be created. In MSP 3, Site Objects are created and edited from the Sites
sub-tab of the Admin tab of the MSP 3 Console UI.
Site Objects frequently reference Network Settings Objects and/or Relay Server Objects.
All referenced Objects must be created before they can be referenced.
User Objects
For each unique User that will be allowed to log in to a given MSP 3 Server, a separate
User Object should be created. In MSP 3, User Objects are created and edited from the
Users sub-tab of the Admin tab of the MSP 3.0 Console UI.
Users are defined by specifying the identification information for the User, specifying
authentication credentials, and by specifying information about the Role and Scope that
will be enabled for that User.
In some cases it might well be appropriate to share User Objects between multiple MSP
3 Servers, if the same Users are desired to have the same access to each.
SMS Carrier Objects
In order to perform SMS-Based Staging, MSP 3 needs some information about the
various WWAN carriers (service providers) that will be used to provide WWAN
connectivity for Mobile Devices. This is accomplished via SMS Carrier Objects.
For each unique WWAN carrier (e.g. Cingular, Verizon, Sprint, etc.) that will be used, a
separate SMS Carrier Object should be created. An SMS Carrier Object identifies the
method, addressing, and credentials required for delivering SMS messages to devices
via that carrier. SMS messages can be delivered via SMTP (Simple Mail Transport
Protocol) or SMPP (Short Message Point-to-Point Protocol), depending on the specific
carrier.
MSP Content Objects
Once an MSP 3 Server is properly configured to work with and support the various
entities within the Enterprise, Content Objects must be created and uploaded into the
MSP 3 Object Library before there will be anything available to Stage or Provision.
Content Objects are described before the Staging and Provisioning Objects that
reference them because they need to be created before they can be referenced. In
actual use, the creation and management of Content Objects may be intermixed with
Staging and Provisioning Objects as the Staging and Provisioning needs of the
Enterprise evolve.
The following figure illustrates the types of Content Objects and identifies both which
when and why they would be used.
Packages
Packages are the primary unit of Content in MSP 3 and define files and folders to be
delivered to and commands to be executed on Mobile Devices. Packages can be
created automatically by MSP 3, in some cases (e.g. Settings Packages), or Packages
can be User-defined.
User-defined Packages are created using either the AirBEAM Package Builder, which
can be installed on any Windows PC via the MSP 3 Installer or using the AirBEAM OS
Update Package Builder, which is specifically for building OS Update Packages and is
available for download from the Symbol Beta Zone at the following link:
http://devzone.symbol.com/betazone.cfm?nav=2.
Once User-defined Packages have been created using the appropriate Package
Builder(s), they can be uploaded into MSP 3 Object Library from the Packages sub-tab of
the Library tab of the MSP 3 Console UI. Once Packages are in the MSP 3 Objects
Library, they can be referenced in Bundle Objects which can then be referenced by
Staging and/or Provisioning Objects.
Package Versions
Versioning of Packages is a valuable MSP 3 feature that allows for management of
different versions of a Package without the requirement of renaming them.
Navigating to the Library->Packages page will display a list of Packages by name and
version. Clicking on the Package name link (e.g. abup30) will display the Packages>Package Detail page. Hitting the “Manage” button on this page will display the different
versions of the Package available and the Bundles that contain steps referencing each
version of the Package. The User may change the version referenced by a Bundle by
selecting the check box for that Bundle and then selecting the desired version in the
“Change To” drop down list. Save the change by hitting the “Apply” button.
A note worthy feature in Package versioning is the ability of MSP 3.1 to make
modifications to a Package without deactivating Policies. For example a Bundle step
may be modified to include a newer version of a Package. After hitting the “Finish” button
a Warning will be displayed listing the Policies that will be deactivated upon completion
of the edit. If you wish to leave one or more affected Policies active, simply select the
“check box” for the Policies that should Remain Active and hit the “Save” button.
Settings Objects
Settings Objects define configuration changes to be made to Mobile Devices. Settings
Objects can be directly applied to Mobile Devices by referencing them from a Staging
Profile Object. Settings Objects can also be used as an alternate form of Content in MSP
3 by referencing them from a Bundle Object. When used as Content, MSP 3
automatically creates the Settings Packages required to deploy and apply them.
In MSP 3.0, Settings Objects could only be created and edited using the MSP 3.0 Object
Builder utility, not directly using the MSP 3.0 Console UI. Beginning with MSP 3.1,
Settings Objects are created and edited from the Settings sub-tab of the Library tab of the
MSP 3 Console UI. Consequently, the MSP Object Builder utility will now longer be
provided or supported from MSP 3.1 onwards.
Additional information on Settings Objects is contained in Appendix A, later in this
document.
Message Set Objects
Message Set Objects are Objects that allow messages to be optionally associated with
Bundle Objects so they can be presented to Mobile Device Users during Provisioning.
In MSP 3.0, Message Set Objects could only be created and edited using the MSP 3.0
Object Builder utility, not directly using the MSP 3.0 Console UI. Beginning with MSP
3.1, Message Set Objects can be created and edited from the Message Sets sub-tab of
the Library tab of the MSP 3 Console UI. Consequently, the MSP Object Builder utility
will now longer be provided or supported from MSP 3.1 onwards.
Bundle Objects
Bundle Objects are the primary unit of Staging and Provisioning in MSP 3 and define the
Deployment Steps to be performed during Staging or Provisioning operations.
A Bundle Object can specify any number of Packages to be installed or uninstalled, in
any order. When installing a Package, a Bundle can also specify that the Package
should “Force Install”, which means that it will be installed even if the same version of the
Package is already present on a device. This overrides the default behavior where a
Package is “skipped” if the same version of that Package is already on the device. This
can be useful with “Control” Packages, where the primary purpose of the Package is to
perform a “Control Action”, not to deliver Content.
A Bundle Object can also specify that reboots be performed at any point amidst the
installing and uninstalling of Packages. A Bundle Object can optionally specify a
Message Set Object to cause messages to be presented to the Mobile Device User
during Provisioning of that Bundle.
In MSP 3, Bundle Objects are created and edited from the Bundles sub-tab of the Library
tab of the MSP 3 Console UI.
Bundle Objects can reference Packages and/or Settings Objects. Note that any
referenced Objects must be created before they can be referenced.
Staging Objects
The following figure illustrates the types of Staging Objects and identifies both which
Staging Profile Objects
Staging Profile Objects define the operations to be performed during Staging in MSP 3.
Staging Profile Objects can reference Settings Objects to define how to configure Mobile
Devices and/or a Bundle Object to define Content to deploy to Mobile Devices.
In MSP 3, Staging Profile Objects are created and edited from the Staging Profiles subtab of the Staging tab of the MSP 3 Console UI.
To perform Staging on “fresh out of the box” Mobile Devices, some configuration of the
devices (e.g. configuring a network connection and Relay Server) is almost always
required to prepare the devices for Content deployment. It may sometimes be desirable
to re-Stage devices if they need to be reconfigured for alternate uses. Settings Objects
provide a generic and extensible means to define and apply configuration to Mobile
Devices. Settings applied directly during Staging are called Staging Settings.
Staging Objects can be made into Staging Settings by using the “Inherit from Site” option
when creating a Staging Profile Object, causing it to inherit all Settings Objects defined
as part of a referenced Staging Site. Alternately, Staging Objects can be made into
Staging Settings using the “Select pre-defined Settings” option to explicitly reference one
or more Settings Objects when creating a Staging Profile Object.
It is important to note that Staging Settings are applied first, before any Content is
deployed. This is a critical distinction since successful Content deployment often relies
on the configuration performed by the Staging Settings. It is possible to define a Profile
that has no Content to deploy (i.e. specifies no Bundle), in which case the ONLY action
performed by the Staging operation would be the configuration defined by the Staging
Settings. This might be done, for example, if the ONLY purpose of the Staging was to
(re)configure a device onto a wireless network.
It is also important to note that Staging Settings are, by definition, transient. Staging
Settings are applied when Staging is performed. While the configuration changes made
by Staging Settings are NOT removed when the Staging is complete, neither is any
specific action made to make them persist. As a result Staging Settings generally will
NOT persist across subsequent cold/clean boots (depending on the device). This is
intentional and, after consideration, will be seen as desirable. Staging Settings have no
versioning or traceability and hence, if they WERE made persistent, there would be no
way to detect that they were present or to remove them if they became obsolete.
In SOME cases, certain Settings classes (e.g. Network.WLAN.*) may provide their own
built-in persistence mechanisms, for backward compatibility with prior versions of MSP.
The use of these legacy persistence methods is not recommended, however, since MSP
3 provides a more flexible and reliable method of accomplishing persistence, one that
can be applied to ALL classes of Settings Objects.
When Settings Objects are converted into Packages by MSP 3, they are referred to as
Settings Content. Settings Content is, by definition, persistent. Settings Packages
deployed as Content to devices are persistent because they will automatically be reapplied as needed, thus making them automatically persist across cold/clean boots. This
is the recommended way of accomplishing persistence since it can be applied to ALL
classes of Settings Objects, even ones added through the development of Plug-Ins.
Settings Objects can be made into Settings Content by referencing them in an install step
when creating a Bundle Object. Settings Objects can alternately be made Settings
Content by referencing them in a Production Site and inheriting Settings from that
Production Site in a Staging Profile Object.
A key advantage of using Settings Content is that since Settings Objects are packaged,
they are also versioned. This makes sense when you think about it. Anything that is
persistent should be traceable and versioned. Otherwise it could be very difficult to
accurately determine the state of a device or how it got that way. MSP 3 uses tried-andtrue AirBEAM Packages to achieve persistence, traceability, and versioning of Settings
Content.
The actual Content to be deployed by a Staging Profile Object (if any), is specified by
referencing a Bundle Object, which MUST already have been defined.
Staging Options Within Staging Objects
Staging Options can be defined as part of a Staging Profile Object to define the Staging
Method(s) that will be allowed to be used when Staging the Profile and the default types
of barcodes that will be generated (if the Barcode Staging Method is selected).
MSP 3.1 supports the following Staging Methods:
•
Barcode-Based Staging
A Staging Profile can be rendered as barcodes in an Adobe Acrobat™ PDF file from
the Staging Profiles sub-tab of the Staging tab of the MSP 3 Console UI using the
Barcode Create link. The barcodes in the PDF file can be printed directly or the PDF
file can be transmitted elsewhere for later printing. Once printed, barcodes can be
scanned by a device to obtain the information required to perform the Staging for the
Staging Profile. Depending on the type of barcode scanner present on a device, it
may also be possible to scan barcodes directly from the PDF file displayed on a
computer screen.
•
On Demand (Electronic) Staging
A Staging Profile can be pulled directly from an On Demand Profile Server running
within the Web Browser on a computer from which the MSP 3 Console UI is being
run. The On Demand Profile Server can be invoked from the Staging Profiles subtab of the Staging tab of the MSP 3 Console UI using the Method On Demand link.
Profiles can be electronically served-up to Mobile Devices via various types of
connections, including:
• Microsoft ActiveSync™ Connection
An IP connection is typically automatically established when a device is directly
connected to a computer running Microsoft ActiveSync™ via a USB or serial
cable or cradle. The most common configuration would be where the On
Demand Profile server is running on the computer to which the device is
connected via Microsoft ActiveSync™. It would also work on with the On
Demand Profile Server running on any other computer that is on the same
subnet as the computer to which the device is connected via Microsoft
ActiveSync™.
If a Microsoft ActiveSync™ connection is established and if an On Demand
Profile Server is running on a computer that is on the same subnet that is
accessible from the connection, then Electronic Staging can proceed using that
connection.
• Ethernet Cradle Connection
With an Ethernet cradle, an IP connection is typically automatically established
when a device is inserted into an Ethernet cradle that is plugged directly into an
Ethernet LAN backbone. Some devices come ready to use with their Ethernet
cradles while others require software to be installed and configured before the
Ethernet cradle connection can be established. The MSP 3 Rapid Deployment
Client does not provide any means to install Ethernet cradle software or
configure or establish an Ethernet cradle connection, but can use Ethernet
cradle connections for Staging, if they exist.
If an Ethernet cradle connection exists and if an On Demand Profile Server is
running on a computer that is on the same subnet that is accessible from the
connection, then Electronic Staging can proceed using that connection.
• Existing WLAN Connection
If a WLAN IP connection is already configured and established, and if an On
Demand Profile Server is running on a computer that is on the same subnet that
is accessible from the connection, then Electronic Staging can proceed using that
connection.
• Well-Known WLAN Connection
The MSP 3 Rapid Deployment Client (a.k.a. Staging Client) can be asked to
attempt to configure and establish WLAN IP connections using pre-defined
Motorola WLAN Settings.
If the Staging Client is able to successfully configure and establish such a
connection, and if an On Demand Profile Server is running on a computer that is
on the same subnet that is accessible from the connection, then Electronic
Staging can proceed using that connection.
•
SMS-Based Staging
A Staging Profile can be pushed directly to WWAN-equipped Mobile Devices by
converting the Profile into a sequence of SMS messages and sending those
messages to the device. SMS Staging can be initiated from the SMS Staging Jobs
sub-tab of the Staging tab of the MSP 3 Console UI using the Create button.
The MSP 3 SMS Staging Client will intercept SMS Staging Messages and
reassemble them into the original Staging Profile on the device. The device User can
then elect to execute the Staging Profile to Stage the devices.
SMS Device Objects
In order to perform SMS-Based Staging, MSP 3 must have some information about the
devices that will be Staged so it can deliver SMS messages to the devices. This is
accomplished by creating SMS Device Objects to capture the required information, such
as the device phone number, hardware identification number, and assigned carrier.
When performing SMS Staging, a Profile can be sent to one or more devices identified by
SMS Device Objects.
Provisioning Objects
The following figure illustrates the types of Provisioning Objects and identifies both which
Condition Objects
Condition Objects are used to limit the MSP 3 Agent from performing operations on a
Mobile Device unless certain conditions are met on that device.
In MSP 3.0, Condition Objects could ONLY be used as Readiness Conditions to control
when Job Execution could occur. In MSP 3.1 and up, Condition Objects can also be
referenced by Settings Objects. This new capability is described in more detail in
Appendix A, later in this document.
In MSP 3.0, Condition Objects could only be created and edited using the MSP 3.0
Object Builder utility, not directly using the MSP 3.0 Console UI. Beginning with MSP
3.1, Condition Objects are created and edited from the Conditions sub-tab of the Library
tab of the MSP 3 Console UI. Consequently, the MSP Object Builder utility will now
longer be provided or supported from MSP 3.1 onwards.
Additional information on the capabilities and usage of Condition Objects is contained in
Appendix A, later in this document.
Provisioning Policy Objects
In MSP 3, Provisioning Policy Objects are created from the Policy Management sub-tab
of the Provisioning tab of the MSP 3 Console UI.
There are two types of Provisioning Policies: On-Going and Manual. On-Going Policies
periodically evaluate applicability and Compliance and automatically take action as
required to ensure Compliance. Manual Policies periodically evaluate applicability and
Compliance, but take action to achieve Compliance ONLY when initiated via the MSP 3
Console UI. Aside from the method of initiation, the actual operation of the two types of
Policies is identical.
When defining a Provisioning Policy, Applicability Rules define the Mobile Devices to
which the Policy is Applicable. A Policy can either be defined to apply to “All Devices” or
a “Custom Rule” can be created. A custom rule allows expressions using any or all
available Device Attributes to be used to determine the Applicability of the Policy.
The Content to be deployed by a Provisioning Policy Object is specified by referencing a
Bundle Object. All referenced Objects must be created before they are referenced.
To prevent Provisioning operations from occurring on devices except under specific
conditions, Readiness Conditions can be specified as part of a Provisioning Policy
Object. Readiness Conditions are specified by referencing one or more Condition
Objects. All referenced Objects must be created before they are referenced.
A Policy can have multiple Condition Objects specified, in which case an implicit AND will
be applied to all specified Condition Objects. This means that ALL specified conditions
will have to be met before the Job created to implement the Policy will be executed on a
device. If any conditions are not met, then the Job for that Policy for that device will be
deferred and re-evaluated each time the device checks in until the Job is able to execute.
Chapter 3 Performing Staging
Once a Staging Profile Object is defined in MSP 3, the Profile defined by the Object can
be Staged into one or more Mobile Devices. It is important to remember that Staging is
always an operation that is initiated by and hence requires the attendance of a Mobile
Device User. The Staging Options, defined as part of the Staging Profile Object,
determines which methods the Mobile Device User is allowed to use to Stage the Profile.
Before a Mobile Device User can Stage a Profile the Profile must be made available.
•
For Barcode-Based Staging, find the Profile in the list of Profiles shown on the
Staging Profiles sub-tab of the Staging tab of the MSP 3 Console UI and click the
Barcode Create link to produce an Adobe Acrobat™ PDF file containing the
barcodes. The barcodes in the PDF file can be printed directly or the PDF file can be
transmitted elsewhere for later printing. Once printed, barcodes can be scanned by a
device to obtain the information required to perform the Staging for the Staging
Profile. Depending on the type of barcode scanner present on a device, it may also
be possible to scan barcodes directly from the PDF file displayed on a computer
screen.
• For On Demand (Electronic) Staging, find the Profile in the list of Profiles shown on
the Staging Profiles sub-tab of the Staging tab of the MSP 3 Console UI and click the
Method On Demand link. This will
• For SMS Staging, go to the SMS Staging Jobs sub-tab of the Staging tab and click
the Create button.
Further details on the exact process followed for each Staging Method is provided in the
following sections.
Staging Methods
Barcode-Based Staging
How Barcode-Based Staging Works
The following figure illustrates the basic operation of Barcode-Based Staging Method.
In accordance with the above figure, the Barcode-Based Staging Method process
proceeds as described below:
•
An MSP 3 Console UI User creates Content and Staging Objects which describe the
Staging Operation to be performed. In general, this consists of:
• Ensuring that any Site and/or Relay Server Objects exist in the MSP Library, and
creating any that are not.
• Ensuring that all required Packages exist in the MSP Library, and creating and
uploading any that are not.
• Ensuring that all required Settings Objects exist in the MSP Library, and creating
any that are not.
• Creating a Bundle to desribed the exact deployment steps to be performing,
including:
• Install any required Packages and/or Settings Objects
• Uninstall any desired Packages
• Perform any required deployment steps
Performing Staging 29
•
Do all of the above in the proper relative order
• Creating a Staging Profile to inherit from the proper Sites or specify the proper
Settings Objects and to specify the Bundle.
•
The MSP 3 Server delivers Content to Relay Server(s), including:
• Determines which Relay Server(s) require the Bundle.
• Delivers each Package (.APD file and subfolder) that is referenced by the Bundle
to the designated folder of each Relay Server that requires the Bundle if the
Relay Server does not already have that Package.
• Delivers the Bundle (.BDL file) to the JOBS sub-folder of each Relay Server that
requires it.
•
An MSP 3 Console UI User selects a single Staging Profile and requests to print a
barcode sheet for Staging one or more devices.
A Mobile Device User invokes the Rapid Deployment function on a device and scans
the barcodes on the barcode sheet appropriate for the Site at which the device is
being Staged, the Site at which the device will be used, and the Staging Operation to
be performed.
The MSP 3 Staging Client configures the device as specified by the Staging Profile,
contacts the Relay Server, downloads the Bundle, and performs the deployment
steps, including installing or uninstalling Packages or performing specified reboot(s).
The MSP 3 Staging Client pushes a Discovery Document (.XML file), describing the
device, to the DISCOVERY sub-folder on the Relay Server.
The MSP 3 Staging Client pushes a Staging Log (.completed or .failed file),
describing the results of the Staging operation, to the LOGS sub-folder of the Relay
Server.
The MSP 3 Server pulls the Discovery Document and adds the device to the list of
Staged Devices and pulls the Staging Logs and stores it for reference in the MSP 3
Database.
An MSP 3 Console UI User consults the list of Staged Devices to see which devices
have been Staged. For any device, he can also consult the Staging Logs to see
what was Staged or to troubleshoot any Staging issues.
•
•
•
•
•
•
How to use Barcode-Based Staging
To generate barcodes for a single Staging Profile, click the “Create” link on the Staging
Profiles sub-tab of the Staging tab of the MSP 3 Console UI to bring up the Generate RD
Barcode Sheets page for the selected Profile. In MSP 3, it is not possible to generate
barcodes for multiple Profiles at once.
When the Generate RD Barcode Sheets page is displayed, it will show default values for
the type(s) of barcodes to be produced based on what was defined in the Staging
Options defined in the Staging Profile Object. The type(s) of barcodes to be produced
can be changed before generation if the defaults do not suit the situation.
Once the options are set correctly, clicking the “Generate” button creates and opens an
Adobe Acrobat™ PDF file containing printable barcode sheet(s). The free Adobe
Acrobat™ reader must be installed on the computer running the MSP 3 Console UI in
order to view or print barcodes sheets. The PDF file can also be saved and then
transmitted to other locations for remote use.
Once the barcode sheets are printed, they can be used to Stage devices. Simply launch
the MSP 3 Rapid Deployment Client and scan the barcodes on the barcode sheet(s). If
the device has an imager-based barcode scanner, it MAY also be possible to scan
barcodes directly from the computer screen, depending on the screen type, lighting
conditions, and device barcode scanner performance.
Note that barcodes can be generated in one of two “RD Compatibility” modes: MSP 3 or
MSP 2.X. If a Mobile Device currently has a Rapid Deployment Client version less than
3, then ONLY barcodes created in 2.X “legacy” mode can be used. Such barcodes will
be limited by the capabilities of the Rapid Deployment Client present on the device
(which must be indicated).
If a Mobile Device has an Rapid Deployment Client version of 3 or higher, then barcodes
created in EITHER mode can be used, but MSP 3 compatible barcodes will provide the
most functionality and hence are recommended.
If a mixture of devices with varying Rapid Deployment Client versions need to be Staged
with a single set of barcodes, then the lowest version of Rapid Deployment Client present
on any device should be selected.
On Demand (Electronic) Staging
How On Demand (Electronic) Staging Works
The following figure illustrates the basic operation of the On Demand (Electronic) Staging
Method.
In accordance with the figure above, the basic operation of On Demand (Electronic)
Staging proceeds as follows:
•
•
Staging Operation to be performed. In general, this consists of the same steps
described above for Barcode-Based Staging.
•
•
•
•
•
•
•
•
•
•
requires it.
An MSP 3 Console UI User selects one or more Staging Profiles and requests to
Stage them On Demand.
The MSP 3 Server gathers together the selected Staging Profiles with the On
Demand Server and delivers it to the PC.
The MSP 3 Console UI User starts the On Demand server that is now running in the
Web Browser on his PC.
A Mobile Device User invokes the Rapid Deployment function on a device and
requests either the Search Connected Networks or Search Unconnected Networks
function.
The MSP 3 Staging Client locates the On Demand Server running on the PC and
downloads a Staging Profile from it.
Server.
Database.
How to use On Demand (Electronic) Staging
To serve up a single Staging Profile to one or more Mobile Devices, click the “On
Demand” link in the Method column of the Staging Profiles sub-tab of the Staging tab of
the MSP 3 Console UI to cause the On Demand Profile Server to be opened and serve
up the single Profile selected.
To serve up multiple Profiles at once, check the boxes at the far left of all desired Profiles
and then click the “On Demand Staging” button to cause the On Demand Profile Server
to be opened and serve up all the selected Profiles.
When the On Demand Profile Server is opened, the Staging Server page is presented.
The selected Profile(s) are downloaded to Web Browser along with the On Demand
Profile Server, which is executed on the computer within the context of the Staging
Server page. Once the Staging Server page is displayed, click the “Turn Staging server
on” button to enable the On Demand Profile Server and begin serving up the selected
Profile(s).
Once the Staging Server is on, it can be used to Stage one or more devices. Simply
launch the Rapid Deployment Client, click the “Options” button, and then select either the
“Search Connected Networks” option or the “Search Unconnected Networks” option.
Connected Networks are Networks that are already connected and can be checked to
see if a Staging Server can be found. Unconnected Networks are the Well-Known WLAN
connections that are automatically configured and established to see if a Staging Server
can be found.
When requested by one of the above options, the Rapid Deployment Client will begin
searching for a Staging Server. If it finds one, it will get a list of all Profiles being served
that are suitable for Staging on that device (based on Model and OS only). This could
lead to one of the following results:
•
There are no suitable Profiles being served
In this case, a message will be displayed to the device User and the Staging process
will terminate.
•
There is exactly one suitable Profile being served
In this case, the single suitable Profile will be executed automatically.
•
There are multiple suitable Profiles being served
In this case, the device User will be presented with a list of all suitable Profiles and
requested to select one for execution.
The Staging Server page will hold the selected Profile(s) as long as it is open. The
Staging Server can be kept open, whether on or off, as long as is necessary, but should
be closed, using the “Exit” button, when it is no longer needed. Note that any changes to
Staging Profile Objects made within the MSP 3 Console UI will NOT be reflected in the
Profiles served by the Staging Server, since the Profiles are cached within the Staging
Server. When the server is closed and reopened, the Profiles will be re-downloaded and
hence will reflect any changes that may have been made.
The Staging Server will keep track of and display the number of and identity of devices
that have been Staged since it was turned on. The Staging Server can be left running as
long as necessary, but should be stopped, using the “Turn Staging server off” button,
when it is no longer needed. Note that each time the server is turned off, the number of
devices Staged will be set back to zero and the list of device identities will be cleared.
SMS Staging
How SMS Staging Works
The following figure illustrates the basic operation of the SMS Staging Method.
In accordance with the figure above, the basic operation of SMS Staging proceeds as
follows:
•
•
•
Staging Operation to be performed. In general, this consists of the same steps
described above for Barcode-Based Staging, but in addition this consists of:
• Ensuring that an SMS Carrier Object is created to describe each Cellular Carriers
over which SMS messages will be sent to Stage one or more devices.
• Ensuring that an SMS Device Object is created for each device that will be
Staged using SMS.
requires it.
An MSP 3 Console User selects a single Staging Profile and requests to Stage it via
SMS Staging to a collection of SMS Devices.
•
•
•
•
•
•
•
The MSP 3 Server converts the Staging Profile into a set of SMS messages for each
SMS Device and delivers the SMS messages via the associated SMS Carrier for
each SMS Device.
A Mobile Device User determines that a Staging Profile is available on a device and
requests to process it.
Server.
Database.
How to use SMS Staging
When devices are equipped with WWAN radios and have been set up with data service
from WWAN carriers that provide ‘short message service’ (SMS) text messaging, SMS
Staging can be used to push a Staging Profile to one or more devices. In order to
support SMS Staging, a Mobile Device must have the MSP 3 SMS Staging Client
installed in order to detect and process the SMS messages that will be used to deliver the
Profile to the device.
To deliver a Staging Profile to one or more Mobile Devices using SMS Staging, go to the
SMS Staging Jobs sub-tab of the Staging tab of the MSP 3 Console UI and click the
Create button. In MSP 3, it is not possible to send more than one Staging Profile via
SMS Staging in a single SMS Staging Job. The following MSP 3 Objects items are
required to use the SMS Staging Method:
•
•
•
SMS Carrier Object(s) define the cellular provider (e.g. Cingular, Verizon, etc.) that a
device uses for cellular service and SMS message delivery. SMS Carrier Objects are
typically defined in advance by a User with the Administrator Role for use during later
SMS Staging operations.
SMS Device Object(s) defines individual WWAN-enabled devices that can be Staged
using SMS Staging. Each SMS Device Object references an SMS Carrier Object,
which must already exist. SMS Device Objects must exist before they can be used to
Stage devices using the SMS Staging Method.
A Staging Profile Object must exist to define the Staging to be performed before the
SMS Staging Method can be invoked.
When a Mobile Device with SMS Staging capability receives SMS Staging messages, it
will consume them, extract the Staging Profile encoded within them, and make the Profile
available to the User for Staging. Note that SMS Staging is not automatic and requires
User intervention to actually initiate the Staging process based on an extracted Staging
Profile. The User will be notified via a pop up window and an SMS message in their inbox
that a Staging Profile is available for Staging. The User must manually launch the SMS
Staging Client software, choose a Staging Profile, and initiated the Staging process.
The details and needed steps for configuring Objects for SMS Staging and the tasks
required to perform SMS Staging are the following.
The following steps describe how to perform SMS Staging:
•
•
•
•
•
•
A User creates SMS Carrier Object(s) using the MSP 3 Console UI.
A User creates Staging Profile Object (s) using the MSP 3 Console UI.
A User creates SMS Device Object (s) using the MSP 3 Console UI.
A User creates SMS Staging Job using the MSP 3 Console UI.
A Mobile Device User interacts with the SMS Staging Client on a Mobile Device and
initiates Staging.
A User tracks Staging status using the MSP 3 Console UI.
Viewing and Reporting on Staging Status
The Staging Status of the one or more devices can be viewed using the Staged Devices
sub-tab of the Staging tab of the MSP 3 Console UI. A device will appear in on the list
of Staged Devices only when it successfully completed Staging via MSP 3.
Click on the link to a device in the “Device ID” column to display the Device Detail page
containing detailed information regarding the device. The Device Attributes section
displays information determined about the device during the Staging process. The
Installed Packages section displays a list of Packages that are installed on the device.
Click on the number in the “# of Logs” column to display the Contents of the Staging Logs
captured during the Staging Process for a device. This enables the details of Staging
operations to be examined, to verify success or detect, diagnose, and correct problems
with the Staging of Mobile Devices.
Note that Staging Status is not available for devices that are staged using an MSP 2.xcompatible Rapid Deployment Client (Legacy Staging, see next section).
Legacy Staging
MSP 3 supports many different model, OSes, and revisions of Mobile Devices. Many of
these devices ship with the MSP 3 Staging Client pre-installed, but some, especially
older, devices ship with an older MSP 2.x-compatible Rapid Deployment Client. Devices
that ship with an older (earlier than version 3) Rapid Deployment Client are referred to as
Legacy Devices. Legacy Devices can be used with MSP 3 Stage and Provision Editions,
but the MSP 3 Client will need to be upgraded before full MSP 3 functionality will be
available.
Legacy Devices can be upgraded to a newer MSP 3 Client by using the Legacy Staging
Process whereby the old Rapid Deployment Client is used to Stage the new MSP 3
Client. The Legacy Staging Process on Legacy Devices can only support the forms of
Staging supported by the version of the Rapid Deployment Client they have. This will
definitely rule out On Demand (Electronic) Staging and SMS Staging and may limit the
features available in Barcode-Based Staging. Once a device has completed the Legacy
Staging Process, all features of MSP 3 will be available for use with that device.
Legacy Staging Prerequisites
Before performing the Legacy Staging Procedure, ensure that you have met all the
following pre-requisites.
Ensure that Legacy Devices are listed on the MSP 3 Supported Devices List. For
current reference information related to supported devices, please see
http://support.symbol.com/support/product/softwaredownloads.do.
•
Know the version(s) of Rapid Deployment Client that are on the Legacy Devices
Legacy Staging can generate barcodes that are compatible with various versions of
Rapid Deployment Clients from 1.1 onward. Selecting a newer Rapid Deployment
Client will enable newer features, especially smaller barcodes and/or more WLAN
security options. But you cannot use barcodes that target a newer version of Rapid
Deployment Client than the version present on a given device. If you have a mixture
of devices with different versions of Rapid Deployment Clients, then you may want to
consider the benefits of using a single “least common denominator” barcode sheet
vs. having several more precisely targeted barcode sheets.
Note: Legacy Staging is a one time operation that will need to be performed on EVERY
LEGACY DEVICE before full MSP 3 functionality will be available.
•
Have MSP 3 installed on a server and properly configured
Legacy Staging requires either MSP 3 Stage Edition or MSP 3 Provision Edition to be
installed, properly configured, and available for use.
•
Have the two Packages abup30.apf and enable30.apf available separately from MSP
3.
These Packages are required for performing the Legacy Staging Procedure and can
be installed as part of the workstation components via the MSP 3 Installer.
Note: Some Legacy Devices may require patches in order to work correctly with MSP 3. In
such cases, the required patches will be listed in the MSP 3 Device Compliance List.
Any required patches should be installed BEFORE the “abup30” Package is
installed. This would normally be done in the same Staging Profile as the “abup30”
Package, as part of Legacy Staging. If a required patch is not installed before Legacy
Staging Device is complete, then the device may not operate correctly with MSP 3. In
such a case, the device should be Staged again to add the missing patch.
Legacy Staging Process
To perform Legacy Staging, perform the following steps in order:
1. Verify that the Packages abup30.apf and enable30.apf are present in the MSP 3
Package library on the MSP 3 Server. These Packages should present automatically
as part of the MSP 3 Server installation.
2. Define one or more Relay Server(s) that represent the FTP Server(s) that will be
used to perform the Legacy Staging. Note that secure FTP (FTPS) cannot be used
during Legacy Staging.
3. Define one or more Network.WLAN Settings Objects that represent the WLANs over
which the Legacy Staging will be performed. This is done using the MSP 3 Server
console.
Legacy Staging can only be performed over WLAN and every unique set of WLAN
Settings over which Legacy Staging will be performed must be defined as part of a
Network.WLAN Settings Object. Note that a Network.WLAN Settings Object is not
required if the device is already configured for use on a WLAN over which the target
FTP Server can be reached.
4. Using the MSP 3 Server console, define a single Bundle containing the Package(s) to
be Staged. In MSP 3, Packages must be included in a Bundle to be Staged.
Note: To enable Provisioning after Staging, include both enable30.apf and abup30.apf. In
MSP 3.1, abup30.apf must be installed before enable30.apf.
5. Define one or more Staging Profile(s) on the MSP 3 Console UI to Stage the Bundle
to the device(s).
If multiple Relay Servers and/or WLAN Settings will be used for Legacy Staging, it
will either be necessary to create multiple Staging Profiles or to use late site binding.
6. Create sheet(s) of legacy barcodes for the Staging Profile(s) previously created. This
is done by clicking “Create” in the barcode column for each Staging Profile. Make
sure to check the 2.x checkbox for RD compatibility and select the RD version from
the drop down that is appropriate for your device(s). When in doubt, select the
lowest version of any devices you will be working with.
DO NOT SCAN THE BARCODES YET!
7. Using the AirBEAM Package Builder, which can be installed a PC using the MSP 3
installer, load the Packages abup30.apf and enable30.apf manually onto each FTP
Server that will be used for Legacy Staging, as follows:
Open each APF file in AirBEAM Package Builder and select FileÆInstall Package
(APD). Complete the information about the desired FTP Server and click OK. This
must be repeated for each Package to be Staged for each FTP Server.
Note: Although MSP 3 distributes Packages automatically to all Relay Servers, this feature
is NOT provided when using Legacy Staging. Because it leverages older versions of
Rapid Deployment Clients, Legacy Staging uses an older Package naming
convention than is used by MSP 3.
8. Using the Rapid Deployment Client on each Legacy Device, scan the barcode sheet
to perform Legacy Staging.
It is important to get the right barcode sheet for the right device if multiple Staging
Profiles are used.
Once Legacy Staging has been successfully completed for a device, that device will have
the MSP 3 Client loaded on it and will be ready to use with MSP 3.
Chapter 4 Performing Provisioning
Provisioning Operation
How Provisioning Works
The following figure illustrates how the Provisioning process works.
In accordance with the above figure, the Provisioning process is future detailed in the
following sections.
Policy Activation and Deactivation
Once a Provisioning Policy Object has been defined in MSP 3, it can be used to
Provision one or more Mobile Devices. Note, however, that a Policy must be activated
before it will cause any Provisioning to occur.
A Policy can be deactivated to prevent it from performing additional Provisioning. A
Policy must be deactivated before it can be edited or deleted. If a Policy fails for one or
more devices, deactivating and then activating the Policy will also force MSP 3 to retry
the Policy on all devices to which it is Applicable and which are not yet Compliant to the
Policy.
Policy Types
On-Going Policies
If an active Policy is of type On-Going, MSP 3 will evaluate the Policy periodically to
determine the devices to which it is Applicable and to determine the Compliance status
for each Applicable device. Based on this periodic evaluation, MSP 3 will detect new
devices and changes in existing devices and automatically create Jobs as needed to
deploy any software required to bring Applicable devices in Compliance with the Policy.
Manual Policies
If an active Policy is of type Manual, MSP 3 will also evaluate the Policy periodically, just
as described for an On-Going Policy, to determine the devices to which it is Applicable
and the Compliance status for each Applicable device. But unlike an On-Going Policy,
MSP 3 will NEVER automatically create Jobs to deploy software to achieve Compliance
to a Manual Policy. Jobs will only be created for a Manual Policy when the Policy is
manually pushed by clicking either the Push or Push All link for the Policy in the list of
devices shown on the Compliance Summary or Policy Management sub-tabs of the
Provisioning tab.
Policy Applicability
When a Policy is periodically evaluated, the Applicability Rules defined for the Policy are
checked to determine the set of devices to which the Policy is Applicable.
Policy Compliance
For each device to which a Policy is determined to be Applicable, the Bundle referenced
by the Policy is tested to determine if that device is Compliant or Not-Compliant to that
Policy, as follows:
•
If any Deployment Step within the Bundle would require action, based on the last
reported state of the device, then the device is considered Not-Compliant to that
Policy. In particular:
Performing Provisioning 41
•
•
• If a Bundle specifies that a specific version of a Package is to be installed and
the device does NOT have that specific version of that Package, then that device
is considered Non-compliant to that Policy.
• If a Bundle specifies that a Package is to be uninstalled and the device has ANY
version of that Package, then that device is considered Non-compliant to that
Policy.
If no Deployment Steps within the Bundle would require action for a device, then that
device is considered Compliant to that Policy.
Note that Reboot deployment steps in a Bundle are ignored when determining the
Compliance status of a device to a Policy that references that Bundle, but will be
executed if the decision is made to execute the Bundle on a device.
Job Initiation
When a Policy is Applicable to a device and that device is Not-compliant to that Policy,
then a Job (.delivered file) is queued up to go to the JOBS sub-folder of the Relay Server
associated with that device. The Job will tell the device to execute the Bundle referenced
by that Policy. Once a Job is sent to the Relay Server associated with a device, it will be
picked up by the device when the MSP Agent on the device later checks-in with the
Relay Server.
Readiness Conditions
When the MSP Agent on a device checks-in with a Relay Server, it locates Jobs
(.delivered files) in the JOBS sub-folder on the Relay Server that are specific to that
device. Jobs are processed in the order they were created. If a Policy references one or
more Condition Objects, then the MSP 3 Agent on the device evaluates these Readiness
Conditions to determine if it is appropriate to execute the Job on the device under the
present conditions.
If any Readiness Condition does not pass, then the Job is deferred (the Job file is
renamed on the Relay Server to .deferred) and will checked again later on a subsequent
check-in. Depending on the conditions specified, a Job could be deferred multiple times
and could continue to be deferred indefinitely, until all Readiness Conditions are met. Or,
depending on the Condition Objects(s) used, the Job could fail if a specific Readiness
Condition is not met within a specified number of tries or within a specified time period.
Job Execution and State
When all Readiness Conditions for a Job are met, the Job is executed by processing the
Bundle in a way nearly identical to that used for processing Bundles during Staging. The
only significant difference is if the Bundle references a Message Set Object, in which
case messages may be presented to the device User during the processing of the
Bundle.
A Job starts in the Queued state and remains in that state until it has been delivered to
the appropriate Relay Server, at which time it is changed to the Delivered state. A Job
changes from the Delivered state to the Deferred state if the MSP Agent decides to defer
the Job because one or more conditions are not met. A Job changes to the Started state
when the MSP Agent begins executing the Job. A Job changes to the Completed or
Failed state when the MSP Agent finishes executing the Job.
Note that a Job invokes the execution of the Bundle referenced by the Policy for which
the Job was created, even if only some of the steps in the Bundle are required. However,
the MSP 3 Agent on the device will optimize the execution of the Bundle as follows:
•
•
•
If a deployment step requests the installation of a specific version of a Package and
the device already has that exact version of that Package, then the Package will be
skipped unless the Bundle specifies the Force Install option for that Package.
If a deployment step requests the uninstallation of a Package and the device has no
version of that Package, then the step will be ignored.
Reboot deployment steps are always executed, in their specified sequence within the
Bundle, whenever a Bundle is executed.
Job Progress
When a Job is executing, the Job state is recorded in the extension of the Job file that
resides on the Relay Server. The MSP Agent renames the Job file to reflect the
changing status of the Job as processing proceeds. When the Job status is changed to
Completed or Failed, a Job log is also uploaded to the Relay Server, providing details of
the progress of the Job during processing.
MSP periodically retrieves Job status from the Relay Server and updates the Policy with
the progress of all extant Jobs. The Compliance status of all Policies can be monitored
from the Compliance Summary sub-tab of the Provisioning tab.
By definition, a Job will be created for a device only if that device is Non-compliant to the
Policy for which that Job was created. By examining devices that are Non-compliant to a
Policy, the Job status for a Job can be monitored to see how it is progressing. If a Job
fails, the Job log can also be viewed to see what went wrong and to determine what
corrective action should be taken.
How to use Provisioning
Policy Activation
When a Policy is first created or imported into MSP 3, it is inactive. A Policy can be
activated by using the Activate button on the Policy Detail page for the Policy or by using
“Activate” link in the list of Policies shown on the Policy Management sub-tab of the
Provisioning tab.
If a Policy is active, then it must be deactivated before it can be edited or deleted. A
Policy can be deactivated by using the Deactivate button on the Policy Detail page for the
Policy or by using the “Deactivate” link in the list of devices shown on the Policy
Management sub-tab of the Provisioning tab.
To edit or delete a Policy, navigate to the Policy Detail page for the Policy from either the
Compliance Summary or Policy Management sub-tabs of the Provisioning tab by clicking
the link for the Policy in the “Name” column. The Policy Detail page will show Edit and
Delete buttons only for deactivated Policies.
If a Bundle Object that is referenced by one or more active Policies is changed, the
Policies can be impacted, thus impacting in-progress Provisioning operations for many
devices. In such cases, a warning is displayed showing a list of Policies affected by the
changed Bundle. The default behavior is for all affected Policies to be automatically
deactivated. This can be overridden by selecting one or more Policies to be left active.
Performing Provisioning 43
Policy Types
On-Going Policies
An On-Going Policy is typically used when certain Packages should be on all devices that
meet certain criteria. Any time a new device is discovered that meets the specified
criteria, the Packages will be deployed automatically. Any time a device that meets the
specified criteria changes and no longer has the specified Packages, corrective action
will be taken to re-deploy the Packages automatically.
Manual Policies
A Manual Policy is typically used when a “Control Action” needs to be performed on one
or more devices. This would be accomplished by delivering a “Control Package” via a
Bundle referenced by a Manual Policy. One example of a “Control Action” would be
locking or unlocking a Mobile Device. Another example might be presenting information
to a device User, such as via a text message, or by playing an audio or video file. It
would generally not make sense to have such a “Control Action” be repeated
automatically as would happen if an On-Going Policy were used. Additionally, Manual
Policies are often combined with the “Force Install” Bundle option to cause a “Control
Package” to be installed even if it the same version of the Package is already on the
device.
A Manual Policy might also be used during troubleshooting to test out the deployment of
patches or workarounds to selected devices to see if they correct a specific problem. A
Manual Policy might also be used to deliver targeted software components, such as
RemoteControl, to a device on an as-needed basis.
Policy Applicability
The devices for which a Policy is Applicable and Not-Applicable can be accessed from
the Policy Detail page for the Policy.
Viewing and Reporting on Provisioning Status
Compliant Status
A summary of the Compliance Status of all active Policies can be viewed from the
Compliance Summary sub-tab of the Provisioning tab. The Compliance Summary page
displays a list of Policy Names and a summary showing the number of device that are
and are not Compliant to each Policy.
Not-Compliant Status
Beginning with MSP 3.1, the Compliance Summary sub-tab of the Provisioning tab has
been enhanced to further break down the reasons for a Policy being Not-Compliant. A
Policy could be Not-Compliant for any for any of the following reason, which are
summarized separately.
•
In-Progress
This status indicates that a Job has been sent to a device to enforce Compliance and
that the results of that Job are still pending.
•
Failed
This status indicates that a Job was sent to a device to enforce Compliance but that
the Job failed and that it will NOT be retried until the Policy is disabled and reenabled.
•
Timed-out
This status indicates that a Job was sent to a device to enforce Compliance but that
the Job did not complete before it expired and that it will NOT be retried until the
Policy is disabled and re-enabled.
•
Must Push
This status indicates that the Policy needs to be manually pushed to the device to
achieve Compliance.
Policy Details
Clicking on a the link in the “Name” column in the Compliance Summary or Policy
Management sub-tabs of the Provisioning tab will bring up the Policy Detail page. The
“Device Information” section of the table displays the number of devices for which the
Policy is Applicable and Not-Applicable. Clicking on the link for “Applicable” devices will
navigate to Compliance Summary->Policy Detail->Compliance Overview page. This
page displays Policy details as well as Bundle Steps and Device IDs. The “Last Job”
column will navigate to the Compliance Summary->Policy Detail->Compliance Overview>Jobs for Device page which displays a list of Jobs by ID number along with the Action,
Status, Results and Date of each Job for the specific device.
Chapter 5 Using MSP Control Modules
Purpose
Although MSP 3.1 is primarily for Staging and Provisioning, it nonetheless provides a
means for implementing some Control functionality. This is accomplished through the
development, deployment, and use of Control Modules. The purpose of this document is
to introduce the various types of Control Modules, describe specific Control Modules
shipped with MSP 3.1, and explain how to use them.
Control Module Types
In MSP 3.1, a Control Module is any Package that performs any sort of Action on a
device and can be deployed to one or more devices using MSP 3 Provision Edition.
Control Modules are generally designed to leverage the capabilities of Provisioning may
provide less functionality or no functionality when used with MSP Stage Edition. The
basic types of Control Modules are described below.
One-Time Action Control Modules
A One-Time Action Control Module is one designed to perform some desired Action once
each time it is deployed. This is typically done by including a utility program into a
Package and invoking that utility program as part of the Install Command of that
Package.
Since a One-Time Action Control Module likely does not need to keep the utility in the
device after it has been executed, the “Delete After Install” option can be used within the
Package for various files to clean up and save storage space on the device. Since such
a Package may leave little or no “residue” on the device, the uninstall command of the
Package often has little or nothing to do.
In most cases, a One-Time Action Control Module is deployed using a Manual Policy via
MSP 3 Provision Edition. The Bundle deployed by the Manual Policy indicates that the
Package that implements the Action Control Module is to be Installed with the Force
Install option. This ensures that the same Action Control Module can be pushed to the
same device any number of times and the Package won’t be “skipped” because the same
version of the Package is already in the device.
When the Manual Policy is pushed to a given device, the Policy is marked as In Progress
for that device and then a Job is queued to be sent to the device. When the device
checks in and pulls and executes the job, the Bundle referenced by that Policy is
executed. The Bundle causes the Package that implements the One-Time Action Control
Module to be installed on the device.
If the Install Command of the Package is successful (as a result of a ZERO return value
from the called utility program), the Package install succeeds. If all the Packages in the
Bundle succeed, then the Job issued by the Policy succeeds and that Policy is marked as
Compliant for that device. So, for a One-Time Action Control Module, the Policy status,
Compliant or Non-Compliant, is an indication of whether the action was successfully
executed on one or more devices.
MSP 3.1 currently DOES NOT include any One-Time Action Control Modules. MSP 3.0
did have some, including FetchDevInfo, which has been obsoleted and replaced by
GetAdapters, which is a Repetitive Action Control Module. Nonetheless, One-Time
Action Control Modules can easily be developed and used with MSP 3.1 and can provide
a powerful method of executing custom actions.
Repetitive Action Control Modules
A Repetitive Action Control Module is very similar to a One-Time Action Control Module
except the utility included in the Package is designed to be kept around and run
repeatedly. This is accomplished using the new Check-In Command feature of Packages
in MSP 3.1.
Each time the MSP 3.1 Agent checks in with its Relay Server, it executes the Check-In
command associated with any Packages that have one. This provides the ability for a
Repetitive Action Control Module to execute periodically.
Since such a Control Module must execute repetitively, it cannot remove all of its Content
at the end of installation and hence generally should NOT use the “Delete After Install”
option, like a One-Time Action Control Module might. Also, since a Repetitive Action
Control Module may keep information around (in the device Registry or File System) to
communicate information to itself between executions, it may require an uninstall
command to clean up if/when the Package is uninstalled.
In MSP 3.1, two Repetitive Action Control Modules are provided: GetAdapters and
GetCabInventory. Each of these Control Modules executes periodically and captures
information from the device and places it into the device registry where it will be reported
to MSP 3 as Device Attributes via the discovery document sent via the Relay Server at
the end of the check-in.
Readiness Control Module
A Readiness Control Module is one designed to install Content on one or more devices,
which then makes the Content ready to be used by one or more subsequent Packages.
Depending on the nature of the service, a Readiness Control Module might consist of an
executable program, DLL, or any other Content that might be needed to perform a
function needed by a Package deployed later.
Using MSP Control Modules 47
Since the primary purpose of a Readiness Control Module is to place Content onto a
device, it generally does NOT use the “Delete After Install” option, at least not on the
primary Content files. Unless some special action (e.g. decoding, unpacking, registering,
etc.) was required when installing a Package that implements a Readiness Control
Module, its uninstall function likely has little to do.
The main reason for having a Readiness Control Module is to separate a Package
containing potentially large Content from a likely smaller Package that uses that Content.
If the large Content were included in the Package that uses it, it would need to be
transferred to each device each time it is needed. By separating the Content into a
Package that is sent in advance, the Action can be performed with less impact on the
device, network, etc. and with less total time lag when it is used.
Some examples may help to illustrate this concept:
•
A large utility application or DLL is deployed in advance to make a device ready to
perform a complex Action.
• A large media file, such as a video, is deployed in advance to make a device ready to
play that media file at need.
A Readiness Control Module could be deployed to devices via Staging or via
Provisioning, using either a Manual or On-Going Policy. The decision of the method
used to deploy a Readiness Control Module would likely depend on which devices will
likely use the Content.
•
If the Content changes seldom and many devices are likely to use it, then the
Content might be Staged onto every device as a matter of course.
• If the Content changes periodically and many devices are likely to use it, then the
Content might be Provisioned via a On-Going Policy that can ensure that all devices
have the proper version at all times.
• If the Content is only occasionally needed on some devices, then it might be
Provisioned via a Manual Policy, on an as-needed basis.
Placing the Content into a separate Package allows it to be deployed at a more
convenient time and/or to be skipped if it is already present on a given device. If a Policy
is being used, the Package containing the Content could be included in the same Bundle
as the Package that uses it. If the device already has the proper version of the Content,
then the Package to deploy that Content would be skipped, otherwise it would be
deployed.
In MSP 3.1, no simple examples of Readiness Control Modules are provided.
Nonetheless, Readiness Control Modules can easily be developed and used with MSP
3.1 and can provide a powerful method of executing custom actions. In addition, MSP
3.1 does provide some sophisticated Configurable Action Control Modules, which have
all the characteristics of Readiness Control Modules as well as additional capabilities.
Configurable Action Control Modules
A Configurable Action Control Module is a sophisticated Control Module that combines
aspects of a Readiness Control Module with those of a Repetitive Action Control Module.
Such a Control Module typically also includes a Settings Plug-In that can be used to
configure the ongoing repetitive action of the Control Module.
Once a Configurable Action Control Module is installed on the device, a Settings Object
can be created and pushed to the device via a Bundle referenced by a Manual or OnGoing Policy. When the Setting Object is applied on the device, the Plug-In part of the
Control Module communicates the information contained in the Settings Object to the
Repetitive Action part and the ongoing repetitive action (during Check-In commands) is
altered accordingly.
In MSP 3.1, two Configurable Action Control Modules are provided: LockAndWipe and
AutoSiteAssign. Each of these Control Modules are installed to prepare the device for
later support of the repetitive action implemented by that Control Module, whose ongoing
operation can be enabled, disabled, or altered by pushing a Settings Object.
Server Control Modules
A Server Control Module is one designed to deploy a Server onto one or more devices.
This Server would typically auto-launch and either run continuously or periodically in
order to provide some service. Some examples might include:
•
A Web Server, FTP Server, SOAP Server, or other similar Server application that
listens for incoming network connections and provides well-defined services to
applications on or off the device.
• A RemoteControl Server that allows connections from PCs that will remotely control
the operation of the device.
• An data collection Server application that runs on the device and periodically collects
data and delivers it to a remote location.
• A local Policy evaluation Server that runs on the device and periodically checks the
status of and enforces local Policies deployed to the device.
Since the primary purpose of a Server Control Module is to start a Server running on a
device, it generally does NOT use the “Delete After Install” option, at least not on the
primary Server files. The install command of a Package that implements a Readiness
Control Module generally should start the Server running and the uninstall command
generally needs to shut down the Server so it can be cleanly uninstalled.
Note that a Server Control Module may need to ensure that the Server is automatically
restarted in the event the device is rebooted. This can be done via various device and
OS-specific methods (such as shortcuts placed in specific folders). Such methods MAY
be required if is important that the server start up very early following a reboot. But if the
need to start the server early is not critical, then the server can be restarted by using the
new Check-In Command feature of Packages in MSP 3.1. When the MSP Agent first
checks-in, the server can use the call to the check-in command to start up.
If a Server Control Module implements an HTTP server, then the Package can be
augmented with a URL field that causes a button to be added to the Device Detail page
of the MSP 3 Console UI for each device that has that Package in its Package Inventory.
When the button is clicked, it launches the URL specified in the Package, which can
connect to the HTTP server in the device.
In MSP 3.1, two Server Control Modules are provided: RemoteControl and RemoteUI.
Each of these Control Modules listens for incoming connections to provide the ability to
control and troubleshoot a device remotely.
MSP 3.1 Control Modules
This section will describe the Control Modules provided in MSP 3.1 and how to use them.
GetAdapters
The GetAdapters Repetitive Action Control Module is most commonly used as an enabler
for the RemoteControl and RemoteUI Server Control Modules. In order to connect to a
device for RemoteControl or RemoteUI purposes, it is important to know the IP address
of the device to connect to. The GetAdapters Control Module sends up information about
all networks adapters present in a device and also determines and sends up information
on what it considers to be the “best” adapter for purposes of connecting to the device.
Unlike the MSP 3.0 One-Time Action Control Module, FetchDevInfo, which it replaces,
GetAdapters is a Repetitive Action Control Module and hence sends updated information,
if it exists, each time the device checks in. This significantly increases the chances that
the IP address information will be correct. This is especially true if the device is roaming
between networks or if dynamic addressing is used.
In addition to adapter information, this Control Module also sends some Device Attributes
containing Phone information on WWAN-enabled devices. Further, some additional
Device Attributes containing auxiliary information needed by the RemoteControl and
RemoteUI Server Control Modules are sent, including keyboard type, screen size, default
color depth, etc.
GetAdapters Device Attributes
The following is an example of the Device Attributes produced by this Control Module:
UserAttribute.adapter.lannds1.class Cradle
UserAttribute.adapter.lannds1.gatewayip 192.168.1.1
UserAttribute.adapter.lannds1.ipaddr 192.168.1.103
UserAttribute.adapter.lannds1.macaddr 00:A0:F8:E4:2F:FC
UserAttribute.adapter.lannds1.name LANNDS1
UserAttribute.adapter.lannds1.subnetmask 255.255.255.0
UserAttribute.adapter.pccardx5cphoton1.class WLAN
UserAttribute.adapter.pccardx5cphoton1.gatewayip 192.168.0.1
UserAttribute.adapter.pccardx5cphoton1.ipaddr 192.168.0.108
UserAttribute.adapter.pccardx5cphoton1.macaddr 00:15:70:6A:F9:C8
UserAttribute.adapter.pccardx5cphoton1.name PCCARDx5CPHOTON1
UserAttribute.adapter.pccardx5cphoton1.subnetmask 255.255.255.0
UserAttribute.adapterbest.adapter LANNDS1
UserAttribute.adapterbest.ipaddr 192.168.1.103
UserAttribute.adapterbest.macaddr 00:A0:F8:E4:2F:FC
UserAttribute.adapterbest.name LANNDS1
UserAttribute.phone.manufacturer Sierra Wireless
UserAttribute.phone.model EM5625D Rev 3
UserAttribute.phone.number 4807731375
UserAttribute.phone.revision 3.03.00:50800
UserAttribute.phone.serialnumber 602a5ca0
UserAttribute.phone.subscriber 6
UserAttribute.remotecontrol.bitdepth 16
UserAttribute.remotecontrol.keyboard MC70XX_NUMERIC
UserAttribute.remotecontrol.screenheight 320
UserAttribute.remotecontrol.screenwidth 240
Note that although the GetAdapters Repetitive Action Control Module is primarily
provided to support the RemoteControl and RemoteUI Server Control Modules, the
Device Attributes delivered to the MSP Server could be useful for other purposes as well.
The adapter information could be used in Policy Applicability Rules to limit sending
certain types of Content to devices with certain types of connectivity. In addition, this
information might come in handy as a reference during device troubleshooting.
GetCabInventory
The GetCabInventory Repetitive Action Control Module sends up information about all
the CAB files installed on a device each time the device checks in. While MSP 3.1
automatically tracks the Packages installed on a device, some devices may have
applications installed through CAB files instead. By using the GetCabInventory
Repetitive Action Control Module, the list of installed CAB files can be tracked.
If a CAB file is deployed using an Package, then the same “application” could be reported
in two different ways, as an installed CAB (via GetCabInventory Repetitive Action Control
Module) and as an installed Package (via the built-in MSP Package inventory tracking).
Note however that if the CAB file were manually removed without uninstalling the
Package that installed it, a discrepancy would occur which might be of interest when
troubleshooting device operation.
If a CAB file was NOT deployed using a Package, then it would ONLY be reported as an
installed CAB (via GetCabInventory Repetitive Action Control Module). This could allow
the detection of undesirable or “rogue” applications installed on devices using “out of
band” methods.
GetCabInventory Device Attributes
The following is an example of the Device Attributes produced by this Control Module:
UserAttribute.getcabinventory.myx20app1 My App1
UserAttribute.getcabinventory.thirdx20partyx20tool Third Party Tool
AutoSiteAssign
The AutoSiteAssign Configurable Action Control Module enables the automatic
assignment and/or reassignment of devices to Sites dynamically, while they are being
managed. Like all Configurable Action Control Modules, AutoSiteAssign must be Staged
or Provisioned to a device before it can be activated. AutoSiteAssign is then configured
and activated by applying a Settings Object of Class Control.AutoSiteAssign.
The basic operation of AutoSiteAssign is to test to see if the device has “moved” to a new
Site each time the device checks in. The device pulls a Relay Server Information File
from the Relay Server when it checks in and uses the information contained therein to
determine when/if the device should automatically be assigned to a new Site.
There are two modes supported by AutoSiteAssign:
•
Assign Site Based On: The Relay Server accessed by the device
In this mode, the ONLY information from the Relay Server Information File used to
determine the eligible Sites for automatic assignment is the list of Site names that
reference that Relay Server. All Sites that reference the Relay Server will be
considered potential candidate Sites.
•
Assign Site Based On: The Relay Server accessed by the device AND the WLAN
Profile in use on the device
In this mode, the WLAN Profile name (if any) of the Network Settings (if any) of each
Site is used in addition to the list of Site names that reference that Relay Server.
Only those Sites whose WLAN Profiles name match the WLAN Profile name
currently in use on the device AND that also reference the Relay Server will be
considered potential candidate Sites.
Once the list of potential candidate Sites is determined based on the selected mode, if
there is only ONE candidate, then that candidate is selected. If more than one candidate
exists, then the Site is considered “Ambiguous” and the selection made for “Handle Site
Ambiguity By” is used to determine what to do. There are two choices:
•
Handle Site Ambiguity By: Not automatically assigning a Site
If this choice is made, no automatic assignment of the device to a Site will be made
when the Site is ambiguous. In this case, the device is known to be at one of several
Sites, but since the proper Site cannot be determined, no change is made.
•
Handle Site Ambiguity By: Asking the device User which Site to assign
If this choice is made, the device User is prompted to select the Site from the
candidate list when the Site is ambiguous.
If the selected Site matches the Site to which the device was already assigned, then no
action is required to assign the device to that Site. If the selected Site does not match
the Site to which the device is currently assigned, then the Production Site Bundle for the
new Site is automatically pulled from the Relay Server the next time the device checks in.
Pulling the Production Site Bundle for the Site will apply the Settings defined for that Site
AND will assign the device to that Site.
AutoSiteAssign Device Attributes
AutoSiteAssign sends up some information about what it does to help understand what
automatic Site assignment activities have taken place on the device. The following is an
example of the Device Attributes produced by this Control Module:
UserAttribute.autositeassign.relayserver MyRelayServer
UserAttribute.autositeassign.relayservercrc C970
UserAttribute.autositeassign.Profile MyWlan
In the above example, the device is currently checking in via the Relay Server named
“MyRelayServer” and is currently using the WLAN Profile named “MyWlan”. This
information can be useful in determining how/why a device was assigned to a particular
Site. While not sent by this Control Module, the following Device Attribute holds the Site
to which the device is assigned and hence may be affected by the operation of this
Control Module.
UserAttribute.autositeassign.siteID MySite
LockAndWipe
The LockAndWipe Configurable Action Control Module enables a device to be locked or
unlocked or wiped either unconditionally (when initiated by Server Policy) or conditionally
(when determined by device conditions defined by Server Policy). Like all Configurable
Action Control Modules, LockAndWipe must be Staged or Provisioned to a device before
it can be activated. LockAndWipe is then configured and activated by applying a Settings
Object of Class Control.LockAndWipe.
The basic operation of LockAndWipe is to check periodically to see if any Scenario
defined by a pushed Settings Object is met and, if so, to take the Action defined for that
Scenario. There may be multiple Scenarios specified, numbered starting from one (1).
The Scenarios are checked in order. If a Scenario is met, then the Action is taken for that
Scenario and then no further Scenarios are checked. If no Scenarios are met, then no
Action is taken.
Each Scenario must specify one of two possible modes:
•
Unconditional
This mode causes the Scenario to ALWAYS be met. This is most commonly used
when only a single Scenario is used, although it COULD also be used as the LAST
Scenario in a list of Scenarios. But note that when an Unconditional Scenario is
reached, the Action for the Scenario will be taken ONE time and then no further
checking of ANY Scenarios will be done until the same or a different Settings Object
is applied.
•
Conditional
This mode causes the Scenario to test one or more Conditions, as specified by one
or more Condition Objects. All Conditions specified for a Scenario must be met for
the Action to that Scenario to be taken. In other words, there is an implicit AND
between all specified Condition Objects for a given Scenario. There is no way to
implement an OR between Condition Objects, but a similar result can be achieved by
using multiple Scenarios that all specify the same action.
Each Scenario must specify one of three possible types of Action:
LockAndWipe Scenario Actions
Lock
The Lock Action causes the device lockdown UI to be invoked, thus preventing the
device User from interacting with the UI of the device. If the device lockdown UI was
already running, then this Action will cause it to be stopped and restarted to allow new
configuration (if any) to be applied.
When this action is selected, the text strings for all messages and buttons to be displayed
by the lockdown UI can be specified. Default values are provided, but can be overridden
by editing the default strings in the Settings Object. The following strings can be
controlled:
•
Lockdown UI Title
This is the text string to be displayed in the title of the lockdown UI (between the two
icons).
•
Lockdown UI Message Prefix
This is the text string to be displayed on the first message line of the lockdown UI
•
Lockdown UI Message
This is the text string to be displayed on the second message line of the lockdown UI.
•
Lockdown UI Message Suffix
This is the text string to be displayed on the third message line of the lockdown UI
(just above the password entry field, if present).
•
Unlock Button Text
This is the text string to be displayed on the Unlock Button (if one is presented).
•
Unlock Password
This is the text string to be used as the Unlock Password. If this text string is
anything EXCEPT a single asterisk character (“*”), then the device operator will be
allowed to enter a password on the device to unlock it. If the text string is a single
asterisk character (“*”), then no password entry will be permitted and hence the
Unlock Button Text (above) will be ignored.
It is important to note that when a Lock Action is applied, the device will remain locked
until one of the following:
•
•
•
The device is unlocked by an Action applied by another Scenario.
A new Settings Object of Class Control.LockAndWipe is pushed to the device.
The Package that delivered the Settings Object of Class Control.LockAndWipe is
uninstalled from the device.
• The Package that delivered the LockAndWipe Control Module is uninstalled from the
device.
• The Lock Action included an Unlock Password and the Mobile Device User
successfully entered the password to unlock the device.
It is also important to note that rebooting the device will NOT unlock it. The lock will be
re-established after the device reboots. The time it takes a device to lock following a
reboot may vary depending on the device model and OS. But the lock should be reestablished in a relatively short time, providing little opportunity for mischief if the device
is in unfriendly hands.
Note, however, that on some Mobile Devices, that cannot properly support cold/clean
boot persistence, the lock may not be possible to persist across a cold or clean boot. But
in such cases, data and network connectivity will also be lost, hence reducing the risk of
compromise. Nonetheless, if the lock was intended to protect the device hardware from
being useful to a potential thief, it may not serve that purpose since the device may be
usable, even though it does not compromise Enterprise data.
Unlock
The Unlock Action causes the device lockdown UI to be terminated, thus allowing the
device User to again interact with the UI of the device. If the device lockdown UI was not
running, then this Action does nothing.
Wipe
The Wipe Action causes one or more Device Wipe Operations to be performed on the
device. Depending on the operations selected, this could result in a large or small
amount of actual wiping of device data. In fact, some operations may not result in any
wiping of device data at all. The following types of Device Wipe Operations are available:
•
Wipe Silently / Wipe Message
This allows a message to be displayed to the device User when a Wipe Action is
being taken. Selecting Wipe Silently means that NO message will be displayed to
the device User.
Depending on the reason for the Wipe Action being taken, it may be preferable to
have no message to prevent any interference with the Wipe (such as when an
unauthorized person is in possession of the device). If the device were rebooted in
the middle of a Wipe Action, then all intended data would not be wiped.
Consequently, it might be better not to warn a potential thief that data is in the
process of being wiped.
•
Wipe AirBEAM Packages
This Device Wipe Operation allows up to five (5) AirBEAM Packages to be
uninstalled, thus removing key applications from the device.
•
Execute a BATCH File
This Device Wipe Operation allows an AirBEAM-style text BATCH file (like those
supported in Package install and uninstall commands) to be executed. The BATCH
file must already be resident on the device and the full path to where the BATCH file
resides on the device must be provided. The BATCH file could be delivered to the
device via a Package included in the same Bundle that delivers the
Control.LockAndWipe Settings Object.
The use of a BATCH file opens up unlimited possibilities for implementing custom
Device Wipe Operations since it permits custom executables to be run. Such custom
executables must be resident on the device and the full path to each executable must
be specified in the BATCH file that invokes it. Such custom executables can be
delivered to the device via Packages included in the same Bundle that delivers the
Control.LockAndWipe Settings Object.
•
Wipe Specific Files or Folders
This Device Wipe Operation allows one or more files, folders, or complete folder
trees to be wiped. Files are specified by a full path to the file and may include
wildcard characters. Folders are specified by a path ending in a backslash character
(“\”) and MUST NOT contain any wildcard characters. If a folder is wiped, all files and
subfolders under that folder are also wiped.
This Device Wipe Operation should be used with caution since by definition it can
cause DATA LOSS (in fact that is its primary intent). Configuring a Conditional
Scenario to automatically wipe entire folder trees could be catastrophic if the
Conditions are incorrectly specified and/or the wrong path is provided.
It is important to note that it may not always be possible to Wipe Files or Folders. If a
file is in use, such as by a running application, then the Operating System will not
allow it to be deleted. If a folder contains any file that was not deleted then that folder
will also not be deleted.
To ensure that critical files and folders are deleted, it is necessary to stop any
applications that may be using them. For applications that were installed via a
Package, this can often by done by uninstalling the Package before attempting to
Wipe the files or folders used by the application. For other applications, it may be
necessary to include a command to stop the application in a BATCH file before
attempting to Wipe the files or folders used by the application.
•
Wipe Built-In File Systems
This Device Wipe Operation allows complete built-in File Systems to be wiped. This
operation is often device and/or OS specific, since not all devices and OSes have the
same sorts of built-in File Systems.
Note that wiping of built-in File Systems happens LAST, since it often results in a
reboot of greater or lesser severity. So, any other Device Wipe Operations that were
specified will have happened BEFORE this one.
Note also that removable media is NOT considered to be a built-in File System. But
files on removable media CAN be wiped using Wipe Specific Files or Folders as long
as the full path of the folder for the removable media is known (e.g. “\Storage Card”).
The following forms of wiping built-in File Systems are provided:
• Don’t wipe any built-in file systems
This indicates that no wiping of built-in file systems should occur.
• Wipe transient file system and registry (cold boot)
This indicates that a cold boot should be done to wipe the transient file system
and registry.
Note that on devices with a version of Windows Mobile BEFORE Windows
Mobile 5.0 or most devices with Windows CE, the root file system and Device
Registry are in RAM. On such devices, a cold boot completely erases the
(transient) root file system and Device Registry.
Note that on devices with a version of Windows Mobile 5.0 or higher, the root file
system and Device Registry are in Flash and hence are persistent. On such
devices, a cold boot does NOT wipe them.
• Wipe persistent file system and registry (clean boot)
This indicates that a clean boot should be done to wipe the persistent file system
and registry.
Note that a clean boot is only available on devices with Windows Mobile 5.0 or
higher. On devices that cannot support a clean boot, a cold boot is performed
instead.
Note that on devices that CAN support a clean boot, a clean boot can ONLY be
performed when the device is on AC power. It may therefore be desirable to
defer the execution of a clean boot until a device is on AC power in one of the
following two ways:
If the wipe is being initiated via an Unconditional Scenario pushed as part of a
Settings Object in a Bundle referenced by a Policy, then use a Power Condition
Object to defer the execution of the Job until AC power is available. This will
cause the Job to be rechecked each time the device checks in until AC power is
available and then executed.
If the wipe is being initiated via a Condition Scenario, then add a Power
Condition Object so the Scenario is not met until the other Conditions AND the
device is on AC power.
•
Wipe all built-in file systems (includes application)
This indicates that the “super persistent” built-in file system (called the
\Application partition on legacy Symbol Motorola devices) should be wiped in
addition to everything in the other built-in File System wiping options. This is as
close to returning a device to “factory Settings” as it is practical without doing an
OS update.
Note that on legacy Symbol Motorola devices which have a “\Platform” partition,
there may be no reliable way to completely return the device to “factory Settings.”
This is because there may be information stored in the \Platform partition. Since
deleting things indiscriminately from the \Platform partition could prevent the
device from booting, there is no built-in code to automatically wipe anything from
the \Platform partition even though it is a built-in File System. Nonetheless, if
there are specific files in the \Platform partition that need to be deleted for
security reasons, the Wipe Specific Files or Folders option can be used to
explicitly delete them.
It is important to note that the \Application partition is Wiped using the same
method used by the Wipe Specific Files or Folders Action. As such, it is subject
to the same limitations about Wiping files that are in use.
LockAndWipe Device Attributes
LockAndWipe sends up some information about what it does to help understand what
Scenario of what Setting Object has caused the device to be placed in what state. The
following is an example of the Device Attributes produced by this Control Module:
UserAttribute.lockandwipe.Object MyLockSettings
UserAttribute.lockandwipe.scenario 1
UserAttribute.lockandwipe.state Locked
In the above example, the device is currently Locked due to the application of Scenario 1
(first scenario) in the Control.LockAndWipe Settings Object Named “MyLockSettings”.
The possible states are:
• Locked
The device lockdown UI was invoked by a Scenario Action.
• Unlocked
The device lockdown UI was terminated by a Scenario Action.
• Password
The device lockdown UI was terminated by entry of a password by the device User.
• Wiped
One or more Device Wipe Operations were invoked by a Scenario Action.
RemoteUI and RemoteControl
MSP 3 comes with Control Modules that offer RemoteUI and RemoteControl
functionality. The purpose of this section is to explain these features and describe how to
deploy, configure and use these capabilities when managing devices with the MSP 3
Stage and/or MSP 3 Provision products.
Overview
In MSP 3, RemoteUI and RemoteControl are implemented as Server Control Modules.
For more information on Control Modules, consult the document titled “MSP 3 Control
Modules”.
RemoteUI vs. RemoteControl
In MSP 3, there are two different Control Modules provided: RemoteUI and
RemoteControl. The RemoteUI Module provides the ability to view and control ONLY the
User Interface (UI) of the device. The RemoteControl Module provides all the features of
the RemoteUI Module plus features related to the maintenance and troubleshooting of a
device, including Registry Management, File Management, Application and Process
Management, DLL Management, and Rebooting.
MSP 3 Stage Edition offers only the RemoteUI Module and requires that the RemoteUI
functionality be launched manually, since the MSP 3 Stage Edition provides no Asset
Management and hence provides no means to track devices and launch RemoteUI for
them. In addition, the GetAdapters Control Module cannot be used in MSP Stage Edition
and hence the User must manually enter the IP address needed to launch RemoteUI.
The MSP 3 Provision product offers BOTH the RemoteUI and RemoteControl Modules.
Even though RemoteControl is a superset of Remote UI, BOTH are provided for the
following reasons:
•
Device Storage and Memory Footprint
The RemoteUI Module is significantly smaller than the RemoteControl Module and
hence is lighter on device resources.
•
Less Opportunity to Damage Device Configuration
Since the RemoteUI Module only permits the UI of the device to be controlled, an
untrained help desk operator could not inadvertently use the other tools to damage
the device configuration.
The MSP 3 Provision product provides a certain amount of Asset Management and
hence can also provide a means to track devices and launch RemoteUI or
RemoteControl for them. In addition, the GetAdapters Control Module can be used in
MSP Provision Edition and hence the User need not manually supply the IP address
needed to launch RemoteUI.
RemoteUI and RemoteControl Changes from MSP 3.0 to MSP 3.1
The following improvements in RemoteUI and RemoteControl have been made between
MSP 3.0 and MSP 3.1:
•
Primary Package Naming Changes
A Package naming change has been made from MSP 3.0 to MSP 3.1. In MSP 3.0,
the RemoteUI Package name was rui.apf and the RemoteControl Package name
was rc.apf.
Since these Packages have been significantly improved and overhauled for MSP 3.1
the names have been changed to keep them separate from the earlier Packages. In
MSP 3.1, the RemoteUI Package name is RemoteUI.apf and the RemoteControl
Package name is RemoteControl.apf.
These new Package are also more intuitive and self-documenting.
•
Auxiliary Package Changes
In MSP 3.0, a Package named FetchDevInfo.apf was provided to collect Device IP
address information for use with RemoteUI and RemoteControl. In MSP 3.1, this
Package is replaced by a Package named GetAdapters. In addition, GetAdapters
now periodically updates the adapter information to help keep MSP up to date if
device conditions change.
•
Improved Licensing
In MSP 3.0, some Motorola Devices shipped with pre-installed License Keys to
enable the use of RemoteUI and RemoteControl. All other Motorola Devices
required the installation of License Key Packages before RemoteUI or
RemoteControl could be installed and used. Since these License Key Packages
were device-specific, and no device could have more than one License Key at a time,
the task of deploying RemoteUI or RemoteControl to mixed populations of Devices
could become quite complex.
In MSP 3.1, the RemoteUI and RemoteControl Packages now ship with a built-in
“Symbol” Vendor Key that enables use on all supported “Symbol” Motorola Devices.
This change significantly simplifies deployment of the RemoteUI and RemoteControl
Packages to all supported “Symbol Legacy” Motorola Devices, since only the
RemoteUI.apf Package or the RemoteControl.apf Package must be deployed – no
additional License Key Package is required.
As additional “Symbol” Motorola Devices are added, most should be supported by
the same “Symbol” Vendor Key. If additional Motorola Devices are later added, an
additional “Motorola” Vendor Key will be added. A single Device can have any
number of Vendor Keys deployed to it, so it is safe to deploy the same Packages to
every Device.
Mutual Exclusivity of Packages
Only one of the two RemoteUI and RemoteControl Packages should never be loaded on
the same device at the same time or on a device that has the earlier rui.apf or rc.apf
Packages from MSP 3.0. When creating a Bundle to install these Packages, it is a good
idea to explicitly uninstall any of the other Packages. Such uninstall commands placed in
the Bundle will be benign if the specified Packages are not present yet can help prevent
inadvertently loading more than one Package.
In the advent that more than one RemoteUI or RemoteControl Package (of any version)
is loaded onto a device at the same time, the proper corrective action is to uninstall ALL
versions of all such Packages and then install the single one desired. Any other recovery
action could result in improper operation either immediately or following a subsequent
reboot.
Using RemoteUI with MSP Stage
Before the RemoteUI feature can be used for a given device from the MSP Stage
Product, the following prerequisites must be met:
•
The Device must be Contactable from the computer that will be used to control it
In order for a device to be controllable, it must be contactable via an IP address or
name (e.g. DNS, etc.).
See the section “Device Contactability,” later in this document, for information on how
to deal with device contactability.
•
The Device must have a Vendor Key suitable for the vendor of the Device model
See the Improved Licensing bullet in the section “RemoteUI and RemoteControl
Changes from MSP 3.0 to MSP 3.1,” earlier in this document, for more information on
Vendor Keys.
•
The Device must have the RemoteUI Package Installed
The MSP Stage product ships with the RemoteUI Package built-in. As part of the
Staging of the device, this Package should be installed.
Once this Package is successfully installed, the RemoteUI Server will automatically
launch on the device, but only if the requisite License Key (see previous bullet) is
present.
•
The User Must Know the IP Address of the Device
In order to launch RemoteUI for a device that has the RemoteUI Server running on it,
the User must know the IP address at which the device can be contacted.
See the section “Dealing with Device IP Addresses,” later in this document, for
information on how to deal with device IP addresses.
Using RemoteUI with MSP Provision
Before the RemoteUI feature can be used for a given device from the MSP Provision
Product, the following prerequisites must be met:
•
•
Vendor Keys.
•
The Device must have the RemoteUI Package Installed
The MSP Provision product ships with the RemoteUI Package built-in. As part of the
Staging or Provisioning of the device, this Package must be installed. If the
RemoteUI Package was NOT installed as part of Staging, then it can be deployed via
a Provisioning Policy, either Manual or On-Going.
Once this Package is successfully installed, the RemoteUI Server will automatically
launch on the device if the requisite Vendor Key is present.
•
MSP (or the User) Must Know the IP Address of the Device
In order to launch RemoteUI for a device that has the RemoteUI Server running on it,
MSP (or the User) must know the IP address at which the device can be contacted.
Using RemoteControl with MSP Provision
Before the RemoteControl feature can be used for a given device from the MSP
Provision Product, the following prerequisites must be met:
•
•
Vendor Keys.
•
The Device must have the RemoteControl Package Installed
The MSP Provision product ships with the RemoteControl Package built-in. As part
of the Staging or Provisioning of the device, this Package must be installed. If the
RemoteControl Package was NOT installed as part of Staging, then it can be
deployed via a Provisioning Policy, either Manual or On-Going.
Once this Package is successfully installed, the RemoteControl Server will
automatically launch on the device, if the requisite Vendor Key is present.
•
MSP (or the User) Must Know the IP Address of the Device
In order to launch RemoteControl for a device that has the RemoteUI Server running
on it, MSP (or the User) must know the IP address at which the device can be
contacted.
Dealing with Device IP Addresses
Both RemoteUI and RemoteControl require an IP Address or name (e.g. DNS, etc.) in
order to contact the device to be controlled. The device must be contactable at this IP
Address or name. See the section “Dealing with Device Contactability,” later in this
document, for information on dealing with any contactability issues that may exist.
Since MSP 3 Stage is NOT an Asset Management solution, it provides no means to track
devices or launch RemoteUI for them. When using RemoteUI with MSP 3 Stage, the IP
Address or name of a device must be determined manually by cooperation between the
device User and the MSP User that seeks to control the device.
MSP 3 Provision DOES offer some Asset Management functionality and hence DOES
provide a means to track devices and launch RemoteUI or RemoteControl for them.
MSP Provision ALSO provides a means to remotely collect the IP Address for a device,
so it can automatically be available for launching RemoteUI or RemoteControl.
Remote collection of device IP Addresses is accomplished via the built-in GetAdapters
Control Module. This Package can be Staged or Provisioned to a device, after which the
device will report information about its network adapters each time it checks in.
Dealing with Device Contactability
Depending on the type of network connectivity being used by the device and the
organization of the network between the device and the computer from which it will be
controlled, the device may or may not be contactable. If the GetAdapters Control Module
is used as described in section “Dealing with Device IP Addresses”, the device can only
report to MSP the IP Address that it knows for itself. Depending on the network topology,
this IP Address may or may not be contactable by the computer from which the User
wished to control it.
The most common reasons for a lack of contactability are Network Address Translation
(NAT) Routers and Firewalls. Both of these can effectively block certain network traffic
and interfere with the contactability required for RemoteUI or RemoteControl. The NAT
or Firewall that is blocking required contactability may or may not be under the direct
control of the Enterprise. For example, most GPRS service providers (carriers)
implement a NAT and hence do not allow devices to be contacted. In such a case, only
the carrier can correct the issue, and doing do might require a different data plan, if it is
available at all.
When a Firewall is under the control of the Enterprise, then it may be possible to open
the necessary ports through the Firewall to achieve the requisite contactability. When a
NAT is under the control of the Enterprise, it may be possible to configure the NAT
Router to achiever the desired contactability.
If One to One NAT is in use, the it will be necessary to set up “Port Forwarding” to
forward contactable (i.e. Public) IP Addresses through to the uncontactable (i.e. Private)
IP Addresses. If One to Many NAT is in use, then it will be necessary to set up “Port
Address Translation” (PAT) to map varied ports on the single contactable (i.e. Public) IP
Address through to the desired port on the uncontactable (i.e. Private) IP Addresses.
If “Port Forwarding” or “Port Address Translation” are used, then contactability of devices
will generally require that MSP use IP Addresses other than those that can be reported
by the device. Consequently, the GetAdapters Control Module cannot be relied upon to
collect these addresses. In such situations, it will be necessary to define the IP
addresses to be used to contact devices by uploading Device Attributes into MSP using
CSV files as described later in this section.
Launching RemoteUI Manually via a Web Browser
When using RemoteUI with MSP 3 Stage Edition, it is possible to launch RemoteUI
manually using a Web Browser. Note that this approach CANNOT be used when
launching RemoteControl, since RemoteControl requires authentication with the device
that is ONLY available when launched via the MSP 3 Console UI.
To launch RemoteUI manually via a Web Browser, ensure that all the prerequisites
defined in section “Using RemoteUI with MSP Stage”, earlier in this document. Using the
IP Address or name (e.g. DNS, etc.) at which the device is known to be contactable from
the PC, launch the Web Brower on the computer and browse to a URL in one of the
following formats:
http://deviceip:8080/RemoteControl/
or
http://devicename:8080/RemoteControl/
The Web Browser will display an HTML page, served up by the device and a Java applet,
also served up by the device, will be hosted on that HTML page. The Java applet
connects back to the device and presents the RemoteUI functionality.
Note that the use of the Java applet requires Internet Explorer on the computer from
which the device will be controlled have the Java Runtime Environment (JRE) installed.
The JRE can be downloaded from various Web Sites, including http://sun.com.
Launching RemoteUI via the MSP 3 Console UI
The RemoteUI Package contains information that allows the MSP 3 Stage Console UI to
automatically launch RemoteUI via a link shown in the Tools section of the Device Detail
page. A link to launch RemoteUI is shown in the Tools section ONLY if the software
inventory reported for by the device includes the RemoteUI Package. Note that
depending on whether a device has been Staged or Provisioned, the means by which the
Device Detail page is reached may be different. Clicking the RemoteUI button on the
Device Detail page launches a new Web Browser window that displays a RemoteUI
“launching page”.
The “launching page” may show information MSP 3 knows about the device if the
GetAdapters Control Module is running on that device. Since the GetAdapters Control
Module cannot be used with MSP 3 Stage Edition, this information will never be known
by MSP 3. If the information is not known by MSP 3 or of the information known by MSP
3 is not correct, then the information will need to be entered and/or edited by the User
before proceeding. Once the information on the “launching page” is correct, click the
“Connect” button on the to connect to the device using that information.
Note that any information modified on the “launching page” is transient and any changes
made by the User will NOT be saved by MSP 3 and hence will NOT be displayed when
the page is re-entered at a later time. To permanently change the IP address used to
contact a device, it will be necessary to upload the IP address into MSP 3 using a CSV
file as described later in this section.
Device Attributes used by the RemoteUI and RemoteControl
When RemoteUI or RemoteControl is launched from the MSP 3 Console UI, the last
known value of the Device Attribute containing the device IP address is used. If IP
Addresses within the network change, the IP address last reported by the device may
NOT actually be the current IP Address of the device.
In MSP 3.1, the GetAdapters Control Module collects adapter information for a device
each time the device checks in. Nonetheless, the IP Address known by MSP for a device
could become out of date. The GetAdapters Control Module determines and reports to
MSP what it considers to be the “best” adapter for contacting the device. If the state of
device connectivity changes (e.g. switching between radios, going in and out of
coverage, DHCP lease renewal, etc.), then MSP will not know the new information until
the device next checks in. This should seldom be an issue if the device is checking in
fairly frequently (the default is every 15 minutes). But if a device has been reconfigured
to check in much less frequently, then Users should be made aware that they may not be
able to connect to a device until its next check in provides MSP with updated information.
The GetAdapters Control Module reports the IP Address of the device via the Device
Attribute UserAttribute.adapterBest.ipAddr. This is then used by MSP 3 to fill in the
“launching page” for RemoteUI or RemoteControl. This Device Attribute COULD also be
set by uploading a CSV file to set Device Attribute values of many devices at once. But
since GetAdapters reports information each time the device checks in, it would override
any information uploaded via a CSV file. This could lead to confusion depending on how
often the device checks in, since the uploaded CSV values would be used for “a while”
then changed based on the values reported by the device.
To avoid this, and to enable some of the more complex cases described later in this
section, MSP provides additional Device Attributes which, if present, override the
information collected and reported by the GetAdapters Control Module. These Device
Attributes are:
•
UserAttribute.remoteControl.natIpAddr
If this Device Attribute is present for a device, then MSP uses that in preference to
the Device Attribute UserAttribute.adapterBest.ipAddr. This is important for cases
where the public address for a device cannot be known by the device, such as in
cases where “Port Forwarding” or “Port Address Translation” will be required.
•
UserAttribute.remoteControl.natWebPort
the default port number of 8080. This is important for supporting cases where “Port
Address Translation” will be required,
•
UserAttribute.remoteControl.natRcPort
the default port number of 7777. This is important for supporting cases where “Port
Address Translation” will be required,
Note that in all cases where CSV files are described for specifying IP Addresses, names
(e.g. DNS, etc.) could be used instead, if the names ultimately resolve to the proper IP
address values.
Note also that when using CSV files to upload Device Attributes, the values uploaded will
apply ONLY to devices that were discovered prior to the time that the CSV file was
uploaded. So, if a large CSV, covering all potential devices in the Enterprise were
prepared and uploaded early, before all devices were discovered, some of the data would
be discarded since it did not apply to devices that were actually known by MSP. In such
a case, the CSV could simply be re-uploaded later, after more devices had been
discovered. There is no harm or danger in re-uploading Device Attributes that have been
uploaded before.
If a device is operating inside a NAT, relative to the computer that will be controlling it,
then the address reported by the device typically CANNOT be used, since it is a Private
IP Address at which the device will NOT be contactable by the PC. There are two
primary NAT cases.
One to One NAT
In One to One NAT, the NAT router obtains a unique Public IP Address from the outer
network for each device and maps it to the Private address assigned to each device by
the router’s local DHCP server. The device is aware only of its Private IP Address.
Consequently, the GetAdapters Control Module cannot report the IP Address at which
the device can be contacted.
Instead, the Public IP Addresses of the devices must be defined to MSP via a CSV file
that would be uploaded into MSP using the Library->Attributes page of the MSP 3
Console UI. This information would generally be determined at the time the NAT Router
is configured and captured in a CSV file for uploading into MSP.
A CSV file to set up Device Attributes to configure RemoteUI or RemoteControl over One
to One NAT might look as follows:
identity.uuid,1501aa010c42fd61,UserAttribute.adapterBest.ipAddr,10.10.1.1
Uploading the above CSV file would define the specified Public IP Addresses for the
corresponding devices identified by UUID.
Note that in MSP 3, UUID is the only automatically collected and reported Device
Attribute available for identifying individual devices. If other Device Attributes have been
added, then they could also be used in the CSV file to identify the devices for which the
IP address attribute should be set.
One to Many NAT
In One to Many NAT, the NAT router obtains a single Public IP Address from the outer
network that it shares amongst all devices. As in the One to One NAT case, the device is
still aware only of its Private IP Address. Consequently, the GetAdapters Control Module
cannot report the IP Address at which the device can be contacted.
Furthermore, since there is only a single Public IP Address used for all devices there is
no way, using that IP Address alone to contact the correct device. As mentioned earlier,
to support One to Many NAT, Port Address Translation (PAT) must be used. This
requires a different port number to be used for each device that shares the same Public
IP Address. The use of the port number permits the NAT router to forward the
connection to the appropriate device.
MSP assumes the standard default port numbers of 7777 (for RemoteUI separately and
as part of RemoteControl) and 8080 (for non-RemoteUI functions of RemoteControl) for
all devices. For One to Many NAT cases, the standard default port numbers cannot be
used since “Port Address Translation” will be required to traverse the One to Many NAT.
Instead, for each device a unique port (for Remote UI) or pair of ports (for
RemoteControl) will need to be defined as part of the configuration of the NAT Router
and then captured in a CSV file for uploading into MSP.
Remote UI
A CSV file to set up Device Attributes to configure RemoteUI over One to Many NAT
might looks as follows:
identity.uuid,1501aa010c42fd61,UserAttribute.remoteControl.natIpAddr,10.10.1.1
identity.uuid,1501aa010c42fd61,UserAttribute.remoteControl.natRcPort,7701
This assumes that the NAT router has a Public IP Address of 10.10.1.1 and maps port
7701 to port 7777 of one device, port 7702 to port 7777 of another device, etc.
For a real Enterprise, the CSV file would need to be expanded to cover all the devices
behind all NATs. This means the above list would need to be extended based on the
number of devices behind a NAT and then repeated based on the number of NATs.
Uploading the above CSV file would define the specified Public IP Addresses and ports
for the corresponding devices identified by UUID.
RemoteControl
A CSV file to set up Device Attributes to configure RemoteControl over One to Many NAT
might looks as follows:
identity.uuid,1501aa010c42fd61,UserAttribute.remoteControl.natWebPort,8801
This assumes that the NAT router has a Public IP Address of 10.10.1.1 and maps ports
7701 and 8801 to ports 7777 and 8080 of one device, ports 7702 and 8802 to ports 7777
and 8080 of another device, etc.
For a real Enterprise, the CSV file would need to be expanded to cover all the devices
behind all NATs. This means the above list would need to be extended based on the
number of devices behind a NAT and then repeated based on the number of NATs.
Uploading the above CSV file would define the specified Public IP Addresses and ports
for the corresponding devices identified by UUID.
Reducing CSV File Size
As mentioned earlier, MSP 3 provides Device Attributes that can be used to override
values collected and reported by GetAdapters Control Module, hence allowing
GetAdapters to be used in parallel with the definition of IP addressing information by CS
file upload. In some cases, it may be possible to “infer” the Public IP Addresses and
ports information reported by GetAdapters. This could be especially useful if a so-called
“cookie-cutter” approach to network organization is used.
For example, consider that each Site has a Motorola WS-2000 Wireless Switch used in
One to Many NAT mode. Assume that each Site has identical NAT configuration and
that each Site has a relatively small number of Mobile Devices which are assigned “well
known” Private IP Addresses via the WS-2000 NAT DHCP server.
The result of the above is that the WS-2000 at each Site would have a unique Public IP
Address and the devices at each Site would all have identical (overlapping) Private IP
Addresses. This means that every device at a given Site shares the same Public IP
Address (of the WS-2000). It also means that every device, regardless of Site, with the
same Private IP Address could use the same ports.
Given the above assumptions, it would make the NAT Router configuration of the WS2000 switches much easier and would produce a drastically simpler a CSV file to
configure MSP for One to Many NAT across many Sites. An example of such a CSV file
is shown below:
UserAttribute.siteID,SiteA,UserAttribute.remoteControl.natIpAddr,10.10.1.1
UserAttribute.adapterBest.ipAddr,192.168.1.101,UserAttribute.remoteControl.natRcPort,7701
UserAttribute.adapterBest.ipAddr,192.168.1.101,UserAttribute.remoteControl.natWebPort,8801
This example assumes that the NAT router has a Public IP Address of 10.10.1.1 and
maps ports 7701 and 8801 to ports 7777 and 8080 of the device with the Private IP
Address of 192.168.1.101, ports 7702 and 8802 to ports 7777 and 8080 the device with
the Private IP Address of 192.168.1.102, etc.
For a real Enterprise, the CSV file would need to be expanded to cover all NATs and the
maximum number of devices behind any one NAT. But there is a significant reduction in
CSV size, which comes from leveraging the wildcard comparison capabilities of the CSV
file.
Consider the following lines:
UserAttribute.siteID,SiteA,UserAttribute.remoteControl.natIpAddr,10.10.1.1
UserAttribute.siteID,SiteB,UserAttribute.remoteControl.natIpAddr,10.10.1.2
UserAttribute.siteID,SiteC,UserAttribute.remoteControl.natIpAddr,10.10.1.3
The above will cause all devices whose Site ID matches “SiteA” to be assigned the value
of “10.10.1.1” for the Device Attribute “UserAttribute.remoteControl.natIpAddr”, all
devices whose Site ID matches “SiteB” to be assigned the value of “10.10.1.2” for the
Device Attribute “UserAttribute.remoteControl.natIpAddr”, etc. This means that one line
covers the assignment of a Public IP Address to every device at one Site.
Similarly, the consider the following lines:
The above will cause all devices whose Private IP Address matches “192.168.1.101” to
be assigned the value of “7701” to Device Attribute
“UserAttribute.remoteControl.natRcPort” and the value of “8801” to Device Attribute
“UserAttribute.remoteControl.natWebPort”, all devices whose Private IP Address
matches “192.168.1.102” to be assigned the value of “7702” to Device Attribute
“UserAttribute.remoteControl.natRcPort” and the value of “8802” to Device Attribute
“UserAttribute.remoteControl.natWebPort”, etc. This means that one line covers the
assignment of a given port to every device using that port across all Sites.
If there were 10 devices per Site and 500 Sites, this would reduce the size of the CSV file
from 500*10*3 = 15,000 lines to 500*1+10*2 = 520 lines. Clearly this is a major savings,
both in initial creation of the CSV file and maintenance of the CSV file if IP addressing
within the Enterprise should later change.
Chapter 6 Other MSP Features and Operations
Importing and Exporting
Transferring Packages To or From MSP 3 Servers
If Objects will be transferred between MSP 3 Servers, particularly Bundle Objects, it may
be necessary to transfer Packages so that any Packages referenced by one or more
Bundles will be present, thus allowing the successful transfer of the Bundles.
There is no means provided in either MSP 3.0 or MSP 3.1 to export Packages from an
MSP 3 Server using the MSP 3 Console UI. If it is necessary to transfer Packages from
one MSP 3 Server to another, it must be done by accessing the Windows Console of the
Server.
If only a few Packages are involved, and if the original APF files are available, it may be
simplest to just manually import the required Packages, one at a time into the destination
MSP 3 Server before importing the Objects that reference the Packages.
If, however, many Packages are involved, or if it is uncertain whether or not the identical
versions of the APF files for all Packages are available, then it may be preferable to
extract the Packages from the source MSP 3 Server and then install them into the new
MSP 3 Server. This can be done by using the following procedure:
•
•
•
•
•
•
•
Log into the source MSP 3 Server via the Windows Console of the PC on which it is
running.
Browse to the folder <install dir>\Library\Packages.
Copy from the folder all (or desired) Package APF files to an external media or
location.
Log into the destination MSP 3 Server via the Windows Console.
Browser to the folder <install dir>\PackagesToInstall.
Copy into the folder all (or desired) Package APF files from an external media or
location.
Wait for MSP to detect and process the Packages.
•
•
•
Refresh the folder and see that all Packages have been removed or replaced by an
Error file.
Determine and correct the cause for any error if needed. The most common reason
for an error is when the same version of the same Package already exists.
Log into the MSP 3 Console UI of the destination MSP 3 Server and verify that all
expected Packages are shown on the Packages sub-tab of the Library tab.
Transferring Objects Between MSP 3 Servers
MSP 3.1 allows all types of Objects to be created from within the MSP 3 Console UI.
This is a significant improvement over MSP 3.0, where many Objects had to be created
externally using the MSP 3.0 Object Builder utility and then transferred into MSP. MSP
3.1 also allows all types of Objects to be edited from within the MSP 3 Console UI. This
is another significant improvement since over MSP 3.0, since it is no longer necessary to
edit Objects externally using the MSP 3.0 Object Builder utility and then transfer them
into MSP.
MSP 3.1 is fully compatible with ALL Objects created for use with MSP 3.0 and all such
Objects can be preserved across an update from MSP 3.0 to MSP 3.1 and/or freely
imported into any MSP 3.1 Server. Additionally, MSP 3.1 includes comparable
capabilities to import and export Objects in all formats supported by MSP 3.0, all from the
MSP 3 Console UI without the to use the external MSP 3.0 Object Builder utility. For this
reason, the MSP 3.0 Object Builder utility is no longer supplied with or formally supported
in MSP 3.1.
Note that no explicit method was provided to import or export Packages to or from either
MSP 3.0 or MSP 3.1. Nonetheless, since Packages may be referenced by Bundles, it
may be necessary to transfer Packages before Bundles can be successfully transferred.
See the section titled “Transferring Packages To or From MSP 3 Servers” for information
on how to accomplish this.
The following are the key use cases supported for transferring Objects to and from an
MSP 3.1 Server:
•
Import collections of Objects into MSP 3.1 from one or more XML files that were
exported from MSP 3.0
In MSP 3.0, the MSP 3.0 Object Builder utility could be used to export all Objects of
one or more types from an MSP 3.0 Server into one XML file per Object type. If such
exported XML files exist, they can be imported into an MSP 3.1 Server using the
Import XML sub-tab of the Transfer tab within the MSP 3 Console UI.
Each individual XML file will need to be imported into the MSP 3.1 Server one at a
time in the proper order. This will ensure that any referenced Objects exist before
they are needed by Objects that reference them. The recommended ordering is:
Users, Conditions, Settings, Relay Servers, Sites, Message Sets, Bundles, Profiles,
and then Policies.
•
Import individual Objects into MSP 3.1 from one or more XML files that were created
using MSP 3.0 Object Builder utility
In MSP 3.0, the MSP 3.0 Object Builder utility could be used to create individual
Objects of various types and save them as individual Object XML files. If such XML
files exist, they can be imported into an MSP 3.1 Server using the Import XML subtab of the Transfer tab within the MSP 3 Console UI.
Each individual XML file will need to be imported into the MSP 3.1 Server one at a
time and it is the responsibility of the User to import them in an appropriate order
Other MSP Features and Operations 69
such that any referenced Objects are imported before any Objects that reference
them.
•
Import collections of Objects into MSP 3.1 from one or more CSV files that were
created using the MSP 3.0 Object Builder utility and/or hand-edited using a text editor
or CSV-aware tool (e.g. Microsoft Excel).
In MSP 3.0, the MSP Object Builder utility could be used to create a “starter” CSV file
from a “representative” Object of a given type. This CSV file could then be edited
using a text editor or CSV-aware tool (e.g. Microsoft Excel) to add more Objects of
the same type in subsequent rows of the CSV file. If such CSV files exist, they can
be imported into an MSP 3.1 Server using the Import CSV sub-tab of the Transfer tab
within the MSP 3 Console UI.
Each CSV file will need to be imported into the MSP 3.1 Server one at a time and it is
the responsibility of the User to import them in an appropriate order such that any
referenced Objects are imported before any Objects that reference them.
•
Import collections of Objects into MSP 3.1 from one or more XML files that were
exported using the MSP 3.1 Console UI of the same or a different MSP 3 Server.
In MSP 3.1, the MSP 3 Console UI can be used to export all Objects of one or more
types into a single XML file. If only one type of Object is selected, then only the
Objects of that type will be exported. If more than one type of Object is selected, the
Objects of the selected types will be exported in an order that ensures proper
importing of all exported Objects.
•
Import collections of Objects into MSP 3.1 using one or more CSV files that were
created using the MSP 3.1 Console UI and/or hand-edited using a text editor or CSV
–aware tool (e.g. Microsoft Excel).
In MSP 3.1, the MSP 3 Console UI can be used to export any single Object of any
type to a CSV file. This CSV file can then be edited using a text editor or CSV-aware
tool (e.g. Microsoft Excel) to add more Objects of the same type in subsequent rows
of the CSV file. Such CSV files can then be imported into an MSP 3.1 Server using
the Import CSV sub-tab of the Transfer tab within the MSP 3 Console UI.
Each CSV file will need to be imported into the MSP 3.1 Server one at a time and it is
the responsibility of the User to import them in an appropriate order such that any
referenced Objects are imported before any Objects that reference them.
•
Export all Objects of one or more types from an MSP 3.1 Server into a single XML file
using the MSP 3.1 Console UI.
In MSP 3.0, it was possible to use the MSP 3.0 Object Builder utility to export all
Objects of one or more selected types to a specified folder with one XML file being
created in that folder per type of Object. In MSP 3.1 the MSP 3 Console UI can be
used to export all Objects of one or more selected types to a single XML file.
There are several advantages to the new approach. First, since all Objects are in a
single XML file, it is easier to keep track of an share the exported set of Objects.
Second, all Objects are exported in an order that ensures proper importing later. In
the event that it is desired, for some reason, to export a separate file for each Object
type, this can still be accomplished by exporting on selected type of Object at a time.
•
Export a single Object from an MSP 3.1 Server into a CSV file using the MSP 3.1
Console UI.
In MSP 3.0, there was no way to export a single Object of any type; Only ALL
Objects of one or more selected types could be exported. In MSP 3.1, the CSV
export feature can be used to export individual Objects of any type from an MSP 3.1
Server via the Export to CSV button on the Details page for any Object in the MSP 3
Console UI.
Once exported to a CSV file, an Object can later be imported into the same or a
different MSP 3.1 Server. This can be handy for saving and restoring or sharing
individual Objects. Note that there is no means provided to export individual Objects
as an XML file.
This method can also used to create a “starter” CSV file from a “representative”
Object of a given type. This CSV file could then be edited using a text editor or CSVaware tool (e.g. Microsoft Excel) to add more Objects of the same type in subsequent
rows of the CSV file. Such extended CSV files can be imported into an MSP 3.1
Server using the Import CSV sub-tab of the Transfer tab within the MSP 3 Console
UI.
Using CSV Files for Bulk Object Creation
Depending on the Enterprise, the number of Objects of various types to be created may
be quite numerous. MSP 3.1 allows all types of Objects to be created manually as a
CSV file and then imported in bulk into an MSP 3.1 Server using the Import CSV sub-tab
of the Transfer tab within the MSP 3 Console UI.
This can be result in a very significant reduction in effort over creating all Objects
individually via the MSP 3 Console UI. For example, for an Enterprise with 1000 Sites,
each of which has a unique Relay Server and WLAN Settings, there will be a need to
create 1000 Settings Objects, 1000 Relay Server Objects, and 1000 Site Objects.
Creating 3 CSV files and them importing them will likely be far less work than creating
3000 Objects individually.
There is a key limitation that must be understood when using this approach. All Objects
in the same CSV file must specify the same set of attributes, although the values
assigned to the attributes may be different. For example, for Network Settings Objects,
all Objects would need to use the same type of encryption (e.g. WPA-PSK) even though
the details (e.g. Pass phrase) could be different for each Object. If very disparate
Objects of the same type need to be created, then multiple CSV files, one for each set of
“similar” Objects, will be needed.
A CSV file for Bulk Object Creation can be created using the following general procedure:
•
•
•
Using the MSP 3 Console UI, create or locate a single “representative” Object of the
desired type which includes “representative” values for all the desired attributes.
Go to the Object Detail Page in the MSP 3 Console UI and click the Export CSV File
button to export the definition of that Object to a CSV file.
Edit the exported CSV file using a text editor or CSV-aware tool (e.g. Microsoft
Excel).
The first row of the CSV file will contain the Object Class name and should not be
altered.
The second row of the CSV file will contain a list of the attribute names for which the
“representative” Object supplied values and should not be altered.
The third row of the CSV file will contain the “representative” values exported for the
selected Object, in the order defined by the attributes names in the second row.
Note: When importing CSV files into MSP, the values in the password fields MUST BE
preceded by one of two characters, a ‘p’ or an ‘e’. A preceding ‘e’ indicates to MSP
that the following text is currently encrypted. If a field is preceded by an ‘e’, DO NOT
change the values in the field. A preceding ‘p’ indicates to MSP that the following text
is unencrypted and must be encrypted by MSP upon import. Therefore, if you are
entering a new value in a password field, you must precede the value with the letter
‘p’. For example, if a User’s password is xyz123, you MUST enter it as “pxyz123” so
that MSP will encrypt the field.
Additional Objects can be added by adding rows to the CSV file, following the
guideline provided by the “representative” values in the third row.
•
•
Save the new CSV file when all changes and/or additions have been made.
On the Import CSV sub-tab of the Transfer tab in the MSP 3 Console UI, import the
CSV to add all the Objects to the MSP 3 Server.
Note that if the original exported “representative” Object is left in the third row of the
CSV file, then if that CSV is imported into the original MSP 3 Server that Object will
be replaced. This will be benign if the Object has not been changed since it was
exported. To avoid replacing the Object, the third row could be deleted from the CSV
file after all new rows have been added. If the CSV file will be imported into another
MSP 3 Server that does not already have Object, then the row containing the
definition for that Object may be appropriate to leave in the file.
Backup and Restore
MSP 3 provides two methods of backing up the MSP 3 Server database: automated and
manual. MSP backups consist of a copy of the database .mdf file and the log .ldf file.
The backup of the file system is not included in either backup process but is a required
step in a complete system backup.
Note: Backups should only be restored on the same version of MSP. For example,
you should not attempt to restore a backup from an MSP 3.1 system onto an
MSP 3.1.1 system.
Automated
Automated backups are performed automatically every 24 hours at a pre-defined time.
The system administrator can set the time an automated backup is performed using the
MSP 3 Console UI, on the Admin tab, Back-up sub-tab.
Automated backups are stored in the same location as the active database used by MSP.
The only way to restore an automatic backup is to use the MSP Backup Utility described
in the following section. Automated backups are local backups and should be
incorporated into an Enterprise backup management plan. This plan should also include
the backup of the default MSP installation. The location of the MSP files is determined at
installation. All folders should be included in the backup. The folders in an MSP
installation are shown above.
The files in the default MSP directory, the database file, and the log file should be backed
up after the automated MSP backup, and before any additional changes to the MSP
database can occur to ensure accurate association of the database and MSP Package,
Bundle, and Object files.
The Automated Backup may also be disabled using the MSP 3 Console UI, however it is
recommended that this only be done when alternative backup procedures have been
established. One alternative is the Manual Backup procedure described below.
Manual
Manual backups can be made using the MSP Administration Program provided with the
MSP installation. Refer to the MSP Administration Program section for more information.
Asset Management
Although the primary function of MSP 3 is to Stage and Provision Mobile Devices, some
of the MSP features can be used to manage Enterprise Mobile Devices as assets. The
following list of topics is not meant to be comprehensive but is only intended to provide
some ideas on how MSP 3 can be used to manage assets.
•
Sort devices by “As of” time to see when they last checked in. This can give an
indication of when a device may have gone “missing”. Note that although devices
may check in often (default is every 15 minutes), they do not upload a new discovery
document unless something has changed. As such, MSP will not see a change in
the time of the document and hence will not update the “As of” time for the device.
The MSP Agent will, by default, upload a discovery document at least once per day,
even if it has not changed. This would allow the “As of” time to be used to tell if a
device has not checked in for multiple days, which could be useful.
Through the use of an Agent.30 Settings Object, the MSP Agent can be configured to
force a discovery document to be sent every N check-ins. This can be used to adjust
the maximum time between updates of the “As of” time.
•
•
•
•
•
•
Push-All a Manual Policy that deploys a Bundle containing a “benign no-op” Package
to a device with Force Install. Those devices that become compliant are responding.
Those that stay non-compliant are not. This could be a way to determine which
devices are “on and working” at a given time.
Develop a custom one-time Control Module that prompts the User to enter a Device
Friendly Name or User Name and places the entered value into a device attribute.
This will allow Users to track devices by names that are meaningful, as opposed to
tracking them by UUID.
Write a custom Repetitive Action Control Module that collects a few key pieces of
information about a device and puts them into device attributes. This could allow
periodic sampling and reporting of system information (e.g. memory, processes,
battery, etc.) or application information (number of transactions, what screen on the
application is it in, etc.).
Use the LockAndWipe Control Module to lock down devices under specific
conditions, use the device attributes reported by LockAndWipe to classify devices
based on their lock/wipe/unlock status. This could allow a User to display potentially
lost or stolen devices.
Develop custom Condition Plug-ins to enhance the ability for LockAndWipe to trigger
based on system or application-specific conditions (for example, too few application
transactions completed in a given unit of time). Use as above for device tracking
from the MSP 3 Console UI.
Create a Policy whose Applicability Rules check some useful combination of Device
Attributes. Keep the Policy deactivated and use the Applicable and Not Applicable
links on the Policy Detail page for that Policy to obtain lists of devices that do and do
not meet the specified Applicability Rules. This could also be used, for example, to
locate a device based on a Device Attribute that is currently not supported by the
Filter function on the Device Status page.
Site-based Management
Site-Based Management involves assigning Devices to Sites so they can be tracked and
managed based on the locations at which they are being used.
MSP 3 Sites
MSP 3 defines a Site as a location within the Enterprise at which a Mobile Device will be
used. Typically this would be a physical place such as a warehouse, an office building, or
other remote location. Sites are optional in MSP 3 and need not be used when they do
not make sense to the nature of the Enterprise.
Site-Based Management can be an especially valuable feature to use if the nature of the
Enterprise has Mobile Devices being used at well-defined locations. Sites provide the
ability to configure Mobile Devices with additional information pertinent to a given
location. This could include WLAN Settings and/or Relay Server Settings. Sites can also
provide a convenient means to track where Devices are being used.
There are two types of Sites that can be defined in MSP 3:
•
Staging Sites
Staging Sites are locations within the Enterprise where Mobile Devices will be
Staged.
Since Staging is typically a one-time operation, Devices are often not intended to be
used at the locations at which they are Staged. Further, Settings that may be applied
to a Device to allow it to be Staged at a Staging Site are typically not made persistent
since Devices are typically not expected to remain at a Staging Site once Staging is
complete.
•
Production Sites
Production Sites are locations within the Enterprise where Mobile Devices will be
used for Production operations.
Even if only MSP 3 Stage Edition is being used, there may still be a need for
Production Sites since the device may need to be configured for use at a different
location than the one at which it was Staged. In such cases, it would be expected
that Settings would be persistent until they are changed by Staging the device with
new Settings.
If the MSP 3 Provision Product is being used, then ongoing management of Devices
at Production Sites becomes possible. In such cases, Devices are likely expected to
remain at Production Sites for significant durations and hence Settings applied to a
Device to allow it to be used at a Production Site must typically be persistent.
For every Production Site created, MSP will automatically create a Production Site
Bundle that can be used assign Devices to that Production Site.
One exception to the above is when a Device will be Staged at the same location at
which it will be in Production use. In such cases, a Site can be defined to be BOTH a
Staging Site and a Production Site and the SAME Site can be used for both purposes.
It is also important to note that Sites are a somewhat “loose” concept in MSP 3. While
Site Objects can be defined and Devices can be assigned to those Sites, it is NOT
necessary for a Device to be assigned to a Site for which a Site Object is defined within
MSP 3.
A Device need not be assigned to ANY Site. A Device can also be assigned to ANY Site
name, whether or not a Site Object exists in MSP 3 with that name. If a Device is
reported as being assigned to a given Site name, the MSP 3 Provision Console UI will
reflect that fact, whether or not a Site Object in MSP 3 exists with that name.
Site Assignment in MSP 3
Site Assignment in MSP 3 most commonly means assigning a Mobile Device to the
Production Site at which it is or will be used.
There are three primary methods by which a Device can be assigned to a Production
Site:
•
•
•
Staging the Device for use at a Production Site
Pushing a Production Site Bundle as Content
Using the Automatic Site Assignment Control Module
All of the above methods accomplish the assignment of Devices to Production Sites by
causing the proper Production Site Bundle(s) to be deployed to the Devices. These
methods are described in more detail later in this section.
When a Production Site Bundle is deployed to a Device, it causes any Settings defined
as part of that Production Site to be applied to the Device. It also causes the value of the
Device Attribute UserAttribute.siteID to be set to name of that Production Site. Once this
Device Attribute is reported to MSP 3 by the MSP 3 Agent, the MSP 3 Provision Console
UI will reflect that the Device is assigned to that Production Site.
Once a Device has been assigned to a Production Site, it will remain assigned to that
Production Site unless it is explicitly re-assigned to a new Production Site. Site reassignment can be achieved using any of the same methods used for initial Site
assignment or can be through various manual process that will be discussed later in this
section.
Staging the Device for use at a Production Site
The simplest method to initially assign a Mobile Device to a Production Site is by Staging
the Device for use at that Production Site. This is done by creating a Staging Profile that
inherits from a Production Site. This will cause the Device to automatically pull the
Production Site Bundle at the end of the Staging Process.
Note that Devices may be Staged at separate Staging Sites locations or may be Staged
at the locations at which they will be in Production use.
•
•
If the Device will be Staged at a different location from which it will be in Production
use, then the Staging Profile should inherit from a separate Staging Site that defines
the location at which it will be Staged AND from a Production Site that defines the
location at which it will be in Production use.
If the Device will be Staged at the same location from which it will be in Production
use, then the Production Site should be defined to be BOTH a Staging Site AND a
Production Site. Then the Staging Profile should inherit from the SAME Site as both
a Staging Site, that defines the location at which it will be Staged, and a Production
Site, that defines the location at which it will be in Production use.
This method is very powerful since it ensures that when a Device completes the Staging
process it is properly configured for use at its target Production Site and is registered with
MSP 3 as being assigned to that Production Site. This is true even if the Device had to
be temporarily configured differently during Staging. It also ensures that the Settings
appropriate for the Production Site are applied persistently.
Pushing a Production Site Bundle as Content
The simplest method to manually assign a Device to a Production Site remotely from the
MSP 3 Console UI is by Pushing a Production Site Bundle as Content.
This is done by creating a Provisioning Policy to push the Production Site Bundle to a
Device. When selecting the Content to be deployed by the Policy, instead of choosing a
User-Defined Bundle, choose Content – Site, which allows you to select a Production
Site Bundle that was automatically created by MSP when the Production Site was
created.
This method is very powerful since it ensures that when a Devices is assigned to a
Production Site it is also properly configured with the Settings required for use at that
Production Site and registered with MSP 3 as being assigned to that Production Site.
Using the Automatic Site Assignment Control Module
If Devices can move between Production Sites or if there are many Production Sites and
it would be too labor-intensive to Stage Devices for use at their target Production Sites, it
may be preferable to assign Devices to their Production Sites by Using the Automatic
Site Assignment Control Module.
This is done by installing the AutoSiteAssign Control Module Package to a Device and
then configuring it using a Settings Object. This will cause the Device to determine
dynamically what Production Site it “should” be at and arrange to automatically assign
itself to that Production Site. See the section on Control Modules for information on
configuring the AutoSiteAssign Control Module.
AutoSiteAssign uses a Relay Server Information file that is automatically created by MSP
3 and delivered to the Relay Server. This file contains a list of all Sites that use the Relay
Server and also may contain the name of WLAN Profile used by each Site.
AutoSiteAssign can be configured to determine the Production Site to which a Device
should be assigned either based on the Relay Server being used by the Device or based
on based on BOTH the Relay Server being used by the Device and the current WLAN
Profile name being used by the Device. Since a given Relay Server can be shared by
multiple Sites, and since a given WLAN Profile name could be used at multiple Sites,
AutoSiteAssign may not be able to uniquely determine a single Site based on the
selected criteria.
In the case where AutoSiteAssign cannot unique identify a single target Site, it can be
configured to prompt the Device User to select the desired Site. Alternately, it can be
configured to skip automatic Site assignment when a unique Site cannot be automatically
determined.
Once AutoSiteAssign determines that a Device should be assigned to a particular
Production Site, the actual assignment is accomplished by pulling the Production Site
Bundle for the desired Site. This ensures that when a Device is assigned to a Production
Site it is also properly configured for use at that Production Site and registered with MSP
3 as being assigned to that Production Site. It also ensures that the Settings appropriate
for the Production Site are applied persistently.
Manual Site Assignment
The methods of Site Assignment described earlier in this section, which are based on the
use of Production Site Bundles, are generally preferred since they have the benefits of
coordinating the registration of the Device with MSP with the application of Site-based
Settings. There may however be cases where manual Site Assignment methods may
make sense, such as:
• When there are no Site-based Settings that need to be applied to Devices
• When there are many Sites and it is not practical to define Site Objects for them all
• When there is no practical way to assign Devices to Sites automatically
Since, as described earlier, Sites are a “loose” concept in MSP 3, when one or more of
the above, or similar, situations occur, it may not be useful or desirable to perform Site
Assignment based on Production Site Bundles. Instead, it may be preferable to simply
set the Device Attribute that registers a Device with MSP 3 as being assigned to a given
Site.
All Manual Site Assignment methods involve setting the Device Attribute
UserAttribute.siteID to the name of the desired Site. There are two primary methods that
can be used to achieve this in MSP 3:
•
Apply an Attribute Settings Object
In this method, the Device Attribute UserAttribute.siteID is set by applying an
Attribute Settings Object (Attribute.Setting.xml) to one or more Devices.
The Attribute Settings Object allows the values of Device Attributes within the
UserAttribute class to be set via Settings Object. When specifying a Device Attribute
name when creating an Attribute Settings Object, the prefix “UserAttribute.” is always
assumed, hence to set the Device Attribute UserAttribute.siteID, only the name
“siteID” needs to be specified. As the value, specify the name of the Site to which the
Device will be assigned.
Once created, a Settings Object can can applied to Devices as Content by placing it
in a Bundle Object using the Content – Setting option. When an Attribute Settings
Object that sets the Device Attribute UserAttribute.siteID is applied on a Device, the
Device will register itself with MSP as being assigned to that Site the next time the
MSP Agent checks in with MSP.
•
Execute Custom Device Code
In some cases, it may be desirable to have custom code on a Device decide the
name of the Site to which a Device should be assigned. For example, it might be
desirable to have the Device User enter the location or there might be an applicationspecific method for determining where the device is being used. It might even be
possible on some devices to assign a Site based on positioning information, such as
from a GPS receiver.
Once custom Device code has been developed to determine the name of the Site to
which a Device should be designed, this code can simply place the desired Site
name into the Device Registry at the following location:
[HKEY_LOCAL_MACHINE\Software\MSP\Attributes]
“siteID”=”Site_Name”
where: Site_Name is the Site name to which the device should be assigned.
The Device will register itself with MSP as being assigned to that Site the next time
the MSP Agent checks in with MSP.
Status Module
The Status Module allows you to view the status of all the devices and Relay Servers in
your system.
Viewing Device Status
The Device Status page shows the identity and status information about the Mobile
Devices being managed by MSP. The purpose of this page is to display key identity and
status information for all devices or all devices that match the specified search criteria
and to allow navigation to the Device Details page for any displayed device. This page is
useful to survey all or a portion of the managed Mobile Device to determine their status or
to perform a basic inventory of Mobile Devices.
This page shows the Policy Compliance Status for each displayed device. A device is
shown as Compliant if it has been updated with every Policy that applies to it. A device is
shown as Non-compliant if it has not been updated with one or more Policies that apply
to it. This page also shows the As Of time, which is the last time the device checked-in
and provided new information.
To view the details of a particular device, click the name of the Device ID.
Viewing Relay Server Status
The Relay Server Status page shows the status of the Relay Servers being managed by
MSP. The purpose of this page is to display status information for all Relay Servers or all
Relay Servers that match the specified search criteria and to allow navigation to the
Relay Server Details page for any displayed Relay Server. This page is useful to survey
all or a portion of the managed Relay Servers to determine their status or to perform a
basic inventory of Relay Servers.
This page shows the Name and Content Status (Green for success, Red for error, Yellow
for trying to connect) for each Relay Server. The Content Status is the status of files that
are being pushed out to the devices. The Content Processed column gives the last time
that the Relay Server attempted to deliver Content to the devices. The Content Message
column shows the result of the last attempt at Content delivery. If there was an error, the
error message is in the Content Message column.
The Upload Status (Green for success, Red for error, Yellow for trying to connect) refers
to files and information that are passed from the devices to the Relay Server. The Upload
Processed column gives the last time that the Relay Server attempted to retrieve an
upload from the devices. The Upload Message column shows the result of the last
attempt at upload delivery. If there was an error, the error message is in the Upload
Message column.
To view more information about a particular Relay Server, click on the Name of the
server. This link takes you to the Relay Server Detail page.
Security
Using HTTPS with MSP 3
Obtaining a SSL Certificate for the Server
Several providers exist that can coordinate and provide, for a fee, trusted SSL certificates
which can be installed on the MSP 3 Server to enable trusted HTTPS access.
The following are links to some common providers. The following list is provided for
convenience, is not intended to be complete and does not indicate any endorsement by
Motorola:
• www.thawte.com
• www.verisign.com
• www.geotrust.com
• www.godaddy.com
In addition, Microsoft provides the capability to produce self-signed SSL certificates
through the IIS 6.0 Resource Toolkit which can be obtained from Microsoft. Self-signed
certificates may be untrusted by browsers accessing MSP unless the SSL certificates are
exported to the browsers that access MSP.
Note: Verisign, GoDaddy, GeoTrust, Thawte, and Microsoft are trademarks of their
respective companies.
Installing Your IIS SSL Certificate on Microsoft IIS 5.x / 6.x
•
•
•
Select Administrative Tools
Start Internet Services Manager
Open the properties window for the website. You can do this by right clicking on the
•
•
Default Website and selecting Properties from the menu
Open Directory Security by right clicking on the Directory Security tab
Click Server Certificate. The following Wizard will appear:
•
•
•
•
•
Choose to Process the Pending Request and Install the Certificate. Click Next.
Enter the location of our IIS SSL certificate (you may also browse to locate your IIS
SSL certificate), and then click Next.
Read the summary screen to be sure that you are processing the correct certificate,
and then click Next.
You will see a confirmation screen. When you have read this information, click Next.
You now have an IIS SSL server certificate installed.
Important: You must now restart IIS to complete the install.
You may want to test the Web site to ensure that everything is working correctly.
Enabling SSL Web Access for MSP 3 Console UI
•
•
•
In IIS select and right click on Default Web Site, Choose Properties
In Properties select Directory Security.
Select Edit under Secure Communications
•
Select Require Secure Channel (SSL)
•
(Optional) Set up HTTP access to redirect to HTTPS by selecting Custom Errors
Tab in Properties.
•
Select HTTP Error 403.4 and choose a file that you create to redirect. See example
below.
Example File for Redirecting HTTP to HTTPS Access
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>MMS Demo Server Redirector</title>
<meta http-equiv="REFRESH"
Content="1;url=https://www.mmsdemoserver.com/MSP.web"></HEAD>
<BODY>
Loading... https://www.mmsdemoserver.com/MSP.web
</BODY>
</HTML>
MSP Administration Program
Beginning with MSP version 3.1.1, a new Administration Program is provided and
installed on the same system as MSP 3 Server.
Description
The MSP Administration Program provides a convenient way to start and stop MSP
services and to back up the MSP database. The program gives a summary of MSPrelated programs and files installed on the system and provides access to the MSP error
log. This utility also allows you to specify locations of MSP configuration and database
files. The utility is included in the MSP Server installation executable.
You must be logged onto the server machine that has the Administration program
installed on it with Administrator privileges to use the program.
Program Overview
The MSP Administration Program consists of five Modules: Installation, Backup/Restore,
DB Maintenance, Configuration and logging. Click on the tabs at the left to enter the
applicable module.
Installation
The Installation module shows the MSP related files and services installed on the system
and gives their version number. If a file or service is not installed, it will still be listed, but
will be labeled as “No” for Installed and as “N/A” for the Version. Yellow icons are
services. Blue icons are files. The green icon represents the MSP Web program.
Backup/Restore
Use the Backup/Restore module to start and stop MSP services and to back up, restore,
and delete the MSP database files. The backup and restore functions of this module
allow you to manually backup and restore the database files.
Note: Backups should only be restored on the same version of MSP. For example,
you should not attempt to restore a backup from an MSP 3.1 system onto an
MSP 3.1.1 system.
Note: Stopping the MSP Web Application will stop IIS services on XP systems. If other
applications are using IIS, they will also be stopped.
DB Maintenance
The DB Maintenance Module allows Users to check the current collation of the MSP
database and, if applicable, to change the collation to agree with the master database. In
order to check the collation, you must have the SQL sa password. If you do not know the
password, contact Tier II Support.
Configuration
The Configuration module allows Users to specify the location of MSP configuration,
database, installation, and client data files in one place without having to manually
change the path names in multiple places. For instance, if MSP were to be installed on a
server that was using a database in a shared folder on another server, Users can specify
the directory path for the database in the configuration module and it will be changed
throughout the system.
Logging
The Logging module Displays the MSP Logs and allows you to save the logs to a text file.
High Availability Configuration of MSP Server 3.1.1
The High Availability Configuration of MSP Server 3.1 allows for quick system availability
and easy recovery in the event of an unexpected machine failure. The system includes a
Primary MSP Server PC and at least one Secondary MSP Server PC. If the Primary MSP
Server PC were to fail, or if it would need to be shut down for maintenance, the
Secondary MSP Server PC can be used to ensure that the system continues to operate
without a lengthy interruption.
Requirements and Installation
The High Availability Configuration requires at least four Servers or PCs. All of the PCs or
servers must be operating Microsoft Server 2003. The four PC’s include a Domain
Controller PC, an SQL Database and File System PC, a Primary Web Application and
Services PC, and a Secondary Web Application and Services PC. It is possible to have
more than one Secondary Web Application and Services PC if desired. All of the PCs
must be operating on the same domain. Refer to the Mobility Services Platform 3.1.1
Software Installation Guide for detailed information on system requirements and
installation.
Switching to the Secondary MSP Web Application and Services PC
In the event of a failure to the Primary MSP Web PC, or for testing or maintenance
purposes, the Enterprise can be switched over to the Secondary MSP Web Application
and Services PC. Before Switching operation to the Secondary MSP Web Application
and Services PC, stop the MSP Web Services on the Primary MSP Web Application and
Services PC. Use the MSP Administration Program to stop the services.
Note: To prevent loss of data and application errors, only one MSP Web Application can be
operational at a time. In order to operate and test the MSP Web Application on the
Secondary PC, the MSP Web Application and MSP Services must be shut down on
the Primary PC and vice/versa.
Troubleshooting
Performance Monitoring
The Windows Performance Utility can be used to monitor MSP 3.1 performance,
including memory usage.
Start the Performance Monitor utility by going to the Start menu and select Control
Panel>Administrative Tools>Performance. The System Monitor portion of the
Performance tool gives a real-time graphical display of various performance counters.
This part of the Performance tool can be used for a quick monitoring of the system.
Performance Counters can be used to track performance data over a longer period of
time.
To access the Performance Counters, double click Performance Logs and Alerts tree
and click Counter Logs. You can create a new “log Settings” (right-click in the
Performance Window and select New Log Settings ...).
You can include the Counters you need to track, the format of the log, and the time
interval for capturing the counters in the new log definition. Many of the same counters
can be used in both System Monitor and Counter Logs. Refer to the Microsoft
Management Console Help Topics for details.
Using Windows Error Logging
MSP adds entries to the Windows Event log to aid in the trouble shooting process. To
view these MSP entries go to the Start menu and select Control Panel>Administrative
Tools>Event Viewer. Click the Application page in the Event Viewer window. All
events recorded for all applications will be displayed. The events recorded for MSP
begin with Motorola.MSP. Click a specific event in order to view a detailed description of
the event.
The Event log may be exported to a .txt file for later reference. To export the event log
click the Export List button at the top of the Event Viewer window.
Using Staging Logs
Staging logs are a good source of information when troubleshooting. Under normal
operation Staging logs are automatically uploaded from devices to their Relay Server and
then sent to the MSP Server. The information contained in these logs is stored in the
MSP database. The information is then made available through the MSP 3 Console UI.
View the Staging Status of by clicking the Staging tab and then “Staged Devices”. The
Staging->Staged Devices page displays the IDs of the devices that have been Staged.
Click on the link to a device in the “Device ID” column. Detailed information regarding the
device can be obtained by expanding “Device Attributes”, “Installed Packages” and
“Policy Status”.
Expand “Device Attributes” to display device parameters such as software versions
residing on the device as well as IP addresses etc.
Expand “Installed Packages” to display Packages that are installed on the device.
Expand “Policy Status” to show Policies that the device is compliant with. Clicking on the
link under “Last Activity” will display a “Results” table listing various “Activities”, “Dates”
and “Job IDs” for this device.
Device-side Staging Logs
In the case where a device is unable to communicate with a Relay Server, the Staging
logs will not be uploaded and therefore the information will not be made available through
the MSP 3 Console UI. In this situation it is necessary to look at the Staging logs on the
device.
To view the device logs select “Log Menu” from the Main Menu of the MSP Agent.
Selecting “View Log” displays a log of activities involving the execution of the MSP Agent.
A date/time stamp is followed by specific MSP Agent actions such as “MSP 3.0 Agent
starting”, “agent inf Log file Opened”, etc. Selecting “View Job Log” displays a log MSP
tasks. A date/time stamp is followed by a specific task such as “inf Loading Bundle …” ,
“inf Installing Package …”, “inf Package installed…”, etc. Setting the log level will affect
what information is contained in the logs. Available log levels are Critical, Error, Warning,
Info and Verbose.
MSP Services
MSP has a number of services that must be running. In order to view the services that
are running on the system go to the Start menu and select Control
Panel>Administrative Tools>Services.
The MSP services that should be running include:
•
•
•
•
•
Motorola MSP Content Delivery Service
Motorola MSP Discovery and Status Service
Motorola MSP Policy Engine Service
Motorola MSP SMS Content Service
Motorola MSP Task Scheduler Service
The Backup and Recovery utility is the only method that should be used for stopping and
starting MSP Services.
Appendix A Reference Information
Using Condition Objects
A Condition Object is used to define criteria that can be evaluated on a device to
determine whether or not a specified condition exists on that device. As described
earlier, Condition Objects can be used as Policy Readiness Conditions to control when
the execution of Jobs is allowed to occur on individual devices.
In MSP 3.0, Condition Objects could ONLY be used as Policy Readiness Conditions. In
MSP 3.1 and up, Condition Objects can also be referenced by Settings Objects. This
new capability enables Settings Objects to configure dynamic reaction based on
definable conditions on the device. MSP uses this capability to implement two key new
capabilities:
•
Check-In Conditions
The MSP Agent is configured using an Agent.30 Settings Object. This now allows
Condition Objects to be specified that control when the MSP Agent will check in with
the Relay Server. The ability to specify the check-in interval at which the MSP Agent
checks in has not been removed. Instead, this interval can now be used in
conjunction with Check-In Conditions to achieve powerful new results.
If no Condition Objects are referenced by the Agent.30 Settings Object that is applied
to the MSP Agent on a device, the MSP Agent will attempt to check in with the Relay
Server at the frequency indicated by the check-in interval. It may or may not
succeed, but it will try every interval. If connectivity is available, a check-in will
generally occur, unless the Relay Server is unreachable for some reason. Whether
or not the Relay Server was contacted, contact will be attempted again on the next
interval.
If one or more Condition Objects are referenced by the Agent.30 Settings Object that
is applied to the MSP Agent on a device, then the MSP Agent evaluates the Check-In
Conditions every interval but may not actually check-in every interval.
On the check-in interval the MSP Agent evaluates all the Check-In Conditions
referenced by the Agent.30 Settings Object to see if it is ALLOWED to check in with
the Relay Server. Only if ALL such conditions are met will the MSP Agent actually
attempt to contact the Relay Server. This enables fine-grained control over the
communications that actually occur between the MSP Agent and the Relay Server.
Some common cases of Check-In Conditions include:
• Limiting check-in based on what adapter is being used. For example, check-in
might be allowed when WLAN or ActiveSync are being used but not when
WWAN is being used.
• Limiting check-in to certain times or days. For example, check-in might be
allowed on the evenings and weekends, but not during the workday.
• Limiting check-in to occur when there is adequate battery power or when the
device is on the charger.
•
LockAndWipe Conditions
When configuring the LockAndWipe Control Module using a Control.LockAndWipe
Settings Object, Condition Objects can be referenced to specify the conditions under
which lock, unlock, or wipe actions will be taken. This enables sophisticated local
conditions to be used to trigger these actions.
Some common cases of LockAndWipe Conditions include:
• Locking a device automatically when it loses connectivity and/or unlocking it
automatically when it regains connectivity.
• Locking a device when it is placed on the charger and unlocking it again when it
is removed from the charger.
• Locking a device during selected hours of the day or on the weekends.
Condition Objects are implemented as Plug-Ins so the number of available types of
conditions can be extended. Each type of Condition deals with a particular aspect of the
device that can be tested (e.g. Power, Adapters, Time, User Confirmation, etc.). A
specific instance of a Condition Object is created to identify a specific condition on the
device. Condition Objects can generally be combined to create complex combinations.
The new ways to use Condition Objects described above can use any available types of
Conditions, both those built-in to MSP and those added via Condition Plug-Ins. This
provides for a high degree of extensibility.
There are seven types of Provisioning conditions currently supported, which are
described in the following sections:
Adapter condition
The Adapter Condition checks to see which network adapters, if any, are available and
could be used by the MSP Agent to communicate with the Relay Server. When creating
an Adapter Condition Object, you specify either the list adapters that are allowed
(included) or the list of adapters that are not allowed (excluded). You can specify as
many as three adapters in an Adapter Condition Object.
An Adapter Condition Object might be used as a Policy Readiness Condition to prevent a
large Provisioning Job from being executed over the wrong type of adapter (e.g. WWAN)
and cause the Job to be deferred until a more suitable adapter is in use (e.g. WLAN or
Ethernet cradle).
Reference Information 91
AdapterTime condition
The AdapterTime Condition combines the functionality of the Adapter Condition and the
Time condition. This allows you to combine what checks for what adapters are being
used (or not used) with checks for when they can or cannot be used. You can specify up
to five different scenarios in a single AdapterTime Condition Object.
An AdapterTime Condition Object might be used as a Check-In Condition, which could all
of the following to be configured via a single Condition Object:
•
•
•
•
On the weekends, regardless of the adapter used to connect, the MSP Agent should
be allowed to check in up to once every 15 minutes.
When connected via Ethernet Cradle, regardless of the time, the MSP Agent should
be allowed to check in up to once every half hour.
When connected via WLAN, during working hours, which are 9:00AM to 5:00PM on
Monday through Friday, the MSP Agent should be allowed to check in up to once
every half hour.
When connected via WWAN, during early morning hours, which are 2:00AM to
6:00AM, the MSP Agent should be allowed to check in up to once every hour.
Connectivity condition
The Connectivity Condition checks to see when connectivity is continuously available or
unavailable on a device. Two types of constraints are support: Adapter Constraints and
Target Constraints.
An Adapter Constraint allows the result to be based on whether an adapter or class of
adapters has been continuously connected or unconnected for at least a certain duration.
This can a low-impact way of determining, for example, of a device is or is not within
range of a WLAN network. In such a case, it might be important to take action to secure
the device.
A Target Constraint allows the result to be based on whether a specified network address
(target) has been continuously pingable or unpingable for at least a certain duration. This
may be necessary if is capable of “roaming” to a network from which it cannot contact a
specified server. In such a case, detecting the inability to reach a specified server via a
ping may be a more reliable method of detecting effective loss of meaningful connectivity.
A Connectivity Condition Object might be used as a LockAndWipe Condition to cause a
device to be locked when connectivity is lost and unlocked when it is regained or lost.
Confirm condition
The Confirm Condition checks with the Mobile Device User to determine its result. The
prompts to be displayed to the Mobile Device User can be controlled, effectively allowing
the “question” being asked to be customized.
A Confirm Condition might be used as a Policy Readiness Condition to allow a Mobile
Device User to temporarily defer or even reject a Provisioning Job that might interfere
with his productivity at a crucial time.
Power condition
The Power Condition is check to see how a Mobile Device is being powered, including
whether the device is on A/C and or has a suitably high battery level. It can also be used
to prompt the Mobile Device User to place the device into the cradle or change the
battery.
For example, a Power Condition Object could be used as a Policy Readiness Condition
to defer an large OS Update Job until the device is in on A/C power and/or has a full
battery.
Time condition
The Time Condition is used to check the current local date and time on a Mobile Device.
Up to three windows, consisting of start and end date/time pairs, can be specified. The
result is based on whether the current local time on the device falls within at least one of
these windows.
For example, this condition could be used as a Policy Readiness Condition to defer a
large Job until the middle of the night when the device would presumably not be in use.
Universal condition
The Universal Condition checks to see if a certain file, folder, registry value, registry key,
or process exists or does not exist on a Mobile Device. This can be used to check very
generic things about a device, such as the presence of a log or error file, a key placed
into the registry by an application, or a process that is running on the device.
A Universal Condition Object might be used as a Check-In Condition to prevent the MSP
Agent from checking-in while an application is performing some critical activity. This
might be done by having the application create and delete a file around its “critical
section” and having the Universal Condition Object check for the non-existence of that
file.
A Universal Condition Object might be used as a LockAndWipe Condition to cause a
device to be locked if a specific process, such as Solitare.exe is found to be running,
indicating that the Mobile Device User is playing a game.
A Universal Condition Object might be used as a Policy Readiness Condition to cause a
Provisioning Job to be deferred until a critical device file is present.
Using Setting Objects
A Settings Object is used to specify configuration to be applied to a Mobile Device. The
following classes of Setting Objects are built into the MSP Library. Support for some of
these classes of Settings Objects is built into the MSP Client. For the rest, a Package
needs to be Staged or Provisioned to a device before Settings Object of that class can be
successfully applied on that device.
Agent.30
The Agent.30 Settings Object Class enables the configuration of the MSP Agent, allowing
its operation on the device to be adjusted.
The standard Package enable30 that comes with MSP 3 is an example of an Agent.30
Settings Object that configures the MSP Agent to check-in at the default interval of 15
minutes. Additional Agent.30 Settings Objects can be created as needed to customize
the MSP Agent to the needs of your Enterprise.
Agent.AirBEAM
The Agent.AirBEAM Settings Object Class enables the configuration of the Legacy
AirBEAM Client, allowing its operation on the device to be adjusted.
In the event that a need exists to use the Legacy AirBEAM Client for some reason, MSP
3 includes this Settings Object Class to configure its settings, although this should
seldom be required.
Attribute
The Attribute Settings Object Class enables up to five Device Attributes to be assigned
values on a Mobile Device. Only Device Attributes whose names begin with
“userAttribute” can be set. The values of existing Device Attributes can be overwritten
and/or new Device Attributes can be created. Once set, the values of these Device
Attributes are reported back to MSP 3 then next time the MSP Agent checks-in.
An Attribute Settings Object might be used to change the Site to which a Mobile Device is
assigned or to assign tags to a device, such as to indicate that it is part of a Pilot test.
Values assigned to Device Attributes can be examined from the MSP 3 Console UI
and/or used in the definition of Policy Applicability Rules.
Certificate
The Certificate Settings Object Class enables Security Certificates to be installed into the
certificate store of a Mobile Device. Security Certificates are most commonly used when
connecting a device to a network resource, such as when configuring a WLAN or VPN
connection or to access a secure Web Site.
A Certificate Settings Object might be used to install a Security Certificate required to
enable a Web-Based application to access a secure Web Server that implements the
application logic.
Clock.TimeZone
The Clock.TimeZone Settings Object Class enables the configuration of the Time Zone,
which is used to translate time in Universal Time Coordinates (UTC) into the proper local
time on the device.
A Clock.TimeZone Settings Object might be Staged into a device to initially configure its
Time Zone or might be pushed to a device by a Policy to change the Time Zone on the a
device, such as when a device moves to a new area.
Control.AutoSiteAssign
The Control.AutoSiteAssign Settings Object Class enables the configuration of the
AutoSiteAssign Control Module to adjust the criteria used to automatically (re)assign
devices to Sites.
A Control.AutoSiteAssign Settings Object might be used to configure a device to move to
a new Site when it roams to a new WLAN or Relay Server.
Control.LockAndWipe
The Control.LockAndWipe Settings Object Class enables the configuration of the
LockAndWipe Control Module to adjust when the device will be locked, unlocked, and/or
wiped either unconditionally (when applied based on Server Policy) or conditionally
(when determined by referenced Condition Objects).
A Control.LockAndWipe Settings Object might be used to configure a device to wipe all
its data if it is continuously unable to ping a specific server in the Enterprise for longer
than a week.
Network.WLAN.FusionPublic
The Network.WLAN.FusionPublic Settings Object Class enables the configuration of the
802.11 WLAN network on devices equipped with the Fusion WLAN Stack version 2.35 or
2.5 and later. Devices equipped with other versions of the Fusion WLAN Stack must use
the Network.WLAN.Legacy Settings Object Class instead.
A Network.WLAN.FusionPublic Settings Object is commonly used to define the WLAN
settings to be applied on the most recent Motorola Mobile Devices during Staging.
Network.WLAN.Legacy
The Network.WLAN.Legacy Settings Object Class enables the configuration of the
802.11 WLAN network on Mobile Devices with older Legacy version of the Fusion WLAN
Stack, most version of the Mobile Companion WLAN Stack, or the Microsoft Wireless
Zero Config Stack.
A Network.WLAN.Legacy Settings Object is commonly used to define the WLAN settings
to be applied on older Motorola Mobile Devices during Staging.
Network.WWAN.GPRS
The Network.WWAN.GPRS Settings Object Class configuration of the WWAN data
connection on Mobile Devices equipped with General Packet Radio Service (GPRS)
modems.
A Network.WWAN.GPRS Settings Object is commonly used to define the WWAN data
connection settings to be applied on Motorola GPRS-enabled Mobile Devices during
Staging.
UCA
The UCA Settings Object Class enables the configuration of device-specific settings on
Motorola CA50 Mobile Devices.
A UCA Settings Object is commonly used when Staging Motorola CA50 devices to
configure the server location for these network appliances.
FTP Server Reference
The following reference information is included for convenience for choosing and
configuring FTP Servers for use as an MSP Relay Server.
Information is provided for the following FTP Servers:
•
•
•
•
FileZilla, an open source FTP Server.
Microsoft IIS FTP that is provided with Windows. Note that IIS FTP does not support
secure FTP.
Motorola WS-2000 FTP Server. Note that WS-2000 does not support secure FTP.
Any external FTP Servers that are compliant to relevant RFCs.
Configuring FileZilla for use as Relay Server
To configure FileZilla as the Relay Server:
1. Go to FileZilla and select Edit > Users > Add.
The Add User account window appears
2. In the Add User account window, enter the Username and click OK.
The Username that you have entered appears in the User pane.
3. From the Account Setting pane, enable the Enable password check box.
4. In the Password field, enter a password.
5. Go to the Shared folders pane and click Add.
6. Select a folder from your system and click OK.
The selected folder appears under the Shared folders pane. All the Contents (Packages,
Bundles, and network Settings) from MSP will be delivered to this folder.
7. Enable the following options under Files and Directories pane:
Files
•
•
•
•
Read
Write
Delete
Append
Directories
•
•
•
•
Create
Delete
List
+Subdirs
8. Click OK.
Refer the FileZilla documentation for more information.
Once you have configured FileZilla for use as an MSP Relay Server, you must create a
Relay Server Object in MSP with the details pertaining to the FTP Server.
If you wish to use secure FTP on FileZilla, see the section later in this Appendix on
Secure FTP.
Configuring Windows IIS FTP Server as Relay Server
Setting up FTP Server
•
•
•
•
•
•
•
The Windows FTP Server is not installed by default. Put the Windows CD in and use
the following steps to install it.
From the System Start menu, select Control Panel > Add/Remove Windows
Components.
Select Application Server and click Details.
Select IIS and click Details.
Check the FTP Service box and click OK to close the IIS window.
Click OK to close the Application Server window.
Click Next to continue and complete the Windows Components Wizard.
Configuring the FTP Server
•
•
•
•
•
•
•
•
•
From the System Start menu, select Administrative Tools > Internet Information
Services (IIS) Manager
Under the Computer pane, double-click the local computer and select FTP Sites
Select Default FTP Site > Properties.
In the Default FTP Site Properties window:
Under FTP Site tab, set the IP address of the server and the desired port number.
Under Security Accounts tab, set desired FTP Username and password
Under Home Directory tab, set desired local path and make sure it has both Read
AND Write access.
Click OK and make sure the service is running.
Verify that you can access the FTP directory from a different computer.
Make sure you can access the FTP directory from another PC.
Once you have configured IIS for use as an MSP Relay Server, you must create a Relay
Server Object in MSP with the details pertaining to the FTP Server.
Using WS-2000 FTP Server as Relay Server
A Motorola WS-2000 Wireless Switch, running firmware version 2.0 or higher, and
equipped with a Compact Flash (CF) card, implements an FTP Server. This FTP Server
can be used to implement an MSP 3 Relay Server, if desired. This can allow the benefits
of having a local Relay Server without the expense or complexity of installing and
managing a separate FTP Server.
The WS-2000 includes a single built-in FTP User account with a User name of AirBEAM
(User name is case sensitive).
You can configure the password for this account as part of the WS-2000 configuration.
When defining a Relay Server Object to reference a WS-2000 FTP Server, always
specify a User name of AirBEAM along with the password that was configured, and
along with the IP addresses from which MSP and Mobile Devices can access the FTP
Server of the WS-2000. The exact IP addresses required will depend on how the WS2000 is configured (e.g. LAN, WAN, NAT, etc.).
The path specified in the Site definition MUST be /compactflash/MSP 30/ –for both
Public and Private.
Before a CF card can be used in the WS-2000 FTP Server, you must configure the WS2000 to enable CF Card Access (via LAN and/or WAN as appropriate). See Also, you
must format the CF card using the following commands issued via the CLI (command line
interface) of the WS-2000, where the text in bold represents the CLI prompts presented
by the WS-2000.
admin >system
admin(system) >exec cformat
Secure FTP Support
FTPS usage is configured as part of the definition of each Relay Server. When the
Private Server Details are configured to use FTPS as the Protocol, then the MSP 3 Client
will use FTPS exclusively when it communicates to that Relay Server. When the Public
Server Details are configured to use FTPS as the Protocol, then the MSP Server will use
FTPS exclusively when it communicates to that Relay Server Relay Server.
It is possible to configure the Private and Public Details differently for a single Relay
Server, in which case the MSP Client and MSP Server will use different protocols to
communicate to the same Relay Server. For example the MSP Server might be
configured to use FTP because its communication is entirely within a secure network;
whereas MSP Clients might be configured to use FTPS to provide additional security
across a WLAN connection.
The support for FTPS in MSP 3 conforms to RFC 2228 (FTP Security Extensions). MSP
3 supports the AUTH TLS mode of FTPS. The deprecated AUTH SLL, and implicit FTPS
(port 990) modes are NOT supported. MSP does not support the SFTP protocol, which
is part of the SSH (secure shell) suite, and is not actually an FTP protocol.
The FTPS protocol supports three forms of security:
•
Data encryption
All FTP traffic, after the initial AUTH command is encrypted. Technically, FTPS can
support leaving data in the clear on an FTPS connection, but the MSP Client does
not support clear data over an FTPS connection. Data is always encrypted over an
MSP Client FTPS connection.
•
Server authentication
This optional feature authenticates that the FTPS server that the FTPS client is
communicating with is in fact the server it is intending to communicate with. This
feature can defeat man-in-the-middle attacks where a rogue FTPS server
impersonates a Relay Server.
This feature requires that a server certificate, signed by a CA recognized by the
client, to be installed on the client before any FTPS connections are attempted.
Some FTPS servers, including Filezilla (see below), provide tools for generating a
self-signed server certificate that can be installed on a client. The certificate setting
plug-in that is built into the client can be used to Stage and/or Provision server
certificates onto a device.
This feature is enabled using the VerifyServer Relay Server setting. When the
VerifyServer option is enabled, the client will not communicate with the Relay Server
(FTPS server) unless it is able to authenticate the server with the server certificate
installed on the device.
•
Client authentication
This optional feature authenticates that the FTPS client that the FTPS server is
communicating with is in fact who it claims to be.
This feature requires that a client-specific client certificate, signed by a CA
recognized by the server, be installed on the client before any FTPS connections are
attempted. The requirements for this certificate are server dependant.
Enabling FTPS Support
MSP Relay Server Configuration
In general, MSP FTPS is enabled through the Relay Server configuration on the MSP
Server. The MSP Relay Server configuration has fields that can be used to specify FTPS
is to be used by the server and client respectively.
The client-side protocol (FTP or FTPS) is configured using the Private Server Details :
Protocol and VerifyServer fields.
The client-side handler for the Relay Server Settings creates registry entries in the
HKEY_LOCAL_MACHINE\SOFTWARE\AIRBEAM hive.
Direct Registry Configuration
There are special situations where it is appropriate to enable FTPS, and optionally FTPS
server authentication, directly through the device registry.
Two of the situations where the registry can be configured directly are:
•
•
When creating an abupdate.reg file to automate the transition from MSP 2.x to MSP
3.x. In this case, the FTPS registry Settings for the MSP 3.x client are added to the
abupdate.reg file. Refer to the separate document that describes the automation of
the migration of clients from MSP 2.x to MSP 3.x.
When creating a “gold image” that pre-configures the MSP 3.c client. In this case, an
AirBEAM.reg file can be created that initializes the MSP 3.x client Settings during the
device’s initial boot.
Sample Reg File
The following lines are an example of the Content of an abupdate.reg file that could be
used to enable FTPS, and server authentication.
[HKEY_LOCAL_MACHINE\SOFTWARE\AIRBEAM]
"FTPS"="1"
"VERIFYSERVER"="1"
The FTPS and VERIFYSERVER entries could be included in an AirBEAM.reg file in a
“gold image:”
Troubleshooting
Error code
When the client is unable to connect to the specified FTPS server a -1011 error will be
returned from the connection attempt. This error will be written to the MSP 3.0 client log,
and will displayed by the RD client UI, and the 30 agent UI, if enabled.
Error causes
There are two common issues that will cause the client to be unable to connect with an
FTPS Relay Server:
•
•
The FTP Server does not support, or is not configured, to support “AUTH TLS” FTPS
connections
Server authentication is enabled (Verify Server set to true) and the server certificate
is missing or invalid.
Invalid server certificate
A server certificate can be determined to be invalid by the client for several reasons:
•
•
•
Certificate is not signed by a CA that the device recognizes. The certificate must be
signed by a CA for which the client has a root certificate installed. The certificate can
be a self-signed root certificate (see Filezilla below)
Certificate does not contain the correct common name for the server (usually the IP
address or DNS name). The client verifies that the common name in the server
certificate matches the IP address of the Relay Server, as configured on the client.
Certificate time window is invalid. Certificates have a valid date range and the client
verifies the current date on the device is within this range. This error typically occurs
if the server certificate time window has expired. This error can also occur if the
client clock is not set correctly
Diagnostic Steps
The following steps can be used to determine the issue if the client cannot connect to an
FTPS Relay Server.
•
•
•
•
•
Verify the client FTPS Settings (Relay Server – Protocol and Verify Server) are set
correctly.
Use an Ethernet network monitor, or the FTP Server logging to determine whether
the server is processing the FTP AUTH command. If the client disconnects
immediately after the AUTH command then it generally indicates there is an issue
with the server certificate installed on the device. If the server rejects the AUTH
command then generally it means FTPS is not enabled on the server.
Verify the client clock is set correctly. An incorrect client clock setting can cause the
server certificate time window to be considered invalid.
Use the Settings / Certificates control panel applet on the device to verify the server
certificate is installed.
Use the Settings / Certificates control panel applet on the device to verify the
Contents of the server certificate:
• Verify the certificate is signed by a CA for which a root certificate is installed on
the device. If the CA root certificate is not on the device then a certificate setting
can be used to install the root certificate.
• Verify the server certificate’s time window is valid, and specifically that the
certificate has not expired.
• Verify the common name in the server certificate matches the IP address of the
Relay Server, as configured on the client.
Server Certificate Installation
In order to use the FTPS server authentication feature on the client a valid server
certificate must be installed on the client.
The built-in certificate plug-in can be used to Stage and/or Provision certificates onto the
device.
•
Obtain the server certificate
The server certificate can be obtained from a CA, or it can be a self-signed certificate
(see Filezilla below)
The certificate must be in DER format to be installable onto a client device.
•
Create a certificate setting to install the certificate on the device
Use MSP Server to create an instance of a certificate setting that contains the server
certificate
•
Install the server certificate onto the device
Use MSP Staging or Provisioning to install the certificate setting generated above.
Once the server certificate is installed on the device then VerifyServer can be enabled on
the client. Note, that VerifyServer must not be enabled until a server certificate is
installed or the FTPS server authentication will fail and the client will be unable to connect
to the FTPS Relay Server.
Creating a certificate setting
The following steps should be used to create a certificate setting suitable for installation
onto a client:
•
Use the MSP Server to create a new instance of a certificate setting. The certificate
setting contains the following fields:
• Name – enter an unique meaningful name for the setting instance (i.e. <Relay
Server name>_cert
• Description – this optional field can be used to provide a description for the
setting instance (i.e. Server certificate for <Relay Server name>)
• Certificate File – Use the provided browse button to specify the file that contains
the server certificate. Once a file is selected the certificate Contents will be
embedded in the setting. If the server certificate changes then the updated file
will need to be re-selected to update the setting Contents.
• Root Certificate – This boolean field should be set to False if the certificate is not
a self-signed certificate. This field should be set to True if the certificate is a selfsigned certificate (see Filezilla below)
Staging certificates
There are two ways a server certificate can be Staged:
•
•
Include the certificate setting in the “barcodes” section of a Profile
Include the certificate setting in the “Content”, or the Bundle that Staging loads
There are considerations regarding which option is used:
•
•
•
If the certificate is included in the Profile itself then the client can be configured to
authenticate the server and the Staging Content can be downloaded from an FTPS
server that is authenticated.
A certificate can be relatively large (usually 1-2KB). Including a certificate in the
Profile can result in a large Profile. If linear barcodes are being used, an
unacceptably large number of barcodes will be generated. Using PDF barcodes may
be usable, but they will still be several PDF barcodes, that may span more than a
single page. A better solution when including certificates in a Profile may be to use
OnDemand Staging. In this mode, the Profile, including the embedded certificates, is
transferred to the device by the OnDemand server.
One compromise option is to enable FTPS, but not server authentication, in the
Staging Profile and use the Staging Content to download the certificate. This
approach results in smaller barcodes, and may be a reasonable solution in a
dedicated Staging environment. Once the Staging Content is loaded, including the
certificate, server authentication can be enabled.
Filezilla Secure FTP Configuration
Edit - Settings - SSL/TLS Settings
Enable SSL/TLS support
This checkbox should be checked to enable SSL/TLS (FTPS) support
Private key file
This field is used to specify the file that contains the server private key. This field is
automatically filled in if a self-signed certificate is generated (see Generate new
certificate …). This can be the same file as the server certificate file if it contains the
private key.
Certificate file
This field is used to specify the file that contains the server certificate. This field is
automatically filled in if a self-signed certificate is generated (see Generate new
certificate …)
Allow explicit SSL/TLS on normal conditions
This checkbox should be checked to enable explicit SSL/TLS (AUTH TLS) support
Force explicit SSL/TLS
This checkbox may be checked to disable FTP and only allow FTPS connections
Force PROT P to encrypt data channel in SSL/TLS mode
This checkbox should be unchecked
Listen for SSL/TLS-only connections on the following ports
This field should be cleared in order to disable implicit FTPS (not supported b MSP). The
default value is 990.
Generate new certificate …
This button can be used to create a self-signed server certificate (see Creating a selfsigned server certificate)
Creating a self-signed server certificate
The Filezilla server supports generating a self-signed server certificate. This approach
can be useful during testing because it is faster than obtaining a server certificate signed
by a real CA.
The following dialog is used to create a self-signed server certificate. Most of the fields
are informational only.
Key size
Specify the key size for the server certificate. Larger keys are more secure, but the
generated certificate file is larger. The default value of 1024 is suggested.
2-Digit country code
Specify the country code of the country where the server is located (i.e. US)
Full state or province
Specify the state where the server is located (i.e. Texas)
Locality (City)
Specify the city where the server is located (i.e. Houston)
Organization
Specify the organization the server is associated with (i.e. Motorola)
Organization unit
Specify the unit within the organization the server is associated with (i.e. MSD)
Contact E-Mail
Specify a contact email address (i.e. support@company.com)
Common name (Server address)
Specify the server’s IP address or DNS name. NOTE: The specified value must match
the IP address used by the client to access the FTPS server.
Save key and certificate to this file
Specify the name and location of the server certificate file to be created. Name the
certificate file Filezilla.crt if the certificate is going to be converted using the PEM to DER
conversion utility (see below).
Generate certificate
Use this button to create the server certificate file with the provided information.
Converting self-signed certificate to DER format
The server certificate generated by Filezilla is in PEM format. Certificates must be in
DER format to be installed on a Windows CE device. There are utilities that can convert
a PEM format certificate to DER format.
One utility that does work to convert PEM to DER is the openssl.exe utility that is part of
openssl. openssl is an open-source implementation of SSL. A separate ZIP file is
available that contains the openssl.exe utility, openssl DLL libraries, and a batch file for
creating a DER format certificate from a PEM format certificate.
The ZIP file with the conversion utility is called FilezillaCert.zip.
Conversion utility
The utility to create a DER format certificate from a PEM format certificate is called
ConvertFileZilla.bat.
The ConvertFileZilla.bat utility creates a DER format certificate (Filezilla.cer) from a PEM
format certificate (Filezilla.crt).
Opening Ports on MSP 3 Server
MSP specifically uses TCP Port 80 (if there is a firewall on the Server) for http connection
with MSP 3 Console UI.
The FTP Servers use a variety of ports that are described below:
If the FTP Server will be running in on the same server, then the appropriate ports will
need to be opened on the firewall depending on whether Active or Passive FTP will be
used.
Note: Windows XP with Service Pack 2 automatically turns on the Windows firewall.
Ports used when FTP Server is in Active Mode:
•
FTP Server's port 21 from anywhere (Client initiates connection)
•
•
FTP Server's port 21 to ports > 1023 (Server responds to client's control port)
FTP Server's port 20 to ports > 1023 (Server initiates data connection to client's data
port)
• FTP Server's port 20 from ports > 1023 (Client sends acknowledgements to server's
data port)
Ports used when FTP Server is in Passive Mode:
•
•
•
FTP Server's port 21 from anywhere (Client initiates connection)
FTP Server's port 21 to ports > 1023 (Server responds to client's control port)
FTP Server's ports > 1023 from anywhere (Client initiates data connection to random
port specified by server)
• FTP Server's ports > 1023 to remote ports > 1023 (Server sends acknowledgments
and data) to client's data port)
If you are using a work station PC and wants RemoteControl connection to the Mobile
Devices from the Workstation PC, you must set port 8080 for communication between
the workstation and the Mobile Devices.
MSP 3 Client Error Codes
The MSP 3 Client components (AirBEAM, Rapid Deployment and the MSP 3.0 agent)
can return error codes in the -8xx rand and the -10xx range.
Error codes in the -8xx range are legacy AirBEAM error codes. Refer to the AirBEAM
User Guide documentation for information on these error codes.
The following table lists the -10xx error codes used by the MSP 3.0 Client.
Error Code
-1001
-1002
-1003
-1004
-1005
-1006
-1007
-1008
-1009
-1010
Description
A Job was orphaned. A Job is considered orphaned when the MSP Agent
starts and the Job was left in a started state. This can occur if a program
within the Job reboots the device (i.e. osupdate) without returning to the
agent.
A pending Job was cancelled.
An error occurred opening the MSP Client log file.
An error occurred reading the MSP Client log file.
Buffer length error. This is an internal error code used by the logging logic and
should never be reported by the agent.
Invalid plug-in class error. This error code is not retuned by the agent. It is
use by custom plug-ins to indicate an unsupported plug-in class value was
specified.
Invalid plug-in provider error. This error indicates the Provider registry value
is missing from the plug-in registration. In other words, the
HKLM\Software\MSP\Plugins\<vendor>\Provider registry entry is missing.
Error reading registry value. This error is returned when an unexpected lowlevel error occurs reading the device registry.
No plug-in provider. This error indicates the a plug-I is not registered
correctly. In other words, the HKLM\Software\MSP\Plugins\<vendor> registry
key is missing.
Missing Bundle error. This error indicates a Bundle specified in a Staging
Profile, or a job, was not found on the Relay Server.
-1011
-1012
-1013
-1014
-1015
-1016
-1017
-1018
-1019
-1020
-1021
-1022
-1023
-1024
-1025
-1026
-1027
-1028
-1029
-1030
Error connecting to FTPS server. This error is usually caused by
missing/invalid server certificate when VerifyServer is enabled.
Invalid Bundle error. This error indicates a Bundle file has invalid Contents.
Invalid Job error. This error indicates a file has invalid Contents
Error occurred during FTP file deletion
Error occurred creating Bundle
Error occurred writing Bundle
Invalid message file. Messages are limited to 50 characters.
Invalid blob header. This error indicates a blob header has invalid Contents.
Invalid device UUID. This error indicates an error occurred while trying to
obtain the device’s UUID from the CE system calls.
Too many attributes. This is an internal error code used by the User attribute
logic and should never be reported by the agent.
No MSP Client mutex error. This error indicates the low-level
Staging/Provisioning engine is in-use by another process.
Provisioning cancelled error. This error indicates the Provisioning process
was cancelled by a Staging process.
Error writing registry entry. This error is returned when an unexpected lowlevel error occurs writing the device registry.
Error processing condition. This error indicates a condition plug-in returned a
failue.
Error occurred during FTP CWD command
Error occurred processing Relay Server info file
Insufficient buffer space for Relay Server info file site list. This is an internal
error code used by the Relay Server info file processing logic and should
never be reported by the agent.
Plug-in (setting or condition) entry point is undefined
Missing plug-in DLL. The specified plug-in DLL does not exist on the device.
Error returned from setting plug-in entry-point.
Device WT4090 Keyboard Anomalies
The keyboard for the WT4090 does not use the expected key combinations in some
cases. When the User selects Exit to shut down the MSP Agent, the UI asks if you are
sure you want to exit and the No button is highlighted. A User would expect that pressing
the Enter button would select “No” and pressing the TAB or Right Arrow key would move
to the Yes button, but this does not work. On the WT4090, the P1 and P2 keys are used
instead. P1 is used for No and P2 is used for Yes.
When the RemoteControl utility sends a message to the WT4090, the message is
displayed on the UI and the OK button is highlighted. Since the OK button is highlighted,
a User would expect to press the Enter button to select it. However, this does not work.
The only way to select the OK button to acknowledge the message is to press the
SPACE key. This is a two button sequence on the WT4090 (Function + BKSP).
Listing of SMS Carriers Domains
The following is a list of domains for some of the SMS Carriers.
Verizon: 10digitphonenumber@vtext.com
AT&T: 10digitphonenumber@mobile.att.net
Sprint: 10digitphonenumber@messaging.sprintpcs.com
T-Mobile: 10digitphonenumber@tmomail.net
Nextel: 10digitphonenumber@messaging.nextel.com
Cingular: 10digitphonenumber@mobile.mycingular.com
Virgin Mobile: 10digitphonenumber@vmobl.com
Alltel: 10digitphonenumber@alltelmessage.com OR message.alltel.com
CellularOne: 10digitphonenumber@mobile.celloneusa.com
Omnipoint: 10digitphonenumber@omnipointpcs.com
Qwest: 10digitphonenumber@qwestmp.com
Glossary
Term
Attribute
Barcode sheet(s)
BLOB
Bundle
Condition Attribute
Device Attribute
Enterprise Mobility
Domain
Enterprise Mobility
Segment
Definition
An Attribute is a name/value pair that is used to define and capture
a single unit of information, such as configuration or status.
Printed sheet(s) of paper containing barcodes that can be
scanned by a barcode scanner built-into or attached to a Mobile
Device.
A Blob is a binary file in which an Object is encoded for transfer
from the MSP Server to a Mobile Device by way of a Relay Server.
Blobs are most commonly used for Objects such as Settings,
Conditions, Bundles, etc.
A Bundle is a generic description of a set of Deployment Steps to
be performed to accomplish Content Deployment as Staging and/
or Provisioning for one or more Mobile Devices. A Bundle can
specify Packages that are to be installed and/or uninstalled in a
defined order and can optionally initiate “reboot” steps if needed. A
Bundle can also specify a Message Set to define messages to be
displayed on the device.
A Condition Attribute is a name/value pair that is defined as part of
a Condition Class and is used to capture information that will
ultimately be used to test a Mobile Device to see if some required
pre-condition is met.
A Device Attribute is a name/value pair that is used to capture
information about a Mobile Device. Device Attributes may be
originate on and be collected from a device and/or they may be
generated on or by the MSP Server. Device Attributes are used to
provide identity and status information about devices, for display
purposes and/or for use in writing and evaluating Provisioning
Policy Applicability Rules
A customer's complete Enterprise mobility domain, which is
comprised of one or more Enterprise Mobility Segments.
A portion of an Enterprise Mobility Domain managed by MSP.
ESSID
Mobile Device
MSP
MSP Client
MSP 3 Console UI
MSP Agent
MSP Server
MSP Server Software
MSP Solution
Network Operations
Center (NOC)
Network Settings
Objects
Packages
Production Site
On Demand Profile
Extended Service Set Identification. The ESSID is the identifying
name of a wireless network. ESSID allows one wireless network to
be clearly distinguishable from another.
A mobile computing device possessing network connectivity and
managed by an MSP as part of an Enterprise Mobility Segment.
A term used generically to refer to all or part of the Mobility
Services Platform Solution. Also used generically to refer to a
specific instance of an MSP Server
A set of software components that collectively implement the
mobility management services on a Mobile Device to integrate the
Mobile Device into an Enterprise Mobility Segment managed by
MSP.
A Web-based User interface used to control an MSP Server and
manage its Enterprise Mobility Segment.
A device-resident software component and part of the MSP 3
Client. Provisioning is the process of keeping devices up-to-date
with respect to software Packages, configuration Settings, and
other device-resident Content. The MSP Agent performs
Provisioning as a background process and hence must be
installed and activated on every Mobile Device before it can be
managed using MSP 3 Provision Edition.
A suitable customer-supplied server, running a supported version
of Windows, on which the MSP Server Software is properly
installed. A single MSP Server is used to manage an Enterprise
Mobility Segment.
MSP Software that can be installed on a Windows Server.
A complete solution deployed using MSP components to manage
a customer's Enterprise mobility domain.
The location from which centralized management operations are
performed.
A Network Settings is any Settings whose Class name in “dotted
name” notation starts with “Network.” These Classes are used to
represent Settings that configure Network Connectivity
subsystems on the device. In particular, all such Settings Classes
relate to types of Connectivity that may be used for Staging or
Provisioning, and hence are of special importance to MSP.
Objects are different work products created and manipulated by
Users of MSP. Objects in MSP include Profiles, Sites, Bundles,
Packages, and Settings.
Packages are software Content that needs to be installed on
Mobile Devices for upgrading or downgrading the devices. MSP
supports Content in the form of AirBEAM Packages.
A Production Site is a Site at which a Mobile Device will be in
Production use. Note that a Production Site may or may not be a
Site at which Provisioning can be performed. If Provisioning will be
performed at the Site, it may or may not be a requirement for a
Production Site to specify Network Settings. If Provisioning of
Mobile Devices will be performed at the Site, then it would be a
requirement for a Production Site to specify a Relay Server, since
otherwise no Content Deployment could be performed at the Site.
The server that serves Staging Profile information to Rapid
Glossary 111
Server
Profiles
Provisioning
Provisioning Client (also
known as MSP Agent)
Provisioning Policy
Provisioning Policy
Condition Plug-In
Provisioning Policy
Deployment Steps
Provisioning Policy Job
Provisioning Policy
Readiness Conditions
Relay Server
Rules (Provisioning
Policy Applicability Rules)
Deployment Client for Staging devices.
Profiles contain network setting details and Packages information
required for Staging of devices.
Deployment of Content (Packages and Settings) to Mobile Devices
that is initiated by a management system.
The device-side component that is responsible for keeping the
device up-to-date as defined by a Provisioning Policy.
On the device, the Provisioning Client is launched as MSP Agent
and identifies itself as such when it runs.
A Provisioning Policy is a generic description of a Content
Deployment that should be performed by MSP, either
automatically or under the control of a User of the MSP 3 Console
UI. A Policy consists of Applicability Rules, Deployment Steps, and
Readiness Conditions. MSP periodically examines each Mobile
Device to determine whether or not each Active Policy is
applicable to that device, based on the Applicability Rules defined
for the Policy.
A Provisioning Policy Condition Plug-In is a means by which new
Condition Classes can be added or existing Condition Classes can
be modified, based on the changing capabilities and needs of
Mobile Devices.
Provisioning Policy Deployment Steps are the steps that will be
followed to deploy software onto one or more Mobile Devices as a
result of an Active Provisioning Profile. Deployment Steps are
encapsulated in a Bundle
A Provisioning Policy Job is an Object created and sent to a
Mobile Device to implement any Policy Deployment Steps
necessary to bring the device into Compliance to a Provisioning
Policy.
Provisioning Policy Readiness Conditions define the conditions
that must be met before a Job can be executed on a Mobile
Device to implement Policy Deployment Steps to make a device
Compliant to a Policy
A Relay Server is an intermediate server used for interchanging
Content and status information between an MSP Server and one
or more Mobile Devices. In MSP 3.0, Relay Servers must be FTP
Servers, which can be located on the same Server as MSP and/or
on other Servers throughout the Enterprise. MSP 3.0 supports two
protocols: FTP and Secure FTP for communicating with Relay
Servers. Relay Servers that use the FTP Protocol must be
compliant to RFCs 959 and 3659 File Transfer Protocol (FTP).
Relay Servers that use the Secure FTP Protocol must be
compliant to RFC 4217, Securing FTP with TLS.
Provisioning Policy Applicability Rules are used within a Policy to
determine the set of Mobile Devices for which the Policy will be
Applicable. A special case of a Rule is “All Devices”, which
indicates that no filtering or limitation on the set of Applicable
devices should be applied. An Explicit Rule can also be defined
which compares one or more of the Device Attributes of a specific
device to supplied values to determine if the Policy is Applicable to
that device.
Settings
Settings Attribute
Settings Plug-In
Site
Staging
Staging Client (also
known as Rapid
Deployment Client)
Staging Barcode Sheet
A Settings is a collection of Settings Attributes that provide
information needed to configure a subsystem on a Mobile Device.
Settings are defined by Settings Classes, which categorize
Settings based on the subsystems they are used to configure.
Classes are also sometimes subdivided hierarchically into Subclasses that allow similar Settings to be further distinguished and
organized. The hierarchy of Settings Classes is represented by
using “dotted name” notation. For example,
Network.WLAN.Legacy, Network.WLAN.FusionPublic, and
Network.WWAN.GPRS
A Settings Attribute is a name/value pair that is defined as part of a
Settings Class and is used to capture information that will
ultimately be used to configure a subsystem on a Mobile Device.
For example, ESSID might be the name of a Settings Attribute
within a Settings Class called Network.WLAN.Legacy, whose
value holds the ESSID of the Wireless Network being configured.
A Settings Plug-In is a means by which new Settings Classes can
be added or existing Settings Classes can be modified, based on
the changing capabilities and needs of Mobile Devices. A Settings
Plug-In implements a single Settings Class and consists of two
parts: An XML Settings Class Definition Document (DefDoc) and a
Settings Device-side Component (DLL). The DefDoc describes
how to display, enter, validate, and encode the values of the
Settings Attributes of that Settings Class. The DLL contains code
to take the values of the various Settings Attributes and apply
them to the appropriate subsystem on a device
A Site is a generic description of a location within the Enterprise at
which a Mobile Device will be used. A Site can be defined to be a
Staging Site and/or a Production Site. A Site can specify
descriptive information about the location of the Site and contact
information for the Site Administrator. Additionally, a Site can
specify Network Settings that should be used by Mobile Devices
operating at that Site and/or a Relay Server that is available for
use by Mobile Devices operating at that Site.
Deployment of Content (Packages and Settings) to Mobile Devices
that is initiated by a device User. Since Staging is often performed
on un-configured Mobile Devices, Staging also allows Settings
(e.g. network and Relay Server) to be configured, from a Profile,
before Content Deployment begins.
The device side component that is responsible for implementing all
device-side Staging activities as defined by a Profile.
On the device, the Staging Client is launched as Rapid
Deployment Client and identifies itself as such when it runs.
A Staging Barcode Sheet is a printable encoding of the information
in a Staging Profile into Barcodes that can be scanned by a Mobile
Device equipped with a Barcode Scanner. Various types of
Barcodes can be generated, depending on the Barcode Scanning
capabilities of various devices. Normal PDF Barcodes have the
highest density, requiring the fewest Barcodes to be scanned for a
Profile. For some devices with lower quality Barcode Scanners,
Small PDF Barcodes can be used to improve the readability, at the
expense of having to scan more Barcodes. For devices with only
Glossary 113
Staging On Demand
Profile Server
Staging Profile
Staging Profile
Deployment Steps
Staging Site
1D (laser) Barcode Scanning capabilities, Normal Linear Barcodes
can be used. For some devices with very low-end Barcode
Scanners, Narrow Linear Barcodes can be used to improve the
readability, at the expense of having to scan more Barcodes.
An On Demand Profile Server allows Staging Profiles to be
acquired by a Mobile Device directly from the PC that is used to
run the MSP 3 Console UI. Using an On Demand Profile Server
enables devices that have connections, such as cradles, ethernet,
etc. that do not require pre-configuration, to be used to accelerate
Staging by avoiding the need to scan Barcodes.
A Staging Profile is a generic description of a Content Deployment
that should be performed by MSP as requested by a User on a
Mobile Device. A Profile consists of Staging Settings, Deployment
Steps, and Staging Options. When Staging is initiated by a User
on a Mobile Device, a specific Profile is acquired by the device.
The Staging Options for the Profile determine how the Profile can
be acquired by the device, which could include having the User
scan a Profile Barcode Sheet or pulling the Profile from an On
Demand Profile Server. Staging of a device proceeds by first
applying any Staging Settings defined by the Profile. Then the
device performs the Deployment Steps for the Profile, which are
defined by a Bundle, to deploy the required software to the device
Staging Profile Deployment Steps are the steps that will be
followed to deploy software onto one or more Mobile Devices as a
result of applying a Staging Profile. Deployment Steps are
encapsulated in a Bundle.
A Staging Site is a Site at which Staging of Mobile Device will be
performed. Depending on how Staging will be performed, it may or
may not be a requirement for a Staging Site to specify Network
Settings. In general, it is a requirement for a Staging Site to specify
a Relay Server, since otherwise no Content Deployment could be
performed at the Site.
Motorola, Inc.
One Motorola Plaza
Holtsville, New York 11742, USA
1-800-927-9626
http://www.symbol.com
MOTOROLA and the Stylized M Logo and Symbol and the Symbol logo are registered in the
U.S. Patent and Trademark Office.
All other product or service names are the property of their registered owners.
© Motorola, Inc. 2007
72E-100158-04

Mobility Services Platform 3.1 User`s Guide

Transcription

Similar documents

here

Inductive Loop Amplifiers Questions? Steve Irwin Gala Dinner

350239B SD505-6RB

wave relay® android™ kit

Glory Hole Spillway Repair - Knowles Industrial Services

Hamilton PPT

Run_Report_2492 - Sydney Hash House Harriers – SH3

Piano Spec Sheet Template

Automated Staging for Built-to