Error not caught with try\catch

When this user is not found an error is generated, shown below, but the catch block is not triggered. Any ideas?

Try{
Remove-DistributionGroupMember -Identity GroupA -member UserA@domain.com -ErrorAction stop
} Catch{Get-Date}

$? shows False

Error thrown, and $error[0] shows:

writeErrorStream : True
PSMessageDetails :
OriginInfo : Server1
Exception : System.Management.Automation.RemoteException: The operation couldn’t be performed because object ‘GroupA’ couldn’t be found on
'serverA.
TargetObject : 0
CategoryInfo : NotSpecified: (0:Int32) [Remove-DistributionGroupMember], ManagementObjectNotFoundException
FullyQualifiedErrorId : EAE3533F,Microsoft.Exchange.Management.RecipientTasks.RemoveDistributionGroupMember
ErrorDetails :
InvocationInfo :
ScriptStackTrace :
PipelineIterationInfo : {}

Hi Matt,
can you try this

Try{
Remove-DistributionGroupMember -Identity GroupA -member UserA@domain.com -ErrorAction stop
}#try 
Catch{
$ErrorMessage = $_.Exception.Message
$ErrorMessage 
}#catch

Regards
Shihan

From my experience, the exchange modules all work remotely.
remote errors aren’t catchable.

my only work-around thusfar has been to do a validation check after i execute the exchange cmdlet
ie if i’m adding a group member, i then retrieve the members of the group and validate my user is now added

This works for me (found it on the web)

Try{
$OldErrorActionPref = $ErrorActionPreference; $ErrorActionPreference = "Stop" # goes inside the try
Remove-DistributionGroupMember -Identity GroupA -member UserA@domain.com -ErrorAction stop
}#try 
Catch{
$ErrorMessage = $_.Exception.Message
$ErrorMessage 
}#catch
$ErrorActionPreference = $OldErrorActionPref  # goes after the catch

Thank you. This is very helpful. It catches the error when the $ErrorActionPreference is set to stop, but not when using -ErrorAction stop on the cmdlet. I don’t like doing that, it seems clumsy, but it works. This is running in a schedule task connecting to exchange within the script using New-PSSession, implicit remoting.

Error details when caught:

Exception : System.Management.Automation.RemoteException: Couldn’t find object “UserA@domain.com”. Please make sure that it was spelled correctly or specify a different
object.
CategoryInfo : NotSpecified: (0:Int32) [Remove-DistributionGroupMember], ManagementObjectNotFoundException
FullyQualifiedErrorId : 8320188C,Microsoft.Exchange.Management.RecipientTasks.RemoveDistributionGroupMember

When I use open the Ems (use …RemoteExchange.ps1’; Connect-ExchangeServer …), explicit connection, the error is caught with -erroraction stop . I wanted to avoid doing that so there wasn’t a dependency on having the Exchange tools loaded. The error detail all looks the same except for the FullyQualifiedErrorId number. It appears the difference is implicit versus explicit connections. Testing using the “Enter-PSSession cmdlet to start an interactive session”, errors with “The Try statement is not allowed in restricted language mode or a Data section.”

It looks like another option is to not use the try\catch and then do an If statement based on $?. Something like:

If($? -eq "false"){"$error[0]  | out-file C:\log.txt"}

Thank you. This is very helpful. It catches the error when the $ErrorActionPreference is set to stop, but not when using -ErrorAction stop on the cmdlet. I don’t like doing that, it seems clumsy, but it works. This is running in a schedule task connecting to exchange within the script using New-PSSession, implicit remoting.

Error details when caught:

Exception : System.Management.Automation.RemoteException: Couldn’t find object “UserA@domain.com”. Please make sure that it was spelled correctly or specify a different
object.
CategoryInfo : NotSpecified: (0:Int32) [Remove-DistributionGroupMember], ManagementObjectNotFoundException
FullyQualifiedErrorId : 8320188C,Microsoft.Exchange.Management.RecipientTasks.RemoveDistributionGroupMember

When I use open the Ems (use …RemoteExchange.ps1’; Connect-ExchangeServer …), explicit connection, the error is caught with -erroraction stop . I wanted to avoid doing that so there wasn’t a dependency on having the Exchange tools loaded. The error detail all looks the same except for the FullyQualifiedErrorId number. It appears the difference is implicit versus explicit connections. Testing using the “Enter-PSSession cmdlet to start an interactive session”, errors with “The Try statement is not allowed in restricted language mode or a Data section.”

Here’s another option that I like also. Rather than use the try\catch, do an If statement based on $?. Something like:

If($?){"$error[0]  | out-file C:\log.txt"}