This is to warn other users who might run into similar troubles.
We have set up a Sparx Keystore Server to maintain our Enterprise Architect Corporate floating licenses using the Active Directory authentication method. Due to the limited performance requirements, we are using a virtual machine with a single CPU.
This worked well for some time. Since we experienced performance issues concerning the machine’s interactivity at boot time, we increased the number of virtual CPUs from 1 to 2. From this time on, we were
unable to check out any EA license. When eventually returning to let the virtual machine use only a single CPU, everything returned to normal.
This one was rather tricky since there is no obvious connection between the cause of the error and the observed symptoms.
Details of observed behaviourAfter increasing the number of CPUs, EA was still able to contact the license server (using the “Test” button when entering the SSKS data), but there was no “Product” offered to select. This usually means that the user is not member of the required AD group. The Keystore Manager application was able to contact the License Service and displayed the correct number of stored floating license. Unfortuately, it was unable to show the details (list of licenses, check out time, user, valid until etc) but showed a ‘connection lost’ error instead.
The ssks logfile did not give useful hints. In fact, it was misleading. Reasserting a checked out license failed:
REASSERT FAIL, dilbert, Sparx Systems Enterprise Architect build 1513, xxxx-xxxx-xxxx-xxxx, EA Corporate Edition, SSKSAnonymous:: dilbertsmachine\dilbert, Error: User 'dilbert' not permitted to checkout product EA Corporate EditionChecking out licenses just failed without notice.
Since it appeared that the AD authentication no longer worked, I added a section to the auth config:
GROUP
Name=SSKSAnonymous
IsManager=false
END GROUPand as expected, the KeyStore Manager was able to show the license details. However, we were not able to find any problem with the AD configuration.
It took some serious effort to analyze the situation. Eventually we gave up and had the idea to return to single CPU which turned out to solve the problem.