SharePoint Connections Session Follow Up: Create an Internet-Facing SharePoint Site

During the Create an Internet-Facing SharePoint Site session I covered the following topics.

1. Setting up forms based authentication.
2. Creating your own custom Master Pages and style sheets
3. Personalizing site content for users.
4. Leveraging the Business Data Catalog to surface and interact with back end systems.
5. Each of these topics is broken down more in depth in this blog post. All the code used during my demos can be found in the rar file linked at the end of this post.
6. Setting up forms based authentication
7. Because a brief survey revealed almost the entire audience had already attended a session that covered setting up forms based authentication for SharePoint sites, I moved quickly through the materials related to setting up forms based authentication for SharePoint sites and did not spend a lot of time on it.

At any rate, here are the step by step instructions that describe how to set up a SharePoint site to use forms based authentication.

*Note: There are also several GREAT blog posts that describe how to set up FBA with SharePoint sites available on the Internet as well

Click here for detailed information.

SharePoint 2007 Performance Optimization

Recommendation: use x64 hardware on all servers to optimize page downloads by minimizing number of round trips between client computers and server computers.

Reason: With x64 you are not limited to 2 GB of Memory.

Benefit: Reduces network traffic and latency due to FE servers hitting the memory limit and needing to recycle.

Recommendation: apply Windows Server 2003 SP2

Reason: A list of all of the reasons can be found here: http://support.microsoft.com/kb/914962/en-us

Benefit: Optimizes the Front End server’s performance

Recommendation: Defragment the Front end Server’s drives

Reason: best practice for optimal disk performance

Benefit: Optimizes the Front End server’s performance

Recommendation: apply MOSS SP1 and post SP1 rollup fixes

Reason: The service packs addresses a lot of the known bugs that currently exist.

Benefit: Reduces network traffic and latency due to FE servers hitting the memory limit and needing to recycle.

Recommendation: Use a dedicated FE crawl target that is not in NLB (i.e. NLB is not installed)

Reason: By default, Office SharePoint Server 2007 uses all Web servers to crawl content in the server farm. When your server farm is configured to use all Web servers for crawling, the index server sends requests to each Web server in the farm.

Benefit: Crawling content in your farm places a heavy load on the Web servers. This tends to cause spikes and surges in network traffic, and is CPU-intensive and memory-intensive. By pointing to a dedicated FE server, users aren’t impacted negatively.

Recommendation: All server computers in the farm are on the same network segment. There is no switching in routers at the data layer. The network link between a Web server and the database server is less than 1 milliseconds (ms) latency and located 10 or fewer miles from the database server.

Reason: Routers and switches will increase latency even if the network connection between these is very fast. If the type of load the Web server is serving is some subset of user browse requests, we expect Office SharePoint Server 2007 to tolerate some latency between the Web server and the database server. On the other hand, pages with many or custom Web Parts, Stsadm commands, and search crawls are likely to fair less well.

Benefit: Reduces latency and provides a better experience for users in remote geographic locations

Recommendation: Do not use web gardens and BLOB cache at the same time

Reason: Because only one process can acquire the lock necessary to manage the cache, successful use the cache depends on which thread services a request. If a Web garden that does not have the BLOB cache lock services a request, the content it sends in response will not have caching directives associated with it.

Benefit: Reduces the amount of requests and data sent over the network by allowing BLOB Caching to work.

Recommendation: Optimize Blob Cache by including most used file extensions and increasing the cacheabilty value

Reason: The BLOB cache enables you to configure caching directives that are associated with items served from publishing site lists, for example, the Pages library and Site Collection Images. When the browser on the client computer encounters a caching directive, it detects that the item it is retrieving can be saved locally and does not need to be requested again until the caching directive expires. When the BLOB cache is turned on, a couple of different things happen. First, each time a cacheable item is requested, MOSS searches the hard disk drive of the Web server that received the request to see if a copy exists locally. If it does, the file is streamed directly from the local disk to the user. If it isn't on the local disk yet, a copy of the item is made from the SQL database where it is stored, and then the item is sent to the user making the request. From that point forward, all requests for the item can be served directly from the Web server until the item's cacheability value indicates that it has expired. The other thing it does is append a cacheability header to the item when the item is sent to the client. This header instructs the browser how long the item should be cached. For example, if a picture had a cacheability value of three days, the browser uses the copy of the image it has in its local cache if the picture is requested again within the next three days; it does not request it from the server again.

Benefit: That results in better performance in the server farm by reducing contention on the database server. In a geographically distributed environment, this is critically important because it reduces the number of items requested and sent over the network.

Please note that you need to ensure that the “Office Sharepoint Server Publishing” feature is activated on all Publishing sites. Also, you should update the location to the best performing drive, add in extra paths, and add in the max-age to expire based on your situation. For example:

Current setting: <BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js)$ " maxSize="10" enabled="false"/>

