Tivoli Management Framework Installation and Configuration

This page details problems and issues relating to the Installation and Configuration of Tivoli Management Framework.

Can I copy the '/etc/Tivoli' directory between servers? [7/1/03]
"Change File Permissions" Message When Installing Framework 3.7B on Windows 2000 [19/9/02]
Framework Error "FRW:IRER:0007" When Trying to Establish a Managing Mode TMR Interconnection [1/5/03]
How Do I Change the IP Address of My TMR Server [15/9/02]
How Do I Find Out My Tivoli License Key? [28/8/02]
How Do I Restore my Tivoli Database from Backup? [10/3/03]
Installing Framework on an NT Member Server [25/7/02]
Migration from 3.7B and 3.7.1 and Having to Reboot all Endpoints [28/4/03]
No "tmersrvd" Account or "Tivoli_Admin_Privileges" Group to Delete on NT Uninstall [14/9/02]
Why Do I Need to Have KBDUS.DLL in My WINNT\SYSTEM32 Directory? [21/9/02]

Can I copy the '/etc/Tivoli' directory between servers?

Unfortunately we had a disk crash on one of our test TMRs and we lost the '/etc/Tivoli' directory. Could it be copied from another TMR with small modifications or do we need to reinstall everything?

Solaris 8
FWK 3.7.1
DM 3.7

Contributed By: Louis Bohm, Eirik Tysse, Neil Wood
You should be able to edit the 'setup_env' and 'oserv.rc' files to reflect the TMR server. You'll also need to copy and modify 'etc/rc3.d/S99Tivoli' and 'etc/rc3.d/S99Tivoli_lfc1' plus '/etc/Tivoli/C/userlink.htm'.

I installed all of Tivoli on my TMR and Managed Nodes in one partition. That way it is very easy for me to back it up and if it breaks to the point I cannot figure it out quickly I can easily just newfs the partition and reload from tape.

"Change File Permissions" Message When Installing Framework 3.7B on Windows 2000

I've just tried installing Framework 3.7B on my fresh build Windows 2000 Server. I got the usual message about it wanting to add the tmersrvd account, but then I got the following dialog box:

Change File Permissions?

TME requires C:\WINNT\SYSTEM32 to have read/execute access for Everyone.

Would you like to adjust the access permissions as required?

If you choose Cancel, the installation will be aborted?

You don't have any option but click on "OK" otherwise the installation will stop.

Does anyone know why Tivoli needs this access (or can anyone point me in the direction of a document) and also if there is a way around it as I'm sure there will be some people out there that won't be too happy about opening up this directory to Everyone even if they do only have Read access?

Contributed By: Albert Wong
The only thing I can think of is that Framework needs to put the "TIVOLIAP.DLL" file into the \WINNT\SYSTEM32 directory. Then it binds the DLL to LSASS (Net Logon), so that it loads up every time the server comes up and allows the setuid methods to work. Since wlcftap is required to be set on all NT/ Windows 2000 servers in order for monitors and Tivoli methods to work as of Framework 3.7.

Framework Error "FRW:IRER:0007" When Trying to Establish a Managing Mode TMR Interconnection

Contributed By: Ken Wood
If you’re seeing this error when trying to run the “wconnect” command to establish a Managing Mode TMR interconnection then this could be why… [Go to the article]

How Do I Change the IP Address of My TMR Server

I need to change the IP address of my TMR server. Is it just a case of changing the IP address and Tivoli will take care of itself?

Contributed By: Cliff Hobbs [MVP SMS]
No it is not just a case of changing the IP address.

Your best bet is to refer to the 'Tivoli Management Framework Maintenance and Troubleshooting Guide' for the version of Framework you are using and do a search for 'IP address'. This manual contains details on how to change the IP address of a Managed Node, TMR Server, All Managed Nodes in a TMR, a Connected TMR Server as well as aliases for Clients, Servers and Connected TMRs.

Alternatively, use the link below:

http://www.tivoli.com/support/public/Prodman/public_manuals/td/ManagementFramework3.7B.html

Briefly, to change the IP address of a TMR server you should:

Login into Tivoli using an account with the super or senior role.
Set the Tivoli environment variables for your session.

Shutdown the oserv services for all installations using the following command:

odadmin shutdown clients

Use the following command to notify the oserv service of the new IP address:

odadmin odlist change_ip 1 <new_IP_address> FALSE

For example if the new IP address of your server is 10.5.1.3 you would use the following command:

odadmin odlist change_ip 1 10.5.1.3 FALSE

To change the IP address of the TMR server, edit the following files (if appropriate to your environment) and reboot the server:

For Unix:
- The local /etc/hosts file
- The DNS hosts map
For NT TMRs:
- The local %systemroot%\system32\drivers\etc\lmhosts file

If need be restart the oserv service using:

odadmin start 1

You can use the 'odadmin odlist' command to make sure the IP address of the server has been updated.

Use the following command to restart the oserv service on all Tivoli clients:

odadmin start clients

But what happens if the IP address of your TMR server has already been changed? Well for starters you won't be able to load the Tivoli Desktop as the oserv service won't start (on an NT system when try to start the 'Tivoli Object Dispatcher' service you get an 'Error 1067: The process terminated unexpectedly' message), but all is not lost.

Login into Tivoli using an account with the super or senior role.
Set the Tivoli environment variables for your session.

To restart the oserv service on the TMR server:

For Unix:
oserv -k $DBDIR -N by_name

For NT:
net start oserv -Nby-name (no spaces)

The above commands force the TMR server to resolve both the server and all managed nodes IP addresses by calling the 'getbyhostname' function with the name defined in the 'odlist' entry.

You can use the 'odadmin odlist' command to make sure the IP address of the server has been updated.

Use the following command to start the oserv service on all of the server's Tivoli clients:

odadmin start clients

You can use the following command submitted by Dr. Michael Staats to change the IP address of a Gateway and to migrate the Endpoints successfully over to the new address:

wep set interfaces -g <gateway> <old_ip+port> <new_ip+port>

So for example, if the old IP address of your gateway is 128.5.6.8 and it is running on port 9494 and the new IP address of your server is 10.5.1.6 then you would use the following command:

wep set interfaces -g <gateway> 128.5.6.8+9494 10.5.1.6+9494

The above command saves you having to migrate the Endpoints to a different Gateway before you change the IP address of a Gateway and then migrate the Endpoints back again.

How Do I Find Out My Tivoli License Key?

Contributed By: Cliff Hobbs [MVP SMS]
From a Command Line Interface window type the following:

odadmin get_platform_license

You can dump your license key to a file for future reference. For example for disaster recovery purposes you could dump the key to a file on a floppy disk which you could use to rebuild the TMR server to save you having re-type the license key.

To do this use the following command:

odadmin get_platform_license >a:<filename.txt>

For example:

odadmin get_platform_license >a:TMFLicense.txt

When it comes to rebuilding your server, simply open this file in Notepad and then copy and paste it when requested during the installation.

How Do I Restore my Tivoli Database from Backup?

I've got a problem whereby no matter what I try I can't get one of our Managed Nodes that was working installed and running again. I was therefore wondering if the worst comes to the worst, is there a set procedure anywhere I need to follow to restore my Tivoli database from tape? What files do I need to replace, do I need to run any special commands to reset pointers in the database, etc?

Contributed By: Jim Federline
Refer to Chapter Two of the relevant Framework Maintenance and Troubleshooting Guide entitled "Maintaining the Tivoli Database" - it is what you need to answer this question - there are multiple scenarios to consider, and it is not evident from this question or context which you need assistance with.

You need to be prepared for both a running recovery, and a dead oserv recovery.

Installing Framework on an NT Member Server

In a pure NT environment it makes sense to me to install my TMR server on an NT member server rather than a DC to save it getting bogged down with replication and authentication traffic and all the other usual reasons.

So you install Framework and it creates the tmersrvd account and the Tivoli_Admin_Privileges group but locally on the member server. Surely Tivoli won't be able to connect to the Endpoints to do anything because it will be using the account on the member server rather than a domain account?

Does this mean you can't install your TMR on an NT Member server or is there a workaround to overcome this?

I'm sure this must have been covered before, but I can't find any reference to it.

Contributed By: Joe Howell, Slawek Koszewski
Take a look at Appendix D of the Tivoli Enterprise Installation Guide. It has a good writeup on TME and NT administrator accounts. Also look at the Redbook, Tivoli Enterprise Internals and Problem Determination. It has pretty much the same information and a bit more.

