SAL 3.0 Upgrade/Installation 3

[t2true]

I understand that Avaya is requiring its customers to upgrade SAL to 3.0 by the end of the year. (I just found out about it last week.)

My questions are around installation.

I am running SAL 2.5 on a business partner gateway, but want to move it to a VMWare VM. Can I have the server team build me a RHEL 6 server so I can run the installer? Or, does an ADS OVA need to be deployed first?

If the former, is this (ADS-Installer-3.0.0.0-379.tar.gz) the file I need to run on the Linux server?

If the latter, is this (AvayaDiagnosticServer-3.0.0.0-vApp-e55-09.ova) the file I need? (I understand I will need the former file at some point.)

 

[dialtonebone]

The OVA is going to provide you a self contained appliance with everything at the "right" versions per Avaya. This is more supportable in my eyes than asking for help with the software only option (you provide OS, they provide an installer). Your choice, but I'd say deploy the OVA, then of course patch/update per the book (with that other installer file).

 

[avayatech2018]

I'm in the beginning stages of moving our SAL to the VMWare model with the OVA. I'm currently waiting on my server team to provide me my VM. I will then be using the top installer file. Then applying the patch. Keep us posted on what you do.

40 years in Telecom. New to Avaya! Go easy.

 

[lundangler]

I have installed the ova and followed the post install steps in the deployment guide but can't access the Gui.Anyone else having this issue.

 

[wpetilli]

I believe I had the same issue. I was planning to re-use the SEID from the current system and it wasn't until I shut that one down and put that SEID on the new box. One of the services wouldn't start until I did that.

 

[dialtonebone]

GUI inaccessible?

SSH in first and check to make sure the port is listening... i.e., port 7443:
netstat -an | grep 7443

If you don't see anything listening on 7443 then you know that the web service is not loaded (or whatever service you are checking the port on).

I typically do these installs by making my backup, shutting down the old one, then spinning the new one up and doing my restore - never having both on at the same time. I keep the IP the same in most of these since it would require programming all the elements with the new alarming address.

 

[avayatech2018]

I was going to suggest make sure you're using the :7443 when logging in. I've been guilty of forgetting that when not using a saved bookmark. Please let us know what happens.

I have a question. We've created a new SAL on VM. It was done by a member of our server team. I disconnected the 2.5 box and assigned the IP to the new box. We kept all the same identifiers. It seems I have one issue. The new box doesn't like the connection to the Core Server. It says Connection to Primary Core Server has failed. Certificate is untrusted. Everything else appears to be happy. It's happy connecting to the Primary Remote Server.

Any thoughts? I hate the thought of paying Avaya $360 an hour for assistance.

TIA

Mark

40 years in Telecom. New to Avaya! Go easy.

 

[t2true]

I was able to upgrade my SAL to 3.0. I pretty much followed the directions in this Avaya Mentor Video.

As mentioned, I was running SAL 2.5 on a business partner (BP) gateway. My SAL 3.0 server is running on VMWare.

The virtual machine/server (VM) was built by the server team following the guidelines from Avaya.
I downloaded the SAL 3.0 OVA from here, the installer from here, and the service pack from here.

The server engineer built the new VM using the OVA from Avaya

I used the following steps to complete the upgrade*:


Login to the SAL 2.5 server. Yes, the 2.5 server. You may have to su to root.

Create a root directory for the installer

mkdir ads3​

Create a directory for the 2.5 backup

mkdir ads3/backup​

(The command pwd will display the current directory.)
Copy the 3.0 installer file (ADS-Installer-3.0.0.0-379.tar.gz) to the ads3 directory. I used WinSCP.
Extract the file:

tar -xzf ADS-Installer-3.0.0.0-379.tar.gz​

This will extract contents into a new directory of the same name - ADS-Installer-3.0.0.0-379​

CD to the new directory and look for the backup script - migration_backup.sh - and execute it using the following to include the destination folder:

./migration_backup.sh /root/ads3/backup/​

The backup will run and create a tarbol** file in the backup directory - ADS_2.5_backup.tar

**Copy the backup tarbol to the new 3.0 server's /root/ads3/backup directory
**If the new 3.0 server will retain same IP address (and it should), shut down 2.5 server


Login to new 3.0 server

Create a root directory for the installer

mkdir ads3​

Create a directory for the 2.5 backup

mkdir ads3/backup​

Copy the 3.0 installer file, and the 3.0 service pack file to /root/ads3 directory, and the 2.5 backup file to the /root/ads3/backup directory.
Extract the installer file:

tar -xzf ADS-Installer-3.0.0.0-379.tar.gz​

This will extract contents into a new directory of the same name​

Next, the unattended install properties file must be modified to fit the installation.
CD to the new directory (ADS-Installer-3.0.0.0-379) and look for the properties file and edit it:

vim ADS_Response.properties​

EDIT THE FILE with appropriate responses and save it. I won’t go into Linux vim commands here.
However, I will mention that in the properties file, the BACKUP_FILE_PATH= will need to match the backup directory and filename. (i.e. BACKUP_FILE_PATH=/ads3/backup/ADS_2.5_backup.tar)
While in that same director - ADS-Installer-3.0.0.0-379 - run the unattended install:

