XML Data and PowerShell


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.



Sponsored Content

What is “Inside Microsoft Teams”?

“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts. Our next episode, “Polaris Inc., and Microsoft Teams- Reinventing how we work and play” will be airing on Oct. 28th from 10-11am PST.

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.

Get-Service wuauserv -comp chi-dc04,chi-p50,chi-core01 | 
Export-Clixml -Path c:\work\wu.xml

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.

Get-Service wuauserv -comp chi-dc04,chi-p50,chi-core01 |
Add-Member -MemberType NoteProperty -Name Exported -Value (Get-Date) -PassThru |
Export-clixml -Path c:\work\wu-dated.xml

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.

$cred = Get-Credential myCompany\Administrator
$cred | Export-Clixml c:\work\admin.xml

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.

$impCred = Import-Clixml c:\work\admin.xml

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.

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.

Get-Process | 
Add-Member -MemberType NoteProperty -Name Exported -Value (Get-Date) -PassThru |
Export-clixml c:\work\proc.xml

At some point in time, I create a reference file. Later, I can compare these results with current file.
$current = Get-Process
$impProc = import-clixml C:\work\proc.xml
compare-object -ReferenceObject $impProc -DifferenceObject $current -Property Name

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.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by: