Hey, Scripting Guy! How can I expand the width of the Windows PowerShell console? When I display certain kinds of data – like information from the event logs – that data gets cut off because the console window isn’t wide enough.

— TB

Hey, TB. Wow, what a coincidence: we were just about to ask you that very same question! Now what do we do?

No, just kidding: the Scripting Guys never ask anyone for help. Not that we couldn’t use help, mind you; it’s just that, when you work at Microsoft, you quickly learn never to ask anyone anything.

Is that because they might give you the wrong answer? We wish; after all, a wrong answer is at least an answer. No, ask a Microsoft person a question and, instead of giving you an answer, they’ll decide to set up a meeting to talk about the issue. In turn, they’ll go back to their office, notify their manager and your manager (and all the managers’ managers as well as their managers) of the question, then invite scores of “key stakeholders” to attend this suddenly-crucial meeting.

Which, by the way, will often be scheduled for a ridiculous hour like 6:00 PM. (Who the heck wants to be at work at 6:00 PM?) And, of course, they won’t actually schedule the meeting; instead, they’ll send everyone a “Sched+”, Sched+ being a reference to a Microsoft product (Schedule+) that was last used in 1847. But the memory lingers on.

After the meeting has been postponed several times, then moved to several different conference rooms, everyone finally gets together, with the only item on the agenda being this: should we go ahead and schedule another meeting or not? After several such false starts we’ll eventually set up a “virtual team” that assigns “action items” to the key stakeholders. (We use a lot of quotation marks here at Microsoft, don’t we?) We’ll then spend several months drawing up policies and procedures for how to best address the question. And then, just before we’re ready to come up with an answer, we’ll decide that maybe we don’t really “own” the question after all, and agree that someone else should provide the answer.

And yes, let’s hope that your original question wasn’t “Where’s the bathroom?”

But things are very different when you ask the Scripting Guys a question. Granted, they probably won’t give you an answer, either. But at least there won’t be any paperwork or meetings involved:

$pshost = get-host
$pswindow = $pshost.ui.rawui
$newsize = $pswindow.buffersize
$newsize.height = 3000
$newsize.width = 150
$pswindow.buffersize = $newsize
$newsize = $pswindow.windowsize
$newsize.height = 50
$newsize.width = 150
$pswindow.windowsize = $newsize

Before we go much further we should note that you don’t have to use a script to change the size of the Windows PowerShell console window. Instead, you can always do this:

That works just fine. But you’re right: that is kind of boring, at least for a scripting column. Therefore, we’ve given you a programmatic way to modify the size of the current Windows PowerShell console. And, as an added bonus, before we’re done we’ll show you how to change the window title and window colors as well.

No thanks necessary; turns out that was an action item that the Scripting Guys, as key stakeholders, agreed to do.

As for the script itself, we start out by creating an object reference (named $pshost) to the Windows PowerShell console object; that’s something we do by calling the Get-Host Cmdlet:

$pshost = get-host

We then use this line of code to create a reference to the console’s UI.RawUI child object:

$pswindow = $pshost.ui.rawui

Now we need to take a brief detour. On our test computer both the Windows PowerShell screen width and the buffer size are set to 120. Does that matter? Yes, it does: you can’t have a screen width that’s bigger than the buffer size. Therefore, before we can increase our window size we need to increase the buffer size. That’s what this block of code does:

$newsize = $pswindow.buffersize
$newsize.height = 3000
$newsize.width = 150
$pswindow.buffersize = $newsize

It’s a tad bit confusing, but what we’re really doing here is constructing a brand-new buffer size in memory, then applying the properties of that virtual buffer to the actual console window. To do that we first assign the BufferSize properties to a variable named $newsize:

$newsize = $pswindow.buffersize

After we’ve done that we set the values of the buffer size Height (3000 lines, the default value) and Width (150 characters). We then use this line of code to assign these values to the actual console window:

$pswindow.buffersize = $newsize

With the buffer size adjusted we then repeat the process with the WindowSize property, giving our new window a Height of 50 lines and a Width of 150 characters:

$newsize = $pswindow.windowsize
$newsize.height = 50
$newsize.width = 150
$pswindow.windowsize = $newsize

Run the script and your Windows PowerShell window will instantly resize itself. (Although we should note that the effect is temporary: the window will revert to its previous size should you close this session and restart it. To permanently change the size of the window you can, among other things, use the UI to change the window properties or put this script in your PowerShell profile.)

Now, as promised, here’s some bonus code that will change the title of the console window (to My PowerShell Session) as well as the foreground and background colors (yellow text on a black background). We won’t discuss the whys and wherefores of the bonus code, but you can probably figure it out on your own (hint: see this article for more information on the colors available to you when configuring the PowerShell UI):

$pshost = get-host
$pswindow = $pshost.ui.rawui
$pswindow.windowtitle = "My PowerShell Session"
$pswindow.foregroundcolor = "Yellow"
$pswindow.backgroundcolor = "Black"
cls

See, what did we tell you? With the Scripting Guys you not only get the answer to your question, but you also get answers to questions you didn’t even ask!

Of course, in all fairness, we should point out that the Scripting Guys tend to exaggerate a little when it comes to discussing life here at Microsoft. Needless to say, questions do get answered around here, all the time.

Or at least that’s what they told us at our last virtual meeting, where we agreed – sometime after the holidays, of course – to get together and try to decide whether or not we should try to make decisions in the future.

Well, not this year, of course, but during the next fiscal year.

We’ll keep you posted.