Loading...
 

Administration

Version 17.4

On this page:

[Show/Hide]

Introduction

The MindLink Management Center provides a user friendly interface to configure MindLink and its client software (MindLink Desktop, MindLink Mobile, MindLink API and the MindLink WebPart).

The MindLink Management Center is installed alongside all MindLink core products and should be run on the server that is being configured.

 

1   MindLink Management Center Outline

The MindLink Management Center can be loaded from the shortcut on the desktop, or can be located in %ProgramFiles%\MindLink Software\ManagementTool.

The Management Center will load with the logging configuration as the default page.

 

The MindLink Management Center can be loaded from the shortcut on the desktop, or can be located in:

 

%ProgramFiles%\MindLink Software\"MindLink Component"\ManagementTool.

 

It will be named according to which component of MindLink is installed. E.g. MindLink Mobile Management Center, MindLink Desktop Management Center, MindLink API Management Center and MindLink SharePoint Management Center.

   

1.1   Editing Configurations

MindLink Management Center

1 – The navigation tree displays all of the available configuration sections. Clicking on a section will display the configuration options for the selected section in the configuration panel (2).

When a change has been made to any configuration setting, the navigation tree icon for the section in which the setting resides will change to  image003.png , to indicate that there are unsaved changes.

2 – When a configuration option has been changed in any section, the “Save Changes” button will be enabled. Clicking the “Save Changes” button will save the configuration.

3 – The configuration section header shows the name of the currently displayed configuration section and a brief description of what the configuration section options affect.

4 – The configuration panel displays all configuration options for a section.

 

1.2   Saving Changes

 

Savingchanges

 

Save Changes Prompt

  • Clicking on the “Save Changes” button will attempt to save configuration changes.
  • The MindLink Management Center can automatically configure port reservations, firewall exemptions and certificate bindings so that the Connector service will function correctly.
  • The MindLink Service will require a restart for these new settings to take effect

 

Updatebindings1

 

Update Bindings Prompt

  • Clicking on the “Save Changes” button will attempt toupdate bindings changes.
  • If required, The MindLink Management Center can automatically update certificate and port bindings
  • Select Save and Update Bindings to update the configuration

2   Configuration Sections

The MindLink Management Center will load with the logging configuration as its default page. The user can navigate through different configuration settings by using the navigation tree , which includes the following configuration sections:

  • Licence
  • Logging
  • General
  • Add-Ins
  • Lync/Skype for Business
  • Active Directory
  • Network
  • Feature
    • MindLink Desktop
    • MindLink Mobile
      • Android
      • Apple
      • BlackBerry (16.3 server)
      • Server Pooling
      • Policies
    • MindLink API
    • MindLink for Sharepoint

2.0.1 Licence Files

The licence page ensures the products you are using are firstly; supported by MindLink and secondly; that only the correct products (as stated by contract) are in use.

Opening the license tab, you are given the ability to browse for a file. This will be the file you received within the correspondence with your account manager.

Click the ‘Browse for license file…’ button which will open file explorer. Navigate to your license file.

 

Click the ‘Browse for license file…’ button which will open file explorer. Navigate to your license file.

Selecting a valid license file will show similar details to the corresponding management center image below.

For MindLink Mobile:

License Holder – This field specifies the Company name the license is issued to and also the product owner at the time of purchase.
Expiry date: – The date the product expires. At this time (grace period built in) the product will cease to function.
Details – This field contains the product/s that the license has been issued for. MindLink will not run with an incorrect product license (a single license can be issued for multiple products).

 

For MindLink Desktop:

Same principles apply for MLA licenses, but there is an extra feature explained below.

Enabled users– This capacity is based on the number of users who could log on, rather than the current number of users logged on.

The system periodically checks the number of users who could log on and starts rejecting new logons if it sees that the number of hypothetical users is larger than the licensed capacity.

If a license reaches expiry the following message will appear. Please contact your account manage to receive a current license within contract renewal.

 

If a license is issued for a different product to the one you are attempting to run. The following message will appear – stating the product this license is valid for. Please contact your account manager to discuss increasing your subscribed products.

 

2.1   Logging

The logging section enables the user to configure the logging level as well as the log file location for the Connector Service.

Please note that logging on the Connector Service is performed using the Microsoft Enterprise Library’s Logging Application Block

 

NewUXWiki6

 

By default logging is configured as follows:

  • Error level - Error class events
  • Warning level - Warning class events (Recommended)
  • Info level - Info class events
  • Verbose level - All class events

Logging Configuration

You can Configure the Connector service logging level and log file location by Clicking on the Browse… button will let you find an absolute path to a new log file location, or you can manually edit the field to a path relative to the Connector Service install location.

The account used to run the Connector Service must have write access to the install location of the product in order to log to the rolling log file. The file can by default be found at %ProgramFiles%\MindLink Software\MindLink Application\ConnectorService\Logs\Connector.log

2.2   General

The General section lets the user configure the general settings that will be applied to the Connector Service. 

Figure 5: General Settings

1*Information service port: The port number used when behind a load-balancer to provide a service heart-beat.To allow collocation, Default Ports are as below and can be tested eg http://{server}:9007/Connector/InfoService/Status

  • MindLink API => 9006 
  • MindLink Desktop => 9007 
  • MindLink SharePoint => 9008 
  • MindLink Mobile => 9009 

2Maximum number of concurrent file downloads: The maximum number of allowed concurrent file download requests.

If an attempt is made to download a file when the number of active file downloads to the server is equal to the number specified, the download will fail with an error indicating that the server limit is currently exceeded and to try again later.

