This article explains how to manually install a SystemWeaver Server on Microsoft Windows. A video demonstration is included at the bottom of this page. When the server installation is done, we recommend you follow the instructions under What's Next?.

• Prerequisites
• Downloading the Software
• Installing the Server
• Configuring the Server
• Configuring the Log Files
• Creating the Internal Database (skip if using SQLite database)
• What's Next? 

Prerequisites

Hardware and Software Requirements

• Before installing SystemWeaver, you'll want to make sure the the server machine meets the minimum requirements for a SystemWeaver Server installation. These requirements are described in SystemWeaver Server - Software and Hardware Requirements and in the SystemWeaver Administration Manual in the client application Help
• The assumption is that you will have only one SystemWeaver server running on the machine.

Downloading the Software

The software is typically delivered via the SystemiteNAS file server as a zipped file.  

If you are having trouble downloading or accessing your delivery, contact support@systemweaver.com.

Installing the Server

SystemWeaver includes a number of server related applications that can be configured and used depending on the needs of the user organization and the IT support organization. A list of all applications can be found in the Overview of SystemWeaver Applications section of the client application Help or in Summary of Main SystemWeaver Executables. This article covers the installation and configuration of the SystemWeaver main server application only. Other applications are covered in separate articles.

1. After downloading your delivery, move it from the Windows Download directory and place it on a local drive of the server machine, e.g., the C: drive. Tip: Place it in a folder called SystemWeaver, in a sub-directory called Deliveries.
2. Extract the files from the zip file. 
3. The server installation is in the directory called Server. The directory contains all of the files necessary to run the server. It is important that they remain intact, and are not modified in any way.
   
   

Configuring the Server

The server consists of two executables: 

• swDBServer.exe
• Systemite.SystemWeaver.TcpSubServer.exe. 

The swDBServer.exe is the main executable. 

The configuration file for the server is swServer.ini. 

There is no configuration file for the TcpSubServer.

In addition, there are two files for configuration of server logs:

• swServer.props (for the main executable logging)
• Systemite.SystemWeaver.TcpSubServer.exe.nlog (for the TcpSubServer logging). This is optional, but highly recommended.

The above two files will be covered later in this article. 

Note: If you do not see swServer.ini, swServer.props and Systemite.SystemWeaver.TcpSubServer.exe.nlog in the Server directory, you can find examples of them in the Configuration Files directory that is included in the delivery. Copy and paste them into the Server directory, then remove the ".example" suffix from the file name. They must be located in the same directory as the executables.

Formatting the swServer.ini

The swServer.ini file has the following content.

Note: Values to the right of the equal signs in the below example are only to illustrate the used format. This example is for configuring the main server so the [MirrorServer] section should remain commented-out. 

[MainServer]
dbType=SQLite
DSN=C:\temp\temp.sqlite
;JournalFile=C:\temp\temp.swjournal
;MinJournalEntries=10000
SyncJournalEntries=
FileRepository=
FileRepositoryType=DB/Files
DatabaseUser=
DatabasePassword=
DatabasePasswordEncrypted=
CallLogging=on/detailed
LogFileDirectory=
AllowLocalCache=True
[Tcp]
Port=1768
IP=
CertPassword=aaaa
AutoStart=False
DLQ=True/False
DLQFileDirectory=
DLS=True/False
[MirrorServer]
;MainServer=localhost
;MainServerPort=1768
;MainServerPassword=password
;MainServerPasswordEncrypted=
;Cache=D:\temp.cache
;CacheEncrypted=True/False
;CacheInMemory=True

1. In the Server directory, open the swServer.ini in a text editor. 
2. Configure the settings for your installation using the explanation below. 
3. Save your changes. 

MainServer

dbType

Required. Defines what type of database is being used. The following options are supported:

• SQLite - SQLite databases
• Oracle - Oracle databases
• MS SQL Server - SQL Server databases

DSN

Required. Defines the file path to the database. 

Examples

JournalFile (skip if not using a mirror server)

