Configure external accessibility
Introduction
There are many paths to wander when it comes to opening up a part to the world wide web. This is a brief description on the best practice on how you could open up the Anywhere365 WebChat to the outside world, without having the worry that all call detail data will be publicly accessible as well.
Configure external accessibility
The Anywhere365 WebChat consists out of two web services, which are:
-
WebChat - This the front-end which the customer can use to initiate a chat conversation with the employee.
-
ChatHub - This is the back-end and takes care of the communication with the UCC A Unified Contact Center, or UCC, is a queue of interactions (voice, email, IM, etc.) that are handled by Agents. Each UCC has its own settings, IVR menus and Agents. Agents can belong to one or several UCCs and can have multiple skills (competencies). A UCC can be visualized as a contact center “micro service”. Customers can utilize one UCC (e.g. a global helpdesk), a few UCC’s (e.g. for each department or regional office) or hundreds of UCC’s (e.g. for each bed at a hospital). They are interconnected and can all be managed from one central location. service (e.g. for presence information)
The best practice teaches us that there are two ways to implement these web services.
Method 1. (Default) Use a reverse proxy
The web services are installed on the Anywhere365 Application Server and made available to the outside world by using reverse proxy (similar to the dial-in web page of Skype for Business).
This needs to be done for both the WebChat and the ChatHub url.
Method 2. Host both web services on a web server in a DMZ.
Prerequisites
Before you start, this method only works in the following scenarios:
MACHINE B |
|||
MACHINE A |
FOREST A |
FOREST B |
WORKGROUP |
FOREST A |
WORKS |
DOES NOT WORK |
WORKS |
FOREST B |
DOES NOT WORK |
WORKS |
WORKS |
WORKGROUP |
WORKS |
WORKS |
WORKS |
Also Webchat needs to be already installed on the Application server, Learn More
By hosting the web services on a web server in a DMZ the UCC application server is not directly accessible from outside the network.
The communication of the ChatHub and UCC takes place via the so called MSMQ’s (Message Queues). This is a Windows (service) feature which is able to exchange encrypted messages. The advantage of this method is that it also allows ‘remote’ control and so is able to read and write from and to these MSMQ’s. This is even possible from each server. In this particular case we will use this method to allow communication from the web server (in DMZ) to the UCC server (inner network).
There is not much needed in order to get this working. Both servers need to have the Windows Message Queue feature installed. The following firewall ports should be opened (from webserver to the UCC server and vice versa):
-
TCP: 1801
-
RPC: 135, 2101, 2103, 2105
-
UDP: 3527, 1801
After installing the WebChat and ChatHub web service on the Web server, you should configure the ChatHub so that it uses the correct MSMQ’s.
Note
The FQDN FDQN stands for Fully Qualified Domain Name and specifies the exact location in the tree hierarchy of the Domain Name System (DNS). An example for [hostname].[domain].[top level domain] is [www].[microsoft].[com] during the installation needs to be Web Server.
When doing a default installation of the WebChat the following is configured in the appsettings.config of the ChatHub (by default on the UCC server that is):
<add key="WebChatInputEndpoint" value="msmq://<message queue name>@localhost" />
<add key="WebChatUccEndpoint" value="msmq://<message queue name>@localhost" />
When having the ChatHub on a other server, this should be changed to either:
<add key="WebChatInputEndpoint" value="FormatName:DIRECT=OS:<ucc application server FQDN>\private$\<message queue name>" />
<add key="WebChatUccEndpoint" value="FormatName:DIRECT=OS:<ucc application server FQDN>\private$\<message queue name>" />
Or
<add key="WebChatInputEndpoint" value=" FormatName:DIRECT=TCP:<ucc application server IP>\private$\<message queue name>" />
<add key="WebChatUccEndpoint" value="FormatName:DIRECT=TCP:<ucc application server IP>\private$\<message queue name>" />
Off course you should also pay attention to the IIS configuration. This can also be done in many ways.
We suggest to use Microsoft TMG (or any other proxy server) to determine which traffic needs to be allowed (and which not).
Create the local service accounts
-
On the UCC server. Go to Computer Management
-
Now go to Local Users and Groups
-
Create a new local user and give it a username and password
-
Now go to Groups and add this user to the local administrators group
-
Now, go to the machine where the web services will be installed and repeat steps 5 till 8.
Note
Make sure to use the EXACT SAME USERNAME AND PASSWORD for both the local accounts.
This doesn't work if the 2 machines are in different forests.
Configure IIS
-
Open IIS and go to Application Pools.
-
Now select: Add Application Pool
-
Fill in an Application Pool name (in this example we went for Webservices) and select OK.
-
Select the pool and select Advanced Settings
-
Modify the Identity, choose for Custom account and select Set.
Configure the Message Queues
-
First thing is, to install the Message Queuing service on the Web server as well.
Do this via control panel or the following PowerShell command
-
Then, on the UCC server, open Computer Management and go to the Private Queues section:
-
Provide ‘Send Message’ permissions to ‘ANONYMOUS LOGON’ to the following queues:
-
UCC_WEBCHATPLUS_xxx_WEB_INPUT
-
UCC_WEBCHATPLUS_xxx_UCC_INPUT
Example:
-
-
Give the local account (created before) ‘Full Control’ permissions. In this example the accounts name is ucc_support
-
UCC_WEBCHATPLUS_xxx_WEB_INPUT
-
UCC_WEBCHATPLUS_xxx_UCC_INPUT
Example:
-
-
You are now finished with configuring the external web services.