I'm finally getting around to posting the slide deck that presented at SharePoint Saturday KC.  The topic was "Architecting for Scale in SharePoint 2010" It's a pretty juicy deck with lots of detail that will help you with storage architecture and SQL tuning.  It also provides good background on Remote BLOB Storage (RBS) and the improvements to the search subsystem in SP2010. You'll find the slides here: Architecting for Scale in SharePoint 2010

Ok, so lets do a little math here. In SharePoint 2007, you can define only 1 Records Center at a time for official files.  A single site collection (including a Records Center) in its own content database might contain somewhere around 1 million documents at a meager average of 55KB per document.  That keeps us under the 100GB content database recommended size limit. 1 million documents?  Seriously?  I suppose you could try to manage multiple records centers but this would get interesting if you actually needed to put something in legal hold in multiple records centers.  So for all practical purposes, we were severey...

I have been very fortunate over the last several years in that I've had many opprtunities to architect many extremely high scale SharePoint systems.  Everything from your standard 3 million document Imaging Repository to systems with 10's and even more than 100 million documents (thanks to FAST ESP!) As I look back on SharePoint 2003 and even to existing SharePoint 2007 solutions, there have definately been several challenges as we design systems that can handle the millions of documents we throw at them.  So it is with great pleasure that I am able to present my 4 favorite improvements in SP2010...

So this has been a long time coming.  It's been over a year since I originally wrote the Storage Architecture whitepaper and it was in need of refreshing. While the original content was certainly accurate, there were a few things that I wanted to clarify, particularly after having attended the SharePoint Master training.  There were also a couple things for which conventional wisdom has shifted a bit like the fact that we are now allowed to split the SearchDB into 2 file groups. Also, I wanted to add in some additional guidance on a few more topics that I receive a LOT...

Ok. So I've been waiting for this day for about 3 months now! The culmination of the efforts of several incredible individuals has officially materialized. ANNOUNCING: Using Microsoft® Office SharePoint® Server to implement a large-scale content storage scenario with rapid search availability This document is a scalability whitepaper that has been reviewd by Microsoft and posted on TechNet. This white paper presents the key decision points, architecture design and definition, test cr

Ok. So after writing that last post on the 100GB database limitation I got some nice feedback from several people. Also, I'm finding that this is information that really needs to get "out there". Far to often, KL is brought in to implement a document imaging or file share conversion solution in SharePoint. The problem lies in the fact that often times the sandbox that everyone learns to play in becomes production! This ends up presenting a lot of challenges for us as consultants when tryi

Right...he's a Star Wars geek. Check. I wanted to discuss something else I heard a lot about at the SharePoint 2008 conference. The 100GB database limitation. Organizations are now looking at SharePoint as a legitimate large scale application. They want to believe. They want to engage. Then they all hit their heads on the same thing. 100GB database size recommendation. Folks... it's a recommendation. The answer to the question of can we go bigger is the same as what I heard several