Tag: Migration Project

Mail Migration Project : iDiscovery Application Part 2

So, I was talking about the ‘iDiscovery’ application I developed in order to aide with database discovery, usage and also migration.

Continuing from Part 1 – using this categorised list of databases I had, I was able to delete a large number based on whether they had usage logged against them, and whether they had secondary replicas.  Quite often I found that when users’ moved from one location to another, the ‘Move Database’ AdminP function didn’t actually remove the old replica, so this stayed dormant in most cases.

In our environment we use IIS sitting on top of the Domino HTTP stack along with the Websphere Application Server Plugin to provide single sign on with Active Directory.  This means that in every person document there needs to be the AD username listed as the last item in the ‘Fullname’ field.  Another good way for us to find stale users was to modify the iDiscovery application so it not only trawled the domino servers for NSFs, but also, to look up the database in the NAB to see if there was a matching person document.

To do this I had to modify the names.nsf and add a custom view.  This isn’t something I do lightly as I am aware of the impact of doing such activities (performance, stability etc) but there was no other way to achieve what I was trying to do so I added a new view which had a first sorted column of a concatenation of MailServer and MailFile fields.  I then used this view in the ‘discovery’ agent to lookup databases against.  This function produced an amazing number of databases that should have been deleted by AdminP when the user was removed, but didn’t.

We used the same code to check for orphan mail archives and also found a lot of large databases that could be removed

So with these things in place we’ve deleted hundreds of databases and have already saved over 2TB of storage AND reduced the number of databases we need to migrate which was great.

Next things I’ll talk about:

  1. How we sync’d the Local Address Books for each user with the mail database in order for the migration suite to migrate them to Outlook Contacts.
  2. How we produced a list of each ‘Mail Distribution’ group and internet addresses of each member (trying to exclude groups used to provide access to notes databases, admin/system groups etc)
  3. How we produced a list of each generic mailbox (i.e. sales@companyname.com) and who had access to them.

Mail Migration Project : iDiscovery Application Part 1

So….in preparation for mail migration, we needed to catalog our entire Domino estate as when the mail migration project was completed, the next task would be to move away from the Lotus Notes Client.

We really had no idea how many databases were in use or even how many we had.  I looked into some third party apps – namely a Cooperteam application which scanned through servers, collecting data on the databases and produced some good reports as to the complexity of the applications and type/category of applications etc.  It was a top product and we would have gone down that route had it not been for our budget, which was near to nothing.

So I thought I’d develop our own, and it was a good job in the end as the app ended up being customised quite heavily to accomplish a number of other requirements.

Cataloguing

The iDiscovery app had an agent which ran every morning in the early hours and catalogued the server, it would check if the database had been logged before, and if so, it would just update the bits that may change (size, usage info, document count, etc).  If it was a new database it would log all the details required and also create an alert.  The agent automatically categorises the databases based on location, and/or template name.

I had this iDiscovery database replicated to each of our servers and set up replication settings so only the hub server was set to hold data for all servers.  This was then used for reporting etc.

From this data, we then knew how many apps were using ‘out of the box’ templates, how many were custom applications and based on the number of design elements etc, a complexity rating (albeit crude).  We found a number of users had replicas of their mailbox in multiple locations so I then added a lookup to a custom view in the NAB to allow the app to determine which is the ‘Primary Replica’.

 

 

 

Mail Migration Project

We began a mail migration project from Lotus Notes to Microsoft Outlook in May 2012. It was a bit of a mission as the company have had Lotus Notes for around 15 years, and Lotus Notes & Domino does have a habit of entangling itself into businesses due to the worklow and collaboration capabilities.

The planning phase took a few months and I ended up creating a bespoke discovery application that would facilitate a smooth transition from Domino to Exchange. I will blog more about this application in coming posts as I think the tasks it accomplished will be common to other Lotus Domino migration projects.

We have domino servers in Europe and APAC with multiple mail servers in all regions. Once we understood the number and size of mailboxes, it soon became clear that the migration process would be impossible with the migration tools that were installed on servers in the Exchange datacenter in the US.  The WAN link between the migration tools and the domino servers in some cases just would not facilitate the load.  To get us over this, we did two things:

  1. Implemented a strict 30 day archiving policy in order to reduce the file size of some of the mailboxes.
  2. Created replicas of the mailboxes to be migrated on a new domino server that we built alongside the exchange servers and migration suite.

The 30 day archiving was done using the built in policy based server archiving in Lotus Domino.  It was pretty straight forward although I found a few ‘gotchas’ along the way, may well blog about these later too.

The creation of replicas wasn’t as easy as it sounded due to the sheer volume of data and the disk space available, although the saviour here was LZ1 Compression, DAOS and De-Duplication.

Until the next time…