PureConnect®

2023 R3

Generated:
09-November-2023

Content last updated:

CIC Multi-Site
24-April-2020
See Change Log for summary of
Technical Reference
changes.

Abstract
This technical reference describes CIC Multi-Site, optional CIC software
that links two or more CIC contact centers to route interactions from one
location to another. Multi-Site provides a company-wide directory,
universal user extensions, and other features that boost employee
mobility.
For the latest version of this document, see the PureConnect
Documentation Library at: http://help.genesys.com/pureconnect.

For copyright and trademark information, see

https://help.genesys.com/pureconnect/desktop/copyright_and_trademark_information.htm.

1
Table of Contents
Table of Contents 2
Introduction to Interaction Multi-Site 4
Organization of material 4
About CIC client versions 4
Apply new releases 4
Multi-Site Concepts 5
How Multi-Site Differs from Status Aggregator 5
Multi-Site Supports Roaming Users 6
Each user has a Home Site 6
Traveling users log on at a Peer Site 6
License considerations 6
Connected CIC Servers Form a Collective 7
Collective Workgroup 7
User information propagates automatically 7
Company-wide directory, extensions, and agent status indicators 7
Multi-Site Messaging 7
Multi-Site RTM Client/Server Components 8
Message Flow Between CIC Sites 8
How Should a Floating User Sign at Another Location? 8
Multi-Site Installation Tasks 9
Overview of Multi-Site installation tasks 9
Install Multi-Site Server on a Dedicated Computer 10
Install Multi-Site Server and Client on a CIC server 10
Install Multi-Site RTM Client on a CIC Peer Site 12
Multi-Site Configuration and Administration Tasks 14
Understand Site Identifiers and Passwords 14
Configure the Current Site 15
Define Peer Sites 15
Configure a Peer Site to Route Calls to Another Peer Site 17
Configuration in Interaction Administrator and DCOM 17
Guidelines for User Extensions 20
Similar user extensions on different peer sites when adding servers to a collective 20
What happens if I have two sites and they do have similar user extensions? 20
Grant Permissions to Users 21
Add Users to the Collective 21
RTM Server Command Line Parameters 22
Install RTMServer as a local service: 22
Install RTMServer as a remote connection: 22
Register RTMServer as a local DCOM Server: 22
Register RTMServer as a remote DCOM object: 22
Uninstall RTMServer (either mode): 22
Change a Site ID 23
Tools and Handlers 24
Multi-Site Tools 24
Multi-Site Create Message 24
Multi-Site Get Integer 24
Multi-Site Get Note 25
Multi-Site Get String 25
Multi-Site Message Received 25
Multi-Site Put Integer 26
Multi-Site Put Note 26
Multi-Site Put String 27
Multi-Site Send Event 27
Multi-Site Send Request 28
Multi-Site Send Response 29
IpNotes Tools 30
Send a Message That Does Not Require a Response (Handler1) 32
Handler1 example 32
Send a Message That Requires a Response (Handler2) 33
Handler2 example 33
Receive a Message (Handler3) 34
2
 Handler3 example 34
Testing and Troubleshooting 35
Verify site connection 35
Test workgroup member 35
Multi-Site RTM Servers cannot communicate 35
RTM message not transferring 35
File-based Mail Connector limitation 35
Multi-Site fails 35
CIC system cannot find a name prompt 36
CIC Server or RTM Server access denied 36
Exception thrown error 36
Change Log 37

3
Introduction to Interaction Multi-Site
Multi-Site is optional Customer Interaction Center (CIC) software that links two or more CIC contact centers to route interactions
from one location to another. Multi-Site provides a company-wide directory, universal user extensions, and other features that boost
employee mobility. It extends the CIC environment to support roaming users. For example, Multi-Site routes interactions to an
agent's current location.
Multi-Site is for organizations that use CIC as the local communication system in multiple office locations. Each CIC server has its
own dial plan, user base, and Notifier. Multi-Site allows spanning users to work from any location in the CIC collective as if that
location were the user’s home server.
Don't confuse Multi-Site with Interaction Director, another CIC extension that tells calls where to go. Director balances loads
among multiple CIC sites and routes calls according to specific agent skills. Director provides cost-effective geographic call
distribution between contact centers, whereas Multi-Site enhances employee mobility by making CIC servers in multiple locations
work as if a single server were involved.
For example, an organization with offices in New York and Paris could use a CIC server at each site as the local communications
system. Each CIC server contains an embedded PureConnect platform with its own Notifier. Once you configure the two servers for
Multi-Site, they immediately make an inter-Notifier connection and start to exchange information. Multi-Site provides the following
business-level capabilities:
Company-wide directory: Employees in New York can access phone numbers and other information for employees in Paris
and vice versa.
Universal user extensions: You can configure single organizational dial plan and make it transparent to users. For example,
you can set up five-digit dial plan and automatically make the necessary long-distance call to reach an employee in Paris.
Employee mobility: Employees can move from location to location and still have the same communications access. For
example, suppose that Pierre is an employee in Paris with an internal extension of 6734. Assume that Pierre goes to New York
for three days for meetings. He can use his laptop to log on to the New York CIC system. A call to extension 6734—whether
placed from New York or Paris—routes intelligently to Pierre (without going unnecessarily through Paris).
Real-time status: The ClientServices component of CIC tracks the real-time status of logged on users—for example, whether
they're available, in a meeting, at lunch, or on vacation. This component even knows when users are on the phone.
ClientServices shares this status information automatically among multiple instances of the PureConnect Platform at different
locations. In the current example, Pierre's manager in Paris can tell at a glance when he comes out of a meeting in New York.
Together, these capabilities help distributed organizations to interact more efficiently than ever before.

Organization of material
The CIC Multi-Site Technical Reference explains what Multi-Site is and the benefits that it provides. It's for the CIC administrator or
anyone who is installing Interaction Multi-Site.
Multi-Site Installation Tasks explains how to install Multi-Site server and client components.
Multi-Site Configuration and Administration Tasks explains how to activate the current site, define Peer Sites, add users to the
collective, and complete other routine activities.
Tools and Handlers is for Interaction Designer authors and programmers. It discusses handler development and provides
information about the Multi-Site and IpNotes tools.
Testing and Troubleshooting provides procedures to ensure that Multi-Site is performing properly.

About CIC client versions

CIC supports two interaction management client applications. In the CIC Multi-Site Technical Reference, CIC client refers to either
Interaction Connect or Interaction Desktop.

Apply new releases

For instructions on applying new releases for Multi-Site, see the PureConnect Product Downloads page.
Note: The PureConnect Product Downloads page requires logon credentials for access. If you do not have your credentials,
contact your Genesys account representative.

4
Multi-Site Concepts
How Multi-Site Differs from Status Aggregator
The features of Multi-Site overlap somewhat with CIC Status Aggregator, an optional software module that aggregates user status
information across multiple CIC servers. However, the two products serve different purposes and are appropriate in different
situations:
Multi-Site provides user mobility, while Status Aggregator provides status information.
Multi-Site links together CIC servers that all have the same set of users, while Status Aggregator consolidates status
information from users on different CIC servers.
The following table compares the features of Multi-Site to the features of Status Aggregator.

