Thursday, January 7, 2010

Get-Oneliner | Group it | Sort it | Format it

Well if you read my first post on my blog you will note that I'm not (or wasn't) a fan of one-liners.  I really like structured code; and PowerShell does a great job at letting me do that.  Recently, though, I've had a change of heart (the more I use PowerShell the more I change my views on it).  I've now officially become a fan of one-liners.

I've been reading Dr. Tobias Weltner's book Mastering-PowerShell (I find it to be very well written and super helpful).  Chapter 5 entitled "The PowerShell Pipeline" was very enlightening.  So I wrote a one-liner that gets all AD users and groups them by manager, sorts them and displays them in a nice text tree.  I have two versions.  I wrote the first one because I have a multi-domain forest and some of the mangers are not in the same domain as the users and currently the ActiveDirectory module won't let you search cross domain to my knowledge.  The second example is for a single domain forest.  Both one-liners take into consideration that the user object my not have the manager attribute set.

Example 1 Multi-domain Forest (replace foreigndomain and localdomain with real domain names)
Get-ADUser -filter * -Properties samaccountname, displayname, manager |             
    group {if(($_.manager -ne $null) -and ($_.manager -imatch "dc=localdomain")){            
        (Get-ADObject $_.manager -Properties displayname).displayname            
        }else{            
        if($_.manager -imatch "dc=foreigndomain"){"FOREIGNDOMAINNAME"            
        }else{            
        "UNKNOWN"}}} |             
        sort name |             
        %{$_.Name; "-------------------"; ($_.Group |             
            %{if($_.displayname -ne $null){"`t$($_.displayname)"}else{"`t$($_.samaccountname)"}}); "`n"}

Get-ADUser -filter * -Properties samaccountname, displayname, manager | group {if(($_.manager -ne $null) -and ($_.manager -imatch "dc=localdomain")){(Get-ADObject $_.manager -Properties displayname).displayname}else{if($_.manager -imatch "dc=foreigndomain"){"FOREIGNDOMAINNAME"}else{"UNKNOWN"}}} | sort name | %{$_.Name; "-------------------"; ($_.Group | %{if($_.displayname -ne $null){"`t$($_.displayname)"}else{"`t$($_.samaccountname)"}}); "`n"}            


Example 2 Single-domain Forest
Get-ADUser -filter * -Properties samaccountname, displayname, manager |             
    group {if($_.manager -ne $null){(Get-ADObject $_.manager -Properties displayname).displayname}else{"UNKNOWN"}} |            
    sort name |             
    % { $_.Name;             
        "-------------------";            
        ($_.Group | %{if($_.displayname -ne $null){"`t$($_.displayname)"}else{"`t$($_.samaccountname)"}});            
        "`n"}

Get-ADUser -filter * -Properties samaccountname, displayname, manager | group {if($_.manager -ne $null){(Get-ADObject $_.manager -Properties displayname).displayname}else{"UNKNOWN"}} | sort name | % { $_.Name;"-------------------";($_.Group | %{if($_.displayname -ne $null){"`t$($_.displayname)"}else{"`t$($_.samaccountname)"}});"`n"}

Output will be something like this:

PS C:\>Get-ADUser -filter * -Properties samaccountname, displayname, manager | group {if(($_.manager -ne $null) -and ($_.manager -imatch "dc=localdomain")){(Get-ADObject $_.manager -Properties displayname).displayname}else{if($_.manager -imatch "dc=foreigndomain"){"FOREIGNDOMAINNAME"}else{"UNKNOWN"}}} | sort name | %{$_.Name; "-------------------"; ($_.Group | %{if($_.displayname -ne $null){"`t$($_.displayname)"}else{"`t$($_.samaccountname)"}}); "`n"}            


Foreign Domain
--------------------
    Employee4
    Employee5
    Employee6
    Employee7

Manager1
--------------------
    Employee1
    Employee2

Manager2
--------------------
    Employee3

UNKNOWN
--------------------
    Employee8
    Employee9
    .
    .
    .
    etc...

You get the idea.


Have fun.!

Monday, January 4, 2010

I definately recommend the PowerShellPack.

When I first started developing for PowerShell I was using the PowerShell ISE that comes with Windows 7.  Mainly because my version of Sapien PrimalScript doesn't support PowerShell v2 with Intellisense.  So I looked all over for a snazzy IDE that gave me full support for PS 2.  I liked Quest's editor (PowerGUI) the best, but it just doesn't work at present with the AD module from Microsoft (go figure--Quest has their own AD tools, which are very robust).  So I checked out Idera's PowerShellPlus.  It is just a bit much for me.  Don't get me wrong.  PowerShellPlus is really amazing and Dr. Tobias Weltner has a really good book (and it's free) to help learn PowerShell, but the IDE is just too much for me (price wise-at least for now).  Also, Sapien's PrimalScript 2009 is supposed to be very good (I've been using 2007 for all my VBScripting for years now and I really like their IDE).

