Welcome to

In my last post I discussed options to handle the inevitable situation of out of control mail database growth from the perspective of the administrator. Four options were given with brief pros and cons, as well as my thoughts on their implementation costs and long-term sustainability. As I was writing the post I quickly realized there was far too much to say on each option and found myself summarizing. Not only did I summarize the discussion on the different options, but I summarized the number of options covered. Due to this I feel that too many questions may be left unanswered. To fill this void I will begin a series of posts on mail database size management were I will cover different options available to fight the ever increasing email bloat that Domino shops of all size face today.

What I hope that you will take away from this is a better understanding of how to manage mail database size and the different options available to you, their strengths and weaknesses, their costs, and their impact on the user community and your environment.

While I do not want to limit myself in future posts on this topic, I do feel that it is important to compare each option in a similar fashion. Therefore, each post will follow similar guidelines in that I will list the pros and cons, implementation cost, and long-term sustainability of each option.

When discussing these type of topics all too often they are only looked at from the administrator or IT’s point of view. How much money does it cost? Is it easy to implement? How much time will it take to configure? Will this require an outage? And all too rarely we forget to discuss the impact as experienced by the end-user. I will do my best to cover the end-user perspective as well because managing email database size will directly affect your user community in some form or fashion.

Implementation cost will be rated from both the admin and end-user perspective. For the admin, I will consider monetary cost, ease of implementation (includes planning), ease of configuration, and outage requirements. Each point will be rated individually along with an explanation of how I came to this conclusion. For the end-user, cost will be rated based on how much time the user will need to spend doing their part initially, if any at all. Because there are so many points being considered I will try to keep the scale simple and rate all cost points from low to high. Keep in mind that what I see as a high cost some organizations may consider it moderate, so do your own cost analysis rather than assume my cost rating is somehow inline with your organizations fiscal standing. Disclaimer aside, I will be basing my opinion of cost on my almost twenty years of experience working in IT with customers ranging from SMB to enterprise and user communities of all knowledge levels.

As with cost, long-term sustainability will also be biased to my experiences with all levels of Domino administrators as well as end-users. I will not be assuming that just because a task is simple equates it to sustainable over a long period of time. Any task, no matter its degree of difficulty, can not be sustained over a long period of time if it requires constant attention and modification. Therefore, sustainability for the admin will consist of these factors: additional workload, scalability, and on-going monetary cost of the solution. For the end-user I will also consider additional workload.

The next four parts of this series will cover adding additional disk drives, archiving email off to another server, using quotas, and data retention policies. If you have a favorite (or not so favorite) method you use to manage your Domino environment’s email database size let me know and we’ll discuss it.