Archive for October, 2009

Symphony Removed During Upgrade to Ubuntu 9.10 “Karmic Koala”

Friday, October 30th, 2009

As Mark Myers mentioned, the on-line upgrade to Ubuntu 9.10 “Karmic Koala” is nice and neat, if a bit slow. I did however notice that during this automated upgrade, Lotus Symphony 1.3 which I had originally installed via the Ubuntu 9.04 partner repositories, was explicitly removed 🙁

I’m sure that this will be fixed in due course by IBM/Canonical, but in the meantime, if you need Symphony then you’ll have to manually download it and install it outside of the repository . . .

SnTT: In Situ Domino Server Rename

Thursday, October 1st, 2009

One of the benefits of Domino server upgrades, when compared to some other emails systems, is the ease with which it is possible to perform upgrades in situ, without having to migrate to new hardware.

So with this in mind, it came as somewhat of a surprise to discover that when renaming an existing Domino server, Lotus actually advise that “The easiest way is to create a new server and move all users, databases, and needed functions to the new server using the AdminP task”.

Whilst I agreed that this approach is certainly appropriate if you are renaming a mail, or other user facing server (in order to maintain service availability), however if you need to rename a hub, or other non-user facing server, there is absolutely no reason why not to perform a very simple in situ upgrade as detailed below:-

1. Register the new Domino server name in the normal way

2. Add the new Domino server name to DNS (I assume the OS host name will remain the same)

3. Review and update the new Server Document, comparing it with the original server. This should include (but is not limited to):
– Directory Assistance
– Directory Catalog
– Transaction Logging

4. Create a new Server Configuration Settings Document for the new server, and copy across any necessary settings from the original server’s Configurations Settings Document

5. Review events4.nsf and create new probes and monitors for the new server as required, based on those configured against the original server

6. Review all mail routing and replication Connection Documents for the original server and create equivalent documents for the new server (as appropriate)

7. Review Program Documents for the original server and create equivalent documents for the new server (as appropriate)

8. Add the new server name to any relevant ACL groups in the Domino Directory

9. Add the new server name to the relevant DDM collection hierarchy (if appropriate)

10. Take a local (i.e. to your workstation) non-replica copy of catalog.nsf (for future reference)

11. Immediately prior to starting the actual rename process on the original server:
– Force AdminP to process any pending requests using tell adminp process new
– Force routing of any pending emails, ensure that there is no undelivered mail in any mail.box
– Force a database cache flush using dbcache flush

12. Shutdown Domino in the normal way

13. Take backup copies (outside of the Domino Data folder) of the following files:
– notes.ini
– server ID file
– log.nsf
– catalog.nsf
– busytime.nsf, or clubusy.nsf (as appropriate)
– all mail.box(es)

14. Delete the following files:
– original server ID file
– log.nsf
– catalog.nsf
– busytime.nsf, or clubusy.nsf (as appropriate)
– all mail.box(es)

15. Copy the new server ID file to the existing server

16. Edit notes.ini as follows:
– Replace any instances of the original server name with the new one name. Typically for the settings: mailserver and servername
– Edit the serverkeyfilename setting to reflect the file name of the new server ID file

17. Start the newly renamed server, ensuring that it recognises it’s new name and check the console and log file for any unexpected errors

18. Verify that you can access the new server from a Notes Client, and a web browser (if appropriate) using it’s new Domino and DNS name

19. Update the ACLs and Administration Server Database property of all server specific databases on the server, to reflect the new server name (making use of the previously saved catalog.nsf to help identify appropriate databases)

20. Review the directory assistance database (if applicable) and update any instances of the original name with the new one

21. Review any application databases and update the ‘run on server’ agent settings to reflect the new server name (if appropriate)

22. Decommission the original server from the Domino Directory (and of course DNS) in the normal way

Please let me know if you think I’ve missed anything, or if you have any suggestions on how to improve this process.

Enjoy!