Deep Dive How to Configure a Shared WSUS Database for Multiple SUPs in SCCM

hi my name is Justin shelf I'm the founder and run our engineering team here at patch my PC we develop a third-party patch management solution that integrates in a Microsoft configuration manager prior to my current role is also a premier phillyd engineer at Microsoft supporting config manager in this video guide I'm going to be talking about how you can use a shared wsus database for multiple software update points within your config manager environment why you would want to do that when to do it and how to do it so the first thing I want to cover is looking directly at the config manager documentation is this bullet point here around best practices for software updates one of those best practices that they mention here is to use a shared WCS database for your software update point the reason why that is generally recommended is because let's say that you have a client that's scanning against software update point oh one within your config manager environment it's going to scan against that WCS database to determine what updates are actually needed now in this scenario that that server were to go offline if that client were to fell over to let's say sup o to if it was using the same wsus database as sup o 1 it's going to drastically reduce the amount of scan data that that client needs to perform when it fells over to that new sub now in addition to improve client scanning in the scenario that a client felled over to another software update point using the same shared database whenever you actually perform a synchronization it's also going to be faster as well because you're not maintaining multiple databases for your ws environment so if you did have multiple and they were both pointing to their own local sequel database it would actually have to go and replicate the data from all the sups when it sinks down if you're using a single database when you perform a sync you extensions essentially only update one wsus database so your syncs will also be faster if you were to switch to use one now there is one scenario where I can think that it probably would not make sense to share your own wsus database let's say that you have a remote location and the connectivity is very slow between that remote software update point and let's say that top-level for update point within your primary location in that scenario I don't think it would make sense to have the shared database because when that remote sup does its canning it would essentially be going over that slow Network to hit that shared sequel database for any type of client scanning going over is so that's really the only scenario I think that you probably wouldn't want to use a shared database but if you if you're well connected between all your software update points I think it could really make sense to switch over to a shared wsus database to get some of those benefits that I mentioned here so with that said we do actually have an environment so this is actually a site that we recently did a high availability video on so we actually have some multiple subs already kind of ready to go here so this is going to be make a lot of sense here so the first thing that we have going on is our primary software update point so that's kind of the top level that's the initial sup that we had configured and then what I did is we went ahead and added a secondary software update point and we just kind of used the default options we didn't go and configure a shared database so if we actually look here at the sup o2 we can of course see we have our sup on there same thing with sup o1 now the key difference here is that if we go ahead and look at sup o1 and we open up the registry we can go ahead and look at the software Microsoft Update Services server and then setup key so there's gonna be where wsus gets installed we can of course see that if we look at our sequel database name we can see that wsus isn't in fact using a sequel database so it's connecting and using that for the wsus database now if we take a look at the ii sup so we'll go ahead and open that one up and if we look at that same value we can see that it's actually using a Windows internal database so we're actually not even running on sequel we're just using the local windows internal database instance on this second sup within our environment so what we're going to talk about here is the first scenario is going to be you have a remote it's using either a different sequel database or even the windows internal database and you want to switch that second sub to use the primary database within the top-level stuff in your environment all right so switching back to our site server I might go ahead and give you a quick look at what actually happens from the config manager perspective when you have multiple software update points that are not configured to share the same database so the first thing I'm going to do is actually enable some debug logging so we're gonna go pretty deep in this video and kind of explain how your subs get configured how you can actually see what's going on within the synchronizations when you have multiple subs so within HQ local machine software microsoft SMS we're gonna go ahead and take a look at the tracing key under the SMS key and we're gonna go ahead and go over to the W sync manager and we're gonna go ahead and enable the debug logging so I can see that I've already enabled it to one we also enabled the logging level to zero which would be setting it to verbose logging and we're gonna do the same thing for the wsus configuration manager so I set it to debug and then I went ahead and set the log level to zero now this is of course optional I'm just gonna enable this that we can get a little bit more details in the log file when we actually see what's going to happen when we start sharing this database and going through the setup all right so next what we're going to do is go under our same SMS key but we're going to take a look at the components so under the components key we're gonna look at the SMS executive service and then within that there's going to be a sub key called thread so these are going to be all the different components or threads running under the SMS executive service so you can also do this in your console so there's a place in your console called the under monitoring you can go here and look at the component status and you can actually start this resource manager now this just generally is a lot slower to load up and do things it just takes longer so what we can do is directly in this reg key is we can look at the different components or threads running under Zek you t'v and we can say hey I want to go ahead and stop that component so I'm gonna go ahead and look at the the stop action here so we're gonna stop the sync manager because we wouldn't want any synchronizations taking place while we're switching that secondary sup to be shared DB we're also going to stop the wsus configuration manager now if we go ahead and take a look at our site server logs and look at that WCM log so that's that W SAS configuration manager component so when we set that requested action to be stopped we can see that that shut down that specific thread so everything else will still be running but that one thread of the executive service won't be so what I'm gonna do is go ahead and start that back up and I want to show you how the software update points get listed here in debug mode so the thing that I really want to show you is we can see our supp o1 right so here's the primary suppo one but more importantly within this WCM component that's where we can see where the actual database is configured for that software update point within our environment so we can see this one is of course pointing to that database sequel server but if we look at that secondary sup we can see that it's set to use that Windows internal database so what that means is that config manager is gonna essentially say whenever I do a software update point sync since these are not shared using the same database we actually have to loop through each of these sups and perform a synchronization of any changed updates whenever we sync so what I'm going to do now to kind of show what that looks like we're gonna go ahead and start back the component for the sync manager then within my sup or my con so I'm going to go ahead and say we want to run a synchronization and then we'll go ahead and open that w sync manager log and I'll wait for this to kick in here okay so it's still kind of running in here but what we can see is that it did find both of those stuff so it's detecting we have two different software update points and we need to synchronize both of those all right so I gave that about three four minutes and our synchronization completed but what I want to show you here is that since we were using separate databases for both software update points what we'll notice is that initially when we perform our synchronization we can see that it's set to synchronize the initial software update plant which is sup - one so we can see that it goes through it configures the synchronization with the initial sup but then what we notice is that it's gonna say that it needs to synchronize the replicas up so here we go so here's where it says we're synchronizing the replicas since they're using two separate databases we're gonna have to essentially replicate any changes from the initial sync that went from the Windows Update catalog to our top-level W sauce or software update point to any of those replicas that aren't using the same database so one benefit by kind of using that shared option is that your synchronizations are going to be much faster because you're only kind of managing that single database source for any of those changes and then you know it went through and then synchronize that replica so that's kind of want to know what I wanted to show here initially before we actually make the change okay so at this point we validated the sync is done so we don't have anything pending so what I'm going to do is go back to that and we're gonna go ahead and stop our W sync manager Huk thread within our site server and we're gonna go ahead and stop that w sauce configuration manager thread by doing that that's just going to ensure that we're not going to try to do any type of replica sinks or anything that goes on during this process when we're actually switching that secondary software update point to use that new shared database so let me jump over to our secondary sup so this is the one that we can see is currently configured to use the windows internal database so if you actually want to know where that database lives within the C Drive under windows there's gonna be a width older so this is gonna be pretty much that that windows internal database that wouldn't even be running on sequel server but within here under the data folder this is going to be where the actual wsus database lives that's running locally within this windows and internal database instance so that that of course is gonna be what we basically switch over so once we once we change that over we don't really care about this database it will just be kind of left here and you could even delete that once you verify everything's working so uh the first thing I do is go ahead and open up a command prompt as admin and then launch PowerShell so this is gonna be a little bit different since we are using the windows internal database instance within within the server what we need to do is actually remove the windows internal instance because we want to use the sequel instance now to do that there's a command line that we can use to only remove the specific windows internal instance of the wsus server ok so there we go um so I think I let me do Update Services Star I think that's actually what I wanted so here we go we can see that since this was initially configured when we installed wsus to use wid we actually wouldn't be able to convert this into a shared database on a sequel server until we actually remove the wid component of W sauce and install the sequel component now if you're already running on a local sequel instance you wouldn't have to perform this configuration to remove the wid instance within W sauce but since I've noticed a lot of remotes UPS when I was going on site with customers a lot of times they would have just used the default would when they configured that so I thought that would be a good option to kind of cover all the different scenarios here all right so I'm gonna go ahead and paste in a command so this is gonna be removing the windows internal database instance within the server so if we look here we're just gonna say remove windows feature - named Windows Update - whit DB so that's gonna be the role service within W sauce that would allow wsus to use a wid database so if we go out and run that command again to show the Windows Update feature we can now see that wid connectivity is completely gone so at this point you really wouldn't be able to connect to your WS console and clients wouldn't be able to scan at this specific moment now before we actually want to configure wsus to point to that remote sequel server that's all so being used on sup o1 we need to install the actual database connectivity service within W sauce so that role service is going to be update services - DB so I'm gonna go ahead and run that and that will install that service for me there we go so if we do a quick refresh we can now see that we are running the wsus service and we have sequel server connectivity within there as well alright so at this point we're ready to kind of switch this wsus instance to use that remote sequel server that's being used on sup o1 as well but what we also need to do is we need this sup - to share the same content folder as sub-1 so I went ahead and switch back to my primary sup that is kind of that top level software update point within config manager and we can of course see if we look at our content folder let's take a look here we can see that this is just pointing to a local drive on that sup o1 server so what we want to do is make sure that we share this folder out because we want to ensure that sup o 2 can also have access to the content because that contains all the EULA's for any updates that require EULA's so if we're not pointing that same path what's going to happen as clients may fail to scan against updates where you need to accept the EULA within the config manager console so what I'm going to do is come over here to my wsus folder so we can see within here we of course have our wsus content and update service packs like you would be accustomed to so back on that root level I'm going to go ahead and choose properties and we're gonna go ahead and share out this folder let's do a dance sharing I'm gonna share it out and I'm just going to name it Debbie sauce here within the permissions we're gonna go ahead and give everybody read or everybody full control and we'll lock this down using NTFS permission so we'll go ahead and do OK on that and then close and that looks good but actually within the security tab what we need to ensure is that the computer account of the secondary software update point has permissions to read into this directory because it's going to be connecting here whenever clients need to do the EULA scans where they actually require it to validate the file so from here we're going to go ahead and look at the permissions and I'm going to go ahead and add the computer object of that secondary stuff that we're gonna be sharing so I'm going to go ahead and just type that in okay and we'll just add that computer account and we need to have full control should be fine technically you could probably get away with just modify with the ER but I'm gonna go ahead and give it full control so that we can make any changes within that secondary sup for that configuration all right so that's it looks like that's applied now so we should be good there we'll go ahead and do close here and then close here all right so let's go back to our sub - and what we want to do is we want to navigate to our WCS installation folder so we're going to go ahead and go to Program Files let's do Program Files Update Services tools CD there we go and I'm gonna go ahead and switch to a command line rather than powershell for this operation so what we want to run next is within the tools folder of the wsus services there's a wsus util tool so this is where we can come in and change different configurations within wsus so we take a quick look back at where we were at and do a refresh we can see that we've switched things over to allow sequel connectivity but of course we haven't told it where to look so it's still saying hey we're pointing out that local wit database so that's of course not what we want here so what we're gonna do is run a wsus util command to switch everything over so let me go ahead and paste this in and kind of show you what we're doing here so we're running wsus retail we're gonna run the post install command so that's going to allow us to set the sequel server and content folder that we need to use for that post action where we want to configure it so what we can see we're running the sequel underscore instance underscore name equals and then the database server so we can see that we're just pointing to our Oh server where the wsus database exists force up Oh once we're going to point it to that same exact sequel server now if you're using a custom instance you could just put a backslash after the server name and then your instance name and the next we want to set the content Durer so there's just a Content underscore der parameter equals and then we want the full path for our wsus share now actually I don't want to include the WCS content I made that wrong we want to go to the root of that share path so just to validate that looks good let me go ahead and copy that path and then we'll paste that end let's just go to the root of W sauce and we can of course see the share path that's going to be the W sells content and update service packs will be within this root folder that we're pointing at so that looks good all right now before we run this I'm going to go ahead and open up CM trace just so we can view the log file so we'll go ahead and get that opened up and we will go ahead and kick off this post install W such detailed configuration now we can see it's writing out to a log file in the temp location so I'm going to copy that past and I'm gonna go ahead and open up that log within CM trace now it might take a second for it to start writing out the log all right so we can see that it's currently running the configuration we've got some log files so for example you can see where the content directory is getting moved to you can see whether the sequel instance is gonna get set to and we'll go ahead and just kind of monitor this it shouldn't take more than probably about 30 seconds or less from what I've seen in the past here all right there we go looks like the post install completed successfully we can also validate in the log file that it completed so if we come back to our registry here and do a refresh of this key we can now see that our content directory is pointed to that remote UNC on the primary supple one and we can see that our database server is using that same shared database server that supple ones w sus sus TB is located on so it looks like the post install is good at this point we're pretty much using the same exact database for any operations for scanning within this secondary sub so this looks pretty good now there are some common actions that can not get configured correctly after this post install so the first thing that that we've noticed is that if you open up is and will go ahead and open up that wsus administration website within the content folder it seems that when you use a UNC path it does not correctly configure the path to point to the remote UNC share so if we come in here and look at our basic settings up here we can see that it put in the path but when it does that move command it doesn't detect that it's actually a UNC path so you can see it's pointing to an invalid path without the backslash backslash so first thing we want to do is go ahead and fix that if you detect that it had that within your scenario so we'll go ahead and choose to run that and we'll test the connection and we can validate that you know it does see that there is a shair there but the first thing that you notice here is that says it can't validate that the IaaS service has permissions to it so first thing we'll save that initially so that looks good now what we want to do is kind of run a test to see if we can actually browse out to that content folder for a file that actually lives there so I'm gonna go ahead and click browse and that's going to take us to the root level of the content folder here all right so the first thing that you're gonna notice this is completely expected that you're going to get a forbidden message if you browse out directly to the root of the content so that's expected that's not going to allow you to browse directly at the root level so that's okay that we're seeing this error message but if we go ahead and look out at that wsus content folder there is always a test text file that you can use to see whether you have permissions to actually browse out from your software update point and I asked to actually view whether it can load that file so of course if we go paste that in we can see that we're detecting that is does not have permissions to actually validate that we can open that text file so what that means that would also cause issues with all these different content folders within this folder so this is going to be where EULA's get stored so each EULA that you have to accept will have a text file that lets you know you accepted it so if they're if you're unable to browse out to this this this file for this basic text file to test it that means that clients would eventually get scan issues if you had any updates in here that required you to accept the EULA within the config manager console so first of all we need to fix this issue where is cannot connect the reason that it's having issues connecting is of course because rather than using just a local path where we would have access to look at it we're using this remote UNC path for that wsus content folder so by default if we look in is and we look at the content if we right-click and choose the advanced or I'm sorry we actually want to go to authentication so if we click on the authentication within the content folder what we want to look at is the anonymous access for authentication so anonymous authentication if you right-click and click edit you can see that by default as the is service is trying to use a local service account only known to this local machine since the content is hosted on that remote sup sup oh one of course this local user that's kind of running this identity is not going to be known or have any type of permission so what we want to do we want to run this under the application pool identity so that's going to be essentially you're using the system account and since we gave the system account access to that shared folder force up OH to that computer account that should allow the authentication to take place when we switch that to use that type of identity for the authentication so that should be set so what we want to do we want to come back in an internet explorer and do our refresh and now what we can see is that file it did in fact load now this is of course just an empty file but we can see that we're not getting any type of permission errors so this looks good that means that clients would be able to validate the EULA's whenever they're scanning against this sup o2w sauce configuration so that that looks good from this shared database we should be good to go lastly what we can do is just open the WCS console and we're just validated of course that it loads and you can connect and see a few different things here so it looks like we do have it loaded we've got a couple updates but they're just not showing up because the current filter that we have configured here but this looks good there we go so that looks good okay so let's go back to our primary site server so next we'll go ahead and start the WCS configuration manager so this was what we had in that stop state so we're gonna go ahead and let me just refresh this to verify it still stopped let's take a look all right it looks like it might have restarted itself I'll just take a look here there we go so yeah it looks like even though we did have it stopped for a second I expect that the executive service detected hey this component is no longer running and then it went ahead and restarted it so what I wanted to show you back in this WCM log let's see if we can figure out when it actually got restarted so there's where we stopped it ok so here we go we can see it started up about three minutes ago it looks like so then it went through the normal startup where it's going to connect to all the software update points so we can see it connecting to sup oh one but what we can see here is that when it connected to sup o2 if we take a look we can see that that component detected hey this this the server is now different wsus is no longer using that wit database but it's also now using the same database server that's up o1 is using so if we look at that we can see that it of course is showing up with that same configuration here so that looks pretty good just to show you that there are exactly the same we'll go ahead and do a requested operation we'll go ahead and stop it once more and then we'll go ahead and start it back up and then we'll open up that same log file and now what you can see is that when it's loading the list we can see that the seppo one in suppo two are now using that same database configuration so this is how SCCM is going to know hey these are the same exact backends for the database so we don't need to do any type of replica syncing we're going to treat these like a single software update point okay so let's looking pretty good now what I want to do is since we just synchronized from Windows Update there's not going to be any type of catalog changes if we go ahead and sync again so what I'm going to do is go back to my primary sup my sup o one and what I'm going to do is just go ahead and run our kind of local patch my PC service that we use for third-party patches and I'm going to go ahead and run a synchronization so since I have Google Chrome currently enabled for publishing I just know that a new chrome update just got released today the 7th of February so what's going to happen is we're gonna go ahead and download and publish the new update for Chrome so while we wait through that for that to complete once that's done we'll go ahead and run one more synchronization within our actual software update point just so we can see the new sync happening and we can see how these sups are now treated as a single software update point within the sync status all right so we can see those two new chrome updates just published so let's go back to our console and let's go ahead and run a synchronization so we can pull in those newly published updates so we'll look back at that w sync manager log kind of zoom in there and wait for that to kick in here we go so starting the sync there we go so we can see the new Google Chrome updates coming in and now what we can see is that we didn't get any notification we need to think in any replicas so of course this is just gonna treat the stink as if it was just a single software update point since both both of these are pointing that same database so that looks good so if we come back in here we can see that the sink looks good of course if we look at our software update point synchronization status we can see that they both just completed and that looks good so there we go last updated so that's how we would move an existing sup that was configured using wood or even sequel server on that local shop to use the same database as the top-level software update point within your site now what I'm going to do is go ahead and remove the sup from my sup o - and what we're gonna do is basically show you how you would configure this if it was a clean installation of a server where you would have to go through the initial wsus installation rather than converting an existing sub that was already out there so I'll go ahead and get that configured and we'll pause it while that happens all right so just remove the wsus role so we're go ahead and restart and get this back to a state where WCS is not installed on sub - all right so we are back and now we're logged back into sub - - and what we're gonna do now is go ahead and reinstall the WCS role now that we cleanly uninstalled it so this would be a scenario where if you wanted to stand up a second sub from scratch and you wanted to make sure that it uses that same shared WCS database during the initial configuration this is what that would look like so we're of course just gonna go through the default kind of wizard here you could of course use PowerShell if you wanted now one thing I did not mention I think in the first scenario is you do need to make sure that the two different software update points are really any number of software update points that is using the same wsus shared database are running the same OS version so you wouldn't want a server running server 2016 version of w sauce to connect and share the database with run running 2019 for example you need to make sure that the wsus version for the operating system as well as if you've done any type of custom patches are at the same level when you use a shared WCS database in my case where of course both running 2016 so we should be perfectly fine here so within the WCS configuration we need to ensure that we uncheck wid so this is kind of that default one where you you could you know accidentally use that and that could be an option where you want to switch from would do that share DB or even go from wid to maybe a local sequel on the actual sub itself and we do have a guide if you do want to convert from wid to sequel we have a separate guide for that as well there we go so a sequel connectivity now for the option where we want to store updates this is going to be where we point out to that same UNC path now I'm not going to worry about recreating that for this demo we of course already did that in the initial scenario where we converted the previous up to use the shared database so we should already have it shared we should have all the permissions configured and ready to go here and then next we're gonna go ahead and enter our sequel database name so we're going to of course point to that remote sequel server that's running the shared sub will do next here and then we'll go ahead and install now this is also if we look at CM trace there we go if we go ahead and open the temp directory we should have the log file is going to be created in this dot temp file so once that kicks in we'll see the configuration happening here so there we go so the initial install is done but of course we have to run this post install task so we'll go ahead and run that and this is actually where we should see the log file let's let's go ahead and see if we have a new one that got created here there we go alright so we can see the post install completed successfully we can of course see all the actions that took place within the install so it's going to be quite similar at the end of the day this is really just running the same post install configuration we're just doing it from the initial setup wizard because wsus wasn't previously installed so of course if we open up some regedit if I could type there we go so if we do a you know a refresh here we're gonna see it looks pretty much exactly the same as the stuff that we kind of converted that was initially installed so we've got our UNC path for the content and we're using our remote sequel server for our connectivity here so this looks good now if we go ahead and copy that anonymous file path and go ahead and test that it's probably pretty likely that the same configuration issues may still be in place so we can see that it looks like it's not able to detect it we're getting a 404 not found so if we look here we can of course see hey when it ran that configuration for whatever reason for that post install bug it did not put the backstops backslash for our unc path so we'll go ahead and open up is go and we'll go ahead and look at our content folder under our WS administration and we'll choose to edit the basic settings over here on the right and we'll go ahead and put in that that backslash backslash like we did before and that looks good now of course if we refresh the page now we're probably going to get the unauthorized because we're running under that special account that that remote software update point for sup oh one will know nothing about and would not be able to authenticate it so we're going to come back in under authentication we're going to right-click anonymous and choose edit and then rather than using that user account that's done by default we want to use the application pool identity we'll go ahead and set that go ahead and refresh and at this point we now have authentication so we can access the EULA files and any third-party updates that have been published when you download them into your deployment package within SCCM so this looks good now come back to our site server of course all we would do here is come back add a new site system role we're going to go ahead and choose our software update point we'll do ok we're running on the non default port so that's going to be 8 530 by default on Server 2012 2016 and 2019 and we'll do next here we don't have SSL currently configured and we'll leave the default options here now when this operation completes so we'll do next here it's going to use that same WCM component of course so if we look at that that's going to be the component that configures any new software update point so we'll see that kick in in a second there we go so we can see it started connecting to the sub two here and it's starting to configure that as well so there we go it's starting that while we're waiting for that to complete we should also see if we open the site comp or the site component manager log on the site server you're also see some information about where it's installing the software update point there's a few binaries that get copied and registered on that remote stuff as well and you can see all of that taking place within the site comp log within the within the site server as well so we can see the different dll's and files that get copied when we actually configure the software update point role to install all right so we can see the configuration is now done in WCM dot log it looks good and just for a quick test we could of course go ahead and run a software update point synchronization to get that validated and make sure that the sinks are happening okay now of course from us multiple software update point perspective you will want to make sure that you have the new site system in the boundaries that you may have configured within your site so for example with both of these subs we're kind of in a similar area and you just wanted to include them both within a single boundary group so in my case I kind of have a lab I have a boundary group here what we could do is you would just want to make sure that under the references for your boundary group that both of the site systems are here so that would just ensure that your clients kind of split across the two different software update points evenly so just keep that in mind you might want to make sure that your stops are kind of in the same group or have them defined in a way where once up is local to your kind of clients that are that are close to that boundary group for example all right so we can see that the synchronization complete define and we now have our two subs using the same WCS database I hope this video was helpful and like always if you have any questions please feel free to leave it in the comment in the video below or the accompanying blog post

