0

I've come across an issue I can't explain. When I use a variable in the below statement, I get incorrect data as my result. If instead I use the value the variable represents, then I get the expected data. The workaround is easy, but I'm curious as to what the problem is. I'd expect the string and the value the string represents to provide the same results.

I'm using Get-CSOnlineUser and filtering by StreetAddress. I assigned the address of Super Secret Address to a variable $location. When I use the variable name it returns the wrong results. When I use the value of the variable it returns the correct results

This code gives the wrong results:

#Returns a table of SFB Users filtered by location and whether or not they have enterprise voice

#Variables
$location = 'Super Secret Address'


#Get all enterprise voice users at specified address
Get-CsOnlineUser -Filter {StreetAddress -eq $location -and VoicePolicy -eq "BusinessVoice"} |ft DisplayName, Alias, Office, Phone, VoicePolicy, LineURI

#Get non-enterprise voice- users at specified address
Get-CsOnlineUser -Filter {StreetAddress -eq $location -and VoicePolicy -eq "HybridVoice"} |ft DisplayName, Alias, Office, Phone, VoicePolicy, LineURI

This gives the right results:

#Get all enterprise voice users at specified address
Get-CsOnlineUser -Filter {StreetAddress -eq 'Super Secret Address' -and VoicePolicy -eq "BusinessVoice"} |ft DisplayName, Alias, Office, Phone, VoicePolicy, LineURI

#Get non-enterprise voice- users at specified address
Get-CsOnlineUser -Filter {StreetAddress -eq 'Super Secret Address' -and VoicePolicy -eq "HybridVoice"} |ft DisplayName, Alias, Office, Phone, VoicePolicy, LineURI

Edit: Apologies. I should have clarified. The wrong results were showing a different subset of users that did not work at that StreetAddress. Interestingly, it seems like those users were contractors. Aside from that, I'm not seeing a pattern here.

In addition to the wrong subset of users, I saw this warning repeat itself within the results WARNING: "OriginalRegistrarPool" with identity "123456789" assigned to "sip:user@company.com" has been removed from configuration store.

Tim Natywa
  • 1
  • 2
  • In what way are the results wrong? – EBGreen Apr 10 '18 at 19:23
  • Apologies. I should have clarified. The wrong results were showing a different subset of users that **did not** work at that `StreetAddress`. Interestingly, it seems like those users were contractors. In addition to the wrong subset of users, I saw this warning repeat itself within the results `WARNING: "OriginalRegistrarPool" with identity "123456789" assigned to "sip:user@company.com" has been removed from configuration store.` – Tim Natywa Apr 10 '18 at 19:35
  • You should add this to the question by editing it. – EBGreen Apr 10 '18 at 19:48
  • I don't know what `Get-CsOnlineUser` is but I imagine the issue is the same as with `Get-AdUser` - the Filter parameter takes a string, not a scriptblock. When you put a variable there, the scriptblock is being cast to a string and the variable name stays literally as `$var` and on the server side, whatever it does - e.g. it's a `$null` value, or processed somehow - breaks the search constraints. Explained a lot more https://stackoverflow.com/a/44184818/478656 for Get-Aduser. – TessellatingHeckler Apr 10 '18 at 19:48
  • Do those wrong users have any value in their StreetAddress field? – EBGreen Apr 10 '18 at 19:49
  • @TessellatingHeckler the docs for `Get-CsOnlineUser` indicate that it ***does*** take a scriptblock for -Filter. Having said that, I think you may be on the right track. – EBGreen Apr 10 '18 at 19:50
  • 1
    @EBGreen I didn't realize it at the time but those users do not have a value in their StreetAddress field. This is becoming more clear to me. I think @TessellatingHeckler was correct in that it's looking for a `$null` – Tim Natywa Apr 10 '18 at 20:21

0 Answers0