Error -519 (no client) unresolved after reintstall

[Camelhump]

I am running into issues with error -519 .

 

I have a BUNCH of computers which are givng me this error after trying to manually add the client to Retrospect server via 'Add source directly'.

 

So far for windows clients - reinstalling the client software resolves this issue and the client can then be added manually.

 

For Mac clients, so far this has NOT resolved the problem.

 

The clients are now running 10.6.4, with Mac Client 6.2.029.

 

Any ideas as to how to resolve this?

 

so far I have tried:

- removed the retrospect.state file from /library/preferences

- I have reinstalled from the installer

-Restarted the client computer

 

Thanks

[Daniels]

Have you made sure the 10.6.4 firewall is not blocking client from communicating with the server? You can either turn off the firewall or add an exception for the client.

I would also suggest updating the clients to 6.3.029

 

[Camelhump]

sorry - the clients are 6.3.029 -that was a typo.

 

The firewall is/was off. So this is not the cause of the problem.

 

Any thing else I should look at?

 

Thanks

 

[twickland]

Be aware that, for clients added directly via an IP address instead of a DNS name, Retrospect 8 typically reports a -519 error in place of the expected -530 error when the client is simply unavailable on the network, such as when it's shut down. Perhaps this may account for some of your instances of this error.

[Camelhump]

no - the client is there, and awake.

 

I am in the process of trying to add the clients.

When finding these errors.

 

What is really mysterious is that the macs are all identical - Mac Minis, and were all setup from the same image. Some will connect, no issue, others wont....

 

 

[twickland]

Can we assume the problematic machines are not in a different subnet from the ones that do connect? Are some possibly also connecting wirelessly? Have you confirmed that all are still at the same address where you first added them?

[Maser]

Are you adding clients by IP address or by hostname?

[Daniels]

If you are using IP address have you made sure that all the clients have static IP?

[Camelhump]

all clients are being added by IP address.

 

The clients are on one of 2 subnets xxx.xxx.104.xxx, or xxx.xxx.168.xxx. Since the clients are being manually added by IP address, different subnets should not be an issue.

 

I have 1 client that uses a wireless network, however the error Im getting there is different (-554), and I havent yet tried to resolve that error - since I have been unable to find out what that error means.

 

The clients are technically assigned IP addresses by DHCP, however, the addresses assigned are permanent once assigned, unless there is a change to the client computer which affects the MAC ID of the computer.

 

I am not sure, but it appears as if (only one instance so far) that a Re-Re-Intsall + restart, may resolve the issue.

 

 

[Maser]

The clients are technically assigned IP addresses by DHCP, however, the addresses assigned are permanent once assigned, unless there is a change to the client computer which affects the MAC ID of the computer.

 

 

 

You say "technically" -- can you confirm this?

 

I've worked with too many places that don't know how to do static DHCP correctly that it wouldn't surprise me if this was the problem.

 

 

 

[Daniels]

The only way you get a permanent IP address with DHCP is to use the setting Manual IP using DHCP. Unless you specify a static IP everytime a computer is restarted the DHCP server will assign it a new IP address from what is available. If you want to add clients by IP addresses you need to give each client a static IP.

[Maser]

well, no...

 

If you run a DHCP server, you can assign a static IP address range and link specific addresses to the MAC on the computer (as indicated above). We do this here and it works fine.

 

But if you are somewhere where your network people don't really know how to do this correctly, your client machines might not be getting the static IP address you think they are once you've added them.

 

 

 

[Camelhump]

the IP addresses are static for all purposes.

THere are 2 conditions in which a computer might not receive the IP address as it previously had

1 - offline for more than 1 week

2 - a change in MAC ID (new network card)

 

And yes - the computer do have the same IP addresses - I check just to be sure when I have done a re-install of the retrospect client software.

[Maser]

