Change a PowerShell Preference Variable to Reveal Hidden Data

Summary: Change the $FormatEnumerationLimit Windows PowerShell preference variable and display more data in the console.


Microsoft Scripting Guy Ed Wilson here. It is approaching the holiday season in Charlotte, North Carolina, in the United States. From now until the middle of January, 2012, many companies are on “IT lockdown” and are not making any changes. In fact, for many companies, they have been on IT lockdown for more than a month. There are several reasons for this lockdown: One reason is because of the number of people taking their vacation during the months of November and December. Another reason is because of the number of year-end reports that need to run during this time of the year. As a result of the critical reports that run, many companies do not want to risk anything adverse happening to their IT infrastructure, so they freeze any changes until after the new year.

One big advantage of having an IT lockdown towards the end of the year is it provides time for IT pros to take advantage of either formal or informal training opportunities. Labs are built, scenarios are tested, and much learning takes place.

At the Scripting Household, we are also in IT lockdown mode, and the Scripting Wife is ensuring no unplanned outages occur because of infrastructure changes. This also means I have time to experiment and to learn new things.

I recently found something in the Windows PowerShell help files I had either not previously noticed or had forgotten. I was reading the about_Preference help topic. What I found is the $FormatEnumerationLimit preference variable. By default the $FormatEnumerationLimit preference variable has a value of 4, and it determines how many items are displayed when a property contains more than a single item.

To obtain the current $FormatEnumerationLimit, I directly query the variable. In the following figure, I query the $FormatEnumerationLimit. Next, I use the Get-Service cmdlet to return information about all services that begin with the letters win. I first pipe the results to the Format-Table cmdlet and choose the name and the dependentServices property. I use the autosize parameter to tighten up the display. Next, I repeat the command and pipe the results to the Format-List cmdlet. In both cases, there is plenty of room in the Windows PowerShell console window to display additional DependentServices, but the space is not utilized because the number of items enumerated is limited to four, which is the default setting of the $FormatENumerationLimit preference variable. The three commands are shown here:


get-service -Name win* | format-table name, dependent* -AutoSize

get-service -Name win* | format-list name, dependent*

The commands and associated output are shown in the following figure.

Image of commands and associated output

I change the value of the $FormatEnumerationLimit variable to 20. Next, I retry my two Get-Service commands. The three commands are shown here:

$FormatEnumerationLimit = 20

get-service -Name win* | format-table name, dependent* -AutoSize

get-service -Name win* | format-list name, dependent*

The commands and associated output are shown in the following figure.

Image of commands and associated output

When $FormatEnumerationLimit is set to the default value of 4, a command to retrieve all processes that begin with the letter w; sort based upon pagedmemorysize; and display a table containing the name and all properties that begin with the letters page; and the threads fit neatly in a table. The problem is that the threading information truncates after four thread values. The command is shown here:

Get-Process w* | sort pagedmemorysize | ft name, page*, threads -Wrap –AutoSize

The command and associated output are shown in the following figure.

Image of command and associated output

When the same command runs with the $FormatEnumerationLimit set to 20, the output spreads out more. The advantage is that all the thread IDs appear in the output.

Image of thread IDs in the output


Well, this is the easy way to see behind the ellipsis in some of the output. I do not think I will add the command to my profile, but it is definitely something to keep in mind when I want to see more output, but I do not want to use the Select-Object –expandproperty command. I will see you tomorrow when I begin a new week on the Hey, Scripting Guy Blog!

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy


Comments (3)

  1. srikanth says:

    Very interesting, that is why one needs to read the help files, I guess 🙂

  2. Klaus Schulte says:

    Hi Ed,

    this is something most users might not know.

    The details are often hidden in the manuals or help files as Srikanth said.

    If you look over all the different powershell blogs and articles you will find lots of burried goodies, that powershell offers "behind the scenes".

    Maybe you'll have to write a new book about the "Secrets of the Powershell Ninjas" 🙂

    But, as the WMF3-CTP1 is already out, I expect that you will be writing a book about "Powershell 3" pretty soon …


  3. Eva B says:

    Hi, thanks for the info. I have set this variable in my powershell script and my script runs everyday based on a windows scheduled task. When the scheduled task runs, my script produces a text file but it still truncates some of the data even though I
    had set $FormatEnumerationLimit = -1 (unlimited). I have also tried $FormatEnumerationLimit = 80. Still didn’t work. I even tried $global:FormatEnumerationLimit = 80 because I saw another thread where there is a bug with this variable and it needs to be declared
    globally (not in a function) in order for it to work.

    One thing I noticed however is that when I run the script manually (logged into the server as myself), the XML does not get truncated. It’s only when the script runs through the scheduled task (using a different service user with admin rights) that some of
    the data is truncated.

    Have you every heard of this before? Or maybe can help me to understand why it works when run manually but not through the scheduled task?

    My code is below:

    The code I am not showing is that I connect to an Oracle database to run a select statement to get the data I need to write to a file.

    # In order to output to a file we need to fill a dataset table
    $DataSet = New-Object System.Data.DataSet
    $nRecords = $OracleAdapter.Fill($DataSet)

    #Export Dataset Table to a text file
    $FormatEnumerationLimit = 80
    $DataSet.Tables[0] | Out-File $rcvrFileName

    # Remove header and lines 2 and 3 from file and re-save it
    $file = Get-Content $rcvrFileName | Select-Object -Skip 3
    Set-Content $rcvrFileName -Value $file


Skip to main content