How to Install WSUS on Windows Server and Run the Initial Configuration

WSUS is deprecated but still supported for production use on supported Windows Server releases. Microsoft is no longer adding new WSUS features, so new deployments should be evaluated against cloud-based alternatives – but the role remains valid for organizations that require on-premises update control, operate disconnected networks, or run Microsoft Configuration Manager.

A typical WSUS installation takes around 20 minutes on a healthy server. The configuration wizard usually takes another 10-15 minutes, excluding the initial synchronization, which can range from 30 minutes to several hours depending on product scope and internet speed.

The decisions that matter happen in the configuration wizard, not during role installation. Product and classification selection determines how much disk space you consume and how long that first sync takes. Getting it wrong does not break anything immediately – it creates a cleanup job six months later.

This guide covers WSUS installation on Windows Server 2016, 2019, 2022, and 2025 via both Server Manager and PowerShell – the post-install wizard, initial sync, and verification are also covered.

WSUS Installation Prerequisites

If you are adding WSUS as a downstream server syncing from an existing upstream, you need connectivity to that upstream on its configured WSUS HTTP/HTTPS ports, typically 8530/8531, instead of outbound internet access to Microsoft.

Microsoft lists a minimum 1.4 GHz x64 processor (2 GHz or faster recommended), an additional 2 GB of RAM beyond the OS and other workloads, at least 40 GB of available disk space recommended, and a 100 Mbps network adapter (1 Gbps recommended).

WID or SQL Server: The WSUS Installation Database Decision

Before starting the WSUS installation, decide which database backend to use. Migrating an existing WSUS deployment from WID to SQL Server is supported, but it is a manual migration rather than a wizard-driven process. Microsoft documents stopping IIS and WSUS, detaching SUSDB from WID, attaching it to SQL Server, updating permissions, and changing the WSUS database registry settings. Going the other direction – SQL to WID – is not supported.

WID (Windows Internal Database) is the default and the right choice for most deployments on Windows Server 2016 through 2022. It is built into Windows Server, requires no additional licensing, and installs automatically with the WSUS role.

WID is intended for local access only and does not expose a normal remote SQL endpoint. You can still connect to it locally with SSMS or sqlcmd using the named pipe \\.\pipe\Microsoft##WID\tsql\query. There is no enforced per-database size cap in WID – that limit belongs to SQL Server Express, not WID. WID is suitable for many single-server WSUS deployments, including environments with thousands of clients, provided that the server is correctly sized and maintained.

WID limitation that matters operationally: cannot be used for network load-balanced WSUS configurations.

Windows Server 2025 note: WID is itself deprecated in Server 2025 alongside WSUS. Deprecation does not mean WID is currently unsupported – both WSUS and WID remain available in Windows Server 2025 and are supported for production use – but Microsoft may remove deprecated components in a future release. For new Server 2025 installations, prefer SQL Server Express for small deployments; WID remains supported but deprecated.

SQL Server Express is free but enforces a hard 10 GB per-database limit. A busy SUSDB on a large deployment can exceed this – error 1827 when it does. SQL Server Express supports normal SSMS administration and can be configured for remote connections, but TCP/IP network access is disabled by default on a new Express installation. Enable TCP/IP, restart the SQL Server service, and configure the required static or dynamic port and firewall rules before using it as a remote WSUS database.

SQL Server Standard or Enterprise is required for NLB/high-availability WSUS deployment, when the SUSDB may exceed the SQL Express 10 GB database limit, when the organization already operates a managed SQL platform, or when SQL-level availability and backup requirements justify it.

Storage Planning for WSUS Installation

Plan storage before the WSUS installation begins. Use a dedicated local NTFS volume where practical and avoid NTFS compression. WSUS can use a path on C:, but separating the content store simplifies capacity management, backup, migration, and recovery. If the folder is created or moved manually, verify that NETWORK SERVICE has the required permissions.

Microsoft’s documented minimums are 20 GB to store updates, 40 GB recommended. For Windows releases serviced through on-premises Unified Update Platform content, plan for roughly 10 GB of additional storage per Windows version and processor architecture – confirm which managed releases currently use UUP before applying that estimate to your full scope.

As a field estimate, a narrowly scoped and regularly maintained WSUS content store stays significantly smaller than a broadly configured or neglected one. Actual storage varies substantially with products, languages, architectures, approvals, driver content, express files, and cleanup frequency. Monitor the volume rather than treating a single size estimate as a design limit.

WSUS Installation: Role Setup via Server Manager and PowerShell

WSUS Installation via Server Manager

1. Open Server Manager → Manage → Add Roles and Features
2. Role-based installation on the local server
3. Select Windows Server Update Services and accept the additional IIS features when prompted
4. In role services, keep WSUS Services checked. For the database: keep WID Connectivity for WID, or uncheck it and check SQL Server Connectivity for SQL
5. Set the content store location – enter the path to your dedicated volume, e.g. D:\WSUS. Uncheck Store updates locally only when you intentionally want WSUS to synchronize metadata while clients download approved update binaries directly from Microsoft Update. Those clients must have the required internet access and policy configuration.
6. Install. When the installation completes, click Launch Post-Installation Tasks in the results pane and wait for “Configuration successfully completed”

Restart the server only if Server Manager reports that a restart is required.

WSUS Installation via PowerShell

WID backend (concise – official path):

WID backend (explicit components):

SQL backend:

Run post-install after either path.

