Filterable properties for the RecipientFilter parameter on Exchange cmdlets

You use the RecipientFilter parameter to create OPATH filters based on the properties of recipient objects in Exchange Server 2016 or later, and Exchange Online. The RecipientFilter parameter is available in the following cmdlets:

• New-AddressList and Set-AddressList
• New-DynamicDistributionGroup and Set-DynamicDistributionGroup
• New-EmailAddressPolicy and Set-EmailAddressPolicy
• New-GlobalAddressList and Set-GlobalAddressList

The recipient properties that have been confirmed to work with the RecipientFilter parameter in all cmdlets are described in the following table.

Notes:

• The list might include:

  • Properties that are only used in one type of environment: Microsoft 365, on-premises Exchange, or hybrid. The property might exist on recipient objects in all environments, but the value is only meaningful (a value other than blank or None) in one type of environment.
  • Properties that are present, but correspond to features that are no longer used in Exchange.

• You can't use properties from other Active Directory schema extensions with the RecipientFilter parameter.

• Not all recipient properties have a corresponding Active Directory property. The LDAP display name value in the table is "n/a" for these properties, which indicates that the property is calculated (likely by Exchange).

• Enclose the whole OPATH filter in double quotation marks " ". If the filter contains system values (for example, $true, $false, or $null), use single quotation marks ' ' instead. Although this parameter is a string (not a system block), you can also use braces { }, but only if the filter doesn't contain variables. For more information, see Additional OPATH syntax information.

• You typically use the object's name for properties that require a valid object value (for example, a mailbox, a distribution group, or an email address policy, but the property might also accept the object's distinguished name (DN) or globally unique identifier (GUID). To find the object's DN or GUID, use the Get- cmdlet that corresponds to the object's type (for example, Get-EmailAddressPolicy | Format-List Name,DistinguishedName,GUID).

• Text string properties that accept wildcard characters require the -like operator (for example, "Property -like 'abc*'"). In Exchange Online PowerShell, you can't use the wildcard as a prefix in most parameters (for example, "Property -like '*abc'") isn't allowed).

  Tip

  Even if a wildcard prefix works in a filter parameter in Exchange Online PowerShell, we don't recommend using it due to low performance issues.

• The Value column in the table describes the acceptable values for the filter, not necessarily for the property itself. For example, a property might obviously contain a date or numeric value, but when you use that property in a filter, it might be treated like a text string (no value check, and wildcards are supported).

• To look for blank or non-blank property values, use the value $null (for example, 'Property -eq $null' or 'Property -ne $null').

• For filtering considerations for the nine exclusive Get-EXO* cmdlets in the Exchange Online PowerShell module, see Filters in the Exchange Online PowerShell module.

• In Exchange Online, you can't use a wildcard character (*) as the first character in the search string.

Exchange Server 2007 was the first version of Exchange that required OPATH filters instead of LDAP filters. For more information about converting LDAP filters to OPATH filters, see the Microsoft Exchange Team Blog article, Need help converting your LDAP filters to OPATH?.