S
By Suhas Das
Author
5 views
Summary
For Documentum Clients (D2, xCP, DA, Webtop, etc), what information do you need to collect for user login problems?
Resolution
To investigate why OTDS users can not login to a repository via Documentum Client (D2, xCP, DA, Webtop, ...) the following logs and configurations are required.
Required logs and configurations
From OTDS:
- otds.log, directory-access.log
- OTDS configuration report
- For complex cases, a web browser and or network trace (for example with Fiddler) (from client machine) with SSL decrypted
From Documentum Server:
- otdsauth.log
- And JMS application server log
- server.log - if JMS is hosted on Wildfly
- catalina.out - if JMS is hosted on Apache Tomcat
- otdsauth.properties
From Documentum Repository:
- API dump of all server config objects
- If login problem only affects some users, THEN API dumps of the problem users and an API dump of at least one known good working user
From Documentum Client application - xCP, D2, Webtop, DA:
- Documentum Client log
- application server log, for example
- server.log - if application hosted on Wildfly
- catalina.out - if application hosted on Apache Tomcat
- SSO configuration files
To enable DEBUG log messages
- If possible please capture problem after enabling DEBUG logging configuration.
- On OTDS this can be achieved by setting parameter otds.log.level to DEBUG.
- On Documentum Server this can be achieved
- by changing INFO setting
- rootLogger.level=INFO
- to DEBUG
- rootLogger.level=DEBUG
- in file
- if 21.1 or less with JMS hosted on WildFly
- ...\DctmServer_MethodServer\deployments\ServerApps.ear\OTDSAuthentication.war\WEB-INF\classes\log4j.properties ( OR log4j2.properties )
- if 21.1 or greater with JMS hosted on Apache Tomcat
- %DM_JMS_HOME%\webapps\OTDSAuthentication\WEB-INF\classes\log4j2.properties
- if 21.1 or less with JMS hosted on WildFly
- And restarting Documentum JMS service
- by changing INFO setting