Jump to content
Sign in to follow this  
Maser

Windows clients repeatedly "deferring" backup overriding server requests

Recommended Posts

Oddly enough -- on *this* client -- setting the countdown to zero worked. However, I can unequivocally state that it made no difference to the WinXP client of a few weeks back.

 

After "zero" started the backup, I stopped the backup and reset the client countdown to 30 seconds (it was 1 minute previously) in the script. Back to deferring.

 

All my PCs are running VirusScan 7.1 -- so it's not specifically indicative of that (necessarily) because all of them run this.

 

Screen Saver is *not* on -- in fact the user was at the computer while all this was going on and working on a Word document.

 

He never sees anything come up to defer the backup. In fact, the *client* is set to back up "as soon as possible"

 

I can't rule out "shareware" causing an adverse reaction, though -- give me some examples that you know of that *does* affect this from coming up and I can see if the user has any of it on the machine.

 

 

I'm stumped. Something *on the client* is doing the deferring. I've even tried (as before) adding the client to another machine running Retrospect. No luck. It's not the backup server acting up. It's all about the client.

Share this post


Link to post
Share on other sites

Unfortunately, the days of "Kill everything but SysTray and Explorer" are long behind us. The MSCONFIG utility should prevent anything else from loading on boot, unless you've got some shortcuts in the Startup Items folder (which I should have mentioned in my prior post). After boot, with the MSCONFIG changes mentioned previously, do you see anything non-standard running as a process? I wouldn't expect to see Norton, for example.

 

Something else to try, which may or may not have any effect but worth a shot none the less, would be to:

 

1. Run the backup while the machine is logged out

2. Run the backup while logged into a new user account

 

Report back when possible.

Share this post


Link to post
Share on other sites

Tried both (waiting at the login screen and logging into a different account.)

 

Same deal -- still deferring the backup.

 

Even after completing a backup with "zero" countdown, I can't get it to backup again if I reinitiate the countdown.

 

I have plans to reformat this computer tomorrow (Thursday) and am willing to try something else in the meantime, but I don't believe I can leave my countdown at "zero" for all my client computers. They probably wouldn't like the option taken away from them to defer the backup.

Share this post


Link to post
Share on other sites

I now have -- yet another -- XP client repeatedly deferring.

 

This one will not back up if I set the countdown to zero.

 

What can I send you that will help debug this problem before I have the client restart?

Share this post


Link to post
Share on other sites

I have a 1.9M "retroclient.log" file from this particular PC.

 

What parts do you want?

 

(the client restarted this a.m. and backed up successfully after restart...)

Share this post


Link to post
Share on other sites

The tail end of the file looks like this:

 

1079359000: connTCPConnection: conn = 3695800, code = 300, tid = 7, count = 280

1079359000: connTransMsg: writing message 300, 7, ncSD

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: connTCPConnection: conn = 3695800, code = 300, tid = 7, count = 280

1079359000: connTransMsg: writing message 300, 7, ncSD

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 276

1079359000: transSubPiper: writing code = 300, tid = 7, count = 0

1079359000: connTCPConnection: conn = 3695800, code = 300, tid = 7, count = 280

1079359000: connTransMsg: writing message 300, 7, ncSD

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 276

1079359000: transSubPiper: writing code = 300, tid = 7, count = 0

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

1079359000: transSubPiper: writing code = 300, tid = 7, count = 644

 

 

there are a *lot* of the last line throughout the entire retroclient.log file with varius "counts" (mostly 644).

Share this post


Link to post
Share on other sites

Hi,

 

I don't recall seeing a specific fix for that but it may still help. There have been some other problems that seemed to be fixed by this client.

 

Nate

Share this post


Link to post
Share on other sites

For what it's worth...

 

Upgrading to this new client and restarting the Win2000 machine still would not let it do a backup server backup -- it's still repeatedly deferring.

 

 

Might there be some 3rd party "popup blocker" software product that interferes with the Retrospect "countdown" screen? If so, what should I be looking for?

Share this post


Link to post
Share on other sites

I'm having the same troubles here. One MS Windows 2000 client started deferring automatically. I updated to the nearly latest and greatest (meaning the latest and greatest for Retrospect 5.1), all to no avail.

 