3Maximum number of concurrent file uploads:  The maximum number of allowed concurrent file upload requests.

If an attempt is made to upload a file when the number of active file uploads to the server is equal to the number specified, the upload will fail with an error indicating that the server limit is currently exceeded and to try again later.

4Maximum file size for file uploads:  If the configured connector supports file posting, the maximum size of files in kilobytes allowed to be uploaded.

If an attempt is made to upload a file that is larger than the specified size, the server will return an error indicating that the file is too large to upload.

5 Enable instant messaging: When set, allows connected clients to use instant messaging.

When not checked, user presence will not be published, instant messaging will be disabled, and the client will be limited to group messaging functionality. Any client that exposes instant messaging functionality when instant messaging is disabled will receive failure notifications from the server when an attempt is made to use such functionality.

6Enable group chat: When set, allows connected clients to use group chat.

When not checked, group chat preferences are not loaded and users will not see any groups or chat rooms to which they are subscribed in their contacts list nor will they be able to search for and add groups.

7Enable optional instant messaging: When set, allows users to specify whether they want to log on with or without the instant messaging capability enabled on their web or mobile client.

When not checked, users will not be able to choose to enable/disable instant messaging upon login and the setting will default to the configuration in the management tool .

8Enable optional group chat: When set, allows users to specify whether they want to log on with or without the group chat capability enabled on their web or mobile client.

When not checked, users will not be able to choose to enable/disable group chat upon login and the setting will default to the configuration in the management tool .

9Maximum message length: The number of characters that a single message can include.

If an attempt is made to send a message that is longer than the specified length, the server will not send the message and an information message will appear in the server logs.

10Maximum story length: The maximum number of characters that a single story can include.

If an attempt is made to send a story that is longer than the specified length the server will not send the story and will return an error indicating that the story exceeded the allowed story length.

 

2.3   Add-Ins

In this section the user can configure Group Chat add-ins across MindLink Desktop and Tablet Platforms.

 

NewUXWiki8

 

Figure 6: Add-in Settings

  • When set, Group Chat add-ins will be displayed within compatible clients. When false, any configured client add-ins will not be displayed for any chat room.
  • MindLink classic and MindLink Tablet only

Rewrite rules for Add-ins:

  • A set of key/value pairs that describe the client add-in proxy rules that should be applied to client add-in URLs.

See Section 5 for detailed instructions on setting up Group Chat Add-ins.

2.4   Lync/Skype for Business

The Adaptor section manages the selection of the underlying chat system to which to connect and the infrastructure DNS servers that define the chosen platform.

 

 

Figure 8: Platform Settings

1Server Version: Select the chat platform version.

2Auto Provisioning Server Information: (Lync 2013/SFB Only) Enable the auto detection of the Front End Server. This will allow the server to detect any server changes within the Topology and auto configure the new servers. This requires Lync Core Components to be installed

3Auto Provisioning Application ID: (Lync 2013/SFB Only) Enter the Application ID of the trusted application on the Front End.

4Local Server Name: Manually enter the FQDN of the local machine

5Server Name: Manually enter the FQDN of the OCS/Lync/SFB front end or pool server.

6 Server/Listen Ports: The default communication port for OCS/Lync/SFB used by the Front End Server to listen on when using trusted authentication.To allow Collocation the default ports are as below :

  • MindLink API => 4096 
  • MindLinkDesktop => 4097 
  • MindLink SharePoint => 4098 
  • MindLinkMobile => 4099

7 Platform Certificate: The certificate to use for establishing an MTLS connection with the OCS/Lync server.

8 Enable Group Chat SDK Logging: Enabled by developers to debug SDK Issues – OCS 2007 and Lync 2010 only.

9 Auto Provision Group Chat Information: Automatic discovery of the lookup address for querying Group Chat – Lync 2013 only. Use this option to look at multiple chat pools

10 Lookup Server Address : Manually enter the lookup address for querying Group Chat. This is the address created upon activation, , use Get-csPersistentChatEndpoint to identify.

11 Enable Debug: To Debug the communication protocol and transport mechanism during debug mode.

12 SIP Transport Type: The transport type between the Connector service and the OCS pool e.g. TLS or TCP – during debug mode.

13 Authentication Protocol: Domain protocol set to either NTLM or Kerberos.

14 Conversation History: Enable conversation history saving and loading.

2.5   Active Directory

1 Enable Auto discovery of Global Catalogue

2 OCS/Lync/ Forest Name: Select the relevant forest name in which platform is installed and base for AD operations for users.

3 Server Name: Manually enter the FQDN of the LDAP server is Auto-Discover is not detecting correctly.

4 Use Default Port: Default port number of the Global Catalog used to look-up user SIP addresses from Active Directory i.e. 3268.

5 Port Number: To enter a custom port number to look-up user SIP addresses from Active Directory.

– Active Directory Time-out: Specify the time interval in seconds for Active Directory queries.

Use Default Naming Context: Auto-discover the name of the root context of the directory. Use this is membership is not restricted.

Naming Context: Manually enter full OU path if users are to be restricted to this AD OU object

9Search Filter: Must be configured, responsible for retrieving sip address for a user via Active Directory.

10Default user domain: The default domain that will be used if a user does log specify a domain in their user name when logging on.

11Restrict usage to members of an AD group. Restrict access to Members of this AD Group to be able to log in

12Group Name Select the Group from the dropdown (start typing the name to dynamically list) if users are to be restricted to this AD Group.

2.5.5 Network

This section allows a HTTP Proxy to be configured to assist with network routing

This section manages MindLink Desktop settings that affect the way the web client is hosted and displayed to a user.

Figure 9: MindLink Desktop Feature Settings

1Web client port number: The port number at which the web client will be available. For example, if the port number is 9080 and HTTPS is enabled, then navigating to “https://{fqdn}:9080/” will display the web client.

2Use HTTPS: When set, hosts the web client over HTTPS. A valid certificate must be specified in order for the configuration to save successfully.

3Certificate: A valid certificate must be specified in order for the configuration to save successfully.

4Base Path: Appended text to the V3 URL i.e. https://FQDN:port/yourbasepath .

5Session Timeout: The session time out period assigned to manage the session when long polling stops.

6Long Polling Session Timeout: Defines when long polling will stop.

2.6.1   Configuring External URLs for SSO

When using SSO, it is often convenient to redirect users to a custom page for login, or a custom page on logging out.

MindLink Desktop allows this by configuring two keys in the ClientSettings.js JavaScript configuration file - found in the MindLink Desktop client installation directory, or by editing two keys in the Connector Service’s configuration file (MindLink.Core.Host.exe.config).

Setting a value for the ExternalLoginPageURL (ClientSettings.js) or gcwa.externalloginpageURL (ConnectorService configuration) key will redirect users to the specified URL when SSO fails.

Setting a value for the ExitPageURL (ClientSettings.js) or gcwa.exitpageURL (ConnectorService configuration) key will redirect users to the specified URL on logging out.

2.6.2   SSO using Windows Authentication

Kerberos operates using “principles” which are identifiers for users and services for which Kerberos tickets can be generated. So that a client can create a ticket readable by a service, it looks up the service principal name and asks the Kerberos server to produce a ticket that can be given to the service. Clearly if the service has no registered principal name, or an incorrect principal name is used (for instance falling back to a default service name) then the ticket will be incorrect and authentication will fail.

Windows authentication can be implemented by running the following command as a domain administrator:

image013.png

Note this only affects Windows Authentication, NTLM does not use SPNs.

 

Version 3 of the MindLink Desktop product supports a number of different authentication mechanisms. SSO can be enabled using either Windows and/or HTTP Header authentication. Within the management tool simply enable the 'Enable Windows Authentication' and/or 'Enable Pre-Authenticated HTTP Header Authentication'. See section 3 for more information. If one authentication mechanism fails to work successfully, it will failover to the next available authentication mechanism.

Enabling the option 'Enable Password Authentication' simply presents a web version of the MindLink desktop username and password screen.

Note: as of 17.1 it is mandatory that you provide a token issuing certificate as this is used to manage user authentication. To do so simply choose a relevant certificate from the 'Token Issuing Certificate:' section, ensuring that the certificate has a key length of 2048 bits and is setup for digital signing. 

Also new for 17.1 it is possible to enable the user to select their preferred authentication mechanism. If more than one authentication mechanism is enabled it means that the user is able to differentiate between what mechanism they would prefer to use. For example, the user can either choose a) 'log me in with the best' or b) a specific mechanism. Also noteworthy is that once an authentication mechanism is chosen by the user, it will be remembered in future instances.

image014.jpg

image014.jpg

2.6.4   SSO - NTLM (V3)

image014.jpg

 

To use NTLM as the authentication protocol, start by enabling 'Windows Authentication'. Once this is done select 'NTLM' under 'Authentication Protocol'

Once you done this, you will want to ensure the web address is saved on the local intranet security zone which can be done via Internet Properties

 

2.6.5   SSO - Kerberos (V3)

image014.jpg

To use Kerberos as the authentication protocol, start by enabling 'Windows Authentication'. Once this is done select 'Kerberos' under 'Authentication Protocol'

Once this is done there are a number of steps required to use Kerberos as your authentication protocol. The following screenshots will cover these steps.

image014.jpg

In order to allow MindLink Desktop to utilise Kerberos you will need to set the URL running the MindLink web service as an SPN. This means that Kerberos can provision a ticket readable to the service, thus allowing authentication.

image014.jpg

The final step required for MindLink to utilise Kerberos as the Windows authentication protocol is to configure your browser appropriately To start make sure that the web address running the MindLink for Desktop service is under the local intranet security zone. Once this is done, depending on your browser, you may need to follow some additional steps to enable Kerberos. Below is a guide on how to do so for all of the major browsers: http://docs.alfresco.com/5.1/concepts/auth-kerberos-clientconfig.html

2.6.6   External URL redirection (V3)

image014.jpg

As of 17.1 it is possible to enable setup of external URL redirection. This can be setup in the event that authentication fails and/or when the user logs out. For example, if a user is unable to authenticate i.e. enters the wrong credentials it is possible to have them redirected to an external URL i.e. www.google.com. Likewise, the same is possible when the user logs out.

2.6.5 Desktop Classic (17.1.2)

For those that prefer the classic/streams view the last v1/v2 release is 17.2.1.2

Please note: If required, it is also possible for the administrator to colocate against a V3 server. Thus allowing users to select between V1/V2 and V3 based on preference

2.6.5.1 License

Please refer to section 2.0.1

2.6.5.2 Logging

Please refer to section 2.1

2.6.5.3 General

Please refer to section 2.2

2.6.5.4 Addins

Please refer to section 2.3

2.6.5.5 Lync/Skype for Business

Please refer to section 2.4

2.6.5.6 Active Directory

Please refer to section 2.5

2.6.5.7 Network

Please refer to section 2.6

Please refer to the diagram in section 2.7

2.6.5.9 Colocation

For this section we will look at the ability to colocate an instance of MindLink Desktop Classic against MindLink Desktop V3.

