Find the answer win a prize

[rwhtmv]

So all you TSM gurus, turn you knowledge into cash:

Start with a Windows 2003 node with TSM 5.5.2.2 x32 client installed (no journaling). Basic setup and config, including dsm.opt file (passwordaccess generate). Scheduler controlled by CAD, and successful backups every night. Let's call this FILE1.

Now, bring in a separate server for a hardware upgrade of FILE1 and install Windows 2008 R2. Call this node FILE2, built and installed TSM 5.5.2.2 x64 version. Both nodes are currently registered with TSM server (Windows 2k3, 5.5.0.2) to allow backup of both servers, due to diff O/S es.

Power off FILE1 since it has been decommissioned. Rename FILE2 to FILE1 as hostname since it is replacing old host, and change nodename in TSM client. Change the IP address to reflect the old host address so FILE2 has now "become" FILE1 to the end user. Obviously reboots are needed for DNS and IP changes.

Run the TSM client gui and it will ask you for the password, which will fail.

So I did UPDATE NODE FILE2 PASSWORD at the server so that I could get the GUI to access the server. Backup, archive, restore, retrieve all work fine. DSMCad service running and automatic. Stopped and restarted more than once.

Now here's the trick that will win you a free lunch. Find a way to make the scheduler actually WORK. I reinstalled client and rebooted, rebooted TSM server, rebooted the node, deleted the schedlog, stood on my head, etc. The scheduler is polling as planned from looking at the schedlog, but never finds its associated schedule. I removed all schedule associations and reassociated them, with no luck.

GOOD LUCK! First correct answer wins a $10 lunch voucher. NO GUESSING! You have enough information, so don't plan on me sending you a bunch of logs.

 

[rvillano]

Here is my idea to solve your problem.... remove the cad and the scheduler using the gui setup wizard. and reinstall the CAD/ scheduler again because the scheduler has invalid password in the registry? If this works no free lunch is required.

Bob...

 

[rwhtmv]

Nope.

I get the message on the client "Node is not registered." At TSM server I do: REGISTER NODE FILE2 and it says Node FILE1 is already registered.

So in TSM has a registration entry for the node, due to nodename, but somewhere it knows that the node is not really FILE1 (or at least the original FILE1 that was registered). Registry entry somewhere perhaps....

Before you tell me to delete the filespaces of the node, and then delete the node and re-register, think again. 4 million files on the file server, and we are talking about 5 servers with same issues.

KEEP LOOKING! Thanks.

 

[Jeff_Jeske]

^ I agree. Normally I stop all TSM servcies and use SC DELETE "SERVICE NAME HERE" or what ever approach you like to remove the TSM services. Then I use the wiz to create a new set of services. You'll need to update the password on the TSM server prior to configuring the services. UPD NODE SERVER1 PASSWORD.

For us ... we always rename the old node to something with a TIL date. SERVER_TIL_01MAR2010. Then install the new node as the server name that it will be. You could do the same even if both servers were active at the same time rename old server to SERVER1_OLD.

 

[Jeff_Jeske]

Ren node file1 file1_old <<< old server. remember to remove it from its schedule.

reg node file1 file1 <<< new server with pw matching the servername.

Q node <<< this will show you file1_old and file1

 

[rwhtmv]

Thanks Jeff, but no.

This has been tried, and I did it again so I didn't think I was losing my mind. Still does not pick up any schedules from TSM server.

 

[moon-buddy]

The problem is the new node's unique registration ID when it was first registered as NODE2.

On the TSM server side:

Run "update node" (NODE1) with a new password.

On the node side:

To correct this, the rename of the must be accompanied by a registry delete of the old NODE2 password entries and a new password generated - remembering to rename the node first to NODE1 before resetting the password.

Everything should work.

 

[rwhtmv]

Ok so you are on the right track.

But I need to know WHAT registry keys to blow away. Not sure, and won't just start hacking.

 

[moon-buddy]

But I need to know WHAT registry keys to blow away. Not sure, and won't just start hacking.

Here is where I have the fun!

Been doing this for a long time ... want to guess which register key?

 

[rwhtmv]

Sure for 10 bucks.

I just ran a full regedit search on TSM server for that nodename (FILE1) and found 3 references that are not related to TSM (FILE1 used to be a print server and those were the references.)

Unless the keys are hexadecimal, I do not know where else to look.

 

[moon-buddy]

I just ran a full regedit search on TSM server for that nodename (FILE1) and found 3 references that are not related to TSM (FILE1 used to be a print server and those were the references.)

Unless the keys are hexadecimal, I do not know where else to look.

OK - here is the key:

HKEY_LOCAL_MACHINE --> IBM --> ADSM --> Nodes --> <nodename> --> <server_name>

The <servername> key has a binary type Password value. You can delete the <nodename> key which will delete the keys beneath it (<servername>, password and (default) values). These three will be regenerated by using the dsmc command.

 

[Jeff_Jeske]

I rename nodes all the time. Never have I ever had to purge a reg key.

rename node and upd pw
upd node options file to reflect new name
open gui and enter newly changed pw

 

[moon-buddy]

I rename nodes all the time. Never have I ever had to purge a reg key.

rename node and upd pw
upd node options file to reflect new name
open gui and enter newly changed pw

Deleting the REG KEY will result in a cleaner setup. The renaming will create another REG KEY entry, and the old one will still be there.

 

[Jeff_Jeske]

That is good to know. In most cases we do not rename a newly deployed server. We rename the old soon to be decommissioned server.

 

[domino]

... and install Windows 2008 R2. Call this node FILE2, built and installed TSM 5.5.2.2 x64 version....

Windows Server 2008 R2 and Windows Server 2008 R2 Server Core, all editions (except Automated System Recovery (ASR)), all SPs supported, on Windows x64 processors only. Client level 6.1.2 or higher required. Windows IA64 processor support in 6.1.3 or higher.

have a lookat this site
http://www-01.ibm.com/support/docview.wss?rs=663&uid=swg21243309#winpart

 

[BBB]

Like Jeff I've never had a problem renaming nodes.

It sounds like your rename has gone ok though. Why can't you post your dsmsched.log showing the polling pickup up no schedules so we can see it?

Check the renamed node is actually associated to a schedule, and that the schedule is activated. Check the next time the schedule has been calculated to run with "q event <dom> <sched> begind=today endd=today+1" and look for your node in the list.

Don't know if this can cause anything but also what about date/time on the client server?

 

[JohanW]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSM Scheduler\Parameters\ClientNodeName

But it's beyond me why rerunning the GUI Setup Wizard "Help me configure the TSM Client Scheduler" would not work. Have you done that?

On a related note: this is what DNS CNAMEs are for. They let you address hosts by function instead of identity.

You need two registry entries to prevent problems when calling hosts by their CNAME instead of hostname:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"DisableLoopbackCheck"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
"DisableStrictNameChecking"=dword:00000001

 

[rwhtmv]

See that's the thing. I rename all the time too.

This just started about the time I upgraded to 5.5.2.0 server. I'm not saying they are related, but the timeframe is similar.

And yes, it's a x64 processor where I installed the x64 TSM client...

Reg delete did NOT work...and I am not pulling your leg. The renamed nodes actually had 2 reg keys in there (i.e. FILE2 and FILE1) since it used to be FILE2. I deleted both. Started the client, and it asked for a password which it took. Backups work fine, schedule does NOT take. I deleted all associations, and defined them again, no luck.

This is totally irritating me, and I am about to make a call to support and go through the entire "send me all your logs, and all 22 server's info, blah, blah" which will tie me up for the next 3 days troubleshooting this with IBM supt.

 

[Jeff_Jeske]

Have you tried simply uninstalling the client code and reinstalling?

Are you still trying to backup both nodes or only the newest node?

 

[rwhtmv]

The newest node IS the old node, as far as I'm concerned. The old servers are powered off, and were before I even changed the hostname/nodename on the replacement servers. I have tried everything, including downgrade clients, upgrade clients, reboots, reg hacks, scheduler removal / reinstall (both with cli and gui), and I even tried rebooting TSM server. I am now talking about 7 servers with same situation. Monday first thing I turn this over to support.