So my screen cast on the HP TRIM 7 integration with SharePoint 2007 seems to have been popular which makes it all worth while re-recording it after the sound was so terrible from the live presentation!

To top this off I got lots of feedback from the HP TRIM product team answering both queries I had and also backing up their architectural decisions along the way. I have summarised below in easy read form (as it was a LOOONG e-mail discussion). It was also great to see that a lot of things limitations I highlighted have been added to their features list too J

Installation challenges

• Version 7.01 is coming and most of the installation issues I highlighted have been addressed (hoorah!!)

Security concerns

• Application Pool permissions requiring dbowner in config database is due to the SPPersistedObject class to store global configuration.

Architecture

• All the events in SharePoint are actually workflows, not event receivers (well a workflow is triggered by an OOTB event receiver so I was close)
• There are no timer jobs
• TRIM workgroup requirement is due to the need for the .NET (not COM) TRIM SDK which means that you do not need web services which was decided to be too complex due to reliance on Kerberos authentication and performance gains
• The mentioned "document store" in settings pages was not meant to be there in final release (has been removed for future releases) this does not exist and the scratch directory is used instead which is stored in SPPersistedObject
• Site Actions and ECM options are shown to everyone if switched on, but if they click on links only Site Owners can actually use this page, others get error
• TRIM search web part is based on the Federated Search Web Part
• No direct search integration with iFilters at this stage

Scalability concerns

• Acknowledge that having to configure TRIM in multiple Site Collections will be painful.
• Memory leak – there is a minor memory leak – but in performance testing they didn't see error

Approach of use

• The main way the integration is supposed to be used is to simply just switch on the integration and let it control everything in background. Although the RMO settings exist at Site and List HP do not perceive this being common approach…therefore switch off those features.
• You can have it so that a Site (SPWeb) can be mapped to one distinct Record Container in HP TRIM rather than dumping into one container. This does require granular control using RMO settings at Site level though.
• Archive - relocates the list item and finalizes it
• Currently setting up mapping from Content Type to Record Type across Site Collections means duplication
• It is not possible to check out a TRIM document exposed twice in SharePoint a second time, the first time you do it, the TRIM document is checked out

TRIM Client

• Finding the site and list records in HP TRIM is hard as no related records tab in HP TRIM. Not intention of product to reconstruct SharePoint structure in HP TRIM.
• You cannot restore from HP TRIM to SharePoint
• Not being able to see the full rendered content is by design, not seen to be able to reproduce what site looks like, just store content as record
• Auto creating Record Types based on Content Types is a deliberate design decision
• Revision numbers and SharePoint version numbers will diverge due to SharePoint doing multiple versions on metadata updates in certain scenarios

Records Manager concerns

• Default values for RMOs are that file containers do not get created, but they agree that this will be an issue for some Records Managers