Summary,
Original problem:
We created a snapshot of our production virtual Intralink 3.4 server named ILINK1 and called the snapshot ILINK2. We started ILINK2 to see if it worked - it did - and shut it down.
Now many clients get a "ILINK2 Dataserver not started" error when trying to log in. The clients should not know ILINK2 exists and the tnsnames.ora file points to ILINK1.
Why are they trying to connect to ILINK2? Any suggestions?
Resolution
PTC helped us figure this out (even though a virtual system is not supported)..
Apparently, we caused this problem a long time ago when we migrated from 3.3 to 3.4 or perhaps it was 3.2 to 3.3.
Once upon a time we had file vaults on servers named ILINK1 and ILINK2. At some point we decided to move the vault on ILINK2 back to ILINK1. We thought we had completed the process because everything worked when ILINK2 was shut down. We did not remember any of this until PTC helped figure it out.
Yesterday, when a new server was created – cloned from ILINK1 in VMware and named ILINK2 – and tested and left running, the old forgotten fileserver links between ILINK1 and ILINK2 were awakened.
The first symptoms of the problem were random failures checking out with “file not found” errors. During the day some files that were checked in had ended up in the vault on ILINK2, some clients could find the files and others could not.
As soon as we noticed that it was looking for files on ILINK2, we shut down ILINK2 not knowing how the clients or ILINK1 could possibly know that ILINK2 existed. Now no one could log into the client because the server on ILINK2 was not running.
We thought we had fixed the problem by running a script that PTC provided to edit the file vault and fileserver information manually. Now the links only point to ILINK1 and everyone could log in.
However, there were files missing from the vault on ILINK1. We found the files on ILINK2 and moved them back to where they belonged. After deleting a workspace where I had checked out files as “link” instead of “local copy” and the links were still pointing to ILINK2, everything works.
I am posting this somewhat embarrassing summary in hopes that if anyone ever experiences this type of problem, they might be able to resolve it a little quicker than we did. Or even better, avoid the problem altogether by making sure ALL the vault and fileserver information is correct when moving vaults.
