Minimal deployment walkthrough
This page walks through a hypothetical deployment of a 3 node "one-box" cluster.
Topology
As each node in the cluster will be deployed with both the MindLink Anywhere and MCE roles, we will form a fully connected network.
Our example environment is as follows:
| Server FQDN | Server IP(s) | Function |
|---|---|---|
| dc.domain.local | 192.168.0.3 | The AD domain controller |
| sql.domain.local | 192.168.0.5 | The SQL always-on cluster |
| files.domain.local | 192.168.0.6 | The network file share |
| attributes.domain.local | 192.168.0.7 | The security attribute server |
| sfb.domain.local | 192.168.0.10, 192.168.0.11, 192.168.0.12 | The Skype-for-Business pool |
| mindlink1.domain.local | 192.168.0.21 | The first MCE/MLA server |
| mindlink2.domain.local | 192.168.0.22 | The second MCE/MLA server |
| mindlink3.domain.local | 192.168.0.23 | The third MCE/MLA server |
| minlink.domain.local | 192.168.0.30 | The web load balancer |
We will assume the default port configuration for the following dependent services:
| Service | Port | Function |
|---|---|---|
| Active Directory global catalog | TCP 3289 | Performing authentication / synchronizing user security attributes |
| Attribute server | TCP 443 | Synchronizing user security attributes |
| SQL server | TCP 1433 | MCE persistence layer |
| SfB server | TCP 5061 | MindLink Anywhere SfB backend communication |
| Network file share server | TCP 135-139, UDP 135-139 | MCE file upload repository |
We will assume the default port configuration for the MindLink server roles as follows:
| Port | Direction | Function |
|---|---|---|
| 11111 | Bi-directional (from other MCE cluster members) | The MCE silo-to-silo communication port |
| 30000 | Bi-directional (from other MCE cluster members) | The MCE client-to-silo gateway port |
| 9080 | Inbound (from anywhere) | The MLA web port (and MCE admin port) |
Therefore each MindLink server will need Firewall rules to allow the following:
| Port | Direction | Target |
|---|---|---|
| TCP 3289 | Outbound | dc.domain.local |
| TCP 443 | Outbound | attributes.domain.local |
| TCP 1433 | Outbound | sql.domain.local |
| TCP 5061 | Outbound | sfb.domain.local |
| TCP 135-139 | Outbound | files.domain.local |
| UDP 135-139 | Outbound | files.domain.local |
| TCP 11111 | Inbound/Outbound | mindlink1.domain.local, mindlink2.domain.local, mindlink3.domain.local |
| TCP 30000 | Inbound/Outbound | mindlink1.domain.local, mindlink2.domain.local, mindlink3.domain.local |
| TCP 9080 | Inbound | mindlink.domain.local |
The network interactions can then be visualized as follows:
Active Directory
We will assume that the Active Directory server has a security group defined for MCE administrators:
| AD DN | Purpose |
|---|---|
| CN=MceAdministrators, DN=Groups, DC=domain, DC=local | A security group containing MCE administrator users |
SQL Server
We will assume that the SQL server has been configured with a database for MCE and has had the pre-requisite SQL scripts already executed against it:
| SQL Server Connection String |
|---|
| Server=sql.domain.local;Database=Mce;Integrated Security=true |
Certificates
We will need certificates to secure communication between MindLink servers and dependency services, MindLink servers and MindLink clients and between MindLink cluster members.
In order to secure the MindLink cluster we need to settle on a cluster address that all servers within the cluster (and any server connecting into the cluster) require as a SAN on any certificate they present. In this example we will use the following:
| Cluster address |
|---|
| mce.domain.local |
In order to secure the MindLink Anywhere services, we will assume that there is an SSL-terminating load balancer in front of the MindLink Anywhere services and so the MindLink servers themselves present internal server certificates to the load balancer.
The following certificates are then required to secure the MindLink services:
| Certificate ID | Certificate Use | Subject/SAN | Scope |
|---|---|---|---|
| SfB MTLS Certificate | Secure MTLS SfB connectivity | mindlink1.domain.local, mindlink2.domain.local, mindlink3.domain.local | per-machine or per-cluster |
| MCE MTLS Certificate | Secure MTLS MCE connectivity | mce.domain.local | per-machine or per-cluster |
| MLA Web Certificate | MLA web service certificate | mindlink1.domain.local, mindlink2.domain.local, mindlink3.domain.local | per-machine or per-cluster |
| MLA Auth Certificate | Authentication token certificate | <anything> e.g. mindlink.domain.local | per-cluster |
We will use the certificate identities above, assuming the simplest certificate configuration where all certificates contain SANs for all cluster server FQDNs.
Configuration
First, we must configure the following integration features:
See Configuring MindLink Anywhere for further details.
The configuration of MCE relies upon the advanced configuration section of the MindLink Management Center.
All cluster members
Most of the configuration across servers in the MindLink cluster must be the same in order for them to be considered members of the same cluster. In fact, the only configuration that should differ is the advertised IP address of the cluster members and possibly the certificates (if a per-machine certificate is used instead of per-cluster):
Management Center configuration
We must configure the settings of the MCE services through the appropriate page in the Management Center for all of the following scenarios.
Server
Enables the services that host the backend for the MindLink Chat Engine.
- Enable MCE backend services: Enables the configuration of the backend services that synchronize with existing infrastructure to host the MindLink Chat Engine.
- Please note the Management Center does not currently validate the input fields on the MCE configuration page if MCE backend services are not enabled.
Cluster configuration
Specify the identity used for the MCE cluster and the database connection used for all MCE operations, including cluster membership.
- Cluster ID: Specifies the identity of the cluster.
- Database connection string: Specifies the database connection for all MCE operations, including cluster membership.
- Database Test: Allows for checking the database connection string's validity as well as checking if the server requires updating. See Database Updates.
Cluster node configuration
Specify the connection details for the local MCE cluster node.
- Advertised IP Address: Specifies the IP address this cluster node can be reached on from other cluster nodes (default
127.0.0.1) - Silo Port: Specifies the port this cluster node will accept peer cluster node connections on (default
11111) - Gateway Port: Specifies the port this cluster node will accept client connections on (default
30000)
Transport Security
Specify the addresses and certificate used to encrypt communication between MCE cluster clients and servers.
- Cluster address: Specifies the DNS name of the cluster.
- This is used by cluster clients to authenticate the server with which they are communicating.
- These values are the main differences between the deplyments. For exaple:
mindlink1.domain.local=192.168.0.21
mindlink2.domain.local=192.168.0.22
mindlink3.domain.local=192.168.0.23
- Cluster certificate: Specifies the certificate in the Windows Machine Certificate Store to use to secure TLS communication between the cluster nodes
- This is used by both cluster clients and servers to authenticate communication bi-directionally.
- This authentication is performed for both client-to-server and server-to-server communication.
- If a per-machine certificate is used instead of per-cluster, these values will need to be different per deplyment.
- Trusted addresses: A comma-separated list of subject names that are trusted. One or more SANs in the certificate used to connect to the cluster must appear in this list
- Disable transport security: Disables secure communication between cluster clients and servers. This will disable the usage of the other fields in Transport Security.
- Warning! Communication within the cluster will be in plain text and therefore unprotected if transport security is disabled.
- It is strongly advised that transport security is enabled.
Orleans dashboard
- Enable Orleans Dashboard: Enables the monitoring dashboard for the MCE cluster
- Orleans Dashboard port: Specifies the port to host the monitoring dashboard over HTTP
Advanced Configuration
| Key | Value | Description |
|---|---|---|
| global.service.modules | Web,Mce,MceAdmin | Enables Web, MCE and the MCE administration services respectively |
| debug.mce.clientenabled | true | Enables the MCE connector for Web, overridden to true when the "MceAdmin" module is enabled |
| mce.attributesynchronization.validissuers | AD | Specifies the issuers that can be used to specify COI attributes. AD = Active Directory. The value for your third-party attribute service can also be used |
| mce.attributesynchronization.activedirectory.synchronizationreminderminutes | 1 | Specifies the reminder interval, in minutes, for synchronizing the Active Directory attributes |
| mce.attributesynchronization.attributeprovider.synchronizationreminderminutes | 1 | Specifies the reminder interval, in minutes, for synchronizing the user attribute provider attributes |
| mce.attributesynchronization.user.defaultissuer | AD | Specifies the default attribute issuer to use for user attribute synchronization |
| mce.attributesynchronization.user.linkedauthenticationidentity.issuer | AD | Specifies the attribute issuer to use as the linked authentication identity for users |
| mce.attributesynchronization.user.linkedauthenticationidentity.name | msRTCSIP-PrimaryUserAddress | Specifies the attribute to synchronize as the linked authentication identity. This is the property defined in the attribute issuer used to link users |
| debug.connector.mce.groupclassificationrequired | true | Enforces that a classification must be specified when creating a group |
| debug.mce.file.server.path.<mce file server identifier> | C:\mce\files | The path to where file uploads should be stored when the specified <file server identifier> is configured as the active file server, this should be a network path accessible to all MLA hosts. This key allows for recording multiple file paths onto which files have been uploaded, the currently "active" path (onto which new files will be uploaded) can be switched with the debug.mce.file.server.activeid key |
| debug.mce.file.server.activeid | mcefileserver1 | The desired mce file server identifier, defined via using the debug.mce.file.server.path.<mce file server identifier> debug flag |
| connector.ucma.custompreferencesrepository | C:\mce\preferences | The path to where user preferences should be stored, this should be a network path accessible to all MLA hosts. |
| debug.mceadmin.admin.adgroup | CN=MceAdministrators, DN=Groups, DC=domain, DC=local | The Active Directory distinguished name of a Security Group for administrator accounts |
| debug.ucma.persistentchat.enabled | false | Determines whether the Skype for Business Persistent Chat connection is created. false => Persistent Chat should not be connected for user sessions, true => Persistent Chat should be connected. |
Running
Each service should be started one-at-a-time to avoid a temporary split-cluster:
- Start the
MindLink Anywhereservice onmindlink1.domain.local - Start the
MindLink Anywhereservice onmindlink2.domain.local - Start the
MindLink Anywhereservice onmindlink3.domain.local
This deployment will continue to operate in the face of a single node failure.
The configuration in this walkthrough enabled the administration services on each server. This means that you can connect the MCE PowerShell module to any one of the servers in order to manage the MCE cluster.
The configuration in this walkthrough enabled the Orleans dashboard on each server. This means that you can browse to https://mindlink1.domain.local:8033, https://mindlink2.domain.local:8033 or https://mindlink3.domain.local:8033 in order to monitor the health of the cluster depending on the Firewall configuration.