Hey, Scripting Guy! Quick-Hits Friday: The Scripting Guys Respond to a Bunch of Questions (11/6/09)


Bookmark and ShareIn this post:


Using the Active Directory DirectoryEntry Class

Hey, Scripting Guy! Question

Hey, Scripting Guy! I have been writing some scripts for Active Directory, and this past weekend I ran into something that puzzled me. When a search is performed against Active Directory (using the DirectoryEntry class and searcher class), and when the GetDirectoryEntry method is called against the returned SearchResult objects, the members of the newly returned DirectoryEntry objects do not match the members listed on MSDN at all (for the .NET class).

Why is that? The Windows PowerShell GetDirectoryEntry method seems to have bound directly to the Active Directory object, whereas the MSDN documentation speaks of returning a DirectoryEntry object with a number of methods and properties available to it. And is there a way to return a true instance of the .NET class in Windows PowerShell?

— AD

Hey, Scripting Guy! AnswerHello AD,

Microsoft Scripting Guy Ed Wilson here. The DirectoryEntry class is documented on MSDN. To gain access to some of the methods and properties described in the MSDN article, you will need to access the base object, which is the .NET Framework class that was used to create the object we see in Windows PowerShell. In many cases, accessing the base object is not required. But because of the way that Active Directory Services Interface (ADSI) created it, we need to use the base object from time to time. An example of obtaining a DirectoryEntry object by using the ADSI type accelerator and displaying its base properties is seen here:

$de = [adsi]”LDAP://dc=nwtraders,dc=com”

$de.psbase | Get-Member

The base members of the DirectoryEntry object are seen here:

Image of base members of DirectoryEntry object

You can, of course, create a DirectoryEntry object directly as seen here. There are five different constructors available for this class. The different constructors are all documented on MSDN:

$de = new-object System.DirectoryServices.DirectoryEntry

You will still need to use PSBase to access all of the methods and properties, but the advantage of creating your own object is you get to define the constructor that is used. I have written several Hey, Scripting Guy! articles that talk about this.


How Can I Run a Script Whenever a New USB Drive Is Attached to a Computer?

Hey, Scripting Guy! Question

Hey, I need to run a script whenever a new USB drive is attached to a computer. Is there a trigger I can use to call my script?

— JG


Hey, Scripting Guy! AnswerHello JG,

Yes. The Monitor Process Event script from the TechNet Script Center Gallery should help. You will need to change Win32_Process to Win32_LogicalDisk, and it will generate an event when a new logical drive is detected.  

Making a Specific Windows PowerShell 2.0 Script Work with Windows PowerShell 1.0

Hey, Scripting Guy! Question

Hey, Scripting Guy! In regards to the Can I Determine Which Folders Are Using the Most Space on My Computer? article, I appreciate the level of detail and helpfulness of this article. The script was written using Windows PowerShell 2.0. For those folks like me who are still using Windows PowerShell 1.0, how can such a task be done?

— JS

Hey, Scripting Guy! AnswerHello JS,

Basically the only Windows PowerShell 2.0 things I did in that script was use the new help tags. When they are removed, the script will work. I took the time to do this for you, and to test it on my Windows XP box that runs Windows PowerShell 1.0. I then posted the script to the new Script Center Script Gallery. You can access the script from http://bit.ly/14dzcY.


Can I Use VBScript to Distinguish Between Versions of Windows Server 2008?

Hey, Scripting Guy! Question

Hey, Scripting Guy! How can I make the distinction between a 32-bit and a 64-bit version of Windows Server 2008 using VBScript?

— VJ


Hey, Scripting Guy! AnswerHello VJ,

Here is some Windows PowerShell code I wrote to determine if a computer is 32-bit or if it is 64-bit.

Function Test-64

{ If($env:PROCESSOR_ARCHITECTURE -match ’64’) { $true } ELSE { $false }}


Function Test-32

{ if($env:PROCESSOR_ARCHITECTURE -match ’86’) { $true } ELSE { $false} }


In the two test functions, I read the value of the Processor_Architecture environmental variable. Here is a VBScript that you can modify to search for the Processor_Architecture variable to use in your VBScript code.



p style=”MARGIN: 0in 0in 8pt” class=”MsoNormal”>


How Can I Determine the Drive Letter of My CD-ROM Drive?

Hey, Scripting Guy! Question

Hey Scripting Guy! The script in the How Can I Determine the Drive Letter for the Drive My Script is Currently Running On? article does not return the CD drive letter (like it says it does) but rather the “C:” drive every time, no matter which PC I put the CD into. Any idea why? 

— JW


Hey, Scripting Guy! AnswerHello JW,

The script that you refer to does not return the drive of the CD-ROM necessarily. It returns the drive letter from where the script was launched. In the email from RKG (in the article), his script was on a CD-ROM and he wanted to know the drive letter from where the script was running—in his case the CD-ROM. If you are running the script from your C: drive (as would often be the case), the script will always return the drive letter “C”. If you are running it from your D: drive, the script will always return “D”. If you have it on a portable USB drive, and do not know which drive letter has been assigned to your USB drive, the script will convey this information to you. This is in fact the purpose of the script: to tell you from where the script is being launched. It is useful in situations when, for instance, you have the script on a USB drive, and want to copy files from your computer to the USB drive, but you do not know the letter of the USB drive. You would include this code at the top of your script to obtain the drive letter of the USB drive, and then begin your copy operation. For simply determining the drive letter of your CD-ROM drive, you could use the List CD-ROM Properties script from the new TechNet Script Center Gallery. 


Well, this concludes another edition of Quick-Hits Friday. It also concludes another exciting week on the Script Center. Join us next week as we delve into the mysteries of…we’ll let that remain a mystery for now.

If you want to know exactly what we will be looking at tomorrow, follow us on Twitter or Facebook. If you have any questions, send e-mail to us at scripter@microsoft.com or post them on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.


Ed Wilson and Craig Liebendorfer, Scripting Guys