Implementing ibm tivoli remote control in small to midsized enviroments redp3663

Redbooks Paper
Szabolcs Barabas
Alan Hsu
Edson Manoel

Implementing IBM Tivoli Remote
Control in Small to Midsized
Environments

The Tivoli® flagship change and configuration management product, IBM® Tivoli
Configuration Manager, has become an industry leader and is deployed across
many of today's Fortune 500 companies. Unfortunately, a product whose value
proposition complements IBM Tivoli Configuration Manager is oftentimes
underemphasized as a complementary help desk tool. IBM Tivoli Remote
Control offers enterprise IT shops a comprehensive, integrated management
suite to perform their configuration management needs. Enabling help desk
operators to fix remote PCs as if they were on-site, and thereby optimizing
customer productivity, IBM Tivoli Remote Control is a natural extension of the
Tivoli environment.

This Redpaper is primarily targeted toward new Customers and small to midsize
Customers who have Tivoli deployed, but have not yet implemented IBM Tivoli
Remote Control. Instructions for setting up the Tivoli Management framework
infrastructure are provided for new Customers as well. The purpose of this
Redpaper is to demonstrate the technical attractiveness, ease-of-deployment,
fast time-to-market, and fundamental integration with Tivoli infrastructure of IBM
Tivoli Remote Control. This paper makes the point that Customers can realize
clear ROI and value by implementing IBM Tivoli Remote Control in addition to
the rest of their current Tivoli investment.

© Copyright IBM Corp. 2003. All rights reserved. ibm.com/redbooks 1

While the information provided by this paper can be used on deployments of any
size, it is particularly useful to enable a remote control solution by small and
medium businesses (SMB), as well as to enable Business Partners and IBM
services for setting up demonstrations and proofs of concept.

The instructions given in this paper are very detailed and explicit. These
instructions are not the only way to install the product and related prerequisites.
They are meant to be followed by someone with limited experience with the
product, to enable them to successfully install and set up the IBM Tivoli Remote
Control environment.

2 Implementing IBM Tivoli Remote Control in Small to Midsized Environments

IBM Tivoli Remote Control overview
IBM Tivoli Remote Control (ITRC) provides a complete real-time solution for
controlling target systems remotely. The technician’s or administrator’s keyboard
and mouse become the target system’s primary keyboard and mouse for the
duration of a remote control session. Functionality such as chat, reboot, and file
transfer are available to the administrator.

IBM Tivoli Remote Control runs on top of the IBM Tivoli Management
Framework. Specific IBM Tivoli Remote Control components will be deployed
depending on the network architecture and existing Tivoli environment. For
example, if there is a need for remote control access to workstations placed in an
environment protected by firewalls, Remote Control Proxies can be utilized to
simplify and secure the way communications are exchanged between the
different components of IBM Tivoli Remote Control. Before we define the
deployment process, it is important to first understand the utility and functionality
of each component of IBM Tivoli Remote Control and of the IBM Tivoli
Management Framework that will be used later in this paper.

IBM Tivoli Management Framework components
The IBM Tivoli Management Framework enables you to install and create several
management components (services) that enable you to manage the resources in
your network. You can install any or all of these services, depending on your
organizational needs. At least one Tivoli management server must be installed.
The following is a list of the management services provided by the Tivoli
Management Framework and a brief description of each:
TMR Server The Tivoli Management Region (TMR) Server includes
the libraries, binaries, data files, and a graphical user
interface (GUI) needed to install and manage your Tivoli
environment. The TMR Server maintains the Object
database and coordinates all communications with Tivoli
managed systems, such as Managed Nodes and
Endpoints (through Tivoli Endpoint Gateways). The
server also performs the authentication and verification
needed to ensure the security of Tivoli Enterprise™ data.
Managed Node A Tivoli Managed Node runs the same software that runs
on a TMR Server. Managed Nodes maintain their own
Object databases, which can be accessed by the TMR
Server. When Managed Nodes communicate directly
with other Managed Nodes, they perform the same
communication or security operations as they would
perform with the TMR Server. Although there is no clear
distinction between managed systems and managing

Implementing IBM Tivoli Remote Control in Small to Midsized Environments 3

systems, the introduction of the Endpoints architecture
leads to a paradigm shift. Managed Nodes are
considered to be managing systems (hosting the
desktop or running as a gateway), whereas endpoints
are the managed systems.
Endpoint Manager The Endpoint Manager establishes and maintains the
relationship between an Endpoint and its assigned
Gateway. It puts the Endpoint in charge when its
assigned Gateway is no longer responding. It also is
involved in identifying the Gateways assigned to an
Endpoint when applications are trying to contact the
Endpoint. The Endpoint Manager runs on top of the TMR
Server and is created automatically during the TMR
Server installation process.
Endpoint Gateway The Endpoint Gateway provides access to the Endpoint
methods and provides the communications with the TMR
Server that the Endpoints occasionally require. A single
Gateway can support communications with thousands of
Endpoints and can launch methods on an Endpoint or
run methods on the Endpoint’s behalf. A Gateway is
created on an existing Managed Node.
Endpoint Proxy An Endpoint Proxy is an optional component that
emulates Endpoints to the Gateway to simplify the Tivoli
communications in a firewall environment through a
common port. The Endpoint Proxy funnels requests for
specific Endpoints through a single TCP/IP port and
passes it down to a Relay or a Gateway Proxy. This
component is part of the Tivoli Firewall Security Toolbox
and must be installed on the same network zone as the
Tivoli Endpoint Gateway to which it is connected.
Relay The Relay component passes information sent to it up or
down the chain to an Endpoint Proxy, Gateway Proxy, or
other Relays. This component is optional and is part of
the Tivoli Firewall Security Toolbox. It must be installed
in the network zone between the Endpoint Proxy and the
Gateway Proxy. Multiple Relays can be chained to allow
this connection if the Endpoint Proxy and Gateway Proxy
are separated by multiple network zones. There can be
multiple instances of the relay running on the same
machine.
Gateway proxy A Gateway Proxy is an optional component that
emulates a Gateway to the Endpoints to simplify the
Tivoli communications in a firewall environment through


