My organization has a small Share Point server (WSS 3.0).Many of the permissions are assigned by putting an Active Directory Security Group as a user inside of a Share Point group. Recently, we noticed that when new users were added to these Active Directory Security Groups, the effective permissions did not update accordingly.

updating ad from sharepoint-71

IRM support has been built in to Share Point as a WSS (now Foundation) technology.

WSS/Foundation don’t have a User Profile Service, so the e-mail address information that RMS requires needs to come from somewhere else.

Lastly, there are a few other things to think about before settling on an approach to working with the Timer Jobs.

Having said all of this, I think the Timer Jobs become essential for many deployments in order to keep the User Information List data up to date.

While deleting and re-adding the user from the Site Collection will import their Profile, and they will display correctly, they will not be continuously sync’d, meaning that further changes to the Profile will not be automatically imported to that Site Collection. On certain Site Collections (such as the Root of a Web Application), we will typically see hundreds of thousands of users in the Site Membership, but very few having Contribute or higher permissions.

We would see a significant performance impact if Share Point were to import all those non-Contribute users every hour.

There is another option, if you’re cool with the implications.

The scope of the Timer Jobs can be modified to ignore the tp_Is Active flag with a little-known parameter of STSADM -o Sync: -Ignore Is Active 1.

This is important since there’s a reasonable chance that at least some users will never be able to access RMS-protected content in Share Point by default, or they may lose access over time without them.