Convert Text to Object with PowerShell and Regular Expressions

squarepatternA few weeks ago I was getting more familiar with named captures in regular expressions. With a named capture, you can give your matches meaningful names which makes it easier to access specific captures. The capture is done by prefixing your regular expression pattern with a name.

When you know the name, you can get the value from $matches.

This also works, and even a bit better, using a REGEX object.

With the REGEX object you can get the names.

Because the names include index numbers, I usually filter them out. Once I know the names, I can use them to extract the relevant matches.

Then I realized it wouldn’t take much to take this to the next step in PowerShell. I have a name and a value, why not create an object? It isn’t too difficult to create a hashtable on the fly and use that to create a custom object. Eventually I came up with ConvertFrom-Text.

The function requires a regular expression pattern that uses named captures. With the pattern you can either specify the path to a log file, or you can pipe structured text to the function. By “structured text” I mean something like a log file with a predictable pattern. Or even output from a command line tool that has a consistent layout. The important part is that you can come up with a regular expression pattern to analyze the data. I also wanted to be able to pipe in text in the event I only wanted to process part of a large log file.

Here’s an example using the ARP command.

In this particular example, I’m trimming the ARP output to remove any leading or trailing spaces from each line and then converting each line to an object, using the regular expression pattern.

convertfrom-text

If you haven’t jumped to why command is useful, is that once I have objects I can easily filter, sort, group, export, or just about anything else. By converting a log file into a collection of objects I can do tasks like this:

convertfrom-text-2

I hope some of you will try this out and let me know what you think. What works? What is missing? What problem did this solve? Inquiring minds, well at least mine, want to know. Enjoy.

Managing Local Admin with PowerShell

021913_2047_WordTest1.pngYears ago when I was deep into VBScript and HTAs, I wrote a tool called PWDMan. It was an HTA that processed a list of computers and returned password age information for the local administrator account. It was also capable of setting a new account password. Apparently this is still a common task because I’ll periodically get emails from people asking where they can get a hold of PWDMan. You can’t. And the reason is that we now have PowerShell and that is what you should be using, and if necessary, learning. So let me share a few examples of how to achieve the same functionality from my old PWDMan tool using PowerShell.

In the HTA, I used ADSI to connect to the remote computer and get the local administrator account. The object you get back has a PasswordAge property that is the number of seconds since the password was changed. So here’s a code sample.

In this example I’m defining a list of names. But you could easily read the contents of a text file with Get-Content or query Active Directory. Because you might have renamed the administrator account, or perhaps you need to check a different local acccount, I’ve created a variable for the account name. PowerShell then takes each computername and builds an ADSI connection to the administrator account, getting the passwordage value and dividing it by the number of seconds in a day. So $Age becomes the account password age in days. Because PowerShell is all about the objects, I create a custom object with some relevant information. Here’s the result.

local-admin-age

You may be wondering why I used ForEach-Object instead of the ForEach enumerator. That’s because the latter doesn’t write anything to the pipeline and I might want to save results to a text file or export to a CSV.

Be aware that I’m simply demonstrating some PowerShell examples. Ideally, you would want to build a tool to get the password information that you could combine with other PowerShell tools. In fact, what I’ve given you is close to being a function already but I’ll let you see if you can work it out. You want to be able to run a command like this:

The middle command is the tool you will build.

Now, what about changing the password? That too, can be accomplished with a one line command.

If you wanted to change the password for all of the machines that you reported on, it wouldn’t take much work to modify “get” code. So you see, using ADSI in PowerShell is just as easy, if not more so, than using it in VBScript.

There are a few caveats:

  • Don’t forget that the WinNT moniker is case sensitive.
  • There is no easy way to use alternate credentials.
  • There is no WhatIf support, unless you write a script that provides it.

My code samples here are intended as educational. You should take the time to build and test a more robust solution based on your needs. So the next time you think you need VBScript, stop and advance to PowerShell Place.

Out with the Windows.old

over-the-hill Over the last few days I’ve started the process of upgrading my test virtual machines to Windows Server 2012 R2, or in the case of my mini Hyper-V server, to the final bits of Windows Hyper-V Server 2012 R2. In many cases I had been running the preview bits. I know I probably should have done clean installs, but I decided to upgrade in-place. The upgrade itself is easy and quick. However, the upgrade comes with a price.

The upgrade process will leave a folder called Windows.old which essentially contains files from the previous installation. As you might expect this file can take up a lot of space. Unfortunately, you can’t simply delete the folder as many of the files and folders have special permissions and owners. If you search, you’ll find a number of articles that explain the proper way to remove this folder is to use the disk clean up wizard or the Cleanmgr.exe command line tool. But some of my systems are running Server Core which means no GUI for the clean up wizard and no command line tool. Eventually I came across this solution.

His solution requires junction.exe from the Sysinternals website. His solution was also a mix of PowerShell and CMD commands. I decided this could all be done with PowerShell, plus I could take advantage of ShouldProcess so the script supports -WhatIf.

You will need to make sure junction.exe is somewhere in your path. I put a copy C:\Windows. I’ve used this a few times and it works pretty well. You will probably get prompted to continue and it will take a few minutes to run. But it gets the job done when other options are not available. I hope you’ll let me know how it works for you, but please test in a virtual environment where you can roll back and/or make sure you have a verified backup.

Turning CLI Tools into PowerShell Tools

talkbubble Last night I gave a presentation for the Mississippi PowerShell User Group. My talk was based on the chapter I contributed to the forthcoming PowerShell Deep Dives book. In the chapter I explore different techniques for turning command line tools into PowerShell tools. My presentation demonstrated those techniques in action. As promised, I’ve bundled my slides, the few that there are, along with my demo commands and sample PowerShell functions.

Download TurnCLItoPS.zip.

Get Local Admin Group Members in a New Old Way

Yesterday I posted a quick article on getting the age of the local administrator account password. It seemed appropropriate to follow up on a quick and dirty way to list all members of the local administrator group. Normally, I would turn to WMI (and have written about this in the past). But WMI is relatively slow for this task and even using the new CIM cmdlets in PowerShell 3.0 don’t improve performance. Instead I’m going to return to an old school technique using the NET command.

It is very easy to see members. To query a remote computer all I need to do is wrap this in Invoke-Command and use PowerShell remoting.

Yes, there is some overhead for remoting but overall performance is pretty decent. And if you already have an established PSSession, even better. For quick and dirty one-liner it doesn’t get much better. Well, maybe it can.

I have no problem using legacy tools when they still get the job done and this certainly qualifies. To make it more PowerShell friendly though, let’s clean up the output by filtering out blanks, that last line and skipping the “header” lines.

Boom. Now I only get the member names. Let’s go one more level and write an object to the pipeline and be better at handling output from multiple computers. I came up with a scriptblock like this:

This will create a simple object with a properties for the computername, group name and members. Here’s how I can use it with Invoke-Command.

get-netlocalgroupNow I have objects that I can export to XML, convert to HTML or send to a file. But since I’ve come this far, I might as well take a few more minutes and turn this into a reusable tool.

This function lets me specify a group of computers or PSSessions as well as the local group name. Today I may need to know who belongs to the local administrator’s group but tomorrow it might be Remote Desktop Users.

Sometimes even old school tools can still be a part of your admin toolkit.