One of my customers wanted to migrate the HCL Traveler Database from IBM DB2 to Microsoft SQL. The customer is using Microsoft SQL for all other applications, which is set up with redundancy and high availability in mind, so this was a sensible choice, opposed to running a single instance of DB2.
EDIT: A migration of the Traveler data, inside the enterprise database, is currently not supported, and I do not know of anyone who has done it successfully. Nevertheless, the move towards another enterprise database was desired by the customer as long as there was no action needed on behalf of the users (entering their credentials again for example), this means that the ActiveSync devices will need to resynchronize their data after the move.
EDIT: There are also no tools to migrate the HCL Traveler data from one enterprise database to another. Although the database is not so complicated, and it may be possible to write your own tool for “low-level” SQL Data migration towards another enterprise database (this is just a thought of mine and I have not tried this out). We decided to continue with a simple move towards another enterprise database, meaning that the end user devices will have to “re-sync” most of their data again, this could be an issue in a larger environment, so when in doubt start with a PoC environment and plan accordingly.
First thing to do is to create a new SQL Database and open up the needed Firewall ports to access it. In our case it was the port 1433, but you may need to check your database server settings, as this may differ depending on the configuration and/or technology used. After that you should create a new service user solely for the traveler connection, this user should have appropriate rights to the database/instance. Consult the official documentation for the appropriate SQL Server permissions.
Before proceeding with the next steps, make sure to test the connection to the SQL Database, using the service user you created earlier. I usually to this using a “UDL” file, as described in the separate post.
After the database is created and the connection is tested, I strongly advise configuring at least two test devices, using the same settings and the same application as the majority of the users are using at the customer site. This is useful during the migration, as you can see the impact on the users during the process and verify that everything is running smoothly.
One important thing to keep in mind is that all the settings in “LotusTraveler.nsf” Database (HCL Traveler Administration Database, accessed only via HTTP/HTTPS) will be lost after migrating to the new Database. This is not a big deal, as there are only a handful of settings involved, take note of them before moving to the new database and do not forget to apply them once you have moved to the new enterprise database.
Before configuring HCL Traveler to use the new database on MS SQL, you will need to download the appropriate JDBC driver for the MS SQL. Just download them using the URL in the official documentation, and you are good to go. After downloading the driver package, shutdown the Traveler Servers, extract and copy the JDBC driver to the “<Domino_Program_Directory>\Traveler\lib\” directory. Make sure to delete the DB2 JDBC drivers which are not needed anymore, I have not done this at first, and it caused a problem with the connection to the new database.
At this point, the devices using HCL Traveler will not be able to sync, due to the Traveler servers being offline. Now you can reconfigure the Database connection on the Traveler servers. Just run the “travelerUtil” tool, using the command appropriate for your environment, as described in the official article. There is no need to run the “db remove” command, just make sure to check the database related settings in the “notes.ini” after running the “travelerUtil” tool, these need to be correct prior to the start of the HCL Traveler Server.
After running the command, run the “travelerUtil db show” and “travelerUtil db check” command and verify the settings. This is a very important to be done before starting the HCL Traveler Domino task.
Before starting the HCL Traveler server for the first time, I would start only the HCL Domino Server without starting the Traveler server task and start it manually afterwards, just so we could make sure that we see all Traveler related messages on the console. You can do this by removing the Traveler task from the list of tasks in the “notes.ini” (“ServerTask” parameter).
After starting the Traveler server for the first time, do not forget to set the settings in the “LotusTraveler.nsf” which you noted previously. This should be done only while the HCL Traveler Server (Traveler task) is running, only then will the changes be written in the new enterprise database.
As soon as the Traveler server is started, all user devices will start with the full re-sync, at this customer site we needed about 1 hour for about 150 Devices. The performance varies from environment to environment. Important to note is that we have done this during the weekend, and we did not get any user complaints nor the users had to enter their credentials again.
A word of warning, before making any configuration changes, make sure that you have created a consistent backup. While doing this procedure, the most important thing is testing along the way, as every change will have immediate user impact. Also make sure to consult the official documentation and check if all the requirements for the HCL Traveler are fulfilled. I especially advise you to read the section about the HCL Traveler High Availability Pool. It is also very important to be running the latest version of the HCL Traveler Servers, as I am sure that with some older versions of Traveler, this process is not so smooth and the initial Sync of the devices using ActiveSync will take a longer time to complete. In this environment, devices do not need to be “approved” by the administrator to connect to the HCL Traveler Servers via ActiveSync, if that is the case in your environment, you should test the impact of this feature in a PoC environment before moving towards a different database in your production environment.
Many thanks to Detlev Poettgen for explaining this procedure to me, make sure to keep an eye to his blog, as his posts are very helpful! Also, big thumbs up for the very helpful HCL Support team.
Let me know if you would like me to cover any part of this procedure in greater detail or if you would like to see this as a Session at a conference!
Thoughts about HCL Connections, Domino and Sametime 