Precision Computing

The Outlook team has a tradition of putting calendar diagrams in their OOF messages to try and help clarify the date ranges. In a recent mail to an Outlook-heavy DL, about 50% of the OOF messages I got back contained these mini OOF calendars, so they must find them helpful.

I asked if it was a new-fangled feature in O14, but in fact they do it by hand! (I wonder if they book vacation time for hand-crafting the OOF message.)

If you’re interested in doing the same thing (but a little less painfully,) you can use a PowerShell script: Show-Calendar.ps1.

By the way, I’ll be OOF December 6^th through December 7^th, returning December 8^th.

[C:\Users\leeholm]
PS:1 > Show-Calendar -HighlightDay (6..7) -HighlightDate 12/8/2008

           December 2008

Sun  Mon  Tue  Wed  Thu  Fri  Sat
---  ---  ---  ---  ---  ---  ---
 30    1    2    3    4    5  [ 6]
[ 7] * 8*   9   10   11   12   13
 14   15   16   17   18   19   20
 21   22   23   24   25   26   27
 28   29   30   31    1    2    3

 

Once you get passionate enough about PowerShell to start looking for swag, you know you have a problem. Unfortunately, there is very little available in that regard. If you haven’t seen /n Software's sticker yet, here’s a bunch of people that picked one up while the promo was live. I haven’t seen anything calling out the end to the promo, but the page generates an error when you visit now.

If that still doesn’t satisfy your craving, then you might have a real problem and consider making some yourself.

Luckily, I know people that know I have a problem, so I have been getting some unique gifts lately. The first is a coffee mug. You can get mugs with paper blanks at many stores, and all it takes is a little artistic talent to complete the picture.

The second is an MP3 cozy that gives my mug company on the morning drive. Knitting and PowerShell go together. Who knew? Others have even made hats – how about you?

Once you’ve been using PowerShell for awhile, it’s natural to want to spread the word. We frequently get questions asking for a standard “Introduction to PowerShell” slide deck, but haven’t really had one to share. The problem is that they tend to be pretty customized to the audience – even a “standard intro talk” becomes much more engaging when you target it to a specific audience.

However, those customizations tend to be centered around specific themes, so I’ve reduced a recent presentation to its core and attached it here. This presentation is demo-heavy. Talk all you want about objects, but it doesn’t really click until they see it in action.

Link: Introduction To PowerShell.zip

To run the demos, this zip file includes a version of Jeffrey Snover’s Start-Demo script. This script is pure Presentation Zen. By automating your keystrokes (yet submitting them to the real PowerShell console,) it lets you demonstrate the wonder of PowerShell without torturing your users with lame attempts to type and talk and backspace all at the same time.

.\Start-Demo .\Demo-Discovery.ps1

The Graphical PowerShell demo is not scripted -- the high points I like to hit are:

• UNICODE. PowerShell has always been Unicode-friendly, but the console window is less so.
  We literally had Exchange administrators in Japan having to write scripts in Notepad, and then run those scripts in order to manage some mailboxes. I usually create a directory with a Unicode name, do a dir. Create a file within it (with a Unicode name,) and do a dir. Set the content (with Unicode text) and then get the content (which shows the Unicode text.) I like to use “PowerShell Rocks!” flipped from http://www.flipmytext.com/
• Syntax highlighting and Tab Completion
• Tabs and Free-sizing of the window. It seems like a small thing, but it’s the most common complaint about the console window.

Also, the font slider at the bottom right lets you enlarge all fonts to become demo-friendly.

A question came up on an internal discussion list today about how to let a cmdlet support both simple and detailed views. For example, a –Detailed flag to tell the cmdlet to emit additional information during the request.

The original approach was to do all of this filtering inside of the cmdlet. When –Details is not specified, run through some additional code to remove the extraneous properties.

The goal is noble, but the implementation decision is misguided.

The correct approach here is to have your cmdlet ALWAYS output all of the information. Your default display should have the most important properties, but users shouldn’t have to specify the –Details switch to get access to more.

