Transforming the Active Directory Cmdlets: Part 4

Transforming the Active Directory Cmdlets: Part 4

  • Comments 2
  • Likes

Summary: Learn how to translate between ADSI, Quest, and Windows PowerShell cmdlets to read additional user properties.

Hey, Scripting Guy! Question Hey, Scripting Guy!

I'm trying figure something out. I can get some properties with the Quest cmdlets without even asking, but when I go to use the Windows PowerShell cmdlets, they aren't there. How can I get these properties from the system?

—RM

Hey, Scripting Guy! Answer Hello RM,

Honorary Scripting Guy, Sean Kearney, here. Today you can peek in as I guide my old buddy, Kevin, through converting some of his newer Windows PowerShell goodies for Active Directory to some older things.

Note This is the fourth post in a series. For more, see:

Kevin is being asked to audit his company's Active Directory to ensure key properties are populated in all of the user objects. A new application is being brought online to introduce a standard signature in the emails for all staff.

"The problem I've noted," as Kevin states while targeting his head for the shiny spot on the desk, "is that some of the staff are missing the email address and the standard website in their signatures. Although this is fine for a generic address, it's not so good for managers."

I smiled, "So just run a Get-QADUser on them and..."

"I found that the Get-QADUser cmdlet will work fine, but against our 150,000 user Active Directory, it was far too slow. So to test it out, this worked:

$UserInfo=GET-Qaduser Valentine-Michael.Sm

$WebSite=$UserInfo.Webpage

$Email=$Userinfo.Email

"I found that I can pull the properties and write a script around that, but it's very slow—mostly because it pulls a lot of extra information that I don't need. But when I run the same query with the Microsoft version, the date wasn't there. I checked by piping it through Get-Member:

GET-ADUser Valentine-Michael.Sm | GET-Member

Image of command output

"I found that this worked, but it gave me everything, which was again way too slow when working with tens of thousands of users:"

GET-ADUser Valentine-Michael.Sm –properties *

Smiling like a Cheshire Cat, I looked at Kevin, "Too easy, my friend. Let's find the properties that match what you're looking for and specify only them. We can do this with Get-Member, and a little 'wildcarding'."

GET-ADUser Valentine-Michael.Sm –properties * | GET-Member –name *email*

Image of command output

But a few minutes later, he came back. "OK, it worked. But I still can't find the website. I tried both of the following commands...and nothing."

GET-ADUser Valentine-Michael.Sm –properties * | GET-Member –name *web*

GET-ADUser Valentine-Michael.Sm –properties * | GET-Member –name *www*

So I showed Kevin a trick I learned a long time ago. Populate the value with something unique via Active Directory Users and Computers. Then pull all properties and look for that unique value.

GET-Aduser Valentine-Michael.Sm –properties *

In moments, we visually spotted the name as being "Homepage."

Kevin continued, "I remember from Quest that if I want to access multiple properties, I could do it like this:

GET-Qaduser Valentine-Michael.Sm –IncludedProperties MaxStorage,OtherPhone

"I'm guessing that if I type it as follows with the –Properties parameter, I'll get the additional ones I want. I would think they should have a similar format for a list of items."

GET-ADUser Valentine-Michael.Sm –properties OfficeEmail,Homepage

He looked at the screen and found all the details appearing in front of him:

Kevin mused for a moment, "I'll bet these are the same names used by the [ADSI] accelerator because they're using the actual names I would see in the ADSI Editor too. Just for fun, let me try something."

Kevin quickly typed the same query by using the [ADSI] accelerator:

$Name='CN=Valentine-Michael Smith'                                   

$Parent='OU=Grok,DC=Contoso,DC=Local'

$Class="user"

$Connection=[ADSI]"LDAP://$Parent"

$GetUser=$Connection.invokeget($Class, $Name)

$WebSite=$GetUser.InvokeGet("Homepage")

$Email=$GetUser.InvokeGet("EmailAddress")

"AhHa!" he jumped on top of the desk after checking the values, "It works!"

Of course, after his great leap onto the desk, quite a few doors opened to see what happened and why a senior systems analyst would be dancing on his cubicle.

Pop in to tomorrow as we wrap up converting between the Active Directory methods in Windows PowerShell. And maybe settle Kevin down a bit. ;)

I invite you to follow The Scripting Guys on Twitter and Facebook. If you have any questions, send an email to The Scripting Guys at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then remember eat your cmdlets each and every day with a dash of creativity.

Sean Kearney, Windows PowerShell MVP and Honorary Scripting Guy 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment