User Information not Changing in Site Collection After Being Updated in Active Directory

Hey Guys,

This is more a follow up most to my previous post on User can’t access SharePoint site after granting appropriate permissions, however I’ve seemed to find a better solution.

Recently a user had their name changed in Active Directory, but the problem was this name change was not reflected in their site collection. The thing that made this weird was that it was only in this one site collection that there was a problem. I’ve checked the User Profile in Central Admin and all looks good. I’ve tried adding the user to another site and all looks good. But for some reason this one site collection was not properly updating the username.

Now when you add a user to a site collection your creating an instance of that user in the hidden user information list: http://Server/sites/YourSiteCollection/_catalogs/users/details.aspx.

This list is what dictates what information a user would have presented about themselves in a Site. As long as a user remains active on a site i.e. updating/modifying files, this hidden user list would get synched with user profiles in Central Admin. Now in my case for some reasone this list was not getting updated by the user synch. Unfortunately I have not yet found a solution to why it was not getting updated but I have found a work around to fix the individual user who had their information changed.

The fix is to have them deleted completely from the site collection. My previous post was a bit of a pain to do but really all you would need to do is view all people of the site using this view:

From there you can select the user and go to Actions >  Delete Users from Site Collection. After you should be able to re-add the user and it will pull their information properly from Active Directory.

Hope this helps


PowerShell to determine SharePoint User Permissions

I came across a great post by Aptillon for using PowerShell to determine who has access to what at a SiteCollection:

The custom function (Get-SPUserEffectivePermissions) was great for determining access people have on sites that do not inherit permissions from the parent site.

It could even generate a report across the farm for all items:

PS C:\>$user = "domain\username"
PS C:\>Get-SPSite -Limit All | Get-SPWeb | %{$_.Lists | %{$_.Items | Get-SPUserEffectivePermissions $user}} | Export-Csv -NoTypeInformation -Path C:\report.csv

Check it out as it was a very helpful tool.

User can’t access SharePoint site after granting appropriate permissions

We have been having an issue with a couple of users in which a site admin would grant them access to either a subsite or a document library. But when the user tries to access the location they recieve the standard SharePoint Page stating current user does not have access. So what was going on, if we just granted them access?

It turned out these users that were having problems were either contractors/summer students/interns. All people who have been here in the past but had their Active Directory account temporarily disabled. This in turn must have set a flag on the SharePoint sites in which the users previously had access to from past positions, that their accounts were disabled.

The fix: was to go through the site collection and remove the user from all locations that they had had access. Once they were fully removed everywhere on the site collection we had to go back through and re-add them. Once they have been re-added to the site collection they still maintained the incorrect user information i.e. Title, Name, etc… This information is stored in a hidden User Information List on site collections: http://<SiteCollectionUrl>/_catalogs/users/detail.aspx. The user information list needs to be synced up by running the appropriate User Profile Service Aplication Proxy timer jobs:

“User Profile Service Application Proxy – User Profile to SharePoint Full
“User Profile Service Application Proxy – User Profile to SharePoint Quick

Generally these jobs are scheduled to run every hour and every couple of minutes respectively, so you may not need to run them immediately and could just wait for the next run time. Once they have run you should see the user information updated and the users should be able to access the sites now.

A real handy tool was to use the Check Permissions tab in the permissions ribbon as well as the powershell script developed by Aptillon

*Update: It appears this fix also works for the case of past users with the same username as new hires. i.e. Bob Dole (username: Bdole) leaves the company and Bill Dole (username: Bdole) joins the company. Bill would run into problems when trying to access a site as it would resolve him as Bob. The fix above resolves this.

Hope you found this helpful