Configuring WinSyslog

In this chapter, you will learn how to configure WinSyslog.

The WinSyslog runtime service runs in the background once it is configured. There is no manual intervention needed to operate it. As such, this chapter focuses on the WinSyslog Configuration Client application. It is used to configure input services, rulesets, actions, and related settings.

To run the WinSyslog Configuration Client, simply click its icon present in the WinSyslog program folder located in the Start menu. Once started, a window similar to the following one appears:

• Configuration Client*

The configuration Client (“the Client”) has two elements. On the left-hand side is a tree view that allows you to select the various elements of the WinSyslog system. On the right-hand side are parameters specific to the element selected in the tree view. In the sample above, the right-hand side displays the specific parameters for a rule action.

The tree view has three top-level elements: General / Defaults, Running Services, and RuleSets.

Under General / Defaults, basic operational parameters as well as defaults for actions and services are defined. The defaults themselves do not activate anything. However, the parameters here are used each time an actual service or action needs a configuration parameter and none is defined in that specific instance. We highly recommend putting the most common parameters into the defaults, which reduces the amount of data entry in the specific elements dramatically. Please note that each default can be overwritten in a specific service or action.

The tree view’s Running Services area lists all configured services as well as their parameters. There is exactly one service entry for each configured input or generator that you create. Please note that there can be as many instances of a specific service type as your application requires. Typically, there can be multiple instances of the same service running, as long as their port, address, and transport settings do not conflict. For example, there can be multiple Syslog server services on a given system as long as they listen on different combinations. For example, there could be three of them: two on the default port of 514, one with TCP and one with UDP, and a third on UDP port 10514. All three can coexist and run at the same time. If these services try to use the same effective port, address, and transport combination, Windows logs an error and WinSyslog cannot perform the intended message intake.

In this manual, input is the clearest plain-language concept for receive configuration, while service remains the main operational term for these configured WinSyslog objects. Some GUI labels still use names such as Syslog server and RELP Listener. Those are exact current service names in the client. For the terminology mapping, see What do “service”, “input”, “listener”, and “server” mean in WinSyslog?.

For the general port, address, and transport conflict rule, including why TCP and TCP+TLS cannot share the same IP address and port, see How Do Port, Address, and Transport Conflicts Work for Input Services?.

Theoretically, you can run a few hundred services in a single service instance. However, both from a usage scenario point of view as well as concerning operating system resources, we recommend limiting the services to a maximum of 20 to 30. Of course, there are some applications where more than this limit is useful. WinSyslog does not restrict this number. If there is a need for a large number of services and the hardware is capable of managing all these tasks, there is nothing in WinSyslog that limits from doing so.

The actual parameters depend on the service type. Common to all services is the capability to enable or disable a service. A service is started only if it is enabled. Otherwise, it will not run, but the configuration data can still be present. That way, it is easy to temporarily disable an input service without deleting it.

Also common to all service types is the association to a ruleset seen at the bottom of the right-hand configuration dialog. This specifies which ruleset processes the information units generated by this service.

To create a new service, right-click on “Running Services”. Then select “Add Service” and the respective service type from the pop-up menu. Then follow the wizard. To delete an existing service, right-click it and select “Delete Service”. This removes the configured input or generator, and its configuration is now irrecoverable. To temporarily remove a service from operation, simply disable it in the property sheet.

The tree view’s last main element is RuleSets. Here, all rulesets are configured. Directly beneath “Rules” are the individual rulesets. Each set is completely independent of the others. They are just centrally stored so they can be associated with services (see above for an explanation).

Beneath each ruleset are the individual rules. As described in Rules, a rule’s position in the list is vitally important. rules at the top of the rule set are executed before those further down. To move a rule up or down, simply right-click it and select “move up” or “move down” from the pop-up menu.

In the tree view, filter conditions and actions are beneath the rule they are associated with. Finally, beneath actions are all actions to carry out.

The following sections describe each element’s properties.