Jump to content

Windows clients repeatedly "deferring" backup overriding server requests


Recommended Posts

Running Server 5.1.175 on Panther (but that shouldn't matter), I will occasionally get Windows 6.5 clients stuck in a mode where they are repeatedly deferring the backup. I can not say for certain what causes this.

 

 

 

I run all my backups in "backup server" mode, but I -- as the server admin -- should be able to override the "defer" option by setting the backup date to a date earlier than today within Backup Server.

 

 

 

On the "stuck" Windows clients, this doesn't work as the client will say "ready", but then it goes back to "deferred". I can guarantee that there are no users in front of the computer deferring the backup.

 

 

 

Unless the Windows machine (usually XP) is restarted by the client owner, I -- as the admin -- can't get backup server to override the deferral. Upon restart of the client, it's still "deferred", but I can then put in an earlier date to override this.

 

 

 

Is there a reason that the Mac backup server can't override this? Or is this strictly a Windows client problem?

 

 

 

Thanks!

Link to comment
Share on other sites

This did not work. I set the client countdown to "zero"

 

the only difference is that the backup server switches to "ready", but then waits a few seconds and skips to the next client.

 

The only workaround seems to be restarting the client computer -- which I shouldn't have to do.

 

So there's a bug somewhere. (Right now I have 4 out of 80 computers doing this...)

Link to comment
Share on other sites

Just an additional data point: last year I tried backing up a Macintosh client running Virtual PC by treating VPC as a Windows client. I had the same user-deferred problem with the hosted client, and did not find a solution. I have not seen the problem on "real" clients.

 

(I did not know about the zero-countdown tip from Mayoff.)

Link to comment
Share on other sites

As an additional data point...

 

On one computer "stuck deferring", I connected to it via Remote Desktop Connection.

 

I used that connection to set the client to "as soon as possible".

 

Still deferring.

 

I'd be willing to try something else before restarting this client. Just let me know what.

Link to comment
Share on other sites

Quitting Retrospect on the mac doesn't matter. Clients are still deferring after quit/restart or reboot (as I just installed 10.3.2 today to see if that would help.)

 

I *can* back them up manually when they are in this state, though.

 

It's just the backup server ability has stopped.

 

Oddly enough, I have even more doing this than previously. It's making me wonder if one of the recent Windows Critical (or other program) updates is having an adverse affect on the behavior of the client...

 

 

Link to comment
Share on other sites

I tried forgetting a client and readding it.

 

Same thing.

 

Client moves to the top of the list, but is deferred. I can't override this.

 

 

I now have 9 *different* Windows clients doing this.

 

And this is on a different backup server than the 4 clients I initially posted about!

Link to comment
Share on other sites

Quote:

Running Server 5.1.175 on Panther (but that shouldn't matter)

 


 

Sure it should.

 

The Retrospect application for sure sends info down the line to Clients. Dantz has already described some Panther interactions, and has even spoken about the testing in progress for the next version (on the RetroTALK mailing list). This may be another such bug.

 

If they didn't know about this the day that they made their Panther announcement, they may have found it since. Or perhaps they're hearing it from you for the first time.

 

The most important test would be, does this happen on 10.2.x?

 

Dave

Link to comment
Share on other sites

Does it happen on 10.2.x? -- excellent question. I'm not sure I can test that at this point.

 

but, the oddity is that if the client restarts -- it's still "deferred" in backup server, but *then* I can override it.

 

I'm wondering if this is a "calendar" issue. Maybe some of these people are deferring to 2004 and as the server is in 2003, the client doesn't know what to do. Or maybe the backup server software can't see beyond 2003. *Normally* if a client defers, it'll say the time/date it's deferred to -- in these instances, it just says "deferred"

 

I'm stumped.

 

I'm open for beta testing -- e-mail me if you need one more tester for the panther-fix version (though I'm still thinking it must be a Windows Client issue -- especially since I can still do an "immediate backup" of the "deferred" clients.)

 

I'm here most of next week and I'm sure some of my clients will still be "deferring" at that point if you want a beta tester (who has been a previous beta tester...)

 

 

Link to comment
Share on other sites

the bug is in the Windows Client -- or Retrospect 5.1.175.

 

I had a compatriot in another department running 5.1.175 *on 10.2.8* add one of my "deferring" clients to her system.

 

She made quick backup server script and saw the same thing:

 

1) the windows client "deferred" immediately.

 

