{"id":17147,"date":"2022-03-05T08:25:51","date_gmt":"2022-03-05T07:25:51","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/"},"modified":"2022-03-05T08:25:51","modified_gmt":"2022-03-05T07:25:51","slug":"documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/","title":{"rendered":"Documentum – r_server_version reset to P00 instead of correct patch version"},"content":{"rendered":"

A few weeks ago, an issue was identified at a customer which would cause the value of “dm_server_config.r_server_version”<\/em> to be reset to the GA version number (16.4 P00) instead of the currently deployed patch (which is 16.4 P26) and that would happen randomly on some of the Content Servers but not all. The different Content Servers are all deployed on a Kubernetes Cluster, are using a single image (which contains the patched binaries) and are using replicas to provide High Availability. That really means that it’s the same image everywhere but despite that, some of them would, at some point, end-up with the P00 shown.<\/p>\n

Every time the pods would start\/restart, the “dm_server_config.r_server_version”<\/em> would properly display the P26 version, without exception. I spent several hours doing testing on that issue, but I was never able to replicate the issue by simply restarting the Content Server. At startup, a Content Server will update the value of “dm_server_config.r_server_version”<\/em> with the currently used binaries (returned by the “documentum -v”<\/em> command). I tried enabling the RPC and SQL traces after some discussion with the OpenText Support, but it didn’t show anything useful.<\/p>\n

Since it appeared randomly and since I couldn’t replicate the issue by restarting the Content Server, I just simply let an environment up&running without any user activity on it and I was checking every day the value of the “dm_server_config.r_server_version”<\/em>. During the week, nothing happened, the P26 was constantly shown and the dm_server_config<\/em>\u00a0object wasn’t updated in any way. However, after the weekend, it was suddenly showing P00 so I started looking into the details:<\/p>\n

[morgan@k8s_master ~]$ kubectl get pod cs-0\nNAME   READY   STATUS    RESTARTS   AGE\ncs-0   1\/1     Running   0          6d22h\n[morgan@k8s_master ~]$\n[morgan@k8s_master ~]$ kubectl describe pod cs-0 | grep Started\n      Started:      Mon, 31 Jan 2022 10:53:48 +0100\n[morgan@k8s_master ~]$\n[morgan@k8s_master ~]$ kubectl exec -it cs-0 -- bash -l\n[dmadmin@cs-0 ~]$\n[dmadmin@cs-0 ~]$ date; iapi ${DOCBASE_NAME} -Udmadmin -Pxxx << EOC\n> retrieve,c,dm_server_config\n> dump,c,l\n> EOC\nMon Feb  7 07:57:00 UTC 2022\n...\nSYSTEM ATTRIBUTES\n\n  r_object_type                   : dm_server_config\n  r_creation_date                 : 7\/15\/2021 11:38:28\n  r_modify_date                   : 2\/6\/2022 03:19:25\n  ...\n  r_server_version                : 16.4.0000.0248  Linux64.Oracle\n  r_host_name                     : cs-0\n  ...\n\nAPI> Bye\n\n[dmadmin@cs-0 ~]$\n[dmadmin@cs-0 ~]$ grep --color \"16.4.0\" $DOCUMENTUM\/dba\/log\/${DOCBASE_NAME}.log\n    OpenText Documentum Content Server (version 16.4.0260.0296  Linux64.Oracle)\n2022-01-31T09:59:36.943158      6994[6994]      0000000000000000        [DM_FULLTEXT_T_QUERY_PLUGIN_VERSION]info:  \"Loaded FT Query Plugin: \/app\/dctm\/server\/product\/16.4\/bin\/libDsearchQueryPlugin.so, API Interface version: 1.0, Build number: HEAD; Feb 14 2018 04:27:20, FT Engine version: xPlore version 16.4.0160.0089\"\nMon Jan 31 10:00:50 2022 [INFORMATION] [AGENTEXEC 8215] Detected during program initialization: Version: 16.4.0260.0296  Linux64\n2022-02-06T03:04:00.114945      23067[23067]    0000000000000000        [DM_FULLTEXT_T_QUERY_PLUGIN_VERSION]info:  \"Loaded FT Query Plugin: \/app\/dctm\/server\/product\/16.4\/bin\/libDsearchQueryPlugin.so, API Interface version: 1.0, Build number: HEAD; Feb 14 2018 04:27:20, FT Engine version: xPlore version 16.4.0160.0089\"\n2022-02-06T03:19:25.601602      31553[31553]    0000000000000000        [DM_FULLTEXT_T_QUERY_PLUGIN_VERSION]info:  \"Loaded FT Query Plugin: \/app\/dctm\/server\/product\/16.4\/bin\/libDsearchQueryPlugin.so, API Interface version: 1.0, Build number: HEAD; Feb 14 2018 04:27:20, FT Engine version: xPlore version 16.4.0160.0089\"\n[morgan@k8s_master ~]$<\/pre>\n
 <\/p>\n
As you can see on the above output, the modification date of the dm_server_config<\/em> was Sunday 6-Feb-2022 at 03:19:25 UTC while the repository started on the Monday 31-Jan-2022 at 09:59 UTC. Until the Friday 4-Feb-2022, the returned version was P26 (16.4.0260.0296) but then after the weekend, it was P00 (16.4.0000.0248). The grep command above was used initially to verify that the repository started with the P26, that’s the very first line of the Repository log file: “OpenText Documentum Content Server (version 16.4.0260.0296 Linux64.Oracle)”<\/em>. However, on the Sunday morning, suddenly there are two new messages shown related to the FT Query Plugin initialization. This usually means that the Content Server was re-initialized and that’s indeed what happened:<\/p>\n
[dmadmin@cs-0 ~]$ grep \"DM_SESSION_I_INIT_BEGIN.*Initialize Server Configuration\" $DOCUMENTUM\/dba\/log\/${DOCBASE_NAME}.log\n2022-01-31T09:59:34.302520      6994[6994]      0000000000000000        [DM_SESSION_I_INIT_BEGIN]info:  \"Initialize Server Configuration.\"\n2022-02-06T03:03:56.846840      23067[23067]    0000000000000000        [DM_SESSION_I_INIT_BEGIN]info:  \"Initialize Server Configuration.\"\n2022-02-06T03:19:23.644453      31553[31553]    0000000000000000        [DM_SESSION_I_INIT_BEGIN]info:  \"Initialize Server Configuration.\"\n[dmadmin@cs-0 ~]$<\/pre>\n
 <\/p>\n
Therefore, something must have triggered the reinit and that would most probably be a job. One that would have run around 03:04 UTC and one around 03:20 UTC. Looking at the dm_sysobject<\/em> created around that time gave me two good candidates of jobs that would have performed the reinit of the Content Server and therefore that might be the cause of the switch from P26 to P00:<\/p>\n
API> ?,c,select r_object_id, r_creation_date, r_modify_date, object_name from dm_sysobject where r_creation_date>=date('06.02.2022 03:00:00','dd.mm.yyyy hh:mi:ss') and r_creation_date<=date('06.02.2022 03:25:00','dd.mm.yyyy hh:mi:ss');\nr_object_id       r_creation_date            r_modify_date              object_name\n----------------  -------------------------  -------------------------  ----------------------------------\n090f45158029f8a6  2\/6\/2022 03:03:13          2\/6\/2022 03:03:14          2\/6\/2022 03:03:11 dm_Initialize_WQ\n090f45158029f8a9  2\/6\/2022 03:04:14          2\/6\/2022 03:04:15          2\/6\/2022 03:03:44 dm_DMClean\n090f45158029f8aa  2\/6\/2022 03:04:11          2\/6\/2022 03:04:11          Result.dmclean\n090f45158029f8ad  2\/6\/2022 03:04:15          2\/6\/2022 03:04:16          2\/6\/2022 03:04:14 dm_WfmsTimer\n090f45158029f8b4  2\/6\/2022 03:11:46          2\/6\/2022 03:11:47          2\/6\/2022 03:11:42 dm_Initialize_WQ\n090f45158029f8b7  2\/6\/2022 03:12:52          2\/6\/2022 03:12:53          2\/6\/2022 03:12:12 DocumentTraining\n090f45158029fc1e  2\/6\/2022 03:16:15          2\/6\/2022 03:16:15          2\/6\/2022 03:16:13 dm_Initialize_WQ\n090f45158029fc21  2\/6\/2022 03:22:17          2\/6\/2022 03:22:17          2\/6\/2022 03:19:13 dm_DMFilescan\n090f45158029fc22  2\/6\/2022 03:22:14          2\/6\/2022 03:22:14          Result.dmfilescan\n090f45158029fc28  2\/6\/2022 03:23:48          2\/6\/2022 03:23:48          2\/6\/2022 03:23:43 dm_Initialize_WQ\n(10 rows affected)<\/pre>\n
 <\/p>\n
As shown above, the first reinit was most probably triggered by the dm_DMClean <\/em>job while the second one was most probably coming from the dm_DMFilescan<\/em> job: if you look at the start time of these jobs (check the object_name) and the completion time (check the Result line), then the reinit is right in the middle of it. Just in case, looking at the “a_last_completion”<\/em> for these two jobs also confirmed the same:<\/p>\n
API> ?,c,select r_object_id, a_last_completion, a_next_invocation, object_name from dm_job where object_name in ('dm_DMClean','dm_DMFilescan');\nr_object_id       a_last_completion          a_next_invocation          object_name\n----------------  -------------------------  -------------------------  -------------\n080f45158000035b  2\/6\/2022 03:04:14          2\/13\/2022 03:00:00         dm_DMClean\n080f45158000035c  2\/6\/2022 03:22:17          2\/13\/2022 03:15:00         dm_DMFilescan<\/pre>\n
 <\/p>\n
Knowing that I got two good candidates, I obviously had to try manually to reproduce the issue. Therefore, I restarted the repository to get back to P26:<\/p>\n
[dmadmin@cs-0 ~]$ date; iapi ${DOCBASE_NAME} -Udmadmin -Pxxx << EOC\n> ?,c,select r_object_id, r_creation_date, r_modify_date, r_server_version from dm_server_config;\n> ?,c,select r_object_id, a_last_completion, a_next_invocation, object_name from dm_job where object_name in ('dm_DMClean','dm_DMFilescan');\n> EOC\nMon Feb  7 08:45:13 UTC 2022\n...\nSession id is s0\nAPI> \nr_object_id       r_creation_date            r_modify_date              r_server_version\n----------------  -------------------------  -------------------------  --------------------------------\n3d0f451580000102  7\/15\/2021 11:38:28         2\/7\/2022 08:41:02          16.4.0260.0296  Linux64.Oracle\n(1 row affected)\n\nAPI> \nr_object_id       a_last_completion          a_next_invocation          object_name\n----------------  -------------------------  -------------------------  -------------\n080f45158000035b  2\/6\/2022 03:04:14          2\/13\/2022 03:00:00         dm_DMClean\n080f45158000035c  2\/6\/2022 03:22:17          2\/13\/2022 03:15:00         dm_DMFilescan\n(2 rows affected)\n\nAPI> Bye\n[dmadmin@cs-0 ~]$<\/pre>\n
 <\/p>\n
Then, I ran the dm_DMClean<\/em> (updated the a_next_invocation<\/em> and window_interval<\/em> so that the job can start), checked that it performed the reinit of the Content Server and verified the “dm_server_config.r_server_version”<\/em> value:<\/p>\n
[dmadmin@cs-0 ~]$ date; iapi ${DOCBASE_NAME} -Udmadmin -Pxxx << EOC\n> ?,c,select r_object_id, r_creation_date, r_modify_date, r_server_version from dm_server_config;\n> ?,c,select r_object_id, a_last_completion, a_next_invocation, object_name from dm_job where object_name in ('dm_DMClean','dm_DMFilescan');\n> EOC\nMon Feb  7 08:50:39 UTC 2022\n...\nSession id is s0\nAPI> \nr_object_id       r_creation_date            r_modify_date              r_server_version\n----------------  -------------------------  -------------------------  --------------------------------\n3d0f451580000102  7\/15\/2021 11:38:28         2\/7\/2022 08:41:02          16.4.0260.0296  Linux64.Oracle\n(1 row affected)\n\nAPI> \nr_object_id       a_last_completion          a_next_invocation          object_name\n----------------  -------------------------  -------------------------  -------------\n080f45158000035b  2\/7\/2022 08:49:19          2\/8\/2022 03:00:00          dm_DMClean\n080f45158000035c  2\/6\/2022 03:22:17          2\/8\/2022 03:15:00          dm_DMFilescan\n(2 rows affected)\n\nAPI> Bye\n[dmadmin@cs-0 ~]$<\/pre>\n
 <\/p>\n
The reinit of the Content Server happened but it didn’t change the “dm_server_config.r_modify_date”<\/em>, maybe because it was already showing P26 so nothing had to be updated? The only thing that changed is the “dm_job.a_last_completion”<\/em> obviously, since the job ran. This means that the dm_DMClean<\/em> is probably not the culprit, so I did the same for the dm_DMFilescan<\/em>:<\/p>\n
[dmadmin@cs-0 ~]$ date; iapi ${DOCBASE_NAME} -Udmadmin -Pxxx << EOC\n> ?,c,select r_object_id, r_creation_date, r_modify_date, r_server_version from dm_server_config;\n> ?,c,select r_object_id, a_last_completion, a_next_invocation, object_name from dm_job where object_name in ('dm_DMClean','dm_DMFilescan');\n> EOC\nMon Feb  7 08:59:23 UTC 2022\n...\nSession id is s0\nAPI> \nr_object_id       r_creation_date            r_modify_date              r_server_version\n----------------  -------------------------  -------------------------  --------------------------------\n3d0f451580000102  7\/15\/2021 11:38:28         2\/7\/2022 08:52:34          16.4.0000.0248  Linux64.Oracle\n(1 row affected)\n\nAPI> \nr_object_id       a_last_completion          a_next_invocation          object_name\n----------------  -------------------------  -------------------------  -------------\n080f45158000035b  2\/7\/2022 08:49:19          2\/8\/2022 03:00:00          dm_DMClean\n080f45158000035c  2\/7\/2022 08:58:44          2\/8\/2022 03:15:00          dm_DMFilescan\n(2 rows affected)\n\nAPI> Bye\n[dmadmin@cs-0 ~]$\n[dmadmin@cs-0 ~]$ grep Report $DOCUMENTUM\/dba\/log\/${DOCBASE_NAME}\/sysadmin\/DMFilescanDoc.txt\nDMFilescan Report For DocBase REPO01 As Of 2\/7\/2022 08:52:22\nReport End  2\/7\/2022 08:58:43\n[dmadmin@cs-0 ~]$<\/pre>\n
 <\/p>\n
As you can see above, the dm_DMFilescan<\/em> did change the “dm_server_config.r_server_version”<\/em> to P00 and therefore the “dm_server_config.r_modify_date”<\/em> was also updated. Checking the dm_DMFilescan<\/em> job report shows that it took around 6min to complete and the update of the dm_server_config<\/em> object happened around 10s after the start of the job.<\/p>\n
Therefore, the reason why the “dm_server_config.r_server_version”<\/em> is being changed “randomly” from P26 back to P00 isn’t actually random but it’s due to the execution of the dm_DMFilescan<\/em> job. On HA environment, since this job can run on any of the available Content Servers, it gave a sense of randomness but it’s not. The same information was provided to OpenText and the bug CS-136387<\/em> was opened for the same.<\/p>\n
While doing further checks to try to understand the root cause, I saw the following on the method’s dmbasic scripts:<\/p>\n
[dmadmin@cs-0 ~]$ cd $DM_HOME\/bin\/\n[dmadmin@cs-0 bin]$\n[dmadmin@cs-0 bin]$ documentum -v\nOpenText Documentum Release Version: 16.4.0260.0296  Linux64.Oracle\n[dmadmin@cs-0 bin]$\n[dmadmin@cs-0 bin]$ ls -ltr dmfilescan* dmclean*\n-rwxr-x--- 1 dmadmin dmadmin 13749675 Nov 11 13:38 dmfilescan\n-rwxr-x--- 1 dmadmin dmadmin 13769063 Nov 11 13:38 dmclean.patch.bak\n-rwxr-x--- 1 dmadmin dmadmin 13866290 Nov 11 13:39 dmclean\n[dmadmin@cs-0 bin]$\n[dmadmin@cs-0 bin]$ strings dmfilescan | grep \"16.4\"\n16.4.0000.0248\n[dmadmin@cs-0 bin]$\n[dmadmin@cs-0 bin]$ strings dmclean.patch.bak | grep \"16.4\"\n16.4.0000.0248\n[dmadmin@cs-0 bin]$\n[dmadmin@cs-0 bin]$ strings dmclean | grep \"16.4\"\n16.4.0260.0296\n[dmadmin@cs-0 bin]$<\/pre>\n
 <\/p>\n
As shown above, the reason is the Documentum patching of the binaries:<\/p>\n
    \n
  • dmclean<\/em>: the dmbasic script is being updated properly and the version number that seems to be hardcoded inside it reflects the P26<\/li>\n
  • dmfilescan<\/em>: the dmbasic script isn’t being updated by the patch (there is no “*.patch.bak”<\/em> file) and therefore it still contains the P00 hardcoded version<\/li>\n<\/ul>\n
     <\/p>\n","protected":false},"excerpt":{"rendered":"
    A few weeks ago, an issue was identified at a customer which would cause the value of “dm_server_config.r_server_version” to be reset to the GA version number (16.4 P00) instead of the currently deployed patch (which is 16.4 P26) and that would happen randomly on some of the Content Servers but not all. The different Content […]<\/p>\n","protected":false},"author":20,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[197,525],"tags":[1875,1876,1877,1878,129,2510],"type_dbi":[],"class_list":["post-17147","post","type-post","status-publish","format-standard","hentry","category-application-integration-middleware","category-enterprise-content-management","tag-dm_dmclean","tag-dm_dmfilescan","tag-dmclean","tag-dmfilescan","tag-documentum","tag-r_server_version"],"acf":[],"yoast_head":"\nDocumentum - r_server_version reset to P00 instead of correct patch version - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Documentum - r_server_version reset to P00 instead of correct patch version\" \/>\n<meta property=\"og:description\" content=\"A few weeks ago, an issue was identified at a customer which would cause the value of “dm_server_config.r_server_version” to be reset to the GA version number (16.4 P00) instead of the currently deployed patch (which is 16.4 P26) and that would happen randomly on some of the Content Servers but not all. The different Content […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2022-03-05T07:25:51+00:00\" \/>\n<meta name=\"author\" content=\"Morgan Patou\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@MorganPatou\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Morgan Patou\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"9 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\\\/\"},\"author\":{\"name\":\"Morgan Patou\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/c4d05b25843a9bc2ab20415dae6bd2d8\"},\"headline\":\"Documentum – r_server_version reset to P00 instead of correct patch version\",\"datePublished\":\"2022-03-05T07:25:51+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\\\/\"},\"wordCount\":928,\"commentCount\":0,\"keywords\":[\"dm_DMClean\",\"dm_DMFilescan\",\"dmclean\",\"dmfilescan\",\"Documentum\",\"r_server_version\"],\"articleSection\":[\"Application integration & Middleware\",\"Enterprise content management\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\\\/\",\"name\":\"Documentum - r_server_version reset to P00 instead of correct patch version - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2022-03-05T07:25:51+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/c4d05b25843a9bc2ab20415dae6bd2d8\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Documentum – r_server_version reset to P00 instead of correct patch version\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/c4d05b25843a9bc2ab20415dae6bd2d8\",\"name\":\"Morgan Patou\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g\",\"caption\":\"Morgan Patou\"},\"description\":\"Morgan Patou has over 12 years of experience in Enterprise Content Management (ECM) systems, with a strong focus in recent years on platforms such as Alfresco, Documentum, and M-Files. He specializes in the architecture, setup, customization, and maintenance of ECM infrastructures in complex & critical environments. Morgan is well-versed in both engineering and operations aspects, including high availability design, system integration, and lifecycle management. He also has a solid foundation in open-source and proprietary technologies - ranging from Apache, OpenLDAP or Kerberos to enterprise-grade systems like WebLogic. Morgan Patou holds an Engineering Degree in Computer Science from ENSISA (\u00c9cole Nationale Sup\u00e9rieure d'Ing\u00e9nieurs Sud Alsace) in Mulhouse, France. He is Alfresco Content Services Certified Administrator (ACSCA), Alfresco Content Services Certified Engineer (ACSCE) as well as OpenText Documentum Certified Administrator. His industry experience spans the Public Sector, IT Services, Financial Services\\\/Banking, and the Pharmaceutical industry.\",\"sameAs\":[\"https:\\\/\\\/blog.dbi-services.com\\\/author\\\/morgan-patou\\\/\",\"https:\\\/\\\/x.com\\\/MorganPatou\"],\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/morgan-patou\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Documentum - r_server_version reset to P00 instead of correct patch version - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/","og_locale":"en_US","og_type":"article","og_title":"Documentum - r_server_version reset to P00 instead of correct patch version","og_description":"A few weeks ago, an issue was identified at a customer which would cause the value of “dm_server_config.r_server_version” to be reset to the GA version number (16.4 P00) instead of the currently deployed patch (which is 16.4 P26) and that would happen randomly on some of the Content Servers but not all. The different Content […]","og_url":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/","og_site_name":"dbi Blog","article_published_time":"2022-03-05T07:25:51+00:00","author":"Morgan Patou","twitter_card":"summary_large_image","twitter_creator":"@MorganPatou","twitter_misc":{"Written by":"Morgan Patou","Est. reading time":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/"},"author":{"name":"Morgan Patou","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8"},"headline":"Documentum – r_server_version reset to P00 instead of correct patch version","datePublished":"2022-03-05T07:25:51+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/"},"wordCount":928,"commentCount":0,"keywords":["dm_DMClean","dm_DMFilescan","dmclean","dmfilescan","Documentum","r_server_version"],"articleSection":["Application integration & Middleware","Enterprise content management"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/","url":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/","name":"Documentum - r_server_version reset to P00 instead of correct patch version - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2022-03-05T07:25:51+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/documentum-r_server_version-reset-to-p00-instead-of-correct-patch-version\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Documentum – r_server_version reset to P00 instead of correct patch version"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/c4d05b25843a9bc2ab20415dae6bd2d8","name":"Morgan Patou","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/5d7f5bec8b597db68a09107a6f5309e3870d6296ef94fb10ead4b09454ca67e5?s=96&d=mm&r=g","caption":"Morgan Patou"},"description":"Morgan Patou has over 12 years of experience in Enterprise Content Management (ECM) systems, with a strong focus in recent years on platforms such as Alfresco, Documentum, and M-Files. He specializes in the architecture, setup, customization, and maintenance of ECM infrastructures in complex & critical environments. Morgan is well-versed in both engineering and operations aspects, including high availability design, system integration, and lifecycle management. He also has a solid foundation in open-source and proprietary technologies - ranging from Apache, OpenLDAP or Kerberos to enterprise-grade systems like WebLogic. Morgan Patou holds an Engineering Degree in Computer Science from ENSISA (\u00c9cole Nationale Sup\u00e9rieure d'Ing\u00e9nieurs Sud Alsace) in Mulhouse, France. He is Alfresco Content Services Certified Administrator (ACSCA), Alfresco Content Services Certified Engineer (ACSCE) as well as OpenText Documentum Certified Administrator. His industry experience spans the Public Sector, IT Services, Financial Services\/Banking, and the Pharmaceutical industry.","sameAs":["https:\/\/blog.dbi-services.com\/author\/morgan-patou\/","https:\/\/x.com\/MorganPatou"],"url":"https:\/\/www.dbi-services.com\/blog\/author\/morgan-patou\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/17147","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=17147"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/17147\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=17147"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=17147"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=17147"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=17147"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}