Create Disk Usage Reports with PowerShell and WizTree

Recently I discovered a neat little utility called WizTree, which can be used to report on space used by files and folders on a drive. There are many utilities out there that can do that, but this one supports running on the command line which makes it very useful for scripting scenarios. It also works extremely quickly because it uses the Master File Table on disk instead of the slower Windows / .Net methods.

I wanted to create a disk usage report for systems that have less than 20GB of free space – the recommended minimum for doing a Windows 10 in-place upgrade – so that I can easily review it and identify files / folders that could potentially be deleted to free space on the disk. I wanted to script it so that it can be run in the background and deployed via ConfigMgr, and the resulting reports copied to a server share for review.

The following script does just that.

First, it runs WizTree on the command line and generates two CSV reports, one each for all files and folders on the drive. Next, since the generated CSV files contain sizes in bytes, the script imports the CSVs, converts the size data to include KB, MB and GB, then outputs to 2 new CSV files.

The script then generates 2 custom HTML reports that contain a list of the largest 100 files and folders, sorted by size.

Next it generates an HTML summary report that shows visually how much space is used on the disk and tells you how much space you need to free up to drop under the minimum 20GB-free limit.

Finally, it copies those reports to a server share, which will look like this:


The Disk Usage Summary report will look something like this:


And here’s a snippet from the large directories and files reports:



There are also CSV reports which contain the entire list of files and directories on the drive:


To use the script, simply download the WizTree Portable app, extract the WizTree64.exe and place it in the same location as the script (assuming 64-bit OS).  Set the run location in the script (ie $PSScriptRoot if calling the script, or the directory location if running in the ISE), the temporary location where it can create files, and the server share where you want to copy the reports to. Then just run the script in admin context.

PowerShell One-liner to Extract a Windows 10 Upgrade Error Code

Short post – here’s a PowerShell one-liner that will extract the upgrade code from the setupact.log generated by a Windows 10 upgrade. It includes both the result code and the extend code. You could include this in an in-place upgrade task sequence with ConfigMgr to stamp the code to the registry, or WMI, or create a task sequence variable etc.

(Get-Content -ReadCount 0 -Path "$env:SystemDrive\`$Windows.~BT\Sources\Panther\setupact.log" |
    Out-String -Stream |
    Select-String -SimpleMatch "MOUPG  SetupHost: Reporting error event").ToString().Split('>')[1].Replace('[','').Replace(']','').Trim()

Here’s an example containing the code for happiness, 0xC1900210, 0x5001B 🙂



Find Windows 10 Upgrade Blockers with PowerShell

This morning I saw a cool post from Gary Blok about automatically capturing hard blockers in a Windows 10 In-Place Upgrade task sequence. It inspired me to look a bit further at that, and I came up with the following PowerShell code which will search all the compatibility xml files created by Windows 10 setup and look for any hard blockers. These will then be reported either in the console, or you can write them to file where you can copy them to a central location together with your SetupDiag files, or you could stamp the info to the registry or a task sequence variable as Gary describes in his blog post. You could also simply run the script against an online remote computer using Invoke-Command.

The script is not the one-liner that Gary likes, so to use in a task sequence you’ll need to wrap it in a package and call it.

The console output looks like this:


You should remove the FileAge property if using it in a task sequence as that’s a real-time value and is a quick indicator of when the blocker was reported.

If you use my solution here for improving the user experience in an IPU, you could also report this info to the end user by adding a script using my New-WPFMessageBox function, something like this…

$Stack = New-Object System.Windows.Controls.StackPanel
$Stack.Orientation = "Vertical"

$TextBox = New-Object System.Windows.Controls.TextBox
$TextBox.BorderThickness = 0
$TextBox.Margin = 5
$TextBox.FontSize = 14
$TextBox.FontWeight = "Bold"
$TextBox.Text = "The following hard blocks were found that prevent Windows 10 from upgrading:"


Foreach ($Blocker in $Blockers)
    $TextBox = New-Object System.Windows.Controls.TextBox
    $TextBox.BorderThickness = 0
    $TextBox.Margin = 5
    $TextBox.FontSize = 14
    $TextBox.Foreground = "Blue"
    $TextBox.Text = "$($Blocker.Title): $($Blocker.Message)"

$TextBox = New-Object System.Windows.Controls.TextBox
$TextBox.BorderThickness = 0
$TextBox.Margin = 5
$TextBox.FontSize = 14
$TextBox.Text = "Please contact the Helpdesk for assistance with this issue."