Compare to System.Diagnostics.Process, a property-rich class emitted by the Get-Process command:

PS C:\Windows\System32> $powershell = Get-Process -Id $pid
PS C:\Windows\System32> $powershell

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    445       9    36688      38156   175     0.78   9828 powershell

If the user wants to view additional details:

PS C:\Windows\System32> $powershell | format-list *
__NounName                 : Process
Name                       : powershell
Handles                    : 445
VM                         : 183631872
WS                         : 39071744
PM                         : 37568512
NPM                        : 9500
(...)

But they can still access specific details if they want:

PS C:\Windows\System32> $powershell.FileVersion
6.1.6930.0 (fbl_srv_powershell(leeholm).071018-1329)

If you have different views of the information you want to surface, our Formatting and Output system fully supports this through formatting extensions and View Names.

In some cases, different views really are a core scenario for the cmdlet. For example, WMI returns an enormous amount of data for nearly everything you request. However, you care about different properties for processes than you do for services, logical disks, etc. In that case, you can add a synthetic type name to the objects you return that indicate the view. Then, write types or formatting sections that apply directly to the synthetic type:

PS >$disk = (Get-WmiObject Win32_LogicalDisk)[0]
PS >$disk.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     ManagementObject                         System.Management.ManagementBaseObject

PS >$disk.PsObject.TypeNames
System.Management.ManagementObject#root\cimv2\Win32_LogicalDisk
System.Management.ManagementObject
System.Management.ManagementBaseObject
System.ComponentModel.Component
System.MarshalByRefObject
System.Object

and the corresponding type definition:

<Type>
    <Name>System.Management.ManagementObject#root\cimv2\Win32_LogicalDisk</Name>
    <Members>
        <PropertySet>
            <Name>PSStatus</Name>
            <ReferencedProperties>
                <Name>Status</Name>
                <Name>Availability</Name>
                <Name>DeviceID</Name>
                <Name>StatusInfo</Name>
            </ReferencedProperties>
        </PropertySet>
        <MemberSet>
            <Name>PSStandardMembers</Name>
            <Members>
                <PropertySet>
                    <Name>DefaultDisplayPropertySet</Name>
                    <ReferencedProperties>
                        <Name>DeviceID</Name>
                        <Name>DriveType</Name>
                        <Name>ProviderName</Name>
                        <Name>FreeSpace</Name>
                        <Name>Size</Name>
                        <Name>VolumeName</Name>
                    </ReferencedProperties>
                </PropertySet>
            </Members>
        </MemberSet>
    </Members>
</Type>

Use the PsObject.TypeNames.Add() method to add custom type names to your output object.

The core tenet here is minimizing the amount of back-tracking the user needs to do. When they realize they need additional data, don’t make them re-run the command, specify –Details, and start over. If your cmdlet always emits the information (even if it is hidden by a view,) they can still access it when they want.

One of the biggest accomplishments in getting your private pilot's license is the "Solo Long Cross-Country." It marks the home-stretch of a lot of training, practice maneuvres, landing drills, and solo flights of increasing complexity.

This flight is where it all comes together: 150 nautical miles total, landing at a minimum of 3 airports, with one leg at least 50 nautical miles.

I planned this flight as a tour of the San Juans and airports I have never been. It took me from Renton (RNT,) to Skagit Regional (BVS,) through Orcas Island (ORS,) Friday Harbor (FHR,) Sequim Valley (W28,) and then finally back to Renton.

Cross-country flights all begin with flight planning, and plenty of it.

Once you've drawn your intended route on the sectional chart (making sure to avoid those pesky restricted areas and military operation areas,) you identify (and plan for) checkpoints that fall every 30 miles or so. For each leg of your journey, you calculate the true direction and distance between each checkpoint. You factor in the magnetic deviation for the area (roughly -18 degrees for most of Western Washington,) and then account for the current atmospheric winds. This gives you a magnetic heading by which you can navigate. Add in the distances and estimated ground speed, and you get a navigation method known as "Dead Reckoning."

