Schedule agent can't acces distant database

Hello,

I try to acces a database hosted by a distant server with a schedule agent.

If I run the agent with Domino Designer: everything 's OK.

But , I the agent is scheduled; my script cant acces the distant database.

I checked Distant Database ACL and Distant server Security options: everything looks like good.


Sub Initialize

	Dim ses As New NotesSession

	Dim db2 As New notesdatabase("","")

	Dim db3 As  New notesdatabase("","")



	f2 = db2.Open("CN=myDistantServer/O=myOrganisation","mail.box")   'Server distant

	Msgbox (CN=myDistantServer/O=myOrganisation mail.box==> " & f2)

	

	f3 = db3.Open(ses.CurrentDatabase.server,"mail.box")

	Msgbox (ses.CurrentDatabase.server & " mail.box ==> " & f3)

End Sub

Result for a scheduled launching:


20/02/2007 09:32:07   AMgr: Agent ('TEST bdGetMailBox' in 'CRD\BC.nsf') message box: CN=myDistantServer/O=myOrganisation" mail.box ==> False

20/02/2007 09:32:07   AMgr: Agent ('TEST bdGetMailBox' in 'CRD\BC.nsf') message box: CN=currentServer/O=myOrganisation mail.box ==> True

Any solution ?

Thks

Subject: Schedule agent can’t acces distant database

I’m pretty sure you can’t access anything other than the current server in a scheduled agent … unless you use the “Run on behalf of…” options on the second tab of the agent properties.

What I’ve done in the past is to schedule the agent on a local machine and replicate the results up to the server.

Hope that helps

Jason

Subject: RE: Schedule agent can’t acces distant database

I’m pretty sure you can’t access anything other than the current >server in a scheduled agent … unless you use the “Run on behalf >of…” options on the second tab of the agent properties.

Thanks Jason.

This is not really enforced me :o(

What I’ve done in the past is to schedule the agent on a local >machine and replicate the results up to the server.

I can’t use your tips .

In fact, I want to reduce harddrive activity with delocalized email notes on a distant server (without writing notes on local mail.box)

Hope that helps

I hope you’re wrong … and that someone find a solution to explore distant database thought a scheduled agent …

Subject: Schedule agent can’t acces distant database

This is a known issue up to R5 servers. It was a limitation of agents run on a schedule. From R6 onwards they introduced a ‘Trusted server’ setting that would allow server agents to access dbs on other servers.

Search support knowledgebase for 1086111

Excerpt…

"In Lotus Notes® and Domino® releases prior to 6.0, for security reasons, a background agent can access only databases which are local to the server where the agent is running.

In Notes/Domino 6 and later, additional security features were added which allow you to specify servers allowed to access a server via background agents or the LotusScript RunOnServer method. The server being accessed via the agent must grant this permission to the server running the agent. The “Trusted servers” setting is found on the Security tab of the Server document in the Domino Directory."

Subject: RE: Schedule agent can’t acces distant database

Hi Melissa,

You wrote : “… The server being accessed via the agent must grant this permission to the server running the agent. …”

My server is trusted … and my agent run correctly within “Execute” option in agents lists (Designer) … but nothing append when it was scheduled (futhermore, log.nsf not mentioned any error about it)

Subject: RE: Schedule agent can’t acces distant database

Cedric,

To be sure we’re talking about the exact same thing:

ServerA contains a db with a schedule agent. ServerB’s names.nsf has a server document for ServerB which says that it trusts ServerA.

If you have done this, then scheduled agents on ServerA will be able to reference ServerB. If you’re having trouble with a particular agent, then I recommend you make something trivial, like an agent that prints out the db.title of a db on ServerB.

regards,

raphael

Subject: RE: Schedule agent can’t acces distant database

This is correct, but note that there are significant security implications in “Trusting Servers” so I would recommend you only trust a server in your own domain, managed by your same admin team.

regards,

raphael