Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About pholzmann

  • Rank
    Occasional Forum Poster
  1. pholzmann

    519/no cnct to Windows 2000 client

    I wrote: [Hmmm... we *do* normally run McAfee ASaP antivirus, which hides itself rather well... so possibly there's a hidden service I haven't found yet. Will look around a bit.] Further testing: removing the antivirus service (myagtsvc) makes no difference. AND (fyi...) connections work great with another Windows 2000 client that's running ASaP Antivirus. So, more ideas needed...
  2. pholzmann

    519/no cnct to Windows 2000 client

    Thanks, Irena... >What version of the client software? Application? Latest: 5.6 with current updates >Do you have anti-virus software or crash protection on the client? If so, test disabling these. >Are there any firewalls between the two? Any firewall software on the client? As I described, all applications are disabled, all optional startup items..., and I've been going through and disabling background services... so no antivirus, no firewall, no other "strange" stuff other than what I listed. [Hmmm... we *do* normally run McAfee ASaP antivirus, which hides itself rather well... so possibly there's a hidden service I haven't found yet. Will look around a bit.] >What OS is the server running? Also Win2k, SP2 >Can you ping with no packet loss between the two? Yes, at full wire speed. >What if you connect the two clients with a crossover cable? This can pinpoint if the problem lies in the network or in one other computers. No change. >Have you reinstalled the client? Several times...
  3. I've got one client computer that absolutely _will not_ connect to retrospect. It works fine with all other software, and I was able to see it enough to set it up as a client. However, any attempt to view/refresh it (Client->Properties->Refresh) causes a 519 error or worse as a visible result. The new 3.0 driver update does not help. I've now done a lot of low level technical checking, and while the problem is still not solved, I have a few clues. I'm hoping someone can help me take this further. 1) When attempting a refresh, IP traffic *does* get through between the two machines. (Using low level tools from www.sysinternals.com to test -- these are GREAT tools!!!) However, the client machine is left in a state where the main retrospect client service (retroclient) is attempting to use 100% of CPU time forever. Nothing will stop this other than killing the service or a reboot. 2) After attempting a refresh (in 1 above), the Tools and Volumes tabs are non functional. If I use them BEFORE a refresh, they work fine. 3) I've tested to ensure no other application or process is interfering with communication. his machine has several behind the scenes services running that I don't see on some of our other machines. I've yet to complete fully testing these (ie checking to see if their presence is interfering), because I have no clue where some of them originate. The remaining services that need testing are: mmc == MS Management Console mspmpsv == MS WMDM PMSP service packethsvc == NT Authority System QUESTIONS: a) Do you know what these are, could they be causing trouble, and how can I disable them. Any other ideas of what I can do to work around this show-stopper problem? At this point, our evaluation of the software is that it does not work at all on some machines, and is frail (easily loses its connection) on others. That would be awful -- there's so much I like about this that I *really* want to be able to recommend it to our many communities worldwide. Thanks, Pete
  4. pholzmann

    2k pro client: 517 error

    >What version of the Retrospect application and client are you using? Latest 5.6, Desktop Trial. >...each computer only has a single client installed, right? Of course. And we're only dealing with one backup computer (the laptop). We've continued to test all day and have not found a way around this: The laptop sees, and successfully connects to, the clients on network A. It can even do so remotely across the Internet (at much reduced speed of course!) if we open up enough firewall holes. Both Windows 2000 and Win98 clients. However, network B is a different matter. A Win98 client we just added is fine. But for a Windows 2000 client, running on another laptop, the backup laptop sees and can add but cannot actually connect to or test a link to the Windows 2000 client. We get quite a variety of strange errors, including most recently an assertion error - cpp-457. We're also now getting error 541 (client not running - but it is!), and then get good data out of the "volumes" and "access" tabs. The general tab refresh button simply will not work. The systems are talking together just fine in all other ways. Only Retrospect has a problem. Thanks for helping with this! pete
  5. pholzmann

    Common DHCP Question?

    Melissa, Your instructions include a few things that I don't see in Retrospect. Perhaps there's a different set of instructions for Windows? You suggest... >go to Configure/Clients ...no problem >... and click on Network. >Highlight the client and click login. >...Do not log them in by pressing the "add by address" button. There are no such buttons or icons: "network", "login", "add by address". Apologies for "dumb" questions :-) p
  6. We're evaluating Retrospect, hoping we can both use and recommend to many clients around the world. Finding a number of strange/painful problems. Overall, perhaps the most painful is that the software seems "fragile" with respect to its access to network resources and the SCSI tape drvie. Scenario: -- A 10/100 ethernet LAN that runs very reliably. Our test tools are easily able to transfer data continuously at wireline speed without any data errors or drops. -- A SCSI backup drive (VXA-1) that also runs very reliably. We've used other software (Cheyenne Backup for Windows, Knox Arkeia for Linux) pretty extensively without hiccups. We're seeing the following kinds of problems, quite regularly: 1) Intermittent loss of access to shared files. When backing up network shares (from Win98 and Linux/Samba), the backup will run for a while, then typically get a lot (hundreds) of -1116 errors [can't access network volume]. Immediately retrying the backup will cause more of these files to be found without trouble. The network volume has not hiccuped, nor has the network had a problem. [One guess?... our portable laptops are set with relatively short DHCP renewal times. Could there be a bug such that if the IP address is renewed (even to the same IP address, since ours are hardwired to the MAC address), the backup breaks? This would be a subtle bug to find, since desktop machines would by default only experience this problem every couple of days when the DHCP address renews.] 2) Extreme sensitivity to network or client activity (?). Apparently, if a client runs any screen saver (even a very mild standard Windows screensaver on a 1.5GHz Win2k Pro machine), the backup will terminate with a -519 error. What's really strange about this one: the situation where we saw this was with a client that had two partitions to be backed up, both on the same physical hard drive. Drive "C:" backed up without error (perhaps because it is small?). Drive "F:" had a lot of trouble until we carefully disabled all screen savers, etc. I don't understand why there's such sensitivity to speed; this is a fast machine, obtaining 10000 k/sec network throughput without trouble. 3) Extreme sensitivity to tape/SCSI errors. Using our setup, I've never before had a backup terminate prematurely due to SCSI communication errors. Our drive always passes all SCSI communication tests. But we've seen Retrospect terminate backups prematurely _several_ times in the last few days, due to such errors (error 203, hardware failure). Without any change, retrying the backup succeeds. Makes me wonder if it is retrying properly or has some other type of bug. We'll continue to test to see if we can discover ways to make all this more reliable. Suggestions most welcome however. Right now, we're concerned that it just seems way too hard to get a reliable backup. Thanks, Pete
  7. Evaluating Retrospect, hoping we can both use and recommend to many clients around the world. Finding a number of strange/painful problems. Here's our #1 current issue (several posts will follow with others): Bottom Line: I'm getting error -517 Backup Client is Busy, and can't get it to go away. Need some ideas. Scenario: - Retrospect is loaded on a high end laptop, with (VXA LVD/SE SCSI tape) backup drive attached. - We have three separate locations that need backing up. Once set up, our idea is to use the drive on a desktop machine in one location, and 'borrow' the drive to do backups in the other locations using a laptop. - Have successfully backed up one of the remote locations using the laptop - Now brought the laptop to a second location, installed a client on one of the machines on the LAN, and attempted to connect to the client. Symptoms: * The client (running Win2k Pro, with all other software disabled) easily installed the client software, and was visible to Retrospect as a client. * However, when either "Refreshing" the client properties window, or closing it, there's a long delay and then we get error -517 Backup Client is Busy. Things tried: * Reinstalling the client * Lots of reboots * Ensuring other software is disabled * Ensuring the computers are idle * Ensuring TCP/IP is clean and happy Any other ideas? This is a bit frustrating! Could Retrospect somehow be confused since the DHCP IP address used for backups at location A is different (of course) from the IP address assigned when the laptop is moved to location B? I don't see anywhere to configure this. Thanks much, Pete
  8. pholzmann

    URGENT-Can't install:

    OK, we've tried: * New installer (both of Desktop and Workgroup versions) * No virust checkin in use on my computer * No background/systray stuff * Install on another (Windows 2000) computer * Yes installing on main C drive (doesn't matter yet -- the installer won't even get started!) It's almost acting as if it were a compressed package that is too large for the program that was used to compress it. In other words, this is a 20MB compressed file, which is larger than the old DOS compressors can handle. The installer *.exe file shows up on my system as a DOS program, not a Windows program. Could it be that the current files on the web site were not created properly? Thanks, Pete
  9. I'm attempting to install the Desktop trial on Win2k (SP2). Downloaded the executable, no problem. But attempts to run immediately fail. I opened a command prompt window and tried again. I get an immediate error "Program too big to fit in memory". I've got 256MB or RAM, gobs of disk space. Any suggestions? I'd really like to try this software out!!! thx, pete