SDS - Troubleshooting Sharing Operations

Symptom	Probable Cause	Solution
The Start Sharing operation has not displayed any signs of progress for more than an hour (that is the operation appears to be hung).	Your Internet Explorer session is timing out before the Start Sharing operation is complete.	Install the required Internet Explorer registry file on your PC. The registry file extends your Internet Explorer session and prevents it from timing out before a Start Sharing is complete. Refer to Mitel Knowledge Base article 07-3829-00006 on Mitel Online for instructions.
Cannot start sharing with an element	SDS is not enabled on the remote element.	Ensure SDS is enabled in the System Options form of the remote element.
Cannot start sharing with an element	Remote element not included in data sharing community.	Ensure that the remote (slave) element has been brought into the data sharing community. See Start Sharing with a New Element for instructions. You must always bring a new element into an existing data sharing community from an element that is already in the data sharing community.
"Data Sharing" alarms are appearing	A minor system alarm is generated whenever an SDS data distribution error occurs.	Resolve the distribution error in the Shared Data Update form. See Resolving Pending Updates or Errors
Data sharing forms not appearing in System Administration menu.	SDS is not enabled on the local element.	Ensure SDS is enabled in the System Options form of the local element.
	Form is not configured as shared.	Configure the form to be shared in the SDS Form Sharing form. See Specifying the Shared Data.
	Shared form icon does not appear beside form name in System Tool Administration menu.	After you configure forms as shared, you must log out and log back into the System Administration Tool to see the Shared form icons.
Data not being shared	Data sharing status of remote element is set to "No".	You must start sharing with the remote element. See Start Sharing Data.
	Scope of sharing is not set correctly.	Set the scope of the sharing. See Identifying the Shared Data.
	Specific forms are not set as shared.	Ensure that the required forms are set to be shared. See Identifying the Shared Data.
	Forms are set as shared but you have not started sharing with the element(s) yet at the corresponding scope.	Use the Start Sharing button in the SDS Form Sharing form to initiate sharing.
Record exception is not working as expected	Record exception rules are not entered correctly.	Check to ensure that you have entered exception rules correctly. See Specifying the Shared Data
Unexpected application errors are being generated on the local element.	The system dimensions are not set the same across the elements. For example, one system supports 96 Classes of Service, the other element supports only 64 COS. The mismatch results in application errors.	Delete the errors and exclude the additional records from being shared. See Specifying the Shared Data.
Data Sharing status for the element is not consistent with all the other SDS elements in the data sharing network even after you perform a sync operation. That is, the other elements indicate in their Network Elements forms that they are sharing with the element, but data is not actually being shared.	You restored an old database that had SDS disabled.	To resolve this issue: At the element at which SDS is off (element A). Turn SDS on and then back off again. Perform a Start Sharing operation from another SDS element (element B) in the data sharing community with element A. Perform a Sync operation from element B to element A to update any data that may be out of sync on element A.
	You disabled SDS while the element was disconnected from the network.	To resolve this issue: At the element at which SDS is off (element A). Turn SDS on again. Perform a Sync operation from another SDS element (element B) in the data sharing community with element A. Do not share any forms. Disable SDS at element A while it is connected to the network.
Unexpected transport errors are being generated at the local element.	The network connection between the elements is down resulting in transport errors.	Fix network issue and retry update errors.
"Data Sharing Mismatch" errors are being generated at the local element in the SDS Shared Data Updates form.	A record has been updated on local element and sent to a remote (slave) element. The slave element has rejected the update because the slave's sharing status is out of sync with the local element (that is, the slave does not recognize that it should be sharing with the local element).	If you want the slave element to accept updates from the local element, perform a sync operation from the local element with the slave. If you want to stop sharing data with the slave element, perform a sync operation from the local element with the slave and then disable SDS at the slave element.
Unexpected "Concurrent Change Rejected" errors are being generated at the local element in the SDS Shared Data Updates form.	"Concurrent Change Rejected" errors were created because during a network outage changes were made on individual elements.	Fix network issue and retry update errors.
	The shared data has different default settings because the system Country variants (set in the License and Option Selection form) are different on the master and remote elements.	Accept the values using the Force Change option, or do not share this data.
Resilient user and device data is not being shared after you upgraded the controllers to Release 7.0 software or higher.	By default, user and device data is not shared. You must first specify the resilient user and device data that you want to be shared with the secondary elements.	Specify the resilient user and device data that you want to be shared with the secondary elements.
	Version of the remote peer has not been updated on the local controller	Perform a synchronization from the local element to the remote peer.
Data for some fields are not being shared.	If a Release 7.0 or later SDS-enabled controller is communicating with a Release 6.x SDS-enabled controller, only the forms that are supported by the Release 6.x SDS will be shared. User and device resiliency data will not be shared to the Release 6.x controller.	Upgrade the controller to the higher software level.
In the SDS Form Sharing form, some record restrictions appear as "Not supported in this Release".	If you share the SDS Form Sharing form from a Release 7.0 controller to a controller running an earlier software release (from Release 6.1 UR2 to pre-Release 7.0) any new Release 7.0 fields that are not supported on the older software release are displayed as "Not supported in this Release" on the controller with the older software.	Upgrade the controller to the higher software level.
In the SDS Form Sharing form of a controller that has pre-Release 6.1 UR2 software, some record restrictions are incorrectly displayed as "Account Code".	If you share the SDS Form Sharing form from a Release 7.0 or later controller among controllers that have pre-Release 6.1 UR2 software, restrictions in the Feature Access Codes form may appear incorrectly. If you restrict sharing of the Call Park and Call Park Retrieve fields from the Release 7.0 system, these restrictions are incorrectly displayed as "Account Code" on the controllers with the older software.	Upgrade the controller to the higher software level.
Errors show that data has been distributed to a network element in a way that is not consistent with the data in the Remote Directory Numbers form.
	Inconsistent entries are appearing in the RDN forms of the elements.	See Correcting Inconsistent RDNs
On 5235 IP Phones, some application keys that are programmed on the set (for example, the History key) do not function after the set fails over or fails back from the resilient peer controller.	The Multiline Set Keys form data is shared, but the High End Set data is not shared.	In the SDS Form Sharing form, share both the Multiline Set Keys form data and the High End Set data. SDS will then share the application set key data. Instruct the 5235 IP Phone users to reprogram the application keys on their sets.
A 5235 IP Phone user is unable to reprogram or clear a programmable key.	In the Multiline Set Keys form, the"Line type" for the key is stuck at "phone app".	In the Multiline Set Keys form change the "line type" for the key to "NotAssigned". The user can then reprogram the key.
Errors show that login status for a hot desk user has been improperly shared between the user's primary and secondary ICP.	A failover occurred between the time the user logged in from one device and then another. For example, an external hot desk user logs in from their cell phone, there's a failover, and before a failback can occur, they log into from their office desk phone.	Perform a synchronization from the local element to the remote peer.
There are many shared data updates occurring on the department/location forms. Doing an SDS Form Comparison results in conflicts for department/location A change to the department field is not distribute throughout the network or cluster.	In a heavily congested clustered hospitality deployment, if there are a many hospitality operations being performed at the same time (either via PMS or GSA or a combination of both), then there is the possibility that department/location operations may result in shared data updates.	Perform an SDS synchronization of the department/location forms. This will update all users that reference the department/location fields with the new department/location strings.