How to properly install CA Service Management 14.1 CP2 in an Advanced Availability Environment.
Article ID: 40989
Updated On:
Products
Issue/Introduction
Summary:
The following steps describe the most effective approach to installing CA Service Management 14.1 CP2 in an Advanced Availability Environment. One of the key concerns to installing the Cumulative Patches in Advanced Availability is that one should NOT treat this activity as a “rolling” patch install, where server components of an Advanced Availability environment are independently and selectively shut down, patch installed, then brought back up, while other servers are active and running. Such actions have led to issues with the resultant install where elements of the application that had been updated to CP2 were in fact regressed to their pre-CP2 state at the end of the install process.
One example is the “Error constructing scoreboard in method got_query_data” message on the Service Desk web interface scoreboard. The logging will report both this message and “Attribute uf_saved_search not found in producer crsq”. This is due to the "cm.maj" file in the NX_ROOT\bopcfg\majic being regressed by Version Control in Advanced Availability to a pre-CP2 state during the install process. One will find both a “cm.maj” and a “cm.maj.ver_old” file in this directory. The “cm.maj” file will have a date stamp consistent with when CP2 was installed and Service Desk pdm_configure executed on either the Background or Standby Server, but the file size is smaller than “cm.maj.ver_old”. Version control would have pushed out the "older" version of "cm.maj" as sourced from either the Background or Standby Server before CP2 was applied onto the affected server, placing a "newer" date stamp on the same file, but the smaller file size of the "newer" file as compared to the "ver_old" version of the file is the giveaway.
Instructions:
To install CP2 (14.1.02) in an advanced availability environment, please follow these steps:
1. Stop services on all servers
2. Run patch installer on Standby Server
3. Run “pdm_configure” on Standby Server (***YOU MUST UNCHECK THE BOX TO START SERVICES WHEN COMPLETE***)
4. Run “pdm_Server_control -v" to suppress version control on Standby Server
5. Start services on Standby Server
6. Run “pdm_server_control –b" to promote the Standby Server to be the Background Server
7. Run the patch installer on original Background Server
8. Run “pdm configure” on original Background Server (***YOU MUST UNCHECK THE BOX TO START SERVICES WHEN COMPLETE***)
9. Run “pdm_server_control –v" to suppress version control on original Background Server
10. Start services on original Background Server
11. Run “pdm_server_control -b" on original Background Server to promote it to be the Background Server
12. Start original Standby Server back up (WITHOUT suppressing version control)
13. Now go ahead and apply the patch to all app servers in the environment, and run pdm_configure on those (Note: you do not need to suppress version control at this point on the app servers)
14. Next, go ahead and perform the post steps including the DB load, CORS updates, BOXI related steps, and any other post steps that apply to your environment. (The DB load part only needs to be done on the background) - NOTE: You do NOT need to run pdm_configure first, as the post steps document currently states - please skip the pdm_configure steps, and simply apply the post step action items on each server.
15. Lastly, recycle each server in the environment, starting with the Original Background, then promoting to be the background server, then do any standby servers, and then finally the app servers.
Additional Information:
One of the challenges is the fact that pdm_configure defaults to starting services when complete, and as such, it does not give you the chance to suppress version control, so, when run on the standby server, it would cause the ddict file to be overwritten from the template, causing your custom tables/columns to be missing from it. The reason for this is due to the wsp_schema.sch, wsp_schema.log, and wsp_index.sch not being pushed to the standby servers via version control from the original background server. Since you would only use WSP on the background server, the files are only created there.
Using the steps we have listed above, the ddict will still get overwritten on the standby when pdm_configure is run, however, since no other servers are running at the time, AND version control is suppressed on that server, when you promote it to be the background, it will not push the bad ddict to the Original background. After you have completed the patch and the pdm_configure on the original background server, start it, and promote it to be the background, it will push the good ddict back over to the standby server, and all app servers, thus avoiding the problem, allowing you to apply CP2 successfully.
Please note that CP2, and any other patch that contains an MDB update, may not be done using "Rolling Maintenance" currently. You must shut down all servers to apply the patch properly.
As a result, if you are seeing an issue with your installation as a result of a prior attempt at installing 14.1 CP2, your best option is to revert the install to a backup or snapshot taken prior to the application of the cumulative. One may attempt to use ApplyPTF to uninstall the CP2 patch, then reapply the patch per the above instructions, but there is a risk that your custom schema may not be available.
Environment
Component:
Feedback
