On the Road

map After a long winter I think is time for a road trip. I will out and about over the next few months, hopefully speaking at an event near you. Many of the events are free or charge a small fee, but all I hope will be worth your time. These are the events I can tell you about now. As more come up, I’ll post them. For now, here is where I’ll be, what I’ll be speaking about and a link to more information and/or registration. Seating may be limited for some of these events so don’t wait too long to make your plans.

March 22, 2013 New York City, NY
Techstravaganza
“Creating Reports Managers Will Love to Read”

April 5, 2013 Omaha, NE
SQL Saturday #197 Pre-Conference workshop
Prof. PowerShell Or How I Learned to Stop Worrying and Love PowerShell

April 6, 2013 Omaha, NE
SQL Saturday #197
Getting Started with PowerShell’s Job Infrastructure
Getting Started with PowerShell Workflows

April 17, 2013 Syracuse, NY
CNY .NET Developers Group
Advanced PowerShell Scripting

April 22-24, 2013 Redmond, WA
PowerShell Summit
Adding a GUI to PowerShell without Winforms
Get-Data | Out-Style Creating HTML Reports with Flair

May 2-3, 2013 San Francisco, CA Just Announced!
Tech Days
10 PowerShell Mistakes, Trips and Traps and How to Avoid Them
File and Folder Provisioning with PowerShell and Windows Server 2012
Troubleshooting Active Directory with Windows PowerShell
Building a Windows 8 Hyper-V Lab

I’m looking forward to getting out there and talking about PowerShell. If you are interested in having me speak at your event, or run a pre-conference say at a SQL Saturday event please feel free to contact me.

TechEd 2012 Slides and Demos

At TechEd North America in Orlando, I presented a great session on Group Policy and Windows PowerShell. The session was entitled Group Policy Reporting and Analysis with Windows PowerShell. I co-presented with Group Policy MVP and guru Jeremy Moskowitz. Jeremy played the part of the “pointy-haired” boss, posing questions about Group Policy such as finding out what policies are being used, what policies have empty nodes and where are there empty registry settings?

Jeremy explained why this should matter to you, and then Prof. PowerShell, demonstrated how to solve the problem with Windows PowerShell and the Group Policy module.

It was a lot of fun and we received some excellent feedback. The session was even streamed live and recorded so if you missed it, you can still check it out.

Or visit http://bit.ly/MpHsAW if you want to download the video for later.

You can download a pdf of the slide deck. I also have a zip file with my PowerShell demo scripts. Some of these files are meant to be run one command at a time so look at the files before you do anything.

If you need some help with Group Policy, I encourage you to visit GPAnswers.com and have Jeremy help you out. And naturally, if you are looking for PowerShell help or training, I hope you’ll let me know.

Enjoy!

Test Connection Troubles

In this week’s Prof. PowerShell column, I have an article on using the Test-Connection in Windows PowerShell. I thought it was pretty straightforward, but I didn’t take problems into account. I received an email asking what to do about error messages. For example, what if you have a computername in the list that can’t be resolved to an IP address? At first I thought you could use a traditional Trap, but after a little testing that’s not really going to give you what you want, I think. Here’s how I would handle it.

Now you can certainly use a Trap statement. You’ll need to use the –ErrorAction common parameter with Test-Connection cmdlet. That’s what I would do with most cmdlets. But in this case, I’m probably going to use it expecting a boolean value of True or False. The cmdlet is a wrapper for the Win32_PingStatus class and as such will attempt to resolve computernames.  You can use an IP address for the computername, but you’ll get the same type of error if the computer is down.

Instead, I’ll simply tell Test-Connection to ignore any exception and keep on rolling. I can (probaby) safely assume that if there was an exception that the computer is “down” or I do not have a valid connection, which is the whole point of the cmdlet anyway, right?

On my network some of these computers are valid and some are not. I don’t really care why a computer fails the connection test and I’m not sure I can get that information anyway from the underlying exception. The exception is the same, although the message does vary. Here’s almost the same code with the addition of a Trap statement.

The other significant change is that I changed the ErrorAction to Stop so that the exception is caught by the trap.  The Trap is part of the ForEach construct so that PowerShell will continue with the next command in the same scope as the trap.

Obviously there are many ways you can use Test-Connection and I won’t swear that these ideas will work in all situations, absolutely. But hopefully it will give you a place to start.