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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>
>
