SAPIEN Solutions

Windows PowerShell™: TFM®

Unfortunately, it's difficult to get every detail right in a large book, especially when the book started out working with pre-release versions of a product. We regret any errors, and will use this page to offer corrections and amplifications as needed. We aren't going to point out minor typos unless they're in a script or unless they're affecting the meaning or clarity of the text.

The following corrections and amplifications apply to the first printing of the book.

Found additional corrections? E-mail errata@sapien.com. Technical support for this book is held in the forums on www.ScriptingAnswers.com.

Chapter 1

On page 42, we refer to the Make-Shell cmdlet. In the release version of PowerShell, this became an external executable not distributed with PowerShell itself. Due to some design considerations made by the PowerShell team, we no longer recommend the user of Make-Shell. Instead, to create a new PowerShell shortcut that pre-loads selected snap-ins for you, do this:

• Open a new shell window
• Load the snap-ins desired
• Use the Export-Console cmdlet to create a new shortcut
• Use this new shortcut to open new shell sessions from now on

Alternately, load snap-ins through your PowerShell profile script by placing Add-PSSnapin commands in your profile. This is recommended because it allows other hosting environments, like SAPIEN PrimalScript, to also read your profile and set up a compatible operating environment for you. Our revised "Multiple Shells" section from Chapter 1 reads as follows:

So far, we've been working with the "default" PowerShell shell that cannot be modified that includes the PowerShell binaries and cmdlets. However, you can build a new shell shortcut that pre-loads any additional snap-ins you obtain or create. For example, this allows you to create a shell that's specific for a particular job task in your environment, ensuring that all related cmdlets stay packaged together. It also helps protect the integrity of the original default shell so you don't mess it up by accident.

The Export-Console cmdlet lets you create a new shell shortcut. You can run Help Export-Console to obtain a complete list of the cmdlet's parameters optional parameters. Of course, making a new shell shortcut isn't the only way to add snap-ins or providers, and you can also simply place calls to Add-PSSnapin into your profile script to have snap-ins load automatically when you launch a new shell session.

Chapter 3

On Page 70, Chapter 3 cuts off unexpectedly. The concluding text was accidentially movied to near the end of page 97 (at the word "asswords," which is part of the word "passwords"), finishing on page 98. This will be corrected in the second printing of the book. Page 70 should end with:

...they're very long passwords-think passphrases-to help avoid the possibility of an easy dictionary attack. You should also be aware that a clever...

Continued by the remainder of the text on pages 97 and 98. Chapter 4, which ends on page 97, should have finished with it's "conclusion" box:

We covered a lot in this chapter including how WMI works and how PowerShell scopes operate. Perhaps most importantly, we looked at how the .NET Framework underlies and enhances PowerShell. We also provided some hints about how PowerShell can utilize the Framework in administrative tasks.

Chapter 4

There is a typo on page 73. This:

$stuff = get-wmiobject -class Win32_Process namespace -root\cimv2

Incorrectly placed the hyphen for the namespace parameter. It should read as follows:

$stuff = get-wmiobject -class Win32_Process -namespace root\cimv2

Another typo exists on page 85. When demonstrating that the ToUpper() method cannot be used on a variable that is an Integer, the code in the book appears to have been partially deleted, resulting in:

$a = 1
write-host $a.r( <<<< )

The correct text is:

$a = 1
write-host $a.ToUpper()

Followed by the error message generated by Windows PowerShell.

Chapter 16

On about page 371, when discussing GetObject, we said:

GetObject() in PowerShell is a bit more difficult. Unfortunately, PowerShell doesn't have a cmdlet that does exactly this. In fact, PowerShell doesn't even provide great built-in support for ADSI. Had this GetObject() example been for WMI, we could use the Get-Wmiobject cmdlet instead. But ADSI is conspicuously missing in PowerShell's repertoire. So, there really isn't a way to use GetObject() or something like it in PowerShell. When possible, try to work with WMI instead. In many cases, WMI offers an alternative to what you were doing in ADSI, although certainly not always.

In fact, the final release of PowerShell does include fairly good support for ADSI, allowing you to retrieve ADSI objects using the [ADSI] type adapter, which we demonstrated pretty thoroughly in Chapter 12 of the book. This paragraph in Chapter 16 was missed during our "RTM" review, and is not wholly correct. We offer this revision:

GetObject() in PowerShell is a bit more difficult. Unfortunately, PowerShell doesn't have a cmdlet that does exactly this. Had this GetObject() example been for WMI, we could use the Get-Wmiobject cmdlet instead. For ADSI, we'd simply use something like [ADSI]$var = "WinNT://don-pc/administrator,user", instead. One weakness of PowerShell v1.0 is that the underlying .NET Framework classes, which PowerShell uses to work with ADSI, don't do a great job of representing objects from the WinNT provider. That's not PowerShell's fault, but rather a limitation of the Framework in its current implementation. That doesn't mean you can't work with WinNT, just that doing so may be less intuitive or straightforward than it was under VBScript.