Sunday, March 23, 2008

Why do I have lots of ACLs in my docbase and how do I remove them?

Why do I have lots of ACLs in my docbase and how do I remove them?


If you believe that you have too many ACLs and they are causing the problem, please read this Support Note.

Background:
Internal ACL vs Named ACL:
- A named ACL is an ACL that was created by an administrator or a user in the docbase. The attribute owner_name of this ACL will show a user name. For example, owner_name: dmadmin
- Internal ACLs are automatically generated by the docbase, and they have a computer generated name, such as dm_. For example dm_4500123480000101


What are the implications of having too many ACLs?
A large number of ACLs in your docbase is difficult maintain. Also, having too many internal ACLs may reveal an incorrect set up: If your business process is correctly implemented and set up, there should be very few occasions when internal ACLs are being generated.


How are Internal ACLs created? ……………….
Every dm_sysobject object in the docbase has an ACL assigned to it. Depending on the ACL inheritance of the serverconfig object, you can set how new objects get their ACL.

There are 4 ways where you can set an ACL to a particular object:
1. user
If your serverconfig is set to use "user", then every time the user creates a new object, this object will get the same ACL values as the user's default ACL.

2. folder
In a "folder" mode, the object gets its ACL from the folder where it is created.

3. type
Using "type" mode, default ACL of the type is being used to set the values of the newly created object's ACL.

4. permission set templates
You can use permission set template to set the ACL of an object. The requirement for permission set template is that the Server needs to be able to resolve any alias sets that might be related to the Permission Set Template. See Documentum eContent Server Object Reference Manual version 4.2 under (Alias Scope) page 1-26.


How do I find out the number of ACLs in my docbase?
1. Total ACLs:
DQL> select count(*) as Total_Number_of_ACLs from dm_acl

2. For Named ACLs created by users or the system administrator, you can run:
DQL> select count(*) as Number_of_Named_ACLs from dm_acl where r_is_internal=0 and acl_class = 0

3. For Template ACLs, you can run:
DQL> select count(*) as Number_of_Template_ACLs from dm_acl where r_is_internal=0 and acl_class <> 0

4. For Internal ACLs, you can run:
DQL> select count(*) as Number_of_Internal_ACLs from dm_acl where r_is_internal=1 and acl_class = 0

5. For Internal ACLs created from Template ACLs, you can run:
DQL> select count(*) as Number_of_Internal_ACLs_From_Template from dm_acl where r_is_internal=1 and acl_class <> 0

You should have:
#1 = #2 + #3 + #4 + #5

