How to install DAR into Documentum repository

Documentum artifacts (jobs, methods, modules, lifecycles, custom types, etc.) are created in a Composer project and built into a DAR file, which consequently must be installed into the repository using DARDeployer (in previous versions called DARInstaller) or Composer Headless (using scripts).
Note: the Composer project artifacts can also be installed into the repository directly from Composer, by choosing Install Documentum Project... item in the context menu (right click on project): specify repository name, user name, password, domain (optional), press login, then install.

To install a DAR file, open DarInstaller (or DARDeployer in old versions) and fill the fields:
 - DAR: the DAR file to install (required)
 - Input File: the installation parameters file (file with custom installation parameters)
 - Locale Folder: Folder with localization
 - Log File: log file location (in case you don't want the default location)

Once filled these fields, select the docbroker host, enter a port number (default: 1489), press Connect to get the repositories list. Then select a repository from the list, enter user name (superuser), password and domain (optional). When ready, click the Install button. The installation process starts and once it's completed you will see a message telling the dar was installed successfully. In case of errors, you will be notified with a proper message (no changes take place as the DAR installation is done in a transaction). In this case check the logs and try to solve the issue (sometimes it might be a trivial connection lost with the CS), then reinstall the DAR file. Sometimes, before reinstalling the DAR, Data Dictionary re-publish could be necessary (using dm_DataDictionaryPublisher job or just with API command: publish_dd,c).

If you can't use DARDeployer (for ex. non-Windows OS: Linux, AIX, etc.), you can install the DAR using Composer Headless. For this, you must create 3 files:

1. darinstall (script file)
Here's a template of the script file (Linux):
#!/bin/sh

export JAVA_HOME=/opt/documentum/shared/java/1.6.0_17
export ECLIPSE=/opt/documentum/product/6.7/install/composer/ComposerHeadless
export WORKSPACE=/opt/project/darinstall-workspace
$JAVA_HOME/bin/java -Xms512m -Xmx1024m -cp $ECLIPSE/startup.jar org.eclipse.core.launcher.Main -clean -data $WORKSPACE -application org.eclipse.ant.core.antRunner -buildfile darinstall.xml

2. darinstall.xml (Ant buildfile)
<?xml version="1.0"?>
<project name="darinstall" default="install">
  <description>ant script to install a DAR file</description>
    <property file="darinstall.properties"/>
    <property name="dar.folder" value="." />
    <target name="install">
      <antcall target="_install.dar">
        <param name="dar.file" value="${dar.folder}/CustomTypes.dar" />
      </antcall>
      <!-- other dars, in order of dependency -->
    </target>
    <target name="_install.dar">
      <echo message="============================"/>
      <echo message="Installing DAR ${dar.file}"/>
      <echo message="============================"/>
      <emc.install dar="${dar.file}" docbase="${dctm.docbase}" username="${dctm.username}" password="${dctm.password}"/>
    </target>
</project>

3. darinstall.properties (configurations,credentials)
dctm.docbase=project_dev
dctm.username=dmadmin
dctm.password=dmadmin
dar.folder=/opt/project/darinstall

Now just launch the first script (darinstall), wait until it completes, then check installation logs. If you find no errors/warnings, it's done!

How to stop running job

A Documentum job consists of a dm_job object, containing job configuration, name of method to run, as well as process execution information. The job method is executed on the Content Server (if it's a java method - on the JMS). Once the job is started, there's no 'soft' approach to stop it, you can only force it.
Below are the steps to stop properly a running job, reseting also the dm_job object:
1. Get the process id, by running the DQL:
select a_last_process_id from dm_job where object_name='[JOB_NAME]'
2. Using Process Explorer (or similar tool) locate the process by id and kill it. (Or with a command like: taskkill /pid 1234)
3. Run the API command to unlock the job object:
unlock,c,[job_id]
4. Execute the following DQL queries to clear job execution-related attributes:
a) Reset application that uses/locked the job
update dm_job objects set a_special_app='' where object_name='[JOB_NAME]';
b) Reset current status
update dm_job object set a_current_status='FAILED' where object_name='[JOB_NAME]';
c) Prevent job from being run immediately
update dm_job object set run_now=FALSE where object_name='[JOB_NAME]';

Remember to change the schedule or inactivate the job if you don't want it to run automatically after specified period.
If your job is locked in running state, check here how to unlock it: How to unlock a job in running state.