Basically my opinion is that you are far better off putting your TMR server on an NT member server. That way the security is all local and you don't need to worry about performance and network traffic because you're always going back to the PDC for authorization. The other side of the coin is making sure that nobody renames your Administrator account (unless you've set "$root_user" to be "BuiltinNtAdministrator" - a Good Thing To Do.)

Also, if you upgrade to Framework 3.7.1, make sure you're at least up to patch 8 to avoid TMR and endpoint problems with BuiltinNtAdministrator.

Installing the TMR server logged on as Domain Administrator should be enough. Tivoli does not need an NT Domain on the TMR server and the only problem will be the correct Endpoint installation procedure.

However there must be a global domain account with an identical name as idmap root_user on the TMR server. In standard case it is Administrator.

Try to install endpoints with the wlcfinst command:

wlcfinst -d <path_to_lcf_directory> -N <source_endpoint_name> -n <new_endpoint_name> -P -Y "<endpoint_address_or_domain_name> DOMAIN\Admin"

<source_endpoint_name> is the name of a manually installed Endpoint (with Setup.exe)

The above example should ask for password of DOMAIN\Admin and everything should be OK. Remember to have KBDUS.DLL on the Endpoint before you start the installation (if you are using non-US Windows on Endpoints). And of course the Endpoint machine MUST be in the domain not a workgroup or you will have to use the local administrator account.

Migration from 3.7B and 3.7.1 and Having to Reboot all Endpoints

Contributed By: Cooper Begis
If you’re wondering whether you need to reboot all of your Endpoints once you've upgraded from Framework 3.7B to 3.7.1 the answer in short is Yes, but don't panic, here's one approach that may lessen the burden... [Go to the article]

No "tmersrvd" Account or "Tivoli_Admin_Privileges" Group to Delete on NT Uninstall

I've uninstalled Tivoli from my NT TMR, but as part of the final cleanup I've loaded User Manager for Domains and the "tmersrvd" account and "Tivoli_Admin_Privileges" group aren't present. Does Tivoli remove these as part of the uninstall?

Contributed By: Cliff Hobbs [MVP SMS]
No Tivoli doesn't remove these as part of the uninstall. You'll probably find that your TMR server is an NT Member Server in which case you'll need to change domains when you load User Manager for Domains (by default when you load User Manager for Domains the focus is set to the Domain rather than to the accounts held on the local machine).

To change the focus:

From the "User" menu select "Select Domain..."
Type the name of the local machine in the "Domain" box and you'll probably find the tmersrvd and Tivoli_Admin_Privileges items are listed.

Why Do I Need to Have KBDUS.DLL in My WINNT\SYSTEM32 Directory?

Quick question - I'm trying to understand why I need to put a copy of the KBDUS.DLL file in my C:\WINNT\SYSTEM32 directory on an NT4 TMR server. I'm assuming that if it's not there Tivoli isn't happy.

I've looked on the Tivoli website (http://www.tivoli.com/support/public/Prodman/public_manuals/td/framework/GC32-0395-00/en_US/HTML/instgu30.htm) which refers to Microsoft incident "SRZ980727000321" a copy of which I can't find, but doesn't detail why I need to put this DLL there, what happens if it's not there, etc.

Does anyone have any insight/info they could share on this?

Contributed By: Martin Cresswell, Gary Hamilton, Victor Van Den Bergh and Cliff Hobbs [MVP SMS]
If you look in your OSERVLOG you'll see something like the following:

2002/04/05 13:27:46 : Tivoli Management Framework () #1 Sat Feb 2 15:33:19 2002
(c) Copyright IBM Corp. 1990, 2002. All Rights Reserved.
TMR 1120518978. ORB 1. TMR server local:8091. Port 8091. Netsec 0x2.
Ciphers NULL.
pid 712
2002/04/05 13:27:46 : ^Hmm... looks like you're running NT 4.0 Service Pack 6.
I won't create a console.
2002/04/05 13:27:46 : ^Creating separate WindowsStation and Desktop.
CreateWindowStation failed: The specified module could not be found.

The last line is the one of interest. The "CreateWindowStation" API Tivoli uses to do this task is a Microsoft API, that uses standard Microsoft C library calls that mistakenly use something in KBDUS.DLL. Tivoli did contemplate writing their own API to overcome this and avoid using the Microsoft one as Microsoft refused to fix this problem (which is why the incident no longer exists).

It was felt that the better solution was to simply roll out this DLL with all Managed Node installations (Endpoints aren't affected by it), therefore in effect solving the problem. This problem is not just limited to Windows NT 4 but Windows 2000 and XP as well.

To get around this problem simply copy another KBD DLL such as KBDUK.DLL and call the copy KBDUS.DLL (the file itself doesn't have to be the actual KBDUS.DLL).

What you can't do is create an empty file such as a Notepad document and call it KBDUS.DLL because when you try to start the oserv service you'll first get dialog box titled "oserv.exe - Bad Image" containing the following text:

"The application or DLL C:\WINNT\System32\KBDUS.DLL is not a valid Windows NT image. Please check this against your installation diskette."

The only option is to press "OK" at which point you get the "Services" dialog box with the standard error:

"Could not start the Tivoli Object Dispatcher service on \\TIVTEST. Error 1067: The process terminated unexpectedly".

Again the only option is to press "OK".