Over the years, I've written about type accelerators and PowerShell. A type accelerator is simply a synthetic type name that you can create to serve as an alias to another type name. For example, you could use the int16 type to refer to the System.Int16, or guid instead of [system.guid]. Type accelerators are meant to simplify handling of types by IT Pros in PowerShell scripts.
TAs were first introduced in a beta of PowerShell V2, and I posted code that worked (then). However, I have been recently updating my script library blog (http://pshscripts.blogspot.com), I discovered that TAs stopped working that way. After some fun and effort, I've now found hot how they work today, and how you can play with them!
TAs work by just providing you with an alias to a full type name. To some degree, TAs make up for the lack of a Using statement such as in the C# language. Some common TAs in use include [ADSI], [WMI], [String], [regex] and many more.
This week, I have published a new TypeAccelerators modules. This module contains scripts that define 4 TA-related functions:
Get-TypeAccelerator– this gets the TAs active in your current PowerShell Session. This function also takes a parameter (AliasRE) which is a regular expression over the type accelerators to return.
The scripts also create aliases for these functions: GTA, CTA, NTA and RTA as you might imagine. The module also includes an about_ file for help – you get this importing the module!
You can get the module at http://www.reskit.net/powershell/typeacceleratosr.zip. I will also look to publish this module to the new PowerShell V5 Internet module repository (and maybe Chocolatey too if I get time).
A small footnote: this module and the scripts therein are intended to illustrate the concepts around type accelerators. They lack any sort of pipeline friendliness or error handling. So if you decide to make use of the concepts here – make sure you add the production quality aspects to your code, leveraging mine.
PowerShell is an awesome product with amazing potential. But as we al know, the product team can not do everything and neither can the various product teams at Microsoft. As has been quite evident since Monad first peeked it’s head outside Redmond, the community can provide a lot of great extra functionality. Some an alternative to MS produced code (e.g. the Quest AD cmdlets), while other add-ons add features not available elsewhere.
These add-ons are typically, at least since V2, wrapped up in a module and the module then published somewhere. Finding these modules can be quite a chore as they are scattered all over the Interweb! The Microsoft Script Gallery project has quite a few add-on modules published in their archives.
Here’s a set of the most popular modules published at the Microsoft Script Centre:
Active Directory Replication PowerShell Module 2.01 Managing Active Directory Sites, Site Links and Subnets very easily with PowerShell. Also checking the Active Directory Replication is easy and richer than repadmin.exe, the cmdlets in this module do return objects and not just text. So no more boring test parsing. Download at: http://gallery.technet.microsoft.com/scriptcenter/780a2272-06f9-4895-827e-9f56bc9272c4
In my PowerShell training, I spend time examining modules and how you can use them to manage code and avoid profile bloat. In the (forgive the pun) modules on modules, I do lots of demos where being able to quickly set your location to the personal or system modules folder is useful. One simple way I demonstrate is to create PS drives pointing to the folders. I do this as follows:
# First, create variables pointing to each folder $mod = (ls env:psmodulepath).value.split(";")[0] $sysmod = (ls env:psmodulepath).value.split(";")[1]
As you can see, I first create variables corresponding to the two built in Profile folders. The PsModulePath environment variable is set to a string holding the names of these folders, delimited by a semi-colon. Once I have the $mod and $sysmod variables, I can call New-PSDrive to create the drives. The last two PowerShell statements do return a value, so to to keep the output to a minimum, I just pipe the results to out-null (although I’ll quickly point out there are other ways to avoid the output!)
in a recent blog article I wrote about a new Codeplex project called PowerShell Admin Modules, being developed by super-star MVP Richard Siddaway. I noted two small things I’d noticed about the module. Well today, Richard wrote to say he’d fixed Get-Share to accept wildcards and had changed around the parameters of New-Share to match that of the venerable Net Share.
He also mentions the latest version, 0.2, has a bunch of functions for dealing with binary and hex numbers, which include:
ConvertTo-Binary
ConvertTo-Decimal
ConvertTo-Hex
Get-BinaryAND
Get-BinaryDifference
Get-BinaryOR
Get-BinarySum
Get-BinaryXOR
Get-HexDifference
Get-HexSum
Test-Binary
Test-Hex
This is nice work – although one thought would be to merge the functions of PSAM into the PowerShell Community Extensions.
I just read a neat blog post entitled PowerShelling Audit Reports over on the TenBrink Tech blog. This blog post sets out three scripts: GetRecursiveGroupMembership.ps1, Audit-QuickGroup.ps1, and Audit-MultipleGroups.ps1. The second and third make use of the first. They make use of Quests’s AD tools to create CSV file(s) containing details of members in an AD Group.
Scripts to Modules
Dillon (the post’s author) has implemented all three of these as separate PS1 files. Which is so Version 1. :-)!! As I read through his scripts, I could not escape the felling that a much better approach would be to implement them as a single module with PowerShell V2. So I did! It took a bit more time than I’d hoped, but it helped me to learn a bit more about modules in PowerShell V2.
Creating a Module
I first created a module file (audit.psm1) which contained the three functions Dillon created. These were slightly modified to be functions rather than script files, but the resulting module is essentially identical to the original. I also created a module manifest, which describes the module, and indicates the functions the module should expose to the user once the module is imported. I felt the first function was a helper function so the module only exports two functions not all three.Of course, I could be wrong, but it did make an interesting challenge – just exporting two of the three functions using a manifest.
Here’s the PSM1 Module itself:
#
Write-Host"Importing Module Audit.psm1"
function Get-RecursiveGroupMembership {
<#
.SYNOPSIS
Gets membership of a group.
.DESCRIPTION
Uses recursion to handle nested groups
.NOTES
File Name : Audit.psm1
Author : Dillon (@tealshark on Twitter)
Updated by : Thomas Lee tfl@psp.co.uk
Requires : PowerShell V2 CTP3
This is a helper function and not exported by the module.
Add-Content$file"Audit Report - Active Directory Group Membership"
Add-Content$file$reportDate
Add-Content$file$groupMembers
}
}
# End of Module
Creating the Manifest
I used the New-ModuleManifest cmdlet to produce the basic module manifest, the .psd1 file. I then did a bit of editing with PowerSHell plus to achieve this final manifest:
# Module manifest for module 'audit'
# Generated by: Thomas Lee
@{
# These modules will be processed when the module manifest is loaded.
NestedModules = 'Audit.psm1'
# This GUID is used to uniquely identify this module.
GUID = '5eed72f9-5f1d-4819-973c-63f80ccee415'
# The author of this module.
Author = 'Thomas Lee ([email protected]), with functions by dillon.'
# The company or vendor for this module.
CompanyName = 'PS Partnership'
# The copyright statement for this module.
Copyright = '(c) PS Partnership 2009'
# The version of this module.
ModuleVersion = '1.0'
# A description of this module.
Description = 'This module is a packaging of audit scripts by Dillon into a single module.'
# The minimum version of PowerShell needed to use this module.
# This is a list of other modules that must be loaded before this module.
RequiredModules = @()
# The script files (.ps1) that are loaded before this module.
ScriptsToProcess = @()
# The type files (.ps1xml) loaded by this module.
TypesToProcess = @()
# The format files (.ps1xml) loaded by this module.
FormatsToProcess = @()
# A list of assemblies that must be loaded before this module can work.
RequiredAssemblies = @()
# Lists additional items like icons, etc. that the module will use.
OtherItems = @()
# Module specific private data can be passed via this member.
PrivateData = ''
}
The Results
It turns out that converting a set of script files, like Dillon created initially, into a module (as above) is easy. The syntax of the module file turns out to be a bit tricky, and the error messages and help text in CTP3 are woefully inadequate.
Here’s what this module looks like at runtime:
PS MyMod:\> # Note the module is not yet loaded so you get no output from Get-module
PS MyMod:\> Get-Module audit PS MyMod:\> # So import the module, then look at module details PS MyMod:\> Import-Module audit Importing Module Audit.psm1 PS MyMod:\> Get-Module audit
Name : audit Path : C:\Users\tfl\Documents\WindowsPowerShell\Modules\audit\audit.psd1 Description : This module is a packaging of audit scripts by Dillon into a single module. Guid : 5eed72f9-5f1d-4819-973c-63f80ccee415 Version : 1.0 ModuleBase : C:\Users\tfl\Documents\WindowsPowerShell\Modules\audit ModuleType : Manifest PrivateData : AccessMode : ReadWrite ExportedAliases : {} ExportedCmdlets : {} ExportedFunctions : {[Audit-QuickGroup, Audit-QuickGroup], [Audit-MultipleGroups, Audit-MultipleGroups]} ExportedVariables : {} NestedModules : {Audit.psm1}
PS MyMod:\> # Here – use AutoHelp feature to get help on the exported function/ PS MyMod:\> Get-Help Audit-QuickGroup
NAME Audit-QuickGroup
SYNOPSIS This function takes the distinguishedName of a group in any domain and writes the results of that group membership to a csv file of the same name.
REMARKS To see the examples, type: "get-help Audit-QuickGroup -examples". For more information, type: "get-help Audit-QuickGroup -detailed". For technical information, type: "get-help Audit-QuickGroup -full".
What I learned
This was an interesting exercise. It was pretty easy, but I did stumble a bit with the module (how I wish there has been better documentation on modules with CTP3!). Here are some of my take-aways relating to PowerShell modules in CTP3:
Turning a set of inter-related scripts into a module is both easy, and a good thing!
If you have a module that you want to also have a manifest with, they can both have the same file name but with different extensions (the module itself in a .psm1 file and the manifest in a pds1 file).
To export only a subset of the functions in the .psm1 file, you use the ExportedFunctions feature in the manifest.
To export multiple functions you enclose the set of functions as a string array inside the parenthesis. See this in line 24 above. This format was not all that obvious at first.
You can add statements into the module that are executed when you import the module. See Line 2 in the module – this prints out a short message when you import the module. This has some great potential – thanks to Jeffrey Snover for the tip!
If you import a module (using import-module as above) you can generally remove it using remove-module. This aids in testing!
There’s certainly room for improvement in this module. One thing that could be done would be to check to see if the Quest QAD tools were installed and issue a warning message if not (even better, if the tools are not found the script could go get them and install them for you auto-magically!). There should also be some trap or try/catch statements in the functions to better handle errors. Some auditing of the functions usage could also be implemented.
Modules are pretty cool – I hope this helps you understand them a bit better!
