Last year I wrote a few articles on working with variables. One task I needed was to identify the variables that I had created in a given PowerShell session with a function I wrote called Get-MyVariable. I also posted an article on identifying the object type for a variable value. While trying to find something today I realized I could combine the two ideas.

One approach would be to leave my original function alone. When I need the variable value type, I could simply to this:

See the value in having a function that writes to the pipeline? However, I wanted this to be the default behavior so I decided to incorporate it into my original function. I also realized that there may be situations where I don’t want this information so I added a -NoTypeInformation switch parameter. The changes to my original function were minimal.

Now, I can run a command like this:

I suppose I could further refine the function to do filtering in place for a specific type. But I’ll leave that exercise to you.

Download Get-MyVariable2 and try it out for yourself.

Yesterday I posted an article on listing members of the local administrators group with PowerShell and Get-WmiObject. PowerShell 3.0 offers an additional way using the CIM cmdlets. The CIM cmdlets query the same WMI information, except instead of using the traditional RPC/DCOM connection, these cmdlets utilize PowerShell’s remoting endpoint so they are much more firewall friendly and a little faster in my testing. I’ll be covering these cmdlets over time as PowerShell v3 is released.

The code I wrote yesterday can be re-used with only a few modifications. We can still easily get the group object.

We can connect either by a computername or a CIMSession. We still need to get associated objects. There is a cmdlet called Get-CIMAssociatedInstance which you could use like this:

However, this will return all associations and I have not been able to find a way with this cmdlet to limit results to user and group objects as I did with WMI. However, we can still use the Associators Of query.

These objects have some slightly different property names so to tweak the output I had to make a few changes. Here’s my complete demo script.

Here’s the code in action.

It wouldn’t be much to turn this into a function, although all computers will need to be running Powershell 3.0. Download Get-CIMLocalAdmin and try it out for yourself.

Disclaimer: All of this is based on pre-released software. No guarantees that it will work when PowerShell 3.0 officially ships.

I have a quick post today on using WMI to list members of the local administrators group. It is very simple to get the group itself with the Win32_Group class.

But the class doesn’t have any methods or properties for returning members. However, WMI does allow for this cool thing called “Associators Of”. Basically we ask WMI, “Find everything associated or related to this object”. One quick way to do this is with the GetRelated() method.

By default this will probably return more information than what you need. However, if you know you want to limit results to a single class you can do something like this:

That’s pretty easy and fast. Unfortunately in this scenario, the group might also have other groups as a member which is a different class and I couldn’t find a reasonable syntax with GetRelated() to handle multiple classes. So instead we’ll go back to native WMI approach and use an Associators Of query.

This type of query must be follow a specific format. The best way is to use WBEMTest to find your object, then click on the Assopciators button. Your query syntax will be in the top of the query dialog box. This default query will return everything, but you can add additional filtering. Check out http://msdn.microsoft.com/en-us/library/windows/desktop/aa384793(v=vs.85).aspx to learn more. In this situation, this query will return both users and groups.

Here’s one way I might use it:

I might even refine it a bit:

It doesn’t take much more effort to turn this into a function, but I’ll leave that fun to you.

Probably like many of you I keep almost all of my scripts in a single location. I’m also usually working on multiple items at the same time. Some times I have difficult remembering the name of a script I might have been working on a few days ago that I need to return to. The concept is simple enough: search my script directory for PowerShell files sorted by the last write time and look for the file I need.

That’s a lot to type so why not build a function to do the work for me? In fact, since I spend a lot of time in the PowerShell ISE, why not produce graphical output? The easiest way is to pipe results to Out-Gridview. So after a little tinkering, I came up with Get-LatestScript.

I decided to try something different with the Path variable. I set the default to a global variable, ScriptPath. The idea is that in your PowerShell profile, you’ll have a line like this:

If the function finds this variable, it will use it. Otherwise it will use the current location. Notice I’m also using a validation attribute to verify the path. By default the function returns the 10 newest PowerShell files, based on the last write time. The number of files can be controlled by the -Newest parameter.

