Hello All,
Thank you for bringing these challenges to our attention. We appreciate your feedback here, and your suggestions where there is room for improvement in the documentation and steps to apply CP2 (14.1.02). We are aware that there have been some challenges, and confusion on the documented steps for applying CP2 (14.1.02) in an Advanced Availability environment, and we are currently in the process of evaluating the solution to improve this experience for our customers. In the interim, while we continue to work through this internally, I would like to share a set of steps with you that we have tested internally, and have used at several customer sites to apply CP2 (14.1.02) successfully in an advanced availability environment. If you need to install CP2 (14.1.02) in an advanced availability environment, please follow these steps:
1. stop services on all servers
2. ran 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.
We are aware that 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.
We hope this helps you to successfully apply CP2.
Thanks,
Jon Israel
Principal Support Engineer
CA Technologies