4

I investigated one day, that I can't add some specific user to any group of some specific collection, I can add them directly to list/library/page only. For example "Xavier Xovi" can't be member of any group of Marketing, but his account can be added to Technology, Sales or Home coll. "Daniel Donn" can't be member of Sales, but his account can be added to Marketing, Home and so on.

I have 6 problematic users right now, all works under old MOSS 2007 portal without problems, even on testing 2010 farm without problems, but fails on product farm. No error message, no on-screen warning, I just get blank group page without my user. Nothing new in event log, ULS logs, users are properly synchronized with AD and they are members of group in another groups, but groups for each of them cannot be more then 4. Any idea whats happening?

[edit #1, 05. 11. 2011] I can see them in groups thru Designer, they are already added. But even if I am owner of the group, SC Admin, Farm Admin and lord of all, I can't see them via classic portal UI.

[edit #2, 05. 11. 2011] The clue is in User Information List in affected SCs, where users completely missing and cannot be added or migrated. If I click on user name in page footer (Created at... or Last modified at...) I can see only error page, because links headings to wrong user ID. Search works, My Site works. When I open another SC and its UIL, users are there and links properly heading to their My Site profile page. No, I can't delete them, they are owners of a huge number of files.

[edit #3, 16. 03. 2012] Problem was open as issue in Microsoft support and the clue is definitely in user list (userdisp.aspx page). The page is buggy, sometimes cannot be render (Render fail error in an attempt to show name filters) and even paging sometimes missing.The only question is whether it is caused by migration tool or not (and how to solve it). Captured correlation ID is not in any log and developer dasboard shows nothing. The userdisp.aspx file from product enviroment is very similar to testing one, there is just one exception in SharePoint:DelegateControl Scope atribute. Testing farm (where everything works properly) has Scope set to "Farm", product farm to "Web", but change did not bring any solution.

[edit #4, 10. 04. 2012] Our nearly one year issue has solution, see answer below please. We tested MS solution this weekend and we are little embarrassed. We ran content deployement job three times, each try ended with different result but third try was quite good... Permission works, even a lot of things, that none of migration tools can deploy correctly was there (like CEWP above the list, color overlays, quick launch menu, list highlighting feature and so on), but there is also a huge number of small things, that must be manually corrected after deploy like home pages, system account at all folders in all libraries or web patrs in pages at all. So, we must decided what is better for us, permission issue or another small "migration" for next 9 or 10 weekends...

See resolution from Microsoft below please and if you have another idea how to fix it, write it down please.

Improve this question
4
  • you say the user is actually added but cannot be seen in web UI. but what about the User's permissions, are the group permissions actually applied? Commented Aug 29, 2011 at 13:26
  • Yes, I have no problems with groups, they are visible and permission works. And yes, users are (sometimes) members of groups too, but they are not visible inside via GUI either (in afected SC) Commented Aug 29, 2011 at 13:44
  • Do you have the same issue if you switch to another view? Commented Aug 29, 2011 at 20:38
  • I dont understand you, which view you mean? Does not matter which view you choose, which person from six mentioned above you choose or which SC of mentioned you choose. We are four with admin rights and permission errors has all of us. Commented Aug 30, 2011 at 10:24

3 Answers 3

Reset to default
2

Site permissions is where all the permission management begins. More specifically the root site permissions (root site is the top site in a site collection). These are the permissions that all sub-items (sub-sites, libraries and lists, folders and document sets, documents and items) will inherit. That’s why it is important to carefully design the site permissions as the whole site will use these by default (unless the inheritance chain is broken). Our advice is to try to find some general permissions so that you do no need to break inheritance chain too often.

When you grant site permissions you can use AD groups, AD users and SharePoint groups. You can either add users to some of SharePoint groups or grant the permissions directly (aka attach permission level to user or group). I’m not sure why Microsoft recommends granting permissions though SharePoint Groups, because in many cases it makes a little sense. Probably because of in-built functionality that is attached to SharePoint groups or that when using SharePoint groups, you are able to move your site more easily to different domain (for example from development to cloud service, BPOS anyone?). My advice is that go with SharePoint groups or grant directly, but try not to overuse SharePoint Groups as it only causes confusion in the end.

Well, Everything starts from Active Directory. If Active Directory is a mess, it should be fixed before designing how to manage rights in SharePoint. If Active Directory is well maintained it also benefits the other applications that integrate to AD (for example normal file sharing and NTFS permissions, or systems like Microsoft CRM).

Use SharePoint groups sparingly. Try to utilize the predefined SharePoint groups that are created in SharePoint sites, if possible. Think twice before defining new Web Application policies or Site Collection Permission Levels, and create new ones only if there isn’t better way around it.

Improve this answer
1
  • Great answer and I 100% agree, but unfortunatelly id does not help to my case. On one of the afected SC are 9 SP groups inherited thru 8 sites and inside are individual users (properly synchroniyzed with well designed clean AD). Commented Mar 16, 2012 at 14:53
2

User list corruption and your problem is known to us. The only workaround is to use content deployment to move this site collection to another DB. I spoke again with Engineer that dealt couple months ago with identical issue on Customer’s side. Guess what was the name of the 3rd party tool they used… (the same as we had, DocAve from AvePoint).

They tried almost every possible way to fix it:

  • Full backups and restorations
  • Exporting and importing
  • Migrating users using stsadm and PowerShell commands
  • Recreating people.aspx page (possible corruption)
  • Migrating Content DBs via detach/attach method
  • And many smaller things….

All above failed. Only Content Deployment worked. They determined as a root cause: dbo.userinfo table corruption made while performing migration from 2007 to 2010. They noticed some guids are different for affected users and are not recognized by people.aspx and userdisp.aspx (you can check and confirm if this is the case). As we do not support environments with direct DB modification, CD was the only solution.

This is white paper for content deployment (http://technet.microsoft.com/en-us/library/cc627268.aspx) with full walkthrough. It is very easy to follow as its contain a lot of necessary details. And this would be the plan for us (all the details included in White Paper):

  1. Create new content DB on that particular Web application
  2. Create a destination site collection (try to create it under the same managed path) – DO NOT USE TEMPLATE, it will fail if you do.
  3. Enable incoming content deployment jobs in Central Administration
  4. Create a content deployment path.
  5. Create a content deployment job – as you can reuse that job and path later for further testing
  6. Deploy the source site to destination site

Of course, you will now have this SC under different URL, but this can be fixed with 3 commands if you require old URL:

---

[Edit 26. 4., statement from AvePoint after some tests in our enviroment]

When migrating the users (at Site Collection level or List level), extra versions are added to the users by mistake. Therefore, the level of the users will be shown as “2” in SQL (by default it should be “1”) which cannot be recognized by SharePoint. Please note that the issue is not related to dbo.uerinfo table corruption as mentioned by Microsoft, because we never modify anything in this table.

We will fix this issue in our later version of DocAve. But if the customer has run the Migration job, they need to delete the destination Site Collection and rerun the job.

Improve this answer
4
  • Are you saying the issue started after migrating the site from a 2007 farm to your 2010 farm using DocAve? Have you contacted AvePoint about this issue? Commented Apr 10, 2012 at 19:06
  • Strong words, I know. Microsoft support wrote, that this problem is already in their database for half a year and the migration scenario was the same with the same tool. Yes, I'm just about in the middle of e-mail to AvePoint, but I don't know how to write everyhting into one e-mail clearly for investigating and don't trigger a panic. All I want is just to help someone else in future, who may get the same problems if there is really a bug. Commented Apr 11, 2012 at 7:16
  • Anyway, this procedure solve the error with corrupted dbo.userinfo table and I don't want to blame any specific tool, it is just a clue how it happened to us. Commented Apr 11, 2012 at 7:27
  • Statement from AvePoint added Commented Apr 26, 2012 at 15:18
0

I found that the group settings had only the group owner the ability to add other group members. there is also an option to have any group member add another.

Improve this answer
1
  • Groups working almost properly, users are inside, but not wisible via GUI. Problem is with users themselves, with user list or user .aspx pages at all. Commented Mar 16, 2012 at 14:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.