How to Install WSUS on Windows Server

A WSUS installation comes down to five decisions: install the Windows Server Update Services role, select one supported database backend, assign a secure content location, complete post-installation tasks, and run the configuration wizard with a narrow initial product and language scope. The installation is complete only after the WSUS console opens, the service and WsusPool are healthy, and the first synchronization succeeds.

This guide stops at that point. Group Policy, computer groups, approval rings, automatic approval rules, recurring maintenance, and synchronization troubleshooting belong to the related RackNotes WSUS guides linked throughout.

WSUS Installation Prerequisites and Sizing

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 content store stays significantly smaller than a broadly configured or neglected one; monitor actual volume rather than treating one size estimate as a design limit.

Check the current state before installing anything:

Confirm the OS build reflects a current cumulative update (for correct UUP content handling), the content volume is NTFS with adequate free space, and no reboot is already pending before you begin.

Choose the Architecture Before Installing

WID or SQL Server

Microsoft supports WID, and supported editions of SQL Server Standard, Enterprise, or Express as the WSUS database. WID (Windows Internal Database) is the default and the right choice for most single-server deployments on Windows Server 2016 through 2022 – built in, no additional licensing, installs automatically with the role. WID is local-access only; you can still connect with SSMS or sqlcmd via the named pipe \\.\pipe\Microsoft##WID\tsql\query. There’s no enforced per-database size cap in WID – that limit belongs to SQL Server Express, not WID. The one operational limitation that matters: WID cannot be used for network load-balanced WSUS configurations.

SQL Server Express is supported and free, but enforces a hard 10 GB per-database limit (error 1827 when exceeded), and Microsoft notes it offers no appreciable single-server performance benefit over WID. Don’t select Express merely because WID is deprecated – it adds a separately serviced SQL instance without removing the database-size risk. Use it only when normal SQL tooling or an existing SQL operational model is a concrete requirement and SUSDB size is demonstrably bounded. TCP/IP network access is disabled by default on a new Express install; enable it, restart the SQL Server service, and configure the required port and firewall rules before using it as a remote WSUS database.

SQL Server Standard or Enterprise is required for NLB/high-availability WSUS, when SUSDB may exceed the SQL Express 10 GB limit, or when the organization already operates a managed SQL platform. NLB/HA WSUS requires a full SQL Server deployment rather than WID – all front ends share the same SUSDB and content location, run the same Windows Server and cumulative-update level, and complete post-installation serially.

Windows Server 2025: WID remains available with WSUS on Server 2025, but WID is itself deprecated and Microsoft says it will be removed from Windows in a future release. For a new Server 2025 deployment, document why WID remains acceptable for the planned server lifetime and record a migration path.

Migrating an existing deployment from WID to SQL is a documented, supported manual process – stop IIS and WSUS, detach SUSDB from WID, attach it to SQL Server, update permissions, and change the WSUS database registry settings. Microsoft doesn’t provide an equivalent supported reverse-migration workflow in current documentation – don’t design a deployment around an assumed SQL-to-WID rollback.

Content storage: local store or Microsoft-hosted payloads

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. Let WSUS create and configure the content structure where possible; if the directory is created, moved, or restored manually, verify the documented WSUS service-account permissions rather than applying broad ACLs to the whole volume.

The second model still requires the WSUS database and metadata synchronization – it only changes where payloads come from. Clients must be allowed to reach Microsoft Update directly for this model to work. This choice is made after installation, under Options -> Update Files and Languages -> Update Files – not during role installation. If content download issues appear later regardless of model, see WSUS Not Downloading Updates.

Microsoft Update or an upstream WSUS server

A top-level server synchronizes directly from Microsoft Update. A downstream server synchronizes from an existing upstream WSUS server instead, over that upstream’s configured ports (typically 8530/8531) – this choice is made in the configuration wizard, covered below.

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. Provide a valid content directory – enter the path to your dedicated volume, e.g. D:\WSUS
6. Install. When it completes, click Launch Post-Installation Tasks in the results pane and wait for “Configuration successfully completed”

Restart the server only if Server Manager reports a restart is required. The local-versus-Microsoft-hosted payload decision isn’t made here – it’s a separate step under Update Files and Languages, covered above.

WSUS Installation via PowerShell

Use Microsoft’s documented parent-role command rather than listing individual child features – it’s shorter, less version-sensitive, and the official supported path for a normal WID installation:

If RestartNeeded is Yes, restart the server before running WsusUtil.exe postinstall – running post-install against a server that still needs a reboot is a common source of confusing partial failures. Alternatively, use Microsoft’s combined command and let it handle the restart:

For a SQL backend, install the role services (validate this command on your target Windows Server version first):

After any pending restart is handled, run post-install. WID:

SQL (local instance):

Run this elevated, quote values containing spaces, and capture the output. Don’t rerun it repeatedly against an unknown partial state – if it fails, check SoftwareDistribution.log, Event Viewer, installed role services, IIS, and database connectivity before retrying.

Verify the installation:

Configure Ports and TLS

By default, the WSUS Administration website uses port 8530 for HTTP and 8531 for HTTPS – custom ports are possible, so use the ports actually configured for your deployment. On a non-TLS deployment, 8530 carries all WSUS service traffic and payloads. On a TLS deployment, WSUS uses 8531 for protected metadata/service traffic and keeps 8530 for update payloads and the specific virtual roots that must remain HTTP. SSL in WSUS encrypts metadata only – update payloads always transfer over HTTP and are protected by signed hash verification, not transport encryption.

Refer to Microsoft’s current documentation for the required Microsoft Update FQDNs rather than maintaining a static list.

