This chapter concerns licensing services in NetWare 6, and describes how to install and manage license certificates. The objectives important to this chapter are found on page 10-1:
Concepts:
Identify How Server and User Licensing WorksNetWare 6 uses Novell Licensing Service (NLS) to manage the number of workstations connected to your network. This is not a change from previous versions of NetWare. A difference is that you can use iManager to install license certificates for new users and new servers. You should be aware that NetWare 6 uses two kinds of license certificates: one for users and the other one for servers. A user license certificate will allow users to access any number of servers, as long as they have proper rights. A general rule is that you should install license certificates higher in the tree than the objects that will use them. An exception is that you are allowed to install license certificate in the same container as users, if all the users in the tree are in that container. History: Before NetWare 6, the licensing model Novell used was the Server Connection License (SCL) model. This was inefficient, in that users tied up a user license for each server they concurrently used. Other resources in the network also tied up user licenses, such as printers and workstations configured for ZENworks. It is possible to run out of licenses in this kind of environment even if all users are not connected. NetWare 6 follows the User Access Licensing (UAL) model. In this model, a single license gives a user access to as many servers and resources as the user has rights to. When a user logs in to the tree, a license is assigned. The same license remains assigned to that user, unless the user stays logged out for 90 days. (This is similar to the way IP addresses are assigned and used by DHCP systems.) If you need to release a license sooner than 90 days from last login, use iManager to do so. SCL licenses are released when a user logs out, but that does not help much, since you need more of them. Novell notes that it can provide Academic licenses to schools and to companies whose workers are assigned to shifts. With Academic licenses, you can change the 90 day release period to a time frame that your license agreement will specify. If you have not changed all your servers to NetWare 6, you may have both SCL and UAL licenses active on your network. A user would need one SCL license for each NetWare 4 or 5 server they are using, but would only need one UAL license for any resources associated with NetWare 6 servers. When a NetWare user logs in to the network, NLS searches for a license for the user. The search starts at the user's container and goes up the tree. A server must have a license certificate placed inside its license container object. A server license usually will be one of the following types, three of which are related to the network's size:
To remember these in the right relationship, remember Roman numerals. M (1000) is bigger than C (100), which is bigger than V (5). The value of the Roman numerals is given here for relative reference only. Don't get confused into thinking, for example, that there are only 5 licenses in a Volume License Agreement. A server can also be given an "emergency" license, downloadable from Novell. This is meant to be temporary, so do it only when you install a new device that you don't have a license for. If you buy a new installation kit, over the counter at a retailer, it should come with an installation CD and a license diskette. This is called buying a Red Box product by your text. Identify Key NLS ComponentsThe next topic in the chapter discusses the components of Novell Licensing Services (NLS). NLS is a service with several purposes. It allows only as many connections to the network as there are licenses installed for such connections. It tracks the number of users of an application installed on the network, if that application supports such tracking. The License Service Provider (LSP) is created on a Novell server by running NLSLSP.NLM. (This can be done on NetWare 4.11 or later servers.) The server this software runs on should have a Master or Read/Write replica of the NDS partition its license certificates are in. If it does not have such a replica, the server must be able to communicate with a server that has such a replica. NLS service can be installed on a server when it is created, or can be added later with Deployment Manager (NWDEPLOY.EXE). NLS software is installed in the SYS:\PUBLIC and SYS:\SYSTEM directories on servers that NLS service is installed on. Workstations and servers can both run the NLS client software to request license services. NLS clients on NLM platforms (Novell servers) search only the connection they currently have for a license. NLS clients for 32-bit versions of Windows will search the tree upward from the server they are connected with. An NDS object called NLS_LSP_servername is created when the schema is extended with SETUPNLS.NLM or when you run NWCONFIG | License Options | Create License Service Provider. The LSP object will contain the name of a transaction database, information about how far up the tree to run searches, and notifications about license problems, including unlicensed access. License certificate objects represent the actual licenses installed in eDirectory. The files that you install licenses from may have several types of extensions:
License certificate objects contain other items described in the text.
Other terms associated with license certificates:
Manage License Certificates in the eDirectory TreeYou will manage licensing service through two eDirectory object types: license container and license certificate objects. License certificates are always stored in license containers. License container objects are created when a server is created that runs NLS. These objects go into the same eDirectory context that the server object is in. In iManager, you can examine the properties of license container object. When troubleshooting, make sure that the version of NLS reported on the object's General tab is the same as the version of NLS running on other network servers. Troubleshoot connection issues with the container object's Units in Use tab. License certificate objects have three tabs in iManager:
Install NLS Certificates and View NetWare UsageIn general, place license certificates near the object (server, user, etc.) that will need them. Place certificates on both sides of a WAN link, if users on both sides of the link will need them. If NetWare is installed without licenses (an option, if you have no license disk when installing) two grace licenses are granted: one for the server, one for a user. A Novell International Cryptographic Infrastructure (NICI) license must be installed on each server. This is called the encryption foundation key in the installation. These license files end with NFK. CLA and VLA licensing works as described above. MLA is a bit different: you do not assign the license to a specific server, nor do you have to install the licenses multiple times (although this is allowed). An MLA server license is good for the whole tree, so you can install it once or many times. If you do assign a license to a specific server, no other server will be able to use it. To install licenses with iManager (for example, the license for an application):
In other than MLA scenarios, servers must be assigned to service license certificates. (In MLA, this is not necessary.) When certificates are associated with a server, no other server can administer those certificates. Servers can have multiple certificates assigned to them. You can monitor license usage with the NetWare usage tool. It requires two specific NLMs be run on the server: NWUSAGE and NLSLRUP. Other NLMs support the data gathering functions as well: CONNAUD, NLSMETER, and NLSADAPT. The NetWare Usage tool is accessed through Remote Manager. You can set configuration settings through this interface or through the server console.
|