To start, ensure that both .msi installers have been downloaded and are ready for setup on the server whereby colocation will occur

To colocate MindLink Desktop Classic alongside MindLink Desktop V3 it is easiest to configure v3 to utilise a base path. This way when the URL is pointed towards, a user preference can be reflected through a simple change in basepath.

The following will run through how this is done

Start by navigating to the base path section of the MindLink features tab as seen below

From here simply add the base path relevant to your administrative infrastructure. Once this is done the URL used to connect users to an instance of MindLink Desktop V3 will look as follows https://FQDN:port/yourbasepath

Assuming the configuration for MindLink Desktop Classic has been done properly, users will be able to decided whether they want to use v1/v2 or v3 simply by either leaving out the base path for v1/v2 or adding it for v3

2.6.7   Disable Instant Messaging (IM) or Group Chat

Disable IM or Disable Group Chat prevents all Web Client users from using IM or Group Chat respectively. This setting can be either disabled globally via the MindLink Management Center within the ‘General’ > ‘Enable Instant Messaging’ or 'Enable Group Chat' options, or it can be set on an individual basis when the user logs into the Web Client. For MindLink Desktop (Classic) users, on the log in page, there is only the option to ‘Disable IM?’. For MindLink v3, besides the 'Disable IM' option there is an additional option to enable/disable Group Chat.

 

image014.jpg

Usermodalities

 

2.6.8 Custom Preferences Repository

Following the 17.4 release of MindLink Desktop and subsequently the inclusion of disabling group chat, the administrator is now able to keep a repository of user preferences. This enables the continuation of preferences across group chat sessions. This feature also allows for the ability to read preferences across nodes. An example, of such a deployment could be a file share across a network. This allows an administrator to store preferences across multiple machines within a network (if required). This means that changes made on one machine persist across multiple nodes when the same file store is referenced. In this sense, preferences can be stored cross-site.

image135.png

 

Above is the screen that administrators will be presented with when configuring the custom preferences repository. First there is the pathway in which the preferences are written to which can be anywhere that is capable of being read and written to; including across networks. Secondly there is also the abilty to test access to the pathway. In the event the file pathway referenced is not accessible it is possible to either A) change location (in the event it is invalid) OR B-)Provision access rights to the service account running MindLink Desktop; which is a pre-requisite to utilising the custom preferences repository.

Also worth noting is the possibility of having preferences persist during an outage such as in an active-passive disaster recovery scenario. If two machines are connected properly and preferences are shared it is possible that in the event machine A falls, machine B can pick the preferences up without any 'outage' on the user side. Please note that a batch job would have to be setup to facilitate this transference of preferences across the machines

2.6.9 Exchange Web Services

image136.png

 

As of 17.7, administrators can now explicitly configure how the exchange server is resolved. This can be done automatically by ticking the 'Autodiscover Exchange Web Services' box or the URL can manually be entered in the box below. Additionally, a list of well-known URLs can be added where the management tool will look to resolve the exchange server name based off of those URLs.

This section manages MindLink Mobile settings and provides general information with regard to the MindLink Mobile Client set up.

MindLink Mobile General Settings

 Mobile Server Global Settings

1 – Token Issuing Certificate  Specify a token issuing certificate to manage user authentication.

2 – Hostname External DNS of the Mobile Server FQDN. This matches the server address in the client app.

3TLS Socket Port The port on which the Connector service will listen on for incoming MindLink Mobile client connections.

4Secure TLS connection Select this if you wish to secure the WebSocket connection

5TLS Certificate Certificate used to secure the connection

6Identification Web Service HTTP port used to initiate a connection

7SSL option Secure the lookup connection

SSL certificate A valid certificate must be selected for the service to provide for HTTPS connections.

9HTTP File transfer port Option to use a different HTTP port for File Transfers

10File Transfer Port File Transfer Port number

11 – Enable Secure file transfer Enable HTTPS File Transfers

12 – SSL Certificate Select the certificate to be used to secure File Transfers

13 – Session Service Proxy Base URL Base URL for session services external proxy connections

14 – File Download External Proxy Base URL Base URL for file transfer external proxy connections

15 – Enable long session control Enable long session timeouts. This is the connection between the Mobile server and SFB/Lync

16 Long session time out Timeout settings in Days

 

2.7.1 Server Pooling

To enhance resiliency for your MindLink Mobile Enterprise implementation. The Server Pooling feature can be utilised. Please note that the Server Pooling feature requires access to a database instance setup on either Microsoft SQL Server versions 2012, 2014 or 2016. In the Management Center for MindLink Mobile, there is a tab within the feature – MindLink Mobile - that enables server pooling.

 

NewUXWikiMob3

 

Server Pooling Options

  • Enable server pooling – Allow/disallow server pooling
  • Database connection string
  • Override credentials for database operation
  • TEST configuration

1- Enable server pooling – This is enable server pooling to be utilised, this will require a SQL database 2- Database connection string – Configure the connection string with the following syntax:

Server=FQDN SQL server; Initial Catalogue=SQL catalogue; Integrated Security=SSPI

or if you wish to use a Failover SQL partner you could use the following syntax :

Server=FQDN SQL server; Failover Partner=FQDN SQL partner; Initial Catalogue=SQL catalogue; Integrated Security=SSPI

3- Override credentials for database operation – If the user running the management tool does not have sufficient SQL permissions, then these can be overridden by a set of credentials that have sufficient permission by your SQL administrator. 4- To check the validity of a relevant SQL database connection string and the override credentials , select ‘Test’. The following steps may differ and as such are outlined in the two scenarios listed below.

