Friday, February 27, 2009

Calendar Profile...Don't you hate that error?

Keith Taylor commented about it from my last post, Fud Buster Friday #29, and I realized I never blogged it before although I see it EVERYWHERE.

There are numerous errors and issues, some are more obvious than others. These appear when you first start up Domino and the server is checking various points of interest, well points of it's own interest. You can also find these, if you never noticed them, in your statrep.nsf(using the infamous name, Monitoring Results) file. Select Events, By Severity.
This will also show you what is wrong in your server(s). Before you do this, be warned, not everything you see is bad, so pay attention and react accordingly. If you need help, ask me.

I will try to hit the main ones in this post.

1)Keep in mind, the most common reason, if you as the Admin open up an employee's mail file and look at the preferences under the more option in the mail file you will see YOUR name NOT the employee. You can either have the employee login and fix this by selecting their name or you will have to run a lotus script agent to resolve it. See more details here(technote #1088892). This is usually the way to do it but I will list a few more possibilities in case you see other messages.

2) SchedMgr: Error processing calendar profile document
(NoteID: NT0000XXXX) in database mail\UserMailFile.NSF: Can't find user in Name and Address Book

Basically what it says is the mail file exists but the user no longer does.
Move the mail file out of the Domino directory to your file server and this goes away. For more details(it's an adminp issue based on what YOU the admin tell it) see the technote #1089324.

3)"SchedMgr: Error processing calendar profile document (NoteID: NT0000xxxx) in database filename.nsf: Can't find $BusyName field on profile"

Also somewhat cryptic but obvious. If you can't find a name on the preferences field of course this won't work. Right? Right.

So you have a few ways to resolve this, read the technote it goes into detail and includes code for you to fix this.

I would have included more except IBM's support search site went down and I need to head out. May update this or post a 2nd entry on this topic if anyone has more odd profile issues they want answered.

Fud Buster Friday #29 - One Outage isn't so bad.. is it?

Naturally it depends on who has the outage and how long it lasts and well, a million other things.

As we know Google had an outage this week. Ho hum. Welcome to IT guys. The world keeps spinning, we get blamed, we fix it, life moves on. Or does it?

Just spent over a week on a server crashing daily problem, because of my laziness and lack of attention to the clients plight. Well, to be fair, I was at 2 new clients this week, plus demoing for a 3rd and rewiring my office but the bottom line is I took a casual liberty attitude with a clients business and that's not good.

The client is extremely happy I have resolved the problem, will wait 72 hours before total acceptance.

But this taught me, and should teach you too, that one outage is too many for ANY client. And repeated ones spell disaster for any IT credit or expectations and it is VERY hard to recover from this and in some cases leads the customer to think about alternative email solutions.

The client had turned down clustering, even a backup replicated server(I am sure some PC could have been found but I digress). Their backup procedures are appalling and they have no idea why they were running LDAP, POP3,DECS, DIIOP or IMAP on the server. (Note to jr admins, just because you see a check box does NOT mean it must be checked.)

The server was throwing out the usual errors about calendar profiles, users not found in the NAB and a bunch of agent signing errors, which happen to run their apps but signed by a previous admin/developer, of course. And they had small quotas like 150MB. And of course you can guess which mail files had these errors. Funny how nonexistent people can fill up a mail file,waste disk space, routing, backup time and space and even have agents running! Also, if you have a donotreply@corp.com address, be prepared to have many replies to it. The fix is to just have an entry in the NAB and a mail file for it that purges every day or 7 or whatever you want. Otherwise, like the client, you could have 100's of dead mails in your 4 mail.box files.

Suggested to the client to take care of these, only to realize they could have been all along and never did. So as any good consultant would, we billed them for the mini clean up and are planning on a bigger clean up under a new project.

I saw the errors upfront, but we were working on a (thought we were)bigger problem and could fix these later. Remember, Eat the Frog, do the stuff you don't like or want to first and move forward. Taking the easy way out will never help you as an admin.

The other thing is delegate. It was bumped to me as others had tried to tackle it already. I was not happy none of them had resolved the errors or the small things.

Training is important, but walk the talk. As the Worst Practices session at LS08 showed, even the great ones don't always follow their own guidelines.

So I apologized to the client and oddly enough they were just happy anyone could resolve the problem. It has been a month or so off and on.

The downside is their clients just expect the server to be down and even if it stays up won't care. The worst part, for me, was after it all, they tell me they are going to move off Domino for mail. Working on that problem next and may blog it if it gets interesting.