7 Years of SharePoint - a History Lesson

7 Years of SharePoint - a History Lesson

  • Comments 13

It's a milestone today (12/27/07) for me.  Seven years ago today, I joined Microsoft to work on an product that would later become Microsoft's fastest growing server product in Microsoft History.  I had just completed my MCSE in NT 4.0 and took a couple of new courses on Windows Server 2000 and Active Directory.  My background in hosting and web administration and engineering of Intranets, extranets, and Internet sites with Nextlink Communications now XO and Slate.com and short entrepreneurial experience with Pizza2u.com, (totally ahead of it's time in 1996) would come in handy.  Update: I didn't notice the Jeff Teper "Tahoe" Happy New Year post on the SharePoint Team blog when I posted this.  What a coincidence.

The Messaging group made up of Exchange Operations and Engineers had just taken on some new responsibilities and renamed themselves MACs the Messaging and Collaboration group.  In my interview loop I would be first interviewed for Exchange Conference Server, then for OWS and Tahoe some collaboration web server technology in development that would replace the need for file shares, or so I was told.  (We know how that IT intention ended up.  Although the Microsoft CIO is no longer waiting for the hundreds of file servers that existed to be put down.  They were consolidated and delegated to the business units that need them for archiving and storage.  No more collaborative shares exist or at least no new ones are being created.)  Five new positions had been created to add to the collaboration side of the house.  One Service Manager to define the service, a Project Manager to drive deployment and adoption, an Operations Analyst to install/configure/manage/deploy, and an Engineer to test, debug, architect, and design the internal software based service.  I wouldn't have changed a thing.  I think this is a great design for a new service in most medium to large enterprises.  Sure you can add redundancy, but this tight group got "SharePoint" (both STS and SPS) off the ground and defined much of what would become the foundation for running global collaboration services nearly everywhere.  If I was in a smaller or medium organization I'd still want 2 heads involved.  One project manager or at least someone who kind of understands the needs of the business to do the communication and layout a plan working with an ops person.  The ops person would do the installation, design the deployment, configuration, troubleshooting, backups, etc...  Hopefully he'd be able to lean on other IT folks to do recurring backups, hardware aquisition, maybe SQL management and storage management...

So where and how did it all begin?  It's beginings are not well understood.  Product or technology, the term SharePoint still confuses.  In an attempt to put some light on the subject.  Here's some history for you.  SharePoint has always been two things, SharePoint Services once known as SharePoint Team Services now Windows SharePoint Services, and Server once known as SharePoint Portal Server now known as Office SharePoint Server.  "But where did these technologies come from," you might ask...  Here's an attempt at giving you some background into this incredibly rich platform which didn't begin yesterday.

In 2001

The first version(s) of "SharePoint" a product marketing term added to 2 different products around beta 2.  SharePoint Team Services and SharePoint Portal Server 2001.  SharePoint Team Services a team collaboration product designed to help teams share information quickly and easily.  Either by design or by disaster a site would say 75 users per site which would limit it's deployment and have it be seen as not enterprise scalable and a workgroup solution.  Marketing would later say Portal was the enterprise product and the one to index STS environments.  Despite the 75 "limit" STS would scale to thousands and break into huge companies attracting many because of ease of use, ease of deployment.  One little add on called the SSC, the self service creation tool, was what I consider the single largest factor in getting STS off the ground in most environments, especially the MS Internal deployment.  Users creating their own sites without IT having to baby sit or to have to click buttons was huge.  Sure lack of any type of quotas was a huge issue, ownership only being defined by either the SSC creation log (if you turned it on) and by current admins was lacking, but wow that was awesome to be able to have that kind of freedom for information workers.  Most start there, but let me tell you this wasn't the absolute beginning.

Getting to the 2001 3-2-1 Release

SharePoint Team Services in those days was known as Office Web Server.  Even STSAdm as we now know it was once OWSAdm in STS.  Office Web Server (OWS) as it was known in the public betas wasn't even the beginning.  Internally we had a significant OWS deployment in Chicago known as chicagoows, one called Teamspace in Redmond, and SharePointbeta an under the desk Gabe Bratton deployment of a few hundred sites that would be moved to the first production class SharePoint server in the building 11 datacenter.  Office Server Extensions (OSE) was server extensions for allowing your information workers to take advantage of standardized ASP server extensions to upload documents and share information (but mostly documents) first shipping in the Office 2000 Resource Kit.  These extensions were not well understood, but FrontPage server extensions 2000 then 2002 would live on, now you'd find little info on FPSE with much telling you to use SharePoint.  There was a branch for the 2000 and 2002 server extensions which were versatile and bought standardization across Windows IIS 5 and even Apache Unix/Linux servers, but even that thread was short lived.  You should seriously, seriously consider WSS 3.0 at least if using Windows Server.  I know there are a bunch of FSPE sites still kicking around even today.  FrontPage itself was an acquisition from Vermeer Technologies Inc (VTI).  Ever wonder where the /_vti_bin now /_layouts back in FPSE and STS/WSS 2.0?  Now you know.  Search in STS was based on index server, remember that from your IIS 4 days with the NT option pack?  Managing those indexes reminds me of a bit of madness trying basically reindexing if you had any problems, no change logs or gatherer logs back in those days.

SharePoint Portal Server known as Microsoft's first corporate search engine wasn't Microsoft's first Search Engine.  The PKM team was shipping MSSearch.exe in a number of Microsoft Products from SQL to Exchange also included in Site Server 3.0 a lot of which went to what is now Commerce Server 2007 and early SPS.  Site Server's search functionality would allow you to index file servers, Exchange PFs, and ODBC data sources.  The PKM Search team was busy putting this search technology in many "BackOffice" servers.  Site Server a product which had audience targeting, groups, and somewhat of a profile... now you know what happened with this stuff...  If you've heard of ship it awards you'd see that the MSSearch folks got a ton of awards before the rule that you could only get one ship it award per release rather than wherever your code shipped.  Later SharePoint Portal Server 2001 SP1 would be the first to do security trimmed search results and be able to index STS content, a very significant milestone.  It would also be seen as a crawler and fixture in the company for "Enterprise" search, not just search within the server and local content, something that Site Server started out for Microsoft.

Remember SQL Dashboards publicized in SQL 2000 resource kit also known as Digital Dashboards Resource Kit (DDRK) for SQL 2000?  Those were the beginnings of web parts.  STS wouldn't get web parts until WSS 2.0, but SharePoint Server wouldn't get lists until SPS 2003.  Workspaces came from SharePoint Portal Server, and Team sites and subsites/subwebs came from STS.  The Exchange Webstore code named Magma had made some big promises.  In addition to Exchange a few collaboration/knowledge management projects internally like Unical a calendaring system, and Rapport were designed to take advantage of this seemingly scalable, extensible.  SharePoint Portal would look to take advantage of this and seemingly would look like public folders and/or OWA as you'd access it through the web.  Web Folders taking advantage of a combination of WebDav and CDO to access the webstore.  It was all a little ugly to me.  I wasn't a big fan.  It was complex and hairy to troubleshoot.  I was a fan of SQL simple connections and pure HTTP.  I liked what I could see.  One day troubleshooting a corrupt store with ESE util and not being able to get the documents I needed was too much.  I'd later add a robocopy job to a nightly routine to save my job.  Versions were first in SPS, but getting the latest copy on disk allowed me to sleep at night.

From a storage perspective STS proved that SQL was more than ready for prime time.  In STS I remember pushing single server deployments to 20,000-30,000 users around 500 concurrent connections before worker processes existed and adding large disk arrays so we could continue growing the environment.  During the first whole year of STS deployment with SSC enabled mind you, we had 4 servers running.  It would take nearly 3 years to reach 500GB of storage.  Today we get nearly this much in a month (that was with no single file upload limit in STS).  Each web app could only be as large as the drive or path.  We had 17 STS servers in 11 locations world wide.    That included 2 upgraded OSE boxes and 1 environment that was in a farm a separate web front end from the SQL server.  One web app with one content database (only one in those days) known as http://sts had over 16,000 tables and 1000 subwebs.  SPS was limited to 5 locations, with some groups and divisions running their own deployments for search and lack of trust of IT or lack our lack of flexibility.  We had 15 workspaces per server for a total of 75 workspaces (portals).  Our biggest challenges in STS were the OWS timer jobs getting hung and keeping the documents and meta data in sync.  Both of these two actually go hand in hand.  The alerts jobs were running across thousands of webs every 5 minutes and not allowed to finish.  Server health a process which would synchronize the meta data and files would run for over 24 hours on 50 GB of data with about 5 million files.  It was tough to know how much data and files you had.  Back in the day I'd use diruse.exe to tell me how many files and the size.  Since it often wasn't on its own drive it would often mean I'd need to know one directories size across a large number of them to tell me the size of my web.  Diruse was a life saver for basic reporting.  Coming full circle in storage is still premature, but I'm anxious to see storage vendors help address the gaps in subsequent versions.

The 2001 aquisition of Ncompass labs Content Management Server would later be incorporated.  The content management capabilities in a self service collaboration environment make this a super powerful easy to use business productivity platform.  Later new servers and services from Forms and Excel would be added in to really enrich the business platform, but that's another story.

Another Milestone

On another topic.  I hit another milestone today.  I passed Guitar Hero III on easy.  It's quite rewarding to beat the devil.  I'm already half way through on medium, I'll keep you posted as I'm sure you're anxious to follow that thread.  I bought the game back in November when it released, but didn't open it till Christmas, so it's only been a couple of days (I know there are likely many of you out there that finished easy in a few hours).  Soon I'll be ready to re-challenge Loke to be the ultimate Guitar Hero (maybe at TechEd SEA 2008?).

If I'm missing anything above, or happened to misspeak, feel free to correct me in the comments and I'll try to make inline updates.

From comments I see that great minds do think alike.  I am impressed by Sharon's SharePoint Product History flow chart.  It's a very impressive thought out SharePoint history post and map.  I don't see any mention of the FPSE stuff though.  I do think the VTI and FrontPage integration was pretty significant. I'm interested in hearing more about these "Team Pages" mentioned in the comments as well.  Searches didn't come up with much.

Leave a Comment
  • Please add 5 and 1 and type the answer here:
  • Post
  • PingBack from http://msdnrss.thecoderblogs.com/2007/12/28/7-years-of-sharepoint-a-history-lesson/

  • Great minds think alike. ;)

    I am also posting about "10 years of SharePoint history"... starting with site server insteat of SPS 2001

  • Hi Joel, happy Xmas and New Year!

    I did a write up on the history of SharePoint last year that might be of interest - http://www.joiningdots.net/blog/2006/08/sharepoint-history.html

    And created a visual diagram to show how the different products and technologies have come together over time - http://www.joiningdots.net/downloads/SharePoint_History.jpg

  • I'm sorry to rain on the parade, but Sharepoint is one of the worst products to come out of MSFT in a long time. It can be used as the high-water mark of everything that has gone wrong with the company in the last ten years.

    Nearly all the functionality be trumped with a simple Wiki application

    Please don't take this as a personal attack on you as I'm sure you did the best you could.

  • Hi Joel,

    I think the history of Sharepoint goes back to at least '99 (maybe '98), when I worked on a product concept called Team Pages. The original idea was SQL-based, and we wanted to make creating data-driven websites something you could do right in the browser. Sharepoint actually looks pretty similar to the demo I made all those years ago.

    Aaron Tinling, UX Designer

  • Hi,

    I worked with the team of MCS consultants who first developed the Digital Dashboard concept for a client in SoCal.  I believe the lead MCS developer was George Gionopolis.

  • ping :





  • Ich wünsche allen meinen Lesern ein gutes und erfolgreiches Jahr 2008. Die guten Vorsätze sind gefasst

  • Ich wünsche allen meinen Lesern ein gutes und erfolgreiches Jahr 2008. Die guten Vorsätze sind gefasst

  • Hi Joel,

    That was pretty comprehensive. It would be nice to read if you could get us something like "SharePoint: The Road Ahead"....

    Rehman Gul

    SharePoint MVP

  • Its really great article.

    Carry on dude...


    Tariq Younas

  • Joel Oleson is leaving the SharePoint Technical Product Management team at Microsoft.  Working on

  • Body: So this blog post is to inform everyone about me stepping out into the big world of SharePoint

Page 1 of 1 (13 items)
--> 'use strict';