2.7.1.1 Scenario 1: Testing with an non-existent database

If you add a non-existent database in the connection string, you will be asked if you want to install one – and populate it with the necessary MindLink schema and tables.

2.7.1.2 Scenario 2: Testing with an empty database

If the database you have directed MindLink to via the connection string, exists - but is empty - you will just be prompted to install the latest database schema and tables. In both cases, you will get a prompt to confirm the database installation. Finally, if the database connection string and the credentials are correct and/or the installation has been completed successfully, you will receive the following message: In case the database connection string is invalid (invalid format/ wrong database/ wrong server/ wrong credentials), you will receive an error screen with a full Exception dump of the error encountered.

2.7.2   Android Settings

 

NewUXWikiMob4

 

MindLink Mobile Android Device Settings

  • Allow Android Device Connections: The setting that allows Android devices to connect to the MindLink Mobile server.
  • Android Notifications use the Google Firebase cloud messaging service.

2.7.3   Apple Settings

The following settings need to be configured for the MindLink Mobile for iPhone implementation.

 

NewUXWikiMob5

 

MindLink Mobile Apple Device Settings

  • Allow iOS Device Connections: This setting enabled iOS support for the Mobile Server
  • Choose to enable or disable APNS
  • APNS notifications are set by default to :
  • APNS HOST : gateway.push.apple.com (TLS)
  • APNS PORT: 2195 (TLS outbound)
  • APNS certificate is supplied by MindLink.
HTTP revocation of this certificate can be disabled.

Figure 13: MindLink Mobile Apple Device Settings

1*Allow Apple Device Connections: The setting that allows iOS devices to connect to the MindLink Mobile server.

2*APNS Host: The Apple Push Notification Settings host server address.

3*APNS Port: Outbound port number for the APNS host, default 2195.

4*APNS Certificate: The certificate assigned to the APNS host. The certificate will be provided by MindLink along with the installers. The certificate needs to be installed first in the Computer Personal store so it can be selected from the MindLink Management Center.

Network : HTTP Connectivity This is a special connectivity mode designed for use with iOS and Mobile Iron. It allows the 7072 TLS connection to be replaced by a HTTPS connection for use when Tunneling supports only HTTP/S traffic and TLS/Websocket is not available.

2.7.4   Blackberry Settings (Server 16.3)

The following settings need to be configured for the MindLink Mobile for Blackberry implementation.

image018.png

Figure 14: MindLink Mobile BlackBerry Device Settings

1*Allow BlackBerry Device Connections: The setting that allows BlackBerry devices to connect to the MindLink Mobile server.

2*Push Connection Type: How push notifications will be handled either through a BES (BlackBerry Enterprise Service for enterprises) or BIS (BlackBerry Internet Service from a public domain). Generally enterprises will have a BES implemented as part of their BlackBerry infrastructure.

3*Mobile Data Service URL: The URL on which the MDS web service listens for incoming requests.

4*Device Push Port: The port on the device to which the MindLink Mobile server should send messages, default 7060.

5*Active Directory LDAP Path: The LDAP path to use when determining a user name from their email address. Required for SSO only.

 

2.7.4.5 BlackBerry 10 Settings (Server 16.3)

The following settings need to be configured for the MindLink Mobile for BlackBerry 10 implementation.

image019.png

Figure 15: MindLink Mobile BlackBerry 10 Device Settings

1*Allow BlackBerry 10 Device Connections: The setting that allows BlackBerry 10 devices to connect to the MindLink Mobile server.

2*Push Connection Type: How push notifications will be handled either through a BES (BlackBerry Enterprise Service for enterprises) or BIS (BlackBerry Internet Service from a public domain). Generally enterprises will have a BES implemented as part of their BlackBerry infrastructure.

3*Mobile Data Service URL: The URL on which the BES 10 MDS web service listens for incoming requests.

 

2.7.5   Configuring the client

The application running ont he device has options to enable the server connection and user experience.

2.7.5.1 Server Settings for Application

For both the BlackBerry, BlackBerry 10 and iOS, the client is configured to connect to the Web Service URL.

For example, for a Web Service running on ‘7074’ (as shown in the Web Service Port), the client should be configured as the following example shows:

http://{servername}:7074

If there is a proxy in front of the service, then the client should be configured with the proxy URL.

 

2.7.5.2 Disable Instant Messaging (IM)

image020.pngDisable IM Setting on Blackberry

image021.pngDisable IM Setting on iPhone

Disable IM prevents all Mobile users from using IM. This setting can be enabled the following ways:

·   Globally via the MindLink Management Center within the ‘General’ > ‘Enable Instant Messaging’ options.

·   For a group of devices by creating an IT policy rule which must be set up on the BlackBerry Administration Server (BAS) (see MindLink Mobile Install Guide section 3.7.1).

·   On an individual’s BlackBerry device level via the MindLink application options on the BlackBerry device, when the user logs into the Mobile Client. To set at device level on the BlackBerry device, just check the ‘Disable IM?’ option.

·   Disable IM is also available on the log-in screen on the iPhone client.

 

2.7.6   Policies

 

Policies 1

 

MindLink Mobile Policy Settings

  • Disable Copy and Paste
  • Disable Sender naem in Notifications
  • Disable message Preview in Notifications

Disable Copy and Paste. Ticking this option will disable the ability to use the native copy and paste functionality within the Mindlink Mobile Application. Applying this option will disable copying content from within the application, however, you will still be able to paste from an external source into the chat.

2.7.7   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.

image022.png

Figure 18: Secure Deployment for Android

 

image023.png

Figure 19: Secure Deployment for Blackberry

image024.jpg

Figure 20: Secure Deployment for iPhone 

·   The Management Tool 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 Tool configures the socket service host name as the FQDN of the server. This value is customizable in the Management Tool 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.

 

2.7.8   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 Tool/app config.

image025.png

Figure 21: HTTP Proxy Configuration for Blackberry

image026.png

Figure 22: HTTP Proxy Configuration for Blackberry

image027.png

Figure 23: HTTP Proxy Configuration for iPhone

·   The Challenge Response Proxy URL and File Transfer Proxy URL are configured on the server via the Management Tool/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.

 

2.7.9   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.

Pre-requisites:

  • 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.

2.7.10 Mobile Autodiscovery

As of 17.6 it is possible to have users initialize to the MLM application using an email domain format. This is made possible through the use of CNAME records in a forward lookup zone on your designated DNS server. The record is pointed towards the server hosting the MLM application as the target host. Assuming that the web server certificates have been setup properly i.e. have the DNS alias as an alternative name, then any user can initialize using an email domain format.

Scenario 1: User enters 'test1@testdomain.local' into the server URL field, this will infer the alias FQDN to be, for example, mindlinkdiscover.testdomain.local. This is forwarded to the FQDN of the server hosting the MindLink Mobile application (the target host). User is then brought to the log on screen.

Please note that the host identification web service (as shown in 2.7) will need to be set to port 443 as the alias assumes HTTPS connectivity.

image028.png

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.

 

This section manages the MindLink Foundation API settings.

image029.png

Figure 25a: MindLink Foundation API feature section.

1*Foundation service port number: The port on which to listen for incoming API connections.

2*Use HTTPS: If ticked, the foundation service will be hosted as an HTTPS service, meaning that all data is encrypted between agents and the service.

3*Certificate: The server certificate to use for incoming connections required only when configuring for HTTPS.

4*Authentication mode: select from ntlm, windows or manual modes

5*Super User: A full username (including domain, in the format DOMAIN\user) of the user who will be the “super user”. This user will always be able to access the provisioning functionality of the foundation API, regardless of the user configuration. Other users with access to provisioning functionality can be created using the API itself.

 

image029.png

Figure 25b: MindLink Foundation API disabled modalities

As of 17.3 the MindLink Foundation API has the functionality required to disable the group chat modality. This is contained under the 'general' section of the API management tool.

If IM is disabled for the API then the Active Directory node is disabled. Conversely if it is enabled the Active Directory node becomes enabled.

With IM disabled the app/bot is unable to send a message to a channel that is not valid, thus the channel ID parameter would be invalid hence the bad request that would be subsequently thrown. This is because REST APIs throw errors when the schema isn't met. Please refer to the MindLink API page for a more technical insight.

2.9.1   Windows Authentication

Kerberos operates using “principles” which are identifiers for users and services for which Kerberos tickets can be generated. So that a client can create a ticket readable by a service, it looks up the service principal name and asks the Kerberos server to produce a ticket that can be given to the service. Clearly if the service has no registered principal name, or an incorrect principal name is used (for instance falling back to a default service name) then the ticket will be incorrect and authentication will fail.

Windows integrated authentication can be implemented by running the following command as a domain administrator:

image030.png

Note this only affects Windows Authentication, NTLM does not use SPNs.

 

3   Single Sign-On

Single Sign-On allows a user to log onto related systems once and not have to re-enter their credentials for each system.

Enabling SSO involves the configuring of the adaptor, and may involve extra configuration depending on the type of connector.

For all connectors, the client must be told to connect via SSO by checking the Enable SSO box.

There are two protocols which support Single Sign-On, 1. Windows Authentication and 2. HTTP Header Authentication

 

3.1   Mechanisms

 

3.1.1 Windows Authentication

MindLink Desktop Single Sign-On supports both Windows Integrated Authentication and NTLM mechanisms.

Windows Integrated Auth is supported browsers except Safari. If Kerberos is not available, Single Sign-On automatically resorts to NTLM.

For Kerberos to be supported, the MLA URL must be registered as a Service Principal Name.

 

3.1.2 HTTP Header Authentication

MindLink Desktop Version 3 supports Windows authentication as detailed above. in addition, Version 3 also supports HTTP Header Authentication. Enabling this option allows HTTP headers to be passed to an external authentication module, for example a proxy server. 

Example: User credentials can be read from the relevant attributes within the HTTP header of the user's security certificate. These attributes are then authenticated against an authentication module such as a proxy. Once authenticated successfully, a session is then established.

 

further information on SSO can be found in the Pre-Requisites section found here

4   Creating Trusted Applications

Information on how to configure Trusted Applications cans be found in the Pre-Requisites section found here

5   Group Chat Client Add-Ins

Microsoft Group Chat supports Client Add-Ins. These are special panels that appear below the chat input panel in chat rooms. The system administrator configures which panel appears in which chat room using the Group Chat Administration Tool.

Client Add-Ins are actually web pages hosted inside the Group Chat Console client, which communicate with the parent window using JavaScript.

This table shows in which cases Proxy and Rules are needed according to whether the Add-In is old or new and which browser you are operating from.

image114.png

MindLink MindLink Desktop hosts each Client Add-In inside an Html IFRAME element within the MindLink Desktop page. The Client Add-In can communicate with MindLink Desktop using the same JavaScript calls as in the Group Chat Console client.

However, to enable this communication to happen, both MindLink Desktop and the Client Add-In page must be served from the same domain and port address. This is a standard security requirement enforced by all browsers.

