Skip to main content

· 2 min read

This script uses an undocumented Microsoft 365 API to check the latest version of Microsoft Office / 365 Apps and compares it to the installed version. It then sets a custom field in NinjaOne to indicate whether the latest security release (if there is one) is installed. It also sets fields to indicate the channel, installed version, update status and a card containing more detailed information.

Thanks to:
security

This article uses an undocumented API to check the latest version of Microsoft Office / 365 Apps. This API is subject to change without notice and may stop working at any time. Use at your own risk.

Creating Fields

Creating custom fields in NinjaOne
To create a custom field in NinjaOne go to Administration > Devices and select either Role Custom Fields or Global Custom Fields then select Add.

  • Role Custom Fields are custom fields that are specific to a device role.
  • Global Custom Fields are custom fields that are applicable to all devices and/or to a location and/or organisation
Make sure you add the fields to the roles you want to use them in at Administration > Devices > Roles (for role custom fields).

When you create your custom field you need to make sure that you set the Scripts permission to ensure that you can read or write to the field from your scripts - as appropriate for the script you're using.

We're adding one role custom field for devices with the Windows Desktop or Laptop and/or Windows Server role, note that we've customised slightly the autogenerated machine name here, if you use the default adjust the field name in the script appropriately.

Field LabelField NameField TypeDescription
M365 Apps Installed VersionofficeInstalledVersionTextThe installed version of Microsoft Office / 365 Apps.
M365 Apps ChannelofficeChannelTextThe channel of Microsoft Office / 365 Apps.
M365 Apps Update StatusofficeUpdateStatusTextThe update status of Microsoft Office / 365 Apps.
M365 Apps SecureofficeSecureCheckboxWhether the latest security (or other) release is installed.
M365 Apps DetailofficeDetailWYSIWYGA card containing more detailed information about Microsoft Office / 365 Apps.

The Script

Detect-CVE202430103.ps1
loading...

The Results

M365 Apps Fields

We run this script daily and have a corresponding monitor setup to check whether M365 Apps Secure is checked. If it's not, we get an alert and can investigate further. This script has already helped us identify a few devices that were not updating correctly.

· One min read

PowerShell 5.1 as shipped with Windows 10 and 11 includes versions 1.0.0.1 of PackageManagement and PowerShellGet this old version cannot install most modern modules, nor can it self update properly.

In most cases fixing this runs into numerous issues with conflicting versions or files in use. This script is an adaptation of a script by Chris Taylor which takes a different approach to downloading the modules, has a bit more error checking and further installs the new PSResourceGet module which is the replacement for PowerShellGet.

The Script

Initialise-PowerShellGet.ps1
loading...

Usage

.\Initialise-PowerShellGet.ps1

Nice and simple on this one, just run the script and it will do the rest. It does expect a close-to-vanilla install of Windows 10 or 11, so if you've been messing around with the default modules before running this script, it may not work as expected.

· 10 min read

This post will hold detection scripts for any serious CVE vulnerability that we write detection scripts for in the future. It will be updated and added to as new vulnerability detection scripts are written.

CVE-2022-41099

This script has been compiled using information from the following Microsoft sources:

security

This article relates to CVE-2022-41099 which is a vulnerability in the Windows Recovery Environment (WinRE) which could allow a successful attacker to bypass the BitLocker Device Encryption feature on the system storage device. An attacker with physical access to the target could exploit this vulnerability to gain access to encrypted data.

Fixed a Bug

Thanks to DTGBilly from the NinjaOne Users Discord for pointing out that in altogether far too many places I had typo'd the CVE as CVE-4022-41099 instead of CVE-2022-41099 🤦‍♂️ this included field names and labels so please check yours are correct as now shown in the post.

Parameters!

Since version 1.2.0 (2023-03-21) this script now requires one of two mandatory parameters.

  • If you are checking for the presence of the small "Safe OS Dynamic Update (SODU)" which is the minimum required change to mitigate the vulnerability use the -CheckPackage parameter and if required alter the -MountDirectory and -LogDirectory parameters (defaults to C:\RMM\WinRE).

  • If you are checking for the presence of the larger "Servicing Stack Update (SSU)" or "Dynamic Cumulative Update" which updates more than is required to mitigate the vulnerability, but may offer other benefits including new WinRE functionality or more reliable reset/restore behaviours use the -CheckImage parameter which checks the image build version.

