I will try and not be long-winded (definitely something I am notorious for). My setup is fairly simple. I have ODB (22.214.171.124) and OEM 12c installed on one machine. OEM is fully functional and working as intended. I have a secondary machine, that I would like to use as an emergency backup. Essentially have a mirrored OEM setup, so if the first machine goes down, I can bring up the second machine and continue monitoring the same targets.
On the second machine, I have installed ODB (126.96.36.199) and OEM 12c (Software ONLY). I then copied the plugins, a backup of the ODB on the first machine), and the software library to the second machine. I ran omsca -standby with the proper verbs, pluginca and then an importconfig using the backup file. When I try to access the OEM GUI on the second machine, the login screen shows, but when I login as SYSMAN, the GUI shows with the following error:
Internal Error has occurred. Check the log file for details.
ADFC-0619: Authorization check failed: 'oracle.jbo.uicli.binding.JUFormDef@27ae29cb' 'VIEW'.
Any ideas? The second machine's OMS is currently pointing at the first machine. Eventually I will copy the first machines DB over and replicate it on the second machine...so the second machine will be an exact working copy of the first...as a backup. But for now, I want to get the second machine's OMS working properly as a standby...with a copied DB, in case of emergencies.
I have seen the exact same behavior. For many reasons, I cannot and do not wish to utilize the deployment procedure mentioned in the Oracle document. Upon further studying it anyways, it does the same things:
1) check the file system for the SW library
2) upload the plugins
3) creates a backup OMS with omsca
4) imports the config from the initial OMS
So I did a SW only install, with 188.8.131.52 and OEM 12c BP1 both 32-bit and 64-bit. I also get the error on two OS fresh installs of both my primary and secondary OMS. In my server logs (emoms.trc) I have seen missing cn=SYSMAN "LDAP" errors. It seems the SYSMAN_APM schema or something like that has errors under 184.108.40.206.
The curious thing, I have done this procedure twice with 220.127.116.11, patched to PSU2 and it worked like a charm. I am thinking [but cannot explain why] that it is an Oracle database bug.
I installed my primary OMS and added some custom plugins we have. I also added an agent. I installed DB 18.104.22.168 on both my primary and backup. Then I used omsca -nostart, emctl importconfig, pluginca to create and configure a standby OMS. It worked.
Can you re-try your procedure with 22.214.171.124 ?
I want to know why cannt you use DP to have 2OMS deployed?
If you cannt use DP then you should foolow the manuall instrucstion from here:
Make sure you are following all the steps from this doc.
I was unable to use the DP because of several things.
I do not, and will not be able to have a mirrored storage for the SW library. This secondary OMS is meant to be the passive OMS in an active passive setup, where we may migrate to it in case of the primary site going down.
The DP procedure did some sort of test to verify whether we had the shared storage so I could not proceed on it. It alerted me to an error.
We also had bandwidth limitations, the operational network has capped our usage to a rate that would be impossible to copy the software installers across the WAN. We do have the bandwidth for an initial bootstrap (omsca, pluginca, importconfig) but not shipping database and OEM 12c install binaries or files across the network.
We were also depending on a very quick deployment time, currently our customer gives us very short deployment and maintenance windows. With our model, we deploy the software to disks, which ship out to the field, as configured as possible. We already had SW installs of OEM 12c and Oracle Database.
While I think Oracle's DP is nice, it should not be advertised as the ONLY way to create a secondary OMS. We found the sequence of 'omsca, pluginca, importconfig' to work.
With 126.96.36.199 I get the ADFC error, but with 188.8.131.52 it works correctly, so I am wondering if there is a bug in 184.108.40.206 database that causes some Repository configuration actions to silently fail.