Oxe12.4 Im SoftwareInstal 8AL91032USAK 3 en

Alcatel-Lucent OmniPCX Enterprise
Communication Server
OXE System: Software Installation Manual
Release 12.4 - April 2021

8AL91032USAK Ed. 03
Legal notice
http://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 2021 ALE
International, ALE USA Inc. All rights reserved in all countries.
Disclaimer
While efforts were made to verify the completeness and accuracy of the information contained in this
documentation, this document is provided “as is”. To get more accurate content concerning Cross
Compatibilities, Product Limits, Software Policy and Feature Lists, please refer to the accurate
documents published on the Business Partner Web Site.
In the interest of continued product development, ALE International reserves the right to make
improvements to this documentation and the products it describes at any time, without notice or
obligation.
The CE mark indicates that this product conforms to the following Council Directives:
• 2014/53/EU for radio equipment
• 2014/35/EU and 2014/30/EU for non radio equipment (including wired Telecom Terminal
Equipment)
• 2014/34/EU for ATEX equipment
• 2011/65/EU (RoHS)
• 2012/19/EU (WEEE)
Table of
contents OXE System: Software Installation
Manual
Chapter 1
Reference documents
Chapter 2
BootDVD generalities
Chapter 3
Communication Server Installation
3.1 Software Installation Overview ...................................................................................16

3.1.1 Organization of the Communication Server hard drive.................................................... 16
3.1.2 Software installation environment...............................................................................................16
3.1.3 Software organization....................................................................................................................... 17
3.1.4 Procedures for installation on the hard drive.........................................................................19
3.2 Standard Communication Server installation............................................... 20
3.2.1 Software release overview............................................................................................................. 20
3.2.2 Standard installation overview......................................................................................................20
3.2.3 Communication Server standard installation requirements........................................... 21
3.2.4 Verifying the BIOS version..............................................................................................................21
3.2.5 Creating a Communication Server deployment project via S.O.T.............................. 22
3.2.6 Deploying the Communication Server project (network boot)...................................... 26
3.2.7 Standard installation progress...................................................................................................... 30
3.2.8 Configuring the Communication Server password policy............................................... 30
3.2.9 Verifying the Communication Server installation (log files)............................................ 31
3.3 Communication Server multiple installation.................................................. 32
3.4 Communication Server Installation in a KVM Environment............ 32
3.4.1 KVM environment............................................................................................................................... 32
3.4.2 Installing the FlexLM server for KVM........................................................................................ 34
3.4.3 Installing the OmniPCX Enterprise on a KVM virtual machine.....................................38
8AL91032USAK - Ed. 03 - April 2021 - OXE System: Software Installation Manual 3/279
Table of
Manual
3.5 Communication Server Installation in a VMware ESXi

Environment................................................................................................................................... 48
3.5.1 VMware ESXi environment............................................................................................................ 48
3.5.2 Installing the OmniPCX Enterprise on a VMware ESXi Virtual Machine.................51
3.5.3 Installing the VMware tools on the OmniPCX Enterprise virtual machine.............. 57
3.5.4 Installing the FLexLM Server for VMware ESXi...................................................................58
3.5.5 Appendix..................................................................................................................................................78
3.6 Communication Server Installation in a Hyper-V Environment ..80
3.6.1 OmniPCX Enterprise virtual machine prerequisites for Hyper-V.................................80
3.6.2 Installing Windows Server on the server................................................................................. 80
3.6.3 Configuring the Hyper-V client on the computer..................................................................81
3.6.4 Launching and configuring the Hyper-V Manager on the computer.......................... 82
3.6.5 Generating the OmniPCX Enterprise virtual machine via S.O.T................................. 83
3.6.6 Deploying the OmniPCX Enterprise virtual machine on a Hyper-V physical
server........................................................................................................................................................ 87
3.6.7 Configuring QoS for Hyper-V........................................................................................................ 89
3.6.8 Configuring virtual machine Live Migration in Hyper-V.................................................... 96
3.7 Communication Server installation using the multi-partition......151
3.7.1 Overview................................................................................................................................................151
3.7.2 Structure................................................................................................................................................ 152
3.7.3 Requirements......................................................................................................................................153
3.7.4 Deploying an OmniPCX Enterprise software on inactive partition............................153
3.8 Communication Server software update..........................................................157
3.8.1 Updating a single Communication Server............................................................................ 157
3.8.2 Updating networked Communication Servers (download/remote installation)... 160
3.9 Swinst................................................................................................................................................. 177
3.9.1 Swinst overview................................................................................................................................. 177
3.9.2 Access and operation..................................................................................................................... 178
3.10 Communication Server Stop/Restart Procedure...................................... 196
3.10.1 Overview................................................................................................................................................196
3.10.2 Appliance Server stop/restart procedure...............................................................................196
3.10.3 Virtual machine stop/restart procedure.................................................................................. 197
Table of
Manual
Chapter 4
Generic Appliance Server Installation
4.1 Overview...........................................................................................................................................198
4.1.1 About this chapter.............................................................................................................................198
4.1.2 Generic Appliance Server description.................................................................................... 198
4.1.3 Generic Appliance Server environment................................................................................. 199
4.1.4 Licenses.................................................................................................................................................200
4.2 Installation procedure......................................................................................................... 201
4.2.1 Collecting the required information.......................................................................................... 201
4.2.2 Verifying BIOS configuration........................................................................................................201
4.2.3 Verifying hardware, isos and licenses.....................................................................................203
4.2.4 Installing the Generic Appliance Server.................................................................................204
4.3 Ethernet bonding configuration................................................................................229
4.3.1 Process overview.............................................................................................................................. 229
4.3.2 Configuring a bonding interface including all the Ethernet interfaces.....................230
4.3.3 Including the bonding interface in the default bridge interface (br0)....................... 231
4.4 VLAN tagging configuration......................................................................................... 232
4.5 Remote login................................................................................................................................ 232
4.6 Remote desktop connection.........................................................................................233
4.6.1 Activating the VNC server on Generic Appliance Server.............................................. 233
4.6.2 Connecting to Generic Appliance Server from a VNC client....................................... 233
4.6.3 Checking connection on Generic Appliance Server........................................................ 235
4.7 Maintenance..................................................................................................................................235
4.7.1 Checking system compatibility................................................................................................... 235
4.7.2 Displaying the Generic Appliance Server version.............................................................236
4.7.3 Shutting down and restarting VMs............................................................................................236
4.7.4 Flex-LM server management...................................................................................................... 237
4.7.5 Backing up and restarting VMs.................................................................................................. 237
4.7.6 Rebooting or stopping the server..............................................................................................238
4.7.7 Modifying the server IP address................................................................................................ 238
4.7.8 Rehosting..............................................................................................................................................238
4.7.9 Updating the SLES Operating System................................................................................... 238
4.7.10 Upgrading OmniPCX Enterprise and OXE-MS.................................................................. 239
Table of
Manual
4.7.11 Adding the Rainbow WebRTC gateway to Generic Appliance Server................... 239
4.7.12 Connecting a UPS............................................................................................................................ 243
4.7.13 Reporting an issue............................................................................................................................243
4.7.14 Un-installation procedure.............................................................................................................. 243
Chapter 5
Non OmniPCX Enterprise virtual machines
5.1 OXE Media Services installation...............................................................................244

5.1.1 OXE-MS overview............................................................................................................................ 244
5.1.2 OXE-MS installation overview.................................................................................................... 248
5.1.3 OXE-MS virtual machine requirements..................................................................................248
5.1.4 OXE-MS installation process overview.................................................................................. 249
5.1.5 Configuring the OXE-MS on the OmniPCX Enterprise.................................................. 250
5.1.6 Generating the OXE-MS virtual machine via S.O.T.........................................................253
5.1.7 Deploying the OXE-MS virtual machine on the target physical server...................256
5.1.8 Replacing an existing Red Hat virtual machine by a new SUSE virtual machine
....................................................................................................................................................................265
5.2 OST Server Installation for OXE Signaling Translator or

External Encryption Gateway...................................................................................... 266
5.2.1 OST overview..................................................................................................................................... 266
5.2.2 OST installation prerequisites.....................................................................................................266
5.2.3 Installing the OST software via S.O.T.....................................................................................266
Chapter 6
Appendixes
6.1 Creating a virtual machine on KVM....................................................................... 270

6.2 Creating a virtual machine on Hyper-V.............................................................. 274
Chapter
1 Reference documents
The OmniPCX Enterprise documentation includes the documents listed in the following table:
table 1.1: OmniPCX Enterprise Documentation
Documentation title Part number
[1] System Services 8AL91000xxyy

Summary: this document provides an overview of system architecture,
topologies, as well as server duplication. It describes how to implement
synchronization and specific connections, as well as licenses, timers,
voice guides (and music-on-hold), languages and date and time.
[2] Management Tools 8AL91002xxyy

Summary: this document describes how to configure access rights to
the system by the management application, how to implement a config-
uration by domains and how to translate the strings displayed on tele-
phone sets and specific OmniPCX Enterprise applications.
[3] User Services 8AL91003xxyy

Summary: this document describes how to implement basic telephone
features such as broker call and transfer, as well as more advanced
collaboration features such as call pick-up, conferences and twin sets.
Each feature is presented in a separated chapter providing a descrip-
tion, the necessary configuration and, if need be, how to operate it.
[4] Attendant Services 8AL91004xxyy

Summary: this document describes how to implement attendant con-
soles. It also details the integrated automated attendant feature and
specific configurations for attendant consoles.
[5] Public Networks 8AL91005xxyy

Summary: this document describes the available features to configure
and implement accesses to public networks
[6] Private Networks 8AL91006xxyy

and implement networks of OmniPCX Enterprises, including QSIG and
PCX synchronization.
[7] IP-PCX Networks 8AL91007xxyy

and implement IP networks. It covers IP redundancy, quality supervi-
sion, SNMP, security and authentications.
Chapter 1 Reference documents
[8] Voice Mail 8AL91008xxyy

Summary: this document describes how to implement and configure the
native 4645 voice mail service in IMAP or VPIM. It also describes how
to centralize voice mail for several nodes and how to implement an ex-
ternal voice mail system.
[9] Mobility 8AL91009xxyy

Summary: this document describes the available features for DECT
sets and how to implement and configure every service. This document
also covers the various ways for GSM sets to rely on OmniPCX Enter-
prise services and the implementation of paging for authorized users.
[10] General Applications 8AL91010xxyy

Summary: this document describes how users can access external ap-
plications via a Presentation server. It also details how call distribution
can be precisely controlled or temporarily restricted for external calls or
within a specific group of users. The configuration to filtering of incom-
ing calls is also presented. Finally, this document covers how to share
an OmniPCX Enterprise between distinct companies and how to imple-
ment metering features, in order to monitor and control call costs.
[11] Hotel/Hospital 8AL91016xxyy

Summary: this document describes the operations and configuration of
the hospitality feature integrated to the OmniPCX Enterprise. It details
the different configurations, by room or by guest and how to connect
the system to an external hospitality application.
[13] Maintenance 8AL91011xxyy

Summary: this document details the syntax and result of the most com-
mon maintenance commands. It also details the management of inci-
dents and alarms, as well as SNMP. It covers remote maintenance fea-
tures and the operations of sets dedicated to alarms.
[14] Security 8AL91012xxyy

Summary: this document includes a detailed description on the neces-
sary measures to ensure the highest system security. Guidelines and
configuration details are provided to cover every level of this highly sen-
sitive issue.
[15] PWT 8AL91019xxyy

Summary: this document describes the implementation and configura-
tion of mobile sets relying on the PWT protocol in an OmniPCX Enter-
prise environment.
[16] Crystal Hardware System Boards 8AL91020xxyy

Summary: this document provides a detailed description of the different
system boards available in the Crystal hardware package. A visual
guidance of the default and specific positions of straps, as well as con-
nections are included.
[17] Crystal Hardware Interface Boards 8AL91021xxyy

interface boards available in the Crystal hardware package. These
boards allow the implementation of T0/S0 interfaces, DECT, analog ter-
minals, accesses to the public network, the implementation of different
OmniPCX Enterprise nodes and IP communications. A visual guidance
of the default and specific positions of straps, as well as connections
are included.
[18] Common Hardware Boards 8AL91022xxyy

boards available in the Common hardware package. Each board is de-
scribed individually. A visual guidance of connections is included for
each board.
[19] Cables 8AL91023xxyy

cables available for Crystal hardware interface boards. Maximum length
are indicated for each type of cables.
[20] Dedicated sets 8AL91024xxyy

Summary: this document provides a detailed description of the propriet-
ary sets and generic sets (including heavy-duty sets), available for the
OmniPCX Enterprise. These telephones sets can be TDM, IP or mo-
bile. Ergonomics, environmental constraints, power supply, initialization
and configuration are explained for each set.
[21] TA and TSC Adapters 8AL91025xxyy

Summary: this document provides a detailed description of the availa-
ble adapters for V24, CTI, S0 and analog peripheral. A visual guidance
of the default and specific positions of straps, as well as connections
are included.
[22] Complementary Equipment 8AL91026xxyy

Summary: this document describes the available connecting devices for
external devices, as well as V24 interfaces, tie line filter box and IBS
base stations for DECT roaming.
[23] Common Hardware Installation Manual 8AL91027xxyy

Summary: this document details what is necessary to install a Common
hardware system. Recommendations on the best environmental situa-
tions are included along with system specificities. The installation pro-
cedure details assembling, internal connections, external connections,
power supplies and first level maintenance operations.
[24] Crystal Hardware Installation Manual 8AL91028xxyy

Summary: this document provides separate chapters for each available
Crystal hardware rack. Recommendations on the best environmental
situations are included along with system specificities and cabling dia-
grams, with visual guidance to implement connections.
[25] Appliance Server Installation Manual 8AL91029xxyy

Summary: this document provides all the necessary information to com-
mission an appliance server, with or without uninterruptible power sup-
ply. Technical specifications and software version compatibilities are
provided for each available piece of hardware.
[26] Blade Center Installation Manual 8AL91030xxyy

mission a blade center, replacing up to fourteen separate servers, in an
OmniPCX Enterprise network, offering maintenance and redundancy
facilities. A precise installation procedure is included. It details how to
download a system software and how to update firmware.
[27] PCX on Standard Racks Installation Manual 8AL91031xxyy

mission a Crystal hardware OmniPCX Enterprise on industry-standard
racks. It details wiring, power supply and fixing kit recommendations
[28] Software Installation Manual 8AL91032xxyy

Summary: this document details the partitions and directories, along
with their contents necessary for system operations. It describes the dif-
ferent procedures available to deploy the software, on site or from a re-
mote location, on a physical or virtual environment.
[29] ALEDS 8AL90508xxyy

Summary: this document describes the implementation of this deploy-
ment tool in the various compatible topologies. This documents in-
cludes requirements and procedures to install each software, among
which the OmniPCX Enterprise. Software deployments and updates are
explained for physical and virtual machines.
[30] Customer Management via mgr 3EU19871xxyy

Summary: this administration manual describes how to connect, set
menus and navigate with this text interface management tools. It pro-
vides information on basic configurations, such as creating users,
speed dialing numbers, directory, telephone class of service or modify-
ing metering costs.
[31] Customer Management via 8770 8AL90615xxyy

Summary: this administration manual describes how to connect to the
OmniVista 8770 client and navigate in this GUI application. It lists the
available configurations for the OmniPCX Enterprise and provides infor-
mation on basic configurations, such as creating users, speed dialing
numbers, telephone services, alarm sets and phone book.
[32] Alcatel-Lucent 4645 - Administrator Manual 3EU19873xxyy

Summary: this administration manual describes how to configure and
implement the voice mail system embedded in the OmniPCX Enter-
prise. It also details the procedure to rely on distribution lists, how to
create mail boxes (including temporary mail boxes in hotel/hospital en-
vironments), set up an automated attendant for incoming calls, as well
as record and implement customized announcements.
[33] Internal Accounting - Administrator Manual 3EU19833xxyy

Summary: this administration manual describes how to configure and
implement the cost metering system embedded in the OmniPCX Enter-
prise. Procedures explain how to set up the different communication
types (normal, business and personal) and process the records. This
document also details how to monitor call costs from a telephone set.
[36] Alcatel-Lucent 4059 IP Attendant Console 3EU19877xxyy

Summary: this user manual describes the various features available for
attendants using a 4059 IP set. Configuration procedures are also de-
tailed.
[37] Alcatel-Lucent IP Touch 4068 Attendant Set 8AL90607xxyy

attendants using a 4068 IP set configured for this particular usage. Ba-
sic configuration procedures are also detailed.
[38] Alcatel-Lucent 4645 VMS - User Manual 3EU19583xxyy

system users wishing to make the most of this voice mail and custom-
ize their announcements.
[39] Hotel - Hospital - User Manual 3EU19837xxyy

hotel/hospital staff to configure and modify and retrieve metering re-
cords for the guests on their facility. Room service management and
basic configuration procedures are also detailed.
[40] Dongle IP / Raspberry for OpenTouch Suite 8AL90617xxyy

Summary: this document covers the deployment of USB over an IP
dongle with OmniPCX Enterprise systems to support FlexLM server de-
ployments. Procedures explain how to install the dongle, obtain the
firmware and boot the system.
[41] NFC Extended OXE Mobility Administration Manual 8AL90614xxyy

Summary: this administration manual describes the implementation of
transparent call shifts from a device to the other via NFC tags. NFC tag
generation is detailed with screenshots from the application.
[42] NFC Extended OXE Mobility User Manual 8AL90613xxyy

Summary: this user manual describes the implementation of transpar-
ent call shifts from a device to the other via NFC tags. Procedures to
read NFC tags and shift calls are provided, and the necessary mobile
phone settings are detailed.
[43] OmniVista 8770 Administrator Manual 8AL90703xxyy

[44] SP0123 Cabinet user manual and technical specifications 8AL90637xxyy
[45] S.O.T. 8AL90559xxyy
Summary: this document describes the implementation of this deploy-
ment tool in the various compatible topologies. This documents in-
cludes requirements and procedures to install each software, among
which the OpenTouch solutions. Software deployments and updates
are explained for physical and virtual machines.
[46] CCdistribution - System Documentation R10.x 8AL91301xxyy

[47] Cloud Connect Operation Overview 8AL91354xxyy
[48] ALE Terminal Accessories Management 8AL90373xxyy
[49] Description of IP flows in OmniPCX Enterprise solution 3BA290002903XX
ZZA
In the present document, cross-references are identified by the number in the first column of the above
table.
Part numbers are given in the last column, where xx corresponds to the language code of the
document, and yy to the incremented edition of the document.
Chapter
2 BootDVD generalities
The bootDVD is a software intended to be burnt in a bootable DVD or to be used through a virtual
machine (iso file format). It mainly includes the Suse Linux Enterprise operating system (previously
Red Hat Enterprise Linux).
Its purpose is to be able to install the Suse Linux Enterprise operating system, and prepare installation
of a software product such as:
• OpenTouch
• OmniPCX Enterprise
• Generic Appliance Server
• OXE Media Services (OXE-MS)
• OST (OXE Signaling Translator 64 (OST64) or Encryption Gateway (EGW))
The product list is evolutive and may include more products.
Once the physical or virtual machine has booted on the bootDVD, a menu is proposed on screen to
install the Suse Linux Enterprise operating system and prepare installation for several products. The
product installation depends on the product itself and needs additional software such as Generic
Appliance Server or OXE-MS iso files. Check corresponding system documentation to have the full
description of the product installation. Check also the OpenTouch system documentation for further
information about using this software.
The bootDVD versions are released regularly with new features, products, fixed bugs, and/or mainly
security fixes. Information is given on the Alcatel-Lucent Enterprise Business Portal.
It is important to consider the compatibilities between the bootDVD version and the product concerned.
As of OmniPCX Enterprise R12.2 MD1 and its corresponding products, ONLY the SP3 version of Suse
must be used.
To update the packages on Suse or a product, proceed as follows:
1. Connect to the product using SSH (Generic Appliance Server, OXE-MS, OST)
2. From the prompt, stop the product concerned (OmniPCX Enterprise, OXE-MS, or OST) using the
shutdown command
3. Execute the following commands:
1. Enter mount /dev/cdrom /media/cdrom with the new bootdvd
Note:
This operation may be automatically performed. Check it with mount and verify the device is correctly
mounted.
2. Enter cd /media/cdrom/scripts
3. Enter ./suse-update.sh /media/cdrom
4. Enter umount /media/cdrom
4. Do a full restart of the server at the end of the installation (Generic Appliance Server, OXE-MS,
OST)
This update procedure applies to all products managed by the bootDVD. In a typical implementation,
this operation is not mandatory, but is recommended for security reasons.
For a new installation, the latest bootDVD found on the Alcatel-Lucent Enterprise Business Portal must
be used.
The default root password is letacla1. It must be changed at first login. Password entry must comply
with the following rule: between 6 and 8 characters minimum, with at least one digit (between 0 to 9),
one lower case alphabetic character and one special character (punctuation mark).
Chapter 2 BootDVD generalities
The following figures display the menus provided after booting on the bootDVD. They may change if
new products are added, or menus are modified. Only OmniPCX Enterprise part is displayed.
Figure 2.1: BootDVD welcome page example
Chapter 2 BootDVD generalities
Figure 2.2: BootDVD main page example
Figure 2.3: BootDVD menu page example for OmniPCX Enterprise products
Chapter
3 Communication Server Installation
3.1 Software Installation Overview

3.1.1 Organization of the Communication Server hard drive
At installation, the hard drive is divided into two different parts. The active version of the application is
installed on the first part and the second part has enough space to contain an inactive version of the
telephone application.
This allows a version of the application to be installed on the inactive part of the drive without disturbing
telephone operation.
Telephony
Active version devices
Inactive version
The hard drive is partitioned.

Each partition may be considered as a virtual drive - an independent drive space containing files,
directories and data.
These partitions are said to be "mounted" (accessible with the mount command) when they can be
accessed and modified by the user.
3.1.2 Software installation environment

The OmniPCX Enterprise software can be installed on a physical server or virtualized environment
(KVM, VMware ESXi or Hyper-V).
In all cases, the OmniPCX Enterprise can connect to the Cloud Connect Infrastructure (CCI) after a
First Time Registration (FTR) and benefits from services such as Right-To-Run (RTR). The RTR
service offers license control and runs at CCI and OmniPCX Enterprise level. It cannot run on Passive
Communication Servers (PCS). For more information on FTR and RTR, see document [1].
Chapter 3 Communication Server Installation
3.1.3 Software organization

The OmniPCX Enterprise software is distributed and delivered by Alcatel-Lucent Enterprise on a CD-
ROM. The directories are always organized in the same way:
<CD-ROM root>\dhs3mgr\<release (version) name, or static or dynamic patch
name>\...
A readme.txt file is included with patches, this is located in <CD-ROM root>\dhs3mgr\<patch
or dynamic patch name>. This file gives a summary of corrections, with name (usually in English)
and error numbers and reports. The file also describes any modified binaries (a new field indicates
each such binary). All former patches for the complete standard version are listed: all previous Readme
files are therefore not needed. The most recent file summarizes all previous files.
There are two main parts:
• The Operating System: Linux.
• The telephone application.
These two parts are subdivided as follows (for installation):
• For Linux:
• Linux full version.
• Linux upgrades.
• For the telephone application:
• Telephone application full version.
• Static patch telephone version.
• Dynamic patch telephone version.
3.1.3.1 Patches
Telephone patches are delivered as a cpiofile file (Unix compressed file) located in the directory
\dhs3mgr\<version>\dhs3linux (example: \dhs3mgr\e1604\dhs3linux\comm\cpiofile).
Most binaries are located in the comm directory. For country-specific binaries, the cpiofile file is at
the same level of the tree structure but in a directory named according to the international standard
(example: es for Spain, ch for Switzerland, etc.).
Linux and swinst patches are delivered as "RPM" packages ("Red hat Package Manager": standard
for Mandrake, Suse, and Red Hat editions). These installable files contain binaries and installation
scripts for various Operating System related features (example: package
dhcp_a4400-2.1.17-1oxe.i386.rpm for the dhcp …).
3.1.3.1.1 Linux patches

Linux patches are Operating System modifications provided with telephone application versions. They
consist of “RPM” packages. The machine must be rebooted after installing such packages. They can
only be installed with the phone shut down or when installation is on the inactive partition.
This type of patch is not installed on its own (except in exceptional circumstances) as it is always part
of a telephone patch(es) delivery and is thus installed simultaneously with this.
3.1.3.1.2 Static telephone patches

These patches are new telephone application files containing corrections or upgrades. They can only
be installed with the phone shut down or when installation is on the inactive partition.
They are installed after a full version has been installed. They cannot be installed if the full version is
not installed.
A static patch can easily be distinguished from a full version by the presence of two text files in the CD-
ROM tree structure: <CD-ROM root>\dhs3mgr\<patch name>\<installlinux\for_comp and
<CD-ROM root>\dhs3mgr\<patch name>\<installlinux\patch>.
The first file is used when installing a full version in standard mode (see the Standard Communication
Server installation on page 20): for a static patch, it gives the name of the full version associated with
the patch. The second file gives patch version: this is a number starting with "1".
• Static patch name is usually the name of the full version followed by patch number.
• Each new static patch includes all corrections made in previous patches.
• To identify the version installed on the hard drive, use the siteid command.
• Some patches require a complete reboot: this is the case when a new version of Linux is installed
for example. When installation (via swinst) is complete, a system message is displayed requesting
the user to reboot the machine.
3.1.3.1.3 Dynamic telephone patches

These patches are new telephone application files containing corrections or upgrades. They can be
installed on the active or inactive partition with the phone running without disturbing phone operation.
They can also be installed with the phone shut down.
After this type of patch has been installed, it is immediately installed in CPU memory. The customer
then has the corrected version available without having to reboot the machine (except in a specific
case, described below). This installation is performed using the memloader tool. For each process
patched in memory, a 2176 incident indicating the operation is emitted. In case of problem when
loading of the dynamic patch, the patcher.log file is created and incident 2177 is emitted.
An official dynamic patch having a telephone binary (e.g. TEL.1.so) lower than an already installed non
official telephone binary (e.g. TEL.800.so) is not installed, but only copied to /DHS3bin/patches.
Dynamic patches are installed after static patch installation. They cannot run if the standard telephone
version and corresponding static patch are not installed.
Dynamic patch name always ends with one or two letters. The first dynamic patch for a version ends
with the letter “a”, the next with the letter “b” and so on till the end of the alphabet. If further patches are
necessary after the letter “z”, they are named “aa”, etc.
Special cases
When the patch provides new coupler board firmware, the boards must be reset for modifications to be
applied. For IO2N boards, the machine must be rebooted for modifications to be applied. Use the
downstat d command to ascertain which boards must be downloaded again.
Also read the readme file included on the CD-ROM in \dhs3mgr\<version>: this contains
information on certain operations to be performed after patch installation, for example, the processes to
be restarted (dhs3_init –R <process name> command) or on rebooting the machine. If these
operations are not performed, the patch will not implement all the desired corrections.
To identify the version installed on the hard drive, use the siteid command.
The file: <CD-ROM root>\dhs3mgr\<dyn patch name>\<installlinux\Nostopte (no size) is
present to inform swinst that this patch can be installed with the phone running.
The file: <CD-ROM root>\dhs3mgr\<dyn patch name>\<installlinux\patchdyn gives the
name of the static patch supporting this dynamic patch. This file is read during installation in standard
mode: for this type of installation, the installer names this patch and patch name and full version name
are retrieved recursively (via the for_comp file of the patch).
3.1.3.2 Swinst
Swinst is a package delivered with the full version of Linux. It can also be delivered as an upgrade with
full versions of the telephone application or for static (or even dynamic) patches. It can be installed with
the phone running or shut down. It is not installed on its own (except in exceptional circumstances) as it
is always part of a Linux or telephone patch(es) delivery and is thus installed simultaneously with this.
It is always located in the directory \dhs3mgr\<version>\pkglinux\facil.
Version number is given in the name (e.g. swinst-2.14.0-4alc.i386.rpm for version 2.14.0).
To identify the version installed on the hard drive, log on with the swinst account: version number is
displayed in menu headers.
For more information on swinst menu features, see: Swinst overview on page 177.
3.1.3.3 Linux
Full versions of Linux are located in: \dhs3mgr\<version>\pcmao\boot_res\bootp\linux\
followed by version number.
The full version of Linux is identified by a number ending by three zeros (for example: 106.000).
To obtain version number, use the command sysload version.
Upgrades are located in: \dhs3mgr\<version>\pkglinux\linux" and "\dhs3mgr
\<version>\pkglinux\RPMS.
To identify the upgrade version, see the file lx_version-[version].
3.1.4 Procedures for installation on the hard drive

The OmniPCX Enterprise software installation is performed via the Software Orchestration Tool
(S.O.T.).
A Communication Server can also be used as server for "remote download" type installation operations
or software upload to inactive partitions. In this case, configuration is performed using the swinst tool.
The following table lists all version and patch installation procedures that can be used.
For more information, refer to the Standard Communication Server installation on page 20, Swinst
overview on page 177, Communication Server installation using the multi-partition on page 151,
Remote download/installation presentation on page 160 or Communication Server software update on
page 157.
Module to be installed Active partition Inactive partition Installation tools
Full version to be installed See Standard Communication This is impossible, but the inactive Bios + S.O.T.
(standard installation) Server installation on page 20 partition is still created (blank)
Note:
Standard installation
comprises a full version of
Linux + Linux upgrade
(optional) + swinst +
telephone + patch (optional) +
dynamic patch (optional) +
encryption patch (optional).
swinst Installed during standard installa- Installed when a partition is dupli- S.O.T. or swinst
tion or installation of a patch cated, during remote installation,
(static or dynamic) installation of a static or dynamic
patch, or installation of a full ver-
sion of Linux
Module to be installed Active partition Inactive partition Installation tools

Full version of Linux Installed during standard installa- Installed during remote load. In- S.O.T. or swinst
tion stalled during a Duplicate Li-
nux operation in the swinst
menu Duplicate partitions.
Installed with the swinst In-
stall package menu
Linux patch "Manually" installed using "Manually" installed using swinst swinst
swinst at static patch installa- at static patch installation or by re-
tion mote load. Copied with the full ver-
sion of Linux via the Duplicate
partition menus
Telephone static patch "Manually" installed using "Manually" installed using swinst
swinst swinst(*) or by remote load.
Telephone dynamic patch "Manually" installed using "Manually" installed using swinst
swinst or by remote load swinst(*) or by remote load.
Encryption patch "Manually" installed using "Manually" installed using swinst
swinst or by remote load swinst(*) or by remote load.
(*):
Manual" installation is performed with swinst via the menu: 2 Expert menu > 9 Remote
download > 10 Local load as distributor of ISO image/ZIP file and
installation.
3.2 Standard Communication Server installation

3.2.1 Software release overview
A software release consists of:
• An Operating System: Linux (for the OmniPCX Enterprise)
• A swinst package (refer to the document [13])
• Binaries for the telephone part
• Any Linux, swinst and telephone upgrades
Upgrades are contained in patches. A patch may contain one or more upgrades.
Some upgrades are referred to as dynamic patches. These patches include telephone binaries and a
method that, in addition to installing files on the hard drive, also installs them in memory, which avoids
having to reboot the system. This is useful for installing a patch on a site in operation.
Software releases delivered by Alcatel-Lucent Enterprise have the following tree structure:
• Under the root, a directory dhs3mgr
• One or more sub-directories containing release (version) names
Caution:
This document does not cover manual installation of telephone binaries (an operation performed without
formatting the drive and during which Operating System and client data are conserved). This type of
installation is performed using swinst (see: Swinst overview on page 177 ), and is particularly useful
when you want to upgrade a release or add a patch (static or dynamic).
3.2.2 Standard installation overview

Standard installation of an Alcatel-Lucent OmniPCX Enterprise Communication Server consists in
automatically loading a full version (complete release) or full version + static patch or full version +
static patch + dynamic patch to the Communication Server hard drive.
Standard installation is performed in several steps:
1. The Communication Server must perform a network boot on the S.O.T.

2. The S.O.T. provides the linux.ram or the pxeloader for an Appliance Server via TFTP.
3. The S.O.T. provides the Linux OS, swinst packages, and telephone application binaries via FTP.
4. The Communication Server restarts automatically when installation is complete.
3.2.3 Communication Server standard installation requirements

The installation of the Communication Server requires:
• The S.O.T. started
For more details on S.O.T. installation and startup, see document [45].
• The Communication Server connected to the S.O.T. host computer or server via a crossed Ethernet
cable, a hub or switch. On Appliance Server, the Ethernet interface 1 must be used for connection.
• The target OmniPCX Enterprise software release available in iso file, including the full version and
static patches in the dhs3mgr directory. The dhs3mgr can also be uploaded to the S.O.T. as it is
The OmniPCX Enterprise software packages are available on the Business Portal Web Site.
• The network parameters of the customer LAN (subnetwork mask, domain name, gateway IP
address, and DNS IP address)
• The OmniPCX Enterprise license file
• The Communication Server settings (CPU type, MAC address, hostname and IP address)
• The twin Communication Server settings in case of duplicated configuration
If the S.O.T. is used as local storage, the OmniPCX Enterprise software package and license must be
downloaded and declared in the media list on S.O.T. For more details, see document [45].
Optionally, you can connect a terminal with VT100 emulation (Hyper-terminal, PuTTY, minicom, etc.) to
the Communication Server to follow the installation progress on screen. For any type of
Communication Server (Crystal Hardware, Common Hardware or Appliance Server), the default
configuration of the serial port is:
• Speed, 9600 bds
• 8 bits
• No parity
• 1 stop bit
• XON/XOFF
3.2.4 Verifying the BIOS version

The Communication Server must have an up to date version of the BIOS:
• For Appliance Servers, refer to Document [25].
• CS-2 boards must have BIOS version 8.3 or higher
• CS-3 and CPU8 boards must have BIOS version 0.4 or higher
• CPU7-2 boards must have BIOS version 3BA24115AAFC or higher
If this is not the case, return the corresponding board to the after-sales department.
To check BIOS version on a CS-2, CS-3 or CPU8 board:
1. Boot the board
2. When required, press the buttons Ctrl + B to enter in BIOS setup
3. Verify the BIOS version displayed on screen
To check BIOS version on CPU7-2 board:
1. Log in as root
2. Launch a command line and type the uhwconf command

3. The output of this command is for example : BIOS Version : 3BA24115AAEB
4. Check the BIOS version
BIOS version must be greater than or equal to 3BA24115AAFC bscpu7300/004.003.
If the BIOS version is lower than 3BA24115AAFC bscpu7300/004.003: the BIOS update is
required.
To update the BIOS version of a board, follow this procedure:
1. Login to the board using the root account
2. Use ftp/sftp to transfer the BIOS binary file to the /tmpd folder of the OmniPCX Enterprise node for
which the BIOS has to be updated
The BIOS binary file differs according to the type of board:
Board Binary file

