Whenever a medium to large sized domino environment decide to ugprade, its usually up to the upgrade project to make sense of the existing environment. The "Last to touch" rule also means that its usually the project thats then "responsible" for any sins uncovered during the project.
On countless (okay, I could probably count them. Lets say the last 10 ?) projects that I've been on involving moving users or applications between servers, we usually find out pretty quickly that:
- Some previously deleted users still have "orphan" mailfiles and cluster mailfiles
- Some previously deleted users may NOT have mail files but still have person documents
- Some old folks out there have mailfiles on multiple old servers, where they have moved between sites. The old mailfile hasnt been replicated to in some time and we definately dont want it (due to deletion stub expiry) to repllicate with his current mail file
- Most users (it should be "all" in a perfect world) have their mailfiles replicated to the new set of servers. Usually, there might be some ACL problems that prevent replication.
- Most users have various different ages of client and template.
- Usually there's a client upgrade project going on at the same time, but not connected to - and cant disturb - the server mailfile move project.
On a small environment, this may take a day or so to work out. On a medium to large environment, this may take several weeks if not months. And - since the project is usually fixed price/fixed deadline (a classic "Death March Project" in other words), there's no resource to fix these issues. And since operational staff are running at full capacity (having to manage TWO environments) they cant do it either.
There's a number of alternatives. One is to cry. Its tempting, but its not really constructive. So what I do (after a good bubble in the toilets) is to construct Bill's All Purpose Mailfile Consolidation Tool. Various forms of this have been constructed over the years, and I'm sure on your current site, you might have a copy, or someones plagarised/butchered copy of it.
So what does it do ?
- It builds an in-memory list (using lists and classes) of all person documents in all domains, noting their name, domain, mailserver and mailfile. We can ignore those person obects that dont use Notes for their mail. A variation on this theme is to include all mail-in database documents too.
- It uses the NotesDbDirectory class to build up a list (again, using - you guessed it - lists and classes) of all databases in target servers, in target directories. Most of the time, the mailfiles are kept to "/mail", but I've seen instances where they're literally all over the directory structure. Take a note (without "opening" the database) of server, filepath, replica ID and title. Read these entries into various lists, including a list by "Server!!Path" and a replicaID list.
- Now "Zipper" these two lists together. The person document contains the mailfile server and mailfile reference right ? (Sometimes you might have to add ".nsf" to the person document version of the mail file name). If you find one (and thats not guaranteed, right?), then use that databases replica ID to find other databases with the same replica ID.
- Associate all those mailfiles with a particular user and mark those mailfiles as "used" in some manner.
- Spew out a report of all people objects, showing each mailfile replica for each person. At this stage, its quite easy to establish if they have a mailfile on the new servers, their mailfile name is correctly named, etc. <./li>
- And spew out a list of all application databases, noting the "status" of each.
Phew. Sounds difficult, but by the 10th or so time you do this, believe me it gets easier. I managed to do it in under 500 lines of lotusscript (and that includes "pretty" output!) and a run-time for a 5k user environment of under two minutes. (Guess you should start to believe me that lists and classes are cool, huh ?)
Now you can construct views of people in your database that have not enough replicas of mailfiles, too many replicas of mailfiles, more than one replica mailfile on a server, etc, etc. And construct views of mailfiles in use, and not in use. All of a sudden, the disk space that might have been tight on both the old environment and the new environment is now plentiful, as you may have identified lots (thousands?) of "orphan" mailfiles, and of course you now have a list of documents showing where people NEED new replicas. And of course, its simple enough to write 10-line agents that perform replica creation, etc. It might tie up a workstation for a day or two (my record is two workstations for THREE months, pulling 10 TERRABYTES of information across the network, and only being allowed to use a 10m/b ethernet link.)
Not bad for a few hours work, eh ?
(No - not posting this code, as its usually highly tailored to particular customers, and usuallly quite difficult to use. If you want this capabilty, then either rent me, or buy FirM. We might consider putting this functionality in there too.!)