Although it was touched upon briefly in the beginning of this chapter, the importance of Powershell’s .NET Framework integration cannot be stressed enough. By using PowerShell, an administrator now has direct CLI access to the .NET Framework’s thousands and thousands of classes, interfaces, and value types. By definition, each of these .NET Framework “types” is an abstract description of a programmable component that can be used to complete a wide range of automation tasks. In other words, directly from the CLI, an administrator now has access to the same type of reusable programmatic objects that programmers have enjoyed for years.

To an administrator, the obvious question might be: “Why is this so exciting?” Simply put, the answer is that access to the .NET Framework’s class library has the power to make administrators extremely productive in relation to the management tasks that they need to complete. Examples of tasks (but not limited to) that fall under this category are as follows:

To better understand how these benefits are derived, you must first remember that most of the power is realized through the usage of .NET objects. At a basic level, PowerShell uses a .NET object to drastically reduce the amount of effort to complete a task. This reduction may be in the form of fewer commands issued in the CLI or in a script.

However, to truly gain insight into how a class and its resulting .NET object can provide these benefits, it helps to first investigate what comprises these somewhat abstract entities.

To start this explorative process, you need to first understand that a .NET Framework type contains a group of members. These members consist of properties, methods, fields, events, and constructors. An explanation for each member type is as follows:

These members consist of two basic types: static or instance. Static members are shared across all instances of a class and don’t require a typed object to be created before being used. Instead, static members are accessed simply by referring to the class name as if it were the name of the object followed by the static operator (::). For example:

In the previous example, the DirectoryServices.ActiveDirectory.Forest class is used to retrieve information about the current forest. To complete this task the class name is enclosed within the two square brackets ([...]). Then the GetCurrentForest method is invoked by using the static operator (::).

The second member type, instance, is a member that can be accessed only when an instance of a class already exists. This means that you need to first create the object instance before an instance member can be put to use. For example:

In the preceding command, the New-Object cmdlet is used to create an instance of the System.Diagnostics.Process class. The resulting Process object, which resides in the $PS variable, consists of instance members from the System.Diagnostics.Process class. In addition to using the New-Object cmdlet, as previously shown, an object instance or collection that is created using a cmdlet also consists of instance members that are based on a .NET class. For example:

The resulting object from the Get-Process cmdlet consists of the same instance members found with the object that was generated using the New-Object cmdlet. In other words, the object is a .NET object that is based on the System.Diagnostics.Process class and inherits instance members from that type. However, in this case, the cmdlet not only creates a System.Diagnostics.Process typed object, but also binds that object to the powershell process.

The use of objects gives you a more robust method for dealing with data. In the past, data was transferred from one command to the next by using the pipeline, which makes it possible to string a series of commands together to gather information from a system. However, as mentioned previously, most shells have a major disadvantage: The information gathered from commands is text-based. In such cases, raw text needs to be parsed (transformed) into a format the next command can understand before being piped. To see how this parsing works, review the following Bash shell example:

The goal in the previous example is to get the process ID (PID) for the bash process. To complete this task, a list of currently running processes is gathered with the ps command and then piped to the grep command and filtered on the string bash. Next, the remaining information is piped to the cut command, which returns the second field containing the PID based on a tab delimiter.

Based on the man information for the grep and cut commands, it seems as though the ps command should work. However, the PID isn’t returned or displayed in the correct format.

The command doesn’t work because the Bash shell requires you to manipulate text data to display the PID. The output of the ps command is text-based, so transforming the text into a more usable format requires a series of other commands, such as grep and cut. Manipulating text data makes this task more complicated. For example, to retrieve the PID from the data piped from the grep command, you need to provide the field location and the delimiter for separating text information to the cut command. To find this information, run the first part of the ps command:

The field you need is the second one, 3628. Notice that the ps command doesn’t use a tab delimiter to separate columns in the output; instead, it uses a variable number of spaces or a whitespace delimiter, between fields.

The cut command has no way to tell that variable number spaces should be used as a field separator, which is why the command doesn’t work. To get the PID, you need to use the awk scripting language. The command and output in that language would look like this:

The point is that although most UNIX and Linux shell commands are powerful, using them can be complicated and frustrating. Because these shells are text-based, often commands lack functionality or require using additional commands or tools to perform tasks. To address the differences in text output from shell commands, many utilities and scripting languages have been developed to parse text.

The result of all this parsing is a tree of commands and tools that make working with shells unwieldy and time-consuming, which is one reason for the proliferation of management interfaces that rely on GUIs. This trend can be seen among tools Windows administrators use, too, as Microsoft has focused on enhancing the management GUI at the expense of the CLI.

