Ektron CMS400.Net eSync

Regardless of your personal opinion of Ektron's eSync technology, you can't help but admit it is a pretty amazing technology. After having used it for the past year or so, I have gained a love-hate relationship for it's ability to seamlessly synchronize every aspect of web CMS implementations, and at the same time, cause hours of angst when it fails.

My hope with this article is to ease the burden of troubleshooting other esync implementations out there by documenting various undocumented aspects of Ektron CMS400.Net's esync platform. I imagine someone at Ektron will eventually write a better explanation than this, but for now, I have not been able to locate anything better, and I am willing to write about it!

First, to clarify something. This is not a "how to" setup and configure esync. There are plenty of article and manuals written to assist with your eSync setup. This article is meant to be a deep dive into the inner workings of esync, as I have observed them, in hopes of assisting other developers, system administrators, etc, that may run into similar esync failure scenarios.

Disclaimer: I do not claim to be an Ektron engineer, all my findings are based on methodical troubleshooting and countless hours of repairing Ektron related issues. Please contact Ektron support for clarification on anything you find questionable in this article.

CMS License

Esync requires a valid, current, non-expired, esync enabled license (with (S) or (EN) in the key.) If any of the servers configured in your esync system have an invalid license, esync will fail.

Web.config

The following config sections, attributes, keys, etc. are necessary:

1. eSyncEnabled Should be set to "true" (individual folder/file sync is disabled w/o this option set to true).
2. WSPath Must be set to the web service callback URL in the workarea (Workarea/ServerControlWS.asmx)

Windows Service

The esync core process is driven by the Ektron Windows Services. If you have it disabled or it is not running for some reason, do not continue. Esync will not function without the service running.

The following files lie under the EktronWindowsService30 folder underneath the base installation directory.

1. Ektron.ASM.EktronServices30.exe.config - Contains valid esync certificate information for the servers that are part of the sync pair. Restoring the original .config file and restarting the Ektron Windows Service has actually fixed a corrupt configuration for me.
2. sitedb.config - Stores each CMS 400.Net site configuration that the Windows service will manage. Each site must have a unique WSPath or it will not show up as a unique site to be managed (this applies to SearchConfigUI instances as well incidentally.) You can safely clear this file as it is regenerated each time the Windows service is restarted. This can help determine why a site is not functioning properly.
3. log (folder) - If you haven't dug into the log folder, start. It contains error events that are not written to the event log that can help assist in troubleshooting failed esync processing.

Database Tables

The following tables are used in one way or another by the esync framework:

1. [AssetServerTable] - Stores a record for each site (domain) that connects to a specific CMS instance. For example, if you have multiple IIS web sites (local or not) using the same CMS database, a separate record will exist for each server that connects to and makes request against the specific CMS instance. The main thing to confirm with this table, is that a record with a valid callback URL (sometimes blank if the Windows service fails to catalog each server) for each esynced web site. If you have problems with any CMS processes that rely on the Windows service, you can safely truncate/delete the records from this table, restart the Ektron Windows Service, and regenerate the valid records.
   • [callbackUrl] - Callback URL the service uses to perform actions.
2. [scheduler] - Stores configuration options for each esync configuration instance.
   • [scheduledesc] - The current sync status of that particular instance (usually completed or running)
   • [triggeraction] - The configuration options for the specific esync instance (get to know this). Also stored in the Sync folder XML configuration files. I'm assuming this field is tied directly to the XML config settings somehow.
3. [perform_action] - This table is the engine of the Windows service. Any action the service is to perform, originates in this table (such as esync actions.)
4. [sync_resolve_tbl] - Undocumented at this time (anyone?)
5. [syncfolder] - Undocumented

Sync Folder

Esync bindings are also stored in local XML files stored under the c:\Sync folder. Though not recommended, you can manually modify these settings in the event of a failed esync setup.

EkStatus Xml Files

Under your web root, lies the EkStatus folder. I haven't been able to find any documentation to clarify my findings, but based on observation, a separate ###.xml file is created for each esync binding configured under synchronization in the workarea.

Each time an esync is kicked off, the correlating ###.xml file is truncated and all logging is done within the file. This is one of the first places to check in the event of a failed esync. You can usually determined what action esync was trying to perform at the time of failure. I've also found myself clearing the out the logs manually to get esync to start back up again after having failed.

Conclusion

Ektron CMS 400.Net Esync Technology is by far one of the most robust Web CMS synchronization platforms on the market. A successfully configured, running, synchronizing implementation results in satisfied developers, content administrators, and ultimately, content stakeholders. I have found that most issues correlate directly to one of the items listed here. Any additional information from those of you that have experienced similar situations is also welcomed.

Happy syncing!

Other Resources

Martin on .NET eSync Reference