ConfigMgr 2007 Crash Dumps: Monitoring SMS Executive script error : ‘Permission denied’ 70 (0×46)

I recently encounter a strange error in a ConfigMgr 2007 rule in one of our OpsMgr 2007 R2 environment.

The error is the following :

Alert Rule: ConfigMgr 2007 Crash Dumps: Monitoring SMS Executive script error <servrnme> – ConfigMgr 2007 Crash Dumps: Monitoring SMS Executive script error. The script ‘ConfigMgr 2007 Monitor SMS Executive Crash Dumps’ running under processing rule ‘{8A4A5EB4-52D2-E4B8-6BD9-E5D659B5EFB8}’ encountered a runtime error. Failed to save script variables. The error returned was: ‘Permission denied’ 70 (0×46)


As usual I started looking inside the MP to try to understand the source of the problem. The rule is called “SMSv4_Crash_Dumps__Monitoring_SMS_Executive_24_Rule” and uses a write action called “SMSv4_Monitor_SMS_Executive_Crash_Dumps” to execute a script. This MP is converted from MOM 2005 so the script is of type System.Mom.BackwardCompatibility.ScriptResponse.

The error is generated by the followings lines of code :

‘Persist the var set this script uses.


If 0 <> Err.number Then
    ScriptError "save script variables." & GetErrorString(Err)
End If

So I supposed that the error is generated inside the function “SaveVarSet” :

Sub SaveVarSet()
    Dim oFSO
    Dim oTempFolder
    Dim oFile

    Set oFSO = CreateObject("Scripting.FileSystemObject")
    If 0 <> Err Then
        ScriptError "create Scripting.FileSystemObject." & GetErrorString(Err)
        Set oTempFolder = oFSO.GetSpecialFolder(2)
        If <> Err Then
            ScriptError "find the Temp directory." & GetErrorString(Err)

            Set oFile = oFSO.CreateTextFile(oTempFolder.Path &amp; "\" & ScriptContext.Name & ".SCOM2007.VarSet", True, True)
            If 0 <> Then
                ScriptError "create the '" & ScriptContext.Name & ".SCOM2007.VarSet' file in the Temp directory." & GetErrorString(Err)
                Dim aKeys, aItems, lIndex
                aKeys = g_oDictionary.Keys
                aItems = g_oDictionary.Items
                For lIndex = 0 to g_oDictionary.Count - 1
                    oFile.WriteLine aKeys(lIndex) & vbTab & aItems(lIndex)

            End If
        End If
    End If

    Set g_oDictionary = nothing
End Sub

The first BUG is that in this function it is not present an instruction “On Error Resume Next” so it is useless to put instruction like “If 0 <> Err then” because they will never executed in case an error occurs as described in MSDN (On Error Statement)  : 

… If local error-handling is not enabled in a procedure and an error occurs, control is passed back through the call stack until a procedure with error-handling enabled is found and the error is handled at that point…

Looking at the function only a few line of code could generate an error “Permisson Denied”, and my supposition was that the problem should be in the line where the script try to Open or Create the text file used to store the var set the script uses. To verify this hypothesis I got a filemon trace during the script execution and this is the output of the trace :


Looking at the trace I found that the same MonitoringHost instance is trying to Create the file 2 times, the first call succeeded, the second call failed with a SHARING VIOLATION (obvious). But why 2 times? the script tries to open the file only 1 time and I searched in the MP and no other rule uses this file to save vars on that machine. The only explanation could be that the script executes two times, and while I thinking why it could happen I realized that this is a multihomed environment. I disabled this rule in one of the ManagementGroup and the problem disappeared.

In conclusion this rule has a BUG that prevents it to run successful in a multihomed environment. How could this problem be fixed? One solution could be to concatenate the “management group GUID” to the name of the file used to store the var set of the script, in this way event if the script runs twice every instance of the script will use a different file.

– Fabrizio

This posting is provided “AS IS” with no warranties, and confers no rights.

About these ads


  1. #1 by Rich on February 20, 2010 - 3:38 am

    been at this issue for two weeks. Thanks for the info, really helped.

  2. #2 by Leonida Wisnoski on January 23, 2010 - 6:37 pm

    great info thanks for discussing, hope you had the best new year.

  1. ConfigMgr 2007 MP – crash dumps monitor script failure « Quae Nocent Docent

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 266 other followers

%d bloggers like this: