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

Hello AD,

Microsoft Scripting Guy Ed Wilson here. TheDirectoryEntry class is documented onMSDN. 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:

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 severalHey, Scripting Guy! articlesthat talk about this.

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

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?

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! How can I make the distinction between a 32-bit and a 64-bit version of Windows Server 2008 using VBScript?

-- VJ

Hello VJ,

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

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 theProcessor_Architecture variable to use in your VBScript code.

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.