WebAdmin bug?

In Domino Admin client what is the relationship between:“Configuration/Messsaging/Messaging Settings” and

“Configuration/Messsaging/Configurations”

???

And why is the list different when viewed from WebAdmin?

In fact, I think when I used webadmin to edit “Configuration/Messaging/Settings” it DELETED the last document out of “Configuration/Messaging/Configurations”!!!

I had to use the admin client to put back both my “all servers” and server specific document.

I guess I have two questions:

  1. What is the realationship?

  2. Have I observed a bug in webadmin?

Subject: Confirmed: This is a bug and is being fixed.

You found a bug which is tracked under SPR # TGUZ5L3PGL. It’ll be fixed in a upcoming MR.The bug occurs if you use webadmin to edit the messaging settings via the “Configuration/Messaging/Settings” option.

To work around this bug, edit the configuration documents via the “Configuration/Messaging/Configurations” option instead.

thanks

Thomas - IBM

Subject: SPR not in database?

Thanks for the response - I could not find my symptoms in the database.

I can’t find that SPR in the database, is it hidden?

I want to know if there was a recovery method so I don’t have to re-install everything.

Can you extend what you explained to cover hosted orgs?

I’m wondering which/if a messaging settings document takes precedence in a hosted org? Is one supposed to make a seperate document for each hosted org?? I have running on the assumption that the server document gives settings for the base organisation, and the global settings are used for all hosted orgs.

Rich.

Subject: It’s logged in our internal SPR db

The SPR number can be tracked in the fix lists (available at http://www-10.lotus.com/ldd/r5fixlist.nsf/Public?OpenView) once included in a MR release. It is currently planned for R6.03 (too late for R6.02).

You don’t have to re-install everything. The configuration documents you edited via the “Configuration/Messaging/Settings” option are all saved in the Domino Directory, they just don’t show up in the configuration view anymore because the form name has been changed from “ServerConfig” to “($MessagingSettings)” (thats the bug). So, to get rid of those “unreferenced/stale” docs, you can simply create a new temporary view in the Domino Directory with the view selection formula Select FORM=“($MessagingSettings)” and then delete all those stale docs.

Thomas - IBM

Subject: RE: It’s logged in our internal SPR db

Thanks for the info!

Would this bug also cause hosted orgs to misbehave?

At about the same time this happened, I noticed that hosted org mail was not routing properly. That is, after a message was recieved for a hosted org, the server would reject all messages for anybody belonging to the original “base” server until the server was restarted. Or is this another bug I need to know about?

Thanks!

Subject: RE: It’s logged in our internal SPR db

Not sure. The bug I am refering to causes the configuration docs to disappear from the NAB (they are still there, but got saved in the wrong format so that the server can’t find em anymore, except webadmin). If the hosted org mail-routing was depending on such a configuration doc, then yes, it’s the same issue.

Subject: RE: It’s logged in our internal SPR db

Ah, well, sadly, I’m not privy to how hosted orgs route mail (vis-a-vis dependance on these documents).

I have tried to search the PR database, but, I am at a loss how to describe the problem.

I find it very odd that once a message has been routed to a hosted org mail to other users in that org continue to work OK. Its just mail to the “base” users (like Administrator) that fail.

Rich.

Subject: WebAdmin bug?

The relationship is that “Configurations” is a simple view with showing all the configuration docs, whereas “Messaging Settings” is a form showing the messaging-specific details only from a bigger configuration form, hiding the rest. It attempts to a) find a configuration doc for the specific server, and if it can’t, falls back to the standard “*” doc for all servers. Re: Whether you found a bug in webadmin: I am not aware of it. Can you reproduce this problem?

thanks

Thomas - IBM