Jump to content
Bryan Krueger

Error -530 (backup client not found)

Recommended Posts

Long time user, first time poster.

 

Settings/system

Retrospect Windows 7.6.123 w/ hotfix 7.6.2.101

Client 7.6.2.101 installed on a Windows 7 x64 machine.

Two daily alternating scripts A&B

 

These settings have been working fine for a couple of years now, but for the past two days I get the following message error -530 (backup client not found) on both A&B scripts. I've seen this error on one of network Mac clients in the past but restarting the Mac usually fixes the problem. Restarting is not fixing the problem for this Windows client.

 

Steps/checks so far

Restarted both server and client

Restared the client again after server was running.

Server and client can read and write to each other.

Manually ran a backup on the mapped drives and I get the same error message.

Changed the client IP address and tried to manually add the IP address in Retrospect, but I still get the -530 error.

The only recent software updates to the client have been MS automatic updates.

No known updates have been made to the server.

Another Windows 7 machine with the same settings is just fine with no errors.

 

++++++

 

I started to post this as a question, but now it looks more like a tip post. ;)

 

I just uninstalled and re-installed the client software. Restrspect would not recogonize the client re-install so I had to manually add the client again with the IP address. There were then two clients wit the same name so I deleted the old one, re-mapped the drives and am performing an immediate backup. Works so far.

 

I now think the whole issue was with Windows firewall settings. I wonder if Retrospect was turned off with a Security essentials update. I can't tell now because of the re-install and wish I would have thought of it sooner. Oh well. Hopefully this will help someone else.

Share this post


Link to post
Share on other sites

This is the Windows Forum, not sure if you'll find much luck. On windows systems when this problem occurs, i've found that it could be because the client is connected to the LAN, but also has their wireless turned on at the same time. Traffic goes out one connection and returns on the other and it just causes problems. Additionally, the Windows firewall can be problematic - especially whenever you upgrade the client or the server software. You can force the application to be allowed through the firewall by running retrospects include "retfwset.exe" which is usually located in one of these locations:

 

client x64 location: C:\Program Files (x86)\Retrospect\Retrospect Client\retfwset.exe

client x86 location: C:\Program Files\Retrospect\Retrospect Client\retfwset.exe

server x64 or x86 location: C:\Program Files\Retrospect\Retrospect 7.7\retfwset.exe

 

Usually though, I've found it easiest to just reload the client altogehter. This requires removing the application from control panel / add/remove programs and then checking for any left over "retrospect data" in these locations and deleting them:

 

C:\ProgramData\Retrospect Client

C:\Program Files (x86)\Retrospect

C:\Program Files\Retrospect

C:\Documents and Settings\All Users\Application Data\Retrospect Client

 

Once everything has been cleaned, REBOOT, then reinstall the lastest client version again.

 

One other thing to note. Retrospect does not automatially remove the "old" client that you just remvoed from the computer. You have to manually remove it from Configure / Clients in the left side panel options. If you don't and you accidentally point your backup script and/or backup set to the old client instead of the new one (once you've rejoined it to the server), you'll still get the error -530 backup client not found, because of course, it won't actually exist as it was removed.

Share this post


Link to post
Share on other sites

Have reinstalled Retrospect Client 7.7.114 on Win7 system after wholesale software reinstallation and now see error -530 when running a backup via Retrospect 7.7 on host PC.

 

My host can detect the client PC but says 'Please enter the password' - but there isn't a password ! (I'm sure I didn't set one)

 

How can I re-establish contact with the client PC ?   TIA

 

Dave.

 

 

Share this post


Link to post
Share on other sites

Did you forget the Client  on the Server and add it again after the re-installs?

 

If you didn't then the Server is still looking for the original instance of the Client which no longer exists after your re-installs. (Although the PC may have the same name and/or IP address the Server will see it as different.

Share this post


Link to post
Share on other sites

Did you forget the Client  on the Server and add it again after the re-installs?...

Many thanks - no, but in my haste I'd misunderstood the installation password entry process.   Client reinstallation + custom password entry = remedy.

 

Dave.

Share this post


Link to post
Share on other sites

Last successful Retrospect 7.7.620 7.7.341 backup 3 May 2017 across network (Win 7 x64 systems), but yesterday encountered "Error -530 backup client not found"

1) Upgraded and replaced v7.7 software with Retrospect v.12.0.0188 (and Retrospect Client), but still see same error.

2) Tried: Configure > Clients > Properties > Tools but see "Error -530 backup client not found"
 

Any suggestions much appreciated.

 

Dave.

