Eli Robillard's World of Blog.

When the Wall Street herd began to stumble over their own their mortgage inventory, there were signs of rockier times ahead. Now that several giants lay collapsed, people like our CEO Greg Brill are writing about what it was like to watch the race to self-destruction unfold, and how they read the signs that clearly said, "now is a good time to evolve."

Read it here: From Wall Street to Dubai: Diary of a tech entrepreneur's adventures in the hot zone

A good adjunct to Greg's article is the lesson that that there were people who had the common sense to get out of the sub-prime mortgage business. A Bloomberg article (Toronto-Dominion Avoids Subprime as Banks' Costs Rise, May 2008) describes how Ed Clark, CEO of TD Bank sold off TD Waterhouse's exposure in 2005. "'I'm an old-school banker,' Clark told reporters last month in Calgary after the annual shareholder meeting. 'I don't think you should do something you don't understand, hoping there's somebody at the bottom of the organization who does. . . . The whole thing didn't make common sense to me.'"

So there's the lesson for the day, it's ageless, and it takes many forms. There are no dumb questions. When something doesn't make sense, resolve it. Traditions and so-called "best practices" come into being because they work for us, but they should never be frozen or used in place of thought and common sense. Each of us in responsible for our own actions and their effects. Traditions, including best-practices and business rules, must be continually questioned and allowed to evolve. A tradition without a means to evolve is merely a symbolic gesture that has lost its original purpose. Many would say, "assess the risk and resolve the question in accordance with that risk," but my mantra remains, "If it's worth doing, it's worth over-doing." Miyamoto Musashi wrote in 1643, "If you do not pursue a genuine path to its consummation, then a little bit of crookedness in the mind will later turn into a major warp. Reflect on this" (The Book of Five Rings, Thomas Cleary translation).

Infusion's path is great technology, not financial services, not the Microsoft stack. It's great to work in a company that evolves and asks the questions it takes to keep us on that path. What's your path?

Members received an update last week, I just wanted to mention here that summer's over and meetings start back up tonight, Wednesday, September 28!

Topic: Jignesh Shaw, Applications Development Manager at Cyberplex Inc. will be doing a presentation on InfoPath 2007 forms development for Forms Server in MOSS 2007 - including tips, tricks and best practices for developing InfoPath forms. Examples will include building an InfoPath form for data collection via a public facing site where anonymous users can submit their data.

Date:                Wednesday, September 24, 2008
Address:          Nexient Learning
                        2 Bloor Street West
Time:               6:00pm

To RSVP, please email susie.ibbotson@cyberplex.com

Next month look for another great session from Bill Brockbank on STSDEV. But first, tonight!

This summarizes the hard limits and recommended guidance for Groups, Access Control Lists (ACLs) and securable objects in SharePoint 2007.

Unique accounts or groups per SharePoint Group: ~2000. This is the identical with the guidance for any large SharePoint list as covered by the Working with large lists in Office SharePoint Server 2007 whitepaper. Lists can handle thousands of items, but performance of a Views (i.e. while viewing or updating membership) will degrade after 200 items and become unacceptable towards 2000 because the underlying SQL queries are not paged or filtered. Note that the next limitation (see Users per SharePoint ACL, below) will affect the ability to index any item (or list) you apply such a large ACL to. Resolution: Use a third-party tool to manage large SharePoint Groups or re-think your design to include AD groups. Mitigation: When possible, rather than assigning users membership in a SharePoint Group, assign users to an AD group and then assign the AD group membership to the SharePoint Group.

Users per SharePoint ACL: Query results must not exceed 64k, or ~1000 users per ACL. When exceeded, the "Parameter is incorrect" error is thrown causing crawling to fail on the item. This issue affects indexing, but does not otherwise affect SharePoint. The limit is noted by Joel Oleson in the comments of a "2003 to 2008 security changes" post and the Best Practices for SharePoint Search article on TechNet. The issue is not SharePoint-specific and will affect any content crawled with large ACLs including file system objects like Network Shares. KB article 885482 describes the cause as "The maximum buffer size of the InitializeAcl function is 64 KB. Therefore, the maximum size of an ACL in Windows, including the access control entries (ACEs) that are contained in the ACL, is 64 KB." Resolution: Either exclude the item from indexed content, or remove entries from the ACL. Mitigation: This is a rare issue normally avoided through sound design. However, since AD groups are not expanded when the ACL is read, assigning individuals to AD Groups rather than SharePoint Groups will mitigate the limit.

