Has anyone else seen a problem when WebLM is on a separate VMware server and AES is also VMware, when the AES loses connectivity to the WebLM, that all applications are dropped/unusable?

Backbone support seems to think the "fix" for this issue is to enable reserved licensing but I believe that to be a band-aid for the real problem. The AES should be able to run for 30 days in license error/grace period mode like any other platform, unless I missed something. I'm wondering how many others have seen this issue, and if anyone knows of a more permanent resolution.

BBE is right.

Once an AE Services server has gone 'into' licensed mode (began using legitimate licenses from a WebLM server), it will remain that mode. If it looses connectivity with WebLM then any license it holds will continue to be in effect (AE Services will not be able to allocate new licenses, and any license that is release will go into a pool that will be returned to WebLM when connectivity is restored - but can not be allocated for some other activity).

The way to accommodate an unstable connection between an AE services server and a WebLM is to use some (an appropriate whatever that means in the customer context) amount reserved licensing notwithstanding the need to address the unstable network issues that are at the root of the problem.

Are you saying it's normal for all applications to drop and become unusable any time the AES loses connectivity to WebLM? Because I have not seen that with any other AES release in the past.

From your description it sounds like you are saying what I am trying to point out - that the current licenses/services should remain up - am I reading this correctly?
If it looses connectivity with WebLM then any license it holds will continue to be in effect <<this is not happening with VMware AES/separate WebLM on VMware

The application just cannot successfully have requests handled that would require new licenses be allocated. How the application reacts to that is up to the application not the AE Services server. Thus if the connection to the applications are dropping it is not (supposed to be) the AE Services that is dropping the connection; it is the application in response to an error response from AE Services. A close examination of the log files would confirm who is initiating the disconnect. You may have to increase the logging level to have enough data to work from.

Once an AES has acquired a license .. it 'owns' it till it is released. Thus if a monitor has been established, the monitor remains in effect until it is released. Events for that monitor will continue even if connectivity with WebLM is lost.

Most other license cases are quite dynamic (license is acquired when request is received, request processed, license released). If that is the use case then while WebLM connectivity is not available, the request would be denied.

What kind of licenses are we discussing here.. TSAPI Basic, TSAPI Advanced, DMCC, something else?

"From your description it sounds like you are saying what I am trying to point out - that the current licenses/services should remain up - am I reading this correctly?" - yes but, see the first paragraph.

I did some more digging on this. I work for a BP and we had several customers experience this issue, however I did not personally handle the tickets. I am reviewing logs on these systems for further details.

I was able to test this in our lab with 2 separate VMware servers and current TSAPI and DMCC connections did remain up during the WebLM outage, as designed. Hopefully this is not a widespread issue and there is something unique about the customers that experienced it. I'll review those cases and if I still have questions, let you know.

Thank you for confirming the VMware-based servers should not behave any differently than any other server type.

I am having issue with AES and WEBLM server: I could access WEBLM directly but AES cannot access it: It is giving me HTTP 403 error – Forbidden "Cross-Site Request Forgery (CSRF) is suspected in your request". I have configured WebLM with 7.1.3 version and AES is in the same 7.1.3 version too. I have configured all TLS connections into the AES server as I saw in other post that WEBLM and MS .
I have other customer with stand alone WEBLM server in release 7, but it is the first time that I have this kind of issue.

If you procured this system from Devconnect, please open a technical support ticket. Otherwise, you should open a support request with your business partner or Avaya Client Services.

Martin