Automatically monitors all key application services

• Automatically monitors the availability of all key services associated with a specific application.
• Improves availability by showing not only whether a server is available or not, but what is happening within the application.

Monitors all key application performance attributes

• Monitors all key performance aspects of the operating system, hardware and application.
• Improves availability by identifying when overall performance begins to degrade.

Preemptive failover avoidance

• Neverfail can take a variety of corrective actions to repair or resolve problems detected through its monitoring capability.
• Avoids expense of IT personnel involvement in managing unnecessary failovers.

Seamless switchover, failover and switchback of application workload

• Automatically moves an application‘s workload back and forth between primary and secondary servers.
• Improves availability by providing seamless, non-disruptive application redundancy to users.

Primary server requirements

• Microsoft Windows 2000 or 2003 compatible server with 2GB of free system hard disk space. This should not be spread over several drives.
• A minimum of 1GB RAM is recommended. Exact requirements depend on application load.
• Microsoft Windows 2000 Server or Advanced Server, or Microsoft Windows 2003 Server or Enterprise Server, latest SP version.
• Microsoft SQL Server 2000 Standard or Enterprise, latest SP version.

Secondary server requirements

• Microsoft Windows 2000 or 2003 compatible server with disk space and memory to match the Primary Server.
• Same version of operating system with the same Service Pack applied as the Primary Server.

Network requirements

• 2 Network cards per machine (1 Public & 1 Channel) or 3 Network cards per machine (1 Public & 2 Channel).

Licensing

• Neverfail for SQL Server is licensed based on the Server in a pair with the greatest number of CPUs.

Download PDF

Neverfail for SharePoint is the only fully integrated high availability, low cost software solution for the entire Microsoft SharePoint environment.

Remember the white board meetings where everyone sat around a conference room brainstorming? With Microsoft SharePoint, those days are over… web sites have replaced white boards and collaboration can take place around the world. How much would it cost your company in lost productivity to go a day without Microsoftฎ SharePoint? With Neverfail for SharePoint, you‘ll never have to know.

Neverfail for SharePoint protects and proactively monitors your entire SharePoint environment, including all connected systems and applications
With new collaborative content being generated, changed, deleted, and more, SharePoint environments never stand still - they‘re subject to constant change. Microsoft clustering cannot protect your SharePoint Portal Server; Neverfail for SharePoint is the only high availability solution that ensures end-to-end protection for your entire SharePoint environment, including all information sharing applications and collaborative servers. With Neverfail, your users stay connected to working applications at all times.

In addition to monitoring the SharePoint Portal Server, Neverfail for SharePoint will also protect the servers that host your valuable SharePoint content - whether it resides in SQL Server, Exchange Public Folders or on a file system. Furthermore, Neverfail is the only cluster-class, high availability solution to proactively monitor the health of your entire SharePoint environment, including: physical server hardware, network infrastructure and operating system. If any problem occurs, Neverfail can take a variety of preemptive, corrective actions without resorting to a full system failover. In extreme cases, a non-disruptive, seamless failover to your secondary server can occur automatically and transparently to your users.

Automatically monitors all key application services

• Automatically monitors the availability of all key services associated with SharePoint and collaborative servers.
• Improves availability by showing not only whether a server is available or not, but what is happening within Sharepoint.

Monitors all key performance attributes

• Monitors all key performance aspects of the operating system, hardware and Sharepoint application and all collaborative servers.
• Improves availability by identifying when overall performance begins to degrade.

Preemptive failover avoidance

• Neverfail can take a variety of corrective actions to repair or resolve problems detected through its monitoring capability.
• Avoids expense of IT personnel involvement in managing unnecessary failovers.

Seamless switchover, failover and switchback of workload

• Automatically moves workload back and forth between primary and secondary portal and collaborative servers with no impact to end users
• Ensures seamless, non-disruptive availability of your entire Sharepoint environment, so users stay connected to working applications.

Primary server requirements

• Microsoft Windows 2003 compatible server with 2GB of free system hard disk space. This should not be spread over several drives.
• A minimum of 1GB RAM is recommended. Exact requirements depend on application load.
• Microsoft Windows 2003 Server or Enterprise Server, latest SP version.
• Microsoft SharePoint Portal Server 2003, latest SP version.

Secondary server requirements

• Microsoft Windows 2003 compatible server with disk space and memory to match the Primary Server.
• Same version of operating system with the same Service Pack applied as the Primary Server.

Network requirements

• 2 Network cards per machine (1 Public & 1 Channel) or 3 Network cards per machine (1 Public & 2 Channel).

Licensing

• Neverfail for SharePoint is licensed based on the Server in a pair with the greatest number of CPUs.

Exchange 2003 Clustering Features

•	Support for up to eight-node clusters   Exchange has added support for up to eight-node active/passive clusters when using Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition.
•	Support for volume mount points   Exchange has added support for the use of volume mount points when using Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition.
•	Improved failover performance   Exchange has improved the performance of clustering by reducing the amount of time it takes a server to fail over to a new node.
•	Improved security   Exchange cluster servers are now more secure. For example, the Exchange 2003 permissions model has changed, and Kerberos authentication protocol is enabled by default.
•	Improved prerequisite checking   Exchange performs more prerequisite checks to help make sure your cluster servers are deployed and configured properly.

The following sections discuss these features in detail.

Support for Up to Eight-Node Clusters

Volume mount points are now supported on shared disks when the nodes of your cluster are running Window Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition. Volume mount points are directories that point to specified disk volumes in a persistent manner. (For example, you can configure C:\Data to point to a disk volume.) Mount points bypass the need to associate each disk volume with a drive letter, thereby surpassing the 26-drive letter limitation.

For clustering in Exchange 2003, the amount of time it takes for a node to fail over to another node is reduced, thereby improving overall performance. The following sections provide information about the improvements to failover times.

To decrease the amount of time it takes to fail over a server, Exchange 2003 provides an improved dependency hierarchy for Exchange services. Specifically, in Exchange 2000, the Exchange protocol services are dependent on the Microsoft Exchange Information Store service. However, in Exchange 2003, these services are dependent on the Microsoft Exchange System Attendant service.

Hierarchy of Exchange dependencies in Exchange 2000

Hierarchy of Exchange dependencies in Exchange 2003

If a failover occurs, this improved hierarchy allows the Exchange mailbox stores, public folder stores, and Exchange protocol services to start simultaneously. As a result, all Exchange resources (except the System Attendant service) can start and stop simultaneously, thereby improving failover time. Additionally, if the Exchange store stops, it no longer must wait for its dependencies to go offline before the store resource can be brought back online

When running Exchange 2003 on Windows Server 2003, the Cluster service automatically detects the available node. The overall time it takes for Exchange to fail over to the available node is reduced. Therefore, for both planned and unplanned failovers, downtime is reduced.

Exchange 2003 clustering includes the following security features:

•	The clustering permission model has changed.
•	Kerberos is enabled by default on Exchange Virtual Servers (EVSs).
•	Internet Protocol security (IPSec) support from front-end servers to clustered back-end servers is included.
•	IMAP4 and POP3 resources are not added by default when you create an EVS.

The following sections discuss each of these features in detail.

The permissions needed to create, delete, or modify an EVS are modified in Exchange 2003. The best way to understand these modifications is to compare the Exchange 2000 permissions model with the new Exchange 2003 permissions model.

In the following sections, the term cluster administrator refers to the person who manages Exchange clusters for your organization.

For an Exchange 2000 cluster administrator to create, delete, or modify an EVS, the cluster administrator‘s account and the Cluster service account require the following permissions:

•	If the EVS is the first EVS in the organization, you must have Exchange Full Administrator permissions at the organizational level.
•	If the EVS is not the first EVS in the organization, you must have Exchange Full Administrator permissions at the administrative group level.

In Exchange 2003, the permissions model has changed. The Windows Cluster service account is no longer Exchange-specific. This means that the Cluster service account no longer requires that the Exchange Full Administrator role be applied to it, neither at the Exchange organizational level nor at the administrative group level. The default permissions for the Cluster service account in the forest are sufficient for it to function in Exchange.

As with Exchange 2000, the cluster administrator requires the following permissions:

•	If the EVS is the first EVS in the organization, the cluster administrator must be a member of a group that has the Exchange Full Administrator role applied at the organization level.
•	If the EVS is not the first EVS in the organization, the cluster administrator must use an account that is a member of a group that has the Exchange Full Administrator role applied at the administrative group level.

However, depending on the mode in which your Exchange organization is running (native mode or mixed mode) and on the configuration of your topology, your cluster administrators must have the following additional permissions:

•

When your Exchange organization is in native mode, if the EVS is in a routing group that spans multiple administrative groups, the cluster administrator must be a member of a group that has the Exchange Full Administrator role applied at the administrative group level for all of the administrative groups that the routing group spans. For example, if the EVS is in a routing group that spans the First Administrative Group and Second Administrative Group, the cluster administrator must use an account that is a member of a group that has the Exchange Full Administrator role for the First Administrative Group and must use an account that is a member of a group that has the Exchange Full Administrator role for the Second Administrative Group. Routing groups in Exchange organizations that are running in native mode can span multiple administrative groups. Routing groups in Exchange organizations that are running in mixed mode cannot span multiple administrative groups.

•

In topologies, such as parent/child domains where the cluster server is the first Exchange server in the child domain, you must have Exchange Administrator Only permissions at the organizational level to specify the server responsible for Recipient Update Service in the child domain.

Kerberos is the authentication protocol in Microsoft Windows 2000 Server and later that provides mutual authentication. However, the Cluster service did not support Kerberos enabled cluster groups until Service Pack 3 (SP3) for Windows 2000. Because of this, the older authentication protocol, NTLM, was the default authentication protocol for Exchange servers running in clusters.

Because Kerberos is supported in the Cluster service on Windows 2000 with SP3 or later or Windows Server 2003 and Exchange 2003, Kerberos is enabled by default when you create an EVS on a server running Windows Server 2003 or Windows 2000 with SP3.

You can use IPSec if a secure channel is required between front-end and back-end cluster servers. This configuration is fully supported when both the front-end servers and back-end servers are running Exchange 2003 on Windows Server 2003.

To ensure that your clusters meet certain requirements, Exchange 2003 performs more prerequisite checks on clusters than previous versions of Exchange. For example, to help make sure that Exchange is correctly installed on your cluster nodes, Exchange 2003 performs more pre-installation checks on the cluster nodes. Similarly, to help make sure that your EVSs are correctly configured, Exchange 2003 performs more checks on your cluster when creating and removing EVSs.

For a complete list of the prerequisite checks that Exchange performs, see the following resources:

•	The "Deploying Exchange 2003 in a Cluster" section in the Exchange Server 2003 Deployment Guide.
•	The "Managing Exchange Clusters" section in the Exchange Server 2003 Administration Guide.