How to delete a single Applocker rule

  • Context:

A colleague of mine was working on Applocker rules and the installer he was working on was so badly designed that we thought it would easier to restore the worst and most dangerous default rule named “*” for the built-in administrators.

If you restore this evil rule, you cannot and should not leave it there. You also have to delete it after it has been used to install successfully that ugly software.

  • Problem:

I started looking around using my google fu but only found the following web page from Microsoft named delete-an-applocker-rule that tells you actually how to clear *all* the rules. It’s a dead end and really not what we want 😦

  • Solution:

Instead I wrote the following function. Before looking at its code, let me tell you the following:

If you specify the first parameter to indicate what type of rules you want to delete, a Exe, Script, Msi, Appx, Dll, it will be used in the dynamic parameters block to enumerate all rules names found for this type.

Let’s see this in action:

You may also notice in the body of the function that the XML representation of Applocker rules never touches the disk. The rule is removed from the XML and its result is directly merged/reimported.

The function specifies a ‘high’ ConfirmImpact and SupportsShouldProcess because it’s destructive. There’s no backup of the rules or the rule being removed.

Last but not least, the rule is deleted but the group policies (GPO) are not refreshed. You’ll see its impact once the GPO have been reapplied.

Here’s the function:


Quick tip: uninstall a driver

  • Context

Before upgrading to the next Windows 10 branch, we thought it would be handy to have a script to update the drivers set installed on the computer if required.

  • Issue

We packaged many drivers set but we encountered an issue while upgrading the Intel Chipset drivers.
The newest drivers wouldn’t install on top the previous version. I think it’s due the the fact that the date in the inf file is in 1968.

  • Solution

To fix it, we first installed the new Intel chipset drivers. They have been made available into the local drivers store.

To force Windows to use them, I had to uninstall these drivers like this. Yes, there’s no cmdlet to remove a driver from an online image.

