locked
Script to check file share RRS feed

  • Question

  • I have a vbscript that I am using to check for the existance of three files on a share and then write to the ops manager event log whether each of the files is found and whether it has been modified in the past 20 minutes.  When I run the script locally, logged into the agent computer with the SCOM admin account, it completes successfully and writes a healthy informational event to the logs for all three files saying they exist and have been modified recently.  However, when I set SCOM up to execute this script via a rule, it runs correctly, but logs an error to the logs saying the file was not found for each of the files I provided to the script. 

    It sounds like a permissions issue to me, but I just wanted to see if maybe there was something I am missing.  When the rule is targeted at a certain Windows Server, it is the SCOM action account that executes the script on the local machine right?  If I need to post the script, I can do that too.  Just let me know if you need to see it.

    Thanks
    Monday, October 26, 2009 5:01 PM

Answers

  • Hi,
    I think you could also solve that with a run as profile, so you use another account when running that check-file-share-script on that machine.
    Anders Bengtsson | Microsoft MVP - Operations Manager | http://www.contoso.se
    • Proposed as answer by Dan Rogers Thursday, October 29, 2009 2:42 PM
    • Marked as answer by Cole W. _ Monday, November 2, 2009 7:26 PM
    Monday, October 26, 2009 6:40 PM
  • Hi Cole,

    Yes, I agree with sorabh_ms about dividing a problem into smaller parts. For the beginning I would confirm that the rule is executed with a proper RunAs account. In order to do it you can try to include the following information to your event:

    ----------------------------------
    Dim wshNetwork
    Set wshNetwork = WScript.CreateObject("WScript.Network")
    WScript.Echo wshNetwork.UserName ' add UserName to your event...
    ----------------------------------

    Thanks,
    Zaki
    • Marked as answer by Cole W. _ Monday, November 2, 2009 7:31 PM
    Friday, October 30, 2009 5:39 PM

All replies

  • Hi

    It is indeed the Action Account that is "executing" the script and that is by default local system. You might want to choose an agent whose action account is a domain user account.

    I did this up in response to someone asking for something similar a while back on the forums:
    http://systemcentersolutions.files.wordpress.com/2009/07/fileexists.pdf

    It is quite a large document so may take a minute to download but you can check the steps against yours. It basically checks the existance of a folder and then a file (and then checks the size of the file). Because your script is remotely checking a share, it is likely to be a permissions issue, although interestingly the error isn't access denied (but that might just be your error checking ... because the share can't be accessed the error coming back is that the file can't be found). Might be worth doing it as a 2 step process:

    1) Check share - if share not found then error msg1

    2) If share ok, then check file. If file not found then error msg2.

    Feel free to post up the VBScript although from what you are saying, there doesn't seem to be an issue with it.

    Good Luck

    Graham



    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Monday, October 26, 2009 6:12 PM
  • Hi,
    I think you could also solve that with a run as profile, so you use another account when running that check-file-share-script on that machine.
    Anders Bengtsson | Microsoft MVP - Operations Manager | http://www.contoso.se
    • Proposed as answer by Dan Rogers Thursday, October 29, 2009 2:42 PM
    • Marked as answer by Cole W. _ Monday, November 2, 2009 7:26 PM
    Monday, October 26, 2009 6:40 PM
  • Agree that you could use a Run As Profile but to associate a rule \ monitor with a run as profile will require scripting .... it would potentially be the "neater" approach as it would mean the action account could stay as local system but it would take a lot more work to achieve.

    Stefan has a great blog about it here.
    http://wchomak.spaces.live.com/blog/cns!F56EFE25599555EC!339.entry

    Have fun

    Graham
    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Monday, October 26, 2009 6:56 PM
  • Thanks for the responses guys, as always!  I am a little confused now to say the least, I thought the agent action account is the account running the script in the rule, which in this case would be my SCOM action account that is a domain user.  Am I missing something here?  I have checked the share and all domain users have read and execute rights against it.  It's very odd that I can log onto the server that the script is running on (agent managed and SCOM action accound is in admin group) and run the script locally and receive the desired output in the opsmanager event log, but when I schedule it through a rule, it fails and says it can't find anything.

    Graham, I tested your method of including more error checking, and was not able to get it to find the share folder itself.  It wouldn't be so odd to me if this rule had not been running in MOM for two years now and is set up the exact same way as it was in that space.  The only difference is the script is running on a W2k8 server...
    Monday, October 26, 2009 9:22 PM
  • Oouchh ... windows 2008 always makes me wince when it comes to permissions. Spent a lifetime complaining MSFT products aren't secure and now windows 2008 comes along and I spend half my time opening it up to get anything to work ;-)

    No, you don't seem to be missing anything. Remember that you'd need to set share and ntfs permissions (actual rights are the most restrictive of the 2).

    When you run the script from the server, do you get run as administrator? Do you get prompted by windows when you try to run the script? For a test, you could turn off UAC for that user and see if that helps:
    http://technet.microsoft.com/en-us/library/cc709691(WS.10).aspx#BKMK_S3

    Cheers

    Graham
    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Monday, October 26, 2009 9:37 PM
  • Not quite sure what you mean by a run as profile "requires scripting", but you can add a Run As Profile to a rule in the Operations console. Go to Rule Properties, Configuration tab if member serves and you'll see it in the bottom window. A Run As Profile on a monitor does require XML or using the SDK as Walter's alticle suggests.


    Pete Zerger, MVP-OpsMgr and SCE | http://www.systemcentercentral.com
    Tuesday, October 27, 2009 5:11 AM
  • Alright, so I was able to test against an agent on a 2003 server, and had the same results :(

    I have disabled UAC on the server, set up a run as account that was my personal domain account to run the script locally on the machine, and set it to the rule as mentioned by Pete.  With these two changes, I received the same results.

    I am including the script for you guys to take a look at, just in case there is something that I could be doing better, or something that I could do to add a little more error checking capabilities.....I am out of ideas :(

    I am really curious now whether this is going to be an issue with all scripts I try to run remotely, or if it is just because I am attempting to check a file share through a remote agent.


    Dim objAPI

    Const EVENT_TYPE_ERROR = 1

    Const EVENT_TYPE_WARNING = 2

    Const EVENT_TYPE_INFORMATION = 4

     

    Set objAPI = CreateObject ("MOM.ScriptAPI")

    'Add in first file directory parameter

    strFirstFile = "\\Share\share1\BusObj 5\Report - Report for Monitoring.pdf"

    strSecondFile = "\\Share\share1\BusObj 5\Development - Report for Monitoring.pdf"

    strThirdFile = "\\Share\share1\BusObj 5\Development - Test Report for Monitoring.pdf"

    Call FileExistCheck (strFirstFile)

    Call FileExistCheck (strSecondFile)

    Call FileExistCheck (strThirdFile)

    Sub FileExistCheck (strFile)

    Set FSO = CreateObject("Scripting.FileSystemObject")

    If FSO.FileExists(strFile) Then

    Date1=Now()

    Set ObjTargetFile = FSO.GetFile(strFile)

    Date2=ObjTargetFile.DateLastModified

    Compared = DateDiff("n",Date2,Date1)

    If Compared > 20 Then

    Call objAPI.LogScriptEvent ("FileShareCheck.vbs",4440,Event_Type_ERROR,"The file " & strFile & " exists, but has not been modified in over 20 minutes.")

    Else

    Call objAPI.LogScriptEvent ("FileShareCheck.vbs",4440,Event_Type_INFORMATION,"The file " & strFile & " exists, and has been modified in the past 20 minutes.")

    End If

    Else

    Call objAPI.LogScriptEvent ("FileShareCheck.vbs",4440,Event_Type_Error,"The file " & strFile & " was not found at the given location.")

    End If

    Set FSO = Nothing

    End Sub

    Tuesday, October 27, 2009 5:29 PM
  • Graham,

    Have you or anyone else been able to test and verify this issue?  I seriously think it may be the way SCOM handles the authentication, as I have just ran accross the issue that the web application templace method has with NTLM authorization.

    I have checked the share and it allows domain users access to it, as the SCOM administrator account which the script is running as is a domain user.  I am guessing it may be time to stop fooling with it, and go ahead and give Microsoft a call.
    Thursday, October 29, 2009 1:58 PM
  • I might have missed it - but have you logged onto the box as the a/c SCOM is using, and manually run the script? Just to verify that it can access the share?
    Thursday, October 29, 2009 2:18 PM
  • Hey Nick,

    Yes I have logged on as the SCOM admin account and successfully ran the script and got the results as expected...
    Thursday, October 29, 2009 9:54 PM
  • oh yeah - there it is, in the second sentence :(
    Thursday, October 29, 2009 10:11 PM
  • Hi Cole,
    If i would be you, i ll break the problem into smaller bits, try to run a simpler script ( may be just check the file locally on the server ) , if that fails as well then its clearly the account its running under rather than the remote share permission.
    Next change the default accoun the agent is running under, from local system account to some other domain account and then retry. Coz there is nothing wrong with the script as you can execute it from the cmd line perfectly.

    Friday, October 30, 2009 5:18 PM
  • Hi Cole,

    Yes, I agree with sorabh_ms about dividing a problem into smaller parts. For the beginning I would confirm that the rule is executed with a proper RunAs account. In order to do it you can try to include the following information to your event:

    ----------------------------------
    Dim wshNetwork
    Set wshNetwork = WScript.CreateObject("WScript.Network")
    WScript.Echo wshNetwork.UserName ' add UserName to your event...
    ----------------------------------

    Thanks,
    Zaki
    • Marked as answer by Cole W. _ Monday, November 2, 2009 7:31 PM
    Friday, October 30, 2009 5:39 PM
  • Zaki,

    I added this into my script, and found that it was showing the user 'SYSTEM' as the one that was running the script.  I created a run as profile (type - Windows, domain user, distributed to server script is running on) and associated it with a profile (targeted at server object), and ran the script again and it is showing the domain user in the output.  Problem solved!

    Thanks for the help everyone! 

    Monday, November 2, 2009 7:31 PM