Luckily, for Windows administrators, this trend is now changing with the introduction of PowerShell. They now not only have access to the same automation capabilities as their UNIX and Linux counterparts, but PowerShell and its use of objects fill the automation need Windows administrators have had since the days of batch scripting and WSH in a more usable and less parsing intense manner. To illustrate this, the following command completes the same type of task that you reviewed in the Bash shell example:

On the surface, the command doesn’t necessarily look any shorter or less complex then the Bash shell example. But, underneath something special is happening in the PowerShell pipeline. When the command is executed, a pipeline processor is generated to manage the entire pipeline execution. To start things off, the pipeline processor binds values to the parameters as command-line input for the first cmdlet in the pipeline. In this case, the value is powershell, which is being bound to the Get-Process name parameter by its position within the command. Next, the pipeline processor starts the command processing, gathers the results as a base .NET object, wraps that object within a specifically typed PowerShell object called a PSObject (explained later in this chapter), and then finally passes that object to the next cmdlet in the pipeline.

Like the first cmdlet, the pipeline processor again performs the value to parameter binding. However, in this case, the pipeline processor attempts to perform the binding to parameters that accept pipeline input. For example, if you were to review the full help information for the Format-Table cmdlet, you will find that the inputObject parameter accepts pipeline input.

After the passed value (PSObject) has been bound to the correct parameter, the pipeline processor again starts the command processing, gathers the results as a base .NET object, wraps that object in a PSObject, and then finally passes that object to the next cmdlet in the pipeline. This process then continues until the end of the pipeline has been reached. The pipeline processor then (by default) pipes the resulting object to the Out-Default cmdlet. The Out-Default cmdlet is a special non-interactive cmdlet that is responsible for figuring out how to format and output the object to the PowerShell Console. All pipelines, by default, end with this cmdlet.

In summary, a PowerShell pipeline is a command-processing factory. In this factory, there are a series of commands (cmdlets) that are separated by the pipe operator (“|”). When the factory is put to work, PowerShell attempts to ensure that data from one command is piped correctly to the next command without the need to perform any type of parsing. An example of this is shown in Figure 3.1.

Figure 3.1. A simplistic view of the PowerShell pipeline

The previously shown figure is a simplistic view of the PowerShell pipeline. If this was a book written purely for an audience of developers, there would be number of additional concepts that would need to be discussed about the PowerShell pipeline. Most important of these concepts is the fact that the previous example explains only the pipeline in reference to a single object being passed through. As such, the question must be asked, “What happens when there are numerous objects that are returned by the first cmdlet?” An example of this is shown in the following command:

Here, the Get-Process cmdlet returns a collection of objects. This is different from the first pipeline example where the Get-Process cmdlet returned only one object (unless you had multiple PowerShell Console sessions running at once). If PowerShell were like a conventional programming environment, the results from the pipeline would be returned to the console session only after the entire object collection had finished being processed by each cmdlet. However, like most other shell languages, PowerShell processes objects one at a time within the pipeline. By streaming the objects, PowerShell is able to start outputting data from the pipeline as soon as it is available.

As you might have guessed, being able to stream results back to the interactive console as soon as they are available is important. If this didn’t happen, and the command was data-intensive, then you might be sitting with a blank console session for some time until the pipeline has finished executing. A perfect example of where streaming might be beneficial is shown with the following command:

Here, the command issued is a recursive dump of the entire HKLM PSDrive. If PowerShell didn’t perform pipeline streaming, then it might take minutes before any information is returned to the console session. Instead, when the command is issued, results are displayed almost immediately within the console.

For the most part, PowerShell is a typeless language in that an administrator rarely needs to specify or think about the type of object that they happen to be working with. However, just because you don’t see it, doesn’t mean PowerShell is typeless. Instead PowerShell is type-driven. After all, it is object-based, and it has to interface with many different types of objects from the less than perfect .NET to Windows Management Instrumentation (WMI), Component Object Model (COM), ActiveX Data Objects (ADO), Active Directory Service Interfaces (ADSI), Extensible Markup Language (XML), and even custom objects. To handle these many different types of objects (both programmatically and logically) while ensuring that they can be passed through the Pipeline, PowerShell adapts to different object types and then produces its interpretation of an object for you. To do this, PowerShell uses the Extended Type System (ETS), which provides an interface that enables administrators to manipulate and change objects as needed.