For instance, if MindLink Desktop is served from http://www.MindLink.net/MindLink Desktop, then for any Client Add-In to be shown in MindLink Desktop it must also be served from a relative path on http://www.MindLink.net e.g. http://www.MindLink.net/myclientaddin.

In an enterprise environment, it is often not the case that MindLink Desktop 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 Desktop communication will be forbidden. The use of a reverse-proxy is therefore required to mux requests to MindLink Desktop 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 Desktop 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 Desktop 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 Desktop should then be configured using the add-in re-write rules configuration key, to convert the Add-In’s 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

  • http://addins.MindLink.net/* to the external address of http://MindLink Desktop.MindLink.net/addins/*

     

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

  • http://addins\.MindLink\.net/(.*), http://MindLink Desktop.MindLink.net/addins/$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.

image115.png

 Figure 113: Example proxy and MindLink Desktop 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.

6   High Availability

Here we discuss high-availability strategies for each tier in the MindLink stack, in terms of node failure within a clustered pool.

The MindLink Server may be deployed in a pool configuration to support high availability. This mechanism ensures that there is always a MindLink Server available to service new log on requests.

The administrator should monitor the service health via the HTTP health check service, performance counters, and status of the Windows Service. The load balancer should be configured to maintain the candidate set of nodes by monitoring the HTTP health check service.

Scenario: A MindLink Server node becomes unavailable:

  • Administrative actions:
    • Diagnose the fault and restart the service.
    • The load balancer will remove the node from the candidate node list and redirect new log on requests to the other available servers.
    • When the node recovers the load balancer will begin directing it new log on requests.
  • Desktop/SharePoint user experience:
    • The user will be notified that they have been disconnected from their session and reconnection will be attempted.
    • After failure to reconnect for longer than the configured session timeout interval, the user will be instructed to re-logon.
    • If the node is restarted within the session timeout interval, then the user will be instructed to re-logon immediately.
  • Mobile user experience:
    • The user will be notified that they have become disconnected.
    • The app will continue to attempt to reconnect periodically.
    • The user may close and restart the app, at which point they will be given the choice to continue attempting reconnection or to re-logon to a different node.
    • When the node is restarted, the user will be immediately informed that their session ended and instructed to re-logon.

6.2 Skype for Business

MindLink integration is supported with all SfB highly available pool configurations and load balancing mechanisms.

Scenario: The account’s home frontend server in an Enterprise pool becomes unavailable:

  • Administrative actions:
    • None.
    • New log on requests will be handled by other available frontend nodes.
  • Desktop/SharePoint/Mobile user experience:
    • The user will be notified that their session has ended and instructed to re-log on.
    • On re-logging on, a SfB session will be established on another node in the frontend pool.
  • API behaviour:
    • The agent and channels will become inactive.
    • The agent will attempt to automatically reconnect and eventually become active and re-activate its channels.

Scenario: A server in the Persistent Chat pool becomes unavailable:

  • Administrative actions:
    • None.
    • New log on requests will be handled by other available frontend nodes.
  • Desktop/SharePoint/Mobile user experience:
    • The user will be notified that their session has ended and instructed to re-log on.
    • On re-logging on, a SfB session will be established on another node in the frontend pool.
  • API behaviour:
    • The agent and channels will become inactive.
    • The agent will attempt to automatically reconnect and eventually become active and re-activate its channels.

6.3 Database Layer (Mobile)

MindLink supports SQL Server Mirroring, Clustering and Always-On Availability Groups for high-availability of the SQL database used for deployment of the mobile server in a pool.

Scenario: The database layer becomes unavailable for a single MindLink Server node.

  • Administrative actions:
    • Repair the connection between the MindLink Server and the database.
  • Failover process:
    • The MindLink Server periodically monitors the connectivity to and health of the database layer.
    • When a MindLink Server node identifies that it has not been able to connect to the database layer for a period of time, it will remove itself from the pool:
      • All active user sessions will be terminated.
      • All log on requests will be rejected.
      • The HTTP health check service will report the status as unavailable. The load balancer should then remove it from the candidate node set.
    • When the database layer recovers, the MindLink Server will observe this and begin accepting new log on requests.
  • User experience:
    • Logged on users will have their session removed and will be informed that they need to re log on.
    • The load balancer will redirect the log on request to an available node and they will restart their session on that node.

Scenario: An SQL Server node becomes unavailable:

  • Administrative actions:
    • None.
    • Database queries will be handled by other available database nodes.
  • Failover process:
    • When a node fails, SQL operations may begin to fail and whilst the node is taken out of the cluster (or in the case of mirroring, the connection is failed over to the mirror database).
    • Recovery and reconnection to the healthy pool nodes is automatic and should not result in MindLink outage.
  • User experience:
    • Logged-on users will not experience any outage.
    • Users attempting to log on as the SQL node fails may fail to log on while the node is taken out of the pool.
    • Once the failed node has been automatically taken out of the pool (depending on the HA mechanism), users will be able to log on.

7   Failover

Here we discuss failover strategies for each tier in the MindLink stack, in terms of complete failure of an entire pool in an active/passive DR configuration.

In an active/passive DR deployment, the MindLink Server is deployed with an identical standby pool in another location. In the event of failover of the primary pool, requests from user devices and browsers should be directed to the standby pool.

The configuration of the two pools should be equivalent. For Desktop, SharePoint and Mobile there is no data that needs to be synchronized between pools.

For the API, the provisioned data files (Agents.xml, Users.xml and Throttle.xml) should be periodically copied between sites. A scheduled copy job is sufficient to copy the files between the installation directories of each pool.