./install.sh -unattended​

This command will use the properties file to answer the install questions.​

After 10-15, the install will complete. It may look like it stalled/halted, but it will continue.
Once it completes, run the service pack the same way. (It, too, has an unattended install properties file that needs to be modified first):
1) Login as admin
2) Type su and then the root password
3) Type cd /ads3/ (enter)
4) Type tar –xzf ADS-ServicePack-3.0.4.0-582.tar.gz (enter)
5) Let the file unpack, it will create a new directory /installer/ADS-Installer-3.0.0.0-458
6) Type cd ADS-ServicePack-3.0.4.0-582 (enter)
7) Type vim ADS_Response.properties (enter) to edit the install file
8) Save and exit
9) Type ./install.sh –unattended (enter)
10) After it is finished installing the service pack I did a reboot at the prompt so that the machine could gracefully shut down and restart all of the services.
Verify SAL is working:

netstat -nap | grep 7443​

Or go to WebUI for SAL -

https://<sal

ip address>:7443​

*These are the steps I used. Run them at your own risk. I am not responsible if you mess it up.

 

[t2true]

One other thing I'll mention is to get the SEID and the Alarm ID from the 2.5 server before shutting it down. They will be needed in the install properties file.

 

[wpetilli]

Also, in one of the versions they reference the change in the Avaya url to access.

 

[avayatech2018]

So no one has seen this issue?

We've created a new SAL on VM. It was done by a member of our server team. I disconnected the 2.5 box and assigned the IP to the new box. We kept all the same identifiers. It seems I have one issue. The new box doesn't like the connection to the Core Server. It says Connection to Primary Core Server has failed. Certificate is untrusted. Everything else appears to be happy. It's happy connecting to the Primary Remote Server.


40 years in Telecom. New to Avaya! Go easy.

 

[t2true]

...I'm sorry, I did not get that error when I built mine.

I don't even know what it means by Core Server. Is that Communication Manager? Avaya's notification site?

 

[avayatech2018]

No it's a server at Avaya. secure.alarming.avaya.com My SAL is supposed to send a heartbeat to the Avaya Core server. I was able to find a way to test the connection from within Linux. It appears the connection is good. Just seems to come down to a certificate issue. I'm still chipping away at it. I'll update once i figure it out.

40 years in Telecom. New to Avaya! Go easy.

 

[dialtonebone]

Core server is where your alarming goes.

The error message is pretty clear - the certificate being presented is not trusted. Typically this means traffic is being intercepted as Avaya preinstalls necessary CAs with SALGW out of the box.

Do you have do SSL inspection on your network? Its sounds like the certificate is getting modified on the way in and out between the SALGW and the Avaya Core servers.

You probably will fail the Remote test too. Have you tried that yet?

 

[avayatech2018]

Randy that's just it. The Primary Remote Server connection is good. No problem with it. I do see the certs that are installed with the gateway.

40 years in Telecom. New to Avaya! Go easy.

 

[avayatech2018]

Can anyone tell me what they have as their Platform Qualifier under their Core Server in their SAL 3.0? I'm reading where the defaults are Avaya. Avaya is the Qualifier on the Primary Remote Server that test good. But I have something else listed as the Qualifier on the Core Server setting.

40 years in Telecom. New to Avaya! Go easy.

 

[dialtonebone]

Use the Avaya defaults on SALGW3.x
If you are on 2.x you probably pointed at a partner system - these don't exist in 3.x of SAL.

 

[ken07734]

I have performed a number of these from upgrade to fresh deployment.

I have skimmed it down to basic items.

export the elements form the existing SALGW. save as a .csv file.

note all the ip addresses of the old SALGW. (DNS/Gateway,Etc)

verify you have the proper specs for wehat you are deploying and whether its stand alone or upgrading 6.3.x VSP

Spin up the new VM machine with the .ova and ping/traceroute the addresses in the playbook to verify you can reach Avaya.

Upgrade the VSP Services to 4 if that is the path you have.

now, it gets a bit dicey here.

you can either wait for the SALGW to pull the updates or in my case I pull the latest patch 4 and push it on to the tmp of the SALGW. I then create a new folder/directory and under root move the file to there. then I do the unattended update but you have to make sure you edit the text file so it will run properly.

Once the SP is installed you will see the BP addition and can then set that up so you have BP access.

there are some details missing here but if you use the play book you will be just fine.

 

[t2true]

 

[bfordz]

After reading through the Playbook and reading these posts, can I assume we have to install SALGW on a "new/different" server?

I'm running my SALGW v2.5.3.0.7 on a standalone VMware machine.
The 2.5 can't be upgraded to 3.0 or 3.0 can't be installed over 2.5?

I don't have the luxury of having a 'server team' or another server to setup before retiring the 2.5 GW.

Any suggestions as to an upgrade path and/or instructions to follow?

TIA
brad