Get-AdUser's Filter Parameter; Guidelines on curly braces vs string.

[JohnLBevan]

The Filter parameter accepts an argument of type string; but can also take a filter formatted between curly braces like a script block.

Examples show both formats, and there's a helpful description of the differences around quoting variables when interpolating in a string filter vs providing within curly braces: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduser?view=windowsserver2022-ps#-filter

However, there's no guidance on when to use which approach. Is this pure personal preference, or are there considerations?
i.e. Does using curly braces mean that you're protected from issues around character escaping / date format issues / etc?
Conversley what are the benefits of using strings; e.g. simpler to understand espacially when creating string filters or working with fixed values)?

There's some great info in this SO Answer; but this focusses primarily on string interpolation vs leaving variable references within strings, with just a side note on the "scriptblock" approach.

Additionally, is it best to use variable references vs resolving those variables to values?

Example scenarios:

The below examples help clarify the benefits of some approaches vs others; but there's little apparant difference between the single quotes vs curly braces approaches.

$name = "Chris O'Dowd"
Get-AdUser -Filter 'Name -eq $name' #automatically handles the character escaping
Get-AdUser -Filter {Name -eq $name} #automatically handles the character escaping
# Get-AdUser -Filter "Name -eq $name" # would error as this is invalid syntax
# Get-AdUser -Filter "Name -eq '$name'" # would error as the value is not escaped
Get-AdUser -Filter "Name -eq '$($name -replace '''', '''''')'" #we have to escape the offending quote; so this is inferior

$when = [DateTime]'2022-01-12' # on a US system this would be 01/12/2022; on most EU systems this would be 12/01/2022
Get-AdUser -Filter 'Created -ge $when' # automatically compares dates as expected
Get-AdUser -Filter {Created -ge $when} # automatically compares dates as expected
# Get-AdUser -Filter "Created -ge $when" # would error as invalid syntax
Get-AdUser -Filter "Created -ge '$when'" # unpredictable; could give you all users created after 12th Jan, or could give you all after 1st Dec.
Get-AdUser -Filter ("Created -ge '{0:yyyy-MM-dd}'" -f $when) # formats the date in a less ambiguous way... but theoretically could be misinterpreted if anyone uses the yyyy-dd-MM format.

# also interesting - this gives visibility of what's being sent as the filter ... but the date format may be different in the string interpolation vs when the date's output directly!
write-verbose "Created -ge '$when'" -Verbose
write-verbose $when -Verbose

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: 3f224958-1e01-e762-a552-6116c76a04e7
• Version Independent ID: b013a1e2-5879-5924-9dbd-a8db54885d10
• Content: Get-ADUser (ActiveDirectory)
• Content Source: docset/winserver2022-ps/activedirectory/Get-ADUser.md
• Product: w10
• Technology: windows
• GitHub Login: @JasonGerend
• Microsoft Alias: jgerend

[officedocspr5]

To make it easier for you to submit feedback on articles on learn.microsoft.com, we're transitioning our feedback system from GitHub Issues to a new experience.

As part of the transition, this GitHub Issue will be moved to a private repository. We're moving Issues to another repository so we can continue working on Issues that were open at the time of the transition. When this Issue is moved, you'll no longer be able to access it.

If you want to provide additional information before this Issue is moved, please update this Issue before December 15th, 2023.

With the new experience, you no longer need to sign in to GitHub to enter and submit your feedback. Instead, you can choose directly on each article's page whether the article was helpful. Then you can then choose one or more reasons for your feedback and optionally provide additional context before you select Submit.

Here's what the new experience looks like.

Note: The new experience is being rolled out across learn.microsoft.com in phases. If you don't see the new experience on an article, please check back later.

First, select whether the article was helpful:

Then, choose at least one reason for your feedback and optionally provide additional details about your feedback:

Article was helpful	Article was unhelpful

Finally, select Submit and you're done!