Channel: Patch My PC

Views: 7,342

Keywords: WSUSUTIL, WSUS Shared Database, SCCM SUP WSUS, SCCM Shared SUPs, Share WSUS SCCM, ConfigMgr SUP Shared Database, WSUS Share SUP DB, WSUS Shared DB, SCCM SUP Best Practice, Setting up Shared WSUS Database

Id: y7w7hBSHShc

Length: 37min 34sec (2254 seconds)

Published: Mon Feb 11 2019

Reddit Comments

[u/PatchMyPCTeam]

This guide is based on your feedback for the poll over on my Twitter: https://twitter.com/SetupConfigMgr

​

Overview

• In this video guide, we will be covering how to use a shared WSUS database for multiple software update points in SCCM. Using a shared WSUS Database is generally considered a best practice in well-connected scenarios since this offloads the vast majority of network impact if a client were to switch SUPs in SCCM.

Topics in Video

• Review the SCCM docs and why a WSUS shared DB is usually a good idea – https://youtu.be/y7w7hBSHShc?t=42
• Review why wsyncmgr syncs are faster when using shared WSUS database – https://youtu.be/y7w7hBSHShc?t=93
• Review current labs primary SUP with SQL DB, and secondary SUP using WID – https://youtu.be/y7w7hBSHShc?t=175
• Enable Debug and Verbose logging to wsyncmgr.log and wcm.log – https://youtu.be/y7w7hBSHShc?t=293
• Review how the WSUS_Configuration_Manager tread reads all available SUPs at startup and how it determines if it’s using a shared WSUS database – https://youtu.be/y7w7hBSHShc?t=419
• Review wsyncmgr.log for multiple SUPs in a non shared WSUS Database – https://youtu.be/y7w7hBSHShc?t=508
• Remove WID WSUS role service and add SQL WSUS role service – https://youtu.be/y7w7hBSHShc?t=686
• Configure SUP-2 to use SUP-1’s WSUSContent library folder for EULA/3rd-Party Update Content – https://youtu.be/y7w7hBSHShc?t=843
• Run WSUSUTIL.exe postinstall to change WSUS to use the shared SQL Database and Shared WSUSContent folder – https://youtu.be/y7w7hBSHShc?t=1005
• Resolve IIS misconfigurations after postinstall – https://youtu.be/y7w7hBSHShc?t=1215
  • Add “\\” to the beginning of Physical path in IIS Content virtual directly
  • Change Authentication for Anonymous Authentication to use WSUS Application Pool Identity instead of local IUSR account