If you were passing these in NinjaOne your parameter preset might look like this:

-CheckPackage -MountDirectory C:\RMM\WinRE -LogDirectory C:\RMM\WinRE

or this:

-CheckImage

Windows Recovery Environment (WinRE) Not Enabled

Before version 1.3.0 the script did not check if WinRE was enabled which could lead to confusing error output in the event WinRE was disabled. Now if you get the WinRE not enabled warning you are clear on why the script isn't executing.

A simple reagentc /enable should enable WinRE or at least provide some useful troubleshooting output.

Creating Fields

Creating custom fields in NinjaOne
To create a custom field in NinjaOne go to Administration > Devices and select either Role Custom Fields or Global Custom Fields then select Add.

  • Role Custom Fields are custom fields that are specific to a device role.
  • Global Custom Fields are custom fields that are applicable to all devices and/or to a location and/or organisation
Make sure you add the fields to the roles you want to use them in at Administration > Devices > Roles (for role custom fields).

When you create your custom field you need to make sure that you set the Scripts permission to ensure that you can read or write to the field from your scripts - as appropriate for the script you're using.

We're adding one role custom field for devices with the Windows Desktop or Laptop and Windows Server roles, note that we've customised slightly the autogenerated machine name here, if you use the default adjust the field name in the script appropriately.

Field LabelField NameField TypeDescription
CVE-2022-41099CVE202241099CheckboxWhether the device has a WinRE image vulnerable to CVE-2022-41099

The Script

This Script Was Updated

This script was updated after being published, if you're using it please compare the version you have with the version available here.

This script was last updated on 2023/04/13.

Detect-CVE202241099.ps1
loading...

The Results

CVE-2022-41099 Related Custom Fields

We run this script daily and have a corresponding monitor setup to check CVE fields with a value of "Yes" and alert us if any are found. You'll find information on remediating this vulnerability in this followup post.

CVE-2023-23397

This script has been compiled using information from the following Microsoft sources:

Thanks to:
  • Concentus on the NinjaOne Users Discord for helping me run down and test different versions of Office to ensure this script was as accurate as possible.
  • Wisecompany on the One Man Band MSP Discord for reminding me to add an exit code and not overuse Write-Warning!
  • Thanks to KennyW on the MSPGeek Discord for helping find an error where certain versions were incorrectly detected as not vulnerable!
  • Thanks to Alkerayn on the NinjaOne Users Discord for helping find an error where certain channels were incorrectly detected as not vulnerable and identifying that we needed to first check the GPO-configured update channel!
  • Thanks to Tanner - MO on the MSPs R Us Discord for pointing out that version comparisons should all use -lt instead of -ne to ensure future compatibility / accuracy.
  • Thanks to DarrenWhite99 on the MSPGeek Discord for pointing out that the check for the GPO UpdateChannel was completely nonsensical and incompletely written.
  • Thanks to JSanz on the NinjaOne Users Discord for pointing out the GUID matching issue/bug.
  • Thanks to Jhn - TS on the NinjaOne Users Discord for discovering the issue with empty registry props causing the script to error.

This has only been tested against M365 Apps and Office 2021 VL versions "en masse" and only 64-bit office - if it doesn't work for you let me know on the NinjaOne Users Discord and I'll see what I can do to fix it!

security

This article relates to CVE-2023-23397 which is a vulnerability in Microsoft Outlook whereby an attacker could access a user's Net-NTLMv2 hash which could be used as a basis of an NTLM Relay attack against another service to authenticate as the user.

Creating Fields

Creating custom fields in NinjaOne
To create a custom field in NinjaOne go to Administration > Devices and select either Role Custom Fields or Global Custom Fields then select Add.

  • Role Custom Fields are custom fields that are specific to a device role.
  • Global Custom Fields are custom fields that are applicable to all devices and/or to a location and/or organisation
Make sure you add the fields to the roles you want to use them in at Administration > Devices > Roles (for role custom fields).

When you create your custom field you need to make sure that you set the Scripts permission to ensure that you can read or write to the field from your scripts - as appropriate for the script you're using.

We're adding one role custom field for devices with the Windows Desktop or Laptop role, note that we've customised slightly the autogenerated machine name here, if you use the default adjust the field name in the script appropriately.

Field LabelField NameField TypeDescription
CVE-2023-23397CVE202323397CheckboxWhether the device has an Office or Microsoft 365 Apps version vulnerable to CVE-2023-23397.