Share this post


Link to post
Share on other sites

Dave... should read this post.  It is about a -530 error problem using Retrospect Mac, but AFAIK that portion of Retrospect is the same in either flavor.  As you will see from the second paragraph, I have unfortunately become something of an expert on -530 errors on Retrospect Mac.

 

Dave... should then read this Knowledge Base article, and make sure he doesn't have any of the "impossible to communicate with" problems.  In particular, he should follow the procedure in paragraph 4 of that article: Go to Configure > Clients. Select the Client and click Properties, then click Refresh.  If he gets an error message, then he should follow the procedure in paragraph 5 of that article.  If the client still fails the connection test, then he should follow the procedures in paragraphs 1 through 3.

 

If the procedure in paragraph 4 still fails, then Dave... should re-do what Scillonian says in post #4 of this thread.  I guess one question would be now, as it was then, did Dave... do anything between 3 May 2017 and now equivalent to the "wholesale software reinstallation" he did in 2015?

Share this post


Link to post
Share on other sites

Many thanks for the suggestions - Tech. support are also investigating and puzzled by my network configuration (they're perusing C:\ProgramData\Retrospect Client\ files and IPConfig details).   I'll post again when anything significant arises.

 

"did Dave... do anything between 3 May 2017 and now equivalent to the "wholesale software reinstallation" he did in 2015?"the - only the updating of both sets of anti-virus/anti-malware software:

* Vipre 10.1.3.3 - ca 14 May 2017
* Malwarebytes 3.1.2.1733/Component 1.0.122/Update package 1.0.2061 - ca 19 May 2017
 

Dave

Share this post


Link to post
Share on other sites

First, when Dave... says "Tech support are also investigating ... ", does he mean Retrospect Inc. Tech Support or his own installation's Tech Support?

 

Second, IMHO Dave... should read again the sixth paragraph of this post.  I don't run anti-virus/anti-malware software, but the -530 situation he is describing sounds similar to the one I had for four months over a year ago—a situation that eventually seemed to be related to a "conceptual bug" bug involving the Firefox browser doing automated updating.  In addition I had a -530 situation for two weeks a year ago, described in the second paragraph of this post, that definitely was a "conceptual bug" caused by Microsoft AutoUpdate on the old Mac G4 I backup once a week; I solved that situation by trashing Microsoft AutoUpdate.

 

I'm not suggesting that Dave... disable the anti-virus/anti-malware software on his client machine, even though a known feature of such software is to do automated updating.  However, assuming he is booting the client machine shortly before his Backup script is scheduled to run, I suggest that he setup a "sacrificial script" per the fourth paragraph of this post—substituting Selectors for Rules because he is running Retrospect Windows.  He may need to schedule that "sacrificial script" more than 10 minutes before his Backup script, depending on how long the automated updating takes for his anti-virus/anti-malware software.

Share this post


Link to post
Share on other sites

Thanks again - it's Retrospect Inc. Tech Support who I've contacted and who are currently puzzled ;-)

 

I use Microsoft Update, not in auto-install mode but in notification mode, for me to update as appropriate.

 

Automated updating of signatures applies for the anti-virus/anti-malware systems, but not the software - this is a manual process.

 

Dave.

Share this post


Link to post
Share on other sites

It's the automatic updating of anti-virus/anti-malware signatures that I'm talking about, not the software. This post amplifies on the first linked-to post in the second paragraph of post #9 in this thread; the -530 problem on my MacBook Pro over a year ago mysteriously disappeared after a major update to my copy of Firefox.  The only non-occult explanation I could come up with is that, prior to the major update, Firefox was doing some kind of automatic updating of files—possibly relating to Adblock Plus.

 

IMHO Dave... should also look into automatically-repeated updating notices for Adobe Reader, coming from the Windows equivalent of Adobe Flash Player Install Manager.app.  As this post recounts, deleting that install app got rid of automatically-repeating notices which had caused -535 errors and a later -505 error on my MacBook Pro in the past.

Share this post


Link to post
Share on other sites

The third paragraph of this post makes it even clearer why I think Dave...'s -530 problem may be caused by some kind of automated updating being done on his client machine.  In the cases I've encountered, that was being being done when the client machine was first booted or awakened from sleep.  That explained why, when I booted the client machine at least 15 minutes before the Backup script was scheduled to run, it ran OK.  It also explained why, when the script had bombed with a -530 error, I could later see the client machine by doing a Clients->select client->Locate (the Retrospect Mac Console equivalent of Configure-> Clients->select client->Properties->Refresh, I think)—after which the script would run when I manually submitted it.  However I can imagine some app, such as a really zealous anti-virus/anti-malware app, that would continually do automated updating.

 

All this assumes that, as Dave... reported in post #6 in this thread, he started getting a -530 error while he was still running Retrospect Windows 7.7.341.  It also assumes that, even if he is not part of his installation's IT team, he has enough knowledge of its inter-machine communications setup to be sure that no firewall software (such as the Windows firewall) or hardware (such as a router that can block ports within his LAN) has been recently installed/modified in such a way that port 497 is now blocked for TCP and/or UDP.

Share this post


Link to post
Share on other sites

I've tried PortQryUI on the Retrospect Client PC and see this response:

 

TCP port 497 (unknown service): LISTENING

UDP port 497 (unknown service): NOT LISTENING
portqry.exe -n 127.0.0.1 -e 497 -p BOTH exits with return code 0x00000001

 

Dave.

Share this post


Link to post
Share on other sites

Ok, let's go back to Dave...'s post #6 in this thread.  It sounds to me as if, from his "backup server", Retrospect can't see his client at all.  

 

I see now that what he's done is to first check if port 497 is open for TCP and UDP on the client.  I have essentially no experience with the Windows command line, but—based on the top part of this article and my long-ago experience with the Unix command line—it looked to me originally as if what Dave... did was to check from his client whether port 497 is open on his server.  That's because I forgot that 127.0.0.1 is in most cases the IP address for localhost (see my P.S. below).

 

The "Working with Clients" section in the Networked Clients" chapter Retrospect Windows 12 User's Guide, on page 293, says "Retrospect uses port 497 for both TCP and UCP communications. To successfully find and access Retrospect clients, your firewall needs to be set to allow communication over port 497 for both TCP and UDP on all Retrospect clients as well as on the Retrospect backup server."

 

If port 497 turns out in fact to be open for both TCP and UDP on his client, we then need to go back further in this thread to posts #3 through #5—which were made in 2015.  Dave... should do what Scillonian advised in post #4.  That was to Forget the Client on the Server and Add it again; Forget is covered on page 302 of the UG, while Add of a single client is covered on pages 293 through 295 of the UG.  Once he has done that, Dave... should follow the procedure in the "Testing Network Addresses" section on pages 295 through 297 of the UG, using the known LAN address of the client machine.  Note that page 297 says "If there is no TCP/IP response from the specified address, Retrospect reports error –530"; sound familiar? 

 

When the Client had been Forgotten, Added, and its address tests OK, Dave... should re-add the newly-re-established client to the appropriate scripts.

 

P.S.: Radically revised the second paragraph, because I originally erroneously thought that 127.0.0.1 was the IP address for the "backup server"—whereas it's the IP address for localhost (meaning the computer on which the command is being run).  What confused me is that, using Retrospect Mac where I run the Retrospect Console app on the same computer as the "backup server" Retrospect Engine (see the third paragraph in this post, if you want to understand that; the sixth paragraph in the same post briefly explains why that superior app separation can't be implemented for Retrospect Windows), the (for me, one-and only) "backup server" address in the Console defaults to 127.0.0.1.  Sorry.

Share this post


Link to post
Share on other sites

"When the Client had been Forgotten, Added, and its address tests OK ..." - I've 'forgotten' the client, but can't 'Add' a new one.

 

Secondly, further feedback from Retrospect Tech Support: "We frequently see the network configuration "changing"

2017-05-31T12:04:49: Network configuration changed
2017-05-31T12:20:09: NetStop: signaling gEndEnumIntfEvent
2017-05-31T12:20:14: Network configuration changed
2017-05-31T12:20:28: Preferred connection changed. Reset listener.
2017-05-31T12:20:34: netCheckNewInterfaces(windows): had an IP address and now lost it
2017-05-31T12:20:34: No IP Address available
2017-05-31T12:20:34: NetStop: signaling gEndEnumIntfEvent
2017-05-31T12:20:34: netEnumInterfaces: broke out of interface loop
2017-05-31T12:20:34: NetSockDel: interface 0 not found, socket 572 could not be deleted"

 

And: From the log I sent him prior, he [network engineer] mentioned that clearly something unusual is going on with the network since netCheckNewInterfaces is alternating between "Network configuration changed" and "No IP Address available". He mentioned

"While retroclient will eventually find "192.168.1.70" again it might not be able to establish a UDP listener which is what their server would use to locate their client on their network."

 

Further investigation by Retrospect is in hand.

 

