Installation script
Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability This functionality is generally available and ready for production usage. Serverless interfaces and procedures might differ from classic Elastic Stack deployments. The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability This functionality is generally available and ready for production usage. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
Serverless
Generally available
Stack
9.0+
Generally available since 9.0
The installation script, install-service-winlogbeat.ps1 is responsible
for creating the Windows Service for Winlogbeat. Starting in 9.0.6, the
base folder has changed from C:\ProgramData\ to C:\Program Files\
because the latter has stricter permissions, therefore the home path
(base for state and logs) is now C:\Program Files\Winlogbeat-Data.
The install script (install-service-winlogbeat.ps1) will check whether
C:\ProgramData\Winlogbeat exits and attempt to move it to C:\Program Files\Winlogbeat-Data.
If an error occurs, the script will stop and print the error.
Then it will create the Windows Service setting:
path.homeas$env:ProgramFiles\Winlogbeat-Datapath.logsas$env:ProgramFiles\Winlogbeat-Data\logs
The script also supports passing the parameter -ForceLegacyPath to
use the old default C:\ProgramData\ that is set using
$env:PROGRAMDATA. However using -ForceLegacyPath is not
recommended.
In a PowerShell prompt, can use Get-Help install-service-winlogbeat.ps1 -detailed to get detailed help.
If there is a permission error when the installation script is moving the folder, ensure the user running the script has enough permissions to do so. If the problem persists, the folder can be moved manually, then the installation script can be executed again.