LMGRD 11.1.1.0 seems to have a problem when it is run as a service using Log On information that is not the Local System account.
When I specify a different log in (whether a local admin login or a domain login with admin privs) and start the service, I instantly get an Error 1053: The service did not respond to the start or control request in a timely fashion. error. When using the Local System account, everything is fine.
I checked the event logs and found that LMGRD was logging the following when using a different account for the service: The license server manager (lmgrd) is using license file C:\flexlm\license.dat.
What's interesting about that is the fact that my registry entries for the Flex service clearly point to a completely different folder where all of my Flex and license files reside. That default path of "c:\flexlm\license.dat" is the exact same thing you get if you were to run lmgrd.exe at the command line with no parameters.
So, when running the service with a user account, lmgrd ignores the values in the registry and defaults to an invalid path.
I thought I could work around this by changing the value in the registry for the service's executable so that it contained the appropriate command line parameters. This does, actually, get the service to run under the custom log on account, but it still generates the 1053 error (it looks like the service failed, but if you check the process list, both lmgrd and the daemon are running, Flex enabled apps are able to check out licenses).
While that workaround gets it up and running, it still leaves it looking ugly. I don't really want to have to tell customers to do all that.
Does anybody know if this is new behavior or has lmgrd always had a problem being run as a service with alternative log on credentials?