I've also run PortQryUI on the other (non-Client) Retrospect PC, querying port 497 for both TCP/UDP, results below.

 

Dave.

 

Starting portqry.exe -n 127.0.0.1 -e 497 -p BOTH ...
Querying target system called:
127.0.0.1
Attempting to resolve IP address to a name...
IP address resolved to XXXLaptop [Retrospect v12; not Client]
querying...
TCP port 497 (unknown service): NOT LISTENING
UDP port 497 (unknown service): NOT LISTENING
portqry.exe -n 127.0.0.1 -e 497 -p BOTH exits with return code 0x00000001.

Share this post


Link to post
Share on other sites

First, I have now radically revised my second paragraph in post #14 in this thread, because I was wrong about what the IP address 127.0.0.1 means (see the P.S. of that post for an explanation of why I made the error).

 

Second, given Dave...'s post #15, my only suggestion would be to give his Client PC a static IP address—see this section of the applicable Wikipedia article.  That is the advice the now-departed (from Retrospect Inc., not AFAIK from life) Alan of Retrospect T.S. gave me nearly two years ago, when I started using Retrospect Mac 12 after five years away from Retrospect Mac 6.1. I gave my two clients the static IP addresses 192.168.1.202 and 192.168.1.203 (which are higher than any DHCP-assigned IP addresses I am likely to have on my LAN), using the internal "website" GUI on my Adaptec Internet-facing (and only) router—which I accessed using the IP address 192.168.1.1.  Alan's advice solved the problem I was having getting my scripts to access my clients; it may do the same for Dave....

 

Note that purposely assigning Client machines a static IP address is not mentioned in either the Retrospect Mac or the Retrospect Windows User's Guide.  This used not to be necessary for Retrospect Mac 6.1 and previous versions, which I used for 15 years from 1995 to 2010  (my "backup server" machine died of old age in 2010).  My gut feeling is that some change to either accepted standards for IP addressing and/or the underlying Retrospect multicast code occurred in or after early 2009 (when Retrospect Mac 8—a Retrospect Mac 7 was never released, which became the foundation for Retrospect Windows 8 and following versions, was released).

 

P.S.: When I telephoned Retrospect Tech Support in mid-2015 and spoke to Alan, it is likely that I was getting a -530 error for my MacBook Pro client.  I remember that my script couldn't find the client when running via a schedule, although the script could find the client when submitted manually after I did a Sources->select client->Locate (the Retrospect Mac semi-equivalent of Configure -> Clients -> Properties).  Although I can no longer remember the error number, giving my MacBook Pro a static IP of 192.168.1.202 fixed the problem.

Share this post


Link to post
Share on other sites

A temporary workround has been found: manually disable the Windows Firewall option in VIPRE on both PCs (auto-managed by VIPRE).   The Firewall can be enabled afterwards.

 

Dave.

Share this post


Link to post
Share on other sites

Congrats, Dave....  IMHO what you want to do on a permanent basis is to open port 497 for both TCP and UDP on both PCs.  However this review implies that may be difficult to do using Vipre, because it says that Vipre has its own firewall distinct from Windows Firewall; see the  "Firewall: Good News, Bad News" section.  It might be best to permanently disable the Vipre firewall and to use Windows Firewall, which I presume can be manipulated to open port 497.  BTW, the PC Mag review rated Vipre at only 3 out of five "stars", and it didn't speak highly of Vipre's firewall.

 

It turns out paragraph 5 in this Retrospect Knowledge Base article, which I linked to in post #7 in this thread, talks about firewall software on the client and backup computer—and says port 497 must be open for TCP and UDP.  I did mention that paragraph in post #7, and mentioned port 497 explicitly from post #12 onward.  

 

Now that I've read the PC Mag review a bit more closely, it says "Vipre defines permissions for its own processes and a few essential Windows processes. For others, it allows all outbound traffic and blocks all unsolicited inbound traffic."  If you ran your portqry.exe tests with the Vipre firewall enabled, it sounds as if the tests didn't detect that the Vipre firewall was blocking inbound Retrospect multicast traffic.  However I now see in the fourth paragraph of the PC Mag review section I referenced that you can enable Vipre's firewall prompting, but I'm not sure how well that prompting would interact with the Retrospect "backup server" and Client apps.  Therefore I stand by my suggestion in the first paragraph of this post to use Windows Firewall instead, if you insist on having firewall software within your LAN rather than relying on your Internet-facing router to do that job.  I welcome comments on this from any malware expert on the Forums.

Share this post


Link to post
Share on other sites

Some followup to my post #18 in this thread:

 

