OpenScape Voice V5, Installation and Upgrades, Installation Guide, Issue 9 - Addfiles

Installation
OpenScape Voice V5
Service Manual
Volume 1, Installation and Upgrades
A31003-H8050-J100-09-7631
Communication for the open minded
Siemens Enterprise Communications

www.siemens.com/open
Our Quality and Environmental Management Systems are implemented according to the requirements of the ISO9001 and ISO14001 standard certified by an external certification company.
Copyright Siemens Enterprise

Communications GmbH & Co. KG 2011
Hofmannstr. 51, 80200 Mnchen
Siemens Enterprise Communications GmbH & Co. KG
is a Trademark Licensee of Siemens AG
Reference No.: A31003-H8040-J100-09-7631
Communication for the open minded

Siemens Enterprise Communications
www.siemens.com/open
The information provided in this document contains

merely general descriptions or characteristics of
performance which in case of actual use do not
always apply as described or which may change as
a result of further development of the products. An
obligation to provide the respective characteristics
shall only exist if expressly agreed in the terms of
contract. Availability and technical specifications are
subject to change without notice.
OpenScape, OpenStage and HiPath are registered
trademarks of Siemens Enterprise
Communications GmbH & Co. KG.
All other company, brand, product and service
names are trademarks or registered trademarks of
their respective holders.
HP8K_IUGTOC.fm
Nur fr den internen Gebrauch
Contents
Contents
1 Important Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 About this Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Prerequisite Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.3 Viewing the Document with Adobe Reader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4 Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 General Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Safety with Electricity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2.1 High Voltages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2.2 Equipment Room. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2.3 Emergencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3 Reporting Accidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13
13
13
14
14
15
15
15
15
16
17
17
2 Preparing for the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 About OpenScape Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Administration and Media Server Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 OpenScape Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Installing OpenScape Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Installation Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Prerequisites and Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Backup License Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 OpenScape Voice Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Guidelines for Static Routes of Geographically Separated Nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Source Based Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 Creating a Node.cfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Loading Patch Sets onto the USB Memory Sticks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
20
20
21
21
22
23
24
28
31
35
43
3 Installing the Hardware Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Computing Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 IBM x3650T Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Fujitsu Siemens Computers PRIMERGY RX330 S1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 IBM x3250 M2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 IBM x3250 M3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.5 IBM x3550 M2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.6 IBM x3550 M3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.7 Fujitsu Technology Solutions (FTS) PRIMERGY RX200 S6 Server . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Ethernet Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Installing the IBM x3650T Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 How to use the IBM x3650T Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 IBM x3650T Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Inventorying and Inspecting the IBM x3650T Server Installation Materials . . . . . . . . . . . . . . . . . . . . .
3.3.4 Locating the IBM x3650T Server Printed Installation Guides and Digital Media . . . . . . . . . . . . . . . . .
3.3.5 Installing the IBM x3650T Servers into the Rack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6 Connecting the Cables to the IBM x3650T Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6.1 Connecting the Cables for a Single-Node IBM x3650T. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6.2 Connecting the Cables for a Redundant IBM x3650T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.7 Modifying the IBM x3650T Server SCSI RAID Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
45
45
46
47
48
49
50
51
52
52
52
53
53
54
54
55
55
57
62
A31003-H8050-J100-09-7631, 09/2011
OpenScape Voice V5, Service Manual: Volume 1, Installation and Upgrades
HP8K_IUGTOC.fm
Contents
3.3.8 Modifying the IBM x3650T Server BIOS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.3.9 IBM x3650T Server Power Up Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.3.10 Installing the Intel Server Management Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.4 Installing the FSC RX330 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4.1 How to use the FSC RX330 Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4.2 FSC RX330 Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4.3 Inventorying and Inspecting the FSC RX330 Server Installation Materials . . . . . . . . . . . . . . . . . . . . . 83
3.4.4 Locating the FSC RX330 Server Printed Installation Guides and Digital Media . . . . . . . . . . . . . . . . . 83
3.4.5 Installing the FSC RX330 Servers into the Rack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.4.6 Connecting the Cables to the FSC RX330 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.4.6.1 Connecting the Cables for a Single-Node FSC RX330 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
3.4.6.2 Connecting the Cables for a Redundant FSC RX330 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.4.7 Modifying the FSC RX330 RAID Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.4.8 Modifying the FSC RX330 BIOS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.4.9 Remote Console Startup for the FSC RX330 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.4.10 Configuring the iRMC for the FSC RX330 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.5 Installing the IBM x3250 M2 and M3 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.5.1 How to use the IBM x3250 Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.5.2 IBM x3250 Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.5.3 Inventorying and Inspecting the IBM x3250 Server Installation Materials . . . . . . . . . . . . . . . . . . . . 114
3.5.4 Locating the IBM x3250 Server Printed Installation Guides and Digital Media . . . . . . . . . . . . . . . . . 115
3.5.5 Installing the IBM x3250 Server into the Rack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.5.6 Connecting the Cables to the IBM x3250 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.5.7 Modifying the IBM x3250 M2 Server BIOS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.5.8 Modifying the IBM x3250 M3 Server UEFI Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.5.9 IMM and Remote Console Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.5.10 Configuring the IMM for the IBM x3250 M3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
3.6 Installing the IBM x3550 M2 and M3 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.6.1 How to use the IBM x3550 M2/M3 Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.6.2 IBM x3550 M2/M3 Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.6.3 Inventorying and Inspecting the IBM x3550
M2/M3 Server Installation Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
3.6.4 Locating the IBM x3550 M2/M3 Server Printed Installation Guides and Digital Media . . . . . . . . . . . 143
3.6.5 Installing the IBM x3550 M2/M3 Servers into the Rack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.6.6 Connecting the Cables to the IBM x3550 M2/M3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.6.6.1 Connecting the Cables for a Single-Node IBM x3550
M2/M3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.6.6.2 Connecting the Cables for a Redundant IBM x3550
M2/M3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
3.6.7 Modifying the IBM x3550 M2/M3 RAID Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
3.6.8 Modifying the IBM x3550 M2/M3 BIOS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3.6.9 Configuring the IMM for the IBM x3550 M2/M3 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
3.6.10 Remote Console Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
3.7 Installing the FTS RX200 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.7.1 How to use the FTS RX200 Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.7.2 FTS RX200 Server Installation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.7.3 Inventorying and Inspecting the FTS RX200 Server Installation Materials . . . . . . . . . . . . . . . . . . . . 173
3.7.4 Locating the FTS RX200 Server Printed Installation Guides and Digital Media . . . . . . . . . . . . . . . . 173
3.7.5 Installing the FTS RX200 Servers into the Rack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
3.7.6 Connecting the Cables to the FTS RX200 Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
3.7.6.1 Connecting the Cables for a Single-Node FTS RX200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
3.7.6.2 Connecting the Cables for a Redundant FTS RX200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
A31003-H8050-J100-09-7631, 09/2011
HP8K_IUGTOC.fm
Contents
3.7.7 Modifying the FTS RX200 RAID Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.7.8 Modifying the FTS RX200 BIOS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.9 Remote Console Startup for the FTS RX200 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.10 Firmware Updates for the FTS RX200 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
181
192
205
212
4 Installing the OpenScape Voice Reference Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

4.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
4.2 Installation via DVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
4.2.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
4.2.2 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
4.3 Virtualization Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
4.3.1 Virtualization Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
4.3.2 Checklist for Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
4.3.3 Virtual Machine Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
4.3.3.1 Requirements to Underlying Host Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
4.3.3.2 Virtual Machine Configuration Parameters Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
4.3.3.3 Overview of the OSV Virtual Machine Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
4.3.3.4 Virtual Machine Network Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
4.3.3.5 .Virtual Machine Memory Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
4.3.3.6 Virtual Machine CPU Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
4.3.3.7 Virtual Machine Disk Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
4.3.3.8 Other Parameters to Consider for the Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
4.3.4 Creating a Node.cfg File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
4.3.4.1 Creating a Virtual Floppy Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
4.3.4.2 Saving the node.cfg File to Virtual Floppy Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
4.3.4.3 Saving the node.cfg File and Patchsets to a CD ISO Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
4.3.5 Preparation of the Image DVDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
4.3.6 VMware vSphere Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
4.3.6.1 Configuration of Login Credentials in VMware vSphere Client . . . . . . . . . . . . . . . . . . . . . . . . . . 240
4.3.6.2 Uploading a file to the Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
4.3.7 Preparation of the VMware Virtual Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
4.3.7.1 Examples of Physical Server NIC to VMNIC Mapping for IBM x3550 M2/M3, FSC RX330 & FTS
RX200 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
4.3.7.2 Preparation of the VMware Virtual Switches: Two Physical Servers Setup (Co-Located or Geo-Separated) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
4.3.7.3 Preparation of the VMware Virtual Switches: Co-Located with one Physical Server . . . . . . . . . 249
4.3.7.4 Preparation of the VMware Guest Machines - One Physical Server Solution. . . . . . . . . . . . . . . 256
4.3.7.5 Preparation of the VMware Guest Machines - Two Physical Server Solution. . . . . . . . . . . . . . . 267
4.3.7.6 Adding a CD/DVD drive to the virtual machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
4.3.7.7 Loading the Image on the VMware Guest Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
4.3.8 Virtual Machine Post Installation Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
4.3.8.1 Increasing Node Boot-Up Speed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
4.4 Post Software Installation Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
4.4.1 Verify Remote Access for srx Account in a Standard Duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
4.4.2 Changing the User ID and Password for the IMM/iRMC Account . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
4.4.3 Configuring the Ethernet NICs for Fixed Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
4.4.4 Checking Ethernet Port Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
4.4.5 Testing the KVM/Mouse Combination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
4.4.6 SNMP Community Names on OpenScape Voice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
4.4.6.1 Changing the Community String for the Emanate Master Agent. . . . . . . . . . . . . . . . . . . . . . . . . 294
4.4.6.2 Restarting the EMANATE Master SNMP Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
4.4.7 Configuring the OpenScape Voice Entry SBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
A31003-H8050-J100-09-7631, 09/2011
HP8K_IUGTOC.fm
Contents
4.4.7.1 SBC Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

4.4.7.2 SBC Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
4.4.8 Stopping the Loquendo Trap Manager Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
5 Installing the OpenScape Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
5.1 Installation Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
5.1.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
5.1.2 Customer Provided Hardware Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
5.2 Installation Instructions for Applications Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
5.2.1 Installing SLES 10 OS with Appropriate Service Pack onto the External Applications Server . . . . . 308
5.2.1.1 Installing SLES 10 with appropriate service pack onto the IBM x3650T . . . . . . . . . . . . . . . . . . 309
5.2.1.2 Installing SLES 10 with appropriate service pack onto the FSC TX150 . . . . . . . . . . . . . . . . . . 316
5.2.1.3 Installing SLES 10 with appropriate service pack onto the FSC RX330 . . . . . . . . . . . . . . . . . . 326
5.2.1.4 Operating Systems Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
5.2.2 External Applications Server Port List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
5.2.3 OpenScape Media Server and OpenScape UC Application Installation Overview . . . . . . . . . . . . . . 338
5.2.4 Installation/Update Instructions for Integrated Simplex Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
5.2.4.1 Prepare Installation of Integrated Simplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
5.2.4.2 Response File for the Integrated Simplex Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
5.2.4.3 Installation of Integrated Simplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
5.2.4.4 SSDP Plug-In Installation for Integrated Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
5.2.4.5 Add Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
5.2.4.6 Start OpenScape UC Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
5.2.4.7 Update of Integrated Simplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
5.2.4.8 Uninstall the Integrated Simplex Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
5.2.5 Installation/Update Instructions for Media Server Standalone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
5.2.5.1 Providing a Server Standalone Setup Medium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
5.2.5.2 Response File for Media Server Standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
5.2.5.3 Installing Media Server Standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
5.2.5.4 SSDP Plug-In Installation for Media Server Standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
5.2.5.5 Adding Additional Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
5.2.5.7 Update Media Server Standalone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
5.2.6 Installation/Update Instructions for Multiple Communications Server Admin deployment. . . . . . . . . 359
5.2.6.1 Prepare Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
5.2.6.2 Response File for Multiple Communications Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
5.2.6.3 Installing Multiple Communications Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
5.2.6.4 SSDP Plug-In IInstallation for for Multiple Communications Server. . . . . . . . . . . . . . . . . . . . . . 364
5.2.6.5 Adding Additional Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
5.2.6.7 Update Multiple Communications Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
5.2.6.8 Remote Access for srx Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
5.2.6.9 Survival Authority on the Multiple Communications Server Admin deployment. . . . . . . . . . . . . 370
5.2.7 Configuring the OSV Connectivity in CMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
5.2.8 Activating IPSec Between OpenScape Voice and the External Applications Server . . . . . . . . . . . . 381
5.2.8.1 Uninstalling IPsec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
5.2.8.2 IPSec Support for Multiple OpenScape Voice Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
5.3 Starting and Stopping the OpenScape Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
5.4 Accessing the OpenScape Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
5.4.1 Accessing the CMP/OpenScape Voice Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
5.4.2 Accessing DLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
5.4.3 Accessing CLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
A31003-H8050-J100-09-7631, 09/2011
HP8K_IUGTOC.fm
Contents
5.5 Retrieving Trace File Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.6 Installing a HotFix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7 Upgrade of External Application Server (OffBoard) Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.1 Upgrade of V3.1R3 Applications to V5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.2 Upgrade of V4R1 Applications to V5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8 Fallback During Upgrade Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8.1 Fallback of an Integrated Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.8.2 External Application Server (OffBoard) Installation Fallback from V5 Applications to V3.1R3 DVD8.
5.8.3 External Application Server (OffBoard) Installation Fallback from V5 Applications to V4R1 DVD3 . .
5.9 Uninstall External Application Server (OffBoard) Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
386
389
391
392
395
398
398
398
399
400
6 Survival Authority and IPMI Shutdown Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.1 Shutdown Agent Overview (Non-Virtual environment). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Shutdown Agent Overview (Virtual environment) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Hints on Survival Authority placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Survival Authority on the CMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Installing a Standalone Survival Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1 Installing the Java Runtime Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.2 Installing the Standalone Survival Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Updating the Standalone Survival Authority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7 Verifying the Shutdown Agents Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7.1 Monitoring the Shutdown Agents From the Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7.2 Examples of sa_down.log and sa_ipmi.log Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7.3 Activity Log for Survival Authority Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
405
406
407
408
409
411
412
412
416
418
419
420
422
7 Overview of Upgrades and Migrations to OpenScape Voice V5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.1 Solution Upgrade Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Hardware Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1 Hardware Platform Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2 IBM x3650T Memory Expansion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.3 Converting to a Multi-Partition Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.4 IBM x3650T Simplex to Standard Duplex Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.5 FSC RX330 Simplex to Standard Duplex Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.6 IBM x3550 M2/M3 Simplex to Standard Duplex Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.7 FTS RX200 Simplex to Standard Duplex Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.8 Additional Servers for Migrations to Standard Duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Upgrade and Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Upgrade Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2 Hardware Migrations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.3 Product/Node Deployment Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Completing the Upgrade to V5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Post Upgrade Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.1 Create CLI Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.2 Create Linux Accounts for CLI Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.3 Take File System and Database Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.4 Modifying Node Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.5 Executive-Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.6 Executive - Assistant with Cockpit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
425
428
428
428
429
429
429
430
431
431
432
434
434
435
435
437
442
442
442
443
443
444
444
8 Upgrades to OpenScape Voice V5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1 Procedure Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.1 Applicable Upgrade Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.2 Preparation Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
445
445
446
447
A31003-H8050-J100-09-7631, 09/2011
HP8K_IUGTOC.fm
Contents
8.1.3 Required Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1.4 Split Mode Upgrade Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.5 Operational Impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.5.1 Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.5.2 Call Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Prerequisites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 System Information and Access Rights. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.3 IP Network Requirements for Geographically Separated Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.4 Convert to Multi-Partition System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Preparation Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1 Collect System Data on Node 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2 Create the Node.cfg for the Target Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.3 Copy the Node.cfg Files to USB Memory Sticks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.4 Verify Prerequisites Met According to Release Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.5 Obtain Licenses for the Target Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4 Pre-Maintenance Window Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.1 Run RapidStat on Both Nodes and Analyze Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.2 Make Test Calls and Document Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.3 Perform Any Customer Specific System Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.4 Verify V3.1R3/V4R1 Patch Set Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.5 Perform a Database and File System Backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.6 Verify the Ethernet Configuration of the External Applications Server . . . . . . . . . . . . . . . . . . . . . . .
8.4.7 Verify the Hosts File Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.8 Executive Assistant with Cockpit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5 Upgrading an Integrated Simplex System (Toolkit Method) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6 Upgrading a Standard Duplex System (SMU Method) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.7 Upgrading a Standard Duplex System (Toolkit Method) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8 Remote SW Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8.1 SW Upgrade for Configuration Standard Duplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8.2 SW Upgrade for Configuration Simplex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8.3 How to Upgrade SW Remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8.4 How to Fallback if Failure During Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.8.5 How to Fallback if Failure During Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.9 Customize Node 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.9.1 Log In to Node 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.9.2 Customize Node 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.9.3 Verify Node Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.10 Customize Node 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.10.1 Log In to Node 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.10.2 Customize Node 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.11 Fallback Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.11.1 Fallback Procedure 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.11.6 General Hard Fallback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.11.7 Fallback for Toolkit Upgrades/Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.12 Handle System Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.12.1 Summary Report Items that can be Ignored . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.12.2 Summary Report Items that can be Ignored after Node 1 Installation Comparison . . . . . . . . . . . .
448
448
451
451
451
453
453
453
453
455
456
456
458
461
462
462
463
463
463
463
463
463
464
464
466
467
472
490
495
495
496
497
498
499
500
500
501
502
506
506
506
508
508
511
516
521
523
527
528
529
538
541
A31003-H8050-J100-09-7631, 09/2011
HP8K_IUGTOC.fm
Contents
9 Migrations to OpenScape Voice V5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.1 Hardware Platform Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.1 Simplex to Simplex Hardware Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.2 Simplex to Standard Duplex Hardware Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.3 Integrated Duplex to Standard Duplex Hardware Migration (Node Deployment Unchanged) . . . . . .
9.1.4 Integrated Duplex to Standard Duplex Hardware Migration (Node Deployment Changed) . . . . . . . .
9.1.5 Standard Duplex to Standard Duplex Hardware Migration (Node Deployment Unchanged) . . . . . . .
9.1.6 Standard Duplex to Standard Duplex Hardware Migration (Node Deployment Changed) . . . . . . . . .
9.1.7 Low Cost to Standard Duplex Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Product Type and Node Deployment Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Simplex to Standard Duplex Product Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.2 Integrated Duplex to Standard Duplex Product Migration (Node Deployment Unchanged) . . . . . . . .
9.2.3 Integrated Duplex to Standard Duplex Product Migration (Node Deployment Changed). . . . . . . . . .
9.2.4 Standard Duplex Node Redeployment Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Create the Node.cfg for the Target System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4 Download and Install the Migration Toolkit Software to the Source System . . . . . . . . . . . . . . . . . . . . . . .
9.5 Export the Data of the Source System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.6 Download and Install the Migration Toolkit Software to the Target System. . . . . . . . . . . . . . . . . . . . . . . .
9.7 Import the Source System Data to the Target System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.8 Remove the Migration Toolkit Software from the Target System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.9 Configure the OpenScape Applications Server for Access to the Nodes . . . . . . . . . . . . . . . . . . . . . . . . .
9.10 Create the Node.cfg for the Target System (Source system = Low Cost) . . . . . . . . . . . . . . . . . . . . . . . .
545
546
547
552
556
560
564
569
574
579
579
583
586
591
596
600
601
602
602
604
604
607
10 Basic Traffic Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10.1 Installation (Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Installing (Client) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Using the Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.1 Graphical and Numerical Data Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2 Menu Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4 Feature Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
615
615
615
615
616
616
617
A Example Install_Time.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

B IBM x3650T RAID Card Removal Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Verify RAID Card Is Installed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 RAID Card Removal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3.1 Required Tools and Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3.2 RAID Card Removal Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
621
621
621
622
622
622
C IBM x3650T Quad Ethernet Card Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2 Quad Ethernet Card Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2.1 Required Tools and Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.2.2 Quad Card Ethernet Installation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
629
629
629
629
629
D IBM xSeries 345 and 346 Wiring Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637

E Changing NTP Server or DNS Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
F Updating the Node.cfg File (Also Known as EZIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
G Formatting a USB Memory Stick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
G.1 Formatting Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
H Verifying V3.1R3/V4R1 Survival Authority and IPMI Shutdown Agents . . . . . . . . . . . . . . . . . . . . . . . . 649
H.1 Verifying the V3.1R3 Survival Authority and IPMI Shutdown Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
A31003-H8050-J100-09-7631, 09/2011
HP8K_IUGTOC.fm
Contents
H.1.1 V3.1R3 Monitoring the Survival Authority From the Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

H.1.2 V3.1R3 Examples of SA_die.log and SA_ipmi.log Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.2 Verifying the V4R1 Survival Authority and IPMI Shutdown Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.2.1 V4R1 Monitoring the Shutdown Agents From the Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.2.2 V4R1 Examples of SA_down.log and SA_ipmi.log Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
649
650
653
653
654
I Removal of Obsolete IP Addresses when Upgrading to V4R1 (or higher releases) . . . . . . . . . . . . . . . 657
I.1 OpenScape Voice V4R1 Solution Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
I.2 Queries to be Performed on V3.1R3/V4R1 Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
I.2.1 OpenScape Voice System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
I.2.1.1 Run Net Sniffer on Each Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
I.2.1.2 Run DLS Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
I.2.2 Proxies and Gateways Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
I.2.2.1 HiPath 3000 Switch Communicating with OpenScape Voice Server . . . . . . . . . . . . . . . . . . . . . 672
I.2.2.2 HG1500 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
I.2.2.3 HiPath 4000 Switch Communicating with OpenScape Voice Server . . . . . . . . . . . . . . . . . . . . . 673
I.2.2.4 RG8700 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
I.2.2.5 RG2700 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
I.2.2.6 OpenScape Branch Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
I.2.2.7 Mediatrix Gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
I.2.2.8 Comdasys Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
I.2.3 Proxies and Gateways Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
I.2.3.1 Examining DNS Server Settings Directly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
I.2.3.2 FQDN Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
I.2.3.3 DNS SRV Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
I.2.3.4 Xpressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
I.2.3.5 SIP Trunking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
I.2.3.6 Convergence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
J Media Server Announcements, Treatments and Prefix Access Code Installation Guide. . . . . . . . . . . 691
J.1 Media Server Provisioning Script Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
J.1.1 Media Server Provisioning Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
J.1.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
J.1.3 The Four Destination Types and a short Explanation of the Equivalent Media Server Deployment: 693
J.1.4 Explanation of each of the Options Offered by the msconf.sh script . . . . . . . . . . . . . . . . . . . . . . . . . 693
J.1.4.1 Option 11 Assign all default (restore) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
J.1.4.2 Option 12 Assign missing default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
J.1.4.3 Option 21 Remove all default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
J.1.4.4 Option 22 Remove all treatments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
J.1.4.5 Option 31 Modify destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
J.1.4.6 Option 41 Centralized Deployment - Single MS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
J.1.4.7 Option 42 Centralized Deployment - Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
J.1.4.8 Option 43 Distributed Deployment - Routing Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
J.1.4.9 Option 81 Collect MS provisioning information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
J.1.4.10 Option 82 Update MS treatment provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
J.2 Centralized Deployment for Single MS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
J.2.1 Media Server Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
J.2.2 Treatments Assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
J.3 Centralized Deployment for Destination MS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
J.3.2 Treatments Assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
J.4 Distributed Deployment for Subscribers with Routing Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
10
A31003-H8050-J100-09-7631, 09/2011
HP8K_IUGTOC.fm
Contents
J.4.2 Treatments Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706

J.5 How to Add/Delete Default Siemens PACs for Vertical Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
J.5.1 Add Default Siemens PACs for Vertical Services Using the pac.sh Script . . . . . . . . . . . . . . . . . . . . . 709
J.5.2 Delete the Default Siemens PACs (Prefix Access Codes) for Vertical Services Using the pac.sh Script.
713
K Configuring the OSV Nodes for Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
K.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
K.2 Shutting Down the Node(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
L OpenScape Voice Signaling Stream Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1 TLS Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.1 Endpoint Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.1.1 TLS Protection of Endpoint SIP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.1.2 TLS Protection of SIP and SIP-Q Server Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.2 Sample Connection Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.3 OpenScape Voice Platform Signaling Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.4 DNS Survivability Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.5 High Availability with SRV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.5.1 Simple Example Including DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.6 Interaction of DNS-SRV and TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.6.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.6.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.6.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.6.4 Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.1.7 Practical Deployment Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2 Creating a TLS Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2.1 OpenSSL Command Line Utility And Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2.2 CA Certificates And Their Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2.2.1 Creating a Root CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2.2.2 Creating an Intermediate CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2.2.3 Creating a Server Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2.2.4 Creating a Client Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2.2.5 Creating Third-Party Product Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2.2.6 Creating the Diffie-Hellman Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.2.3 Example Root CA Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.3 Installing or Updating a TLS Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.3.1 Installing a Certificate on an Endpoint Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.3.2 Installing a Certificate on a Mutual Authentication Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.3.3 Installing a Certificate on a Mutual Authentication Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.4 Client (Endpoint) Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L.5 Media Server Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
717
717
718
718
720
721
724
725
727
728
729
731
732
733
734
736
737
738
739
740
742
743
744
746
747
747
749
750
751
752
752
753
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
A31003-H8050-J100-09-7631, 09/2011
11
HP8K_IUGTOC.fm
Contents
12
A31003-H8050-J100-09-7631, 09/2011
notices.fm
Important Notices
About this Book
1 Important Notices
1.1 About this Book
This book guides installation personnel through the process of installing the
hardware and software up to and including the point where provisioning can begin
and the expanded network components can be installed and verified. The user
must refer to the provisioning and expanded network component document (s) to
support that phase of the system installation process.
1.1.1 Audience
The audience for this guide is Siemens Professional Services and Back Level
Support personnel. Note that this does not preclude other Siemens personnel,
customers, or third-party service providers who have the necessary prerequisite
knowledge from using the guide.
1.1.2 Prerequisite Knowledge

This guide is written to the user who has:
Successfully completed the Siemens OpenScape Voice installation and

technical training courses.
Advanced SuSE Linux Enterprise Server (SLES) operating system and

Microsoft Windows operating systems knowledge and experience.
Basic knowledge of the third-party platforms and equipment used for

OpenScape Voice including: their physical characteristics, their assembly,
their documentation (installation, service, and troubleshooting), and the
documentation web sites associated with the third-party platform and
equipment manufacturers.
Basic knowledge of the industry standards and specifications utilized by

OpenScape Voice and associated equipment.
The procedures in this guide require an understanding of and adherence to local

safety practices, the safety practices identified in this guide, and the safety
practices identified in the third-party documentation.
A31003-H8050-J100-09-7631, 09/2011
13
notices.fm
Important Notices
About this Book
1.1.3 Viewing the Document with Adobe Reader

When viewing the document with Adobe Reader add the Previous View icon to
the Reader toolbar. This will ease the navigation between this procedure and
associated sections of the document.
Add the Previous View icon as follows;
1. Open the tools menu.
2. Navigate to Customize Toolbars; this will present the More Tools window.
3. In the More Tools window scroll down to the Page Navigation Toolbar.
4. Select the Previous View icon.
5. Select Okay in the More Tools window.
1.1.4 Special Notices

Potentially dangerous situations are noted throughout this guide. The three alert
methods are defined below:
DANGER
A danger notice calls attention to conditions that, if not avoided, will

result in death or serious injury.
WARNING A warning notice calls attention to conditions that, if not avoided,

could result in death or serious injury.
Caution
14
A caution notice calls attention to conditions that, if not avoided,

may damage or destroy hardware or software.
A31003-H8050-J100-09-7631, 09/2011
notices.fm
Important Notices
Safety
1.2 Safety
The following information is included in this publication for the use and safety of
installation and maintenance personnel.
1.2.1 General Safety
Do not attempt to lift objects that you think are too heavy for you.
Do not wear loose clothing; tie back your hair while working on machines.
Wear eye protection when you are working in any conditions that might be
hazardous to your eyes.
After maintenance, reinstall all safety devices such as shields, guards, labels,
and ground wires. Replace worn safety devices.
If you feel any action is unsafe, notify your manager before proceeding.
Do not use a telephone to report a gas leak while in the vicinity of the leak.
1.2.2 Safety with Electricity

Danger: Do not take chances with your life. Follow these safety guidelines
carefully.
1.2.2.1 High Voltages
Observe all safety regulations and read the warnings, cautions, and notes
posted on the equipment.
Find the switch to power off the cabinet. Read the posted instructions.
Ensure that a machine cannot be powered on from another source or

controlled from a different circuit breaker or disconnecting switch.
When a procedure requires that you power off the system:
Lock the wall box-switch in the off position.
Attach a DO NOT OPERATE tag to the wall box-switch.
Never assume that the power is turned off. Always check to ensure that a
circuit does not have power.
A31003-H8050-J100-09-7631, 09/2011
15
notices.fm
Important Notices
Safety
Do not work alone. Work with another person who knows the locations of the
power-off switches, especially if you are working with exposed electrical
circuits.
Follow the instructions in the manual carefully, especially when working with
circuits that are powered. Disconnect power when instructed to do so in the
procedures.
Disconnect all power before working near power supplies unless otherwise
instructed by a maintenance procedure.
Disconnect all power before installing changes in machine circuits unless

otherwise instructed by a maintenance procedure.
High voltages capable of causing shock are used in this equipment. Be

extremely careful when measuring high voltages and when servicing cards,
panels, and boards while the system is powered on.
Do not wear jewelry or other metal objects.
When possible, work with one hand so that a circuit is not created. Keep the
other hand in your pocket or behind your back.
Use caution when installing or modifying telephone lines. Never install

telephone wiring during an electrical storm.
Never install a telephone jack where it can get wet unless the jack is
specifically designed for wet conditions.
Never touch uninsulated telephone wires or terminals unless the telephone

line has been disconnected at the network interface.
Avoid using a telephone (other than the cordless type) during an electrical
storm due to the remote risk of shock from lightning.
1.2.2.2 Equipment Room
16
Look for hazards in your area and eliminate them. Examples are moist floors,
ungrounded power extension cables, power surges, and missing safety
grounds.
Rubber electrostatic mats will not protect you from electrical shock. Do not
use them for this purpose. Stand on suitable rubber mats to insulate you from
grounds such as metal floor strips and machine frames.
Do not use tools covered with a soft material that does not insulate you when
working with powered circuits. Use only tools and testers suitable for the job,
approved by Siemens. Do not use worn or broken tools or testers; inspect
them regularly.
Set controls on testers correctly and use approved probe leads and
accessories intended for that tester.
A31003-H8050-J100-09-7631, 09/2011
notices.fm
Important Notices
Safety
The surface of a mirror is conductive. Do not touch powered circuits with a

mirror. To do so can cause personal injury and machine damage.
Do not store combustible gases or flammable materials in cabinets near the

site.
1.2.2.3 Emergencies
Be familiar with first aid for electrical shock. This includes resuscitation
methods, heartbeat restoration, and burn treatment.
Use caution if an accident occurs. Disconnect the power before touching the
victim.
If you do not know how to disconnect the power, use a nonconductive object,
such as a wooden rod, to push or pull the victim away from electrical contact.
Administer resuscitation if the person is not breathing.
If you are trained and certified, administer cardiac compression if the heart is
not beating.
Call a rescue group, an ambulance, or a hospital immediately.
1.2.3 Reporting Accidents
Report to your manager all accidents, near accidents, and possible hazards
to ensure their causes are resolved as soon as possible.
Report any electric shock, no matter how small.
A31003-H8050-J100-09-7631, 09/2011
17
notices.fm
Important Notices
Safety
18
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
Preparing for the Installation
About OpenScape Voice
2 Preparing for the Installation

2.1 About OpenScape Voice
OpenScape Voice is available as a redundant or a single-node system:
OpenScape Voice redundant is available in a standard duplex configuration:

The nodes in an A31003-H8040-J100-09-7631 redundant system can be
deployed as follows:
Co-located nodes
Geographically separated nodes in either the same subnet or in different

subnets.
The cluster interconnect links for geographically separated nodes employ
a layer 3 IP connection.
The layer 3 IP cluster interconnect connection uses a proprietary
transport layer protocol, Internode Communication Facility (ICF), for
communication. If the cluster interconnect traffic passes through a
firewall, the firewall might block all this traffic. If this is the case, ensure
that the customer has defined custom rules in the firewalls to allow ICF
traffic.
Note: The distance between geographically separated nodes is limited by
a maximum round-trip delay between the nodes of 100 milliseconds. The
theoretical maximum distance is 6,000 miles (10,000 kilometers), but the
customers network must be able to keep the round-trip delay between
the nodes to less than 100 milliseconds.
Standard duplex: The OpenScape Applications (OpenScape Voice

Assistant, RG8700 Assistant, OpenScape Media Server, Customer
License Manager [CLM], Common Management Portal [CMP], and
OpenScape UC Application [not available with initial release of
OpenScape Voice V4]) are installed on an external applications server (or
servers depending upon the OpenScape Voice configuration [the
OpenScape Media Server can be installed on one or more separate
external servers]).
Note: The OpenScape Applications Deployment Service (DLS)
component might not be supported on the external applications server
due to sizing limitations. A separate server running Microsoft Windows
A31003-H8050-J100-09-7631, 09/2011
19
bybegin.fm
About OpenScape Voice
might be required for the DLS component. Please review the DLS release
notes for sizing limitations when DLS is installed as a component of the
external applications server.
Integrated simplex: In this configuration, the OpenScape Applications

(OpenScape Voice Assistant, RG8700 Assistant, OpenScape Media Server,
Customer License Manager [CLM], Common Management Portal [CMP],
Deployment Service [DLS], and OpenScape UC Application [not available
with initial release of OpenScape Voice V4]) are installed on the same server
(the OpenScape Media Server or DLS can be optionally installed on a
separate external server) that hosts OpenScape Voice.
The OpenScape Voice Entry (a low-cost integrated simplex system on an IBM

x3250 M2 server) is offered beginning with OpenScape Voice V4. The lower
cost is achieved by reducing the hardware components and adding an
integrated Session Border Control (SBC) functionality. In OpenScape Voice
V5, the low-cost integrated simplex system is available on IBM x3250 M2 and
x3250 M3 servers.
2.1.1 Administration and Media Server Options

The administration and media server deployment options are as follows:
Integrated simplex: The administration tools and OpenScape Media Server

are installed on the same server (and additional external servers depending
on configuration) that hosts OpenScape Voice.
Standard duplex: The administration tools and OpenScape Media Server are
installed on an external applications server (and additional external servers
depending on configuration).
RadiSys Convedia media servers are also available for use with OpenScape
Voice.
Attention: When servers (e.g media server or DLS) in the same network as one
of the OSV's subnets need to communicate with another of the OSV's subnets,
then changes to the network firewall are required to allow this communication.
Any questions should be addressed to the next level of support.
2.1.2 OpenScape Branch

Available in conjunction with OpenScape Voice V5 is OpenScape Branch for
remote branch offices.
OpenScape Branch provides:
20
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
Installing OpenScape Voice
Continuance of communication services while providing a feature rich set of

survivability capabilities at a remote branch location during loss of
communication or service degradation between the remote branch and the
main location.
A local Media Server for tones, announcements and conferencing reducing

the bandwidth needed between the locations.
Proxy and Session Border Controller (SBC) functionalities and security

functions like Firewall and Virtual Private Network (VPN).
Deployment on several hardware platforms: from one with a maximum

capacity of up to 50 users to one with a maximum of up to 6000 users.
Management via the main locations OpenScape Voice CMP/Assistant and a

localized OpenScape Branch Management Portal.
Refer to OpenScape Branch V1 R4, Installation and Upgrades, Installation Guide,

Issue 5, part number: A31003-H8113-J100-5-7631, for OpenScape Branch
installation instructions.
2.2 Installing OpenScape Voice

2.2.1 Installation Media
The installation media is as follows:
Reference Image DVD: One DVD for a simplex system and two DVDs for a
redundant system.
The OpenScape Voice V5 Reference Image DVD provides the following
components:
OpenScape Voice software
OpenScape Applications (OpenScape Voice Assistant, RG8700

Assistant, OpenScape Media Server, Customer License Manager [CLM],
Common Management Portal [CMP], Deployment Service [DLS], and
OpenScape UC Application [not available with initial release of
OpenScape Voice V4])
SuSE Linux Enterprise Server Version 10 (SLES 10) operating system

with Service Pack 3, Fujitsu-Siemens PrimeCluster, Fujitsu-Siemens
Resilient Telco Platform, SolidTech Database Engine, and other
miscellaneous Siemens and third-party software
OpenScape Voice V5 Installation Wizard CD

Provides several components that help you create the node.cfg file that is
used during the installation to modify the Reference Image.
A31003-H8050-J100-09-7631, 09/2011
21
bybegin.fm
Node.cfg and response file media

One or two USB memory sticks as appropriate for the type of system (one for
a single-node system and two for a redundant system).
Note: Response files no longer need to be generated for integrated systems
and they should not be placed on USB sticks. If a response file is found on
the USB stick that file will take precedence over the file that is automatically
generated via the Image installation.
OpenScape Applications DVD 1 and 2

Note: The OpenScape Applications DVDs are used to install or upgrade the
external OpenScape Applications server for the standard duplex system only.
In the case of an integrated simplex (install and upgrades) , the OpenScape
Applications DVD is only used to create the response files if needed. In V5R0
(and later releases) integrated systems response files are built automatically
as part of the installation process. Response files no longer need to be
generated for images and are not required on USB sticks. If a response file is
found on the USB stick that file will take precedence over the file that is
automatically generated via the Image installation. For integrated systems,
the OpenScape Applications are installed using the OpenScape Voice V5
Reference Image DVD.
DVD 1 contains the OpenScape Applications. This DVD is used to install the
OpenScape Applications onto the external applications server for a standard
duplex after the OpenScape Voice reference image has been installed onto
the nodes. DVD 2 contains the Loquendo TTS announcements.
2.2.2 Prerequisites and Assumptions

The building of the network infrastructure required to support OpenScape Voice
and the network components associated with OpenScape Voice is outside the
scope of this guide. The following is assumed:
22
The design and the configuration of the network infrastructure and

OpenScape Voice is complete.
The IP addresses for OpenScape Voice and its expanded network

components have been established and are available to the installation team.
All the information necessary for creating the node.cfg file is available and
has been provided to the installation team.
All information relevant for implementing IPSec is available and has been
provided to the installation team.
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
2.2.3 Backup License Recommendations

It is strongly recommended that backup license files, which Siemens supplies at
no charge, be readily available. This ensures a rapid return to service if a system
restore must be performed, as described in the OpenScape Voice V4, Network
Planning GuideOpenScape Voice V4, Design and Planning: Volume 3, Security
Reference.
Attention: OpenScape Voice may not be fully operational until these new
licenses are installed.
Refer to OpenScape Voice V4, Reference Manual: Volume 1, System Overview

and Description for detailed information on licensing.
A31003-H8050-J100-09-7631, 09/2011
23
bybegin.fm
2.2.4 OpenScape Voice Installation Checklist

Use the checklist as follows:
1. Make two copies of the checklist.
Keep one copy at the installation site in a location accessible by the

installation team members.
Keep the other copy with you as a backup in the event something
happens to the job site copy.
2. Inform the installation team members of the location of the checklist and ask
them to initial the checklist item when they complete tasks for which they are
responsible.
3. At the beginning and end of your shift each day, update your copy of the
checklist to match the copy kept at the installation site.
Item
Description
Initials
Pre-installation activities: These activities should be completed prior to arriving at the customers installation site
to perform the physical installation tasks.
1.
Download the following from SWS:
The OpenScape Voice V5 reference image and burn (use DVD-R media) it to a DVD (for
a single node system) or two DVDs (for a redundant system).
The Installation Wizard ISO image and burn it to a CD.
The OpenScape Applications DVD ISO image and burn it to a DVD.
Note: While it is not part of the installation media, also download the latest Restore CD as it
might be needed in the event of a failed installation.
Refer to appropriate release notes on G-DMS for the links to SWS and instructions for
downloading the images and preparing the media.
2.
For x3650T only: Download the Siemens re-mastered firmware updates or the Intel/IBM
firmware updates (if appropriate) from SWS.
Siemens has re-mastered the IBM x3650T firmware updates (associated with MOP P30310Q2028-Q110-xx-7620) and automated the update process. In some cases, there might be
more recent Intel/IBM firmware updates that have been tested as a single unit, but have not
been automated yet.
Refer to the OpenScape Voice V5 release notes on G-DMS for a link to SWS and for
instructions on downloading and preparing the updates.
Table 1
24
OpenScape Voice Installation Checklist (Sheet 1 of 5)
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
Item
Description
3.
If necessary, prepare the patch sets and MOP materials. Refer to the OpenScape Voice V5
patch set release notes on G-DMS for a link to SWS and for instructions on downloading and
preparing the patch sets and MOP materials.
4.
Obtain the V5 license activation codes.
5.
Create the response file for an integrated system: Refer to Section 5.2.4, Installation/Update
Instructions for Integrated Simplex Systems, on page 340.
Note: In V5R0 (and later releases), integrated systems response files are built automatically
as part of the installation process. Response files no longer need to be generated for images
and are not required on USB sticks. If a response file is found on the USB stick, that file will
take precedence over the file that is automatically generated via the Image installation.
6.
Create a node.cfg file.
For non virtual machine server, refer to Section 2.5 on page 35.
For a virtual machine server, refer to Section 4.3.4, Creating a Node.cfg File, on page
235.
Initials
On-site installation activities: These activities are performed at the local installation site and, as applicable, at
associated remote sites.
7.
Install the Ethernet switches into the rack. Refer to the rack and Ethernet switch
documentation.
8.
Install the servers.
For IBM x3650T servers, refer to Section 3.3 on page 52 for instructions.
For FSC RX330 servers, refer to Section 3.4 on page 82 for instructions.
For IBM x3250 M2/M3 servers, refer to Section 3.5 on page 113 for instructions.
For IBM x3550 M2/M3 servers, refer Section 3.6 on page 142 to for instructions.
For FTS RX200 servers, refer to Section 3.7 on page 172 for instructions.
9.
Install the OpenScape Voice V5 reference image. Refer to Chapter 4 for instructions. The
Virtual Machine environment setup can be found in Section 4.3, Virtualization Environment
Setup, on page 222.
10.
Create a password for root and perform any other password and account management
activities. Refer to the OpenScape Voice OpenScape Voice V4, Design and Planning:
Volume 3, Security Reference, Design and Planning Manual: Volume 4, Security Checklist
for instructions.
11.
For IBM x3650T, FSC RX330, IBM x3550 M2/M3 and FTS RX200: Change the default user
ID and password for the Intel Management Module account or Integrated Remote
Management Controller (iRMC) account. Refer to Section 4.4.2 on page 284.
Note: Step 11 is not required in a virtual machine environment.
Table 1
A31003-H8050-J100-09-7631, 09/2011
25
bybegin.fm
Item
Description
12.
For duplex systems, verify the Linux HA Survival Authority and IPMI shutdown agents.
Reference Section 6.7, Verifying the Shutdown Agents Configuration, on page 418.
13.
If applicable, change the Ethernet NICs to a fixed operation mode (the default is autonegotiation operation). Refer to Section 4.4.3 on page 286.
14.
Check the Ethernet port assignments, refer to Section 4.4.4 on page 288.
15.
If applicable, test the KVM/mouse combination. Refer to Section 4.4.5 on page 293.
16.
For the OpenScape Voice Entry only: If applicable, enable and configure the OpenScape
Voice Entrys integrated SBC function. Refer to Section 4.4.7 on page 295.
17.
If applicable, create and install Transport Layer Security (TLS) certificates. Refer to Appendix
Appendix L, OpenScape Voice Signaling Stream Security for instructions.
18.
If necessary, apply MOPs. Refer to the MOPs for instructions.
19.
If the customer is providing hardware for an external applications server, ensure that the
server is installed and meets the requirements described in Section 5.1.2, Customer
Provided Hardware Specifications, on page 306.
20.
If the OpenScape UC Application (not available with initial release of OpenScape Voice V4) is going to
be deployed, refer to the OpenScape UC Application Installation and Planning guides for preinstallation
requirements.
21.
Configure the media server using the msconf.sh script. Refer to Appendix J, Media Server
Announcements, Treatments and Prefix Access Code Installation Guide.
Note: The Media server must also be configured in the simplex version.
22.
For integrated systems, install any additional Media Server language(s). Refer to Section
5.2.4.5, Add Languages, on page 345.
23.
If applicable, verify remote access for the srx user account in a Standard Duplex
configuration. Refer to Section 4.4.1, Verify Remote Access for srx Account in a Standard
Duplex, on page 284.
24.
For standard duplex only: Install OpenScape Applications onto the external applications
server. Refer to Section 5.2, Installation Instructions for Applications Servers, on page 308.
25.
If applicable, change the SNMP Community Names on the OpenScape Voice server. Refer
to Section 4.4.6, SNMP Community Names on OpenScape Voice, on page 293.
Table 1
26
Initials
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
Item
Description
26.
Download the licenses to the OpenScape Voice nodes.

Simplex systems perform the activity of Section 8.9.2, Customize Node 1 and then return to
Checklist Item 27.
Duplex systems must perform both the Section 8.9.2, Customize Node 1 and Section 8.10.2,
Customize Node 2 activities. Return to Checklist Item 27.
------------------------------------------------------------------------------------------------------------------------------------Hint: Verify the license data has been updated to the OpenScape voice server. After the license files
(or file in the case of a simplex system) are downloaded; wait at least 7 minutes and then display the
License Usage Indicator info via Cli;
Initials
To access the RTP Cli interface enter startCli from the OpenScape Voice server prompt (the
OpenScape Voice server must be in state 4);
sysad@nodename:[/home/sysad] #183
$ startCli
From the Cli Main Menu select:
6 (Application-level Management)
1 (Softswitch Management)
1 (Softswitch Information)
10 (Software License Management)
1 (Display Usage Indicator Info)
The Usage Indicator display should reflect the values of the downloaded license files (or file in the case
of a simplex system).
Or, to enter the expert form of RTP Cli enter startCli x from the OpenScape Voice server prompt
(the OpenScape Voice server must be in state 4);
sysad@ nodename:[/home/sysad] #184

$ startCli -x
>licendpointdisplay
The Usage Indicator display should reflect the values of the downloaded license files (or file in the case
of an simplex system). Any questions should be addressed to your next level of support.
-------------------------------------------------------------------------------------------------------------------------------------
27.
Import the subscriber database file using the Common Management Portal. Refer to the
OpenScape Voice V5, Service Manual, Service Documentation or CMP online help for
instructions.
28.
For geo-separated deployments: refer to the OpenScape UC Suite V*, Solution Test Manual,
Administrator Documentation, Section Configuration Guide FQDN & DNS-SRV for
instructions on how to enable FQDN support on the OpenScape Voice Server.
29.
If applicable, ensure that OpenScape Voice is configured for HiPath 4000 interoperability.
Refer to the appropriate OpenScape Voice configuration documentation and HiPath 4000
documentation for instructions.
30.
If applicable, ensure that the RG 8700 is installed and operational. Refer to the RG 8700
31.
If applicable, ensure that the RG 2700 is installed and operational. Refer to the RG 2700
Table 1
A31003-H8050-J100-09-7631, 09/2011
27
bybegin.fm
Guidelines for Static Routes of Geographically Separated Nodes
Item
Description
32.
If applicable, ensure that OpenScape Voice is configured for the gateway that provides E911
functionality.
33.
Ensure that the billing servers are installed.
34.
If applicable, ensure that the third-party media server, or servers, are installed and
operational.
35.
If applicable, ensure that the CAP server, or servers, are installed.
36.
If applicable, ensure that the ComAssistant server/application is installed and operational.
37.
If applicable, ensure that the OpenScape Xpressions server/application is installed and

operational.
38.
If applicable, ensure that the OpenScape Contact Center server/application is installed and
operational.
39.
Ensure that optiPoint telephones and optiPoint soft clients are deployed and operational.
40.
Ensure that OpenStage telephones are deployed and operational.
41.
If applicable, verify OpenScape Voice interoperability with the HiPath 4000.
42.
If applicable, verify OpenScape Voice interoperability with the RG 8700.
43.
If applicable, verify OpenScape Voice interoperability with the RG 2700.
44.
Verify E911 functionality through the gateway that provides E911 functionality.
45.
Ensure that the basic traffic tool is installed and configured. Refer to Chapter 10.
46.
If applicable, ensure that branch survivability equipment is installed, configured, and

functioning properly. For OpenScape Branch, refer to OpenScape Branch V*/R* Service
Manual Volume 1, Installation and Upgrades, part number A31003-H8113-J100-*-7631 for
more information. If branch survivability solutions other than OpenScape Branch are
employed, refer to the appropriate documentation for the survivability solution.
47.
If applicable, ensure that IPSec-based connections are created for secure endpoints, SIP
endpoints, media servers, and media gateways.
48.
After system and feature verification is complete, perform a file system backup. Refer to the
OpenScape Voice V5, Service Manual, Service Documentation or CMP online help for
instructions.
Table 1
Initials
2.3 Guidelines for Static Routes of Geographically Separated Nodes

The following guidelines apply to static routes of geographically separated nodes.
The general rules for creating the static routes in the node.cfg file are:
28
The default router in the node.cfg must be on the SIGNALING network

(nafo1 [bond1] subnet) of OpenScape Voice.
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
In general, all static routes should be created for the Admin network for both
subnets (nafo0 [bond0]), except of the broadcast routes and the x-channel
static routes that are automatically created for the Cluster network (nafo3
[bond3]).
Create static routes for the SurvivalAuthority IP for both nodes.
Static routes 'first_node_bc1' and 'second_node_bc1' (if they exist) are set by
default and should not be changed. These routes are used for OpenScape
Voice network broadcast and multicast messages.
For example, assume that the SIGNALING network IP addresses on the nafo1
(bond1) subnet and that the ADMIN network IP addresses on the nafo0 (bond0)
subnet are as follows:
Parameter
SIGNALING NETWORK
ADMIN NETWORK
(bond1)
(bond0)
id
nafo1
nafo0
nafo group
nafo_udp
nafo_alias
itf1
bond1
bond0
itf2
bond1
bond0
node 1
10.5.11.10
10.5.12.10
node 2
10.5.131.20
10.5.132.20
netmask
255.255.255.0
255.255.255.0
subnet
10.5.11.0
10.5.12.0
gateway
10.5.11.1
10.5.12.1
broadcast
10.5.11.255
10.5.12.255
netmask_2
255.255.255.0
255.255.255.0
subnet_2
10.5.131.0
10.5.132.0
gateway_2
10.5.131.1
10.5.132.1
broadcast_2
10.5.131.255
10.5.132.255
Using the general rules and these network IP addresses, an example of the static
routes created using the NCPE for the node.cfg file would be as follows:
default_router: 10.5.11.1
default_router_2: 10.5.131.1
domain_name: h8k.sec
DOMAIN_NAME: H8K.SEC
survival_authority: 10.0.242.250
first_node_r1:
10.5.132.20 255.255.255.255 10.5.12.1 nafo0
first_node_bc1:
239.255.255.253 255.255.255.255 nafo3
second_node_bc1:
239.255.255.253 255.255.255.255 nafo3
second_node_r1:
10.5.12.10 255.255.255.255 10.5.132.1 nafo0
Consider the following regarding static routes:
A31003-H8050-J100-09-7631, 09/2011
29
bybegin.fm
During the installation of OpenScape Voice geographically separated nodes,

you will see error messages such as "network unreachable" on your console
for the NTP server IP addresses and for all the "static route" IP addresses.
These are expected errors because the bonding devices on the OpenScape
Voice nodes are not set up at that time.
After the bonding devices are created, these error messages will no longer be
displayed, the cluster should go to state 4 4, and the L2/L3 interconnection
test should pass successfully.
There are two methods to add static routes to the node.cfg file for machines
you add to the network after OpenScape Voice has been placed into service:
You may use the NCPE Update function. The NCPE update function
requires a reboot that will take OpenScape Voice out of service for several
minutes. See the Caution note on page 641 for more details.
To avoid taking the server out of service, you may use the route add
command from the OpenScape Voice console while OpenScape Voice is
in state 4 4. For example, for Node1 and Node2, issue the following
command from the console:
# route add -net <destination IP> <destination IP mask> <gateway>
<interface>
Static routes added from the console in this manner will not survive a
node reboot. The node.cfg needs to be updated with the static routes so
that after a reboot the routes will survive. Update the node.cfg files as
follows:
1. Transfer each nodes node.cfg file to a computer that can run the
NCPE.
2. Add the static routes to the node.cfg files.
3. Keep backups of the original node.cfg files in each node.
4. Replace the node.cfg files with the new node.cfg files that contain the
static routes.
The default filter rules of OpenScape Voice block pinging through the
SIGNALING network. To use ping through the ADMIN network, do the
following:
1. Get the bond0 IP addresses of the nodes with the command:
# grep bond0 /etc/hiq8000/node.cfg
2. Then use ping from Node1 with the command:
# ping -I <bond0_IP_node1> <ping_IP>
For example, assume bond0 is 10.5.12.10 for node1 and bond0 is
10.5.132.20 for Node2, issue the following command from Node1:
# ping -I 10.5.12.10 10.5.132.20
30
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
Source Based Routes
Or to ping with tracing, issue the command:

# ping -R -I 10.5.12.10 10.5.132.20
2.4 Source Based Routes

OpenScape Voice V5 supports source based routing, where OSV sends IP
packets to an IP gateway/router based on which subnet the source IP of the
packet belongs to. For this, default gateways should be specified for the OSV IP
subnets admin, signaling and billing. If, for example, a billing gateway is
specified, the OSV sends billing files via this gateway and there is no need for the
creation of static routes to each billing server.
Another advantage of source base routing is that responses to admin requests
from a remote IP network to the OSV admin IP address are sent back via the
default admin gateway. Without this admin gateway, the response would be sent
via the default router, which is usually on the signaling network.
Even with source based routing, there is a need for static routes because not all
OSV Software specifies a source IP to an outgoing packet to give source based
routing the necessary information. Some static routes are automatically created
by the NCPE tool at installation, but others have to be created by the installer/
craft. Generally a route is needed if the IP address of the destination is not in one
of the local subnets.
(It is assumed that the global default router is in the Signaling subnet)
DNS
If the DNS is on the customer OAM&P network, the static route should
employ the admin gateway as the destination.
If the DNS is on the customer signaling network, there is no need for

a static route as the DNS traffic can route via the default router
(without a static route applied).
NTP
If the NTP server is on the customer OAM&P network, the static route
should employ the admin gateway as the destination.
If the NTP server is on the customer signaling network, there is no

need for a static route as the NTP traffic can route via the default
router (without a static route applied).
Partner billing node (employed during a Split Mode Upgrade)
Billing server (unless there is a default billing gateway - in this case, the
default route of the Billing subnet will be used)
A31003-H8050-J100-09-7631, 09/2011
31
bybegin.fm
Source Based Routes
Partner admin (unless there is a default admin gateway - in this case the
NCPE creates the static route automatically)
Partner x-channel (unless there is a default x-channel gateway - in this

case the NCPE creates the static route automatically)
SNMP Trap destination (a static route should be added pointing to the

Admin subnet gateway IP address). There are plans to have the NCPE
generate static routes automatically if an admin gateway exists.
Backup server (unless there is a default admin gateway - in this case the
default route of the Admin subnet will be used)
Trace Manager (unless there is a default admin gateway - in this case the
default route of the Admin subnet will be used)
Super User (CMP) (unless there is a default admin gateway - in this case
NCPE creates the static route automatically)
Survival Authority (unless there is a default admin gateway - in this case

the NCPE creates the static route automatically)
The following diagram represents possible static routes for an OpenScape Voice
server. The following assumptions are made for this system;
32
The Admin, Signaling, Billing, and x-channel subnets have default

gateways assigned
The global default router is in the Signaling subnet
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
Source Based Routes
It is therefore highly recommended to specify default gateways via NCPE, when

preparing the node.cfg for the new release.
Notes:
There is no source based routing for the OSV x-channel subnet. But an xchannel default gateway is still required if the x-channel subnets of the two
nodes are different. It is used by the OSV to automatically create a static
route to the partner node x-channel IP address.
A31003-H8050-J100-09-7631, 09/2011
33
bybegin.fm
Source Based Routes
Even with source based routing, static routes are still required for OSV trap
destinations, NTP and DNS (the reason is that OSV software does not control
the source IP of packets sent to these devices).
OSV automatically replicates each static route to the source based routing
table of the subnet that the router belongs to. For example, if the admin
network is 1.2.3.0 to 1.2.3.255 and if a static route to IP 4.4.4.4 is specified
via router 1.2.3.1, there will be two static routes, one in the admin source
based routing table and one in the global routing table. So even if the OSV
sends out a packet to 4.4.4.4 with source IP 2.2.2.2, it will still go via 1.2.3.1.
Note: If you arrived here from Section 2.5, Step 8 on page 40, this link will take
you back.
34
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
Creating a Node.cfg File
2.5 Creating a Node.cfg File

Note: Because the network design and IP address allocations should already be
known, it is strongly recommended that you prepare the node.cfg file prior to
arriving at the customers installation site to perform the physical hardware and
software installation tasks.
Refer to the OpenScape Voice V4, Network Planning Guide for information on
subnetting scheme network assignments and for the recommended cluster
addressing scheme.
Note: In OpenScape V5 Source-Based IP Routing is implemented. If route

operations message windows are presented during the Node.cfg creation, the
OK button should be selected. For more information regarding the SourceBased IP Routing feature as it applies to installations, refer to Section 2.4,
Source Based Routes.
You create the node.cfg file by editing a node.cfg file template using the
Installation Wizard. The Installation Wizard helps to eliminate errors in the
node.cfg file that can result in problematic or failed installations.
The Installation Wizard consists of several components: an Installation
Framework (IF), Node Configuration Parameters Editor (NCPE), hardware
definition files, IP address definition files, and other data definition files. The
Installation Wizard automatically populates fields in the NCPE (and the node.cfg
file) based on your selection in the Installation Framework screen and selections
in subsequent NCPE screens.
The NCPE provides two modes: Wizard and Expert. The Installation Framework
component launches the NCPE in Wizard Mode after you select whether you are
doing an Install or an Update. A button at the bottom right corner of the NCPE
screens allows you to switch to Expert Mode and an icon in the tool bar in Expert
Mode allows you to switch to Wizard Mode.
Attention: Input to the IP Configuration and IP Security sections of the node.cfg
will create packet filter rules that secure access to the OpenScape Voice server.
Create the node.cfg file as follows:

Attention: The following procedure is for an initial installation of OpenScape
Voice V5. If you are upgrading to V5, refer to Chapter 7, Overview of
Upgrades and Migrations to OpenScape Voice V5 for upgrade information
and procedures.
A31003-H8050-J100-09-7631, 09/2011
35
bybegin.fm
1. As necessary, format the USB memory stick or sticks. Refer to Appendix G,

Formatting a USB Memory Stick.
2. Insert the OpenScape Voice Installation Wizard CD into the CD/DVD drive
and connect the USB memory stick to a USB port (if the Installation Wizard
does not start automatically, navigate to the bin folder on the CD and doubleclick ifgui.cmd).
Note: If necessary, refer to the OpenScape Voice base software release note
on G-DMS for the link to SWS to download the Installation Wizard ISO image
and burn it to a CD.
The Installation Framework options screen appears.
3. On the Installation Framework options screen, select Install and click Next.
The Node Configuration Parameters Editor (NCPE) opens in Wizard Mode
and displays the Section 1: Configuration and Hardware (1/1) screen.
4. On the Section 1: Configuration and Hardware (1/1) screen, select the values
for the following fields.
Hardware Platform: Select FSC RX 330 S1, FTS RX 200 S6, IBM
x3250M2, IBM x3250M3, IBM x3550M2, IBM x3550M3, IBM x3650T or
Virtual-OSV as appropriate.
When selecting Virtual-OSV, only the configuration Standard Duplex is
offered.
If you select a IBM x3250 hardware platform, the Low Cost option (also
known as the OpenScape Voice Entry) is automatically specified in the
Configuration field. The Node Separation field, Survival Authority
field, and Stand Alone Service Enabled check box are removed and
only the Timezone and Keyboard fields are shown.
Configuration: Select Integrated Simplex or Standard Duplex as

appropriate.
If you select Integrated Simplex; the Node Separation field, Survival
Authority field, and Stand Alone Service Enabled check box are
removed and only the Timezone and Keyboard fields are shown.
Note: New installations, upgrades or migrations to an integrated duplex
system are not offered with V5R0. If you are upgrading an integrated
duplex to V5R0, refer to Chapter 7, Overview of Upgrades and
Migrations to OpenScape Voice V5 for upgrade information and
procedures.
36
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
Node Separation: This field appears only if you selected the duplex
option.
Select none for co-located duplex systems or for duplex systems where
the nodes are geographically separated but still on the same IP subnet
(L2 geographically-separated systems).
Select the separate option for duplex systems where the nodes are
geographically separated and require different subnet schemes for the
management, signaling, and billing networks of each node (L3
geographically-separated systems).
In OpenScape Voice V4 (and later releases), the Standalone Service
option is available for duplex configurations. If it is enabled, a node that
does not receive permission to take over from the Survival Authority stays
active (in Standalone Secondary mode). For more information regarding
the Standalone Service feature refer to Section 2.5, Creating a Node.cfg
File step 4or to the OpenScape Voice V5, Feature Description
documentation, section "Survival Authority".
For the StandAlone Service feature to be available in a Virtual or
non-Virtual environment, the node.cfg parameter Node Separation =
separate must be selected. The Stand Alone Service is enabled by
default in this configuration.
Note: When the separate option is selected, virtual IP migration is not
possible.
Survival Authority: This field appears only if you selected the duplex
option. Enter the Survival Authority IP address.
Timezone: Select the appropriate time zone from the drop-down list.
Keyboard: Select the appropriate keyboard language from the drop-down

list.
Stand Alone Service Enabled check box:
A31003-H8050-J100-09-7631, 09/2011
37
bybegin.fm
This box appears only if you selected the duplex option. Stand Alone
Service is enabled by default for all L3 geographically separated
deployments. Stand Alone Service is recommended to be enabled for L2
geographically separated deployments as well, where the nodes are in
different geographic locations but still on the same IP subnet.
Note: There is one exception for the case of Virtual geographically
separated deployments with the two nodes belonging to the same IP
subnets (indicated by node separation = none); the Stand Alone Service
should not be enabled.
If this flag is enabled both OSV nodes will stay up and running (in
Standalone Primary / Standalone Secondary mode) if the cluster
interconnection is totally lost and the down status of the partner node
cannot be confirmed. Once the failure is repaired and the communication
between the nodes is restored, the Standalone Secondary node will
perform a reboot to synchronize cluster.
If this flag is disabled (not recommended) one node will perform a reboot
immediately upon detection of a complete interconnection failure and will
stay at cross-connect-check step, waiting for the craft input or for the
repair of the interconnection failure.
Stand Alone Service is recommended to be disabled for co-located
duplex systems, so leave this box unchecked if you are configuring such
a deployment.
Click Next. The NCPE displays the Section 2: Cluster Installation (1/1)
screen.
5. Enter the cluster installation parameters as follows:
Note: The convention in this guide for referring to the nodes is as follows:
Node1 refers to the node identified by the node1name parameter value and
Node2 refers to the node identified by the node2name parameter value in
the node.cfg file.
a) On the Section 2: Cluster Installation (1/1) screen, type the
<clustername>, <node1name>, and <node2name> (if applicable).
Observe the following when naming the nodes:
Attention: If you were referred to this section by a V3.1R3/V4R1 to V5
upgrade or migration procedure and are updating your node.cfg for
conversion to the target release of V5, do not make changes to the node
names at this time. Refer to the upgrade or migration procedure for the
specific node.cfg changes required.
38
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
The node name should not contain the underscore (_) character (for
example, node1_name). The Installation Wizard will reject a node
name that contains an underscore character.
Do not use the following as node names: Single characters (for

example; a, b, c, 1, 2, 3), dots (...), pri, sec, dev, alias, bond, priv, prim,
cluster, node0, node1, node2, clusternode1, clusternode2, or
localhost.
Use only lowercase alphabet and numeric characters (for example;

pchprod1, pchprod2). Do not use any symbols. Node names cannot
begin with a numeric character (for example; 1pchprod), but can use
numeric characters inside or at the end of the name (for example;
pch1prod or pchprod1).
Node names should consist of at least four characters (more than six
is recommended) and can include up to 20 characters.
If you have questions regarding node naming, contact your next level of
support.
b) Click Next.
The NCPE displays the Section 3: IP Configuration (1/3) screen.
6. Enter the IP configuration parameters for the Management Network,
Signaling Network, Billing Network and Cluster Interconnect Group
(CIGroup).
a) On the Section 3: IP Configuration (1/3) screen, type the IP addresses in
the Subnet and Netmask fields for the Management, Signaling Network,
Billing Network and Cluster Interconnect Group (CIGroup).
Note: If you selected Separate for the Node Separation parameter there
are 2 additional fields (Subnet Node 2 and Netmask Node 2) for each
network. The IP addresses for the second subnet are indicated in these
fields. For example, if the management interface on Node1 is on subnet
1.2.3.0, and the second subnet is 4, then Subnet Node 2 is 1.2.4.0.
b) Click Next.
The NCPE displays the Section 3: IP Configuration screen (2/3).
7. Enter IP configuration parameters for;
DNS Configuration
NTP Configuration (FQDNs or IP addresses)
A31003-H8050-J100-09-7631, 09/2011
39
bybegin.fm
For the Super User value enter the IP address of the CMP/external
Applications server associated with the OpenScape Voice system.
Note: To change the NTP server or DNS configuration after the system is
placed into service, refer to Appendix F, Updating the Node.cfg File (Also
Known as EZIP). Changing the NTP server or DNS configuration is done by
using the Update option of the EZIP tool as described in Appendix F. The
changes to NTP and DNS parameters will not cause a system outage.
When opening the EZIP GUI in the Update option, the fields that are related
to NTP and DNS have a blue background color. The colored background
indicates that modification to these fields will not cause a system outage.
The EZIP tool updates all the files and packet filter rules that relate to the NTP
and DNS parameters and IP addresses.
Click Next.
The NCPE displays the Section 3: IP Configuration screen (3/3).
8. Enter IP configuration parameters for the Default Router, Domain Name, the
Cluster Name for the OpenScape Voice Assistant, and the SIP addresses for
Node 1 and Node 2 (if applicable) as follows:
Note: If you selected separate for the Node Separation parameter in step 4
on page 36, there is a Default Router Node 2 field. Ensure that the IP
address for the second subnet in the Default Router Node 2 field is correct.
a) On the Section 3: IP Configuration screen (3/3), enter the parameters for
the following:
Default Router Node 1 (and Default Router Node 2, if applicable)
Domain Name
Cluster Name for the OpenScape Voice Assistant
SIP addresses for Node 1 and Node 2 (if applicable)
IPv6 addresses of SIP signaling manager are available (if needed)
If you selected separate for the Node Separation parameter in step 4 on

page 36, the NCPE automatically created static routes for each node.
Check (switch to Expert Mode and click the IP Configuration (5/6) tab) the
routes and ensure that they are correct (refer to Section 2.3, Guidelines
for Static Routes of Geographically Separated Nodes, on page 28).
To add static routes, switch to Expert Mode and select the IP
Configuration (5/6) tab and add the static routes in the according field.
NO duplicate routes should exist. Duplicate routes will result in Image
installation failures. Duplicate routes should be deleted using the Delete
40
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
button (X) provided with each table. A method to verify the existence of
duplicate routes is to employ the Preview mode, which is accessed by
selecting the Preview icon in the NCPE menu bar (or by selecting the File
menu and then Preview). This same exercise should be performed in the
IP Configuration (6/6) screen as required.
Even with source based routing, there is a need for static routes because
not all OSV Software specifies a source IP to an outgoing packet to give
source based routing the necessary information. Some static routes are
automatically created by the NCPE tool at installation, but others have to
be created by the installer/craft. Generally a route is needed if the IP
address of the destination is not in one of the local subnets. For more
details refer to Section 2.4, Source Based Routes, on page 31.
The following info would be required to add this static route;
The destination server IP address
The destination IP address netmask (typically 255.255.255.255)
For the subnet gateway IP address, refer to Section 3: IP

Configuration screen (1/6).
For the SNMP server example the Administration subnet gateway IP

address would be employed.
For the Billing server example the Billing subnet gateway IP address
would be employed.
The Nafo ID is automatically populated based on the subnet gateway.
Any questions should be addressed to your next level of support.

To enter CSTA (Computer Supported Telecommunications Applications)
Server(s), switch to Expert Mode and select the IP Configuration (4/6) tab
and enter the FQDN or IP address of the CSTA Server in the according
field.
b) Click Next.
The NCPE displays the Section 4: IP Security screen (1/3).
9. Enter IP Security parameters as follows:
A31003-H8050-J100-09-7631, 09/2011
41
bybegin.fm
a) On the Section 4: IP Security screen (1/3), the SNMP Servers field, type
the IP addresses and ports for the OpenScape Voice Assistant and for the
HISPA server (the HISPA server uses port 12345). Click the appropriate
icon below the table to enter more values or to remove values.
Attention: For Integrated system enter the local loopback IP address
127.0.0.1 and port 162 as an SNMP server.
Also on the Section 4: IP Security screen (1/3), type the FQDNs or IP
addresses for the License Servers and accept the default value for the
LicenseAgentPort. Click the appropriate icon below the table to enter
more values or to remove values. Click Next.
b) On the Section 4: IP Security screen (2/3), type the FQDNs or IP
addresses for the Billing Servers and Billing Clients. Click the appropriate
icon below the table to enter more values or to remove values. Click Next.
c) On the Section 4: IP Security screen (3/3), select the desired SSH
Algorithms from the list and click Finish.
The NCPE opens a Node.cfg Preview window and displays the node.cfg
file you just created for you to review.
10. In the Node.cfg Preview window, click OK.
The NCPE opens a Node.cfg Save dialog box.
11. In the Node.cfg Save dialog box, specify where to save the file and click Save.
The NCPE displays a message box stating that the node.cfg was saved
successfully.
12. In the message box indicating the node.cfg was saved successfully, click OK
and when prompted, Do you want to exit?, click Yes.
13. After the Installation Framework screen appears, click Finish.
14. Copy the completed node.cfg file to the USB memory stick as
node.cfg.primary, disconnect the stick from the USB port, and label it
node.cfg.primary. For a redundant system, connect another memory stick,
copy the node.cfg to the second memory stick as node.cfg.secondary, and
label the stick node.cfg.secondary. Ensure the file was not saved with a
name that has a .cfg extension (for example: node.cfg.primary.cfg). The file
name should be without the second .cfg extension (in fact: node.cfg.primary).
Note: Patch sets can be loaded onto the memory sticks for automatic
installation during the image installation. This can be done now or at any time
before you begin the image installation. Refer to Section 2.6, Loading Patch
Sets onto the USB Memory Sticks, on page 43 for instructions.
42
A31003-H8050-J100-09-7631, 09/2011
bybegin.fm
Loading Patch Sets onto the USB Memory Sticks
15. For an integrated simplex only: Rename the response file that you created for
the simplex system to response.cfg.primary and copy it to the USB stick.
Attention: In V5R0 (and later releases) integrated systems response files are
built automatically as part of the installation process. Response files no longer
need to be generated for images and are not required on USB sticks. If a
response file is found on the USB stick that file will take precedence over the
file that is automatically generated via the Image installation.
16. On the OpenScape Voice Installation Checklist, initial step 6. After you arrive
at the customer site and are ready to begin the physical installation tasks,
proceed to step 7 of the OpenScape Voice Installation Checklist.
2.6 Loading Patch Sets onto the USB Memory Sticks

Patch sets and emergency patch sets may be loaded onto the USB memory stick
for automatic installation during the image installation as follows:
Note: A Windows PC or Linux server can be used for performing this procedure.
1. Create a /patch directory on the memory stick for node 1. This memory stick
also contains the node.cfg.primary file.
2. Create an empty file, dev.8kps, under the /patch directory.
3. Put the patch sets and the emergency patch sets into the patch directory.
Generally, this means the needed tar files from the latest cumulative
patch set and all the tar files of the latest cumulative emergency patch
set.
For example, the latest image is delivered with PS07.E02 and cumulative
PS10.E03 is required as part of the image installation;
Download from the cumulative PS10 dummy patch sets 8, 9 and the
cumulative PS10.
Download all of cumulative emergency PS10.E03 (dummy PS10.E01,

PS10 E02 and cumulative PS10.E03).
A31003-H8050-J100-09-7631, 09/2011
43
bybegin.fm
Loading Patch Sets onto the USB Memory Sticks
Place the downloaded patch sets in the patch directory of the USB
memory stick.
Note: If cumulative patch sets are not available, tar files of the regular patch
sets can be placed in the patch directory as well as the related tar files of the
emergency patch sets. The standard naming convention of the patch sets
should be maintained.
4. For a duplex configuration, repeat this procedure to load the patch sets onto
the memory stick for node 2. This memory stick also contains the
node.cfg.secondary file.
Note: This link will take you to Section 4.2, Installation via DVD, on page 213.
44
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Installing the Hardware Platform
Computing Node
3 Installing the Hardware Platform

OpenScape Voice software has passed operability testing on the equipment
described in Section 3.1, Computing Node.
If you are installing a OpenScape Voice redundant system in a geographically
separated node configuration, note that the distance between the nodes is limited
by a maximum round-trip delay between the nodes of 100 milliseconds. The
theoretical maximum distance is 6,000 miles (10,000 kilometers), but the
customers network must be able to keep the round-trip delay between the nodes
to less than 100 milliseconds.
3.1 Computing Node

3.1.1 IBM x3650T Server
Note: The IBM x3650T server has reached end-of-sale and is not available for
new installations. However, an existing IBM x3650T-based OpenScape Voice can
be upgraded to OpenScape Voice V5R0.
The IBM x346 server has also reached end-of-sale and is no longer available for
new installations. Upgrades of an x346-based OpenScape Voice to V5R0
requires replacement of the x346 server with a currently supported platform as
defined by the Product Matrix document.
The IBM x3650T server can be used as the computing node in both of the
redundant configurations and the simplex configuration. The OpenScape Voice
redundant configurations consists of two IBM x3650T servers.
Housed within a rack-mountable enclosure, the IBM x3650T server is equipped
for OpenScape Voice as follows:
Processor: Two 3.2 GHz processors with 800 MHz front-side bus speed
Memory: 8 GB of Double Data Rate 2 (DDR2) memory

Note: OpenScape Voice V5R0 requires 8 GB of memory on this server. IBM
x3650T systems equipped with 4 GB of memory require a memory expansion
to 8 GB before the system can be upgraded to V5.
Hard disk drive: Two 146 GB hot-swappable HDDs in RAID1
CD/DVD drive
A31003-H8050-J100-09-7631, 09/2011
45
recmd_hw.fm
Computing Node
Disk controller: Internal on-board RAID controller
Ethernet interfaces
For a single-node OpenScape Voice server: Four 100/1000BT ports

(three are used). One Dual Gigabit Ethernet PCI card provides two ports
in addition to the two system board ports.
For a redundant OpenScape Voice server: Eight 100/1000BT ports. One

Dual Port Gigabit Ethernet PCI card and one Quad Port Gigabit Ethernet
PCI card provide six ports in addition to the two system board ports.
Remote supervision: One Intel Management Module
Universal Serial Bus (USB) ports: Four (two at the front, two at the back)
Power supply: Two hot-swappable AC power supplies
3.1.2 Fujitsu Siemens Computers PRIMERGY RX330

S1 Server
Note: The FSC RX330 server has reached end-of-sale and is not available for
new installations. However, an existing FSC RX330-based OpenScape Voice can
be upgraded to OpenScape Voice V5R0.
The IBM x346 server has also reached end-of-sale and is no longer available for
new installations. Upgrades of an x346-based OpenScape Voice to V5R0
requires replacement of the x346 server with a currently supported platform as
defined by the Product Matrix document.
The FSC PRIMERGY RX330 S1 (hereafter referred to as the FSC RX330) server
is used as the computing node in both of the redundant configurations and the
simplex configuration. The OpenScape Voice redundant system consists of two
FSC RX330 servers.
Housed within a rack-mountable enclosure, the FSC RX330 server is equipped
46
Processor: Two Dual-Core or Quad-Core (available first quarter of 2009)

processors
Memory: Eight GB of Double Data Rate 2 (DDR2) memory
CD/DVD drive
Ethernet interfaces:
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Computing Node
For a single-node OpenScape Voice: Four 100/1000BT ports (three are

used). One Dual Gigabit Ethernet PCI card provides two ports in addition
to the two system board ports.
For a redundant OpenScape Voice: Eight 100/1000BT ports. Three Dual

Port Gigabit Ethernet PCI cards provide six ports in addition to the two
system board ports.
Remote supervision: One Integrated Remote Management Controller (iRMC)
Power supply: Two hot-swappable 110/220 AC power supplies
3.1.3 IBM x3250 M2 Server

The IBM x3250 M2 server is used as the computing node for the OpenScape
Voice Entry system and for the OpenScape Branch system.
Housed within a rack-mountable enclosure, the IBM x3250 M2 server is equipped
for OpenScape Voice and OpenScape Branch systems as follows:
Processor: One 2.4 GHz Dual-Core Intel Xeon CPU
Memory: Eight GB
Hard disk drive: One 160 GB SATA
CD/DVD drive
Ethernet interfaces: Two Dual Gigabit Ethernet ports (100/1000BT) on the

system board
Power supply: One 110/220 AC power supply
A31003-H8050-J100-09-7631, 09/2011
47
recmd_hw.fm
Computing Node

The IBM x3250 M3 server is used as the computing node for the OpenScape
Voice Entry system and for the OpenScape Branch system. Housed within a rackmountable enclosure, the IBM x3250 M3 server is equipped for OpenScape Voice
and OpenScape Branch systems as follows:
48
Processor: One 2.4 GHz Quad-Core Intel Xeon CPU
Memory: Eight GB
Hard disk drive: One 250 GB SATA
CD/DVD drive
Ethernet interfaces: Two Dual Gigabit Ethernet ports (100/1000BT) on the

system board
Power supply: One 110/220 AC power supply
The x3250M3 is delivered with a Virtual Media Key which is an independent

maintenance controller (VMK for the X2550 M3) that allows remote console
access.
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Computing Node

Note: The IBM x3550 M2 server has reached end-of-sale and is not available for
new installations. However, an existing IBM x3550 M2-based OpenScape Voice
can be upgraded to OpenScape Voice V5R0.
The IBM x346 server has reached end-of-sale and is no longer available for new
installations. Upgrades of an x346-based OpenScape Voice to V5R0 requires
replacement of the x346 server with a currently supported platform as defined by
the Product Matrix document.
The IBM x3550 M2 server can be used as the computing node in both of the
redundant configuration consists of two IBM x3550 M2 servers.
Processor: Two 2.53 GHz Quad-Core Intel Xeon 5540 CPUs
CD/DVD drive
Ethernet interfaces

(three are used). One Dual Gigabit Ethernet daughter card provides two
ports in addition to the two system board ports.

Dual Gigabit Ethernet daughter card and one Quad Port Gigabit Ethernet
PCI card provide six ports in addition to the two system board ports.
Remote supervision: One Intel Management Module with optional Virtual

Media Key (VMK)
Power supply: Two hot-swappable AC power supplies
A31003-H8050-J100-09-7631, 09/2011
49
recmd_hw.fm
Computing Node

Note: The IBM x3550 M3 is available for upgrades and new installations.
The IBM x346 server has reached end-of-sale and is no longer available for new
installations.
Upgrades of an x346-based OpenScape Voice to V5R0 requires replacement of
the x346 server with a currently supported platform as defined by the Product
Matrix document.
Note: The IBM x3550 M3 is a new server that uses two 6-core CPUs while the
IBM x3550 M2 is an older server and uses two Quad-core CPUs.
Since the two servers are almost alike with only a few differences when it comes
to installation, most of the references in this document will indicate IBM x3550
M2/M3 meaning the section or description applies to both IBM x3550 M2 and IBM
x3550 M3 servers. If differences apply, then they will be clearly indicated as to
which server they apply to.
The IBM x3550 M3 server can be used as the computing node in both of the
redundant configuration consists of two IBM x3550 M3 servers.
Processor: Two 2.66 GHz 6-Core Intel Xeon 5650 CPUs
CD/DVD drive
Ethernet interfaces
50

(three are used). One Dual port Gigabit Ethernet daughter card provides
two ports in addition to the two system board ports.

Dual port Gigabit Ethernet daughter card and one Quad port Gigabit
Ethernet PCI card provide six ports in addition to the two system board
ports.
Remote supervision: One Intel Management Module with optional Virtual

Media Key (VMK)
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Computing Node
Power supply: Two hot-swappable AC power supplies. DC power is optional
3.1.7 Fujitsu Technology Solutions (FTS) PRIMERGY

RX200 S6 Server
Note: The FTS RX200 is available for upgrades and new installations.
The IBM x346 server has reached end-of-sale and is no longer available for
upgrades.
Upgrades of an x346-based OpenScape Voice to V5R0 requires replacement of
the x346 server with a currently supported platform as defined by the Product
Matrix document.
The FTS PRIMERGY RX200 S6 (hereafter referred to as the FTS RX200) server
is used as the computing node in both of the redundant configurations and the
simplex configuration. The OpenScape Voice redundant system consists of two
FTS RX200 servers.
Housed within a rack-mountable enclosure, the FTS RX200 server is equipped
Processor: Two 2.66 GHz 6-Core Intel Xeon X5650 CPUs
CD/DVD drive
Ethernet interfaces:
For a single-node OpenScape Voice: Four 1000PT Cu Ip ports (three are

used). One Dual port Gigabit Ethernet PCI card provides two ports in
addition to the two system board ports.
For a redundant OpenScape Voice: Eight 1000PT Cu Ip ports. One Dual

port Gigabit Ethernet PCI card and one Quad port Gigabit Ethernet PCI
card provide six ports in addition to the two system board ports.
Universal Serial Bus (USB) ports: Six (three at the front, three at the back)
Remote supervision: One Integrated Remote Management Controller (iRMC)
Power supply: Two hot-swappable 110/220 AC power supplies
A31003-H8050-J100-09-7631, 09/2011
51
recmd_hw.fm
Ethernet Switch
3.2 Ethernet Switch

An Ethernet switch, or switches, are required. The Ethernet switch requirements
are as follows:
For a redundant OpenScape Voice with co-located nodes: two, VLAN

capable, in duplex configuration with two high-speed links, at least seven
ports on the OpenScape Voice side, gratuitous ARP support.
For a single-node OpenScape Voice system: one, VLAN capable, at least

four ports on the OpenScape Voice side, gratuitous ARP support. If the
customer premises has a dual subnet LAN configuration, two LAN switches
can be used.
A redundant OpenScape Voice with geographically separated nodes requires

two LAN switches for each node.
The Ethernet switch provides 24 RJ-45 copper 10/100 FastEthernet paths for
system management, control, transfer of call detail record files, and database
maintenance and mirroring. Two Gigabit copper ports and two fiber ports deliver
two active uplinks for greater throughput and two redundant uplinks.
For detailed IP addressing information, refer to the OpenScape Voice V4,
Network Planning GuideOpenScape Voice V4, Network Planning
GuideOpenScape Voice V4, Design and Planning: Volume 3, Security
Reference.
3.3 Installing the IBM x3650T Server

3.3.1 How to use the IBM x3650T Server Installation
Checklist

responsible.
52
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Installing the IBM x3650T Server
3.3.2 IBM x3650T Server Installation Checklist

Use the following checklist to monitor the installation of the IBM x3650T server.
Note: The x3650T is available for new installations; the xSeries 346 has gone
end-of-life and is no longer available for new installations.
The x3650T is shipped to the site fully assembled.
Item
Description
Initials
1.
Inventory and inspect the hardware. Refer to Section 3.3.3 on

page 53.
2.
Check to see if a RAID card is installed in the top full-height PCI

slot of the x3650T. If it is installed, remove it. Refer to Section
B.2 on page 621.
3.
Locate the IBM x3650T server printed documentation and digital

media. Refer to Section 3.3.4 on page 54.
4.
Attach the slides to the rack and place the servers onto the
slides. Refer to Section 3.3.5 on page 54.
5.
Connect all cables.
Single-node OpenScape Voice systems: Refer to Section

3.3.6.1 on page 55.
Redundant OpenScape Voice systems: Refer to Section

3.3.6.2 on page 57.
6.
Modify the SCSI RAID configuration. Refer to Section 3.3.7 on

page 62.
7.
Modify the server BIOS settings: Refer to Section 3.3.8 on page

69.
8.
Update firmware. Refer to Method of Procedure (MOP),

P30310-Q2692-Q130-XX-7620, IBM X3650T base firmware for
HiPath V4. Where XX = latest release version of the MOP.
9.
Ensure that the Intel Management Server (ISM) software is

installed onto the Microsoft machine where console redirection
shall take place. Refer to Section 3.3.10 on page 76.
Table 2
IBM x3650T Server Installation Checklist
3.3.3 Inventorying and Inspecting the IBM x3650T

Server Installation Materials
Receive the materials as follows:
A31003-H8050-J100-09-7631, 09/2011
53
recmd_hw.fm
1. Inventory and inspect the materials.

2. Check for shipping damage.
3. Track shortages and discrepancies of materials.
4. Return and reorder damaged material according to local procedures.
5. On the IBM x3650T Server Installation Checklist, initial step 1 and proceed to
step 2.
3.3.4 Locating the IBM x3650T Server Printed

Installation Guides and Digital Media
Collect and store in a secure location at the job site all the printed documentation
and digital media for any equipment that you will be installing. This includes, but
is not necessarily limited to the following:
IBM x3650T server printed guides and digital media
Ethernet switch documentation
KVM (if so equipped) documentation
Power distribution unit (PDU) or uninterruptible power supply (UPS)

documentation (if so equipped)
You might need to reference these documents/media for installation procedures,

physical characteristics of the server and other hardware components, and for
troubleshooting procedures.
On the IBM x3650T Server Installation Checklist, initial step 3 and proceed to step
4.
3.3.5 Installing the IBM x3650T Servers into the Rack

Install the servers into the rack as follows:
1. Refer to the IBM rack installation instructions to install the servers into the
rack.
step 5.
54
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3.3.6 Connecting the Cables to the IBM x3650T Server

Note: The procedures for connecting cables are different based on the type of
OpenScape Voice system (single-node or redundant). Refer to Section 3.3.6.1 on
page 55 for a single-node OpenScape Voice and to Section 3.3.6.2 on page 57
for a redundant OpenScape Voice.
3.3.6.1 Connecting the Cables for a Single-Node IBM x3650T

Connect the cables as follows:
1. Attach the keyboard, mouse, and monitor cables to the server. Figure 2 on
page 58 shows the connector locations at the back of the x3650T.
Note: If the equipment for OpenScape Voice includes a KVM, connect cables
from the keyboard, mouse, and monitor connectors on the server to the KVM
and connect the keyboard, mouse and monitor cables to the appropriate
connectors on the KVM. If necessary, refer to the KVM documentation for
assistance.
2. Attach the Ethernet cables.
Note: Ensure that the Ethernet switch or switches are configured for VLAN
operation. Refer to the Ethernet switch manufacturers documentation for
instructions.
The Ethernet connections specified here assume that the standard Ethernet
device definitions in the node.cfg file were used. If the standard was not used,
the connections will be different from those listed here. The standard Ethernet
device definitions are as follows:
Ethernet device definitions
eth0_device_node1 through eth2_device_node1 are set to Ethernet

definition e1000.
Figure 1 on page 57 shows the Ethernet ports for a single-node OpenScape

Voice on an x3650T platform.
The block of 24 Ethernet ports on the Ethernet switches are designated as
follows:
The upper row of ports are odd numbers, 1 through 23, starting from the
left. For example, the first jack in the upper row of the Ethernet switch 0
is designated as switch0.1
A31003-H8050-J100-09-7631, 09/2011
55
recmd_hw.fm
The lower row of ports are even numbers, 2 through 24, starting from the
left. For example, the last jack in the lower row of the Ethernet switch 1 is
designated as switch1.24.
11
13
15
17
19
21
23
10
12
14
16
18
20
22
24
Whenever possible, cable the system as prescribed in Table 3 (for a single

LAN) or Table 4 on page 56 (for a redundant LAN) so that the wiring from one
single-node OpenScape Voice installation to another is uniform. Refer to
Figure 1 on page 57 and to the appropriate table to complete the Ethernet
connections.
Connections for a Single LAN Configuration
Connection
From
To
Administration
Port0
switch0.1
Signaling
Port1
switch0.2
Billing/CDR
Port2
switch0.3
IMM interconnection
IMM Ethernet port
switch0.4
Table 3
Ethernet Connections (IBM x3650T Single-Node, Single LAN)

Connections for a Redundant LAN Configuration
Connection
From
To
Administration
Port0
switch0.1
Signaling
Port1
switch1.1
Billing/CDR
Port2
switch1.2
IMM interconnection
IMM Ethernet port
switch1.3
Table 4
56
Ethernet Connections (IBM x3650T Single-Node, Redundant

LAN)
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Port2
Port0
Mouse
Keyboard
Figure 1
Port3
(not used)
Port1
Monitor
Power
IMM Ethernet Port
IBM x3650T Rear View for a Single-Node OpenScape Voice
3. Attach the power cords to the server and to the power receptacle.
step 6.
3.3.6.2 Connecting the Cables for a Redundant IBM x3650T

page 58 shows the connector locations at the back of the x3650T.
Repeat this step on the other node as applicable.
assistance.
Note: Ensure that the Ethernet switches are configured for VLAN operation
and the gigabit links are programmed. Refer to the manufacturers
For a geographically separated node configuration in the same IP subnet
A31003-H8050-J100-09-7631, 09/2011
57
recmd_hw.fm
where the nodes are connected via an L2 network, each nodes cluster
interconnect ports (2 and 4) must be in the same VLAN to ensure correct
bonding and creation of the cluster virtual IP addresses.
The Ethernet connections assume that the standard Ethernet device and
bonding driver definitions port mapping in the node.cfg file were used. If the
standard was not used, the connections will be different from those listed
here. The standard Ethernet device definitions and bonding driver definitions
port mapping are as follows:

definition e1000.

definition e1000.
Bonding driver definitions port mapping
Cluster interconnection (cluster_dev): Port2 and Port4
System administration (bonding_dev0): Port0 and Port6
Signaling (bonding_dev1): Port1 and Port5
Billing/CDR (bonding_dev2): Port3 and Port7
Figure 2 shows the Ethernet ports for the x3650T.

Port7
Port4
Mouse
Keyboard
Figure 2
Port6
Port0
Port2
Port3
Port1
Power
Port5
Monitor
IMM Ethernet
IBM x3650T Rear View for a Redundant OpenScape Voice

follows:
58
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
left. For example, the first jack in the upper row of Ethernet switch 0 is
designated as switch0.1
left. For example, the last jack in the lower row of Ethernet switch 1 is
11
13
15
17
19
21
23
10
12
14
16
18
20
22
24
Whenever possible, cable the system as prescribed in the following tables so

that the wiring from one OpenScape Voice installation to another is uniform.
Complete the Ethernet connections as follows;
Co-located node configuration

Use Figure 2 on page 58 and Table 5 on page 59 to make the Ethernet
connections.
Geographically separated node configuration

connections.
Different cabling is required for the geographically separated node
configuration because two Ethernet LAN switches are required at each
node location.
Connections for a Co-Located Node Configuration
Connection
From
To
Cluster interconnection (cluster_dev) using

direct connect CAT-5 null cable.
Node1 Port2
Node2 Port2
Node1 Port4
Node2 Port4
Bond0 interconnection (administration)
Node1 Port0
switch0.1
Node1 Port6
switch1.1
Node2 Port0
switch0.2
Node2 Port6
switch1.2
Node1 Port1
switch0.3
Node1 Port5
switch1.3
Node2 Port1
switch0.4
Node2 Port5
switch1.4
Bond1 interconnection (signaling)
Table 5
Ethernet Connections; IBM x3650T Co-Located Node

Configuration (Sheet 1 of 2)
A31003-H8050-J100-09-7631, 09/2011
59
recmd_hw.fm

Connection
From
To
Bond2 interconnection (billing/CDR)
Node1 Port3
switch0.5
Node1 Port7
switch1.5
Node2 Port3
switch0.6
Node2 Port7
switch1.6
Node1 IMM
Ethernet port
switch0.7
Node2 IMM
Ethernet port
switch1.7
IMM interconnection
Table 5
Ethernet Connections; IBM x3650T Co-Located Node

Configuration (Sheet 2 of 2)
The Ethernet LAN switch designations for a geographically separated

configuration are as follows:
Switch0 and Switch1 for the Node1 location.

Connections for a Geographically Separated Node Configuration
Connection
From
To
Node1 Port0
switch0.1
Node1 Port6
switch1.1
Node2 Port0
switch2.1
Node2 Port6
switch3.1
Node1 Port1
switch0.2
Node1 Port5
switch1.2
Node2 Port1
switch2.2
Node2 Port5
switch3.2
Node1 Port3
switch0.3
Node1 Port7
switch1.3
Node2 Port3
switch2.3
Node2 Port7
switch3.3
Node1 IMM
Ethernet port
switch0.4
Node2 IMM
Ethernet port
switch2.4
IMM interconnection
Table 6
60
Ethernet Connections; IBM x3650T Geographically Separated

Node Configuration (Sheet 1 of 2)
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm

Connection
From
To
Cluster interconnection (cluster_dev)
Node1 Port2
switch0.6
Node1 Port4
switch1.6
Node2 Port2
switch2.6
Node2 Port4
switch3.6
Table 6
Ethernet Connections; IBM x3650T Geographically Separated

3. Attach the links between the Ethernet switches as follows:

Co-located node configuration:
Attach two links (100BaseT) between switch 0 and switch 1.
Geographically separated node configuration with a layer 2 cluster
interconnect:
Node1 site
Attach one link (100BaseT) between switch 0 and switch 1.
Attach one link (100BaseT) between switch 0 and one layer 2 bridge.
Attach one link (100BaseT) between switch 1 and the other layer 2
bridge.
Node2 site
bridge.

interconnect:
The layer 3 IP cluster interconnect connection uses a proprietary transport
layer protocol, Internode Communication Facility (ICF), for communication. If
the cluster interconnect traffic passes through a firewall, the firewall might
block all this traffic. If this is the case, ensure that the customer has defined
custom rules in the firewalls to allow ICF traffic.
Node1 site
Attach one link (100BaseT) between switch 0 and one layer 3 router.
router.
A31003-H8050-J100-09-7631, 09/2011
61
recmd_hw.fm
Node2 site
router.
4. Attach the 2 power cords to the server and to the power receptacles. Repeat
this step for the other node.
step 6.
3.3.7 Modifying the IBM x3650T Server SCSI RAID

Configuration
Configure the SCSI RAID and create the disk mirror as follows:
1. Turn on the server. After a while the following screen is shown:
2. A number of screens will display system information until an LSI banner is

shown indicating that the LSI controller is Initializing.
62
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3. After initialization is complete, the system will display the following:
4. Press the Ctrl and C keys simultaneously. The LSI Logic MPT SCSI Setup
Utility screen is displayed.
5. On the LSI Logic MPT SCSI Setup Utility screen, press the down arrow key
to select the second controller (this is where the internal disks are attached).
A31003-H8050-J100-09-7631, 09/2011
63
recmd_hw.fm
6. Press Enter to scan the controller. After the scanning is complete, the setup
utility will display the Adapter Properties screen.
7. On the Adapter Properties screen, select <Device Properties> and press

Enter. The Device Properties screen is displayed.
There should be disk entries at SCSI IDs 0 and 1. Both entries should show
the following properties: Restore Defaults = <Defaults>, MT/Sec = [160], MB/
Sec = 320, Data Width = [16], and Scan ID = [Yes]. If anything is different,
contact your next level of support.
64
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
8. Press the Esc key to return to the Adapter Properties screen.

9. On the Adapter Properties screen, select <RAID Properties> and press
Enter.
A31003-H8050-J100-09-7631, 09/2011
65
recmd_hw.fm
The RAID Properties array configuration screen is displayed.
10. On the RAID Properties array configuration screen, ensure that the Array
Disk? entry for the first disk is selected and press the + (plus sign) key.
Note: If you do not see No in yellow for both disks (SCSI IDs 0 and 1) an
array is already configured. Contact your next level of support for assistance.
The setup utility will display the following:
F3 Keep Data (Create 2 disk array)
Delete Erase Disk (Create 2 to 6 disk array)
11. Press the F3 function key to keep the data that is already on the disk and
create a two-disk array.
The RAID Properties screen is displayed again. The first drive should now
show Yes in the Array Disk? field and Primary in the Status field.
66
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
12. On the RAID Properties screen, select the second drive and press the + (plus
sign) key. The setup utility will display the following:
WARNING: Data on drive will be LOST!
Press DELETE if data loss OK or any other key to cancel
This indicates that all the data on the second drive will be replaced with the
data from the primary drive.
13. Press the Del key to replace the data on the second drive.
The RAID Properties screen is displayed again. The second drive should now
show Yes in the Array Disk? field.
A31003-H8050-J100-09-7631, 09/2011
67
recmd_hw.fm
14. Press the Esc key to exit the RAID Properties screen. The setup utility will
display the following:
RAID Properties changed
<Cancel Exit>
Exit the Configuration Utility
<Save changes then exit this menu>
<Discard changes then exit this menu>
15. On the RAID Properties changed menu, select the <Save changes then exit
this menu> option and press Enter.
The setup utility will display a screen that indicates the disks are Resyncing.
Because this can take up to approximately 12 hours on a 146 GB disk it is
recommended that you exit the utility. When finished, the RAID Status will
change from Resyncing to Optimal indicating a good mirror.
16. Press Esc to return to the top level menu and then press Esc to exit the setup
utility. The setup utility will display the following:
68
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Are you sure you want to exit?

<Cancel Exit>
<Exit the Configuration Utility>
Save changes then exit this menu
Discard changes then exit this menu
17. On the exit menu, select the <Exit the Configuration Utility> option and
press Enter. The system will continue to boot. Each time the system is
restarted the resync will continue until the disks are fully in sync.
18. If you are installing an OpenScape voice server go to step 19.
If you arrived at this procedure while preparing a x3650T server for external
Applications Server installation return to Section 5.2.1.1, Installing SLES 10
with appropriate service pack onto the IBM x3650T, on page 309.
19. For a redundant system, repeat step 1 on page 62 through step 17 on page
69 on the other server. Otherwise, continue to the next step.
step 7.
3.3.8 Modifying the IBM x3650T Server BIOS Settings

Modify the x3650T BIOS settings as follows:
1. Reboot (either cycle the power or press the Ctrl-Alt-Del keys simultaneously)
the server.
2. At the IBM screen, press the F2 function key to run the BIOS Setup Utility.
The system displays a number of messages regarding system equipment.
After the messages are done the Main screen of the BIOS Setup Utility is
displayed.
A31003-H8050-J100-09-7631, 09/2011
69
recmd_hw.fm
3. Set the date and time. The column on the right-hand side of the Main screen
describes how to select and manipulate the date and time fields on the Main
screen.
4. Select the Exit screen. The column on the right-hand side of the Main screen
describes how to select the screens.
5. On the Exit screen, select the Load Setup Defaults item, press Enter, and
then select OK. The settings will be set to the default values.
70
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
6. Select the Advanced screen, select the Processor Configuration item, and
press Enter.
The Configure advanced CPU settings sub screen is displayed.
A31003-H8050-J100-09-7631, 09/2011
71
recmd_hw.fm
7. On the Configure advanced CPU settings sub screen, ensure that Processor
Retest is set to Enabled.
If it is not, select Processor Retest, press Enter, select Enabled in the
Options menu, and press Enter to enable Processor Retest.
8. Press Esc to exit the Configure advanced CPU settings sub screen.
9. Select the Boot screen, select the Boot Settings Configuration item, and
press Enter.
The Boot Setting Configuration sub screen displays.
72
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
10. On the Boot Setting Configuration sub screen, select the Quiet Boot item,
press Enter, select Disabled in the Options menu, and press enter to disable
Quiet Boot.
11. Press Esc to exit the Boot Setting Configuration sub screen and return to the
main Boot screen.
12. On the Boot screen, select the Boot Device Priority item, and press Enter.
A31003-H8050-J100-09-7631, 09/2011
73
recmd_hw.fm
The Boot Device Priority sub screen displays.
13. On the Boot Device Priority sub screen, select the EFI Boot Manager item,
press Enter, select Disabled in the Options menu, and press Enter to disable
the device.
74
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
14. On the Boot Device Priority sub screen, select the IntelTSD Syscn item,
press Enter, select PM-SONY CD-RW/DVD-ROM in the Options menu, and
press Enter to select this as the 1st Boot Device.
15. On the Boot Device Priority sub screen, select the IntelTSD Syscn item,
the device.
Note: If the 2nd Boot Device does not show [#228 ID00 LUN0 LSI] the RAID
mirror will not be available. Contact your next level of support.
16. On the Boot Device Priority sub screen, select the IBA GE Slot 0420 v item,
the device.
Repeat this step for the rest of the IBA GE Slot entries.
17. After you disable all the IBA GE Slot entries, ensure that the boot device
priority is as follows:
A31003-H8050-J100-09-7631, 09/2011
75
recmd_hw.fm
18. Press Esc to exit the Boot Device Priority sub screen.
19. Select the Exit screen, select the Save Changes and Exit item, press Enter,
and then select OK to save the configuration changes and exit setup.
At this point, the machine will reset.
20. If a power up error is displayed (they appear as a brief red message that
flashes in the output. An example is Processor 01: thermal trip
failure, refer to Section 3.3.9 on page 76. Otherwise, continue to the next
step.
21. For a redundant system, repeat steps 1 on page 69 through 20 on page 76
on the other server. Otherwise, continue to the next step.
step 8.
3.3.9 IBM x3650T Server Power Up Errors

If you see an error during power up, perform the following procedure:
1. Press the F2 function key to run the BIOS Setup utility.
2. Select the Advanced screen, select the Processor Configuration item, and
press Enter. The Configure advanced CPU settings sub screen is displayed.
3. On the Configure advanced CPU settings sub screen, select Processor
Retest, press Enter, select Enabled in the Options menu, and press Enter to
enable Processor Retest.
4. Press Esc to exit the Configure advanced CPU settings sub screen.
5. Select the Exit screen, select the Save Changes and Exit item, press Enter,
and then select OK to save the configuration changes and exit setup.
This will restart the system and retest the CPUs. After the restart, the system
automatically sets Processor Retest back to Disabled.
6. Return to step 21 on page 76.
3.3.10 Installing the Intel Server Management

Software
Install the ISM software onto the Microsoft machine where you want the console
redirection to take place as follows:
76
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
1. Insert the Intel Resource CD into the CD/DVD drive of the machine where the
console redirection is to take place. The Intel Server Management screen is
displayed with a Read Me First window.
2. On the left side of the Intel Server Management screen, click Install
Software. The Install Software window is displayed.
3. In the Install Software window, click <Launch Intel Server Manager 8.40
installation>. A File Download Security Warning dialog box is displayed.
Note: If you are asked about Active Content, click Yes.
A31003-H8050-J100-09-7631, 09/2011
77
recmd_hw.fm
4. In the File Download Security Warning dialog box, click Run. A Internet
Explorer Security Warning dialog box is displayed.
5. In the Internet Explorer Security Warning dialog box, click Run. The Intel
Server Manager Setup screen is displayed.
Note: If you are asked about installing JRE, click Yes.
6. On the left side of the Intel Server Manager Setup screen, click Start. The
License Agreement window is displayed.
7. In the License Agreement window, click Accept. The Local Computer Details
window is displayed.
8. In the Local Computer Details window, wait for the system report, and then
click Next. The Installation Method window is displayed.
9. In the Installation Method window, select the Custom Install option and click
Next.
78
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
The Custom Installation window is displayed.

10. In the Custom Installation window, scroll to the bottom of the window, select
the Advanced Remote Server Control option check box, and click Next.
A31003-H8050-J100-09-7631, 09/2011
79
recmd_hw.fm
The Multiple System Selection window is displayed.

11. In the Multiple System Selection window, type the <IP address> of the
machine you are loading the software onto in the System field, type
c:\Program Files\IntelCR in the Installation Path field, click Add, and
click Next.
80
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
The Confirmation window is displayed.

12. In the Confirmation window, click Install Now. The File Copy window is
displayed and will display a progress bar. After the files are copied, the
Installer Launch window is displayed.
13. If Hardware Installation dialog boxes are displayed with messages regarding
software that has not passed Windows Logo testing, click Continue Anyway
in the dialog box, or boxes, to continue. The System Shutdown window is
displayed.
14. In the System Shutdown window, click Reboot Now.
15. On the IBM x3650T Server Installation Checklist, initial step 9.
16. On the OpenScape Voice Installation Checklist, initial step 8 and proceed to
step 9.
A31003-H8050-J100-09-7631, 09/2011
81
recmd_hw.fm
Installing the FSC RX330 Server
3.4 Installing the FSC RX330 Server

3.4.1 How to use the FSC RX330 Server Installation
Checklist

responsible.
3.4.2 FSC RX330 Server Installation Checklist

Use the following checklist to monitor the installation of the FSC RX330 server.
Note: The FSC RX330 is shipped to the site fully assembled. Firmware is preloaded at the factory.
Item
Description
1.

page 83.
2.
Locate the FSC RX330 server printed documentation and digital

3.
Install the servers into the rack. Refer to Section 3.4.5 on page
84.
4.
Connect all cables.
Table 7
82
Initials
Single-node OpenScape Voice: Refer to Section 3.4.6.1 on

page 84.
Redundant OpenScape Voice: Refer to Section 3.4.6.2 on

page 86.
FSC RX330 Server Installation Checklist (Sheet 1 of 2)
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Item
Description
5.

page 92.
6.

99.
7.
Activate the remote system console. Refer to Section 3.4.9 on

page 103.
Table 7
Initials
FSC RX330 Server Installation Checklist (Sheet 2 of 2)
3.4.3 Inventorying and Inspecting the FSC RX330

5. On the FSC RX330 Server Installation Checklist, initial step 1 and proceed to
step 2.
3.4.4 Locating the FSC RX330 Server Printed

FSC RX330 server printed guides and digital media


On the FSC RX330 Server Installation Checklist, initial step 2 and proceed to step
3.
A31003-H8050-J100-09-7631, 09/2011
83
recmd_hw.fm
3.4.5 Installing the FSC RX330 Servers into the Rack

1. Refer to the FSC RX330 rack installation instructions to install the servers into
the rack.
step 4.
3.4.6 Connecting the Cables to the FSC RX330 Server

OpenScape Voice (single-node or redundant). Refer to Section 3.4.6.1 on page
84 for a single-node OpenScape Voice and to Section 3.4.6.2 on page 86 for a
redundant OpenScape Voice.
3.4.6.1 Connecting the Cables for a Single-Node FSC RX330

page 86 shows the connector locations at the back of the FSC RX330.
assistance.
instructions.
84
Ethernet device definitions: eth0_device_node1 through

eth3_device_node1 are set to Ethernet definition e1000.
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm

Voice on an FSC RX330 platform.
follows:
11
13
15
17
19
21
23
10
12
14
16
18
20
22
24
Whenever possible, cable the server as prescribed in Table 8 (for a single

LAN) or Table 9 on page 85 (for a redundant LAN) so that the wiring from one
single-node OpenScape Voice installation to another is uniform. Refer to
connections.
Connection
From
To
Administration
Port0
switch0.1
Signaling
Port2
switch0.2
Billing/CDR
Port3
switch0.3
iRMC interconnection
iRMC Ethernet port
switch0.4
Table 8
Ethernet Connections (FSC RX330 Single-Node Server, Single

LAN)
Connection
From
To
Administration
Port0
switch0.1
Signaling
Port2
switch1.1
Billing/CDR
Port3
switch1.2
iRMC Ethernet port
switch1.3
Table 9
Ethernet Connections (FSC RX330 Single-Node Server,

Redundant LAN)
A31003-H8050-J100-09-7631, 09/2011
85
recmd_hw.fm
Mouse
Keyboard
Figure 3
iRMC Ethernet Port
Monitor
Port1
(not used)
Port2
Port0
Port3
FSC RX330 Rear View for the Single-Node OpenScape Voice
step 5.
3.4.6.2 Connecting the Cables for a Redundant FSC RX330

page 88 shows the connector locations at the back of the FSC RX330.
assistance.
86
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm

definition e1000.
eth6_device_node1 and eth7_device_node1 are set to Ethernet

definition tg3.

definition e1000.
eth6_device_node2 and eth7_device_node2 are set to Ethernet

definition tg3.
Figure 4 shows the Ethernet ports for the FSC RX330.
A31003-H8050-J100-09-7631, 09/2011
87
recmd_hw.fm
Mouse
iRMC Ethernet Port
Monitor
Keyboard
Figure 4
Port7
Port6
Port1
Port2
Port5
Port3
Port0
Port4
FSC RX330 Rear View for a Redundant OpenScape Voice

follows:
11
13
15
17
19
21
23
10
12
14
16
18
20
22
24
Whenever possible, cable the server as prescribed in the following tables so


connections.

connections.
88
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm

node location.
Connection
From
To

Node1 Port1
Node2 Port1
Node1 Port5
Node2 Port5
Node1 Port0
switch0.1
Node1 Port4
switch1.1
Node2 Port0
switch0.2
Node2 Port4
switch1.2
Node1 Port2
switch0.3
Node1 Port6
switch1.3
Node2 Port2
switch0.4
Node2 Port6
switch1.4
Node1 Port3
switch0.5
Node1 Port7
switch1.5
Node2 Port3
switch0.6
Node2 Port7
switch1.6
Node1 iRMC
Ethernet port
switch0.7
Node2 iRMC
Ethernet port
switch1.7
Table 10
Ethernet Connections; FSC RX330 Co-Located Node

Configuration


Connection
From
To
Node1 Port0
switch0.1
Node1 Port4
switch1.1
Node2 Port0
switch2.1
Node2 Port4
switch3.1
Table 11
Ethernet Connections; FSC RX330 Geographically Separated

A31003-H8050-J100-09-7631, 09/2011
89
recmd_hw.fm

Connection
From
To
Node1 Port2
switch0.2
Node1 Port6
switch1.2
Node2 Port2
switch2.2
Node2 Port6
switch3.2
Node1 Port3
switch0.3
Node1 Port7
switch1.3
Node2 Port3
switch2.3
Node2 Port7
switch3.3
Node1 iRMC
Ethernet port
switch0.4
Node2 iRMC
Ethernet port
switch2.4
Node1 Port1
switch0.6
Node1 Port5
switch1.6
Node2 Port1
switch2.6
Node2 Port5
switch3.6
Table 11
Ethernet Connections; FSC RX330 Geographically Separated


interconnect:
Node1 site
bridge.
Node2 site
bridge.

interconnect:
90
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm

Node1 site
router.
Node2 site
router.
step 5.
A31003-H8050-J100-09-7631, 09/2011
91
recmd_hw.fm
3.4.7 Modifying the FSC RX330 RAID Configuration

Configure the internal LSI controller and create the disk mirror as follows:
1. Turn on the server. After a while the following screen is shown:
Then the LSI controller will begin initializing and after a few seconds of
initialization the following screen is displayed:
2. Press the Ctrl and C keys simultaneously to start the LSI Logic Configuration
Utility. The system will ask you to wait and after the utility is invoked, the
Adapter List Global Properties screen is displayed:
92
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3. Press Enter to select the internal controller (SAS1068). The Adapter

Properties screen is displayed:
4. Use the down arrow key to highlight RAID Properties and press Enter. The
following screen is displayed:
A31003-H8050-J100-09-7631, 09/2011
93
recmd_hw.fm
5. Ensure that Create IM Volume is highlighted and press Enter to create the
array. The following screen is displayed:
6. Use the right arrow key to select the RAID Disk in the Slot Num 0 row as
shown in the following screen:
94
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
7. Press the + (plus sign) key to select the drive to be placed into the array. The
following menu is displayed:
8. Press the D key to overwrite all existing data and create a new IM array. The
first drive is now selected as shown in the following screen:
Note: If the disks had been used previously, you may be asked to confirm this
action before you can continue.
A31003-H8050-J100-09-7631, 09/2011
95
recmd_hw.fm
9. Use the down arrow key to select the RAID Disk in the Slot Num 1 row as
shown in the following screen:
10. Press the + (plus sign) key to select the second drive to be placed into the
array and press the C key to create the array. You are then prompted to create
and save the new array in the next screen displayed.
11. Use the down arrow key to select the Save changes then exit this menu
option and press Enter.
96
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
The system will process the request:
After the request is processed, the Adapter Properties screen is displayed:
12. Press the Esc key to exit the Adapter Properties menu. The Adapter List
Global Properties screen is displayed.
13. Press the Esc key to exit the Adapter List Global Properties screen. The
A31003-H8050-J100-09-7631, 09/2011
97
recmd_hw.fm
14. Select the Exit the Configuration Utility and Reboot option and press Enter
to finish the RAID configuration. After the system reboots, you should see the
following display indicating that a single logical volume exists:
step 6.
98
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3.4.8 Modifying the FSC RX330 BIOS Settings

Modify the BIOS settings as follows:
the server.
2. When the following screen is displayed, press the F2 function key to run the
BIOS Setup Utility.
The Main screen of the BIOS Setup Utility is then displayed.

3. On the Main screen of the Setup Utility, set the date and time.
The banner at the bottom of the Main screen describes how to select and
change the values in the time and date fields on the Main screen. It also
describes how to select screens.
The right column of the Main screen provides item specific help.
A31003-H8050-J100-09-7631, 09/2011
99
recmd_hw.fm
4. Select the Advanced screen, select IPMI, and press Enter.
The IPMI sub screen is displayed.

5. On the IPMI sub screen, select Lan Settings, and press Enter.
100
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
The LAN Settings sub screen is displayed.

6. On the LAN Settings sub screen: Ensure that DHCP is set to Disabled and
that the LAN Port is set to separate (this forces the use of the maintenance
port). Type the IP address for the iRMC in the Local IP Address field and the
IP addresses for the Subnet Mask and Gateway Address in to the appropriate
fields.
7. Press Esc twice to return to the Advanced screen.

8. On the Advanced screen, select Power On/Off, and press Enter.
A31003-H8050-J100-09-7631, 09/2011
101
recmd_hw.fm
The Power On/Off sub screen is displayed.

9. On the Power On/Off sub screen, ensure that the values are the same as
those shown in this screen:
10. Press Esc to exit the Power On/Off sub screen.

11. Select the Boot screen and ensure that the CD/DVD drive has priority over
the logical disk drive as shown in this screen:
102
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
12. Select the Exit screen, select Save Changes & Exit, and press Enter.
13. In the Setup Confirmation dialog box, select Yes to confirm that you want to
exit. The system will reset.
step 7.
3.4.9 Remote Console Startup for the FSC RX330

Server
Note: If you cannot perform this procedure there may be a problem with the
iRMC. Contact your next level of support and refer to Section 3.4.10 on page 107.
Activate the remote system console from the iRMC as follows:

1. Start a web browser and type the IP address of the iRMC in the Address bar
and click Go.
Note: Use the iRMC IP address you specified in step 6 on page 101 of the
BIOS setup procedure.
2. If a Security Alert is displayed, click Yes to proceed.
A31003-H8050-J100-09-7631, 09/2011
103
recmd_hw.fm
3. When prompted, enter the User Name and Password. The default user name
is USERID and the password is PASSW0RD (zero, not the letter O).
4. If the system has not been entered since the power was applied you will see
the following screen:
Select Server Management. The Server Management Information screen

(the specific screen that is displayed depends on the last state of the iRMC)
is displayed.
5. On the Server Management Information screen, select Video Redirection
from the column on the left side of the screen.
104
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
If this is the first time anyone has logged in to the iRMC, the following screen
is displayed:
A31003-H8050-J100-09-7631, 09/2011
105
recmd_hw.fm
If it is not the initial log in, a similar display showing the previous users is
shown.
6. In either case, on the Advanced Video Redirection screen, click the Start
Video Redirection button.
7. If you get a warning regarding an invalid web site certificate, click Yes.
8. If you get a warning regarding a hostname mismatch, click Run.
The following screen is displayed while the Java script is started:
9. If you see the following messages, click OK.
10. After you are connected to the remote console the following screen is
displayed (note the Full Control in the title bar at the top of the screen):
106
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
11. To finish, select Exit from the Extras drop down menu, and click OK.
13. On the FSC RX330 Server Installation Checklist, initial step 7.
step 9.
3.4.10 Configuring the iRMC for the FSC RX330

Server
Note: The official process is that the iRMC is configured at the factory. Only
perform this procedure if you are having problems with the iRMC. Contact your
next level of support before continuing.
1. Insert the PRIMERGY ServerView Suite ServerStart, Disc 1 DVD into the
DVD drive of the FSC RX330.
Note: Ensure that the FSC RX330 DVD drive has been configured with boot
priority over the disk drive. Refer to Section 3.4.8, Modifying the FSC RX330
BIOS Settings, on page 99.
2. Reboot the FSC RX330 server.
3. The system will boot from the DVD and will display a Loading ServerStart32
message along with a status bar on the iRMC Advanced Video Redirection
screen.
The system will display a Fujitsu Siemens Computers splash screen and then
display the ServerStart - StartUp screen.
4. On the ServerStart - StartUp screen; select the language, the keyboard type,
the No status backup option, and click Continue.
A31003-H8050-J100-09-7631, 09/2011
107
recmd_hw.fm
ServerStart will begin initializing and after it is done the license agreement is
displayed.
5. Click Accept to accept the license and continue.
The Welcome to ServerStart screen displays various system information.
6. At the bottom on the Welcome to ServerStart screen, select Guided/Expert
Installation, and click Next.
108
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
7. On the next screen under Further Functions, click Tools. The Tools screen is
displayed.
8. On the Tools screen, click System Configuration Utilities. The System
Configuration Utilities screen is displayed.
9. On the System Configuration Utilities screen, click SCU (Server
Configuration Utility). The SCU Wizard is run and PRIMERGY RX330 S1
should appear in the drop-down window indicating that the FSC RX330
system has been detected.
10. In the System successfully detected dialog box, click OK to continue. The
Boot Watchdog screen is displayed.
11. On the Boot Watchdog screen, ensure that the Activate box is not checked
and click next>. The System Power On/Off screen is displayed.
12. On the System Power On/Off screen, ensure that no boxes are checked for
the power on/off times for any day and click next>. The Other Settings screen
is displayed.
13. On the Other Settings screen, leave the Fan test time as it is at 23:00 and
click next>. The UPS Integration screen is displayed.
14. No changes are needed to the UPS settings. On the UPS Integration screen,
click next>. The iRMC LAN Settings screen is displayed.
A31003-H8050-J100-09-7631, 09/2011
109
recmd_hw.fm
15. On the iRMC LAN Settings screen:
Type the IP addresses for the iRMC, Subnet Mask, and Default Gateway in
to the appropriate fields. These can be found in the RSA parameters section
of the node.cfg file for the server.
Ensure that the LAN Speed is set to Auto Negotiate, that the LAN Port is set
to Service LAN, that the VLAN Enabled box is not checked, and click
next>.
The iRMC Networking Ports screen is displayed.

16. On the iRMC Networking Ports screen, place a check in the Force HTTPS
box, ensure that the Telnet enabled box is not checked, and click next>.
The iRMC DNS Registration screen is displayed.
110
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
17. On the iRMC DNS Registration screen, ensure that the Register DHCP
address in DNS box is not checked, and click next>. The iRMC DNS Server
screen is displayed.
18. On the iRMS DNS Server screen, ensure that the DNS enabled and the
Obtain configuration from DHCP boxes are not checked, and click next>.
The iRMC EMail Alerting screen is displayed.
19. On the iRMC EMail Alerting screen, ensure that the Enable email alerting
box is not checked and click next>. The iRMC Email Format Settings screen
is displayed.
20. On the iRMC Email Format Settings screen, click next>. The iRMC SNMP
Alerting screen is displayed.
21. On the iRMC SNMP Alerting screen, click next>. The iRMC User
Management screen is displayed.
22. On the iRMC User Management screen, change the initial user name and
password values (admin for both). Select the admin user from the list and
then click Modify at the bottom of the screen.
The User Account Properties dialog box is displayed.

23. In the User Account Properties dialog box, type the default user name
(USERID) and the password (PASSW0RD [zero, not the letter O]) in the
appropriate fields.
Note: If these defaults are not used, a corresponding change will have to be
made to the /etc/opt/SMAW/SMAWhaext/sa_ipmi.cfg file of each node.
Ensure that the Account enabled box is checked, that LAN Access and
Serial Access are set to OEM, that all the boxes in the Privileges section are
checked, that the Enabled box in the Email Paging Settings section is not
checked, and then click OK to close the dialog box.
A31003-H8050-J100-09-7631, 09/2011
111
recmd_hw.fm
24. The current list of accounts is displayed, click next>. The iRMC Remote
Storage screen is displayed.
25. On the iRMC Remote Storage screen, if the license key needs to be entered
you will find the license key on the product paraphernalia labelled as follows:
iRMC advanced pack
integrated remote management controller activation key for graphical
redirection and remote media redirection.
This should have been done at the factory: if the License Key field is
populated, click save all. Otherwise, type the license key and click save all.
26. The utility displays a progress bar and asks you to wait while it saves the
setting. After the settings are saved, click the leave wizard button.
27. Click the red X icon in the toolbar to exit the System Configuration Utilities.
112
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Installing the IBM x3250 M2 and M3 Servers
28. Click Yes to confirm that you want to exit. The following screen is displayed.
29. Remove the DVD and click OK. This completes the iRMC configuration, the
server will reboot.
30. If necessary, repeat this procedure on the other server.
3.5 Installing the IBM x3250 M2 and M3 Servers

Installation of the low cost OpenScape Voice Entry simplex system or the
OpenScape Branch system is supported on the IBM x3250 M2 and
IBM x3250 M3 server.
3.5.1 How to use the IBM x3250 Server Installation

Checklist

responsible.
A31003-H8050-J100-09-7631, 09/2011
113
recmd_hw.fm
3.5.2 IBM x3250 Server Installation Checklist

Use the following checklist to monitor the installation of the IBM x3250 M2
server.
Note: The IBM x3250 M2 is shipped to the site fully assembled. Firmware is preloaded at the factory. The x3250 servers will be configured with a single hard disk.
As a result, no RAID configuration is necessary.
Item
Description
Initials
1.
Inventory and inspect the hardware. Refer to Section 3.5.3 on page

114.
2.
Locate the IBM x3250 server printed documentation and digital media.
Refer to Section 3.5.4 on page 115.
3.
Install the server into the rack. Refer to Section 3.5.5 on page 115.
4.
Connect all cables. Refer to Section 3.5.6 on page 115.
5.
Modify the server BIOS settings:

For the x3250 M2 Server refer to Section 3.5.7 on page 117.
In IBMs latest servers the traditional BIOS has been replaced with
a new Unified Extensible Firmware Interface, or UEFI.
The x3250 M3 employs the UEFI. For the x3250 M3 UEFI settings
refer to Section 3.5.8 on page 123.
Note: If you are installing an x3250 M2 server you have

completed the IBM x3250 Server Installation Checklist after
step 5. Return to the OpenScape Voice Installation Checklist
step 9.
6.
For the x3250 M3 server only; Activate the remote system console,
refer to Section 3.5.9, IMM and Remote Console Access.
Note: If you are installing an x3250 M3 server you have

completed the IBM x3250 Server Installation Checklist after
step 6. Return to the OpenScape Voice Installation Checklist
step 9.
Table 12
IBM x3250 Server Installation Checklist

114
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm

5. On the IBM x3250 Server Installation Checklist, initial step 1 and proceed to
step 2.
3.5.4 Locating the IBM x3250 Server Printed

IBM x3250 server printed guides and digital media


On the IBM x3250 Server Installation Checklist, initial step 2 and proceed to step
3.
3.5.5 Installing the IBM x3250 Server into the Rack

Install the server into the rack as follows:
1. Refer to the IBM x3250 rack installation instructions to install the servers into
the rack.
step 4.
3.5.6 Connecting the Cables to the IBM x3250 Server

Connect cables as follows:
A31003-H8050-J100-09-7631, 09/2011
115
recmd_hw.fm
1. Attach the keyboard, mouse (the IBM x3250 server requires a USB keyboard
and mouse: a PS/2 to USB adaptor can be used in most cases), and monitor
cables to the server.
Figure 5 on page 117 shows the connector locations at the back of the
IBM x3250 M2.
Figure 6 on page 117 shows the connector locations at the back of the
IBM x3250 M3.
Note: If the equipment for the server includes a KVM, connect cables from
the keyboard, mouse, and monitor connectors on the server to the KVM and
connect the keyboard, mouse and monitor cables to the appropriate
assistance.
instructions.
a) Attach an Ethernet cable to the LAN switch for the local LAN and to the
Ethernet 1 connector (eth0).
b) For OpenScape Voice and OpenScape Branch configured as SBC:
Attach an Ethernet cable to the LAN switch or router for the external WAN
and to the Ethernet 2 connector (eth1). This Ethernet 2 cabling is not
necessary for an OpenScape Voice system in which the SBC function is
not configured or for an OpenScape Branch system configured as Proxy.
Note: For the x3250 M2; The Systems-management connector is not
used.
116
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Figure 5
IBM x3250 M2 Rear View
Figure 6
IBM x3250 M3 Rear View
3. Attach the power cord to the server and to the power receptacle.
step 5.
3.5.7 Modifying the IBM x3250 M2 Server BIOS

Settings
1. Turn on the server.
Configuration/Setup Utility.
A31003-H8050-J100-09-7631, 09/2011
117
recmd_hw.fm
The main menu of the Configuration/Setup Utility is displayed:
Refer to the banner at the bottom of this screen and subsequent screens for
instructions on how to navigate and manipulate screen data.
3. From the main menu of the Configuration/Setup Utility, select Date and Time
and press Enter.
118
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
4. In the Date and Time screen, ensure that the date and time is correct, and
then press the Esc key to return to the main menu of the Configuration/Setup
Utility.
5. From the main menu of the Configuration/Setup Utility, select Devices and
I/O Ports and press Enter.
A31003-H8050-J100-09-7631, 09/2011
119
recmd_hw.fm
6. In the Devices and I/O Ports screen, ensure that the parameter values are as
follows:
Press the Esc key to return to the main menu of the Configuration/Setup
Utility.
7. From the main screen of the Configuration/Setup Utility, select Start Options
and press Enter. The Start Options screen is displayed:
120
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
8. From the Start Options screen, select Startup Sequence Options and press
Enter.
In the Startup Sequence Options screen, ensure that the boot sequence is
similar to the following:
The DVD should be first and the HDD second (optionally, the start up devices
can be set to None beginning with the Third Startup Device and the Wake on
LAN Startup Sequence can be Disabled).
Press the Esc key to return to the main menu of the Configuration/Setup
Utility.
9. From the main menu of the Configuration/Setup Utility, select Exit Setup and
press Enter. The Exit Setup screen is displayed.
A31003-H8050-J100-09-7631, 09/2011
121
recmd_hw.fm
10. In the Exit Setup screen, select Yes, save and exit the Setup Utility, and
press Enter to confirm that you want to exit.
The system will reset.
11. On the IBM x3250 Server Installation Checklist, initial step 5.
12. Proceed as follows:
If you are installing OpenScape Voice: On the OpenScape Voice

Installation Checklist, initial step 8 and proceed to step 9.
If you are installing OpenScape Branch: On the OpenScape Branch

Installation Checklist in OpenScape Branch V1 R3 Service Manual
Volume 1, Installation and Upgrades, part number A31003-H8113-J100X-7631, initial step 3 and proceed to step 4.
Note: The IBM x3250 M2 is not equipped with an RSA card and therefore the
remote console feature is not available.
122
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3.5.8 Modifying the IBM x3250 M3 Server UEFI

Settings
1. UEFI (Setup)
In IBMs latest servers the traditional BIOS has been replaced with a new
Unified Extensible Firmware Interface, or UEFI. The following is the UEFI
setup. During the boot process the following screen will appear. At this point,
type the F1 key to enter UEFI Setup.
A31003-H8050-J100-09-7631, 09/2011
123
recmd_hw.fm
2. The main UEFI screen (main menu) will come up, allowing you to make
necessary modifications:
Use the down arrow key to select the Date and Time item and Enter key to
select the tab. Modify/correct the date and time as needed, then press the
Esc key to get back to the main menu.
124
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3. Next from the main menu, choose Boot Manager. Arrow up or down if
necessary to the Change Boot Order and press Enter key:
4. If necessary, modify the Boot order to match as follows:
Note: Floppy Disk and PXE Network options can be removed from the Boot
order if desired.
A31003-H8050-J100-09-7631, 09/2011
125
recmd_hw.fm
Select Commit Changes and follow any prompts to save the boot order.
When finished, back out to the main menu using the Esc key.
5. Once back in the main menu, select System Settings which takes you to the
following screen:
6. Arrow down to the Integrated Management Module and press the enter
key. This will take you to the Integrated Management Module screen:
126
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
7. Press the down arrow to Reboot System on NMI and press enter. Change the
value from Enable to Disable:
A31003-H8050-J100-09-7631, 09/2011
127
recmd_hw.fm
8. Next, arrow down to Network Configuration, and press Enter.

At this time, the IP, and network settings for the IMM will have to be set. Arrow
down and change DHCP Control, IP Address, Subnet Mask and Default
Gateway to relevant values (Note it is highly recommended to use a static IP
if at all possible). An example is as follows:
128
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
9. Once the network parameters are correctly configured for the IMM, arrow
down to Save Network Settings and press enter.
(Make note of the IP address, as it is needed to remotely access the IMM and
its functions.)
10. A confirmation should come up, after which press Enter to continue.
11. Once again press Esc to back up to the Main Menu.
A31003-H8050-J100-09-7631, 09/2011
129
recmd_hw.fm
12. At this point all changes should have been made (all other settings should
take the default values). At this time the changes can be saved and the UEFI
exited. At the main menu choose Save Settings:
13. Next choose Exit Setup which should result in the following confirmation
window:
14. Finally choose Y to exit the Setup utility and boot the system.
step 6.
130
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3.5.9 IMM and Remote Console Access

Note: If you cannot perform this procedure there may be a problem with the IMM.
Contact your next level of support and refer to Section 3.5.8, Modifying the IBM
x3250 M3 Server UEFI Settings, on page 123.
Note: Currently the IMM functionality is only available with the x3250 M3 server
configured in a flat network. Address any questions to your next level of support.
Ensure the following prerequisites are met before attempting this procedure:
Attention: When using Microsoft Internet Explorer (IE) 7 or 8 with an Integrated
Management Module (IMM), IE advanced security settings will block the Java
application from starting. IBM has developed workarounds to resolve this issue.
The title of the IBM document is IMM remote control does not start - IBM System
x. Refer to the following URL (at the IBM support site) for access to these
workarounds;
http://www-947.ibm.com/support/entry/portal/
docdisplay?brand=5000008&lndocid=MIGR-5083262
The IMM has been configured. The IMM settings are configured automatically
during image installation using the RSA parameters in the node.cfg. If you
cannot successfully complete this procedure there may be a problem with the
IMM configuration. Contact your next level of support and refer to Section
3.5.10 on page 138 if necessary.
The Java 1.5 Plug-in or later is installed on the client server. Observe the
following recommendations:
That HTTP access be restricted and that secure HTTPS access be enabled.
Please refer to the IMM Users Guide for details on how to change IMM Web
access.
That telnet be disabled. The IMM Users Guide provides instructions to

disable telnet access.
A31003-H8050-J100-09-7631, 09/2011
131
recmd_hw.fm
Startup the remote console as follows:

1. The IMM interface is accessible via web browser (see IBM website for full list
of compatible browsers). Open a web browser window and in the address
window enter the IP address or hostname of the IMM server to which you
want to connect (as entered in the UEFI in the section above).
2. On the Integrated Management Module Login page, type your userid/

password pair in the IMM Login window and click Login. If you are using the
IMM for the first time and have not changed the userid/password (Section
4.4.2, Changing the User ID and Password for the IMM/iRMC Account, on
page 284), the default userid/password of USERID/PASSW0RD should be
used (note PASSW0RD uses the number zero and not the letter O). All login
attempts are documented in the event log.
132
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3. On the Welcome Web page, select a timeout value from the drop-down list in
the field that is provided. If your browser is inactive for that number of minutes,
the IMM logs you off the Web interface. Depending on how your system
administrator configured the global login settings, the timeout value might be
a fixed value.
Set the Inactive Session timeout value (if desired) and click Continue. The
browser opens the System Status page
A31003-H8050-J100-09-7631, 09/2011
133
recmd_hw.fm
4. The System Status page provides a quick view of the server status and the
server health summary:
From the Main Control panel, the System Status, Alarms, System Settings,
Events, and other diagnostic information can be accessed.
134
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
5. To activate Remote Control; under Tasks in the navigation panel on the left
side of the screen click Remote Control. This will bring up the following
window:
Note: The x3250 M3 server is equipped with a Virtual Media Key (VMK). This
key enables remote presence support (remote video, remote keyboard/
mouse, and remote storage) in addition to the standard IMM functionality
(service processor control and monitoring functions, system summary,
system status).
Note: If you cannot perform this procedure there may be a problem with the
IMM. Contact your next level of support and refer to Section 3.5.10,
Configuring the IMM for the IBM x3250 M3 Server, on page 138.
A31003-H8050-J100-09-7631, 09/2011
135
recmd_hw.fm
From this window the current remote control session status can be read (if
other remote consoles are running). To begin a Console session, click on
either the Start Remote Control in Single User Mode or Start Remote
Console in Multi-User Mode.
Note: Single User mode will block users from accessing the console
simultaneously.
Attention: Please observe the Note: regarding the Java Runtime

Environment and Java Plug-in from the previous screenshot. The correct
JRE and Plug-in are required for remote access. If the step below does not
work, it may be necessary to install a new JRE and/or Plug-in to enable the
remote console.)
6. The following two windows will now appear, allowing remote access:
136
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
7. Click in the Video Viewer window in order to enter commands on the console.
Once finished, make sure to gracefully shut down both windows. Also make
sure to log off IMM interface before closing IMM browser window.
8. On the IBM x3250 Server Installation Checklist, initial step 6.
9. Proceed as follows:
If you are installing OpenScape Voice: On the OpenScape Voice

Installation Checklist, initial step 8 and proceed to step 9.
If you are installing OpenScape Branch: On the OpenScape Branch

Installation Checklist in OpenScape Branch V1 R3 Service Manual
Volume 1, Installation and Upgrades, part number A31003-H8113-J100X-7631, initial step 3 and proceed to step 4.
A31003-H8050-J100-09-7631, 09/2011
137
recmd_hw.fm
3.5.10 Configuring the IMM for the IBM x3250 M3

Server
Note: Currently the IMM functionality is only available with the x3250 M3 server
configured in a flat network. Address any questions to your next level of
support.
Note: The IMM settings are configured automatically during image installation
using the RSA parameters in the node.cfg. Only perform this procedure if you are
having problems with the remote console startup Section 3.5.9, IMM and
Remote Console Access, on page 131. Contact your next level of support
before continuing.
1. Review Section 3.5.8, Modifying the IBM x3250 M3 Server UEFI Settings
to ensure the UEFI settings are correct.
Attention: This procedure entails powering down the server to verify the
VMK is installed properly. Please contact your next level of support before
proceeding. The OpenScape voice server must be properly shutdown
before the server is powered off.
2. This procedure entails powering down the server to verify the VMK is installed
properly. The x3250 M3 server is equipped with a Virtual Media Key (VMK).
This key enables remote presence support (remote video, remote keyboard/
mouse, and remote storage) in addition to the standard IMM functionality
(service processor control and monitoring functions, system summary,
system status, etc.) The VMK is pictured below;
138
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3. In order to verify the VMK installation, first power off the server and unplug the
power cable (to disconnect power). Remove the top cover by pressing the 2
blue tabs (shown below) and sliding the cover towards the back of the server
until it unhinges.
Remove the top and place it aside.
A31003-H8050-J100-09-7631, 09/2011
139
recmd_hw.fm
4. With the cover off, the VMK connector will be located towards the back right
of the machine as shown below (yellow circle):
140
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
5. The following image shows a close-up of the VMK connector location:
6. Install the VMK by plugging it into the pins shown above. After the VMK is
installed it should appear as follows (reverse angle from previous picture to
show how clip is seeded in VMK):
A31003-H8050-J100-09-7631, 09/2011
141
recmd_hw.fm
3.6 Installing the IBM x3550 M2 and M3 Servers

3.6.1 How to use the IBM x3550 M2/M3 Server
Installation Checklist

responsible.
3.6.2 IBM x3550 M2/M3 Server Installation Checklist

Use the following checklist to monitor the installation of the IBM x3550 M2/M3
server.
Note: The IBM x3550 M2/M3 is shipped to the site fully assembled. Firmware is
pre-loaded at the factory.
Item
Description
1.

page 143.
2.
Locate the IBM x3550 M2/M3 server printed documentation and

digital media. Refer to Section 3.6.4 on page 143.
3.
144.
Table 13
142
Initials
IBM x3550 M2/M3 Server Installation Checklist (Sheet 1 of 2)
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Item
Description
Initials
4.
Connect all cables.

page 144.
Redundant OpenScape Voice: Refer to Section 3.6.6.2 on

page 146.
5.

page 151.
6.

157.
7.
Activate the remote system console: Refer to Section 3.6.10 on

page 168.
Table 13
IBM x3550 M2/M3 Server Installation Checklist (Sheet 2 of 2)

M2/M3 Server Installation Materials
5. On the IBM x3550 M2/M3 Server Installation Checklist, initial step 1 and
proceed to step 2.
3.6.4 Locating the IBM x3550 M2/M3 Server Printed

IBM x3550 M2/M3 server printed guides and digital media

A31003-H8050-J100-09-7631, 09/2011
143
recmd_hw.fm

On the IBM x3550 M2/M3 Server Installation Checklist, initial step 2 and proceed
to step 3.
3.6.5 Installing the IBM x3550 M2/M3 Servers into the

Rack
1. Refer to the IBM x3550 M2/M3 rack installation instructions to install the
servers into the rack.
proceed to step 4.
3.6.6 Connecting the Cables to the IBM x3550 M2/M3

Server
144 for a single-node OpenScape Voice and to Section 3.6.6.2 on page 146 for
a redundant OpenScape Voice.
3.6.6.1 Connecting the Cables for a Single-Node IBM x3550

M2/M3
1. Attach the keyboard, mouse (the IBM x3550 M2/M3 requires a USB keyboard
cables to the server. Figure 7 on page 146 shows the connector locations at
the back of the IBM x3550 M2/M3.
assistance.
144
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm

instructions.
Ethernet device definitions: eth0_device_node1 through

eth3_device_node1 are set to Ethernet definition bnx2.
Voice on an IBM x3550 M2/M3 platform.
follows:
11
13
15
17
19
21
23
10
12
14
16
18
20
22
24

LAN) or Table 15 on page 146 (for a redundant LAN) so that the wiring from
one single-node OpenScape Voice installation to another is uniform. Refer to
connections.
Connection
From
To
Administration
Port0
switch0.1
Signaling
Port1
switch0.2
Billing/CDR
Port2
switch0.3
IMM interconnection
IMM Ethernet port
switch0.4
Table 14
Ethernet Connections (IBM x3550 M2/M3 Single-Node

Server, Single LAN)
A31003-H8050-J100-09-7631, 09/2011
145
recmd_hw.fm

Connection
From
To
Administration
Port0
switch0.1
Signaling
Port1
switch1.1
Billing/CDR
Port2
switch1.2
IMM interconnection
IMM Ethernet port
switch1.3
Table 15
Port2
IMM Ethernet Port

Figure 7
Ethernet Connections (IBM x3550 M2/M3 Single-Node

Server, Redundant LAN)
Not used on Simplex
Port0 Port1
Port3 (not used)
Monitor
USB Ports for

Mouse/Keyboard
IBM x3550 M2/M3 Rear View for the Single-Node OpenScape Voice
proceed to step 5.
3.6.6.2 Connecting the Cables for a Redundant IBM x3550

M2/M3
146
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
1. Attach the keyboard, mouse (the IBM x3550 M2/M3 requires a USB keyboard
the back of the IBM x3550 M2/M3.
assistance.
eth0_device_node1 through eth3_device_node1 and

definition bnx2.

definition e1000.
A31003-H8050-J100-09-7631, 09/2011
147
recmd_hw.fm
Figure 8 shows the Ethernet ports for the IBM x3550 M2/M3.
Port0 Port1
Port2 Port3
Port7
Port5
Port4
USB Ports for

Mouse/Keyboard
Monitor
IMM Ethernet Port

Figure 8
Port6
IBM x3550 M2/M3 Rear View for a Redundant OpenScape Voice

follows:
11
13
15
17
19
21
23
10
12
14
16
18
20
22
24


connections.

connections.
148
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm

node location.
Connection
From
To

Node1 Port3
Node2 Port3
Node1 Port7
Node2 Port7
Node1 Port0
switch0.1
Node1 Port4
switch1.1
Node2 Port0
switch0.2
Node2 Port4
switch1.2
Node1 Port1
switch0.3
Node1 Port5
switch1.3
Node2 Port1
switch0.4
Node2 Port5
switch1.4
Node1 Port2
switch0.5
Node1 Port6
switch1.5
Node2 Port2
switch0.6
Node2 Port6
switch1.6
Node1 IMM
Ethernet port
switch0.7
Node2 IMM
Ethernet port
switch1.7
IMM interconnection
Table 16
Ethernet Connections; IBM x3550 M2/M3 Co-Located Node

Configuration


Connection
From
To
Node1 Port0
switch0.1
Node1 Port4
switch1.1
Node2 Port0
switch2.1
Node2 Port4
switch3.1
Table 17
Ethernet Connections; IBM x3550 M2/M3 Geographically

Separated Node Configuration (Sheet 1 of 2)
A31003-H8050-J100-09-7631, 09/2011
149
recmd_hw.fm

Connection
From
To
Node1 Port1
switch0.2
Node1 Port5
switch1.2
Node2 Port1
switch2.2
Node2 Port5
switch3.2
Node1 Port2
switch0.3
Node1 Port6
switch1.3
Node2 Port2
switch2.3
Node2 Port6
switch3.3
Node1 IMM
Ethernet port
switch0.4
Node2 IMM
Ethernet port
switch2.4
Node1 Port3
switch0.6
Node1 Port7
switch1.6
Node2 Port3
switch2.6
Node2 Port7
switch3.6
IMM interconnection
Table 17
Ethernet Connections; IBM x3550 M2/M3 Geographically

Separated Node Configuration (Sheet 2 of 2)

interconnect:
150
Node1 site
Attach one link (100BaseT or 1000BaseT) between switch 0 and

switch 1.
Attach one link (100BaseT or 1000BaseT) between switch 0 and one

layer 2 bridge.
Attach one link (100BaseT or 1000BaseT) between switch 1 and the

other layer 2 bridge.
Node2 site

switch 3.

layer 2 bridge.
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm


interconnect:
Node1 site

switch 1.

layer 3 router.

other layer 3 router.
Node2 site

switch 3.

layer 3 router.

proceed to step 5.
3.6.7 Modifying the IBM x3550 M2/M3 RAID

Configuration
1. Turn on the server.
2. When the following screen is displayed (it may take up to four minutes), press
the F1 key to run the Setup program.
A31003-H8050-J100-09-7631, 09/2011
151
recmd_hw.fm
The System Configuration and Boot Management screen is displayed:
Refer to the banner at the bottom of the Setup screens for information on how
to navigate the Setup program screens and manipulate the data on the
various Setup screens.
152
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Some of the Setup screens display screen specific help in the right column of
the screen.
3. On the System Configuration and Boot Management screen, select System
Settings. The System Settings screen is displayed (the screenshot below
may differ slightly for the IBM x3550 M2 server):
A31003-H8050-J100-09-7631, 09/2011
153
recmd_hw.fm
4. On the System Settings screen, select Adapters and UEFI Drivers. The
Adapters and UEFI Drivers screen is displayed (the screenshot below may
differ slightly for the IBM x3550 M2 server):
5. Press Enter to refresh the page and compile the list of drivers. The list of
adapters is displayed. As indicated in the following screenshot, scroll down to
and highlight the LSI Logic Fusion MPT SAS Driver. Now press Enter:
154
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
6. Scroll down to the LSI adapter and press Enter. The Adapter Properties
screen is displayed (the screenshot below may differ slightly for the IBM
x3550 M2 server):
7. On the Adapter Properties screen, select RAID Properties. The Select New
Array Type screen is displayed:
8. On the Select New Array Type screen, select Create IM Volume. The Create
New Array screen is displayed:
A31003-H8050-J100-09-7631, 09/2011
155
recmd_hw.fm
9. On the Create New Array screen, use the arrow keys to select the first drive
in the pair and use the + (plus) or - (minus) key to change RAID Disk to Yes
and Drive Status to Primary. Continue to select the next drive in the pair using
the + (plus) or - (minus) key so that the drive settings are similar to the
following screen:
156
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
10. Press C to create the array. The mirroring takes a while; however there is no
need to wait as the mirroring will continue in the background.
11. Select Apply changes and exit menu to create the array.
12. Press Esc until you are out of the LSI Adapter Setting screens and back to
the System Configuration and Boot Management screen. Save any
configurations when prompted.
proceed to step 6.
3.6.8 Modifying the IBM x3550 M2/M3 BIOS Settings

1. If you are not currently in the Setup program, reboot (either cycle the power
or press the Ctrl-Alt-Del keys simultaneously) the server and press F1 at the
screen prompt to run the Setup program. The System Configuration and Boot
Management screen is displayed:
A31003-H8050-J100-09-7631, 09/2011
157
recmd_hw.fm
the screen.
2. On the System Configuration and Boot Management screen, select Date and
Time. The Date and Time screen is displayed:
3. Ensure that the date and time settings are correct; change them as
necessary. Press Esc to return to the System Configuration and Boot
Management screen.
Information. The System Information screen is displayed.
158
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
5. On the System Information screen, select Product Data. The Product Data
For the IBM x3550 M2 server, verify that the version levels of the Host
Firmware, IMM, and Diagnostics are at least to the levels listed in the Product
Data screen shown below:
For the IBM x3550 M3 server, verify that the version levels of the Host
Firmware, IMM, and Diagnostics are at least to the levels listed in the Product
Data screen shown below:
A31003-H8050-J100-09-7631, 09/2011
159
recmd_hw.fm
6. Press Esc to return to the System Configuration and Boot Management

screen.
7. On the System Configuration and Boot Management screen, select Boot
Manager. The Boot Manager screen is displayed:
8. On the Boot Manager screen, select Change Boot Order. The Change Boot
Order screen is displayed.
160
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
9. On the Change Boot Order screen, change the order to match the order in
this screen:
10. Select Confirm Changes. Press the Esc key twice to get back to the System
Configuration and Boot Management Screen.
11. If you are setting up the BIOS of the IBM x3550 M2 server, proceed to step 15.
If you are setting up the BIOS of the IBM x3550 M3, proceed to the next step
to disable the processors hyper-threading capability.
Attention: Steps 12 through 14 are only applicable to the IBM x3550 M3
server.
A31003-H8050-J100-09-7631, 09/2011
161
recmd_hw.fm
Settings. The System Settings screen is displayed:
13. On the System Settings screen, select Processors. The Processors screen
is displayed:
162
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
14. On the Processors screen, use the arrow keys to move down to HyperThreading. Set Hyper-Threading to Disable.
Press the Esc key twice to get back to the System Configuration and Boot
Management Screen.
15. Press the Esc key to exit the Setup program.
16. For a redundant system, repeat step 1 on page 157 through 15 on page 163
on the other server. Otherwise, continue to the next step.
17. On the IBM x3550 M2/M3 Server Installation Checklist, initial step 6.
step 9.
A31003-H8050-J100-09-7631, 09/2011
163
recmd_hw.fm
3.6.9 Configuring the IMM for the IBM x3550 M2/M3

Server
Note: The IMM settings are configured automatically during image installation
using the RSA parameters in the node.cfg. Only perform this procedure if you are
having problems with the remote console startup Section 3.6.10 on page 168
Contact your next level of support before continuing.
Configure the IMM settings using the Setup program as follows:

the server and press F1 at the screen prompt to run the Setup program. The
System Configuration and Boot Management screen is displayed:
the screen.
Settings. The System Settings screen is displayed (the screenshot below
may differ slightly for the IBM x3550 M2 server):
164
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3. On the System Settings screen, select Integrated Management Module.

The Integrated Management Module screen is displayed:
4. On the Integrated Management Module screen, select Network

Configuration. The Network Configuration screen is displayed:
A31003-H8050-J100-09-7631, 09/2011
165
recmd_hw.fm
5. On the Network Configuration screen, do the following:
Set Hostname to the relevant value
Set DHCP Control to Static IP
Specify the IP addresses in the IP Address, Subnet Mask, and Default

Gateway fields appropriate for your network configuration.
Select Save Network Settings and press Enter.
6. Press the Esc key a number of times until you are back at the System
Configuration and Boot Management screen.
7. On the System Configuration and Boot Management screen, select Exit
Setup and press Enter.
166
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
8. At the following prompt, type Y to exit the Setup program and boot the system:
9. For a redundant system, repeat this procedure on the other server.
A31003-H8050-J100-09-7631, 09/2011
167
recmd_hw.fm
3.6.10 Remote Console Startup

Note: If you cannot perform this procedure there may be a problem with the IMM.
Contact your next level of support and refer to Section 3.6.9, Configuring the
IMM for the IBM x3550 M2/M3 Server, on page 164.
Ensure the following prerequisites are met before attempting this procedure:
The IMM has been configured. The IMM settings are configured automatically
during image installation using the RSA parameters in the node.cfg. If you
cannot successfully complete this procedure there may be a problem with the
IMM configuration. Contact your next level of support and refer to Section
3.6.9 on page 164 if necessary.
For the IBM x3550 M2 server, Java 1.5 Plug-in or later is installed on the client
server.
For the IBM x3550 M3 server, Java 1.6 Plug-in or later is installed on the client
server.
Observe the following recommendations:
That HTTP access be restricted and that secure HTTPS access be enabled.
Please refer to the IMM Users Guide for details on how to change IMM Web
access.
That telnet be disabled. The IMM Users Guide provides instructions to

disable telnet access.
Startup the remote console as follows:

1. Open a Web browser and type the IP address or hostname of the IMM server
to which you want to connect in the address field.
The Integrated Management Module Login page will be displayed.
2. On the Integrated Management Module Login page, type your user name/
password pair in the IMM Login window and click Login. If you are using the
IMM for the first time and have not changed the userid/password (Section
4.4.2, Changing the User ID and Password for the IMM/iRMC Account, on
page 284), the default USERID/PASSW0RD (note PASSW0RD uses the
number zero and not the letter O) should be used. All login attempts are
documented in the event log.
3. On the Welcome Web page, select a timeout value from the drop-down list in
the field that is provided. If your browser is inactive for that number of minutes,
the IMM logs you off the Web interface. Depending on how your system
administrator configured the global login settings, the timeout value might be
a fixed value.
168
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
4. Click Continue to start the session. The browser opens the System Status
page, which gives you a quick view of the server status and the server health
summary:
5. Next run remote control. In the navigation panel on the left side of the screen,
click Remote Control. A page similar to the following is displayed:
A31003-H8050-J100-09-7631, 09/2011
169
recmd_hw.fm
6. To control the server remotely, use one of the links at the bottom of the
Remote Control page.
If you want exclusive remote access during your session, click Start
Remote Control in Single User Mode.
If you want to allow other users remote console (KVM) access during your
session, click Start Remote Control in Multi-user Mode.
New windows open that provide access to the Remote Disk and Remote
Console functionality. If the Encrypt disk and KVM data during transmission
check box was selected before the Remote Control window was opened, the
disk data is encrypted with 3DES encryption.
Note: The following steps are only intended if the user receives the error
message "Unable to launch the application."
If you receive the error message, "Unable to launch the application,"
perform the following steps:
a) Verify that the Windows PC is running Java 1.6 or higher
Go to the PCs control panel.
Navigate to General > Temporary Internet Files > Settings
Select Keep temporary files on my computer
Click OK
Click OK
b) Re-click the appropriate link: Start Remote Control in Single User

Mode or Start Remote Control in Multi-user Mode.
170
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
7. Close both the Video Viewer window and the Virtual Media Session window
when you are finished using the Remote Control feature.
Attention: The IMM Remote Console has a Power/Restart option as shown
below:
The sub-options Shut down OS and then Power Off Server and Shut down
OS and then Restart Server are disabled. These options are disabled
because IBM implemented the Shut down OS option by mimicking a short
press of the power button. If the Shut down OS option is enabled, then giving
a short press on the power button would also be enabled. To prevent the
inadvertent shut down, (i.e., by mistakenly bumping the power button), both
of these options have been disabled.
To shut down the OS and then power off or restart the OSV server, the user
must shut the OS down manually and then select power off or restart as
follows:
a) Go to the IMMs navigation tree on the left side of the screen.
b) Navigate to: Tasks > Remote Control
c) Open a console screen and enter the following as user root:
# /unisphere/srx/3000/srx/startup/srxctrl 2 0
# halt
d) Go to the IMMs navigation tree on the left side of the screen.
e) Navigate to: Tasks > Power/Restart
f)
Appropriately, click either: Power Off Server Immediately or Restart

Server Immediately
A31003-H8050-J100-09-7631, 09/2011
171
recmd_hw.fm
Installing the FTS RX200 Server
3.7 Installing the FTS RX200 Server

3.7.1 How to use the FTS RX200 Server Installation
Checklist

responsible.
3.7.2 FTS RX200 Server Installation Checklist

Use the following checklist to monitor the installation of the FTS RX200 server.
Note: The FTS RX200 is shipped to the site fully assembled. Firmware is
preloaded at the factory.
Item
Description
1.

page 173.
2.
Locate the FTS RX200 server printed documentation and digital

3.
174.
4.
Connect all cables.
Table 18
172
Initials

page 174.
Redundant OpenScape Voice systems: Refer to Section

3.7.6.2 on page 176.
FTS RX200 Server Installation Checklist (Sheet 1 of 2)
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Item
Description
5.

page 181.
6.

192.
7.
Activate the remote system console. Refer to Section 3.7.9 on

page 205.
8.
Verify that the correct firmware version is used. Refer to Section

3.7.10 on page 212.
Click this link to return to step 3 on page 212.
Table 18
Initials
FTS RX200 Server Installation Checklist (Sheet 2 of 2)
3.7.3 Inventorying and Inspecting the FTS RX200

5. On the FTS RX200 Server Installation Checklist, initial step 1 and proceed to
step 2.
3.7.4 Locating the FTS RX200 Server Printed

FTS RX200 server printed guides and digital media
KVM documentation (if so equipped)


A31003-H8050-J100-09-7631, 09/2011
173
recmd_hw.fm
On the FTS RX200 Server Installation Checklist, initial step 2 and proceed to
step 3.
3.7.5 Installing the FTS RX200 Servers into the Rack

1. Refer to the FTS RX200 rack installation instructions to install the servers into
the rack.
step 4.
3.7.6 Connecting the Cables to the FTS RX200 Server

174 for a single-node OpenScape Voice and to Section 3.7.6.2 on page 176 for
a redundant OpenScape Voice.
3.7.6.1 Connecting the Cables for a Single-Node FTS RX200

1. Attach the keyboard, mouse (the FTS RX200 requires a USB keyboard and
mouse: a PS/2 to USB adaptor can be used in most cases), and monitor
the back of the FTS RX200.
assistance.
operation and the gigabit links are programmed. Refer to the Ethernet switch
manufacturers documentation for instructions.
174
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
device definitions in the node.cfg file were used. If the standard was not
used, the connections will be different from those listed here. The standard
Ethernet device definitions are as follows:
Ethernet device definitions:

definition igb.
Voice on an FTS RX200 platform.
follows:
The upper row of ports is odd numbers, 1 through 23, starting from the
The lower row of ports is even numbers, 2 through 24, starting from the
1
11
13
15
17
19
21
23
10
12
14
16
18
20
22
24

LAN) or Table 20 on page 175 (for a redundant LAN) so that the wiring from
one single-node OpenScape Voice installation to another is uniform. Refer to
connections.
Connection
From
To
Administration
Port0
switch0.1
Signaling
Port1
switch0.2
Billing/CDR
Port2
switch0.3
iRMC Ethernet port
switch0.4
Table 19
Ethernet Connections (FTS RX200 Single-Node Server, Single

LAN)
Connection
From
To
Administration
Port0
switch0.1
Signaling
Port1
switch1.1
Table 20
Ethernet Connections (FTS RX200 Single-Node Server,

Redundant LAN)
A31003-H8050-J100-09-7631, 09/2011
175
recmd_hw.fm

Connection
From
To
Billing/CDR
Port2
switch1.2
iRMC Ethernet port
switch1.3
Table 20
Ethernet Connections (FTS RX200 Single-Node Server,

Redundant LAN)
Figure 9
FTS RX200 Rear View for the Single-Node OpenScape Voice
step 5.
3.7.6.2 Connecting the Cables for a Redundant FTS RX200

1. Attach the keyboard, mouse (the FTS RX200 requires a USB keyboard and
mouse: a PS/2 to USB adaptor can be used in most cases), and monitor
cables to the server.Figure 10 on page 177 shows the connector locations at
the back of the FTS RX200.
assistance.
176
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
Ethernet device definitions:

definition igb.

definition igb.
Figure 10 shows the Ethernet ports for the FTS RX200.
Figure 10
FTS RX200 Rear View for a Redundant OpenScape Voice

follows:
The upper row of ports is odd numbers, 1 through 23, starting from the
The lower row of ports is even numbers, 2 through 24, starting from the
A31003-H8050-J100-09-7631, 09/2011
177
recmd_hw.fm
11
13
15
17
19
21
23
10
12
14
16
18
20
22
24

Complete the Ethernet connections as follows:

connections.

Use Figure 10 on page 177 and Table 22 on page 179 to make the
Ethernet connections.

configuration because two Ethernet LAN switches are required at each node
location.
Connection
From
To

direct connect CAT-5 cable.
Node1 Port3
Node2 Port3
Node1 Port7
Node2 Port7
Node1 Port0
switch0.1
Node1 Port4
switch1.1
Node2 Port0
switch0.2
Node2 Port4
switch1.2
Node1 Port1
switch0.3
Node1 Port5
switch1.3
Node2 Port1
switch0.4
Node2 Port5
switch1.4
Node1 Port2
switch0.5
Node1 Port6
switch1.5
Node2 Port2
switch0.6
Node2 Port6
switch1.6
Node1 iRMC
Ethernet port
switch0.7
Node2 iRMC
Ethernet port
switch1.7
Table 21
Ethernet Connections; FTS RX200 Co-Located Node

Configuration

178
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm

Connection
From
To
Node1 Port0
switch0.1
Node1 Port4
switch1.1
Node2 Port0
switch2.1
Node1 Port4
switch3.1
Node1 Port1
switch0.2
Node1 Port5
switch1.2
Node2 Port1
switch2.2
Node2 Port5
switch3.2
Node1 Port2
switch0.3
Node1 Port6
switch1.3
Node2 Port2
switch2.3
Node2 Port6
switch3.3
Node1 iRMC
switch0.4
direct connect CAT-5 cable.
Ethernet port
Node2 iRMC
switch2.4
Ethernet port
Table 22
Node1 Port3
switch0.6
Node1 Port7
switch1.6
Node2 Port3
switch2.6
Node2 Port7
switch3.6
Ethernet Connections; FTS RX200 Geographically
Separated Node
Attach two links (100BaseT or 1000BaseT) between switch 0 and switch 1.
interconnect:
Node1 site

switch 1.

layer 2 bridge.

A31003-H8050-J100-09-7631, 09/2011
179
recmd_hw.fm
Node2 site

switch 3.

layer 2 bridge.


interconnect:
Node1 site

switch 1.

layer 3 router.

Node2 site

switch 3.

layer 3 router.

step 5.
180
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3.7.7 Modifying the FTS RX200 RAID Configuration

1. Turn on the server. After a short while the following screen is displayed:
Note: It is normal to see a blank screen for approximately 45 seconds.
A31003-H8050-J100-09-7631, 09/2011
181
recmd_hw.fm
2. Press the Ctrl and H keys simultaneously to start the WebBios utility. The
182
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3. Select Start button and press Enter to get to the main page of WebBios. The
A31003-H8050-J100-09-7631, 09/2011
183
recmd_hw.fm
4. Use the tab key to navigate through the WebBios options on the left side of
the screen.
Select Configuration Wizard and press Enter. The following screen is
displayed:
184
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
5. Select New Configuration. Click Next. The following screen is displayed:

Note: If the server was previously used and you want to reset the RAID
configuration and start as if it is a new system, select Clear Configuration.
Click Next. On the following screen, select Yes to clear the configuration. You
can then go back to step 4 and start setting up the RAID configuration.
A31003-H8050-J100-09-7631, 09/2011
185
recmd_hw.fm
6. Since it is a new system, select Yes and press Enter to clear the
configuration. The following screen is displayed:
186
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
7. Select Automatic Configuration. In the Redundancy field, select

Redundancy when possible. Click Next. This illustrates the new Virtual
RAID to be created as displayed on the following screen:
8. Select Accept and press Enter.
A31003-H8050-J100-09-7631, 09/2011
187
recmd_hw.fm
9. When prompted if you want to Save this Configuration, select Yes and press
enter. The following screen is displayed:
10. Select Yes and press Enter to initialize the drives:
188
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
11. Select Fast Initialize. Select Go and press Enter. The following screen is
displayed:
12. Select Yes to proceed with initialization.
A31003-H8050-J100-09-7631, 09/2011
189
recmd_hw.fm
13. Click on the Home button to get back to the main page. The following screen
is displayed:
190
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
14. The logical view should now indicate the presence of a Virtual RAID.
From the WebBios options on the left, select Exit and press Enter. The
15. Select Yes and press Enter to confirm exiting the application.
On the FTS RX200 Server Installation Checklist, initial step 5 and proceed to
step 6.
A31003-H8050-J100-09-7631, 09/2011
191
recmd_hw.fm
3.7.8 Modifying the FTS RX200 BIOS Settings

1. If not currently in the Setup Utility, reboot the server (either cycle the power or
press the Ctrl-Alt-Del keys simultaneously).
BIOS Setup Utility.
Note: It is normal to see a blank screen for approximately 45 seconds.
192
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
The Main screen of the BIOS Setup Utility is displayed as in the following
screen:
3. On the Main screen of the Setup Utility, verify the systems time and date. If it
is incorrect, set System Time and System Date. Use the tab key to highlight
the correct field and press the space bar to change the field to the correct
time/date value.
The banner at the bottom of the Main screen describes how to select and
change the values in the time and date fields on the Main screen. It also
describes how to select screens.
The right column of the Main screen provides item specific help.
A31003-H8050-J100-09-7631, 09/2011
193
recmd_hw.fm
Once completed, use the right arrow key to move to Advanced tab:
194
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
4. Using the down arrow, navigate to Advanced Processor Options and press
Enter. Using the down arrow, move down to Enhanced Idle Power State.
Change the value to Disabled and press Enter as shown on the following
screen:
A31003-H8050-J100-09-7631, 09/2011
195
recmd_hw.fm
5. Using the down arrow, move down to Hyper-Threading. Change the value
to Disabled and press Enter as displayed on the following screen:
6. Press Esc to return to Advanced tab screen.
196
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
7. Using the right arrow, move to Server tab:
A31003-H8050-J100-09-7631, 09/2011
197
recmd_hw.fm
8. Using the down arrow, navigate to IPMI and press Enter. The following
screen is displayed:
198
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
9. Using the down arrow, navigate to LAN Settings and press Enter. The
following LAN Settings sub screen is displayed:
A31003-H8050-J100-09-7631, 09/2011
199
recmd_hw.fm
10. Unless the IPMI address comes from a DHCP server, change DHCP value to
Disabled as shown on the following screen:
200
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
11. Enter valid values for the Local IP Address, Subnet Mask and Gateway
Address of the iRMC as shown on the following screen:
A31003-H8050-J100-09-7631, 09/2011
201
recmd_hw.fm
12. Press the Esc key twice to back out to the Menu screen. Using the right arrow
key, move to Boot tab:
202
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
13. Verify that the boot order is as above, using the +, - and other keys to set the
boot order to appropriate values. When done, using the right arrow key, move
to Exit tab:
A31003-H8050-J100-09-7631, 09/2011
203
recmd_hw.fm
14. Select Save Changes & Exit, and press Enter.
15. In the Setup Confirmation dialog box, select Yes to confirm that you want to
exit. The system reboots.
step 7.
204
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3.7.9 Remote Console Startup for the FTS RX200

Server
1. Start a web browser. Type the IP address of the iRMC in the Address bar and
click Go.
Note: Use the iRMC IP address you specified in step 10 of Section 3.7.8 on
page 200 of the BIOS setup procedure.
Use https for a secure connection. This should bring up the web page for the
iRMC:
You will be prompted for a user id and password. The default values are
admin (for both fields). After the login and password are entered, the main
page should come up:
A31003-H8050-J100-09-7631, 09/2011
205
recmd_hw.fm
2. On the Server View Suite screen, from the column on the left side of the
screen, select Console Redirection then Video Redirection.
206
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
3. Click on Start Video Redirection button from the main window. A second
window will pop up for the Java applet as shown on the next screen:
Note: A Security Warning pop up window may appear before the Java Applet
of the next screen indicating the web sites certificate cannot be verified and
if you want to continue? Select Always trust content from this publisher.
Select Yes. On the next window that appears, select Run.
A31003-H8050-J100-09-7631, 09/2011
207
recmd_hw.fm
And then the console window pops up as shown on the following screen:
208
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
4. Select Ok to take control of the console. Then click in the main window to gain
focus.
After you are connected to the remote console the following screen is
displayed (note the Full Control in the title bar at the top of the screen).
A31003-H8050-J100-09-7631, 09/2011
209
recmd_hw.fm
5. To finish, click on Extras from the menu bar and select Exit from the drop
down menu as shown on the following screen:
210
A31003-H8050-J100-09-7631, 09/2011
recmd_hw.fm
6. On the Server View Suite screen, from the column on the left side of the
screen, select Logout as shown on the following screen and then on the main
window, confirm the Logout.
step 8.
A31003-H8050-J100-09-7631, 09/2011
211
recmd_hw.fm
3.7.10 Firmware Updates for the FTS RX200 Server

1. From the main ServerView Suite Page, verify that the BIOS version is at
version 1.04.3031 or higher as shown below:
Note: The BIOS version should come preloaded from Fujitsu; however if it is
not at the level indicated above (or higher), log onto the Fujitsu website to
download and install the latest version for this platform.
2. On the FTS RX200 Server Installation Checklist, initial step x.
step 9.
212
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Installing the OpenScape Voice Reference Image
Prerequisites
4 Installing the OpenScape Voice Reference Image

4.1 Prerequisites
Hardware installation: Before the OpenScape Voice reference image can be

loaded, the hardware must be installed and cabled. Refer to the checklists in
Chapter 2, Preparing for the Installation and Chapter 3, Installing the
Hardware Platform.
Reference image DVDs: You must first burn the OpenScape Voice V5
reference image to the DVDs that you then use to install OpenScape Voice.
Node.cfg file: Because the network design and IP address allocations are
already known, the node.cfg configuration file can and should be prepared in
advance of the installation process. Refer to Section 2.5 on page 35 to
prepare the node.cfg file.
4.2 Installation via DVD

4.2.1 Overview
The L3 interconnection link must be up and running during the entire procedure
in order for the installation to complete successfully.
You may start the installation on a duplex system (co-located or geographically
separated) at one node first and then start the installation some time later at the
second node.
The first node will stop at RtpInstall step 0 and wait for the second node to reach
RtpInstall step 0.
At that point, the two nodes will get in sync, pass the interconnection test, and
complete the installation.
During an installation or an upgrade process, the hard disk drives for each node
are divided into two partitions of equal size. These HDD partitions are referred to
as the Primary partition and the Secondary partition.
The partition on which the running software resides is called the Active partition
(this could be either the Primary or Secondary) and the other partition is called
the Fallback partition (also referred to as the standby partition).
A31003-H8050-J100-09-7631, 09/2011
213
sw_install.fm
Installation via DVD
Patching procedures always apply to the Active partition only.

Note: This Note does not pertain to Upgrade or Migration procedures.
Upgrades and migrations should follow the steps of their respective
Upgrade/Migration scenario.
This note only applies to lab environments installing an OpenScape Voice server
image without updating the existing External Application Server (OffBoard)
server. This will prevent a lockout of the OpenScape Voice srx user during the
image installation. Any questions should be addressed to your next level of
support before proceeding.
In lab environments with an already existing External Application Server
(OffBoard);
- If the external Applications server is a Multiple Communication Server Admin
deployment, remove the Voice server system from the external Applications
server List of Switches. Do not Add the Voice Server to the external
Applications server until the image install is complete.
- If the external Applications server is monitoring this system only, i.e.,
Applications servers deployed in a Standard Duplex - Small Deployment, stop
symphoniad. The symphoniad process can be stopped before the image is
installed and started after the image install completes.
Removing an OpenScape Voice server from a Standard Duplex (Large or
Small) UC Applications deployment will result in the loss of UC application
data (e.g., OpenScape Users/Resources).
Any questions should be addressed to your next level of support before
proceeding.
4.2.2 Installation
Note: If you are upgrading OpenScape Voice, refer to Chapter 7, Overview of
Upgrades and Migrations to OpenScape Voice V5 for instructions. Please do so
before proceeding.
This section provides a procedure for installing the OpenScape Voice reference
image onto IBM x3650T, IBM x3550 M2/M3, FTS RX200 or FSC RX330 servers
for either redundant or single-node OpenScape Voice and onto an IBM x3250
M2/M3 server for the single-node OpenScape Voice Entry.
One DVD with the reference image and one USB memory stick with the node.cfg
file and response file is required for a single node system.
214
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Two DVDs with the reference image and two USB memory sticks with the
node.cfg files are required for a redundant system.
Note: In V5R0 (and later releases), integrated systems response files are built
automatically as part of the installation process. Response files no longer need to
be generated for images and are not required on USB sticks. If a response file is
found on the USB stick, that file will take precedence over the file that is
automatically generated via the Image installation.
Install the OpenScape Voice V5 reference image software as follows:

Note: Patch sets can be loaded onto the memory sticks for automatic
installation during the image installation. Refer to Section 2.6, Loading Patch
Sets onto the USB Memory Sticks, on page 43 for instructions.
1. Insert the reference image DVD into the DVD drive of node 1. Do not insert
the USB until prompted to do so by the system.
2. For a redundant system, insert the reference image DVD into the DVD drive
of node 2. Do not insert the USB until prompted to do so by the system.
3. Read the following choices and proceed as necessary for your Image
installation scenario.
If you reached this section as part of a new install (not an Upgrade/

Migration procedure), cycle the power with the power buttons and
proceed to Step 4.
If you reached this instruction from a Migration procedure in which the

server platforms have been replaced and the target image is being
installed on the new platforms cycle the power with the power buttons and
proceed to Step 4.
If you reached this instruction from a Upgrade/Migration procedure
and the OpenScape Voice servers (server for simplex) are not
replaced, the server(s) have to be prepared for rebooting. The Voice
server nodes must be configured to state 2 and the nodes (node for a
simplex system) should be rebooted from the command line. For this
case the following instructions will configure your node(s) for the 'reboot':
For integrated systems, follow steps 3a through 3d, then proceed to

step 4.
For a standard duplex system, follow steps 3b through 3d, then

proceed to step 4.
Note: The commands are to be executed as user "root".
A31003-H8050-J100-09-7631, 09/2011
215
sw_install.fm
a) For integrated systems stop Symphonia with this command:

root@fsc301:[~] #1000
# /etc/init.d/symphoniad stop
Shutting down OpenSOA Framework
b) From Node 1, configure the nodes (or node for simplex systems) to state
2 with the command:
Duplex systems:
root@fsc301:[~] #910
# /unisphere/srx3000/srx/startup/srxctrl 2 2
Simplex systems;
root@fsc301:[~] #910
The nodes (or node for simplex systems) should be at state 2 when the
system displays a message similar to this:
--- srxctrl ended on Wed May 27 13:52:27 2009 --c) Verify the status of the nodes (or node for simplex systems) with the
command:
root@fsc301:[~] #911
# /unisphere/srx3000/srx/startup/srxqry
It is expected that nodes (or node for simplex systems) will be at state 2
at this time.
d) From the console of each node, reboot the node with the command:
root@fsc301:[~] #912
# reboot
Note: The labeling convention for the images has changed to better
represent the OpenScape Voice image being installed. The image label will
be represented as Va_Rb.c.d_ee in step 4 where:
a = Base software version
b = Software release version
c = Patch set level
d = Emergency patch set level
ee = Image version
As an example, V5_R0.8.5_06 represents:
V5R0, patch set 8, emergency patch set 5, image version 6.
4. Select Install Softswitch - V5.0 and press Enter when the boot screen with
the following options is shown:
216
Boot from Hard Disk
Install Softswitch - V5.0
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
The End User License Agreement (EULA) is displayed in a new window on

the console screen.
Review and accept the EULA as follows:
a) Review the EULA using the Page Up/Page Down or arrow keys; when
you are finished reviewing the EULA, select Done and press the Enter
key.
A window is opened with the question: Do you accept the License
Agreement? with the options Yes and No.
b) In the EULA acceptance window, use the Tab or arrow keys to select Yes
to proceed with the image installation. Selecting No will halt the image
installation. If you select No by mistake, to continue with the image
installation, reboot the server and when prompted to accept the EULA
select Yes.
5. When prompted to Please insert the USB stick now,
a) Connect the memory stick labeled node.cfg.primary to the primary
node. Only the node.cfg.primary file is required in the usb stick. In V5R0
(and later releases), integrated systems response files are built
automatically as part of the installation process. Response files no longer
response file is found on the USB stick, that file will take precedence over
the file that is automatically generated via the Image installation.
Attention: New installations, upgrades or migrations to an integrated
duplex system are not offered with V5R0. If you are upgrading an
integrated duplex to V5R0, refer to Section , Overview of Upgrades and
Migrations to OpenScape Voice V5 for upgrade information and
procedures.
b) A Network Information window is displayed. Review the information.
Select Done and press Enter. At the next step, you will have the option
to continue or exit the install process. If the network information is
unsatisfactory, select no to exit the installation in the next step. After
exiting the installation, correct the erroneous information in the node.cfg
file and start the installation procedure again. If the network information is
satisfactory, continue with the image installation.
Attention: A safeguard has been implemented for the installation to prevent
users from employing a node.cfg file with the incorrect installation mode setting.
If your node.cfg contains an installation mode used by Split Mode Upgrade
(SMU), an Installation Mode Warning window will display on the console. If you
are performing an SMU, select <Yes>. If your installation is not an SMU, select
A31003-H8050-J100-09-7631, 09/2011
217
sw_install.fm
<No>. The installation will be aborted. Change the Installation Mode to 'normal'
with the NCPE and restart the installation process. Below is an example of the
Installation Node Warning.
c) Users have the option to install the image on the partition of their choice.
On boot, they are prompted with "yes/no/format/lockprim/locksec"
options. An explanation of the options is next, followed by a sample
snapshot of the output.
Attention: The Format option should not be employed during Upgrade or
Migration procedures. The source release partition needs to be
maintained in case a "Fallback" to the source release is required.
Options:
yes: Erases data from the first unlocked image and the image is installed
on that unlocked partition\image.
no: Aborts the installation.
Format: Reformats hard disk, user looses all the data and the image is
installed on the primary partition.
Lockprim: Erases data from the secondary partition and the image is
installed on the secondary partition.
Locksec: Erases data from the primary partition and the image is
installed on the primary partition.
Any questions regarding these new options should be addressed to your
next level of support.
Sample screenshot;
Note: Typing yes or format will erase all data from
unlocked partition on the disk.
: yes
- Erases data from the first unlocked image.
: no
- Aborts installation.
: format - Reformats harddisk, user looses all the data

: lockprim - Erases data from the secondary partition
218
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
: locksec - Erases data from the primary partition

Do you want to continue with installation (enter yes/no/
format/lockprim/locksec)?
Go to step 5d
d) The installation process is started and takes approximately 40 minutes
(depending on the target patch set level). Please note the following:
The DVD is ejected automatically prior to final reboot with the x3250
server. For the FSC RX330 server, the DVD or DVDs are ejected and
on reboot are automatically reinserted. For the FTS RX200 and
RX330 servers, the DVD or DVDs are ejected and on reboot are
automatically reinserted. For the x3650T and the x3550 M2/M3
servers, the DVD or DVDs are not ejected. The user need not take
any action; the installation will continue.
The node or nodes are rebooted.
The installation process is completed when messages similar to the

following example are displayed on the Console monitor:
Image Status: Completed installation at

<Day MM Date hh:mm:sec Timezone Year>
System verification
done
Master Resource Control: runlevel 3 has been
reached
Skipped services in run level 3:
acpid nfs
Authorized uses only. All activity may be monitored and

reported.
<hostname>
login: 0: OK Command execution
The text OK Command execution appears on the Console monitor in

a simplex installation or only one of the Console monitors in a duplex
installation. During the imaging process, there are times when the above
message appears before the server is rebooted, please ignore this
message. Wait for the message to appear after the login prompt on the
Console monitor. You can then remove the DVDs and USB memory sticks
(or DVD and stick for a simplex system).
Note: To clarify the Image Status text layout an example is presented;
Image Status: Completed installation at Tue Dec 21 13:31:13 EST 2010.
Note: It is a good practice to copy the files from the top level directory of
the USB memory stick to another location (for example, an FTP server or
backup server/device) for future reference or diagnostic purposes.
Depending on the OpenScape Voice system configuration, the files on
the stick can include the following:
A31003-H8050-J100-09-7631, 09/2011
219
sw_install.fm
node.cfg.primary or secondary - written before the installation begins

response.cfg.primary - written before the installation begins
install.log - written during the image installation process
current.hwinfo - written during the image installation process
Ensure that the file naming convention for the files install.log and
current.hwinfo easily identifies the files as a Node 1 or Node 2 file. An
example follows;
File install.log could be named nX_install.log where X=1 for node 1 and
X=2 for node 2.
File current.hwinfo could be named nX_current.hwinfo where X=1 for
node 1 and X=2 for node 2.
OpenScape Voice V5 default users and passwords are:
Type
User
Password
Console
root
T@R63dis
Console
srx
2GwN!gb4
SSH
sysad
1clENtk=
SSH
superad
BF0bpt@x
SFTP
cdr
MNY9$dta
The "sysad" and "superad" users can be used to access the system via
console as well as via SSH.
6. After the installation is complete, to verify that the installation was successful,
log in as user root and execute the following commands:
# cd /unisphere/srx3000/srx/startup
# ./srxqry -v
A successful software installation is indicated if the nodes (or node) are at run
level 4 (RTP and application running with all processes started).
Note: If the installation process stops prematurely or if the nodes (or node)
do not reach run level 4, this is an indication of a failed installation.
The installation logs are kept on the USB memory stick in the install.log file.
The hardware information for the platform in progress is also placed on the
USB memory stick in the current.hwinfo file.
If the installation has failed and the reason is not obvious from the general
system behavior or the install.log file, contact your next level of support for
assistance.
Regardless of installation success or failure, copy the install.log,
220
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
current.hwinfo, node.cfg.primary (and node.cfg.secondary, if applicable), and

response.cfg.primary (for integrated systems only; also copy the
response.cfg.secondary, if applicable) files from the memory stick to another
location (for example, FTP server or backup server/device) for future
reference or diagnostic purposes.
7. As user srx, verify that the software is at the patch set level listed in the
OpenScape Voice V5 release note with the command:
pkgversion -ps
Attention: Unless directed otherwise by Release Notes, the target
OpenScape voice server patch level must be V5R0 patch set 6E03 or greater.
An integrated system should ensure that the applications server is updated
with the latest released DVD/PatchSet/HotFix.
If the patch set level is not correct, install the corresponding patch sets using
the CMP/Assistant (after installing the OpenScape Applications for a
standard duplex).
8. As user root, verify that the system is an imaged system with the command:
rpm -qa | grep UNSPxtree
Verify that UNSPxtree-1.0-1 is displayed.
Note: If you were sent to this section from an upgrade or migration procedure,
return to the upgrade or migration procedure rather than going to the
OpenScape Voice Installation Checklist.
9. On the OpenScape Voice Installation Checklist in Section 2.2.4 on page 24,
initial step 9 and proceed to step 10.
A31003-H8050-J100-09-7631, 09/2011
221
sw_install.fm
Virtualization Environment Setup
4.3 Virtualization Environment Setup

The following provides a guideline for installing an OpenScape Voice (OSV)
image onto a VMware ESXi virtualized platform. The installation of the VMware
environment is outside the scope of this guide.
VMWare features tested for V5 OpenScape Voice with ESXi 4.1:
VMware HA
Migration with VMotion
WMware DRS
Snapshots (of a Virtual machine). When snapshots of the OSCV virtual

machine were taken, the two boxes presented in the "Take Virtual Machine
Snapshot" window were NOT selected. The "Snapshot the virtual machines
memory" box is not selected to prevent stale call data if the snapshot is
restored. The "Quiesce guest file system" box is not selected because this
selection will pause running processess which will degrade service. An
example of the "Take Virtual Machine Snapshot" window follows:
Attention: If a vMotion or snapshot activity is performed during high traffic

periods, a slight degradation in service may be observed.
Feature information can be accessed from the vSphere client toolbar Help menu.
More information regarding Migration with vMotion and VMware can be found in
the following manual:
222
vSphere Datacenter Administration Guide, ESX 4.1, ESXi 4.1, vCenter

Server 4.1
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Information regarding VMware HA can be found in the following manual:
vSphere Availability Guide, ESX 4.1, ESXi 4.1, vCenter Server 4.1
More information regarding Snapshots can be found in the following manual:
vSphere Virtual Machine Administration Guide, ESX 4.1, ESXi 4.1, vCenter
Server 4.1
Note: VMware best practices include installing VMware tools. However, OSV
does not support using VMware tools to change the NW Adapter from the default
E1000 (for SLES 10 64 bit). Also, OSV requires resources to be reserved per the
table in Section 4.3.3.2, Virtual Machine Configuration Parameters Overview,
on page 228. Installing VMware tools without reserving resources is not
supported by OSV.
Note: The following VMware specific features have not been tested:
- VMware vStorage APIs/VCB-consolidated backup
- VMware vCenter Update Manager
- VMware Fault Tolerance
- VMware Data Recovery
- VMware vShield Zones
- VMware Storage vMotion
- VMware DPM
4.3.1 Virtualization Overview

Attention: Tests were executed on a Two Physical Server Solution, for
configuration details, see Section 4.3.3, Virtual Machine Guidelines, on page
226.The tests employed IBM System x3550 M2 platforms with the following
hardware profile;
- 2 CPU Quad core Intel Xeon 5540 Series Nehalem processors minimum
2.53 GHZ
- 8 GB RAM
- 300 GB HD
A31003-H8050-J100-09-7631, 09/2011
223
sw_install.fm
The installation described herein is not the only possible virtual OSV installation.
The host, not the OSV VM, needs to be configured with NIC teaming if network
redundancy is required.
Note: Reference the VMware Compatibility Guides for software and hardware
recommendations. As an example, for information regarding using Nehalem
processors in the Virtual machine host, see the VMware Resource Management
Guide for virtual machine overhead characteristics. These guides are available at
the VMware homepage (www.vmware.com).
In V5, virtualization is supported for standard duplex (co-located and

geographically separated) configurations only.
By definition, a virtual environment is hardware independent. Because of this
hardware independence, the examples provided in this guide will describe the
installation and setup for a IBM X3550M2. Therefore all references to a Physical
Server will refer to the IBM x3550M2 system.
Note: In this document, one more subnet to control the VMware Management
Interface is added. This is not necessary if the desired the VMware Management
Interface can be tied to a valid and available IP in the admin subnet.
Viewing the Document with Adobe Reader

When viewing the document with Adobe Reader, add the Previous View icon to
the Reader toolbar. This will ease the navigation between this procedure and
associated sections of the document.
Add the Previous View icon as follows;
Open the tools menu
Navigate to Customize Toolbars; this will present the More Tools window.
In the More Tools window scroll down to the Page Navigation Toolbar
Select the Previous View icon.
Select Okay in the More Tools window
If this procedure contains links to other sections of the document, execute the
specified task and then select the Previous View icon in the Reader toolbar to
return to this procedure.
Characteristics of the Virtual OpenScape Voice
The virtual OSV has the following characteristics;
224
Supports OSV images in a Storage Area referred to as a datastore.

A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Is HW independent.
Has no maintenance controller interfaces (RSA, IMM, iRMC, VMK).
Does not support HW Alarming.
Currently supports and requires a fixed number of 4 (virtual) Ethernet ports.
Supports 2 node clustering in co-location and network geographical

separation.
OSV can be deployed on as a co-located on 1 (both nodes on same physical

host) or 2 hosts, or as a geo-separated system on 2 hosts. It can use internal
or SAN storage.
OSV is compatible with ESXi V4.1 and all hardware used should be on the
VMware compatibility list for ESXi V4.1.
Virtual machine disk size of at least 140 GB.
OSCV redundancy depends on Survival Authority. Without Survival Authority

a single node failure or interconnection failure may bring down the whole
cluster. This is a valid for all co-located and geo-separated configurations.
OSCV StandAlone Sevice is only allowed for a L3-geo-separated

configuration (i.e., a configuration that does not provide a virtual IP failover).
For the StandAlone Service feature to be available in a virtual environment
the node.cfg parameter Node Separation = separate must be selected. The
Stand Alone Service is enabled by default in this configuration.
Disk Space Limitations:

If you choose to install from an ISO image file instead of a DVD, please allocate
at least 5 GB of disk space in a nodes datastore for the placement of the
Virtualization Image DVD ISO and Node Configuration files.
Other Limitations:
The virtual OSV system is hardware (HW) independent. It is assumed that the
HW platform is installed, supervised and maintained by the customer. This
includes the installation and configuration of the virtual machine that will host the
OSV.
The virtual OSV assumes it has one disk and 4 Ethernet ports.
Disk location (local or network), disk redundancy (RAID), any kind of HW
redundancy, and network redundancy (bonding driver) are outside the scope of
virtual OSV control and need to be installed by the customer.
A31003-H8050-J100-09-7631, 09/2011
225
sw_install.fm
4.3.2 Checklist for Virtualization

This procedure assumes that steps 1 through 8 of Section 2.2.4, OpenScape
Voice Installation Checklist, on page 24, have already been completed. Please
review steps 1 through 8 before proceeding.
At the end of the Virtual Machine Environment setup, you will be referred back to
the Installation Checklist to perform other installation tasks (as required for your
environment).
Task
Description
Determine if Physical Server hardware is supported by VMware.
Determine if the local hard disk of this server will be the datastore or if a SAN will
be connected.
If a SAN will be connected then determine if it is supported by VMware.
Have an operational Windows or Linux system at hand in order to build the

node.cfg and place them on the virtual floppies. For virtual machine node.cfg
instructions refer to Section 4.3.4, Creating a Node.cfg File, on page 235.
Determine the Network Port to VMNIC mapping.
Determine what kind of installation configuration you will be conducting (CoLocated, Geo-Separated).
For Co-Located configurations determine if the guest servers will be running on

1 physical host server or 2 physical host servers.
Determine network cabling based on the decisions made in steps 5 through 7.
Create the guest VMs according to the specifications in the VM release notes.
10
Install the HiPath8000 Image on the guest VMs created.
11
The Survival Authority is installed with the OpenScape Voice image and will be
verified as part of the installation.
Table 23
Checklist for Virtualization
4.3.3 Virtual Machine Guidelines

Attention: Tests were executed on a Two Physical Server Solution, for
configuration details see below. The tests employed IBM System x3550 M2
platforms with the following hardware profile;
- 2 CPU Quad core Intel Xeon 5540 Series Nehalem processors minimum
226
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
2.53 GHZ
- 8 GB RAM
- 300 GB HD
Note: Reference the VMware Compatibility Guides for software and hardware
recommendations. As an example; the use of Nehalem processors in the Virtual
machine host. See the VMware Resource Management Guide for Virtual
machine overhead characteristics. These guides are available at the VMware
homepage (www.vmware.com).
Note: The configuration of the virtual machine must be done prior to the
installation of the OSV software. The host machine must be using ESXi V4.1.
4.3.3.1 Requirements to Underlying Host Hardware

Due to the resource and configuration requirements of the VMs for OpenScape
Voice, the following dependencies to the hardware of the ESXi hosts need to be
considered before system setup:
CPU
For each VM, CPU, resources shall be reserved as described in
Section 4.3.3.2. For lower number of users on a given deployment, less CPU
resources might be required.
RAM
All OpenScape Voice nodes require RAM reservation based on the values in
Section 4.3.3.2. This means that VMs memory needs to exist as physical
memory in the host.
A31003-H8050-J100-09-7631, 09/2011
227
sw_install.fm
Storage
For each VM, hard disk space must be reserved as described in
Section 4.3.3.2. This space may either be local to the ESXi host or reside on
a SAN, provided the SAN is equivalent to a local hard disk from a
performance point of view.
Note: Disk redundancy (RAID) is outside the scope of virtual OSV control and
needs to be installed by the customer.
4.3.3.2 Virtual Machine Configuration Parameters Overview

Table 24 lists the configuration parameters needed to configure each OpenScape
Voice node.
Note: The line VM RAM [GB] + reservation includes the memory to be reserved
for the VM. For overall memory sizing, include at least 2.5 GB of RAM for the
ESXi.
Note: See Section 4.3.3.7, Virtual Machine Disk Requirements for additional
HD overhead required on the physical host.
Deployment
OSVoice
OSVoice
OSVoice
OSVoice
Users
<=1.000 Users
<=5.000 user
<=10.000 users
Up to Max # of
Users
Server
Each OSV
NODE
Each OSV
NODE
Each OSV
NODE
Each OSV
NODE
Guest OS
SLES 10 SP3
SLES 10 SP3
SLES 10 SP3
SLES 10 SP3
Real time Application

Y
Note: Resources need to be reserved for Real time
apps otherwise availability cannot be guaranteed
VM HD [GB]
140 GB
140 GB
140 GB
Table 24
228
140 GB
Virtual Machine Computer (minimum) Requirements for OpenScape Voice with OpenScape UC Suite V5
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Deployment
OSVoice
OSVoice
OSVoice
IOPS - Input output operations per second (Storage Shares = N +

I/O)
unlimited IOPS
Note from VMware Resource Management Guide: (defaults)
Before using Storage I/O Control on data stores that
are backed by arrays with automated storage tiering
capabilities, check the VMware Storage/SAN
Compatibility Guide to verify whether your
automated tiered storage array has been certified to
be compatible with Storage I/O Control.
Shares = N +
unlimited IOPS
(defaults)
Shares = N +
unlimited IOPS
(defaults)
Shares = N +
unlimited IOPS
(defaults)
Disk Throughput in Kbps
23
113
225
1129
Network Bandwidth in Kbps
319
1598
3194
16000
Virtual disk mode
Independent
persistent
Independent
persistent
Independent
persistent
Independent
persistent
Virtual disk format type

Thick lazyNote: Using thick eager-zeroed virtual disk reduces zeroed
delays the first time that a block is written to the disk
and ensures that all space is allocated and initialized
at creation time.
Note: FT requires thin disk to be converted to thick
eager-zeroed
Thick lazyzeroed
Thick lazyzeroed
Thick lazyzeroed
Additional HD space needed (on the server/SAN) to 10 GB

hold things like images, patchsets, mass
provisioning files, restore cd, etc
10 GB
10 GB
10 GB
vCPUs
vCPU Reservation
5000 MHz
5000 MHz
10000 MHz
20000 MHz
vCPU Limit
5000 MHz
5000 MHz
10000 MHz
20000 MHz
VM Memory [GB]
4 GB
4 GB
8 GB
8 GB
VM Memory Shares H=High N=Normal
VM Memory Reservation
4 GB
4 GB
8 GB
8 GB
VM Memory Limit
4 GB
4 GB
8 GB
8 GB
# vNICs
vCPU Shares
Table 24
OSVoice
H=High N=Normal
A31003-H8050-J100-09-7631, 09/2011
229
sw_install.fm
Deployment
OSVoice
OSVoice
OSVoice
VMware manual MAC used [Y/N]

Y
Note: Refer to the "Notes" listed below this table to
find the allowed MAC address range.
VMware VMotion supported [Y/N]
VMware High Availability supported [Y/N]
Snapshots
VMware Fault Tolerance supported [Y/N]
VMware Distributed Resource Scheduler (DRS)

supported [Y/N]
Required for
vMotion
Required for
vMotion
Required for
vMotion
Required for
vMotion
VMware Data Recovery supported [Y/N]
N (planned for
vApp)
N (planned for
vApp)
N (planned for
vApp)
N (planned for
vApp)
VMXNET3 virtual network adapter supported [Y/N]

Note: If supported please reference product specific
installation/configuration documentation section for
VMXNET3
N (planned for
vApp)
N (planned for
vApp)
N (planned for
vApp)
N (planned for
vApp)
Table 24
OSVoice
Notes:
230
OSV figures in the table indicate requirements for each node
OSV figures in the table are based on a typical Enterprise Feature set
OSV figures in the table are based on no Continuous tracing/distributed

registration/Nodes on Separate servers/Active-Standby mode
OSV NW and Disk usage may vary based on call usage and Feature mix
OSV cps (Calls per Second) formula = # of users*5/3600*5 (5 calls per user
per hour with a loading factor of 5 for features)
OSV NW Total Bandwidth KB/s Requirement formula = cps*46
OSV X-channel Bandwidth KB/s Requirement formula = cps*35
OSV HD KB/s formula = cps*3.25
OSV nodes are recommended to reside on separate physical servers for HW

redundancy. However, if both nodes are located on the same server the Xchannel traffic will not go out on the physical nw.
OSV uses additional disk space mainly for additional log and trace files (/
software directory).
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
The VMware manual MAC address range (as specified in the VMware
Configuration Guide) is 00:50:56:00:00:00-00:50:56:3F:FF:FF
(http://www.vmware.com/pdf/vsphere4/r40/vsp_40_esxi_server_config.pdf)
Table 25 lists the overhead requirements per physical system for the OSV V5
solution. Some values can not be defined because they are based on the
configuration of the host (physical) server.
Hardware
Description
Size
HD
VMware system disk

overhead
17 GB
HD
Overhead for swap space

for all unreserved VM
memory
This value cannot be strictly defined because it

is based on other VMs the customer may host
on the physical server that are not configured
to reserve all their (VM) memory.
HD
Overhead for snapshots if

used
The size of a snapshot can be calculated by

adding the sizes of the vmdk delta file, vmsn,
and vmsd file associated with that snapshot.
A snapshot contains all changes written to the
disk after that snapshot was taken (so the size
can 'increase' over time).
The total overhead required for snapshots will
also depend on the number of snapshots taken
and stored in that virtual machine datastore.
RAM
VMware system overhead 2.5 GB
CPU
VMware system overhead See the vSphere Resource Management

Guide
Table 25
Template for Virtualization Overhead Requirements per Physical

System for OSV V5 Solution:
A31003-H8050-J100-09-7631, 09/2011
231
sw_install.fm
4.3.3.3 Overview of the OSV Virtual Machine Solutions

Co-located One Physical Server:
3 subnets reserved for Admin, Billing, Signaling
Cross-over connected via virtual switch
Co-located Two Physical Servers:
Two Options for Subnets:
Three Subnets + one Private
Three subnets reserved for Admin, Billing, Signaling and one Private
for Cross-over
Cross-over cable connection between the nodes
Four Subnets
Four Subnets reserved for Admin, Billing, Signaling and Cross-over
Cross-over connectivity occurs through a layer 2 switch
Geo/Network-Separated Two Physical Servers:
Four Subnets per node for a total of eight subnets total
Four Subnets reserved for Admin, Billing, Signaling and Cross-over for
node 1.
Four Subnets reserved for Admin, Billing, Signaling and Cross-over for
node 2.
4.3.3.4 Virtual Machine Network Requirements

The OSV requires that 4 Ethernets be presented to it as labels during virtual
machine creation. Each of these labels needs to be in a different subnet as
presented to the OSV. These subnets are used in building the node.cfg file.
These are:
232
Admin subnet - used for admin/maintenance information
Signaling subnet - used for SIP/CSTA/MGCP signaling
Cross Connect - used for call state synchronization.
For the case of a co-located on the same host, this is a Vswitch only
connection.
For co-located systems on separate hosts it is a direct gigabit quality

Ethernet cable cross connect.
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
In the case of a geo-separated system it can be either a L2 bridged

connection or a L3 routed connection.
Billing subnet - This is used for sending CDRs to the billing server.
The connection of the labels to the real network is dependant on the customer
network configuration. This can be a flat or segmented network and can also use
the VMware VLAN capability. VMware network interface redundancy can also be
used if required.
The exception to this is the cross connect link which due to the heavy traffic
carried and the L2 nature of co-located or L2 bridged geo-separated connections
should be a dedicated link.
The Ethernets must be created as type E1000 in the virtual machine.
The Survival Authority shutdown agent configuration is installed with the
OpenScape Voice image and will be verified as part of the installation.
4.3.3.5 .Virtual Machine Memory Requirements

Refer to Section 4.3.3.2, Virtual Machine Configuration Parameters Overview
and the VMware Resource Management Guide for additional memory required
for Virtual machine overhead.
4.3.3.6 Virtual Machine CPU Requirements

Refer to Section 4.3.3.2, Virtual Machine Configuration Parameters Overview
and the VMware Resource Management Guide for Virtual CPU requirements.
4.3.3.7 Virtual Machine Disk Requirements

The OSV requires that the virtual machine present a single SCSI disk on target
(0:0). The virtual machine disk size should be 140 GB. VMware requires an
additional 40 GB over and above the virtual machine disk size.
The host server disk drive should be at least 180 GB for a single OSV virtual
machine on a dedicated server (140 GB + 40 GB).
The host server disk drive should be at least 320 GB for a co-located OSV
virtual system on one physical server (140 Gb + 140 Gb + 40 GB).
Calculations for the physical HD sizing including allowances for VMware and ISO
images are based on the following;
New Image + old Image during upgrade: 10 GB
restore CD: 100 MB
A31003-H8050-J100-09-7631, 09/2011
233
sw_install.fm
Allowed for VMware machine overhead: 3 GB (140 GB VM disk size)
Allowed for VMware system disk overhead: 17 GB
Note: The calculations for the physical HD sizing does not include space that
would be needed for snapshots or other swap space for other VMs that do not
reserve their memory.
The virtual SCSI controller must be type LSI Logic parallel.

The physical disks can be onboard the host or connected by SAN. Any level of
raid can be used.
Disk reservation parameters should be left as their default. The virtual SCSI
controller must be type LSI Logic parallel.
4.3.3.8 Other Parameters to Consider for the Virtual Machine

Most other parameters should be left as their default. The exceptions are:
234
Hyperthreading should be turned on if it is available.
The CDROM must be on virtual device node IDE(0:0)
For ease of installation the CDROM should be set to connect on power on.
For ease of installation the force BIOS flag on next reboot should be set in the
boot options.
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
4.3.4 Creating a Node.cfg File

Note: In OpenScape V5 Source-Based IP Routing is implemented. If route
OK button should be selected. For more information regarding the SourceBased IP Routing feature as it applies to installations, refer to Section 2.4,
Source Based Routes.
The node.cfg file is used by the installation process to determine which image will
be installed on your OpenScape Voice server. The determination is based on the
platform you select. For V5R0 Virtual machines:
The default Hardware Platform is the Virtual-OSV
The default Configuration is Standard-Duplex
After completing steps 1 through 6 of this procedure refer to Section 2.5,

Creating a Node.cfg File, on page 35 to complete the node.cfg. In Section 2.5,
complete steps 4 through 13. Be sure to take note of where the node.cfg file is
saved in step 13. Skip steps 14, 15 and 16. When Section 2.5, steps 4 through
13 are complete return to Section 4.3.4.1, Creating a Virtual Floppy Disk, on
page 237 of this procedure. Any questions regarding the node.cfg creation should
be addressed to your next level of support.
Preparation of the node.cfg files using a Linux Environment
Using the ISO image for the NCPE Wizard, create a DVD-R disk of the latest
HIQ8k-LiveCD-OfflineWizard.
Mount the DVD on a Linux system and access the DVD.
If needed, export the DISPLAY of the output to your PC by entering export

DISPLAY=<IP address>:0 where the IP address of the destination of the
DISPLAY is to be sent is used. This step is done as the root user.
Change directory /ncpe/bin and start the wizard by entering ./ncpe. The
Installation Framework options screen appears.
On the Installation Framework options screen, select Install and click Next.
The Configuration and Hardware (1/1) page will be presented. Select the
Hardware Platform Virtual-OSV. This selection sets the value of Configuration
to Standard-Duplex.
A31003-H8050-J100-09-7631, 09/2011
235
sw_install.fm
Refer to Section 2.5, Creating a Node.cfg File, on page 35 for further details
regarding the node.cfg creation. Complete Section 2.5, steps 4 through 13.
When Section 2.5, steps 4 through 13 are complete return to Section 4.3.4.1,
Creating a Virtual Floppy Disk, on page 237 of this procedure. Any
questions regarding the node.cfg creation should be addressed to your next
level of support.
Preparation of the node.cfg files using a Windows Environment.
Using the ISO image for the NCPE Wizard, create a DVD-R disk of latest
HIQ8k-LiveCD-OfflineWizard.
Insert the DVD in the DVD drive and the NCPE will automatically start. The
Installation Framework options screen appears.
On the Installation Framework options screen, select Install and click Next.
The Configuration and Hardware (1/1) page will be presented. Select

Hardware Platform Virtual-OSV. This selection sets the value of Configuration
to Standard-Duplex.
Refer to Section 2.5, Creating a Node.cfg File, on page 35 for further details
regarding the node.cfg creation. Complete Section 2.5, steps 4 through 13.
When Section 2.5, steps 4 through 13 are complete return to Section 4.3.4.1,
Creating a Virtual Floppy Disk, on page 237 of this procedure. Any
questions regarding the node.cfg creation should be addressed to your next
level of support.
Attention: The user has a choice of installing the Image via a virtual floppy that
includes the node.cfg or with a CD ISO image that can include the node.cfg and
any released patch sets that may not be included with the delivered Image.
To install using a virtual floppy refer to Section 4.3.4.1, Creating a Virtual Floppy
Disk and Section 4.3.4.2, Saving the node.cfg File to Virtual Floppy Files.
To install with a CD ISO image, which will allow patch sets to be installed
automatically as part of the Image installation process, proceed to Section
4.3.4.3, Saving the node.cfg File and Patchsets to a CD ISO Image.
236
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
4.3.4.1 Creating a Virtual Floppy Disk

For the Windows OS there are special imaging software packages, e.g.
winImage, which would create a virtual floppy file which can be used in VMware
ESXi server. The following is an example of creating a virtual floppy in the Linux
environment.
1. As root user type the following commands:
dd if=/dev/zero of=/tmp/Node1.flp bs=1024 count=1024
mkfs.msdos /tmp/Node1.flp
cp /tmp/Node1.flp /tmp/Node2.flp
This will create two virtual floppy devices under the /tmp directory named
Node1.flp and Node2.flp. A snapshot of the commands and results follow;
root@fsc501:[/tmp] #216
# dd if=/dev/zero of=/tmp/Node1.flp bs=1024 count=1024
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.004398 seconds, 238 MB/s
# mkfs.msdos /tmp/Node1.flp
mkfs.msdos 2.11 (12 Mar 2005)
# cp /tmp/Node1.flp /tmp/Node2.flp
# ll /tmp/Node*
-rw-r--r-- 1 root root 1048576 Feb 17 17:35 /tmp/Node1.flp
-rw-r--r-- 1 root root 1048576 Feb 17 17:35 /tmp/Node2.flp
4.3.4.2 Saving the node.cfg File to Virtual Floppy Files

Copy the node.cfg file created in Section 4.3.4 to the /tmp directory. As root user
type the following commands:
For Node 1:
mount -o loop /tmp/Node1.flp /media/floppy
cp node.cfg.primary /media/floppy/node.cfg.primary
A31003-H8050-J100-09-7631, 09/2011
237
sw_install.fm
umount /media/floppy
For Node 2:
mount -o loop /tmp/Node2.flp /media/floppy
cp node.cfg.secondary /media/floppy/node.cfg.secondary
umount /media/floppy
The Node1.flp and Node2.flp files are now ready for transfer to the datastore.
Note: Please refer to the Uploading to the Datastore section in Section 4.3.6.2 on
page 240 for instruction on uploading a file to the datastore.
Proceed to Section 4.3.5, Preparation of the Image DVDs.
4.3.4.3 Saving the node.cfg File and Patchsets to a CD ISO

Image
A CD ISO image which includes the appropriate node.cfg file and patch sets
(including emergency patch sets) may be employed for the image installation.
For the installation this CD ISO image has to be created with the same structure
as a native machine USB stick (as described in Section 2.6, Loading Patch Sets
onto the USB Memory Sticks);
1. The node.cfg file(s) should be generated as per the instructions in Section
4.3.4, Creating a Node.cfg File. There is no need to create virtual
floppies for the CD ISO image procedure.
2. The root level directory on the CD ISO image should contain the
node.cfg.primary file for node1.
3. An empty file, dev.8kps, should be under the /patch directory.
4. The patch sets and the emergency patch sets should be in the patch directory.
Generally, this means all the tar files in the latest cumulative patch set and the
tar files of the emergency patch sets related to the cumulative patch set. For
example, if the latest image brings the system to PS07.E02 and cumulative
PS09 needs to be installed as part of the image installation, then only the
PS08 and PS09 tar files need to be in the patch directory.
Note: If cumulative patch sets are not available, tar files of the regular patch
sets can be placed in the patch directory as well as the related tar files of the
emergency patch sets. The standard naming convention of the patch sets
should be maintained.
5. Generate the CD ISO image. The generation of the CD ISO image is outside
the scope of this document.
238
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
6. For a duplex configuration, repeat this procedure for node 2. This CD ISO
should contain the node.cfg.secondary file in the top level of its structure.
Attention: Name the CD ISO image appropriately to ensure that the proper
ISO image is selected for the image install; Sample naming convention:
- Node 1 CD ISO filename: CD_N1.iso
- Node 2 CD ISO filename: CD_N2.iso
The CD ISO image is now ready for transfer to the datastore. Section 4.3.6.2 on
page 240 contains instructions for uploading a file to the datastore.
Any questions regarding the CD ISO image creation process should be
addressed to your next level of support.
If the Installation and Upgrade Guide is followed, the OSC Voice iso and node.cfg
will already be prepped when Section 4.3.7.7, Loading the Image on the VMware
Guest Machine is performed.
Section 4.3.7.4, Preparation of the VMware Guest Machines - One Physical

Server Solution, on page 256, step 14 provides instruction on how to add a
virtual CD/DVD device for the OSC Voice iso file.
Section 4.3.7.6, Adding a CD/DVD drive to the virtual machine, on page

268, provides instruction on how to make this node.cfg ISO available on a
virtual CD/DVD device.
Section 4.3.7.7, Loading the Image on the VMware Guest Machine, on page
274, step 7, provides the instructions necessary to include this CD ISO in the
image install process.
A31003-H8050-J100-09-7631, 09/2011
239
sw_install.fm
4.3.5 Preparation of the Image DVDs

Installation via virtual floppy and DVD image (no physical media) are supported
only.
Currently only imaging DVDs version V4_R1.29.3_03_IMG.iso and above
support Virtualization.
Note: Please refer to the Uploading to the Datastore section in Section 4.3.6.2 on
page 240 for instruction on uploading a file to the datastore.
4.3.6 VMware vSphere Client

4.3.6.1 Configuration of Login Credentials in VMware vSphere
Client
Proceed as follows:
1. Open the VMware vSphere Client and Enter the Login Credentials:
Enter the IP address/Name: Management IP of the Virtual server or

VCenter server serving the host machine.
Enter the User name: root (or VCenter login)
Password: Password creation is optional when installing the VMware. If a

VMware password was created it must be entered here.
2. Select Login.
4.3.6.2 Uploading a file to the Datastore

1. Select the Summary tab of the Virtual Machine.
2. On the Summary tab of the Virtual Machine right click on the datastore and
choose Browse Datastore. As shown below:
240
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
3. Select the root directory and click on the following icon to create a logical
folder under the datastores root / directory called images:
Note: This folder can be named anything you choose.
Enter the new name (e.g. "images") for the directory in the New Folder
window.
Click the OK button to confirm the name.
4. Select the new directory and click on the "Upload File" icon to upload a file.
Select Upload File...
Select a file from the next dialog and click Open to initiate the
transfer to the datastore.
A31003-H8050-J100-09-7631, 09/2011
241
sw_install.fm
Note: This procedure needs to be done for the Image ISO as well as the
Virtual Floppy Disks.
If 1 Physical Server is being used upload the following files to the

images directory of the datastore;
Image.iso
Node1.flp
Node2.flp
If 2 Physical Servers are being used then upload the following files to the
images directory of the node 1 datastore:
Image.iso
Node1.flp
Then upload the following files to the images directory of the node 2
datastore;
Image.iso
Node2.flp
Note: Items in the datastore can easily be modified by right clicking on an item
and choosing the appropriate operation from the context menu presented.
242
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
4.3.7 Preparation of the VMware Virtual Switches

4.3.7.1 Examples of Physical Server NIC to VMNIC Mapping for
IBM x3550 M2/M3, FSC RX330 & FTS RX200 Server
Note: The following charts map 8 VMNIC ports to the physical servers NICs. The
virtual OSV system only supports 4 Ethernet ports. It is suggested that the first 4
VMNIC ports be employed for the virtual machine port mapping.
FTS RX200 and IBM x3550M2/M3 server NIC to VMNIC mapping is as

follows:
Port
Vmnic0
Vmnic1
Vmnic2
Vmnic3
Vmnic4
Vmnic5
Vmnic6
Vmnic7
Table 26
FTS RX200 and IBM x3550M2/M3 Network Interface to VMNIC

mapping
Suggested mapping for a FTS RX200 or IBM x3550M2/M3 virtual installation;

VMNIC
Subnet Label
x3550M2 Physical NIC
VMNIC0
admin_primary
VMNIC1
signaling_primary
VMNIC2
billing_primary
VMNIC3
cross_connect_primary
3 (depending on the configuration this may not

be used)
FSC RX330 server NIC to VMNIC mapping is as follows

Port
Table 27
vmnic0
Vmnic1
Vmnic2
Vmnic3
Vmnic6
Vmnic7
Vmnic4
Vmnic5
FSC RX330 Network Interfaces to VMNIC mapping
Suggested mapping for a FSC RX330 virtual installation;

VMNIC
Subnet Label
RX330 Physical NIC
VMNIC0
admin_primary
VMNIC2
signaling_primary
VMNIC3
billing_primary
VMNIC1
1 (depending on the configuration this may

not be used)
A31003-H8050-J100-09-7631, 09/2011
243
sw_install.fm
4.3.7.2 Preparation of the VMware Virtual Switches: Two

Physical Servers Setup (Co-Located or Geo-Separated)
Note: This mapping is a one-to-one representation of what is presented in the
Installation and Upgrade Guide (IUG), A31003-H8040-J100-10-7631, for the
Ethernet NICs on an IBM x3550M2 duplex. The Port Names are a logical
association. For example: VMNIC7 will be used as the Ethernet interface to our
VM ESXi servers management interface. This interface would be chosen during
the VMWare installation.
For a co-located system running on 2 physical servers the Crossover

interconnect must be a direct or bridged unrouted physical connection.
The user can define any VMNIC association with a subnet label. For example,
the user could choose to make VMNIC1 the admin_primary and VMNIC5 the
signaling_primary; however for illustration purposes, the procedures in this
document will use the mapping defined below. The following is the virtual
machine to physical Ethernet port mapping for a x3550M2 platform (taken from
section "FTS RX200 and IBM x3550M2/M3 server NIC to VMNIC mapping is as
follows:", on page 243).
244
VMNIC
Subnet Label
x3550M2 Physical NIC
VMNIC0
admin_primary
VMNIC1
signaling_primary
VMNIC2
billing_primary
VMNIC3
3 (depending on the configuration this

may not be used)
VMNIC7
Management Network interface
7 (chosen during VMware install)
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Configuring the Virtual Switches

Proceed as follows to configure the virtual switches:
1. Select the ESXi servers Management IP address (see red ellipse in figure
below) and click on the Configuration tab (see green ellipse).
2. Select Networking (see blue ellipse in figure above) in the Hardware menu.
3. Initially, configure one Virtual Switch which the ESXi Management interface
will be associated with (see black ellipse in figure above).
Note: Co-Located with one Physical Server setup is a special case. Please
follow the procedures in Section 4.3.7.3, Preparation of the VMware Virtual
Switches: Co-Located with one Physical Server, on page 249.
4. Add four More Virtual Switches by clicking on the Add Networking... option
located in the top right segment as shown below:
A31003-H8050-J100-09-7631, 09/2011
245
sw_install.fm
The Add Network window appears:
5. Select the Virtual Machine option for the connection type and click the Next
button.
The Virtual Machines - Network Access dialog appears.
246
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
6.
Click the Next button. The Add Network Wizard Connection Settings
dialog appears:
7. Enter admin_primary in the Network label field and click the Next button.
The Add Network Wizard Ready to Complete dialog appears.
8. Click the Finish button.

9. Repeat the steps 2 - 8 three more times to add the other subnets,
remembering to follow the order in Table 28. If you intend to use VMotion/HA
then the network labels used must be unique in your network. The names
below are only examples and are not mandatory.
A31003-H8050-J100-09-7631, 09/2011
247
sw_install.fm
Subnet
Network Label
vmnic0
admin_primary
vmnic1
signaling_primary
vmnic2
billing_primary
vmnic3
Table 28
Network Labels Primary Server
Example:
The following is an example of the completed VMware switch preparation:
10. Repeat the same procedure on the second physical server, naming the
interfaces (for example) as follows:
Subnet
Network Label
vmnic0
admin_secondary
vmnic1
signaling_secondary
Table 29
248
Network Labels Secondary Server
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Subnet
Network Label
vmnic2
billing_secondary
vmnic3
cross_connect_secondary
Table 29
Network Labels Secondary Server
4.3.7.3 Preparation of the VMware Virtual Switches: CoLocated with one Physical Server
Conduct the steps 2 - 8 described in Section 4.3.7, Preparation of the VMware
Virtual Switches, on page 243 three times to create the virtual switches for the
admin, signaling and billing.
Follow the procedure below for the cross-connect (shown in Section 4.3.7, steps
3 - 4):
1. Select the ESXi servers Management IP address and click on the
Configuration tab.
2. Select Networking in the Hardware menu.
3. Click on the Add Networking... option located in the top right segment.
The Add Network Wizard - Connection Type window appears:
A31003-H8050-J100-09-7631, 09/2011
249
sw_install.fm
4. Select the Virtual Machine option for the connection type and click the Next
button.
The Virtual Machines - Network Access dialog appears.
5. De-select vmnic3 and click on the Next button.

The Add Network Wizard Connection Settings dialog appears:
250
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
6. Enter cross_connect_primary in the Network label field and click the

Next button. The Add Network Wizard Ready to Complete dialog
appears.
7. Click the Finish button.

The following is an example of the completed virtual switches:
A31003-H8050-J100-09-7631, 09/2011
251
sw_install.fm
8. Since both the servers will be maintained on the same physical server,
connections for this server on the virtual switches have to be created. In order
to do this continue the configuration as follows:
Click on Properties for vSwitch1
The vSwtch1 Properties window appears.
9. Click on the Add... button.

The Add Network Wizard - Connection Type window appears:
252
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
10. Click on the Next button.
11. Enter admin_secondary in the Network label field and click the Next
button. The Add Network Wizard Ready to Complete dialog appears.
A31003-H8050-J100-09-7631, 09/2011
253
sw_install.fm
12. Click the Finish button. The vSwtch1 Properties window appears containing
the new connection.
13. Click the Close button.

14. Repeat the procedure for the remaining Virtual Switches, in turn creating:
254
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
signaling_secondary
billing_secondary
cross_connect_secondary
15. In the end your configuration should look like the following:
A31003-H8050-J100-09-7631, 09/2011
255
sw_install.fm
4.3.7.4 Preparation of the VMware Guest Machines - One

Physical Server Solution
Attention: The following values are presented as examples only. The values may
require adjustment based on a sites particular installation environment.
Attention: Mandatory settings for these steps in this section.

- NIC Adapter type for all configurations should be set to E1000 in step 8.
- The virtual disk drive should be set to SCSI 0:0 in step 12.
- The CD/DVD Virtual Device Node should be set to IDE (0:0) in step 15.
Attention: Default values should be used during the configuration process

unless specified otherwise. Using other than the default values may result in
unexpected behavior.
The Create New Virtual Machine wizard will be used to configure the virtualized
OSV installations. This procedure assumes that the Datacenter and Cluster are
already configured.
Select your Cluster (the cluster element is with in the red border in the following
figure.)
Access the Create New Virtual Machine wizard from the vSphere Client menu
after selecting your Cluster by one of two methods:
256
Right click the cluster icon and select "New Virtual Machine"
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Or from the vSphere Client Toolbar, select File New Virtual Machine
Note: These steps will be repeated for the creation of the second node as well so
first time through the procedure, conduct the steps indicated as Step 1 wherever
specified and when conducting the steps the second time around for Node 2
follow the steps indicated as Step 2 wherever specified.
Starting from the initial Create New Virtual Machine Wizard screen the following
are the steps to configure the system:
1. Configuration: Select Custom configuration, then select Next.
2. Name and Location: Enter the name for the new virtual machine
a) Step 1: Enter Node1, then select Next.
b) Step 2: Enter Node2, then select Next.
Note: Node1 or Node2 are user defined names.
3. Datastore: Select a data store with sufficient data size for the machine (see:
Section 4.3.1, Virtualization Overview, on page 223). After selecting the
datastore size select Next.
4. Virtual Machine Version: Select virtual machine version 7, then select Next.
5. Guest Operating System: Select Linux and version SUSE Linux Enterprise
10 (64 bit) , then select Next.
A31003-H8050-J100-09-7631, 09/2011
257
sw_install.fm
6. CPUs: Enter 4 for the number of virtual processors, then select Next.
Note: Except for the Enterprise Plus license the maximum number of CPU
available is 4. Licensing for VMware is the responsibility of the customer.
7. Memory: Set the memory size to 4 GB (5000 or less subscribers) or 8GB

(5001 to 100000 subscribers), then select Next.
8. Network: Select 4 Network adapters (NICs). Select the following choices
from the NIC drop down lists as indicated below;
a) Step 1
NIC1 admin_primary
NIC2 signaling_primary
NIC3 cross_connect_primary
NIC4 billing_primary
b) Step 2
NIC1 admin_secondary
NIC2 signaling_ secondary
NIC3 cross_connect_ secondary
NIC4 billing_ secondary
9. The order of the Network adapter to Network label is important and must
match the order shown in the screenshot below for all VMware installations.
After verifying the NIC configuration select Next.
258
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
10. SCSI Controller: use defaults, select Next.

11. Select a Disk: Select Create a new virtual disk. Select Next. The Create a
Disk window appears:
Create a Disk: For the Capacity parameter select a Disk Size of 140 GB,
A31003-H8050-J100-09-7631, 09/2011
259
sw_install.fm
use the default selections for the remaining choices.
12. Select Next. The Advanced Options window appears.
Advanced Options: use the default values.
13. Select Next. The Ready to Complete window appears.
260
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Ready to Complete: The configuration summary of the new virtual

machine is displayed.
Check the Edit the virtual machine settings before completion checkbox
as shown.
14. Select Continue. The Virtual Machine Properties window appears.
A31003-H8050-J100-09-7631, 09/2011
261
sw_install.fm
Select the Hardware tab.
In the Hardware tab, select New CD/DVD
Select Datastore ISO File and browse to the previously downloaded

OpenScape Voice ISO image to be installed.
Select the Connect at power on checkbox under Device Status.
Change the Virtual Device Node to IDE (0:0)
15. New licenses are required based on the MAC address of the eth0 port. This
corresponds to the ADMIN port. It is suggested a fixed MAC address be
employed for this, as VMware will generate a different MAC address if the
virtual machine is deleted and recreated. This step may also be accomplished
during the network setup phase of building the virtual network.
262
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Select the New Nic device that corresponds to the admin port. Click on
the manual button in the MAC address for the ADMIN port. You can set
the last 3 blocks of digits, the 00:50:56 is fixed. The VMware manual MAC
address range (as specified in the VMware Configuration Guide) is
00:50:56:00:00:00-00:50:56:3F:FF:FF
(http://www.vmware.com/pdf/vsphere4/r40/
vsp_40_esxi_server_config.pdf)
Attention: Be sure to repeat the process for node 2 of a duplex system. The
MAC addresses of node 1 and node 2 must be unique (they can not be
identical).
16. Select the Options tab.
A31003-H8050-J100-09-7631, 09/2011
263
sw_install.fm
In the Options tab select Boot Options.
Set Power-on Boot Delay to 5000
Check the Force BIOS Setup checkbox
17. Select the Resources tab.
264
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
In the Resources tab select CPU.
Note: Settings are based on values from Table 24 on page 228, Virtual
Machine Computer (minimum) Requirements for OpenScape Voice with
OpenScape UC Suite V5. Any questions should be addressed to your next
level of support.
For this example, 4 vCPUs were selected in Step 6 on page 258.
Set Shares to High.
Verify Reservation is set to 10000 MHz.
Verify the Unlimited checkbox is NOT selected.
18. In the Resources tab, select Memory.
Note: Setting are based on values fromTable 24 on page 228, Virtual

Machine Computer (minimum) Requirements for OpenScape Voice with
OpenScape UC Suite V5. Any questions should be addressed to your next
level of support.
If 4 GB of memory was allocated in step 7 on page 221,
Shares should be set to Normal.
Verify that Reservation is set to 4 GB.
Verify that Limit is set to 4 GB.
Verify that the Unlimited checkbox is NOT selected.
If 8 GB of memory was allocated in step 7 on page 221,
Shares should be set to Normal.
A31003-H8050-J100-09-7631, 09/2011
265
sw_install.fm
Verify that Reservation is set to 8 GB.
Verify that Limit is set to 8 GB.
Verify that the Unlimited checkbox is NOT selected.
Verify the Unlimited checkbox is selected.
19. Click Finish to create the new VM. VMs will appear on the left hand side of
the vSphere Client dialog, e.g. Node 1.
20. Repeat the Steps of Section 4.3.7.4 following Step 2 wherever specified in
order to create the Node2 VM.
266
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
4.3.7.5 Preparation of the VMware Guest Machines - Two

Physical Server Solution
Attention: The following values are presented as examples only. The values may
require adjustment based on a sites particular installation environment.
Note: In order to save space and not repeat the equivalent steps from Section
4.3.7.4, Preparation of the VMware Guest Machines - One Physical Server
Solution, setup we will only specify the differences, that must be conducted in
order to create the 2 Physical Server Solutions VM nodes, here.
Note: First time through Section 4.3.7.4 you will create Node1 and second time
through, Node2 will be created. Please follow the step specified as Step 1
wherever indicated first time through and the step specified as Step 2 second
time through the procedure.
Differences
Step 7 from Section 4.3.7.4 should be changed as follows for this section:
Memory: Set the memory size to 4 GB (5000 or less subscribers) or 8GB

(5001 to 100000 subscribers).
Step 18 from Section 4.3.7.4 should be changed as follows for this section:
Verify Reservation is set the same as the VM memory was configured in

step 7 of this procedure. In the step 7 example 4 GB is reserved.
Note: Reserve 4 GB (5000 or less subscribers) or 8 GB (5001 to 100000
subscribers).
A31003-H8050-J100-09-7631, 09/2011
267
sw_install.fm
4.3.7.6 Adding a CD/DVD drive to the virtual machine

This section can be employed to make a node.cfg ISO file available on a virtual
CD/DVD device. Section 4.3.7.4, Preparation of the VMware Guest Machines One Physical Server Solution, step 14, provides instruction to add a virutual CD/
DVD device for the OSC Voice iso file. If you are following the Installation and
Upgrades Guide, Section 4.3.7.4, Preparation of the VMware Guest Machines One Physical Server Solution, step 14 should already be complete.
Attention: This procedure must be completed on both nodes of a duplex system.
1. Access the vSphere client.
268
Select the appropriate node
Select the Resource Allocation tab
Select Edit in the CPU (or Memory) window
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
2. The Virtual Machine Properties window is displayed, select the Add button.
3. The Add Hardware Device Type window is presented.
On the Add Hardware Device Type window select/highlight CD/DVD Drive.
A31003-H8050-J100-09-7631, 09/2011
269
sw_install.fm
4. Select the Next button. The Add Hardware CD/DVD Media Type window is
presented;
Select the Use ISO image radio button.

5. Select the Next button. The Add Hardware Select ISO Image window is
presented;
270
Browse to and select the appropriate ISO image for this activity.
Do NOT select the Connect at power on radio button.
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
6. Select the Next button. The Add Hardware Specify Advanced Options
window is presented;
The expected value of Virtual Device Node is IDE (0:1). Typically this is the
default value.
7. Select the Next button. The Add Hardware Ready to Complete window is
presented;
Verify the options settings are listed correctly. Refer to the snapshot
above.
If any options are different than those presented here use the Back button
to update that option accordingly and then return to this page. It is a good
practice to verify the options once more (the best check is a double
check).
A31003-H8050-J100-09-7631, 09/2011
271
sw_install.fm
8. After verifying the options are correct select the Finish button. The Virtual
Machine Properties window is presented. The new CD/DVD should now
be present in the Hardware list.
272
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
9.
If you return to the vSphere top level and select Edit in the CPU (or Memory)
window the Virtual Machine properties are displayed as;
Attention: This procedure must be completed on both nodes of a duplex system.
A31003-H8050-J100-09-7631, 09/2011
273
sw_install.fm
4.3.7.7 Loading the Image on the VMware Guest Machine

Attention: After the node 1 install is started (steps 1 through 10), proceed with
the installation of node 2 promptly, so that node 1 and 2 will synch during the
install process. Be sure to select the appropriate virtual floppy for node 2.
1. Power on the guest machines just created.
2. Open up the vSphere Clients Console tab, click in the console window and
hit return to connect to the guest Linux environment OSV will run in. At this
point the BIOS screen should appear. Verify/update the System Date and
Time.
Note: To switch between the WMware console window and desktop
environments;
- click into the Console window to enter the Console.
- CTRL-ALT will leave the Console.
274
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
3. Select the BIOS screens BOOT tab and move the CD ROM to the top of the
list and the Floppy to the second position.
A31003-H8050-J100-09-7631, 09/2011
275
sw_install.fm
4. Press the Esc key to exit this menu, then select Exit Saving Changes. In the
Setup Confirmation window select Yes to Save configuration changes and
exit now?.
276
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
5. Select Install Softswitch - V5.0 and press Enter when the boot screen with
the following options is shown:
Boot from Hard Disk
Install Softswitch - V5.0
The End User License Agreement (EULA) is displayed in a new window on

the console screen.
6. Review and accept the EULA as follows:

a) Review the EULA using the Page Up/Page Down or arrow keys; when
you are finished reviewing the EULA, select Done and press the Enter
key.
A window is opened with the question: Do you accept the License
Agreement? with the options Yes and No.
b) In the EULA acceptance window, use the Tab or arrow keys to select Yes
to proceed with the image installation. Selecting No will halt the image
installation. If you select No by mistake, to continue with the image
installation, reboot the server and when prompted to accept the EULA
select Yes.
7. The Installation will wait for the node.cfg.primary|secondary. At this point the
appropriate procedure must be followed so that the Image installation may
continue;
A31003-H8050-J100-09-7631, 09/2011
277
sw_install.fm
Follow step 7a if the node.cfg has been saved to a Virtual Floppy File.
Follow step 7b if the node.cfg (and patchsets) has been saved to a CD

ISO Image.
a) Follow this step if the node.cfg has been saved to a Virtual Floppy File.
After step 7a is complete proceed to step 8.
Attention: If the node.cfg (and patchsets) have been saved to a CD ISO
Image skip step 7a and proceed to step 7b.
Exit VM capture (CTRL+ALT),
Click on the floppy icon on the vSphere UI,
Choose the Floppy Drive icon and from its sub-menu select Connect
to floppy image on a datastore as shown below:
Now proceed to step 8.
b) Follow this step if the node.cfg (and patchsets) have been saved to a CD
ISO Image.
After step 7b is complete proceed to step 8.
Attention: If the node.cfg has been saved to a Virtual Floppy Files follow
step 7a.
278
Exit the VM console capture (CTRL+ALT),
Click on the CD/DVD icon, select CD/DVD Drive 2 and from its submenu select Connect to ISO image on a datastore as shown
below:
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Now proceed to step 8.
8. Navigate the datastore to the Virtual Floppy file or CD ISO file. Choose the
appropriate file and select OK (two example snapshots follow).
Virtual Floppy file selection;
A31003-H8050-J100-09-7631, 09/2011
279
sw_install.fm
CD ISO file selection;
9. Press Done on the Network Information page, which is displayed as soon

as the appropriate Virtual Floppy with the node.cfg is mounted.
10. Type yes and press enter as shown below and the Image installation will start.
280
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Repeat steps 1 through 10 of Section 4.3.7.7 for Node 2; making sure to

select the appropriate virtual floppy which contains the
node.cfg.secondary.
Note: For specific details of the Image installation please refer to the
Release Notes of the Image DVD.
11. The installation completes.

The installation process is completed when messages similar to the following
example are displayed on the Console monitor:
Image Status: Completed installation at <Day MM Date hh:mm:sec
Timezone Year>
System verification
done
Master Resource Control: runlevel 3 has been
reached
A31003-H8050-J100-09-7631, 09/2011
281
sw_install.fm
Skipped services in run level 3:
acpid nfs
Authorized uses only. All activity may be monitored and

reported.
<hostname> login: 0: OK Command execution
The text "OK Command execution" appears on the Console monitor in a simple
installation or only on one of the Console monitors in a duplex installation. During
the imaging process, there are times when the above message appears before
the server is rebooted. Please ignore this message. Wait for the message to
appear after the "logon" prompt on the Console monitor.
Note: To clarify the "Image Status" text layout, an example is presented:
Image Status: Completed installation at Tue Dec 21 13:31:13 EST 2010.
282
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
4.3.8 Virtual Machine Post Installation Best Practices

4.3.8.1 Increasing Node Boot-Up Speed
After the installation completes, several steps can be taken to speed up the Node
Boot-Up time if the servers were ever rebooted.
1. Disconnect the CD/DVD device and prevent it from connecting during boot.
a) First click the nodes Edit Virtual Machine Settings and select the CD/DVD
Drive where the Image ISO was connected.
b) Uncheck the Connected and Connect at power on checkboxes inside
device status.
2. Select the Options tab.

a) Select Advanced, Boot Options.
b) Set the Power-on Boot Delay time value to 1000.
3. Click the OK button.
4. Repeat steps 1 through 3 on the other node.
A31003-H8050-J100-09-7631, 09/2011
283
sw_install.fm
Post Software Installation Activities
5. On the OpenScape Voice Installation Checklist, in Section 2.2.4, OpenScape

Voice Installation Checklist, on page 24, initial step 9 and proceed to step 10.
Perform the tasks required for your installation environment.
4.4 Post Software Installation Activities

4.4.1 Verify Remote Access for srx Account in a
Standard Duplex
Standard duplex OpenScape Voice configurations employ an External (offboard)
Applications Server. Verify the Voice servers /etc/security/access.conf file is
configured to allow remote access for user srx from the External Applications
server. This activity needs to be performed on both nodes. An example follows:
The access.conf file should be changed from this:
-:root srx:ALL EXCEPT <list of allowed devices which should be the nodes,
the console, and ttys>
To this:
-:root:ALL EXCEPT <list of allowed devices which should be the nodes, the
console, and ttys>
-:srx:ALL EXCEPT < IP address of external machine and the list of allowed
devices which should be the nodes, the console, and ttys>
Note: The IP address in the list (for example: IP address of external assistant
machine) is a numeric address (for example: 165.218.177.242).
4.4.2 Changing the User ID and Password for the IMM/

iRMC Account
Note: Please note that the Virtual OSV has no maintenance controller interfaces
(RSA, IMM, iRMC, VMK).
Change the default user ID (USERID) and password (PASSW0RD, the 0

character is the number zero) for the IMM (IBM x3650T and IBM x3550 M2/M3)
or iRMC (FTS RX200 and FSC RX330) account as follows (execute these steps
on each node):
284
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
1. Log in as user root.

2. The sa_ipmi.cfg file is read to update the maintenance controller user ID and
password. Edit the sa_ipmi configuration file (/etc/opt/SMAW/SMAWhaext/
sa_ipmi.cfg) to update the default user ID and password. Change only the
user ID and password. Be sure to edit the file on both nodes in a redundant
system.
Note: There should be four entries (TestLocalStatus, retryPonCnt, info for
Node1, and info for Node2) in the sa_ipmi.cfg file. If there are more than two
entries for node info, the survival operation will not succeed in the case of a
node failure.
root@fsc301:[/etc/opt/SMAW/SMAWhaext] #836
# cat sa_ipmi.cfg
TestLocalStatus
retryPonCnt 2
fsc301 10.235.22.20:USERID:PASSW0RD cycle
fsc302 10.235.22.21:USERID:PASSW0RD cycle
An example of an edited sa_ipmi.cfg file follows:
# cat sa_ipmi.cfg
TestLocalStatus
retryPonCnt 2
fsc301 10.235.22.20:fsc30:iRMCpsw cycle
fsc302 10.235.22.21:fsc30:iRMCpsw cycle
3. Change the user ID and password in the maintenance controller with the
following commands (snapshot of command result included):
A31003-H8050-J100-09-7631, 09/2011
285
sw_install.fm
# cd /unisphere/srx3000/callp/bin
root@fsc301:[/unisphere/srx3000/callp/bin] #846
# ./rsaConfig -v
Host name for this node is: fsc301
hardware platform is RX330
Retrieving rsa configuration for node 1
rsa_enabled = 'YES'
Found IPMI parameters for this node =
'10.235.22.20:fsc30:iRMCpsw'
IP address from SA_ipmi = 10.235.22.20
Username from SA_ipmi = fsc30
Password from SA_ipmi = iRMCpsw
platform type=RX330, user number=2, access level=5 channel
number=2
Configuration Data to be written to the BMC
Network Data:
Interface IP Address: 10.235.22.20
Network Mask: 255.255.255.0
Default Gateway Address: 10.235.22.1
Login Data:
User Name: fsc30
Password: iRMCpsw
Successfully set Username
Successfully set Password
Successfully set User Access
Successfully set User Enable
Successfully set IP address
Successfully set IP Netmask
Successfully set IP source
Successfully set Default Gateway
Successfully set the Service LAN interface
Successfully disabled LDAP
Successfully set Force HTTPS
Successfully disabled DHCP Registration
Successfully disabled DNS
Note: This snapshot is from a FSC RX330 platform and also applies to the
RX200 platform. An IBM x3650t, x3250 M2/M3 or x3550 M2/M3 platform
response is complete when Successfully set Default Gateway" is
output.
4. Verify the new configuration. Refer to Section 6.7, Verifying the Shutdown
Agents Configuration, on page 418.
4.4.3 Configuring the Ethernet NICs for Fixed

Operation
By default, Ethernet NICs are set to auto-negotiate interface speed and mode.
286
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
If the customers LAN equipment does not support auto-negotiation, the Ethernet
NICs have to be set to the interface speed and mode appropriate for the
customers LAN.
Only the interfaces that are directly connected to the customers LAN need to be
changed; the Ethernet NICs that are used for the cluster crossovers do not need
to be changed since they are not in direct contact with the customers LAN.
The supported fixed operation speeds and modes are as follows:
100BaseTx-FD
1000BaseTx-FD
Disable auto-negotiation and set the Ethernet NICs for fixed operation as follows:
1. Log in as root.
2. Create a Linux text file named etherset in the /etc/init.d directory and enter
the text as follows:
Note: This step employs the configuration of a duplex x3650T server as an
example. Only the interfaces that are directly connected to the customers
LAN should be changed.
Simplex server configuration;
- For the IBM x3650T configure eth0, eth1, and eth2.
- For the FSC RX330 configure eth0, eth2, and eth3.
- For the IBM x3550 M2/M3 configure eth0, eth1, and eth2.
- For the FTS RX200 configure eth0, eth1, and eth2.
The Ethernet assignments for a duplex server follow. The Ethernet NICs that
are used for the cluster crossovers do not need to be changed.
- IBM x3650T employs eth2 and eth4 as the cluster interconnects.
o For the x3650T case configure only eth0, eth1, eth3, eth5, eth6 & eth7.
- FSC RX330 employs eth1 and eth5 as the cluster interconnects.
o For the RX330 case configure only eth0, eth2, eth3, eth4, eth6 & eth7.
- IBM x3550 M2/M3 employs eth3 and eth7 as the cluster interconnects.
o For the x3550 M2/M3 case configure only eth0, eth1, eth2, eth4, eth5, &
eth6.
- FTS RX200 employs eth3 and eth7 as the cluster interconnects.
o For the FTS RX200 case configure only eth0, eth1, eth2, eth4, eth5, &
eth6.
#!/bin/bash
### BEGIN INIT INFO
# Provides: etherset
A31003-H8050-J100-09-7631, 09/2011
287
sw_install.fm
# Required-Start: network
# Required-Stop:
# Default-Start: 3 5
# Default-Stop:
# Description: Configure the network interfaces
### END INIT INFO
echo begin etherset
ethtool -s eth0 speed
ifconfig eth0 up
ifconfig eth1 up
ifconfig eth3 up
ifconfig eth5 up
ifconfig eth6 up
ifconfig eth7 up
echo end etherset
exit 0
100 duplex full autoneg off

In this example, the speed is set to 100, with full duplex operation, and auto
negotiation turned off. For 1000BaseTx, specify speed 1000.
3. Set the Ethernet interfaces to the values specified in the etherset file with
following commands:
cd /etc/init.d
chmod +x /etc/init.d/etherset
insserv etherset /etc/init.d/etherset
/etc/init.d/etherset
4. If applicable, repeat steps 1 on page 287 through 3 on the other node.
step 14.
4.4.4 Checking Ethernet Port Assignments

Check the Ethernet port assignments as follows:
1. As root, issue the following command for each of the Ethernet interfaces (eth0
through eth2 for a single node system and eth0 through eth7 for a redundant
system):
ethtool <Ethernet interface>
If you check a non-existent Ethernet interface, the following snapshot shows
what is displayed:
# ethtool eth3
Settings for eth3:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available
288
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
The following examples show the information displayed for eth0 through eth7
on a redundant system. The eth0, eth1, and eth2 interfaces should be
displayed for a single-node system.
For an x3650T, the following is displayed:
# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes:
10baseT/Half 10baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: g
Link detected: yes
# ethtool eth1
Settings for eth1:
1000baseT/Full
1000baseT/Full
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Supports Wake-on: g
Wake-on: g
Link detected: yes
# ethtool eth2
Settings for eth2:
1000baseT/Full
1000baseT/Full
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
A31003-H8050-J100-09-7631, 09/2011
289
sw_install.fm
PHYAD: 1
Supports Wake-on: g
Wake-on: g
Link detected: yes
# ethtool eth3
Settings for eth3:
1000baseT/Full
1000baseT/Full
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Supports Wake-on: g
Wake-on: g
Link detected: yes
# ethtool eth4
Settings for eth4:
1000baseT/Full
1000baseT/Full
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Supports Wake-on: umbg
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
# ethtool eth5
Settings for eth5:
1000baseT/Full
1000baseT/Full
Speed: 100Mb/s
Duplex: Full
290
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
Port: Twisted Pair

PHYAD: 1
Supports Wake-on: d
Wake-on: d
Link detected: yes
# ethtool eth6
Settings for eth6:
1000baseT/Full
1000baseT/Full
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Supports Wake-on: d
Wake-on: d
Link detected: yes
# ethtool eth7
Settings for eth7:
1000baseT/Full
1000baseT/Full
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Supports Wake-on: d
Wake-on: d
Link detected: yes
Attention: Steps 2 through 5 are intended for fresh installations of OpenScape

Voice servers only. Service degradation will occur if these steps are performed on
a live system.
A31003-H8050-J100-09-7631, 09/2011
291
sw_install.fm
2. Unplug an Ethernet connector and issue the ethtool command (specifying

that interface). The display indicates which port (Link) was disconnected
(Link detected: no).
# ethtool <Ethernet interface>
Note: Chapter 3 of this document contains Connecting the Cables
information for each platform. Within these subsections are snapshots of the
server backplane that will help in identifying the physical locations of the
Ethernet interfaces.
A console snapshot is provided as an example;
# ethtool eth7
Settings for eth7:
1000baseT/Full

Advertised link modes:
1000baseT/Full

Speed: Unknown! (65535)
Duplex: Unknown! (255)
Port: Twisted Pair
PHYAD: 1
Supports Wake-on: d
Wake-on: d
Link detected: no
3. Restore the Ethernet connector and reissue the ethtool command to verify the
Link was reactivated (Link detected: yes).
4. Repeat steps 3 and 4 on all the Ethernet ports on this node.
5. If applicable, repeat steps 1 through 4 on the other node.
step 15.
292
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
4.4.5 Testing the KVM/Mouse Combination

If the equipment for OpenScape Voice includes a KVM, the KVM/mouse
combination must be tested for compatibility.
When the KVM is not switched to a server/node, it must simulate the connection.
If a different signature is generated on the simulation, the server/node requests
clarification of the type of mouse in use.
Some combinations of KVM switches and mice are not 100% compatible. Failure
to have a correctly working KVM/mouse combination will cause the server to
hang (waiting for operator input) during a reboot.
Test the KVM as follows:
1. Select the test node with the KVM and log in as root.
2. Run hwbootscan. It should produce no output.
3. Switch the KVM to another position.
4. Remotely log in to the test node as user sysad and then switch to user root
using the switch user (su -) command.
5. Run hwbootscan. It should produce no output.
If a menu is displayed to select a mouse, perform the following steps:
a) When prompted, select the mouse type, and select ACCEPT.
b) Switch the KVM back to the test node.
c) Run hwbootscan. It should produce no output.
6. Repeat this procedure on the other node.
step 17.
4.4.6 SNMP Community Names on OpenScape Voice

Note: To change the SNMP community name string to meet site security
requirements, it is strongly recommended that you contact your next level of
support before attempting the following procedures.
A31003-H8050-J100-09-7631, 09/2011
293
sw_install.fm
4.4.6.1 Changing the Community String for the Emanate

Master Agent
In V5 (and later releases), you may change community strings with the use of Cli.
In order to use startCli, follow the procedure below:
1. Login to CLI as: sysad
Node1:/home/sysad (62> startCli
2. Navigate to menu 6 > 1 > 10 > 2
3. Change the read-only/read-write community strings as shown below:
SNMP Management (methods):
Display SNMP Configuration.....................1
Modify SNMP Configuration......................2
Return..................................99
Selection (default: 1): 2
*** Modify SNMP community String ***
Enter Read-only SNMP community String: <Any ASCII
string (max length: 64)> (default: SENread):
Enter Read-write SNMP community String: <Any ASCII
string (max length: 64)> (default: SENSnmp):
Do you want to execute this action? <y/n> (default:
yes):
Checking connection with grd404n1.
Checking connection with grd404n2.
Backing up original configuration file.
Copying new configuration file to grd404n1.
Copying new configuration file to grd404n2.
Please wait. Applying new configuration on grd404n1.
Please wait. Applying new configuration on grd404n2.
Validating new configuration
Done.
4. Navigate to menu 6 > 1 > 10 > 2 to display the SNMP configuration for
verification purposes.
294
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
4.4.6.2 Restarting the EMANATE Master SNMP Agent

Once the snmpd.cnf file has been modified, you must restart the EMANATE
Master SNMP agent. This must be done every time this file is modified in order
for the changes to be set. To restart the master agent:
1. Log in as the superuser: su
2. Enter the following command:
cd /etc/init.d
./snmpdm stop
./snmpdm start
4.4.7 Configuring the OpenScape Voice Entry SBC

Enable and configure the low cost OpenScape Voice Entrys integrated SBC as
follows:
1. Log in to the Common Management Portal for the OpenScape Voice Entry
system.
2. Select the OpenScape Voice tab, Administration, General Settings, and
Session Border Control (note that if the RTP parameter Srx/Main/SBC is
not set to RtpTrue, the Session Border Control option will not be shown).
A Session Border Controller window is opened.
3. On the General tab of the Session Border Controller window:
Select the Enable Session Border Control check box
In the WAN IP Configuration section, specify the following for the SBC:
IP Address
Subnet Mask
Subnet
Default Gateway
Broadcast
Click Save. For example:
A31003-H8050-J100-09-7631, 09/2011
295
sw_install.fm
4. Configure SIP trunks in the SBC as follows:

a) On the Session Border Controller window: select the Endpoints tab and
click Add.
A SBC EndPoint configuration window is opened.
b) In the SBC EndPoint configuration window, specify the following for the
SIP trunk:
296
Transport Protocol
Port
GW Name
Wan IP
Wan Port
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
FQDN
Click Save. For example:
5. Create a static endpoint for the SBC LAN IP (refer to section 3: IP

configuration of the node.cfg for the SBC LAN IP address) and port as
follows:
a) Select the OpenScape Voice tab, Business Group, Members,
Endpoints (or select the OpenScape Voice tab, Global Translation and
Routing, and Endpoints), and click Add.
An Endpoint configuration window is opened.
b) On the General tab of the Endpoint configuration window: enter a name
for the endpoint, and click on the selection box next to Profile.
The Select Endpoint Profile window opens. Select the desired Endpoint
Profile and click OK.
c) On the SIP tab, set the SIP configuration for the static endpoint similar to
the example below and scroll down to the bottom of the page:
A31003-H8050-J100-09-7631, 09/2011
297
sw_install.fm
d) Click the Add button. The Add SIP Configuration window opens:
298
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
e) Check the Trusted entity box and click OK. In the Add Endpoint
window, the address is shown as trusted:
f)
Go back to the General tab and check the Registered check box.
g) On the Aliases tab, click Add to associate an alias with the SBC LAN IP
endpoint, and click OK.
A31003-H8050-J100-09-7631, 09/2011
299
sw_install.fm
6. Create a branch office connected via the SBC as follows:

a) Select the OpenScape Voice tab, Business Group, Branch Office, and
Branch Office List.
The Branch Office List screen is displayed.
b) On the Branch Office List screen, click Add.
A Create Branch Office window is opened.
c) On the General tab in the Create Branch Office window:
Enter a name for the branch office.
Enter the name of the endpoint you created in step 5 on page 297 in
the Representative End Point field.
Enter the appropriate numbering plan, office code, and routing area.
Click Save.
7. In the newly created branch office, create the static endpoint for the SIP trunk
using the SBC LAN IP address and the mapped port (specified in step 4 on
page 296; the range is 17000 to 17999) as follows:
a) Select the OpenScape Voice tab, Business Group, Members,
Endpoints, and click Add.
An Endpoint configuration window is opened.
b) On the General tab of the Endpoint configuration window: enter the name
for the endpoint name for the SIP trunk, ensure that the Registered check
box (for Static Registration) is checked, endpoint profile, and click OK.
c) On the SIP tab, set the SIP configuration for the SIP trunk static endpoint
and click OK.
8. Add the sbc_lan_ip address (the sbc_lan_ip address is defined in the
node.cfg file) to the whitelist for Snort to allow unthrottled traffic via the
OpenScape Voice Entrys integrated SBC as follows:
300
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
a) As user srx, enter the startCli command and select option 98.
b) At the CLI prompt, enter the command:
CLI>dosAssignTrustedHost <sbc_lan_ip address>
Note: Refer to Section 4.4.7.1 to view/edit alarms and to Section 4.4.7.2 to
change the default log level (Error) for log files.
4.4.7.1 SBC Alarms

View and edit alarms as follows:
system.
Session Border Control.
3. Select the Alarms tab of the Session Border Controller window.
An example of the Alarms tab is as follows:
A31003-H8050-J100-09-7631, 09/2011
301
sw_install.fm
302
A31003-H8050-J100-09-7631, 09/2011
sw_install.fm
4. To view or edit an Event, select the Events radio button and click Edit. For
example, Event ID 2:
Make changes as desired and click Save or Cancel as appropriate.
4.4.7.2 SBC Logs

Change the default level (Error) for log files as follows:
system.
Session Border Control.
3. Select the Logging tab of the Session Border Controller window.
A31003-H8050-J100-09-7631, 09/2011
303
sw_install.fm
An example of the Logging tab is as follows:

Note: Setting the log levels to Warning, Notice, Info, or Debug may impact
system performance and should only be done during maintenance windows.
The default log level is Error.
Select a log level from the drop down menu and click Save.
4.4.8 Stopping the Loquendo Trap Manager Service

For proper processing of SNMP traps, the following workaround to stop the
Loquendo Trap Manager Service should be executed on all OSV integrated
installations and external (offboard) applications servers acting as a Survival
Authority. This workaround does not apply to a Standalone Survival Authority.
As user root, execute the following commands:
# /etc/init.d/LoquendoTrapManagerd stop
# chkconfig LoquendoTrapManagerd off
# /etc/init.d/snmpd restart
304
A31003-H8050-J100-09-7631, 09/2011
assistant_install.fm
Installing the OpenScape Applications
Installation Overview
5 Installing the OpenScape Applications

5.1 Installation Overview
This chapter describes the procedures for installing the OpenScape Applications
(OpenScape Voice Assistant, RG8700 Assistant, OpenScape Media Server,
Deployment Service [DLS], and OpenScape UC Application).
The OpenScape Applications are installed:
Internally on the integrated simplex.

Note: New installations, upgrades or migrations to an integrated duplex
system are not offered with V5R0. If you are upgrading an integrated duplex
to V5R0, refer to Chapter 7, Overview of Upgrades and Migrations to
OpenScape Voice V5 for upgrade information and procedures.
Externally on an applications server for the standard duplex.
There are three basic steps for installing the OpenScape Applications:
1. Create response files (or file depending on deployment scenario).
2. Transfer the response files (or file) to the USB sticks (or stick) that contains
the node.cfg file for an integrated system or to the external applications server
for a standard duplex system.
3. Install the OpenScape Applications:
For an integrated system: The Applications are installed as part of the

OpenScape Voice Image installation. Use the OpenScape Voice V5R0
Reference Image DVD and USB stick that contains the node.cfg file to
install the OpenScape Applications onto the OpenScape Voice node. In
V5R0 (and later releases) integrated systems response files are built
automatically as part of the installation process. Response files no longer
response file is found on the USB stick that file will take precedence over
the file that is automatically generated via the Image installation. Refer to
Section 4.2, Installation via DVD for more details on the installation
procedure.
For a standard duplex: Use the OpenScape Applications DVD and

response file to install the OpenScape Applications onto the external
applications server.
A31003-H8050-J100-09-7631, 09/2011
305
5.1.1 Prerequisites
For all OpenScape Voice systems: The installer needs root access or
administrator rights on the SLES operating system of the machine on which the
OpenScape Applications will be installed.
For a standard duplex system:
OpenScape Voice software must be installed. Refer to Chapter 2, Preparing

for the Installation, Chapter 3, Installing the Hardware Platform, and
Chapter 4, Installing the OpenScape Voice Reference Image for
information.
The minimum patch level for OpenScape Voice must be installed to ensure
compatibility with the OpenScape Applications.
Refer to the OpenScape Applications release note to confirm the minimum
patch level for OpenScape Voice. The minimum patch level in the release
note supersedes the patch level specified here.
A currently supported external applications server (for example, IBM x3650T,

FSC RX330, FSC TX150, FTS RX200, IBM x3550 M2/M3) or a customerprovided external applications server with the appropriate SLES OS and
service pack level (that meets or exceeds the requirements described in
Section 5.1.2, Customer Provided Hardware Specifications, on page 306)
must be available for installation of the OpenScape Applications.
For more information on the OpenScape Applications, refer to the release notes.
5.1.2 Customer Provided Hardware Specifications

Customer-provided hardware for an external applications server (i.e., Media
Server Standalone and the Multiple Communications Server deployments) must
meet or exceed the specifications described here.
Note: Use Section 5.2.1.1 on page 309 as a guideline for installing the
appropriate SLES 10 OS with service pack onto customer-provided hardware.
Usage Ranges
Server Specifications*
Low end administration:

OpenScape Voice < 20,000
ports
Maximum of 20 RG 8700s
One IA32/EM64t (x86-64)

One Dual Core CPU 2.4 GHz
4 GB RAM
Two 160 GB SATA hard disks in RAID 1 configuration
One DVD ROM drive
Ethernet interfaces as required
Low end OpenScape Media

Server:
< 7,500 users
Up to 150 channels**
306
A31003-H8050-J100-09-7631, 09/2011
Usage Ranges
Server Specifications*
High end administration:

OpenScape Voice > 20,000
ports
Minimum of 20 RG 8700s
Two Quad Core CPU

(Intel Xeon 5345 CPU/QuadCore/2.33 GHz or higher or
AMD Opterion 2350 [2 GHz Quad Core - Barcelona])
8 GB RAM
Two 146 GB SAS hard disks in RAID 1 configuration
High end OpenScape Media
One DVD ROM drive
Server:
Ethernet interfaces as required
< 25,000 users
**
Up to 500 channels
*All
servers must be certified for SLES 10 with SP3.

Media Server configuration and usage (for example: number of codecs,
heavy conferencing or call center use) can impact the use ranges in this chart. If in doubt,
contact HELPS to confirm recommended server specifications. Use the following
guidelines for selecting the hardware for the OpenScape Media Server:
**OpenScape
Low end:
6,000 BHCA
G.711: Maximum of 150 channels for announcements and conferencing
High end:
20,000 BHCA
A31003-H8050-J100-09-7631, 09/2011
307
Installation Instructions for Applications Servers
5.2 Installation Instructions for Applications Servers

Note: Information for installing the OpenScape UC Application separately (apart
from the normal OpenScape Voice installation) is included in the OpenScape UC
Application V3, Installation Instructions, Installation Guide. There, the installation
procedures for standard duplex small deployment and the standard duplex
large deployment are described.
Note: The Deployment Service (DLS) component might not be supported on the
external applications server due to sizing limitations. A separate server running
Microsoft Windows might be required for the DLS component. Please review the
DLS release notes for sizing limitations when DLS is installed as a component of
the external applications server.
5.2.1 Installing SLES 10 OS with Appropriate Service

Pack onto the External Applications Server
Refer to the section appropriate for the type of platform as a guide for the SLES
installation:
Section 5.2.1.1, Installing SLES 10 with appropriate service pack onto the
IBM x3650T, on page 309
FSC TX150, on page 316
FSC RX330, on page 326
Attention: These instructions are provided as a guideline for installing the
appropriate SLES distribution onto customer provided hardware.
Review the following document section before proceeding with the
SLES install:
Documentation
OpenScape UC Application V3
Installation and Upgrade
Installation Guide
Section Preparing the OpenScape UC Application Unified Communications
Server
The instructions in the Section "Preparing the OcenScape UC Application
308
A31003-H8050-J100-09-7631, 09/2011
Unified Communications Server" supersede any installation instruction

contained in this document.
5.2.1.1 Installing SLES 10 with appropriate service pack onto

the IBM x3650T
Attention: To modify the IBM x3650T Server SCSI RAID Configuration refer to
Section 3.3.7, Modifying the IBM x3650T Server SCSI RAID Configuration, on
page 62 of this document. Return to this procedure after completing Section 3.3.7
(a link back to this page will be present).
Install and set up the appropriate SLES 10 service pack on the external
applications server for the OpenScape Applications as follows:
1. Insert the appropriate SLES10 installation DVD into the DVD drive of the
target machine and reboot the machine to start the installation. Wait for the
installation menu screen.
2. Select the Installation - ACPI Disabled that provides the option acpi=off
and also add the option hwprobe=+cpuemu. Press Enter.
3. On the next screen, select the language for the keyboard and click next.
4. Accept the License Agreement and click Next. If an error message appears
regarding RAID, ignore it and go to the next screen.
5. On the Installation Mode screen, select New Installation and click Next.
6. On the Clock and Time Zone Mode screen, set the Region Type and Time
Zone and click Next:
7. Set the Installation Settings as follows:
a) Select Partitioning, Create Custom Partition Setup, and click next.
b) On the next screen, select Custom Partitioning (for experts) and click
next. The Expert Partitioner screen is displayed.
c) Retain only /dev/sda.
d) Create /dev/sda1 as follows: Click Create, select Primary Partition,
select Format, select Swap for File System. Set the Start Cylinder to 0
and the End Cylinder to +2GB; set the Mount Point to swap.
e) Create /dev/sda2 as follows: Click Create, select Primary Partition,
select Format, select Ext3 for File System. Dont change the Start or End
Cylinders; set the Mount Point to /. For example:
A31003-H8050-J100-09-7631, 09/2011
309
Device
f)
Size
Type
/dev/sda
136.7 GB
/dev/sda1
2.0 GB
/dev/sda2
134.7 GB Linux native(ext3)
Linux swap
Mount
Start
End
17848
swap
261
262
17848
On the Expert Partitioner screen, click Finish and then click Accept.
g) On the Confirm Installation screen, click I Agree and then click Install.
The system now will prepare your hard disk and the package installation
starts. After it is finished, the system will reboot from the hard disk.
8. If a Confirm Hardware Detection Network Cards window appears, click
Continue.
If you are using CDs for the SLES install the system will prompt you to insert
CD2.
9. Enter the password for the system administrator root as follows:
a) When prompted type siemens* for the root password:
Insert password for root User: siemens*
b) Confirm the password and click Next.
310
A31003-H8050-J100-09-7631, 09/2011
c) A confirmation pop up window is displayed for using a simple password.

Click Yes to continue using this password.
10. Enter the Hostname and Domain Name:
Hostname: <Offboard_Hostname>
Domain name: site
Clear the Change Hostname via DHCP check box and click next.
11. If a window appears for DSL, PPPoE DSL Devices, ISDN Cards and
Modems, click Skip (if these devices are not used which is usually the case).
12. On the Network Configuration screen, configure the network as follows:
a) Select Use following Configuration.
b) Select Network Interfaces.
c) At the already configured devices, click Edit. The Network Address Setup
d) On the Network Address Setup screen, select the Static Address Setup
radio button.
e) Enter the static IP address and the subnet Mask of the external
applications server in the respective fields.
f)
On the Network Address Setup screen, click Routing.

The Routing Configuration screen is displayed.
A31003-H8050-J100-09-7631, 09/2011
311
g) On the Routing Configuration screen, enter the Default Gateway IP

address and click OK.
h) Click next and click next again to return to the Network Configuration
screen.
i)
On the Network Configuration screen, select Firewall is enabled and

SSH port is open, and then click Next.
13. On the Test Internet Connection screen, click No Skip this Test and click
next.
14. On the Installation Settings screen, select Use following Configuration and
Open LDAP server. Disable the server and click next.
15. On the User authentication Method screen, select Local (/etc/passwd) and
click next.
Optionally, you can create a user account or an empty user login and then
click next.
16. On the Release Notes for SuSE Linux Enterprise server screen, click next.
17. On the Hardware Configuration screen, select Use Following Configuration
and click next.
18. On the Installation Complete screen, clear the Clone This System for
Autoyast check box and click Finish.
312
A31003-H8050-J100-09-7631, 09/2011
The system now will reboot on runlevel5.

Note: Sometimes, after a system reboot, the network connection might not
be available because the system deactivates the network card. If this occurs,
reconfigure the network card using YaST.
19. Edit the hosts file to remove the line that starts with 127.0.0.2 (this error was
in SLES 10 but appears to have been corrected in SLES 10 SP1; you should
still verify that the hosts file is correct.) with the command:
<hostname>:~ # vi /etc/hosts
The hosts file is opened for editing.
#
# hosts
This file describes a number of hostname-to-address
#
mappings for the TCP/IP subsystem. It is mostly
#
used at boot time, when no name servers are
#
running.
#
On small systems, this file can be used instead of
#
a "named" name server.
# Syntax:
#
# IP-Address Full-Qualified-Hostname Short-Hostname
#
127.0.0.1
localhost
# special IPv6 addresses

::1 localhost ipv6-localhost ipv6-loopback
fe00::0
ipv6-localnet
ff00::0
ipv6-mcastprefix
ff02::1
ipv6-allnodes
ff02::2
ipv6-allrouters
ff02::3
ipv6-allhosts
127.0.0.2
<hostname>.site <hostname>
10.1.250.70
Find the line 127.0.0.2 <hostname>.site <hostname> and either delete the
line or comment it out with a # sign at the beginning of the line. Save the hosts
file.
If this is not done, when the OpenScape Applications installation begins there
will be the following message and the installation will not start:
In /etc/hosts the ip-address for <hostname> is not correct. It should be an
external address. Please correct and start Installation again.
20. Change the default run level as follows:
a) Edit the inittab file with the command:
<hostname>:~ # vi /etc/inittab
b) Find the following lines:
# The default runlevel is defined here
id:5:initdefault:
A31003-H8050-J100-09-7631, 09/2011
313
c) You can change the default run level (5 in this example) in the range 1
through 5.
#
#
#
#
#
#
#
runlevel
runlevel
runlevel
runlevel
runlevel
runlevel
runlevel
0
1
2
3
4
5
6
is
is
is
is
is
is
is
System halt (Do not use this for initdefault!)

Single user mode
Local multiuser without remote network (e.g. NFS)
Full multiuser with network
Not used
Full multiuser with network and xdm
System reboot (Do not use this for initdefault!)
The recommended default runlevel is 3 for booting in a command line

Linux interface.
21. Verify network connectivity by pinging one of the nodes with the command:
<hostname>: ~ # ping <IP address of one of the nodes>
If no reply is received, investigate the network problem before you continue.
It could be that the Ethernet cable at the back of the external server is
connected to the eth1 interface instead of the eth0 interface. If this is the case,
move the cable to the eth0 interface.
22. Install additional software packages from the SLES 10 CD/DVD media. The
needed packages are ethereal, expect, netcat, openssh, and java-1_5_0ibm. Proceed with the installation as follows:
a) If the SLES installation DVD is not in the DVD drive, insert the DVD now.
b) Click YaST, click Software, and then click Add-on Product.
c) Select DVD and click next.
d) In the Insert the add-on Product DVD window, click continue.
e) Agree to the License and click next.
f)
In the Search box, enter the package name (for example, expect), and
click Search.
g) When the package is found, if it is unchecked (meaning not installed),

select it and click Accept.
h) In the install or remove more products window, click yes.
i)
Repeat steps 22f and 22g on page 314 for the java-1_5_0-ibm package.
The system will indicate that two other packages have dependency on the
java-1_5_0-ibm package. Accept to have them installed by clicking
continue.
j)
In the install or remove more products window, click no.
23. If a local NTP server is used to coordinate servers time, then it could be
configured as follows. Otherwise, skip this step.
a) Click YaST, click Network Services, and then click NTP Configuration.
b) Select During Boot, click Select, and choose Local NTP Server.
314
A31003-H8050-J100-09-7631, 09/2011
c) Enter the IP Address of the local NTP server.

d) Click Test. When the server is reachable, click OK, click OK again, and
then click Finish.
24. Harden the operating system as specified in Section 5.2.2, External
Applications Server Port List, on page 336.
25. Remove or unmount the SLES 10 installation DVD.
26. IF the OpenScape Voice server separates the interfaces for admin and
signaling, (one for accessing the admin interface of the 8K, one for Signaling)
than two network interfaces are necessary for the application sever. In case
signaling (CSTA) and admin traffic are separated;
eth1 or any other network interface must be configured with an IP address

that can reach the HP8K CSTA signaling address.
Ensure that the hostname entry of the OpenScapes CSTA signaling IP

address in /etc/hosts does NOT match the hostname entry for eth0.
For example:
vi /etc/hosts
# hosts
mappings for the TCP/IP subsystem.
used at boot time, when no name servers are running.
On small systems, this file can be used instead of a
"named" name server.
It is mostly
# Syntax:
#
# IP-Address
Full-Qualified-Hostname
Short-Hostname
127.0.0.1
localhost
10.2.100.111
openscape-1.fwcbyellow openscape-1
10.3.100.111
openscape-1-sig.fwcbyellow openscape-1-sig
Attention: The Applications server NIC chosen as the CSTA interface must be
defined in the Voice server node.cfg CSTA server list. IF the Voice server system
is already operational and the CSTA interface must be changed refer to Appendix
F, Updating the Node.cfg File (Also Known as EZIP) on page 641. It is
suggested you contact your next level of support before executing this procedure.
A31003-H8050-J100-09-7631, 09/2011
315

the FSC TX150
Install and set up SLES 10 with appropriate service pack on the external
1. Insert the Fujitsu Siemens PRIMERGY ServerStart, Disc1 CD into the DVD
drive and boot the system.
2. Select the language, the keyboard type, the No status backup radio button
(accept the defaults for the Connect status media check box [unchecked] and
the parameters below it on this screen), and click Continue.
3. Accept the License Agreement.
4. At the bottom of the Welcome to Server Start screen, select Guided/Expert
5. On the next Welcome to Server Start screen, select Click here to prepare
and/or initiate an operating system installation.
6. On the Select the operating system to be installed screen, select Linux.
7. On the Linux Operating System Installation screen, select Install SuSE
Linux Enterprise Server.
8. On the Installation of SuSE Linux Enterprise Server screen, select Install
SuSE Linux Enterprise Server interactively (expertise required).
9. On the Installation of Suse Linux Enterprise Server (expert mode) screen,
select Please configure the RAID system.
10. On the Fujitsu Siemens: RAID Manager screen, proceed as follows:
a) Change the Combo Box in Menu Line to Write Access.
b) Select LSI Logic Embedded MegaRAID (0).
c) Right click on this entry and select Create Logical Drive (if a logical drive
already exists, right click on the entry, select Delete all logical drives,
and type yes to confirm. Right click the same entry and select Create
Logical Drive.).
d) For the Create Logical Drive, select LSI Logic Embedded MegaRAID
(0).
e) For the Capacity Logical Drivers, select RAID-0 for the RAID Level and
Use Maximum Capacity.
f)
316
For the General Parameters, set the parameters as follows:
Read mode: No read-ahead
Disk cache mode: Disabled
A31003-H8050-J100-09-7631, 09/2011
Init mode: No initialization
Name: Use any arbitrary name, for example: disc1.
g) Select the Layout tab, add all the disk drivers that will use RAID(0), and
click Create. Type yes to confirm.
h) Select Exit from the File menu. Click yes to confirm closing the session.
A message box asks for a reboot (a reboot is not necessary at this time),
click No.
select Use Disk Manager to create a temporary service partition.
12. On the Disk Manager screen, a tree of partitions is shown, on a brand new
system, only PARTITION_ENTRY_UNUS is displayed. If there are any other
partitions, delete them (right click on the partition and select Delete) and then
create the Service Partition as follows:
a) Select PARTITION_ENTRY_UNUS, right click the partition, select
Create, and then select Linux Service.
A 55 MB partition "* Linux" is shown in the tree.
b) From the menu bar, select File and Exit.
13. On the Installation of SUSE Linux Enterprise Server (expert mode)
screen, ensure that the following three items are checked:
Use SCU
RAID system
Disk Manager
Then select the appropriate SUSE Linux Enterprise Server (SLES)10 version
for your installation. Questions should be addressed to your next level of
support.
14. On the ServerStart installation support for SuSE Linux screen, click Start (via
service partition).
A confirmation box displays: The system will be restarted...
15. Remove the Fujitsu Siemens PRIMERGY ServerStart, Disc1 CD and click
OK.
After the system reboots (about 2 minutes), you can begin installing the
appropriate SLES 10 operating system with service pack.
16. Select the language and click OK.
17. Select the language for the keyboard and click OK.
18. From the Main Menu, select Start Installation or System and click OK.
A31003-H8050-J100-09-7631, 09/2011
317
19. On the next screen, select Start Installation or Update and click OK.
20. On the next screen, select CD-ROM for the source medium and click OK.
21. Insert the SLES10 installation DVD into the DVD drive and click OK.
22. On the next screen, select the Language for the Keyboard and click next.
23. Accept the License Agreement and click next.
24. On the Confirm Driver Activation screen, click OK.
25. On the Installation Mode screen, select New Installation and click next.
26. On the Clock and Time Zone screen, set the Region Type and Time Zone and
click next.
Device
318
Size
Type
/dev/sda
149.0 GB
/dev/sda1
2.0 GB
/dev/sda2
Linux swap
Mount
Start
End
19456
swap
261
262
19456
A31003-H8050-J100-09-7631, 09/2011
f)
Continue.
CD2.
b) Confirm the password and click next.
c) A confirmation window is displayed for using a simple password. Click
Yes to continue using this password.
Domain name: site
A31003-H8050-J100-09-7631, 09/2011
319
c) At the already configured devices, click Edit. The Network Address Setup
d) On the Network Address Setup screen, select the Static Address Setup
radio button.
e) Enter the static IP address and the subnet Mask of the external
f)
On the Network Address Setup screen, click Routing.

320
A31003-H8050-J100-09-7631, 09/2011
g) On the Routing Configuration screen, enter the IP address for the Default
Gateway and click OK.
h) Click next and click next again to return to the Network Configuration
screen.
i)

SSH port is open. Click next.
next.
click next.
click next.
and click next.
If a window appears for printers and they are not being used, click Skip and
then click next.
A31003-H8050-J100-09-7631, 09/2011
321

#
# hosts
#
#
#
running.
#
#
# Syntax:
#
#
127.0.0.1
localhost

fe00::0
ipv6-localnet
ff00::0
ipv6-mcastprefix
ff02::1
ipv6-allnodes
ff02::2
ipv6-allrouters
ff02::3
ipv6-allhosts
127.0.0.2
10.1.250.70
file.
id:5:initdefault:
322
A31003-H8050-J100-09-7631, 09/2011
through 5.
#
#
#
#
#
#
#
runlevel
runlevel
runlevel
runlevel
runlevel
runlevel
runlevel
0
1
2
3
4
5
6
is
is
is
is
is
is
is

Single user mode
Not used

Linux interface.
a) If the SLES 10 installation DVD is not still in the DVD drive, insert the
DVD.
f)
click Search.

i)
Repeat steps 42f and 42g for the java-1_5_0-ibm package. The system
will indicate that two other packages have dependency on the java1_5_0-ibm package. Accept to have them installed by clicking continue.
j)
A31003-H8050-J100-09-7631, 09/2011
323

then click Finish.
44. Remove or unmount the SLES 10 install DVD.
46. IF the OpenScape Voice server separates the interfaces for admin and


For example:
vi /etc/hosts
# hosts
It is mostly
# Syntax:
#
# IP-Address
Short-Hostname
127.0.0.1
localhost
10.2.100.111
10.3.100.111
Attention: The Applications server NIC chosen as the CSTA interface must
be defined in the Voice server node.cfg CSTA server list. IF the Voice server
system is already operational and the CSTA interface must be changed refer
to Appendix F, Updating the Node.cfg File (Also Known as EZIP) on page
641. It is suggested you contact your next level of support before executing
this procedure.
47. This step is a workaround for the interface eth0 configuration after reboot.
324
A31003-H8050-J100-09-7631, 09/2011
This is a fault in SLES 10 SP2 only and it only seems to affect FSC TX150
servers.
This workaround corrects the fault mentioned in the Note of step 38 on page
321.
a) As user root, edit the kernel file with the command:
# vi /etc/sysconfig/kernel
b) Search for the line starting with "INITRD_MODULES". You will find:
INITRD_MODULES="piix megasr processor thermal fan jbd ext3 edd"
c) Append parameter tg3 to the parameters at the end of the line. After
appending tg3, the line should be as follows:
INITRD_MODULES="piix megasr processor thermal fan jbd ext3 edd tg3"
d) Save the kernel file.
e) Save the existing network configuration file (filename starting with
"initrd-") with the following commands:
<hostname>: # cd /boot
<hostname>:/boot # ls -l
The system will display text similar to the following (the initrd- file is in
bold)
total 7392
-rw-r--r--rw------lrwxrwxrwx
-rw-r--r-drwxr-xr-x
lrwxrwxrwx
smp
-rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rwxr-xr-x
lrwxrwxrwx
bigsmp
-rw-r--r--
1
1
1
1
2
1
root
root
root
root
root
root
root
root
root
root
root
root
720969
512
1
69808
4096
28
May
Feb
Feb
May
Feb
Feb
18
25
25
18
25
25
2007
15:47
15:38
2007
15:47
15:47
System.map-2.6.16.46-0.12-bigsmp
backup_mbr
boot -> .
config-2.6.16.46-0.12-bigsmp
grub
initrd -> initrd-2.6.16.46-0.12-big-
1
1
1
1
1
1
1
root
root
root
root
root
root
root
root 3007812 Feb 25 15:47

root 135680 Feb 25 15:47
root 105627 May 18 2007
root 341361 May 18 2007
root
95043 May 18 2007
root 1650698 May 18 2007
root
29 Feb 25 15:42
initrd-2.6.16.46-0.12-bigsmp
message
symsets-2.6.16.46-0.12-bigsmp.tar.gz
symtypes-2.6.16.46-0.12-bigsmp.gz
symvers-2.6.16.46-0.12-bigsmp.gz
vmlinux-2.6.16.46-0.12-bigsmp.gz
vmlinuz -> vmlinuz-2.6.16.46-0.12-
1 root root 1370989 May 18
2007 vmlinuz-2.6.16.46-0.12-bigsmp
Then issue the command:

<hostname>:/boot # cp -p initrd-2.6.16.46-0.12-bigsmp
initrd-2.6.16.46-0.12-bigsmp_saved
f)
Rebuild the initial ramdisk with the command:

<hostname>:/boot # mkinitrd
The system will display text similar to the following
Root device:
Module list:
xenblk)
/dev/sda3 (mounted on / as ext3)

piix megasr processor thermal fan jbd ext3 edd tg3 (xennet
A31003-H8050-J100-09-7631, 09/2011
325
Kernel image:
/boot/vmlinuz-2.6.16.46-0.12-bigsmp
Initrd image:
/boot/initrd-2.6.16.46-0.12-bigsmp
Shared libs:
lib/ld-2.4.so lib/libacl.so.1.1.0 lib/libattr.so.1.1.0
lib/libblkid.so.1.0 lib/libc-2.4.so lib/libcom_err.so.2.1 lib/libdl-2.4.so
lib/libext2fs.so.2.4 lib/libhistory.so.5.1 lib/libncurses.so.5.5
lib/libpthread-2.4.so lib/libreadline.so.5.1 lib/librt-2.4.so
lib/libuuid.so.1.2 lib/libnss_files-2.4.so lib/libnss_files.so.2
lib/libgcc_s.so.1
Driver modules: ide-core ide-disk scsi_mod sd_mod piix megasr processor
thermal fan edd tg3 libata ahci ata_piix
Filesystem modules:
jbd ext3
Including:
initramfs fsck.ext3
14564 blocks
g) Reboot the server with the command:

<hostname>: # reboot
h) When the server reboots, you will be prompted to enter the login ID and
password. They should be the same as what you entered in 29 on page
319.
i)
To go to the GUI, type the command:

<hostname>: # startx

the FSC RX330
Install and set up SLES 10 with appropriate service pack on the external
1. Insert the Fujitsu PRIMERGY ServerStart, Disc1 CD into the DVD drive and
boot the system.
2. Select the language, the keyboard type, the No status backup radio button
(accept the defaults for the Connect status media check box [unchecked] and
the parameters below it on this screen), and click Continue.
3. Accept the License Agreement.
4. At the bottom of the Welcome to Server Start screen, select Guided/Expert
5. On the next Welcome to Server Start screen, select Click here to prepare
and/or initiate an operating system installation.
6. On the Select the operating system to be in installed screen, select Linux.
7. On the Linux Operating System Installation screen, select Install SuSE
Linux Enterprise Server.
8. On the Installation of SuSE Linux Enterprise Server screen, select Install
SuSE Linux Enterprise Server interactively (expertise required).
326
A31003-H8050-J100-09-7631, 09/2011

select Please configure the RAID system.
Note: If you arrived at this point after following the instructions of step 10g on
page 327, then go to step 10h on page 327). Otherwise, continue with step
10.
10. On the Fujitsu Siemens: RAID Manager screen, proceed as follows:
a) Change the Combo Box in Menu Line to Write Access.
b) Select LSI xxxxxSASxxxxxxx (0).
c) Right click on this entry and select Create Logical Drive (if a logical drive
already exists, right click on the entry, select Delete all logical drives,
and type yes to confirm. Right click the same entry and select Create
Logical Drive.).
d) For the General Parameters, set the following values:
RAID Level: RAID-0
Read mode: No read-ahead (already set)
Disk cache mode: Disabled (already set)
Init mode: No initialization (already set)
Name: Use any arbitrary name, for example: disc1.
e) Select the Layout tab, add all the disk drives that will use RAID(0), click
Create, and type yes to confirm.
f)
From the menu bar, select File and Exit. Click Yes to confirm closing the
session.
A message box asks for a reboot, click Yes.
g) After the system reboots, repeat steps 2 on page 326 through step 9 on
page 327 (you must perform these steps in order for the system to accept
the RAID configuration).
h) On the Fujitsu Siemens: RAID Manager screen, ensure that the logical
drive(s) had been created.
i)
From the menu bar, select File and Exit. Click Yes to confirm closing the
session.
A message box asks for a reboot, click no (there should be a check mark
on the right side of the RAID Manager screen).
select Use Disk Manager to create a temporary service partition.
A31003-H8050-J100-09-7631, 09/2011
327
12. On the Disk Manager screen, a tree of partitions is shown, on a brand new
system, only PARTITION_ENTRY_UNUS is displayed. If there are any other
partitions, delete them (right click on the partition and select Delete) and then
create the Service Partition as follows:
a) Select PARTITION_ENTRY_UNUS, right click the partition, select
Create, and then select Linux Service.
A 55 MB partition "* Linux" is shown in the tree.
b) From the menu bar, select File and Exit.
13. On the Installation of SUSE Linux Enterprise Server (expert mode)
screen, ensure that the following three items are checked:
Use SCU
RAID system
Disk Manager
Then select the appropriate SUSE Linux Enterprise Server (SLES) 10 version
for your installation. Questions should be addressed to your next level of
support.
14. On the ServerStart installation support for SuSE Linux screen, click Start (via
service partition).
A confirmation box displays: The system will be restarted...
15. Remove the Fujitsu PRIMERGY ServerStart, Disc1 CD and click OK.
After the system reboots (about 2 minutes), you can begin installing the
appropriate SLES 10 operating system with service pack.
16. Select the language and click OK.
17. Select the language for the keyboard and click OK.
18. From the Main Menu, select Start Installation or System and click OK.
19. On the next screen, select Start Installation or Update and click OK.
20. On the next screen, select CD-ROM for the source medium and click OK.
21. Insert the SLES10 DVD into the DVD drive and click OK.
22. On the next screen, select the language for the keyboard and click next.
23. Accept the License Agreement and click next.
24. On the Confirm Driver Activation screen, click OK.
25. On the Installation Mode screen, select new installation.
26. On the Clock and Time Zone screen, set the Region Type and Time Zone and
click next.
328
A31003-H8050-J100-09-7631, 09/2011

Device
f)
Size
Type
/dev/sda
272.0 GB
/dev/sda1
2.0 GB
/dev/sda2
Linux swap
Mount
Start
End
35499
swap
261
262
35499
A31003-H8050-J100-09-7631, 09/2011
329
Continue.
CD2.
b) Confirm the password and click next.
c) A confirmation window is displayed for using a simple password. Click
Yes to continue using this password.
Domain name: site
c) Select the Ethernet controller that is already configured for DHCP and
click Delete. The IP address field is changed from DHCP to Not
Configured.
d) Select the first Fujitsu Siemens NetXtreme BCM5715 Gigabit Ethernet
controller (this is the onboard Ethernet controller) and click Edit.
e) On the Network Address Setup screen, select the Static Address Setup
radio button.
f)
330
Enter the static IP address and the subnet Mask of the external
A31003-H8050-J100-09-7631, 09/2011
g) On the Network Address Setup screen, click Routing.

h) On the Routing Configuration screen, enter the IP address for the Default
Gateway and click OK.
i)
Click next and click next again to return to the Network Configuration
screen.
j)

SSH port is open. Click next.
A31003-H8050-J100-09-7631, 09/2011
331
next.
click next.
click next.
and click next.
If a window appears for printers and they are not being used, click Skip and
then click next.
#
# hosts
#
#
#
running.
#
#
# Syntax:
#
#
127.0.0.1
localhost

fe00::0
ipv6-localnet
ff00::0
ipv6-mcastprefix
ff02::1
ipv6-allnodes
ff02::2
ipv6-allrouters
332
A31003-H8050-J100-09-7631, 09/2011
ff02::3
127.0.0.2
10.1.250.70
ipv6-allhosts
file.
id:5:initdefault:
through 5.
#
#
#
#
#
#
#
runlevel
runlevel
runlevel
runlevel
runlevel
runlevel
runlevel
0
1
2
3
4
5
6
is
is
is
is
is
is
is

Single user mode
Not used

Linux interface.
a) If the SLES 10 install DVD is not still in the DVD drive, insert the DVD.
A31003-H8050-J100-09-7631, 09/2011
333

f)
click Search.

i)
Repeat steps 42f and 42g for the java-1_5_0-ibm package. The system
will indicate that two other packages have dependency on the java1_5_0-ibm package. Accept to have them installed by clicking continue.
j)
then click Finish.
45. Remove or unmount the SLES 10 install DVD.
46. If the OpenScape Voice server separates the interfaces for admin and


For example:
vi /etc/hosts
# hosts
It is mostly
# Syntax:
334
A31003-H8050-J100-09-7631, 09/2011
#
# IP-Address
Short-Hostname
127.0.0.1
localhost
10.2.100.111
10.3.100.111
Attention: The Applications server NIC chosen as the CSTA interface must
be defined in the Voice server node.cfg CSTA server list. IF the Voice server
system is already operational and the CSTA interface must be changed refer
to Appendix F, Updating the Node.cfg File (Also Known as EZIP) on page
641. It is suggested you contact your next level of support before executing
this procedure.
5.2.1.4 Operating Systems Supported

Server operating system and database system
Database System Name
Database System Version
SolidTech
04.5.175
Operating System Name
Operating System Version
SUSE Linux Enterprise Server (SLES)

for OpenScape Voice V5 servers
10 SP3 64 Bit
SUSE Linux Enterprise Server (SLES)

for application servers
10 SP3 32bit and 64 bit (with 32bit

runtime environment)
Note: Please take care that for the SLES 10 SP3 64bit operating system the
package "32 Bit Runtime Environment" must be installed at first.
The following documents should help installation on following hardware

examples, check vendor documentation for other hardware:
A31003-H8050-J100-09-7631, 09/2011
335
Installing SUSE Linux Enterprise Server 10 SP3 - IBM System x3650 M3

(4255, 7945) (according to http://www-947.ibm.com/support/entry/portal/
docdisplay?lndocid=MIGR-5083486&brandind=5000008).
Note: SLES 10 is currently not officially supported by IBM for the IBM System
x3650 T server, but a statement of support has been request and is being
processed with IBM.
Meanwhile, the Common Management Portal (CMP), OpenScapeVoice and

RG8700 Assistant, Media Server, and License Management have been verified
to run on this configuration without any problems for upgrades and migrations.
Note: For OpenScape Voice Assistant the following rpms are required: expect,
netcat and openssh. All 3 packages can be found in the SLES 10 distribution.
File System
Make sure that you select the "ext3" file system for the Linux partition (and do not
use the default reiserfs).
5.2.2 External Applications Server Port List

To harden the operating system of the external OpenScape Applications server,
activate the Linux Firewall (using YaST) or use firewalls in the network
infrastructure to block all ports not listed in Table 30. Access the external
applications server firewall port table as follows:
1. Click Yast, Security and Users, Firewall, Allowed Services, and
Advanced.
2. Update the port data to the firewall as specified in Table 30 on page 336.
3. When you are finished updating the port data, click Advanced, Next, and
Accept.
Table 30 lists all the ports that should not be blocked. During installation of the
OpenScape Applications these ports are required incoming.
Port
25
TCP
For SMTP groupware integration
443
TCP
HTTPS for browser access to Common Management Portal
483
TCP
Office Communicator connection
4444
TCP
HiPath User Management Access (optional)
Table 30
336
Protocol Description
Port List for the External OpenScape Applications (Sheet 1 of 2)
A31003-H8050-J100-09-7631, 09/2011
Port
Protocol Description
4708
TCP
SOAP communication to Siemens Shared Services. Required

for OpenScape RichClient using HTTP.
4709
TCP
SOAP communication to Siemens Shared Services. Required

for OpenScape RichClient using HTTPS.
4710
TCP
Osgi communication
4711
TCP
Osgi communication via TLS
7778
TCP
XML asynchronous events for WebClient
7788
TCP
XMLS secure for WebClient
7789
TCP
HTTP access to OpenScape WebClient
7800
TCP
Application discovery (optional; required for distributed

installations)
8443
TCP
HTTPS access to OpenScape WebClient
8787
TCP
Communication from XPressions
8818
TCP
Communication (HTTPS) to CLM
8819
TCP
Communication (HTTP) to CLM
10001
TCP
Communication from XPressions
16760
TCP
Solid database connection
61616
TCP
Symphonia events
UDP Protocol Ports
161
UDP
SNMP Get and Set Requests (optional, only required for

communication to SNMP management systems, for example:
OpenScape Voice Fault Management)
162
UDP
Retrieve alarms via SNMP traps.
2427
UDP
MGCP protocol of the external OpenScape Media Server
5004:5008
UDP
RTP (voice) payload for the external OpenScape Media Server
5060:5061
UDP
SIP signaling for the external OpenScape Media Server
20000:21000
(see Note)
UDP
RTP (voice) payload for the external OpenScape Media

Server.
Note: Older OpenScape Applications DVDs with versions
V3.1R3 DVD8 and lower used the 4000:4999 port range.
45566
UDP
Symphonia Multicast Discovery
Table 30
Port List for the External OpenScape Applications (Sheet 2 of 2)
A31003-H8050-J100-09-7631, 09/2011
337
5.2.3 OpenScape Media Server and OpenScape UC

Application Installation Overview
Note: After executing a symphoniad start or symphoniad restart command
there is a period of time in which the applications services are set into operation.
As user root the applications services startup can be monitored by the following
command:
For integrated applications servers;
tailf /log/osgi.log
For External (offboard) applications servers;
tailf /var/siemens/common/log/osgi.log
Monitor the file osgi.log for the services startup sequence. When the osgi.log file
reports "* Start processing all bundles done.* " the system is ready. The startup
sequence should not have been interrupted by error messages. The file osgi.err
(located in the same path as the osgi.log file) should be empty also.
Questions should be addressed to your next level of support.
Note: To execute the steps described in this section you need to know which
deployment scenario you want to use (see OpenScape UC Application Planning
Guide).
Deployment Scenarios
The supported deployment scenarios are:
integrated simplex
standard duplex small deployment
standard duplex large deployment
Multiple standard duplex communication server deployment (= standard

duplex voice)
Media server stand alone
Multiple Communication Server
This document contains the installation and update procedures of OpenScape

UC Applications for the following deployment scenarios.
338
Integrated simplex
Media server stand alone

A31003-H8050-J100-09-7631, 09/2011
Multiple Communication Server
Note: Information for installing the OpenScape UC Application separately (apart

from the normal OpenScape Voice installation) is included in the OpenScape UC
Application V3, Installation Instructions, Installation Guide. There the installation
procedures for standard duplex small deployment and the standard duplex
large deployment are described.
Documentation
Before installing the OpenScape Applications, refer to the OpenScape UC
Application V3, Configuration and Administration, Administrator Documentation,
Issue 2 for configuration and administration information for the internal or external
OpenScape Media Server.
For the OpenScape UC Application, refer to the following documents for detailed
installation, configuration, and administration information:
OpenScape UC Application V3, System Description
OpenScape UC Application V3, Planning Guide, Administrator

Documentation
OpenScape UC Application V3, Installation Instructions, Installation Guide
OpenScape UC Application V3, Client (Web, Mobile, and Desktop)

Installation and User documents (as applicable)
OpenScape UC Application V3, Mass Rollout, Description (if applicable)
OpenScape UC Application V3, Configuration and Administration,

Administrator Documentation
A31003-H8050-J100-09-7631, 09/2011
339
5.2.4 Installation/Update Instructions for Integrated

Simplex Systems
Attention: For details regarding OpenScape UC Application components please
refer to the OpenScape UC Application V3, Installation and Upgrade, Installation
Guide document.
Attention: Carefully review the Installation Prerequisites section of the

OpenScape Applications release note for any activities that might be required
before creating the response files.
Note: Refer to the OpenScape Applications DVD release notes for the latest
updates to the OpenScape Applications.
5.2.4.1 Prepare Installation of Integrated Simplex

Execute the following steps on the application computer.
1. Mount the setup source as follows:
a) How to proceed if a DVD is your setup source:
If the DVD is not mounted automatically, execute the following command
as superuser:
mount /dev/hda /mnt
Check whether the DVD is mounted correctly:
mount | egrep cdfss|iso9660
The output should resemble the following example:
/dev/hda on /media/cdrecorder type subfs (ro,nosuid,nodev,fs=cdfss,procuid,iocharset=utf8)
b) How to proceed if an ISO file is your setup source:

mount -o loop OpenScapeApplicationDVD1-<version number>.iso /mnt
Example:
mount -o loop OpenScapeApplicationDVD1-V4R1.500.0.iso /mnt
340
A31003-H8050-J100-09-7631, 09/2011
5.2.4.2 Response File for the Integrated Simplex Deployment

Note: Before creating response files, ensure that the customer administrator or
representative has provided you with the necessary configuration data.
Execute the following steps on the application computer to create a response file
for the application computer.
1. Execute the following command to copy the response file template:
cp /mnt/templates/knut.responsefile.txt.templ_IntegratedSimplex /root/knut.responsefile.txt
Attention: Copy the file as specified to the directory named /root but not to
the Root directory /.
2. Open the response file with an editor (for example with vi):
vi /root/knut.responsefile.txt
3. Look for the following line:
SI_SYMPHONIA_ADMIN_PASSWORD=<PLACEHOLDER_symphonia_admin_pass
word>
Replace <PLACEHOLDER_symphonia_admin_password> with the
password of the Symphonia administrator.
Note: This password must comply with the security policies, which are
defaulted as follows:
- At least 8 characters
- At least one special character
- At least one number
- At least one capital letter
- Not more than 3 identical characters in a row
SI_COMMUNITY_NAME=<PLACEHOLDER_community_name>
A31003-H8050-J100-09-7631, 09/2011
341
Replace <PLACEHOLDER_community_name> with the community name.

Attention: The Community has nothing to do with SNMP.
Capital letters, small letters and underscore are permitted. The latter must not
appear at the beginning or end of the name. The corresponding regular
expression reads as follows:[A-Za-Z0-9][A-Za-Z0-9_]*[A-Za-Z0-9]
Note: The value you assign to SI_COMMUNITY_NAME must be the same in

all knut.responsefile.txt files on all computers (application, front-end
and Media Server computers).
SI_PRIMARY_NODE_HOST=<PLACEHOLDER_hostname>
Replace <PLACEHOLDER_hostname> with the fully qualified domain name
(FQDN) or the (administration subnet) IP address of the Integrated Simplex
server. We recommend using the FQDN.
SI_LOCAL_HOST=<PLACEHOLDER_hostname>
SI_DB_HOST=<PLACEHOLDER_hostname>
SI_DB_LOGON_PASSWORD=<PLACEHOLDER_dbms_dba_password>
Replace <PLACEHOLDER_dbms_dba_password> with the password of the
Solid database administrator. It must not be the default password (dba).
Employ a secret, complex string of characters for the database password.
9. If the response file is created for an upgrade scenario, in which the
applications database has to be migrated from an older release to a new
release, proceed as follows:
a) Look for the following line:
SI_FW_DB_MIGRATION=false
b) Set the migration flag to "true":
SI_FW_DB_MIGRATION=true
10. Verify responsefile on the node:
342
A31003-H8050-J100-09-7631, 09/2011
# cd /mnt
# sh support/checkResponsefileOnLocalNode.sh
11. Ensure that the response file is saved and kept in a safe location. The
response file is not currently contained in the system backup sets, but it is
needed to rebuild the system during a crash recovery.
Note: The restore mechanism uses the database administrator password
from the original system, where the backup was taken, to access the Solid
database. If this password is not known, no recovery is possible. This
password is defined in the response file and that is why the created response
file must be backed up in a safe location.
5.2.4.3 Installation of Integrated Simplex

1. Execute the following commands to install UC Applications applications on
the integrated simplex system.
# cd /mnt
# sh support/installIntegratedSimplex.sh importBuildKey
Note: (If asked to import data into the rpm db, enter y)
# sh support/installIntegratedSimplex.sh install
/root/knut.responsefile.txt
Note: A blank space follows the word "install" in the command above (i.e.,
install /root/knut.responsefile.txt.)
Attention: For proper processing of SNMP traps, the following workaround to

stop the Loquendo Trap Manager Service should be executed on all OpenScape
Voice integrated installations and external (offboard) applications servers acting
as a Survival Authority. This workaround does not apply to a Standalone Survival
Authority.
A31003-H8050-J100-09-7631, 09/2011
343
# /etc/init.d/symphoniad start
Note: DLS is installed by default on the integrated Simplex, to remove run:

rpm -e dls
while the applications are stopped.
5.2.4.4 SSDP Plug-In Installation for Integrated Applications

The SSDP is an optional element of the Openscape Voice solution. The SSDP
(Smart Services Delivery Platform) is a remote service of Siemens Enterprise
Communications and complements the existing SIRA (Secured Infrastructure for
Remote Access) Platform.
For detailed SSDP configuration instructions refer to the OpenScape Voice V5,
System Service Manual, Service Documentation.
Attention: Review the Applications Release Notes to ensure these instructions
have not changed. Any questions should be addressed to the next level of
support.
1. On the OpenScape Voice server with Integrated Applications execute the

following commands as the root user;
# /enterprise/SSDP/installSSDP.sh
2. As the root user verify whether SSDP has been set up correctly by;
a) Executing the following command (a response indicating running is
expected);
# /etc/init.d/service-plugin status
b) Open the file xGate.log in the SSDP setup directory
(default: /opt/ServicePlugin/). After opening this file, look for
Device registered with server, among the entries with the latest
time stamps, which indicates a successful start and communication with
the Enterprise server in the SEN network.
344
A31003-H8050-J100-09-7631, 09/2011
5.2.4.5 Add Languages

Note: For media server announcement, treatments or Prefix Access Code (PAC)
information refer to Appendix J, Media Server Announcements, Treatments and
Prefix Access Code Installation Guide.
The installed image contains English and German languages for

announcements. If any other languages are needed for Integrated systems they
must be installed.
1. Stop the applications:
2. Execute the following commands to add languages on the integrated simplex
system.
# sh support/installIntegratedSimplex.sh addLang <component>
<lang>
e.g. add german language:
#cd/mnt
# sh support/installIntegratedSimplex.sh addLang
mediaserver_announcements de
e.g. add TTS german language:
# sh support/installIntegratedSimplex.sh addLang LoquendoTTS
de
5.2.4.6 Start OpenScape UC Application

1. Execute in the root shell on the OpenScape UC server:
Start of Loquendo:
/etc/init.d/snmpd restart
/etc/init.d/LoquendoManagementContextd start
Start of OpenScapeUC:
/etc/init.d/symphoniad start
A31003-H8050-J100-09-7631, 09/2011
345
5.2.4.7 Update of Integrated Simplex

Attention: Ensure that all workarounds described in the Release Notes were
executed before you start the OpenScape UC Application for the first time. If you
do not perform these workarounds the system may adopt a defective state.
Attention: Uninstall old style Loquendo (lss_uninstall.sh).
Execute the following steps on the application computer.

1. Mount the setup source as follows:
a) How to proceed if a DVD is your setup source:
If the DVD is not mounted automatically, execute the following command
as superuser:
mount /dev/hda /mnt
Check whether the DVD is mounted correctly:
mount | egrep cdfss|iso9660
The output should resemble the following example:
/dev/hda on /media/cdrecorder type subfs
(ro,nosuid,nodev,fs=cdfss,procuid,iocharset=utf8)
b) How to proceed if an ISO file is your setup source:
mount -o loop OpenScapeApplicationDVD1-<version
number>.iso /mnt
Example:
mount -o loop OpenScapeApplicationDVD1-V4R1.500.0.iso /mnt
2. Execute in the root shell on the OpenScape UC server:
#/etc/init.d/symphoniad stop
# cd /mnt
# sh support/installIntegratedSimplex.sh update
#/etc/init.d/symphoniad start
5.2.4.8 Uninstall the Integrated Simplex Applications

Note: It is not possible to uninstall individual patch sets. Uninstall will always
uninstall the whole product.
To uninstall the Integrated Simplex Applications:
346
A31003-H8050-J100-09-7631, 09/2011
1. Stop Sympohnia daemon

/etc/init.d/symphoniad stop
2. Stop the Loquendo Management Context daemon
/etc/init.d/LoquendoManagementContextd stop
3. Stop the Loquendo Trap Manager daemon
/etc/init.d/LoquendoTrapManagerd stop
4. Change the directory path to the uninstall script location.
cd /enterprise/overall_installer
5. The option list can be employed with the uninstall script for an overview of
what has been installed.
sh uninstall.sh list
6. Start the script;
sh uninstall.sh uninstall
7. Uninstall may leave directories in /enterprise (integrated on OpenScape
Voice) which could result in problems with the next Applications installation
on the integrated system. After the uninstall completes execute the following
commands to remove these directories;
cd /enterprise
rm -rf *
5.2.5 Installation/Update Instructions for Media

Server Standalone
Attention: An external (offboard) CMP has a Survival Authority component that
is included as part of the CMP Applications software installation. The Standalone
Survival Authority snmpreceiver rpm IS NOT intended for installation on a CMP.
Installation of the Standalone Survival Authority rpm on a CMP will negatively
impact the CMP snmpreceiver functionality.
The SNMPReciever should only be installed in the case of a Standalone
Survival Authority as described in Section 5.3, Starting and Stopping the
A31003-H8050-J100-09-7631, 09/2011
347
OpenScape Applications, on page 384 .

Setting up the standalone media server is performed by means of the Zypper

program, which is an SLES 10 component.
348
A31003-H8050-J100-09-7631, 09/2011
5.2.5.1 Providing a Server Standalone Setup Medium

The setup medium can be a DVD or an ISO file.
1. The sa option represents service-add. Execute a command according to the
following example:
zypper sa <URI> <Alias>
a) Example of <URI> in case of using a DVD:
zypper sa cd:///?devices=/dev/hdc,/dev/hdd V5R0.300.0
b) Example of <URI> in case of using an ISO file:
zypper sa "iso:///?iso=OpenScapeUcSuiteAppsV5R0.0.0-030000.iso&url=dir:///Images/" V5R0.300.0
In the above example:
iso name: OpenScapeUcSuiteAppsV5R0.0.0-030000.iso
Directory where iso image is installed: /Images
Alias: V5R0.300.0
Note: Replace <Alias> with any character string. If this string contains at
least one blank, it must be enclosed by quotation marks.
2. This output follows:
Determining iso:///?iso=OpenScapeApplicationDVD1-V4R1.500.0.iso&url=
dir:///software/ source type...
iso:///?iso=OpenScapeApplicationDVD1-V4R1.500.0.iso&url=dir:///software/
is type YUM
Added Installation Sources:
[x]* V4.1(iso:///?iso=OpenScapeApplicationDVD1-V4R1.500.0.iso&url=dir:///software/)
3. You can check the result of the action with the following command:
zypper sl
The sl option represents service list.
# | Enab| Refr. | Type | Name
| URI
--+-----+-------+------+-----------+---1 | Yes | Yes | YUM | V5R0.300.0|iso:///?iso=OpenScapeUcSuiteAppsV5R0.0.0-030000.iso&url=dir:///Images/
A31003-H8050-J100-09-7631, 09/2011
349
5.2.5.2 Response File for Media Server Standalone

Execute the following steps to create a response file for the application computer.
cp /mnt/templates/knut.responsefile.txt.templ_MediaServerStandalone /root/
knut.responsefile.txt
word>
350
A31003-H8050-J100-09-7631, 09/2011
(FQDN) or the IP address of the Media server Standalone. We recommend
using the FQDN.
using the FQDN.
using the FQDN.
Replace <PLACEHOLDER_dbms_dba_password> with the password of the
Solid database administrator. It must not be the default password (dba).
Employ a secret, complex string of characters for the database password.
# cd /mnt
A31003-H8050-J100-09-7631, 09/2011
351
5.2.5.3 Installing Media Server Standalone

Installing
1. Enter the following command on the application computer to start the setup.
zypper in OpenScapeUC_MediaServerStandalone
Zypper now determines the packages required for the installation.
The following is put out, for example:
Restoring system sources...
Parsing RPM database...
Summary:
<install> [S2:0][package]scs_licensing_base-2.2_5.0.0-018.noarch
<install> [S2:0][package]scs_licensing_be-2.2_5.0.0-018.noarch
<install> [S2:0][package]symphonia-persistence_common-2.2_5.3.1-060.noarch
...
<install> [S2:0][package]mediaservercommon-3.3_5.4.0-543.i586
Continue? [y/n]
2. Push the y key and conclude with the return key.
Note: Executing this step takes some time.
3. Check for any newer fix release and hotfix versions for the OpenScape UC
Application DVD, and install them according to the corresponding version
notes if applicable.
5.2.5.4 SSDP Plug-In Installation for Media Server Standalone

support.
352
A31003-H8050-J100-09-7631, 09/2011
1. On the Media Server Standalone execute the following command as the root
user;
# zypper in OpenScapeUC_ssdpaddons
expected);
5.2.5.5 Adding Additional Languages

The default installation sets up only the basic language English for the Media
Server telephone prompts. If you wish to install further languages, execute the
following steps:
1. Execute the following command to list the available languages:
zypper se --match-any announ
Attention: Please be sure to enter two hyphens before match.
The following is put out:
Parsing metadata for SUSE Linux Enterprise Server 10 SP3...
Parsing metadata for V4.1...
S | Catalog | Type
| Name
| Version
| Arch
--+---------+---------+----------------------------------+---------------+----| V4.1
| package | mediaserver_announcements_ar
| 3.3_5.3.0-488 | i586
| V4.1
| package | mediaserver_announcements_bg
| 3.3_5.3.0-488 | i586
| V4.1
| package | mediaserver_announcements_bs
| 3.3_5.3.0-488 | i586
| V4.1
| package | mediaserver_announcements_cs
| 3.3_5.3.0-488 | i586
| V4.1
| package | mediaserver_announcements_da
| 3.3_5.3.0-488 | i586
| V4.1
| package | mediaserver_announcements_de
| 3.3_5.3.0-488 | i586
| V4.1
| package | mediaserver_announcements_de_at
| 3.3_5.3.0-488 | i586
| V4.1
| package | mediaserver_announcements_el
| 3.3_5.3.0-488 | i586
i| V4.1
| package | mediaserver_announcements_en _us | 3.3_5.3.0-488 | i586...
A31003-H8050-J100-09-7631, 09/2011
353
Note: The i in the first column marks packages already installed.

2. Execute the following command for installing another language for phone
prompt texts:
zypper in mediaserver_announcements_<language>
<language> stands for the token that represents the language (see column
Name in the above table).
Example:
zypper in mediaserver_announcements_el
Note: This language is used for the Media Server announcements, which are
provided for OpenScape Voice.

Note: When executing the following commands, verify that they are executed by
user root.
Perform the following steps:

1. Enter the following command for starting the OpenScape UC Application:
2. If you need to end it at a later date, execute the following command:
5.2.5.7 Update Media Server Standalone

Execute the following update steps:
354
A31003-H8050-J100-09-7631, 09/2011
1. Log on with user name root.

2. Backup the configuration data of the applications server (select backup type:
DATA) using CMP (Common Management Portal). Make sure that all
available options are selected, except from HiPath8000:[OSC Voice node
name] (e.g. HiPath8000:ATHENSFT). Any questions should be referred to
your next level of support before proceeding.
Attention: Backup archives created from the OpenScape Applications server
can only be restored to the Applications server at that same software level
(DVD / PatchSet / HotFix). Restoring Applications backup archives created at
a different software level is not supported.
3. Use wget, winSCP or scp, for example, to copy the
OpenScapeApplicationDVD1-<version>.iso file to the /software
directory on the application computer.
4. Check the current configuration of the installation sources:
zypper sl
This output follows:
# | Enabled | Refresh | Type | Name | URI
--+---------+---------+------+------+---1 | Yes
| Yes
| YUM | osc32| iso:///?iso=OpenScapeApplicationDVD1V4R1.500.0.iso&url=dir:///software/
5. If the setup medium is older than the one specified in the example output, it
must be deleted by the following command:
zypper sd <Alias>
6. Execute a command according to the following example:
The sa option represents service-add.
7. Execute the following command to configure the new setup medium:
Example of <URI> in case of using an ISO file:
For example,
A31003-H8050-J100-09-7631, 09/2011
355
Alias: V5R0.300.0
You can check the result with zypper sl.
8. Stop the OpenScape UC Application by executing the following command:
9. Execute the following command:
#zypper up -t package
#zypper in OpenScapeUC_MediaServerStandalone
The upgrade process is fully automatic and since no configuration files are
overridden you need not back up these files before the upgrade.
Note: This note applies to the case of an applications failure outside
the scope of a Split Mode Upgrade (SMU) or Migration procedure;
Perform the steps of Section 5.9, Uninstall External Application Server

(OffBoard) Applications.
Re-install the Applications server software to the same level as was

backed up in step 2 of this procedure.
Restore the Applications with the backup set taken in step 2 of this
procedure.
Contact your next level of support before proceeding.
Note: This note only applies to Split Mode Upgrade (SMU) and Migration
procedures. If you arrived here from the Split Mode Upgrade (SMU) and
Migration procedure of Section 5.7.1 or Section 5.7.2 and HotFixes are
required for the External (offboard) Applications server target release then
proceed to Section 5.6, Installing a HotFix, step 2. It is a good practice to
review the HotFix Release Notes in case that procedure differs from the
Installing a HotFix section of this document. The actual HotFix release note
should include detailed instructions.
If there are no HotFixes required for the External (offboard) Applications
target release complete step 10 of this procedure and then return to the
appropriate step of your Split Mode Upgrade (SMU) and Migration
procedure;
Section 8.6, Upgrading a Standard Duplex System (SMU Method), step 18
356
A31003-H8050-J100-09-7631, 09/2011
Section 8.7, Upgrading a Standard Duplex System (Toolkit Method),

step 20
Section 9.1.2, Simplex to Standard Duplex Hardware Migration, step 24
Section 9.1.3, Integrated Duplex to Standard Duplex Hardware Migration
(Node Deployment Unchanged), step 23
(Node Deployment Changed), step 23
Section 9.1.5, Standard Duplex to Standard Duplex Hardware Migration
Section 9.1.7, Low Cost to Standard Duplex Migration, step 22
Section 9.2.1, Simplex to Standard Duplex Product Migration, step 24
Section 9.2.2, Integrated Duplex to Standard Duplex Product Migration
Section 9.2.4, Standard Duplex Node Redeployment Migration, step 21
In case of an applications upgrade failure during a Split Mode Upgrade (SMU)
or Migration procedure refer to Section 5.8, Fallback During Upgrade
Procedure, on page 398 of this document.
Any questions should be referred to your next level of support before
proceeding.
10. Start the OpenScape UC Application when the upgrade process is finished by
executing the following command:
Note: IF HotFixes are required for the External (offboard) Applications
server target release then proceed to Section 5.6, Installing a HotFix, step
2. It is not necessary to start the symphoniad at this time .It is a good practice
A31003-H8050-J100-09-7631, 09/2011
357
to review the HotFix Release Notes in case that procedure differs from the
executed before you start the OpenScape UC Application for the first time. If
you do not perform these workarounds the system may adopt a defective
state.
358
A31003-H8050-J100-09-7631, 09/2011
5.2.6 Installation/Update Instructions for Multiple

Communications Server Admin deployment
The Multiple Communications Server Admin Applications deployment can
administer 10 OpenScape Voice systems. An snmpreceiver installed with the
applications server software allows this deployment to act as a Survival
Authority for the monitored OSV systems. For more Survival Authority details,
refer to Section 6.4, Survival Authority on the CMP, on page 409.
The Multiple Communications Server Admin deployment does not support
UC services/features. Standard Duplex Large or Small Applications server
deployments do support UC services/features. More information on these
deployments can be found in the document "OpenScape UC Application V5,
Installation and Upgrade, Installation Guide".
The SNMPReciever should only be installed in the case of a Standalone
Survival Authority as described in Section 6.5, Installing a Standalone
Survival Authority, on page 411 .
Setting up the Multiple Communications Server is performed by means of the

Zypper program, which is an SLES 10 component.
5.2.6.1 Prepare Installation

The setup medium can be a DVD or an ISO file.
1. The sa option represents service-add. Execute a command according to the
following example:
a) Example of <URI> in case of using a DVD:
zypper sa cd:///?devices=/dev/hdc,/dev/hdd V5R0.300.0
A31003-H8050-J100-09-7631, 09/2011
359
b) Example of <URI> in case of using an ISO file:

Alias: V5R0.300.0
Determining iso:///?iso=OpenScapeApplicationDVD1-V4R1.500.0.iso&url=dir:///software/
source type...
iso:///?iso=OpenScapeApplicationDVD1-V4R1.500.0.iso&url=dir:///software/ is type YUM
Added Installation Sources:
[x]* V4.1(iso:///?iso=OpenScapeApplicationDVD1-V4R1.500.0.iso&url=dir:///software/)
3. You can check the result of the action with the following command:
zypper sl
# | Enab| Refr. | Type | Name
| URI
--+-----+-------+------+-----------+---1 | Yes | Yes | YUM | V5R0.300.0|iso:///?iso=OpenScapeUcSuiteAppsV5R0.0.0-030000.iso&url=dir:///Images/
5.2.6.2 Response File for Multiple Communications Server

Execute the following steps to create a response file.
360
A31003-H8050-J100-09-7631, 09/2011

cp /mnt/templates/knut.responsefile.txt.templ_MultipleCommunicationServerAdmin
/root/knut.responsefile.txt
word>
Note: The value you assign to SI_COMMUNITY_NAME must be the same in

all knut.responsefile.txt files on all computers (application, front-end
and Media Server computers).
A31003-H8050-J100-09-7631, 09/2011
361

(FQDN) or the IP address of the Multiple Communications Server. We
recommend using the FQDN.
Replace <PLACEHOLDER_dbms_dba_password> with the password for the
admin user "dba". It must not be the default password (dba). Employ a
secret, complex string of characters for the database password.
# cd /mnt
362
A31003-H8050-J100-09-7631, 09/2011
5.2.6.3 Installing Multiple Communications Server

Installing
1. Enter the following command on the application computer to start the setup.
zypper in OpenScapeUC_MultipleCommunicationServerAdmin
Zypper now determines the packages required for the installation.
The following is put out, for example:
Summary:
<install> [S2:0][package]symphonia-apache-tomcat-5.5.28-1.noarch
<install> [S2:0][package]scs_licensing_base-2.2_5.0.0-018.noarch
<install> [S2:0][package]scs_licensing_be-2.2_5.0.0-018.noarch
<install> [S2:0][package]symphonia-persistence_common-2.2_5.3.1-060.noarch
...
<install> [S2:0][package]mediaservercommon-3.3_5.4.0-543.i586
Continue? [y/n]
2. Push the y key and conclude with the return key.
Note: Executing this step takes some time.
3. Check for any newer fix release and hotfix versions for the OpenScape UC
Application DVD, and install them according to the corresponding version
notes if applicable.
Attention: For proper processing of SNMP traps, the following workaround
to stop the Loquendo Trap Manager Service should be executed on all
OpenScape Voice integrated installations and external (offboard) applications
servers acting as a Survival Authority. This workaround does not apply to a
Standalone Survival Authority.
A31003-H8050-J100-09-7631, 09/2011
363
5.2.6.4 SSDP Plug-In IInstallation for for Multiple

Communications Server
support.
1. On the Multiple Communication Server execute the following command as

the root user;
# zypper in OpenScapeUC_ssdpaddons
expected);
5.2.6.5 Adding Additional Software

If you wish to install optional software, execute the following steps:

1. Execute the following command to list the desired packages:
# zypper se --match-any dls clm rg8700 openbranch medias
The following is put out:
364
A31003-H8050-J100-09-7631, 09/2011
RRestoring system sources...

Parsing metadata for V4R1DVD5...
S | Catalog
| Type
| Name
| Version
| Arch
--+----------+---------+--------------------------------------------+----------------+------| V4R1DVD5 | package | CLM
| 1.3.0.1-0001
| i586
| V4R1DVD5 | package | OpenBranchAssistant
| 1.0_2.9.1-048
| i586
| V4R1DVD5 | package | OpenScapeUC_MediaServerStandalone
| 3.2_0.15.0-048 | noarch
i | V4R1DVD5 | package | RG8700Assistant
| 3.1_3.8.0-402
| i586
| 3.0_0.742.0-0
| i586
| 3.3_5.6.0-600
| i586
| V4R1DVD5 | package | mediaserver_announcements_ar
| 3.3_5.5.0-583
| i586
| V4R1DVD5 | package | mediaserver_announcements_bg
| 3.3_5.5.0-583
| i586
| V4R1DVD5 | package | mediaserver_announcements_bs
| 3.3_5.5.0-583
| i586
| V4R1DVD5 | package | mediaserver_announcements_cs
| 3.3_5.5.0-583
| i586
| V4R1DVD5 | package | mediaserver_announcements_da
| 3.3_5.5.0-583
| i586
i | V4R1DVD5 | package | mediaserver_announcements_de
| 3.3_5.5.0-583
| i586
| V4R1DVD5 | package | mediaserver_announcements_de_at
| 3.3_5.5.0-583
| i586
| V4R1DVD5 | package | mediaserver_announcements_el
| 3.3_5.5.0-583
| i586
i | V4R1DVD5 | package | mediaserver_announcements_en
| 3.3_5.5.0-583
| i586
| 3.3_5.5.0-583
| i586
| V4R1DVD5 | package | dls

i | V4R1DVD5 | package | mediaserver
| V4R1DVD5 | package | mediaserver_announcements_en_au

2. Stop the applications:
3. Execute the following command to install the OpenBranch Assistant and the
Argentine language for announcements.
zypper in <name>
<name> stands for the token that represents the software component (see
column Name in the above table).
Example:
# zypper in OpenBranchAssistant mediaserver_announcements_ar
A31003-H8050-J100-09-7631, 09/2011
365

Note: When executing the following commands, verify that they are executed by
user root.
Perform the following steps:

1. Enter the following command for starting the OpenScape UC Application:
2. If you need to end it at a later date, execute the following command:
5.2.6.7 Update Multiple Communications Server

Execute the following update steps:
1. Log on with user name root.
3. Use wget, winSCP or scp, for example, to copy the
OpenScapeApplicationDVD1-<version>.iso file to a temporary
directory (e.g /tmp) on the application computer.
4. Check the current configuration of the installation sources:
zypper sl
This output follows:
366
A31003-H8050-J100-09-7631, 09/2011
# | Enabled | Refresh | Type | Name | URI

--+---------+---------+------+------+---1 | Yes
| Yes
| YUM | osc32| iso:///?iso=OpenScapeApplicationDVD1V4R1.500.0.iso&url=dir:///software/
5. If the setup medium is older than the one specified in the example output, it
must be deleted by the following command:
zypper sd <Alias>
6. Execute a command according to the following example:
The sa option represents service-add.
7. Execute the following command to configure the new setup medium:
Example of <URI> in case of using an ISO file:
For example,
Alias: V5R0.300.0
8. Stop the OpenScape UC Application by executing the following command:
9. Execute the following command:
#zypper up -t package
#zypper in OpenScapeUC_MultipleCommunicationServerAdmin
The upgrade process is fully automatic and since no configuration files are
overridden you need not back up these files before the upgrade.
A31003-H8050-J100-09-7631, 09/2011
367
Note: This note applies to the case of an applications failure outside

the scope of a Split Mode Upgrade (SMU) or Migration procedure;
Perform the steps of Section 5.9, Uninstall External Application Server

(OffBoard) Applications.
Re-install the Applications server software to the same level as was

backed up in step 2 of this procedure.
Restore the Applications with the backup set taken in step 2 of this
procedure.
procedures. If you arrived here from the Split Mode Upgrade (SMU) and
Migration procedure of Section 5.7.1 or Section 5.7.2 and HotFixes are
required for the External (offboard) Applications server target release then
proceed to Section 5.6, Installing a HotFix, step 2. It is a good practice to
review the HotFix Release Notes in case that procedure differs from the
If there are no HotFixes required for the External (offboard) Applications
target release complete step 10 of this procedure and then return to the
appropriate step of your Split Mode Upgrade (SMU) and Migration
procedure;
step 20
368
A31003-H8050-J100-09-7631, 09/2011

In case of an applications upgrade failure during a Split Mode Upgrade (SMU)
or Migration procedure refer to Section 5.8, Fallback During Upgrade
Procedure, on page 398 of this document.
Any questions should be referred to your next level of support before
proceeding.
10. Start the OpenScape UC Application when the upgrade process is finished by
executing the following command:
Note: IF HotFixes are required for the External (offboard) Applications
server target release then proceed to Section 5.6, Installing a HotFix, step
2. It is not necessary to start the symphoniad at this time .It is a good practice
to review the HotFix Release Notes in case that procedure differs from the
state.
5.2.6.8 Remote Access for srx Account

On the OpenScape Voice system, edit the /etc/security/access.conf file (on both
nodes in a duplex system) that restricts remote access for root and srx to permit
access for srx as follows:
For example, in the access.conf file, change this:
-:root srx:ALL EXCEPT <list of exception IP addresses which should be the
nodes, the console, and ttys>
A31003-H8050-J100-09-7631, 09/2011
369
To this:
-:root:ALL EXCEPT <list of exception IP addresses which should be the
nodes, the console, and ttys>
-:srx:ALL EXCEPT <IP address of external assistant machine and the list of
original exception IP addresses which should be the nodes, the console, and
ttys>
Note: The IP address in the list (for example: IP address of external assistant
machine) can be a numeric address (for example: 165.218.177.242) or a host
name (for example: h8kAssistant). If the host name is used, make sure that
there is an entry in the /etc/hosts file, for example:
###############################################
# Please add new hosts under this line#
###############################################
165.218.177.242 h8kAssistant
If there is not an entry, add the IP address and host name as the last line of
the /etc/hosts file.
5.2.6.9 Survival Authority on the Multiple Communications

Server Admin deployment
The snmpreceiver is installed with the applications server software in this
deployment. This applications deployment can also act as a Survival Authority
for the monitored OSV systems. For more details regarding the Survival
Authority on a CMP, refer to Section 6.4, Survival Authority on the CMP, on page
409.
5.2.7 Configuring the OSV Connectivity in CMP

Configure the CMP as follows:
1. Log in as administrator (provide the ADMIN_PASSWORD specified in the
response file) to the CMP with the link:
https://<applications server IP address>/management
2. On the CMP home page, select the OpenScape Voice tab, click General,
click List of Switches, click Switches, and click Add. The Add Switch screen
is displayed.
Note: OpenScape Voice was formerly known as HiPath 8000. References to
HiPath 8000 in the following example are equivalent to OpenScape Voice.
370
A31003-H8050-J100-09-7631, 09/2011
3. On the Add Switch screen, place a check in the Use cluster name box, type
the node1 IP address, type the srx password, and click SAVE.
A31003-H8050-J100-09-7631, 09/2011
371
Note: If configuring UC applications proceed with step 4 other wise move

onto Section 5.2.8, Activating IPSec Between OpenScape Voice and the
External Applications Server, on page 381.
4. To configure bcom (CSTA) access to OpenScape Voice: Select the
Operation & Maintenance tab, click Configuration & Monitoring, click
System Status, click Applications. Click the Action arrow on the right side
of the OpenScapeUC Application.
From the drop down list select OS Voice Connection. The OpenScape Voice
Connections window is presented. Select the Add button.
The Add OpenScape Voice Connection window is presented.
a) Update/verify the OpenScape Voice parameters Switch and Version
parameters (required).
b) Update/Verify the CSTA access configuration IP Address and Port
parameters (required).
372
A31003-H8050-J100-09-7631, 09/2011
c) Update/Verify the BCOM configuration Node parameter (required).

d) Update/Verify the SOAP access config configuration IP Address and
Port parameters (required).
e) Click the SAVE button.
f)
If more CSTA server connections are required repeat 4a) through 4e),
otherwise click Close.
5. Complete the office codes: select the Users & Resources tab, click Office
Codes. A list of the imported office codes is displayed. Click the office Code
to edit it. An Edit Office Code dialog box is opened.
6. In the Edit Office Code dialog box, add Overlap, National, International
values, and click Save (note that the office code values that you will see in
these screens are dependant on the site-specific configuration of the
OpenScape Voice server).
A31003-H8050-J100-09-7631, 09/2011
373
7. In the Assistant Settings dialog box, click Synchronize.

8. Add users: Select the Users & Resources tab, click Users, click User
Administration, click Users, and click Add. An Add User dialog box opens.
374
A31003-H8050-J100-09-7631, 09/2011
9. On the General tab of the Add User dialog box, type the Login Name and
Name (for example, the telephone extension) for logging into the CMP. Also,
select the Host time zone, Default language.
10. In the Add User dialog box, click the Password/PIN tab and type the Login
password for CMP, Desktop Client, and WebClient. Only check the Password
never expires box if it does not violate security guidelines.
A31003-H8050-J100-09-7631, 09/2011
375
11. Create import data for importing contacts for the Tab Contact Information
(necessary for global contact lists).
Attention: Please do not configure any contact information before contact
information import is done! Otherwise, it is not possible to add the telephone
number to the contact information in the database (the user is saved in the
global contact list without a telephone number). It is not possible to edit the
contacts data in the global contact list after saving the contact the first time.
Create a Import Data csv file according to the following example template:
##Contact;externalId;middleName;lastName;givenName;displayName;salutation;title;alias
;gender;countryCode;state;postalCode;city;street;buildingNumber;roomNumber;companyNam
e;department;costLocation;domain;assignedPhoneNumber;assignedEmail;assignedSymUserIdentity
Contact;8102@system;;Down;John;;;;;0;;;;;;;;;;;system;+49896228102;;8102@system
Contact;8103@system;;Feller;Allan;;;;;0;;;;;;;;;;;system;+49896228103;;8103@system
Contact;8200@system;;Cramer;Patricia;;;;;0;;;;;;;;;;;system;+49896228200;;8200@system
The first part of the file (see below) is the header part and is essential.
##Contact;externalId;middleName;lastName;givenName;displayName;s
alutation;title;alias;gender;countryCode;state;postalCode;city;s
treet;buildingNumber;roomNumber;companyName;department;costLocat
ion;domain;assignedPhoneNumber;assignedEmail;assignedSymUserIden
tity
In the lines below the header the users can be configured in the following way:
Contact;8102@system;;Last;First;;;;;0;;;;;;;;;;;system;+49896228102;;8102@system
Where the first 8102@system is the configured login name from step 9 on
page 375.
Where Last is the last name (optional).
376
A31003-H8050-J100-09-7631, 09/2011
Where First is the first name (optional).

Where +49896228102 is the telephone number
Where the final 8102@system is the configured login name from step 9 on
page 375.
12. Import the prepared csv file: select the Operation & Maintenance tab, click
Recovery, click Import & Export, and click Import. A Configuration Import
dialog box is opened.
13. On the Configuration Import dialog box, click Browse, select the path where
the csv file is saved, check the Domain Management box, and click Import.
14. In the Add User dialog box, select the Contact Information tab and enter
additional user contact information.
A31003-H8050-J100-09-7631, 09/2011
377
15. In the Add User dialog box, select the Profiles tab, click the radio button for
the desired Profile, and check the corresponding box to assign the profile to
the user. This is necessary so that the User Presence works in the Web
Client. There may be two pages of profile information. Be sure to review each
page of profiles to ensure the correct choices are made.
16. In the Add User dialog box, select the Resources tab, under the User
Devices heading, click Advanced. A Resource List dialog box is opened.
378
A31003-H8050-J100-09-7631, 09/2011
17. In the Resource List dialog box, check the corresponding box for the
extension number, and click Ok. You then return to the Resources tab of the
Add user dialog box.
A31003-H8050-J100-09-7631, 09/2011
379
18. On the Resources tab of the Add User dialog box, click the arrow to the right
of the configured extension and select Set as ONS number. Click Save to
apply the update.
380
A31003-H8050-J100-09-7631, 09/2011
5.2.8 Activating IPSec Between OpenScape Voice and

the External Applications Server
Access from the external OpenScape Applications server to OpenScape Voice
includes sensitive data like SIP access information which should not be
accessible by unauthorized personnel.
One way to achieve this is to install the external OpenScape Applications server
in the same DMZ as OpenScape Voice; this ensures that all internal traffic
between the external applications server and OpenScape Voice is not accessible
by unauthorized personnel.
If this is not possible, another way to protect this information is to activate
encrypted communication between the external applications server and
OpenScape Voice via IPSec.
A31003-H8050-J100-09-7631, 09/2011
381
Configure IPSec on OpenScape Voice using RtpAdmCli on the shell level as

follows:
1. Login to RtpAdmCli with sysad (or comparable) and navigate to:
Main Menu->
Application-level Management->
Network Element Security Management->
Secure EndPoint Device Security Management
2. Create a new secure endpoint as shown in the following example (user input
is bold):
Secure End Point Name <Max Length 63 (max length: 63)> (default: ): <Ext_Asst>
Description <Max Length 63 (max length: 63)> (default: ):
FQDN <Max Length 63 (max length: 63)> (default: ):
Remote IP Address < (max length: 15)> (default: ): <Ext_Asst_IP_Address>
Remote NetMask < (max length: 15)> (default: ): 255.255.255.255
Remote Port <0 = All Ports>:
Local Host < (max length: 32)> (default: ): bond_node_alias
Local Port <0 = All Ports>:
IPSec Profile Name <Max Length 63 (max length: 63)> (default:): IPSEC_ESP
IKE Profile Name <Max Length 63 (max length: 63)> (default: ): IKE_SHA
Key Generation Method <1 = automatic, 2 = user input> (default: 1): 1
Key Length in Bytes (default: 16):
Do you want to execute this action? <y/n> (default: yes):
Operation successful
IPSEC_ESP is a pre configured IPSec profile and IKE_SHA is a preconcerted

IKE profile. The automatic key generation selection (1) lets OpenScape Voice
generate the key.
3. List the newly created secure endpoint to verify the parameters and obtain the
OpenScape Voice generated key as follows:
Secure End Point Name <Max Length 63 (max length: 63)> (default: ): Ext_Asst
Do you want to execute this action? <y/n> (default: yes): y
Total Number of SecEndPts Retrieved : 1
Name: Ext_Asst
Description:
FQDN:
Remote IP Address: <Ext_Asst_IP_Address>
Remote NetMask: 255.255.255.255
Remote Port : 0
Local Host: bond_node_alias
Local Port: 0
IPSec Profile: IPSEC_ESP
IKE Profile: IKE_SHA
Key Gen Method: Automatic
Key Type: Hex
Key Length: 16
Key: 7aa88aecd7f40699884b75795fbf9354
382
A31003-H8050-J100-09-7631, 09/2011
Make a note of the key generated by the OpenScape Voice system and
ensure that it is not accessible by unauthorized personnel.
4. Restart the RTP on both nodes.
5. Before you install IPSec on to the external applications server, use yast to
install the ipsec-tools and gmp packets onto the external applications server.
6. As user root on the external applications server, install the IPSec packages
with the commands:
cd /opt/siemens/assistant/ipsec
sh install.sh
The system will display the status:
Preparing... ######################################## [100%]
1:isakmpd ########################################### [100%]
7. Activate IPSec on the external applications server using the key generated
earlier by the OpenScape Voice system with the command:
sh configure.sh 10.1.250.20 10.1.112.10 <HP8K_Generated_Key>
The system will display the status:
stopping isakmpd done
starting isakmpd done
The 10.1.250.20 IP Address stands for the address of the external
applications server and 10.1.112.10 for the bond_node_alias of the
OpenScape Voice server.
8. To configure IPSec to both nodes of a cluster you have to additionally run the
following command (supposing 10.1.112.20 is the other cluster node):
sh configure.sh 10.1.250.20 10.1.112.20 <HP8K_Generated_Key>
Note: Cluster configuration with IPSec may cause a conflict with the IP Alias
behavior of OpenScape Voice in case of failover. To avoid problems with
IPSec configuration on a cluster, configure the OpenScape Voice system in
the CMP Switch Configuration Screen as Node Separation. There is no harm
in doing that for a normal cluster and it will suppress the usage of the IP Alias.
9. Verify IPSec operation with following command on the OpenScape Voice
system:
tcpdump - iany | grep ESP
If the system displays messages similar to the following when communication
between the external applications server and OpenScape Voice is active,
IPSec is operating properly.
17:09:23.063745 IP 10.1.250.20 > adsa11n1: ESP(spi=0xfb1c7d52,seq=0x16)
17:09:23.064081 IP adsa11n1 > 10.1.250.20: ESP(spi=0x39281790,seq=0x16)
A31003-H8050-J100-09-7631, 09/2011
383
Starting and Stopping the OpenScape Applications

10. OpenScape Voice will log configuration errors in /log/HiQLogSwError.log.
Runtime errors are only logged if the RTP parameter to do so is set. Use the
CLI to set the parameter hiQ/Security/SecMgr/EnableIkeLog to 1. You will
have to login to the CLI as superad. After setting this parameter, restart RTP
(level 3 and 4). You should see an isakmpd.log file in the /var/run directory.
5.2.8.1 Uninstalling IPsec

To uninstall IPSec, delete the secure endpoints on the OpenScape Voice system
and run the following commands on the external applications server:
cd /opt/siemens/assistant/ipsec
sh uninstall.sh
5.2.8.2 IPSec Support for Multiple OpenScape Voice Systems

To use IPSec with multiple OpenScape Voice systems, you have to configure
each OpenScape Voice system (cluster or simplex) as in Section 5.2.8,
Activating IPSec Between OpenScape Voice and the External Applications
Server, on page 381. To add a new IPSec communication between the external
applications server and the OpenScape Voice system use the command:
configure.sh <Ext_Asst_IP_Address> <HP8K_IP_Address> <HP8K_Generated_Key>
To delete all existing IPSec connections to OpenScape Voice systems, use the
command:
configure.sh [-d]
5.3 Starting and Stopping the OpenScape Applications

To start the OpenScape Applications, as user root, enter the command:
To stop, enter the command:
384
A31003-H8050-J100-09-7631, 09/2011
Accessing the OpenScape Applications
5.4 Accessing the OpenScape Applications

5.4.1 Accessing the CMP/OpenScape Voice Assistant
From a web browser, access the CMP/OpenScape Voice Assistant with the URL
https://<IP address>/management and enter the password:
User: administrator@system
password: Provide the ADMIN_PASSWORD specified in the response file.
The IP address you use in the URL to access the CMP/OpenScape Voice
Assistant is dependant on the type of OpenScape Voice system:
Integrated simplex systems

Use the IP address specified by the node_1_ip parameter of the node.cfg
file. From the node1 ssh prompt, run the following command to identify the
node_1_ip IP address:
# grep node_1_ip /etc/hiq8000/node.cfg
Example given;
sysad@x3550st1n1:[/home/sysad] #5
$ grep -i node_1_ip /etc/hiq8000/node.cfg
node_1_ip: 10.235.85.6
lsm_node_1_ip: 10.235.85.8
In this example 10.235.85.6 (the node_1_ip result) would be employed to
access the CMP/OpenScape Voice Assistant.
External OpenScape Applications server

Use the IP address of eth0 of the external applications server. From the
external applications server ssh prompt, run the following command to
identify the eth0 IP address:
# ifconfig eth0
5.4.2 Accessing DLS

From a web browser, access the DLS with the URL https://<IP address
where DLS is installed>/DeploymentService, enter the following user
name and password pair:
User: admin
Password: Siemens2004
Access to the DLS interface is established via the bond_node_alias address.
A31003-H8050-J100-09-7631, 09/2011
385
Retrieving Trace File Information
5.4.3 Accessing CLM

In order to log onto the CLM, modifications have to be made to the
ClmSettings.xml file.
On the integrated system, execute the following commands:
# cd /enterprise/clm/
# sh remoteAccess.sh <IP address 1>,<IP address 2>,<IP address
n>
<IP address 1>,<IP address 2>,<IP address n> are the remote IP addresses to
be allowed access to the CLM.
For example,
# sh remoteAccess.sh 10.5.12.40,10.0.251.42,10.235.65.221
Attention: Verify that no blanks are entered between the IP addresses.
On an external applications server, execute the following commands:

# cd /opt/licenses/clm
# sh remoteAccess.sh <IP address 1>,<IP address 2>,<IP address
n>
<IP address 1>,<IP address 2>,<IP address n> are the remote IP addresses to
be allowed access to the CLM.
Example:
5.5 Retrieving Trace File Information

Note: For information relating to the OpenScape Voice 'SESAP' or 'Trace
Manager';
- For SESAP refer to Section "Continuous Trace" in the OpenScape Voice
V5, Service Manual, Service Documentation, Serviceability Features
- For the OpenScape Voice Trace Manager (OSVTM) refer to the
"OpenScape Voice V5, Trace Manager, Service
Documentation".
386
A31003-H8050-J100-09-7631, 09/2011
The OpenScape Applications include a small tool for easy gathering of diagnostic
information.
Generate and retrieve the trace file as follows:
1. Log in as root on the machine where the Common Management Portal (CMP)
is installed (external server where the OpenScape Applications are installed
for a non-integrated system or OpenScape Voice for an integrated system)
and issue the appropriate command for the type of system:
Standard duplex (external applications server):
# sh /opt/siemens/assistant/scripts/traces.sh
Integrated systems (integrated applications):
# sh /enterprise/assistant/scripts/traces.sh
The system displays information similar to the following example:
adsa11n1:~ # sh /opt/siemens/assistant/scripts/traces.sh
Old trace files deleted.
Storing HiPath 8000 Assistant Traces at adsa11n1-2007-03-0615-30-55
Old trace files deleted.
Storing HiPath 8000 Assistant Traces at adsa11n2-2007-03-0615-30-55
Trace files stored, getting system information...
Trace files stored, getting system information...
Tar and compressing information
Trace Archive created in /opt/siemens/trace
total 1884
-rw-r--r-- 1 root root 1921742 Mar 6 15:31 trace-adsa11n22007-03-06-15-30-55.tar.gz
Tar and compressing information
Trace Archive created in /opt/siemens/trace
trace-adsa11n2-2007-03-06-15-30-55.tar.gz
100% 1877KB 1.8MB/s 00:00
/opt/siemens/trace/trace-adsa11n2-adsa11n1-2007-03-06-15-3055.tar.gz: No such file or directory
tar: /opt/siemens/trace/trace-adsa11n2-adsa11n1-2007-03-0615-30-55.tar: file is the archive; not dumped
total 4488
-rw-r--r-- 1 root root 4579331 Mar 6 15:32 trace-adsa11n2adsa11n1-2007-03-06-15-30-55.tar.gz
The script gathers required information in a compressed tar file archived for
further analysis.
A31003-H8050-J100-09-7631, 09/2011
387
2. To retrieve the trace file from the CMP, click Operation & Maintenance,
Diagnostics, Diagnostics Data, Trace File, and then Download Trace File.
388
A31003-H8050-J100-09-7631, 09/2011
Installing a HotFix
5.6 Installing a HotFix

Hotfixes are usually delivered as ZIP files. They contain:
New RPM packages for the application computer, the front-end computers
and the Media Server computers
New software for Desktop Client, FastViewer, Loquendo etc.
Please refer to the Release Notes to learn which of the above modifications are
contained in the respective hot-fix.
The usual procedure for installing the application computer RPM packages is as
follows:
Note: Check whether the Release Notes contain a procedure that differs from the
one outlined here.
1. Stop the OpenScape UC Application by executing the following command on

the application computer:
3. Place the zip file of the hot-fix in a directory, for example /software, on the
application computer. Unzip the hot-fix file. This creates a subdirectory with
the same name as the hot-fix.
4. Change into the newly created directory named after the hot-fix.
5. Start the hot-fix installer by executing the following command:
sh ./install.sh
A31003-H8050-J100-09-7631, 09/2011
389
Installing a HotFix
6. Start the OpenScape UC Application after the hot-fix installation by executing

the command that follows the series of notes listed below. (Be sure to read
the series of notes below before entering the command.)
state.
Note: This note applies when an applications installation failure

occurs and when this installation is not part of a Split Mode Upgrade
(SMU) or Migration procedure.
Since such an installation failure occurs outside of the scope of a Split
Mode Upgrade (SMU) or Migration procedure, contact your next level
of support before proceeding.
The first activity is dependent upon the applications;
For External (offboard) Applications;
Perform the steps of Section 5.9, Uninstall External Application Server (OffBoard)
Applications.
For Integrated Applications;
Perform the steps of Section 5.2.4.8, Uninstall the Integrated Simplex Applications
Re-install the Applications server software to the same level as was backed up in
step 2 of this procedure.
Restore the Applications with the backup set taken in step 2 of this procedure.
procedures. The addition of required Updates and HotFixes for the target
release External (offboard) Applications server should now be complete.
Return to the appropriate step of your Split Mode Upgrade (SMU) and
Migration procedure;
step 20
390
A31003-H8050-J100-09-7631, 09/2011
Upgrade of External Application Server (OffBoard) Installation

In case of an applications upgrade failure during a Split Mode Upgrade
(SMU) or Migration procedure refer to Section 5.8, Fallback During
Upgrade Procedure, on page 398 of this document.
5.7 Upgrade of External Application Server (OffBoard) Installation

Note: The Upgrade of External Application Server (OffBoard) Installation
sections are related to the Upgrade and Migration of Applications servers to new
releases. To update an Applications server to the latest DVD/PatchSet/HotFix
level refer to one of the following sections as appropriate for your deployment
scenario;
- For DVD/PatchSet Updates
Integrated system deployments;
Section 5.2.4.7, Update of Integrated Simplex
Standalone Media server deployments;
Section 5.2.5.7, Update Media Server Standalone
Multiple Communications Server deployments;
A31003-H8050-J100-09-7631, 09/2011
391
Section 5.2.6.7, Update Multiple Communications Server

- For HotFix Updates (applies to all deployments);
Section 5.6, Installing a HotFix.
Overview
These procedures include the backup/restore procedure of an external
applications server in case a fresh installation of SLES 10 is required, for example
going from SLES 10 SP2 32bit to SLES 10 SP3 64 bit.
After the source release Applications have been restored on the new SLES 10, a
direct applications upgrade will be performed as well. These procedures list the
source to target release applications versions available at the writing of the
procedure. Unless directed otherwise by Release Notes it is a good practice to
start an upgrade with the source release applications at the latest released DVD/
PatchSet/HotFix level. Another good practice is to upgrade the target release to
the latest released DVD/PatchSet/HotFix level (unless directed otherwise by
Release Notes). Any questions should be addressed to your next level of support.
Procedures described;
1. Upgrade V3.1R3 DVD8 to V5 Applications
2. Upgrade V4R1 DVD3 to V5 Applications
5.7.1 Upgrade of V3.1R3 Applications to V5

Applications
1. Update applications server to the latest fix release and HotFix, for example
DVD8 FR5 HotFix2.
More details regarding backing up the configuration data can be found in
section 6.12.1 Backup and Restoration Concept of OpenScape UC
Application V3, Configuration and Administration, Administrator
Documentation.
392
A31003-H8050-J100-09-7631, 09/2011
3. Copy the previously created backup set to an external location. If the default
archive has been used, the backup set folder can be found under /var/
siemens/backup.
The response file used for the initial installation will also have to be saved
externally, as it will be used for the reinstallation of the applications.
In case CLM (Customer License Manager) is installed, save file
ClmSettings.xml, which can be found under /opt/licenses/clm/
ApacheTomcat/. This file contains the access configuration for the CLM.
4. If required install SLES 10 SP3 64bit operating system. If the installation
of the SLES 10 SP3 64 bit operating system is not required go to step
12. It is assumed that the same hardware will be used. Configure the system
with the same IP and hostname.
Note: Section 5.2.1, Installing SLES 10 OS with Appropriate Service Pack
onto the External Applications Server, on page 308 of this document can be
employed as a guide for installing the SLES 10 SP3 64 bit operating system.
Be sure to review the following document section before proceeding
with the SLES install. Section 5.2.1 will provide the same advice.
Documentation
Installation Guide
Server.
5. Reinstall V3.1R3 DVD8 using the saved response file. Reference the
appropriate release notes for installing V3.1R3 DVD8. After V3.1R3 DVD8 is
successfully installed, update the Applications server to the same level that
was backed up in step 2 of this procedure.
6. Copy the saved backup set to /var/siemens/backup.
7. Open the stored ClmSettings.xml file containing the CLM access
configuration. Execute the following commands to create a new
/opt/licenses/clm/ApacheTomcat/ClmSettings.xml file and update the
database:
# sh remoteAccess.sh <IP address 1>,<IP address 2>,<IP
address...>,<IP adddresse n>
Here, <IP address 1>,<IP address 2>,<IP address >,<IPaddress n> are the
IP addresses displayed in the ClmSettings.xml file in field AllowedClients.
Attention: All IP addresses listed in field AllowedClients must be restored.
A31003-H8050-J100-09-7631, 09/2011
393
Example:
# sh remoteAccess.sh
10.235.200.113,10.235.200.28,10.235.65.221
Attention: Verify that no blanks are entered between the IP addresses. The
backed up ClmSettings.xml file was in a different directory (/opt/siemens/clm/
ApacheTomcat/) than the ClmSettings.xml file created here.
8. Start symphonia
9. Restore the backup set using the CMP default archive.
Note: A Container Configuration files warning is acceptable during the CMP
data restore. The requested "WARN Pre/Post action" of "Please restart the
container" is carried out by next step of this procedure.

More details regarding restoring the configuration data can be found in
Documentation. Any questions should be referred to your next level of
10. Stop the Loquendo Trap Manager Service and restart symphonia
Loquendo Trap Manager Service should be executed on all OpenScape
Voice integrated installations and external (offboard) applications servers
acting as a Survival Authority. This workaround does not apply to a
# /etc/init.d/symphoniad restart.
11. Check that all previous configuration, data and functionality have been
restored.
12. Unless directed otherwise by Release Notes the target OpenScape
Applications server should be updated to the latest released V5 DVD/
PatchSet/HotFix level.
394
A31003-H8050-J100-09-7631, 09/2011
To update to the latest DVD/Patchset level (dependent on your external

applications server deployment) reference either;
Section 5.2.6.7, Update Multiple Communications Server, on page 366
Section 5.2.5.7, Update Media Server Standalone, on page 354.
A guide to installing the latest HotFix level can be found in Section 5.6,
Installing a HotFix. It is a good practice to review the HotFix Release Notes
in case that procedure differs from the Installing a Hotfix section of this
document. The actual HotFix release note should include detailed
instructions.
5.7.2 Upgrade of V4R1 Applications to V5

Applications
1. Update applications server to the latest patch set and HotFix, for example
which in our case is DVD3 PS5 HotFix9.
More details regarding backing up the configuration data can be found in
Documentation.
3. Copy the previously created backup set to an external location. If the default
archive has been used, the backup set folder can be found under /var/
siemens/backup.
The response file used for the initial installation will also have to be saved
externally, as it will be used for the reinstallation of the applications.
In case CLM (Customer License Manager) is installed, save file
ClmSettings.xml, which can be found under /opt/licenses/clm/
ApacheTomcat/. This file contains the access configuration for the CLM.
A31003-H8050-J100-09-7631, 09/2011
395
4. If required install SLES 10 SP3 64 bit operating system. If the installation

of the SLES 10 SP3 64 bit operating system is not required go to step
12. It is assumed that the same hardware will be used. Configure the system
with the same IP and hostname.
Note: Section 5.2.1, Installing SLES 10 OS with Appropriate Service Pack
onto the External Applications Server, on page 308 of this document can be
employed as a guide for installing the SLES10 SP3 64 bit operating system.
Be sure to review the following document section before proceeding
with the SLES install. Section 5.2.1 will provide the same advice.
Documentation
Installation Guide
Server.
5. Reinstall V4R1 DVD3 using the saved response file. Reference the
appropriate release notes for installing V4R1 DVD3. After V4R1 DVD3 is
successfully installed, update the Applications server to the same level that
was backed up in step 2 of this procedure
6. Copy the saved backup set to /var/siemens/backup.
7. Open the stored ClmSettings.xml file containing the CLM access
configuration. Execute the following commands to create a new /opt/licenses/
clm/ApacheTomcat/ClmSettings.xml file and update the database:
# sh remoteAccess.sh <IP address 1>,<IP address 2>,<IP
address...>,<IP adddress n>
Here, <IP address 1>,<IP address 2>,<IP address >,<IPaddress n> are the
IP addresses displayed in the ClmSettings.xml file in field AllowedClients.
Attention: All IP addresses listed in field AllowedClients must be restored.
Example:
# sh remoteAccess.sh
10.235.200.113,10.235.200.28,10.235.65.221
Attention: Verify that no blanks are entered between the IP addresses. The
backed up ClmSettings.xml file was in a different directory (/opt/siemens/clm/
ApacheTomcat/) than the ClmSettings.xml file created here.
8. Start symphonia
396
A31003-H8050-J100-09-7631, 09/2011
9. Restore the backup set using the CMP default archive.
container" is carried out by next step of this procedure.

More details regarding restoring the configuration data can be found in
Documentation. Any questions should be referred to your next level of
10. Stop the Loquendo Trap Manager Service and restart symphonia
Loquendo Trap Manager Service should be executed on all OpenScape
Voice integrated installations and external (offboard) applications servers
acting as a Survival Authority. This workaround does not apply to a
# /etc/init.d/symphoniad restart
11. Check that all previous configuration, data and functionality have been
restored.
12. Unless directed otherwise by Release Notes the target OpenScape
Applications server should be updated to the latest released V5 DVD/
PatchSet/HotFix level.
To update to the latest DVD/Patchset level (dependent on your external
applications server deployment) reference either;
Section 5.2.6.7, Update Multiple Communications Server, on page 366
Section 5.2.5.7, Update Media Server Standalone, on page 354.
A31003-H8050-J100-09-7631, 09/2011
397
Fallback During Upgrade Procedure
A guide to installing the latest HotFix level can be found in Section 5.6,
Installing a HotFix. It is a good practice to review the HotFix Release Notes
in case that procedure differs from the Installing a Hotfix section of this
document. The actual HotFix release note should include detailed
instructions.
5.8 Fallback During Upgrade Procedure

5.8.1 Fallback of an Integrated Installation
Fallback of an integrated installation is tied to the OpenScape Voice system
fallback. See the descriptions for fallback in Section 8.11.7, Fallback for Toolkit
Upgrades/Migrations, on page 528.
Attention: In some failure scenarios a Fallback to the source release
partition may not be necessary.
5.8.2 External Application Server (OffBoard)

Installation Fallback from V5 Applications to V3.1R3
DVD8
In case applications fallback is required, uninstall the V5R0 DVD4 applications
(Section 5.9, Uninstall External Application Server (OffBoard) Applications, on
page 400).
After successfully uninstalling the applications reinstall the V3.1R3 DVD8
applications. Restore the V3.1R3 DVD8 applications to the version level that the
backup was taken from in step 2 of the upgrade procedure. Restore the system
398
A31003-H8050-J100-09-7631, 09/2011
Fallback During Upgrade Procedure
configuration data using the backup set created in step 2 of the upgrade
procedure. Steps 6 through 10 of the upgrade procedure can be used as a guide
for restoring the system configuration data.
container" is carried out by restarting symphonia after the data restore completes.
Attention: Any questions should be addressed to your next level of support

before proceeding. Backup archives created from the OpenScape Applications
server can only be restored to the Applications server at that same software level
(DVD / PatchSet / HotFix). Restoring Applications backup archives created at a
different software level is not supported.
5.8.3 External Application Server (OffBoard)

Installation Fallback from V5 Applications to V4R1
DVD3
In case applications fallback is required, uninstall the V5R0 DVD4 applications
(Section 5.9, Uninstall External Application Server (OffBoard) Applications, on
page 400).
After successfully uninstalling the applications reinstall the V4R1 DVD3
applications. Restore the V4R1 DVD3 applications to the version level that the
backup was taken from in step 2 of the upgrade procedure. Restore the system
configuration data using the backup set created in step 2 of the upgrade
procedure. Steps 6 through 10 of the upgrade procedure can be used as a guide
for restoring the system configuration data.
container" is carried out by restarting symphonia after the data restore completes.
Attention: Attention: Any questions should be addressed to your next level of

support before proceeding. Backup archives created from the OpenScape
Applications server can only be restored to the Applications server at that same
software level (DVD / PatchSet / HotFix). Restoring Applications backup archives
created at a different software level is not supported.
A31003-H8050-J100-09-7631, 09/2011
399
Uninstall External Application Server (OffBoard) Applications
5.9 Uninstall External Application Server (OffBoard) Applications

Attention: Important Hint: This feature requires SLES 10 SP2 or SP3.
These instructions use the zypper tool. For help with the zypper tool;
# zypper h
For help with a zypper command;
# zypper <command>
To remove OpenScape Applications software, please perform following steps:

1. First stop the OpenScape UC Application services:
2. Verify the proper iso is present in the service list;
# zypper sl
is output follows:
# | Enabled | Refresh | Type
| Name
| URI
--+---------+---------+-------+------------+------------------1 | Yes
| Yes
| YUM | V4R1DVD4
| iso:///
?iso=OpenScapeApplicationDVD1-V4R1.400.0.iso&url=dir:///Images/
If the correct iso file is not listed;
# zypper sd V4R1DVD4
Add the proper iso file to the service list;
# zypper sa "iso:///?iso=OpenScapeApplicationDVD1V4R1.500.0.iso&url=dir:///Images/" V4R1DVD5
Verify the proper iso is present in the service list;
# zypper sl
# | Enabled | Refresh | Type
| Name
| URI
--+---------+---------+-------+------------+------------------1 | Yes
| Yes
| YUM | V4R1DVD5 | iso:///
?iso=OpenScapeApplicationDVD1-V4R1.500.0.iso&url=dir:///Images/
3. Remove the packages. Package names are case sensitive. Problems may be
reported during the uninstall process. In the following uninstall example
common problems observed and their resolutions are presented. An
explanation of the problem and its resolution precedes each problem
example. The explanations and resolution text will be in italicized text.
Syntax: zypper remove <Alias>
400
A31003-H8050-J100-09-7631, 09/2011
# zypper rm symphonia-solid symphonia-jre-ibm symphoniaapache-tomcat HiPath8000Assistant OpenBranchAssistant

RG8700Assistant
Rpm-packages may report a locked and cannot be uninstalled problem. The
user will then be prompted with 3 solutions to resolve the problem (Solution
1 thru 3). For this case choose solution 2 to resolve the problem. At the
writing of this instruction the user must manually confirm this solution for
every rpm-package reporting this problem. Example given;
1 Problems:
Problem: symphonia-symdb-2.0-0.7.1.noarch is locked and
cannot be uninstalled.
Problem: symphonia-symdb-2.0-0.7.1.noarch is locked and
cannot be uninstalled.
Solution 1: unlock symphonia-symdb
Solution 2: unlock all resolvables
Solution 3: keep symphonia-symdb
keep symphonia-symdb-2.0-0.7.1.noarch
number, (r)etry or (c)ancel> 2
Applying solution 2
Every rpm-package which reports a missing dependencies problem will

present the user with 4 solutions to resolve the problem (Solution 1 thru 4).
Choose solution 2 for deleting the rpm-package. At the writing of this
instruction the user must manually confirm this solution for every rpmpackage reporting this problem. An example missing dependencies
problem list and two resolution examples follow (this example missing
dependencies list is edited to save space);
;
40 Problems:
Problem: scs_backup_common-2.2_5.8.0-122.noarch has missing
dependencies
Problem: scs_provisioning-2.2_2.4.0-058.noarch has missing
dependencies
.
.
.
Problem: mediaserver-3.3_5.6.0-600.i586 has missing
dependencies
A31003-H8050-J100-09-7631, 09/2011
401
Problem: symphonia-activemq-2.2_5.8.0-122.noarch has missing

dependencies
Problem: scs_backup_common-2.2_5.8.0-122.noarch has missing
dependencies
There are no alternative installed providers of symphonia >=
2.2_5.3 for scs_backup_common-2.2_5.8.0-122.noarch
Solution 1: keep symphonia
keep symphonia-2.2_5.8.0-122.i586
Solution 2: delete scs_backup_common
delete scs_backup_common-2.2_5.8.0-122.noarch
Solution 3: Ignore this requirement just here
Solution 4: Ignore this requirement generally
Applying solution 2
.
.
.
Problem: symphonia-activemq-2.2_5.8.0-122.noarch has missing
dependencies
There are no alternative installed providers of symphonia >=
2.2_3.0.0 for symphonia-activemq-2.2_5.8.0-122.noarch
Solution 1: keep symphonia
keep symphonia-2.2_5.8.0-122.i586
Solution 2: delete symphonia-activemq
delete symphonia-activemq-2.2_5.8.0-122.noarch
Solution 3: Ignore this requirement just here
Solution 4: Ignore this requirement generally
Applying solution 2
After manually confirming this solution (for every rpm-package) a summary

will be displayed confirming the rpms which are going to be uninstalled. After
the summary display completes the user is presented with the option to
Continue?. Choose the y (yes) option to remove the packages. The system
will then log the removal of each package to the terminal. An example of this
activity follows (this example list is edited to save space);;
Summary:
<uninstall> [S0:0][package]scs_backup_common-2.2_5.8.0122.noarch
402
A31003-H8050-J100-09-7631, 09/2011
<uninstall> [S0:0][package]scs_provisioning-2.2_2.4.0058.noarch
.
.
.
<uninstall> [S0:0][package]symphonia-jre-ibm-5.0.11.0-1.i386
<uninstall> [S0:0][package]symphonia-activemq-2.2_5.8.0122.noarch
Continue? [y/n]: y
Removing: [S0:0][package]scs_backup_common-2.2_5.8.0122.noarch
Removing: [S0:0][package]scs_provisioning-2.2_2.4.0058.noarch
.
.
.
Removing: [S0:0][package]symphonia-jre-ibm-5.0.11.0-1.i386
Removing: [[S0:0][package]symphonia-activemq-2.2_5.8.0122.noarch
#
4. It is possible that all dependencies are not recognized and a Invalid object
error is observed. These rpm packages must be removed manually. Example
given;
Removing: [S0:0][package]scs_domain_common-2.2_5.3.4004.noarch
Invalid object
# rpm e scs_domain_common
5. The applications should now be removed. It is a good practice to check

whether all rpm-packages of the OpenScape Applications have been
removed.
# /opt/siemens/common/bin/productInventory.sh -a list -L
-bash: /opt/siemens/common/bin/productInventory.sh: No such
file or directory
# zypper se --match-any symphonia-solid symphonia-jre-ibm
symphonia-apache-tomcat HiPath8000Assistant
OpenBranchAssistant
A31003-H8050-J100-09-7631, 09/2011
403
RG8700Assistant
S | Catalog
| Type
| Name
| Version
| Arch
--+----------+---------+-------------------------+----------------+------| V4R1DVD5 | package | HiPath8000Assistant
| 4.0_1.17.2-356 | i586
| V4R1DVD5 | package | HiPath8000AssistantSync | 4.0_1.17.2-356 | i586
404
| V4R1DVD5 | package | OpenBranchAssistant
| 1.0_2.9.1-048
| i586
| V4R1DVD5 | package | RG8700Assistant
| 3.1_3.8.0-402
| i586
| V4R1DVD5 | package | symphonia-apache-tomcat | 5.5.28-3
| noarch
| V4R1DVD5 | package | symphonia-jre-ibm
| 5.0.11.0-1
| i386
| V4R1DVD5 | package | symphonia-solid
| 4.5-175.1
| i586
A31003-H8050-J100-09-7631, 09/2011
survival_authority_ipmi_sal.fm
Survival Authority and IPMI Shutdown Agents
6 Survival Authority and IPMI Shutdown Agents

OpenScape Voice cluster communication failures are handled by the OSV
shutdown agents sa_ipmi and sa_down. The sa_ipmi shutdown agent tries to
verify a partner node failure by sending ipmi commands to the mtc controller of
the partner node (e.g., IMM, iRMC) while the sa_down shutdown agent
communicates with the Survival Authority to decide whether to switchover, shut
down or enter StandAlone operation.
A snmpreceiver should only be installed in the case of a Standalone Survival
Authority as described in Section 6.5, Installing a Standalone Survival Authority,
on page 411.
In OpenScape Voice V4 (and later releases) the Standalone Service option is

available for duplex configurations. If it is enabled, a node that does not receive
permission to take over from the Survival Authority stays active (in Standalone
Secondary mode). For more information regarding the Standalone Service
feature refer to Section 2.5, Creating a Node.cfg File, on page 35, step 4 of this
document or to the OpenScape Voice V5, Feature Description documentation,
section "Survival Authority".
The Survival Authority and IPMI Shutdown Agents are installed with the
OpenScape Voice image.
The Survival Authority shutdown agent (sa_down) employs the node.cfg Survival
Authority IP address as the Survival Authority. The external (offboard) CMP has
a Survival Authority component that is included as part of the CMP
Applications software installation.
The IPMI shutdown agent (sa_ipmi) employs the node.cfg RSA IP addresses as
the IPMI remote administrative IP addresses.
The sa_ipmi shutdown agent is NOT applicable to a Virtual OSCV
environment.
The sa_down and sa_ipmi shutdown agents are applicable to non-Virtual
OSCV environments.
A31003-H8050-J100-09-7631, 09/2011
405
Shutdown Agent Overview (Non-Virtual environment)
Changes to the shutdown agent configuration files are not recommended.

It is a good practice to always consult the next level of support before
changing any shutdown agent file configuration. If a customer alters the
shutdown agent file configuration, the updated files must be verified after every
patch set and MOP installation because the default (expected) settings may be
restored.
The USERID:PASSWORD credentials of the sa_ipmi shutdown agent can be
changed. Refer to Section 4.4.2, Changing the User ID and Password for the
IMM/iRMC Account, on page 284 of this document. This activity should have
been addressed during installation of the OSCV image Section 2.2.4,
OpenScape Voice Installation Checklist, on page 24 task 11.
To change the sa_ipmi shutdown agent RSA IP addresses employ the IFgui tool
in Update mode. Refer to Appendix F, Updating the Node.cfg File (Also Known
as EZIP).
If the CMP is not used as a survival authority (e.g., because it is co-located with
one of the OSV nodes and not the other) a Standalone Survival Authority can be
created. Refer to Section 6.3, Hints on Survival Authority placement, on page
408 and Section 6.7, Verifying the Shutdown Agents Configuration, on page
418.
6.1 Shutdown Agent Overview (Non-Virtual environment)

Attention: The sa_ipmi and sa_down shutdown agents are applicable to NonVirtual OSCV environments.
When the x-channel between the two OSCV nodes fails, each OSCV node tries
to avoid a 'split-brain' situation by power cycling the partner node via the
Maintenance Controller interface (whether Stand Alone Service is enabled or
not). The sa_ipmi shutdown agent is employed for this purpose.
If this power cycle does not work the nodes block the x-channel and contact the
Survival Authority (via the sa_down shutdown agent), which responds to one
node with 'takeover' and to the other with 'shutdown'. It is possible that the
Survival Authority does not respond at all (example given; due to network issues).
The OSV node treats a missing response from the survival authority as having
received 'shutdown'.
If the StandAlone feature is disabled;
The node that received 'takeover' switches over as in a partner node failure
The node that received 'shutdown' (or no response at all) shuts down.
If the StandAlone feature is enabled;
406
A31003-H8050-J100-09-7631, 09/2011
Shutdown Agent Overview (Virtual environment)
The node that received 'takeover' becomes 'stand-alone-primary'
The node that received 'shutdown' (or no response at all) becomes 'standalone-secondary'. It is possible that both nodes enter the standalonesecondary state.
Nodes in standalone do not takeover the virtual IP addresses, especially all

signaling IPs of the partner node, which is a functional restriction for L2-geoseparation. The reason is that a node in a StandAlone mode has to assume
that the partner node is active. In standalone, both nodes support all
subscribers. It does not matter where the registration took place, since
registrations are replicated between the nodes. Of course, new registrations
in standalone cannot be replicated. This is done as soon as the x-channel is
restored.
StandAlone Service is the default when node.cfg parameter Node Separation

= separate is selected.
If Node Separation = none is selected in the node.cfg then Stand Alone
service must be enabled manually.
The Stand Alone feature can be configured while creating the node.cfg file when
preparing to install an OSC Voice cluster (refer to Section 2.5, Creating a
Node.cfg File Step 4 on page 36.
For clusters already in-service, if it is necessary to change the Stand Alone
Service feature refer to Appendix F, Updating the Node.cfg File (Also Known as
EZIP)
6.2 Shutdown Agent Overview (Virtual environment)

Attention: Only the sa_down shutdown agent is applicable to a Virtual OSCV
environment
When the x-channel between the two OSCV nodes fails, each OSCV node tries
to avoid a 'split-brain' situation by contacting the Survival Authority (via the
sa_down shutdown agent), which responds to one node with 'takeover' and to the
other with 'shutdown'. It is possible that the Survival Authority does not respond
at all (example given; due to network issues). The OSV node treats a missing
response from the survival authority as having received 'shutdown'.
If the StandAlone feature is disabled:
The node that received 'takeover' switches over as in a partner node failure
The node that received 'shutdown' (or no response at all) shuts down.
If the StandAlone feature is enabled:

A31003-H8050-J100-09-7631, 09/2011
407
Hints on Survival Authority placement
The node that received 'takeover' becomes 'stand-alone-primary'
The node that received 'shutdown' (or no response at all) becomes 'standalone-secondary'. It is possible that both nodes enter the standalonesecondary state.
Nodes in standalone do not takeover the virtual IP addresses, especially all

signaling IPs of the partner node, which is a functional restriction for L2-geoseparation. The reason is that a node in a StandAlone mode has to assume
that the partner node is active. In standalone, both nodes support all
subscribers. It does not matter where the registration took place, since
registrations are replicated between the nodes. Of course, new registrations
in standalone cannot be replicated. This is done as soon as the x-channel is
restored.
For the StandAlone Service feature to be available in a virtual environment the

node.cfg parameter Node Separation = separate must be selected. The Stand
Alone Service is enabled by default in this configuration.
The Stand Alone feature can be configured while creating the node.cfg file when
Node.cfg File Step 4 on page 36.
For clusters already in-service, if it is necessary to change the Stand Alone
Service feature refer to Appendix F, Updating the Node.cfg File (Also Known as
EZIP).
6.3 Hints on Survival Authority placement

For the survival authority to be useful, it cannot be placed within a failure unit that
is common to either node of the cluster. A simple example of a common failure
unit would be a node and the Survival Authority sharing a common power source.
Another example for this rule; if the two nodes are in different locations (the
meaning of geo redundancy), the survival authority should be in a third location.
The survival authority has to survive a disaster that disables one location in order
to support the failover of the surviving node in the other location.
If both nodes are in the same data center, the survival authority can be in that data
center, but not on a server hosting one of the nodes. There is still a potential for
a common failure unit in this configuration.
The OSCV cluster with the Stand Alone Service enabled may be considered an
exception to this rule. With Stand Alone service enabled it may be ok to co-locate
the survival authority with one OSV node, if the OSV node is in the same failure
unit as the CMP or the provisioning systems. If the provisioning system fails
together with the OSV node and the survival authority, the surviving node
408
A31003-H8050-J100-09-7631, 09/2011
Survival Authority on the CMP
transitions to the standalone-secondary operation mode. This mode means call

processing, but blocking of all provisioning. This could be acceptable, because
the provisioning system is not functioning either.
6.4 Survival Authority on the CMP

The survival authority function can be provided by the CMP or by a Standalone
Survival Authority.
If the CMP cannot be used as survival authority, because it may fail together with
one of the OSV nodes, the standalone survival authority can be installed. Refer
to Section 6.3, Hints on Survival Authority placement, on page 408 and Section
6.5, Installing a Standalone Survival Authority, on page 411.
The Standard Duplex Large, Standard Duplex Small and Multiple
Communications Server Admin applications deployments include a snmpreceiver
as part of the Applications software installation. The snmpreceiver allows these
CMP deployments to act as a Survival Authority for their monitored OSV
systems.
Attention: Installation of the Standalone Survival Authority rpm on a CMP will
negatively impact the CMP snmpreceiver functionality.
A snmpreceiver should only be installed in the case of a Standalone Survival
Authority as described in Section 6.5, Installing a Standalone Survival Authority,
on page 411.
For the CMP to function as the survival authority of an OpenScape Voice cluster,
the CMP needs to manage this cluster and the cluster needs to be configured with
the CMP IP address as the Survival Authority.
The Survival Authority can be configured while creating the node.cfg file when
Node.cfg File Step 4 on page 36).
For clusters already in-service, if it is necessary to change the Survival Authority
IP address in the OpenScape Voice nodes, refer to Appendix F, Updating the
Node.cfg File (Also Known as EZIP). The EZIP feature will require system
downtime to perform this update. If the customer cannot accept system
downtime, the voice server Survival Authority can also be configured via the Cli.
The result of a successful Cli execution is the Survival Authority configuration files
and the firewall (packet filtering rules) of the OpenScape Voice server are
updated. The node.cfg file on the OSCV server will not be updated with the
'new' Survival Authority IP address.
A31003-H8050-J100-09-7631, 09/2011
409
Survival Authority on the CMP
Subsequent node.cfg files built in Upgrade or IFgui Update (aka EZIP)

procedures will reflect the 'new' Survival Authority because these procedures
build the node.cfg from the OpenScape Voice database (not the node.cfg resident
on the OSCV system). A prerequisite for this Cli update is knowing the IP address
of the Survival Authority system.
a) To execute the Survival Authority update with Cli, as user root on the voice
server primary node, issue the following:
# su - srx -c "startCli -x"
b) Log in as user sysad.
c) At the CLI> prompt, run the following commands. These two commands
remove packet filter rules that are not needed. Responses indicating the packet
filter rules do not exist are acceptable.
pktFltrRulesRemove "SnmpStandaloneSurvAth1"
d) The Survival Authority configuration files and firewall (packet filtering rule) of
the OpenScape voice server are configured with the
'mainSetSurvivalAuthority' command (these commands are NOT case
sensitive). At the CLI> prompt, run the following command (replace <HOST IP>
with the IP address of the Survival Authority:
mainSetSurvivalAuthority "<HOST IP>"
e) To display the 'new' survival authority IP execute the following command;
mainGetSurvivalAuthority
f) To verify the 'new' survival authority configuration refer to Section 6.7, Verifying
the Shutdown Agents Configuration, on page 418.
410
A31003-H8050-J100-09-7631, 09/2011
Installing a Standalone Survival Authority
6.5 Installing a Standalone Survival Authority

In case you prefer to install the survival authority on a third SLES 10 SP3 machine
(Standalone Survival Authority) instead of your External Applications Server, you
must;
install in advance the standalone survival authority on a third SLES 10 SP3

machine
configure the needed packet filter rules on your duplex voice server (colocated or geographically separated) for the standalone survival authority
application.
Additionally, the firewall on the third machine must either be disabled or packet
filter rules need to be created on the third machine in order to allow the required
SNMP messages to be exchanged between the standalone survival authority and
the standard duplex nodes (co-located or geographically separated).
The minimum hardware, software, and performance requirements for the
standalone survival authority are as follows:
Intel or AMD processor
SLES 10 SP3
Minimum of 500 MB RAM
Non-volatile storage (for example: disk or compact flash)
One or more Ethernet ports
Enough performance that the time between SNMP trap and corresponding
SET is below two seconds under maximum PC load.
Note: Maximum load is defined by the customer based on the customerprovided applications that might be installed on the PC in addition to the
survival authority (the stand-alone CLM may also be installed on this PC).
A31003-H8050-J100-09-7631, 09/2011
411
6.5.1 Installing the Java Runtime Environment

The snmpreceiver needs Java runtime environment (JRE) version equal to or
greater than v1_5_0_12. The standard SLES 10 SP3 distribution comes with
java-1.5. Install it using the yast2 tool as follows:
1. Run yast2 with the command:
# yast2
2. Select Software and then Software Management.
3. In the Search In frame select the RPM provides check box. The Name and
Summary checkboxes should already be selected.
4. In the Search list type jre, and then select Search.
5. Place a check mark in the RPM provides check box and click Search.
6. Select jre 1.5 from the search results. Select the Accept button.
This package should resolve any dependencies, but any jre greater than or
equal to 1_5 is acceptable.
6.5.2 Installing the Standalone Survival Authority

Install the standalone survival authority onto a third SLES 10 SP3 machine as
follows:
1. Insert the OpenScape Applications DVD into the DVD drive of the Linux
machine and issue the commands:
#mount o loop <filename_of_iso_distribution>.iso /mnt
#cd /mnt/i586/
#ll snmp*
#rpm -i snmpreceiver-1-0.xx.i586.rpm
Where xx = the version.
Examples given;
# mount -o loop OpenScapeUcSuiteAppsV5R0.0.0-030000.iso /mnt
#cd /mnt/i586/
# ll snmp*
-rw-r--r-- 1 wwwrun 18306 910298 Feb 16 07:17 /mnt/i586/snmpreceiver-15.03.i586.rpm
# rpm -i snmpreceiver-1-5.03.i586.rpm
The standalone survival authority daemon will start automatically.
2. The Standalone survival authority can be configured to specific IP, read/write
communities and versions of multiple H8K nodes.
412
A31003-H8050-J100-09-7631, 09/2011
a) There is a configuration file in the survival authority dir (/opt/siemens/

survival_authority) named assistant. The default file configuration is as
follows:
export HIPATH8000NODE1=localhost
export SNMPREAD1=public
export SNMPWRITE1=public
export VERSION1=12.00.02.ALL.15
export HIPATH8000NODE2=127.0.0.1
b) The Survival Authority can be configured by editing the entries in this file.
Change the HIPATH8000NODE1 parameter value from "localhost" to the
IP address of Node1 (<node_1_ip> in node.cfg) and the
HIPATH8000NODE2 parameter value from "127.0.0.1" to the IP address
of Node2 (<node_2_ip> in node.cfg). Enter the appropriate software
version for the nodes being added.
Note: For the V5R0 OSV switch only; there is no need to add the two
lines referring to the community strings for Survival Authority
(SNMPREAD, SNMPWRITE). A OSV V5.0 example follows;
export VERSION1=V5.00.01.ALL.11
export VERSION2=V5.00.01.ALL.11
An example of the assistant file after an edit to add a set of V3.1R3 nodes
follows;
A31003-H8050-J100-09-7631, 09/2011
413
c) Additional nodes can be configured by entering additional sets of entries

to the file. Be careful to;
Maintain the numbering convention as indicated for the export

parameter entries. E.g.; the next set of nodes entered in this
configuration file would employ 3 and 4 for the export parameter
references.
Enter the appropriate software version of the nodes being added.
In this example a V4 voice server cluster has been added to the Survival
Authority configuration;
export VERSION3= V4.00.01.ALL.40
export VERSION4= V4.00.01.ALL.40
3. After the Survival Authority configuration restart the daemon by running the
following command:
#/etc/init.d/snmpreceiverd restart
The daemon status can be verified by running the following command:
#/etc/init.d/snmpreceiverd status
4. After successful installation of the Standalone Survival Authority, configure
the OpenScape Voice packet filtering rules as follows:
414
A31003-H8050-J100-09-7631, 09/2011
a) Obtain the IP address of the Standalone Survival Authority system. From

a command line on the Standalone Survival Authority run:
# ifconfig
In the command output result, the eth0 interface IP address is the IP
address of the Standalone Survival Authority system. Use this IP address
in place of <HOST IP> for the command listed in step 4e).
b) To complete the configuration, as user root on the voice server primary
node, issue the following:
# su - srx -c startCli -x
c) Log in as user sysad.
d) At the CLI> prompt, run the following commands. These two commands
remove packet filter rules that are not needed. Responses indicating the
packet filter rules do not exist are acceptable.
e) The voice server firewall is opened for the Standalone Survival Authority
with the mainsetsurvivalauthority command. At the CLI> prompt, run the
following command (replace <HOST IP> with the IP address of the
Standalone Survival Authority identified in step 4a):
mainSetSurvivalAuthority "<HOST IP>"
5. In order for the standalone survival authority machine to have access to the
Internet it is recommended that its firewall is enabled (the firewall is disabled
by default in SLES 10 SP3) and its firewall rules are configured accordingly
as follows:
a) On the standalone survival authority machine, run yast2 with the
command:
# yast2
b) Select Computer, Firewall, and Allowed Services.
c) On the Allowed Services screen, select Allow Service for External use,
select DHCP service, and click Advanced.
d) In the Additional Allowed Ports window, enter the following values:
TCP Ports: 161 162
UDP Ports: 161 162 8163
RPC Ports: <Leave blank>
IP Protocols: snmp
e) Click OK in the Additional Allowed Ports window.
f)
On the Allowed Services screen, select Allow Service for Internal use,
select DHCP service, click Advanced, enter the values in step d on page
415, and click OK in the Additional Allowed Ports window.
A31003-H8050-J100-09-7631, 09/2011
415
Updating the Standalone Survival Authority
g) On the Allowed Services screen, select Allow Service for External use,
select SSH service, and click Advanced.
h) In the Additional Allowed Ports window, enter the following values:
TCP Ports: <Leave blank>
UDP Ports: 22
RPC Ports: <Leave blank>
IP Protocols: ssh
i)
On the Allowed Services screen, select Allow Service for Internal use,
select SSH service, click Advanced, enter the values in step h on page
416, and click OK in the Additional Allowed Ports window.
j)
Perform similar steps to allow HTTP (Internet) access.
k) Enable the firewall (it is disabled by default) as follows: Select Computer,

Firewall, Startup, choose either Manually or When Booting (as
preferred), click Start Firewall Now, and click Next.
The Firewall Configuration: Summary screen is displayed.
l)
In the Firewall Configuration: Summary screen, confirm that the

configuration is as desired and click Accept.
Note: After installation of the standalone survival authority, verify the survival
authority configuration (refer to Section 6.7, Verifying the Shutdown Agents
Configuration, on page 418).
6.6 Updating the Standalone Survival Authority

This section is intended to provide instructions for updating the Standalone
Survival Authority rpm.
It is a good practice to verify the survival authority configuration before
proceeding. Refer to Section 6.7, Verifying the Shutdown Agents Configuration,
on page 418. For this case we are particularly concerned with the Survival
Authority shutdown agent (sa_down) test result.
This procedure should be continued only if the 'sa_down' test result returns
success.
A list of the OpenScape Voice systems this StandAlone Survival Authority
supports can be found in the file named 'assistant' (located on the StandAlone
Survival Authority in /opt/siemens/survival_authority).
It is expected the following commands be executed as user root.
416
A31003-H8050-J100-09-7631, 09/2011
Updating the Standalone Survival Authority
1. Verify the version of the snmpreceiver package already installed;

# rpm -qa | grep -i snmpreceiver
The version of the installed snmpreceiver package is presented. Example:
snmpreceiver-1-5.04
Note: If the installed snmpreceiver is already at the appropriate version level,
do not proceed; otherwise, continue with the update procedure. Continue
with steps 2 through 11 below.
2. Copy the snmpreceiver package to the Stand Alone Survival Authority.
3. Backup the 'Applications' configuration file by copying the file to a
temporary storage location on the server. This example uses the /tmp
directory;
# cd /opt/siemens/survival_authority
# cp -p assistant /tmp/assistant.bak
4. Stop the SNMP receiver daemon.
# /etc/init.d/snmpreceiverd stop
The expected response is stopping survival authority
done
5. Verify the daemon is stopped.

# /etc/init.d/snmpreceiverd status
The expected response is dead
6. Uninstall the snmpreceiver package.
# rpm -e snmpreceiver
The expected response is stopping survival authority
done
7. From the path where the snmpreceiver package was copied, install the
new snmpreceiver package.
# rpm -ivh --replacefiles --replacepkgs snmpreceiver<version_number>.rpm
It is expected the rpm is successfully installed.
8. Restore the backed up 'Applications' configuration file.
# cd /opt/siemens/survival_authority
# cp -p /tmp/assistant.bak .
# cp -p assistant.bak assistant
9. Start the SNMP receiver daemon.
# /etc/init.d/snmpreceiverd start
The expected response is starting survival authority
running
10. Verify the daemon status.

# /etc/init.d/snmpreceiverd status
A31003-H8050-J100-09-7631, 09/2011
417
Verifying the Shutdown Agents Configuration
The expected response is running

11. After installation of the standalone survival authority, verify the survival
authority configuration (refer to Section 6.7, Verifying the Shutdown
Agents Configuration, on page 418).
6.7 Verifying the Shutdown Agents Configuration

The SNMPReciever should only be installed in the case of a Standalone Survival
Authority as described in Section 6.5.2, Installing the Standalone Survival
Authority, on page 412.
Each node tests the Survival Authority function every 10 minutes and will report
a Survival Authority test failure with a major communication alarm. RapidStat also
performs sa_ipmi and sa_down shutdown agent tests in addition to shutdown
agent configuration checks. It is recommended that RapidStat be configured as a
cronjob to schedule daily RapidStat health checks. Refer to the OpenScape Voice
V5 Service Documentation, section "How to Configure RapidStat as a Cronjob"
for details.
Use the following sections to verify the survival authority configuration and to
monitor survival authority activity:
418
Section 6.7.1, Monitoring the Shutdown Agents From the Nodes, on page
419
Section 6.7.2, Examples of sa_down.log and sa_ipmi.log Output, on page

420
Section 6.7.3, Activity Log for Survival Authority Action, on page 422
A31003-H8050-J100-09-7631, 09/2011
6.7.1 Monitoring the Shutdown Agents From the

Nodes
Attention: The sa_ipmi test is NOT applicable to a Virtual OSCV environment.
The sa_down test is applicable to Virtual and non-Virtual OSCV environments.
As root user, perform a manual survival authority test with the following
command(s):
The binaries to test the sa_ipmi and sa_down are located in path
/opt/SMAW/SMAWhaext/bin.
For a sa_ipmi test:
sa_ipmi -d -s <the partner node hostname>
For a sa_down test:
sa_down -d -s <the partner node hostname>
The -s option invokes a test of the survival authority function.
The -d option switches logging to the debug mode (which writes test results to
the sa_ipmi.log or sa_down.log files). The sa_ipmi.log and sa_down.log files are
located at /var/opt/SMAWhaext/log. The log files should be reviewed for
information regarding the cause of a survival authority test failure.
The <the partner node hostname> is the hostname of the cluster partner
node.
Examples of the commands are as follows:
Attention: The sa_ipmi test is NOT applicable to a Virtual OSCV environment.
The sa_down test is applicable to Virtual and non-Virtual OSCV environments.
root@bocast4a:[/opt/SMAW/SMAWhaext/bin] #424
# ./sa_ipmi -s -d bocast4b
root@bocast4a:[/opt/SMAW/SMAWhaext/bin] #426
# ./sa_down -s -d bocast4b
A31003-H8050-J100-09-7631, 09/2011
419
6.7.2 Examples of sa_down.log and sa_ipmi.log

Output
An example of the sa_down.log output for a successful sa_down shutdown agent
test follows. The actual sa_down test command was executed in a different
session window (reference command example listed in Section 6.7.1, Monitoring
the Shutdown Agents From the Nodes, on page 419). Direct questions regarding
the content of a sa_down.log file to your next level of support. The NOTICE
sa_down: do_test: SaQuery returned success. is the expected result of a
successful sa_down test.
Note: The tail job indicated will initially print the last ten lines in the sa_down.log
file. To gain separation from these ten lines and your test output, press the Enter
key 4 or 5 times.
Note: The sa_down test is applicable to Virtual and non-Virtual OSCV

environments. The sa_ipmi test is NOT applicable to a Virtual OSCV
environment.
This log was collected from the node of an OpenScape Voice cluster at software
level V5.00.01.ALL.11_PS0017.E09.
420
A31003-H8050-J100-09-7631, 09/2011
root@bocastress1a:[/var/opt/SMAWhaext/log] #98
# tail -f sa_down.log
2011-04-30 12:03:25.932
try $ SNI
7315 @(#)$Header: SA_down.c /main/6 2010/08/10 12:49:17
2011-04-30 12:03:25.932
7315 ReadConfigFile called for host bocast4b
2011-04-30 12:03:25.932
7315 Line: bocast4a
2011-04-30 12:03:25.932
7315 Configuration entry found for host: >bocast4b<
2011-04-30 12:03:25.932
7315 SaQuery -s bocast4b
2011-04-30 12:03:26.118
7315 srx on bocast4a using /dev/pts/2 ...
2011-04-30 12:03:27.503
7315 NOTICE SA_down: do_test: SaQuery returned success
2011-04-30 12:03:27.503
7315 result of status test is: 0
An example of the sa_ipmi.log output for a successful sa_ipmi shutdown agent

test follows. The actual sa_ipmi test command was executed in a different
session window (reference command example listed in Section 6.7.1, Monitoring
the Shutdown Agents From the Nodes, on page 419). Direct questions regarding
the content of a sa_ipmi.log file to your next level of support.
An empty output is expected as a result for all of the queries and/or tests of a
successful sa_ipmi test run from the command line.
Note: The tail job indicated will initially print the last ten lines in the sa_down.log
key 4 or 5 times.
Note: The sa_down test is applicable to Virtual and non-Virtual OSCV

environments. The sa_ipmi test is NOT applicable to a Virtual OSCV
environment.
A31003-H8050-J100-09-7631, 09/2011
421
This log was collected from the node of an OpenScape Voice cluster at software
level V5.00.01.ALL.11_PS0017.E09.
root@bocastress1a:[/var/opt/SMAWhaext/log] #
# tail -f sa_ipmi.log
2011-04-30 11:54:47.68
$
6380 $Header: SA_ipmi.c /main/9 2010/08/10 12:43:07 try
2011-04-30 11:54:47.68
6380 global Parameter setting: TestLocalStatus
2011-04-30 11:54:47.68
6380 global Parameter setting for testLocal: 1
2011-04-30 11:54:47.68
6380 global Parameter setting: retryPonCnt 2
2011-04-30 11:54:47.69
6380 Line: bocast4a cycle
2011-04-30 11:54:47.69
6380 found entry for host >bocast4b< cycle >1<
2011-04-30 11:54:47.69
6380 Read from Config File, user: NEWUSER
2011-04-30 11:54:47.69
6380 Read from Config File, printDevIp:
10.235.54.21:NEWUSER:********
2011-04-30 11:54:47.69
6380 Read from Config File, DevIp: 10.235.54.21
2011-04-30 11:54:47.69
6380 type ipmitool > /dev/null 2>&1
2011-04-30 11:54:47.72
6380 has_ipmitool is: 1
2011-04-30 11:54:47.73
6380 ipmitool -P xyz -V 2>&1
2011-04-30 11:54:47.79
6380 ipmitool version 1.8.10
2011-04-30 11:54:47.79
6380 has_paramP is: 1
2011-04-30 11:54:47.79
6380 status query (has_ipmitool 1) ...
2011-04-30 11:54:47.79
6380 ipmitool -v -I lan -H 10.235.54.21 -U NEWUSER -P
##### chassis power status
2011-04-30 11:54:49.162
6380 Chassis Power is on
2011-04-30 11:54:49.162
6380 query result is 0
6.7.3 Activity Log for Survival Authority Action

In the case of a complete interconnection failure between OpenScape Voice
nodes, and OSV nodes and the partner maintenance controller (IMM, iRMC),
each node will send a trap "hiQPartnerNodeLeftClusterTrap" to the Survival
Authority. The Survival Authority reponds with an SNMP SET command to
"takeover" or to "shutdown". The Survival Authority returns "takeover" to the first
node to deliver the trap and the "shutdown" to the second node to deliver the trap.
An example follows:
422
A31003-H8050-J100-09-7631, 09/2011
Attention: In OpenScape Voice V4 (and later releases) the Standalone Service

option is available for duplex configurations. If it is enabled, the node that does
not get the permission to take over from the Survival Authority stays active (in
Standalone Secondary mode). For more information regarding the Standalone
Service feature, refer to Section 2.5, Creating a Node.cfg File, step 4 of this
document or to the OpenScape Voice V5, Feature Description documentation,
section Survival Authority. Any questions regarding the Standalone Service
should be addressed to your next level of support.
You can monitor the Survival Authority activities via the CMP webpage, by
navigating to Operation & Maintenance -> Configuration & Monitoring -> Audit
Log tab and then filtering for Survival Authority in the Advanced options. You
should see two entries like the following:
A31003-H8050-J100-09-7631, 09/2011
423
424
TakeOver + IP address of the surviving node under Parameters for the node
which survives the failure (or becomes Standalone Primary if
StandAloneService is enabled)
Shutdown + IP address of the killed node under Parameters for the node
which gets shutdown (or becomes Standalone Secondary if
StandAloneService is enabled)
A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
Overview of Upgrades and Migrations to OpenScape Voice V5
7 Overview of Upgrades and Migrations to OpenScape

Voice V5
Attention:
For V4R1 systems that have provisioned one or more of the following supported
languages to the system/subscriber:
"Croatian", "Czech", "Danish", "Egyptian", "Esperanto", "Estonian", "Faroese",
"Finnish", "Gaelic", "Ganda", "Georgian", "Greek", "Hebrew", "Hindi",
"Hungarian", "Icelandic", "Indonesian", "Iranian", "Javanese", "Kashmiri",
"Korean", "Kurdish", "Latin", "Latvian", "Lithuanian", "Macedonian", "Malay",
"Maltese", "Moldavian", "Nepali", "Norwegian", "Panjabi", "Persian", "Polish",
"Portuguese", "Romanian", "Sanskrit", "Sardinian", "Scots", "Serbian", "Slavic",
"Slovak", "Slovenian", "Somali", "Sudanese", "Swahili", "Tahitian", "Tamil",
"Telugu", "Thai", "Tibetan", "Turkish", "Turkmen", "Urdu", "Uzbek",
"Vietnamese", "Welsh", "Yiddish", "Zulu".
After the installation of PS0029.E04.E0386 or V4.00.01.ALL.40_PS0031
(P2105), the language name will change. The user has to manually update the
language of the system/subscriber to the original/desired language.
System:
From Assistant: OpenScape Voice Tab: Administration ->Media Servers >Languages -> Add.
Subscriber:
From Assistant: OpenScape Voice Tab: Business Group -> Members ->
Subscriber(s).
Attention: Before beginning an upgrade on a redundant system, ensure that the

survival authority is properly configured and functioning correctly. Refer to
Appendix H, Verifying V3.1R3/V4R1 Survival Authority and IPMI Shutdown
Agents.
Attention: There is no need to re-provision/re-assign the MediaServer

announcement/treatments or Prefix Access Code (PAC) data after completing the
Upgrade/Migration. The upgrade process manages the required database and
configuration changes.
A31003-H8050-J100-09-7631, 09/2011
425
upg_procedure.fm
OpenScape Voice Server system migrations with a network schema change are
supported (refer to Chapter 9, Migrations to OpenScape Voice V5). Another
strategy to implement a network change migration scenario is to upgrade (or
migrate) the OSC Voice server to the target release first and then update to the
new network schema with the Installation Framework Update (EZIP). Refer to
Appendix F, Updating the Node.cfg File (Also Known as EZIP). Questions
OSV V5 supports source based routing, where OSV sends IP packets to an IP
gateway/router based on which subnet the source IP of the packet belongs to.
For this default, gateways should be specified for the OSV IP subnets admin,
signaling and billing. If, for example, a billing gateway specified, the OSV sends
billing files via this gateway and there is no need for the creation of static routes
to each billing server.
Another advantage of source base routing is that responses to admin requests
from a remote IP network to the OSV admin IP address are sent back via the
default admin gateway. Without this admin gateway, the response would be sent
via the default router, which is usually on the signaling network.
It is therefore highly recommended to specify default gateways via NCPE when
preparing the node.cfg for the new release.
Notes:
426
There is no source based routing for the OSV x-channel subnet. But an xchannel default gateway is still required if the x-channel subnets of the two
nodes are different. It is used by the OSV to automatically create a static
route to the partner node x-channel IP address.
Even with source based routing, static routes are still required for OSV trap
destinations, NTP and DNS (the reason is that OSV software does not control
the source IP of packets sent to these devices).
OSV automatically replicates each static route to the source based routing
table of the subnet that the router belongs to. For example, if the admin
network is 1.2.3.0 to 1.2.3.255 and if a static route to IP 4.4.4.4 is specified
via router 1.2.3.1, there will be two static routes, one in the admin source
based routing table and one in the global routing table. So even if the OSV
sends out a packet to 4.4.4.4 with source IP 2.2.2.2, it will still go via 1.2.3.1.
If source based routes are already established on the source release, these
default gateways will be reflected in the node.cfg built from the system data
collection step. The system data collection step is included in each upgrade
procedure (refer to Section 8.3.1, Collect System Data on Node 1, on page
456, for details on this procedure). This data collection node.cfg will be the
A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
basis for the target release installation node.cfg. The source based routes will
be included in the target release node.cfg. It is a good practice to review the
target release node.cfg before installation of the target release.
Attention: The implementation or updating of source based routes during an
upgrade will require the use of a Migration strategy (and therefore a system
outage). These Migration strategies are detailed in Chapter 9, Migrations to
OpenScape Voice V5. For duplex systems, if an OpenScape Voice system
outage cannot be tolerated during the upgrade, then the Split Mode Upgrade
(SMU) method will need to be performed. The SMU method upgrade is detailed
in Section 8.6, Upgrading a Standard Duplex System (SMU Method). As a
general rule, no changes to the OSCV target release node.cfg are allowed during
the three upgrade procedures detailed in Chapter 8, Upgrades to OpenScape
Voice V5. After a Chapter 8 upgrade procedure is completed, the EZIP feature
can be employed to establish source based routing (by specifying default
gateway addresses). For more information regarding EZIP, refer to Appendix F,
Updating the Node.cfg File (Also Known as EZIP). Any questions should be
With the removal of Secondary IP addresses, OpenScape Voice Servers installed

as network separated systems can not be upgraded to V4R1 (or higher releases)
until it is verified that no component in the OSV system network is using IP
addresses that are being removed. All OpenScape customer installations with
network separated systems, configured in load sharing manner, must be modified
to remove obsolete IP addresses used for call processing. Refer to Appendix I,
Removal of Obsolete IP Addresses when Upgrading to V4R1 (or higher
releases) for further instructions. Any questions should be addressed to your
next level of support.
Should the Active partition become unstable during the upgrade, one option is to
recover by booting off of the Fallback partition that contains the backup (contact
your next level of support for assistance).
To determine the contents of the active and passive partitions, execute as user
root:
# unisphere/srx3000/srx/bin/sync8k -v
Read the following sections carefully before beginning any upgrade or migration:
Section 7.1, Solution Upgrade Considerations, on page 428
A31003-H8050-J100-09-7631, 09/2011
427
upg_procedure.fm
Solution Upgrade Considerations
Section 7.2, Hardware Considerations, on page 428.
Section 7.3, Upgrade and Migration Scenarios, on page 434.
7.1 Solution Upgrade Considerations

The various hardware/software components associated with the OpenScape
Voice system might require upgrades/updates to maintain compatibility with the
upgraded OpenScape Voice system. Refer to the Solutions Upgrade Guide on
E-Doku for information and instructions.
7.2 Hardware Considerations

7.2.1 Hardware Platform Migrations
Note: Upgrades to V5R0 integrated duplex systems are not supported.
Customers with an Integrated Duplex system must migrate to a Standard Duplex
on HW supported in V5 (after reading Chapter 7 refer to Chapter 9, Migrations
to OpenScape Voice V5 ).
OpenScape Voice V5 is not supported on IBM xSeries 346 servers.

The IBM x346 server for OpenScape Voice systems must migrate to a currently
supported platform as defined by the Product Matrix document in order to
upgrade to OpenScape Voice V5R0.
The new server (or servers) should be installed into the rack and prepared (for
example: modify the SCSI RAID configuration, modify the BIOS settings, update
firmware) for the migration before the maintenance window in which the migration
shall be performed.
Attention: An upgrade that includes a migration to a different hardware platform,
for whatever reason, is performed using the migration toolkit and appropriate
checklist in Chapter 9, Migrations to OpenScape Voice V5.
428
A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
Hardware Considerations
7.2.2 IBM x3650T Memory Expansion

OpenScape Voice V5 requires 8 GB of memory. Therefore, any upgrade or
migration involving an x3650T-based system requires that the x3650T 4 GB of
memory be expanded to 8 GB. This memory expansion should be performed
before the maintenance window in which the upgrade or migration is to be
performed.
Refer to the OpenScape Voice V5 release note for the Installing Additional RAM
Memory on Installed x3650T Systems, MOP P30310-X0692-R222-xx-7620.
7.2.3 Converting to a Multi-Partition Disk

Note: The V5 Restore CD should not be used to convert a V3.1R3 system to a
multi-partition disk. The V5 Restore CD uses a different scheme for partitioning
and therefore the V3.1R3 Restore CD should be used.
Some early V3.1R3 systems use a single-partition disk format; these systems
must first be converted to a multi-partition disk format before attempting the
upgrade using the Section 8.6, Upgrading a Standard Duplex System (SMU
Method) procedure. Refer to MOP P30310-Q2582-Q031-xx-7620, Conversion
to a Multi Partition Platform.
Note: This MOP is not required for the Section 8.5, Upgrading an Integrated
Simplex System (Toolkit Method), and Section 8.7, Upgrading a Standard
Duplex System (Toolkit Method) upgrade procedures or any of the Chapter 9
migration procedures.
7.2.4 IBM x3650T Simplex to Standard Duplex

Migration
Attention: This migration is performed using the migration toolkit and appropriate
Simplex to duplex migrations require the following for x3650T-based systems:
A Quad Ethernet card must be installed into the single-node x3650T. Do not
install the Quad Ethernet card until instructed to do so by the migration
documentation.
A31003-H8050-J100-09-7631, 09/2011
429
upg_procedure.fm
When instructed by the migration documentation to install the Quad Ethernet

card, refer to Appendix C, IBM x3650T Quad Ethernet Card Installation for
instructions.
A second x3650T must be installed.

Install the second x3650T into the rack, modify the SCSI RAID configuration
(Section 3.3.7 on page 62), modify the BIOS settings (Section 3.3.8 on page
69), and update firmware (refer to Method of Procedure (MOP), P30310Q2692-Q130-01-7620, IBM X3650T base firmware for HiPath V4) before the
maintenance window in which the migration shall be performed. Do not
connect any Ethernet cables until instructed to do so by the migration
documentation.
When instructed by the migration documentation to connect the Ethernet
cables, refer to Section 3.3.6.2, Connecting the Cables for a Redundant IBM
x3650T, on page 57 for instructions.
7.2.5 FSC RX330 Simplex to Standard Duplex

Migration
Simplex to duplex migrations require the following for FSC RX330-based

systems:
Two Dual Port Ethernet cards must be installed into the single-node FSC
RX330. Do not install the Ethernet cards until instructed to do so by the
migration documentation.
When instructed by the migration documentation to install the Ethernet cards,
refer to the FSC RX330 service documentation for instructions.
A second FSC RX330 must be installed.

Install the second FSC RX330 into the rack, modify the SCSI RAID
configuration (Section 3.4.7 on page 92) and modify the BIOS settings
(Section 3.4.8 on page 99) before the maintenance window in which the
migration shall be performed. Do not connect any Ethernet cables until
instructed to do so by the migration documentation.
cables, refer to Section 3.4.6.2, Connecting the Cables for a Redundant FSC
RX330, on page 86 for instructions.
430
A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
7.2.6 IBM x3550 M2/M3 Simplex to Standard Duplex

Migration
Simplex to duplex migrations require the following for IBM x3550 M2/M3-based
systems:
One Quad port Gigabit Ethernet PCI card must be installed into the singlenode IBM x3550 M2/M3 server. Do not install the Ethernet card until
When instructed by the migration documentation to install the Ethernet card,
refer to the appropriate IBM x3550 M2 or M3 service documentation for
instructions.
A second IBM x3550 M2 or M3 server must be installed matching the first

server type.
Install the second IBM x3550 M2/M3 server into the rack, modify the SCSI
RAID configuration (Section 3.6.7 on page 151) and modify the BIOS settings
cables, refer to Section 3.6.6.2, Connecting the Cables for a Redundant IBM
x3550 M2/M3, on page 146 for instructions.
7.2.7 FTS RX200 Simplex to Standard Duplex

Migration
Simplex to duplex migrations require the following for FTS RX200-based

systems:
One Quad port Gigabit Ethernet PCI card must be installed into the singlenode FSC RX200. Do not install the Ethernet cards until instructed to do so
by the migration documentation.
When instructed by the migration documentation to install the Ethernet card,
refer to the FTS RX200 service documentation for instructions.
A31003-H8050-J100-09-7631, 09/2011
431
upg_procedure.fm
A second FTS RX200 must be installed.

Install the second FTS RX200 into the rack, modify the SCSI RAID
configuration (Section 3.7.7 on page 181) and modify the BIOS settings
cables, refer to Section 3.7.6.2, Connecting the Cables for a Redundant FTS
RX200, on page 176 for instructions.
7.2.8 Additional Servers for Migrations to Standard

Duplex
Note: Integrated simplex or duplex migrations to standard duplex are performed
using the migration toolkit and appropriate checklist in Chapter 9, Migrations to
OpenScape Voice V5.
Migrations to standard duplex require that an external applications server is

installed with the OpenScape Applications DVD version level and the SLES
operating system level that is compatible with the OpenScape Voice software
version and patch set level.
For Multiple Communications Server Admin deployments refer to Chapter 5,
Installing the OpenScape Applications of this document.
For Standard Duplex Small or Standard Duplex Large deployments refer to the
appropriate section(s) of the OpenScape UC Application V3, Installation and
Upgrade, Installation Guide.
432
A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
After you perform the checklist steps to migrate to standard duplex you then
install/update this external applications server to the OpenScape Applications
DVD V5 level and the recommended SLES 10 OS and SP distribution level as
necessary.
Note: The Deployment Service (DLS) component might not be supported on the
external OpenScape Applications server due to sizing limitations. A separate
server running Microsoft Windows might be required for the DLS component.
Please review the DLS release notes for sizing limitations when DLS is installed
as a component of the external applications server.
Attention: For Migrating DLS from Linux to Windows refer to DLS Release
Notes.
A31003-H8050-J100-09-7631, 09/2011
433
upg_procedure.fm
Upgrade and Migration Scenarios
7.3 Upgrade and Migration Scenarios

Attention: Ensure that SIP-Q connections are configured to use the TCP or TLS
transport before you begin the upgrade. For a SIP-Q GW (for example, HG3540):
ensure the transport type = TCP or TLS (no UDP). Please refer to "HiPath 8000
Solution Configuration Guide" (reference INF-08-000789 on G-DMS for links to
the solution configuration guides) for details. Ensure that GW calls complete
successfully (inbound and/or outbound) before you begin the upgrade if you
update the configuration.
7.3.1 Upgrade Scenarios

Refer to Chapter 8, Upgrades to OpenScape Voice V5 for these upgrade
scenarios (in each scenario the target systems hardware server platform model,
product type, subnet configuration, and deployment type [co-located nodes or
geographically separated nodes] is kept the same as the source system).
In V5 Remote Software Upgrades are introduced (Section 8.8, Remote SW
Upgrade). This capability saves service cost by providing a procedure to perform
major release upgrades without the cost of having a Service Technician on-site.
Note: There will be an outage of approximately 1 hour. If the outage is not
acceptable on a Standard Duplex system, Split Mode Upgrade can be performed
at the customer site.
Remote Software Upgrades are applicable to:
OSV Low Cost (requires new support for RSA card)
OSV Integrated Simplex
OSV Standard Duplex (the OSV nodes only). SMU should be employed if an
outage is not acceptable.
OSV Virtual deployment (Standard Duplex)
Attention: Upgrades to V5R0 integrated duplex systems are not supported.

Integrated Duplex systems must migrate to a Standard Duplex configuration on
HW supported in V5 (refer to Chapter 9, Migrations to OpenScape Voice V5).
Upgrades to integrated simplex systems are now performed using the migration
toolkit and Section 8.5, Upgrading an Integrated Simplex System (Toolkit
Method) checklist.
434
A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
The SMU (Section 8.6 on page 472) is still supported for standard duplex systems
if the customer cannot accept system downtime.
V3.1R3/V4R1 simplex to V5 simplex
V3.1R3/V4R1 standard duplex to V5 standard duplex
7.3.2 Hardware Migrations

Attention: These migrations are performed using the migration toolkit and
appropriate checklist in Chapter 9, Migrations to OpenScape Voice V5.
Refer to Chapter 9, Migrations to OpenScape Voice V5 for the following

upgrades that include a hardware platform migration:
Note: Product type and node deployment changes are allowed as part of the
hardware platform migration.
V4R1 OpenScape Voice Entry (Low Cost IBM x3250 simplex) to V5 duplex
V3.1R3/V4R1 simplex to V5 simplex
V3.1R3/V4R1 simplex to V5 standard duplex (co-located nodes or

geographically separated nodes)
V3.1R3/V4R1 integrated duplex (co-located nodes or geographically

separated nodes) to V5 standard duplex (same node deployment as source)
V3.1R3/V4R1 integrated duplex (co-located nodes) to V5 standard duplex

(geographically separated nodes)
V3.1R3/V4R1 standard duplex (co-located nodes or geographically

V3.1R3/V4R1 standard duplex (co-located nodes) to V5 standard duplex

7.3.3 Product/Node Deployment Migrations

Note: These migrations are performed using the migration toolkit and appropriate
A31003-H8050-J100-09-7631, 09/2011
435
upg_procedure.fm
Refer to Chapter 9, Migrations to OpenScape Voice V5 for the following product

type or node deployment migrations:
Note: In these product type and node deployment migrations the existing
OpenScape Voice server hardware is reused.
436

geographically separated nodes)



A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
Completing the Upgrade to V5
7.4 Completing the Upgrade to V5

Attention:
For V4R1 systems that have provisioned one or more of the following supported
languages to the system/subscriber:
"Croatian", "Czech", "Danish", "Egyptian", "Esperanto", "Estonian", "Faroese",
"Finnish", "Gaelic", "Ganda", "Georgian", "Greek", "Hebrew", "Hindi",
"Hungarian", "Icelandic", "Indonesian", "Iranian", "Javanese", "Kashmiri",
"Korean", "Kurdish", "Latin", "Latvian", "Lithuanian", "Macedonian", "Malay",
"Maltese", "Moldavian", "Nepali", "Norwegian", "Panjabi", "Persian", "Polish",
"Portuguese", "Romanian", "Sanskrit", "Sardinian", "Scots", "Serbian", "Slavic",
"Slovak", "Slovenian", "Somali", "Sudanese", "Swahili", "Tahitian", "Tamil",
"Telugu", "Thai", "Tibetan", "Turkish", "Turkmen", "Urdu", "Uzbek",
"Vietnamese", "Welsh", "Yiddish", "Zulu".
After the installation of PS0029.E04.E0386 or V4.00.01.ALL.40_PS0031
(P2105), the language name will change. The user has to manually update the
language of the system/subscriber to the original/desired language.
System:
From Assistant: OpenScape Voice Tab: Administration ->Media Servers >Languages -> Add.
Subscriber:
From Assistant: OpenScape Voice Tab: Business Group -> Members ->
Subscriber(s).
Note: When migrating from a simplex to a standard duplex configuration or

performing an upgrade that includes a node deployment migration, please
consider the following;
Basic TLS certificates are included in the image install. If custom certificates
have been employed the migration from a simplex to a co-located duplex
system should not require the generation of additional custom certificates for
node 2 (because the network schema does not change). Migration to a geoseparated environment will require the generation of additional custom
certificates because node 2 will have a different network schema than node
1. Node deployment migrations will require the generation of additional
custom certificates for node 2 also.
The external DNS will have to be administered with the node 2 IP address
information.
A31003-H8050-J100-09-7631, 09/2011
437
upg_procedure.fm
Complete the upgrade to V5 as follows:

1. If the Solid db password was changed to dba during the upgrade/migration be
sure to change the solid db password back to the original value.
2. If migration was performed with server(s) hardware change out, the IMM/
iRMC user id and password are created with the default values (USERID/
PASSW0RD where the "0" in PASSW0RD is zero, not the letter O) on the new
server(s). If the old server(s) had non-default values for the user id and
password, then update the IMM/IFMC user id and password on the new
server(s) as described in Section 4.4.2, Changing the User ID and Password
for the IMM/iRMC Account, on page 284.
3. If the source release hosts file was copied and saved due to the Section 8.4.7,
Verify the Hosts File Configuration, on page 464 procedure, rebuild the
user-created entry list in the target release hosts file as follows:
Note: For duplex systems, both nodes need to be updated. The duplex
system hosts files should be updated from the saved hosts file of that node.
The stored hosts files should have been saved with names indicative of the
node the hosts file was saved from (for example: hosts_n1 and hosts_n2).
a) Open and copy the user-created entry list from the saved source release
hosts file and paste the list below the new banner in the target release
hosts file (new user-created entries can be added to the bottom of the
list). For example, the nmcsnmptrap and host_pc are user-created entries
copied and pasted into the target release hosts file:
10.235.54.10
rtp_com0_eth6
10.235.54.30
rtp_com1_eth6
########################################
# Please add new hosts under this line #
########################################
10.235.200.230
nmcsnmptrap
10.235.200.29
host_pc
b) Verify that all the user hosts entries were carried properly.
4. Open the saved system_configuration_report.rpt (from Section 8.3.1 step 2,
page 456). Search for the string ##BEGIN_CRONTAB_root. Beneath this
string will be the crontab data for the root user. For each entry determine
whether the source release cronjob should be added to the target release
crontab. Use the crontab command to list the crontab. It is recommended
only users familiar with the Linux OS edit the crontab.
To review the crontab as the root user;
sysad@<hostname>:[/home/sysad] #
$ su root
root@<hostname>:[~] #
# crontab -l
438
A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
To edit the crontab (as root user!);

root@<hostname>:[~] #
# crontab e
Attention: The file cfg_<node_name>_<release>_<date-time>.rpt can also
be employed for this purpose. See Section 8.3.1 section 7.3.1, step 2, page
456 for details. These files should be available in the source release partition
of the Voice server also. Questions can be addressed to your next level of
support.
5. Perform the same procedure detailed in step 4 for the user srx. Search the
system_configuration_report.rpt for the string ##BEGIN_CRONTAB_srx.
Beneath this string will be the crontab data for the srx user. For each entry
determine whether the source release cronjob should be added to the target
release crontab. The Attention statement for step 2 (above) applies here also.
Use the crontab command to list the crontab. It is recommended only users
familiar with Linux OS edit the crontab.
To review the crontab as the srx user;
sysad@<hostname>:[/home/sysad] #
$ su - srx
Password:
srx on bocastress1a using /dev/pts/1 ...
srx@<hostname>:[/unisphere/srx3000/srx] #
$ crontab l
To edit the crontab (as srx user!);
srx@<hostname>:[/unisphere/srx3000/srx] #
$ crontab e
6. Carefully review the OpenScape Voice V5 System release note and
download any materials the release note indicates that you will need to install
any required workarounds, hot fixes, or updates to the OpenScape Voice
system.
7. Carefully review the OpenScape Applications V5 release note and
download any materials the release note indicates that you will need to install
any required workarounds, hot fixes, or updates to the OpenScape
Applications.
8. For an integrated system, install any additional Media Server Language(s).
Refer to Section 5.2.4.5, Add Languages, on page 345.
9. There should be no need to re-provision/re-assign the MediaServer
announcements, treatments or Prefix Access Code (PAC) data after
completing the Upgrade/Migration. If problems with the media server are
observed or suspected;
A31003-H8050-J100-09-7631, 09/2011
439
upg_procedure.fm
For an internal or external OpenScape Media Server If there are any

problems with the media server announcements or treatments, refer to
Appendix J, Media Server Announcements, Treatments and Prefix
Access Code Installation Guide.
For a RadiSys Convedia media server:
MOP 30310-Q2623-Q150-XX-7620
For media server announcements, treatments or PAC information

refer to Appendix J, Media Server Announcements, Treatments and
The IP Unity media server is no longer supported in V5.
Note: For specific information regarding the Media Server, e.g. Packet Filter
Rule requirements, refer to the Media Server Component Release Note
(found in the OpenScape UC Applications release Notes).
More details for PACs can be found in the OpenScape Voice V5,
Configuration Manual, System Configuration and Administration,
Administrator Documentation.
Questions should be addressed to your next level of support.
10. Refer to Section 7.5, Post Upgrade Actions, on page 442 and perform the
appropriate procedures.
11. After the completion of migration login to CMP web page, navigate to the
following menu: OpenScape Voice --> General.
Select your switch and click on Refresh Switch Data button. In case some
information is incorrect, you may use the Edit option to correct it.
12. After the completion of migration, login to CMP web page, navigate to the
following menu: OpenScape Voice --> General --> OpenScape Voice
Assistant Deployment Servers, delete the entry of the DLS and re-add it.
Then you can access the DLS API.
13. After the completion of migration, login to CMP web page, navigate to the
following menu: Operation & Maintenance --> Recovery --> General.
Delete the old archives except from the default and re-add them.
14. For CLM access:
If the file /opt/licenses/clm/ApacheTomcat/ClmSettings.xml exists and is

not emtpy
Open the file with an editor and look for the entries ClmNetworkAccess
and AllowedClients.
By default there is no remote access configured. You will see:
440
A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
<ClmNetworkAccess>false</ClmNetworkAccess>
<AllowedClients/>
Please change the entry ClmNetworkAccess from false to true.
At AllowedClients insert the IP addresses of all clients which should have
access to the License Management. Several IP addresses have to be
separated with commas. An example follows;
<AllowedClients/>10.235.200.29,10.235.200.49</AllowedClients>
If the file /opt/licenses/clm/ApacheTomcat/ClmSettings.xml does not exist

or is empty:
Use the /opt/licenses/clm/remoteAccess.sh script to set up a list of
allowed remote clients after CLM installation. Execute the following
commands to create a new ClmSettings.xml file and update the
database:
# sh remoteAccess.sh <IP address 1>,<IP address 2>,<IP address n>
Here, <IP address 1>,<IP address 2>,<IP address >,<IPaddress n> are
the IP addresses of all clients which should have access to the License
Management.
Example:
15. After V4R1, branches and their members can be separately displayed in OSV
Assistant. If you are upgrading from V3.1R3, you may organize your
branches in OSV Assistant based on Associated Endpoint.
A31003-H8050-J100-09-7631, 09/2011
441
upg_procedure.fm
Post Upgrade Actions
7.5 Post Upgrade Actions

7.5.1 Create CLI Users
This step is necessary if customer created CLI accounts were not carried forward
following a successful upgrade. If no customer created CLI accounts are missing
refer to Section 7.5.3, Take File System and Database Backups, on page 443.
Create users for each missing CLI account identified during the data collection
phase.
Login to Node 1 as the user srx and start the RTP CLI:
> startCli
Select the following menu options:

4 - Security Management
1 - Users
1 - Create User
Create each user with the role and password expiration criteria as identified in the
data collection phase.
7.5.2 Create Linux Accounts for CLI Users

This step is necessary if customer created Linux accounts were not carried
forward following a successful upgrade. If no customer created Linux accounts
are missing refer to Section 7.5.3, Take File System and Database Backups, on
page 443.
In order to access the CLI using a remote login, each CLI user must have its own
Linux account. The following steps can be used to create Linux accounts for each
CLI user:
All of the following commands must be executed as user root on both nodes:
useradd -c "<Comment>" -g rtpgrp -m -s /bin/ksh <user-id>
Note: If the following two messages are output they can be ignored;
useradd: Unknown group `video'.
useradd: Unknown group `dialout'.
442
passwd -x 99999 -w 0 -n 1 <user-id>
passwd <user-id>
A31003-H8050-J100-09-7631, 09/2011
upg_procedure.fm
... <set initial password> ...
cd /home/<user-id>
cp /unisphere/srx3000/srx/.profile .profile
cp /unisphere/srx3000/srx/.kshrc .kshrc
Ensure the .profile and .kshrc files have <userid>:rtpgrp ownership. If not
update as follows;
chown <user-id>:rtpgrp .profile
chown <user-id>:rtpgrp .kshrc
By default, all passwords will expire in 60 days. To exempt the user-ids for CLI
from this requirement, add the new user-id to the file /etc/secure/
pamSpecialUserAuth.
7.5.3 Take File System and Database Backups

As described in the OpenScape UC Application V3 Configuration and
Administration , part number A31003-S5030-M104-*-76A9, in the Backing up and
Restoring the System section, perform the following:
Create a database backup
Create a file system backup of each node
7.5.4 Modifying Node Names

If the upgraded nodes (or node) have names that do not meet node naming
standards (see step 5a on page 38 for details), then the node names must be
modified to meet the naming standards. Use the IFgui tool in Update mode to
change the node names (or name).
Refer to the following:
The section titled, Important Information for Easy IP Address Changing in

the current release note for OpenScape Voice for information regarding the
use of the IFgui tool.
Appendix F, Updating the Node.cfg File (Also Known as EZIP) for an

overview and procedure for updating the node.cfg file.
If you have questions regarding the use of the IFgui tool, contact your next level
of support.
A31003-H8050-J100-09-7631, 09/2011
443
upg_procedure.fm
7.5.5 Executive-Assistant
If the source release applications employ the Executive-Assistant feature; in
order to carry over Executive-Assistant data to target release the following MOP
must be implemented:
Method Of Procedure (MOP) P30310-Q2725-Q150-**-7620 - Title: Linux EA
Group database tables migration from V3.1 to V5.0 (carryover of FRN3158).
7.5.6 Executive - Assistant with Cockpit

If the source release Applications employed the Executive - Assistant Cockpit
feature, the source release '.eag' files should have been backed up as part of the
Pre-Maintenance Window Activities, Section 8.4.8, Executive Assistant with
Cockpit, on page 466.
The backed up Executive - Assistant Cockpit files should copied to the target
release Applications server:
Simplex and Low Cost OSC Voice Integrated Applications server;
/enterprise/HiPathCA/WebSpace/Portal/webapps/eacockpit-osc/WEB-INF/
groups
External Application Server(OFFBoard) Applications:
/opt/siemens/HiPathCA/WebSpace/Portal/webapps/eacockpit-osc/WEBINF/groups
444
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Upgrades to OpenScape Voice V5
Procedure Descriptions
8 Upgrades to OpenScape Voice V5

Attention: When servers (e.g., media server or DLS) in the same network as
one of the OSV's subnets need to communicate with another of the OSV's
subnets, then changes to the network firewall are required to allow this
communication. Any questions should be addressed to the next level of support.
Attention: Ensure that SIP-Q connections are configured to use the TCP or TLS
transport before you begin the upgrade. For a SIP-Q GW (for example, HG3540):
ensure the transport type = TCP or TLS (no UDP). Ensure that GW calls complete
successfully (inbound and/or outbound) before you begin the upgrade if you
update the configuration.
Should the Active partition become unstable during the upgrade, one option is to
recover by booting off of the Fallback partition that contains the backup (contact
your next level of support for assistance).
To determine the contents of the active and passive partitions, execute as user
root;
# unisphere/srx3000/srx/bin/sync8k -v
8.1 Procedure Descriptions

Attention: If you have not already done so, read Chapter 7, Overview of
Upgrades and Migrations to OpenScape Voice V5 before using the procedures
in this chapter.
The procedures in this chapter provide instructions on how to upgrade the

software from V3.1R3/V4R1 to V5. The procedures provide instructions to
upgrade standard duplex and simplex systems.
A31003-H8050-J100-09-7631, 09/2011
445
smu_linux_R1.fm
The procedures require preparatory steps that need to be executed before

performing the upgrade and detailed descriptions of the commands and outputs
that are associated with the upgrade procedure. System outputs shown
throughout the procedures are examples only and might deviate slightly from the
actual output.
There is an operational impact as a result of the upgrade. For more details, see
Section 8.1.5, Operational Impacts.
Review the actual upgrade procedure for tasks that may be performed prior to the
upgrade maintenance window.
The actual upgrades as described in Section 8.5, Upgrading an Integrated
Simplex System (Toolkit Method), on page 467, Section 8.6, Upgrading a
Standard Duplex System (SMU Method), on page 472, and Section 8.7,
Upgrading a Standard Duplex System (Toolkit Method), on page 490 are to be
performed during a maintenance window.
The SMU upgrade procedure include several fallback points. Fallback
instructions are provided in Section 8.11, Fallback Procedures.
8.1.1 Applicable Upgrade Scenarios

Note: After you complete the applicable procedure for your scenario, refer to
Section 7.4, Completing the Upgrade to V5, on page 437.
Attention: Upgrades to V5R0 integrated duplex systems are not supported.

Integrated Duplex systems must migrate to a Standard Duplex configuration on
HW supported in V5 (refer to Chapter 9, Migrations to OpenScape Voice V5).
Upgrades to integrated simplex systems are now performed using the migration
toolkit and Section 8.5, Upgrading an Integrated Simplex System (Toolkit
Method) checklist.
The SMU (Section 8.6 on page 472) is still supported for standard duplex systems
if the customer cannot accept system downtime.
The procedures in this chapter apply to the following upgrade scenarios:
446
Integrated simplex: V3.1R3/V4R1 single-node with internal V3.1R3/V4R1

Applications to V5 single-node with internal V5 OpenScape Applications
Standard duplex: V3.1R3/V4R1 redundant with external V3.1R3/V4R1

Applications server to V5 redundant with external V5 OpenScape
Applications server
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
8.1.2 Preparation Checklist
Ensure that all items are available before you start the procedure.
Read the release notes before you start the procedure.
Read the entire procedure applicable to your scenario before you start the
procedure.
Item
Number
Description
Available
OpenScape Voice V5 Image DVD set
1.
OpenScape Voice V5 Applications DVD (minimum DVD 3.00
2.
or higher)
3.
SLES 10 OS and SP distribution approved for external

Applications Server installations.
4.
NCPE CD/DVD that corresponds to OpenScape Voice V5
5.
Unless directed otherwise by Release Notes the V5R0 target

OpenScape voice server patch level must be V5R0 patch set
6E03 or greater.
6.
The latest V3.1R3/V4R1 patch sets on CD/DVD
7.
Latest OpenScape Voice System Restore CDs of the source

release
8.
OpenScape Voice V5 Release Notes
9.
Documentation: Refer to Section 8.1.3, Required Documents.
10.
For Toolkit Migrations and Upgrades the migration toolkit

software is required.
Table 31
Preparation Checklist
Ensure that the network configuration requirements for the system

configuration type (co-located nodes or geographically separated nodes) are
met before beginning the upgrade. Refer to Chapter 12 of the OpenScape
Voice, Design and Planning Manual, Volume 3, SIP Network Planning for
more information.
Specifically, ensure that each of the bonded Ethernet pairs are assigned to a
separate IP subnet (collision domain) within the reserved address range. The
upgrade will fail if this requirement is not met.
With the removal of secondary IP addresses, OpenScape Voice Servers

installed as network separated systems, can not be upgraded to V4R1 (or
higher releases) until it is verified that no component in the OSV system
network is using IP addresses that are being removed. See the Appendix I,
Removal of Obsolete IP Addresses when Upgrading to V4R1 (or higher
releases) in case of network separated systems.
A31003-H8050-J100-09-7631, 09/2011
447
smu_linux_R1.fm
8.1.3 Required Documents

In addition to this document, the following documents are required to perform the
upgrade.
The OpenScape UC Application V5, Installation and Upgrade, Installation

Guide
The OpenScape Voice V5, Configuration and Administration Using Common

Management Portal and Assistant Plug-ins, Administrator Documentation
The V3.1R3 OpenScape Voice, Maintenance Manual, Volume 2, Backup and

Recovery as appropriate for the source release
The V3.1R3 OpenScape Voice, Maintenance Manual, Volume 3, Software

Maintenance as appropriate for the source release
OpenScape Voice V5, Design and Planning Manual, Volume 3, SIP Network
Planning
The Solutions Upgrade Guide on E-Doku.
Release Notes for OpenScape Voice Server V5 Reference Image
Release Notes for OpenScape Voice V5 Applications DVD
Release Notes for applicable patch sets
Any applicable MOPs
8.1.4 Split Mode Upgrade Overview

Attention: During a Split Mode Upgrade (SMU), the OpenScape Voice servers
need to communicate via the Billing subnets of the nodes. Please be sure that
the Billing subnets are functional. Section 8.2.3, IP Network Requirements for
Geographically Separated Nodes, on page 453, details a procedure to establish
static routes between the nodes of an OpenScape Voice geo-separated system.
Note: This section applies to standard duplex systems only.
The Split Mode Upgrade method provides an upgrade procedure equivalent to

the cluster replacement procedure, but without the need for separate cluster
hardware.
This upgrade procedure allows upgrade without imposing interworking
requirements between old and new versions of third party software, allowing third
party upgrades which otherwise would have required a prolonged outage.
448
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Additionally the upgrade procedure does not require the old and new versions of
the software to interwork, which reduces development and test effort and
simplifies upgrade between multiple release lines at different patch levels.
The Split Mode Upgrade method is based on the fact that the cluster is made up
of two individual nodes (two separate servers running in active/active mode).
The Split Mode Upgrade procedure consists of three main phases:
Phase 1: The cluster is running V3.1R3/V4R1 and the RTP is at run level 4.
Preconditions (see Figure 11):
All processes are up.
There are no HW alarms.
All needed patch sets are installed.
Figure 11
Initial Cluster Configuration
Phase 2: Upgrade Node 1

The interconnects between the nodes are disabled and Node 1 is temporarily
isolated from the network. Node 1 is upgraded to the new release. See Figure 12.
A31003-H8050-J100-09-7631, 09/2011
449
smu_linux_R1.fm
Figure 12
Cluster Configuration After Split
Phase 3: Upgrade Node 2

The L2 redundant cluster connects between Node 1 and Node 2 are reestablished and Node 2 is upgraded to the new release. See Figure 13.
Figure 13
450
Cluster State After Restore of Node 2
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
8.1.5 Operational Impacts

8.1.5.1 Provisioning
#
Impact
Duration
Provisioning must be disabled for the

period beginning when the database is
backed up on Node 2, and ending when
Node 1 takes over traffic from Node 2.
Subscriber controlled input (* codes) is

4 hours
disabled after the database is backed up
on Node 2, until Node 1 takes over traffic.
Users & Resources:
Table 32
Comment
4 Hours
(SMU Method)
2 Hours
(Toolkit Method)
Item #2 applies
to the SMU
Method only
n/a
Operational Impacts Provisioning
8.1.5.2 Call Processing

Note: Table 33 applies to Section 8.6, Upgrading a Standard Duplex System
(SMU Method).
Impact
Duration
General Call Behavior - New Originations: < 30 seconds

During the switch of traffic from the 'old'
release to the 'new' release, there will be a
short duration where new dial tone will not
be available and new calls will be rejected.
General Call Behavior - Transient Calls:

< 30 seconds
Calls in the process of being set up on the
'old' release will be lost.
General Call Behavior - Mid-call Features: Until all 'old'

Mid-call features will not operate until the release calls
call is released & re-established.
complete
SIP Calls - Registration data:

60 minutes
Registration data that is updated after the
database is backed up is lost following the
upgrade.
Table 33
Comment
Lost registrations
are refreshed after
60 minutes, or
when a new call is
initiated from the
endpoint.
Operational Impacts Call Processing (Sheet 1 of 2)
A31003-H8050-J100-09-7631, 09/2011
451
smu_linux_R1.fm
Impact
Comment
SIP Calls - Keysets:

60 minutes
Keyset information (stop hunt, make busy
etc.) is lost and must be refreshed following
the upgrade.
Refresh of keyset
data occurs
automatically via
periodic
SUBSCRIBE_NO
TIFY
SIP Calls - Session Timers (for a V3.1R3

source release):
Calls with session timers active may be lost
after switching call control from the V3.1R3
source release (node 2) to the V5 target
release (node 1).
This is because the target release (V5) is
not aware of any existing calls.
Session timers
can be turned off
prior to the
upgrade (1 day) to
reduce the impact
of this issue.
SIP Calls - Session Timers (for a V4R1 and Until call control is
later source release):
switched to the
Calls set up on the source release during target release.
the Split Mode Upgrade (SMU) and prior to
switching call control from the source
release (node 2) to the V5 target release (
node-1) will not use Session Timing.
TLS Subscribers connections to devices

using TLS will be lost during a fallback from
V5R0 to V3.1R3/V4R1. The TLS
connection will be reestablished upon the
next device reregistration.
Table 33
452
Duration
Until all the

V3.1R3 (source
release) calls
complete.
Calls established
on the target
release will use
Session Timing (
if RTP parameter
Srx/Sip/
Session_Timer is
set to YES )
Next reregistration
(typically 60
minutes
maximum)
Operational Impacts Call Processing (Sheet 2 of 2)
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Prerequisites
8.2 Prerequisites
8.2.1 System Information and Access Rights
The super user passwords for both cluster nodes will be required during the
execution of the upgrade.
Consoles should be opened to each node for the duration of procedure execution.
Since V2.1, remote login as user srx or root is no longer permitted. Consequently,
the system must be accessed using the default sysad user-id, followed by a
subsequent login to the srx or root account, using the su command as shown
below:
<< Logged in
> su - srx
<< Logged in
> exit
<< Return to
> su << Logged in
# exit
<< Return to
as sysad >>
as srx >>
sysad >>
as root >>
sysad >>
8.2.2 Logging
All actions should be logged via console log, the Linux script command or other
mechanism.
8.2.3 IP Network Requirements for Geographically

Separated Nodes
Attention: For this section use the NCPE tool of the source release. A good
practice is to employ the latest released version of the NCPE tool. Any questions
To upgrade geographically separated nodes, you must first establish static routes
between the billing networks of the two nodes. This is needed so that the
components that drive the split mode upgrade can communicate with each node
for the entire upgrade process.
Ensure that the IP network in which the two nodes are connected is configured to
allow such routing.
Verify the billing network static routes as follows:
A31003-H8050-J100-09-7631, 09/2011
453
smu_linux_R1.fm
Prerequisites
1. Copy the Voice server node.cfg (/etc/hiq8000/node.cfg) to a PC from where

the NCPE tool can be run. Use the NCPE tool of the source release. A good
practice is to employ the latest released version of the NCPE tool. Locate the
Billing subnet details. Identify the following values;
The bonding Ethernet device name for the billing interface (the default is
bond2).
The Subnet and Netmask IP addresses for Node1 and Node2.
The static routes use the following format:

-net <Subnet Node2> netmask (Netmask Node2> gw <Node1 billing
gateway> dev <billing bond interface>
-net <Subnet Node1> netmask (Netmask Node1> gw <Node2 billing
gateway> dev <billing bond interface>
For example, assume that a geographically separated cluster has the
following characteristics:
Node1
Billing interface IP address is 10.4.43.10
Billing network IP address is 10.4.43.0
Netmask is 255.255.255.0
Router interface IP address on that network is 10.4.43.1
Node2
Billing interface IP address is 10.7.43.10
Billing network IP address is 10.7.43.0
Netmask is 255.255.255.0
Router interface IP address on that network is 10.7.43.1
Using this example, the static routes would be as follows:

-net 10.7.43.0 netmask 255.255.255.0 gw 10.4.43.1 dev bond2
-net 10.4.43.0 netmask 255.255.255.0 gw 10.7.43.1 dev bond2
2. If the static routes from step 1 do not already exist in the node.cfg they must
be added. If necessary add the static routes from step 1 to the node.cfg file
(in the IP Configuration screen of the NCPE) and save the updated node.cfg.
3. Replace the node.cfg on each node with the updated node.cfg. This will
ensure the new static routes are maintained through the upgrade. It is a good
practice to keep a backup copy of the original node.cfg.
4. To ensure that the added routes are present through the whole of the SMU,
manually add the same static routes from step 1 to each node of the Voice
server as follows:
a) Log in as user root starting with node 1.
b) Execute the following command. Save the log output for the verification
of the static route addition.
454
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Prerequisites
# netstat -anr
c) Add the route to node 2 billing subnet on node 1. An example based on
the step 1 information follows:
# route add -net 10.7.43.0 netmask 255.255.255.0 gw
10.4.43.1
d) Execute the command netstat anr. Compare the log result against that
of step b). Verify the addition of the new static route and that previously
established static routes are maintained. You may want to save both log
results.
# netstat -anr
e) Log in as user root on node 2.
f)
Execute the following command. Save the log output for the verification
of the static route addition.
# netstat -anr
g) Add the route to the node 1 billing subnet on node 2. An example based
on the step 1 information follows:
# route add net 10.4.43.0 netmask 255.255.255.0 gw
10.7.43.1
h) Execute the command netstat anr. Compare the log result against that
of step f). Verify the addition of the new static route(s) and that previously
established static routes are maintained. You may want to save both log
results.
bocastress1a: # netstat -anr
The route add procedure for Geographically Separated Nodes is complete.
8.2.4 Convert to Multi-Partition System

Note: The V5 Restore CD should not be used to convert a V3.1R3 system to a
multi-partition disk. The V5 Restore CD uses a different scheme for partitioning
and therefore the V3.1R3 Restore CD should be used.
Some early V3.1R3 systems use a single-partition disk format; these systems
must first be converted to a multi-partition disk format before attempting the SMU
for a standard duplex. Apply MOP P30310-Q2582-Q031-xx-7620, Conversion to
a Multi Partition Platform before attempting the SMU. The SMU script will not run
without this MOP installed.
A31003-H8050-J100-09-7631, 09/2011
455
smu_linux_R1.fm
Preparation Phase
8.3 Preparation Phase

Note: With the removal of secondary IP addresses, OpenScape Voice Servers
installed as network separated systems, can not be upgraded to V4R1 (or higher
releases) until it is verified that no component in the OSV system network is using
IP addresses that are being removed. See the Appendix I, Removal of Obsolete
IP Addresses when Upgrading to V4R1 (or higher releases) in case of network
separated systems.
Run the following steps in preparation for the upgrade one week prior to the
upgrade.
8.3.1 Collect System Data on Node 1

1. Log on to Node 1 as user sysad and switch to super user.
2. Collect system data and create the node.cfg file.
Enter the following commands, in this order, to collect system information and
to create the node.cfg based on the information gathered on the node:
# cd /opt/unisphere/srx3000/SWO/bin
# ./smu_data_collection.sh
When prompted, type y to proceed. This collects the configuration data and
saves it in the current directory in a file named as follows:
cfg_<node-name>_<release>_<date-time>.rpt
The following output will be displayed:
456
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Preparation Phase
====================================
=
Upgrade Data Collection
=
====================================
This script will collect system information
required for an upgrade.
Do you want to proceed?
Enter 'y' to continue, n to exit: y
(enter y here)
Wed Feb 4 11:47:45 EST 2009 linux1

Creating node.cfg...
Generating system configuration report...
smu_data_collection.sh [INFO]
Collecting OS Information...
Collecting Package Information...
Collecting Routing Information...
Collecting System File Information...
Collecting System Defaults Information...
Collecting System Security Configuration...
Collecting DNS Information...
Collecting Cron Information...
Collecting Inet Config Files Info...
Collecting Snort Information...
Collecting Startup scripts list...
Collecting User Information...
Collecting Group Information...
Collecting Misc Information...
Collecting Shutdown Agent Information...
Collecting SNMP Information...
Collecting SNMP trap destinations...
Collecting CLI Users...
Collecting CLI Roles...
System configuration written to cfg_linux1_R11.00.03.ALL.12_04_Feb_11_47.rpt
Building tar file...
Results stored in dc_linux1_R11.00.03.ALL.12_04_Feb_11_47.tar
====================================
=
Data collection complete
=
====================================
#
The smu_data_collection script collects the system specific settings

(such as host file, routes, users, groups, etc.) and generates two files: the
node.cfg of the old release and the system configuration report.
The node configuration file is named as follows:
node_<node-name>.cfg
For example, node_linux1.cfg.
A31003-H8050-J100-09-7631, 09/2011
457
smu_linux_R1.fm
Preparation Phase
The system configuration report is named as follows:

For example, cfg_linux1_R11.00.03.ALL.12_04_Feb_11_47.rpt.
Additionally, the node.cfg and the system configuration report (*.rpt) are
stored in a .tar file in the current directory and named as follows:
dc_<node-name>_<release>_<date-time>.tar
For example: dc_linux1_R11.00.03.ALL.12_04_Feb_11_47.tar.
3. Move the collected configuration data file (cfg_<node-name>_
<release>_<date-time>.rpt) to directory /log/smu and rename it to
system_configuration_report.rpt.
For example:
#ls -ltr
The (cfg_<node-name>_<release>_<date-time>.rpt) is listed near the
bottom.
# mv cfg_linux1_R11.00.03.ALL.12_04_Feb_11_47.rpt
/log/smu/system_configuration_report.rpt
Note: Be sure to copy the renamed configuration data file
(system_configuration_report.rpt), the node configuration file
(node_<nodename>. cfg), and the tar file (dc_<node-name>_<release>_<datetime>.tar) to an external server for later reference.
8.3.2 Create the Node.cfg for the Target Release

Attention: This section is only for use with Section 8.6, Upgrading a Standard
Duplex System (SMU Method). All other Upgrade/Migration procedures should
use the Create Node.cfg procedure indicated in their respective checklist.
Note: In OpenScape V5, Source-Based IP Routing is implemented. If route

OK button should be selected. For more information regarding the Source
Based Routing feature, refer to Chapter 7, Overview of Upgrades and Migrations
to OpenScape Voice V5.
The implementation or updating of source based routes during an upgrade will
require the use of a Migration strategy (and therefore a system outage).
Migration strategies are detailed in Chapter 9, Migrations to OpenScape Voice
V5. For duplex systems, if an OpenScape Voice system outage cannot be
tolerated during the upgrade, then the Split Mode Upgrade (SMU method) will
458
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Preparation Phase
need to be performed. The SMU upgrade method is detailed in Chapter 8,

Upgrading a Standard Duplex System (SMU Method). As a general rule, no
changes to the OSCV target release node.cfg are allowed during the three
upgrade procedure detailed in Chapter 8, Upgrades to OpenScape Voice V5.
After a Chapter 8 upgrade procedure is completed, the EZIP feature can be
employed to establish source based routing (by specifying default gateway
addresses). For more information regarding the EZIP feature, refer to Chapter F,
Updating the Node.cfg File (Also Known as EZIP). Any questions should be
Use the latest version of the OffLineWizard software indicated in the release
notes for the target release.
1. Transfer the node_<node-name>.cfg file generated in Section 8.3.1, Collect
System Data on Node 1, on page 456 to a Windows/Linux machine that can
run the OfflineWizard.
2. Start the OffLineWizard. Select Install on the first screen, click Next, then
select Expert Mode on the next screen.
3. From the NCPE GUI:
Attention: Only the modifications described below to the target node.cfg are
supported by the upgrade procedure. If other parameters or IP addresses are
to be changed, they should be modified after the upgrade procedure is
completed.
a) Under File, open the file node_<node-name>.cfg (e.g.,
node_linux1.cfg) that was created in Section 8.3.1, Collect System
Data on Node 1 and generate the node.cfg for the target release.
b) Answer Yes to question The file node_<node-name>.cfg is from
source release (example given; V4.0R1). Do you want to convert it to
target release (example given; V5.0)?
Answer OK to Messages indicating route operations have been
performed.
c) Enter OK and the click OK to the Warning window to accept new
parameters added to the node.cfg.
d) Under Configuration and Hardware (1/1) make sure that the
Installation_mode is set as follows:
single_node_to_create for node 1 (node.cfg.primary) in a cluster.
single_node_to_add for node 2 (node.cfg.secondary) in a cluster.
e) Under Additional Parameters (1/1) update the Software Build ID to the

target release.
A31003-H8050-J100-09-7631, 09/2011
459
smu_linux_R1.fm
Preparation Phase

performed.
If this OpenScape Voice server does not carry CSTA traffic go to step 3f.
If this OpenScape Voice server does carry CSTA traffic, it is necessary
(due to security rules being tightened for CSTA servers in V5) to update
the CSTA server addresses to the node.cfg.
Update the CSTA server addresses to the node.cfg as follows:
Note: The IP addresses in the CSTA Servers table are used to build the
more secure V5 packet filtering rules. Contact your next level of support
if you have questions.
1. Select the IP Configuration (4/6) screen.
2. Enter IP configuration parameters for the CSTA Servers ONLY. Click
the appropriate icon below the CSTA Servers table to enter more (or
remove) entries.
3. Go to step 3f.
f)
Select the IP Configuration (5/6) screen.

If Static/Source Routes exist please verify there are NO duplicate routes.
Duplicate routes will result in Image installation failures. Duplicate routes
should be deleted using the Delete button (X) provided with each table. A
method to verify the existence of duplicate routes is to employ the
Preview mode, which is accessed by selecting the Preview icon in the
NCPE menu bar (or by selecting the File menu and then Preview).
This same exercise should be performed in the IP Configuration (6/6)
screen as required.
g) Check and correct all errors/warnings (all red marked items).

There is an exception: The user may disregard the warning about node
name that contain an underscore. This will happen if the node name of
the old release contains underscore and, by design, the same node name
has to be carried over to the new release.
h) If you are upgrading geographically separated nodes, ensure that static
routes described in Section 8.2.3, IP Network Requirements for
Geographically Separated Nodes, on page 453 are correct. If they are
not correct, the upgrade will start but will fail later in the upgrade process.
460
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Preparation Phase
i)
Select File, Save As, set File of Type to All Files, and enter File
name: node.cfg.primary for node 1 of the duplex system or the single
node of a simplex system. Click Save, make note of the path to which
the file was saved and then click OK.
Note: Ensure the file was not saved with a name that has a .cfg extension
(for example: node.cfg.primary.cfg). The file name should be without the
second .cfg extension (in fact: node.cfg.primary).
j)
If this is a simplex system, proceed to step 4. If this is a duplex system,

return to the Configuration and Hardware (1/1) page of the NCPE. Set
the Installation_mode to single_node_to_add.
k) Select File, Save As, set File of Type to All Files, and enter File
name: node.cfg.secondary for the second node of the duplex system.
Click Save, make note of the path to which the file was saved and then
click OK.
(for example: node.cfg.secondary.cfg). The file name should be without
the second .cfg extension (in fact: node.cfg.secondary).
4. Exit the NCPE. Select File, Exit, Yes, and Finish.
8.3.3 Copy the Node.cfg Files to USB Memory Sticks

Copy the node.cfg files (primary and secondary [for duplex]) of the new release
to USB memory sticks (one stick required for each node).
Note: Patch sets and emergency patch sets may be loaded onto the USB
memory stick (or sticks - depending on the system configuration) for automatic
installation during the image install. Refer to Section 2.6, Loading Patch Sets
onto the USB Memory Sticks, for details. Unless directed otherwise by Release
Notes the target OpenScape voice server patch level must be V5R0 patch set
6E03 or greater.
A31003-H8050-J100-09-7631, 09/2011
461
smu_linux_R1.fm
Preparation Phase
8.3.4 Verify Prerequisites Met According to Release

Notes
The release notes identify the order of the upgrades (Assistant, Media Server,
etc.) and all prerequisites and dependencies before upgrading the system. Verify
that the specified prerequisites are met. Also prepare any necessary files needed
for Applications installation/upgrade (for example: response files, licenses).
Attention: In V5R0 (and later releases), integrated systems response files are
built automatically as part of the installation process. Response files no longer
response file is found on the USB stick, that file will take precedence over the file
that is automatically generated via the Image installation.
Attention: For upgrades/migrations, if the OSV server Solid password is not dba,
it must be changed to dba using CMP (to ensure the solid password is updated
on both nodes in the case of a duplex system). Remember to restore the OSV
server Solid password at the end of the upgrade/migration procedure.
For Applications without UC service refer to the appropriate section title in this
document;
Response File for the Integrated Simplex Deployment
Response File for Media Server Standalone
Response File for Multiple Communications Server
For Applications with UC service refer to the appropriate section title in the
OpenScape UC Application V3, Installation and Upgrade, Installation Guide;
Example of the Deployment Scenario Standard Duplex (small)
Example of the Deployment Scenario Standard Duplex (large)
8.3.5 Obtain Licenses for the Target Release

Before proceeding with the upgrade procedure, obtain licenses for the target
release.
Note: Refer to Section 2.2.3, Backup License Recommendations, on page 23.
462
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Pre-Maintenance Window Activities
8.4 Pre-Maintenance Window Activities

The following steps must be run prior to the maintenance window to ensure that
the system is ready to be upgraded.
8.4.1 Run RapidStat on Both Nodes and Analyze

Output
For instructions for running Rapidstat, refer to the RapidStat chapter in
OpenScape Voice VxRy (where VxRy indicates the release version, i.e. V3.1R3),
Service Manual, Service Documentation of the source release.
8.4.2 Make Test Calls and Document Results

Make test calls and document results so that the result can be compared with the
same test calls after the upgrade. Note that test calls for the upgrade may be
different than what is required for normal maintenance.
8.4.3 Perform Any Customer Specific System Checks

Perform any customer specific system checks before you continue with the
database and system backup.
8.4.4 Verify V3.1R3/V4R1 Patch Set Level

Attention: Unless directed otherwise by Release Notes the target OpenScape
voice server patch level must be patch set 6E03 or greater. If this is an integrated
system ensure your applications server is updated with the latest released DVD/
PatchSet/HotFix.
Based on the OpenScape Voice V5R0 release notes, ensure that the system is
at the correct V3.1R3/V4R1 patch set level. If it is not, install the correct V3.1R3/
V4R1 patch sets before beginning the upgrade.
8.4.5 Perform a Database and File System Backup

For detailed instructions on the backup procedures;
A31003-H8050-J100-09-7631, 09/2011
463
smu_linux_R1.fm
For V3.1R3 refer to the Maintenance Manual, Volume 2, Backup and

Recovery.
For V4R1 refer to the OpenScape Voice V4R1, Service Manual Volume
2:Service Manual, Service Documentation
8.4.6 Verify the Ethernet Configuration of the External

Applications Server
Ethernet interface eth0 has to be used in the SLES 10 distributions.
To determine which interface is currently being used, log on as root user to the
external application server using ssh or the console and enter the following
command:
# ifconfig
If line inet addr:<IP address of external server> appears in the eth0 entry then
eth0 is being used. If it appears in the eth1 entry then eth1 is being used.
Write down this information as it will be needed later when SLES OS and SP is
installed.
8.4.7 Verify the Hosts File Configuration

Note: Contact your next level of support if you have any questions regarding this
verification procedure.
Logic has been implemented for the /etc/hosts file wherein a new banner, Please
add new hosts under this line, indicates to OpenScape Voice tools that the
Ipaddress-hostname entries that appear below the banner are created by the
user. Employing the banner as such allows OpenScape Voice to carry forward
user-created entries in the hosts file during activities that require the hosts file to
be rebuilt.
Verify the OpenScape Voice /etc/hosts file (or files for duplex systems)
configuration with the following commands (execute on both nodes in duplex
system):
# cd /etc
# cat hosts
A truncated example of an /etc/hosts file with the new banner (with no usercreated entries) is as follows:
464
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
10.235.54.10
rtp_com0_eth6
10.235.54.30
rtp_com1_eth6
########################################
########################################
Proceed as appropriate:
No further action is necessary in the following cases:
The source release /etc/hosts file does not contain user-created entries
and the banner is not present (it will be present in the hosts file after the
SMU is completed).
The source release /etc/hosts file does not contain user-created entries
and the banner is present.
The source release hosts file does contain the new banner and all usercreated entries are below the banner.
Modify the source release hosts file (or files for duplex) if the file contains the
new banner but all user-created entries are not below the new banner.
For duplex systems, the /etc/hosts file of both nodes needs to be updated.
Duplicate entries in the /etc/hosts file should be avoided.
In the following example, the nmcsnmptrap and host_pc are user-created
entries in the hosts file containing the new banner. If a user-created entry
needs to be moved from above the banner, place it as the last line (bottom of
the list below the banner) in the /etc/hosts file. Remember to update both /etc/
hosts files in a duplex system.
10.235.54.10
rtp_com0_eth6
10.235.54.30
rtp_com1_eth6
########################################
########################################
10.235.200.230
nmcsnmptrap
10.235.200.29
host_pc
Copy and save the source release /etc/hosts file (or files for duplex) to a safe
location (not on the OpenScape Voice server!) if it does not contain the new
banner (as shown above) and it contains user-created entries.
Copy and save duplex system hosts files with names indicative of which node
the hosts file is saved from (for example: hosts_n1 and hosts_n2). After the
SMU is complete the new banner will be present in the target release /etc/
A31003-H8050-J100-09-7631, 09/2011
465
smu_linux_R1.fm
hosts file of the OpenScape Voice server and you can use the source release
hosts file (or files for duplex) you saved to rebuild the user-created entry list
in the target release /etc/hosts file.
Attention: When servers (e.g media server or DLS) in the same network as
one of the OSV's subnets need to communicate with another of the OSV's
subnets, then changes to the network firewall are required to allow this
communication. Any questions should be addressed to the next level of
support.
8.4.8 Executive Assistant with Cockpit

If your Applications employ the Executive - Assistant with Cockpit feature,
the source release '.eag' files must be backed up to an external server for
restoral after the upgrade.
The files are found on the Simplex and Low Cost OpenScape Voice Integrated
Applications server at:
/enterprise/HiPathCA/WebSpace/Portal/webapps/eacockpit-osc/WEB-INF/
groups
The files are found on the External Application Server(OFFBoard) server at:
/opt/siemens/HiPathCA/WebSpace/Portal/webapps/eacockpit-osc/WEBINF/groups
In the target release, these .eag files will be copied to the upgraded Applications
server. This activity is addressed in the "Post Upgrade Actions, Section 7.5.6,
Executive - Assistant with Cockpit section.
466
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Upgrading an Integrated Simplex System (Toolkit Method)
8.5 Upgrading an Integrated Simplex System (Toolkit Method)

Attention: If a Fallback is required after installing the target release images
(image for an integrated system), follow the instructions in Section 8.11.7,
Fallback for Toolkit Upgrades/Migrations, on page 528.
Any questions should be addressed to your next level of support before
proceeding.
Attention: For upgrades, if the OSV server Solid password is not dba, it must be
changed to dba using CMP (to ensure the solid password is updated on both
nodes in the case of a duplex system). Remember to restore the OSV server
Solid password at the end of the upgrade procedure.
Attention: The previous Switchover Controller Sequencer (CSOCSC) upgrade

procedure for integrated simplex systems is no longer supported. Upgrades to
integrated simplex systems are now performed using the migration toolkit and this
checklist.
No modifications to the voice server hardware, product type or deployment are
expected in this procedure. If the voice server hardware, product type or
deployment is to be changed a procedure from Chapter 9, Migrations to
OpenScape Voice V5, should be employed for the upgrade.
The upgrade (data export, image install, and data import) takes approximately 70
minutes to complete with a system downtime of approximately 60 minutes.
At the discretion of the technician checklist tasks 1 through 9 may be performed
prior to the upgrade maintenance window.
Use Table 34 to monitor the upgrade. Perform only the task indicated and then
return to the checklist. As an example; if the checklist indicates Section 7.3.1
should be performed, follow the link to Section 7.3.1, perform that task, and return
to the checklist.
A31003-H8050-J100-09-7631, 09/2011
467
smu_linux_R1.fm
Hint: When viewing the Installation and Upgrade Guide (IUG) with Adobe Reader
add the Previous View icon to the Reader toolbar. This will ease the navigation
between the checklists and associated sections of the IUG. Add the Previous
View icon as follows;
Open the tools menu
After executing a checklist task, select the Previous View icon in the Reader
toolbar to return to the checklist.
Task
Description
1.
Refer to Section 8.1.2, Preparation Checklist, on page 447 and

Section 8.1.3, Required Documents, on page 448.
2.
Refer to Section 8.2.1, System Information and Access Rights, on

page 453 and Section 8.2.2, Logging, on page 453.
3.
Refer to Section 8.3.4, Verify Prerequisites Met According to Release

Notes, on page 462 and Section 8.3.5, Obtain Licenses for the Target
Release, on page 462.
Note: During an upgrade from VnRx to VnRy (e.g., fromV4R0 to
V4R1), licenses are transferred automatically from the source release
to the target release. Thus, the procedure described in Section 8.3.5
may not be required. Generally, most upgrades are from VaRx to VbRy
(e.g., fromV4R1 to V5R0) and in this case new licenses have to be
obtained for the target release as described in Section 8.3.5.
4.
Refer to Section 8.4, Pre-Maintenance Window Activities, on page

463.
5.
Perform the procedure in Section Section 8.3.1, Collect System Data

on Node 1, on page 456. This procedure will provide a source release
node.cfg that can be modified for use in the target release (in Task 6).
6.
Create the node.cfg for the target system. Refer to Section 9.3, Create
the Node.cfg for the Target System, on page 596.
Table 34
468
Simplex Upgrade (Sheet 1 of 4)
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Task
Description
7.
Copy the node.cfg.primary file for the target system to a USB memory
stick and label the stick node.cfg.primary.
Note: Patch sets and emergency patch sets may be loaded onto the
USB memory stick (or sticks - depending on the system configuration)
for automatic installation during the image install. Refer to Section 2.6,
Loading Patch Sets onto the USB Memory Sticks, for details.
Attention: Unless directed otherwise by Release Notes the target

OpenScape voice server patch level must be V5R0 patch set 6E03 or
greater. After the installation completes an integrated system should
ensure the applications server is updated with the latest released DVD/
PatchSet/HotFix.
Table 34
A31003-H8050-J100-09-7631, 09/2011
469
smu_linux_R1.fm
Task
Description
8.
Create the response.cfg.primary file using one of the methods below.

Method#1:
The response.cfg.primary is similar to the response file you will find on your
source installation at: /enterprise/servicetools/install/conf/responsefile.txt.
Copy this responsefile.txt to your USB stick and rename it to
response.cfg.primary. Parameters SI_SYMPHONIA_ADMIN_PASSWORD
and SI_DB_LOGON_PASSWORD must be edited because in this file the
password's are encrypted. Please replace the encrypted password string
with the "normal" password string. Replace the IP's you find inside
response.cfg.primary with the Admin IP of node 1. This is the nafo0 IP listed
for node 1 in the target release node.cfg.
If you ran an earlier import8k or migrate8k with -noapps options, and choose
to preserve the application data, then set SI_FW_DB_MIGRATION=true in
the response file.
Text at the end of this task explains How to determine Admin IP of node 1
(nafo0 IP);.
Method#2:
If you choose to use a template then please add the same
SI_COMMUNITY_NAME, SI_SYMPHONIA_ADMIN_PASSWORD,
SI_DB_LOGON_PASSWORD as actually configured at your source system.
For a guide to help build the response file from a template refer to Section
5.2.4.2, Response File for the Integrated Simplex Deployment, on page
341.
Make sure to populate the correct IP's for IP related fields in the template.
The IP you should be employing is the Admin IP of node 1. This is the nafo0
IP listed for node 1 in the target release node.cfg. Text at the end of this task
explains How to determine Admin IP of node 1 (nafo0 IP);
the response file. Copy this file to your USB stick and rename it to
response.cfg.primary.
How to determine Admin IP of node 1 (nafo0 IP);
The admin IP will be the IP address assigned to node 1 of nafo0 in the target
release node.cfg file. In the following example, 1.2.3.6 is the nafo0 node 1 IP
(this example is an excerpt of the nafo configuration from a Low Cost
node.cfg);
Table 34
470
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Task
Description
9.
For upgrades, if the OSV server Solid password is not dba, it must be
changed to dba using CMP.
Remember to restore the OSV server Solid password at the end of the
upgrade procedure.
10.
Run RapidStat. Errors and/or Warnings must be reviewed and

corrected as necessary before continuing. Download the migration
toolkit software (UNSPmigration-<V#>.rpm) and install it onto the
source system. Refer to Section 9.4 on page 600.
11.
Export the data of the source system to the USB memory stick labeled
node.cfg.primary. Refer to Section 9.5 on page 601.
12.
Install the OpenScape Voice V5 image onto the target system. Refer
to Section 4.2, Installation via DVD, on page 213.
Attention: Do not disconnect the USB stick as indicated in the
Section 4.2 procedure; leave the USB stick connected until directed by
the migration procedure instructions to disconnect.
13.
Log in to node 1. Refer to Section 8.9.1, Log In to Node 1, on page

500.
14.
Customize node 1. Refer to Section 8.9.2, Customize Node 1, on

page 501.
Note: Unless directed otherwise by Release Notes the target
greater. An integrated system should ensure the applications server is
updated with the latest released DVD/PatchSet/HotFix.
15.
Download the migration toolkit software (UNSPmigration-<V#>.rpm)

and install it onto the target system. Refer to Section 9.6 on page 602.
16.
Import the data of the source system from the USB memory stick
labeled node.cfg.primary to the target system. Refer to Section 9.7 on
page 602.
17.
Remove the migration toolkit software (UNSPmigration-<V#>.rpm)

from the target system. Refer to Section 9.8 on page 604.
18.
Execute RapidStat and place test calls to verify there are no issues and
that the system is functioning correctly.
19.
Complete the upgrade. Refer to Section 7.4, Completing the Upgrade

to V5, on page 437.
Table 34
A31003-H8050-J100-09-7631, 09/2011
471
smu_linux_R1.fm
Upgrading a Standard Duplex System (SMU Method)
8.6 Upgrading a Standard Duplex System (SMU Method)

Before starting this procedure, review and perform activities as required in
the following sections:
Section 8.1, Procedure Descriptions
Section 8.2, Prerequisites
Section 8.3, Preparation Phase (a failure will occur later during the SMU if
you do not perform the procedure in Section 8.3.1, Collect System Data on
Node 1, on page 456).
Section 8.4, Pre-Maintenance Window Activities.
Attention: For upgrades, the /etc/security/access.conf file CAN NOT have any of
the user access lists remarked out. The user access list should be restored
before the SMU is started. This activity must be performed on each node.
Questions should be addressed to your next level of support. Examples
follow;
An access.conf file with the srx user remarked out. The pound sign would
remove access restrictions for the srx user;
# -:srx:ALL EXCEPT LOCAL 10.235.200.247 srxl217a fsc301
fsc301_cip0 srxl217a_cip0 srxl217b fsc302 fsc302_cip0
srxl217b_cip0 console localhost
tty1 tty2 tty3 tty4 tty5
tty6 clusternode1-priv clusternode2-priv
To restore srx user access list remove the pound sign;

-:srx:ALL EXCEPT LOCAL 10.235.200.247 srxl217a fsc301
fsc301_cip0 srxl217a_cip0 srxl217b fsc302 fsc302_cip0
srxl217b_cip0 console localhost
tty1 tty2 tty3 tty4 tty5
tty6 clusternode1-priv clusternode2-priv
The upgrade will be controlled from Node 2. On this node, the user will start the
Switchover Controller Sequencer (CSOCSC). The CSOCSC provides menus
that offer a set of options that are relevant to the actual upgrade phase. In the
course of the upgrade, Node 2 will be isolated from the network.
472
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
The CSOCSC should be started from a console or remote Keyboard, Video,

Mouse (KVM) via Intel Management Module (IMM) (IBM platform x3650T or
x3550 M2/M3) or iRMC (FSC Platform RX330 or FTS Platform RX200) on node
2. The reason is that if the CSOCSC is started from an SSH session through the
network, once Node 2 becomes isolated, no commands can be entered.
The CSOCSC has two modes: normal (default) and expert. Functionally they are
the same. The difference is that the normal mode stops for user input fewer times
through the upgrade. The expert mode will stop and prompt for confirmation
several more times during the upgrade. It provides more control and might be
desired if there are actions to be made manually after certain points in the
upgrade.
This upgrade example uses the normal mode. If you need to use the expert mode
contact your next level of support before and during the upgrade as necessary.
The upgrade (beginning with the export of source data and ending with the first
call) takes approximately 225 minutes to complete with no system downtime. If
you use HMS you will not have announcements for one to two hours (depending
on the path you must follow to update your Applications server)
Upgrade the standard duplex system as follows:
1. As user root on node 2 (do not use ssh, log in either from the console or RSA/
iRMC), start the CSOCSC with the commands:
cd /opt/unisphere/srx3000/SWO/bin
./csocsc
Example screen output follows. User input is in bold. Type the required choice
and then press Enter.
linux2:/opt/unisphere/srx3000/SWO/bin # ./csocsc
Cluster Switchover Controller Sequencer Server v.03.01.0002
(C) Copyright 2007, 2008 Siemens Enterprise Communications
NOTE: You may use this software only in accordance with the terms of
your license agreement, located on any of the installation CDs for this
product.
CSOCSC:
CSOCSC:
CSOCSC:
CSOCSC:
CSOCSC:
CSOCSC:
CSOCSC:
Starting in NORMAL mode...

Checking execution mode consistency...(/lock/.csocsc_mode.lock)
Saving execution mode (NORMAL)...
CSOCS server is not running. Starting it...
Trying to attach to CSOCS on port 50000...
Trying to attach to CSOCS on port 50000...
Attached to CSOCS.
2. Start the upgrade. At the following screen, type 1 and press Enter, then type
y and press Enter:
---------------------------------------------------------------Split Mode Installation Menu
-o(STATE=STARTUP)
---------------------------------------------------------------IMPORTANT NOTE: This procedure may lead to a total system outage if
not executed properly. If not sure on how to execute a split mode
A31003-H8050-J100-09-7631, 09/2011
473
smu_linux_R1.fm
upgrade or how to recover the system, please stop now and exit.
To initiate the Split Mode Upgrade (SMU), select option '(1) START
UPGRADE' below.
(1)
(2)
(3)
- START UPGRADE
- FALLBACK: Perform FALLBACK
- GET RTP STATUS: Local only
(99) - EXIT
-> 1
The installation will proceed with the following steps:
- The system health is about to be checked using RapidStat.
- The configuration of both nodes is going to be checked.
- The configuration will be exported.
Are you sure you want to execute these actions? (y/n):y
Attention: If the CSOCSC displays a screen indicating that the RapidStat

diagnostic produced warnings, open a new window and check the /log/smu/
RapidStatFullReport.txt file. If necessary, contact your next level of support
before continuing. Otherwise, type 1 and press Enter to continue.
3. Stop the RTP and database on node 1. At the following screen, type 1 and
press Enter, then type y and press Enter:
Attention: This step will stop call processing on node 1. Do not proceed
unless node 2 has been verified to be operating normally and is capable of
taking over traffic.
-------------------------------------------------------------------Split Mode Installation Menu
-o(STATE=CLUSTER_SMU_STARTUP)
-------------------------------------------------------------------IMPORTANT NOTE: This procedure may lead to a total system outage if
not executed properly. If not sure on how to execute a split mode
upgrade or how to recover the system, please stop now and exit.
INSTALLATION' below.
(1)
(2)
(3)
- START INSTALLATION: Stop RTP & DB on NODE 1

(99) - EXIT
-> 1
RTP & DB on NODE 1 are about to be stopped.
Are you sure you want to execute this action? (y/n):y
4. Verify that the management interface is running as follows:
474
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
a) On Node 2, open a new window (on the system console, press the Alt and
F2 keys to open a second window and press the Alt and F1 keys to switch
back to the first window) and log in (if necessary) as root.
b) Enter the following command:
su - srx -c startCli
c) When prompted to log in, type sysad.
Login: sysad
d) When presented with the startCli menu, select 99 to exit.
Do not proceed if at any point during steps 4a through 4d an error occurs.
Attention: Fallback point 1: If, for any reason, the procedure cannot be
continued at this point, refer to Section 8.11.1, Fallback Procedure 1.
5. Transfer accumulated CDRs from Node 1 to a remote billing server or other
safe storage location. This will prevent the loss of these records when Node
1 is upgraded.
Note: First check the billing mode (push/pull) of the system; if it is push mode,
the CDRs are stored at the respective billing server and not at /cdr. If this is
the case, skip this step. If the billing mode is pull mode or if the files are stored
locally at /cdr, then first check the /tpa/cdr directory. This is because the CDRs
are initially stored and processed from /tpa/cdr and a time/size parameter
defines when the files are moved to /cdr. So, there may be new files in /tpa/
cdr that have not been moved to /cdr.
# cd /cdr
Transfer all CDR records to remote storage.
6. Transfer Malicious Call Trace (MCT) records from Node 1 to a safe storage
location. This will prevent the loss of these records when Node 1 is upgraded.
# cd /unisphere/srx3000/srx/40/mct
Transfer all MCT records to remote storage.
On Node 2, return to the original window (on the system console, press the
Alt and F1 keys).
7. Shutdown node 1 and split the cluster. At the following screen, type 1 and
-------------------------------------------------------------------Split Mode Installation Menu
-o(STATE=STOP_REMOTE_NODE_OK)
-------------------------------------------------------------------RTP & DB have been stopped successfully on NODE 1.
To continue the SMU procedure, please select option '(1) CONTINUE
A31003-H8050-J100-09-7631, 09/2011
475
smu_linux_R1.fm
(1)
(2)
(3)
- CONTINUE INSTALLATION: Shutdown NODE 1 & Split cluster

- FALLBACK: Restart RTP & DB on NODE 1
(99) - EXIT
-> 1
The shutdown of NODE 1 and cluster split actions are about to be
executed.
8. Verify that Node 1 has shut down as follows:

a) Press the left Alt and F10 keys on Node 1s console, the last line should
state System Halted).
b) On Node 2, enter the command:
# ifconfig -a | less
Use the arrow keys to move up and down. Press Q to quit.
For the x3650T platform; Verify that NO inet Address line is showing for
eth2 or eth4.
For the RX330 platform; Verify that NO inet Address line is showing for
eth1 or eth5.
For the x3550 M2/M3 platform; Verify that NO inet Address line is
showing for eth3 or eth7.
For the RX200 platform; Verify that NO inet Address line is showing for
eth3 or eth7.
The following sets of screenshots are from an x3650T platform;
eth2
Link encap:Ethernet HWaddr 00:0E:0C:AA:32:CA

BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:1345310 errors:0 dropped:0 overruns:0 frame:0
TX packets:1619163 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1157659294 (1104.0 Mb) TX bytes:1684887062 (1606.8 Mb)
Base address:0xcc00 Memory:fcdc0000-fcde0000
eth4
Link encap:Ethernet HWaddr 00:04:23:CC:75:18

BROADCAST MULTICAST MTU:1500 Metric:1
Base address:0xd800 Memory:fcee0000-fcf00000
If you see an IP Address as in the example below, the system is not split. This
result is not as expected for this stage of the SMU. Do not proceed, contact
your next level of support for assistance.
476
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
eth2
eth4
Link encap:Ethernet HWaddr 00:0E:0C:AA:32:CA

inet addr:10.1.1.2 Bcast:10.1.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0xcc00 Memory:fcdc0000-fcde0000
Base address:0xcc80 Memory:fcde0000-fce00000
Link encap:Ethernet HWaddr 00:04:23:CC:75:18

inet addr:10.1.2.2 Bcast:10.1.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0xd800 Memory:fcee0000-fcf00000
Note: For the external Applications server(s) monitoring the Voice Server
system to be updated;
1. If the external Applications server is deployed as a Multiple Standard
Duplex Communication Server remove the Voice server system to be
updated from the external Applications server List of Switches. Do not add the
Voice Server to the external Applications server until instructed to do so in
step 29 of this procedure.
2. If the external Applications server is monitoring this system only, i.e.
Applications servers deployed in a Standard Duplex - Small Deployment,
stop symphoniad. The symphoniad process will be restarted as part of the
external Applications server Installation/update process.
Attention: Removing an OpenScape Voice server from a Standard Duplex

(Large or Small) UC Applications deployment will result in the loss of UC
application data (e.g.; OpenScape Users/Resources). Any questions should
be addressed to your next level of support before proceeding.
9. Install OpenScape Voice V5 onto node 1 with the image DVD and the USB
stick labeled node.cfg.primary as follows:
A31003-H8050-J100-09-7631, 09/2011
477
smu_linux_R1.fm
a) Ensure that node1 is halted. If it is not halted (indicating an OS issue

outside the scope of this procedure) shutdown the node manually.
Note: Ensure that any OpenScape Voice patch sets or emergency patch
sets that are needed for the upgrade but were not included in the image
DVD are stored on the USB memory stick. Refer to Section 2.6, Loading
Patch Sets onto the USB Memory Sticks, on page 43.
b) Insert the OpenScape Voice V5 Image DVD in the DVD drive.
c) Cycle the power on node 1.
d) Follow the instructions on the screen. Perform these instructions on
node 1 only. These instructions are similar to instruction steps 4 through
8 in Section 4.2, Installation via DVD, on page 213. If you use
Section 4.2 as a reference return to this procedure after step 8 is
complete.
Note: At the end of this step, the new release is installed on Node 1. The
RTP is created and is at run level 3. Both nodes are isolated with regard
to Cluster Foundation (CF), RTP, and Solid DB. However, nfs, rsh, ssh
via bonding devices between the two nodes are possible.
e) When finished, proceed to step 10 to continue the upgrade.
Note that after the target release image installation the OpenScape Voice
server user ids and passwords are set to the target release configuration:
Type
User
Password
Console
root
T@R63dis
Console
srx
2GwN!gb4
SSH
sysad
1clENtk=
SSH
superad
BF0bpt@x
SFTP
cdr
MNY9$dta
10. Log in to node 1. Refer to Section 8.9.1, Log In to Node 1, on page 500 for
instructions.
478
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
11. Customize node 1 and apply the licenses. Refer to Section 8.9.2, Customize
Node 1, on page 501 for instructions.
Note: In SMU step 1, a snapshot of the registered phones was taken. After step
12 completes, the registered phones have approximately 1 hour before their
registrations expire. It is the best practice to not delay in the execution of steps 12
through 16.
12. This step marks node 1 as installation complete and transfers the database
to node 1. Node 1 is then isolated from the network, the RTP is started and
node 1 goes to RTP level 4. From node 2 where the CSOCSC is running, at
the following screen, type 1 and press Enter, then type y and press Enter to
continue the upgrade:
-------------------------------------------------------------------------------Split Mode Installation Menu
-o(STATE=SPLIT_OK)
-------------------------------------------------------------------------------The cluster interconnect has been successfully closed and NODE 1 is shutdown and
ready to be installed with the target SW release
After finishing NODE 1 installation and to continue the SMU procedure, please
select option '(1) CONTINUE INSTALLATION' below.
(1)
(2)
(3)
- CONTINUE INSTALLATION: Mark NODE 1 installation completed.

- FALLBACK: Restore original release of Node1
- GET STATUS: Local only
(99) - EXIT
->1
This action flags the SMU controller that the NODE 1 installation and all manual steps were completed.
The installation procedure will continue with the following steps:
- Collect configuration from NODE 2 and tranfer it to NODE 1.
- Disable all interfaces and start RTP on NODE 1
Are you sure you want to execute these actions? (y/n):y
Note: This step imports the source release configuration to the target release
node. The OpenScape Voice system userids and passwords will now reflect the
source release configuration. The message RCSD is already running may be
seen at the node 1 console command prompt after step 12 is complete. This
message is not an error and can be ignored.
13. Preserve the packet filtering rules. New packet filtering rules that may have
been added (for example, due to modifications to the node.cfg files) have to
be preserved after the database is transferred to Node 1.
A31003-H8050-J100-09-7631, 09/2011
479
smu_linux_R1.fm
As root user, execute the following command on Node 1:

# /etc/init.d/srx_security start trusted
14. Switch the call processing and traffic from node 2 to node 1. At the following
screen, type 1 and press Enter, then type y and press Enter:
-------------------------------------------------------------------------------Split Mode Installation Menu
-o(STATE=PREPARE_SWITCHOVER)
-------------------------------------------------------------------------------RTP was started on NODE 1, but NODE 1 is still isolated.
To continue the SMU procedure, please select option '(1) CONTINUE INSTALLATION'
below.
(1)
(2)
(3)
- CONTINUE INSTALLATION: Swing call processing from NODE 2 to NODE 1

- FALLBACK: Restore original release of node1
- GET STATUS: Local & Remote
(99) - EXIT
-> 1
This action will enable all interfaces on NODE 1 and disable all interfaces on
NODE 2.
It is expected that the call processing is transferred to NODE 1.
15. Verify the following:
The cluster status is split.
Node 2 is at run level 4.
Node 1 is the active node and it is the node handling traffic.
16. Verify that node 1 is handling call processing and functioning correctly as
follows:
a) Make test calls.
b) Special care should be taken to verify the following:
480
Call processing & features
DNS access & configuration by using the dig command:

dig <FQDN to lookup>
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
or, check if the DNS is working by using the following command:

/etc/init.d/bz_node_com_test dns
NTP access & configuration (using command: ntpq -np)
CDR handling connectivity to billing server(s), FTP, user-ids and

passwords
Access from upstream provisioning systems
17. Upgrading the External Application Server (OffBoard).
Direct update from these Applications server levels to the V5 Applications
level is supported;
V3.1R3 DVD8 to V5 Applications
V4R1 DVD3 to V5 Applications
For Multiple Communications Server Admin deployments refer to

Section 5.7, Upgrade of External Application Server (OffBoard) Installation
of this document and the following subsection for the appropriate procedure;
Section 5.7.1, Upgrade of V3.1R3 Applications to V5 Applications, on

page 392
Section 5.7.2, Upgrade of V4R1 Applications to V5 Applications, on

page 395
For Standard Duplex Small or Standard Duplex Large deployments refer

to the OpenScape UC Application V3, Installation and Upgrade, Installation
Guide, section titled Updating, Upgrading and Migrating.
Note: The DLS component can also be installed on the external OpenScape
Applications server; review the DLS release notes for sizing limitations if the DLS
component is to be installed on the external OpenScape Applications server.
18. Verify that the external OpenScape Applications server is configured for
access to node 1 as follows:
a) Allow remote access for srx account on node 1. Refer to Section 5.2.6.8,
Remote Access for srx Account, on page 369 for instructions.
b) Log in (use the same password for the CMP of the previous release) to
the Common Management Portal.
c) Select the OpenScape Voice tab, List of Switches, and select Switches
from the drop down menu.
A31003-H8050-J100-09-7631, 09/2011
481
smu_linux_R1.fm
d) If you reached this step after a fresh install of the appropriate SLES
distribution and target release OpenScape Applications, click Add. The
Configure Switch Addresses screen is displayed.
If the appropriate SLES distribution was already installed on the
applications server and you reached this step after the Update
Installation process steps, click Edit.
e) Ensure that the information (cluster IP, srx password, Node 1/2
management IP addresses, and so on) is correct. Enter the correct
information as necessary.
f)
Click Test Connection for Node 1. If this test is successful, click Cancel
on the bottom of the form.
This step might fail due to srx user access violations.
If it does, ensure that remote access for Node 1 (or Node 2) is configured
correctly and use the pam_tally command to resolve the srx user
access violations before you repeat the step.
As user root on Node 1, query the pam_tally count. For example:
root@bocast4a:[~] #99
# pam_tally
User srx
(1522)
has 25
Note: If there are no pam violations this command returns the command
line prompt.
If the pam_tally reports 5 or more counts for user srx, reset the pam_tally
count for the srx user. For example:
# pam_tally --user srx --reset
User srx
(1522) had 25
Query the pam_tally count again to ensure there are no pam_tally errors
for the srx user. For example:
# pam_tally
Remember that when the upgrade is completed, it is necessary to log in again
to the Common Management Portal, bring up the Switch Information page,
check the information again and save it.
If you are unable to complete step 18 successfully, proceed as follows:
The upgraded OpenScape Voice Applications should fallback to the

previous release.
482

Section 5.8.2, External Application Server (OffBoard) Installation Fallback
from V5 Applications to V3.1R3 DVD8, on page 398 of this document. Any
questions should be referred to your next level of support before proceeding.
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
For Standard Duplex Small or Standard Duplex Large deployments refer

to the OpenScape UC Application V3, Installation and Upgrade, Installation
Guide, section Fallback after aborted Upgrade.
Refer to Section 8.11.4, Fallback Procedure 4.
19. Transfer accumulated CDRs from Node 2 to a local billing server or other safe
storage location. This will prevent the loss of these records when Node 2 is
upgraded. If no safe storage location is available on the local network,
transfer the CDRs to a USB disk or stick and then transfer them from the USB
device to a safe storage location.
Note: First check the billing mode (push/pull) of the system; if it is push mode,
the CDRs are stored at the respective billing server and not at /cdr. If this is
the case, skip this step. If the billing mode is pull mode or if the files are stored
locally at /cdr, then first check the /tpa/cdr directory. This is because the CDRs
are initially stored and processed from /tpa/cdr and a time/size parameter
defines when the files are moved to /cdr. So, there may be new files in /tpa/
cdr that have not been moved to /cdr.
# cd /cdr
<transfer all CDR records to storage>
20. Transfer Malicious Call Trace (MCT) records from Node 2 to a safe storage
location. This will prevent the loss of these records when Node 2 is upgraded.
If no safe storage location is available on the local network, transfer the MCT
records to a USB disk or stick and then transfer them from the USB device to
a safe storage location.
# cd /unisphere/srx3000/srx/40/mct
<transfer all MCT records to storage>
21. Stop the RTP on node 2 and halt node 2. At the following screen, type 1 and
-----------------------------------------------------------------------------Split Mode Installation Menu
-o(STATE=SWITCHOVER_OK)
----------------------------------------------------------------------------NODE 2 is isolated and all applications on NODE 1 should now be
operational.
(1)
down NODE 2.
(2)
NODE 2
(3)
- CONTINUE INSTALLATION: Stop RTP on NODE 2 and shut

- SWITCHBACK: Transfer call processing from NODE 1 to
(99) - EXIT
A31003-H8050-J100-09-7631, 09/2011
483
smu_linux_R1.fm
-> 1
This action will stop RTP and initiate the shutdown of NODE 2 in
preparation for the reinstallation of the local node.
2008.11.06-08:08:35 - linux2 - Checking if remote RTP level is 40
...
2008.11.06-08:08:43 - linux2 - Success - RTP level is 40.
2008.11.06-08:08:43 - linux2 - Disabling the Shutdown Daemon on
remote node...
2008.11.06-08:08:43 - linux2 - Executing </opt/SMAW/SMAWsf/bin
sdtool -e> on partner node...
2008.11.06-08:08:50 - linux2 - Success!
2008.11.06-08:08:50 - linux2 - Success! Shutdown Daemon disabled on
remote node
2008.11.06-08:08:50 - linux2 - Saving state on remote CSOCSS...
2008.11.06-08:08:56 - linux2 - Success! State saved on remote
CSOCSS.
2008.11.06-08:08:57 - linux2 - Stopping RTP & DB on local node (this
may take up to 10 minutes)...
2008.11.06-08:08:57 - linux2 - Executing </unisphere/srx3000 srx/
startup/srxctrl 2 0>...
2008.11.06-08:08:58 - linux2 - Success!
2008.11.06-08:08:58 - linux2 - Success! RTP & DB stopped on local
node.
2008.11.06-08:08:58 - linux2 - Executing <./smu_lock_inst.sh
lock>...
2008.11.06-08:08:59 - linux2 - Success!
2008.11.06-08:08:59 - linux2 - Shutting down local node (you should
expect disconnection in a few minutes)...
2008.11.06-08:08:59 - linux2 - Executing <./smu_shutdown_node.sh
own>...
2008.11.06-08:09:00 - linux2 - Success!
2008.11.06-08:09:00 - linux2 - Success!
Getting autoexec command...
:
:
:
:
:
:
Skipped services in runlevel 0:
nfs
22. Verify the system status is as follows:
Node 2 has shut down (press left Alt and F10 on the console; the last line
should state System Halted).
Node 1 is at run level 4 and processing calls.
Attention: Fallback point 6: If, for any reason, the procedure did not finish as
described (for example, node 2 did not shut down), refer to Section 8.11.6,
General Hard Fallback and then continue to Section 8.11.4, Fallback
Procedure 4.
23. Install OpenScape Voice V5 onto node 2 with the image DVD and the USB
stick labeled node.cfg.secondary as follows:
484
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
a) Ensure that node 2 is halted. If it is not halted (indicating an OS issue

outside the scope of this procedure) shutdown the node manually.
Note: Ensure that any OpenScape Voice patch sets or emergency patch
sets that are needed for the upgrade but were not included in the image
DVD are stored on the USB memory stick. Refer to Section 2.6, Loading
Patch Sets onto the USB Memory Sticks, on page 43.
b) Insert the OpenScape Voice V5 Image DVD in the DVD drive.
c) Cycle the power on node 2.
d) Follow the instructions on the screen. Perform these instructions on
node 2 only. These instructions are similar to instruction steps 4 through
8 in Section 4.2, Installation via DVD, on page 213. If you use
Section 4.2 as a reference return to this procedure after step 8 is
complete.
Note: At the end of this step, the new release is installed on Node 2. The
RTP is created and is at run level 3. Both nodes are isolated with regard
to Cluster Foundation (CF), RTP, and Solid DB. However; nfs, rsh, and
ssh via bonding devices between the two nodes is possible.
Attention: Fallback point 7: If, for any reason, the procedure did not finish
as described (for example, node 2 did not shut down), refer to Section
8.11.6, General Hard Fallback and then continue to Section 8.11.4,
Fallback Procedure 4.
e) When finished, proceed to step 24 to continue the upgrade.
Note that after the target release image installation the OpenScape Voice
server userids and passwords are set to the target release configuration:
Type
User
Password
Console
root
T@R63dis
Console
srx
2GwN!gb4
SSH
sysad
1clENtk=
SSH
superad
BF0bpt@x
SFTP
cdr
MNY9$dta
24. Log in to node 2. Refer to Section 8.10.1, Log In to Node 2, on page 506 for
instructions.
A31003-H8050-J100-09-7631, 09/2011
485
smu_linux_R1.fm
25. Customize node 2 and apply the licenses. Refer to Section 8.10.2,
Customize Node 2, on page 506 for instructions.
26. Start the CSOCS server from the node 2 console. After the CSOCS server is
started the Split Mode Installation Menu should be presented with
STATE=INSTALL_DONE_2. An example display result follows this
command. Log in as user root on node 2 and enter the following commands:
cd /opt/unisphere/srx3000/SWO/bin
./csocsc
The following should be displayed.
linux2:/opt/unisphere/srx3000/SWO/bin # ./csocsc
Cluster Switchover Controller Sequencer Server v.03.01.0002
(C) Copyright 2007, 2008 Siemens Enterprise Communications
NOTE: You may use this software only in accordance with the
terms of your license agreement, located on any of the
installation CDs for this product.
CSOCSC: Starting in NORMAL mode...
CSOCSC: Checking execution mode consistency...(/lock
.csocsc_mode.lock)
CSOCSC: SMU appears to have already been started...
CSOCSC: CSOCS server is not running. Starting it...
CSOCSC: Trying to attach to CSOCS on port 50000...
CSOCSC: Trying to attach to CSOCS on port 50000...
CSOCSC: Attached to CSOCS.
27. Start the RTP on node 2. At the following screen, type 1 and press Enter, then
type y and press Enter:
-o(STATE=INSTALL_DONE_2)
---------------------------------------------------------------NODE 2 has been installed with the target release with all needed
patch sets.
To continue the SMU procedure, please select option (1) CONTINUE
INSTALLATION below.
(1)
(2)
(3)
- CONTINUE INSTALLATION
(99) - EXIT
-> 1
The installation will continue with the following actions:
- Configuration data will be imported on NODE 2.
- RTP will be started on NODE 2.
- SMU Cleanup will be performed on NODE 2.
486
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Note: This step imports the source release configuration to the target release
node. The OpenScape Voice system userids and passwords will now reflect
the source release configuration.
28. Finish the upgrade for the OpenScape Voice servers. At the following screen,
type 99 and press Enter to exit CSOCSC:
-o(STATE=SMU_OK)
---------------------------------------------------------------The Split Mode Upgrade has been successfully completed.
(1)
- GET RTP STATUS: Local & Remote
(99) - EXIT
-> 99
linux2:/opt/unisphere/srx3000/SWO/bin #
29. Configure the external OpenScape Applications server to access the two
nodes as follows:
a) Allow remote access for srx account on node 2. Refer to Section 5.2.6.8,
b) Log in (use the same password for the CMP of the previous release) to
the Common Management Portal.
c) Select the OpenScape Voice tab, List of Switches, and select Switches
d) If you reached this step after a fresh install of the appropriate SLES
distribution and target release OpenScape Applications, click Add. The
Configure Switch Addresses screen is displayed.
If the appropriate SLES distribution was already installed on the
applications server and you reached this step after the Update
Installation process steps, click Edit.
e) Ensure that the information (cluster IP, srx password, Node 1/2
f)
Click Test Connection for Node 1.

A31003-H8050-J100-09-7631, 09/2011
487
smu_linux_R1.fm
correctly and use the pam_tally command to resolve the srx user
access violations before you repeat the step.
# pam_tally
User srx
(1522)
has 25
User srx
(1522) had 25
Query the pam_tally count again to ensure there are no pam_tally errors
for the srx user. For example:
# pam_tally
g) If this test is successful, click Save at the bottom of the form.
Attention: Saving the switch configuration may not be successful the first
time with a Configuration Failed message given due to install key. If
this happens, close the window of the error message and click Save again.
The switch configuration will be successfully saved the second time.
30. This completes the SMU phase of the upgrade. Execute RapidStat and place
test calls to verify that there are no issues after the upgrade and that the
system is functioning correctly. The expected RapidStat results for each
nodes "SMU STATE" are as follows:
Node 1;
SMU STATE: state.lock contents .....
STARTUP
Node 2;
SMU STATE: state.lock contents .....
SMU_OK
Pay particular attention to any Warning or Error messages reported by

RapidStat for either node. If the pre-SMU RapidStat did not report Warning or
Errors messages, it is NOT expected that the post-SMU RapidStat reports any
Warning or Errors messages.
As an example; Licensing errors are reported and it is noticed that the license
data reported by RapidStat does not match the values expected. The first step is
to 're-apply' the target release licenses to each node. Keep in mind that the
license files are keyed to the MAC address of eth0 of the server - apply the
appropriate license file to each node. Section 8.9.2, Customize Node 1 and
Section 8.10.2, Customize Node 2 contain instructions for applying the target
release licenses.
488
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Wait at least 7 minutes and then verify the license data with Cli. If you are not
familiar with this procedure, Section 2.2.4, Download the licenses to the
OpenScape Voice nodes. task 26 contains instructions for reviewing the license
data via Cli.
31. To complete the upgrade to V5R0, refer to Section 7.4, Completing the
Upgrade to V5, on page 437.
A31003-H8050-J100-09-7631, 09/2011
489
smu_linux_R1.fm
Upgrading a Standard Duplex System (Toolkit Method)
8.7 Upgrading a Standard Duplex System (Toolkit Method)

Attention: If a Fallback is required after installing the target release images
(image for an integrated system) follow the instructions in Section 8.11.7,
Fallback for Toolkit Upgrades/Migrations, on page 528. Any questions should be
addressed to your next level of support before proceeding.
Attention: Use this upgrade method only if the customer can accept system
downtime. Otherwise, use Section 8.6, Upgrading a Standard Duplex System
(SMU Method), on page 472.
No modifications to the voice server hardware, product type or deployment are
expected in this procedure. If the voice server hardware, product type or
deployment is to be changed a procedure from Chapter 9, Migrations to
OpenScape Voice V5, should be employed for the upgrade.
The upgrade (data export, image install, and data import) takes approximately
115 minutes to complete with a system downtime of approximately 100 minutes.
Use Table 35 to monitor the upgrade. Perform only the task indicated and then
return to the checklist. As an example; if the checklist indicates Section 7.3.1
should be performed, follow the link to Section 7.3.1, perform that task, and return
to the checklist.
490
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Open the tools menu
Task
Description
1.

2.

3.

4.

463.
5.

6.
7.
stick and label the stick node.cfg.primary; copy the
node.cfg.secondary file for the target system to another USB memory
stick and label that stick node.cfg.secondary.
Unless directed otherwise by Release Notes the target OpenScape
voice server patch level must be V5R0 patch set 6E03 or greater.
8.
Table 35

Standard Duplex Upgrade (Sheet 1 of 4)
A31003-H8050-J100-09-7631, 09/2011
491
smu_linux_R1.fm
Task
Description
9.
Attention: For upgrades, if the OSV server Solid password is not dba,
it must be changed to dba using CMP (to ensure the solid password
is updated on both nodes in the case of a duplex system). Remember
to restore the OSV server Solid password at the end of the upgrade
procedure.
Export the data of the source system to the USB memory sticks labeled
node.cfg.primary and node.cfg.secondary. Refer to Section 9.5 on
page 601.
10.
For the external Applications server(s) monitoring the Voice Server system to
be updated;
1. If the external Applications server is deployed as a Multiple

Standard Duplex Communication Server remove the Voice
server system to be updated from the external Applications
server List of Switches. Do not add the Voice Server to the
external Applications server until instructed to do so in task 18
of this procedure.
2. If the external Applications server is monitoring this system
only, i.e. Applications servers deployed in a Standard Duplex
- Small Deployment, stop symphoniad. The symphoniad
process will be restarted as part of the external Applications
server Installation/update process.
Attention: Removing an OpenScape Voice server from a Standard
Duplex (Large or Small) UC Applications deployment will result in the
loss of UC application data (e.g.; OpenScape Users/Resources). Any
questions should be addressed to your next level of support before
proceeding.
Attention: Do not disconnect the USB sticks as indicated in the
Section 4.2 procedure; leave the USB sticks connected until directed
by the migration procedure instructions to disconnect.
11.

500.
12.

page 501.
Table 35
492
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Task
Description
13.

506.
14.

page 506.
15.

Make sure you upgrade your system to the latest patchset or
emergency patchset.
Note: Unless directed otherwise by Release Notes the target
greater.
16.
Import the data of the source system from the USB memory sticks
labeled node.cfg.primary and node.cfg.secondary to the target
system. Refer to Section 9.7 on page 602.
17.

Table 35
A31003-H8050-J100-09-7631, 09/2011
493
smu_linux_R1.fm
Task
Description
18.
Install/update the OpenScape Applications onto the external

applications server as follows:
Note: At the discretion of the user this step can be started while step
10 or 16 is in process. Do NOT execute the actions described in
Section Section 9.9, Configure the OpenScape Applications Server
for Access to the Nodes until step 17 is complete.
Upgrading the External Application Server (OffBoard).
Direct update from these Applications server levels to the V5

Applications level is supported;
V3.1R3 DVD8 to V5 Applications
V4R1 DVD3 to V5 Applications
Section 5.7, Upgrade of External Application Server (OffBoard)

Installation of this document and the following subsection for the
appropriate procedure;
Section 5.7.1, Upgrade of V3.1R3 Applications to V5

Applications, on page 392
Section 5.7.2, Upgrade of V4R1 Applications to V5

For Standard Duplex Small or Standard Duplex Large

deployments refer to the OpenScape UC Application V3,
Installation and Upgrade, Installation Guide, section titled
Updating, Upgrading and Migrating.
Note: The DLS component can also be installed on the external
OpenScape Applications server; review the DLS release notes for
sizing limitations if the DLS component is to be installed on the
external OpenScape Applications server.
19.
20.

to V5, on page 437.
Table 35
494
Configure the external OpenScape Applications server for access

to the nodes. Refer to Section 9.9, Configure the OpenScape
Applications Server for Access to the Nodes for instructions.
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Remote SW Upgrade
8.8 Remote SW Upgrade

The general concept of upgrading performs major SW release upgrades remotely
and splitting SW transfer from SW activation, which can reduce service cost
related to sending service personnel to a site to perform the upgrade.
The remote upgrade procedure uses the following features and properties:
Creation of a place on the OSV node to store the image ISO, node.cfg,
response file (for integrated systems), migration toolkit, license file, and OSV
patchsets.
Transferring the image, node.cfg, response file, license file, migration toolkit
and OpenScape Voice patchsets to the nodes via SFTP.
Elimination of the need for a real DVDs and USB sticks during major release
upgrade.
Utilization of the RSA functionality for remote access (new: include optional
RSA functionality for the low cost platform). Utilization of the Remote console
for Virtual deployment.
New boot option to execute the Upgrade Manager Functionality based on the
Migration toolkit.
Note: For remote upgrades you need to have a fully functional system as a
prerequisite.
8.8.1 SW Upgrade for Configuration Standard Duplex

SW activation is realized via the boot option which starts the on-board upgrade
manager, based on the existing Migration toolkit SW.
Note: The continuous tracing is not active after an upgrade with the Migration
toolkit. Migration toolkit will not save/import any tracing configuration.
There will be an outage of ~1 hour. If the outage is not acceptable on a Standard

Duplex system, Split Mode Upgrade can be performed.
Functional Sequence
Steps of the Upgrade
A31003-H8050-J100-09-7631, 09/2011
495
smu_linux_R1.fm
Remote SW Upgrade
1. Install migration toolkit

Install latest migration toolkit on both OSV nodes. This will also automatically
create /repository/upload directory if it does not exist (e.g. v3.1R3).
Note: All OpenScape Voice licenses which have the keyword
OpenScape_Voice in the license file name are imported. All OpenScapeUC
licenses which have the keyword OpenScape in the license file are imported.
2. SW Transfer
Upload the image, node.cfg, license file, toolkit rpm, and OpenScape
Voice patchsets (optional) to the /repository/upload on both nodes using
SFTP.
Note: Use node.cfg.primary for Node 1 and node.cfg.secondary for Node
2.
The user could also choose to transfer a single zip file containing the
above files instead. This functionality must be avoided in V3.1R3 due to
the limitation of 32 bit OS to unzip large files.
3. Upgrade Setup and Data Export phase via RSA..

4. Activation new SW via RSA
You will use RSA for remote access (must log in to each node).
You will reboot both nodes and boot off a new boot option ("Install
SoftSwitch") to begin the SW activation.
The on-board upgrade manager SW will look in a predefined directory for

SW and files necessary to perform the upgrade.
If the on-board upgrade manager SW finds all the SW and files necessary
to perform the upgrade, the new SW will be installed on the backup
partition including importing the data (via toolkit functionality).
After the upgrade is completed the new software will be active.
If for any reason the upgrade fails, the service person will be able to
fallback to the source partition. (For fallback, refer to Section 8.8.4, How
to Fallback if Failure During Installation, on page 498 and Section 8.8.5,
How to Fallback if Failure During Import, on page 499, as needed.)
8.8.2 SW Upgrade for Configuration Simplex

The steps follow the process as Standard Duplex.
496
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Remote SW Upgrade
The OpenScape Applications will be automatically installed during image

installation.
Note: Response files no longer need to be generated for integrated systems in
/repository/upload.
If a response file is found in /repository/upload that file will take precedence
over the file that is automatically generated via the Image installation.
8.8.3 How to Upgrade SW Remotely

Prerequisites:
Adequate administrative permissions.
Step by Step:
1. 1. Login to RSA for remote access (must log in to each node).
2. 2. Install latest migration toolkit on OSV (both nodes if cluster):
Enter
rpm -ivh --replacefiles --replacepkgs UNSPmigration<V#>.rpm
Example:
# rpm -ivh --replacefiles --replacepkgs UNSPmigration1.05-33.rpm
3. Place the following files under /repository/upload on node(s) via SFTP.
node.cfg.primary (1st node) / node.cfg.secondary (2nd node)
response.cfg.primary
(Optional for applications upgrade of Integrated simplex only.)
The image iso.
OSV patchsets if any.
Latest migration toolkit.
License files.
Note: All OpenScapeVoice licenses which have the keyword
OpenScape_Voice in the license file name are imported.
All OpenScapeUC licenses which have the keyword OpenScape in the
license file are imported.
4. Run upgrade8k as user root on node1.

A31003-H8050-J100-09-7631, 09/2011
497
smu_linux_R1.fm
Remote SW Upgrade
5. Reboot both nodes for software upgrade to begin. From the RSA or console
type Yes when asked to proceed with install.
Result: Upgrade proceeds without any more interaction and software
automatically activated on completion.
6. After the target OpenScape Voice server is running with the new release,
enter the following command on both nodes (or node for integrated Simplex)
of the target OpenScape Voice server:
As the root user run:
rpm -e UNSPmigration
Result: The following messages are displayed (the version of rsync may
vary):
Checking rsync package : rsync-2.6.8-53.7
Migration tools uninstalled successfully.
7. Execute RapidStat and place test calls to verify that there are no issues and
8.8.4 How to Fallback if Failure During Installation

If for any reason the upgrade fails during installation, then reboot nodes (or node
for integrated Simplex systems) and select to boot from the source partition on
each node.
Prerequisites:
Adequate administrative permissions
Step by Step:
1. Login to RSA for remote access (must log on to each node).
2. Reboot both nodes:
#reboot
Result: After reboot, the system may be in state 2 depending on the failure
point.
3. If the system has not reached state 4, in order to startup the system, run the
following command on both nodes (or node for simplex systems):
# /unisphere/srx3000/srx/bin/activate8k -done
4. Check the systems:
If both nodes work normally:

Contact your next level of support in order to investigate the failure
leading to the upgrade failure.
Restart the upgrade.
498
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Remote SW Upgrade
Under certain conditions it is possible that the installation could fail e.g.
due to a bad node.cfg. If for some reason the remote upgrade menu's
are not reset continue with step 5.
5. If for some reason (e.g. a bad node.cfg) the remote upgrade menus are not
reset then the user can run the following command in order to reset the
remote upgrade setup:
#upgrade8k -reset
6. In order to startup the system, run the following command on both nodes (or
node for simplex systems) to reset the remote upgrade setup after activation
of the fallback image is complete:
# /unisphere/srx3000/srx/bin/activate8k -reset
Note: The same option can also be used to reset a remote upgrade that has
been setup but not initated.
7. Contact your next level of support in order to investigate the failure leading to
the break of upgrading.
8.8.5 How to Fallback if Failure During Import

If for any reason the upgrade fails during import, then run the following commands
in order to activate the fallback partition (source release).
Prerequisites:
Adequate administrative permissions
Step by Step:
1. Login to RSA for remote access (must log on to each node).
2. Run the following command on both nodes (or node for simplex systems):
# /unisphere/srx3000/srx/bin/activate8k
3. Enter Yes in order to activate Fallback partition.
4. Reboot both nodes (or node for simplex systems):
#reboot
Result: After reboot, the system will be in state 2.
5. In order to startup the system, run the following command on both nodes (or
node for simplex systems):
6. If for some reason the remote upgrade menus are not reset then the user can
run the following command in order to reset the remote upgrade setup:
A31003-H8050-J100-09-7631, 09/2011
499
smu_linux_R1.fm
Customize Node 1
#upgrade8k -reset
Note: Contact your next level of support in order to investigate the failure.
8.9 Customize Node 1

8.9.1 Log In to Node 1
Note that after the target release image installation the OpenScape Voice server
userids and passwords are set to the target release configuration:
Type
User
Password
Console
root
T@R63dis
Console
srx
2GwN!gb4
SSH
sysad
1clENtk=
SSH
superad
BF0bpt@x
SFTP
cdr
MNY9$dta
The "sysad" and "superad" users can be used to access the system via console
as well as via SSH.
1. Log in to Node 1 as user sysad using one of the following:
Remote shell (ssh)
Remote access KVM (Keyboard Video Mouse) via IMM (platform

x3650T). The user-id/password for remote access to the IMM (Intel
Management Module) is reset to the default values: userid=USERID,
password=PASSW0RD (0 in PASSW0RD is zero, not the letter O).
Console
Note that the default password of user sysad is 1clENtk=.

2. After the first login, you have to change the password. The new password
should have at least 8 characters and mixed cases (for example something
like !Q2w3e4r).
500
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Customize Node 1
8.9.2 Customize Node 1

The license files are keyed to the MAC address of eth0 of the server - be sure to
apply the appropriate license file to each node. If necessary the eth0 MAC
address can be verified against the license locking_id. In this example, the
HWaddr and locking_id values in a bold font are document enhancements. On
node 1, as the root user, execute ifconfig eth0;
root@node1:[~] #1000
# ifconfig eth0
eth0
Link encap:Ethernet
HWaddr 00:0E:0C:D7:9D:F0
UP BROADCAST RUNNING SLAVE MULTICAST
MTU:1500
Metric:1

RX bytes:37244423 (35.5 Mb)
TX bytes:74285319 (70.8 Mb)
Base address:0xc400 Memory:fcd40000-fcd60000
Open the node 1 license file in an editor and verify the eth0 HWaddr matches the
license locking_id value.
<locking_mode>USER</locking_mode>
<locking_id>000E0CD79DF0</locking_id>
<alias>node1</alias>
1. On Node 1, switch to root: type su - root, press Enter, and provide the
root password.
2. Install software licenses on Node 1. Copy the licenses key file to directory /
opt/unisphere/srx3000/cla/import.
# cp <license_file> /opt/unisphere/srx3000/cla/import/
Example:
linux1:/unisphere/srx3000/srx # cp 14823_linux1.lic /opt/unisphere/srx3000/
cla/import/
3. Continue with the appropriate upgrade procedure:
Note: If sent to this section from a Chapter 9 migration procedure, return to
the Chapter 9 migration checklist.
For a standard duplex (SMU method), return to step 12 on page 479.
For a standard duplex (Toolkit method), return to step 13 in Table 35 on

page 491.
A31003-H8050-J100-09-7631, 09/2011
501
smu_linux_R1.fm
Customize Node 1
If you arrived at this section from the Installation checklist and this is a
simplex system return to Section 2.2.4, OpenScape Voice Installation
Checklist, Step 26.
If you arrived at this section from the Installation checklist and this is a
duplex system proceed to Section 8.10.2, Customize Node 2.
8.9.3 Verify Node Customization

This procedure collects the system configuration from the new release on Node
1 and compares this to the system data of the original release that was collected
in Section 8.3.1, Collect System Data on Node 1 to verify that all customization
was completed successfully.
1. Log on to Node 1 as user sysad and switch to super user.
2. Collect system configuration data as follows:
# ./smu_data_collection.sh
When prompted, type y to proceed. This collects the configuration data and
saves it in the current directory in a file named as follows:
The following output will be displayed:
502
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Customize Node 1
====================================
=
Upgrade Data Collection
=
====================================
This script will collect system information
required for an upgrade.
Do you want to proceed?
Enter 'y' to continue, n to exit: y
(enter y here)

Creating node.cfg...
Generating system configuration report...
Collecting OS Information...
Collecting Package Information...
Collecting Routing Information...
Collecting System File Information...
Collecting System Defaults Information...
Collecting System Security Configuration...
Collecting DNS Information...
Collecting Cron Information...
Collecting Inet Config Files Info...
Collecting Snort Information...
Collecting Startup scripts list...
Collecting User Information...
Collecting Group Information...
Collecting Misc Information...
Collecting Shutdown Agent Information...
Collecting SNMP Information...
Collecting SNMP trap destinations...
Collecting CLI Users...
Collecting CLI Roles...
System configuration written to cfg_linux1_R12.00.02.ALL.15_04_Feb_03_58.rpt
Building tar file...
Results stored in dc_linux1_R12.00.02.ALL.15_04_Feb_03_58.tar
====================================
=
Data collection complete
=
====================================
#
3. Run the data compare script on the original system (source) report and the
new system (target) report that was generated from the new load. The
command syntax is as follows:
smu_compare_system_reports.sh <File 1> <File 2> <Ignore File>
Where:
A31003-H8050-J100-09-7631, 09/2011
503
smu_linux_R1.fm
Customize Node 1
File 1 = System report from old software load. The

system_configuration_report.rpt was stored to an external server as a part of
Section 8.3.1, step 2. Copy the saved system_configuration_report.rpt to
/log/smu/system_configuration_report.rpt.
File 2 = System report from new software load (file generated from the
previous step in the current directory and named as follows: cfg_<nodename>_<release>_<date-time>.rpt.)
Ignore File = Contains a list of configuration differences that can be ignored
during the comparison (the file name prefix corresponds to the target
release).
For example:
# ls -ltr
The cfg_... file is listed near the bottom.
# ./smu_compare_system_reports.sh
/log/smu/system_configuration_report.rpt
cfg_linux1_R12.00.02.ALL.15_04_Feb_03_58.rpt
ignoreConfigDiffs.V4
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
Checking
504
Packages...
Groups...
Users...
Routing Information...
Hosts...
Section System_File...
Section Resolver_File...
Section Nsswitch_File...
Section NTP_Conf...
Section Inittab...
Section Syslog...
Section Netmasks...
Section Networks...
Section Protocols...
Section Services...
Section Timezone...
Section SNORT_Conf...
Section SNORTSam_Conf...
Section SPP_PACKETRATE...
RC Scripts...
Section Default_cron...
Section Default_fs...
Section Default_inetinit...
Section Default_init...
Section Default_kbd...
Section Default_login...
Section Default_mpathd...
Section Default_nfslogd...
Section Default_nss...
Section Default_passwd...
Section Default_su...
Section Default_syslogd...
Section Snare...
Section Access...
Section PAM_Login...
Section Special_Users...
Section Policy...
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Customize Node 1
Checking Default_inetd...
Checking Section CRONTAB_adm...
Checking Section CRONTAB_adm.old...
Checking Section CRONTAB_root...
Checking Section CRONTAB_root.old...
Checking Section CRONTAB_srx...
Checking Section CRONTAB_sys...
Checking Message of the day...
Checking Omni configuration...
Checking CLI Users...
Checking CLI Roles...
Checking Trap Dests...
Checking inet services...
Checking SNMP config...
Checking Section Emanate_SNMP...
Checking Section Sun_SNMP_Conf...
Checking Section Netra_SNMP_Conf...
Checking Cluster config...
Checking Section Rcsd...
Checking Section CF...
Checking Section ShutdownAgt_IPMI...
Checking Section ShutdownAgt_Die...
Checking Section ShutdownAgt_snmp...
======== COMPARE COMPLETE =======
No differences found.
4. If no differences are reported, go to step 7 on page 505.
5. If differences are found, open the /log/sysConfig_summary.rpt file and
verify the comparison result.
# less /log/sysConfig_summary.rpt
Analyze the differences to determine if any of the reported differences will
affect service. If it is determined that any of the differences will affect service,
correct these before continuing. The remaining non-service affecting changes
can be made as part of the Section 7.5, Post Upgrade Actions, on page 442.
6. For a complete list of the compared items and how to handle the differences
go to Section 8.12, Handle System Differences.
Note: The summary report may show many false positives or intended
differences, which do not need to be investigated. See Section 8.12.2 for
samples of items that can be ignored.
7. If there were no differences or all the differences were handled or ignored,
continue with the appropriate upgrade procedure:
Note: If sent to this section from a Chapter 9 migration checklist, return to the
Chapter 9 migration checklist.
For an integrated simplex, return to step 18 in Table 34 on page 468.
For a standard duplex (SMU method), return to step 30 on page 488.
A31003-H8050-J100-09-7631, 09/2011
505
smu_linux_R1.fm
Customize Node 2

page 491.
8.10 Customize Node 2

8.10.1 Log In to Node 2
Note that after the target release image installation the OpenScape Voice server
userids and passwords are set to the target release configuration:
Type
User
Password
Console
root
T@R63dis
Console
srx
2GwN!gb4
SSH
sysad
1clENtk=
SSH
superad
BF0bpt@x
SFTP
cdr
MNY9$dta
The "sysad" and "superad" users can be used to access the system via console
as well as via SSH.
1. Log in to Node 2 as user sysad using one of the following:
Remote shell (ssh)
Remote access KVM (Keyboard Video Mouse) via IMM (platform

x3650T). The user-id/password for remote access to the IMM (Intel
Management Module) is reset to the default values: userid=USERID,
password=PASSW0RD (0 in PASSW0RD is zero, not the letter O).
Console
The default password for user sysad is 1clENtk=.

2. After the first login, you have to change the password. The new password
should have at least 8 characters and mixed cases (for example something
like !Q2w3e4r).
8.10.2 Customize Node 2

The license files are keyed to the MAC address of eth0 of the server - be sure to
apply the appropriate license file to each node. If necessary the eth0 MAC
address can be verified against the license locking_id. In this example, the
HWaddr and locking_id values in a bold font are document enhancements. On
node 2, as the root user, execute ifconfig eth0;
506
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Customize Node 2
root@node2:[~] #377
# ifconfig eth0
eth0
Link encap:Ethernet
HWaddr 00:0E:0C:D7:93:90
UP BROADCAST RUNNING SLAVE MULTICAST
MTU:1500
Metric:1

RX bytes:31039836 (29.6 Mb)
TX bytes:32159786 (30.6 Mb)
Base address:0xc800 Memory:fcd80000-fcda0000
Open the node 2 license file in an editor and verify the eth0 HWaddr matches the
license locking_id value.
<locking_mode>USER</locking_mode>
<locking_id>000E0CD79390</locking_id>
<alias>node2</alias>
1. On Node 2, switch to root: type su - root, press Enter, and provide the
root password.
2. Install software licenses on Node 2. Copy the licenses key file to directory
/opt/unisphere/srx3000/cla/import.
# cp <license_file> /opt/unisphere/srx3000/cla/import/
Example: linux2:/unisphere/srx3000/srx # cp 14824_linux2.lic /opt/unisphere/
srx3000/cla/import/
3. Continue with the appropriate upgrade procedure:
Note: If sent to this section from a Chapter 9 migration checklist, return to
Chapter 9 migration checklist.
For a standard duplex, return to step 26 on page 486.

page 491.
If you arrived at this section from the Installation checklist (via

Section 8.9.2) return to the Section 2.2.4, OpenScape Voice Installation
Checklist, Step 26.
A31003-H8050-J100-09-7631, 09/2011
507
smu_linux_R1.fm
Fallback Procedures
8.11 Fallback Procedures

8.11.1 Fallback Procedure 1
Note: Copy the files from the top level directory of the USB memory stick to
another location (for example, FTP server or backup server/device) for future
reference or diagnostic purposes. Depending on the OpenScape Voice system
configuration and the step of the SMU process, the files on the stick can include
the following:
node.cfg.primary and secondarywritten before the SMU begins
response.cfg.primary and secondarywritten before the SMU begins
install.logwritten during the image install process
current.hwinfowritten during the image install process
Ensure the file naming convention for the files install.log and current.hwinfo
easily identifies the files as a Node 1 or Node 2 file. An example follows;
File install.log could be named nX_install.log where X=1 for node 1 and X=2 for
node 2.
File current.hwinfo could be named nX_current.hwinfo where X=1 for node 1
and X=2 for node 2.
This fallback procedure is associated with fallback point 1.

The status of the cluster is as follows:
All call processing is on Node 2.
1. If an error is reported or it is determined that the system is not fully operational

on Node 2, return to the CSOCSC menu on Node 2.
2. Select option 2 from the CSOCSC menu and press y when prompted.
3. Press Enter when prompted to Press ENTER key to continue.
---------------------------------------------------------------------------Split Mode Installation Menu
-o(STATE=STOP_REMOTE_NODE_OK)
---------------------------------------------------------------------------RTP & DB have been stopped successfully on NODE 1.
(1)
(2)
508
- CONTINUE INSTALLATION: Shutdown NODE 1 & Split cluster

- FALLBACK: Restart RTP & DB on NODE 1
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures
(3)
(99) - EXIT
-> 2
(enter 2 here)
This action will attempt to restart RTP & DB on the remote node.
Are you sure you want
2007.08.13-15:02:08 cluster x-connect ...
2007.08.13-15:02:08 2007.08.13-15:02:08 2007.08.13-15:02:08 srxctrl 0 4>...
2007.08.13-15:06:36 2007.08.13-15:06:36 -----<Press ENTER key
to execute this action? (y/n):y

(enter y here)
linux2 - Checking if partner node is visible via
linux2 - Success - Partner node visible.
linux2 - Starting RTP & DB on partner node...
linux2 - Executing </unisphere/srx3000/srx/startup/
linux2 - Success!
linux2 - Success: Partner node RTP & DB started.
to continue>-----
4. Upon completion of this step, both nodes should be at run level 4. Select
option 99 to exit.
-o(STATE=STARTUP)
---------------------------------------------------------------------------IMPORTANT NOTE: This procedure may lead to a total system outage if not
executed properly. If not sure on how to execute a split
mode upgrade or how to recover the system, please stop now
and exit.
To initiate the Split Mode Upgrade (SMU), select option '(1) START INSTALLATION'
below.
(1)
(2)

(99) - EXIT
-> 99
(enter 99 here)
5. Verify that Node 1 is fully operational, e.g., make sure that call processing and
other processes are running (srxqry).
6. After verifying that Node 1 is fully operational, data collection steps are
required. From Node 1, as user root, run the following command to collect
node 1 system status and log files. Answer y (yes) to any question(s). An
example follows:
#/unisphere/srx3000/srx/bin/RapidStat -t -c
!!! Data collection can affect traffic during peak
usage!!!
Continue anyway? [y | n]: y
***************************************************
RapidStat V7.014
***************************************************
A31003-H8050-J100-09-7631, 09/2011
509
smu_linux_R1.fm
Fallback Procedures
RapidStat Initializing, please wait: Initialization

Complete.
Collecting Data: From srxl91 Please Wait...
The RapidStat tool will list the data collection steps in their order of execution.
When RapidStat has completed, a message similar to the following is
displayed:
Compressing Report File for transport:

/log/srxl91_report.tar...Finished!
Finished, please submit the file /log/srxl91_report.tar.gz
Note: Note: If an error is given when executing this step tar the files in the
/log directory. Name the tar file so that it is easily identifiable as a file from
Node 1 (n1_log.tar). Transfer the file to another server or media for later
analysis. The best practice would be to utilize the same storage employed for
the USB memory stick files. For this error case skip step 7 and proceed to
step 8.
7.
Copy the indicated <node_name>_report.tar.gz file to another location

(for example, FTP server or backup server/device) for future reference or
diagnostic purposes. The best practice would be to utilize the same storage
employed for the USB memory stick files. Ensure the file naming convention
easily identifies it as a Node 1 file.
8. Node 2 data collection. As user root, run the following command on Node 2
to collect system status and log files. Answer y (yes) to any question(s). An
example follows:
!!! Data collection can affect traffic during peak usage!!!
***************************************************
RapidStat V7.014
***************************************************
RapidStat Initializing, please wait: Initialization Complete.
510
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures
displayed:
Compressing Report File for transport: /log/

srxl91_report.tar...Finished!
Note: If an error is given when executing this step tar the files in the /log
directory. Name the tar file so that it is easily identifiable as a file from Node
2 (n2_log.tar). Transfer the file to another server or media for later analysis.
The best practice would be to utilize the same storage employed for the USB
memory stick files. For this error case skip step 9 and proceed to step 10.
9. Copy the indicated <node_name>_report.tar.gz file to another location
10. This concludes the data Collection. The collected data and the following
information should be provided to your next level of support.
User provided input;
Which document was used to perform the SMU (customer document

title and number).
The exact step where the problem occurred (with reference to the
customer doc).
Terminal capture of the CLI output (if possible).
The source and target release, along with the source and target
release's patchset level

the following:
A31003-H8050-J100-09-7631, 09/2011
511
smu_linux_R1.fm
Fallback Procedures

node 2.
and X=2 for node 2.

Node 1 is shut down and the 'boot net' procedure has not been started.
Cluster interconnections are blocked (cluster is split).
1. Verify that Node 1 is at the system prompt.

2. Return to the CSOCSC menu on Node 2.
3. Select option 2 from the CSOCSC menu and press y when prompted.
4. Press Enter when prompted to Press ENTER key to continue.
-o(STATE=SPLIT_OK)
---------------------------------------------------------------------------The cluster interconnect has been successfully closed and NODE 1 is shutdown
and ready to be installed with the target SW release.
After finishing NODE 1 installation and to continue the SMU procedure,
please select option '(1) CONTINUE INSTALLATION' below.
(1) - CONTINUE INSTALLATION: Mark NODE 1 installation completed.
(2) - FALLBACK: Reopen cluster interconnect (NODE 1 must be halted
first)
(3) - GET STATUS: Local only
(99) - EXIT
-> 2
(enter 2 here)
This action will reopen the cluster interconnect and will enable NODE 1 to
join the cluster AFTER being restored.
Before proceeding with this action please make sure NODE 1 is halted
Are you sure you want
2007.08.13-15:18:29 2007.08.13-15:18:30 -----<Press ENTER key
512
to execute this action? (y/n):y

(enter y here)
linux2 - Executing <./smu_split_cluster.sh merge>...
linux2 - Success!
to continue>-----
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures
5. Select option 99 to exit.

-o(STATE=STARTUP)
and exit.
To initiate the Split Mode Upgrade (SMU), select option '(1) START INSTALLATION'
below.
(1)
(2)

(99) - EXIT
-> 99
(enter 99 here)
6. Cycle the power on Node 1 or enter 'boot' at the system prompt.

# boot
7. Verify that Node 1 boots, joins the cluster and is fully operational, e.g, make
sure that call processing and other processes are running (srxqry).
Srxctrl is run automatically and both nodes are at run level 4.
8. After verifying that Node 1 is fully operational, data collection steps are
required. From Node 1, as user root, run the following command to collect
node 1 system status and log files. Answer y (yes) to any question(s). An
example follows:
***************************************************
RapidStat V7.014
***************************************************
displayed:
A31003-H8050-J100-09-7631, 09/2011
513
smu_linux_R1.fm
Fallback Procedures

memory stick files.. For this error case skip step 9 and proceed to step 10.
example follows:
***************************************************
RapidStat V7.014
***************************************************
displayed:
514
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures

memory stick files. For this error case skip step 11 and proceed to step 12.

title and number).
customer doc).
A31003-H8050-J100-09-7631, 09/2011
515
smu_linux_R1.fm
Fallback Procedures

the following:
node 2.
and X=2 for node 2.
This fallback procedure is associated with fallback points 3 and 4.

Node 1 has been installed with the new release.
Cluster interconnections are blocked.
1. As user root, run the following command on Node 1 to collect system status
and log files and answer y (yes) to any question(s):
***************************************************
RapidStat V7.014
***************************************************
516
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures
displayed:
Compressing Report File for transport: /log/srxl91_report.tar...Finished!
memory stick files. In this case, proceed to step 3 to continue the fallback
process.
A31003-H8050-J100-09-7631, 09/2011
517
smu_linux_R1.fm
Fallback Procedures
3. From node 2, select option 2 from the CSOCSC menu and press y when
prompted.
-o(STATE=PREPARE_SWITCHOVER)
---------------------------------------------------------------------------All applications have started on Node 1, but Node 1 is still isolated.
To continue the SMU procedure, please select option '(1) CONTINUE INSTALLATION' below.
(1)
(2)
(3)
- CONTINUE INSTALLATION: Swing call processing from NODE 2 to NODE1.

- FALLBACK: Restore original release of node1
(99) - EXIT
-> 2
(enter 2 here)
This action will reopen the cluster interconnect and will enable NODE 1 to
join the cluster AFTER being restored.
Before proceeding with this action please make sure NODE 1 is halted
(enter y here)
2007.08.14-09:33:02 - linux2 - Activating the inactive partition set on
Remote node...
2007.08.14-09:33:52 - linux2 - Executing <./smu_activate_other_side.sh> on
Partner node...
2007.08.14-09:33:53 - linux2 - Success!
:
:
:
:
:
:
:
:
2007.08.14-09:33:53 - linux2 - Success!
2007.08.14-09:33:53 - linux2 - Success! Cluster x-connect merged.
-o(STATE=STARTUP)
---------------------------------------------------------------------------IMPORTANT NOTE: This procedure may lead to a total system outage if not executed properly. If not sure on how to execute a split mode upgrade or how to
recover the system, please stop now and exit.
To initiate the
below.
(1) (2) (3) -
Split Mode Upgrade (SMU), select option '(1) START UPGRADE'

START UPGRADE
FALLBACK: Perform FALLBACK
GET RTP STATUS: Local only
(99) - EXIT
->
Attention: There are customers who may employ the SMU for a V5 to V5
upgrade. For V5 the Fallback logic has been enhanced so that a Fallback
from a V5 target to a V5 source release is automatic. When the Fallback from
a V5 target to a V5 source release is executed it is only necessary to
monitor node 1 to ensure the source release software load is selected
automatically from the grub menu during the reboot executed during the
Fallback process. After node 1 completes rebooting the server should be at
state 2 (which can be verified with the srxqry command). Users whose SMU
source release was V5 should proceed to step 5 of this procedure after
518
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures
node 1 successfully reboots on the V5 source release and reaches state

2.
The aforementioned automation is only available for SMUs from a V5 source
release. The automation does not apply if the source release is V4R1 or
V3.1R3. If your SMU source release was V3.1R3 or V4R1 proceed to step
4.
4. Step 4 is intended for users executing a Fallback from a V5 target to a
V3.1R3 or V4R1 source release. For this Fallback scenario node 1 must be
manually booted with the load of the source release.
Attention: Users whose SMU source release was V5 should skip step 4 and
proceed to step 5 (after node 1 successfully reboots on the V5 source release
and reaches state 2).
For an integrated duplex system, start at step 4a on page 519.
For a standard duplex system, start at step 4b on page 519.
Note: The following commands are to be executed as user root.
a) For an integrated duplex system only, stop Symphonia on Node 1 with the
command:
root@fsc301:[~] #1000
b) From Node 1, configure Node 1 to state 2 with the command:
root@fsc301:[~] #910
Node 1 should be at state 2 when the system displays a message similar
to this:
--- srxctrl ended on Wed May 27 13:52:27 2009 --c) Verify the status of Node 1 with the command:
root@fsc301:[~] #911
It is expected that Node 1 will be at state 2 at this time.
d) From the Node 1 console, reboot Node 1 with the command:
root@fsc301:[~] #912
# reboot
e) Monitor the console output. When presented with the option for which
load to use for the reboot be sure to select the load of the source release.
Node 1 will come up to run level 2.
A31003-H8050-J100-09-7631, 09/2011
519
smu_linux_R1.fm
Fallback Procedures
5. From node 1 as user root, bring node 1 to run level 4 with the following
command:
6. When the single node restore is completed, both nodes should be at run level
4. Verify that node 1 boots, joins the cluster and is fully operational, e.g, make
sure that call processing and other processes are running (srxqry).
7. From node 2, select option 99 from the CSOCSC to exit.
-o(STATE=STARTUP)
and exit.
(1)
(2)
(3)
- START UPGRADE
(99) - EXIT
-> 99
(enter 99 here).
8. After it is verified that both nodes are at run level 4 and fully operational, data
collection on Node 2 is required. As user root, run the following command on
Node 2 to collect system status and log files. Answer y (yes) to any
question(s). An example follows:
***************************************************
RapidStat V7.014
***************************************************
displayed:
520
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures

memory stick files. In this case, proceed to step 10.

title and number).
customer doc).

the following:
A31003-H8050-J100-09-7631, 09/2011
521
smu_linux_R1.fm
Fallback Procedures
node 2.
and X=2 for node 2.

Both nodes are at run level 4.
Node 1 has the new release installed.
Node 2 is running on the old software.
The cluster interconnections are blocked (cluster is split).
Traffic has been switched from Node 2 to Node 1.
1. Switch traffic from Node 1 to Node 2 by selecting option 2 in the CSOCSC

and press y when prompted.
-o(STATE=SWITCHOVER_OK)
---------------------------------------------------------------------------NODE 2 is isolated and all applications on NODE 1 should now be operational.
(1)
- CONTINUE INSTALLATION: Stop RTP on NODE 2 and shut down NODE

2.
(2) - SWITCHBACK: Transfer call processing from NODE 1 to NODE 2
(3) - GET STATUS: Local & Remote
(99) - EXIT
-> 2
(enter 2 here)
This action will disable all interfaces on NODE 1 and will enable all
interfaces on NODE 2. It is expected that the call processing is transferred
back to NODE 2.
(enter y here)
2007.08.14-16:57:29 - linux2 - Executing <./smu_SS7_gatectl.sh open>...
2007.08.14-16:57:30 - linux2 - Success!
2007.08.14-16:57:31 - linux2 - Executing <./smu_SS7_gatectl.sh close> on
partner node...
2007.08.14-16:57:38 - linux2 - Success!
2007.08.14-16:57:38 - linux2 - Executing <./smu_gate_ctl.sh open>...
2007.08.14-16:57:50 - linux2 - Success!
2007.08.14-16:57:52 - linux2 - Executing <./smu_gate_ctl.sh close> on
partner node...
2007.08.14-16:58:06 - linux2 - Success!
2007.08.14-16:58:15 - linux2 Sending SWO_ENABLE_UPDATE to AswoMgr2...
2007.08.14-16:58:17 - linux2 - Success! SWO_ENABLE_UPDATE sent to
AswoMgr2...
2. Run all steps of Fallback Procedure 3.
522
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures

the following:
node 2.
and X=2 for node 2.

Node 1 is at run level 4 and handling the traffic on the new software.
Node 2 is loaded with the new software.
The cluster interconnections are blocked (cluster is split.)
Fallback to the original software load on both nodes as follows:

1. Select option 2 in the CSOCSC menu on node 2 and press y when
prompted.
(1)
(2)
(3)
(99)
-> 2
CONTINUE INSTALLATION
FALLBACK: Perform FALLBACK
GET STATUS: Local & Remote
EXIT
(enter 2 here)
This action will perform fallback

Are you sure? (y/n):y
2008.11.06-12:28:45
local node...
2008.11.06-12:28:45
2008.11.06-12:28:46
2008.11.06-12:28:46
on local node.
2008.11.06-12:28:46
remote node...
(enter y here)
- linux2 - Activating the inactive partition set on

- linux2 - Executing <.smu_activate_other_side.sh>...
- linux2 - Success!
- linux2 - Success! Activated the inactive partition set
- linux2 - Activating the inactive partition set on
A31003-H8050-J100-09-7631, 09/2011
523
smu_linux_R1.fm
Fallback Procedures
2008.11.06-12:28:46
partner node...
2008.11.06-12:28:53
2008.11.06-12:28:53
on remote node.
2008.11.06-12:28:53
mergefallback>...
2008.11.06-12:28:54
2008.11.06-12:28:54
- linux2 - Executing <.smu_activate_other_side.sh> on

- linux2 - Success!
- linux2 - Success! Activated the inactive partition set
- linux2 - Executing <.smu_split_cluster.sh
- linux2 - Success!
- linux2 - Success! Cluster x-connect merged.
2. Upon completion of this step, select option 99 in the CSOCSC menu to exit
the SMU.
---------------------------------------------------------------------------Split Mode Installation Menu -o- (STATE=STARTUP)
and exit.
INSTALLATION'
below.
(1) - START INSTALLATION: Stop RTP & DB on NODE 1
(2) - GET RTP STATUS: Local only
(99) - EXIT
-> 99 (enter 99 here)
#
example follows:
***************************************************
RapidStat V7.014
***************************************************
displayed:
524
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures

memory stick files. In this error case, proceed to step 4.
4. Copy the indicated <node_name>_report.tar.gz file to another location (for
example, FTP server or backup server/device) for future reference or
5. For this scenario Node 2 will have target and source release data collection
steps. This is the Node 2 target release data collection step. As user root, run
the following command on Node 2 to collect system status and log files.
Answer y (yes) to any question(s). An example follows:
***************************************************
RapidStat V7.014
***************************************************
displayed:
2 (n2_target_log.tar). Transfer the file to another server or media for later
analysis. The best practice would be to utilize the same storage employed for
the USB memory stick files. On the remote storage device ensure the word
target is in the file name (i.e. n2_target_log.tar).The file is named in order to
differentiate this data from the source release data collection file. In this case,
proceed to step 6.
A31003-H8050-J100-09-7631, 09/2011
525
smu_linux_R1.fm
Fallback Procedures
6. Copy the indicated <node_name>_report.tar.gz file to another location (for

example, FTP server or backup server/device) for future reference or
employed for the USB memory stick files. On the remote storage device
rename the file target_<node_name>_report.tar.gz. The file is renamed to
differentiate this data from the source release data collection file. Ensure the
file naming convention easily identifies it as a Node 2 file.
7. Both nodes must be configured to state 2 prior to rebooting. From Node 1,
configure the nodes (or node for simplex systems) to state 2 with the
command:
Duplex systems:
root@fsc301:[~] #910
Simplex systems;
For integrated systems stop Symphonia and then configure the node to
state 2.
Stop Symphonia:
root@fsc301:[~] #1000
Configure the simplex system to state 2:

root@fsc301:[~] #910
--- srxctrl ended on Wed May 27 13:52:27 2009 --8. Verify the status of the nodes (or node for simplex systems) with the
command:
root@fsc301:[~] #911
It is expected that nodes (or node for simplex systems) will be at state 2 at
this time.
9. As user root enter the following command on both nodes (or node for simplex
systems):
Type Yes in order to activate Fallback partition.
10. After the Fallback partition is activated, reboot the nodes (or node for simplex
systems) with the command;
# reboot
526
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Fallback Procedures
11. Both nodes (or node for simplex systems) come up automatically on the
original load to run level 2. Log in as user root on each node and enter on
each node (or node for simplex systems) the following command:
This completes the activation of the original load on both nodes and the
system returns to the initial state (before starting the upgrade). The system
comes up to run level 4 and the cluster is interconnected.
Attention: If the fallback was for a standard duplex configuration (with an
external applications server), then fallback may have to be performed on the
external applications server. Refer to the appropriate Fallback instruction for
your deployment;
- For Multiple Communications Server Admin deployments refer section
Fallback of an External Application Server (OffBoard) Installation of this
document.
- For Standard Duplex Small or Standard Duplex Large deployments refer to
the OpenScape UC Application V3, Installation and Upgrade, Installation
8.11.6 General Hard Fallback

the following:
node 2.
and X=2 for node 2.
A31003-H8050-J100-09-7631, 09/2011
527
smu_linux_R1.fm
Fallback Procedures
When a node is hung due to a software error and the fallback procedure specified
in the associated section did not work, this hard fallback procedure can be used
to fallback to a working system. In other words, this procedure is to be used when
the specified fallback procedure for that section fails or a fallback procedure was
not specified.
1. Power cycle the node using the hung nodes power button.
2. Wait for the node to come up. If the cluster interconnect test fails, type GO
and let the node continue its processing for coming up.
3. Login as root user.
4. Start CSOCSC menu. In a cluster system, start the menu only if it is not
already running on the other node:
# ./csocsc
5. Follow the fallback procedure that corresponds to the current SMU state/step
as described in this document.
8.11.7 Fallback for Toolkit Upgrades/Migrations

For integrated systems follow steps 1 through 6.
For a standard duplex system follow steps 2 through 6.
1. For integrated systems stop Symphonia with this command:
root@fsc301:[~] #1000
2. From Node 1, configure the nodes (or node for simplex systems) to state 2
with the command:
Duplex systems:
root@fsc301:[~] #910
Simplex systems;
root@fsc301:[~] #910
--- srxctrl ended on Wed May 27 13:52:27 2009 ---
528
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Handle System Differences
3. Verify the status of the nodes (or node for simplex systems) with the
command:
root@fsc301:[~] #911
It is expected that nodes (or node for simplex systems) will be at state 2 at
this time.
4. As user root enter the following command on both nodes (or node for simplex
systems):
Type Yes in order to activate Fallback partition
5. After the Fallback partition is activated, reboot the nodes (or node for simplex
systems) with the command;
# reboot
6. Both nodes (or node for simplex systems) come up automatically on the
original load to run level 2. Log in as user root on each node and enter on
each node (or node for simplex systems) the following command:
This completes the activation of the original load on both nodes and the
system returns to the initial state (before starting the upgrade). The system
comes up to run level 4 and the cluster is interconnected.
Attention: If the fallback was for a standard duplex configuration (with an
external applications server), then fallback may have to be performed on the
external applications server. Refer to the appropriate Fallback instruction for your
deployment;
- For Multiple Communications Server Admin deployments refer section
Fallback of an External Application Server (OffBoard) Installation of this
document.
- For Standard Duplex Small or Standard Duplex Large deployments refer to
the OpenScape UC Application V3, Installation and Upgrade, Installation
8.12 Handle System Differences

Below is the list of items that are compared between the new and old releases.
Table 36 gives instructions on how to resolve the mismatches.
A31003-H8050-J100-09-7631, 09/2011
529
smu_linux_R1.fm
Section
Resolving Differences
Package
Install the required packages

If the source of any packages in the list cannot be
identified, contact your next level of support for
assistance.
Groups
Missing groups can be created using the 'groupadd'

command. When creating groups, ensure that the new
group-id matches the group-id identified in the system
configuration report.
If missing users are causing the group difference, create
the users as described for User Accounts, and then add
them to the appropriate group.
Note: Only common linux users and groups (defined in
both cluster nodes) are maintained during split mode
upgrade.
User Accounts
Missing users can be re-created with the 'useradd'

command.
A default password should be assigned to the user, along
with the option to force change of the password on first
login.
Note: Only common linux users and groups (defined in
both cluster nodes) are maintained during split mode
upgrade.
Routing Information For each entry in the report, check the destination, mask
and gateway columns to determine the purpose of the

route entry. Based on this information, determine whether
the route is required after the upgrade.
For each such route, contact the operator to determine
how the route is currently being added to the 'target'
cluster. This is usually done using a special startup
script or by modifying an existing script.
Table 36
530
Resolving System Differences (Sheet 1 of 8)
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Section
Static Route Script
Differences in this section indicate that the script /etc/

init.d/static_route is different on the new and the
old release.
This would normally be caused by static route entries that
have been manually added to the script file in the old
cluster after initial installation. Carry over to the new
release.
Hosts File
For each identified difference, determine the source of the

change and whether it must be carried over through the
upgrade. If a change is required, modify the /etc/
hosts files.
The following rules must be followed when adding entries
to the /etc/hosts file to ensure that the file remains in
a consistent format:
Aliases for existing IP addresses must be appended on the
same line.
All IP address assignments for the same hostname must be
grouped together.
Duplicate entries in the hosts file must be avoided.
System File
Differences in this section indicate that entries in the /

etc/system file are different.
Resolver File

upgrade.
If a change is required, modify the /etc/resolv.conf
files.
Nsswitch File

upgrade.
If a change is required, modify the /etc/
nsswitch.conf file.
NTP Conf File

etc/ntp.conf.cluster file on the new release are
different than those in the old release.
upgrade.
Table 36
A31003-H8050-J100-09-7631, 09/2011
531
smu_linux_R1.fm
Section
Inittab

etc/inittab file are different on the new and old
releases.
For each missing entry on the upgraded node, determine
whether it is already covered by a missing system
package.
For entries that cannot be mapped to a missing package,
contact the operator for information on the purpose of the
inittab entry.
If an entry is related to a HiPath component, contact your
next level of support for further analysis.
etc/syslog.conf file are different on the new and old
releases.
Syslog
After making any changes to syslog.conf, restart the

syslogd process (cd to /etc/init.d and run./
syslog restart).
Netmasks/Networks
The node.cfg generated for installation should have

created an identical network configuration.
Examine the summary report file
/log/sysConfig_summary.rpt for details.
Contact your next level of support for further analysis.
Protocols
Differences in this section indicate that the /etc/

protocols files are different on the old release node
and the upgraded node.
Protocol configuration should not differ between new and
old releases.
/log/sysConfig_summary.rpt for details.
Contact your next level of support for further analysis.
Table 36
532
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Section
Services

services files are different on the new and old releases.
/log/sysConfig_summary.rpt.rpt for details on
the services differences. For each entry determine
whether the service is used by a missing package.
If the service cannot be mapped to a package, contact
your next level of support for further analysis.
Timezone

sysconfig/clock file is different on the new and old
releases.
Use the yast2 utility to change the time zone.
Snort
Differences in these sections indicate that the /etc/

snort.conf, /etc/snortsam.conf and /etc/
spp_packetrate.conf files are different on the new
and old releases.
For each entry, determine whether the change is still
relevant and modify the corresponding file.
After making any changes, restart the 'Snort' package:
cd /etc/init.d/rc3.d
./S99IDS restart
Startup Script
Differences in this section indicate that the list of startup

scripts is different on the new and old releases. This is
normally caused by custom startup scripts in the /etc/
init.d/rc2.d and /etc/init.d/rc3.d
directories, or by missing customer specific packages that
include startup scripts.
For each identified script, determine the purpose of the
script and whether it belongs to a missing package.
If the script does not belong to a package, determine the
purpose of the script and whether it needs to be preserved
across the upgrade.
Note that static route entries are often implemented as
custom scripts and must be carried over.
Table 36
A31003-H8050-J100-09-7631, 09/2011
533
smu_linux_R1.fm
Section
Inetd Conf file

etc/xinetd.conf file are different on the new and old
release.
upgrade.
If a change is required, use the yast2 utility to modify.
Default
Configuration
Differences in these sections indicate that the

corresponding file in the /etc/default directory is
different between the new and old releases.
Reboot node after changes.
Security
Configuration
Differences in these sections indicate that the

corresponding file in the /etc/security directory is
different between the new and old releases.
The Access section will show the additional hostnames
on the 'root' and 'srx' access lines due to differences in the
setup of 'root' access in the new release. These can be
safely ignored.
The new entries are highlighted in the example below:
:root srx:ALL EXCEPT <node1> <node2>
console tty1 tty2 tty3 tty4 tty5 tty6
clusternode1-priv clusternode2-priv
If changes are identified in the Special Users section,
update the file /etc/secure/pamSpecialUserAuth
so that the new release node includes all users from the
old release's node.
After all changes are made, reboot the node.
Table 36
534
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Section
Cron
Differences in these sections indicate that the 'crontab'

entries do not match between the new and old releases.
For each reported entry, determine whether the cron job
needs to be carried over across the upgrade. Eliminate
those cron jobs that are associated with missing
packages.
Add required crontab entries to the upgraded node using
the 'crontab' command.
Message of the Day
Differences in these sections indicate that the /etc/

motd or /etc/issue files are different between the
new and old releases.
For each file that is different, obtain a copy from the old
release and copy to the upgraded node.
CLI Users
Don't care about the differences.

Note that the RTP CLI user 'survop' has been deprecated
in Release 12.
CLI Roles
Don't care about the differences.
Trap Destinations
For each identified trap destination, use the Assistant to

create a corresponding trap destination.
Note that entries that show no trap destination port
number will default to a port number of 162. Entries for
which this is the only difference can be safely ignored.
SNMP configuration For Emanate SNMP Agent configuration differences:

Login to Node 1 as super user.
Add or remove the necessary entries from the Emanate
SNMP configuration file (/etc/snmp/agt/snmpd.cnf)
Restart the SNMP daemon to ensure that the changes take
effect:
cd /etc/init.d
./snmpdm stop
./snmpdm start
ps -ef | grep snmpdm
Verify that the SNMP daemon 'snmpdm' is running according
to the output of the ps' command
Table 36
A31003-H8050-J100-09-7631, 09/2011
535
smu_linux_R1.fm
Section
Rcsd
Differences in this section indicate that the file /etc/

opt/SMAW/SMAWsf/rcsd.cfg is different between the
new and the old releases.
Determine whether the values from the old release should
be carried over. If this is the case, edit the file above.
Then restart the Shutdown facility SMAWsf as follows: (as
super user)
cd /etc/init.d
./SMAWsf stop
./SMAWsf start
Cluster Foundation
(CF)
Table 36
536
Differences in this section indicate that the file

/etc/default/cluster.config is different between the
new and old releases. Note that the default values of R11.0 is 25
sec., R12 is 10 sec. (recommendation: use default). This is the
time out value used by the prime cluster for monitoring the node
interconnection.
Determine whether the values from the old release should be
carried over. If this is the case, edit the file above.
Then load the new value as follows: (as super user)
cfset -r
cfset -a
Verify that the new value is displayed.
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Section
ShutdownAgent
SA_ipmi (x3650T
only)

opt/SMAW/SMAWsf/SA_ipmi.cfg is different between
the new and the old releases.
be carried over. If this is the case, edit the SA_ipmi.cfg file
on each node.
Then load the new value as follows: (as super user).
Get the userid and password from the file above (on the
line that begins with the name of this node)
Example:
If the file above contains two lines:
intel3 10.77.234.2:USERID2:PASSW0RD3 cycle
intel4 10.77.234.3:USERID2:PASSW0RD3 cycle
and this node is intel3, the userid is USERID2 and the
password is PASSW0RD
cd /usr/local/syscfg
./syscfg /user 2 <userid> <password>
Make sure that the following messages are displayed:

successfully completed.
Restart the Shutdown facility SMAWsf as follows:
cd /etc/init.d
./SMAWsf stop
./SMAWsf start
ShutdownAgent
SA_down

opt/SMAW/SMAWsf/SA_down.cfg is different between
the new and the old releases.
be carried over. If this is the case, edit the file above.
Then restart the Shutdown Facility SMAWsf as follows:
cd /etc/init.d
./SMAWsf stop
./SMAWsf start
Table 36
A31003-H8050-J100-09-7631, 09/2011
537
smu_linux_R1.fm
8.12.1 Summary Report Items that can be Ignored

The /log/sysConfig_summary.rpt items that can be ignored are as follows:
System_Packages Section
Ignore if the following packages are missing:
DirServerExt, ITDServer IBM, ibmusbasm, panicsel, IBMJava5JRE
Also ignore any issues related to SuSE , openSuSE and openser packages.
Groups Section
Ignore Added/Modified users in cfg_templateV4.rpt:
trusted
superad,intad,sysad,sysop1,sysop2,srx
Ignore Missing/Modified groups in cfg_templateV4.rpt:

lp mail news uucp dialout audio video games modem diradmin
dirsuper
Users Section
Ignore Missing/Modified users in cfg_templateV4.rpt:
news
Routing Section
Ignore Added/Modified routes in cfg_templateV4.rpt:
Destination
10.77.183.96
10.77.183.32
10.77.183.0
0.0.0.0
Mask
0.0.0.0
0.0.0.0
0.0.0.0
10.77.183.1
Gateway
255.255.255.224
255.255.255.224
255.255.255.224
0.0.0.0
Flags
U
U
U
UG
Ignore Result: Missing/Modified routes in cfg_templateV4.rpt:

Destination
10.1.2.2
10.1.1.2
10.0.0.0
10.0.1.0
10.0.2.0
10.0.3.0
165.218.0.0
0.0.0.0
Mask
0.0.0.0
0.0.0.0
10.0.1.16
0.0.0.0
0.0.0.0
0.0.0.0
10.0.2.1
10.0.1.1
Gateway
255.255.255.255
255.255.255.255
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.0.0
0.0.0.0
Flags
UH
UH
UG
U
U
U
UG
UG
Hosts_File Section
Ignore the following:
Missing hosts in cfg_templateV4.rpt if the IPs are found in the
node.cfg.
538
Resolver_File Section
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
Ignore Missing/Modified entries in cfg_templateV4.rpt if the IPs are

found in the node.cfg.
Ignore the following Added/Modified entries in cfg_templateV4.rpt:
nameserver 10.77.75.19
nameserver 10.77.0.13
domain lab.bocc.icn.siemens.com
search lab.bocc.icn.siemens.com bocc.icn.siemens.com
dhcp.bocc.icn.siemens.com
NTP_Conf Section
Ignore Missing/Modified entries in cfg_templateV4.rpt if the IPs are
found in the node.cfg.
Ignore the following Added/Modified entries in cfg_templateV4.rpt:
server 10.77.0.11
server 10.77.0.12
Netmasks Section
Ignore all mismatches
Timezone Section
SNORT_Conf Section
SNORTSam_Conf Section
SPP_PACKETRATE Section
Ignore all mismatches such as Section SPP_PACKETRATE not present in
cfg_templateV4.rpt.
RC2_Scripts Section, RC3_Scripts Section

Ignore all mismatches of:
dirsnmpd, TWGserver, ibmasm
Additionally, ignore mismatches caused by the S#, for example, ignore
mismatch of
S15 snmpd vs. S14 snmpd
Default_nss Section
Ignore all mismatches, such as
Section Default_nss not present in
cfg_lmst6a_R11.00.03.ALL.12_19_Sep_11_00.rpt.
A31003-H8050-J100-09-7631, 09/2011
539
smu_linux_R1.fm
Special_Users Section
Ignore
Missing/Modified entries in cfg_templateV4.rpt:
oracle
CLI_Users Section
Ignore:
Result: Missing/Modified CLI users in cfg_templateV4.rpt:
User
Role
Locked Exp Time Exp Intvl Max Att Max Idle
User Chk
survop surveil 1
0
0
0
0
0
Trap_Dests Section
Ignore Added Trap dests in cfg_templateV4.rpt:
Dest IP Port
10.77.223.159
10.77.223.170
10.77.246.35 162
10.77.246.69
Ignore Result: Missing/Modified Trap dests in cfg_templateV4.rpt, if the IP is
found in the node.cfg
Emanate_SNMP Section
Rcsd Section
Ignore all mismatches, that are caused by the host name mismatch.
CF Section
Ignore Result: CF not identical:
CLUSTER_TIMEOUT 25
Added/Modified entries in cfg_templateV4.rpt:
CLUSTER_TIMEOUT 10
ShutdownAgt_IPMI Section
Ignore Result: mismatch, such as
Section ShutdownAgt_IPMI not present in
cfg_lmst6a_R11.00.03.ALL.12_19_Sep_11_00.rpt
ShutdownAgt_Die Section
Ignore mismatches that are caused by the cluster name, host name and IPs
540
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm

For example:
survival-authority 10.0.2.21
cluster-name lmst6
lmst6a#10.0.2.106
lmst6b#10.0.2.136
or
Added/Modified entries in cfg_templateV4.rpt:
survival-authority 10.77.183.11
cluster-name C9
srxl91#10.77.183.10srxl92#10.77.183.30
8.12.2 Summary Report Items that can be Ignored

after Node 1 Installation Comparison
The /log/sysConfig_summary.rpt items that can be ignored are as follows:
System_Packages Section:
Ignore if the following packages are missing
DirServerExt, ITDServer IBM, ibmusbasm, panicsel
Also ignore any issues related to SuSE packages.
Groups Section:
Ignore Added/Modified users in cfg_templateV4.rpt:
trusted
superad,intad,sysad,sysop1,sysop2,srx
Ignore Missing/Modified groups in cfg_templateV4.rpt:

lp mail news uucp dialout audio video games modem diradmin dirsuper
Users Section
Ignore Missing/Modified users in cfg_templateV4.rpt
news
Routing Section
Ignore Missing/Modified routes in cfg_lmst6a_R12_19_Sep_11_07.rpt that
contain the IP of the inter connection,
such as:
Destination
10.1.2.2
10.1.1.2
10.0.0.0
Mask
0.0.0.0
0.0.0.0
10.0.1.16
Gateway
255.255.255.255
255.255.255.255
255.255.255.0
A31003-H8050-J100-09-7631, 09/2011
Flags
UH
UH
UG
541
smu_linux_R1.fm
Netmasks Section
Timezone Section
SNORT_Conf Section
SNORTSam_Conf Section
SPP_PACKETRATE Section
Ignore all mismatch, such as Section SPP_PACKETRATE not present in
cfg_templateV4.rpt
RC2_Scripts Section, RC3_Scripts Section

Ignore mismatches or missing scripts caused by the S#. For example, ignore
mismatch of:
S15 snmpd vs. S14 snmpd
Or, ignore missing script:
S05hotplug
Default_nss Section
Ignore all mismatch, such as
Section Default_nss not present in
cfg_lmst6a_R11.00.03.ALL.12_19_Sep_11_00.rpt
Special_Users Section
Ignore
oracle
CLI_Users Section
Ignore:
Result: Missing/Modified CLI users in cfg_templateV4.rpt:
User
Role
Locked Exp Time Exp Intvl Max Att Max Idle
User Chk
survop surveil 1
0
0
0
0
0
Emanate_SNMP Section
542
A31003-H8050-J100-09-7631, 09/2011
smu_linux_R1.fm
ShutdownAgt_IPMI Section
Ignore all mismatch if the platform is x346
ShutdownAgt_Die Section
Ignore mismatch caused by upper cases/lower cases cluster name.
A31003-H8050-J100-09-7631, 09/2011
543
smu_linux_R1.fm
544
A31003-H8050-J100-09-7631, 09/2011
Migration_procedures.fm
Migrations to OpenScape Voice V5
9 Migrations to OpenScape Voice V5

Attention: For migration strategies where the Hardware Platform changes, use
the node.cfg collected in Section 8.3.1, step 2 (node_<node-name>.cfg), as a
guide to build a target release node.cfg that meets the requirements of your
particular upgrade scenario.
Attention: If you have not already done so, read Chapter 7, Overview of
Upgrades and Migrations to OpenScape Voice V5 before using the checklists in
this chapter.
Upgrades that include one or more of the following must use the checklists in this
chapter:
appropriate checklist.
Hardware platform migration (product type and node deployment changes

are allowed):
IBM x346, x3650T, FSC RX330 and IBM x3550 M2 servers replaced with
currently supported platforms (for example FTS RX200 or IBM x3550 M3
servers) as defined by the Product Matrix document.
Refer to Section 9.1, Hardware Platform Migrations, on page 546.
Product type migration (existing OpenScape Voice server hardware reused):

Change the product type from an integrated simplex or integrated duplex
system to a standard duplex system.
Refer to Section 9.2, Product Type and Node Deployment Migrations, on
page 579.
Node deployment migration (existing OpenScape Voice server hardware

reused):
Change the system from co-located nodes to geographically separated
nodes.
Refer to Section 9.2, Product Type and Node Deployment Migrations, on
page 579.
A31003-H8050-J100-09-7631, 09/2011
545
Hardware Platform Migrations
The following notes have to be considered:

Note: Basic TLS certificates are included in the image install. If custom
certificates have been employed the migration from a simplex to a co-located
duplex system should not require the generation of additional custom
certificates for node 2 (because the network schema does not change). The
external DNS will have to be administered with the node 2 IP address
information.
Note: A node deployment migration or any migration to a Voice Server target

release with a different network schema than the source release may require
the external DNS be administered to reflect the new IP addresses of the Voice
Server node(s). TLS certificates (including custom TLS certificates) should be
reviewed and generated as required for these cases.
9.1 Hardware Platform Migrations

The supported upgrade paths for hardware platform migration scenarios are as
follows:
546
V4R1 OpenScape Voice Entry (Low Cost IBM x3250 simplex) to V5 Standard
Duplex: Refer to Section 9.1.7 on page 574. Migration to the IBM x3650T is
not supported.
V3.1R3/V4R1 simplex to V5 simplex: Refer to Section 9.1.1 on page 547.

geographically separated nodes): Refer to Section 9.1.2 on page 552.

separated nodes) to V5 standard duplex (same node deployment as source):

(geographically separated nodes): Refer to Section 9.1.4 on page 560.
V3.1R3/V4R1 standard duplex (co-located nodes or geographically

A31003-H8050-J100-09-7631, 09/2011

9.1.1 Simplex to Simplex Hardware Migration

At the discretion of the technician, checklist tasks 1 through 10 may be performed
Use Table 37 to monitor the migration to the new hardware platform. Perform only
the task indicated and then return to the checklist. As an example; if the checklist
indicates Section 7.3.1 should be performed, follow the link to Section 7.3.1,
perform that task, and return to the checklist.
Open the tools menu
Task
Description
1.

2.

3.

4.

463.
5.
Perform the procedure in Section 8.3.1, Collect System Data on Node

1, on page 456. This procedure will provide a source release node.cfg
that can be modified for use in the target release (in Task 6).
6.
Table 37
Simplex to Simplex Hardware Migration (Sheet 1 of 5)
A31003-H8050-J100-09-7631, 09/2011
547
Task
Description
7.
stick and label the stick node.cfg.primary.
Table 37
548
A31003-H8050-J100-09-7631, 09/2011
Task
Description
8.
Create the response.cfg.primary file using one of the methods below.

Method#1:
The response.cfg.primary is similar to the response file you will find on your
source installation at: /enterprise/servicetools/install/conf/responsefile.txt.
Copy this responsefile.txt to your USB stick and rename it to
response.cfg.primary. Parameters SI_SYMPHONIA_ADMIN_PASSWORD
and SI_DB_LOGON_PASSWORD must be edited because in this file the
password's are encrypted. Please replace the encrypted password string
with the "normal" password string. Replace the IP's you find inside
response.cfg.primary with the Admin IP of node 1. This is the nafo0 IP listed
for node 1 in the target release node.cfg.
the response file.
Text at the end of this task explains How to determine Admin IP of node 1
(nafo0 IP);.
Method#2:
If you choose to use a template then please add the same
SI_COMMUNITY_NAME, SI_SYMPHONIA_ADMIN_PASSWORD,
SI_DB_LOGON_PASSWORD as actually configured at your source system.
For a guide to help build the response file from a template refer to Section
5.2.4.2, Response File for the Integrated Simplex Deployment, on page
341.
Make sure to populate the correct IP's for IP related fields in the template.
The IP you should be employing is the Admin IP of node 1. This is the nafo0
IP listed for node 1 in the target release node.cfg. Text at the end of this task
explains How to determine Admin IP of node 1 (nafo0 IP);
the response file. Copy this file to your USB stick and rename it to
response.cfg.primary.
How to determine Admin IP of node 1 (nafo0 IP);
The admin IP will be the IP address assigned to node 1 of nafo0 in the target
release node.cfg file. In the following example, 1.2.3.6 is the nafo0 node 1 IP
(this example is an excerpt of the nafo configuration from a Low Cost
node.cfg);
Table 37
A31003-H8050-J100-09-7631, 09/2011
549
Task
Description
9.
Ensure that the new hardware platform for OpenScape Voice has been
installed. For example: BIOS/RAID is configured, firmware is updated,
and remote console function is configured. Ethernet cables should not
be connected at this time.
If the server has not been installed, refer to the appropriate checklist
for the server type and install it now:
For IBM x3550 M2/M3 server: Refer to Table 13 on page 142.
For FTS RX200 server: Refer to Table 18 on page 172.
10.

11.
node.cfg.primary. Refer to Section 9.5 on page 601.
12.
Swap the cables from the old system to the new system. Refer to
Chapter 3, Installing the Hardware Platform and locate the
subsection that describes each platforms cable connections (e.g.,
Section 3.3.6, Connecting the Cables to the IBM x3650T Server, on
page 55). These sections provide the steps to swap cables from the
old system to the new system.
For an x3250M2 to x3250M3 Simplex to Simplex Hardware Migration:
Move the cable from the x3250M2 Ethernet 1 interface to the

x3250M3 Ethernet 1 interface.
Move the cable from the x3250M2 Ethernet 2 interface to the

x3250M3 Ethernet 2 interface.
Use the following figures as a guide for cable placement:
13.
Figure 5, IBM x3250 M2 Rear View for the Single-Node

OpenScape Voice
Figure 6, IBM x3250 M3 Rear View for the Single-Node

OpenScape Voice.
Attention: Do not disconnect the USB stick as indicated in the
Section 4.2 procedure; leave the USB stick connected until directed by
the migration procedure instructions to disconnect.
Table 37
550
A31003-H8050-J100-09-7631, 09/2011
Task
Description
14.

500.
15.

page 501.
16.

17.
Import the data of the source system from the USB memory stick
labeled node.cfg.primary to the target system. Refer to Section 9.7 on
page 602.
18.

19.
20.

to V5, on page 437.
Table 37
A31003-H8050-J100-09-7631, 09/2011
551
9.1.2 Simplex to Standard Duplex Hardware Migration

Use Table 38 to monitor the migration to the new hardware platforms and product
type. Perform only the task indicated and then return to the checklist. As an
example; if the checklist indicates Section 7.3.1 should be performed, follow the
link to Section 7.3.1, perform that task, and then return to the checklist.
Open the tools menu
In the More Tools window scroll down to the Page Navigation Toolbar.
Select Okay in the More Tools window.
Task
Description
1.

2.

3.

4.

463.
5.

6.
Table 38
552
Simplex to Standard Duplex Hardware Migration (Sheet 1 of 4)
A31003-H8050-J100-09-7631, 09/2011
Task
Description
7.
8.
Ensure that the required network components (for example: additional

Ethernet switches, L2/L3 routers) to support the standard duplex node
deployment (co-located or geographically separated nodes) are
installed.
Note: Section 2.3, Guidelines for Static Routes of Geographically
Separated Nodes, and Appendix I, Removal of Obsolete IP
Addresses when Upgrading to V4R1 (or higher releases) detail the
requirements for network separated systems. If these sections have
not already been reviewed please do so now.
9.
Ensure that the additional servers required for the standard duplex are
installed. Refer to Section 7.2.8, Additional Servers for Migrations to
Standard Duplex.
10.
Ensure that the new hardware platforms for OpenScape Voice have
been installed. For example: BIOS/RAID is configured, firmware is
updated, remote console function is configured, and Ethernet cables
are connected.
If the servers have not been installed, refer to the appropriate checklist
for the server type and install them now:
11.
Table 38
For IBM X3650T servers: Refer to Table 2 on page 53.
For FSC RX330 servers: Refer to Table 7 on page 82.
For IBM x3550 M2/M3 servers: Refer to Table 13 on page 142.

A31003-H8050-J100-09-7631, 09/2011
553
Task
Description
12.
node.cfg.primary. Refer to Section 9.5 on page 601. For this
migration scenario you will be directed to copy the patch directory,
which contains the export.tar file, from the node.cfg.primary USB
stick (for node A) to the node.cfg.secondary USB stick (Node B).
13.
Install the additional Ethernet card (or cards) to the simplex node.
Refer to Appendix C, IBM x3650T Quad Ethernet Card Installation,
Section 7.2.5, FSC RX330 Simplex to Standard Duplex Migration, on
page 430, or Section 7.2.6, IBM x3550 M2/M3 Simplex to Standard
Duplex Migration, on page 431, or Section 7.2.7, FTS RX200 Simplex
to Standard Duplex Migration, on page 431 as appropriate.
14.
Attach the Ethernet cables as appropriate for the hardware server:

For IBM X3650T servers: Refer to Section 3.3.6.2, Connecting the Cables
for a Redundant IBM x3650T, on page 57.
For FSC RX330 servers: Refer to Section 3.4.6.2, Connecting the Cables
for a Redundant FSC RX330, on page 86 .
For IBM x3550 M2/M3 servers: Refer to Section 3.6.6.2, Connecting the
Cables for a Redundant IBM x3550 M2/M3, on page 146.
For FTS RX200 servers: Refer to Section 3.7.6.2, Connecting the Cables
for a Redundant FTS RX200, on page 176.
15.
16.

500.
17.

page 501.
18.

506.
19.

page 506.
20.

21.
22.

Table 38
554
A31003-H8050-J100-09-7631, 09/2011
Task
Description
23.
Note: At the discretion of the user this task can be started while task
Section 9.9, Configure the OpenScape Applications Server for Access
to the Nodes until task 22 is complete.
For Migration from Integrated Simplex to Standard Duplex

Small Deployment instructions, refer to the OpenScape UC
Application V3, Installation and Upgrade, Installation Guide,
section titled "Migrating from Integrated Simplex V3 R2 to Standard
Duplex (small) V3 R2".

The following modifications should be done for the Media Server

(in case an internal Media Server is pre-configured from source
release):
The pre-configured Media Server should be blocked.
Fully Qualified Domain Name should change to FQDN of

External Applications Server.
MG Signaling IP should change to the IP of External

Applications Server.
The Media Server should be unblocked.
DLS data Application data that was configured on the source release
will be lost. This data needs to be re-configured manually on the target
system.
24.
Execute RapidStat and place test calls to verify that there are no issues
and that the system is functioning correctly.
25.

to V5, on page 437.
Table 38
A31003-H8050-J100-09-7631, 09/2011
555
9.1.3 Integrated Duplex to Standard Duplex Hardware

Migration (Node Deployment Unchanged)
type in which the node deployment of the target system is kept the same as it was
for the source system. Perform only the task indicated and then return to the
checklist. As an example; if the checklist indicates Section 7.3.1 should be
performed, follow the link to Section 7.3.1, perform that task, and return to the
checklist.
Open the tools menu
Task
Description
1.

2.

3.

4.

463.
5.

6.
Table 39
556
Integrated Duplex to Standard Duplex Hardware Migration with

Same Node Deployment (Sheet 1 of 4)
A31003-H8050-J100-09-7631, 09/2011
Task
Description
7.
8.
Standard Duplex.
9.
Ensure that the new hardware servers for OpenScape Voice have
been installed. For example: BIOS/RAID is configured, firmware
updated, and remote console function is configured. Ethernet cables
should not be connected at this time.
10.

11.
page 601.
12.
Table 39

A31003-H8050-J100-09-7631, 09/2011
557
Task
Description
13.
14.

500.
15.

page 501.
16.

506.
17.

page 506.
18.

19.
20.

Table 39
558

A31003-H8050-J100-09-7631, 09/2011
Task
Description
21.
For Migration from Integrated Duplex to Standard Duplex

section titled "Migrating from Integrated Duplex V3 R2 to Standard

The following modifications should be done for Media Server (in

case an internal Media Server is pre-configured from source
release):
The pre configured Media Server should be blocked.


system.
22.
23.

to V5, on page 437.
Table 39

A31003-H8050-J100-09-7631, 09/2011
559
9.1.4 Integrated Duplex to Standard Duplex Hardware

Migration (Node Deployment Changed)
type in which the co-located node deployment of the source system is changed
to a geographically separated node deployment in the target system. Perform
only the task indicated and then return to the checklist. As an example; if the
checklist indicates Section 7.3.1 should be performed, follow the link to Section
7.3.1, perform that task, and return to the checklist.
Open the tools menu
Task
Description
1.

2.

3.

4.

463.
5.

6.
Table 40
560

Change from Co-located to Geo-separated Nodes (Sheet 1 of 4)
A31003-H8050-J100-09-7631, 09/2011
Task
Description
7.
8.

Ethernet switches, L2/L3 routers) to support the geographically
separated nodes are installed.
Addresses when Upgrading to V4R1 (or higher releases) detail
9.
Standard Duplex.
10.
are attached.
11.
Table 40

A31003-H8050-J100-09-7631, 09/2011
561
Task
Description
12.
page 601.
13.
14.

500.
15.

page 501.
16.

506.
17.

page 506.
18.

19.
20.

Table 40
562

A31003-H8050-J100-09-7631, 09/2011
Task
Description
21.



release):


system.
22.
23.

to V5, on page 437.
Table 40

A31003-H8050-J100-09-7631, 09/2011
563
9.1.5 Standard Duplex to Standard Duplex Hardware

Use Table 41 to monitor the migration to the new hardware servers in which the
node deployment of the target system is kept the same as it was in the source
system. Perform only the task indicated and then return to the checklist. As an
link to Section 7.3.1, perform that task, and return to the checklist.
Open the tools menu
Task
Description
1.

2.

3.

4.

463.
5.

6.
Table 41
564
Standard Duplex to Standard Duplex Hardware Migration with Same

Node Deployment (Sheet 1 of 5)
A31003-H8050-J100-09-7631, 09/2011
Task
Description
7.
8.
updated, and remote console function is configured. Ethernet cables
9.

10.
page 601.
11.
Table 41

A31003-H8050-J100-09-7631, 09/2011
565
Task
Description
12.
For the external Applications server(s) monitoring the Voice Server

of this procedure.
server Installation/update process.:
proceeding.
13.

500.
14.

page 501.
15.

506.
16.

page 506.
17.

18.
Table 41
566

A31003-H8050-J100-09-7631, 09/2011
Task
Description
19.

20.
Install/update the OpenScape Applications onto the external


V3.1R3 DVD8 PS5 HF5 (or newer) to V5 Applications
V3.1R3 DVD5 HF7 (or newer) to V5 Applications
V4R1 DVD5 HF7 (or newer) to V5 Applications




Installation and Upgrade, Installation Guide, section; titled
Table 41

A31003-H8050-J100-09-7631, 09/2011
567
Task
Description
21.
22.

to V5, on page 437.
Table 41
568

A31003-H8050-J100-09-7631, 09/2011
9.1.6 Standard Duplex to Standard Duplex Hardware

Use Table 42 to monitor the migration to the new hardware servers in which the
co-located node deployment of the source system is changed to a geographically
separated node deployment in the target system. Perform only the task indicated
and then return to the checklist. As an example; if the checklist indicates Section
7.3.1 should be performed, follow the link to Section 7.3.1, perform that task, and
return to the checklist.
Open the tools menu
Task
Description
1.

2.

3.

4.

463.
5.

6.
Table 42
Standard Duplex to Standard Duplex Hardware Migration with

Change to Geo-separated Nodes (Sheet 1 of 5)
A31003-H8050-J100-09-7631, 09/2011
569
Task
Description
7.
8.

9.
are attached.
For FTS RX200 servers: Refer to Table 18 on page 172.
10.

11.
page 601.
Table 42
570

A31003-H8050-J100-09-7631, 09/2011
Task
Description
12.

of this procedure.
proceeding.
13.

500.
14.

page 501.
15.

506.
16.

page 506.
17.

18.
Table 42

A31003-H8050-J100-09-7631, 09/2011
571
Task
Description
19.

20.
Install/update the OpenScape Applications on the external






Table 42
572

A31003-H8050-J100-09-7631, 09/2011
Task
Description
21.
22.

to V5, on page 437.
Table 42

A31003-H8050-J100-09-7631, 09/2011
573
9.1.7 Low Cost to Standard Duplex Migration

Attention: If the LowCost is configured to use its internal SBC, the SBC has to
be bypassed prior to the migration, since the target system does not have an
integrated SBC: instead of the Low Cost routing destinations to the SBC, the
routing should point to an endpoint that interfaces with the Signaling interface of
the distant end. In turn, the distant end must route calls to the Low Cost signaling
interface directly.

type. Perform only the task indicated and then return to the checklist. As an
link to Section 7.3.1, perform that task, and return to the checklist.
Open the tools menu
Task
Description
1.

2.

3.

4.

463.
Table 43
574
Low Cost to Standard Duplex Migration (Sheet 1 of 5)
A31003-H8050-J100-09-7631, 09/2011
Task
Description
5.
For this migration strategy it is not possible to switch to a different

hardware platform when the input node.cfg already has the IBM x3250
LowCost platform selected.
node.cfg that can be modified for use in the target release.
Adapt the parameters from the node.cfg collected in Section 8.3.1,
step 2 (node_<node-name>.cfg) to build the node.cfg for the target
system. Use Section 9.10, Create the Node.cfg for the Target System
(Source system = Low Cost), on page 607.
6.
stick and label the stick node.cfg.primary. Copy the
7.

8.
Table 43
Standard Duplex, on page 432.
A31003-H8050-J100-09-7631, 09/2011
575
Task
Description
9.
are attached.
10.

11.
node.cfg.primary (in Task 7). Refer to Section 9.5 on page 601. As a
part of the export step, for this migration scenario, you will be directed
to copy the patch directory, which contains the export.tar file, from the
node.cfg.primary USB stick (for node A) to the node.cfg.secondary
USB stick (Node B)
12.
13.

500.
14.

page 501.
15.

506.
16.

page 506.
17.

18.
Table 43
576
A31003-H8050-J100-09-7631, 09/2011
Task
Description
19.

20.
For Migration from Integrated Simplex to Standard Duplex Small

Deployment instructions, refer to the OpenScape UC Application
V3, Installation and Upgrade, Installation Guide, section titled
"Migrating from Integrated Simplex V3 R2 to Standard Duplex (small)
V3 R2".


release):


system.
21.
Table 43
The following modifications should be done for Media Server (in case
an internal Media Server is pre-configured from source release):
Fully Qualified Domain Name should change to FQDN of External

MG Signaling IP should change to the IP of External Applications

Server.

A31003-H8050-J100-09-7631, 09/2011
577
Task
Description
22.
23.

to V5, on page 437.
Table 43
578
A31003-H8050-J100-09-7631, 09/2011
Product Type and Node Deployment Migrations
9.2 Product Type and Node Deployment Migrations

The supported product type and node deployment migrations are as follows:
Note: In these product type and node deployment migrations the existing
OpenScape Voice hardware platform is reused.

geographically separated nodes): Refer to Section 9.2.1 on page 579.



9.2.1 Simplex to Standard Duplex Product Migration

Use Table 44 to monitor the migration to the new product (existing OpenScape
Voice hardware platform reused). Perform only the task indicated and then return
to the checklist. As an example; if the checklist indicates Section 7.3.1 should be
checklist.
Open the tools menu
A31003-H8050-J100-09-7631, 09/2011
579
Task
Description
1.

2.

3.

4.

463.
5.

6.
7.
8.

Ethernet switches, L2/L3 routers) to support the standard duplex node
deployment (co-located or geographically separated nodes) are
installed. Refer to Section 2.3, Guidelines for Static Routes of
Geographically Separated Nodes.
Table 44
580
Simplex to Standard Duplex Product Migration
A31003-H8050-J100-09-7631, 09/2011
Task
Description
9.
Standard Duplex.
10.
Ensure that the additional hardware server for OpenScape Voice has
updated, and remote console function configured. Ethernet cables
If the server has not been installed, refer to the appropriate checklist
for the server type and install it now:
11.

12.
node.cfg.primary. Refer to Section 9.5 on page 601. For this
migration scenario you will be directed to copy the patch directory,
which contains the export.tar file, from the node.cfg.primary USB
stick (for node A) to the node.cfg.secondary USB stick (Node B).
13.
Install the additional Ethernet card (or cards) to the simplex node.
Refer to Appendix C, IBM x3650T Quad Ethernet Card Installation,
Section 7.2.5, FSC RX330 Simplex to Standard Duplex Migration, on
page 430, Section 7.2.6, IBM x3550 M2/M3 Simplex to Standard
Duplex Migration, on page 431 or Section 7.2.7, FTS RX200 Simplex
to Standard Duplex Migration, on page 431 as appropriate.
14.
Attach the Ethernet cables as appropriate for the hardware server:
Table 44
For IBM X3650T servers: Refer to Section 3.3.6.2, Connecting the

Cables for a Redundant IBM x3650T, on page 57.
For FSC RX330 servers: Refer to Section 3.4.6.2, Connecting the

Cables for a Redundant FSC RX330, on page 86.
For IBM x3550 M2/M3 servers: Refer to Section 3.6.6.2,

Connecting the Cables for a Redundant IBM x3550 M2/M3, on
page 146.
For FTS RX200 servers: Refer to Section 3.7.6.2, Connecting the

Cables for a Redundant FTS RX200, on page 176.
A31003-H8050-J100-09-7631, 09/2011
581
Task
Description
15.
16.

500.
17.

page 501.
18.

506.
19.

page 506.
20.

21.
22.

23.
For Migration from Integrated Simplex to Standard Duplex

section titled "Migrating from Integrated Simplex V3 R2 to Standard
<task 23 continues on the following page>

Table 44
582
A31003-H8050-J100-09-7631, 09/2011
Task
Description
23.cnt.


release):


system.
24.
25.

to V5, on page 437.
Table 44
9.2.2 Integrated Duplex to Standard Duplex Product

Voice hardware platforms reused) in which the node deployment of the target
system is kept the same as it was in the source system. Perform only the task
indicated and then return to the checklist. As an example; if the checklist indicates
Section 7.3.1 should be performed, follow the link to Section 7.3.1, perform that
task, and return to the checklist.
Open the tools menu
A31003-H8050-J100-09-7631, 09/2011
583
Task
Description
1.

2.

3.

4.

463.
5.

6.
7.
8.
Standard Duplex.
9.

Table 45
584
Integrated Duplex to Standard Duplex Migration with Same Node

Deployment (Sheet 1 of 3)
A31003-H8050-J100-09-7631, 09/2011
Task
Description
10.
page 601.
11.
12.

500.
13.

page 501.
14.

506.
15.

page 506.
16.

17.
18.

19.


Table 45

A31003-H8050-J100-09-7631, 09/2011
585
Task
Description
19. cnt.

release):


system.
20.
21.

to V5, on page 437.
Table 45

9.2.3 Integrated Duplex to Standard Duplex Product

Voice hardware platforms reused) in which the co-located node deployment of the
source system is changed to a geographically separated node deployment in the
target system. Perform only the task indicated and then return to the checklist. As
an example; if the checklist indicates Section 7.3.1 should be performed, follow
the link to Section 7.3.1, perform that task, and return to the checklist.
586
A31003-H8050-J100-09-7631, 09/2011
Open the tools menu
Task
Description
1.

2.

3.

4.

463.
5.

6.
7.
Table 46
Integrated Duplex to Standard Duplex Migration with Change to

Geo-separated Nodes (Sheet 1 of 4)
A31003-H8050-J100-09-7631, 09/2011
587
Task
Description
8.

Ethernet switches, L2/L3 routers) to support the standard duplex
geographically separated nodes are installed.
9.
Standard Duplex.
10.

11.
page 601.
12.
Disconnect all cables from the nodes, relocate the nodes to the
geographically separate locations and reattach the cables as
appropriate:
13.
Section 3.3.6.2, Connecting the Cables for a Redundant IBM

x3650T, on page 57
Section 3.4.6.2, Connecting the Cables for a Redundant FSC

RX330, on page 86

x3550 M2/M3, on page 146
Section 3.7.6.2, Connecting the Cables for a Redundant FTS

RX200, on page 176
14.
Table 46
588

500.
A31003-H8050-J100-09-7631, 09/2011
Task
Description
15.

page 501.
16.

506.
17.

page 506.
18.

19.
20.

Table 46

A31003-H8050-J100-09-7631, 09/2011
589
Task
Description
21.

Duplex (small) V3 R2"


release):


system.
22.
23.

to V5, on page 437.
Table 46
590

A31003-H8050-J100-09-7631, 09/2011
9.2.4 Standard Duplex Node Redeployment Migration

Use Table 47 to monitor the migration from co-located nodes to geographically
separated nodes (existing OpenScape Voice hardware servers reused) for a
standard duplex system. Perform only the task indicated and then return to the
checklist. As an example; if the checklist indicates Section 7.3.1 should be
checklist.
Open the tools menu
Task
Description
1.

2.

3.

4.

463.
5.

6.
Table 47
Standard Duplex Node Redeployment Migration (Sheet 1 of 5)
A31003-H8050-J100-09-7631, 09/2011
591
Task
Description
7.
8.

9.

10.
page 601.
11.
Disconnect all cables from the nodes, relocate to the geographically

separate locations and reattach the cables as appropriate:
Table 47
592

x3650T, on page 57
Section 3.4.6.2, Connecting the Cables for a Redundant FSC

RX330, on page 86

x3550 M2/M3, on page 146
Section 3.7.6.2, Connecting the Cables for a Redundant FTS

RX200, on page 176
A31003-H8050-J100-09-7631, 09/2011
Task
Description
12.

of this procedure.
proceeding.
13.

500.
14.

page 501.
15.

506.
16.

page 506.
17.

18.
Table 47
A31003-H8050-J100-09-7631, 09/2011
593
Task
Description
19.

20.
Install/update the OpenScape Applications on the external






Table 47
594

A31003-H8050-J100-09-7631, 09/2011
Task
Description
21.
22.

to V5, on page 437.
Table 47
A31003-H8050-J100-09-7631, 09/2011
595
Create the Node.cfg for the Target System
9.3 Create the Node.cfg for the Target System

Attention: This procedure is NOT intended for;
Section 8.6, Upgrading a Standard Duplex System (SMU Method)
If you are performing the SMU method then employ Section 8.3.2, Create the
Node.cfg for the Target Release, on page 458.
Section 9.1.7, Low Cost to Standard Duplex Migration
If you are performing the Low Cost to Standard Duplex Migration then employ
Section 9.10, Create the Node.cfg for the Target System (Source system = Low
Cost), on page 607.
All other migrations should employ this procedure.

need to be performed. The SMU upgrade method is detailed in Section 8.1.4,
Split Mode Upgrade Overview, on page 448. As a general rule, no changes to
the OSCV target release node.cfg are allowed during the three upgrade
procedure detailed in Chapter 8, Upgrades to OpenScape Voice V5. After a
Chapter 8 upgrade procedure is completed, the EZIP feature can be employed to
establish source based routing (by specifying default gateway addresses). For
more information regarding the EZIP feature, refer to Chapter F, Updating the
Node.cfg File (Also Known as EZIP). Any questions should be addressed to
your next level of support.
Note: The VLAN tagging configuration offered in V4R1 OSV-E (IBM x3250M2) is
no longer supported in V5. For new installations, the V5 NCPE tool does not
display the VLAN Enabled box and the respective field in node.cfg is set to "No."
If the NCPE is opened with an old node.cfg that has VLAN tagging enabled, (e.g.,
during upgrade), it will display the VLAN tagging field, but in red (indicating invalid
data). If you see this, please contact GVS to discuss options to configure the OSV
and how to potentially modify the IP network. No VLAN tagging means that the
OSV-E does not support separated IP networks on its LAN interface. It is
596
A31003-H8050-J100-09-7631, 09/2011
connected to one single IP network, which also means that there is no IP source
based routing. Discontinuation of VLAN tagging is primarily due to the
introduction of the integrated IMM that comes standard with the x3250M3 and
allows remote connectivity to the server (the x3250M2 has been discontinued).
This remote connectivity is needed for the V5 feature "Remote Software
Upgrades". This new integrated IBM module unfortunately does not support
VLAN Tagging (as the x3250M2 non-integrated IMM did).
Attention: For the migration scenarios, it is recommended that the user create
the node.cfg from scratch using the NCPE. Specify the new IP configuration using
the appropriate tabs. Specify the new IP configuration using the appropriate tabs.
The node.cfg collected in Section 8.3.1, Collect System Data on Node 1, on
page 456 may be used as a reference for external server IP addresses (e.g.,
Name (DNS), NTP, CSTA, SNMP, License, Billing, SNMP and Misc. Host
servers.)
1. Transfer the node_<node-name>.cfg file generated in Section 8.3.1, Collect
System Data on Node 1, on page 456 to a Windows/Linux machine that can
run the OfflineWizard.
2. Start the OffLineWizard. Select Install on the first screen, click Next, then
select Expert Mode on the next screen.
3. From the NCPE GUI:
a) Under File, open the file node_<node-name>.cfg (e.g.,
node_linux1.cfg) that was created in Section 8.3.1, Collect System
Data on Node 1, on page 456 and generate the node.cfg for the target
release.
b) Answer Yes to question The file node_<node-name>.cfg is from
source release (example given; V4.0R1). Do you want to convert it to
target release (example given; V5.0)?"
performed.
c) Enter OK and the click OK to the Warning window to accept new
parameters added to the node.cfg.
A31003-H8050-J100-09-7631, 09/2011
597
d) Under Configuration and Hardware (1/1) make sure that the

Installation mode is set to normal. As appropriate, specify all new
parameters for the new configuration of the target system.
Note: If you arrive at Section 9.3, step 3d from Section 8.5, Section 8.6
or Section 8.7 no modifications to the voice server hardware, product type
or deployment are allowed. You should be employing a procedure from
Section 8, Migrations to OpenScape Voice V5R0 (if the Voice Server
hardware, product type or deployment is to be changed). Only the
changes indicated in steps 3b, 3c, and 3e through 3i are allowed if you
arrived at Section 9.3, step 3d from Section 8.5, Section 8.6 or
Section 8.7.
e) Under Additional Parameters (1/1) update the Software Build ID to the
target release.
performed.
If this OpenScape Voice server does not carry CSTA traffic go to step 3f.
If this OpenScape Voice server does carry CSTA traffic, it is necessary
(due to security rules being tightened for CSTA servers in V5) to update
the CSTA server addresses to the node.cfg.
Update the CSTA server addresses to the node.cfg as follows:
Note: The IP addresses in the CSTA Servers table are used to build the
more secure V5 packet filtering rules. Contact your next level of support
if you have questions.
1. Select the IP Configuration (4/6) screen.
2. Enter IP configuration parameters for the CSTA Servers ONLY. Click
the appropriate icon below the CSTA Servers table to enter more (or
remove) entries.
3. Go to step 3f.
f)
Select the IP Configuration (5/6) screen.

If Static/Source Routes exist please verify there are NO duplicate routes.
Duplicate routes will result in Image installation failures. Duplicate routes
should be deleted using the Delete button (X) provided with each table. A
method to verify the existence of duplicate routes is to employ the
Preview mode, which is accessed by selecting the Preview icon in the
NCPE menu bar (or by selecting the File menu and then Preview).
598
A31003-H8050-J100-09-7631, 09/2011
The NCPE defaults to the signaling subnet gateway as the default route
subnet. If servers have been added to the node.cfg and these servers
must communicate over a subnet other than the default route subnet; add
these static routes at this time. Examples of servers that may require
static routes;
A Billing Server may need a static route to transfer data over the
billing subnet.
A SNMP server may need a static route to transfer data (snmp traps)
over the administration subnet to a Network Operations Center.
The destination server IP address.
The destination IP address netmask (typically 255.255.255.255).
For the subnet gateway IP address, refer to IP Configuration page

1/6.
- For the SNMP server example the Administration subnet gateway IP
- For the Billing server example the Billing subnet gateway IP address
would be employed.

screen as required.
Attention: Ensure that any static routes manually added to the
OpenScape Voice server (not added with the EZIP feature) are included
in the static route table.
For more info regarding the EZIP refer to Appendix F, Updating the
Node.cfg File (Also Known as EZIP) of this document.
g) In migration scenarios, including a network change, specify the new IP
configuration using the appropriate tabs.
Attention: For migration scenarios, including a major network change, it
is recommended that the user create the node.cfg from scratch using the
OffLineWizard. Specify the new IP configuration using the appropriate
tabs. The node.cfg collected in Section 8.3.1, Collect System Data on
Node 1, on page 456 may be used as a reference for external server IP
addresses (e.g., Name (DNS), NTP, CSTA, SNMP, License, Billing,
SNMP and Misc. Host servers.)
A31003-H8050-J100-09-7631, 09/2011
599
Download and Install the Migration Toolkit Software to the Source System
h) Check and correct all errors/warnings (all red marked items). There is an
exception: the user may disregard the warning about node names that
contain an "underscore". This will happen if the node name of the old
release contains an underscore and, by design, the same node name has
to be carried over to the new release.
i)
Select File, Save As, set File of Type to All Files, and enter File
name: node.cfg.primary for a simplex system or node 1 of a duplex
system. Click Save, make note of the path to which the file was saved
and then click OK.
Note: Ensure that the file was not saved with a name that has a .cfg
extension (for example: node.cfg.primary.cfg). The file name should be
without the second .cfg extension (in fact: node.cfg.primary).
j)
If this is a simplex system, go to step 4. For a duplex system, continue to

the next step.
k) Select File, Save As, set File of Type to All Files, and enter File
name: node.cfg.secondary for the second node of a duplex system.
Click Save, make note of the path to which the file was saved and then
click OK.
(for example: node.cfg.secondary.cfg). The file name should be without
the second .cfg extension (in fact: node.cfg.secondary).
4. Exit the NCPE. Select File, Exit, Yes, and Finish.
9.4 Download and Install the Migration Toolkit Software to the Source
System
Verify that an old migration toolkit software does not exist on the system with the
command:
rpm -qa | grep -i UNSPmigration
If an old version of the migration toolkit software is found, then it should be
removed with the following command:
As user root, download to the /tmp directory and install the latest
UNSPmigration-<V#>.rpm to the nodes (or node for a simplex system) with the
command:
rpm -ivh --replacefiles --replacepkgs UNSPmigration-<V#>.rpm
600
A31003-H8050-J100-09-7631, 09/2011
Export the Data of the Source System
Example given;
# rpm -ivh --replacefiles --replacepkgs UNSPmigration-1.05-29.rpm
After some seconds, messages similar to the following will be displayed:

Preparing...
########################################### [100%]
1:UNSPmigration ########################################### [100%]

Checking rsync package : rsync-2.6.8-36.26.28
Migration tools installed successfully.
9.5 Export the Data of the Source System

Note: Do NOT manually mount the USB stick. The USB stick will be mounted by
the script. Run the indicated command from node 1 only.
Export the data of the source system to the USB memory sticks (or stick for a
simplex system) that you copied the node.cfg to earlier as follows:
1. Connect the USB stick labeled node.cfg.primary to node 1.
2. For a duplex system, connect the USB stick labeled node.cfg.secondary to
node 2.
3. As user root on node 1 of the current HiPath 8000 enter the following
command. The action of this command will export all user configurations of
the nodes onto both the USB stick in node 1 and in node 2 (for a duplex
system).
Note: Please run this on node 1 only.
export8k
After approximately 10 minutes, a list of messages will be displayed with the
following message at the end of the list indicating a successful export:
[*] Export completed: <date>
Note: The above procedure creates file: patch/export.tar on each USB
memory stick.
A31003-H8050-J100-09-7631, 09/2011
601
Download and Install the Migration Toolkit Software to the Target System
4. Remove the USB memory stick (or sticks for a duplex system) from the node
(or nodes for a duplex system).
Attention: If you reached this Section from a Simplex to Duplex Migration
scenario, copy the export.tar file from the patch directory of the
node.cfg.primary USB stick to the patch directory of the node.cfg.secondary
USB stick.
9.6 Download and Install the Migration Toolkit Software to the Target
System
Verify that an old migration toolkit software does not exist on the system with the
command:
rpm -qa | grep -i UNSPmigration
If an old version of the migration toolkit software is found, then it should be
removed with the following command:
As user root, download to the /tmp directory and install the latest
UNSPmigration-<V#>.rpm to the nodes (or node for a simplex system) with the
command:
rpm -ivh --replacefiles --replacepkgs UNSPmigration-<V#>.rpm
Example given;
# rpm -ivh --replacefiles --replacepkgs UNSPmigration-1.05-29.rpm
After some seconds, messages similar to the following will be displayed:

Preparing...
########################################### [100%]
1:UNSPmigration ########################################### [100%]

Checking rsync package : rsync-2.6.8-36.26.28
Migration tools installed successfully.
9.7 Import the Source System Data to the Target System

Attention: Unless directed otherwise by Release Notes the target OpenScape
voice server patch level must be on latest V5R0 patch set. An integrated system
should ensure the applications server is updated with the latest released DVD/
PatchSet/HotFix.
602
A31003-H8050-J100-09-7631, 09/2011
Import the Source System Data to the Target System
Any questions concerning the Import step should be addressed to your next level
of support.
Note: Do NOT manually mount the USB stick. The USB stick will be mounted
by the script. Run the indicated command from node 1 only.
Note: By default the source release passwords for system-defined OpenScape

Voice accounts (for example, srx, and root) are imported to the target release.
As user root on node 1, import the data of the source system from the USB sticks
(or stick for a simplex system) to the target system as follows:
For system upgrades/migrations in which the network configuration of the

source and target system stay the same follow step a). This should apply to;
Section 8.5, Upgrading an Integrated Simplex System (Toolkit Method)
Section 8.7, Upgrading a Standard Duplex System (Toolkit Method)
Section 9.1.1, Simplex to Simplex Hardware Migration

(Node Deployment Unchanged) (Node Deployment Unchanged)


For system upgrades/migrations (with or without a hardware migration) in

which the network configuration is changed follow step b). This should apply
to;
Section 9.1.2, Simplex to Standard Duplex Hardware Migration

(Node Deployment Changed) (Node Deployment Changed)

Section 9.1.7, Low Cost to Standard Duplex Migration
Section 9.2.1, Simplex to Standard Duplex Product Migration

Section 9.2.4, Standard Duplex Node Redeployment Migration
A31003-H8050-J100-09-7631, 09/2011
603
Remove the Migration Toolkit Software from the Target System
a) Execute this command for system upgrades/migrations involving in which the

network configuration of the source and target system stay the same.
As user root, run the following command from node 1 only:
import8k
Go to step c)
b) Execute this command for system upgrades/migrations (with or without a
hardware migration) in which the network configuration is changed.
As user root, run the following command from node 1 only:
migrate8k -config
Go to step c)
c) The time required to import the configuration varies (based on the size of the
imported database). Messages similar to the following at the end of the list
indicate a successful import:
prepare8k:Data imported successfully.
[*] Migrate completed: <date>
Disconnect the USB memory sticks (or stick for a simplex system).
9.8 Remove the Migration Toolkit Software from the Target System
As user root, erase the migration toolkit software from the system (execute on
both nodes in duplex systems) with the command:
# rpm -e UNSPmigration
Messages similar to the following will be displayed:
Checking rsync package : rsync-<version #>
Migration tools uninstalled successfully.
9.9 Configure the OpenScape Applications Server for Access to the Nodes
Configure the external OpenScape Applications server for access to the two
nodes as follows:
1. Allow remote access for srx account on both nodes. Refer to Section 5.2.6.8,
2. Log in (use the same password for the CMP of the previous release) to the
Common Management Portal.
604
A31003-H8050-J100-09-7631, 09/2011
Configure the OpenScape Applications Server for Access to the Nodes
3. Select the OpenScape Voice tab, List of Switches, and select Switches
Note: It may take some time to display the switch list.
4. Refresh or Add the OpenScape Voice Server in the Applications server List
of Switches.
If you reached this step from one of the following sections, click Edit.
Section 8.7, Upgrading a Standard Duplex System (Toolkit Method)
Section 9.1.1, Simplex to Simplex Hardware Migration
Section 9.1.2, Simplex to Standard Duplex Hardware Migration

(Node Deployment Unchanged)

(Node Deployment Changed)


Section 9.2.1, Simplex to Standard Duplex Product Migration


Section 9.2.4, Standard Duplex Node Redeployment Migration
For all other scenarios, click Add.

Attention: Removing an OpenScape Voice server from a Standard Duplex
(Large or Small) UC Applications deployment will result in the loss of UC
application data (e.g.; OpenScape Users/Resources).
5. Ensure that the required information (e.g. srx password, Node 1/2
6. Click Test Connection.
A31003-H8050-J100-09-7631, 09/2011
605
Configure the OpenScape Applications Server for Access to the Nodes
correctly and use the pam_tally command to resolve the srx user access
violations before you repeat the step.
# pam_tally
User srx
(1522)
has 25
User srx
(1522) had 25
Query the pam_tally count again to ensure there are no pam_tally errors for
the srx user. For example:
# pam_tally
7. If the above test is successful, click Save at the bottom of the form.
Attention: Saving the switch configuration may not be successful the first
time with a Configuration Failed message given due to install key. If
this happens, close the window of the error message and click Save again.
The switch configuration will be successfully saved the second time.
606
A31003-H8050-J100-09-7631, 09/2011
Create the Node.cfg for the Target System (Source system = Low Cost)
9.10 Create the Node.cfg for the Target System (Source system = Low Cost)
Attention: This procedure is intended for the Low Cost to Standard Duplex
Migration only.
Any other migrations should employ Section 9.3, Create the Node.cfg for the
Target System, on page 596.
Section 8.6, Upgrading a Standard Duplex System (SMU Method) should
employ Section 8.3.2, Create the Node.cfg for the Target Release, on page 458.

need to be performed. The SMU upgrade method is detailed in Chapter 8,
Upgrades to OpenScape Voice V5. As a general rule, no changes to the OSCV
target release node.cfg are allowed during the three upgrade procedure detailed
in Chapter 8. After a Chapter 8 upgrade procedure is completed, the EZIP feature
can be employed to establish source based routing (by specifying default
gateway addresses). For more information regarding the EZIP feature, refer to
Chapter F, Updating the Node.cfg File (Also Known as EZIP). Any questions
For the Low Cost to Standard Duplex Migration scenario, it is recommended that
the user create the node.cfg from scratch using the NCPE. Specify the new IP
configuration using the appropriate tabs. The node.cfg collected in Section 8.3.1
on page 456 may be used as a reference for external server IP addresses (e.g.,
Name (DNS), NTP, CSTA, SNMP, License, Billing, SNMP and Misc. Host
servers.)
A31003-H8050-J100-09-7631, 09/2011
607
1. As necessary, format the USB memory stick or sticks. Refer to Appendix G,

Formatting a USB Memory Stick.
2. Insert the OpenScape Voice Installation Wizard CD into the CD/DVD drive
and connect the USB memory stick to a USB port (if the Installation Wizard
does not start automatically, navigate to the bin folder on the CD and
doubleclick ifgui.cmd).
The Installation Framework options screen appears.
3. On the Installation Framework options screen, select Install and click Next,
then select Expert Mode on the next screen.
4. On the Section 1: Configuration and Hardware (1/1) screen, select the values
for the following fields.
Hardware Platform: Select FSC RX 330 S1, FTS RX 200 S6, IBM
x3550M2, IBM x3550M3 or IBM x3650T as appropriate.
Configuration: Select Standard Duplex.
Under Configuration and Hardware (1/1) make sure that the

Installation mode is set to normal.
Node Separation: This field appears only if you selected the duplex
option. Select none for co-located duplex systems. Select the separate
option for duplex systems where the nodes are geographically separated
and require different subnet schemes for the management, signaling, and
billing networks of each node. If you select separate an additional
Cluster Interconnect Type field is shown.
Note: When the separate option is selected, virtual IP migration is not

possible.
608
Survival Authority: This field appears only if you selected the duplex
option. Enter the Survival Authority IP address.
Timezone: Select the appropriate time zone from the drop-down list.
Keyboard: Select the appropriate keyboard language from the drop-down

list.
Stand Alone Service Enabled check box: This box appears only if you
selected the duplex option. Check this box if stand alone service is
desired.
A31003-H8050-J100-09-7631, 09/2011
5. Select Section 2: Cluster Installation (1/1). Enter the Cluster Name and Node
Names.
Note: The convention in this guide for referring to the nodes is as follows:
Node1 refers to the node identified by the node1name parameter value and
Node2 refers to the node identified by the node2name parameter value in
the node.cfg file.
Observe the following when naming the nodes:
The node name should not contain the underscore (_) character (for
example, node1_name). The Installation Wizard will reject a node name
that contains an underscore character.
Do not use the following as node names: Single characters (for example;
a, b, c, 1, 2, 3), dots (...), pri, sec, dev, alias, bond, priv, prim, cluster,
node0, node1, node2, clusternode1, clusternode2, or localhost.
Use only lowercase alphabet and numeric characters (for example;

pchprod1, pchprod2). Do not use any symbols. Node names cannot
begin with a numeric character (for example; 1pchprod), but can use
numeric characters inside or at the end of the name (for example;
pch1prod or pchprod1).
Node names should consist of at least four characters (more than six is
recommended) and can include up to 20 characters.
If you have questions regarding node naming, contact your next level of
support.
6. Select Section 3: IP Configuration (1/6) screen. Enter the IP configuration
parameters for the Management Network, Signaling Network, Billing Network
and Cluster Interconnect Group (CIGroup).
Note: If you selected Separate for the Node Separation parameter there are
2 additional fields (Subnet Node 2 and Netmask Node 2) for each network.
The IP addresses for the second subnet are indicated in these fields. For
example, if the management interface on Node1 is on subnet 1.2.3.0, and the
second subnet is 4, then Subnet Node 2 is 1.2.4.0.
Note: Currently the IMM functionality is only available with the x3250 M3
server configured in a flat network. Address any questions to your next
level of support.
A31003-H8050-J100-09-7631, 09/2011
609
7. Select Section 3: IP Configuration (2/6) screen. These fields should be

automatically updated based on the input in step 6. Verify the IP addresses
indicated are correct in reference to the Subnet and Netmask fields chosen in
step 6.
8. Select Section 3: IP Configuration (3/6) screen. Enter the following
parameters as required.
Assistant values should be automatically populated based on input in

step 5.
DNS Configuration
NTP Configuration (FQDNs or IP addresses)

Note: To change the NTP server or DNS configuration after the system is
placed into service, refer to Appendix F, Updating the Node.cfg File (Also
Known as EZIP). Changing the NTP server or DNS configuration is done
by using the Update option of the EZIP tool as described in Appendix F.
The changes to NTP and DNS parameters will not cause a system
outage.
When opening the EZIP GUI in the Update option, the fields that are
related to NTP and DNS have a blue background color. The colored
background indicates that modification to these fields will not cause a
system outage.
The EZIP tool updates all the files and packet filter rules that relate to the
NTP and DNS parameters and IP addresses.
For the Super User value enter the IP address of the CMP/external
Applications server associated with the OSC voice system.
9. Select Section 3: IP Configuration (4/6) screen. Enter the following

parameters as required.
610
Default Router Node 1 (and Default Router Node 2, if applicable)
CSTA Servers (FQDNs or IP addresses)
Domain Name
Kerberos Realm will be updated based on the Domain Name entered.
A31003-H8050-J100-09-7631, 09/2011
10. Select Section 3: IP Configuration (5/6) screen. If Static/Source Routes exist

please verify there are NO duplicate routes. Duplicate routes will result in
Image installation failures.
Note: If you selected separate for the Node Separation parameter in step 4
on page 36, the NCPE automatically created static routes for each node.
Check (switch to Expert Mode and click the IP Configuration (5/6) tab) the
routes and ensure that they are correct. (refer to Section 2.3, Guidelines for
Static Routes of Geographically Separated Nodes, on page 28). If Static/
Source Routes exist verify there are NO duplicate routes. Duplicate routes
will result in Image installation failures. Duplicate routes should be deleted
using the Delete button (X) provided with each table. A method to verify the
existence of duplicate routes is to employ the Preview mode, which is
accessed by selecting the Preview icon in the NCPE menu bar (or by
selecting the File menu and then Preview).
The NCPE defaults to the signaling subnet gateway as the default route
subnet. If servers have been added to the node.cfg and these servers must
communicate over a subnet other than the default route subnet; add these
static routes at this time. Examples of servers that may require static routes;
A Billing Server may need a static route to transfer data over the billing
subnet.
A SNMP server may need a static route to transfer data (snmp traps) over
the administration subnet to a Network Operations Center.
The destination server IP address.
The destination IP address netmask (typically 255.255.255.255).
For the subnet gateway IP address, refer to IP Configuration page

1/6.
For the SNMP server example the Administration subnet gateway IP

For the Billing server example the Billing subnet gateway IP address
would be employed.
A31003-H8050-J100-09-7631, 09/2011
611

screen as required.
Attention: Ensure that any static routes manually added to the OpenScape
Voice server (not added with the EZIP feature) are included in the static route
table.
For more info regarding the EZIP refer to Appendix F, Updating the Node.cfg
File (Also Known as EZIP) of this document.
11. Select Section 4: IP Security screen (1/3). Enter the following parameters as
required;
SNMP Servers type the IP addresses and ports for the OpenScape
Voice Assistant and for the HISPA server in the SNMP Servers field. Click
the appropriate icon below the table to enter or remove values.
Note: For the HISPA server, the HISPA service uses port 12345.
License Servers (FQDNs or IP addresses)
12. Select Section 4: IP Security screen (2/3). Enter the following parameters as
required;
Billing Servers (FQDNs or IP addresses)
Billing Clients (FQDNs or IP addresses)
Misc Hosts
13. Select Section 4: IP Security screen (3/3). Select the desired SSH Algorithms
from the Algorithms column. The Algorithm order of use can be arranged
with the Up and Down buttons located in the By Order column.
14. Under Additional Parameters (1/1) verify the Software Build ID reflects the
target release version.
15. Check and correct all errors/warnings (all red marked items).
16. Select File, Save As, set File of Type to All Files, and enter File name:
node.cfg.primary for node 1 of the duplex system. Click Save, make note
of the path to which the file was saved and then click OK.
Note: Ensure the file was not saved with a name that has a .cfg extension (for
example: node.cfg.primary.cfg). The file name should be without the
second .cfg extension (in fact: node.cfg.primary).
612
A31003-H8050-J100-09-7631, 09/2011
17. Select File, Save As, set File of Type to All Files, and enter File name:
node.cfg.secondary for the second node of a duplex system. Click Save,
make note of the path to which the file was saved and then click OK.
Note: Ensure the file was not saved with a name that has a .cfg extension (for
example: node.cfg.secondary.cfg). The file name should be without the
second .cfg extension (in fact: node.cfg.secondary).
18. Exit the NCPE. Select File, Exit, Yes, and Finish. Return to the
migration Task list.
A31003-H8050-J100-09-7631, 09/2011
613
614
A31003-H8050-J100-09-7631, 09/2011
ap_basictraffictool.fm
Basic Traffic Tool
Installation (Server)
10 Basic Traffic Tool

The Basic Traffic Tool (BTT) is a performance monitoring tool that helps analyze
performance data for OpenScape Voice. The application has two software
components: server and client.
The server collects data into a csv file every 15 minutes. It runs under a cron
job.
The client, a Windows based JAVA application generates graphical and

numerical data displays using the data in the csv file. An authorized user
opens an SFTP shell and manually transfers the csv file to the PC where the
BTT client is installed.
10.1 Installation (Server)

The BTT Server is installed automatically during the installation of the
OpenScape Voice software and should be available immediately.
The file where the data is collected (/var/tmp/data.csv) is also created
automatically (approximately 15 minutes after installation of the OpenScape
Voice software). After initial creation the file is updated every 15 minutes.
10.2 Installing (Client)

Install the client as follows:
1. From SWS, copy btt<nnnn>.zip (where <nnnn> is the version for BTT, for
example: Version 1.07 is btt0107.zip) to a directory on your PC.
2. Extract the contents of package btt<nnnn>.zip into a directory on the PC.
10.3 Using the Tool

Use the BTT as follows:
1. Open an SFTP shell and connect to the OpenScape Voice system.
2. Copy the file /var/tmp/data.csv to a folder on the PC where the BTT Client is
installed.
3. Start the traffic tool by executing the batch file pmStats.bat.
4. You are prompted to enter the location of the data file (for example, C:/
data.csv).
A31003-H8050-J100-09-7631, 09/2011
615
Basic Traffic Tool
Using the Tool
5. Enter a start date and an end date. The default end date is the current day
and time; the default start date is five days prior to that.
If data exists for the selected period, it will immediately be displayed.
If the input start or end date is invalid, valid data within the input range is
displayed if it is available.
10.3.1 Graphical and Numerical Data Screens

Graphical and numerical data is visible when the user clicks on one of the six
tabs. Table 48 shows the four screens that provide graphical data. Table 49 shows
the two screens that display numerical data.
Screen
Information Provided
Call attempts in selected

period
Displays the call attempts within the user-selected time

period.
Call attempts today
Displays the call attempts for the current day (if available).
Traffic load in selected period Displays the traffic load for the selected period.
Traffic load today
Table 48
Displays the traffic load for the current day (if available).
Graphical Data Presented by the Basic Traffic Tool
Screen
Information Provided
Numerical data in selected

period
Displays data for the user-selected period
Numerical data today
Displays data for the current day (if available).
Table 49
Numerical Data Presented by the Basic Traffic Tool
Numerical data is displayed for the following fields:
Number of calls
Number of incoming calls
Number of outgoing calls
Unsuccessful call attempts
Busy hour call attempts (BHCA)
10.3.2 Menu Structure

Table 50 describes the various menu options.
616
A31003-H8050-J100-09-7631, 09/2011
Basic Traffic Tool
Feature Considerations
Menu
Description
File
A new report may be generated from the File menu without

closing the application. When a new report is generated, the
existing graphs and text areas are removed and new data is
displayed. The user is prompted to enter the data file location.
The print this tab sheet permits output from any of the six
screens to be printed.
Edit
Copy numerical data allows data from the text areas to be copied to
another file, but data cannot be pasted into the text areas because
they can not be edited. Graphical data cannot be saved to a file nor
can it be copied or pasted.
Help
The version number of the application is available.
Table 50
Basic Traffic Tool Menu Structure
10.4 Feature Considerations

The Basic Traffic Tool is not a node failover-safe tool. It is installed on the primary
node of the cluster and will not failover to the secondary node upon primary node
failover.
A31003-H8050-J100-09-7631, 09/2011
617
Basic Traffic Tool
Feature Considerations
618
A31003-H8050-J100-09-7631, 09/2011
eg_instime.fm
Example Install_Time.log
A Example Install_Time.log
The install_time.log (located in the /log directory) holds installation execution
times. Studying the contents of this log file can provide another simple verification
of the installation. The execution times recorded in this file should be consistent
for all installations of Node1 (master node). Node2 will have some variations due
to timing dependencies. An example of the install_time.log follows.
start
stop
start
stop
start
stop
S96configure:
S96configure:
S97provision:
S97provision:
S98buildplus:
S98buildplus:
Wed
Wed
Wed
Wed
Wed
Wed
Dec
Dec
Dec
Dec
Dec
Dec
11
11
11
11
11
11
14:00:37
18:39:43
18:39:43
18:41:22
18:41:22
18:54:01
A31003-H8050-J100-09-7631, 09/2011
EST
EST
EST
EST
EST
EST
2002
2002
2002
2002
2002
2002
619
eg_instime.fm
Example Install_Time.log
620
A31003-H8050-J100-09-7631, 09/2011
x3650T_hardware.fm
IBM x3650T RAID Card Removal Procedure
Overview
B IBM x3650T RAID Card Removal Procedure

B.1 Overview
Because the IBM x3650T is fully assembled by IBM and shipped to Siemens no
assembly instructions for the server platform are normally provided in this guide.
If it is necessary for Siemens technicians to work with components inside the
x3650T, they would normally refer to IBM x3650T documentation for hardware
information. At this time, documentation for the x3650T is not available on the
IBM web site.
For defective x3650T hardware components, Siemens technicians should
contact IBM for service.
B.2 Verify RAID Card Is Installed

The x3650T with a RAID card is no longer a supported configuration. Therefore,
this appendix is being provided temporarily to support the removal of the RAID
card from the system and moving the Quad Ethernet card from the middle PCI
slot to the top PCI slot vacated by the RAID card.
If a RAID card is installed in the x3650T, refer to Section B.3 on page 622 to
remove it. If not, initial step 2 and continue to step 3 on the IBM x3650T Server
Installation Checklist.
RAID card
Figure 14
PCI RAID Card Installed
A31003-H8050-J100-09-7631, 09/2011
621
x3650T_hardware.fm
RAID Card Removal
B.3 RAID Card Removal

B.3.1 Required Tools and Equipment
Phillips #2 screwdriver
A full-height PCI slot filler panel
B.3.2 RAID Card Removal Procedure

Note: Use this procedure to remove the RAID card from the x3650T in a new
installation before you install the software. To remove the RAID card from a
system that has been placed into service, use the MOP (P31003-Q2022-Q102xx-7620) available on G-DMS.
Perform the following to remove the RAID card:

1. Ensure that the AC power cords or DC mains are not connected.
2. While pressing the blue button on the chassis cover, slide the cover towards
the back of the chassis until it stops.
Cover release button
Figure 15
622
Removing the x3650T Cover
A31003-H8050-J100-09-7631, 09/2011
x3650T_hardware.fm
RAID Card Removal
3. Lift the cover up and off the chassis.

Note: Observe safety procedures and electro-static discharge (ESD)
prevention procedures.
4. Disconnect the power connector from the PCI riser card assembly.
Note: Instructions or information provided on equipment labels shall
supersede instructions or information in this procedure if there are
contradictions.
PCI riser card assembly

power connector unplugged
Figure 16
Disconnecting the PCI Riser Card Assembly Power Connector
5. Lift the blue tabs to unseat the PCI riser card assembly from the server board
connectors.
A31003-H8050-J100-09-7631, 09/2011
623
x3650T_hardware.fm
RAID Card Removal
PCI riser card assembly extraction tabs
Figure 17
Removing the PCI Riser Card Assembly
6. Lift the PCI riser card assembly out of the chassis.

7. Place the PCI riser card assembly top-side down on an anti-static mat.
8. Remove the Quad Ethernet card and the RAID card from the PCI riser card
assembly as follows:
a) Remove the screws that secures the card brackets to the PCI riser card
assembly.
b) Loosen the screw that secures the retention bracket to the PCI riser card
assembly and open the retention bracket.
c) Disconnect the cards from the riser card connectors.
9. Attach a full-height PCI slot filler panel to the middle full-height PCI slot with
one screw.
10. Install the Quad Ethernet card into the top slot of the PCI riser card assembly
as follows:
Note: The PCI slots must be populated beginning with the slot furthest from
the server board for proper operation.
624
A31003-H8050-J100-09-7631, 09/2011
x3650T_hardware.fm
RAID Card Removal
a) Insert the Quad Ethernet card into the top connector of the PCI riser card
assembly.
b) Attach the Quad Ethernet card bracket to the PCI riser card assembly with
one screw.
c) Close the retention bracket and secure it to the PCI riser card assembly
by tightening the captive screw.
11. Place the PCI riser card assembly top-side up on the anti-static mat and
ensure that the Quad Ethernet card is in the top slot as indicated in the
following figure.
Figure 18
Quad Ethernet Card PCI Slot Location
12. Place the PCI riser card assembly onto the server board connectors ensuring
that the PCI riser cards align properly with the connectors on the server
board.
A31003-H8050-J100-09-7631, 09/2011
625
x3650T_hardware.fm
RAID Card Removal
13. Ensure that there is only a slight height difference at the three points indicated
in the following two figures.
Check height difference at these points.

Figure 19
PCI Riser Card Assembly Alignment Points
14. Reconnect the PCI riser card assembly power connector.
626
A31003-H8050-J100-09-7631, 09/2011
x3650T_hardware.fm
RAID Card Removal
Check height difference here.
Figure 20

power connector plugged
Connecting the PCI Riser Card Power Connector
15. Seat the riser card connectors into the server board connectors with a firm
tap. Use the bottom of your fist on the top of the PCI riser card assembly as
indicated in the following figure.
Caution: Use the minimum amount of force necessary to seat the riser cards
into the server board connectors. Excessive force might result in damage to
the server board or riser cards.
A31003-H8050-J100-09-7631, 09/2011
627
x3650T_hardware.fm
RAID Card Removal
Tap firmly here.
Figure 21
Seating the Riser Card Connectors
16. Place the cover onto the chassis so that there is approximately an 1/8-inch
gap between the cover and the sheet metal at the front of the chassis.
17. Press down slightly on the cover above the DVD drive area and slide it toward
the front of the chassis until it clicks into place.
step 3.
628
A31003-H8050-J100-09-7631, 09/2011
simplex_to_duplex.fm
IBM x3650T Quad Ethernet Card Installation
Overview
C IBM x3650T Quad Ethernet Card Installation

C.1 Overview
Use the procedure in this appendix to install the Quad Ethernet Card into the
x3650T when upgrading and migrating a single-node system to a redundant
system.
Because the IBM x3650T is fully assembled by IBM and shipped to Siemens, no
assembly instructions for the server platform are provided in this guide. If it is
necessary for Siemens technicians to work with components inside the x3650T,
they would normally refer to IBM x3650T documentation for hardware
information. At this time, documentation for the x3650T is not available on the
IBM web site.
For defective x3650T hardware components, Siemens technicians should
contact IBM for service.
C.2 Quad Ethernet Card Installation

C.2.1 Required Tools and Equipment
Phillips #2 screwdriver
A full-height PCI slot filler panel
C.2.2 Quad Card Ethernet Installation Procedure

Perform the following to install the Quad Ethernet card:
1. Ensure that the AC power cords or DC mains are not connected.
2. While pressing the blue button on the chassis cover, slide the cover towards
the back of the chassis until it stops.
A31003-H8050-J100-09-7631, 09/2011
629
Quad Ethernet Card Installation
Cover release button
Figure 22
Removing the x3650T Cover
3. Lift the cover up and off the chassis.

Note: Observe safety procedures and electro-static discharge (ESD)
prevention procedures.
4. Disconnect the power connector from the PCI riser card assembly.
Note: Instructions or information provided on equipment labels shall
supersede instructions or information in this procedure if there are
contradictions.
630
A31003-H8050-J100-09-7631, 09/2011
PCI riser card assembly power

connector unplugged
Figure 23
Disconnecting the PCI Riser Card Assembly Power Connector
5. Lift the blue tabs to unseat the PCI riser card assembly from the server board
connectors.
A31003-H8050-J100-09-7631, 09/2011
631
PCI riser card assembly extraction tabs
Figure 24
Removing the PCI Riser Card Assembly
6. Lift the PCI riser card assembly out of the chassis.

7. Place the PCI riser card assembly top-side down on an anti-static mat.
8. Loosen and remove the screw that secures the full-height PCI slot filler panel
to the top slot of the PCI riser card assembly and remove the filler panel.
9. Install the Quad Ethernet card into the top slot of the PCI riser card assembly
as follows:
Note: The PCI slots must be populated beginning with the slot furthest from
the server board for proper operation.
a) Loosen the captive screw that secures the retention bracket to the PCI
riser card assembly.
b) Insert the Quad Ethernet card into the top connector of the PCI riser card
assembly.
c) Attach the Quad Ethernet card bracket to the PCI riser card assembly with
one screw.
d) Close the retention bracket and secure it to the PCI riser card assembly
by tightening the captive screw.
632
A31003-H8050-J100-09-7631, 09/2011
10. Place the PCI riser card assembly top-side up on the anti-static mat and
ensure that the Quad Ethernet card is in the top slot as indicated in the
following figure.
Figure 25
Quad Ethernet Card PCI Slot Location
11. Place the PCI riser card assembly onto the server board connectors ensuring
that the PCI riser cards align properly with the connectors on the server
board.
A31003-H8050-J100-09-7631, 09/2011
633
12. Ensure that there is only a slight height difference at the three points indicated
in the following two figures.
Check height difference at these points.

Figure 26
PCI Riser Card Assembly Alignment Points
13. Reconnect the PCI riser card assembly power connector.
634
A31003-H8050-J100-09-7631, 09/2011
Check height difference here.
Figure 27

power connector plugged
Connecting the PCI Riser Card Power Connector
14. Seat the riser card connectors into the server board connectors with a firm
tap. Use the bottom of your fist on the top of the PCI riser card assembly as
indicated in the following figure.
Caution: Use the minimum amount of force necessary to seat the riser cards
into the server board connectors. Excessive force might result in damage to
the server board or riser cards.
A31003-H8050-J100-09-7631, 09/2011
635
Tap firmly here.
Figure 28
Seating the Riser Card Connectors
15. Place the cover onto the chassis so that there is approximately an 1/8-inch
gap between the cover and the sheet metal at the front of the chassis.
16. Press down slightly on the cover above the DVD drive area and slide it toward
the front of the chassis until it clicks into place.
17. Return to the upgrade procedure.
636
A31003-H8050-J100-09-7631, 09/2011
345_reference.fm
IBM xSeries 345 and 346 Wiring Reference
D IBM xSeries 345 and 346 Wiring Reference

Figure 29 shows the connector assignments for the xSeries 345 and Figure 30
shows the connector assignments for the xSeries 346.
Figure 29
Mouse
xSeries 345 Computing Node - Rear View
eth4
eth5
eth0
Power
eth1
eth2
Monitor
eth6
Keyboard
eth7
Figure 30
RSA II Ethernet
(Labelled System Management)
eth3
Rear View for the Duplex (xSeries 346)
A31003-H8050-J100-09-7631, 09/2011
637
345_reference.fm
IBM xSeries 345 and 346 Wiring Reference
638
A31003-H8050-J100-09-7631, 09/2011
Changing_DNS_NTP_Servers.fm
Changing NTP Server or DNS Configurations
E Changing NTP Server or DNS Configurations

Changing the NTP server or DNS configuration is done by using the Update
option of the EZIP tool as described in Appendix F. The changes to NTP and DNS
parameters will not cause a system outage.
When opening the EZIP GUI in the Update option, the fields that are related to
NTP and DNS have a blue background color. The colored background indicates
that modification to these fields will not cause a system outage.
The EZIP tool updates all the files and packet filter rules that relate to the NTP
and DNS parameters and IP addresses.
A31003-H8050-J100-09-7631, 09/2011
639
Changing_DNS_NTP_Servers.fm
Changing NTP Server or DNS Configurations
640
A31003-H8050-J100-09-7631, 09/2011
Updating_the_NodeCfg_File.fm
Updating the Node.cfg File (Also Known as EZIP)
F Updating the Node.cfg File (Also Known as EZIP)

Caution: Changing the node.cfg can have unintended consequences and should
be performed with care. Before beginning, ensure that an up-to-date file system
backup is available and be prepared to do a file system restore in case of any
problems.
The Installation Framework Update (EZIP) did not maintain the Source Based
Routes configuration in V4R1 (and earlier releases). In V5, (and later releases)
the Installation Framework Update (EZIP) DOES MAINTAIN the Source
Based Routes configuration.
Also, save the /etc/hosts file of each node to a safe location. After you
complete the update verify that any user-added entries to the /etc/hosts file were
not removed during the update (or restore). If any user-added entries were
removed, edit the /etc/hosts file and add the missing entries as the last lines in
the file (edit the file in both nodes for redundant systems). An example hosts file
edit is shown below.
Attention: It is a good practice to verify the system Health before an EZIP

configuration change. To access he Node Health function;
1. Navigate to Operation & Maintenance > Configuration & Monitoring >
System Status > Applications.
2. Choose the application of type "OpenScape Voice" from the list (for the
system in which the EZIP will be executed). Click on the arrow at the right
margin of the screen to open the context menu.
3. In the context menu, click Software Activation.
Result: Window Software activation opens.
4. Click Check Node Health in the area Software Updates. This health check
will run on each node of the system. This may take several minutes.
After the Node Health check completes, it is expected that no warnings or error
messages should be present. Do NOT proceed until it is resolved that the
warnings or errors will not affect the EZIP function. Any questions
regarding warnings or error messages should be addressed to your next
level of support.
A PC that has the NCPE software installed and a network connection (one of the
SNMP servers listed in "Section 4: IP Security" of the node.cfg file) can be used
for the Installation Framework (IFgui) update.
A31003-H8050-J100-09-7631, 09/2011
641
Always verify that the IP address of the PC hosting the IFgui is contained in the
node(s) /etc/hosts file before each IFgui update. If the /etc/hosts file does not
contain the IP address of the machine hosting the IFgui, edit the hosts file by
adding the IFgui host PC IP address as the last line of the hosts file. The hosts
file should be edited on each node. As an example, IP address 10.235.200.29
was added to the hosts file:
10.235.54.10
rtp_com0_eth6
10.235.54.30
rtp_com1_eth6
########################################
########################################
10.235.200.230
nmcsnmptrap
10.235.200.29
host_pc
This update will allow the console terminal window on the IFgui host PC to log
activity as the IFgui update (or restore) proceeds. The console terminal window
should not be closed during the IFgui update or restore as it can not be reestablished. The console terminal window will close when the Installation
Framework is closed (steps 8 through 10 on page 643).
Note: For integrated systems only: Before you start the update, open a console
terminal and as user root stop the onboard assistant with the command:
Update the node.cfg file for the OpenScape Voice system as follows:
Note: Performing this procedure will generally cause an outage and should only
be done during a low-traffic period. The exception is when changing parameters
that have a blue background color (e.g., NTP, DNS, etc). Changes to such
parameters will not cause an outage.
1. In the directory where the Installation Wizard/NCPE software is stored,

double-click ifgui.cmd for a Windows system or ifgui for a Linux system.
The Installation Framework options screen is displayed.
2. In the Installation Framework options screen, select Update and click Next.
The Installation Framework - Update Mode screen appears and displays the
Section 1: Cluster Menu window.
3. In the Section 1: Cluster Menu window, enter the requested data:
642
Node 1 Name:
Type the name of the node1.
Username:
Type the name of a predefined RtpAdminCli user (for example:

sysad, sysop1 and so on). Do not use root or srx. The users root
and srx are not typically allowed remote access to the OpenScape
Voice server.
A31003-H8050-J100-09-7631, 09/2011
Password:
Type the password for the user entered in the Username field.
root Pass:
Type the password for the root user.
Node 1 IP:
Insert the IP address of Node1.
Click Next.
The Section 2: Cluster Configuration window is displayed.
4. In the Section 2: Cluster Configuration window, click Edit Current
Configuration and click OK to any messages. The NCPE opens in Expert
Mode and displays the current configuration of the OpenScape Voice system.
5. Make your changes to the current configuration. Some parameter fields are
disabled and cannot be changed.
6. After you are done, save your changes and exit the NCPE tool. The Section
2: Cluster Configuration window is displayed.
7. In the Section 2: Cluster Configuration window, click Apply New
Configuration and click OK to confirm that you want to proceed. A log
console is opened that shows the process of the update.
After the update is complete, a message is shown certifying that all of the
changes were made.
8. Click Back to return to the Section 1: Cluster Menu screen.
9. In the Section 1: Cluster Menu screen, click Finish and then click Yes. The
Installation Framework options screen is displayed.
10. In the Installation Framework options screen, click Finish.
Note: It is a good practice to verify the system Health after a successful EZIP
configuration change. To access the Node Health function;
Navigate to Operation & Maintenance > Configuration & Monitoring

> System Status > Applications.
Choose an application of type "OpenScape Voice" from the list (for the
system that just completed the EZIP successfully). Click on the arrow at
the right margin of the screen to open the context menu.
In the context menu click Software Activation.

Click Check Node Health in the area Software Updates. This health
check will run on each node of the system. This may take several
minutes.
After the Node Health check completes, it is expected that no warnings or

error messages should be present. Any questions regarding warnings or
error messages should be addressed to your next level of support.
A31003-H8050-J100-09-7631, 09/2011
643
11. For integrated systems only: Open a console terminal and as user root enter
the following commands:
# /enterprise/servicetools/install/bin/changeSFWip.sh -c change
12. For an external application server (standard duplex):
For changes to the OpenScape Voice server administration subnet IP

address scheme that would change the node 1 and node 2 administration
IP addresses;
a) Navigate to OpenScape Voice tab-> General->List of Switches
-> Switches, select the checkbox for the updated Voice Server
system.
b) Select the Edit button.
A window titled Edit Switch:<ClusterName> is presented.
c) Select the Change IP address button.
A window titled <ClusterName>-Connection Settings is presented.
d) Update the IP address of the node 1.
e) Select the Test Connection button.
f)
After a successful connection test, select the Save button.

The window titled Edit Switch:<ClusterName> is presented. The IP
address values of node 1 and node 2 will be updated.
g) Select the Save button.

The List of Switches will be presented with the updated IP addresses
of node 1 and node 2.
For changes to the OpenScape Voice server cluster or node names;

a) Navigate to OpenScape Voice tab -> General -> List of Switches > Switches, select the checkbox for the updated Voice Server
system.
b) Select the Refresh button. The Voice server cluster information will
be updated on the List of Switches page.
IF a duplex cluster reconfigures the OpenScape Voice server

administration subnet IP address scheme such that the node 1 and node
2 administration IP addresses change AND that duplex cluster employs
a Standalone Survival Authority;
The assistant file on the Standalone Survival Authority must be
configured with the updated node 1 and node 2 administration IP
addresses. Refer to Section 6.5.2, Installing the Standalone Survival
Authority, steps 2 and 3 for instructions on updating the configuration file.
Any questions can be addressed to your next level of support.
644
A31003-H8050-J100-09-7631, 09/2011
Note: It is a good practice to verify the system Health after a successful

EZIP configuration change. To access the Node Health function;
Navigate to Operation & Maintenance > Configuration &

Monitoring > System Status > Applications.
Choose an application of type "OpenScape Voice" from the list (for

the system that just completed the EZIP successfully). Click on the
arrow at the right margin of the screen to open the context menu.
In the context menu click Software Activation.

Click Check Node Health in the area Software Updates. This

health check will run on each node of the system. This may take
several minutes.
After the Node Health check completes, it is expected that no warnings

or error messages should be present. Any questions regarding
warnings or error messages should be addressed to your next level
of support.
A31003-H8050-J100-09-7631, 09/2011
645
646
A31003-H8050-J100-09-7631, 09/2011
Formatting_USB_Memory_Stick.fm
Formatting a USB Memory Stick
Formatting Procedure
G Formatting a USB Memory Stick

A new, out-of-the-box USB memory stick device usually has multiple partitions.
Even if the USB device is formatted in Windows, these partitions are not
removed. When the node.cfg file is copied onto a device in this state, OpenScape
Voice is unable to detect the node.cfg file during installation.
Therefore, all the partitions of the USB memory stick device must be deleted and
a single partition which constitutes the full memory range of the USB device must
be created. The USB device must then be formatted as a FAT32 file system,
which will insure readability through a Windows operating system.
The following USB memory stick devices have been verified to resolve the issue
described in this chapter. These drives should also be formatted as described in
this chapter to help ensure a successful installation.
8 GB Memorex
1 GB Lexar JD Mercury
256 MB Lexar
256 MB Cruzer Micro
32 MB USB Disk USB 2.0 device (generic - no brand name)
G.1 Formatting Procedure

1. On an existing Linux system or a system booted to Rescue mode using a
OpenScape Voice boot DVD or CD, log in as root and run the following
command:
fdisk -l | grep Disk
Make note of the devices it finds (i.e., /dev/sda, /dev/sdb, /dev/sdc, /dev/sdd,
etc.).
2. Connect the USB flash drive to a USB port and run the command again:
fdisk -l | grep Disk
Make note of the devices again and you should see an additional device. This
additional device should be the USB flash drive. This will be the device to use
for the rest of this procedure. This procedure will use /dev/<sdx>. You need
to replace /dev/<sdx> with the device you noted.
Note: If there is more than one additional device, perform all steps below on
the first additional device and steps 3, 4 and 7 only on any other additional
devices.
A31003-H8050-J100-09-7631, 09/2011
647
Formatting_USB_Memory_Stick.fm
Formatting a USB Memory Stick
Formatting Procedure
3. Use the fdisk utility to modify the partition table in the USB flash drive:
fdisk /dev/<sdx>
4. Delete all of the existing partitions:
Type o and press Enter
5. Create a new partition:
Type n and press Enter
Type p and press Enter
Type 1 and press Enter
Press Enter
Press Enter
6. Toggle the partition type:
Type t and press Enter
Type b and press Enter
7. Write the new partition table and exit the fdisk utility:
Type w and press Enter
8. Format the USB flash drive partition (note the 1 at the end of the device
name):
mkfs.vfat -F 32 /dev/sdx1
9. Remove the USB flash drive.
The USB flash drive is now ready for use. Copy your node.cfg file to the USB flash
drive and follow the OpenScape Voice software installation instructions.
648
A31003-H8050-J100-09-7631, 09/2011
V30_V31_Survivability_Verification.fm
Verifying V3.1R3/V4R1 Survival Authority and IPMI Shutdown Agents
Verifying the V3.1R3 Survival Authority and IPMI Shutdown Agents
H Verifying V3.1R3/V4R1 Survival Authority and IPMI

Shutdown Agents
H.1 Verifying the V3.1R3 Survival Authority and IPMI Shutdown Agents
Use the following sections to verify the Survival Authority and IPMI shutdown
agents and to monitor survival authority activity:
Section H.1.1, V3.1R3 Monitoring the Survival Authority From the Nodes, on
page 649
Section H.1.2, V3.1R3 Examples of SA_die.log and SA_ipmi.log Output, on

page 650
H.1.1 V3.1R3 Monitoring the Survival Authority From

the Nodes
In the case of a standard duplex, it is a prerequisite that the OpenScape
Applications are up and running before using the sdtool utility to monitor the
survival authority status.
In the case of an integrated duplex, the standalone survival authority must be up
and running on a third machine before using the sdtool utility to monitor the
survival authority status.
The sdtool utility can be used to monitor survival authority status from the nodes.
The sdtool utility is the interface tool for the Reliant Cluster Shutdown Daemon
contained within the Reliant Cluster Shutdown Framework product (SMAWsf).
Two helpful sdtool command options are:
-s
Retrieve the status of each Shutdown Agent as a one-time dump in

table format.
-S
Retrieve the status of each Shutdown Agent as a continuous update in

parseable format.
More information regarding the sdtool utility can be found in the man pages (type
man sdtool). Direct any questions regarding the use of the sdtool outside of the
-s and -S options to your next level of support.
For example, display the status of each Shutdown Agent as a one-time dump in
table format as follows:
bocastress1a:~ # sdtool -s
Cluster Host
-----------bocastress1a
Agent
SA State
-----------SA_ipmi Idle
Shut State
---------Unknown
A31003-H8050-J100-09-7631, 09/2011
Test State
---------TestWorked
Init State
--------InitWorked
649
bocastress1a
bocastress1b
bocastress1b
SA_die Idle
SA_ipmi Idle
SA_die Idle
Unknown
Unknown
Unknown
TestWorked
TestWorked
TestWorked
InitWorked
InitWorked
InitWorked
If any of the Agents report a Test State of TestFailed, a manual test for that Agent
can be run (from /opt/SMAW/SMAWsf/bin).
command(s):
For a SA_ipmi failure:
SA_ipmi -d -s <the partner node hostname>
For a SA_die failure:
SA_die -d -s <the node hostname>
the SA_ipmi.log or SA_die.log files). The SA_ipmi.log and SA_die.log files are
located at /var/opt/SMAWsf/log. The log files should be reviewed for information
regarding the cause of the survival authority test failure.
The <the partner node hostname> is the hostname of the cluster partner node.
The <the node hostname> is the hostname of the node from where the test is
being executed.
bocastress1a:/opt/SMAW/SMAWsf/bin # SA_ipmi -d -s bocastress1b
bocastress1a:/opt/SMAW/SMAWsf/bin # SA_die -d -s bocastress1a
H.1.2 V3.1R3 Examples of SA_die.log and

SA_ipmi.log Output
An example of the SA_die.log output for a successful survival authority test
follows. The actual SA_die test command was executed in different session
window (reference command example listed in Section H.1.1). Direct questions
regarding the content of a SA_die.log file to your next level of support. The got
answer TestAck from Quorum Host and result of status test is: 0 are the
expected results of a successful SA_die test.
Note: The tail job indicated will initially print the last ten lines in the SA_die.log
key 4 or 5 times (as indicated by the dots in the following screen snapshot).
bocastress1a:/var/opt/SMAWsf/log #
bocastress1a:/var/opt/SMAWsf/log # tail -f SA_die.log
650
A31003-H8050-J100-09-7631, 09/2011
2008-09-17 10:27:28.863: wait_for_file_entry: waiting for answer from Quorum Host.

2008-09-17 10:27:29.865: wait_for_file_entry: waiting for answer from Quorum Host.
2008-09-17 10:27:30.867: wait_for_file_entry: got no answer from Quorum Host after
15 sec.
2008-09-17 10:27:30.867: result of status test is: 1
2008-09-17 10:27:36.861 WARNING SA_die: Timeout is 20 sec.
.
.
.
2008-09-17 10:38:12.414: Found ip of survival authority: 10.235.200.248.
2008-09-17 10:38:12.414: Found query kind : snmp.
2008-09-17 10:38:12.414: Found community string : public.
2008-09-17 10:38:12.414: Found power option : cycle.
2008-09-17 10:38:12.414: Found cluster name : bocastress1.
2008-09-17 10:38:12.414: tmpHost: bocastress1a, ReplyIp: 10.235.10.10
2008-09-17 10:38:12.414: found entry for host: >bocastress1a<, QuorumIp
>10.235.200.248< echo >1< cycle >1<
2008-09-17 10:38:12.414: tmpHost: bocastress1b, ReplyIp: 10.235.10.30
2008-09-17 10:38:12.414:
Line: bocastress1b

2008-09-17 10:38:12.414: name of local host >bocastress1a<.2008-09-17 10:38:12.414:
Using this as my own IP address: 10.235.10.10.2008-09-17 10:38:12.414: status query
...
2008-09-17 10:38:12.414: snmptrap -v 2c -c public 10.235.200.248 ''
1.3.6.1.4.1.4329.2.18.2.2.1.47.223.1 1.3.6.1.4.1.4329.2.18.2.2.1.47.222.1.0 i 2
1.3.6.1.4.1.4329.2.18.2.2.1.47.222.2.0 s bocastress1a
1.3.6.1.4.1.4329.2.18.2.2.1.47.222.3.0 s bocastress1
1.3.6.1.4.1.4329.2.18.2.2.1.47.222.4.0 a 10.235.10.10
2008-09-17 10:38:17.456: wait_for_file_entry: got answer TestAck from Quorum Host.
An example of the SA_ipmi.log output for a successful survival authority test
follows. The actual SA_ipmi test command was executed in different session
window (reference command example listed in Section H.1.1). The SA_ipmi.log
will contain the userid and password of the remote maintenance controller in
clear text. In this SA_ipmi.log example the userid and password have been
A31003-H8050-J100-09-7631, 09/2011
651
masked with asterisks (*). Direct questions regarding the content of a

SA_ipmi.log file to your next level of support. A zero (0) or OK result is expected
for all of the queries and/or tests of a successful SA_ipmi test.
Note: The tail job indicated will print the last ten lines in the SA_die.log file. To
gain separation from these ten lines and your test output, press the Enter key 4
or 5 times (as indicated by the dots in the following screen snapshot).
bocastress1a:/var/opt/SMAWsf/log # tail -f SA_ipmi.log
written by Eric Young (eay@cryptsoft.com)
Current PowerState is ON
IPMIpower version 1.0.4 Copyright(c) Fujitsu Siemens Computers 2003-2004
This product includes cryptographic software
IPMIpower version 1.0.4 Copyright(c) Fujitsu Siemens Computers 2003-2004
.
.
2008-09-17 16:14:24.809:
Line: bocastress1a cycle
2008-09-17 16:14:24.810: found entry for host: >bocastress1b< cycle >1<
2008-09-17 16:14:24.810: name of local host >bocastress1a<.
2008-09-17 16:14:24.810: Read from Config File, user: USERID
2008-09-17 16:14:24.810: Read from Config File, printDevIp:
10.235.10.21:USERID:********
2008-09-17 16:14:24.810: Read from Config File, DevIp: 10.235.10.21
2008-09-17 16:14:24.810: type ipmitool > /dev/null 2>&1
2008-09-17 16:14:24.814: has_ipmitool is: 0
2008-09-17 16:14:24.814: status query ...
2008-09-17 16:14:25.426: result of ipmipower is: 0
2008-09-17 16:14:25.426: -- stdout for debugging ipmipower -IPMIpower version 1.0.4 Copyright(c) Fujitsu Siemens Computers 2003-2004
Server: 10.235.10.21 User:****** Pass:******** Auth:2 Cmd:0xFF
TimeOut: 1000 Retries: 1 WaitTime: 5 I2C: 0x20 Priv: 3
SEND: IPMI NetFun: 0x06 Lun: 0 CMD: 0x38 (Get Channel Authen. Capabilities)
RCVD: IPMI NetFun: 0x06 Lun: 0 CMD: 0x38 8(30) Bytes - (OK)
SEND: IPMI NetFun: 0x06 Lun: 0 CMD: 0x39 (Get Session Challenge)
SEND: IPMI NetFun: 0x06 Lun: 0 CMD: 0x3A (Activate Session)
RCVD: IPMI NetFun: 0x06 Lun: 0 CMD: 0x3A 10(48) Bytes - (OK)
SEND: IPMI NetFun: 0x06 Lun: 0 CMD: 0x01 (Get Device ID)
INFO: IPMB Dev: 0x20 Rev: 0x01 Prod: 0x0022 from: 0x000157 FW: 0.54
==> Other Controller 0.11.0.3D
SEND: IPMI NetFun: 0x00 Lun: 0 CMD: 0x01 (Get Chassis Status)
SEND: IPMI NetFun: 0x06 Lun: 0 CMD: 0x3C (Close Session)
RCVD: IPMI NetFun: 0x06 Lun: 0 CMD: 0x3C 0(38) Bytes - (OK)
652
A31003-H8050-J100-09-7631, 09/2011
Verifying the V4R1 Survival Authority and IPMI Shutdown Agents
H.2 Verifying the V4R1 Survival Authority and IPMI Shutdown Agents
Use the following sections to verify the Survival Authority and IPMI shutdown
agents and to monitor survival authority activity:
Section H.2.1, V4R1 Monitoring the Shutdown Agents From the Nodes, on
page 653
Section H.2.2, V4R1 Examples of SA_down.log and SA_ipmi.log Output, on

page 654
H.2.1 V4R1 Monitoring the Shutdown Agents From

the Nodes
In the case of a standard duplex, it is a prerequisite that the OpenScape
Applications are up and running before using the sdtool utility to monitor the
survival authority status. Refer to Section 5.2, Installation Instructions for
Applications Servers, on page 308.
In the case of an integrated duplex, a standalone survival authority must be
installed and running on a third machine running SLES 10 SP3 before using the
sdtool utility to monitor the survival authority status. Refer to Section 5.3, Starting
and Stopping the OpenScape Applications, on page 384 for instructions.
The sdtool utility can be used to monitor survival authority status from the nodes.
The sdtool utility is the interface tool for the Reliant Cluster Shutdown Daemon
contained within the Reliant Cluster Shutdown Framework product (SMAWsf).
Two helpful sdtool command options are:
-s
Retrieve the status of each Shutdown Agent as a one-time dump in

table format.
-S
Retrieve the status of each Shutdown Agent as a continuous update in

parseable format.
More information regarding the sdtool utility can be found in the man pages (type
man sdtool). Direct any questions regarding the use of the sdtool outside of the
-s and -S options to your next level of support.
For example, display the status of each Shutdown Agent as a one-time dump in
table format as follows:
root@bocastress1a:[/etc/opt/SMAW/SMAWsf] #73
# sdtool -s
Cluster Host
-----------bocastress1a
bocastress1a
bocastress1b
bocastress1b
Agent
----SA_ipmi
SA_down
SA_ipmi
SA_down
SA State
-------Idle
Idle
Idle
Idle
Shut State
---------Unknown
Unknown
Unknown
Unknown
A31003-H8050-J100-09-7631, 09/2011
Test State
---------TestWorked
TestWorked
TestWorked
TestWorked
Init State
--------InitWorked
InitWorked
InitWorked
InitWorked
653
If any of the Agents report a Test State of TestFailed, a manual test for that Agent
can be run (from /opt/SMAW/SMAWsf/bin).
command(s):
For a SA_ipmi failure:
SA_ipmi -d -s <the partner node hostname>
For a SA_down failure:
SA_down -d -s <the partner node hostname>
the SA_ipmi.log or SA_down.log files). The SA_ipmi.log and SA_down.log files
are located at /var/opt/SMAWsf/log. The log files should be reviewed for
information regarding the cause of the survival authority test failure.
The <the partner node hostname> is the hostname of the cluster partner node.
bocastress1a:/opt/SMAW/SMAWsf/bin # SA_ipmi -d -s bocastress1b
bocastress1a:/opt/SMAW/SMAWsf/bin # SA_down -d -s bocastress1b
H.2.2 V4R1 Examples of SA_down.log and

SA_ipmi.log Output
An example of the SA_down.log output for a successful survival authority test
follows. The actual SA_down test command was executed in different session
window (reference command example listed in Section H.1.1). Direct questions
regarding the content of a SA_down.log file to your next level of support. The got
answer TestAck from Quorum Host and result of status test is: 0 are the
expected results of a successful SA_down test.
Note: The tail job indicated will initially print the last ten lines in the SA_down.log
key 4 or 5 times (as indicated by the dots in the following screen snapshot).
root@bocastress1a:[/var/opt/SMAWsf/log] #98
# tail -f SA_down.log
2009-04-06 14:00:49.985 NOTICE SA_down: do_test: SaQuery returned success.
2009-04-06 14:01:12.493 WARNING SA_down: Timeout is 20 sec.
654
A31003-H8050-J100-09-7631, 09/2011
2009-04-06 14:01:14.601 WARNING SA_down: Timeout is 20 sec.

2009-04-06 14:01:19.988 NOTICE SA_down: do_test: SaQuery returned success.
An example of the SA_ipmi.log output for a successful survival authority test
follows. The actual SA_ipmi test command was executed in a different session
window (reference command example listed in Section H.1.1). The SA_ipmi.log
will contain the userid and password of the remote maintenance controller in
clear text. In this SA_ipmi.log example the userid and password have been
masked with asterisks (*). Direct questions regarding the content of a
SA_ipmi.log file to your next level of support. A zero (0) or OK result is expected
for all of the queries and/or tests of a successful SA_ipmi test.
root@bocastress1a:[/var/opt/SMAWsf/log] #
# tail -f SA_ipmi.log
2009-06-25 14:25:25.414: global Parameter setting:
TestLocalStatus
2009-06-25 14:25:25.414: global Parameter setting for
testLocal: 1
2009-06-25 14:25:25.414: found entry for host: >bocastress1a<
cycle >1<
2009-06-25 14:25:25.414: Line: bocastress1a cycle
2009-06-25 14:25:25.414: name of local host >bocastress1a<.
2009-06-25 14:25:25.414: Read from Config File, user: USERID
2009-06-25 14:25:25.414: Read from Config File, printDevIp:
10.0.42.11:USERID:********
2009-06-25 14:25:25.414: Read from Config File, DevIp:
10.0.42.11
2009-06-25 14:25:25.414: type ipmitool > /dev/null 2>&1
2009-06-25 14:25:25.417: has_ipmitool is: 1
2009-06-25 14:25:25.417: ipmitool -P xyz -V 2>&1
2009-06-25 14:25:25.421: ipmitool version 1.8.9
2009-06-25 14:25:25.422: has_paramP is: 1
2009-06-25 14:25:25.422: status query ...
2009-06-25 14:25:25.422: ipmitool -v -I lan -H 10.0.42.11 -U
USERID -P ##### chassis power status
2009-06-25 14:25:25.452: Chassis Power is on
A31003-H8050-J100-09-7631, 09/2011
655
656
A31003-H8050-J100-09-7631, 09/2011
prep_V4R1_upgrade_second_IP.fm
Removal of Obsolete IP Addresses when Upgrading to V4R1 (or higher releases)
OpenScape Voice V4R1 Solution Matrix
I Removal of Obsolete IP Addresses when Upgrading to

V4R1 (or higher releases)
With the removal of secondary IP addresses, OpenScape Voice Servers installed
as network separated systems, can not be upgraded to V4R1 (or higher releases)
until it is verified that no component in the OSV system network is using IP
addresses that are being removed. All OpenScape Voice customer installations
with network separated systems, configured in load sharing manner, must be
modified to remove obsolete IP addresses used for call processing.
Basic Considerations
1. In V3.1R3, the secondary SIP IP addresses are not active and it has become
a practice to configure in external components (such as RG8700 gateways),
the primary SIP IP address of Node1 and primary SIP IP address of Node2
as the signaling IP addresses of those devices. This configuration was
chosen to provide some level of service for geo-separated systems in the
chance of a network failure.
This document instructs the user to configure devices to no longer use the
primary SIP IP address of Node2 (as it is being removed in V4R1), and to
replace this IP with the secondary SIP IP address of Node 1 (which is not
active in V3.1R3).
Therefore it is highly recommended to make these addressing changes as
close as possible to the night of the upgrade because a network failure with
the signaling address changed prior to the upgrade can lead to a network
outage.
2. If a reconfiguration of the IP addressing scheme in the solution components
is required, firewall settings must be interrogated to ensure that any newly
administered IP addresses will be allowed to be accessed through the
firewall.
3. If DNS SRV is used in the /etc/hosts file, then the /etc/hosts file on
Node1 and Node 2 should be examined to determine if the DNS-SRV entries
need to be updated to reflect the new IP addresses used.
I.1 OpenScape Voice V4R1 Solution Matrix

Note: This table is the OpenScape Voice V4R1 Solution Matrix. A column
indicating whether the component is potentially impacted by the removal of
Secondary IP addresses has been added. If the product is identified as being
impacted, this component must be interrogated for a Network Separated system
prior to the V4R1 upgrade.
A31003-H8050-J100-09-7631, 09/2011
657
Comm. System
Branch Office Gateways
Endpoints
Applications
Table 51
658
Devices potentially impacted by logical node 2 IP removal
Impacted
OpenScape Voice application
yes
(Other 8K connected to upgrading 8k)
yes
Comdasys Convergence 1600, 2600, 3600
yes
HiPath 3000
yes
HiPath 4000
yes
HiPath 4000
yes
Mediatrix 3600, 44xx
yes
OpenBranch
yes
RG 2734
yes
RG 8300
yes
RG 8702, 8708, 8716
yes
OpenScape Personal Edition
yes
OpenStage 15
yes
OpenStage 20E
yes
OpenStage 20, 40, 60, 80
yes
optiClient 130S
yes
optiPoint 410/420 SIP
yes
optiPoint WL2 S
yes
AP 1120
yes
Mediatrix 1204
yes
Mediatrix 14xx, 15xx, 16xx
yes
Mediatrix 41xx
yes
Call Ticket
yes
E/A cockpit,
yes
HiPath ProCenter Attendant Console
yes
HiPath ProCenter Enterprise
yes
HiPath ProCenter Voice Portal
yes
OpenScape ComAssistant
yes
OpenScape Xpressions
yes
Removal of secondary IPs: Impacted components
A31003-H8050-J100-09-7631, 09/2011
Management
Network Products
Media Server
Other
Table 51
Devices potentially impacted by logical node 2 IP removal
Impacted
Accounting Management
no
Deployment Service (DLS)
no
HiPath Fault Management
no
Quality of Service (QoS) Management
no
Common Management Portal (CMP)
no
RG 8700 Assistant
no
OpenBranch Assistant
no
HiPath Assistant
no
Basic Traffic Tool
no
GEM
no
HiPath User Management
no
HLM (CLM)
no
ACME (SBC)
yes
Covergence (SBC)
yes
HiPath Media Server
no
Convedia CMS 3000
no
Convedia CMS 1000
no
IP Unity MS
no
RTT Maintenance server (3306)
no
Removal of secondary IPs: Impacted components
A31003-H8050-J100-09-7631, 09/2011
659
Queries to be Performed on V3.1R3/V4R1 Systems
I.2 Queries to be Performed on V3.1R3/V4R1 Systems

Note: The activities described in this chapter are only required to be performed
on network separated clusters.
The following queries will be performed on all V3.0/V3.1R3/V4 systems that are
configured with network separation.
If the results of the interrogation determine that the customer network is

configured in an unbalanced manner (all devices are configured to use
Node 1 signaling IPs), no further actions will be required.
If the interrogations determine that the customer network is configured in a

balanced manner (some devices are configured to use Node 2 signaling
IPs), then a reconfiguration of these devices must occur prior to proceeding
with the V4R1 upgrade.
This chapter attempts to provide an overview of the solution devices that may be
impacted and examples of identifying the obsolete IPs requiring reconfiguration.
I.2.1 OpenScape Voice System

I.2.1.1 Run Net Sniffer on Each Node
The NetSniffer utility will trace the traffic of an OpenScape Voice Server by
running a tethereal trace on the OSV Server node and capturing messages for
the addresses that are going to be deprecated in V4R1.
The IP addresses to scan are determined by comparing the current node.cfg,
running at the customer site, with a pre-defined list of the obsolete IP aliases. If
traffic is detected that is using these IPs, it is logged in a
capture_traffic_*.cap file. There are ten 5 MB files that are used to
capture this data, the oldest being overwritten.
1. Steps to execute on each node (in / directory, as root ):
tar xvzf NetSniffer.tar.gz
cd NetSniffer
cp /etc/hiq8000/node.cfg /NetSniffer
chmod 777 sniffd
chmod 777 sniff
./sniffd start
660
A31003-H8050-J100-09-7631, 09/2011
2. After the seven day period or a manual halt of the NetSniffer, the
capture_traffic_*.cap files need to be post-processed to determine if
any traffic was detected.
Example of capture files:
captured_traffic_00001_20090918101954.cap
3. At this point, the capture files can be post-processed to determine if any traffic
is being initiated from any of the obsolete IP addresses.
Steps to execute on each node that contains capture files:
chmod 777 /NetSniffer/Post/Processing
cd /NetSniffer/PostProcessing
./post
A file search_these_IPs_in_network.txt will be produced from the capture
files. This file will contain a list of unique IP addresses that are generating
traffic to a OpenScape Voice Server address that will be obsolete in V4R1.
The component/device must be modified to remove this IP and replace with
a valid IP address.
Example output:
10.42.84.100
10.42.81.114
4. After the IPs have been modified and replaced with valid IP addresses, a
second execution of the NetSniffer utility can be performed. In order to
execute this procedure a second time to ensure all invalid IPs have been
removed, the log and text files must be removed.
a) Execute the following to remove the NetSniffer logs and text files:
cd /NetSniffer/PostProcessing
./post clean_all
b) Additionally, the capture files must be deleted.
cd /NetSniffer
./sniffd clean
A31003-H8050-J100-09-7631, 09/2011
661
c) Now the procedure can be repeated from Step 1 on. This time there
should be no capture files created.
5. Additionally, the NetSniffer script should be executed as follows to obtain the
list of obsolete IPs. This list will be used later in this interrogation process to
determine if any IPs need to be removed from the solution component
configurations.
cd /NetSniffer
# ./sniffd show
Result:
cdc_df_vip: 10.236.71.118
ccmdq_1_vip: 10.236.71.113
ccmdq_2_vip: 10.236.71.114
ccmdq_1_vip_2: 10.236.71.114
ccmdq_2_vip_2: 10.236.71.113
smdi_vip: 10.236.71.117
pcmm_ip: 10.236.71.106
pcmm_ip_2: 10.236.71.106
ccm10_1_vip: 10.236.71.107
ccm10_2_vip: 10.236.71.108
ccm10_1_vip_2: 10.236.71.108
ccm10_2_vip_2: 10.236.71.107
ccmtg_1_vip: 10.236.71.111
ccmtg_2_vip: 10.236.71.112
ccmtg_1_vip_2: 10.236.71.112
ccmtg_2_vip_2: 10.236.71.111
sipsm2_vip: 10.236.71.103
sipsm1_vip_2: 10.236.71.103
sipsm4_vip: 10.236.71.105
sipsm3_vip_2: 10.236.71.105
cstasm2_vip: 10.236.71.116
cstasm1_vip_2: 10.236.71.116
ccm05_1_vip_2: 10.236.71.110
ccm05_2_vip_2: 10.236.71.109
Result stored in /NetSniffer/mapping.log!
6. Since the NetSniffer tool will only capture data from addresses that are
actively transmitting traffic, if a deprecated IP address is configured as a
backup IP address on a device, this tool can not detect this scenario. Please
continue execute the following queries.
662
A31003-H8050-J100-09-7631, 09/2011
I.2.1.2 Run DLS Scan

The deployment server will be used to find all the configured phones for the
OpenScape Voice Server system. A scan is requested for specified IP address
ranges and from the scan data, phones that are registered to the SIP addresses
that are to be deprecated can be determined.
Once phones have been identified as being registered to Node2, these devices
must be re-homed to Node1 and begin registering to Node1.
1. At first, run the deployment server and create an IP scanner.
Object --> New
2. Save the new IP scanner.
A31003-H8050-J100-09-7631, 09/2011
663
3. Select the IP Ranges tab and click the Add Entry icon to add the address
ranges of the phones.
664
A31003-H8050-J100-09-7631, 09/2011
4. After all ranges are added and the scanner saved, click the Scan IP Devices
button.
5. The Scan IP Devices dialog appears.
6. Check the Scan IP Devices and Register IP Devices checkboxes.

7. Select the New IP Devices from Scan Results option and the Execute
Autoconfiguration and Excecute AutoDeployment options.
A31003-H8050-J100-09-7631, 09/2011
665
8. Click the OK button. The scan process starts. The progress is indicated.
Note: No devices are displayed during the scan.
666
A31003-H8050-J100-09-7631, 09/2011
9. After the scan has been finished, click the Refresh button.
10. The scan is complete. There are 21 phones in the two IP address ranges in
this example.
A31003-H8050-J100-09-7631, 09/2011
667
11. Select the Read IP Device Data link in the navigation area.
668
A31003-H8050-J100-09-7631, 09/2011
12. Enter the SIP IP addresses into the Reg Address field (must be executed 1
at a time for the two SIP IP addresses) being deprecated.
13. Click the Search button.
A31003-H8050-J100-09-7631, 09/2011
669
14. The Information of one device is displayed.
15. To display all devices, select the Table view.
670
A31003-H8050-J100-09-7631, 09/2011
16. The table view appears. In this example, clearly there are 2 of the 21 phones
registered to 10.236.71.103 (one of the depreciated IP addresses).
17. This address needs to be changed to one of the two valid SIP IP addresses.
A31003-H8050-J100-09-7631, 09/2011
671
I.2.2 Proxies and Gateways Part 1

Phones can be configured behind proxies and gateways. If the NetSniffer did not
detect any problems with traffic coming into addresses that are to be deprecated,
there could still be potential issues with proxies and gateways. For example, a
gateway or proxy may be using a depreciated IP address as a backup server
address.
To determine if proxies and gateways are configured compatibly for the
introduction of V4R1 with regard to the removal of secondary IP addresses, it is
necessary to manually query these elements to determine how they have been
configured.
The pages that follow show examples of configurations using fixed IP addresses
directly entered into the particular devices. However, many proxies and gateways
also support getting this information from a DNS. The use of DNS is discussed in
the section Proxies and Gateways Part 2
I.2.2.1 HiPath 3000 Switch Communicating with OpenScape

Voice Server
If the Alternate RG IP address contains a deprecated SIP IP address, it must be

changed to one of the two valid SIP IP addresses.
672
A31003-H8050-J100-09-7631, 09/2011
I.2.2.2 HG1500 Gateway
I.2.2.3 HiPath 4000 Switch Communicating with OpenScape

Voice Server
The command that needs to be run, via COMWIN, on a HiPath 4000 V4 or V5
system is :
DIS-CGWB:,,SIPTRSSA;
This will generate the following text. REGIP1 and/or REGIP2 indicates what IP
address on the OpenScape Voice Server the gateway register with:
DIS-CGWB:,,SIPTRSSA;
H500: AMO CGWB STARTED
------------------------------------------------------------| CGW BOARD DATA |
------------------------------------------------------------| HG3550 |
------------------------------------------------------------| LTU = 1 SLOT = 79 SMODE = NORMAL POOLNO: 0 |
------------------------------------------------------------SIP TRUNKING DATA FOR SSA
A31003-H8050-J100-09-7631, 09/2011
673
--------------------------SIPREG = YES (NO)

REGIP1 = 172.20.34.96 (0.0.0.0)
PORTTCP1 = 5060 (5060)
PORTTLS1 = 5061 (5061)
REGIP2 = 172.20.34.97 (0.0.0.0)
PORTTCP2 = 5060 (5060)
PORTTLS2 = 5061 (5061)
REGTIME = 310 (120)
------------------------------------------------------------------------------------------------------------------------| HG3550 |
------------------------------------------------------------| LTU = 1 SLOT = 109 SMODE = NORMAL POOLNO: 0 |
------------------------------------------------------------SIP TRUNKING DATA FOR SSA
--------------------------SIPREG = YES (NO)
REGIP1 = 172.20.34.65 (0.0.0.0)
PORTTCP1 = 5060 (5060)
PORTTLS1 = 5061 (5061)
REGIP2 = 172.20.34.165 (0.0.0.0)
PORTTCP2 = 5060 (5060)
PORTTLS2 = 5061 (5061)
REGTIME = 305 (120)
AMO-CGWB -111 CONFIGURATION OF HG3500 BOARD
DISPLAY COMPLETED;
<
If any of these REGIP addresses uses an address that is to be deprecated, it will
need to be changed before the upgrade to V4R1 can proceed.
674
A31003-H8050-J100-09-7631, 09/2011
I.2.2.4 RG8700 Gateways
If the Node 2 IP address contains a deprecated SIP IP address, it must be

changed to one of the two valid SIP IP addresses.
A31003-H8050-J100-09-7631, 09/2011
675
I.2.2.5 RG2700 Gateway
If the Secondary SIP Server IP address contains a deprecated SIP IP address, it

must be changed to one of the two valid SIP IP addresses.
676
A31003-H8050-J100-09-7631, 09/2011
I.2.2.6 OpenScape Branch Configuration
If the Node 2 Primary Server address contains a deprecated SIP IP address, it

must be changed to one of the two valid SIP IP addresses.
A31003-H8050-J100-09-7631, 09/2011
677
I.2.2.7 Mediatrix Gateways
If the Registrar Host IP contains a deprecated SIP IP address, it must be changed

to one of the two valid SIP IP addresses.
678
A31003-H8050-J100-09-7631, 09/2011
I.2.2.8 Comdasys Gateways
The PBX Alias field defines the OpenScape Voice Server IP addressing scheme.
If a deprecated SIP IP address is used, it must be changed to one of the two valid
SIP IP addresses.
A31003-H8050-J100-09-7631, 09/2011
679
I.2.3 Proxies and Gateways Part 2

Any device that can send DNS queries or DNS SRV queries to a DNS server
could obtain a response with an IP address that is going to be deprecated. In
particular, DNS SRV could be a problem if the alternate server IP address was
deprecated because when a failover occurs, the deprecated address would
become active.
Therefore, in customer configurations using FQDNs or DNS SRV, the DNS
should be queried to see if any entries are returning what will potentially become
an invalid address.
This could be done in one of two ways.
1. By issuing manual nslookup commands to the DNS for the FQDNs found in
gateways and proxies.
2. By manually examining the DNS server directly.
For example issuing nslookup commands for an FQDN may give output similar
to the following:
C:\Documents and Settings\Lab PC>nslookup
> bocast04a.sip1.8k.st.lz.com
Server:
Address:
Name:
Address:
UnKnown
10.237.1.3
bocast04a.sip1.8k.st.lz.com
10.237.41.142
> comdasys.st09a.8k.st.lz.com
Server:
Address:
Name:
Address:
UnKnown
10.237.1.3
comdasys.st09a.8k.st.lz.com
10.237.191.20
These commands give the IP addresses associated with two different FQDNs.
One FQDN gives one IP address.
680
A31003-H8050-J100-09-7631, 09/2011
The output below is for two nslookup commands issuing DNS SRV queries:
C:\Documents and Settings\Lab PC>nslookup
*** Can't find server name for address 10.237.1.3:
Non-existent domain
*** Default servers are not available
Default Server:
Address:
UnKnown
10.237.1.3
> set type=srv

> _sip._tcp.ph06a.st.lz.com
Server:
Address:
UnKnown
10.237.1.3
_sip._tcp.ph06a.st.lz.com
SRV service location:
priority
= 1
weight
= 0
port
= 5060
svr hostname
= bocast06a.sip1.8k.st.lz.com
_sip._tcp.ph06a.st.lz.com
priority
= 2
weight
= 0
port
= 5060
svr hostname
= bocast06b.sip1.8k.st.lz.com
bocast06a.sip1.8k.st.lz.com
10.237.61.142
internet address =
bocast06b.sip1.8k.st.lz.com internet address = 10.237.61.143
A31003-H8050-J100-09-7631, 09/2011
681
> _sip._tcp.br09a.st.lz.com
Server:
Address:
UnKnown
10.237.1.3
_sip._tcp.br09a.st.lz.com
priority
= 1
weight
= 0
port
= 5060
svr hostname
= comdasys.st09a.8k.st.lz.com
_sip._tcp.br09a.st.lz.com
priority
= 2
weight
= 0
port
= 5060
svr hostname
= bocast09a.sip1.8k.st.lz.com
comdasys.st09a.8k.st.lz.com internet address = 10.237.191.20

bocast09a.sip1.8k.st.lz.com internet address = 10.237.91.142
This shows which FQDNs are associated with the DNS-SRV.
The first command returns the two addresses of the OpenScape nodes. The
second command returns a proxy address and an OpenScape node address.
682
A31003-H8050-J100-09-7631, 09/2011
I.2.3.1 Examining DNS Server Settings Directly
A31003-H8050-J100-09-7631, 09/2011
683
I.2.3.2 FQDN Example

Devices can be configured to use FQDNs where a simple query to the DNS
server returns one IP address. The example below shows FQDNs set up in the
Comdasys Gateway. You can see FQDNs are configured in the Comdasys device
e.g. bocast06a.sip2.8k.st.lz.com and
bocast06b.sipv2.8kst.lz.com. A manual nslookup will be performed.
684
A31003-H8050-J100-09-7631, 09/2011
I.2.3.3 DNS SRV Example

The DNS-SRV feature is a special DNS service. Some phones (like those in a
small branch office) can send a DNS-SRV request, to the DNS Server. The phone
gets an answer with multiple IP-Addresses, DNS Names and a priority of all SIPServers (SIP-Proxy and the SIP addresses of the OpenScape Voice Nodes).
Normally the SIP-Proxy has the lowest priority value (which is preferred).
The phone uses the SIP-Server with the lowest priority value and sends
registrations and INVITES to this server.
In case of a failure of the first SIP-Server (in this case the proxy) the phone
sends all sip messages to the SIP-Server with the next highest priority value
(in this case the OpenScape Voice).
Below you can see typical settings for a Comdasys proxy set up for DNS SRV.
Example of Comdasys Proxy setup for DNS SRV.
A31003-H8050-J100-09-7631, 09/2011
685
I.2.3.4 Xpressions
Go to Xpression Monitor -> IPAapl -> Advanced Settings -> Device -> SIP
Protocol Stack -> SIP
686
A31003-H8050-J100-09-7631, 09/2011
I.2.3.5 SIP Trunking
A31003-H8050-J100-09-7631, 09/2011
687
688
A31003-H8050-J100-09-7631, 09/2011
I.2.3.6 Convergence
A31003-H8050-J100-09-7631, 09/2011
689
690
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
Media Server Announcements, Treatments and Prefix Access Code Installation Guide
Media Server Provisioning Script Overview
J Media Server Announcements, Treatments and Prefix

Access Code Installation Guide
J.1 Media Server Provisioning Script Overview
In previous releases, MOPs P30310-Q2575-QYYY-XX-7620 and P30310Q2302-QYYY-XX-7620 addressed the Media Server Standard Deployment
configurations. The msconf.sh script, which is now delivered with the OSC Voice
server, replaces the procedures and deliverables of MOPs Q2575 and Q2302.
The table below lists the deployments previously supported by the MOPs and the
sections of this appendix that address those deployments. This section contains
descriptions of the mcsconf.sh script and the provisioning options. Section J.2
through Section J.4 contain examples of the procedures.
For specific information regarding the Media Server, e.g. Packet Filter Rule
requirements, refer to the Media Server Component Release Note (found in the
OpenScape UC Applications release Notes).
Existing MOPs
Standard deployments
currently supported by MOPs
Single MS (CMS)
Configuration script
for Media Server
P30310-Q2302
Installation of iMS
HMS treatments
P30310-Q2575
New msconf.sh script
Section K.2
script options: 41, 11
this document: 4.1
integrated simplex
(ON-board with iMS)
standard co-located cluster

(OFF-board with one HMS)
standard co-located cluster

(OFF-board with two HMS)
Section K.3
this document: 4.2
standard geo-separated cluster

(OFF-board with HMS)
Section K.4
this document: 4.3
A31003-H8050-J100-09-7631, 09/2011
691
MS_announcements.fm
J.1.1 Media Server Provisioning Script

msconf.sh is a tool for working with treatments. For running it, login as srx user
and give the following commands:
cd /unisphere/srx3000/srx/ms_scripts
./msconf.sh
Note: Use this link to return to Step 21 in the Installation Checklist.
J.1.2 General
This script allows you to perform a number of media server treatment provisioning
operations.
Treatments are essentially a way of setting the announcements that are to be
played by the system at various points. Each treatment is associated with an
intercept. An intercept may be associated with up to three treatments, each of
which will have a different treatment order. The treatment order is what
determines the order with which treatments will be executed.
When we refer to "default treatments", we mean all treatments that are part of the
official system provisioning. Any treatments that are not part of the official
provisioning (for instance treatments assigned by an administrator for a specific
customer) are considered as non-default/custom. The intercepts which
correspond with the default set of treatments are pre-installed on the system. This
discrimination between default/non-default treatments is used in a number of
options provided by this script in order to define which treatments should be
added or removed.
Treatments are assigned to a destination. This named destination corresponds to
one of four available media server destination types. Each of the four destination
types corresponds to a certain media server deployment.
Intercept
|
|
V
Treatments assigned for
intercept (up to three)
|
|
V
Destination
692
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
J.1.3 The Four Destination Types and a short

Explanation of the Equivalent Media Server
Deployment:
Centralized Deployment for Single MS: This destination type should be used
when only one media server GW is required. Treatments route directly to a
single media server GW. The destination name in this case is the name of the
media server GW.
Centralized Deployment for Destination: This destination type should be

used when multiple media server GWs with redundancy or load balancing are
required. Treatments are assigned to a destination with routes for all the
media servers. The destination name in this case is the name of the
destination that holds the routes to the media server GWs.
Origin Destination for Routing Area: This destination type should be used for
routing using rate areas (subscriber or location). Treatments are assigned to
an origin destination with routes for all
serving rate areas. The destination
name in that case is the name of that origin destination.
Origin Destination for Branch Offices: This destination type should be used
for branch office deployments. Treatments are assigned to a pre-existing
origin destination with routes for all serving branches. In this case, there is no
need for any user input, as long as the origin destination pre-exists.
More details regarding available media server deployments is provided in the

relevant section of the customer documentation.
J.1.4 Explanation of each of the Options Offered by

the msconf.sh script
J.1.4.1 Option 11 Assign all default (restore)
This option will assign the full set of default treatments to the destination type and
name defined by the user. Any existing or modified default treatment will be
overwritten. Any existing non-default treatment will be modified to the same
destination type and name, as defined by the user.
J.1.4.2 Option 12 Assign missing default

This option will assign the full set of default treatments to the destination type and
name defined by the user. Any existing treatment (both default and non-default)
will be modified to the same destination type and name, as defined by the user.
A31003-H8050-J100-09-7631, 09/2011
693
MS_announcements.fm
No other modification (other than destination type and name) will be performed
to the existing treatments.
By entering the same treatment destination type and name as the one currently
provisioned on your system, no modifications will be made to your existing
treatments.
J.1.4.3 Option 21 Remove all default

This option will remove all default treatments. Any existing non-default treatment
will not be removed or modified.
J.1.4.4 Option 22 Remove all treatments

This option will remove all existing treatments (default or non-default) from the
system.
J.1.4.5 Option 31 Modify destination

This option will modify all existing treatments (default or non-default) to the
destination type and name defined by the user.
No other modification (other than destination type and name) will be performed
on the existing treatments.
J.1.4.6 Option 41 Centralized Deployment - Single MS

This option allows the user to install or uninstall a Single MS configuration
consisting of a media server with all the corresponding circuits.
J.1.4.7 Option 42 Centralized Deployment - Destination

This option allows the user to install or uninstall a Destination MS configuration.
This configuration consist of a destination with two prioritized routes to the
specified media servers and all the corresponding circuits for these two media
servers.
J.1.4.8 Option 43 Distributed Deployment - Routing Area

This option allows the user to install or uninstall a Routing Area MS configuration.
694
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
This configuration consists of an origin destination and two routing areas, one
destination for each routing area and a route to each of the specified media
servers announcement circuits.
J.1.4.9 Option 81 Collect MS provisioning information

This option will export all MS related provisioning. All exported files are added to
a file named mediaServerProvisioning.zip. The exported files can either be used
to restore provisioning at a later time, or for gathering media server provisioning
information so that it can be used for troubleshooting problems. The .zip file
includes a soapExport format provisioning file for each of the following:
Media gateways
Media gateway circuits
Treatments
Intercepts
Destinations
Origin destinations
Routes
Origin Routes
Branches
Rate areas (routing areas)
J.1.4.10 Option 82 Update MS treatment provisioning

This option will perform any necessary actions to upgrade your existing MS
treatment provisioning to the latest valid one.
Note: This action does not perform complete treatment provisioning. It only
upgrades a previously complete treatment provisioning to the latest valid one.
This is not required if regular upgrade procedures have been followed.
A31003-H8050-J100-09-7631, 09/2011
695
MS_announcements.fm
Centralized Deployment for Single MS
J.2 Centralized Deployment for Single MS

J.2.1 Media Server Provisioning
The script will request a signaling IP address for the MS. For external (offboard)
servers the signaling IP is typically the eth0 address of the external (offboard)
server.
For simplex or Low Cost OpenScape Voice servers, the signaling IP will be the IP
address assigned to node 1 of nafo1 of the node.cfg. In the following example,
1.2.3.4 is the nafo1 node 1 IP (this example is an excerpt of the nafo configuration
from a Low Cost node.cfg);

Next Step: K.2.2
Description: Creation of a single Media Server with all the corresponding circuits
(ann/$, cnf/$, es/$, aud/$)
OSV Server: execute msconf.sh script located in:
/unisphere/srx3000/srx/ms_scripts
Hint: An example of the provisioning for this deployment is shown below.
Expected user input is in bold.
Script execution (User prompts are marked with bold):
srx@grd410n1:[/unisphere/srx3000/srx/] #2931
$ cd /unisphere/srx3000/srx/ms_scripts
srx@grd410n1:[/unisphere/srx3000/srx/ms_scripts] #2932
$ ./msconf.sh
Assign Treatments
11. Assign all default (restore)
12. Assign missing default
Remove Treatments
21. Remove all default
22. Remove all treatments
Modify Treatments
696
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
31. Modify treatment destination

MS Provisioning Examples
41. Centralized Deployment - Single MS
42. Centralized Deployment - Destination
43. Distributed Deployment - Routing Area
Miscellaneous
81. Collect MS provisioning information
82. Update MS treatment provisioning
98. Help
99. Exit
Selection:
41
This option allows the user to install or uninstall a Single MS
configuration consisting of a media server with all the
corresponding circuits.
Do you want to assign or unassign a Single MS configuration? [1
| 2]
1
What is the signaling IP of your Single MS?
10.4.255.100
What is the media server name for the Single MS?
---------------------------------------------------------------Hint: This name will be used in Appendix J.2.2, Treatments Assignment.
This hint is a document note and not part of the actual ms.conf script output.
---------------------------------------------------------------HMS
Performing provisioning, please wait...
....
Finished assigning media server configuration.
Press Enter to go back to the menu.
J.2.2 Treatments Assignment

Previous Step: K.2.1
Description: The intercepts that are already preinstalled in the system must be
linked to the corresponding treatments and routed to the destination previously
created.
OSV Server:execute script located in: /unisphere/srx3000/srx/ms_scripts
A31003-H8050-J100-09-7631, 09/2011
697
MS_announcements.fm
Hint: The default configuration values are available in the screenshot below.
$ ./msconf.sh
Assign Treatments
Remove Treatments
Modify Treatments
Miscellaneous
98. Help
99. Exit
Selection:
11
This option will assign the full set of default treatments to
the destination name and type defined by the user.
Any existing or modified default treatment will be overwritten.
Any existing non-default treatment will be modified to the same
destination name and type, as defined by the user.
Choose the type of MS treatment provisioning you would like to
perform (enter 99 to go back to the menu):
4. Distributed Deployment - Branch Office
698
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
Selection [ 1 - 4 ]:
1
Enter the name of the Media Gateway you want to assign the
treatments to (enter 99 to go back to the menu):
---------------------------------------------------------------Hint: This is the Media Server name used in Appendix J.2.1, Media Server
Provisioning. This hint is a document note and not part of the actual ms.conf
script output.
---------------------------------------------------------------HMS
Would you like to create a backup of your current treatments
before proceeding? [y | n]
y
Exported soapMassProv treatments file to the location:
/unisphere/srx3000/srx/ms_scripts/exports/exportedTreatments_0308-10__18_51_01
Are you sure you want to proceed? [y | n]
y
A31003-H8050-J100-09-7631, 09/2011
699
MS_announcements.fm
Centralized Deployment for Destination MS
J.3 Centralized Deployment for Destination MS

Note: The script will request a signaling IP address for the MS. For external
(offboard) servers the signaling IP is typically the eth0 address of the external
(offboard) server.

Next Step: K.3.2
Description: Creation of 2 Media Servers with all the corresponding circuits (ann/
$, cnf/$, es/$, aud/$). A destination will also be created with a route to each
desired Media Server announcement circuit in use.
OSV Server: Execute msconf.sh script located in:
Please note that the default destination is created with the name MS_dest.
$ ./msconf.sh
Assign Treatments
Remove Treatments
700
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
Modify Treatments
Miscellaneous
98. Help
99. Exit
Selection:
42
This option allows the user to install or uninstall a
Destination MS configuration.
This configuration consist of a destination with two prioritized
routes to the
specified media servers and all the corresponding circuits for
these two media servers.
Do you want to assign or unassign a Destination MS
configuration? [1 | 2]
1
What is the signaling IP for MS 1?
10.4.255.100
What is the signaling IP for MS 2?
10.4.255.106
What is the media server name for MS 1?
iMS1
What is the media server name for MS 2?
iMS2
Enter the name for the destination:
A31003-H8050-J100-09-7631, 09/2011
701
MS_announcements.fm
---------------------------------------------------------------Hint: This name will be used in Appendix J.3.2, Treatments Assignment. This
hint is a document note and not part of the actual ms.conf script output.
---------------------------------------------------------------MS_dest
....
Press Enter to go back to the menu.

linked to the corresponding treatments and routed to the destination previously
created.
$ ./msconf.sh
Assign Treatments
Remove Treatments
Modify Treatments
Miscellaneous
702
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm

98. Help
99. Exit
Selection:
11
This option will assign the full set of default treatments
to the destination name and type defined by the user.
Choose the type of MS treatment provisioning you would
like to perform (enter 99 to go back to the menu):
2
Enter the name of the Destination you want to assign
the treatments to (enter 99 to go back to the menu):
---------------------------------------------------------------Hint: This is the destination name used in Appendix J.3.1, Media Server
script output.
---------------------------------------------------------------MS_dest
Would you like to create a backup of your current
treatments before proceeding? [y | n]
y
y
A31003-H8050-J100-09-7631, 09/2011
703
MS_announcements.fm
Distributed Deployment for Subscribers with Routing Areas
J.4 Distributed Deployment for Subscribers with Routing Areas

Note: The script will request a signaling IP address for the MS. For external
(offboard) servers the signaling IP is typically the eth0 address of the external
(offboard) server.

Next Step: K.4.2
Description: An Origin Destination will be created and routes to the Destinations
according to Routing Areas will be added. It is recommended to create also
manually a route with no Routing Area for serving the subscribers with no RA This
route could point to a default destination that serves only subscribers with no RA
or to any of the other existing destinations.
OSV Server: Execute msconf.sh script located in:
Expected user input is in bold. Please make sure that you use "names" for
destinations, routing areas etc, without spaces -or- special characters. Otherwise
error will occur.
$ ./msconf.sh
Assign Treatments
704
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm

Remove Treatments
Modify Treatments
Miscellaneous
98. Help
99. Exit
Selection:
43
This option allows the user
Area MS configuration. This
destination and two routing
routing area and a route to
announcement circuits.
to install or uninstall a Routing

configuration consists of an origin
areas, one destination for each
each of the specified media servers
Do you want to assign or unassign a Routing Area MS

configuration? [1 | 2]
1
What is the ip for iMS/HMS (nafo1/eth0) at node 1?
10.4.255.100
What is the ip for iMS/HMS (nafo1/eth0) at node 2?
10.4.255.106
What is the MediaServer Name for node 1?
MS1
What is the MediaServer Name for node 2?
MS2
Enter the name for destination 1:
MS_Dest1
Enter the name for destination 2:
MS_Dest2
Enter the name for the routing area you want to create for node
1:
A31003-H8050-J100-09-7631, 09/2011
705
MS_announcements.fm
Athens
Enter the digits of the office code of the subscribers in node 1
associated with the above routing area:
210400
Enter the name for the routing area you want to create for node
2:
Brazil
Enter the digits of the office code of the subscribers in node 2
associated with the above routing area:
210500
Enter the name for the origin destination:
---------------------------------------------------------------Hint: This name will be used in Appendix J.4.2, Treatments Assignment. This
hint is a document note and not part of the actual ms.conf script output.
---------------------------------------------------------------orig_dest
....
Press Enter to go back to the menu..

linked to the corresponding treatments and routed to the origin destination
previously created.
$ ./msconf.sh
Assign Treatments
706
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
Remove Treatments
Modify Treatments
Miscellaneous
98. Help
99. Exit
Selection:
11
This option will assign the full set of default treatments
to the destination name and type defined by the user.
Choose the type of MS treatment provisioning you would
like to perform (enter 99 to go back to the menu):
3
Enter the name of the Destination you want to assign
the treatments to (enter 99 to go back to the menu):
A31003-H8050-J100-09-7631, 09/2011
707
MS_announcements.fm
---------------------------------------------------------------Hint: This is the origin destination name used in Appendix J.4.1, Media Server
script output.
---------------------------------------------------------------orig dest
Would you like to create a backup of your current
treatments before proceeding? [y | n]
y
y
708
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
How to Add/Delete Default Siemens PACs for Vertical Services
J.5 How to Add/Delete Default Siemens PACs for Vertical Services

A configuration script (pac.sh) for the provisioning of the default Siemens
Services Prefix Access Codes (PACs) is delivered with new/fresh OpenScape
Voice V5 installations. This script is available at software version level
V5.00.01.ALL.11_PS0004 (and higher).
J.5.1 Add Default Siemens PACs for Vertical Services

Using the pac.sh Script
For Integrated Simplex or Standard duplex (Co-located or Geo separated
deployments) run the following commands from node 1 (as the srx user);
su - srx
cd /unisphere/srx3000/srx/bin
./pac.sh
Note: There is a period proceeding the forward slash (/) in the third command
example.
You will be asked for the action you want to perform; create (c) PACs, delete (d)
PACs, and the Numbering Plan (NP) name in which you wish to delete the PACs.
In this case create (c) PACs is the correct choice.
The pac.sh script accepts a Private Numbering Plan (PNP) Name as an optional
input.
If the PNP Name IS NOT PROVIDED, the script adds the default PACs to the
E164 NP.
If the PNP Name IS PROVIDED, the script adds the default PACs to the
specified PNP.
Note: If the basic Business Group has already been provisioned, the PNP name
can be found through the OpenScape Voice Assistant > Business Group >
Private Numbering Plans.
If you choose to create the PACs for the default E164 NP, you will need to create
the needed *,**, # PACs and reference them to the E164 NP (in each working
BG).
Examples are provided in the following snapshots (the user interface may change
in later versions of the OpenScape Voice (OSV) Assistant);
A31003-H8050-J100-09-7631, 09/2011
709
MS_announcements.fm
PAC * create;
...
710
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
PAC ** create;
...
A31003-H8050-J100-09-7631, 09/2011
711
MS_announcements.fm
PAC # create;
712
A31003-H8050-J100-09-7631, 09/2011
MS_announcements.fm
J.5.2 Delete the Default Siemens PACs (Prefix Access

Codes) for Vertical Services Using the pac.sh Script
For Integrated Simplex or Standard duplex (Co-located or Geo separated
deployments), run the following commands from node 1 (as the srx user);
su - srx
cd /unisphere/srx3000/srx/bin
./pac.sh
Note: There is a period proceeding the forward slash (/) in the third command
example.
You will be asked for the action you want to perform; create (c) PACs, delete (d)
PACs, and the Numbering Plan (NP) name in which you wish to delete the PACs.
In this case, delete (d) PACs is the correct choice.
The pac.sh script accepts a Private Numbering Plan (PNP) Name as an optional
input.
If the PNP Name IS NOT PROVIDED, the script removes the default PACs
from the E164 NP.
If the PNP Name IS PROVIDED, the script removes the default PACs from the
specified PNP.
Note: If the basic Business Group has already been provisioned, the PNP name
can be found through the OpenScape Voice Assistant > Business Group >
Private Numbering Plans.
If you chose to create the PACs *, ** and # (referencing them to the E164 NP) in
each working BG; these PACs should be deleted using the OpenScape Voice
(OSV) Assistant.
A31003-H8050-J100-09-7631, 09/2011
713
MS_announcements.fm
714
A31003-H8050-J100-09-7631, 09/2011
graceful_shutdown.fm
Configuring the OSV Nodes for Shutdown
Overview
K Configuring the OSV Nodes for Shutdown

K.1 Overview
Before rebooting or shutting down the voice server node(s), the system must be
configured to state 2. After the node(s) are at state 2, they can be rebooted or
shutdown.
Note: The commands are to be executed as user "root".
K.2 Shutting Down the Node(s)

For integrated systems, begin at step 1.
For a standard duplex system, begin at step 2.
1. For integrated systems, stop Symphonia with this command (as user root):
root@fsc301:[~] #1000
2. As user root, from the node that will be shutdown, configure the node to state
2 as indicated:
Duplex systems. Examples for each node follow:
Attention: For a correctly configured duplex system, each node can be
configured individually without a loss of call processing. If you need call
processing to remain active, do not shutdown both nodes of a duplex
system at the same time.
Duplex system node 1, from node 1;
root@fsc301:[~] #910
# /unisphere/srx3000/srx/startup/srxctrl 2 nc
or
Duplex system node 2, from node 2;
root@fsc302:[~] #910
# /unisphere/srx3000/srx/startup/srxctrl 2 nc
A31003-H8050-J100-09-7631, 09/2011
715
graceful_shutdown.fm
Configuring the OSV Nodes for Shutdown
Shutting Down the Node(s)
Simplex systems:
Attention: For a simplex system this step will result in a complete loss of
OSV call processing for the duration of the process.
root@fsc301:[~] #910
--- srxctrl ended on Wed May 27 13:52:27 2009 --3. Verify the status of the nodes (or node for simplex systems) with the
command:
root@fsc301:[~] #911
It is expected that the nodes (or node for simplex systems) will be at state 2
at this time.
4. From the console of each node, the voice server node can now be 'rebooted'
or shutdown. Execute the commands as user root.
Example command syntax for reboot;
# reboot
Example command syntax for shutdown;
# shutdown -h -g0 -tnow -y
If a node is 'shutdown,' it can be restored by powering on the voice server. Use
the power button to power up a server. It is expected the node (or nodes) should
be at state 4 when the system displays a message similar to this:
--- srxctrl ended on Wed May 27 13:52:27 2009 --Note: If the node(s) were shutdown for maintenance it is a good practice to run
RapidStat after they are restored (to verify the node health state).
716
A31003-H8050-J100-09-7631, 09/2011
hp8000_signaling_stream_security.fm
OpenScape Voice Signaling Stream Security
TLS Overview
L OpenScape Voice Signaling Stream Security

This chapter describes signaling stream security for OpenScape Voice itself.
L.1 TLS Overview

The TLS protocol allows applications to communicate across a network in a way
designed to prevent eavesdropping, tampering, and message forgery. TLS runs
on OSI layers beneath application protocols such as HTTP, SOAP, and SIP, and
above a reliable transport protocolfor example, TCP. It does not run over UDP.
Only the server is authenticated using TLSfor example, its identity is ensured
while the endpoint is authenticated using a method other than TLS. This means
that the end user (whether an individual phone, gateway, or application such as
a Web browser) can be sure with whom it is communicating using TLS with
unilateral authentication.
In OpenScape Voice, phones use TLS to authenticate the OpenScape Voice
server; they then authenticate themselves to the OpenScape Voice server using
digest authentication.
As shown in Figure 31, the client always establishes the TLS session. After it is
negotiated successfully, the OpenScape Voice server challenges it for a digest
login, realm, and password. The connection is established by the phone on
power-up; the TLS credentials are cached after successful negotiation to avoid
call setup times being delayed later.
The client sends keep-alive packets to the server to ensure the server is still
there. If it does not receive a response, it will reconnect to the next server in its
list of DNS-SRV1 servers for redundancy and failover purposes.
Figure 31
Authentication Between TLS Client and OpenScape Voice Server
On server-to-server interfaces, such as a SIP-NNI connection between two

OpenScape Voice servers, or between an OpenScape Voice server and a thirdparty server such as IBMs SameTime, a TLS connection with mutual
authentication is used to bilaterally authenticate the connection in both directions.
This means each machine can act as either a client or a server for the connection
setup. However, only one connection can be in place at a time.
A31003-H8050-J100-09-7631, 09/2011
717
TLS Overview
Figure 32 shows authentication between two OpenScape Voice servers. The

origin of the traffic determines which OpenScape Voice server acts as a TLS
client and which as a TLS server, as follows:
If the traffic originates in the USA, the server in the USA is the TLS client and
the server in Germany is the TLS server. This is illustrated by the upper
connection shown in Figure 32.
If the traffic originates in Germany, the server in Germany is the TLS client
and the server in the USA is the TLS server. This is illustrated by the lower
connection shown in Figure 32.
Because a new connection can be established, there is no need for a keep-alive

heartbeat mechanism in a TLS connection with mutual authentication. If a
connection were to drop, the next packet that is sent instantly initiates the
establishment of a new connection.
Figure 32
Mutual Authentication Between Two OpenScape Voice Servers
L.1.1 Endpoint Signaling

OpenScape Voice supports SIP signaling to endpoint devices.
OpenScape Voice supports digest authentication for all SIP endpoint devices in
accordance with Internet Engineering Task Force (IETF) Request for Comment
(RFC) 3261, Session Initiation Protocol (SIP), June 2002. In addition, for SIP
endpoint devices that use TCP instead of UDP, OpenScape Voice also supports
secure SIP using TLS to protect the SIP signaling connection.
L.1.1.1 TLS Protection of Endpoint SIP Signaling

Using OpenScape Voices back-to-back user agent architecture, TLS can be
individually enabled or disabled on the SIP signaling connection between the
OpenScape Voice SIP signaling manager and each SIP endpoint device.
Because TLS is applied on a hop-by-hop basis, end-to-end signaling security is
provided when all hops of the signaling connection use TLS or an equivalent
security mechanism, such as IPsec for MGCP signaling connections.
718
A31003-H8050-J100-09-7631, 09/2011
TLS Overview
End-to-end signaling security can be ensured in a customers OpenScape Voice

network by configuring security on all of the signaling interfaces. Also, when the
SIPS uniform resource identifier (URI) is used by the originating endpoint to
specify the called party, the OpenScape Voice system blocks the call when
signaling security is not available on every hop from the originating endpoint to
the last hop serving the terminating endpoint within the same administrative
domain. Signaling security cannot be guaranteed for calls that leave the
administrative domain of the customers OpenScape Voice network.
A server-side certificate is used on OpenScape Voice to permit the SIP endpoint
device to authenticate OpenScape Voice when the endpoint device establishes
its TLS connection to the OpenScape Voice SIP signaling manager. OpenScape
Voice authentication of the endpoint device is provided by applying SIP digest
authentication when the endpoint device registers with OpenScape Voice.
Warning: OpenScape Voice complies with the TLS security mechanism as
defined in IETF RFC 3261 for SIP, including section 26.3.2.1, which requires the
SIP proxy to reuse the TLS connection that is established by the SIP endpoint.
Therefore, use of TLS for SIP signaling requires a persistent (full-time) signaling
connection be established between OpenScape Voice and the SIP endpoint.
IETF RFC 3261 does not require SIP endpoints to support TLS server
functionality; thus, the TLS connection must always be established from the SIP
endpoint to OpenScape Voice. It is not possible for OpenScape Voice to reestablish the TLS connection toward the SIP endpoint if it fails. Therefore, the
responsibility to keep the TLS connection open and to re-establish the connection
if it fails rests solely with the SIP endpoint. If the TLS connection fails, OpenScape
Voice cannot deliver SIP messages to the SIP endpointfor example, it cannot
deliver an incoming call to the SIP endpoint.
The two servers of the OpenScape Voice system are referred to as node 1 and
node 2. OpenScape Voice is capable of operating in both an active-active
configuration and active-standby configuration.
In the active-active configuration, roughly half of the phones are registered on
each node, during normal operation. This is controlled by setting the appropriate
registrar address within each phone. In the active-standby configuration, all
phones are registered to one node, during normal operation. In both
configurations, in the event of a node failure, the remaining node will assume
control of all phones.
There are two specific customer configurations in which active-standby operation
is required:
If TLS transport is in use to any SIP phones or endpoints
If the system is supporting one or more branch locations operating behind a

survivable SIP proxy serverfor example, OpenScape Branch.
A31003-H8050-J100-09-7631, 09/2011
719
TLS Overview
In either of these customer configurations, the OpenScape Voice system must be

operated in the active-standby configuration, with all phones and gateways
registered on node 1.
Note: These restrictions will be removed in V4R1.
It is the responsibility of the TLS client (the SIP endpoint) to detect and recover
the TLS connection whenever it fails. Therefore, the SIP endpoint must monitor
the TLS connection to detect a loss of signaling communication with the
OpenScape Voice server.
OpenScape Voice supports a rapid recovery mechanism for TLS connections.
This mechanism is only supported for Siemens SIP endpoints that also support
this mechanism.
The rapid recovery mechanism is based on a frequent connectivity check (keepalive message) the SIP endpoint sends to OpenScape Voice. The interval of the
connectivity check is provisioned in the SIP endpoint. The connectivity check is
successful if the SIP endpoint receives back the identical message within five
seconds.
The OpenScape Voice server responds to the keep-alive message when it is
received. If the SIP endpoint fails to receive the response within five seconds, it
repeats the keep-alive message. If a response is still not received after the
number of attempts indicated by the specific phone device, the SIP endpoint
considers the TLS connection to be failed, then establishes a new TLS
connection.
To allow the Siemens SIP endpoints that support rapid recovery of TLS
connections to determine when it is connected to a HiPath version that also
supports this mechanism, OpenScape Voice includes a server version in its
response to the SIP REGISTER message. The following conditions must be
present:
The SIP signaling manager must be provisioned to include the server version
in its response to the SIP REGISTER messages. Refer to the OpenScape
Voice Configuration Manual: Volume 2, Configuration and Administration
Using CMP and Assistant Plug-Ins.
The SIP REGISTER message from a SIP endpoint must be received on a

TLS connection. The OpenScape Voice server does not provide the server
version when the SIP REGISTER message is received on UDP or TCP
without TLS.
L.1.1.2 TLS Protection of SIP and SIP-Q Server Signaling

TLS can be used to protect SIP and SIP-Q signaling interfaces between network
servers. Examples of where TLS may be used include the following:
720
A31003-H8050-J100-09-7631, 09/2011
TLS Overview
OpenScape Voice-to-OpenScape Voice interfaces
OpenScape Voice-to-RG 8700 interfaces (when supported by the RG 8700)
SIP-Q to HiPath 3000 and HiPath 4000
Mutual authentication within TLS is supported for SIP and SIP-Q server
connections. When TLS is used, both OpenScape Voice and the remote SIP or
SIP-Q server can do the following:
Act as either a TLS client or a TLS server; either side can set up or reestablish a TLS session.
Authenticate each other using certificates. This is different from the use of
TLS with SIP subscriber endpoints (refer to Section L.1.1.1, TLS Protection
of Endpoint SIP Signaling, on page 718) which, in accordance with IETF
RFC 3261, uses digest authentication for authentication of the client to
OpenScape Voice.
L.1.2 Sample Connection Call Flows

Figure 33 on page 722 provides an example of a simple connection one-way TLS
example, including a full handshake:
1. A client sends a ClientHello message specifying the highest TLS protocol
version it supports, a random number, a list of suggested cipher suites and
compression methods.
2. The server responds with a ServerHello message, containing the chosen
protocol version, a random number, cipher suite, and compression method
from the choices offered by the client. The server may also send a session id
as part of the message to perform a resumed handshake.
3. The server sends its Certificate message.
4. The server sends a ServerHelloDone message, indicating it is done with
handshake negotiation.
5. The client responds with a ClientKeyExchange message, which may
contain a PreMasterSecret, public key, or nothing. (Again, this depends on
the selected cipher.)
6. The client and server use the random numbers and PreMasterSecret to
compute a common secret, known as the master secret. All other key data for
this connection is derived from this master secret and the client- and servergenerated random values, which is passed through a carefully designed
pseudo-random function.
A31003-H8050-J100-09-7631, 09/2011
721
TLS Overview
7. The client sends a ChangeCipherSpec record, essentially telling the server,

Everything I tell you from now on will be encrypted. Note that the
ChangeCipherSpec is itself a record-level protocol, and has type 20, and not
22.
8. The client sends an encrypted Finished message, containing a hash and
MAC over the previous handshake messages.
9. The server attempts to decrypt the clients Finished message, and verify the
hash and MAC. If the decryption or verification fails, the handshake is
considered to have failed and the connection should be torn down.
10. The server sends a ChangeCipherSpec and its encrypted Finished
message, and the client performs the same decryption and verification.
At this point, the handshake is complete and the application protocol is enabled,
with content type of 23. Application messages exchanged between client and
server will be encrypted.
Figure 33
Sample TLS Connection Call Flow
The following provides an example of a client being authenticated using TLS with
mutual authentication:
722
A31003-H8050-J100-09-7631, 09/2011
TLS Overview
1. A client sends a ClientHello message specifying the highest TLS protocol

version it supports, a random number, a list of suggested cipher suites and
compression methods.
2. The server responds with a ServerHello message, containing the chosen
protocol version, a random number, cipher suite, and compression method
from the choices offered by the client. The server may also send a session id
as part of the message to perform a resumed handshake.
3. The server sends its ServerCertificate message.
4. The server requests a certificate from the client, so that the connection can
be mutually authenticated, using a CertificateRequest message.
5. The server sends a ServerHelloDone message, indicating it is done with
handshake negotiation.
6. The client responds with a Certificate message, which contains the clients
certificate.
7. The client sends a ClientKeyExchange message, which may contain a
PreMasterSecret, public key, or nothing. (Again, this depends on the selected
cipher.) This PreMasterSecret is encrypted using the public key of the server
certificate.
8. The client sends a CertificateVerify message, which is a signature over the
previous handshake messages using the clients certificates private key. This
signature can be verified by using the clients certificates public key. This lets
the server know that the client has access to the private key of the certificate
and thus owns the certificate.
9. The client and server use the random numbers and PreMasterSecret to
compute the master secret. All other key data for this connection is derived
from this master secret (and the client- and server-generated random values),
which is passed through a carefully designed pseudo-random function.
10. The client sends a ChangeCipherSpec record, essentially telling the server,
Everything I tell you from now on will be encrypted. Note that the
ChangeCipherSpec is itself a record-level protocol, and has type 20, and not
22.
11. Finally, the client sends an encrypted Finished message, containing a hash
and MAC over the previous handshake messages.
12. The server attempts to decrypt the clients Finished message, and verify the
hash and MAC. If the decryption or verification fails, the handshake is
considered to have failed and the connection should be torn down.
13. Finally, the server sends a ChangeCipherSpec and its encrypted Finished
message, and the client performs the same decryption and verification.
A31003-H8050-J100-09-7631, 09/2011
723
TLS Overview
At this point, the handshake is complete and the application protocol is enabled,
with content type of 23. Application messages exchanged between client and
server will be encrypted.
Figure 34
Sample Mutual TLS Connection Call Flow
L.1.3 OpenScape Voice Platform Signaling Managers

This section describes the concept of primary and backup signaling managers as
it exists on the OpenScape Voice platform. These concepts are useful in
understanding the practical DNS examples presented elsewhere in this chapter.
As shown in Figure 35 on page 725:
724
When establishing a unilaterally authenticated TLS connectionfor example,

a phonethe connection is made to the IP address of the SIP signaling
manager (SIPSM). Each node has its own SIP signaling manager. In addition,
A31003-H8050-J100-09-7631, 09/2011
TLS Overview
each signaling manager has a secondary instance on the other node, in case
one node were to go down. This avoids the need for all devices to re-register
on a node failover due to an outage. The secondary signaling manager on
each node shares all the registration credentials that the primary signaling
manager recorded as the phones registered.
When establishing a TLS connection with mutual authentication for server-toserver interworkingfor example, SIP-NNIsa different set of IP addresses
is used. These IP addresses exclusively handle mutual TLS connections and
cannot handle unilateral TLS connections, such as those from phones.
Similarly, the IP addresses associated with unilateral TLS cannot handle
mutual TLS connection attempts.
Figure 35
Signaling Managers Used in Unilateral and Mutual TLS

Connections
L.1.4 DNS Survivability Overview

An SRV record or Service record is a category of data in the Internet Domain
Name System specifying information on available services. It is defined in
RFC 2782, A DNS RR for Specifying the Location of Services (DNS SRV). Newer
Internet protocols such as SIP often require SRV support from clients.
The remainder of this section describes the problem DNS-SRV solves.
A31003-H8050-J100-09-7631, 09/2011
725
TLS Overview
Figure 36
TLS Phones in Branch By Node-Separated System
Assuming an endpoint in a branch office can obtain service from the local branch
office proxy or from the OpenScape Voice server directly (Figure 36), an
automated flexible method is required that enables the endpoint to determine this
configuration as part of the boot-up process. The concept of DNS-SRV provides
this ability.
If the configuration were to be statically configured within the phone, the phone
could not be moved from location to location without a Move, Add or Change
(MAC) being done manually. This does not fit with the idea of being available on
any device, anywhere, any time with the same one number service.
An SRV record has the form:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
726
Service: the symbolic name of the desired service, for example, SIP or SIPS.
Proto: the protocol of the desired service; this is usually either TCP or UDP.
Name: the domain name for which this record is valid.
TTL: standard DNS time-to-live.
Class: standard DNS class (this is always IN).
Priority: the priority of the target host, with lower values having higher priority.
Weight: A relative weight for records with the same priority.

A31003-H8050-J100-09-7631, 09/2011
TLS Overview
Port: the TCP or UDP port on which the service is to be found.
Target: the canonical hostname of the machine providing the service.
An example SRV record might look like this:

_sip._udp.example.com. 86400 IN SRV 0 5 5060
sipserver.example.com.
This points to a server named sipserver.example.com listening on UDP port 5060
for SIP protocol connections. The priority given here is 0, and the weight is 5.
As with PTR records, SRV records must point to the canonical name of the host.
Aliases or CNAMEs cannot be used as valid targets.
L.1.5 High Availability with SRV

The Priority field is similar to an MX records priority value. Clients always use the
SRV record with the lowest-numbered priority value first, and only fall back to
other records if the connection with this records host fails. Thus a service may
have a designated fallback server, used only if the primary server fails. Only
another SRV record, with a priority field value higher than the primary servers
record, is needed.
If a service has multiple SRV records with the same priority value, clients use the
Weight field to determine which host to use. The weight value is relevant only in
relation to other weight values for the service, and only among records with the
same priority value. OpenScape Voice does not uses weights to perform load
balancing.
If we consider our original problem, a solution would appear as follows:
_sips._tcp.example.com. 86400 IN SRV 10 10 5070 proxy1.example.com.
_sips._tcp.example.com. 86400 IN SRV 20 10 5070 osc-node1.example.com.
_sips._tcp.example.com. 86400 IN SRV 30 10 5070 osc-node2.example.com.
Because proxy1 has the highest priority (lowest number), phones register with it
first. If the proxy is unavailable, the record with the next highest priority value is
chosen, which is osc-node1.example.com. This is the primary node of the
OpenScape Voice server in the data center. If it is down for maintenance, the
phone connects with the osc-node2, which is the secondary node of the cluster.
Note: The load balancing provided by SRV records is inherently limited, since the
information is essentially static; current load of servers is not taken into account.
For that reason, its use is not recommended.
After the branch office proxy comes back online, the phones detect this (as they
recheck its availability periodically) and automatically switch back to using the
proxy. This is an advantage of classic A-Records.
A31003-H8050-J100-09-7631, 09/2011
727
TLS Overview
L.1.5.1 Simple Example Including DNS Server

In the following example, assume that no branch offices are present; the phones
connect directly to the OpenScape Voice server. In this example, a customer may
require the capability to use DNS-SRV to connect both UDP, TCP, and TLS
devices. Depending on which protocol they support, they must be connected to
different IP addresses or ports.
;;;; NAPTR records for sip services
;
order pref flags service
regexp
replacement
IN NAPTR 50
50
SIPS+D2T
_sips._tcp.bocb.siemens.com.
IN NAPTR 90
50
SIP+D2T
_sip._tcp.bocb.siemens.com.
IN NAPTR 100
50
SIP+D2U
_sip._udp.bocb.siemens.com.
;;;; SRV records for each sip service

;;
Priority
Weight
Port Target
_sips._tcp.bocb.siemens.com SRV
10
1 5061 bocaft3a.bocb.siemens.com.
SRV
20
5061 bocaft3b.bocb.siemens.com.
SRV
10
5060 bocaft3a.bocb.siemens.com.
SRV
20
SRV
10
5060 bocaft3a.bocb.siemens.com.
SRV
20
_sip._tcp.bocb.siemens.com
_sip._udp.bocb.siemens.com
;;;; A records for the contacts mentioned in SRV records

bocaft3a
IN
165.218.179.96
;; sip-sm node1
bocaft3b
IN
165.218.179.97
;; sip-sm node2
;;;; PTR records for reverse lookup of the contacts mentioned in SRV records
96.179.218.165.in-addr.arpa. 3570
97.179.218.165.in-addr.arpa. 3570
IN
IN
PTR
PTR
bocaft3a.bocb.siemens.com.
bocaft3b.bocb.siemens.com.
After it is installed, the following commands can be used to test the record:
To return the DNS names of the nodes and the port number offering UDP
service:
host -t srv _sip._udp.bocb.siemens.com
To return the DNS names of the nodes and the port number offering TCP
service:
host -t srv _sip._tcp.bocb.siemens.com
To return the DNS names of the nodes and the port number offering TCP
service:
host -t srv _sips._tcp.bocb.siemens.com
728
A31003-H8050-J100-09-7631, 09/2011
TLS Overview
L.1.6 Interaction of DNS-SRV and TLS

By default, the contents of the TLS certificates are not checked after the TLS
handshake is complete. However, the certificates contents will be checked if the
RTP system parameter Srx/ttud/verification is set appropriately.
The information contained in a certificate (Figure 37 and Figure 38 on page 730)
can be viewed by opening any of the certificates that come preinstalled on any
web browser.
Figure 37
TLS Certificate ExampleGeneral Properties
A31003-H8050-J100-09-7631, 09/2011
729
TLS Overview
Figure 38
TLS Certificate ExampleDetails
The following are particularly important fields that are checked:
Valid From and Valid To: Checking these fields verifies that the certificate is
currently valid and not out of date.
CommonName (CN) or SubjectAlternativeName: Depending on which of

these fields is relevant based on the configuration present, checking the
correct field verifies the server for which this certificate was made.
By comparing the IP address that the certificate came from with the IP address
(resolved using DNS) of the CommonName field, it can be verified that the
certificate issued for that server really appeared to come from that server. If it
does not match, the TLS connection can be rejected and torn down.
In the previous example shown in Figure 36 on page 726 with a branch office
proxy and a two-node redundant OpenScape Voice server, it is necessary to
ensure that the contents of the certificate are correct or the certificates will be
rejected after the post-connection check takes place. However, the
CommonName field can only contain one DNS name or IP address, which does
not match with the concept of DNS-SRV. Therefore, certificates use a concept of
SubjectAlternativeName, which can be used instead of a single CommonName
to identify the accepted source of service.
730
A31003-H8050-J100-09-7631, 09/2011
TLS Overview
The SubjectAlternativeName fields of a certificate can be as long a list as is

required for the solution at hand, and can contain DNS names, IP addresses, or
a combination of both. It also contains the FQDN of the server system it belongs
to. If added, the CommonName field is ignored and no longer evaluated as part
of the post-connection check mechanism.
The following sections, which provide examples of DNS-SRV and TLS certificate
content, illustrate what is required in which scenario.
L.1.6.1 Example 1
In this example (Figure 39):
No proxy is present.
Phones are directly connected to OpenScape Voice, with both nodes in the
same subnet.
Figure 39
TLSPhones in Headquarter by Collocated System
In this case, the phones do not use DNS-SRV because they always connect to
the primary node. Therefore the certificate can be made to have just one
CommonName, which would have the name SIPSM1-Primary.example.com. If
the primary node goes down, this IP address is taken over by the secondary
nodes backup signaling manager. Thus the CN field would still resolve to the IP
address that communication is being established with.
A31003-H8050-J100-09-7631, 09/2011
731
TLS Overview
L.1.6.2 Example 2
A local proxy is present.
Phones are connected to OpenScape Voice using the proxy, with both nodes
in same subnet.
If the proxy fails, the phones register to the primary node for service.
Figure 40
732
TLSPhones in Branch by Collocated System
A31003-H8050-J100-09-7631, 09/2011
TLS Overview
In this case, the phone normally registers to the local proxy for service. If the
proxy goes down, the phones register directly with the primary node for service.
Therefore one CommonName is not adequate; instead, the
SubjectAlternativeName fields are used in combination with the correct DNSSRV record:
_sips._tcp.branch1.example.com. 86400 IN SRV 10 10 5070 proxy1.example.com.
_sips._tcp.branch1.example.com. 86400 IN SRV 20 10 5070 SIPSM1-Primary.example.com.
The corresponding certificate sent by proxy1 would contain:

X509v3 Subject Alternative Name:
DNS:proxy1.example.com
The DNS SRV records for a different branch office would look similar to the
records of branch1 but its proxy name would be slightly different:
_sips._tcp.branch2.example.com. 86400 IN SRV 10 10 5070 proxy2.example.com.
_sips._tcp.branch2.example.com. 86400 IN SRV 20 10 5070 SIPSM1-Primary.example.com.
The corresponding certificate sent by node1 would contain:

DNS:SIPSM1-Primary.example.com
L.1.6.3 Example 3
No proxy is present.
Phones are registered to a two-node redundant OpenScape Voice system

with each node being in a different subnet.
A31003-H8050-J100-09-7631, 09/2011
733
TLS Overview
Figure 41
TLS - Phones in Headquarter by Node Separated System
In this case, the phones register with the primary signaling manager on node 1
for service. If that node goes down, the phones switch to the backup signaling
manager on node 2.
_sips._tcp.example.com. 86400 IN SRV 10 10 5070 SIPSM1-Primary.example.com.
_sips._tcp.example.com. 86400 IN SRV 20 10 5070 SIPSM2-Backup.example.com.

DNS:SIPSM2-Primary.example.com, DNS:SIPSM2-Backup.example.com
Because all phones must register with the primary node when using TLS, all
phones would get flashed with the same certificate in this scenario.
L.1.6.4 Example 4
734
A local proxy is present.
Phones are connected to OpenScape Voice using the proxy, with both nodes
in different subnets.
If the proxy fails, the phones register to the primary node for service.
A31003-H8050-J100-09-7631, 09/2011
TLS Overview
If the primary node is down, the phones register with the backup signaling
manager on node 2.
Figure 42
TLSPhones in Branch by Node-Separated System
In this case, the phones normally register to the local proxy for service. If the
proxy goes down, the phones register directly with the primary node for service.
If that node is unavailable, the phones register to the backup signaling manager
on node 2. Therefore one CommonName will not be adequate; instead, the
SubjectAlternativeName fields are used in combination with the correct DNSSRV record:
_sips._tcp.example.com. 86400 IN SRV 30 10 5070 SIPSM2-Backup.example.com
The corresponding certificate sent by proxy1 would contain:

DNS:proxy1.example.com
The DNS SRV records for a different branch office would look similar to the
records of branch1 but its proxy name would be slightly different:
_sips._tcp.example.com. 86400 IN SRV 30 10 5070 SIPSM2-Backup.example.com.
A31003-H8050-J100-09-7631, 09/2011
735
TLS Overview

DNS:SIPSM1-Primary.example.com, DNS:SIPSM2-Secondary.example.com
L.1.7 Practical Deployment Recommendations

Assuming that a customer can have many branches that come online
sequentially in a phased approach, it is not practical to create one jumbo
certificate on the OpenScape Voice platform that contains all the
SubjectAlternativeName values for each proxy in each branch. Therefore, it is
recommended that the same certificate be installed on each node of a dual-node
cluster that contains the SubjectAlternativeName values of only those
components that are likely to connect directly to it.
In Figure 43 on page 736, the connections in red are mutual TLS connections and
all others are unilateral TLS connections. Therefore, the certificate on both nodes
of a dual-node cluster (symbolized as an OpenScape Voice cluster) contains the
SubjectAlternativeName values for each of the signaling managers of both nodes
of the cluster and for the servers connected via mutual TLS. However, it does not
contain SubjectAlternativeName values for the proxies in the branch offices. Each
proxy in each branch office should have its own certificate (signed using the same
root CA).
Figure 43
736
Deployment Recommendations
A31003-H8050-J100-09-7631, 09/2011
Creating a TLS Certificate
L.2 Creating a TLS Certificate

Note: This section is intended for customers who do not have a PKI system.
Customers with a PKI in place can use their own PKI tool to create the TLS
certificate files in the appropriate directories on the nodes.
Certificates are created in hierarchies; levels above are known as certificate

authorities (CAs). The CA is used to sign the certificate being created. The CA
certificate is then stored on the receiving end of the certificate so that the
signatures can be compared. Figure 44 on page 737 shows an example of a twolevel certificate hierarchy.
Chain
Depth
Certificate
Hierarchy
Root CA
Issuing CA
OpenScape Voice
server certificate
Figure 44
OpenScape Voice
server certificate
OpenScape Voice
server certificate
Sample Certificate Hierarchy
The Issuing CA, or Root CA certificates are located on the peers of the
OpenScape Voice server. Similarly, the equivalent CA certificate is also located
on the OpenScape Voice server.
The OpenScape Voice server accepts certificates in PEM format only. If another
format is usedfor example, PKCS#12a conversion to PEM format is required
before the certificate can be used. The conversion to PEM format can be
completed using the openssl command line utility.
A31003-H8050-J100-09-7631, 09/2011
737
L.2.1 OpenSSL Command Line Utility And

Configuration Files
Certificates are created using the OpenSSL command line utility, openssl, and
configuration files. For examples of template files used to create a certificate,
refer to /usr/local/ssl or Section L.2.3, Example Root CA Configuration
File, on page 747.
Two command line utility subcommands are used to create certificates:
req is used to create certificate request.
x509 is used to sign the certificate.
The configuration file contains default values that are used if they are not defined
on the command line. The section of the configuration file to be used is given as
command line options. The sections of the configuration file are defined by a
name in brackets. For example, [ req ] would define the req section.
738
A31003-H8050-J100-09-7631, 09/2011
Details of the openssl subcommands can be found in:
Online documentation, OpenSSL req command

http://www.openssl.org/docs/pps/req.html#
Online documentation, OpenSSL x509 command

http://www.openssl.org/docs/apps/x509.html#
Further details of the format of the OpenSSL configuration file can be found in:
Online documentation, OpenSSL configuration files
http://www.openssl.org/docs/apps/config.html#
The OpenSSL mechanism supported on OpenScape Voice is not a complete PKI.
The OpenScape Voice CA is a built-in procedure, using OpenSSL, which is useful
as a default mechanism, but does not support the management of certificates.
The OpenSSL package on OpenScape Voice provides a toolkit to generate
certificates for use in scenarios where a separate customer PKI is not intended
for use. Large customers will require that the existing PKI be used to get the
OpenScape Voice certificate.
In environments where a separate PKI is required, OpenScape Voice can use the
server provided by the customer PKI.
The following sections describe the procedures used to create certificates using
the command line utility.
Note: The DLS is used to install the corresponding root CA certification onto
Siemens SIP endpoints that use TLS transport. The same root CA certificate is
used by all SIP endpoints to validate the X.509 server certificate that is installed
on the OpenScape Voice system.
L.2.2 CA Certificates And Their Usage

CA certificates are used so that their signature can be compared against the CA
signature within the certificate being offered by the peer. CA certificates can be
stored either all within one file or as separate files.
If the CA certificates are stored within one file, the file must use the following
format:
-----BEGIN CERTIFICATE----... (CA certificate in base64 encoding) ...
-----END CERTIFICATE-----
A31003-H8050-J100-09-7631, 09/2011
739
If certificates are stored in one file, TTUD must be restarted when a new
certificate is added to the file. The default file, rootcert.pem, contains the root CA
certificate for the OpenScape Voice server. It can used by peers within the
network.
If CA certificates are stored in separate files, they should be stored in the directory
using the following RTP parameters:
SSL/EndPoint/Server/CertificatesPath
SSL/MutualAuth/Server/CertificatesPath
SSL/MutualAuth/Client/CertificatesPath
The directory used depends on the type of peer that the certificate is coming from.
The RTP parameters above can point to the same directory.
After the file is added to the directory, the following command must be run as root
user in that directory:
/usr/bin/c_rehash $PWD
The advantage of this method is that TTUD does not have to be restarted for the
changes to take affect. TTUD uses both methods to access CA certificates. The
file is accessed first and if not found, the directory is then searched.
L.2.2.1 Creating a Root CA Certificate

The following procedure is an example of how to create a new private key and
certificate request. All commands should be executed as root user.
1. Store the new key in rootkey.pem and store the certificate request in
rootreq.pem:
openssl req -newkey rsa:2048 -sha1 -keyout rootkey.pem -out rootreq.pem -config root.cnf
nodes
Note the following:
740
The newkey option requests a new private RSA key of length 2048 bits.
The size of key can be 512, 1024, 2048 or 4096 bits.
The sha1 option defines the message digest that the certificate request
is signed with.
The option nodes states that the private key will not be encrypted.
The config option states the name of the configuration file to be used. As
there is no extension option given, the default section [ req ] of the
configuration file will be used. For additional information, refer to Section
L.2.3, Example Root CA Configuration File, on page 747.
A31003-H8050-J100-09-7631, 09/2011
2. Sign the certificate using the certificate request and private key. Store it in
rootcert.pem using the following command:
openssl x509 -req -in rootreq.pem -sha1 -extfile root.cnf -extensions v3_ca -signkey
rootkey.pem -out rootcert.pem -days 3650
Note the following:
The req option states that a certificate request is being used to create
the new certificate.
The sha1 option defines the message digest that the certificate is signed
with.
The extfile option states the name of the configuration file to be used.
This option is used with the extensions option which states section [
v3_ca ] will be used. The section v3_ca is an example another section
can be defined if needed. The parameter basicConstraints = CA:true
indicates that the resulting certificate is a certificate of a CA.
The signkey option gives the file that is used to sign the certificate (in this
case the root CAs key).
The figure for the days option is the number of days that the certificate
will be valid from the day of creation.
3. Copy the file rootcert.pm to root.pem.

4. View the certificate using the following command:
openssl x509 -text -noout -in rootcert.pem
The certificate is used on peer systems to verify the client and server
certificates that will be used by the OpenScape Voice server. It is also located
in the directory indicated by the following RTP parameters:
The files are owned by root user with group of other.
5. This procedure should be repeated if separate certificates are needed for
each interface (EndPoint or MutualAuthentication) and for each connection
type (Client or Server).
6. Once the certificate has been stored in the directories listed, run the following
command above as the root user in each directory.
Note: The RTP parameters can contain the same directory name, so the
certificate only needs to be copied once and the c_rehash command only
executed once.
A31003-H8050-J100-09-7631, 09/2011
741
L.2.2.2 Creating an Intermediate CA Certificate

The following procedure is an example of how to create an intermediate CA
certificate from the root CA. This step can also be repeated if needed in the
certificate hierarchy is more complex. All commands should be executed as root
user.
To create a intermediate CA certificate:
1. Create a new key and store it in serverCAkey.pem. Create a certificate
request and store it in serverCAreq.pem using the following command:
openssl req -newkey rsa:2048 -sha1 -keyout serverCAkey.pem
-out serverCAreq.pem -config serverCA.cnf nodes
Note the following:
is signed with.
there is no extension option given, the default section [ req ] of the
configuration file will be used. For additional information, refer to Section
L.2.3, Example Root CA Configuration File, on page 747.
2. Sign the certificate request using the root CA and store it in serverCAcert.pem
with the following command:
openssl x509 -req -in serverCAreq.pem -sha1 extfile serverCA.cnf -extensions v3_ca -CA
rootcert.pem CAkey rootkey.pem -CAcreateserial -out serverCAcert.pem -days 3650
Note the following:
742
with.
This option is used with the extensions option which states section
[ v3_ca ] will be used. The section v3_ca is an example another section
can be defined if needed. The parameter basicConstraints = CA:true
indicates that the resulting certificate is a certificate of a CA.
The CA and -CAkey options give the certificate that is used to sign the
certificate (in this case the root CAs certificate).
The Cacreateserial creates a serial number for the certificate.
A31003-H8050-J100-09-7631, 09/2011
3. Create the server CA certificate and add the root CA certificate using the
following command:
cat serverCAcert.pem serverCAkey.pem rootcert.pem >
serverCA.pem
openssl x509 text noout in serverCA.pem
L.2.2.3 Creating a Server Certificate

The following is an example of how to create a server certificate from the server
CA. All command should be executed as root user.
Note: The server certificate can also be generated from the root CA.
1. Create a new key and store it in serverkey.pem. Create a certificate request

and store it in serverreq.pem using the following command:
openssl req -newkey rsa:2048 -sha1 -keyout serverkey.pem -out serverreq.pem -config
server.cnf reqexts v3_req nodes
Note the following:
is signed with.
there is section given by the reqext option is used (in the example above
the section header is [v3_req ]).
2. Sign the certificate request using the server CA and store it in servercert.pem
using the following command:
openssl x509 -req -in serverreq.pem -sha1 extfile server.cnf -extensions v3_req -CA
serverCA.pem CAkey serverCAkey.pem -CAcreateserial -out servercert.pem -days 3650
Note the following:
with.
A31003-H8050-J100-09-7631, 09/2011
743
This option is used with the extensions option which states section
[ v3_req ] will be used. The section v3_req is an example another
section can be defined if needed. The SubjectAlternativeName
(mentioned above) should be listed in this section.
3. Create the server certificate and add the server CA and root CA certificates
cat servercert.pem serverkey.pem serverCAcert.pem rootcert.pem > server.pem
openssl x509 text noout in server.pem
The certificate is used on the OpenScape Voice server and is located in the
directory indicated by the following RTP parameters:
SSL/EndPoint/Server/KeysPath
SSL/MutualAuth/Server/KeysPath
5. Repeat this procedure if separate certificates are needed for each interface
(EndPoint or MutualAuthentication). The files should be owned by root user
with group of other. The name of the certificate(s) should match the RTP the
following parameters:
SSL/EndPoint/Server/Keys
SSL/MutualAuth/Server/Keys
L.2.2.4 Creating a Client Certificate

The following procedure is an example of how to create a client certificate from
the root CA. All commands should be executed as root user.
Note: The client certificate can also be generated from an intermediate CA. In this
example, however, an intermediate CA is not used.
1. Create a new key and store it in clientkey.pem and create a certificate request
and store it in clientreq.pem with the following command:
openssl req -newkey rsa:2048 -sha1 -keyout clientkey.pem -out clientreq.pem -config client.cnf
reqexts v3_req nodes
Notes the following:
744
A31003-H8050-J100-09-7631, 09/2011
is signed with.
there is section given by the reqext option is used (in the example above
the section header is [v3_req ]).The req_extensions above is the
configuration file section header name that should be used for the
creation of the certificate.
2. Sign the certificate request using the root CA and store it in clientcert.pem
openssl x509 -req -in clientreq.pem -sha1 extfile client.cnf -extensions v3_req -CA
rootcert.pem CAkey rootkey.pem -CAcreateserial -out clientcert.pem -days 3650
Note the following:
with.
This option is used with the extensions option which states section [
v3_req ] will be used. The section v3_req is an example another section
can be defined if needed. The SubjectAlternativeName (mentioned
above) should be listed in this section.
3. Create the client certificate and add the root CA certificate using the following
command:
cat clientcert.pem clientkey.pem rootcert.pem > client.pem
openssl x509 text noout in client.pem
5. The certificate is used on the OpenScape Voice server and is located in the
directory indicated by the following RTP parameter:
SSL/MutualAuth/Client/KeysPath
A31003-H8050-J100-09-7631, 09/2011
745
The file should be owned by srx user with group of other. The name of the
certificate should match the following RTP parameter:
SSL/MutualAuth/Client/Keys
L.2.2.5 Creating Third-Party Product Certificates

Third-party products should have their own certificates; if they do not, certificates
need to be created. Refer to the third-party documentation for information to do
so.
OpenScape Voice uses PEM format for TLS certificates. For that reason, it is
possible that the third-party product's CA certificate needs to be converted to
PEM format from its own format. OpenSSL has command line options to perform
this conversion. Refer to the following web pages for assistance:
To convert from DER to PEM:

http://www.openssl.org/docs/apps/x509.html
To convert from PCKS#7 to PEM

http://www.openssl.org/docs/apps/pkcs7.html
To convert from PCKS#12 to PEM:

http://www.openssl.org/docs/apps/pkcs12.html
To convert from other formats, check the general command line page:
http://www.openssl.org/docs/apps/openssl.html.
After the PEM-format certificate has been created for the third partys CA, it needs
to be stored on OpenScape Voice as follows:
1. Store the CA certificate matching this certificate in the directories of the
following RTP parameters:
The files should be owned by srx user with group of other.
2. After the certificate has been stored into the directories, run the following
command as root user for each of the directories:
Note: The RTP parameters can contain the same directory name so the
certificate only needs to be copied once and the c_rehash command only
executed once.
746
A31003-H8050-J100-09-7631, 09/2011
L.2.2.6 Creating the Diffie-Hellman Key

If a Diffie-Hellman key is required:
openssl dhparam -check -text -5 2048 -out dh2048.pem
The name of the file created, in this example, dh2048.pem, (in the case of
the should match the following RTP parameters:
SSL/EndPoint/Server/SupportedDH
SSL/MutualAuth/Server/SupportedDH
SSL/MutualAuth/Client/SupportedDH
2. Repeat this procedure if separate keys are required for each interface
(EndPoint or MutualAuthentication) and for each connection type (Client or
Server).
3. Store the key file(s) in the directory indicated by the following RTP
parameters:
SSL/EndPoint/Server/DHPath
SSL/MutualAuth/Server/DHPath
SSL/MutualAuth/Client/DHPath
The files should be owned by root user.
L.2.3 Example Root CA Configuration File

The following is an example OpenSSL configuration file that can be used to
create root CA certificates. It is stored on the OpenScape Voice server as
/usr/local/ssl/root.cnf.
#
# root CA example configuration file.
# This file is based on the OpenSSL example configuration file
#
# This definition stops the following lines choking if HOME isn't
# defined.
HOME
=
[ req ]distinguished_name = req_distinguished_name
attributes
= req_attributes
x509_extensions
= v3_ca # The extensions to add to the self signed cert
[ req_distinguished_name ]
# If prompting has been switched off, remove _min, _max and _default lines
# in this section and set values to those that are required.
countryName
= Country Name (2 letter code)
countryName_default
= AU
countryName_min
= 2
countryName_max
= 2
A31003-H8050-J100-09-7631, 09/2011
747
stateOrProvinceName
stateOrProvinceName_default
= State or Province Name (full name)

= Some-State
localityName
= Locality Name (eg, city)
0.organizationName
0.organizationName_default
= Organization Name (eg, company)

= Internet Widgits Pty Ltd
# we can do this but it is not needed normally :-)

#1.organizationName
= Second Organization Name (eg, company)
#1.organizationName_default
= World Wide Web Pty Ltd
organizationalUnitName
= Organizational Unit Name (eg, section)
commonName
commonName_max
= Common Name (eg, YOUR name)

= 64
[ req_attributes ]
challengePassword
challengePassword_min
challengePassword_max
= A challenge password
= 4
= 20
unstructuredName
= An optional company name
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true
Intermediate CA Configuration File

The root CA configuration file can be used for the creation of intermediate CA
certificates. Create a copy and name it serverCA.cnf.
Server Configuration File
SIP IP addresses and FQDNs must be modified for the system where the server
certificates are being created.
The following is an example of a configuration file.
#
# server certificate example configuration file.
# This file is based on the OpenSSL example configuration file
#
# This definition stops the following lines choking if HOME isn't
# defined.
HOME
= .
[ req ]
distinguished_name
attributes
x509_extensions
= req_distinguished_name
= req_attributes
= v3_req # The extensions to add to the self signed cert
[ req_distinguished_name ]
# If prompting has been switched off, remove _min, _max and _default lines
# in this section and set values to those that are required.
countryName
= Country Name (2 letter code)
countryName_default
= AU
countryName_min
= 2
countryName_max
= 2
748
A31003-H8050-J100-09-7631, 09/2011
Installing or Updating a TLS Certificate
stateOrProvinceName
stateOrProvinceName_default
= State or Province Name (full name)

= Some-State
localityName
= Locality Name (eg, city)
0.organizationName
0.organizationName_default
= Organization Name (eg, company)

= Internet Widgits Pty Ltd
# we can do this but it is not needed normally :-)

#1.organizationName
= Second Organization Name (eg, company)
#1.organizationName_default
= World Wide Web Pty Ltd
# For Name it is important to use OpenScape Voice IP address or FQDN
organizationalUnitName
= Organizational Unit Name (eg, section)
commonName
commonName_max
= Common Name (eg, YOUR name)

= 64
[ req_attributes ]
challengePassword
challengePassword_min
challengePassword_max
= A challenge password
= 4
= 20
unstructuredName
= An optional company name
[ v3_req ]
# Extensions to add to certificate
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# example of FQDN is sever.myco.com
subjectAltName=DNS:<insert FQDN here>, IP:<insert IP here>
#It is required to add IP and FQDN in the subjectALTName= field.
Client Configuration File

Use the server configuration file to create client certificates. Create a copy of the
certificate and name it client.cnf.
L.3 Installing or Updating a TLS Certificate

After certificates have been created, they need to be installed on the OpenScape
Voice server. However, this process should be done with extreme care and
pre-planning to avoid a total system outage! This is especially important if a
server certificate is to be exchanged on a system that is already running
encryption, as it can lead to existing TLS or mutual TLS connections being
dropped and no longer being capable of being re-established.
To ensure an outage does not occur, the following steps must be taken:
For TLS connections to endpoints (phones, analog terminal adapters,

and so on):
Before a new server certificate can be installed on the OpenScape Voice
platform, one of the following steps must be taken:
A31003-H8050-J100-09-7631, 09/2011
749
The phones profiles must be set to not validate the certificate if they are
already using TLS. This change will not result in a phone reboot or
disruption in service. The connection between the phone and the
OpenScape Voice platform will continue to be encrypted, but may be
subject to man-in-the-middle attacks during this time.
The phones must be set to do UDP or TCP without encryption. This may
take a little more effort as the SIP endpoint must be configured on
OpenScape Voice Assistant as allowed to enter using UDP/TCP as well.
This change will result in a short outage as the phone re-registers.
Attention: If one of these actions is not undertaken first, the phones will fail
to authenticate against the new server certificate and will de-register,
resulting in an outage until new certificates are pushed to all the phones or
until the situation is rectified manually.
For mutual TLS connections to gateways and other servers (OpenScape

Voice, RG 8700 gateway, and so on):
Before a new server certificate can be installed on the OpenScape Voice
platform, the corresponding client certificate must be added to the root CA of
the partner devices doing mutual TLS in addition to the current client
certificate. This ensures that the partner device already has the matching
certificate available before the server certificate is exchanged.
Attention: If this new certificate is not added to the CA, the partner device will
not be able to verify it; this may result in an outage depending on the partner
device design.
L.3.1 Installing a Certificate on an Endpoint Server

Table 52 lists the RTP parameters that control the directories where certificates
are stored and the names of the certificates to be used. The same directories and
names can be used for mutual authentication and endpoints.
Note: If any of the RTP parameter values listed in Table 52 are changed using
CLI, TTUD must be restarted for them to take effect.
Parameter Name
Default Value
SSL/EndPoint/Server/KeysPath
/usr/local/ssl/private
SSL/EndPoint/Server/Keys
server.pem
/usr/local/ssl/certs
Table 52
750
RTP ParametersEndpoint Server (Sheet 1 of 2)
A31003-H8050-J100-09-7631, 09/2011
Parameter Name
Default Value
SSL/EndPoint/Server/SupportedCertificates
rootcert.pem
SSL/EndPoint/Server/DHPath
/usr/local/ssl/dh_keys
SSL/EndPoint/Server/SupportedDH
dh1024.pem
Table 52
RTP ParametersEndpoint Server (Sheet 2 of 2)
To install a new CA certificate on the endpoint server, complete the following

procedure:
1. Access the directory in which the certificates are stored, as indicated by the
RTP parameter SSL/EndPoint/Server/CertificatesPath.
2. Copy the CA certificate to this directory.
3. Regenerate the hashes used to find the certificates by running, as root user,
the following command:
L.3.2 Installing a Certificate on a Mutual

Authentication Server
are stored and the names of the certificates to be used. The same directories and
names can be used for mutual authentication and endpoints.
CLI, TTUD must be restarted for them to take effect.
Parameter Name
Default Value
SSL/MutualAuth/Server/KeysPath
SSL/MutualAuth/Server/Keys
server.pem
SSL/MutualAuth/Server/SupportedCertificates
rootcert.pem
SSL/MutualAuth/Server/DHPath
SSL/MutualAuth/Server/SupportedDH
dh1024.pem
Table 53
RTP ParametersMutual Authentication Server
To install a new CA certificate on the mutual authentication server, complete the

following procedure:
1. Access the directory in which the certificates are stored, as indicated by the
RTP parameter SSL/MutualAuth/Server/CertificatesPath.
A31003-H8050-J100-09-7631, 09/2011
751
Client (Endpoint) Authentication
L.3.3 Installing a Certificate on a Mutual

Authentication Client
are stored and the names of the certificates to be used.
CLI, TTUD has to be restarted for them to take effect.
Parameter Name
Default Value
SSL/MutualAuth/Client/KeysPath
SSL/MutualAuth/Client/Keys
client.pem
SSL/MutualAuth/Client/
SupportedCertificates
rootcert.pem
SSL/MutualAuth/Client/DHPath
SSL/MutualAuth/Client/SupportedDH
dh1024.pem
Table 54
RTP ParametersMutual Authentication Client
To install new CA certificate on the mutual authentication client, use the following
procedure:
1. Change directory to the one in which certificates are held, as indicated by the
RTP parameter SSL/MutualAuth/Client/CertificatesPath.
the following command:
L.4 Client (Endpoint) Authentication

SIP digest authentication is enabled or disabled on OpenScape Voice using
provisioning of SIP signaling manager options. It is recommended that SIP digest
authentication be enabled during system installation. Refer also to Section L.5,
Media Server Signaling.
752
A31003-H8050-J100-09-7631, 09/2011
Media Server Signaling
Weak or short SIP passwords can be easily cracked by currently available hacker
tools. OpenScape Voice supports SIP passwords of up to 20 characters. It is
recommended that SIP passwords be of at least 8 characters and contain a mix
of uppercase, lowercase, numeric characters, and special characters. Dictionary
words or purely numeric SIP passwords should be avoided.
L.5 Media Server Signaling

OpenScape Voice supports IPsec with IKE and pre-shared keys for MGCP
signaling interfaces.
A31003-H8050-J100-09-7631, 09/2011
753
Media Server Signaling
754
A31003-H8050-J100-09-7631, 09/2011
HP8K_IUGIX.fm
Index
Index
accidents, reporting 17
Adobe Reader 14
Applications 305
Applications Servers 308
ating 747
editing
the node.cfg file 35
electrical safety information 15
emergency information 17
emergency safety 17
endpoint signaling 718
equipment room safety 16
Ethernet card
bonding driver definitions 58, 87, 147
configuring for fixed operation 286
Ethernet switch 52
Executive Assistant with Cockpit 444, 466
Executive-Assistant 444
EZIP 641
B
Backups 443
BasicTraffic Tool (BTT) 405, 615
BIOS 117
Boot-Up speed 283
C
certificate authority (CA)
certificate usage 739
creating client certificate 744
creating Diffie-Hellman key 747
creating intermediate CA certificate 742
creating root CA certificate 740
creating server certificate 743
creating third-party product certificate 746
general description 737
certificate, transport layer security (TLS)
creating 737
installing or updating 749
checking
port assignments 288
Checklist 226
CLI Users 442
co-located node installation 59, 88, 148
configuration files, OpenSSL 738
configuring Ethernet NICs 286
connecting cables
for a duplex (FSC RX330) 86
for a duplex (IBM x3550) 146
for a duplex (x3650T) 57
for a simplex (FSC RX330) 84
for a simplex (IBM x3550 M2) 144
for a simplex (x3650T) 55
D
Datastore 240
Destination MS 700
Diffie-Helman key 747
disabling auto-negotiation 287
DLS Scan 663
F
Fallback 398, 508
FSC RX330 Server
description 46
installation checklist 82
FTS RX200 S6 Server
description 51
G
general safety 15
graphical and numerical data screens 616
Guest machine 256
Guidelines 226
I
IBM x3250 M2 Server
description 47
IBM x3550 M2 Server
description 49
IBM x3550 M3 Server
description 50
IBM x3650T Server
description 45
Image DVD 240
install_time.log 619
installation
assumptions 22
checklist 24
A31003-H8050-J100-09-7631, 09/2011
755
HP8K_IUGIX.fm
Index
media 21
prerequisites 22, 213
Installation prerequisites 306
Installation Wizard 35
installing
co-located node configuration 59, 88, 148
FSC RX330 server 84
IBM x3550 M2 server 144
Intel server management software 76
Linux platform software 214
OpenScape Voice application software 214
OpenScape Voice hardware platform 45
OpenScape Voice using DVDs 213
split-node configuration 59, 88, 148
the client 615
x3650T server 54
Integrated Managment Module (IMM) 131, 138
Integrated Simplex 340
Integrated Simplex System 467
Intel server management software 76
K
L
Linux Accounts 442
Login credentials 240
Loquendo trap manager service 304
M
Media Server
Announcements 691
Deployment 693
Destination Types 693
Prefix Access Code 691
Treatments 691
menu structure of BTT 616
Migration 545
Migration Toolkit Software 600
Migrations 425
Multiple Communications Server 359
Net Sniffer 660
Node.cfg file 235
node.cfg file 213
O
Offboard Applications 400
Offboard Installation 391
OpenScape Applications 305, 384
OpenScape UC Application 338
OpenScape Voice
756
P
Post installation 283
prerequisite knowledge 13
Proxies and Gateways 672, 680
R
Remote SW Upgrade 495
Simplex 496
Standard Duplex 495
Removal of obsolete IP addresses 657
reporting accidents 17
KVM/Mouse combination 293
basic traffic tool 615

installation 22
installation DVDs 213
signaling stream security 717
software installation 213
OpenScape Voice Entry SBC 295
OpenScape Voice Reference Image 213
OpenSSL, configuration files 738
Overview 223
safety information 15
session initiation protocol (SIP)
endpoints
and RFC 3261 719
network signaling 720
setting Ethernet NICs 287
signaling
stream security
OpenScape Voice 717
Single MS 696
SLES 10 OS 308
split-node installation 59, 88, 148
SSDP Plug-In 344, 352, 364
Standalone Survival Authority 411
Standard Duplex System 472, 490
Survival Authority 649
Survival Authority Configuration 418
T
testing
KVM/mouse combination 293
Toolkit Method 467
Trace File Information 386
transport layer security (TLS) 717
creating certificate 737
deployment recommendations 736
installing or updating certificate 749
U
Unified Extensible Firmware Interface (UEFI) 123
A31003-H8050-J100-09-7631, 09/2011
HP8K_IUGIX.fm
Index
Uninstall Integrated Simplex 346

upgrade
paths 434
Upgrades 425, 445
USB Memory Stick 647
User ID and Password 284
using the basic traffic tool 615
V
Virtual floppy disk 237
Virtual Media Key 138
Virtual switch 243
Virtualization 222
VM Configuration Parameters 228
VM CPU requirements 233
VM Disk requirements 233
VM Memory requirements 233
VM Network requirements 232
VM Solutions 232
VMware vSphere client 240
vSphere client 240
A31003-H8050-J100-09-7631, 09/2011
757
HP8K_IUGIX.fm
Index
758
A31003-H8050-J100-09-7631, 09/2011

OpenScape Voice V5, Installation and Upgrades, Installation Guide, Issue 9 - Addfiles

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

OpenScape Voice V5, Installation and Upgrades, Installation Guide, Issue 9 - Addfiles

Hochgeladen von

Copyright:

Verfügbare Formate

Installation

Communication for the open minded

Siemens Enterprise Communications

Copyright Siemens Enterprise

Communication for the open minded

The information provided in this document contains

2 Preparing for the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Installing the Hardware Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nur fr den internen Gebrauch

3.3.8 Modifying the IBM x3650T Server BIOS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.7.7 Modifying the FTS RX200 RAID Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Installing the OpenScape Voice Reference Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Nur fr den internen Gebrauch

4.4.7.1 SBC Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

5.5 Retrieving Trace File Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Survival Authority and IPMI Shutdown Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Overview of Upgrades and Migrations to OpenScape Voice V5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 Upgrades to OpenScape Voice V5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Nur fr den internen Gebrauch

8.1.3 Required Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 Migrations to OpenScape Voice V5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 Basic Traffic Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A Example Install_Time.log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

C IBM x3650T Quad Ethernet Card Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

D IBM xSeries 345 and 346 Wiring Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637

Nur fr den internen Gebrauch

H.1.1 V3.1R3 Monitoring the Survival Authority From the Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

J.4.2 Treatments Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706

Nur fr den internen Gebrauch

1.1.2 Prerequisite Knowledge

Successfully completed the Siemens OpenScape Voice installation and

Advanced SuSE Linux Enterprise Server (SLES) operating system and

Basic knowledge of the third-party platforms and equipment used for

Basic knowledge of the industry standards and specifications utilized by

The procedures in this guide require an understanding of and adherence to local

1.1.3 Viewing the Document with Adobe Reader

1.1.4 Special Notices

A danger notice calls attention to conditions that, if not avoided, will

WARNING A warning notice calls attention to conditions that, if not avoided,

A caution notice calls attention to conditions that, if not avoided,

1.2.1 General Safety

1.2.2 Safety with Electricity

1.2.2.1 High Voltages

Ensure that a machine cannot be powered on from another source or

When a procedure requires that you power off the system:

Lock the wall box-switch in the off position.

Attach a DO NOT OPERATE tag to the wall box-switch.

Disconnect all power before installing changes in machine circuits unless

High voltages capable of causing shock are used in this equipment. Be

Do not wear jewelry or other metal objects.

Use caution when installing or modifying telephone lines. Never install

Never touch uninsulated telephone wires or terminals unless the telephone

1.2.2.2 Equipment Room

The surface of a mirror is conductive. Do not touch powered circuits with a

Do not store combustible gases or flammable materials in cabinets near the

Administer resuscitation if the person is not breathing.

Call a rescue group, an ambulance, or a hospital immediately.

1.2.3 Reporting Accidents

Report any electric shock, no matter how small.

2 Preparing for the Installation

OpenScape Voice redundant is available in a standard duplex configuration:

Geographically separated nodes in either the same subnet or in different

Standard duplex: The OpenScape Applications (OpenScape Voice