• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
TSB Alfresco Cobrand White tagline

Technology Services Group

  • Home
  • Products
    • Alfresco Enterprise Viewer
    • OpenContent Search
    • OpenContent Case
    • OpenContent Forms
    • OpenMigrate
    • OpenContent Web Services
    • OpenCapture
    • OpenOverlay
  • Solutions
    • Alfresco Content Accelerator for Claims Management
      • Claims Demo Series
    • Alfresco Content Accelerator for Policy & Procedure Management
      • Compliance Demo Series
    • OpenContent Accounts Payable
    • OpenContent Contract Management
    • OpenContent Batch Records
    • OpenContent Government
    • OpenContent Corporate Forms
    • OpenContent Construction Management
    • OpenContent Digital Archive
    • OpenContent Human Resources
    • OpenContent Patient Records
  • Platforms
    • Alfresco Consulting
      • Alfresco Case Study – Canadian Museum of Human Rights
      • Alfresco Case Study – New York Philharmonic
      • Alfresco Case Study – New York Property Insurance Underwriting Association
      • Alfresco Case Study – American Society for Clinical Pathology
      • Alfresco Case Study – American Association of Insurance Services
      • Alfresco Case Study – United Cerebral Palsy
    • HBase
    • DynamoDB
    • OpenText & Documentum Consulting
      • Upgrades – A Well Documented Approach
      • Life Science Solutions
        • Life Sciences Project Sampling
    • Veeva Consulting
    • Ephesoft
    • Workshare
  • Case Studies
    • White Papers
    • 11 Billion Document Migration
    • Learning Zone
    • Digital Asset Collection – Canadian Museum of Human Rights
    • Digital Archive and Retrieval – ASCP
    • Digital Archives – New York Philharmonic
    • Insurance Claim Processing – New York Property Insurance
    • Policy Forms Management with Machine Learning – AAIS
    • Liferay and Alfresco Portal – United Cerebral Palsy of Greater Chicago
  • About
    • Contact Us
  • Blog

Documentum Client for Outlook (DCO) – A cautionary tale in regards to message formats and object types – comment if you have experience to share.

You are here: Home / Documentum / D6.5 / Documentum Client for Outlook (DCO) – A cautionary tale in regards to message formats and object types – comment if you have experience to share.

January 31, 2012

We have two clients that are struggling with the combination of email formatting as well as the Documentum Client for Outlook (DCO) regarding format and different releases.  TSG doesn’t see a ton of DCO or email implementations so we thought we would share our client’s experiences here.  Please comment if you have any DCO experience to share.

Documentum Client for Outlook and storing emails in Documentum – background

Documentum offers multiple ways to store emails in Documentum.  They include:

  • Documentum Client for Outlook – DCO provides for integration for users working in Outlook to drag emails (and attachments) into folders in Documentum.  As a client/server application, DCO has had some technical issues in the past but those will not be the topic of this post.
  • Multiple Client Applications – Webtop and other interfaces (ex:  Desktop Client) have enabled users in Outlook to drag and drop emails and attachments into Documentum as well.

Emails are slightly different than other documents in that an email (one document) can contain attachments (additional documents).  Each needs to be stored in the repository as a separate object and the relationship between the email and attachment needs to be maintained.  The email also has additional metadata (To, From, Subject, Sent Date, Received Date) that should be maintained as attributes.   Documentum began with just storing .MSG Outlook format (Microsoft standard) as another object.  As you can read below, the move to store the email as more of a specific email type along with object types and formats has led to issues with long-term users.

Documentum Client for Outlook and email formats