Certificate requirements: use one canonical WSUS DNS name in Group Policy and wsusutil configuressl. The certificate SAN must include that name, plus any additional hostname intentionally supported for WSUS access. The issuing CA must be trusted in the Local Computer certificate store on clients and downstream servers – not the user certificate store.

Verify afterward:

Then confirm the certificate name, chain, expiry, and Local Computer trust with certlm.msc. Common failure: the issuing CA is trusted only in the administrator’s Current User store – the administrator sees it as trusted while the computer account, IIS, clients, or downstream servers do not.

Run the Configuration Wizard

Open the WSUS console via Server Manager -> Tools -> Windows Server Update Services. The Post-Deployment Configuration Wizard launches on first open. This section covers a minimum working initial scope – final product strategy, approval rules, and deployment rings belong in the WSUS Configuration guide linked in the scope note above.

Upstream server: “Synchronize from Microsoft Update” for a standalone or top-level server, or “Synchronize from another Windows Server Update Services server” for a downstream – enter the upstream FQDN and port, and check “This is a replica of the upstream server” only for intentional Replica mode.

Proxy: configure this page only if the WSUS server must use a proxy to reach Microsoft Update, supplying credentials only when that proxy requires authentication. Start Connecting retrieves the list of available products, classifications, and languages – this takes a few minutes.

Languages: select only what your environment requires, always including English, since updates are built on English base packages. Products: add only the operating systems you actually manage – don’t select the top-level Windows product family unless you intend to synchronize every product below it. Product labels in the console can differ from the public release name; select the entry that explicitly applies to the managed release. For a current SMB environment this may mean Windows 11 and Windows Server 2019, 2022, and 2025. Windows 10 version 22H2 reached end of support on October 14, 2025 – select Windows 10 products only for supported LTSC editions, enrolled ESU devices, or a documented legacy requirement.

Every enabled product increases the metadata WSUS stores and processes. Update payloads download separately according to local-storage and approval settings, so selecting a product doesn’t immediately queue every update file.

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 to start immediately, or start it later from the console. Let the initial synchronization complete without restarting IIS, the WSUS service, or the server unless troubleshooting requires it – an interruption is recoverable but delays validation. You can close the console; synchronization continues on the server.

Verify the First Synchronization

Check role and service health first:

Then IIS:

Then the API – a successful connection confirms the administration service responds, but it doesn’t by itself confirm synchronization, content download, approvals, or client reporting:

Then capture the effective configuration – confirm the exact property names on your target release before relying on this:

Finally, check the Synchronizations view in the console – the most recent entry should show “Succeeded” with a count of updates found, start/end timestamps advanced, and Updates -> All Updates populated with metadata. For sync failures: open the failed entry in the console, read %ProgramFiles%\Update Services\LogFiles\SoftwareDistribution.log, and check Event Viewer -> Application -> source Windows Server Update Services. The WindowsUpdateClient/Operational log is client-side and isn’t the primary log for server-side sync failures – see Windows Server Event Log Troubleshooting for general log-reading technique. If the first sync itself keeps failing, the detailed endpoint/TLS/proxy/firewall diagnostic lives in the WSUS Sync Failed guide linked in the scope note.

As an optional network preflight only – not proof of a working client – Test-NetConnection confirms TCP reachability alone; it doesn’t prove a correct HTTP response, TLS trust, WSUS API operation, client GPO, scan success, or reporting. Full client validation happens after Group Policy is configured, covered in WSUS Configuration.

Before onboarding clients, record the WsusPool state and review Microsoft’s current WSUS best-practices baseline. Large metadata sets and scan storms can require a higher queue length and disabled IIS recycling/memory limits, but setting memory to unlimited can allow very high RAM consumption – apply the complete baseline deliberately on a dedicated server and monitor it. The WSUS Console Slow or Crashing guide owns the full tuning and recovery workflow:

Common WSUS Installation Failures

For a post-install 0x80070003 IIS COMException, or a .NET Framework 3.5/Features on Demand error while installing prerequisites: capture the full post-install log and Event Viewer message, verify installed WSUS/IIS role services, and identify the missing path rather than recreating components from the HRESULT alone. A servicing-source error on the WSUS server itself while adding roles doesn’t by itself prove WSUS is misconfigured – resolve the server’s servicing source before continuing installation.

Next Steps

A healthy WSUS server can open the console and complete a successful synchronization – that’s where this guide stops. Client targeting, deployment rings, and approval automation are covered in WSUS Configuration. Ongoing SUSDB and disk maintenance are covered in WSUS Maintenance (both linked in the scope note above). If content later shows as not downloading, see the WSUS Not Downloading Updates guide linked earlier in this article.

FAQ

Is WSUS installation still supported on Windows Server 2025?

WSUS is deprecated and no longer receives new features, but it remains available and supported for production use according to the Windows Server lifecycle.

Should I use WID or SQL Server?

Use WID for a straightforward single-server deployment without an existing SQL or NLB requirement. Use SQL when the organization already operates it, needs NLB/shared SUSDB, or has a clear database-management requirement. Don’t choose SQL Express merely as a supposed performance upgrade from WID.

Can WSUS clients download update files from Microsoft instead of the WSUS server?

Yes. WSUS can store metadata locally while clients download approved payloads directly from Microsoft Update. Clients then need internet access to the required Microsoft endpoints.

How long does the first WSUS synchronization take?

Microsoft states initial synchronization can take more than an hour; real duration depends on products, classifications, languages, proxy, hierarchy, and connectivity to Microsoft Update.

Does enabling TLS remove the need for port 8530?

No. A standard TLS deployment uses 8531 for protected metadata/service traffic and keeps 8530 for update payloads and the WSUS virtual roots that must remain HTTP.

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
• WSUS overview and deprecation status
• Deprecated Windows Server features, including WID
• Microsoft reversal of planned WSUS driver synchronization deprecation