You are on page 1of 164

Implementing Tivoli Remote Control in Large

Enterprises
Harley Allkins, Shreedhar Atre, Donal Fallon, Fred Plassman, Clifford Vaughan

International Technical Support Organization


http://www.redbooks.ibm.com

SG24-5125-00

SG24-5125-00

International Technical Support Organization


Implementing Tivoli Remote Control in Large
Enterprises
May 1999

Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix C, Special Notices on page 127.

First Edition (May 1999)


This edition applies to Tivoli Remote Control Version 3.6 for use with the Windows NT 4.0 Operating
System
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. OSJB Building 003 Internal Zip 2834
11400 Burnet Road
Austin, Texas 78758-3493
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 1999. All rights reserved
Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
The Team That Wrote This Redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Chapter 1. Tivoli Remote Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 How Remote Control Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Security Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Authorization Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Default Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 Securing the Remote Control Controller Defaults. . . . . . . . . . . . . . . . . 2
1.6.1 Remote Control Policy Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6.2 Security Conscious Environment Modifications . . . . . . . . . . . . . . . 6
Chapter 2. Check Point Software Firewall Technologies, Inc. .
2.1 FireWall-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 VPN-1 SecuRemote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 FloodGate-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

. .9
. .9
. 10
. 11

Chapter 3. Defining Target Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13


3.1 Default Target List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Changing Remote Control Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Using the rc_def_define Policy Method. . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Using the rc_def_checkinterp Policy Method . . . . . . . . . . . . . . . . . . . 16
3.5 Dynamic Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5.1 Using the rc_def_targets Policy Method . . . . . . . . . . . . . . . . . . . 17
3.5.2 Using the rc_def_filter_mode Policy Method . . . . . . . . . . . . . . . . 18
3.5.3 Using the rc_def_polfilter_mode Policy Method . . . . . . . . . . . . . 20
3.5.4 Using the rc_def_uncheckedlist Policy Method . . . . . . . . . . . . . . 22
3.6 Static Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.1 Using the rc_def_targets Policy Method . . . . . . . . . . . . . . . . . . . 25
3.6.2 Using the rc_def_uncheckedlist Policy Method . . . . . . . . . . . . . . 26
3.6.3 Building a List Using Tasks - An Example. . . . . . . . . . . . . . . . . . 26
Chapter 4. Remote Control with Firewalls . . . . . . . . . . . . . . . . . . . . . . 35
4.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 TME Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 Daemons/Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Copyright IBM Corp. 1999

iii

4.2.2 Communications Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36


4.2.3 Types of Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.4 Ports and Port Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Remote Control Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Firewall Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.6 Firewall-1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6.1 Management Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.6.2 Defining Firewall-1 Rule Base. . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.7 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7.1 Scenario 1 - Firewall Between EP Gateway and Endpoint . . . . . 49
4.7.2 Scenario 2 - EP Gateway and Endpoint Outside Firewall . . . . . . 53
4.7.3 Scenario 3 - TMR Server Outside the Firewall . . . . . . . . . . . . . . 55
4.7.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.8 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Chapter 5. Remote Access Scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 An Introduction to VPN and SecuRemote . . . . . . . . . . . . . . . . . . . . . . 59
5.1.1 Encryption Schemes Supported by FireWall-1 . . . . . . . . . . . . . . 59
5.1.2 Validation of IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 Implementing Secure Remote for Basic Access . . . . . . . . . . . . . . . . . 60
5.2.1 SecuRemote Client Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.2 Creating Authentication IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.3 Modifying the Firewall-1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.4 Investigating the SecuRemote Environment . . . . . . . . . . . . . . . . 65
5.3 Permitting Remote Control Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3.1 SecuRemote as a Remote Control Target . . . . . . . . . . . . . . . . . 69
5.3.2 SecuRemote as a Remote Control Controller . . . . . . . . . . . . . . . 71
5.3.3 Starting Controller from the Desktop with SecuRemote . . . . . . . 73
Chapter 6. Bandwidth Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2.1 Understanding TCP Characteristics . . . . . . . . . . . . . . . . . . . . . . 76
6.3 FloodGate-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.3.1 FloodGate-1 Technology Overview . . . . . . . . . . . . . . . . . . . . . . . 77
6.3.2 Installation of FloodGate-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Chapter 7. Tivoli Enterprise Console (TEC) Integration . . . . . . . . . . . . 81
7.1 Event Logging and Audit Trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.2 TEC Environment Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.3 Configuration and Deployment of TEC Profiles . . . . . . . . . . . . . . . . . . 84
7.3.1 Understanding and Modifying the TEC NT Adapter. . . . . . . . . . . 85
iv

Implementing Tivoli Remote Control In Large Enterprises

7.3.2 The Event Classes and BAROC Files . . . . . . . . . . . . . . . .


7.3.3 Creating a Rule Base . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.4 Creating Event Groups . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Managing Remote Control with TEC. . . . . . . . . . . . . . . . . . . . .
7.4.1 Initiating an Event on a Remote Control Failure . . . . . . . .
7.4.2 Configuring TEC to Automatically Start Remote Control . .

.
.
.
.
.
.

..
..
..
..
..
..

.
.
.
.
.
.

. 89
. 90
. 93
. 94
. 94
. 97

Chapter 8. Web Browser Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 101


8.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.1.1 Operating System Requirements . . . . . . . . . . . . . . . . . . . . . . . 101
8.1.2 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.2 Administrator Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.3 Installing Tivoli Web Access for Remote Control . . . . . . . . . . . . . . . 102
8.4 Using Tivoli Web Access for Remote Control . . . . . . . . . . . . . . . . . . 103
8.4.1 Running on Node with Remote Control Controller . . . . . . . . . . . 103
8.4.2 Running on Node without Remote Control Controller . . . . . . . . 107
8.4.3 Changing the Target List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Chapter 9. Installation Tips for Endpoints . . . . . . . . . . . . . . . . . . . . . 111
9.1 Using Tivoli Software Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.1.1 Update REGILOG.INI for Windows NT Endpoint. . . . . . . . . . . . 111
9.1.2 Step-by-Step Installation Procedure . . . . . . . . . . . . . . . . . . . . . 112
9.2 Using InstallShield to Install on Windows Endpoints . . . . . . . . . . . . . 114
9.2.1 Response Files to Use with InstallShield . . . . . . . . . . . . . . . . . 115
9.2.2 The SETUP.INI File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
9.2.3 Starting the InstallShield Install. . . . . . . . . . . . . . . . . . . . . . . . . 116
9.2.4 Checking for Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
9.3 Using Diskettes to Install on Windows Endpoints . . . . . . . . . . . . . . . 118
9.4 Unattended Install on OS/2 Endpoints . . . . . . . . . . . . . . . . . . . . . . . 119
9.4.1 Starting the Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9.5 Using Diskettes to Install on OS/2 Endpoints . . . . . . . . . . . . . . . . . . 119
Appendix A. GetNewEPs.sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Appendix B. SETUP.ISS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Appendix C. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Appendix D. Related Publications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
D.1 International Technical Support Organization Publications . . . . . . . . . . 131
D.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
D.3 Other Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
D.4 Other References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135


How IBM Employees Can Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . 135
How Customers Can Get ITSO Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . 136
IBM Redbook Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
List of Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

vi

Implementing Tivoli Remote Control In Large Enterprises

Figures
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.

Remote Control Start Session Panel Using Defaults. . . . . . . . . . . . . . . . . . 3


List Policy Methods - wlspolm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Get Policy Method - wgetpolm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
List Policy Objects - wlspol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Remote Control Start Session Dialog Panel . . . . . . . . . . . . . . . . . . . . . . . . 8
rc_def_define Policy Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
rc_def_checkinterp Policy Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
rc_def_targets Policy Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Display All Nodes in All Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
rc_def_filter_mode Policy Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Display Endpoint Nodes in myregion Region. . . . . . . . . . . . . . . . . . . . . . . 20
rc_def_polfilter_mode Policy Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Display Endpoint Nodes in a Selected Region . . . . . . . . . . . . . . . . . . . . . 22
rc_def_uncheckedlist Policy Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Display All Endpoints in TMR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
rc_def_targets Using a File for the List of Targets . . . . . . . . . . . . . . . . . . . 25
Specific Target List in rc_def_targets Policy Method . . . . . . . . . . . . . . . . . 25
Target List File rclist.txt to be Used by rc_def_targets. . . . . . . . . . . . . . . . 26
Target List File rclist.txt Used by rc_def_uncheckedlist Policy Method . . . 26
Check if Remote Control Installed - GetRCs.sh. . . . . . . . . . . . . . . . . . . . . 27
Create Endpoint Remote Control Targets List - GetNewEPs.SH . . . . . . . 30
Remote Control Session Initialization without RC Gateway . . . . . . . . . . . 41
Remote Control Session Initialization with RC Gateway . . . . . . . . . . . . . . 41
Endpoint External to the RC Gateway and TMR Server . . . . . . . . . . . . . . 43
Endpoint and Gateway External to TMR Server . . . . . . . . . . . . . . . . . . . . 44
Endpoint, Gateway, and TMR Server All External . . . . . . . . . . . . . . . . . . . 45
The Service Manager - Add Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Full Logging of Events to the Log Viewer . . . . . . . . . . . . . . . . . . . . . . . . . 48
Log Viewer - Initial Endpoint Logon Attempt Failure . . . . . . . . . . . . . . . . . 50
Rule 1 - UDP AATiv_HighRange_9494 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Rule 2 - TCP AATivGW_HighRange_9494 . . . . . . . . . . . . . . . . . . . . . . . . 51
Rule 3 - TCP AATiv_HighRange_30K-35K . . . . . . . . . . . . . . . . . . . . . . . . 51
Rules 4 and 5 - TCP AATiv_HighRange_2501 . . . . . . . . . . . . . . . . . . . . . 52
Rule Base Required for RC in Internal Gateway Scenario . . . . . . . . . . . . 53
Security Policy with an External Gateway.. . . . . . . . . . . . . . . . . . . . . . . . . 54
Security Policy External TMR Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
SecuRemote Status Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Rules Required for Site Registration.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
FireWall-1 Rules Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Client Encrypt Action Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Copyright IBM Corp. 1999

vii

41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.

viii

NetBIOS Session Decryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66


Log Showing Successful Connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Rules Limiting Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Rules 2 and 4 - AATivEP_All_9495 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Remote Control to a SecuRemote Client - Rule Base . . . . . . . . . . . . . . . . 71
Remote Control to a SecuRemote Client - Log . . . . . . . . . . . . . . . . . . . . . 71
SecuRemote Controller Started with the WRC Command - Rule Base. . . 72
SecuRemote Controller Started with the WRC Command - Log . . . . . . . . 73
Rules Required to Start the Tivoli Desktop . . . . . . . . . . . . . . . . . . . . . . . . 73
FloodGate-1 Component Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Windows NT Event Log - Session Started and Ended. . . . . . . . . . . . . . . . 82
Windows NT Event Log - Session Failed. . . . . . . . . . . . . . . . . . . . . . . . . . 82
TECAD_NT.FMT Additions for Remote Control . . . . . . . . . . . . . . . . . . . . 87
TEC BAROC File - TECRC.baroc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
New Rule Base Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Enterprise Console Event Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Stop and Start Remote Control - BounceRC.CMD . . . . . . . . . . . . . . . . . . 95
Run Remote Control Task - BounceIP.sh . . . . . . . . . . . . . . . . . . . . . . . . . 96
Restart Remote Control on Failure - BncRC_on_Fail.rls . . . . . . . . . . . . . . 97
Automatic Start Remote Control - StartRCSess.cmd . . . . . . . . . . . . . . . . 98
Start Remote Control on Disk Full - RC_on_DiskFull.rls . . . . . . . . . . . . . . 99
Tivoli Remote Control Web Access - First Panel . . . . . . . . . . . . . . . . . . . 104
Tivoli Remote Control Web Access - Second Panel . . . . . . . . . . . . . . . . 105
Tivoli Remote Control Web Access - Third Panel . . . . . . . . . . . . . . . . . . 106
Tivoli Remote Web Access with Target List. . . . . . . . . . . . . . . . . . . . . . . 108
Add Registry Key to REGILOG.INI - Remote Control . . . . . . . . . . . . . . . 112
Add Registry Key to REGILOG.INI - Remote Control Controller Only. . . 112
SETUP.ISS for RC Target Install on NT 4.0 Endpoint . . . . . . . . . . . . . . . 116
Remote Control Install Batch File - RCINST.BAT . . . . . . . . . . . . . . . . . . 116

Implementing Tivoli Remote Control In Large Enterprises

Tables
1. Summary of TME Network Port Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2. Services Used Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Copyright IBM Corp. 1999

ix

Implementing Tivoli Remote Control In Large Enterprises

Preface
System administrators and help desk personnel sometimes need access to
remote PCs in order to resolve problems and assist users with important
business applications. Tivoli Remote Control allows a system administrator to
control the keyboard and mouse input and monitor the display output of a remote
PC running Windows NT, Windows 95, Windows 3.1, or OS/2. The administrator
can also monitor a PC and allow a user to maintain control of the system. Tivoli
Remote Control can even reboot a remote PC.
This redbook describes the functions of the Tivoli Remote Control, how these
functions provide benefits for customers, and practical suggestions for planning,
creating, and managing Tivoli Remote Control in a large enterprise environment.

The Team That Wrote This Redbook


This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization, Austin Center.
Fred Plassman is a Senior Software Engineer at the International Technical
Support Organization, Austin Center. He writes extensively and teaches IBM
classes worldwide on all areas of Tivoli system management, particularly
deployment management. Before joining the ITSO in July 1996, Fred worked
in the Software Distribution Support Team, Advanced Technical Support, IBM
North America.
Harley Allkins is an Advisory IT Specialist in Johannesburg, South Africa. He
has four years of experience in client-server implementations, two of which
have been focused on the implementation and support of systems
management products and disciplines.
Shreedhar Atre is an IT Specialist in Mumbai, India. He has six years of
experience in the hardware support field, and four years in network design
and implementation. His areas of expertise include implementing network
management solutions on AIX platforms.
Donal Fallon is a Technical Support Specialist in Dublin, Ireland. He has two
years of experience in the client-server field. He holds a degree in Physics
and Chemistry from Trinity College, Dublin. His areas of expertise include the
deployment of manufacturing and office PC support infrastructure.
Clifford Vaughan is a Tivoli Senior Software Engineer in the United States.
He has over 10 years of experience in software Customer support. His areas
of expertise include problem determination and problem source identification

Copyright IBM Corp. 1999

xi

(PD/PSI) in the client-server environment. He is currently performing Level 2


support on Tivoli Remote Control.
Thanks to the following people for their invaluable contributions to this
project:
Paul Fern, Bart Jacob, Vasfi Gucer, Steve Gardner
International Technical Support Organization, Austin Center @
www.redbooks.ibm.com

Luca Loiodice, Riccardo Colella, Antonio Perrone


Tivoli Systems, Austin, Texas @ www.tivoli.com
Sean Costello, Neil Gehani, Upesh Patel
Check Point Software Technologies, Inc. @ www.checkpoint.com

Comments Welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your
comments about this or other redbooks in one of the following ways:
Fax the evaluation form found in ITSO Redbook Evaluation on page 149
to the fax number shown on the form.
Use the electronic evaluation form found on the Redbooks Web sites:
For Internet users
For IBM Intranet users

http://www.redbooks.ibm.com
http://w3.itso.ibm.com

Send us a note at the following address:


redbook@us.ibm.com

xii

Implementing Tivoli Remote Control In Large Enterprises

Chapter 1. Tivoli Remote Control


A system administrator often needs to manage PCs in locations that are
distant from the administrators office. These PCs may be on a different floor,
in a different building, or even in a distant city. If a problem on one of these
PCs requires attention, the administrator traditionally has two options. One is
to try to resolve the problem over the telephone. However, the chances of
miscommunication might be great if the user is exasperated or is describing a
symptom that is not related to the real problem. The other is to go to the PC
to determine the problem, but this is often impractical.
Remote Control allows an administrator to control the keyboard and mouse
input and monitor the display output of a remote PC. In addition, the
administrator can monitor a PC while allowing the user to maintain control of
their system; Remote Control can also be used to reboot a remote PC.

1.1 How Remote Control Works


Remote Control contains the following components: a server, a gateway, a
controller, and a target.
The Remote Control server allows you to start up the Remote Control session
by using a Tivoli desktop.
A Remote Control gateway is an optional machine that handles
communication between controllers and targets.
A Remote Control controller is a machine that can monitor or take over and
operate the keyboard, mouse, and display of another workstation.
A Remote Control target is a machine that the controller monitors or acts
upon.

1.2 Security Issues


Any product that provides remote access to the display, keyboard, and files of
another system can be considered a security risk. However, the Tivoli
Framework allows Remote Control to be configured to match the security
model that an organization has. You can permit all administrators to perform
any function that Remote Control provides, or a senior administrator can edit
the default policy to restrict which functions junior administrators can perform.
Also, through default policy, you can determine whether administrators can

Copyright IBM Corp. 1999

control or reboot a system without prompting the end user (which is useful if
the end user is absent), or only if the end user allows it.

1.3 Authorization Roles


Remote Control provides unique authorization roles that are not hierarchical.
Therefore, an administrator must be explicitly assigned each of these roles to
perform the tasks associated with the roles.
remote_control enables the administrator to monitor the actions, to control
the mouse actions, and to enter keyboard data on a remote workstation.
remote_monitor enables the administrator to monitor the actions on a
remote workstation.
remote_probe enables the administrator to run commands on a target
from the command line interface.
remote_boot enables the administrator to restart a remote workstation.

1.4 Default Policy


Remote Control provides default policy methods that define the default
settings on the Remote Control dialog.
The product is configured to be as flexible as possible for the administrator. If
your site security policy requires a more stringent definition of access, you
can edit any of the policy methods. A list of the default policy methods is
found in the Tivoli Remote Control Users Guide Version Version 3.6,
GC31-8437.

1.5 Notices
Remote Control generates a notice in the TME 10 Remote Control notice
group for each operation attempted. The notice indicates what action was
taken and the outcome of the operation. Actions performed during a remote
control session are not logged, but the fact that a session was successfully
initiated is, as well as the administrator responsible for the session.

1.6 Securing the Remote Control Controller Defaults.


When starting the Tivoli Remote Control controller, the user is prompted with
a list of targets which can be controlled. Once a target is selected and the

Implementing Tivoli Remote Control In Large Enterprises

user presses Start Session, the user is prompted with the Start Session
dialogue box as shown in Figure 1 on page 3.

Figure 1. Remote Control Start Session Panel Using Defaults

Here, the Remote Control user has the option of selecting which mode of
control to implement, how much warning time (Grace Period) to give the user
at the target, and whether to allow the user at the target to break the session
(State Change on Target).
In some environments, such as an out-sourced help desk, it is not advisable
for personnel to be able to take control of a target and not allow the user at
the target to override this action. In a banking environment, for example, it
might be necessary for the user at the target to first give permission to the
controller to connect before allowing them to do so. Alternatively, it is
sometimes more practical to alter the defaults that appear on this panel to
settings that would better suit a production environment, instead of expecting
Remote Control users to continuously change the settings each time they
start a session.
This can be done by modifying the Remote Control policy methods.

Tivoli Remote Control

1.6.1 Remote Control Policy Methods


A list of the methods that belong to a managed resource that can be modified
can be obtained by executing the wlspolm command. We used this command
to obtain a list of the policy methods for Remote Control, and this output is
shown in Figure 2 on page 4.

c:\> wlspolm -d RemoteControl


rc_def_command
rc_def_filter_mode
rc_def_grace_time
rc_def_timeout_op
rc_def_alt_t
rc_def_backgrnd
rc_def_checkinterp
rc_def_color
rc_def_comp
rc_def_define
rc_def_gw
rc_def_polfilter_mode
rc_def_ports
rc_def_rate
rc_def_targets
rc_def_uncheckedlist

Figure 2. List Policy Methods - wlspolm

In this case, RemoteControl is the name of the predefined managed resource


that Remote Control uses.
The function of each of these policy methods is detailed in the Tivoli Remote
Control Users Guide Version 3.6, GC31-8437, and some are covered in
Chapter 1 of this book. The current setting for any of these values can be
viewed using the wgetpolm command. Figure 3 on page 5 shows an example
of the output of the wgetpolm command.

Implementing Tivoli Remote Control In Large Enterprises

C:\>wgetpolm -d RemoteControl RemoteControl_PDO rc_def_command


#!/bin/sh
#
# Default policy method for Remote Control Command
#
# This method prints the command which the controller will
# perform on the target. The choices are:
#
#
"monitor"
#
"controla"
#
"controlm"
#
"reboot"
#
#XXXX-locked Use the XXX setting, and the user cannot change it
#
(eg: "monitor-locked")
#
echo "monitor"
exit 0

Figure 3. Get Policy Method - wgetpolm

The default policy method that is installed when Remote Control is installed is
called RemoteControl_PDO. You can obtain a list of all the default Remote
Control policy objects that are defined by executing the following command:
wlspol -d RemoteControl.

To confirm the current default policy object for a particular Remote Control
tool (icon) in a particular policy region, open the policy region where that
Remote Control tool was defined. Select the Remote Control tool (one left
mouse click), select Properties on the Action Bar, then select Managed
Resource Policies... in the drop down menu. On the Managed Resource
Policies panel, select RemoteControl in the Managed Resources list. The
default policy object for this instance of the Remote Control tool is in the
Default Policy drop down box entry field. Click on the Close button to exit
this panel.
It is good practice to leave the RemoteControl_PDO policy object unchanged,
and only make modifications to policies which have been copied from this
default. To copy a policy object, execute the following command:
wcrtpol -d RemoteControl Restricted RemoteControl_PDO

We elected to call our new policy Restricted. Executing wlspol again will
show the new policy in the class for Remote Control, as shown in Figure 4.

Tivoli Remote Control

c:\>wlspol RemoteControl
RemoteControl_PDO
Restricted.

Figure 4. List Policy Objects - wlspol

Just as one would use the wgetpolm command to view the contents of a policy
method, the command wputpolm replaces the current content. The simplest
method of using these commands to make changes is to follow the process
listed below. To illustrate this point, we are modifying the rc_def_command
policy method.
Execute:
wgetpolm -d RemoteControl Restricted rc_def_command >
c:\temp\AFileName

which pipes the contents to a temporary file.


Edit the output file (in this case c:\temp\AFileName) using a text editor
to alter the content as required, then save the file.
Store the new policy methods using the command:
wputpolm -d RemoteControl Restricted rc_def_command <
c:\temp\AFileName

Confirm that the change has taken place as required by viewing the
output of wgetpolm again.

1.6.2 Security Conscious Environment Modifications


The content of each policy method is a bash script file which runs and then
returns one of a set of predefined outputs back to Remote Control once it has
run. This means that the scripts can be intelligent and return different values
depending on the hostname of the local machine, the time of day, and almost
any other environment setting one could probe. For the purposes of our
exercise, we assumed an environment that was cautious about giving easy
access to unauthorized personnel while allowing the support personnel to
gain access to the target when necessary. We decided to keep the scripts
simple and immediately returned the desired value to Remote Control.
In order for our environment to work efficiently, and without compromising on
security we decided on the following changes:
We changed the contents of rc_def_command from the default of monitor to
controlm. We felt that this was the option that would be used most often.
It would start in monitor mode, so as not to immediately take control from

Implementing Tivoli Remote Control In Large Enterprises

the user, but give the Remote Control user the opportunity to take control
once the session has been established.
We wanted to give our users more time to respond to the initialization of
the Remote Control session and cancel it if they were busy with a
confidential document. At the same time, however, if no one was at the
workstation to cancel the session, the Remote Control user would then
automatically have access. This would allow support personnel to control
a machine after hours. To do this, we altered rc_def_grace_time to be
15-locked and rc_def_timeout_op to be ENABLED. The Remote Control
User is not able to modify the default timeout as we have specified it to be
locked.
One can improve on this by writing a script which gives different output
depending on the time of day that this command is run. For instance,
during office hours, rc_def_grace_time could be set to 15-locked, and the
rc_def_timeout_op could be DISABLED-locked. After hours, the user
could be given the option to modify these settings on the Start Session
dialogue.
Finally, we modified rc_def_alt_t. This is by default DISABLED, and we
changed it to read ENABLED-locked. Any user at a Remote Control
target can then terminate a Remote Control session, and this setting
cannot be overridden by the user at the Remote Control controller.
Once the policy methods have been modified, the policy object must be
activated and this is done using the command
wsetpr -d Restricted RemoteControl ostmr-region.

The new start session dialogue box is shown in Figure 5 on page 8. Notice
that the Grace Period drop-down-list and the State Change on Target
check-box are both lowlighted, or grayed out, and cannot be modified.

Tivoli Remote Control

Figure 5. Remote Control Start Session Dialog Panel