There is a good chance that the number of Internal ACLs (query #4 above) is high and represents more than 95% of the total number of ACLs in the docbase (query #1). Those are the ACLs that we can get rid of. Also, once your docbase is properly set up, no new Internal ACLs should be created any more.

For more information on those topics, please refer to the eContent Server documentation.

***********### IMPORTANT ###***********
Before going further in the resolution, we assume that you understand:
- DQL queries
- ACL model in Docbase
***************************************


==[ Step A ]=============================
Find out which Default ACL Mode the Docbase is currently using, then identify the folders / type / users which are using an Internal ACl and change it to a Named ACL so that the docbase stops generating Internal ACLs.

A.1. First, run the following query to find out what Default ACL the docbase is using:
DQL> select default_acl as Default_ACL_Mode from dm_server_config where object_name=''

A.2. The result should be 1, 2 or 3 but regardless of the result, we suggest that you go through all the steps A.2.1, A.2.2 and A.2.3. The reason is that you want to remove all references to Internal ACls that folders or types or users may have.

A.2.1 If Default ACL mode is 1 (Folder):
Retrieve all the folder names which have an Internal ACL:
DQL> select r_object_id, acl_name, acl_domain, object_name from dm_folder where acl_name like 'dm_45%'

Update the ACLs of all folders that have Internal ACLs to your Named ACL.
DQL> update dm_folder objects set acl_name = '', set acl_domain = '' where acl_name like 'dm_45%'

Note: 'your docbase name' is the name of the docbase and 'your system ACL' is the name of a system ACL that you want to use as the default ACL. A system ACL is a Named ACL owned by the system administrator which can be shared across users.

Note: You need to update the acl_domain also if you want to update the acl of an object.

Note: We strongly recommend that you use a Named ACL that is owned by System. The reason is because you want to easily share this Named ACL with other users.


A.2.2 If Default ACL mode is 2 (Type):
Retrieve the default ACL and the owner name of the ACL for object types if the types have an Internal ACL associated with them:
DQL> select r_type_name, acl_name, acl_domain from dmi_type_info where acl_name like 'dm_45%' or acl_name = ' '

Update the ACLs of all types that using an Internal ACL or are don't have an ACL assigned and are subtypes of dm_sysobject by using Documentum Administrator interface. No DQL query is available for this task since dmi_type_info is an internal type.


A.2.3 - If Default ACL mode is 3 (User):
Retrieve all users (and groups) that are using an Internal ACL:
DQL> select r_object_id, user_name, acl_name from dm_user where acl_name like 'dm_45%'

Assign a named ACL to those users (and groups):
DQL> update dm_user objects set acl_name = '', set acl_domain = '' where acl_name like 'dm_45%'

Note: 'your docbase name' is the name of the docbase and 'your system ACL' is the name of a system ACL that you want to use as the default ACL. A system ACL is a Named ACL owned by the system administrator which can be shared across users.

Note: Make sure you update the acl_domain together with the acl_name. If the acl that you are assigning is not part of the current acl_domain, the server will return an error.

Note: We strongly recommend that you use a Named ACL that is owned by System acl_domain= rather than acl_domain=

The reason is because you want to easily share this Named ACL with other users and this is only possible if the ACL is owned by System.

===[ Step B ]=======================
At this point, you docbase should not generate new Internal ACLs. However, existing objects may be using an Internal ACL. This step helps you indentify those objects and change the Internal ACL to a Named ACL. This step is required before attempting to remove Internal ACLs.

B.1 - Retrieve all objects (content and folders) across the docbase that are using an Internal ACL:
DQL> select count(*) from dm_sysobject (all) where acl_name like 'dm_45%' and acl_name not like 'dm_45%\_8%' ESCAPE '\'

If you need to review those objects one by one:
DQL> select r_object_id, object_name, acl_name, acl_domain from dm_sysobject (all) where acl_name like 'dm_45%' and acl_name not like 'dm_45%\_8%' ESCAPE '\'

B.2 - Assign your Named ACL to all objects (content and folders) across the docbase that have Internal ACL:
DQL> update dm_sysobject (all) objects set acl_name='', set acl_domain='' where acl_name like 'dm_45%' and acl_name not like 'dm_45%\_8%' ESCAPE '\' and r_lock_owner is NULLSTRING

Note: 'your docbase name' is the name of the docbase and 'your system ACL' is the name of a system ACL that you want to use as the default ACL. A system ACL is a Named ACL owned by the system administrator which can be shared across users.

Note: Only the contents that are not checked out will be updated. You may want to run this query periodically until no contents get returned from the queries in B.1

Note: You can refine the query so that only a subset of those objects get a Named ACL - per folder or creation date for instance.

Note: Make sure you update the acl_domain together with the acl_name. If the acl that you are assigning is not part of the current acl_domain, the server will return an error.

Note: We strongly recommend that you use a Named ACL that is owned by System (acl_domain= rather than acl_domain=). The reason is because you want to easily share this Named ACL with other users and this is only possible if the ACL is owned by System.

Note: This query may take quite some time to run. In fact, the update statement may update so many objects at the same time that your database may run out of TEMP tablespace causing the query to fail. You may want to modify the query to modify a limited number of objects at the same time - by restricting per folder or creation date.

Note: You may not be able to update non-CURRENT objects if they are immutable. If this is your case, the query will return error DM_SYSOBJECT_E_CANT_SAVE_IMMUTABLE. In order to resolve this issue, you can take the '(all)' keyword out of the update statement so that only CURRENT objects will be updated. This may leave quite a significant number of Internal ACLs left in the docbase that are used by non-CURRENT objects.


===[ Step C ]===============================
Now that no new Internal ACL is created and most of the objects in the docbase are assigned a Named ACL - the remaining Internal Acls are those created from Template ACLs. Your docbase is now hosting many orphan ACLs. It is time to clean them up!

Job dm_clean can delete orphan ACLs from the docbase. While running job dm_clean (from Documentum Administrator or you can schedule the job to run periodically), make sure that argument '-clean_acl' is set to TRUE.

Before running the job, you can find out how many ACL the job will clean after going through step A and B:
DQL> select count(*) as Number_of_Internal_ACLs from dm_acl where r_is_internal=1 and acl_class = 0

To get more details about those ACLs:
DQL> select * from dm_acl where r_is_internal=1 and acl_class = 0

If you agree with the result, run dm_clean and go to Step D.

For more information, Refer to Documentum eContent Server Administrator's Guide Chapter 10 "Removing Unreferenced Internal ACLs".


===[ Step D ]===========================
Restart the docbase. Active sessions may still be running with no default ACLs and will keep generating internal ACLs.

After running dm_clean and restarting the docbase, you can verify if all Internal ACLs are gone by re-running the same queries as in Step C:
DQL> select count(*) as Number_of_Internal_ACLs from dm_acl where r_is_internal=1 and acl_class = 0

To get more details about those ACLs:
DQL> select * from dm_acl where r_is_internal=1 and acl_class = 0

You can identify the remaining documents that are still using a Internal ACL:
DQL> select r_object_id, object_name, title, acl_name, owner_name, r_version_label from dm_sysobject (all) where acl_name in (select object_name from dm_acl where object_name like 'dm_45%' and object_name not like 'dm_45%\_8%' ESCAPE '\') order by 1

For more information on how ACL are assigned in WebPublisher, please refer to Support Note 15997


How can I setup a lifecycle to use multiple permission set aliases that are resolved randomly?

Sample Scenario:
You would like to configure a single lifecycle to assign ACLs to documents based on the line of business using the lifecycle. For example, Company A uses this lifecycle so that stage 1 attaches ACL 1-a to the document, but Company B uses the exact same lifecycle so that stage 1 attaches ACL 1-b to a document.

1) Create a docapp

2) Create a new alias set, say 'DLC_Alias'
- Create some new permission set aliases in this new 'DLC_Alias' set.
-Citibank_ACL
-Chase_ACL
-Manhattan_ACL
Resolve the aliases to the desired values.