This entry is required only if a mirror server is in use. Enter the file path and file name of the journal file. See How to Configure a Main Server for Mirroring for journal initialization. 

MinJournalEntries (skip if not using a mirror server)

This entry can only be used if a mirror server is in use. This optional setting can be used to set a minimum number of most recent entries to be saved in the swjournal file which will limit the size of the file. We recommend the use of this setting if there is a very high level of transactions since the file can otherwise get quite large. 

How it works: If total > MinJournalEntries * 1.1, then remove MinJournalEntries * .1

Example: If you specify 10000, the number of entries will grow to 10000, then be somewhere between 10000 and 11000. In other words, without the limitation, the journal will store the total number of journal entries, e.g., 500000, whereas with the journal limitation, the server will remove old entries and maintain only the most recent 10000-11000 entries per this example configuration. 

The Journal file info tool in the swDatabaseManager will show the "First transaction id" and "Last transaction ID".

Organizations that want to limit the journal size will need to decide how many transactions to keep. Monitoring the .swjournal and using the swDatabaseManager tool to see how many transactions it contains and, e.g., how many there are on average per day, can help in making this decision.

SyncJournalEntries (skip if not using a mirror server)

This entry can only be used if a mirror server is in use. This optional setting, when set to "True", will allow the main server to run transactions found in the journal file upon start-up that are not found in the database. During normal operation on a local disk, there is no risk of this scenario occurring. However, this option does provide an automated way to handle an unforeseen synchronization problem should the need appear. We do not recommend the use of SyncJournalEntries=True by default, since it can potentially hide network/disk problems that you otherwise would want to be aware of. Please consult Systemite if you are considering using this option.

Warning: If this option is set to "True" and you want to revert to a backup database copy as a means of "wiping out" unwanted database transactions,  you will want to run Remove extra entries on the journal file before you start the server against the backup database.

FileRepository

Only required if a file repository is in use. Defines the file path to the file repository. If the FileRepositoryType is 'Files' the path should identify the folder under which the files will be stored. If the type is 'DB', the path defines the SQLite database file. (Currently, SQLite is the only supported database file repository.)

FileRepositoryType

Only required if file repository is in use. Defines the type of file repository. Valid values are 'DB' or 'Files'.

DatabaseUser

Required by some databases. The username for logging in to the database. This entry can be left empty in case no login is required.  If left blank, Windows authentication will be used. For non-SQLite database types, Windows authentication will only work if the user running the swDBServer process is added as a user with sufficient authorization in the database. 

DatabasePassword

Required by some databases. The password used for login to the database. This entry can be left empty in case no login is required. Note that this password is not a SystemWeaver user account password. If left blank, Windows authentication will be used. For non-SQLite database types, Windows authentication will only work if the user running the swDBServer process is added as a user with sufficient authorization in the database. 

DatabasePasswordEncrypted

Required by some databases. The encrypted password used for login to the database. An example use case is when the SystemWeaver Server is located on one physical server and the database server on another* and security policies prohibit that unencrypted passwords are sent on the network between the servers. This entry may be left empty in case no login is required. The SystemWeaver tool EncryptString.exe may be used for generating an encrypted password for this purpose.

CallLogging

Optional. Turns on extended performance logging in the server. When logging is activated, a new log file is generated each time the server is started, with automatically defined file names. Alternatives are 'on' for standard logging, 'detailed' for extended logging, and none (or any invalid entry) for no logging at all. CallLogging is only recommended for troubleshooting purposes. In normal operation, it should not be used. 

LogFileDirectory

Optional. Defines the file path to the CallLogging log file.

LogFileDirectory

Optional. Defines whether or not connecting mirror servers can use a local cache file or must use in-memory cache. Supported values are True or False. True is the system default. If AllowLocalCache is set to False, mirror servers connecting to the main server can only run using in-memory cache (CacheInMemory=True in mirror server swServer.ini). 

Tcp

This section is for configuration related to the TcpSubServer. 

