June 26th, 2005
The Philosphy of Notes Admin - Part 1
One very important rule of
Notes Administration is: Listen to your server.
It's been my experience that if you listen to your Domino server, it will
usually - to the best of its ability - tell you what's wrong when it doesn't
feel good. Time and again when I've tried to get all sophisticated
with troubleshooting and investigating, I get smacked back down to basics
in the end when I realize that the answer was there all along - and the
server told me the problem. Sometimes there's a bit of a language
barrier because Domino speaks its own dialect, and it only has the words
that its given by the developers, but it tries.
For instance, this oldie but goody:
06/26/2005 10:10:17 AM SchedMgr: Error processing calendar profile document (NoteID: NT00000902) in database mail\jfallon.nsf: Cannot find user in Domino Directory
Now to me, this screams "There's an orphaned mail file on that server!" The server simply doesn't have enough room for the long error message which would go something like this: "Hey - this is the Schedule Manager server task here. I've been going through the list of calendar profiles I've found on this server and comparing them to the person documents in your Directory, I've found this one profile document belonging to jfallon (is that THE Jimmy Fallon?) - and it appears that jfallon doesn't exist in your directory. You might want to check this out."
There could of course be several reasons for this - maybe a name change gone wrong, maybe your AdminP approval document hasn't been processed, or maybe there's even a typo. But the server doesn't know - and doesn't have time to spit out the possibilities - but it did tell you where to start looking for the problem. Learn more about the Schedule Manager here.
Another one that caused me great humiliation - because it was a developer pal who pointed out the obvious - is this one: "Unable to replicate names.nsf: Replication cannot proceed because cannot maintain uniform access control list on replicas". I searched for about a day for problems. The ACLs were identical on all copies of names.nsf. I sent out a note to my team mates seeking help, and one of the developers suggested that I check the access level of the server throwing that error, and mused that the ACL level would be something less than Manager. DOH.
How could I have known that? Why didn't the server say something like, "Hey - listen, I'd love to maintain a consistent ACL for you, but we all know that only a Manager of a database can make changes to an ACL, and I'm only an Editor, so even if I wanted to - I couldn't possibly maintain that ACL for you because I can't change it. So, since I can't maintain that ACL for you, I have decided to not accept replication changes. You, Notes Goddess are obviously confused and have asked me to do the impossible, so I will wait here and not allow damage to the Directory until you figure out what you really want me to do, 'kay?"
My problem was that I didn't listen to the server. It very clearly told me that it could not MAINTAIN a consistent ACL and left the reason as an exercise for the student - which I should have known, but was so far down into investigating the problem that I didn't look at the obvious.
These are just two examples of how listening to the server can be beneficial. Do you have others?