3) Create a lifecycle, add X states.

4) Add your new DLC_Alias set as a default alias set to your lifecycle.

5) Edit some of the states of the lifecycle,
Add a new action
- Select Set Permission Set
- Specify Permission Set Alias
At this point, when you select this option, you should then see the aliases 'Citibank_ACL, Chase_ACL, Manhattan_ACL'
You can specify this to the desired alias.

6) Check-in the Lifecycle.

When someone goes to apply the lifecycle, in Desktop and in Webtop, they should see the lifecycle as well as a list of available alias sets that can be used.

They select the desired alias set and apply.

As the document goes thru the lifecycle, various Permission Sets or "ACLs" will be applied to the document while in the lifecycle.

Webtop Code Tips

To disable the folderselect buttons in webtop

Modify the below tag in Fileselection.jsp file
dmf:fileselectorapplet width="500" name="fileselector" folderselectmode="tree" folderselect="'false'" height="250"
dmf:fileselectorapplet
?xml:namespace prefix = dmf
dmf:fileselectorapplet width="500" name="fileselector" folderselectmode="tree" folderselect="'false'" height="250"
dmf:fileselectorapplet


Session Cookie Issue

Engineering Release Details: Webtop_53SP5_hotfix_152572.txt
============================
Product and Version this ER Works With: Webtop 5.3 SP5
Bug Number(s): 152572
Bug Abstract: A large cookie causes UCF operations to fail as WDK does not pass cookie info correctly to UCF. UCF fails if customer visits one of their web application first then vist the Webtop application, as their web application puts additional large cookies into the session. If they visit webtop only, UCF works without a problem.
Date: 02/22/2008

Additional Required Engineering Releases and Patches:
=====================================================
None

Installation Procedure:
=======================
1. Stop application server
2. Backup the following files to be able to revert back to the original installed product:

\WEB-INF\classes\com\documentum\web\applet\ucfinvoker\LaunchRuntimeDelegate.class
\wdk\system\ucfinit.cab
\wdk\system\ucfinit.jar

Where is the root directory of the exploded Webtop web application. For example, on Tomcat this typically is \webapps\webtop
3. Unzip the supplied zip file into . This will place the following files in the target directory
\WEB-INF\classes\com\documentum\web\applet\ucfinvoker\LaunchRuntimeDelegate.class
\wdk\system\ucfinit.cab
\wdk\system\ucfinit.jar
4. Clean the all cache in 'Windows start menu -> Settings -> Control panel -> Java -> Delete Files'.
5. Restart the Application Server and test the fix.

Change default Checkout Dir and Viewed Files

By default, the clean up of the viewed files folder and registry settings will only occur every seven days when UCF is used as the content transfer mechanism.

From Webtop 5.3 SP2 onwards it is possible to configure the interval by adding the house.keeping.interval configuration option to the ucf.client.config.xml
e.g.

option name="house.keeping.interval"
value 1 value
option



With this value set you should find that the viewed files folder is cleaned of files older than the specified value when housekeeping is invoked. However we do not guarantee that that document will be deleted at exactly the time specified in this configuration parameter because UCF is not service like process, it starts only when client requests content transfer and ends shortly after that. Also when a view operation is performed against a file that exist in the viewed file folder housekeeping does not occur. The reason that the house keeping is only started when you view a file that has not been viewed before is a result of performance considerations made during the design of the functionality.

Checkin and Checkout operations will also invoke the housekeeping.

