Chapter 10

Administration Manager (20071205)

Chapter Goal
The goal of this chapter is to get a brief introduction on the use of Avaya Administration
Manager (AM) for basic PDS Admin Manager User tasks.

Chapter Learning Objectives

After completing this section you will be able to:
• Explain the stages of data synchronization for AM
• Instruct the PDS AM User on how to run an Empty data install and a Data install
• Instruct the PDS AM User on how to run a “fake” install data to look at complete files
before they are installed on the PDS

Administration Manager 3.0

Administration Manager is a separate application that resides on the System Operator’s
workstation. It is a powerful tool for administering the PDS and allows quite a bit of
configuration changes to be made by the end user. If used correctly, the user can
make infinite changes to the system. If used incorrectly (or without full knowledge of
what the user is doing) it can cause a PDS to not function or limit the functionality of
features or calling lists. Because of this power, only users who have been to training
on this product should have access to the application. This is often not the case, but it
is the ideal situation.
Administration Manger 3.0 is the current version of this application for Avaya PDS
Version 12.0 and version 11.x. It is often called Admin Manager.
APC 3.0 does not have a separate application for the configuration available in Admin
Manager. APC 3.0 instead has some of the functionality of Admin Manager built into
the Supervisor application and some built into the CUI menus. Note that some of the
functionality of Admin Manager is not built into APC 3.0 at all. You will learn more
about this in other courses later.
For prior PDS versions (9x,11x), the Admin Manager product was named Producer, and
Admin Manager is often referred to as Producer by System Operators and Support
staff.
For simplicity in this chapter, the application will be referred to as “AM”.

1
 Course Title

• Admin Manager overview

Using AM takes additional training for the System Operators or Administrator. This is
extremely important, as someone using AM without proper training and experience
can easily cause the PDS to fail. For this course, the user will be referred to as the
PDS AM User. It is not uncommon for a company to have only one person trained on
AM and this would likely be the same person that handles most of the System
Administrator tasks as well.
It is strongly suggested that only limited changes be made to the PDS at a time.
Especially when large calling lists are modified, the changes can take considerable
time to go in place.

In chapter 1 you downloaded the User’s Guide for AM, read chapter 1 (overview) for
functionality and some cautions.

• Install of AM
Unlike the Campaign Director suite, the install of AM is quite time consuming and
complicated, requiring configuration and synchronization with the PDS when first
installed. This course will not go through the install of AM as it is rare that PDS
Support has to install it, and there are workorders which detail the installation steps.

• AM User Accounts
AM has three user accounts, each with more access to functionality. The two for the
PDS Admin Manager user are “user1” and “user2”. User1 can modify the Completion
Codes, Agent Keys files, and the Messages (virtual/autoplay messages, wait queue
messages, calling scripts, etc). User2 can do those and modify/add/delete calling
lists, uploads and downloads, and modify the scheduling of automated tasks (like the
processing of lists). The other user is “var1” which is for use by PDS Support and
Installers only for the configuration and interoperability of AM with the PDS.
Each revision of the application has different passwords for each user. See Avaya’s
knowledge base for the current list of passwords for AM.

• User’s Guide
The AM User’s Guide has quite a bit of information about how to do each of the
functions of AM. There is also a Glossary at the end of the manual which will explain
a lot of the terms used throughout the User’s Guide. What they do and how they
configure things are based on their business needs. PDS Support should not be
involved with making suggestions around how or what their uses are, we can refer
them for getting a paid consulting engagement if they want advise around that.
Whenever a PDS AM User opens a case for support on how to do something with the
application, make sure to refer them to the User’s Guide first.

• AM data synchronization
Chapter 2 discusses the data installs and how the AM application knows what state the
configuration is in (by the status codes associated). Specifically, pages 2-6 to 2-10

2
 Course Title

discuss the data sync. Read the whole chapter and discuss confusions with your
course facilitator.

• Data Install
(Empty) Install Data
The first thing that ALL PDS AM Users must do it understand the Install Data and Empty
Install Data process. This terminology is interchangeably referred to as Data Install or
Empty Data Install by PDS Support. These processes are how the AM application
syncs changes with the PDS. There must be a careful syncing process so that prior
changes will not be overwritten with new changes.
Basically the AM application builds new configuration files on the Windows PC and
exports them to the HP Unix CPU. The changes go live when the PDS Application
restarts (typically just after midnight nightly). If one change is made and sent to the
PDS and then another change is made but did not take into consideration the last
change, the second one will go in place and the first one will be lost.
The Empty Install Data verifies that the current configuration seen in Admin Manager
matches the configuration on the PDS. It is a good idea for this to be done prior to
each time any modifications are being made by an Admin Manager user.
Instructions for performing the “Empty” Install Data starting on page 2-13.

• Uses of AM
As discussed in the manual, there are many uses for AM. Each business will modify
different areas depending on their business needs. Some use the application
regularly, others very seldom. Like most things about the dialer, the use of this
application varies a huge amount.
Each chapter of the User’s Guide gives information about each area before giving the
steps on how to do it. Take some time and read through the first section of each
chapter to familiarize yourself with each area which can be changed.
This course does not intend to teach you how to make changes in AM, as that is not
your role in PDS Support, and if changes have to be made, you would typically do
them manually from the command line of the PDS CPU.

• Reports
The last use of AM is the reports within the application. These reports allow the PDS
Admin Manager user to see the current configuration of their PDS which can help to
formulate any planned changes to these configurations. This reporting functionality is
a very underutilized by the typical PDS AM User.
For instance, a report can be run from AM which shows the complete configuration of
the calling lists. This can be incredibly useful if the PDS AM User needs to make
changes. As you saw earlier in this course, you can run an fdictdump of the calling list
an adump of the raw file. These are especially useful to use to look at the raw file
from the host and see which characters and fields show up in which character space
so they can build their calling list configuration. Using those two menu options along
with the reports which can be generated from AM, the PDS AM User can do most of
the troubleshooting of their configuration without involving PDS Support.

3
 Course Title

That is not to say that they don’t contact PDS Support. They usually do call us to tell
them what they did wrong (or more often, to tell us that our product does not work
because they configured it correctly but the calling list is coming out wrong).

• Support of AM
Most of the support cases we get are not on how to do things, but making sure the
changes are okay and will not break anything, or backing a change out because it did
break something. There are many knowledge base articles about this, so this course
will not go into that in great detail, just give some general information about what you
may encounter.

Back Out Changes

When changes are made and Installed, the PDS Application restart puts these changes
into place. Occasionally, a change that is made can have negative consequences
such as part of the PDS Application will not start up, or a calling list format has been
changed in such a way that the calling list fields do not line up and the list appears
corrupted.
Part of the Install of AM changes on the PDS involves backing up the original files. PDS
Support can restore these changes and clean up any problems associated (maybe
restoring calling list configuration or restarting the PDS Application with the old files in
place).

Verify Changes
When PDS AM Users want to make sure their changes are valid, they can do a “fake”
install data. They save their proposed changes as complete and do an Install Data,
but cancel the actual data install process. This will save the complete files which
would normally be exported to the dialer into an “export” directory on the AM
workstation. They can then share these files with PDS Support so we can verify them
(they are just configuration files which you will learn about later in this course). This is
very useful for Messages and wait queue script type changes.

Changes and files on the PDS

Changes made in AM create new configuration files. As PDS Support, you need to
understand the relationship of areas in AM and the files which will be modified. This
will be discussed later in the course as you learn the Unix side of the PDS.

Bind Parameter errors

One issue that seems to get escalated a lot is a Bind parameter errors. These are
caused by parameters being over a certain size. The AM User will get an error on
their AM workstation similar to the below.
Bind Parameter value for ' :7' is to big(15)
No changes made to the database
INSERT INTO c_action_command(system_id, sw_version,
keyword,seq_no,tree_seq,filename,name,live,complete, f_base) VALUES(?, x10)

Bind Parameter value for ':3' is too big(15)

No changes made to database

4
 Course Title

INSERT INTO
c_xfer_summary(system_id,live,xfer_name,description,create_stamp,create_user,modify_st
amp,modify_user,end_hour,end_min,end_time) VALUES (?, x11)

These errors indicate that some parameter that the AM User entered was too long.
Usually this is a file name or an entry in part of a configuration set with too many
characters. There are places in AM which do not limit the characters on the screen,
but when the changes are attempted to be saved, the error is seen.

Dialer Event Schedules

This gives the PDS AM User the ability to schedule activities from the Unix Crontab file.
The best advice for creating new events is to look at the format of a current working
event and match that format (for instance, all must include a redirect to /dev/null).
As these are scheduled, it is important to think about other scheduled events and to not
put them all around the same time. For instance, do not schedule a backup of the
system right before it reboots.

Common Support Issues

There are many documented issues with the AM application, its connection states with
the PDS CPU, and bugs which are known to cause problems. The Avaya Knowledge
base has a lot of articles and should help when you are working issues with PDS AM
Users.
One of the most common is a known issue where changes to Calling Scripts will fail and
subscripts will be deleted in the new file. PDS Support can either recreate the
subscripts which are deleted manually or back out changes and provide information to
the PDS AM User about what they need to do to avoid having AM cause this problem.
See Avaya’s Knowledge Base for articles about this problem.