Licensing Options in MOSS

Office SharePoint Server 2007 licensing has changed from previous versions in that now you don’t have to worry about the Enterprise or Standard version of the server. The server is available in two flavors.

·         Office SharePoint Server 2007, Server License

o   If you are going for intranet enabled SharePoint and you don’t have any plans to make it available over the internet

 

·         Office SharePoint Server 2007 for Internet Sites

o   If the intention is to develop internet-facing sites and allow anonymous users to connect and access information over the portal.

If you go for the second option i.e. internet license, no CALs are needed as anonymous users are also allowed to connect. In fact, there is a huge addition in the cost of Internet License itself as compared to the Intranet License.  In case of the first option, i.e. intranet license, you will have to buy CALs for the number of users you want to connect to the server. Two types of CALs are available

·         Standard CALs

o   The Standard CALs are needed to access information available on your intranet server. You can access the features like portal, collaboration, search, ECM, document management etc. However, you cannot use things like BDC, Electronic Forms, Excel Services, Business Intelligence and LOB search features.

 

·         Enterprise CALs

o   If you need to remove limitations as discussed in the Standard CALS, Enterprise CALs need to be purchased. Here again, you will find a catch, as Enterprise CALs cannot work alone. Enterprise CALs are always deployed on top of Standard CALs. So for any user, if you need the provision of Enterprise features (mentioned above), you will need 1 Standard CAL and 1 Enterprise CAL per user.  

It should be noted that Office SharePoint Server Internet License gives you the Enterprise Functionality that you can have with the Enterprise CALs in case of intranet server.

Design Factors in MOSS 2007 Part 2

This is the continuation of my previous article Design Factors in MOSS 2007 Part 1. To summarize that, I discussed the different topology designs based on three different layers proposed for designing a solution with MOSS. In this article, I will be discussing the various factors that can affect such a solution. We already saw in Part 1 that the three major influential factors are:

·         Availability

·         Performance

·         Capacity

I will have a brief discussion of the first two factors and we will be leaving Capacity Analysis to Part 3 of this blog.

Availability and Performance

Most SharePoint consultants are faced with a situation where the clients ask for maximum (say 99%) uptime which is quite logical because in such enterprise level organizations, a little downtime period can result in huge loss of business activities. Some of them need the ability to fail over to a different server farm in case of a disaster. Customers also dream for a design that can considerably optimize performance of the system. Keeping all the above high end requirements in focus, they still insist that the constraints of budget, hardware and software licenses do applyJ

In cases like these, we have to think for a design which can best meet the client requirements being in limits of budget and other maintenance costs. In this blog, I have taken care of the trade-off between availability and performance design and tried to find a balance between the two.

Let’s talk about availability first. Availability, by definition is the extent to which the solution is responsive to the requests and tolerant to failure. If the availability requirements for a particular system are too high, the server farm designs (discussed in Part 1) can be modified to use redundant servers at the WFE and the database level. This is the typical criteria for deciding the number of servers in a server farm. This should normally also result in a high performing system as NLB technique on the WFE servers can result in a better performance in peak times.

Four-Server Farm

Normally, server redundancy is implemented at each layer to bring high availability in the overall system.  For the WFE layer, this can be achieved by using at least two front-end web servers load-balanced and for database layer; two clustered database servers can be used. This is a typical extension of the Two Server Farm architecture.

This server farm design introduces minimum high availability features into the system. Since this is an extension of the Two Server farm where the application roles are merged in the WFE roles, the system might not perform at its best but still, the availability requirements are being met using this architecture.

Five and Six Server Farms

To add the application layer to the overall design, at least one more server would be needed to represent the application layer. This will result in a design where high availability is induced at least in the Front End Servers. In addition, releasing the responsibility of Application Roles (Excel Services, Search etc.) from the front end layer results in improved application performance in terms of response time and user experience.

To add redundancy to the application layer itself in turn, we add one more server to the application layer that results in a six-server farm. This, in my point of view, results in the best design that caters both availability and performance requirements.

It should be noted that not all application server roles can be redundant. There are limitations that restrict you from adding redundancy to some server roles. Although these application roles can be deployed to multiple servers for scalability, but they do not operate in a load-balanced manner and are not redundant. Such application roles are:

·         WSS 3.0 Search Role (this is different from Office SharePoint Server Search which can be made redundant)

·         Index Server Role

For a solution that has high availability and optimized performance requirements, six-server farm is a design to start with. While designing a system using MOSS for a particular customer scenario, all the above-mentioned aspects should be considered to carve a good design which is long-lasting and meets the customer expectations.

Design Factors in MOSS 2007 Part 1

The design aspect of MOSS is the most frequently faced and least discussed subject area. Recently, I had been posed towards issues that relate to decision criteria for the selection of number and organization of servers in a server farm design for MOSS. I looked over the factors that rule the decision making in this context and after some research; the answers were no different than expected. The answers were:

