- How to change the PowerShell prompt - Wed, Mar 22 2023
- Trim characters from strings in PowerShell - Tue, Mar 14 2023
- Set Chrome, Firefox and Edge as default mail client (mailto handlers) - Mon, Mar 6 2023
To help manage the constantly growing amount of data on a WSUS server, a server cleanup wizard in the console can remove unneeded updates. However, if (for example) the system has downloaded a large number of updates due to a poor configuration, this tool does not succeed in cleaning up thoroughly and regaining sufficient storage space.
Deleting downloaded updates
In this case, it is usually easier to delete the existing downloads. To do this, stop the services for WSUS and IIS with the following PowerShell command:
Stop-Service WSUSService, W3SVC
After removing the entire directory tree below the content folder, start the services again with:
Start-Service WSUSService, W3SVC
WSUS will then start fetching the currently required updates again. If it doesn't reload the updates automatically, use this command to initiate the download:
wsusutil.exe reset
Moving the content directory
However, if you think there is not enough free space on the volume for the updates, you can move the content directory to a different drive. You can achieve this with the command-line program wsusutil.exe:
wsusutil.exe postinstall CONTENT_DIR=D:\WSUS
If WSUS uses the Windows Internal Database (WID) as the database, this command would set D:\wsus as the new directory for the updates.
Changing the content directory for downloaded updates
But if you use a SQL Server, you additionally have to specify the instance name for WSUS from the command line (even if it doesn't change):
wsusutil.exe postinstall CONTENT_DIR=D:\WSUS SQL_INSTANCE_NAME="sql.contoso.de"
In this example, SUSDB runs on the default instance; therefore, the hostname is sufficient. Otherwise you would have to use the format Server\Instance here. Now you can remove the old content directory and its files.
Moving the WID database to another location
If you run the Best Practices Analyzer over a standard installation of WSUS, it will yield a warning if the database is located on the system drive. However, the WSUS setup does not allow you to install it to an alternative location if you use the WID.
The Best Practices Analyzer recommends not storing the WSUS database on the system drive
If you want to comply with this recommendation, you can move the database to another drive afterward. To do this, you have to quit the IIS and WSUS services as already mentioned above:
Stop-Service WSUSService, W3SVC
In the next step, you will need a management tool to disconnect the database. The SQL Server Management Studio is suitable for this, but it does not run under Server Core and cannot manage a WID database remotely. Therefore, the example below is based on the command-line program sqlcmd.exe.
If it is not yet available on the server, install the ODBC driver for SQL Server first and then the Command Line Utilities for SQL Server.
Then execute the following command:
sqlcmd -E -S np:\\.\pipe\MICROSOFT##WID\tsql\query -Q "sp_detach_db 'SUSDB'"
The next step is to copy the SUSDB.mdf and SUSDB_log.ldf files from their previous location (the default is %systemroot%\WID\data) to the new location. Now you can reconnect it from there to the database:
sqlcmd.exe -E -S np:\\.\pipe\MICROSOFT##WID\tsql\query -Q "sp_attach_db @dbname=N'SUSDB',@filename1=N'D:\DB\SUSDB.mdf', @filename2=N'D:\DB\SUSDB_log.ldf'"
In this example, D:\db would be the new directory for SUSDB.
Disconnect SUSDB with sqlcmd and reconnect from a new location
Finally, restart the previously stopped services:
Subscribe to 4sysops newsletter!
Start-Service WSUSService, W3SVC
Also read: Move or migrate WSUS to a new server.
I followed this and then found out there's a missing step. After you have moved the SUSDB and LogFile, you need to make sure this account has read and write permissions to both or your WSUS will not sync because it will be in READONLY mode: NT Service\MSSQL$MICROSOFT##WID
Source: https://mivilisnet.wordpress.com/2018/01/30/relocating-the-wsus-databases/
I was thinking of same permissions thing while reading this post. What a coincidence it is. 😜
Other than that, it is a really useful post indeed.
I should have read the comments, too… I was just getting ready to say the same thing. Brian beat me to it.