First, this page by the maker of Vipre describes how to open a port for Retrospect on a client; see the section "Firewall application and Port Exceptions".

 

Second, it's apparent that Dave...'s use of portqry.exe, described in post #13 in this thread, didn't detect the problem with port 497 not being open on his client because of the Vipre firewall.  Looking at this Microsoft page, it's not clear to me whether portqry.exe really works to detect open ports on the machine the command is run from—even though a lot of examples on that page use -n 127.0.0.1 as a parameter.  It looks as if Dave... should have used portqry -local instead, and looked for port 497 in the list of ports returned.

 

P.S.: Of course Dave... could theoretically also have used portqry.exe from his "backup server" to see if port 497 was open on his client machine, thusly

   portqry.exe -n clientmachineIPaddress -e 497 -p BOTH

But that would assume that he knew the actual 4-octet IP address value for what I've denoted as clientmachineIPaddress.  Judging from what Dave... wrote in post #15, it looks as if that client IP address varied over time.  AFAIK, a way to make that client IP address static would be to do what I suggested in the second paragraph of post #16.

 

P.P.S.: I have submitted the contents of this post as a no-reply-needed Support Case, just to let Retrospect Inc. T. S. know what the outcome was in case they encounter the same Vipre problem again.

Share this post


Link to post
Share on other sites

Update - currently: stalemate, VIPRE Tech Support and Retrospect Tech Support need to talk to each other.

I've tried a number of VIPRE firewall settings, without success - screenshot attached - and the conclusion seems to be that VIPRE and Retrospect are no longer compatible.

This is possibly due to VIPRE inflexibility with the settings for TCP/UDP protocols (Retrospect Tech Support say: "The client uses both TCP when streaming data, and UDP when sending multicast packets. Both should be allowed for port 497").

post-40257-0-47011000-1499160171_thumb.jpg

Share this post


Link to post
Share on other sites

This appears to be resolved, after VIPRE Tech Support were allowed direct access to my PC re Retrospect Client.

 

The procedure complemented the VIPRE Exception/Port settings (see previous screenshot), and involved 2 VIPRE firewall 'learning' sessions: 1) with VIPRE on the PC, where various modules are flagged by VIPRE (some have cryptic names), to be set as 'allowed' until such messages cease to appear, whilst also running Restrospect on the networked Laptop, 2) and then for VIPRE running on the networked laptop, ditto.

 

NB After concluding the successful 'learning' sessions on the PC ('Retrospect client'), and on the networked laptop, the PC was immediately shut down via Windows 'sleep' mode. Upon re-starting the PC, several hours later, a Windows 'Blue Screen' appeared, screenshot attached. It seems to have been a single event, and not evident in subsequent reboots.

post-40257-0-91337700-1499424071_thumb.jpg

Share this post


Link to post
Share on other sites

FYI: Just upgraded to Retrospect 12.5.0.177 and find that Error -530 (backup client not found) has returned - does anyone know if Retrospect is going to address this problem ?

Share this post


Link to post
Share on other sites

 

FYI: Just upgraded to Retrospect 12.5.0.177 and find that Error -530 (backup client not found) has returned - does anyone know if Retrospect is going to address this problem ?

Ditto.

Share this post


Link to post
Share on other sites

Dave..., post #21 in this thread says you solved your -530 problem by having VIPRE Tech Support conduct two firewall "learning" sessions—one on your networked PC (you called that a Retrospect client, but I'm wondering if it is your "backup server") and one on your networked laptop.  Did upgrading to Retrospect 12.5.0.177 involve installing any new versions of Retrospect software, Client or Server?  If so, I'm afraid you may have to repeat the firewall "learning" sessions.  Personally, I don't see why you don't disable the VIPRE firewall entirely (as you did temporarily per post #17 in this thread), and use Windows firewall instead.

 

HawkinOz and Dave..., there is no indication in the Release Notes for Retrospect 12.5.0.177 that Retrospect Inc. has addressed this problem.  I have not had any reply to my outstanding Support Case that indicates they are trying.

 

HawkinOz, you give us no indication of what versions of Retrospect software, Windows software, or other network-using software you are running.  Without information we can't help.

Share this post


Link to post
Share on other sites

Dave... Personally, I don't see why you don't disable the VIPRE firewall entirely (as you did temporarily per post #17 in this thread), and use Windows firewall instead.

 

David: Many thanks - I'll bear this in mind (this latest time I simply switched off the firewall on both systems, whilst I undertook a backup, but I'm not keen on this).

 

Dave.

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

×