Short answer: NO, unless you really need it and you really know what you are doing.
WMF 3.0 is known to be not compatible at all with Exchange Server (both 2007 and 2010), at least until further updates are released for these products; also, although this is not yet officially documented, it has been found to wreak havoc on SharePoint 2010, and to break Small Business Server 2008/2011.
I've also personally experienced it completely and utterly destroying System Center Configuration Manager 2012, and breaking both the setup and the Configuration Manager for SQL Server 2008 R2, which, after its installation, started failing with loud complaints about the WMI service not being available (although it was actually running fine).
Last but not least, once WMF 3.0 is installed, it can become very hard to remove it, because its uninstaller has quite a real chance of failing, leaving your servers in an inconsistent state which usually requires a full O.S. reinstall to get them up and running again.
Be very, very, very careful with this update.
Update: apart from known compatibility issues with various programs, it looks like installing WMF 3.0 can (sometimes? often? always?) completely destroy WMI. Well, this sure explains why nothing seems to work anymore after installing it...
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
The following Powershell script uses WMI to find which computers do not have Hyper Threading turned on by comparing cores to threads. You should run it in an Administrative console using as a Domain Administrator account:
This shows the CPU core and thread counts for all computers in Active Directory who's name starts with host. If there are multiple CPUs they will show up as CPU0, CPU1, etc. Example:
I still think there should be a way to use SCOM to do this, but the above works.