PowerShell Portability

As we’ve seen there is a lot of product teams within Microsoft adopting PowerShell:

  • Windows Server 2008
  • Exchange Server 2007
  • System Center Operations Manager 2007
  • System Center Data Protection Manager V2
  • System Center Virtual Machine Manager
  • As people start to become aware of the power of PowerShell, we can see vendors starting looking to leverage this also:

  • F5 Networks: Support use of Windows PowerShell to manage F5′s BIG-IP network hardware.
  • Full Armor: Group-Policy Management via Windows PowerShell.
  • /n Software: Network management, messaging and ability to remotely manage Windows via Windows PowerShell.
  • PowerGadgets: Visualization product that allows users to run real-time Gadgets such as charts, gauges and maps. Uses Windows PowerShell to allow users or administrators to easily create Windows Vista Sidebar gadgets.
  • PowerGUI by Quest Software: Graphical user interface for executing Windows PowerShell commands and writing scripts. PowerShell Analyzer by Shelltools: Graphical User Interface for developers as well as administrators.
  • Quest Software: Active Directory Management including new Windows Server 2008 features including read-only domain controllers and new user configuration.
  • Lists taken from PowerShell Home page

    I can see that as each product team and vendor take up this new technology they are going to create their own cmdlets to make administration tasks easier. Now I think this is a good thing, the adoption, creating tools to make life easier. However I see a problem that could arise from this.

    We are going to see the PowerShell landscape changing from machine to machine depending on what products are installed. Are we going to start seeing scripts fail because they have been written with cmdlet dependencies?

    So what’s the solution to this? Should cmdlets be deployed as addons to all PowerShell installations to keep the landscape uniform? What would be the impact on this?

    If I’m on a non-exchange 2007 server, and I have the exchange cmdlets installed should they work regardless, so long as they can reach the exchange server in question?

    Or is the solution to have our scripts smarter, and exit nicely when the cmdlet isn’t available? This still leaves us with a fractured landscape, and I can see as more products adopt PowerShell a larger difference from installation to installation. Or am I just looking at this all wrong?

    Linking a GPO using GPMC and PowerShell

    Previously we have gone through the process of creating a Group Policy Object, and importing a backed up GPO into the directory. In this post we’ll take a look at linking our GPO to an OU.

    We will use the GPO from the previous examples: “New GPO Test”, and we will link it to the Domain Controllers OU.

    As usual, we start by creating a reference to the domain ($root), instantiating the GPMC COM object ($gpm), and by binding to the domain through GPMC ($domain).
    Creating a GPO link with GPMC and PowerShell
    After searching AD for a policy called New GPO Test, we check to see if we have found a match by looking at $GPOlist.count. We have only found one here so we have no problems to proceed.

    The $SOM object refers to the Scope of Management, which is where we specify our target for the link. The -1 refers to the link order, which in this example will append our GPO to the end of the list.
    Methods available to the GPMlink object
    Here we have the available methods on the GPMlink object, in particular we can set the enforcement of the policy. In the example above we can see that the newly linked policy has a link order of 3 showing us that there are 2 other policies linked to the Domain Controllers OU.

    There’s a lot of automated administration that we can apply to Group Policies through the GPMC COM object and PowerShell. For more ideas I’d recommend checking out the scripts provided with GPMC, and the GPMC object model


    #———————————————————————————————————-
    function Create-GPOLink
    #———————————————————————————————————-
    # Depends on Convert-DNtoFQDN function from Code Samples Page
    {
    Param (
    $GPOname,
    [int]$GPOlinkPos,
    $DSlocation
    )
    # Make the connection to the domain through GPMC COM
    $domain = $gpm.GetDomain( (Convert-DNtoFQDN $root.distinguishedName[0]), $null, $gpm.GetConstants().UseAnyDC )

    # Build a GPMC search object to locate the GPO (in both the backup directory and AD)
    $searcher = $gpm.CreateSearchCriteria()
    $searcher.Add( $gpm.GetConstants().SearchPropertyGPODisplayName, `
    $gpm.GetConstants().SearchOpEquals, $GPOname )

    $GPOlist = $domain.SearchGPOs( $searcher )
    # This would be a good place to check that our GPOlist.count is as desired!

    #Define our Scope Of Management (SoM)
    $SOM = $domain.GetSOM( $DSlocation “,”+$root.distinguishedName)

    # Create the actual link
    $GPMlink = $SOM.CreateGPOLink( $GPOlinkPos, $GPOlist.Item(1) )
    }
    # Sample calling:
    Create-GPOlink “New GPO Test” -1 “ou=domain controllers”

    Utilising CMD behaviour in PowerShell

    A couple of days ago Jeffrey Snover posted this article on the Windows PowerShell Team blog. I had noted this behaviour previously and just put it down to a quirk of PowerShell.

    So I’ve been musing over what I miss from the CMD that I’d like available in PoSh. To help jog my memory I fired up a CMD session and typed

    help > help.txt

    That’s quite a list!
    CMD Help output in notepad
    I started to take a look at what command I might be interested in outside of the few Jeffrey highlighted. At first glance I just though about writing a loop to check if an alias already existed, and then create a function for them all. Looking at the list though and some of these are not suitable for PoSh anymore.

    So other than dir, assoc, and vol is there anything to note? Well I did find that a few of the commands appear to be supported natively.
    PowerShell CMD’s
    Well I agree with Mark Russinovich. I like to be able to call the dir command with switches sometimes, but admittedly I’ve been weaned off its use since using PoSH full time.

    I think the only other command I would be tempted to map over would be ftype. It’s a compliment to assoc, and could have an occasional use.

    Ftype command in PowerShell
    Notice that there deliberately appears to be no open action associated with the Microsoft.PowerShellScript.1 ProgId…