# Flow Through Provisioning - Conditions and Limitations

Refer to the MiCollab Installation and Maintenance Guide for instructions on how to configure Flow Through Provisioning.

## General

- Flow Through Provisioning is only supported between MiCollab systems and MiVoice Business platforms.

- Flow Through Provisioning is not supported for co-located mode.

- MiCollab Release 7.0 or later is required.

- MiVoice Business Release 7.2 or later is required.

- If MiCollab Client is in co-located mode and you start sharing, then MiCollab Client must remain in co-located mode. You cannot put MiCollab Client in integrated mode after sharing has been started.

- Flow Through Provisioning is only supported from one MiCollab system. It is not supported for multiple MiCollab systems in the same SDS sharing network. You can only include one MiCollab system to share within a SDS sharing network.

- If MiCollab is managing a group of MiVoice Business systems, they must be configured within an SDS sharing cluster. All the MiVoice Business servers in the cluster must be at Release 7.2 or later.

- Flow Through Provisioning must be enabled (started) either from the Mitel Integrated Configuration wizard or manually from a MiVoice Business platform in the administration group of the cluster.

- The USP application allows you to manage the local MiCollab application services and the remote MiVoice Business phone services.

- The recommended best practice is to always manage (add, edit, and delete) users from the MiCollab Users and Services application. You can manage users from the MiVoice Business Users and Services Configuration form and the updates will be shared with MiCollab. However, if you add, edit or delete a user from the Telephone Directory form the update is not shared with MiCollab.

- If you create a user with System Admin or Root access in the MiVoice Business User Authorization form, the user is not shared with the MiCollab Users and Services database.

- The MiCollab USP database lists all the users in the MiVoice Business network. The USP application identifies the host network elements for extensions in the Phone tab and application services tabs. For example: 3001 (on Local_30) where extension 3001 is hosted on network element Local_30.

- A maximum of three phones are supported in a shared MiCollab template. You cannot use a template that is programmed with more than three phones.

- If resiliency is configured for a MiVoice Business solution, data updates are sent from MiCollab to the primary controller. If the primary controller is out of service, the MiCollab USP application does not provide data updates to the secondary controller. Instead, an error message is presented in MiCollab indicating that the primary controller cannot be reached.

- Synchronization is bidirectional. Changes made to users, phones, templates, multi-device user groups, and personal ring groups in any remote MiVoice Business element in the sharing network are reflected in the MiCollab server's USP entry.

- The synchronization of MiVoice Business elements with MiCollab takes substantially longer than the synchronization of just MiVoice Business element form data.

- If Flow Through Provisioning is enabled, IDS Integration must be enabled from MiCollab to Active Directory, not from MiVoice Business to Active Directory.

- MiVoice Business allows you to associate multiple users with the same directory number; however, MiCollab does not support this functionality. If you associate multiple users with the same directory number from the MiVoice Business User and Services Configuration form, the association is not shown in the MiCollab Users and Services application. The following SDS Distribution Error is also generated: “Cannot associate more than one user to the same phone service”.

## Topology

- You control the sharing topology of the solution from the following System Data Synchronization (SDS) forms in the MiVoice Business System Administration Tool:

  - Network Elements

  - Cluster Elements

  - Admin Groups

  - SDS Forms Comparison

  - SDS Form Sharing.

The system verifies the topology as part of the Start Sharing process with a MiCollab server. If the topology is invalid, the system displays an error message indicating that start sharing failed or cannot be started, you will need to correct the issue and try again. The MiVoice Business software will not allow the topology to become invalid after sharing has been started with MiCollab.

- Sharing is only supported to one cluster. It is not possible to start sharing with MiCollab from an SDS network which contains more than one MiVoice Business cluster. However, you do not have to have a cluster defined. MiCollab can perform flow through provisioning to a single MiVoice Business; however, if there are multiple MiVoice Business elements in the network which are hosting phone services, you must create a cluster before flow through provisioning can be used to manage all the MiVoice Business systems.

- All MiVoice Business controllers must be active and reachable from MiCollab when sharing is started. It is not possible to create phone services on a MiVoice Business controller which is offline. Flow through provisioning does not fall back to the resilient controller.

- You can configure how data is shared among the MiVoice Business elements using the ‘SDS Form Sharing’ form in the MiVoice Business System Administration Tool However, the flow through provisioning feature requires specific MiVoice Business forms to be shared with MiCollab, so you cannot remove sharing from these forms, nor can you share them at a scope which MiCollab cannot participate in. These restrictions are enforced by MiVoice Business. MiVoice Business will not allow ‘Start Sharing’ with MiCollab if an invalid sharing scope is currently selected. And, after sharing has started with MiCollab, MiVoice Business will not allow you to select an invalid sharing scope.

- The simplest supported configuration is one MiCollab server and one MiVoice Business server in a single (default) administration group with no cluster defined. If there is no cluster defined, MiCollab only shares its data with the MiVoice Business server that started sharing with MiCollab. Flow Through Provisioning is not offered to other MiVoice Business servers in this configuration even if they are included in the local administration group.

- To support Flow Through Provisioning to multiple MiVoice Business servers, a cluster must be defined. Only a single cluster is supported. MiVoice Business will not allow ‘Start Sharing’ with MiCollab if there are multiple clusters. After sharing has started with MiCollab, MiVoice Business will disallow the creation of a second cluster.

- You can use Admin groups to limit the sharing of data between selected network elements. If there are multiple MiCollab servers in an SDS network they must be placed into different Admin groups. MiVoice Business will not allow ‘Start Sharing’ to a new MiCollab server if there is already a MiCollab server in the admin group. In addition, Roles and Templates must be shared at admin group scope.After sharing has started with MiCollab, MiVoice Business will disallow a 2nd MiCollab to be added to an existing admin group which contains a MiCollab server and will disallow changing the sharing scope of Roles and Templates to ‘All Network Elements.

