Calendar Sync Overview
Add2Exchange has many uses for Exchange, Outlook & mobile device users. Add2Exchange is ideal for managers who need a “master” calendar for all users/employees in their organization. Users and Management can instantly see a composite schedule of their entire organization at a glance. Managers can also use Add2Exchange for any scheduling performed by their assistant. By synchronizing calendars, your assistant will only need to check one calendar to see all users' availability at all times. For mobile professionals, Add2Exchange can sync public calendar items to a private calendar so they can be synchronized to a PDA or Pocket PC like iPAQ or a Blackberry and even Treo Smartphones.
Add2Exchange for Calendars is great for organizations who have a public calendar and want it populated with private calendar items automatically. Add2Exchange can also be used for resource scheduling as well as vacation scheduling and departmental group calendars without any extra effort by the users.
Contact Sync Overview
Add2Exchange for Contacts is an Outlook contact synchronization solution which can replicate and synchronize Outlook contacts between private and public folders. With Add2Exchange for Contacts, your business can easily share the Outlook contacts which you designate by setting up relationships between contact folders during installation.
Task Sync Overview
Add2Exchange for Tasks is an Exchange Add-on, Outlook task sync solution which synchronizes any combination of Outlook tasks- private (mailbox) and public (group). Add2Exchange for Tasks was created for Outlook and Exchange users who want to collaborate on tasks and to be able to sync their public tasks to their private (or vise versa) so they can view them on their PDAs. In addition, Add2Exchange for Tasks can greatly benefit managers and users by dramatically reducing labor intensive copying and pasting and, therefore, enable knowledge workers to focus more on the tasks at hand.
The Need for Synchronization: 5 Ideal Situations
Ideal for Mobile Device Users - Public to Private Outlook Calendar, Contact & Task Folder Sync
Managers and users can place an item or entry in a public folder which then gets copied to each users private (mailbox) folder without acceptances. Automatically!
- Create this type of relationship if your company or client needs to access public Outlook appointments, contacts or tasks (which reside on Exchange public folders) from their PDAs, Smartphones, BlackBerry handhelds, Pocket PCs or any other mobile device while in the field.
- This type of relationship is usually built One-to-Many but can also be built One-to-One.
Ideal for Managers- Private to Public Outlook Calendar, Contact & Task Folder Sync
Managers can have a centralized view of the entire organization or team. Automatically!
- Create this type of relationship if your company or client needs their Outlook calendars, contacts and tasks residing on their mobile devices to be accessed by others who use Exchange public folders at the office.
- This type of relationship is usually built Many-to-One but can be built One-to-One or One-to-Many.
Ideal for Teams or Administrative Assistants- Private to Private Outlook Calendar, Contact & Task Folder Sync
Managers and assistants or team leaders/schedulers and team members can have access to the same information and update it anywhere.
- Create this type of relationship if your company or client has a team of people who need to know each other's individual schedules, share contacts and share tasks.
- This type of relationship is usually built One-to-One but can be built One-to-Many or Many-to-One
Ideal for Managers and Administration- Public to Public Outlook Calendar, Contact & Task Folder Sync
Managers, team leaders, and schedulers can have access to consolidated information of entire departments or special function calendars, contacts and tasks
- Create this type of relationship if your company or client has management who need a consolidated folder from individual public folders
- This type of relationship can be built One-to-One or One-to-Many or Many-to-One
Folder Relationship Fundamentals
Add2Exchange is a folder synchronization tool. It copies the contents of one folder to another, then periodically determines whether changes to the source folder have occurred and synchronizes those changes.
Relationships may be built between any combination of folders in the public folder store and private mailbox stores, provided that the folders contain the same type of items (e.g. contacts).
Add2Exchange can synchronize calender events (one-time and recurring), contacts, distributions lists
Relationships synchronize only the contents of the specified source and destination folders and do not synchronize the contents of subfolders. Synchronization of subfolders requires a separate relationship.
Folders in an active relationship are referred to as active folders. Items created by regular users (i.e., not created by a relationship) in the active folders are called originating items or originals. Items created by relationships are called either copies or replicas.
Items that are subject to a relationship include both originating items in the source folder as well as the replicas in the destination folder. The relationship monitors these items for changes.
Items that originate in the destination folder are NOT subject to the relationship. For example, contacts in a destination folder prior to a relationship being set up are not subject to the relationship. A relationship does not monitor those items that it did not itself create in a destination folder, nor does it copy those items to the source folder.
In the following example, two folders both containing original items are made subject to a relationship. The source is the public folder on left side with blue contacts and the destination is a contacts folder in a user's mailbox with pre-existing yellow contacts. After synchronization, the user's folder contains the both the original yellow contacts and replicas of the blue contacts from the public folder. However, only the blue contacts are subject to the relationship, since the yellow contacts are the original items in a destination folder. The relationship will not monitor yellow contacts for changes, nor will they be copied to the public folder.
|
Original contacts in source (left) and destination (right)
|
Blue contacts are subject to the relationship and are copied.
|
Yellow contacts are not subject to the relationship.
|
Triggers and Settings
Along with defining a source and destination, relationships also define the synchronization behavior in response to trigger events (or just triggers). While there are a number of trigger events, they fall into three basic categories: addition of items (adds), changes to items (edits) and deletion of items (deletes). Items being moved in or out of active folders trigger adds or deletes respectively.
Adds
Adds consist of either the creation a new item in a source folder or the movement of an existing item into a source folder from another folder.
The behavior of the add trigger is uniform for all types of relationships: the item is copied to the destination. There is no relationship configuration setting for adds.
Since items originating in the destination folder are not subject to the relationship, there is no such thing as an add to a destination folder.
Upon setting up a new relationship, all of the items in the source folder are considered adds and are copied to the destination.
Because of the potential for duplication (see duplication), it is recommended that prior to the first synchronization of a new relationship you empty your destination folders by moving the contents to a side folder. Then return any needed items from the side folder after synchronization.
|
The Private Mailbox Folder starts empty to avoid duplication.
|
Contacts are copied from the Public Folder to the Private Mailbox.
|
Edits and Deletes
Edits consist of any change to the fields of an item that is subject to the relationship. The items in question include any item originating in the source as well as any replicas in the destination. Edits to destination replicas may or may not affect the originating item in the source, depending on your relationship settings.
|
Edits are made to a contact in the Public Folder.
|
Changes are synchronized to the replica in the Private Mailbox.
|
Similarly, deletes consist of either the deletion of an item that is subject to the relationship or movement of such an item from an active folder to another folder. The relationship is defined by the folders being monitored, not the items, so movement of an item out of the active folder is indistinguishable from the item having been deleted.
|
An originating contact is deleted from the Public Folder.
|
The contact copy in the Private Mailbox is also deleted.
|
How the relationship responds to edits or deletes is a configurable setting.
Synchronization Profiles
A synchronization profile is the collection of trigger settings that define the general behavior of a relationship. While relationship settings are independent of one another, they are generally set in coordination to achieve one of two kinds of behavior: one-way or two-way. These are the possible synchronization profiles for a relationship.
A relationship is not required conform to a profile and there is no single "profile setting". Profiles are a simply a concept to denote the general intent of the settings.
One-way and two-way profiles typically share the same behavior for adds, edits and deletes in the source folder. Changes in the source are synchronized to the destination folder.
The profiles differ in how they treat edits and deletes to replicas in the destination folder. (Adds to the destination aren't considered here because they are never subject to the relationship.)
One-way relationships prevent edits to and deletes of replicas in the destination from affecting the originating items.
Two-way relationships allow edits and deletes of replicas in the destination to be reflected in the originating items.
|
Convention
Further examples of synchronization behavior will use logos to represent whether they apply to a one-way or two-way profile. Examples may illustrate one or both kinds of behavior. Both logos will appear in each example, but either will be crossed out if an example does not apply to that profile.
One-way: 
Two-way: 
|
The following table summarizes typical profile behavior. Note that a relationship may be configured to give a hybrid of the two behaviors. The triggers shown are for replicas in the destination folder only.
|
|
|
|
|
| • |
Discard edits to the replica and reset to match originating item. |
- or -
| • |
Preserve modifications and make a new replica. |
|
Synchronize edits back to the originating item.
|
|
|
| • |
Make a new replica of the originating item |
- or -
| • |
Keep originating item in source but do not recopy |
|
Delete the originating item.
|
One-way Behavior
One-way synchronization generally means that changes to destination replicas are prevented from affecting the originating items. What happens to the modified replica depends on the relationship settings.
One-way behavior usually means that edits are discarded.
|
Edits are made to a replica in the Private Mailbox.
|
Changes do NOT synchronize to the originating contact in the Public Folder.
|
Instead a new replica is made in the Private Mailbox, replacing the modified copy.
|
An example of an alternate setting that is still considered one-way is to preserve a modified replica and create a new copy.
When a replica is modified under this configuration, the originating contact and modified replica are dissociated from each other. The copy is no longer considered a replica since it is not subject to the relationship and is no longer synchronized with the originating item. new replica is made that follows the usual synchronization rules.
|
Edits are made to a replica in the Private Mailbox.
|
A new replica is made alongside the modified one in the Private Mailbox.
|
|
Be Aware
Because the former and new replicas appear similar (except for the hair), they are sometimes mistaken for duplicates. Educate your users about this issue when using this configuration.
|
The delete trigger in a one-way relationship also has multiple settings. The usual behavior is to recopy the originating item to the destination, effectively preventing the deletion.
|
A replica is deleted from the Private Mailbox.
|
A new replica is made in the Private Mailbox.
|
An alternate setting that is still considered one-way is to allow the replica to be deleted. The originating item is unaffected but will not be copied to the destination in the future, even if it is modified. This is called pruning.
|
A replica is deleted from the Private Mailbox.
|
The originating contact in the Public Folder is NOT deleted. It is also not recopied by subsequent synchronization.
|
Two-way Behavior
Two-way synchronization means that changes (edits and deletes) of destination replicas are synchronized back to the originating item in the source.
|
Edits are made to a replica in the Private Mailbox.
|
Changes are synchronized to the originating contact in the Public Folder.
|
|
A replica is deleted from the Private Mailbox.
|
The originating contact in the Public Folder is also deleted.
|
Because a relationship creates and tracks its own replicas, if the destination folder already contains copies of any of the originating items there is the potential for duplication when setting up a new relationship. The relationship does not try to discover and match destination items to the source. Doing so would be performance prohibitive. Instead, the relationship creates and tracks its own copies irrespective of the existing contents of the destination folder.
|
The destination folder already contains a user's copy of the contacts in the source.
|
The relationship creates replicas, apparently duplicating the destination's contents.
|
For this reason, you want to make sure that the destination folder is clear of copies prior to initial synchronization. If the destination folder is a perfect copy of the source, you may simply delete the contents of the destination or move them to a side folder. We recommend keeping the copies in a side folder until you are satisfied with the results of synchronization to be on the safe side. A side folder may be created in the user's mailbox for this purpose, for example.
More than likely your destination is not a perfect copy of the source. It may contain the user's personal contacts or local modifications to public contacts that are important to keep. In this case we still recommend moving items to a side folder to preserve personal copies. However, the user will need to determine which copies are important to return to the destination folder once synchronization has completed.
Mesh Relationships
Relationships are not transitive, that is, they do not chain together. This has important implications for how many relationships are required to achieve synchronization if you are trying to make a set of folders to have an equivalent set of items.
Another way of saying this is that replicas made by one relationship are not subject to other relationships. Copies are never copied further. This simple rule prevents configurations that could lead to an infinite loop in relationship synchronization that could fill a mailbox or public folder with duplicates.
The following example illustrates what it means for relationships to not be transitive. Imagine a private folder (yellow) with a relationship going to a public folder (blue). The public folder also has a relationship going to another private folder (red).
|
Existing contacts in each folder.
|
The first relationship copies yellow contacts to the public folder.
|
|
The second relationship does NOT copy yellow contacts to the other private mailbox.
|
Instead, just the blue contacts originating in the public folder are copied.
|
Because of this property of relationships, if you want a set of folders to be equivalent, you have to build relationships directly from each folder to every other folder. This is called meshing or a full mesh.
To be equivalent, a set of folders should contain the same set of items. To be fully equivalent, changes to any of those items, including replicas, should be synchronized to the other folder. Relationships can be configured to provide equivalent contents only or full equivalence depending on the relationship profiles used.
The following example shows this for two private mailbox folders. A relationship is set up in each direction, giving the smallest possible example of a mesh. This special case is also called a reciprocal relationship.
To provide full equivalence, two-way profiles are used on both relationships. Adds, edits and deletes to either folder will be reflected in the other.
|
Existing contacts in each folder.
|
After both relationships synchronize, folder contents are equivalent.
|
As more folders are added to the mesh, each new folder must have reciprocal relationships with every other folder. This means a third folder will add four more relationships, a fourth will add six and so on.
The following table summarizes the number of relationships required to build a mesh between the given number of folders. Both private and public folders count the same for this purpose.
|
|
|
|
2
|
2
|
|
3
|
6
|
|
4
|
12
|
|
5
|
20
|
|
6
|
30
|
|
7
|
42
|
|
8
|
56
|
|
9
|
72
|
|
10
|
90
|
|
N
|
N x (N - 1)
|
As can be seen, the number of relationships required by a full mesh grows quickly. Because of this, you should only consider using a full mesh for a small number of folders.
Learn more about what's new in Add2Exchange Standard Edition: Add2Exchange Release Notes