Formats of emails, object types and attached documents are causing the most issues for our clients.   Below is a brief history of email formatting before expanding on the different client issues.

  • Pre Documentum 5.3 SP3 – Emails could be stored as any type of object type, just like importing a Word or Excel document.  For applications like Webtop or Desktop Client, emails were stored as whatever default document type was being used or that the user selected during import, usually dm_document or a custom subtype. This approach lacked any storage of email specific metadata.  For both DCO and Webtop, the email format was .MSG (Microsoft standard for Outlook) Attachments were embedded within the MSG content and were not stored as separate objects.
  • Pre Documentum 5.3 SP3 – Documentum Client for Outlook  – Emails were stored as dm_mail_message again in the .MSG format.   With this object type, certain meta-data was extracted from the email for subject and other fields but attachments were still stored embedded within the MSG file.
  • DCO 5.3 SP3 – With the 5.3 release of DCO SP3, Documentum moved to a new dm_message_archive object type with movement from MSG format to EMCMF (proprietary format from EMC).  The EMCMF format (and DCO client) relies on splitting the attachments out of the MSG file and storing them as separate objects with a relationship between the email and attachments.   The format also requires a hidden folder in the same folder where the email is stored and places the attachment object(s) into that folder.  Given the new format, Documentum gave out a conversion utility to move all the old emails to the new email format.  Since the conversion of the outlook MSG format to EMCMF takes place in the Unified Client Facilities (UCF) – the migration tool was a client based tool.  The migration utility needs to run on a client and is not multi-threaded.  Seems like somewhat of a “hack” particularly if you have a large amount of emails to convert.   Initially, the utility forced de-duplication of messages. If the utility detected the same message id (in the email message header which is then stored in one of the dm_message_archive attributes) already stored in the repository, it would skip any later instances of the same message that were stored in other locations. While this might make sense for a litigation support application, it was completely unacceptable given that more than one user might each store the same message.  The other consideration with the conversion utility is that only dm_email_message can be converted to dm_message_archive.  For Desktop Client or Webtop users who had been importing messages as dm_document or a subtype, a preliminary conversion step had to be done using some other third party tool to get to dm_email_message before the utility could even be used.
  • Documentum 6.5 – The conversion EMCMF utility was updated to not do the de-duplication but instead will store both emails as well as attachments in separate hidden folders.
  • Webtop 6.5  – provides for a way to view emails but not as a MSG document (only as an HTML view).  The viewer does not have the ability to reply/forward or respond.  The only way to open as an MSG format would be to open from DCO client or export from Webtop at which point the UCF conferts the EMCF format back to MSG.
  • DCO 6.7 – in the new release of DCO, the way DCO stores the document attachment relationships has changed.

Email Issues

Here are some the issues two of our clients are struggling with:

  •  Client One –  is attempting to upgrade to DCO 6.7 as part of their Documentum 6.6 upgrade.  The client ran the migration utility on their 5.3 docbase.  Unfortunately, the new DCO client cannot read the old emails but can only read new emails.  The client is also disappointed that, in order to get emails in the MSG format, they are required to use the DCO (ironically, Webtop 6.6 can read both formats).  The client thinks something was lost regarding a change in relationships between objects and is working through the issue with EMC while their upgrade is delayed.
  • Client Two – is a non-DCO user struggling with conversion.  The client was thinking of running the migration utility on their older documents (still in MSG format) but is very concerned about the utility running on the client side (they have 500,000 emails), being stuck in the proprietary EMC format, as well as having to move their older documents from dm_document to dm_email_message as a first step in the conversion process.

Please comment below if you have similar experiences and would like to share your thoughts and email strategy.

Filed Under: D6.5, D6.7, Documentum, OpenInterchange

Reader Interactions

Comments

  1. aquickremark says

    February 1, 2012 at 1:24 pm

    We have the same problem. We’re using DCO. Has anybody successfully migrated off of Documentum for Email?

    Reply
    • Alan Ogden says

      August 15, 2012 at 10:46 am

      In my organization we use a product called Oasys Mail Manager, it’s easy to file emails and includes the most powerful search UI that I’ve ever come across.

      Reply
      • George says

        August 15, 2012 at 1:39 pm

        Alan – I think you’re referring to email management on your desktop. This article is about how to store and manage emails in an ECM repository, not on an individual’s desktop PC.

        Reply
  2. Matt says

    February 7, 2012 at 2:07 pm

    The fun does not stop there… There are issues with xPlore and My Documentum for Outlook. https://community.emc.com/message/585087#585087

    This is pending response from EMC Engineering.

    Reply
  3. BeyondContent says

    February 7, 2012 at 4:18 pm

    We are a non-DCO customer and we looked into converting from email stored as dm_document subtype, .MSG format in 6.5 SP2. To even attempt to test the migration utility we had to get special access and permission to use the docapps for DCO since the client-based utility required a bunch of the doc types, etc. from DCO. Once we got all the pieces working, and bugs in the utility fixed, plus a 3rd party app to get to dm_email_message, we eventually decided it wasn’t worth the effort.
    And if EMC ever goes away from the EMCMF format, I’d hate to have to move it all back!
    We’ve now upgraded to 6.6 and would have to start the whole investigation from scratch – not planned.
    Biggest drawback to our existing setup is that we cannot search on email-specific attributes (to, from, subject, received date, sent date, etc.).

    Reply
  4. BeyondContent says

    February 8, 2012 at 2:35 pm

    This just in from EMC:

    ——–
    The current product strategy for 2012 plans to address this issue as follows:

    MyDocumentum for Microsoft Outlook will shift from using a proprietary email message format (EMCMF) to storing email message in their native format, .msg. The MS Outlook integration will manage its specific email properties (To, From, Date, etc.) via an aspect attached to the email object. Other Documentum clients, such as Webtop which do not handle aspects, will simply not show these email properties.
    ——–

    Leaves me with more questions than answers.

    Reply
  5. Jorge says

    August 10, 2012 at 10:13 am

    On the 4i Days with desktop client. Outlook integration was native to that client. And the function was basically performed by the “import” component. I actually did an Import customization that was able to take the relevant email attributes and also import the attachments separately forming a virtual document. The email message was a custom doctype with the basic email attributes and the attachments could be any doctype.
    I really miss this functionallity on recent versions. We sold DCO to one of our customers (Oil and Gas company) and have nothing but trouble with DCO even on 6.7 version (tested v. 6.5 SP3, 6.6, 6.7, 6.7 SP1) and different things failed on each of this versions:

    1. Used a propietary lightweight object not a standard dm_document so didn’t match the designed doctype infraestructure wich derived from dm_document

    2. Properties functionallity didn’t worked with value assistance

    3. TBO’s weren’t working either as validations where not transmitted to the UI by the product.

    We still think that DCO could be a good solution if EMC had built it with good enough quality process that could match Documentum’s basic functionality. But as today it’s unusable other than to store it’s OOTB attributes an standard functions

    Reply
  6. Rag says

    January 23, 2019 at 12:38 pm

    7 years later.. we still have this issue while archiving our Documentum content to Infoarchive. I was unable to even find a 3rd party utility that can do the conversion for us.

    Reply

Trackbacks

  1. EMC World 2012 – May 23rd – What’s Next? ECM Documentum Family Roadmap – Aaron Aubrecht « TSG Blog says:
    May 23, 2012 at 12:49 pm

    […] MyDocumentum for Outlook 6.7.1 Q4 2012 – Moving away from proprietary format – see related post […]

    Reply
  2. Documentum D2 and EMC Professional Services « TSG Blog says:
    July 19, 2012 at 5:06 pm

    […] to replace existing drag and drop functionality in Webtop.  We posted about some of this client’s struggles back in […]

    Reply
  3. Documentum Email Integration – A Simple Approach « TSG Blog says:
    August 9, 2012 at 2:25 pm

    […] solutions including leveraging IMAP as well as issues with drag and drop functionality leveraging MyDocumentum for Outlook or Webtop.  This post will review the use of the “forward” button to provide an email client neutral […]

    Reply

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Search

Related Posts

  • Documentum, Mobile and IMAP – A standard and open source approach for email archiving and mobile access
  • Supersized Documentum Migrations and Upgrades Two Billion Documents and Counting
  • Documentum Upgrades – Handling eSignatures in Documentum 6.6+
  • Documentum Upgrade to 6.7 – a simple approach
  • Documentum 6.5 to 6.7 Upgrade Lessons Learned
  • EMC World 2012 – May 23rd – What’s Next? ECM Documentum Family Roadmap – Aaron Aubrecht
  • Documentum 6.7 Upgrades and Hardware Changes
  • Debugging Documentum Java Method Server (JMS) Code in Eclipse
  • Documentum Webtop 5.3 running on Documentum Content Server 6.x
  • Documentum , Weblogic and DM_DFC_E_BAD_CLASS error

Recent Posts

  • Alfresco Content Accelerator and Alfresco Enterprise Viewer – Improving User Collaboration Efficiency
  • Alfresco Content Accelerator – Document Notification Distribution Lists
  • Alfresco Webinar – Productivity Anywhere: How modern claim and policy document processing can help the new work-from-home normal succeed
  • Alfresco – Viewing Annotations on Versions
  • Alfresco Content Accelerator – Collaboration Enhancements
stacks-of-paper

11 BILLION DOCUMENT
BENCHMARK
OVERVIEW

Learn how TSG was able to leverage DynamoDB, S3, ElasticSearch & AWS to successfully migrate 11 Billion documents.

Download White Paper

Footer

Search

Contact

22 West Washington St
5th Floor
Chicago, IL 60602

inquiry@tsgrp.com

312.372.7777

Copyright © 2023 · Technology Services Group, Inc. · Log in

This website uses cookies to improve your experience. Please accept this site's cookies, but you can opt-out if you wish. Privacy Policy ACCEPT | Cookie settings
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT