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