Get-ADUser Attribute that is set to not set

Question

_{Wednesday, July 31, 2019 2:39 PM}

Hi,

I want to produce a list of users who have their msRTCSIP-UserEnabled AD attribute set to True and their msRTCSIP-PrimaryUserAddress attribute set to Not Set. I can bring back results for when the msRTCSIP-PrimaryUserAddress is set to a value, but when it is not I cannot get the below script to work.

I can see when I run the Get-ADUser -Identity samaccountname -Properties * for a user who does not have this attribute set it doesn't bring this attribute at all in the properties list.

I have tried different variations of  -EQ "Null"} without success.

Import-Csv C:\Users\username\Desktop\queryadusers.csv |

ForEach-Object {
 Get-ADUser -Identity $_.SamAccountName -Properties * | where {$_."msRTCSIP-UserEnabled" -EQ "True" -and $_.'msRTCSIP-PrimaryUserAddress' -EQ "Null"}
 } | Select-Object -Property Displayname

All replies (3)

_{Wednesday, July 31, 2019 3:07 PM ✅Answered}

Hi,

I am unable to test now, but can you please try the following:

Get-ADUser -Identity $_.SamAccountName -Properties * | where {($_."msRTCSIP-UserEnabled" -EQ "True") -and ($_.'msRTCSIP-PrimaryUserAddress' -EQ $null)}

If your oject, coming from the csv is properly formated, this should definetely work.

Regards,

(Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!) Blog: https://blog.pohn.ch/ Twitter: @StoyanChalakov

_{Wednesday, July 31, 2019 3:18 PM}

That worked thank and also the below worked. Obviously, wrapping the $null in quotations marks affected the results, as I had tried "$Null" with my original script as well. Out of interest why would putting quotation marks around $null in this instance affect the results Stoyan?

Import-Csv C:\Users\usrname\Desktop\queryadusers.csv |

ForEach-Object {
 Get-ADUser -Identity $_.SamAccountName -Properties * | where {$_."msRTCSIP-UserEnabled" -EQ "True" -and $_.'msRTCSIP-PrimaryUserAddress' -EQ $null}
 } | Select-Object -Property Displayname

_{Wednesday, July 31, 2019 4:10 PM}

Powershell accepts the designation of a literal string in 2 ways:  wrapped with "double quotes", or wrapped with 'single quotes'.

When a string is wrapped with 'single quotes', the string is treated as an absolute literal.  all text contained by the quotes is left as is.  If a quote exists in the middle of that string, it needs to be doubled in order to not confuse the parser.

When a string is wrapped with "double quotes", the string is parsed and any powershell variables, escape codes, or special characters are processed first before returning the final string.  This is very valuable for producing dynamically resolved string values.

Example:

$var = 'this text has a $dollar sign.'
This $var will have exactly what is between the quotes, including the dollar sign and the slashes.

however...

$var = "this text has a $dollar sign."
This time, $var will treat $dollar as a variable name and replace it with the contents of the variable, if any.  and if $dollar is undeclared, empty, or null, will simply return an empty string.
The final string, if $dollar was never really a variable in the first place would be:
> this text has sign.

This is very handing for string concatenation scenarios...

While this works:
$var = "Part 1 " + $varname + " Part 2"

This is usually easier and easier to read:
$var = "Part 1 $varname Part 2"

One quirk with this feature is when you want to get the property value of an object.

Consider an object variable, $user, that has a Name property...

This will not produce the expected result:
$var = "Hello $user.Name"
The powershell will try to convert the entire $user object to a string, then append .Name to that text.

For such cases you have to wrap it with a directive...

$var = "Hello $($user.name)"

The $() sequence tells the powershell parser to "convert this to a string first".

-Eriq VanBibber, CTO, Priasoft Inc.