Renaming users - how dm_UserRename job works

In a previous article How to change the user_name of a dm_user we've seen how to rename a Documentum user manually (using Documentum Administrator) and by DFC code.
Let's assume we want to update a set of users, but can't or don't want to write DFC code (it also requires some time to write and run the code). We have an additional option: have the dm_UserRename job rename the users automatically. But how does the dm_UserRename job work?
This job polls a queue: dm_job_request objects. The object has the following attributes which are relevant for the job:
object_name         : UserRename
job_name            : dm_UserRename
method_name         : dm_UserRename
request_completed   : F
arguments_keys   [0]: OldUserName
                 [1]: NewUserName
                 [2]: report_only
                 [3]: unlock_locked_obj
arguments_values [0]: userA
                 [1]: userB
                 [2]: F
                 [3]: F

The jobs read the arguments_keys & arguments_values values and calls the dm_UserRename method with these arguments, so the specified user is renamed with selected options (report_only mode, unlock objects or leave locked). When the operation completes, the request_completed attributed is set to TRUE.
Thus in order to rename a set of users, you need to create a dm_job_request object for each user and run the dm_UserRename job. Note that by default the dm_UserRename job is inactive, so you can either run it manually, or activate it and schedule if you often rename users.

Here's sample DQL to create a dm_job_request object (to rename 1 user):
create dm_job_request object set object_name='UserRename', set job_name='dm_UserRename', set method_name='dm_UserRename', set request_completed=FALSE, append arguments_keys='OldUserName', append arguments_keys='NewUserName', append arguments_keys='report_only', append arguments_keys='unlock_locked_obj', append arguments_values='userA', append arguments_values='userB', append arguments_values=FALSE, append arguments_values=FALSE

How to change the user_name of a dm_user

In a Documentum repository users are uniquely identified by the user_name attribute. Being a key, the user_name value is used in related objects (for example: owner, r_modifier, r_creator, r_lock_owner, etc.) stating that this user performed an action on this object.
In certain cases we need to change the user_name value: for example when we want to create a new user, but an old one (perhaps deactivated) already exists with the same user_name.
Being a key, we can't simply update this value, you won't even be able to modify it on user property screen. Here are the ways to accomplish this:

1. Manual renaming
There's a simple tool called Reassign User which invokes the dm_UserRename job (Renaming users - how dm_UserRename job works explains how this job works):
a. (Optional) Create a new user with the user_name you want to rename the old user to.
b. Open DA, go to Users node in browsertree, find the desired user, right click on it and choose Reassign User. On the opened page enter/select the new user, select the option to run the reassign job now (and change other settings if required).
c. (Optional) As soon as the dm_RenameUser job has completed, you can remove the original (old) user if it's not needed anymore.
Note that you can skip the creation of a new user and just enter the new user_name on the Reassign User page, it will handle the modification of user_name itself.

2. Automatic renaming
If we want to rename many users, the manual approach would be really annoying, so as usual we turn to some DFC coding.
Renaming users in DFC is quite straightforward, it's enough to call the rename method:
 IDfUser user = session.getUser("userA");
 user.renameUser("userB", true, false, true);
 user.save();

Here's the method description from the API:
void renameUser(String userName,
                boolean isImmediate,
                boolean unlockObjects,
                boolean reportOnly)
                throws DfException
    Renames this user. If this is a new user, the attribute value is set. If this is an existing user, this method invokes a job to rename user.
    Parameters:
        userName - user name to be set or renamed to (existing user)
        isImmediate - Detemines if the job should be run immediately or run on schedule.
        unlockObjects - control if the objects should be unlocked when renaming user. If this is a new user, this parameter does not take any effect.
        reportOnly - control if the job created is to report or actual rename. If this is a new user, this parameter does not take any effect.

How to register and unregister types for indexing

Documentum uses fulltext indexing to enable search on all document properties as well as its contents.  How does fulltext indexing work?
Indexing is performed by a dedicated server (FAST, xPlore, etc.) that polls the queue of the fulltext user. In order to index certain (sub)types of documents, you must register certain events of these types for index user. Thus when a registered event occurs on a document of the registered type, a queue item is created in the fulltext user's queue, which consequently is processed by the Fulltext indexing server, by indexing the document. The events to register are those that usually change the object metadata and/or content: dm_save,dm_readonlysave,dm_checkin,dm_move_content,dm_destroy

