Today I had one of those "walk-on-water" moments that occasionally make consulting satisfying. Over the weekend I assisted a client in upgrading nine Domino servers from version 7.0.2 to 8.5.2. The marathon upgrade went generally smoothly. The main problem with it was there were just not enough hours in the weekend to upgrade (via compact -c) all of the databases on all of the servers. In particular, the headquarters mail server has an eye-popping number of multi-gigabyte mail databases on it. Those top execs just can't bear to part with any of their mail, and of course you can't enforce quotas against them; they'd have you (a lowly tech) drawn-and-quartered if you tried. So the one mail server never did get all of its databases upgraded to ODS 51. But except for that and a couple other minor problems, everything was working great on Monday morning.
Then a field technician in England reported that he couldn't set up a Notes workstation for a user who had been registered the previous week. The Notes setup kept failing with the following error message:
The Policy and/or Settings document assigned to you has been edited by an unauthorized person. Please notify your Administrator that you cannot proceed with the client setup.
Some Googling revealed that this error message arises when a policy or settings document is (as the message plainly says) signed by one who is unauthorized to sign it.. How could this happen? As follows: An administrator might in the past have created Policy and/or Settings documents that worked just fine. But then the administrator left the company and his account was removed from the domain. As a result, the retired administrator's signatures on the Policy and/or Settings documents were no longer those of an authorized signer, which is defined as one who has Editor access to the Domino Directory and is assigned the Policy Creator and Policy Modifier roles. See Technotes 1110644 and 1205444. Both of these Technotes state further that, to re-sign a Policy or Settings document you can, among other techniques, edit and save it.
How did this apply to us? That was not clear. As we could plainly see in the Policies and Settings views, the signer of all of the the Policy and Settings documents in the domain was a generic user named "Administrator" who is still to this day being used to create new users and who has the requisite access rights and roles assigned. So the error message seemed to be bogus, telling us something which was demonstrably untrue. Nonetheless, we tried editing/saving the policy and settings documents to apply new signatures. And, according to the Policies and Settings views, this worked. The views showed that each newly saved document had a new signer. But even though this new signer also had sufficient rights and roles assigned, we discovered that we could not register a new user into the England OU. So our problem was not only that we couldn't set up a new workstation for users registered before the upgrade, but also that we couldn't register new users after the upgrade.
We were scratching our heads over this and hunkering down for a long siege against this problem, when one of us had the bright idea of looking at the console of the mail server in question. (In this particular domain, there are several regional OUs. Each region also has a dedicated mail server. Also, each OU has an organizational policy with several OU-specific settings documents assigned to it. So our problem was affecting the England OU, the England mail server, and the England-specific policy and settings documents.)
There on the England mail server's console, in bright purple letters, was a cascade of error messages, repeating every few seconds:
Policies and settings documents signed by XXXXX are no longer valid because this person does not have the required access level or roles to the Domino Directory.
More Googling revealed that this new error message had the same cause as the earlier message, that is, that a Policy or Settings document was signed by an insufficiently authorized entity. The server was trying to apply a mail policy to the mail users on the server, but it didn't like the signature on the policy or mail settings document. However, this message told us one other bit of information that the earlier message had left out, which was that the Policy or Settings document was signed by the mail server itself, not, as the Policies and Settings views claimed, by the Administrator who actually created or last edited each document. Either the error message or the views were lying to us.
But the server did not in fact have the Policy Creator or Policy Modifier roles assigned to it in the ACL of the Domino Directory. So that meant that the error messages were perhaps not bogus after all. Assigning those roles to the server in the ACL should have solved our problem. We'll never know, however, if it would have done so, because our second bout with Google revealed one other fact -- that there was another (newer?) way to re-sign the Policies and Settings documents:
Select the documents in the Policies or Settings views, then in the Actions menu choose Resign Policy.
We tried that and it worked like magic. The cascade of messages in the server's console abruptly stopped. Thereafter, we found we could once again register new users and set up Notes for them. Later we checked the other mail servers and discovered that the Mexico server was experiencing the same problem. So we re-signed all of the policies and settings documents. Just like that, the Mexico server's messages stopped too.
Conclusion: Something happened that shouldn't have when we upgraded two of the nine servers. Apparently that something is that, somehow, the upgraded servers' signatures were applied to the Policy and/or Settings documents. Also, the Policies and Settings views tell us that the last editor of a document is the signer of it, which makes sense. The Technotes cited above tell us that too. But in our case saving the Policy or Settings document did not apply a new signature to it. So the view is misleading in that regard (and so are the Technotes). I think I'll tell Lotus about this.
No comments:
Post a Comment