·         Availability

·         Performance

·         Capacity

Each of the above factors, in my point of view, is important to consider while trying to achieve a workable design for MOSS based solutions. This is why this post has been suffixed with the title ‘Part 1’ as I will be discussing each of these factors in next parts of this post and will also examine the effect of topology design over these factors. However, before moving to the optimization factors, let’s focus on the baseline server farm configuration for a typical MOSS installation.

A recommended MOSS 2007 deployment topology is composed of three virtual layers:

·         Web Front End Layer

·         Application Layer

·         Database Layer.

I said virtual because nobody enforces that there need to be all these layers isolated and separate server(s) attached to each layer. OK, so we are faced with scenarios here. Let’s simplify it a bit. Based on the above mentioned factors, let’s say we conclude that the layers (roles), all of them aggregate in a single physical server which of course is not recommended for production scenarios. This results in a single server farm.

Single Server Farm

Single Server Farm, as the name suggests is deprived of the luxury of a lot of hardware and everything resides in a single box. This can be used for demonstration, proof of concept or evaluation purposes. Although this topology is not recommended for production environment, but still in cases where there are low number of users and performance bottlenecks are tolerable to a large extent, this configuration can be useful.

           

Two Server FarmThere might be cases where due to some of the factors (mentioned above), one or more of the layers be represented by separate servers (one or more for each role based on the redundancy requirements).  The least recommended starting topology for most of the scenarios is a two server farm where one server acts as a database server and the other serves WFE and Application Server Roles.      

                                           

                                                        

This topology is typically useful when the data needs to be isolated and flexible enough to be scaled to multiple servers in future.

Three Server Farm (Adding the Application Layer)

This topology typically introduces another layer and hence the three layers now are isolated and each represented by one or more servers. Each of these roles may also introduce redundancy by adding redundant hardware and using the load balancing techniques.

 

What is important to note is that the server farms depicted above are differentatied by the number of layers and not the number of servers to use in a particular farm topology. Each of the above farm configuration is different from the other due to the introduction of roles and representation of roles at different tier levels. A three-server farm, for instance, may also be achieved by adding a redundant database server to the above-discussed two-server farm or by adding a redundant WFE server. So there is much to think over for a good design and we are yet to examine the factors that affect the number of servers in each of the server farms discussed above.

I hope this post was helpful to understand the typical server farm tiers available with MOSS. In the next posts, I will be discussing the extension of these baseline topologies that include redundant hardware to fulfill varied client requirements based on Availability, Performance and Capacity.

WSS 3.0 – as a development platform?

 When it comes to SharePoint, it’s a sin not to have a word on WSS. To say the least, WSS is the cradle in which SharePoint was born.  It’s a freely available offering from Microsoft. For the geeks, WSS is a set of services and programs that provide a foundation for not only SharePoint Products and Technologies but also other server products like Enterprise Project Management Server, BizTalk Server etc. People tend to say that WSS is all about collaboration which is not true in my opinion and that’s what I am going to discuss here.

As expected, Microsoft while moving from V2.0 to V3.0 introduced several new features that have added value to the already available platform services. You might have heard of the war of ‘Using the word SharePoint’ that is going on between famous SharePoint bloggers like Fritz and Arpan Shah. Although the idea behind fighting over whether SharePoint is an adjective or a noun might not seem appropriate but the important aspect is to keep an eye on is the intention of MS:  bringing WSS to a stage where it can serve as both a solution and development platform.

Presenting WSS as a Solution Platform is quite reasonable for obvious reasons. There are already services available and API exposed (enhanced in v3) which can be used inside and outside the SharePoint context. Microsoft, as part of Office SharePoint Server, has shipped some applications built on top of WSS 3.0 and the services are ready for you to make use of and develop new solutions. When I talk about the development platform, it’s more from the framework point of view. Those who have worked/ developed for SPS 2003 might know that it made use of .NET 1.1, yes the .NET classes, but not the framework itself to a very large extent. In WSS 3.0, however, the story is a bit more .NET friendly. WSS 3.0, to a bigger extent, leverages the framework services available in .NET 2.0, the provider framework, authentication framework, the web part framework etc. This depicts the idea that WSS and .NET, who were once far apart, are now becoming closer to each other and what I can guess is (don’t know what MS guys are thinkingJ) that this growing friendship of WSS and .NET may result in a merger whereby the set of development frameworks provided by Microsoft combine with the power of WSS and present a unified solution and development platform.  

We can see that WSS isn’t just a collaboration tool rather; the new generation of WSS can be considered a foundation platform to develop highly flexible and re-usable web application services. To conclude, I would like to recommend a good book written by Todd Bleeker named Developer’s Guide to the Windows SharePoint Services v3 Platform (Charles River Media Programming).