The ETS was designed to overcome three basic problems that are encountered in PowerShell. First, there can be cases where a .NET object doesn’t behave in a default manner, which then can prevent data from flowing between cmdlets. For example, when working with WMI, ADO, and XML objects, their members describe only the data that they contain. Nonetheless, the goal of PowerShell is to work with the data that is referenced by these objects. To get around this predicament, the ETS provides the notion of adapters, which allow an underlying object to be adapted to meet the expected default semantics. Secondly, there might be cases where a .NET object just doesn’t provide the capabilities that are required to complete the task at hand. Using the ETS, these objects can be extended with additional members. Lastly, PowerShell attempts to always interact with an operator by presenting itself as a typeless scripting language. In other words, a variable rarely needs to be declared as a particular type despite the fact that PowerShell is type-driven.

To accomplish these feats the ETS uses a common object that has the capability to state its type dynamically, add members dynamically, and make interactions with all objects consistent. The name for this abstraction layer is the PSObject, a common object used for all object access in PowerShell. The PSObject can encapsulate any base object (.NET, custom, and so on), any instance members, and implicit or explicit access to adapted and type-based extended members, depending on the type of base object.

By wrapping an existing object (base object), the PSObject can be used to show an adapted view of an object or as a vehicle to extend that object. An adapted view of an object will expose only a view of an object that contains a selected set of members that can then be directly accessible. To better understand the relationship between a base object and the resulting PSObject, refer to Figure 3.2.

Figure 3.2. How an object is adapted and the resulting PSObject

In the event that the resulting PSObject does not expose the needed functionality, PowerShell has several different object views that can be used to access blocked members from the base object and gain insight into how the PSObject was constructed. These views are explained as follows:

In certain cases, you might encounter issues with the behavior of a cmdlet’s interpretation of an object. A perfect example of such a scenario can be found with how PowerShell interacts with the DirectoryEntry class. Details about this interaction are explained in Chapter 13, “PowerShell as a Management Interface.” Many of the more useful base object members are not exposed in a PowerShell-based DirectoryEntry object. When this type of scenario is encountered, you can use PSBase view to review the base object and make use of its members. For example:

By default, the Get-Member cmdlet returns only information from the PSObject, PSExtended, and PSTypeNames views. As shown in the previous example, the PSBase view is used in conjunction with the Get-Member cmdlet to expose the members of the base object. To interact with the base object’s members, you use the PSBase view and PowerShell’s “.” notation, as shown in the following command:

After the previous command is issued, you are presented with a formatted table that contains all of the specified Active Directory object’s attributes and their associated values.

Type Accelerators

A type accelerator, also known as a type shortcut, is simply an alias for specifying a .NET type. Without a type accelerator, defining a variable type requires entering a fully qualified class name, as shown here:

PS > $User = [System.DirectoryServices.DirectoryEntry]"LDAP://CN=Fujio
Saitoh,OU=Accounts,OU=Managed Objects,DC=companyabc,DC=com"
PS > $User

distinguishedName
-----------------
{CN=Fujio Saitoh,OU=Accounts,OU=Managed Objects,DC=companyabc,DC=com}
...

Instead of typing the entire class name, you can just use the [ADSI] type accelerator to define the variable type, as shown in the following example:

PS > $User = [ADSI]"LDAP://CN=Fujio Saitoh,OU=Accounts,OU=Managed
Objects,DC=companyabc,DC=com"

Type accelerators have been included in PowerShell mainly to cut down on the amount of typing to define an object type. However, for some reason, a definitive list of supported type accelerators isn’t provided within the PowerShell documentation, even though the [WMI], [ADSI], and other common type accelerators are referenced on numerous Web blogs. Regardless of the lack of documentation, type accelerators are a fairly useful feature of PowerShell. Table 3.1 lists some of the more commonly used type accelerators.

Table 3.1. Type Accelerators in PowerShell

This chapter’s primary focus was to delve deeper into what PowerShell is and how it works. Among the many key concepts that were reviewed, the most important of these is to understand that PowerShell is an object-based shell that is built on top of the .NET Framework. In addition, because of PowerShell’s relationship with the .NET Framework, it exposes the power of that framework’s object model and a .NET feature called Reflection directly from within a command-line console (or script file).

While an object-based shell is not necessarily a new concept, the PowerShell product team wanted to design a shell that would empower its users, not frustrate them. The end result is a shell that meets this objective by attempting to abstract all objects into a common form (PSObject) that can be used without modification (parsing) in your commands and scripts. This feature combined with a robust command pipeline, the concept of cmdlets, and the capability to be adapted as needed, make PowerShell a tool that facilitates the ability to complete tasks.