- To avoid role and template conflicts, it is recommended that you segregate the MiVoice Business servers into separate administration groups and change the sharing scope of roles and user templates to "Admin Group" before you start sharing with thefirstMiCollab server.

- Ensure that all MiVoice Business elements in the sharing network are configured with an IP address or FQDN. MiCollab will not support a network element unless it is provisioned with an IP address or FQDN. If a MiVoice Business element is provisioned in the network without an IP address or FQDN then sharing with MiCollab cannot be established. The Start Sharing operation will fail with a message to check the MiCollab logs.

- A MiVoice Business server should not be moved from an Admin Group that contains a MiCollab server to an Admin Group containing a different MiCollab server, otherwise; roles and templates learned in the first administration group may conflict with roles and templates in the second cluster.

## Departments

- Departments and Locations are shared by default at the network scope, although you can narrow down the scope to just the Admin Group in the ‘Shared Forms Configuration’ form in MiVoice Business System Administration Tool.

- If you delete a department from MiCollab, the department is also removed from the user entries. If Flow Through Provisioning is enabled to MiVoice Business elements, the department is also removed from the MiVoice Business Department form and user entries. However, the behavior on the MiVoice Business is slightly different. Before you can delete a department from the MiVoice Business Department form, you must first remove all references to that department name from the MiVoice Business user entries. After you delete a department from the MiVoice Business, the department is also removed from MiCollab if Flow Through Provisioning is enabled.

## Roles and Templates

- A shared template definition is used to create phone services. Flow Through Provisioning is only able to offer the ability to create phone services on MiVoice Business servers which are sharing role and template data.

- Role and template data is shared among the MiCollab server and the MiVoice Business servers in the same Admin Group. Role and template data is not shared with other MiCollab servers (only one MiCollab server is allowed in an Admin Group). Roles and templates are merged during the synchronization process and may need to be reconciled.

- Templates can be added by either copying an existing template (in the Edit Template page) or by adding a new template. You can edit templates either in USP or MiVoice Business System Administration Tool and the changes are shared. You need to refresh the form to see changes that were made on a remote network element.

- If MiVoice Businesswas upgraded from Release 6.0, there may be legacy templates in the database. These templates will not be imported into MiCollab and will not appear in MiCollab USP. If you attempt to create a new template with the same name as a legacy template, an error is presented.

- USP can manage all the service components within a user and service template, but only a subset of the fields which are offered in the MiVoice Business System Administration forms are available in USP. Use Reach Through to manage the complete phone service template on the MiVoice Business (for example, to edit feature key templates).

## Users and Services

- Create users from MiCollab USP using pre-defined roles and templates. Do not create users from the MiVoice Business servers.

- The USP directory only displays phones that are assigned to users. However, the MiVoice Business supports phones that do not have users associated with them. To manage these phones from USP, add a new user to the phone or associate a user with the phone in the MiVoice Business User and Services Configuration form. After you assign a user to the phone, the user and phone will appear in the USP directory and you can add services to the user.

- You cannot assign DNIC or analog phone services to users from USP. However, DNIC or analog phones that have been created on the MiVoice Business system administration tool are displayed in the USP directory and can be modified or deleted.

- The USP directory does not list the following MiVoice Business directory numbers:

  - Phones that are not associated with users

  - Directory numbers that are associated with line appearances on feature keys

  - Local-only phones

  - Directory numbers that are used in certain types of hunt groups.

- It is only possible to manage multi-line MiNET and SIP devices. Single line, DNIC and analog devices cannot be created from the Users and Services application and are not listed in the directory. The same is true for other types of service such as traditional ACD agents, IP consoles, non-prime broadcast groups, and so forth.

- The Users and Services application does not manage phones which are not associated with a user.

- You can assign the "Phantom" Device Type to any MiCollab entries that you do not want shared or synchronized with the MiVoice Business via Flow Through Provisioning. For example, you could assign a "Phantom" device to

  - a mailbox-only entry to allow the mailbox number to be located in the USP directory using the Search feature.

  - an entry that is programmed in the MiVoice Business database as a system speed call, non-prime broadcast group, or console.

## Fully Qualified Domain Name (FQDN) for Cloud Deployments

The following Domain Name Server (DNS) configurations are possible in Cloud solution deployments:

- MiVoice Business server may or may not be resolvable in DNS.

- MiCollab server may or may not be resolvable in DNS.

- Any of the servers which make up the solution may resolve to a different IP address inside the LAN versus out in the WAN/cloud (split DNS).

- Any of the servers may not resolve internally, but may resolve externally (partial DNS).

- Mitel Standard Linux operating system can be configured to use a corporate (external) DNS server.

The following conditions apply to programming FQDN(s):

- When MiCollab is initially deployed, the IP address that you enter for the local (LAN) interface is added to the network element in the Network Element list. The FQDN field is initially blank.

- Enter the FQDN for the MiCollab server at any time by editing the local network element in the Network Element page. The FQDN can be the same as the host name and domain that is entered in MiCollab server console or it may be a different FQDN which is only resolvable externally.

- After Mitel Integrated Configuration Wizard adds MiVoice Business servers to the MiCollab server, you must provide the IP address. You can also provide an FQDN. This is also the case when you add MiVoice Business servers to the network.

Note: The host name and domain entered during server commissioning may not be resolvable anywhere except inside the MSL system. For this reason, the MiCollab server will not attempt to reverse-DNS in order to ‘automatically’ detect FQDNs.