XML Data and PowerShell

Posted on January 10, 2017 by Jeff Hicks in PowerShell with 0 Comments

PowerShell-Text-Purple-hero

Now that you’ve created some XML files, let’s see how you can use them in PowerShell. If you’re just jumping into the series now, I strongly encourage you to at least skim the previous articles. I want to demonstrate how to bring XML files into PowerShell and I will be using some of the files created earlier.

 

 

The easiest way to bring an XML file to life in PowerShell assumes you planned ahead and used the Export-Clixml cmdlet. This command is designed to serialize the pipeline output of a PowerShell expression and save the results to an XML file. This file is designed to be used within another PowerShell session. In a previous article, I ran this command.

The resulting XML file can be re-imported into any PowerShell session using Import-Clixml. This cmdlet will deserialize the contents of the file and in essence recreate the objects.

Imported clixml

Imported clixml (Image Credit: Jeff Hicks)

The output is the same as it was when I originally ran the command. Using this set of commands can be very handy. I could send you the XML file and you could import it on your computer allowing you to see the results as if you had run the command on my computer. Although there is one significant difference. Look at the objects after they are imported.

Imported XML objects

Imported XML objects (Image Credit: Jeff Hicks)

The first thing to notice is the type name. This is no longer a System.ServiceProcess.ServiceController object, but a deserialized version. The property names are all the same but there are no object methods such as Start() or Stop(). The few methods listed, which I’ve crossed out, are added by PowerShell for every object type.  But because the properties are the same, I can use them.

Using imported data

Using imported data (Image Credit: Jeff Hicks)

Remember, the XML file is essentially a point-in-time view of these services at the time of export.  Something you might consider is adding a property when you export the data that will indicate when it was exported.

This will add a new property to the object, which I can use if I want.

Using a custom property

Using a custom property (Image Credit: Jeff Hicks)

Depending on your version of PowerShell, you can also use Export-Clixml and Import-Clixml to safely store credentials.

The XML file does not store the password in plain text.

An exported credential

An exported credential (Image Credit: Jeff Hicks)

You can re-import this file at any time on the original computer.

The passwords are the same!

Comparing credentials

Comparing credentials (Image Credit: Jeff Hicks)

This should be a safe technique, provided you limit access to your computer. If someone tries to import the file on another computer, it will fail.

Testing the credential file

Testing the credential file (Image Credit: Jeff Hicks)

I copied the XML file to the Work folder on another machine, which can’t decrypt the password. However, the username is still accessible, so I would continue to urge caution.

Sponsored

Learning how to use these cmdlets is very important in your PowerShell work. They will help you out in troubleshooting because you can compare a previous state, exported to a file, against the current state.

At some point in time, I create a reference file. Later, I can compare these results with current file.

For processes, which change constantly, all I want to see is the name of processes that are running now that weren’t at the time of the import.

Comparing process differences

Comparing process differences (Image Credit: Jeff Hicks)

Of course, you may have other XML files that you want to work with in PowerShell that were not created by Export-Clixml. These files require a different set of steps, which I’ll cover next time.

Sponsored

Tagged with , ,