{"id":1059,"date":"2012-12-04T07:32:35","date_gmt":"2012-12-04T07:32:35","guid":{"rendered":"https:\/\/poiseddevelopers.com\/reality-tech\/?p=1059"},"modified":"2024-04-26T12:45:48","modified_gmt":"2024-04-26T12:45:48","slug":"ad-user-group-membership-not-propagating-into-site-collections","status":"publish","type":"post","link":"https:\/\/poiseddevelopers.com\/reality-tech\/ad-user-group-membership-not-propagating-into-site-collections\/","title":{"rendered":"AD User group membership not propagating into site collections"},"content":{"rendered":"<h4>AD User group membership propagation issue<\/h4>\n<p>In some rare instances, users may exist within a Site Collection that don\u2019t receive their AD group membership updates.<\/p>\n<p>I\u2019ve traced this down to recreated AD users that have the same account name, yet a new SID. The solution is to wipe the user references from the site collection.<\/p>\n<p>Be forewarned, any user permissions will be wiped as well. One more excellent reason to only use AD groups for assigning permissions in SharePoint!<\/p>\n<p>You can see this internal list and even delete the user by adapting this URL:<br role=\"presentation\" data-uw-rm-sr=\"\" \/>http :\/\/WebApp\/ManagedPath\/namedSiteCollection\/_layouts\/people.aspx?MembershipGroupId=0<\/p>\n<p>Better to do it in PowerShell for speed, extensibility, consistency, and across many site collections. The trick comes down to a specific way to eliminate the user from the site collection:<\/p>\n<div>\n<div id=\"highlighter_528878\" class=\"syntaxhighlighter powershell\">\n<table border=\"0\" cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td class=\"gutter\">\n<div class=\"line number1 index0 alt2\">1<\/div>\n<\/td>\n<td class=\"code\">\n<div class=\"container\">\n<div class=\"line number1 index0 alt2\"><code class=\"powershell variable\">$RootWeb<\/code><code class=\"powershell plain\">.SiteUsers.Remove(<\/code><code class=\"powershell variable\">$MyUser<\/code><code class=\"powershell plain\">)<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n<p data-uw-rm-sr=\"\">Note trying $RootWeb.Users.Remove($MyUser) or $RootWeb.AllUsers.Remove($MyUser) will not work.<\/p>\n<p>To finish it off, I prefer to re-add the user:<\/p>\n<div>\n<div id=\"highlighter_839508\" class=\"syntaxhighlighter powershell\">\n<table border=\"0\" cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td class=\"gutter\">\n<div class=\"line number1 index0 alt2\">1<\/div>\n<\/td>\n<td class=\"code\">\n<div class=\"container\">\n<div class=\"line number1 index0 alt2\"><code class=\"powershell variable\">$RootWeb<\/code><code class=\"powershell plain\">.EnsureUser(<\/code><code class=\"powershell variable\">$MyUser<\/code><code class=\"powershell plain\">)<\/code><\/div>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<\/div>\n<p>Here\u2019s the full script, where I traverse through site collections in a Web App, filter them based on criteria (in this case the managed path), then carefully take the action on a list of users (one or more, comma separated), and output any failures along the way:<\/p>\n<pre lang=\"php\">  Start-SPAssignment \u2013Global\r\n$UsersToWipe = \"DOMAINPoorBloke\"\r\n$UsersToWipeArray = $UsersToWipe.Split(\u201c,\u201d)\r\n \r\n$siteUrl = \"http :\/\/SharePoint\" \r\n \r\nWrite-Host \"script starting $(get-date)\"\r\n \r\n$rootSite = New-Object Microsoft.SharePoint.SPSite($siteUrl)\r\n$spWebApp = $rootSite.WebApplication \r\nforeach($site in $spWebApp.Sites)\r\n{\r\n \r\n  \r\n if ($site.Url -notlike \"$siteurl\/SpecificPath\/*\") \r\n {\r\n     Write-Host \"Fast Skipping $($site.Url)\"\r\n }\r\n else\r\n  { \r\n   $rootWeb = $site.RootWeb;\r\n \r\n   foreach ($MyUser in $UsersToWipeArray)\r\n   {\r\n        try\r\n        {\r\n            try\r\n            {\r\n                $user1 = $RootWeb.EnsureUser($MyUser)\r\n            }\r\n            catch\r\n            {\r\n                Write-Host \"x1: Failed to ensure user $($MyUser) in $($Site.url)\"\r\n            }\r\n             \r\n            try\r\n            {\r\n                $RootWeb.SiteUsers.Remove($MyUser)\r\n                $RootWeb.update()\r\n            }\r\n            catch\r\n            {\r\n                Write-Host \"x2: Failed to remove $($MyUser) from all users in $($Site.url)\"\r\n            }\r\n             \r\n            try\r\n            {\r\n                $user1 = $RootWeb.EnsureUser($MyUser)\r\n            }\r\n            catch\r\n            {\r\n                Write-Host \"x3: Failed to ensure user $($MyUser) in $($Site.url)\"\r\n            }\r\n \r\n       }\r\n       catch\r\n       {\r\n            Write-Host \"x4: other failure for $($MyUser) in $($Site.url)\"\r\n       }\r\n   }\r\n } #Site to process \r\n   \r\n    $site.Dispose();  \r\n } #foreach Site\r\n \r\n   \r\nWrite-Host \"script finishing $(get-date)\"\r\n \r\n \r\nStop-SPAssignment \u2013Global<\/pre>\n","protected":false},"excerpt":{"rendered":"<p>AD User group membership propagation issue In some rare instances, users may exist within a Site Collection that don\u2019t receive their AD group membership updates. I\u2019ve traced this down to recreated AD users that have the same account name, yet a new SID. The solution is to wipe the user references from the site collection. [&hellip;]<\/p>\n","protected":false},"author":6,"featured_media":1062,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[26],"tags":[],"class_list":["post-1059","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell"],"acf":[],"_links":{"self":[{"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/posts\/1059","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/comments?post=1059"}],"version-history":[{"count":1,"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/posts\/1059\/revisions"}],"predecessor-version":[{"id":1063,"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/posts\/1059\/revisions\/1063"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/media\/1062"}],"wp:attachment":[{"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/media?parent=1059"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/categories?post=1059"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/poiseddevelopers.com\/reality-tech\/wp-json\/wp\/v2\/tags?post=1059"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}