Publishing error (failed to connect to server)

Report · May 24, 2007

Using X5, I am trying to publish to our help server (web help pro), but getting a message in the output window "Warining: Failed to publish to 'yourserver'. reason: Failed to connect to server.

All my permissions are set up as described here: http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=rb_e01

So... I ran a packet sniffer and then tried to publish again... and saw that the publisher attempts to access http://yourserver/robo/robo.dll?mgr=sys&cmd=svr When I try to access this address in a browser, I get a 401 error with the message below.

+---------------------------------------------------------------------------------------------
|Server: unauthorized
|Unauthorized due to ACL on resource
|
|This error indicates that the credentials passed by the client do not have access to the particular resource on the server. This |resource could be either the page or file listed in the address line of the client, or it could be another file on the server that is |needed to process the file listed on the address line of the client.
|
|Please make a note of the entire address you were trying to access and then contact the Web server's administrator to verify |that you have permission to access the requested resource.
+--------------------------------------------------------------------------------------

However, if I try to access that address _on_ the server ( http://localhost/....) I get some nice XML:

+--------------------------------------------------------------------------
|
|<?xml version="1.0" ?>
|- <mrs xmlns=" http://www.ehelp.com/mrs/xml/serverinfo/">
|- <head>
| <url host="localhost" ip="127.0.0.1" version="4.00.083" />
| <publish type="httppost" script="/robo/bin/WPSHost.dll?PUBLISH" />
| <serverapi url=" http://localhost/RoboAPI.asp" />
| <admin url=" http://localhost/robo/Admin/" />
| <projects url=" http://localhost/robo/Projects/" type="httppost" script="/robo/bin/WPSHost.dll?PUBLISH" />
| <documents url=" http://localhost/robo/Documents/" />
| <reports url=" http://localhost/robo/Reports/" />
| </head>
| </mrs>
+--------------------------------------------------------------------------

I can not seem to figure out what ACL is incorrect. I tried running process monitor (from winternals), and did not see anything helpful. The IIS www worker process seems to access all the robo files/registry without error.

Has anyone else had this problem? Can I get some guidance on how to resolve? We are about to purchase support incidents, but the sooner I can resolve, the better.

Any help appreciated. thanks,

ajperrins

Report · May 26, 2007

I'm afraid I won't be of much help except to say that this is a classic permissions issue. I have to assume you've checked and double-checked the link referred to in your post (which is a good one).

You might also try this technote:
Publishing to RoboEngine

In helping others troubleshoot this, it sometimes turns out that there are firewall issues that are not obvious especially if you are in a large organization crossing many domains from author to server. Are you the ultimate "server admin" or is there someone in your organization's network admnistration who could help resolve the permission issue?
Sorry I can't be of immediate help.
john

John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Newport, Oregon

Report · May 29, 2007

Also, make sure that the password stored in the publishing wizard matches your password on the server. If you recently changed your server password, the two will be out of synch, and the authentication will fail. This will result in the "failed to connect to server" message.

Report · May 29, 2007

johndaigle and ChetZeshonski: thanks for responding.

As it happens, I am in a large organization, and I'm not familiar with any firewall or domain policies that are in place. I've opened a ticket to try to resolve things with IT. My domain account has admin access to the box (which is a Virtual Server), and I am an administrator on it.

I have checked the ACL permissions on the box several times for the IWAM_<machine> and IUSR_<machine> accounts to no avail.

So I suspect (hope desperately?!) that IT has some weird domain policy or firewall set up that we can get changed.

I'll post the resolution when I know more.

Thanks again.

A.