As mentioned in a previous post, many clients are struggling with software audits from Documentum and are revisiting how they are using Documentum within their company.
Understanding what happens in the software audit
The following are the types of questions that Documentum is trying to answer during a software audit:
- Is there any anonymous access to the docbase?
- Do all users/machines creating content have the appropriate Documentum license?
- Is one machine being used to front-end a group of users that really should be licensed?
To answer these and other questions, Documentum will send a list of queries to the customer to execute in their environment. To help users understand the audit, we’ve included a few sample queries below. We recommend users execute these types of queries in their environment in order to verify their own usage, even as a part of regular system maintenance.
Where is content being created from?
The following is one query that a client of mine executed and had concerns about after seeing the query results in their environment:
SELECT set_client, count(*) FROM dmr_content GROUP BY set_client ORDER BY 2 desc
According to the document provided by Documentum, this query will show what machines are being used to access the docbase. However, this query actually shows the machines from which content has been created in the docbase, not just from where the docbase has been accessed.
The results of this query will return the names of the application server, the content server box, as well as the transformation server (if DTS has been installed). It may also return some unfamiliar server names or those that don’t seem like they should appear here. There’s a good explanation for these additional server names. If any other machine was ever used to execute a setfile or setcontent API command, maybe through Samson, or other API tool, that machine would appear in this list as well. For example, your IT department might have needed to execute a setfile command to fix an issue with a document, and they could have done that from their own machine.
This particular client also had a row in their results that contained a blank server name as the set_client value, with a fairly large number as the total count. This obviously caused some concern for them, but after some investigation, we assured them that this was a perfectly legitimate value to have. It seems that the blank server name actually represents the content server, but it represents those times when the content server itself must have encountered a situation that caused the host name value to be lost or not accessible when setting the set_client property.
In order to see what objects actually fall into this blank set_client category, run the following query:
SELECT r_object_id, object_name FROM dm_sysobject WHERE r_object_id IN (SELECT parent_id FROM dmr_content can WHERE set_client = ‘ ‘)
Most of the objects that are returned from this query are internal Documentum files, and drilling down even further shows that most of them are just job reports. It looks like the set_client property is blank for reports created by jobs that are set to ‘Run as Server’. It might be that the sessions are handled differently within these types of jobs, in a way that does not keep track of the client host name.
Who is modifying and creating content?
The two other queries that my client raised questions about were the ones that pull back how many objects have been modified by each user:
SELECT r_modifier, count(*) FROM dm_sysobject GROUP BY r_modifier ORDER BY 2 desc
And how many objects have been created by each user:
SELECT r_creator_name, count(*) FROM dm_sysobject GROUP BY r_creator_name ORDER BY 2 desc
If the results of either of these queries show that dmadmin and the docbase owner have created or modified a lot of objects, there’s no need to be alarmed right away. When talking about creating objects, dmadmin will be the creator on all job reports and certain instances of workflow activities, so that will account for a large portion, which is perfectly normal. Dmadmin or the docbase owner will also be the creator on all out-of-the-box Documentum files or objects, so that takes up a big portion as well.
In terms of objects that are modified, dmadmin or the docbase owner can come into play in various ways. If there are any automatic workflow activities that are set to run as the docbase owner and the workflow method attached to that activity executes a save on the object at any point in its logic, then the modifier of that object will be set to the docbase owner. Dmadmin could be set as the modifier if any lifecycle actions are being executed on an object and the docbase has the a_bpaction_run_as attribute set to ‘superuser’. If the value is set to ‘superuser’, that means all promotes, demotes, etc. will be executed as dmadmin and therefore will cause the modifier on the object to be set to dmadmin. If there are any jobs set to ‘Run as Server’ and the logic in the job updates any documents, that will cause the modifier on those documents to be set to dmadmin as well. Also, all job reports will have the modifier set to dmadmin.
Overall, as mentioned in a previous post, the Documentum software audit is something that clients can plan and prepare for as part of their regular system license maintenance. In the case of my client, after working through the results with Documentum, the audit revealed no license shortfalls.
Please feel free to contact us if you have any additional questions about Documentum software audits.