PowerShell and XML Fundamentals
I’ve had a few requests to write about using XML with PowerShell. XML is one of those topics that IT pros know they should probably understand better, but often feel intimidated or don’t know where to begin. Sounds like a learning opportunity to me. So over the course of the next several weeks, we’ll explore how to work with XML and PowerShell. This first article will cover some basic concepts and commands.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
XML, which stands for eXtensible Markup Language, is a long-established industry standard intended to describe data in a text format. This description can be read by people (once you understand the syntax) and consumed by software for all sorts of purposes. I am not going to cover everything in the XML universe. But I want to impart enough information for IT pros who want to take advantage of XML in their PowerShell work. Because PowerShell is built on the .NET Framework, we have full access to the XML libraries. More on that later.
Note: I will be focusing on current PowerShell releases. The open-source PowerShell project is still under early development and there’s no guarantee that everything I plan on discussing will work on non-Windows platforms. But you are certainly encouraged to test it and find out for yourself.
The core of your XML experience will be an XML document. This file will almost certainly have an XML file extension. It should be a simple text file, which means you can open it with any text editor, including the PowerShell ISE. On many Windows systems, if you double-click an XML file, it most likely will open in Internet Explorer, which is fine if you only need to view the file.
Here is a sample XML file opened in the PowerShell ISE.
The first line in any XML file is a declaration tag. It should be included, but I’ve encountered files without that still “work” as XML files. The declaration indicates what version of the XML specification is being used and file encoding. After that, my sample file has a comment, which the ISE depicts in green.
XML is designed to describe complex data structures, such as objects. XML is a hierarchical structure that begins with a root element, also referred to as a node. This root element is defined with some sort of tag. There are no XML standard tags. You can create and use whatever works for you. That’s the beauty of XML. Tags come in pairs. I don’t show it in the screenshot, but there is also a closing tag at the end of the document:
Caution: Tag names in XML are case-sensitive.
Within the root node tags is a hierarchy of child nodes, each described by a matching set of tags. The text between tags is, in essence, the value for that particular element. In my example, there is a Name tag and the text between the tags, such as Aerosmith or Rush, can be considered the value.
Because XML is used to describe things, it also supports attributes. An attribute is defined within a tag and often provides some sort of additional information that helps define the attribute. In my example, I’m using Year and City to help describe the name of the band. I did this for demonstration purposes as much as anything. There was no reason I couldn’t have defined them as child nodes as follows:
<Band> <Name>Aerosmith</Name> <Year>1970</Year> <City>Boston</City> <Lead>Steven Tyler</Lead> <Members> <Member>Tom Hamilton</Member> <Member>Joey Kramer</Member> <Member>Joe Perry</Member> <Member>Brad Whitford</Member> </Members> </Band>
When you get to creating custom XML, you’ll have decide what needs to be a node and what needs to be an attribute, which might depend on how you expect the file to be used. But let’s not get ahead of ourselves. One important thing to remember is that the attribute value must always be in quotes.
And that’s pretty much it for XML terms and core concepts. One thing I’ll point out is that XML is often formatted like my screenshot. The use of indentation makes it visually easy to understand the hierarchy. The worst thing you could do is create an XML file in which everything is left justified. PowerShell won’t complain, but you will if you have to read the file!
That’s enough for now. Next time we’ll start looking at working with XML in PowerShell.