Release Note OmniPCX Enterprise

TC3104 ed.06 Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*)

This document provides the detailed process of migration from an OXE system from a previous release to R101.0 MD4
(N3.521.* or above).

Revision History
Edition 1: June 6, 2024 creation of the document
Edition 2: July 26, 2024 update of the document with serviceability improvements from version R101.0 MD1
Edition 3: October 3, 2024 update of the document for PCS migration steps
Edition 4: October 8, 2024 update of the document for password policy
Edition 5: November 18, 2024 update of the document for version R101.0 MD3
Edition 6: March 12, 2025 update of the document for version R101.0 MD4 serviceability improvements

Legal notice:
www.al-enterprise.com The Alcatel-Lucent name and logo are trademarks of Nokia used under license by ALE. To view other
trademarks used by affiliated companies of ALE Holding, visit: www.al-enterprise.com/en/legal/trademarks-copyright. All other
trademarks are the property of their respective owners. The information presented is subject to change without notice. Neither
ALE Holding nor any of its affiliates assumes any responsibility for inaccuracies contained herein.
© Copyright 2025 ALE International, ALE USA Inc. All rights reserved in all countries.
Table of contents
1 Migration Use Case .............................................................................................................................. 5
2 Overview ............................................................................................................................................ 6
3 Software evolutions ............................................................................................................................. 8

3.1 Evolutions from version R101.0 MD4 .............................................................................................. 8

3.2 Evolutions from version R101.0 MD3 .............................................................................................. 8
3.2.1 Serviceability improvement for trusted hosts declaration .......................................................... 8
3.2.2 New process installation for GAS with Rocky Linux (MD3) ......................................................... 8
3.3 Serviceability improvement from patch R101.0 MD1 ....................................................................... 9
3.3.1 Radius server constraint for SSH key distribution ..................................................................... 9
4 Restrictions ....................................................................................................................................... 10
4.1 Native encryption NOE-DTLS with Mutual authentication ............................................................... 10

5 Preparation before migration.............................................................................................................. 11

5.1 Hardware and Software compatibilities......................................................................................... 11
5.2 Remove IPTouch security encryption / migrate to Native encryption .............................................. 11
5.3 Activate SSHv2 ........................................................................................................................... 11
5.4 Update SNMP configuration to SNMPv3 with user authentication ................................................... 13
5.5 Prepare the list of trusted hosts to setup the Firewall .................................................................... 13
5.5.1 If the trusted hosts and TCP wrapper are already declared in the previous release .................. 14
5.5.2 If trusted hosts are not declared before migration.................................................................. 14
5.6 Download the software from R101.0 and preparation of OVA files ................................................. 17
5.6.1 OXE VM preparation with Template factory ............................................................................ 17
5.6.2 OMS and EEGW VM with Template factory (MD3) .................................................................. 18
5.7 Retrieve the new license for CAPEX system .................................................................................. 18
6 Migration steps from previous release R100.1 (N2) or lower ................................................................ 19

6.1 Checklist .................................................................................................................................... 19

6.2 Functional diagram of steps of migration ...................................................................................... 19
6.2.1 Installation overview of main Call Server or dedicated voicemail 4645 ..................................... 19
6.2.2 Installation overview for new External EGW with Rocky Linux ................................................. 20
6.2.3 Installation overview of standby Call Server ........................................................................... 21
6.2.4 Installation overview for new OMS with Rocky Linux .............................................................. 21
6.2.5 Installation overview from PCS ............................................................................................. 22
6.2.5.1 Overview of PCS remote installation through customer network .........................................................22
6.2.5.2 Overview of PCS new installation at local site ....................................................................................23
6.3 Migrating the local node .............................................................................................................. 24
6.3.1 Installation of main Call Server ............................................................................................. 24
6.3.1.1 Step-1: Backup the database, linux data, ACD configuration, 4645/4635 data, customization files .........24
6.3.1.2 Step-2: Install the version R101.0 with SOT or load the pre-installed Virtual Machine ...........................25
6.3.1.3 Step-3: Configure the extended password ........................................................................................27

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 2/122
 6.3.1.4 Step-4: Upload of the backup and restore from the configuration .......................................................29
6.3.1.5 Step-5: Check the migration of system data .....................................................................................41
6.3.1.6 Step-6: Load the new license file .....................................................................................................42
6.3.1.7 Step-7: Start the telephonic application ............................................................................................43
6.3.1.8 Step-8: Install and update SSH keys on External EGW .......................................................................47
6.3.2 Installation of standby Call Server ......................................................................................... 50
6.3.2.1 Step-1: Install the version N3 or load the OVA file .............................................................................50
6.3.2.2 Step-2: Configure the extended password ........................................................................................51
6.3.2.3 Step-3: Configure IP parameters for duplication ................................................................................55
6.3.2.4 Step-4: Perform the mastercopy ......................................................................................................59
6.3.2.5 Step-5: Install and update SSH keys on External EGW .......................................................................61
6.3.3 New OMS installation with Rocky Linux .................................................................................. 64
6.3.4 NGP boards (GD3/INTIP3) SSH activation with new password ................................................ 64
6.3.5 GD4/GA4 ............................................................................................................................. 64
6.4 Migrating dedicated Voicemail 4645 ............................................................................................. 65
6.4.1 Step-1: Perform the backup of the Voicemail and Data Linux .................................................. 65
6.4.2 Step-2: Install the version R101.0 with SOT or load the pre-installed Virtual Machine ............... 65
6.4.3 Step-3: Configure the extended password ............................................................................. 68
6.4.4 Step-4: Upload of the backup and restore from the configuration ........................................... 70
6.4.5 Step-5: Synchronization of SSH keys between Call Server and dedicated voicemail in R101.0 (N3)
75
6.4.6 Step-6: Check the 4645 is restarted and channel accessible with the command vmail .............. 76
6.5 Migrating PCS with remote installation or local installation ............................................................. 77
6.5.1 Local installation process ...................................................................................................... 77
6.5.1.1 Step-1: Perform the backup of the PCS Linux data ............................................................................78
6.5.1.2 Step-2: Install the version R101.0 with SOT or load the pre-installed Virtual Machine ...........................78
6.5.1.3 Step-2: Configure the extended password ........................................................................................80
6.5.1.4 Step-3: Upload of the backup and restore the Linux data ...................................................................82
6.5.1.5 Step-4: Synchronization of SSH keys between Call Server and PCS in R101.0 (N3) ...............................87
6.5.2 Remote installation process .................................................................................................. 87
6.5.3 Synchronization of SSH key between Call Server in R101.0 (N3) and PCS in previous release ... 88
6.5.4 Remote installation of PCS with SOT ..................................................................................... 89
6.5.5 Post installation synchronization from PCS ........................................................................... 101
6.6 SSH key distribution in OXE network and PCS list ....................................................................... 102
6.6.1 New SSH keys management from OXE R101.0 (N3) and time of execution ............................ 103
6.6.2 Strategies of SSH key distribution in OXE network ................................................................ 106
6.6.3 Homogeneous network of OXE nodes .................................................................................. 107
6.6.4 Heterogeneous network of OXE nodes ................................................................................ 108
6.6.5 Example of execution with heterogeneous network .............................................................. 108
6.6.5.1 SSH keys distribution from Node 1 ................................................................................................. 109
6.6.5.2 SSH keys distribution from Node 2 ................................................................................................. 115
6.6.5.3 Radius specific configuration ......................................................................................................... 116

7 Post installation ............................................................................................................................... 117

7.1 Renew the certificate of OXE Call Server to 4096 bit ................................................................... 117
7.1.1 Configure OXE FQDN in tool netadmin & activate DNS resolver from OXE .............................. 117

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 3/122
 7.1.2 Generate the new certificate based on OXE FQDN and renew CTL file ................................... 117
7.1.2.1 Local node signing the certificate or CSR ........................................................................................ 118
7.1.2.2 Remote node from OXE subnetwork signing the certificate .............................................................. 118

8 Maintenance commands with new Linux ........................................................................................... 121

8.1 Root account is not accessible directly through SFTP .................................................................. 121

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 4/122
 1 Migration Use Case
This document details the different steps to follow to migrate a network of OXE nodes into new release R101.0
(N3). It includes the latest features and serviceability improvements provided in patch N3.521.8.

The operation can be performed node per node, one after each other. The network connectivity is maintained
during the migration time.

It is recommended to migrate all nodes into the new release to benefit from a homogeneous level of services
for new features about native encryption or CCD integration with SIP SoftPhone.

However, it is still possible to maintain connectivity in network with previous release that are still supported
R12.4 (M5), R100.0 (N1) and R100.1 (N2). The new release R101.0 (N3) is retro compatible with both types
of network links: Hybrid link with VPN overflow or Direct IP link.

On each node, the migration will require reinstalling the new Linux delivery on all physical boards, Virtual
Machines or GAS servers, whatever they are used as Call Server, dedicated voicemail or PCS.

New security features are introduced in R101.0 (N3) to ensure:

1. Complex password policy
2. Secured connections
3. Basic Firewall protection
4. Passwordless authentication with independent SSH keys

In regards of the new protections provided, the process of migration has been adapted and enhanced with
new installation tools.

Warning New linux and new partitioning requires a new installation from scratch from the Call Server followed by
the restoration of the call server data. The minimum hard disk size is 80 Gb. Use SOT version R3.2.002.105
minimum.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 5/122
2 Overview
The migration process considers the different components of the OXE solution, connected devices and
applications.

For each node, you need to consider in chronological order:

1) Installation tool to upgrade before Call Server upgrade

o SOT : to upgrade into new release R3.2
o VM Flex : to upgrade into new release 3.0

2) OXE components
o Call Server Main and Standby from duplication : new installation in release R101.0 and
restore from backup files
o GAS : new installation with Rocky Linux (MD3)
o Media Gateway : GD3 / GD4 / INTIP 3 - updated automatically after upgrade of main Call
Server
o OMS : new installation with Rocky Linux (MD3)
o OST virtual machine : OST64/External EGW new installation for Rocky Linux (MD3)
o Dedicated Voicemail 4645: new installation in release R101.0 and restore from backup files
o PCS call servers : remote installation for upgrade into release R101.0

3) Connected devices
o ALE NOE devices : updated automatically after upgrade of main Call Server
o ALE SIP devices: updated automatically after upgrade of main Call Server
o ALE SoftPhone clients :
▪ ALES PC R2.5 to update via Windows deployment tools with new version
▪ ALES Android R2.5 published on Google store
▪ ALES iPhone R2.5 published on Apple store
o Attendant :
▪ NOE devices : updated automatically after upgrade of main Call Server
▪ 4059EE : to update with new version
o 3rd party devices : to update separately

4) Voice guide application

o Alcatel Audio Station (AAS) : compatible with latest version 7.2
o EVA Software : compatible with latest version 1.10
o System Voice guides : compatible with latest version 6.0

5) Connected applications to upgrade separately after Call Server upgrade

o OmniVista 8770 : to upgrade into new release R5.2
o Attendant
▪ Visual Automated Attendant : to upgrade into new release R5.2
▪ Dispatch console: to upgrade into new release R3.3

6) Connected applications compatible with OXE R101.0

o OTMS/OTMC : compatible with latest version R2.6.1 MD5
o Rainbow Web RTC Gateway : compatible with latest version R2.4.3
o OmniPCX Record: compatible with latest version R2.5

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 6/122
 o OT SBC : compatible with latest version R7.4
o OTFC : compatible with latest version R9.2
o O2G : compatible with latest version R2.7
o Contact center applications ALE
▪ ACR : compatible with latest versionR10
▪ Call routing manager: compatible with latest version R1.5
▪ Contact center agent: compatible with latest version R10
▪ Contact center barometer : compatible with latest version R10.1
▪ CC IVR: compatible with latest version R12
▪ CCS: compatible with latest version R10
▪ OTCS: compatible with latest version R8.2
▪ SoftPanel: compatible with latest version R6
▪ Ticket extractor: compatible with latest version 4.4.2
o Notification server
▪ Visual Notification Assistant : compatible with latest version R2
▪ IQ messenger : compatible with latest version R13
▪ OTNS : compatible with latest version R9
▪ ENS : compatible with latest version R9
o Selfcare : compatible with latest version R9

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 7/122
3 Software evolutions

3.1 Evolutions from version R101.0 MD4

