# SDS Sharing Groups - Definition of Classifications

The following table outlines the data that is shared or synchronized for each of the form groups in the SDS Form Sharing form.

Group Classification | Purpose
General System | Shares the selected form data among the cluster elements at the specified scope. By sharing these forms, you can keep the data the same on all the cluster elements in the data sharing community. If an administrator makes a programming change to one of the shared forms on an element, SDS updates the databases of the other cluster elements that belong to that sharing community. For Hunt Groups and Ring Groups, SDS shares the data in the respective Group Assignment form and the group membership data with the resilient peer. You can configure the system to support both hunt and ring group resiliency. Then, if the primary controller goes out of service, the resilient groups and resilient group members fail over to the secondary controller and are able to answer the incoming calls to the group pilot number. Refer to Resiliency Guidelines for hunt group and ring group resiliency configuration. For Clustered Pickup Groups, SDS shares the call pickup group data and group membership data among all the cluster elements on which the group members reside. Therefore, if you add or delete a member from a clustered pickup group, SDS updates all the elements that host that pickup group with the change in membership.
Trunk - Links
ARS
Device Level Call Handling
System Level Call Handling
SNMP
User
ACD | Shares the data in the ACD Agent forms and the agent skill group membership data with the resilient peer. You can configure the system to support ACD resiliency. Then, if the primary controller goes out of service, the resilient agents and resilient agent skill groups fail over to the secondary controller and are able to process the incoming ACD calls. Refer to Resiliency Guidelines for ACD resiliency configuration.
Service Hosting Data | Shares the information related to hosting of phone services and group features such as hunt groups, ring groups, and agent skill groups and so forth. This data is distributed at the Network scope by default, but may be shared at smaller scopes such as All 3300 ICPs, Cluster, or Admin Group. The RDNs displayed in the Remote Directory Number forms of the network elements are distributed indirectly via the Service Hosting Data.
Device Level Resiliency - Administrator Managed Data - Device and User Data | Shares the device and user data for resilient devices from the listed forms to the resilient peer controller. This group classification also shares the CESID assignment data and voice mailbox configuration data of resilient devices with the resilient peer controller. For example, if you change the CESID data for a resilient device while on the primary controller, SDS updates the device's secondary controller with the CESID data. Then if the primary controller fails and the device homes to the secondary, the secondary controller will have the latest CESID data for the device. For voice mailboxes, SDS shares the data from the VM Mailboxes or User and Services Configuration form (mailbox number, name, extension number, and mailbox type) for resilient devices with the resilient peer controller. SDS does not share voice mail box greetings. Users must program their greetings on both the primary and secondary controller. Also, if a user changes his or her passcode through the telephone user interface, SDS does not update the resilient peer with the new code.
Device Level Resiliency - Administrator Managed Data - User Managed Data | Allows you to share the data in the Multi-Level Auto Attendants form between resilient peers. The lower portion of the Multiline Set Keys form lists the softkey programming for devices. SDS shares the feature key ( softkey) assignment for resilient devices with the resilient peer. For example, if a user programs a Redial feature key on a set, SDS distributes the key to the resilient peer. However, a number programmed for a resilient key is not shared. After a failover from the primary controller, the Redial key would appear on the secondary controller, but the last number dialed on the primary controller will not be available to the user on the secondary.
User Call Handling Data | Allows you to share the Auto Answer, DND, and Make Busy status of resilient sets between their resilient peer controllers. Then, if the primary controller fails, the status of these features is maintained when the set fails over to the secondary. For example, if Do Not Disturb is activated on a resilient set and the set fails over to the secondary, the Do Not Disturb feature will be activated on the secondary controller.
High End Set Data | Allows you to share the phone configuration settings that are available under the Applications shutter of resilient 5235 IP Phones with the resilient peer controllers. If the user's resilient 5235 IP Phone fails over, the 5235 IP Phone applications will have the same settings on the secondary controller. Likewise, when a user's 5235 IP Phone fails back to the primary controller, SDS updates the database of the primary controller with any application configuration changes that the user made while on the secondary controller. You cannot share all 5235 IP Phone programmable keys, such as the DND key, by sharing High End Set Data. To share all 5235 IP Phone programmable keys, you must also share the Multiline Set Keys form. NOTE: The 5235 IP Phone is no longer supported as of MiVoice Business Release 8.0.
Hospitality | Shares the selected form data among the clustered hospitality elements at the specified scope. By sharing these forms, you can keep the data the same on all the cluster elements in the data sharing community. If an administrator makes a programming change to one of the shared forms on an element, SDS updates the databases of the other cluster elements that belong to that sharing community.
System Maintenance | Shares the external FTP server settings among the elements in an SDS Administrative Group.
Templates | Shares the User Role and template data. In a network of mixed releases, MiVoice Business (MiVB) Release 7.0 templates are shared only with MiVB 7.0 and up systems. However, Pre-7.0 (MCD 5.x and 6.x) templates are shared with and visible on all nodes (5.x, 6.x, 7.x and up). Once shared, a pre-7.0 template can be modified on a 7.x system (within its limitations, such as, one phone service per user) and still remain compatible with pre-7.0 systems. When a pre-7.0 template is copied on a 7.x system, the new copy becomes a 7.x template and is no longer shared with pre-7.0 systems. User Roles associated with the Default or a pre-Release 7.0 template are shared with all nodes (MiVB Release 7.x, 6.x, and 5.x). Roles associated with 7.0 templates are NOT shared with the older systems, which do not support 7.0 templates. MiVB 7.x User and Service Template can only use 7.x Key Template; however, the Default Key Template can be used for both 7.x User and Service Templates and pre-7.0 User and Device Templates.
Templates (Pre-7.0)
Integrated Directory Service | Allows you to share the user and service data synchronized between a corporate directory server and the MiVoice Business Integrated Directory Service (IDS) application.
Application Group Licensing | Shares the licensing information among the members in an Application Group Refers to two or more MiVoice Business systems that are grouped into a single entity at the Mitel Application Management Center for licensing purposes..

Related Topics

- What Data Can Be Shared?

- SDS Form Sharing

- About System Data Synchronization

- About Synchronizing User and Device Data