“PowerGadgets” is an interesting looking data visualization product that works with PowerShell. Graphs, charts, dials, maps and gauges, what’s not to like?

According to their web site “As a Windows PowerShell Snapin, PowerGadgets lets you easily explore, visualize and monitor enterprise data from virtually any data source, including traditional databases and text files, with little or no coding involved.”

They’re currently running a promotion that they’re calling their PowerGadgets MVP Program. Tell them a little about yourself and they may give you a free copy of PowerGadgets. I’ve been wanting to look into this product but didn’t have a budget for it. I recalled a “negotiating skills” course I took a long time ago whose motto was “if you don’t ask, they can’t say yes”, so I filled out their form over the weekend. Got my free license in this morning’s email. Cool. So “thanks” to the nice folks at PowerGadgers. Now to get busy and learn how to use it.

Not to be confused with the above is Andrew Peter’s “PowerShell Gadget” which he describes as “a small gadget that hosts the PowerShell console window in your Sidebar. Commands can be entered straight into the collapsed gadget or, by clicking on the PowerShell icon, the complete PowerShell console is available“. This sounds so interesting that I’m going to have to fire up my Vista test machine just to give it a spin.

Another couple products that I just found are both from “PowerLocker”. Powerlocker (”Encrypt and protect your PowerShell scripts“) and PowerPad (”Quickly edit multi-line scripts, functions, or script-blocks“) both have “community” (read: free) versions, although the free PowerLocker version is limited to 10 line scripts. The paid version of Powerlocker obviously has no line limit. I’ll try both of them, although I’m kind of a die-hard vi user. And I don’t need to encrypt anything at this point, but it sounds interesting to test.

I use AdsiEdit an awful lot. Rarely to actually make changes in AD, but mostly to view or search for objects in AD – looking at attributes, etc. - in order to explore AD. Great tool but in order to search AD, I’d have to switch to LDP or ADUC or some other tool and then go back to AdsiEdit to view the objects that I found. (Of course, now I mostly search with PowerShell but I still prefer a GUI tool for actually viewing the objects/attributes I’m researching.)

So I was interested to find that Microsoft has released a free download of Active Directory Explorer 1.0, which was written by Bryce Cogswell and Mark Russinovich of SysInternals fame. Here’s the description from the tool itself:

Active Directory Explorer (AD Explorer) is an advanced Active Directory (AD) viewer and editor. You can use AD Explorer to easily navigate an AD database, define favorite locations, view object properties and attributes without having to open dialog boxes, edit permissions, view an object’s schema, and execute sophisticated searches that you can save and re-execute.

AD Explorer also includes the ability to save snapshots of an AD database for off-line viewing and comparisons. When you load a saved snapshot you can navigate and explorer it as you would a live database. If you have two snapshots of an AD database you can use AD Explorer’s comparison functionality to see what objects, attributes and security permissions changed between them.

I’m still exploring the tool, but here’s my impressions to date.

First, the visual presentation. Similar to AdsiEdit, but when you select an object on the left side of the interface, it immediately displays the populated attributes on the right side. Much quicker to use than AdsiEdit in this respect. Right-click on the object and you can view the oject’s security and attributes, as well as jump directly to the object’s schema object. It doesn’t appear to show unpopulated attributes. AdsiEdit seems to win on this point – you can toggle between displaying all possible attributes and only those wth values.

It also offers a history mechanism so you can backtrack through the containers and objects you’ve already visited.

Next, the search capability. It’s similar to the search dialog in ADUC, but it gives an extensive list of classes to choose from, as well as a dropdown box of the relevant attributes once you’ve selected a class. More flexible than ADUC in that regard but it doesn’t seem to allow you to create your own arbitrary LDAP search strings like ADUC does, nor does it seem to allow for “or” conditions, only “and” conditions. Unless I’ve missed something, that seems rather limiting.