However, the more I used PowerShell ISE the more I enjoyed developing with it. It has a great interactive environment.  I can try out my commands first in the console window then go on the left pane (where I've located the editor in my environment), and type my code when it finally works. It's so simple, yet so powerful.

But...I want intellisense (so I thought).  Also I'm blogging now, and I want to copy my nice color coded script to my blog.  Well there really isn't a need for intellisense in ISE. Microsft allows the script editor to use tab completion (out-of-the-box).  I love tab completion and behaves just like the PS console.  Once you get used to tab completion intellisense becomes annoying (at least in my case it did).

What about my blogging though. Well that is where the PowerShellPack comes in (finally--maybe I should have titled this blog entry something else).  When you install the pack (get it here) it adds a ton of features to the ISE.  I can now copy my code in colored HTML straight to the clipboard so that I can post it in my blog.  Isn't that great!

That's not all the PowerShellPack does.  It comes with 10 modules that let you do all kinds of things.  I'm playing around with building UIs using the new cmdlets around WPF.  Good stuff.  Head over to the main site.  Check out some videos and have fun.

Running PowerShell v2 RTM on Something Other Than Win 7 or Win 2008R2

I know this site is dedicated to running PowerShell v2 RTM on Windows 7 or Windows 2008 R2.  However if you would like to start playing with PowerShell v2 RTM on some other operating system go here.

Have fun.

How to use PowerShell v2 RTM and the ActiveDirectory Module that comes with RSAT.

I noticed that not a lot of people are using the new Active Directory module in PowerShell v2 RTM (ps2rtm).  Maybe it's because you can only take advantage of the AD module if you are running Windows 7.  Windows 7 with AD module and ADWS will let you manage Win 2003 AD but you cannot run the PowerShell AD module on Win XP or 2003. 

I had been avoiding PowerShell until recently for the more familiar (in my case) vbscript for several years now.  I just didn't want to give up vb.  [adsi] in PowerShell didn't seem that much easier than adsi in vbscript.  However, recently a catastrophic event took place in my life (all my work in vb for the last year were gone) which caused me to re-evaluate PowerShell.  I'd been putting it off but now forces were at work that kind of shoved me in that direction.  So I dove in.  I have to say--I am so glad I did.

That said I'm finding that a large majority of the posh community are not using the latest greatest.  I can understand that.  Had I invested a couple of years in ps1 I would be reluctant to move to ps2rtm for production stuff (look at me I didn't even want to move away from vbscript).  Plus I was reluctant to move to Windows 7.  All my colleagues were using Win7 RCx not sure which version.  I waited until RTM and then only installed it on an extra workstation in my office.  Now I run it on my primary workstation--it really is a nice OS.

Anyway, I just wanted to say to moving to ps2rtm and using the new ActiveDirectory module is not that painful (if you are running Windows 7).  It takes all of 15 minutes.  I'm not trying to diminish the value of Quest tools, but really the future of ps2 includes a fully functional, fully featured set of AD tools.  And it's really not that hard to start taking advantage of them (even if you are running a Windows 2003 functional AD environment).

First prepare your AD environment.  Here are the instructions and download.  Read the page carefully.  For Windows 2003 DCs you will need to install two patches (the links for the patches are in the instructions on that page) and you may need to install the latest .Net 3.5 from Microsoft Update site.  Again all of the instructions and prerequisites are found on the page I linked to above.  I'm running a Windows 2003 native AD environment on DCs with Windows 2003 SP2 (no R2 in my environment) and ADWS works great.  You only need one DC running ADWS in each domain.

Next install the RSAT tools in Windows 7.  Installation and instructions are here.  After installing the RSAT tools you need to enable the AD features.

If you have prepared your environment according to the instructions, then, after starting PowerShell enter the command import-module activedirectory

enter get-help *-ad* or get-command -Module ActiveDirectory to see all of the AD functionality that the ActiveDirectory module gives.

Sorry Windows XP users or Windows 2003 server users.  The ActiveDirectory module is not (as of yet) available for those systems.  I saw a number of forums with complaints about that but with no response so not sure if MS will ever make the module available for those systems.

Have fun.