As I mentioned, "In addition" :) If your ErrorAction is set implicitly to ignore, you won't even see an error...
> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Maglinger, Paul > Sent: Saturday, November 4, 2017 9:15 AM > To: [email protected] > Subject: Re: [Exchange] RE: Outlook rules errors > > But if it's a warning shouldn't I use WarningAction Stop? > > > On Nov 3, 2017, at 5:37 PM, Joseph L. Casale <[email protected]> > wrote: > > > > In addition to that, don't forget about what I said about always using > `ErrorAction Stop`. > > Without it, if your preference is set otherwise, there won't be anything to > catch. This > > touches on probably my first largest rant about the implementation that > just plain saddens me... > > > > For example, run the following and swap the ErrorActionPreference value: > > > > $ErrorActionPreference = 'SilentlyContinue' # 'Stop' > > > > try > > { > > gci 'x:\dontExist' > > } > > catch > > { > > write-host $_ > > } > > > > The first produces no output. > > > > hth, > > jlc > > > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Michael B. Smith > >> Sent: Friday, November 3, 2017 3:00 PM > >> To: [email protected] > >> Subject: [Exchange] RE: Outlook rules errors > >> > >> You have two hyphens in front of WarningAction instead of one. > >> > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Maglinger, Paul > >> Sent: Friday, November 3, 2017 4:50 PM > >> To: '[email protected]' > >> Subject: [Exchange] RE: Outlook rules errors > >> > >> Thanks Joseph. > >> I tried using the try/catch but not getting anywhere. I'm wondering if > >> it's > >> because it's not an error per se, but a warning. > >> The complete response I'm getting back is: > >> > >> "WARNING: The Inbox rule "[Apply to all messages]" contains errors. To > >> resolve the error, please edit the rule or re-create it." > >> > >> So I took your idea, did a little Googling and finally came up with this: > >> > >> try > >> { > >> foreach ($i in (Get-Mailbox -ResultSize unlimited)) {Get-InboxRule - > Mailbox > >> $i.DistinguishedName --WarningAction Stop} > >> } > >> catch > >> { > >> Write-Host ('{0} has an error.' -f $_.Identity) > >> } > >> > >> But when I run it I get this: > >> > >> A positional parameter cannot be found that accepts argument 'Stop'. > >> + CategoryInfo : InvalidArgument: (:) [Get-InboxRule], > >> ParameterBindingException > >> + FullyQualifiedErrorId : PositionalParameterNotFound,Get-InboxRule > >> > >> From what I've read WarningAction uses the same options as ErrorAction. > >> > >> Paul > >> > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Joseph L. Casale > >> Sent: Wednesday, November 01, 2017 3:31 PM > >> To: '[email protected]' <[email protected]> > >> Subject: [Exchange] RE: Outlook rules errors > >> > >> Sorry, > >> I am 100% confident on this one. The indeterminate behavior results from > >> myriad of error handling practices possible. The default preference and its > >> implicit behavior, all pet peeves of mine. > >> > >> When writing a binary cmdlet, you can opt to throw an error which can be > >> terminating if desired (by invoking the cmdlet with -ErrorActoin Stop) or > you > >> can throw a terminating error you can't catch. > >> > >> When processing in a pipeline, I assure you the data is processed record > by > >> record as it is retrieved, trust me. > >> > >> If you **don't** want the pipeline to terminate, then state so: > >> > >> get-Mailbox ... -ErrorAction SilentlyContinue | Some-OtherCmdlet ... > >> > >> However, using try catch in the pipeline is possible, the syntax is just > >> awful > to > >> look at. > >> For example: > >> > >> Get-ChildItem c:\ |%{ > >> Write-Host $_.FullName > >> try > >> { > >> throw 'Some error' > >> } > >> catch > >> { > >> Write-Host ('Caught an error: {0}, but continuing anyway...' -f > >> $_.Exception.Message) -ForegroundColor Red > >> } > >> > >> $_ > >> } |%{ > >> Write-Host ('And here we are again: {0}...' -f $_.FullName) - > >> ForegroundColor Green } > >> > >> Back to my point about the pipeline and accumulation, since I know you > also > >> develop, you are familiar with what some language's call generators or > >> iterators (think c# yield return). > >> > >> Type the following: > >> Get-ChildItem c:\ -Force -Recurse -ErrorAction SilentlyContinue You > >> see results immediately and they stream consecutively until finished. > >> > >> Now try this: > >> foreach ($i in (Get-ChildItem c:\ -Force -Recurse -ErrorAction > >> SilentlyContinue)) > >> { > >> $i > >> } > >> Notice the long wait before the first result? > >> > >> Hth, > >> jlc > >> > >>> -----Original Message----- > >>> From: [email protected] > >>> [mailto:[email protected]] On Behalf Of Michael B. Smith > >>> Sent: Wednesday, November 1, 2017 1:46 PM > >>> To: [email protected] > >>> Subject: [Exchange] RE: Outlook rules errors > >>> > >>> I gotta jump in here: > >>> > >>>>> By invoking Get-Mailbox outside the pipeline the way you are, all > >>>>> the > >>> objects are > >>>>> accumulated in memory, then fed to the body one at a time. > >>>>> That doesn't scale in large environments, but if this runs already > >>>>> you are > >>> obviously ok. > >>> > >>> In my experience, exactly the opposite is true. > >>> > >>> For example, if you've got 50,000 mailboxes and you are trying to use > >>> a pipeline with them, my experience says that exactly zero percent of > >>> the time will that pipeline complete without an error. > >>> > >>> 100% of the time you'll get "steppable pipeline already in use" or a > >>> similar error indicating that there were buffer collisions. > >>> > >>> P.S. - Another way to handle the OP's issue is with redirecting the > >>> warning stream. > >>> > >>> > https://blogs.technet.microsoft.com/heyscriptingguy/2014/03/30/underst > >>> an ding-streams-redirection-and-write-host-in-powershell/ > >>> > >>> -----Original Message----- > >>> From: [email protected] > >>> [mailto:[email protected]] On Behalf Of Joseph L. Casale > >>> Sent: Wednesday, November 1, 2017 3:30 PM > >>> To: '[email protected]' > >>> Subject: [Exchange] RE: Outlook rules errors > >>> > >>> Sure, > >>> $i references a mailbox. That has the offending owner of the invalid rule. > >>> > >>> Here is a rule I require all code I work with to follow, otherwise it > >>> gets filed in > >>> G:) > >>> Always use `Set-StrictMode -Version Latest` For every cmdlet that > >>> exposes it, use the -ErrorLevel parameter and either try/catch it or > >>> ignore it (for the rare cases that might make sense). > >>> > >>> So in your case, wrap the body in a try catch and report the offender, > >>> for > >>> example: > >>> try > >>> { > >>> Get-InboxRule... -ErrorAction Stop } catch { > >>> Write-Host ('{0} has an error.' -f $_.Identity) } > >>> > >>> A note about pipelines, while writing programs with a pipeline is > >>> programmatically gruesome, you can rationalize it in some cases with > >>> Powershell. > >>> By invoking Get-Mailbox outside the pipeline the way you are, all the > >>> objects are accumulated in memory, then fed to the body one at a time. > >>> That doesn't scale in large environments, but if this runs already you > >>> are obviously ok. > >>> > >>> hth, > >>> jlc > >>> > >>>> -----Original Message----- > >>>> From: [email protected] > >>>> [mailto:[email protected]] On Behalf Of Maglinger, Paul > >>>> Sent: Wednesday, November 1, 2017 1:04 PM > >>>> To: [email protected] > >>>> Subject: [Exchange] Outlook rules errors > >>>> > >>>> I'm using the following Powershell script to search for users that > >>>> are using rules to either forward or redirect email outside of the > >> company: > >>>> # foreach ($i in (Get-Mailbox -ResultSize unlimited)) {Get-InboxRule > >>>> - Mailbox $i.DistinguishedName | where {$_.ForwardTo} | fl > >>>> MailboxOwnerID,Name,ForwardTo >> C:\downloads\ForwardRules.txt > } > >>>> > >>>> While it runs this script I get a lot of warnings of "The Inbox rule > >>>> "Blahblahblah" contains errors. To resolve the error, please edit > >>>> the rule or re-create it." > >>>> > >>>> Very informative. not. I have no idea which mailbox to look at. Is > >>>> there a way to refine the script, or is there another script that > >>>> can be run that will > >>> tell > >>>> me who has rules that have problems? > >>>> > >>>> Everything that I've found online talks about going into Outlook. I > >>>> haven't found anything using PowerShell. > >>>> > >>>> Thanks! > >>>> > >>>> Paul > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> > >> > >> > > > > > > >