By default, (in previous versions of Documentum) all dm_sysobject types and its subtypes are registered for indexing. Usually you don't need all the dm_sysobject to be indexed, so before registering your custom types, you should unregister the dm_sysobject first. You can do that by running the following API script, being connected with the fulltext user (dm_fulltext_index_user):
(Note: if you don't know the password for dm_fulltext_index_user you can generate a login ticket by running following API with a superuser: getlogin,c,dm_fulltext_index_user Read more details about this trick in: How to login to the repository with a ticket).

API for unregistering indexing:
unregister,c,[TYPE_ID],dm_save,,F
unregister,c,[TYPE_ID],dm_readonlysave,,F
unregister,c,[TYPE_ID],dm_checkin,,F
unregister,c,[TYPE_ID],dm_move_content,,F
unregister,c,[TYPE_ID],dm_destroy,,F
[TYPE_ID] is the r_object_id of the dm_type object
Note: If you have more Index servers, you should have an index user for each, so run the unregister script for each user.

You can also do that by unchecking the 'Enable Indexing' checkbox on dm_sysobject type properties in DA.

You can register a custom type for indexing in 2 ways:
1. By executing the following API script, with the fulltext user (dm_fulltext_index_user):
register,c,[TYPE_ID],dm_save,,F
register,c,[TYPE_ID],dm_readonlysave,,F
register,c,[TYPE_ID],dm_checkin,,F
register,c,[TYPE_ID],dm_move_content,,F
register,c,[TYPE_ID],dm_destroy,,F

[TYPE_ID] is the r_object_id of the dm_type object
Note: If you have more Index servers, you should have an index user for each, so run the register script for each user.

2. Manually, by using DA: Open Types node in browsertree, find the desired type, open its properties and check the 'Enable Indexing' checkbox.

To check which types are currently registered for indexing, use the DQL:
select name from dm_type where r_object_id in (select distinct registered_id from dmi_registry where user_name='dm_fulltext_index_user')

JMS 6.7 SP1 error connecting to inexisting docbase

Recently I've installed Content Server 6.7 SP1 and the patch 08. When I start the Java Method Service, I find the following error in the logs:
INFO [STDOUT] (main) 10:02:37,932 ERROR [main] com.documentum.mthdservlet.MethodConfig - DfNoServersException:: THREAD: main; MSG: [DM_DOCBROKER_E_NO_SERVERS_FOR_DOCBASE]error: "The DocBroker running on host ([HOST]:1489) does not know of a server for the specified docbase ([INSTALLATION_OWNER])"; ERRORCODE: 100; NEXT: null

So it seems JMS client tries to connect to a docbase which has a name equal to the installation owner of the current docbase. Error in JMS configuration? Nope - checked all configurations, everything's correct. So what's the problem?
Ok, I checked again the stack trace and saw the problem is coming from method populateDocbaseNames of MethodConfig class, which is in mthdservlet.jar library.
Decompiled the jar, opened the method and here's the big surprise from EMC developers:
...
  String str1 = (String)localEnumeration.nextElement();
  if ((!Utils.isNull(str1)) && (str1.toLowerCase().startsWith("docbase")))
...

these lines read all the docbase names from web.xml, found in ...\ServerApps.ear\DmMethods.war\WEB-INF\
Opening the file we see the tags:
    <init-param>
      <param-name>docbase-my_docbase</param-name>
      <param-value>my_docbase</param-value>
    </init-param>

So it should read this docbase and all other available & configured repositories, the tag <param-name> having values of format 'docbase-[DOCBASE_NAME]'.
Ok, but I have only 1 repository configured. Scrolling a bit, I find another tag:
    <init-param>
      <param-name>docbase_install_owner_name</param-name>
      <param-value>dmadmin</param-value>
    </init-param>

Having the code above - startsWith("docbase") it will read also this tag and interpret it as a docbase name. Ok, then I decompiled an older version of mthdservlet.jar and found a bit different code:
  if ((!Utils.isNull(str1)) && (str1.toLowerCase().startsWith("docbase-")))

Here it is! A genious EMC developer removed that dash after docbase: startsWith("docbase-") Well, sh*t happens, even to geniuses.

So while we wait for a patch for this patch :) we can use the old version of mdthdservlet.jar or just ignore this error, as it has no impact on JMS work.

