Continued from Page 1, here

Cause 4a. Different TCP/IP subnets.

You need to ensure that the server machine and client machine are both on the same subnets. Briefly, they should all have the first 3 sets of numbers as the same, so if the Retrospect server's IP number is 192.168.1.10, the client should be on the same subnet: 192.168.1.xxx, xxx being any number between 1 and 254.

If the client is 10.20.10.xxx or 169.169.1.xxx, (for example) you are not going to get the two Retrospect machines talking and you need to change one or both machines so they are the same defined subnet.

If you do not have a network setup, then define the Retrospect server as 192.168.1.1 and define the client as 192.168.1.2, as this subnet is allowed for individual usage on the internet and you remove any chance of getting some massive corporate screaming at you to get off THEIR IP numbers which they have paid lots of money for.

Cause 4b. Different TCP/IP subnets, corporate scenario.

If you are in an organisation which has a superscope DHCP server spanning multiple TCP/IP subnets, then you probably have routers, switches etc to redirect the TCP/IP traffic. These routers may/may not pass on the PITON traffic that Retrospect generates, so try bringing the two Retrospect machines onto the same subnet and see if the problem disappears.

If it does, the likely problem is the routers/switches.

To test this, you need to make a router which you know passes all the traffic. To do this, turn an old PC into a router. It is required to be a minimum of Windows NT, W2K or XP. Put 2 ethernet cards into it. Put one ethernet card on the one network (192.168.1.100 for example) and the second card on the second network (192.168.2.100, for example) and route all the traffic over the two cards. Change the default gateway on both Retrospect server and client to be the PC (192.168.1.100 or 192.168.2.100) and try backing up the client again. First check you can successfully ping the client from the server, making sure the TCP/IP traffic is not going via other routers/switches. If Retrospect works, you have proved it to be the switch which is stopping the Retrospect traffic and can talk to the manufacturer about any options available, or find some means of sending the Retrospect traffic via your homemade router.

This problem is beyond what I have room for on these pages, so I am avoiding too much more on this one

Cause 5. Incorrect order of accessing network.

This applies if you have multiple networks (infra-red, bluetooth, wireless, multiple ethernet cards etc)

You may find that Retrospect is unable to find the client as it is searching the wrong network first. To adjust this (XP only), do the following:

Open Settings, Control panels, Network Connections:

Click the Advanced Menu next to the Tools menu.

Click on Advanced Settings (below Bridge Connections)

This is mine, with 3 alternatives, but yours will be different. Select the Local Area Network (and this assumes you are connecting to the client via the Local area Network. If you are connecting via Wireless, then select the Wireless Network Connection). In this case, the local network is searched second

Click the button on the right pointing upwards, and click it as many times are required to get your network which Retrospect uses to the top of the list, at which point the green down arrow becomes active:

Click OK.

Try running the Retrospect backup again.