The Script

This Script Was Updated

This script was updated after being published, if you're using it please compare the version you have with the version available here.

This script was last updated on 2023/04/13.

Detect-CVE202323397.ps1
loading...

The Results

CVE-2023-23397 Related Custom Fields

We run this script daily and have a corresponding monitor setup to check CVE fields with a value of "Yes" and alert us if any are found. To remediate this vulnerability update Microsoft Office by running something like this:

This Script Was Updated

This script was updated after being published, if you're using it please compare the version you have with the version available here.

This script was last updated on 2023/03/16.

Update-C2ROffice.ps1
loading...

This update script will force restart Office apps - it should restore open files automatically but if you want a softer approach replace the Start-Process line with:

Start-Process -FilePath $C2RPath -ArgumentList '/update user forceappshutdown=true updatepromptuser=true' -Wait

Prejay on the MSPGeek Discord has helpfully suggested the following to update C2R Office builds without a user logged in or as system:

Start-Process -FilePath $C2RPath -ArgumentList '/frequentupdate SCHEDULEDTASK displaylevel=false' -Wait

Mark Hodges (also on the MSPGeek Discord) has also helpfully suggested this more comprehensive update script which will update Office 2016 and 2019 as well as C2R Office.

CVE-2023-21554

This script has been compiled using information from the following Microsoft sources:

security

This article relates to CVE-2023-21554 which is a vulnerability in the Microsoft Message Queuing system which could allow remote code execution.

Creating Fields

Creating custom fields in NinjaOne
To create a custom field in NinjaOne go to Administration > Devices and select either Role Custom Fields or Global Custom Fields then select Add.

  • Role Custom Fields are custom fields that are specific to a device role.
  • Global Custom Fields are custom fields that are applicable to all devices and/or to a location and/or organisation
Make sure you add the fields to the roles you want to use them in at Administration > Devices > Roles (for role custom fields).

When you create your custom field you need to make sure that you set the Scripts permission to ensure that you can read or write to the field from your scripts - as appropriate for the script you're using.

We're adding one role custom field for devices with the Windows Desktop or Laptop role, note that we've customised slightly the autogenerated machine name here, if you use the default adjust the field name in the script appropriately.

Field LabelField NameField TypeDescription
CVE-2023-21554CVE202321554CheckboxWhether the device has the MSMQ features installed and is missing the April 2023 Security Update.

The Script

This Script Was Updated

This script was updated after being published, if you're using it please compare the version you have with the version available here.

This script was last updated on 2023/03/16.

Detect-CVE202321554.ps1
loading...

The Results

CVE-2023-21554 Related Custom Fields

We run this script daily and have a corresponding monitor setup to check CVE fields with a value of "Yes" and alert us if any are found. To remediate install the April 2023 Security Update.

CVE-2023-35628

This script has been compiled using information from the following Microsoft sources:

security

This article relates to CVE-2023-35628 which is a vulnerability affecting Microsoft Outlook's email rendering system which could allow remote code execution.

Creating Fields

Creating custom fields in NinjaOne
To create a custom field in NinjaOne go to Administration > Devices and select either Role Custom Fields or Global Custom Fields then select Add.

  • Role Custom Fields are custom fields that are specific to a device role.
  • Global Custom Fields are custom fields that are applicable to all devices and/or to a location and/or organisation
Make sure you add the fields to the roles you want to use them in at Administration > Devices > Roles (for role custom fields).

When you create your custom field you need to make sure that you set the Scripts permission to ensure that you can read or write to the field from your scripts - as appropriate for the script you're using.

We're adding one role custom field for devices with the Windows Desktop or Laptop and/or Windows Server role, note that we've customised slightly the autogenerated machine name here, if you use the default adjust the field name in the script appropriately.

Thanks to Gavsto for stopping me doing down the rabbit hole of checking KB numbers by pointing out that it wouldn't be future proof once the next cumulative update was released!

Field LabelField NameField TypeDescription
CVE-2023-35628CVE202335628CheckboxWhether the device is updated/patched for CVE-2023-35628.

The Script

Detect-CVE202335628.ps1
loading...

The Results

CVE-2023-35628 Related Custom Fields

We run this script daily and have a corresponding monitor setup to check CVE fields with a value of "Yes" and alert us if any are found. To remediate install the December 2023 Cumulative Update.

