I have been tasked with updated users OOO profiles (Amend the general and special subject following a domain transfer). I have managed to get this working via a scheduled Lotus Script agent. I have now been asked to modify this code to also update the “$MachineName” variable on the “ProcessOutOfOffice” agents if this is incorrect and the agent is not currently enabled.
When the code is scheduled I am receiving the following error on the server console
“4000 Notes error: Effective users of the saved agent and the saving agent must match”
The agents runtime security is set to “3. Allow restricted operation with full administration rights”
I have checked throught the forum and (unless I have been reading things wrong) I have modified the servers document security section so that I can sign agents to run on behalf of someone else.(agent manager was restarted following this change)
Any further suggestions would be most appreciated.
Cheers
Dave
Subject: Update OOO Programatically
When you resave the agent you change its signature. When you perform this operation on the server, the user id is not available for resigning so there are extra checks in play to make sure that the save operation cannot be spoofed. If you can perform these modifications while running from the client (database can be on the server) you will avoid the complexities of the situation.
I have written some explanation in of how saving on the server works, rather than retyping it here see if the explanation in “Decoding ND6 agents” article in agent FAQ might be of help.
Subject: RE: Update OOO Programatically
Hi Julie, Thanks for the response. I have read your article, very useful thanks. I thought someone might say run it manually so I have modified the scheduled agent to flag up any OOO agents with the wrong $MachineName. I can now easily modify via the client. (Great thing these background agents)
Pity I could not all be done via a scheduled agent, but you can’t have it all.
Again, thanks for your response
Cheers
Dave
Subject: RE: Update OOO Programatically
What were the signiture in the agents in your example (server or user, and what level of priviledges did they have) and did they have OnBehalf field value set? (The agents you were trying to modify, not your agent that was doing the changes).
Subject: RE: Update OOO Programatically
The agents are signed by the mailbox owners. They have manager access to the mailbox holding the agent. The “Run on behalf of” security option is blank in the agent to be updated.
The agent trying to make the updates is signed by myself. I have full admin rights and Manager access to users mailbox.
Subject: RE: Update OOO Programatically
Julie,
I’m having the same problem here, trying to disable the OOO agent. I have an agent that inspects mail files for enabled OOO agents and, if the current date is greater than the First Day Back field in the OOO profile, attempts to disable the OOO agent.
To answer your questions:
-
The OOO agent is signed by the owner of the mail file. Other than being a Manager of the mail file, the owner doesn’t have any special privileges on the server.
-
The owner/signer of the OOO agent is NOT listed in the “Sign agents to run on behalf of someone else” field of the server doc.
-
The helper agent is signed by an admin ID that appears in the “Sign agents to run on behalf of someone else” field of the server doc. This ID is not in the ACL of the mail files but it is a full-access admin and that option is selected in the helper agent’s security options.
If I’m reading your message and the “Decoding… agent features” document correctly, I take it that the signer of the OOO agent AND the signer of the helper agent must appear in the “Sign agents to run on behalf…” field of the server doc? Is this correct?
If this is the case, then I don’t know how to accomplish my task with a scheduled agent - disable “expired” OOO agents. It doesn’t seem like a good idea to give everyone the “Sign agents to run on behalf…” privilege. Is there another way to accomplish this? Thanks.
Mark
Subject: RE: Update OOO Programatically
-
The OOO agent is signed by the owner of the mail file. Other than being a Manager of the mail file, the owner doesn’t have any special privileges on the server.–> If a person is a manger or designer they need to have rights to run LotusScript agents for the agent to run. I would expect that this agent receives a run time error when it attempts to run.
-
The helper agent is signed by an admin ID that appears in the “Sign agents to run on behalf of someone else” field of the server doc. This ID is not in the ACL of the mail files but it is a full-access admin and that option is selected in the helper agent’s security options.
If I’m reading your message and the “Decoding… agent features” document correctly, I take it that the signer of the OOO agent AND the signer of the helper agent must appear in the “Sign agents to run on behalf…” field of the server doc? Is this correct?
→ You are correct. To avoid spoofing situations this had to be pretty tight so some useful scenarios become difficult.
If this is the case, then I don’t know how to accomplish my task with a scheduled agent - disable “expired” OOO agents. It doesn’t seem like a good idea to give everyone the “Sign agents to run on behalf…” privilege. Is there another way to accomplish this? Thanks.
→ I have some suggestions in a new article I wrote about Out of office agent (came out last week). There are some utility agents that are part of the template that might be helpful. There also AdminP class that has methods to turn on/off mail agents that might do what you need.