a common port. The Endpoints are not explicitly aware of
the fact that this destination is not truly a Gateway. This
component is part of the Tivoli Firewall Security Toolbox
and must be installed on the same network zone as the
distant Endpoints.
Endpoint A Tivoli Management Agent (TMA) is any system that
runs an Endpoint service (or daemon). Typically, an
Endpoint is installed on a machine that is not used for
daily management operations. Endpoints run a very
small amount of software and do not maintain a
database. The majority of systems in most Tivoli
Enterprise installations will be Endpoints.
Policy Region A Policy Region is a collection of Tivoli resources that are
governed by a common set of policies. A Policy Region
is created to represent a management domain or area of
influence for one or more system administrators.
Administrator Tivoli Administrators are responsible for managing
various aspects of enterprise-wide systems
management. Tivoli functionality enables administrative
functions that may be performed at many levels and
locations of the organization. Administrators may be
individuals or groups of persons with different logons.
Collection The Collection is a container that groups objects on a
Tivoli Desktop, thus providing the Tivoli Administrator
with a single view of related resources. Such Collections
are defined when an Administrator needs to centralize
miscellaneous resources stored in different Policy
Regions. A Collection provides a “shortcut” for using
resources.

For more information about TMR Server, Managed Node, Endpoint Gateway,
Endpoint and Policy Region, refer to the manual Tivoli Management Framework
Planning for Deployment Guide, GC32-0803.

For more information about Endpoint Proxy, Gateway Proxy, and Relay, refer to
the manual Firewall Security Toolbox User’s Guide, GC23-4826, and to the
Redbook Tivoli Enterprise Management Across Firewalls, SG24-5510.

IBM Tivoli Remote Control components
The IBM Tivoli Remote Control is a client-server application that helps you take
control over workstations on a network using a specific remote control
technology. It can serve as a central location for monitoring and controlling


machines at local or remote locations. Installation is mandatory for the following
Remote Control components (except for the Remote Control Proxies and the
Remote Control Gateway, which are used only in environments where
components of a Tivoli Management Region are separated by firewalls):
RC Server The Remote Control Server (RC Server) component is
installed on the TMR Server and on each Managed Node
that will act as an Endpoint Gateway. It manages the
Remote Control session request from a Remote Control
Controller to a Remote Control Target until successful
initiation of the connection between the two machines.
RC Tool The Remote Control Tool (RC Tool) is the Remote
Control managed resource in the Tivoli Management
Region and is associated with a Policy Region. This tool
enables remote operations such as remote controlling or
rebooting of a workstation, transferring files, and
chatting. Customizing the default Remote Control
policies enables you to change the set of rules that will
apply to the RC Tool within a Policy Region.
RC Policies The Remote Control Policies consist of a set of rules, the
policy methods, that govern the default behavior and
graphical appearance of Remote Control Tools.
RC Controller The Remote Control Controller component is installed
automatically on each Endpoint that initiates a Remote
Control session. It enables a Tivoli Administrator to take
control of a remote target workstation to which it is linked
over a network. This component is also known as
Controller.
RC Target The Remote Control Target component is installed
automatically on each Endpoint when a session from a
Remote Control Controller is initiated. This component is
also known as Target.
RC Controller Proxy The Remote Control Controller Proxy is an optional
component that can be used to simplify communication
between Controllers and Targets in a firewall
environment through a common port. In fact, this
component simulates a Remote Control Controller to the
Targets that are separated from the Controllers by
firewalls. This component must be installed in the same
network zone as the Targets. Nevertheless, this
component could be installed either on top of an
Endpoint/Gateway Proxy or as a standalone component.


RC Target Proxy The Remote Control Target Proxy is an optional
component that can be used to simplify the
communication between Controllers and Targets in a
firewall environment through a common port. This
component simulates Remote Control Targets to the
Controllers that are separated from the Targets by
firewalls. This component must be installed in the same
network zone as Controllers. Nevertheless, this
component could be installed either on top of an
Endpoint/Gateway Proxy or as a standalone component.
RC Gateway The Remote Control Gateway is an optional component
that can be used when a direct link from the Controller to
the Target is not authorized. In this case, a Remote
Control Gateway must be installed on top of a Tivoli
Endpoint Gateway.

For more information about Remote Control Server, Tool, Policies, Controller,
and Target, refer to product manual IBM Tivoli Remote Control User’s Guide,
SC23-4842.

For more information about Remote Control Controller and Target Proxies and
their implementation in an IBM Remote Control environment where firewalls are
involved, refer to the redbook Implementing Remote Control Across Firewalls,
SG24-6944.

IBM Tivoli Remote Control sessions overview
This section describes in detail the data flow of Remote Control sessions used in
simple implementations. This is meant to help you fully understand how IBM
Tivoli Remote Control communications work and what you have to consider in
your design. The scenario presented in this section should provide you enough
information to master other, more complicated situations. Event though only the
Remote Control action is discussed here, the process is similar for the File
Transfer action. More information about these actions can be found in the IBM
Tivoli Remote Control User’s Guide, SC23-4842.

Figure 1 on page 8 shows in detail how a Remote Control session works in a
single-TMR environment without firewall restrictions. Figure 1 on page 8
assumes that the TMR Server, RC Server, Endpoint Manager, Endpoint
Gateway, Endpoint, and RC Controller are installed in the same physical
machine. The concepts and explanations that follow do not change if some of
those components are installed in separate machines.


TMR Server A D

PR
Endpoint

A RC Controller
RC Tool J

C
I
E H I
RC Server Endpoint GW H Target
B

F

G
Endpoint Mgr

Figure 1 Remote Control session data flow in a single-TMR environment

Based on Figure 1, we provide a description of each step, from the time the Tivoli
Administrator opens the Remote Control Tool (RC Tool) until the connection is
established between the Controller and the Target. The legend used in Figure 1
is explained as follows:
A The Tivoli Administrator must first open an RC Tool to be able to
select a Target from a list. The Policy Region in which the RC Tool is
located must be opened as well.
B As soon as the RC Tool is opened, the Remote Control Server must
validate the RC Controller by checking:
– Whether the RC Controller is an Endpoint.
– Whether the label of the Endpoint is the same as that of the
hostname of the RC Controller.
– Whether the interpreter of the RC Controller is supported and
able to start a Remote Control session.
To get this information, the Remote Control Server must contact the
Endpoint Manager.


