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...

Binary Large Objects, or BLOBs as the SQL types like to call them, are the byte arrays that represent documents and other files in SharePoint.  Typicaly, they are stored in the SharePoint content database.  The reality is, the ECM industry has known for decades that RDBMS is not the best place to store BLOBs.  SQL database storage needs to be high IOPS and low latency... translated... EXPENSIVE storage.  It's much more efficient if we are able to store the BLOBs on lower cost, possibly even archival-class storage while we continue to invest in high performance storage for the structured content metadata. As...

For the last several years, I've worked on several projects that stretch the recommended limits regarding the amount of content that SharePoint can handle.  Back in December of 2007 I started on an interesting scalability journey with a couple of awesome guys at Microsoft.  The first, Paul Learning, is a quality MCS SharePoint guy out of Detroit.  The second, Andy Hopkins, served as our red-tape bulldozer.  The three of us worked to put a small server room full of Fujitsu blades and storage arrays to good use in order to prove that SharePoint could do 50 million documents. The result of our efforts was a very...

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

What can I say about this past week! It was a great ride and I'm not even talking about The Mummy at Universal! I spent this last week at TechEd 2008 in Orlando. It was such an amazing event that I don't even know where to begin! So I'll start with the facts. Microsoft's new hypervisor technology "Hyper-V" is set to storm onto the scene. I saw some excellent demos this week. So good in fact, that I'll probably have Windows Server 2008 with Hyper-V running on my laptop and/or my desktop

In the storage whitepaper that I recently released, I talked a bit about the SPDatabaseStatisticsJobDefinition timer job and the fact that it can, in most cases keep SharePoint running smoothly. However, I recently had to research a bit further into what exactly this timer job does. This is what I discovered:

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