Are you using the same user to edit the standard that originally created and associated targets to it?
I ask because this error message can be generated if the user attempting to save the updated standard, does not have view access to all of the targets already associated to that standard.
Could it be possible the user you were using to edit the standard did NOT have access to all of the targets originally associated to the standard?
Thanks for the response. I've been attempting to do this with the same user account as was used to originally create the compliance standard and to associate targets to it (my account has EM_ALL_ADMINISTRATOR, EM_COMPLIANCE_DESIGNER, EM_COMPLIANCE_ADMINISTATOR, etc so it should have all necessary permissions). To try to rule out a permissions issue, I just tried to repeat this test while logged in as SYSMAN and I received the same error (both while adding a rule owned by a SYSMAN and while adding a rule owned by the original user account). I've also confirmed that it occurs for both users even with no targets associated to the standard. It occurs with both customized rules and with out-of-the-box rules that I have not customized.
This isn't a big issue for me (since everything works fine after a Create Like and moving targets to the new standard), but I do have a couple standards in my library exhibiting this behavior if you think this is worth an SR for support to investigate. The workaround is flawless as far as I can tell, but maybe an issue for sites with hundreds/thousands of targets. I only have 10 per standard so it doesn't take long to re-associate them to the new standard.
Ok, well the other condition that can cause this is an association to a target that no longer exists. Obviously, this should not happen but it is possible to check for such a condition.
If you run the below query as sysman user against EM repository, it should return zero rows. ( Substitute the name of your compliance standard first obviously. ).
select r.target_guid from em_cs_tgt_assoc_txf_req r where r.root_cs_guid
in (select cs_guid from mgmt_cs_config_standard where cs_dname =
'<Compliance Standard Display Name>') and r.target_guid not in (select target_guid from mgmt_targets);
If one or more rows is returned, this is the cause of the issue.
Please let me know the results.
Looks like you nailed it! I get three rows back from that query.
I had a problem during my upgrade to EM12cR3 where one of the agents ran out of disk space during the upgrade to the new agent. After fumbling the agent recovery, I ended up deleting those targets, that host and that agent, then reinstalling the agent and re-adding the targets. That host had three targets on it that were associated with these compliance standards and I'd be willing to bet that the three target_guids returned are those that belonged to the deleted targets (though I can't find anywhere in the repository to confirm that).
Consider me impressed! Now I wish I had marked this as a question so I could at least send points your way since I can't send you a beer or three.
Thanks Brian. Glad we got to the bottom of it especially as to how the issue relates to upgrade. That part had us scratching our heads.
Hopefully others will not run into the same issue ( unless they run out of disk space as well. )
Be assured that I'm telling anyone who will listen to NOT be stingy like me and only allocate 2GB to their agent filesystems... and I have a SAN admin that will give me all the space I ask for, so I only have myself to blame.
Thanks again for clearing this up and have a great day!