When you install SQL Server, you'll see a dialog box asking which licensing choice you want to use: Per-Server or Per-Seat. A special licensing option, the Internet Connector, is available for using SQL Server on the Internet.
The license agreement in the SQL Server box is a legal document that you should read and understand. This section explains the licensing schemes but does not represent the official licensing policy of the product. Packaging and licensing periodically change. Consult the licensing agreement to be sure you are in compliance and have chosen the best options for your needs.
Per-server licensing lets you support a stated maximum number of simultaneous users for a specific installation of SQL Server. This is probably the simplest option, although it might not be the best choice for you. Choose per-server if you have only one or two instances of SQL Server in your environment or if you use SQL Server with a large number of occasional users, with a minority of them being connected to the specific instance of SQL Server at any time. Per-server licensing is considered unlimited for more than 250 users with SQL Server Enterprise edition.
Per-seat licensing lets you economically deploy multiple instances of SQL Server to serve a given population of users. A user with a per-seat license can access any instance of SQL Server in the environment. You can deploy additional instances of SQL Server with minimal expense and you don't have to buy additional client licenses. You simply acquire as many additional server licenses as you need, and your users are already licensed to use them.
The two licensing options also require you to buy user licenses (also referred to as CALs, or client access licenses). But you (the administrator) must decide whether to aggregate the count of user licenses and use the per-server option to support a maximum number of simultaneous users or to designate each license to a specific user, who can then access any number of SQL Server instances in the environment. If need be, you can start with per-server licensing and later convert to per-seat licensing. The conversion is done on the honor system; you don't have to notify Microsoft. It is, however, intended to be a one-time, one-way conversion.
Table 4-3 shows the estimated retail prices (ERP) for each license type as of January 1999.
Table 4-3. Prices of SQL Server license types.
|License Type||ERP U.S.|
|Server license + 5 CALs||$1399|
|Server license + 10 CALs||$1999|
|Server license + 25 CALs||$3999|
|Internet Connector licensing option||$2999 per processor on each machine on which SQL Server will be running on the Internet|
To better understand these licensing options, consider a couple of scenarios involving the ACME Company, which is deploying its first installation of SQL Server. All 100 employees will access the application from time to time, but ACME is confident that no more than 25 users will do so simultaneously . ACME chooses per-server licensing and a SQL Server license that includes 25 CALs. This choice is the most economical for ACME. Its 100 users do not each need to have a license to access any installation of SQL Server ( especially since ACME will initially have only one installation of SQL Server).
After three months, the popularity of the application grows and periodically someone trying to connect to SQL Server gets error message 18458, which states that all licensed connections are in use. ACME calculates that it now needs to support 35 simultaneous users. It buys a 10-pack of user licenses to add to the 25 that it purchased with SQL Server. Using the Licensing applet in the Windows NT Control Panel, ACME updates the per-server licensing option for SQL Server to indicate its new status of supporting 35 simultaneous connections.
ACME decides to expand its use of SQL Server. It plans to deploy seven new SQL Server machines and possibly more later. All 100 employees will never access any single installation of SQL Server simultaneously, but they all will use one or more applications that use SQL Server as a regular part of their jobs. ACME decides to move to per-seat licensing. It converts its 35 user licenses to specific users and buys seven more SQL Server packages, each with 10 CALS, and installs each of them with the per-seat option. It then converts the existing SQL Server installation from the per-server to the per-seat option. Later in the year, ACME grows even more and decides to roll out two more SQL Server installations, for a total of 10. But because its user base has only grown by a few employees, ACME needs to procure only two new SQL Server packages, with the minimum of 5 CALs with each. All of its employees are already licensed to use any and all SQL Server installations deployed, and the cost of each new SQL Server, even if accessed by every employee in the company, is only $1399.
SQL Server Desktop can only be installed on a machine that has a per-seat CAL.
Neither of the first two licensing options makes sense when you use SQL Server on the Internet. The per-seat choice makes no sense because potentially millions of "users" can access your Web site and behind the scenes cause a query to get executed that extracts data from SQL Server. It is impossible , not to mention prohibitively expensive, to determine whether the users are licensed for SQL Server use. Similarly, the per-server option isn't practical because Internet access is usually stateless. Unlike in a typical client/server environment, a client on the Internet rarely stays connected to SQL Server. With a product such as Microsoft Internet Information Server (IIS) with the Internet Connector feature, users on the Internet cause commands and queries to be dynamically dispatched to SQL Server. For example, a user might click on a region of a Web page that shows current seat availability for a concert, resulting in a query to SQL Server. A connection is established on behalf of the user, the query is processed , the user disconnects, and the result set of the query is dynamically merged into the Web page that the user is viewing. All this happens in perhaps a second or two. When the user makes another request a moment later, the same process occurs.
In a normal LAN-based client/server application, a client remains connected at least for several minutes, even while the client has no active query processing. On the Internet, it is impractical to count distinct SQL Server users at least in the same way that the per-server license option was intended to support. For this reason, Microsoft offers the SQL Server Internet Connector licensing option, which you can use instead of or in addition to user licenses. SQL Server can be accessed through your Web server software (such as IIS) on an unlimited basis in a cost-effective way. If you use SQL Server only for publishing data on your Web server, the Internet Connector license is essentially all you need. But remember that if you are also supporting a number of more traditional client/server users, you must have the appropriate user licenses.
Note that you do not need the Internet Connector license if users are simply accessing an HTML file that was statically built with the Web Assistant Wizard. Unlike the situation in which Internet users cause queries to be dispatched dynamically to SQL Server, in this case users do not cause statements to be issued to SQL Server; they simply read an HTML file created and periodically updated with SQL Server data. Therefore, the file is essentially static. Reading the file does not cause work to be performed at the SQL Server. (The user running the Web Assistant Wizard must be a licensed user, of course.)
Strict enforcement is not the goal of SQL Server licensing. The licenses let honest users be honest and make it easier for users to manage their environment and remain in compliance. The standard Windows NT Server licensing dialog box appears during installation. The user chooses the appropriate licensing option and, in the case of the per-server option, enters the number of user licenses purchased specifically for that server.
For per-server licensing, SQL Server keeps a list of all workstations currently connected. Each workstation represents one user. In this respect, a user is different from a SQL Server connection, since an application often has several connections open to the same instance of SQL Server. In addition, one workstation can use multiple applications that access the same installation of SQL Server. The user count for per-server licensing is based on a unique value for each workstation. Typically, this value reflects the identifier for the first Network Interface Card (NIC) found in the system. (Network software relies on a unique signature that is included on each NIC upon its manufacture.) The SQL Server client interfaces grab the NIC's identifier and pass it as part of the login handshake between client and server. The count is incremented if the NIC signature is not included in SQL Server's list of connected workstations. If the signature does exist in the list, SQL Server recognizes that the connection is from a workstation that is already connected and the count does not change. When all connections having a given NIC ID disconnect, the count decreases. Even if multiple application types from a given workstation connect to the server, they all contain the same NIC ID and are recognized as one user. For example, a Windows NT Workstation might be simultaneously running an old MS-DOS_based application, a Windows 3.11 DB-Library application, a 32-bit Windows DB-Library application, a 32-bit ODBC application, and an OLE DB application. Although these all access SQL Server and some might use multiple connections, the SQL Server per-server counting mechanism recognizes all of them as the same user and the count for all of them is one.
A client without a network card can access SQL Server using Remote Access Services (RAS). When no NIC ID is available, the client creates a random number and uses it for all connections from that workstation. (If a machine has a NIC, the NIC ID is used even when the connection is via RAS rather than the network card.) Although this random number could theoretically collide with another random number, the chances of this happening are less than those for winning the lottery. Even if it did happen, the collision would reduce the count and would never cause the count to inaccurately exceed the stated limit.
To change the per-server count, you simply use the Licensing applet and adjust the count accordingly . The next time SQL Server starts, the new value takes effect. Obviously, this does not enforce license compliance it is completely up to you to enter and keep the correct value. But the applet provides a way for you to monitor your compliance and fulfills the goal of letting honest people stay honest. You should also be aware that a small overhead in static memory structures exists at the server to keep the count for each user licensed. If a reasonable value is entered, overhead should never be an issue.
With per-seat licensing, SQL Server simply calls the Windows NT APIs that are used for integration with the License Manager and the Licensing applet (sometimes referred to as the "honesty" API) and reports each user who logged on. SQL Server cannot know that a workstation that just connected actually has a user license to access the server. But by providing the information to the Windows NT services, you can use the Windows NT Server License Manager (contained in the Administrative Tools program group ) to monitor compliance. Both the per-server and per-seat licensing options call the Windows NT "honesty" services.
One final point about licensing: in a three- tier architecture, clients sometimes connect to an application server, which in turn connects to SQL Server. In effect, the application server multiplexes the client connections to SQL Server. The application as a whole might service a large number of clients, but only the single, middle-tier application server directly connects to SQL Server. However, the licensing policies of SQL Server are based on the clients who access SQL Server services, albeit by a proxy. So even though the physical connection in this case is from the single application server machine, if 50 users make use of SQL Server by proxy, SQL Server must be licensed for all 50 users.