Feature Status Aggregator Multi-Site

Organization-wide directory Yes Yes
Universal user extensions (users keep No Yes
their normal telephone extensions when
in remote offices)
Real-time status Yes Yes
Scalable. Each Status Aggregator Yes No
server efficiently handles status
information for over 50,000 users and
over five CIC servers.
Allows change of status No Yes
Server Status Aggregator server. Must RTM server. For 200 or fewer users, can be on any
be on stand-alone server. CIC server. For more than 200 users, must be on
stand-alone server.
Architecture SA Server + SA clients. Each RTM server + CIC clients. Each RTM server gets
Status Aggregator server gets information from the CIC servers that are in its
information from all connected "collective". Each CIC server must include the
CIC servers. EMSServer subsystem.
Fault tolerance Two or more Status Aggregator No fail-over backup between multiple RTM servers.
servers can be “fail-over”
backups for each other.
For more information about Status Aggregator, see the Status Aggregator Technical Reference.

5
Multi-Site Supports Roaming Users
Multi-Site routes interactions to an agent's current site, which is the CIC server where the agent is logged on. Users who float
between multiple CIC locations are called spanning users.
For example, suppose that a company has CIC servers at a main call center location and at two regional offices such as Boca
Raton, Florida, and Paris, France. If an employee visits Boca Raton, someone dialing that person's extension from any of the other
offices connects automatically to the phone that person is logged on to currently at the Boca Raton office. Multi-Site's distributed
dial plan considers the user's location and routes all calls for that user to that site. The caller does not need to know where the
agent is, or dial a long-distance number.

Each user has a Home Site

The CIC site where an administrator defined the user's account is the user's Home Site.

Traveling users log on at a Peer Site

When users travel to an alternate office location, they log on to the local CIC server, which is called a Peer Site. Peer Sites are CIC
servers in the collective that are remote from the Home Site. Administrators define Collectives and Peer Sites in Interaction
Administrator, using the Peer Sites container. For more information, see the Interaction Administrator documentation.

Multiple Peer Sites can participate in a collective. Each Peer Site has these attributes:
A unique site name
A unique site ID
A telephone number
A password

License considerations
Users cannot access software not licensed for the server onto which they are logged. When users log on to a CIC server other than
their home server (where their home station is configured) in a multi-site environment, the license conditions defined on the home
server apply to those users.

6
Connected CIC Servers Form a Collective
A Home Site and a Peer Site combination comprise a collective. A collective is a group of CIC servers that share resources. The
Home Site defines specific characteristics of the CIC server that is participating in the collective. Administrators define Home Sites
and Peer Sites in Interaction Administrator, using the Collective container.
A collective is a group of connected CIC servers that can share data. CIC servers in a collective are often geographically dispersed.
Administrators add each Peer Site to the collective using Interaction Administrator.
The Collective container supports multiple CIC servers working together. For example, CIC servers in Indianapolis, Indiana; Deerfield
Beach, Florida; and Aix, France; could all communicate with one another allowing a person in Indianapolis to see whether another
person in Deerfield is available and even whether that person is on the phone. Also, if a person visits Indianapolis, someone dialing
that person’s extension from any of the other sites connects automatically to the phone that person is logged on to currently in
Indianapolis. When adding new employees in one city, they appear automatically in the Company Directory around the world.
You can include CIC servers in a collective running different versions of CIC. For example, when you install CIC and Multi-Site, you
can establish communication with a Peer Site running a different version of CIC. Administrators configure each Peer Site using the
version of Multi-Site that matches the CIC version.

Collective Workgroup
A collective workgroup is like other workgroups except that it spans the resources of multiple CIC servers. A CIC administrator
creates the collective workgroup, and then adds members from the user community. Users from many sites can belong to this
workgroup. Users can call and connect to anyone in the workgroup, and monitor a user's status, logged on state, and phone state.

User information propagates automatically

When adding users to a collective workgroup, the information replicates to all servers in the collective. When adding or changing
attributes for users who belong to a collective workgroup, the information propagates automatically to all servers in the collective.
The new or updated information appears in the company-wide directory around the world. When deleting data, the system removes
all information from all servers in the collective, and from the company-wide directory.
The collective site and span workgroups can share users. User data replicates between collective sites, but not all users replicate.
Only users belonging to workgroups enabled as spanning workgroups replicate.

Company-wide directory, extensions, and agent status indicators

Users who are members of a collective workgroup can visit any site in the collective and log on. The location of the user distributes
immediately throughout the collective and each site is implicitly aware of the user's availability to take calls. The site that the user
is logged on to becomes the user's current site.
Employees in one location can access phone numbers and other information for employees in remote locations and vice versa. To
reach an employee who is working at a remote CIC site, it is not necessary to dial special digits. The system makes the necessary
long-distance call in accordance with the local server's dial plan. Employees who move from location to location have the same
communications access and extension number.
Multi-Site monitors the logged on status of agents in the collective workgroup. For example, it knows whether an agent is available,
in a meeting, at lunch, or on the phone. Multi-site shares this status information automatically between CIC servers at multiple
locations. This feature allows employees at one location to see the availability status of employees at other locations.

Multi-Site Messaging
Multi-Site provides a set of tools that gives handlers the ability to communicate with one another across multiple sites.
Administrators create Multi-Site messages using Interaction Designer and they carry through the system with the help of reliable
transport mechanism (RTM) technology. For more information, see Tools and Handlers.

7
Multi-Site RTM Client/Server Components
Multi-Site uses a technology called Reliable Transport Mechanism (RTM) to send messages and data between CIC servers. RTM is
a message queue service that is similar to Microsoft Message Queue (MSMQ). Unlike MSMQ, RTM is optimized to maximize the
performance of a CIC server. Multi-Site requires installing the following two software components:
Multi-Site RTM Client runs on each CIC Server. RTM client is middleware for messages between CIC and the RTM Server.
Multi-Site RTM Server is the hub through which all messages pass. You can install this COM server on a dedicated server or
on one CIC server in your organization. If the number of spanning users exceeds 200, Genesys recommends installing on a
dedicated server. Organizations with less than 200 spanning users can install RTM server on a CIC server. RTM Server cannot
reside on a CIC server that is part of a switchover pair.

Note: When you install your CIC server, the install program copies all the files required for Multi-Site into your server directory.
Those files include EMSE.exe (Multi-Site), RTMServerU.exe (message routing), RTM-related binary files, and Multi-Site (EMS)
handlers. However, it does not install the Multi-Site programs except for the message routing, which it sets up as a Windows
service. You need to install Multi-Site separately.

Message Flow Between CIC Sites

CIC passes Multi-Site messages to the Multi-Site RTM Client which in turn forwards the messages to the Multi-Site RTM Server.
The Multi-Site RTM Server distributes the messages to the appropriate recipients. If a connection breaks between the client and
server, messages deliver as soon as the communication link restores. The following figure shows a CIC environment with a stand-
alone Multi-Site RTM Server and four Multi-Site RTM Clients. Arrows represent messages. Connectivity is by means of the Internet
or TCP/IP-based network.

How Should a Floating User Sign at Another Location?

When users move from one CIC location to another location, their phone calls follow automatically when the users log on to the
current site. This action is possible because each CIC user has a unique user name and password, and CIC uses these identifiers to
detect when the user logs on and where the user is located physically. Following is the most efficient way for CIC users to log on to
another CIC location:
1. Log on to Windows using your network password. CIC uses a separate password than does Windows.
2. Start the CIC client, and then provide your CIC password.
3. Change your status to Available. All calls route to that site.

8
Multi-Site Installation Tasks
Multi-Site supports mixed versions of CIC in a collective. However, Administrators have to configure each Peer Site using the
version of Multi-Site that matches the CIC version. Accordingly, Genesys provides installation instructions for supported releases
of CIC. The components that administrators need to install are Multi-Site RTM Server and Multi-Site RTM Client.
Note: If you are upgrading an existing RTM Server, running the RTM install on an existing stand-alone RTM server does not
provide an upgrade option. Therefore, uninstall the existing RTM application and then install the new RTM Application.

Overview of Multi-Site installation tasks

To install and configure Multi-Site for your organization, do these installation tasks in order:
1. Decide where to install Multi-Site RTM Server. You can install Multi-Site RTM Server on a CIC server (along with Multi-Site RTM
Client), or on a dedicated server.
If either of the following apply, Multi-Site RTM Server requires dedicated hardware:
Multi-Site needs to accommodate more than 200 spanning users . The number of spanning users is the total
number of individuals who roam between servers, rather than the total number of CIC users in the overall organization
(collective).
All CIC servers in your organization use Switchover . Multi-Site RTM Server cannot reside on a CIC server that is part
of a switchover pair. For this reason, you must dedicate hardware even if you have less than 200 spanning users in your
organization.
You do not need dedicated hardware if:
The total number of spanning users is less than 200 and you are setting up a CIC server that is not part of a
switchover pair . When you don't use dedicated hardware, you can install Multi-Site RTM Server and Client together using
Setup Assistant.
2. To install Multi-Site RTM Server:
On dedicated hardware, Install Multi-Site Server on a Dedicated Computer.
On the CIC server, Install Multi-Site Server and Client on a CIC server. Multi-Site RTM Client always installs on a CIC server.
You cannot install it on stand-alone hardware.
Whenever you use dedicated hardware to host the RTM server process, install Multi-Site RTM Server before installing Multi-Site
RTM Client on CIC servers. When you don't use dedicated hardware, you can install Multi-Site RTM Server and Client together
when using Setup Assistant to configure a CIC Server.
3. Next, Install Multi-Site RTM Client on a CIC Peer Site in the collective.
4. Finally, do all tasks listed in Multi-Site Configuration and Administration Tasks.

9
Install Multi-Site Server on a Dedicated Computer
Install CIC Multi-Site RTM Server on a dedicated computer, after meeting the following minimum requirements.
Multi-Site for PureConnect 2018 R4 or later requires at least:
On the CIC server, Windows Server 2016 (64-bit) or Windows Server 2012 R2 (64-bit)
Windows 10 version 1511.
Microsoft .NET Framework 4.7 or later
PureConnect 2018 R4 or later.
Multi-Site for CIC 2015 R1 through 2018 R3 requires at least:
On the CIC server, Windows Server 2008 R2 SP1 (64-bit) or Windows Server 2012 R2 (64-bit)
Windows 8.x.
Microsoft .NET Framework 4.5.2 or later
CIC 2015 up to 2018 R3.
To install the Multi-Site RTM Server on a dedicated computer
1. If you have not done so already:
a. Download the CIC 2015 R1 or later .iso file from the PureConnect Product Downloads page.
b. Copy the .iso file to a file server (non-IC server) with a high-bandwidth connection to the servers on which you plan to run
the CIC 2015 R1 or later installs.
c. Mount the .iso file and share the contents to make them accessible to the servers on which you plan to run the CIC 2015
R1 or later installs.
2. Navigate to the \Installs\Off-ServerComponents [or \Installs\Integrations] directory on the file server.
3. Copy the RTMServer_20nnRx.msi file to the server on which you plan to run this install and double-click to start it. (In the
file name, n represents the final two digits of the release year and x represents a digit such as 1.)

Install Multi-Site Server and Client on a CIC server

When you don't require a dedicated Multi-Site RTM Server, install Multi-Site RTM Server and Client together on a CIC server that is
not part of a switchover pair. In this scenario, Multi-Site is an installation option available through Setup Assistant and supports
refresh and new installs.
To install Multi-Site Server and Client on a CIC server
1. Start Setup Assistant, click Options , and then click Proceed .
2. If Setup Assistant prompts you to confirm your CIC administrator account, type the administrator password and then click
Next .
3. Setup Assistant asks which option you want to install.

4. Select Multi-Site and then click Next . The Configure Multi-Site for this Server dialog box appears.
5. Click Multi-Site Server and Client and then click Next .

10
6. Type the name and password for the Multi-Site server and then click Next . The server name is an integer from 1 through 999.

Setup Assistant configures installation parameters, which can take a minute or more. When completed, the Commit Your
Choices dialog box appears.
7. Click Commit . Setup Assistant installs the Multi-Site Client and Server. When completed, the IC Setup Assistant has
finished! dialog box appears.
8. Click Finish to restart your computer and complete the installation.
11
You are ready to install the Multi-Site Client on every Peer Site in the collective.

Install Multi-Site RTM Client on a CIC Peer Site

Follow this procedure to install Multi-Site RTM Client on a CIC Peer Site in the collective. Install the Multi-Site Server on a dedicated
computer or another CIC server in the collective.
To install Multi-Site Client on a CIC server
1. Start Setup Assistant, click Options , and then click Proceed .
2. If Setup Assistant asks you to confirm your CIC administrator account, type the administrator password and then click Next .
Setup Assistant asks which option to install.

3. Select Multi-Site and then click Next . The Configure Multi-Site for this Server dialog box appears.
4. Select Multi-Site RTM Client Only and then click Next .

5. Type the name and password for the CIC server, the name of the Multi-Site Server, and then click Next . The server names are
integers from 1 through 999.

12
 Setup Assistant configures installation parameters, which can take a minute or more. When completed, the Commit Your
Choices dialog box appears.
6. Click Commit . Setup Assistant installs the Multi-Site Client and Server. When completed, the IC Setup Assistant has
finished! dialog box appears.
7. Click Finish to restart your computer and complete the installation.

13
Multi-Site Configuration and Administration Tasks
Configure Multi-Site to establish communication between sites by making the collective aware of the current site and its peer sites.
Once all of the Multi-Site components install successfully, enable a connection between the current site and Peer Sites. This action
makes the collective aware of the current site and its member users.
The following instructions assume the existence of two CIC sites configured with Multi-Site:
Understand Site Identifiers and Passwords
Configure the Current Site
Define Peer Sites
Grant Permissions to Users
Add Users to the Collective

Understand Site Identifiers and Passwords

A site requires a Site Identifier and password. The Site ID and password allow peer sites to connect with one another. For example,
suppose that there are two CIC sites, one in Boca Raton, Florida called Boca, and one in Indianapolis, Indiana called Indy. In this
scenario, configuring sites for Multi-Site is a two-part process:

Steps Performed by CIC Administrator in Boca Steps Performed by CIC Administrator in Indy
1. The Boca administrator defines the Boca home site by 1. The Indy administrator defines the Indy home site by
creating a unique site identifier and password. creating a unique site identifier and password.
2. The Boca administrator creates a peer site for Indy and 2. The Indy administrator creates a peer site for Boca and
uses the Indy site identifier and password to establish a uses the Boca site identifier and password to establish a
connection. connection.

Each CIC site defines other sites as peers, using the Site ID and Password of the other server. Every Peer Site has these attributes:
Unique site name
Unique site ID
Telephone number
Password
To define a Peer Site, the administrator must know the name of the Peer Site, its site ID number, password, and telephone number.
To coordinate this information, you can use the same password for all sites in a collective.

14
Configure the Current Site
Complete this task on each CIC server to ensure proper configuration of the Home Site.
To configure the current site
1. Start Interaction Administrator.
2. Click the Home Site container.
3. Do one of the following:
To edit a configuration, double-click the Configuration entry.
To create a configuration, click Insert .
4. In the Site Identifier box, type a unique site ID for the server.
5. Type and confirm the password for other sites to use to access this server for Multi-Site purposes.

Note: You can use the same password on all sites in a collective.
The following figure illustrates how a Boca administrator defines the Boca Home Site. The Indy CIC administrator, likewise,
assigns a unique site identifier and password. The key thing to understand is that the Site IDs must be unique; however, you
can use the same password.

6. Leave the Note ID Dial String Digits box blank, unless the servers connect by a tie line. It defines digit values for the system
to use to identify a call as a Multi-Site call when sending a multi-site call to a peer by means of an established tie-line
connection.
When using tie lines, this box contains a default value of *90 to identify a call as a multi-site call when sending a multi-site
call to a peer. This value is configurable for sites in which the default value conflicts with existing area codes. If *90
conflicts with an area code, you can assign different digits, as long as you use the same digits for all Multi-Site RTM
Servers. If you change the default value, you must change the value to match in all sites of the collective.
7. Click OK .

Define Peer Sites

Each CIC server in the collective represents a specific call center location called a Peer Site. Each peer site has a unique name, a
site identifier, a telephone number, and a password. The next step is to define peer sites, so that the current site can communicate
15
with other servers in the collective. Each CIC administrator performs this procedure on each CIC server that they maintain. The
administrators must know the name, Site ID, telephone number, and password of peer sites before starting this procedure.
To define Peer Sites
1. Start Interaction Administrator.
2. Click the Peer Sites container.
3. Click the Insert key. The Entry Name dialog box appears.
In our example scenario, the Boca administrator creates a Peer Site for Indy and the Indy administrator creates a Peer Site
for Boca.

4. Type the name of the peer site and then click OK . The Peer Site Configuration dialog box appears.
Continuing with our example, the Boca administrator defines Indy as a Peer Site using Indy's Site ID, phone number, and
password. The Indy administrator defines Boca as a Peer Site using Boca's Site ID, phone number, and password.

Site Identifier: Unique number that identifies the CIC site to add to the collective as a Peer Site.
Phone Number: Phone number of the CIC site to add to the collective as a Peer Site. The system uses the phone number
to route a call to a user when the user is logged on to that Peer Site.
Password: Password of the CIC site to add to the collective as a Peer Site. Passwords are case-sensitive.
Use Note ID Dial String: If selected, indicates to CIC that when a Tie Line handles a Multi-Site call, use Tie Line
optimization to handle the call efficiently. Peer Sites connect by Tie Lines and PSTN. When establishing a Tie Line between
two sites, CIC uses this feature to process Multi-Site calls more efficiently.
5. Complete the information and then click Check Site to validate the information provided. If the system establishes a
connection, a message appears indicating that the connection was successful. If the system cannot log on to the Peer Site, a
message displays indicating that the information is incorrect. Correct the information and then click Check Site.
6. When the check is successful, click OK .

16
 7. In the Peer Site Configuration dialog box, click Synchronize . A message appears indicating that the system sent a
message requesting synchronization to occur.
8. Click OK . It can take several minutes for synchronization to complete. The Peer Site Configuration dialog box appears.
9. In the Peer Site Configuration dialog box, click OK . The completion of this process establishes a connection between the
current CIC site and Peer Site and allows you to view the status of users who belong to that peer site.
10. To confirm that synchronization succeeded, click the Users container. The users from the site you just established connection
with appear in Interaction Administrator's list view. Ensure that these users are members of a workgroup that you enabled to
span all sites. See Add Users to the Collective.

Configure a Peer Site to Route Calls to Another Peer Site

There are three main steps in configuring a Peer Site to route calls to another Peer Site in a collective:
1. Create a Tie Line. You do this step outside CIC.
2. Configure Dial Plan to route the call to the number associated to the Peer Site.
3. Use the Default Profile and the extended menu of 9 > 0 for Multi-Site routed calls. Genesys recommends using a dedicated
Attendant Profile at each site to catch the EMS Calls.

Configuration in Interaction Administrator and DCOM

You must configure Multi-Site correctly in Interaction Administrator and DCOM. Incorrect configuration is a common cause of
problems in using Multi-Site.

Interaction Administrator configuration

Route Calls to a Peer Site

In Interaction Administrator, go to Collective | Peer Sites and obtain the phone number of the Peer Site.
If the Peer Site is not in the Collective | Peer Sites container, define the site first.
In Interaction Administrator, set the following values.

17
 Home Site
Site Identifier Unique number in your Multi-Site "cluster."
Password CIC administrator account password for this CIC server.
Note ID Dial String Digits Leave as *90. Don't ever change it.
Peer Site
Name Name of each server that you want local users to span.
Site Identifier Number that identifies the Peer CIC server. You set this ID in the Peer's Home Site container.
Phone Number Phone number to reach the Peer Site. You can use any number of digits, as long as the dial plan
can "pick it up."
Password Peer CIC server password. You set this password in the Peer's Home Site container.
Use Note ID Dial String Only select this check box if there is a direct ISDN Tie Line between sites. You can clear this
check box for any environment and it works correctly.
SIP Line
Create one SIP line for each Peer Site.
Proxy IP address of corresponding CIC server.
Access Select the Denied Access check box.
Add the IP address of the corresponding CIC server.
Line Group Create one line group for each Peer Site.
Use as Dial Group Select this check box.
Members Add the corresponding CIC server.
Dial Plan
Create one dial plan for each Peer Site.
Input Pattern Phone number that you set in the corresponding Peer Site container.
Classification Local.
Dial Group Select the corresponding Line Group.
Classification Local.
Dial String [Corresponding Phone Number]@SERVERNAME
Simulate Peer Site phone numbers to confirm that the call routes to the correct CIC server.
Workgroup
Create a workgroup named Multisite_SERVERNAME where SERVERNAME is the name of
your RTM server.
Add spanning users to the workgroup.
Workgroup Spans Sites (on the Select this check box.
Configuration tab)
Attendant

Note: Genesys recommends using a dedicated Attendant Profile at each site to catch the EMS Calls.
Default Schedule The default profile and its schedule handle Multi-Site calls correctly.
Add a greeting.
Repetition Set this value to 3 so that the greeting repeats three times.
Wait Set this value to 15 so that there are 15 seconds between repetitions.
Listen for Extension Dialing Clear this check box.
9 - Extended Menu Do not set as the default action.
0 - Multi-Site Do not set as the default action.
Subroutine EMSSystemIVRCustomizations

DCOM configuration
Configure the RTM server and Peer Sites.
To configure the RTM Server
1. On the Windows Start menu, click Run , type DCOMCNFG, and then click OK . The Component Services window
appears.
18
2. Click Component Services > Computers > My Computer > DCOM Config .

3. Right-click RTMServer and then click Properties .

4. On the Location tab, select the Run Application on This Computer check box.
5. Close the dialog box.
To configure the Peer Site CIC servers
1. On the Windows Start menu, click Run , type DCOMCNFG, and then click OK . The Component Services window
appears.
2. Click Component Services > Computers > My Computer > DCOM Config .
3. Right-click RTMServer and then click Properties .
4. On the Location tab, select the Run Application on The Following Computer check box.
5. Type RTM SERVERNAME, where SERVERNAME is the name of the RTM server.
6. Close the dialog box.

19
Guidelines for User Extensions
Multi-Site does not allow you to place calls to the station extensions of a peer server. You can only call user extensions. For
example, Server A and Server B are peers. From a station or CIC client connected to Server A, you cannot call a station on Server B.
You can call a user on Server B, either by dialing that user's extension, or by clicking that user's name in the CIC client.

Similar user extensions on different peer sites when adding servers to a collective
It is always important to plan ahead when creating user extensions in Interaction Administrator. Base this planning on the growth of
the current site and continued growth of other sites or other CIC systems. Multi-Site can connect multiple CIC systems into a
collective and with the automatic propagation of user information, replicate user information throughout the collective. The reason
this planning is so important is the issue of duplicating user extensions.
A user who spans sites (a spanner) on a CIC server that is part of a collective of CIC servers cannot have the same user extension
as another user that spans sites (a spanner) on another CIC server in that collective. In other words, there is an issue if User A on
Server 1 who is part of a workgroup that spans sites has an extension of 8001 and User B who is part of a workgroup that spans
sites on Server 2 has an extension of 8001. They replicate through the collective with this extension but have a problem getting
calls and other services. This issue does not affect users who are not spanners, they are unique to their specific servers.

What happens if I have two sites and they do have similar user extensions?
Use extensive planning when changing user extensions. If you add a user to a workgroup that spans sites, assign a unique user
extension. Following are a couple of examples:
Change the user extension all together.
For example, User A on Server 1 has an extension of 8001, change it to 8801.
Add a digit to the beginning of the user's extension.
For example, User A on Server 1 has an extension of 8001, change it to 18001 {for Server 1, User A extension 8001; User B on
Server 2 has an extension of 8001, change it to 28001 {for Server 2, User B extension 8001.

20
Grant Permissions to Users
You can define a set of permissions for users who log on to your site. For example, when a user from the Indy site logs on to the
Boca site, the Boca system knows what rights the Indy user has. You can allow users to publish and manage handlers but not have
master administrator permissions enjoyed at their home site. You can turn on or off user permissions at any time.
To grant permissions to users
1. In Interaction Administrator, click Peer Site .
2. Open the Peer Site for which to set user rights. The Peer Site Configuration dialog box appears.
3. Click the Trusted Access tab. Trusted Access refers to the ability a user has when logged on to a Peer Site.
For example, a user could have permissions to publish and manage handlers, but not have master administrator permissions
enjoyed at the home site level.

Publish Handlers: If selected, allows users who are logged on to the Peer Site to publish new or updated handlers on the
CIC server. This option applies only to users who have the Interaction Designer program and have authorization to update
production handlers or create new handlers on the CIC telephony server. If cleared, users who attempt to publish handlers
from Interaction Designer receive an appropriate error message.
Manage Handlers: If selected, allows users who are logged on to the Peer Site to add or remove handlers published to
the CIC server. If cleared, users who attempt to manage handlers from Interaction Designer receive an appropriate error
message.
Master Administrator: If selected, allows users who are logged on to the Peer Site to view and change everything in
Interaction Administrator and assign or remove all levels of administrator rights for any other CIC account, including others
with master administrator permissions. All property pages (especially Admin Access and Access Control ) for the
Default User , User , and Workgroup containers are visible to master administrators. Other accounts without master
administrator permissions cannot do these actions.
4. Select the permissions to allow and then click OK .

Add Users to the Collective

To add users who are members of a workgroup to the collective, enable the workgroup to span sites. Spanning allows sharing and
replicating of member users between sites. The following steps assume that the workgroup exists.
To add users to the collective
1. In Interaction Administrator, click Workgroup .
2. From the list view, open the workgroup to allow to span multiple sites.
3. On the Configuration tab, select Workgroup Spans Sites and then click OK .
4. Click the Members tab.
5. Under Available Users , select the users you want to add to the spanning workgroup and then click Add . The users appear
under Currently Selected Users .
6. Click OK . The completion of this process adds members of the workgroup to all connected Peer Sites. Interaction
Administrator displays data and the status of members of the workgroup in its list view when you select the Users container.
Note: Workgroup memberships span and replicate across multiple sites, but workgroup queue information don't.

21
RTM Server Command Line Parameters
You can start RTMServerU.exe using optional command-line parameters that register it as a local service or as a remote
connection. These modes of operation have different DCOM and Service settings, so Genesys created command-line parameters to
make it easier for PureConnect Customer Care or a setup program to configure or reconfigure Multi-Site.

Install RTMServer as a local service:

/Service [/Username={username}] [/Password={password}]
This option installs RTMServer as a service in the SCM and registers it for DCOM. Optionally, you can provide a user name and
password, but it fails to install if it is not a valid username/password combination.
Example: RTMServerU.exe /Service /Username=UserAccount /Password=Password

Install RTMServer as a remote connection:

Installing RTMServer as a remote connection renames or removes the LocalServer32 entries applicable only to the service.
Example: RTMServerU.exe /RemoteServer=RemoteServerName

Register RTMServer as a local DCOM Server:

Example: RTMServerU.exe /RegServer
Registers it as a DCOM server for running on the local computer

Register RTMServer as a remote DCOM object:

/RegClient={machine}
Registers it as a remote DCOM object for running on {machine}
Example: RTMServerU.exe /RegClient=machine

Uninstall RTMServer (either mode):

/UnRegServer
Unregisters it as a DCOM client/server and removes it from the SCM. Each registration option undoes the others, so it is not
necessary to run /UnRegServer between each use.
Example: RTMServerU.exe /UnRegServer

22
Change a Site ID
Note: Changing the Site ID can cause problems. If you change the Site ID, synchronization with Peer Sites halts until you use IC
System Manager to restart EMS (Multi-Site) on the servers where you changed the Site ID. You also have to delete all users
with the old Site ID from every replicated server, recreate them on the home server, and then resync.
To change a Site ID to give a CIC server a unique ID
1. In Interaction Administrator, click Home Site and then double-click Configuration . The Site Configuration page appears.

2. In the Site Identifier box, type a number that uniquely identifies this CIC site and then click OK .
A home site with a unique ID can be part of a collective.

23
Tools and Handlers
Every CIC server has an event-handling engine called an Interaction Processor (IP). As part of its responsibility, the IP engine
invokes handlers including those handlers that communicate with one another across multiple sites. You create Multi-Site
messages in handlers using a set of Multi-Site and IpNotes tools available in Interaction Designer.
Using the Multi-Site messaging tools, you can construct an arbitrary message format within a handler and receive that message in
another handler on a remote server. The order in which you add the various elements to the message determines the format of the
message. On the receiving end, the handler must read the elements from the message in the correct order. The handler checks the
element type when it reads it, so an attempt to read the wrong element type results in an error.
When a message is ready to send, the sender specifies a destination site ID; and the object and event values to use to start the
notification on the receiving server.
Messages send asynchronously, requiring no response, or synchronously, where the sending tool waits a specified amount of time
for the return of a response message. The handler reads the response message in the exact same way as the original message by
using the get tools in the same order as the sender used the put tools.
To assist you with understanding how these tools work, Genesys provides three sample message handlers Along with these
samples are detailed descriptions of the parameters associated to each tool. These samples provide guidance on how to set the
inputs and what to do with the outputs of each tool.
For more information, see:
Multi-Site Tools
IpNotes Tools
Send a Message That Does Not Require a Response (Handler1)
Send a Message That Requires a Response (Handler2)
Receive a Message (Handler3)

Multi-Site Tools
Following are the available Multi-Site tools (and one initiator). The data types that you can add to and retrieved from a message are
any of the Interaction Designer (ID) defined types Integer, String, and IpNotes. For more information about IpNotes, see IpNotes
Tools.

Multi-Site Create Message

Creates a message in the system and then provides a handle to it as an output. The handle is an input to all other tools that operate
on the message. An asterisk (*) indicates an external data type.

Parameter Process Data Type Description

Message Handle Output Message Handle* Valid handle to the newly created message.
Success Exit Not applicable Path taken when the message creates successfully.
Failure Exit Not applicable Path taken when message creation fails.

Multi-Site Get Integer

Reads a data element from the message that the supplied handle specified. An asterisk (*) indicates an external data type.

24
 Parameter Process Data Type Description
Message Input Message Valid handle to the message.
Handle Handle*
Integer Value Output Integer Value read from the message. The output doesn't contain a valid value unless taking
the success exit path.
Success Exit Not Path taken when reading the value from the message is successful.
applicable
Failure Exit Not Path taken when the operation fails or when the element read from the message is not
applicable the correct type.

Multi-Site Get Note

Reads an IpNote from the message that the supplied handle specified. An asterisk (*) indicates an external data type.

Parameter Process Data Description

Type
Message Input Messag Valid handle to a message.
Handle e
Handle*
Note Name Input String Name of the note to read from the message. For more information about how to create and
manage notes, see IpNotes Tools.
Success Exit Not Path taken when reading the note from the message is successful.
applicab
le
Failure Exit Not Path taken when the operation fails or when the element read from the message is not the
applicab correct type.
le
Note Name Exit Not Path taken when reading a note from the message and its name does not match the one
Mismatch applicab supplied. Unlike other message elements, the name of a note is integral to the note data.
le
The system requires a note name so that it can better check for an error in retrieving notes
and guaranteeing that a sent note element has the same name on multiple servers.

Multi-Site Get String

Reads a data element from the message that the supplied handle specified. An asterisk (*) indicates an external data type.

Parameter Process Data Type Description

Message Input Message Valid handle to a message.
Handle Handle*
String Value Output String Value read from the message. The output doesn't contain a valid value unless taking
the success exit path.
Success Exit Not Path taken when the value read from the message is successful.
applicable
Failure Exit Not The path taken when the operation fails or when the element read from the message is
applicable not the correct type.

Multi-Site Message Received

25
Starts the handler that processes a specific message. This initiator allows the handler author to type a string value for both the
Event ID and Object ID. When receiving a notification with matching Event and Object IDs, it triggers the initiator. The same initiator
receives messages sent as events and requests. In the latter case, certain outputs that contain return information for a response
contain valid values. If the message sends as an event, those outputs are zero.

Parameter Process Data Description

Type
Label Input Strin Name for the initiator.
g
Object ID Input Strin String value that matches the Object ID you set in Multi-Site Send Event or Multi-Site Send
g Request .
Notification Input Strin String value that matches the Event ID you set in Multi-Site Send Event or Multi-Site Send
Event g Request .
Message Output Mes Valid message to the incoming message from which the data elements are read.
Handle sage
Hand
le
Response Output Integ Unique identifier for this message when the message sends synchronously. Otherwise, this value
Correlation er is zero. If the message requires a response, the value of the variable contains a non-zero value.
ID This value must pass unchanged to Multi-Site Send Response .
Response Output Strin Value that identifies the source of the request when the message sends synchronously.
Destination g Otherwise, the value is an empty string. This value must pass unchanged to Multi-Site Send
ID Response .

Multi-Site Put Integer

Adds an integer value to the message that the supplied handle specified. An asterisk (*) indicates an external data type.

Parameter Process Data Type Description

Message Handle Input Message Handle* Valid handle to a message.
Integer Value Input Integer Value to add to the message.
Success Exit Not applicable Path taken when the value adds to the message successfully.
Failure Exit Not applicable Path taken when the operation fails.

Multi-Site Put Note

Adds an entire IpNote element to a message that the supplied handle specified. An asterisk (*) indicates an external data type.

26
 Parameter Process Data Type Description
Note Name Input String Name of an existing note to add to the message. For more information about how to
create and manage notes, see IpNotes Tools.
Message Input Message Valid handle to a message.
Handle Handle*
Success Exit Not Path taken when the value adds to the message successfully.
applicable
Failure Exit Not Path taken when the operation fails.
applicable
Unknown Exit Not Path taken when the name of the note supplied does not match that of an existing note.
Note Name applicable

Multi-Site Put String

Adds a text string to the message that the supplied handle specified. An asterisk (*) indicates an external data type.
Parameter Process Data Type Description
Message Handle Input Message Handle* Valid handle to a message.
Value Input String Value to add to the message.
Success Exit Not applicable Path taken when the value adds to the message successfully.
Failure Exit Not applicable Path taken when the operation fails.

Multi-Site Send Event

Sends the message that the supplied handle specified to another handler on a remote server or to multiple servers. The Event and
Object IDs specified determine which handler the message triggers. Handler execution continues as soon as the message sends
and expects no response. An asterisk (*) indicates an external data type.

27
 Parameter Process Data Description
Type
Message Input Mess Valid handle to a message.
Handle age
Handl
e*
Destination Input String Site ID as configured at each site in Interaction Administrator. Although the value is a number,
the input must be a string. You can use an asterisk (*) to broadcast a message.
Object ID Input String Value to use for the Object ID to include with the message notification to the receiving handler.
To trigger a handler, this value must match the value specified in the Object ID input on the
Multi-Site Message Received initiator.
Event ID Input String Value to use for the event ID to include with the message notification to the receiving handler.
To trigger a handler, this value must match the value specified in the Notification Event input
on the Multi-Site Message Received initiator.
Success Exit Not Path taken when the value sends successfully.
applic
able Note: Although the handler sends the message successfully, this value does not mean that
the intended handler received it.

Failure Exit Not Path taken when the operation fails.

applic
able

Multi-Site Send Request

Sends the message that the supplied handle specified to another handler on a remote server or to multiple servers. The Event and
Object IDs specified determine which handler the message triggers. Handler execution continues only after receiving a response or
the timeout period expires. An asterisk (*) indicates an external data type.

28
 Parameter Process Data Description
Type
Message Input Mess Valid handle to a message.
Handle age
Hand
le*
Destination Input Strin Site ID as configured at each site in Interaction Administrator. Although the value is a number,
g the input must be a string. You can only specify one destination for a request.
Object ID Input Strin Value to use for the Object ID to include with the incoming message notification on the receiving
g server. To trigger a handler, this value must match the value specified in the Object ID input on
the Multi-Site Message Received initiator.
Event ID Input Strin Value to use for the event ID to include with the incoming message notification on the receiving
g server. To trigger a handler, this value must match the value specified in the Notification Event
input on the Multi-Site Message Received initiator.
Timeout Input Input Number of milliseconds to wait for a response to the message. A value of zero means to wait
forever.
Response Output Mess Handle to the response message when receiving one in time. This output only contains a valid
Message age value when taking the success path.
Handle Hand
le
Success Exit Not Path taken when sending the message successfully and receiving a response within the time
appli specified.
cable
Failure Exit Not Path taken when the operation fails.
appli
cable
Timeout Exit Not Path taken when the timeout period expires before receiving a response message.
appli
cable

Multi-Site Send Response

Sends a response message that the supplied handle specified back to the source of the original message. By using the Response
Correlation ID obtained from the Multi-Site Message Received initiator, the response message routes automatically to the correct
handler that is waiting for it. An asterisk (*) indicates an external data type.

29
Parameter Process Data Description
Type
Message Input Mess Valid handle to a message.
Handle age
Handl
e*
Response Input Intege Value used to route the response back to the sender of the original message. The server
Correlation r assigns this value and can only obtain it from the Response Correlation ID output on the
ID Multi-Site Message Received initiator.
Response Input Intege Value used to route the response back to the sender of the original message. The server
Destination r assigns this value and can only obtain it from the Response Destination ID output on the
ID Multi-Site Message Received initiator.
Success Exit Not Path taken when the response adds to the message successfully.
applic
able Note: Although the handler sends the response successfully, this value does not mean that
the intended handler received it.

Failure Exit Not Path taken when the operation fails.

applic
able

30
IpNotes Tools
The IpNotes tool set allows the handler author to store and retrieve named entities consisting of an arbitrary number of named
attributes of any of the ID-defined types Integer, String, or Date/Time. Each attribute is a list of values of a particular type. An IpNote
is available to all handlers on a server and is accessible by name. You can remove IpNotes explicitly, or they self-destruct after a
time interval specified at creation. For more information about configuring the parameters of each tool, see the Interaction
Designer Help.

Tool Description
Create Creates a note that is accessible by name from any handler on the local server. The author can specify the number of
Note minutes for the note to live before removing itself. Otherwise, the note exists until explicitly removed. Creating the
note does not put any information into it. You add attributes using the update tools.
Get Notes Retrieves the attribute of the specified type with the name specified on the input. The output is a list of the correct
Attribute type. The list can be empty. You can handle the list using the list tools. If the handler cannot find an attribute with the
Date/Time supplied name or one exists but it is the wrong type, the handler takes the appropriate error exit paths.
Get Notes Retrieves the attribute of the specified type with the name specified on the input. The output is a list of the correct
Attribute type. The list can be empty. You can handle the list using the list tools. If the handler cannot find an attribute with the
Integer supplied name or one exists but it is the wrong type, the handler takes the appropriate error exit paths.
Get Notes Retrieves the attribute of the specified type with the name specified on the input. The output is a list of the correct
Attribute type. The list can be empty. You can handle the list using the list tools. If the handler cannot find an attribute with the
String supplied name or one exists but it is the wrong type, the handler takes the appropriate error exit paths.
Remove Removes a note created previously. If a handler removes a note, it ceases to exist for any handler that tries to
Note retrieve it after that.
Update Adds, replaces, or removes values from an IpNotes attribute. Provide the name of the attribute along with a list of the
Notes proper type containing the values to add or remove. You can specify one of three operations with this tool: append,
Attribute replace, or remove. If the choice is append or remove, the attribute must exist already. Specifying replace causes
Date/Time replacement of the entire contents of the attribute. You can also use this option for the initial update.
Update Adds, replaces, or removes values from an IpNotes attribute. Provide the name of the attribute along with a list of the
Notes proper type containing the values to add or remove. You can specify one of three operations with this tool: append,
Attribute replace, or remove. If the choice is append or remove, the attribute must exist already. Specifying replace causes
Integer replacement of the entire contents of the attribute. You can also use this option for the initial update.
Update Adds, replaces, or removes values from an IpNotes attribute. Provide the name of the attribute along with a list of the
Notes proper type containing the values to be add or remove. You can specify one of three operations with this tool:
Attribute append, replace, or remove. If the choice is append or remove, the attribute must exist already. Specifying replace
String causes replacement of the entire contents of the attribute. You can also use this option for the initial update.

31
Send a Message That Does Not Require a Response (Handler1)
You can create a handler to send a message to a single server or all servers in a collective. The message does not require a
response.

Handler1 example
The following example shows how to create a message that results in a message handler that you can supply to other Multi-Site
message tools. The message includes a text string and integer, and the message sends as an event.
1. In Interaction Designer, click the Multi-Site tab and then add the following tools to a blank handler page:
Multi-Site Create Message
Multi-Site Put String
Multi-Site Put Integer
Multi-Site Send Event
2. Set the appropriate parameters for each tool. For more information, see Multi-Site Tools.
3. Connect each tool so that the handler looks similar to the following:

4. Name and save the new handler.

32
Send a Message That Requires a Response (Handler2)
You can create a handler that sends a message to a specific server and then waits a specified time for a response.

Handler2 example
The following example shows how to create a message in much the way as in Handler1; however, you only put an integer into the
message. The message structure is fundamentally different from Handler1 and the receiving handler must recognize the difference
in the two messages and unpack them accordingly. For more information about the receiving handler, see Receive a Message
(Handler3).
1. In Interaction Designer, click the Multi-Site tab, and then add following tools to a blank handler page:
Multi-Site Create Message
Multi-Site Put Integer
Multi-Site Send Request
Multi-Site Get Integer
2. Set the appropriate properties for each tool. For more information, see Multi-Site Tools.
3. Connect the tools so that the handler looks similar to the following:

4. Name and save the handler.

33
Receive a Message (Handler3)
You can create a handler that can receive a message and then decide whether the message is a request that requires a response or
an event that doesn't. The receiving handler bases the decision on the correlation ID that the initiator provides. If the correlation ID
is equal to zero, the message is an event. If the correlation ID is not equal to zero, the message is a request.

Handler3 example
Handler3 example assumes that the message came from either Handler1 or Handler2. Start Interaction Designer and follow these
steps:
1. From the File menu, click Change Initiator . The Interaction Handler Initiators window appears.
2. Select Multi-Site Message Received and then click OK . Interaction Designer adds Multi-Site Message Received to a blank
handler page.
3. Click the Multi-Site tab and then add the following tools to the handler page:
Multi-Site Get String
Multi-Site Get Integer (2)
Multi-Site Create Message
Multi-Site Put Integer
Multi-Site Send Response
4. Set the appropriate parameters for each tool. For more information, see Multi-Site Tools.
5. On the Basic tab, add the Condition tool and then set the Boolean so that zero takes the True exit path.
6. Connect the tools so that the handler looks similar to the following:

7. Name and save the handler.

34
Testing and Troubleshooting
This information assists you in ensuring that your Multi-Site installation is performing properly.

Verify site connection

In Interaction Administrator, click Check Site at each site to verify connectivity to each of its Peer Sites.

Test workgroup member

Test a member of a workgroup that spans sites.
Add a user to a spanning workgroup and verify that the user replicates to other sites.
Remove a user from all spanning workgroups and verify deletion of the user from other sites.
Change the status of a spanning user and verify that all sites display the correct status.
Exit/Enter the CIC client for a spanning user and verify that all sites show the user as Not logged in/Logged in.
Place a call as a spanning user and verify that all sites show the user as On the phone .
Place a call from ServerA to UserA by dialing the user's extension (or directly from the CIC client).
As UserA (logged on ServerA), place a call from ServerA to UserB (logged on ServerB) by dialing the user's extension (or directly
from the CIC client). Verify that the call goes straight to the user and skips the IVR on ServerB. Verify that UserB's CIC client
shows the call as originating from UserA.

Multi-Site RTM Servers cannot communicate

Some versions of the CIC Multi-Site RTM Server install set the Services identity to Local System Account and the DCOM identity
to The System Account . As a result, Multi-Site RTM Servers are unable to communicate with each other. The workaround is to
start the Services Control Panel applet.
To start the Services Control Panel applet
1. Right-click the RTM Server process and click Properties .
2. Click This Account to use the identity of the logged on domain user.
3. Restart RTM Server to put changes into effect.

RTM message not transferring

For the following issues, click Check Site in Interaction Administrator to ensure that RTM messages are transferring between the
computers:
Cannot see caller name and extension numbers
Get the default IVR option when calling across servers
Status not updating
Receive voice mail when in available status
Telephone Handset playback issues
Verify the following:
User is a member in a spanning workgroup
Sites are in sync regarding the user's current status
User is not on the phone

File-based Mail Connector limitation

Multi-Site is incompatible with a combination of FBMC-only (File-based Mail Connector) sites and other sites that use mail
connectors (for example, Exchange and Notes).

Multi-Site fails
35
If you have Multi-Site RTM server and RTM client installed on one CIC server, and you install Microsoft Visual C++ 6.0 with Service
Pack 2, it can cause Multi-Site to fail.
When installing the Service Pack 2 software, the installation program asks whether you want to replace existing files with newer
version files. Click No . If you click Yes , the program overwrites the following files:
olepro32.dll
oleaut32.dll
asycfilt.dll
stdole2.tlb
Overwriting these files causes Multi-Site to fail and requires that you reinstall Multi-Site.

CIC system cannot find a name prompt

If users are receiving a message that the CIC system cannot find a name prompt, you might have to move the location of the
resources directory.
Multi-Site replicates all prompt locations exactly as they are on the home site. For Multi-Site RTM Client to find prompts on other
servers, all your servers need to have their resources directory installed on the same letter drive.

CIC Server or RTM Server access denied

Only do these steps if you configured the computes as indicated in Multi-Site Configuration and Administration Tasks and you are
still experiencing issues. If you see event log errors on either the CIC server or RTM Server about access being denied, do the
following:
1. Run dcomcnfg.exe on the RTM Server computer.
2. Scroll down until you see RTMServer .
3. Click it and then click Properties .
4. Click the Security tab.
5. Click Use custom access permissions .
6. Click Edit , and configure it so that Everyone has Allow Access .
7. Select the Use custom launch permission.
8. Click Edit , and configure it so that only System has Allow Launch .
9. Select Use default configuration permissions .

Exception thrown error

If you see errors in the trace log that resemble Exception thrown during GetRTMMessage HR=, the COM registration is
corrupt.
Do one of the following, depending on which server you are seeing the error:
To fix the issue on the CIC server with RTM Server installed, do the following
a. Open a Command Prompt window and go to the \i3\ic\server directory.
b. Type in the command window rtmserveru –Service. Only the command prompt appears.
c. Type regsvr32 rtmserverps. A window appears, stating DllRegisterServer in rtmserverps.dll succeeded.
d. Run dcomcnfg.exe and reconfigure the RTMServer settings.
e. Restart your computer.
To fix the issue on the CIC server without RTM Server installed, do the following:
a. Open a Command Prompt window and go to the \i3\ic\server directory.
b. Type in the command window rtmserveru –RegServer. Only the command prompt appears.
c. Type regsvr32 rtmserverps . A window appears, stating DllRegisterServer in rtmserverps.dll succeeded.
d. Run dcomcnfg.exe and reconfigure the RTMServer settings.
e. Restart your computer.

36
Change Log
The following table lists the changes to the CIC Multi-Site Technical Reference since its initial release.

Change Date
31-October-2011 Initial release of this document for IC 4.0.
12-January-2012 Updated and tweaked install-related material and a few other places.
Added two new sections in Chapter 3 to provide more specific guidance about configuring Interaction
Administrator and DCOM for Multi-Site.
Updated copyright and platform statement pages.

19-November-2013 Finalized example of configuring Multi-Site in IA for routing to peer sites.

Updated copyright and made a few minor tweaks.

24-September-2014 Updated documentation to reflect changes required in the transition from version 4.0 SU# to CIC 2015 R1,
such as updates to product version numbers, system requirements, installation procedures, references to
Interactive Intelligence Product Information site URLs, and copyright and trademark information.
11-August-2015 Updated documentation to reflect the addition of two CIC client applications, Interaction Desktop and
Interaction Connect.
14-January-2016 Updated document formatting and copyright statements.
07-April-2017 Updated copyright statement and removed reference to Interaction Client Web Edition.
03-May-2017 Updated .NET Framework 4.0 to 4.5.2 or later.
21-September-2017 Rebranded to Genesys.
19-March-2018 Updated document format.
15-June-2018 Added Microsoft .NET Framework 4.7 requirement for PureConnect 2018 R4 or later.
07-May-2019 Reorganized the content only, which included combining some topics and deleting others that just had an
introductory sentence such as, "In this section...".
24-April-2020 Update or remove links to "my.inin.com" as appropriate.

37