Loose or exact matching in AD cmdlets

Do you know what is the difference between Get-QADComputer A2101 and Get-QADComputer -Name A2101?

When we were designing Quest AD cmdlets we did our best to be as forgiving as possible. So for example you can just do Get-QADUser and get the first 1000 user objects (or whatever is the default number you set) retrieved. Or you can just do a Get-QADUser Dmitry and get all the Dmitry’s you have in your organizations (if you have any :))

In most cases, this forgiving nature is what you are in the command-line interactively managing your Active Directory. If you have ever tried using some other snapins/modules from other vendors who went a different route – you should have noticed how much difference this makes.

However, sometimes you do want to be explicit and just get the exact object you want and not just whatever matches. In this forum thread Jason was trying to update a set of computer records based on a CSV file he was importing.

Unfortunately for him, some of computer names in his environment include other names. E.g. he not only has a computer called ‘A2101’, but also ‘A21012’ and ‘A21013’.

Which means that Get-QADComputer A2101 returns all three of those:

Jason obviously did not need the other two computers and explicitly wanted to update just the one which matches exaqctly.

Luckily the workaround is very simple. If you know what you need – be explicit when you are asking for it. For example, if the you are identifying the computer by its Name – just tell us so and if no wildcards are used we will only retrieve the exact match:

Get-QADComputer -Name A2101 only returns one computer record with Name being A2101.

Happy scripting!

12 Responses to “Loose or exact matching in AD cmdlets”

  1. 1 Ben Wilkinson April 13, 2011 at 11:13 pm

    Nice, awesome little article, very useful.

    I have run into that before, however I believe I ended up using some kind of filter and a pipeline to achieve the end result, which was the single item.

    Are you actually saying the -Identity parameter will wildcard, however the -Name parameter will not?

    • 2 Dmitry Sotnikov April 13, 2011 at 11:20 pm


      Identity parameter is effectively trying to match any substring across a variety of attributes (Name, samAccountName, DN – see help and user’s guide for the full list).

      Any other parameter is doing exact search unless you use wildcards.


  2. 3 Jacques April 15, 2011 at 10:08 pm

    Thank you Dmitry,
    If I had known things could be so simple……..
    Long ago in our company someone set a standard for file authorisation groups, the names should end in _r or _rw, for Read or ReadWrite respectively.
    I have constructed so many workarounds in somany scripts to get only the Read groups when I needed , stayed a pain in the neck. And now you tell me, so simple…


  3. 4 Jason Crider April 19, 2011 at 5:15 pm

    Good info on what was really causing me trouble. My blog post on the topic just went online (added referrences to here)


  4. 5 Marco Shaw April 21, 2011 at 3:06 pm

    Yes, classic example of being very careful when doing system changes. I was deleting accounts using Get-QADUser, and not explicitly defining to match on -Sam or similar and ended up deleting accounts I should not have.

    • 6 Dmitry Sotnikov April 21, 2011 at 6:03 pm

      Sorry to hear that, Marco… Yes, deletes with loose matching, without -whatif first, and without conforming each delete are a dangerous thing…

  5. 7 Thomas Keller February 7, 2012 at 5:07 pm

    Is there another way to do “exact matching” with the -identity parameter, as Set-QADUser does not support the -name parameter?

    According to the manual page I could also use -identity “domain\username” but that throws the error: Cannot resolve directory object for the given identity: ‘domain\username’. Same problem if I use -identity “username@domain”

    Anyone aware of a work around, except using using SID or GUID with the -identity parameter?

    Thanks for any suggestion.

  6. 8 Thomas Keller February 7, 2012 at 6:09 pm

    Found a possible solution by retrieving the user with “Get-QADUser” (which supports the -name parameter) and piping it into Set-QADUser. For example:

    Get-QADUser -name username | Set-Qaduser -UserPassword secret -UserMustChangePassword $true

  7. 9 zarberg July 23, 2013 at 7:34 pm

    Say I was trying to list all computers that did not have a server operating system, my base command would be “Get-QADComputer -SearchRoot ‘domain/OU you want to search’| select-object name,operatingsystem”

    How would I filter that to not show machines with include *server* in their operatingsystem?


    • 10 Dmitry Sotnikov July 24, 2013 at 7:25 am

      Get-QADComputer has OSName parameter which accepts wildcards – see if you can come up with the proper wildcard for what you need: http://wiki.powergui.org/index.php/Get-QADComputer

      You can also make a few separate calls and just join the results with +.

      • 11 zarberg July 24, 2013 at 1:42 pm

        I actually ended up doing this:

        Get-QADComputer -SearchRoot ‘contoso.com/’ -OSName *windows* | where{$_.operatingSystem -notlike “*Server*”} | select-object name,operatingsystem

      • 12 Dmitry Sotnikov July 24, 2013 at 1:57 pm

        That is fine. The downside is that a lot of filtering is being done on the client side (where{} only works after the set has been downloaded) so can be inefficient on large data samples. If performance is fine – I’m glad that this works for you.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

My Recent Tweets


The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

April 2011
« Mar   May »

%d bloggers like this: