Month: February 2011

SCOM alert for ‘SMS_WSUS_SYNC_MANAGER’

Posted on Updated on

If both SCCM and SCOM are implemented in your environment (and SCOM is monitoring SCCM) then you may at some time receive the following alert:

The availability state for SMS component ‘SMS_WSUS_SYNC_MANAGER’ in site XYZ changed from ‘Online’ to ‘Failed’. Its installation state is ‘Installed’. Its execution state is ‘Hung’. This component last provided a heartbeat at ‘DATE TIME‘. The next heartbeat is expected in ‘3600’ seconds from that time.

Investigation of the alert (SCCM console, logs, etc.) reveals that the component is truly functional and never reports being hung.  After a long drawn out support case with Microsoft, this is what was discovered:

Whenever a scheduled sync is triggered it does a complete sync and that is by default to run for about 40-50 minutes. And during this action the SCCM marks a registry as “3”(HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\SMS\Operations Management), which means that the service is hung. This registry change is made if the heart beat is not received by the WSUS component(this heart beat is from the WSUS component to the SCCM), by default the heart beat is received within 6 minutes every hour(i.e. 2:00-2:06, 3:00-3:06…and so on), and whenever next time the heart beat is received then the component is marked as online and usable. So SCCM console doesn’t show any issue. However during this time MON monitors the registry and comes to know that the component is marked as “3” so it send the alert. Our motive here is SCCM should not mark the registry as “3” and that can be established if we have the sync process start after 2:06 and end before 3:06 or respectively. This behavior is by default.

So the solution (just a workaround) is to schedule the sync to occur in the 7th minute of the hour (e.g. 2:07 instead of what I had at 2:00).  Additionally they said a true fix won’t be created because there has not been enough reported issues to justify a fix.  Anyway, I hope this helps!

**** Update as of 2/28/11 ****

To help determine that SCCM was incorrectly setting the registry values, I wrote a simply VBScript to log the registry values (code below).  Then on the server, I created a custom scheduled task to run the script every 1 minute for the period being monitored.

' This script runs via a scheduled task to capture registry entries SCCM WSUS Sync
' Written by Nick Moseley
Option Explicit
Const HKLM = &H80000002
Const ForAppending = 8
Const sLogFile = "C:\PSS_WSUS.log"
Dim oShell, oFSO, sKeyPath
Set oShell = CreateObject("WScript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")
sKeyPath = "HKLM\SOFTWARE\Wow6432Node\Microsoft\SMS\Operations Management\Components\SMS_WSUS_SYNC_MANAGER\Execution State"
Dim oLogFile
If Not oFSO.FileExists (sLogFile) Then 
    oFSO.CreateTextFile sLogFile
End If
Set oLogFile = oFSO.OpenTextFile (sLogFile, ForAppending, True)
oLogFile.WriteLine  "ExecutionState: " & oShell.RegRead(sKeyPath) & " (" & Date & ", " & Time & ")"
wscript.Quit(oLogFile.Close)
Advertisements

Limit DCM and Programs to Win7 RTM

Posted on

Microsoft began supporting Windows 7 in SCCM with SP2, so there has been the option to limit execution of DCM or package/program on a computer running Win7.  SCCM has the ability to limit execution based upon an OS + Architecture + SP level.  For example, you could limit execution to just Vista x86 RTM by selecting the following option.

Now that SP1 for Win7 has been released (to MSDN/TechNet/MVLS), you may find yourself in a position of needing to prevent a DCM or package from running on computers with SP1.   Unlike with other operating systems, SCCM SP2 doesn’t have an option to limit execution to “x86 Windows 7 original release”. 

To work around this, I found (for both DCM and package/programs) that selecting option “x86 Windows 7” will detect Win7 SP1 as not being applicable….and it works in my brief tests!