Targets used by active policies are not getting populated but remain at 0 members
Article ID: 162244
Updated On:
Products
IT Management Suite
Issue/Introduction
Targets used by active policies are not getting populated but remain at 0 members.
Many targets used by active/enabled policies have 0 members when they should have many. The only way to get it to populate the targets are to go into them individually, while running the SMP Console as a member of Symantec Administrators, and manually update the target.
However, after the NS.Complete Resource Membership Update…” schedule runs the target is reduced to 0 members again.
Many targets used by active/enabled policies have 0 members when they should have many. The only way to get it to populate the targets are to go into them individually, while running the SMP Console as a member of Symantec Administrators, and manually update the target.
However, after the NS.Complete Resource Membership Update…” schedule runs the target is reduced to 0 members again.
Cause
There were two contributing factors:
1. The GUIDs of some of the affected targets were represented in table ResourceTargetOwnerTrustees, but the Security Trustee assigned to the targets (a security role) that did not have permissions, directly or inherited, to the targets. The permissions of its parent security role had somehow been lost, possibly via an upgrade.
2. Many of the affected targets were not represented in the table ResourceTargetOwnerTrustees, so they were skipped during the process.
All targets and filters should be registered in the table. It is not known how many were no represented in the table.
The following query will show all existing targets that are not represented in ResourceTargetOwnerTrustees and should be.
select i.Name as [Target],iat.ResourceTargetGuid
from ItemAppliesTo iat
join Item i on i.Guid = iat.ItemGuid
left join ResourceTargetOwnerTrustees t on t.ResourceTargetGuid = iat.ResourceTargetGuid
where t.ResourceTargetGuid is null
order by 1
1. The GUIDs of some of the affected targets were represented in table ResourceTargetOwnerTrustees, but the Security Trustee assigned to the targets (a security role) that did not have permissions, directly or inherited, to the targets. The permissions of its parent security role had somehow been lost, possibly via an upgrade.
2. Many of the affected targets were not represented in the table ResourceTargetOwnerTrustees, so they were skipped during the process.
All targets and filters should be registered in the table. It is not known how many were no represented in the table.
The following query will show all existing targets that are not represented in ResourceTargetOwnerTrustees and should be.
select i.Name as [Target],iat.ResourceTargetGuid
from ItemAppliesTo iat
join Item i on i.Guid = iat.ItemGuid
left join ResourceTargetOwnerTrustees t on t.ResourceTargetGuid = iat.ResourceTargetGuid
where t.ResourceTargetGuid is null
order by 1
Resolution
Using the SQL script below reassigned the security trustee for the filters to that of the Symantec Administrators role. The Symantec Administrators role is static in that it will always exist, and it has the permissions necessary to touch targets etc.
update ResourceTargetOwnerTrustees
set TrusteeGuid = '2E1F478A-4986-4223-9D1E-B5920A63AB41' -- Symantec Administrators
where ResourceTargetGuid in
(select distinct t.ResourceTargetGuid
from ResourceTargetOwnerTrustees t
join ItemClass ic on ic.Guid = t.ResourceTargetGuid
and ic.ClassGuid = 'D1D31520-C3AE-471D-BE99-D0FF1221BBCA'
)
If the query in factor #2 returns any rows then run the following SQL cursor script against the database. It will insert targets not represented in ResourceTargetOwnerTrustees into the table, and assign the role Symantec Administrators as their security trustee.
declare @srg uniqueidentifier
declare @rtg uniqueidentifier
set @srg = '2E1F478A-4986-4223-9D1E-B5920A63AB41' -- Symantec Administrators
declare TargetFixCursor cursor for
select ResourceTargetGuid from ItemAppliesTo
where ResourceTargetGuid not in
(select distinct ResourceTargetGuid from ResourceTargetOwnerTrustees)
open TargetFixCursor
fetch next from TargetFixCursor into @rtg
while @@FETCH_STATUS = 0
begin
insert into ResourceTargetOwnerTrustees (ResourceTargetGuid, TrusteeGuid) values (@rtg, @srg)
fetch next from TargetFixCursor into @rtg
end
close TargetFixCursor
deallocate TargetFixCursor
After performing the previous steps run the “NS.Complete Resource Membership Update…” scheduled task. This should seat the targets, previously changed, so that they will be updated going forward.
update ResourceTargetOwnerTrustees
set TrusteeGuid = '2E1F478A-4986-4223-9D1E-B5920A63AB41' -- Symantec Administrators
where ResourceTargetGuid in
(select distinct t.ResourceTargetGuid
from ResourceTargetOwnerTrustees t
join ItemClass ic on ic.Guid = t.ResourceTargetGuid
and ic.ClassGuid = 'D1D31520-C3AE-471D-BE99-D0FF1221BBCA'
)
If the query in factor #2 returns any rows then run the following SQL cursor script against the database. It will insert targets not represented in ResourceTargetOwnerTrustees into the table, and assign the role Symantec Administrators as their security trustee.
declare @srg uniqueidentifier
declare @rtg uniqueidentifier
set @srg = '2E1F478A-4986-4223-9D1E-B5920A63AB41' -- Symantec Administrators
declare TargetFixCursor cursor for
select ResourceTargetGuid from ItemAppliesTo
where ResourceTargetGuid not in
(select distinct ResourceTargetGuid from ResourceTargetOwnerTrustees)
open TargetFixCursor
fetch next from TargetFixCursor into @rtg
while @@FETCH_STATUS = 0
begin
insert into ResourceTargetOwnerTrustees (ResourceTargetGuid, TrusteeGuid) values (@rtg, @srg)
fetch next from TargetFixCursor into @rtg
end
close TargetFixCursor
deallocate TargetFixCursor
After performing the previous steps run the “NS.Complete Resource Membership Update…” scheduled task. This should seat the targets, previously changed, so that they will be updated going forward.
Feedback
Yes
No
Powered by
