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

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

So... I've been holding off on this post for a few days now because I couldn't determine if this information was "in the wild" yet. But it turns out that it's been reported on by at least one other blog post, so if this was protected info, I'm not the guy who released it! :) That said... here's the deal. Microsoft is doing a Wal-Mart rollback on ESP (FAST Search) for SharePoint! If you have an EA with Microsoft that includes MOSS, then you can "add on" ESP for SharePoint for $25K per se

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

So what can we do to really tighten down search result availability? Well in this type of environment I would architect the farm a certain way and setup the incremental crawl for the content source to fire literally every minute. So the information below outlines how I would configure the farm to squeeze the absolute most performance out of crawl processing.

Ok. So the real reason that I chose today to on-ramp this blog. I wanted to add a little something to Joel Oleson's post yesterday regarding the Anatomy of Indexing. First of all, I'm sure anyone interested in my take on SharePoint is probably well aware of Joel Oleson. Most of the SharePoint community, myself included, holds Joel in the highest respect. I respect him for his wealth of SharePoint knowledge and his willingness to share it. I met him recently and in addition to being a S

Before I continue on with any other posts on this blog, I have to lay some very exciting groundwork. I said in my bio that SharePoint can be architected to scale from a single server installation that handles just a handful of static documents to extremely large implementations consisting of multiple farms that can handle 50 terabytes or more. Well, this is statement requires a bit of qualification. I have been part of architecture teams that have loaded 10s of terabytes into SharePoint