C If the RC Controller is validated, the Remote Control Server loads a
subset of the Remote Control policies from the Policy Region where
the RC Tool is located. In this scenario, we will call these policies
basis policies. These basis policies are accessed only when the RC
Tool is opened and not loaded again while the Tool is active.
D At this point, the Tivoli Administrator can start a Remote Control
session by clicking on the Run button of the RC Tool after selecting a
Target.
E The Remote Control Server then loads the rest of the Remote
Control policies. These policies are more network-related; for
example, they specify whether a Remote Control Proxy or a Remote
Control Gateway should be used and which port is defined to start
the session. Unlike the basis policies, these Remote Control policies
are loaded every time a new session is started from this RC Tool.
F When all Remote Control policies are loaded, the Remote Control
Server must obtain additional information for both the RC Controller
and the Target, such as their IP addresses. To obtain this information,
the Remote Control Server must contact the Endpoint Manager.
G Before initiating the connection, the Remote Control Server needs to
know whether the Target must be reached using an Endpoint
Proxy/Gateway proxy infrastructure. If the Target is a proxied
Endpoint, the Remote Control Server should send the request
through an Endpoint Proxy instead of using the standard Tivoli
Endpoint Gateway communication process.
H As soon as the Remote Control Server knows how it should contact
the Target, it sends an executable (sometimes referred as Endpoint
method) to the Target and waits for the process to start. This
executable prepares the Target to communicate to the RC Controller
and is named EQNRCMAI.EXE.
I As soon as the Target is started, the Remote Control Server sends
an executable method to the RC Controller and waits for the process
to start. The local process started on the RC Controller prepares the
RC Controller to contact the Target and is named EQNRSMAI.EXE.
J The Remote Control session is now established. It is important to
note that once the session established, the RC Controller
communicates directly with the Target; this is a peer-to-peer
communication. The Target listens on port 2501 (port 2502 for file
transfer and port 2503 for chat) by default. On the Controller side, by
default, the port is assigned by the communication stack. However,
these ports can be changed easily by changing the Remote Control
Policies.


There can be cases where the network architecture requires the use of the
Remote Control Proxies because of firewall restrictions. In order to understand
how IBM Tivoli Remote Control sessions work where firewalls are involved, refer
to the redbook Implementing Remote Control Across Firewalls, SG24-6944.

Case study scenario overview
In order to illustrate the IBM Tivoli Remote Control installation and configuration
process, this Redpaper models a fictitious SMB financial service company
named CSI Financial. CSI Financial is based in Austin, Texas, and its IT
infrastructure consists of a total of 70 corporate servers and 500 desktops, all
running Microsoft Windows operating systems.

CSI Financial wants to ensure the high availability and quality of its services and
would like to set up a technical support team, which can interact quickly with end
users as well as its servers in case of any problems. This technical support team
would consist of systems administrators and technical support operators.
Corporate system administrators
The system administrators would be responsible primarily for the corporate
servers containing sensitive data, such as the domain controllers, and file and
application servers. CSI Financial wants only these administrators to have
Remote Control access the servers that are critical to its business.
Technical support personnel
These personnel are IT operators who will be in charge of providing technical
support to CSI’s workstation users. Access to the workstations will be
requested by the operator and then granted by the end user. CSI Financial
wants the technical support personnel to have access to non-mission-critical
servers, such as printer servers, in case system administrators are not
available, but doesn’t want them to access servers that are critical to its
business.

Figure 2 on page 11 depicts the planned Remote Control access level design for
CSI Financial.


full access with full access with
user's permission user's permission

end user
Workstations

full access

full access

non-mission
critical servers

full access

technical
systems
suppport
administrators

mission-critical servers
holding sensitive data

CSI Financial

Figure 2 Planned Access levels for IBM Tivoli Remote Control

The company would like to implement the remote control environment from one
central point, preferably the entire management environment rolled out on one
single server, and has chosen IBM Tivoli Remote Control.

The proposed Tivoli environment for CSI Financial is depicted in Figure 3 on
page 12.
An additional server will be introduced to the CSI IT environment hosting the
TMR server. This server will also host the RC Server and RC Controller
components.
Tivoli Desktop software will be deployed on the technical support team
systems.
Tivoli endpoint will be deployed throughout the CSI IT infrastructure, enabling
remote control access for the technical support team.


Endpoint targets

Tivoli Desktop
Tivoli Desktop

Endpoint targets

Tivoli Desktop

Tivoli Desktop

TMR server
endpoint gateway
endpoint
RC server
RC Controller

Endpoint targets

Figure 3 Proposed Tivoli implementation environment for CSI

In the next sections of this Redpaper, we will cover the installation steps required
to have the remote control environment for CSI Financial shown in Figure 3 up
and running. We will also show how to configure the Tivoli environment in order
to have the proper remote control solution and permissions according to the
company’s requirements presented in this section and shown in Figure 2 on
page 11. We will also show how to establish a remote control session
step-by-step with the Target, using one of the technical support operators as an
example.


Implementing the Remote Control environment
This section describes the installation process of IBM Tivoli Remote Control 3.8
based on the scenario presented in Figure 3 on page 12. We also present the
installation steps for the IBM Tivoli Management Framework in case of a new
customer or a proof-of-concepts situation. We also list the systems requirements
for AIX®, Linux and Microsoft Windows operating systems installations. In line
with our approach to show IBM Remote Control ease-of-deployment and fast
time-to-market capabilities for small and medium businesses, we provide in this
section installation steps on a Windows platform, as this is the most widely used
OS in small environments.

Tivoli software has specific software and hardware prerequisites that must be
met before it can be installed and considered functional. These requirements
include operating systems, hardware platforms, and relational and object
database management systems. The prerequisites listed in this section are the
recommended environment for Tivoli software at the time of publication. Always
refer to the official product documentation for up-to-date information.

System requirements for Tivoli Management Framework
This section contains information about the supported OS versions for each
supported hardware platform. IBM does not distribute or maintain OS patches
from hardware vendors, except for IBM operating systems. Contact your
hardware vendor for information about obtaining and installing the most current
OS patches. If you do not know how to contact your hardware vendor, contact
your IBM support provider for details about the recommended procedure.

The following table lists which Tivoli Management Framework resources are
supported on which operating systems.

Table 1 Resource types supported on operating systems
Operating system Resource type

AIX 4.3.3 ML 4330-09 Tivoli Server, Managed Node, Endpoint
AIX 5.1.1 ML 5100-01 Gateway, and Endpoint

Red Hat 7.2 or SuSE 7.2 Tivoli Server, Managed Node, Endpoint
Gateway, and Endpoint

Windows NT 4.0 SP6a Tivoli Server, Managed Node, Endpoint
Windows 2000 Server or Advanced Server Gateway, and Endpoint

Windows 98 Endpoint
Windows 2000 Professional
Windows XP Professional


