locked
Detecting failures from cmdlets RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    We are using R2 and have a need to schedule objects into a daily maintenance mode.  For example, service X on server Y needs to go into maintenance mode every day from 8:00pm to 9:00pm.

    So far, we are handling this with a powershell script that is called from a Windows scheduled task.  We are using something along the lines of:

    param($Minutes)

    $rmsserver = "myrms.company.com"

    $comment = "Normal Daily Maintenance for Service X"

    $reason = "PlannedOther"

    Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin;
    Set-Location "OperationsManagerMonitoring::" -ErrorVariable errSnapin;
    new-managementGroupConnection -ConnectionString:$rmsserver -ErrorVariable errSnapin;
    set-location $rmsserver -ErrorVariable errSnapin;

    $startTime = [System.DateTime]::Now
    $endTime = $startTime.AddMinutes($minutes)


    $objMaint = "\myrms.company.com\Microsoft.SystemCenter.AllComputersGroup\serverY.company.com\serverY.company.com%003aServiceX"

    New-MaintenanceWindow -startTime:$startTime -endTime:$endTime  -comment:$comment -Reason:$reason -path:$objMaint

    ---------------------------------------

    When we run this from the Windows Scheduled task, it runs fine with a result of "The operation completed successfully. (0x0)".

    If I update the objMaint variable above to a non-existant object, (i.e. change the end to ServiceY) and run the scheduled task again, it still completes successfully. 

    Running the powershell script from powershell itself, I see the errors on the execution of the "New-MaintenanceWindow" cmdlet letting me know it cannot find the path.

    I'm looking for ideas on how I could detect and report on failures so that I'm aware this object isn't actually going into maintenance.

    Thank you,

    Kate

    Thursday, October 7, 2010 9:25 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    You simply want to return an error code to the Task Scheduler service?  I have an idea that combines one or two blog posts...  What do you want returned, just a non-zero value, for example?  0=success, 1=failure (of any kind)?
    • Marked as answer by Vivian Xing Wednesday, November 3, 2010 2:23 AM
    Friday, October 8, 2010 8:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Kate,

    This article by Daniele might help.

    http://nocentdocent.wordpress.com/2010/03/18/returning-failure-from-powershell-in-probes/

    HTH, Jonathan Almquist - MSFT
    • Marked as answer by Vivian Xing Wednesday, November 3, 2010 2:23 AM
    Sunday, October 24, 2010 5:25 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    OK, here's v1:

    $ErrorActionPreference="stop"

function send-email {
 $smtp=New-Object System.Net.Mail.SMTPClient –ArgumentList some_smtp.server.com
 $smtp.Send('from@domain.com','to@domain.com','Script error','Script error')
}

function write-event {
 if(![System.Diagnostics.EventLog]::SourceExists("PowerShell_script")){
  [System.Diagnostics.EventLog]::CreateEventSource("PowerShell_script","Application")
 }
 [System.Diagnostics.EventLog]::WriteEntry("PowerShell_script","Script error","Error",999)
}

trap {
 send-email
 write-event
 continue
}

your_powershell_commands

    • Proposed as answer by Marco Shaw Friday, October 29, 2010 12:59 AM
    • Marked as answer by Vivian Xing Wednesday, November 3, 2010 2:22 AM
    Friday, October 29, 2010 12:51 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    You simply want to return an error code to the Task Scheduler service?  I have an idea that combines one or two blog posts...  What do you want returned, just a non-zero value, for example?  0=success, 1=failure (of any kind)?
    • Marked as answer by Vivian Xing Wednesday, November 3, 2010 2:23 AM
    Friday, October 8, 2010 8:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    A non-zero value would be fine to keep it simple.  I'm open to any solutions that would let me know there was an issue within the script.


    Thanks for your ideas, suggestions.

    Kate

    Thursday, October 21, 2010 2:09 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    There's a particular trick to get a PowerShell script to return an error code to the Task Scheduler.  I had seen others indicate that it may not work on R2, and I think I've just confirmed that.

    But are you actually going to look at the Task Scheduler return codes or do you want your script to write to the Windows event log or possibly even email out that there was a failure?

    Friday, October 22, 2010 3:27 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Writing to the event log or emailing would be an ideal solution.  Ideas on how to accomplish that?
    Friday, October 22, 2010 3:50 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Yup, I'll response in the next 12 hours with both methods...
    Friday, October 22, 2010 3:55 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I was writing the script, I came across my own questions on whether I was doing something properly.  I'm going to ping some fellow PowerShell'ers...  Hopefull you can wait until Monday...
    Saturday, October 23, 2010 1:34 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Kate,

    This article by Daniele might help.

    http://nocentdocent.wordpress.com/2010/03/18/returning-failure-from-powershell-in-probes/

    HTH, Jonathan Almquist - MSFT
    • Marked as answer by Vivian Xing Wednesday, November 3, 2010 2:23 AM
    Sunday, October 24, 2010 5:25 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Here's some sample code:

    $ErrorActionPreference="stop"

function send-email {
 send-mailmessage -from "powershell@scripting.com" -to "some_user@domain.com" -subject "Script error" -body "Script error" -smtpserver "some_smtp_server.com"
}

function write-event {
 if(![System.Diagnostics.EventLog]::SourceExists("PowerShell_script")){
  [System.Diagnostics.EventLog]::CreateEventSource("PowerShell_script","Application")
 }
 Write-EventLog -LogName Application -Source PowerShell_script -EventId 999 -entrytype Error -Message "Script error"
}

try {
 your_powershell_commands
}
catch {
 send-email
 write-event
}
    In the try{...} section, you would include all your PowerShell commands in there.  You want to make sure everything outside of your try and catch sections are correct though.

     

    • Proposed as answer by Marco Shaw Sunday, October 24, 2010 11:15 PM
    • Unproposed as answer by Marco Shaw Monday, October 25, 2010 8:12 PM
    Sunday, October 24, 2010 11:15 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you Marco.  I've tried the code and I am receiving:

                The term 'try' is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.

    We are using powershell v1.0.  Is it supported/available at that version? 

    I may also be using your suggestion incorrectly.  I've put the $ErrorActionPreference="stop"  statement along with the functions between the $reason and the "Add-PSSnapin" statements.  I then enclosed the Add-PSSnapin all the way to the end of the New-MaintenanceWindow statement in the try {...}, followed by the catch {...} section you have above.

    Kate

    Monday, October 25, 2010 6:46 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you Marco.  I've tried the code and I am receiving:

                The term 'try' is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.

    We are using powershell v1.0.  Is it supported/available at that version? 

    I may also be using your suggestion incorrectly.  I've put the $ErrorActionPreference="stop"  statement along with the functions between the $reason and the "Add-PSSnapin" statements.  I then enclosed the Add-PSSnapin all the way to the end of the New-MaintenanceWindow statement in the try {...}, followed by the catch {...} section you have above.

    Kate

    Sorry!  When I saw "R2", I thought you meant Server 2008 R2...  Try is part of PowerShell v2, which is fully supported with SCOM 2007 R2.  Would you like me to provide you with a PowerShell v1 version of my script?  It won't be as "nice" since PowerShell v1 doesn't have some of the features I used in my sample code above.
    Monday, October 25, 2010 8:11 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I'm sorry,  I should have been more specific.  We are using Operations Manager 2007 R2 on a Windows Server 2008 x64 system with PowerShell v1.  We recently talked about going to PowerShell v2 - but haven't looked into it much.

    If you have time to provide a v1 version, that would be great.

    Thanks,

    Kate

     

     

    Monday, October 25, 2010 8:26 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    OK, here's v1:

    $ErrorActionPreference="stop"

function send-email {
 $smtp=New-Object System.Net.Mail.SMTPClient –ArgumentList some_smtp.server.com
 $smtp.Send('from@domain.com','to@domain.com','Script error','Script error')
}

function write-event {
 if(![System.Diagnostics.EventLog]::SourceExists("PowerShell_script")){
  [System.Diagnostics.EventLog]::CreateEventSource("PowerShell_script","Application")
 }
 [System.Diagnostics.EventLog]::WriteEntry("PowerShell_script","Script error","Error",999)
}

trap {
 send-email
 write-event
 continue
}

your_powershell_commands

    • Proposed as answer by Marco Shaw Friday, October 29, 2010 12:59 AM
    • Marked as answer by Vivian Xing Wednesday, November 3, 2010 2:22 AM
    Friday, October 29, 2010 12:51 AM