Recently I built a new test lab. As an aside, in my opinion, this is one of the most complicated labs that you could have, but I’ll write more about that at a later date. While building this lab, I needed to setup WSUS on my new CAS server. This post tells you about the problem I encountered with WID and SQL.
Usually, when you setup the WSUS server role on the server, there is a post role task that needs to be completed before WSUS can be used. Normally you click the post task in Server Manager and a few minutes later the task gets marked as successfully completed.
Needless-to-say, the post task didn’t complete successfully for me. When I reviewed the log file, I saw the following error message:
You can clearly see within the error message (highlighted text) that it looks like there was an error within the database (DB) structure.
When I researched this error message, I found a lot of suggestions online, but none of them worked for me. Since this was a new lab and I didn’t need WSUS/Software Updates right away, I left this issue alone for a bit.
It was while I was working on completing the setup for my ConfigMgr Current Branch 1610 lab, that I noticed within the user directory that there was a profile for MSSQL$MICROSOFT##WID.
Hmmm, I thought this was funny as I didn’t select the Windows Internal Database (WID) server role to be installed on the server. I didn’t select the WID because I’m using SQL 2016 for all ConfigMgr server roles.
When I examined the server roles I installed, I noticed that, in fact, the WID role was installed! Immediately, I removed the WID server role, and dropped the SUSUB database within SQL 2016 (as a precaution) and then rebooted. After the reboot, I tried the WSUS post task again and this time it worked!
The moral of the story: don’t install WID and SQL on the same server, if you can help it!