Lotus Software, Domino, Sametime and the life of a freelancing IT Consultant - And now the home of the CT chapter of the Grand Order of GONAD

 
alt

Victor Toal

 













Blogs I really like:

11TMR
Planet Lotus
vowe dot net
Alan Leposfsky
Andy Yiu
Andy's Blog
Bruce Elgort
Carl Tyler
Domi-No-Yes-Maybe
Domino Blog
Ed Brill
eknori.de
Francie Whitlock
Chris Miller / IdoNotes
Jamie Magee
Julian Robichaux
Kevin Kanarski - Domino
Lotus Germany
Notes Design Blog - Mary Beth Raven
Notes Goddess
Notes Migration Blog
Paul Mooney
Sherpa Software Domino Blog
Sametime Blog
Chris Miller / The Social Networker
Vision for Hire
Vineet Rohatgi
Wild Bill's Blog
The Notes Advocate
Adam Osbourne's Blog
XFN Friendly



Domino Server Configuration Docs - Mail rules and the "No Copy rule"

Victor Toal  October 15 2009 06:39:43 AM
In my current project I am part of a team that is doing a rather large R6.5.x to R8.5 migration. In the process of that project the architect of the team - I will call him "JZ" (real names removed to protect the innocent) is giving my Notes-Nazi inner self rather free reign on re-organizing how the servers are configured. The client actually is not in bad shape, they have been using server group based configuration documents all along. But for the migration process and ease of administration later, I am splitting them up a bit more to make control more granular. One of the main reasons of course being that we have different settings for R8.5 (HF1) servers that run on 64bit Windows and 64 bit Domino vs their older 6.x and some 8.x servers that run 32bit binaries.

Config Docs in general:

Anyone who has heard me speak at conference , had me working in their environment or met me over beer and was unsuccessful in shutting me up knows one thing: I am pretty adamant about a well structured configuration scheme - it just makes the life of an admin so much easier. I like moving all non-standard notes.ini variables that are shared by more than one server into configuration documents, I move [servertaskat=] calls into program docs, etc..

Server config docs are also the place where mail rules are set and this is where my little "gotcha" tale of the day starts. My current client journals the mail for specific users, it is actually a fairly good number of them (over 50) but not everybody in the domain of course. The client is using Domino based mail journaling (I approve - easy, reliable and quick) and this is accomplished using mail rules.

Like I mentioned, I have never used mail rules much up until now so I have to admit that I was surprised that when you copy a configuration document (or cut-and paste) the mail rules do not copy along with the document. Everything else of course is there, mail rules though ..... nada. Renaming the configuration document is not an issue, a simple copy however kills you. (WINK - LOTUS - WINK -> FIX THIS PLEASE!!!)


What does this mean for us admins now? Well:

If y'all got allot of mail rules you have to really think through how you have your configuration documents planned:
  • If you have one document per server and you have allot of them ... man are you screwed - you get to update EVERY document separately
  • If you have many changes to mail rules - each config document that needs to have that change or a new rule added needs to be updated individually

How do Configuration documents Apply?

So if your environment is large (= many servers) you really will benefit from a centralized configuration document scheme. Here is are the rules of how a server decides which configuration document will apply. Keep in mind that config docs are not cumulative - only the settings in the document that the server actually ends up using will be applied:
1.        Server-specific document (server's name is in the config doc's name field)
2.        Group based configuration document - if multiple documents for groups exist that the server is a member of, the alphabetically first one will be chosen
3.        OU based configuration docs - if multiple OU docs exist (i.e. one for */servers/Acme and one for */Acme) the one that shows first (alphabetical order) will be chosen
4.        Default configuration document for the domain (if one exists)

Domino will check one by one if there is a configuration document that meets one of the above criteria and then apply the first one it finds to itself. Again, config documents are not cumulative, they are explicit - only the settings in the document that the Domino server thinks apply to itself will be used. That is why you have to really think this through well when you do a clean-up or set it up for the first time.

Incidentally, this is the same order that ACLs rights are applied as - Domino is very logical here. I always like to call Domino the little ABC student - when in doubt, go by alphabetical order (including numerals) in EVERYTHING.

Go now, comb through your config docs and find out if you have servers that either don't have a configuration doccument that apply to them or have a different one than from what you thought - fix it today, don't wait until later.

© Victor Toal – 2009

Contact Victor









XFN Friendly










Locations of visitors to this page


Lotusphere 2010