However, anything beyond 2GB becomes very difficult to manage and here’s why.
1. Databases become corrupt very often.
2. Running Fixup or Compact on a weekly basis as part of Domino routine maintenance becomes problematic because the server is always running the maintenance on the databases. In fact, you’ll need to split up fixup and compact to run on specific directories during different evenings of the weeks. You may even want to run Updall on different directories different nights of the week.
3. Backups take forever and may not finish before the beginning of your work day.
4. Opening the mailboxes takes a very long time because it has to index the inbox every time you open it (if the user does not file messages to folders, which most don’t).
5. You pretty much can’t have full text indexing turned on for the server copies of the database because the full text indexing will be continuous around the clock on your server, not to mention more disk space required on server.
6. We’ve had some very strange things happen with Blackberry Enterprise Server accessing very large mailboxes. Specifically, We have had instances where a Domino server running Blackberry Enterprise Server (BES) can have frequent outages in IDTable code when working with large ID tables, which causes the server to crash. See technote titled “BES server crash in IDTable code”

7. If users have local replicas of their mailboxes, sometimes their hard drive is not large enough, sometimes the local replica becomes corrupt on the hard drive because no maintenance (fixup/compact) is ever run on it.
8. Creating new replicas onto new servers can take a week across the wire.

The list goes on.

These are real world examples of issues that I come up against every week. The best practice is to have quota policies in place that the upper management supports.

The second major thing to note here is that a proper archiving solution needs to be implemented. The local archiving that is built into Notes is often times not sufficient if you have so many enourmous mail files.

Keith Brooks commented in the last post that the ability to see the templates and ODS has been available in the Administration client since 6.5, plus the ability to modify the Administration Server (not see it). This is all true, but I still find the tool very useful for cleaning up ACL and administration server inconsistencies.

Here’s my review:

Super Admin has some helpful features. Many of the features, such as the ability to see what template a database is using or tell what ODS version a database is easily viewable in the Notes admin client.

It does take a while to run on the server and a while to get all of the report views updated properly.

As the installation instruction says, it does require your signor ID that you’ve signed the database with to be a full admin, even if the signor ID is a server administrator and a manager of all database. It didn’t seem to work properly until I added the ID file that I signed it with to the full administrator field in the server document.

The Orphaned databases view was very helpful. It found a mailbox that no longer had a person document which is one of the main reasons that I want to use the tool.

The All Databases section contains the template, ODS, and quota information which is currently already visible using the administration client. So it’s not really an improvement, unless you want to put a replica of this tool on all of your databases and be able to see the template, ODS, and disk space/quota information all in one place.

ACL Anomolies Section:
Administration Server View:
There is a categorization for “No administration server Set in ACL” which is very helpful.

However, I found at least one database that did have the administration server set, but the tool reported that it didn’t.

The “Administration Server Does Not Match Database Server” categorization isn’t very helpful because it provides false positives on cluster mate servers or hubs.

LocalDomainAdmins View:
The “LocalDomainAdmins Missing From ACL” categorization was very helpful, but would be better if this was further categorized by directory. It would make it easier to delineate root directory/system databases from mailboxes. Our mailboxes don’t have LocalDomainAdmins in the ACL.

The “LocalDomainAdmins Does Not Have Manager Access” categorization was also very helpful.

LocalDomainServers – View
There were 3 categorizations that were really helpful including:
LocaldomainServer Missing From ACL
LocalDomainServer Does Not Have Manager Access
LocalDomainServer Not Set to “Server Group”

I don’t use OtherDomainServers so I didn’t really need the OtherDomainServers view. However, I did find a couple of false positives reported that OtherDomainServers was not set as server group in when it actually was. Incidentally, these were also two databases that actually had LocalDomainServers missing from the ACL. Once, I added LocalDomainServers to the ACL, they disappeared from the OtherDomainServers Not Set To “Server Group” view.

It would be beneficial if there was a LocalDomainAdmins not set as person group categorization. Maybe there is that categorization, but I simply didn’t have any databases that matched the criteria.

It would also be great if we could define a group other than LocalDomainAdmins or LocalDomainServers to check whether the database had the group and whether it was a group type that we could specify (such as person group). Many organizations use a group other than LocalDomainAdmins or LocalDomainServers to manage their Domino infrastructure.

Once I made corrections in the ACLs of a couple of database, I found that the updates to what Super Admin was reporting happened within a few minutes.

I looked at the agent properties, and it appears that it runs every hour. It starts running as soon as you put the database on the server. I couldn’t see how you could run this locally and found no way to manually initiate the agent. So it appears that this must run on a server.

Well, today, I received yet another great tip from him. He pointed me to an OpenNTF project called SuperAdmin by project chef Declan Lynch

Here’s the synopsis:

Have you ever wondered if you have dead mailfiles sitting on your server taking up space, or if the all your databases are on the latest ODS version, or if the administration server in the ACL is set correctly on all databases, if so then this is the app for you.

Written by a notes admin for notes admins all the information that you need to make sure your Domino environment is running like a well oiled machine will be waiting for you once you deploy SuperAdmin.

I’ll setup it up and review it in a subsequent post.

I’ve got a bunch of mailboxes that did not already have LZ1 compression enabled (mostly archive mailboxes and a few mailboxes scattered around on remote servers). Mostly, it’s been turned on, and it’s definitely turned on in all of our mail.boxes.

The only reason that it is not turned on for all mailboxes up to this point is that we had to disabled it in our OpenNTF1.7b template because we have a couple of Mac OSX users. When design would run on the server at 1AM every night, the LZ1 property would be turned on for these 2 Mac users even though, we had manually turned it off. It was weird since, technote 1176010 entitled “Which Database properties are affected by a Design Replace or Refresh” clearly indicates that LZ1 compression is only affected by design replace and not design refresh.

These Mac OSX users would have problems with their attachments. There used to be technote number 1193756 on the issue, but it’s gone now. IBM must have fixed the issue and removed the technote.

I’ve enabled LZ1 compression for all databases now with the admin client (advanced properties).

Now, I’ve set the DEBUG_ENABLE_LZ1_REPAIR=1 in our * Configuration document so that it gets written to the notes.ini of all of our servers.

Next, I’m testing running load compact -ZU on a few databases to see how much disk space we could save.

Compact -ZU upgrades the compression of existing attachments in a database from Huffman to LZ1.
compact -ZD downgrades that compression from LZ1 to Huffman.
Setting the Enable LZ1 compression database property only compresses attachments from that point forward.
See the technote 1084388 entitled “Switches for COMPACT server task for Domino”

Initial tests show that I could save anywhere from 85% to 95% of disk space and that it takes about 3 minutes per GB to run the compact -ZU.

I’m also showing that I need to run compact a second time withouth any switches because compact -ZU may upgrade the attachment compressed with Huffman to LZ1, but it actually makes the database size bigger than before I started.

This prompted me to wonder. Does the compression replicate? or do I have to do this for every database on every server?

Anybody know the answer?