The following table lists the minimum disk space required for Tivoli Management
Framework. The estimated disk space includes space for the Tivoli libraries,
binaries, server database, client database, manual pages, and message
catalogs.

Table 2 Required disk space
Platform Libraries Binary Server Client Man Message
files DB DB pages catalogs
AIX 20MB 110MB 30MB 10MB 1MB 1MB

Linux 15MB 100MB 30MB 10MB 1MB 1MB

Windows 110MB in the same 30MB 10MB 1MB 1MB
location

The following table presents the minimum memory requirements for Tivoli
Management Framework.

Table 3 Memory requirements
Platform Tivoli Server Managed Node Endpoint

AIX 128MB 128MB less than 2MB

Linux 128MB 128MB less than 2MB

Windows 128MB 128MB less than 2MB

As each Tivoli Enterprise product is added to your Tivoli environment, additional
disk space and memory are required. Refer to the appropriate documentation for
planning information and additional disk space requirements.

System requirements for IBM Tivoli Remote Control
When you install IBM Tivoli Remote Control for the first time, you should ensure
that your hardware and software match or exceed the requirements for the Tivoli
Management Framework in addition to the requirements presented in this
section.

IBM Tivoli Remote Control has specific hardware prerequisites that must be met
before it can be installed and considered functional. These requirements include
hardware platforms, RAM, and disk space. The prerequisites listed in this section
are the minimum recommended environment for IBM Tivoli Remote Control at
the time of publication.

Table 4 on page 15 identifies the supported operating system versions for each
supported hardware platform.


Table 4 Remote Control supported platforms
Operating Version RC Server RC Controller Target
system
AIX 4.3.3 and 5.1 X

Solaris 7 and 8 X

HP-UX 11.0 and 11i X

Red Hat Linux 7.1, 7.2, and 7.2 X
for S/390®

SuSE Linux 7.3 X

Turbo Linux 6.5 X

Windows 2000 Professional X X

Server and X X X
Advanced Server

Windows NT 4.0 SP 6A X X

4.0 Terminal X X
Server edition

Windows 98 Second edition X X

Windows XP Professional X X

OS/2® Warp 4.5.1 X X
Server

Table 5 on page 16 lists the hard-disk space required by the IBM Tivoli Remote
Control components for each supported platform.

To know the disk space needed when file transfer and chat software are installed
you must also consider the disk space occupied by the Java ™ Run-time
Environment 1.3 files. These files are downloaded, if not already present, the first
time you start a file transfer or chat session.


Table 5 Remote Control hard drive requirements
Remote Hard disk space required (MB)
Control
component Windows Windows Windows Windows UNIX /
98 XP NT 2000 Linux for
Second Intel
Edition
Controller 4.0 4.4 4.3 4.3 -

Target 3.2 5.1 5.1 5.1 -

RC Server - - - 57.3 57.3

RC Gateway

JRE 1.3 24 24 24 24 -

RC Proxies - - - 28.3 32.1 - AIX
35.7 other

Pre-installation tasks
Before installing IBM Tivoli Remote Control, you must have the following software
installed and running. Information provided here is focused on Windows
platforms. For other platforms, refer to product manual IBM Tivoli Remote Control
User’s Guide, SC23-4842.
A supported operating system and network protocol.
Tivoli Management Framework 3.7.1 or higher.
Tivoli Endpoint (lcf version 91 or later) installed on the workstations that will
work as Controllers and Targets.
Tivoli Desktop on the workstations where you want to use the Tivoli Remote
Control graphical user interface.
One of the following Web browsers on the workstations where you want to
use the Tivoli Remote Control Web interface:
– Netscape 4.6 or later
– Internet Explorer 5.0, 5.5+SP1® or later
User Permission Requirements on Windows Endpoints
Before installing Tivoli Remote Control and starting a session, ensure that the
user account name specified in the root_user map is an administrator
account for the endpoint operating system. For Windows NT, Windows 2000,
and Windows XP Endpoints the default value of the root_user map is the
default built-in Administrator account. If you rename the default built-in


administrator account or you use a different Windows account name as the
root_user map, ensure that this new user account conforms to the following
rules:
– Is defined either at domain level or on each Endpoint of the Tivoli
management region.
– Is defined in the Windows Administrators and Tivoli_Admin_Privileges
groups on each endpoint.
– Has Full Control permission on the following directories:
• %WINDIR%
• %WINDIR%system32
• %WINDIR%system32 drivers
• %LCF_DIR%, where LCF_DIR is the Endpoint installation directory
– Has Full Control access to the following registry keys:
• HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersion
RunOnce
• HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices
• HKEY_LOCAL_MACHINESOFTWARETivoli
– Is authorized to:
• Log on locally
• Access the workstation from the network
• Install services and drivers
• Reboot the workstation

Tivoli Framework environment installation
This section describes the steps required to have all the IBM Tivoli Management
Framework components up and running. They will all be installed on a single
machine, as described in “Case study scenario overview” on page 10, running
Windows 2000 Advanced Server SP3. The following components will be installed
or created:
Tivoli Management Framework
Tivoli Desktop
Endpoint Gateway
Endpoint


IBM Tivoli Management Framework installation
In order to have the IBM Tivoli Management Framework installed on Windows,
perform the following steps:
1. Run Setup.exe, located in the root directory of the IBM Tivoli Management
Framework installation media. The install welcome screen will appear:

Figure 4 Tivoli Management Framework setup: Welcome

2. Press Next to continue. The license agreement screen will be displayed.
Click Yes to accept the agreement.
3. The window in Figure 5 on page 19 describes what accounts should be
created and what permissions should be set in order to ensure the proper
operation of the software. Click Next to continue.


Figure 5 Accounts and file permissions

4. The installation proceeds asking for a installation password. We did not
specify one. Click Next to continue.
5. The next panel enables you to create a Remote Access user id and password
with which you can access remote drives. We did not define one. Click Next.
6. The Setup Type panel appears. Select the destination folder and installation
type Typical. Click Next.
7. Select the directory for the Tivoli database, as shown in Figure 6 on page 20.
Click Next.


Figure 6 Choose Database Directory window

8. Enter your license key, and click Next.
9. You will have a chance to review the installation settings. Click Next to start
the installation.

Figure 7 Setup status window


10.While the files are being copied, the Tivoli Object Dispatcher Server database
initializes.

Figure 8 Object Dispatcher database initialization

11.When the installation wizard completes the installation process, click Finish
and reboot the system.
12.After restart, the following services should be running:
– Tivoli Object Dispatcher
– Tivoli Remote Execution Service


