Fundamentals: Implementing a Web Application

Two weeks ago, I delivered a series of online workshops addressing governance, administration, and "business intelligence light." To those of you that attended, thank you! There were a lot of great questions that came in during and after the event, and several of them caught my eye because they highlight the problems with the default settings in Central Administration when you create a new web application. Those default settings, which are wrong for most scenarios, lead to a lot of confusion. So, I'd like to clarify them by reviewing the fundamentals of creating a web application. Along the way, I'll point out the problems with the default settings and, hopefully, you'll end up making better, more informed choices the next time you configure a web application.

In SharePoint, a web application is a website to IIS. Every website must have a URL, such as http://intranet.contoso.com/default.aspx:80. As you can see, this URL consists of the protocol, the address or domain name of the host, a path, the filename of a page to serve, and a port. Obviously, the example I've shown is a bit extreme because parts of the URL can be left out. Both the client (browser) and server will fill in the blanks. So, for example, a user browsing to intranet.contoso.com will end up getting the same page. But behind the scenes, the missing components of the URL are completed. The client adds the http:// automatically and makes the request over port 80. The server or application decides what to serve as a default page if a page isn't specified. In between the browser and the server is DNS, which resolves the name—in this case intranet.contoso.com—to an IP address so that the request can be sent to the server's address.

Each web application needs a unique identifier, which can be a combination of:

In most scenarios, the port will be 80 (http://) or 443 (https://), which means that the uniqueness must come from the IP address or host header. Many organizations host multiple websites on a single server, and there's often no need to have a unique IP address for each site, particularly on an intranet. Therefore, the IP address of the applications is shared. That leaves the host header. When a browser sends a request to the server, it sends the request to the IP address of the server, but it includes the name of the web application as a host header. The server can therefore receive requests for different websites on a single IP address and get those requests to the right place.

That brings us to SharePoint's defaults. When you create a new web application in SharePoint, the defaults use the port to create the unique identifier. A random port is suggested. Since you'll probably want to change that to port 80 (or 443), you'll need to also add a host header: the name of the web application, e.g., intranet.contoso.com (leaving out the http://). You can then change the default suggested description to something more meaningful. You've now created a unique web application based on the host header rather than the port.

Don't forget that clients need to be able to find the server, so add an "A" record (host record) to DNS mapping the name of the web application to the server's IP address. While you can use CNAME records, a number of people smarter than me have pointed out that CNAME records create some issues with more advanced uses of SharePoint, including single sign-on (SSO), so it's best to use A records.

Another default that you'll often want to change is the application pool. By default, SharePoint suggests creating a new application pool for each new web application. An application pool helps segregate and isolate processes. If two web applications share an application pool and one is resource intensive, it could prevent the other from getting things done. Plus, if you have to reset the application pool, you'll reset all the applications in the pool. There will be scenarios in which a unique application pool is necessary. However, each application pool requires memory—in the 700-800MB range—so on a 32-bit system, which can only access 3GB-4GB of RAM, you'll end up getting memory strapped very quickly if you have three or more SharePoint application pools. I've seen it happen—it's ugly. So you'll often want to put applications with related functionality and stability requirements in a shared app pool, particularly on farms with 32-bit servers.

Finally, do yourself a favor and change the default content database name. SharePoint suggests a crazy GUID-based name for the content database. Give it a name you'll recognize when you're performing administrative tasks in either SharePoint or SQL Server.

It's too bad that at least three defaults (the URL, the application pool, and the content database name) are configured in ways that lead SharePoint admins, particularly folks who are newer to the platform, down a dark path. I hope that this review will help you out the next time you see the defaults on the Create Web Application page.