Port

Required. Defines the TCP/IP port number to be used by the server. The port number for SystemWeaver has not been standardized. The Dynamic and/or private ports in the 49152-65535 range are allowed for use by the Internet Assigned Numbers Authority (IANA), but these may be in momentary conflict with other applications depending on the configuration of other applications on the server computer. Refer to e.g. http://www.iana.org/ for the use of port numbers.
In case there is no web server active on the SystemWeaver host computer, then the 443 port assigned to the https protocol can be used with no side effects for the SystemWeaver. In case a web browser tries to connect to the port, the request is simply ignored by the SystemWeaver server. Since the communication on 443 is assumed to be encrypted, no other network components should assume anything about the content of the communication. Note however that IANA does not approve the use of this number, likely due to the possibility of conflicts with any web server active on the host.
Port names must be unique on the host computer, and not used by any other application, including other SystemWeaver servers.
In case the access to the server from the user network will be through a proxy, the SystemWeaver client to server communication set up in SystemWeaver clients can be directed though the standard port (#8080) of the proxy. For access through firewalls and proxies, the server port 443 (https, see above) is useful since this port may offer remote access to SystemWeaver without the need to open new ports on the firewall.

IP

Defines the IP address or domain name to be used by the SystemWeaver server. This entry should only be used for the case that the server uses multiple IP addresses or domain names. Otherwise, leave blank.

CertPassword

Required if encryption is turned on (See UseSSL below). Used for authentication purposes in the TLS (Transport Layer Security) so that the SystemWeaver clients can detect the legitimacy of the server. Enter the certificate password here. For intranet use, authentication is normally not required and SystemWeaver is therefore distributed with dummy certificates, with the dummy password "aaaa". If there is a need for encryption, the provided dummy certificate should be replaced with a specific certificate file.

AutoStart

Optional. Enables the swTestServer to start and connect to the database immediately after the server application is started. Possible values are 'true' and 'false'. The value 'true' should normally be used only after the server configuration has been verified to be fully functional. The swDBServer.exe requires 'true' since this is the only way to start the server.

UseSSL*

Optional. Defines whether SSL/TLS should be used or not. Alternatives are 'true' for yes and 'False' for no. Within a closed network, 'false' could be used to improve robustness for network disturbances, while 'true' should be used for communications over Internet.

DLQ

Defines whether a .dlq file should be generated (True) or not (False). The default setting is False, but it is recommended that it be set to True, at least initially, since its content allows for proper analysis should there be issues with server performance. IT administrators should be aware that a .dlq file can take some space depending on the size and activity level in the server (e.g., 10GB for very large and active systems).

DLQDirectory

Define the file path for the .dlq file location. If left blank, the file will generate in the same location as the server executables. Note that the system account running the server must have write permissions to the directory being written to and the directory must exist. Otherwise, the server will not start. 

MirrorServer

This section can be ignored when configuring the main server. 

Configuring the Log Files

Since there are two server executables, you will want to configure a log file for each. The configuration files are: 

• swServer.props for the main swDBServer executable
• Systemite.SystemWeaver.TcpSubServer.exe.nlog for the Systemite.SystemWeaver.TcpSubServer executable

You can find examples of them in the Configuration Files directory included in the delivery or create your own. Instructions for how to configure these files can be found in How to Configure and Start Logging (for the main server) and How to Configure Logging for the TcPSubServer for the TcpSubServer.

Creating the Internal Database (skip if using SQLite database)

For non-SQLite databases only

If your organization is running an MS SQL or Oracle database, you will need to create the internal database that the SystemWeaver server uses. See Creating the Internal Database (for non-SQLite databases). If you are using a SQLite database file, you can skip this step.

Demo

What's Next? 

The SystemWeaver server is now installed, configured and ready to be tested. See Testing a SystemWeaver Installation for instructions on how to use the swTestServer utility to run the server.

* The availability of the encryption option is restricted due to EU regulations. Please contact us for more information.