EM Console 11g shows OID is down

The Enterprise Manager Fusion Middleware Control 11g shows OID is down even though opmnctl shows OID is up.

The EM console also displays the following error while trying to access the OID instance under Farm_IDMDomain -> Identity and Access -> oid1 or while trying to create a wallet for SSL

Error:

Information Configuration settings are unavailable because /Farm_IDMDomain/OID_Inst/oid1 is down.

There could be 2 reasons for this.

Reason1:

The WebLogic user password used by EM Console to monitor OID is not correct.

Solution:

• Go to the Farm drop down menu on the top of EM Console -> Agent Monitored Targets -> Configure . Verify if the Weblogic Monitoring User Name is correct and Change the WebLogic Monitoring Password to the correct password. Click Ok.
• Check the OID status now.

Reason2:

The IP address/hostname given in the Middleware Administration Server Service URL is wrong.

The following is an example of the Middleware Administration Server Service URL

service:jmx:t3://your_ip_address:7002/jndi/weblogic.management.mbeanservers.domainruntime

Solution:

• Go to the Farm drop down menu on the top of EM Console -> Agent Monitored Targets -> Configure .
• Try using hostname instead of IP address. Click OK and verify the status of OID from EM console.

Resources Missing After Upgrade

It is unlikely that many will have this problem, but if you do this could save some time and headache troubleshooting...

When you upgrade from 7.x to 10.1.4.0.1 the resources on policy domains and policies go missing. It appears that the only known fix for this is to manually recreate this data using the UI after the upgrade.

The other approach would be to proactively take them out of the directory server before you do the upgrade and then simply add them back afterward.

The resources themselves are still there after the upgrade. All that is really missing is the pointer from the resource action object to the resource.

These can be found by performing an ldapsearch with the following criteria:

search base: obapp=PSC,OU=oblix root,DC=,DC=com
filter: (&(objectClass=oblixWRSCAction)(obResourceID=*))
attributes: obResourceID

This will return all of the objects that have this value set.

After the upgrade run the same search and compare the results. Those values should be missing. If so, prepare an LDIF file to update the entries.

An LDIF entry to fix the missing obResourceID could take this form...

dn: obname=,obname=,obapp=PSC,OU=oblix,DC=,DC=
changetype: modify
replace: obResourceID
obResourceID:

replace the tags with the appropriate value for your environment based on the LDIF you extracted.

Simple Mode Root CA Strikes Again

We discussed the expiration of this cert already in this post. I never thought i would see this problem again. Ahhh, was i wrong. When upgrading from COREid 7 to OAM 10, the 10.1.4.0.1 upgrade drops the old (now expired) root CA over the updated ones.

If you keep the faith and keep going the 10.1.4.3 patch set replaces it with the new one that is good until 2024.

transfilter.dll disappears and won't load

I just had the most frustrating experience. I am in the midst of upgrading OAM 7.x to 10.1.4.3. I had all the components upgraded to 10.1.4.0.1 so I got backups taken. Afterwards one of the webpass instances did not work. Upon further inspection transfilter.dll was actually removed form the file system. Strange, but no problem, i grabbed a copy from another 10.1.4.0.1 webpass.

The transfilter.dll still didn't get loaded by IIS and it still did not work. I ended up trying numerour different things. I added and re-added transfilter.dll to the Default Web Site multiple times. I uninstalled 10.1.4.0.1 and re-upgrade; still go the same behaviour. I uninstalled webpass alltogether (purged registry, etc) and installed 10.1.4.0.1 instead of upgrading an old one; still got the same behaviour.

I had given up home when i decided to try adding transfilter.dll at "Web Sites" instead of "Default Web Site". Low and behold it took and loaded. Then I tried moving it back to "Default Web Site" and it worked there too. I was back! Frustrated, but back.

I have no idea what caused transfilter.dll to disappear in the first place. I have no idea why it would not load in IIS after it was replaced. I have no idea why moving it in IIS fixed the problem. I am thankful though and if this strange occurence ever recurs I will have a strategy.

SAML Back Inside?

What's old is new again. Remember SAML Service in CoreID 5x? Sounds like OIF will be merged back into OAM in a future release.

OAM 11g R1

AuthN and AuthZ responses support much more options for returning user data. It appears that the need to create plugins to return more complex data has been eliminated.

Will your OAM installation fail in July 2010?

Is your OAM installation setup in simple mode? Then chances are your installation is going to break on July 25, 2010. You may have heard a faint ticking every time you got near one of your OAM machines, but never had a chance to figure out where this impending failure was going to come from. As you know,
according to Mayan Calendar, in 2012in simple mode OAM generates certificates for you using the simpleCA root CA (tools\openssl\simpleCA). This root certificate is also used to complete the chain of trust when establishing SSL connections.

But did you know that root CA certificates expire? The OAM certificate expires Jul 25 18:03:57 2010 GMT after which your OAM components will no longer be able to communicate with each other

How do I fix this?

Luckily the fix is extremely easy.

If you have an account for support.oracle.com, log in and search for ID 811105.1, which will instruct you to download a new cacert.pem and place it in all your simpleCA folders. Don't forget to include any AccessSDK installations, and make sure the new cacert.pem has the correct permissions.

If you don't have an account with support.oracle.com, then the release notes (bug 8556756) for OAM have instructions for extending the life of the Simple mode certificate. Once extended you can copy the new cacert.pem everywhere that it's needed and restart all components.

How do I know if I am affected?

You can browse to tools\openssl and use the openssl command to check the expiration date of the certificate.

openssl.exe x509 -in simpleCA\cacert.pem -noout -enddate

notAfter=Jul 25 18:03:57 2010 GMT

Oracle says the expiration date is July 5th, 2010 in their release notes. What is the real date?

Yes it does say that and we're not sure why. Feel free to update your cacert.pem prior to July 5th - no need to wait until the last minute.

What errors might I see if I did nothing?

WebGate protected pages will say they can't contact the access server.

You may see webgate errors like

2010/07/26@18:03:00.718000 3728 3240 CONN_MGMT ERROR 0x00001C08 \Oblix\coreid\palantir\aaa_client\src\watcher_thread.cpp:84 "NAP initialization failed"

2010/07/26@18:03:00.718000 3728 3256 CONFIG INFO 0x0000182C \Oblix\coreid\palantir\access_api\src\obconfig.cpp:865 "ObAccessException_ENGINE_DOWN" raw_code^301

or if your certificate permissions are wrong

2010/07/26@18:04:59.796000 3712 300 ACCESS_SDK FATAL 0x0000181C \Oblix\coreid\palantir\access_api\src\obconfig.cpp:422 "ObAccessException_NOT_INITIALIZED" raw_code^204

2010/07/26@18:04:59.796000 3712 300 ACCESS_GATE FATAL 0x00001520 \Oblix\coreid\palantir\webgate2\src\iisentry_web_gate.cpp:183 "Exception thrown during WebGate initialization" Error^Oracle AccessGate API is not initialized.