RE: Converting HTML to pdf using LS agent MALLIK R PERVELA 5.Feb.12 08:04 AM a Web browser Applications Development All ReleasesAll Platforms
Hope below description helps.
Pervela Mallik Ram Sharma
R5 to 6.5 Migration Update (Monday, Jan 19)
[ permalink ] [ GoogleTrack ] [ e-mail me ] [ comments (4) >> ]
With all the Lotusphere talk that's going on, I forgot to tell you how the R5 to 6.5 server migration went 2 weekends ago (by the way, I know that version 5 was "R5", and version 6 was "ND6", but what's version 6.5 -- ND6.5?).
Everything went quite smoothly. I wasn't in charge of the server migrations themselves (we have a competent administrator who does such things), but I did have to make sure that the apps would continue to run. In retrospect, I've got a few things to add to my earlier comments about what to look for before you upgrade:
My initial plan included using DDSearch to find obsoleted bits of code, but it didn't occur to me that databases with hidden designs or code that %Includes LSS files wouldn't be searchable. As always, nothing beats a healthy dose of testing.
I found a Notes/Domino 6 Migration Knowledge Collection in the Lotus Knowledgebase that has a few extra things to watch out for.
I also found a technote describing the problem with uploads greater than 10 MB, which is important to be aware of. Rocky mentioned this recently too.
In ND6, the permissions of the signer of a script library will filter down to agents that use that script library, so make sure that you have everything signed properly.
And the biggest gotcha of all: beware the new security settings that restrict agent operations. By default, the runtime security level on some agents seemed to be set to "1. Do not allow restricted operations", which caused some scheduled agents to fail. After resetting the runtime security level to "2. Allow restricted operations", they worked fine. One thing I noticed though is that the CreateObject and GetObject functions seem to be restricted operations, although they are not listed as such in the Notes Help.
As I said, the biggest thing to watch out for after you migrate to ND6 and higher is the agent runtime security, because your agents can fail somewhat silently if this isn't set properly in ND6 and 6.5. All you'll see is that the agents don't seem to be running, and there might be some errors like this in the Console Log:
Error 201: Operation is disallowed in this session
Programmer that I am, when I discovered this, I knew I had to write an agent that checks the runtime security settings. So I wrote a LotusScript agent that checks all the agents in all the databases on a server (the ones you have access to, anyway) and spits out a comma-delimited file with information about the $Restricted field for the agents ($Restricted = 1 is level 1, $Restricted = 0 is level 2, $Restricted = 2 is level 3 -- if the field doesn't exist, I think it's treated as level 1). This code is available as my latest tip: Listing the ND6 Restriction Level for All Agents.
One nice thing about the code in this tip is that it can serve as a template for any other agent you want to write that searches though agents and script libraries in a database. The procedure is that it gets the NoteIDs of all the agents and script libraries and returns them in a List, so you can access them as regular Notes documents (and read and/or set their fields). Granted, you can also do this using Damien Katz's DatabaseDesign library, but I think that his technique requires Designer access to the databases you're looking at, and I'm pretty sure that mine only requires Reader access (see update below for a correction to that statement).
If you're feeling a bit wacky, you could easily modify this agent to set the $Restricted field to 0 for all scheduled agents, but that could be dangerous. Script hacker beware.
UPDATE: Okay, here are two clarifications to what I was saying about Damien Katz's DatabaseDesign library:
1. When I was remembering the library, I was thinking of the PlatformIndependentDatabaseDesign class, which creates temporary views and uses some interesting $FormulaClass manipulations to get collections of design documents. That particular method requires Editor access (with the ability to create public views), not Designer access as I previously said.
2. The API_DBDesign class in Mr. Katz's library uses exactly the same technique that I was demonstrating (using IDScan to get the NoteIDs of a class of Notes), so I'm not really presenting a different method at all. It's really the same technique, only he uses a class and offers a much more finished and flexible piece of code, and I've got a function with more specific functionality. In either case, that way of doing it does only require Reader access to a database.
I think that covers it. Sorry to put such false and misleading information on my site. I really should have actually looked at the DatabaseDesign library before I talked about it, instead of relying on my increasingly faulty memory. Measure twice, cut once and all that.
Error: "Operation Is Disallowed in this Session" Running Scheduled LotusScript Agent
A Scheduled LotusScript agent generates the following error message on the Domino Server console:
"<date time> AMgr: Agent ('<agent name>' in '<filename>' error message: Operation is disallowed in this session".
The server console also indicates that the agent ran successfully but in fact the agent did not execute all of the code within the agent. The agent in this case makes use of an unrestricted LotusScript call Dir. The signer of the agent is listed under the "Run Unrestricted Methods and Operations" option in the server's Server document (under the Security, Programmability Restrictions area).
The same agent can be triggered manually without issue.
In Notes/Domino 6.0 and above additional functionality was added to the Agent Properties which allows a variety of security options, one of which controls the agent's ability to execute restricted operations. These properties are found on the Security (Key) tab of the Agent Properties. The "Set Runtime Security Level" property defaults to a value which does not allow agents to access restricted operations. In order to execute restricted operations the property would have to be set to "Allow Restricted Operations".
Details on the Property Settings
There are three levels available:
1. Do not allow restricted operations (Default)
2. Allow restricted operations
3. Allow restricted operations with full administration rights
Description of these values:
Do not allow restricted operations
The agent is not allowed to perform restricted operations. Note that this is the most secure choice. The reason the agent cannot perform restricted operations is that the agent has rights that are restricted.
Allow restricted operations
The agent can perform restricted operations because it is has been granted unrestricted rights. Note that this is a less secure choice than the previous one and grants the agent more power.
Allow restricted operations with full administration rights
The agent can perform restricted operations and can do so with full administration rights. This choice grants even more power to the agent because the agent now has been granted unrestricted rights and given full administration rights. Use this choice with caution.
The "Set Runtime Security Level" property setting is saved as a numerical value in the $Restricted field of the agent. The values of the $Restricted fields correspond as follows:
Do not allow restricted operations = 1
Allow restricted operations = 0
Allow restricted operations with full administration Rights = 2
Some of the other new properties introduced in Notes Domino 6.0 which are also found on the Agent Properties Security tab:
- Run on behalf of
- Allow remote debugging
- Allow user activation
- Default access for viewing and running