While this is technically possible, there's probably a better way to go about it.
And speaking of better ways to go about it, You could do this in a GPO with a few lines of code as a startup or shutdown script, which is how I handle this. With a few more lines of code you could log the results of checking for the presence of this thing and/or uninstalling it, which would undoubtedly be useful in your compliance efforts.
If a GPO-linked startup/shutdown script's not an option for whatever reason, I think I'd use PSExec to kill the process on a list of computers read in from file and then script the uninstall in an appropriate language. Seem to me that this is a lot easier in VB, for example.
a=WshShell.RegRead("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{2318C2B1-4965-11d4-9B18-009027A5CD4F}\UninstallString")
If a<>"" Then
WshShell.Run(a&" /S"),1,True
i=i+1
end if
(Goodbye Google Toolbar, in that example which I wrote or copied a few years back. Copied, probably. I am rather lazy.)
Without debugging the PS script you copied, I'd point out that you might be running a different PS version, different PS modules installed/loaded and/or there might be some dependencies that your XP machines don't have in place that's causing problems.
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.
Best Answer
You want to filter on the
EvaluationStateproperty of the updates that are returned. There are several types of Evaluation States for pending reboots, they are listed on the technet page for the sccm client sdk. States 8,9, & 10 are for pending reboots. Looking at your function, I would do something likeIf you're going to feed raw syntax instead of using powershell, whatever floats your boat. I don't have any pending sccm updates right now, or time to rig up a test box, but this should get you going.