Archive for October, 2010

Changing the Installation owner in Documentum

October 30, 2010 Comments off

Although changing the installation owner is not recommended in Documentum but when need demand you can try the below steps to change the installation owner:

1. Log in as the Windows NT system administrator.

2. Stop Services for all Docbases and the DocBroker.

3. Edit the install_owner parameter in the server.ini file for each Docbase in the installation to reference the new installation owner.

a. The server.ini file is found in %DOCUMENTUM%\dba\config\Docbase_name\server.ini.

4. Change permissions on the data, dba, product, and share subdirectories under the eContent Server installation root directory (%DOCUMENTUM%). For each directory:

a. In Explorer, select the directory.

b. Right click to display a menu; choose Properties from the menu.

c. Select the Security tab on the Properties dialog box.

d. Click Permissions to display the Directory Permissions dialog box.

e. Click Add to add the new installation owner to the list of those with permissions on the directory.

f. You will be asked for the new owner’s domain.

g. Give the new owner Full Control permission.

h. Check “Replace Permissions on Subdirectories” and “Replace Permissions on Existing Files”.

i. Remove the old installation owner from the list of those with access permission on the directory.

j. Click OK.

5. If your content storage directories are not located under the %DOCUMENTUM%\data directory, change the permissions on each content storage directory also. Use the procedure in Step 4 to change their permissions.

6. Edit the Registry to reflect the change in ownership:

a. In the following key:


i. Change the value of DM_DMADMIN_USER to the new owner.

ii. If needed, change the value of DM_DMADMIN_DOMAIN to the domain of the new owner.

b. In the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DmServer Docbase_name

Change the –install_owner parameter in the value for ImagePath to the new owner.

7. For each Docbase in the installation, use regedt32 to change the security permissions on the following Registry keys:

a. HKEY_LOCAL_MACHINE\SOFTWARE\Documentum\Docbases\Docbase_name

b. HKEY_LOCAL_MACHINE\SOFTWARE\Documentum\Server\version_no

c. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\Documentum

d. For each key:

I. Select the key and right click to display a menu.

II. Choose Security .Permissions.

III. Add the new installation owner user with Full Control

IV. Remove the old installation owner.

8. For each Docbase, set the appropriate start-up information:

a. Choose Control Panel .Services.

b. Select the Service: Documentum Docbase Docbase_name

c. In the Startup dialog, enter the new owner and the owner’s password under Log On As: This Account.

9. Move the Documentum-related Program Items in Start menu to the new owner.



Documentum Docbase Docbase_name


WinNT\Profiles\old_owner\Start Menu\Programs\


WinNT\Profiles\new_owner\Start Menu\Programs\

10. Update the r_install_owner and r_install_domain in the server_config object to reflect the new installation owner.

11. Restart Windows NT

What does Documentum recommend about deleting users?

October 28, 2010 Comments off

Every SysObject or SysObject subtype in the Docbase has an attribute called owner_name that identifies the user who owns the object. Its better to  deactivate the  users, rather than deleting them based on the following issues:

  1. Before deleting a user from a Docbase, you must update the objects created by the deleted user to change the owner_name to identify a different user. You do not need to change the owner_name if you deactivate the user.
  2. When you delete a user, the server does not remove the user’s name from objects in the Docbase such as groups and ACLs. It is possible to delete a user, and then re-create the user with the same name. However, if you add a new user with the same name as a previously deleted Docbase user, the new user will inherit the group membership and object permissions of the previously deleted user.
  3. You cannot delete the Docbase owner, installation owner, or yourself.
  4. When you no longer need a user account, deactivate the user. Deactivating a user is better than deleting a user. Once a user is deactivated in a Docbase, that user will not be able to log in to that Docbase. You must have Sysadmin or Superuser privileges to deactivate or reactivate a user.
  5. You cannot change the login state of the Docbase owner, installation owner, or yourself. You deactivate and reactivate users by changing the user’s login state using Documentum Administrator, DQL or the API.
  6. By default, users are active when you create them, so you do not need to activate new users. The user’s login state is tracked by the user_state attribute of the dm_user object. If you deactivate a user who is currently logged in, the change takes affect when the user next logs in.
  7. If necessary, a user with Superuser privileges can use a ticket to log in as a deactivated user, and a user with Superuser privileges can add a deactivated user to a group.