Figure 9 Tivoli Services are running

Tivoli Desktop installation
In order to have the IBM Tivoli Management Framework installed on Windows on
the same machine where the IBM Tivoli Management Framework is installed, run
Setup.exe (located in the <CD_drive>:DESKTOPNT_95 folder) and follow the
installation wizard instructions.

The Tivoli Desktop software also must be installed in the systems where remote
control sessions will be initiated. In the case of CSI Financial, the Tivoli Desktop
must be installed on the technical support team systems.

Endpoint Gateway creation
The Endpoint Gateway can be created either by using the Tivoli Desktop or
command line. In order to speed up the process, here we describe the command
line method. This step should be performed on the same machine where the IBM
Tivoli Management Framework is installed.
1. Open a Command Prompt window and initialize the Tivoli command line
environment as follows:
cd WINNTsystem32driversetcTivoli
.setup_env.cmd


2. Issue the wcrtgate command as follows:
wcrtgate -h <Tivoli_Srv_hostname> -n <Endpoint_GW_name> -p port -P protocol
where <Tivoli_Srv_hostname> is the Tivoli Server hostname,
<Endpoint_GW_name> is the name of the new Endpoint Gateway, port is the
communication port, and protocol is the communication protocol (TCP/IP).
For example:
wcrtgate –h itrc01 –n itrc01_gw –p 9494 –P tcpip

Endpoint installation
To install the Endpoint on a Windows platform, perform the following steps. In our
case study scenario, we install the Endpoint on the same machine as the IBM
Tivoli Management Framework, as well as on every machine that will be a
Remote Control Target.
1. To install the Endpoint, mount the IBM Tivoli Management framework media,
locate and run Setup.exe in <CD_drive>:lcf<OS>, where <OS> is the
operating system. In our case WINNT. Click Next on the welcome screen.
2. The license agreement screen will be displayed. Click Yes to accept the
agreement.
3. The following window describes what accounts should be created and what
permissions should be set in order to ensure the proper operation of the
software. Click Next to continue.
4. Choose the destination folder. Click Next to continue.

Figure 10 Endpoint install: Choose Destination Folder


5. The next panel asks for the Remote Access user ID and password. As this
was not specified during the IBM Tivoli Management Framework installation,
we do not enter any value. Click Next to continue.
6. The Advanced Settings window is now displayed.

Figure 11 Endpoint install: Advanced Settings

In this panel, you should specify the following:
– The Endpoint Gateway communication port. Default to 9494.
– The Endpoint communication port. Default to 9495.
– In the Options box, the login interfaces to the Endpoint Gateway:
-D lcs.login_interfaces=<Endpoint_GW_IPADDR>+port, where
<Endpoint_GW_IPADDR> is the Endpoint gateway IP address and port is the
communication port specified in the Gateway port box.
Click Next to continue.
7. Review the installation settings, and click Next to start the installation.
8. When the installation completes, the Endpoint tries to log on to the Endpoint
gateway using the information provided in the Advanced Configuration panel.

Figure 12 Login to gateway


If successful, you will see the following message.

Figure 13 Gateway login successful

Press Next and Finish to complete the installation process.
9. You can check the Endpoint status by clicking on the endpoint icon in the
system tray of your machine. A status window will pop up.

Figure 14 Endpoint status window


IBM Tivoli Remote Control Server installation
This section describes the steps required to get the IBM Tivoli Remote Control
components up and running. They will all be installed on the same machine as
the IBM Tivoli Management Framework, as described in “Case study scenario
overview” on page 10. The following components will be installedor created:
Remote Control Server
The main component to be installed.
Remote Control Tool
Provided by the Remote Control Server installation. It will be created later by
the Tivoli Administrator. This step will be shown in “Creating the Remote
Control Tool” on page 33.
Remote Control Controller and Remote Control Target
You do not have to install Remote Control Controller software manually on
Endpoints. When you start a remote control session for the first time from an
Endpoint, through the Tivoli Desktop, the Tivoli command line, or the Web
interface, the Remote Control Controller software is automatically installed on
that Endpoint. The Remote Control Target software is installed on the
Endpoint contacted by the Controller to start a session.
Remote Control Policies
Provided by the Remote Control Server installation. It will be customized later
by the Tivoli Administrator. This step will be shown in “Customizing the
Remote Control Policy” on page 42.

The IBM Tivoli Remote Control software can be installed on the Tivoli framework
environment either by the Tivoli Desktop or using a command line. The
installation procedure presented here uses the Tivoli Desktop method.


To install the IBM Tivoli Management Framework on Windows, perform the
following steps:
1. From the Start menu, open Tivoli Desktop, and click Desktop -> Install ->
Install Product, as shown in Figure 15.

Figure 15 Install Product


2. The File Browser window pops up, as shown in Figure 16. Set the path to
Remote Control installation media, and click Set Media & Close.

Figure 16 File Browser window

3. The Install Product window appears, as shown in Figure 17 on page 29.


Figure 17 Install Product window

Highlight IBM Tivoli Remote Control Server 3.8, and select the machine that
you want to install on. Press Install & Close to start the installation.
4. The product installer performs all dependency checks and lists what files will
be installed and what actions will be performed. Click Continue Install.


Figure 18 Product Install window

5. When the installation is finished, click Close to exit.

Customizing the Remote Control environment
This section describes the customization steps of IBM Tivoli Remote Control 3.8
based on the scenario presented in “Case study scenario overview” on page 10.
The following topics will be presented:
Policy Regions structure
Assign the Target machines to the appropriate Policy Region
Remote Control Tool creation
Create the Tivoli Administrators
Customize the Remote Control Policies
Create Tivoli Desktops for the Tivoli Administrators


Setting up Policy Regions
Based on the scenario presented in “Case study scenario overview” on page 10,
the company has four kinds of computers on which administrators and technical
support operators must have Remote Control access:
User workstations
Printer servers
Servers
Web server

These machine groups have the same characteristics regarding the access level,
so we create four separate policy regions for them. In order to have an organized
structure, we created the following Policy Region hierarchy shown in Figure 19.

TMR Server
itrc01

itrc01_Region pr.RC.SA pr.RC.TS pr.RC.UserWS

rc_SA_SRV rc_TS_SRV rc_UserWS
pr.RemoteControl

pr.RemoteControl.UserWS pr.RemoteControl.PrinterSVR pr.RemoteControl.SVR pr.RemoteControl.WebSVR

UserWS1 UserWS2 PRT.SRV1 SVR1 WebSvr1

Figure 19 Remote Control Sample Policy region structure

To create a Policy Region, open Tivoli Desktop and select Create -> Region
from the menu. Enter a name for the new Policy Region and click Create &
Close. You can create subregions by opening the new Policy Region and clicking
Create -> Subregion.


More on Policy Region can be found in the Tivoli Management Framework
Planning for Deployment Guide, GC32-0803 manual.

Assigning Remote Control Targets to Policy Regions
Once this Policy Region structure has been created, assign the Target machines
to the respective Policy Region. All Target machines should be Endpoints of the
Tivoli environment and must have the Endpoint software installed and running.

To assign a Target to a policy region, perform the following steps for all Targets:
1. Ensure that the Policy Region where the Endpoint will be assigned has the
Endpoint resource in the list of managed resource types valid for that specific
Policy Region. To do this using the Tivoli Desktop, open the Policy Region and
click Properties -> Managed Resources. Select Endpoint from the Current
Resources list, then click Set & Close to continue.

Figure 20 Policy Region Managed Resources

2. Use the Tivoli command line to assign the Endpoint to the Policy Region.
Open a Command Prompt window and initialize the Tivoli command line
.setup_env.cmd
3. Issue the wmv command as follows:
wmv @Endpoint:<Endpoint_Label> @PolicyRegion:<Policy_Region_Label>
where <Endpoint_Label> specifies the Endpoint label on the Tivoli
environment, and <Policy_Region_Label> specifies the Policy Region name
to which the Endpoint has to be assigned.


For example:
wmv @Endpoint:itcmpda1 @PolicyRegion:pr.RemoteControl.PrinterSVR
4. Synchronize the Tivoli gateway to which the endpoint logs on by using the
following command:
wep sync_gateways
5. Close and restart the Tivoli Desktop in order to effect these changes.
6. Check to see whether the endpoint is assigned by opening the Policy Region.

Figure 21 Endpoint assigned successfully

Creating the Remote Control Tool
The next step is to create all the Remote Control Tools needed. In our case study
scenario, we define three Remote Control Tools as follows:
rc_SA_SVR
This will be used by the system administrators to open Remote Control
sessions to the company’s servers.
rc_TS_SVR
This will be used by the technical support operators to open Remote Control
sessions to the company’s servers with no critical information, such as printer
servers.
rc_UserWS
This will be used by the technical support operators to open Remote Control
sessions to the company’s users workstations.


To create the Remote Control Tool:
1. Ensure that the Policy Region where the Endpoint will be assigned has the
RemoteControl resource in the list of managed resource types valid for that
specific Policy Region. Using the Tivoli Desktop, open the Policy Region and
click Properties -> Managed Resources. Select RemoteControl from the
Current Resources list, then click Set & Close to continue.

Figure 22 Setting managed resources

2. From the Policy Region, select Create -> RemoteControl to display the
Create Remote Control Tool dialog.

Figure 23 Creating a Remote Control Tool

3. Enter a unique name for the Remote Control tool in the Name/Icon Label field.
4. Click Create & Close to create the Remote Control Tool and return to the
Policy Region window.


Creating Tivoli Administrators
In our case study scenario, Tivoli Administrators have two distinct roles. One role,
assigned to systems administrators, gives Remote Control access to any target
in the company. A second role, assigned to technical support operators, gives
Remote Control access only to user workstations and servers with no sensitive
data. Therefore, we will create the following two Tivoli Administrators:
system_admin
technical_support

To create a new Tivoli administrator:
1. Open the Tivoli Desktop, right-click the Administrators icon, and select Create
Administrator to display the Create Administrator window.

Figure 24 Creating an Administrator

2. Specify the label and accounts for the administrator:
a. In the Administrator Name/Icon Label box, type the administrator name.


b. In the User Login Name text box, type the user login name (not a numeric
user ID). The user login name must be a valid login name on all machines.
c. In the Group Name text box, type the group name (not a numeric group
ID). The group name can be a user login map in the form $map_name.
This text box is used for operations performed on UNIX managed nodes.
For our case study, we leave it blank.

Figure 25 Create Administrator window

3. Click Set TMR Roles to set the following Tivoli Region roles for the
administrator in order to use the Remote Control features:
– Admin
– User


Figure 26 Set TMR Roles window

4. Click Change & Close to save your changes and return to the Create
Administrator window.
5. Click Set Logins to display the Set Login Names window where you can list
the login names under which the administrator will run Tivoli operations from
either the Tivoli Desktop or the command line.
The user account name must be in one of the following formats:
– username
– username@ManagedNode
– domainusername
– domainusername@ManagedNode
– kerberos-name:realm
In our case study scenario, we add the following account names
– sysadmin for the system_admin Tivoli Administrator
– support for the technical_support Tivoli Administrator


Figure 27 Set Login Names

6. Click Set & Close to save your changes and return to the Create
Administrator window shown in Figure 25 on page 36.
7. Click Set Resource Roles to associate the IBM Tivoli Remote Control roles
to the Tivoli Administrators. In our case, we created two administrators, the
technical_support and the system_admin. Now we have to assign Remote
Control roles to them.
Setting roles at the Policy Region level enables you to perform the
appropriate IBM Tivoli Remote Control tasks within the specified Policy
Region. These privileges do not extend to other Policy Regions. These
privileges do apply to any sub-Policy Region associated with the Policy
Region where the IBM Tivoli Remote Control roles have been defined.
If the sub-Policy Region was created before you assigned new privileges to its
parent Policy Region, the sub-Policy Region does not inherit these privileges.
The IBM Tivoli Remote Control roles are required in the Policy Region where
the Target systems are defined. In addition to these roles, the Admin role is
required where the RemoteControl managed resource is defined.
Table 6 and Table 7 on page 39 show the activities available to administrators
of Tivoli Remote Control and the role associated with each activity.

Table 6 Controller - Role X Activity
Activity Role in the Controller’s Policy Region
Use any Tivoli Remote Control action Admin


Table 7 Target - Role X Activity
Activity Role in the Target’s Policy Region
Monitor a target remote_monitor

Monitor and control a target remote_control

Run commands on a target using the remote_probe
wrcmdpcr command

Reboot a target remote_reboot

Exchange text messages with a target remote_chat

Send files to a target from the controller remote_ft_send

Receive files from a target remote_ft_receive

We want the system_admin Tivoli Administrator to have full control over all of
the Targets in all Policy Regions, so we assign all of the IBM Tivoli Remote
Control roles to them.