The frequency at which this synchronization occurs depends on how frequently changes are made to the provisioned agents, channels, users and throttles. If regular changes are made, synchronization should occur at least once per day.

Scenario: The MindLink pool becomes unavailable

  • Administrative actions:
    • Redirect client requests to the new pool.
    • This can be achieved via DNS, load balancer configuration, or otherwise.
    • The load balanced pool name should be redirected to connect to the new pool.
    • For mobile, the individual names of each server should also be redirected to their equivalent nodes on the failover pool.
  • Desktop/SharePoint user experience:
    • The user will be notified that they have been disconnected from their session and reconnection will be attempted.
    • After failure to reconnect for longer than the configured session timeout interval, the user will be instructed to re-logon.
    • If connections are redirected to the failover pool within the session timeout interval, then the user will be instructed to re-logon immediately.
    • When connections have been redirected to the failover pool, users will be able to re-logon.
  • Mobile user experience:
    • The user will be notified that they have become disconnected.
    • The app will continue to attempt to reconnect periodically.
    • The user may close and restart the app, at which point they will be given the choice to continue attempting reconnection to their old session or to re-logon.
    • When connections have been redirected to the new pool, the user will be immediately informed that their session ended and instructed to re-logon.
  • Failback
    • Connections should be redirected to the primary pool.
    • Users will be notified immediately that their session has ended and they should re-logon.

7.2 Skype for Business

Scenario: The next-hop Skype for Business frontend pool becomes unavailable.

  • Administrative actions:
    • Reconfigure the MindLink Server to use another pool as the next-hop pool.
    • If using manual configuration of the named next-hop pool, this requires setting the name of the failover pool and restarting the MindLink service.
    • If using auto-provisioning:
      • Mobile/Desktop/SharePoint – the SfB DNS auto-discovery records should be changed to point to the failover pool. The MindLink service does not require a restart.
      • API – The new next-hop pool should be changed in the published SfB topology. The topology changes will be replicated to the MindLink server. The MindLink service does not require a restart.
  • Desktop/SharePoint/Mobile user experience:
    • The user will be notified that their session has ended and instructed to re-log on.
    • On re-logging on, a SfB session will be established on another node in the frontend pool.
  • API behaviour:
    • The agent and channels will become inactive.
    • The agent will attempt to automatically reconnect and eventually become active and re-activate its channels.

Scenario: The user’s home Skype for Business frontend pool becomes unavailable.

  • Administrative actions:
    • None. When homed users are moved to their failover pool the MindLink Server will be redirected to the new log on pool by the next-hop pool.
  • Desktop/SharePoint/Mobile user experience:
    • The user will be notified that their session has ended and instructed to re-log on.
    • On re-logging on, a SfB session will be established on another node in the frontend pool.
  • API behaviour:
    • The agent and channels will become inactive.
    • The agent will attempt to automatically reconnect and eventually become active and re-activate its channels.

Scenario: The SfB Persistent Chat Pool becomes unavailable:

SfB persistent chat supports a stretched-pool configuration for DR. As such, recovery of services in at least one site should be the administrative priority.

If the persistent chat pool fails, users will be notified of session disconnection and unable to log on until services are restored.

7.3 Database Layer (Mobile)

Scenario: The database layer becomes unavailable.

  • Administrative actions:
    • Configure the MindLink Server to connect to a new database via the Management Center.
    • Restart the MindLink Server.
  • Failover process:
    • The MindLink Server periodically monitors the connectivity to and health of the database layer.
    • When a MindLink Server node identifies that it has not been able to connect to the database layer for a period of time, it will remove itself from the pool.
    • It will terminate all user sessions and refuse future log ons.
  • User experience:
    • Logged on users will have their session removed and will be informed that they need to re-log on.
    • Once the database has been reconfigured and services restarted, users will be able to re-log on.

8   MAM and MDM Deployment

Configuration and Deployment Information can be found here

9   Enabling Conversation History

Enabling Conversation History can be found in our Pre-Requisites section here

10 SfBO

As of MindLink 17.7 it is now possible to deploy an IM only installation of MLM and MLD against Skype for Business Online (SfBO) and your O365 tenancy. The following will run through the necessary steps required to successfully deploy an MLM/MLD instance against SfBO.

10.1 Configuring the application against Azure Active Directory

Under your organisations Azure AD portal, click on 'App Registrations' as shown below. From here click on 'Create'. Following this ensure you register with some memorable details in the fields presented. This acts as the MindLink registration against Azure. This will be thus allocated permissions to access SfBO.

image137.png

By default MLD and MLM are configured to work against the UCMA platform and thus to make these products work against your O365 tenancy you will need to make a few changes. All of which will be discussed in the following.

In order to more conveniently change the connection type from UCMA over to SfBO you will want to start by navigating to the installation directory of the MindLink product you wish to configure i.e. 'C:\Program Files\MindLink Software\MindLink Desktop\ManagementTool'. From here go to the 'Management Tool' folder. This is where the 'SkypeForBusinessConfigurationModule' resides, this Powershell Module allows you to load and connect an instance of SfBO that is linked to your O365 tenancy.

image138.png

image139.png

10.3 Enabling the connector

As shown in the above, once the powershell module has been loaded, you will want to enable the connector by passing the following argument 'Enable-mlsfboconnector'. Once you have done this you will be presented with the relevant variables that can be changed to match your tenancy details.

11   Bibliography

1.       Microsoft. Enterprise Library Logging Application Block. Online http://msdn.microsoft.com/en-us/library/cc511708.aspx.