Well... had a hard day today. But I have only myself to blame.
We had 100+ databases which were recently moved to a new server. So we had to update the "Run on" property of the agent to the new server. That can't be difficult! Just write a helper agent that will update all those agents using the ServerName property of NotesAgent class. I did just that, made it a little bit generic by adding configurable parameters. As their were a lot of databases to be updated I decided to run this agent on the server using the OpenAgent URL command. BIG MISTAKE!
After running the helper agent I noticed that my current ID's name had been put in the "Run on behalf of". Also the "Runtime security level" had been reset to "Do not allow restricted operations". I guess I found the answer here. Basically when you re-save the agent you change its signature and when this operation is performed on the server, the user ID is not available for resigning so there are some extra checks which complicate the situation. I guess this problem might also occur if you use scheduled helper agents but haven't tried it. So it is recommended that you run these kind of helper agents from Notes client to avoid them.
But in my case the damage had already been done. There was still a ray of hope. I could set the OnBehalfOf property to a blank value. Alas, its a read-only property. A little bit of search and I found this, this and this. There is field $OnBehalfOf which actually stores the value. So get the agent as a notes document using its Universal ID and then set its value. But there is a risk of your agent getting corrupted. Nope I am not ready to take that risk, not after all this. So finally I decided to manually update all those agents!
Moral of the story: When you need to update agent properties via code through an helper agent, make sure that you run the helper agent via Notes client and never under any circumstances from web or as scheduled.
We had 100+ databases which were recently moved to a new server. So we had to update the "Run on" property of the agent to the new server. That can't be difficult! Just write a helper agent that will update all those agents using the ServerName property of NotesAgent class. I did just that, made it a little bit generic by adding configurable parameters. As their were a lot of databases to be updated I decided to run this agent on the server using the OpenAgent URL command. BIG MISTAKE!
After running the helper agent I noticed that my current ID's name had been put in the "Run on behalf of". Also the "Runtime security level" had been reset to "Do not allow restricted operations". I guess I found the answer here. Basically when you re-save the agent you change its signature and when this operation is performed on the server, the user ID is not available for resigning so there are some extra checks which complicate the situation. I guess this problem might also occur if you use scheduled helper agents but haven't tried it. So it is recommended that you run these kind of helper agents from Notes client to avoid them.
But in my case the damage had already been done. There was still a ray of hope. I could set the OnBehalfOf property to a blank value. Alas, its a read-only property. A little bit of search and I found this, this and this. There is field $OnBehalfOf which actually stores the value. So get the agent as a notes document using its Universal ID and then set its value. But there is a risk of your agent getting corrupted. Nope I am not ready to take that risk, not after all this. So finally I decided to manually update all those agents!
Moral of the story: When you need to update agent properties via code through an helper agent, make sure that you run the helper agent via Notes client and never under any circumstances from web or as scheduled.
No comments:
Post a Comment