Figure 28 Setting Resource Roles: system_admin

Select the Policy Regions one by one, and add all Remote Control roles to its
Current Roles list. Click Change before you select another Policy Region.
Do the same for the technical_support Tivoli Administrator, except exclude
the pr.RemoteControl.SVR and pr.RemoteControl.WebSVR Policy Regions.
These Policy Regions contain Targets that technical_support administrators
are not supposed to control. On the Policy Region hosting the company’s
servers with no sensitive data, such as printer servers
(pr.RemoteControl.PrinterSVR), grant the remote_monitor and
remote_reboot roles to the technical_support administrators.


Figure 29 Set Resource Roles: technical_support

8. Click Change & Close to save your changes and return to the Create
Administrator window.
9. Click Create & Close to create the new administrator and return to the
Administrators window. An icon for the new administrator is displayed in the
Administrators window, showin in Figure 30 on page 42.


Figure 30 Administrator created

Customizing the Remote Control Policy
The Remote Control Policy controls the behavior and appearance of the Remote
Control Tool. The default Remote Control policy is named RemoteControl_PDO.
When you create a RemoteControl managed resource in a policy region, the
default policy is automatically associated to the managed resource and
consequently to the Remote Control Tool of that Policy Region.

We will modify the behavior of the Remote Control Tool to obey the rules that
were assigned by the company to the systems administrators and technical
support operators. As described in “Case study scenario overview” on page 10,
the rules are:
System administrators have full control of all machines in the organization.
The only restrictions are for user workstations. The system administrator can
access these workstations only when the user grants access.
Technical support operators may not access remotely the company’s domain
controllers and file servers. Technical support operators can access the
workstations of the users only when the user grants access. However,
technical support operators may have remote access to certain servers, such
as printer servers, without any permission restrictions.

To change the default settings of the Remote Control Tool in a Policy Region you
should not modify the RemoteControl_PDO default Policy, but create a new
Policy. You may also create as many different Remote Control Policies as the
number of Remote Control Tool in different Policy Regions.


The method used is:
1. Create a copy of the default Policy.
2. Modify the values of some of its methods to comply with the desired rules.
3. Assign the new Policy to the RemoteControl managed resource of the Policy
Region where the Remote Control Tool that you want to customize resides.

Creating a copy of the Remote Control default Policy
To create a copy of the Remote Control default Policy:
.setup_env.cmd
2. Issue the wcrtpol command as follows:
wcrtpol -d RemoteControl <New_Policy_Name> RemoteControl_PDO
where <New_Policy_Name> is the name of the new Policy to be created, for
example, to create three different Policies:
wcrtpol -d RemoteControl UserWS_Pol RemoteControl_PDO
wcrtpol -d RemoteControl TSPS_Pol RemoteControl_PDO
wcrtpol -d RemoteControl SASVR_Pol RemoteControl_PDO

Customizing the contents of a Policy Method
To customize the value of some methods of the RemoteControl default policy
perform the following operations:
environment.
2. Issue the wgetpolm command as follows:
wgetpolm -d RemoteControl <New_Policy_Name> <policy_method_name> > outfile
where:
<New_Policy_Name> is the new Policy name, <policy_method_name> is a
particular rule that applies to the desired behavior, and outfile is a
temporary text file.
Using the UserWS_Pol Policy as an example, we want the Target machine
user to be able to accept the Remote Control session initiated by the Tivoli
Administrator. In this case we have to modify the rc_def_timeout_op policy
method. The wgetpolm command would be the following:
wgetpolm -d RemoteControl UserWS_Pol rc_def_timeout_op > UserWS_Pol.txt
The UserWS_Pol.txt file content would be similar to Example 1 on page 44.


Example 1 Default rc_def_timeout_op policy method
#!/bin/sh
#
# Default policy method for Remote Control Policy Region
# This policy method determines whether or not to start a session if
# the target user does not respond within the grace period.
#
# Possible values:
# ENABLED Starts the session if the grace period times out.
# DISABLED Cancels the session if the grace period times out.
#
# Default value: DISABLED
#
# If the value has the suffix -locked, it cannot be reset in
# the Edit Settings dialog.
#
# (For example: echo "ENABLED-locked")
#

echo "DISABLED"

exit 0

We have to change the echo line to ENABLE-lock, which means the Target
machine user must accept the Remote Control session to establish it.
The modified UserWS_Pol.txt file would be similar to Example 2.

Example 2 Modified rc_def_timeout_op policy method
#!/bin/sh
#
# Default policy method for Remote Control Policy Region
# This policy method determines whether or not to start a session if
# the target user does not respond within the grace period.
#
# Possible values:
# ENABLED Starts the session if the grace period times out.
# DISABLED Cancels the session if the grace period times out.
#
# Default value: DISABLED
#
# If the value has the suffix -locked, it cannot be reset in
# the Edit Settings dialog.
#
# (For example: echo "ENABLED-locked")
#


echo "DISABLED-locked"

exit 0

3. Issue the wputpolm command as follows:
wputpolm -d RemoteControl <New_Policy_Name> <policy_method_name> < outfile
where:
<New_Policy_Name> is the new Policy name, <policy_method_name> is a
particular rule that applies to the desired behavior, and outfile is a
temporary text file.
Using the UserWS_Pol Policy as an example, the wputpolm command would
be the following:
wgetpolm -d RemoteControl UserWS_Pol rc_def_timeout_op > UserWS_Pol.txt
4. The first three steps of this procedure must be performed to all the Remote
Control Tools defined in the environment, whenever necessary.

Assigning the new default Policy
To assign the new default Policy to the RemoteControl managed resource of a
Policy Region you can use either the Tivoli desktop or the command line, which
we show here:
environment.
2. Issue the wsetpr command as follows:
wgetpolm -d <New_Policy_Name> RemoteControl @PolicyRegion:<Region_Name>
where:
<New_Policy_Name> is the new Policy name and <Region_name> specifies the
Policy Region where the new default Policy is assigned.
Using the our case study scenario’s new policies as examples, the wsetpr
command would be:
wsetpr -d UserWS_Pol RemoteControl @PolicyRegion:pr.RemoteControl.UserWS
wsetpr -d TSPS_Pol RemoteControl @PolicyRegion:pr.RemoteControl.PrinterSVR
wsetpr -d SASVR_Pol RemoteControl @PolicyRegion:pr.RemoteControl.SVR

Creating Desktop for Administrators
The technical_support and system_admin Tivoli Administrators must have in
their Tivoli Desktops access to the corresponding Policy Regions.


