rsyslog Windows Agent 2026 — New major release, new licensing, new release cycle
Overview
rsyslog Windows Agent now ships on the 26.07 line (July 2026). This release line uses calendar-based YY.MM version numbers, a monthly update cadence, a license.alic license file, and a next-generation Configuration Client Preview in the installer.
If you are upgrading from rsyslog Windows Agent 8.x (or earlier), read this article before you deploy. Your existing registration name and numeric license keys do not apply on current builds—you need a new license.alic file from Adiscon.
A new way to read version numbers
Older product lines (through 8.x)
Historically, rsyslog Windows Agent used sequential version numbers that increased independently of the calendar. Different Adiscon products used different leading numbers (WinSyslog 18, EventReporter 19, MonitorWare Agent 15, and so on).
| Component | Legacy (8.x) | New (YY.MM) |
|---|---|---|
| Example | 8.3.0.236 | 26.07 |
| Year part | Sequential major 8 | Calendar year short form 26 (2026) |
| Month part | Feature release (e.g. 3) | Release month 07 = July |
Current YY.MM versions
Adiscon changed to calendar-based version numbers. In 26.07, 26 means 2026 and 07 means July. There are no missing intermediate product releases between the last 8.x builds and 26.07.
Later monthly builds in the same year continue as 26.08, 26.09, and so on. When the calendar year rolls forward, the year part advances (for example to 27.01).
New release cycle: monthly updates
Adiscon is aligning rsyslog Windows Agent with a predictable monthly rhythm:
- YY = calendar year (26 = 2026)
- MM = release month (01 = January, 07 = July, 12 = December)
- Regular monthly builds with fixes and improvements during the year
The current general-availability line for this announcement is 26.07 (July). You can plan upgrades knowing that 26.08, 26.09, and so on will arrive through the year. Detailed change lists belong in release notes, not in this overview.
Licensing: from name + keys to a license file
The largest operational change for upgrades from rsyslog Windows Agent 8.x is licensing. Older builds used a registration name and numeric license keys. Current builds use a license.alic file applied under General → License in the configuration client.
| Topic | Older product lines | Current builds |
|---|---|---|
| What you apply | Registration name + numeric license keys | license.alic file |
| Where in the client | License key fields | General → License |
| Optional path | N/A | szLicenseV2Path (path to the file) |
Important: Keys from rsyslog Windows Agent 8.x do not apply on current builds. Contact Adiscon support or sales to obtain a new license.alic for your edition.
Licensing
License file details and how to apply it
What you use now
| File name | license.alic |
| Default location | %ProgramData%\Adiscon\RSyslogAgent\license.alic |
| Configuration | szLicenseV2Path — optional path to the file (path only, not license text) |
| Client location | General → License |
Editions (Basic, Professional, Enterprise) still exist as commercial labels. Product limits such as Remote Event Log and client connections are enforced from entitlements in the license file. The main window status bar shows license status (for example, the licensed organization). A version mismatch between the license file and the installed service may show a warning banner until you apply a matching license.
How to apply the license file
- Obtain license.alic from Adiscon for rsyslog Windows Agent (correct edition and entitlements).
- Open the configuration client and select General → License.
- Browse for license.alic, drag-and-drop the file, or paste the file path.
- Use Verify License if you want to check the selected file before or after saving.
- Save the configuration.
- Restart the service so the updated license state is applied.
Configuration snippet (optional)
Administrators using file-based configuration may set an explicit path when they do not use the default location:
szLicenseV2Path C:\ProgramData\Adiscon\RSyslogAgent\license.alic
Frequently asked questions (licensing)
Do my 8.x license keys work on current builds?
No for activating current rsyslog Windows Agent builds. Current builds require a license.alic file. Contact Adiscon to obtain one.
Can I use an older product version with my current license?
Yes. Your license can cover older product versions. If the older version does not support license files, contact Adiscon support or sales and request a free license key for that product version.
Can I copy license.alic from another product?
No. Each license is issued for specific product SKUs (RSyslog-WA-Basic, RSyslog-WA-Pro, RSyslog-WA-Enter). The service rejects mismatched products.
What if license.alic is missing?
Without a valid license file, the product follows its normal unlicensed or evaluation behavior for that edition. Apply a valid license.alic under General → License, save, and restart the service.
Do I need internet activation?
No for normal operation. The license file is validated on the machine; you do not need online activation for routine use.
Upgrade
Upgrade path and compatibility
Upgrade planning for rsyslog Windows Agent 8.x to current builds should start with a license.alic request before production rollout. Install or upgrade to 26.07 (July) or a later 26.x monthly build.
Note: The rsyslog Windows Agent is Adiscon’s native Windows agent for rsyslog-compatible deployments—it is not the open-source Linux rsyslog project.
Next-generation Configuration Client Preview
The rsyslog Windows Agent installer for current builds includes two configuration clients:
- Established configuration client — familiar UI, updated for the license file page under General → License.
- Next-generation Configuration Client Preview — modern WinUI-based workbench (adiscon-client-ng), shipped as a preview alongside the classic client.
The preview is intended for early adopters. Both clients target the same service and the same license.alic file. Expect the preview label until Adiscon declares general availability.
What changed between 8.x and current builds (overview)
Current builds are a platform refresh, not a single-feature update. Alongside YY.MM versioning and monthly updates, they introduce a license.alic license file, expanded file/YAML configuration options, operational metrics (disabled by default), installer improvements, and ongoing reliability hardening across listeners, actions, and the core engine. For detailed changes in a specific month build, see the product release notes for 26.07 and later.
rsyslog Windows Agent continues to focus on reliable Windows log ingestion and forwarding in rsyslog-compatible deployments; the current line modernizes how you license, version, and configure the product. This is Adiscon’s Windows agent only—not the Linux rsyslog project.
Frequently asked questions (upgrade)
Where is the license file?
Default: %ProgramData%\Adiscon\RSyslogAgent\license.alic
Is the nextgen client required?
No. It is a preview. The classic configuration client remains supported for applying license.alic.
Where should backup tools copy the license?
Back up license.alic together with your configuration directory under the product’s ProgramData folder.
Next steps
- Existing customers: Contact Adiscon support or sales to request your license.alic before or during upgrade.
- New deployments: Install 26.07 or later, apply license.alic under General → License, verify status, then roll out rules and services as usual.
- Monthly updates: Check release notes for 26.07, 26.08, and subsequent monthly builds.
rsyslog on AWS – Update an existing CloudFormation stack
Welcome to this guide on updating an existing CloudFormation stack for the rsyslog server on AWS. In this tutorial, we will walk you through the steps necessary to ensure your rsyslog server is running the latest version with all the benefits of updated features and performance improvements. We will provide detailed instructions and screenshots to make the update process straightforward, ensuring minimal disruption to your logging setup. Whether you’re a seasoned AWS user or new to CloudFormation, this guide will help you achieve a smooth and efficient update.
Prerequisites
If changes were made to the rsyslog configuration, use the guide in this article to back up and restore configuration: AWS rsyslog Sync Configuration with S3.
Step 1: Select the CloudFormation Stack
To begin the update process for your rsyslog server on AWS, first, navigate to the AWS Management Console and go to the CloudFormation section. Here, locate the stack you wish to update.
- Visit AWS CloudFormation: Log in to your AWS Management Console and go to the CloudFormation service.
- Select Your Stack: Identify and select the CloudFormation stack for your rsyslog server. In this example, the stack is named “rsyslogtest”.
- Initiate Update: Click on the Update button, as highlighted in the screenshot above.
This will start the process to update your existing CloudFormation stack.
Click Update to proceed.
Step 2: Prepare the Template
After selecting the stack to update, the next step involves preparing the template for the update. Follow these instructions:
- Choose Template Option: In the “Prepare template” section, select the Replace existing template option.
- Specify Template Source: Under “Template source”, choose Amazon S3 URL.
- Enter S3 URL: Enter the following URL in the provided field:
https://rsyslogpublic.s3.amazonaws.com/office_rsyslog_server.yamlAlternatively, you can use the template URL provided on the AWS Marketplace product page for the rsyslog server.
This will prepare the new template to be applied to your existing stack.
Click Next to proceed.
Step 3: Specify Stack Details
After preparing the template, proceed to specify the stack details:
- Review Parameters: Ensure all parameters are correct. Adjust as necessary.
- Instance Settings:
- Identifier Name: Change if necessary.
- EC2 Instance Type: Change if necessary, as a new instance will be deployed.
Review all options carefully in case new features have been added.
Once all configurations are reviewed and adjusted, click Next to proceed.
Step 4: Configure Stack Options and Review
Review the stack options and make any necessary adjustments.
- Review Changes: Carefully review the list of changes in the “Change set preview”. Ensure all modifications align with your expectations.
- Submit: Once everything is reviewed and confirmed, click the Submit button to start the update process.
After clicking Submit, AWS will begin updating your CloudFormation stack. Monitor the progress to ensure the update completes successfully. If any issues arise, refer to the stack events for troubleshooting.
Step 5: Monitor the Update Process
- Monitor Progress: Check the events tab to monitor the progress of the update. The status should show “UPDATE_IN_PROGRESS” and various components being modified.
- Confirm Completion: When the update completes, ensure the status changes to “UPDATE_COMPLETE”.
Once the process is complete, verify that the CloudFormation stack was updated successfully by checking the final status and confirming that all intended changes were applied correctly.
Confirm EC2 Instance Running rsyslog Server
- Access the EC2 Instance: Use SSH to log in to your EC2 instance running the rsyslog server.
- Verify rsyslog: Once logged in, confirm that the rsyslog server is running properly. You should see the rsyslog welcome message, indicating that the application is installed and operational.
Check the rsyslog meta configuration located in /opt/rsyslog/config to ensure all settings are correct and the service is functioning as expected. This final verification confirms the successful update of your CloudFormation stack and the deployment of the new rsyslog server instance.
rsyslog on AWS – Version changelog
S2: v13 rsyslog
We are excited to announce the second public release of Rsyslog Server on AWS Marketplace. This version includes efficient logging, noise event filtering, and a streamlined web interface for system management. New features: Cloudwatch LogGroups, logfile compression, S3 log/config storage, enhanced CloudFormation support, and improved AWS region handling. Experience enhanced logging capabilities and simplified management with Rsyslog Server.
Key Features:
- Cloudwatch LogGroups Integration: Now you can leverage AWS Cloudwatch LogGroups for better log management and analysis directly through our CloudFormation templates.
- Logfile Compression: Enabled logfile compression to optimize storage and improve performance.
- S3 Bucket Support: Added S3 support for both log storage and configuration backup, ensuring your data is safely stored and easily accessible.
- Improved AWS Region Handling: Fixed issues with AWS_REGION in rsyslogctl to automatically use the correct region configuration.
- Configuration Sync to S3: Fixed the sync_config_history_to_s3 feature, ensuring your configuration history is consistently backed up.
- Enhanced CloudFormation Features: Added new features, including S3 support, access policies, and additional InstanceTypes, to our CloudFormation file for easier and more flexible deployments.
- EFS Resource Management: Added Delete and Retain policies to EFS resources to ensure they survive a Stack Update.
S2: v12 rsyslog
We are excited to announce the inaugural public release of the official Rsyslog Server product on AWS Marketplace. This release introduces an efficient logging solution right out of the box. Additionally, it empowers users with seamless configuration options to filter out noise events and includes a streamlined web interface for system operation management. Get ready for enhanced logging capabilities and simplified management with the Rsyslog Server.
rsyslog on AWS – Sync Configuration with S3
Ensuring the integrity and availability of your rsyslog configuration is crucial for maintaining a robust logging system. By syncing your rsyslog configuration to AWS S3, you create a reliable backup that can be easily restored when needed. This guide will walk you through the process of syncing your rsyslog configuration to S3 and restoring it when necessary.
Prerequisites
Before you begin, ensure you have the following:
- rsyslog server from AWS Marketplace with at least Version S2: v13 rsyslog
- S3Bucket (Is created by default since S2: v13 rsyslog or higher).
Syncing Configuration History to S3
This command synchronizes the current rsyslog configuration history to a specified S3 bucket. It ensures all configuration changes are backed up, providing a reliable recovery solution.
sudo rsyslogctl sync-config-history-to-s3
When executed, this command uploads your rsyslog configuration history to the S3 bucket configured in your settings. Regular execution of this command, especially after making significant changes, ensures your backups are always current.
Restoring Configuration from S3
This command downloads the rsyslog configuration history from an S3 bucket to the local machine, facilitating configuration restoration.
sudo rsyslogctl sync-s3-to-config-history
Executing this command retrieves the configuration history from S3 and applies it to your local rsyslog setup.
RSyslog Windows Agent 4.3c Released
Adiscon is proud to announce the 4.3c release of Rsyslog Windows Agent.
This release contains some a minor bugfix.
Detailed information can be found in the version history below.
Build-IDs: Service 4.3.0.178, Client 4.3.0.255
Version 4.3c is a free download. Customers with existing 3.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.
Bugfixes |
|
RSyslog Windows Agent 4.3b Released
Adiscon is proud to announce the 4.3b release of Rsyslog Windows Agent.
This release contains some a minor bugfix.
Detailed information can be found in the version history below.
Build-IDs: Service 4.3.0.177, Client 4.3.0.255
Features |
Bugfixes |
|
Version 4.3b is a free download. Customers with existing 3.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.
rsyslog 8.32.0 (v8-stable) released
Today, we release rsyslog 8.32.0. This realease, again, sports a vast number of changes. E.g. there are a number of new or updated build requirements, namely: libfastjson 0.99.8, libczmq >= 3.0.2 and libcurl. Otherwise most notably is the major update that ompgsql has received through contribution. Other changes include modules like pmrfc3164, omhiredis, mmexternal, omprog, imfile, omfile, mmpstrucdata. The full list of changes to rsyslog can be reviewed in the Changelog.
We have also made some major changes to the RHEL/CentOS packages for rsyslog. We are now using a modified spec file from the CentOS base repository for building the EL7 release RPM. We decided to go this way out of several reasons. The major reason was a huge issue with the startup scripts that we used, which did not really work well on EL7 systems. More details are available here: http://www.rsyslog.com/major-centos7-rpm-changes/ and here: https://github.com/rsyslog/rsyslog/issues/2134#issuecomment-355483536
Another reason is, that we wanted to make our own RPMs more similar to those in the base repository to avoid major conflicts in the future. That also means, that some additional module packages are not available anymore, because they are now included in the base rsyslog package (mmanon, mmutf8fix, ommail and pmaixforwardedfrom). All other additional sub-packages are still available.
Because the Launchpad build environment [1] is currently unavailable, we cannot produce packages for Ubuntu at the moment. They will be published once the systems are available again.
https://github.com/rsyslog/rsyslog/blob/v8-stable/ChangeLog
Download:
http://www.rsyslog.com/downloads/download-v8-stable/
As always, feedback is appreciated.
Best regards,
Florian Riedl
[1] https://lists.ubuntu.com/
Major CentOS7 RPM changes
We made some major changes to the way the RPMs for CentOS7/RHEL7 are built. We have adapted the spec file definitions of the base repo to build our own RPMs after we detected some trouble with the last released version. That means, that some things will also change, so our RPMs are more like the official ones.
Stock CentOS 7 8.24.0 package to 8.32.0-1 package upgrade
The upgrade completes and the same functionality present before is present here. Because the syntax was obsolete legacy format before and the format is obsolete legacy format now the /etc/rsyslog.d/listen.conf file passes validation checks (rsyslogd -N6) without issue.
That said, the /etc/rsyslog.d/listen.conf file doesn’t really do anything because the /etc/rsyslog.conffile disables local logging and the /usr/lib/systemd/system/rsyslog.repo unit file doesn’t enable socket activation (basically the symlink from /etc/systemd/system/syslog.service to /usr/lib/systemd/system/rsyslog.service wasn’t created and systemd doesn’t create the /run/systemd/journal/syslog socket for rsyslog to read from).
Not a problem here because the conf file was stock before and is still stock (now upstream Adiscon copy), so imjournal is used to pull log messages (API?) instead of via a socket.
Adiscon repo 8.31.0-4 stable package (with unmodified Adiscon RPM config) to 8.32.0-1 package upgrade
After installing the 8.31.0-4 package (the last one), systemctl disable rsyslog; systemctl enable rsyslog and that workaround seemed to allow that version to function as expected (restart, start, stop). A now performed upgrade to the new package and rebooted. Prior to that, attempting to run systemctl status rsyslogwarned me that I should run systemctl daemon-reload (or restart) to sort things out.
After a restart, all stock settings appeared to function normally. The upgrade (yum install rsyslog) pulled in the needed libfastjson package version without my explicitly specifying to install that package. The /etc/rsyslog.conf file included in the previous stable version was replaced, but this was to be expected because I did not modify the previous conf file (thus the checksums match).
Adiscon repo 8.31.0-4 with custom config to 8.32.0-1 package upgrade
In short, the symlink from /etc/systemd/system/syslog.service to /usr/lib/systemd/system/rsyslog.service wasn’t created and systemd doesn’t create the /run/systemd/journal/syslog socket for rsyslog to read from. In a setup where imuxsock is used, not imjournal this means that rsyslog was not able to read from the socket. To restore this functionality, you have to create a drop-in to restore the socket activation.
Once you did that and either rebooted or ran systemctl daemon-reload, the /run/systemd/journal/syslogsocket was restored.
Addendum
Unmodified configurations should continue to work as before, so there is that.
Users of rsyslog who are using the Adiscon RPMs for a while now, may notice a change in the available module packages because the modules are now incorporated in the basic rsyslog package as in the RPM from the base repo. The affected module packages are (now no longer needed):
rsyslog-mmanon
rsyslog-mmutf8fix
rsyslog-mail
rsyslog-pmaixforwardedfrom
libfastjson 0.99.8 released
This is a new fork of the json-c library, which is optimized for liblognorm processing.
This release provides several fixes to libfastjson. Most notably is the bugfix for proper handling of constant key names. For more details, please refer to the changelog below.
Changelog:
0.99.8 2017-12-18
– make build under gcc7 with strict settings (warning==error)
– bugfix: constant key names not properly handled
if fjson_object_object_add_ex() is used with option
FJSON_OBJECT_KEY_IS_CONSTANT, fjson_object_object_del() will still
try to delete the key name. Depending on use, this can lead to
double-free, use-after-free or no problem.
see also https://github.com/rsyslog/rsyslog/issues/1839
closes https://github.com/rsyslog/libfastjson/issues/148
– fix potentially invalid return value of fjson_object_iter_begin
this could lead to callers doing improper opreations and thus
could lead to a segfault in callers
detected by Coverity scan, CID 198891
– fix small potential memory leak in json_tokener (unlinkely to occur)
detected by Coverity Scan, CID 198890
Download:
http://download.rsyslog.com/libfastjson/libfastjson-0.99.8.tar.gz
sha256sum: 3544c757668b4a257825b3cbc26f800f59ef3c1ff2a260f40f96b48ab1d59e07
As always, feedback is appreciated.
Best regards,
Florian Riedl
rsyslog 8.31.0 (v8-stable) released
Today, we release rsyslog 8.31. This is probably one of the biggest releases in the past couple of years. While it also offers great new functionality, what really important about it is the focus on further improved software quality. For a more detailed description, please read Rainer’s blog post. Detailed information about the huge list of changes is available in the changelog.
http://blog.gerhards.net/2017/11/rsyslog-831-important-release.html
The packages have received some notable changes as well. First off, we were able to implement the Redis output module as a separate package on Ubuntu 14.04 and newer. Also there was a dependency change for the ommongo module, thus it is now only available on Ubuntu 16.04 or newer, but not on CentOS/RHEL anymore. Platform restrictions are unavoidable right now due to dependency availability.
https://github.com/rsyslog/rsyslog/blob/v8-stable/ChangeLog
Download:
http://www.rsyslog.com/downloads/download-v8-stable/
As always, feedback is appreciated.
Best regards,
Florian Riedl