New-WPFMessageBox -Title "Windows 10 Upgrade Hard Block" -Content $Stack -TitleBackground Red -TitleTextForeground White -TitleFontSize 18

…which creates a message box like this:


Thanks to Gary and Keith Garner for the inspiration here!

Fix Http 500.19 Error after Removing WSUS

This post is more of a ‘note to self’ for troubleshooting IIS errors.

Recently I decided to remove the WSUS role from an SCCM distribution point as it was previously being used for patching during OSD, but now we patch only the reference image instead. After removing the WSUS role, I also did some cleanup including deleting the WSUS_Updates directory, the %Program Files%\Update Services directory and removing the WsusPool website and application pool from IIS.

After that, clients using that distribution point failed to get content for packages, returning an Http 500 error:


Checking the IIS log on the distribution point I found the following corresponding entry:


The error code is 500.19 which translates to ‘Internal Server Error / Configuration data is invalid‘ and is documented in more detail in this Microsoft article. A further clue is found in the 126 windows error code, which translates to ‘The specified module could not be found‘.

Browsing to the website directly, ie http://localhost/SMS_DP_SMSPKG$, gave the following information:


The error code 0x8007007e is the same as the windows error code 126 and also means ‘The specified module could not be found”. The module referenced in the error is the DynamicCompressionModule.

To get more detailed information on the error, I decided to enable Failed Request Tracing in IIS and log the 500.19 error. The process for enabling and using Failed Request Tracing is nicely summarised here as well as documented by Microsoft here. Using that, I found that a couple of modules were being referenced that were no longer present.


Following a hint from here, I checked the applicationHost.config file and found a reference to a dll in the %Program Files%\Update Services directory that was installed with WSUS and that I deleted after removing the WSUS role:

<scheme name="xpress" doStaticCompression="false" doDynamicCompression="true" dll="C:\Program Files\Update Services\WebServices\suscomp.dll" staticCompressionLevel="10" dynamicCompressionLevel="0" />

To remove the reference, I ran the following command as admin:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name='xpress']

You can find more info on IIS modules and how to add/remove/disable/enable here.

After removing the reference to the xpress schema and restarting the W3SVC service, everything was back to normal 🙂

Using Windows 10 Toast Notifications with ConfigMgr Application Deployments

When deploying software with ConfigMgr, the ConfigMgr client can create a simple “New software is available” notification to inform the user that something new is available to install from the Software Center. But this notification is not overly descriptive. You might wish to provide a more detailed notification with a description of the software, why the user should install it, the installation deadline etc. For Windows 10, we can do that simply by disabling the inbuilt notifications on the deployment and creating our own custom toast notifications instead.

The Notification

Consider the examples below.

Here I have created a simple toast notification with the name of the software, what it does, what it is needed for, and a simple instruction to close Outlook before installing. The user can then choose to install it now – and clicking on that button will simply open the Software Center to that application via it’s sharing link. If they click Another time… the notification goes away for now, and if they dismiss it, it will move to the Action Center.

Title Only

In this version, I’ve added a logo instead of a title…

Image Only

…and in this version, I’ve added both.

Title and Image

If the deployment has a deadline, you can state the deadline in the notification as well as tell the user how long they have left before the deadline is reached.

Image with Deadline

Clicking Install now opens that app in the Software Center where the user can go ahead and install it…

Software Center

The big gotcha (for now) is that this only works with Application deployments, and you need to be running ConfigMgr 1706 or later. Please, Microsoft, make sharing links possible for other deployments (packages/programs, task sequences) too!

The client machines also need to be running Windows 10 Anniversary Update or later for the notification to work properly.

The Magic

So how does this work? Well, first we need to disable the inbuilt notifications on the application deployment, so set that to Display in Software Center, and only show notifications for computer restarts in the deployment type on the User Experience tab.

Next, we create a compliance item and compliance baseline which will display the notification. Target the compliance baseline at the same collection/s you are targetting your application.

The compliance item will have a PowerShell discovery script and remediation script. The discovery script will simply detect whether the software has been installed and report compliance if it is. The remediation script contains the code that displays the notification, and will only run if the discovery script does not report compliance, ie the software is not yet installed.

The Code

For the discovery script, create some code that will detect whether the software is installed. For my example, I used the code below which simply checks for the existence of a registry key.

## Discovery script for Veritas Enterprise Vault Outlook Add-in (x64)

