In a simplified nutshell, Windows Update works by sending a series of web service requests to a known Microsoft-managed endpoint -- let's say, for example's sake only, that endpoint is https://update.microsoft.com. From there it makes further requests to other Microsoft-managed endpoints, because the original response tells them to (e.g. redirects for load balancing) -- let's say these could be https://update1.microsoft.com, https://wu2.update.microsoft.com and https://windowsupdate.largescalecontenthost.net.
For the sake of argument/example, let's also assume that the web service specification for the public Windows Update is exactly the same as the one for WSUS, and nothing else exists in the requests that identifies it as a WU request, rather than a WSUS request.
Your hypothesis is that, if you can intercept all requests that Windows Update might make, and point them at your WSUS server instead, you might be able make your unmanaged clients pick up your WSUS.
Practically, however, you only have a small number of ways to intercept this traffic:
You configure a DNS proxy: Using our example setup, you would need zone roots for microsoft.com and largescalecontenthost.net. This would allow you to alter the IP addresses that your DNS clients receive, so that it gets the IP address of your WSUS server instead of the real Windows Update service. Here are some headaches I can see with that:
Maintaining the intercepting DNS proxy is hard. The IP addresses and service names in resilient, highly-available services are always changing. You would have to keep up with those changes. They might be using largescalecontenthost.net now, but then in a week's time, they might change to anothercontenthost.net, and you need to intercept these too.
Maintaining the intercepting DNS proxy is hard. If your DNS clients (i.e. your end-users) actually want to get to a real address in microsoft.com, your proxy will need to know to ignore that value and get the real one from a forwarder.
Interfering with encrpyted traffic is hard. The traffic is HTTPS-based, which means server traffic is signed using a private key known only to the valid Windows Update servers, which send on a public certificate as part of the traffic, and the WU client uses both to verify traffic is legitimate. If your WSUS server actually received this traffic, it would send its own certificate. The Windows Update client would validate this certificate using (at least) the Subject information contained in the certificate. It is unlikely that you would be able to obtain certificate(s) with Subject or SubjectAltName values that end in microsoft.com or largescalecontenthost.net, because you don't own those domains. Well-functioning certificate authorities will not honour a request for a domain that you don't own; and CAs that might allow this, tend not to remain in Windows' trust chain for very long.
You configure a DNS proxy, and your own internal CA: You use the internal CA to issue fake certificates for update.microsoft.com, update1.microsoft.com, wu2.update.microsoft.com and windowsupdate.largescalecontenthost.net. Here are some headaches I can see with that:
Interfering with encrypted traffic is hard. You would have to continue to issue these for any alternative hostnames that come up during the requests made by Windows Update. You probably won't immediately know that these are requests from Windows Update, because you won't have been able to inspect them, because they're encrypted. So you'll need an offline source of these hostnames to feed your process.
Interfering with encrypted traffic is hard. None of your end-user clients (i.e. your VMs) will trust your fake certificates, because you haven't imported the chain into your Trusted Roots stores. You will have to go to every machine and import your trusted root cert. While you're doing that, you might as well set the registry keys needed to point at the WSUS server in the first place.
You configure a DNS proxy, your own internal CA, you push the CA root out to all your clients, and you implement an outbound TLS reverse-proxy: Now your TLS reverse-proxy can decrypt the traffic sent and received by WU, make fake certificates on the fly based on what is needed by WSUS and, if you somehow hook that to rewrite DNS on the fly, too, all WU client requests are covered. Your clients trust the fake certs because the root got imported everywhere. Some big-ticket vendors have hardware that can claim to do exactly this, reliably enough, for a price. Next set of headaches:
Deciding what to decrypt is hard. Do you also want to intercept your finance team's internet banking? Your reverse-proxy is probably doing that already. Maybe you have a corporate policy that doesn't care about this, but I expect you'll have to maintain a whole heap of whitelists that prevent your proxy snooping on any traffic with a reasonable expectation of privacy.
Interfering with encrypted traffic is hard. Many sites attempt to be resilient against such proxies. Public Key Pinning is on the decline (because it's hard to get right), but it is a reasonably effective tool against you issuing fake certificates. Google will probably stop working, since they pin their certificates right into Chrome. The proxy might be configurable to strip the Public Key Pins headers out of the response, but it's still too late for any of your end-users who's ever been to those sites already.
Now, consider the alternative: Prepopulate a Windows Registry export file, with the few minimal values required to point the Windows Update client to your WSUS server. Log into all of your VMs and import the Registry file. Update your gold images/templates so that new VMs get those settings automatically. Update your process documentation so that build engineers know to include these settings. Lament the week you had to log in to all your estate and update settings manually, and look into how you might alleviate this manual effort in the future -- e.g. bringing everything into the fold of domain architecture (even a light-touch one), or rolling out an automation tool like Salt, Otter or even cross-domain Powershell Remoting -- so you never have to suffer this again.
In practice, I'm going to bet (unless your IT team is really methodical) that there is probably a secret common account on each of those disparate VMs. If not a common account, then a secret list of computers and credentials. If so, you can probably set the registry settings for 80% of those machines with a single, well-written batch file.
If not, well then your IT team's day-to-day maintenance tasks are probably a massive pain point for them.
