Very good topic. Good to know the internals and the fact that Micorsoft has increased the usage of SQL Server in many of its products.

Great Tip but I was unable to connect with (\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query) and result was:   "An error has occurred while establishing a connection to the server.  When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: SQL Network Interfaces, error: 25 - Connection string is not valid) (.Net SqlClient Data Provider)"

Got it.  The instructions were missing one leading "\".     \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query

Edwin,

Thank you!  You've brought an answer to my issue after hours of searching!

This is brilliant - I have been stuck trying to connect to the instance of Sharepoint and couldn't work out why I couldn't connect.

I am now in and can shrink the DB - many thanks for such a useful post..shame I couldn't find this on MS this easily.

Wally

Hi Wally,

Be aware that shrinking SQL Server databases - including SharePoint-related ones - is not recommended due to internal fragmentation both for the data files and the log file. If you are concerned about your log file growing and are not concerned about point-in-time recoverability for your SharePoint databases, set the database RECOVERY model to SIMPLE, shrink the log file to the smallest size possible and resize it to a size that you think would be enough for it to contain the active transactions without growing unexpectedly. You can resize your log file to 4GB and monitor accordingly. This process minimizes the amount of virtual log files while the recovery model truncates your log, thus, keeping it from growing 

Hi Edwin,

is it possible to create a linked server in Windows Internal Database

Thanks a ton, you have provided very clear instructions, i was searching for it for a while. Thanks agian.

It is designed in such a way that you are not allowed to connect to and use this particular database service for non-Microsoft products

I am not sure this is true.  Any appilcation that can connect using Named Pipes can use the Windows Internal Database.  It has the same operational characteristics as SQL Express (1 CPU, limited memory, etc), except that database size is unlimited.

Before you think you can run your 1TB database on WID and avoid the Standard Edition license, remember that the CPU cores and memory avalable to Standard Edition are there to give performance, so don't expect WID to be fast if your DB is large.

You are correct. However, from a licensing and support perspective, you are not allowed to connect any line-of-business application to the WID aside from those sanctioned by Microsoft.

Thank you for this post, it was a solution for our problem!

I have two of these for SharePoint, and four for VMM management. I am unable to make myself SysAdmin on these, as the only two logins are "sa" which is disabled, and BUILTIN\Users, which is crippled. Not being a SysAdmin, it's not possible to keep these patched.

If you are a local Administrator on the machine running these SQL Server instances, you can still regain access to them even when the sa account is disabled or even when you do not have access. Here's how you can do it

http://msdn.microsoft.com/en-us/library/dd207004(v=sql.100).aspx

When trying to do a backup of the WSUS DB, it defaults to a non-existent disk location at D:\WSUS\{2AE3D45E-09F4-4B90-B694-22AAFE208AD1}\SUSDB.bak.  When I create another backup location and try to run the backup if fails with an error pointing to D:\WSUS\{2AE3D45E-09F4-4B90-B694-22AAFE208AD1}\SUSDB.bak as not being found.  Is it safe to delete this default location?

We use a centralized backup solution (Tivoli Storage Manager) that cannot do a normal SQL backup of the WSUS DB remotely.  The file backup fails as being in use leaving us with no way to backup the WSUS DB.  I'd like to script the backup within SQL and then capture a backup of the backup file with Tivoli.

Any ideas?

Just if someone runs into the same problem: I've tried to use your connector: \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query on a Windows Server 2012 internal database and it doesn't work.

Now it seems to be a new connector string you have to use with 2012: \\.\pipe\MICROSOFT##WID\tsql\query

best regards

Thanks Edwin! After so many hours of searching for solution, good thing i found this website. It works like a charm!! 

A shot in the dark here but I'm trying to connect to the Windows Search Server 4.0 'database' and can't with the above examples.  So I'm either barking up the wrong tree or WSS4.0 has a completely different connection model.  Anyone offer anything in the way of enlightenment?

Hi Neil,

I don't think Windows Search Server uses SQL Server under-the-covers. I couldn't find anything in the documentation on TechNet that specifically points to a SQL Server database. So, the steps outlined above will not work. I might also be wrong in my assumptions