How to recover deleted document

If you want to recover an object deleted in the Documentum repository, you have big chances to recover it's content. Here you'll find the steps to recover a document content even without having many details about it.
Object metadata can be recovered only if you have a database backup, made before the deletion.
Anyway, usually the most important thing is the content itself, not the metadata, so we'll focus on the procedure of recovering the content of removed document.

The first and most important thing to do is to disable the dm_DMClean job, which cleans up orphaned objects, including the content ones. Check the job last execution time: if it ran after the document was deleted, I'm sorry - the content is lost (well, if you have both DB & content backup you can recover anything you want).
Also check the job dm_DMFileScan, usually it's disabled, if it's enabled you'd better disable it untill you recover your document.

Next, our task is to find the dmr_content object which has information about the content location.
As there might be thousands of orphaned content objects, try to get as much information as possible about the deleted document:
1) Date/time of deletion and user who deleted the document
2) Date/time of creation / last modification of content (checkin)
3) File format, aprox. size, object name

The query to get the content objects having no associated metadata objects (dm_sysobject) is:
select * from dmr_content where any parent_id is null

The problem is this query most probably will give you too many results, but I guess you don't want to find the right document when you reach 65 years :)

Now let's see how this information can help you to narrow the results:
1) Date/time of deletion and user who deleted the document
Hoping you have auditing enabled, you can get some information from this audit:
select * from dm_audittrail where event_name='dm_destroy' where time_stamp > date('some date before deletion') and user_id = (select r_object_id from dm_user where user_name='USER_WHO_DELETED')

From the results returned, if you find a record that seems to represent the deleted document, grab the object_name value

2) Date/time of creation / last modification of content (checkin):
select r_object_id,full_format from dmr_content where any parent_id is null and set_time > date([time before creation]) and set_time < date([time after creation])

3) File format, aprox. size, object name (possibly grabbed at step 1):
select r_object_id,full_format from dmr_content where any parent_id is null and full_format='[FORMAT]' and content_size > [MIN_SIZE] and content_size < [MAX_SIZE] and set_file like '%[OBJECT NAME]%'

Note: You can combine filters from point 2 & 3 if you have this information. The more filters you use, the less results you'll have.

Ok, so now you have a list of content objects (hopefully not too big). Now you can get corresponding paths to the files, on the file storage.
For each id in the list generate a DQL command:
execute get_path for '[ID]'
where [ID] is the r_object_id of dmr_content object

Executing the obtained script you get a list of file paths. Copy the results to a file.
Now you have 2 options to getting the files:
1) You can get the content files directly (without creating objects in repository), by obtained paths. Generate a script that will copy all the files to your folder. For example, you can use commands like:
cp [OBTAINED PATH] /target_folder/[COUNTER].[FULL_FORMAT]

where COUNTER is a counter (1..n) - to not have name conflicts during the copy operation.

2) Create new objects in the docbase by generating a DQL with queries like:
create my_type object set object_name='Some identifier', link '[Folder path]', setfile '[PATH]' with content_format='[FORMAT]'

If you recovered more documents, you can open them and find the one you were searching for.
Once you're happy with having recovered the deleted document, don't forget to enable back the dm_DMClean job if you disabled it.

How to delete a Documentum repository

For many years the repository served us truly and faithfuly, but the time has come... and we don't need it anymore.
Yes, we will delete it! Unfortunately it's not such trivial as running a single wizzard.
Below are the steps to do a complete removal:

0. Check one more time you're deleting the right repository (and it's not live production) :)