CVE-2024-21413

This Script Was Updated

This script was updated after being published, if you're using it please compare the version you have with the version available here.

This script was last updated on 2023/02/16.

This script has been compiled using information from the following Microsoft sources:

security

This article relates to CVE-2023-35628 which is a vulnerability affecting Microsoft Outlook's preview pane system which could allow remote code execution.

The updates include changes/corrections to the targetted versions - check your version please!

Creating Fields

Creating custom fields in NinjaOne
To create a custom field in NinjaOne go to Administration > Devices and select either Role Custom Fields or Global Custom Fields then select Add.

  • Role Custom Fields are custom fields that are specific to a device role.
  • Global Custom Fields are custom fields that are applicable to all devices and/or to a location and/or organisation
Make sure you add the fields to the roles you want to use them in at Administration > Devices > Roles (for role custom fields).

When you create your custom field you need to make sure that you set the Scripts permission to ensure that you can read or write to the field from your scripts - as appropriate for the script you're using.

We're adding one role custom field for devices with the Windows Desktop or Laptop and/or Windows Server role, note that we've customised slightly the autogenerated machine name here, if you use the default adjust the field name in the script appropriately.

Field LabelField NameField TypeDescription
CVE-2024-21413CVE202421413CheckboxWhether the device is updated/patched for CVE-2024-21413.

The Script

Detect-CVE202421413.ps1
loading...

The Results

CVE-2024-21413 Related Custom Fields

We run this script daily and have a corresponding monitor setup to check CVE fields with a value of "Yes" and alert us if any are found. To remediate install the applicable Office / M365 Apps February 2024 Security Update.

CVE-2024-30103

This script has been compiled using information from the following Microsoft sources:

This script also uses information from the following non-Microsoft sources:

Thanks to:
  • Xzul on the NinjaOne Users Discord for bringing this one to the forefront of my attention as I'd seen it and then promptly forgotten about it!
security

This article relates to CVE-2024-30103 which is a vulnerability affecting Microsoft Outlook's email rendering system which could allow remote code execution.

Creating Fields

Creating custom fields in NinjaOne
To create a custom field in NinjaOne go to Administration > Devices and select either Role Custom Fields or Global Custom Fields then select Add.

  • Role Custom Fields are custom fields that are specific to a device role.
  • Global Custom Fields are custom fields that are applicable to all devices and/or to a location and/or organisation
Make sure you add the fields to the roles you want to use them in at Administration > Devices > Roles (for role custom fields).

When you create your custom field you need to make sure that you set the Scripts permission to ensure that you can read or write to the field from your scripts - as appropriate for the script you're using.

We're adding one role custom field for devices with the Windows Desktop or Laptop and/or Windows Server role, note that we've customised slightly the autogenerated machine name here, if you use the default adjust the field name in the script appropriately.

Field LabelField NameField TypeDescription
CVE-2024-30103CVE202430103CheckboxWhether the device is updated/patched for CVE-2024-30103.

The Script

Detect-CVE202430103.ps1
loading...

The Results

CVE-2024-30103 Related Custom Fields

We run this script daily and have a corresponding monitor setup to check CVE fields with a value of "Yes" and alert us if any are found. To remediate install the applicable Office / M365 Apps June 2024 Security Update.

· One min read

This post will show you how to deploy the New Teams client using a PowerShell script.

The Script

Install-NewTeams.ps1
loading...
Parameters

