Fixing Licensing Problems - Updated June 3, 2002

June 3, 2002 - Updated patch NLSLSP6A to NLSLSP6.

Apr. 29, 2002 - Added note about the PM commands to display license information.

Note: You might want to read Novell TID 10051637, "Troubleshooting BorderManager Licensing" at http://support.novell.com. Also check out TID 10013723, "Understanding NetWare 5 Licensing". Also, for C0001006 errors (All Licenses in Use), see TID 10025573, "How to eliminate error C0001006 from being broadcast to all users".

August 23, 2000: An AppNote has been published by Novell on Troubleshooting BorderManager Licensing Issues. Go to this LINK.

Background

These instructions apply to both NetWare 5.x and BorderManager NLS-based licenses, and to some extent, ZENWorks Software Mettering licenses. (NLS=Novell Licensing Services). NLS-based licenses suffer from the disadvantage of being very sensitive to NDS communications problems. If there is something going on that prevents a quick communication to and from NDS, license issues can occur. That explanation still fails to explain why some licenses just seem to fail completely - perhaps when they were created an NDS problem occurred.

NLS-based licenses are licenses which are stored in NDS and accessed by a server through NLSLSP.NLM. The NLSLSP program communicates to NDS through the NLS_LSP_<servername> object. This object is created using the SETUPNLS.NLM utility, which can be run manually or transparently through the netWare 5.x NWCONFIG, License Options, Create License Server Provider menu entry. Licenses can be installed either in NWCONFIG, or in NWADMN32, Tools, Novell Licensing Services, Add Licenses.

BorderManager probably suffers from NLS license issues more than other servers simply because the Enterprise Edition contains five separate NLS licenses:

Each of the licenses is contained inside a License Container which also shows the version number of the license. As an example:

This does not mean that 300 users are licensed, it means that the license is for BorderManager version 3.00. A +350 means BorderManager 3.5 (or BorderManager 3.6).

NetWare 5 licenses look like:

These containers hold, respectively, NetWare 5.00 server connection license(s), and NetWare 5.00 user connection licenses. NetWare 5.1 licenses look the same except they will say +510.

Licenses, except MLA licenses, must be assigned to a server. Normally, installing licenses as part of an installation routine also assigns the license to the server, but if you install a license using NWADM32.EXE, the license is NOT automatically assigned to a server. NWADMN32 allows you to manually assign the license to a server. Normally you will always want to make a server assignment, except for MLA licenses. MLA licenses can be shared by other servers in the same context or lower in the tree as long as an explicit assignment has not been made. If you do not have an MLA license (and if you don't know what an MLA license is, you probably don't have one), then you need to be sure that you have the license assigned to the server or it will not work.

Look inside one of the license containers, and you will see one or more license objects. Each license object should exist with a name equal to the license object's serial number. Click on one of the license objects to open it up. You should see five tabs on the right:

On the General screen you will see one very important statistic: Units in Use. If this value is 0, then you have a problem. If units in use is not equal to 1 for a BorderManager license, then the BorderManager server is not using it (the server could be down). If the BorderManager server is up and running, check the Assignments tab to see if there is a Server Assignment. If the Server Assignment is blank, manually add a server assignment. Do not assign users to BorderManager service licenses.

The Installer tab contains one very important property - the user ID of the user who installed the license. The installer is considered the owner of the license, and is generally the only user that NDS will allow to delete that license. If you have deleted the user ID of the installer, you may need to recreate the same ID and log in as that user in order to manipulate the license.

License Error Codes

If you have licensing problems, you may see various error codes, which are shown in TID 10013723. Each code has a specific meaning, and you should understand what the error code means before proceeding.

Policy Manager Display (PM Commands)

It seems many people do not know about the Policy Manager commands, which can be useful for getting basic licensing information. These commands are typed at the server console, and can help you determine whether or not you are out of user licenses, and some other information. I don't see this as being directly related to BorderManager licenses, but you may find the information useful. Try these commands: PM HELP, PM DISPLAY, PM STATS. See Novell TID 10060109 for additional information.

A Common Problem - No License Available When Server Boots

If you have just applied one of the NetWare service packs with the NLS updates, and now you see something like this:

"NBMLicense Manager - Unable to obtain a valid license "

You probably don't have a license problem at all. Instead, the BorderManager software is loading and timing out before the updated NLS modules are ready to provide licensing services. If you can manually load PROXY.NLM after the NLSFLAIM.NLM completes loading, this is probably the issue.

The workaround is pretty simple, usually. Delay BorderManager from loading for a little while, so that NLS completes initializing, and licenses are available. What has worked for me, and others, is to use a ? in front of the LOAD BRDSRV, and have that line last in autoexec.ncf, as I show below:

etc, etc, etc.....
LOAD SYS:ETC\CPFILTER\CPFILTER
LOAD ACLCHECK /S < see the readme in the latest patches, such as BM35C06.EXE, for ACLCHECK command line options.
?LOAD BRDSRV

The ? in front of a command will, by default, introduce a 10 second delay before the command is executed. This is normally enough time for NLS services to finish loading. There are ways to change the default 10 seconds to a longer or shorter value as well. If you need more delay, add another ? to some command before BorderManager loads.

Fixing License Problems

Now we get to the heart of the matter. You have probably come here because you have a licensing problem, and you need to solve it. There are really only a few things I can suggest here, and often the most useful method is to simply delete and reinstall licenses AND the NLS_LSP_<servername> object. Try the following procedure:

Make A Server Assignment

Using NWADMN32 to look at the license object itself, be sure you have a server assigned!

