Ask the Expert: What's New in EMC Documentum 7.1?

@PanfilovAB, trust me, it happens.  Don't make the mistake of thinking that because you wouldn't do it, others would also not do it.  I wish you were correct, however, my experience has taught me otherwise.   I don't want to go on record with any specific cases but I see consultants called in to do things that our staff already clearly understands how to do.  In fact, we have a consultant coming in to build a production system later this year, and for a very well documented process (from another vendor).  Often times it is part of some sort of agreement that is negotiated at the time of procurement, for either the product or a support contract, and management feels like if they don't use it they're throwing away money.  I'm just speculating but I suspect it is because they have deadlines for projects and they don't want to take the chance that the on-site team will have trouble meeting the deadline so they include the consultant as a failsafe, then always end up using the failsafe even when they don't need it.

I'd like to ask about Java support changes for 7.1.  Can you list everything that has changed in regards to Java?

For example, I'd really like to see all of the Documentum process that use Java to use the system Java and not an included JDK.  One important advantage of this would be to make it much easier for us to support IT security mandated updates to Java without the need and paperwork involved for obtaining waivers.  I have learned through various sources that replacing the included JDK and symlinking (Linux) to your system installed Java usually works fine anyway so why isn't this the way it is done out-of-the-box?  Just use $JAVA_HOME and require that a JDK be installed.  I can understand limiting the version of the JDK to the most recent stable major version but anything more specific than that won't work for us.  If incompatibilities are introduced they should be handled with patches to Documentum and not by requiring a specific version of Java.

Julien Fontaine , old school is putting it mildly.  It's all PDFs.  You can't imagine how hard that is to manage until you are the one who has to use it.  It might be a convenient method of providing documentation for EMC but it is horribly inconvenient for the customers.  Personally, I think if anyone is going to be inconvenienced it should always be EMC in favor or making things easier for the customer.  As if having to cross reference multiple PDFs in order to install and manage one product wasn't bad enough, those PDFs are almost always just minor edits from the previous versions, hardly ever platform or architecture specific, and full of errors and omissions that can literally have you struggling for days only to find that you weren't doing anything wrong, it was just the documentation that was wrong.  If I were EMC, before I started work on any more features I'd fix the documentation for the existing product, and I don't mean submitting a bunch of DOC FIX SRs to correct the existing PDFs.

It needs to be rebuilt from the ground up, all online, all of it easily accessible in one place, and constantly updated and corrected.  Though, I'd still like a wiki, official or not.  I disagree with Alvaro de Andres , wikis work great for documentation in the open source world, but usually only with FLOSS, the problem is with open source software that is really just commercial software using the words "open source" for marketing appeal.  It can work with commercial software too, but that requires the company to be extraordinary in the relationship they have with their customers, and that usually isn't the case.

I'd like to ask about kerberos (single domain, single forest) multi-docbase support within Webtop.  In the past we had trouble configuring webtop for Kerberos authentication for more than one docbase.  The user was required to authenticate to subsequent dobases after the initial selection on the docbase selection page.  However, we need to have multiple docbases open within the same Webtop instance, to be able to search across these multiple docbases  but to never have to type a username and password.  The inability to do this is what tanked our previous efforts at upgrading since we had planned on doing a complete architectural overhaul in the process.  If 7.1 can support this it would go a long way toward convincing management that the time to go to 7.1 is now.

Don't make the mistake of thinking that because you wouldn't do it, others would also not do it.  I wish you were correct, however, my experience has taught me otherwise. ...

Mark, all you had written is, actually, means that your customer either doesn't trust you (your team) or does not think you are qualified enough (I don't want to put doubt on your skills, it's just about how I read that you had written). But I'm talking about another things. Let's give a few examples.

10 of 10 customers face problems with LDAP (though kerberos is more painful) setup, the problems are really different, some of them are:

1. SSL is a challenge
2. Documentum does not support long distinguished names
3. it's not possible to setup account name transformations
4. it's not obvious how to synchronize existing inline users with ldap or move users from one domain to another
5. etc, etc, etc
   

but all LDAP related problems have the only one root cause - LDAP integration is not properly documented, so, if customer has a strong desire to use LDAP as user source customer need to hire someone (PS, partner, employee, freelancer, etc).

Performance and troubleshooting activities have the same problem: no documentation, no best practices, want to solve problem - hire someone.

Hi.

The CTS suite was modified in 7.0 and 7.1.

A customer who has DTS licenses should/may upgrade to ADTS 7.1 ?

Thanks,

Roney

Patrick Walsh wrote:   Anonymous SSL mode secures the communication between the DFC client and the Content Server.  The new SSL mode also establishes the identity of the Content Server.  As you pointed out earlier, this secures the system from malicious internal masquerade attacks that try to spoof the identity of the Content Server.

Patrick Walsh 

Yesterday we discussed incompatibilities introduced with Certificate-based SSL:

And that is a real issue, for example: how can we copy some data between old CS and 7.1 with Certificate-based SSL without switching it to anonymous SSL? And I can't understand what was the problem to implement new SSL feature in clearer way? For example:

1. add support of new options to DFC like:

   dfc.security.trusted_docbase[0]=docbase1

   dfc.security.trusted_cert_alias[0]=cert_alias1

   that will cause DFC to require server authentication for specific docbase
2. when server sends response on NEW_SESSION_BY_ADDR request it sets some flag whether it supports Certificate-based SSL or not (the same behavior is implemented for serialization protocol and time format convention)
3. if DFC expects that connection should be secure but CS didn't set specific flag, DFC disconnects
4. otherwise DFC upgrades cipher suite (removes DH_anon_*), initiates renegotiation and checks received server certificate

Hello rstein ,

As far as i know DTS and ADTS doesn't exist since the version 6.7 SPxx. You have to migrate to CTS. Did you ask your sales rep ?

Hi PanfilovAB ,

we are able to give our opinion on the documentation here : IIG Tech Pubs Documentation Survey

Enjoy it

Hi Julien Fontaine , we tried but didn't got an answer for this question through our commercial channel, that's why I asked here.

The CTS 7.1 documentation now have different installers for ADTS, MTS and AVTS. Not for DTS.

This may be more of a commercial question, but as the installers are different in the 7.1 release and DTS is not mentioned in the documentation I thought you could help me clarify this.

Thanks.

we are able to give our opinion on the documentation here

I already wrote my opinion about that survey: it's author is not familiar with Pigeonhole principle, 6 questions - 5 options:

Moreover, it's incorrect to force select different options.

@Patrick Walsh  That sounds like a reasonable response, though I don't know what it is you're responding to?  Perhaps you meant to reply to someone else?  I don't think I asked any questions about stores, or did I?

With Documentum, we try to balance the addition of new features against the impact to current solutions.  We're discussing areas that have reached a point where the complexity demands careful reduction.  We're looking to approach stores from two angles: consolidate as much as possible within Documentum for standalone deployments or push as much as possible to remote protection system that can secure the stores in one location across the Enterprise.

I agree that strongly recommended does need more context.

And a good suggestion for the docbroker.  The docbroker was originally built to direct traffic, but it has potential to evolve into something greater.