When you run this script you need to pass some parameters. Use -Offline to install using the MSIX file (script will download this if you don't provide it) if you're providing the MSIX provide the path with -MSIXPath. Use -Uninstall to remove the provisioned New Teams package. You can specify your own staging folder with -TeamsFolder.

· 2 min read

When deploying a password manager, one of the first things you'll want to do is disable the built-in password manager in your browsers. This is a pretty simple task, but it's also one that's easy to forget. It's also a good idea to clear out any passwords that may have been saved before you deployed your password manager.

We automate this for the two browsers we support on managed Windows devices (Edge and Firefox) using PowerShell. Here's how we do it.

Edge

For Edge we're going to be setting the registry key at HKLM:\SOFTWARE\Policies\Microsoft\Edge\PasswordManagerEnabled to 0. This will disable the password manager for all users on the device.

Then we're going to clear out any passwords that may have been saved by deleting the contents of the Login Data file in the user's Edge profile. We'll do this by removing the file entirely.

Now in some cases you only want to do the first part (disabling the password manager) and not the second (clearing out any saved passwords). For that reason the script functionality is controlled with two switch parameters: -DisablePasswordManager and -RemoveExistingPasswords. If you run the script without either of these switches, it will do nothing.

Application%20Configuration/EdgePasswordManagerConfig.ps1
loading...

Firefox

For Firefox we're going to be setting the registry key at HKLM:\SOFTWARE\Policies\Mozilla\Firefox\PasswordManagerEnabled to 0. This will disable the password manager for all users on the device.

Then we're going to clear out any passwords that may have been saved by deleting the contents of the logins.json file in the user's Firefox profile and any key*.db files. We'll do this by removing the files entirely.

Now in some cases you only want to do the first part (disabling the password manager) and not the second (clearing out any saved passwords). For that reason the script functionality is controlled with two switch parameters: -DisablePasswordManager and -RemoveExistingPasswords. If you run the script without either of these switches, it will do nothing.

Application%20Configuration/FirefoxPasswordManagerConfig.ps1
loading...

As we don't use Chrome, Opera or Safari, we don't have scripts for those browsers. However for other chromium-based browsers a similar approach to Edge should work. It is possible to do this with Safari on MacOS as well but we haven't yet scripted it.

· 2 min read

Sometimes I get a script idea put in my head that's so irritatingly pervasive that the only fix is to write the damned script. David Szpunar from the NinjaOne Users Discord made a somewhat passing comment about time drift causing issues with a remote support tool and that let to me thinking... You could probably monitor for that with a PowerShell one-liner right?

Wrong! Turns out that it's more than one line!

The Script

This Script Requires Input
This script requires user input, whether in the form of variables, parameters or edits to the script itself before you can run it. Areas where you need to provide input will be indicated with:
### Inline Comments
and / or
'<MARKED STRINGS>'
Parameters will be indicated before the script block.
This Script Was Updated

This script was updated after being published, if you're using it please compare the version you have with the version available here.

This script was last updated on 2023/03/17.

Test-TimeDrift.ps1
loading...

Using The Script

We tested this as a "Script Result Condition" in NinjaOne set to trigger the monitor if a machine's time drifts by more than 10 seconds from uk.pool.ntp.org (the UK's NTP pool) and it worked like a charm. The script is pretty self-explanatory but here's a quick rundown of what it does:

  1. It uses a configurable NTP or SNTP server to get the "reference" time. (Parameter -ReferenceServer)
  2. It uses the w32tm executable to conduct a number of skew checks against that reference server (Parameter -NumberOfSamples)
  3. It averages the samples and compares the result to the threshold (Parameter -AllowedTimeDrift)
  4. Optionally you can force a resync if the time drift is greater than the threshold (Parameter -ForceResync)

If the average time drift is greater than the threshold, the script returns a non-zero exit code and the monitor triggers. If the w32tm command errors (non existent server, network down etc) the script returns a non-zero exit code and the monitor triggers.

Credits

This script borrows ideas and the approach and a little code from the excellent blog of Kevin Holman.

The formidable Chris Taylor helped with a cool suggestion to suppress empty lines in the output and his site is well worth a visit.

· One min read

This post will show you how to use registry keys to test, set and remove target versions for Windows Feature Updates. This allows you to prevent Windows 10 or 11 from updating past your configured limit.

The Script

This Script Was Updated

This script was updated after being published, if you're using it please compare the version you have with the version available here.

This script was last updated on 2023/04/05.

Invoke-WindowsUpdateTargetVersion.ps1
loading...
Parameters

When you run this script you might want to pass some parameters - here's what they do:

  • -Test - This will test the current target version settings and show you the results.
  • -Unset - This will remove the target version settings.
  • -TargetProductVersion - Specify the target version to aim for, examples would be 21H2 or 22H2.
  • -TargetProduct - Specify the target product to aim for, examples would be Windows 10 or Windows 11.

· One min read

This post will show you how to deploy the Printix client using NinjaOne Documentation fields and a PowerShell script.

Creating Fields

Creating custom fields in NinjaOne
To create a custom field in NinjaOne go to Administration > Devices and select either Role Custom Fields or Global Custom Fields then select Add.

  • Role Custom Fields are custom fields that are specific to a device role.
  • Global Custom Fields are custom fields that are applicable to all devices and/or to a location and/or organisation
