IBM E027SLL-H Troubleshooting Guide - Page 90

Installation of OS agent on a Microsoft Windows Server 2003

Page 90 highlights

-x profilemanagers/DM_TEST_PM.xml Specifies the name and location of the output file that resulted from the assessment of the DM_TEST_PM profile manager. -r Indicates that the purpose of this command is to perform a rollback. -f scans/baseline.xml Specifies the name and location of the baseline file to use as input for this command. 3. Restart the Windows endpoint. The rollback option can also be used to roll back an endpoint upgrade or a profile upgrade independently. By rolling back the profile manager upgrade, you roll back all upgrades (profile manager, profile, and endpoint) in one step. "SQL1_OpenRequest status = 79" return code occurs during when upgrading an agent: The return code SQL1_OpenRequest status = 79 occurs in the agent log when the application support is added during an upgrade. This return code results from an attempt to delete a table entry that does not exist in the table. When you add application support for a V6.1 agent, the return code is expected behavior because the agent application support data does not exist in the table. Installation of OS agent on a Microsoft Windows Server 2003 fails with this error: "Unable to establish BSS1 environment, can't continue" This error is caused by the deletion of the gskit directory, whether intentionally or by accident, without clearing the registry information. If gskit was previously installed by another product and has a dependency on it, for example DB2 9.1, then let that product reinstall it, or if there are no other products that depend on the version of that gskit, then you can clear the GSK7 entry in the registry that can be found under My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\GSK7. Then rerun the IBM Tivoli Monitoring installation to allow the gskit to be reinstalled. Note: Create a backup of the registry before editing it. Unable to update the Tivoli Data Warehouse agent by using the command line interface When using remote deployment to upgrade the Tivoli Data Warehouse agents (Warehouse Proxy Agent and Summarization and Pruning Agent), you must use a specific workaround to ensure that the upgrade is successful. On UNIX and Linux systems, you must add the following variable to the hd.ini file for the Warehouse Proxy Agent or the sy.ini file for the Summarization and Pruning Agent, and then restart the agent: CTIRA_SYSTEM_NAME=$RUNNINGHOSTNAME$ On Windows systems, you must add the following line to the KHDCMA.INI file for the Warehouse Proxy Agent or the KSYCMA.INI file for the Summarization and Pruning Agent, and then reconfigure and restart the agent: CTIRA_SYSTEM_NAME=%computername% .TYPE=REG_EXPAND_SZ Monitoring server connection information is changed after upgrade A Tivoli Enterprise Monitoring Agent that connects to a different Tivoli Enterprise Monitoring Server than the one that the OS agent connects to might have its monitoring server changed after the monitoring agent is upgraded to a new version using remote deployment. 72 IBM Tivoli Monitoring: Troubleshooting Guide

  • 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
  • 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
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310

-x profilemanagers/DM_TEST_PM.xml
Specifies the name and location of the output file that resulted from the
assessment of the DM_TEST_PM profile manager.
-r
Indicates that the purpose of this command is to perform a rollback.
-f scans/baseline.xml
Specifies the name and location of the baseline file to use as input for
this command.
3.
Restart the Windows endpoint.
The rollback option can also be used to roll back an endpoint upgrade or a profile
upgrade independently. By rolling back the profile manager upgrade, you roll back
all upgrades (profile manager, profile, and endpoint) in one step.
“SQL1_OpenRequest status = 79” return code occurs during when upgrading an
agent:
The return code
SQL1_OpenRequest status = 79
occurs in the agent log
when the application support is added during an upgrade. This return code results
from an attempt to delete a table entry that does not exist in the table. When you
add application support for a V6.1 agent, the return code is expected behavior
because the agent application support data does not exist in the table.
Installation of OS agent on a Microsoft Windows Server 2003
fails with this error: “Unable to establish BSS1 environment,
can't continue”
This error is caused by the deletion of the gskit directory, whether intentionally or
by accident, without clearing the registry information. If gskit was previously
installed by another product and has a dependency on it, for example DB2 9.1,
then let that product reinstall it, or if there are no other products that depend on
the version of that gskit, then you can clear the GSK7 entry in the registry that can
be found under
My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\GSK7
. Then rerun
the IBM Tivoli Monitoring installation to allow the gskit to be reinstalled.
Note:
Create a backup of the registry before editing it.
Unable to update the Tivoli Data Warehouse agent by using the
command line interface
When using remote deployment to upgrade the Tivoli Data Warehouse agents
(Warehouse Proxy Agent and Summarization and Pruning Agent), you must use a
specific workaround to ensure that the upgrade is successful.
On UNIX and Linux systems, you must add the following variable to the
hd.ini
file for the Warehouse Proxy Agent or the
sy.ini
file for the Summarization and
Pruning Agent, and then restart the agent:
CTIRA_SYSTEM_NAME=$RUNNINGHOSTNAME$
On Windows systems, you must add the following line to the
KHDCMA.INI
file for
the Warehouse Proxy Agent or the
KSYCMA.INI
file for the Summarization and
Pruning Agent, and then reconfigure and restart the agent:
CTIRA_SYSTEM_NAME=%computername% .TYPE=REG_EXPAND_SZ
Monitoring server connection information is changed after
upgrade
A Tivoli Enterprise Monitoring Agent that connects to a different Tivoli Enterprise
Monitoring Server than the one that the OS agent connects to might have its
monitoring server changed after the monitoring agent is upgraded to a new
version using remote deployment.
72
IBM Tivoli Monitoring: Troubleshooting Guide