Wonder if the Operating-mode parameter playing any role which decides if all servers are upgraded or not in server group. We have that parameter available in 9.x.
Worth checking it. Regards, Ravi On Mon, Apr 29, 2019, 9:46 AM Thomas Miskiewicz <[email protected]> wrote: > Doug > > > You said: Even if you change that dbversion, that shouldn’t solve the > problem. Even though the key was supposed to be the version number, > simply changing it doesn’t make the DB structure the old version. > > > That’s exactly my point: Can someone please reveal to us the specific > criteria by which the installer decides whether a server is secondary vs > primary. > > > I do have servers that were upgraded successfully and are considered > primary. I don’t see any difference in DB structure between secondary and > primary servers and it’s be illogical if it were or if the rule once > primary always primary applied. > > > Once you’re in a server group you should be able to take any server out of > the group. So if there is a particular DB in place I guess you wouldn’t be > able to do that as the primary/ secondary thing is set in stone. Just a > thought! > > > Thomas > > On 29. Apr 2019, at 05:50, Reif, Douglas <[email protected]> wrote: > > Thomas, > > I’m sure there was a lot of thought put into this by Engineering with the > intention of making the install process easier. > > When the installer changes were made, it was with the plan to help > customers out by automating some of the decisions made by the installer. > > Having said that, I understand exactly what you are talking about. I > can’t do much about the way the installer behaves other than suggest an > Idea on the Communities page. But as far as the installer choosing the > wrong option, I will look into that a little more. > > I am traveling this week and may not get back right away. But I’ll do my > best. > > If there is an open case with this, you can ask the Support person to > contact me and I will work with them. > > > > One more thing. Even if you change that dbversion, that shouldn’t solve > the problem. Even though the key was supposed to be the version number, > simply changing it doesn’t make the DB structure the old version. As far > as I know, there is no way to downgrade the db other than actually > reverting the db > > Thanks, > > Doug > > > > > > > > *From:* ARSList [mailto:[email protected] > <[email protected]>] * On Behalf Of *Thomas Miskiewicz > *Sent:* Saturday, April 27, 2019 9:46 PM > *To:* ARSList <[email protected]> > *Subject:* [EXTERNAL] Re: Installer is performing a secondary server > install/upgrade, No forms will be imported. > > > > The thing is that I have reset the currdbversion but that doesn’t do > anything. > > > > Well in the last pre installation screen the info “Installer is > performing a secondary server install/upgrade, No forms will be imported” > disappeared indeed but it did appear after the fact at the end of the > installation. So there must be more to it than just currdbversion. > > > > With other fresh installations I’ve noticed for instance that if you set > the alias and the host name to different values you end up with the same > problem. Why? Unfortunately I’ve noticed to late with this server and I’m > trying to recover from that costly “mistake”. > > > > Why doesn’t the installer make such a guessing game out of this? Cannot we > just ask primary/secondary and make this more transparent and manageable? > > > On 28. Apr 2019, at 00:04, Reif, Douglas <[email protected]> wrote: > > Was there doubt with what I stated earlier? > > If what I said doesn’t jive with reality, I can go back and do some more > research but all the evidence I’ve seen points to the CurrDBVersion being > the key. > > Let me know if you see the currDBversion and dbversion in the control > table being 57 (not higher) and yet it still thinks it is secondary > install when installing 1902. > > As I mentioned, the Secondary install believes that the DB was already > upgraded. If this is not the case, there could be a situation where it > doesn’t follow the rules and we will have to look into that > > > > DougR > > > > > > > > *From:* ARSList [mailto:[email protected] > <[email protected]>] *On Behalf Of *Thomas Miskiewicz > *Sent:* Saturday, April 27, 2019 7:59 AM > *To:* ARSList <[email protected]> > *Subject:* [EXTERNAL] Re: Installer is performing a secondary server > install/upgrade, No forms will be imported. > > > > Thanks Abhijit, > > > > I upgraded from 9.1.04 to the latest version and the installer still says > it’s a secondary server. > > > > This server is just an archive and it’s running fine so I think I’ll leave > it like this. > > > > It remains a mystery to me that BMC apparently doesn’t know the exact > procedure they use to determine whether it’s a primary or a secondary > server. > > > > After spending countless hours with their support to no avail I’m giving > up. > > > > > > Thomas > > > On 27. Apr 2019, at 13:30, Abhijit Hendre <[email protected]> wrote: > > For 9.1.04 , there is a roll back utility to roll back platform upgrade > (AR, Atrium Core, Atrium Integrator) which also roll backs control table > mentioned by Doug. Please check with BMC support for this utility. You will > have to run this utility and then run upgrade again. > > > > > > Thanks, > > Abhijit H > > > > On Thu, Apr 25, 2019, 12:41 AM Thomas Miskiewicz <[email protected]> > wrote: > > I have a restore point for the current messed up state so I’ll run the > installer and see what it says. > > > On 24. Apr 2019, at 21:00, Reif, Douglas <[email protected]> wrote: > > If I ran this past the ‘committee’ you know what they would say; “We never > tested that”. > > I’m guessing. Maybe they did test it. But I have a good feeling that > you’d be on your own. > > Having said that, the idea has merit. > > Say you upgraded to 1902. It should assume that your DB is a fully > intact 9104 DB with all the forms and workflow that would have been > imported had it been a successful 9104 upgrade > > . > > So it should go ahead and upgrade the DB on your first install, which is > going to be a “primary” server install because the DB version is > different.. Then it will start ARServer and if it starts up fine, will > import stuff. > > > > Now, it is only going to import stuff that it thinks needs to be imported > based on the fact that you are upgrading from 9104 to 1902. This is where > there is potential to not go perfectly. But it should be pretty close. > > > > The concern would be if something was missing from your 9104 definitions > that prevents a 9102 definition from being imported. Or in 9102 did not > import something because it assumed it was already there. > > > > There are not critical problems. But you could test and see how it goes. > > Check the install logs and look for any files with ‘error’ in the name > under the ..\ARSystem\logs directory > > Good idea, > > > > Doug > > > > > > *From:* ARSList [mailto:[email protected] > <[email protected]>] *On Behalf Of *Thomas Miskiewicz > *Sent:* Wednesday, April 24, 2019 11:39 AM > *To:* ARSList <[email protected]> > *Subject:* [EXTERNAL] Re: Installer is performing a secondary server > install/upgrade, No forms will be imported. > > > > What about upgrading to even higher version? I see that the DB version > would change so maybe we could force it this way? > > > On 24. Apr 2019, at 20:33, Reif, Douglas <[email protected]> wrote: > > This is a difficult position. Since the DB was already upgraded to 57, > the installer won’t upgrade it again; nor will it perform the imports that > typically would have occurred after the DB was upgraded and arserver > restarted. > > And there is not a way to downgrade the DB. > > A “secondary” server is any server that is installing *after* the db was > upgraded. > > The “primary” server is the first one to run the install while the DB is > still the original version. > > Without a backup, I don’t know how you are going to get the installer to > do what you want. > > An alternative is to simply manually import everything. > > As you may be aware, there’s a lot of stuff to import. And this is not > technically a supported method. > > BMC wants you to always have a DB backup or restore point you can use. > > If you do decide to import manually, most everything is going to be in > the ‘Installforms’ directory. > > But I am not going to make an official recommendation that you do that. > You can try it and see where it takes you. Test, Test, Test > > > > Doug > > > > > > *From:* ARSList [mailto:[email protected] > <[email protected]>] *On Behalf Of *Thomas Miskiewicz > *Sent:* Wednesday, April 24, 2019 11:23 AM > *To:* ARSList <[email protected]> > *Subject:* [EXTERNAL] Re: Installer is performing a secondary server > install/upgrade, No forms will be imported. > > > > Hi Doug, > > > > and thank you for the prompt reaction! > > > > The currdbversion version is indeed 57 however we don’t have a db we can > revert to... > > > > So the questions remain: > > > > - how does the installer recognize whether it’s dealing primary vs > secondary server > > > > or > > > > - how can we convince it to think of this server as primary server. > > > > Is a secondary server secondary forever? No right? > > > > > > > > Thomas > > > > > > > > On Wed 24. Apr 2019 at 20:17, Reif, Douglas <[email protected]> wrote: > > 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]] *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 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=SpOPrgB_XTsQD-5g08WreuNvNTqBaQ-FNIfCXPZKULM&m=Uv62_dGmNMu2QH55a5SAli8OTV-vOrhNdGTejWV5yeI&s=28a_g7AJY4g1lci_O0Qy58ua58_SkLmjYnpdLSFJs9I&e=> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=SpOPrgB_XTsQD-5g08WreuNvNTqBaQ-FNIfCXPZKULM&m=vh4_vK6jK1nL0kji-C8RKq0xPBm-EfD9SVUpjve3QEI&s=GvrxHn2IY6w4B8BVg3FKHEy7RdZDZ_Vvaef_18earU4&e=> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=SpOPrgB_XTsQD-5g08WreuNvNTqBaQ-FNIfCXPZKULM&m=IMCHb1gO6lnunshiU2qfYWDyPcHeBZIgaZ3aW7k_vaA&s=qWngKvqu9SmsrylCU9IJn64D5LRp-L_fM5EJO7Syl6U&e=> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=SpOPrgB_XTsQD-5g08WreuNvNTqBaQ-FNIfCXPZKULM&m=IMCHb1gO6lnunshiU2qfYWDyPcHeBZIgaZ3aW7k_vaA&s=qWngKvqu9SmsrylCU9IJn64D5LRp-L_fM5EJO7Syl6U&e=> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=SpOPrgB_XTsQD-5g08WreuNvNTqBaQ-FNIfCXPZKULM&m=IMCHb1gO6lnunshiU2qfYWDyPcHeBZIgaZ3aW7k_vaA&s=qWngKvqu9SmsrylCU9IJn64D5LRp-L_fM5EJO7Syl6U&e=> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=SpOPrgB_XTsQD-5g08WreuNvNTqBaQ-FNIfCXPZKULM&m=yEJVBILe8sLdU5LTABRS-B6R56LjXaoMjtHqiaPdCxs&s=vr0VnPQ8DRHnGBstU-qLDI_QrejhlIFFDYLrVeqKwLU&e=> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist >
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