Implementing Tivoli Remote Control In Large Enterprises

Chapter 2. Check Point Software Firewall Technologies, Inc.


Check Point Software Technologies Ltd. provides secure enterprise
networking solutions through an integrated architecture that includes network
security, traffic control, and IP address management. Check Point is the
worldwide leader in secure enterprise networking solutions. Check Point
solutions enable customers to implement centralized, policy-based
management with enterprise-wide deployment. For this residency, we used
FireWall-1, VPN-1 SecuRemote, and FloodGate-1.

2.1 FireWall-1
Internet technology has changed not only the way organizations do business,
but also the way they approach network security. The dynamic nature of
todays corporate networks means that they are no longer defined by physical
boundaries, but instead by enterprise-wide security policies. To be effective,
these policies must include a broad range of security services that govern
access to network resources while protecting these same resources from
both internal and external threats.
A complete enterprise security solution must provide the ability to:
Grant selective network access to authorized remote and corporate users
Authenticate network users with strong authentication techniques before
granting access to sensitive corporate data
Ensure the privacy and integrity of communications over untrusted public
networks like the Internet
Provide content security at the gateway to screen malicious content such
as viruses and malevolent Java/ActiveX applets
Detect network attacks and misuse in real time and respond automatically
to defeat an attack
Protect internal network addressing schemes and conserve IP addresses
Ensure high availability to network resources and applications
Deliver detailed logging and accounting information on all communication
attempts
With its Enterprise Security Management product family, Check Point
Software Technologies offers a comprehensive set of solutions that meet
these demanding requirements. Check Points FireWall-1/VPN-1 security
suites enable all functionality to be deployed and managed with a single

Copyright IBM Corp. 1999

enterprise-wide security policy for straightforward management and