In the heart of the script is a one-line expression to find all matching files in the script folder and subfolders.

These files are then sorted on the LastWriteTime in descending order and then I only select the first $newest number of files.

I am only interested in a few file properties so I select them. I also add a custom property to measure the file and get the number of lines in the script.

Finally the results are piped to Out-Gridview.

For now, I have to manually open the file. Perhaps I’ll create a WinForm or use ShowUI to integrate it into the PowerShell ISE.

You can download Get-LatestScript which includes comment based help.

Over the last few weeks I’ve posted articles on the different parameter validation options in Windows PowerShell. More than one person suggested consolidating the articles. That seemed like a good idea. There were a variety of ways to handle this but I wanted something more PowerShell-oriented. Then I realized, why not produce PowerShell About topics? I could create a module that primarily was a collection of about topics on scripting in PowerShell. Import the module and you get the documentation.

In fact, this is a slick idea you might want to take advantage of: create a PowerShell module with nothing but documentation delivered via About_* files. If you are spending a lot of time in the shell, stay there! But before I get sidetracked, let’s look at the module I’m calling ScriptingHelp.

As I said the module is mostly a collection of About_* topics based on some of my blog articles. Then I realized I wanted to make it easier to expose them so I threw together a brief function called Get-ScriptingHelp.

The About topics are edited and revised versions of material previously posted on my blog.

I plan on contributing additional content over time based on previous blog articles, suggestions or anything that comes to mind that I think can help you write more effective PowerShell scripts and functions.

To that end, I have also included a function to help you start scripting even faster. It is a new function wizard called Invoke-FunctionWizard. When you run the wizard, you will be prompted for information about your new function such as its name and parameter information. The wizard will then write a string object with the skeletal outline of your new function, complete with comment-based help. If you run the wizard in the ISE it will automatically insert the text into the currently open file.

But perhaps you’d like to see all of this in action.

I hope you’ll let me know what you think and if you find this useful or worthy of continued development. You can download a zip file of ScriptingHelp_0_9. Extract the folder as a subfolder under C:\Users\\Documents\WindowsPowerShell\Modules. Then import the ScriptingHelp module. This should work in both the console and the PowerShell ISE. Enjoy!

I’ve been writing about the different parameter validation attributes that you can use in your PowerShell scripting. One that I use in practically every script is [ValidateNotNullorEmpty()]. This validation will ensure that something is passed as a parameter value. I’m not talking about making a parameter mandatory; only that if the user decides to use the parameter that something is passed. Let’s look at my demo.

I’ve used the attribute on both parameters. The first parameter I’ve also made mandatory which makes it more likely that something will be entered. But if not, then the script will fail.

I would get a similar message if the user forgot to complete the command.

Even though I’m using a default value for Computername, as soon as the parameter is detected PowerShell assumes I’m going to use a different value.

Validation should work for missing values, a variable that might be null, or in general anything that is meaningless. However, it won’t prevent something quirky like this:

The variable, while semantically meaningless to us, is not null or empty but a string of 1 space. If there’s the chance you might run into this situation then you can add additional validation checks to the parameter.

If you’d like, feel free to download Demo-ValidateNotNull and see for yourself.

I spoke this past weekend at a SQL Saturday event in Rochester, NY. My first SQL Saturday event and it was a lot of fun. A great turnout and some very interested attendees. I did three PowerShell sessions on jobs, scheduled jobs/tasks and an intro to workflows. The latter talk I think blew out some neurons on a few people, but I believe they were still enthusiastic about it.

For SQL Saturday attendees, I’ve posted my slide deck and demo files on the conference site. For everyone else, if you are interested, I’ll also make them available here.

PowerShell 3 Jobs and Tasks
PowerShell Background Jobs
PowerShell Workflow Basics

I expect I’ll be covering this material again in the future here as well as in my Prof. PowerShell column. And as always, if your organization is thinking about some private PowerShell training or mentoring, let me know.

