EmployeeType AD Attribute is an Invalid Filter syntax when creating New-DynamicDistributionGroup

Question

EmployeeType AD Attribute is an Invalid Filter syntax when creating New-DynamicDistributionGroup

RS84 6

Hi guys, on our Exchange Management Server, I have imported-module ActiveDirectory.. I am creating new DDL's.
I have successfully been able to create a new DDL with City as a filer, for example:

New-DynamicDistributionGroup -DisplayName allstaff.London -Name allstaff.London -Alias allstaff.London -RecipientContainer "localdomain.com/OU/EMEA" -RecipientFilter "(city -eq 'London')"

^ This works fine.

But I want to also create a new DDL this time using EmployeeType = Perm as a RecipientFilter.
This is what i'm doing:

New-DynamicDistributionGroup -DisplayName allstaff.Perm -Name allstaff.Perm -Alias allstaff.Perm -RecipientContainer "localdomain.com/OU/EMEA" -RecipientFilter "(EmployeeType -eq 'Perm')"

However, when I run this, I get the following error:

Cannot bind parameter 'RecipientFilter' to the target. Exception setting "RecipientFilter": "Invalid filter syntax. For a description of the filter parameter syntax see the command help.
"('employeetype' -eq 'Perm')" at position 2."

CategoryInfo : WriteError: (:) [New-DynamicDistributionGroup], ParameterBindingException
FullyQualifiedErrorId : ParameterBindingFailed,Microsoft.Exchange.Management.RecipientTasks.NewDynamicDistributionGroup
PSComputerName : servername.localdomain.com

I am running this in Exchange Mgmt Shell, and I have imported AD Module.

Joyce Shen - MSFT 16,701 Reputation points

2021-11-25T02:36:19.55+00:00

Hi @RS84

Agree with Andy, the EmployeeType is not included in Filterable recipient properties, you could consider using CustomAttribute to meet your requirement.

If an Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Joyce Shen - MSFT 16,701 Reputation points

2021-11-30T07:12:53.783+00:00

Hi @RS84

Any update so far? Have you succeed filtering the members using customattribute?

If an Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Alessandro Kornowski 15 Reputation points

2023-06-02T15:35:51.17+00:00

This is most perfect example of Minimum Viable Product. They create part of solution and forget that this atribute should be used to filter something. So the workaround is limited to forget the correct field because the solution was half implemented. Good job Microsoft! Any time frame to add this field to make it really usable?
Rich Matheisen 47,901 Reputation points

2023-06-02T19:12:49.1833333+00:00

I think that's a somewhat unfair criticism. The cmdlet deals with recipient objects, and not all recipient objects would have any reason to even have an employeeType property because their base class(es) may not include any object that has the property in their schema definition.

Why would, say, a distribution group (which is a recipient) have any reason to be classified as any type of employee?
Alessandro Kornowski 15 Reputation points

2023-06-02T19:17:13.0466667+00:00

To HR be able to send comunications to respective group, once Payroll will populate this proper field.
Gérémy Vernet 0 Reputation points

2023-06-27T10:14:16.7366667+00:00

Hi, is this statement still accurate ?

Because i'm facing same but didn't find ExtensionAttribute anymore, in on-prem AD, cloudExtensionAttribute instead.

Is it the same ?

Sorry for post's exhumation
Arthur Young 5 Reputation points

2025-04-08T19:19:10.8433333+00:00

This, sadly, is still not an option. My company has many employee types (FTEs, students, contractors, etc), and it would be nice to be able to make dynamic groups based on that without having to script it.

2 answers

Your answer

Joyce Shen - MSFT 16,701 Reputation points

2021-11-25T02:36:19.55+00:00

Hi @RS84

Agree with Andy, the EmployeeType is not included in Filterable recipient properties, you could consider using CustomAttribute to meet your requirement.

If an Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Joyce Shen - MSFT 16,701 Reputation points

2021-11-30T07:12:53.783+00:00

Hi @RS84

Any update so far? Have you succeed filtering the members using customattribute?

If an Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Alessandro Kornowski 15 Reputation points

2023-06-02T15:35:51.17+00:00

This is most perfect example of Minimum Viable Product. They create part of solution and forget that this atribute should be used to filter something. So the workaround is limited to forget the correct field because the solution was half implemented. Good job Microsoft! Any time frame to add this field to make it really usable?
Rich Matheisen 47,901 Reputation points

2023-06-02T19:12:49.1833333+00:00

I think that's a somewhat unfair criticism. The cmdlet deals with recipient objects, and not all recipient objects would have any reason to even have an employeeType property because their base class(es) may not include any object that has the property in their schema definition.

Why would, say, a distribution group (which is a recipient) have any reason to be classified as any type of employee?
Alessandro Kornowski 15 Reputation points

2023-06-02T19:17:13.0466667+00:00

To HR be able to send comunications to respective group, once Payroll will populate this proper field.
Gérémy Vernet 0 Reputation points

2023-06-27T10:14:16.7366667+00:00

Hi, is this statement still accurate ?

Because i'm facing same but didn't find ExtensionAttribute anymore, in on-prem AD, cloudExtensionAttribute instead.

Is it the same ?

Sorry for post's exhumation
Arthur Young 5 Reputation points

2025-04-08T19:19:10.8433333+00:00

This, sadly, is still not an option. My company has many employee types (FTEs, students, contractors, etc), and it would be nice to be able to make dynamic groups based on that without having to script it.

Answer 1

Andy David - MVP 157.8K MVP Volunteer Moderator

Thats not a valid filter:
https://learn.microsoft.com/en-us/powershell/exchange/recipientfilter-properties?view=exchange-ps

You'll have to use something else other than "EmployeeType"

Perhaps a custom attribute or group etc...

Answer 2

Hello RandeepSahota

The parameter supports an OPATH filter with limited filterable properties and comparison operators. According to the documentation, employeeType is not filterable with the OPATH filter.

As an alternative, you could have an automated or scripted process that updates an attribute that can be conditionally queried by the dynamic group. Here is an example of using the employeeType to update extensionAttribute1.

Get-AdUser -Filter "employeeType -eq 'Vendor'" |
Set-AdUser -Replace @{'extensionAttribute1' = 'Vendor'}
Then you can create a dynamic distribution group based on ConditionalCustomAttribute1, which maps to extensionAttribute1 in AD.

New-DynamicDistributionGroup -Name "Vendor Dynamic Group" -IncludedRecipients "MailboxUsers" -ConditionalCustomAttribute1 "Vendor"
Note that you can query for more than one value since -ConditionalCustomAttribute1 accepts an array. So you could pass -ConditionalCustomAttribute1 "Vendor","Contractor", which would look for the values Vendor or Contractor in extensionAttribute1.

--If the reply is helpful, please Upvote and Accept as answer--

Share via

EmployeeType AD Attribute is an Invalid Filter syntax when creating New-DynamicDistributionGroup

2 answers

Your answer