Active Directory groups per-user: 1024. Each membership increases a user's "SID count" and the limit on the token bag is 1024. When the limit is exceeded the error reads, "During a logon attempt, the user’s security context accumulated too many security IDs." The whitepaper Addressing Problems Due to Access Token Limitation discusses the issue in depth, and KB 906208 describes the error. Consider this limit if AD groups are to be used to manage SharePoint groups. Resolution: Remove the users from one or more AD groups to reduce the SID count. You can verify the issue with the Group Membership Evaluation feature of the Ntdsutil.exe tool. Mitigation: Manage users in SharePoint Groups rather than AD groups if growth would require any user to be a member of more than 1024 groups.

Recommended Guidance
The Plan for Software Boundaries whitepaper contains guidelines for "people objects" but its guidance for security principals is (politely) less-than-useful. For example, the guidance that "You can add millions of people to your Web site by using Microsoft Windows security groups to manage security instead of using individual users" says nothing about how many people can (or should) be added to a SharePoint Group and ignores the SID limits of AD groups. It would also lead you to believe that it's an acceptable option to use local Windows security groups to manage permissions rather than domain accounts. In a nutshell, that would be a bad idea if your farm will ever have more than one server.

There are many MSDN and TechNet articles with recommendations on what granularity of permissions is "right" but the one simply named Plan site security is the most detailed and provides the best example. To summarize and disambiguate the best practices and recommendations:

