XML Marks the Spot
Use the Export-Clixml cmdlet when capturing XML data that you'll want to use later in a PowerShell session.
- By Jeffery Hicks
In the Windows world the XML format has long been the format of choice for capturing complex data. XML is a big topic that deserves a number of lessons, but I'll save that for later. Today I want to cover a few choices you have in taking PowerShell data and turning it into XML.
The first question I always ask in this situation is, "What do you intend to do with XML data?" If you intend to re-use the XML data in a future PowerShell session, then I have one recommendation. If you need XML that you can use outside of PowerShell, then I recommend a different choice. In either situation, XML is the right choice if you need to capture rich objects complete with nested object properties. The CSV format can't handle this, but XML is perfect for hierarchical data.
If you intend on only using the XML data within a PowerShell session, then the best choice is to use the Export-Clixml cmdlet. You can run any PowerShell expression and as long as it writes objects to the pipeline, export it:
PS C:\> Get-Process | Export-Clixml C:\work\myprocs.xml
This might take a little bit to run because all objects are being serialized. In my case I got a 21MB file:
PS C:\> dir C:\work\myprocs.xml
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 5/23/2012 1:56 PM 22215572 myprocs.xml
Sure it is big, but I now have a snapshot of all processes. I can "recreate" those processes by re-importing them into PowerShell:
PS C:\> $importProc=Import-Clixml C:\work\myprocs.xml
The objects even look like process objects:
PS C:\> $importproc
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
------- ------ ----- ----- ----- ------ -- -----------
196 15 26080 19476 73 6272 audiodg
121 10 4308 2340 56 0.17 5012 cAudioFilterAgent64
650 51 35048 8984 241 179.03 2524 cfp
107 14 5188 1060 88 0.19 6072 CFSwMgr
Although technically these are Deserialized.System.Diagnostics.Process objects which means I have no methods, but usually all I want are properties and values anyway.
To use Export-Clixml you must specify a filename. Optionally, you can also limit the hierarchy depth. The default value 2 which means the cmdlet will go down 2 levels. If you have an exceptionally rich object you can capture even more information.
One drawback to this file is that I have always found it problematic to work with outside of PowerShell. For those situations use ConvertTo-XML.
PS C:\> $xml=Get-Process | ConvertTo-Xml
PS C:\> $xml
The cmdlet doesn't create a file, it only creates an XML representation of piped in objects. Like Export-Clixml you can also limit the depth with -Depth. You can also use -NoTypeInformation if you plan on using the file outside of PowerShell. Otherwise, the cmdlet adds some helper information so that if you load the xml in a PowerShell session it has some hints as to what the original objects were.
Because $xml is a complete XML document, it can be modified or explored right from here. But to save the results to a file is a little trickier. You can't just pipe the object or cmdlet to Out-File. Instead you need to invoke the object's Save() method.
PS C:\> $xml.Save("c:\work\procs.xml")
I strongly recommend using the complete filename and path. Curiously, this file is only 1.5MB. But I should be able to use this file anywhere, even back in a PowerShell session.
PS C:\> [xml]$impXML=get-content c:\work\procs.xml
Working with this data is beyond what I want to cover today. But now you have a few tools to transform your PowerShell data to XML. Please transform responsibly.
Jeffery Hicks is an IT veteran with over 25 years of experience, much of it spent as an IT infrastructure consultant specializing in Microsoft server technologies with an emphasis in automation and efficiency. He is a multi-year recipient of the Microsoft MVP Award in Windows PowerShell. He works today as an independent author, trainer and consultant. Jeff has written for numerous online sites and print publications, is a contributing editor at Petri.com, and a frequent speaker at technology conferences and user groups.