Once you have estalished the foundation for your MindLink deployment in the Pre-requisites section it is time to configure some of the functionality in order to prepare for your MindLink deployment. Depending what you want to get out of your MindLink deployment, some of the configurations below may not apply.

Group Chat Disabled

As of 17.3 MindLink Mobile supports a Skype for Business/Lync topology that does not have PChat installed; this is achieved by enabling administrators and subsequently users to choose between modalities (if supported). Please note: this should be discussed during the planning phase.


  • Service account with read/write permissions to the preferences repository

  • Preferences repository stored locally or on a network drive. Default location for Local Preferences Repository is \Program Files\MindLink Software\MindLink Mobile\Connector Service\preferences. This can be changed to any local or network file location within the 'Lync/Skype for Business' tab within the MindLink Managment Center.

Skype for Business Online Configuration


  • Multiparties are compatible with SfBO

  • Conversation history is conpatible with SfBO

In the Windows powershell change the directory to either the MLA or MLM directory

For Anywhere - Set-Location –Path “C:\Program Files\MindLink Software\MindLink Anywhere\ManagementTool”

For Mobile - Set-Location –Path “C:\Program Files\MindLink Software\MindLink Mobile\ManagementTool”

The below command imports the Skype for Businss Online module

import-module ".\SkypeForBusinessConfigurationModule.psm1"

The management tool will need to be saved with group chat disabled after importing the Skype for Business Online module.

Enable-MlSfboConnector - This enables an SfBO connection to the server

Get-MlConnectorConfiguration - This will display what connection has been configured.

The command will need to copied and pasted into file in the directory MindLink Software\MindLink Anywhere\Connector Service. This will need to be pasted under the O365 settings.

- <add key="connector.sfbo.applicationid" value="1e468961-eb5a-433d-b541-301226afaf72" /><add key="connector.sfbo.autodiscoveryurl" value="" /><add key="connector.sfbo.authenticationcontexturltemplate" value="{0}" /><add key="connector.sfbo.clientsecret" value="RFMyug51XBPsMa1Tj4AhbbLOoj5Ooa73jZMMNA5Vxwc=" /><add key="connector.sfbo.commonoauthendpointurl" value="" /><add key="connector.sfbo.microsoftapplicationid" value="d3590ed6-52b3-4102-aeff-aad2292ab01c" /><add key="connector.sfbo.oauthurltemplate" value="{0}/oauth2/token" /><add key="connector.sfbo.tenantname" value="" /><add key="connector.sfbo.exchangeservicesurl" value="" />

Reset-MlConnectorConfiguration - This resets the conection back to the Skype for Business On Premise

Configuring Add-in proxies.

In an enterprise environment, it is often not the case that MindLink Anywhere and any Client Add-Ins will be served from the same actual machine. Hence, they will be served from different domains/ports and so Client Add-In/MindLink Anywhere communication will be forbidden. The use of a reverse-proxy is therefore required to mux requests to MindLink Anywhere and to any configured Client Add-Ins to the same domain. This can be achieved by configuring the reverse-proxy with forwarding rules based on the relative-path of the incoming HTTP request. The reverse-proxy is not a component of MindLink Anywhere and must be sourced from a third-party vendor.

It may also be the case that a Client Add-In's URL as loaded by Group Chat Console clients is not that which is exposed by the MindLink Anywhere reverse-proxy. In this case, the Add-In should be configured using the Group Chat MindLink Management Center as the URL that the Group Chat Console should load. MindLink Anywhere should then be configured using the add-in re-write rules configuration key, to convert the Add-Ins URL into the URL that the reverse-proxy exposes it as.

The add-in re-write rules configuration setting is a set of key/value pairs. The "key" is a regular expression to test any Client Add-In URLs against. If the regex matches, the Client Add-In URL is transformed using the "value" string. The value string supports regex style group placeholders (e.g. $1) to re-use elements of the original matched URL.

For instance: to re-write an internal Client Add-In URL of:

  • to the external address of http://MindLink

the regular expression would be*), and the replacement would be http://MindLink$1 In the MindLink Management Center, this would be typed in the add in re write rules config box as:

  •*), http://MindLink$1;

Note that the literal special characters in the regular expression "key" string are escaped with a backslash.

An example Client Add-In configuration is shown below.


Figure 113: Example proxy and MindLink Anywhere configuration

The enable an add-in, a check box can be used to disable Client Add-In support across the whole system in all chat rooms, if needed.

Secure Deployment

The following diagram shows the configuration necessary for a secure deployment. We make the following assumptions:

The Challenge Response Service and Host Identification Service listen on the same port.

Security on the File Transfer Service, Socket Service and MDS push communication is either globally enabled or disabled.

The same certificate is used to secure the Socket Service and the File Transfer Service.


Figure 18: Secure Deployment for Android


Figure 19: Secure Deployment for iPhone

The management centre is used to configure the socket service port, the port of the file transfer web service, and the shared port of the Challenge Response Service and Host Location Service.

By default, the management centre configures the socket service host name as the FQDN of the server. This value is customizable in the management centre if the organization has its network infrastructure setup, so that clients can make connections to a different address.

