SharePoint's "Big" Problems
It's interesting to me to watch the maturation of a technology, and the market's use of technology. SharePoint (WSS 3.0 and MOSS 2007) is entering its "terrible twos" and, with that, more large enterprises are trying to put SharePoint to use. They're running into some big problems—problems with big lists, big libraries, and big contributing user bases.
Awhile back, Microsoft released the document, Plan for software boundaries. This document set forth limitations of scalability in SharePoint. Most of these limitations can be worked around with good architectural design. Some cannot, sadly illustrating the truism that no tool—not even SharePoint—is the silver bullet. One of the limitations that has been discussed in many places is the 2000 item per list or library limit. This is not (I repeat "not") a hard limit. In fact, in my "summer project," we were dealing actively with a list of 11,000 items. It's a limit related to views, which can be addressed through views and indexing.
A limit that has not received enough attention is limits that arise due to SharePoint's security implementation—limits related to the number of users and permissions in a site collection. Unfortunately, the document's lack of detail underplays limits that can be quite problematic in some scenarios. This week, a number of my colleagues were discussing real world encounters with these limitations. So in the event that this may save you headaches now or in the future, I'd like to summarize the limits and provide some example scenarios. My goal is to help you identify whether you are, or might become, a ‘victim' of these limits. Later in this article, I'll point you to the resources you need for more detail, and I'll propose some solutions for Microsoft to consider in Office 14.
1. 600 to 1000 unique list-item permissions. If you do a lot of "inheritance breaking" to create unique permissions within a list or library, this limit might hit you. A common scenario involves a list where a user can add an item, then a custom workflow is used to change permissions on that item to provide Edit Item permission to a "reviewer," while preventing other non-reviewers in the list from modifying that item. But if you end up with more than 600 to 1000 items with unique permissions in a list, it will start to be problematic.2. 1500 to 2000 contributing users in a site collection. Yup, you read that right. You can't have more than 1500-2000 users contributing in a site. The limit is really 1500-2000 identities in the Site Collection User Info Gallery, aka the "SPWeb.SiteUsers." A user ends up in this list if you add them directly to the site collection user list; create a permission for an object assigned to a user who's not already in the list; or if the user is in a group that has permissions to the site and the user contributes to the site—is added to the Created By, Last Modified By, or Assigned To fields. The key here is those three fields. You can expose your site to millions of readers by using groups, or with anonymous access. 3. Approx. 2000 users or groups per SharePoint group. This is actually related to the 2000 item limit in list views. 4. Unique permissions (Access Control Entries or ACEs) per Access Control List (ACL). Behind the scenes, an ACL cannot be larger than 64KB. This translates to roughly 1000 users being individually assigned permissions on one object. 5. 1024 total (nested) Active Directory (AD) group memberships per user. This is a limit that affects other Windows technologies as well.
Are you likely to be "hit" by one of these limits? Some can be worked around through informed design. Others cannot. If these limits are in your present or future, then you must read Eli Robillard's detailed coverage of the limits at Eli's blog. Eli Robillard, also a SharePoint MVP, is a popular speaker, co-author of Professional SharePoint 2007 Development (Wrox), the founder of the Toronto SharePoint Users Group. The work he's done, and the great contributions of Todd Bleeker, Todd Klindt, Joel Oleson and Keith Ritchie deserve a huge "shout out." I know the details about these issues will evolve as more feedback is obtained from customers and as the SharePoint code and architecture is examined in more detail.
Indexing, search, the security-trimmed UI, and basic functionality are compromised when these limits are hit, and (as usual), the error messages that arise are not informative enough. There's no doubt that large collaborative sites won't be supported by SharePoint without major customization of security-related functionality. While site collection architecture can overcome some of these limits, some will be show-stoppers. Imagine trying to build a "forum" site with more than 2000 users. If each user is supposed to be able to add posts and modify (only their own) post, this would simply not work due to both #1 and #2 above. I know that Microsoft has to "draw the line" at some point, and release a finished product to market. What troubles me is that SharePoint is being sold as a silver bullet across six different scenarios, and these limits have real impact on several of them. They mean some significant coding of custom security interfaces or the choice of another product besides SharePoint.
My colleagues' discussion of these security related limits really came to a head last week, so there's a lot more to be learned. At this point, I'd like to propose the following (perhaps completely naïve) solutions to Microsoft for Office 14:
• Support true "contribute" role assignments, in which a user can add items and read items and modify only their own items. Windows Server 2008 now supports the "Owner Rights" identity which could be an approach, but there could be others. This would address a super-common security requirement that SharePoint just misses right now. It would prevent some implementations from running into #1.
• To further address #2, the SharePoint team should consider "template-izing" item permissions. Ask the Directory Services team how they managed to cut the size of NTDS.DIT in Windows Server 2003 by doing so. My guess is there is guidance, if not answers, in that team's work.
• #2 will just have to be fixed. Period.
• In my naïve world, I'd want the option to offload the entire account management to Active Directory, as Microsoft did with Exchange 2000 (for those of you young kids, previous versions of Exchange had an independent directory) . SharePoint's group management is great for two major reasons: it supports mixed environments with AD and other authentication providers; and it provides a group management interface to users so non-technical users can manage group membership. The latter functionality should have been put in AD--oh, about 9 years ago. Maybe SharePoint's functionality and user interface can be a layer over AD. I know that'd be complicated, particularly when it came time to support forms-based authentication (FBA) and such, but it would be great.
• Much clearer communication about SharePoint's limits—security and otherwise. Not just one line in one paper on TechNet, but real "call outs", including scenario-based examples, of where SharePoint will fail out-of-the-box.
Knowing Microsoft's history, I've got to think the company will be investing heavily in Office 14 in areas that improve scalability, in solutions for enterprises, and in modifying SharePoint to better support Software-Plus-Services. So I'm hopeful that some of these limitations, which clearly affect scalability, will in fact be addressed.
And here are some open questions to you, the community:
• What security related limits have you run into in your environments? What scenarios have you found difficult or impossible to support?
• Has anyone really "beat up" (tested) how the new OWNER RIGHTS identity on NTFS works with SharePoint indexing and security-trimmed results? After some meditation, I can imagine some configurations that could be very difficult to "reflect" correctly in indexing. I haven't dug into this yet. Have you? (BTW, if you don't know about OWNER RIGHTS, it's the best security addition to Windows file servers since NTFS itself. Check it out if you manage file servers.)
I'll close this discussion with my "bottom line" with SharePoint: It's an awesome product. It's innovative, it's effective in many many scenarios, and (best of all) it has great potential for user adoption thanks to its UI and tight integration with well-known tools (i.e. the Office clients). I'm a huge believer that with the insane growth of SharePoint utilization in enterprises large and small, and the resources Microsoft is pouring into the product, we have the unique opportunity and responsibility to help Microsoft better understand what we're needing the product to do, and where it's failing to deliver. Microsoft is really trying to listen to customers and community but (believe it or not) even Microsoft's resources are limited. We need to help that listening happen, request clarity about this incredible product's strengths and weaknesses, and be patient as Microsoft addresses the weaknesses we all discover as the product evolves.
Until next week, all the best! Dan Holme
Awhile back, Microsoft released the document, Plan for software boundaries. This document set forth limitations of scalability in SharePoint. Most of these limitations can be worked around with good architectural design. Some cannot, sadly illustrating the truism that no tool—not even SharePoint—is the silver bullet. One of the limitations that has been discussed in many places is the 2000 item per list or library limit. This is not (I repeat "not") a hard limit. In fact, in my "summer project," we were dealing actively with a list of 11,000 items. It's a limit related to views, which can be addressed through views and indexing.
A limit that has not received enough attention is limits that arise due to SharePoint's security implementation—limits related to the number of users and permissions in a site collection. Unfortunately, the document's lack of detail underplays limits that can be quite problematic in some scenarios. This week, a number of my colleagues were discussing real world encounters with these limitations. So in the event that this may save you headaches now or in the future, I'd like to summarize the limits and provide some example scenarios. My goal is to help you identify whether you are, or might become, a ‘victim' of these limits. Later in this article, I'll point you to the resources you need for more detail, and I'll propose some solutions for Microsoft to consider in Office 14.
1. 600 to 1000 unique list-item permissions. If you do a lot of "inheritance breaking" to create unique permissions within a list or library, this limit might hit you. A common scenario involves a list where a user can add an item, then a custom workflow is used to change permissions on that item to provide Edit Item permission to a "reviewer," while preventing other non-reviewers in the list from modifying that item. But if you end up with more than 600 to 1000 items with unique permissions in a list, it will start to be problematic.2. 1500 to 2000 contributing users in a site collection. Yup, you read that right. You can't have more than 1500-2000 users contributing in a site. The limit is really 1500-2000 identities in the Site Collection User Info Gallery, aka the "SPWeb.SiteUsers." A user ends up in this list if you add them directly to the site collection user list; create a permission for an object assigned to a user who's not already in the list; or if the user is in a group that has permissions to the site and the user contributes to the site—is added to the Created By, Last Modified By, or Assigned To fields. The key here is those three fields. You can expose your site to millions of readers by using groups, or with anonymous access. 3. Approx. 2000 users or groups per SharePoint group. This is actually related to the 2000 item limit in list views. 4. Unique permissions (Access Control Entries or ACEs) per Access Control List (ACL). Behind the scenes, an ACL cannot be larger than 64KB. This translates to roughly 1000 users being individually assigned permissions on one object. 5. 1024 total (nested) Active Directory (AD) group memberships per user. This is a limit that affects other Windows technologies as well.
Are you likely to be "hit" by one of these limits? Some can be worked around through informed design. Others cannot. If these limits are in your present or future, then you must read Eli Robillard's detailed coverage of the limits at Eli's blog. Eli Robillard, also a SharePoint MVP, is a popular speaker, co-author of Professional SharePoint 2007 Development (Wrox), the founder of the Toronto SharePoint Users Group. The work he's done, and the great contributions of Todd Bleeker, Todd Klindt, Joel Oleson and Keith Ritchie deserve a huge "shout out." I know the details about these issues will evolve as more feedback is obtained from customers and as the SharePoint code and architecture is examined in more detail.
Indexing, search, the security-trimmed UI, and basic functionality are compromised when these limits are hit, and (as usual), the error messages that arise are not informative enough. There's no doubt that large collaborative sites won't be supported by SharePoint without major customization of security-related functionality. While site collection architecture can overcome some of these limits, some will be show-stoppers. Imagine trying to build a "forum" site with more than 2000 users. If each user is supposed to be able to add posts and modify (only their own) post, this would simply not work due to both #1 and #2 above. I know that Microsoft has to "draw the line" at some point, and release a finished product to market. What troubles me is that SharePoint is being sold as a silver bullet across six different scenarios, and these limits have real impact on several of them. They mean some significant coding of custom security interfaces or the choice of another product besides SharePoint.
My colleagues' discussion of these security related limits really came to a head last week, so there's a lot more to be learned. At this point, I'd like to propose the following (perhaps completely naïve) solutions to Microsoft for Office 14:
• Support true "contribute" role assignments, in which a user can add items and read items and modify only their own items. Windows Server 2008 now supports the "Owner Rights" identity which could be an approach, but there could be others. This would address a super-common security requirement that SharePoint just misses right now. It would prevent some implementations from running into #1.
• To further address #2, the SharePoint team should consider "template-izing" item permissions. Ask the Directory Services team how they managed to cut the size of NTDS.DIT in Windows Server 2003 by doing so. My guess is there is guidance, if not answers, in that team's work.
• #2 will just have to be fixed. Period.
• In my naïve world, I'd want the option to offload the entire account management to Active Directory, as Microsoft did with Exchange 2000 (for those of you young kids, previous versions of Exchange had an independent directory) . SharePoint's group management is great for two major reasons: it supports mixed environments with AD and other authentication providers; and it provides a group management interface to users so non-technical users can manage group membership. The latter functionality should have been put in AD--oh, about 9 years ago. Maybe SharePoint's functionality and user interface can be a layer over AD. I know that'd be complicated, particularly when it came time to support forms-based authentication (FBA) and such, but it would be great.
• Much clearer communication about SharePoint's limits—security and otherwise. Not just one line in one paper on TechNet, but real "call outs", including scenario-based examples, of where SharePoint will fail out-of-the-box.
Knowing Microsoft's history, I've got to think the company will be investing heavily in Office 14 in areas that improve scalability, in solutions for enterprises, and in modifying SharePoint to better support Software-Plus-Services. So I'm hopeful that some of these limitations, which clearly affect scalability, will in fact be addressed.
And here are some open questions to you, the community:
• What security related limits have you run into in your environments? What scenarios have you found difficult or impossible to support?
• Has anyone really "beat up" (tested) how the new OWNER RIGHTS identity on NTFS works with SharePoint indexing and security-trimmed results? After some meditation, I can imagine some configurations that could be very difficult to "reflect" correctly in indexing. I haven't dug into this yet. Have you? (BTW, if you don't know about OWNER RIGHTS, it's the best security addition to Windows file servers since NTFS itself. Check it out if you manage file servers.)
I'll close this discussion with my "bottom line" with SharePoint: It's an awesome product. It's innovative, it's effective in many many scenarios, and (best of all) it has great potential for user adoption thanks to its UI and tight integration with well-known tools (i.e. the Office clients). I'm a huge believer that with the insane growth of SharePoint utilization in enterprises large and small, and the resources Microsoft is pouring into the product, we have the unique opportunity and responsibility to help Microsoft better understand what we're needing the product to do, and where it's failing to deliver. Microsoft is really trying to listen to customers and community but (believe it or not) even Microsoft's resources are limited. We need to help that listening happen, request clarity about this incredible product's strengths and weaknesses, and be patient as Microsoft addresses the weaknesses we all discover as the product evolves.
Until next week, all the best! Dan Holme
Entradas
No hay comentarios.:
Publicar un comentario