Preface:
After some time, I finally managed to continue working on the hardening script and integrate a number of new ideas.
This time my approach was slightly different. Besides improving and restructuring the coding style to make the script easier to read and maintain, I also tried to integrate the recommendations from the Veeam Security & Compliance Analyzer directly into the script. The idea behind this was simple: instead of running multiple scripts separately, the hardening script should already cover the most relevant checks and configurations in a single run.
From my perspective, this worked out quite well. However, it is still a good idea to run the original Veeam Security & Compliance Analyzer from time to time. The Analyzer also includes checks that go beyond the operating system itself and look at the broader Veeam environment. Those aspects are intentionally not fully replicated in this script, as the focus here remains primarily on operating system hardening for Veeam-related workloads.
I also decided to provide both the script for Veeam components and the script version for PAWs (Privileged Access Workstations) together so you can now download both versions of the script and refer to this article.
The changes compared to previous versions can be found in the change log below!
Disclaimer:
Important: I do not provide any guarantee that the script, which has been successfully tested by me, will run without errors in every environment. The script is intended solely to simplify and standardize hardening standards, which may not be suitable for every environment! Additionally, I do not guarantee the completeness of the tests!
Requirements and procedure:
The scripts are designed for new and existing installations. They supports systems that have used a previous version of my script before as well as systems that have not been hardened and optimized at all.
- The server must not be a domain member
- Initial script execution (new installations only) must be performed with the built-in Administrator
- Script execution for pre-hardened systems can be performed with any administrator
- OS: Windows Server 2022 or 2025 Standard or Datacenter
Procedure for new installations:
- Install Windows Server (as required).
- Install drivers (VMware Tools or vendor-specific drivers).
- Set IP configurations (assign IP address, etc.) and disable IPv6 (optional).
- Set server name and workgroup, then restart the server.
- Create a folder named “Install” on drive C:.
- Copy the contents of the ZIP file (script and ntrights.exe) into the Install folder.
- Execute the script with administrative privileges (PowerShell) and select “new installation” when prompted.
- Allow the server to restart and install Veeam, specifying the service account.
- Apply / implement the Veeam Security & Compliance script.
Procedure for new installations (PAW only):
- Install Windows Server (as required).
- Install drivers (VMware Tools or vendor-specific drivers).
- Set IP configurations (assign IP address, etc.) and disable IPv6 (optional).
- Set server name and workgroup, then restart the server.
- Create a folder named “Install” on drive C:.
- Copy the contents of the ZIP file (script and ntrights.exe) into the Install folder.
- Execute the PAW script with administrative privileges (PowerShell) and select “new installation” when prompted.
- Allow the server to restart and installtools as required.
Procedure for existing installations:
- Create a folder named “Install” on drive C: (if not already existing).
- Copy the script into the Install folder.
- Execute the script with administrative privileges (PowerShell) and select “existing installation” when prompted.
- Allow the server to restart and verify Veeam service availability (await the services set to “delayed start” by default).
- Apply / re-run the Veeam Security & Compliance script.
Procedure for existing installations (PAW only):
- Create a folder named “Install” on drive C: (if not already existing).
- Copy the script into the Install folder.
- Execute the PAW script with administrative privileges (PowerShell) and select “existing installation” when prompted.
- Allow the server to restart and verify tool availability (as required).
Note: ntrights.exe is not required for existing installations.
Important: I recommend familiarizing yourself with the content listed below, as it introduces changes that may affect the operation of the system!
For example, an idle timeout of 15 minutes is configured. This means that an active session will be disconnected after 15 minutes, and all open windows and processes within that session will be terminated. This does not apply for the PAW script!
Windows Server 2025 – CIS Benchmark:
The contents of the scripts are still based on the CIS Benchmark, which my previous employer has kindly provided access to.
I reviewed v1.0 of of the Benchmark for Windows Server 2025 and ran multiple tests and consulted colleagues deeper involved into Windows OS to decide on which sections and settings to focus.
After running multiple tests and going through the Benchmark for Windows Server 2022 the script and the applied settings and options can be set for Windows Server 2022 and Windows Server 2025.
Veeam Security & Compliance Analyzer:
As mentioned earlier, I tried to incorporate the recommendations and configuration checks from the Veeam Security & Compliance Analyzer into this hardening script. While the overall goal was to align with the Analyzer’s guidance, the actual implementation was adapted to match the coding style and structure already used throughout the script. This keeps the code consistent, easier to maintain, and ensures that all changes follow the same logging and compliance-check logic.
One important exception is RDP. The script intentionally does not disable Remote Desktop. In many environments – including my own – the script is typically executed through an RDP session. Automatically disabling RDP would immediately lock you out of the server you are currently working on.
Another point worth mentioning is Credential Guard. The script includes the relevant registry settings to prepare the system for Credential Guard, but it does not fully enable it on its own. Properly activating Credential Guard requires additional platform prerequisites and configuration, most importantly Virtualization-Based Security (VBS). Depending on the system, this may involve BIOS/UEFI settings, Secure Boot, and virtualization support. As a result, some manual configuration steps may still be required on the server to fully enable Credential Guard.
Please find the Veeam script here: https://www.veeam.com/kb4525
SMB v3 (encryption):
Another improvement in version 1.3 is the enforcement of SMB v3 encryption on the server side. SMB 3 introduced several security enhancements compared to older versions of the protocol, with encryption being one of the most important ones. When SMB encryption is enabled, data transferred between the client and the server is encrypted in transit. This helps protect sensitive data from interception or man-in-the-middle attacks, especially in environments where backup repositories or administrative shares might otherwise be accessible over the network.
From a hardening perspective, enabling SMB encryption adds an additional layer of protection for file-based workloads and administrative access paths. In the context of backup infrastructure, this can be particularly valuable, since backup repositories often contain large amounts of sensitive or business-critical data.
However, it is important to be aware that not all systems fully support SMB v3 encryption. Older devices – for example some NAS systems or legacy appliances – may only support older SMB dialects or may not handle encrypted SMB sessions correctly. In such cases, enabling mandatory SMB encryption can lead to connectivity issues. Therefore, before enforcing this setting in production, it is advisable to verify compatibility with all systems that need to access the server via SMB.
System language check:
A small but important improvement came from a real-world test. I got feedback from a very special friend of mine who tried to run the script on a German Windows installation in his lab. This actually resulted in a useful feature request and led to the addition of a language check at the beginning of the script. If the check fails, the script will simply stop and not continue.
The requirement is straightforward: the operating system UI language (specifically the UICulture value) must be set to English. The reason for this is that several Windows components use localized names, especially built-in local user groups. The script currently references these groups using their English names, which would not match on systems installed in other languages.
For example, the local group “Administrators” on an English system is called “Administratoren” on a German system. Without an English system language, certain commands in the script would therefore fail or behave unpredictably.
So yes — this feature was added after a practical test scenario.
Shoutout to Markus Hartmann!
Test scenarios:
I ran multiple tests to ensure the correct deployment of the policies and to make sure that the scripts do not interfere with Veeam product installations. The following Veeam products and components have been tested successfully on Windows Server 2022 and 2025:
- Veeam Backup & Replication v13
- Veeam Enterprise Manager v13
- Veeam components:
- Proxy server
- Repository server
- Tape server
- WAN Accelerator
- Backup & Replication Console
- Cloud Gateway Server
- Veeam ONE v13
- Veeam Recovery Orchestrator 7.2.1
- Veeam Backup for M365 v8
- PAWs (with tools like Veeam Backup & Replication Console and Veeam ONE Console installed)
Downloading the script:
Within the Veeam Community, the scripts, including all related information, is available for download at:
Here is the corresponding GitHub link:
https://github.com/lukas-kl/veeam-win-hardening-script
Execution & script contents (ReadMe):
The scripts must be executed with administrative privileges!
The scripts, including the ntrights.exe file, must be located in and executed from the following path:
C:\Install
ntrights.exe (only required for new deployments):
The tool “ntrights.exe” is used to modify the local security policy of the Windows system and set various rules. The required .exe file is provided in a tested version, but it can also be downloaded manually if preferred. This tool is well-known and originates from the Windows Server 2003 Resource Kit.
Change Log v1.3 PAW (as of 03/12/2026):
- Removing the option of creating service accounts
- Removing the RDS / RDP idle limit of 15 min
- Removing the RDS disconnect limit of 1 min
- See v1.3 “base version” below
Change Log v1.3 (as of 03/12/2026):
- Editing multiple descriptions and removing typos
- Added a check, if the OS language (UICultute) is English (if not, cancel script run)
- Added enhanced logging framework:
- Added central script version variable
- Added structured logging output in JSON format
- Added optional transcript support
- Extended Write-Log with:
- log levels: info, success, error, warn
- status values: changed, alreadycompliant, failed
- component tagging for cleaner log output
- timestamped human-readable log lines
- machine-readable structured log output
- Added idempotent helper functions
- Added new security helper functions:
- Enable SMB Server Encryption
- Disable NetBIOS on all adapters
- Added additional service hardening:
- Disabled RemoteRegistry
- Disabled WinHttpAutoProxySvc
- Disabled WinRM
- Added additional protocol and network hardening:
- Added SMB server-side encryption enforcement
- Added explicit NetBIOS disablement across network interfaces
- Added additional application and scripting hardening:
- Disabled Windows Script Host
- Added additional credential protection:
- Added Credential Guard related settings:
- EnableVirtualizationBasedSecurity
- RequirePlatformSecurityFeatures
- LsaCfgFlags
- Added Credential Guard related settings:
- Added safer WinRE / recovery handling:
- Added disk layout snapshot logging before and after destructive actions
- Added more defensive recovery partition detection
- Added safer C: partition extension logic
- Added fallback logic for partition extension
- Registry values are now checked first, and the script distinguishes between:
- Already compliant
- Changed
- Failed