Dead Reckoning isn't usually the primary form of navigation, however. The modern aviation world is filled with navigation beacons that help you travel along specific paths from beacon to beacon. These are known as VOR Radials. During your preparations, you identify helpful VOR radials and frequencies, and then account for them in your flight plan.

Finally, you research the airports you plan to land at (and some that you don't) for the communication frequencies, runway information, and traffic patterns. Once you've done all that, a completed flight plan looks something like this:

I had originally planned to leave at 9:00 AM on Saturday, but low clouds kept me hampered in for the better part of the morning. Even once the clouds had lifted at Renton, the Orcas Islands were still covered by fairly low cloud.

Once the clouds finally lifted, I departed to the north. I had originally planned use one of Paine Field's VOR radials for much of my journey, but fly over their airspace as to not interfere with traffic there. Clouds kept me below the 4500 feet that I would have needed, so I called Paine Field and got clearance to transition over the field. I followed the radial to Skagit Regional airport, notched up my first landing of the day, and checked off the requirement for a leg of 50+ nautical miles.

The next checkpoint was Orcas Island. I had originally planned to enter the airport from the north of the island, but the weather favoured a northerly landing. I circled, and instead entered the harbour from the south -- easily the prettiest approach of the day.

The landing went smoothly, so I departed and headed to my next destination. Here's a picture of the Orcas Island airport as you leave:

The next landing was at Friday Harbor, a runway I had heard was slightly challenging due to its slope. It proved to be uneventful, so I parked in transient parking and made my way down to the harbour for lunch.

I found a great place right on the harbour -- Downriggers -- and enjoyed an awesome grilled crab and cheese sandwitch. It was also the most expensive meal I had ever had. The bill wasn't so bad, but the commute sure was a killer :)

After leaving Friday Harbor, I climbed to 5,500 ft to fly across the largest span of the journey. Climbing to 5,500 feet gives a glide distance of about 15 nautical miles -- enough to safely make it back to shore should the engine fail part-way.

Once I found Sequim, I got to enjoy my most challenging landing ever. Sequim Valley airport is 40 feet wide, much thinner than the 100-150 feet most regional airports offer. My initial pass at the traffic pattern was much too tight, so I spaced myself again and landed well on the second attempt.

After a short-field takeoff from Sequim Valley, I hugged the coast to avoid a small chunk of prohibited airspace over the Navy's submarine base at Bangor, Washington. I followed that path until I hit my planned VOR radial for the SeaTac airport, and followed that toward Vashon Island.

As you approach Vashon Island, SeaTac airport becomes quickly evident, as does downtown Seattle.

In the left picture, Seattle's Control Tower is about 25% from the left of the picture, about half-way down. Seattle's runways are nearly perpendicular to you at this point.

As you approach Vashon, you contact Seattle Tower to request a transition across their airspace. Transition across this class of airspace is much more restrictive, since it handles such heavy traffic. They give you an exact altitude to fly (usually 1500 feet,) and ask you to cross over the approach-end of the runway. As you cross the runways, you'll continue to see large commercial jets land below you. Since they are landing, you still have 1/4 mile of vertical separation between you. A typical crossing looks like this. It's amazing how simple and clean it looks when you're not battling lineups, security, and crowds.

After crossing the Seattle airspace, you get told to head toward downtown Kent. After a short while, they release you from their radar service, and it's back to landing at Renton. At the end of a 4-hour flight, I had no clue what was in store for me.

After transitioning through the SeaTac airspace and getting to downtown Kent, I called Renton with my intention to land. They told me to come straight-in for runway 33 (basically North,) and that I was clear to land. They asked me to report when I was 2 miles from the end of the runway. As I reported, they said that I was #3, clear to land. I had not heard anybody else talking with the tower or being cleared to land, so I clarified "#3 clear to land?" A second controller corrected that I was #2 clear to land. Still not a surprise you want to get on your final approach. They told me I had traffic at 12:00 on (obviously short) final approach, which I found.

At this point, I’m making the final adjustments, adding the final notch of flaps, watching airspeed, and we’re about 1 mile out.

As I get closer, the traffic ahead of me still hasn’t landed, and still hasn’t started rolling down the runway. In fact, they appear to be stationary on the end of the runway, and at this point I thought I might have lost the original traffic and was instead watching somebody who had stumbled onto the runway in the midst of an incursion. After reflection, I now think that we were on exactly the same glide-slope – causing little-to-no relative movement between us.

As I was now about ½ mile from the threshold (later confirmed by my GPS log,) this was much too close for comfort. I told the tower that we were too close, and started to make a tight spacing turn. The tower got upset, and said that they only had to give 3500 feet of spacing (although ½ mile is 2600 feet by my calculations.) He had somebody on downwind (parallel the runway, about 1 mile east of it, heading toward me) make a left turn for safety, as I did the same. We both saw each other, and fortunately had plenty of room between us. My diversion to the right, and the left turn after that are the first crags in the bottom part of the graphic below:

He then told me to not turn at all, and started to lose control as I complied. These directions left me heading toward the right, so he finally yelled, "What do YOU want to do?" to which I said that I would be doing a "go around" toward the east channel (the upper-right body of water.) After doing that, I entered the traffic pattern like usual (the loop right, and downward,) and then landed uneventfully.

All-in-all, several errors compounded themselves, but it seems to have started with ATC trying to sequence traffic too tightly together. My initial reaction to do a clearing turn was was stupid of me, and was my first Pilot Error. I have no qualms about the decision I made, but do regret the way I decided to do it. I should have just done a go-around – a spacing turn toward the downwind-final direction was dangerous, and easily could have caused problems.

I completed my landing, post-flight checklists, and headed back to base -- completing a huge milestone in my flying journey. Over the next few weeks, I'll be studying like crazy to prepare for the knowledge test and oral grilling that the official flight examiner will give me. Once I feel ready, I'll complete the last 5-or-so hours of practical flying practice and go for my official check ride!

One bit of feedback we frequently get is that PowerShell's learning curve has some steeper bumps than we would like. Or simply, is strongly affected by habits learned from other languages or shells.

Interestingly enough, many of these problems aren't new to us -- we just don't have a good way (aside from help) of exposing them to the user. This was something I touched on in the footnotes of a blog in 2005, and started implementing personally shortly after that. Here's an example of its output:

[C:\temp]
PS:14 > "c:\temp\has space\test.ps1"
c:\temp\has space\test.ps1

Suggestion: Did you mean to run the command in quotes?  If so, try using & "<command>"

The core of this is implemented by a script, Get-TrainingSuggestion.ps1. It retrieves the last item from your history, and runs a bunch of regular expression comparisons against it. If it finds a match in the list of training rules, it outputs the suggestion that corresponds to that rule.

##############################################################################
## Get-TrainingSuggestion.ps1
## Retrieve a training suggestion (if applicable) for the last command
## you typed.
##############################################################################

$history = get-history -Count 1

$suggestions = @{
   "/\?"="To get help on a topic, use -? instead of /?.`nAlternatively, use get-help <command>.";
   ".length"="Try using the .Count property instead of the .Length property.  Although .Length " +
       "often works, .Count is the more consistent way to get the number of objects in a collection.";
   ";[ \t]*$"="Semicolons are not required as line terminators in PowerShell.  Try your command without one.";
   "Regex.*]::Match"="PowerShell's -match evaluator is much more efficent than calling it through the .NET API.";
   "^`".*`"$"="Did you mean to run the command in quotes?  If so, try using & `"<command>`"";
   "start "="Are you trying to run the program associated with that path?  If so, try invoke-item <path>";
   "%.*%"="To access environment variables, try `"`$env:variable`" instead of `"%variable%`"";
   "ren[^ ]* [^ ]+ .*:\.*"="Rename-item takes only a name as its second argument.  Unless you want the " +
       "name to have those path characters, do not include them.";
   "dir.*/s.*"="To get a recursive directory listing, try `"dir . * -rec`".";
   "dir.*/ad"="To get a list of directories, try `"dir | where { `$_.PsIsContainer }`""
   "^get-childitem.*/s.*$"="To get a recursive directory listing, try `"get-childitem . * -rec`".";
   "^grep"="To search files for text patterns, use the Select-String cmdlet.";
}

$helpMatches = ""

if($history)
{
   $lastCommand = $history.CommandLine

   ## Get the suggestions from the baked list
   foreach($key in $suggestions.Keys)
   {
    if($lastCommand -match $key)
    {
        $helpMatches += "`nSuggestion: " + $suggestions[$key]
    }
   }
}

$helpMatches

To use this, simply update your PROMPT function to call Get-TrainingSuggestion.ps1.

function prompt
{
    $suggestion = Get-TrainingSuggestion
    if($suggestion)
    {
        Write-Host $suggestion
        Write-Host
    }

    "PS >"
}

One tension that sometimes arises in the PowerShell community is between the hard-core developers, and hair-on-fire administrators. As a broad technology, this tension and desire for balance drives our design decisions every day.

PowerShell is all about striking a balance between a range of experiences:

• Task oriented, and consumption-only. AKA “Copy and Paste Admin.”
• How do I use PowerShell to restart a computer?
• Problem oriented, and composition-based. AKA “Admin Scripter.”
• How do I collect a log file from a cluster of machines I need to parse out of a web page?
• Technology oriented, and interoperability-focused. AKA “Developer” / ISV
• How do I expose my product’s transacted object model to PowerShell users?

In general, the output of each category empowers the categories that come before it. As a product becomes PowerShell-enabled, admin scripters can then leverage the cmdlets and providers to solve their problems and scenarios. They might blog them, wrap them in a script or module, or otherwise share them. At that point, they become pre-packaged tasks ready for copy and paste.

We tend to walk a fine line with this goal, but I’ve grouped our 100+ new V2 cmdlets into three buckets: Admin, Developer, and Both. Here is what the comparison looks like right now:

PS >gc newcommands.txt | group { $_.Substring(0,1) }
Count Name                      Group
----- ----                      -----
   75 a                         {a Add-BitsFile, a Add-Module, a Checkpoint
   11 d                         {d Add-Type, d Debug-Process, d Export-Prox
   16 b                         {b Complete-PSTransaction, b ConvertFrom-St

Granted, we’ve spilled more blogging ink on the developer and scripting-oriented features (transactions, modules, eventing, etc,) but that’s largely because it will take some time for our SDK and help documentation to catch up.

In addition, PowerShell’s goal is always to soften the learning curve and blur the distinction between the buckets I mentioned earlier. For example, the scripts and functions you’ve come to know and love now have access to all of the power of compiled cmdlets. Or more simply, some scenarios that used to require .NET scripting (random numbers, split and join, etc) now have task-oriented cmdlets or language features.

Now, what about "constructive feedback?" Frequently, we'll find a blog post or comment saying something along the lines of, "PowerShell just isn't admin-friendly." Or, "PowerShell just isn't developer-friendly." Of course, we're always working to make the product better, but that comment is an ideal spot to help ensure we get this right. The best way to help us is to make your feedback constructive, and something we can act on. Tell us why you feel this way, and it has a chance of improving the product. Aimlessly grumble, and it does not.

... Quitting lasts Forever.                     ~ Lance Armstrong

I hadn't heard this before yesterday, but it makes a good quote for the whiteboard!

Once problem that often arises when trying to manage machines is when the management layer itself is the thing you need to diagnose. For example, trying to diagnose Remote Desktop connectivity issues when port 3389 is blocked, or using PowerShell Remoting when WSMAN is misconfigured.

Alternatively, you might not have the client you need to manage the machine -- such as an SSH client, or a version of PowerShell V2 installed.

One way to get around both of these problems is another communication channel. It may be of lower fidelity, but can help you get your job done.

One perfect example of an alternative communication channel is any of the many synchronization tools out there: Live Mesh, Syncplicity, FolderShare, etc. In addition to managing connectivity, they let you broadcast messages (by way of files) between connected computers. Let's use that as our communication protocol:

The core of this experience comes from a PowerShell Mesh Monitor. This script monitors a computer-specific directory for new scripts that appear. When it sees a new script, it processes it, captures the output, and then stores the output in a similarly named file. You can then retrieve the file, review its contents, and continue to manage the system this way:

#requires -version 2.0

## Assuming the script is located in the (Mesh-synched folder)
##    D:\Documents\Mesh
## and the computer name is
##     "MESH-CLIENT"
## We'll monitor D:\Documents\Mesh\Computers\MESH-CLIENT for PowerShell
## scripts to run.
##
## Run this script on any machines that you want listening for scriptable
## Mesh management commands:
##
## powershell -noprofile -file D:\Documents\Mesh\Start-MeshMonitor.ps1
##
## Commands that impact the shell's state (such as current location) are
## persisted for future commands. If you want to share data between scripts
## use global variables.

## Set up the environment
$host.UI.RawUI.WindowTitle = "PowerShell Mesh Monitor"
$myWindowHandle = (Get-Process -Id $pid).MainWindowHandle

## Determine the monitoring directory. Create it if we have to.
$scriptLocation = Split-Path -Parent $myInvocation.MyCommand.Definition
$monitorPath = Join-Path $scriptLocation "Computers\$($env:COMPUTERNAME)"
if(-not (Test-Path $monitorPath))
{
    [void] (New-Item -Type Directory $monitorPath -Force)
}

## Create a P/Invoke type that gives us access to the window
## management functions (show / hide)
$windowUtils = Add-Type -memberDefinition @"
[DllImport("user32.dll")]
public static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);
"@ -name "Win32ShowWindowAsync" -namespace Win32Functions -passThru

## Hide ourselves
[void] $windowUtils::ShowWindow($myWindowHandle, 0)

Set-Location $monitorPath

## Continuously go through all PowerShell scripts in the drop location,
## run them, and store their output back in the drop location.
while($true)
{
    ## Show the window if they create a file called "SHOW"
    if(Test-Path SHOW)
    {
        [void] $windowUtils::ShowWindow($myWindowHandle, 1)
        Remove-Item SHOW
    }
    
    foreach($inputFile in Get-ChildItem $monitorPath -Filter *.ps1 | Sort LastWriteTime)
    {
        $script = $inputFile.FullName
        "Processing input script $script"

        & { trap { $_; continue }; & $script } > "$script.output.txt" 2>&1 
        Move-Item $script "$script.processed"
    }

    Start-Sleep 1
}

With file synchronization as a back-end, you can now write a thin remoting client in nearly any language, and nearly any OS -- as long as it can read and write files, and is supported by your file synchronization client. Taking this same approach, you could also use email, FTP, web pages, or nearly anything else as a communication mechanism.

On top of that, you might want to build a primitive interactive remoting experience. Once Live Mesh completes their Windows Mobile client, I'll be doing that ASAP. Here's a PowerShell script that demonstrates the approach:

## Assuming the script is located in the (Mesh-synched folder)
##    D:\Documents\Mesh
## and the computer name is
##     "MESH-CLIENT"
## We'll drop scripts in D:\Documents\Mesh\Computers\MESH-CLIENT and
## process the resulting output files.
##
## Commands that impact the shell's state (such as current location) are
## persisted for future commands. If you want to share data between scripts
## use global variables.

param($computerName)

## If they specified a computer name, change to that directory
if($computerName)
{
    $scriptLocation = Split-Path -Parent $myInvocation.MyCommand.Definition
    $monitorPath = Join-Path $scriptLocation "Computers\$computerName"
    if(-not (Test-Path $monitorPath))
    {
        throw "$computerName does not have a Mesh Monitor directory"
    }
    
    Set-Location $monitorPath
}


$remotePromptText = "[MESH/$(Split-Path . -Leaf)] PS >"

## Invoke a command and retrieve its output
function InvokeCommand($command)
{
    $filename = [GUID]::NewGuid().ToString() + ".ps1"
    $outputFilename = "$filename.output.txt"
    $processedFilename = "$filename.processed"
    
    $command > $filename
    while(-not (Test-Path $processedFilename)) { Start-Sleep -m 100 }
    while(-not (Test-Path $outputFilename)) { Start-Sleep -m 100 }
    
    Get-Content $outputFilename

    ## Clean up our temporary files
    Remove-Item $outputFilename
    Remove-Item $processedFilename
}

## Get a command from the user, invoke it, and display
## the results
while($true)
{
    Write-Host -NoNewLine $remotePromptText
    $command = $host.UI.ReadLine()

    if($command -eq "exit")
    {
        break
    }
    
    InvokeCommand ($command + " | Out-String -Width $($host.UI.RawUI.BufferSize.Width - 1)")
}

If you have a PowerShell script that you are calling from cmd.exe, you might run into the following error:

Write-Host : The OS handle's position is not what FileStream expected. Do not use a handle simultaneously in one FileStream and in Win32 code or another FileStream. This may cause data loss.

This is bug in PowerShell, and happens when:

• a PowerShell command generates both regular and error output
• you have used cmd.exe to redirect the output to a file
• you have used cmd.exe to merge the output and error streams

For example:

PowerShell -Command '"start"'; Write-Error "Foo"; '"end"' > c:\temp\redirect.log 2>&1

One workaround is to use Start-Transcript for file logging (rather than cmd.exe) or have PowerShell do the error stream redirection.

However, if you don't have control over your logging, you can add the following snippet to any scripts that get launched this way.

Note: this is an unsupported workaround. It will almost definitely break as future versions of PowerShell are released.

V1

$bindingFlags = [Reflection.BindingFlags] "Instance,NonPublic,GetField"
$consoleHost = $host.GetType().GetField("externalHost", $bindingFlags).GetValue($host)
[void] $consoleHost.GetType().GetProperty("IsStandardOutputRedirected", $bindingFlags).GetValue($consoleHost, @())
$field = $consoleHost.GetType().GetField("standardOutputWriter", $bindingFlags)
$field.SetValue($consoleHost, [Console]::Out)

V2 CTP2

$bindingFlags = [Reflection.BindingFlags] "Instance,NonPublic,GetField"
$objectRef = $host.GetType().GetField("externalHostRef", $bindingFlags).GetValue($host)

$bindingFlags = [Reflection.BindingFlags] "Instance,NonPublic,GetProperty"
$consoleHost = $objectRef.GetType().GetProperty("Value", $bindingFlags).GetValue($objectRef, @())

[void] $consoleHost.GetType().GetProperty("IsStandardOutputRedirected", $bindingFlags).GetValue($consoleHost, @())
$bindingFlags = [Reflection.BindingFlags] "Instance,NonPublic,GetField"
$field = $consoleHost.GetType().GetField("standardOutputWriter", $bindingFlags)
$field.SetValue($consoleHost, [Console]::Out)

How does this work, and why does this happen in the first place? When PowerShell sends output to its output stream the first time, it keeps a reference to the output stream for future use. However, this output stream is really a wrapper around a lower-level stream. When cmd.exe writes to the output stream, it writes to the lower-level stream. This makes the .NET wrapper complain that the underlying stream has changed from beneath it.

This workaround modifies some private engine state to not keep a reference to the output stream -- but instead to re-examine the output stream on every use.