His system: MS Windows 2000 version 5.00.2195 sp4. Deferring started when using client v6.5.131 and continued for client v6.5.136. The only new software he recalls having put on the computer of late was the Google toolbar inside of MSIE. Of course, it would be bizarre if this were blocking the dialog box from Retrospect (which isn't even a real popup window) when MSIE isn't running.

 

My system: Mac OS X 10.3.3 version 5.1.177 using the 4.3.103 drivers. The problem started when I was using 5.1.175 with the 4.2.105 drivers.

 

It would be nice if someone would find the solution to this problem.

 

-- Bill

Share this post


Link to post
Share on other sites

Hi

 

Does your client respond to standard backup scripts?

Does creating a separate backup server script for this client make any difference? Have you tried uninstalling the current client and downgrading to the 6.0 Windows client?

 

Thanks

Nate

Share this post


Link to post
Share on other sites

Does your client respont to standard backup scripts?

Yes. I made a plain old backup script, fired it up, and it started looking through the client hard drive.

 

Does creating a separate backup server script for this client make any difference?

No. The backup server scripts defer regardless of which script tells it to back up anything from the client machine.

 

Have you tried uninstalling the current client and downgrading to the 6.0 Windows client?

No. I'm not sure I'm willing to try, because of lack of time and inclination. The machine in question was working just fine until these autodeferrals started up. Since I run the backups as a sideline, rather than as a true admin, I'm looking for a solution which won't involve reinstallations each time the problem occurs. From what Maser says earlier, reinstallation sometimes works, sometimes fails. Still, I'll keep it in mind if no real solution comes up soon.

 

Thanks for the questions, though.

Share this post


Link to post
Share on other sites

Here's a thought about what could cause the trouble (a shot in the dark):

 

For a couple of backups before the autodeferrals, there were some communications errors. During the last semi-successful backup, one hard drive backed up just fine, but during the backup (not the compare) of a second drive attached to the machine, there was a '519 network communication failed' error. I would guess that the person at the client computer unhooked the external drive while getting ready to leave for the day.

 

So... my guess is that some file which retrospect uses on the client machine was left in a bad state, and it is this file which is causing the autodeferrals.

 

Unfortunately, I have no clue how to track down such a mystery file, since I know little about temporary files in MS Windows. If it were a Mac problem, I'd trash preference files. Is there a similar first-try solution in the MS Windows world?

Share this post


Link to post
Share on other sites

Hi

 

An uninstall and reinstall of the client would accomplish that.

 

Can you try uninstalling/reinstalling/updating your Network adapter drivers? I would install the client after doing that. Can you try another NIC in the machine?

 

Thanks

Nate

Share this post


Link to post
Share on other sites

An uninstall and reinstall of the client would accomplish that.

 

This would be true if the file which were left in a comprimised state were in the files wiped by the uninstaller. If it's a tmp file it might not be noticed by an uninstaller. This appears to be Maser's experience. Still, this is probably the only solution until the underlying cause can be identified. Ugh.

 

Can you try uninstalling/reinstalling/updating your Network adapter drivers?

 

Not really. I'm a professor backing up others' machines over the school network. I'm not a sysadmin, not even for the department computers. Besides - all others' MS Windows machines are working just fine.

 

Can you try another NIC in the machine?

 

The client is a laptop. It has just one NIC. My machine is a plain old desktop. It has just one NIC. This is a really small time operation running on a big network.

 

Thanks again.

Share this post


Link to post
Share on other sites

This is a follow-up:

 

An uninstall and reinstall of the client would accomplish that

 

Uninstalling and reinstalling the client did not fix the problem.

 

I went and searched the client machine for files modified on the day where the backups started failing, in hopes of finding a lock file or some other settings file which would cause automatic deferrals. While there were many files which were altered, I couldn't find anything which I thought might be traceable to Retrospect.

 

Has anyone found a cause for the autodeferral problem?

Share this post


Link to post
Share on other sites

Hi

 

I spoke to another customer who had this same problem just recently. To resolve the issue we deleted the network adapter from the device manager on the client machine and rebooted. After that all was well.

 

Thanks

Nate

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×