1. If many securable objects share the same ACL, then group them into a container with that ACL. This applies equally to list items within lists, or libraries within sites. If the permission change is a temporary state in a securable object's lifecycle (for example to assign reviewer permissions during a workflow) then reset the permissions to inherited when the temporary state is complete (e.g. at the end of the workflow). [Update 2008-09-12 TB] Avoid unique permissions on folders, as Flat views will not secure folder content as expected.
   
   
2. The more ACLs you create, the more ACLs you have to manage. I know, I know, it's self-evident, no? How I wish it were. A problem of some articles is that they can be interpreted to recommend moving the problem rather than solving it. For example: "Minimize the use of custom or fine-grained permissions. The more fine-grained permissions that are applied, the more difficult it is to track who has access to what." Well duh. The problem is that not applying permissions does not remove the business need to have permissions. If the issue is the tools and not the limits of the platform, the correct guidance should be "if management or reporting tools don't work the way you want. . . ." Better, it deserves to be a recommendation of its own.
   
   
3. If management or reporting tools don't work the way you want, then build or buy better management or reporting tools. DeliverPoint is one option. [I'll continue update this post as others are suggested.]
   
   
4. Understand the strengths and weaknesses of managing users in SharePoint Groups vs. Active Directory. A strength of SharePoint Groups is allowing the same people responsible for building teams in an enterprise to form their own groups. IT has been the bottleneck for too long. Advantages of SharePoint groups are decentralized maintenance, isolation by Site Collection, the ability to query it with the API without adding to DC load, and the ability to integrate it as necessary with external Authorization Providers (AD, FBA, etc.). This last point makes SharePoint groups preferable for extranets and mixed authentication zones, allowing internal users to authenticate through AD and external users through another AuthZ provider.
   
   AD Domain Groups may be preferred for central management and a standardization of tools. Unfortunately these tools are not usually built for or available to users outside of IT and support services. AD groups are also not visible from within SharePoint without custom code or third-party components.
   
   Unless your AD groups are subject to strict discipline so that "Help Desk" only contains people from Help Desk, and not people who for any reason one day needed access to the Help Desk's files (e.g. senior management or Gladys from accounting), it is best to start fresh with new AD groups for SharePoint. Since 95% of companies did not have that discipline when securing network shares, you should start fresh unless you can both prove that your AD groups are clean, and policies are in place so groups will not be corrupted when people start applying them to SharePoint.
   
   [Update 2008-09-12: This entire section was rewritten based on TB's suggestions. The earlier version preferred ADGroups to SPGroups solely by virtue of central management.]
   
   
5. If you break inheritance on many lists for the same users, clean up duplicate Limited Access entries in the containing site. When you configure a list or list item to use unique permissions and add a user to it who is not listed as a member of the site, so as to not break navigation the user is automagically given Limited Access -- bare-minimum read access -- to the site that contains the list. All fine and dandy until it hapens again and a duplicate entry is created. Resolution: Remove the duplicate entries by hand or automated utility.
   
   
6. Do right for the Business. Sometimes to meet a business need you need to break from the recommended guidance. There is "recommended guidance," and then there are hard limits imposed by the platform that you should not break without raising flags and shooting off fireworks. The appropriate solution may be at odds with "recommended guidance" and that's okay. Your goal is to simulate the business, not to change the business. When conflict happens, help the business understand its choices. Make any conflict crystal clear to the people paying the bills and suggest alternatives. If the conflict is a hard platform limit with an eventual breaking point, provide all the options to mitigate the issue and make sure that the person with the power to make the decision understands the eventual consequence of the decision. You cannot stop someone above you in the food chain from blowing his or her own foot off. This is natural selection. You can only prove that you asked them not to, and escalated alerts to the issue as danger became imminent.

Thanks to Dennis Shtemberg from Infusion for getting the ball rolling with his research on uniquely-permissioned items per list, Todd Klindt for a great dialogue, corrections and help to tease apart the issues, Todd Bleeker for taking the time to review this post and make it better, and Joel Oleson and Keith Richie for their clarifying the ACL issue and their earlier work on the subject. Todd and Keith are co-authors of DeliverPoint.

Fixed or Unproved [Last Updated: 2008-09-26]

This section contians the guidance that either no longer applies, or never did.

Unique list-item permissions per list: 600 to 1000. Resolved by WSS and MOSS SP1. When you assign unique permissions to list items in a given list, when the critical point is exceeded the error is displayed: "Operation is not valid due to the current state of the object" and the following event is logged in Event Viewer: "Unknown SQL Exception 156 occured. Additional error information from SQL Server is included below. Incorrect syntax near the keyword 'SET'. Incorrect syntax near ')'. Incorrect syntax near the keyword 'with'. If this statement is a common table expression or an xmlnamespaces clause, the previous statement must be terminated with a semicolon." Resolution: When any list item with unique permissions is deleted, the list works again. When any list item with inherited permissions is deleted, the issue persists. Mitigation: If many items will share the same ACLs, then group them into a separate list or library and apply the ACL to the list or library. If the permission change is a temporary state in a list item's lifecycle (for example to assign reviewer permissions during a workflow) then reset the permissions to inherited when the temporary state is complete (e.g. at the end of the workflow). 

Users listed in a Site Collection's User Info Gallery (aka SPWeb.SiteUsers): 1500 to 2000. No evidence can be found to support this guidance, and believe it to be a misinterpretation of the limit on ACL size. If you've been affected, please comment with further detail. 

A user is added to this list (and assigned an ID unique to the Site Collection) when a user is a) explicitly assigned a permission level on a securable object, or b) when a user is named as a member of either a SharePoint group or an Active Directory (AD) Group and that group is assigned a permission level on a securable object and the user then contributes to the site. Note that prior to WSS 3.0, just visiting a site added the member to the list, and now the user needs to actually contribute. When a user is deleted from the list either through the API or the User Info Gallery, the entry is marked "Deleted" but not removed [Update 2008-09-12: Corrected by KR]. Resolution: If you pass the limit, you need to remove users from the list. The difficulty is figuring out which are no longer listed in Created By and Last Modified By fields. Displaying or editing a list item with a reference to a deleted entry results in an error. Mitigation: 1) Create Site Collections such that each will serve up to 1000 contributors. [Deleted: "Create AD groups for readers." Not necessary as readers aren't added to the list.] Monitor the size of the SiteUsers list, and consider routines to prune rows from it where contributors are no longer named on sites in the collection (e.g. in Created By, Modified By, or Assigned To columns). 2) Either assign AD groups, or a combination of AD groups and individual users (the exceptions who do not logically belong in the AD group) to SharePoint Groups unless this will lead to SID count issues (see Active Directory Groups per User, below).

In the last 24 hours there's been a lot of conversation about Chrome. When Safari was released for Windows, why was so little written about Safari's SharePoint compatibility? I used Opera for years,  but why never a post about Opera and SharePoint (summary: it stinks, even drop-down menus fail to render)? What's the big deal about Chrome? Web developers certainly don't need another browser to support, unless this is the one that finally gets it right, and the odds of that are way high against. So why did I bother?

Unlike earlier entries -- and Firefox is the only measure of success to compare anything against --  Chrome has a chance of grabbing enough market share to make a difference against MSIE. The first win with long-term implications is that Google did a great job of designing a browser core, and while the first cartoon was aimed at developers, you can bet that its next features and marketing will be aimed squarely at users. Chrome is the first contender since Netscape with even a snowball's chance in Furnace Creek of unseating MSIE. Even though it's hot and the snowball isn't like to make it, this is an event.

The release of Chrome is also an opportunity to point out what's wrong with the browser market. Browser choice (that is, for any browser that bothers to adhere to standards) should be as much a matter of style as Word vs. WordPerfect used to be or Zune vs. iPod vs. Sansa vs. Zen is today. Say it again, web developers don't need another browser to support, web designers should be writing to standards, not to brands. A brand can become a de facto standard, but that's still a sign of either an immature market or a space that no one cares enough to compete in. I'd like to think we've come further than this since 1993, and that a new browser release should have little more effect on web developers than a new MP3 player does for musicians. Why are so many of today's conversation about standards and compatibility? That's a problem.

I do expect that as soon as browscap.ini (or whatever the equivalent is today) is updated we’ll see better behavior out of Chrome against existing sites including SharePoint. My guess is that Chrome would render existing .js better, but it’s being served a safe fall-back version by sites that don't yet recognize it as a client. Opera provides a switch to identify itself as different browsers against any given site, and that was a great trick when Opera worked better against some versions of IE-targeted code than others. Full Silverlight support will be coming soon. I don't know that for certain, but ScottGu's entire team is obsessed about cross-platform and they consistently surprise the skeptics, so it would be more surprising if it doesn't come to pass.

As for SharePoint and standards, the unfortunate reality is that when your product is deployed at companies that can limit browser choice and have consultants who can bend your product to meet the low percentage of organizations with accessibility standards, you get to live in a bubble and standards aren't yet a priority. Keep pushing, maybe one day a release like this really won't matter.

Until then, what I wrote yesterday stands. This is a new product that needs to accelerate through a lifecycle that other browsers have lived for years. It isn't ready for prime-time today. And if you needed another reminder not to use beta products in production, Chrome even had its own Day Zero Security Flaw. Since malicious hackers tend to target the clients people use most, perhaps the clearest signal of Chrome's importance is that people are bothering to look. On to the next question: "how long before Chrome tells me that a security update is ready for download?"

[Updated 2008-08-04]

Chrome's EULA will prevent it from being blessed as a corporate browser anytime soon was fixed within a day so now you can own the content you write in Chrome, now there's a happy update, issue resolved.

Privacy concern -  Chrome sends every URL you visit to toolbarqueries.google.com by default (you can watch it with Fiddler). You can turn it off through Options, Under the Hood, and uncheck "Help make Google Chrome better by automatically sending usage statistics and crash reports to Google." How does tracking my clicks improve Chrome? Good question.

Today I downloaded and installed the just-released Google Chrome browser, ran it through some preliminary tests with SharePoint 2007 and so far, acceptable but missing a few key things. Chrome supports NTLM authentication, uploads (though not multiple uploads), renders all the usual menus correctly, and generally does a good job of rendering SharePoint pages. And it's screaming fast.

On the downside, when you click a file you're asked for a Save location rather than opening it with the associated application. So if you're in a Doc Lib and click a document, you're asked for a location to save it. If you open the ECB menu and click "Edit in Microsoft Word" you get the message that "'Edit Document' requires a Windows SharePoint Services-compatible application and Microsot Internet Explorer 6.0 or greater." And the back button sometimes asks you to reload / re-post, even if there wasn't a user-driven POST and you'd expect it to work, like like opening an image in a library and then hitting Alt-left. Maybe I'm just used to this behaviour in other browsers.

Administrators will especially want to hang on to MSIE or Firefox for a while. Web Parts don't drag and drop while a page is in Edit mode, and even the Minimize/Close/Delete/Modify This Web part menu oddly shows as a right-hand column rather than inline with each web part itself, perhaps this is default behaviour for unrecognized browsers. Because SharePoint's UI was designed to provide all it's functionality to unknown or unsupported browsers (e.g. Opera), you can still assemble and rearrange pages, but niceties like drag and drop don't work here yet.

So for WCM sites, Chrome will work fine. For Collaboration sites, hold off until Chrome supports opening files with their associated applications. For administration, you may want to hang onto MSIE or Firefox for a while.

And if only Chrome would render the rich text box controls used in my blogging engine, I could have used it to write this post. . .

My general (non-SharePoint reaction to Chrome -- It's fast and clean. I wouldn't be surprised if they heard from Hasbro about possible trademark infringement against Simon for that logo. There are a few odd things in like missing borders on text boxes. It supports NTLM, that's a plus. Silverlight 2 doesn't support it yet so no NBCOlympics.com video. YouTube is fine though, I suppose you'd expect them to get the most popular sites right.

It saves paswords but there doesn't seem to be a master key file that I have any control over (Firefox does), so no idea whether it's actually encrypting my secrets on disk.

Conclusion: not bad for an initial beta, but when you write anything from the ground up in a mature industry you can expect several releases to get the important parts right.