Bruce Payette’s new book

Bruce Payette is a founding member of the Windows PowerShell team, the author of the Windows PowerShell language interpreter, and one of the key designers of the Windows PowerShell language.

I got my copy today of Bruce Payette’s soon-to-be-released book “Windows Powershell in Action”. While the final version is not yet available, you can buy an “Early Access Edition” from the publisher’s website right now.  That allows you to download a PDF version of the unedited draft now and then receive the final published copy in paper and/or ebook version when released. Since my wife is a “bookie” (the kind that sells books, not betting slips), I’m accustomed to reading pre-publication editions of books. Plus I’m impatient and wanted it right now. Downloading a PDF beats FedEx every time.

At any rate, I’m only in chapter 2 since I’ve only been able to read it occasionally at work today. But it looks to be just what I was looking for. Highly recommended.

Advertisement

“Invisible” methods for ADSI?

RC2’s new [ADSI] type shortcut showed up without any methods, only properties, causing quite a bit of confusion, given that a lot of working scripts are now broken. Aruk Kumaravel, Windows PowerShell Development Manager, provided a little clarification in a posting at microsoft.public.windows.powershell. The part I still don’t understand is why they would even consider not exposing the methods via get-member…

Folks,
I know that many of  you are wondering about ADSI changes in RC2.  I am currently in the process of  writing a blog to explain  the new ADSI support. People are wondering as to why methods are not showing up in  GM.  .Net DirectoryService Object is wrapper around the underlying AD com object. Based on the  type of AD com object, it can have any number of interfaces like  IADs, IADsContainer, IADsNameSpaces   etc.   .Net DirectoryService doesn’t expose all the functionality of the underlying AD object. That is the reason why  DirectoryEntry object has property called  NativeObject  to access the underlying COM object. The Native COM object doesn’t have all the metadata to determine all the methods that it provides.  Faced with this constraint, we chose a route similar to VBScript.  When we decided to support AD Scripting, we wanted to make it as simple as possible but at the same time expose of the full functionality of  AD. VBSCript provides this functionality with set of following methods alone

Create
Put
Set
PutEx
SetEx
GetInfo
SetInfo

The above list of methods will allow you to do pretty much all ADSI scripting tasks.  We thought of exposing these set of methods as part of Get-Member call but decided against it (In retrospect, maybe we should have exposed these).  Not exposing the methods is what throws people off with the new ADSI support.

I had  written some blog posts on using new ADSI support in the following blogs.  Please take a look at it. I used  ADAM to test these scripts

http://blogs.msdn.com/arulk/archive/2006/07/25/678137.aspx
http://blogs.msdn.com/arulk/archive/2006/07/28/682289.aspx
http://blogs.msdn.com/arulk/archive/2006/08/24/719241.aspx

For Advanced script users, who are still interested in access to the DirectoryEntry object,  it is available as PSBase property in the PSObject. People who are familiar with ADSI scripting with VBScript will find the transition much easier.  If you are used to using DirectoryEntry object then the new changes would be disruptive to existing mental model.

I will  look into some of the examples people have provided in the blog posts and convert few of this into new ADSI syntax and share it  with you.

thanks

Aruk Kumaravel [MSFT]
Windows PowerShell Development Manager
Microsoft Corporation

I want my DirectoryEntry methods back

RC2 is out and we have a new type alias [ADSI] for dealing with DirectoryEntry objects in AD, but inexplicably (at least to me), we’ve lost all the methods associated with that class unless you change everything to use psbase

So instead of saying something like

PS>$Entry = New-Object DirectoryServices.DirectoryEntry (“LDAP://dc=domain,dc=com”)

I can say

PS>$Entry = [ADSI] “LDAP://dc=domain,dc=com”

But instead of saying

PS>$Entry.get_Children()

I have to say

PS>$Entry.psbase.get_Children() 

And a fair amount of working code no longer works.

I don’t pretend to understand the discussion on the newsgroup about “adapting” and why using psbase is better than before. So in the spirit of PowerShell, I’ve just extended the type definition for DirectoryEntry so that I can still use the previous code.

For each of the previous methods for DirectoryEntry, I’ve added a ScriptMethod. So for example,

<ScriptMethod>
  <Name>get_Children</Name>
  <Script>
    $this.psbase.get_Children()
  </Script>
</ScriptMethod>

allows me to continue to use

$Entry.get_Children()

without the psbase “layer”.

This also allows previous code like MoW’s

<ScriptProperty>
  <Name>PasswordLastChanged</Name>
  <GetScriptBlock>
  $this.InvokeGet(‘PasswordLastChanged’)
  </GetScriptBlock>
</ScriptProperty>

to work again. I haven’t tested these definitions thoroughly so YMMV, but if you’d like to try them out, please help yourself to a copy of them. Comments are always welcome also.