CPU7-2 bsp_cpu7.hex
CPU8 bioscpu8.rom
CS-2 bioscs2.rom
CS-3 bioscs3.rom
3. Use the cp command to copy the BIOS binary file to the location /usr2/downbin/
Example:
[root@cpu7s2_33 tmpd]# cp /tmpd/bsp_cpu7.hex /usr2/downbin/bsp_cpu7.hex
4. Click y (yes) to overwrite the existing file
Example:
cp: overwrite `/usr2/downbin/bsp_cpu7.hex'? y
[root@cpu7s2_33 tmpd]#
5. Reboot the board
During BIOS reboot, the BIOS is automatically flashed if the existing BIOS version is lower than the
version placed in /usr2/downbin
6. When the flash is completed, reboot the board again
The board boots with the new BIOS
Caution:
During flashing, do not hard reboot the board and do not remove the power.
3.2.5 Creating a Communication Server deployment project via S.O.T.

The project allows you to prepare the Communication Server server deployment, and deploy it either
immediately after its creation or later according to your needs. The project creation is performed using
S.O.T.
To create a Communication Server deployment project via S.O.T.:
1. From the S.O.T. home page, select Projects > Create project
2. Select the Greenfield project option
3. Select OXE and click Next
The Medias page opens
4. Select the media on which the OmniPCX Enterprise software package and license are available:
• If the files are available on an external storage server (NFS or Windows server), and you have
already declared the external storage path for another project, select it in the drop-down list
• If the files are available on an external storage server, and you have not already declared the
external storage path, declare the external storage server, using any of the following:
• For NFS server: select the NFS share check box, and enter the NFS storage path: [NFS
URL]:/[NFS folder(s)]
• For Windows server: select the Windows share check box, and enter the Windows storage
path: //[Windows server URL]:/[Windows folder(s)]/, followed by the credentials
of a user with access rights to the storage folder(s)
• If the files have been uploaded to the S.O.T. local storage, select S.O.T. Local storage
5. Click Refresh medias list
6. Select the appropriate files listed on screen and click Declare media
7. In the OXE soft. version option, select the software version to install: the full software version,
a software version with static patch, or a software version without any patch
Figure 3.4: Media selection page example
8. When the necessary information has been provided, click Next

The Project settings configuration page opens
9. Perform the following operations:
1. Enter a Project name
2. Complete the other fields with the network parameters of the customer LAN
Note:
Do not select OVF Generation. This option is only used for Communication Server deployment on virtual
machine.
Figure 3.5: Project settings page example
10. Click Next

The OXE settings configuration page opens
11. Complete the fields with the Communication Server settings:
Field Meaning
OXE Hardware Type Select the hardware on which the Communication Server is
running
OXE keyboard Select the keyboard type used by the Communication Server
By default, the keyboard is configured as English (US). If using a
different keyboard, ensure you select it in the Keyboard field to
avoid later mismatches.
CPU hostname Enter the hostname of the Communication Server

CPU MAC address Enter the MAC address of the Communication Server
OXE country Enter the country in which the Communication Server is deployed
Field Meaning
CPU IP address Enter the IP address of the Communication Server.
In a Communication Server duplication (local redundancy), this
field must be completed with the main IP address, which is identi-
cal for the two Communication Servers.
In spatial redundancy, this field must be completed with the main
IP addresses of the two Communication Servers.
Note:
Spatial redundancy is a duplicated Communication Server configuration
where the two Communication Servers are on different IP subnetworks.
CPU redundancy (optional) In case of a duplicated configuration, if the installation must also
include the twin Communication Server installation, select this
check box and complete the configuration with the twin
Communication Server settings
Figure 3.6: OXE settings page example
12. Click Next

The Summary page opens
13. Verify the CPU hostname and software version and click Deploy
You can also click Save to create the project, and deploy it later from the project listing. For more
details, see document [45].
Figure 3.7: Summary page example
14. If you launch immediately the deployment using the Deploy button, start PXE boot on the CPU on
which the OmniPCX Enterprise software must be deployed (see: Deploying the Communication
Server project (network boot) on page 26)
3.2.6 Deploying the Communication Server project (network boot)

3.2.6.1 Network boot overview
To install a Communication Server, the Communication Server must perform a network boot.
There are two cases:
• The Communication Server hard drive is blank (for example, new board, drive replaced, etc.):
The Communication Server automatically network boots at startup.
• A release (version) is already installed on the Communication Server hard drive (this is usually the
case):
The network boot must be performed manually. It differs according to the hardware used:
• CPU7-2 board: The network boot is launched from the CPU BIOS menu, which is available after
carrying out any of the following operations:
• Starting the CPU7-2. The board boots and a message prompts you to enter in the BIOS
menu (see: CPU7-2 boards on page 27)
• Running the shutdown command. The board reboots and a message prompts you to enter
in the BIOS menu (see: CS or CPU8 boards on page 28)
• Running the command grubboot ETHER under the Linux root account. The board reboots
and automatically opens the BIOS menu (see: Network boot with the grubboot ETHER
command on page 29)
• Appliance Server, CS and CPU8 boards: There are two methods of forcing the Communication
Server to perform a network boot:
• By running the command grubboot ETHER under the Linux root account, a confirmation is
required and the board reboots. The board reboots and automatically opens the BIOS menu
(see: Network boot with the grubboot ETHER command on page 29)
Caution:
Following this command, the Communication Server hard drive is invalid and requires
reformatting.
• With a PC monitor and keyboard connected to the Appliance Server or serial console
connected to the CS or CPU8 board, press the F12 key (PXE type boot). In this case, the
hard drive is not invalidated and the network boot is performed.
Caution:
Do not modify server configuration in the BIOS menu (accessed via the F1 key) unless
specifically requested to do so by Alcatel-Lucent Enterprise support. The ex-factory
configuration has been tested to operate correctly with these values.
3.2.6.2 Network boot from the BIOS menu
3.2.6.2.1 CPU7-2 boards

Note:
Standard installation of a complete version must be previously configured in S.O.T. (see document [45])
1. From the console window of the terminal connected to the CPU7-2: boot the CPU7-2 board and
wait for the following message:
YOU CAN strike Ctrl B to enter in BIOS monitor during several seconds
from NOW !
2. A timer of a few seconds is started when this message is displayed. Press the buttons Ctrl + B.
A second entry message is displayed: hit [Ctrl I] for BIOS monitor!
3. Press the buttons Ctrl + I
A password request is displayed
4. Press Enter (no password)
The Boot Loader Menu is displayed
5. Select option 3 - Load From Ethernet (4400 method)
6. Enter y for standard installation
7. In the TEL version field, enter the version ID including the patch and country (for example:
m14011c.fr)
8. Press Enter until the New loaded file field is displayed
9. In the New loaded file field, enter the Linux version preceded by % (for example: %107.000).
Note:
The Linux version is available in the following directory: \dhs3mgr\version\pcmao\boot_res\bootp
\linux
The Communication Server makes a bootp request to the S.O.T. and software installation starts (see:
Standard installation progress on page 30).
Example:
Launching the network boot from the CPU7-2 board:
In the console window, wait for the following message:
......
value of DIL switch forced CPU7 2
USB Base address is FC21
No HD trace
YOU CAN strike Ctrl B to enter in BIOS monitor during several seconds
from NOW !
[Action]: Press Ctrl + B
hit [Ctrl I] for BIOS monitor!

[Action]: Press Ctrl + i
CPU7 Password or CR ?:
[Action]: Press Enter (no password)
Boot Loader Menu
1 - Load From Hdisk #0
2 - * disabled menu entry *
3 - Load From Ethernet (4400 method)
4 - Load From Hdisk #0 and Bootp
5 - Display MAC address
6 - PCMS id
7 - System informations
8 - Set interface KENDIN to default(auto-nego)
9 - Interface KENDIN state
10 - Set Interface KENDIN
11 - Ethernet embedded interface state
10 - Reset System
12 - Full Option Menu
13 - Reset System
CPU7>
[Action]: Select 3
3.2.6.2.2 CS or CPU8 boards

Note:
Standard installation of a complete version must be previously configured in S.O.T. (see document [45]) . This
must also include the selection of the software version and country.
1. From the console window of the terminal connected to the CS or CPU8 board, boot the board and
wait for the following message:
...............
ALCATEL CS-2 BIOS VERSION OABPT110
Press ^B to enter setup
2. A timer of a few seconds is started when this message is displayed. Press the buttons Ctrl + B.
The BIOS menu is displayed
3. To load from Ethernet, go to the Boot tab and change the boot order
4. In the Boot Option Priorities part, set the first boot option to IBA GE SLOT 0200 v1216
5. Go the Save & exit tab and press Enter to exit the BIOS menu
The Communication Server makes a bootp request to S.O.T. and the software installation starts (see:
Standard installation progress on page 30).
3.2.6.3 Network boot with the grubboot ETHER command

Caution:
The grubboot ETHER command invalidates the Communication Server hard drive and thus forces a
network boot at restart.
This operation cannot be undone and reformats the Communication Server hard drive (as is the case
for standard installation).
To launch the network boot:
1. Log in as root
2. Enter the command grubboot ETHER
A confirmation is required, then the Communication Server reboots.
Example:
[root@localhost /root]#grubboot ETHER
3.2.6.4 Network boot on a CS or CPU8 board with a blank drive

This is the same as rebooting after running the grubboot ETHER command. A confirmation is
required.
3.2.6.5 Network boot on an Appliance Server with a drive that is not blank (monitor and
keyboard connected)
Wait until the following message is displayed on the screen: PRESS F1 FOR CONFIGURATION/
SETUP, at the bottom left of the monitor screen (before the message: Verifying DMI pool data …
…….).
Press F12. The network boot starts. If there is an error:
• No address supplied by the DHCP server:
• No boot PXE loader file supplied: The server boots on the hard drive.
Various messages are displayed on the screen: these messages give information such as the IP
address assigned, the DHCP server, and the cause of any boot problems.
When this phase is complete, the system reports all installation information on the screen connected to
the V24 connector. The monitor no longer displays anything.
3.2.7 Standard installation progress

When the Communication Server is started by network boot, standard installation is performed in
several stages.
• Bootp Request and Loading of linux.ram
The Communication Server makes a bootp request to the S.O.T. to obtain an IP address via the
DHCP server.
The S.O.T. transfers the linux.ram to the Communication Server via TFTP
Boot continues.
• Loading Linux Packages
The S.O.T. transfers the Linux packages to the Communication Server via FTP
Use <Tab>/<Alt-Tab> toggle between elements | <Space> selects | <F12> next screen
• Loading the swinst Package
The S.O.T. transfers the swinst package to the Communication Server via FTP
• Loading Telephone Binaries
The S.O.T. transfers the telephone binaries to the Communication Server via FTP
• Communication Server Restart
When telephone binary loading is complete, the Communication Server reboots, restarts, and shuts
down in Linux.
Standard installation is finished and must be completed by configuring the Communication Server
network parameters using the netadmin tool (IP address and netmask to be configured).
3.2.8 Configuring the Communication Server password policy

As of R6.2, at the end of the Communication Server reboot, the security menu is displayed on the
system console. The security menu requests to define security level before the Communication Server
is in use.
When the security dialog is displayed, no IP interface is configured. This implies that no external IP
connection can be achieved. In other words, nobody, apart from the console user, can access the
Communication Server.
Security setting dialog:
Do you want to activate server security high level (Y/N) ?
• N: when the answer is No the following menu is displayed:

Select server security level:
R) Configuration to be restored
0) Level_0 = no security feature activated
1) Level_1 = password/aging
2) Level_2 = password/aging + trusted hosts/TCP wrapper
3) Level_3 = password/aging + trusted hosts/TCP wrapper + SSH
• R): no security function is activated. The installer must later restore the security configuration
from a backup.
• 0): no security function is activated. This configuration applies when a trusted IP network is used.
• 1): in this case the system requests a new password for the accounts root, swinst, mtcl and
adfexc. The new passwords must comply with the password check rules. For more information
on password check rules, refer to the section Password composition check rules of the
document [14]. Note that the account name and the password cannot be identical. For example:
root is not a valid password for the account root.
In addition, the system request the maximum duration of use for the password of each account.
Set to zero, the aging password option indicates that this option is deactivated for the
corresponding account.
• 2): in this case the system requests new passwords (as done for 1). In addition, the
Communication Server is isolated from the IP network. Only trusted hosts can connect to it. The
installer must declare trusted hosts later, using the netadmin tool.
• 3): in this case new passwords are requested (as done for 1), the Communication Server is
isolated (as done for 2). In addition the SSH function is activated. The SSH function performs
encryption of the calls between machines. For more information on SSH function, refer to the
section Securing exchanges via SSH of the document [14].
• Y: when the answer is Yes new passwords/password maximum duration are requested (as for 1),
the Communication Server is isolated (as for 2) and the SSH function is activated (as for 3).
When the security level selection is performed, the final security configuration is displayed.
For example:
Security configuration:
[+] Default password changed.
[+] Aging password configured.
[+] Isolation from ethernet (trusted host TO
BE configured).
[-] The SSH security is currently NOT set.
You are strongly advised to modify the passwords for all Communication Server user accounts and
also the passwords recorded on the OmniVista 8770 at system installation. These modifications should
be performed on the passwords for the root, swinst, mtcl, adfexc, and client (if there is one) accounts.
The modifications should be carried out on all network nodes.
For more information on Alcatel-Lucent Enterprise recommendations for password management, see:
[14] Recommended password policy.
3.2.9 Verifying the Communication Server installation (log files)

Log files can be viewed in the directory /install-log. These files store Communication Server
installation and the settings sent to the installer server for the boot.
These files may be required by technical support in the event of a problem.
3.3 Communication Server multiple installation

The Software Orchestration Tool (S.O.T.) can be used to install multiple communication servers with
the same software version:
• If there are two communication servers to install:
1. Create a project in S.O.T., using the CPU redundancy option, and the settings of the two
communication servers
Note:
The two communication servers are installed as one with the main role, and the other communication
server with the standby role.
2. Deploy the project from S.O.T.
3. Start the two communication servers (network boot)
Note:
For more details on project creation and deployment on S.O.T., see: Standard Communication Server
installation on page 20.
• If there are more than two communication servers to install:
1. Create a project in S.O.T. with the settings of the first communication server to install (project X)
2. Deploy project X from S.O.T.
3. Start the first communication server (network boot)
4. For each new communication server to install:
1. Edit and update project X with the settings of the next communication server:
1. From S.O.T., go to: Projects > Projects listing
2. Click the button to the right of project X

3. Click the down arrow to view OXE server details
4. Update with the settings of the next communication server
5. Click the Save button
2. Deploy project X:
1. From S.O.T., go to: Projects > Projects listing
2. Click the button to the right of project X
3. Start the communication server (network boot)
Note:
For more details on project creation and deployment on S.O.T., see: Standard Communication Server
installation on page 20.
3.4 Communication Server Installation in a KVM Environment

3.4.1 KVM environment
3.4.1.1 Overview
The OmniPCX Enterprise can be installed on a Kernel-based Virtual Machine (KVM) environment. The
KVM solution is based on a Suse Linux Enterprise operating system and a KVM virtualization layer. In
this configuration, a virtual machine can be created to host the OmniPCX Enterprise.
The following topologies are supported by the KVM environment:
• Stand alone OmniPCX Enterprise with a single FlexLM server
• Stand alone OmniPCX Enterprise with FlexLM server duplication

• OmniPCX Enterprise duplication with one single FlexLM server
• OmniPCX Enterprise duplication with FlexLM server duplication
Figure 3.8: Exemple of OmniPCX Enterprise duplication with FlexLM server duplication
• Stand alone OmniPCX Enterprise without any FlexLM server (as of R12.0). The OmniPCX
Enterprise connects to the Cloud Connect Infrastructure (CCI) after a First Time Registration (FTR)
and benefits from services such as Right-To-Run (RTR). The RTR service offers license control and
runs at CCI and OmniPCX Enterprise level. It cannot run on Passive Communication Servers
(PCS). For more information on FTR and RTR, see Document [1].
The FlexLM server is included in a virtual machine for KVM (iso format) and this virtual machine can be
installed on the same server as the OmniPCX Enterprise virtual machine or on another server.
When no USB port is available on the FLEX server VM, the installation can also include a remote USB
IP box for the dongle.
3.4.1.2 Installation process overview

Operations consist in:
• Installing the FlexLM server for KVM on page 34
Note:
Skip this operation when licensing is performed using Cloud Connect. See the section on Licenses in [1].
• Installing the OmniPCX Enterprise on a KVM virtual machine on page 38
• If using a dongle on a remote USB IP box, see: [40]
This does not include the operating system and KVM packages installation on the physical server. The
installation of KVM virtualization packages requires SUSE Linux Enterprise Server (SLES) 12 SP3 (or
higher) as operating system. To install the SLES operating system and KVM packages, refer to the
technical documentation of the manufacturer.
Notes:
• Virtualization packages can be installed either during the host installation sequence or after host installation
using the zypper command.
• Ensure that bridged network has been configured, because Communication Server virtual machines use the
same for access over LAN, and also turn off the NetworkManager to use the network service instead.
3.4.2 Installing the FlexLM server for KVM

3.4.2.1 Overview
Licensing with a FlexLM server is used by the OmniPCX Enterprise for:
• RSI licenses
• In a virtualized CS, instead of checking the CPU-ID against the content of the software.mao file, a
product-ID is acquired by the FlexLM server. There is only one product-ID per OmniPCX Enterprise
A FlexLM server can be used by several OmniPCX Enterprise servers. When a panic flag is raised on
the OmniPCX Enterprise, the configuration and services become highly restricted.
To fulfill high availability requirements, current OmniPCX Enterprise versions can rely on a second
FlexLM server.
3.4.2.2 Services provided

In a high availability configuration, the OmniPCX Enterprise provides:
• FlexLM server redundancy: to rely on a second FlexLM server when the first FlexLM server is
unavailable. FlexLM servers are independent. They each provide the same product-ID
• OmniPCX Enterprise redundancy: when the main OmniPCX Enterprise shuts down, the stand by
OmniPCX Enterprise (which becomes new main) ensures the licensing service with the FlexLM
server (checkouts, heartbeats)
• Defense: to prevent fraud attempts
3.4.2.3 Prerequisites
Before installation you must have:
• a physical dongle from Aladdin Knowledge Systems (type Hasp 4MI USB memory key
Part:#FLEXid-ALA-7200): this dongle defines the FLEX-ID used to authenticate the OmniPCX
Enterprise license file.
• The FlexLM Server DVD: this DVD contains the pre-installed license server for KVM in the ISO
format. The iso file must contain:
• FlexlmServer.xml
• FlexlmServer.img.gz
• The FlexLM server licence file (extension .ice): license for the FlexLM server for the dongle
• The OmniPCX Enterprise license file (extension .swk). This license file is for the OmniPCX
Enterprise which is virtualized
Note:
All these are required for the installation. If one of these items is not available, stop the procedure.
3.4.2.4 Installing the FlexLM server virtual machine
3.4.2.4.1 Deploying the KVM packages

1. Mount the iso image:
$ mount –o loop vmFlex-kvm-X.X.XXX.XXX.iso <mountpoint>
2. Go to the working directory:
$ cd /var/lib/libvirt/images
3. Uncompress the image:
$ gunzip -c /<path_to_iso_mounting>/FlexlmServer/FlexlmServer.img.gz >

MyFlexLMServer1.img
4. Define the virtual machine:

$ cp /path_to_iso_mounting/FlexlmServer/FlexlmServer.xml
MyFlexLMServer1.xml
In the MyFlexLMServer1.xml file, change lines:
<name>MyFlexLMServer1</name>
<source file='/var/lib/libvirt/images/MyFlexLMServer1.img'/>
$ virsh define MyFlexLMServer1.xml
5. Start the Virtual Machine Manager application:
$ virt-manager
When the FlexLM Server virtual machine has been successfully created, it is displayed in the
Virtual Machine Manager application:
Figure 3.9: FlexLM Server creation example
6. Start the FlexLM server virtual machine: right click the virtual machine and use the contextual menu
to select Run
The FlexLm server starts booting
3.4.2.4.2 System configuration

System configuration consists in:
1. Configuring the keyboard
2. Configuring the network
3. Modifying passwords
4. Configuring NTP parameters
5. Configuring time zone
For more details on this configuration, see: Installation of OVF FlexLM server on the VMware ESXi
server on page 59.
3.4.2.5 Dongle installation

The dongle installation procedure can be performed in one of the two following methods:
• The dongle is plugged directly in a USB port of the FlexLM server, if a USB port is available, see
below
• When no USB port is available on the FlexLM server VM, the dongle is plugged on a remote USB/IP
box, see: [40]
The USB dongle installation consists in:
1. Identifying the USB device on page 36
2. Selecting the USB device on page 36
3.4.2.5.1 Identifying the USB device

1. From the server home page, select: Applications > System tools > Konsole
This opens a console window
2. From the prompt, enter the lsusb command
This command allows you to display the vendor and product ID required to choose the USB device
in the FlexLM server Virtual Machine.
This returns a line such as: Bus 001 Device 003: ID 0529:0001 Aladdin Knowledge
Systems HASP v0.06
3.4.2.5.2 Selecting the USB device

1. Plug the USB dongle on the USB port
2. From the server home page, navigate to: Applications > System Tools > Virtual Machine
Manager to launch the Virtual Machine Manager application
The Virtual Machine Manager opens
3. Select the Virtual Machine, then select: Edit > Virtual Machine details
The Virtual Machine detail window opens
4. Select Add hardware.
A virtual hardware configuration window opens
5. Select the menu USB Host Device
6. In the left right part of the window, select the line corresponding to the vendor and product ID
searched previously and click Finish
3.4.2.6 License installation

When network configuration is completed, the license server must be configured.
Copy the license file corresponding to the server (the file with extension .ice). This license must match
the license file provided with the dongle.
Note:
By default, FTP does not operate on this server. You can copy this file using secure FTP or SCP or from any
media source
• Copy this file to $LICENSES_HOME
• Restart the FlexLM services: service flexlmd restart
Note:
If the hostname configuration is faulty or if the license file is not generated for the attached dongle or if the dongle
is not attached, the FlexLM Server does not start.
Logs are available in: /opt/Alcatel-Lucent/logs/flexlm/.
Verify FlexLM logs to ensure that the flexlmd service has been started
Details on the OmniPCX Enterprise virtual machine license checkout from the FlexLM server are
logged in: /opt/Alcatel-Lucent/logs/flexlm/flexlm_lmlog.log
Verify that the FlexLM services are started: service flexlmd status
Verify that licence information is available:
/opt/Alcatel-Lucent/flexlm_standalone/lmutil lmstat –a
You have successfully installed and configured the FlexLM server.
3.4.2.7 Installing one FLexLM server for several virtualized OmniPCX Enterprise servers
• This architecture does not require any specific configuration on the OmniPCX Enterprise servers or
on the FlexLM Server.
• One single dongle is used
• Several license files (.ice extension) must be installed on the FlexLM server
• Several license files (.swk extension) must be installed on each OmniPCX Enterprise server
Once license files have been installed on all servers, restart the FlexLM service or restart the virtual
machine so that licenses are taken into account. Each OmniPCX Enterprise server can then register on
the same FlexLM server.
In case the FlexLM server is duplicated (which implies that two addresses are declared on each
OmniPCX Enterprise server), two dongles are necessary and twice as many .ice licenses must be
installed on the FlexLM servers.
3.4.2.8 Configuring the FlexLM server on the OmniPCX Enterprise

Open a configuration console on OmniPCX Enterprise (for example: mgr), and navigate to System >
Licenses and configure the following parameters:
Figure 3.10: FlexLM server configuration example
Notes:
• Once you have configured the FlexLM server, reboot the OmniPCX Enterprise to apply your modifications
• As of R11.2, if no FlexLM server responds, after five days , the panic flag is raised on the OmniPCX Enterprise,
before displaying Call Installer on telephone sets.
Note:
The panic flag is raised four hours after no response from the FlexLM server in earlier releases.
3.4.3 Installing the OmniPCX Enterprise on a KVM virtual machine

3.4.3.1 Overview
Virtual machine creation is performed with the Virtual Machine Manager application. This
application, a graphical tool to create and configure virtual machines, is available in the KVM packages,
installed with the operating system on the server.
OmniPCX Enterprise installation on the virtual machine is performed with the S.O.T..
3.4.3.2 OmniPCX Enterprise virtual machine prerequisites for KVM

Hardware prerequisites for the OmniPCX Enterprise virtual machine are detailed in the following
documents available on the Alcatel-Lucent Enterprise Business Portal:
• TBE043: see: https://businessportal.al-enterprise.com/node/430986

The OmniPCX Enterprise installation on a KVM virtual machine consists in:
• Generating the OmniPCX Enterprise virtual machine via S.O.T. on page 39
• Deploying the OmniPCX Enterprise virtual machine on a KVM physical server on page 43
• Configuring the OmniPCX Enterprise on page 47
3.4.3.4 Generating the OmniPCX Enterprise virtual machine via S.O.T.

To generate the OmniPCX Enterprise virtual machine via S.O.T.:
1. If OmniPCX Enterprise virtual machine deployment without OVF, create manually the virtual
machine on the physical server with the appropriate characteristics. According to the virtualization
environment, perform one of the following:
• Create a virtual machine on KVM: see: Creating a virtual machine on KVM on page 270.
• Create a virtual machine on VMware ESXi: see TC2431 available on the Alcatel-Lucent
Enterprise Business Portal: https://businessportal.al-enterprise.com/TC2431en.
• Create a virtual machine on Hyper-V: see: Creating a virtual machine on Hyper-V on page 274.
Note:
Hyper-V does not support virtual machine deployment with OVF file. The virtual machine must be created
manually on Hyper-V.
Important:
Do not start immediately the virtual machine.
5. Select the media on which the files (software release and license) are available:
7. Select the appropriate files listed on screen, and click Declare medias
Figure 3.11: Media selection window example
9. When the necessary information has been provided, click NextThe Project settings
configuration page opens
2. If OmniPCX Enterprise virtual machine deployment with OVF, select the OVF Generation field
11. Click Next

12. Complete the fields with the Communication Server (OmniPCX Enterprise) settings:
Field Meaning
OXE Hardware Type This field is only displayed if deployment without OVF.
Select the hardware on which the Communication Server is run-
ning
OXE sizing This field is only displayed if deployment with OVF.

Select the number of users used to size the OVF file

Note:
If OmniPCX Enterprise virtual machine deployment with OVF, the MAC
address field is grayed and cannot be modified.
Field Meaning
Note:
13. Click Next

14. Verify the OmniPCX Enterprise hostname and software version and click Deploy
15. According to the type of deployment, perform one of the following:

• If OmniPCX Enterprise virtual machine deployment without OVF: start PXE boot on the virtual
machine on which the OXE-MS must be installed
• If deployment of the OmniPCX Enterprise virtual machine with OVF file: once OVF file is
successfully generated, click Download and save the OVF file on a device storage. Use this
OVF file to deploy the OXE-MS virtual machine on the target physical machine
According to the virtualization environment, see:
• Deploying the OmniPCX Enterprise virtual machine on a VMware physical server on page 55
• Deploying the OmniPCX Enterprise virtual machine on a Hyper-V physical server on page 87
3.4.3.5 Deploying the OmniPCX Enterprise virtual machine on a KVM physical server
To deploy the OmniPCX Enterprise virtual machine on a KVM physical server:
1. From the KVM physical server home page, navigate to: Applications > System Tools >
Virtual Machine Manager to launch the Virtual Machine Manager application
• Deployment of the OmniPCX Enterprise virtual machine using an OVF file:
1. Select File > New Virtual Machine, or click the icon

The Virtual Machine creation window opens
2. Select the Network Install (HTTP, FTP or NTFS) option, and enter the URL of the
OVF file including the OmniPCX Enterprise virtual machine
3. Click Next several times to verify and modify the OmniPCX Enterprise virtual machine
settings such as the name, then click Finish
The virtual machine is created and started, and the OmniPCX Enterprise installation
automatically starts on the virtual machine.
• Deployment of the OmniPCX Enterprise virtual machine without using an OVF file:
Power on the virtual machine using any of the following:
• Right click the virtual machine and select Run
• Select the virtual machine and click the icon symbolized by a right-pointing arrow
The virtual machine performs a network boot, connects to the S.O.T. and loads the OmniPCX
Enterprise software. The OmniPCX Enterprise installation automatically starts on the virtual
machine.
Monitor the progress of the OmniPCX Enterprise installation on the console of the Virtual
Machine Manager application.
Installation differs from a Blade Server/Appliance Server installation, it stops after loading Linux
config files, and requires manual input to select the installation type.
3. Select standard installation and specify the path to download the files: /path/
releaseversion.country_name (for example: /dhs3mgr/l1301.fr), and select Ok.
Note:
If the version includes a dynamic patch, enter the complete name of the version up to the dynamic patch. For
example, select l130110b.fr to automatically install the software version with the dynamic patch: l1.301.10.b.
The installation procedure continues.
The login prompt is displayed after a successful installation
3.4.3.6 Configuring the OmniPCX Enterprise

After OmniPCX Enterprise installation, the default keyboard is English US. If you must use a keyboard
other than the default keyboard (for example: French or German), you must first change the keyboard
type before configuring the OmniPCX Enterprise:
1. Open a console on the virtual machine
2. Open a root session

Note:
Root password is letacla.
3. Enter the kbdconfig command
4. Use the up and down arrows to select the corresponding keyboard, and press the space bar to
validate your selection
Once the keyboard type selected, configure the IP settings of the OmniPCX Enterprise:
From the same root session, enter the netadmin command and configure the IP Address of the
OmniPCX Enterprise virtual machine, netmask and default router
It is recommended to configure the IP address of this virtual machine in the subnetwork of the physical
server.
3.5 Communication Server Installation in a VMware ESXi Environment

3.5.1 VMware ESXi environment
3.5.1.1 Overview
Virtualization dramatically improves the efficiency and availability of resources and applications.
Virtual Machine (VM) software can be used for a number of purposes. Server consolidation (running
multiple logical servers on a single physical machine) is a popular way to save money on hardware
costs and also makes backup and administration easier.
The following topologies are supported by this feature:
• Stand alone OmniPCX Enterprise with a single FlexLM server
• Stand alone OmniPCX Enterprise with FlexLM server duplication
• OmniPCX Enterprise duplication with one single FlexLM server
• OmniPCX Enterprise duplication with FlexLM server duplication
Figure 3.15: Example of OmniPCX Enterprise duplication with FlexLM server duplication
• Stand alone OmniPCX Enterprise without any FlexLM server (as of R12.0). The OmniPCX
Enterprise connects to the cloud Connect Infrastructure (CCI) after a First Time Registration (FTR)
and benefits from services such as Right-To-Run (RTR). The RTR service offers license control and
runs at CCI and OmniPCX Enterprise level. It cannot run on Passive Communication Servers
(PCS). For more information on FTR and RTR, see Document [1].
The FlexLM server is provided in a VM for VMware ESXi (ovf format) and this VM can be installed on
the same server as the OmniPCX Enterprise VM or on another server.
• Before R10.1.1, only one OmniPCX Enterprise VM is allowed on a server but other VMs for
applications can be used on the same server. For example, an embedded 4645 voice mail (16 port)
is allowed.
• As of R10.1.1, up to eight virtual machines hosting an OmniPCX Enterprise can run on one physical
machine but the embedded 4645 voice mail is not available
• As of R11.0, up to eight virtual machines hosting an OmniPCX Enterprise can run on one physical
machine, with their embedded 4645 voice mail available
The installation of more than one virtual machine hosting an OmniPCX Enterprise on the same
physical server requires:
• VMware ESXi 5.5 with hardware Vmware version 8 to 10
• VMware ESXi 6.0 with hardware Vmware version 11
• VMware ESXi 6.5 with hardware Vmware version 13
• VMware ESXi 6.7 with hardware Vmware version 14 and above
• VMware ESXi 7.0 with hardware Vmware version 17 and above
• Hardware, recent enough to provide sufficient capacity.
The following processors, for example, can be used:
• Xeon Westmere-EP (35xx, 55xx, or later version)
• Nehalem -EX (65xx, 75xx, or later version)
• AMD 4000 Valencia and 6000 Interlagos series (or later version)
The OmniPCX Enterprise VM supports RAID - Redundant Array of Independent Disks, however UPS is
not supported.
As of R10.1.1, an OmniPCX Enterprise hosted on a virtual machine can rely on a SAN (Storage Area
Network) rather than a virtual disk.
The SAN allows the VMotion feature: a virtual machine, hosting an OmniPCX Enterprise, can be
moved from a physical ESXi server to another, without interruption of service.
The VMotion feature is available:
• For the main OmniPCX Enterprise with very light traffic
• For the standby OmniPCX Enterprise
By vSphere Virtual Machine Encryption, we can create encrypted OXE/OMS/OST virtual machines and
encrypt existing OXE/OMS/OST virtual machines. Because all virtual machine files with sensitive
information are encrypted, the virtual machine is protected. Only administrators with encryption
privileges can perform encryption and decryption tasks.
An external KMS, the vCenter Server system, and your ESXi hosts are contributing to the vSphere
Virtual Machine Encryption solution. In vSphere Web Client or the vSphere API add a cluster of KMS
instances to the vCenter Server system, vCenter Server uses the Key Management Interoperability
Protocol (KMIP) to make it easy to use the KMS of your choice.
It is mandatory to enable VMWARE License file with the vSphere VM Encryption and vSphere
encrypted vMotion parameters enabled.
3.5.1.2 Software version

The following software versions can be used:
• VMware ESXi Server:
• For one Communication Server on a physical machine, the VMware ESXi Server: version 5.5
and 6.0 are certified
• For up to eight servers on a physical machine, without the 4645 voice mail, the VMware ESXi
Server: 6.5, 6.7 and 7.0 are certified
• For up to eight servers on a physical machine, with the 4645 voice mail, the VMware ESXi
Server: 6.5, 6.7 and 7.0 are certified
• vSphere Client version 5.5 to 6.5 according to the VMware ESXi server version
• FlexLM Sever 9.50

Operations consist in:
• Installing the OmniPCX Enterprise on a VMware ESXi Virtual Machine on page 51
• Installing the FLexLM Server for VMware ESXi on page 58
Note:
Skip this operation when licensing is performed using Cloud Connect. See the Licenses section of [1].
• If using a dongle on a remote USB IP box, see [40]
This does not include the VMWare ESXi Infrastructure installation on the physical server. The VMWare
ESXi Infrastructure is not the responsibility of Alcatel-Lucent Enterprise. Correct deployment of virtual
machines demands that the ESXi infrastructure has been properly installed and configured.
3.5.2 Installing the OmniPCX Enterprise on a VMware ESXi Virtual Machine

3.5.2.1 Overview
Alcatel-Lucent Enterprise recommends one of the following installation methods to install the OmniPCX
Enterprise on a Virtual Machine:
• Installation of the OmniPCX Enterprise VM through the S.O.T.
• Installation of the OmniPCX Enterprise VM through the OmniVista 8770 (used to install the
OmniPCX Enterprise on an inactive partition)
For a first installation, refer to: Generating the OmniPCX Enterprise virtual machine via S.O.T. on page
39.
3.5.2.2 OmniPCX Enterprise virtual machine prerequisites for VMware

Hardware prerequisites for the OmniPCX Enterprise virtual machine are detailed in the following
documents available on the Alcatel-Lucent Enterprise Business Portal:
• TC2431: see: https://businessportal.al-enterprise.com/TC2431en
3.5.2.3 Generating the OmniPCX Enterprise virtual machine via S.O.T.

Note:
Important:
11. Click Next

Field Meaning
ning

Field Meaning
Note:
Note:
13. Click Next


3.5.2.4 Deploying the OmniPCX Enterprise virtual machine on a VMware physical server
To deploy the OmniPCX Enterprise virtual machine on a VMware physical server:

1. Open a web browser and enter the following URL:
https://<VMware ESXi server IP address>
2. Log in with your user credentials
The vSphere web client inventory page opens
• Deployment of the OXE-MS virtual machine using an OVF file:
1. Right click the host and select Create/Register VM
The virtual machine creation window opens
2. Select Deploy a virtual machine from an OVF or OVA file and click Next
The source selection window opens
3. Enter the name of the virtual machine and select the OVF file including the OXE-MS virtual
machine
4. Click Next several times to verify and modify the OXE-MS virtual machine settings such as
the name, then click Finish
The virtual machine is created and started, and the OXE-MS installation automatically starts on
the virtual machine.
• Deployment of the OXE-MS virtual machine without using an OVF file:
• Right click the virtual machine and select Power > Power On
• Select the virtual machine and select Power On
The virtual machine performs a network boot, connects to the S.O.T. and loads the bootdvd and
OXE-MS software. The OXE-MS installation automatically starts on the virtual machine.
Monitor the progress of the OXE-MS installation on the console of the VMware web client.
4. Select Yes to reboot the OmniPCX Enterprise after the successful installation
Note:
To select the Yes option, make a single mouse click on the console window and use the arrow keys to navigate
to Yes. Press Enter
5. Secure the OmniPCX Enterprise passwords according to your needs
Note:
The parameters shown in these figures were used for testing
6. At this stage, the default keyboard is English. If you must use a keyboard other than the default
keyboard (for example: French or German), you must first change the keyboard type before
configuring the OmniPCX Enterprise:
a) Enter the root credentials (login and password)
b) Enter the kbdconfig command
c) Use the up and down arrows to select the corresponding keyboard, and press the space bar to
7. From the same root session, enter the netadmin command and configure the IP Address of the
OmniPCX Enterprise virtual machine, netmask and default router:
• When netadmin configuration is completed, you can access the OmniPCX Enterprise virtual
machine from the network.
• OmniPCX Enterprise virtual machine configuration is similar to standard OmniPCX Enterprise
configuration, except for the license file. The license used for the OmniPCX Enterprise virtual
machine must be the license associated to the FlexLM server licence file, or a specific license
request is necessary (.swk file).
• Before you configure the FlexLM server on the OmniPCX Enterprise virtual machine, ensure that
the role of the OmniPCX Enterprise virtual machine is main.
3.5.3 Installing the VMware tools on the OmniPCX Enterprise virtual machine
For releases prior to R12, do not install VMware tools manually, as before R12, the OmniPCX
Enterprise uses a customized Linux distribution for which there is no official version of VMware tools.
For releases higher than or equal to R12, it is mandatory to install the VMware tools in the OmniPCX
Enterprise virtual machine. For details on VMware tools installation, refer to the TC2432 available on
the Alcatel-Lucent Enterprise Business Portal: https://businessportal.al-enterprise.com/TC2432en.
Caution:
As of R12, the OmniPCX Enterprise delivery includes a compatible version of VMware tools (open-vm-
tools). However, ALE recommends to check whether VMware provides a more up-to-date version of
VMware tools.
3.5.4 Installing the FLexLM Server for VMware ESXi

3.5.4.1 Overview
Licensing with a FlexLM server is used by the OmniPCX Enterprise in the following cases:
• RSI licenses
• In a virtualized CS (e.g. BiCS or OpenTouch), instead of checking the CPU-ID against the content of
the software.mao file, a product-ID is acquired by the FlexLM server. There is only one product-ID
per OmniPCX Enterprise
A FlexLM server can be used by several OmniPCX Enterprise servers.
In earlier OmniPCX Enterprise versions, each OmniPCX Enterprise could only address one FlexLM
server. As of R11.2, if the FlexLM server shuts down (crash, disconnection, or any other reason), the
OmniPCX Enterprise can continue to work for five days, before raising a panic flag. When a panic flag
is raised on the OmniPCX Enterprise, the configuration and services become highly restricted.
To fulfill high availability requirements, current OmniPCX Enterprise versions can rely on a second
FlexLM server.
3.5.4.2 Basic description

In a configuration with one FlexLM server, when the OmniPCX Enterprise requests checkout of
licenses, it sends checkout requests to the FlexLM server. Once the checkout is done, the OmniPCX
Enterprise checks the connection with the FlexLM server by sending heartbeats.
However, the OmniPCX Enterprise can lose the connection with the FlexLM server (for example,
FlexLM server crash) during checkout attempt or heartbeats. In this case, a panic flag can be raised:
• Immediately after checkout failure
• As of R11.2, five days after the heartbeat connection is lost
In a configuration with FlexLM server redundancy, if the connection is lost, the OmniPCX Enterprise
switches between the two FlexLM servers for five days until it reaches a FlexLM server. If no checkout
is performed after five days, the panic flag is raised.
3.5.4.3 Services provided

In a high availability configuration, the OmniPCX Enterprise provides the following services:
• FlexLM server redundancy: to rely on a second FlexLM server when the first FlexLM server is
unavailable. FlexLM servers are independent. They each provide the same product-ID
• OmniPCX Enterprise redundancy: when the main OmniPCX Enterprise shuts down, the stand-by
OmniPCX Enterprise (which becomes new main) ensures the licensing service with the FlexLM
server (checkouts, heartbeats)
• Defense: to prevent fraud attempts
3.5.4.4 Prerequisites
Before installation you must have:
• a physical dongle from Aladin Knowledge Systems (type Hasp 4MI USB memory key Part:#FLEXid-
ALA-7200): this dongle defines the FLEX-ID used to authenticate the OmniPCX Enterprise license
file.
• The FlexLM Server DVD: this DVD contains the pre-installed license server in ISO format, including
the OVF FlexLM VM (OVF file to extract from ISO)
• The FlexLM server licence file (extension .ice): license for the FlexLM server for the dongle
• The OmniPCX Enterprise license file (extension .swk). This license file is for the OmniPCX
Enterprise which is virtualized
Note:
All these are required for the installation. If any one of the items is not available, stop the procedure.
3.5.4.5 Installation of OVF FlexLM server on the VMware ESXi server

Ensure that the OVF template contains the following files:
• <VM Name>.mf
• <VM Name>.ovf
• <VM Name>.vmdk
3.5.4.5.1 Deployment of the OVF template

1. From the vSphere client select File > Deploy OVF Template
2. Click Browse to navigate and select the location of the OVF file
Figure 3.20: Source selection page example
3. Click Next
Figure 3.21: VMFlexServer detail page example
Figure 3.22: Name and location page example
Figure 3.23: Disk format page example
4. Click Finish to proceed
The FlexLM Server window is displayed to show that deployment is in progress
Figure 3.25: Installation successful dialog box example
When the virtual machine has been successfully created it is displayed to the left of the vSphere
client
Figure 3.26: Virtual machine list example
5. Power on the OVF FlexLM Server. Right Click the FlexLM server to display the contextual menu
and select Power > Power On
The FlexLM server starts booting.
Figure 3.27: FlexLM start example
6. Select the keyboard type (US English in this example)
Figure 3.28: Keyboard selection page example
7. Enter login credentials

• The default username is root
• The default password is letacla
8. Enter a new password for root
9. When prompted, enter the hostname of the FlexLM server, and validate
10. In the window which opens, select Edit a connection
11. Select eth0, and select <Edit...>
12. Select Manual for type of initialization
13. Validate the <Show> option
14. Enter the IP addressing:

• IP Address indicating the netmask size, for example: 192.168.201.144/24
• Default gateway IP address
• DNS server IP Address
Verify that Automatically connect is selected
15. Select OK to validate
16. Select Quit
17. According to your needs, select one of the predefined NTP servers, or add a new one, and validate
18. When prompted, enter the startx command to open the graphical interface
19. Go to Applications > System tools > Settings and click Date & Time
20. Configure time and time zone
21. Confirm your entries
3.5.4.5.2 Dongle installation

The dongle installation procedure can be performed by one of the two methods:
• Use of USB dongle: the dongle is plugged directly in a USB port of the FlexLM server, if a USB port
is available, see below
• Use of USB/IP dongle: the dongle is a USB over IP interface to the FlexLM server, see: [40]
1. Plug the USB dongle on the USB port and right click the VM. Select Edit Settings from the
contextual menu
2. From the Hardware tab, Click Add
Figure 3.29: Virtual Machine properties page example
3. Select the USB Device and click Next
Figure 3.30: Add hardware page example
The USB dongle is detected and is displayed
Figure 3.31: USB device selection page example
4. Click Finish
Figure 3.32: Ready to complete page example
When the USB dongle is detected, it is displayed in the Properties window
Figure 3.33: Virtual Machine properties with USB dongle selected
3.5.4.5.3 License installation

When network configuration is completed, the license server must be configured.
Copy the license file corresponding to the server (the file with extension .ice). This license to use must
match the license file provided with the dongle, ensure you obtain it.
Note:
By default, FTP does not operate on this server. You can copy this file using secure FTP or SCP or from any
media source
• Copy this file to /opt/Alcatel-Lucent/data/licenses
• Restart the FlexLM services: service flexlmd restart
Note:
If the hostname configuration is faulty or the license file is not generated for the attached dongle or the dongle is
not attached, the FlexLM Server does not start.
Logs are available in /opt/Alcatel-Lucent/logs/flexlm/.
Verify the FlexLM logs to ensure that the flexlmd service has been started
Details on the VM-OXE license checkout from the FlexLM server are logged in: /opt/Alcatel-
Lucent/logs/flexlm/flexlm_lmlog.log
You have successfully installed and configured the OVF FlexLM server.
3.5.4.6 Installing one FLexLM server for several virtualized OmniPCX Enterprise servers
• This architecture does not require any specific configuration on the OmniPCX Enterprise servers or
on the FlexLM Server.
• One single dongle is used
• Several license files (.ice extension) must be installed in the FlexLM server
• Several license files (.swk extension) must be installed on each OmniPCX Enterprise server
Once license files have been installed on all servers, restart the FlexLM service or restart the virtual
machine so that licenses are taken into account. Each OmniPCX Enterprise server can then register on
the same FlexLM server.
In case the FlexLM server is duplicated (which implies that two addresses are declared on each
OmniPCX Enterprise server), two dongles are necessary and twice as many .ice licenses must be
installed on the FlexLM servers.
3.5.4.7 FlexLM Server management on the OmniPCX Enterprise

Configure the FlexLM server on the VM-OXE
Navigate to Mgr→system→Licenses→Review/Modify and configure the following parameters
Figure 3.34: Review/Modify Licenses
Note:
Once you have configured the FlexLM server, you need to reboot the VM-OXE to apply modifications
Note:
If no FlexLM server responds after five days, the panic flag is raised on the OmniPCX Enterprise before displaying
Call Installer on telephone sets.
3.5.5 Appendix
3.5.5.1 Export OVF image/template from the VMware ESXi server
You must power off the Virtual Machine to export OVF Template, otherwise the export option will be
disabled.
1. Select the virtual machine to export
2. Power off the selected VM
3. Go to File>Export>Export OVF Template
Figure 3.35: Export OVF template window example
Figure 3.36: Export file example
The virtual machine has been successfully exported via OVF Image/Template
3.5.5.2 Install VM OXE (OVF image) from one ESX towards another ESX
If you have an OVF image/template of a Virtual Machine OmniPCX Enterprise, see: Deploying the KVM
packages on page 35to install.
Otherwise refer the following sections:
• Export OVF image/template from the VMware ESXi server on page 78
• Deploying the KVM packages on page 35
3.6 Communication Server Installation in a Hyper-V Environment

3.6.1 OmniPCX Enterprise virtual machine prerequisites for Hyper-V
The following characteristics are required to successfully run a Hyper-V client on a computer:
• Windows 10 Pro or Enterprise 64 bit Operating System
• A 64 bit processor with Second Level Address Translation (SLAT)
• A minimum of 4 GB of RAM
• Hardware virtualization support at BIOS level
The following characteristics are required to successfully run a Windows Server version on a physical
server:
• A 64 bit processor with the following features:
• Hardware-assisted virtualization. This feature is available on processors including a virtualization
option, specifically processors with Intel Virtualization Technology (Intel VT), or AMD
Virtualization (AMD-V) technology
• Hardware-enforced Data Execution Prevention (DEP). This feature must be enabled.
Specifically, you must enable Intel XD bit (execute disable bit), or AMD NX bit (no execute bit)
• At least 500 GB of hard disk space
The following characteristics are required to install an OmniPCX Enterprise on virtual machine:
• At least 80 GB of hard disk space
• The virtual machine generation must be Generation 1
Important:
Only legacy Network Adapter must be used for Hyper-V installation.
3.6.2 Installing Windows Server on the server

The following procedure describes the Windows Server 2016/2019 installation on a LENEVO-IBM
x3250 M4 Server.
To install Windows Server, complete the following steps:
1. Insert the Windows Server bootable CD/DVD media into an available CD/DVD drive
2. Power on the server and press F12 when the message F12 One Time Boot Device is
displayed at the bottom right of the screen
3. When the Boot Devices Manager is displayed on screen, select your bootable CD/DVD device
and press Enter
4. When the message Press any key to boot from cd or dvd is displayed on screen, press
any key to launch the installation process from the Windows Server CD/DVD media.
The files are copied from the DVD media. This operation may take a few minutes.
5. In the Windows setup window, make the following selections:

1. In the Language to install field, use the drop-down menu to select English (United
States) (or other language preference)
2. In the Time and currency format field, use the drop-down menu to select Other time &
currency as preference
3. In the Keyboard or input method field, use the drop-down menu to select US (or other
preference)
6. Click Next
7. Click Install Now
8. Enter the Product Key and click Next to activate Windows
9. Select your Windows Server version
10. Click Next
11. Scroll down and read the license agreement
12. Select I accept the license terms and click Next
13. Select Custom: Install Windows only (Advanced)
14. When the Windows Server setup displays all hard disk storage available on the server, select one of
the following options to choose or create a drive partition on which the Windows Server must be
installed:
• Allow setup to create a partition: to partition the entire hard disk as one primary
partition, highlight Disk0 unallocated space for the hard disk drive on which you want to install
Windows Server, and click Next
• Create a partition: to create a partition, highlight Disk0 unallocated space for the hard disk
drive on which the Windows Server must be installed. Click Drive options then New.
You are prompted to define the available space to allocate to the partition. Type the amount of
space (in MB). Click Apply then Next.
• Delete: use this option to delete a previous partition before creating a new partition using any of
the methods described above.
15. Set up the format of the selected partition and copies the applicable files to the drive partition. This
process takes 30-45 minutes and restarts the system twice.
16. When process is complete, you are prompted to create an administrator password before logging
on. Enter the password twice and click Finish. Press Ctrl + Alt + Delete to sign in using the
password you just created.
17. After you log on as administrator, the Server Manager window starts. Use the Server Manager
to name your system, configure the network setups and other basic setup tasks.
3.6.3 Configuring the Hyper-V client on the computer

1. Power on the computer and access the BIOS settings
2. Ensure that the hardware virtualization support is turned on in the BIOS settings
The Virtualization Technology field must be set to Enabled in the System Security
settings (Security tab)
3. Save the BIOS settings and boot up the computer
4. Once your computer is started, click the search icon (magnified glass) on the taskbar, type Turn
windows features on or off, then select this item
The Turn windows features on or off window opens
5. In the feature list, select and enable Hyper-V
6. If Hyper-V was not previously enabled, reboot the computer to apply change
Note:
As best practice, configure networking for the Hyper-V environment to support external network connections.
Ensure that a virtual switch has been created and is operational.
3.6.4 Launching and configuring the Hyper-V Manager on the computer

1. Click the search icon (magnified glass) on the taskbar, type Hyper-V Manager, then select this
item
The Hyper-V Manager window opens
Note:
Right click Hyper-V Manager to pin it to the taskbar.
2. To connect to the server, perform the following operations:
1. Select: Action > Connect to Server...
2. Click Another computer and select Browse...
3. Select Advanced and Find Now to select the corresponding server in the available list
Note:
The Hyper-V Manager does not allow to select the server via its IP address or name.
The Hyper-V Manager connects to the server and the server name (for example: HYPERVIBM3) is
displayed on screen
3. In the Actions pane, select Virtual Switch Manager...
4. Ensure that External is highlighted, then click Create Virtual Switch

5. If more than one NIC is present, ensure that the proper NIC is selected for the VM external network
connections
3.6.5 Generating the OmniPCX Enterprise virtual machine via S.O.T.

Note:
Important:
11. Click Next

Field Meaning
ning


Note:
Field Meaning
Note:
13. Click Next


3.6.6 Deploying the OmniPCX Enterprise virtual machine on a Hyper-V physical

server
To deploy the OmniPCX Enterprise virtual machine on a Hyper-V physical server:

1. From the management computer, open the Hyper-V Manager
The Hyper-V Manager access differs according to the Windows OS version deployed on the
management computer. For more details, refer to the manufacturer documentation.
2. Power on the virtual machine using any of the following:
• Right click the virtual machine and select Start
• Select the virtual machine and select Start in the Actions vertical bar
The virtual machine performs a network boot, connects to the S.O.T. and loads the OmniPCX
Enterprise software. The OmniPCX Enterprise installation automatically starts on the virtual
machine.
Monitor the progress of the OmniPCX Enterprise installation on the console of the Hyper-V
Manager.
3. Select Yes to reboot the OmniPCX Enterprise after the successful installation
Note:
To select the Yes option, make a single mouse click on the console window and use the arrow keys to navigate
to Yes. Press Enter
4. Secure the OmniPCX Enterprise passwords according to your needs
Note:
The parameters shown in these figures were used for testing
5. At this stage, the default keyboard is English. If you must use a keyboard other than the default
keyboard (for example: French or German), you must first change the keyboard type before
configuring the OmniPCX Enterprise:
a) Enter the root credentials (login and password)
b) Enter the kbdconfig command
c) Use the up and down arrows to select the corresponding keyboard, and press the space bar to
6. From the same root session, enter the netadmin command and configure the IP Address of the
OmniPCX Enterprise virtual machine, netmask and default router:
• When netadmin configuration is completed, you can access the OmniPCX Enterprise virtual
machine from the network.
• OmniPCX Enterprise virtual machine configuration is similar to standard OmniPCX Enterprise
configuration, except for the license file. The license used for the OmniPCX Enterprise virtual
machine must be the license associated to the FlexLM server licence file, or a specific license
request is necessary (.swk file).
• Before you configure the FlexLM server on the OmniPCX Enterprise virtual machine, ensure that
the role of the OmniPCX Enterprise virtual machine is main.
3.6.7 Configuring QoS for Hyper-V
Ports in the switch

tagged to the VLAN
Hyper-V IP phone tagged

VLAN enabled server with VLAN
computer
Hyper-V v-Switch
OXE VM OXE-MS VM
(VLAN enabled (VLAN enabled
in access mode) in trunk mode)
3.6.7.1 PowerShell commands for virtual LAN configuration

The following PowerShell commands allow to configure the virtual LAN settings to route the traffic
through a virtual network adapter:
Syntax Description
Get-VMNetworkAdapterVlan This cmdlet is used to get the virtual network
adapters of the specified virtual machine (see:
Verifying the virtual LAN configuration of the
virtual machine on page 95).
Set-VMNetworkAdapterVlan -VMname This cmdlet is used to configure traffic through

"<OmniPCX Enterprise virtual machine Access mode (for OmniPCX Enterprise virtual
name>" -Access -VlanId <VLAN number> machine) (see: Configuring QoS on the OmniPCX
Enterprise on page 92).
Set-VMNetworkAdapterVlan -VMname > This cmdlet is used to configure traffic through
"<OXE-MS virtual machine name>" - trunk mode (for OXE-MS virtual machine) (see:
Trunk -AllowedVlanIdList 1-4094 - Configuring QoS on the OXE-MS on page 94).
NativeVlanId <VLAN number>
Set-VMNetworkAdapterVlan -VMname This cmdlet is used to untag a virtual LAN
"<virtual machine name>" -Untagged settings.
3.6.7.2 Configuring QoS on OmniPCX Enterprise virtual machine
3.6.7.2.1 Configuring QoS on the host server

1. From the Hyper-V Manager window, configure the legacy network adapter in the virtual machine
settings:
1. Right click the virtual machine and select Settings
2. Select New hardware and add Legacy Network Adapter to the virtual machine
3. In the Hardware group, select Legacy Network Adapter and use the drop-down menu to
select the virtual switch configured in Launching and configuring the Hyper-V Manager on the
computer on page 82
4. Select VLAN ID and enter a VLAN identifier

This allows any traffic in the allowed VLAN list to be sent or received by the VLAN.
Figure 3.41: Example of the legacy network adapter configuration
2. Set the VLAN identifier to the Access mode using PowerShell command:
1. Click the Windows start button or perform the following operations:
1. Press Ctrl + Alt + Del
2. Select Open Task Manager
3. Select File > New task
2. Enter PowerShell
3. Enter the following PowerShell command:
Example:
PS C:\Windows\system32> “Set-VMNetworkAdapterVlan -VMname "MUL*8B" -Access -VlanId 30”
where:
• MUL*8B is the name of OmniPCX Enterprise virtual machine.
• 30 is the VLAN number set in the legacy network adapter.
3.6.7.2.2 Configuring QoS on the OmniPCX Enterprise

1. Log in to the OmniPCX Enterprise
2. Run the netadmin -m command
3. Select 14. 'VLan configuration' > 2. 'VLan feature', then activate the 802.1p/Q
tagging and configure the VLAN number
Example:
VLan Setup update
=================
Do you want to activate 802.1p/q frame tagging (y/n default is 'n') ? y
Enter the VLan ID to use (0-4094, default is 0): 30
Caution:
Enabling or modifying VLAN number may result in loss of the network, this must therefore be done via
a V24 port and not via telnet.
4. In a duplicated configuration, repeat the operation on the second OmniPCX Enterprise
Caution:
Enable or modify the VLAN number manually on both OmniPCX Enterprises. The Copy Setup of
netadmin must not be used.
5. Configure the priority level via the OmniPCX Enterprise configuration tool (see: Configuring
802.1p/Q parameters in IP QoS COS on page 95)
Caution:
If 802.1p/Q is not activated via netadmin, the priority level management in the IP Quality of Service
COS is not taken into account.
3.6.7.3 Configuring QoS on OXE-MS virtual machine
3.6.7.3.1 Configuring QoS on the host server

1. From the Hyper-V Manager window, configure the legacy network adapter in the virtual machine
settings:
1. Right click the virtual machine and select Settings
2. Select New hardware and add Legacy Network Adapter to the virtual machine
3. In the Hardware group, select Legacy Network Adapter and use the drop-down menu to
select the virtual switch configured in Launching and configuring the Hyper-V Manager on the
computer on page 82
4. Select VLAN ID and enter a VLAN identifier
This allows any traffic in the allowed VLAN list to be sent or received by the VLAN.
Figure 3.42: Example of the legacy network adapter configuration
2. Set the VLAN identifier to the trunk mode using PowerShell command:
2. Enter PowerShell
Example:
PS C:\Windows\system32> “Set-VMNetworkAdapterVlan -VMname "OMSVM" -Trunk -
AllowedVlanIdList 1-4094 -NativeVlanId 30”
where:
• OMSVM is the name of OmniPCX Enterprise virtual machine.
• 30 is the VLAN number set in the legacy network adapter.
3.6.7.3.2 Configuring QoS on the OXE-MS

1. Log in to the OXE-MS as root
2. Run the omsconfig command
3. Select 4. IP QoS menu, then 2. Change vlan id, and enter the VLAN number
Example:
Enter new VLan ID (0<vlan<=4094): 30
4. Select 4. IP QoS menu, then 4. Change user priority, and configure the priority level
Note:
The priority level configuration can also be performed from the OmniPCX Enterprise (see: Configuring
802.1p/Q parameters in IP QoS COS on page 95).
5. Save and reboot the OXE-MS
3.6.7.4 Configuring QoS on OST virtual machine
3.6.7.4.1 Configuring QoS on Hyper-V Host

• Set the virtual network adapter for OST VM to Network Adapter
• Set the VLAN identifier to the trunk mode using PowerShell command:
2. Enter PowerShell
Example:
PS C:\Windows\system32> “Set-VMNetworkAdapterVlan -VMname "OST" -Trunk -
AllowedVlanIdList 1-4094 -NativeVlanId 0”
where OST is the name of OST virtual machine.
3.6.7.4.2 Configuring QoS on the OST

VLAN number management must be performed directly on the OST before start-up:
• Log in to the OST as root
• Run the ostconfig command
• Select 9. IP QoS menu, then 2. Change vlan id and enter new VLAN Id
Example:
Enter new VLan ID (0<vlan<=4094): 30
• If necessary select 4. Change user priority, and then reboot the OST
Note:
The priority level configuration can also be performed from the OmniPCX Enterprise (see: Configuring 802.1p/Q
parameters in IP QoS COS on page 95).
3.6.7.5 Configuring QoS on IP phones

The VLAN number can be configured either manually on IP phones (via the MMI), or automatically
through DHCP or LLDP. The priority number is not configured via the set MMI. It must be configured on
the OmniPCX Enterprise.
For details on VLAN number and priority level configuration for IP phones, refer to the section
802.1p/Q configuration for IP Devices of document [7].
3.6.7.6 Configuring 802.1p/Q parameters in IP QoS COS

The 802.1p/Q parameters (VLAN number and priority level) must be configured in an IP Quality of
Service COS used by the OmniPCX Enterprise and also remote devices (IP phones and OXE-MS),
when they are initialized.
1. Open the OmniPCX Enterprise configuration tool, and select: IP > IP Quality Of Service COS
2. Review/modify the following attributes:
IP QoS COS Enter an IP QoS COS number (between 0 and 15)
802.1Q Used Select Yes to activate 802.1Q tagging
802.1p Priority Enter the level of priority to assign to datagrams using
the access. Priority level is a number between 0 and 7.
Priority 0 is the lowest priority. This value must be
specified by the person in charge of the customer
network
VLAN ID Enter the virtual LAN network identifier. Entering "0"

disables the VLAN mechanism. This value must be
specified by the person in charge of the customer
network
3.6.7.7 Verifying the virtual LAN configuration of the virtual machine

2. Enter PowerShell
3. Enter the Get-VMNetworkAdapterVlan PowerShell command:
Example:
This PowerShell command gets the virtual LAN configured on all the virtual network adapters of the
specified virtual machine.
3.6.7.8 Capturing and displaying VLAN tag

Use the tcpdump tool to verify the incoming and outgoing traffic and see if there are VLAN tag.
1. Log in to the OmniPCX Enterprise as root
2. Enter the tcpdump tool with the -e and VLAN options
This displays details of the VLAN header as displayed in bold below.
Example:
[root@Centos7 ~]# tcpdump -i eth0 -e
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:29:15.280482 00:15:5d:16:be:6f (oui Unknown) > 18:a9:05:19:ae:85 (oui Unknown), ethertype
802.1Q (0x8100), length 254: vlan 30, p 0, ethertype IPv4, 172.15.15.87.ssh >
172.15.15.178.49627: Flags [P.], seq 1715129129:1715129325, ack 1115062799, win 212, length
196
3.6.8 Configuring virtual machine Live Migration in Hyper-V

The figure below illustrates the network and storage configuration of Live Migration in Hyper-V.
1. Make sure to have a domain controller and the servers added to the domain.
2. Install Failover Clustering and Multipath I/O features, along with the Hyper-V role on the
two servers.
3. Configure network interfaces on each server to make sure that synchronization and iSCSI/StarWind
Heartbeat interfaces are in different subnetworks and connected according to the network diagram
above. In this figure, 10.10.20.xx subnet is used for iSCSI/StarWind Heartbeat traffic, while
10.10.10.xx subnet is used for the Synchronization traffic.
Note:
Additional network connections may be necessary, depending on the cluster setup and application requirements.
3.6.8.1 Configuring the network adapter settings

This operation must be performed on the two host servers:
1. Open a command prompt with administration rights

2. Type sconfig.cmd and press Enter
3. Select option 7, and enable remote connection

4. Select option 1, and address the server to the domain
5. Select option 8, and configure the settings of network adapters:
1. Enter the network adapter index
2. Select option 1 to set the IP address of the selected network adapter
3. Select option 2 to set the DNS server settings
4. Select option 4 to return to the main menu
The network adapter settings can also be modified using PowerShell command:
1. Click the Windows start button and enter PowerShell
2. Enter the Get-NetAdapter command
3. Configure the settings of network adapters. For example, to change the name and set the static IP
address for Heartbeat/iSCSI and Synchronization channel, run the following PowerShell
commands:
Get-NetAdapter “Ethernet3” | Rename-NetAdapter –NewName “Sync”
Get-NetAdapter “Sync” | New-NetIPAddress –IPAddress 10.10.10.1 –PrefixLength 24
Get-NetAdapter “Ethernet4” | Rename-NetAdapter –NewName “iSCSI”
Get-NetAdapter “iSCSI” | New-NetIPAddress –IPAddress 10.10.20.1 –PrefixLength 24
Note:
The corresponding IP addresses must be configured on the partner server.
3.6.8.2 Creating a Virtual Switch

To create a virtual switch on the management interface, launch the following PowerShell command:
New-VMSwitch –Name “vSwitch” –NetAdapterName “VLAN_64”
The Virtual Switch can also be created using the Hyper-V Manager (see: Launching and configuring
the Hyper-V Manager on the computer on page 82).
Note:
The Virtual Switch name must be the same on the two servers.
3.6.8.3 Disabling firewall

To disable firewall, launch the following PowerShell command on each server:
Get-NetFirewallProfile | Set-NetFirewallProfile –Enabled False
3.6.8.4 Installing necessary roles and features

To install Failover Clustering and Multipath I/O features, launch the following PowerShell
commands on each server:
Get-NetFirewallProfile | Set-NetFirewallProfile –Enabled False
Install-WindowsFeature Failover-Clustering –IncludeAllSubFeature –Restart
Enable-WindowsOptionalFeature –Online –FeatureName MultiPathIO
Enable-MSDSMAutomaticClaim –BusType iSCSI
Any storage array intended to be used by StarWind Virtual SAN for storing virtual disk images must
meet the following requirements:
• Initialized as GPT
• Have a single NTFS-formatted partition
• Have a drive letter assigned
3.6.8.5 Installing StarWind Virtual SAN

The StarWind Virtual SAN must be installed on the two servers.
To install the StarWind Virtual SAN on a server:
1. Download the StarWind Virtual VSAN setup file from the StarWind website:
https://www.starwindsoftware.com/starwind-virtual-san
2. Copy the StarWind Virtual VSAN setup file on the server where the StarWind Virtual SAN or one of
its components needs to be installed
3. Launch the StarWind Virtual VSAN setup file
The wizard welcome page is displayed.
4. Click Next
The license agreement page is displayed.
5. Read and accept the agreement, and click Next
An information page is displayed.
This page provides information on the new features and improvements. Text highlighted in red
indicates warnings for users who are updating existing software installations.
6. Read carefully these information and click Next
The destination folder page is displayed.
7. If necessary, click the Browse button to modify the installation path, then click Next
The component selection page is displayed.

Note:
This installation type is designed for GUI-less OS editions. The StarWind service is the “core” of the software. It
can create iSCSI targets as well as share virtual and physical devices. The service can be operated by the
StarWind Management Console from any Windows computer or virtual machine in the network where the
StarWind Management Console is installed, or using the Web Client of StarWind Management Console.
8. Select the required deployment scenario for StarWind VSAN, and click Next
9. Click the Browse button to select the program shortcut location in the start menu folder, and click
Next
10. Select the appropriate option for license key entry, and click Next
11. Click the Browse button to locate the license file, and click Next
12. Review the licensing information, and click Next
13. Verify the installation settings. Click Back to make any changes, or click Install
14. Click Finish to close the wizard

To manage StarWind Virtual SAN deployment on the OS edition with no GUI enabled, StarWind
Management Console must be installed on a computer running the GUI-enabled OS.
Note:
In order to allow iSCSI Initiators to discover all StarWind Virtual SAN interfaces, the StarWind configuration file
(StarWind.cfg) must be changed as follows:
1. Stop the StarWind service on the server where it will be edited
2. Locate the StarWind Virtual SAN configuration file (default path: C:\Program Files\StarWind Software
\StarWind\StarWind.cfg), and open it in WordPad with administrator rights
3. Find the <iScsiDiscoveryListInterfaces value=”0”/> string and change the value from 0 to 1 (for
example: <iScsiDiscoveryListInterfaces value=”1”/>)
4. Save the changes and exit WordPad
Once the StarWind.cfg file is modified and saved, the StarWind service can be started again.
3.6.8.6 Configuring shared storage

Note:
The StarWind Management Console cannot be installed on the operating system without GUI. It can be
installed on any GUI-enabled OS, including a desktop version of Windows.
1. Double-click the StarWind tray icon to launch the StarWind Management Console
2. Add the StarWind VSAN server:
1. Click the Add Server button on the control panel
2. Enter the server domain name or IP address, and click OK
3. Repeat this operation for the second server

4. Connect to the servers and specify the path for the storage pool. Press Yes to select the default
location of storage pool. If the storage pool destination needs to be changed, press Choose path…
and select the desired location
Note:
The StarWind Management Console requests the default storage pool location on the server connected
for the first time. Configure the default storage pool to use one of the volumes prepared earlier. All the devices
created through the Add Device wizard will be stored there. If an alternative storage path for StarWind virtual
disks is needed, the Add Device (advanced) menu item can be used.
5. Select the StarWind server on which the device must be created and press the Add Device
(advanced) button on the toolbar, or right click the StarWind server
6. In Add Device Wizard, select Hard Disk Device, and click Next
7. Select Virtual Disk, and click Next
8. Select Create a new Virtual Disk and specify the StarWind device settings (Name,
Location and Size), and click Next
Note:
It is recommended to create a 1 GB device to avoid long synchronization process. Sizing can be extended after
creation.
9. Specify the virtual disk options. Select Use 4096 bytes sector size. May be
incompatible with some clients for Microsoft Windows, and click Next
10. Define the caching policy and size (in GB), and click Next
Note:
The basic recommendation is to assign 1 GB of L1 cache in Write-Back or Write-Through mode per 1 TB
of storage capacity if necessary. The cache size must correspond to the storage working set of the servers.
11. If necessary, define Flash Cache parameters (SSD location and size), and click Next
Note:
The recommended size of the L2 cache is 10% of the initial StarWind device capacity.
12. Specify the target parameters. Enable the Target Name check box to customize the target name,
and click Next
If it is not the case, the name will be automatically generated based on the target alias.
13. Select Create to add a new device and attach it to the target, then click Close to finish working
with the wizard
14. Right click the device previously created and select Replication Manager
15. In the Replication Manager window, press the Add Replica menu item
16. Select Synchronous "Two-Way" Replication, and click Next

17. Specify the partner server hostname or IP address and its port number, and click Next
The default StarWind management port is 3261. In case any other port needs to be configured,
please type it in the Port Number field.
18. Select the failover strategy for the HA device, and click Next
For the purposes of this document, the Heartbeat failover strategy is used.
19. Select Create new Partner Device, and click Next
20. If necessary, specify the partner device Location and/or modify the target name of the device, and
click Next
21. Click Change Network Settings to select the Synchronization and Heartbeat networks for the
HA device
22. Specify the interfaces for Synchronization and Heartbeat, and click OK
Note:
It is recommended to configure the Heartbeat and iSCSI channels (in this document 10.10.10.xx and
10.10.20.xx) on the same interfaces to avoid the split-brain issue. If the Synchronization and Heartbeat
interfaces are located on the same network adapter, it is recommended to assign one more Heartbeat interface
to a separate adapter.
23. Click Next
24. Select Synchronize from existing Device for the partner device initialization mode, and
click Next
25. Click Create Replica, and click Close to exit the wizard
The added device appears in the StarWind Management Console.
26. Repeat the HA device creation steps for any virtual disks that will be used as Cluster Shared
Volumes (CSV) further. Once all the devices are created, they are displayed in the StarWind
Management Console as following:
3.6.8.7 Extending StarWind device sizing

1. From the StarWind Management Console home page, right click the target StarWind device
and select Extend Size of HA (High Availability) Device...
2. Extend the amount of space for this device and select Extend
After extension is completed, the new size of the StarWind HA device appears in the StarWind
Management Console as follows:
3.6.8.8 Discovering target portals

This part describes how to connect the previously created disks which need to be added to the cluster
further.
1. Open a CMD window and enter the iscsicpl command to launch the Microsoft iSCSI
Initiator
Note:
A dialog box may open if the Microsoft iSCSI is not running. In this case, click Yes to start the service now.
The iSCSI Initiator Properties window is displayed.

2. Select the Discover tab
3. Click the Discover Portal button, and enter 127.0.0.1 in the IP address or DNS name
4. Click the Advanced button

5. In the General tab, complete the following fields:
• Local adapter: select Microsoft iSCSI Initiator
• Initiator IP: select Default
6. Confirm your actions to complete the target portal discovery

7. Select the Discover Portal tab again, and specify the iSCSI interface IP address of the partner
server that will be used to connect the StarWind provisioned targets
8. Click the Advanced button

• Initiator IP: select the IP address in the same subnet as the IP address of the partner
server configured in the previous step
10. Confirm your actions to complete the target portal discovery

All target portals are added on the first server.
Go through the target portals discovery steps on the partner server.
3.6.8.9 Connecting targets

1. From the iSCSI Initiator Properties window (see: Discovering target portals on page 120),
select the Targets tab
The previously created targets are listed in the Discovered targets section.
Note:
If the created targets are not listed, check the firewall settings of the StarWind server as well as the list of
networks served by the StarWind server (go to: StarWind Management Console > Configuration >
Network).
Alternatively, check the Access Rights tab on a corresponding StarWind server in the StarWind
Management Console for any restrictions implemented.
2. Select the witness target available from the local server, and click Connect
3. Enable all the check boxes, and click Advanced

• Target portal IP: select 127.0.0.1
Note:
It is recommended to connect the witness device using the loopback IP address (127.0.0.1) only. Do not
connect the target to the witness device from the StarWind partner server.
5. Validate your modifications
6. Select the CSV target available from the local server, and click Connect

• Target portal IP: select 127.0.0.1

10. In the Targets tab, select the partner target from the other StarWind server, and click Connect

• Initiator IP: select the IP address of the host iSCSI link
• Target portal IP: select the corresponding partner’s IP address from the same subnet

14. Repeat the steps above for the remaining HA device targets. The result must be similar to that of
the figure below
15. Repeat the steps described in this part on another StarWind server, specifying corresponding local
and data channel IP addresses. The result must be similar to that of the figure below
3.6.8.10 Configuring multipath

Note:
It is recommended to configure other MPIO policies depending on iSCSI channel throughput:
• For 1 Gbps iSCSI channel throughput, it is recommended to set Failover Only or Least Queue Depth
MPIO load balancing policy.
• For 10 Gbps iSCSI channel throughput, it is recommended to set Round Robin or Least Queue Depth
MPIO load balancing policy.
1. From the iSCSI Initiator Properties window (see: Discovering target portals on page 120),
select the Targets tab
2. Configure the MPIO policy for each target (except the witness target) with the load balance policy
of your choice. Select the target located on the local server, and click the Devices button
3. Click the MPIO button in the Devices page

4. Select the appropriate Load balance policy in the device details
5. For the witness target, set the Load balance policy to Failover Only
6. Repeat the steps above for configuring the MPIO policy for each remaining device on the current
server and on the partner server
Note:
In case the Failover Only MPIO policy is used, verify that the local path (127.0.0.1) is set to Active, while the
partner connection is set to Standby.
3.6.8.11 Configuring StarWind disks on servers

Use the DISKPART command to initialize the disks and create the partitions on servers. To create a
cluster, the disks must be visible on the two servers.
1. Open a CMD window and enter the DISKPART command
2. Enter your commands in the following order:
1. List disk
2. select disk X, where X is the number of the disk to be processed
3. Online disk
4. Clean
5. attributes disk clear readonly
6. convert GPT
7. create partition primary

8. format fs=ntfs label=X quick, where X is the name of the volume
Do not assign any letter for the cluster disks.
Note:
It is recommended to initialize the disks as GPT.
3. Repeat these operations on the partner server
3.6.8.12 Creating a cluster

Note:
To avoid issues during the cluster configuration validation, it is recommended to install the latest Microsoft updates
on each server.
1. Open the Failover Cluster Manager using the desktop version of Windows or a different GUI-
based Windows Server
2. Select Create Cluster in the Actions section of Failover Cluster Manager
3. Specify the servers to be added to the cluster, and click Next
4. Validate configuration by performing the cluster validation tests: select Yes and Run all tests
(recommended), then click Next
5. Specify the cluster name, and click Next
6. Make sure that all settings are correct, then click Next
If necessary, use the Previous button to make any changes.
Note:
If the Add all eligible storage to the cluster check box is enabled, the wizard will try to
automatically add all disks to the cluster. The smallest device will be assigned as the witness. It is
recommended to disable this option before clicking Next, and add witness manually.
Upon completion of the cluster creation, the system displays a report with the detailed information that can be
checked by clicking the View Report button.
3.6.8.13 Adding storage to the cluster

Follow the steps below to add the Cluster Shared Volumes (CSV) that are necessary for working with
Hyper-V virtual machines.
1. From the Failover Cluster Manager, go to: Cluster > Storage > Disks, and click Add
Disk in the Actions panel
2. Select the StarWind disks from the list and click OK
3. To configure the cluster witness disk, right click the Cluster and select More Actions >
Configure Cluster Quorum Settings
4. Select Select the quorum witness, and click Next

5. Select Configure a disk witness, and click Next
6. Select the witness disk to be assigned as the cluster witness disk, then click Next and Finish to
complete the operation
7. From the Failover Cluster Manager, under Disks, right click the Cluster Disk and select
Add to Cluster Shared Volumes
8. If the Cluster Shared Volume (CSV) must be renamed:

1. Right click the disk and select Properties
2. Type the new name of the disk, and click Apply
3. Click OK to exit
9. Perform the steps above if other disks must be configured in the Failover Cluster Manager.
The result (list of disks) must be similar to that of the figure below
3.6.8.14 Configuring cluster network preferences

1. From the Networks section of the Failover Cluster Manager, right click the network from the
list and enter its new name if required, identifying the network by its subnet. Apply the change and
press OK
Caution:
Do not allow cluster network communication on either iSCSI or synchronization network.
2. If required, rename other networks as described above
3. In the Actions tab, click Live Migration Settings

4. Uncheck the Synchronization network only if the iSCSI network is higher to 10 Gbps. Apply the
changes and click OK
3.6.8.15 Post configuration tasks

Once the disks have been added to the Cluster Shared Volumes and the network preferences
configured, highly-available virtual machines can be created on the Cluster Shared Volumes:
1. From the Roles section of the Failover Cluster Manager, go to Virtual Machines > New
Virtual Machine in the Action tab, and complete the wizard
Note:
To avoid unnecessary CSV overhead, configure each CSV to be owned by a different cluster server. This
server must also be the preferred owner of the VMs running on this CSV.
2. If Hyper-V cluster is available, add virtual machines: right click the Roles section and select
Configure Role
3. Click Next
4. Select Virtual Machine in the drop-down list, and click Next
5. Select the target virtual machines, and click Next
6. Click Next for confirmation
7. Click Next for confirmation
3.7 Communication Server installation using the multi-partition

3.7.1 Overview
When a hard drive is formatted, partitions are created to host a second Communication Server release.
This enables an upgraded release to be installed while conserving the current release, phone
unavailability time to be reduced and hard drive handling operations to be avoided.
This operation can be performed with the phone running or shut down. This is of no advantage if the
phone is shut down. There is no impact on users if the phone is running: the file operations performed
on the file-systems do not affect call-handling in any way.
Multi-partitioning can only be used if all partitions are kept at the same size. That is, if the new Linux
release, in the case of a standard installation, formats all partitions to the same size as that of the
release to be upgraded. Otherwise, a standard installation must be performed (with reformatting. The
old release is not kept).
The term "second partition" will generally be used, although, there are, in fact, several duplicated
partitions. The new release to be installed may contain a new Linux release (upgrade or major release)
or only telephone binaries (that is, be a full release or just patches).
The current release is said to be on the "active" partition. The new release is said to be installed on the
"inactive" partition. The version to be installed on inactive partition must be higher or equal to the
current version running on the active partition.
The database is duplicated on one of the inactive partitions. It may be translated with swinst either
before or after the new release takes effect. Translation is also performed automatically when the
phone is started if it was not done previously.
After installation on the inactive partition, the operation for changeover to the new release is referred to
as a "switch". This must be manually triggered. Various operations are then performed on the different
file-systems and a reboot is performed. The new release then switches to the new active partition.
Not all partitions are duplicated. Some remain common whatever the state before or after a switch (see
Structure on page 152).
"Second" partitions cannot be seen by the user. Once the switch to a new release has been performed,
the user does not need to concern himself about file paths or paths for other operations: the syntax
remains identical. All such details remain hidden to the user as a Unix link mechanism is used for this
feature.
The multi-partition method is also used by the "Remote downloading" application (available as from
R5.1). This application can also be used to install a Communication Server (remotely or even locally).
Caution:
R12 is not compatible with earlier releases. You cannot upgrade to R12 without full reinstallation. The
following configuration is not possible: R11.2 or lower installed on the active partition, and R12 or higher
installed on the inactive partition (or vice versa).
3.7.2 Structure
The main common file-systems are:
/dev/hda9 on /usr4 type ext2 (rw) Contains accounting, traffic analysis and various trace
files, etc.
/dev/hda15 on /usr7 type ext2 (rw) Contains voice guides.
Eva partition Contains the 4645 voice mail service.
Duplicated file-systems:
/ Root (hosts the Linux OS)
/usr2 Contains the telephone release.
/usr3 Contains the database.
/var Contains system information used by Linux.
The partition containing the crashdump is not duplicated.
3.7.3 Requirements
The installation of the Communication Server requires:
For more details on S.O.T. installation and startup, see document [45].
• The target OmniPCX Enterprise software release available in iso file, including the full version and
static patches in the dhs3mgr directory. The dhs3mgr can also be uploaded to the S.O.T. as it is
The OmniPCX Enterprise software packages are available on the Business Portal Web Site.
• The network parameters of the customer LAN (subnetwork mask, domain name, gateway IP
address, and DNS IP address)
• The OmniPCX Enterprise license file
• The Communication Server settings (CPU IP address, mtcl credentials, and swinst password)
• The twin Communication Server settings in case of duplicated configuration
If the S.O.T. is used as local storage, the OmniPCX Enterprise software package and license must be
downloaded and declared in the media list on S.O.T. For more details, see document [45].
3.7.4 Deploying an OmniPCX Enterprise software on inactive partition

The S.O.T. allows to install an OmniPCX Enterprise software on an inactive partition with or without
Linux/database copy.
To install an OmniPCX Enterprise software on an inactive partition via S.O.T.:
2. Select the Project for existing products option

1. Select the Update on inactive part. check box
2. Select the Use a clean inactive partition check box if a software version is already
installed on the inactive partition
3. Select the Duplicate Linux data check box if the Linux data of active partition must be
copied on inactive partition after software installation
4. Select the Duplicate OXE data check box if the database of active partition must be copied
on inactive partition after software installation
5. If needed, select the switch partition after update installation check box to
schedule the partition switchover at a specific time.
Note:
A switch back can also be scheduled at a specific day of the week, allowing the old version to be used in
the event of a system reboot (accidental or deliberate).
6. Complete the other fields with the OmniPCX Enterprise settings:
Field Meaning
field must be completed with the main IP address, which is
identical for the two Communication Servers.
In spatial redundancy, this field must be completed with the
main IP addresses of the two Communication Servers.
Note:
Spatial redundancy is a duplicated Communication Server
configuration where the two Communication Servers are on different
IP subnetworks.
OXE license Select the license file

mtcl login and mtcl Complete the fields with the mtcl credentials
password
swinst password enter the password of the swinst account
CPU redundancy (optional) In case of a duplicated configuration, if the installation must
also include the twin Communication Server installation, select
this check box and complete the configuration with the twin
Note:
The Enable autostart field is grayed and cannot be modified.

The Media page opens
8. Select the media on which the OmniPCX Enterprise software package is available:
• If the file is available on an external storage server (NFS or Windows server), and you have
• If the file is available on an external storage server, and you have not already declared the
• If the file has been uploaded to the S.O.T. local storage, select S.O.T. Local storage
10. Select the appropriate file listed on screen and click Declare media
12. Click Next

13. Verify the CPU hostname and software version and click Update
The software installation on the inactive partition starts either immediately, or at the specific time
configured in the switch partition after update installation area.
Click the Details link to monitor the progress of software installation on inactive partition.
3.8 Communication Server software update

3.8.1 Updating a single Communication Server
3.8.1.1 Update overview
A software update consists in installing a new software version on an existing Communication Server.
Two types of software update can be performed on the Communication Server:
• A full update with the complete telephone version
• A partial update with only static or dynamic patches
A full version may include static and dynamic patches. For more details, see: Software organization on
page 17.
A Communication Server includes two partitions allowing to install two different software versions on
the same Communication Server using active and inactive partitions.
To perform an update, you can:
• Download and install the new software version on the active partition of the Communication Server
(partition where the telephone is started):
• For a full update or partial update with static patch, the Communication Server is down during
the entire update process.
• For a partial update with dynamic patch, the Communication Server remains operational
(telephone running).
• Download and install the new software version on the inactive partition, and reboot the
Communication Server on the inactive partition which becomes the active partition (switchover).
The software update on inactive partition allows to reduce the Communication Server downtime to
the reboot time.
A software update can be launched:
• From the Communication Server via swinst. This tool allows you to perform:
• A software update (full update or partial update) on inactive partition
• A partial update with dynamic patch on active or inactive partition
• From the network, via the Software Orchestration Tool (S.O.T.). This tool enables software updates
(full and/or partial updates) on the active or inactive partitions of the Communication Server. The
partition switchover can be scheduled in case of installation on inactive partition.
Only update operation from the Communication Server is described in the rest of the document. For
update operation from the network via S.O.T., see document [39].
3.8.1.2 Software package delivery

The software package used to update the OmniPCX Enterprise must be available in zip or iso format.
The following directory structure (as described in the table below) is recommended to create the
software package in iso or zip format.
Software package ISO file directory structure ZIP file directory structure
Full software package <full path>/ISO/dhs3mgr/n1222 zip -r n1222.zip n1.222.delivery
Full software package + static patch <full path>/ISO/dhs3mgr/n1222 zip –r n12223.zip n1.222.delivery
patch_n1.222.3
<full path>/ISO/dhs3mgr/n12223
Full software package + static + <full path>/ISO/dhs3mgr/n1222 zip –r n12223a.zip n1.222.delivery

dynamic patches patch_n1.222.3 dyn_n1.222.3.a
<full path>/ISO/dhs3mgr/n12223
<full path>/ISO/dhs3mgr/n12223a
Static patch <full path>/ISO/dhs3mgr/n12223 zip –r n12223.zip patch_n1.222.3

Dynamic patch <full path>/ISO/dhs3mgr/n12223a zip –r n12223a.zip dyn_n1.222.3.a
Secured software package:
Full software package <full path>/ISO/dhs3mgr/sn1222 zip –r sn1222.zip sn1.222
Static patch <full path>/ISO/dhs3mgr/sn12223 zip –r sn12223.zip sn1.222.3
Dynamic patch <full path>/ISO/dhs3mgr/ zip –r sn12223a.zip sn1.222.3.a
sn12223a
Note:
For smooth installation, the directory structure described in the table above is recommended while creating
ISO/ZIP software packages. However, the installation tool is able to handle any directory structure format in iso/zip
files.
3.8.1.3 Update operation

1. Copy the software package (full software version, static patch, and/or dynamic patch) on a
computer.
The software package must be available in zip or iso format. For details, see: Software package
delivery on page 158.
2. Use FTP/SFTP to transfer the software package to the /tmpd folder of the Communication Server.
3. From the Communication Server prompt, open a swinst session (see: Access and operation on
page 178).
4. Select: 2 Expert menu > 9 Remote download > 10 Local load as distributor of
ISO image/ZIP file and installation
5. Enter the name of the software package stored in the /tmpd folder.
Note:
A patch can only be installed on the corresponding basic version. For example, the patch m5.200.3 can only be
installed if the basic version on the target partition is m5.200.
6. Enter y to confirm the software download on the Communication Server.
7. After downloading the software, if the software package only includes a dynamic patch, you are
asked to select its installation partition:
• 1 for the ACTIVE version (default)to install a dynamic patch on the active partition
• 2 for the INACTIVE version to install the dynamic patch on the inactive partition
If the software package contains a full version and/or static patch, the installation is directly done on
the inactive partition.
8. Enter y to confirm
A message is displayed when the operation is successful. The software package is loaded and
installed on the target partition of the Communication Server.
9. Press the Enter key to exit the menu.
Additional operations are required after a software update on inactive partition. For details, see:
Additional operations after an update on inactive partition on page 160.
Example of a full software update on the inactive partition:
Please enter the name of the ISO/ZIP file in /tmpd directory (enter for none)
=> OXE-m430218a.iso
Confirm the local load of OXE-m430218a.iso (y/n, default y): y
******* REMOTE LOAD OPERATION *******
BEGIN LOCAL LOADING OPERATION AT

DATE : 09/27/19 TIME : 14:09:43
BEGIN LOADING installation files

*******************************
Getting file /OXE-m430218a.iso/installlinux/rload
BEGIN LOADING LINUX

*******************
Getting file /OXE-m430218a.iso/pcmao/boot_res/bootp/linux/129.000/archive.chk
BEGIN LOADING PACKAGES

**********************
No packages to download in this delivery
BEGIN LOADING export PART OF THE PHONE

**************************************
Restoring flush
OPERATION ENDED CORRECTLY AT

DATE : 09/27/19 TIME : 14:34:25
Select the partition for installation of OXE-m430218a.iso

1 for the ACTIVE version (default)
2 for the INACTIVE version
q to quit
=>2
Confirm the remote load of OXE-m430218a.iso (y/n, default y): y
******* INSTALL DISTRIBUTOR *******

Distrib CPU : kvm23
Client CPU : kvm23
Client country : fr
Retry mode : no
Checking files after installation : no
DATE : 09/20/19 TIME : 19:47:04
Install of OXE-m430218a.iso
The distrib CPU checking is correct
.
.
Common post installation
End of post installation
THE MODULE comm IS CORRECTLY INSTALLED.

Restoring flush

DATE : 09/20/19 TIME : 19:58:02
Press return
3.8.1.4 Additional operations after an update on inactive partition

After an update on inactive partition:
• If a full version has been installed, duplicate the database from the active partition to the inactive
partition:
1. From swinst, return to the initial menu: 2 Expert menu.
2. Select: 2 Expert menu > 3 Cloning & duplicate operations > 2 Partitions
duplication.
3. Select the data to duplicate on the inactive partition, and validate selection.
For more details, see: Partitions Duplication on page 179.
• Perform a partition switchover to reboot the Communication Server on the inactive partition, which
becomes the active partition:
1. From swinst, return to the initial menu: 2 Expert menu.
2. Select: 2 Expert menu > 3 Cloning & duplicate operations > 3 Switch on
inactive version.
3. Follow the instructions on screen.
For more details, see: Switching on Inactive Version on page 180.
The telephone is shut down during the switchover operation.
3.8.2 Updating networked Communication Servers (download/remote installation)

3.8.2.1 Remote download/installation presentation
3.8.2.1.1 Overview
This function allows software updates to be performed for one or more networked Communication
Servers from a single geographical site.
It offers the advantage of using only one swinst menu to perform two different remote actions (transfer
and installation) on several machines (see: Swinst overview on page 177).
Remote transfer and installation can be performed over IP and on ABC network (but not via the public
network).
A Communication Server comprises two partitions. The first partition contains the active version, that
allows the telephone to operate. The second partition contains the inactive version, that will be installed
remotely.
Software updates are transferred to the part common to both partitions.
Installations are performed on the second partition and do not affect updated OmniPCX Enterprise
telephone operation.
Any installation can be performed locally or via the Remote Download swinst menu.
Two types of updates can be performed:
• Full update (the entire telephone version).
• Partial update (of a static or dynamic patch).
Note:
A dynamic patch can be updated on the active partition of the remote Communication Server, without affecting
installation operation.
Important:
Delta update must not be used anymore.
3.8.2.1.2 Terminology
Archive: This is the compact structure of the uninstalled software update, to be transferred or installed
on a Communication Server (see the Software Installation Overview on page 16).
An archive may be:
• A version: full update of the Communication Server software part.
• A static patch: partial software upgrade (binaries).
• A dynamic patch: partial software upgrade.
The archive can be transferred or installed on another Communication Server. This target
Communication Server is called Communication Server Client.
The Communication Server from which the archive is transferred is either a Communication Server
Master or a Communication Server Distributor. During archive transfer, the Communication Server
Client becomes a Master or Distributor.
According to system configuration, a Communication Server Client may become Communication
Server Master. In this case, it transfers (or installs) only one version, one patch, and one dynamic
patch on a Communication Server Client. If transfer is performed from a Communication Server Master
to the Communication Server Client, the new archive overwrites previous versions of the same type of
archive on the Communication Server Client.
According to system configuration, a Communication Server Client may also become Communication
Server Distributor. In this case; it transfers (or installs) one or more versions and/or one or more
patches (static and/or dynamic). If transfer is performed from a Communication Server Distributor to the
Communication Server Client, the new archive does not overwrite previous versions of the same type
of archive.
Example:
Transfer of version e2.401 to a Communication Server Client containing version e1.604. If the Communication
Server by which the transfer transits is Master, the new version, e2.401, overwrites the previous version, e1.604. If
the Communication Server by which the transfer transits is Distributor, both versions e2.401 and e1.604 are
available in the part common to both partitions of the Communication Server Client.
A download consists in loading and installing the content of an archive in the Communication Server
Master/Distributor. The archive download can be performed:
• Locally after transferring the archive (zip or iso format) on the /tmpd directory of the
Communication Server (feature available as of R12.4). After downloading, the archive can be used
to update the Communication Server Master/Distributor (see: Local download on page 166).
• Remotely from a storage server such as another Communication Server (to which the archive has
already been transferred from a PC) (see: Remote download on page 168).
An installation must be performed by a Communication Server. The archive is installed either on
another Communication Server or on the Communication Server initiating installation.
3.8.2.1.3 Requirements
Depending on site configuration and the updates to be performed, the resources required may be
different.
Good knowledge of the client network topology is essential. In all circumstances, the following items
are required.
3.8.2.1.3.1 Hardware
• For local download: A PC equipped with an Ethernet board and connected to the Communication
Server Master/Distributor via the customer network.
• A Communication Server (version higher than e1.604) with a capacity of 8 GB or higher used as
Master/Distributor.
• On OmniPCX 4400 rack: an external hub connected to the CPUx board ensuring the
Communication Server functions.
3.8.2.1.3.2 Software
• For local download: A FTP or SFTP client used to transfer the archive from the PC to the
• One or mores archives (as delivered by Alcatel-Lucent Enterprise).
3.8.2.1.3.3 Connection
The names or IP addresses of the transfer or installation target Communication Servers
(Communication Server Clients) and of the Communication Servers (Master or Distributor) and/or the
PC.
3.8.2.1.4 Operation
To be able to perform remote download, all hosts must be declared (in a secure configuration). Remote
sites are configured via netadmin (see section Routing in [13]).
3.8.2.1.4.1 Transfer
Archive transfer (or download) is the very first operation to perform.
Using the remote or local download feature, the archive is transferred and loaded in the part common
to both versions of a Communication Server.
Communication server
remote
download
Partition Active
n°2 partition
Inactive Active
version version
Part common to
archive transfer over IP
both versions
link
Figure 3.47: Software Transfer to Communication Server
The Remote download menu is then used to transfer the archive from this Communication Server
(which becomes the source: Communication Server Master/Distributor) to another, target,
Communication Server (Communication Server Client) on the network. The Remote load submenu
allows an archive to be transferred to a Communication Server Client without installing it.
Communication Communication
Server Master remote Server Client
download
Inactive Active Inactive Active

version version version version
Part common to Part common to

both versions both versions
Figure 3.48: Software Transfer from Master Communication Server to Client Communication Server
3.8.2.1.4.2 Installation
After transfer, the archive is installed on the inactive version (second partition) of the Communication
Server.
Note:
For a full version, at the end of installation, do not forget to copy the database from the active partition to the
second partition loaded with the new version (see the Partitions Duplication on page 179).
A patch can only be installed on the corresponding basic version. For example, patch f1.500.4 may be
installed if the basic version on the second (inactive) partition is f1.500. If the inactive version is f1.400,
patch f1.500.4 cannot be installed.
remote
installation
Inactive Active
version version
Part common to
both versions
Figure 3.49: Software Installation on the Inactive Partition
The Remote install menu allows an archive present on the common part of another
Communication Server to be installed on the inactive version of a second Communication Server.
Server Master remote Server Client
installation
Inactive Active
Inactive Active version version
version version
Part common to Part common to

both versions both versions
Figure 3.50: Remote Installation
3.8.2.1.4.3 Switch
To implement the full version update or the patch installed on the inactive version, the versions must be
switched. Version switch is a separate menu (see: Switching on Inactive Version on page 180).
version
switch
Inactive Active
version version
Part common to
both versions
Figure 3.51: Partition Switch
After switching the versions, return to the swinst menu to complete installation (and answer the
questions from the application about the type of installation).
Caution:
Do not confuse this switch between active and inactive versions and that of a duplicated Communication
Server (from the Communication Server Main and the Communication Server Stand-by), for more
information, see Communication Server duplication in [1].
As this operation restarts the system, switches should preferably by performed outside busy (high
traffic) periods to avoid disturbing the telephone. The swinst menu allows a switch to be scheduled in
advance for the same day.
3.8.2.1.4.4 A special case: duplicated Communication Server via ABC

Whether it is a transfer or an installation, the procedure operates on an IP/X25 tunnel (declared under
netadmin).
Master/Distributor
IP tunnel
IP tunnel Communication Server Communication Server

ABC Client (Main) Stand-by
Ethernet
Figure 3.52: Remote Installation via ABC Network
When the Communication Server Client tunnel IP address is used, the archive is transferred (or
installed) to the Communication Server Main.
To transfer/install the archive to the Communication Server Stand-by, use the machine physical IP
address (by configuring the route via the netadmin menu).
Caution:
This case must not be used via a non IP ABC-F logical link.
3.8.2.1.4.5 Archive location in a Communication Server

Depending on their types, archives are transferred in the following Communication Server Master/
Distributor directories:
• After a remote download:
• /usr4/ftp/tftpboot/Rload/version for full versions
• /usr4/ftp/tftpboot/Rload/patch for static patches
• /usr4/ftp/tftpboot/Rload/dynpatch for dynamic patches
• After a local download:
• /usr4/ftp/Rload/version for full versions
• /usr4/ftp/Rload/patch for static patches
• /usr4/ftp/Rload/dynpatch for dynamic patches
3.8.2.1.5 Remote download operation using OmniVista 8770

The OmniVista 8770 allows to perform the software update (immediate or scheduled) of many remote
Communication Servers and/or Passive Communication Servers.
For more information on software update using OmniVista 8770, refer to document [43].
3.8.2.2 Operation
3.8.2.2.1 Accessing the swinst menu

• Open a session under the swinst account (see the Swinst overview on page 177).
• Select option 9 Remote download.
ALCATEL BUSINESS SYSTEMS
Remote Download menu Installation FACILITIES 2.20.0
1 Remote install of a client CPU
2 Retry the last remote install operation (if justified)
3 About last remote install (if trace exists)
4 Remote load a CPU as master or distributor
5 Retry the last remote load operation (if justified)
6 About last remote load operation (if trace exists)
7 Cleaning operation on master/distributor CPU
8 Programmed operations
9 Fast Delta programmed operations
10 Local load as distributor of ISO image/ZIP file and installation
Q Go back to previous menu Your choice [1..9, Q]
3.8.2.2.2 Archive download
3.8.2.2.2.1 Local download

1. Copy the archive (full software version, static patch, and/or dynamic patch) on a computer.
The archive must be available in zip or iso format.
2. Use FTP/SFTP to transfer the archive to the /tmpd folder of the Communication Server.
3. From the menu 9 Remote download of swinst (see: Accessing the swinst menu on page 166),
select option 10 Local load as distributor of ISO image/ZIP file and
installation.
4. Enter the name of the archive (iso or zip file) stored in the /tmpd folder.
5. Confirm the archive download and installation on the Communication Server.
A message is displayed when the operation is successful.
6. In case the archive is used to update the Communication Server:

• If the archive contains a full version and/or static patch, the installation is directly done on the
inactive partition.
• If the archive only contains a dynamic patch, select either the menu 1 for the ACTIVE
version (default), or menu 2 for the INACTIVE version to install the archive on the
active or inactive partition.
7. Press the Enter key to exit the menu.
The archive downloaded and installed on this Communication Server (that is Master/distributor) is
available for the software update of remote Communication Servers (see: Remote Installation on
page 169).
Example of local download completed with a software update on the inactive partition:
Please enter the name of the ISO/ZIP file in /tmpd directory (enter for none)
=> OXE-m430218a.iso
Confirm the local load of OXE-m430218a.iso (y/n, default y): y
******* REMOTE LOAD OPERATION *******
BEGIN LOCAL LOADING OPERATION AT

DATE : 09/27/19 TIME : 14:09:43
BEGIN LOADING installation files

*******************************
Getting file /OXE-m430218a.iso/installlinux/rload
BEGIN LOADING LINUX

*******************
Getting file /OXE-m430218a.iso/pcmao/boot_res/bootp/linux/129.000/archive.chk
BEGIN LOADING PACKAGES

**********************
No packages to download in this delivery
:
:
BEGIN LOADING export PART OF THE PHONE

**************************************
Restoring flush

DATE : 09/27/19 TIME : 14:34:25
Select the partition for installation of OXE-m430218a.iso

1 for the ACTIVE version (default)
2 for the INACTIVE version
q to quit
=>2
Confirm the remote load of OXE-m430218a.iso (y/n, default y): y
******* INSTALL DISTRIBUTOR *******

Distrib CPU : kvm23
Client CPU : kvm23
Client country : fr
Retry mode : no
Checking files after installation : no
DATE : 09/20/19 TIME : 19:47:04
Install of OXE-m430218a.iso
The distrib CPU checking is correct
.
.
THE MODULE comm IS CORRECTLY INSTALLED.

Restoring flush

DATE : 09/20/19 TIME : 19:58:02
Press return
3.8.2.2.2.2 Remote download

From the menu 9 Remote download of swinst (see: Accessing the swinst menu on page 166), select
option 4 Remote load a CPU as master or distributor for any new transfer.
Enter the name or IP address of server (return for this CPU, q to quit)
->
Enter the name or IP address of the server, the default server being the Communication Server on
which the remote download process is started.
Example:
Enter the name or IP address of the server
(return for this CPU, q to quit) -> 192.168.4.29
Enter the type of the server
1 Windows server
2 Unix server
3 Call server
q to quit => 1
Enter the name or IP address of the CLIENT CPU
(return for this CPU, q to quit) ->
The Windows server source is : 192.168.4.29

The CLIENT CPU is : oxe
Checking connections
**
The system immediately proposes to download a new version or a patch to the Communication Server
that will be a Master or Distributor.
Remote load of delta ? (y/n q to quit): n
Delta update must not be used anymore.
Remote load of version ? (y/n q to quit) y
With a Windows server, the system asks for the exact version name, before proposing any patch
download.
Enter the name of version (q to quit) =>e2.400
Remote load of patch ? (y/n q to quit) n
Remote load of dynamic patch ? (y/n q to quit) n
The system asks for the installation countries of the machines to be loaded.
Enter the countries

To choose all, press return.
To display the possible choice, enter ?
To end a selection, enter a null line (just enter).
To quit, enter q
=> fr
=>
Then select whether the Communication Server Client is Master or Distributor

1 for a distributor CPU (default)
2 for a master CPU
q to quit
=> 2
Confirm download.
Confirm the remote load of e2.400 (y/n, default y): y
Select the type of checking you want to be performed after download.

Client checking after remote installation
1 for no check (default)
2 for size of files
3 for size and checksum of files
q to quit
=> 3
Installing client CPU ...

In case of failure (connection lost)
As download concerns several modules, in the event that the link is lost between the server and its
client, the number of uninstalled modules is registered and installation can resume from the point at
which it was interrupted.
Select option 5 Retry the last remote load operation (if justified)
If no information has been registered on the Communication Server client, the tool displays:
No retry information is available
Press return
If installation has been successfully completed, the tool displays:

All modules are already installed on 192.168.4.56
Checking previous transfer
Select option 6 About last remote load operation (if trace exists).
When connection is possible, the tool details the inputs and errors noted during the previous operation.
Checking is made on the Communication Server Client.
3.8.2.2.3 Remote Installation

select option 1 Remote install of a client CPU for any new installation. Installation (of the
version, of a patch (static or dynamic) is performed on the Communication Server Client inactive
version. The server must be a Communication Server previously declared as Master or Distributor.
Note:
A dynamic patch (alone) can be installed on the Communication Server active version.
Example:
Enter the name or IP address of the MASTER/DISTRIBUTOR CPU
(return for this CPU, q to quit) -> 192.168.4.56
The MASTER/DISTRIBUTOR CPU is : oxe

The CLIENT CPU is : 192.168.4.56
Please confirm this choice (y/n, default y):y
**
Enter the version to be installed.

Please enter the version (enter for none)
The versions available are the following:
E2.350
E2.400
—>E2.400
Confirm installation of the selected version

Confirm the remote install of E2.400
(y/n, default y):
3.8.2.2.3.1 In case of failure (connection lost)

As installation concerns several modules, in the event that the link is lost between the Communication
Server Master/Distributor and its client, the number of uninstalled modules is registered and installation
can resume from the point at which it was interrupted.
Select option 2 Retry the last remote install operation (if justified)
If no information has been registered on the Communication Server client, the tool displays:
No retry information is available
Press return
If installation has been successfully completed, the tool displays:

All modules are already installed on 192.168.4.56
Note:
Installation of a dynamic patch on the active partition must be resumed via option 1 Remote install of a
client CPU.
3.8.2.2.3.2 Checking the last installation performed

Select option 3 About last remote install (if trace exists). Checking is made on the
Communication Server Client.
Example:
(return for this cpu, q to quit) —>192.168.4.56
the CLIENT CPU is : pabx56
Please confirm this choice (y/n, default y): y
**
Example installation of version E2.400 on a machine in France. Delivery comprises a major Linux 3.0
version, a Linux 3.2 update, and a patch to be installed on a machine in France (country code: fr).
The master or distrib cpu checking is correct
***************************
BEGIN INSTALLATION OF MODULE 3.0...
Secdonde version cleaned
Getting Rload/version /E2.400/linux/3.0from...
Getting the .rpm files from ...
Installing the RPM packages...
Installing the bootp server...
THE MODULE 3.0 IS CORRECTLY INSTALLED

***************************
BEGIN INSTALLATION OF MODULE LINUX...
Checking linux version
Transfer for pkg part in preparation
List of packages...
End of remote copy for pkg part files
Installing ... package

package installed
...
THE MODULE linux IS CORRECTLY INSTALLED

***************************
BEGIN INSTALLATION OF MODULE facil...
List of packages...

package installed
...
THE MODULE facil IS CORRECTLY INSTALLED.
***************************
BEGIN INSTALLATION OF MODULE RPMS...
List of packages...

package installed
...
New LINUX patch 3.2 is correctly installed
THE MODULE RPMS IS CORRECTILY INSTALLED

***************************
BEGIN SINTALLATION OF MODULE fr...
List of packages...
List of operations...
THE MODULE fr IS CORRECTLY INSTALLED
Press return
3.8.2.2.4 Switching versions manually

This option allows the version installed on the inactive partition to be switched to the active partition.
The telephone is shut down during the switch operation.
Return to the initial swinst Expert menu.
Select option 3 Cloning & duplicate operations.
The options offered by the application are listed in the Access and operation on page 178.
3.8.2.2.5 Cleaning a Communication Server Master/Distributor

This option allows any delivery to be removed remotely (or locally) from a Communication Server
Master/Distributor.
Select option 7 Cleaning operation on master/distributor CPU.
Example:
(return for this cpu, q to quit) —>192.168.4.56
The CLIENT CPU is : pabx56

Please confirm this choice (y/n, default y): y
**
Remove version E2.400 (y/n): y
Remove patch E2.400.1 (y/n): y
You are going to remove these deliveries on master/distrib cpu pabx56

version E2.400
patch E2.400.1
Please confirm your action (y/n, default y):

Done
Press return
3.8.2.2.6 Programming a sequence of operations

A sequence is a series of operations required for remote download. It can be programmed in advance
then executed on demand simultaneously with other sequences.
When a sequence is being programmed, the application asks the same questions as for each
individual operation.
Example:
1. Transfer CD-ROM content to a Communication Server.
2. Transfer (or install) the archive to another Communication Server.
3. Transfer (or install) the archive to a third Communication Server via IP tunnel
Communication
1
Server
2 3
programmed
operations ABC
IP tunnel
Server Client Server Client
Figure 3.53: Programming a Remote Download
If connection is impossible, the corresponding sequence is stopped. The next sequence is executed.
The Communication Server Master/ Distributor performing the installation must be permanently
connected.
Select option 8 Programmed operations.
Caution:
If the The job “Execute sequences” is working message is displayed when the menu is opened,
wait for job execution to end before creating or deleting a sequence of operations.
3.8.2.2.6.1 Creating or modifying a sequence

In the 8 Programmed operations option submenu, select option 1 Create/overwrite a
sequence.
If no sequence has been defined, the tool displays:
No sequences
If sequences have been defined, the tool details all the sequences already registered.
Example:
SEQUENCE : 1
-------------
OPERATION : Remote load a cpu as master or distributor
Source name : cdar37
Server type : Call Server
Client CPU : clin13
Version delivery to load : E1.502
Patch delivery to load : no
Dynamic patch to load : no
list of export : fr
type of cpu to load : DISTRI
Client checking after remote installation : no check
SEQUENCE : 2
––––––––––––––––
OPERATION : Remote installation of the client CPU
Master CPU : clin13
Client CPU : clin12
Version delivery to install : E1.502
Patch delivery to install : no patch installation
Dynamic patch to install : no dynamic patch installation
Master checking before remote installation : presence of files
Connection during the remote installation : connected
Entrer the number of sequence to create or overwrite : 1
In the submenu, select the desired type of sequence:
Choose the operation to program

1 Make a remote install of a client CPU
2 Retry a remote installation
3 Edit the log file of a remote installation
4 Load a CPU as master or distributor
5 Retry a remote load
6 Edit the log file of a remote load
—>4
Enter the name or IP address of the server

If you have to use a GATEWAY, enter its name or IP adress

(return for no) ->
Press Enter (for no).

Reminder:
If the operation is not performed via the public network, systematically answer no to any question on GATEWAY.
Some choices can be made while the sequence is being executed instead of programming them in
advance.
Example:
Remote load of version ?
(y/n q for manual choice at execution time)
—> q
3.8.2.2.6.2 Deleting a sequence

In the 8 Programmed operations option submenu, select option 2 Delete a sequence.
The tool lists the sequences already registered, then prompts:
Enter the sequences to delete (blank separated and return)
=>
Enter the numbers of the sequences to delete (separated by the space character).
The tool confirms deletion
Done
Press return
3.8.2.2.6.3 Show existing sequences

In the 8 Programmed operations option submenu, select option 3 List sequences.
3.8.2.2.6.4 Executing one or more sequences

In the 8 Programmed operations option submenu, select option 4 Execute sequences.
Enter the numbers of the sequences to execute (separated by a space) in the order of their execution.
Example:
Enter the sequences to execute (blank separated and return)
=> 1 2
–––––––––––––––––––––––––––––––––
EXECUTE SEQUENCE : 1
–––––––––––––––––––––––––––––––––
**
Installing cpu client ...
Source address : cdar37
Type of source : UNIX
Client cpu : 192.40.103.213
etc.
END OF REMOTE LOADING OPERATION AT
DATE : 03/19/02 TIME : 15:19:32
As soon as this sequence has been executed, the tool immediately starts execution of the next
sequence.
–––––––––––––––––––––––––––––––––
EXECUTE SEQUENCE : 2
–––––––––––––––––––––––––––––––––
*
Installing cpu client ...

The master or distrib cpu checking is correct
etc.
THE MODULE fr IS CORRECTLY INSTALLED.
–––––––––––––––––––––––––––––––––
PROGRAMMED EXECUTION ENDED
–––––––––––––––––––––––––––––––––
Press return
3.8.2.2.6.5 Checking connections

This operation is particularly useful after creating a sequence to check the status of the connection
between the server and the client. It triggers the traceroute command, that details routing through
the various hosts, including routers and gateways.
In the 8 Programmed operations option submenu, select option 5 Check connections.
Example:
Enter the sequences to check (blank separated and return)
=> 1 2
–––––––––––––––––––––––––––––––––
CHECK SEQUENCE : 1
–––––––––––––––––––––––––––––––––
**
traceroute to cdar37 (155.132.43.67), 20 hops max, 38 byte packets
1 colomcC3M–C43 (192.40.103.254) 16.646 ms 13.045 ms 51.676 ms
2 broadcast (155.132.43.67) 0.968 ms 0.956 ms 0.919 ms
traceroute to clin12 (192.40.103.212), 20 hops max, 38 byte packets

1 clin12 (192.40.103.212) 12.412 ms * 1.020 ms
Connections successfully checked
–––––––––––––––––––––––––––––––––
CHECK SEQUENCE : 2
–––––––––––––––––––––––––––––––––
*****
Impossible to make the connection between server_name and client_name
3.8.2.2.6.6 Programming execution of one or more sequences

Execution of one or more sequences can be programmed up to 24 hours in advance. These
sequences must be accurately defined (manual choices during execution are not allowed).
In the 8 Programmed operations option submenu, select option 6 Postponed operations.
Note:
Only one execution (comprising one or more sequences) can be programmed in advance.
Example:
No postponed execution has been registered
1 Set a posponed execution

2 Cancel a postponed execution
3 List the registered sequences
Q Go back to previous menu
Your choice [1..3, Q] 1

EXISTING SEQUENCES
------------------
SEQUENCE : 1
-------------
OPERATION : Remote load a cpu as master or distributor
Source name : cdar37
Server type : Windows
Client CPU : clin13
Version delivery to load : E1.502
Patch delivery to load : no
Dynamic patch to load : no
list of export : fr
type of cpu to load : DISTRI
SEQUENCE : 2
––––––––––––––––
OPERATION : Remote installation of the client CPU
Master CPU : clin13
Client CPU : clin12
Version delivery to install : E1.502
Patch delivery to install : no patch installation
Dynamic patch to install : no dynamic patch installation
Master checking before remote installation : presence of files
Connection during the remote installation : connected
Enter the sequences to execute (blank separated and return)

=>1 2
At which time do you want to execute the sequence ?

1 - Hours ( between 0-23 ) :22
2 - Minutes ( between 0-59 ) : 0
Your request is registered
Press return
Cancelling programmed execution
Select option 2 Cancel a postponed execution.
Example:
A postponed execution is set at : 2003-02-25 22:00
1 Set a postponed execution
2 Cancel a postponed execution
3 List the registered sequences
Your choice [1..3, Q] 2
Your postponed execution is canceled
Press return
Checking execution details
Select option 3 List the registered sequences to display the detail of the different sequences
programmed for postponed execution.
Checking the last execution performed
Select option 7 About last programmed execution.
Note:
This menu is available only if traces of the last operations exist.
3.8.2.3 Maintenance
3.8.2.3.1 Useful commands

• ping: from the Communication Server Master/Distributor to the Client and vice versa allows
checking that the IP connection is set up between both machines.
• traceroute: to check the status of the routes between both machines.
3.8.2.3.2 Typical swinst error messages

• Permission denied: means that host not declared (see the netadmin section of document [13])
• Error when connecting to client CPU: means that the client network cannot be reached
• The client entry point cannot reach client CPU: means that the client network
cannot reach the client server and the client CPU
• Error when installing client CPU: means that the archive (or at least one of its
components) does not exist on the Communication Server Master/Distributor
• Impossible to remote load a CPU over itself: means that there is an error in the
download PC IP address (same address as that of the Communication Server)
• Operating system Chorus on client xxx is not compatible: means that both
environments (Chorus and Linux) are not compatible
3.8.2.3.3 Traces
In the event of a malfunction while connections are correct. Create a directory named: /tmpd/
soft_install/RLOAD_TRACE. Traces are displayed on screen and recorded in logs. Delete the
directory once traces have been recorded. Contact Alcatel-Lucent Enterprise support.
3.8.2.3.4 Log files

As of R9.1, the download process provides log files. For each CPU, the following temporary log files
are created on the master CPU:
• /tmpd/softinstall/SoftwareUpdateStatus_<session_id>_<seq_index>
• /tmpd/rmtpgm_<seq_index>.log
• /tmpd/softinstall/Pcxrmtseq_<seq_index>
Where:
• <session_id> is the sequence index of the CPU in the order of CPU upgrades determined by the
system
• <seq_index> is the numerical value to identify the session
When all updates are over, the contents of these temporary files are reproduced in the
file: /var/ftp/pcx/logs/softwareUpdateStatus_<session_id>_end. Temporary files are
deleted.
For each updated CPU, the recorded events are:
• Download status with information on the download performed:
• The name of the updated CPU
• The name of the downloaded software
• The update status OK/NOK
• Additional information such as reason for error(s)
• Switch status with information on the switch of partitions:
• The name of the switched CPU
• The switch type: Immediate/Relative/Absolute
• The switch status OK/NOK
• Additional information such as reason for error(s)
3.9 Swinst
3.9.1 Swinst overview
The Facilities menu (more commonly referred to as "swinst", from the session identifier name) is used
to:
• Install or update:
• OS files on the OmniPCX Enterprise from an external disk. These files may be a complete Linux
release, packages or a patch.
• Binary files (constituting the telephone application).
• Duplicate a Communication Server (to compensate for any failure of the main system
Communication Server).
• Back up and restore:
• OmniPCX Enterprise data.
• ACTIS files.
• Access system management.
• Perform database operations (create, translate, delete).
Two different menus may be used, according to needs:
• The "Easy" menu (covered in the documentation dealing with installation via the Wizard).
• The "Expert" menu (described below).
Communication Server hard disk structure is described in Software Installation Overview on page 16.
3.9.2 Access and operation

On a PC connected to the Communication Server by V24 or IP link, open a session (log on) using the
mtcl account, then enter swinst, before entering the required password.
ALCATEL-LUCENT FACILITIES
Main menu Installation FACILITIES 2.24.0
1 Easy menu
2 Expert menu
Q Exit
Your choice [1..2, Q] ?
Navigation is performed using the keyboard. The desired option is accessed by pressing the keys
shown on screen.
When swinst asks a question, there is no timer for automatic selection of the default option.
When swinst indicates that an item is selected by default, it is not necessary to enter the item.
To stop a current process (scrolling of a file list for example) press Q.
ALCATEL-LUCENT FACILITIES
Expert menu Installation FACILITIES 2.24.0
1 Packages installation
2 Deliveries installation
3 Cloning & duplicate operations
4 Backup & restore operations
5 OPS configuration
6 System management
7 Database tools
8 Software identity display
9 Remote download
3.9.2.1 Packages Installation

Select option 1 Packages installation.
1 Install package from server

2 Display package
3 Install Linux patch from server
4 Install Linux on inactive version from server
Option 1 Install package from server is reserved for Alcatel-Lucent Enterprise (as is option 3
Install Linux patch from server).
Option 2 Display package is used to check installation of a specific file.
Example:
Enter the name of the package (return for all) -> swinst
Name : swinst Relocations: (not relocateable)
Version : 2.24.0 Vendor : Alcatel-Lucent
Release : 3oxe Build Date: Wed Jan 30
07:02:39 2008
Install date: Mon Apr 28 10:22:26 2008 Build Host: csbu064
Group : Applications/System Source RPM: swinst-2.50.0-3oxe.src.rpm
Size : 805829 License: Alcatel-Lucent
Packager : xxx.xxxxxxx@col.bsf.alcatel-lucent.fr
Summary : The SoftWare INSTallation package for Alcatel-Lucent
OmniPCX Enterprise
Description : Swinst package is mainly intended for delivery installation, backup
of databases and system maintenance.
3.9.2.2 Deliveries Installation

Select option 2 Deliveries installation.
Installation is on the inactive or active version as desired.
1 Install delivery from server

2 About last install deliveries operations
Select option 1 Install delivery from server, enter the address (or name) of the server and
confirm the installation request.
Note:
For server name to be recognized, it must have been previously configured in netadmin.
Caution:
This operation may take some time.
When installing a dynamic patch, the system compares the version of telephone binaries already
installed with the telephone binaries contained in the patch. If the dynamic patch has a telephone
binary that is lower than or equal to the already installed telephone binary, a message is displayed,
indicating that a higher or equal version of telephone patch is already installed and that the patch
installation aborted.
TEL binaries installed are higher than the TEL binaries in dyn_n1.243.2.b.The binaries already
installed are as follows
TEL.1.so
TEL.2.so
The dynamic patch installation aborted.
For installation on the active version, the tool offers to "back up" the system, i.e. make a copy of the
binary files used before the installation operation. The resulting backup files can be restored via the
Restore operations menu.
Option 2 About last install deliveries operations gives details about the:
• Last installation of a dynamic patch
• Last installation of a static patch
• Last full installation delivery
3.9.2.3 Cloning & Duplicate Operations

Select option 3 Cloning & duplicate operations.
Cloning & duplicate operations menu:
1 CPU cloning
2 Partitions duplication
3 Switch on inactive version
4 Postponed switch on inactive version
3.9.2.3.1 CPU Cloning

See section on Communication Server duplication in document [1]
3.9.2.3.2 Partitions Duplication

Select option 3 Cloning & duplicate operations, then option 2 Partitions
duplication.
Then select the desired option(s).
Note:
To duplicate all data, select option 5 Duplicate all. This operation may take some time.
1 Duplicate Linux, packages and Linux data
2 Duplicate Linux data
3 Duplicate delivery
4 Duplicate database
5 Duplicate all
Example:
Confirm the duplication of Linux, packages and Linux data (y/n, default y): y
Duplicating Linux and packages
Clean the second Linux version. Confirm (y/n, default is y):
Second version cleaned
(list of files)
Linux and packages are duplicated
Duplicating the network configuration
Duplicate the network configuration in the second Linux version.
Confirm (y/n, default is y):(N4G-apply):
The network configuration is duplicated
Duplicating the Linux data
Building list of files...
Deleting the old files on inactive version...
Duplicating data on inactive version...
(list of files)
The Linux data are duplicated
Duplicating the timezone
Updating timezone ...
The timezone is duplicated
Press return
3.9.2.3.3 Switching on Inactive Version

This feature allows to switch on the second partition by rebooting the CPU.
Note:
This operation can be performed with the telephone running.
Important:
When the switch has been performed, you must log on again with the swinst account before restarting the
telephone.
Select option 3 Cloning & duplicate operations, then option 3 Switch on inactive
version.
The operator must confirm the operation:
Please confirm switching on the inactive version (y/n, default y)
If no Linux has been installed on the "inactive" version, the operation stops. If a telephone application is
installed on the active and "inactive" version, the tool displays the current status of autostart mode:
Before the switch autostart mode is :
Autostart is [not] set
The operator can duplicate this autostart mode on the "inactive" version:
Do you want to keep this autostart mode after switching (y/n, default
y)
Autostart is [not] set on inactive version
When the system is running on the new version and a shutdown occurs before a specified delay, the
system can reboot on the same version or go back to the previous one:
Do you want to switch back to the previous version if system resets
(y/n, default n): y
Enter the delay (1..7 days, q to quit): 1
A final confirmation is required before the CPU reboots:

Do a version switch. Confirm (y/n, default y):
3.9.2.3.4 Postponed Switch on Inactive Version

Postponed switch menu
No postponed switch has been registered
1 Set a postponed switch
2 Cancel a postponed switch
Your choice [1..2 Q]
This feature allows the operator to register a switch at an appointed time in the next 24 hours. The
operator can register a switch, check if a switch is registered or discard a registered switch.
Note:
The Linux data and database are automatically duplicated just before the switch.
3.9.2.4 Backup and Restore Operations

Select option 4 Backup and restore operations.
Backups can be performed on the Communication Server hard disk or another Communication Server
(network), using the swinst account. They can also be performed via the swinst Easy menu (see the
Installation Wizard documentation) or the OmniVista 8770 application.
1 Immediate backup operations
2 Periodic backup operations
3 Restore operations
3.9.2.4.1 Immediate Backup Operations

Select option 1 Immediate backup operations.
1 Immediate backup on cpu disk

2 Immediate backup on network
3 About last backup
3.9.2.4.1.1 Immediate Backup on CPU Disk

This option performs an immediate backup of the local CPU. Backup files are saved to /usr4/
BACKUP/IMMED.
A submenu is displayed to select the data to backup.
ALCATEL-LUCENT ENTERPRISE
Immediate backup on network Installation FACILITIES 2.38.0
1 Backup mao, voice guides and accounting data

2 Backup mao data
3 Backup accounting data
4 Backup voice guides
5 Backup mao data for rebuild
6 Backup traffic history
7 Backup Acd config & statistic files
8 Backup 4645 data
9 Backup 4645 data without messages
10 Backup 4635 data
11 Backup Linux (Unix) site specific data
Your choices [1..11, Q] ?
One choice per line and just press "return" to end the selection
your choice ==>
Option 1 Backup mao, voice guides and accounting data triggers mao, voice guide and
accounting backup (mao, vg and acc files)
Note:
Dynamic voice messages are automatically backed up, the tool also offers to back up specific voice messages
(custom directory). However, generic and standard voice messages (available on the voice guide CD-ROM) are
not backed up.
Option 3 Backup accounting data, triggers an accounting data backup operation (acc file).
Option 6 Backup traffic history, triggers a traffic analysis backup operation (obstraf file).
Option 7 Backup Acd config & statistic data, triggers a traffic analysis backup operation
(acd file).
Option 8 Backup 4645 data, triggers a 4645 voice mail data backup operation - messages,
mailboxes and greetings (eva-msg file).
Option 9 Backup 4645 data without messages, triggers a 4645 voice mail data backup
operation - except for received messages - (eva file).
Option 11 Backup linux ( unix ) site specifics data, triggers a backup operation of the
cho-dat file (system-specific Linux data).
Note:
OPS file backup operations are managed from option: OPS Configuration on page 187.
3.9.2.4.1.2 Immediate Backup on Network

Select the data to backup (see: Immediate Backup on CPU Disk on page 181).
Enter the name of the remote Communication Server.
If this name is not declared in the Communication Server host file, enter the IP address of the remote
When a "backup on network" has been saved, for any new backup of this type, the application offers
the last used address as the default setting.
Example:
Backup on network
your choice ==> 3
Name of remote host (default 192.168.4.52) ->
Name of user on 192.168.4.52 (default swinst) ->
Name of remote file (full path) -> /usr4/BACKUP/save2604
your choice ==>
Starting immediate backup on network
Stopping the none process...
Backing up of obstraf files...
(list of backup files)

352+0 records in
352+0 records out
Backup completed
*******************************************************
* The backup operation for traffic history, all files
* are completed
*******************************************************
Press return
3.9.2.4.1.3 About Last Backup

This option gives details (date, time, files saved) of the last backup performed.
3.9.2.4.2 Periodic Backup Operations

Periodic backup can be performed in "local" mode, and, as of R12.2 MD1, on network.
It is based on a calendar type mechanism (DAY, DAY-1, DAY-2, ... DAY-6, WEEK-1, WEEK-2, WEEK-3,
MONTH-1, MONTH-2).
When swinst is first installed, daily backup to the hard disk is automatically enabled at a time set by the
system. The user is informed of this by the message:
A daily backup will be executed on cpu disk at 5 hour 45 mn.
If periodic backup is programmed, the user is informed of this by the message:
A periodic backup is already registered.
Reactivating daily backup resets the calendar mechanism but previous backups are not deleted.
Periodic backups on local CPU disk are saved in directories of type /usr4/BACKUP/DAY DAY-1 etc.
The directories used to store immediate backups are in /usr4/BACKUP/IMMED.
Periodic backups on a remote server are saved in directories in the format: <name of base file_day of
backup>. For example, if OXE is the name of the base file, backups (cho-dat, mao-dat) will be stored in
the specified path under the following directories: OXE_DAY, OXE_DAY1, OXE_DAY2, OXE_DAY3,
OXE_DAY4, OXE_DAY5, OXE_DAY6, OXE_WEEK1, OXE_WEEK2, OXE_WEEK3, OXE_MONTH1.
A maximum of 11 backup files is retained.
Example:
Accessing periodic backups
A periodic backup is registered
1 Periodic backup on cpu disk
2 Periodic backup on network
3 Cancel periodic backup operations
4 List periodic operations
5 About last backup
3.9.2.4.2.1 Periodic Backup on CPU Disk

This option performs periodic backups of the local OmniPCX Enterprise on the local disk.
Select the data to backup and the time for backup operations.
Example:
Space used on cpu disk: 3%
1 Backup mao data for rebuild and
Backup Linux (Unix) site specific data
Your choices [1..1, Q] ?
One choice per line and just press "return" to end the selection
your choice ==>1
your choice ==>
Computing the best time for the backup operation (between 0-6 AM)...
The time proposed by the system is 5 hour 45 min
Do you agree with it (y/n, default y): n
At which time do you want to execute the save operation ?
1 - Hours ( between 0-23 ) : 1
2 - Minutes ( between 0-59 ) : 0
***************************************
* Your request is registered
***************************************
Press return
3.9.2.4.2.2 Periodic backup on network

This option performs periodic backups of the local OmniPCX Enterprise on a remote server.
The remote server must allow host based authentication without password (as for immediate save on
network). FQDN is not supported. Either the host name (added in the /etc/host file), or the IP
address of the remote server can be specified.
Only one remote server can be specified, multiple servers are not allowed. When the remote server is
changed, the periodic backup operations are cancelled on the old server. The existing data on old
server are not disturbed.
To enable a periodic backup on a remote server:
1. Press 1 to program a daily save operation of mao (data files only) and Linux data on the network at
a fixed time in a day. These two savings are performed simultaneously, nevertheless they will be
restored individually.
1 Backup mao data for rebuild and backup Linux (Unix) site specific data
Your choice [1...1, Q]
One choice per line and just press ”return” to end the selection
2. Enter the name of the server, name of the account, and complete path and base file name where
the data has to be saved
your choice ==> 1 return
Name of remote node : <name of unix server>

Name of user on remote node : <name of account on the server>
Name of remote file : <complete path and base file name>
Name of remote node : <name of unix server>

<*************CHECKING CONNECTIONS*************>
SERVER IS REACHABLE.
The reachability to the server is checked. If the server is reachable and the user name and the path
of the remote file are valid, the system displays details and proceeds to the next option.
If an invalid user name is entered, the system displays an error message:
Name of user on <system IP address> (default swinst): <wrong entry>
Name of remote file (full path): /tmpd
Access denied
your choice ==>
If the path is invalid, the system displays the corresponding message.

your choice ==> 1 return
Name of remote node : <xxx>

Name of user on remote node : <yyy>
Name of remote file : <zzz>
<*************CHECKING CONNECTIONS*************>
INCORRECT DATA LOCATION ON REMOTE HOST
your choice ==>

3. An optimum time between 0AM-6AM for taking the periodic backup is suggested by scanning
crontabs files and proposed on screen.
Computing the best time for the save operation (between 0–6AM)...
The time proposed by the system is
5 hour 45 min
Do you agree with it (Y/N)? N
4. If the system cannot find the best time or if the answer selected is no, enter the best time to start
backup on network.
At which time do you execute the periodic save operation?
1 – Hours (between 0-23):
2 – Time minutes (between 0-59):
************************************
Your request time is registered
************************************
If the remote server is not reachable at the registered time, incident 3078 is sent to the local host. No
retry operation is attempted if the server is not reachable. Backup will only take place at the next
scheduled time.
3.9.2.4.2.3 Cancel periodic backup operations

Cancel periodic backup operation on CPU disk
This option cancels periodic backup operation on CPU disk.
Example:
1 Cancel periodic backup operation on cpu disk
2 Cancel periodic backup operation on network
Your choice [1...2, Q]? 1
***************************************
* Your periodic backup on CPU disk is canceled
***************************************
Press return
Cancel periodic backup operation on network
This option cancels periodic backup operation on network.
Example:
1 Cancel periodic backup operation on cpu disk
2 Cancel periodic backup operation on network
Your choice [1...2, Q]? 2
***************************************
* Your periodic backup on network is canceled
***************************************
Press return
3.9.2.4.2.4 List Periodic Backup Operations

This option displays information on periodic backups.
Example:
Hour : 5 Minute : 45
Day of the month : all
Month of the year : all
Day of the week (0=Sunday) : all
executed command : /DHS3bin/soft_install/bin/bck -save 1>/dev/null 2>&1
Backup of "Linux data" performed on "cpu disk"
Backup of "MAO data only" performed on "cpu disk"
Press return
3.9.2.4.2.5 About Last Backup

This option gives details on the last backup operation (whether immediate or periodic).
Example:
**************************************************
* Last backup operation
**************************************************
For client : For CPU : oxe
backup of Linux-data
for Linux data
to LOC_ARCHIVE
data version : F1.600
in date of Wed Jun 16 15:13:54 CEST 2004
local cpu : oxe
twin cpu : unknown
Periodic backup performed on cpu disk
**************************************************
--------------------------------------------------
Pre backup operation
--------------------------------------------------
Stopping the none process...
(list of files)
Backup completed
--------------------------------------------------
Post backup operation

--------------------------------------------------
End of backup operation
--------------------------------------------------
Note:
This option can also be accessed from the previous menu.
3.9.2.4.3 Restore Operations

Any restore operation is performed on the active part of the hard disk and must be performed with the
telephone shut down (see the swinst Easy menu for details on how to shut down the telephone).
Select option 3 Restore operations.
Restore operation menu Installation FACILITIES 3.16.0
1 Restore from cpu disk
2 Restore from network
3 Clean IMMEDIATE backups on cpu disk
4 About last restoring
Depending on the backup operations performed, select a restore operation from the network or the
local hard disk.
3.9.2.4.3.1 Restore from CPU Disk

The available backups are displayed.
Example:
1 Restore from IMMEDIATE backup
2 Restore from FEB 18 backup
Select the backup to be restored from the list of dates shown.

Then select the data to be restored.
Example:
1 Restore mao data for rebuild
2 Restore Linux ( Unix ) site specific data
Your choice [1..2, Q] ? 2
You are going to restore linux-data from cpu disk
# For client : For CPU : oxe
# for Linux data
# in date of Wed Feb 18 05:45:12 CET 2003
# data version 13.0
Confirm your action (y/n, default y): y
Warning:
After a software upgrade to release 12.0, it is prohibited to perform Restore MAO data for rebuild
operation for any database from a release prior to R12.0, due to binary incompatibility.
3.9.2.4.3.2 Restore from Network

If a "backup on network" operation has already been performed, keep or modify the default data
offered.
Select the desired option:
1 Restore from IMMEDIATE backup

2 Restore from PERIODIC backup
If restore from periodic backup is requested, the procedure is the same as for Restore from CPU Disk
on page 186.
If restore from immediate backup is requested by the administrator, the previous files are backed up
and the system automatically offers to clean (purge) the backup when the procedure is complete.
Name of remote host (default 192. 168.4.52) ->
Name of user on 192.168.4.52 (default swinst) ->
Name of remote file (full path) -> /usr4/BACKUP/save2604
You are going to restore obstraf from network
# For client : For CPU : oxe
# for traffic history
# in date of Mon Feb 17 11:00:05 CET 2003
# data version no-version
confirm your action (y/n, default y):
Do you wish to secure the restoration (y/n): y
Checking disk space ...
Wait the system is backing up old files ...
(list of files)
Archive of old files is created
Restoring data...
Display of the security configuration (in reversed video):

For example:
Security configuration:
[+] Aging password configured for some account.
[+] The internet accesses to the PABX are currently
secured.
[+] Trusted host(s) declared on your system.
[+] TCP WRAPPER activated for configured trusted
hosts.
[-] The SSH security is currently NOT set.
(list of files)
Restoration completed
End of restoring data
Do you wish to clean up the archive : get rid of old files (y/n): y
********************************************************
* The restore operation for traffic history, all files
* is completed
********************************************************
Press return
3.9.2.4.3.3 Clean Immediate Backups on CPU Disk

Select the data to be cleaned.
Clean IMMEDIATE backups Installation FACILITIES 2.36.0
Space used on CPU disk: 24%
1. Clean mao, voice guides and accounting data

2. Clean Linux (UNIX) site specific data
The selected data is deleted.

Note:
Periodic daily archives are never displayed because they cannot be deleted.
3.9.2.5 OPS Configuration

This option allows to display and manage OPS files.
For more information, refer to the Licenses section of the document [1].
3.9.2.6 System Management

Select option 6 System management.
System management menu Installation FACILITIES 3.16.0
1 Date & time update
2 Autostart management
3 Shutdown powerfail delay (Current Value : 1 h 30 m )
4 Console configuration
5 User's accounts management
6 IMAP server management
7 Enable USB key
3.9.2.6.1 Date & Time Update

Select option 1 Date & time update.
The exact time can be obtained from a reference clock then used to synchronize all system OmniPCXs
via NTP (Network Time Protocol).
The difference between summer and winter time (when appropriate) is automatically managed by the
system depending on OmniPCX installation country.
Note:
This time change is automatically performed on the duplicated Communication Server (if there is one).
The date is MAR 24, 2003 and the time is 11:21:05 (11:21:05 AM)
The timezone is Europe/Paris
1 Set date & time
2 Set timezone
3 NTP server management
3.9.2.6.1.1 Set Date and Time

Select option 1 Set date & time.
Enter the year (default is 2003) : 2002
Enter the month (01..12, default is 03) : 03
Enter the day (01..31, default is 24) : 29
Enter the hour (00..23, default is 04) : 18
Enter the minutes (00..59, default is 21) : 39
The date & time have been set on your CPU
Press return
3.9.2.6.1.2 Set Timezone

This option allows CCx type applications to manage calls according to the timezone of the parties to be
called. The timezone selected is saved as being that of the OmniPCX Enterprise.
Select option 2 Set timezone.
timeconfig 3.0.2 - (C) 1999 Red Hat Software

ÚÄÄÄÄÄÄ´ Configure Timezones ÃÄÄÄÄÄÄ¿
³ ³
³ Format machine time is stored in: ³
³ ³
³ [*] Hardware clock set to GMT ³
³ ³
³ Europe/Malta ² ³
³ Europe/Minsk ² ³
³ Europe/Monaco ² ³
³ Europe/Moscow ² ³
³ Europe/Oslo ² ³
³ Europe/Paris # ³
³ ³
³ ÚÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄ¿ ³
³ ³ Ok ³ ³ Cancel ³ ³
³ ÀÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÙ ³
³ ³
³ ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
<Tab>/<Alt-Tab> between elements | <Space> selects | <F12> next screen
In the above example, OmniPCX timezone is shown by the # symbol.

As shown on the screen, use the Tab and Alt keys to select another timezone. Confirm your selection
with the space bar.
Note:
The scroll arrows and alphabetic keys on the keyboard are used to navigate through the list. When selection has
been made, swinst requests confirmation.
After setting a new timezone , YOU HAVE TO REBOOT THE SYSTEM

Do you really want to set timezone to: GB (y/n, default y): n
If you make a mistake, enter n (for no) before pressing the "Return" key.
3.9.2.6.1.3 NTP server management

The NTP server allows to synchronize time with a reference clock. For more information on NTP
configuration, see Configuration procedure section on Network Time Protocol (NTP) in document [7].
3.9.2.6.2 Autostart Management

Select option 2 Autostart management.
Note:
After a shutdown or power failure, the telephone has to be started manually if "autostart" is not selected:
• either with the RUNTEL command,
• or via the swinst Easy menu (option 8, "Start the telephone").
If autostart is enabled (set to "Yes") then, in the case of a duplicated Communication Server, it is also set to "Yes"
(automatically) on the Stand-by Communication Server. However if set to "No" on the Main Communication Server,
it has to be manually disabled on the Stand-by Communication Server.
Autostart is not set

1 Set autostart
2 Unset autostart
Autostart is set
3.9.2.6.3 Shutdown Powerfail Delay

Select option 3 Shutdown powerfail delay (Current value : 0h 0m).
This is the delay between mains power supply failure and the beginning of system shutdown. This
delay is used when the Communication Server is hosted in:
• Communication Server board located in an S or L rack with internal batteries
• Appliance Server connected to the UPS with a serial V24 port
Enter the hours (default is 0) : 0
Enter the minutes (default is 0) : 2
Please confirm the shutdown delay 0 h 2 m (y/n, default y): y
If you want to correct the delay, enter n (for "No") and repeat the actions.
For more information on Communication Server startup and shutdown, see the Communication Server
Stop/Restart Procedure.
3.9.2.6.4 Console Configuration

Select option 4 Console configuration.
This operation allows the configuration of the console communication port. The available options are
displayed and include a "help" option to assist in the configuration.
Enter the console mode (direct,modem,ppp,ups,?)
• direct: the link between the CPU and the console is a simple V24 cable.
• modem: the console is far away from the CPU, the serial link is transmitted via a commutated line
with modem. Kernel messages are transmitted to the console.
• ppp: instead of character, the modem line, linked to the console with a modem, transmits data
packets. Kernel messages are not transmitted to the console.
• ups: the serial port is used to drive an UPS system.
• ?: provides help about the configuration.
Confirm your modification (y/n, default y):
Apply modifications immediatly ? [Yes|No]:
Communication Server Stop/Restart Procedure

The new configuration can be taken into account immediately or at next reboot.
3.9.2.6.5 UPS Configuration

As of R6.1, this option allows the configuration of the UPS monitoring process.
For more information, see: Appliance Server - Detailed description - Uninterruptable Power Supply
(UPS).
3.9.2.6.5.1 Access
Select option 5 UPS configuration.
UPS configuration menu Installation FACILITIES 2.24.0
UPS is stopped (1)
1 Start UPS on USB

2 Stop UPS
3 UPS status
(1) This line gives the main UPS status: start or stop.
3.9.2.6.5.2 Start UPS on USB

This option starts a UPS monitoring process via a USB port.
The UPS device must allow USB connections. For UPS configuration, see the UPS manufacturer
documentation.
Caution:
To take into account this new configuration (port COM to port USB), reboot the Communication Server and
the UPS:
1. Stop the Appliance Server
2. Stop UPS with the front panel ON/OFF button
3. Disconnect the UPS from the mains supply
4. Wait for the fan to stop
5. Connect the UPS to the mains supply
6. Restart the UPS with the front panel ON/OFF button
7. Restart the Appliance Server
3.9.2.6.5.3 Stop UPS

This option stops the UPS monitoring process.
3.9.2.6.5.4 UPS Status

This option checks the connection between the Appliance Server and UPS and details UPS status.
Example:
battery.charge: 100 (1)
battery.runtime: 13524 (2)
battery.voltage: 2.3 (3)
driver.name: hidups (4)
driver.parameter.port: /dev/usb/hiddev0 (5)
driver.version: 2.0.0 (6)
ups.load: 14 (7)
ups. MGE UPS SYSTEMS (8)
ups.model: EXtreme (9)
ups.serial: 884E06029 (10)
ups.status: OL (11)
Press return
1. Displays batteries charge (in percentage)

2. Batteries autonomy according to batteries level and electric load (in seconds)
3. Batteries voltage (in volts)
4. Reserved for Alcatel-Lucent Enterprise
11. UPS status:
• OL : On Line (mains supply)
• OB: On Batteries
3.9.2.6.6 User's Accounts Management

This swinst menu allows to configure user authentications.
Select option 6 User's accounts management.
This opens a sub-menu with the following options:
1 Change account password
2 Change account aging password
3 Set maximum authentication attempts
4 Configure RADIUS authentication
5 Create the 'client' account
6 Remove the 'client' account
1. This option allows to modify the password of a specified account. The following instructions are
displayed:
Current password check rules :

- password string must have a minimum of 8 characters (can be lower/upper
case, numeric or punctuation). This rule doesn't concern accounts root and
swinst, but nevertheless a warning is displayed.
- new password must be different from the last three.
- at least fifty percent of characters of the new password must be
different from the previous one.
Enter a username : XXXX
Changing password for XXXX
(current) UNIX password :
New UNIX password :
Retype new UNIX password :
2. This option displays the current aging password status for every account available. It allows to
modify the maximum time during which to use a password for a specified account.
Current aging password status :
[root] – 100 days / last change 0 days ago, 100 days left
[swinst] – Not activated
[mtcl] - 200 days / last change 5 days ago, 195 days left
[adfexc] – Not activated
[client] – Not activated
Enter a username : XXXX
How many days do you want to keep validate passwords (10<X<366,
0 for no aging)?
3. This option defines the number of authorized failed attempts when trying to login. When the number
of attempts is reached, an alarm (incident 3070) is sent to the administrator and the account is
locked for 15 seconds. The maximum number of attempts is common for all accounts.
How many failed authentication attempts allowed for login (0<x<100,
default 2)?
The default value is set to the current one.

4. This option opens the Radius configuration sub-menu:
1 View configured RADIUS servers
2 Add/Modify RADIUS server
3 Delete RADIUS server
4 View RADIUS users
5 Add/Modify RADIUS user
6 Delete RADIUS user
7 Enable/Disable RADIUS authentication
8 RADIUS authentication without local User
9 Local database authentication
10 Enable/Disable Export authentication to MGR
1. View configured RADIUS servers: displays the configuration and the status of the
previously defined Radius servers. For security reasons, the shared secret is not displayed.
2. Add/Modify RADIUS server: allows to create or modify a Radius server. Up to 2 Radius
servers can be defined to ensure redundancy in case of failure. The first Radius server declared
is called the primary Radius server, the second server is called the secondary Radius server.
The secondary Radius server is used only when the primary Radius server is not reachable.
In order to define Radius servers, the following menus are displayed:
Enter the name or the IP address of the RADIUS server:
When a name is used, the Radius server must be declared previously in the host database,
using the netadmin tool (see: netadmin - Operation - Host Names and Addresses).
If the defined server is already known as a Radius server, it can be modified, if not the Radius
server can be created.
Enter the destination port (default is 1812):
Enter the shared secret:
Enter the timeout value in second (default is 3):
The destination port is the port number used by Radius requests sent to the Radius server.
Destination port = 1812 is the standard value.
The shared secret is shared between the Communication Server and Radius server. The
shared secret acts as a key for encryption of the Radius requests. The shared secret must be
identical on the Radius server and Communication Server. It does not exceed 64 characters.
Note:
Prior to R11.2, the minimum length for shared secret was 8 characters. As of R11.2, the minimum length for
shared secret is changed to 4 characters. If users prefer a shared secret with length less than 8 characters,
a warning message is displayed:
Less than 8 characters for shared secret is not compliant with security
standards. Manufacturer disclaims all liabilities in case of misuses due to low
level of security. Do you really want to continue? (y/n, default y): y
If users accept the warning message, the shared secret is accepted.
The timeout feature checks responses to the Radius requests. When the timer expires, the
Radius server is declared not reachable.
If the server is being modified, the default value is set to the current one. The current value of the
shared secret is not displayed for security reasons. The shared secret must be entered each
time a modification is performed.
3. Delete RADIUS server : allows to delete a Radius server.
4. View RADIUS users: displays the corporate login list
Example:
Login: john Account: mtcl
Login: william Account: root
Press return
In this example, user john can open a session with mtcl rights.
5. Add/Modify RADIUS user: allows to create or modify a corporate login
Example:
Enter the RADIUS user (eg: Peter SMITH): tom
Enter the system user (root, swinst, mtcl, adfexc, client): mtcl
In this example user tom is created with mtcl rights.

User logins are recorded in the /etc/passwd file. In duplicated Communication Server
configurations, this file is copied on the twin Communication Server when activating the copy
linux data menu from the swinst tool.
6. Delete RADIUS user: allows to delete a corporate login
7. Enable/Disable RADIUS authentication: allows to enable or disable Radius
authentication. When trying to enable authentication, the system checks the defined Radius
server(s). In case of no answer, the Radius authentication cannot be enabled. The following
message is displayed:
WARNING: No RADIUS server configured! Cannot enable RADIUS
authentication.
8. RADIUS authentication without local User allows to authorize the login of users not
declared on the Communication Server.
If the RADIUS authentication without local User option is enabled and:
• There is no corresponding local user in the Communication Server for this particular
corporate user, the final identity of the corporate user is mtcl
• A local user is present with different a permission (UID) in the Communication Server, the
session opens with the corresponding permission.
If the RADIUS authentication without local User option is disabled, all corporate users must
be declared on the Communication Server using the Add/Modify RADIUS user menu
9. Local database authentication. The local database authentication is used when no
Radius server is reachable. The following submenu is displayed:
Note : If primary and secondary RADIUS servers are unreachable for any
reason, it can be allowed to the administrator to access the system and
modify the configuration if this is the origin of the problem. Default
behavior is to forbid local database authentication.
Current configuration : Local database authentication from any

connection (console and IP)
1 No local database authentication
2 Local database authentication only from console port
3 Local database authentication from any connection (console and IP)
No local database authentication: local authentication is not allowed.
Local database authentication only from console port: local authentication is allowed on the
system console only. In this case, authentication is performed according to the security policy
defined in the local database.
Local database authentication from any connection (console and IP): local authentication is
allowed for local and remote users.
10. Enable/Disable Export authentication to MGR: allows to enable or disable the
Access control to mgr feature. For more details on Access control to mgr, see section on
Access control to management in document [14].
5. This option allows to create a “client” account, which contains a single maintenance menu. A
password is requested.
6. This option allows to delete the “client” account created previously.
For more information on security, see section on Access to Communication Server user accounts -
User authentication in document [14]
3.9.2.6.7 IMAP Server Management

Select option 7 IMAP server management.
See Configuration procedure in IMAP service section from document [8].
3.9.2.7 Database Tools

Some operations on the database must be performed with the telephone shut down. If an operation is
not allowed, it is not performed and a warning message is displayed.
Select option 7 Database tools.
3.9.2.7.1 Database Translation

Translation consists in making data file format comply with a new software version (release). It is
automatically performed when the Communication Server reboots after a new release has been
loaded.
Select option 1 Database translation.
3.9.2.7.2 Creating an Empty Database

Select option 2 Create an empty database.
This operation overwrites the existing database and the lock files. It can only be performed with the
telephone shut down.
Note:
Creation of a new database may take some time.
Restart the Communication Server after this operation (and before restarting the telephone).
3.9.2.7.3 Remove Database

Note:
At installation, the existing database is automatically overwritten and replaced by the new database.
Select option 3 Remove database.
3.9.2.7.4 Acd Stat File Translation

Select option 4 Acd stat file translation.
3.9.2.8 Software Identity Display

This feature allows specific details on the operating system, software release and patch and binary
releases (versions) to be obtained. It also allows all known data on a specific component to be viewed.
Select option 8 Software identity display.
Then select the desired option.
ALCATEL-LUCENT ENTERPRISE
Software identity display Installation FACILITIES 2.24.0
1 System release identity
2 Application software identity
3 Delivery status
4 Component status
5 System release validity checking
6 Application software validity checking
Option 1 System release identity gives the Linux version used by the system.
Option 2 Application software identity gives the telephone version used by the system.
Option 3 Delivery status gives the version of software firmware and modules.
Option 4 Component status gives the version of a module found by performing a search on a
keyword.
Example:
Enter the component name : bios
bios_cpu5 from /twdhs3/col_int/ws/r_bios_cpu5_4.0_3BA20032ADAB01 delivered
in e2.400
bios_cpu5d from /twdhs3/col_int/ws/r_bios_cpu5_4.0_3BA20032ADAB01 delivered
in e2.400
bios_cpu6 from /twdhs3/col_int/ws/r_bios_cpu6_2.4_3BA24084AAAA04 delivered
in d1.305
bios_cpu6d from /twdhs3/col_int/ws/r_bios_cpu6_2.4_3BA24084AAAA04 delivered

in d1.305
new bios_cpu6s2 from /twdhs3/sxb_int/ws/r_bios_cpu6s2_3BA24095AAAB03_4.6
bios_cpu7 from /twdhs3/sxb_int/ws/r_bios_cpu7_3BA24115AAAA13_2.16 delivered
in f2.500
new ch_cpbios from /twdhs3/col_int/ws/r_f3.301
Press return
Option 5 System release validity checking checks package versions (no CRC check). Some
packages are only loaded on certain CPUs. The results of the command specify which packages are
not installed.
Option 6 Application software validity checking checks telephone version by size and
checksum.
Note:
This operation may take some time (a few minutes).
Note:
Although some files can be modified, neither binaries nor executables should be modified.
Example:
Please wait ..
Checking mode : 1=size & sum 2=size only (default is 1) 1
Checking size and sum of all files , please wait ...
file modified (authorized) : /DHS3data/afe/params.cfg checksum is not correct :
The application software is correct
Press return
3.9.2.9 Remote Download

Select option 9 Remote download.
This operation is described in the section Updating networked Communication Servers (download/
remote installation) on page 160
3.10 Communication Server Stop/Restart Procedure

3.10.1 Overview
The following paragraphs exclusively describe the intentional stop/restart procedures for an OmniPCX
Enterprise installed on:
• An Appliance Server (see: Appliance Server stop/restart procedure on page 196)
• A virtual machine in a Kernel-based Virtual Machine (KVM) or VMware ESXi environment (see:
Virtual machine stop/restart procedure on page 197)
This procedure can be used for maintenance operations. For example, an OmniPCX Enterprise virtual
machine may be moved to another location or its disk may need unmounting.
3.10.2 Appliance Server stop/restart procedure

The procedure to stop the Appliance Server depends on the OmniPCX Enterprise software version
installed on this Appliance Server:
• If the software version installed is K1.520.35 (or higher), or L1.301.23 (or higher), press the off/on
button (set to off). This action shuts the OmniPCX Enterprise down (it is equivalent to the
shutdown -h process). Then, physically stop the Appliance Server.
Note:
The shutdown -h command can also be used to stop the Appliance Server.
• For the other OmniPCX Enterprise software versions:

1. Open a console on the Appliance Server and log onto mtcl account and type shutdown -h
now. The -h option stops the OmniPCX Enterprise
2. Wait until the message : Power down is displayed on the system console screen
3. Press the off/on button of the Appliance Server (set to off)
To restart, press the on/off button of the Appliance Server (set to on). Let the system restart completely
(to be monitored on the system console).
3.10.3 Virtual machine stop/restart procedure

3.10.3.1 KVM context
The procedure to stop the KVM virtual machine depends on the OmniPCX Enterprise software version
installed on this virtual machine:
• If the software version installed is K1.520.35 (or higher), or L1.301.23 (or higher), the Power /
Power Off is supported. In this case, open a console on the virtual machine and select Power >
Power Off. This action launches a shutdown -h on the virtual machine (the -h option stops the
OmniPCX Enterprise). At the end of the shutdown, the virtual machine is automatically switched off.
Note:
The shutdown -h command can also be used to stop the KVM virtual machine.
• For the other OmniPCX Enterprise software versions, the Power Off is not supported. The virtual
machine must be manually switched off as follows:
1. Open a console on the KVM virtual machine and log onto mtcl account and type shutdown -h
now. The -h option stops the OmniPCX Enterprise
3. From the management console, stop manually the virtual machine using Power > Force Off
3.10.3.2 VMware ESXi context

The procedure to stop the VMware ESXi virtual machine depends on the OmniPCX Enterprise
software version installed on this virtual machine:
• If the software version installed is K1.520.35 (or higher), or L1.301.23 (or higher), open a console on
the VMware ESXi virtual machine and log onto mtcl account and type shutdown -h now. The -h
option stops the OmniPCX Enterprise, then stop the virtual machine.
• For the other OmniPCX Enterprise software versions:
1. Open a console on the VMware ESXi virtual machine and log onto mtcl account and type
shutdown -h now. The -h option stops the OmniPCX Enterprise
3. From the management console, right click the virtual machine and select Power > Power Off
Chapter
4 Generic Appliance Server

Installation
4.1 Overview
4.1.1 About this chapter
This chapter is intended for people in charge of installing a Generic Appliance Server on a customer
site. The Generic Appliance Server is available as of R12.2. It replaces OmniPCX Enterprise Software
Server, available in previous releases.
This chapter details:
• Hardware and software architecture: see Generic Appliance Server environment on page 199
• Deploying Licenses on page 200
• Installation, including:
• SUSE Linux Enterprise Server installation on a physical server: see Installing SUSE Linux
Enterprise Server on the host server on page 204
• Generic Appliance Server installation: pre-installation and post-installation: see Installing the
Generic Appliance Server on page 208
• Maintenance on page 235 including:
• Shutdown and restart operations
• Reboot or stop operations
• Backup and restore operations
• Rehosting operations
• Upgrade and update operations
• Flex-LM management
• Un-installation procedure
4.1.2 Generic Appliance Server description

The Generic Appliance Server includes:
• One OmniPCX Enterprise (OXE)
• Optionally, one OXE Media Services (OXE-MS)
• Optionally, one Rainbow WebRTC gateway, providing media handling (voice/video)
communications between OmniPCX Enterprise telephone devices and Rainbow clients
• A Flex-LM server, running directly on the host operating system, and providing centralized license
control for OmniPCX Enterprise virtual machines
The host operating system is a SUSE Linux Enterprise Server (SLES), with a Kernel-based Virtual
Machine (KVM) package.
The use of OXE-MSs is controlled by software locks.
In case of duplication, the duplicated Generic Appliance Server must be installed on a different
hardware.
The Flex-LM server verifies the accuracy of a specific and unique identifier, called ALUID. This allows
to do without a USB dongle.
Chapter 4 Generic Appliance Server Installation
4.1.3 Generic Appliance Server environment

The Generic Appliance Server contains virtual machines to host the different servers. The server is
built on SUSE Linux Enterprise Server (SLES) which serves as operating system in the given
hardware. This OS is called host.
The Generic Appliance Server is delivered as a full software package including the following
components:
• A Kernel-based Virtual Machine (KVM) solution based on the SLES OS and a KVM virtualization
layer. Virtual machines can be created to host the different network elements included in the
Generic Appliance Server software package
KVM virtualization allows all Alcatel-Lucent Enterprise applications to operate on the same server.
The layer creates VMs using their OS system
• A virtual machine for OmniPCX Enterprise deployment (OXE VM). It consists of a Linux operating
system and the OmniPCX Enterprise software
• A virtual machine for OXE Media Services deployment (OXE-MS VM). It consists of a Linux
operating system and the OXE-MS software
• A virtual machine for Rainbow WebRTC gateway deployment (WebRTC VM). It consists of a Linux
operating system and the Rainbow WebRTC gateway software
The Generic Appliance Server Installer is a package (.bin) containing:
• Pre-installed VM images of OXE, OXE-MS, and Rainbow WebRTC gateway
• Flex-LM setup
• Script files for configuring the VMs
When this package is executed on the host OS, it deploys and configures the servers.
The pre-installed VM image is a clone of the running VM (already installed virtual machine with OXE).
This is an image file with the extension: .img. This image file is taken as input to create the OXE VM
on the target platform.
The following configurations are supported:
• No redundancy
• Local redundancy: the redundant CPU is hosted on two servers located in the same subnetwork
• Spatial redundancy: the redundant CPU is hosted on two servers located in a different remote
subnetwork
Caution:
Installing another VM in this environment is not supported. To install the stand-by server, proceed as for a
main server. The two hardware include one OmniPCX Enterprise and one optional OXE-MS. In addition,
only one optional WebRTC gateway can be deployed in a redundant configuration: if a WebRTC gateway is
already installed on a server, you cannot install a second WebRTC gateway on the redundant server.
Note:
The Multi-IP configuration feature enabling to create separated VLAN is not supported on Generic Appliance
Server. The host server and virtual machines must be in the same IP subnetwork.
The following figure represents the deployed architecture on the target hardware: one instance of
OmniPCX Enterprise (OXE VM), one instance of OXE-MS (OXE-MS VM), one instance of WebRTC
gateway (WebRTC VM), and one Flex-LM.
Virtual Machines
OXE VM OXE-MS VM WebRTC VM

WebRTC
OXE OXE MS
Gateway
Software Software
Software
Flex-LM
SUSE Linux
Server
OXE Linux DEBIAN Linux
Kernel-based Virtualization Machine
SUSE Linux Enterprise Server Operating System
Host
Hardware
SIP Trunking
Carrier
Figure 4.54: OmniPCX Enterprise Software Server architecture
4.1.4 Licenses
4.1.4.1 OmniPCX Enterprise licenses
The ALUID is a unique 32-digit hexadecimal number, associated to a hardware server, and used to
sign all technical items in the license files.
The ALUID must be declared in the eLicensing Host Registration page to finalize the license file. The
ALUID can be read after SLES OS installation, using the command:/usr/bin/getaluid.
The OmniPCX Enterprise license related files are obtained through the e-License Portal (eLP) based
on the ALUID of the physical host.
In the installation process, the Actis files are automatically recopied on the OmniPCX Enterprise.
4.1.4.2 Flex-LM
Flex-LM is a software license manager from Flexera Software. It is intended for corporate
environments, where floating licenses are made available to multiple software end-users.
4.2 Installation procedure

Installation consists in:
1. Collecting the required information on page 201
2. Verifying BIOS configuration on page 201
3. Verifying hardware, isos and licenses on page 203
4. Installing the Generic Appliance Server on page 204
4.2.1 Collecting the required information

Installation requires:
• The IP address of the host server
• The FQDN of the host server
• The subnet mask of the host server
• The IP address of the default gateway
• The IP address of the DNS server
• The IP address of the OmniPCX Enterprise
• The IP address of the OXE-MS (optional)
• The WebRTC gateway network settings (optional)
Information are available online on Rainbow Help Center
4.2.2 Verifying BIOS configuration

The virtualization option must be enabled:
1. At server initialization, Press F9 to enter BIOS configuration
2. Navigate to: System Options > Processor Options
3. Validate the Intel Virtualization Technology option
Verify that the boot sequence is configured to start on the DVD drive.
Refer to the server manufacturer documentation on BIOS configuration.
4.2.2.1 Lenovo x3250 M6

To run on a Lenovo x3250 M6 server, the Generic Appliance Server requires several BIOS
modifications.
Check and/or modify the following parameters:
1. At server initialization, press F9 to enter BIOS configuration
2. Navigate to: Boot Manager > Boot Modes
3. Set the System Boot Mode option to Legacy Mode
4.2.2.2 Configuring BIOS settings

To run on an HP DL20 G9 server, the Generic Appliance Server requires several BIOS modifications.
Check and/or modify the following parameters:
1. At server initialization, press F9 to enter BIOS configuration
2. Navigate to: System Options > Boot Options
3. Set the Boot Mode option to Legacy BIOS Mode

4. Navigate to: System Options > USB Options
5. Set the USB Boot Support option to Disabled

6. Navigate to: System Options > SATA Controller Options
7. Set the Embedded SATA Configuration option to Enable SATA AHCI Support
8. Navigate to: Service availability
9. Set the Automatic Power-on option to Always On
4.2.3 Verifying hardware, isos and licenses

• The hardware characteristics of the host server and Generic Appliance Server components. The
minimum hardware requirements are:
Memory (RAM) size Hard disk size
Host OS 512 MB 12 GB
OmniPCX Enterprise 2 GB 80 GB
OXE-MS 1 GB 4 GB
Memory (RAM) size Hard disk size

Rainbow WebRTC gateway 2 GB 4 GB
• The .iso files which correspond to the applications to install:
Component File name (*.iso)

SLES Operating System bootdvd.YY.Z.xxx.xxx.x86_64.iso
Where:
• YY is the Release number
• Z is the service pack
Generic Appliance Server oxesws_x.yy.iso containing the following files:

• oxeswspreinst.bin (pre-Installation setup)
• oxeswsposinst.bin (post-Installation setup)
• checksystemcompatability.sh
• License files for the different Generic Appliance Server components: OmniPCX Enterprise licenses
and Flex-LM licenses
• If the license files are available, they must be placed in: /opt/sws_lic (sws_lic folder to be
created if not available) for auto detection of license files during post-installation
4.2.4 Installing the Generic Appliance Server

4.2.4.1 Installing the Generic Appliance Server via DVD/USB key
4.2.4.1.1 Installing SUSE Linux Enterprise Server on the host server

The SLES operating system is customized by Alcatel-Lucent Enterprise specifically for the Generic
Appliance Server.
The SLES OS is installed on the host using the AutoYaST configuration file. It contains installation
data, such as language, login, password, packages to install, and partitioning.
To install SLES on the host server:
1. Load the "ALE boot DVD" in the drive
Note:
This "ALE boot DVD" can also be used to install other Alcatel-Lucent Enterprise products.
After a few seconds, a welcome page displays
Figure 4.55: SLES installation wizard welcome page
Note:
If the server does not boot on the DVD drive, change boot order in the server BIOS.
2. Press F2 to select your language and your keyboard type
3. Scroll down the list of installation options and select OmniPCX Software Package
The corresponding AutoYaST file (autoinstoxesw.xml) is assigned to Boot Options.
Figure 4.56: SLES installation wizard options page (part 1)
4. Press Enter to start installation

Installation takes abound 30 minutes
All actions are performed automatically and the different pop-up windows indicate the installation
progression
5. As soon as the server reboots, press the eject button on the DVD drive and remove the DVD
6. Request for password change is prompted and needs to be changed if required:
• The default account is root
• The default password is letacla1
Do not forget your new password. It will be asked later.
7. Configure IP details for the server: enter successively:
• The IP address of the host server
• The FQDN of the host server
This information is the concatenation of host name and domain name
• The subnet mask of the host server
• The IP address of the default gateway
• The IP address of the DNS server
You are prompted to confirm your entries.
Figure 4.57: Installation network configuration page example
8. Confirm and press Enter to logout

Note:
After installing the SLES Operating System on the host server, an administration account (other than root) is
provided to access the host server (for example: access the Generic Appliance Server remotely). The credentials
are admin/letacla1 (default password).
The admin account does not allow to perform operations such as installing/uninstalling Generic Appliance Server,
or configuring virtual machines. These operations must be performed using the root account.
Warning:
This installation procedure is not applicable when updating the SLES Operating System on the host server (see:
Updating the SLES Operating System on page 238).
4.2.4.1.2 Getting the ALUID and posting it to eLP

The ALUID is necessary to obtain license files to install or replace an Generic Appliance Server. If you
ordered machines, the ALUID is displayed on the hardware sticker. The Generic Appliance Server is
delivered without a sticker.
To obtain license files:
1. After SLES OS installation, click the Not listed link and log in as root (with the password
changed previously)
The graphical interface is displayed
Note:
• According to the type of keyboard, the menu bar available at the top right of the login window allows to
select the language keyboard, or display a virtual keyboard on screen.
or
• The graphical interface can also be started with the command:

systemctl start display-manager
2. Right click the desktop and select Open Terminal
3. Enter the command /usr/bin/getaluid to retrieve the ALUID
4. Register your ALUID on eBuy (see the eLicensing Host Registration page of the Enterprise
Business Portal)
After your request is processed, you receive the necessary license files, bearing the extension
*.swk and *.ice
4.2.4.1.3 Installing the Generic Appliance Server
4.2.4.1.3.1 Process overview

Installation of the Generic Appliance Server on the host operating system can be performed in any of
the following ways:
• From the hard disk
• From the DVD or USB key
Note:
The key plugged on a USB port must be in FAT32 format.
The pre-installation and post-installation of the Generic Appliance Server can be performed either from
a Graphical User Interface (GUI), or from console in silent mode.
Pre-installation and post-installation are masked into a single command xxxxxxx.sh.
The following operations are performed during the pre-installation procedure:
• Compatibility check of hardware (free space availability, processor virtualization support)
• Compatibility check of host OS (version of OS, KVM support)
• Copy of mandatory files (Virtual Machine images, scripts) to the host
• Installation of Flex-LM on host OS
• Creation of networking bridge (br0) in the host OS to facilitate VM access the network outside
The following operations are performed during the post-installation procedure:
• Network configuration
• Creation of one VM for the OmniPCX Enterprise and, optionally, one VM for each optional
component (OXE-MS and Rainbow WebRTC gateway) with their corresponding images
By default, there is no optional component (OXE-MS and/or Rainbow WebRTC gateway) selected
at post-installation.
If it not selected at post-installation, the OXE-MS cannot be installed later on the Generic Appliance
Server. However, the Rainbow WebRTC gateway can be installed later using the webrtc.bin file
(see: Adding the Rainbow WebRTC gateway to Generic Appliance Server on page 239).
• Transfer of license files to the OmniPCX Enterprise VM
4.2.4.1.3.2 Pre-Installation procedure

Silent pre-installation
To perform the pre-installation of Generic Appliance Server Installer package:
1. Open a session on the server console as root
2. Insert the external media containing the .iso file (cd rom in the drive or USB key on a server port), or
copy it via SFTP.
The external media used can be either a cd rom with the iso image, or a USB key with the .iso file
mounted on the host. The USB key is the only media described here.
The USB key is automatically mounted in /run/media/root/.
3. Start the graphical interface, using the command:
4. Open a terminal session: Applications > Utilities > XTerm
5. Extract the installation files (.bin) from the .iso file using the commands:
mkdir /root/Desktop/GASiso
mount -o loop /<directory of iso>/oxe_sws-5.04.iso /root/Desktop/GASiso/
mkdir /root/Desktop/GASinstallfiles
cp -r /root/Desktop/GASiso/ /root/Desktop/GASinstallfiles/
umount /<directory of iso>/oxe_sws-5.04.iso
rm /root/Desktop/GASiso/
6. Enter the /root/Desktop/GASinstallfiles/GASiso/checksystemcompatibility.sh
command to check your system and fix the reported issues (if any)
7. Check that no error is logged in the file:
/var/log/OXEMS/InstallLog/checkingsystem.log
8. Optionally, if the license files are available, copy the license files from: /opt/sws_lic to /usr4/
BACKUP/OPS (these files are placed automatically in the directory). They will be to install from the
OmniPCX Enterprise install process via Swinst.
Note:
As soon as the manual option to add the license files is chosen (via Skip button), the process must be
manually executed
9. Locate the oxeswspreinst.bin file and give executable rights to this file, using the commands:
cd /root/Desktop/GASinstallfiles/GASiso/
#./chmod +x oxeswspreinst.bin
10. Start installation, using the command:
#./oxeswspreinst.bin -i Silent
During installation:
• The OmniPCX Enterprise, OXE-MS, and Rainbow WebRTC gateway image files are extracted
and copied in:
/home/OmniPCXEnterpriseSoftwareServer/Installation_Folder/imgs
• Configuration files and scripts are extracted and copied in:
/home/OmniPCXEnterpriseSoftwareServer/Installation_Folder/scripts
• The Flex-LM server is installed on the host
The Installation takes about 15 minutes to 25 minutes.
Installation status message (PRE INSTALLATION STATUS: SUCCESS/FAILED) is displayed on
screen at the end of the silent pre-installation. You can also verify the pre-installation status from the
file /etc/sws_preinstall.inf.
Pre-installation via GUI
To perform the pre-installation via GUI:
1. Locate the oxeswspreinst.bin file and give executable rights to this file, using the command:
#./chmod +x oxeswspreinst.bin
2. Execute the command:
#./oxeswspreinst.bin
The software installation wizard is started and the welcome page is displayed
Figure 4.58: Pre-installation wizard welcome page
3. Click Next
The License Agreement page is displayed
4. Accept the terms of the license agreement and click Next
The installation wizard verifies the server configuration such as the free space available, processor
virtualization support, OS version, and KVM support
Caution:
In case of failure, an error message is displayed on screen, and the pre-installation is stopped. Click
the Cancel button and relaunch the pre-installation after correcting the error.
5. If the server configuration is correct, click Next
The Pre-Installation Summary page is displayed
This page provides details on the Generic Appliance Server components to be installed (OmniPCX
Enterprise, OXE-MS, and WebRTC gateway virtual machines), hard disk sizing, and expected time
for installation
Figure 4.59: Pre-installation summary page example
6. Verify the Generic Appliance Server configuration, and click Next

The pre-installation starts. A progress bar allows you to follow the pre-installation.
Caution:
Once launched, the pre-installation cannot be stopped.
At pre-installation:
• The OmniPCX Enterprise, OXE-MS, and Rainbow WebRTC gateway image files are extracted
and copied in:
/home/OmniPCXEnterpriseSoftwareServer/Installation_Folder/imgs
• Configuration files and scripts are extracted and copied in:
/home/OmniPCXEnterpriseSoftwareServer/Installation_Folder/scripts
• The Flex-LM server is installed on the host
At the end of the process, the Install Complete page is displayed
7. Click Done to exit the wizard
4.2.4.1.3.3 Post-installation procedure

Silent post-installation
Prerequisite: the post-installation binary files must be copied on a directory of the server and the pre-
installation performed (see: Silent pre-installation on page 209).
To perform the post-installation:
1. Enter the post-installation inputs in the following configuration file:
/home/OmniPCXEnterpriseSoftwareServer/Installation_Folders/scripts/
PostInstall.cfg
PostInstall.cfg file example with an OmniPCX Enterprise configuration without redundancy, an
OXE-MS, and a WebRTC gateway:
//THIS FILE IS USED FOR CONFIGURING OXE SOFTWARE SERVER FOR SILENT POST-INSTALLATION
//**********************************************************************************
//OXE configuration details

COUNTRY_CODE=FR
REDUNDANCY=NO
CPU_HOST_NAME=xa000000
CPU_IP_ADDRESS=172.19.106.210
SUBNET_MASK=255.255.255.0
DEFAULT_GATEWAY_NAME=default
GATEWAY_ADDRESS=172.19.106.254
NETWORK_NUMBER=1
NODE_NUMBER=1
NODE_NAME=node000000
//Below given parameters are applicable redundancy mode

CPU_MAIN_NAME=
CPU_MAIN_IP_ADDRESS=
TWIN_HOST_NAME=
TWIN_IP_ADDRESS=
TWIN_SUBNET_MASK=
//Below given parameters are applicable only for SPATIAL redundancy mode
TWIN_GATEWAY_IP_ADDRESS=
TWIN_GATEWAY_NAME=
TWIN_MAIN_NAME=
TWIN_MAIN_IP_ADDRESS=
//OMS configuration details

NUMBER_OF_OMS=1
OMS_IP_ADDRESS=172.19.106.220
//WebRTC Gateway configuration details

INSTALL_WEBRTC_GW=1
IP=10.2.3.4
NETMASK=255.255.255.0
GATEWAY=10.2.3.254
HOSTNAME=rainbow-mpgw
HOSTDOMAIN=mycompany.com
DNS=10.2.3.253
NTP=10.2.3.253
PROXY=http://10.2.3.252:8000/
MPROXY=tcp
TURN_SERVER=turn-eu1.openrainbow.com
PBXID=PBXa1b1-2wxy-3c3d-6789-4e4f-g556-7h89-10i9
PBX_DOMAIN=172.19.106.210
RAINBOW_DOMAIN=openrainbow.com
RAINBOW_HOST=openrainbow.com
SSH=true
2. Locate the oxeswsposinst.bin file and give executable rights to this file, using the command:
#./chmod +x oxeswsposinst.bin
3. Enter the command:
#./oxeswsposinst.bin -i Silent –f /home/OmniPCXEnterpriseSoftwareServer/
Installation_Folders/scripts/PostInstall.cfg
Installation status message (POST INSTALLATION STATUS: SUCCESS/FAILED) is displayed on
screen at the end of the silent post-installation. You can also verify the post-installation status from
the file /etc/sws_postinstall.inf.
The following table gives a brief description of all the parameters of the configuration file
(PostInstall.cfg):
Field Value
OXE configuration details
COUNTRY_CODE Your country code (for example: FR for France)
Field Value
REDUNDANCY Type of redundant configuration:
• NO: no redundancy
• LOCAL: local redundancy
• SPATIAL: spatial redundancy
CPU_HOST_NAME CPU hostname

CPU_IP_ADDRESS CPU IP address
SUBNET_MASK Network mask
DEFAULT_GATEWAY_NAME Default gateway name
GATEWAY_ADDRESS Default gateway IP address
NETWORK_NUMBER Network number
NODE_NUMBER Node number
NODE_NAME Node name
The following parameters applies for redundancy:
CPU_MAIN_NAME Main CPU name
CPU_MAIN_IP_ADDRESS Main CPU IP address
TWIN_HOST_NAME Twin CPU name
TWIN_IP_ADDRESS Twin CPU IP address
The following parameters applies for spatial redundancy:
TWIN_SUBNET_MASK Network mask for twin CPU
TWIN GATEWAY IP ADDRESS IP address of the default gateway associated to the twin CPU
TWIN GATEWAY NAME Name of the default gateway associated to the twin CPU
TWIN MAIN NAME Name used when the twin CPU role is main
TWIN MAIN IP ADDRESS IP address when the twin CPU role is main
OMS configuration details
NUMBER OF OMS Number of OXE-MS:
• 0: no OXE-MS
• 1: one OXE-MS
OMS IP ADDRESS OXE-MS IP address (if the NUMBER OF OMS field is set to 1)
WebRTC GW configuration details
IP IP address of the Rainbow WebRTC gateway
NETMASK Network mask
GATEWAY Default gateway IP address
HOSTNAME Hostname of the Rainbow WebRTC Gateway
HOSTDOMAIN Domain name of the Rainbow WebRTC Gateway
Field Value
DNS IP address of the DNS server used by the Rainbow WebRTC
Gateway for name resolution
NTP IP address of the NTP server used by the Rainbow WebRTC
Gateway for time and date synchronization
PROXY Address of the proxy used by the Rainbow WebRTC gateway for
communication (for example: http://10.2.3.252:8080/)
MPROXY Protocol used for the media flows exchanged through the proxy.
Value is off, tcp or tls
PBXID Unique identifier of your OmniPCX Enterprise in the Rainbow Cloud
infrastructure (for example: PBXa1b1-2wxy-3c3d-6789-4e4f-
g556-7h89-10i9)
PBX_DOMAIN OmniPCX Enterprise IP address (or OmniPCX Enterprise FQDN in
case of spatial redundancy)
RAINBOW_DOMAIN Domain name of the Rainbow Cloud infrastructure
RAINBOW_HOST Hostname of the Rainbow Cloud infrastructure
TURN_SERVER Address of the TURN server used by the Rainbow WebRTC
gateway for media flow relay (for example: turn-
eu1.openrainbow.com)
SSH Option to enable connection to the Rainbow WebRTC gateway via
SSH. Value is true or false
Note:
• For more information on the OmniPCX Enterprise parameters, refer to the netadmin management chapter in
document [13].
• For more information on the Rainbow WebRTC Gateway, refer to the Rainbow Help Center.
Post-installation via GUI
#./oxeswsposinst.bin
3. Once the welcome message shows, click the Next button
Figure 4.60: Post installation wizard welcome page
4. In the local settings page, select your country code (for OmniPCX Enterprise database and time
zone)
Figure 4.61: Local settings wizard page example
5. Click Next
The network settings page is displayed

6. Configure the OmniPCX Enterprise with its node related information details (Netadmin details)
• If the OmniPCX Enterprise is not duplicated:
1. Select the No Redundancy radio button in the OXE IP Configuration
2. Enter the parameters in the Configuration Details.
For more information about the OmniPCX Enterprise parameters, refer to the netadmin
management chapter in [13].
Figure 4.62: OmniPCX Enterprise wizard page example
• If the OmniPCX Enterprise is configured as Local redundancy:

1. Select the Local Redundancy radio button in the OXE IP Configuration
Note:
Twin CPU configuration must be managed whatever the state of twin CPU.
Figure 4.63: OmniPCX Enterprise network settings for local redundancy wizard page example
• If the OmniPCX Enterprise is configured as Spatial redundancy:

1. Select the Spatial Redundancy radio button in the OXE IP Configuration
Figure 4.64: OmniPCX Enterprise network settings for spatial redundancy wizard page example
7. Click the Next button

The configuration screen of the optional components (OXE-MS and Rainbow WebRTC gateway) is
displayed
8. If the Generic Appliance Server includes an OXE-MS:
1. Select the OMS check box
2. In the OMS details frame, enter the IP address of the OXE-MS
Caution:
An error message for insufficient RAM is displayed when selecting optional components (OXE-MS
and/or Rainbow WebRTC gateway). For more details on the minimum hardware requirements (see:
Verifying hardware, isos and licenses on page 203).
Figure 4.65: OXE-MS configuration page example
9. If the Generic Appliance Server includes a Rainbow WebRTC gateway:

1. Select the Rainbow WebRTC check box and click Next
2. In the WebRTC GW configuration page, complete the following fields:
Field Value
Network configuration
IP address Enter the IP address of the Rainbow WebRTC gateway
Netmask Enter the network mask
Gateway address Enter the default gateway IP address
Hostname Enter the hostname of the Rainbow WebRTC Gateway
Hostdomain Enter the domain name of the Rainbow WebRTC Gateway
DNS Enter the IP address of the DNS server used by the Rainbow WebRTC
NTP Enter the IP address of the NTP server used by the Rainbow WebRTC
PROXY Enter the address of the proxy used by the Rainbow WebRTC gateway
for communication (for example: http://10.2.3.252:8080/)
TURN SERVER Enter the address of the TURN server used by the Rainbow WebRTC
Gateway configuration
Field Value
PBXID Enter the unique identifier of your OmniPCX Enterprise in the Rainbow
Cloud infrastructure (for example: PBXa1b1-2wxy-3c3d-6789-4e4f-
g556-7h89-10i9)
PBX_DOMAIN Enter the OmniPCX Enterprise IP address (or OmniPCX Enterprise
FQDN in case of spatial redundancy)
RAINBOW_DOMAIN Enter the domain name of the Rainbow Cloud infrastructure. The
Rainbow domain name is initialized to openrainbow.com. It is the
default value
RAINBOW_HOST Enter the hostname of the Rainbow Cloud infrastructure
MPROXY If a proxy has been declared in the PROXY field, use the drop-down
menu to select the protocol (tcp or tls) used for the media flows
exchanged through the proxy
Enable SSH If required, select the check box to enable connection to the Rainbow
WebRTC gateway via SSH
Caution:
Figure 4.66: Rainbow WebRTC gateway configuration page example
10. Click the Next button to provide the OXE License details
Typically, license files have been already installed or are stored on a data carrier.
• When license files are installed: all files must be copied to a single directory. The files
including .zip, .swk, hardware.mao, software.mao, .ice extension are available in the
path: /opt/sws_lic
The OXE Licenses files is displayed.
Click Next
• When any of the license files is missing in the target machine (/opt/sws_lic), two options can
be chosen:
1. If you wish to manually provide license files after the post-installation process, click the Skip
button
2. If the license files are on a USB media, execute the following procedure:
1. Plug in the USB media hosting the license files
Wait for a few seconds
Figure 4.67: Licensing wizard page example
2. Click the Browse button and select the license files

• If all files are found, a success message OK is displayed and the Next button is
available
• If some files are missing, an error message Not OK is displayed. Fix the problem or
click Skip to make the Next button available
11. Click Next
The Post-installation Summary page is displayed with all the entered settings
Figure 4.68: Post installation wizard summary page
12. Check server parameters

If settings are correct, click Install to start configuration. The duration is around 20 minutes.
The following page shows the configuration progress status in steps
Figure 4.69: Post installation wizard progress page
The data captured through the post-installation pages are written into a configuration file. This
configuration file is used to proceed to the following steps to configure through scripts:
• Network Configuration:
All the network parameters such as OXE IP, CPU Name, network number, router details are
extracted from configuration file and updated in to the Netadmin file to enable network
configuration
• Empty database configuration:
An empty database is created as per the country chosen during post installation
• License configuration:
License files .zip, hardware.mao, software.mao, .swk, .ice are placed in the OXE directory /
usr4/BACKUP/OPS for future installation
The .ice file is placed in the directory /opt/Alcatel-Lucent.data/licenses/ on the Suse
OS for FlexLM server usage
• Network Configuration for OXE-MS:
Network parameter of OXE-MS, such as OXE-MS IP, CS IP and subnet mask are updated in the
oms.cfg file to enable network configuration in OXE-MS
After successful configuration, the OmniPCX Enterprise starts along with the OXE-MS.
13. At the end of the post-installation, check the installation status displayed in the Install
Complete page:
• In case of success, click the Done button
• In case of failure, the corresponding error message with the information of log file displays, see:
Un-installation procedure on page 243
After correcting the errors, try again the post-installation procedure.
Figure 4.70: Post installation completion page
14. Once installation is complete, you can verify the versions of Generic Appliance Server, patches,
OXE-MS and FlexLM server from the sws_release file available in the /etc path
15. Configure the OXE VM and OXE-MS VMs
Connect to the virtual machines in any of the following manners
• From a Telnet terminal
• From the KVM console:
1. Open a session on the KVM console
2. Start the graphical interface, using the command:
3. Go to: Activities
4. Click the Show Applications icon, then the Yast icon
The Administrator Settings window is displayed
5. Select the Virtual Machine Manager icon
The Virtual Machine Manager window opens to access VMs
6. From the VM Manager home page, open one of virtual machines by clicking its name.
4.2.4.2 Installing the Generic Appliance Server via S.O.T.

Prerequisite: The S.O.T. must be deployed on a virtualized environment. For details on S.O.T.
deployment and startup, see document [45].
To install the Generic Appliance Server via S.O.T.:
3. Select GAS and click Next
4. Select the media on which the bootdvd and Generic Appliance Server software package are
available:
6. Select the appropriate files listed on screen and click Declare media

Note:
The Description field is not mandatory.
9. Click Next
The GAS settings configuration page opens
10. Complete the fields with the Generic Appliance Server settings: keyboard, hostname, MAC address
and IP address of the server hosting the Generic Appliance Server.
Figure 4.73: GAS settings page example
11. Click Next

12. Verify the software version and click Deploy
13. If you launch immediately the deployment using the Deploy button, wait around 15 seconds to be
sure that the S.O.T. is ready to receive the request from the host server on which the Generic
Appliance Server software must be deployed, then start PXE boot on the host server.
The host server performs a network boot, connects to the S.O.T. and loads the bootDVD and
Generic Appliance Server software. The installation automatically starts on the host server.
Monitor the progress of the Generic Appliance Server installation from the S.O.T. interface.
After installation, a post-installation wizard starts on the host server.
14. From the console connected to the host server, complete the settings of the Generic Appliance
Server components (OmniPCX Enterprise, OXE-MS, and Rainbow WebRTC gateway)
For more details, see the procedure of Post-installation via GUI on page 215 (starting from step 3).
4.3 Ethernet bonding configuration

4.3.1 Process overview
The Ethernet bonding configuration for Generic Appliance Server consists in:
1. Configuring a bonding interface including all the Ethernet interfaces on page 230
2. Including the bonding interface in the default bridge interface (br0) on page 231
All configuration is performed on the host operating system (SLES). There is no configuration change
on IMM/ILO, KVM hypervisor, and OXE/OXE-MS/Rainbow WebRTC gateway VMs.
Note:
• IMM/ILO are configured on the BIOS and are tied to a specific Ethernet card.
• The VMs are already configured to use the interface br0 for communication.
4.3.2 Configuring a bonding interface including all the Ethernet interfaces

1. From the KVM interface, start the graphical interface and go to: YaST2 > Network Settings
2. Select the Overview tab to access the Ethernet device list
Figure 4.75: Ethernet device list example
3. If needed, remove the Ethernet interfaces from the default bridge interface (br0):
1. Select the br0 interface and click Edit
2. Unselect the Ethernet interfaces in the Bridged Devices tab
4. If a bonding device is not available, click Add and select Bond in the Device Type field, then
select Next
5. For IP configuration, select No Link and IP Setup (Bonding Slaves)
6. Select the Bond Slaves tab, and the target Ethernet devices to include in the bonding interface
7. Verify the Bond Driver Options field present at the bottom of the Bond Slaves tab. It is
recommended to set the option to: mode=balanced-rr miimon=100
Figure 4.76: Bond Driver Options field example
8. Click Next to go back to Network Settings

For more details on the bonding interface configuration, refer to:
https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_bond.html
4.3.3 Including the bonding interface in the default bridge interface (br0)
1. From the YaST2 tool, select the bridge interface br0 and click Edit
2. Verify IP setting is correctly configured for the bridge interface (static or dynamic, depending on
requirement)
3. In the Bridged Devices tab, select the new created bonding interface
4. Click Next to go back to Network Settings
5. Verify the details in the Routing tab, and ensure that a valid default gateway is configured for the
bridge interface
6. Click OK to save the configuration and exit the tool
The host is now configured with Ethernet bonding.
Verify the network connectivity is not disturbed when bringing an Ethernet interface down.
Figure 4.77: Final configuration example
4.4 VLAN tagging configuration

This operation allows to tag the host operating system (SLES) and the OXE and OXE-MS VMs in the
same VLAN xxxx:
1. From the host operating system (SLES), enter the following commands:
cd /etc/sysconfig/network
cp ifcfg-eth0 ifcfg-vlanxxxx
2. Open the ifcfg-vlanxxxx file with the vi editor, and add the following fields:
vi ifcfg-vlanxxxx
VLAN='yes'
ETHERDEVICE='eth0'
3. Open the ifcfg-br0 file with the vi editor, and modify the following field:
vi ifcfg-vlanxxxx
BRIDGE_PORTS='vlanxxxx'
4. Restart the network with the command:
rcnetwork restart
Wait until the end of the restart. VLAN tagging at host level is now complete.
5. Stop completely the OXE and OXE-MS VMs (restart does not work)
6. Start the OXE and OXE-MS VMs
4.5 Remote login

After SLES OS installation, a user can login using the default account (root) and the new password.
After successful SLES OS installation, in addition to the root account, the admin account (with no
root rights) is provided for general purposes (e.g.: remote login). The login for this account is admin
and the default Password is letacla1.
The admin user does not have permission to perform root user operations such as Installing/
Uninstalling Generic Appliance Server, managing virtual machines etc. In order to perform such
operations, this user must switch to root.
4.6 Remote desktop connection

This chapter describes how to set up a remote connection to the SLES operating system of Generic
Appliance Server.
Remote connection can be used when local connection to the SLES with a screen, keyboard and
mouse is necessary, for example to restart the OmniPCX Enterprise VM, OXE-MS VM or the FlexLM
service.
4.6.1 Activating the VNC server on Generic Appliance Server

1. Connect as root on the host of Generic Appliance Server
2. Enter the following command:
[root@gas ~]# vncserver -geometry 1024x768 -depth 32
3. When prompted, enter the password that will be used by the VNC client for the connection
You will require a password to access you desktops.
Password:
Verify:
4. You are prompted to enter a view-only password (optional), then the log file name is displayed,
gas:2.log in our example
Would you like to enter a view-only password (y/n)? n
New 'gas:2 (root)' desktop is gas:2
Creating default startup script /root/.nvc/xstartup
Creating default config /root/.vnc/.vnc/config
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/gas:2.log
5. Enter the following commands to check logs
ll /root/.vnc/gas.phisa.com\:2.log
cat /root/.vnc/gas.phisa.com\:2.log
6. Check that the following line is present, indicating that the VNC server is activated:
vncext: Listening for VNC connections on all interface(s), port 5902
4.6.2 Connecting to Generic Appliance Server from a VNC client

The following presents the connection using TightVNC viewer.
1. Start TightVNC viewer on your client workstation
2. Enter the IP address of the Generic Appliance Server and indicate the port defined in the VNC
server, for example:
10.69.201.130:2 if the port 5902 is used
3. Click Connect and enter the password defined when activating VNC on Generic Appliance Server
The connection is done and you have access to the SLES operating system on the Generic
Appliance Server.
4.6.3 Checking connection on Generic Appliance Server

1. Enter the following command
cat /root/.vnc/gas.phisa.com\gas:2.log
2. You can check the history of connections via VNC
Mon Oct 26 17:05:01 2020
Connections: accepted: 192.168.201.98::58497
SConnection: Client needs protocol version 3.8
SConnection: Client requests security type VncAuth(2)
Mon Oct 26 17:05:05 2020

VNCSConnST: Server default pixel format depth 32 (32bpp) little-endian rgb
max 255,255,255 shift 16,8,0
VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888
4.7 Maintenance
4.7.1 Checking system compatibility
To check system compatibility, run the script checksystemcompatability.sh in a terminal and
ensure that no error is logged in the file:
/var/log/oxems/InstallLog/checkingsystem.log
If errors are logged, take corrective actions and run the script until all the errors are solved. This file
(which verifies OS version, KVM support, etc. of the target machine) is available along with
oxeswspreinst.bin.
4.7.2 Displaying the Generic Appliance Server version

To display the Generic Appliance Server version, open a terminal on the host and enter the command:
cat /etc/sws_release
4.7.3 Shutting down and restarting VMs

4.7.3.1 Managing VMs through script commands
The following scripts allow to manage the OmniPCX Enterprise, OXE-MS, and Rainbow WebRTC
gateway virtual machines from the host operating system:
• oxe_cmd for the OmniPCX Enterprise VM
• oms_cmd for the OXE-MS VM
• webrtcgw_cmd for the Rainbow WebRTC gateway VM
The backup and restore scripts are available in the following folder: /home/
OmniPCXEnterpriseSoftwareServer/Installation_Folders/Tools
4.7.3.1.1 OXE management

From host OS, OmniPCX Enterprise management can be done by executing the script oxe_cmd (for
the OmniPCX Enterprise Virtual Machine named “OXEVM”).
Menu options:
• start: to start the VM
• stop: to shut down the VM
• restart: to shut down and restart the VM
• forcestop: to stop the VM
• status: to give the status of the VM (not registered, stopped, started, suspended)
4.7.3.1.2 OXE-MS Management

From host OS, OXE-MS management can be done by executing the script oms_cmd (for the OXE-MS
Virtual Machine).
The following menu options are offered:
• stop: to stop the VM
• status: to give the status (start or stop) of the VM
4.7.3.1.3 Rainbow WebRTC gateway Management

From host OS, Rainbow WebRTC gateway management can be done by executing the script
webrtc_cmd (for the Rainbow WebRTC gateway Virtual Machine).
When running the script, you are first prompted to select the VM name of the Rainbow WebRTC
gateway.
After selecting the Rainbow WebRTC gateway, the following menu options are offered:
• status: to give the status (start or stop) of the VM

4.7.3.2 Managing VMs via GUI

You can also start and stop a virtual machine using the Virtual Machine Manager menu in the drop-
down menus.
Note:
These submenus are equivalent to an on/off switch on a real machine. Perform a clean shutdown before you stop
a virtual machine.
Menu options:
4.7.4 Flex-LM server management

Flex-LM service can be managed with the following command:
#service flexlmd {start|stop|restart|status}
If the Flex-LM license file (.k2 or .ice) has not been selected at post-installation, perform the following:
1. Copy the license file to the directory /opt/Alcatel-Lucent/data/licenses/
2. Restart the Flex-LM service with the command:
service flexlmd restart
3. Verify the Flex-LM service state with the command:
service flexlmd status
Figure 4.78: Example of a running Flex-LM service
Figure 4.79: Example of a Flex-LM service out of service (no license file found)
4.7.5 Backing up and restarting VMs

VM Backup:
Vmbackup.sh script takes the backup of OmniPCX Enterprise, OXE-MS VM, or Rainbow WebRTC
gateway VM
Vmbackup.sh vmName outputVMName.img
VM Restore:
Vmrestore.sh script creates OmniPCX Enterprise, OXE-MS, or Rainbow WebRTC gateway VM in
the target machine
Vmrestore.sh outputVMName.img outputVMName.xml
The backup images and xmls are available in the following folder: /home/
OmniPCXEnterpriseSoftwareServer/Backup.
4.7.6 Rebooting or stopping the server

To reboot or stop the server:
• From the graphical environment, use the menu to stop the server
• From a terminal of the host, use the command: shutdown -r now to reboot the server or
shutdown -h now to stop the server
All the VMs are stopped properly.
4.7.7 Modifying the server IP address

To modify the server IP address, Ethernet bonding (see: Ethernet bonding configuration on page 229)
and VLAN tagging (see: VLAN tagging configuration on page 232) must not be configured on the
Generic Appliance Server.
Open a terminal and enter the commands:
cd /usr/bin
/setIPAddress.sh
4.7.8 Rehosting
There is no specific command to rehost the OmniPCX Enterprise, OXE-MS or Rainbow WebRTC
gateway.
• To rehost the OmniPCX Enterprise:
1. Open a terminal on the OmniPCX Enterprise VM
2. Enter the commands: netadmin
• To rehost the OXE-MS:
1. Open a terminal on the OXE-MS VM
2. Enter the command: omsconfig
• To rehost the host (changing IP parameters of the host):
1. Open a terminal on the host
2. Execute the script: setIPAddress.sh present at /usr/bin/
• To rehost the Rainbow WebRTC Gateway:
1. Open a terminal on the Rainbow WebRTC Gateway VM
mpnetwork --IP=<new IP address> --NETMASK=<new netmask> --Gateway=<new
gateway>
4.7.9 Updating the SLES Operating System

As of Generic Appliance Server version 8.00, the SLES Operating System can be updated by
executing the script gas-suse-update.sh available in the following folder:
/home/OmniPCXEnterpriseSoftwareServer/Installation_Folders/Tools
To update the SLES Operating System:

1. Insert the external media containing the new SLES OS boot file (DVD in the drive or USB key on a
server port), or copy the new SLES OS boot file on the host server
(bootdvd.x.x.xxx.xxx.x86_64.iso)
2. Mount the iso file via the command:
mount <source directory> <target directory>
Example: If present on DVD, mount the iso file via the command:
mount /dev/cdrom /media/cdrom
3. Open a terminal on the host server
4. Execute the script gas-suse-update.sh, with the target directory as argument:
gas-suse-update.sh /media/<target directory>
The virtual machines (OmniPCX Enterprise, OXE-MS and Rainbow WebRTC gateway) are stopped
before SLES Operating System update. The SLES Operating System reboots after a successful
update.
The update status is displayed on the terminal, and detailed logs are available in:
• /var/log/suse-update.log and
• /var/log/gas-suse-update.log.
4.7.10 Upgrading OmniPCX Enterprise and OXE-MS

To upgrade the OmniPCX Enterprise (version, patch, ...), use the installation server in the same way as
for a regular OmniPCX Enterprise (see: Procedures for installation on the hard drive on page 19).
The OXE-MS is automatically updated when the OmniPCX Enterprise is upgraded.
4.7.11 Adding the Rainbow WebRTC gateway to Generic Appliance Server

If it was not selected at Generic Appliance Server installation, the Rainbow WebRTC gateway can be
installed later on the Generic Appliance Server, using the webrtc.bin file delivered with the Generic
Appliance Server software package.
The Rainbow WebRTC gateway installation consists of:
• Rainbow WebRTC gateway pre-installation on page 239
• Rainbow WebRTC gateway post-installation on page 240
The two operations can be performed either from a Graphical User Interface (GUI), or from console in
silent mode.
4.7.11.1 Rainbow WebRTC gateway pre-installation

To perform the pre-installation:
1. Open a session on the server console as root and copy the webrtc.bin file on a server directory
2. Locate the webrtc.bin file and give executable rights to this file, using the command:
#./chmod +x webrtc.bin
3. For a silent pre-installation, execute the command:
#./webrtc.bin -i Silent
During installation, the Rainbow WebRTC gateway files are extracted and copied on the server.
Installation status message (PRE INSTALLATION STATUS: SUCCESS/FAILED) is displayed on

screen at the end of the silent pre-installation. You can also verify the pre-installation status from the
file /etc/webrtc_preinstall.inf file.
4. For a pre-installation via GUI, perform the following operations:
#./webrtc.bin
The software installation wizard is started and the welcome page is displayed.
The installation wizard verifies the server configuration. An error message is displayed if a Web
RTC gateway is already available, or an OXE VM is not available.
2. Click Next
The Pre-Installation Summary page is displayed.
This page provides details on the component to be installed (WebRTC gateway), hard disk
sizing, and expected time for installation.
3. If the WebRTC gateway configuration is correct, click Install
The pre-installation starts. A progress bar allows you to follow the pre-installation.
Caution:
Once launched, the pre-installation cannot be stopped.
At pre-installation, the Rainbow WebRTC gateway files are extracted and copied on the server.
At the end of the process, the Install Complete page is displayed.
4. Click Done to exit the wizard
4.7.11.2 Rainbow WebRTC gateway post-installation
4.7.11.2.1 Rainbow WebRTC gateway silent post-installation

Prerequisite: the post-installation binary files must be copied on a directory of the server and the pre-
installation performed (see: Rainbow WebRTC gateway pre-installation on page 239).
To perform the Rainbow WebRTC gateway post-installation:
1. Complete the Rainbow WebRTC gateway parameters in the following configuration file:
/home/OmniPCXEnterpriseSoftwareServer/Installation_Folders/scripts/
PostInstall.cfg
Example of Rainbow WebRTC gateway parameters in PostInstall.cfg file:
……
//WebRTC Gateway configuration details
INSTALL_WEBRTC_GW=1
IP=10.2.3.4
NETMASK=255.255.255.0
GATEWAY=10.2.3.254
HOSTNAME=rainbow-mpgw
HOSTDOMAIN=mycompany.com
DNS=10.2.3.253
NTP=10.2.3.253
PROXY=http://10.2.3.252:8000/
MPROXY=tcp
TURN_SERVER=turn-eu1.openrainbow.com
PBXID=PBXa1b1-2wxy-3c3d-6789-4e4f-g556-7h89-10i9
PBX_DOMAIN=172.19.106.210
RAINBOW_DOMAIN=openrainbow.com
RAINBOW_HOST=openrainbow.com
SSH=true
For details on Rainbow WebRTC gateway parameters, see: Silent post-installation on page 212.
#./oxeswsposinst.bin -i Silent –f /home/OmniPCXEnterpriseSoftwareServer/
Installation_Folders/scripts/PostInstall.cfg
Installation status message is displayed on screen at the end of the silent post-installation. You can
also verify the post-installation status from the file /etc/sws_postinstall.inf.
Note:
For more information on the Rainbow WebRTC Gateway, open a web browser and enter the following URL:
Rainbow Help Center.
4.7.11.2.2 Rainbow WebRTC Gateway post-installation via GUI

#./oxeswsposinst.bin
The post installation wizard is started and the welcome page is displayed.
3. Click Next
The configuration screen of the Rainbow WebRTC gateway is displayed
4. In the WebRTC GW configuration page, Complete the following fields:
Field Value
Network configuration
IP address Enter the IP address of the Rainbow WebRTC gateway
Netmask Enter the network mask
Gateway address Enter the default gateway IP address
Hostname Enter the hostname of the Rainbow WebRTC Gateway
Hostdomain Enter the domain name of the Rainbow WebRTC Gateway
DNS Enter the IP address of the DNS server used by the Rainbow WebRTC
NTP Enter the IP address of the NTP server used by the Rainbow WebRTC
PROXY Enter the address of the proxy used by the Rainbow WebRTC gateway for
communication (for example: http://10.2.3.252:8080/)
TURN SERVER Enter the address of the TURN server used by the Rainbow WebRTC
Gateway configuration
PBXID Enter the unique identifier of your OmniPCX Enterprise in the Rainbow
Cloud infrastructure (for example: PBXa1b1-2wxy-3c3d-6789-4e4f-
g556-7h89-10i9)
Field Value
PBX_DOMAIN Enter the OmniPCX Enterprise IP address (or OmniPCX Enterprise FQDN
in case of spatial redundancy)
RAINBOW_DOMAIN Enter the domain name of the Rainbow Cloud infrastructure. The Rainbow
domain name is initialized to openrainbow.com. It is the default value
RAINBOW_HOST Enter the hostname of the Rainbow Cloud infrastructure
MPROXY If a proxy has been declared in the PROXY field, use the drop-down menu
to select the protocol (tcp or tls) used for the media flows exchanged
through the proxy
Enable SSH If required, select the check box to enable connection to the Rainbow
WebRTC gateway via SSH
Caution:
Figure 4.80: Rainbow WebRTC gateway configuration page example
5. Click Next several times until the Post-installation Summary page is displayed with all the
entered settings
Figure 4.81: Post installation wizard summary page
6. If settings are correct, click Install to start configuration.

The post-installation starts. A progress bar allows you to follow the post-installation.
7. At the end of the post-installation, check the installation status displayed in the Install
Complete page and click Done
4.7.12 Connecting a UPS

For more information concerning UPS support with Generic Appliance Server, refer to document [25].
4.7.13 Reporting an issue

In case of installer package failure or crash, the incidents are logged in the log file:
/home/OmniPCXEnterpriseSoftwareServer/Logs
4.7.14 Un-installation procedure

Use this procedure to completely uninstall the Generic Appliance Server:
1. Open a terminal on the host
2. Go to the folder:
/home/OmniPCXEnterpriseSoftwareServer/Uninstall
3. For a silent execution, execute the command:
#. /oxeswsuninst -i Silent
4. Go to: home and check that the directory Generic Appliance Server has been suppressed
After uninstalling the Generic Appliance Server:
• All VMs and related Folders/Files created during the installation are removed.
• A new post-installation of the Generic Appliance Server can be performed in silent mode or via GUI
Chapter
5 Non OmniPCX Enterprise virtual

machines
5.1 OXE Media Services installation

5.1.1 OXE-MS overview
5.1.1.1 Overview
The OXE Media Services (called OXE-MS in the rest of this document) offer media processing features
that used to be provided by the GD-3 board of an OmniPCX Media Gateway. The OXE-MS does not
require any specific hardware for media processing features: it is a fully-fledged software solution that
can be deployed on any of the following virtualization environments:
• A VMware ESXi hypervisor, installed on the physical server. In this configuration, a virtual machine
can be created to host the OXE-MS (see: Deploying the OXE-MS virtual machine on the target
physical server on page 256).
OXE-MS:
- Suse Operating System
- OXE-MS software
Virtual Machine
Vmware ESXi
Physical server
Figure 5.82: OXE-MS Installation example on a VMware ESXi environment
• A Kernel-based Virtual Machine (KVM) solution based:

• Before R11.2, a Red Hat Enterprise Linux operating system and a KVM virtualization layer
• As of R11.2, a Suse Linux Enterprise operating system and a KVM virtualization layer
In this configuration, a virtual machine can be created to host the OXE-MS (see: OXE-MS
installation process overview on page 249).
Chapter 5 Non OmniPCX Enterprise virtual machines
OXE-MS:
- OXE-MS software
Virtual Machine
KVM virtualization layer
Suse Operating System
Physical server
Figure 5.83: OXE-MS Installation example on a KVM environment
• The virtualization solution of Windows Server (Hyper-V), installed on a physical server. In this
configuration, a virtual machine can be created to host the OXE-MS.
OXE-MS:
- OXE-MS software
Virtual Machine
Hyper-V virtualization layer
Windows Server Operating System
Physical server
Figure 5.84: OXE-MS Installation example on a Hyper-V environment
In these virtualized environments, other virtual machines can be created on the server to host other
applications (such as the OmniPCX Enterprise or Alcatel-Lucent 4645 voice mail).
Virtual Machines
OmniPCX
OXE-MS
Enterprise
Virtualized environment
Physical server
Figure 5.85: Virtualized environment example with two virtual machines
Notes:
• Only one instance of OXE-MS per virtual machine is allowed. The OXE-MS cannot operate when other
applications (such as the OmniPCX Enterprise or Alcatel-Lucent 4645 voice mail) are installed on the same
virtual machine
• The OXE-MS runs in the virtual machine with its own IP address
• The OXE-MS can operate with hardware Media Gateway such as Common Media Gateway
5.1.1.2 Features provided

The OXE-MS provides the following main features:
• VoIP codecs (G711 and G729)
• G.711 (20 ms VoIP framing)
• G.729 (up to R12.0: 20 ms VoIP framing , as of R12.0: 20/40ms VoIP framing)
• Voice guides (Up to 30 per PCM. Max. 120)
As of R11.0, only static voice guides are supported.
As of R11.0.1 (K1.5) static and dynamic voice guides are supported.
As of R12, dynamic voice guide can be recorded with OXE-MS.
• Generation of tones
• Three-party conferences
• 6-party conference (as of R11.0.1)
• G.722 conference
• RTP payload for DTMF digits (RFC 4733 or previously called RFC 2833)
• QoS tagging (802.1p/DiffServ)
• Codec transcoding
• H.323 (only for ABC-F):
• As of R11.0.1 (K1.5) , only one H.323 access is supported
• As of R11.1, two H.323 accesses are supported
Notes:
• Configurations of trunk groups and analog/TDM/IP sets are not supported.

• The OXE-MS does not support A/µ law conversion.
5.1.1.3 G.722 conference

As of R11.1, conferences on OXE-MS can support participants connected with G.711, G.729 or G.722
coding algorithms.
When a participant with G.722 speaks, participants with G.722 receive a high quality voice flow.
Participants with G.711 or G.729 receive a lower quality voice flow.
Participants with G.711 (or G.729) speaks, other participants listen with their corresponding algorithm.
The voice quality is always G.711(G.729) .
Conditions for a G.722 conference are:
• The G722 conference with OMS system option must be set to Yes
• The participant must support G.722
• The trunk groups used by participants must support G.722
• IP domains between participants and OXE-MS must support G.722.
The conference type can be:
• An N-party conference (mastered or meet me conference)
• A 3-party conference
• A barge-in (also called intrusion)
• Voice recording through 4645 or an external SIP recorder
5.1.1.4 Communication Server duplication

The OXE-MS supports Communication Server duplication in the same subnetwork, as well as
duplication with the two Communication Servers on two different subnetworks (spatial redundancy).
Example:
Two OXE-MS (OXE-MS1 and OXE-MS2) are connected to the main Communication Server (called CS main in the
figure). When the main Communication Server activity is interrupted, the standby Communication Server switches
to main and the two OXE-MS are connected to this Communication Server.
VM VM VM VM
CS main OXE-MS1 CS main OXE-MS1
Virtualized environment Virtualized environment
Switchover
VM VM VM VM
CS standby OXE-MS2 CS standby OXE-MS2
Virtualized environment Virtualized environment
: IPLink
Figure 5.86: Switchover between two Communication Servers
5.1.1.5 Passive Communication Server

As of R12.3, an OXE-MS can be rescued by a Passive Communication Server in case of loss of the
Communication Server(s).
When an OXE-MS is rescued by a PCS, it performs a soft reset (voice contexts are released but the
VM does not reboot) before connecting to the PCS.
When the Communication Server is available again, the OXE-MS performs a hard reset (the VM
reboots) before connecting to the Communication Server.
PCS connection can be established in clear mode or in cipher mode if native encryption is enabled on
the node.
Select the PCS configuration menu in the omsconfig tool to configure the PCS IP address.
5.1.1.6 Security
5.1.1.6.1 Binary authentication

A digital signature is introduced in the OXE-MS release production of software binaries. The signature
is verified by the Public Verification Key (PKI) when an OXE-MS software upgrade is performed on
customer location.
5.1.1.6.2 Signaling and voice flow encryption

IP Touch Security modules (SSM or MSM) must be used for OXE-MS signaling and voice flow
encryption. The OXE-MS uses UDP ports (2049 and 2050) to exchange messages with the IP Touch
Security module placed in front of the server.
The figure below represents a configuration with a Communication Server (CS) and an OXE-MS
protected by an SSM.
VM VM
CS OXE-MS
Virtualized environment
SSM
LAN
Figure 5.87: OXE-MS secured by an SSM
5.1.2 OXE-MS installation overview

The following paragraphs describe the installation of an OXE-MS virtual machine on KVM or VMware.
The OXE-MS virtual machine installation on KVM or VMware is performed via the S.O.T.
The S.O.T. allows to collect the OXE-MS files, and perform any of the following:
• Generate an OVF file to deploy on the physical machine on which the OXE-MS virtual machine
must run. This OVF file is provided according to the sizing desired. Once this OVF file is deployed
on the target machine, the VMware or KVM client retrieves the vmdk file from the S.O.T. and install
the OXE-MS virtual machine.
This operation allows to deploy the virtual machine and OXE-MS files in one go on the physical
machine.
• Deploy the OXE-MS files on the appropriate virtual machine already created on the physical
machine. Once the virtual machine is started via the VMware or KVM client, it boots from the
network, connects to the S.O.T. and loads the OXE-MS software. The OXE-MS software installation
automatically starts on the virtual machine.
The OXE-MS virtual machine installation via S.O.T. does not include the KVM or VMware solution
installation on the physical server.
5.1.3 OXE-MS virtual machine requirements

The installation of the OXE-MS requires:
• The virtualization solution (VMware, KVM, or Hyper-V), installed and configured on the physical
server.
For more details on the VMware,KVM, or Hyper-V solution installation and configuration, refer to the
Notes:
• In case of KVM:
• The KVM solution consists of Suse Linux Enterprise operation system, KVM virtualization layer, and
KVM packages. The installation of KVM virtualization packages requires before R11.2, RedHat
Enterprise Linux 6.4 x86_64 bit Edition (or higher) or from R11.2, Suse Linux Enterprise as operating
system.
• Virtualization packages can be installed either during the host installation sequence or after host
installation using the zypper command and the Suse network.
• Ensure that bridged network has been configured, because Communication Server and OXE-MS virtual
machines use the same for access over LAN, and also turn off the NetworkManager to use the network
service instead.
• In case of VMware: The version must be 5.5 or higher.
• A virtualization management tool started:
• For KVM: use the Virtual Machine Manager application available in the KVM packages installed
with the KVM solution on the physical server.
• For VMware: use the vSphere web client (version 5.5 or higher), as it is the only client allowing
the installation of a bootdvd for SUSE 12 SP3 on a virtual machine.
• For Hyper-V: use the Hyper-V Manager
For more details on the VMware or KVM management tool installation and startup, refer to the
For more details on S.O.T. installation and startup, see document [45]
• The bootdvd including the SUSE Linux Enterprise Server operating system (bootdvd.x.iso)
• The OXE-MS software file (vmOMS-<version>.iso)
The bootdvd and OXE-MS software files are present in the OmniPCX Enterprise software package
available on the Business Portal Web Site. They must be downloaded and declared in the media list on
S.O.T. For more details, see document [45].
In case of OXE-MS virtual machine deployment without OVF, the OXE-MS virtual machine must be
created manually with the following characteristics:
• Dedicated memory: 1 GB of RAM
• Virtual hard disk: 4 GB
• Processing: one vCPU. The core frequency depends on the number of ports and coding/algorithm:
• With G711 coding only: 7 MHz with a maximum of 120 ports per OXE-MS
• With G722 coding: 10 MHz with a maximum of 120 ports per OXE-MS
• When G729 compression is used: 25 MHz with a maximum of 120 ports per OXE-MS
• Operating system: Linux
• Version: SUSE Linux Enterprise Server 12 SP3 (64-bit) (as of OXE-MS v8.00)
• SCSI controller: LSI Logic parallel with a disk Virtual Device Node set to SCSI(0:0)
• Network adapter: VMXNET 3
Important:
Only legacy Network Adapter must be used for Hyper-V installation.
• For Hyper-V: the virtual machine generation must be Generation 1
5.1.4 OXE-MS installation process overview

OXE-MS installation consists in:
• Configuring the OXE-MS on the OmniPCX Enterprise on page 250
• Generating the OXE-MS virtual machine via S.O.T. on page 253
• Deploying the OXE-MS virtual machine on the target physical server on page 256
5.1.5 Configuring the OXE-MS on the OmniPCX Enterprise

The OXE-MS configuration consists in:
• Verifying the software locks dedicated to the OXE-MS on page 250
• Declaring the OXE-MS on page 250
• Configuring OXE-MS parameters on page 250
• Entering the Ethernet (MAC) address of the OXE-MS on page 253
5.1.5.1 Verifying the software locks dedicated to the OXE-MS

Two software locks are dedicated to the OXE-MS:
• 384-OXE Media Servers: this software lock controls the number of OXE-MS declared in the
OmniPCX Enterprise
• 385-VoIP channels on OMS: this software lock controls the total number of VoIP channels
(compressors) allowed for all the OXE-MS declared in the OmniPCX Enterprise
The two software locks must be greater than 0.
To display software lock states, enter the spadmin command from the OmniPCX Enterprise prompt.
5.1.5.2 Declaring the OXE-MS

The OXE-MS is declared as a media gateway in the OmniPCX Enterprise (called OXE-MS media
gateway in the rest of this chapter).
OXE-MS declaration can be performed from any of the following:
• The Shelf menu. In this case, review/modify the following attributes:
Shelf Address Enter the rack address of the OXE-MS media gateway
Shelf Type Select: Media Gateway Large
OXE Media Server Select YES

Default value: NO
• The Media Gateway menu. In this case, review/modify the following attributes:
Main shelf Address Enter the rack address of the OXE-MS media gateway
Main shelf type Select: Media Gateway Large
OXE Media Server Select YES

Default value: NO
Declaring the OXE-MS in the Shelf menu automatically creates the OXE-MS in the Media Gateway
menu and vice-versa.
Caution:
Do not declare any secondary racks and boards.
5.1.5.3 Configuring OXE-MS parameters

Declaring the OXE-MS rack results in the automatic creation of a GD-3 board in the controller position
(position 0).
1. Select Shelf > Board

Shelf address Enter the number of the OXE-MS media gateway
Board Address Displays 0 (controller position)
Interface Type Displays GD3

Caution:
Do not modify this board type.
Max simultane- Enter the maximum number of simultaneous voice guides.

ous voice
This value must comply with PCM rules. See note below.
guides
N-part confer- Select the type of N-party conference:

ence type
• Add-on (default value)
• Meet-Me
No. of Com- Enter the number of compressors (VoIP channels) allowed for IP devices.
pressors for IP
This number must be compatible with hardware resources.
Devices
Default value: 0 (maximum value: 120)
Max. number of Enter the number of 3-party conferences allowed on the OXE-MS media gate-
3-part conferen- way.
ces
Default value: 0 (maximum value: 40)
To take the modified value into account, the OXE-MS media gateway must be
restarted.
Max. number of Enter the maximum number of 6-party conferences

6-part conferen-
ces

14-part confer-
ences

29-part confer-
ences
Note:
PCM rules:
Voice guides and n-party conferences are performed by a PCM (Pulse Code Modulation).
The OXE-MS media gateway supports 4 PCM.
Each PCM can perform:
• Up to 30 voice guides
• Up to 4 6-party conferences
A PCM does not support mixed configuration: only voice guides or only conferences of the same type.
The table below gives configuration possibilities:
Simultaneous voice Max. number of Max. number of Max. number of

guides
29-party conferences 14-party conferences 6-party conferences
<= 30 3
<= 30 2 1 or 2
<= 30 2 <= 4
<= 30 1 3 or 4
<= 30 1 1 or 2 <= 4
<= 30 1 <= 8
<= 30 5 or 6
<= 30 3 or 4 <= 4
<= 30 1 or 2 <= 8
<= 30 <= 12
31 <= x <= 60 2
31 <= x <= 60 1 1 or 2
31 <= x <= 60 1 <= 4
31 <= x <= 60 3 or 4
31 <= x <= 60 1 or 2 <= 4
31 <= x <= 60 <= 8
61 <= x <= 90 1
61 <= x <= 90 1 or 2
61 <= x <= 90 <= 4
91 <= x <= 120
In case of misconfiguration, a warning message is displayed.
5.1.5.4 Entering the Ethernet (MAC) address of the OXE-MS

The Ethernet (MAC) address of the OXE-MS virtual machine must be entered in the OXE-MS Ethernet
parameters. The IP parameters (IP Coupler Address, IP Netmask, Default Gateway IP Address)
must not be entered at this stage, they will be entered when the OXE-MS is started.
1. Select Shelf > Board > Ethernet Parameters
Shelf address Enter the number of the OXE-MS media gateway
Board Address Enter 0 (controller position)
Interface Type Displays GD3
Board Ethernet Enter the MAC address of the OXE-MS virtual machine
Address
Note:
The MAC address of the OXE-MS virtual machine can be retrieved from the virtual machine properties.
5.1.5.5 G722 conference

To allow G722 conferences, the G722 conference with OMS system option must be configured.
1. Select System > Other System Param > Compression Parameters
Option Select: G722 conference with OMS
G722 confer- • No: no G722 conference allowed with OXE-MS (default value)
ence with OMS • Yes: G722 conference allowed with OXE-MS
Note:
The OXE-MS must be reset for this option modification to be taken into account
5.1.6 Generating the OXE-MS virtual machine via S.O.T.

To generate the OXE-MS virtual machine via S.O.T.:
1. If OXE-MS virtual machine deployment without OVF, create manually the virtual machine on the
physical server with the appropriate characteristics (see: OXE-MS virtual machine requirements on
page 248). According to the virtualization environment, perform one of the following:
• Create a virtual machine on KVM: see: Creating a virtual machine on KVM on page 270
Note:
Important:

4. Select OMS and click Next
5. Select the media on which the files (bootdvd and OXE-MS software) are available:
8. After the necessary information has been provided, click Next

2. If OXE-MS virtual machine deployment with OVF, select the OVF Generation field
10. Click Next
Figure 5.90: OMS server settings page example
11. Complete the OXE-MS server settings

Note:
If OXE-MS virtual machine deployment with OVF, the MAC address field is grayed and cannot be modified.
12. Click Next
13. Verify the OXE-MS hostname and software version and click Deploy
• If OXE-MS virtual machine deployment without OVF: start PXE boot on the virtual machine on
which the OXE-MS must be installed
• If deployment of the OXE-MS virtual machine with OVF file: once OVF file is successfully
generated, click Download and save the OVF file on a device storage. Use this OVF file to
deploy the OXE-MS virtual machine on the target physical machine
• Deploying the OXE-MS virtual machine on a KVM physical server on page 256
• Deploying the OXE-MS virtual machine on a VMware physical server on page 259
• Deploying the OXE-MS virtual machine on a Hyper-V physical server on page 262
5.1.7 Deploying the OXE-MS virtual machine on the target physical server
5.1.7.1 Deploying the OXE-MS virtual machine on a KVM physical server
To deploy the OXE-MS virtual machine on a KVM physical server:
1. From the KVM physical server home page, navigate to: Applications > System Tools >
Virtual Machine Manager to launch the Virtual Machine Manager application
1. Select File > New Virtual Machine, or click the icon

The Virtual Machine creation window opens
2. Select the Network Install (HTTP, FTP or NTFS) option, and enter the URL of the
OVF file including the OXE-MS virtual machine
• Right click the virtual machine and select Run
• Select the virtual machine and click the icon symbolized by a right-pointing arrow
Monitor the progress of the OXE-MS installation on the console of the Virtual Machine
Manager application.
The Suse Linux Enterprise installation starts, followed by the OXE-MS software installation. At the
end of process, a login window opens
Figure 5.91: OXE-MS login prompt example
3. Log in as admin (default password: letacla1)

Note:
At this stage, letacla1 is entered using an English keyboard. To change the English keyboard to a different
keyboard (for example: AZERTY for French people):
1. Enter the kb/kb credentials
2. Select the appropriate language in the list, and select OK
The login prompt is displayed again.
4. From the admin session, log in as root using the su command (default password: letacla1)
You are prompted to change the default password
5. Change the default password
Figure 5.92: Password change prompt example
6. Enter the omsconfig command to configure the OXE-MS

7. Verify that the OXE-MS version and parameters (MAC address, IP address, Netmask and
Gateway address) correspond to those defined for OXE-MS installation
Welcome to the OMS configuration tool
_______________________________________
FW version
oms_09.01_24Jan19_14h40
_______________________________________
Board role OMS
MAC address 0050568E5065
1. IP N/W Mode IPV4only
2. View/Modify IP Addresses
3. Crystal number 4 (Manual allocation)
4. IP QoS menu VLAN disabled
5. ssh server open
6. Archive log files
7. Certificate management
0. Exit
8. Select the menu 2. View/Modify IP Addresses, and complete the IP addresses:
• The OmniPCX Enterprise IP address (menu 1. IPv4 address)
• The IP network mask (menu 2. IPv4 subnetmask)
• The router IP address (menu 3. IPv4 gateway)
• The local OmniPCX Enterprise communication server main IP address (menu 4. CPU role
address)
• The duplicated OmniPCX Enterprise communication server main IP address in a duplicated
OmniPCX Enterprise communication server configuration where the two OmniPCX Enterprise
communication servers are on different IP subnetworks (menu 5. CPU redundancy role
address)
• Optionally, the PCS IP address (menu 6. Passive CS address)
9. Complete the other parameters:
• The rack address of the OXE-MS Media Gateway (menu 3. Crystal number). For more
information, see: Configuring the OXE-MS on the OmniPCX Enterprise on page 250
• The 5. ssh server option opens ssh, only for the admin user and only from the associated
OmniPCX Enterprise
Note:
For the access from any other IP address, the /etc/hosts.allow needs to be changed.
11. On the OmniPCX Enterprise, the status of the OXE-MS can be verified using the command config
<crystal number>
Example:
(1)cs80> config 6
Thu Aug 14 19:24:14 CEST 2014
+-------------------------------------------------------------------+
| Cr | cpl| cpl type | hw type | cpl state | coupler ID |
|----|----|------------|-----------|--------------|-----------------|
| 6 | 0 | GD3 | OXE MS | IN SERVICE | NO PCMS CODE |
+-------------------------------------------------------------------+
--- Inter Crystal Topology ---
+-------------------------------------------------------------------------+
| CR | CPL Type Role Free/Tot Role Type CPL | CR |
|-------------------------------------------------------------------------|
|006 | 00 -GD3 <MAIN > --- 0/0--- < INT_A> INTIP3A - 01|019 |
|-------------------------------------------------------------------------|
(1)cs80>
The status of the OXE-MS can also be verified using other OmniPCX Enterprise commands such as
cplstat or listerm.
You can access the OXE-MS using an SSH connection. From the prompt of OmniPCX Enterprise,
enter the following command: ssh –l admin -2 <OXE-MS IP address>. A password is asked
for access: it corresponds to the password of the OmniPCX Enterprise root account.
Example:
(1)cs80>ssh –l admin -2 172.19.108.12
5.1.7.2 Deploying the OXE-MS virtual machine on a VMware physical server

To deploy the OXE-MS virtual machine on a VMware physical server:
1. Open a web browser and enter the following URL:
https://<VMware ESXi server IP address>
2. Log in with your user credentials
The vSphere web client inventory page opens
1. Right click the host and select Create/Register VM
The virtual machine creation window opens
2. Select Deploy a virtual machine from an OVF or OVA file and click Next
The source selection window opens
3. Enter the name of the virtual machine and select the OVF file including the OXE-MS virtual
machine
• Right click the virtual machine and select Power > Power On
• Select the virtual machine and select Power On

Monitor the progress of the OXE-MS installation on the console of the VMware web client.

Note:

_______________________________________
FW version
oms_09.01_24Jan19_14h40
_______________________________________
Board role OMS
5. ssh server open
0. Exit
address)
address)
OmniPCX Enterprise
Note:
<crystal number>
Example:
(1)cs80> config 6
Thu Aug 14 19:24:14 CEST 2014
+-------------------------------------------------------------------+
|----|----|------------|-----------|--------------|-----------------|
+-------------------------------------------------------------------+
+-------------------------------------------------------------------------+
|-------------------------------------------------------------------------|
|-------------------------------------------------------------------------|
(1)cs80>
cplstat or listerm.
Example:
(1)cs80>ssh –l admin -2 172.19.108.12
5.1.7.3 Deploying the OXE-MS virtual machine on a Hyper-V physical server

Before you begin, ensure the legacy network adapter is configured in the virtual machine settings. Only
legacy network adapter must be used for Hyper-V installation. A configuration example is detailed in
Configuring QoS on the host server on page 90.
To deploy the OXE-MS virtual machine on a Hyper-V physical server:
1. From the management computer, open the Hyper-V Manager
The Hyper-V Manager access differs according to the Windows OS version deployed on the
management computer. For more details, refer to the manufacturer documentation.
2. Power on the virtual machine using any of the following:
• Right click the virtual machine and select Start
• Select the virtual machine and select Start in the Actions vertical bar
Monitor the progress of the OXE-MS installation on the console of the Hyper-V Manager.

Note:
_______________________________________
FW version
oms_09.01_24Jan19_14h40
_______________________________________
Board role OMS
5. ssh server open
0. Exit
address)
address)
OmniPCX Enterprise
Note:
<crystal number>
Example:
(1)cs80> config 6
Thu Aug 14 19:24:14 CEST 2014
+-------------------------------------------------------------------+
|----|----|------------|-----------|--------------|-----------------|
+-------------------------------------------------------------------+
+-------------------------------------------------------------------------+
|-------------------------------------------------------------------------|
|-------------------------------------------------------------------------|
(1)cs80>
cplstat or listerm.
Example:
(1)cs80>ssh –l admin -2 172.19.108.12
12. After the OXE-MS installation is completed, remove the legacy network adapter from the virtual
machine settings, and add a network adapter with the virtual machine network settings.
5.1.8 Replacing an existing Red Hat virtual machine by a new SUSE virtual machine
This procedure applies to an OXE-MS virtual machine deployed on a KVM physical server. It stops the
OXE-MS for a few minutes.
The new SUSE OXE-MS must be configured with the same parameters as the existing Red Hat OXE-
MS. If necessary, use the omsconfig tool to retrieve this information.
To replace an existing Red Hat OXE-MS by a new SUSE OXE-MS:
1. On S.O.T., configure the settings of OXE-MS virtual machine, as explained in: Generating the OXE-
MS virtual machine via S.O.T. on page 253
2. Stop the Red Hat OXE-MS
3. Deploy the OXE-MS virtual machine on the target physical server, as explained in: Deploying the
OXE-MS virtual machine on a VMware physical server on page 259
4. Go to the OmniPCX Enterprise management console
5. Go to Shelf > Board > Ethernet Parameters
6. Select the appropriate shelf and review modify the following attribute
Board Ethernet address Enter the MAC address of your SUSE OXE-MS
virtual machine
8. Restart the SUSE OXE-MS virtual machine
9. In the OmniPCX Enterprise management tool, verify the status of the OMS crystal with the
command config <crystal no.>
10. Close your VMware player and
5.2 OST Server Installation for OXE Signaling Translator or External

Encryption Gateway
5.2.1 OST overview
The OST software package must be installed in a virtual machine provided by either a Kernel-based
Virtual Machine (KVM), VMware ESXi solution, or Hyper-V. In all virtualization environments (KVM,
VMware ESXi or Hyper-V), SUSE Linux Enterprise Server (SLES) is used as OS for OST software. It is
provided with the OST installation package.
The OST can operate as any of the following:
• OXE Signaling Translator 64 (OST64), used by the OmniPCX Enterprise to operate with IPv6
devices. For more details, see the section on IPV6 of document [7]
• External Encryption Gateway (EEGW), used by the OmniPCX Enterprise to operate with DTLS
compatible IP devices. For more details, see to the section on FSNE of document [7]
An OST must be created for each OmniPCX Enterprise or PCS. When your configuration is duplicated,
you must create two OST: one for the main communication server and another one for the standby
communication server. If your configuration is not coherent: an OST is configured on a CPU and not on
the standby CPU, incident 6010 is generated.
A Communication Server (main, standby, PCS) and the associated OST must be installed on the same
physical server, and located on the same network.
5.2.2 OST installation prerequisites

The OST is installed in a virtual machine using the S.O.T.
For information on the virtual machine characteristics, refer to https://businessportal.al-enterprise.com/
node/430986.
Caution:
Direct upgrade of OST from a version running on SUSE Linux Enterprise 12 SP1 to a version running on
SUSE Linux Enterprise 12 SP3 (v4.00 or higher) is not allowed. You must first install SP3 boot and reinstall
OST.
For more information on the S.O.T., see the S.O.T. manual [45].
5.2.3 Installing the OST software via S.O.T.

Prerequisite: The bootdvd and OST software must be declared in the media list on S.O.T. For more
details, see the S.O.T. manual [45].
To Install the OST via the S.O.T.:
1. If OXE-MS virtual machine deployment without OVF, create manually the virtual machine on the
physical server with the appropriate characteristics (see: OST installation prerequisites on page
266). According to the virtualization environment, perform one of the following:
• Create a virtual machine on KVM: see: Creating a virtual machine on KVM on page 270
Note:
Important:
3. Select Greenfield project option
4. Select OST and click Next
5. Select the media on which the files (bootdvd and OST software) are available, and click Refresh
medias list
6. Select the files listed on screen, and click Declare medias
The Project settings page opens
8. Enter a Project name, and complete the other fields with the network parameters of the customer
LAN and click Next
Select the OVF Generation field if the OST virtual machine must be deployed on the target
machine using an OVF file.
The OST settings page opens
9. Complete the fields with the OST server settings
The Machine type field is used to select the operating mode of the OST virtual machine (EEGW or
OST64)
If OVF is used, the MAC address of the virtual machine is not required: the OST MAC address
field is grayed.
Figure 5.97: OST virtual machine configuration example for OST64
10. Click Next

11. Verify the OST server hostname and software version and click Deploy
12. According to the type of deployment, perform any of the following on the target server:
• Deployment with OVF: copy the URL of the OVF, replace https by http (to prevent transfer failure
due to lack of certificate), and use the resulting URL to install the OST virtual machine on the
target server
• Deployment without OVF: start the virtual machine (PXE boot)
After the OST virtual machine installation on the target server, you are prompted to open a session
13. Open a root session (password: letacla1)
You are prompted to change the password
14. Change the password
15. Enter the ostconfig command to access the OST configuration tool
The OST virtual machine settings are displayed on screen. Some fields are automatically completed
with information provided by S.O.T. (IP address, Netmask, and Gateway address)
16. If needed, select 10. Machine Type to check the operating mode of the OST virtual machine
(OST64 or E-Gateway (External Encryption Gateway))
17. If the OST virtual machine operates as External Encryption Gateway (E-Gateway), review/modify
the following settings:
• Select 7. CS Physical address, and enter the physical IPv4 address of the associated
communication server
• Select 8. CS role address, and enter the IPv4 address of the associated communication
server when it plays the main role (communication server duplication)
• Select 9. IP QoS menu to access and configure the VLAN settings
The other fields must be left empty.
Configuration tool example for EEGW
[root@ost ~]# ostconfig
Welcome to the OST configuration tool
-----------------------------------------------
FW version
ost_05.18_20Sep19_16h40
-----------------------------------------------
Board role EGW

MAC address 000C29B46168
1. IP address 192.168.201.148
2. Netmask 255.255.255.0
3. Gateway address 192.168.201.254
4. V6 IP Address ::
5. V6 Gateway Address ::
6. V6 Prefix Length 64
7. CS physical address 0.0.0.0
8. CS role address 0.0.0.0
10. Machine Type EGW
11. Download certificates
12. Certificate check
0. Exit
18. If the OST virtual machine operates as OST64, review/modify the following settings:
• Select 4. V6 IP Address, and enter the IPv6 address of the OST64 server
• Select 5. V6 Gateway Address, and enter the IPv6 address of the gateway
• Select 6. V6 Prefix Length, and enter the IPv6 prefix length
• Select 7. CS Physical address, and enter the physical IPv4 address of the associated
communication server
• Select 8. CS role address, and enter the IPv4 address of the associated communication
server when it plays the main role (communication server duplication)
• Select 9. IP QoS menu to access and configure the VLAN settings
Configuration tool example for OST64
[root@ost ~]# ostconfig
Welcome to the OST configuration tool
-----------------------------------------------
FW version
ost_05.18_20Sep19_16h40
-----------------------------------------------
Board role OST

MAC address 000C29B46168
1. IP address 192.168.201.148
2. Netmask 255.255.255.0
3. Gateway address 192.168.201.254
4. V6 IP Address fc1e::209
5. V6 Gateway Address fc1e::1
6. V6 Prefix Length 64
7. CS physical address 0.0.0.0
8. CS role address 0.0.0.0
10. Machine Type OST
0. Exit
19. Enter 0 to apply change and exit the OST configuration tool
Chapter
6 Appendixes
6.1 Creating a virtual machine on KVM

This procedure allows to create a KVM virtual machine to install a product later (OmniPCX Enterprise
or OXE-MS). The virtual machine characteristics differ according to the target product:
• For OmniPCX Enterprise: see: OmniPCX Enterprise virtual machine prerequisites for KVM on page
39
• For OXE-MS: see: OXE-MS virtual machine requirements on page 248
The figures displayed in the procedure illustrate the KVM virtual machine creation for an OmniPCX
Enterprise.
To create a virtual machine on KVM:
1. Open the Virtual Machine Manager application: select the Applications tab, then System
Tools > Virtual Machine Manager
2. Click the Create a new virtual machine icon to open the virtual machine creation wizard
The guest virtual machine creation process starts with the selection of a name and installation type.
3. Enter a name for the virtual machine. Virtual machine names can include special characters:
underscores (_), periods (.), and hyphens (-).
Note:
For best practice, give the same name to the virtual machine and the product.
Select the Network Boot (PXE) radio button to select the installation type and click Forward.
Figure 6.1: Name and installation type configuration page example
4. Right click the OS type and Version fields and use the contextual menu to select the
corresponding Operating System and version type, then click Forward.
Chapter 6 Appendixes
Figure 6.2: Guest operating system page example
5. Select the memory (RAM) and the number of CPUs to allocate to the virtual machine, then click
Forward.
Figure 6.3: Memory and CPU configuration page
6. Select the disk size to allocate to the virtual machine, and click Forward.
Figure 6.4: Storage configuration page
7. For OmniPCX Enterprise only: Select the Customize configuration before install check
box, and set the Architecture to i686.
Figure 6.5: Ready to begin installation page example
8. Verify the virtual machine settings and click Finish.

The virtual machine is displayed with the new parameters
Figure 6.6: Virtual Machine Manager with a new virtual machine creation example
For OmniPCX Enterprise only: The OmniPCX Enterprise does not support the default KVM NIC device
model. Complete the virtual machine configuration by modifying its model device:
1. Double click the virtual machine to open the console of the virtual machine, then click the
information icon.
2. In the virtual machine information page, select the NIC card on the left hand side of the navigation
pane (for example: NIC C5:05:77)
3. change the device model to e1000, then click Apply.
Figure 6.7: Network configuration page
6.2 Creating a virtual machine on Hyper-V

This procedure allows to create a Hyper-V virtual machine to install a product later (OmniPCX
Enterprise or OXE-MS). The virtual machine characteristics differ according to the target product:
• For OmniPCX Enterprise: see: OmniPCX Enterprise virtual machine prerequisites for Hyper-V on
page 80
• For OXE-MS: see: OXE-MS virtual machine requirements on page 248
The figures displayed in the procedure illustrate the Hyper-V virtual machine creation for an OmniPCX
Enterprise.
1. From the Hyper-V Manager window, select the server
2. Access the contextual menu (or select the Actions pane), and select New > Virtual
Machine...
3. From the New Virtual Machine Wizard, click Next

4. Make the appropriate choices for your virtual machine in each page of the wizard
Example of virtual machine creation for OmniPCX Enterprise:
5. After verifying your choices in the Summary page, click Finish

6. From the Hyper-V Manager window, right click the virtual machine and select Connect
7. In the Virtual Machine Connection window, select: Action > Start

Oxe12.4 Im SoftwareInstal 8AL91032USAK 3 en

Uploaded by

Copyright:

Available Formats

You might also like

Oxe12.4 Im SoftwareInstal 8AL91032USAK 3 en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oxe12.4 Im SoftwareInstal 8AL91032USAK 3 en

Uploaded by

Copyright:

Available Formats

Alcatel-Lucent OmniPCX Enterprise

Release 12.4 - April 2021

3.1 Software Installation Overview ...................................................................................16

3.5 Communication Server Installation in a VMware ESXi

5.1 OXE Media Services installation...............................................................................244

5.2 OST Server Installation for OXE Signaling Translator or

6.1 Creating a virtual machine on KVM....................................................................... 270

Documentation title Part number

[1] System Services 8AL91000xxyy

[2] Management Tools 8AL91002xxyy

[3] User Services 8AL91003xxyy

[4] Attendant Services 8AL91004xxyy

[5] Public Networks 8AL91005xxyy

[6] Private Networks 8AL91006xxyy

[7] IP-PCX Networks 8AL91007xxyy

Documentation title Part number

[8] Voice Mail 8AL91008xxyy

[9] Mobility 8AL91009xxyy

[10] General Applications 8AL91010xxyy

[11] Hotel/Hospital 8AL91016xxyy

[13] Maintenance 8AL91011xxyy

[14] Security 8AL91012xxyy

[15] PWT 8AL91019xxyy

Documentation title Part number

[16] Crystal Hardware System Boards 8AL91020xxyy

[17] Crystal Hardware Interface Boards 8AL91021xxyy

[18] Common Hardware Boards 8AL91022xxyy

[19] Cables 8AL91023xxyy

[20] Dedicated sets 8AL91024xxyy

[21] TA and TSC Adapters 8AL91025xxyy

[22] Complementary Equipment 8AL91026xxyy

Documentation title Part number

[23] Common Hardware Installation Manual 8AL91027xxyy

[24] Crystal Hardware Installation Manual 8AL91028xxyy

[25] Appliance Server Installation Manual 8AL91029xxyy

[26] Blade Center Installation Manual 8AL91030xxyy

[27] PCX on Standard Racks Installation Manual 8AL91031xxyy

[28] Software Installation Manual 8AL91032xxyy

[29] ALEDS 8AL90508xxyy

Documentation title Part number

[30] Customer Management via mgr 3EU19871xxyy

[31] Customer Management via 8770 8AL90615xxyy

[32] Alcatel-Lucent 4645 - Administrator Manual 3EU19873xxyy

[33] Internal Accounting - Administrator Manual 3EU19833xxyy

[36] Alcatel-Lucent 4059 IP Attendant Console 3EU19877xxyy

[37] Alcatel-Lucent IP Touch 4068 Attendant Set 8AL90607xxyy

[38] Alcatel-Lucent 4645 VMS - User Manual 3EU19583xxyy

Documentation title Part number

[39] Hotel - Hospital - User Manual 3EU19837xxyy

[40] Dongle IP / Raspberry for OpenTouch Suite 8AL90617xxyy

[41] NFC Extended OXE Mobility Administration Manual 8AL90614xxyy

[42] NFC Extended OXE Mobility User Manual 8AL90613xxyy

[43] OmniVista 8770 Administrator Manual 8AL90703xxyy

[46] CCdistribution - System Documentation R10.x 8AL91301xxyy

Figure 2.1: BootDVD welcome page example

Figure 2.2: BootDVD main page example

3 Communication Server Installation

3.1 Software Installation Overview