• Start WSUS_Configuration_Manager and validate it updates SUP-2 configuration in the active SUP list to be a shared WSUS database – https://youtu.be/y7w7hBSHShc?t=1505
• Publish a third-party update to get a WSUS catalog change and run a SUP sync to review how the sync is now treated as a single SUP sync – https://youtu.be/y7w7hBSHShc?t=1637
• Setup shared WSUS database in a new clean WSUS installation on a new SUP rather than converting an existing SUP to a shared WSUS database – https://youtu.be/y7w7hBSHShc?t=1744

Commands and Notes:

• Powershell command to see WSUS installed role services: Get-WindowsFeature -Name UpdateServices\*
• Powershell command to remove WSUS WidDB: Remove-WindowsFeature -Name UpdateServices-WidDB
• Powershell command to install WSUS SQL Database Connectivity: Install-WindowsFeature -Name UpdateServices-DB
• WsusUtil command: WsusUtil.exe postinstall SQL_INSTANCE_NAME=”SCUP.CONTOSO.LOCAL” CONTENT_DIR=”\\SCCM3-DPMPSUP-1.CONTOSO.LOCAL\WSUS”
  • SQL_INSTANCE_NAME and CONTENT_DIR should be changed to for your environment details

Helpful Resources:

• Great blog post version of using a shared WSUS Database – https://blogs.technet.microsoft.com/configurationmgr/2016/10/12/how-to-implement-a-shared-susdb-for-configuration-manager-software-update-points/
• Manually switch clients to a new software update point – https://docs.microsoft.com/en-us/sccm/sum/plan-design/plan-for-software-updates#BKMK_ManuallySwitchSUPs
• Use a shared WSUS database for software update points (Installation Best Practices) – https://docs.microsoft.com/en-us/sccm/sum/plan-design/software-updates-best-practices#bkmk_shared-susdb
• Managing WSUS from the Command Line – https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127395

[u/theSysadminChannel]

Excellent tutorial as always.

[u/0scillator]

Haven't had a chance to check out the material yet but thanks for doing this - I just implemented a multi SUP shared DB without much documentation and it was a bit of a pain. Will check it out when I get a chance and provide feedback.

[u/thefritob]

Just a heads up, last spring i had to put in a ticket because I was having Office365 update issues and they had me unshare the DB and put the 2nd SUP on it's own DB because it was "an unsupported configuration." Not saying don't do this, but if you burn a support ticket on software updates you'll end up having to undo it, which really isn't a big deal just time consuming.