nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Content Server 6.7 SP1 Strangeness

david.matheson

I've just installed content server 6.7 SP1 and I'm having issues with it, namely running the LDAP sync from the command line and running Java Method Server jobs in general (the latter led me to figuring out the former). Here's what I've noticed so far (note that I put everything on but you probably have it on C:, that's the only difference from default):

The file \Documentum\product\6.7\dctm-server.jar is used as a catch-all to add to the environment variable "CLASSPATH" and just has a MANIFEST.MF file that references everything in \Documentum\product\6.7\lib, but it has a mistake: it references jss311.jar when jss42.jar is there in lib. This prevented me from running LDAP sync from the command line until I fixed it.
The JBoss version changed from 4.3.0 to 5.1.0, so some stuff is moved around, namely the place where you specify the port that it runs on. This is now in \Documentum\jboss5.1.0\server\DctmServer_MethodServer\conf\bindingservice.beans\META-INF\bindings-jboss-beans.xml in the bean configuration for "org.jboss.services.binding.ServiceBindingMetadata"
JBoss's deploy directory (D:\Documentum\jboss5.1.0\server\DctmServer_MethodServer\deploy) now contains a bunch of directories and files that end in .bak ("jmx-console.war.bak", "jmx-remoting.sar.bak", "management.bak", "ROOT.war.bak", "xnio-provider.bak" and "uuid-key-generator.sar.bak" for directories and "jms-ra.rar.bak", "mail-ra.rar.bak", "mail-service.xml.bak", "schedule-manager-service.xml.bak", "scheduler-service.xml.bak", and "sqlexception-service.xml.bak"). I haven't changed these files, and nobody else touches this server but me.

I'll mark this as a question, but feel free to add your own items specific to 6.7 SP1, and let me know if you also experience any of these issues.

Find more posts tagged with

Comments

david.matheson

It turns out my problem with the JMS not running jobs was just that the reports in /System/Sysadmin/Reports were locked by an account other than the installation owner. That's all working fine, but the issues raised above are still valid.

This would cause any method you're trying to run manually to crash if it depends on JSS (network security services for Java).
This causes confusion when you contact support, because they still point you to the old ways of checking the port, and it looks like it's set to 8080, not 9080.
This adds to the confusion because the real test of whether the JMS is running is to try http://localhost:9080/jmx-console from the browser on the content server, and this will fail because someone has moved jmx-console out of the way.

JedSpink

Point 3: Would you not try: http://<host>:9080/DmMethods/servlet/DoMethod and the one for ACS too (ACS/servlet/ACS)? Or 8080 now if this has changed... I prefer to know these are running as well.

david.matheson

Yes, you can also try those, but jmx-console is present in out-of-the-box JBoss, so EMC support often uses that as a first step, and assumes that you have the wrong port if it doesn't come up. The default of 9080 hasn't changed, but it can look like it has if you go hunting for it the old way.

crossroadsk

Hi David,

We are working with CS 6.5SP1 which had jboss4.2.0 as method server. We are planning to upgrade CS to a higher version and expecting a higher version of jboss to be installed with CS6.7/6.7SP1.

When I was referring installation guide, noticed "jboss4.2.0" in the "configuration jboss application servers for ssl" section.

Can you confirm the Jboss version installed with content server 6.7SP1 is 5.1??

Your response would be very helpful.

Thanks!

david.matheson

Hi crossroadsk,

Yes, the version of JBoss is 5.1.0. You can verify this with the release notes for Content Server Enterprise Edition Version 6.7 SP1.

Dave

crossroadsk

This is very helpful information.

Thank you!

r_mair

david.matheson wrote:This adds to the confusion because the real test of whether the JMS is running is to try http://localhost:9080/jmx-console from the browser on the content server, and this will fail because someone has moved jmx-console out of the way.

Have you ever got a reply on this strange situation? I just installed a new instance of 6.7 SP1 (not an upgrade) and all of those .bak files are in there, so it isn't that "someone moved them" it's that EMC is not activating them by default any more.

Is there a reason why they are shut down? will they cause problems if they are active or is it just that they aren't necessary for the method server to run?

Akulhari

Hi David,

As you have installed CS 6.7 sp1.So can you please help us on repository creation on CS 6.7sp1.

Issue-

While creating repository the stepup is struck during last steps where it is testing connection with repository...

even we manually start the repository after changing the oracle instant client lib...but the stepup remains struck in last step of testing connection 98% ... & in logs it give last print - Waiting for repository **** startup.

Thanks ,

Ashok Kulhari

david.matheson

Hi Ashok,

Hard to say what your issue is. What server OS are you on? What database server OS are you using? What version of Oracle? Are you able to start the content server outside of the setup process? I'm not sure what you mean by changing the Oracle instant client lib. Good luck to you.

Akulhari

Hi David,

Thanks.

Yes we are able to start repository after adding Oracle 11g instant client library for 32-bit manually.

But during some of last step of repository configuration steps .. like creating dm_bof_registry etc... the stepup struck during testing to connect with repository.

DCTM_Guru

Hi David,

Just wanted to let you know that we too are experience LDAP strangeness after upgrading to SP1. When we downgrade JMS back to 4.3.0 (orig 6.7 version), it works as expected. Support says that Patch 03 may fix this, but we havent gotten around to testing it yet.

david.matheson

I coaxed LDAP into working by turning on SSL, although this wasn't necessary in all cases. We could not nail down why it sometimes worked and sometimes didn't, even after hours on support calls with EMC.