**Slow** client update scan; Saving config changes (not)

[awnews]

On Sat. night (5PM) I set Retrospect to scan and update (=>107) all found clients with the latest client software. I figured it would be done in a few hours. However, when I came in on Mon. morning (8:30PM), it was *still* scanning, having reached only 82 of 105 clients. And most of those were off-line. The log showed some clients already up-to-date [no update needed], some updated by the scan and many not found. But the thing was taking an *eternity* to make its way thru the list over a 100M & 10M (mix) LAN (all clients on same subnet).

 

When I tried to [stop] the update scan, the program pretty much hung up [click button, button greys but nothing every happens, dialog never vanishes, program non-responsive]. After 20min and no progress, I finally TaskManager-killed all of Retrospect.

 

1) There's no way the program should take this long to scan for and update clients. Doing a Piton multicast to ID clients doesn't take this long and manually updating clients doesn't take that long. I don't know if Retro is just unbelievability slow at skipping over *missing* clients? Perhaps it needs to use the Piton multicast as part of this process.

 

2) Stop means *stop*. There's no acceptable reason why clicking on the Stop button shouldn't cause the scan to stop *immediately* (*maybe* finishing if it its in the middle of a particular client update).

 

-----------------------------------

BTW, when I TM-quit Retrospect and restarted it, all the clients that I had previously Added had been forgotten and I had to manually re-Add them. I've seen Retrospect do this before, losing settings made *days* before if the program is TM-quit. My "workaround" has been to quit Retrospect manually after making any changes. However, Retro should be saving the changes on it's own (on every change, after N changes, every N minutes) or you need to give me a "Save" menu option so I can do this myself without needing to manually quit and restart the program.

[natew]

Hi

 

Are there any errors in your log or in the Windows event log?

 

In regard to the slow stop, I'm not sure we can blame Retrospect entirely for this. Windows too will lock up when polling for network resouces especially if explorer barfs along the way. (This time Retrospect did the barfing...)

 

Here is what I suspect happened:

During the update scan Retrospect came across a client entry in your config file that was corrupt. That locked up the scan process which made Retrospect unresponsive.

 

The Task manager quit of the process managed to take the Retrospect config file down along with it. As a result, when you restarted the machine the backup config file configxx.bak was imported to replace the damaged configxx.dat. The configxx.bak file is a couple days out of date so any new settings that you had made were lost.

 

That is one theory anyway. Did the machine function normally after closing Retrospect?

 

Thanks

Nate

[awnews]

I don't know about a corrupted client config. I guess I can rerun the same scan next Fri. and note where Retrospect locks up (if it does) again. Of course it shouldn't *never* lock.

 

On the TM quit and lost settings, this is "normal" for Retrospect. I've often seen Retrospect lose all setting changes made since the last Retro quit/restart if Retrospect or the PC crashes or has to be TM-quit (I think I've posted on this). It seems like the program only writes out config changes on quit. As noted, a periodic save or manual save feature would be a good "enhancement" to the program.

 

Yes, Retrospect seems to be doing OK after the restart, although it's just sitting there at the moment (all backups deferred since I'm still making a lot of changes to the clients and server configs). No messages or logs regarding any corrupted configxx.dat files.

[natew]

Hi

 

Sorry about that- I forgot how well you know the program.

 

Yes, periodic saves of the config file would indeed be a good thing. I'll submit this again as a feature request.

 

For the moment the only option is to close and relaunch Retrospect from time to time.

 

Thanks

Nate

[awnews]

I just got done doing more client moves and software updates (e.g. with the latest client (.107), up from .106 and earlier [even some 6.5.x] versions).

 

I found that the fastest way to update these clients was to *not* use Retrospect's scan and update. The problem with that method, as I noted earlier, is that it spends a *huge* amount of time scanning for stations that aren't present. Instead I manually used the "Add" client method which uses the Piton multicast. I then (re) "Added" clients that were already listed as present and updated only those that had old client software.

 

So, as a suggestion, Retrospect could save a lot of time during the automated updates if it would *first* use the very fast Piton multicast to only find clients that are accessible, and *then* only update those clients. This would avoid the huge delay for timeouts, regardless of whether we "blame Retrospect entirely for this" or the fact that "Windows too will lock up when polling for network resources" since missing clients won't be polled.

 

------------------------------

And, as another suggestion, how about a way to do a "Proactive" update of the client software. I use SpySweeper Enterprise to block or remove spyware and have it set to auto-update definitions and do software updates as they are available from the vendor's servers (downloaded to my server nightly). It does these daily, without manual effort from me, whenever the client machines are on. This is far more elegant and automated that how clients are updates with Retrospect.