For the system_admin Tivoli Administrator, they are:
pr.RC.SA
pr.RC.UserWS
pr.RemoteControl

For the technical_support Tivoli Administrator, they are:
pr.RC.TS
pr.RC.UserWS
pr.RemoteControl

To assign the Policy Regions to technical_support and system_admin Tivoli
Administrators:
1. Log on to the Tivoli Desktop using the Administrator user ID.
2. Double-click the Administrators icon.
3. Double-click the related Tivoli Administrator group (system_admin and
technical_support groups in our case study) to open the designated Tivoli
Desktop of the Tivoli Administrator group.
4. Drag and drop the respective Policy Regions to the Tivoli Desktop.
5. Exit the Tivoli Desktop.
6. To verify the Tivoli Administrators Desktop, log in to the Tivoli Desktop using
the Tivoli Administrator user ID. (In our example, system_admin.) The Tivoli
Desktop will be similar to Figure 31 on page 47.


Figure 31 Tivoli Desktop for system_admin

Testing Remote Control features
In this section we put into practice the main IBM Tivoli Remote Control features
using the case study scenario and the technical_support Tivoli Administrator to
illustrate the examples:
The technical support operator is working on a help desk ticket and needs to:
– Remote-control a user’s workstation
– Interact with the user during the Remote Control session via chat
– Transfer some files to the user’s workstation
– Reboot the user’s workstation


Remote Control
Logging on to the Tivoli environment with the Tivoli Desktop using the
technical_support Tivoli Administrator results in the Tivoli Desktop shown in
Figure 32.

Figure 32 Tivoli Desktop for technical_support

At this point:
The technical support operator opens the pr.RC.UserWS Policy Region, and
double-clicks the rc_UserWS icon to start Remote Control Tool.
The Controller interface appears, as shown in Figure 33 on page 49.


Figure 33 Remote Control controller interface

The Targets field shows all of the user workstations, and in Actions field
shows all of the Actions that can be performed on the Targets.
The technical support operator clicks the appropriate workstation and Edit
Settings to open the Edit Settings dialog, as seen in Figure 34 on page 50.


Figure 34 rc_UserWS: Edit Settings

As you see, the Grace period, the Proceed if timeout, and the State
Change on Target fields are grayed-out. They are fixed values that you
cannot change due to the fact that we applied the -locked tag to these
variables in the Remote Control Policy file. Click Close to return to the
Controller window.
The technical support operator clicks Remote Control from the Actions list
then Run to start the session.
A window pops up on the Target user’s workstation, indicating that a Remote
Control session is being requested. The user can choose to accept the
remote session or not.

Figure 35 Remote session: waiting for acceptance


If the user does not accept the session, or the grace period passes, the
technical support operator receives a notification, as shown in Figure 36 and
Figure 37.

Figure 36 No action in the grace period

Figure 37 Remote session rejected by the user

If the user accepts the session, the session window in Figure 38 on page 52
opens.
To exit the session select File -> Exit from the menu.


Figure 38 Remote Control session

When a session is established, the dialog shown in Figure 39 appears on the
Target machine. Through this dialog, a Target machine user can change the
Remote Control session or terminate it.

Figure 39 Remote Control Target interface


Chat
Chat can be used to interact with the user to obtain additional information about
the problem:
The technical support operator opens a chat session by selecting Chat from
the Actions list on the Remote Control Tool window, then Run to start the chat
session.

When running chat for the first time for that particular workstation, a JRE1.3
installation window appears. Press Yes to proceed with JRE installation.

Figure 40 JRE 1.3 installation window

After the JRE is installed on the Target machine, a chat session window pops up.

Figure 41 Chat interface


File transfer
Use file transfer to update files on a user’s workstation:
The technical support operator selects File Transfer from the Actions list on
the Remote Control Tool window, and Run to start the file transfer session. If
the Target machine user accepts the request, the file transfer window shown
in Figure 42 appears.

Figure 42 File transfer window.

Now the technical support operator can copy any required file from the
Controller machine to the Target machine, and vice-versa.


Reboot
After transferring the required files, the Target machine can be rebooted, if
necessary, to make the changes effective:
The technical support operator selects Reboot from the Actions list on the
Remote Control window, then clicks Run. A dialog window pops up, asking for
confirmation, as shown in Figure 43.

Figure 43 Confirm reboot

Conclusion
IBM Tivoli Remote Control offers highly robust, enterprise-scalable, secure
remote control functionality for organizations and enterprises of all sizes.

Although typically sold into the largest, most complex Global 5,000-type
customers, IBM Tivoli Remote Control also gives small and midsized enterprises
the ability to increase productivity and lower costs. When implemented
side-by-side with other Tivoli solutions, such as IBM Tivoli Configuration
Manager, the value proposition and ROI increase significantly. IT shops are able
to leverage the unified, integrated solutions to simplify the IT management
process and to bolster administrative ease-of-use.

With the latest version of IBM Tivoli Remote Control (version 3.8), small to
midsized businesses can leverage the new firewall traversal technologies and
data stream protection capabilities to extend their growing enterprise.

With this Redpaper, Customers can quickly implement and realize the
tremendous value and business advantages that IBM Tivoli Remote Control
brings. Running either independently or integrated with IBM Tivoli Configuration
Manager, IBM Tivoli Remote Control enables customers to support their
employees and productive resources by quickly deploying an enterprise-scale,
robust desktop management solution.


Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.

© Copyright IBM Corp. 2003. All rights reserved. 57

This document created or updated on May 29, 2003.

Send us your comments in one of the following ways: ®
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. JN9B Building 003 Internal Zip 2834, 11400 Burnet Road
Austin, Texas 78758-3493 U.S.A.

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX® Redbooks™ Tivoli®
IBM® Redbooks (logo) ™ Tivoli Enterprise™
ibm.com® S/390®
OS/2® SP1®

The following terms are trademarks of other companies:

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United
States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.

C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure
Electronic Transaction LLC.

Other company, product, and service names may be trademarks or service marks of others.


Implementing ibm tivoli remote control in small to midsized enviroments redp3663

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie Implementing ibm tivoli remote control in small to midsized enviroments redp3663

Ähnlich wie Implementing ibm tivoli remote control in small to midsized enviroments redp3663 (20)

Mehr von Banking at Ho Chi Minh city

Mehr von Banking at Ho Chi Minh city (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Implementing ibm tivoli remote control in small to midsized enviroments redp3663