OU, Logical Processor, Physical Processor, and other class properties are not discovered with OpsMgr 2012 on Windows Server 2003

You may notice on your Windows Server 2003 servers monitored with OpsMgr 2012, that some class properties on Windows Computer instances are not discovered.  Organizational Unit, IP Address, Logical Processor, Physical Processor, etc.




Windows Server 2003 machines need a hotfix for this to work, due to some changes that were apparently made to the Windows Computer discovery script in OpsMgr 2012.


The hotfix is http://support.microsoft.com/kb/932370  “The number of physical hyperthreading-enabled processors or the number of physical multicore processors is incorrectly reported in Windows Server 2003”

Once you apply this, changes are made to the Win32_ComputerSystem and Win32_Processor classes in WMI to make them similar to Windows Server 2008 and later.  Makes me think that the SCOM team isn't testing a whole lot with Windows Server 2003 anymore.  Smile


After applying the hotfix and a reboot, the info comes in quickly.




Thanks to PFE Greg Davies for bringing this to my attention, and credit goes to Cameron Fuller and RobK for finding the solution.  Cameron has a quick way of using groups to find out who needs this hotfix quickly.



Apparently Daniele was recommending this ages ago – I am just catching up to these guys. 


Comments (11)

  1. Anonymous says:

    Thx for bring this up Kevin….Sorta makes u wonder what else may be broken.

    Glad the decision was made to run 2012 in parallel with 2008R2 at our installations.


    John Bradshaw

  2. Kevin Holman says:

    @Wilson –

    While I can totally understand your perspective, it is very common for monitoring platforms to require OS level hotfixes to work correctly.  Just look at my hotfix page and you can see many many required or strongly advised hotfixes which should be applied to servers no matter what monitoring tool you are using.

    As to the service pack, I'd seriously doubt we are going to see another major SP for a 10 year old operating system, that will be N-3 (3 versions old)… but thats just a guess.

    My recommendation is for customers to simply add this hoptfix into their monthly patching cycle for their servers, that they already are performing.

  3. Anonymous says:

    Thanks Kevin for clarifying that for me and also the quick response!

  4. Kevin Holman says:

    @ntguru5 –

    That's normal.  There is no issue reading simple perfmon data.  The issue is discovering specific information out of WMI.  The %Processor Time is collected against the Windows Server 2003 Operating System class, which is discovered.

  5. Kevin Holman says:

    @Rob – that sure sounds odd…. each management group does not cook down between them – they are distinct.

  6. Kevin Holman says:

    @Joey –

    Nope – I just installed the hotfix, then rebooted, and upon service startup the SCOM agent will run its discoveries.  Bounc the SCOM agent service and see if it speeds up.

  7. Anonymous says:

    My 2003 agents do not report their Logical and Physical Processors, but I am still able to view performance data like % Processor Time -Total.  Anyone know why that is?  Just wanted to know if I can hold off until our next patch maintenance…

  8. Wilson says:

    hoo-boy, telling customers that they need to patch *their* servers because something isn't working right on SCOM is not going to go over very well…..plus this hotfix requires a reboot.  Double-whammy…..  🙁

    Can we hope that Microsoft will incorporate this hotfix into a future Service Pack for Windows 2003?

  9. Joey says:

    Kevin, I see that you said "After applying the hotfix and a reboot, the info comes in quickly." did you have to do anything else?  I have installed the patch on several servers and I am not having any luck getting the info to populate.

  10. Rob says:


    I just came across this problem also, but not because details were not discovered.  After moving a couple of servers to a new subnet the IP address was not updated.  In most cases (not all) the IP address and AD Site are discovered.  OU is never discovered for 2003 servers.  

    After digging through the discovery script and finding the faulty WMI query it make sense that the IP address and potentially other attributes will not get changed.  What I am confused about is how they got there in the first place.  It might make more sense if this was an upgrad from 2007 but the management group is a clean install of 2012.  We are multihoming a number of agents so maybe cookdown is playing a role.

    Any thoughts?

  11. OdgeUK says:

    I have a strange issue where the OU information in the SCOM console is changing to just the top level of the domain, and not the full path. Where does SCOM get this information from so I can investigate?

Skip to main content