$RegKey = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{0DBA46D1-5D49-4888-BC50-D3DF38F85126}"
If (Test-Path $RegKey)
    "Not compliant"

It’s important that the script outputs a value whether it’s compliant or not, so you don’t get issues with the instance not being found.

For the remediation script, I created the following code to display a toast notification:

Code Walkthrough

Let’s walk through the code to explain the variables and what it does.


Title is the notification title that displays more prominently, the name of the software for example.

SoftwareCenterShortcut is the sharing link from your ConfigMgr application. To get this, you simply deploy the application to a machine, go to the Software Center, open the application and in the top-right click the link and copy and paste the link as the variable value.

AudioSource is the sound that displays when the notification appears. There are various options here, see the reference in the script for more info.

SubtitleText and BodyText contain the main wording in the notification.

HeaderFormat is a choice of either:

  1. TitleOnly – this just displays a title in the notification header
  2. ImageOnly – this just displays an image in the notification header
  3. TitleAndImage – this displays both

Base64Image – if you wish to include an image or a logo, use this optional variable. You need to convert an image file to a base64 string first, and code is included in the script for how to do that. You can output the base64 string to a text file and copy and paste it back into the script in this variable.

The reason for encoding the image is simply to avoid any dependencies on files in network locations, setting directory access or requiring internet access. The script will convert the base64 string back to an image file and save it in the user’s temporary directory.

Deadline is an optional parameter. If your deployment has a deadline, you probably want to include that in the notification. Deadline should be a parseable datetime format.

What the Script Does

The script will register PowerShell in the HKCU registry as an application that can display notifications in the Action Center, if it isn’t registered already.

Next it defines the toast notification in XML format. I chose XML to avoid any dependencies on external modules, and it’s actually quite simple to create a notification that way. The schema for toast notification is all documented by Microsoft and you can find a reference in the script.

Next it manipulates the XML a bit depending on whether you chose to display an image or use a deadline etc.

Finally, the notification is displayed.


The notification uses the reminder scenario so that it stays visible on the screen until the user takes action with it. If this is undesirable, you can change it to a normal notification with either the standard or longer duration. In this case, you need to be sure that the text in the notification can be read in that time frame.

In the toast template XML definition, change the first line from:

<toast scenario=”reminder”>

to either (default duration 5 seconds)

<toast duration=”short”>

or (around 25 seconds)

<toast duration=”long”>

Creating the Compliance Item and Baseline

When creating the compliance item in SCCM, make sure of the following:

  • Supported platforms – should be Windows 10 only. Actually, I have used some features in toast notifications that are only available in the Anniversary Update and later, so don’t target versions less than.
  • User context – make sure the compliance item has the option Run scripts by using the logged on user credentials checked
  • Compliance rule value – the value returned by the script should equal “Compliant
  • Compliance rule remediation – make sure that Run the specified remediation script when this setting is noncompliant is checked

When creating the deployment for the compliance baseline in SCCM, make sure of the following:

  • Remediate noncompliant rules when supported is checked
  • Allow remediation outside the maintenance window is checked (if that is acceptable in your environment)


This is a handy way to create your own notifications for ConfigMgr application deployments in Windows 10 and is fully customizable per application, within the limits of the toast notification schema. If and when Microsoft make sharing links available for task sequences, or packages and programs too, this would become even more useful, for example, sending a custom notification when a Windows 10 version upgrade is available.

Simplify Resolving Windows 10 Upgrade Errors with SetupDiag and ConfigMgr

A few weeks ago Microsoft released a handy tool to help diagnose issues with Windows 10 upgrades called SetupDiag. The tool basically analyzes the Windows Setup logs against known issues and reports it’s findings in a log file. Troubleshooting Windows 10 setup is not the most fun activity, so using this tool certainly makes the process easier. To make it easier still, we can run it using SCCM, either standalone, or as part of a Windows 10 Upgrade task sequence.

Below is a simple PowerShell script wrapper that can be used to run the tool. It checks that the requirement of .Net 4.6 has been met then runs the tool, logging to the location you specify. In this example I am logging the results to the CCM Logs directory for convenience. It creates a file called Setupdiagresults.log and an archive called containing the Windows setup logs used.

Download the SetupDiag utility from here, and create a package in SCCM containing both SetupDiag.exe and the PS script in the same directory.

Add a Run PowerShell Script step to your task sequence and reference the package you created.


Here’s an example log file output from a successful upgrade: