As with all services, ciSync is started and stopped by the Service Control Manager, which is a part of the operating system. When the executable file, referred to as the ImagePath, is launched it receives the 'Onstart' system event. The first thing that happens after this is the creation of the main log file; ciSync.log and the ciSync_Proxy.log.
Creating a log file means that some standard information is put into the file from scratch. The log file in its entirety can be seen here.
This information is vital. It describes the service name, the service version and the creation date of the executable. The Fully Qualified Domain Name of the server is given as well as the operating system. The scope that the service runs in and the process ID is also part of the log header and can often help determining causes of error. The amount of free physical and virtual memory available at start up is a definite nice-element in case of other issues on the server interfering with the service. At last, the network state is displayed. It is of course essential to a service that synchronizes data between servers for a living, that the server is actually connected to the network. Initializing the log file is very important since it covers everything that the service does and because it is the primary source of information in the event that an error should occour.
The CiSync Settings.xml settings file is then loaded. It contains information about how the service should connect to the database, such as authentication methods and encrypted credentials. If any command line parameters were supplied, they are listed next. In this case the service is instructed to run every synchronization job found in the sql database regardless of the planned time for each schedule. Wether or not the service was told to run in debug mode is also stated. The debug mode does not in itself change any functionality, but is sometimes requested by the CapaInstaller Support team in the case of errors.
Connecting to the sql server is another critical step in actually getting some data synchronized since the service needs to find itself in the database to justify its own existence. First the sql server is shown, and indented the database name and the authentication method. There are three possibilities
- SQL - This means that the service will connect to the sql server with supplied sql credentials. The password is encrypted.
- WINDOWS - The computer is already granted access, because there exists an sql account for the server.
- WCF - Connection to the sql server is done via the Data Connection Service (DCS) which supplies HTTP/HTTPS access to the sql server inside the firewall.
Per definition the ciSync service does know where it is located or where the DCS is located, so if there is more that one url to the DCS they are tried on turn basis, starting with the one that can be reached directly, the Internal url. Connection was made on the internal url.
Now that an sql connection is established, there are a few facts to get straight. The first thing is to track down the service id. This is important because synchronization jobs are listed per server ID. This means that ciSync services scan the Synccom and SyncJob table frequently and filter the data on the service id (The SYNCSERVICEID column in the SYNCJOB table).
The service GUID and the server role are mostly shown for convenience for the log viewer.
For any communication to work, the relevant ports mus be opened. Natively ciSync communicates on HTTP but can additionally communicate on HTTPS. In this case the ports 8036 and 8037 are used. Default values are HTTP port 80 and HTTPS port 443. When working with firewall ports it becomes clear that you can open the same port on different networks (profiles). Workgroup servers has a Public Profile and a Private Profile. Servers that are part of a domain also sports the Domain Profile. Each port on each profile is then checked to be opened or opened and checked to be enabled or enabled. In the log file there is a difference checking a port to be open and opening a port. When the log says; 'is open' then the port was already open. When it says; 'is now open' then it means that the port was initially closed, but the service opened the port. The same goes with 'enabled' and 'now enabled'. Firewall ports can be altered from many places. Therefor the ciSync service checks and ensures throughput on a regular basis via the Synchronization service idle check.
If HTTPS communication is setup there will need to be a certificate installed on the parent server. In this case its a star certificate located in the Personal Store.
The certificates are identified by their thumbprint, since certificate names are ununique. For the certificate to work, it must be bound to the HTTPS port. The service checks that it is, and binds it if it's not already bound.
In order to communicate with child servers the ciSync service must establish service-hosts containing endpoints to do so. Two endpoints are needed per protocol. The general endpoint handles all comminucation/negotiation between parent and child, and when it comes to the actual data transfer it is streamed on the transfer endpoint.
To test that the service-hosts and endpoints are actually working, the service performs a loop-back test on each protocol, and if configured for the server, the Public url is tried as well. In case of an error, it is always nice to be able to out rule half of the equation, and by testing the server part, any bug-tracking can concentrate on the client part. The public url test is a bit tricky, because this means that the service must access itself by entering the firewall from the outside. In many cases, the ability to do this has been revoked by the systems administrator, and therefor this test is only partly useful.
Now that the service is running, is connected to the sql server and has established a service-host, it is time to connect to the parent server. The sql server identifies the parent server from the Service ID and Service Role. If the server is both a management server and an OS server, the OS server ranks higher. When a synchronization job, with this server as target server, is running, then the source server is automatically deemed the parent server. The parent server can be contacted on the internal URL as well as via the public url, and in both cases HTTP and HTTPS can be selected. With more that one choice, the server alternated between them, starting with the internal url for speed. In this case the internal url worked just fine, and two clients were hooked up to the equivalent endpoints, general and transfer.
Servers in the top of the server hierarchy does not connect to a parent server
Once connected, the parent server is queried for file version of the service. If the parent service is newer, then the parent service is requested to 'zip' itself and hand over the goods. When received, the zip file is decompressed, and the ciSync service calls the selfupdate utility, which will in turn stops the service, replaces the executables with the new ones and then starts the service. In this example the parent service version was found to be of equal version.
The last initialization act is to start the various timers. Their job is listed below;
Check the internal schedule for synchronization jobs that are due to run.
Query the parent server with the security token for maintenance.
Deliver a heartbeat in the SQL server to signal activity.
The service is now up and running. Ready to receive orders from the sql server.