Summary

This Knowledgebase article describes the information needed and the process to propose Neverfail products effectively to a prospective client.

More Information

To propose Neverfail effectively as a solution for a client you must first gather the following information.

Procedure

Ask the client the following to determine if Neverfail is the right fit for their organization.

1. How many production servers need to be protected?

Neverfail is licensed per server pair, so 1 license covers both the active and passive servers in the pair. Customers can get confused on this point, so it is important to review it with them. For example, if a customer says they need Neverfail for 2 Exchange servers, ask them if they are referring to 1 active and 1 passive, or 2 production Exchange boxes that will each need their own “passive” server.

2. For each server pair, what is the greater number of processors (CPUs) between the 2 servers?

Neverfail is licensed based upon the greater number of CPUs in a server pair. Neverfail uses 3 different pricing levels: Single processor, Dual processor, and Quad+ processors. If a Primary server has dual processors, and the Secondary has a single processor, then the Neverfail license would be purchased at the 2 processor pricing level. We are looking at the physical processors for pricing. If a customer has a single processor server that is hyperthreaded to look like 2 processors, you still sell them a single processor license. The same methodology applies to dual-core processors. This license model is also the same in virtual environments.

3. For Exchange servers:
   1. Do you have any Exchange-integrated Anti-Virus running on the actual Exchange server (i.e. Symantec Mail Security for Exchange, McAfee GroupShield for Exchange, etc)?
   2. Are you on Exchange 2000 or above?
      
      
4. For File Servers and SQL Servers:
   1. Are there any other applications (outside of File Server and/or SQL) running on these servers?
   2. Is any of the data on these servers from an accounting package?
   3. Is the server Windows 2000 or above?

Out of the box, Neverfail will protect the named application. For example, Neverfail for SQL will protect, replicate, monitor, and failover all things SQL out of the box. This includes the application, registry settings, services, instances, databases, etc. If there are other applications running on the SQL server Neverfail is protecting, Neverfail will not automatically handle it the same way it does SQL. There is a possibility to replicate such an application's files and directories, and even start and stop the application through Neverfail. Neverfail would still not be monitoring or failing over such an application however, and some manual intervention may be needed to bring that application up on the Secondary server. Please consult with your Neverfail Regional team in these instances. If protected data is from an accounting package, the customer needs to confirm if their accounting solution has the ability to roll out incomplete transactions (i.e. is it crash consistent). If not, there is a high potential they could lose transactions. This is not a Neverfail issue, but applies to anything that has a replication component. If this is the case, Neverfail has terminology the customer should acknowledge beforehand.

5. For IIS servers:
   1. Are there any other application running on the IIS server?
   2. Is this server for a corporate website, or accessed by users in the outside world?
   3. Are you looking at a LAN or WAN installation?
   4. Is the IIS server running ColdFusion on it?
   5. Is your IIS server running on SQL or a file structure?

If the IIS server is for a corporate website, and the implementation will be in a WAN with different subnets, they will have to decide how to deal with external IP propagation as well. While Neverfail will fail the server over automatically and update the internal DNS server, users outside of the company still need to get to the site via external DNS servers. That would have to be changed outside of Neverfail, and it can take 12-48 hours to propagate across the entire World Wide Web. Again, this is not specific to Neverfail, but to all technologies, and needs to be discussed. Please consult with your Neverfail Regional team in these instances.

6. For SharePoint servers:
   1. Are you running a standalone server, a medium portal, or a large portal?
   2. If standalone, are you running SharePoint on a SQL backend, or a File System backend?
   3. If stand alone, are you running the database on the same server or a separate server?
7. For BlackBerry Servers, are you running BES on a SQL or MSDE backend?
8. If the installation is to be in a WAN (different physical locations):
   1. What is the type of connection to your secondary facility?
   2. What is the average available bandwidth?
   3. Have they run SCOPE for the bandwidth assessment yet? If not, they need to do so.

All WAN rollouts should be quoted the Low Bandwidth Module.  In any WAN installation, where bandwidth is a potential question, you should always run SCOPE with the bandwidth estimator before the sale and quote the Low Bandwidth Module for each server pair. Total bandwidth is not as important as available bandwidth vs. total data that needs to be replicated at that time.

9. If they need Data Rollback Module, are they running Windows 2003 SP1 or above?

Once this information has been obtained, you then have all of the information necessary to determine if Neverfail is the right solution for the client and effectively propose Neverfail.  When proposing Neverfail, use the information gathered to highlight why Neverfail is the right solution for the client.  Explain how Neverfail will easily integrate into the client's current server environment.

Applies To

Not Applicable

Related Information

None

KBID-1071