WID:

SQL (local instance):

Verify WSUS Installation

All relevant features should show [X] (installed). Confirm WsusService is running:

Tune IIS After WSUS Installation, Before Clients Connect

Do this before the configuration wizard – it is part of completing the WSUS installation correctly. The default WsusPool settings cause problems under load and are documented by Microsoft.

Open IIS Manager → Application Pools → WsusPool → Advanced Settings:

Review these values against available RAM and client count for the specific deployment. Official reference: Microsoft WSUS best practices.

Ports and Firewall Rules for WSUS Installation

By default, the WSUS Administration website uses port 8530 for HTTP and 8531 for HTTPS. Custom ports are possible, so use the ports configured for your deployment.

• 8530 (HTTP): metadata sync and update payload downloads. Always required, even when SSL is configured.
• 8531 (HTTPS): encrypted metadata sync. Required if you configure SSL.

SSL in WSUS encrypts metadata only. Update payloads always transfer over HTTP and are protected by signed hash verification, not transport encryption.

If your WSUS server is behind a firewall, confirm outbound 80/443 to Microsoft’s update endpoints is permitted. Refer to Microsoft’s current documentation for the required FQDNs rather than maintaining a static list.

SSL/TLS Configuration for WSUS Installation (Strongly Recommended for Production)

WSUS SSL/TLS encrypts metadata in transit – computer group membership, approval state, detection results. Payloads always go over HTTP regardless.

Certificate requirements: use a certificate whose SAN includes every hostname clients and administrators use to reach WSUS, including the FQDN and any required short name or DNS alias. The issuing CA must be trusted in the Local Computer certificate store on clients and downstream servers – not the user certificate store.

Common failure: the issuing CA is trusted only in the administrator’s Current User store. The administrator may see the certificate as trusted while the computer account, IIS, clients, or downstream servers do not. Verify the server certificate and CA chain in the Local Computer stores with certlm.msc.

Running the WSUS Installation Configuration Wizard

Open the WSUS console via Server Manager → Tools → Windows Server Update Services. The Post-Deployment Configuration Wizard launches on first open.

Upstream server:

• “Synchronize from Microsoft Update” – standalone server or top-level upstream
• “Synchronize from another Windows Server Update Services server” – downstream. Enter the upstream FQDN and port. Check “This is a replica of the upstream server” only for Replica mode (centralized administration, all approvals inherited from upstream)

Proxy: configure this page if the WSUS server must use a proxy to reach Microsoft Update. Supply credentials only when that proxy requires authentication.

Start Connecting: the wizard contacts Microsoft Update or the upstream server to retrieve the list of available products, classifications, and languages. This takes a few minutes.

Languages: select only what your environment requires. Always include English – updates are built on English base packages. Missing a required language means clients for that language will not see applicable updates.

Products: add only the operating systems you actually manage. Do not select the top-level Windows product family unless you intend to synchronize every product below it – select individual products. Product labels in the WSUS console can differ from the public Windows release name; select the product entry that explicitly applies to the managed release.

For a current SMB environment, this may include Windows 11 and Windows Server 2019, 2022, and 2025. Select Windows 10 only for devices still covered by an LTSC lifecycle, enrolled in Extended Security Updates, or intentionally retained as legacy systems. Windows 10 version 22H2 reached end of support on October 14, 2025.

Every enabled product increases the amount of metadata stored and processed by WSUS. Update payloads are downloaded separately according to the server’s local-storage and approval settings, so selecting a product does not immediately queue all of its update files.

Sync schedule: configure automatic synchronization for an off-peak time, such as daily at 3:00 AM. On the final wizard page, select Begin initial synchronization if you want the first sync to start immediately; otherwise, start it later from the WSUS console.

Allow the initial synchronization to complete without restarting IIS, the WSUS service, or the server unless troubleshooting requires it. An interruption is recoverable, but it delays validation and can make the first-sync status harder to interpret. You can close the WSUS console – synchronization continues on the server.

Verifying a Successful WSUS Installation

After the first sync completes, check the Synchronizations view in the WSUS console. The most recent sync should show “Succeeded” with a count of updates found. Under Updates → All Updates, update metadata should be populated.

Server-side logs for sync failures:

• WSUS console → Synchronizations → open the failed synchronization entry for details
• %ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log – the primary WSUS synchronization log
• Event Viewer → Windows Logs → Application → Source: Windows Server Update Services

The WindowsUpdateClient/Operational log is a client-side log for diagnosing scan and download behavior on endpoints. It is not the primary log for server-side sync failures.

Verify WsusPool runtime state:

Verify the WSUS API responds:

For SSL:

Confirm clients can reach the WSUS server. Run from a client machine, not the WSUS server:

For an SSL-enabled deployment, test both ports – 8531 carries the protected WSUS service traffic, while 8530 remains required for update content:

If TcpTestSucceeded is False, verify DNS resolution, the configured WSUS port, IIS bindings, the WSUS Administration website state, WsusPool state, and network or host firewall rules.

Common WSUS Installation Failures

Official Microsoft Sources

• Install the WSUS server role
• Configure WSUS
• Plan your WSUS deployment
• Migrate WSUS database from WID to SQL
• WSUS best practices and WsusPool settings
• Microsoft reversal of planned WSUS driver synchronization deprecation
• Features on Demand and language packs through WSUS
• Get-WebAppPoolState
• Default SQL Server network protocol configuration