Make sure you add the fields to the roles you want to use them in at Administration > Devices > Roles (for role custom fields).

When you create your custom field you need to make sure that you set the Scripts permission to ensure that you can read or write to the field from your scripts - as appropriate for the script you're using.

We're adding two documentation fields to facilitate this script. You'll need to note your document template id, in the screenshots / our internal use we have a template called "Integration Identifiers" which we use to store any integration identifiers we need to reference in our scripts.

Field LabelField NameField TypeDescription
Printix Tenant IdprintixTenantIdTextHolds the customer's Printix tenant id.
Printix Tenant DomainprintixTenantDomainTextHolds the customer's Printix domain.

The Script

Install-PrintixClient.ps1
loading...
Parameters

When you run this script you need to pass your document template id. For example, sticking with our example above, you'd run the script with the parameter: -DocumentTemplate Integration Identifiers

The Results

Printix Documentation Fields

Printix Installation Activity

We run this script on a group of devices which don't have the Printix client installed.

· 5 min read

Collaboration with Martin Himken

This post and the WinRE patching script on Martin's blog at https://manima.de are the result of a collaboration between Martin and I to help mutually improve our various efforts towards patching CVE-2022-41099.

security

This article relates to CVE-2022-41099 which is a vulnerability in the Windows Recovery Environment (WinRE) which could allow a successful attacker to bypass the BitLocker Device Encryption feature on the system storage device. An attacker with physical access to the target could exploit this vulnerability to gain access to encrypted data.

If you're running Windows 10 or 11 you might have come across CVE-2022-41099 which is a vulnerability in the Windows Recovery Environment (WinRE) which could allow a successful attacker to bypass BitLocker if they can boot the device to WinRE. This is a pretty serious vulnerability and Microsoft have released a patch for it. However, the patch is not applied automatically and you need to take action to apply it.

Martin Himken has written a script to patch the WinRE drivers and I've written a script to download and stage the patch and servicing stack update files. The link to Martin's blog is at the top of this post and will be repeated at the end.

This script takes a few parameters to control it's behaviour. Parameter documentation follows:

ParameterTypeDescription
PatchFolderDirectoryInfoThe folder to download the patch files to. If not specified, C:\RMM\CVEs\2022-41099\ will be used.
AllSwitchIf specified, the script will download the patch files for all supported versions and available architechtures of Windows 10 and 11. If not specified, the script will only download the patch files for the version of Windows that is running on the device.
-All

Using the -All parameter will download a lot of files and take a long time to complete. It is recommended that you only use this parameter if you are patching a large number of devices or want to prepare a cache to serve files from.

Downloading all files consumes roughly 4.9GB of disk space.

The Script

info

This new version of the script downloads the Safe OS Dynamic Update (SODU) files - these are tiny and designed only to patch the vulnerable components.

Safe OS Dynamic Update (SODU) version.
This Script Was Updated

This script was updated after being published, if you're using it please compare the version you have with the version available here.

This script was last updated on 2023/03/22.

Get-CVE202241099Patches.ps1
loading...
Change Logs

Version: 1.5

Fixes incorrectly switched URLs for 19042 to 19045 for the x86 and x64 downloads. Thanks to Wisecompany for helping find this.

Version: 1.4

Update to use the Safe OS Dynamic Update packages which are considerably smaller.

Version: 1.3

Use $ProgressPreference to speed up execution. Thanks to https://github.com/CodyRWhite for the suggestion.

Version: 1.2