1. Drop (uninstall) the Index Agent
1.1 Stop the Index Agent (from DA or Index Admin page)
1.2 On the Index Server host Start the Index Agent Configuration Program, select 'Delete Index Agent', then select the Index Agent (if you have more).
1.3 From Index Server Admin page (ie: http://localhost:16000/admin) delete the corresponding collection for the docbase.

2. Remove DTS / ADTS service from the repository
2.1 Start the ADTS Configuration Utility. Check that your docbroker and docbase are running before proceeding.
2.2 Choose 'Remove an instance of ADTS from a docbase', then select the repository, enter installation owner credentials and finish the procedure.

3. Stop any other applications or/and services that are using the repository

* If you don't know the content files location, check it now before removing the repository (dm_location object)

4. Remove the docbase service
4.1 Launch Documentum Server Manager, on Utilities tab click Server Configuration and following the wizzard instructions.
4.2 Choose Custom configuration, Delete an existing repository, choose the repository and complete the procedure.

5. Delete DB tablespace(s) and schema.

6. Delete docbase files from the Content Server host
6.1 Delete the content files
6.2 Delete the log files

Congratulations! You've done it! Next repository? :)

How to clone a Documentum repository

Why cloning a Documentum repository? Well sometimes it is required to perform some tests (new software/versions/features) on the real production data. Development environment might not be very relevant because usually it has a very reduced set of data. There might be also plenty of other reasons.
Cloning a repository means creating an identic copy of it, with no impcat on the original repository.
This activity is not trivial and requires more steps to be performed:
* Note: The supposed OS is Windows, for other OS some steps might require appropriate changes.

1. Create a new DB schema and clone the data from the schema of the repository.
2. Stop the repository service.
3. Copy the content and configuration files from the source Content Server file system. On Windows you can use the robocopy command, like this:
robocopy [SOURCE_PATH] [DESTINATION_PATH] /NP /MIR /SEC /R:10 /W:10 /LOG:[LOG_FILE] >> [OUTPUT_FILE]

 Copy the following paths:
  a) [DOCUMENTUM]\dba\config\[repository_name]
  b) [DOCUMENTUM]\dba\auth\[repository_name]
  c) Folder with content files (obtain it from the dm_location object)

4. Execute the SQL script (on the new DB schema):
-- Set the clone host name
update dm_server_config_s set r_host_name='[NEW_HOST]';
update dm_mount_point_s set host_name='[NEW_HOST]';
update dm_server_config_s set web_server_loc='[NEW_HOST]';

-- Force server to recreate views
update dm_type_s set views_valid = 0;

-- Set the clone content location
update dm_location_s set file_system_path='[CONTENT_PATH_NEW]' where file_system_path='[CONTENT_PATH_OLD]';
update dm_location_s set file_system_path='[CONTENT_PATH_NEW]\replicate_temp_store' where 
file_system_path='[CONTENT_PATH_OLD]\replicate_temp_store';
update dm_location_s set file_system_path='[CONTENT_PATH_NEW]\replica_content_storage_01' where file_system_path='[CONTENT_PATH_OLD]\replica_content_storage_01';
update dm_location_s set file_system_path='[CONTENT_PATH_NEW]\content_storage_01' where file_system_path='[CONTENT_PATH_OLD]\content_storage_01';
update dm_location_s set file_system_path='[CONTENT_PATH_NEW]\thumbnail_storage_01' where 
file_system_path=' [CONTENT_PATH_OLD]\thumbnail_storage_01';
update dm_location_s set file_system_path='[CONTENT_PATH_NEW]\streaming_storage_01' where file_system_path='[CONTENT_PATH_OLD]\streaming_storage_01';

-- Set job server execution
update dm_job_s set target_server='[DOCBASE_NAME].[DM_SERVER_CONFIG.OBJECT_NAME]@[HOST]' where target_server = '[DOCBASE_NAME_OLD].[DM_SERVER_CONFIG.OBJECT_NAME_OLD]@[HOST_OLD]'

-- Note: If the cloned repository was served by more CS instances (so more dm_server_config objects present) you must run a query like this per each server config object.
-- The value [DM_SERVER_CONFIG.OBJECT_NAME] can be obtained with this query: select object_name from dm_server_config

-- Disable the jobs (will be reactivated later)
update dm_job_s set is_inactive=1;

