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