The Windows Internal Database is nothing more than an embedded lite SQL Server instance running under specific credentials and with a few protocols enabled.
Therefore in order to connect, you can use any SQL Server client tool: SQL Server Management Studio, SQLCMD, …
Starting with Windows Server 2012, the named pipe to access is \\.\pipe\MICROSOFT##WID\tsql\query. For older systems, the pipe is different and is named \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query.
From this we can already sense that this is some kind of named instance now called MICROSOFT##WID and MICROSOFT##SSEE in the past.
Please note that the tools must be run with elevated privileges, otherwise you’ll get an access denied message.
Once logged in we can see that Windows 2016 Windows Internal database feature hosts a SQL Server 2014 RTM like version.
The SUSDB is a regular user database created by the WSUS feature. If we look into logins, they can be split into 3 groups:
- the built-in logins you’ll find in every SQL Server, the ##XXXX certificate ones, sa, etc.
- a set of logins for the WID feature, which get the sysadmin role. The NT Service\WIDWriter and the NT Service\MSSQL$MICROSOFT##WID will again make you think about a named instance MICROSOFT#WID,
- a group here created by the client application (MACHINE\WSUS administrators)
If we dig into the characteristics of the SUSDB database, we see a regular user database for which some user roles are defined and attached to the specific logins we mentioned earlier.
Needless to say that you can issue backups of the SUSDB as you would for any regular database, although officially Microsoft maintains there is no need to deploy any maintenance solution.
You may want to note that this SQL Server “Edition” behaves like the Express Edition under some circumstances, e.g. contrary to the Standard, Enterprise or Web Edition, it doesn’t eat as much as RAM as it can.