2) She tried to override the deferral. It says "ready", then "deferred" right away again.

 

 

So it's not a Panther issue.

 

I also *went* to a deferred client and hit "as soon as possible" on their client software. No difference.

 

Please let me know if you need other info or would like me to try something else here.

Link to comment
Share on other sites

Ah, FWIW....

 

I noticed that there was a new version of the Windows app out, so I figured there might be a new Windows Client version.

 

So I downloaded that and "pushed" the Windows Client updates from 6.5.131 to 6.5.132

 

Didn't restart any of my client machines, but some of them that were repeatedly deferring are now backing up. I can't be sure that this is a 100% fix for the problem (as what do I do if they stick with 6.5.132?), but it's a good sign so far.

 

I'm not certain I have any more "stuck" computers on-line at the moment, but if you want me to try something if there is one, please let me know.

Link to comment
Share on other sites

FWIW (yet again) -- even after doing a "push" upgrade of all computers that were on-line, there are still a number of them deferring the backup that I can't override.

 

I'm open for suggestions and -- as before -- willing to have you connect to one of these clients to see if you can override it.

Link to comment
Share on other sites

  • 2 weeks later...

Just wanted to return to this thread with an update:

 

It's still an issue.

 

What would be new "data" is that machines that have gone past the "one week since last backup" of my weekly backup server script are still deferring.

 

So *something* is sticking the Windows clients -- the problem must be there.

 

I'm still available to test things prior to any MacWorld announcement if you want...

Link to comment
Share on other sites

I'm still willing to test this with a new version before you release 6.0 as I have *new* problems.

 

I'm getting more -- and different -- computers stuck "deferring" the backup now. XP computers that sucessfully backed up a week ago are now in "Ready" mode on the client, but are only "deferring" when trying to back them up with backup server.

 

this is becoming a significant problem because I'm using backup server and my *log* files are filling up with "user deferred" lines.

 

 

AND NOW -- I had a client deferring that would not respond even to a restart. So I went to the client and "removed" the 6.5.132 client and reinstalled the client (did not repair it).

 

I went back to my server and readded the client. Client is *still* deferring! I can do an immediate backup of the client, but it refuses to respond to the backup server!

 

AAAAHHHH!

 

Any help here?

Link to comment
Share on other sites

 

What I've tried:

 

1) Removing and readding the client to the backup server machine -- no difference.

 

2) Adding the client to *another* backup server machine in another subnet running different version of Retrospect on a different OS -- no difference.

 

3) Removing the client from the backup server machine and readding it with a different client name -- no difference

 

4) Removing the client, rebooting and reinstalling the client -- no difference

 

5) Removing the client, rebooting and reinstalling the client in a *different* administrator account -- no difference.

 

I *can* do an "immediate backup" of the client -- the client/server connection *is* functional in that respect.

 

 

I can not get this client to stop "deferring" the backup. And it's not the normal "defer" where it shows the date the client says to defer to -- there *is* no user at this machine deferring the backup.

 

 

The "retroclient.log" file on the client shows this:

 

1073659418: ConnStartListen: starting thread ConnStartListen for 127.0.0.1:64119

1073659419: netCheckNewInterfaces: found new address CLIENTIPADDRESS:0

1073659419: iplud: bound to address CLIENTIPADDRESS

1073659419: ipludAddMembership: adding membership for CLIENTIPADDRESS

1073659425: IPNSRegister(1): registered: "CLIENTNAME"/"489a7aa762844ef2"

1073659425: ConnStartListen: starting thread ConnStartListen for CLIENTIPADDRESS:0

1073659470: Connection established by SERVERIPADDRESS:62513

1073659470: ConnReadData: Connection with SERVERIPADDRESS:62513 was reset

1073659470: ServicePurge: service not found

1073659570: Connection established by SERVERIPADDRESS:62530