-- ACS config: assuming the repository is served by 2 CS
update dm_acs_config_r set acs_base_url='http://[NEW_HOST]:[[PORT]/ACS/servlet/ACS' where acs_base_url in ('http://[OLD_HOST_1]:[PORT]/ACS/servlet/ACS', http://[OLD_HOST_2]:[PORT]/ACS/servlet/ACS') ;
-- PORT: default is 9080

-- Reset the crypto key
update dm_docbase_config_s set i_crypto_key = ' ', i_ticket_crypto_key = ' ';
delete from dmi_vstamp_s where i_application = 'dm_docbase_config_crypto_key_init';
delete from dmi_vstamp_s where i_application = 'dm_docbase_config_ticket_crypto_key_init';

delete dm_sysobject_s where r_object_id = (select r_object_id from dm_public_key_certificate_s where key_type = 1);
delete dm_sysobject_r where r_object_id = (select r_object_id from dm_public_key_certificate_s where key_type = 1);
delete dm_public_key_certificate_s where key_type = 1;

delete dm_sysobject_s where r_object_id = (select r_object_id from dm_cryptographic_key_s where key_type = 1);
delete dm_sysobject_r where r_object_id = (select r_object_id from dm_cryptographic_key_s where key_type = 1);
delete dm_cryptographic_key_s where key_type = 1;

-- Old fast index configuration cleanup (if FullText is installed)
update dm_ftengine_config_r set param_value='[FULLTEXT_HOST]' where param_name='fds_config_host';
update dm_ftengine_config_r set param_value='[FULLTEXT_HOST]' where param_name='query_engine_host_name';

delete from dm_ftindex_agent_config_s;
delete from dm_sysobject_s where r_object_type=’dm_ftindex_agent_config’;

-- Old ADTS configuration cleanup (if ADTS is installed)
delete from cts_instance_info_s;
delete from cts_instance_info_r; (16 row deleted)
delete from dm_sysobject_s where r_object_type=’cts_instance_info’;

commit;

5. Content Server update

5.1 Update server.ini
Edit the server.ini file located in %DOCUMENTUM%\dba\config\[DOCBASE_NAME] and update the following fields:
database_conn [NEW_DB_INSTANCE]
[DOCBROKER_PROJECTION_TARGET]
host = [NEW_DOCBROKER]
port = 1489

5.2 Re-encrypt the Database password
cd %DM_HOME%\bin
dm_encrypt_password -docbase [NEW_DOCBASE_NAME] -rdbms -encrypt [DB PASSWORD]

5.3 Windows service.
Execute the following commands script to create the Windows Service for the repository (you can save it in a .bat file and run it):
@echo off
setlocal

set docbase=[DOCBASE_NAME]
set instowner=[INSTALLATION_OWNER]
set iodom=[DOMAIN]
set iopw=[PASSWORD]

set binPath=%DM_HOME%\product\[VERSION]\bin\documentum.exe -docbase_name %docbase% -security acl -init_file E:\Documentum\dba\config\%docbase%\server.ini -run_as_service -install_owner %instowner% -logfile E:\Documentum\dba\log\%docbase%.log

sc create DmServer%docbase% binPath= "%binPath%" start= demand DisplayName= "Documentum Docbase Service %docbase%" obj= %iodom%\%instowner% password= %iopw%

sc description DmServer%docbase% %docbase%_clone

endlocal

5.4 Add port numbers
Edit %WINDIR%\system32\drivers\etc\services and add the following entries at the end of the file:
dm_[DOCBASE_NAME] [N]/tcp #Documentum Docbase Service [DOCBASE_NAME]
dm_[DOCBASE_NAME]_si [N+1]/tcp #Documentum Docbase Service [DOCBASE_NAME] (secure service)

* where N can be the incremented last port used in the list

5.5 Windows Registry update

Export the docbase registry key from the Windows registry on the old machine, from branch:
"HKLM\SOFTWARE\Documentum\DOCBASES\[DOCBASE]"

Open the exported file and update the following keys:

"DM_DOCBASE_CONNECTION" => "[DB_INSTANCE]"
"DM_HOME" => "[PATH]\\product\\[VERSION]" (ie: C:\\Documentum\\product\\6.7)
"DOCUMENTUM" => "[DOCUMENTUM_PATH]" (ie: C:\\Documentum)
Save the file with UTF-8 encoding.

Update the registry on the target machine by importing the reg file.

5.6 Create session logs folder:
[DOCUMENTUM]\dba\log\[DOCBASE]

6. Start the repository service

7. Post-cloning activities

7.1 Reset the inline passwords
Inline passwords must be reset (usualy they are not working anymore because of encryption changes)
Use a DQL like this:
update dm_user objects set user_password=user_name where user_source='inline password' [AND user_name not in (exception_list)]

or provide an explicit list of users:
update dm_user objects set user_password=user_name where user_name in (update_list)
Usualy update_list contains users: dm_bof_registry, dm_fulltext_index_user, dmc_wdk_presets_owner and others.

7.2 Install other required products: Index Agent, ADTS instance, etc.

How to change a job's scheduled run time

Even if you have changed the scheduled time for a job to run (using DA, on the job properties, schedule tab), you will notice the the job continues to run at the old time.
What's wrong? Let's have a look behind the curtains!
The agent_exec pols the a_next_invocation attribute of the dm_job object to determine when the job should run next.
In fact, when you update the job schedule, this attribute is not updated (it is when the job runs). So, you have to update it manually and the 2 options are:

1. API (using DA or other client):
retrieve,c,dm_job where object_name='[JOB_NAME]'
set,c,l,a_next_invocation
04/09/2012 19:00:00
save,c,l
2. DQL:
update dm_job object set a_next_invocation=DATE('04/09/2012 19:00:00','mm/dd/yyyy hh:mi:ss') where object_name='[JOB_NAME]'

If your changes had no effect, perhaps you have to reinitialize the Content Server process (thread). Use the following API command for that:
reinit,c

How to restart the Documentum ADTS (CTS) services

The Documentum ADTS (Advanced Document Transformation Services) is a suite of services (which analyse and transfrom repository content) that must be restarted in a defined order.

Below is the correct way to restart the ADTS services:

Change the startup type to 'Disabled' and stop the services:

1. Adlib Exponent Connector

2. Adlib Exponent Manager

3. Adlib FMR

4. Adlib Express Server

5. Documentum Content Transformation Monitor Service

6. Documentum CTS Admin. Agent

7. Documentum Content Transformation Services

8. Clean the DFC cache (for ex: DM_HOME\dfcdata\cache)

Change the startup type to 'Auto' (or Manual) and start the services:

9. Change startup type to manual for Adlib FMR

10. Adlib Express Server (the Adlib FMR service will start automatically)

11. Adlib Exponent Manager

12. Adlib Exponent Connector

13. Documentum Content Transformation Services

13* Check the logs (mainly CTS_log.txt and AdvancePDF_log.txt)

14. Documentum Content Transformation Monitor Service

15. Documentum CTS Admin. Agent

How to restart correctly the repository (Content Server services)

A typical Content Server contains 3 types of services: Docbroker, Docbase and JavaMethodServer. The correct restart procedure is:

Change the startup type to 'Disabled' and stop the services:

1. JMS service

1a Check for java.exe process (use ProcessExplorer): if found, ensure it's related to JMS and kill it (sometimes it hangs and doesn't terminate when you stop JMS).