Finally, the “snap-shot” capability. The documentation says that you can save and reload snapshots into the tool, as well as compare selected parts of two saved snapshots. Haven’t used it yet, but it looks like it might be useful in validating and documenting changes in AD. Our change management folks would like that. Soon as I get my test environment rebuilt, I’ll test that feature.

So my overall impression is that it’s worth further evaluation, even though it doesn’t seem to answer all my wish-list regarding search capabilities and attribute presentation. But for a first version, and a free tool at that, it’s a welcome addition to the tool-kit.

I’ve been doing a lot of work recently where I export data to a csv file and then open the file with Excel so I can convert it to a spreadsheet. But I’m inherently lazy so I went looking for an out-excel cmdlet or some such that would allow me to pipe data directly to Excel. I found code samples of how to start Excel and how to write to cells in a worksheet, but couldn’t find what I wanted, so I wrote an out-excel function.

The basic behavior I wanted was to be able to do something like this -
get-process | where {$_.handles -gt 500} | select name,handles,path | out-excel
and get an open workbook in Excel where the column headers were the names of the properties and where each row corresponded to an object in the pipeline.

I cobbled together some code which worked fine but then I wanted more. I knew that the convertto-html cmdlet has a -property  parameter which allows you to select the specific properties you want, so I decided to add that. Now I could do something like this -
get-process | where {$_.handles -gt 500} | out-excel -pr name,handles,path

I’ve been doing a lot of ad-hoc Active Directory searching and reporting, sometimes retrieving DirectoryEntry objects and sometimes only retrieving SearchResult objects. SearchResults are odd creatures that require way too many keystrokes since instead of typing something nice and short like -
get-searchresults -type user,lockedout -raw | out-excel name, userprincipalname
I would have to type something like this -
get-searchresults -type user,lockedout -raw | select @{n=”Name”;e={$_.properties.name}},
    @{n=”UPN”;e={$_.properties.userprincipalname}}| out-excelname

(That get-searchresults function is a tool I’ve built and added to over time to make my AD searching easier. Normally it returns DirectoryEntry objects, but the -raw switch lets it return the SearchResult objects directly. Saves time when I just need the results of the query and don’t actually need to do anything with the corresponding DirectoryEntry objects. I need to write about that sometime. But did I mention that I was lazy?)

So I added a -raw  switch. Now I can do this -
get-searchresults -type user,lockedout -raw | out-excelname -pr name,userprincipalname -raw

The function itself is relatively straightforward.

The begin  section starts Excel, creates a workbook and initializes  two variables.

In the process section, when the first object is encountered, we use the property list to write the property names in the first row. (If we weren’t provided a property list, we just build one based on the properties of the first object.) At the same time, we build a hash table so later we can look up a property name and find the corresponding column.

After this, we can process each object, enumerating the property names in our header table and writing the matching value from the object to the appropriate column. Using a hash table has the advantage that we don’t have to worry about missing properties or the “ordering” of the properties in the columns.

In the end  section, we just resize all the columns to fit the data. Now we have a spreadsheet open for further analysis in Excel or that we can save for later.

Here’s the function in its entirety – out-excel

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.

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

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.

Yesterday I talked about some “wrapper” functions I use to make the .Net 2.0 AD DirectorySearcher and DirectoryEntry classes easier to use. Then I learned from Marc van Orsouw (better known as  /\/\o\/\/) that I was being too verbose in my use of DirectorySearcher. With Marc’s tips, I could simplify my get-ADEntry function and eliminate the get-UserDN function. (By the way, if you haven’t visited Marc’s site recently, you’re missing some really good Powershell and AD info.)

Instead of