Fix a bug on line 82 where a hashtable of architectures was attempted to be accessed using the Windows build number. Thanks to Sir Loin of House WinAdmins for spotting this. (Yes, it's a Game of Thrones reference. So original.)

Version: 1.1

Adds handling for 19044.

Version: 1.0

Initial release.

info

This version of the script downloads the SSU and Dynamic Cumulative Update files - these are large and designed to update WinRE completely not just patch the vulnerability.

Servicing Stack Update (SSU) and Dynamic Cumulative Update (DCU) version.
Large Files

This script downloads the SSU and Dynamic Cumulative Update files - these are large and designed to update WinRE completely not just patch the vulnerability. This will require a lot of space both to download them (especially if using -All) and to apply them to WinRE.

This Script Was Updated

This script was updated after being published, if you're using it please compare the version you have with the version available here.

This script was last updated on 2023/03/22.

Get-CVE202241099Patches.ps1
loading...
Change Logs

Version: 1.4

Empty the patch folder if it's not empty. Thanks to Wisecompany for the suggestion.

Version: 1.3

Use $ProgressPreference to speed up execution. Thanks to https://github.com/CodyRWhite for the suggestion.

Version: 1.2

Fix a bug on line 82 where a hashtable of architectures was attempted to be accessed using the Windows build number. Thanks to Sir Loin of House WinAdmins for spotting this. (Yes, it's a Game of Thrones reference. So original.)

Version: 1.1

Adds handling for 19044.

Version: 1.0

Initial release.

Examples

This example will download the applicable patch and SSU (if applicable) for CVE-2022-41099 to the folder C:\RMM\CVEs\2022-41099.

Get-CVE202241099Patches.ps1 -PatchFolder 'C:\RMM\CVEs\2022-41099\'

This example will download all patches for CVE-2022-41099 to the folder C:\RMM\CVEs\2022-41099. With subfolders for each KB and architecture.

Get-CVE202241099Patches.ps1 -PatchFolder 'C:\RMM\CVEs\2022-41099\' -All

Validating the Fix

By popular request you can validate the fix using the principles in the script used for CVE detection.

Collaboration with Martin Himken

This post and the WinRE patching script on Martin's blog at https://manima.de are the result of a collaboration between Martin and I to help mutually improve our various efforts towards patching CVE-2022-41099.

· 8 min read

This post uses code in part from the SMSAgent Blog.

This post takes a snippet from the SMSAgent Blog and adds some additional magic along with two new custom functions.

If you're a Windows 10 or 11 user you'll be familiar with the toast notifications that appear in the bottom right of your screen. These are a great way to get a quick message to the user without interrupting what they're doing. In this article we'll look at how to send a toast notification from PowerShell.

We could use the excellent BurntToast PowerShell module to send a toast notification, but in the interests of reducing the number of third-party modules installed on client machines we'll be using the underlying .NET APIs directly as our needs are fairly simple.

Sending toast notifications is fairly simple once you get to grips with the underlying XML schema but we want our Toasts to be next-level so we're going to make them

Creating a Notification App

This script takes a few parameters to create a Notification App. The App Name and Icon are the most important as these are what will appear in the toast notification.

Parameter documentation follows:

ParameterTypeDescription
IconURIURIThe URI of the app icon to use for the notification app registration. This will be downloaded to the working directory.
IconFileNameStringFile name to use for the app icon. Optional. If not specified, the file name from the URI will be used.
WorkingDirectoryDirectoryInfoThe working directory to use for the app icon. If not specified, 'C:\RMM\NotificationApp' will be used.
AppIdStringThe app ID to use for the notification app registration. Expected format is something like: 'CompanyName.AppName'.
AppDisplayNameStringThe app display name to use for the notification app registration.
AppIconBackgroundColorStringThe background color to use for the app icon. Optional. If not specified, the background color will be transparent. Expected format is a hex value like 'FF000000' or '0' for transparent.
ShowInSettingsIntShow the app in the Windows Settings app. Optional. If not specified, the app will not be shown in the Settings app.

The Script

New-NotificationApp.ps1
loading...

Generic Example

# Setup parameter hashtable.
$NotificationAppParams = @{
IconURI = 'https://homotechsual.dev/img/Icon.png'
IconFileName = 'homotechsual.png'
WorkingDirectory = 'C:\RMM\NotificationApp'
AppId = 'homotechsual.example'
AppDisplayName = 'Homotechsual Example'
AppIconBackgroundColor = 0
ShowInSettings = 1
}
Register-NotificationApp @NotificationAppParams

RMM Example

Unsurprisingly, I'm going to use NinjaOne as the example RMM here. So I've done the donkeywork that is best documented by NinjaOne themselves on the Dojo and added the script above to the NinjaOne Script Library - but what next?

Option 1: Same App for All Customers

Well the chances are that you want to use the same relatively small set of apps per customer so we'll just store a nice blob of text in the Ninja Script Library.

We could end up with a "Preset Parameter" set like this:

-IconURI https://homotechsual.dev/img/Icon.png -IconFileName homotechsual.png -WorkingDirectory C:\RMM\NotificationApp -AppId homotechsual.example -AppDisplayName "Homotechsual Example" -AppIconBackgroundColor 0 -ShowInSettings 1

You can have multiple preset parameter sets and simply select the one you want to use when you run the script or when you schedule it against a group (or however you want to run this) but what about getting more creative?

Option 2: Pull App Details per Customer

We can use Documentation fields to store the details of the app per client and then use the NinjaOne CLI to pull the details when we run the script. This is a little more work but it's worth it if you want to brand your notifications per customer.

We'll need to add a few fields to the NinjaOne Documentation tab for each client:

FieldTypeDescription
NotificationIconURIURLThe URI of the app icon to use for the notification app registration. This will be downloaded to the working directory.
NotificationAppIdStringThe app ID to use for the notification app registration. Expected format is something like: 'CompanyName.AppName'.
NotificationAppDisplayNameStringThe app display name to use for the notification app registration.
NotificationAppBackgroundColorStringThe background color to use for the app icon. Optional. If not specified, the background color will be transparent. Expected format is a hex value like 'FF000000' or '0' for transparent.

We can then use the NinjaOne CLI to pull the details for the client we're running the script against and use them to create the parameter set for the script.

This means editing our script a little to accept the parameters from the CLI and then using the NinjaOne CLI to pull the details from the Documentation tab. We're going to assume you called your Document Template Example Template and your fields named as above in the table (with spaces between words if you wish).

At the top of the script we're going to replace the entire parameter block:

[CmdletBinding()]
Param(
# The URI of the app icon to use for the notification app registration.
[Parameter(Mandatory)]
[uri]$IconURI,
# File name to use for the app icon. Optional. If not specified, the file name from the URI will be used.
[string]$IconFileName,
# The working directory to use for the app icon. If not specified, 'C:\RMM\NotificationApp\' will be used.
[System.IO.DirectoryInfo]$WorkingDirectory = 'C:\RMM\NotificationApp\',
# The app ID to use for the notification app registration. Expected format is something like: 'CompanyName.AppName'.
[Parameter(Mandatory)]
[string]$AppId,
# The app display name to use for the notification app registration.
[Parameter(Mandatory)]
[string]$AppDisplayName,
# The background color to use for the app icon. Optional. If not specified, the background color will be transparent. Expected format is a hex value like 'FF000000' or '0' for transparent.
[ValidatePattern('^(0)$|^([A-F0-9]{8})$')]
[string]$AppIconBackgroundColor = 0,
# Whether or not to show the app in the Windows Settings app. Optional. If not specified, the app will not be shown in the Settings app. Expected values are 0 or 1 (0 = false, 1 = true).
[int]$ShowInSettings = 0
)

Well that's setting up the notification app registration. Now we need to actually send a notification using the app.

Sending a Notification

So this is an entirely separate script - you can use it with the custom app you just created or you can use it with the default where notifications come from Windows PowerShell. It's up to you.

"Runs as User"

This script runs in the user's context it is unlikely it'll work running as Administrator or as a scheduled task. If you want to run it as a scheduled task, you'll need to use something like RunAsUser to run it as the user.

This script takes a few parameters to create a Notification App. The App Name and Icon are the most important as these are what will appear in the toast notification.

Parameter documentation follows:

ParameterTypeDescription
AppIdStringThe app ID to use for the notification app registration. Expected format is something like: 'CompanyName.AppName'.
NotificationImageStringThe path to the image to use for the notification.
NotificationTitleStringThe title to use for the notification.
NotificationMessageStringThe message text to use for the notification.
NotificationTypeStringThe type of notification to send. Expected values are alarm, reminder, incomingcall or default. Details on what each type looks like can be found in Microsoft's Toast schema.

The Script

Send-SimpleNotification.ps1
loading...

Generic Example

# Setup parameter hashtable.
$NotificationParams = @{
AppId = 'homotechsual.example'
NotificationImage = 'C:\RMM\NotificationApp\NotificationIcon.png'
NotificationTitle = 'Example Notification'
NotificationMessage = 'This is an example notification.'
NotificationType = 'reminder'
}
Send-Notification @NotificationParams

Script Example

It's probably most useful to use this script as part of a larger script. For example, you could use it to send a notification when a script has finished running. You could also use it to send a notification when a scheduled task has finished running.

NotificationExample.ps1
loading...

This would output something like this:

Example Notification

There are many other ways you could use notifications and you can add (and handle) actions within notifications but I'm spoiling some killer upcoming blog posts.