none
Are only certain categories of errors stored when specifying the -errorvariable parameter? RRS feed

  • Question

  • I have a script that I have noticed captures some errors and not others.

    When this command fails, the results are correctly stored in my error variable:

    get-msoluser -userprincipalname user@upn.com -errorvariable myerr

    When this command fails, my error variable is still blank:

    enable-remotemailbox user@upn.com -errorvariable myerr

    However, I can see the error from both commands by running $error

    The category of the error from get-msoluser is "OperationStopped", while the category of the error from enable-remotemailbox is "1000" and has a reason of "ManagementObjectAmbiguousException" whereas the other has a reason of "MicrosoftOnlineException"

    Is the variation in the error category the reason why the error from enable-remotemailbox is not stored in my errorvariable? If not, what is the reason? 


    • Edited by JasonBeckett Thursday, December 31, 2015 8:22 PM corrected typo
    Thursday, December 31, 2015 8:21 PM

Answers

  • Yes, you can trap the error. See the help topic:


    C:\> help about_Try_Catch_Finally


    -- Bill Stewart [Bill_Stewart]

    • Marked as answer by JasonBeckett Tuesday, January 5, 2016 11:21 PM
    Tuesday, January 5, 2016 10:50 PM
    Moderator

All replies

  • http://blogs.msdn.com/b/kebab/archive/2013/06/09/an-introduction-to-error-handling-in-powershell.aspx

    https://technet.microsoft.com/en-us/library/dd878319%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

    Likely the UPN resolves to more than one recipient or to no recipient.  I suspect that this amounts to an invalid set of parameters or an invalid call context.


    \_(ツ)_/

    Friday, January 1, 2016 6:42 AM
  • So I know why the command fails. That isn't my question. 

    I am asking why the error doesn't store in my error variable. 

    Saturday, January 2, 2016 12:01 AM
  • If the command doesn't even start running, PowerShell will throw an error before it evaluates the -ErrorVariable parameter.

    -- Bill Stewart [Bill_Stewart]

    Tuesday, January 5, 2016 6:52 PM
    Moderator
  • Thank you for the reply but that isn't my scenario. As I showed in my original post the command does in fact start running and the error returned is an exchange error. I'll post the full error for reference. 
    Tuesday, January 5, 2016 8:23 PM
  • Ambiguous means just that.  The supplied parameters cannot be resolved so the CmdLet is never executed as Bill has noted.  Fix the parameters.


    \_(ツ)_/

    Tuesday, January 5, 2016 8:28 PM
  • If my parameters were wrong, wouldn't the cmdlet fail every time? it doesn't fail every time, it only fails for this error (copied below). 

    The operation couldn't be performed because 'samaccountname@domain.com' matches multiple entries.
        + CategoryInfo          : NotSpecified: (:) [Enable-RemoteMailbox], ManagementObjectAmbiguousException
        + FullyQualifiedErrorId : [Server=PHSI-MSX-06,RequestId=23cf9776-cf71-4804-9df4-8d0c9335cc52,TimeStamp=1/5/2016 10:06:11 PM] [FailureCategory=Cmdlet-ManagementObjectAmbiguousException] 1CB79B6B,Microso 
       ft.Exchange.Management.RecipientTasks.EnableRemoteMailbox
        + PSComputerName        : server.local

    And if I run $error[0]

    I get the same above output. It's just not stored in my error variable which I'm using to write to my log file. 


    Tuesday, January 5, 2016 10:09 PM
  • Please try to read the actual error.  It tells you exactly what the issue is:

    The operation couldn't be performed because 'samaccountname@domain.com' matches multiple entries.

    The CmdLet could not execute because it could not resolve the identity.  Of course you have changed the code or changed somerhing now so you are getting a different issue.


    \_(ツ)_/

    Tuesday, January 5, 2016 10:20 PM
  • As noted, PowerShell is throwing the error before it evaluates the -ErrorVariable parameter.

    In any case, I'm not sure the "why" is too helpful, is it, since it doesn't work the way you expect? You will have to work around the problem.


    -- Bill Stewart [Bill_Stewart]

    Tuesday, January 5, 2016 10:20 PM
    Moderator
  • In that case do I need a try-catch-finally to get the error stored to a variable? Is there another method you would suggest?
    Tuesday, January 5, 2016 10:29 PM
  • Yes, you can trap the error. See the help topic:


    C:\> help about_Try_Catch_Finally


    -- Bill Stewart [Bill_Stewart]

    • Marked as answer by JasonBeckett Tuesday, January 5, 2016 11:21 PM
    Tuesday, January 5, 2016 10:50 PM
    Moderator