$SearchResults = $Searcher.FindOne()
New-Object DirectoryServices.DirectoryEntry (”LDAP://” + ($SearchResults.properties.distinguishedname))

I could just use

$Searcher.FindOne().GetDirectoryEntry()

So now my get-ADEntry function looks like this

function get-ADEntry {
  param ($LdapPath=”", $samAccount=”", $Guid=”", $SmtpAddress=”")
  $Searcher = New-Object DirectoryServices.DirectorySearcher

  if ($LdapPath -ne “”) {
    New-Object DirectoryServices.DirectoryEntry (”LDAP://” + $LdapPath)
  }
  elseif ($samAccount -ne “”) {
    $Searcher.Filter = “(&(objectCategory=person)(objectClass=user)(samAccountName=$samAccount))”
    $Searcher.FindOne().GetDirectoryEntry()
  }
  elseif ($SmtpAddress -ne “”) {
    $Searcher.Filter = “(&(objectCategory=person)(objectClass=user)(proxyaddresses=smtp:$SmtpAddress))”
    $Searcher.FindOne().GetDirectoryEntry()
  }
  elseif ($Guid -ne “”) {
    New-Object DirectoryServices.DirectoryEntry (”LDAP://<GUID=” + (get-NativeGuid $Guid) + “>”)
  }
  else {
    New-Object DirectoryServices.DirectoryEntry
  }
}

I’ve always liked extensible languages like Perl so I’m enjoying PowerShell’s type extensibility. I’ve added several script methods or properties written by other people to my standard setup. After writing about how I had added a function to my profile.ps1 file which would convert a Guid string to “native” format, it occurred to me that I could just add that as a method to the system.guid type definition. So I added this to my My.Types.Ps1xml file:

<Type>
  <Name>System.Guid</Name>
  <Members>
    <ScriptMethod>
      <Name>ToNativeString</Name>
      <Script>
        $local:NativeGuid = “”
        $this.ToByteArray() | foreach { $NativeGuid +=  $_.tostring(”x2″) }
        $NativeGuid
      </Script>
    </ScriptMethod>
  </Members>
</Type>

 Now I can use that method like this:

PS>$Guid = new-object system.guid (”4c5efbc3-a504-4cda-8cc7-1211ad502c60″)
PS>$Guid|gm

   TypeName: System.Guid

Name           MemberType   Definition
—-           ———-   ———-
CompareTo      Method       System.Int32 CompareTo(Object value), System.Int32 CompareTo(Guid value)
Equals         Method       System.Boolean Equals(Object o), System.Boolean Equals(Guid g)
GetHashCode    Method       System.Int32 GetHashCode()
GetType        Method       System.Type GetType()
ToByteArray    Method       System.Byte[] ToByteArray()
ToString       Method       System.String ToString(), System.String ToString(String format), System.String ToString(…
MSDN           ScriptMethod System.Object MSDN();
ToNativeString ScriptMethod System.Object ToNativeString();
PS>$Guid.ToNativeString()
c3fb5e4c04a5da4c8cc71211ad502c60

And my function becomes  this:

function get-NativeGuid {
  param ($GuidString)
  (new-object system.guid ($GuidString)).ToNativeString()
}

I’ve been using PowerShell to explore Active Directory. Since I do most of my exploring from the command line and I’m inherently lazy, I’ve been creating “wrappers” for some .Net 2.0 AD stuff to add to my profile.ps1 file. (”The fewer keystrokes, the better” is my motto.) I started with the DirectorySearcher by creating a function “new-ADSearcher”.

I was always using the same “preamble” of setting the CacheResults, SearchScope and PageSize so at least I could get rid of typing those all the time. (Yeah, I know that those values for CacheResults and SearchScope are the PS defaults, but I don’t like to have to depend on defaults. So call me OCD.)

The Filter and SearchRoot attributes of the DirectorySearcher were the main things I seemed to be using so they became the parameters for the function. But since the SearchRoot attribute actually required a DirectoryEntry object, that lead to a separate function named (predictably enough) “get-ADEntry”.

get-ADEntry originally only had a single optional parameter of LdapPath, which met the need for the new-ADSearcher function. But I was also frequently needing to access user objects based on their sAMAccountName attribute, as well as other AD objects based on their objectGuid attribute. So get-ADEntry grew a little with the addition of the samAccount and Guid parameters. And now I needed two additional functions, get-UserDN and get-NativeGuid.

get-UserDN was pretty straightforward. All I needed to do was use new-ADSearcher with the appropriate filter. (Did I mention that I was lazy?) Of course, after I wrote get-UserDN, I found myself searching for users by their SMTP address so I just added this to get-USerDN also. (And now I can go back and add that as an option to get-ADEntry also since it’ll just need to call get-UserDN.)

get-NativeGuid was needed because GUIDs are IMHO weird things. By definition a GUID is a 128-bit integer (16 bytes). The most common representation that you seem to see is in the form “e1c9f329-a5c2-46c0-b900-ee8e4e3ebbf6″. But to search for a GUID in an LDAP filter in PowerShell with DirectorySearcher object, you seem to need to use the form “29f3c9e1c2a5c046b900ee8e4e3ebbf6″ which is the form that you’ll get from the get_NativeGuid() method of a DirectoryEntry object in PowerShell. (I say “seem to need” because I can’t find this documented anywhere.) Unfortunately, the system.guid class.tostring formatting options don’t seem to provide this conversion so this function was needed.

Disclaimer: Since I primarily work in a single domain, single forest environment, these functions might have issues in a multi-domain forest. And I haven’t spent any time adding error-checking or usability features. (Did I mention that I was lazy?)

function new-ADSearcher {
  param ($Filter=”",$Root=”")
  $local:Searcher = New-Object DirectoryServices.DirectorySearcher
  $Searcher.CacheResults = $true
  $Searcher.SearchScope = “Subtree”
  $Searcher.PageSize = 1000
  if ($Filter -ne “”) { $Searcher.Filter = $Filter }
  if ($Root -ne “”) { $Searcher.SearchRoot = get-ADEntry -ldappath $Root }
  $Searcher
}

function get-ADEntry {
  param ($LdapPath=”", $samAccount=”", $Guid=”", $SmtpAddress=”")
  if ($LdapPath -ne “”) {
    New-Object DirectoryServices.DirectoryEntry (”LDAP://” + $LdapPath)
  }
  elseif ($samAccount -ne “”) {
    New-Object DirectoryServices.DirectoryEntry (”LDAP://” + (get-userDN -samAccount $samAccount))
  }
  elseif ($SmtpAddress -ne “”) {
    New-Object DirectoryServices.DirectoryEntry (”LDAP://” + (get-userDN -SmtpAddress $SmtpAddress))
  }
  elseif ($Guid -ne “”) {
    New-Object DirectoryServices.DirectoryEntry (”LDAP://<GUID=” + (get-NativeGuid $Guid) + “>”)
  }
  else {
    New-Object DirectoryServices.DirectoryEntry
  }
}

function get-UserDN {
  param ($samAccount = “”, $SmtpAddress = “”)
  $local:Filter = “”
  if ($samAccount -ne “”) {
    $Filter = “(&(objectCategory=person)(objectClass=user)(samAccountName=” + $samAccount + “))”
  }
  elseif ($SmtpAddress -ne “”) {
    $Filter = “(&(objectCategory=person)(objectClass=user)(mailnickname=*)(proxyaddresses=smtp:” + $SmtpAddress + “))”
  }
  $local:Searcher = new-ADSearcher -filter $Filter
  $local:SearchResults = $Searcher.FindOne()
  $SearchResults.properties.distinguishedname
}

function get-NativeGuid {
  param ($GuidString)
  $local:Guid = new-object system.guid ($GuidString)
  $local:NativeGuid = “”
  $Guid.ToByteArray() | foreach { $NativeGuid +=  $_.tostring(”x2″) }
  $NativeGuid
}

Welcome to the Pathological Scripter.