If you asked anyone knowledgeable about Documentum, you would be discouraged from toying with filestore_01. This is the default storage area that is used by a repository, unless you create additional storage areas and configure types/objects to use those storage areas. This file store is critical for the operation of the Content Server.
While trying a high availability (HA) and disaster recovery (DR) configuration, we decided to try moving all content (including that created/used by Content Server for its internal purposes) to replicated Centera stores. This is another no-no (per EMC Documentum), in general, since Centera is intended for storing content that doesn’t change much (archiving). The problem we were trying to overcome was that all stores needed to be available as identical (shared) to both the Content Servers and we were trying to utilize the existing Centera infrastructure set up for storing business content. By default, filestore_01 location was local and there were two copies – one on each Content Server. If you do things like checking in a lifecycle using one Content Server, the other one doesn’t see the changes and starts throwing errors.
So we decided to migrate all objects from filestore_01 to a new Centera store. We would also configure all built-in types to use this new store. However, the more we investigated the more it appeared that filestore_01 may be “special” (as in hard-coded default) in various scenarios. So we would also keep another Centera store named filestore_01 to capture any future objects trying to land there.
The worry was that we would have to rename the existing filestore_01 to something else before naming a Centera store as filestore_01. Would the Content Server stop working as soon as we renamed filestore_01 to something else? Thankfully, that didn’t happen – probably all the caches helped us out.
Now, everything seemed to still work fine and it was a great accomplishment!
Everything was fine until we rebooted the Content Servers. Within a minute or so the Docbase service (Content Server) would stop by itself. And we were going crazy figuring out the probable cause. With no solution is sight, we dove back into the admin guide. We found out that the Centera plugin (CSEC Plugin) DLL is stored in the repository itself. So here was the catch 22 – the DLL was needed to get into Centera and the DLL wdm_pluginas present inside Centera!! Of course, the guide mentioned that the plugin ( object) must use a filesystem-based store.
So we had locked ourselves out of the repository! Finally, we were able to restore the operation to normalcy by using a filesystem-based store to store the plugin:
- Got a copy of the DLL. The DLL is present on the Content Server, but we exported it from another repository.
- Got the object ID of filestore_03 (originally filestore_01). This was a filesystem-based store.
- Used SQL to perform database updates
- a_storage_type in dm_sysobject_s for the plugin object = ‘filestore_03’
- storage_id in dmr_content_s for the content object corresponding to the plugin object = object ID from step 2
- Started the Content Server
- Tried to view a document through DA – gave data ticket error showing the path that was missing
- Created the path and placed the DLL from step 1 and renamed it to the expected name
- We were back in business
Now this seems to be sufficient but we can never be sure what else may have problems. Further, EMC probably won’t support this configuration. So, good learning exercise but don’t bet your job on it!