If security is enabled, the certificate used to secure the file transfer service and socket service must also be configured. The subject must be the host name of the broker service, and it must be issued by an authority trusted by the device.

  • The relative paths of each HTTP service are hardcoded constants.

  • The Host Location Service returns the details of the socket service and Challenge Response Service to the device.

File download links are sent in-band with the chat history as direct download links to the file transfer service. Hence, the client must only be configured with the load-balanced URL of the Host Identification Service.

HTTP Proxy

Given that the client connects to the proxy and not directly to the hostname, port or even potentially the relative path of the actual broker service when using an HTTP proxy, the actual URLs to connect to must be made configurable.

Since the client connects to the URL in its own IT policy or local configuration for the Host Location Service, only the URLs of the Challenge Response Service and the File Transfer Service must be configured on the server via the management centre/app config.


Figure 20: HTTP Proxy Configuration for iPhone

  • The Challenge Response Proxy URL and File Transfer Proxy URL are configured on the server via the management centre/app config.

  • The proxy URL of the Challenge Response Service is sent to the client in the response from the Host Location Service.

  • The File Transfer Proxy URL is used to form file download links sent to the client in messages.

Note: the security protocol on the proxied URLs is not necessarily linked to whether security is enabled on the server, as the HTTP proxy may be configured to perform HTTPS communication and/or offloading between itself and the client, or itself and the Mobile Broker.

The client is configured with the proxied URL of the load balanced Host Location Service.

Profile Pictures (18.6+)

As of 18.6 MindLink supports user profile pictures. These will be displayed in the web client and can be configured through several sources.


User photos in SfB/Lync can be specified in three ways:

  1. URL
  2. Exchange
  3. Active Directory

MindLink will attempt to resolve a user's photo in the order that these types are listed, so if you have a photo set in Exchange and have also configured a user photo image URL through the native client, the URL image will be shown in MindLink.

Setting User Photos in MLA (18.7+)

MindLink also offers the ability to set your user photo directly through the client. This feature is provided by Exchange server (version 15.1 and above) which must be configured correctly to work along-side MindLink.

When a user uploads a new user photo from the client, the MindLink server acts on their behalf using its service account domain credentials to authorize a request against the Exchange Web Services. This single Active Directory service account is therefore responsible for accessing Exchange information for all users, and as such, requires special elevated permissions.

Exchange administration is restricted by Role-Based Access Control (RBAC), a system whereby rights to certain administrative operations and features are defined by distinct "management roles" and granted to users/groups in Active Directory either directly, via a Universal Security Group or via a role group assignment.

Exchange installs with a large set of pre-defined roles out-of-the-box; these typically cover all the different access scenarios administrators are likely to require.

One such role is the Mail Recipients role which includes (but is not limited to) the following entry:

  • SetUserPhoto

It is also configured with the appropriate scopes that MindLink requires to access all user accounts across the organization. For the simplest way of granting these permissions, you can assign this role directly to the service account user:

  • New-ManagementRoleAssignment –Role "Mail Recipients" –User "YourServiceAccountName"

The preferred approach would be to create a new admin role group, assign the role, and then add the service account as a member of the group. This can be easily acheived through the Exchange Admin Center. If you already have MindLink configured with Exchange to enable private conversation history then you may have already already created a new admin role group to apply the ApplicationImpersonation role to the service account. If this is the case, then you can simply add the Mailbox Recipients role to this group too; otherwise, create a new role.

The Mail Recipients role comes with a lot of other entries that aren't directly relevant to configuring user photos. If security is a consideration, then it may be desirable to restrict the service account access to only those commands that are directly releveant. This can be be done quite easily by creating a new management role that only contains the role entry above. We can do this by "cloning" the Mail Recipients role and removing all other role entries:

  • New-ManagementRole -Name “Set User Photos” -Parent "Mail Recipients"
  • Get-ManagementRoleEntry "Set User Photos\*" | Where {$_.Name -NotLike "SetUserPhoto"} | Remove-ManagementRoleEntry

We now have a new management role "Set User Photos" with all the same scopes as Mail Recipients but that only contains the entry relevant to configuring user photos. This should be assigned to the service account using either of the methods described previously.

Mobile Autodiscovery (17.6+)

DNS requirements

As of 17.6 it is possible to configure your mobile deployment to accept users domain email addresses i.e. test1@testdomain.local as a means of initializing against a MindLink Mobile deployment. However there a few pre-requisite steps that will be discussed to make this possible. Firstly, ensure that a CNAME (alias) record is setup in your forward lookup zone. Once this is done you will want to choose a target host, this will be the server hosting the MindLink Mobile service.


Figure 24: SharePoint Feature Settings

1 - SharePoint API Port: The port on which to listen for incoming SharePoint server MTLS connections required only when configuring for Single Sign-On.

2 - Certificate: The server certificate to use for incoming SharePoint MTLS connections. This authenticates the Connector Service to the SharePoint server required only when configuring for Single Sign-On.

3 - Authorized Hosts: The authorized hosts collection should contain the FQDN of all SharePoint hosts that will connect to the Connector Service instance being configured required only when configuring for Single Sign-On.

If a SharePoint host attempts to connect to the Connector Service and is not in the Authorized Host collection, an error indicating that the host is not authorized will be returned.