2. Docbase(s) service(s) (if there are more than 1 Docbase, stop them one by one, the global repository must be the last).

3. Docbroker(s) service(s).

4. Clean the JMS cache ([JBOSS]\server\DctmServer_MethodServer\work\) and DFC(BOF) cache (DM_HOME\dfcdata\cache)

Change startyp type to 'Auto' (or Manual) and start the services:

5. Docbroker(s)

6. Docbases (if you have more, start the global repository first, then the others)

6a Check each started docbase log for errors

7. JMS

7a Check JMS logs ([JBOSS]server\DctmServer_MethodServer\log): boot.log and server.log

Change repository owner password in Documentum

If the Database user password used for the Documentum repository is modified, you can update it accordingly in Content Server by following the steps:

1) Stop the repository service(s) (and all dependant services, ie: app servers)

2) Go to $DM_HOME/dba/config/

3) Create a copy of the file dbpasswd.txt

4) Edit the dbpasswd.txt and replace the old (encrypted) password with the new password, as plain text (not encrypted)

5) Save dbpasswd.txt

6) Go to $DM_HOME/bin and run the following command: dm_encrypt_password -docbase -rdbms -encrypt

7) Open the dbpassword.txt file (created at step 4-5) and check if the password has been encrypted

8) Restart repository service(s) (and other dependant services)

9) Check the repository log if it started successfully

Configure the second Content Server for the repository

If you have a multiple-Content Server Documentum Infrastructure, you should install and configure manually the second Content Server instance. Assuming the first (main) CS is already installed and configured, below are the steps to install manually the second one (no wizzard). Ensure it will be on a different host machine (you can use a virtual one if you don’t want to buy a new box ;) ).

1) Connect to the repository as the installation owner by using Documentum Administrator and create a new server config object (below sample values):

Name: CS_NAME_LB1

Web server location: [server name of the CS Workstation]

Web server port: 80

Locale name: en

Default client codepage: ISO_8859-1

Server OS codepage ISO_8859-1

SMTP server [smtp_dns]

Workflow Content

Migration Threads: 10

Maximum Login Ticket 43200

