Supporting Providers
| Note: |
|---|
|
Before using this information and the product it supports, read the information in Notices. |
(C) Copyright International Business Machines Corporation 2000, 2002. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication, or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
The following topics are described in this section:
Device Manager is device management technology from Tivoli software, offered by IBM, that helps enterprises and private networks, or providers, manage information appliances. Information appliances, hereafter called devices, are the personal digital assistants (PDAs), handheld PCs, subnotebooks, cellular phones, set-top boxes, in-vehicle information systems, or other, emerging devices for pervasive computing. Integrated with a provider's subscription manager component, Device Manager can be used to identify, configure, inventory, and distribute software to any device supported by the provider.
Device Manager is packaged with and installed by the product that includes it. Tivoli software and IBM software products that include Device Manager are developed for providers to meet their device management needs as well as those of their customers or end users.
Supporting Providers
Device Manager supports two categories of provider: enterprises, and private networks such as service providers. A provider is any organization that manages devices using Device Manager technology. An enterprise is a large organization that uses mainframe computers and PCs to conduct business or serve networked users, but increasingly supports end users who require devices for pervasive computing in their jobs. A service provider is an organization that serves networked customers. Service providers are typically ISPs, ASPs, telephone companies, and portal businesses, but more recently, retailers and other consumer-oriented businesses seeking to invent new services and open new revenue streams between themselves and connected consumers.
Devices for Pervasive Computing
Forward-looking providers recognize that modern users demand value-added services above and beyond basic Internet or intranet connectivity. No longer satisfied with connection alone, they want online customer service and integrated billing, or self care and software provisioning--a broadening spectrum of services. At the same time, the use of PDAs and other devices for pervasive computing is on the rise. They may be small, resource-limited, and not perceived as computers, but these devices are increasingly used to access that spectrum of network-based services which also include Internet-based e-commerce services.
Devices for pervasive computing give their users, both expert and novice, the ability to access and take action on information conveniently. Users can explore the Internet, send and receive e-mail, shop and bank online, and even arrange remote home networking--often through a provider.
The Challenges for Providers
As the underlying complexities that support these activities increase, so does the likelihood that people will experience frustration when setting up their devices, updating and reconfiguring software, or obtaining new services. Even experienced users may have little knowledge about how their own devices really work.
For service providers, the challenges of a diverse yet ever more demanding subscriber base, consumer demand for ever-smaller access devices, and the underlying complexities of such devices all meet at the service provider's door. To offer the most value, and often to secure brand loyalty and earn money from consumers, service providers need to help consumers efficiently manage their information and devices.
Enterprises face challenges of their own, including keeping track of the hardware and software inventories of their device users and managing uniform software distribution.
Meanwhile the popularity of devices for pervasive computing grows steadily, and providers are further challenged to manage thousands or more devices effectively.
Delivering Value to Providers
Device Manager addresses provider needs, extending the functionality of the provider's subscription management applications and database management systems to include management of many thousands of devices and their related resources, like applications, from a variety of device manufacturers.
How Device Manager Works
To manage devices, a Device Manager server comprised of a set of servlets running in an application server works as an engine for processing jobs on network-connected devices. A Device Manager database acts as the repository for device-related data. The provider uses a supplied administrator interface, the Device Manager console, to manage user devices by submitting various types of jobs to run on them. A provider's service representatives, and even device users themselves, can manage and monitor devices to a limited extent through Customer Care and Self Care applications supplied with Device Manager.
In addition, Device Manager defines a plug-in architecture for the Device Manager server that provides specialized support for different kinds of devices (a Palm PDA versus a subnotebook running Windows CE, for example) and any number of future devices.
HTTP and HTTPS communications between devices and Device Manager allows requests and responses to pass through various network elements, like firewalls.
Operating System Environments
Device Manager uses Java technology. Device Manager servers run in IBM AIX, Sun Solaris, Red Hat Linux, Microsoft Windows NT Server, or Microsoft Windows 2000 Server operating system environments. The Device Manager database server runs in the same operating system environments, using a global, relational database for data storage. IBM DB2 Universal Database and Oracle8i RDBMS are supported.
Device Manager can be installed as a single-server environment or, for larger user populations, as a multiserver environment with a network dispatcher as the front end. The latter provides scalability and high availability for a number of Device Manager servers.
Device Manager administration clients run in Microsoft Windows operating system environments. The Device Manager console used by administrators is deployed on administration clients. Device Manager Care clients also run in Microsoft Windows operating system environments. The Device Manager Care applications are started from a Web browser by service representatives or device owners from these clients.
Device owners and subscribers
In Device Manager the terms device owner and subscriber are used interchangeably. In general, the term subscriber is used in enrollment scenarios where the user of a device is subscribing to a device management service; otherwise, the term device owner (or the more generic term, device user) is used.
A device owner is person who, during device enrollment, is registered in the Device Manager database as the owner of a device. To identify the device owner, Device Manager by default uses the user ID obtained from the device agent program installed on the device. In a service provider environment, the device owner is typically an enrolled subscriber; in an enterprise environment, the device owner is typically the user responsible for an enterprise device asset.
A subscriber is a person who, during subscriber enrollment, is registered in the subscription manager component as the primary user of a device management service. In a service provider environment, the subscriber may be a person who is billed for the service; in an enterprise environment, the subscriber is the employee whose device is managed.
For more on device and subscriber enrollment, see Enrolling and Configuring a PDA and Enrolling and Configuring a Windows CE Device.
Administration of Devices
Administrators work from a Microsoft Windows client using a graphical user interface, the Device Manager console, shown in Figure 1.
|
From this console, a provider's administrators can manage the following:
More information about the Device Manager console and its uses may be found in Administrator's Guide for Device Manager.
Self Care and Customer Care for Devices
Device owners and their provider's service representatives work from a Microsoft Windows client and use a Web browser to access the Care applications to care for devices. Figure 2 shows a sample Customer Care main window (Self Care looks similar):
|
The Self Care or Customer Care application permits people to do management tasks like those listed on the left side of the Customer Care main window shown in Figure 2. Generally, the tasks displayed for Self Care are more restrictive than the tasks displayed for Customer Care, although this is a provider determination. The task list can be customized by the provider.
More information about the Self Care and Customer Care applications and their uses may be found in Device Manager Care Applications.
This information is for the following audiences:
Device Manager enables administrators to manage different kinds of manufacturer devices. Device Manager manages these devices by device class. A device class is a collection of devices that have similar characteristics and that can be managed similarly. For example, Palm OS computing PDAs such as Palm III and Palm V devices belong to the Palm device class. Device Manager provides specialized, pluggable software, called device plug-ins, for job processing and other handling of the devices in a device class. The device classes supplied with Device Manager support the following:
Palm OS is the operating system designed for Palm Computing Platform devices and similar devices. Device Manager supports all devices that use the Palm OS 3.1 (or later) operating system. Palm positions these devices as PC companions used as organizers.
Features of the Palm OS include:
Device Manager supplies a device plug-in for the supported Palm OS devices that includes Java classes for the following:
For more information about the Palm OS device plug-in, see the document Palm OS Plug-in Guide for Device Manager.
For more about Palm devices and Palm software, see the Palm Computing Web site.
A Windows CE device is a handheld PC, pocket-type device, or subnotebook for sales and service people, mobile business professionals, and other field personnel who need access to their enterprise network or the Internet. Generic Windows CE devices include Microsoft Windows CE for Handheld PC Professional Edition, Version 3.0 operating system.
Windows CE devices have many features and resources available, such as:
Because screen size and resolution varies among the Windows CE devices, the Device Manager user interface may change for different types of Windows CE devices. In addition, the CPU type and file structure can differ among the various Windows CE devices.
The provider can preconfigure a Windows CE device with the device agent program for Device Manager, or it can be downloaded by the device owner.
Device Manager supplies a device plug-in for the supported Windows CE devices that includes Java classes for the following:
For more information about the Windows CE device plug-in, see the document Windows CE Plug-in Guide for Device Manager.
Businesses have an increased number of wireless devices for day-to-day operations. Providing a management solution for multiple types of wireless devices is critical. SyncML-DM-capable devices are devices that implement a subset of the SyncML DM 1.1 specifications. Device Manager and the base SyncML DM plug-in support all devices that implement this specification.
The benefits provided by the base SyncML DM plug-in are:
Device Manager provides a base SyncML DM management server for SyncML DM enabled devices. For testing purposes only, Device Manager includes a limited function base SyncML DM client simulator. The base SyncML DM client simulator is not a supported part of Device Manager. The simulator must be used as is, and is available in English only.
Device Manager supplies a device plug-in for the supported base SyncML DM devices that includes Java classes for the following:
For more information about the base SyncML DM plug-in, see the document Base SyncML DM Plug-in Guide for Device Manager.
The job types that follow are supplied by Device Manager. A job type is a category of job whose members, or jobs, perform a specialized task. Job types are affiliated with device classes, collections of devices that have similar characteristics and that can be managed similarly. Every job type is not necessarily applicable to every device class. But even if the job type (for example, device configuration) does not change from one device class to another, the implementation (the Java job class) does. The supplied job types are:
Administrators using the Device Manager console can submit jobs to the following:
An owner group is a collection of device owner IDs, defined and saved by the provider in the subscription manager component. For example, a service provider might define an owner group to identify all the device owners who subscribe to a particular deal or offering available from the service provider. Device Manager retrieves the list of valid owner groups from the subscription manager and displays them in the Device Manager console as possible targets of submitted jobs.
The following are typical device processing scenarios in a provider environment that has integrated Device Manager with a subscription manager component:
With such a large mix of manufacturer devices, providers, retailers, and device distributors, many user enrollment scenarios are conceivable. The following scenarios are illustrative but not the only ones possible. Take configuration as an example. Many small devices like PDAs and subnotebooks have no direct way to connect to a provider Web site to retrieve their initial configuration programs or data. They require a PC and device accessories to do so. Other devices, such as certain Windows CE devices, can connect directly.
When a person obtains a new device, such as a PDA, it may or may not come already preconfigured for a particular enterprise or service provider. For example, some service providers have a business relationship with device retailers. A service provider may therefore preconfigure the device, in order to offer the consumer Internet access solely by way of a portal that displays the retailer's advertising. By the same token, an enterprise provider can preconfigure the devices it supplies to employees with its own server URL. A server URL is a Web address stored on a device and used by the device agent program to direct the device to a Device Manager server or network dispatcher on the provider's network for processing. If the device does not come preconfigured, configuration may be one of the first tasks performed on it after an enrolled user connects for the first time and registers the device with the provider.
The first scenario assumes a service provider environment where the PDA is not preconfigured, and must use a PC and device accessories to transfer programs and data from the service provider to the device. The next scenario assumes that a Windows CE device is preconfigured to connect directly to an enterprise or service provider enrollment application on a Web site. Both scenarios assume that the provider network is large enough to justify using a network dispatcher for load balancing among many Device Manager servers.
A consumer buys an unconfigured Palm PDA from a retailer. The consumer contacts a service provider's customer service representative (CSR) by phone or on the Web. The CSR enrolls the consumer using the Customer Care application provided by the subscription manager component, adding a subscriber record in the subscription manager. The CSR also gives the subscriber a user ID, password, and a server URL.
To enable the new subscriber's device to connect directly to the service provider, the CSR supplies a device agent program. It contains the initial communications and configuration data for the device. If the subscriber enrolled by phone, the CSR mails the subscriber a CD or diskette that contains the device agent program and data to install on a PC. If the subscriber enrolled on the Web, the CSR directs the subscriber to a location where the device agent program and data can be downloaded to a PC. The subscriber then copies the device agent program to the device. Although the actual copying method can vary with the device, a subscriber with a Palm device, for example, can use a hardware accessory called a cradle, in conjunction with a synchronization program, to copy the device agent program and data from the PC to the Palm device.
As soon as the CSR has enrolled the subscriber and the device agent program is installed, the subscriber can enroll the device itself. The first time the device connects to a Device Manager server in the service provider network, the Device Manager server will redirect the device to an enrollment server for processing. To begin this process, the subscriber connects to the Device Manager server by selecting and running the device agent program on the device. The subscriber enters the required user ID, password, and server URL. At this point, the subscriber's task is done.
The device agent program initiates a device dial-in by cradle or modem to the service provider network. In a large network with many Device Manager servers, a network dispatcher directs the device to the most available server. Device Manager checks its relational database for a device record indicating the device is enrolled. It is not enrolled, so Device Manager retrieves the enrollment URL from the database. An enrollment URL is a Web address used to direct an enrolling device to an enrollment server on the provider's network for device registration. Device Manager redirects the device to the enrollment server, which enrolls new devices. This server adds a device record in the Device Manager database and associates the new device with its owner, the previously enrolled subscriber.
The enrollment server then returns the device to the Device Manager server, and, if there is a job to process, Device Manager redirects the device back to the Device Manager server's own server URL. This prevents the device from returning through the network dispatcher and being rerouted to a different Device Manager server, should multiple HTTP connections be required to complete the job. Any initial inventory collection, device configuration, or software distribution job is then processed for the device. When the jobs are finished, the device agent program automatically disconnects the device from the Device Manager server.
This scenario applies to either of the following:
The device includes a device agent program and is preconfigured with a dial-up number for the provider network, a user ID and password for enrolling, some connection preferences (such as using a proxy server), and the like. The device is also configured with a server URL in its Web browser for connecting to Device Manager through the network dispatcher.
The device user connects the device to a wall port and presses the Internet button to dial in to the provider network. With the dial-in connection established, the user presses a button or selects an icon to start the Web browser on the device. The preconfigured server URL routes the device to a network dispatcher, which redirects the device to the most available Device Manager server. Device Manager checks its relational database for a device record indicating the device is enrolled. It is not enrolled, so Device Manager retrieves the enrollment URL from the database and redirects the device to the provider's self-enrollment application on the Web. The device user enters the required subscriber information (for example: name, address, credit card type and number, preferred user ID for service provider subscribers, and user ID for enterprise subscribers), and submits the form for processing. The enrollment application validates the supplied information and adds a subscriber record in the subscription manager.
With the device user now enrolled as a new subscriber, the subscription manager component can enroll the actual device with no further user actions required. The subscription manager directs the device to the its enrollment server, which enrolls new devices. This server adds a device record in the Device Manager database and associates the new device with the new subscriber.
The enrollment server then returns the device to the Device Manager server, and, if there is a job to process, Device Manager redirects the device back to the Device Manager server's own server URL. This prevents the device from returning through the network dispatcher and being rerouted to a different Device Manager server, should multiple HTTP connections be required to complete the job. Any first connection job, such as inventory collection or configuring a user ID, password, and phone number for a direct Internet connection (as opposed to the provider's enrollment application connection) is processed for the device.
As with enrollment, a variety of scenarios for processing jobs are possible. Some reasons are:
The following scenario assumes a Palm device is already connected to the provider network when the device user decides to check for jobs waiting to run on the device. A waiting software distribution job is found.
A provider administrator uses the Device Manager console, a graphical user interface that runs on a Microsoft Windows client, to submit a job for one or more devices. Some time later, a connected device user wants to look for and run any waiting jobs. To do so, the user must specifically select and run the device agent program on the device. This must be done even though the user is already connected to the service provider network by modem. In the case of a Palm device, for example, the dialed-in user specifically selects the device agent program and requests a connection. The device agent program detects that the user is already connected, so without having to disconnect and reconnect, the agent contacts the provider's Device Manager server directly.
The device agent program queries Device Manager for work. Device Manager verifies that the device is enrolled with the provider. Device Manager checks its relational database for any jobs submitted for the enrolled device and finds, for example, a software distribution job.
The task of distributing new software is accomplished by a job created especially to handle software distribution for a particular device class. The job processing software is packaged as part of a device plug-in on the Device Manager server. In this case, the Palm OS plug-in provides all the specific handling for the class of devices running Palm OS R3.1 (or later) operating systems. For the software distribution job, this handling involves retrieving from the Device Manager database a URL that points to a Web server where the new software can be obtained, and then distributing the software to the device with the help of the device agent program. After this is done, the device agent program signals the Palm OS plug-in on the Device Manager server that the job has completed successfully.
Device Manager then updates the job information in the database to indicate the job has been run for this particular device. If software was distributed to the device, the device information in the database is also updated to reflect the new software installed on the device. When the work is finished, the device modem connection remains open because the original connection was initiated by the subscriber, not by the device agent program.
More examples of device processing can be found among the getting started scenarios in the following documents:
The Device Manager environment includes the following:
|
The Device Manager console is a graphical user interface (GUI) for administering device management operations from a Microsoft Windows client. Administrators use this interface to do tasks like register and view devices or device software, modify device or software properties, create and use queries, submit jobs for devices, and check job status. The console invokes an application programming interface (API) to access information in the Device Manager database and perform requested operations.
See Installing and Starting the Device Manager Console for information on setting up and starting the console, and see Administrator's Guide for Device Manager for more about the tasks you can perform with the console.
Device Manager supplies two applications for providing care for devices:
Device Manager Customer Care is an application that a customer service representative (CSR) uses to manage provider-supported devices, and jobs and software for these devices. The CSR administers device care using a graphical user interface (GUI) from a Web browser on a Microsoft Windows client. The CSR selects a device from a list and then selects a task from a list (see the Customer Care main window in Figure 2). All devices owned by the subscriber or user appear in the device list. The device owner list is determined by the subscription manager component.
Customer Care allows a customer service representative to perform a subset of the tasks that an administrator performs with the Device Manager console. Using Customer Care, the CSR performs tasks for one device at a time.
Customer Care can be customized. Tasks can be assigned to the Customer Care task list in accordance with the responsibilities the provider wants to give its customer service representatives. Device management tasks are displayed in the task list by including XML tags for that task in the Customer Care customization file. Other Customer Care features, such as colors, fonts, and images, can also be customized by including XML tags in the Customer Care customization file.
See Customizing the Care Applications for customization details, and see Starting the Device Manager Care Applications for information on starting Customer Care.
Device Manager Self Care is analogous to Customer Care but is used by device owners to manage their own devices. The device owner performs device care using a graphical user interface (GUI) from a Web browser on a Microsoft Windows client. The same set of customizable tasks are available for Self Care as for Customer Care. Generally, the tasks displayed for Self Care are a subset of the tasks displayed for Customer Care. As with Customer Care, XML tags in the Self Care customization file determine whether tasks appear in the Self Care task list. Likewise, colors, fonts, images, and other features can be customized for Self Care by including XML tags in the Self Care customization file.
See Customizing the Care Applications for customization details, and see Starting the Device Manager Care Applications for information on starting Self Care.
A Device Manager database server is a computer that meets the database server requirements and includes a Device Manager database.
The Device Manager database is the repository for all device management information and is implemented in a relational database and accessed by an application programming interface (API). The Device Manager database in an installable component that includes:
When using Device Manager in a provider environment, a subscription manager component is required that implements an enrollment server to register new devices in the Device Manager relational database upon enrollment.
Device Manager configures each provider-supported device class with the enrollment URL. This URL is supplied by the provider either during Device Manager installation (see Table 7 in Installation Options) or afterward, using the Device Manager console. An enrollment URL is a Web address stored in the Device Manager database and used by the device plug-in to direct an unenrolled device to the enrollment server for device registration. For example, the Palm and Wince device classes supplied with Device Manager use this default enrollment URL:
http://hostname/dmserver/DeviceEnrollmentServlet
where hostname is the short or fully qualified host name or IP address of the enrollment server.
Note: Port 80 is the default port for the IBM HTTP Web Server used by Device Manager. Before installation of a Device Manager server, the default port for the Web server can be changed. If the port number was changed, then you will have to include the new port number in the hostname portion of the URL of the above Web page. For example, you will have to type a URL like:
http://dmserver.raleigh.tivoli.com:8080/dmserver/DeviceEnrollmentServlet
where :8080 references the changed port number.
The enrollment server also registers service subscribers or enterprise device owners with the subscription manager during the provider's user enrollment process.
When registering devices, the enrollment server must ensure that each registered device has one and only one owner associated with it. The enrollment server must know how to interact with supported devices to obtain the necessary enrollment information.
A Device Manager server is a computer that meets the server requirements and includes the device management server servlet (DMS servlet) and device plug-ins. The main role of the Device Manager server is processing jobs for devices.
A new job gets submitted for processing by one of the following:
At the time the job is submitted, the administrator, CSR, device owner specifies the type of job, any job-specific parameters, the devices the job should run on, the activation and expiration time for the job, and whether or how often the job should be rerun.
The DMS servlet and device plug-ins then work together to process a job.
When a device connects to the provider network, it is routed, either directly or by a network dispatcher, to a Device Manager server for job processing. The DMS servlet ensures the device is enrolled with the provider:
The DMS servlet searches the database for any submitted jobs pertaining to the device and builds a prioritized job list. The DMS servlet processes the jobs using a device plug-in to interact with the device, often through several iterations of requests and responses. The DMS servlet also determines what jobs are scheduled for a device and obtains information about any next-scheduled or currently running job.
A device plug-in is software that resides on the Device Manager server and provides the logic that handles device identification, communications, job processing, and high-level management tasks for a particular class of managed devices. A device class is made up of specific kinds of manufacturer devices with similar characteristics and whose operations can be managed similarly. For example, one device class provided with Device Manager includes Palm PDAs that run Palm OS 3.1 (or later); another device class might include devices that use the Windows CE operating system and a specific CPU. Device plug-ins are typically developed by and provided with Device Manager, but they can also originate with a device manufacturer or integrator and be installed later on a Device Manager server.
A device plug-in includes the following:
The following topics are described in this section:
Device Manager is a technology from Tivoli software, complete with its
own online library that is installed on the Device Manager server during
Device Manager installation.
The following information is installed with the Device Manager server:
Table 1. Device Manager library
| Document Name | File Name |
|---|---|
| Introduction to Device Manager | dmsimst.htm |
| Administrator's Guide | dmsamst.htm |
| Customizing the Care Applications | dmscustom_mst.htm |
| Palm OS Plug-in Guide | dmspi_palmmst.htm |
| Base SyncML DM Plug-in Guide | dmspi_basesyncmlmst.htm |
| Windows CE Plug-in Guide | dmspi_wince_wea_mst.htm |
After Device Manager server installation, the library files in Table 1 can be found in the following Device Manager server locations:
Web_server_dir\document_root\dms\docs\language_id
where Web_server_dir is the directory where your Web server is located (such as c:\Program Files\IBM HTTP Server on Microsoft Windows NT servers), document_root is the subdirectory where your Web server files are located (such as \htdocs on Microsoft Windows NT servers), and language_id is the identifier for the language you want to display the information in (for example, en for the English language).
Web_server_dir/document_root/dms/docs/language_id
where Web_server_dir is the directory where your Web server is located (such as /usr/HTTPServer on IBM AIX servers and /opt/IBMHTTPD on Sun Solaris and Red Hat Linux servers), document_root is the subdirectory where your Web server files are located (such as /htdocs/en_US), and language_id is the identifier for the language you want to display the information in (for example, en for the English language).
A table of languages
and language IDs follows:
Table 2. Languages and language IDs
| Language | Language ID |
|---|---|
| Brazilian Portuguese | pt_BR |
| English | en |
| French | fr |
| German | de |
| Italian | it |
| Japanese | ja |
| Korean | ko |
| Portuguese | pt |
| Simplified Chinese | zh |
| Spanish | es |
| Traditional Chinese (Mandarin) | zh_TW |
http://server_name/dms/docs/language_id/index.htm
where server_name is a computer where the Device Manager server is installed, and language_id is the identifier for the language you want to display the information in (for example, en for the English language).
To access the Device Manager library from the computer running the Device Manager server, open index.htm in a Web browser on the Device Manager server and click the link to the document you want to read.
To access the Device Manager library from the
administration client running the
Device Manager console, start the Device Manager console and click
Help 
Device Manager Library
from the main
window. Then click the link to the document you want to read.
The following topics are described in this section:
If a product that includes Device Manager also includes an authentication server component, users of that product can take advantage of the services provided by the authentication server, such as single sign-on. Single sign-on can give users a single point of entry into the subscription manager server, the network dispatcher, and the Device Manager server. Users who choose to take advantage of this single sign-on capability need to do some extra configuration steps to make sure that redirection from Device Manager to an enrollment server is done correctly. For more details, see the user authentication information provided with the product that includes Device Manager.
Device Manager uses several network communications protocols:
Device plug-ins supplied with Device Manager typically use HTTP or HTTPS network communications protocol.
When planning how to set up your network and servers for use with Device Manager, read the following sections to understand more about the software and hardware Device Manager requires or recommends and the tasks you need to do.
Use is optional but recommended when supporting a large number of devices
Provides scalability and load balancing
when managing many devices
Provides a front end for multiple Device Manager servers
The provider's network must be configured for
a network dispatcher
Each physical device must be configured with the server URL
for the network dispatcher
Providers deploying multiple Device Manager servers in their network can optionally use a network dispatcher as their front end. A network dispatcher provides scalability, load-balancing, and fault-tolerance when using multiple servers to manage large numbers of devices.
The network dispatcher controls incoming data traffic by sending requests to the most-suitable Device Manager server available. In so doing, it balances the load among all the Device Manager servers. Additional Device Manager servers can be added without interrupting service.
When setting up the network dispatcher in your network, make sure of the following:
Before a device can use the dispatching capability, the device must be configured with the server URL of the network dispatcher cluster. In the dispatcher, a cluster is a group of TCP or UDP servers that are used for the same purpose and are identified by a single host name or IP address, the cluster address. A server URL is a Web address stored on a device and used by the device agent program to direct the device to a Device Management server, possibly through a network dispatcher (by using the host name of the dispatcher's appropriate cluster address) for job processing. Each device supported by the provider must be configured with the provider's cluster server URL.
The cluster server URL is typically supplied by the service provider during subscriber enrollment, as with PDAs, or is preconfigured on the device by the service provider or enterprise. Devices not using a network dispatcher must be configured with the server URL of the specific Device Manager server intended to process the jobs for these devices.
If you are using a network dispatcher in your Device Manager environment, the cluster environment parameter must be set to true during Device Manager installation (see Table 7 in Installation Options).
When the device connects to the network dispatcher, the dispatcher forwards the HTTP request from the device to the most available Device Manager server. If jobs are scheduled for the device, the Device Manager server redirects the device back to its own server URL. This prevents the device from returning through the network dispatcher and being rerouted to a different Device Manager server whenever multiple HTTP connections are required to complete the job. When the device instead connects back to the Device Manager server's server URL, the DMS servlet running on the server begins processing scheduled jobs for the device. If the job processing requires multiple HTTP requests and responses with the device in order to complete, the device is sure to return to the same Device Manager server every time.
Device Manager was tested with IBM SecureWay Network Dispatcher 2.1.
A database server is required by Device Manager
Supported database products are IBM DB2 Universal Database and Oracle8i RDBMS
Database server needs at least 512 MB RAM
Install Oracle or DB2 before the application server
or Device Manager
Install database schema for Device Manager before installing Device Manager
A database client and JDBC driver are required on the Device Manager server
To access, update, and store device owner, device inventory, device configuration, software package, and job-related information, Device Manager requires a database server with one of the following database software products installed:
It is recommended that the relational database server have a minimum of 512 MB memory (RAM), plus hard disk space in proportion to the number of supported devices (see Table 3 and the related database size formula), for storing Device Manager data.
The relational database is Web-enabled with Java support. The relational database can be on the same or on a different server than the Device Manager server. If Device Manager is integrated with an existing subscription manager, both can share a common database by using different tables for the device- and subscriber-related information.
The Oracle or DB2 database software must be installed before the application server or Device Manager (see Installing the Device Manager Database). Following installation of the database software and application server, database tables for Device Manager can be created by installing the Device Manager database and schema according to the Device Manager database installation instructions provided with the product that includes Device Manager.
The recommended tablespace storage allocation for devices is as listed in Table 3.
Table 3. Tablespace storage allocation for devices
| Planned number of devices | Database size in bytes |
| 100 | 971,715 |
| 1,000 | 9,341,715 |
| 10,000 | 93,041,715 |
| 50,000 | 465,041,715 |
| 100,000 | 930,041,715 |
| 500,000 | 4,650,041,715 |
| 1,000,000 | 9,300,041,715 |
You can use the following formula to obtain the required database size, based on the planned number of devices, n:
Database size in bytes = 41,715 + (9,300 * n)
See Table 7 in Installation Options for the Oracle or DB2 database parameters that need to be supplied during Device Manager installation.
If you plan to install Device Manager on a different computer than the Device Manager database, you first need to install a database client and JDBC driver on the intended Device Manager server. Client computers that will run the Device Manager console also require a database client and JDBC driver. Later, when installing Device Manager, you will need to provide the fully qualified path name for the installed JDBC driver (see the instructions for installing the database client).
Before installing IBM DB2 on a Red Hat Linux system, you must install the pdksh-5.2.14-2.i386.rpm package from the Red Hat Linux product CD in the /RedHat/RPMS/ directory:
bash# rpm -ivh /mnt/cdrom/RedHat/RPMS/pdksh-5.2.14-2.i386.rpm
Oracle8i requires a valid DISPLAY environment, even if it is not used. Therefore make sure that the DISPLAY variable set in the .profile file in the home directory of the oracle8 user ID is set to an X session display which the Device Manager database server is currently allowed to access. For example:
DISPLAY=hostname.domain:0.0 ; export DISPLAY
where hostname.domain is the host name and domain name of the Device Manager database server. The Oracle database creation script will fail if the DISPLAY variable setting is not valid.
To optimize Device Manager performance, consider implementing the changes described in the following sections.
If you are using DB2 Universal Database as the relational database, increase the Maximum Locks DB2 configuration parameter from 10 (which is the default value) to 20.
To improve Device Manager performance, set the database connections in Transaction.properties higher.
Device Manager includes a Transaction.properties file on every Device Manager server at the following location:
app_server_dir/installedApps/dmserver_hostname_DMS_WebApp.ear /dmserver.war/WEB-INF/classes/Transaction.properties
where app_server_dir is the directory where your application server is located, such as /usr/WebSphere/AppServer on AIX servers, /opt/WebSphere/AppServer on Solaris and Linux servers, or c:\WebSphere\AppServer on Windows servers and dmserver_hostname is the short host name of the Device Manager server, such as myhost.
This file is used by the Device Manager server.
It is more efficient to open a larger number of database connections at startup rather than later, during run time. Later, opening database connections slows server capabilities to process requests, which affects device clients, and therefore subscribers or users.
If you plan 70 to 100 concurrent device connections, use that range as a guideline to set the MinDBConnections. MaxDBConnections should be larger, but not more that the system can realistically handle. The recommended maximum is 256 or 512.
Device Manager includes a ConsoleTransaction.properties file on every Device Manager server at the following location:
app_server_dir/installedApps/dmserver_hostname_DMS_WebApp.ear /dmserver.war/WEB-INF/classes/ConsoleTransaction.properties
where app_server_dir is the home directory of your application server, such as /usr/WebSphere/AppServer on AIX servers, /opt/WebSphere/AppServer on Solaris and Linux servers, or c:\WebSphere\AppServer on Windows servers; and dmserver_hostname is the short host name of the Device Manager server, such as myhost.
This file is used by the Device Manager console.
By default, MinDBConnections is set to 1, and MaxDBConnections is set to 200.
Required by Device Manager
Must be able to register supported devices
in the Device Manager database
Must have an enrollment URL for registering devices
Must ensure that
each enrolled device has one device owner
When using Device Manager in a provider environment, a subscription manager component is required that implements an enrollment server to register new devices in the Device Manager database during the provider's enrollment process.
Device Manager must be able to direct unenrolled devices to the enrollment server for device registration. Device Manager configures each provider-supported device class with the enrollment URL. This URL is supplied by the provider either during Device Manager installation (see Table 7 in Installation Options) or afterward, using the Device Manager console. An enrollment URL is a Web address stored in the Device Manager database and used by the device plug-in to direct the unenrolled devices to the enrollment server on the provider network. Device Manager configures each device class supported by the provider with the enrollment URL specified during installation.
In addition, the enrollment server must know how to interact with supported devices to obtain the necessary enrollment information. Also, the enrollment server must ensure that each registered device has one and only one owner associated with it.
Required by, and provided with, IBM WebSphere Application Server
IBM WebSphere Application Server requires and provides IBM Java 2 Software Developer's Kit (SDK) 1.3.0 for all supported Device Manager server operating systems.
Provided and installed with WebSphere Application server
Required on all Device Manager servers
Must be installed on the computer before
Device Manager.
When configuring,
specify the port to be used
for the Device Manager server
Improve Web server performance on AIX systems
Device Manager uses a Web server to redirect servlet calls and deliver Web pages, images, and documents over the network for viewing from remote Web browsers. The application server and Device Manager both require a supported Web server such as IBM HTTP Server 1.3.19.3. IBM HTTP Server 1.3.19.3 is installed by IBM WebSphere Application Server, which is a requirement of Device Manager. The Web server must be installed on the computer before Device Manager.
The Web server must be configured for the port to be used for the Device Manager server. Port 80, or port 443 if you are enabling optional SSL support, is required. The port numbers used by the Web server and IBM WebSphere Application Server must match one another. See Table 7 in Installation Options for all the Web server parameters that need to be supplied during Device Manager installation.
To improve IBM HTTP Server performance, you can adjust the MinSpareServers, MaxSpareServers, MaxClients, and StartServers variables on AIX in the /usr/HTTPServer/conf/httpd.conf file or on Solaris in the /opt/IBMHTTPD/conf/httpd.conf file. MinSpareServers and MaxSpareServers determine how many extra inactive processes should be kept on hand to handle new, incoming requests. MaxClients indicates the number of requests the Web server can handle at any given time before connections are denied, and is limited by how much memory the server has. StartServers is the number of HTTP daemon processes that will be started when the Web server is initialized.
MinSpareServers, MaxSpareServers, and MaxClients should be equal and set large enough to accommodate the number of device clients you expect the Web server to support. The reason is that performance is more efficient if you start a larger number of processes at startup rather than later, during run time. Later, HTTP daemon startups slow Web server capabilities to process requests, which affects device clients and therefore device users.
Because MaxClients is limited by how much memory the server has, do not set the MinSpareServers, MaxSpareServers, and MaxClients variables higher than the total megabytes of memory available after everything else is started. An HTTP daemon process uses about 788 KB memory.
Required by Device Manager
Install it on all Device Manager servers
Requires Web server and software developer kit for Java technology
When installing,
be sure
to select
Typical Installation
Uses port 80 or the same port as the Device Manager server
Improve performance by resetting heap size and maximum connections
Update the mime.types file
for clients that use Netscape browsers
Each Device Manager server uses IBM WebSphere Application Server Advanced Edition (Full Version) 4.0.4 to manage servlets. IBM WebSphere Application Server, in turn, requires a Web server, plus the IBM Java 2 Software Developer's Kit, both of which are provided by, and installed with, IBM WebSphere Application Server.
When installing using the IBM WebSphere Application Server Setup program, be sure to select Typical Installation on the setup window. Do not select Developer's Kit (Full Installation). Selecting Typical Installation will later allow you to configure IBM HTTP Server with an IBM WebSphere plug-in. Also, be sure to install IBM WebSphere Application Server in the default directory:
IBM WebSphere Application Server uses the same the port number used by the Device Manager server. This is the port number configured for Device Manager on your Web server; either port 80, or port 443 for SSL, is recommended. These port numbers must match one another.
When starting the Device Manager server for the first time after its installation, you must first restart IBM HTTP Web server, and then restart WebSphere Application Server to enable the Device Manager environment settings. When you restart WebSphere Application Server, the Device Manager server will start automatically because it was left in a running state when it was installed. See Starting Device Manager for additional details.
You can improve the application server's performance by setting the Java heap size for DMS_AppServer to 256 MB or greater from the WebSphere Advanced Administrative Console. By default these settings are low. If the server has 512 MB or more of memory, increasing the heap size would improve performance when garbage collection and heap reallocation occurs during run time.
To reset the heap size from the WebSphere Advanced Administrative Console, do the following:
256
256
Also, if the application server is allowed too many concurrent connections, the concurrency affects performance. Nevertheless, some concurrency is needed to keep device clients from constantly being rejected. A MaxConnections setting of 100 appears to provide the best performance.
To increase the number of concurrent database connections from the WebSphere Advanced Administrative Console, do the following:
To enable Netscape browsers to correctly handle downloading Device Manager JAR files to administration clients installing the Device Manager console, update the mime.types file on the application server. From the WebSphere Advanced Administrative Console, do the following:
| MIME Type | Extension |
| application/java-archive | jar |
Required by Device Manager
Install it on any computers that access
the product documentation or Care apps
Requires Netscape or Microsoft Internet Explorer with JavaScript support
Device Manager requires a Web browser on administration clients (to install the console, to display the Device Manager console help and Device Manager library information), on care clients (to display the Device Manager Customer Care or Self Care applications and related help information), and on any computer used to display the Device Manager library. The following Web browsers are supported:
When using a Netscape 6 (or later) browser to view the table of contents in a Device Manager document, contents subtopics are not collapsible and therefore always remain displayed.
For optimal presentation of the Device Manager help and library information,
a Web browser must be at the version level specified above and
support JavaScript. If you are using a Netscape browser, make sure SmartUpdate is
enabled (Edit
Preferences
Advanced
SmartUpdate). Earlier Web browser
levels will display the
library information,
although without features like
the expandable table of contents. At a minimum, however, the Web browser
must support HTML 2.
The following requirements are described in this section:
Table 4 shows the requirements for Device Manager servers. The required products or conditions must already exist on the computer before you install Device Manager.
Table 4. Device Manager server requirements
| A processor with one of these operating systems: |
|
| One of these Web browsers (optional): |
Install a Web browser if you need to view Device Manager
documents from the server:
|
| Web server |
IBM HTTP Server 1.3.19.3.
|
| Application Server | IBM WebSphere Application Server, Advanced Edition (Full Version) 4.0.4 |
| Software developer kit for Java technology | IBM Java 2 Software Developer's Kit (SDK) 1.3.0 installed by WebSphere Application Server |
| Database client software |
One of the following database clients is required if the relational database is
on a different server:
|
| Hard disk |
|
| Memory | For Windows, Solaris, and AIX systems: 512 MB, 1 GB recommended. For Linux systems, 1 GB recommended. |
| Processor | For Intel-compatible processors running Windows operating systems, 600 MHz. For Intel-compatible processors running Linux, 1130 MHz. For IBM RS/6000 and SPARC processors, 450 MHz. |
| Media drive | CD-ROM. |
| Access | You must be the root user or have administrative privileges to perform installation. |
Table 5 shows the requirements for the database server used by Device Manager.
Tip: If you choose, you can use the same computer as a database server and Device Manager server (see Table 4). In this case, you will not need to install a database client on the computer because the database server and Device Manager server will be local to one another.
The required products or conditions must already exist on the computer before you install Device Manager.
Table 5. Database server requirements
| A processor with one of these operating systems: |
|
| One of the following database software products: |
|
| Hard disk |
|
| Memory | For Windows, Solaris, and AIX systems: 512 MB, 1 GB recommended. For Linux systems, 1 GB recommended. |
| Processor | For Intel-compatible processors running Windows operating systems, 600 MHz. For Intel-compatible processors running Linux, 1130 MHz. For IBM RS/6000 and SPARC processors, 450 MHz. |
| Media drive | CD-ROM. |
| Access | You must be the root user or have administrative privileges to perform installation. |
Table 6 shows the requirements for Device Manager administration clients. Administration clients are used to run the Device Manager console. The required products or conditions must already exist on a computer before using it to install the Device Manager console.
After installing the console, use the client computer to set up and administer devices.
Table 6. Device Manager administration client requirements
| One of these operating systems: |
|
| One of these Web browsers: |
|
| Database client software |
For Device Manager console clients only (not required for Customer Care or Self Care clients), one of the following:
|
| Hard disk |
|
| Processor | 133 MHz, minimum, for Intel-compatible processors; 500 MHz recommended. |
| Memory | 256 MB. |
| Screen resolution | 800x600 pixels and 256 colors, minimum; 1024x768 pixels recommended. |
Care clients are used to run the Device Manager Customer Care and Self Care applications. The requirements for Device Manager Care clients are the same as the requirements shown in Table 6, except the Care clients do not require the database client software. The required products or conditions must already exist on a computer before using it to start the Care applications.
The following topics are described in this section:
The following topics are described in this section:
Before installing the required products, remember the following:
The following required products (prereqs) must be installed before installing Device Manager. Do these steps in the order presented.
A network dispatcher is optional.
Install the required database server software, in the order indicated, on the computer where the Device Manager relational database and database schema will be installed.
Install the required server software, in the order indicated, on all computers where the Device Manager server will be installed.
Install the required client software, in the order indicated, on all computers where you want to run the Device Manager console.
The following topics are described in this section:
Before installing Device Manager, remember to do the following:
Important note: For DB2 databases, you must create the database user ID (for example, dmsadmin) before installing Device Manager. Device Manager does not create the database user ID during installation, nor assign database access to the user ID if it does not already exist.
During Device Manager installation, you will need to choose from a number of installation options. When preparing for installation, use Table 7 to help familiarize yourself with all the installation options, their meaning, and their default values:
Table 7. Device Manager installation options
| Option | Description | Default |
| Drive |
The target drive for program files on Windows operating systems.
|
c |
| Server destination directory |
The fully qualified path of the destination directory where you want the Device Manager server files to reside after Device Manager is installed.
|
/opt/TivDMS on a Solaris or Linux system
/usr/TivDMS on an AIX system c:\TivDMS on a Windows system Important note for IBM WebSphere Everyplace Access users: If you are using Device Manager as included with IBM WebSphere Everyplace Access, the default paths are: /usr/WebSphere/DMS on an AIX system c:\WebSphere\DMS on a Windows system
|
| Web server home directory |
The fully qualified path of the home directory for Web server files.
|
/opt/IBMHTTPD on a Solaris or Linux system
/usr/IBMHTTPD on an AIX system c:\IBM HTTP Server on a Windows system
|
|
Web server protocol
|
The communications protocol for the Web server.
|
http |
| Web server port |
The port number for Device Manager communications with the Web server and application server. Specify port 80, or port 443 for SSL.
|
80 |
| Database destination directory |
The fully qualified path of the temporary directory where you want the Web Gateway database files copied from the product CD. For example, /temp/TWG on a Solaris, AIX, or Linux system, or drive:\temp\TWG on a Windows system.
|
[No default]
|
| Database engine |
The relational database product used by the Device Manager database server.
Specify oracle or db2.
|
db2
|
| Database host name |
The fully qualified local or remote host name of the Device Manager DB2 relational database server.
|
[No default]
|
| Database name |
The unique name (database ID) of the Device Manager database, which is used to store device information.
|
dms |
| Database alias |
The alias for the DB2 database name.
|
dms |
| Database driver location |
The fully qualified path name for the JDBC driver used by Device Manager. For DB2, this is the path name for db2java.zip; for Oracle this is the path name for classes12_01.zip.
|
/home/db2inst1/sqllib/java12/db2java.zip
on a Solaris, Linux, or AIX system
c:\Program Files\SQLLIB\java12\db2java.zip on a Windows system
|
| Database port |
The database connection port number (for example, 1521 for Oracle, 6879 for DB2).
|
6879 |
| Database user ID |
The name of the user ID that owns the database (for example, stage_user for Oracle, dmsadmin for DB2).
Important DB2 note: You must create the database user ID (for example, dmsadmin) before installing Device Manager. Device Manager does not create the database user ID, nor assign database access to the user ID if it does not already exist.
|
dmsadmin |
| Database password |
The Oracle or DB2 database password (the Oracle default password is oracle, the DB2 default password is ibmdb2).
|
ibmdb2 |
| Palm enrollment URL |
The enrollment URL for Palm OS devices. Device Manager uses this URL to direct unenrolled Palm OS devices to the enrollment server on the provider network.
Specify
http://hostname/path,
where hostname is the short or fully qualified host name or IP address of the enrollment server, and path is the path and file name of the enrollment servlet.
Note: If the default port number (80) for the IBM HTTP Web Server used by Device Manager was changed, then you will have to include the new port number in the hostname portion of the URL of the above Web page. For example, you will have to type a URL like: http://dmserver.raleigh.tivoli.com:8080 /dmserver/DeviceEnrollmentServlet where :8080 references the changed port number.
|
http://hostname/dmserver /DeviceEnrollmentServlet
|
| Windows CE enrollment URL |
The enrollment URL for Windows CE devices. Device Manager uses this URL to direct unenrolled Windows CE devices to the enrollment server on the provider network.
Specify
http://hostname/path,
where hostname is the short or fully qualified host name or IP address of the enrollment server, and path is the path and file name of the enrollment servlet.
Note: If the default port number (80) for the IBM HTTP Web Server used by Device Manager was changed, then you will have to include the new port number in the hostname portion of the URL of the above Web page. For example, you will have to type a URL like: http://dmserver.raleigh.tivoli.com:8080 /dmserver/DeviceEnrollmentServlet where :8080 references the changed port number.
|
http://hostname/dmserver /DeviceEnrollmentServlet
|
| SyncML DM enrollment URL |
The enrollment URL for SyncML DM devices. Device Manager uses this URL to direct unenrolled SyncML DM devices to the enrollment server on the provider network.
Specify
http://hostname/path,
where hostname is the short or fully qualified host name or IP address of the enrollment server, and path is the path and file name of the enrollment servlet.
Note: If the default port number (80) for the IBM HTTP Web Server used by Device Manager was changed, then you will have to include the new port number in the hostname portion of the URL of the above Web page. For example, you will have to type a URL like: http://dmserver.raleigh.tivoli.com:8080 /dmserver/DeviceEnrollmentServlet where :8080 references the changed port number.
|
http://hostname/dmserver /DeviceEnrollmentServlet
|
| Cluster environment |
Indicates whether to enable a cluster environment that uses a network dispatcher.
Specify true to enable or false to disable a cluster environment.
|
false |
Install the Device Manager database by following the installation instructions provided with the product that includes Device Manager.
Installation notes:
Install the Device Manager server by following the installation instructions provided with the product that includes Device Manager.
Installation notes:
Basic steps for installing the Device Manager server:
To test your database connection, enter one of the following commands from the Device Manager server computer.
connect to database_name user database_user_ID using database_password
sqlplus database_user_ID/database_password@database_name
If the database connection fails, you may have supplied incorrect database values when installing the Device Manager database or when installing the database client.
Troubleshooting tip:
To determine where the problem is if the database connection fails, use the above DB2 connect command or Oracle sqlplus command to test your database connection from the database server computer. If this test fails, there could be an error in the values you supplied when installing the Device Manager database, and you may have to reinstall it. If this test succeeds, the problem may be with the values supplied when configuring your database client, and you may have to reconfigure it.
The following topics are described in this section:
On Device Manager servers
Install the database client (with JDBC driver) on every Device Manager server that is remote to the Device Manager database. If the Device Manager server and Device Manager database are on the same computer, you do not need to install the database client on that computer.
The Device Manager database must be installed and the JDBC driver, which is installed with the database client, must already be on the target computer before installing the Device Manager server. During the installation of the Device Manager server, you will be asked for the fully qualified path name for the installed database driver.
On Device Manager administration clients
After installing the Device Manager database, install the database client (with JDBC driver) on every Device Manager administration client computer that is remote to the Device Manager database. If the administration client and Device Manager database are on the same computer, you do not need to install the database client on that computer.
After installing and configuring the database client, DB2 users must copy the file db2java.zip, and Oracle users must copy the file classes12_01.zip, to install_dir\prereqs, where install_dir is the directory where the Device Manager console was installed. For example, if the console was installed in c:\TivoliDM, save the zip file to c:\TivoliDM\prereqs. Putting the zip file in the \prereqs subdirectory allows the Device Manager console to communicate with the Device Manager database.
The database client must be installed on the Device Manager server (if your database server is installed on a different computer) and on any client computers where you want to run the Device Manager console.
Note: Oracle8i RDBMS database 8.1.7 was used to develop these instructions.
The basic steps to installing the Oracle database client are:
The following steps are for all supported operating systems, unless otherwise noted in boldface type. Do these steps in the order presented.
Do one of the following:
./runInstaller
From the Oracle Universal Installer interface:
From the Net8 Configuration Assistant interface:
The following topics are described in this section:
The database client must be installed on the Device Manager server (if your database server is installed on a different computer) and on any client computers where you want to run the Device Manager console.
Note: DB2 Universal Database Enterprise Edition 7.2 with FixPak 5 was used to develop these instructions.
The basic steps to installing the DB2 database client are:
Do these steps in the order presented.
Run Setup from the DB2 product CD to display the DB2 Universal Database Enterprise Edition interface.
From the DB2 Universal Database Enterprise Edition interface:
On the Windows desktop, click
Start
Programs
IBM DB2
Client Configuration Assistant
to start the IBM DB2 for Windows Client Configuration Assistant interface.
From the IBM DB2 for Windows Client Configuration Assistant interface:
Click Next.
When the message The connection test was successful appears, click OK.
The DB2 database client must be set up to use the JDBC 2 driver.
Settings
Control Panel
Services and stop any running DB2 services.
cd program files cd sqllib cd java12 jdbc20 usejdbc2
Note: A Linux operating system and DB2 Universal Database Enterprise Edition 7.2 with FixPak 5 was used to develop these instructions.
The basic steps to installing the DB2 database client are:
Do these steps in the order presented.
From a command line on your operating system, run the db2setup command located on the DB2 product CD to display the DB2 Setup Utility.
From the DB2 Setup Utility window:
Log on to your instance ID (for example, db2inst1) and do the following:
catalog tcpip node db2server_short_hostname remote fully_qualified_db2server_hostname server db2_port_number
For example, enter:
catalog tcpip node mydb2server remote mydb2server.raleigh.tivoli.com server 50000
to catalog your database server.
catalog database database_name at node db2server_short_hostname authentication server
For example, enter:
catalog database dms at node mydb2server authentication server
to catalog your database ID.
From your instance ID, at the DB2 command prompt enter:
connect to database_name user database_owner using ibmdb2
For example, to test your connection, enter:
connect to dms user dmsadmin using ibmdb2
Upon successful connection, you will receive a message similar to the following:
db2 connect to dms user dmsadmin using ibmdb2 Database Connection Information Database server = DB2/op_sys SQL authorization ID = DMSADMIN Local database alias = DMS
where op_sys is the operating system and level of your database server; for example, LINUX 7.2.3.
Information on how to install the device agent program for the Palm and Windows CE device classes can be found in the following documents:
For SyncML DM devices, the device agent program is typically installed by the device manufacturer. In the absence of a SyncML DM device, the base SyncML DM client simulator can be used to run jobs. Information on how to install the base SyncML DM client simulator can be found in the Base SyncML DM Plug-in Guide for Device Manager.
After you install Device Manager, do the following post-installation tasks to get Device Manager up and running.
Do these tasks in the order presented:
Servers like Device Manager are started by WebSphere Application Server based on their state when the application server last ran. If the Device Manager server was running the last time the application server stopped, then Device Manager will start automatically when you restart the application server. If the Device Manager server was not running when the application server stopped, then you must start Device Manager manually when you restart the application server.
To start the Device Manager server for the first time after its installation, you must first restart IBM HTTP Web server, and then restart WebSphere Application Server to enable the Device Manager environment settings. When you restart WebSphere Application Server, the Device Manager server will start automatically because it was left in a running state when it was installed.
To start the Device Manager server:
/usr/HTTPServer/bin/apachectl start
/opt/IBMHTTPD/bin/apachectl start
Settings
Control Panel
Services.
/usr/WebSphere/AppServer/bin/startupServer.sh &
/opt/WebSphere/AppServer/bin/startupServer.sh &
Settings
Control Panel
Services.
tail -f /usr/WebSphere/AppServer/logs/tracefile
Wait until the trace completes with the message WebSphere Administration server open for e-business, then press Ctrl-C to exit TAIL.
tail -f /opt/WebSphere/AppServer/logs/tracefile
Wait until the trace completes with the message WebSphere Administration server open for e-business, then press Ctrl-C to exit TAIL.
notepad c:\WebSphere\AppServer\logs\tracefile
Check the bottom of the Notepad window for the message WebSphere Administration server open for e-business.
If you are starting the Device Manager server for the first time after installation, or if it was running the last time the application server stopped, skip steps 4 and 5, and go to step 6.
/opt/WebSphere/AppServer/bin/adminclient.sh &
/usr/WebSphere/AppServer/bin/adminclient.sh &
Start
Programs
IBM WebSphere
Application Server 4.0 AE
Administrator's Console.
DMS_App_Server.start completed successfully
check the WebSphere Application Server log files (you may have renamed them) for the message:
Server DMS_AppServer open for e-business.
/usr/WebSphere/AppServer/logs/DMS_stdout.log to make sure the servlets were started correctly
/usr/WebSphere/AppServer/logs/DMS_stderr.log to make sure there are no error messages
/opt/WebSphere/AppServer/logs/DMS_stdout.log to make sure the servlets were started correctly
/opt/WebSphere/AppServer/logs/DMS_stderr.log to make sure there are no error messages
c:\WebSphere\AppServer\logs\DMS_stdout.log to make sure the servlets were started correctly
c:\WebSphere\AppServer\logs\DMS_stderr.log to make sure there are no error messages
Device Manager will instantiate the installed and configured device classes and be ready for work.
The following topics are described in this section:
The Device Manager console is a graphical user interface (GUI) for administering device management operations. The administration tasks that can be performed from the console are described in Administrator's Guide for Device Manager.
The installing and starting tasks in this section must be performed on every Device Manager administration client computer.
You can install the Device Manager console on any supported administration client computer.
To download and install the console:
http://server_name/dmconsole/DMconsole
where server_name is the host name and domain of a Device Manager server (for example, dmserver.raleigh.tivoli.com).
Note: Port 80 is the default port for the IBM HTTP Web Server used by Device Manager. Before installation of a Device Manager server, the default port for the Web server can be changed. If the port number was changed, then you will have to include the new port number in the server_name portion of the URL of the above Web page. For example, you will have to type a URL like:
http://dmserver.raleigh.tivoli.com:8080/dmconsole/DMconsole
where :8080 references the changed port number.
When you install the console as described in Installing the Device Manager Console, a Tivoli folder that contains a Device Manager Console selection is added to the Programs information in your Microsoft Windows Start menu.
To start the console:
Programs
Tivoli
and select Device Manager Console.
Note: Port 80 is the default port for the IBM HTTP Web Server used by Device Manager. Before installation of a Device Manager server, the default port for the Web server can be changed. If the port number was changed, then you will have to include the changed port number when completing the Device Manager server field of the Login window. For example, the administrator will have to type a Device Manager server like:
myserver.raleigh.tivoli.com:8080
where :8080 references the changed port number.
It is important that the Device Manager server and Device Manager database be up and running the first time a console startup is attempted.
At every startup, the Device Manager console retrieves necessary properties files from the Device Manager server. Without these files you cannot log in to the console. After each successful startup, the most recent properties files are retained locally on the client and can be used as backup files to enable login, should the Device Manager server be unreachable for any reason. However, if the Device Manager server cannot be reached the very first time after installation, console login is not possible because no backup files exist on the client.
Following the first successful startup, the console can access the Device Manager database directly and only needs to contact a Device Manager server to retrieve updated properties files or display help.
Troubleshooting tip: Unicode fonts
If you have trouble displaying Unicode fonts in the Device Manager console, installing another font and changing the fontName property in the preferences.properties file may resolve the problem:
For example, WebSphere Everyplace Access customers can copy any of the following Montotype Sans WT font files from the \dms\fonts directory of product CD 6:
console_directory\dm\dmspkgs\preferences.properties
where console_directory is the Windows administration client directory where the Device Manager console is installed (for example C:\TivoliDM).Example fontName property statements:
fontName=Montotype Sans WT J
fontName=Montotype Sans WT K
fontName=Montotype Sans WT S
fontName=Montotype Sans WT T
If the product that includes Device Manager supports the Device Manager Care applications, see the instructions provided with that product for startup information.
To remove the Device Manager console from a Microsoft Windows client, do the following: