Hiding Errors When Using Get-ADGroup Hiding Errors When Using Get-ADGroup powershell powershell

Hiding Errors When Using Get-ADGroup


I find that this works best:

$Group = Get-ADGroup -Filter {SamAccountName -eq $GroupName}

If the filter returns no results, then $Group is simply set to $null and no error message is generated. Also, since a SAM account name must be unique in Active Directory, there is no risk of $Group being set to an array of more than one object.

I find that using -Filter to get the group rather than -Identity works really well when checking for the existence of groups (or users) in If statements. For example:

If (Get-ADGroup -Filter {SamAccountName -eq $GroupName}){    Add-ADGroupMember -Identity $GroupName -Members $ListOfUserSamAccountNames}Else{    Write-Warning "Users could not be added to $GroupName because $GroupName    does not exist in Active Directory."}

I find that is a lot easier to deal with logically (if the group exists, add the users; if not, display a message) than mjolinor's suggestion of try/catch with using the Get-ADGroup cmdlet with the -Identity parameter. Consider the try/catch method of doing the same as above, using the -Identity parameter:

Try{    Get-ADGroup -Identity $GroupName    Add-ADGroupMember -Identity $GroupName -Members $ListOfUserSamAccountNames}Catch{    Write-Warning "Users could not be added to $GroupName because $GroupName    does not exist in Active Directory."}

You see if any of the commands in the try block throws a terminating error. If one does, it means the group doesn't exist and will move on and process the command(s) in the catch block. It will work, but I don't think try/catch here flows as well, logically, in comparison to if/else.

Don't get me wrong, mjolinor is a PowerShell genius. It's just that in this case I don't think his solution is the best one.


 try {get-adgroup <groupname>}  catch  {      <make new group>     }


@mjolinor gives the good answer, but I think some explanation can also help.

Windows PowerShell provides two mechanisms for reporting errors: one mechanism for terminating errors and another mechanism for non-terminating errors.

Internal CmdLets code can call a ThrowTerminatingError method when an error occurs that does not or should not allow the cmdlet to continue to process its input objects. The script writter can them use exception to catch these error.

Internal CmdLets code can call a WriteError method to report non-terminating errors when the cmdlet can continue processing the input objects. The script writer can then use -ErrorAction option to hide the messages.