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:arslist-boun...@arslist.org] On Behalf Of Thomas 
Miskiewicz
Sent: Wednesday, April 24, 2019 11:39 AM
To: ARSList <arslist@arslist.org>
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 
<doug_r...@bmc.com<mailto:doug_r...@bmc.com>> 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:arslist-boun...@arslist.org] On Behalf Of Thomas 
Miskiewicz
Sent: Wednesday, April 24, 2019 11:23 AM
To: ARSList <arslist@arslist.org<mailto:arslist@arslist.org>>
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 
<doug_r...@bmc.com<mailto:doug_r...@bmc.com>> 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:arslist-boun...@arslist.org<mailto:arslist-boun...@arslist.org>] On 
Behalf Of Thomas Miskiewicz
Sent: Wednesday, April 24, 2019 10:01 AM
To: ARSList <arslist@arslist.org<mailto:arslist@arslist.org>>
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
ARSList@arslist.org<mailto:ARSList@arslist.org>
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
ARSList@arslist.org<mailto:ARSList@arslist.org>
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
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Reply via email to