After an upgrade had been performed there were hundreds of active policies whose targets were not getting updated when the Delta Resource Membership update schedule ran. The targets could not be edited or manually updated because they were grayed out.
If the target was deleted and created again the problem was fixed for the policy. But there were hundreds affected.
Found in 7.5.1 and 7.6. Possibly others.
The problem is rare so it is not understood why/how this condition occurred; but it is believed to be related to timing in communications between the SMP and the database server during an upgrade.
Within that window, or some other event the following had occurred (one or both).
The GUID (ResourceTargetGuid ) of the affected targets had their security owner changed to a user who no longer existed or the user/trustee who originally created the target no longer existed in the database and therefore could not be verified.
The ResourceTargetGuid of the affected targets had been removed from the ResourceTargetOwnerTrustee table so that the owner trustee could not be verified.
The following query will return the names of the affected policies, and the count of targets per policy that are problematic.
selectdistinct p.Name as Policy,COUNT(*)as [Affected Targets]
from ItemAppliesTo iat
join Item p on p.GUID= iat.ItemGuid
join Item i on i.GUID= iat.ResourceTargetGuid
leftjoin ResourceTargetOwnerTrustees rot on rot.ResourceTargetGuid = iat.ResourceTargetGuid
leftjoin SecurityTrustee st on st.GUID= rot.TrusteeGuid
where rot.ResourceTargetGuid isnullor st.GUIDisnull
Run the SQL script attached to this article. The script will do the following two procedures.
Identify all targets whose security owner exists in ResourceTargetOwnerTrustee but cannot be verified. It will then change the security owner of all affected targets to be owned by "Symantec Administrators"
Identify all targets that have no representation in ResourceTargetOwnerTrustee, and insert them into the table - also setting Symantec Administrators as the owner trustee.
Note: It is good practice and highly recommended that, before running any SQL script against a database, a backup of the database should be created first.