With the launch of the new My Support Portal, we replaced the identity management system behind the OpenText Connect authentication tool with OpenText™ Identity and Access Management (IAM) as your single-entry point to OpenText developer and OpenText support resources.

For our Developer Trial users, if you experience any issues signing in to the Developer site or our Developer console, please refer to these articles.

Error: Failed to retrieve content from ACS/BOCS server(s).

edited May 12, 2014 in Documentum #1

We recently upgraded content server from 5.3 SP5 to SP6. After upgrade operation we are getting following error for view operation:

"Failed to retrieve content from ACS/BOCS server(s). The ACS/BOCS server(s) may be down or your machine may not be able to reach the server(s) due to network connectivity or configuration issues

com.documentum.ucf.common.UCFException: All remote hosts failed "

We want to use ACS server and I have checked that ACS server is running by using ACS URL. We are using SSL (https) for content transfer.

Anybody knows what causes this error? Also how do I know if I am using ACS or regular web server for content transfer?


  • tarh33l
    edited October 27, 2008 #2

    Check the attribute "acs_base_url" in dm_acs_config and make sure it's correct (and that you can browse to that URL from the client which is trying to fetch content). Also, you can enable or disable ACS for your webapp by changing app.xml (details in the link below). By default, ACS is enabled (however, if DFC queries the repository and determines ACS is not enabled, it should fall back to the old method of transferring content through the app server)

    Disable ACS


  • RaviJha
    edited May 8, 2009 #3


    You may want to try out the following:

    1. Check if ACS status page is seen when you try to access the “Base URL” from the client machine.

    Get the base URL from ACS config object (something like: http://<ACS_server_name>:<port>/ACS/servlet/ACS) and point the browser to that.

    The status page may not be displayed because of the following reason:
    ACS is not running
    ACS machine is not reachable from the client.
    You will need to make sure it is fixed.
    Many a time, the client and ACS are in different domains.
    Please try to specify a fully qualified ACS server name in the ACS URL and see if it resolves the issue.

    2.    If you get the ACS status page in 1, check the clocks on appserver machine and CS machine. If they are skewed up by more than 6 hours, try to synch them.

    3.    If both the above fail, please post a dump of ACS config, ACS log from CS, DFC log from the appserver and UCF client logs.

  • RaviJha
    edited May 22, 2009 #4

    I just realized that I missed to answer the second part of the question.

    The settings of "accelerated-read"/"accelerated-write" in app.xml, tell you whether you wish to use ACS for outbound/inbound operations or not.

    But the reliable way to find out whether the content transfer is using ACS/BOCS or not is to look into UCF client logs if you are getting a ACS URL (like http://<hostname>:port/ACS/servlet/ACS/...) or not.

    To enable UCF client logging go to %USERPROFILE%\Documentum\ucf\<hostname>\shared\config\ucf.client.logging.properties and set the logging level to ALL.

    Message was edited by: Ravi Jha

    Message was edited by: Ravi Jha

  • Webster
    Webster Andrew Webster
    edited June 19, 2009 #5

    Just had a similar problem to this and found this thread so I thought I would describe how I fixed it.

    In the following we are using D6SP1 on AIX.

    <host-name> is the host name of the content server (eg ppcsxx99)

    <full-host-name> is the fully resolved hostname of the content server (eg ppcsxx99.proj.unix)

    <alias-name> is an alias on the server - this is what we generally use to refer to the content server "host" (eg dmcsprod)

    In dm_acs_config, the acs_base_url was set to "http://<alias-name>:9080/ACS/servlet/ACS"

    Viewing the URL in a browser gave us an unresolved hostname error

    We updated the acs_base_url to "http://<host-name>:9080/ACS/servlet/ACS"

    Viewing this URL gave us a page not found error (better!)

    We then finally updated the acs_base_url to "http://<full-host-name>:9080/ACS/servlet/ACS"

    Viewing this URL gave us the ACS Running message - Fixed!

    Hope this helps someone in the future

  • gordon.freeman
    edited May 12, 2014 #6

    Check if the attribute "acs_base_url" in dm_acs_config has got "http://" in the beginning. I had the same issue because I forgot to put "http://" before hostname.