As enterprises deploy mobile applications to increasing numbers of employees, a need arises for an effective way to manage both the applications and the devices themselves. For a small number of remote users, it is possible for IT staff to configure each device individually. As the number grows, mobile device management software quickly becomes necessary. Mobile device management (MDM) platforms focus on providing an intuitive way for system administrators to deploy and manage software applications, usually to a wide variety of devices running on an even wider number of wireless networks. This technology is often provided as an out-of-the-box solution that can be used with existing applications and security architectures.
Figure 16.2 illustrates the most common architecture for device management platforms. As the diagram shows, both client and server components are required for a complete solution. The management server is responsible for the overall device management, software distribution, and administration facilities, while the client component carries out much of the on-device configuration and maintenance. This is accomplished by deploying mobile agent software to the remote devices. This agent can then be configured to carry out a variety of tasks locally on the device, often without requiring a network connection. Depending on the solution being used, there may be client agents for Windows-based laptops, Windows CE/Pocket PC devices, Palm OS, Symbian OS, RIM BlackBerry, and Java clients. Usually, the client functionality varies depending on the platform being used. Laptops have the most complete set of features, and RIM devices usually have the least.
The devices can connect to the server directly using wireless or wireline (very often dial-up) connections or by using a companion PC as a proxy server. The server itself usually stores device statistics in a relational database. The server may also interact with other management software such as Microsoft Systems Management Server (SMS) or directory services such as LDAP or Active Directory.
Traditional LAN-based application management systems have a hard time functioning in mobile and wireless environments where low bandwidth and unreliable network connectivity are common properties. The introduction of new mobile operating systems and wireless protocols do not improve the situation. The cost of managing these devices can surpass the cost of the devices themselves.
Mobile device management software has been designed to overcome these issues in order to reduce the overall cost of a mobile solution. These platforms also provide other capabilities that are well suited for a mobile environment such as remote administration and backup and recovery.
Software distribution is difficult in a networked environment. It becomes even more challenging when mobility is added to the mix. Device management platforms provide the capability to distribute software over a variety of wireless network protocols such as CDPD, Mobitex, GPRS, and 802.11b. In addition, they work with LAN and dial-up configurations and often over a serial port. The software distribution is controlled from a central location making it possible for a single administrator to configure devices in multiple locations using several types of devices. It is even possible to schedule future software installation and activation for a controlled application rollout.
Additionally, remote software management allows administrators to ensure that applications are installed correctly, thereby reducing user error. Both push and pull mechanisms are typically provided. In addition, many of the mobile device packages provide the following software distribution benefits:
File collection and retrieval
Remote command execution and control
As application updates are deployed and users install personal software on their devices, a need arises for a way to manage that software. Snapshots of device configurations can be downloaded to a server, where they can be analyzed to ensure that remote users are following corporate policies with regard to information content and software licensing. It is also possible to remove applications from the device to prevent further data access. This is especially important in the case of a lost device or an unauthorized user.
Hardware tracking is also possible. Corporations can keep track of the number and type of devices that are deployed remotely. With this information they can make educated decisions on additional hardware purchases such as modems, memory cards, and other peripherals. In addition, the cost of future device upgrades can be predicted more accurately.
Remote administration is a requirement for any sizable mobile environment. It is not feasible to continually ship devices back to corporate headquarters, where IT staff configure the applications on site. At the same time, mobile device users should not have to be concerned with hardware and software maintenance issues. Remote device administration solves this problem.
Administration functionality may include, but is not limited to, running custom scripts to delete temporary files, running maintenance applications (scan disk, defrag, virus scans), and monitoring available memory. In some cases, it is also possible to remotely control a device for troubleshooting purposes.
Backup and restoration capabilities are required when a device is lost or malfunctions. By archiving vital mobile device information, corporations can feel confident that important information will not be lost. Data backup can occur transparently so that remote users do not have to be concerned with performing manual backups. When the device comes back online, current data can be downloaded and new software can be installed to replace what was lost.
When evaluating mobile device solutions, certain core features deserve consideration. The platform capabilities discussed in the previous section are common to nearly all vendor solutions. The features described in this section will vary between vendor offerings. Usually only a subset of these features are required for any particular deployment, so during an evaluation you will want to give extra consideration to the components that are relevant to your situation.
Every device management platform has an administration console for managing and scheduling data and software transfers, monitoring systems activity, and viewing client inventory. This console is the main interface into the system, and its importance cannot be overstated. Each vendor provides a different feature set. Some may focus on ease of use by providing advanced wizards to set up common tasks, while others may feel that providing administration from remote sites is important. Another core administration feature is the ability to authorize users for different tasks. For example, you probably would not want to give helpdesk staff the same rights as the system administrator. Finally, the types of client software may make a difference. Very often, both an Internet interface and a Windows desktop client are available.
For on-device functionality, mobile agent software is required. The agent software is responsible for the most common tasks such as application installation, software configuration, and data transfer management. Device management vendors list support for Windows, Windows CE, Palm OS, Symbian OS, RIM, and Java clients, but it is important to realize that the level of functionality varies dramatically between client types. Windows and Windows CE clients usually have the most complete feature sets, while RIM clients are usually quite limited. Keep this in mind when making both device and management platform decisions.
Before the mobile agents can be used, they have to be deployed to each mobile device. There are a variety of ways to accomplish this. Three approaches are common: provide an install tool in an email message; make agents downloadable from a Web page; or activate them automatically during a system login. A fourth option is to install the agent using CompactFlash cards or a companion PC.
Software is also installed on a network server. This software usually stores the device information in a relational database, commonly MS SQL Server, Sybase Adaptive Server Anywhere, or Oracle. Find out what the software requirements are, including whether it has to be installed on a dedicated machine, its hardware requirements, and which enterprise systems it can integrate with.
Though the standard device management functions provide 90 percent of what you will require, there must be a way to perform custom tasks to meet the other 10 percent. This is typically accomplished by enabling the administrator to create and execute custom scripts. This allows for the platform to extend beyond the typical uses, and be useful for situations that may not have been foreseen.
There are two main ways for mobile agents to connect to the device management server: directly or via a companion PC. For direct connectivity, the main network protocols (both wireless and wireline) should be supported. These include LAN and dialup connectivity over TCP/IP or HTTP, 802.11, CDPD, CDMA, GSM, TDMA, GPRS, and Mobitex. If the connection is being made via a companion PC, then you must understand how easy or difficult it is to install and maintain the proxy server that resides on the PC.
Device management platforms support a variety of standards to help pake the systems easier to use and configure. For file and data transfer, support for HTTP/HTTPS provides connectivity through corporate firewalls from virtually anywhere on the Internet. FTP support can provide similar benefits. For data access and reporting, many systems store the captured data in relational databases that can be accessed using ODBC, and queried using SQL. This makes it possible to use reporting packages such as Crystal Reports to analyze the device data. Support for the Desktop Management Interface (DMI) and Windows Management Interface (WMI) is beneficial for collecting hardware and system information, while integration with the Lightweight Directory Access Protocol (LDAP) and Active Directory are useful for accessing user, group, and resource information. Finally, as discussed later in this chapter, the SyncML Initiative has released a standard for device management called SyncML DM.
Any new technology that is introduced to an enterprise should integrate well with existing systems. Mobile device management platforms are no exception. They need to work in conjunction with existing Web servers, firewalls, relational databases, and other system management software such as Microsoft SMS. In addition, being able to integrate with directory servers such as LDAP or Active Directory will allow for anyone to locate resources such as individuals, users, lists, and groups.
Mobile device management solutions address two areas of security. The first is the security of the data and applications themselves. This is accomplished by encrypting the data communication stream and by using digital certificates for authentication. The second is by enforcing corporate security policies. Device Management software can ensure that security software such as firewalls, virtual private networks (VPNs), and virus databases are installed and configured correctly. If a user removes or alters the software in any way, the mobile agent can transparently reinstall or reconfigure it, thereby ensuring the security infrastructure remains intact. Finally, in the case of a lost or stolen device, the device management software can automatically remove any confidential applications or data as soon as the device connects to the Internet. This level of security is not possible without implementing device management software.
Many techniques can be used to provide scalable solutions. Device management platforms provide load balancing and failover capabilities, in addition to various deployment strategies for distributed environments. At least two servers operating in a cluster are required to take advantage of these features.
Load balancing ensures that the users are distributed evenly across the servers within a cluster, while failover allows a system to keep operating as long as any server in the cluster is still active. For deploying applications across multiple geographies, it is possible to distribute management servers in each location to handle that region's set of users. These remote servers can then communicate with one another during system updates.
Unlike corporate LANs, wireless networks are inherently unreliable. Mobile device management platforms include several features that address this. Because it is best to transfer as little data as possible over these networks, only changed data is transmitted, and it is compressed prior to transmission. Also, during transmission, bandwidth "throttling" can detect the bandwidth and scale back the transmission rate during a package download. This makes it possible to distribute applications and data in the background. Larger files can be segmented into smaller chunks before transmission and then reassembled once all the pieces have been sent. This increases the chances that an application will be deployed without interruption. When a connection is dropped during transfer, these platforms provide a way to restart the download at the exact place where it was stopped. (Note: This feature is a requirement for wireless environments, because dropped connections are common.)
A snapshot of the correct client configuration can be taken and compared to the current configuration at defined intervals. If an error is detected, the correct image can be reinstalled to prevent any potential problems. The status can then be sent back to the server for logging purposes. This process can be applied to the mobile operating system itself. Self-healing, as it is called, enables the maintenance of critical applications without intervention by the user or system administrator.
All the information about a mobile environment can be logged in to a database for reporting purposes. This may include application usage patterns, software and hardware inventory, device statistics, and error information. Once this information is captured, many useful reports can be created. For example, for licensing purposes, you may need to know how many users have a certain software program installed; conversely, you may want to know how many users do not have a set of required software on their devices. Along the same lines, you can view application usage statistics to see if the applications are being used to their full potential. When an error occurs, the logs are an invaluable set of information for finding and correcting the problem. But note that the logging and reporting capabilities vary between platforms, so it is a good idea to choose a solution that provides the information that is most important to your organization.
In February 2002, the SyncML Initiative (now part of the Open Mobile Alliance) released the SyncML Device Management (SyncML DM) Protocol specification. SyncML DM defines a protocol for creating interoperable, device- and network-independent management platforms. Many of the concepts are similar to those specified in the SyncML synchronization protocol released in mid-2001. (Refer back to Chapter 10 for more on the SyncML synchronization specification.)
The SyncML DM Protocol consists of two parts: a setup phase and a management phase. The setup phase is responsible for authentication and device information exchange. SyncML DM uses the SyncML authentication framework, with some security extensions defined in the SyncML Device Management Security specification. It is mandatory that the client and server be authenticated to each other before any data is transferred. This can be accomplished using existing transport-level authentication mechanisms, if they use a form of strong authentication; if not, the SyncML DM Protocollevel authentication must be used. Ideally, the underlying transport protocol will permit authentication to occur only once per session. If this is not possible, then each request has to be authenticated. The setup phase only occurs once during a session. Once it is completed, the management phase takes over.
The management phase is responsible for the remaining communication between the client and the server. This involves one or more content packages being sent from the server to the client. If the package requires a response, then the client will send a package back to the server with its response. The response package starts a new protocol iteration. The server can continue to send new management operation packages and continue the session with new protocols iterations as many times as required. The information in each package is defined using XML. Unless specified, the management commands can be executed in any order. There is no timeout between package iterations, because operations consume an unpredictable amount of time. Either the client or the server can abort a session at any time for reasons such as server shutdown, client powerdown, or user interaction from the client.
A SyncML DM Protocol iteration can be initiated either by the client or the server. Where both the client and the server are on and listening for connections, the setup phase initiates an iteration as just defined. Unfortunately, many devices cannot continuously listen for incoming requests from a management server or do not want to keep a port open for security reasons. In these situations, a push message such as an alert or notification can be sent to the device to cause the client to initiate a session back to the management server. This technique provides a way to "wake up" the device to start a management session. Once the session is initiated, the setup and management phases occur.
For complete information on the SyncML DM specification, including common usage scenarios and example code, visit the SyncML Initiative Web site at www.syncml.org, or the Open Mobile Alliance Web site at www.openmobilealliance.org.
The SyncML Initiative predicts that the DM protocol will first be used by wireless carriers, followed by corporations. The carriers will provide services such as automatic backup of phone books, and device preferences. They will then add more advanced features such as over-the-air provisioning of new applications. Without device management capabilities, a user would have to go to a store and have the phone memory "reflashed" to install a new application. Corporations are expected to use SyncML DM for more traditional device management features such as software distribution and asset tracking. The main benefit for enterprise deployments is interoperability. SyncML DM will enable a single client to synchronize with multiple information sources. With proprietary solutions, the client can only communicate with the corresponding server software, usually at a single location. In addition, with a standard protocol, the mobile agent software can be preinstalled on devices. This will remove one of the challenges with current device management software. It is expected that, as the standard evolves, many of the current device management vendors will add SyncML DM support to their enterprise offerings.
Table 16.3 lists the companies that provide mobile device management platforms with many of the core features discussed in this chapter. Note that these companies are regarded as having the leading offerings in this field. Over time, more companies will surely develop products in this area. At the same time, consolidation of the market is expected.
Manage Anywhere Studio
Systems Management Server (SMS) 2003
Mobile Automation 2000
ZENworks for Handhelds
iMobile Systems Management
Tivoli Configuration Manager