"offline for more than a week" -- shouldn't happen if static DHCP is set correctly. (Well, I guess it *could* happen, but that would be really, really odd for a setup -- nobody goes on vacation in your company?)

 

Have you tried readding the client, but starting with a temporary new config80.dat file -- just to see if you can add it when nothing else is in the config80 file?

[Camelhump]

after much much more screwing around... sigh...

I may have resolved the issue of the unresolvable -519

 

All of the Mac minis are new, they were all setup from 1 image, BUT, it seems some of them are not the same (why I have no clue).

 

On one of these minis, I reinstalled the OS and now the client can be added.

 

I will be trying this on other minis next week.

I will post a followup.

 

 

@Smaser - yes people go on vacation, but that doesnt mean the computer is off, and therefore off line.

[CallMeDave]

All of the Mac minis are new, they were all setup from 1 image...

 

Was the Retrospect OS X Client software part of the pre-made image?

 

Did you use a public key inside the installer before using it for the master image?

[Maser]

FWIW -- my Mac "image" has the Retrospect Client installer on it -- but it's not been configured (beyond adding the password at installation and setting the "private" button in the client preferences.)

 

I have no problems installing this image on machines and then adding the client.

 

I don't use the Public Key...

[Camelhump]

Installed - yes

public key - no

 

as someone once said "...curiouser and curiouser..."

 

I took one of the clients that doesnt want to talk (-519 error). I added an external Firewire drive, and installed the OS (10.6.3 - from restore disk) and updated it to 10.6.5, installed retrospect client, on the firewire drive.

 

Booted the mini in my office (on subnet A) using the newly installed OS (10.6.5) on the firewire drive. Server (also on subnet A) can see it, and it even shows up automagically.

 

I use carbon copy cloner to image the mini to a second firewire drive as a backup (10.6.4). I then use carbon copy cloner to move the updated 10.6.5 OS to the mini.

 

Reboot the mini, from the new cloned OS, on the mini's internal drive, still on subnet A, check with the server and it can see the mini.

 

GREAT!!! - now I have a simple quick way to fix the other clients!!..... (not so fast)

 

