LawrenceGarvin

Well, that makes it simple. If there's no Update Services service, then it's not a WSUS Server, and without the service, that'll make it near impossible to connect to the database. Either the installation is corrupted, or the role was partially uninstalled. Inasmuch as it seems the WID was in SINGLE_USER mode when WSUS was being installed (we know that's where it was when the post-install wizard was launched), this thing could be all sorts of sideways. Your best option may be to start from scratch.

It's difficult to imagine what would have caused the database to get stuck in SINGLE_USER mode on a WS2012/WSUS v6.x installation, but there is only ONE way to resolve this issue. 1. STOP the Update Services service. (The reason you cannot get your console connection to work is because the SERVICE has already consumed that one authorized "user".) 2. Open SQL Server Management Studio. (When using WID, you may need to download and install SQL Server 2012 Management Studio Express Edition.) 3. Execute this command: ALTER DATABASE SUSDB SET MULTI_USER; 4. Restart the Update Services service.

The typical way in which WSUS is implemented for supporting VPN clients is to deploy an additional replica server WITHOUT a local content store. (i.e. Updates, Groups, and Update Approvals only). Because there are no files on the replica WSUS server, the VPN clients will download those files direct from Microsoft (but still get approvals from the central management server). More notably, the clients will continue to get those updates, and install them, even if they do not remain connected to the VPN -- the files will be downloaded over the regular Internet connection. In addition to this implementation, using a separate target group for those VPN clients, as Michael has suggested, is also a good idea. In this way you can also control the when regarding the deployment of those updates. (e.g. Maybe you want to focus only on High-Priority Security Updates during the week after Patch Tuesday, then do Critical Updates in the 2nd week after Patch Tuesday, and defer all non-critical/non-security updates to the 3rd week after Patch Tuesday -- which is also when Microsoft typically releases those non-critical/non-security updates.)

The 99% value actually has nothing at all to do with approvals, directly, in most cases, but can be impacted by a missing approval. More often than not, though, it's simply the presence of an update that is not yet installed (and may actually be already approved). If you are synchronizing Definition Updates, then it's actually a *normal* indication that a client is 99% Installed/NotApplicable, because there will most certainly almost always be a current Definition Update that has not yet been installed. Even more so if your clients are using the default detection interval (22 hours). For Definition Updates with Auto-Approval rules, you may find more consistent statistical reporting if you synchronize the WSUS server 3x or 4x daily, and configure the clients with 6-hour (or 8-hour) detection intervals. To see specifically what is contributing to this <100% value, filter the All Updates view on Approval="Any Except Declined" and Status="Failed or Needed", and then sort on the "Approval" column. You may actually find several updates that are NotApproved, and intentionally so -- for example, on my WSUS server I currently have 24 updates that are needed by at least one system, but intentionally Not Approved because I've chosen to not deploy those updates. If you find any that are NotApproved, but should be, then obviously you should approve those update(s) for the appropriate group(s). Otherwise, if everything is Approved, then the <100% indicates an approved update not yet installed. If some updates are intentionally not approved, then the <100% may be an absolutely normal indication. What you may find more useful for monitoring compliance is looking at the Percentage Installed/NotApplicable on the *update* rather than on the computer. With only a few exceptions, updates should ultimately be reported as 100% Installed/NotApplicable, and if not, then you should be able to directly identify the system(s) where the update is not installed, and exactly why it is not installed -- effectively indicating a fully compliant environment for that update.

The fix for this is to install KB2734608 and then re-run the setup wizard.

Error code 0x8024402C when you try to install updates on Windows Update or Microsoft Update Web sites Unable to Download Updates from WSUS, Error 0x8024402c - TechNet Articles - United States (English) - TechNet Wiki WSUS: Client sync fails with 80072ee7 and 0x8024402c errors in WindowsUpdate.log - The WSUS Support Team Blog - Site Home - TechNet Blogs

Actually, based on the fact that all of the updates have NO STATUS, they're not even TALKING to the WSUS server. They are "registered", so that tells us that your GPO and Proxy configurations are correct, but now the question is why are they not talking. Inasmuch as your WSUS server has only been running "for a few weeks now", the most likely case here is that your WSUS clients, which probably were AU clients previously, were updated with the new Windows Update Agent in June, 2012. But your WSUS server, being new, probably does not have the KB2720211 patch applied, which is required so that the June, 2012, WUAgent (v7.6) can successfully detect/report to the WSUS server. This situation will be evidenced by the presence of the 0x800B0001 error code in the WindowsUpdate.log of each client system.