As the house.keeping.interval option is not part of the standard set of ucf client side configuration options you can actually add "house.keeping.interval" to the ucf.installer.config.xml file within the webapp/wdk/contentxfer folder on the application server in order to have the setting propagated to the client side configuration files by following the advice provided in support note 75075

Note
You cannot set housekeeping interval to "0" because in this case UCF would have to delete document as client viewed it.

see UCF Housekeeping info on developer web site http://developer.emc.com/developer/Articles/UCFHouseKeeping.htm

wdk\contentXfer\ucf.installer.config.xml
Configuring the above XML, to check out to home directory looks good from my local machine running tomcat and webtop.

Error - Failed to retrieve content from ACS/BOCS server(s)

In 5.3 webtop/da frequently getting the error "Error - Failed to retrieve content from ACS/BOCS server(s). The ACS/BOCS server(s) may be down or your machine may not be able to reach the server(s) due to network connectivity or configuration issues"
If you encounter this, try the below resolution.

Symptoms Error - Failed to retrieve content from ACS/BOCS server(s). The ACS/BOCS server(s) may be down or your machine may not be able to reach the server(s) due to network connectivity or configuration issues

com.documentum.ucf.common.UCFException: All remote hosts failed

Cause
Content transfer is trying to use ACS instead of virtual link.

Resolution
I finally found the failure. In the dmcl_QA that corresponds to the bug.The getservermap api call with the mn_acs_map parameter.The bug # is 129741. I am enclosing the hotfix and am adding it to the case. If you wish, you can disable the ACS instead.

If you are not using ACS (used in Distributed Env) you can disable the ACS feature from your installation.Open the app.xml, on windows it's located under the following directory:C:\Program Files\Apache Software Foundation\Tomcat 5.0\webapps\", change to DO this for all of your wdks.

Saturday, March 22, 2008

Bug Fixes

Documentum DA 5.3 Sp2: Audit Trail- Ref No : 114997

- when choosing events for audit trail, the default 'show items' is ‘10’ and if you change it to 50/100, the results are displayed but the vertical scroll bar is missing and we cannot select items. This is a bug and it is fixed in 6.0

Friday, March 21, 2008

Retreive Deleted Documents

Whenever a document is deleted, only the document's metadata is deleted. The content itself (i.e. the object pointed to by the dmr_content object) remains in the content storage area until the IAPI script generated by the dmclean utility is run.Assuming that the dmclean utility has not been run, it is still possible to recover the object's content file.

Note: The document's attributes cannot be recovered without going back to a database backup. Below is an outline of a strategy which can be used to do this recovery.

Initially, you need to gather some data on the document that you want to recover such as:
In DQL: select * from dm_audittrail where event_name='dm_destroy'
a) What was the name of the client machine where the file was last checked in? This is the set_client attribute.
b) What was the date/time of the last checkin? This is the set_time attribute.
c) What format was the document? This is the full_format attribute.
d) What was the name of the object? This is the object_name attribute.
For E.g : recoverddoc
With this information, the following query can be issued
IDQL: select r_object_id from dmr_content where any parent_id is null and set_client = and full_format = and set_time > DATE('')

This will retrieve a set of r_object_id's that correspond to content objects that have been deleted and meet your criteria. Once you have found the appropriate r_object_id of the deleted document, you are ready to find the file.
Using IAPI, execute the following commands:
API> apply,c,,GET_PATH
API> next,c,q0
API> get,c,q0,result
This returns the file system path to the object.
For example: 'c:\Documentum\data\happydays\content_storage_01\00003039\80\00\00\e6.doc'

Using DQL:
create "dm_document" OBJECT SET "object_name"='recoverddoc',SET "authors"='chandu', SETFILE 'c:\Documentum\data\happydays\content_storage_01\00003039\80\00\00\e6.doc' with content_format='msw8'

Alternatively using API’sNow that you have the path of the content file, you can create a new object with this content by doing the following:
API> create,c,dm_document 0900006580005a65
API> set,c,,object_name
SET> Restored Document
OK
API> setfile,c,,'c:\Documentum\data\happydays\content_storage_01\00003039\80\00\00\e6.doc'
OK
API> link,c,,/Temp
OK
API> save,c,
Now look for a document named "Restored Document" in the /Temp cabinet. If it is there, then you have successfully recovered the deleted document!

Note:
- Add an event dm_destroy in the audit trails
- Stop dm_clean and dm_DMFilescan jobs which will instead clear contents of orphaned objects on scheduled basis
- select * from dm_audittrail where event_name='dm_destroy'
o this will give the details like ‘who,when,where deleted, object name’
- select * from dmr_content where any parent_id is null and set_time >= DATE(Today)
o this has the list of all the deleted documents on that day