1073659570: ConnReadData: Connection with SERVERIPADDRESS:62530 was reset

1073659570: ServicePurge: service not found

 

 

and this for #3 above:

 

073659645: Connection established by SERVERIPADDRESS:62549

1073659645: ConnReadData: Connection with SERVERIPADDRESS:62549 was reset

1073659645: ServicePurge: service not found

1073659645: Connection established by SERVERIPADDRESS:62550

1073659656: IPNSRegister(0): registered: "NEWCLIENTNAME"/"489a7aa762844ef2"

1073659663: ConnReadData: Connection with SERVERIPADDRESS:62550 was reset

1073659681: Connection established by SERVERIPADDRESS:62552

1073659683: ConnReadData: Connection with SERVERIPADDRESS:62552 was reset

 

 

I need help here. I can't reformat this computer at this time to fix the problem (which I'm sure it would).

 

Something is wrong with the client (or Windows on the client) that uninstalling and reinstalling isn't clearing up.

 

*Is* there a client setting/file somewhere that holds a "deferral" date in it that might need purging?

 

I'm open for suggestions.

 

Link to comment
Share on other sites

  • 1 month later...

Hi

 

Are the clients that are having this problem DHCP clients or do they have static addresses? Can you try setting a problem client to a static IP to see if the problems continue?

 

One thing you may want to try is uninstalling the network drivers and restarting the problem client machines.

 

Do the problem clients share any common network hardware?

 

Thanks

Nate

Link to comment
Share on other sites

I need to come back to this.

 

I have another machine (Win2000) that is doing the same problem.

 

I removed TCP/IP from the Local network and readded it -- no help.

 

Removing/reinstalling the client (6.5.132) -- no help.

 

I can still *manually* back up the client.

 

It just repeatedly defers the "backup server" backup.

 

I need suggestions. I reformatted the *last* computer that did this. I'm looking for another answer to address the problem so I don't have to continually reformat my Windows machines when this happens.

Link to comment
Share on other sites

Hi Steve -

 

Here's a quick summary of most of what I'm getting from your troubleshooting:

 

- Rebooting usually fixes the issue

- Reinstall Windows fixed the issue the one time it was tried

- Reinstalling the client and the TCP/IP protocols have no effect

- Only 4 (or so) clients out of ~80 are affected by this behavior

 

The ability to do Immediate Backups would make sense in this context because the ability does to "Defer" does not exist with Immediate Backups. This is only included in Backup Server scripts.

 

Can you isolate any programs/utilites which may be running only on the 4 problems clients?

 

If you can consistently reproduce this on an XP client try the following test:

 

On the client end go to Start > Run

Type MSCONFIG and then hit OK

On the Services tab hide all Microsoft Services and disable everything else except for the Retrospect Client

On the Startup tab disable everything

Reboot and run test backups of the client to see if the problem still exists

 

This will rule out (or in) any third party software conflicts.

Link to comment
Share on other sites

The summary is correct with a few modifications:

 

1) Rebooting usually does fix the issue.

2) Sometimes updating the client from 6.5.131 to 6.5.132 (without rebooting) fixed the issue

3) For the one where we could not do anything -- we had to reformat to fix the problem.

4) the number of clients vary that show this. On average, there's at least one a week that we need to notify.

5) We can not *consistently reproduce* this anywhere. this is only the 2nd machine we've had whereby the usual tricks have not worked.

 

 

For your steps, can we use them on a Win2000 machine? That's what's currently deferring and refusing to accept any alternate solutions.

 

Oh, and I tried Retrospect 6.0 -- same thing as with 5.1.175

Link to comment
Share on other sites

to reply to my own post...

 

we downloaded the XP version of MSCONFIG and ran it on this Win2000 client.

 

client rebooted after turning off all things indicated above.

 

*Still* deferring.

 

Suggestions? We'll probably have to schedule a reformat of this client tomorrow morning unless there are any other options to try.

Link to comment
Share on other sites

Don't forget, if you set the client countdown to Zero, then a defer should not be possible (even by a confused system).

 

My experience has been that a bogus defer happens when the OS is preventing the countdown dialog from being displayed due to a virus utility, screen saver, or shareware.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...