Data Synchronizer Mobility Pack Best Practices

From CoolSolutionsWiki

This page was last modified on 04/24/2013

This wiki details some of the best practices and user stories for administering Novell Data Synchronizer Mobility Pack.

Many useful topics may be missing or incomplete. Please help out by contributing relevant topics and information.

Data Synchronizer Mobility Connector

Contents


I am about to Install

Planning Considerations

Users. Number of users. How many and which of your users will use Data Synchronizer? Clarifying this initially will make things easier on you as you proceed with the Install and post-install configuration.

Devices. What types of devices and phone do your users have? Some of your settings may vary depending on which devices you are supported. WinMobile devices, for example, need a certificate from a Trusted Authority, whereas Apple or Android devices are more flexible.

Certificate. Do I need a trusted root certificate? How do I go about doing that? Which ones are supported?

Groups. Adding users in groups is superior to adding them individually. How big should the groups be? Should I add the groups during the install and after the install?

Database. Don't reuse an existing database. Have a standalone Data Synchronizer server with a standalone database.

Certificates

Used a Trusted Authority. Best practice is to use a certificate signed by the trusted authority. Most devices require a .pem certificate file, but WinMobile devices require a .cer file. Make sure you have both.

Further Reading: http://openssl.org and Configuring Self-Signed Certificate

Configuration

Blocking Devices. Check “Block Devices” during the Yast install if you are updating the systems until the system is up and running completely. This will prevent devices from connecting while the system is down.

I want to monitor performance and troubleshoot

Initial Sync

An initial sync is performed for all users regardless of whether or not they have added their account to any devices. The initial sync is when the database is populated with GroupWise events. A typical initial sync for a user will last about 3-5 minutes. Depending on how much content a user has, the initial sync can take up to an hour. Overall averages tend to be about 8 minutes per user (50 users would take approximately 6 1/2 hours for the initial sync to complete.

Connector Monitoring

Monitoring Page. The Mobility Connector has a monitoring page that includes information on events, users, and devices. Use this page to monitor performance on a system-wide or user-specific level:

  • The Mobility Status portion shows system-wide stats for events
  • For each user you will see the devices that are being used by that user.
  • Clicking on a user will open up a user-specific summary and shows sums for events by event type.

User Actions. On the monitoring page, there are icons for actions to be performed for a particular user:

  • Re-initialize user (blue arrow under the "Actions" column): This pulls down the information for the user from GroupWise and into the database manually.
  • Resync device (blue arrow under the "Device" column): This resends all of the events to the phone by manually sending all the information for the user from the database to the Mobility connector.
  • Delete device (Red X):
  • Reset device (gray crossed-out circle): Resets device to factory settings. Use this sparingly as the user will lose data and may have to reactive the phone manually.

Logging

Log Settings. For more detailed logging, change the log settings to Debug - Verbose in the Connector Settings page. Activate diagnostic logging by clicking on "Edit XML Source" in the same page and replacing <verbose>on</verbose> with <verbose>diagnostic</verbose. Unless you're troubleshooting, you can keep diagnostic off to keep your logs from becoming excessively large.

Log Files. Log files for Data Synchronizer are located in /var/log/datasync/ The connector directory has logs for installed connectors.

Using Log Files. The log files can be used to verify activity. For example, to verify that a particular user is making contact with the system you can check the mobility-appInterface log file. If you don't see the user there, then the user's device could have issues like no wifi connection or outside the firewall, etc. There are also many ways to use the log files to monitor performance and troubleshooting. Here are some useful commands:

  • tail -f [logfile] // This will display changes as they occur to the log
  • tail -f default.pipeline1.mobility-AppInterface.log | grep "Idle Threads" //checks for active device threads
  • tail -f ../syncengine/engine.log | grep -i queue // checks for THREADPOOL and pending queue
  • tail -f default.pipeline1.groupwise-AppInterface.log | grep queue // counts poa slaps -- 1 to 250 items for a user.
  • grep "Received event from GroupWise" default.pipeline1.groupwise-AppInterface.log // type of items coming from GroupWise
  • grep "queue" default.pipeline1.groupwise-AppInterface.log // queue of tasks waiting to be synced. Each task represents a collection of events, so a queue with 1 task could represent 100 events. This same grep command can be done for the sync engine log too.
  • You can grep an entire log and export it to a csv file and graph variables such as performance for a visual model. You can then link things like spikes in queue size or wait time to other events (like adding 50 users to the system, etc.)

Tools. There are three tools in the /opt/novell/datasync/tools directory: CollectLogs.pyc, traceLog.pyc, and trackTime.pyc. These tools draw upon the Data Synchronizer log files to track events, errors, and performance.

Database

Caution. It is not recommend to access the databases because it can be very easy to break something. Rather than using the database for troubleshooting and monitoring, rely on the Connector Monitoring and log files.

Good and Bad Habits

Users and Groups

Adding Users. It is normally preferable to add large amounts of users in the form of groups. When adding users:

  • Add users to the GroupWise Connector first, then the Mobility Connector.
  • It can take some time for the users to actually be added. After adding a group to the UI, give it some time.
  • Only add users that will use Mobility Pack. Even if an added user doesn't use Mobility, their events will still be processed and this will slow down the system.
  • If a user isn't going to be using a specific phone anymore, have him/her remove the account from his/her device. This will lessen the workload.

Using Groups. If you provision users via a group, it will save time and workload. Things to consider:

  • The LDAP polling does not impact the LDAP server much, as it only checks the one group defined for changes, and only at the interval specified.
  • When a user is added through a group, the application name is set by default to the LDAP CN. You may want to consider a requirement that the GroupWise Object ID and CN match before adding the user. It will allow user provisioning without a Data Synchronizer admin override of the application name.

Database

Warning. Do not go into the database and perform manual operations. This is a recipe for disaster.

Maintenance. Perform regular postgreSQL database maintenance. See http://www.postgresql.org/docs/8.3/interactive/maintenance.html

Misc.

  • When restarting connectors, start the GroupWise Connector first.