When you first start planning an Intralink upgrade, you’re struck by just how much work is involved. The file server, data server and client machines all need to be updated. All your Intralink users and the precious data on your servers will be affected by the change. Things will go much more smoothly if you thouroughly prepare your plan of action.
In this article I’ll mention examples from a couple of typical upgrades: Intralink 2.0-3.0 (upgrade with patches) and Intralink 3.0-3.2 (involving migration). Intralink 3.2-3.3 is a much simpler operation, where you can rely on the PTC CD to do most of the work. Always remember to backup the server, and get a dump file before you proceed.
The principles apply to any operating system, but my examples particularly relate to Windows.
Because of how Intralink is set up, it’s possible to have multiple versions of the client software installed side by side. This makes it easy for you to copy out all the files you need. Get the files ready on all active clients before you upgrade the server. Then it will be a quick switch-over when the server is restarted.
With some clever planning you can trigger a few steps the next time a user tries to start Intralink:
1) Register the new Intralink client (run PTC.setup automatically with a trail file and no display)
2) Swap the startup scripts (substitute a new script that kicks off your new Intralink version)
3) Call this script to start the new client
Find out more: Automate PTC.Setup | Startup scripts
Also see this article on Pro/Files magazine: Reducing the Administrator’s Workload
Ensure you have a backup copy of your meta-data (the information held in the Oracle database and viewed in the commonspace browser). On the day of the upgrade, do this after all users have logged out of Intralink.
| A few lines to set the database to Read Only mode.
(Change the RO to RW to set Read/Write mode.)
PDMTransactionSetRO INTRALINK INTRALINK
Two more lines to produce a “dump file” of your data server.
ilink_export manager d:ptcbackupdump.dmp
You can run a database export from the command prompt. You should really run this kind of backup every night, so you can recover the whole database in case of emergency.
I would advise scheduling daily scripts that carry out these steps to create a “hot” backup:
- copy the old dump file to a secure location (store a few days worth of dump files)
- set the server to Read Only mode
- create a dump file of the current database
- set the server back to Read/Write mode
You can also create the backup using a graphical interface via the DSMU (Data Server Management Utility, also known as proimgr.bat – see section below).
Several sources also advise you to have a “cold” backup available (so-called because the server is not running during backup). This involves copying .ctl & .dbf files from the %PROI_HOME%dbs folder to enable you to restore the database later. I’ve always a hot backup sufficient but a cold backup may be a good safety net, should you ever need it.
Even if you don’t make a cold backup, it’s a good idea to take note of the .dbf file sizes. These files are the database tables that Intralink uses to store information. If you’re doing an upgrade involving a straight import of a dump file, you’ll need to resize the tables. You can use the existing .dbf file sizes as a guide.
In some cases this backup is all you need for the upgrade. However, if you’re following a migration path, you will need to perform a few extra steps.
Migration – Stage 1
| Set a couple of environment variables:
set PROI_SYS_PWD dschangeme
set ORA_SYS_PWD manager
Get the current database info & export the database
(substitute the location of the upgrade CD & migrate folder):
getdbinfo migration d:ptcmigrate
ds_export migration d:ptcmigrate
The Intralink CD will have a Migration folder with scripts that enable you to migrate previous versions of the database to the new level. When upgrading from a CD, I often find it useful to copy the entire contents of the CD to a folder on the server, so you can run PTC.setup and migration programs direct from disk. This is particularly useful if you work on the server remotely. In the examples, set the <upgrade_disk> to the correct folder.
The migration scripts create a folder (d:ptcmigrate in the example) that holds enough information about the database to rebuild it. This folder includes details of the database objects and a dump file that will be used later in the upgrade process.
Also see this PTC suggested migration technique
Remove old servers
After making a secure backup of the data, the next step is to remove all traces of the old servers. Simply using the (Windows) Add/Remove Programs utility will be sufficient for the file server, but for some versions of the dataserver you may need to use harsher tactics.
After using Add/Remove, open the registry (Programs | Run | regedit) & browse to:
Delete the keys for OracleServiceilnk & OracleTNSListenerL816
Reboot the machine and check there’s no mention of the dataserver (also remove the dataserver folder).
Install File Server
The file server is usually pretty straightforward, but there’s one thing to note:
Before you start the Fileserver service, enter the startup parameter 7777 (this is the port number). If you don’t enter a startup parameter you’ll get an error message.
Install Data Server
The data server is a major part of Intralink, so it’s important to get this step right. Run PTC.setup from the Intralink CD to install the data server. Usually it’s simply a case of working through the choices, accepting default values where appropriate.
| During a migration you need one change: On the Components screen pick Configuration options and deselect Run Intralink Configuration
Import Dump File
|Two lines to import the dump file:
ilink_import manager d:ptcbackupdump.dmp
A few variables and commands to run patches (for 2.0-3.0):
ilink_patches oracle ilnk
ilink_patches SCHEMA English INTRALINK
ilink_patches VALIDATION English INTRALINK
If you are preparing to manually import a dump file (eg: upgrade 2.0-3.0) – you need to resize the new database tables so they will accept the import. Log on to the DSMU (see section below) to resize the Tablespaces, using the original .dbf file sizes as a guide.
When you import a dump file after an upgrade (or recovering from a server crash!), use the command prompt to run the import script, adding your dump file location (d:ptcbackupdump.dmp in this case).
Each specific upgrade may need some patches or other tweaks. In the case of 2.0-3.0, a few patches need to be manually applied (see box). In other upgrades, patches and healing scripts may be built into the migration process. These ensure the integrity of the database as it goes forward to a new version.
Migration – Stage 2
|Retrieve the migration data & rebuild database:
ds_migration ilnk INTRALINK d:ptcmigrate
This is the migration step where you re-create the database. Ensure you run PTC.Setup without the “Run Intralink Configuration” option checked.
Use the ds_migration script (see box) to read back the data stored previously in the migrate folder. This will also import the dump file and trigger a series of healing scripts. Monitor the migration script – check for any error messages, warnings, etc…
Working with the DSMU
Run the DSMU by typing proimgr at the command prompt. These are the default combinations for login:
- Dataserver: system / manager
- Administrator: INTRALINK / INTRALINK
The DSMU helps you manage the server, including: checking space, resizing, backups, set mode, etc…
You can resize the database as a whole, or by individual tablespaces. These correspond to the .dbf files in the %PROI_HOME%dbs folder. You should ensure these are large enough for daily running (with sufficient space for expansion). They should also be sized correctly to accept an incoming dump file during upgrades.
Note: You can also use the DSMU to configure file servers and vaults. It allows you to register them for use with the dataserver, or move vaults between different servers.
At the end of all your upgrading, be sure to test the server before letting it loose on your users! Try some Check-outs and Locates, to make sure things are working. Remember to set the server mode back to Read/Write (check the status using the DSMU).