Here’s an annoying change Oracle implemented in EM12cR2. You can no longer directly black out an agent target through the OEM GUI interface. Attempting to do so will result in an unhelpful error message on the GUI stating simply: Error editing the blackout “Blackout-Jan 14 2013 10:13:59 AM”. This worked in EM12cR1 and I made use of this functionality very frequently, and I’ve only now dug in a bit to figure out why.
Apparently Oracle has decided to remove the ability to black out an agent target. You couldn’t tell that from the error on the screen, but OEM follows up that error by generating an incident and a problem, and picking through the incident packaging directory you can see the actual error message:
[2013-01-14T10:12:43.245-05:00] [EMGC_OMS1] [ERROR] [EM-02916] [oracle.sysman.eml.admin.rep.blackout.BlackoutEvents] [host: omshost.domain.com] [nwaddr: x.x.x.x] [tid: EMUI_10_12_43_/console/admin/rep/blackout/blackoutConfig] [userId: USERNAME] [ecid: 004oo4JeaWFDwW95zf8DyW0007vt0004WR,0:1] [APP: emgc] [LOG_FILE: /oracle/oem/Middleware12cR2/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/sysman/log/emoms.log] [URI: /em/console/admin/rep/blackout/blackoutConfig] Submit of Blackout Failed.[[
java.sql.SQLException: ORA-20233: Agent targets cannot be directly blacked out
ORA-06512: at “SYSMAN.MGMT_BLACKOUT_ENGINE”, line 2368
ORA-06512: at “SYSMAN.MGMT_BLACKOUT_ENGINE”, line 2395
ORA-06512: at “SYSMAN.MGMT_BLACKOUT”, line 39
ORA-06512: at “SYSMAN.MGMT_BLACKOUT_UI”, line 1403
ORA-06512: at line 1
It seems like it was a late decision to remove this functionality since it’s still a bit rough around the edges. If you’re logged in as SYSMAN and attempt to create a blackout against an agent target, the “Search and Select: Targets” screen will not even contain ‘Agent’ in the drop down selection list for target type. But if you follow Oracle’s security recommendations and login as a regular user account rather than SYSMAN, you will still see ‘Agent’ available in the selection list, but attempting to use it throws the error and incident described above.
The workaround appears to be to select a HOST target to blackout, rather than an agent. This seems to replicate the functionality (black out everything on that host) that was achieved previously by blacking out an agent.