SharePoint / Guide 2

Architecture from 2003 to Subscription Edition

How SharePoint sits on IIS and ASP.NET, from the 2003 ISAPI filter to Subscription Edition.

SharePoint has been rebuilt on top of IIS and ASP.NET several times. Knowing how a request travels through each version explains a lot of real-world behaviour: why old farms needed "excluded paths", why _vti_bin still exists, why a page can live in the database or on disk, and why upgrades have to go one version at a time.

The versions at a glance

The "hive" is the SharePoint install folder under C:\Program Files\Common Files\microsoft shared\Web Server Extensions\. Admins still say "the 16 hive" for 2016, 2019 and Subscription Edition.

2003: an ISAPI filter in front of IIS

Windows SharePoint Services 2.0 didn't run inside ASP.NET the way later versions do. When you "extended" an IIS virtual server with WSS, it installed an ISAPI filter (stsfltr.dll) on that IIS site.

Every request hit the filter first. If the URL was under a SharePoint managed path, the filter routed it to SharePoint, which read the page and its content from SQL Server. Anything else passed straight through to IIS. That's why WSS 2.0 had excluded paths: if you wanted to run another web application on the same IIS site, you had to tell the filter to leave that path alone.

Two other pieces from this era still exist today:

• owssvr.dll, an ISAPI extension from the FrontPage and SharePoint Team Services days. It implements the old URL protocol (for example /_vti_bin/owssvr.dll?Cmd=Display&List=...&XMLDATA=TRUE).
• FrontPage Server Extensions RPC (_vti_bin/_vti_aut/author.dll and friends), which older Office clients used to open and save documents.

The _vti_bin virtual directory maps to the hive's ISAPI folder. The folder name is a leftover from this design, even though it now mostly holds .asmx and .svc web services.

SharePoint Portal Server 2003 added portal "areas", audiences, user profiles, and a search engine built on the Microsoft Search (MSSearch) service. WSS 2.0 on its own used SQL Server full-text search.

2007: into the ASP.NET 2.0 pipeline

WSS 3.0 dropped the ISAPI filter and became a proper ASP.NET 2.0 application:

• On IIS 6, SharePoint configured a wildcard application map, so every request (including images and CSS) was handed to aspnet_isapi.dll and into ASP.NET.
• SharePoint's HTTP module (SPRequestModule) and its virtual path provider (SPVirtualPathProvider) took over from there.
• The virtual path provider decides whether a page comes from the file system (the hive) or from the content database. That's the "ghosted/unghosted" behaviour, later renamed uncustomized/customized: an uncustomized page is a pointer to a file on disk; editing it in SharePoint Designer stores a customized copy in the database.

2007 also introduced most of the concepts still in use: content types, features and solutions (WSP), master pages, alternate access mappings with five zones, and "web application" replacing "virtual server". Shared services (search, profiles, Excel Services, BDC) ran in a Shared Services Provider (SSP).

2010: IIS 7 integrated pipeline, service applications and claims

• IIS 7 integrated pipeline. No more wildcard maps. SPRequestModule is registered as a managed module in each web application's web.config, and IIS and ASP.NET process the request as one pipeline.
• 64-bit only, on Windows Server 2008 or 2008 R2.
• Service applications replaced the SSP. Each service (search, managed metadata, user profiles, Secure Store, Excel) became independently deployable and shareable between web applications and even farms.
• Claims-based authentication arrived alongside classic Windows authentication, enabling SAML sign-in (for example through AD FS) and forms-based authentication.
• PowerShell replaced STSADM as the admin tool, and the client object model (CSOM, JSOM) and the REST endpoint arrived.

2013: claims by default, new search and Distributed Cache

• Claims became the default for new web applications; classic mode was deprecated. Convert-SPWebApplication moves older web applications to claims.
• Search was rebuilt by merging in FAST technology (see the search guide).
• Distributed Cache (built on AppFabric) was added for the newsfeed, the logon token cache and other shared state across web servers.
• The app model (SharePoint Add-ins) with OAuth, and /_api REST endpoints (a friendly rewrite of /_vti_bin/client.svc).
• Office Web Apps Server and Workflow Manager became separate server products that SharePoint connects to.

2016 and 2019: MinRole and modern

• MinRole (2016) assigns each server a role and starts only the services that role needs (see the services guide). Combined roles came in Feature Pack 1.
• Zero-downtime patching and much smaller update packages.
• Excel Services moved to Office Online Server, and the FIM-based profile sync engine was removed in favour of AD import or Microsoft Identity Manager.
• 2019 brought the modern experience on-premises: modern lists, libraries, pages, communication sites and team sites, plus support for the OneDrive sync client, longer paths, and # and % in file names.

Subscription Edition: continuous updates

SharePoint Server Subscription Edition (2021) is the current on-premises version. There are no more "big bang" versions: new features arrive in feature updates delivered through the regular cumulative updates, and you choose whether your farm receives them early or on the standard schedule. Notable additions include OpenID Connect sign-in (for example with Microsoft Entra ID), TLS 1.3 support, SSL certificate management built into Central Administration and PowerShell, and support for Windows Server Core.

How a request flows today

1. HTTP.sys receives the request and hands it to the IIS worker process (w3wp.exe) of the web application's application pool.
2. The integrated pipeline runs IIS and ASP.NET modules in order. SPRequestModule initialises the SharePoint context.
3. Authentication runs: Windows (NTLM or Kerberos), SAML, forms or OpenID Connect. SharePoint turns the result into a claims identity.
4. The virtual path provider decides whether the requested page comes from disk (the hive) or the content database.
5. The page renders. Static files may be served from the BLOB cache instead of SQL (see the BLOB cache guide).

The virtual directories you'll recognise

The URL stays _layouts/15 in 2016, 2019 and Subscription Edition even though the hive is 16.

Each IIS site's files, including web.config, live in C:\inetpub\wwwroot\wss\VirtualDirectories\<host name or port>.

Why upgrades go one version at a time

Each version changed the database schema and the way pages are stored and rendered. SharePoint only knows how to upgrade content databases from the version directly before it, so a 2010 database must go through 2013 and 2016 before it can reach 2019 or Subscription Edition (which accepts 2016 and 2019 databases). The migration guide covers the path in more detail.