If you're already using
SQL Server (and not WID) for your WSUS database, then no, you do
not need to install WID. Instead, the issue lies in correctly configuring WSUS to use your SQL instance. Let’s focus on resolving this by properly linking WSUS with your SQL Server setup.
Verify SQL Server Configuration
Here’s what we need to check to ensure WSUS works seamlessly with your SQL instance:
Step 1: Verify SQL Instance
Confirm the name and state of your SQL Server instance where
SUSDB is hosted. If unsure:
- Open SQL Server Management Studio (SSMS) or connect via
SQLCMD.
- Query the existing databases:
Code:
sql SELECT name FROM sys.databases;
- If
SUSDB exists, great! If not, you’ll need to create or reinitialize it (details in Step 3).
- Ensure WSUS Has Permissions:
- The SQL instance must allow connections from the WSUS Server.
- Add the WSUS machine account (
Domain\ServerName$) or NT AUTHORITY\NETWORK SERVICE as a login in SQL Server and grant it:
db_owner rights on SUSDB.
- Confirm SQL is listening on the correct port (default:
1433 for TCP):
- Use:
SQL Server Configuration Manager > Network Configuration > Protocols for .
Step 2: Reconfigure WSUS to Use SQL
Run the
postinstall command again, specifying your SQL instance:
- Use the Correct SQL Instance Name:
Replace
Code:
bash wsusutil.exe postinstall SQL_INSTANCE_NAME="\" CONTENT_DIR="D:\WSUS"
Example for a typical SQL Express instance:
Code:
bash wsusutil.exe postinstall SQL_INSTANCE_NAME="MyServer\SQLExpress" CONTENT_DIR="D:\WSUS"
If using the default SQL instance, drop the \SQLInstance:
Code:
bash wsusutil.exe postinstall SQL_INSTANCE_NAME="MyServer" CONTENT_DIR="D:\WSUS"
- Validate the Connection:
If wsusutil fails, double-check:
- The
SUSDB exists.
- SQL is accepting remote/TCP connections.
- Firewall is allowing the SQL port (default:
1433).
Step 3: Create or Reinitialize SUSDB (if missing)
If
SUSDB doesn’t exist (or is corrupted), follow these steps to recreate it:
Option 1: Let WSUS Rebuild It
- Stop the WSUSService (to avoid conflicts):
Code:
bash net stop WsusService
- Run the
postinstall command again. Provided WSUS has access to the SQL instance, it will automatically create SUSDB.
Option 2: Create SUSDB Manually
If WSUS can’t create
SUSDB, do the following:
- Use SQL Server Management Studio (SSMS) or
SQLCMD to manually create the database:
Code:
sql CREATE DATABASE SUSDB;
- Grant necessary permissions:
Code:
sql USE SUSDB; CREATE USER [NT AUTHORITY\NETWORK SERVICE] FOR LOGIN [NT AUTHORITY\NETWORK SERVICE]; ALTER ROLE db_owner ADD MEMBER [NT AUTHORITY\NETWORK SERVICE];
- Re-run
postinstall with the proper SQL instance.
Step 4: Validate Logs
If
wsusutil.exe postinstall still fails, check the logs for more clues:
- WSUS Log:
- Located in:
Code:
C:\Program Files\Update Services\LogFiles
- Look for any lines mentioning SQL or communication failures.
- SQL Logs:
- Open SQL Server Management Studio (SSMS) or check under:
Code:
C:\Program Files\Microsoft SQL Server\\MSSQL\Log
Key log entries can help identify whether the issue is with permissions, connectivity, or schema mismatches.
Step 5: Optional - Bypass SQL for Testing
If technical challenges persist, you could switch to WID temporarily just to confirm WSUS functionality:
- Install WID:
Code:
bash Install-WindowsFeature -Name Windows-Internal-Database
- Run:
Code:
bash wsusutil.exe postinstall CONTENT_DIR="D:\WSUS"
Once WSUS is stable, migrate back to your SQL Server instance.
Let me know how this progresses, and feel free to share relevant log snippets if something still feels off. We’ll make sure WSUS and SQL get on speaking terms!
ReportingEvent.Client.167;. Removed and readded the Content virtual directory to IIS. Can't see to get it working again. Any help would be much appreciated. Thanks
