Backup Missing

[GregE]

I have a Windows 2003 BA client in the DMZ. The firewall is not open, so I have all client and server settings set so that only the server can initiate contact with the client. I've had this in place for 4 years on this client. Last week I had to restore a file for this client, so for simplicity I set my laptop dsm.opt to a nodename for this DMZ client, changed the node definition in TSM server to SESSIONINIT=ClientOrServer and restored the file to my laptop. Then on the TSM server I changed the node definition back to the way it was...SESSIONINIT=ServerOnly

It has missed it's backup window everytime since I did this. The LLADDRESS and HLADDRESS were never changed so they're the same as they were. Also a Q NODE F=D shows the correct TCP/IP Name and TCP/IP Address.

What am I missing?

[Raakin]

What am I missing?

The schedule?

Curious, my first impression was the TSM server was looking for your laptop node still but the q node dismissed that idea.

Are the TSM clients on the DMZ node and your laptop node the same version and level?

I am assuming poking a temp hole in the firewall to allow the DMZ node to communicate with the TSM server is not possible or lot of tape to cut through?

[GregE]

Curious, my first impression was the TSM server was looking for your laptop node still but the q node dismissed that idea.

It showed my laptop after I ran the restore of course, but then it changed itself at the next backup attempt. So how could it change without making contact to KNOW to change? And since it changed, it obviously knows how to get there yet won't backup.

Yep, same version, same level.

I am assuming poking a temp hole in the firewall to allow the DMZ node to communicate with the TSM server is not possible or lot of tape to cut through?

Way too much red tape to cut through. Should not have to do that anyway. Something is odd about this. Seems I've seen it before, on this or some other DMZ client but it's been so long I don't remember.

[dms19]

After you set your DMZ client back to normal did you open a dsmc to reauthenticate with the new HLAddy and LLaddy?

Give that a whirl.

May want to reset the node password on the server and reauthenticate on the DMZ client either way.

[GregE]

After you set your DMZ client back to normal did you open a dsmc to reauthenticate with the new HLAddy and LLaddy?

I didn't make any changes on the client. The only thing I did was change the node definition SESSIONINIT setting and then set it back to the original setting.

May want to reset the node password on the server and reauthenticate on the DMZ client either way.

I can't authenticate from the client side. The firewall is closed, as it always has been.

[dms19]

If you cant authenticate from the client how can TSM get the updated HLA and LLA from the DMZ client? You should at least (I would think) be able to open the gui or dsmc and set the pw.

You can try to update node and provide it with the ip and port for HLA & LLA but I would still think you'd need to reauthenticate?

[GregE]

All of that is in place. HLA, LLA never changed. I set the password earlier, just for the heck of it, and reset it on the client too.

Just ran a test...
ANR2567W Schedule prompter skipped contact attempt with NODE_1 to start a scheduled operation.

This is not making any sense.

[dms19]

is the node locked? Can you define a clientaction schedule for that node?

[dms19]

Just curious, when you spoofed the dmz client on your laptop and did the restore, didnt the attributes change for the DMZ client (they should have)? If they were set back that means the connectivity was there from the server to the client and perhaps a port changed?

I ran into an issue like this before and I had to review the firewall rule to make sure it was on the proper port and run dsmcutil to redefine the IP and ports used on the scheduler though even it was serveronly and prompted.

Might be worth a look?

[rwhtmv]

When upgrading a server with new hardware, server01 (old server) and server02, both have proper client installed per their O/S. Backed up both to TSM server for recovery purposes then shipped server02 and eventually powered off server01.

Then I changed the nodename of server02 to server01, with identical options. Something gets whacked with the scheduler service, and a reinstall/reboot is necessary. Tried searching registry for old references, and that worked once. Also had intermittent luck with uninstall/reboot/reinstall. TSM support basically had me manually blow away the services using dsmcutil command, and that seems to be the best option.

Although you should always be able to "pose" as a node by using dsm.opt nodename option, the scheduler (specifically on newer clients) doesn't like it. So I recommend blowing away your TSM client services using dsmcutil.exe, and readding them.

Good luck.

[GregE]

is the node locked?

Good grief, you're right. I searched actlog back to when I was doing my work and noticed that that night, when the backup tried to start, it was failing with "invalid sign-on attempts" until it hit 10 and locked the node. Why??? I don't know, since the password never changed. I never thought it would be locked and didn't pay attention to it when re-checking the node settings. All's well again.

rwhtmv, interesting info you've posted. Something is definitely odd about the password suddenly not being liked after simply using a different client's dsm.opt file for a node.