Get-WindowsDriver -Online | 
Where {$_.Version -eq ''} | Foreach-Object {
 pnputil.exe /delete-driver $_.Driver  /force 

Disclaimer: Be careful, you cannot always do that. Some drivers are more (boot) critical to Windows than others.
If you force the uninstall of a driver that was critical, Windows may not boot anymore.

About the Exchange Online (EXO) module and multi-factor authentication (MFA)

It’s officially documented on this page (you should start there)

The only thing missing on this page is what happens if you’re behind a proxy.

After the first use, you have an .appref-ms file sitting on your desktop that points to the URL below.

To get it right the first time, immediately, here are the basic steps

# Launch a new shell

# type the following in this new shell
$o = New-PSSessionOption -ProxyAccessType IEConfig
Connect-EXOPSSession -UserPrincipalName `
"" -PSSessionOption $o

The first visit to the URL above will download Microsoft.Online.CSE.PSModule.Client.exe somewhere under ~/AppData\Local\Apps\2.0\
If you don’t have an application whitelisting solution blocking it, you’ll see

Once executed, it will download whatever dependencies are required (System.Management.Automation.dll, Microsoft.IdentityModel.Clients.ActiveDirectory.dll, Microsoft.Exchange.Management.ExoPowershellModule.dll, Microsoft.IdentityModel.Clients.ActiveDirectory.WindowsForms.dll,…) and run the downloaded CreateExoPSSession.ps1 script that will display this new shell

# it runs this actually to start a new shell
C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -NoLogo -NoExit -ExecutionPolicy RemoteSigned -File ~\AppData\Local\Apps\2.0\YO2PKAE1.DKY\GAOJE34E.RXK\micr..tion_1975b8453054a2b5_0010.0000_22e56f9efbc200c6\CreateExoPSSession.ps1

Then you can capture the proxy settings defined in your profile and use them when you need to connect to the remote endpoint that allows you to manage the remote Exchange online infrastructure.

The Connect-EXOPSSession function should be used with a UserPrincipalName parameter and not credentials. The UserPrincipalName allows you to get the MFA form while the credentials assume that you don’t have MFA enabled. If you use credentials instead of the UserPrincipalName, you get an error saying that you’ve MFA enabled and you didn’t go through the MFA validation process:
New-ExoPSSession : AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access ‘00000002-0000-0ff1-ce00-000000000000’.

Enjoy EXO with MFA 😎

What kind of server channel are your running on: SAC or LTS?

  • Context:

I installed a SAC (Semi Annual Channel) based server and wanted to know what’s the difference with the LTS (Long Term Support) branch?

There’s only 18 months support for the SAC channel.
There’s no upgrade path between branches, so you need to install from scratch when you want to move to a new branch.
That’s a big the deal.
I also wanted to have some code that would help me differentiate these 2 channels?

  • Solution:

I started to dig in google and the registry. I found this relevant info:


The WMI repository can help and contains the following:

Get-CimInstance -Property Caption -ClassName Win32_OperatingSystem |
Select -expand Caption

NB: Notice the year in the caption name before the edition (ex: Standard or Datacenter)
When the server is on a LTS channel, the year is specified whereas when on a SAC channel, it’s absent.

While there is a Get-ComputerInfo cmdlet, it doesn’t meet my needs. I wrote another function

The isExpired property is only valid for the SAC channel. I should modify the code accordingly in a further release.
If you run on the LTS channel, I would recommend that you use the official info on this site:

Let’s see the above function in action:

On a Windows server 2016

On a Windows server 2019

On a Windows Server 1903

On a Windows Server 1709

Notice that this SAC channel is expired

On a Windows 2012 R2 Server

Again, the LTS channel have an expiry date specified on this site:

Quick post: IIS drive

  • Context:

I installed recently a SAC (Semi Annual Channel) based Windows Server and I wanted to use some IIS cmdlets to configure it.

  • Problem:

The IIS: drive didn’t mount

  • Solution:

It appears that there are actually 2 modules.

One that doesn’t mount the IIS drive: the IISAdministration module

One that does: the WebAdministration module

What’s the difference between these 2 modules?

The IISAdministration module is more recent and compatible with both Windows PowerShell and PowerShell (Core).

Quick post: DISM and Features on Demand (FOD)

  • Context:

I started to migrate to the 1809 Windows 10 branch and Remote Server Administration Tools (RSAT) are no longer provided as a separate patch (MSU/cab file) but as a Feature on Demand.

  • Problem:

I wanted to avoid computers downloading the package from Windows Update or the default location set by Group Policy or the Windows directory of a mounted image or a running Windows installation that is shared on the network.

  • Solution:

I downloaded the FOD ISO image and extracted just the cab files I needed.

With the following structure (yes, you need the metadata subfolder and its content + meet the package dependencies)

you can use the Add-WindowsCapability cmdlet and do:

$Source = '\\server-share\whereIextractedCabfiles'
$HT = @{
 Name ='Rsat.ActiveDirectory.DS-LDS.Tools~~~~'
 Online = [switch]::Present
 LimitAccess = [switch]::Present
Add-WindowsCapability @HT -Source:"$($Source)"

Quick post: Windows branch downgrade

  • Context:

We started testing the Windows 10 1809 on different hardware and we noticed some issues. Explorer keeps crashing and we decided to rollback.

  • Problem:

After the upgrade a new account logged on the computer.
DISM.exe /Online /Initiate-OSUninstall now refuses to run and says:

Error: 0xc16a0102
The OS uninstall cannot be initiated. User profiles were added.

  • Solution:

Identify the offending profile by opening the dism log file

Delete the offending profile

$UserProfiles = Get-WmiObject -Class Win32_UserProfile
# View it
$u = $UserProfiles | ? LocalPath -match 'myOffendingUserName'
# Delete user folder
Get-Item "$($u.LocalPath)" | 
Remove-Item -Force -Recurse -Confirm:$false
# Delete user profile reference

Rollback to 1803 is now successful using dism.exe 😎