Production Setup of SharePoint 2010 and SSRS Load balanced with NLB

Production Setup:

1. Two Web Front Ends (Network Load balanced) - No Central Administration
2. Two Application Servers (Includes SharePoint, Power Pivot and SSRS Servers - Network Load balanced) - Both Servers contain Central Administration
3. Clustered Database (Active-Passive Mode)
4. SAN (Later switched to NAS) for storage of terabytes of Images. Product involves storing a lot of images.

All machines were Windows Server 2008 R2 with imaginably very high configuration on memory and hard drive.

SharePoint does not require you to load balance the Application Server, however in this specific case the requirement was to have high availability of the application and provision for scaling later.

First configure the DB in a clustered mode. This was already done by the DBA, so I will not cover it here.

Next, configure the Report Server in a scale out mode over a NLB

http://msdn.microsoft.com/en-us/library/cc281307.aspx

To setup and configure the SharePoint, we followed the steps mentioned in the below article with a few exceptions (Configuring Search was not required).

http://www.jppinto.com/2010/07/sharepoint-2010-installation-overview-table-of-contents/ 

http://www.khamis.net/blog/Lists/Posts/Post.aspx?List=6c8a23d1%2D47ea%2D47e5%2Db56f%2D2bc57cb95b93&ID=48&Web=d64cd8b3%2Da3f4%2D40d8%2D8d93%2D6aa6dc82fcda

We made sure that all the Service applications (Excel, Power Pivot & Secured Store Service) were provisioned on both the Application Servers.

Make sure to have only the required services in the WFE. You can turn off all the Service Applications that are provisioned on the Application Servers.

Next, setup the Power Pivot on both the Application Server and re-configure the Power Pivot Service Application from the Central Administration.

http://www.cjvandyk.com/blog/Articles/How%20do%20I%20-%20Install%20PowerPivot%20into%20an%20EXISTING%20SharePoint%202010%20farm.aspx

http://msdn.microsoft.com/en-us/library/ee210616.aspx

Once the Configuration was done, most of the steps were custom. 

Few things that is worth of mentioning:

1. Ensure that your domain name and web site names are not the same. We had a very hard time reverting it as users internally to the company were not able to use the Web Site. The reason, was all the requests to the site was going to the Domain Controller instead.
2. When you are creating a Web Application, use the website name for Public URL Ex: http://mywebsite.domain.com instead of the default, Application Server name (filled by default). We could not find a way to revert this.
3. Ensure to make appropriate DNS entries so that the web site is really internet facing. Your administrator may want to make entries in the Name server, to map the website name to the local load balancing web server, so that users (employees) within the domain need not go through internet.

 Hope this should be a good start. Good Luck! on your setup.

Can't find my SharePoint Web page on IIS?

Coming from a background of ASP.net, we are used to going to the IIS Manager and locating a web page file. In SharePoint, try finding it. You will be surprised. We usually map the URL relative to the Application directory of the WFE.
When you create a new Web Application in SharePoint it creates an entry in the IIS with the application by default being hosted on the Physical Directory C:\inetpub\wwwroot\wss\VirtualDirectories\ 
All Standard Pages/Pages that you created in the SharePoint Console, ideally should have been placed in this directory, but, instead SharePoint stores them in the Content database.


Then you must be wondering how SharePoint manages to find the correct page through the URL. 
ASP.Net came up with a new concept of VirtualPathProvider. To allow users to implement custom storage of the files (web pages) without affecting the way users access web pages. SharePoint has provided a custom implementation through SPVirtualPathProvider that connects the URL with the appropriate page from the Content Database.
The SPVirtualPathProvider class works together with another class named the SPPageParserFilter to supply processing instructions to the ASP.NET page parser. For example, the SPPageParserFilter component controls whether the ASP.NET page parser compiles the ASP.NET page into an assembly DLL or whether it processes the page in a no-compile mode that is introduced with ASP.NET 2.0

Not all standard pages come from SharePoint Content database. Some pages are hosted within the SharePoint root folder. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\
SPVirtualPathProvider will know from where a particular page has to be picked up from (File System vs. Database). These kinds of pages are called as Ghosted Pages. The pages that come from Content database are called UnGhosted pages. These are customized pages of the standard pages.


SharePoint version of the life cycle is depicted in the below image. They integrate with the ASP.Net runtime seamlessly by adding the SPHttpApplication (HttpApplication replacement for the ASP.net) containing a Module SPRequestModule with a couple of common ASP.Net modules. This finally uses the SPHttpHandler (SharePoint implementation of HttpHandler) to process requests.

Global.asax would contain a directive as 

<@Application Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" >

Http Module and Http Handers will be registered with the application through the Web.Config.

A quick view of the IIS brings us to a couple of Virtual Directories of a SharePoint web application. If you follow the Physical path of these they point to the Root folder.

Note: The image is from the MOSS. However, they are pretty much the same with a few additions in SharePoint 2010.

• _vit_bin : Provides Windows SharePoint Services with a way to expose DLLs and .asmx Web service files at a path within the URL space of a Web application. 
• _controltemplates : Provides a repository for deploying ASP.NET user controls that can be used within pages. 
• _wpresources : Provides a repository for resource files that are deployed along with Web Parts.
• layouts :  Provides the repository for application pages. 

There is only one version of an application page scoped at the farm level, it can be compiled into a single DLL and loaded into memory once for each Web application. 

An application page, such as settings.aspx, can be accessed by adding its relative path within the _layouts directory to the end of a site’s URL

http://Litwareinc.com/_layouts/settings.aspx 
http://Litwareinc.com/sites/Vendors/_layouts/settings.aspx  
http://Litwareinc.com:1001/sites/Accounting/_layouts/settings.aspx 

Reference: http://msdn.microsoft.com/en-us/library/bb892189.aspx