The problem as described by the customer.
Customer has a custom Security Role. He setup his role with the permissions that he considered pertinent to his needs.
Here is what the security role on the parent looks like. Notice the "Read" checkbox for the Default Organization View.
During Differential Replication this custom Security Role changed. Customer found that resource scoping for his security role was cleared on all servers. Other Security Roles containing resource scopes were replicating fine, only the role that contained the resource scope that included the "Default" Organizational View has been effected. The image above is the parent, and is what this role should look like.
Notice most everything is still set in the role, with the exception of the "Default" Organizational View. It has been removed from the role on the child server by Differential replication and left the role in a state unlike all the other servers.
Running Differential replication does not resolve this issue. It seem like only full replication properly restores the role.
Unknown. Permissions attempted to be replicated are inherited from items which are marked as no-replication. Unless the hierarchy is already in place at the time those permissions are created (like during install time), they will not get replicated - even with a full replication.
See HOWTO42294 "Things to know regarding Replication of Security Objects" and HOWTO42320 "Why Item actions and right click menu actions are not replicated when used 'Replicate Now' on Security Roles?"
This issue is under further investigation. So far the current workaround is to delete the affected Security Role on child server and from Windows Groups and Users. After that run Full Replication and it should recreate the Security Role as expected.
Symantec Management Platform 7.0 SP4 HF1