Introduction: a look in the past
All the way up to SAP Business One Release 6.5, the license information was stored inside the SBO-Common database. This caused an interesting side-effect: by copying the SBO-COMMON database, you also got a copy of all the licenses in that database. It was no wonder that SAP soon fixed this loophole. Starting with B1 Release 2004, there was a new service called the License Manager. The License Manager brought us a whole new smorgasbord of pain points. Before Release 2004, if you had a working database connection, you were most likely also able to log into SAP B1.
The License Manager is a bit different animal, as it is tightly interwoven with Windows authentication. One of the first issues I remember resolving in the ramp-up for 2004 was connecting to the server from a B1 client on a workstation that didn't belong to the same Windows domain as the server. It turned out that either the client and the server need to be in the same Windows domain (or ActiveDirectory) or alternatively the userid used to log in to the workstation also needs to be found on the server as a local account, with exactly the same password on both accounts. Thus, instead of a two-level authentication (SQL Server and B1), there are now three levels: Windows network authentication, SQL Server authentication and B1 authentication.
Another issue came up with the security fixes in Windows Server 2003 service packs. Those service packs were so effective in closing the security holes that the clients once again could not log in to the server. The reason was that the License Service is dependent on DCOM and the security fixes made the DCOM Settings too strict. There are excellent SAP Notes (Nrs 833798 and 824976) on this issue, so I will let the readers who need this information look them up from the Service Marketplace.
In the rest of this blog, I will present some of the issues that I've witnessed during my four-year journey with the License Manager. I am assuming that everyone's already read the SAP Business One License Guide that comes with the B1 installation media. I will try not to repeat the issues documented there. Some of the issues discussed here are discussed in SAP Notes or in the Forums, but anyway I thought it would be useful to have a single document putting all these issues together.
License Manager FAQ
Q: When exactly do we need the License Manager ?
A: The B1 clients (as well as the DI Server and all the DI API-based client applications) only need to connect to the License server when logging in. After the users have been successfully logged in, you could even restart or completely stop the License server without the logged-in users ever noticing it.
Q: How does the License Manager store information about which licenses have been allocated to which user ?
A: The following image is taken directly from the License Guide:
The License Guide explains that "the license mechanism in SAP Business One is implemented using a License Service, a License File, and an external API". The license file is used to import new licenses to the License Service, but SAP does disclose where these imported licenses actually are located. Not that we need to know it, though. In fact, it' more useful to know the file that stores information about how those licenses are allocated to users. That file actually exists in the program folder for the License Manager. For B1 2005 SP1, the default installation folder is C:\Program Files\SAP\SAP Business One ServerTools\License. If the License Manager has been in use, you should be able to locate a file called B1Upf.xml. I'll return to this file regarding the issue of reclaiming 'lost' licenses.
Q: It Takes several minutes to log into SAP B1, even from a fast local network. How to fix this?
A: This issue is often a result of having had two active network interface cards in the server at the time of installing the license service. This is a known bug addressed in some SAP Notes. SAP has promised to fix this in some future release. Meanwhile, you can get the issue fixed by uninstalling the License Service, then making sure you only have one active NIC on the server and reinstalling the License Service. I've seen cases where the login time dropped down from 2-3 minutes to about 5 seconds after doing the fix.
Q: I have trouble importing the new license key. What to do?
A: There are a number of reasons that might be causing this. One particular thing which will always cause a license key import to fail is having the DI Server service started (with active sessions) while you're doing the import. It is always safest to stop all the other SAP B1 Services (except the License Service) when doing the license key import and also restart the License Service just prior to the import.
As a precaution, it might be a good idea to have all the users who need the system on that day already logged into B1 when doing the import. If anything goes wrong with the import, those users can continue using B1 without ever noticing the problem. That'll buy you some precious time.
Quite often, just trying the import once again will get the desired result. However, sometimes it seems that the keys sent by email are somehow corrupted. You might want to go to the Service Marketplace and download the key directly. This has fixed the problem for me several times.
Q: How to recover when all licenses are used up after a B1 client crashes?
A: If a B1 client crashes, it still reserves the "slot" on the license sserver that it reserved during login. As the License service limits the maximum number of simultaneous sessions for a single named user to two, you could still log in to B1 after recovering the client from the crash. However, another crash will leave both of your sessions reserved. What to do next? You could do as the License Guide instructs: wait for 3 minutes and then try connecting again so that the reserved connection has timed out. If you're in a hurry, you could also restart the License server, which actually clears up all the information about the users who have logged in. Restarting the License Manager might take a minute or two, but it is anyhow faster than waiting for timeout. Those users who are already logged in are not disturbed. Remember - License Service is only needed at login.
Q: My userid requires two licenses when using two databases. What is the problem ?
A: The funny thing about the License Service is that while B1 (or rather SQL Server) database is case insensitive regarding userid's (you cannot for instance create users 'User1' and 'user1' in the same B1 database as the database treats them as identical), the License Service isn't.
If you have several databases (I suppose everyone has at least a test database), you might easily end up in a situation where you have the same username in different databases but with different case (for instance, user1 against User1). If you wish to use both user accounts, they will gobble up two user licenses. From the B1 user interface, these usernames cannot be changed. Also, it is prohibited to manipulate the database directly.
Luckily, the DI API is permissive enough so that we *can* alter the userid as long as we are only modifying the case. For convenience, here's a simple DI Commander (version 2.0) snippet that shows how it can be done.
u=get(USER,1)
u.UserCode="ManageR"
if update(u):
print "OK"
else:
geterror()Please note that the second parameter of get should in this case be the value that is found in the INTERNAL_K column of the OUSR table.
Q: I'm having problems with login - the wrong license server address keeps coming up. How to fix this ?
A: There is a short reference to the SLIC table in the License Guide: "The SAP Business One workstations read the name of the license service to which they connect from the SLIC table in the SBO-Common database."
The problem is that this doesn't tell anything about the practical implications of this table.
Try running this query from B1 Query Builder or from MS SQL Query Analyzer to get an idea about how it works:
select lsrv from [SBO-COMMON].dbo.slicIt is usually a good idea not to provide the license server address and port when logging in (this applies to B1 clients, DI API and DI Server) unless you absolutely have to. SLIC-table is the place where B1 server stores information about the default address of the license server. Guess how it gets updated? Whenever you specify the License Manager address at login. Well, what's so wrong about that?
Let's say that we have one user who specifies the address as "192.168.220.20". Another user then logs in with "sap-server1", which happens to be the valid hostname for the server in IP address 192.168.220.20. Both are correct, of course. Except that it could be that some of the workstations may only recognize the IP address but not the hostname (for a variety of reasons that I'm not diving into deeper here). Once the SLIC table contains an address that the B1 client cannot resolve, the user can no longer log in.
The good thing is that once the user types in the correct address for the license server, she can log in. The bad thing is that the UI API add-ons don't follow: they will stubbornly refuse to connect until you can once again log in to B1 without manually giving the License Manager address. This is just one of the many reasons why I hate UI API add-ons so much.
Lessons from the field
For a long time, one of my customers had the license address problem reoccurring each time they rebooted the server. They were able to get rid of the problem by restarting the License Manager and then logging into B1 directly from the server (this procedure was repeated always after a reboot - luckily the reboot interval was pretty long). Eventually I found out what was causing this problem: A DI Server application that was installed on their server had the License Manager address specified in a properties file. Guess what address had been specified? How about 127.0.0.1:30000 ?-) Needless to say, the DI Server application was working just fine. It was just the B1 clients installed on other machines except the server that had problems, as for them the License Service was not located in localhost address 🙂
Another similar situation occurred in our own production environment. As I had a License Manager running locally on my laptop, I figured out it would be nice to use this License Manager instance instead of the one located on the server also when logging in to the production server. It worked very nicely, I didn't have to care about all that Domain authentication nonsense. But guess what happened to all those users of the production environment who didn't have a local License Manager ?
Q: I renamed the server that's running the license service. Now the license manager says that I don't have any licenses. What to do ?
A: The Windows hostname of the server is used as one of the ingredients of the hardware key. If you rename the server, the hardware key will change as well. If you can't change the name back, you need to apply for a new license key with the changed hardware key.
Q: I don't see as many licenses in the license management screen as I've bought. What is the problem ?
A: A not so uncommon situation that I've run into with some B1 production environments: a B1 license is assigned to a user that does not exist in any of the current B1 databases. However, this does not automatically liberate the license in License Service, it it was once assigned there.
Typically this would happen if a temporary user was created in a test database, given a license and then the whole database deleted before unassigning the license. As the username is no longer present in B1, you can't use the license management dialog to remove the license from the user.
How to reclaim this 'lost' license to active use? There are several possible approaches:
Method 1:"Raise the dead"
If you know the username that the license has been assigned to, you could of course create it in some test database and then use the license management dialog. Don't do it in a production database, though, as you would end up stuck with a user record that you can't completely delete from the database.
Method 2:"Genocide"
To liberate all the licenses currently assigned in the License Server, you could simply delete the whole file and then restart the License Server.
However, after this you would need to assign all the licenses again. This is perhaps not a problem if you have just a couple of users, but with say 50 users and five add-ons, it would be quite a nuisance.
Method 3:"Seek and destroy"
As the B1Upf.xml file is an XML file, you can stab it with any text editor such as Notepad. While it's not so difficult if you're at least a bit familiar with XML, it's still a bit awkward. Luckily, the XML Notepad 2007, which is available free from Microsoft renders the license assignment file pretty nicely. It allows WYSIWYG-type editing of the user tree. This is my favourite method as it is powerful but still pretty safe.
- SAP Managed Tags:
