GPO change, and clients went to MS for updates?

Question

I'm trying to prepare for a switch to SCCM 2012 SUP. Our existing WSUS infrastructure has been solid for years (native WSUS no SUP).
I made a change to the GPO that is configuring where the WSUS servers are (the "specify intranet Microsoft update service location") by setting this to "not configured" but in the same policy adding a preference to look for the SCCM 2012
client install, if it's NOT installed then manually write the two reg keys ("WUServer" and "WUStatusServer") with the correct server information.
The idea is that once the clients get the SCCM 2012 policy they will stop looking at our old WSUS infrastructure and the SCCM (SUP) will take over the update management on the client.
What I found was that even though this logic worked, meaning the reg keys would contain the proper WSUS server locations, after a gpupdate the machine would freak out and immediately go to Microsoft for updates! They ignored all the other settings, for example
time to check in. A gpupdate immediately triggered the wuauclt to go to work getting updates from Microsoft - no /detectnow needed, it's going right now! Looking at the windowsupdate.log shows that the WSUS server was set to <NULL> even though the policy
reg keys existed and are correct.
To better test this I created a duplicate WSUS policy of the one that we've been using over 2 years and applied it to a machine that previously had the same policy settings I just created, and it had the same effect. The content of the policy deosn't seem
to matter. If I removed policy "WSUS policy" and replaced it with "Copy of WSUS policy" (even if they have IDENTICAL settings, as in one is literally a gpedit make copy of the other) the machine would freak out and go to MS for updates
until I did a GPupdate another 2 times... after which it would "settle down" and work the way the policy says to. Not only that, but these two policies now seem to be "known" by the client and changes made to them are OK, and do not force
the MS updates.
Is this by design? It feels like MS doesn't want to "risk" not knowing the wsus policy settings are and will default to get all it's updates right from MS if it "thinks" there is any problems (to protect from malware, virus, etc)?

Answer 1

Thanks Jason, I actually just finished working with MS support on this late last week. There are a couple of things here:
1. I learned that the GPO setting "Specify intranet Microsoft update service location"
adds not only the two intranet wsus server reg entries but the additional reg key "UseWUServer" set to 1 under the AU reg path. This is required to use the reg keys that plug the server information. So I was troubleshooting my reg key logic
to plug the servers, which worked, but was ignored. It appears that the WUA is looking to this key and triggering the checks for all things update exclusively on this key. If you don't
specify
this key when adding "manual" reg keys it will ignore all the GPO policy settings (time to check, how to install, etc), not just the server location settings.
2. I also learned that this method is should not be implemented when migrating to SCCM 2012 from a native WSUS infrastructure. The MS recommended solution is to use a WMI filter on the entire WSUS policy checking for the existence of the SCCM 2012 client
and NOT apply any policies if the 2012 client is installed. The way to check is to look for the file existence of c:\windows\ccm\ccmexec.exe (not version of this file).
3. In my troubleshooting on this issue I also learned that the SCCM 2012 client (and possibly the 2007, but we don't use it) are actually using local machine policies to manage updates so it would make sense to NOT apply any domain level policies setting
anything having to do with updates and instead let the 2012 client just handle the settings else you have domain policies "defeating" the local polices.