administration.
Enterprise security solutions are unified by Check Points [Open Platform for
Secure Enterprise Connectivity (OPSEC) policy management framework
which provides central integration, configuration and management for Check
Point products as well as other third-party security applications. Only Check
Point provides organizations with the ability to define a single, integrated
security policy that can be distributed across multiple gateways and managed
remotely from anywhere on the enterprise network. There is never any need
to individually reconfigure each security gateway.
All of Check Points security solutions are built on Stateful Inspection, the de
facto standard for network security that was invented and patented by Check
Point. Stateful Inspection provides full application-layer awareness without
requiring a separate proxy for every Internet service and protocol. This
provides unparalleled performance, scalability, and the ability to support new
and custom applications and services quickly and easily.

2.2 VPN-1 SecuRemote


Virtual Private Networks (VPNs) provide a powerful means of protecting the
privacy and integrity of business communications over the Internet.
Organizations now have a viable alternative to expensive leased lines when
connecting private networks. However, VPNs between private networks do
not provide secure connectivity to the growing number of remote users with
Internet access. A true enterprise-wide VPN must extend to include all
individuals requiring access to corporate network resources over the Internet,
including sales professionals, telecommuters, and trusted business partners.
SecuRemote provides flexible VPN support for remote and mobile users
and is an integral component of Check Point Software Technologies
comprehensive VPN solution. Using SecuRemote, Windows 95 and Windows
NT users can connect to their corporate network through dial-up Internet
connections and establish secure VPN sessions to access sensitive network
resources. Once established, the VPN will transparently encrypt and
authenticate business-critical data traveling between the corporate network
and the user's laptop or desktop PC to protect against eavesdropping and
malicious data tampering.
The SecuRemote software installs on any Windows desktop or laptop PC and
supports all IP-based network communications. It interfaces with existing
network adapters and TCP/IP network stacks for maximum compatibility.

10

Implementing Tivoli Remote Control In Large Enterprises

And, because it supports high-performance IP-layer encryption, SecuRemote


does not require any change or modification to any applications. In addition to
supporting dynamic IP addressing for dial-up communications, SecuRemote
can also be deployed in LAN environments using fixed IP addresses. With
this level of flexibility, SecuRemote is the ideal VPN solution for both Internet
and intranet deployments.
SecuRemote supports public key infrastructures utilizing X.509 digital
certificates and Entrust Certificate Authorities (CA). As an Entrust Ready
application, SecuRemote can request and validate Entrust certificates on a
user's behalf to initiate an IKE key negotiation with a FireWall-1 gateway.
Remote VPN users can now benefit from the improved security and
scalability offered by public key infrastructures.
To enhance user-level security for PKI deployments, SecuRemote supports
the Public Key Cryptography Standard (PKCS) #11 interface for accessing
information contained in hardware or software tokens. PKCS #11 compatible
tokens provide secure storage of private keys used for data encryption and
digital signatures.
SecuRemote works seamlessly with Check Point's market-leading FireWall-1
enterprise security suite. It is easy to incorporate secure remote access as
part of an overall security policy by adding a single rule to the FireWall-1 Rule
Base. And, because SecuRemote establishes VPN tunnels directly with the
FireWall-1 gateway, all elements of an enterprise security policy are strictly
enforced, including access control, user authentication, and logging.

2.3 FloodGate-1
Organizations worldwide are using the Internet to support mission-critical
business applications. At the same time, corporate intranets and extranets
are being deployed at an unprecedented rate to deliver valuable information
resources to both internal and external users. Although the benefits of
Internet technologies are undeniable, many corporations are suffering from
the inevitable network congestion on both Internet and intranet links resulting
from the flood of IP-based traffic.
Even during moderate levels of network congestion, users experience a
degradation in the performance and availability of critical Internet services.
Without the ability to control traffic flow at all network access points,
corporations are unable to direct limited bandwidth resources to
revenue-generating applications. Important services or users may be starved
of bandwidth by non-critical Internet or intranet traffic.

Check Point Software Firewall Technologies, Inc.

11

Check Point FloodGate-1 solves the network congestion problem by


delivering a policy based, enterprise-wide, bandwidth management solution.
By dynamically managing the overall mix of communications traffic,
FloodGate-1 minimizes congestion on oversubscribed Internet and intranet
links, allowing network administrators to allocate limited bandwidth resources
based on criticality or merit. In addition to increasing network efficiency and
improving user experience, FloodGate-1 minimizes the need to add costly
bandwidth.
Bandwidth management policies are defined using the FloodGate-1 intuitive
graphical user interface (GUI). The management policy consists of traffic
rules that define bandwidth privileges for user-defined traffic classes.
FloodGate-1 is designed as a client/server application and allows a single
enterprise policy to be defined and automatically distributed to multiple
FloodGate-1 modules.
FloodGate-1 uniquely delivers total bandwidth management by controlling the
bandwidth usage of entire classes of traffic, not just individual connections.
Organizations can now allocate valuable bandwidth resources among
multiple classes of traffic, such as critical applications or important groups of
users.
FloodGate-1 provides powerful control criteria to actively manage bandwidth
consumption by traffic class. In addition to basic bandwidth guarantees and
limits, all network traffic can be controlled using weighted priorities that
allocate bandwidth based on relative merit or importance. Unlike absolute
priorities, weighted prioritization ensures that all traffic is delivered and not
starved of bandwidth.
A real-time traffic monitor is integrated with FloodGate-1 to analyze network
congestion and monitor bandwidth allocation. Comprehensive information is
provided on all inbound and outbound network traffic to define custom
bandwidth management policies and to monitor the effect of existing policies.
This powerful feedback mechanism allows precise adjustments of bandwidth
policies to meet specific management requirements.
FloodGate-1 is a stand-alone bandwidth management solution that can be
used with any Internet firewall. When integrated with FireWall-1, however,
organizations can support their existing VPN deployments and provide
flexible address translation. No other bandwidth management product offers
this level of advanced functionality.

12

Implementing Tivoli Remote Control In Large Enterprises

Chapter 3. Defining Target Lists


Tivoli Remote Control (RC) provides different ways to define the list of target
system names. This section explains how to take advantage of dynamic and
static lists to make the help desk analyst more efficient. Lists can also be
periodically generated, extracting information from the TMR server, Tivoli
Inventory databases, or by the use of Tivoli tasks.
In very large enterprises of over 5000 endpoints, it is recommended to use
static lists to minimize the time necessary to gather the desired list of targets.
This chapter discusses the Remote Control policy methods that may be
changed to generate different target lists within the same enterprise.

3.1 Default Target List


The default target list is generated by Remote Control policy methods.
By changing the appropriate Remote Control policy methods, a list of targets
can be displayed containing anywhere from one or more specific targets, to
all targets across all TMRs in a large enterprise.
The Remote Control policy methods that affect the contents of the target list
are:
rc_def_define

Determines whether the user can filter the target


list, and which other policy method(s) generate the
list.

rc_def_targets

Allows the user to define a list of targets. It has


effect only if rc_def_define is set to
DefinableTargetList.

rc_def_filter_mode

Determines which target types to display in the


list. It has effect only if rc_def_define is set to
FilteredList.

rc_def_polfilter_mode

Determines whether to display the target list for a


specific region, or all regions. it has effect only if
rc_def_define is set to FilteredList.

rc_def_uncheckedlist

Allows the user to define a list of targets. It has


effect only if rc_def_define is set to
UncheckedList.

rc_def_checkinterp

Determines whether to exclude UNIX clients from


the target list. It has no effect if rc_def_define is
set to UncheckedList.

Copyright IBM Corp. 1999

13

3.2 Changing Remote Control Policy


The default policy installed with Remote Control server is
RemoteControl_PDO. This default policy should NOT be modified. A new
policy should be created using the Tivoli command wcrtpol. You may create
as many different Remote Control policies as you have instances of the
Remote Control Tool (icon) in different policy regions. An example of creating
a new Remote Control default policy is:
wcrtpol -d RemoteControl RC_Alt_policy RemoteControl_PDO

The above example creates a new Remote Control policy named


RC_Alt_policy.
To modify the new policy, use the Tivoli commands wgetpolm and wputpolm.
Here is an example of changing rc_def_define in RC_Alt_policy from
FilteredList to UncheckedList:
wgetpolm -d RemoteControl RC_Alt_policy rc_def_define >temp.txt

Edit temp.txt to change FilteredList to UncheckedList and save the change.


wputpolm -d RemoteControl RC_Alt_policy rc_def_define < temp.txt

Please refer to the Tivoli Framework Reference Manual Version 3.6,


SC31-8434, for more detail on the wcrtpol, wgetpolm, and wputpolm
commands.
In order to use the new, modified, RC policy, you need to associate it with an
instance of the Remote Control tool. On the Tivoli Desktop, open the policy
region containing the instance of the Remote Control tool with which you will
associate RC_Alt_policy. Select the Remote Control tool(one left click), select
Properties on the Action Bar, then select Managed Resource Policies... in
the drop down menu. On the Managed Resource Policies panel, select
RemoteControl in the Managed Resources list. Select RC_Alt_policy in the
Default Policy drop down box. Click on the Set & Close button. Now, when
this instance of Remote Control is used, RC policy will be controlled by the
methods in RC_Alt_policy instead of RemoteControl_PDO.
Since there may be several instances of the Remote Control tool, each
instance that is in a different policy region may use a different Remote Control
policy object to obtain the target list. This way, each separate Remote Control
user could be restricted to a particular set of targets, or have access to all
Remote Control targets.

14

Implementing Tivoli Remote Control In Large Enterprises

3.3 Using the rc_def_define Policy Method


The rc_def_define policy method determines whether the user can filter the
target list, and which other policy method(s) generates the list.
The default setting for this method is echo "DefinableTargetList".
This statement allows the target list to be filtered, and it can be modified at
run time.

#!/bin/sh
#
# Default policy method for Remote Control Define Target list
#
# This method authorizes the user to define a new targets list.
#
# Possible modes are:
#
DefinableTargetList
(can filter the list)
#
FilteredList
(cannot filter the list)
#
UncheckedList
(the list is displayed w/o any validation)
#
#
DefinableTargetList-locked(the user cannot change the setting)
#
echo "DefinableTargetList"
exit 0

Figure 6. rc_def_define Policy Method

Change rc_def_define to DefinableTargetList in order to use rc_def_targets


to define the list of targets.
Change rc_def_define to FilteredList to use rc_def_filter_mode in order to
define the types of targets, and rc_def_polfilter_mode to filter the list for a
specific region or all regions.
Change rc_def_define to UncheckedList to use rc_def_uncheckedlist in
order to define the list of targets. Remote Control does NOT perform a
validation of the targets before listing them when Uncheckedlist is in effect.
A validation is performed after the target is selected.

Defining Target Lists

15

3.4 Using the rc_def_checkinterp Policy Method


The rc_def_checkinterp policy method determines whether to exclude UNIX
clients from the target list.
The default setting for this method is echo "Yes".
This method has no effect if rc_def_define is set to UncheckedList.

#!/bin/sh
#
# Default policy method for Remote Control
#
# This method allows to set another GUI Performance tuning :
# you can choose if avoid or not from the Endpoint list the UNIX
# ManagedNode
# Possible modes are:
#
Yes the check on each ManagedNode interp is done
#
No
no check is executed
#
echo "Yes"
exit 0

Figure 7. rc_def_checkinterp Policy Method

Introduced in patches 2.1.1-RCL-0002 and 3.6-RCL-0002, the


rc_def_checkinterp policy method determines whether to exclude UNIX
clients from the list of targets. When set to Yes, a check is performed and the
UNIX clients are excluded from the list. When set to No, the UNIX clients will
be displayed in the list. Setting this value to No improves the performance of
displaying the Remote Control panel.

3.5 Dynamic Lists


Dynamic list implementation obtains all of the specified target types from the
TMR, or from all interconnected TMRs in a multiple TMR enterprise. The list
will be built each time Remote Control is launched.

16

Implementing Tivoli Remote Control In Large Enterprises

3.5.1 Using the rc_def_targets Policy Method


The rc_def_targets policy method allows the user to define a list of targets.
This method has effect only if rc_def_define is set to DefinableTargetList.
The default setting for this method is echo "default-list". This statement lists
all the non-UNIX clients in the TMR.

#!/bin/sh
# This method is to set a list of the possible RemoteControl targets
# Input values: i.e. echo "endpoint-label" list or
# echo "default-list" if you want to display all the machines.
echo "default-list"
exit 0
Figure 8. rc_def_targets Policy Method

To list only specific node types, change the statement in rc_def_targets to


wgetallinst node_type, where node_type is one of the following:
ManagedNode
PCManagedNode
Endpoint
NetWareManagedSite

To list all managed nodes and all endpoints, you replace


echo "default-list"

with:
wgetallinst ManagedNode
wgetallinst Endpoint

Figure 9 on page 18 is an example of the resulting target list when


rc_def_targets is set to echo "default-list".

Defining Target Lists

17

Figure 9. Display All Nodes in All Regions

3.5.2 Using the rc_def_filter_mode Policy Method


The rc_def_filter policy method determines which target types to display in
the list. This method has effect only if rc_def_define is set to FilteredList.
The default setting for this method is echo "all". This statement lists all nodes
for all node types.

18

Implementing Tivoli Remote Control In Large Enterprises

#!/bin/sh
#
# Default policy method for Remote Control Policy Region
#
# This method prints the filtering mode for the list of possible
# targets.
#
# Possible modes are:
#
node
(show only managed nodes)
#
pcnode
(show only PC managed nodes)
#
nwnode
(show only netware clients)
#
epnode
(show only LCF Endpoints)
#
all
(show all)
#
#
XXX-locked(show XXX only, and the user cannot change the setting)
#
(eg. "pcnode-locked")
echo "all"
exit 0

Figure 10. rc_def_filter_mode Policy Method

Similar to the rc_def_targets policy method, the rc_def_filter_mode policy


method can be set to display the different target types individually, as a mix,
or as all types. This method is normally used together with
rc_def_polfilter_mode. To display only specific node types, change echo
"all" to one or more of the following:
echo
echo
echo
echo

"node"
"pcnode"
"nwnode"
"epnode"

Figure 11 on page 20 is an example of the resulting target list when


rc_def_filter_mode is set to echo "epnode" and rc_def_polfilter_mode is set to
echo "myregion".

Defining Target Lists

19

Figure 11. Display Endpoint Nodes in myregion Region

3.5.3 Using the rc_def_polfilter_mode Policy Method


The rc_def_polfilter policy method determines whether to display the target
list for a specific region or all regions. This method is normally used together
with the rc_def_filter_mode policy method.
This method has effect only if rc_def_define is set to FilteredList.
The default setting for this method is echo "myregion". This statement lists all
selected nodes and node types in the region containing the Remote Control
tool being used.

20

Implementing Tivoli Remote Control In Large Enterprises

#!/bin/sh
#
# Default policy method for Remote Control Policy Region
#
# This method prints the filtering mode for the list of
# possible targets .
#
# Possible modes are:
#
region (show according the policy choosen)
#
myregion (show according the policy region where is the
#
tool)
#
all
(show all)
#
#
XXX-locked(show XXX only, and the user cannot change the
#
setting)
#
(eg. "pcnode-locked")
echo "myregion"
exit 0
Figure 12. rc_def_polfilter_mode Policy Method

The rc_def_polfilter policy method can also be set to display nodes in all
regions or in a specific region. To allow the user to select a region from the
Policy Region Names list, change echo "myregion" to echo "region". To
display nodes in all regions, change echo "myregion" to echo "all". The types
of nodes displayed will be the types that are set in rc_def_filter_mode.
Figure 13 on page 22 is an example of the resulting target list when
rc_def_filter_mode is set to echo "epnode" and rc_def_polfilter_mode is set
to echo "region".

Defining Target Lists

21

Figure 13. Display Endpoint Nodes in a Selected Region

For this figure, if you select a different region from the policy region names
list, you get a different list of endpoints in the Endpoint Name list.

3.5.4 Using the rc_def_uncheckedlist Policy Method


The rc_def_uncheckedlist policy method allows the user to define a list of
targets. This method has effect only if rc_def_define is set to
UncheckedList.
The default setting for this method is:
wgetallinst ManagedNode
wgetallinst PCManagedNode

These statements will list all managed nodes and all PC managed nodes in
the TMR.

22

Implementing Tivoli Remote Control In Large Enterprises

Note

When rc_def_define is set to Uncheckedlist, Remote Control does NOT


perform a validation of the targets before listing them. A validation is
performed after the target is selected.

#!/bin/sh
# This method is to set a list of the possible RemoteControl targets
# Input values follow this naming convention :
# ManagedNode
echo "label"
# PCManagedNode:
echo "label"
# NetWare Clientes
echo "NetWareClientName@NetWareManagedSiteName"
# Endpoint
echo "label+"
# Default value: wgetallinst ManagedNode wgetallinst PCManagedNode
wgetallinst
ManagedNode
wgetallinst PcManagedNode
exit 0
Figure 14. rc_def_uncheckedlist Policy Method

Introduced in patches 2.1.1-RCL-0002 and 3.6-RCL-0002, the


rc_def_uncheckedlist policy method is used to define the list of targets when
rc_def_define is set to UncheckedList. The list will be displayed without any
validation of the targets. A validation will be performed after the target is
selected.
Use this policy method the same as rc_def_targets. To display a list of all
endpoints in the TMR, change the default statement to:
wgetallinst Endpoint

Setting rc_def_define to UncheckedList and using rc_def_uncheckedlist to


define the list of targets improves the performance of displaying the Remote
Control panel.
Figure 15 on page 24 is an example of the resulting target list when
rc_def_uncheckedlist is set to wgetallinst Endpoint.

Defining Target Lists

23

Figure 15. Display All Endpoints in TMR

3.6 Static Lists


The static list implementation will display a specific list of targets. The
Remote Control policy method modified to display the specific list of targets
can have the list directly added to the policy method.
The policy methods will also accept a command, such as cat, followed by a
path and file name. The entries in the designated file must be in the form of
one target name per line.
These types of lists must be maintained manually or by a custom script to
update the target list periodically. The hostnames for these static lists may be
obtained from the TMR server database, from the Tivoli Inventory database
using queries and custom scripts, or by using tasks to build a file that will be
used by the Remote Control policy method.

24

Implementing Tivoli Remote Control In Large Enterprises

Since the target list can be very large, having the list in a file would make the
list easier to maintain without having to change the policy method over and
over. You can change rc_def_targets or rc_def_uncheckedlist to point to the
target list file by replacing the default statement in the policy method with
something like cat <drive:\path>\targetlist.txt where:
<drive:\path>

Is the drive and path to target list file on the Managed


Node running the instance of the Remote Control tool
being used.

targetlist.txt

Is the name of file containing the specific list of targets


to be displayed for this instance of the Remote Control
tool.

#!/bin/sh
# This method is to set a list of the possible RemoteControl targets
# Input values: i.e. echo "endpoint-label" list or
# echo "default-list" if you want to display all the machines.
cat c:\rctools\rclist.txt
exit 0
Figure 16. rc_def_targets Using a File for the List of Targets

3.6.1 Using the rc_def_targets Policy Method


To have the policy method contain the list of specific targets, change the
default statement in the rc_def_targets policy method to include one line in
the form echo"target_name" for each specific target, where target_name is the
hostname of the target.

.
echo "target01"

echo "target02"
echo "target03"
.
echo "target99"
exit 0

Figure 17. Specific Target List in rc_def_targets Policy Method

If the rc_def_targets policy method will get the list from a file (see Figure 16
on page 25), the entries in the file should be in the form of one target_name
per line as seen in Figure 17 on page 25.

Defining Target Lists

25

target01
target02
target03
.
.
.
target100

Figure 18. Target List File rclist.txt to be Used by rc_def_targets

3.6.2 Using the rc_def_uncheckedlist Policy Method


To have the policy method contain the list of specific targets, change the
default statement in the rc_def_uncheckedlist policy method to include one
line for each specific target, in the form echo "target_name" where target_name
is one of the following:
echo "target_name"

When the target is a managed node or PC managed node.


echo "target_name+"

When the target is an endpoint.


echo "target_name@NetWareManagedSite

When the target is a NetWare client.


If the rc_def_uncheckedlist policy method gets the list from a file (see Figure
16 on page 25), the entries in the file should be in the form of one
target_name per line as seen in Figure 19

MNtarget
PcMNtarget
EPTarget+
.
.
.

NWtarget@NetWareManagedSite

Figure 19. Target List File rclist.txt Used by rc_def_uncheckedlist Policy Method

3.6.3 Building a List Using Tasks - An Example


A relatively simple way to build a list of targets is through the use of Tivoli
tasks.

26

Implementing Tivoli Remote Control In Large Enterprises

In this example, two tasks were created. The first to query a list of nodes to
see if Remote Control target is installed. The second task starts the main
script which gathers a list of all endpoints in the TMR, compares the lists,
starts the first task to query only the list of new endpoints, creates a new list
of only endpoints with Remote Control installed, and appends them to the list
that will be used by one of the Remote Control policy methods. The list is
then sorted alphabetically and duplicates are removed.
The resulting list must be on the managed node where the Remote Control
tool was defined so the Remote Control policy method can read the list.
3.6.3.1 Create the Scripts
In our test TME, all nodes were running Windows NT 4.0 Server with SP3.
Your environment may be different; so, the scripts you need to create may be
different.
The first bash script, GetRCs.sh, checks each node in a temporary list for the
presence of the Remote Control target on each machine. You can view this
script in Figure 20 on page 27. This script is run by a task started from the
second script.
By searching for the presence of EQNRCMAI.EXE in directory
c:\Tivoli\Pcremote, the script determines if Remote Control has been installed
on each new endpoint. If the executable is found, a string made up of the
words VALIDRC and the hostname of the endpoint separated by a colon, is
passed to STDOUT. The inclusion of the string VALIDRC makes it easier to
identify the line in the final output that is collected from all the machines, as
you will see later.
If the executable is not found, then nothing is returned to STDOUT.

#!/bin/sh
# Determine if file eqnrcmai exists
# If it exists then return VALIDRC:hostname
#
dummyvar=hostname
if [ -f c:/tivoli/pcremote/eqnrcmai.exe ]
then
echo "VALIDRC:$dummyvar"
fi

Figure 20. Check if Remote Control Installed - GetRCs.sh

Defining Target Lists

27

We originally made use of a DOS batch script to do this, but the DOS script
failed because there is a limitation on the current version of the endpoints
which does not pass the output sent to STDOUT back to the executing task.
The second script, GetNewEPs.sh, is a bash shell script file and is listed in
Figure 21 on page 30. This script takes the output from GetRCs.sh and
extracts the list of machines which have returned data to STDOUT. This is
done by performing a search for the string VALIDRC. From this list, the script
drops the word VALIDRC as well as the colon, and only the hostnames
remain.
The output from the task contains comment lines, machine hostnames, error
output as well as the standard output from the various executions of
GetRCs.sh.
Each of the endpoints in the list is appended to the existing list of Remote
Control endpoint targets, and, if at least one new endpoint was added, the
endpoint gateway is restarted. The list of hostnames for endpoint targets
resides, in our case, in C:\RCTOOLS on the TMR server. The script then
proceeds to sort the full list of hostnames into alphabetical order which makes
locating a particular workstation much easier.
Now, we have a process to determine whether machines which previously did
not have Remote Control running now have it installed, and if so, to add these
machines to the total list of Remote Control workstations. A function was also
needed to analyze the list of existing endpoints, and determine which of
them, if any, do not appear in the list of Remote Control targets maintained in
C:\RCTOOLS. If there are such targets, then GetRCs.sh should be run
against only these, and not all nodes. Performing the process this way is
more efficient since it only runs on the machines when necessary.
The GetNewEPs.sh script performs this task by building a temporary list of all
the defined endpoints using the wgetallinst command, and then compares
this list against the list of Remote Control targets in C:\RCTOOLS. The script
extracts the names of the machines which do not exist in the temporary list,
but do exist in the C:\RCTOOLS list. This task simultaneously removes
machines which are no longer defined in the TMR from the list of Remote
Control Targets, while adding any new RC Targets to the list.
#!/bin/sh
# Create list of all endpoints with Remote Control Target
# installed to be used by RC policy method rc_def_targets
RCList=c:/rctools/list.txt
# List of all EP targets for rc_def_targets
WLookList=c:/rctools/temp/WlookList.txt # List of all EPS
TL=c:/rctools/temp/tl.txt
# List for nodes in WLooklist and not in RCList

28

Implementing Tivoli Remote Control In Large Enterprises

TL1=c:/rctools/temp/tl1.txt
GetRCs=c:/rctools/temp/getrcs.txt
rm
rm
rm
rm

-f
-f
-f
-f

# created for temporary purpose


# Output file from wruntask command

$WLookList
$TL
$TL1
$GetRCs

echo "Building a list of defined Endpoints"


wgetallinst Endpoint > $WLookList
# obtain list of all endpoints
echo "
...done"
# If a list of targets exists, this checks
if [ -f $RCList ]
#
then
echo "Obtaining list of new EPs"
LIST=cat $WLookList
for i in $LIST
#
do
grep -ix "$i" $RCList > /dev/null
RC=$?
if [ $RC -ne 0 ]
then
echo $i >> $TL
#
fi
done

for new possible targets and adds them


check if the RCList list is there

check for machines in WLookList and not RCList

if the node is not in RCList write to TL

LIST=cat $RCList
echo "Building list of valid EPs in RC list"
for i in $LIST
# check the RCList content against WLookList
do
grep -ix "$i" $WLookList > /dev/null
RC=$?
if [ $RC -eq 0 ]
# if the node is in both lists then write it to TL1
then
echo $l >> $TL1
fi
done
if [ -f $TL1 ]
then
echo "Refreshing $RCList from $TL1" # Debug line
cat $TL1 > $RCList
# refresh RCList
fi
else
cat $WLookList > $TL
fi

# If no RCList list create node list

LIST=cat $TL
rtcmd=wruntask -t "Is RC Installed" -l "RC Tools" -m 30 -M parallel -o 15
for i in $LIST
do

# Build wruntask command line

Defining Target Lists

29

rtcmd="$rtcmd -h $i"
done
echo "Executing command $rtcmd"
echo $rtcmd > c:/rctools/go.cmd
c:/rctools/go.cmd > $GetRCs

# Query the list of possible new targets

echo "Retrieving RC Target names"


# Prune list to only those with RC installed
cat $GetRCs | grep VALIDRC | awk -F: {print $2} > $TL
cat $TL

# DEBUG

LIST=cat $TL
ctr=0
for i in $LIST
do
echo $i >> $RCList
echo "Added $i to list"
ctr=1
done

# If new Targets, add to the list

if [ $ctr -ne 0 ]
then
echo "Restarting the EP Gateway"
wgateway ostmr restart
# restart the EP Gateway after link
else
echo "No EP Gateway restart required"
fi
cat $RCList | sort -u > $TL1
cat $TL1 > $RCList
echo "$RCList created/updated"

# Sort RCList
# Refresh the list

Figure 21. Create Endpoint Remote Control Targets List - GetNewEPs.SH

For the scripts that we have described above to work correctly, they must be
defined as tasks in the TME and within a Tivoli task library.
3.6.3.2 Create the Task Library
For our scenarios, we decided to put all Remote Control related tasks and
jobs into one task library. We created the task library, RC Tools, as follows:
wcrttlib "RC Tools" ostmr-region

From the GUI, you would do the following:


1. In the chosen policy region, select Create from the action bar.
2. In the pull down menu, select Task Library...
3. On the Create Task Library panel, enter the name of your task, then click
on the Create & Close button.

30

Implementing Tivoli Remote Control In Large Enterprises

3.6.3.3 Create the Tasks


Note

When the task is built, the script is immediately loaded from the source you
specified, and stored on the TMR database. This means that whenever you
make changes to the script, you must re-edit the task so that your new
script can be incorporated into the existing task.
Typically, we gave the tasks admin, senior, and super roles.
We found it was quicker to create the task from the command line, and we
created two separate tasks, one for each of the scripts. Here are the
commands that we used to create each task:
wcrttask -t "Get New EPs" -l "RC Tools" -r admin:senior:super -i
w32-ix86 ostmr c:\rctools\GetNewEPs.sh
wcrttask -t "Is RC Installed" -l "RC Tools" -r admin:senior:super -i
w32-ix86 ostmr c:\rctools\GetRCs.sh

From the GUI, you would do the following:


1. On the policy region panel, select your new task library icon, then right
click and select Create Task... from the pop-up menu.
2. On the Create Task panel, enter the Task Name for this task.
3. Select the appropriate platform from the Platforms Supported list.
This is the platform on which this task will run.
4. On the <Platform> Executable for Task pop-up, enter the hostname and
the full path for the task script. Then, click on the Set & Close button.
5. Select the appropriate roles from the Roles Required to Execute Task
list. For our tasks, we chose user, admin, senior, and super.
6. Click on the Create & Close button.
Repeat the above procedure for each task required.
3.6.3.4 Create the Job(s)
When you run a task, you are prompted for information such as which target it
must be run against. Since we wanted this process to be automated, we
created a job which has that information predefined. We created the job as
follows:
wcrtjob -j "Prep EP List" -l "RC Tools" -t "Get New EPs" -M parallel -o
05 -h ostmr -m 60

Defining Target Lists

31

From the GUI, do the following:


1. On the Task Library <Name> panel, right click on your task library icon
and select Create Job... from the pop-up menu.
2. On the Create Job panel, enter the Job Name, select the Task Name,
Execution Mode, Execution Targets, and any other options desired.
3. Click on Create & Close.
3.6.3.5 Schedule the Job
We then scheduled the jobs as follows:
wschedjob -n "Prep EP List" -L "RC Tools" -t 03/02/1999 23:30 -r
1 day

From the GUI, you would do:


1. Drag and drop the job icon onto the scheduler icon.
2. On the Add Schedule Job panel, fill in a Description, the Date and Time
the job is to run for the first time, and repeat options of Indefinitely and
every 1 day.
3. Click on Schedule Job & Close.
3.6.3.6 The Data Flow
Now that we have defined the scripts, tasks and job, and defined the
schedule, lets walk through the automated process.
At 23:30 every day, job "Prep EP List" runs the script GetNewEPs.sh. This
will generate a list of all the endpoints which are defined in the TMR. A
comparison is made to the list of Remote Control targets in C:\RCTOOLS.
Any target in the C:\RCTOOLS list that is not in the newly generated list is
removed, and any endpoint that is in the new list, but does not appear in the
C:\RCTOOLS list of Remote Control targets, is saved in a temporary file. Task
"Is RC Installed " is then started.
"Is RC Installed" executes GetRCs.sh on each endpoint in the temporary file,
and the output of this process is stored in C:\RCTOOLS\temp\getrcs.txt. For
each machine that has the Remote Control target installed, there will be one
line which reads
VALIDRC:Hostname

where Hostname is the name of that machine.


After GetRCs.sh completes, GetNewEPs.sh reads the output stored in
C:\RCTOOLS\temp\getrcs.txt and extracts the names of the new Remote

32

Implementing Tivoli Remote Control In Large Enterprises

Control targets. Each of these targets is added to the list of Remote Control
targets. If any new target was added to the list, the endpoint gateway is
restarted. The list is sorted alphabetically, any duplicates are removed, and
the file is now ready to be used by the Remote Control policy method
rc_def_targets or rc_def_uncheckedlist.
3.6.3.7 Potential Enhancements
A potential enhancement would build a list of Remote Control targets that
also have an application, such as Lotus Notes, installed.
Another task could be defined and started from the main script in the above
example to run against the list of new Remote Control targets, or all Remote
Control targets, in order to find which ones also have the application installed.
You could use Tivoli Inventory and extract the list of targets from a list
generated by an inventory scan that looked for all endpoints having Remote
Control and the particular application installed.

Defining Target Lists

33

34

Implementing Tivoli Remote Control In Large Enterprises

Chapter 4. Remote Control with Firewalls


This section explains how to customize Remote Control and Tivoli Framework
for communications through firewalls. Check Point FireWall-1 is used in this
section.
This chapter begins by explaining, in some detail, the communication
between the components of a TME installation. This information is taken from
the Framework Planning and Installation Guide Version 3.6 , SC31-8432. This
chapter goes on to describe the impact of firewalls to these communications
with regard to the relative placement of the firewall. Next, there is a
discussion of the Firewall-1 product and its configuration-based information
from the FireWall-1 user guides, Managing FireWall-1 Using the Windows
GUI, and Getting Started with FireWall-1 , which are product documentation.
We then go on to describe our installation of FireWall-1 and its configuration
in our different environments. Remote Control was successfully initiated
across these different environments.

4.1 Background
The growth in outsourcing of IT services has created virtual extensions of the
enterprises network. More and more, network users are having to traverse
public net-space in order to access the domains of their private network.
Network security is therefore an essential facet of every Tivoli Managed
Environment installation.
Firewalls are network access control devices that are used in securing the
network perimeter of an enterprise installation. The firewall ensures that all
communication between an enterprises network and the Internet conforms to
the enterprises security policy.
The use of firewalls in a Tivoli Management Region (TMR) creates security
issues during the deployment. Firewall placement obviously influences the
workings of the TME installation. Outsourcers use Remote Control to provide
IT outsourcing services to their customers. This chapter addresses these
issues with the implementation of FireWall-1 from Check Point Software
Technologies, Ltd. in a number of scenarios and the successful use of
Remote Control in each of the scenarios.

Copyright IBM Corp. 1999

35

4.2 TME Communications


Here we will look at the data transactions which need to occur between the
TME components for Remote Control to be initiated.

4.2.1 Daemons/Services
Our TME installation included the following types of network (listening)
servers:
The Object Dispatcher running on all managed nodes/gateways
The LCF gateway daemon running on managed nodes configured as
gateways
The TMA (LCF) daemon that runs on endpoints
The TME 10 Remote Control service that runs on targets and controllers

4.2.2 Communications Protocols


All TMR Servers, managed nodes/gateways, endpoints, and PC managed
nodes must have the TCP/IP protocol installed and configured on their
systems. This is a fixed requirement for the TME Framework Release 3.6 to
function.
There is support for IPX/SPX for NetWare managed nodes, but Tivoli does
not support operations between TMR servers and their IPX/SPX managed
nodes with firewalls.

4.2.3 Types of Communication


The various components of a TME (TMR server, managed nodes, PC
managed nodes and endpoints) establish different types of networking
connections between each other in an installation. Following this
inter-connectivity between the components is the key to understanding the
TME operation. This ability is vital in a firewall environment where maximizing
the security a firewall can provide is fundamental.
The different types of communications one can have between the
components are listed below:
4. Inter-ORB communications
This is the basic interaction mechanism between the different Object
Request Brokers (ORBs) in installation. The communication takes place
whenever requests from one managed node involve a remote method on
another managed node. This type of communication also manages

36

Implementing Tivoli Remote Control In Large Enterprises

request authorizations and resolves implementation details of requests.


So, TMR to EP gateway communications initiate using this mechanism. An
example of such a communication would be with the use of the odadmin
command.
This type of communication initiates a sustained TCP connection over
TCP port 94. These connections are therefore only disrupted when there
is network fault or when a Tivoli dispatcher has been restarted.
5. Inter-TMR communications
A Tivoli Management Region (TMR) is defined as a set of managed nodes
controlled by one TME server. In addition, multiple TMR servers can be
linked together to assist in making the managed enterprise scalable.
Resources can be exchanged to the extent that two or more TMRs can,
more or less, function like a single extended TMR.The communication
between two ORBs of two TMR servers is known as Inter-TMR
communication.
From a network perspective, it is the same as Inter-ORB communications.
Communication is therefore sustained and on port 94.
6. Inter-Object Messaging (IOM)
This is a communication channel that allows the exchange of bulk data
(>16K) between two object implementations.
The communication is not sustained (ephemeral) and runs on TCP ports in
the high range i.e. above 1023. Each time IOM communication is initiated,
a new port is chosen to handle the traffic. Once the bulk data is
exchanged, the connection gets torn down at both ends.
The ports used can be tuned using the odamin command as described in
the next section.
Applications that use IOM calls are Tivoli Software Distribution and Tivoli
Inventory.
7. Endpoint and Gateway Communications
The TME Framework interacts with the Tivoli Management Agent software
running on endpoints. An endpoint first communicates with its EP gateway
by issuing a UDP packet. Once the endpoint is authenticated, it then
communicates through TCP. The endpoint gateway by default listens on
port 9494 for Version 3.6 or port 9495 for version 3.6.1.
8. Remote Control Communications
This communications is represented during Remote Control of an endpoint
or managed node from an endpoint or managed node.

Remote Control with Firewalls

37

This is a sustained TCP connection on default port 2501 of the target.

4.2.4 Ports and Port Ranges


Table 1 on page 38 shows a summary of the port-specific information for the
types of communication previously mentioned.
Table 1. Summary of TME Network Port Usage

Type of Connection

TCP Server
Listening Port

TCP
ClientEphemeral
Port

Protocol/Duration

Inter-Orb

94

Either chosen from


selected range or
assigned by OS

TCP/Sustained.

Inter-TMR

94

Either chosen from


selected range or
assigned by OS

TCP/Sustained.

Inter-Object
Messaging

Either chosen from


selected range or
assigned by OS

Either chosen from


selected range or
assigned by OS

TCP/On-Demand
creation for
duration of bulk
data exchange.

Endpoint to
Gateway Initial
login

Gateway server
port chosen at
installation

Ephemeral port
provided by the OS
at the endpoint

UDP/Initial login to
determine
assigned gateway

Endpoint to
Gateway
Normal login or
upcalls

Gateway server
port chosen at
installation

Ephemeral port
chosen by OS at
the endpoint

TCP/Sustained.

Gateway to
Endpoint

Endpoint Server
chosen at
installation

Ephemeral port
chosen from the
selected port
range, or assigned
by OS at the
gateway

TCP/Sustained for
the duration of the
downcall or control
packets.

Remote Control

Chosen from a
selected range or
assigned by OS or
port 2501

Ephemeral port
chosen by OS

TCP/Sustained
during the period of
the session.

The table refers to there being TCP servers and TCP clients. These
references are made purely in the context of the request. Therefore, when an
object requests a transaction, it is a TCP client. The roles of the TCP server
and client have no bearing on the TME roles of the TME client and server. In

38

Implementing Tivoli Remote Control In Large Enterprises

other words, an ORB that is a server to one remote ORB can also invoke TCP
client requests on other remote ORBs, that is, the roles are interchangeable
and are determined by only one event - the request.
The object-call induced client ephemeral connections, the IOM channel
server, and IOM ephemeral client connections can be locally bound to a port
range. The port range selection in 3.6 is on a per-TMR basis, and 3.6.1
allows a per-managed-node basis, although this functionality will probably be
removed in future releases. The odadmin set_port_range command was used,
and we selected a port range of 30,000 - 35,000.

Note
TME installation uses network services such as rexec and trip (Tivolis
version of remote execution facility for Windows NT), which do not allow
port selection for connectivity. Thus, the firewall may need to open port 513
during installation. Once deployed, the port can be closed.

4.3 Network Address Translation (NAT)


With the explosion of the Internet, there has been a proliferation of internet
addresses. There are, however, not enough unique IP addresses to ensure
secure and accurate data transmission from site to site or company to
company.
As a result, Network Address Translation (NAT) devices are becoming a way
for companies to avoid IP address conflicts. NAT devices act as a conduit
between public and private address spaces. NAT devices typically create
virtual routers between the two spaces, along with the ability to transform IP
addresses and ports. By deploying NAT on private network boundaries,
unregistered hosts can be made visible on the internet. NAT devices,
therefore, also act as firewalls.
In a TME 10 environment, where thousands of endpoint clients may reside in
different domains of networks, a NAT device may be used to interconnect
these endpoints to their gateway and to the TMR server.
The following are requirements for NAT support in a TME 10 environment:

Remote Control with Firewalls

39

The NAT mappings from private to public addresses must be static (no
time slicing/sharing of public addresses).
The NAT device acts as a router for IP traffic between public and private
networks.
The NAT device must act as a proxy DNS server to ensure that client
systems can resolve hostname addresses on both sides of the NAT
address spaces.
Fully Qualified Host Names (FQHN) must be used for gateways when
providing login information.
The assigned gateways in the select_gateway_policy script must detail
the gateways FQHN along with its Object Identification (OID). This is done
by appending the FQHN to the OID, the strings being separated by the "|"
(pipe) symbol (no spaces between OID and pipe symbol).
Remote Control was not tested in a NAT environment.

4.4 Remote Control Components


Remote control consists of four components:
Remote Control Server
The Remote Control server allows you to start up an RC session. It must
be installed on a managed node. The server initiates the start target and
start controller methods.
Remote Control Gateway
The Remote Control gateway is an optional machine that handles the
communication between controllers and targets, but it must be a managed
node.
Remote Control Controller
A Remote Control controller is a machine that can monitor or take over
and operate the keyboard, mouse, and display of another workstation that
is a Remote Control target.
Remote Control Target
The Remote Control target is the machine that the Remote Control
controller monitors or acts upon.
The two figures below show the communications between the various
components when a Remote Control gateway is and is not used.

40

Implementing Tivoli Remote Control In Large Enterprises

tC

t
ge
ar
tT

St
ar

ar
St

on
tro
lle
r

Server

Controller

Target

Figure 22. Remote Control Session Initialization without RC Gateway

For performance reasons, you may want to avoid using the Remote Control
gateway. When a Remote Control gateway is used, all communications
between the Remote Control controller and the Remote Control target must
first pass through the Remote Control gateway. However, if you must run
Remote Control through a firewall, the Remote Control gateway may provide
you better security.

Gateway

Server

t
Star
et
Targ

Star
t Co
ntro
ller

Start Gateway

Target

Controller
Figure 23. Remote Control Session Initialization with RC Gateway

Remote Control with Firewalls

41

We have attempted to show the most secure setup for different firewall
placements.

4.5 Firewall Placement


One of the most important issues when using firewalls is their level of
transparency to user applications while maintaining the sanctity of the
network space they need to secure. Since the TME Framework is a system
management infrastructure, this level of transparency is influenced by the
placement of the firewall relative to the TME components.
For example, issues of the possible requirement of a Remote Control
gateway, as well as performance considerations, come into play when
considering firewall placement.
Another example of how firewall placement may affect transparency is where
policies are used to set ports, for example, the rc_def_ports policy method,
where a Remote Control controller can open a Remote Control target if the
firewall is configured to let communication through on that specific port.
However, if that same Remote Control controller attempts to open another
session with a different Remote Control target, it may fail if the firewall blocks
communications on any ports other than the one defined.

Note
The diagrams are merely a representation of the setup. In fact, Remote
Control server was always installed on the TMR server, and the TMR
server was always used as a Remote Control gateway. Also, Remote
Control target and Remote Control controller can be on machines on either
side of the firewall.

Possible firewall placements:


1. Where the endpoint is external to the Remote Control gateway and
TMR (and Remote Control) server.

42

Implementing Tivoli Remote Control In Large Enterprises

Controller or
Target Endpoint
TMR
Server
Remote Control
Controller

LAN
Router

Router

Firewall

LAN

Controller or
Target Endpoint

Figure 24. Endpoint External to the RC Gateway and TMR Server

where:
EP is an endpoint.
GW is a Remote Control gateway.
TMR is a TMR sever.
RC is the Remote Control server.
CT means that the box is both a Remote Control target and a Remote
Control controller.
Note

Tivoli does not recommend putting firewalls between Remote


Control gateways and endpoints in a security conscious
environment.
2. Where the endpoint and Remote Control gateway are external to the
TMR server.

Remote Control with Firewalls

43

External
Internal

Controller or
Target Endpoint

Controller or
Target Endpoint

Remote Control
Controller

LAN

Router

Router

Firewall

LAN

Remote Control
Gateway
Remote Control
Gateway

TMR
Server

Figure 25. Endpoint and Gateway External to TMR Server

Placing a firewall between a TMR server and a Remote Control gateway is


common practice because Remote Control gateways are frequently used
as MDIST repeaters.
3. Where a TMR server is deployed externally along with an endpoint and
a Remote Control gateway.

44

Implementing Tivoli Remote Control In Large Enterprises

TMR
Server
Remote Control
Gateway

LAN
Remote Control
Controller

Router
Controller or
Target Endpoint

Router

Firewall

TMR
Server

Remote Control
Controller

LAN
Controller or
Target Endpoint
Figure 26. Endpoint, Gateway, and TMR Server All External

This may be relevant to sites that have significant concerns about opening
inbound/outbound ports to a large number of external systems.

4.6 Firewall-1 Basic Concepts


When installed on a network gateway, the FireWall Module supervises traffic
passing between networks. The Firewall Module is inside the operating
system kernel between the data link and the network layers. Since the data
link is the actual network interface card, and the network link is the first layer
of the protocol stack, Firewall-1 is positioned at the lowest software layer.

Remote Control with Firewalls

45

Inspection at this layer ensures that the FireWall Module intercepts and
inspects all inbound and outbound packets on the network gateway. No
packet is processed by the higher protocol stack layers unless the FireWall
Module verifies that the packet complies with the security policy. The FireWall
Module examines IP addresses, port numbers, and any other information to
determine whether packets should be accepted in accordance with the
Security Policy.

4.6.1 Management Module


FireWall-1 consists of four management modules, the Rule Base, the
Network Object Manager, the Service Manager, and the Log Viewer.
A Rule Base is an ordered set of rules that defines a specific Security Policy.
A rule describes a communication in terms of its source, destination and
service, and specifies whether the communication should be accepted or
rejected, as well as whether it is to be logged.
The Network Object Manager defines the entities that are part of the Security
Policy. For example, specific workstations, servers, or networks and
sub-networks.
The Service Manager defines the services known to the system and used in
the Security Policy. New services can be defined by selecting the service type
and setting the services attributes.
In the Rule Base, the administrator can specify logging and alerting for any
communication attempt and view the results with the Log Viewer. The
standard format contains the source and destination of the communication,
the service attempted, the protocol used, time and date, source port action
taken, log and alert type, rule number, user, and the FireWall Module that
originated the log entry.

4.6.2 Defining Firewall-1 Rule Base


To start Firewall-1, select Start -> programs -> Firewall-1 and select
security policy. You will need to enter your administrative password
defined during the FireWall-1 installation .
1. First you must define your FireWall-1 network objects.
Select Manage -> Network Objects to bring up the Network Object
Manager. Click on new and define your internal and external networks. Next,
define the machine on which the Firewall-1 module resides, including its
network interfaces. This information can be found by using the ipconfig

46

Implementing Tivoli Remote Control In Large Enterprises

command from a DOS prompt in Windows NT. Continue to define any network
objects which you will be using in your FireWall-1 rule base.
2. Define any additional services.
Select Manage -> Services to bring up the Service Manager dialog box.
Choose the type of protocol you require, for example, TCP. Give the service a
name and fill in the destination and source port ranges.

Figure 27. The Service Manager - Add Object

3. Add and define rules.


To define your security policy through the FireWall-1 Rule Base, select Edit ->
Add Rule -> Top to add the default rule which drops everything while trying to
traverse the firewall. The configuration options include the packets source, the
packets destination, the service which it is using, and the way the packet is
tracked.

Remote Control with Firewalls

47

Note

Firewall-1 follows the premise that if an action is not expressly permitted, it


is prohibited. To enforce the principle, FW-1 implicitly adds a rule at the end
of the Rule Base that drops all communication attempts not described by
the other rules.
To view the packets being dropped in the Log Viewer, you must define how
the compliance of rules is to be tracked.
Right click on the box under the heading of Track to produce the screen as
shown in Figure 28 on page 48.

Figure 28. Full Logging of Events to the Log Viewer

To add the source to a rule, right-click on the box of the source field and click
add. This brings up the Network Object Manager. Choose from the selections
given.
4. Load the policy.

48

Implementing Tivoli Remote Control In Large Enterprises

Now, for the firewall to use your new settings, select Policy and then install.
Choose the module where you want this policy to be installed.
The Log Viewer is a very useful aid for seeing the communications that cross
the firewall between the TMRs components. Therefore, the Log Viewer was
opened (from the Window panel of Security Policy window) and was set to
refresh automatically.

4.7 Scenarios
The three different scenarios correspond to the implementation of the three
different firewall placements. Firewall-1 was used to implement as strict a
security policy as possible while still allowing Remote Control of machines on
both sides of the firewall. Remote Control controllers were placed on both
sides of the firewall, in the customer site (external), as well as in the
outsourser site (internal). Internal controllers represent customer machines
being supported remotely. External controllers represent the occasions where
a remote user has to take control of an internal machine.

4.7.1 Scenario 1 - Firewall Between EP Gateway and Endpoint


In Figure 25 on page 44, the firewall stands between the gateway and the
endpoint.
The endpoint service was engaged on the endpoint called CUSTOMER, and
the Firewall-1 log was viewed.
We know that an initial logon attempt by the endpoint generates packets
using UDP client connections to the gateway UDP server. (UDP is also used
during gateway fail-over/recovery modes.) So, we are expecting to see a
UDP packet being dropped by Firewall-1. The EP gateway listens by default
on port 9494 (port 9495 with 3.6.1) so this should be the destination port of
the packet. The endpoint ephemeral port is provided by the OS at the
endpoint; so, we expect to see a high source port.
This is what happens as we can see in Figure 29 on page 50.

Remote Control with Firewalls

49

Figure 29. Log Viewer - Initial Endpoint Logon Attempt Failure

Since we require a source port range representing all high ports from 1023 64000, and a destination port of 9494, this requirement becomes Rule 1 (see
Figure 30 on page 50).

Figure 30. Rule 1 - UDP AATiv_HighRange_9494

The hostname of the endpoint that tried to log in is VIKING. But VIKING could
represent any machine trying to log in, and, therefore, it is equivalent to
having the source as any.
What is required now is to define a rule which allows this packet through
while opening a minimal amount of ports. Packets are matched against a
rules Source, Destination, Service and Time. The first rule that succeeds in
matching the packet is applied. In order for the EP gateway to reply to the
initial logon attempt by the endpoint, the EP gateway needs to open a high
port and connects to 9494 on the Endpoint. This requirement becomes Rule
2.

50

Implementing Tivoli Remote Control In Large Enterprises

Figure 31. Rule 2 - TCP AATivGW_HighRange_9494

The response from the endpoint is on a high port and connects to port 9494
on the EP gateway. This response is covered by Rule 1.
Next, we started the Tivoli Desktop on the endpoint. The initial dialogue is
initiated from a high port to port 94, that is, Inter-ORB communications. For
the bulk data transfer, IOM communications are invoked from a high port on
the Endpoint to our selected range on the TMR server ports 30,000-35,000.
This requirement becomes Rule 3.

Figure 32. Rule 3 - TCP AATiv_HighRange_30K-35K

Now, all that is left is to start Remote Control. Once again, the machine that
initiates a transfer of data does so from a high port, and, with Remote

Remote Control with Firewalls

51

Control, we have a destination port of 2501. These requirements become


Rules 4 and 5.

Figure 33. Rules 4 and 5 - TCP AATiv_HighRange_2501

In Figure 34 on page 53, VIKING and OS1 are endpoints and OSTMR is the
TMR server, the EP gateway, and the Remote Control server.

52

Implementing Tivoli Remote Control In Large Enterprises

Figure 34. Rule Base Required for RC in Internal Gateway Scenario

This is a wide-open configuration. Rule 1 allows through packets from the


entire range of high ports to 9494 from any machine.
Putting the EP gateway on the same side of the firewall as its endpoints will
therefore reduce exposure. This is what we did in scenario 2.

4.7.2 Scenario 2 - EP Gateway and Endpoint Outside Firewall


The endpoint and gateway are on the same side of the firewall (external) with
the TMR server on the other (internal). See Figure 26 on page 45.
For Remote Control to function in this environment, the gateway must be able
to communicate with the TMR Server. This communication is allowed by Rule
1 (see Figure 30 on page 50).

Remote Control with Firewalls

53

Rule 2 (Figure 31 on page 51) allows a Remote Control session to be started


with an internal controller and an external target. An external controller and
internal target communication is allowed by Rule 3 (Figure 32 on page 51).
Rule 4 (Figure 33 on page 52) allows the initializing of the Tivoli Desktop.

Figure 35. Security Policy with an External Gateway.

Now, with the EP logins removed from the equation, Rule 1 has change
significantly. Now, we have ports opened in a much more restricted range
and, more importantly, between only two specified machines instead of any
machine.
We defined the Rule Base for Remote Control before that of the Tivoli
Desktop to highlight the fact that it is not always necessary to use the Tivoli
Desktop to initiate Remote Control.
In this case, we used the wrc command:
wrc RmtCtrl controlmr @Endpoint:montague @Endpoint:os1 -B:Y -C:Y -G:0 -Z:Y

54

Implementing Tivoli Remote Control In Large Enterprises

where RmtCtrl is the Remote Control object, controlmr specifies that the
control session initial state is monitor, montague is the Tivoli name of the
target, os1 is the Tivoli name of the controller, -B:Y disables background,
-C:Y limits to 16 colors, -G:0 specifies no grace period, and -Z:Y enables
compression.
RC control can also be initialized from a Web interface (see Chapter 8, Web
Browser Integration on page 101) which is especially useful where slow
network :s are involved.

4.7.3 Scenario 3 - TMR Server Outside the Firewall


This is where a TMR Server has been deployed outside the firewall. See
Figure 26 on page 45.
Now, only one external machine needs to communicate to one internal
system.
The second TMR server was set up external to the firewall. Both one-way and
two-way connections were initiated from the TMR inside the Firewall.
With the one-way communication, Remote Control is unidirectional, and, in
our case, with the controller in the internal site.
Rule 1 encompasses the Inter-TMR traffic. Rule 2 and Rule 3 are used for
Remote Control, opening up high range ports to port 2501.

Remote Control with Firewalls

55

Figure 36. Security Policy External TMR Server

Rule 1 is very tight and opens a minimized port range to a single port from
known machines.
Table 2. Services Used Definitions

Service/Type

Source Port

Dest. Port

Protocol

AATiv_HighRange_9494

High Port

9494

UDP

High Port

9494

TCP/Sustained

High Port

94

TCP

High Port

30000- 35000

TCP

30000 - 35000

94

TCP/Sustained

EP - GW Initial login

AATivGW_HighRange_9494
EP - GW Normal

AATiv_HighRange_94
Inter-Orb/TMR

AATiv_HighRange_30K-35K
IOM

AATiv_30K-35K_94
Inter-Orb/TMR

56

Implementing Tivoli Remote Control In Large Enterprises

Service/Type

Source Port

Dest. Port

Protocol

AATivGW_30K-35K_30K-35K
IOM

30000 - 35000

30000 - 35000

TCP

AATivRC_HighRange_2501

High Port

2501

TCP

RC

See Table 1 on page 38 for comparison.

4.7.4 Summary
With Scenario 1, there was massive port exposure. In Scenario 2, this
exposure was reduced by replacing endpoint to gateway trans-firewall
communications with gateway to TMR communications. Further reductions in
the port exposure occur when the need for opening the Tivoli Desktop is
removed, and further still where multiple TMRs are involved, leaving Remote
Control as the primary exposure.
When Remote Control is being initiated from the internal site, this opens a
high port range to 2501 on any machine. This is quite loose, but it is at least
initiated from the internal site.
When Remote Control is being initiated from the external site, Remote
Control is opening a range of ports on any machine to port 2501 on internally
available machines that make it wide open.

4.8 Recommendations
General recommendations include:
It is strongly recommended that, in a security conscious environment, the
endpoint gateway is on the same side of the firewall as its endpoints.
Where possible, do not use the Tivoli Desktop.
Where relevant, use multiple TMRs.
Specific recommendations for Remote Control are:
To reduce the risk from Rule 2 in Scenario 3 above, you should implement
the use of a Remote Control gateway. The Remote Control gateway would
be placed external to the Remote Control controllers. Instead of the need
to open ports to any destination, you need only open the range to the
Remote Control gateway which then handles all of the communications
between Remote control controller and Remote Control target. Use of the
Remote Control gateway could significantly reduce performance.

Remote Control with Firewalls

57

Controllers must be known, defined machines, especially where they are


external. This way rules can be defined for specific instances between
known controllers and targets. This would significantly reduce the risk as
seen in Rule 3, Scenario 3 above, where VIKING would represent a single
box instead of any machine.
If only one target needs to be taken over by a controller at a time, then
configure rc_def_ports to a port of choice. This will totally get rid of the
need to open a range of ports, thus securing your environment.
That RC server is located on the TMR.

58

Implementing Tivoli Remote Control In Large Enterprises

Chapter 5. Remote Access Scenario


In a corporate environment, it is a great benefit for employees to be able to
connect to their office applications and connect to the office network simply
by dialing into their Local Service Provider (LSP). This is a great benefit, but,
normally, a significant security exposure to the company.
SecuRemote is a PC-based application that will allow a secure private
network connection to be established between a remote PC and a network
behind a Firewall-1 firewall. The configuration of the firewall environment
must be modified in order to implement SecuRemote.
Ideally, remote machines that are outside the firewall must continue to take
part in the day-to-day systems management processes.
In this chapter, we will look at the implementation of SecuRemote version 4
and the configuration that is required to enable Tivoli Remote Control to
establish sessions both to and from such a workstation.

5.1 An Introduction to VPN and SecuRemote


SecuRemote seamlessly encrypts data leaving a PC destined for a FireWall-1
site. No modifications to applications are necessary since the product plugs
directly into the TCP/IP protocol stack. SecuRemote can run on Microsoft
Windows 95 and Microsoft Windows NT. If running on NT, it is necessary to
have at least Service Pack 3 for NT installed.
It is also possible to connect a SecuRemote client to multiple firewalls. In our
environment, we elected to run SecuRemote on Microsoft Windows NT and to
connect to only one Firewall-1 gateway.

5.1.1 Encryption Schemes Supported by FireWall-1


FireWall-1supports the following encryption schemes:
FWZ is a proprietary FireWall-1 encrytion scheme.
Manual IPSec is an encryption and authentication scheme that uses fixed
keys.
SKIP (Simple Key-Management for Internet Protocols), developed by Sun
Microsystems, adds improved keys and key management to Manual
IPSec.
ISAKMP/OAKLEY (commonly called ISAKMP), like SKIP, adds key
management to Manual IPSec.

Copyright IBM Corp. 1999

59

These encryption schemes are described in more detail in Virtual Private


Networking with FireWall-1 , which is product documentation, available from
Check Point Technologies, Ltd.

5.1.2 Validation of IDs


While it is running, the SecuRemote intercepts any network connectivity that
is initiated by the client. If this is the first connection to the firewall,
SecuRemote will prompt the user for a user-id and password. This is
validated against a number of possible sources at the firewall.
We elected to validate against the Windows NT SAM database for some
userids, while others would be validated by Firewall-1s authentication.

5.2 Implementing Secure Remote for Basic Access


The installation of the SecuRemote client on Windows NT is straight-forward,
and any configuration issues that arise should be covered in the product
documentation.

5.2.1 SecuRemote Client Installation


SecuRemote is not a service that is run on the PC, but rather an application
that starts each time a user logs on. It is started from the following entry in the
registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

The full path name of the executable that is run is:


c:\winnt\fw\bin\fwenc.exe.

It is easy to determine whether the process is running by looking at the icons


which appear at the end of the Windows NT taskbar. The taskbar normally
appears at the bottom of the screen on Windows NT and Windows 95 or 98.
While SecuRemote is running, an icon of a white envelope appears. See
Figure 37 on page 61. Right-clicking on this icon opens a short menu.
Selecting Kill will end the SecuRemote application, if required. While this
icon appears on the taskbar, SecuRemote intercepts all packets destined to
the local machine, as well as all packets that leave the machine.

60

Implementing Tivoli Remote Control In Large Enterprises

Figure 37. SecuRemote Status Icon

Double-click on this icon to start up the configuration application. You should


see that the main window is empty since no sites have been defined. Select
Sites -> Make New to define a new site. An entry panel is displayed. In the
Name field, enter the hostname or the IP address of the Firewall-1 gateway
through which this client will connect. To complete this definition process
successfully, Firewall-1 must be running and able to receive requests
destined for it so that it can complete the validation sequence that
SecuRemote requires. Refer to Figure 38 to see which rules we had active on
the firewall for site registration.

Figure 38. Rules Required for Site Registration.

The destination in Rule 1, osfw, is the name of the machine on which


FireWall-1 is installed. This rule allows packets destined for the firewall to be
granted access, provided that the packet is talking to the FireWall-1 service.
Once the SecuRemote client has connected to the Firewall, it obtains the
encryption keys it requires and then asks the user to validate them. The user
is prompted with both the key and the date on which it was created. An entry
is made in the log stating that a connection to the FireWall-1 service on the
firewall was accepted because of Rule 1.
When the client connects for the first time, it downloads a topology of what
the network looks like behind the firewall. This information is then used to
determine what course of action to take when the workstation attempts to
make a connection to a remote machine. If SecuRemote determines that the
packet is destined for a machine behind the firewall, the packet will be

Remote Access Scenario

61

intercepted and encrypted. Otherwise, the packet will be left to follow its
normal course.
After the user has confirmed the information on the screen and closed the
window, SecuRemote is ready to encrypt any data that is destined for the
firewall or for machines behind the firewall.

5.2.2 Creating Authentication IDs


SecuRemote performs validation on a user ID and password basis. This
process is not handled by the SecuRemote client, but by the firewall itself. We
started our access control definition by creating a user group on the firewall.
This can be done by selecting the Manage -> Users... menu on the Security
Policy window. Press the New -> group and the Users Window opens. Enter
the name of the group you wish to define. We called our group ITSO.
5.2.2.1 FireWall-1 Validation
From the same Users window, select New-> Default to create a user. A
window titled User Properties is displayed. We entered Jimboy in the Name
field. At the Groups Tab, we added the ITSO group.
At the Authentication page, we specified FireWall-1 Password in the
Authentication Scheme drop-down box. In the Settings panel, which then
appears at the bottom of the page, we entered this users password. We left
the Location and Time panels unmodified.
On the Encryption Panel, confirm that FWZ is selected in the Client
Encryption Methods combo box. We left the properties of the FWZ encryption
method unchanged.
When you press OK, the window closes and returns you to the Users window.
Press the Install button and then Close. If this step was ignored, we found
that the user could not be found when attempting to logon from the
SecuRemote client.
5.2.2.2 OS Validation
While creating the user, instead of specifying FireWall-1 Password in the
Authentication Scheme drop-down box, select OS Password. The Settings
panel at the bottom of the page is blank, and no further configuration is
required.
The user must, however, be defined as a local user or domain user on the
Windows NT Server on which FireWall-1 is installed. If the user is not defined

62

Implementing Tivoli Remote Control In Large Enterprises

to Windows NT, then SecuRemote returns with a message that the user is
unknown to the operating system.
Note

The user ID and password for SecuRemote are both case sensitive. The
user ID and password for the operating system may not be case sensitive.
If you choose to validate a user ID against the operating system, then,
when logging on, enter the user ID in the same case as you used when you
defined it to FireWall-1 and not to the operating system.

5.2.3 Modifying the Firewall-1 Rules


After the firewall is installed and running, ensure that the firewall is able to
receive direct requests from the workstations. We specified the rules as
shown in Figure 38 on page 61. The source machine can be specified to
minimize the security risk. When workstations do not require validation, the
rule should be disabled entirely. Refer to Chapter 4, Remote Control with
Firewalls on page 35 and the Managing FireWall-1 Users Guide for more
information on setting up and modifying the rules.
The rules shown in Figure 38 only allow the SecuRemote client to connect to
the firewall and perform validation. This rule does not allow sessions initiated
at the client to be passed through the firewall. We added a number of rules.
All the rules in the rule base are shown in Figure 39.

Figure 39. FireWall-1 Rules Used

We inserted Rule 2 to allow the sessions to be initialized by the SecuRemote


client to our target. We specified a single machine as a target, namely

Remote Access Scenario

63

OSTMR. You will notice that the action for Rule 2 is not Accept, but rather
Client Encrypt. Client Encrypt must be specified as it is this action that
performs the encryption and decryption of packets that go to and come from a
SecuRemote client. The action menu is shown in Figure 40 on page 64.
Rule 3 is necessary to allow the session to be able to connect back from the
target machine.

Figure 40. Client Encrypt Action Item

You will also notice that we added Rule 4. We added this rule so that the
continuous NetBIOS-name-find and other NetBIOS datagram packets that
Windows NT issues are not logged when dropped by the firewall. This rule
reduced the amount of clutter in the log file while we were taking traces of this
environment.

64

Implementing Tivoli Remote Control In Large Enterprises

This set of rules was going to provide us with the basic environment to allow
us to establish a secure connection. We had to understand how the secure
connection would behave under different circumstances in order to apply this
knowledge to Tivoli Remote Control connections. We put SecuRemote
through some test cases.

5.2.4 Investigating the SecuRemote Environment


We identified the following scenarios as ones that we could use to determine
how Remote Control and the associated Tivoli processes would operate, and
what modifications we needed to make to the environment.

Connecting from SecuRemote


Connecting to SecuRemote client
Limiting permissible services
Termination of the secure session

5.2.4.1 Connecting from SecuRemote


We started with the rules shown in Figure 39 on page 63. These rules allowed
a user to connect to one machine behind the firewall (on OSTMR). However,
this connection could only be established from machine VIKING because all
the ports for this session were open.
We started this test while SecuRemote was not running. From the Windows
command line on the SecuRemote client, we executed:
net use x: \\ostmr\c$

This failed since the nbsession service was denied access by Rule 5. We
started SecuRemote on VIKING and repeated the net use command on
OSTMR.
We were immediately prompted for a userid and a password. When we used
the ID Jimboy (validation performed by FireWall-1), we received the following
authorization message:
User Jimboy authenticated by FireWall-1 Authentication.

When we used the ID Administrator with the password that Administrator


would use to log on to the firewall box from Windows NT, the message we
received was:
User administrator authenticated by OS Password.

In both cases, the log file showed no entry to indicate a successful logon.
However, if an unsuccessful logon occurs, an alert is generated in the log,
giving an explanation for the failure.

Remote Access Scenario

65

Note

If the user is defined at the firewall, but is not defined to the groups which
are permitted through the firewall, the users logon (to the firewall) will still
be successful, but the user will not be able to establish sessions through
the firewall.
Once user authorization completed, we could perform a net use across the
firewall to our target machine from the SecuRemote machine. Figure 41 is an
extract from the log file which shows the entry detailing the successful
session establishment. Notice that the action performed on the packet was a
decryption.

Figure 41. NetBIOS Session Decryption

We confirmed that an attempt to connect with a net use command to any


other machine behind the firewall failed.
After we established a connection to our target, we could perform numerous
tasks to and from it without problem. For example, we established an HTTP
session from our SecuRemote client to OSTMR. We were not prompted for
validation again.
5.2.4.2 Connecting to a SecuRemote Client
We then halted all the sessions on machine VIKING. We logged off Windows
NT and logged back on to ensure that SecuRemote was reset. We then
attempted to start a session from OSTMR to VIKING by repeating a similar
command. From a command line on OSTMR, we ran:
net use v: \\viking\c$.

The session was not established. We saw that the nbsession and nbname
requests from OSTMR were accepted by the firewall, but we saw no
response from machine VIKING. Though there was nothing explicitly detailed
in the log of packets being dropped, we confirmed from a line trace taken on
the side of OSTMR that there were no responses from machine VIKING.
This means that even though a machine has a running application that is
listening for requests, this machine will not respond to a request coming from

66

Implementing Tivoli Remote Control In Large Enterprises

behind the firewall until the user at the local machine has been validated
against the firewall.
What we did see was that, when we halted SecuRemote on the client, we
were able to successfully connect, indicating that the SecuRemote
application was probably intercepting packets leaving the workstation.
To further confirm our findings, we established a connection from machine
VIKING. We opened an HTTP connection and then repeated the above
net use command on machine VIKING. The log shown in Figure 42 on page
67 lists the transactions that took place.

Figure 42. Log Showing Successful Connection

First, you see the successful connection of the HTTP session from VIKING to
OSTMR. The next entry is the NetBIOS session establishment packet coming
from OSTMR and shows that the packet was accepted. This entry is what we
saw previously, but the third line, showing the encryption of the packet, is now
there because of the HTTP session that we established earlier. Because of
what happens in this third entry, the net use command is successful.
A request from a node inside the firewall to a SecuRemote node outside the
firewall is successful if the SecuRemote node outside the firewall has
established any successful connection to that node inside the firewall. This
behavior is an important aspect of SecuRemote that we need to bear in mind
when working with Remote Control, but raises questions about how
SecuRemote operates in more complex environments.
First, we modified Rule 2 (refer back to Figure 39 on page 63) to allow the
SecuRemote client to connect to any machine on our internal network. This
rule base was loaded, and then we repeated the situation discussed earlier in
this section. VIKING had been validated by the FireWall-1 and we had a
secure connection to and from OSTMR.
From a second machine on our internal network, MONTAGUE, we executed:
net use v: \\viking\c$

This command failed to establish a session through the firewall.

Remote Access Scenario

67

Next, we created a session from our SecuRemote client, VIKING, to our


second machine, MONTAGUE. Once this completed successfully, we again
repeated the net use command from MONTAGUE to VIKING. This time the
net use command was successful.
This behavior clearly indicates that if any machine within the firewall wants to
establish a connection to a SecuRemote client, that SecuRemote client must
first establish a connection to that machine in order for the connection
request from that machine to be successfully encrypted.
5.2.4.3 Limiting Permissible Services
We observed that, in order to establish a session between two machines
across the firewall, the SecuRemote client must first establish a secure
connection to the machine on the internal network.
Up to now, we allowed workstations to use any available service, and we
observed that a secure session opened on one service (port) will allow
sessions on other ports to be opened from inside the firewall. Now, we
investigate what happens when we limit the ports that are allowed access
through the firewall.
We modified our new set of rules as shown in Figure 43 on page 68. This set
of rules only allows the creation of HTTP sessions. We specify this limit in the
Services column. When we attempt to create NetBIOS sessions in either
direction, through the firewall, they all fail. This failure is clearly doing what
we expect.

Figure 43. Rules Limiting Sessions

68

Implementing Tivoli Remote Control In Large Enterprises

By adding the services nbname and nbsession to Rule 3, we allow both HTTP
and NetBIOS sessions to be established from within the firewall, but still only
HTTP sessions from the SecuRemote client may be created. Before the user
at the client is validated, we are not able to start any sessions from any of the
internal machines. After VIKING establishes an HTTP session across the
firewall, we are able to create HTTP and NetBIOS sessions in the opposite
direction.
When we open the ports for nbname and nbsession commands, we are able to
perform SMB and HTTP transactions through the firewall.
These results may be intuitive, but we tested them and documented what we
found here for completeness.
5.2.4.4 Termination of Secure Session
During our tests, we often used the net use command to initiate from our
SecuRemote client, across the firewall, to our internal network. But, these
sessions go to a disconnected state if they are left idle for some time. When
this happens, the firewall assumes that the connection from the client is
broken. No more connections are allowed from machines on the internal
network, and existing connections are disconnected.

5.3 Permitting Remote Control Sessions


Now that we have a good understanding of how SecuRemote manages its
sessions with the firewall, we can configure the environment to allow for a
Remote Control session to be established.

5.3.1 SecuRemote as a Remote Control Target


For this scenario, we assumed an environment where a user who has dialed
into the company network requires help from the support help desk. The help
desk user needs to initiate a remote control session to the dialed-in users
machine.
During our tests of this scenario, the responses we expected were based on
what we saw in the test scenarios we documented in Investigating the
SecuRemote Environment on page 65. Our objective was to see what were
the minimal permissions we had to set on the firewall to allow a Remote
Control controller to establish a session to a target with SecuRemote
installed. The final rule base is shown in Figure 45 on page 71.
These rules do not permit any up-calls that the endpoint may need to make in
order to contact the endpoint gateway, nor do they permit the UDP packet

Remote Access Scenario

69

that the endpoint uses to perform its initial logon. These rules only permit a
Remote Control session to take place. Naturally, the rules will need to be
modified to include the applications that the user must connect to.
Rule 4 is responsible for allowing the endpoint gateway, OSTMR, which is on
the internal network, to communicate with the endpoint service running on
machine VIKING. Rule 4 (see Figure 44 on page 70) opens all source ports
and permits a connection to port 9495 on the target.

Figure 44. Rules 2 and 4 - AATivEP_All_9495

MONTAGUE is our selected Remote Control controller. Rule 5 allows


MONTAGUE to establish a session, using any ephemeral port, to the default
Remote Control listening port of 2501.
With Rules 4 and 5 active, the controller can connect to a client through the
firewall, but these sessions are not encrypted. If SecuRemote is active on the
target, and Rules 2 and 3 do not exist, the controller cannot establish a
Remote Control session. Rules 2 and 3 duplicate Rules 4 and 5, but allow for
the sessions to talk to the SecuRemote application, and, thus, encrypt the
data.
The creation of the FireWall-1 workstations and services is documented in
Chapter 4, Remote Control with Firewalls on page 35.

70

Implementing Tivoli Remote Control In Large Enterprises

Figure 45. Remote Control to a SecuRemote Client - Rule Base

The log file shown in Figure 46 indicates that it is the permissions set by
Rules 4 and 5 that permit the packets to be encrypted. Though the data that
is returned from the target is encrypted, the decrypting action was not entered
into the log.

Figure 46. Remote Control to a SecuRemote Client - Log

Rules 2 and 4 can be improved by limiting the source port to the ephemeral
ports instead of opening all ports.

5.3.2 SecuRemote as a Remote Control Controller


Assume a scenario where a technical specialist must connect to a corporate
network and take control of a problem machine. Assume that the specialist
has been called by a help desk operator, and, now, the operator can establish
a connection by executing:
wrc RmtCtl controla @Endpoint:montague @Endpoint:viking -G:5 -P:Y

Remote Access Scenario

71

This command need not be issued from a command line, but can, of course,
be issued by clicking on an icon, from TEC, or by means of REXEC from the
SecuRemote client, along with many other ways.
For a successful connection to take place to the controller on VIKING, we had
to have the rules as shown in Figure 47.

Figure 47. SecuRemote Controller Started with the WRC Command - Rule Base

We found, in this scenario, that there was little complication caused by the
fact that the SecuRemote client must first issue a connection to a machine on
the internal network before communication takes place. For Remote Control
to operate, the endpoint service must be operational. As part of the endpoint
initialization process, an endpoint attempts to connect to its defined endpoint
gateway. In this case, the endpoint gateway is OSTMR. The problem,
however, is that this communication takes place when the service starts, that
is, at boot time. The SecuRemote application is not running since it only
starts at user logon; so, the user is not prompted for an ID or password, and
the LCF daemon remains in a login state and cannot get access to the
internal network. The status of an endpoint can be obtained by opening a web
browser and opening the IP address and the port of the endpoint.
We found that, in order to resolve this situation, we were forced to stop and
start the service on the endpoint after SecuRemote had started, and then we
were prompted for an ID and password. This action then establishes a
communication session to the endpoint gateway, which, in our case, also
happens to be the Remote Control server we will execute commands from.
This action can be seen in the first line of the log shown in Figure 48.

72

Implementing Tivoli Remote Control In Large Enterprises

When the wrc command is executed, Rule 4 permits the Remote Control
server to send the command to start the controller, and Rule 3 permits
VIKING to establish a secure session to the target.
If the Remote Control server is the server you have specified to use in the wrc
command, and is not the gateway to which the endpoint on the SecuRemote
client is defined, then you will need to create an automated method of
creating a secure session to the Remote Control Server.

Figure 48. SecuRemote Controller Started with the WRC Command - Log

5.3.3 Starting Controller from the Desktop with SecuRemote


We now extend the previous scenario to one where the user at the
SecuRemote client starts the controller from the Tivoli Desktop. Here, the
user establishes a connection to the TMR server to start the Tivoli Desktop,
and, as in 5.3.2, SecuRemote as a Remote Control Controller on page 71,
the endpoint must perform an upcall to the endpoint gateway in order to
complete the login process.
In our environment, the TMR server, the Remote Control server, and the
endpoint gateway were defined on OSTMR. Since the endpoint had already
made a connection to OSTMR from VIKING, the only modifications we made
to the rule set was to open the ports that the Tivoli Desktop uses. The Rule 3
that we added is shown in Figure 49. You could incorporate the services in
this rule into other rules, but we separated them for illustrative purposes.

Figure 49. Rules Required to Start the Tivoli Desktop

If your TMR, endpoint gateway, and Remote Control server reside on


separate machines, you must establish a session to the Remote Control
server before attempting to start Remote Control. You will automatically

Remote Access Scenario

73

receive validation to connect to the TMR server when you start the Tivoli
Desktop. Since you are establishing a connection to the target from the
controller, SecuRemote permits access. Remember that the Remote Control
server sends a downcall instruction to the endpoint to start the controller, and
this is why you must have a validated ID and session to this machine before
the downcall will be successful.

74

Implementing Tivoli Remote Control In Large Enterprises

Chapter 6. Bandwidth Management


When a large number of help desk analysts use Remote Control over a low
bandwidth network, a bandwidth management product, such as Check Point
Floodgate-1, can help improve network efficiency without impacting
customers mission-critical applications.

6.1 Background
As the internet-centric business model becomes increasingly dominant
among corporations of all sizes, network administrators are faced with the
task of managing business-critical applications along with non-critical
applications so that they coexist. Or, when you connect your network to the
Internet, it is very important to make the most efficient use of the available
bandwidth. Under these situations, the bandwidth management may become
a critical issue.
To have sufficient bandwidth for application data being exchanged between
the head office and the branch office, a bandwidth management tool must
track and control the flow of communication.
This chapter explains the conditions where Floodgate-1 is useful. It further
explains the scenarios we tried in the labs and the installation procedure for
FloodGate-1.
We installed the FloodGate-1 tool from Check Point Software Technologies
Inc. (Redwood City, CA) in the labs, along with other applications which are
considered mission critical. The purpose was to see the effect of FloodGate-1
in the environment where the bandwidth utilization is almost 100%.

6.2 Requirements
The effective tool needs to address the following requirements:
Flexible Prioritization
Many times, prioritizing the communication is just not sufficient. For
example, you may want to specify higher priority for HTTP traffic than for
SMTP. The result can be that all the bandwidth resources get allocated to
HTTP and none to SMTP. We assume here that HTTP traffic has the
priority and is also occupying the entire bandwidth.
Minimum bandwidth

Copyright IBM Corp. 1999

75

Any type of traffic over the network should be guaranteed a minimum


required bandwidth. This guarantee would work within the total bandwidth
capacity. For example, if Remote Control is a critical support application, a
minimum required bandwidth should be allocated to this application as the
application is executed.
Classification
The tool must be able to classify communications and distinguish between
similar services, for example, between PointCast and the HTTP.
Monitoring
The tool must be able to provide a clear picture about what is actually
happening so that the network administrator can monitor the network
performance and be able to predict the capacity requirements in real time.

6.2.1 Understanding TCP Characteristics


It is important to know the TCP characteristics in order to understand different
technologies involved in managing the network traffic.
TCP has a slow start algorithm where communication begins slowly and
then ramps quickly.
TCP based protocols use an acknowledgment scheme (ACK) to indicate:
That each and every message was received.
Whether or not additional data can be accepted.The parameter here is
called TCP receiver window size which indicates how much more can
be sent during the next packet transfer.
The time taken for a packet to be sent and an ACK (this time with new
window size data) to be received is called the round trip time (RTT). Each
individual sender will wait for the RTT before the next series of packets
can be sent.
Most non-TCP communications do not require an ACK and are
connectionless. Common applications that use this connectionless protocol
are multimedia and voice over IP. Since their applications do not use any
ACK, there is no way to receive window size information or any RTT.
Applications using connectionless protocols throw the packets into the
network and move on to the next packet. These applications more often use
all available bandwidth. The tools used for bandwidth management must take
care of such applications.

76

Implementing Tivoli Remote Control In Large Enterprises

6.3 FloodGate-1
In order to experiment with the bandwidth management scenario in the lab,
we created the environment as described below.
There are two Token Ring LANs connected with a low bandwidth SLIP link
providing 38.4 Kbps.The connectivity is simple. We want to test the scenario
in which Remote Control is used across the SLIP link while HTTP and ftp
traffic is flowing across, and flood the available bandwidth. We install
FloodGate-1 on one of the nodes and configure FloodGate-1, build various
bandwidth policies, apply these bandwidth policies, and observe the traffic
flow across this slow link.
The following steps are involved in installing and configuring the FloodGate-1
tool on a node:
1. Load the software.
2. Configure the bandwidth policy which includes defining the network
objects used in the Rule Base.
3. Define the rule base where you classify the traffic by type of service
4. Define any proprietary services used in the network. We defined Remote
Control as the service. (The commonly used services are already defined
here as default.)
5. Define bandwidth policy; this is the set of rules for classifying connections
and allocating bandwidth among them.
6. Install the bandwidth policy.
7. Use the monitor tool to monitor the network and adjust the bandwidth
policy accordingly.

6.3.1 FloodGate-1 Technology Overview


FloodGate-1 implements three technologies to provide all the necessary
floodgate capabilities:
Intelligent Queuing engine for allocating bandwidth
Stateful Inspection for classifying communications
Retransmission Detection Early Drop for reducing the number of
retransmits and retransmit storms

Bandwidth Management

77

6.3.2 Installation of FloodGate-1


We started FloodGate-1 Version 1.1 installation on a node on the head office
LAN. This is because the queries would be reaching the head office network
and the response data would flow from there to the corresponding node in
branch location.
You need to decide how you wish to configure FloodGate-1 and on what
nodes you want to install FloodGate-1 components. For detailed instructions,
refer to Chapter 1 of the FloodGate-1 Quick Start Guide, Version 1.0, which is
product documentation, available from Check Point Software Technologies,
Inc.
FloodGate-1 allows the required type of traffic to get the priority which is
configured through the bandwidth policy.
Before installation, make sure that you have a valid license key to install this
product.
Insert the FloodGate-1 CD and execute the setup program for installing
the tool. Type the required licensing information.
Select both the FloodGate-1 module and the management module to be
installed on the same node.

78

Implementing Tivoli Remote Control In Large Enterprises

Figure 50. FloodGate-1 Component Selection

Enter the license and the administrator ID and password in the following
popup windows.
Add the GIU clients. These are the nodes from where you can invoke the
FloodGate-1. In the next screen, add the nodes on which the FloodGate-1
module can be installed.
The setup is now complete.

6.4 Summary
During the installation steps, we discovered a minimum bandwidth
requirement for FloodGate-1 to work. Since we could not match the required
minimum bandwidth, we could not complete this investigation of the use of
Floodgate-1. We were not able to use the FloodGate-1 product in our
environment because Floodgate requires at lease a 56 Kbps link, and we only
had a 38.4 Kbps link.

Bandwidth Management

79

80

Implementing Tivoli Remote Control In Large Enterprises

Chapter 7. Tivoli Enterprise Console (TEC) Integration


When Remote Control is implemented in a large enterprise environment, its
benefits may not be fully realized. The product is often only used as an
after-thought and not as an integral part of problem determination, support
and event management. The benefits derived from the implementation of
Remote Control can be significantly enhanced by introducing TEC into the
Tivoli environment.
In security sensitive environments, there is a perception that Remote Control
creates a security exposure. Not many people are aware that this can be
addressed with the implementation of policy methods in Remote Control as
well as tracking by means of audit trails using TEC. See Securing the
Remote Control Controller Defaults. on page 2.

7.1 Event Logging and Audit Trails


Remote Control can log events to the Windows NT Event Log. To activate this
function, you must make the following change to the Windows NT Registry
location HKEY_LOCAL_MACHINE\SOFTWARE\Tivoli\Remote Control Controller.
Change the registry key, Logging:REG_DWORD:0 to read Logging:REG_DWORD:1.
This change must be done on the Remote Control controller. It was neither
necessary to restart the machine nor the Remote Control Service after this
had been done. There are a number of tools available on the Internet which
allow you to make modifications to the Windows NT Registry directly from a
command line. This is the ideal option in an environment where many
alterations must be made.
Once this change has been made, any connections that are made and closed
by Remote Control, as well as connection failures, are logged in the Windows
NT Event Log. These can be viewed on the Windows NT node by selecting
Start -> Programs -> Administrative Tools -> Event Viewer.
A typical connection open and closure creates Windows NT Event Log entries
as shown in Figure 51 on page 82.

Copyright IBM Corp. 1999

81

Figure 51. Windows NT Event Log - Session Started and Ended.

If a connection failed to be established, you would see a message in your


Windows NT Event Log similar to the one in Figure 52 on page 82.

Figure 52. Windows NT Event Log - Session Failed

In a separate environment, we installed an early pre-release version of Tivoli


Remote Control 3.6.1 to determine what the new Windows NT Event Log
entries would look like. Since this was an early pre-release version of the
code, we could not get the logging to function as it should. We do expect to
see additional information in the Windows NT Event Log for Remote Control

82

Implementing Tivoli Remote Control In Large Enterprises

in future releases. Such additional information could include entries, for


example, of the Administrator that launched Remote Control.
These log entries, though useful in smaller environments, are difficult to use
effectively in a large environment because the events are not consolidated on
a single repository. We implemented TEC in our environment to do this
consolidation.

7.2 TEC Environment Installation


Our environment consisted of a separate machine dedicated to the TEC
environment. We used Oracle 7.3 for Windows NT as our DBMS. Oracle was
installed on our chosen server using the process as documented in the IBM
redbook, Using Databases with Tivoli Applications, SG24-5112. After
installing and testing Oracle, we installed the Tivoli 3.6 Framework. From the
TMR server, we installed TEC 3.6 without patches.
Note

A prerequisite requirement for Tivoli Enterprise Console 3.6 to run on


Windows NT is to have Windows NT Service Pack 3 installed. Without
this service pack, TEC will not install successfully.
The RIM object is created during the TEC installation. However, the data that
we originally used when configuring the TEC installation was incorrect; so, we
were forced to recreate the RIM object. We deleted the RIM object using the
command:
wdel @RIM:tec

and then recreated the RIM object using the command:


wcrtrim -v Oracle -h montague -d ORCL -u tec -H d:\orant -s tecdb tec

After this step, we were able to create the database tables that TEC requires.
The following script performs this task:
c:\usr\local\tivoli\bin\w32-ix86\TME\TEC\cr_tec_db.sh

The general recommendation is not to install the console, DBMS, and TEC
server on the same node because of performance constraints that may be
encountered under load. This configuration is also relatively impractical in a
production environment, but has served its purpose in our test environment.
Because we used a single node for all TEC components, we could perform
thorough TEC testing and even remove the TEC from our environment
without impacting the other tests that were being run.

Tivoli Enterprise Console (TEC) Integration

83

The TEC Console was also installed on the same machine by performing the
standard Desktop -> Install -> Install Product... procedure.
After installation of TEC server and the TEC Console was complete, we
installed the TEC Adapter Configuration Facility (ACF) on the TMR server.
ACF must be installed to have the Application Configuration Profile (ACP)
type appear as an option in the list of possible policy types that can be
created when one creates a new policy in a policy manager. The ACF must
also be installed on the TEC server and to any managed nodes that act as
endpoint gateways to endpoints which will have the TEC Adapter installed.
The ACF does not need to be installed on the endpoints, since the binaries
and other configuration files are downloaded when the policy is sent to the
endpoints.
Though the documentation is not clear on this, the TEC NT event log adapter
only works on an endpoint. Any attempt to run any of the adapter binaries on
a managed node results in an attempt to load the endpoint file libraries, such
as libmrt.dll, for example. If you want events generated from a Windows NT
managed node, you must install an endpoint on the Windows NT managed
node.
When installing an endpoint on a managed node that is defined as an
endpoint gateway, the default listening ports of these services may conflict. In
Tivoli Framework version 3.6, both these services use port 9494 by default.
We modified the endpoints default listening port to be the same as the
default used in version 3.6.1. This port number is 9495 for the endpoint, and
the endpoint gateway continues to use port 9494.

7.3 Configuration and Deployment of TEC Profiles


We created a profile manager in our selected policy region and defined
profiles which we wanted to distribute.The profile manager can be created
from the Create -> ProfileManager menu within a policy region. You are
prompted for the name of the profile manager you want to create. There is
also a checkbox labeled Dataless Endpoint Mode. Selecting this checkbox
creates a dataless profile manager, which is necessary to distribute to
endpoints. If you attempt to subscribe an endpoint to a non-dataless profile
manager (now called a database profile manager), you receive an error
message saying the subscription cannot be done.
We used the following command to create a profile manager called
TEC NT Profiles:
wcrtprfmgr TEC36Region "TEC NT Profiles"

84

Implementing Tivoli Remote Control In Large Enterprises

Since the TEC NT event adapter resides on endpoints, we make this policy
manager a dataless one by executing:
wsetpm -d @ProfileManager:"TEC NT Profiles"

Once the profile manager is created within the specified policy region (in our
case the TEC36Region), from the open window of the profile manager, click
Create -> Profile... to create a new profile. A profile can be created using the
following command:
wcrtprf @ProfileManager:"TEC NT Adapter" ACP "NTnRC"

To edit the profile, double-click on the icon. The Adapter Configuration


Profile panel appears with a number of radio buttons running along the top of
the configuration panels. These radio buttons select the different components
of the profile which can be modified.
We set our Distribution Profile options for All levels of subscribers and
Make subscribers profile an EXACT COPY of this profile. This is
particularly applicable in a test environment to ensure consistency of a profile
across a TMR. We did this from the GUI by selecting a profile on the profile
manager panel, then, on the action bar, selecting Profile->Distribution
Defaults. On the Set Distribution Defaults panel, we selected the above
two items.

7.3.1 Understanding and Modifying the TEC NT Adapter


The TEC NT adapter profile consists of four configuration files and two
executables that are distributed to each endpoint that receives the TEC
profile. These files are:

tecad_nt.conf
tecad_nt.fmt
tecad_nt.cds
tecad_nt.err
tecad_nt.exe
tecadnts.exe

7.3.1.1 TECAD_NT.CONF
The tecad_nt.conf file stores environment variables and connection settings
for the profile, as well as alert filters. When the policy is created or modified,
these changes are neither reflected in any file on the TEC server, nor on the
TMR server, but are stored in the TMR names database. The contents of this
file can be viewed using the following command:
wlsac -l "TEC policy for EP"

Tivoli Enterprise Console (TEC) Integration

85

To change these settings, you modify the settings in the Adapter


Configuration Profile panel for the selected profile. All the changes made on
this panel are reflected in tecad_nt.conf.
When this file has been distributed to endpoints, it is stored in the
C:\Program Files\tivoli\lcf\bin\w32-ix86\tme\TEC\adapters\tec directory.
Note

Commands such as wlsac and wsetac must be run from bash in order for
them to execute. We found that copying the files to new names with the
extension EXE allowed us to run the commands directly from a
command prompt.
7.3.1.2 TECAD_NT.FMT
The TEC NT Event Log adapter uses the tecad_nt.fmt file to determine how it
should categorize an event. An incoming event is mapped against the formats
specified in this file. When a match is found, the event is assigned the event
class against which the match was made, and then the various fields of
information from the event are mapped to TEC slots.
A slot is an attribute that is, in this context, a set of fields that define an event
that consists of an attribute name and an attribute description.
We added the lines shown in Figure 53 on page 87 to the end of the existing
TECAD_NT.FMT file using a standard text file editor.

86

Implementing Tivoli Remote Control In Large Enterprises

FORMAT NT_RemoteControl_Start FOLLOWS NT_Base


%t %s %s %s %s %s Remote Control 1 Taking over %s*
target $7
msg PRINTF("Taking over %s",target)
id 1
END
FORMAT NT_RemoteControl_End FOLLOWS NT_Base
%t %s %s %s %s %s Remote Control 2 Closing session with %s*
target $7
msg PRINTF("Closing session with %s",target)
id 2
END
FORMAT NT_RemoteControl_Fail FOLLOWS NT_Base
%t %s %s %s %s %s Remote Control 3 Could not establish session with %s*
target $7
msg PRINTF("Failed to start session with %s",target)
id 3
END

Figure 53. TECAD_NT.FMT Additions for Remote Control

We created one unique event class for each of the events that Remote
Control logs. At first, it was difficult to determine what mask to use, but we
were able to see the format of the information using tecad_nt.exe in debug
mode. Please see TECAD_NT.EXE and TECADNTS.EXE on page 88 for
the use of tecad_nt.exe.
Each of these events is uniquely identified by the event ID number which
follows the string Remote Control. Originally, we assigned the remaining
string, using %s, to msg, but then we identified a need to have a slot defined
for the IP address of the target. With the formats as above, the IP address of
the target was assigned to the target slot, and we built a customized message
for each event which we then assigned to slot msg.
7.3.1.3 TECAD_NT.CDS
The tecad_nt.cds file is the NT adapter Class Definition Statement file.
Though this file does contain information specific to the event class
configuration, we did not modify this file at all, since it is rebuilt each time a
policy is distributed to an endpoint. The tecad_nt.cds file is built from
tecad_nt.fmt with the command:
nt_gencds "${AC_TARGDIR}/tecad_nt.fmt" > "${AC_TARGDIR}/tecad_nt.cds

Tivoli Enterprise Console (TEC) Integration

87

This command is executed on each subscriber after the profile has been
distributed. You see this command in the after file distribution entry panel
when you select the Actions radio button on the Edit Adapter Profile panel.
7.3.1.4 TECAD_NT.ERR
The tecad-nt.err file contains error logging and tracing options. We did not
find any need to view or modify this file while performing our tests.
7.3.1.5 TECAD_NT.EXE and TECADNTS.EXE
The two executables that make up the adapter perform the same function,
that is, locate entries in the NT event viewer and then act upon them based
on the information given. The executables are, however, used in two different
ways. The first, tecadnts.exe, is the executable run by the TEC Event Adapter
service on Windows NT. The other executable, tecad_nt.exe, can be run from
the command line. Ideally, the latter executable is used in problem
determination situations. If you decide to make use of tecad_nt.exe, ensure
that the service has stopped running. When the profile is distributed to an
endpoint, the TEC Event Adapter Service is automatically configured and
started once the files have been copied into place.
We encountered a problem with tecadnts.exe during our tests. The service
would abend as soon as it encountered an event which it had to forward. We
obtained the latest release of these executables from the Tivoli support page
at http://www.support.tivoli.com. We downloaded TEC service pack 13
which contains only refreshes for both of these executables. We copied them
to C:\tivoli\bin\lcf_bundle\bin\w32-ix86\tme\TEC\adapters\bin on the endpoint
gateway. The next time we distributed the profile to the endpoints, the new
executable was put in place, and the service remained active and forwarded
TEC.
Note

If you find that events are being forwarded, make certain that the default
distribution setting for the profile is Make each subscribers profile an
EXACT COPY of this profile.
The ACP profile is solely responsible for detecting and forwarding events to
the TEC server. How these alerts are handled and interpreted by TEC is
managed by a rule base.

88

Implementing Tivoli Remote Control In Large Enterprises

7.3.2 The Event Classes and BAROC Files


For TEC to interpret what it receives from the adapter, the alert that TEC
receives must be assigned to a defined event class by means of BAROC
files.
The Tivoli Remote Control Users Guide Version 3.6, GC31-8437, and
Release Notes explain how to modify the TECAD_NT.BAROC file to define
the NT_RemoteControl_Event event class. Since one event class for our
environment was inadequate, we created 3 separate event classes - one for
each of the Remote Control Events that we encountered, namely:

NT_RemoteControl_Start to record all session initialisations


NT_RemoteControl_End to record all session terminations
NT_RemoteControl_Fail to record all session initialization failures
Refer to Figure 53 on page 87 to see how each of these event classes is
identified and formatted.
We used a text editor to create a new baroc file and saved it as
C:\Development\TECRC.baroc. The contents of the file are shown in Figure
54 on page 90. Using this file, we create a TEC slot for the IP address of the
Remote Control target, which is called target, and assign the default
severities of these events.

Tivoli Enterprise Console (TEC) Integration

89

TEC_CLASS :
NT_RemoteControl_Start ISA NT_Base
DEFINES {
target: STRING;
severity: default = HARMLESS;
};
END
TEC_CLASS :
NT_RemoteControl_End ISA NT_Base
DEFINES {
target: STRING;
severity: default = HARMLESS;
};
END
TEC_CLASS :
NT_RemoteControl_Fail ISA NT_Base
DEFINES {
target: STRING;
severity: default = WARNING;
};
END

Figure 54. TEC BAROC File - TECRC.baroc

Now, most of the ground work is done in preparing the changes. The next
step is to activate all these modifications by means of a rule base.

7.3.3 Creating a Rule Base


TEC ships with a default rule base which contains all the standard events that
TEC can manage. However, this does not incorporate the alerts for Remote
Control; so, it is necessary to modify the class and rule files.
It is good practice to maintain two separate working directories for the rules:
one for the production environment, where all rules and classes that are in
use are stored, and a second directory to store all the rules and classes that
are in development and testing. Since we did not need all the rules in the
default rule base, and because working with so many classes can become
cumbersome, we decided to create a new rule base. We kept all our
development work in C:\development and decided that the active rule base
would use c:\RC_Rules
To do this, double-click on the Event Server icon. In the Rule Base window
select Create -> Rule Base. The equivalent command for doing this is:
wcrtrb -d C:\RC_Rules "Remote Control"

90

Implementing Tivoli Remote Control In Large Enterprises

This command creates a rule base called Remote Control and places it in the
directory C:\RC_RULES. A new icon is created in the rule base folder. If the
directory does not exist, it is automatically created along with three
subdirectories. In our case the directories were:
C:\RC_Rules\TEC_CLASSES
C:\RC_Rules\TEC_RULES
C:\RC_Rules\TEC_TEMPLATES
Now that the rule base has been defined, we need to define event classes to
the rule base. In our environment, we wanted TEC to be aware of the NT
alerts as well as the alerts coming from Remote Control. The inclusion of
these event classes into the rule base is done by importing the BAROC files
in which these event classes are defined, namely, TECAD_NT.BAROC and
TECRC.BAROC. Refer to 7.3.2, The Event Classes and BAROC Files on
page 89 to see how we created this file. We imported these files using the
commands:
wimprbclass -a tec.baroc montague:c:/development/tecad_nt.baroc "Remote
Control"
wimprbclass -a tecad_nt.baroc montague:c:/development/tecrc.baroc
"Remote Control"
Note

The path parameter uses forward slashes (/) and not backslashes (\) if
you run this from the NT Command prompt. Using forward slashes in
the path causes the command to fail with error:
chdir failed with return code 22:invalid argument

This importing can also be accessed from the GUI by right-clicking on the
Rule Base icon. From the GUI, one can clearly see that classes root.baroc
and tec.baroc are already in place before the remaining two are imported. It
is best to import tecad_nt.baroc after tec.baroc, as some of the classes
defined in tec.baroc are parents to those used in tecad_nt.baroc. This
sequencing is done by using the -a switch on the command line.
After completing the import, our directory, C:\RC_Rules\TEC_CLASSES, contained
the following files:
.event_sum_slots
.load_classes
.task_slots
root.baroc
tec.baroc

Tivoli Enterprise Console (TEC) Integration

91

tecad_nt.baroc
tecRC.baroc
The next step is to run a compile either from the icon menu, or with the
command:
C:\usr\local\Tivoli\bin\w32-ix86\bin\wcomprules "Remote Control"

and then load and activate the rule base using:


C:\usr\local\Tivoli\bin\w32-ix86\bin\wloadrb -u "Remote Control"

The -u switch forces the rule to load and become immediately active, as
opposed to waiting until the event server is restarted before becoming active.
However, this does not apply to changes to the event classes. Although the
output of the wlsrbclass command at this point will show that the class
NT_RemoteControl_Event exists, the class is not active until the event server
is stopped and started. The command wstopesvr stops the event server and
wstartsrv starts the event server.
We occasionally encountered a problem when loading a rule base. This
particular problem is a probable defect in the version of TEC that we have in
our test environment. When performing a load, it would occasionally fail with
the message:
rmdir failed with code 41:Directory not empty

You must erase the working and current directories of the rule base. In our
environment, we had to remove the following directories if they existed:
\var\spool\tivoli\montague.db\TEC\rb_dir
\var\spool\tivoli\montague.db\TEC\rb_dir.bck
\var\spool\tivoli\montague.db\TEC\rb_dir.tmp
Once the rule base has loaded successfully, the icon should change to
indicate that it is now the active rule base. Refer to Figure 55 on page 93

92

Implementing Tivoli Remote Control In Large Enterprises

Figure 55. New Rule Base Icon

7.3.4 Creating Event Groups


Event groups are one way of displaying a subset of all the alerts that TEC has
received. To create an event group for Remote Control, first right-click on the
Event Server icon on the Tivoli desktop. From the menu, select
Event Groups... and a window listing the event groups appears. From the
Event Group menu, select New. In the name field, enter a distinguishing
name for this event group. We called ours Remote Control, for lack of
imagination. Once you have selected an icon to represent this event group,
press the Create & Close button.
A window detailing the filters for this event group appears. In this window, you
can define the criteria that must be met by any event before it will appear in
the event group you have just defined. We are interested in any event that
was generated by Remote Control, that is, any event where the event class is
NT_RemoteControl_Event. Press the Event Class button to obtain a list of
the event classes and select NT_RemoteControl_Event from the panel that
appears to the right. We have no criteria for any of the other fields, so leave
them blank, and they will be filled with the wildcard symbol (*). Press Add
Filter and then Set & Close. Close the Event Group Manager and save.
Now, the event group is defined, and we have specified the filter we require
for this event group. The next step is to assign this event group to the
consoles that need to access it.
To assign this event group to a console, bring up the consoles configuration
menu by right-clicking on the icon. Select Assign Event Groups. In the
window that appears, place Remote Control (or your chosen event group
name) in the Assigned Event Groups list and press Set & Close.

Tivoli Enterprise Console (TEC) Integration

93

Now, open the console view and the Event Groups window should look
similar to the one in Figure 56.

Figure 56. Enterprise Console Event Groups

7.4 Managing Remote Control with TEC


In a large enterprise environment, one can often manage the environment by
automating certain actions which are regularly required. We decided to
integrate Remote Control with TEC so that Remote Control is invoked based
upon the event received by TEC.

7.4.1 Initiating an Event on a Remote Control Failure


First, we decided to execute a task based on the arrival of an
NT_RemoteControl_Fail event. Based on the assumption that a failure may
occur because the Tivoli Remote Control service is not running on the target,
we decided to create a task that would restart the service on the specified
target.
Please be aware that if a second controller has already established a session
to the target which you are trying to monitor, then an NT_RemoteControl_Fail
event will be generated; so, be careful how you implement this in your
production environment.
We used a simple task to start the Remote Control service for us. The script,
BounceRC.CMD, is listed in Figure 57 on page 95. It is a very simple set of

94

Implementing Tivoli Remote Control In Large Enterprises

commands, as you can see, but it is effective in demonstrating the execution


of a task after an event is received.

NET stop TME10RC


NET start TME10RC.

Figure 57. Stop and Start Remote Control - BounceRC.CMD

We created this script file using an ordinary text editor and saved it in
C:\RCTools on the TMR server. We used this directory to consolidate all our
scripts in one storage repository.
We then created the task using:
wcrttask -t BounceRC -l "RC Tools" -i w32-ix86 ostmr
c:\rctools\bouncerc.cmd -r senior

This command creates a task icon in the RC Tools task library. We


confirmed that the script worked by stopping the TME10RC service on a
target workstation and then executing:
wruntask -t BounceRC -l "RCTools" -h viking -E.

and we noted that the service had then started. One point we overlooked
when creating the rules was that the target slot returned the IP address of the
target and not the machine name of the target that the connection was made
to. This oversight posed a problem as to how we were to convert this IP
address to a machine name. We were not able to locate any objcalls that
would help us in this, and so, we were forced to use a far less elegant
solution which involved two tasks.
Now, with the modification, TEC executes task BounceIP.sh (See Figure 58
on page 96) on the TMR Server and passes the IP address of the target to
the task. This task, in turn, resolves the IP address and then executes the
BounceRC.cmd task on the correct endpoint. This solution is clumsy and
makes a few assumptions:
The hostname of the endpoint is the same as that of the machine name.
The hostname of the machine, as specified in the hosts file, matches the
case of the machine name as defined to Tivoli. This can be easily
remedied by modifying the hosts file which is located in
C:\winnt\system32\drivers\etc, but is probably not feasible in a large
environment.

Tivoli Enterprise Console (TEC) Integration

95

You could also investigate the feasibility of using nslookup to retrieve the
information if you have a DNS in your environment.

#!/bin/sh
# set -x
ipaddr=$1
target=ping -n 1 -a $ipaddr | grep "Pinging" | cut -f 2 -d " "
wruntask -t BounceRC -l "RC Tools" -h $target -E
echo $target

Figure 58. Run Remote Control Task - BounceIP.sh

Now, we have a task that TEC can execute upon receiving an event. We
proceeded to create a simple rule which will execute this task when Remote
Control fails to start on a node.
The rule that we used in the end is listed in Figure 59 on page 97 and was
created using Notepad on Windows NT. We saved this rule in our
development directory, in a file called BncRC_on_Fail.rls.
Note

When creating rules on NT, always make sure that there is a Carriage
Return/Line-Feed at the end of the last line of your rule. This is easily
achieved by pressing the Enter key at the end of the very last line of the
file. If this was not done, we encountered one of two errors during compile:
Unexpected end of file
Unexpected character
It was easier for us to manage the rules from the command line as we used
batch scripts to unload, delete, import, compile and load rules. You must
import the new rule into the rule base, and this can be done using the
command:
wimprbrules c:/development/BncRC_on_Fail.rls "Remote Control"

Before importing a rule that already exists, it is a good idea to delete the rule
in case conflicts occur. So, in the above case, before performing the import,
execute:
wdelrbrules BncRC_on_Fail.rls "Remote Control"

After importing the new rule, it needs to be compiled, and we do this using the
command:

96

Implementing Tivoli Remote Control In Large Enterprises

wcomprules -t "Remote Control"

Finally, the Rule Base must be loaded and made active, and the command to
do this is:
wloadrb -u "Remote Control"

Perhaps now you will understand why we put all the above commands in a
script file. In our environment, and with bad typists, you can find yourself
repeating the above process numerous times in an hour.

rule: remote control restart :


(
description:Restart RC on failing target,
event: _rc_fail of_class NT_RemoteControl_Fail
where [
target:_target
],
reception_action:BncNClose:
(
exec_task(_rc_fail,BounceIP,-l "RC Tools" -h ostmr -E -a "%s",[_target],YES)
change_event_status(_rc_fail,CLOSED)
)
).

Figure 59. Restart Remote Control on Failure - BncRC_on_Fail.rls

The rule which is responsible for restarting the Remote Control Service starts
by obtaining the slot target and assigning this value to the variable _target.
With the exec_task action, task BounceIP is started and passed the
arguments stored in the second parameter. Each occurrence of the %s
variable is replaced by the variables listed in the third parameter. In
BncRC_on_Fail.sh, the value of _target is passed as an argument to the -a
switch when the task is run.
The second action performed by the rule is to set the status of the previous
event to CLOSED.

7.4.2 Configuring TEC to Automatically Start Remote Control


The next step in our action plan was to determine how we could get remote
control to automatically start a session based on an incoming event. This was
our hypothetical situation. We have a number of database servers in our
organization. Some of them act as file servers, but these resources are on
separate drives from the databases, which, by convention, are stored on
drive I:. If any of these machines report that their I: drive is running out of
space, then the help desk user must immediately have a remote control

Tivoli Enterprise Console (TEC) Integration

97

session to the server. This is a critical event, but once we know that someone
at the help desk has looked into the problem, we are happy to drop the
severity.
First, we create a script that will allow us to establish remote control sessions
between machines. We created this script using a text editor and saved it as
C:\rctools\StartRCSess.cmd. You can see the listing of the command in
Figure 60.

call c:\winnt\system32\drivers\etc\tivoli\setup_env.cmd
wrc RmtCtrl controlm @Endpoint:%2 @Endpoint:%1 -P:Y -G:0 -T:Y.

Figure 60. Automatic Start Remote Control - StartRCSess.cmd

The command used to start the session is wrc and is located on any of the
Remote Control servers in your TMR. Run this command on the Remote
Control server and pass the names of the machines you wish to connect to it.
The first parameter specifies the type of session to establish. In this case, we
are establishing Remote Control sessions that start in monitor mode. The
second parameter is the fully distinguished name of the Remote Control
controller, and this is followed by the name of the Remote Control target. The
P switch specifies whether to proceed with the establishment of the session
after the grace period has expired, and the length of the grace period is
controlled by the G switch. The last switch, T, allows the user to alter the state
of the session if it is set to Y.
The values for the names of the target and controller are passed to the
program as arguments, and are designated in the script by %1 and %2
respectively.
We created a Tivoli task to run this script with the command:
wcrttask -t "Start Session" -l "RC Tools" -i w32-ix86 ostmr
c:\rctools\StartRCSess.cmd -r senior

This task can now be run using the command:


wruntask -t "Start Session" -l "RC Tools" -h "ostmr" -a "montague" -a
"os1"

You can see in this command that the task executes on OSTMR, our TMR
server, and passes the names of the target and controller as two separate
arguments. This task established a remote control session between
MONTAGUE and OS1.

98

Implementing Tivoli Remote Control In Large Enterprises

The final step is to create the rule, import it into the rule base, and compile
and load the rule base. These steps are covered in Initiating an Event on a
Remote Control Failure on page 94.
The rule that we used is listed in Figure 61.

rule: remote control restart :


(
description: Restart RC service on failing target ,
event: _NT_full of_class NT_Diskfull
where [
hostname: _target within [DBSVR,OS1,DB2,RULES],
msg: equals I:
],
reception_action: startup:
(
change_event_severity(_NT_full,CRITICAL),
exec_task(_NT_full,"Start Session",-l "RC Tools" -h ostmr -o15 -E -a "montague"
"%s",[_target],YES)
)
).

Figure 61. Start Remote Control on Disk Full - RC_on_DiskFull.rls

This rule is only activated if both of the following conditions are met:
The machine which sent the alert is one of those specified in the list.
The drive which is full is I:.
This rule then executes two actions. First, the severity of the event is set to
Critical. Remember that events that do not meet the criteria will still be
viewable in the TEC console, but the requirement is that only these events
are set to critical. Second, a remote control session is established from the
controller at MONTAGUE to the client which has reported the problem.

Tivoli Enterprise Console (TEC) Integration

99

100

Implementing Tivoli Remote Control In Large Enterprises

Chapter 8. Web Browser Integration


This chapter describes how to install Tivoli Web Access for Remote Control,
and how to use the Tivoli Framework secure HTTP daemon to launch remote
control from a Web browser. This applies only to Tivoli Servers running NT
4.0.

8.1 System Requirements


Tivoli Web Access for Remote Control was tested solely on a Tivoli server
running Windows NT 4.0 with SP3, with the Tivoli Remote Control server
component installed. The Web Access for Remote Control files to execute in
the Windows NT 4.0 SP3 environment are in webrc.zip and may be obtained
from http://itsopok.itso.ibm.com/itsoapps/material.NSF. These files are
provided as is with no formal support. The authrc.exe that is provided only
runs on the Windows NT 4.0 platform.

8.1.1 Operating System Requirements


IBM-compatible PCs 486 or Pentium series running Microsoft Windows NT
4.0 with NT SP3, and TCP/IP stack.
For more information about the supported TCP/IP stack, see the Tivoli
Framework 3.6 Release Notes .

8.1.2 Software Requirements


Tivoli Web Access for Remote Control requires the following products to be
installed:
Tivoli Framework 3.6 or later
One of the following:
Tivoli Remote Control 3.6 server component with one of the following
patches installed:
3.6-RCL-0002

If you installed Tivoli Remote Control Version 3.6 by


making a full installation.

3.6-RCL-0003

If you installed Tivoli Remote Control Version 3.6 by


upgrading from Version 2.1 of 2.1.1.

Tivoli Remote Control 3.6.1, or later, server component.


On the workstation that will be running Tivoli Web Access to launch Remote
Control, install one of the following:

Copyright IBM Corp. 1999

101

Tivoli PC agent version 5.0 or later for PC managed node


Tivoli Management Agent (LCF agent) for endpoint
Tivoli Framework Version 3.6 or later for managed node
AND
A web browser, such as, Netscape or Internet Explorer
Remote Control 3.6 controller is required on the node selected as Controller
on the first Remote Control Web Access panel.(See Figure 62 on page 104.)

8.2 Administrator Authorization


Running Remote Control from a Web browser still requires that the person
launching Remote Control from a browser has the correct Tivoli authority and
Tivoli roles in the appropriate policy regions.
The user must have the appropriate roles in the policy region for the Remote
Control tool (icon) name that was entered in the Remote Control server field
on the first Remote Control Web Access panel. This user must also have the
appropriate roles in the policy region of the target entered in the Target field
on the first Remote Control Web Access panel, or the target selected from the
list on the second Remote Control Web Access panel.(See Figure 63 on page
105.)

8.3 Installing Tivoli Web Access for Remote Control


To install Web Access for Tivoli Remote Control, perform the following steps
at the Tivoli server:

Note

References to $BINDIR in the following steps assume this is being


performed in the BASH shell. If the instructions are performed from a
Windows NT command prompt, you should use %BINDIR%. In either case,
the command prompt window must have the Tivoli environment enabled
(sourced).

102

Implementing Tivoli Remote Control In Large Enterprises

1. Obtain webrc.zip from http://itsopok.itso.ibm.com/itsoapps/material.NSF.


Download to a temporary directory and unzip the file. Copy the resulting
files to a diskette if they are not downloaded to the Tivoli server where you
intend to install them.
2. On the Tivoli server, create a pcremote directory under
$BINDIR/../generic/HTTPd.
3. Copy the files WEBRC_install.sh and pcremote.html to
$BINDIR/../generic/HTTPd/pcremote.
4. Create a pcremote directory under $BINDIR/TAS/HTTPd/cgi-bin.
5. Copy the files authrc.exe, pcremote.cgi, options.cgi, and startsession.cgi to
$BINDIR/TAS/HTTPd/cgi-bin/pcremote.
6. From a bash shell where you have already set the tivoli environment, run
$BINDIR/../generic/HTTPd/pcremote/WEBRC_install.sh.

8.4 Using Tivoli Web Access for Remote Control


Using the Tivoli Web Access to launch Tivoli Remote Control has the
advantage of being able to start the Remote Control application quickly when
the target hostname is already known. In a large enterprise, Tivoli Web
Access can reduce the time normally required to generate the list of targets,
find, and then select the desired target from the list. Tivoli Web Access can
work well in a help desk environment where the help desk person may
already know the hostname of the intended Remote Control target.
Tivoli Web Access can also be advantageous to a system administrator that
uses a laptop for remote connection to the enterprise LAN without the
overhead of the Tivoli Desktop, and needs to have Remote Control capability
available from different locations.

8.4.1 Running on Node with Remote Control Controller


1. On a workstation that has Remote Control controller installed, start a Web
browser such as Netscape or Internet Explorer.
2. Enter http://your-server-name:94 in the URL of the browser where:
Your-server-name is the hostname of the Tivoli server where Remote
Control server and the Remote Control Web Access files have been
installed.
94 is the TCP port of the oserv on this Tivoli server.
3. Select Remote Control from the list of available Web Access applications.

Web Browser Integration

103

Figure 62. Tivoli Remote Control Web Access - First Panel

4. Refer to Figure 62 on page 104 and fill in the three fields on the panel,
where:
Remote Control Server is the name of the Remote Control tool (icon) to
be launched.
Controller is the hostname of the Remote Control controller for this
Remote Control session and should be the hostname of this
workstation.
Select the correct workstation type of the Controller from the list using
radio buttons.
Target is the hostname of the intended target for this Remote Control
session.
Select the correct workstation type of the Target from the list using the
radio buttons.

104

Implementing Tivoli Remote Control In Large Enterprises

5. Click on the >> button to continue.


Note

If this is your attempt to initiate Remote Control after starting the Web
browser, you will see a pop-up panel at this point requesting user ID and
Password. You will need to enter a valid user ID and Password that has
the correct Tivoli authority and roles in the appropriate policy regions to
successfully complete the Remote Control session. For the test
scenario, the Administrator user ID and password were used.

Figure 63. Tivoli Remote Control Web Access - Second Panel

6. Refer to Figure 63 on page 105 and select the Action from the drop down
list, where Action is one of the following:
monitor
controla
controlm

Web Browser Integration

105

reboot
7. Click on the >> button to continue.

Figure 64. Tivoli Remote Control Web Access - Third Panel

8. Refer to Figure 64 on page 106, and select the desired options, then click
on the Start button. If you have selected the Default for any option, the
option takes the value set in the governing policy method for the instance
of the Remote Control Tool that was entered into the Remote Control
Server field on the first panel. Also, if any method in the governing policy
object has been set with -locked, that option cannot be changed, and that
option uses the setting in the policy object method.

106

Implementing Tivoli Remote Control In Large Enterprises

When the Remote Control session is terminated, or if it did not start correctly,
the result, or error message, will be displayed on the Web Access panel.

8.4.2 Running on Node without Remote Control Controller


Perform the following steps to run on node without Remote Control controller:
1. Start the Web browser.
2. Enter http://your-server-name:94 in the URL of the browser where:
Your-server-name is the hostname of the Tivoli Server where Remote
Control server and the Remote Control Web Access files have been
installed.
94 is the TCP port of the oserv on this Tivoli Server.
3. Select Remote Control from the list of available Web Access
applications.
4. Refer to Figure 62 on page 104 and fill in the three fields on the panel
where:
Remote Control Server is the name of the Remote Control tool (icon) to
launch.
Controller is the hostname of the Remote Control controller for this
Remote Control session. This is the hostname of the workstation where
the Remote Control GUI will run for this session.
Select the correct workstation type of the Controller from the list using
the radio buttons.
Note

There needs to be a person present at the Controller node since the


Remote Control session cannot be terminated from the node that
launched Remote Control through Web Access.
Target is the hostname of the intended target for this Remote Control
session. Leave this field blank to select a target from the list on the
second panel.
5. Click on the >> button to continue.

Web Browser Integration

107

Note

If this is the first attempt to initiate Remote Control after starting the
browser, you will see a pop-up panel at this point requesting UserID and
Password. You will need to enter a valid UserID and Password that has
the correct Tivoli authority and roles in the appropriate policy regions in
order to successfully complete the Remote Control session. For our
scenario, the Administrator user ID and password were used.

Figure 65. Tivoli Remote Web Access with Target List

6. Select the desired target from the list.

108

Implementing Tivoli Remote Control In Large Enterprises

7. Refer to Figure 63 on page 105 and select the Action from the drop down
list, where Action is one of the following:

monitor
controla
controlm
reboot

8. Click on the >> button to continue.


9. Refer to Figure 64 on page 106 and select the desired options, then click
on the Start button. If you have selected the Default for any option, it will
take the value set in the governing policy method for the instance of the
Remote Control Tool that was entered into the Remote Control Server field
on the first panel. Also, if any method in the governing policy object has
been set with -locked, that option cannot be changed, and that option will
use the setting in the policy object method.
When the Remote Control session has started, or, if it did not start correctly,
the result, or error message, is displayed on the Web Access panel. If the
session did start correctly, the OK message appears on the Web Access
panel, but the control of terminating the Remote Control session is on the
node designated as the controller for this session.

8.4.3 Changing the Target List


If you would prefer to select a target from a list, do not enter a target name on
the first Remote Control Web Access panel; see Figure 62 on page 104.
When the second panel is displayed, there will be a drop down entry box
containing the list of possible targets. The default list will be all endpoints, all
managed nodes, and all PC managed nodes. To eliminate a particular node
type from the list, on the Tivoli server where the Web Access for Remote
Control files were installed, go to the $BINDIR/TAS/HTTPd/cgi-bin/pcremote
directory and edit the file pcremote.cgi. For example, if you want to remove
managed nodes from the list of targets, change:
@TARGETS = wgetallinst ManagedNode;
foreach $TARGET (@TARGETS) {
print ("<OPTION> $TARGET# ManagedNode");
{

to read
# @TARGETS = wgetallinst ManagedNode;
# foreach $TARGET (@TARGETS) {
#
print ("<OPTION> $TARGET# ManagedNode");
# {

Web Browser Integration

109

After this change, the list of targets will include only endpoints and PC
Managed nodes.

110

Implementing Tivoli Remote Control In Large Enterprises

Chapter 9. Installation Tips for Endpoints


Tivoli Remote Control provides different ways of installing the controller or
target on an endpoint node. As with previous releases of Remote Control,
managed nodes and PC managed nodes can be installed using the Desktop
Install Product, or, with Framework Release 3.6, Software Installation
Services (SIS) can be used. Endpoint nodes cannot be installed using these
installation facilities. You must use Tivoli Software Distribution (SWD), or, for
Windows clients, you can use the InstallShield process. This chapter
discusses the methods of installing the Remote Control controller or target to
endpoint nodes.
Note

This chapter pertains to Remote Control Releases 3.6 and 3.6.1 only.
Future releases of Remote Control are planned to support caching for
automated installations on endpoints.

9.1 Using Tivoli Software Distribution


The Remote Control CD-ROM includes binaries and sample profiles to install
the Remote Control target or controller on an endpoint using Tivoli Software
Distribution. You should copy the Remote Control CD contents to the
managed node where you plan to have all Tivoli installation images.
Note

These binaries and sample profiles can only be used to install the
controller or target on endpoints. They are not valid for installation on other
types of clients.

9.1.1 Update REGILOG.INI for Windows NT Endpoint


By default, an NT endpoint does not have a Tivoli registry key. If this is not
added, the Remote Control Target registry key and values will not be added
during installation. To ensure that the Tivoli registry key is created, edit
<drive:\path>\SDPACK\WINNT\TGT\SYS\SET\Regilog.ini. Just before the
statement \registry\machine\SOFTWARE\Tivoli\Remote Control
Target, add \registry\machine\SOFTWARE\Tivoli as a separate line
with a blank line before and after it. You will also need to add the RCPath line
to the last entry. The end of Regilog.ini should look similar to Figure 66 on
page 112.

Copyright IBM Corp. 1999

111

.
.
.
\registry\machine\SYSTEM\CurrentControlSet\Services\TGrab
ErrorControl = REG_DWORD 0
Start = REG_DWORD 1
Type = REG_DWORD 1

\registry\machine\SOFTWARE\Tivoli
\registry\machine\SOFTWARE\Tivoli\Remote Control Target
Logging = REG_DWORD 0
Trace Length = REG_DWORD 0
Target = REG_DWORD 1
Build = REG_DWORD 00360001
Version = REG_SZ 3.6

RCPath = REG_SZ c:\Tivoli\pcremote

Figure 66. Add Registry Key to REGILOG.INI - Remote Control

If you are using Tivoli Software Distribution to install only the Remote Control
Controller to a Windows NT endpoint, edit
<drive:\path>\SDPACK\WINNT\CTL\Regilog.ini and add
\registry\machine\SOFTWARE\Tivoli to the top of the file, then add the
RCPath statement as the last line. The Remote Control Controller Regilog.ini
should look similar to Figure 67 on page 112.

\registry\machine\SOFTWARE\Tivoli
\registry\machine\SOFTWARE\Tivoli\Remote Control Controller
Logging = REG_DWORD 0
Trace Length = REG_DWORD 0
Controller = REG_DWORD 1
Build = REG_DWORD 00360001
Version = REG_SZ 3.6

RCPath = REG_SZ c:\Tivoli\pcremote

Figure 67. Add Registry Key to REGILOG.INI - Remote Control Controller Only

Now, you are ready to use Tivoli Software Distribution.

9.1.2 Step-by-Step Installation Procedure


To perform the Remote Control installation, follow these steps:
1. Select the Create -> Profile option of the Profile Manager dialog to create
a FilePackage profile.

112

Implementing Tivoli Remote Control In Large Enterprises

Note

You have to create a profile for each type of package that you want to
install.
2. Select the Properties... option in the profile menu. The File Package
Properties dialog is displayed.
3. Select the File Package -> Import option to import a sample profile.
The following profiles are included in the /SDPACK/PROFILES directory of
the product CD-ROM and can be used as samples for the installation:
OS2CTL.PRF

for the OS/2 controller

OS2TGT.PRF

for the OS/2 target

WIN31TGT.PRF

for the Windows 3.x target

WIN95CTL.PRF

for the Windows 95 controller

WIN95TGT.PRF

for the Windows 95 target

WINNTCTL.PRF

for the Windows NT controller

WINNTTGT.PRF

for the Windows NT target

4. Select one of the sample profiles and select the Import & Close button.
5. If you are asked to specify a source host, select the host where the files to
be distributed are stored.
6. In the Source Directories & Files field, specify the following path:
x:/SDPACK/operating_system/component/*

where:
x

is the drive where you have the product CD-ROM.

operating_system

is one of the following:


OS2

Installation Tips for Endpoints

113

WIN31
WIN95
WINNT
component

is one of the following:


TGT
CTL

Note

The specified source directory must not be enclosed by quotes.


7. Remove other source directories if they are specified.
8. In the Log Information Options field, specify the Host and the log file
name.
9. To change the directory where you want to install the Remote Control
component, select the Edit -> Platform-Specific Options -> System
Options option. The File Package System Options dialog is displayed.
10.If you change the directory in the Destination Directory Path field, select
the After Distribution button and specify the same path for the program
specified in the Enter BAT/EXEC/COM file name field.
11.Select the Set & Close button to exit the File Package Options dialog.
12.Select the Save & Close button to exit the File Package Properties dialog.
13.From the Profile Manager dialog, distribute the selected profile to the
subscribers.
For more information about a FilePackage profile, see the Tivoli Software
Distribution Users Guide Version 3.6 , GC31-8330.

9.2 Using InstallShield to Install on Windows Endpoints


Most Windows programs use InstallShield as the primary method for
installing their product. The default method for installing Remote Control
controller or target on a Windows endpoint is to use InstallShield to install
directly from the product CD onto the Windows endpoint. This is documented
in the Tivoli Remote Control Users Guide Version 3.6, GC31-8437, and the
Tivoli Remote Control Release Notes Version 3.6 .
This section discusses using InstallShield to install from a CD image residing
on a managed node which can be some distance from the Windows endpoint.

114

Implementing Tivoli Remote Control In Large Enterprises

9.2.1 Response Files to Use with InstallShield


There are sample InstallShield response files on the Remote Control product
CD under the \lcf4win\rspfiles directory. There is a separate setup.iss for
each of the following supported platforms in a directory of the platform
named:
NT35X
NT40
WIN3X
WIN95
The setup.iss for WIN3X is for target only because Windows 3.x only
supports the Remote Control target. The other three contain setup responses
for both the controller and target. If you want to install only one of the
components, you should copy the CD image to a managed node were you
can modify the setup.iss to include only the component to be installed. Figure
68 on page 116 is an example of setup.iss copied to tgt.iss and modified for
installation of only the Remote Control target on a Windows NT 4.0 endpoint.
[InstallShield Silent]
Version=v5.00.000
File=Response File
[Application]
Name=Remote Control Target
Version=3.6
Company=Tivoli
[DlgOrder]
Dlg0=SdWelcome-0
Count=5
Dlg1=SdComponentDialog2-0
Dlg2=SdAskDestPath-0
Dlg3=SdStartCopy-0
Dlg4=SdFinishReboot-0
[SdWelcome-0] Result=1
[SdComponentDialog2-0]
Remote Control Target (Windows NT 4.0)-type=string
Remote Control Target (Windows NT 4.0)-count=12
Remote Control Target (Windows NT 4.0)-0=Remote Control Target (Windows NT 4.0)\Program
Remote Control Target (Windows NT 4.0)-1=Remote Control Target (Windows NT 4.0)\Help
Remote Control Target (Windows NT 4.0)-2=Remote Control Target (Windows NT 4.0)\Libraries
Remote Control Target (Windows NT 4.0)-3=Remote Control Target (Windows NT 4.0)\Service
Remote Control Target (Windows NT 4.0)-4=Remote Control Target (Windows NT 4.0)\Remove Service
Remote Control Target (Windows NT 4.0)-5=Remote Control Target (Windows NT 4.0)\Drivers
Remote Control Target (Windows NT 4.0)-6=Remote Control Target (Windows NT 4.0)\Video Drivers
Remote Control Target (Windows NT 4.0)-7=Remote Control Target (Windows NT 4.0)\Hooking
Remote Control Target (Windows NT 4.0)-8=Remote Control Target (Windows NT 4.0)\Help FRA
Remote Control Target (Windows NT 4.0)-9=Remote Control Target (Windows NT 4.0)\Help PTB
Remote Control Target (Windows NT 4.0)-10=Remote Control Target (Windows NT 4.0)\Libraries FRA
Remote Control Target (Windows NT 4.0)-11=Remote Control Target (Windows NT 4.0)\Libraries PTB
Component-type=string
Component-count=1
Component-0=Remote Control Target (Windows NT 4.0)
Result=1
[SdAskDestPath-0]
szDir=C:\TIVOLI\PCREMOTE

Installation Tips for Endpoints

115

Result=1
[SdStartCopy-0]
Result=1
[SdFinishReboot-0]
Result=1
BootOption=0

Figure 68. SETUP.ISS for RC Target Install on NT 4.0 Endpoint

Note

If you wish to reboot the endpoint as soon as Remote Control is installed,


in the Response file(.iss), set BootOption=3.

9.2.2 The SETUP.INI File


If you intend to do a silent install, you must modify setup.ini, which is in the
\lcf4win\cdrom\west\disk1 directory. Change EnableLangDlg=Y to
EnableLangDlg=N. Changing EnableLangDlg to N suppresses the language
dialog at the Windows endpoint during the installation.

9.2.3 Starting the InstallShield Install


Whether you use a logon script or some other means to initiate the install
using InstallShield, you must use the correct parameters when starting
setup.exe. In our scenario, we used a batch file on a Windows NT endpoint to
install Remote Control target at the first login of the Administrator. The file,
rcinst.bat, was placed in the Winnt\Profiles\Administrator\Start
Menu\Programs\Startup directory on the NT endpoint. At the next login of the
Administrator on the endpoint, rcinst.bat executed, and Remote Control
target was installed on the endpoint.

REM This is to install RC Target if not already installed.


set RCDIR=c:\Tivoli\Pcremote
REM Check for previous install of RC Target
if exist %RCDIR%\eqnrcmai.exe goto end
set PROGFILE=\\ostmr\36
set RSPFILE=\\ostmr\rspfiles
REM Connect to network drives
net use p: %PROGFILE%
net use r: %RSPFILE%
set ISHIELDOPTS=-s -SMS -f1r:\nt40\tgt.iss -f2c:\rcinst.log
REM Do Silent Install of RC Target
start p:\setup.exe %ISHIELDOPTS%
:end

Figure 69. Remote Control Install Batch File - RCINST.BAT

116

Implementing Tivoli Remote Control In Large Enterprises

For our scenario, we copied the Remote Control CD-ROM images to the TMR
server running Windows NT 4.0. Two drive shares were defined on the TMR
server, one was ostmr\36 which pointed to
<drive>:\Install\RCimages\lcf4win\cdrom\west\disk1, and the other was
ostmr\rspfiles, which pointed to <drive>:\Install\RCimages\lcf4win\respfiles.
The Remote Control target was installed on the Windows NT endpoint in
c:\Tivoli\Pcremote.
The InstallShield setup.exe options used were:
-s

Run InstallShield Silent to execute a silent


installation.

-SMS

Prevents a network connection and the Setup.exe


from closing before the installation is complete.

-f1<path\ResponseFile>

The location and name of the response file (*.iss).

-f2<path\LogFile>

(Optional) Location and name of the installation


log file.

This is one method to automate the installation of Remote Control to a


Windows endpoint using a logon script. Please see Installing with Logon
Scripts in the TME 10 Framework Installation and Planning Guide Version
3.6, SC31-8432, Chapter 8 for more detail. Tivoli has a Windows NT logon
script available from ftp.tivoli.com (146.84.1.5). Login as anonymous and use
your e-mail address as the password. Change to /support/patches/unofficial
and get the file named ntlogon.bat. This sample script contains comments to
assist you in modifying the script to suit your purposes. The script contains
the information necessary to install the endpoint at the first logon, but the
script could be changed to install Remote Control instead. In our scenario,
there was no Windows NT domain controller; so, the logon script was placed
on the endpoint instead of a domain controller.

9.2.4 Checking for Errors


When using InstallShield silent install, a Result Code is generated and placed
into the log file. If you did not specify a log file (-f2 option), the default,
setup.log, is written to the same directory where setup.exe resides.
InstallShield places one of the following return values in the
[ResponseResult] section of the log file:
0
-1
-2
-3

Success
General error
Invalid Mode
Required data not found in the Setup.iss file

Installation Tips for Endpoints

117

-4
-5
-6
-7
-8
-9
-10
-11
-12
-51
-52
-53

Not enough memory available


File does not exist
Cannot write to the response file
Unable to write to the log file
Invalid path to the InstallShield Silent response file
Not a valid list type(string or number)
Data type is invalid
Unknown error during setup
Dialogs are out of order
Cannot create the specified folder
Cannot access the specified file or folder
Invalid option selected

9.3 Using Diskettes to Install on Windows Endpoints


The Remote Control product CD includes facilities for making diskettes from
which to install Remote Control on the Windows endpoint. Using either the
CD or a CD image on a managed node, go to
<drive:\path>\lcf4win\floppy\Lang\Type:
where <drive:\path> is the full path to the source images,
and where Lang is one of the following:

ENGLISH
FRENCH
JAPANESE
PORTUGUESE

and where Type is one of the following:


WIN3X
WIN95
WINNT35X
WINNT40
Run MKRCDSK.BAT to make the appropriate diskettes.
At the Windows endpoint, insert Disk1 and run <drive>:\setup.exe to install
Remote Control Controller, Target, or both.

118

Implementing Tivoli Remote Control In Large Enterprises

9.4 Unattended Install on OS/2 Endpoints


The same file, INSTALL.EXE, is used for an unattended installation for an
OS/2 endpoint, but parameters must be added to the invocation of the
process. The same basic process as the silent install for Windows endpoints
is used.

9.4.1 Starting the Install


You create a drive share on the managed node where the CD-ROM image
was copied. Then, you create a small.BAT file to net use to the shared drive
on the managed node and copy the necessary OS/2 files to the endpoint,
preferably into a temporary directory. Now, the installation is initiated for the
unattended install of Remote Control on the OS/2 endpoint. Remember that
INSTALL.EXE is an OS/2 file and needs to be run on the OS/2 endpoint. The
command line is as follows:
<drive:\path>\install.exe /A:I /L1:<drive:\path> /O:DRIVE /R:<RspFile>
/T:<drive:\path> /X

where:
<drive:\path>

Is the drive and path to the install.exe file on the managed


node.

/A:I

The action to be performed. In our case, it is Install.

/L1:<drive:\path> The drive and path to the install error log file.
/O:

The originating system. This must be DRIVE.

/R:<RspFile>

The drive, path and file name of the specific response file.

/T:<drive:\path>

The drive and path where the product files will be installed
on the target.

/X

Specifies that this is to be an unattended action.

9.5 Using Diskettes to Install on OS/2 Endpoints


This procedure is fully documented in the Tivoli Remote Control Users Guide
Version 3.6, GC31-8437, Chapter 2, in the section Installing on OS/2
Machines.

Installation Tips for Endpoints

119

120

Implementing Tivoli Remote Control In Large Enterprises

Appendix A. GetNewEPs.sh
The GetNewEPs.sh script performs this task by building a temporary list of all
the defined endpoints using the wgetallinst command, and then it compares
this list against the list of Remote Control targets in C:\RCTOOLS. The script
extracts the names of the machines that do not exist in the temporary list, but
do exist in the C:\RCTOOLS list. This task simultaneously removes machines
which are no longer defined in the TMR from the list of Remote Control
Targets, while adding any new RC Targets to the list.

#!/bin/sh
# Create list of all endpoints with Remote Control Target
# installed to be used by RC policy method rc_def_targets

RCList=c:/rctools/list.txt # All EP targets for rc_def_targets


WLookList=c:/rctools/temp/WlookList.txt # List of all EPS
TL=c:/rctools/temp/tl.txt # Nodes in WLooklist and not in RCList
TL1=c:/rctools/temp/tl1.txt

# created for temporary purpose

GetRCs=c:/rctools/temp/getrcs.txt # Output file wruntask command

rm -f $WLookList
rm -f $TL
rm -f $TL1
rm -f $GetRCs

echo "Building a list of defined Endpoints"


wgetallinst Endpoint > $WLookList # obtain list of all endpoints
echo "

Copyright IBM Corp. 1999

...done"

121

# If a list of targets exists, this checks for new possible targets and adds
them
if [ -f $RCList ]

# check if the RCList list is there

then
echo "Obtaining list of new EPs"
LIST=cat $WLookList
for i in $LIST # check for machines in WLookList and not RCList
do
grep -ix "$i" $RCList > /dev/null
RC=$?
if [ $RC -ne 0 ]
then
echo $i >> $TL

# if the node is not in RCList write to TL

fi
done

LIST=cat $RCList
echo "Building list of valid EPs in RC list"
for i in $LIST

# check the RCList content against WLookList

do

grep -ix "$i" $WLookList > /dev/null


RC=$?
if [ $RC -eq 0 ]

# if the node is in both lists then write it to TL1

then
echo $l >> $TL1
fi
done

122

Implementing Tivoli Remote Control In Large Enterprises

if [ -f $TL1 ]
then
echo "Refreshing $RCList from $TL1" # Debug line
cat $TL1 > $RCList

# refresh RCList

fi

else
cat $WLookList > $TL

# If no RCList list create node list

fi

LIST=cat $TL
rtcmd=wruntask -t "Is RC Installed" -l "RC Tools" -m 30 -M parallel -o 15

for i in $LIST

# Build wruntask command line

do
rtcmd="$rtcmd -h $i"
done

echo "Executing command $rtcmd"


echo $rtcmd > c:/rctools/go.cmd
c:/rctools/go.cmd > $GetRCs# Query list of possible new targets

echo "Retrieving RC Target names" # Only those with RC installed


cat $GetRCs | grep VALIDRC | awk -F: {print $2} > $TL

cat $TL

# DEBUG

GetNewEPs.sh

123

LIST=cat $TL
ctr=0
for i in $LIST
do

If new Targets, add to the list

echo $i >> $RCList


echo "Added $i to list"
ctr=1
done

if [ $ctr -ne 0 ]
then
echo "Restarting the EP Gateway"
wgateway ostmr restart

# restart the EP Gateway after link

else
echo "No EP Gateway restart required"
fi

cat $RCList | sort -u > $TL1

# Sort RCList

cat $TL1 > $RCList

# Refresh the list

echo "$RCList created/updated"

124

Implementing Tivoli Remote Control In Large Enterprises

Appendix B. SETUP.ISS
There are sample InstallShield response files on the Remote Control product
CD under the \lcf4win\rspfiles directory. There is a separate setup.iss for
each of the following supported platforms. Below is a SETUP.ISS modified for
installation of only the Remote Control target on a Windows NT 4.0 endpoint.
[InstallShield Silent]
Version=v5.00.000
File=Response File
[Application]
Name=Remote Control Target
Version=3.6
Company=Tivoli
[DlgOrder]
Dlg0=SdWelcome-0
Count=5
Dlg1=SdComponentDialog2-0
Dlg2=SdAskDestPath-0
Dlg3=SdStartCopy-0
Dlg4=SdFinishReboot-0
[SdWelcome-0] Result=1
[SdComponentDialog2-0]
Remote Control Target (Windows NT 4.0)-type=string
Remote Control Target (Windows NT 4.0)-count=12
Remote Control Target (Windows NT 4.0)-0=Remote Control Target (Windows NT
4.0)\Program
Remote Control Target (Windows NT 4.0)-1=Remote Control Target (Windows NT
4.0)\Help
Remote Control Target (Windows NT 4.0)-2=Remote Control Target (Windows NT
4.0)\Libraries

Copyright IBM Corp. 1999

125

Remote Control Target (Windows NT 4.0)-3=Remote Control Target (Windows NT


4.0)\Service
Remote Control Target (Windows NT 4.0)-4=Remote Control Target (Windows NT
4.0)\Remove Service
Remote Control Target (Windows NT 4.0)-5=Remote Control Target (Windows NT
4.0)\Drivers
Remote Control Target (Windows NT 4.0)-6=Remote Control Target (Windows NT
4.0)\Video Drivers
Remote Control Target (Windows NT 4.0)-7=Remote Control Target (Windows NT
4.0)\Hooking
Remote Control Target (Windows NT 4.0)-8=Remote Control Target (Windows NT
4.0)\Help FRA
Remote Control Target (Windows NT 4.0)-9=Remote Control Target (Windows NT
4.0)\Help PTB
Remote Control Target (Windows NT 4.0)-10=Remote Control Target (Windows NT
4.0)\Libraries FRA
Remote Control Target (Windows NT 4.0)-11=Remote Control Target (Windows NT
4.0)\Libraries PTB
Component-type=string
Component-count=1
Component-0=Remote Control Target (Windows NT 4.0)
Result=1
[SdAskDestPath-0]
szDir=C:\TIVOLI\PCREMOTE
Result=1
[SdStartCopy-0]
Result=1
[SdFinishReboot-0]
Result=1
BootOption=0

126

Implementing Tivoli Remote Control In Large Enterprises

Appendix C. Special Notices


This publication is intended to help technical professionals who must install
and configure Tivoli Remote Control. The information in this publication is not
intended to be the specification of any programming interfaces that are
provided by Tivoli Remote Control. See the PUBLICATIONS section of the
IBM Programming Announcement for Tivoli Remote Control for more
information about what publications are considered to be product
documentation.
References in this publication to IBM products, programs or services do not
imply that IBM intends to make these available in all countries in which IBM
operates. Any reference to an IBM product, program, or service is not
intended to state or imply that only IBMs product, program, or service may be
used. Any functionally equivalent program that does not infringe any of IBMs
intellectual property rights may be used instead of the IBM product, program
or service.
Information in this book was developed in conjunction with use of the
equipment specified and is limited in application to those specific hardware
and software products and levels.
IBM may have patents or pending patent applications covering subject matter
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 the IBM
Director of Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood,
NY 10594 USA.
Licensees of this program who wish to have information about it for the
purpose of enabling: (i) the exchange of information between independently
created programs and other programs (including this one) and (ii) the mutual
use of the information which has been exchanged, should contact IBM
Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and
conditions, including, in some cases, payment of a fee.
The information contained in this document has not been submitted to any
formal IBM test and is distributed AS IS. The information about non-IBM
(vendor) products in this manual has been supplied by the vendor, and IBM
assumes no responsibility for its accuracy or completeness. The use of this
information or the implementation of any of these techniques is a customer
responsibility and depends on the customer's ability to evaluate and integrate
them into the customer's operational environment. While each item may have

Copyright IBM Corp. 1999

127

been reviewed by IBM for accuracy in a specific situation, there is no


guarantee that the same or similar results will be obtained elsewhere.
Customers attempting to adapt these techniques to their own environments
do so at their own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of
these Web sites.
Any performance data contained in this document was determined in a
controlled environment, and therefore, the results that may be obtained in
other operating environments may vary significantly. Users of this document
should verify the applicable data for their specific environment.
Reference to PTF numbers that have not been released through the normal
distribution process does not imply general availability. The purpose of
including these reference numbers is to alert IBM customers to specific
information relative to the implementation of the PTF when it becomes
available to each customer according to the normal IBM PTF distribution
process.
The following terms are trademarks of the International Business Machines
Corporation in the United States and/or other countries:
AIX
AT
CT
IBM
OS/2
RACF
S/390
System/390
XT

AS/400
BookManager
DB2
NetView
OS/390
RS/6000
SP
VisualAge
400

The following terms are trademarks of other companies:


C-bus is a trademark of Corollary, Inc. in the United States and/or other
countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other
countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.

128

Implementing Tivoli Remote Control In Large Enterprises

PC Direct is a trademark of Ziff Communications Company in the United


States and/or other countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel
Corporation in the United States and/or other countries. (For a complete list
of Intel trademarks see www.intel.com/dradmarx.htm)
UNIX is a registered trademark in the United States and/or other countries
licensed exclusively through X/Open Company Limited.
Other company, product, and service names may be trademarks or service
marks of others.

Special Notices

129

130

Implementing Tivoli Remote Control In Large Enterprises

Appendix D. Related Publications


The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.

D.1 International Technical Support Organization Publications


For information on ordering these ITSO publications see How to Get ITSO
Redbooks on page 135.

Developing Plus Modules for Tivoli with the TME 10 Integration Toolkit,
SG24-2007
Getting Started with TME 10 User Administration, SG24-2015
Managing Access from Desktop to Datacenter: Introducing TME 10
Security Management, SG24-2021
TME 10 Framework Version 3.2: An Introduction to the Lightweight Client
Framework, SG24-2025
Implementing TME 10 in High Availability Environments, SG24-2032
Tivoli Enterprise Internals and Problem Determination, SG24-2034
New Features in Tivoli Software Distribution 3.6, SG24-2045
Integrating TME 10 on the RS/6000 SP, SG24-2071
Managing a Notes Environment with TME 10 Module for Domino Version
1.5, SG24-2104
A First Look at TME 10 Distributed Monitoring 3.5, SG24-2112
Using the VisualAge for Smalltalk Tivoli Connection to Create a
Tivoli-Manageable Application, SG24-2114
TME 10 Deployment Cookbook: Inventory and Company, SG24-2120
An Industry Around the Tivoli Framework: Examples From the 10/Plus
Association, SG24-2122
TME 10 Inventory 3.2: New Features and Database Support, SG24-2135
Measuring Lotus Notes Response Times with Tivoli's ARM Agents,
SG24-4787
Examples of Using TME 10 NetView for AIX V5 and TME 10 NetView for
Windows NT, SG24-4898
TME 10 Global Enterprise Manager Event/Automation and User
Administration, SG24-4921

Copyright IBM Corp. 1999

131

An Introduction to TME 10 NetView for OS/390, SG24-4922


Migrating from Systems Monitor for AIX to TME 10 Distributed Monitoring,
SG24-4936
An Introduction to Tivoli's TME 10, SG24-4948
The TME 10 Deployment Cookbook: Courier and Friends, SG24-4976
Tivoli Security Management Design Guide, SG24-5101
Tivoli User Administration Design Guide, SG24-5108
Using Tivoli Software Installation Service for Mass Installations,
SG24-5109
Using Databases with Tivoli Applications, SG24-5112
SLR to Tivoli Performance Reporter for OS/390 Migration Cookbook,
SG24-5128
Deploying a Tivoli Infrastructure in Large-Scale Environments, SG24-5210
Creating Custom Monitors for Tivoli Distributed Monitoring, SG24-5211
TEC Implementation Examples, SG24-5216
Managing RDBMS Servers With Tivoli, SG24-5240
Integrated Management Solutions Using NetView Version 5.1, SG24-5285
Managing SAP R/3 with Tivoli, SG24-5298
Problem Management Using Tivoli Service Desk and the TEC, SG24-5301
The OS/390 Security Meets Tivoli: Managing RACF with Tivoli Security
Products, SG24-5339
Laying the Foundation for Tivoli Modules, SG24-5379

D.2 Redbooks on CD-ROMs


Redbooks are also available on CD-ROMs. Order a subscription and receive
updates 2 to 4 times a year at significant savings.

CD-ROM Title
System/390 Redbooks Collection
Networking and Systems Management Redbooks Collection
Transaction Processing and Data Management Redbook
Lotus Redbooks Collection
Tivoli Redbooks Collection

132

Implementing Tivoli Remote Control In Large Enterprises

Subscription
Number
SBOF-7201
SBOF-7370
SBOF-7240
SBOF-6899
SBOF-6898

Collection Kit
Number
SK2T-2177
SK2T-6022
SK2T-8038
SK2T-8039
SK2T-8044

CD-ROM Title
AS/400 Redbooks Collection
RS/6000 Redbooks Collection (HTML, BkMgr)
RS/6000 Redbooks Collection (PostScript)
RS/6000 Redbooks Collection (PDF Format)
Application Development Redbooks Collection

Subscription
Number
SBOF-7270
SBOF-7230
SBOF-7205
SBOF-8700
SBOF-7290

Collection Kit
Number
SK2T-2849
SK2T-8040
SK2T-8041
SK2T-8043
SK2T-8037

D.3 Other Publications


These publications are also relevant as further information sources, and are
available from Tivoli Systems (an IBM Company):

TME 10 Remote Control Users Guide Version 3.6, GC31-8437


TME 10 Remote Control Release Notes Version 3.6, GI10-3021
TME 10 Framework Reference Manual Version 3.6, SC31-8434
TME 10 Framework Installation and Planning Guide Version 3.6,
SC31-8432
TME 10 Framework Release Notes Version 3.6, GI10-8014
TME 10 Enterprise Console Reference Manual Version 3.6, SC31-8505
TME 10 Enterprise Console Users Guide Version 3.6, GC31-8506
TME 10 Enterprise Console Release Notes Version 3.6, GI10-8020
TME 10 Software Distribution Users Guide Version 3.6, GC31-8330
An Introduction To Tivolis TME 10, (ISBN 0-13-899717-9) .
The FireWall-1 User Guide describes the Check Point FireWall-1 products
and consists of the following product documentation, which is available from
Check Point Software Technologies, Inc.:

Getting Started with Firewall-1


Managing FireWall-1 Using the OpenLook GUI
Managing FireWall-1 Using the Windows GUI
FireWall-1 Architecture and Administration
Virtual Private Networking with FireWall-1
Account Management Client

Related Publications

133

The Floodgate-1 User Guide describes the Check Point Floodgate-1 products
and consists of the following product documentation, which is available from
Check Point Software Technologies, Inc.:

Getting Started with Floodgate-1


Architecture and Administration
Floodgate-1 QuickStart Guide, Version 1.0
Getting Started with FireWall-1
Managing FireWall-1 Using the Windows GUI

D.4 Other References


The IBM Software Glossary that contains terminology for software, the
Internet, and products from Tivoli is available at the Web site
http://www.networking.ibm.com/nsg/nsgmain.htm. You can use this site to
search for the definition of a term or retrieve the entire glossary in PDF or
PostScript format.

134

Implementing Tivoli Remote Control In Large Enterprises

How to Get ITSO Redbooks


This section explains how both customers and IBM employees can find out about ITSO redbooks,
CD-ROMs, workshops, and residencies. A form for ordering books and CD-ROMs is also provided.
This information was current at the time of publication, but is continually subject to change. The latest
information may be found at http://www.redbooks.ibm.com/.

How IBM Employees Can Get ITSO Redbooks


Employees may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and
information about redbooks, workshops, and residencies in the following ways:
Redbooks Web Site on the World Wide Web
http://w3.itso.ibm.com/

PUBORDER to order hardcopies in the United States


Tools Disks
To get LIST3820s of redbooks, type one of the following commands:
TOOLCAT REDPRINT
TOOLS SENDTO EHONE4 TOOLS2 REDPRINT GET SG24xxxx PACKAGE
TOOLS SENDTO CANVM2 TOOLS REDPRINT GET SG24xxxx PACKAGE (Canadian users only)

To get BookManager BOOKs of redbooks, type the following command:


TOOLCAT REDBOOKS

To get lists of redbooks, type the following command:


TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET ITSOCAT TXT

To register for information on workshops, residencies, and redbooks, type the following command:
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ITSOREGI 1998

REDBOOKS Category on INEWS


Online send orders to: USIB6FPL at IBMMAIL or DKIBMBSH at IBMMAIL
Redpieces
For information so current it is still in the process of being written, look at "Redpieces" on the
Redbooks Web Site (http://www.redbooks.ibm.com/redpieces.html). Redpieces are redbooks in
progress; not all redbooks become redpieces, and sometimes just a few chapters will be published
this way. The intent is to get the information out much quicker than the formal publishing process
allows.

Copyright IBM Corp. 1999

135

How Customers Can Get ITSO Redbooks


Customers may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and
information about redbooks, workshops, and residencies in the following ways:
Online Orders send orders to:
In United States
In Canada
Outside North America

IBMMAIL
usib6fpl at ibmmail
caibmbkz at ibmmail
dkibmbsh at ibmmail

Internet
usib6fpl@ibmmail.com
lmannix@vnet.ibm.com
bookshop@dk.ibm.com

Telephone Orders
United States (toll free)
Canada (toll free)

1-800-879-2755
1-800-IBM-4YOU

Outside North America


(+45) 4810-1320 - Danish
(+45) 4810-1420 - Dutch
(+45) 4810-1540 - English
(+45) 4810-1670 - Finnish
(+45) 4810-1220 - French

(long distance charges apply)


(+45) 4810-1020 - German
(+45) 4810-1620 - Italian
(+45) 4810-1270 - Norwegian
(+45) 4810-1120 - Spanish
(+45) 4810-1170 - Swedish

Mail Orders send orders to:


IBM Publications
Publications Customer Support
P.O. Box 29570
Raleigh, NC 27626-0570
USA

IBM Publications
144-4th Avenue, S.W.
Calgary, Alberta T2P 3N5
Canada

IBM Direct Services


Sortemosevej 21
DK-3450 Allerd
Denmark

Fax send orders to:


United States (toll free)
Canada
Outside North America

1-800-445-9269
1-800-267-4455
(+45) 48 14 2207

(long distance charge)

1-800-IBM-4FAX (United States) or (+1) 408 256 5422 (Outside USA) ask for:
Index # 4421 Abstracts of new redbooks
Index # 4422 IBM redbooks
Index # 4420 Redbooks for last six months
On the World Wide Web
Redbooks Web Site
IBM Direct Publications Catalog

http://www.redbooks.ibm.com
http://www.elink.ibmlink.ibm.com/pbl/pbl

Redpieces
For information so current it is still in the process of being written, look at "Redpieces" on the
Redbooks Web Site (http://www.redbooks.ibm.com/redpieces.html). Redpieces are redbooks in
progress; not all redbooks become redpieces, and sometimes just a few chapters will be published
this way. The intent is to get the information out much quicker than the formal publishing process
allows.

136

Implementing Tivoli Remote Control In Large Enterprises

IBM Redbook Order Form


Please send me the following:
Title

First name

Order Number

Quantity

Last name

Company
Address
City

Postal code

Country

Telephone number

Telefax number

VAT number

Card issued to

Signature

Invoice to customer number


Credit card number

Credit card expiration date

We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.

137

138

Implementing Tivoli Remote Control In Large Enterprises

List of Abbreviations
ACF

TEC Adapter
Configuration Facility

ACP

Application
Configuration Profile

EP

Endpoint

HTML

HyperText Markup
Language

HTTP

HyperText Transport
Protocol

IBM

International Business
Machines Corporation

IOM

Inter-Object Messaging

IT

Information Technology

ITSO

International Technical
Support Organization

LCF

Lightweight Client
Framework (now called
TMA)

ORB

Object Request Broker

SMB

Service Message Block

TMA

Tivoli Management
Agent

TMA

Tivoli Management
Architecture

TME

Tivoli Management
Environment

TMR

Tivoli Management
Region

RC

Tivoli Remote Control

URL

Uniform Resource
Locator

VPN

Virtual Private Network

Copyright IBM Corp. 1999

139

140

Implementing Tivoli Remote Control In Large Enterprises

Index
Symbols
$BINDIR 102
%BINDIR% 102
%s variable 97
_target 97

Numerics
2.1.1-RCL-0002 16, 23
3.6-RCL-0002 16, 23, 101
3.6-RCL-0003 101
38.4 Kbps 77
56 Kbps 79

A
abbreviations 139
absolute priorities 12
access
network 9
remote
secure 11
access control
network 35
accounting information 9
ACF
TEC Adapter Configuration Facility 84
ACK
TCP acknowledgment scheme 76
ACP profile 88
acronyms 139
ActiveX 9
address
IP 9, 39, 46, 72
dynamic 11
addressing schemes 9
agent
Tivoli Management Agent 37
alert 65
allocation
network 12
applets 9
attacks
network 9
audit trail 81
authentication 59
authentication scheme 62

Copyright IBM Corp. 1999

authorization roles 2
authrc.exe 101
availability
high 9

B
bandwidth
limited 11
bandwidth allocation 12
bandwidth management 12, 75, 76
bandwidth management policy 12
bandwidth policy 77
BAROC 89
bash 6, 27, 28
BncRC_on_Fail.rls 96
BounceIP.sh 95
BounceRC.CMD 94
bulk data transfer 37, 51

C
CA
Entrust Certificate Authorities 11
card
network interface 45
case sensitive 63
certificates
digital 11
Check Point Software Technologies 9
class
event 89, 93
client
NetWare 26
UNIX 16
communications
dial-up 11
Inter-ORB 36, 51
Inter-TMR 37
IOM 51
compliance 48
congestion
network 11, 12
connectionless protocol 76
considerations
performance 42
controla 105
controller

141

Remote Control 1, 2, 7, 40, 41, 70


controlm 6, 105
controlmr 55
cr_tec_db.sh 83
customer site (external) 49

D
daemon
HTTP 101
LCF 72
LCF gateway 36
TMA (LCF) 36
data link 45
data transfer
bulk 37, 51
database profile manager 84
datagram packet
NetBIOS 64
dataless profile manager 84
decryption 64
default policy 1
default policy method 2, 5
default policy object 5
default rule base 90
DefinableTargetList 15, 17
Desktop
Tivoli 14, 51, 73
Desktop Install Product 111
device
NAT 40
dial-up communications 11
digital certificates
X.509 11
digital signatures 11
direct requests 63
directory
pcremote 103
diskette 118
Dispatcher
Object 36
DNS server
proxy 40
DOS batch script 28
down-call 74
dynamic IP addressing 11
dynamic list 16
dynamic lists 13

142

E
encryption 11, 59, 64
IP-layer 11
encrytion scheme
FireWall-1 59
endpoint 17, 22, 26, 36
OS/2 119
endpoint ephemeral port 49
Endpoint Name list 22
engine
Intelligent Queuing 77
enterprise LAN 103
enterprise networking 9
Enterprise Security Management 9
Entrust Certificate Authorities (CA) 11
EP gateway 50
ephemeral 37, 39
endpoint port 49
ephemeral port 71
EQNRCMAI.EXE 27
error log 88
establishment
session 66
Event Adapter
TEC 88
event class 89, 93
event group 93
Event Log 82
events 84
standard 90
exposure
port 57
external
customer site 49

F
feedback mechanism 12
file
log 65, 117
response 117
FilteredList 15, 18, 20
firewall 35, 39, 53, 55, 63
FireWall Module 45
firewall placement 42
FireWall-1 9, 35, 59
FireWall-1 encrytion scheme 59
FireWall-1 gateway 11
FireWall-1 Rule Base 11

Implementing Tivoli Remote Control In Large Enterprises

fixed keys 59
FloodGate-1 9, 12
FQHN
Fully Qualified Host Names 40
Framework
Tivoli 35
ftp.tivoli.com 117
Fully Qualified Host Names (FQHN) 40
fwenc.exe 60
FWZ 59, 62

G
gateway 36
endpoint 50
FireWall-1 11
network 45
Remote Control 1, 40, 41
GetNewEPs.sh 28
GetRCs.sh 27
grace period 3, 98
group
event 93
notice 2

interconnected TMRs 16
interface
Web 55
internal
outsourser 49
internal network 68, 72
Internet 9, 10, 11, 35, 39, 75
Internet service 10, 11
Inter-Object Messaging (IOM) 37
inter-ORB communications 36, 51
inter-TMR communications 37
intranet 11
Inventory
Tivoli 13, 24, 33, 37
IOM
Inter-Object Messaging 37
IOM communications 51
IP address 9, 39, 46, 72
dynamic 11
ipconfig 46
IP-layer encryption 11
IPSec
Manual 59
IPX/SPX 36
ISAKMP/OAKLEY 59

H
help desk 3, 69, 75, 103
high availability 9
high source port 49
HKEY_LOCAL_MACHINE 60, 81
HTTP daemon 101
HTTP session 66, 68

I
IKE key 11
information
accounting 9
port 38
initial logon 49
Inspection
Stateful 10, 77
Install Product
Tivoli Desktop 111
installation
silent 117
unattended 119
InstallShield 111, 114
Intelligent Queuing engine 77

J
Java 9

K
Kbps
38.4 77
56 79
kernel
operating system 45
key
fixed 59
IKE 11
public 11
key management 59

L
LAN
enterprise 103
layer
network 45
LCF daemon 72

143

LCF gateway daemon 36


limited bandwidth 11
link
data 45
SLIP 77
list
dynamic 16
Endpoint Name 22
static 24
target 15
lists
dynamic 13
static 13
local service provider 59
log
error 88
log file 65, 117
Log Viewer 46
logging 9
logon
initial 49
logon script 116, 117
LSP
local service provider 59

M
managed node 17, 22, 26, 36
management
bandwidth 12, 75, 76
key 59
management policy
bandwidth 12
Manual IPSec 59
mapping
NAT 40
MDIST repeater 44
mechanism
feedback 12
method
policy 3, 6, 13, 24, 81, 106
default 2, 5
MKRCDSK.BAT 118
mobile users 10
model
security 1
Module
FireWall 45
monitor 6, 55, 105

144

N
NAT
Network Address Translation 39
NAT device 40
NAT mappings 40
nbname 66, 69
nbsession 66, 69
nbsession service 65
net use 65, 67
NetBIOS 64
NetBIOS datagram packets 64
NetBIOS session 69
net-space 35
NetWare 36
NetWare client 26
NetWare managed node 36
network
internal 68, 72
private 35, 39
secure 59
slow 55
network access 9
network access control 35
network address translation (NAT) 39
network attacks 9
network congestion 11, 12
network gateway 45
network interface card 45
network layer 45
network link
slow 55
Network Object Manager 46
network security 9, 35
network stacks
TCP/IP 10
network users 9
networking
enterprise 9
networks
public 9
notice group 2
nslookup 96
number
port 46

O
OAKLEY 59
object

Implementing Tivoli Remote Control In Large Enterprises

policy
default 5
Remote Control 14
Object Dispatcher 36
object identification (OID) 40
Object Request Brokers (ORBs) 36
odadmin 37, 39
odadmin set_port_range 39
OID
object identification 40
OPSEC 10
Open Platform for Secure Enterprise Connectivity
(OPSEC) 10
operating system kernel 45
options
trace 88
options.cgi 103
Oracle 7.3 83
ORB
Object Request Broker 36
OS/2 endpoint 119
outsourser site (Internal) 49

P
packet
datagram
NetBIOS 64
UDP 37, 49, 69
patches 101
PC managed node 22, 26, 36
pcremote directory 103
pcremote.cgi 103
pcremote.html 103
performance considerations 42
period
grace 3, 98
PKCS
Public Key Cryptography Standard 11
PKI 11
placement
firewall 42
policy
bandwidth 77
default 1
security 35, 46
policy method 3, 6, 13, 24, 81, 106
default 2, 5
policy object

default 5
Remote Control 14
policy region 22
port
ephemeral 71
high source 49
port 2501 38, 55, 57, 70
port 513 39
port 94 37
port 9494 37, 49, 51, 84
port 9495 37, 49, 70, 84
port exposure 57
port information 38
port number 46
port specific information 38
ports 30,000-35,000 51
pre-release version 82
priorities
absolute 12
weighted 12
private network 35, 39
secure 59
process
systems management 59
profile
ACP 88
profile manager
database 84
dataless 84
protocol
connectionless 76
protocol stack 45
TCP/IP 59
proxy 10
proxy DNS server 40
public key 11
Public Key Cryptography Standard (PKCS) 11
public networks 9

R
rc_def_alt_t 7
rc_def_checkinterp 13, 16
rc_def_command 6
rc_def_define 13, 15, 22, 23
rc_def_filter 18
rc_def_filter_mode 13, 19, 20, 21
rc_def_grace_time 7
rc_def_polfilter 20, 21

145

rc_def_polfilter_mode 13, 19
rc_def_ports 42
rc_def_targets 13, 17, 19, 23, 25, 33
rc_def_timeout_op 7
rc_def_uncheckedlist 13, 22, 23, 25, 26, 33
rcinst.bat 116
reboot 106
receiver window size 76
REG_DWORD 81
regilog.ini 111
region
policy 22
remote access
secure 11
Remote Control
Web Access 101
Remote Control controller 1, 2, 7, 40, 41, 70
Remote Control gateway 1, 40, 41
Remote Control policy object 14
Remote Control server 1, 14, 40
Remote Control service 36
Remote Control target 1, 14, 27, 32, 40, 41
Remote Control tool 14
Remote Control user 14
remote execution facility 39
remote_boot 2
remote_control 2
remote_monitor 2
remote_probe 2
RemoteControl 4
RemoteControl_PDO 14
repeater
MDIST 44
requests
direct 63
response file 117
Result Code 117
Retransmission Detection Early Drop 77
rexec 39
risk
security 1
roles 31
authorization 2
root.baroc 91
round trip time (RTT) 76
route
virtual 39
RTT
round trip time 76

146

Rule Base 46, 54


FireWall-1 11
rule base
default 90
rules
traffic 12

S
scheme
addressing 9
authrntication 62
encrytion
FireWall-1 59
script
DOS 28
logon 116, 117
secure private network 59
secure remote access 11
SecuRemote 9, 10, 59
security
network 9, 35
security model 1
security policy 35, 46
security risk 1
security services 9
select_gateway_policy 40
server
proxy DNS 40
Remote Control 1, 14, 40
TMR 13, 24, 28
service
Internet 10, 11
nbsession 65
Remote Control 36
TEC Event Adapter 88
Tivoli Remote Control 94
Service Manager 46
service pack
TEC 13 88
services
security 9
session
HTTP 66, 68
NetBIOS 69
type 98
session establishment 66
set_port_range
odadmin 39

Implementing Tivoli Remote Control In Large Enterprises

setup.iss 115
setup.log 117
signatures
digital 11
silent installation 117
Simple Key-Management for Internet Protocols
(SKIP) 59
SIS
Tivoli Software installation Services 111
SKIP (Simple Key-Management for Internet Protocols) 59
SLIP link 77
slow network links 55
SMB 69
SMTP 75
Software Distribution
Tivoli 37
Software Installation Services (SIS) 111
stack
protocol 45
TCP/IP 59
TCP/IP 10
standard events 90
StartRCSess.cmd 98
startsession.cgi 103
State Change on Target 3
Stateful Inspection 10, 77
static lists 13, 24
STDOUT 27
Sun Microsystems 59
system administrator 103
systems management process 59

T
target
Remote Control 1, 14, 27, 32, 40, 41
state change 3
target list 15
task
Tivoli 26
task library
Tivoli 30
taskbar
Windows NT 60
tasks 13
TCP acknowledgment (ACK) 76
TCP receiver window size 76
TCP/IP network stacks 10

TCP/IP protocol stack 59


TEC Adapter Configuration Facility (ACF) 84
TEC Event Adapter service 88
TEC service pack 13 88
tec.baroc 91
tecad_nt.baroc 89, 91
tecad_nt.cds 87
tecad_nt.conf 85
tecad_nt.exe 88
tecad_nt.fmt 86
tecad-nt.err 88
tecadnts.exe 88
tecrc.baroc 89, 91
Tivoli Desktop 14, 51, 73
Tivoli Framework 35
Tivoli Inventory 13, 24, 33, 37
Tivoli Managed Environment 35
Tivoli Management Agent 37
Tivoli Remote Control service 94
Tivoli Software Distribution 37
Tivoli task 26
Tivoli task library 30
TMA (LCF) daemon 36
TMR
interconnected 16
TMR server 13, 24, 28
tool
Remote Control 14
topology 61
tracing options 88
traffic rules 12
transparency 42
trip 39
type of session 98

U
UDP 49
UDP packet 37, 69
unattended installation 119
UncheckedList 15, 16, 22, 23
UNIX clients 16
up-call 69
URL 103
users
mobile 10
network 9
Remote Control 14

147

V
validation 62
VALIDRC 27, 32
variable
$BINDIR 102
%BINDIR% 102
%s 97
Virtual Private Networks (VPNs) 10
virtual route 39
VPN 10
Virtual Private Network 10
VPN-1 9

wsetpr 7
wstartsrv 92
wstopesvr 92

X
X.509 digital certificates 11

W
wcomprules 92, 97
wcrtjob 31
wcrtpol 5, 14
wcrtprf 85
wcrtprfmgr 84
wcrtrb 90
wcrtrim 83
wcrttask 31, 98
wdel 83
wdelrbrules 96
Web Access for Remote Control 101
Web interface 55
webrc.zip 101
WEBRC_install.sh 103
weighted priorities 12
wgetallinst 22, 23, 28
wgetpolm 4, 14
wildcard 93
wimprbclass 91
wimprbrules 96
window size
receiver
TCP 76
Windows NT Event Log 82
Windows NT taskbar 60
wloadrb 97
wlsac 85
wlspolm 4
wlsrbclass 92
wputpolm 6, 14
wrc 54, 71, 98
wruntask 95, 98
wschedjob 32
wsetpm 85

148

Implementing Tivoli Remote Control In Large Enterprises

ITSO Redbook Evaluation


Implementing Tivoli Remote Control in Large Enterprises
SG24-5125-00
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete
this questionnaire and return it using one of the following methods:
Use the online evaluation form found at http://www.redbooks.ibm.com
Fax this form to: USA International Access Code + 1 914 432 8264
Send your comments in an Internet note to redbook@us.ibm.com
Which of the following best describes you?
_ Customer _ Business Partner
_ Solution Developer
_ None of the above

_ IBM employee

Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction

__________

Please answer the following questions:


Was this redbook published in time for your needs?

Yes___ No___

If no, please explain:

What other redbooks would you like to see published?

Comments/Suggestions:

Copyright IBM Corp. 1999

(THANK YOU FOR YOUR FEEDBACK!)

149

SG24-5125-00
Printed in the U.S.A.

Implementing Tivoli Remote Control in Large Enterprises

SG24-5125-00

You might also like