Great Kevin, that’s sounds like a like I can work with. I will give it shot and yet it’s be great to know how bmc recognizes primary vs secondary.
Thomas On Wed 24. Apr 2019 at 20:21, Kevin Shaffer <[email protected]> wrote: > In addition to what Doug said, we had a similar issue and these are all > the pre req steps we had to perform to make it work in our environment > because the prechecker also enforced some things. > > > > We too spent days looking through numerous XML files for the > BMC_IS_SECONDARY_SERVER > variable but found that our root cause was that DEV was a copy of PROD and > when we upgraded DEV, all the server group settings in DEV pointed to > PROD. In our case I think deleting the servergrp data from the DB and > deleting all Operation Ranking records, then rebooted. The install then > worked for us. > > > Pre-Implementation Tasks > > 1. Shut down all AR Servers except for Admin Server > 2. Delete all Operation Ranking records > 3. Ensure that Disable_Admin-Ops is set to F in the ar.conf > 4. Ensure that Server-Group-Member is T in the ar.conf. Installers > for v9 assume that all servers are server groups even if they are stand > alone. > 5. Change the Server-Name parameter from <long name> to host name > <short name> > 6. Delete servgrp_applic where applicable > 7. Delete servgrp_board where applicable > 8. Delete servgrp_config where applicable > 9. Delete servgrp_ftslic where applicable > 10. Delete servgrp_op_mstr where applicable > 11. Delete servgrp_userlic where applicable > 12. Change the parameter, Oracle-Cursor-Sharing, from FORCE to EXACT > in the ar.conf > 13. Change the parameter, Next-ID-Block-Size, from 5 to 100 in the > ar.conf > 14. Change the escalation thread from Private-RPC-Socket: 390603 3 3 > to Private-RPC-Socket: 390603 6 6 in the ar.conf > > HTH > > > > > > > > *From:* ARSList <[email protected]> *On Behalf Of *Reif, Douglas > *Sent:* Wednesday, April 24, 2019 1:13 PM > *To:* ARSList <[email protected]> > *Subject:* RE: Installer is performing a secondary server > install/upgrade, No forms will be imported. > > > > Thomas, > > We often see this problem after a prior install failed but had already > updated the database. > > You run the next install and it checks the dbversion from the control > table. > > See https://communities.bmc.com/docs/DOC-37267. This shows that for 9104 > the currdbversion would be 57. > > So my assumption is that if you checked the control table, you would see > this, meaning the DB was upgraded. > > > > The solution for this is to rollback the DB to prior to the upgrade that > failed. > > The upgrades do not rollback the database automatically. It’s a lot of > work to undo some of the things the installers does because decisions are > made dynamically based on the environment. It’s a lot easier to make a db > backup or restore point and if the install fails, just revert to that. > > > > DougR > > > > > > *From:* ARSList [mailto:[email protected] > <[email protected]>] *On Behalf Of *Thomas Miskiewicz > *Sent:* Wednesday, April 24, 2019 10:01 AM > *To:* ARSList <[email protected]> > *Subject:* [EXTERNAL] Installer is performing a secondary server > install/upgrade, No forms will be imported. > > > > Hi All, > > > > we upgraded one single 7.6.04 server to 9.1.04 and got this at the end: > Installer > is performing a secondary server install/upgrade, No forms will be imported > > > > Same situation when we try to re-run the installer. Does anyone know where > does Remedy store the info or how it recognises which type of server > (primary/secondary)? > > (Definitely not via ARSystemInstallationConfiguration as the parameter > BMC_IS_SECONDARY_SERVER is set to false.) > > > > BMC Support doesn’t know how to solve this… > > > > > > > > Thomas > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist >
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