I put the cloned mini into place where it is supposed to live (this places it on subnet . Go back to the server try to add the mini - by IP address... No joy. still get a -519.

 

Bring the mini back to my office, boot it from its internal drive (on subnet A), the server is happy to see to it.

 

Move it back to the location it is supposed to live, boot from the firewire drive that was the source of the clone (on subnet . Server will see it and add it.

 

(without moving the mini, and all on the internal drive)

- re-boot, no joy -519

- remove retro client

- reboot

- install new client - still get -519

- reboot still get -519

 

Move mini (booting from internal drive) to different network port (subnet A) - server sees it an it can be added

 

Move mini (booting from internal drive) to a 3rd network port (subnet - client is now -519

 

All attempts to test or add the mini to the server are done via actual IP address.

 

ANY help here would be useful

 

Thanks

[Maser]

Are you actually *removing* the clients after you add them successfully in Subnet A before you attempt to add them in Subnet B? (That's not clear...).

 

 

If I read this correctly...

 

Using your *firewire image* -- you can boot *any computer in Subnet A* with it -- the computers will get a *different* static DHCP address each time (right?) and you can add the computer to the engine without problem (different IP address each time).

 

But if you take the same firewire image and boot *any computer* in Subnet B with it -- getting a completely different DHCP address -- and you can *not* add the client?

 

 

If so, then I'm guessing there's either a misconfiguration in DHCP settings in "Subnet B", *or* there's a firewall issue in Subnet B that doesn't exist in Subnet A.

 

And this would have nothing to do with the client software (or the image -- again, I'm assuming you are using *full* DHCP -- not "DHCP with manual address" on the client.

 

 

 

 

 

[Daniels]

The other issue to consider is can subnet A actually see computers on subnet B?

[Camelhump]

Smaser -

not quite.

any computer booted with the firewire drive on subnet A or B is visible (via direct IP) to the server.

 

The mini itself is visible to the server only on subnet A, but gives -519 error on subnet B, regardless of network port.

 

As far as IP addresses - the IP address of the computer being booted does change with subnet, and computer, IP addresses are assigned via (full) DHCP.

 

After a client is added (ive resorted to testing), it is removed from the server list before trying to add it again (on either subnet).

 

Smaser & Daniels

There are computers on subnet B which are already added to the server, via direct IP. So there is not a firewall between the two subnets.

 

-----

I have, since my last post, re-intalled the OS from the restoration disk (installs 10.6.3), this does an "archive and install" and re-installed retro client. The behavior described above remains....

 

I am now in the process of erasing the disk entirely, and reinstalling...we will see....

 

 

 

[Maser]

So, the mini -- that is visible on subnet A, but errors on subnet B...

 

If you boot this mini from the firewire drive -- on subnet B -- does it add properly?

[Camelhump]

smaser - yes

 

I have been doing long, boring, and extensive testing.

Here is what I found:

Basic setup -

- I boot from the firewire drive (retro client works as expected)

- using disk utility, I erase the internal drive of the mini.

- using CCC I clone the firewire boot disk to the mini.

- boot mini using internal (cloned) drive, retro client works as expected

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

migration assistant

- move everything (except admin account) from backup image of mini - this gets the users's files and accounts back.

- retro client no longer works -- ONLY ON subnet B -- but works as expected on subnet A

 

go to backup clone of original state of the mini - remove retrospect (and all related files - search including system files for "retro" - delete them all)

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

- repeat above basic setup

- use migration assistant to:

-- bring over users's directories - retro client works

-- bring over 'other files and folders' - retro client works

-- bring over applications - retro client stops working on ONE subnet but not the other.

- remove retrospect from cloned and migrated mini (see above removal process)

- install retrospect again - retro client works !!!

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

 

now trying to find a less time consuming process to repair other clients.

 

Under the above method - clone computer, erase drive, clone working OS to computer, migration assistant to move user files etc back to computer, clear out retrospect and reinstall - test - at least 1.5 hours (depends on how much data has to be cloned and re-migrated)

 

So - I try this:

-erase internal drive

- clone backup of original state of mini back to mini -- this puts the computer in the same state as when I started so I can test a different method. at this point client doesnt work on subnet B.

 

- clone working OS (and client) on top of system from above. This *should* place a working OS and client on the internal drive. It does place a work OS on the drive, but the client still fails on subnet B.

- remove retrospect client (see above method)

- reinstall retro client - no joy... the client still fails on subnet B.

 

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

 

at least I have a means for correcting the problem on the other clients where there is this same problem... only it is very time consuming...

 

Thanks for reading this far

 

if you have any ideas as to why bringing over the applications directory would cause retrospect client to fail - especially when there is NO retrospect client application being migrated......

 

or ideas which would shorten the time required to get retrospect client working on other computers with this ame problem -

 

Im happy to hear them

btw - happy T-day, as I won t be at work tomorrow

[Maser]

When the client on subnet B is showing -519

 

What does the client software say when you run it? "On"? "Ready"? Does it have a "name" associated with it?

 

 

Also, what DVD OS version are you using to do the migration?

 

(I honestly can't think of why you could take two identical computers that *work* in different subnets, run the same migration assistant steps on both of them, but have a piece of software work on one network, but not the other network -- unless there's some other piece of software doing something wrong...)

 

 

Since you have a working system that you appear to be able to clone everywhere correctly, is there any reason you can't just clone your client machines using that and just reset up the user accounts on the "new" systems and copy/"chown" the user files into the user accounts accordingly?

 

Or do you have to migrate "custom applications" that are unique to each machine?

[Camelhump]

 

Final solution :

clone (using CCC) existing client that wont connect (-519).

Install new OS

use migration assistant to move everything but setting back

install retro client

 

1.5 - 4 hours/machine