Avaya Aura WFO Configuration Guide

Avaya Aura WFO
Release 11.0
Configuration Guide
March 2012
© 2003 - 2011 Verint Systems Inc. All Rights Reserved. THIS AVAYA PRODUCT portions of the Product ('Third Party Terms'). Information identifying Third Party
('Product') CONTAINS CONFIDENTIAL AND PROPRIETARY INFORMATION Components and the Third Party Terms that apply to them is available on
OF VERINT SYSTEMS INC. OR ITS SUBSIDIARIES. USE OF THE PRODUCT Avaya's web site at: http://support.avaya.com/ThirdPartyLicense/. In addition,
INDICATES THE END USER'S ACCEPTANCE OF THE TERMS SET FORTH this product may contain the ReportNet application from Cognos Corporation. If
HEREIN AND THE GENERAL LICENSE TERMS AVAILABLE ON THE AVAYA so, you are granted a limited for use: (i) by an unlimited number of "Anonymous
WEBSITE AT http://support.avaya.com/LicenseInfo/ ('GENERAL LICENSE Users" to set personal preferences, view, run, schedule and output reports,
TERMS'). IN THE EVENT OF ANY CONFLICT OR INCONSISTENCY subscribe to scheduled reports, create and manage personal folders, and
BETWEEN THE TERMS SET FORTH HEREIN AND ANY WRITTEN personalize standard reports, and (ii) by one "Named User" (unless otherwise
AGREEMENT WITH AVAYA AND/OR AVAYA EULA, THE TERMS OF SUCH specified on this Order) to, in addition to the rights of an Anonymous User, use
EITHER WRITTEN AGREEMENT WITH AVAYA AND/OR AVAYA EULA SHALL the Query Studio module.
GOVERN. IF YOU DO NOT WISH TO BE BOUND BY THESE TERMS, YOU Avaya fraud intervention:
MUST RETURN THE PRODUCT(S) TO THE POINT OF PURCHASE WITHIN
If you suspect that you are being victimized by toll fraud and you need technical
TEN (10) DAYS OF DELIVERY FOR A REFUND OR CREDIT.
assistance or support, call Technical Service Center Toll Fraud Intervention
Avaya grants End User a license within the scope of the license types described Hotline at +1-800-643-2353 for the United States and Canada. Suspected
below. The applicable number of licenses and units of capacity for which the security vulnerabilities with Avaya Products should be reported to Avaya by
license is granted will be one (1), unless a different number of licenses or units of sending mail to: securityalerts@avaya.com
capacity is specified in the Documentation or other materials available to End
Trademarks:
User. 'Software' means the computer programs in object code, originally licensed
by Avaya and ultimately utilized by End User, whether as stand-alone Products Avaya and the Avaya Logo are trademarks of Avaya Inc. and are registered in
or pre-installed on Hardware. 'Hardware' means the standard hardware the United States and/or other countries. Avaya may also have trademark rights
Products, originally sold by Avaya and ultimately utilized by End User. in other terms used herein. References to Avaya include the Nortel Enterprise
business, which was acquired as of December 18, 2009.
License Type(s):
All trademarks identified by ®, TM or SM are registered marks, trademarks, and
"Channel" means a physical connection between or logical address associated
service marks, respectively, of Avaya Inc. or the property of their respective
with a recording device and an audio source.
owners.
"Enterprise" means a license to use, without limitation on the number of copies or
Patents:
users applicable to that End User, that Software within that End User's technical
environment in conjunction with other Software licensed. The Verint Systems Inc. products are protected by one or more of the following
U.S., European or International Patents: USPN 5,790,798; USPN 6,278,978;
"Seat" means the number of uniquely identified work-stations (i) on which the
USPN 6,370,574; USPN 6,404,857; USPN 6,510,220; USPN 6,724,887; USPN
Software is licensed to be installed, (ii) from or to which the Software will send or
6,751,297; USPN 6,757,361; USPN 6,782,093; USPN 6,952,732; USPN
receive data, or (iii) about which the Software generates data. Any one or more of
the foregoing, in the aggregate, applicable to a work-station shall qualify that
work-station as a licensed Seat. Seat licenses are not concurrent, except that
licenses relating to a work-station may be transferred to another work-station so
long as such transfer is on a permanent basis.
"Server" means a license to install the Software on a single central computer 7,587,041; USPN 7,613,290; USPN 7,633,930; USPN 7,634,422; USPN
server. 7,650,293; USPN 7,660,307; USPN 7,660,406; USPN 7,660,407; USPN
"Site" means a license to use the Software at a physical End User location, 7,672,746; USPN 7,680,264; USPN 7,701,972; USPN 7,734,783; USPN
without limitation on the number of copies or users applicable to that physical 7,752,043; USPN 7,752,508; USPN 7,769,176; USPN 7,774,854; USPN
End User location. 7,787,974; USPN 7,788,286; USPN 7,792,278; USPN 7,792,671; USPN
Copyright: 7,801,055; USPN 7,817,795; USPN 7,822,018; USPN 7,826,608; USPN
Except where expressly stated otherwise, the Product is protected by copyright
and other laws respecting proprietary rights. Unauthorized reproduction, transfer,
and or use can be a criminal, as well as a civil, offense under the applicable law.
Third-party Components: 7,904,481; USPN 7,903,568; USPN 7,904,325; USPN 7,907,142; USPN
This computer program is protected by U.S. and international copyright laws, 7,913,063; USPN D606,983; USPN RE40,634; USPN RE41,534; USPN
patent laws, and other intellectual property laws and treaties. Unauthorized use, RE41,608; AU 2003214926; CA 2,474,735; CA 2,563,960; CA 2,564,127; CA
duplication, publication and distribution of all or any portion of this computer 2,564,760; CA 2,567,232; CA 2,623,178; CA 2,627,060; CA 2,627,064; CA
program are expressly prohibited and will be prosecuted to the maximum extent 2,628,553; EP 1096382; EP 1248449; EP 1284077; DE 1284077; FR 1284077;
provided by law. Your rights in this computer program are limited to the license DE 833489; FR 833489; GB 833,489; GB 2374249; IE 84821; IE 85519; IL
rights granted under the license agreement executed by you in hardcopy form (or 13532400; NZ 534642; ZL 200520118289.3; ZL 200520118288.9; ZL
if none, by acceptance of the clickwrap terms included with this computer 200520118287.4; and other provisional rights from one or more of the following
program). If needed, please contact your vendor for an additional copy of those Published U.S. Patent Applications: US 10/061,491; US 10/467,899; US
terms. All other rights, title and interest are expressly restricted and retained by 10/525,260; US 10/633,357; US 11/166,630; US 11/345,587; US 11/359,195; US
Verint Systems, Inc. and its licensors. 11/359,319; US 11/359,356; US 11/359,357; US 11/359,358; US 11/359,532; US
Certain open source applications ("Open Source") may be included with this 11/361,208; US 11/388,944; US 11/394,408; US 11/394,410; US 11/394,794; US
computer program. For specific ownership information and license rights relating 11/395,759; US 11/396,062; US 11/428,239; US 11/475,683; US 11/477,124; US
to those open source applications, please see the "Free and Open Source 11/478,714; US 11/479,056; US 11/479,267; US 11/479,506; US 11/479,899; US
Licensing Information" guide ("Guide") provided with your computer program, or 11/509,549; US 11/509,550; US 11/528,267; US 11/529,132; US 11/529,946; US
contact your vendor for a copy of that Guide. 11/529,947; US 11/540,107; US 11/540,171; US 11/540,185; US 11/540,281; US
11/540,320; US 11/540,785; US 11/540,900; US 11/540,902; US 11/540,904; US
A license in each Open Source software application is provided to you in
11/567,808; US 11/567,852; US 11/583,381; US 11/608,340; US 11/608,350; US
accordance with the specific license terms specified in the Guide. EXCEPT
11/608,358; US 11/608,438; US 11/608,440; US 11/608,894; US 11/616,490; US
WITH REGARD TO ANY WARRANTIES OR OTHER RIGHTS AND
11/621,134; US 11/676,818; US 11/691,530; US 11/692,983; US 11/693,828; US
OBLIGATIONS EXPRESSLY PROVIDED DIRECTLY TO YOU FROM VERINT,
11/693,899; US 11/693,923; US 11/693,933; US 11/712,933; US 11/723,010; US
ALL OPEN SOURCE SOFTWARE IS PROVIDED "AS IS'' AND ANY
11/742,733; US 11/752,458; US 11/771,499; US 11/776,659; US 11/824,980; US
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
11/831,250; US 11/831,257; US 11/831,260; US 11/831,634; US 11/844,759; US
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
11/872,575; US 11/924,201; US 11/937,553; US 11/959,650; US 11/968,428; US
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
12/015,375; US 12/015,621; US 12/053,788; US 12/055,102; US 12/057,442; US
OWNERS OF THE OPEN SOURCE SOFTWARE OR ITS CONTRIBUTORS BE
12/057,476; US 12/107,976; US 12/118,781; US 12/118,789; US 12/118,792; US
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
12/164,480; US 12/245,781; US 12/326,205; US 12/351,370; US 12/416,906; US
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
12/464,694; US 12/466,673; US 12/483,075; US 12/497,793; US 12/497,799; US
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
12/504,492; US 12/539,640; US 12/608,474; US 12/628,089; US 12/630,030; US
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
12/684,027; US 12/686,213; US 12/708,558; US 12/725,127; US 12/753,137; US
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
12/762,402; US 12/768,194; US 12/792,796; US 12/840,227; US 12/840,233; US
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
12/852,144; US 12/879,868; US 12/887,059; US 12/887,089; US 12/888,445; US
IN ANY WAY OUT OF THE USE OF THE OPEN SOURCE SOFTWARE, EVEN
12/888,448; US 12/891,620; US 12/915,868; US 12/915,941; US 12/916,006;
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
US 12/940,508; US 12/942,111; US 12/964,891; US 13/005,996; US 13/008,283;
Certain other software programs or portions thereof included in the Product may US 13/011,870; US 13/011,871; US 13/016,998; and other U.S. and International
contain software distributed under third party agreements ('Third Party Patents and Patents Pending.
Components'), which may contain terms that expand or limit rights to use certain
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Suite Architecture and Deployment Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
Platforms and Server Roles . . . . . . . . . . . . . . . . . . . . . . . . .9
Deployment Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Deployment Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Platform Flavors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Configuration Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Configuration Access Privileges . . . . . . . . . . . . . . . . . . . . . . . . 12
Suite Configuration Workflow . . . . . . . . . . . . . . . . . . . . . . . . 14
2 License and Product Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

About Licensing and Product Activation . . . . . . . . . . . . . . . . . . . . . 17
Licensing Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
License Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Activating a License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Product Activation using the License Management Screen . . . . . . . . . . . . . . 21
3 Site Organization and Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Before You Begin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Setting Up the Installation Tree . . . . . . . . . . . . . . . . . . . . . . . . 27
Accessing the Enterprise Manager Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Setting up Site Group Nodes and Site Nodes on the Installation Tree . . . . . . . . . . . . . 28
About the Enterprise node . . . . . . . . . . . . . . . . . . . . . . . . 28
About Site Group Nodes (optional for larger deployments) . . . . . . . . . . . . . 29
Creating Site Group Nodes . . . . . . . . . . . . . . . . . . . . . . . . 29
Creating Site Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Adding Servers (Server/Installations Nodes) to the Installation Tree . . . . . . . . . . . 31
Adding a Server node . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Creating a server template for copying server configuration information . . . . . . . . 33
Creating and Managing Server Clusters (used in larger deployments) . . . . . . . . . . 34
Creating a Server Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Creating Application Server Clusters that Include Active Framework Application Server Roles . . 38
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Contents
Creating an Application Server Cluster . . . . . . . . . . . . . . . . . . . . 39

Adding Servers to Functioning Application Server Clusters. . . . . . . . . . . . . . 42
Changing Server Configuration in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . .43
Moving and Removing Servers in a Cluster . . . . . . . . . . . . . . . . . . . 43
Creating and Editing Role Associations in a Cluster . . . . . . . . . . . . . . . . 44
Patching Servers in a Server Cluster . . . . . . . . . . . . . . . . . . . . . 44
Viewing Server Role Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4 Enterprise Settings and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

About Enterprise and Security Settings . . . . . . . . . . . . . . . . . . . . . . 47
Configuring General Enterprise Settings . . . . . . . . . . . . . . . . . . . . . 48
First Day Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Configuring Enterprise Security Settings . . . . . . . . . . . . . . . . . . . . . 54
Authenticating Connections to Managed Server(s) . . . . . . . . . . . . . . . . . . 57
Working with the Authentication Server and Authconfig.xml . . . . . . . . . . . . . 57
Using the Authentication/Single Sign-On (SSO) Process . . . . . . . . . . . . . . 57
Replacing the Enterprise Manager . . . . . . . . . . . . . . . . . . . . . . 58
Encrypting connections with SSL . . . . . . . . . . . . . . . . . . . . . . 59
5 Server Role Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Mapping Server Roles to Platforms . . . . . . . . . . . . . . . . . . . . . . . 61
Platforms and Deployment Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
About Activating or Deactivating Server Roles . . . . . . . . . . . . . . . . . . . 62
Activating/Deactivating Server Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Configuring Server Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Setting Server Role Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Configuration Details: Data Center Zone Server Roles . . . . . . . . . . . . . . . . 67
Framework Applications Server Role and Associations . . . . . . . . . . . . . . . . . . . . .67
Framework Applications Server Role . . . . . . . . . . . . . . . . . . . . . 69
Framework Applications Server Role Associations . . . . . . . . . . . . . . . . . 69
Framework Reports Server Role and Associations . . . . . . . . . . . . . . . . . . . . . . .69
Framework Reports Server Role . . . . . . . . . . . . . . . . . . . . . . . 71
Framework Report Server Role Associations. . . . . . . . . . . . . . . . . . . 72
Framework Database Server Role and Associations. . . . . . . . . . . . . . . . . . . . . . .72
Framework Database Server Role . . . . . . . . . . . . . . . . . . . . . . 74
Framework Database Server Role Associations. . . . . . . . . . . . . . . . . . 77
Framework Data Warehouse Server Role and Associations . . . . . . . . . . . . . . . . . . .77
Framework Data Warehouse Server Role . . . . . . . . . . . . . . . . . . . . 78
Framework Data Warehouse Server Role Associations . . . . . . . . . . . . . . . 79
Framework Integration Service Server Role and Associations . . . . . . . . . . . . . . . . . .79
Framework Integration Service Server Role . . . . . . . . . . . . . . . . . . . 80
Framework Integration Service Server Role Associations . . . . . . . . . . . . . . 80
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Avaya Aura WFO Configuration Guide 4
© 2011 Verint Systems Inc. All Rights Reserved Worldwide. Confidential and Proprietary Information of Verint Systems Inc.
Contents
6 Validating Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Reviewing Notifications on the Configuration Status tab . . . . . . . . . . . . . . . . 82
Reviewing the Configuration Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Reviewing Alarms on the Alarm Status Tab . . . . . . . . . . . . . . . . . . . . 84
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Retrieving a Server Role’s XML File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Reviewing the Component Internal Configuration Repository . . . . . . . . . . . . . . . . . .85
7 Configuring Single Sign-On (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Configuring SSO with the SSO Wizard . . . . . . . . . . . . . . . . . . . . . . 88
Verifying SSO Service Binding Account, Host and Domain Names, and the Default DB Authentication88
Verifying the SSO Service Binding Account . . . . . . . . . . . . . . . . . . . 88
Verifying Host and Domain Names . . . . . . . . . . . . . . . . . . . . . . 89
Verifying the Suite’s Default DB Authentication . . . . . . . . . . . . . . . . . 89
Configuring SSO with the SSO Configuration Wizard . . . . . . . . . . . . . . . . . . . . . .93
Restarting Weblogic Services . . . . . . . . . . . . . . . . . . . . . . . 101
Configuring the Administrator Account Username and Password in Enterprise Manager . . 101
Testing the SSO Configuration . . . . . . . . . . . . . . . . . . . . . . . . 103
Troubleshooting SSO Configuration Issues. . . . . . . . . . . . . . . . . . . . 104
A workstation stops working with SSO . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
SSO fails because setspn is not running correctly . . . . . . . . . . . . . . . . . . . . . . 105
I have found a problem in the SSO configuration and fixed but it still doesn't work. What is being
cached? How do I clear the cache?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
What should I do if I encounter the message KDC has no support for encryption type (14)? . . 106
SSO works from one desktop but doesn't work from another one . . . . . . . . . . . . . . . 107
Can I use the IP address instead of the host name for the fully qualified domain name in the URL when
accessing the suite with SSO? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
What is the problem when the WebLogic server fails to start and the suite’s home page or the Weblogic
console cannot be accessed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Can SSO fail due to case sensitivity? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Can a customer IT department lock prerequisite accounts, such as Firstuser, WLSAdmin, the SSO
service binding account, or test user accounts to log on only to specific servers or workstations?108
What should I do when ktpass fails due to an extra setspn? . . . . . . . . . . . . . . . . . 108
Do I have to force DES encryption for the SSOBind account? . . . . . . . . . . . . . . . . . 108
Does the SSO Configuration Wizard need WLSAdmin to be member of WLSAdminGroup or any other
privilege group? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
What do I do when the System Monitor tool in Enterprise Manager triggers an alarm that indicates that
the Framework Applications Administrator Account Name and/or password are incorrect? . . . 109
Can the Domain Controller have multiple NICs? . . . . . . . . . . . . . . . . . . . . . . . 109
SSO doesn't work but when I De-Select the Trusted Login check box and enter credentials, my user is
authenticated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
What if somebody changes the service binding account password? . . . . . . . . . . . . . . 111
Can I run the uninstallService.cmd and installService.cmd in Windows Explorer by double-clicking
them? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
How do I turn on debug mode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Contents
A Working with Deployment Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

About Deployment Levels . . . . . . . . . . . . . . . . . . . . . . . . . 114
Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Level 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Levels 4 and 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Level 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B Managed Servers Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

About Managed Servers . . . . . . . . . . . . . . . . . . . . . . . . . . 116
C High Availability and Server Clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

About High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Application High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Database High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
About Server Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
D Server Roles and Associations and Constraints/Restrictions . . . . . . . . . . . . . . . 122

Server Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Server Role Associations . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Server Role and Association Constraints . . . . . . . . . . . . . . . . . . . . 124
Server Role Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 124
Associated Role Constraints . . . . . . . . . . . . . . . . . . . . . . . 125
E Configuring Active Directory with Lightweight Directory Access Protocol (LDAP) . . . . 126
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
LDAP Authentication Workflow . . . . . . . . . . . . . . . . . . . . . . . . 127
Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Configuring LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Stopping and Restarting the WebLogic Server . . . . . . . . . . . . . . . . . . . . . . . . 142
Configuring the Administrator Account Username and Password in Enterprise Manager . . . . . 143
Validating the LDAP Configuration . . . . . . . . . . . . . . . . . . . . . . 144
Chapter 1
Introduction
The following sections provide a high level description of the suite solution, and the
configuration and documentation workflow.
z Overview, page 8
z Suite Architecture and Deployment Overview, page 8
z Configuration Prerequisites, page 11
z Suite Configuration Workflow on page 14
Chapter 1 - Introduction Overview
Overview
In this release, once installation is complete, the licensing and initial configuration
process for all suite products, including Workforce Management, is unified across the
suite as follows:
z Licensing: is now unified across the suite for all suite products. License and
product activation processes follow suite installation. For details, see Chapter 2
“License and Product Activation”.
z Avaya Aura WFO Configuration: initial hierarchy/servers and server roles are
configured using the Enterprise Management module. For details, see Chapter 3
“Site Organization and Server Setup” and Chapter 5 “Server Role Configuration”.
See:
z Suite Architecture and Deployment Overview, page 8
z Configuration Prerequisites, page 11
z Configuration Access Privileges, page 12
Suite Architecture and Deployment Overview

NOTE The section below provides a brief, high level overview of the suite’s
architecture and deployment.
For full details, see the Avaya Aura WFO Technical Overview Guide and the
Avaya WFO Installation Guide.
Avaya Aura WFO includes the following integrated products:

z Framework applications
z Workforce Management
z Forecasting & Scheduling
z Coaching
z Desktop Activity Management
z Scorecards
z Customer Feedback
z eLearning
Due to the system’s architecture, installation and configuration of these products is now
unified across the suite.
For an architecture overview, see:
z Platforms and Server Roles, page 9

z Deployment Zones, page 9
z Deployment Levels, page 10
z Platform Flavors, page 11
Platforms and Server Roles

NOTE An Installation & Configuration Report for each customer is prepared
during Fulfillment. This report indicates the deployment size, how many
servers are required, and the platforms to be installed on each server.
Field engineers/technical staff use this report:
z during the installation phase to select and install appropriate
platforms.
z during the configuration stage, to build the customer’s site
hierarchy, and to deploy the installed servers/platforms according to
the customer’s organizational requirements.
Suite products are part of a software solution that is comprised of:

z Platforms/Servers: A platform is a software unit that contains a pre-defined
logical group of server roles installed side-by-side on a server. There are a number
of different platform types (for example, Consolidated, Data Center, Database),
each with its own set of server roles.
For an overview of each platform and their server roles, see Mapping Server Roles
to Platforms, page 61.
z Server roles. Each server role contains a set of pre-defined software components;
these software components are specific to the individual suite products.
Following license and product activation, only those server roles relevant to the
licensed products are available for configuration.
NOTE For details on licensing, see Chapter 2 “License and Product Activation”.
The available server roles are then configured using the Enterprise Manager tool.
For details about server roles and their configuration, see Chapter 5 “Server Role
Configuration”.
Deployment Zones
The suite architecture comprises two logical deployment zones, Data Center and Site
zones:
z Data Center zone—Contains servers whose platforms comprise the applications,
database, and centralized data processing server roles.
Depending on the size of the deployment, data center zone platforms can be
installed on more than one server.
NOTE Data Center zone servers and their platforms are usually located at a
single central physical location where the customer’s IT personnel and
tools are readily available to monitor and maintain the servers.
However, there are some cases where a Data Center zone server and
platform is deployed remotely, in the same way as many Site zone servers
are; often these scenarios involve remote SQL farms/server clusters.
z Site zone(s)—Contain platforms that include server roles for integration with the
customer environment.
While site zone platforms can be deployed at the same physical (geographical) site
as the Data Center zone platform, they are often deployed at multiple physical sites.
For example, if a customer has call center operations in three cities, a Site zone
platform can be deployed in each city, with data from the Site zones flowing to and
from the Data Center zone, which is generally located at a central geographical site.
A Site zone can include one or more servers.
Deployment Levels
The Enterprise solution offers the following deployment level options:
z Single server deployment is used for small deployments at a single physical site.
A single server deployment comprises the installation of a single server that
contains the Consolidated platform, which includes both Data Center and Site server
roles.
During Enterprise-level configuration, this deployment type requires the creation of
a relatively simple hierarchy, and configuration of the server roles for those
products for which the customer is licensed.
z Distributed deployment is used for medium and large deployments. Depending
on the geographic distribution of the contact centers, the data center and site
logical zones can be deployed in a single physical site or multiple physical sites. This
requires a more complex approach to site and server role configuration.
For more details on deployment levels and configuration, see Appendix A, “Working with
Deployment Levels” on page 113 and Chapter 5 “Server Role Configuration”.
Platform Flavors
A platform flavor indicates the platform with the server roles to be activated.
The Customer Furnished Equipment Deployment Reference Guide (CFE Guide) specifies
the platform flavors required for deployments.
NOTE The following platform flavors are not part of the installation process and need to
be installed independently (refer to the relevant installation guides):
z DPA Database
z DPA Application
z CF Survey Server
Configuration Prerequisites
z You have reviewed the appropriate documentation, for example the following:
z the customer’s site preparation checklist.
z the customer’s installation and configuration report, which describes the
customer deployment requirements.
z the Avaya Aura Technical Overview Guide.
z the Avaya WFO Installation Guide
For details on the documentation set surrounding installation and configuration,
see Related Documents, page 7.
z You have successfully installed the suite. Successful installation includes:
z Physical set up and installation of all servers required for the customer
deployment, with information recorded regarding server name, port number,
qualified domain name, and HTTP alias (used only by Application severs), and
so on.
z You may need this information when configuring individual servers.
z Appropriate platforms (set of server roles) selected for each server as required
for the customer deployment, where the appropriate deployment zone (Data
Center zone or Site zone) is identified for each server.
z You need this information to determine how you set up the organization
hierarchy (described in Chapter 3 “Site Organization and Server Setup”).
z For example, you may want to ensure that all servers with data center
platforms are at a single physical site. You also need to know how many site
group and site nodes you must add, and then which servers you must add to
each site node.
z Default administrator (superuser) logon ID and password entered.
The information for the server set up required for installation is contained in the
Avaya WFO Installation Guide.
Chapter 1 - Introduction Configuration Access Privileges
Configuration Access Privileges

Once the suite has been installed, a default Administrator role is created, which includes
full privileges and access rights to configure the entire Suite.
However, following initial suite installation and configuration, the Administrator role’s
access to the original default privileges and their scope may be changed.
For example, the Administrator role for certain individuals can be changed so that they
only have access to configure a single site node or server or server role on the
installation tree, instead of all of them. With this type of access, other parts of the
installation tree are generally not visible and cannot be configured.
NOTE For more details about the Installation tree and its structure, see
Chapter 3 “Site Organization and Server Setup”.
The procedure below describes how the Administrator role’s access privileges can be
expanded or limited.
To change Administrator access to configuration roles and privileges:

1 Log on to the suite web portal as the system administrator.
2 Navigate to User Management > Access Rights.
3 Select the individual who needs access rights to configure elements on the
installation tree, such as servers and server nodes.
4 Click Edit Access Rights.
On the right panel, a list of role names available within the Suite displays, and
below them several columns, including Installation Scope. The Installation
Scope area, when expanded, shows the structure of the installation tree with all
Chapter 1 - Introduction Configuration Access Privileges
site nodes, and beneath each site node, all server installation nodes and their server
roles.
5 Under Role Name, make sure Administrator is selected.

6 In the Installation Scope area, select the level of installation for which you want
the administrator to have access. All sub-levels of your selection are automatically
selected as well.
For example, if you select the check box for the top level of the installation, all other
check boxes are automatically selected, and the user can configure any level of the
installation.
Or, if you just want the administrator to configure a particular site node or server
node, select that node. The administrator only has the ability to configure that site
node and its servers.
7 Click Save.
For more details on user management, refer to the Avaya Aura WFO User
Management Guide.
Chapter 1 - Introduction Suite Configuration Workflow
Suite Configuration Workflow

Following installation, the customer or our company’s service engineer configures the
suite as follows:
Chapter/Location Processes
Chapter 2 “License and 1 License Activation on page 18, using the licensing
Product Activation” web portal
2 Product Activation using the License Management
Screen on page 21
3 Creating Site Group Nodes on page 29

Chapter 3 “Site 4 Creating Site Nodes on page 30
Organization and Server
Setup” 5 Adding server nodes:
z Adding a Server node on page 32
z Creating and Managing Server Clusters (used in
larger deployments) on page 34
Chapter 4 “Enterprise 6 Configuring General Enterprise Settings on page 48

Settings and Security” 7 Configuring Enterprise Security Settings on page 54
8 Authenticating Connections to Managed Server(s)
on page 57
Chapter 5 “Server Role 9 Activating/Deactivating Server Roles on page 64

Configuration”
10 Configuring Server Roles on page 65
z Configuration Details: Data Center Zone Server
Roles on page 67
Chapter 6 “Validating 11 Reviewing Notifications on the Configuration Status

Configuration” tab
12 Reviewing Alarms on the Alarm Status Tab
Chapter 1 - Introduction Suite Configuration Workflow
Chapter/Location Processes
Chapter 7 “Configuring 13 Configuring SSO with the SSO Wizard, page 88.
Single Sign-On (SSO)”
Follow instructions in this section if you are
configuring the single-sign on feature for the
system.
See Related Documents, 14 Post-suite configuration tasks (including system
page 7. administration/configuration for individual
applications such as Recorder and Interactions and
Analytics) include:
a. Creating/configuring data sources, using the
System Management Module for Workforce
Management, and Scorecards applications.
See the Recorder and the Avaya Framework
Applications System Administration Guide if
working with these applications.
b. Importing/setting up organizations and groups
within the Organization module.
See the Avaya Aura WFO User Management
Guide for applications.
c. Importing/setting up employees using the User
Management modules.
See the Avaya Aura WFO User Management
Guide for all applications.
Chapter 2
License and Product

Activation
This section describes how to activate a customer license and to then activate the
product.
z About Licensing and Product Activation, page 17
z Licensing Workflow, page 17
z License Activation, page 18
z Product Activation using the License Management Screen, page 21
Chapter 2 - License and Product Activation About Licensing and Product Activation
About Licensing and Product Activation

In this release, licensing for all products is unified across the suite.
Licensing for the suite is centrally managed, and is designed to allow the system to
monitor license usage, statistics and violations reporting.
These are the outcomes of successful license and product activation:
z Enterprise configuration: the installer sets up the customer’s Enterprise
hierarchy and configure the server roles associated with the products for which the
customer purchased the license. For details on the Enterprise hierarchy setup and
server role configuration, see Chapter 3, “Site Organization and Server Setup” and
Chapter 5, “Server Role Configuration”.
z User management: roles and privileges related to selected products are activated,
depending on the licensing. For details, see the Enterprise User Management Guide.
z User interface: Modules and screens are visible in the suite portal depending on
the products that were activated.
For licensing details, see:
z Licensing Workflow, page 17
z License Activation, page 18
z Product Activation using the License Management Screen, page 21
Licensing Workflow
1 New (unsigned) license creation during Fulfillment: The licensing process
begins with an initial unsigned license file that is generated after a customer order is
placed. The license is then stored with a unique license reference number.
2 Suite Installation: The customer’s Avaya solution is installed. For details on
installation, see the Avaya WFO Installation Guide.
NOTE During installation, the suite’s URL address is established, and a default
administrator’s ID and password are created. You use this information to
log on to the suite portal during product activation.
3 License registration key generation: During installation of the customer’s

Enterprise solution, a license registration key is generated.
4 License activation: Upon completion of installation, the installer activates the
license using the license web application. Both the unique license reference number
and registration key are required for the activation. This creates an active (signed)
license file.
See License Activation, page 18.
5 Product activation: To activate products, the installer logs on to the suite portal,
and in the License administration screen, uploads the newly activated license
document and restarts the server.
See Product Activation using the License Management Screen, page 21.
Chapter 2 - License and Product Activation License Activation
License Activation
Following installation of an Enterprise solution, you need to activate the license using
the license activation application, which is a web-based application available for access
twenty-four hours, 7 days a week.
Ensure that:
z The License Reference Number is valid.
z You have received the Registration Key and have the correct number.
See Activating a License, page 18
Activating a License
1 Navigate to the license activation web application at this URL:
https://ilaccess.verint.com/V11Activator/Activate.aspx
The License Activation screen opens.
2 In the License Reference Number (LRN) text box, type the LRN.
NOTE If the license activation process described in steps 2 to 5 were completed

earlier, you receive a message confirming the license has already been
activated.
The message includes the license file XML text that can be copied and
pasted into the license XML file. You upload this file during product
activation using the suite portal’s license management screen.
3 Click Go.
4 To accept the license agreement, click Accept.
5 When the screen refreshes with the license details, if you accept the license details,
click OK.
The screen refreshes, displaying a number of verification fields: End User Contact
Name, End User Contact Telephone Number, End User Contact Email, as well
as fields to enter and re-enter the 32-digit Registration Key.
6 Do the following:
a. Enter the appropriate information in the End User Contact Name, End User
Contact Telephone Number, and End User Contact Email fields.
b. Enter the registration key (RK) in the Please enter the 32-digit Registration
Key (RK) and Re-enter the 32-digit Registration Key (RK) fields.
c. Click OK.
The screen refreshes again, showing the XML file that you copy to your hard drive,
and then use to activate your licensed products.
7 Click Download to download the file to your computer. The license file opens.
8 Do one of the following:
a. Save the XML license file on your hard drive
b. If you don’t want to save the file immediately to your hard drive, access your
email at a later time, at the address you provided in Step 6 (a) above. You should
receive an email that confirms your details, and that includes the file attachment
for your license. Open and save the attachment on your hard drive.
9 Proceed to Product Activation using the License Management Screen, page 21 to
activate your products using the license file.
Chapter 2 - License and Product Activation Product Activation using the License Management Screen
Product Activation using the License

Management Screen
1 Log on to the system as follows:
a. Enter the URL of the system established during the suite installation process. An
example of a login URL could be:
http://10.1.4.169:7001/wfo/
b. On the logon screen, type the default administrator’s user name and password,
established during the suite installation process.
c. Click the Login button.
The suite portal opens, displaying only the General Settings and License
Management tabs.
2 Click System Management > License Management to open the License
Management tab.
In the upper panel of the License Management screen, you see the Licensee,
Version and Registration Key information.
3 At the bottom right of the screen, click the Upload License button.
4 In the Upload License File dialog box, beside the License box, click Browse.
Then navigate to and select the XML activated license file that you had saved to
your hard drive during the license activation process.
5 Click Upload.
Once the upload completes, a message appears in the Upload License File dialog
box to restart all application servers.
6 Restart the Weblogic service on the application server(s) by doing the following:
a. Click Start > Run and, in the Run dialog box, type services.msc.
b. In the Windows Services window, restart the Weblogic service called

WFO_ProductionDomain_ProductionServer.
IMPORTANT When uploading licenses for a hierarchy setup that includes application
server clusters, you must do the following:
1 When activating the products, log on to one of the application servers.
2 Upload the license.
3 Add the other application servers to Enterprise Manager as described
in Creating and Managing Server Clusters (used in larger
deployments), page 34.
4 Restart the Weblogic service on each application server.
Note that you receive a message prompt to restart each machine; the
message only closes once all machines have been restarted.
After you restart the Weblogic service, the License screen displays the list of all the
products for which the customer has purchased the license. The check boxes beside
the product names are selected by default. Some product names have a clickable
arrow at their left.
5 Click the arrows beside those product names that have them, to expand the product
feature list.
NOTE Unlike the product names, the product feature names are not checked by
default.
Some examples of additional feature items are:
z Agent Adherence (Basic minimum)
z Dashboards
6 If you want to customize the product list and add some or all of the additional
feature items available to you, select the check box beside each available item to
activate it.
7 If you want to remove or revoke certain license items, click inside the check box
next to the item you want to remove to clear the check box. Once the application
server is restarted, these items are longer available for use in the system.
NOTE You can only remove/revoke license items if the check box beside the item
is enabled.
IMPORTANT When you remove/revoke certain license items, you may get a message
that warns you that while you can remove the item, once you stop and
restart the application server, its removal may cause the system to not
function as it is supposed to.
The license items that trigger this warning message are as follows:
z AppLink Server (per DB instance)
z Integration Quality Monitoring 7
8 Once you have completed the product activation process, you are ready to begin
using the Enterprise Manager feature to build the Enterprise hierarchy required for
the customer’s organization, and to configure the server roles for the products that
you have activated.
For details, see Chapter 3, “Site Organization and Server Setup” and Chapter 5,
“Server Role Configuration”.
Chapter 3
Site Organization and Server

Setup
The sections that follow provide an overview of the suite’s site organization and server
set up, and then more detailed descriptions around creating or adding site group, site,
and server nodes to the installation tree.
z Overview, page 26
z Setting Up the Installation Tree, page 27
z Setting up Site Group Nodes and Site Nodes on the Installation Tree, page 28
z Adding Servers (Server/Installations Nodes) to the Installation Tree, page 31
z Creating and Managing Server Clusters (used in larger deployments), page 34
z Viewing Server Role Nodes, page 44
Chapter 3 - Site Organization and Server Setup Overview
Overview
Once the suite installation is complete (this includes installation of all servers,
application platforms and their server roles), you use the suite’s Enterprise Manager tool
to create a hierarchical structure that contains the site groups and sites that reflect the
customer’s organizational requirements.
You then add the servers installed during the Enterprise installation process to the
appropriate sites, configuring them according to customer licensing and requirements.
You can then configure the server roles contained within each server; server role
configuration is covered in Chapter 5, “Server Role Configuration”).
In Enterprise Manager, typically site group > site > server nodes are displayed in a
hierarchical manner.
The hierarchy is meant to provide a graphical view of the customer’s enterprise,
reflecting the real-world organization of that enterprise.
NOTE Refer to the customer’s Installation and Configuration Report to ensure
that you configure the installation tree in the correct order.
This hierarchy is referred to as the Installations tree.

See:
z Before You Begin, page 26
z Setting Up the Installation Tree, page 27
z Adding Servers (Server/Installations Nodes) to the Installation Tree, page 31
z Viewing Server Role Nodes, page 44
Before You Begin

The configuration steps that follow assume the following:
z You have completed license and product activation tasks. For details on this, see
Chapter 2, “License and Product Activation”.
z You have full access rights as Administrator to configure and edit the installation
tree, site and server nodes, servers, and server roles and their associations. By
default, this should be available to you if configuring the Suite after installation.
NOTE If your role, privileges and user access rights do not include the ability to
configure an installation, you may not be able to see all features of the
configuration.
For details on changing access rights, see Configuration Access Privileges,
page 12, or contact the customer’s system administrator.
Once you complete the setup process that follows, you then configure the server roles
required to activate the suite applications for which the customer has acquired licensing.
For details on server role configuration, see Chapter 5, “Server Role Configuration”.
Chapter 3 - Site Organization and Server Setup Setting Up the Installation Tree
Setting Up the Installation Tree

Since every customer deployment is unique, it is impossible to describe in detail all
configuration options for adding the site groups, sites, and finally servers to the
Enterprise Manager installation tree. Generally, however, there are two key types of
configurations:
z Installation and configuration of a server with a Consolidated platform.This is the
simplest configuration, used for the smaller suite deployments; it is called a Level 1
deployment.
A consolidated platform contains all server roles for all applications on a single
server only.
As a consequence, the installation tree hierarchy is a simple one, usually requiring
addition of a single Site node and the server node beneath it.
z Installation and configuration of a number of servers, depending on the deployment
level (levels 2 to 6). There are many flavours of deployment at these levels that can
include a combination of Databases and Applications, and their platforms.
See:
z Accessing the Enterprise Manager Tool, page 27
z Setting up Site Group Nodes and Site Nodes on the Installation Tree, page 28
Accessing the Enterprise Manager Tool

During installation, the Enterprise Manager is installed on the suite portal, for all
deployments.
After installation, you access the Enterprise Manager tool using the default administrator
(superuser) logon ID and password created during installation.
NOTE The sections that follow describe only those Enterprise Manager tasks
specific to setting up the site group/Enterprise hierarchy and relevant
servers to reflect the customer’s organizational requirement.
The content herein does not reflect the full scope of Enterprise Manager
functionality, such as Enterprise Management editing features (editing
settings, deleting settings, and more).
For a description of the full range of Enterprise Manager functionality, see
the Avaya Aura WFO Enterprise Manager Basics Guide.
To access the Enterprise Manager tool

1 Access the suite portal’s logon screen and enter the default administrator’s logon ID
and password.
2 Navigate to System Management > Enterprise Management > Settings.
Following a new installation, the screen refreshes and displays the screen, showing
the top-level Enterprise node that exists by default in the hierarchical tree structure.
This node represents your entire organization and cannot be deleted. All site groups
and sites that you create and configure are created beneath this node.
You are now ready to create and configure site groups, sites, and server
installations. See Setting up Site Group Nodes and Site Nodes on the Installation
Tree, page 28
Setting up Site Group Nodes and Site Nodes on the

Installation Tree
Installation tree nodes are configured in hierarchical order.
z About the Enterprise node, page 28
z About Site Group Nodes (optional for larger deployments), page 29
z Creating Site Group Nodes, page 29
z Creating Site Nodes, page 30
About the Enterprise node

This node is the highest level node in the Installations tree, and exists by default
following the installation of the Enterprise Manager. The node represents the
customer’s entire organization, and cannot be deleted.
The default Enterprise node settings for an organizations are configured during the
Enterprise installation process. All other nodes are created beneath it.You can
create site nodes and sites from the Enterprise node settings screen.
About Site Group Nodes (optional for larger deployments)

This node falls directly below the Enterprise node. You create site group nodes to
represent major divisions in the customer’s organization, under which smaller sites are
organized.
Typically, site groups are created to either represent geographical divisions of an
enterprise, or separate lines-of-business at different geographical locations.
Once you are at the site group level, you can add other site group nodes, if required, or
site nodes. You cannot add a managed or external server.
Examples:
z Geographical divisions
You can create one site group to represent the Southern division of an enterprise,
and another site group to represent the Northern division. Below these nodes, you
then add Site nodes to represent the geographic locations of individual offices or
operations centers that comprise each of these divisions.
z Line-of-Business divisions
You can create site groups to represent such line-of-business divisions as Human
Resources, Credit Card Processing, or Call Centers.
Note that you would only use site groups to represent line-of-business divisions if
each of these divisions has offices in multiple locations (or sites) in the customer’s
enterprise. Otherwise, you would set up a site node to represent each line-of-
business, if they are all at the same location.
Creating Site Group Nodes

1 Navigate to System Management > Enterprise Management > Settings.
2 On the left panel, select the Enterprise node and click Create Site Group.
On the right panel, the Site Group screen displays.
3 In the Name and Description boxes, type a name for the site group and a
description of it. In general, the name should represent the business and location
related to that site group.
4 Click Save.
5 You can create further site group nodes below the one you just completed, or you
can begin creating site nodes (see Creating Site Nodes, page 30).
Creating Site Nodes

This node is a mandatory node you create beneath the site group node (if applicable) or
the Enterprise node itself, if the organization does not have multiple physical locations
and does not require site group nodes.
Generally, site nodes should represent offices or lines of businesses within an
organization.
NOTE Typically, in deployments other than Consolidated ones (which require
only a single server), you create site nodes that contain the Data Center
(database and application) zone servers or server clusters first.
Then you create site nodes for the Site (Recorder, Speech, VAM content
acquisition) zone servers, which may be physically co-located with the
Data Center servers, or at remote locations.
For more information on Data Center zones and Site zones, see
Deployment Zones, page 9.
Once you have added the site node, you can add servers (referred to as ‘creating
installations’ in Enterprise Manager).
Chapter 3 - Site Organization and Server Setup Adding Servers (Server/Installations Nodes) to the Installation Tree
To create a site node

1 Navigate to System Management > Enterprise Management > Settings and
on the left panel, select the site group node under which you want to create a site
node.
2 Click Create Site.
On the right panel, the Site screen displays.
3 In the Name and Description boxes, type a meaningful name for the site node,
and a description of it.
4 Click Save.
5 You can now either:
z Create a server cluster (see Creating and Managing Server Clusters (used in
larger deployments), page 34).
z Add a server to the site node (see Adding a Server node, page 32).
Adding Servers (Server/Installations Nodes)

to the Installation Tree
The server node can contain servers (also known as managed servers), search and
replay applications and external servers. This guide describes procedures to set up
managed servers, servers that can be managed and configured from the Enterprise
Manager.
NOTE For details on deployment of managed servers, see Appendix A, Working
with Deployment Levels, page 113.
You can also create server clusters, used in larger deployments to support load
balancing and high availability, and add servers to them. For details on creating and
managing server clusters and adding and configuring servers within the clusters, see
Creating and Managing Server Clusters (used in larger deployments), page 34.
NOTE For details on clustered servers, see Appendix A, High Availability and
Server Clusters, page 118.
See also:
z Creating a server template for copying server configuration information, page 33
z Adding a Server node, page 32
z Creating and Managing Server Clusters (used in larger deployments), page 34
Adding a Server node

on the left panel, select the site node to which you want to add servers.
NOTE If you are adding servers to an existing system, make sure to add the
servers to the correct deployment zone. For example, all application and
database servers should be added to the data center zone.
For details on deployment zones, see Deployment Zones, page 9.
2 Click Create Installation > Server.

On the right panel, the Server screen displays.
3 Complete the information as follows:
Field Description
Name Type the server name. Typically you enter the Host Name,
Fully Qualified domain name, or the server’s IP address.
Description Type (optional) description to describe the server.
Server Name. Type either the Host Name, FQDN address, Domain Name
System (DNS), or NetBIOS name of the server in this field.
Enterprise Manager uses this name to connect to this server.
By default this field contains the Name you entered above.
Warning: Avoid using the IP address as the Server Name,
since there may be issues using it, such the fact that the
server’s IP may change, and server’s server roles do not
support IP address identification.
Port Number If Secure Sockets Layer (SSL) is not being used to encrypt the
Enterprise Manager/server communication, this field shows
the port number (default 8080) that is to be used.
Field Description
SSL Port Number If Secure Sockets Layer (SSL) is being used to encrypt the
HTTP Alias By default, this field is automatically populated by the server

name in the Name field above.
An HTTP Alias is typically used in a clustered server scenario,
and can only be used with application servers (for details on
clustered servers, see Creating and Managing Server
Clusters (used in larger deployments), page 34).
Fully-Qualified Optionally, type the FQDN of the HTPP Alias (described above).
Domain Name
(FQDN)
Blocked Config Select this check box to prevent (block) configuration

Distribution messages received from the Enterprise Manager. In this case
the server cannot receive configuration changes or cache
updates from Enterprise Manager.
Clear the check box to unblock the server.
4 Repeat steps 2 and 3 for each server you want to add to this site node.
5 Click Save.
6 To see the server role nodes associated with the server cluster, select the primary
server, and expand it. For details on viewing the server roles see Viewing Server
Role Nodes, page 44.
7 Configure the server roles associated with each of the servers you added. For
details, see Chapter 5, “Server Role Configuration”.
Creating a server template for copying server configuration

information
If you need to do multiple server configurations for numerous sites, such as Recorder or
Speech transcription sites, create a server ‘template’ from which you can copy server
configuration information to the other servers in your installation tree.
When you copy server configuration, a server’s role settings, associations, and
component configurations are duplicated in one or more other servers of the same
version and service pack. Ensure the following:
Chapter 3 - Site Organization and Server Setup Creating and Managing Server Clusters (used in larger deployments)
z The source and target managed servers must be at the same version and service
pack level.
z Only server roles of the same type and same server role metadata version are
copied.
z Only the server roles settings and components that are available on the source
server are copied. Server roles existing on the target server, but not on the Source
server, are not affected by the copy operation.
z Associations (if any) are copied.
For details on server roles and associations, see Chapter 5, “Server Role Configuration”.
For details on copying server configurations, and other server administration topics, see
the Enterprise Manager Basics Guide.
Creating and Managing Server Clusters (used

in larger deployments)
Server clusters, used for larger deployments, consist of multiple servers with identical
server role configurations and associations, and appear below the site node. Server
clustering supports high availability and load balancing in the suite.
Server clusters can be created for Data Center zone application servers (these servers
contain the platforms that comprise application server roles), and are called Application
Server Clusters.
Within a server cluster, multiple managed servers work together to operate as a single
logical server. Each server in the cluster provides identical functionality and the multiple
servers appear to be a single server from the point of view of the end user.
A load-balancing device is deployed in front of the server cluster to ensure user
connections are equally distributed to the multiple servers in the cluster.
To change the cluster configuration, it is recommended to edit the configuration of the
server designated as the primary, regardless of the type of server cluster.
NOTE For details on high availability/load balancing and server clusters, see
Appendix C, High Availability and Server Clusters, page 118.
See:
z Creating a Server Cluster, page 35

z Creating Application Server Clusters that Include Active Framework Application
Server Roles, page 38
TIP Clusters created for servers with Framework Application server roles,
which manage both the Enterprise Manager application and other
applications in the suite, have additional pre-requisites and procedures.
z Changing Server Configuration in a Cluster, page 43
Creating a Server Cluster

Note the following about adding managed servers to a server cluster:
z The first server added to the server cluster becomes the primary server in the
cluster by default.
Subsequent servers added to the server cluster inherit the configuration of the
primary server. All pre-existing configurations on these servers are lost when the
servers are added to the cluster.
z All servers added to a server cluster must have the same server roles installed and
the roles must be of the same version. The servers do not need to have the same
server roles activated. The server roles are automatically activated and configured
to match the server role configuration of the primary server at the time a secondary
server is added to the cluster.
z Any server added to a cluster cannot be involved in any kind of redundant
relationship with another server in the environment. Specifically, a clustered server
cannot be part of either a Secondary Role relationship or an IP extension cluster.
z The creation of Application Server Clusters (where servers contain the Framework
Applications role) require additional steps/procedures. For these additional steps/
procedures, see Creating an Application Server Cluster, page 39.
To create a server cluster node and add servers to it

on the left panel, select the site node under which you want to create a server
cluster.
2 Click Create Server Cluster.
On the right panel, the Server Cluster screen displays.
In the Name and Description boxes, type a meaningful name for the server
cluster and a description.
3 Click Save.
4 On the left panel, select the server cluster you just created, do one of the following:
z If this is a fresh installation, click Create Installations > Server to add the first
server to the cluster.
z If you are expanding an existing cluster by adding a server to it, do the following:
i. Select the server you adding to the cluster, click More Actions > Move
Installation.
ii. Select the server cluster you are expanding, and then click Save.
The server is moved, and assumes the same configuration (role settings,
associations and legacy associations) as the other servers in the cluster to which
it was moved. Any settings that existed prior to the server being added are lost.
The moved server assumes the HTTP Alias of the new cluster.
5 Configure the first server as follows, or verify the settings in the cluster you just
expanded:
Field Description
Name Type the name of the managed server being added. This name
is at your discretion, but it is recommended that you enter
either the Host Name, Fully-Qualified Domain Name, or IP
address of the managed server.
Note: The name you enter here also automatically populates
the Server Name field and the HTTP Alias field. The Server
Name field must contain either the Host Name, Fully-Qualified
Domain Name (FQDN), or IP address. If you do not enter the
Host Name, FQDN, or IP address in this field, you must
manually edit the Server Name field. You must alter the HTTP
Alias field so that the HTTP Alias field specifies the address of
the load balancing device that supports the cluster.
Description Type (optional) description to describe the server.
Server Name. Type either the Host Name, FQDN, or IP address of the server
in this field. Enterprise Manager uses this name to connect to
this server.
By default this field contains the Name you entered above.
Warning: Entering the IP address may cause problems with
system functionality, especially if the IP address changes.
Port Number If Secure Sockets Layer (SSL) is not being used to encrypt the
SSL Port Number If Secure Sockets Layer (SSL) is being used to encrypt the
Field Description
HTTP Alias Type the HTTP address of the load-balancing device that is
used to distribute user connections to the servers in the
cluster.
Note: Users connect to the load-balancing device that is used
to distribute user connections to the servers in the cluster. The
load-balancing device distributes user connections equally
among the clustered servers.
Note: ITS clusters (related to speech analytics) do NOT have
load balancing devices, and the HTTP Alias can be set as the
primary server in the cluster (the HTTP Alias in this context
does not have any functionality).
Note: If you are clustering a server that includes Enterprise
Manager, with the Framework Applications server role
activated, you must also specify the address of the load
balancing device in the Enterprise Manager Locations tab.
For details, see Creating an Application Server Cluster,
page 39.
Fully-Qualified Type the FQDN of the HTPP Alias (described above).

Domain Name
(FQDN)
Blocked Select this check box to prevent (or block) the clustered server
from receiving configuration changes or cache updates from
Enterprise Manager.
Clear the check mark from this check box to unblock the
server. When the server is unblocked, it can receive
configuration messages and cache updates from Enterprise
Manager.
Primary Select this check box to establish this server as the primary
server in the cluster.
Subsequent servers added to the cluster inherit the
configuration of the primary server in the cluster.
It is recommended that you access the primary server to
make all configuration changes, as noted in Changing Server
Configuration in a Cluster on page 43.
By default, this check box is selected for the first server added
to the cluster and is not selected for subsequent servers added
to the cluster.
For more details on making configuration changes to server
clusters, see the Enterprise Manager Reference Guide.
6 Configure the cluster server roles and associations.

NOTE Servers that operate in a cluster have identical sets of server role
configurations, so that the same set of server roles are activated, and the
same server role settings and associations are configured on each server
in a cluster.
If you make any configuration change to a server role on one server in the
cluster, the same configuration change is automatically made on the other
servers in the cluster.
For example, if you deactivate a server role on one server in the cluster,
the same role is automatically deactivated on all servers in the cluster. If
you change any server role setting on one server in the cluster, the same
role setting is automatically changed on all servers in the cluster.
For details on configuring individual server roles, see Chapter 5, “Server
Role Configuration”.
7 Add additional servers to the cluster as required. These servers inherit the
configuration you set up for the first (or primary) server.
8 Click Save.
NOTE If you created an application server cluster, and one of the application
servers is assigned a new IP address by the DHCP server, you must
manually restart all the servers in the cluster.
9 You can now view the server role nodes on the server you’ve added and configured.
For details, see Viewing Server Role Nodes, page 44.
Creating Application Server Clusters that Include Active

Framework Application Server Roles
This section describes all procedures associated with creating a cluster of servers that
have the Framework Applications server role.
This type of cluster supports a clustered version of Enterprise Manager as well as

clustered versions of the other applications supported by the Framework Applications
server role.
See:
z Prerequisites, page 39
z Creating an Application Server Cluster, page 39
z Adding Servers to Functioning Application Server Clusters, page 42
Prerequisites
Before you can create this kind of server cluster, all of the following prerequisite tasks
must be performed. The tasks must be performed in the order listed.
IMPORTANT All of the servers that you install as part of the cluster mustinclude the same
server roles and alarm definitions. Also the server roles and alarm
definitions on each server must be of the same version. Otherwise, you
will not be able to add the servers to the Application Server Cluster in a
subsequent procedure.
These prerequisite tasks must be performed before you can create an Application Server
Cluster.
1 Install the database to which the managed servers (servers containing the
Framework Applications server role) will connect.
2 Install the first managed server (Server1 in this example) and connect it to the
database.
3 Install the additional managed servers and connect them to the same database. All
servers in the cluster must connect to the same database.
4 Activate the license on Server1 for the number of servers that will operate as part of
the cluster.
5 Install the load balancing device. You should know the address required to connect
to the load balancing device before beginning the procedure below.
IMPORTANT Do not configure the servers to connect to the load balancing device at this time.
The servers must be added to the cluster from Enterprise Manager before they are
connected to the load balancing device, as noted in the procedure below.
Creating an Application Server Cluster

When you have completed the prerequisite tasks, use Enterprise Manager to create the
server cluster.
IMPORTANT Follow the steps below exactly in the order described, otherwise the cluster may
not function. In particular, be sure to add the servers to the cluster in Enterprise
Manager before the servers are added to the load balancer. If the servers are
added to the load balancer before they are added to the cluster, it may be
necessary to manually refresh the cache on each of the clustered servers to make
the cluster function properly.
Also, once you begin this procedure, complete the entire procedure before using
Enterprise Manager to make any kind of configuration change that is not part of
the clustering procedure described below.
1 Navigate to the System Management > General Settings > Enterprise

Manager Location tab, and enter the Server Name and Port Number for the
server that will operate as the primary server in the cluster:
2 Navigate to the System Management > Enterprise Management > Enterprise
Settings tab, and ensure that a valid username and password are entered in the
Application Service Account Username and Password fields.
If the username and password are not specified, you must enter a valid username
and password in these fields and save the settings. For details, see Configuring
General Enterprise Settings, page 48.
3 In the Installations tree, create the Site node under which you want the server
cluster to reside, as described in Creating Site Nodes, page 30.
4 Create a Server Cluster node beneath the Site node and add the first server (for
example Server1) to the node, as described in To create a server cluster node and
add servers to it, page 35.
NOTE The first server added to the Server Cluster node automatically becomes
the primary server in the cluster. Subsequent servers added to the cluster
inherit the configuration of this server.
5 In the Installations tree, activate the Framework Applications server role, as

described below:
a. Select the Server Cluster node added in step 4 above.
b. Select the Server Roles tab.
c. Select the Framework Applications server role and click Save to activate the
role.
Optionally, you can activate other server roles on the selected server. Note that
the Framework Applications server role must be active for Enterprise Manager to
function.
NOTE When you add additional servers to the cluster in a subsequent step, the
additional servers automatically assume the same configuration as the
first server added to the cluster, including the server role configuration.
6 After you activate the server role(s), a Pending Messages icon (asterisk) appears at
the top of the screen while Enterprise Manager processes the configuration change.
Wait for the Pending Messages icon to disappear before continuing to the next step.
It may take a few minutes for the icon to disappear.
7 Add each of the remaining servers to the server cluster, as described in “To create a
server cluster node and add servers to it” on page 35.
IMPORTANT When adding each server to the server cluster, be sure to specify the address of
the load balancing device in the HTTP Alias setting for the server. While this
setting is not required for connectivity to the Enterprise Manager, it is required for
connectivity to the other applications supported by the Framework Applications
server role.
8 After adding the remaining servers to the server cluster, the Pending Messages icon
appears while Enterprise Manager processes the configuration changes. Again, wait
for the Pending Messages icon to disappear before continuing to the next step.
9 If it was necessary to enter a valid username and password in the Application
Service Account fields in step 2, you must restart the UCM services on the primary
server in the server cluster (Server1 in this example). Restart these services from
the Services dialog in Windows.
Skip this step if it was not necessary to enter a valid username and password in
step 2.
10 Restart the wfo service on the primary server in the cluster. Restart this service
from the Services dialog in Windows.
After restarting this service, do not proceed to the next step until you are able to
login to the Enterprise Portal web application (containing the Enterprise Manager
and other applications).
11 If it was necessary to enter a valid username and password in the Application
Service Account fields in step 2, restart the UCM services on each of the remaining
(non-primary) servers in the cluster.
12 Restart the wfo service on each of the remaining (secondary) servers in the cluster.
13 Perform the following check to verify the cache is set up correctly and the cluster is
functioning.
a. Click System Management > General Settings > Cache.
b. In the Cache Viewer screen, verify the following to ensure the cache is set up
correctly and the cluster is functioning:
z Each server in the cluster must be listed under the Host column.
z Each server in the cluster must be listed under the ServerName from DB
column.
z For each server in the cluster, the value Yes must appear under the Cache is
Clustered column.
z For each server in the cluster the value Yes must appear under the
Synchronized column.
14 Connect all servers in the cluster (both primary and secondary) to the load
balancing device.
15 In the System Management > General Settings > Enterprise Manager
Location tab, enter the connection information for the load balancing device.
In the Enterprise Manager Location tab, you must specify the server name
(hostname, IP address, or FQDN) and port number required to connect to the load
balancing device.
Adding Servers to Functioning Application Server Clusters

After you have a functioning Application Server Cluster that supports the Framework
Applications server role (and therefore the Enterprise Manager application), you can
expand the server cluster by adding additional servers to it.
Follow the instructions below to add an additional server to a functioning server cluster.
IMPORTANT Any server added to a functioning server cluster must include the same server
roles and alarm definitions as the existing servers in the cluster.
1 Install the server and connect it to the same database to which the other servers in
the cluster are connected.
Do not connect the server to the load balancing device at this time.
2 Add a the server to the Server Cluster node, as described in “To create a server
cluster node and add servers to it” on page 35.
3 After you add the server to the Server Cluster node, a Pending Messages icon
(asterisk) appears at the top of the screen while Enterprise Manager processes the
configuration change.
Wait for the Pending Messages icon to disappear before continuing to the next step.
It may take a few minutes for the icon to disappear.
4 On the newly added server, restart these services from the Windows Services
dialog:
z UCM services
z wfo service
5 Verify the cache is set up correctly and the cluster is functioning.
You can perform the following check to verify that the cache is set up correctly and
the cluster is functioning:
a. Click System Management > General Settings > Cache.
b. In the Cache Viewer screen, all of the servers in the cluster should be listed
under the Host and the ServerNamefromDB columns. For each server, the
screen should indicate that the Cache is Clustered and the server is
Synchronized.
6 Connect the newly-added server to the load balancing device.

NOTE If you created an application server cluster, and one of the application
servers is assigned a new IP address by the DHCP server, you must
manually restart all the servers in the cluster.
Changing Server Configuration in a Cluster

It is recommended that you use the primary server in the cluster to make configuration
changes to any cluster. Configuration changes made on the primary server are
automatically replicated to the other servers in the cluster.
Servers that operate in a cluster have identical sets of server role configurations, (that
is, they have the same set of active server roles, and the same server role settings and
associations).
If you make any configuration change to a server role on one server in the cluster, the
same configuration change is automatically made on the other servers in the cluster.
For example, if you deactivate a server role on one server in the cluster, the same role is
automatically deactivated on all servers in the cluster. If you change any server role
setting on one server in the cluster, the same role setting is automatically changed on all
servers in the cluster.
See:
z Moving and Removing Servers in a Cluster, page 43
z Creating and Editing Role Associations in a Cluster, page 44
z Patching Servers in a Server Cluster, page 44
Moving and Removing Servers in a Cluster

Move and remove servers in a cluster to place a server into another cluster (which will
have a different server cluster configuration), or to place it in a non-clustered Site Group
or Site. If placed into another cluster, the moved server assumes the configuration
settings (including the HTTP Alias) of the primary server in that cluster.
To move and remove servers in a cluster:

1 Click on System Management > Enterprise Management > Settings.
2 In the installations tree (left pane), select a server in a cluster.
3 Click More Actions > Move Installation. The installation tree displays in the right
pane.
a. Select another server cluster, and then click Save. The server is moved, and
assumes the same configuration (role settings, associations and legacy
associations) as the other servers in the new cluster. Any settings that existed
prior to the server being added are lost. The moved server assumes the HTTP
Alias of the new cluster.
Chapter 3 - Site Organization and Server Setup Viewing Server Role Nodes
b. Select any non-clustered Site Group or Site, and then click Save. The server is
removed from the cluster and moved to the non-clustered Site Group or Site.
The server retains the configuration settings it had when it was a member of a
cluster.
Creating and Editing Role Associations in a Cluster

When you create or edit a server role association on one server role in a server cluster,
the same association is automatically made for all other server roles of the same type
that exist in the cluster. This functionality ensures that all server roles in the cluster that
are of the same type maintain the identical server role associations.
To create or edit role associations in a cluster:

1 In the Installations pane select any role in a server in a cluster, and then click
Associations. All roles that can be associated are displayed in the right pane.
NOTE Within the cluster, only the cluster name and its server roles display. Servers in the
cluster do not display.
2 Select one or more roles in the cluster, or make any necessary changes, and then
click Save.
Patching Servers in a Server Cluster

Update Servers in a cluster (also known as patching) to update server role metadata or
add a new role on a server. No action is necessary, except for actually updating the roles
in all the servers in the cluster. When you update, or patch, a server role on a clustered
server, the other servers in the cluster are not also patched automatically. You must
patch each server individually.
When Enterprise Manager detects a configuration difference in servers in a server
cluster, a warning message displays, and all communications are temporarily blocked
until server configuration consistency across the cluster is restored. Once restored, all
servers in the cluster are automatically unblocked.
Viewing Server Role Nodes

Server roles are at the lowest level of the installation tree.
Server roles are a predefined set of software components that when properly configured
in Enterprise Manager control the functionality of the suite applications for which the
customer is licensed.
Depending on the customer’s deployment, you may have a single server that contains
the set of all server roles required for a deployment (referred to as a Consolidated
Chapter 3 - Site Organization and Server Setup Viewing Server Role Nodes
platform), or several servers, each containing platforms with different sets of server
roles. Multiple servers/sets of server roles are used in larger deployments.
To view the server roles associated with a server, click beside the Server node to expand
the server role list.
For details regarding server roles, the platforms they belong to and how to configure
them, see Chapter 5, “Server Role Configuration”.
Chapter 4
Enterprise Settings and

Security
This section describes the screens used for Enterprise settings and security.
z About Enterprise and Security Settings, page 47
z General Enterprise Settings, page 47
z Using the Authentication/Single Sign-On (SSO) Process, page 57
z Encrypting connections with SSL, page 59
Chapter 4 - Enterprise Settings and Security About Enterprise and Security Settings
About Enterprise and Security Settings

After setting up the installation tree and its components, you configure the default
Enterprise and Security settings in Enterprise Manager.
You may also need to authenticate connections to servers.
General Enterprise Settings
Enterprise Settings are configured at the Enterprise node level, and apply to all
managed servers in all Site Groups and Sites in the Enterprise.
When you add a new Site Group, Site, or Server node to the Installations tree, the
added node inherits the Enterprise Settings from its parent node. You cannot modify any
of the Enterprise Settings from a Server node of the Installations tree.
When you change Enterprise Settings, it may be necessary to restart services on the
managed servers. If this is the case, one alarm is raised in the System Monitor on the
affected server for each service that must be restarted.
Security Enterprise Settings
Many of the security settings are configurable only at the Enterprise node and apply to
all managed servers deployed in the enterprise.
When you change Security Settings, it may be necessary to restart services on the
managed servers. If this is the case, one alarm is raised in the System Monitor on the
affected server for each service that must be restarted.
Authentication of Connections to Managed Server(s)
The Enterprise Manager establishes an HTTP(S) connection to the Enterprise Manager

Agent (EMA).
The EMA on the managed server authenticates connections from the Enterprise
Manager. This authentication process ensures that the EMA accepts configuration
changes only from a trusted instance of the Enterprise Manager application.
SSL Encryptions
For maximum security, you can encrypt Enterprise Manager-related communications

with SSL.
For details on working with each of the features described above, see:
z Configuring General Enterprise Settings, page 48
z Configuring Enterprise Security Settings, page 54
z Working with the Authentication Server and Authconfig.xml, page 57
Once you have configured required settings, you are ready to start configuring the
Enterprise suite products you installed. For details, see Chapter 3, “Site Organization
and Server Setup”.
Chapter 4 - Enterprise Settings and Security Configuring General Enterprise Settings
Configuring General Enterprise Settings

1 Access the suite’s portal’s logon screen and enter the default administrator’s logon
ID and password.
2 Navigate to System Management > Enterprise Management > Settings,
select the Enterprise node, then select Enterprise Settings.
The Enterprise window displays.
3 Make settings changes according to the following:
Item Description
Calendar Settings
First Day of the Specify the day that is considered the first day of the week in your part of
Week the world. This day will be listed as the first day of the week in the user
interfaces of your suite portal applications.
Note: This setting is not configured for Scorecards in Enterprise
Manager. For Scorecards, the setting is configured during installation
itself and cannot be changed.
First Day settings for other applications are configured in other parts of
the system (for example, for Workforce Management, they are configured
by organization and campaign in the web application).
For more details on First Day settings in the system, see First Day
Settings, page 54.
Starting Date of Select the starting month and day (mm/dd) of the fiscal year for your
the Fiscal Year enterprise. The year is not needed. This information is required by some
suite portal applications.
Item Description
Locale Settings
Default Language Specify the language to be used in the user interfaces of all suite portal
applications (including Enterprise Manager).
Default Regional Specify the regional formats appropriate for your part of the world. The
Format regional formats affect the display of the following in all suite portal
applications (including Enterprise Manager):
z Date (short and long formats, order, separator)
z Time (12 or 24 and relevant symbols, separator, leading zero)
z Currency (symbol, number settings)
z Number settings (000 separator, decimal point character)
Default Time Zone Specify the time zone appropriate for your location. This setting can be
overridden by individual users in their User Preferences settings.
Access Settings
Management Specify the username of the Windows user account that managed servers
Service Account use to access services in the system.
Username This username must be from a valid Windows user account in the
Windows domain in which the Enterprise Manager and the managed
servers in your system reside. This Windows user account should be used
only for this purpose.
Management Specify the password associated with the Windows user account (specified
Service Account above) that managed servers use to access various services in the
Password system.
Following a system upgrade, these settings are not automatically populated. For details, see
the Note below following this procedure.
Maintenance Times Settings
Day of Week for Specify the day of the week in which you want the weekly maintenance
Weekly jobs to run on all managed servers in the Enterprise.
Maintenance These maintenance jobs run in the background once per week on a
managed server at the scheduled time. These jobs perform maintenance
procedures to clean up and optimize the managed server. These jobs
should be scheduled at the time of the lowest system usage as they
consume system resources and can adversely affect system performance.
Weekly Specify the day and the hour when you want the weekly maintenance
Maintenance Start tasks to run.
Time This setting applies to all managed servers in the suite, and uses the time
zone within which each server is located.
For example, if you select Saturday, 1:00 p.m. as the time for the weekly
maintenance tasks to run, they will run at 1:00 p.m. on Saturday in each
server’s local time zone.
Item Description
Weekly Specify the time in minutes that you want the weekly maintenance jobs to
Maintenance run. If the maintenance jobs exceed the specified time limit, an alarm is
Duration raised.
Daily Maintenance Specify the time of day when you when you want the daily maintenance
Start Time tasks to run.
These maintenance jobs run in the background once per day on each
managed server at the scheduled time. These jobs perform maintenance
procedures to clean up and optimize the server, and should be scheduled
at the time of lowest system usage as they consume system resources
and can adversely affect system performance.
This setting applies to all managed servers in the suite, and uses the time
zone within which each server is located.
For example, if you select 11:00 p.m. as the time for the daily
maintenance tasks to run, they will run at 11:00 p.m. in each server’s
local time zone.
Daily Maintenance Specify the time in minutes that you want the daily maintenance jobs to
Duration run. If the maintenance jobs exceed the specified time limit, an alarm is
raised.
Use Custom Select this option if you are using a customized schedule defined in an
Schedule external tool (for example, SQL Enterprise Manager) to perform
maintenance procedures. When this option is selected, the other
maintenance scheduling fields in this section are disabled and the weekly
and daily maintenance jobs described above do not run.
SMTP Settings
SMTP Server Enter the server host name, IP address, or the Fully-Qualified Domain
Name (FQDN) of the SMTP server used by the managed servers.
Servers use this address to connect to the SMTP server to send an email
(for example, to notify an administrator of a triggered alarm).
SMTP Port Enter the port on which the SMTP server listens for connections from the
managed servers.
Secondary SMTP Enter the server host name, IP address, or the FQDN of the secondary
Server SMTP server used by the managed servers.
Servers will access this SMTP server to send email if the primary SMTP
server is unavailable.
Secondary SMTP Enter the port on which the secondary SMTP server listens for connections
Server Port from managed servers.
Return Email Enter the return email address to appear in emails that are sent on behalf
Address of the managed servers.
When a user replies to a server-generated email, the reply is sent to this
email address.
Use Select this option if you want the managed servers to present
Authentication authentication credentials to the SMTP server when connecting to the
SMTP server. Specify these credentials below.
Item Description
Username This field is required only if you select the Use Authentication option.
Enter the domain and username of the SMTP server account that the
managed servers use to authenticate when connecting to the SMTP
server. Enter the username in the format Domain\Username.
This must be a username associated with a valid account on the SMTP
server.
Password Enter the password associated with the SMTP server account that the
managed servers use to authenticate when connecting to the SMTP
server.
This field is required only if you select the Use Authentication option.
System Backup Settings
System Backup Each managed server stores some, but not all, of its configuration data in
various databases.
Select this option if you also want to store backup copies of the managed
server XML configuration and properties files that are not stored in any
database. Storing these files ensures that you have backup copies of all
configuration files if it is necessary to completely restore the configuration
of a managed server.
For more information about the specific files backed up by this feature,
see the Avaya Aura WFO Maintenance Guide.
When you select this option, use the System Backup Path field below to
specify the network location where you want to store the backup copies of
these XML files.
System Backup Specify the Universal Naming Convention (UNC) path to the specific
Path server and directory where you want to store the backup copies of the
Server XML configuration and properties files (for example:
\\ComputerName\FolderName). This server and directory must be
accessible on the network from the managed servers.
You can modify this setting at the Site Group or Site node of the
Installations tree. The network location specified here must be accessible
by all of the managed servers in the selected Site Group or Site.
You cannot store the backup copies of the configuration and properties
files on the local physical drive of the computer hosting Enterprise
Manager.
NOTE The Access settings and the System Backup settings are the only
groups of Enterprise Settings that can be overridden (configured) at the
Site Group and Site nodes of the Installations tree. All other Enterprise
Settings are configured at the Enterprise node and apply to all managed
servers in the enterprise; none of the other settings can be overridden at
lower nodes of the Installations tree.
z Click Save. When you click Save, the changes are applied to the selected node.
The changes are also applied to a child node if the child node has not been
previously altered from its default state and saved.
If a child node has been previously altered and saved, changes are not sent to
the child node when you click Save. In this case, you must click the Save and
Apply to Children button to apply the changes to the child node.
z Click Save and Apply to Children to apply changes to all managed servers
below the selected node. For example, with a Site Group selected, click Save and
Apply to Children to pass updated settings to all managed servers in Sites in the
Site Group.
5 Check the System Management > System Monitor > Alarm Status tab for new
alarms that indicate it is necessary to restart services. If these alarms appear,
restart the services indicated by the alarms.
NOTE In some cases, changes to the Enterprise Settings necessitate the
restarting of services on some managed servers. If this is necessary,
an alarm is raised in the System Monitor on the affected server. It
may take several minutes after changing the Enterprise Settings for
these alarms to be raised in Enterprise Manager. One alarm is raised
for each service that must be restarted.
NOTE If you are upgrading from earlier versions of the suite, the upgrade
process does NOT automatically populate the Management Service
Account Username and Management Service Account Password
fields.
1 After the upgrade process, navigate to System Management >
Enterprise Management > Settings, select the Enterprise
Node and click the Enterprise Settings tab.
2 Scroll down to the Access area, and in the Management Service

Account Username and Management Service Account Password
fields, enter the correct user name and password.
For more details, see the table above, where it describes Access
Settings.
Chapter 4 - Enterprise Settings and Security Configuring Enterprise Security Settings
First Day Settings

The following table outlines the impact of First Day settings on different applications in
the system, at what point the settings are configured, and whether settings can be
changed after they have been saved.
Application Setting Configuration Can Change Feature

Scope Stage after Purpose
Installation/
Configuration
Scorecards Enterprise- During Cannot be Defines how

wide (one Scorecards changed after weekly KPIs are
per system) database system defined.
installation, installation.
using the SR
installer
Workforce Per During creation/ Can be changed Defines how WFM

Management Organization configuration of as required. workrules and
in User organizations in work rule
Management User assignments are
and per Management as interpreted by the
Campaign well as setting scheduler. It also
work rules for defines how
campaigns in reports are
Workforce aggregated. It also
Management. defines how
various calendars
are displayed in
WFM.
Configuring Enterprise Security Settings

Configure the settings on the Security tab to support encryption of recorded data,
secure communications within the system with SSL, and to specify timeout intervals for
applications.
Note that some settings are configurable from only the Enterprise node, and others can
be configured from the Enterprise, Site Group or Site nodes on the installation tree.
To configure security settings:

1 Click System Management > Enterprise Management > Security
2 In the Installations tree (left pane), select the node from which you want to
configure the Security settings. Some settings are configurable only from the
Enterprise node, as noted in the table below.
3 Complete the settings window according to the following:
Item Description
Enterprise Select the Enterprise node and then click the Security tab and complete
the following:
General settings - The General Security settings allow you to configure
the following:
- Security Token PassPhrase - Not applicable to this release.
- Security Token Timeout Period - Not applicable to this release.
- Restrict Application Server to SSL Only - Use this setting to tighten
security by restricting all communication with the application server to
SSL only. When this setting is selected no HTTP connections are allowed
to the application server; only HTTPS connections are allowed.
z SSL setting - Select the Enable SSL setting in if you want to secure
managed servers in the system with SSL. Note that selecting the
Enable SSL option alone does not implement SSL encryption. You
must also perform supporting procedures (such as installing SSL
certificates and configuring Web Servers to support SSL) as described
in the Security Overview and SSL Configuration Guide to implement the
SSL encryption.
z Data-At-Rest Encryption - Not applicable to this release
z Screen Encryption - Not applicable to this release
z Encryption Management - Not applicable to this release.
z Application Security - Use these settings in the Security tab available
from the Enterprise node to set timeout intervals for inactive
applications inthe Enterprise suite.These settings require a user to log
in to applications that are open but have not been used for a specified
period of time. This security precaution prevents an unauthorized user
from accessing the system through an application that is left open on
an unattended computer. The two Application Security Settings include:
z Session Timeout - Specifies the time interval for which an open
application must be in an inactive state before requiring the user to log
in again.
z Apply Session Timeout to Auto Refresh Pages Some applications
contain auto-refresh pages. You must select this option to apply the
Session Timeout interval to these applications. If you do not select this
option, the auto-refresh pages are seen as user activity, and the
application will not timeout at the specified Session Timeout interval.
Site Group Select a Site Group node in the Installations tree, and then select the
Security tab to configure any of the following settings. All other Security
settings are inherited from the parent node and cannot be changed.
z Enable SSL - Use this setting to override the Enable SSL setting that
was inherited from the Enterprise node. You can either enable or
disable SSL for all of the managed servers in the selected Site
Group.You may want to enable SSL for Site Groups that handle
sensitive data while disabling it for Site Groups that do not.
z Enable Data-At-Rest Encryption - Not applicable to this release.
z Encrypt Screen Content in Transit - Not applicable to this release.
Item Description
Site Select a Site node in the Installations tree, and then select the Security
tab to configure any of the following settings.
z Enable SSL - Use this setting to override the Enable SSL setting that
was inherited from the parent node. You can either enable or disable
SSL for all of the managed servers in the selected Site.You may want to
enable SSL for Sites that handle sensitive data while disabling it for
Sites that do not.
z Enable Data-At-Rest Encryption - Not applicable to this release.
z Encrypt Screen Content in Transit - Not applicable to this release
Server The Security tab appears at the Server node, but all settings are read-
only. The settings are inherited from the parent node and cannot be
changed at the Server node.

z Click Save. When you click Save, the changes are applied to the selected node.
The changes are also applied to a child node if the child node has not been
previously altered from its default state and saved.
If a child node has been previously altered and saved, changes are not sent to
the child node when you click Save. In this case, you must click the Save and
Apply to Children button to apply the changes to the child node. Refer to the
Security Installation and Configuration Guide for more information.
z Click Save and Apply to Children to apply changes to all managed servers
below the selected node. For example, with a Site Group selected, click Save and
Apply to Children to pass updated settings to all managed servers in Sites in the
Site Group.
Warning: Even though you have updated the child nodes in a Site Group or Site,
clicking Save and Apply to Children overwrites all the changes to all the managed
servers in any Site Group or Site below the selected node.
5 Check the System Management > System Monitor > Alarm Status tab for new
alarms that indicate it is necessary to restart services. If these alarms appear,
restart the services indicated by the alarms.
In some cases, changes to the Security settings necessitate the restarting of
services on some managed servers. If this is necessary, an alarm is raised in the
System Monitor on the affected server. It may take several minutes after changing
the Security settings for these alarms to be raised. One alarm is raised for each
service that must be restarted.
Chapter 4 - Enterprise Settings and Security Authenticating Connections to Managed Server(s)
Authenticating Connections to Managed

Server(s)
For details on working with the authentication process, see:
z Working with the Authentication Server and Authconfig.xml, page 57
z Using the Authentication/Single Sign-On (SSO) Process, page 57
z Replacing the Enterprise Manager, page 58
Working with the Authentication Server and Authconfig.xml

Before you can understand the authentication process that occurs when the Enterprise
Manager connects to a managed server, you need to be aware of these two important
entities involved in the authentication process:
z Authentication server - The Enterprise Manager operates as an authentication
server for the EMA. The authentication server software on
Enterprise Manager (which exists by default) validates tokens that are transmitted
to it by the EMA on the managed server, as discussed in
Using the Authentication/Single Sign-On (SSO) Process on page 57.
z Authconfig.xml - Each managed server has an authconfig.xml file. The
authconfig.xml file stores the location of the authentication server on the
Enterprise Manager and uses this information to connect to the authentication
server.
The first time you add a managed server to the Enterprise Manager Installations tree,
the Enterprise Manager transmits to the managed server the location of the
authentication server. The managed server writes this location information to its
authconfig.xml file.
The authentication server location information transmitted to the managed server is the
Server name and port number that is specified in the Enterprise Manager Location
tab in Enterprise Manager (to access this tab, select System Management > General
Settings > Enterprise Manager Location).
Using the Authentication/Single Sign-On (SSO) Process

The following authentication process occurs when a user logs into Enterprise Manager.
This authentication process enables the user to configure and monitor the managed
servers from Enterprise Manager. This process also supports single sign-on.
1 Enterprise Manager initiates an HTTP(S) connection to the Enterprise Manager
Agent (EMA) on the managed server.
The Enterprise Manager generates a token and sends it to the EMA on the managed server.
This token includes information about the user
initiating the connection (for example, an administrator or the Enterprise Manager
itself).
2 The EMA on the managed server receives the token.

3 The EMA looks at the authconfig.xml file to determine the
location of the authentication server on the Enterprise Manager server.
4 The EMA creates an HTTP(S) connection back to the
authentication server on the Enterprise Manager.
5 The EMA makes a request to the authentication server on the
Enterprise Manager to validate the token it received in step 3.
6 The authentication server on the Enterprise Manager validates the token (verifies
that this instance of the Enterprise Manager originally sent the token).
If the Enterprise Manager did not originally send this token, the authentication fails.
This aspect of the authentication process prevents users from making changes to
managed servers from an Enterprise Manager other than the one specified in the
authconfig.xml file on the managed server.
If the Enterprise Manager originally sent the token, the authentication process
continues to the next step.
7 The Enterprise Manager retrieves information about the user specified in the token.
This information includes a user profile, the security privileges assigned to the user,
and the user preferences for the user.
8 The Enterprise Manager sends to the EMA the information
about the user (user profile, user security privileges, and user preferences). This
information is sent in XML files.
9 The EMA receives the information about the user and creates a
user session. The EMA applies the appropriate user security
privileges and user preferences to this session.
10 The user (administrator or Enterprise Manager application) can now make
configuration changes and interact with the managed server according to the
security privileges and user preferences specified for that user.
Replacing the Enterprise Manager

This section discusses how the authentication process is handled when you replace an
existing instance of the Enterprise Manager with a new Enterprise Manager that resides
on a different server.
NOTE You can have only one instance of the Enterprise Manager operating in your
enterprise at a time. You cannot use multiple instances of Enterprise Manager to
manage your enterprise.
There are two exceptions to this rule. You can cluster multiple Enterprise Managers
so that the multiple Enterprise Managers operate as a single logical Enterprise
Manager. Also, when replacing an Enterprise Manager with a different Enterprise
Manager, you can have two Enterprise Managers operating in the same enterprise,
but only for a brief period as you transition from the old Enterprise Manager to the
new one, as discussed below.
If you elect to replace your existing Enterprise Manager, you must ensure the managed
servers can authenticate tokens generated on the new instance of Enterprise Manager.
1 Install the new instance of Enterprise Manager.

2 In the existing instance of Enterprise Manager (the one that you are replacing),
select System Management > General Settings > Enterprise Manager
Location.
3 In the Enterprise Manager Location tab of the existing instance of Enterprise
Manager, specify the Server name, Port Number, and Context setting for the new
instance of Enterprise Manager.
4 Click the Save button.
5 Click the Update EM Location button.
When you click the Update EM Location button, the connection information for the
new Enterprise Manager is transmitted to all managed servers that are managed by
the existing version of the Enterprise Manager. The managed servers write this new
connection information to their authconfig.xml files and can then authenticate
connections from the new version of the Enterprise Manager.
The user should be aware of the following point regarding the process described above:
z The managed server maintains two authentication server entries in its
authconfig.xml file: a Primary authentication server entry and a Secondary
authentication server entry.
When you perform the process above, the managed server specifies the new
Enterprise Manager as the Primary authentication server and the existing Enterprise
Manager as the Secondary authentication server.
The managed server can authenticate connections from either the Primary
authentication server or the Secondary authentication server. This capability means
that managed servers can authenticate connections from both the new Enterprise
Manager and the existing Enterprise Manager while you are transitioning the control
of your environment to the new Enterprise Manager.
Encrypting connections with SSL

For maximum security, you can encrypt Enterprise Manager-related communications
with SSL. Specifically, you can encrypt each of the following connections with SSL:
z The Web browser to Enterprise Manager connection - A user accesses the Enterprise
Manager with a web browser. You can encrypt all data that passes between the
user’s Web browser and the Enterprise Manager server with SSL.
z The Enterprise Manager to Enterprise Manager Agent connection - The Enterprise
Manager connects to the Enterprise Manager Agent to transmit configuration
information to and receive alarm and status information from the Enterprise
Manager Agent on the managed server. This connection can be encrypted with SSL.
Chapter 5
Server Role Configuration
The sections that follow provide a descriptive overview of server roles and detailed
descriptions on configuring each server role’s parameters.
z Overview, page 61
z Mapping Server Roles to Platforms, page 61
z Activating/Deactivating Server Roles, page 64
z Configuring Server Roles, page 65
z Configuration Details: Data Center Zone Server Roles, page 67
Chapter 5 - Server Role Configuration Overview
Overview
Once a customer’s license and products are activated, as described in Chapter 2,
“License and Product Activation”, you can use Enterprise Manager to see the available
server roles installed on each server.
After completion of the Enterprise hierarchy and server node set up as described in
Chapter 3, “Site Organization and Server Setup”, you are ready to activate server roles,
configure recording channels for recorders (if applicable), and finally configure the
server roles installed on each server, in order to achieve the product functionality for
which the customer is licensed.
See:
z Mapping Server Roles to Platforms, page 61
z About Activating or Deactivating Server Roles, page 62
z Configuration Details: Data Center Zone Server Roles, page 67
Mapping Server Roles to Platforms

During installation, each server used in the suite deployment is installed with a selected
platform. Each platform is comprised of specific server roles that support database and
application functionality, and all server roles are installed automatically, though not all of
these server roles are activated.
Chapter 5 - Server Role Configuration About Activating or Deactivating Server Roles
Installing a platform installs all the server roles that are mapped to that platform, as
shown in the table below.
The number of server platforms installed and configured for the customer’s Enterprise
Suite solution depends on the size of the deployment.
For example, if you are installing and configuring a single server deployment (Level
1 deployment), you install a single server that contains the Consolidated platform,
comprising all server roles. This is one of the most common deployments types.
In a distributed server deployment scenario (Level 2 to 6 deployments), servers
and roles are separated by platform. The number of servers, and the specialized
platforms installed on them, depends on the size of the deployment and the product
licensing requirements.
For descriptions deployment levels and server roles and their associations, see:
z Appendix A, Working with Deployment Levels, page 113
z Appendix D, Server Roles and Associations and Constraints/Restrictions, page 122.
See also below:
z Platforms and Deployment Levels, page 62
z About Activating or Deactivating Server Roles, page 62
Platforms and Deployment Levels

There are six levels of deployment in the Enterprise Suite, depending on client
requirements.
Level 1 deployment (the smallest) comprises installation of a single server, with the
Consolidated platform selected.
Deployment levels 2 to 6 require additional servers, which store separate databses.
The combination of servers and their platforms depend on the complexity of the
customer’s suite deployment. For more details, see Chapter A, “Working with
Deployment Levels”.
About Activating or Deactivating Server Roles

Each server you add to the installation tree contains a platform that has a pre-defined
set of server roles. Server role availability is based on licensing.
NOTE For more detailed description about server roles and their associations,
see Appendix D, Server Roles and Associations and Constraints/
Restrictions, page 122.
Once you have completed installing the Avaya suite, and have activated the licensed
products, server roles for which the customer is licensed are visible in Enterprise
Manager.
NOTE The ability to view server installations and their server roles is based on
access privileges that have been granted to users.
If a user is only granted privileges to view a specific server role, and then
navigates to the System Management > Enterprise Manager >
Server Roles screen, the name of the server installation to which the
server role belongs is displayed.
However, the user cannot view or edit the server installation’s
configuration.
For details on installation and configuration access privileges, see
Configuration Access Privileges, page 12.
The following section describes how to activate or deactivate server roles.

IMPORTANT The following server roles must be activated (and then configured) in
order for the Enterprise suite to function properly:
z The Framework Applications server role is always activated by
default for all products, and must be configured and associated with
the appropriate server roles (for example, it must be associated with
the Database Analytics Processing Engine, QM Database, and Contact
Database server roles).
See Activating/Deactivating Server Roles, page 64.
Activating/Deactivating Server Roles

1 Complete Enterprise hierarchy and server setup as described in Chapter 3, “Site
Organization and Server Setup”.
2 Navigate to System Management > Enterprise Management > Settings, and
select the server node that contains the platform of server roles you want to
configure.
3 To display the list of available server roles installed on the server, click the Server
Roles tab.
By default, the server roles associated with the product(s) activated by the
customer’s license are listed.
NOTE z In general, activate all Data Zone server roles.
4 To activate or deactivate a server role, select or de-select the check box beside the
server role name.
5 Click the Save button.
NOTE If required, Enterprise Manager generates a message indicating that you
must restart the server.
6 Next Step: Configure each server role selected in the Server Roles screen as
described in Configuring Server Roles, page 65.
Chapter 5 - Server Role Configuration Configuring Server Roles
Configuring Server Roles

1 Once you have activated/deactivated server roles as required, navigate to System
Management > Enterprise Management > Settings, select the server node
that contains the platform of server roles you want to configure, and expand the
server node.
The list of active server roles displays.
2 From the list of server roles, select the server role you want to configure.
The panel on the right refreshes to display the Server Role <Server Role Name>
screen, with the parameters that require configuration.
NOTE If necessary, you can view the Server Role screen in Advanced Mode,
which may display additional parameters for some server role screens.
To view the server role screens in advanced mode, navigate to the
Enterprise node (the top-level node in the installation tree and, at the
bottom of the right panel, click More Actions > Turn Advanced Mode
On.
However, it is not recommended that you change Advanced Mode
settings.
To return the server role screens to the default view, click More Actions
> Turn Advanced Mode Off.
3 Complete the server role configuration as required for each server role:
z Data Center Zone server roles
z Framework Applications Server Role and Associations, page 67
z Framework Reports Server Role and Associations, page 69
z Framework Database Server Role and Associations, page 72
z Framework Data Warehouse Server Role and Associations, page 77
z Framework Integration Service Server Role and Associations, page 79
NOTE Note that if you are configuring Customer Feedback, these three server
roles need to be configured:
z Framework Applications
z Framework Database
z Framework Data Warehouse
4 When you have completed configuring each server role, click Save.
Chapter 5 - Server Role Configuration Configuring Server Roles
5 If required, after you complete configuring each server role, set the role’s
associations as described in Setting Server Role Associations, page 66.
IMPORTANT After you configure each server role or role association, the Enterprise
Manager’s alarming system provides the following information:
z Requirement to restart services
z Server Role: The Enterprise Manager notifies you in advance
which services (if any) for each server role you need to restart once
you save your changes.
z Associated Roles: Once you save your changes, an alarm may
appear in the System Monitor to notify you of which services (if
any) to restart on the associated server roles. An alarm appears for
each service that needs to restart.
z Error messages
If you make an error while configuring server roles and their
associations, Enterprise Manager generates the relevant error
messages.
Upon receiving notification, ensure that you restart services and fix errors
as required. Otherwise, the suite will not function as planned.
For details, see Chapter 6, “Validating Configuration”.
6 Once you have completed the server role and association configuration, validate
your configuration using Enterprise Manager’s validation tools. See Chapter 6,
“Validating Configuration”.
NOTE Roles and associations may have constraints/restrictions on how they are
configured.
Configuration validation indicates if there are any problems in your
configuration related to possible server role/association constraints or
restrictions.
For details on roles and association constraints/restrictions, see Appendix
D, Server Roles and Associations and Constraints/Restrictions, page 122
Setting Server Role Associations

Most server roles are automatically associated with the appropriate roles, or
associations that are set by default, based on product licensing. It is best practice in
general not change these associations.
However, in some cases you must set associations for a server role manually.
The Enterprise Manager generates an alarm if mandatory associations are not set or are
deactivated.
Chapter 5 - Server Role Configuration Configuration Details: Data Center Zone Server Roles
To set associations for a server

1 Select the server role you configured and click the Associations tab.
The Associations <Server Role Name> screen opens on the right panel, showing
the roles that can be associated with your selected server role.
By default, many of the server roles’ associated roles are already selected. And
when the check box is inactive (greyed out), the association is a mandatory one.
It is not recommended that you de-select a mandatory association, since that may
result in the Enterprise suite not working properly.
2 You can do one of the following:
z If you need to select a role to be associated with the server role, select the check
box beside the associated role’s name.
z If you need to remove an association from the server role, clear the check box
beside the associated role’s name.
For details on how to set associations for individual server roles, select the server
role whose association you want to configure from the list of server roles in the
procedure Configuring Server Roles, Step 3, on page 65.
Configuration Details: Data Center Zone

Server Roles
The following server roles and their associations belong to platforms installed on servers
in the Data Center zone. These server roles are required for database functionality and
for application functionality (Workforce Management, Scorecards, eLearning, and so
on).
z Framework Applications Server Role and Associations, page 67
z Framework Reports Server Role and Associations, page 69
z Framework Database Server Role and Associations, page 72
z Framework Data Warehouse Server Role and Associations, page 77
z Framework Integration Service Server Role and Associations, page 79
Framework Applications Server Role and Associations

This server role is required for all Enterprise Suite deployments, as it activates the
suite portal and such suite modules as Enterprise Management, Organization
Management and User Management.
The Enterprise Management module contains the Enterprise Manager tool required to
implement Enterprise settings, setup and configure the Enterprise hierarchy, sites and
servers.
This server is also associated with the Framework Reports server role, the Framework
Database server role and, if the Scorecards license has been purchased, the
Framework Data Warehouse server role.
This server role also configures the Pop-up Server used with Framework applications in
the suite portal.
This server role is available in the following platforms:
z Consolidated
z Data Center
z Database
z Application
Once the configuration is complete, you need to restart the Weblogic service. To do so,
use the Watchdog services window to restart the
WFO_ProductionDomain_ProductionServer service.
See:
z Framework Applications Server Role, page 69
z Framework Applications Server Role Associations, page 69
Framework Applications Server Role

Server Access
Parameter Description
Administrator Account Name Weblogic server administrator account name. Please provide
an account, which is configured to manage Weblogic server.
For example WLSAdmin
Administrator Account Weblogic server administrator account password.

Password
Pop-up Server
Pop-Up Domain Pop-up server DNS domain.
Default: Field empty
Framework Applications Server Role Associations
Associated Mandatory, Association Association Why is this

Roles Optional, Scope Type Association
If Exists & Limits required or used?
Framework Mandatory Enterprise One-to-One Dependency

DB enforcement.
Framework If Exists Enterprise One-to-One Required to associate

Reports with the Cognos
Reports Server.
Framework If Exists Enterprise One-to-One If a Scorecards license

WHDB exists, required to
connect to the
Warehouse Database.
Framework Reports Server Role and Associations

With the Framework Reports server role, the system connections to the Cognos Report
Server ports used with Framework applications such as Workforce Management,
Scorecards and eLearning.
This role may be included in the following platforms:
z Consolidated
z Data Center
z Database
z Framework Database & Reporting
z Reporting
See:
z Framework Reports Server Role, page 71
z Framework Report Server Role Associations, page 72
Framework Reports Server Role

Report Server Content Store Details
SQL Server Name The TCP/IP host name or IP address of the SQL Server
hosting the SQL Server database. No SQL Instance name.
Port Default: enter 1433

The TCP/IP static port from where the SQL Server hosting the
database is listening.
Report Server Details
Gateway Port This value installs IBM Cognos 8 server.

Default: enter 8383
Gateway SSL Port Port value is used to configure IBM Cognos 8 server in secure
mode.
Default: enter 8387
Dispatcher Port Represents non-SSL Port.

Default: enter 9300.
Dispatcher SSL Port Port value is used to configure IBM Cognos 8 server in secure
mode.
Reporter Server Access
Administrator Domain user name.

Namespace
Administrator Account Used by the Framework Reports plug-in to deploy Framework

Name application reports. Report trimmer. Report dump
components also use this account to run.
Default: radmin
Administrator Account Used by Framework Reports plug-in to deploy Framework

Password application reports. Report trimmer. Report dump
components also use it to run.
Default: DeamLiner787
Framework Report Server Role Associations
Associated Mandatory Association Association Why is this

Roles (M) or Scope Type Association Required
Optional & Limits or used?
(O)
Framework M Enterprise One-to-one Uses SQL server host and

Database port of WFO production
database to configure:
z WFO CAP property file for
WFO_Production
namespace
WFO_Whatif namespace
z Data source bpmaindb on
report server
z Data source bpwhatifdb
on report server
Framework M Enterprise One-to-one Uses Framework

Applications Applications server http-
alias and port to configure:
WFO_Production
namespace
WFO_Whatif namespace
Framework O Server One-to-one Uses SQL server host and

Data port of WFO warehouse
Warehouse database to configure:
z Data source
bpwarehousedb on report
server
Framework Database Server Role and Associations

The Framework Database server role supports the core Framework database that is
required for use with Enterprise Suite modules in the suite portal, such as Enterprise
Management, Organization Management, User Management, as well as the Framework
applications.
This server role can be installed with the following platforms:
z Consolidated
z Data Center
z Database
z Framework Database
See:
z Framework Database Server Role, page 74

z Framework Database Server Role Associations, page 77
Framework Database Server Role

NOTE If the database server role is used with remote SQL Servers (SQL Farms/
Clusters), do not configure the TempDB data storage parameter.
The customer owns the SQL server and its configuration, including
TempDB data storage parameter values.
SQL Server Details
SQL Server Name Type the SQL server host address used as the default for all
databases.
For SQL cluster or SQL farm the server name must be the
cluster name.
The SQL instance name is not required.
Port The TCP/IP static port from where the SQL Server hosting the
Default: 1433.
Database Sizing
NOTE These values are customized for each customer and included in the
Installation and Configuration Report prepared for the customer site.
Database Storage No default.

Allocation (GB) The total size in GB that is pre-allocated for the database's
data and index files
Transaction Log Storage The number refers to the GB that will be pre-allocated for the
(GB) database's transaction log.
Default: 4
TempDB Data Storage The number refers to the GB that will be pre-allocated for
(GB) SQL Server's TEMPDB data files, up to a maximum value of
64 GB.
Default: 3
TempDB Log Storage The number refers to the GB that will be pre-allocated to SQL
Server's TEMPDB log file. Valid values are from 1GB to 10GB.
Default: 2
Purging Data
NOTE These values are customized for each customer, and provided in an
external document.
Purging Enabled Check box, Is the purging job enabled for this
database?
Default: Check box not selected.
Enable Delete by Rows If checked, each execution of the purging job will delete a
maximum of the number of rows indicated in each specific
area below.
If unchecked, all rows beyond the retention period will be
deleted per job execution.
Default: Enabled
Report Area Specify retention period in months and rows to be deleted for
tables to be purged in the Reporting area.
Defaults: 12 months and 1000 rows respectively.
Timerecord Area Specify retention period in months and rows to be deleted for
tables to be purged in the Time Record area.
Schedule Area Specify retention period in months and rows to be deleted for
tables to be purged in the Schedule area.
Queue Area Specify retention period in months and rows to be deleted for
tables to be purged in the Queue area.
Defaults: 24 months and 1000 rows respectively
Audit Compliance Area Specify retention period in months and rows to be deleted for
tables to be purged in the Audit Compliance area.
Audit Non-Compliance Specify retention period in months and rows to be deleted for
Area tables to be purged in the Audit Non-Compliance area.
VCT Events (Managed) Specify retention period in months and rows to be deleted for
Area tables to be purged in Managed VCT Events area.
VCT Events (Unmanaged) Specify retention period in months and rows to be deleted for
Area tables to be purged in the Audit Compliance area.
Defaults: 0 months (all records deleted) and 1000 rows
respectively
Framework Database Server Role Associations

Roles (M) or Scope Type Association
Optional & Limits Required or
(O) used?
FrameworkWHDB Optional Enterprise One-to-One Data

acquisition,
required for
solutions that
include the
Scorecards
application.
The Framework Data Warehouse is optional for the Framework Database role. If it does
not exist, no error message will be generated.
Framework Data Warehouse Server Role and Associations

The Framework Data Warehouse server role is required for Enterprise solutions that
include the Scorecards application.
This server role can be installed on servers with the following platforms:
z Consolidated
z Data Center
z Database
z Data Warehouse
See:
z Framework Data Warehouse Server Role, page 78
z Framework Data Warehouse Server Role Associations, page 79
Framework Data Warehouse Server Role

NOTE If the database server role is used with remote SQL Servers (SQL Farms/
Clusters), do not configure the TempDB data storage parameter.
The customer owns the SQL server and its configuration, including
TempDB data storage parameter values.
SQL Server Details
SQL Server Name The TCP/IP host name or IP address of the SQL Server
hosting the SQL Server database.
Default: No SQL Instance name.
Port The TCP/IP static port from where the SQL Server hosting the
Default: 1433.
Database Sizing
NOTE These values are customized for each customer and included in the
Installation and Configuration Report prepared for the customer site.
Database Storage The total size in GB that is pre-allocated for the database's
Allocation (GB) data and index files
Transaction Log Storage The number refers to the GB that will be pre-allocated for the
(GB) database's transaction log.
Default: 5
TempDB Data Storage The number refers to the GB that will be pre-allocated for
(GB) SQL Server's TEMPDB data files, up to a maximum value of
64 GB.
Default: 2
TempDB Log Storage The number refers to the GB that will be pre-allocated to SQL
Server's TEMPDB log file. Valid values are from 1GB to
10GB.\
Default: 2
Purging Data
NOTE These values are customized for each customer, and provided in an
external document.
Purging Enabled Check box, Is the purging job enabled for this
database?
Default: Not enabled.
Scorecards Fact Tables In the Retention (Month) box, type the retention period (in
months), and in the Rows to delete box, the number of
rows that are to be deleted (in batches) per job.
Defaults:
Retention (Months) = 24
Rows to delete = 100000
Framework Data Warehouse Server Role Associations

Roles (M) or Scope Type Association
Optional & Limits Required or used?
(O)
FrameworkDB Mandatory Enterprise One-to-One The FrameworkWHDB

database requires the
FrameworkDB
database association in
order to function.
The Framework Data Warehouse role cannot be installed without the existence of the
Framework Database role.
Framework Integration Service Server Role and Associations

The Framework Integration Service server role is required for Enterprise Suite solutions
that include Framework applications such as Workforce Management, Forecasting and
Scheduling, Scorecards and eLearning.
Once installed and activated, the Framework Integration Service is used to configure
and run a variety of adapters, whose features are described in individual adapter guides.
This service role can be installed on servers with the following platforms:
z Consolidated
z Framework Integration Service
Chapter 5 - Server Role Configuration
Upon completion of the Enterprise Suite configuration, start the Integration Service.
See:
z Framework Integration Service Server Role, page 80
z Framework Integration Service Server Role Associations, page 80
Framework Integration Service Server Role

There are no parameters associated with this server role.
Framework Integration Service Server Role Associations
Associ- Manda- Association Associa- Why is this Associa-

ated Roles tory (M) or Scope tion Type tion Required or
Optional & Limits used?
(O)
Framework Mandatory Enterprise One-to-One Automatic association.

Applications
Chapter 6
Validating Configuration
The following sections describe how to access the Enterprise Manager’s configuration
status and alarm tools.
z Overview, page 82
z Reviewing Notifications on the Configuration Status tab, page 82
z Reviewing Alarms on the Alarm Status Tab, page 84
z Troubleshooting, page 85
Chapter 6 - Validating Configuration Overview
Overview
Enterprise Manager includes system monitoring features to notify you when services
need to be restarted, or to indicate when there are errors in your configuration.
When changing any of a server role’s parameters, you may receive the following types
of notification:
z Requirement to restart services
z Error messages
There are two primary areas in Enterprise Manager that indicate errors/messages: the
Installations > Configuration Status and the System Monitor > Alarm Status
tabs.
At each level of the installation tree, you can access Configuration Status and Alarm
Status to view the list of configuration errors that exist on each server on the
installation tree.
See:
z Reviewing Notifications on the Configuration Status tab, page 82
z Reviewing Alarms on the Alarm Status Tab, page 84
For detailed information about each possible alarm in the system related to
configuration, as well as other tasks, see the Enterprise System Alarm and Messaging
Guide.
The sections that follow only describe configuration and alarm status relevant for
Enterprise configuration. For more details on Enterprise Manager and its alarming
system, see the Avaya Enterprise Manager Basics Guide.
Reviewing Notifications on the Configuration

Status tab
Various warning icons, such as the yellow warning icon , appear beside group site,
site, and server role nodes in the installation tree, to indicate that there is a problem
with the server configuration.
Errors that occur at one level (for example at the server level) are rolled up to the next
level.
For example, if a site node contains two server nodes, each with errors, the
Configuration Status tab lists the errors separately for each server node, but then
combines them when you view the Configuration Status tab from the site node level
that includes the two server nodes.
You can check the Configuration Status tab to review each problem, and resolve it.
You can also view the current status of configuration messages sent to servers on the
installation tree.
Chapter 6 - Validating Configuration Reviewing Notifications on the Configuration Status tab
Also, you can review the list of issues related to your Enterprise suite configuration on
the Configuration Status tab by clicking the configuration validation check mark .
Each issue is shown with instructions for resolving the problem.
See Reviewing the Configuration Status, page 83
Reviewing the Configuration Status

1 Navigate to System Management > Enterprise Management > Settings, and
select the level of the installation tree for which you wish to see the configuration
status screen (Enterprise, Site Group, Site, Server or Server Role node).
2 Click the Configuration Status tab. screen.
The Configuration Status screen opens, with a list of error types, error levels (for
example, Warning), error dates, and error descriptions (for example, role
constraint violation). Note that error descriptions often contain information that is
useful for resolving the error.
3 To filter the warnings on the screen, click the arrow beside the View drop-down list
box, and select an error level filter option, such as All, Fatal, Error, Warning.
4 To view the status of the configuration messages the Enterprise Manager is
processing, click the View Message Status button at the bottom right of the
screen.
The screen refreshes, and shows a list of configuration messages, their status (All,
Scheduled Import, Pending, Completed, Failed), the result (for example,
Success), the configuration operation transmitted by the message (for example,
Update Cache) and the date.
NOTE Since server roles do not transmit configuration messages, the View
Message Status option is not available from a server role Configuration
Status screen.
5 Click the View Configuration Status button to return to the original

Configuration Status screen.
Chapter 6 - Validating Configuration Reviewing Alarms on the Alarm Status Tab
Reviewing Alarms on the Alarm Status Tab

When alarms related to server roles are triggered, a red circle with an ‘x’ appears on the
node(s) to indicate the active alarm notification.
These alarms are recorded in the System Monitor area of the Enterprise Management
module.
To view active alarms

1 Navigate to System Management > System Monitor > Alarm Status.
The Alarm Summary screen displays.

2 Select the alarm on the screen whose details you want to view and, at the bottom
right of the screen, click the View button.
The Active Alarms screen opens. The left panel indicates the servers and their
roles, for which the alarms have been triggered, while the right panel lists the
following items:
z Alarm Name - the name of each alarm found on the server/server roles (e.g.
Archive Configuration Error, Call Buffer Path Undefined)
Chapter 6 - Validating Configuration Troubleshooting
z Last Triggered - time when the alarm was most recently triggered
z Details - the reason why the alarm was triggered
z Priority - urgency of the alarm (for example, Major or Minor)
z Count - number of times the same alarm has been triggered.
3 To see more details about each alarm, select the alarm and then click the View
button.
4 Once you have addressed the problem described by the alarm, select the alarm and
click the Acknowledge button.
The alarm is removed from the list.
Troubleshooting
Server roles have internal server role names that are different from the server role
names displayed in Enterprise Manager.
If you are troubleshooting configuration errors, you may need to view the server role’s
XML file in the local server cache, however, to find that XML file you need the server
role’s internal server role name.
For additional troubleshooting, you can also review the component internal configuration
repository.
See:
z Retrieving a Server Role’s XML File, page 85
z Reviewing the Component Internal Configuration Repository, page 85
Retrieving a Server Role’s XML File

1 Following each server role’s configuration, use the validation process described
under Reviewing Notifications on the Configuration Status tab, page 82 and
Reviewing Alarms on the Alarm Status Tab, page 84 to see if there are any warnings
or errors.
2 If you find warnings or errors for a server role and need to investigate further,
navigate to the local server’s cache and retrieve the server role’s XML file, using the
following variables to construct the path to show the location of internal server role:
%Impact360SoftareDir%\conf\Roles\<Internal server role name>\..
Reviewing the Component Internal Configuration Repository

Navigate to the component internal configuration repository to see if the plug-in has
applied the configuration correctly.
Components may be stored in registry files, which get set by the plug-in from the XML.
TBD: This needs to be defined component by component.
Chapter 7
Configuring Single Sign-On

(SSO)
The following sections describe how to configure single-sign on for a suite solution using
the single sign-on wizard.
z Overview, page 87
z Before You Begin, page 87
z Configuring SSO with the SSO Wizard, page 88
z Testing the SSO Configuration, page 103
z Troubleshooting SSO Configuration Issues, page 104
Chapter 7 - Configuring Single Sign-On (SSO) Overview
Overview
The following sections are intended to guide you through the process of enabling single
sign-on (SSO) for the suite using the SSO wizard.
The configuration procedures described below enable single sign-on to the system with
Windows authentication.
Single sign-on allows users to switch seamlessly between suite applications, such as
Workforce Management and Scorecards and, for example, Quality Monitoring.
The authentication happens in the background, and is invisible to the end-user.
NOTE SSO configuration is not mandatory.
However, if you are configuring SSO for the suite, it can be configured any
time after the server role configuration described in Appendix 5 “Server
Role Configuration”.
Before You Begin

Do the following before configuring SSO:
z Configure Active Directory for the system, which includes setting up the following:
z SSO_test_user, SSO_Test_Group, Firstuser and WLSAdmin users
z The SSO service binding account, host and domain names
z Run setspn and ktpass commands.
NOTE z For details on preparing user accounts in the Active Directory, as well
as setspn and ktpass commands, see the Technologies, Security and
Network Integration Deployment Reference Guide.
z For details on configuring the Windows Active Directory with
Lightweight Directory Access Protocol (LDAP), see Appendix E
“Configuring Active Directory with Lightweight Directory Access
Protocol (LDAP)”
z Configure Internet Explorer on each workstation for SSO with Active Directory.
Because there are potentially large numbers of Internet Explorers to be configured,
the customer's IT department should push the configuration from Active Directory
Chapter 7 - Configuring Single Sign-On (SSO) Configuring SSO with the SSO Wizard
to all users. For details, see the Deskop Applications Deployment Reference and
Installation Guide.
z Before beginning the configuration, back up this folder:
z %Impact360SoftwareDir%ProductionServer\weblogic10sp3\Impact360
\ProductionDomain
NOTE If there is an error with the configuration that follows, you cannot re-
configure using the SSO configuration wizard unless the original state of
the DB authentication is restored.
For this reason, it s best to back up the folder noted above, and then
restore it in the event it is required.
Configuring SSO with the SSO Wizard

SSO configuration tasks are performed using the WebLogic server machine.
Before you proceed, you need to verify that the prerequisite steps to set up the SSO
service binding account have been completed properly, Weblogic host and fully qualified
domain names are set up, and that the suite is configured with the default DB
authentication option.
Then you begin using the SSO configuration wizard.
See:
z Verifying SSO Service Binding Account, Host and Domain Names, and the Default
DB Authentication, page 88
z Configuring SSO with the SSO Configuration Wizard, page 93
Verifying SSO Service Binding Account, Host and Domain

Names, and the Default DB Authentication
Verify the following before proceeding to use the SSO configuration wizard:
z Verifying the SSO Service Binding Account, page 88
z Verifying Host and Domain Names, page 89
z Verifying the Suite’s Default DB Authentication, page 89
Verifying the SSO Service Binding Account

Run this command:
setspn -L <service_binding_account_such_as_SSOBind>
For example:
setspn -L SSOBind
The result should show exactly two items:
z HTTP/<weblogic_or_load_balancer_host_name>
z HTTP/< weblogic_or_load_balancer_full_qualified_domain_name>
where both <weblogic_or_load_balancer_host_name> and
< weblogic_or_load_balancer_full_qualified_domain_name> should be in
lower case.
NOTE
The Weblogic server is hosted on the Application server. If you have a 1st
or 2nd level deployment, then it is hosted on the Consolidated/Data
Center server. For details on deployment levels, see Appendix A “Working
with Deployment Levels”.
For example:
HTTP/lmapp
HTTP/lmapp.wlm.com
NOTE z If the above verifications fail, ensure that all users were configured
properly in the Active Directory User Forest/Domain, as described in
the Technologies, Security and Network Integration Deployment
Reference Guide.
z Then verify that the setspn and ktpass commands were completed
successfully.
Verifying Host and Domain Names

Use nslookup or ping to verify the Weblogic host and fully qualified domain names.
For example:
nslookup lmapp
ping lmapp
nslookup lmapp.wlm.com
ping lmapp.wlm.com
If the ping and/or nslookup attempts fail, work with the customer’s IT group to resolve
the problem.
NOTE
If there are multiple Application servers (in an application cluster), the
host and FQDN of the load balancer should also be verified.
Verifying the Suite’s Default DB Authentication

Our system provides an internal authentication method, which is referred to as the DB
Realm. The DB Realm authenticates the user with a username and password that is
maintained within the system (in the database).
The SSO configuration wizard only works with the default DB Authentication (the
configuration package is installed with that authentication method by default).
If the verification does not match the following description, configuration should be
stopped, and the DB authentication should be configured.
To verify the default DB authentication:

1 Log on as WLSAdmin to the WebLogic server web console using the link below. Use
the default administrator’s password established during installation.
http://<application_server_hostname>:7001/console
2 Verify that wfosDBAuthenticator is the default authenticator as follows:
a. On the left panel, select Security Realms and, on the right panel under Name,
click BPDBRealm.
b. On the right panel, on the Settings for BPDBRealm screen, click Providers >
Authentication. The default authenticator, wfosDBAuthenticator, is shown in
the Authentication Providers area in the Name box, where

wfosDBAuthenticator is the only authenticator.
If the wfosDBAuthenticator is configured by default, you can continue to the

next verification. If not configured, DB authentication should be restored.
3 Enter the URL of the system, which was established during the suite installation
process. The login screen should open.
4 Log on to the suite web application using the administrator user name, such as
wsuperuser, with the administrator password established during installation. The
web application should open, showing installed/configured modules.
IMPORTANT If the Workorce Optimization suite’s default authentication has been

modified, note the following:
If before the authentication was modified, you backed up the
%Impact360SoftwareDir%ProductionServer\weblogic10sp3\Imp
act360\ProductionDomain folder, as described under the section
Before You Begin, page 87, the authentication can be restored by
replacing the files and restarting the WFO_ProductionDomain_
ProductionServer service.
Configuring SSO with the SSO Configuration Wizard

The SSO Wizard configures Weblogic with Windows Authentication and Single Sign-On.
Therefore it should run on the Application server, which hosts Weblogic.
NOTE
If the deployment has more than one Application server (that is, an
Application cluster), you should run the SSO Wizard on each of the
Application servers separately.
1 On the Application server (or the Consolidated or Data Center server in smaller
deployments), double-click the System Tools shortcut on your desktop to add the
System Tools icon to the system tray. Once it is in the system tray, right-click the
icon to open the System Tools menu.
2 On the menu, click Run, then click SSO Wizard.
3 In the first screen, the SSO Configuration Wizard detects the current domain.
If the information displayed in the Domain Name text box is not correct, replace
the value with the correct value. The domain name you enter in this step is inherited
by all subsequent screens in this procedure.
When you are finished with this screen, click Next>>.
NOTE To support an environment where the system is joined to a forest different
from the Application User forest, you must set up a virtual DNS for the
WebLogic server in the Active directory of the Application User Forest/
Domain.
For details on how to do this, see the Technologies, Security and Network
Integration Deployment Reference Guide.
In this case, the Domain Name in the SSO Wizard should be configured as
the domain in the Application User Forest (which has the virtual DNS), and
not as the domain which hosts the system’s servers.
For example, if users are located in a domain called usersdomain.com
while servers are in a domain called wlm.com, type usersdomain.com in
the Domain Name text box.
4 To provide the information necessary for connecting to the WebLogic server, enter
appropriate information on the SSO Configuration wizard’s next screen:
z WebLogic Host Name: The wizard detects the host name automatically. If the
default information is not correct, you need to correct the information, then enter
the remaining information on the screen as required.
z Weblogic Port: The port remains the default 7001 port (unless the Weblogic
port was changed).
z Domain Name: The domain name is inherited from the first screen in this
wizard.
NOTE Note that in cases where special adjustments (as described in the note in
the previous step) are performed to support an Application user forest
which is different from the suite’s system forest, the Weblogic Host
Name does not change, but the Domain Name field shows the domain in
the Application user forest, not the suite’s domain name.
z Admin User: The Admin User is the user that is currently used to connect to
Weblogic. The default is WLSAdmin.
z Admin Password: The password shown here is the one currently configured in
Weblogic.
NOTE If the account and password have been changed, you need to adjust the
values of Admin User and Admin Password
z Load Balancer: If the suite is configured using an Application cluster, provide

the host name for the load balancer in the Load Balancer field. Otherwise, leave
this field blank.
z Support check box [value: userPrincipalName]: If you select this check box,
you have the flexibility in the suite to use either the sAMAaccountName or
userPrincipalName from the Active Directory.
sAMAccountName would be similar to Firstuser, while userPrincipalName
would be Firstuser@<domain>.com (for example, Firstuser@wlm.com).
NOTE If you choose userPrincipalName, you need to migrate all user names in
the BPUSER table of BPMAINDB accordingly, that is, using a
@<domain> pattern.
z Replace wsuperuser: Use this field to replace the wsuperuser account with
another account in Active Directory.
NOTE You can leave this field blank. If you do, wsuperuser continues to exist
with all its privileges.
However, if wsuperuser is not replaced with a user from Active Directory,
make sure that wsuperuser is also created in the Active directory (that
is, the Active Directory of the Application Users Forest/Domain should
include a user called wsuperuser).
If you provide a value, the SSO Wizard replaces wsuperuser in the BPUSER
table of BPMAINDB with that value. The wsuperuser account is removed; the
replacement account has all previous wsuperuser's privileges.
IMPORTANT The Replace wsuperuser field and the Support check box [value:
userPrincipalName] should be consistent and configured together.
When replacing the wsuperuser value, note the following:
z If the checkbox is checked,enter the userPrincipalName (e.g.
Firstuser@<domain>.com).
z If the check box is unchecked, enter the sAMAccountName (e.g.
Firstuser).
z If the check box is checked and the Replace wsuperuser field is left
blank, wsuperuser is replaced with wsuperuser@<domain>.com
(even if that is not your intent, for consistency reasons).
5 Click Next>>.
The SSO Configuration Wizard then verifies the information provided. If the
information is valid, the wizard moves to the next screen. Otherwise, it stays at the
current screen until you correct the information.
The error details are provided in the bottom area of the SSO wizard and also in the
open Command Line window in the background.
6 To verify the LDAP configuration, complete information in the SSO Configuration

wizard’s next screen as required.
z AD/LDAP Host Name: This is the host name for the domain controller/Active
Directory server, which runs the LDAP service.
When the Application user domain is different from the suite domain, you should
provide the domain controller for the Application user domain.
z Admin User and Admin Password: These fields contain the account
information that the WebLogic server uses to connect to the Active Directory
LDAP service.
This account is also used to log on to the WebLogic console once SSO
configuration is done.
NOTE The defaults for this account in the SSO Wizard are WLSAdmin and the
default password is the password currently used to access WebLogic.
WLSAdmin user must be configured in the Active Directory so that the
SSO Wizard can use it.
If the WLSAdmin user was created in the Active Directory with a password
different from the default password (that is, the password currently used
to access WebLogic), change the password in the Admin Password field
on this screen.
z User Base DN and Group Base DN: By default, the SSO Configuration Wizard
automatically populates these fields.
You can adjust values if they are incorrect or in order to improve performance.
z Test User Account and Test Group Name: Type the test user account name
and the test group name that were configured in Active Directory. These are to
verify AD/LDAP configuration.
7 Once you’ve verified/added the information required, click Next.
The SSO Configuration Wizard then verifies the information provided. If the
information is valid, the wizard moves to the next screen. Otherwise, it stays at the
current screen until you correct the information.
The error details are provided in the bottom area of the SSO wizard and also in the
open Command Line window in the background.
8 To complete information about the Kerberos Distribution Center (KDC), use the SSO
Configuration wizard’s next screen:
z KDC Host Name: Generally, this is the host name for the domain controller for
the LDAP service. It is inherited from the previous screen. We do not advise
adjusting this value.
z Test Account: This field is inherited from the previous screen.
z Test Password: Provide the Test Account password.
z HTTP/<host> Account: This field is automatically populated with the HTTP
service that is bound to the SSOBind user. It should have the same host name as
that used to browse to the Workforce Optimization web application.
z HTTP/<host> Password: Provide the password for the SSOBind user that is
bound to the HTTP service.
NOTE The HTTP/<host> Account and the HTTP/<host> Password values
correspond to the parameters which were given for the setspn and ktpass.
For details, see Verifying the SSO Service Binding Account, page 88.
9 Once you have verified/added the required information, click Finish.
10 The information you provided is then verified. If accurate, you are prompted for
confirmation about continuing the SSO configuration with the information collected.
Click Yes to proceed with the SSO configuration.

If the configuration is successful, the wizard displays the following:
11 Click Yes to exit the SSO Configuration Wizard.

12 Do the following:
z Navigate to Windows Server Manager > Services and stop the Weblogic
service (WFO_ProductionDomain_ProductionServer).
z Stop the Watchdog service, to ensure that the

WFO_ProductionDomain_ProductionServer service does not start
automatically.
13 Restart the Weblogic services. For details, see Restarting Weblogic Services,
page 101.
NOTE If your system has an application cluster configured, repeat steps 1 to 13
in this procedure, and the procedure Restarting Weblogic Services,
page 101 for every Application Server in the suite.
14 If a change is made to the default Admin User (WLSAdmin) and Admin password
that connects to Weblogic, configure the correct user name and password in
Enterprise Manager in the suite’s web application. For details, see Configuring the
Administrator Account Username and Password in Enterprise Manager, page 101.
Restarting Weblogic Services

NOTE WLSAdmin or its replacement is used to start the WebLogic server.
If the password for the WLSAdmin has changed (from the default
password) or the account has been deleted, the WebLogic server cannot
start.
The correct password is the one that was set in the Domain's Active
Directory for the WLSAdmin user, since that user is used from now on to
access Weblogic.
If there are changes made to the default user/password, make sure to
adjust the password in the boot.properties file, which is located in the
security folder in this directory path:
act360\ProductionDomain\servers\ProductionServer\security
Once you change the password, begin the following procedure.
1 Open Command Line (if this is on a WIN2008 operating system, open the command
line as an administrator). Navigate to the ProductionDomain folder, which is
located in this directory:
%Impact360Softwaredir%ProductionServer\weblogic10sp3\Impact360\
ProductionDomain
2 In the ProductionDomain folder, run uninstallService.cmd.
3 In the ProductionDomain folder, run installService.cmd, which automatically
restarts the Weblogic Windows service.
4 Start the Watchdog service and verify that the WFO_ProductionDomain_
ProductionServer service is running.
Configuring the Administrator Account Username and

Password in Enterprise Manager
The Framework Applications configuration requires that you use the correct
administrator username and password. This user and password information should
match the username and password that were defined in the Active Directory and
configured in the SSO Wizard.
If a change is made to the default Admin User (WLSAdmin) and Admin password that
connects to Weblogic, complete this procedure.
To configure the account username and password

1 Wait until the Weblogic service is up and then log on to the suite web application.
2 On the login screen, deselect Trusted Login check box and type the username and
password of the ‘super’ administration user, such as Firstuser.
The user name entered depends on whether you checked the Support check box to
use userPrincipalName or not during the SSO configuration described (for
example, type Firstuser if the check box remained unchecked, but

Firstuser@domain.com if it was selected).
3 In the suite web application, navigate to System Management > Enterprise
Management and, under the Application Server node, select the Framework
Applications server role.
4 On the server role’s Settings tab, in the Server Access area, type the correct
username and password in the Administrator Account Name and Administrator
Account Password text boxes.
5 Click Save.
Chapter 7 - Configuring Single Sign-On (SSO) Testing the SSO Configuration
Testing the SSO Configuration

These are the pre-requisites for a successful test:
z At minimum, a user name, such as Firstuser, with administrative privileges, exists.
NOTE For general users of the system, note that when configuring the suite with
Windows Authentication for use with SSO, application users cannot be
created within the suite web application itself, but must exist in the
Application user forest/Domain Active Directory.
They must be imported from there using the Import Domain Users on
the suite’s web application’s User Management > Profiles screen.
For details on this feature, see the Avaya Aura WFO User Management
Guide.
z The desktop used is in the Application forest (or in the suite system forest, if only
one forest is used in the deployment).
Internet Explorer has been configured on the desktop for SSO. This process is described
in the Desktop Applications Deployment Reference and Installation Guide.
To test the SSO configuration

1 In the Internet Explorer (IE) address bar, type the suite’s URL.
NOTE Note the following:
z Use a designated desktop, not the Application server.
z The DNS/FQDN defined in the SETSPN command is used for the
verification.
z Make sure you logged into the desktop you are using with a Windows
login for a user that has access to the Workforce Optimization suite.
The login screen appears. The Trusted Login check box should be already
selected.
2 Click the Login button.
The suite’s home page should display, without the user having to supply credentials.
NOTE Site Acceptance Test documents also contain detailed SSO configuration
tests.
Chapter 7 - Configuring Single Sign-On (SSO) Troubleshooting SSO Configuration Issues
Troubleshooting SSO Configuration Issues

These are some possible troubleshooting issues that you may need to resolve during the
overall SSO setup and configuration process:
z A workstation stops working with SSO, page 105
z SSO fails because setspn is not running correctly, page 105
z I have found a problem in the SSO configuration and fixed but it still doesn't work.
What is being cached? How do I clear the cache?, page 106
z What should I do if I encounter the message KDC has no support for encryption
type (14)?, page 106
z SSO works from one desktop but doesn't work from another one, page 107
z Can I use the IP address instead of the host name for the fully qualified domain
name in the URL when accessing the suite with SSO?, page 107
z What is the problem when the WebLogic server fails to start and the suite’s home
page or the Weblogic console cannot be accessed?, page 107
z Can SSO fail due to case sensitivity?, page 108
z Can a customer IT department lock prerequisite accounts, such as Firstuser,
WLSAdmin, the SSO service binding account, or test user accounts to log on only to
specific servers or workstations?, page 108
z What should I do when ktpass fails due to an extra setspn?, page 108
z Do I have to force DES encryption for the SSOBind account?, page 108
z Does the SSO Configuration Wizard need WLSAdmin to be member of
WLSAdminGroup or any other privilege group?, page 109
z What do I do when the System Monitor tool in Enterprise Manager triggers an alarm
that indicates that the Framework Applications Administrator Account Name and/or
password are incorrect?, page 109
z Can the Domain Controller have multiple NICs?, page 109
z SSO doesn't work but when I De-Select the Trusted Login check box and enter
credentials, my user is authenticated., page 110
z What if somebody changes the service binding account password?, page 111
z Can I run the uninstallService.cmd and installService.cmd in Windows Explorer by
double-clicking them?, page 111
z Can I run the uninstallService.cmd and installService.cmd in Windows Explorer by
double-clicking them?, page 111
A workstation stops working with SSO

Check the following scenarios to resolve this problem:
z Check the browser configuration. It is possible that settings were overridden by a
Group Policy. For details, see the Deskop Applications Deployment Reference and
Installation Guide.
z There is a problem with the system clock synchronization between the desktop,
domain controller and/or Application server.
z Ensure that the host name or fully qualified domain name are being used to access
the suite.
z Ensure that the administrative user (for example, Firstuser), WLSAdmin, and
SSOBind accounts are not locked so that they only log onto specific computers or
servers
z Ensure that KDC service (Kerberos Key Distribution Center) is running on the
Domain Controller and SPN is set correctly
SSO fails because setspn is not running correctly

If you know the HTTP/… service binding account, for example, SSOBind, you can verify
the setspn command as follows:
setspn -L <service_binding_account_such_as_SSOBind>
For example:
setspn -L SSOBind
The result should show exactly two items:
z HTTP/<weblogic_or_load_balancer_host_name>
z HTTP/< weblogic_or_load_balancer_full_qualified_domain_name>
Both <weblogic_or_load_balancer_host_name> and
< weblogic_or_load_balancer_full_qualified_domain_name> should be in lower
case.
The Weblogic server is hosted on the Application server (if you have a 1st or 2nd scale
environment than it is hosted on the Consolidated / Data Center server).
For example:
z HTTP/lmapp
z HTTP/lmapp.wlm.com
You should also be able to verify that the names are correct with ping and nslookup.
If this verification fails, verify that the SSOBind user was created properly in the Domain
Controller's Active Directory. For details, see the Technologies, Security and Network
If the user was created properly, then the problem is probably with the SETSPN
command and you should follow the instructions in order to set it correctly.
I have found a problem in the SSO configuration and fixed but

it still doesn't work. What is being cached? How do I clear the
cache?
For performance reasons, the Kerberos ticket is cached.
To clear the cache, for example when the setspn command is done incorrectly and the
browser failed to single sign-on with Active Directory, once you have fixed setspn, you
should log out of the Windows account and log in again to clear the cache.
The same cache clearance is required in case there was a failure to authenticate due to
disconnecting from the Domain Controller's Active Directory or specifically to the KDC
service on the Domain Controller (Kerberos Key Distribution Center).
What should I do if I encounter the message KDC has no

support for encryption type (14)?
In this scenario, these are possible fixes:
z If your environment requires the DES encryption type, in Active Directory, select the
user for the SSO service binding user, right-click, go to the Properties window's
account tab, and make sure the Use DES encryption types option for this account
is selected.
z Make sure that the SSOBind user password has not been changed.
z On the Application server, make sure the file krb5.ini file under c:\winnt has not
been modified. The SSO Configuration Wizard generates this file.
z If your desktop is WIN7 / 2008, verify that the correct security policy has been
applied for Internet Explorer. For details, see the the Deskop Applications
Deployment Reference and Installation Guide.
z If your domain controller is Windows 2008 R2, verify that the correct security policy
has been applied. For details, see the Technologies, Security and Network
SSO works from one desktop but doesn't work from another
one
z SSO works only from a workstation. If you're trying to single sign-on with Internet
Explorer on the WebLogic server (Application Server) or on the DC/Active Directory
it does not work.
z If your desktop is WIN7 / 2008, verify that the correct security policy has been
applied for Internet Explorer. For details, see the Deskop Applications Deployment
Reference and Installation Guide.
z Review the Deskop Applications Deployment Reference and Installation Guide and
verify that all settings have been configured properly.
z Verify that your desktop is in the same Forest where the SPN was set and which has
the SSOBind user in its Active Directory.
z Verify that you can ping from your desktop both the DNS and FQDN names of the
Application server, and that the correct IP is resolved.
z To log on to the system, ensure that you log on as a user that has access privileges
to the web application portal.
Can I use the IP address instead of the host name for the fully
qualified domain name in the URL when accessing the suite
with SSO?
No, SSO does not work with IP addresses.
What is the problem when the WebLogic server fails to start

and the suite’s home page or the Weblogic console cannot be
accessed?
If the password for the WLSAdmin user has changed (from the default set up during
installation) or the account is deleted, the WebLogic server cannot start.
The correct password is the one which was set in the Domain's Active Directory for the
WLSAdmin user, since that user account is used from now on to access Weblogic.
In case there is a difference from defaults, adjust the password in the boot.properties
file, which is located in the security folder in this directory:
%Impact360SoftwareDir%ProductionServer\weblogic10sp3\Impact360\Pro
ductionDomain\servers\ProductionServer\security
After adjusting the password, restart the WFO_ProductionDomain_
ProductionServer service.
Can SSO fail due to case sensitivity?

Yes. You should follow the case-sensitivity conventions which were defined in the
configuration steps (specifically for setspn and ktpass). Many sub-systems, such as
Kerberos, are case sensitive.
The test user account is also case sensitive. User account names can be checked in the
Active Directory user properties.
For details on configuration for setspn and ktpass, see the Technologies, Security and
Network Integration Deployment Reference Guide.
Can a customer IT department lock prerequisite accounts,

such as Firstuser, WLSAdmin, the SSO service binding
account, or test user accounts to log on only to specific servers
or workstations?
No, locking those accounts to a specific server or workstation will result in SSO
configuration and SSO runtime failure. LDAP and Kerberos do not support a locking
configuration. LDAP and Kerberos will fail in turn under such circumstances.
Note that the SSO test user is only required during the configuration stage.
What should I do when ktpass fails due to an extra setspn?

The command setspn -A HTTP/<hostname> <SSOBind> should never be run. Only
run the command setspn that includes the FQDN.
This extra setspn prevents ktpass from appending the HTTP/<hostname>. If this
wrong usage is discovered, all SPNs shown when running setspn -1 <SSOBind> and
the <SSOBind> user should be removed from Active Directory.
Then recreate SSOBind user and re-run setspn and ktpass as described in the
Technologies, Security and Network Integration Deployment Reference Guide.
Furthermore, no workaround should be made to "fix" the ktpass failure caused by this
extra setspn. A workaround may allow SSO configuration to finish, but it will cause SSO
failure.
Do I have to force DES encryption for the SSOBind account?

DES encryption is mandatory in several environments. For more details, see the
Technologies, Security and Network Integration Deployment Reference Guide.
If your environment requires a DES encryption type:
Make sure this property is selected for the SSOBind account, and reset the password
after you force DES encryption.
By default, DES encryption for Kerberos authentication is disabled in Windows Server
2008 R2 and Windows 7 so you must enable it.
For more details, see the Technologies, Security and Network Integration Deployment
Reference Guide and the Desktop Applications Deployment Reference and Installation
Guide.
Does the SSO Configuration Wizard need WLSAdmin to be

member of WLSAdminGroup or any other privilege group?
No, WLSAdminGroup or any other privilege group is not necessary when SSO is
configured using the SSO Configuration Wizard.
What do I do when the System Monitor tool in Enterprise

Manager triggers an alarm that indicates that the Framework
Applications Administrator Account Name and/or password are
incorrect?
Configure the correct WLSAdmin user and password in the Framework Applications role
settings as described under Configuring the Administrator Account Username and
Password in Enterprise Manager, page 101.
This user and password information should match the username and password that
were defined in the Active Directory and configured in the SSO configuration wizard.
NOTE If you make a configuration change, and the user and password
information do not match the username/password defined in the Active
Directory and configured with the SSO configuration wizard, an alarm is
triggered.
Correct the user and password information, and reapply the configuration
change.
Can the Domain Controller have multiple NICs?

Using multiple NICs on a Domain Controller can cause Active Directory and DNS
problems, often resulting in authentication issues.
For additional guidance on NIC configuration in this scenario, see Microsoft’s article
http://support.microsoft.com/kb/272294.
SSO doesn't work but when I De-Select the Trusted Login

check box and enter credentials, my user is authenticated.
Make sure that the user name in the Users tab under User Management ->
Employees is defined according to the configuration of the Support check box [value:
userPrincipalName] attribute that was defined in the SSO Wizard.
NOTE When configuring the suite with Windows Authentication for use with SSO,
application users cannot be created within the suite web application itself,
but must exist in the Application user forest/Domain Active Directory.
They must be imported from there using the Import Domain Users on
the suite’s web application’s User Management > Profiles screen.
For details on this feature, see the Avaya Aura WFO User Management
Guide.
If the Support check box is selected, the User Name should be in the form of
Username@Domain.
If the Support check box [value: userPrincipalName] was not checked (this is the
default setting), User Name should be in the form of Username only without @Domain.
In case there is a mismatch, edit the user name in the User Management tab in the
web application, appropriately and click Save.
Alternatively, if the mismatch is general to all users, change the logons directly in the
BPUSER table in the BPMAINDB database.
For details on how to use the Support check box feature, see step 4 under Configuring
SSO with the SSO Configuration Wizard, page 93.
If the above does not work, troubleshoot other possible SSO issues as mentioned in the
other troubleshooting sections.
What if somebody changes the service binding account

password?
The key tab file needs to be recreated, as follows:
1 Delete the file SSOKeyTabFile under the
%Impact360Softwaredir%ProductionServer\
weblogic10sp3\Impact360\ProductionDomain folder.
2 Run the following command:
ktab -k SSOKeyTabFile -a HTTP/
<host_or_load_balancer_host_name>@<DOMAIN>
Where:
<host_or_load_balancer_host_name> is in lower case and
<DOMAIN> is in upper case
For example:
ktab -k SSOKeyTabFile -a HTTP/lmapp@WLM.COM
(ktab is located under the JAVA_HOME bin folder.)
Can I run the uninstallService.cmd and installService.cmd in

Windows Explorer by double-clicking them?
No. Running the *.cmd file in Windows Explorer involves both file permission and
relative path issues. Therefore, the *.cmd scripts would fail.
UninstallService.cmd and InstallService.cmd should be run from the command line.
If the operating system on the Application Server is Windows 2008, the command line
must be opened in Administrator mode.
How do I turn on debug mode?

When problems occur in the SSO environment, you need to acquire more debug
information.
By default, debug flags are turned off to minimize the log size and to improve
performance.
To turn on SSO debug, use a text editor to edit the file ssoenv.cmd file, which is
located under the %Impact360Softwaredir%ProductionServer\
weblogic10sp3\Impact360\ProductionDomain folder and append the following
lines to the file.
REM ========= start of debug flags ======================

set ADSSO=%ADSSO% -Dsun.security.krb5.debug=true
set ADSSO=%ADSSO% -DDebugSecurityAdjudicator=true
set ADSSO=%ADSSO% -Dweblogic.debug.DebugSecurityAtn=true
set ADSSO=%ADSSO% -Dweblogic.debug.DebugSecurityAtz=true

set ADSSO=%ADSSO% -Dweblogic.StdoutSeverityLevel=64
set ADSSO=%ADSSO% -Dweblogic.StdoutDebugEnabled=true
REM ========= end of debug flags ======================
You need to restart the WebLogic service to make the debug flags take effect.
In addition, you might consider editing the file krb5login.conf, which is located under
the ProductionDomain folder and set debug=false.
IMPORTANT When debug is turned on, a large amount of information is logged to the
destination STDOUT.
Thus you might want to run Weblogic in command-line mode, or redirect
STDOUT to a log file.
Once you have finished debugging, you must turn off debug mode.
Appendix A
Working with Deployment

Levels
This section describes the deployment levels available in the suite.

See:
z About Deployment Levels, page 114
z Level 1, page 114
z Level 2, page 114
z Level 3, page 114
z Levels 4 and 5, page 115
z Level 6, page 115
Appendix A - Working with Deployment Levels About Deployment Levels
About Deployment Levels

The suite provides a solution for a range of deployment levels from small deployments
(level 1) up to enterprise level (level 6). For the number of agent seats supported for
each deployment level, see the Avaya Aura WFO Performance and Sizing Guidelines.
The following diagram shows the deployment levels regardless of the packages and
applications required by the customer. Each deployment level specifies the relevant
platforms that can be installed on the servers.
The platforms are categorized by Data Center platforms and Site platforms to indicate
the deployment zone.
Servers and their platforms are installed during the installation process, and configured
and activated during Enterprise configuration. For installation details, see the Avaya
Aura WFO Installation Guide.
NOTE The deployment levels content below describes only the platforms that are covered
in this guide. Additional servers that you may be required to install (for example,
Encryption Server) are described in the relevant guides.
Each level specifies platforms that you can install on the servers, depending on the size
of the deployment.
For example, a Level 1 deployment is generally configured for up to 600 agent seats,
while a Level 4 deployment would be configured for up to 7,500 agent seats.
Level 1
This is the smallest deployment size with recording. In this configuration, a single server
is installed with the Consolidated platform, which contains all data center (data and
application) and site (content acquisition/recording) server roles. This is one of the most
common configurations.
NOTE Consolidated platforms contain almost all possible server roless.
Level 2
Next scaling level for one of the following deployments.
Level 3
In the Data Center zone, the Database servers and the Application servers are physically
separated. The separation enables the following:
Appendix A - Working with Deployment Levels About Deployment Levels
z Supports more agent seats.

z Level 3 is the first level that allows you to cluster Application servers for high
availability. High availability can achieve load balancing as well as automatic fallback
across the system.
NOTE
For details on high availability, see About Deployment Levels, page 114.
z The physical separation between the database platform and the application platform
enhances system security.
Levels 4 and 5
Provides physical separation between the Framework Database & Reporting server.
Levels 4 and 5 are differentiated by the required machine.
You can have multiple instances of most platforms. The number of servers required is
determined by customer deployment requirements.
A deployment level 5 requires stronger machines (server model, CPU, and memory).
Level 6
The largest deployment size. Level 6 provides physical separation between all database
servers/platforms (Framework Database, Framework Data Warehouse, Reporting
[Framework].
Appendix B
Managed Servers Overview
This section describes managed servers.

See:
z About Managed Servers, page 116
About Managed Servers

Managed servers are those servers that can be managed and configured from the
Enterprise Manager. For the purposes of this documentation, we are focusing on
setting up and configuring those servers that are defined as managed. (For details
on search and replay applications and external servers, see the Enterprise Manager
Reference Guide).
All servers required for the customer were installed during the Enterprise
installation process. Also during installation, a platform containing a pre-defined set
of server roles was selected for each server that was installed.
In larger deployments (level 3 on), if you are adding servers where the database
and application server roles are installed with separate database and application
platforms, add the servers with the database platforms first, then the servers with
application platforms.
When you add a server to the installation tree, you refer to the server information
you recorded during the installation process. This information includes server name,
port number, SSL port number, HTTP Alias (where applicable), and fully qualified
domain name
Appendix B - Managed Servers Overview About Managed Servers
Once the server is added to the installation tree and configured with the correct
information, the set of server roles associated with that server also becomes
available.
NOTE In larger deployments, you may need to create server clusters for load
balancing and high availability in the event of failover.
These clusters are application server clusters (so part of the Data Center
zone deployment).
For details on clusters, see Appendix C, High Availability and Server
Clusters, page 118.
Appendix C
High Availability and Server

Clusters
This section describes concepts and solutions around high availability and server
clustering.
See:
z About High Availability, page 118
z About Server Clusters, page 120
About High Availability

The Enterprise Suite provides different levels of high availability for customer
installations, particularly for application and database servers.
High availability built into a customer’s configuration allows:
Appendix C - High Availability and Server Clusters About High Availability
z Load balancing - with load balancing, the application/data load is evenly distributed
across the system.
z Automatic failover - with automatic failover, if a server goes down, the system is re-
routed to another server. In this scenario, users lose their sessions, but can log back
on to the system, so that their downtime is minimal.
z Continuous data accessibility wherever databases have been configured for high
availability.
NOTE High availability features in a customer’s Enterprise Suite configuration
also provide maintenance and disaster recovery options for the customer’s
system.
For details on maintenance and disaster recovery, see the Enterprise Suite
Maintenance Guide.
See:
z Application High Availability, page 119
z Database High Availability, page 119
Application High Availability

To achieve application high availability, you cluster a set of application server nodes in
the Data Center zone. Each application server node in a cluster contains the identical set
of server roles, each set of server roles is configured identically.
Thus when one of the application servers goes down, the application information is re-
routed to another server. The user’s session ends, but the user can then log back on and
continue using the application.
Since an application server is ‘stateless’ (only containing information about the
application software itself but no data), in the event of server corruption, the application
server can be replaced with another server without any data loss.
The new server can be easily added to an application cluster and the cluster mechanism
in the Enterprise Manager automatically provides the new server with the same
configuration as the other servers in the cluster.
This high availability option is available to deployment levels 3 to 6.
Database High Availability

Database high availability protects availability and access to the data.
High availability for databases is achieved by deploying the Enterprise Suite database(s)
on the customer’s existing SQL server farm or SQL cluster with multiple nodes, instead
of deploying the customer’s SQL database on a server in an Enterprise Suite Data
Center zone.
An SQL server farm or cluster is a deployment of multiple servers that is highly scaleable
and can achieve high-performance. An SQL server farm can be expanded (scaled) to
accommodate increased site traffic and site performance in a cost-effective manner.
Appendix C - High Availability and Server Clusters About Server Clusters
This setup also provides a failover mechanism so that if there is a problem with one
server node in the farm, another of the cluster nodes is always available so that the
customer data is always accessible.
Since the SQL server farm is deployed remotely, which in this context means that SQL
runs on servers other than those running the Enterprise software, a database platform
server is set up in the suite’s Data Center zone, and manages (installs, configures and
monitors) the remote SQL database setup.
In this setup, the application servers containing the suite software products access the
remote SQL cluster directly. This access is configured by adding the correct URL for the
remote SQL cluster during the database server role configuration process.
About Server Clusters

Server clusters consist of multiple servers with identical server role configurations and
associations, and appear below the site node.
Server clusters are created for Data Center zone application servers (these servers
contain the platform that comprises application server roles).
NOTE Multiple application servers in larger deployments are always configured
as server clusters.
NOTE Typically, Enterprise Manager prevents servers added to a cluster that

contain roles that are not supported in a cluster.
While the server role can reside in a cluster that doesn’t support it,
Enterprise Manager prevents you from enabling such roles.
The most common use of a server cluster is to support load balancing and high
availability.
Server clusters are generally used with larger deployments (for details on deployment
levels, see Appendix A, Working with Deployment Levels, page 113).
Within a server cluster, multiple servers work together to operate as a single logical
server. These servers all provide the same functionality to the user:
z With load balancing, server clusters ensure that user connections are equally
distributed to the multiple servers in the cluster, supporting the workload of a large
audience of users.
z With high availability, when one server in the cluster fails, that server’s workload
can be redirected to the remaining functioning servers in the cluster. This way
supported functionality is always available to the users (for details on high
availability, see About High Availability, page 118).
A load-balancing device is deployed in front of the server cluster to ensure user
connections are equally distributed to the multiple servers in the cluster.
Appendix C - High Availability and Server Clusters About Server Clusters
This deployment is more efficient than unclustered servers as it allows the workload
associated with a large audience of users to be equally distributed among multiple
servers.
Also, if one server in the cluster fails, that server’s workload can be redirected to the
remaining functioning servers in the cluster ensuring the supported functionality is
always available to the users.
Users connect to the load balancing device to access the server cluster. To support a
server cluster, the address of this load balancing device must be specified in the
following locations:
z The HTTP Alias in the Settings tab of each clustered server.
z If the Enterprise Manager application is one of the applications on the clustered
servers, you must also specify the address of the load balancing device in the
System Management > General Settings > Enterprise Manager Location
tab.
Appendix D
Server Roles and

Associations and
Constraints/Restrictions
The following provides brief descriptions of server roles and associations:

z Server Roles, page 123
z Server Role Associations, page 123
z Server Role and Association Constraints, page 124
Appendix D - Server Roles and Associations and Constraints/Restrictions Server Roles
Server Roles
Server roles are activated depending on the products for which a customer is licensed,
and the server roles that are required for each product.
Some of the functionality supported through the configuration of server roles includes:
z Framework applications
z Reporting
z Databases
Each server role is comprised of separate components that are grouped together to
support a specific functionality.
Most server roles must function in association with other server roles to achieve product
functionality; once server roles are activated and configured, most associations are
identified for each server role.
Each server role also has a version, which can change during upgrades and patches
when the role metadata changes.
If you plan to copy server role configurations for multiple server sites, the server roles’
version numbers must match.
For more information on server roles and their place in the suite architecture, refer to
the Avaya Aura WFO Technology Overview Guide.
Server Role Associations

The functionality for which a server role is configured generally (but not always)
requires other server roles to work with it - these are associated server roles.
Most server role associations are configured automatically when you configure server
roles on a server, and in general, it is not recommended that you change server role
associations.
How Associations Function
NOTE For purposes of the explanation below, Role A is the server role you are
describing in the following section, and Role B is the associated server
role.
z Within EM, each server role screen (the Settings screen) has an accompanying
screen (the Associations screen).
z Most role associations are both mandatory and automatically activated. However,
in some cases (described in the server role sections that follow), installers may
need to configure a server role’s associations. It is not recommended that you
change mandatory, automatic associations.
z If a mandatory association is missing, the Enterprise Manager’s alarming system
reports an error.
Appendix D - Server Roles and Associations and Constraints/Restrictions Server Role and Association Constraints
z An association may be the dependency between Role A and Role B is either

functional or configuration-based.
z Note that a server role’s associations (associated roles) are categorized according
to type and scope.
Type
A server role’s association with other roles may be:
z One-to-One (1:1) – the server role can be associated to only one instance of the
other role
z One-to-Many (1:N) – the server role can be associated to zero or more instances
of the other role
z One-to-All(1:All) – the server role should be associated to all instances of the
other role
The association type determines how many associated roles can be associated to the
role.
Scope
A server role’s association scope - Enterprise, Site Group, Site scope, Server Scope -
limits how a role is associated to other roles.
Example:
If Role A has a Type of 1:1 association to Role B with Scope of Site, Role A can be
associated to one Role B within the same site as Role A. If there is another instance of
Role B that is not on the same site as Role A, it will not be associated to Role A.
Server Role and Association Constraints

Some server roles and their associations have constraints or restrictions on how they
are used or configured.
Server Role Constraints

Some server roles have constraints. A server role constraint is a particular condition or
restriction under which the server role must operate. Examples of server role
constraints include:
A restriction on the number of server role instances that can exist within a particular
Site or within the Enterprise.
There are three levels of restrictions:
Appendix D - Server Roles and Associations and Constraints/Restrictions
z Lax - If you violate a lax server role constraint, a warning message displays in the
Configuration Status tab. You can ignore the warning and the system will continue
to function.
z Overrideable - If you violate an overrideable server role constraint, an error or
warning message appears in the Configuration Status tab. You can ignore this
message and the system will continue to function, although the error indicates your
configuration is not optimal.
z Strict - If you violate a strict server role constraint, an error message appears in the
Configuration Status tab and you cannot ignore the error. The system will not
function properly until the error is addressed.
For example, there can be only one Foundation Application Server server role active on
all servers in the enterprise. If more than one Foundation Application Server server role
is active, Enterprise Manager reports a server role constraint violation.
Associated Role Constraints

These constraints determine whether a server role association is mandatory or optional.
There are three kinds of server role association constraints:
z Required - A server role must be associated to another server role to operate
properly. If the server role is not associated with the other server role, an error
message appears in the Configuration Status tab and the system will not operate
properly until the association is created. This constraint is enforced even if the
required role is not installed or activated.
z If Exists - A server role must be associated to another server role if the other server
role is installed and is active. If the other server role is not installed, or is not active,
the server role association is not mandatory. An error message displays in the
Configuration Status tab for this kind of server role constraint.
z Optional - A server role association is optional. No errors are reported if the server
role association is not made.
There are other types of server role constraints. If a server role violates one of its
constraints, Enterprise Manager reports a server role constraint violation in the
Configuration Status tab.
You must remedy any server role constraint violations reported by the Enterprise
Manager.
For information on configuration status, see Chapter 6 “Validating Configuration”.
Appendix E
Configuring Active Directory

with Lightweight Directory
Access Protocol (LDAP)
This section contains the following:

z Overview, page 127
z LDAP Authentication Workflow, page 127
z Configuring LDAP, page 128
Appendix E - Configuring Active Directory with Lightweight Directory Access Protocol (LDAP) Overview
Overview
By default, the suite stores usernames and passwords in the system database. The
passwords are encrypted there. This set-up is known as DBRealm.
However, the authentication method can be changed to use LDAP for user
authentication. You can use existing usernames and passwords to log into the suite’s
web application, making the system much easier to use and maintain.
The suite’s user authentication and support for LDAP is controlled by Oracle WebLogic,
the application server platform. To configure LDAP user authentication, you must have a
good understanding of the technical configuration details of your LDAP server.
For more details regarding the requirements for the Windows Active Directory user
authentication, see relevant sections in the Technology, Security and Network
LDAP Authentication Workflow

The following describes the workflow used for LDAP authentication within the suite:
1 A user opens a browser to access the suite, which provides an HTTP form to let the
user input a username and password.
2 The user submits the form through an HTTP/HTTPS posting to the application
server, using port 80 (or 7001 on the WebLogic server).
3 The application server opens a connection to the Active Directory server under a
predefined user name, and issues a query to verify the username/password through
the Active Directory protocol, using port 389.
4 The application server receives a positive result from the Active Directory server,
and then generates user information in the HTTP Session, issuing back an HTTP
session ID as a cookie to the browser.
5 The user continues operation with the browser, which will always send back the
cookie with the session ID to the application server.
6 The application server retrieves the user information stored in the HTTP session
based on the session ID from the cookie; it does not authenticate the user a second
time.
7 When the user signs off from the web application, the HTTP session is cleared along
with user information.
If the user doesn't issue any HTTP request in a given window (controlled in the suite),
the application server automatically times out the HTTP session.
Appendix E - Configuring Active Directory with Lightweight Directory Access Protocol (LDAP) Before You Begin
Before You Begin

Before you configure LDAP, back up the ProductionDomain folder on the Weblogic
server to a location from which you can retrieve it, in the event that the configuration
fails and the system needs to be restored.
The ProductionDomain folder can be found at this location:
%Impact360Softwaredir%\ProductionServer\weblogic10sp3\Impact36\
ProductionDomain
Configuring LDAP
NOTE The information in this section has been tested with Microsoft Active Directory only. Any other
Active Directory server server may differ in configuration. Also, this integration is not a single
sign-on solution. You may choose to try another Authenticator but the application may not
function properly. If you run into problems, contact our support services team.
You need the following information for LDAP configuration:

z The host name or IP address of the Active Directory server.
z The port number on which the Active Directory server is listening. (default port =
389)
z The User Base DN of the Active Directory server.
z The Group Base DN of the Active Directory server.
z The user account that has access to query the Active Directory server for
usernames and passwords; or you can use the WLSAdmin user. Instructions for
creating the WLSAdmin user is described in the Technology, Security and Network
z The domain name of the Active Directory server (for example, qa.acme.com)
NOTE We recommend that you try the following procedure first on a test or training
environment. In any event, make sure to back up the ProductionDomain folder on
the Weblogic server, as described in Before You Begin, page 128.
NOTE If your system has an application cluster, the following procedure must be
completed for each application server separately.
To configure LDAP
1 Validate that you have created these users in Active Directory:
z Username = WLSAdmin
z Username = FirstUser
Appendix E - Configuring Active Directory with Lightweight Directory Access Protocol (LDAP) Configuring LDAP
2 Create a group under the Active Directory server’s Group Base DN called
WLSAdminGroup that contains these two users.
NOTE WLSAdmin is used to start WebLogic. This user must be created in Active
Directory for WebLogic to authenticate during startup. Firstuser is a user that is
used to administer WebLogic and the suite web application after startup. If this
user is not created, you are not able to log in to the WebLogic console and make
changes.
3 The user authentication and support for LDAP is controlled by WebLogic. To access
the LDAP configuration, you must first log on to the WebLogic console. The console
can be found at:
http://<applicationservername>:<port>/console
where:
<applicationservername> is the name of your application server
<port> is the port on which the Weblogic server is listening (default 7001)
4 Log on as WLSAdmin. The WebLogic Server Administration Console opens.
5 In the upper left corner, in the Change Center area, click the Lock & Edit button.
6 On the left panel under Domain Structure, click the Security Realm folder.
7 On the right panel, click BPDBRealm name, then click Roles and Policies >
Realm Roles.
NOTE It is usually more convenient to modify the existing BPDBRealm instead of creating
a new realm in Weblogic.
8 In the Roles area, under the Name column, expand Global Roles, then expand
Roles.
9 Under Roles, select Admin and under the Role Policy column, click View Role
Conditions.
10 On the Edit Global Role screen, click the Add Conditions button.
11 Complete the following steps:
a. In the Edit Global Role screen, from the Predicate List drop-down list box,
select Group, and then click Next.
b. In the next screen, beside Group Argument Name, type WLSAdminGroup,

click the Add button, then click Finish.
c. In the final screen, select the group you want to use (that is, Group:
WLSAdminGroup), then click Save.
12 On the left panel, click Security Realms, then click BPDBRealm > Providers >
Authentication.
13 In the Authentication Providers area of the Authentication tab, click the New
button.
The Create a New Authentication Provider screen displays on the right panel.
14 When prompted to create a new authentication provider, in the Name field, type a
name, <NameAuthenicatorProvider> and in the Type field, select
ActiveDirectoryAuthenticator. Then click OK.
15 Do the following:
a. Click the newly created Active Directory Authenticator in the Authentication
Providers screen.
b. Navigate to Settings for ActiveDirectoryAuthenticator > Configuration >
Common tab and, inside the Control Flag drop-down list box, select Sufficient
and then click Save.
16 On the Settings for ActiveDirectoryAuthenticator > Configuration >
Provider Specific screen, set parameters:
z In the Connection area of the screen, set parameters as follows:
z Host: provide hostname or IP address of the LDAP server.

z Port: provide port number on which the Active Directory LDAP server listens
z Principal: The user name created on the AD server that the Weblogic server
uses to connect to the AD server. WLSAdmin can be used here.
z Credential and Confirm Credential: Enter the credential (password) used to
authenticate the above user specified in the Principal field.
z Ensure that the SSL Enabled check box is selected only when configuring
secure LDAP (with SSL certificate installed). If you turn this option on without
configuring SSL, you cannot start the WFO service afterwards.
z In the Users area of the screen, set parameters as follows:
z User Base DN: Enter settings for this field, for example: CN = Users; DC =
<domain>; DC = com; and so on. This setting needs to include the
WLSAdmin and FirstUser user names identified in step 1.
z User From Name Filter: When using Microsoft Active Directory, replace the
CN portion of the filter name with sAMAccountName.
NOTE This filter must be set to sAMAccountName for WebLogic to read the logon name
in Active Directory. If it is set to CN, WebLogic reads the display name and not the
logon name.
z User Name Attribute: Enter sAMAccountName.

z All other Users parameter defaults should be retained.
z In the Groups area of the screen, set parameters as follows:
z Group Base DN: For example dc=qa,dc=<domain>,dc=local. This setting

needs to include the WLSAdminGroup.
z Group Search Scope: Ensure that subtree is selected.
z All other Group parameters should retain their default values.
17 Once you are finished configuring this screen, click Save.
18 Return to the Providers > Authentication screen. In the Authentication
Providers area, the list displays the ActiveDirectoryAuthenticator you just
created, and the former authentication provider names (for example, the default DB
authenticator, wfosDBAuthenticator).
19 In the event that one of the providers in the list is no longer required (for example
wfosDBAuthenticator), select the check box beside it and click the Delete
button.
20 In the upper left corner, click the Activate Changes button.
21 Complete the stop and restart WebLogic services process, as described in the
procedures under Stopping and Restarting the WebLogic Server, page 142.
NOTE If WebLogic cannot restart because of an error in the configuration
described above, restore the backed up copy of the ProductionDomain
folder that you had saved prior to beginning the LDAP configuration
process.
For details, see Before You Begin, page 128.
NOTE If you have created created Firstuser to replace wsuperuser, the name
WSUPERUSER should be changed to Firstuser in the BPUSER table in
the BPMAINDB database.
22 If a change is made to the default Admin User (WLSAdmin) and Admin password
that connects to Weblogic, configure the correct user name and password in
Enterprise Manager in the suite’s web application. For details, see Configuring the
Administrator Account Username and Password in Enterprise Manager, page 143.
Stopping and Restarting the WebLogic Server

To finalize your LDAP changes you need to stop and then restart the WebLogic server as
described below:
z To stop the WebLogic Server, page 142
z To restart the webLogic server, page 143
To stop the WebLogic Server

1 Navigate to Windows Server Manager > Services and stop the Weblogic service
(WFO_ProductionDomain_ProductionServer).
2 Stop the Watchdog service, to ensure that the

WFO_ProductionDomain_ProductionServer service does not start
automatically.
To restart the webLogic server

NOTE WLSAdmin or its replacement is used to start the WebLogic server.
If the user name or password for the WLSAdmin has changed (from the
default password) or the account has been deleted, the WebLogic server
cannot start.
The correct password is the one that was set in the Domain's Active
Directory for the WLSAdmin user, since that user is used from now on to
access Weblogic.
If there are changes made to the default user/password, make sure to
adjust the password in the boot.properties file, which is located in the
security folder in this directory path:
act360\ProductionDomain\servers\ProductionServer\security
Once you change the password, begin the following procedure.
1 Open Command Line (if this is on a WIN2008 operating system, open the command
line as an administrator). Navigate to the ProductionDomain folder, which is
located in this directory:
%Impact360Softwaredir%ProductionServer\weblogic10sp3\Impact360\
ProductionDomain
2 In the ProductionDomain folder, run uninstallService.cmd.
3 In the ProductionDomain folder, run installService.cmd, which automatically
restarts the Weblogic Windows service.
4 Start the Watchdog service and verify that the WFO_ProductionDomain_
ProductionServer service is running.
Configuring the Administrator Account Username and

Password in Enterprise Manager
1 Wait until the Weblogic service is up and then log on to the suite web application.
2 On the login screen, type the username and password of the ‘super’ administration
user, such as Firstuser.
Appendix E - Configuring Active Directory with Lightweight Directory Access Protocol (LDAP) Validating the LDAP
3 In the suite web application, navigate to System Management > Enterprise

Management and, under the Application Server node, select the Framework
Applications server role.
4 On the server role’s Settings tab, in the Server Access area, type the correct
username and password in the Administrator Account Name and Administrator
Account Password text boxes.
5 Click Save.
Validating the LDAP Configuration

To validate the LDAP configuration, log on to the system with Firstuser or any other
application user from Active Directory.
The configuration is validated once you are able to log on with the above users.

Avaya Aura WFO Configuration Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Avaya Aura WFO Configuration Guide

Uploaded by

Copyright:

Available Formats

Avaya Aura WFO

2 License and Product Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Site Organization and Server Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Creating an Application Server Cluster . . . . . . . . . . . . . . . . . . . . 39

4 Enterprise Settings and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5 Server Role Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Avaya Aura WFO Configuration Guide 4

7 Configuring Single Sign-On (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Avaya Aura WFO Configuration Guide 5

A Working with Deployment Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

B Managed Servers Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

C High Availability and Server Clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

D Server Roles and Associations and Constraints/Restrictions . . . . . . . . . . . . . . . 122

Avaya Aura WFO Configuration Guide 6

Suite Architecture and Deployment Overview

Avaya Aura WFO includes the following integrated products:

Avaya Aura WFO Configuration Guide 8

z Platforms and Server Roles, page 9

Platforms and Server Roles

Suite products are part of a software solution that is comprised of:

Avaya Aura WFO Configuration Guide 9

Avaya Aura WFO Configuration Guide 10

Avaya Aura WFO Configuration Guide 11

Configuration Access Privileges

To change Administrator access to configuration roles and privileges:

Avaya Aura WFO Configuration Guide 12

5 Under Role Name, make sure Administrator is selected.

Avaya Aura WFO Configuration Guide 13

Suite Configuration Workflow

3 Creating Site Group Nodes on page 29

Chapter 4 “Enterprise 6 Configuring General Enterprise Settings on page 48

Chapter 5 “Server Role 9 Activating/Deactivating Server Roles on page 64

Chapter 6 “Validating 11 Reviewing Notifications on the Configuration Status

Avaya Aura WFO Configuration Guide 14

Avaya Aura WFO Configuration Guide 15

License and Product

About Licensing and Product Activation

3 License registration key generation: During installation of the customer’s

Avaya Aura WFO Configuration Guide 17

NOTE If the license activation process described in steps 2 to 5 were completed

Avaya Aura WFO Configuration Guide 18

Avaya Aura WFO Configuration Guide 19

Avaya Aura WFO Configuration Guide 20

Product Activation using the License

Avaya Aura WFO Configuration Guide 21

Avaya Aura WFO Configuration Guide 22

b. In the Windows Services window, restart the Weblogic service called

Avaya Aura WFO Configuration Guide 23

Avaya Aura WFO Configuration Guide 24

Site Organization and Server

This hierarchy is referred to as the Installations tree.

Before You Begin

Avaya Aura WFO Configuration Guide 26

Setting Up the Installation Tree

Accessing the Enterprise Manager Tool

To access the Enterprise Manager tool

Avaya Aura WFO Configuration Guide 27

Setting up Site Group Nodes and Site Nodes on the

About the Enterprise node

Avaya Aura WFO Configuration Guide 28

About Site Group Nodes (optional for larger deployments)

Creating Site Group Nodes

Avaya Aura WFO Configuration Guide 29

Creating Site Nodes