Migrating to AE Services for Virtualized Environment from SWonly

[wpetilli]

We are heading down the path of migrating off of our AES SWonly offering (2 servers) to the VE. I'm not even sure what the difference is as my SWonly is running on vmware. My question is regarding the license file. I am pretty certain the license file has to be regenerated (if I'm using the term correctly). Since we have VMware techs on staff and a backup of the current AES data we don't see a need to engage any professional services. The only area of where we have no experience is PLDS. I have SSO credentials that allow me to download software all the time, and we have maintenance. Is there a high level explanation of the process of how I should get the new license files for this specific migration?

 

[kyle555]

PLDS licenses match up to the WebLM MAC address. So you don't license each server, rather you have a WebLM instance with a MAC address and you generate licenses for your products against that, then you point your products to your WebLM.
Did Avaya set yours up? I'm actually dealing with something like this right now and there seems to be cascading licensing scheme where you have a WebLM on each AES that connect to an Enterprise WebLM, and in the enterprise one you point to the local WebLMs to delegate licenses accordingly. You can split 50/50 or 60/40 or whatever you want. I'm having a bit of a problem wrapping my head around that aspect at the moment and I think I botched one and have to reinstall the VMWare version. AFAIK, an AES license is an AES license and it shouldn't matter whether its System Platform, SWOnly or VMWare.
The difference with SWOnly and VMWare is whether you put up the RHEL yourself and install the AES packages that way or whether you deploy an OVA from Avaya already built. If they're already on VMWare - what's the big deal?

 

[wpetilli]

Thanks..my current scenario is a bit more convoluted. We originally had our swonly installed by a BP on our own vm farm. I believe 6.1.1. I'm not even sure how the license file was applied on that version. A few years later our datacenters relocated and our sys admin basically cloned these instances and moved them onto a new vm farm. To get the system working he changed the new vm mac addresses to those of the previous and that got the license working. After that the firm rolled out LYNC 2013 and it was determined from AVAYA that v6.3 was required for compatibility. The same sys admin went ahead and upgraded the linux OS and then the AES software to 6.3. So there was no use of the AVAYA .ova nor any activity with the license file. On my AES servers right now there is no weblm configured, yet the AE services show the license in normal mode. I have no idea where the license even is. In my logs there are a bunch of TSAPI errors indicating unable to connect to weblm server. Of course, because there is none. So I did raise an AVAYA ticket and I'm certain they are going to flag this as a messed up implementation so I'm trying to prepare. My guess is somewhere in this upgrade process a license activity was supposed to take place and didn't. So I'm considering downloading the prepackaged .ova and weblm, but don't know how to get an updated copy of this current license file.

 

[wpetilli]

Not that it makes any difference, but I did just find the email with the original license files. I know they can't be re-used, but maybe the info in the email is helpful in getting new ones?

 

[kyle555]

Well, if you have access to your licensing in PLDS, you can search by host-id - which is the MAC the first license was generated against and choose to rehost and enter the MAC of the WebLM you want to use. But there must be some traffic leaving your AES to look for licensing, usually https port 52233, 8443, or http 8080. Maybe if you have root to the CLI of the aes you can netstat that and see where it is looking for licensing/at what IP and trace back that way.

 

[wpetilli]

Is there a way to just sort my current setup out? By just configuring a Weblm and either reapplying the license file (wherever it is sitting right now) or does just starting fresh make more sense?

 

[kyle555]

to reapply the license, the weblm server must have the same MAC address - which works ok if its on System Platform or something with a physical MAC address. If you delete a Midsize Enterprise template (as an example) and reinstall it, the System Manager WebLM won't have the same virtual MAC anymore, so you'd need to rehost it in PLDS at that point.

You should be ok if you can point your AES boxes/instances to the same WebLM, and you'd need to find which WebLM instance they originally pointed to. Maybe the MAC address in the xml license file of the first license can point you in that direction. When you install your AES in VMWare, in the web admin I believe you have a place you point that AES instance to a WebLM to grab a license. All to say, if you've got the original license server info, you might very well be OK.

Upon reading your post a bit more carefully, saying "there is no weblm configured" may make reference to "on the AES server itself" and not "at all". Somewhere there must be a WebLM with a total number of DMCC/TSAPI licenses purchased and how many are available.

What exact TSAPI errors are you getting to think you're not licensed?

 

[wpetilli]

In my error logs I have a massive amount of entries that show:

11:34:10.934 ERROR:WARNING:TSAPI:GenericLicense::SetMode:License mode changed to LICENSE_NORMAL; cause: Initialize license as normal
11:46:33.000 ERROR:WARNING:TSAPI:TSAPI UDL->countingRelease:free(1) failed: Timeout occured contacting license server:
13:19:54.000 ERROR:WARNING:TSAPI:TSAPI UDL->countingRelease:free(1) failed: Timeout occured contacting license server:
13:32:26.000 ERROR:CRITICAL:TSAPI:RenewTimeoutEH::handle_timeout:renewAllLicenses failed: Timeout occured contacting license server:
13:32:26.000 ERROR:WARNING:TSAPI:GenericLicense::SetMode:License mode changed to LICENSE_ERROR; cause: Timeout occured contacting license server:; grace period: 2592000 secs
13:32:26.058 ERROR:WARNING:TSAPI:GenericLicense::SetMode:License mode changed to LICENSE_NORMAL; cause: Initialize license as normal
14:18:08.000 ERROR:WARNING:TSAPI:TSAPI UDL->countingRelease:free(1) failed: Timeout occured contacting license server:
14:37:15.000 ERROR:WARNING:TSAPI:TSAPI UDL->countingRelease:free(1) failed: Timeout occured contacting license server:

When I look in the logs it references the local weblm address 127.0.0.1 -- When I go into the web interface of the AES and go into weblm, the 127.0.0.1 is set. I didn't try to log into it and am assuming the 'real' license isn't associated there.

 

[kyle555]

This is the same problem I think I'm having where you have a local WebLM with no actual license on it, but it is delegated from an Enterprise WebLM with the MAC in PLDS and all the other gobbledygook I was talking about. I'll probably know more about this very soon

 

[wpetilli]

Ok, let's keep eachother posted on this one. The AVAYA case engineer (who is the lowest of tiers, but is very responsive)worked with me on the TSAPI service crashes I was having. So we just upgraded from 6.3.0 to 6.3.1 SP1, which looks like those errors have gone away and all that is left are the ones above. I re-engaged her, sent her the logs and she stated this was a bug and was going up to development. Sounded like she was liasoning with a higher tier'd engineer that knew about this. Anyway.. I'm not sure what issues these are causing, if any. The only reason I even opened a case on this server was randomly our LYNC 2013 clients lose the rcc functionality. It goes away in seconds, but this was the first stop on the troubleshooting train.

Your explanation makes total sense regarding the WEBLM. Maybe this is very fixable after all and I don't have to revert to rebuilding the thing.

 

[wpetilli]

I was just contacted by AVAYA and they have a hotfix ready for this issue. Only they install it, not customer. I'm going to look to have it deployed in the next day or so and will let you know how it goes.

 

[kyle555]

Interesting. I'm with a BP, wonder if I would be able to do the install of that fix or if you got any name/patch number. Is it specific to your 6.3.1? Typically AES updates are Super Patches. Super Patches being the equivalent of a service pack, but 6.3.1 vs 6.3.3 seem to be different minor releases - to say its more than just running an RPM patch.

The first AES OVA I installed was 6.3.1 - and I want to do 6.3.3.

See page 13/14 here:

https://downloads.avaya.com/css/P8/documents/100180542

This is the stuff I previously said was confusing me. "Run this importCertToWebLm.zip patch if the following conditions are true" - but it would be kinda nice if they explicitly said "this has to/can't/might apply to VMWare if you did your licensing/WebLM's this/that/the other way" But AES documentation is always kind of spotty like that, I find.

 

[wpetilli]

It was told to me that it was a hotfix that was just written and has to be installed by AVAYA. Not sure if they'd release it to a BP,,,, I'm a customer. I inquired about if this was strictly for my company, which I would have had an issue with, but they say other customers on this release are having this issue. I don't believe it goes away or is wrapped into 6.3.3 either or that would have been the more logical path. I asked for a date this fix would be wrapped into a formal patch/release and they have no date.

 

[dikshv]

How to Login in to the AES vmware engine to assign a ip address ?

 

[kyle555]

Depends on what AES release you've got. The first one seems to work like a regular AES - same default passwords as you'd have used in System Platform, then you do it from a console and there's a script somewhere to set up stuff like IP, hostname,date/time,etc.

In the more recent release, when you deploy the OVA template, there are some forms to fill in prior to pushing the image, and you set your IPs in there.

If I recall correctly, cust/custpw is the webpage login you can use to get started after you set it up. That being said, learn from my fail and set up your accounts that never expire or lock right away otherwise, 90 days in you'll be scratching your head wondering why you're not getting anywhere!