PowerShell's Noble Blue

Once in awhile, you'll see a PowerShell screenshot that is still black and boring like the traditional cmd.exe prompt. Other times, you'll see the fancy blue window you've come to love. Why the difference? And if you're suffering from black window syndrome, what can you do about it?


Before shipping Version 1, our marketing and design teams set to make the PowerShell window a unique and marquee experience. What form did this take?

  • Blue. Specifically, Red: 1, Green: 36, Blue: 86. -- In hex, 012 456. That number is much too cool to be a coincidence, but I haven't done the social archeology to find out why 🙂
  • Lucida Console. Lucida Console is infinitely more readable than the raster fonts, and ships with all versions of Windows. Consolas is a beautiful alternative, but isn't broadly available.
  • Window Size. Long gone are the days of 640x480 monitors being the most common, so PowerShell's default window gives about 800x600 of usable space.
  • Screen Buffer. Likewise, long gone are the days of 256mb of memory being the most common, so PowerShell's default window gives a dreamy 60 pages of history buffer. This is a shell you want to live in. And when you live in a shell, you  want to be able to see what you've done.
  • Quick Edit. Quick Edit mode lets you copy and paste easily to and from the console window. It is the setting that most console users enable once they realize it exists, and long gone are the days of mouse-driven console applications.

Now, even with all of these improvements, you still see screen shots of PowerShell prompts blinking desolate in the confines of a traditional black console window. Why is this?

PowerShell customizes its window through the shortcut properties in its Start Menu link. When you launch PowerShell through the Start | Run dialog or some other app launcher, these shortcut properties don't apply. Surprisingly, Windows does not support a mechanism to make these console customizations machine-wide. Windows supports per-user console customizations in the the HKCU hive of the registry, but there's usually no "Current User" during a PowerShell install. And even if there were, any customizations would not apply to user accounts created after PowerShell was installed.

So how do you get PowerShell's Noble Blue if you prefer Start | Run? Here's a script from the PowerShell Cookbook that does exactly that -- for your current user account.:

## From Windows PowerShell, The Definitive Guide (O'Reilly)
## by Lee Holmes (

Set-Location HKCU:\Console
New-Item ".\%SystemRoot%_system32_WindowsPowerShell_v1.0_powershell.exe"
Set-Location ".\%SystemRoot%_system32_WindowsPowerShell_v1.0_powershell.exe"

New-ItemProperty . ColorTable00 -type DWORD -value 0x00562401
New-ItemProperty . ColorTable07 -type DWORD -value 0x00f0edee
New-ItemProperty . FaceName -type STRING -value "Lucida Console"
New-ItemProperty . FontFamily -type DWORD -value 0x00000036
New-ItemProperty . FontSize -type DWORD -value 0x000c0000
New-ItemProperty . FontWeight -type DWORD -value 0x00000190
New-ItemProperty . HistoryNoDup -type DWORD -value 0x00000000
New-ItemProperty . QuickEdit -type DWORD -value 0x00000001
New-ItemProperty . ScreenBufferSize -type DWORD -value 0x0bb80078
New-ItemProperty . WindowSize -type DWORD -value 0x00320078

2 Responses to “PowerShell's Noble Blue”

  1. DK writes:

    In case anybody else gets confused by this…

    At first when I saw %SystemRoot% I thought that I was to replace that with c:_Windows (or whatever your local path to Windows is).

    Not at all the case; %SystemRoot% is not only valid for the registry key, it seems to be required. Changing it back and forth betwen C:_Windows and %SystemRoot% is the difference between this working and not working.

  2. Marc C writes:

    Familiarize yourself with this and other Environment Variables that are at your disposal in your Windows OS:


    …and last but definitely not least

    $0.02 — of course, most users looking to really “get wild” with PowerShell will already know this. 😉

Leave a Reply