Symptoms
UCF component unable to upload any files to Documentum. Enabling UCF trace shows no UCF server log.
An error has occurred when invoking the UCF runtime. Details:
Failed to connect to server - refer ucf client logs for details
An error has occurred when invoking the UCF runtime. Details:
Failed to connect to server - refer ucf client logs for details
After closing this window, press the Refresh or Reload button on your browser to continue.
Hide Details
Stack Trace:
An error has occurred when invoking the UCF runtime. Details:
Failed to connect to server - refer ucf client logs for details
com.documentum.ucf.client.install.launcher.InvocationException: An error has occurred when invoking the UCF runtime. Details:
Failed to connect to server - refer ucf client logs for details
at com.documentum.ucf.client.install.launcher.impl.RuntimeInvoker.retrieveContent(RuntimeInvoker.java:433)
at com.documentum.ucf.client.install.launcher.impl.RuntimeInvoker.initConnectionForSharedProcess(RuntimeInvoker.java:287)
at com.documentum.ucf.client.install.launcher.impl.RuntimeInvoker.initConnection(RuntimeInvoker.java:59)
at com.documentum.web.applet.ucfinvoker.LaunchRuntimeDelegate.connectRuntime(Unknown Source)
at com.documentum.web.applet.ucfinvoker.Java2DelegateImpl.access$201(Unknown Source)
at com.documentum.web.applet.ucfinvoker.Java2DelegateImpl$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.documentum.web.applet.ucfinvoker.Java2DelegateImpl.connectRuntime(Unknown Source)
at com.documentum.web.applet.ucfinvoker.LaunchRuntimeDelegate.safeConnectRuntime(Unknown Source)
at com.documentum.web.applet.ucfinvoker.LaunchRuntimeDelegate.getUcfSessionId(Unknown Source)
at com.documentum.web.applet.ucfinvoker.LaunchRuntimeDelegate.start(Unknown Source)
at com.documentum.web.applet.ucfinvoker.LaunchRuntime.start(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
SEVERE: Error during retrieveing Requests:
java.io.EOFException
at java.io.DataInputStream.readFully(Unknown Source)
at java.io.DataInputStream.readUTF(Unknown Source)
at java.io.DataInputStream.readUTF(Unknown Source)
at com.documentum.ucf.common.transport.spi.StreamHelper.readString(StreamHelper.java:29)
at com.documentum.ucf.client.transport.impl.ClientReceiver.getRequests(ClientReceiver.java:44)
at com.documentum.ucf.client.transport.impl.ClientSession.handshake(ClientSession.java:510)
at com.documentum.ucf.client.transport.impl.ClientSession.handshake(ClientSession.java:485)
at com.documentum.ucf.client.transport.impl.ClientSession.run(ClientSession.java:201)
Cause
Bug 118836, install dab after Webtop or DA.
If Webtop is installed before DAB, you may experience the ucf-server-api.jar issue referring to different location, the one in DAB. The reason is that, dctm.jar ->manifest.mf has the following:
Application%20Builder/devws.jar
And devws.jar ->manifest.mf has ucf specified as below. This jar is in C:\Program Files\Documentum\Application Builder, the ucf-server_api.jar is under C:\Program Files\Documentum\Application Builder\lib
Resolution
1. Go to DOS prompt.
2. Enter:
==
set classpath=
==
3. Start WebLogic from that command line prompt and see if that works.
An alternative solution is to get rid of dctm.jar from classpath. Reference all the jar files under Documentum\shared directory in the classpath.
Thursday, November 20, 2008
Why am I seeing error "All remote hosts failed" when trying to retrieve content?
Below are things to check when seeing error "Failed to transfer content due to a transport error com.documentum.ucf.common.UCFException: All remote hosts failed":
Background:
When using ACS to retrieve content (the default content transfer mode starting in 5.3 SP1), DFC produces URLs that point to content on the ACS/Content Server machine. UCF on the browser machine tries to use these URLs to retrieve the content. These URLs are produced based on a "base url" in the ACS config attribute. (The ACS config is managed in DA.) This means the browser machines requires connecting to the ACS/Content Server machine.
A URL will not be generated for an ACS that is not running but if ACS goes down AFTER the URL was generated that client will fail with the error but all other content requests will succeed using the pre-ACS content transfer mode (just using Content Server) until ACS is restarted.
1. One possibility for the error is that URLs cannot be DNS-resolved on a client computer. (like http://localhost, or http://servername instead of http://servername.emc.com). If need be, the base URL can be changed using IAPI:
API>retrieve,c,dm_acs_config
API>set,c,l,acs_base_url
SET>
API>save,c,l
In order to check which URL the browser is using to access content, change the UCF log level on a client side (where the browser is) by changing:
.level=FINE
In the file:
C:\Documents and Settings\\Documentum\ucf\\shared\config\ucf.client.logging.properties
The output goes to file- C:\Documentum\Logs\ucf.trace<….>.log
Another way is to get the same information on a Webtop/DFC side. Enable INFO or DEBUG logging for a category
com.documentum.acs
Webtop machine in the log4j.properties file. These changes should be picked up dynamically.
2. Check that a firewall does not restrict access to these URLs from the client computer.
3. Check the $DOCUMENTUM/shared/logs/AcsServer.log for errors.
4. If the following error occurs in the Java Method Server log:
FATAL [HttpProcessor[9080][4]] acs.com.documentum.acs.sdi.ACS -
java.lang.NoSuchMethodError: org.aspectj.runtime.reflect.Factory.makeJP(Lorg/aspectj/lang/JoinPoint$StaticPart;Ljava/lan
g/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Lorg/aspectj/lang/JoinPoint;
and DCM is being used in the Docbase, go to C:\Program Files\Documentum\tcf\lib or the appropriate place on the UNIX system and rename file aspectjrt1.1.0.jar to something like aspectjrt1.1.0.bak
In some cases, you may be getting the "all remote hosts failed" error in a standalone docbase WITHOUT DCM, and in that case, you will need to go find the 1.2.0 version of that jar file, aspectjrt-1.2.0.jar, merged with custom documentum classes in the Documentum\product\5.3\tomcat\webapps\ACS\WEB-INF\lib\ucf-server-impl.jar class.
If you copy that the aspectjrt-1.2.0.jar to the lib directory and rename the aspectjrt-1.1.0.jar to something like .bak, then all errors go away.
5. If there is an error like 'java.lang.NoClassDefFoundError: org/aspectj/lang/NoAspectBoundException', the reason for this error is that Application Builder is installed on the same machine as the Content Server.
App Builder and ACS server use common jar file ucf-server-api.jar. In the classpath for ACS Server, the ucf-server-api.jar located in program Files\Application Builder\lib directory has precedence over the same jar file present in ACS server webapp lib directory. Quick test to confirm this would be rename the ucf-server-api.jar in Application Builder lib directory to ucf-server-api.bak and restart the Java Method Server. Note that you have to stop the method server before renaming the jar file as the jar will be in use while the server is running and will not allow you to rename the file.
The workaround for this is to install Application Builder on a different machine or modify the classpath of the java method Server so that App Builders ucf-server-api.jar is not in the classpath of the java method server.
Background:
When using ACS to retrieve content (the default content transfer mode starting in 5.3 SP1), DFC produces URLs that point to content on the ACS/Content Server machine. UCF on the browser machine tries to use these URLs to retrieve the content. These URLs are produced based on a "base url" in the ACS config attribute. (The ACS config is managed in DA.) This means the browser machines requires connecting to the ACS/Content Server machine.
A URL will not be generated for an ACS that is not running but if ACS goes down AFTER the URL was generated that client will fail with the error but all other content requests will succeed using the pre-ACS content transfer mode (just using Content Server) until ACS is restarted.
1. One possibility for the error is that URLs cannot be DNS-resolved on a client computer. (like http://localhost, or http://servername instead of http://servername.emc.com). If need be, the base URL can be changed using IAPI:
API>retrieve,c,dm_acs_config
API>set,c,l,acs_base_url
SET>
API>save,c,l
In order to check which URL the browser is using to access content, change the UCF log level on a client side (where the browser is) by changing:
.level=FINE
In the file:
C:\Documents and Settings\
The output goes to file- C:\Documentum\Logs\ucf.trace<….>.log
Another way is to get the same information on a Webtop/DFC side. Enable INFO or DEBUG logging for a category
com.documentum.acs
Webtop machine in the log4j.properties file. These changes should be picked up dynamically.
2. Check that a firewall does not restrict access to these URLs from the client computer.
3. Check the $DOCUMENTUM/shared/logs/AcsServer.log for errors.
4. If the following error occurs in the Java Method Server log:
FATAL [HttpProcessor[9080][4]] acs.com.documentum.acs.sdi.ACS -
java.lang.NoSuchMethodError: org.aspectj.runtime.reflect.Factory.makeJP(Lorg/aspectj/lang/JoinPoint$StaticPart;Ljava/lan
g/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Lorg/aspectj/lang/JoinPoint;
and DCM is being used in the Docbase, go to C:\Program Files\Documentum\tcf\lib or the appropriate place on the UNIX system and rename file aspectjrt1.1.0.jar to something like aspectjrt1.1.0.bak
In some cases, you may be getting the "all remote hosts failed" error in a standalone docbase WITHOUT DCM, and in that case, you will need to go find the 1.2.0 version of that jar file, aspectjrt-1.2.0.jar, merged with custom documentum classes in the Documentum\product\5.3\tomcat\webapps\ACS\WEB-INF\lib\ucf-server-impl.jar class.
If you copy that the aspectjrt-1.2.0.jar to the lib directory and rename the aspectjrt-1.1.0.jar to something like .bak, then all errors go away.
5. If there is an error like 'java.lang.NoClassDefFoundError: org/aspectj/lang/NoAspectBoundException', the reason for this error is that Application Builder is installed on the same machine as the Content Server.
App Builder and ACS server use common jar file ucf-server-api.jar. In the classpath for ACS Server, the ucf-server-api.jar located in program Files\Application Builder\lib directory has precedence over the same jar file present in ACS server webapp lib directory. Quick test to confirm this would be rename the ucf-server-api.jar in Application Builder lib directory to ucf-server-api.bak and restart the Java Method Server. Note that you have to stop the method server before renaming the jar file as the jar will be in use while the server is running and will not allow you to rename the file.
The workaround for this is to install Application Builder on a different machine or modify the classpath of the java method Server so that App Builders ucf-server-api.jar is not in the classpath of the java method server.
Friday, November 7, 2008
Exception in thread "main" java.lang.NoClassDefFoundError
A simple Hello World example.
public class Hello {
public static void main(String argv[]) {
System.out.println("Hello world !");
}
}
then, when you compile it:
> javac Hello.java
and want to execute it:
> java Hello
Exception in thread "main" java.lang.NoClassDefFoundError: Hello
We set the CLASSPATH and JAVA_HOME enviroment variable correctly, and the problem was still the same..
When we copied the Hello.class into a lib directory of JAVA_HOME, it worked, but not from the current directory !
We tried different versions of java.. and do you know where this stupid problem is?
in the CLASSPATH there should be:
CLASSPATH=.;c:\programme\jboss\lib;c:\programme\
j2sdk1.4.2_08\lib;c:\programme\j2sdk1.4.2_08\jre\lib; ...
yes.. a dot .. it means, that it will search for classes bytecode in the current directory !
you can also tell java to search the current directory with the -classpath parameter
> java -classpath . Hello
public class Hello {
public static void main(String argv[]) {
System.out.println("Hello world !");
}
}
then, when you compile it:
> javac Hello.java
and want to execute it:
> java Hello
Exception in thread "main" java.lang.NoClassDefFoundError: Hello
We set the CLASSPATH and JAVA_HOME enviroment variable correctly, and the problem was still the same..
When we copied the Hello.class into a lib directory of JAVA_HOME, it worked, but not from the current directory !
We tried different versions of java.. and do you know where this stupid problem is?
in the CLASSPATH there should be:
CLASSPATH=.;c:\programme\jboss\lib;c:\programme\
j2sdk1.4.2_08\lib;c:\programme\j2sdk1.4.2_08\jre\lib; ...
yes.. a dot .. it means, that it will search for classes bytecode in the current directory !
you can also tell java to search the current directory with the -classpath parameter
> java -classpath . Hello
Thursday, October 23, 2008
Automatic rendition on import
Symptoms
When configuring the repository with automatic renditions on import, the renditions are not happening.
Cause
Register.xml is missing an entry for the PDF profile.
Resolution
Follow the steps given in Pg 26,27 in the DTS Admin Guide for configuring the automatic renditions on import. You could find the renditions are not happening. This is because you need to add one more entry to the register.xml:
1. Stop the CTS Services.
2. Edit the register.xml(System/Media Server/System Profiles).
Add this to the:
3. Back up the log folder.
4. Start the CTS.
5. Check the logs for any errors.
6. Import the document and check the renditions
When configuring the repository with automatic renditions on import, the renditions are not happening.
Cause
Register.xml is missing an entry for the PDF profile.
Resolution
Follow the steps given in Pg 26,27 in the DTS Admin Guide for configuring the automatic renditions on import. You could find the renditions are not happening. This is because you need to add one more entry to the register.xml:
1. Stop the CTS Services.
2. Edit the register.xml(System/Media Server/System Profiles).
Add this to the
3. Back up the log folder.
4. Start the CTS.
5. Check the logs for any errors.
6. Import the document and check the renditions
Sunday, October 12, 2008
How do I resolve the error, User "User_name" DOES NOT have Super User privileges
When you try to run the DocApp Installer with the ldap authentication, you may receive the error message below:
User "User_name" DOES NOT have Super User privileges.
EXPLANATION OF THE PROBLEM:
When you connect to the Docbase with the ldap authentications, you DO NOT need to specify an OS Domain Name. However, when you connect to the Docbase via DocApp Installer, you DO need to login with the user_name, Password and OS Domain name (even a dummy Domain name will work).
Your login to the Docbase via DocApp Installer with the user_name, Password and OS Domain name successes, but when you run the installer, will be NOT able to install the docapp and receive the error message above even you DO have a Super User privileges.
FIXING THE PROBLEM (ERROR):
1) Login to the Docbase via DA.
2) Select the user try to install the DocApp and go on his Properties.
3) In the attribute "Windows Domain" add the Domain name (or a dummy Domain name).
4) Save and exit.
5) Login and run the DocApp Installer again, it will work.
NOTE: You need to use the SAME Domain name to login to the DocApp Installer as the one you specified in the attribute "Windows Domain".
----------------------
Check the user_os_name: this should not be blank. it should be a valid name like 'dmadmin' then this issue will not occur
User "User_name" DOES NOT have Super User privileges.
EXPLANATION OF THE PROBLEM:
When you connect to the Docbase with the ldap authentications, you DO NOT need to specify an OS Domain Name. However, when you connect to the Docbase via DocApp Installer, you DO need to login with the user_name, Password and OS Domain name (even a dummy Domain name will work).
Your login to the Docbase via DocApp Installer with the user_name, Password and OS Domain name successes, but when you run the installer, will be NOT able to install the docapp and receive the error message above even you DO have a Super User privileges.
FIXING THE PROBLEM (ERROR):
1) Login to the Docbase via DA.
2) Select the user try to install the DocApp and go on his Properties.
3) In the attribute "Windows Domain" add the Domain name (or a dummy Domain name).
4) Save and exit.
5) Login and run the DocApp Installer again, it will work.
NOTE: You need to use the SAME Domain name to login to the DocApp Installer as the one you specified in the attribute "Windows Domain".
----------------------
Check the user_os_name: this should not be blank. it should be a valid name like 'dmadmin' then this issue will not occur
Sunday, October 5, 2008
How can I tell if the BOF Global Registry is configured correctly?
Symptoms
Need to troubleshoot the BOF user setup to allow connecting to a Global Repository/ Global Registry.
Cause
Troubles using BOF (TBOs/SBOs) or using version 6 web clients and be caused due to incomplete or incorrect configuration.
Resolution
To use BOF (TBO/SBO) requires that at least one of your Repositories be designated as the BOF Global Registry. Each Application Server must identify the BOF Global Registry it will use via the dfc.properties file.
There are two parts to setting up the BOF Global Registry:
1) making sure the "dm_bof_registry" Repository user is active.
2) making sure that the dfc.properties file on your Application Server(s) are correctly referencing the Repository that is acting as the BOF Global Registry and has the listed the correct user information for the dm_bof_registry user.
1. Verifying that a Repository is the BOF Global Registry:
===================================
-Using Documentum Administrator (DA), log into the Repository that should be the BOF Global Registry, using an administrator account.
-In Classic view, in the left navigation tree, click on the Administration node. In the page that appears, under the heading "User Management", click on "Search for Users".
-Search for the following user: 'dm_bof_registry" (enter this value next to the User Name label, and click Search).
-View the properties of this user "dm_bof_registry" (click the (i) icon).
-Make note of the user's 'State' and 'User Login Name'.
If the user State is 'Inactive', then this Repository is not the BOF Global Registry. To make this Repository the BOF Global Registry, follow Steps 2-4.
If the BOF Global Registry user is 'Active', you need to verify some information in your dfc.properties file on your Application Server(s).
From the Application Server machine, locate the dfc.properties file.
Open this file in any text editor. Ensure the following three attributes are set in the dfc.properties file:
dfc.bof.registry.repository =
dfc.bof.registry.username =
dfc.bof.registry.password =
Without the above three entries, the BOF Global Registry will not be set.
If these entries are missing or values are not complete, you will need to add and populate these values. See the following steps for more details.
2. Enabling the BOF Global Registry
===================================
The following section outlines the steps required to enable the BOF Global Registry using the Documentum Administrator (DA) application.
-Log into Documentum Administrator (DA) as an Administrator in the Repository where you want to enable TBO/SBO functionality.
-In Classic view, in the tree, click on the Administration node. In the page that appears, under the heading "User Management", click on "Search for Users".
-Search for the following user: 'dm_bof_registry" (enter this value next to the User Name label, and click Search).
-View the properties of this user 'dm_bof_registry" (click the (i) icon).
- The properties page will appear. From the properties page, ensure the following options and values are set to the following:
User State: Active
User Source: Inline Password
Restrict Folder Access: System
- For security purposes, change the default password (make a note of the new password).
- Click OK on the 'dm_bof_registry' user 'Properties' page.
3. Verifying the dfc.properties file
====================================
On each Application Server, locate the dfc.properties file. Open this file in any text editor. Ensure the following three attributes are set in the dfc.properties file:
dfc.bof.registry.repository =
dfc.bof.registry.username =
dfc.bof.registry.password =
Without the above three entries, the BOF Global Registry will not be set.
Note: The password supplied in the entry 'dfc.bof.registry.password' must be consistent with the password provided when setting the 'dm_bof_registry' password via Documentum Administrator (DA). The password must also be encrypted. For information on how to encrypt the password, see the next section in this document, entitled 'Encrypting Passwords for the dfc.properties file'.
4. Encrypting Passwords for the dfc.properties file
===================================================
The password provided in the 'dfc.properties' file must be encrypted. A utility is provided to encrypt this password. The following section outlines the steps required to invoke the password utility program to encrypt a password.
From a command prompt, execute the following:
java com.documentum.fc.tools.RegistryPasswordUtils
Note- If you are using java methods that use the TBOs/SBOs then you will need the following entries on the %DM_Home/config/dfc.properties file as well
dfc.bof.registry.repository =
dfc.bof.registry.username =
dfc.bof.registry.password =
Need to troubleshoot the BOF user setup to allow connecting to a Global Repository/ Global Registry.
Cause
Troubles using BOF (TBOs/SBOs) or using version 6 web clients and be caused due to incomplete or incorrect configuration.
Resolution
To use BOF (TBO/SBO) requires that at least one of your Repositories be designated as the BOF Global Registry. Each Application Server must identify the BOF Global Registry it will use via the dfc.properties file.
There are two parts to setting up the BOF Global Registry:
1) making sure the "dm_bof_registry" Repository user is active.
2) making sure that the dfc.properties file on your Application Server(s) are correctly referencing the Repository that is acting as the BOF Global Registry and has the listed the correct user information for the dm_bof_registry user.
1. Verifying that a Repository is the BOF Global Registry:
===================================
-Using Documentum Administrator (DA), log into the Repository that should be the BOF Global Registry, using an administrator account.
-In Classic view, in the left navigation tree, click on the Administration node. In the page that appears, under the heading "User Management", click on "Search for Users".
-Search for the following user: 'dm_bof_registry" (enter this value next to the User Name label, and click Search).
-View the properties of this user "dm_bof_registry" (click the (i) icon).
-Make note of the user's 'State' and 'User Login Name'.
If the user State is 'Inactive', then this Repository is not the BOF Global Registry. To make this Repository the BOF Global Registry, follow Steps 2-4.
If the BOF Global Registry user is 'Active', you need to verify some information in your dfc.properties file on your Application Server(s).
From the Application Server machine, locate the dfc.properties file.
Open this file in any text editor. Ensure the following three attributes are set in the dfc.properties file:
dfc.bof.registry.repository =
dfc.bof.registry.username =
dfc.bof.registry.password =
Without the above three entries, the BOF Global Registry will not be set.
If these entries are missing or values are not complete, you will need to add and populate these values. See the following steps for more details.
2. Enabling the BOF Global Registry
===================================
The following section outlines the steps required to enable the BOF Global Registry using the Documentum Administrator (DA) application.
-Log into Documentum Administrator (DA) as an Administrator in the Repository where you want to enable TBO/SBO functionality.
-In Classic view, in the tree, click on the Administration node. In the page that appears, under the heading "User Management", click on "Search for Users".
-Search for the following user: 'dm_bof_registry" (enter this value next to the User Name label, and click Search).
-View the properties of this user 'dm_bof_registry" (click the (i) icon).
- The properties page will appear. From the properties page, ensure the following options and values are set to the following:
User State: Active
User Source: Inline Password
Restrict Folder Access: System
- For security purposes, change the default password (make a note of the new password).
- Click OK on the 'dm_bof_registry' user 'Properties' page.
3. Verifying the dfc.properties file
====================================
On each Application Server, locate the dfc.properties file. Open this file in any text editor. Ensure the following three attributes are set in the dfc.properties file:
dfc.bof.registry.repository =
dfc.bof.registry.username =
dfc.bof.registry.password =
Without the above three entries, the BOF Global Registry will not be set.
Note: The password supplied in the entry 'dfc.bof.registry.password' must be consistent with the password provided when setting the 'dm_bof_registry' password via Documentum Administrator (DA). The password must also be encrypted. For information on how to encrypt the password, see the next section in this document, entitled 'Encrypting Passwords for the dfc.properties file'.
4. Encrypting Passwords for the dfc.properties file
===================================================
The password provided in the 'dfc.properties' file must be encrypted. A utility is provided to encrypt this password. The following section outlines the steps required to invoke the password utility program to encrypt a password.
From a command prompt, execute the following:
java com.documentum.fc.tools.RegistryPasswordUtils
Note- If you are using java methods that use the TBOs/SBOs then you will need the following entries on the %DM_Home/config/dfc.properties file as well
dfc.bof.registry.repository =
dfc.bof.registry.username =
dfc.bof.registry.password =
Thursday, October 2, 2008
After installing Transformation Services, I do not see a Content Transformation Services Service listed in my Services
Cause
This can be because you have not configured your docbase yet, or because you have registered the service as an invalid user.
Resolution
When you first install a Transformation Services product you will only see the Admin listed as a service. This is because you have not configured to a docbase yet. Once you run the configuration utility to add a docbase, you should see three services:
Documentum Content Transformation Monitor Service
Documentum Content Transformation Services
Documentum CTS Admin. Agent
If you do not see three services after configuring you docbase this is most likely because the user that you used when installing the Transformation Services Product was not a local Administrator, or you did not specify the domain if it was a domain user. To resolve the issue you can do one of two things:
Unconfigure and uninstall and then re-install using a local Admin and domain in necessary.
Register the service manually by running the following utility:
cmd> C:\Program Files\Documentum\CTS\server_install\CTSService\InstallLocalCTS.bat
This should register the service with the Local System account. You will then need to manually change it to run as the local admin user.
Notes:
You can start the CTS service from a bat file to see if there are any problems with the service starting.
cmd> C:\Program Files\Documentum\CTS\server_install\CTSService\startCTS.bat
Make sure you run this from the command console as you will see any error message in the terminal.
You can reference the install.log located on the same directory as the installer for more information.
You can also run the installer with the following option for more verbose information:
cmd> rptsWinSuiteSetup.exe -is:log "C:\temp\rpts_install_log_txt"
This can be because you have not configured your docbase yet, or because you have registered the service as an invalid user.
Resolution
When you first install a Transformation Services product you will only see the Admin listed as a service. This is because you have not configured to a docbase yet. Once you run the configuration utility to add a docbase, you should see three services:
Documentum Content Transformation Monitor Service
Documentum Content Transformation Services
Documentum CTS Admin. Agent
If you do not see three services after configuring you docbase this is most likely because the user that you used when installing the Transformation Services Product was not a local Administrator, or you did not specify the domain if it was a domain user. To resolve the issue you can do one of two things:
Unconfigure and uninstall and then re-install using a local Admin and domain in necessary.
Register the service manually by running the following utility:
cmd> C:\Program Files\Documentum\CTS\server_install\CTSService\InstallLocalCTS.bat
This should register the service with the Local System account. You will then need to manually change it to run as the local admin user.
Notes:
You can start the CTS service from a bat file to see if there are any problems with the service starting.
cmd> C:\Program Files\Documentum\CTS\server_install\CTSService\startCTS.bat
Make sure you run this from the command console as you will see any error message in the terminal.
You can reference the install.log located on the same directory as the installer for more information.
You can also run the installer with the following option for more verbose information:
cmd> rptsWinSuiteSetup.exe -is:log "C:\temp\rpts_install_log_txt"
Subscribe to:
Posts (Atom)