Feel free to add/correct points. Appreciate your comments.

Including ExtJS in your Pages

October 28, 2010 Comments off

How to use ExtJS in our Screens/Pages ?

Before we can use Ext in our pages, we need to reference the Ext library files. To do this, we need to include a few of the files provided in the SDK download in the HEAD portion of our HTML page.
<link rel=”stylesheet” type=”text/css” href=”lib/extjs/resources/css/ext-

all.css” />
<script src=”lib/extjs/adapter/ext/ext-base.js”></script>
<script src=”lib/extjs/ext-all-debug.js”></script>
<!– Nothing in the body –>


The path to the Ext files must be correct and is relative to the location of our HTML file. These files must be included in the following order:

  1. ext-all.css: The main Ext CSS file.
  2. An external js library file, if needed .
  3. ext-base.js: The Ext ‘adapter.
  4. ext-all.js or ext-all-debug.js: The primary ExtJS library file
  5. A theme file could also be included here, after the main ExtJS CSS file.


Benefits of WCMS and When to choose WCMS

October 27, 2010 Comments off

A Web Content Management System or any CMS supports the following benefits:

Ø  Import and creation of documents and multimedia material

Ø  Identification of all key users and their content management roles

Ø  The ability to assign roles and responsibilities to different content categories or types.

Ø  Definition of the content workflow tasks, often coupled with event messaging so that content managers are alerted to changes in content.

Ø  The ability to track and manage multiple versions of a single instance of content.

Ø  The ability to publish the content to a repository to support access to the content. Increasingly, the repository is an inherent part of the system, and incorporates enterprise search and retrieval.

Ø  Some content management systems allow the textual aspect of content to be separated to some extent from formatting. For example the CMS may automatically set default color, fonts, or layout.


But When one can Choose a WCMS , i could list out few of the scenarios where we can go for WCMS :

1. If you are publishing a lot of content from a number of authors, and yet the content are to be published in the single format (eg. Portal for a world wide reputed company) you should consider a Web Content management system (WCMS).  It can allow you to manage your content efficiently and cost-effectively.

2. When you have resources who are non – technical editors (not strong HTML, programming), you can consider WCMS as it allows to create, edit and publish content on a website.

3. When the published contents needs frequent edition or updation we can consider WCMS as this tool makes it easier to update a content and also to maintain the old version of the content.

4. When you want to publish large volumes of data or web pages in a short span of time you can consider WCMS. This is an important issue for the modern organization. The quicker you get key content published, the more value it creates.

Categories: WEB-CMS Tags: , ,

General terminologies used in WCMS

October 27, 2010 Comments off

Below i tried to list out some of the General terminologies used in WCMS:

Site:Used to group a set of Site Areas and Content.

Site Area: Used to build the Site Framework within which content items are grouped.

Authoring Template: Defines what data entry fields appear when creating new Content. Default values can also be entered into an Authoring Template.

Presentation Template: Specifies the design of a displayed page, including the layout of Components in a page and the default properties of a page (background, font, etc.). Presentation Templates allow you to change the look of a page without having to update what is being displayed on a page.

Components: Components are the building blocks of a Web Content Management environment. They either store content that can then be referenced in another Web Content Management item (e.g., Text Component, Image Component), or generate content based on selected parameters (e.g., Menus, Navigators).

Personalization Component: References content based on Web Sphere Portal Personalization rules and displays the content as Web Content Management Components.

Taxonomy and Categories: A Category refers to the subject matter of your content, i.e., what your content is about. For example, your news content may be of the category “Sports”, “Travel”, or “Entertainment”. Categories can be used to determine what links will display in a menu. Categories are grouped within Taxonomies.

Workflow: controls access to, verification and eventual approval of Web Content Management Items. Only if an item is approved at all stages up to a published stage can it be viewed on your web site.

%d bloggers like this: