For those using a x64 Windows OS, you may find that many times you still need to use the x86 version of Powershell due to snapin compatibilities. Have you ever noticed that a number of native (dos/command prompt) commands are only available as 64 bit EXEs and not immediately available from your x86 Powershell session? Some examples are nbtstat.exe, telnet.exe, tscon.exe, tsdiscon.exe, and query.exe. Somewhat annoying.

I’m not going to go into details about all the fun of API call thunking or Windows-On-Windows (WoW), because frankly… I don’t care. I just want to run nbtstat.exe from my x86 version of Powershell!

Fortunately, there is a way to access these elusive 64 bit EXEs. Add %systemroot%\sysnative to your PATH. Here’s a small snippet you can add to your profile.ps1 that will add this folder to the end of the path for your Powershell session.

Version 2 Code: (see Version 1 variant below)

if ( (Test-Path "$($env:systemroot)\sysnative") -and ($env:path -split ';' -notcontains "$($env:systemroot)\sysnative") ) { 
    $env:path = "$($env:path);$($env:systemroot)\sysnative" 
    Write-Host "Path updated to include: $($env:systemroot)\sysnative"
} 

I added in checks to make sure the sysnative exists (it won’t under a x64 process, only x86 processes) and that it’s not already in the path to avoid duplication.

One caveat. %systemroot%\sysnative redirection only works on Vista, Windows 2008, or Windows 7. XP and 2003 are a bit in the cold on this one (although there is hotfix KB942589 to add sysnative to Windows 2003 – but I’ve not tested it).

 ** Alexandair pointed out that I used -split operator which requires Powershell v2. The following works in v1 and v2:

if ( (Test-Path "$($env:systemroot)\sysnative") -and (($env:path).split(';') -notcontains "$($env:systemroot)\sysnative") ) {
    $env:path = "$($env:path);$($env:systemroot)\sysnative"
    Write-Host "Path updated to include: $($env:systemroot)\sysnative"
}

Gaurhoth

Maybe it's senility, but I sure don't remember MS pushing a new Server OS quite as hard as they seem to be with Windows 2008. System Center Virtual Machine Manager 2008 Beta and the new ISA portion of Forefront Stirling both require Windows 2008. Given that Windows 2008 is brand spanking new, this surprises me. I can remember using Windows 2000 for several years after 2003's release and most everything worked just fine with it.

Ah well. I'm particularly saddened by SCVMM 2008's reluctance to embrace Server 2003. I understand part of it's mission is to support Hyper-V but that's a small piece of the entire VMM package.

gaurhoth