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.
New Liblognorm 2.1.0 release
We are pleased to announce the release of liblognorm 2.1.0, the fast lognormalization library.
liblognorm 2.1.0 introduces TurboVM, a new optional bytecode engine for high-performance log normalization. TurboVM compiles rulebases into optimized bytecode and provides a faster execution path for applications that choose to enable it with ./configure --enable-turbo.
This is a major feature for liblognorm itself, not only for rsyslog. Any liblognorm consumer can add TurboVM support and use the new fast path. rsyslog users are expected to benefit strongly through matching mmnormalize integration work, but the capability is available at the library level.
rsyslog 8.2606.0: stream compression, Elastic Beats input, and ongoing defensive hardening
We have released rsyslog 8.2606.0, the June 2026 scheduled-stable version. Scheduled-stable releases are bi-monthly snapshots of the daily-stable branch, providing predictable update points with the same functional content as daily-stable at the time of the snapshot.
The main theme of this release is operational robustness under pressure: reducing forwarding bandwidth with experimental stream compression, adding Elastic Beats input support for selected pipeline use cases, and continuing the defensive hardening work across the code base.
The three changes that deserve the most attention are:
- Experimental TCP stream compression for
omfwdtoimtcp - New Elastic Beats / Lumberjack input module via
imbeats - Continued defensive hardening and reliability work
Rsyslog Windows Agent 8.3 Released
We have just released Rsyslog Windows Agent 8.3, bringing enhanced interoperability, modern configuration options, and deep operational visibility to our professional Windows-to-Linux logging bridge.
A major highlight of this release is the introduction of YAML configuration support. By adding file-based YAML support for service configuration files, rsyslog Windows Agent now allows administrators to utilize human-readable, industry-standard formatting for their configuration logic. This facilitates easier integration with DevOps toolchains and simplifies the management of complex forwarding rules across diverse Windows environments.
Operational transparency has also been significantly improved with the addition of Runtime Metrics. Administrators can now enable a dedicated HTTPS query endpoint to access real-time service metrics. This feature allows for the direct monitoring of event throughput and service health, making it simple to pull performance data into centralized monitoring systems.
Furthermore, rsyslog Windows Agent 8.3 is ready for the next generation of infrastructure with enhanced Windows Server 2025 support, including improved message fallback and custom-channel cleanup within the Event Monitor service.
Continue reading “Rsyslog Windows Agent 8.3 Released”rsyslog 8.2604.0: YAML configuration, Azure Monitor output, and stronger hardening
We have released rsyslog 8.2604.0, the April 2026 scheduled-stable version. Scheduled-stable releases are bi-monthly snapshots of the daily-stable branch, providing predictable update points with the same functional content as daily-stable at the time of the snapshot.
This release makes rsyslog easier to configure, easier to integrate with modern observability platforms, and more robust under failure conditions.
Four major highlights:
- YAML as an alternative configuration format
- Azure Monitor and HTTP ecosystem integration
- Reliability and security hardening
- Packaging, CI, and portability improvements
rsyslog gains native Azure Monitor Logs Ingestion support
Cloud logging environments are rarely simple. Many organizations run mixed estates where on-prem systems, private infrastructure, and cloud services all need to feed into a central observability workflow. That is exactly where rsyslog is supposed to help: reliable, flexible log transport and processing without forcing a one-size-fits-all architecture.
We have now taken another step in that direction.
With the merge of PR #6615 on March 18, 2026, rsyslog now includes a new output module, omazuredce, for sending events directly to Azure Monitor Logs Ingestion. The merged change includes the module itself, documentation, configuration parameters, build integration, and tests.
The rsyslog Evolution: Bridging BSD Heritage with Adiscon Innovation
It is a well-documented fact in the open-source community that rsyslog traces its lineage back to the original 1980s BSD syslogd developed by Eric Allman, primarily through the sysklogd fork. This foundation provided the industry with a standardized way to communicate system events for decades.
However, even before the digital landscape evolved into the era of high-velocity data, the original single-threaded BSD design was known by us to face significant performance bottlenecks. As such, we were well aware of the need to support multithreading.
Continue reading “The rsyslog Evolution: Bridging BSD Heritage with Adiscon Innovation”Docs moved to new Domain
We have today moved the rsyslog official documentation to https://docs.rsyslog.com/doc instead of our long-standing location directly on www.rsyslog.com/doc. All existing links will be properly redirected. The goal is to keep the all-important doc set on its own resource, which helps with scaling and ensuring availability of the documentation.
This move was considered for quite a while and has its pros and cons. The ultimate reason we are doing it, and doing it now is a cyberattack against rsyslog.com which began four days ago. While we mitigated it quickly, it led to unavailability of the doc for around one hour. That made us finally make the decision to move doc to a dedicated system, which we can make more robust than the full featured site with it’s dynamic content.
Continue reading “Docs moved to new Domain”rsyslog 8.2602.0: ROSI Collector, rate-limit policies, stronger TLS, and telemetry integration
We have released rsyslog 8.2602.0, the February 2026 scheduled-stable version. Scheduled-stable releases are bi-monthly snapshots of the daily-stable branch, providing predictable update points with the same functional content as daily-stable at the time of the snapshot.
This release introduces a new production-ready deployment stack and continues significant runtime and security hardening.
Four major highlights:
- ROSI Collector: centralized log collection stack
- Named rate limit policies for imtcp and imptcp
- Security and TLS hardening
- Telemetry and ecosystem integration
What rsyslog is today: a high-performance log ingestion and ETL engine
The site title and GitHub project tagline now describe rsyslog as a high-performance log ingestion and ETL engine.
This is a small but visible change. It reflects how rsyslog is actually used today in modern infrastructures, and it aligns the project’s public description with long-standing technical reality. It is not a rebranding exercise, and it does not change what rsyslog is compatible with or where it comes from.
If you have followed the project for a long time, the wording may stand out. That is intentional. It acknowledges an evolution that has been underway for years and that many users already rely on in production.
Continue reading “What rsyslog is today: a high-performance log ingestion and ETL engine”