Software Update Point Switching is not working for some Clients

Question

Hi there,
I found nothing similar here and I hope this is the right section.
I´m running ConfigMgr 2012 R2 where one of the Site Systems from one of the Primaries is located in an untrusted Forest in a perimeter Network. The Site System there has the MP, SUP and DB Roles. In general it works great. The Systems in that untrusted Forest
get the SCCM Agent pushed, see and can install published Software packages and receive Windows Updates. But there are a few systems where everything works, except Windows Updates.
So I had a deeper look at what is happening and found out that the SUP switching is not working for them. They always try to contact the SUP from the Primary, which they cannot reach (this is intended).
From how I understand SUP switching as described here
http://blogs.technet.com/b/configmgrteam/archive/2013/03/27/software-update-points-in-cm2012sp1.aspx#pi140062=1
the Windows Update Agent tries to connect to a SUP every 30 minutes and after 4 failed attempts he will try to connect to the next one until he finds one which works.
As I said before, this seems to work for most systems in the untrusted forest, but some do not make any intentions to switch the SUP.
So my next step was to find out from where the Update Agent can get the information of the available SUPs. I think they either don´t receive the information that other SUPs exist, or if the Information is there, they don´t realize that there´s an error and
make no attempt to switch.
I used the System Center Support Center to gather all Information from some of the systems with that problems (Log Files, WMI information, registry information, policies etc.) but I cannot find where SCCM or the Update Agent store the information which SUPs
are available in my environment.
I´m sure the problem is on the Systems which fail to connect to the right SUP and not in the SCCM infrastructure itself, because for most of the systems everything is working just perfect. Unfortunately in the Blog Post above there´s also no information
where this information is stored and how it is obtained by the clients. In the comments there´s even one post which describes the same problem I have here, but there was no answer. I hope someone can point me into the right direction, because I´m stuck currently.
Things I tried additionally to all the log file / WMI / registry sniffing:
Removing the Software Distribution Folder and restarting the Windows Update Agent
Removing the WindowsUpdate Registry folder in the HKLM\SOFTWARE\Policies\Windows section in the Registry and restarting the Windows Update Agent.
Tried to reset the WUAgent with wuauclt /Resetauthorization additionally to the steps above.
I also tried to manually set the WUServer and WUStatusServer Keys in the registry to the new Server, but as soon as the next Update Scan cycle runs, the value is set back to the URL of the Primary Sites SUP
Is someone having additional ideas? It seems to me older systems are more affected (which were configured for a standard WSUS before SCCM 2012 was deployed) than newer ones which were installed when SCCM was in place already. But I don´t know what else to
"reset" on those machines without reinstalling them.

Answer 1

Thank you very much for your response. I must have missed that one by looking through numerous Logfiles. In this, there´s indeed a list of all available SUPs. So according to the LocationServices.log the machine should have a choice.
The WMI Key however, contains just one entry and this is the URL of the Primaries SUP which is not reachable in the untrusted forest. Is it OK that the WMI entry includes only one entry? If yes, what process is putting the results from the LocationServices
into WMI? It seems like the Windows Update Agent is feeded from the WMI Key then. If this is the case my problems seems to be the "communication path" between these two components.
Is this the job from the SCCM Agent, the Windows Update Agent or maybe some third component I´m not aware of? I wonder how I can fix this.