SCCM – How to make new deployed applications appear in Software Center faster

Are the machines picking up your SCCM Site Code automatically? Presumably you're deploying the SCCM client with the SMS Site Code set to AUTO, which would normally mean that through a combination of AD and/or DNS the machines should find your SCCM site code and server automatically.

On a problem PC, if you look in Control Panel, Configuration Manager applet, Advanced tab you should see "Currently Assigned to Site Code:" with your three letter site code in the box. If it's not there, click the Discover button and make sure it appears.

The errors you're getting look like the clients tried all the methods it knows for discovering the management point and ended up looking for the SLP in WINS, as it couldn't find the management point in DNS, and couldn't access the schema extensions in AD. See Configuration Manager and Service Location (Site Information and Management Points), see also How to Extend the Active Directory Schema for Configuration Manager. Check the permissions on the System Management container that's been created, most methods of extending the schema don't automatically assign the needed permissions to this folder

Other things worth checking are time related settings on the client, make sure that the client are set to the right time (also check what time zone they think they're in to make sure the clock is really showing the right time), if the clock on your clients is more than an hour out from the server you'll have problems. Do a net time /set on the client to sync it up with your domain controller.

Also check the firewall settings on the XP machines, we've had problems with them where SCCM isn't getting through the built-in XP Windows Firewall properly.

Perhaps the REV site code was used for a temporary test installation of SCCM 2012? Perhaps not. Institutional knowledge doesn't have any record of the REV it and the migration we performed before I was hired.

This hunch was correct. I got a hold of my predecessor and apparently the first and unsuccessful attempt to migrate from SCCM 2007 to SCCM 2010 used the REV site code. How it managed to sit dormant in WMI all this time and why it got "activated" is a complete mystery to me.

I very carefully re-read the solution in this TechNet post which advised deleting the old namespaces and decided to try that. I kind of hesitate to mark this as an answer even though it did resolve this issue, it indicates that I implicitly approve of it, especially since I couldn't get anyone "official" at Microsoft to confirm whether or not this was a safe approach or what the consequences were for doing this. That being said, make sure you have complete backups of your SCCM server or at least a much more intimate knowledge of WMI before proceeding. You could very easily break everything doing this, especially if like me, you're not familiar with WMI and how deeply SCCM leverages it.

I used wbemtest to connect to the root\sms namespace on our SCCM server. From there I used the [Enum_Instances...] button and search for __NAMESPACE as the superclass. I deleted the entry for the REV site code. I then did the same Enum_Instances for the SMS_ProviderLocation as the superclass and deleted the old site code from that namespace. Re-running the Automatic Deployment Rules and reviewing the PatchDownloader.log showed the successful downloading of each Windows Update.

I would greatly appreciate more information about how these namespaces are used by SCCM and exactly how this fixed the issue if anyone has more detailed information.