SYNCHRONIZE
System Administrator’s Guide
Version 2.0
CrossWind Technologies, LLC.
© 1993-1997 CrossWind Technologies, LLC.
Part Number 5201000-009
Synchronize is a trademark of CrossWind Technologies, LLC.
Motif is a trademark of the Open Software Foundation, Inc.
PostScript is a registered trademark of Adobe Systems, Inc.
UNIX is a registered trademark of UNIX Systems Laboratories, Inc.
X Window System and X are trademarks of the Massachusetts Institute of Technology.
Microsoft, MS, DOS, Windows and Windows NT are either trademarks or registered trademarks of Microsoft Corporation.
All other brand and product names are either trademarks or registered trademarks of their respective companies.
This guide describes the installation and maintenance of SynchronizeTM release 2.0 from CrossWind Technologies, LLC.
Synchronize is a real-time calendaring and scheduling application for corporations of all sizes. It is designed to support enterprise-wide collaboration among team members regardless of their individual locations. Synchronize’s advanced architecture makes it one of the most scalable applications in its category, offering enterprise collaboration from five to 50,000 users and beyond.
Synchronize’s advanced scalable design ensures that it will grow with the enterprise. Designed for cross-platform deployments, Synchronize 2.0 supports servers for Windows NT and over 20 UNIX platforms, as well as clients for Microsoft Windows, X11/Motif and character-based UNIX desktops. Its robust client/server architecture with distributed databases includes optimizations for multi-threaded architectures to enhance performance. Synchronize takes advantage of your existing servers and networks and does not require any special hardware or software to run. Because Synchronize 2.0 communicates directly across TCP/IP, access to critical information is instantaneous with none of the delays associated with file-based access methods, e-mail-based scheduling or slower transports.
Release 2.0 consists of various software components in three categories:
If you have any questions or comments about Synchronize or about this guide, please call, e-mail or write to CrossWind Technologies, LLC.: Synchronize servers are currently available for the following platforms:
Synchronize is a client-server application that uses TCP/IP for client-server communications. Remote file sharing (e.g., NFS, AFS, etc.) is not required (nor used) for database access. Any Synchronize client may access any Synchronize server regardless of the platform of either. To use Synchronize, you must have both a Synchronize server and a Synchronize client installed. UNIX RAM Disk space Virtual memory Other requirements Synchronize Server for UNIX Minimum recommended by OS 3.5 MB* (including sample database) 500 KB per active user in the database Disk and memory usage will increase over time depending on number of users and habits of use. 100MB per 100 users per year of use is a good rule of thumb. UNIX/Motif client Minimum recommended by OS 5 MB* 2-4 MB per instance of client X Windows version 11 Release 4, 5, 6 UNIX/ASCII client Minimum recommended by OS 2 MB* 2 MB per instance of client VT or ANSI compatible terminal emulation (not all terminal types supported) Note: Synchronize for UNIX is distributed as a single 3 to 6 MB tar image (7 to 10 MB after installation) and contains both client and server software as well as a sample database. The amount of initial disk space required will vary depending on which components you choose to install. It is available as a tar image via FTP, on floppy disks, QIC, or 4mm DAT. (Not all media types are available for all platforms.)
* varies by platform Windows RAM Disk space Virtual memory Other requirements Synchronize Server for Windows NT 24 MB 3MB 500 KB per active user in the database Disk and memory usage will increase over time depending on number of users and habits of use. 100MB per 100 users per year of use is a good rule of thumb. Windows Client 8 MB 2.5 MB 4 MB per instance of the client TCP/IP required: Winsock 1.1 or higher, Novell LAN WorkPlace or Microsoft LAN Manager (including HP ARPA services). Note: The Synchronize server for Windows NT and Windows client are each distributed on a single floppy or as a ZIP file available via FTP.
The following are the basic steps for installing the Synchronize UNIX software for the first time. Be sure to see the Installation Details section below for more information.
sh ./INSTALL
We recommend that you run the installation as root, although this is not strictly necessary.
bin/synchrod.sh &
If you did not install the Synchronize server component, make sure that the Synchronize server will be running on some other machine.
Synchronize is designed to be simple to install and maintain. Whether installing for a large or small number of users, it is helpful to plan ahead. The following topics will help you determine what details may be important when planning and executing the installation.
All the files that make up Synchronize 2.0 for UNIX can exist in a single rooted hierarchy. The installation procedure gives you the option of installing the client component, the server component, or both in this hierarchy. The client component contains items such as:
The server component contains items such as:
The two components can be (and typically are) installed together in the same hierarchy. You may, however, maintain client software in a separate location from the server and database if your environment requires you to do so. The Synchronize installation procedure is designed to be very flexible in this respect.
Before you extract the release from the release media, you should decide where the Synchronize hierarchy will reside and which components (client, server, or both) should be installed. It typically makes for much easier administration if the software is installed in a single shared location that can be easily updated with new releases. You may instead opt to install the server software on a machine that will house the server and database, and install the client software in one or more locations on other machines. Make the directory owned by whichever user will own the Synchronize hierarchy. CrossWind recommends that the database be installed in a local file system on the machine where the server will run. If the server must access the database files on a remotely mounted file system (e.g., over an NFS mount), efficiency and data integrity may be compromised.
Regardless of which components you have decided to install, Synchronize expects to find its hierarchy in $SYNCHROPATH, /usr/local/lib/synchronize, /usr/synchronize, or /synchronize. Each time it starts up, it looks in those four places (in that order) for a directory of that name (or a symbolic link pointing to a directory). The installation script will offer to create this symbolic link for you. Synchronize must find the hierarchy in one of these four expected places or it will not run. If the SYNCHROPATH environment variable is used, there will be no need to create any of the latter three directories, or symbolic links pointing to them. If you opt to use the SYNCHROPATH environment variable, you must set that variable to the correct path name of the Synchronize hierarchy before running Synchronize. The startup scripts in the bin subdirectory allow you to set this variable.
The following examples assume you have decided to install the Synchronize software in the directory mkdir -p /usr/local/lib/synchronize cd /usr/local/lib/synchronize If the system on which you want to install Synchronize has a drive capable of reading the distribution media, follow these steps to extract the Synchronize software:
To extract the software into the current directory, type:
tar xf Where media_device is your tape or floppy device name (for example, If the system on which you wish to install Synchronize does not have a drive that is capable of reading the distribution media, you will need to find some other system on the network that can. One way to read the distribution is to use a remote shell. Type the following to extract from a remote device after completing steps 1 and 2 mentioned above:
remsh Depending on your system, you may need to use the Some distribution media (tapes, in particular) may contain Synchronize releases for more than one platform. To extract the software for multiple platforms, use the examples above for the first file on tape. For subsequent files, use the mt command to skip forward on the tape. You must specify the non-rewind tape device for your system and how many files to skip as follows:
mt -f (Use mt -t on HP-UX)
where n indicates how many files to skip over from the beginning of the tape. Once the tape is positioned, you can use the examples in the Extracting From Tape or Floppy section above to extract the file. For example, if your tape contains Synchronize tar images for SunOS, HP800 and Solaris, in that order, and you wish to extract only the first two tar images, you would take the following steps after completing steps 1 and 2 mentioned above:
tar xf The above command will extract the SunOS software that you must install before extracting the next tar image. After it’s installed, you would then type:
mt -f (Use to skip forward one file from the beginning of the tape followed by:
tar xf to then extract the HP800 software. If you have downloaded or obtained a Synchronize release tar file, you should complete steps 1 and 2 mentioned above, copy the tar file to /usr/local/lib/synchronize, and then type:
tar xf to extract the contents of the file into the current directory.
The Synchronize release contains the following files and directories. During installation the .new suffixes are renamed or removed as necessary. Files or directories particular to either the client or server component are noted:
File or directory Description INSTALL Installation script SYSADM Synchronize System Administrator’s Guide (ASCII text) VER_ File indicating the release version and platform architecture bin.new/ Startup scripts and installation support scripts db.new/ Synchronize database and related files (Server component only) arch Platform-specific executables and support files ps.new/ Support files for PostScript® printing (Client component only) relnote Release notes resources.new/ Synchronize resource files including X resource files, help and message catalogs (Client component only) The installation will attempt to adjust ownership and permissions of files and directories as necessary to that of the specified Synchronize owner. It may not be able to do so if you do not run the installation as root or as the owner of the Synchronize hierarchy. It may be necessary to adjust ownership of the hierarchy manually before running the installation (especially if installing the release on a remote file system, e.g., over an NFS mount). The following command examples assume you are installing in the directory /usr/local/lib/synchronize and that you will specify bin as the Synchronize owner. If your system supports the chown -R command then:
chown -R bin /usr/local/lib/synchronize
will do the job, or, if your system does not support the find /usr/local/lib/synchronize -exec chown bin ’{}’ ’;’
Once ownership of the hierarchy is consistent throughout as the new Synchronize owner, then the installation should be able to complete without any problems. CrossWind recommends bin as the owner of the hierarchy in most instances. If installing the server and database component, then the hierarchy, however, must not be owned by root, as the database locking mechanism depends on this. The installation will not allow you to choose root as the owner when installing this component. The command During the installation, you will be asked various questions. Each question that appears on the screen will typically be followed by a prompt listing valid responses, such as " [y/n](n):
Any response that appears in parentheses following the list of valid responses is the default response. Pressing only the Return or Enter key enters the default.
You will be prompted as to which components of the software you wish to install. If you choose to install only the client software, then you should have already installed or plan to install the server software and database on some other machine. If you plan to run without a server, i.e., client-only mode, then see the section Client-only Mode in this guide.
If you are installing Synchronize for the first time, then you will be prompted to enter your license number (except when installing only the client component). License installation requires executing the Synchronize binaries. Therefore, when installing for the first time, you must perform the installation procedure on a machine on which those binaries will run. In other words, if you are installing Synchronize for the first time and you are installing it for Solaris, then you must run the installation on a Solaris system so that the licensing step will succeed. If you are installing a release in a hierarchy to which a license has been previously applied, then you can run it on any supported platform that is convenient. For more information on licensing details, see the Upgrading and Licensing sections in this guide.
If you are installing the release on a remote file system (e.g., over an NFS mount), then keep in mind that your identity on the local machine may not be the same as that on the remote machine. For example, the user root usually does not map to root over an NFS mount. Similarly, if your installation involves a SunOS system, you must take into account that the bin and sys accounts on such systems are typically reversed from that of most other systems. If you run the installation as root, then you will be prompted whether you are installing in a local or remote file system. If remote, then the installation will perform an su to the specified Synchronize owner while manipulating files in the remote file system. If the installation fails because it cannot adjust ownership or permissions, then first try to manually adjust the ownership as outlined in the section Ownership of Files and Directories above before proceeding.
You will be prompted to specify the owner of the Synchronize hierarchy that you are installing. In most instances, CrossWind recommends the user bin as the owner. The recommended owner will appear as the default. You are free to choose any user to own the Synchronize hierarchy. If installing the server and database component, then you may not choose root as the owner. The database locking mechanism depends on this. If installing only the client component, then this restriction does not apply.
The installation program will offer to create either one or three symbolic links for you depending on which components you are installing. These links are not strictly necessary in order for Synchronize to run but CrossWind recommends that they exist to ease administration. See the section External Symbolic Links below for details. After the installation has been completed, the installation program can be run on other machines to create the necessary symbolic links so that Synchronize can be executed there.
At this point, the installation will be complete. If the script fails to execute to completion it will issue pertinent error messages and terminate. After corrective action has been taken, the script may be restarted. Although the installation takes care to compose itself in the event of a failure, you may need to re-extract the release before re-running the installation program.
The Synchronize installation will offer to create the following external (to the Synchronize hierarchy) symbolic links for you. The existence of these links is not strictly necessary, but will facilitate the execution of Synchronize and probably make Synchronize administration easier. Alternatives to creating these links are noted below. If you choose to create the links at a later time, or if you want to set them up on for a machine which will be accessing the hierarchy over the network (e.g., over an NFS mount), then you can simply run the installation script again with nothing new to install and it will skip directly to that step. These links should exist on any machine(s) on which Synchronize will be executed.
CrossWind Technologies, LLC.
835 Fern Ridge Rd
Felton, CA 95018
sales@crosswind.com
support@crosswind.com
http://www.crosswind.com
Phone: (831) 335-8351
Fax: (831) 469-1750
Supported Server Platforms
Supported Desktop Clients
System Requirements
INSTALLING SYNCHRONIZE
Installing the Synchronize Client or Server for UNIX
Installation Summary
Installation Details
What to Install
Where to Install
Extracting the Software
Extracting from Tape or Floppy
Extracting Multiple Releases from a Single Tape
Extracting from a Downloaded File
Release Contents
Ownership of Files and Directories
Running the Installation Program
External Symbolic Links
Link to the Synchronize hierarchy (could also be
/usr/synchronize or /synchronize). If the SYNCHROPATH environment variable is used then this link is not needed. This link applies to both client and server components.
Command name typed by users to start the Synchronize client application. This link should exist in a directory included in a user’s
PATH environment variable (could be in some other appropriate directory, e.g., /usr/bin/X11). This link only applies to the client component of the software.
/usr/lib/X11/app-defaults/Synchronize ¾
> resources/Synchronize
Link to the Synchronize client X resource file. You can also use environment variables such as
XFILESEARCHPATH or XAPPLRESDIR if you prefer to not use the link. This link only applies to the client component of the software.
The installation script optionally allows you to install only the client component of the software. Use the installation summary above for installing the UNIX software with the following exceptions:
For the sake of backward compatibility, the Synchronize 2.0 release supports what is termed "client-only mode." When run in this mode, each instance of the Synchronize UNIX client manipulates the common database directly either through the local file system or on a remote file system. The Synchronize server is not used in this mode. Operating in client-only mode precludes you from running other clients (e.g., Windows) against this database as they require a Synchronize server. It also precludes you from setting up multiple Synchronize databases that share calendaring information, as a server is required in this case also. CrossWind Technologies does not recommend that you run in client-only mode unless you do not have network access to a Synchronize server. If you must run in this mode, then the following additional details will apply to you:
Use the installation summary above for installing the UNIX software with the following exceptions:
All other steps mentioned in the summary and details above still apply.
If you have installed the server and database component of the release, then for convenience you may wish to change the ownership or group of certain files that you will need to occasionally modify in the course of maintaining Synchronize. These files are as follows:
db/users
db/groups
db/groups/*
db/domains
db/database/server/*.opts
It is not strictly necessary that they be owned by the Synchronize owner, but they must be readable by the Synchronize server. If you change the ownership of these files to another user (such as yourself), then you can more easily modify them when necessary.
The installation program can be used to set up symbolic links on client machines that will be accessing the Synchronize hierarchy. When the script is run in a hierarchy where there is nothing to install, it simply asks if you wish to set up the symbolic links. This is useful when you have a single installation location which users access in a shared directory but will run Synchronize locally on their own machines. Remember that you can also set the environment variables mentioned in the External Symbolic Links section above in the
bin/synchronize.sh client startup script.Be sure to see the section on Client Administration in this guide for information on default configuration settings for the UNIX/Motif client.
Upgrading
The installation procedure will never modify or damage the contents of your existing database. In addition, it attempts to modify or replace as few files as possible that may have been previously changed by the Synchronize administrator. For example, the Synchronize client start-up script (bin/synchronize.sh) is almost never replaced and the resources directory is replaced (and the existing directory renamed to resources.old) only when absolutely necessary. As a result, you should not hesitate to extract and install new releases of Synchronize on top of existing ones, when such installation is warranted. In all cases, the directory containing the platform specific binaries (e.g., solaris, rs6000, etc.) for which you are installing will be renamed with a .old suffix and a new directory will be created for the new release.
The following are the basic steps you should take when upgrading Synchronize to a new version or when adding software for a new platform to an existing installation:
After the upgrade is complete, the following files will have been added/updated in your hierarchy and represent the distributed versions of the files with the same name (minus the bin/synchronize.sh.dist
The files listed above may be periodically updated by CrossWind with fixes or new configuration options.
There are two notable changes to the version 2.0 UNIX installation procedure over version 1.3 and earlier:
The Windows NT installation procedure is executed through a standard graphical interface. The Synchronize server will be installed by default in \SYNCHRO\SERVER on your hard drive. You may choose to install in any other directory accessible on the system (except network drives). Most references to file and directory paths in this guide use the UNIX convention of forward slashes (e.g., db/users). You can safely substitute back slashes for any of these references (e.g., db\users) when working with the Synchronize server for Windows NT. All file and directory locations are identical between Windows NT and UNIX. Any exceptions to this rule are explicitly noted in their respective sections of this guide.
.new suffix to distinguish them from your existing release.
bin/synchrod.sh.dist
db/database/tztab.dist
db/database/client.opts.dist
db/database/macprefs.dist
db/database/server/server.opts.dist
db/database/server/router.opts.distChanges to the Installation Procedure from Version 1.3
Installing the Synchronize Server for Windows NT
Overview
Installing from Floppy Disk
If you have obtained the Synchronize Windows NT server software as a ZIP file, simply extract the software into a temporary directory on your system using PKZIP, WinZIP or other compatible utility. Then, follow the instructions starting from step 1 in the Installing from Floppy Disk section above.
The installation procedure installs the Synchronize server as a Windows NT service. The service can be stopped and started from the Services icon in the Windows Control Panel. The server will be listed as "CrossWind Synchronize Server." The installation procedure will also create a new key in your Windows NT registry under the pre-defined HKEY_LOCAL_MACHINE\SOFTWARE\ key. The new key will be created as CrossWind Technologies\Synchronize Server\Current Version\. There are three value entries created under this key. They are as follows:
A Synchronize account with a login of "demo" is provided in the sample database shipped with Synchronize. If a user does not have an entry in the You must stop the Synchronize server before beginning an upgrade. The procedure for upgrading is similar to that for installing, with the following exceptions:
The Windows installation procedure is executed through a standard graphical interface that asks a few simple questions and installs the software with little fuss. You will be asked as many as three questions:
If you are not sure which TCP/IP stack you are using, choose the Winsock 1.1 option. In most cases this will be the correct choice. The default directory into which the Synchronize Windows client will be installed is C:\SYNCHRO\CLIENT. The default directory for previous releases of Synchronize was C:\SYNCHRO. You may choose to install in any other directory accessible on that system (including network drives). Be sure to see the section on Client Administration in this guide for information on default configuration settings for the Windows client.
If you have obtained the Synchronize Windows software as a ZIP file, simply extract the software into a temporary directory on your system using PKZIP, WinZIP or other compatible utility. Then follow the instructions starting from step 1 in the Installing from Floppy Disk section above.
The procedure for upgrading is exactly the same as for installing. The old software will be automatically replaced by the new and your existing configuration will be preserved. One notable change is that the default installation directory is now C:\SYNCHRO\CLIENT. In previous releases, it was C:\SYNCHRO.
The following example offers a simple scenario that may help you in setting up Synchronize. Keep in mind that the installation procedure is very flexible and you may modify this example to suit your needs.
XYZ Corporation is a public relations firm that employs about 25 people. Each employee has a PC on their desk running Windows 95 and the company owns a Sun SPARC 5 running SunOS called "soapstone" that serves as both a file server and as their Internet e-mail server. The company has decided that soapstone will host the Synchronize server and database and that the users will install the Windows client on their desktop PCs.
The administrator for XYZ Corporation, Nelson, has decided that he will install Synchronize in /usr/local/lib/synchronize on soapstone and completes the following steps:
XYZ Corporation is now up and running with Synchronize.
The following example covers a broad range of scenarios. You can use this example in its entirety, or pick and choose which parts may apply to you. Keep in mind that the installation procedure is very flexible and you may modify this example to suit your needs.
ABC Company designs, manufactures and markets its own line of gadgets. The company occupies three sites, Research and Development, Manufacturing and Sales and Marketing, each in a different city. Each of these sites is connected on the company’s network. The company has decided that each site will have their own Synchronize database and that users from each site should be able to use Synchronize to schedule users in the other sites, too. Site specifics are as follows:
The administrator at this site, Edith, has chosen to install Synchronize in the directory /shared/apps/synchronize on topaz. The /shared directory on topaz is already shared (exported) since users access other applications and documents installed under /shared.
r&d, topaz, Research & Development After finishing, she shares her work on the Now that Edith has finished setting up Synchronize on topaz, she must enable users to run the client application from their own systems.
For each system on which Synchronize will run, Edith does exactly what she did on brimstone, i.e., she logs in as root and sets up the symbolic links. Users now can type The administrator at this site, Sam, has decided to install the Synchronize server and database in the default directory C:\SYNCHRO\SERVER on bauxite, their Windows NT system.
Now that Sam has finished setting up Synchronize on bauxite, he must enable users to run the client application from their own systems. He starts first with the UNIX users.
Now the UNIX users may simply type synchronize at their shell prompt to start the application. Next Sam sets up the Windows users.
The administrator for this site, Wayne, has decided to install the Synchronize server and database in /usr/local/lib/synchronize on tetraploid, their Solaris host. He has also decided to install the Windows and Mac software each in a single location to make upgrades easier. The Windows and Mac systems all use some form of network file sharing and consequently have access to network file servers on which the software will be installed.
Now that the server is set up, he must set up the client software for the Windows users.
Once Synchronize is installed, you should edit the Synchronize_name, login_name, e-mail_address, Synchronize_alias
The above fields are defined as follows:
Fields (including blank fields) must be separated by commas. Any extra white space before or after a comma is optional and will be ignored. If a particular field contains a comma, then you must surround the entire field with double quotation marks so that the comma will not be interpreted as a field separator. You should take care to hit Return or Enter at the end of the last line in the file. Most of the time it will not be a problem, but some text editors fail to automatically include an end-of-line character before the end-of-file thereby causing the last line to be ignored. Here is an example of entries in the Joe, jclark, , Joey Note: The leading " As you can see in the above example, you can also list resources such as conference rooms and slide projectors in the There will commonly be times when a user’s entry in You can disable a Synchronize account without removing the calendar data associated with it. You can use any of the following techniques depending on your needs:
To delete a user account, you can either remove the user’s entry from the Synchronize administrators can be designated by an optional " Synchronize passwords are optional for UNIX users and mandatory for Windows users. Listed below are some details to keep in mind when working with Synchronize passwords.
In some cases, it may be necessary to reset a password if, for example, a user forgets his or her password. To reset a password, the user’s password entry must be deleted from the As the number of Synchronize users grows, a linear set of names becomes insufficient to allow quick access to users. To deal with this issue, the ability to display a hierarchy of user groups is provided. The Building-1 (subdirectory)
Engineering (subdirectory)
Development (file)
Manufacturing (file)
Building-2 (subdirectory)
Administration (file)
A group file lists either the Synchronize_alias or Synchronize_name of users in the group, one per line. For example, if Joe, Jim and Rhonda (as specified in the example Joe
Note that it is not necessary to surround Jim’s name by double quotation marks as in the users file. Also note that a group file entry will always refer to a matching Synchronize_alias before a matching Synchronize_name. For example, "Joe" in the above group file refers to the user whose login is "joe", not "jclark".
UNIX users can create their own personal groups. This feature is not currently supported in the 2.0 Windows client. The procedure and rules for creating personal groups are the same as that described above for system groups with the following exceptions:
While maintaining the Synchronize client software, the following topics may be helpful to look at from time to time.
All Synchronize 2.0 clients can run in two modes: client-server or stand-alone. Stand-alone mode is also sometimes referred to as detached or nomadic mode. Details of each mode are as follows:
Users will most often or always run Synchronize in client-server mode. When operating in this mode, all database access occurs over your network with a Synchronize server running on a UNIX or Windows NT host. For the Windows client, you must specify the server host in the login dialog when logging in. For UNIX clients, there are two ways to specify the server host:
synchronize -server Sometimes it may be necessary to use Synchronize while disconnected from the network (for example if you carry your laptop computer with you when traveling). Stand-alone mode allows you to do this. Stand-alone capability can be enabled via the configuration/preferences dialog for each client. When running in stand-alone mode, the client accesses a local copy of the user's data that is stored on the local hard disk. When the user reconnects to the server, any changes made while running in stand-alone mode are merged with the server database (at the discretion of the user).
Stand-alone mode is functionally equivalent to client-server mode with the following exceptions:
When stand-alone mode is enabled, the user is prompted to save his or her data to the local disk each time he or she exits Synchronize. Upon subsequent restart, Windows users can click the "Stand-alone" check box in the login dialog. UNIX/Motif users will be automatically prompted to run in stand-alone mode when connection to the server fails.
Since Synchronize will be keeping users’ appointments, an important requirement for trouble-free Synchronize use is to have the proper time zone setting in place with consistent rules for transitions into and out of daylight savings time for all users. This is especially true if users are located in different time zones. Users with differing time zone settings or inconsistent transition rules may not always see appointments displayed at the correct times on their calendars. Any inconsistencies must be addressed before users are able to use Synchronize reliably. To ensure consistent behavior, you must first make sure that all users who are scheduling within the same time zone have the same time zone configuration setting. For Windows users, this must be set in the configuration options/preferences window (also see below for instructions on setting default configuration options). For UNIX users, the TZ= You must substitute your correct time zone (e.g., PST8PDT) in place of timezone above. Although users’ time zone settings may be set consistently, it cannot always be assumed that daylight savings transitions are handled correctly (especially when running clients for multiple platforms in non-U.S. time zones). A convenient mechanism for keeping all Synchronize users running with the same daylight savings transition rules is by using the When users run Synchronize for the first time, it may be preferable to start them off with a pre-configured set of default options. This is especially true for a setting such as their time zone, since an incorrect time zone setting can cause meetings to be displayed at incorrect times (see Time Zone Settings above). Each client has its own way of handling default configuration options. Details for each are outlined as follows:
By default, users only have permission to schedule each other. If it is necessary to establish some alternative default calendar permissions (e.g., all users must be able to view others’ calendars, too), the file To set the default permissions on users’ calendars, the administrator can add a special entry of the following format at the beginning of the file:
#O < #J A single <tab> must separate the field identifier (e.g., #O) from its value, and a blank line separates each #J section from the next. The #J designations are only needed if specifying access for users in remote databases. For the entry, the various items are defined as follows:
Any of the above fields can be omitted (except As an example, suppose that you wish all local users to be able to schedule each other as well as view each other's calendars by default. The only entry you would need to make is as follows:
#O __ALL__
As another example, suppose that in addition to the scenario above, there are also four managers (Bill, Mary, Joe and Barbara) in a remote database who must have agency permission by default for all users in the local database. The local database is named "xwind" and the remote database is named "mtnview" according to the first fields in the #O __ALL__
#J mtnview
Keep in mind that a user can change their permissions and override the default so that none of the managers could then become their agent.
The Synchronize administrator may find it necessary to impose special system-wide options on clients’ behavior. This can be done by editing the file option The following options are supported in the 2.0.0 release or higher of the Synchronize client for UNIX/Motif and Windows.
Daily and Work-daily: 2-year limit
The default value is False.
There are two ways you can start/stop the Synchronize server daemon (synchrod).
bin/synchrod.sh &
To stop the Synchronize server in this case, use the following steps:
kill A useful side effect of using the bin/synchrod.sh platform/bin/synchrod
where platform is the platform-specific directory corresponding to the machine on which it runs. When the server is run in this fashion, there is no need to background it as above since it runs as a daemon and automatically backgrounds itself. Executing the server binary directly makes it easier to use special command-line options such as To stop the Synchronize server in this case, follow these steps:
kill You should not use kill -9 The Synchronize server for Windows NT runs as an NT service. Starting and stopping it is performed via the Services icon in the Control Panel as with any NT service. You may also start and stop it from the command-line using the following syntax:
net {start|stop} synchrod
If the Synchronize server for Windows NT is unable to start for some reason and its log file ( The Synchronize server has several configurable options and command-line options that control its behavior. The file containing the options settings is All configurable options are shown below with their default settings. The format for an option entry is:
option: value Comments can be entered with a "#" or a "!" as the first character of the line. This file can be updated while the server is running, as the server checks periodically (see checkInterval) to see if the file exists and if it has been changed. The following options are listed alphabetically:
checkInterval The default value is 900 (15 minutes). If you wish to see changes to the above files take effect immediately, you can send the UNIX Synchronize server a debugLevel inetRange 201.93.140.*,201.93.145-147.*,201.94.133.24
You can use the inetRange option to prevent unauthorized clients from accessing your server. If no value is specified, the server will accept connections from any IP address.
mailerCmd mailerDelimiter mailerHost mailerOpts maxClientThreads maxMsgLen remoteDbUpdateInterval threadTimeout truncateLog writeDelay The Synchronize server for UNIX accepts the following command-line options:
-filterDups -maxSockets -newLicense -noFork -showLicense -socketOffset -test -version One server process is started to serve all Synchronize clients for a particular database. There is great advantage in preventing any other process from directly accessing the database files:
The limitation on the number of open file descriptors per process necessitates that the server close the socket connections for old clients in order to accept new ones when the number of simultaneous clients approaches the limit (see the -maxSockets option in the Command Line Options section for more details on this limit). This results in the server dropping the connection to a client. However, a reconnection strategy allows those clients to reconnect automatically with the server at their next request. Since typically at least 60 file descriptors are available and the reconnection delay is about 1 or 2 seconds, this strategy should result only in a slight delay in accessing the server for clients whose connections have been dropped. In addition, a positive side effect of this strategy is that the server may be killed and restarted without adversely affecting existing clients.
The Synchronize server sends its output to a log file in the Synchronize incorporates a multi-threaded server for Windows NT and several UNIX platforms. The multi-threaded design optimizes performance by alleviating bottlenecks associated with disk and network I/O. The server includes a flexible design to support both multi-threaded and single-threaded process architectures.
One administrator-configurable option exists and four classes of threads are supported (not counting the main thread, which directs the activity of the other threads). The four classes of threads are as follows:
Synchronize uses a central database containing calendaring information for the users it serves. As the number of users grows, the size of and traffic to the database grows in a corresponding fashion. Eventually, the database may be so large as to cause a performance bottleneck. For example, while support for 500 to 1,000 users in a single database may be feasible, support for 5,000 users is not. To deal with such issues of scale, as well as administration requirements within an organization, the Synchronize 2.0 release supports multiple distributed databases. Multiple Synchronize databases can exist on different hosts or on the same host. (See the Hosting Multiple Databases on the Same Machine section for more information on that topic.)
Typically a group, department or site might have its own Synchronize server and database installed on a machine at that location while other groups, departments or sites might have their Synchronize servers and databases installed on machines over which they have control. It is also possible to have more than one Synchronize server and database on the same machine (see below). Whether you are setting up multiple Synchronize servers and databases for the first time or joining a group of existing ones, the following instructions will help you.
You inform a Synchronize server of the presence of remote databases by editing the database_identifier Definitions of the above three fields are as follows:
database_identifier hostname database_alias An example of a domains file is as follows:
sc, whirlwind, Santa Cruz
The above example assumes that there is a database on a machine called "whirlwind" in the city of Santa Cruz, another on a machine called "lupine" in the city of Mountain View, and a third on a machine called "hpuxsv8" in the city of Cupertino. The same unedited domains file can be shared among all Synchronize databases thereby minimizing administration effort.
Note that communication among Synchronize databases must be bilateral. For instance, in the example above, Cupertino must have an entry in its When a user schedules or modifies a calendar item that includes invitees in remote databases, those changes are first made in the local database. It is at this time that the Synchronize forwarding agent comes into play. The agent spends most of its time sleeping, waking up only to query its local Synchronize server for new or modified calendar items that need to be forwarded to remote databases. If any such items do exist, the agent attempts to do so. If for some reason the agent fails to forward items to a particular remote database (e.g., the remote machine is down for maintenance), then the agent will try again when it next wakes up. The forwarding agent for your local database is only responsible for forwarding information from the local database to remote databases, i.e., it never retrieves information from them. Your local database receives information sent from remote databases by the forwarding agents running on those remote servers.
Behavior of the forwarding agent is controlled by options in the file checkInterval debugLevel forwardRange backwardRange The forwarding agent (sync.forward) binary is located in the platform As Synchronize databases are linked together in order for users within large organizations to schedule each other using Synchronize, it becomes necessary to make access to users in remote databases as seamless as possible. One way that an administrator can facilitate such access is to create groups that include users both from remote databases as well as the local one. The format of an entry in a group file for a remote user is as follows:
user where user reflects either the remote user’s Synchronize_name or Synchronize_alias in the db/users file for the remote database, and database reflects either the database_identifier or database_alias in the db/domains file for the remote database. The "@" designation for users in the local database is optional.
For example, using the sample domains file mentioned previously, if a Strategic Marketing group spans two databases, where the local database is has a database_identifier of "sc" and the remote database has a database_identifier of "mtnview," the Strategic_Marketing group file may contain the following entries:
Joe@Santa Cruz
Although the " The Windows client does not support groups which span databases. It simply ignores any entries using the " In some cases, it may be necessary or desirable to have the same machine host multiple Synchronize databases/servers. For example, if you only have one machine available to you, yet must host more users than a single Synchronize server may be able to handle, then splitting those users among multiple databases on the same system might solve that problem. If you are planning in the future to expand your Synchronize user population in various departments or groups, then you may find it desirable to give each department or group its own database. Moving an existing database to another machine in the future is a very simple procedure, whereas splitting a single database into two or more when it has grown too big is more involved. Only the UNIX Synchronize server can be installed this way. The Windows NT Synchronize server does not support this capability. There are some important points to keep in mind when hosting more than one Synchronize database on the same machine:
As an example, assume that a single machine will host three Synchronize databases. The databases will serve the Sales, Marketing and Manufacturing departments. First, you must create three directories, one for each database. For example,
/usr/local/lib/synchronize-sales
After installing the Synchronize server software in each location and setting up Synchronize user accounts in each, you must edit the Sales, soapstone To start the three servers, you might have a master script executed at boot time such as:
#!/bin/sh
Each The following limitation applies to all supported platforms when using multiple databases:
The following limitation applies only to the Windows client when using multiple databases:
Synchronize supports e-mail notification to users about scheduled events. Synchronize accomplishes e-mail notification in a variety of ways. E-mail can be sent by clients or servers depending on the platform and configured options. For Windows clients, e-mail is always sent by the Synchronize server for them. For UNIX/Motif clients, the server can optionally send the e-mail, but the default is for the client to send the mail itself using sendmail.
The following options can be set in the Configuration/Preferences dialog for each client:
The following option(s) apply only to the UNIX/Motif client and can be added to the client’s X resources (e.g., the resources/Synchronize file):
Synchronize*serverSendmail: True
The following e-mail related options can be set in the A sendmail trusted user is one who is allowed to use the Trusted users are defined in the sendmail configuration file ( T uucp
The above T commands show that there may optionally be white space between the T and the first name in any list of names. They indicate that uucp, root, and daemon are trusted, and have been added to the list of trusted users in that order. Depending on your version of sendmail, you may need to "freeze" the configuration file so modifications to the sendmail configuration are recognized. To do this, invoke sendmail with the If the Synchronize server is sending e-mail where the sender address appears to be that of the Synchronize database owner (e.g., bin), then there are two options to make e-mail appear as it is from the correct Synchronize user:
The Synchronize administrator may pre-define the format and content of the e-mail messages that notify users of events. The file template_header A template_header followed by a colon (" NewEventSubject %t An example of a NewEventSubject:
NewEventBody:
There are various tools available for performing the administrative tasks mentioned below on the Synchronize database. Tools for measuring performance as well as technical papers on other administrative topics such as the database file format are also available. These can be found on CrossWind’s FTP server in the following locations:
http://www.crosswind.com/products/synchronize/admintools See the CrossWind recommends that you back up your Synchronize database on a daily basis. Only the #!/bin/sh
BACKUP_DIR="/backups"
cd $SYNC_DIR
You do not need to stop the Synchronize server when backing up the database. When deciding what time the backup should occur, keep in mind that the Synchronize server propagates unfinished to-dos to the next day around midnight. The amount of time required to do this depends on the size of the database and the speed of your system. For this reason, when scheduling your backup, it’s probably a good idea to avoid the time between 12:00 a.m. and 1:00 a.m.
There are three scenarios to consider when restoring the Synchronize database:
When performing a full restore, you should carefully follow these steps:
When performing a partial restore, you should carefully follow these steps:
When restoring data for a particular user or users, you should carefully follow these steps:
setenv SYNCHROPATH /tmp/synchronize
As time passes, the size of your database will increase. Expiring old data periodically will conserve disk space as well as help to improve performance and decrease the virtual memory footprint of the Synchronize server. The sy_expire utility allows you to specify how much past data to keep and deletes everything older than the date you specify. There is no strict rule about how much data to keep around. Base your judgment on disk and virtual memory usage. CrossWind recommends that you make a backup of your database before expiring data. See the instructions that come with sy_expire for more information on its options.
CrossWind recommends that you back up your database before moving it to another machine. See the Backing Up the Database section for more information.
The following procedure covers the cases where UNIX systems are both of the same type or of different types. For moving a database between a UNIX and Windows NT system, see the section Moving Between a UNIX and Windows NT System When moving a Synchronize database to Windows NT from UNIX or vice versa, the database files must be converted. Specifically, the EOL character used by Windows NT and that used by UNIX are different and must be converted. This conversion must be done in order for standard DOS/Windows text editors to work correctly on editable UNIX files (and vice versa) and for the Synchronize server to function correctly. Carefully follow these steps. The file conversions must take place on a UNIX system on which Synchronize is supported.
mkdir /tmp/tempsync
You should ensure that empty directories and zero-length files (if any) are also copied.
README - Depending on who owns the Synchronize database and who does the conversion, you may need to modify the ownership of the files in the database. To be safe, you can either run the conversion as root, or use the ./convertdb.sh -2dos
or if you are converting from Windows NT to UNIX, then type:
./convertdb.sh -2unix
The conversion may take several minutes depending on the size of your database and speed of your system.
If moving from Windows NT to UNIX, you should do the following:
The following procedure describes how to move one or more users’ data from one Synchronize database to another. CrossWind recommends that you make a backup of your database before proceeding.
#!/bin/sh
This script assumes that the list of users contains only the Synchronize_name for each. If you made a copy of the You will need to obtain the sy_mover utility for your specific platform from the You should arrange to have the appropriate revised license strings before beginning this procedure. If necessary, CrossWind can supply you with a temporary license string. Please contact your Synchronize supplier or your CrossWind sales representative for this information.
In summary, you will be performing the following tasks:
Follow these detailed steps carefully to split up your database:
You will need to obtain the sy_mover utility for your specific platform from the You must have the appropriate revised license strings before beginning this procedure. If necessary, CrossWind can supply you with a temporary license string. Please contact your Synchronize supplier or your CrossWind sales representative for this information.
In summary, you will be performing the following tasks:
Follow these detailed steps carefully to combine your databases:
Synchronize provides a built-in command-line import/export mechanism in the UNIX/Motif client. For details on this feature, see the document
In most cases, Synchronize should allow quick access to your calendar. Occasional delays of one or two seconds are normal. As the number of active users increases, duration and frequency of delays may increase. Performance problems are caused by one or more "bottlenecks" in system resources. Examples of system resources include network bandwidth, CPU availability, hard disk I/O, etc. Unfortunately there is no easy answer to the question, "How many Synchronize users can this system handle?" In general, you should be able to host a database of several hundred users on a modern lower-end UNIX workstation running a multi-threaded Synchronize server. The following topics should help you determine the cause of performance problems should they arise. Some topics are relevant to any application, not just Synchronize and can be used to determine performance problems in general with your systems.
In most cases, performance problems experienced by users tend to be caused by bottlenecks on the server. When most or all users are experiencing similar performance problems, this is a strong indication that a server-side performance bottleneck exists. CrossWind Technologies provides a simple script ( Typically, perceived client performance problems are caused by performance problems on the server. This is especially true when Synchronize users across the board experience similar performance problems. If this is the case, start with the Server Performance section above. Nonetheless, client-side performance problems can exist. Each of the following items addresses a potential bottleneck for a client:
The licensing mechanism in Synchronize is a static one. If you have an N-user license for your database, then the first N users in the The number of licensed users at a site may be upgraded at any time. Simply contact your Synchronize supplier or CrossWind Technologies. A new license can be faxed, e-mailed, or communicated to you over the phone. No re-installation of the software is necessary. The license for your database is contained in the Windows NT Registry. The license itself is an encrypted string located in the pre-defined HKEY_LOCAL_MACHINE\SOFTWARE\ under the following key:
CrossWind Technologies\Synchronize Server\Current Version\
To view or alter the license string, use the Windows NT Registry Editor. Select the key referenced above and edit the "License" value entry by double-clicking on it. A string editor dialog will appear with the current license number. Replace this string with the new one given to you by CrossWind Technologies or your Synchronize supplier. The license information is checked and updated periodically according to the value of checkInterval in the After Installation
Upgrading
Installing the Synchronize Client for Windows
Overview
Installing from Floppy Disk
Installing from a Downloaded File
Upgrading
A Simple Installation Example
The Example Environment
Setting Up Synchronize for the Office
/usr/local/lib/synchronize directory. He then extracts the Synchronize release for SunOS and runs the installation program opting to install only the server component.
A More Complex Installation Example
The Example Environment
Setting Up Synchronize at Each Site
Research and Development Site
/shared/apps/synchronize directory on topaz and extracting the Synchronize release for HP-700/800 into that directory. Next she runs the installation program on topaz and chooses to install both the client and server software there. The installation program proceeds, prompts for the new license, creates the recommended symbolic links and finishes successfully.
mfg, bauxite, Manufacturing
sales, tetraploid, Sales and Marketing
/shared directory on topaz as /network/topaz.
Manufacturing Site
db\domains file which was given to him by Edith from the R&D site.
/netshare/synchronize. The /netshare directory is an exported NFS directory to which all UNIX systems at this site have access. Since he is installing only the client software, he will not be required to enter a license for this installation.
Sales and Marketing Site
/usr/local/lib/synchronize directory on tetraploid and then extracts the release for Solaris there. He then runs the installation script as root and opts to install only the server component of the software.
/shared/pcapps on tetraploid is a read-only NFS exported directory. All Windows users have NFS software installed, and they each have access to this shared directory as drive M:\ on their computers.
SYNCHRONIZE ADMINISTRATION
Users and Groups
Creating User Accounts
MAPI:. Doing so indicates that any e-mail to this user must be sent specifically through the MAPI system.
+Larry,lsmith,lsmith@mantle,
Rhonda, rjones, , Rhonda Jones
"Karlsen, Jim", jkarlsen,,Jim
Joseph, joe,, Joe
Conference Room A,,,
Slide ProjectorDesignating Non-Human Resources
Modifying User Accounts
Disabling User Accounts
Deleting User Accounts
Designating a Synchronize Administrator
Synchronize Passwords
Hierarchical User Groups
Pubs (file)
Marketing (file)
Sales (file)
Karlsen, Jim
Rhonda Jones
.synchronize/groups in their home directory ($HOME) which will contain groups files and subdirectories. The .synchronize subdirectory may have already been created for them automatically by Synchronize.
Client Administration
Modes of Operation
Client-Server Mode
SYNCHROSERVER environment variable is commonly set in the bin/synchronize.sh client start-up script. See the script itself for details.
Stand-alone Mode
Time Zone Settings
Setting Default Configuration Options
SYNCHRO.INI (typically C:\WINDOWS\SYNCHRO.INI) for its configuration options. If this file is not found, then Synchronize copies the SYNCHRO.INI file from the working directory (typically C:\SYNCHRO\CLIENT\SYNCHRO.INI) into the Windows directory for subsequent use. Behavior is unpredictable if no SYNCHRO.INI file can be found. An administrator need only provide the SYNCHRO.INI file in the working directory to initialize settings for first-time users. Any subsequent modifications to configuration options by the user are stored in the user’s SYNCHRO.INI file in the Windows directory.
Setting Default Calendar Permissions
tab> __ALL__
#J <tab> database_name
#R <tab> names
#C <tab> names
#Y <tab> names
#N <tab> names
#R <tab> names
#C <tab> names
#Y <tab> names
#N <tab> names
.
.
.
#J <tab> database_name
#R <tab> names
#C <tab> names
#Y <tab> names
#N <tab> names
#O field is required and must specify the value __ALL__ (two underbars before and after).
#R __ALL__
#N __ALL__
#J xwind
#R __ALL__
#N __ALL__
#Y Bill,Mary,Joe,Barbara
Administrator-Imposed Options
: value
Weekly and Biweekly: 10-year limit
Monthly and greater: no limit
Server Administration
Starting/Stopping the Synchronize Server for UNIX
bin/synchrod.sh) for starting the Synchronize server. This script must be edited (using vi or some other text editor) before use and provides an easy way to ensure that the server is running at all times. It also notifies the Synchronize administrator if any problems occur. Because the script runs in the foreground, when executed from another script (e.g., a system rc startup script), it should be backgrounded, e.g.,
synchrod -noFork" in the command name field.
kill PID
SIGTERM) to the process, e.g.,
Starting/Stopping the Synchronize Server for Windows NT
Server Options and Details
Overview
Options File Settings
db/users file
Command Line Options for UNIX
Server Details
Multi-threaded Server Details
db/database/server/server.opts.
Setting Up Multiple Synchronize Databases
Overview
db/domains files to reflect that move. If multiple Synchronize databases exist on a single host, then the hostname:N notation can be used to specify them as needed.
mtnview, lupine, Mountain View
cupertino, hpuxsv8, CupertinoThe Forwarding Agent
db/database/server/router.log file. The default value is 0.
0 - only fatal errors are logged
1 - information about network connections is logged
2 - summary of forwarding activity is logged
3 - detailed forwarding activity is logged
Starting and Stopping the Forwarding Agent
Groups Spanning Databases
Tom@Mountain View
Larry@Santa Cruz
Rhonda@Santa Cruz
Shirley@Mountain View
Jack@Mountain ViewHosting Multiple Databases on the Same Machine (UNIX Only)
SYNCHROPATH environment variable so that it knows where to find its corresponding database.
/usr/local/lib/synchronize-mktg
/usr/local/lib/synchronize-mfg
(could also be soapstone:0)
Marketing, soapstone:1
Manufacturing, soapstone:2
/usr/local/lib/synchronize-sales/bin/synchrod.sh &
/usr/local/lib/synchronize-mktg/bin/synchrod.sh &
/usr/local/lib/synchronize-mfg/bin/synchrod.sh &SYNCHROPATH="/usr/local/lib/synchronize-mktg"
export SYNCHROPATH
OPTIONS="-socketOffset 1"Limitations
@" designation.
E-Mail Administration
Overview
Client E-Mail Options
Server E-Mail Options
UNIX Sendmail and Trusted Users
Troot daemon
chown -R daemon /usr/local/lib/synchronize). Keep in mind that the Synchronize database cannot be owned by root.
(e.g., Customizing E-Mail Notification
db/database/mailmsg contains up to six separate templates. Each template is separated from the next by at least one blank line.
template_body
NewEventBody - Message body for new events
ModifyEventSubject - Message subject for modified events
ModifyEventBody - Message body for modified events
DeleteEventSubject - Message subject for deleted events
DeleteEventBody - Message body for deleted events
%o - event originator
%s - event start time/date
%e - event end time/date
%i - event invitees
%r - event readers
%w - event writers
%p - popup notes (first 3 KB of each)
%% - the % symbol itself
New event "%t" scheduled by %o
The following event:
\
"%t"
\
has been scheduled by "%o" to begin at %s
and end at %e.
Database Administration, Utilities and Procedures
http://www.crosswind.com/products/synchronize/docs/techpapers
Backing Up the Database
SYNC_DIR="/usr/local/lib/synchronize"
tar cf - db | compress > ${BACKUP_DIR}/db.tar.Z
Restoring the Database
db subdirectory and its contents from a previous backup into the appropriate location in the existing Synchronize hierarchy.
cd /usr/local/lib/synchronize
platform/bin/synchrod -socketOffset 1
Expiring Old Data from the Database
Moving the Database to Another Machine
Moving from One UNIX System to Another
Moving Between a UNIX and Windows NT System
db subdirectory to a temporary working directory. For example in UNIX you might type the following:
cd /usr/local/lib/synchronize
tar cf - db | (cd /tmp/tempsync; tar xf - )
convertdb.sh - Main script
convertfile.sh - Helper script
sy_convertfile - Conversion program
sy_convertfile.c - Source code for sy_convertfile
db subdirectory there. Extract the Synchronize distribution tar image into that directory and run the INSTALL program. The installation will detect the existing database there. Follow the instructions and enter your license string when prompted. Restart the Synchronize server. You are done.
Moving a User from One Database to Another
db/domains file and that multi-database functionality is working correctly before proceeding.
for user in `cat /tmp/myusers`
do
sy_mover -from soapstone -to tetraploid -user "$user"
done
Splitting a Database into Two or More
db subdirectory for the database that you will be splitting. See the section Backing Up the Database for details on how to do this.
Combining Databases
db/users file in the target database and make sure all names are visible when viewed with a Synchronize client.
Import/Export of Users’ Calendars
Performance Tuning
Server Performance
db/database/server/server.opts. The more frequent the writes, the more frequent the possible delays are for users. By setting the debugLevel to 2 in server.opts and using the synccheck.sh script, you can look for correlations between delays and the "writing" messages in the server.log file. There are three possible remedies for this type of problem:
http://www.crosswind.com/products/synchronize/admintools/sy_expire subdirectory on CrossWind’s FTP server. You should always make a backup copy of your Synchronize database before removing data.
Client Performance
LICENSING
Applying a License to a Windows NT Database
To apply a new license, change directories to the top of the Synchronize hierarchy on the same machine that hosts the Synchronize database and type the following command (note that you may need to first set the
SYNCHROPATH environment variable to the top of the Synchronize hierarchy, e.g., /usr/local/lib/synchronize):platform
/bin/synchrod -newLicense license_stringwhere platform indicates the platform-specific directory for the type of system on which you are running. If you get the response "Success!", your new license has been installed correctly and is in effect immediately. If not, contact your Synchronize supplier or CrossWind Technologies.
You can query the database to find the status of your license by typing the following command:
synchronize -showLicense
Synchronize will then display your unique license ID (not the license_string), the number of currently licensed users and the expiration date of the license, if applicable.