Example Setting: <BlobCache location="E:\blobcache" path="\.(gif|jpg|png|css|js|htc|)$ " maxSize="10" max-age="86400" enabled="true"/>

Recommendation: Optimizing IIS Compression by changing the level of IIS compression from 0 to 9 and adding in certain dynamic files

Reason: When MOSS is installed, setup configures IIS to compress the static file types .htm, .html and .txt; it compresses the dynamic file types .asp and .exe. After a site has been hit by a few users, you can verify that compression is working by viewing the %WINDIR%\IIS Temporary Compressed Files directory on a Web server. It should contain multiple files, which indicates that static files have been requested and IIS has compressed a copy of them and stored them on the local drive. When that file is requested again, whether it's the same user or not, the compressed version of the file is served directly from this folder. Dynamic files can be compressed as well, but they are always compressed on the fly; copies are not kept on the local Web server. It may be advantageous to compress additional file types. For example, it probably makes sense to also compress the static file types .css and .js; it may also make sense to compress the dynamic file types .axd and .aspx.

Benefit: The IIS Compression can result in significant bandwidth savings. For example, the core.js file is included on every SharePoint page. When it's uncompressed, it is 257 KB; after compression, the file is only 54 KB without performing additional tuning to IIS compression.

Please note: Before applying IIS Compression, you will need to ensure that you only include files that are well-suited to being compressed. For example, .jpg files are not a good candidate for compression because the file format is inherently compressed already. Also, 2007 Microsoft Office system file types such as docx, xlsx and pptx are not a good choice for compression because the files are not served directly from the server; instead, they are routed through the different ISAPI filters that are used to manage the rich integrated end user experience for Microsoft Office content. In addition, in the 2007 Microsoft Office system, these file types are inherently compressed.

Ref: http://technet.microsoft.com/en-us/library/cc263099(office.12).aspx

and

http://blogs.technet.com/b/waynemo/archive/2008/03/19/moss-server-performance-considerations.aspx

MOSS Architecture and SSP

MOSS adopts a typical 3-tier model with web servers at the front, application servers in the middle and a database server at the back where all the data and config is stored.

The front-end web servers are simple web servers that can be network load balanced to achieve additional performance and fault tolerance (like 2003). The backend database is a typical SQL 2005 database service and can be clustered as you’d expect.

So what is different?

The interesting bit is what goes on in the middle. With MOSS, it is mandatory to have a Shared Service Provider. This is a collection of application servers that provide shared services out to any portals or sites that need them. These services include:

• Search
• Index
• Audience compilation
• User profiles database
• My Sites
• Business Data Catalogue
• Excel Services

Any of the above services can exist on any number of servers within the SSP. For example, for a small-ish deployment you could have them all on one box, or you could scale them out onto different boxes as you see fit. There are no rules that govern where these services reside within the SSP or how many servers you have servicing them (with the exception of the Index server - only one per SSP). For example if you want 10 search servers – got for it ... “fill your boots” as we’d say here in England!

This model is very similar to the 2003 approach with one crucial difference,  the SSP has no portal affiliation. This means that you are not forced to have a specific parent/child style portal topology in order to use Shared Services which was one of the big sticking points with Sharepoint 2003 shared services.

So what does the ‘Portal’ actually do now?

For starters, it is now called ‘Collaboration Portal', not ‘portal’ and it is just another type of site collection that is hosted on an IIS site (called web applications in MOSS). Portals no longer contain any application services such as search, my site etc – all these services now have to come from an SSP. This means that all you need to host a portal is a web server and a place to put the content database.

Different portals can live on their own hardware which is completely isolated from any other hardware other than the fact that it consumes services from a centrally managed SSP. Alternatively, you can put some of your portals on shared hardware and some on dedicated.

I always hear requirements around different business units wanting their own portal which has its own visual style, custom webparts, different SLAs etc . With this model, there does not have to be any affiliation between any portals or sites if it is not required.

This diagram outlines the logic of how SSP provide services that are consumed by several site collections:

So does this mean that ‘Supported Farm configurations’ have gone?

In short, yes!

This model means that you can scale any element of the system out as you see fit. However, there are several recommended server layouts that will meet most scenarios. These broadly follow the small, medium and large models of Sharepoint 2003, but should be considered as starting points only. You can easily deviate to a different setup depending on your requirements.

So how does all this map to physical servers?

All three tiers (web, application, database) of the SharePoint model can be hosted on a single machine or scaled out to a huge collection of servers to meet the requirements.

Most organisations will want some level of fault tolerance and separation between server roles. Typically these kind of organisations will have at least 2 web servers running your portals and sites, at least one application server hosting all services (maybe a second for fault tolerance) and one database cluster. This diagram shows this model:

Larger organisations may want to have separate web servers for each of their portals, sites and my sites. They may also have multiple application servers as part of the SSP. This diagram describes this model:

I hope this was usefull.