Tuesday, December 21, 2010
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.
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=
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=
replace: obResourceID
obResourceID:
replace the
Comments:
<< Home
Hi there
I had this issue numerous times.
You can also apply the 10.1.4.2.0 + 10.1.4.3 BP's to the upgrade binaries themselves.
Or directly delete trailing tabs in the at_700_to_1014_map_psc.lst mapping file during the install, RIGHT BEFORE the installer starts upgrading the LDAP.
I had this issue numerous times.
You can also apply the 10.1.4.2.0 + 10.1.4.3 BP's to the upgrade binaries themselves.
Or directly delete trailing tabs in the at_700_to_1014_map_psc.lst mapping file during the install, RIGHT BEFORE the installer starts upgrading the LDAP.
Hi there
I had this issue numerous times.
You can also apply the 10.1.4.2.0 + 10.1.4.3 BP's to the upgrade binaries themselves.
Or directly delete trailing tabs in the at_700_to_1014_map_psc.lst mapping file during the install, RIGHT BEFORE the installer starts upgrading the LDAP.
I had this issue numerous times.
You can also apply the 10.1.4.2.0 + 10.1.4.3 BP's to the upgrade binaries themselves.
Or directly delete trailing tabs in the at_700_to_1014_map_psc.lst mapping file during the install, RIGHT BEFORE the installer starts upgrading the LDAP.
Another issue that is present due to faulty files from Oracle is that audit rules may not be upgraded/migrated properly. This is due to a missing blob in the file oc_700_to_1014_map.lst located in \access\oblix\tools\migration_tools\obmigratedata RIGHT BEFORE you tell the installer to update the LDAP repository.
The blob is to be added right before the MasterAuditRule section:
oblixAuditPolicy:
BEGIN:vCompoundList
preserve:true
oblixAuditPolicy:
BEGIN:vCompoundList
occurances:1
parent:NULL
END:vCompoundList
END:vCompoundList
Post a Comment
The blob is to be added right before the MasterAuditRule section:
oblixAuditPolicy:
BEGIN:vCompoundList
preserve:true
oblixAuditPolicy:
BEGIN:vCompoundList
occurances:1
parent:NULL
END:vCompoundList
END:vCompoundList
<< Home