Note: For BorderManager 3.6 l.icenses, you should NOT need to have a server assignment as these licenses are essentially MLA licenses.

Install the Correct Licenses

This one bit me once. BorderManager 3.0 licenses don't work on BorderManager 3.5 servers. They look a lot alike though... If installing BorderManager 3.5, your license container objects should end in +350, not +300.

Note: BorderManager 3.6 uses 3.5 licenses! The licenses shipped with BorderManager 3.6 are MLA versions of 3.5 licenses (unlimited number of servers can use the same license object).

Have a NLS_LSP_<servername> Object

Be sure that the server has an NLS_LSP_<servername> object. Use SETUPNLS to create one if it does not exist, and then reboot the server.

Check the NLS_LSP_<servername> Object Settings

The NLS_LSP_<servername> object can be configured with NWADMN32 to search for licenses to the top of the tree, or just to the root of the partition. If you have licenses in another context higher in the tree (not recommended), be sure you have not limited the search to the local partition root.

Be Sure NLSLSP is Running

Use LOAD NLSLSP at the server console to ensure that the licensing services NLM is loaded. For NetWare5, this module should be loaded automatically, but for NetWare 4.11 servers, you may need to add it to AUTOEXEC.NCF. If it was not running before, you may need to reboot the server to get it to really look for its assigned licenses.

Same Version of NLSLSP on All Servers

Some people have said that their licensing problems went away after upgrading NLSLSP.NLM to the latest version on all the servers in the tree. I cannot confirm that every server needs to be upgraded, though perhaps every server in the same replica ring as the BorderManager server would make sense.

June 3, 2002 - NLSLSP6.EXE is a new licensing services patch, primarily for NetWare 4.11 / 4.2 servers. However, it has newer files than the version contained in NW50SP6. Certainly have a look at this patch if you are having problems with an older version of licensing services.

Have the license objects in the same context as the server

While it is theoretically possible to have the licenses higher in the tree than the server, it just isn't a good idea. Even MLA licenses should be put into the same context as the server, and MLA licenses (unlike others) can be installed into multiple contexts at the same time.

If Using BorderManager 3.0, check out the BM3LICFX.EXE patch

See TID 2954946, "BorderManager 3.0 License Fix"

BorderManager Snapins May Not Be Current on the Server

BM35SP2 does not update the snapins in the SYS:PUBLIC\BRDRMGR\SNAPINS directory, so you have to manually copy them from the patch to that directory before running the SETUP program there to update other servers. (The BorderManager server itself should have the correct snapins installed by BM35SP2, this only applies to updating a non-BorderManager server with the BorderManager snapins). A symptom of this problem is 'No BorderManager licenses found' error when using NWADMN32 to try to administer BorderManager.

BSCOV.DLL, BSMON.DLL and RESTRICT.DLL error on loading NWADMN32

The versions of these files may be obsolete. FYI: My BorderManager 3.6 servers, patched up to BM36SP1A and the PXY027 level, have the following dates:

BSCOV.DLL 9/15/1999
SMON.DLL 9/14/1999
ESTRICT.DLL 10/24/2001 (This is from the PXY027.EXE patch)

Note that the PROXYCFG.DLL file should be moved from PUBLIC/WIN32/SNAPINS to PUBLIC/WIN32 in many cases.

NWADMN32 loads with a 'license not installed' error

Move the NLSAPI32.DLL from SYS:PUBLIC to SYS:PUBLIC\WIN32.

License Not Installed Error when trying to load Proxy

In SYS:SYSTEM\NLS\4, you should have a NBMLICEN.MSG file. If it is not there, copy it in from the BorderManager installation CD.

If All Else Fails, Delete and Recreate

  1. Have the server license and BorderManager license disks at hand, and be sure they are readable!
  2. Be sure NDS is healthy and synchronized before proceeding.
  3. Delete either the problem licenses or ALL the licenses for the server. If you cannot delete the licenses, you may need to log in as the same user that created the license objects.
  4. Delete the NLS_LSP_<servername> object using NWADMN32.
  5. At the server console, LOAD SETUPNLS to create a new NLS_LSP_<servername> object for the server.
  6. Install the licenses again.
  8. Reboot the server.
Note: If you want to share an MLA license between multiple servers, you do not want to use NWCONFIG to install the license because you do not want to make a server assignment for a shared MLA license. NWCONFIG explicitly assigns the license to a server, which is good for BorderManager 3.0 and 3.5 non-MLA licenses.

The procedure above usually fixes license problems, especially if they occurred right after installing a service pack that made some NLS changes. If the procedure does not help, you may want to look for NDS synchronization issues, repeat the process, and/or call Novell to open an incident.

If the License Reinstall Doesn't Help

One sysop tried all of the tips listed above trying to get the licenses to be recognized by his BorderManager 3.5 server. He then found something that worked, first time. He tried using the LICINST.NLM to install the license, but there was no file by that name on his NetWare 5 server. So he copied LICINST.NLM from the BorderManager 3.5 CD, reinstalled BM licenses using LICINST, and they worked immediately.

Deleting ZENWorks Software Metering Licenses

I just throw out this bit of experience I had with ZENWork software metering license certificates in case it may be helpful. Even after I had just created a license certificate and was still logged in as Admin, I was unable to delete the new license certificates. Or so I thought. I would get an error saying that I did not have the rights to delete the object. However, I discovered, through a combination of frustration and happy accident, that if I repeatedly tried the delete the object three times in a row, even though I got an error message, the license was deleted. I hope this works for you as well...


Return to the Main Page