I'm trying to standardize how we deploy and harden new Windows Server 2025 domains. The environments may range from a single domain controller to two domain controllers with several Windows Server application servers.
I've been testing OSConfig, but applying the configuration individually to every server feels difficult to maintain once machines join the domain. Group Policy seems more practical because it provides centralized management.
Would it be better to use Microsoft's Windows Server 2025 Security Baseline through Group Policy, or is OSConfig now the preferred approach? I'd also appreciate advice on deploying a baseline safely to existing Windows Server 2022 domains and handling compatibility issues with applications and legacy devices.
4 Answers
For production environments, I’d strongly recommend two domain controllers and keeping application roles off them. A single controller may be acceptable for a very small or temporary installation, but it creates a single point of failure.
The baseline should also be treated as a living standard. Review it whenever Microsoft releases an updated version, compare it with the current configuration, and retest before making changes. For larger environments, automated compliance and configuration-management tooling can help, but the policies and approved exceptions should still be centrally documented and controlled.
For a repeatable domain standard, I’d use Microsoft’s Security Compliance Toolkit and apply the Server 2025 baseline through GPO. Test it in a separate OU first, then move it into production gradually. OSConfig may be where Microsoft is heading, but it currently feels more like a per-machine configuration tool than a complete centralized management solution for domain-joined servers.
Use the baseline as a starting point rather than assuming it covers everything. Add controls such as Windows LAPS, administrative tiering, Protected Users for privileged accounts, SMB and LDAP signing, and disabling NTLMv1 and SMBv1 where compatibility allows. Keep application servers and domain controllers in separate OUs so their policies can be tailored appropriately.
Also test for older backup agents, scanners, printers, database clients, and line-of-business applications. A baseline can expose dependencies that nobody realized were still in use. Apply it to a lab or test OU, monitor it for several days, and only then expand the scope. Policy Analyzer is useful for comparing the live configuration with the intended baseline and detecting drift.
CIS Benchmarks are a good reference if you want a detailed hardening standard, and the national Windows security guidance is worth reviewing as well. In practice, manage the settings with GPO instead of relying on local policy. It is much easier to track exceptions, apply different rules to domain controllers and member servers, and maintain the configuration as the environment changes.
Build and validate the policies in a test lab, document any deviations from the benchmark, and promote them in stages. Avoid applying a fresh baseline directly to production because changes to authentication, SMB, or security policy can interrupt older applications.
STIG guidance is another free source of hardening recommendations. I’d use it alongside the Microsoft baseline rather than blindly applying every setting. Create the GPOs in a test environment, use security filtering or separate OUs where necessary, and record the exceptions required by supported applications. Centralized GPO management is safer and more scalable than configuring every new server locally.
That’s useful for existing domains too. I was mainly concerned that importing the baseline would require a huge amount of customization, but testing it in a separate OU should make the compatibility issues much easier to identify before deployment.