Infrastructure at your Service

Middleware Team

Upgrading to 7.2 created a new ACS. How to remove it and test it?

I had this strange behavior that once upgraded from 6.7 to 7.2 a new ACS was created. I think it’s because the current ACS name didn’t fit the new ACS name pattern. Well it’s not a big issue to have 2 ACS configured. But in my case they pointed both to the same port and servlet so… I had to remove one.

Hence, how can we know which one is used?

That’s easy, just find the file located in:



In this file you should find the line:



In fact my previous ACS was named YOUR_ACS_NAME.cACS1 that’s why I think a new one was created. So here you have the ACS used and you just have to remove the other one:

delete dm_acs_config objects where object_name = ‘YOUR_OLD_ACS_NAME’;

Fine, now how can we check that the ACS is working properly?

First you can paste the ACS url i your browser to check if it’s running, it should look like this:



If you installed your method server on another port than 9080, use it.

You should see the following result (maybe with a different version):

ACS Server Is Running - Version :


If you can’t find the ACS url, login to Documentum Administrator and navigate to:
Administration -> Distributed Content Configuration -> ACS Server
If you right click on it you will see the url at the bottom of the page.

At this point the ACS is running but is documentum using it properly?

In order to verify this point a bit of configuration is needed. Login to the server on which you have DA installed, in the DA application search for a file and add the following lines:, ACS_LOG, ACS_LOG
log4j.appender.ACS_LOG.layout.ConversionPattern=%d{ABSOLUTE} %5p [%t] %c - %m%n

You may have to update the line log4j.appender.ACS_LOG.File.

Restart the tomcat or whatever webapp server you have. In order to generate logs you’ll have to open a document from DA. Let’s say we have a document called TESTDOC.doc.
Once you open it you’ll have around 3 to 4 lines in AcsServer.log. In order to verify that everything went fine, you should NOT see the following line:
INFO [Timer-161] com.documentum.acs.dfc – [DFC_ACS_LOG_UNAVAILABLE] “userName=”test”, objectId=”0903d0908010000″, objectName=”TESTDOC.doc””, skip unavailable “ACS” serverName=”YOUR_ACS_NAME_HERE” protocol “http”

Instead you must have a kind of ticket/key formed by a lot of letters/numbers. This step will validate that you have been served by the ACS.

One Comment

  • /pct says:

    quite interesting and useful blog Stephane
    issue explained in this blog is common with migration to v7 and the easiest way to fix it is to drop all existing ACS config objects and re-create using dm_acs_install.ebs, this requires a few parameters including JMS port

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Middleware Team
Middleware Team