Default Login Ticket 5

* Set other settings to fit the first config object.

Update the owner name for the new created object using the DQL

update dm_server_config objects set owner_name = '[docbase_owner]' where bject_name='[object_name]'

Disconnect from the repository

2) Create a server.ini file for the new Content Server

Create the folder [docbase_name] in the following path on the new Content Server:

…\Documentum\dba\config

Copy in this folder ([docbase_name]) the server.ini file from the first Content Server, for this repository.

Change the server_config name

server_config_name = CS_NAME_LB1

and the docbroker configurations

[DOCBROKER_PROJECTION_TARGET]

host = [docbroker2]

port = 1489

[DOCBROKER_PROJECTION_TARGET_1]

host = [docbroker1]

port = 1489

proximity = 100

* if additional projections required (add as many as required):

[DOCBROKER_PROJECTION_TARGET_2]

host = [docbroker3]

port = [port]

3) Create the repository Windows service by running the following command file:

@echo off

setlocal

set docbase=[docbase_name]

set instowner=[installation_owner_user]

set iodomain=[domain]

set iopass=[password]

set binPath=E:\Documentum\product\6.5\bin\documentum.exe -docbase_name %docbase% -security acl -init_file E:\Documentum\dba\config\%docbase%\server.ini -run_as_service -install_owner %instowner% -logfile E:\Documentum\dba\log\%docbase%.log

sc create DmServer%docbase% binPath= "%binPath%" start= demand DisplayName= "Documentum Docbase Service %docbase%" obj= %iodomain%\%instowner% password= %iopass%

sc description DmServer%docbase% %docbase%_clone

endlocal

5) Configure port numbers

Edit C:\WINDOWS\system32\drivers\etc\Services file and add the following entries at the end of the file:

dm_[docbase_name] [prev+1]/tcp #Documentum Docbase Service [docbase_name]

dm_[docbase_name]_s [prev+1]/tcp #Documentum Docbase Service [docbase_name] (secure service)

6) Update the windows registry

* sample values used, set the ones from your system

[HKEY_LOCAL_MACHINE\SOFTWARE\Documentum\DOCBASES\[docbase_name]]

"DM_CONFIGURE_STATUS"=hex(2):43,00,6f,00,6d,00,70,00,6c,00,65,00,74,00,65,00,\ 00,00

"DM_AUTH_LOCATION"="[domain]"

"DM_DATABASE_NAME"=""

"DM_DOCBASE_CONNECTION"="[DB_TNS]"

"DM_DATABASE_USER"="[docbase_name]"

"DM_DATABASE_ID"="db_id"

"DM_SERVER_VERSION"="6.5 SP2"

"DM_HOME"="E:\\Documentum\\product\\6.5"

"DM_CONFIGURE_TIME"="Fri Jan 14 12:34:00 CET 2011"

"DM_SERVICE_NAME"="[service_name]"

"DM_RDBMS"="Oracle"

"DOCUMENTUM"="E:\\Documentum"

7) Copy the dbpasswd.txt and webcache.ini file from first CS to second CS, in following path:

…\Documentum\dba\config\[docbase_name]

8) Create the folder for the session log files

…\Documentum\dba\log\[docbase_name]

9) Start the docbase services on both content servers

10) Using DA create the dm_LogPurge_LB1 job, as a clone of dm_LogPurge. Set as designated server the second CS (the one installed now). Set other settings similar to original LogPurge job (method, arguments, etc.).

11) Advice: in a multiple-CS environment, it is recommended to set a designated server for each job (otherwise it can happen a job is started simultaneously on 2 CS). User job sequences, if necessary.

12) Create the ACS object for the second Content Server

dmbasic -fE:\Documentum\product\6.5\install\admin\dm_acs_install.ebs -eInstall – [docbase_name].[CS_name] [install_owner] [password] [server_host_name]ACS1 [CS_name] 9080 http F "" ]dm_acs_install.log

Update the acs.properties file with the newly created ACS object by adding in the properties file

…\[method_server_path]\deploy\acs.ear\APP-INF\classes\config\acs.properties

the entries for the new created object:

repository.name.i=[docbase_name].[CS_name]

repository.login.i=[install_owner]

repository.password.i=[password]

repository.acsconfig.i=[acs_config_object_name]

* i – number not used yet in this file settings

13) Start the JMS.

Test and enjoy!