The scripts to copy the SSH keys between nodes “oxe_nw_sync_sshkeys/oxe-ssh-auth” have been enhanced:
- It now supports the full list of special characters available in the password configuration (”&()\’<>`,)
- The execution time has also been optimized to:
o 3 min between OXE nodes running with release R101.0 (N3) and 1m30 for PCS or dedicated
voicemail
o 12 min between a node with R101.0 (N3) with an older release R100.1 (N2), R100.0 (N1) or
R12.4 (M5)

3.2 Evolutions from version R101.0 MD3

The new version R101.0 MD3, patch N3.510.7.A, deliver a list of new features. Two of them impact the migration
process:

✓ Improvement from SOT, Call Server, and GAS wizard to provide the list of trusted hosts through a text
file with import and export mechanisms.

✓ New Rocky Linux 9.4 for OMS / OST (OST-64 & EEGW) / GAS

For full details, check the latest edition of the Release Note of OmniPCX Enterprise R101.0
TC3103 New features from OXE R101.0

3.2.1 Serviceability improvement for trusted hosts declaration

From version of SOT R3.2.002.105, a new entry is available in the project to load the list of Trusted hosts of
the OXE firewall. It is compatible with all types of servers: GAS, physical boards or virtual machines.

In addition, the list of trusted hosts is now copied automatically from Call Server to PCS during the pcscopy.

It is also possible to perform an export from the current list of rules from the Call Server to import it on
another system.

For full details, check the latest edition of the Release Note of SOT R3.2
TC2456 Software Orchestration Tool R3.2

3.2.2 New process installation for GAS with Rocky Linux (MD3)
From R101.0 MD3, the new operating System Rocky Linux is provided for GAS server. As a result, a new
installation from the GAS server is required.

Full details of the installation process are provided in the document

TC3138 GAS installation on Rocky Linux.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 8/122
Installation overview

3.3 Serviceability improvement from patch R101.0 MD1

3.3.1 Radius server constraint for SSH key distribution
New version R101.0 is compatible with Radius account authentication. For security enforcement, new SSH keys
will be generated for the local system accounts mtcl & swinst.

Script available for SSH key distribution is compatible only with the local system accounts, therefore it will be
necessary to disable temporarily the Radius authentication for the duplicated system but also for other nodes in
the network.

Once the distribution of SSH keys is completed the Radius account authentication can be restored.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 9/122
 4 Restrictions

4.1 Native encryption NOE-DTLS with Mutual authentication

New release OXE R101.0 (N3) provides the support of the latest OpenSSL version 3.0 that implies an increase
of the security level. Certificate request from Call Server will now requires a minimum size of certificate with
2048 bits keys. Such request is addressed currently by the Call Server for the feature of Native encryption in
case of activation of the Mutual authentication for NOE device, which includes the DeskPhone in NOE mode,
8378 DECT IP-xBS base station and 8328 SIP-DECT single base station.

The current certificates provided from factory to secure DeskPhone and DECT base station with Native encryption
support 1024 bits keys. As a result, after migration into R101.0 (N3), the mutual authentication can’t be
established.

1. Disable temporarily the parameter Enable Mutual TLS Authentication from the menu System/Other
System Param./Native Encryption Parameters.

2. For Media Gateway GD3/GD4/INTIP3/OMS, if required, create and load new certificates with 4096 bits
keys.

3. For base station IP-xBS, create and load new certificates with 4096 bits keys.

4. For Deskphone, the new ranges of ALE Deskphone Essential and Enterprise can support new certificate
of 4096 bits keys using the SCEP protocol or HTTP transfer.

5. Re-activate the parameter Enable Mutual TLS Authentication from the menu System/Other System
Param./Native Encryption Parameters.

New DeskPhone ranges from factory will also provide a new factory certificate of 4096 bits.

Note SoftPhone application IP-DSP is not compliant with Mutual Authentication for NOE-DTLS

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 10/122
 5 Preparation before migration

5.1 Hardware and Software compatibilities

1. Ensure the CS model is compatible with R101.0 (N3)
o Board supported
▪ CS3 board only for common Hardware
▪ CPU8 board only for crystal Hardware
o Virtual Machine for virtualized environment
▪ Update VMware ecosystem to version 7.* or 8.0
▪ Update Hyper-V ecosystem to version Hyper-V 2019 or 2022
o Hard disk size must be at minimum of 80Gb.
o RAM size must be at minimum 1Go

2. Update Installation software SOT into R3.2. Use SOT version 3.2.002.006 minimum.

5.2 Remove IPTouch security encryption / migrate to Native encryption

Process of removal from IPTouch security encryption is detailed in the document 8AL91012ENBB - OXE
System: Security in section 6.7 Migration from IP Touch Security to FSNE

Note For full support of encryption:

1. Boards GD/GA/MEX, GD2/GA2/MEX2 must be replaced by GD4/GA4/EvolMEX , INTIP/INTIP2 by INTIP3
2. Phone range IPTouch, NOE3G don’t support native encryption and can be replaced by NOE3GEE or ALE
DesksPhones Essential or Enterprise

5.3 Activate SSHv2

It is recommended to activate the SSHv2 on the previous release especially if you have several OXE nodes in
network.

The activation must be performed on each CS duplication and PCS from the node with the basic key OXE
hostkeys

1. Log into root, and type command netadmin –m

2. Enter menu 11. 'Security' / 7. 'SSH configuration' / 2. 'Enable SSH'
3. Select SSHv2 then OXE hostkeys

In case of OXE network, it is recommended to perform the modification asap on all the nodes, otherwise the
audit/broadcast services will be temporarily blocked.

For details check document 8AL91012ENBB - OXE System: Security in section 3.3.3.2 Enabling SSHv2 with
OXE host keys

Update the rest of ALE ecosystem that establish SSH connectivity too:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 11/122
 4. In 8770, open Configuration application, select OXE systems, select tab connectivity and check the
parameter SSH connection:

5. In 8770, open OT Configuration application, select Network/OXE CS and check the parameter Secure
transfer:

6. Secured mode activation on O2G

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 12/122
The access mode (secured SSH - or not) from O2G to OXE is defined during OXE creation. This can be
modified as well later during O2G configuration tool “roxe_config.sh”.This can be modified afterward
running the same command as following:

• Logon to O2G server and run the command:

roxe_config.sh
• Choose menu 3 -- system configuration/rehosting / 3 -- oxe(s) configuration
• Select the concerned OXE
• Then “5 -- change for ssh activated mode” followed by the ssh user login & password (mtcl / xxxx)

7. Emergency Notification Server

5.4 Update SNMP configuration to SNMPv3 with user authentication

If SNMP V1/V2 is activated, it is recommended to move to SNMPv3 with user authentication.

Refer to Doc 8AL91011ENBB - OXE System: Maintenance in section 8.2.2 Declaring SNMPv3 users (if SNMPv3
is available)

5.5 Prepare the list of trusted hosts to setup the Firewall

The new release is now relying on the IP-Tables mechanism to authorize access to the Call Server. It is thus
mandatory to provide the list of trusted hosts to the system to build the firewall rules.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 13/122
It concerns only the incoming connections received by the server, not the outgoing connections that are
allowed by default. Therefore, it is not required to configure any rule for the Cloud services (CCO, Rainbow,
POD, Recorder)

There are 2 strategies possible to setup the firewall in R101.0 according to the activation of the TCP wrapper
in netadmin 'Isolate Ethernet interface and TCP accesses'.

5.5.1 If the trusted hosts and TCP wrapper are already declared in the previous release
1. List of trusted hosts has already been provided through netadmin tool in the previous release and will
be part of the backup of the Linux data.
2. During restoration of the Linux data, the trusted hosts will be restored in netadmin and will be
automatically adapted to the IP tables configuration.
3. After the restore operation, the rules associated to Cloud Service (Rainbow, Cloud Connect, etc … ) will
be no longer required and have to be removed.

Cloud service OXE agent FQDN

CCO ccagent connect2.opentouch.com
CCO SWU ccagent cdn-oxe-sw-update.al-enterprise.com
Rainbow rainbowagent agent.openrainbow.com
LMS lmsagent oxe.lms.opentouch.com
LMS Amigo lmsagent opr.lmsopr.opentouch.com

For details check document 8AL91012ENBB - OXE System: Security in section 3.2.2.2 Declaration with
netadmin.

5.5.2 If trusted hosts are not declared before migration

From release R101.0, several improvements in netadmin are delivered to simplify the declaration of trusted
hosts:

1. A file CSV can be created to list all the rules to declare in the firewall:
a. Each entry can be either a host or a range of IP addresses, up to 250 rules per system
b. There is no more type of host to declare. Different type of IP equipment can be declared in the
same subnet: Call Server, IP Phones, Media Gateway, Servers, …
c. Outgoing connections are authorized by default, thus Cloud Services don’t need to be declared.
and corresponding response will be authorized by default in the in

2. Import of the CSV file can be managed through:

a. SOT project during installation of the new version OXE R101.0 (for new installation)
b. netadmin with new entry bulk import (after a restore of database)
c. CSV file can be automatically imported at next restart of the system, if the trusted hosts file is
named import_th.csv and copied into directory /usr4/ftp (MD3). (for OVA installation)

It is necessary to collect the list of trusted hosts and trusted ranges before the migration to identify on the
system the established connections to other IP equipment.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 14/122
For the initial input, you can retrieve the list of established connection on the server using the command
netstat -a.

Collect the IP addresses or ranges using the following commands:

• Enter command netadmin -m to collect

o DNS server 1 : IP address
o DNS server 2 : IP address
o HTTP Proxy : IP address and FQDN if available
o Syslog server : IP address and FQDN if available
o SMTP server : IP address and FQDN if available
• Enter tool swinst to check
o NTP server 1 : IP address
o NTP server 2 : IP address
o Radius server : IP address and FQDN if available
o LDAP server : IP address and FQDN if available
• Enter tool mgr to check
o Voicemail 4645 : IP address and FQDN if available
o IP Recorder : IP address and FQDN if available
o SNMP server : IP address and FQDN if available
• Recover the addresses from maintenance server
o PC-admin : IP address
o 8770 server : IP address and FQDN
o SOT : IP address
• Recover the addresses from Remote worker available un
o Reverse Proxy private : IP address
o SBC private : IP address
o VPN gateway private : IP address
• Enter command compvisu ip add to check
o GD : IP address(es)
o INTIP : IP address(es)
o OMS : IP address(es)
• Enter command dectview xbs to check
o IP DECT Base station : IP address(es)
• Enter command ipcheck -g all to check SIP Servers
o Public SIP trunk or SBC : IP address and FQDN if available
o WRG : IP address
o VAA : IP address and FQDN if available
o DC : IP address and FQDN if available
o O2G : IP address and FQDN if available
o OTFC : IP address and FQDN if available
o OTMS / OTMC : IP address and FQDN if available
o Teams : IP address and FQDN if available
o VideoBridge : IP address and FQDN if available
• Identify the Notification server
o VNA : IP address and FQDN if available
o ENS : IP address and FQDN if available
o OTNS : IP address and FQDN if available
o IQ messenger : IP address and FQDN if available

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 15/122
 • Identify the Contact Center servers
o ACR : IP address and FQDN if available
o Call routing manager: IP address and FQDN if available
o Contact center agent: IP address and FQDN if available
o Contact center barometer : IP address and FQDN if available
o CC IVR: IP address and FQDN if available
o CCS: IP address and FQDN if available
o OTCS: IP address and FQDN if available
o SoftPanel: IP address and FQDN if available
• Identify the Ticket extractor: IP address and FQDN if available
• Enter Hybvisu all to recover Remote OXE IP address(es)

For TRUSTED RANGES also identify the IP addresses from

• Local OXE network
• Remote OXE networks
• X25 network for audit and broadcast
• VLAN of VPN IP range for PC Admin or ALES
• VLAN of Wired IP ranges for PC Admin or ALES / DeskPhones
• VLAN of Wifi IP ranges for PC Admin or ALES
• Enter domstat option 11 to recover the remote subnet sites with PCS/MG/IPPhones

Based on the information collected, create a the list of rules for TRUSTED_HOST or TRUSTED_RANGES into
the file import_th.csv :

################### TRUSTED HOSTS ###################

TRUSTED_HOST,dns,192.170.0.1
TRUSTED_HOST,PCadmin, 192.169.35.45
TRUSTED_HOST,server8770.company.com,192.169.5.1

################### TRUSTED RANGES ###################

TRUSTED_RANGE,192.168.0.0,192.168.0.255
TRUSTED_RANGE, 192.168.1.0,192.168.1.255

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 16/122
 5.6 Download the software from R101.0 and preparation of OVA files
The software delivery from the OXE R101.0 (N3) is available on MyPortal:

Collect the new version of SOT R3.2:

Note The new version of SOT provides an evolution to ease the deployment of the Template factory mode on
PC. Check TC3094 for further details.

Template factory mode can be used to create the Virtual Machine for VMware or Nutanix (KVM format).

5.6.1 OXE VM preparation with Template factory

1. Collect the OXE software:
- OXE patch : N3.5xx.x
- For GAS : GAS version 12.x and Boot DVD Rocky 9.4.7 minimum

2. Create the OVA file for VMware or Nutanix (KVM) using documentation:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 17/122
 8AL90559USAF - Software Orchestration Tool Manual > 5.1.3 Creating a project to generate template
of virtual machine (easy/expert mode)

5.6.2 OMS and EEGW VM with Template factory (MD3)

A new installation of the virtual machines OMS and EEGW with Rocky linux from R101.0 MD3.

1. Collect OMS and OST softwares:

- OMS version : 14.05 minimum
- EEGW version : 9.03 minimum
- BOOT DVD Rocky version : 9.4.7 minimum

2. Create the OVA files for VMware / Nutanix / Standard Linux and KVM using documentation:
8AL90559USAF - Software Orchestration Tool Manual > 5.1.3 Creating a project to generate template
of virtual machine (easy/expert mode)

5.7 Retrieve the new license for CAPEX system

For Capex system managed with ACTIS a new licence file *.swk must be provided after the upgrade with the
lock 165 Release OXE set to 52:

It can be retrieved from eBuy web site, or retrieved from Fleet Dashboard via the service
- Get from ALE : to download the zip file including file *.swk and sw8770.
- Push : to upload the license (requires to start the telephonic application first )

For details consult, OXE system documentation:

8AL91047ENAC - OXE System: Initial Configuration > 3.2. License management in CAPEX mode

If you move to POD licence, install the new file .swk retrieved from the service manager for the OXE asset.
Then reboot the system.

For details consult, OXE system documentation:

8AL91047ENAC - OXE System: Initial Configuration > 3.1. License management in OPEX mode (Purple on
demand)

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 18/122
6 Migration steps from previous release R100.1 (N2) or lower

6.1 Checklist
Check the availability of:
- The new licenses *.swk, *.sw8770 and zip file for R101.0
- The new software for OXE and SOT, or corresponding OVA/QCOW2 files
- The new software for OMS or OST, or corresponding OVA/QCOW2 files
- The file import_th.csv for the configuration of the firewall

Perform an Infocollect to logs the status of the system before the migration and compare the logs after
migration.

6.2 Functional diagram of steps of migration

This section details an overview of each step of migration for the different target of deployment:
- Physical boards: CS-3 or CPU8
- Virtual Machines: VMware / Hyper-V / Generic Linux with KVM / Nutanix

6.2.1 Installation overview of main Call Server or dedicated voicemail 4645

Two types of installation are possible according to the target:

➢ New Installation from Scratch with SOT 3.2.002.105

o CS-3
o CPU-8
o Hyper-V
o GAS through previous process

➢ Import of OVA from Template factory mode of SOT

o VMware 7.0 / 8.0
o Nutanix AHV 20220304
o Standard Linux & KVM ( kernel ≥ 4.12.14 & KVM ≥ 5.2 )

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 19/122
6.2.2 Installation overview for new External EGW with Rocky Linux
From R101.0 MD3, a new installation of the External EGW with Rocky Linux is mandatory to replace the
existing VM with Suse.

During the migration, there is no issue to keep the existing VM with Suse but it will not be updated to the
latest binary to support the new features.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 20/122
6.2.3 Installation overview of standby Call Server
Installation and initial configuration is similar to the main Call Server. Database and firewall rules are retrieved
through the mastercopy mechanism.

6.2.4 Installation overview for new OMS with Rocky Linux

From R101.0 MD3, a new installation of the OMS with Rocky Linux is mandatory to replace the existing VM
with Suse.

During the migration, there is no issue to keep the existing VM with Suse but it will not be updated to the
latest binary to support the new features.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 21/122
6.2.5 Installation overview from PCS
There are two types of installations possible for PCS according to the hardware compatibility and size of the
hard disk:

➢ Remote installation via SSHv2 through customer network

o CS3 with 80Gb Hard disk
o Virtual machine with 80Gb hard disk
o Minimum version R100.0 on PCS

➢ New installation from PCS at local site with console port

o Installation from scratch with SOT
▪ CS or CS-2 replaced by new board CS-3
▪ CS-3 with version R12.4 or lower
▪ Virtual machine Hyper-V with 60 Gb hard disk or version R12.4 or lower
▪ GAS server with Rocky Linux
o Import OVA from template factory
▪ For VMware/Nutanix/Linux-KVM
▪ Virtual machine running with version R12.4 or lower
▪ Virtual machine with 60 Gb hard disk

6.2.5.1 Overview of PCS remote installation through customer network

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 22/122
6.2.5.2 Overview of PCS new installation at local site

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 23/122
 6.3 Migrating the local node
6.3.1 Installation of main Call Server
Following steps must be followed to migrate a single node or the first node of the network from R100.1 (N2)
or lower.

It can be configured with Twin CPU, PCS or 4645 embedded or dedicated.

Warning If the 4645 is embedded on one of the Call Server, it is recommended to use first that host with voicemail
to retrieve 4645 data.

6.3.1.1 Step-1: Backup the database, linux data, ACD configuration, 4645/4635 data,
customization files
Perform a full backup of data configured on the system through swinst→ 2. Expert Menu

Check that each of the backup is completed successfully:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 24/122
Copy the backup files on the PC admin or external location.

For details consult, OXE system documentation:

8AL91011ENBC- OXE System: Maintenance > 6.2.4. Backup and restore operations

6.3.1.2 Step-2: Install the version R101.0 with SOT or load the pre-installed Virtual Machine
Install new version R101.0-N3 through SOT on twin Call Serer or create a new virtual machine from OVA
(VMware) or QCOW2 (Linux) file delivered with template factory.

SOT deployment project for: CS3 / CPU8 / GAS / Hyper-V

Reminder: the size of the hard disk must be at least 80 Gb. Use SOT version 3.2.002.105
minimum.

Install software SOT R3.2, then create/update an OXE project where you declare main and standby Call Server
and PCS IP addresses. Provide the CSV file that list the rules for firewall.

For details consult, OXE system documentation:

8AL91032ENBC - OXE System: Installation Manual > 8 Communication server installation on a physical
machine
8AL91032ENBC - OXE System: Installation Manual > 9 Communication server installation on a virtual machine

1. In case of duplicated system, you can keep the main Call Server running with the previous release while
you are re-installing the release on the twin call server.
2. Once the twin Call Server configuration is ready with the database and new license, stop the telephone
on main Call Server and start the telephone on twin Call server to minimize the down time.

OVA import for: VMware / Nutanix / Linux + KVM

Reminder: the size of the hard disk must be at least 80 Gb.

Create a new Virtual Machine by importing on the *.ova or *.vmdk file.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 25/122
Note 1 It’s better to correct the system time in BIOS before installation, because change the system time after
call server installed, it will cause all system password invalid

Note 2 Update the Boot Options at creation of a new Virtual Machines to change to BIOS firmware

Once installation is completed, the system will start the console interface on the menu for keyboard selection.

Note Several minutes after the initialization, some system message can overwrite the display of the keyboard
configuration. Restart the CS to display the menu properly.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 26/122
 6.3.1.3 Step-3: Configure the extended password

1. At first connection, initialization script requires to confirm or modify the keyboard configuration:

Note If you don’t connect immediately after initialization, system messages may be displayed over the keyboard
dialog box. If the menu is not correctly visible, restart the system to recover the original display.

2. Test of the keyboard configuration is proposed to check the keyboard selection and give the possibility
to modify the setup:

Then the admin is prompted to configure the system password for mtcl/swinst/root/adfexc and select
the activation of password Ageing if required.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 27/122
 3. Enter the password for each account and confirm if you want to activate the Password aging:

In our example we use for mtcl : Superuser01*mt swinst : Superuser01*sw, root : Superuser01*ro

Warning Support of the full list of special characters in passwords has been delivered from patch N3 MD4 for the
scripts of SSH key distribution.
In version N3 MD1 and MD2, the list of special characters ”&()\’<>`, in passwords were not supported.
In version N3 MD3, the special characters , (comma) ’ (single quote) in passwords were not supported.
As a result, the distribution of the SSH public key to network nodes or PCS fails.

Note If Password ageing is activated: after password expiry, a 30 days grace period is offered to renew the
password, then the system blocks the access to the account.

In case of mismatch of the rules, unmatching rule is indicated

4. At the end of operation validate the modifications of the password or restart the script of customization.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 28/122
 6.3.1.4 Step-4: Upload of the backup and restore from the configuration
2. Connect to mtcl login and check the system date and time

If the date is not correct, launch the tool swinst to update the date and time in menu:
2 Expert menu / 6 System Management / 1 Date & time update

OVA installation from Template Factory for: VMware / Nutanix / Linux KVM

Note If martian packets are displayed on the console and disturb the configuration of the system:

You can either:

- disable the network interface from the Virtual Machine momentarily to perform the complete the
netadmin then perform SSH connection.
- disable the display of the martian packets momentarily through netadmin -m menu : 11. 'Security'
/ 11. 'Logging Martian packet'

WARNING : Logging martian packet is necessary for security purpose.

Martian packet logging is activated,

Do you want to deactivate it? (y/n default is 'n') ?y

a. For OVA: perform the command netadmin to configure the IP configuration

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 29/122
 Configure only the local IP address and keep other default values:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 30/122
 The router:

Then activate the SSH for All in the Firewall(iptables) configuration 2. 'Allow/Deny SSH for all'

Then type y to activate:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 31/122
 Type 0 to finalize netadmin:

It is possible that some message linked to Martian packets are displayed due to the missing
entries in the firewall:

SOT deployment project for: CS3 / CPU8 / GAS / Hyper-V

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 32/122
 IP configuration has been provided in the SOT project and provided to OXE to configure the IP
addresses from netadmin with duplication of Call Server.

Rules for firewall have also been provided and imported on the system to authorize SFTP to transfer
the backup files and remote access to the system with SSH.

3. In your application of file transfer, update the SFTP configuration with the new mtcl password. New SSH
key will be prompted.

4. Connect with SFTP client on main Call server and copy :

a. BACKUP files in /usr4/BACKUP/IMMED for database / linux data / voicemail / ACD

configuration / Custom files

b. new license *.swk in /usr4/BACKUP/OPS for CAPEX mode

c. file import_th.csv in /usr4/ftp

5. Connect to SSH from the PC Admin

From swinst tool, restore all backups:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 33/122
OmniPCX Enterprise - Release 101.0 MD1 and above
Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 34/122
OmniPCX Enterprise - Release 101.0 MD1 and above
Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 35/122
OmniPCX Enterprise - Release 101.0 MD1 and above
Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 36/122
Note • Old user passwords from previous database release (R12.x/R100.x) are not restored
• New SSH key is generated for the Call Server
• As standby Call Server is not started the copy to twin is not completed
• Radius server is not activated by default after restoration. See next section for activation
• If the certificate size is not set to 4096 bits, a warning will be displayed. Previous value of 2046
bits is still supported.
• If Trusted hosts were configured, they will be restored and migrated automatically into rules for IP
Tables

After the restoration of Linux data, the new setting ‘SSH for all’ will be disabled.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 37/122
 If the trusted hosts were declared the list of trusted hosts is restored from the back file, you can skip to step 5.
However, some entries must be removed if you declared previously the FQDN the cloud services as trusted
domain in the trusted hosts:

Cloud service OXE agent FQDN

CCO ccagent connect2.opentouch.com
CCO SWU ccagent cdn-oxe-sw-update.al-enterprise.com
Rainbow rainbowagent agent.openrainbow.com
LMS lmsagent oxe.lms.opentouch.com
LMS Amigo lmsagent opr.lmsopr.opentouch.com

Those entries are not requested anymore as the firewall doesn’t filter outgoing connections from OXE, it is only
applied on incoming connections.

Note After you restore the Linux data, system messages are reported on the screen, restart the Call Server to
remove the display of messages below:

6. Connect to root login and enter tool netadmin -m to configure the firewall 11. 'Security' / 1.
'Firewall(iptables) Configuration' / 3. 'Restricted Access Configuration' / 7. Bulk import:

Use entry 1. 'View trusted hosts' to check the list of rules uploaded :

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 38/122
OmniPCX Enterprise - Release 101.0 MD1 and above
Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 39/122
Warning After import of the trusted hosts, you need to apply the modification to update the IPTables. Type key a
then Enter to force the loading

Come back to previous menu 'Firewall(iptables) Configuration'

Select entry 1. ‘View’ to check the rules declared

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 40/122
 If the SSH connection is closed, connect on the console port to perform the bulk import from netadmin -m in
root login.

Note IP forwarding is activated by default in older release then R101.0. It is useful to keep this feature activated
for the configuration using internal DHCP server. If the DHCP Server is not used, it is recommended to
disable IP forwarding from netadmin 11. 'Security' / 10. 'IP forwarding'

6.3.1.5 Step-5: Check the migration of system data

1. From root login, check in netadmin -m, the restoration of the settings in menu:
o 2. 'Show current configuration'
o 14. 'DNS configuration' (if configured)
o 15. 'Proxy configuration' (if configured)
o 17. 'Node configuration'
o 19. 'Domain Management'
o 20. 'Encryption GW Management' (if configured)

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 41/122
 2. In tool swinst:
o Enter menu 2 Expert menu / 6 System management / 1 Date & time update
▪ Check Timezone and date displayed
o Enter sub-menu 3 NTP server management
▪ Check NTP status and list of Server on the top
o Go to menu 2 Expert menu /6 System management / 5 User's accounts management
▪ If RADIUS or LDAP server is configured check
• submenu 5 Configure LDAP authentication / 1 View configured LDAP server
• submenu 4 Configure RADIUS authentication / 1 View configured RADIUS
servers
▪ If Password Aging is activated check status
• submenu 2 Change account aging password
• Press key Enter to exit menu without modification

6.3.1.6 Step-6: Load the new license file

For Capex system managed with ACTIS a new licence file *.swk must be provided after the upgrade with the
lock 165 Release OXE set to 53. It can be retrieved from Ebuy web site, or retrieved from Fleet Dashboard via
the service
- Get from ALE : to download the zip file including file *.swk and sw8770.
- Push : to upload the license (requires to start the telephonic application first )

For details consult, OXE system documentation:

8AL91047ENAC - OXE System: Initial Configuration > 3.2. License management in CAPEX mode

If you move to POD licence, install the new file .swk retrieved from the service manager for the OXE asset.
Then reboot the system.

For details consult, OXE system documentation:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 42/122
 8AL91047ENAC - OXE System: Initial Configuration > 3.1. License management in OPEX mode (Purple on
demand)

If the system was connected to a Flex LM or Cloud Connect before the upgrade, the configuration will be
restored from the database backup.

1. In tool swinst, enter menu 2 Expert menu / 5 OPS configuration / 2 Restore OPS from cpu
disk

Warning If the telephonic application was already started with the license from previous release, the system start
in Panic mode. After loading the new license in swinst perform a restart of the main Call Server.

6.3.1.7 Step-7: Start the telephonic application

At the end of the operation start the Call Handling:

1. Connect to the console port, to check the system init

o CTL file update in directory /usr3/mao/DM/VHE8082
o SIP configuration files in directory /usr3/mao/DM/dmictouch

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 43/122
Note You can retrieve the file after the startup into /tmpd/RUNTEL.log

2. System checklist

Perform an Infocollect to logs the status of the system after the migration and compare the logs before
migration.

o Check in incvisu config all

▪ Call Server take over the main role
▪ the restart of the network links
▪ the restart of the boards
▪ the restart of Cloud services: Rainbow, CCO, POD, PM agent
▪ the restore of the SIP trunk and application in incvisu
o Check in config all, the restart of
▪ The EEGW in rack 0

▪ The OMS/GDx in next rack

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 44/122
 ▪ The 4645 in rack 18

o Check in tftp_check -c, the number of phones reconnected

o Check the status of the voicemail with command vmail:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 45/122
 o Cryptview

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 46/122
6.3.1.8 Step-8: Install and update SSH keys on External EGW

If the system is configured with Native Encryption and External Encryption Gateway (EEGW), it is necessary to
perform a new installation with Rocky Linux and update of SSH keys between EEGW and Call Server

1. Connect to the EEGW associated to the Call Server using the root account (default password is
letacla1). Update the password on first connection.

2. Launch the maintenance command ostconfig and declare the IP configuration, then select the entry
11. Download Certificates

Answer y to regenerate the EEGW SSH key and force the update of the Public key to Call Server :

Answer yes to update the new public key from Call Server into the known_hosts file from the EEGW, then enter
the swinst password from the Call Server to transfer the certificates files:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 47/122
 3. Enter menu 12. Check Certificates to confirm the synchronization of OXE

Answer n to keep the existing SSH key from EEGW that was renew at previous step.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 48/122
 4. Exit and reboot the EEGW to perform the upgrade of its binary.

5. After reboot, you can check the EEGW is back IN SERVICE with the command config 0.

6. Connect to EEGW with root login, and check in menu ostconfig that the binary version has upgraded
into version 9.05 minimum

For details consult, OXE system documentation:

8AL91032ENBC - OXE System: Installation Manual > 11.2. OST server installation (for OST64 or EEGW)

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 49/122
 6.3.2 Installation of standby Call Server

6.3.2.1 Step-1: Install the version N3 or load the OVA file

Install new version R101.0-N3 through SOT on twin Call Serer or create a new virtual machine from OVA file.

SOT deployment project for: CS3 / CPU8 / GAS / Hyper-V

Reminder: the size of the hard disk must be at least 80 Gb. Use SOT version 3.2.002.105
minimum.

Install software SOT R3.2, then create/update an OXE project where you declare main and standby Call Server
and PCS IP addresses. Provide the CSV file that list the rules for firewall.

For details consult, OXE system documentation:

8AL91032ENBC - OXE System: Installation Manual > 8 Communication server installation on a physical
machine
8AL91032ENBC - OXE System: Installation Manual > 9 Communication server installation on a virtual machine

1. In case of duplicated system, you can keep the main Call Server running with the previous release while
you are re-installing the release on the twin call server.
2. Once the twin Call Server configuration is ready with the database and new license, stop the telephone
on main Call Server and start the telephone on twin Call server to minimize the down time.

OVA installation for: VMware /Nutanix / Linux + KVM

Reminder: the size of the hard disk must be at least 80 Gb.

Create a new Virtual Machine by importing on the *.ova or *.vmdk file.

Note 1 It’s better to correct the system time in BIOS before installation, because change the system time after
call server installed, it will cause all system password invalid

Note 2 Update the Boot Options at creation of a new Virtual Machines to change to BIOS firmware

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 50/122
 Once installation is completed, the system will start the console interface on the menu for keyboard selection.

Note Several minutes after the initialization, some system message can overwrite the display of the keyboard
configuration. Restart the CS to display the menu properly.

6.3.2.2 Step-2: Configure the extended password

At first connection, initialization script requires to confirm or modify the keyboard configuration:

Note If you don’t connect immediately after initialization, system messages may be displayed over the keyboard
dialog box. If the menu is not correctly visible, restart the system to recover the original display.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 51/122
OmniPCX Enterprise - Release 101.0 MD1 and above
Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 52/122
 Then the admin is prompted to configure the system password for mtcl/swinst/root/adfexc and select
the activation of password Ageing if required.

In our example we use for mtcl : Superuser01*mt swinst : Superuser01*sw, root : Superuser01*ro

Warning Support of the full list of special characters in passwords has been delivered from patch N3 MD4 for the
scripts of SSH key distribution.
In version N3 MD1 and MD2, the list of special characters ”&()\’<>`, in passwords were not supported.
In version N3 MD3, the special characters , (comma) ’ (single quote) in passwords were not supported.
As a result, the distribution of the SSH public key to network nodes or PCS fails.

Enter the password for each account and confirm if you want to activate the Password aging:

Note if Password ageing is installed: after password expiry, a 30 days grace period is offered to renew the
password, then the system blocks the access to the account

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 53/122
 At the end of operation validate the modifications of the password or restart the script of
customization.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 54/122
 6.3.2.3 Step-3: Configure IP parameters for duplication
1. Connect to mtcl login and check the system date and time

If the date is not correct, connect in swinst to update the date and time in menu:
2 Expert menu / 6 System management / 1 Date & time update

OVA installation for VMware environment

Note If martian packets are displayed on the console and disturb the configuration of the system:

You can either:

- disable the network interface from the Virtual Machine momentarily to perform the complete the
netadmin then perform SSH connection.
- disable the display of the martian packets momentarily through netadmin -m menu : 11. 'Security'
/ 11. 'Logging Martian packet'

WARNING : Logging martian packet is necessary for security purpose.

Martian packet logging is activated,

Do you want to deactivate it? (y/n default is 'n') ?y

a. For OVA : perform the command netadmin to configure the IP parameters for both Call
Servers in duplication :

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 55/122
 Configure only the local IP address and keep other default values:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 56/122
 The router:

Then activate the SSH for All in the Firewall(iptables) configuration 2. 'Allow/Deny SSH for all',
and type y to activate:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 57/122
 Type 0 to finalize netadmin:

It is possible that some message linked to Martian packets are displayed due to the missing
entries in the firewall:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 58/122
 SOT deployment project for: CS3 / CPU8 / GAS / Hyper-V

IP configuration has been provided in the SOT project and provided to OXE to configure the IP
addresses from netadmin with duplication of Call Server.

Rules for firewall have also been provided and imported on the system to authorize SFTP to transfer
the backup files and remote access to the system with SSH.

2. Connect to SSH from the PC Admin

6.3.2.4 Step-4: Perform the mastercopy

1. From standby Call Server, run the script oxe-ssh-auth -c twincpu_eth to update the authorized key
for mtcl & swinst account :

In root login execute commands:

[root@csa]# oxe-ssh-auth -c twincpu_eth

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 59/122
 2. Telephonic application is not started on standby Call Server.
Launch the command mastercopy twincpu_eth to start the update of data from main to standby.

3. Select the data to duplicate including DATABASE AND ACCOUNTING and LINUX DATA, then START
TELEPHONIC APPLICATION at the end

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 60/122
6.3.2.5 Step-5: Install and update SSH keys on External EGW

If the system is configured with Native Encryption and External Encryption Gateway (EEGW), it is necessary to
perform a new installation with Rocky Linux and update of SSH keys between EEGW and Call Server

1. Connect to the EEGW associated to the Call Server using the root account (default password is
letacla1). Update the password on first connection.

2. Launch the maintenance command ostconfig and declare the IP configuration, then select the entry
11. Download Certificates

Answer y to regenerate the EEGW SSH key and force the update of the Public key to Call Server :

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 61/122
Answer yes to update the new public key from Call Server into the known_hosts file from the EEGW, then enter
the swinst password from the Call Server to transfer the certificates files:

3. Enter menu 12. Check Certificates to confirm the synchronization of OXE

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 62/122
 Answer n to keep the existing SSH key from EEGW that was renew at previous step.

4. Exit and reboot the EEGW to perform the upgrade of its binary.

5. After reboot, you can check the EEGW is back IN SERVICE with the command config 0.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 63/122
 6. Connect to EEGW with root login and check in menu ostconfig that the binary version has upgraded
into version 9.05 minimum.

For details consult, OXE system documentation:

8AL91032ENBC - OXE System: Installation Manual > 11.2. OST server installation (for OST64 or EEGW)

6.3.3 New OMS installation with Rocky Linux

It requires to use SOT version R3.2.002.105 minimum, and OMS software 14.04 minimum.

The new VM can be installed from SOT with standard installation with network boot or prepared with Template
Factory mode.

Once the new VM is installed, connect in admin, then root login and execute omsconfig to restore the IP
parameters.

On main Call Server, update the new MAC address in OXE database in Shelf/Board/Ethernet parameters.

For details consult, OXE system documentation:

8AL91032ENBC - OXE System: Installation Manual > 11.1. OXE Media Services installation

6.3.4 NGP boards (GD3/INTIP3) SSH activation with new password

After upgrade of the Call Server into N3, the new binary 14.x for NGP boards (GD3/INTIP3) will be automatically
upgraded by the boards.

Following this upgrade, SSH connectivity will replace the telnet protocol, and a new set of passwords will be
applied:
✓ Admin: letacla1
✓ Root: ngp.ale

6.3.5 GD4/GA4

Warning mg4_2.03 or higher will be upgraded only from firmware mg4_1.19. If your OXE has a version < N1.291.66
(N1 MD4) you must first migrate to N1 version N1.291.66 (N1 MD4) or install temporarily the firmware 1.19
before installing the new N2 version

The firmware 1.19 is present under myPortal, located at the R101.0 software place.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 64/122
 Backup the corresponding files (all named “binmg4…”) & place the new files under /usr2/downbin. Make
sure the Linux rights are the same. Reboot the GD4/GA4. Once the new firmware is installed the N2 version can
be started.

6.4 Migrating dedicated Voicemail 4645

6.4.1 Step-1: Perform the backup of the Voicemail and Data Linux
Perform a full backup of data configured on the system through swinst→ 2. Expert Menu

6.4.2 Step-2: Install the version R101.0 with SOT or load the pre-installed Virtual Machine

Install new version R101.0-N3 through SOT on Voicemail Call Server or create a new virtual machine from
OVA file.

SOT deployment project for: CS3 / GAS / Hyper-V

Reminder: the size of the hard disk must be at least 80 Gb. Use SOT version 3.2.002.105
minimum.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 65/122
 Install software SOT R3.2, then create/update an OXE project where you declare main and standby Call Server
and PCS IP addresses. Provide the CSV file that list the rules for firewall.

For details consult, OXE system documentation:

8AL91032ENBC - OXE System: Installation Manual > 8 Communication server installation on a physical
machine
8AL91032ENBC - OXE System: Installation Manual > 9 Communication server installation on a virtual machine

1. In case of duplicated system, you can keep the main Call Server running with the previous release while
you are re-installing the release on the twin call server.
2. Once the twin Call Server configuration is ready with the database and new license, stop the telephone
on main Call Server and start the telephone on twin Call server to minimize the down time.

OVA installation for: VMware / Nutanix / Linux-KVM

Reminder: the size of the hard disk must be at least 80 Gb.

Create a new Virtual Machine by importing on the *.ova or *.vmdk file.

Note 1 It’s better to correct the system time in BIOS before installation, because change the system time after
call server installed, it will cause all system password invalid

Note 2 Update the Boot Options at creation of a new Virtual Machines to change to BIOS firmware

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 66/122
 Once installation is completed, the system will start the console interface on the menu for keyboard selection.

Note Several minutes after the initialization, some system message can overwrite the display of the keyboard
configuration. Restart the CS to display the menu properly.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 67/122
 6.4.3 Step-3: Configure the extended password
1. At first connection, initialization script requires to confirm or modify the keyboard configuration:

Note If you don’t connect immediately after initialization, system messages may be displayed over the keyboard
dialog box. If the menu is not correctly visible, restart the system to recover the original display.

2. Test of the keyboard configuration is proposed to check the keyboard selection and give the possibility
to modify the setup:

Then the admin is prompted to configure the system password for mtcl/swinst/root/adfexc and select
the activation of password Ageing if required.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 68/122
 In our example we use for mtcl : Superuser01*mt swinst : Superuser01*sw, root : Superuser01*ro

Warning Support of the full list of special characters in passwords has been delivered from patch N3 MD4 for the
scripts of SSH key distribution.
In version N3 MD1 and MD2, the list of special characters ”&()\’<>`, in passwords were not supported.
In version N3 MD3, the special characters , (comma) ’ (single quote) in passwords were not supported.
As a result, the distribution of the SSH public key to network nodes or PCS fails.

3. Enter the password for each account and confirm if you want to activate the Password aging:

Note If Password ageing is activated: after password expiry, a 30 days grace period is offered to renew the
password, then the system blocks the access to the account.

In case of mismatch of the rules, unmatching rule is indicated

4. At the end of operation validate the modifications of the password or restart the script of customization.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 69/122
 6.4.4 Step-4: Upload of the backup and restore from the configuration
1. Connect to mtcl login and check the system date and time

If the date is not correct, connect in swinst to update the date and time in menu:
2 Expert menu / 6 System management / 1 Date & time update

OVA installation for: VMware / Nutanix / Linux-KVM

Note If martian packets are displayed on the console and disturb the configuration of the system:

You can either:

- disable the network interface from the Virtual Machine momentarily to perform the complete the
netadmin then perform SSH connection.
- disable the display of the martian packets momentarily through netadmin -m menu : 11. 'Security'
/ 11. 'Logging Martian packet'

WARNING : Logging martian packet is necessary for security purpose.

Martian packet logging is activated,

Do you want to deactivate it? (y/n default is 'n') ?y

a. For OVA: perform the command netadmin to configure the IP configuration

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 70/122
 Configure only the local IP address and keep other default values:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 71/122
 The router:

Then activate the SSH for All in the Firewall(iptables) configuration 2. 'Allow/Deny SSH for all'

Then type y to activate:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 72/122
 Type 0 to finalize netadmin:

It is possible that some message linked to Martian packets are displayed due to the missing
entries in the firewall:

SOT deployment project for: CS3 / CPU8 / GAS / Hyper-V

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 73/122
 IP configuration has been provided in the SOT project and provided to OXE to configure the IP
addresses from netadmin with duplication of Call Server.

Rules for firewall have also been provided and imported on the system to authorize SFTP to transfer
the backup files and remote access to the system with SSH.

2. In your application of file transfer, update the SFTP configuration with the new mtcl password. New SSH
key will be prompted.

3. Connect with SFTP client on main Call server and copy :

a. BACKUP files in /usr4/BACKUP/IMMED for linux data / voicemail

b. new license *.swk in /usr4/BACKUP/OPS for CAPEX mode

c. file import-th.csv in /tmpd for bulk import of the Firewall rules

4. Connect to SSH from the PC Admin

From swinst tool, restore backup from voicemail & Linux data

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 74/122
Note • Old user passwords from previous database release (R12.x/R100/*) are not restored
• Trusted hosts are restored and migrated automatically into rules for IP Tables

After the restoration of Linux data, the new setting ‘SSH for all’ will be disabled.

5. Connect to root login and enter tool netadmin -m to configure the firewall 11. 'Security' / 1.
'Firewall(iptables) Configuration' / 3. 'Restricted Access Configuration' / 7. Bulk import:

6.4.5 Step-5: Synchronization of SSH keys between Call Server and dedicated voicemail in
R101.0 (N3)

On Call Server, connect in root login and use the script oxe-nw-sshkey-sync to establish passwordless
connection between Call Server duplication and dedicated voicemail in R101.0 (N3)

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 75/122
The password file must contain OXE and dedicated voicemail passwords:

@IP_OXE_main,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_OXE_CSA,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_OXE_CSB,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_dedicated_VM,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log

6.4.6 Step-6: Check the 4645 is restarted and channel accessible with the command vmail

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 76/122
6.5 Migrating PCS with remote installation or local installation

From R101.0, the PCS software can run only on CS-3, Virtual Machines or GAS Server.

Reminder: the size of the hard disk must be at least 80 Gb.

There are two types of installations possible for PCS according to the hardware compatibility and size of the
hard disk:

➢ Remote installation via SSHv2 through customer network

o CS3 with 80Gb Hard disk
o Virtual machine with 80Gb hard disk
o Minimum version R100.0 on PCS

➢ New installation from PCS at local site with console port

o Installation from scratch with SOT
▪ CS or CS-2 replaced by new board CS-3
▪ CS-3 with version R12.4 or lower
▪ Virtual machine Hyper-V with 60 Gb hard disk or version R12.4 or lower
▪ GAS server with Rocky Linux
o Import OVA from template factory
▪ For VMware/Nutanix/Linux-KVM
▪ Virtual machine running with version R12.4 or lower
▪ Virtual machine with 60 Gb hard disk

6.5.1 Local installation process

If the PCS is installed with SOT, the process of installation is identical to the Call Server installation

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 77/122
6.5.1.1 Step-1: Perform the backup of the PCS Linux data

Perform a backup of Linux data configured on the system through swinst→ 2. Expert Menu

6.5.1.2 Step-2: Install the version R101.0 with SOT or load the pre-installed Virtual Machine

Install new version R101.0-N3 through SOT on PCS or create a new virtual machine from OVA file.

SOT deployment project for: CS3 / GAS / Hyper-V

Reminder: the size of the hard disk must be at least 80 Gb. Use SOT version 3.2.002.105
minimum.

Install software SOT R3.2, then create/update an OXE project where you declare main and standby Call Server
and PCS IP addresses. Provide the CSV file that list the rules for firewall.

For details consult, OXE system documentation:

8AL91032ENBC - OXE System: Installation Manual > 8 Communication server installation on a physical
machine
8AL91032ENBC - OXE System: Installation Manual > 9 Communication server installation on a virtual machine

1. In case of duplicated system, you can keep the main Call Server running with the previous release while
you are re-installing the release on the twin call server.
2. Once the twin Call Server configuration is ready with the database and new license, stop the telephone
on main Call Server and start the telephone on twin Call server to minimize the down time.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 78/122
 OVA installation for: VMware / Nutanix / Linux-KVM

Reminder: the size of the hard disk must be at least 80 Gb.

Create a new Virtual Machine by importing on the *.ova or *.vmdk file.

Note 1 It’s better to correct the system time in BIOS before installation, because change the system time after
call server installed, it will cause all system password invalid

Note 2 Update the Boot Options at creation of a new Virtual Machines to change to BIOS firmware

Once installation is completed, the system will start the console interface on the menu for keyboard selection.

Note Several minutes after the initialization, some system message can overwrite the display of the keyboard
configuration. Restart the CS to display the menu properly.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 79/122
 6.5.1.3 Step-2: Configure the extended password
1. At first connection, initialization script requires to confirm or modify the keyboard configuration:

Note If you don’t connect immediately after initialization, system messages may be displayed over the keyboard
dialog box. If the menu is not correctly visible, restart the system to recover the original display.

2. Test of the keyboard configuration is proposed to check the keyboard selection and give the possibility
to modify the setup:

Then the admin is prompted to configure the system password for mtcl/swinst/root/adfexc and select
the activation of password Ageing if required.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 80/122
 For PCS, the same password than Call Server will be applied.
In our example, we use for mtcl : Superuser01*mt swinst : Superuser01*sw, root : Superuser01*ro

Warning Support of the full list of special characters in passwords has been delivered from patch N3 MD4 for the
scripts of SSH key distribution.
In version N3 MD1 and MD2, the list of special characters ”&()\’<>`, in passwords were not supported.
In version N3 MD3, the special characters , (comma) ’ (single quote) in passwords were not supported.
As a result, the distribution of the SSH public key to network nodes or PCS fails.

3. Enter the password for each account and confirm if you want to activate the Password aging:

Note If Password ageing is activated: after password expiry, a 30 days grace period is offered to renew the
password, then the system blocks the access to the account.

In case of mismatch of the rules, unmatching rule is indicated

4. At the end of operation validate the modifications of the password or restart the script of customization.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 81/122
 6.5.1.4 Step-3: Upload of the backup and restore the Linux data
1. Connect to mtcl login and check the system date and time

If the date is not correct, connect in swinst to update the date and time in menu:
2 Expert menu / 6 System management / 1 Date & time update

OVA installation for: VMware / Nutanix / Linux-KVM

Note If martian packets are displayed on the console and disturb the configuration of the system:

You can either:

- disable the network interface from the Virtual Machine momentarily to perform the complete the
netadmin then perform SSH connection.
- disable the display of the martian packets momentarily through netadmin -m menu : 11. 'Security'
/ 11. 'Logging Martian packet'

WARNING : Logging martian packet is necessary for security purpose.

Martian packet logging is activated,

Do you want to deactivate it? (y/n default is 'n') ?y

a. For OVA: perform the command netadmin to configure the IP configuration

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 82/122
 Configure only the local IP address and keep other default values:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 83/122
 The router:

Then activate the SSH for All in the Firewall(iptables) configuration 2. 'Allow/Deny SSH for all'

Then type y to activate:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 84/122
 Type 0 to finalize netadmin:

It is possible that some message linked to Martian packets are displayed due to the missing
entries in the firewall:

SOT deployment project for: CS3 / CPU8 / GAS / Hyper-V

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 85/122
 IP configuration has been provided in the SOT project and provided to OXE to configure the IP
addresses from netadmin.

Rules for firewall have also been provided and imported on the PCS to authorize SFTP to transfer the
backup files and remote access to the PCS with SSH.

2. In your application of file transfer, update the SFTP configuration with the new mtcl password. New SSH
key will be prompted.

3. Connect with SFTP client on PCS and copy :

b. BACKUP files in /usr4/BACKUP/IMMED for linux data

c. File import-th.csv in /tmpd for bulk import of the Firewall rules

4. Connect to SSH from the PC Admin

From swinst tool, restore Linux Data from PCS

Note • Old user passwords from previous database release (R12.x/R100/*) are not restored
• Trusted hosts are restored and migrated automatically into rules for IP Tables

After the restoration of Linux data, the new setting ‘SSH for all’ will be disabled.

5. Connect to root login and enter tool netadmin -m to configure the firewall 11. 'Security' / 1.
'Firewall(iptables) Configuration' / 3. 'Restricted Access Configuration' / 7. Bulk import:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 86/122
 6.5.1.5 Step-4: Synchronization of SSH keys between Call Server and PCS in R101.0 (N3)
On Call Server, connect in root login and use the script oxe-nw-sshkey-sync to establish passwordless
connection between Call Server duplication and each PCS in R101.0 (N3)

The password file must contain OXE and PCS passwords:

@IP_OXE_main,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_OXE_CSA,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_OXE_CSB,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_PCS1,Superuser01*mt, Superuser01*sw,Superuser01*ro,pcs1.log
@IP_PCS2,Superuser01*mt, Superuser01*sw,Superuser01*ro,pcs2.log
@IP_PCS3,Superuser01*mt, Superuser01*sw,Superuser01*ro,pcs3.log

6.5.2 Remote installation process

This process applies mainly for CS-3 boards or Virtual Machines already deployed at PCS in customer premises.

As former CS-2 or dedicated Appliance Server are not supported with R101.0, they will be replaced by new CS-
3 / GAS server with new installation from scratch.

For usual migration of OXE system, PCS are migrated first. However, as the migration to release R101.0 (N3)
requires a new installation and activation of the new security feature, it is recommended to upgrade the Call
Server duplication followed by the PCS using the remote installation process.

Warning Using this process the PCS remaining in previous version will be able to maintained in operation but the
pcscopy won’t complete until the PCS is updated into release R101.0 (N3)

The process of remote installation includes the following steps:

1- Synchronization of SSH key using the script oxe-ssh-auth or oxe-nw-sshkey-sync between Call
Server in R101.0 (N3) and PCS in previous release

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 87/122
 2- Remote download of the firmware from SOT through the Call Server and installation of the R101.0 (N3)
remotely in active partition
3- Synchronization of SSH key using the script oxe-ssh-auth or oxe-nw-sshkey-sync between Call
Server in R101.0 (N3) and PCS in R101.0 (N3)
4- Pcscopy to update the database and new linux password share with Call Server
5- Copy the rules.csv file shared with Call Server using SFTP protocol and use command netadmin to import
in bulk the firewall rules: 11. 'Security' / 1. 'Firewall(iptables) Configuration' / 3. 'Restricted
Access Configuration' / 7. Bulk import

Warning The reliability of this process relies on the stability and bandwidth of the network link between OXE and
PCS. If the network link is unstable or bandwidth is limited, it is recommended to perform the upgrade of
the PCS server locally using the same method of installation than Call Server. The version SOT 3.2.002.006
provides mandatory correction for this step, make sure the corresponding is installed before proceeding
further.

6.5.3 Synchronization of SSH key between Call Server in R101.0 (N3) and PCS in previous
release

Warning If SSH has been activated on Call Server and PCS, the file /etc/ssh/ssh_known_hosts will contain the public
key from Call Server from initial release and block the copy of the new SSH public key in patch MD1 or MD2:
On PCS, connect in root login and execute the command ssh-keygen to clean the file
/etc/ssh/ssh_known_hosts :

[root@csa]# ssh-keygen -R <CSA_IP_address> -f /etc/ssh/ssh_known_hosts

[root@csa]# ssh-keygen -R <CSB_IP_address> -f /etc/ssh/ssh_known_hosts
[root@csa]# ssh-keygen -R <CSM_IP_address> -f /etc/ssh/ssh_known_hosts

This issue has been fixed from patch MD3.

On Call Server, connect in root login and use the script oxe-ssh-auth to establish passwordless connection
between Call Server in R101.0 (N3) and PCS in previous release:

[root@csa]# oxe-ssh-auth -c <pcs_IP_address>

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 88/122
Note System passwords are still the initial passwords from previous release at this step. (mtcl, SoftInst, letacla)

In case of duplicated Call Server or multiple PCS, it is recommended to use the script oxe-nw-sshkey-sync with
one line for each PCS.

The password file must contain OXE and PCS passwords:

@IP_OXE_main,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_OXE_CSA,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_OXE_CSB,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_PCS1,mtcl,SoftInst,letacla,pcs1.log
@IP_PCS2,mtcl,SoftInst,letacla,pcs2.log
@IP_PCS3,mtcl,SoftInst,letacla,pcs3.log

6.5.4 Remote installation of PCS with SOT

1- If the existing project is not created yet, select Projects/Create project.

a. Page Project Type will open, select Project for existing products, then click Next.
b. Page Product already installed will open, select OXE, then click Next.
c. Page Project settings will open, fill the different fields Project Name, Country, Timezone,
Network Interface, then click Next.
d. Page OXE settings will open, fill the complementary fields including the CPU IP Address(es)
mtcl password and swinst password.

2- Select Projects/Project List to open the list of projects and identify the corresponding project by its
name. In the right column Actions, click on the button Update

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 89/122
 3- Enter the mtcl/swinst/root passwords from the primary Call Server that is selected by default. Then
check the box Update secondary OXE server to enter also the mtcl/swinst/root passwords.

4- Identify which Call Server is running with main role and check the corresponding box Update primary
OXE server or Update secondary OXE server:

When ready, press button Discover PCS

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 90/122
Note Note: if you see this error it means the Call Server in standby was selected, check the other box instead.

PCS discovered are displayed in a new section.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 91/122
Note Discover PCS must be repeated after each update of the project.

5- Immediately after PCS are discovered, check the box Update PCS only and select each PCS to migrate
with its mtcl credentials.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 92/122
Note If you see this error, it means the standby password is not set properly:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 93/122
 6- Press button Checking

Note With SOT 3.2.002.006, for update PCS, it is first requires to press Checking button, as Update selected
product(s) button is greyed.

If PCS version is <N3 following message is displayed, select Yes if agree to reinstall completely PCS

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 94/122
 Close following message

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 95/122
Note If one of the PCS has moved to ACTIVE mode or was stopped in the meantime, the following error will be
reported:

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 96/122
Note If you see this error, it means the transfer from SSH key from Call Server to PCS has not been completed
with tool oxe-ssh-auth in root login:

7- Now Update button is available, press ‘Update selected product(s)’

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 97/122
 8- Select OK to start update

9- Project is started

Note It takes few minutes to copy the iso file from SOT to Call Server, then the remote installation itself starts

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 98/122
 10- Update is started

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 99/122
 11- Update on-going

12- Update completed

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 100/122
 6.5.5 Post installation synchronization from PCS

1- Synchronization of SSH keys between Call Server (N3) and Passive Call Server (N3)

Note For PCS upgrade by remote installation, the system passwords are still the default passwords from the
system:
- mtcl / mtcl, swinst / SoftInst, root / letacla

Use the script oxe-ssh-auth in root login to exchange SSH keys generated after installation of R101.0 on PCS

[root@csa]# oxe-ssh-auth -c <pcs_IP_address>

In case of duplicated Call Server or multiple PCS, it is recommended to use the script oxe-nw-sshkey-sync
with one line for each PCS.

The password file must contains:

@IP_OXE_main,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_OXE_CSA,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_OXE_CSB,Superuser01*mt, Superuser01*sw,Superuser01*ro,file01.log
@IP_PCS1,mtcl,SoftInst,letacla,pcs1.log

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 101/122
 @IP_PCS2,mtcl,SoftInst,letacla,pcs2.log
@IP_PCS3,mtcl,SoftInst,letacla,pcs3.log

2- Perform pcscopy to update the database and passwords

Warning If the PCS server is seen ACTIVE from the Call Server, a double bascul or reset from the Call Server is
mandatory to update the status into UNDEF and get the possibility to execute the pcscopy.

3- After the reboot of PCS, new linux password shared with Call Server, and PCS will come back INACTIVE
mode

4- Copy the csv file for firewall rules on PCS and import it using netadmin -m in root login

6.6 SSH key distribution in OXE network and PCS list

Many features in OXE like mastercopy, pcscopy, audit-broadcast in OXE networking heavily rely on
passwordless authentication. With this change in the authentication method, it requires significant effort from
the administrator to synchronize the SSH keys of each account to the corresponding account in the remote node.

To ease this task for the administrators, a new tool called oxe-nw-sshkey-sync is provided. This tool takes
care of synchronizing the OXE network automatically without any user intervention. This tool must be launched
from an R101.0 (N3) OXE Node. It is also compatible with the OXE nodes with lower releases.

When launched from a CPU, the tool synchronizes SSH Keys with the following OXE nodes in the network
automatically. The key synchronization is done for the CPU in both the direction(A<->B) with each node in the
list.
1. Twin CPU
2. PCS Nodes
3. Voicemail 4645
4. Network Nodes
5. Twin CPU of Network Nodes

After synchronizing the main Call Server, the same transfer of Key is also performed from the standby Call
Server. To ensure proper execution the standby Call Server must be active.

Retro compatibility for network links is supported for the two previous releases with R12.4 (M5), R100.0 (N1)
and R100.1 (N2).

Internode links can be either:

- Hybrid links using IP or other protocols, homogeneous links using ISDN or other protocols for R12.4
(M5)
- Direct IP links available from R100.0 (N1)

The script can be used within OXE network with heterogeneous release such as R12.4 (M5) / R100.0 (N1) /
R100.1 (N2) / R101.0 (N3).

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 102/122
Network links with R12.3 or lower release may remain temporarily during the migration phase, but the
compatibility is not guaranteed.

6.6.1 New SSH keys management from OXE R101.0 (N3) and time of execution

The mechanism to regenerate the SSH keys during installation of R101.0 (N3) is as follow:
- Each Call Server has its own SSH keys generated during installation of software R101.0
- There are 3 pairs of SSH keys for each system account mtcl/swinst/root on each Call Server, versus only 1
key per OXE node in previous releases
- The passwordless authentication is based on new files authorized_keys created for accounts mtcl & swinst
available only from R101.0, versus the known_host file attached to swinst for previous releases

Once a node of the network is migrated into R101.0, the SSH pub keys must be shared to all other nodes
connected with an internode link, either Hybrid IP or Direct IP Links .

The network links themselves are restored immediately, and network calls are possible between nodes. In
case of encryption, it the Call Server certificates that are used to negotiate the IP sec VPN for network links.
As a result, only the function of Audit/Broadcast is temporarily disabled.

The scripts oxe-ssh-auth & oxe-nw-sshkeys-sync were created especially for this purpose to save time for the
global operation.
- Script oxe-ssh-auth is used for server to server connection, it is useful in the context of the
duplication from Call Server
- Script oxe-nw-sshkeys-sync is used within OXE network or PCS topology, by identifying
automatically the remote nodes, PCS, dedicated voicemail and automize transfer of the SSH pub
key the remote Call Server

Scripts to share SSH keys between N3 nodes (oxe-ssh-auth) work this way:
- clean known_hosts file from local node for existing entries, otherwise SSH will be blocked due to mismatch of
public keys
- clean known_hosts file from remote node for existing entries, otherwise SSH will be blocked due to mismatch
of public keys
- from local node to remote node, public key from each accounts mtcl/swinst/root are copied in the
authorized_keys file of mtcl account
- from local node to remote node, public key from each accounts mtcl/swinst/root are copied in the
authorized_keys file of swinst accounts
- from local node to remote node, SSH connection without password is verified for mtcl & swinst accounts
- from remote node to local node, public key from each accounts mtcl/swinst/root are copied in the
authorized_keys file of mtcl account
- from remote node to local node, public key from each accounts mtcl/swinst/root are copied in the
authorized_keys file of swinst accounts
- from remote node to local node, SSH connection without password is verified for mtcl & swinst accounts

Further testing in the lab with both nodes in N3 provide an execution time about 40s.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 103/122
If you consider that both nodes are duplicated there are 4 transfers of keys to perform between each Call
Server main and standby, with a total time around 3 min as detailed below:

Fri Jan 24 14:07:34 CET 2025 : Synchronizing Local CPU(10.29.19.186) Keys

Network nodes & its Twins List ! ...
Fri Jan 24 14:07:34 CET 2025 : Synchronizing Local CPU(10.29.19.186) SSH
Keys with Network Node 10.29.23.187 ...
Fri Jan 24 14:08:10 CET 2025 : Synchronizing Local CPU(10.29.19.186) SSH
Keys with Network Node twin 10.29.23.185 ...
Fri Jan 24 14:08:45 CET 2025 : Sync for Network Nodes& its Twin List
Finished !

Fri Jan 24 14:08:54 CET 2025 : Synchronizing Twin CPU(10.29.19.185) Keys

Network nodes & its Twins List ! ...
Fri Jan 24 14:08:54 CET 2025 : Synchronizing Twin CPU(10.29.19.185) SSH
Keys with Network Node 10.29.23.187 ...
Fri Jan 24 14:09:29 CET 2025 : Synchronizing Twin CPU(10.29.19.185) SSH
Keys with Network Node twin 10.29.23.185 ...
Fri Jan 24 14:10:05 CET 2025 : Sync for Network Nodes& its Twin List
Finished !

Those scripts are also compatible with previous release to maintain a retro compatibility in network from OXE
R12.4 up to R101.0. However, as the previous release do not use the same SSH keys, the transfer scripts have
been adapted to update the SSH configuration from the previous release with 3 SSH keys, known_hosts and
authorized_keys files.

To share SSH keys between N3 and N2 nodes, the first step takes some time (1m30s) to exchange the RPM
and create all SSH keys and files:
- Copy sshpass rpm to N2 node
- Install sshpass rpm on N2 node
- Create 3 SSH keys for each account on N2 node
- Create the local known_hosts and authorized_keys files

Then the regular copy of the files can be executed (1m30s)

- clean known_hosts file from local node for existing entries, otherwise SSH will be blocked due to
mismatch of public keys
- clean known_hosts file from remote node for existing entries, otherwise SSH will be blocked due to
mismatch of public keys
- from local node to remote node, public key from each accounts mtcl/swinst/root are copied in the
authorized_keys file of mtcl account
- from local node to remote node, public key from each accounts mtcl/swinst/root are copied in the
authorized_keys file of swinst accounts
- from local node to remote node, SSH connection without password is verified for mtcl & swinst
accounts
- from remote node to local node, public key from each accounts mtcl/swinst/root are copied in the
authorized_keys file of mtcl account

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 104/122
 - from remote node to local node, public key from each accounts mtcl/swinst/root are copied in the
authorized_keys file of swinst accounts
- from remote node to local node, SSH connection without password is verified for mtcl & swinst
accounts

To resume for those 2 steps, it takes 3 min per Call Server,

- Step1, take 1m30s to share the RPM and generate the keys, it is only requested for the first exchange
of keys
- Step2, takes also 1m30s to share the public key of SSH between the nodes to update the
authorized_keys files

If you consider that both nodes are duplicated there are 4 transfers of keys to perform between each Call
Server main and standby, with a total time around 12 min as detailed below:

Tue Feb 4 10:28:59 CET 2025 : Synchronizing Local CPU(10.29.19.186) SSH

Keys with Network Node 10.29.25.187 ...
Tue Feb 4 10:32:06 CET 2025 : Synchronizing Local CPU(10.29.19.186) SSH
Keys with Network Node twin 10.29.25.185 ...
Tue Feb 4 10:35:09 CET 2025 : Sync for Network Nodes& its Twin List
Finished !
…
Tue Feb 4 10:35:28 CET 2025 : Synchronizing Twin CPU(10.29.19.185) SSH
Keys with Network Node 10.29.25.187 ...
Tue Feb 4 10:38:25 CET 2025 : Synchronizing Twin CPU(10.29.19.185) SSH
Keys with Network Node twin 10.29.25.185 ...
Tue Feb 4 10:41:20 CET 2025 : Sync for Network Nodes& its Twin List
Finished !

However, if a second nodes the time of execution will be reduced by half to 1m30s perf call server and a total
of 6 min between each node with duplication:

Tue Feb 4 10:54:12 CET 2025 : Synchronizing Local CPU(10.29.23.186) SSH

Keys with Network Node 10.29.25.187 ...
Tue Feb 4 10:55:57 CET 2025 : Synchronizing Local CPU(10.29.23.186) SSH
Keys with Network Node twin 10.29.25.185 ...
Tue Feb 4 10:57:40 CET 2025 : Sync for Network Nodes& its Twin List
Finished !
…
Tue Feb 4 10:57:55 CET 2025 : Synchronizing Twin CPU(10.29.23.185) SSH
Keys with Network Node 10.29.25.187 ...
Tue Feb 4 10:59:40 CET 2025 : Synchronizing Twin CPU(10.29.23.185) SSH
Keys with Network Node twin 10.29.25.185 ...
Tue Feb 4 11:01:25 CET 2025 : Sync for Network Nodes& its Twin List
Finished !

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 105/122
6.6.2 Strategies of SSH key distribution in OXE network

You can adopt different strategies to perform the SSH keys distribution according to the customer context:

1- If you can migrate all the server OXE network is a short period with a limited number of nodes:
- Upgrade all nodes to R101.0
- Launch the script oxe-nw-sshkeys-sync once on each node of the network upgraded to R101.0.
o On the 1st node, the time of execution will be of 3 minutes for each remote node to
synchronize
o On the 2nd node, the time of execution will be of 3 minutes for each remote node to
synchronize except 1st node
o On the 3rd node, the time of execution will be of 3 minutes for each remote node to
synchronize except 1st & 2nd node
o Etc …

2- If you can migrate only a part of the nodes in several batches

- Upgrade the 1st batch of nodes to R101.0
- Launch the script oxe-nw-sshkeys-sync once on each node upgraded to R101.0
o On the 1st node, the time of execution will be of
▪ 3 minutes for each remote node to synchronize in R101.0
▪ 12 minutes for each remote node to synchronize in previous release, R100.1 or
below
o On the 2nd node, the time of execution will be of
▪ 3 minutes for each remote node to synchronize except 1st node
▪ 6 minutes for each remote node to synchronize in previous release, R100.1 or
below
o On the 3rd node, the time of execution will be of 3 minutes for each remote node to
synchronize except 1st & 2nd node
▪ 3 minutes for each remote node to synchronize except 1st & 2nd node
▪ 6 minutes for each remote node to synchronize in previous release, R100.1 or
below
o Etc …

- Upgrade the 2nd batch of nodes to R101.0

- Launch the script oxe-nw-sshkeys-sync once on each node upgraded to R101.0
o On the 1st node, the time of execution will be of
▪ 3 minutes for each remote node to synchronize in R101.0
▪ 12 minutes for each remote node to synchronize in previous release, R100.1 or
below
o On the 2nd node, the time of execution will be of
▪ 3 minutes for each remote node to synchronize except 1st node
▪ 6 minutes for each remote node to synchronize in previous release, R100.1 or
below
o On the 3rd node, the time of execution will be of
▪ 3 minutes for each remote node to synchronize except 1st and 2nd node
▪ 6 minutes for each remote node to synchronize in previous release, R100.1 or
below
o Etc …

- Upgrade the 3rd batch of nodes to R101.0

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 106/122
 - Launch the script oxe-nw-sshkeys-sync once on each node upgraded to R101.0
- Etc…

3- If you can only update update the node 1 by 1 and need to recover the broadcast service asap, the
goal will be to limit the downtime of each node.

It is possible to use a first node to perform the first key exchange with all other nodes of network, to
create the pair of SSH keys and share the rpm:

- Preparation step on 1st node

o Upgrade the 1st node to R101.0
o Launch the script oxe-nw-sshkeys-sync once on each node upgraded to R101.0. The time
of execution will be of
▪ 12 minutes for each remote node to synchronize in previous release, R100.1 or
below
o For all other nodes which don’t have an hybrid link with this reference node, use the oxe-
ssh-auth with option -c password file
▪ 12 minutes for each remote node to synchronize in previous release, R100.1 or
below

Then you can update the rest of the nodes:

- Upgrade the 2nd node to R101.0

o Launch the script oxe-nw-sshkeys-sync once on each node upgraded to R101.0. The time
of execution will be of
▪ 3 minutes for each remote node to synchronize in R101.0 except 1st node
▪ 6 minutes for each remote node to synchronize in previous release, R100.1 or
below
- Upgrade the 3rd node to R101.0
o Launch the script oxe-nw-sshkeys-sync once on each node upgraded to R101.0. The time
of execution will be of
▪ 3 minutes for each remote node to synchronize in R101.0 except 1st and 2nd node
▪ 6 minutes for each remote node to synchronize in previous release, R100.1 or
below
- Etc …

6.6.3 Homogeneous network of OXE nodes

Here, we consider a network with several OXE nodes where all the nodes will be migrated into R101.0 (N3) in
a limited period of time, several days to 1 week

The strategy 1 will be applied:

- Each node of the network is upgraded one after each other
- New password will be implemented during the migration of each node
- Internode links will be maintained during the migration period
- Broadcast will be disabled temporarily until all the migration of the full network is finished …

In such conditions, you can perform the SSH keys distribution after the migration of all nodes from the network:
- Build the password file with the final password for each node
- Apply the script on all the nodes one after each other

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 107/122
 The execution of the script will take around 3 min for each remote node in duplication, or 1m30s for each PCS
or dedicated voicemail.

Warning Support of the full list of special characters in passwords has been delivered from patch N3 MD4 for the
scripts of SSH key distribution.
In version N3 MD1 and MD2, the list of special characters ”&()\’<>`, in passwords were not supported.
In version N3 MD3, the special characters , (comma) ’ (single quote) in passwords were not supported.
As a result, the distribution of the SSH public key to network nodes or PCS fails.

6.6.4 Heterogeneous network of OXE nodes

Here we consider an OXE network, where only one or a part of the network is updated in R101.0 (N3), other
nodes can remain in release R12.4 (M5), R100.0 (N1) or R100.1 (N2).

Proceed to the upgrade the selected nodes

- One or several nodes of the network will be upgraded into R101.0 (N3)
- New password will be implemented during the migration process
- Internode links will be maintained during the migration

Script must be executed only on the nodes upgraded into R101.0 (N3).

The password file must contain the passwords from all the nodes including the ones in lower releases.

Nodes with lower releases will remain with their current password. During the execution of the script, new pairs
of SSH keys will be generated automatically through the script and password copied automatically to the remote
node.

The execution of the script will take around 12 min for each remote node in duplication or PCS still connected
to OXE with previous release.

Warning Support of the full list of special characters in passwords has been delivered from patch N3 MD4 for the
scripts of SSH key distribution.
In version N3 MD1 and MD2, the list of special characters ”&()\’<>`, in passwords were not supported.
In version N3 MD3, the special characters , (comma) ’ (single quote) in passwords were not supported.
As a result, the distribution of the SSH public key to network nodes or PCS fails.

6.6.5 Example of execution with heterogeneous network

Let’s take an example with 3 nodes configuration where Node1 and Node2 are upgraded into R101.0 (N3) and
Node 3 is still running with R100.1 (N2) :

Node 1 with local redundancy, dedicated voicemail 4645, 2 PCS subnets in R101.0 (N3) :
✓ CSA Physical IP address : 192.168.0.1
✓ CSB Physical IP address : 192.168.0.2
✓ CS Main IP address : 192.168.0.3
✓ Dedicated voicemail 4645 : 192.168.0.4
✓ PCS subnet1 : 192.169.0.1

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 108/122
 ✓ PCS subnet2 : 192.170.0.1

Node 2 with spatial redundancy, External EGW, embedded voicemail 4645, 1 PCS subnet in R101.0 (N3):
✓ CSA Physical IP address & embedded voicemail 4645 : 192.50.0.1
✓ CSA Main IP address : 192.50.0.2
✓ EEGWA IP address : 192.50.0.3
✓ CSB Physical IP address : 192.51.0.1
✓ CSB Main IP address : 192.51.0.2
✓ EEGWB IP address : 192.51.0.3
✓ PCS subnet1 : 192.52.0.1

Note There is no need to consider the IP addresses of the EEGW for this script.

Node 3 with local redundancy, embedded voicemail 4645, 3 PCS subnets in R100.1 (N2) :
✓ CSA Physical IP address : 172.25.0.1
✓ CSB Physical IP address & embedded voicemail 4645 : 172.25.0.2
✓ CS Main IP address : 172.25.0.3
✓ PCS subnet1 : 172.30.0.5
✓ PCS subnet2 : 172.31.0.10
✓ PCS subnet3 : 172.32.0.6

Note As the Node3 remains in release R100.1 (N2), the script is not executed on this node and there is no need
to declare the PCS addresses from Node3.

6.6.5.1 SSH keys distribution from Node 1

Warning If SSH has been activated on Call Server nodes in network, the file /etc/ssh/ssh_known_hosts will contain
the public key from Call Server from initial release and block the copy of the new SSH public key from
R101.0.

On Call Server main and standby of Node 3, connect in root login and execute the command ssh-keygen to
clean the file /etc/ssh/ssh_known_hosts :

[root@csa]# ssh-keygen -R <node1_CSA_IP_address> -f /etc/ssh/ssh_known_hosts

[root@csa]# ssh-keygen -R <node1_CSB_IP_address> -f /etc/ssh/ssh_known_hosts
[root@csa]# ssh-keygen -R <node1_CSM_IP_address> -f /etc/ssh/ssh_known_hosts

[root@csa]# ssh-keygen -R <node2_CSA_IP_address> -f /etc/ssh/ssh_known_hosts

[root@csa]# ssh-keygen -R <node2_CSB_IP_address> -f /etc/ssh/ssh_known_hosts
[root@csa]# ssh-keygen -R <node2_CSM_IP_address> -f /etc/ssh/ssh_known_hosts

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 109/122
 Step-1: Declare the IP Addresses or ranges of trusted hosts on each node of the OXE network

Make sure the IP addresses or ranges are declared as trusted hosts on all nodes.

You can already check that SSH command is authorized with password requests between the 3 nodes.

Execute commands ssh from node 1 to node 2, main and standby Call Servers:
[root@csa001001 tmpd]#ssh [email protected]
[root@csa001001 tmpd]#ssh [email protected]

Execute commands ssh from node 1 to node 3, main and standby Call Servers:
[root@csa001001 tmpd]#ssh [email protected]
[root@csa001001 tmpd]#ssh [email protected]

You can also test the same commands from the twin cpu of node 1.

Step-2 : Create the password file on the PC admin

1. Prepare the list of Call Server and associated password with coma separated values in a test editor from
the PC admin:

<IP_address>,<mtcl_password>,<swinst_password>,<root_password>,<login_file>

It gives for our example the following lines :

192.168.0.1,Superuser01*mt,Superuser01*sw,Superuser01*ro,node1.log
192.168.0.2,Superuser01*mt,Superuser01*sw,Superuser01*ro,node1.log
192.168.0.3,Superuser01*mt,Superuser01*sw,Superuser01*ro,node1.log
192.168.0.4,Superuser01*mt,Superuser01*sw,Superuser01*ro,node1.log
192.169.0.1,Superuser01*mt,Superuser01*sw,Superuser01*ro,node1.log
192.170.0.1,Superuser01*mt,Superuser01*sw,Superuser01*ro,file1.log
192.50.0.1,Superuser02*mt,Superuser02*sw,Superuser02*ro,node2.log
192.50.0.2,Superuser02*mt,Superuser02*sw,Superuser02*ro,node2.log
192.51.0.1,Superuser02*mt,Superuser02*sw,Superuser02*ro,node2.log
192.51.0.2,Superuser02*mt,Superuser02*sw,Superuser02*ro,node2.log
192.52.0.1,Superuser02*mt,Superuser02*sw,Superuser02*ro,node2.log
172.25.0.1,mtcl,SoftInst,letacla1,node3.log
172.25.0.2,mtcl,SoftInst,letacla1,node3.log
172.25.0.3,mtcl,SoftInst,letacla1,node3.log
172.30.0.5,mtcl,SoftInst,letacla1,node3.log
172.31.0.10,mtcl,SoftInst,letacla1,node3.log
172.32.0.6,mtcl,SoftInst,letacla1,node3.log

Note From patch MD1, the log file mandatory, and must be added on each line of the file.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 110/122
 2. Check that the twin Call Server is in service with command twin:

Note If the standby Call Server is not activated, you will need to run the script a second time once the twin Call
server is restarted.

3. Connect into root login on Node 1 running with new release R101.0 (N3)

4. Create a new file in the /tmpd directory from the Call Server main, here we will use the name
password.csv :

[root@csa001001 tmpd]# vi /tmpd/password.csv

5. Press key i to insert text, copy the list of IP addresses and password from the PC admin and paste the
data into the file from Call Server

6. Save file by pressing Esc then :wq! and validate with Enter

7. Display the content of the file with command cat /tmpd/password.csv

8. Execute the script oxe-nw-sshkey-sync

[root@csa001001 tmpd]# oxe-nw-sshkey-sync -f /tmpd/password.csv

All the activities of this tool are logged in the file /tmpd/logs/oxenwsync.log
At any point of time the running status or outcome of this tool can be checked in
that log file
Press any key to continue ...

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 111/122
 Getting Local CPU Info ...
Getting Local Twin CPU Info ...
Getting PCS List ...
Getting EVA(4645) List ...
Getting Network Node List ...
Getting Twin List of Network Nodes ...

It will first provide the status from the local Call Server:

Checking Local CPU(192.168.0.1) Connectivity Status ...

Connectivity Status Check Finished !!!
+-------------------------------------------------------------------------------------------+
+ LOCAL CPU Connection Status +
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst
+-------------------------------------------------------------------------------------------+
192.168.0.1 OK | OK | OK OK | OK
192.168.0.2 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ EVA CPU Connection Status +
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst
+-------------------------------------------------------------------------------------------+
192.168.0.4 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ PCS CPU Connection Status +
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst
+-------------------------------------------------------------------------------------------+
192.169.0.1 OK | OK | OK OK | OK
192.170.0.1 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ NETWORK NODE Connection Status +
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst
+-------------------------------------------------------------------------------------------+
192.50.0.2 OK | OK | OK OK | OK
192.51.0.2 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ NETWORK NODE TWIN Connection Status +

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 112/122
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst
+-------------------------------------------------------------------------------------------+
192.50.0.1 OK | OK | OK OK | OK
192.51.0.1 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+

Press any key to continue ...

Then it will provide the status from the twin Call Server if it is in service :

Checking Twin CPU(135.117.104.105) Connectivity Status ...

Connectivity Status Check for Twin Finished !!!
+-------------------------------------------------------------------------------------------+
+ TWIN CPU Connection Status +
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst
+-------------------------------------------------------------------------------------------+
192.168.0.1 OK | OK | OK OK | OK
192.168.0.2 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ EVA CPU Connection Status +
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst
+-------------------------------------------------------------------------------------------+
192.168.0.4 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ PCS CPU Connection Status +
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst ma
+-------------------------------------------------------------------------------------------+
192.169.0.1 OK | OK | OK OK | OK
192.170.0.1 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ NETWORK NODE Connection Status +
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst
+-------------------------------------------------------------------------------------------+
192.50.0.2 OK | OK | OK OK | OK

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 113/122
192.51.0.2 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ NETWORK NODE TWIN Connection Status +
+-------------------------------------------------------------------------------------------+
Password-Status Connection-Status
+-------------------------------------------------------------------------------------------+
IP mtcl | swinst | root mtcl | swinst
+-------------------------------------------------------------------------------------------+
192.50.0.1 OK | OK | OK OK | OK
192.51.0.1 OK | OK | OK OK | OK
+-----------------------------------------XXXXX---------------------------------------------+

Press any key to continue ...

Select y to execute the transfer of SSH keys

Connectivity Status 'NOK' Nodes will be skipped for SSH keys synchronization ... Do you want to
continue ? (y/n): y
Synchronizing Local CPU(192.168.0.1) Keys with Network, may take some time please wait ...
Synchronizing CPU SSH Keys with OXE network finished !
Synchronizing Twin CPU(192.168.0.2) Keys with Network, may take some time, please wait ...
Synchronizing Twin CPU(192.168.0.2) SSH Keys with OXE network finished !

Once all transfers have been completed the final status is shown
+-------------------------------------------------------------------------------------------+
+ LOCAL & TWIN SSH Keysync Status +
+-------------------------------------------------------------------------------------------+
IP Local-CPU Twin-CPU
+-------------------------------------------------------------------------------------------+
192.168.0.1 OK | OK
192.168.0.2 OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ EVA CPU SSH Keysync Status +
+-------------------------------------------------------------------------------------------+
IP Local-CPU Twin-CPU
+-------------------------------------------------------------------------------------------+
192.168.0.4 OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ PCS CPU SSH Keysync Status +
+-------------------------------------------------------------------------------------------+
IP Local-CPU Twin-CPU
+-------------------------------------------------------------------------------------------+
192.169.0.1 OK | OK
192.170.0.1 OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ Network Node SSH Keysync Status +
+-------------------------------------------------------------------------------------------+
IP Local-CPU Twin-CPU

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 114/122
+-------------------------------------------------------------------------------------------+
192.50.0.2 OK | OK
192.51.0.2 OK | OK
+-----------------------------------------XXXXX---------------------------------------------+
+-------------------------------------------------------------------------------------------+
+ Network Node Twin SSH Keysync Status +
+-------------------------------------------------------------------------------------------+
IP Local-CPU Twin-CPU
+-------------------------------------------------------------------------------------------+
192.50.0.1 OK | OK
192.51.0.1 OK | OK
+-----------------------------------------XXXXX---------------------------------------------+

SSH Key Synchronization for the CPU(192.168.0.1) Network Finished !!!

Archiving Log files under /tmpd/logs folder ...
Log files Archival Done Successfully in the file /tmpd/oxenwsynclogs.zip !!!
Password CSV file /tmpd/password.csv, Config(/tmpd/config) folders are cleared !
Done !!!

Step-3 : Check the SSH connectivity passwordless

After the exchange of SSH keys, SSH connection should now be available without password from Node 1 to all
other nodes. And the reverse connection should also be authorized.

Execute commands ssh from node 1 to node 2, main and standby Call Servers:
[root@csa001001 tmpd]#ssh [email protected]
[root@csa001001 tmpd]#ssh [email protected]

Execute commands ssh from node 1 to node 3, main and standby Call Servers:
[root@csa001001 tmpd]#ssh [email protected]
[root@csa001001 tmpd]#ssh [email protected]

You can also test the same commands from the twin cpu of node 1.

6.6.5.2 SSH keys distribution from Node 2

Step-4 : Update the SSH keys from the second node in Release R101.0 (N3)

The same commands must be applied on Node 2 using the same list of passwords to create all the local and
network connections.

Node 3 running with old release R100.1 (N2) is already up to date.

Step-5 : Check the SSH connectivity passwordless

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 115/122
After the exchange of SSH keys, SSH connection should now be available without password from Node 2 to all
other nodes. And the reverse connection should also be authorized.

Execute commands ssh from node 2 to node 1, main and standby Call Servers:
[root@csa001001 tmpd]#ssh [email protected]
[root@csa001001 tmpd]#ssh [email protected]

Execute commands ssh from node 2 to node 3, main and standby Call Servers:
[root@csa001001 tmpd]#ssh [email protected]
[root@csa001001 tmpd]#ssh [email protected]

You can test the same command from the twin cpu of node 2.

6.6.5.3 Radius specific configuration

From R101.0 MD1, the tool has been adapted to run with Radius configuration. If a RADIUS node is present in
the OXE network, RADIUS with local user should be configured and we need at least one mtcl /
swinst / root user to be mapped in OXE.

For this purpose, the csv file must contain the name of the mtcl, swinst and root account created with radius:

<IP_address>,<mtcl_user>,<mtcl_password>,<swinst_user>,<swinst_password>,<root_us
er>,<root_password>,<login_file>

Let’s say we created RADIUS accounts, basic with mtcl rights, admin with swinst right and superuser with
root rights in the configuration of node1 and node2 with RADIUS authentication.

It gives for our example the following lines:

192.168.0.1,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n1.log
192.168.0.2,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n1.log
192.168.0.3,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n1.log
192.168.0.4,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n1.log
192.169.0.1,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n1.log
192.170.0.1,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n1.log
192.50.0.1,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n2.log
192.50.0.2,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n2.log
192.51.0.1,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n2.log
192.51.0.2,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n2.log
192.52.0.1,basic,Superuser01*ba,admin,Superuser01*ad,superuser,Superuser01*su,n2.log

Then launch the tool with the additional option -r:

[root@csa001001 tmpd]# oxe-nw-sshkey-sync -f /tmpd/password.csv -r

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 116/122
 7 Post installation

7.1 Renew the certificate of OXE Call Server to 4096 bit

Note If you migrate a system configured with Native Encryption from a release lower than R100.1 (N2) MD3, or
with a certificate of RSA key of 1024 bit, it is required to update the certificate of the Call Server

From R100.1 MD3, the internal OXE PKI has evolve to support the generation of a new certificate based on
FQDN adapted to SIP equipment. Therefore, the configuration of the FQDN from OXE system in the tool
netadmin becomes mandatory and a new certificate must be generated to deploy the new SIP DeskPhone .

It is necessary to generate/renew the OXE certificate delivered from internal OXE PKI or external PKI and
generate/renew the associated CTL file for SIP DeskPhones.

In addition, the minimum size of the RSA key of the Call Server certificate must be at minimum of 2048 bit after
migration. The recommendation is now to increase the key size to 4096 bit by renewing the certificate after
migration.

From R101.0, the size of key has been raised to 4096 bit by default.

7.1.1 Configure OXE FQDN in tool netadmin & activate DNS resolver from OXE

1. In root login, run command netadmin and enter menu 17. 'Node configuration' / 2. 'Update'

Warning: the node name must be unique.

Warning: *** Change of Node name, requires regeneration of Call Server Certificates (CA
Update is not required ) followed by an OXE reboot ***
Enter node name (default is oxe61) ? oxe61
Do you want to activate internal name resolver (y/n default is 'n') ? y

2. Enter menu 19. 'Domain Management' / 1. 'Configure OXE Domain' / 2. 'Create/Update'

Warning: *** Change of OXE Domain name, requires regeneration of Call Server Certificates
(CA Update is not required ) followed by an OXE reboot***
Do you want to continue now (y/n default is 'n') ? y
Enter OXE Domain to be configured (default is company.com) ? company.com

7.1.2 Generate the new certificate based on OXE FQDN and renew CTL file

Warning this modification requires a restart of the system via reboot or double bascul

1. In root login, run command netadmin and enter menu 11. 'Security' / 11. 'PKI Management' / 1.
'Certificate'

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 117/122
7.1.2.1 Local node signing the certificate or CSR

1. You can either update

a. Internal certificate with entry : 1. 'Create/Modify CS Certificate' / 1. 'Internal
Certificate (Automatic Generated)'

Call Server Certificate Already present.

Do you want to replace it (y/n default is n) ? y
Do you want to update the CA (y/n, default is n)?n
Do you want to create Call Server Certificates (y/n, default is y)?y

The certificate will be created with the following CN & SAN fields
Common Name(CN)=oxe61.company.com
Subject Alternative Name(SAN)=DNS:oxe61.company.com DNS:*.company.com IP:10.13.0.6
IP:10.13.0.4 IP:10.13.0.5

Do you want to configure any additional Subject alternative Names (y/n, default is n) ?n

Enter the key size (Between 2048-4096, Default 4096) : 4096

Please enter information that will be incorporated into your certificate request.

Country Name (2 letter code) [XX]:FR

State or Province Name []:HDS
Locality Name []:Paris
Organization Name []:ALE
Organization Unit Name []:TS

/C=FR/ST=HDS/L=Paris/O=ALE/OU=TS/

Are you sure you want to create Certificate/CSR with above details (y/n default is y)?y

Generating Physical Call Server private key...

Generating Call Server Certificate Signing Request for Physical Call Server...
Signing Physical Call Server CSR...
Physical Call Server and Twin Call Server Certificates successfully generated

Note : Perform Copy to Twin Operation to copy the Twin Certificates to Twin Server

b. For External certificate, create a new CSR for an external PKI : 2. 'Generate CSR' then
import the new certificate with 1. 'Create/Modify CS Certificate' / 2. 'Import
PKCS#12/PKCS#7' on the same Call Server

7.1.2.2 Remote node from OXE subnetwork signing the certificate

1. Select entry : 5. 'CSR Sign and Import (Network)'

11.11.1.Certificate Management
==============================
1. 'Create/Modify CS Certificate'
2. 'Generate CSR'

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 118/122
 3. 'Delete Certificate'
4. 'CSR Signing (Local)'
5. 'CSR Sign and Import (Network)'
0. 'Previous menu'

What is your choice ? 5

Enter the OXE signing IP : 135.117.104.103

Please wait...

Do you want to add DNS with wildcard operator(*.al-enterprise.com) in the SAN field
entries(y/n, default is y) ?y

The certificate will be created with the following CN & SAN fields
Common Name(CN)=node006001.fr.alcatel-lucent.com
Subject Alternative Name(SAN)=IP:135.117.86.198 DNS:135.117.86.198
DNS:node006001.fr.alcatel-lucent.com DNS:*.fr.alcatel-lucent.com IP:135.117.86.204
DNS:135.117.86.204 IP:135.117.86.202 DNS:135.117.86.202 IP:135.117.86.199
DNS:135.117.86.199 IP:135.117.86.203 DNS:135.117.86.203

Do you want to configure any additional Subject alternative Names (y/n, default is n) ?n

Enter the key Size (Between 2048-4096, Default 4096): 4096

Please enter information that will be incorporated into your certificate request.

Country Name (2 letter code) [XX]:FR

State or Province Name []:HDS
Locality Name []:Paris
Organization Name []:ALE
Organization Unit Name []:TS

/C=FR/ST=HDS/L=Paris/O=ALE/OU=TS/

Are you sure you want to create Certificate/CSR with above details (y/n default is y)?y

Generating CSR for main call server...

Network signing in progress, please wait...

Network signing completed.

Warning:
CA update requires
1.Immediate regeneration of lanpbx followed by an OXE reboot. Multiple CA updates without
lanpbx regeneration and endpoint trust store update could cause CTL inconsistency between
OXE & endpoints and may lead to communication issues.
2.PCS certificate(s) to be generated manually through PCS menu if PCS(s) configured.

Do you want to import the certificates (y/n)? y

/tmp/xa006001_cert.pem: OK

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 119/122
 Certificates are imported successfully.

Note : Perform 'Copy to twin CPU (all)' operation to copy the twin certificates to twin
server.

2. New certificate is now common to both Call Server.

It includes the FQDN as the Common Name of the certificate and all IP addresses are added as SAN.
Consult the certificate with entry 4. 'View':

Call Server Certificate

-----------------------
issuer=/C=FR/ST=HDS/L=Paris/O=ALE/OU=TS/CN=lab01-12345-67890-11111
subject=/C=FR/ST=HDS/L=Paris/O=ALE/OU=TS/CN=oxe61.company.com
notBefore=Sep 8 06:58:37 2022 GMT
notAfter=Sep 3 06:58:37 2042 GMT
subjectAltName=DNS:oxe61.company.com, DNS:*.company.com, IP Address:10.13.0.6, IP
Address:10.13.0.4, IP Address:10.13.0.5

3. Perform the copy of the certificate to twin cpu with entry 10. 'Copy setup' / 2. 'Copy to twin
CPU (all)'

4. Exit from root login then launch command lanpbxbuild to renew the CTL file and select entry 6.
Apply changes

6. Apply changes
7. Copy lanpbx to lanpbx-mipt
0. Quit

==> 6

Signed CTL generated: /DHS3data/mao/DM/VHE8082/ctl_VHE8082

CTL_sign OK
--------DM ctl_VH8082 file generation--------
--------Start of Native Encryption signing------
lanpbx content signing Completed.
lanpbx content signing Completed.
lanpbx content signing Completed.
lanpbx content signing Completed.
------------------------------------------------
------------------------------------------------
--------End of Native Encryption signing--------
Renaming /DHS3data/mao/lanpbx.cfg to /DHS3data/mao/lanpbx.cfg.old

5. If you have External Encryption Gateway configured on the system, load the new certificate from the
call server on each VM of External Encryption Gateway as detailed is section Step-7: Update SSH keys
on External EGW

6. Reset the system by a restart or double bascul from the Call Server

Note

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 120/122
 If you have encrypted network link, it is necessary to remove and restore the encryption on the Direct IP
Link or Hybrid VPN Link to renew the IPSec tunnel between the nodes.

8 Maintenance commands with new Linux

8.1 Root account is not accessible directly through SFTP

To collect logs files or tcpdump limited to root account and rights, you need to copy the file to /tmpd directory
and update the rights to view them using mtcl account (chmod 705 <file_name>).

Those logs can be collected using Infocollect or oxetrace tools that provide a zip file in /tmpd directory.

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 121/122
Submitting a Service Request
Please connect to our eService Request application.

Before submitting a Service Request, please be sure:

− The application has been certified via the AAPP if a third party application is involved.
− You have read the release notes that list new features, system requirements, restrictions, and more,
and are available in the Technical Documentation Library.
− You have read through the related troubleshooting guides and technical bulletins available in the
Technical Documentation Library.
− You have read through the self-service information on commonly asked support questions and known
issues and workarounds available in the Technical Knowledge Center.

- END OF DOCUMENT -

OmniPCX Enterprise - Release 101.0 MD1 and above

Migration guide to OXE R101.0 MD4 (N3.521.*) TC3104 ed.06
© Copyright 2025 ALE International, ALE USA Inc. page 122/122