At the PowerShell Deep Dive in San Diego, I did a lightning session showing off something I had been working on. Sometimes I don’t know what possesses me, but I felt the need for a better way to navigate my PowerShell scripts files that had many functions. Some files, especially modules, can get quite long and contain a number of functions. When using the PowerShell ISE I wanted a faster way to jump to a function. The problem is I don’t always remember what I called a function or where it is in the file. It is very easy to jump to a particular line in the ISE using the Ctrl+G shortcut.

So I started with some basics.

I decided I’d use a regular expression pattern to find my functions. I write my functions like this:

So I came up with a regex pattern to match the first line and to include the Filter keyword as well.

I first thought of searching the content of the current file, but that won’t give me a line number. Then I thought of Select-String. With my regex pattern, I can get the content of the current file and pipe it to Select-String. The match object that comes out the other end of the pipeline includes a line number property (awesome) and the matching line. I decided to do a little string parsing on the later to drop off the trailing curly brace.

Because I’m in the ISE I felt the need to stay graphical, so my first thought was to pipe the results to Out-Gridview.

Here’s a sample result.

Now I can see the function name and line number. In the ISE I can do Ctrl+G and jump to the function. Of course, if I modify the file and line numbers change I need to close the grid and re-run my command. But wait, there’s more….

I’ve never done much with the WPF and figured this would be a great opportunity to do something with the ShowUI module. I already had the data. All I had to do was create a form with ShowUI. This is what I ended up with.

The result is a stack panel of buttons in a scroll control. The button shows the line number and function name.

When a button is clicked, the function gets the line number and automatically jumps to it. Originally I was leaving the control open, but this means the function is still running. And if I change the script the line numbers are off so I simply close the form after jumping to the function.

In the end, I packaged all of this as a script file that adds a menu choice. If ShowUI is available, the function will use it. Otherwise the function defaults to Out-GridView.

Now, I can click the List Functions menu choice and I’ll get a graphical list of any functions in the current file. I’m sure the regex could be tweaked. I’m also sure there are improvements I could make to the ShowUI code, but it works.

Download Get-ISEFunction and let me know what you think.

I continue to tinker with Office applications and Windows PowerShell. I was looking at an Excel issue related to opening a new workbook. To verify the problem wasn’t PowerShell related I offered a suggestion to try creating an Excel workbook in VBScript.

In VBScript creating a blank workbook in Microsoft Excel can be accomplished with three lines of code.

In Windows PowerShell we essentially use the same 3 lines.

But PowerShell is all about the objects, so how about a quick and dirty approach? Something perhaps in one line:

You could easily build a simple function to run the 3 lines it takes to open a new Excel workbook but one-liners like this make me smile. Granted, I’m probably not likely to use it, but if nothing else I think it reinforces the object nature of Windows PowerShell.

Each expression nested in () is treated as an object. The inner most expression using New-Object, creates the Excel application object which has a Workbooks property that is an object with an Add() method. Invoking this method creates the workbook object. If I stopped there Excel would be running but not visible. So I get the Application property of the workbook object, and set the Visible property to True.

This command doesn’t offer any way to continue working with Excel from PowerShell; it only opens a new workbook. Let me be clear, I’m not advocating that this is how you work with Excel from PowerShell. I think you will need scripts like the ones I posted from my Deep Dive session. But this one-liner demonstrates what is possible with PowerShell and maybe it will add a little smile to your day as well.

Last week at the PowerShell Deep Dive in San Diego, I did a short presentation on integrating Microsoft Office applications like Excel and Word with Windows PowerShell. I easily could have spoken much longer and probably tried to cram too much in. I spent a lot of time with my demos. I expect at some point a video of my talk will be posted on the TEC site. In the mean time you can download a PDF of my slide deck and a zip file with all of my demos. Some of the scripts have been revised slightly since my presentation. The scripts are NOT intended for production use. They are demonstration and proof-of-concept scripts. Many of them have hard coded paths for additional files so read them carefully before you try to run. I’ve tried to comment extensively so you can understand what is going on, but this is admittedly a complicated topic. I’m hoping to create some additional videos around these demos, but if you have questions please post a comment.

Enjoy.