I’m really delighted and honoured to have been included in this list — Computing.co.uk’s Rising Stars 2025!

Over the past year, he has revolutionised the charity’s observability, teaching himself Zabbix, an open source monitoring tool. His custom scripts now proactively detect and resolve issues before they can have an impact, significantly reducing both downtime and the risk to [the organisation]. Peter extended monitoring for domains and certificates across the infrastructure to prevent outages caused by expired certificates, all while managing a full workload that included optimising cloud costs, saving… £150,000 annually.

Beyond technical achievements, he has transformed team culture, fostering better communication and aligning technology solutions with the organisation’s mission.

The recognition is really nice to have. What I am most grateful for is that, in a very uncertain and challenging world, I’m in the really fortunate position to be able to spend most of my time contributing to an organisation that shares my values. Technology’s job should be to make people’s lives better. It should empower all of us. It should be a tool to help us maintain the delicate balances of power that keep a society healthy and just. It’s very clear that there’s a lot of work to do on that in 2025.

So, I’ve written a script that will set these “not important” macros against a number of hosts and interfaces provided in a CSV file.

You can find the script here.

• configuring a virtual network topology in Azure in the “hub and spoke model”
• deploying an example resource (a Key Vault) in our spoke network
  • restricting access to the Key Vault using a private endpoint connection so that it is only accessible inside the vnet
• configuring a DNS forwarder running Debian + Unbound in the hub network for resolving the private DNS name of the Key Vault
• configuring a Basic SKU Virtual Network Gateway
• configuring a Windows client to connect to the Basic VPN Gateway in a point-to-site configuration so it has access to the Key Vault through the private endpoint

Why?

A hub and spoke network with private endpoints for restricting access to various Azure PaaS resources is a fairly common architecture, but there are a few parts of it that lead to unnecessary costs: namely the PaaS private DNS resolver and the Virtual Network Gateway in its non-Basic SKUs, such as VpnGw1.

The primary purpose of this post is to document how I’ve achieved this architecture using the Virtual Network Gateway Basic SKU, which saves ~£80/month over the VpnGw1 SKU. It also saves the PaaS private DNS resolver costs by using a lightweight VM.

Create hub network

We’ll start by creating our “hub” network, called vnetHSTestConnectivity in my case.

We’ll be using the 172.16.0.0/24 range for this network.

We will make the default subnet smaller, a /26, and add a gateway subnet after it:

Create “Dev” spoke network

Our spoke network will be considered the “Dev” network, and called vnetHSTestDev.

Here, we’ll use the next /24 block for IP addressing, 172.16.1.0/24.

Peer the Connectivity (hub) and Dev (spoke) networks

We need to peer the two networks. In the vnet configuration, go to Peerings and Add:

We need to do this on both ends of the connection, so for both vnets:

Deploy a Basic SKU VPN Gateway in the Connectivity (Hub) network

The Basic SKU cannot be selected in the Azure Portal UI, so we’ll need to deploy by PowerShell. Let’s deploy this via the cloud shell. We will need to select switch to PowerShell if the shell starts in bash.

The script to run is in my GitHub repository for this post, and is adapted from this comment in the azure-docs repository (thanks to Gitarani Sharma).

(I quickly used vim to paste in the script contents and run it, but you can also use the cloud shell’s Manage files > Upload to get the PowerShell script into the cloud shell environment so that you can run it.)

Build a VPN client machine

The machine that will connect into this virtual network and access the key vault will also be another Azure VM. This doesn’t need to be in Azure at all — I’ve done it just for convenience’s sake; it’s a mighty quick way to build a Windows VM! In a real environment, this is likely to be your development machine that you’re using to develop whatever Azure solution you’re building.

Note that the VPN client machine lives entirely outside the vnets we have created — the point is that this machine is remote and connects via the VPN!

Generate VPN Gateway certificates

For the purposes of authenticating to the VPN Gateway, we will use self-signed certificates as per Microsoft’s guidance. In a real environment, of course, we would want to use a proper PKI!

We will misuse the VPN client machine to generate these for our lab environment. In PowerShell:

$params = @{
Type = 'Custom'
Subject = 'CN=P2SRootCert'
KeySpec = 'Signature'
KeyExportPolicy = 'Exportable'
KeyUsage = 'CertSign'
KeyUsageProperty = 'Sign'
KeyLength = 2048
HashAlgorithm = 'sha256'
NotAfter = (Get-Date).AddMonths(24)
CertStoreLocation = 'Cert:\CurrentUser\My'
}
$cert = New-SelfSignedCertificate @params

$params = @{
Type = 'Custom'
Subject = 'CN=P2SChildCert'
DnsName = 'P2SChildCert'
KeySpec = 'Signature'
KeyExportPolicy = 'Exportable'
KeyLength = 2048
HashAlgorithm = 'sha256'
NotAfter = (Get-Date).AddMonths(18)
CertStoreLocation = 'Cert:\CurrentUser\My'
Signer = $cert
TextExtension = @(
'2.5.29.37={text}1.3.6.1.5.5.7.3.2')
}
New-SelfSignedCertificate @params

Make a note of the 24 month and 18 month certificate expiry, if this environment is likely to last that long!

Now, we need to export the P2SRootCert root certificate. Open mmc and add the Certificates snap-in for the current user.

We don’t need to export the private key in this case, as we won’t be signing any new certificates or using this PKI outside of this test environment.

Export as base 64 format:

Open the exported file in Notepad and copy the base 64 certificate content. Exclude the beginning and end lines; you should have just the base 64 characters themselves.

Set up VPN Gateway point-to-site configuration

The address pool needs to be a range specifically for VPN clients and must be outside the ranges of the networks that those clients seek to access through the VPN.

We will choose 192.168.240.0/24, as this is well outside the 172.16 ranges we are using for the hub and spoke networks, and is less likely to conflict with domestic local networks that use low numbers in the 192.168.* space!

Paste the base64 content of the root certificate into public certificate data and give it a name.

Add the additional routes of the peered networks to Additional routes to advertise. In our case, that’s the IP range of the Dev network, 172.16.1.0/24.

This may take some time to save the new configuration, so while we wait for Updating to disappear from the VPN Gateway’s Overview page, we’ll set up our private DNS zone for the Key Vault. (We haven’t created the vault yet!)

Create private DNS zone for Key Vault

Deploy a new Private DNS Zone. We don’t need to do anything in the Private DNS Zone Editor, just deploy it as is:

Link the Private DNS Zone to the connectivity (hub) network:

Deploy DNS server in the Connectivity (hub) network

So that we can resolve the name of the Key Vault to its internal IP address in our Dev (spoke) network, we need a DNS server that’s in the Connectivity (hub) network.

The VPN client machine will query this DNS server for the specific namespaces that my connection script will configure, including .vault.azure.net.

You can of course do this with Azure Private DNS Resolver, but at a much higher cost!

I will deploy a Debian VM in this instance, and use the Unbound DNS server.

It will be deployed into the default subnet of vnetHSTestConnectivity:

Once deployed, connect over SSH to the new VM.

This new DNS server has been assigned 172.16.0.4 in my example.

We will install and configure Unbound:

sudo apt update
sudo systemctl disable --now systemd-resolved
sudo apt install unbound
sudo vim /etc/unbound/unbound.conf

I’ll edit the config file to add access-control entries for both the private ranges of the hub and spoke network, and also for the VPN connection IP address range 192.168.240.0/24.

Finally, the forward-zone stanza ensures that all DNS queries are forwarded via the Azure DNS resolver inside the Connectivity network. Because the private DNS zone is linked to this network, our DNS VM and its clients can resolve the private names.

server:
  interface: 0.0.0.0
  access-control: 172.16.0.0/16 allow
  access-control: 192.168.240.0/24 allow

forward-zone:
  name: "."
  forward-addr: 168.63.129.16

Let’s restart Unbound:

sudo systemctl restart unbound

Deploy Key Vault with private link

My Key Vault is called KVNEHubAndSpokeTestDev.

On the Networking tab, we will disable public access and create a private endpoint linked to vnetHSTestDev:

Once created, we will be unable to list keys or secrets in the portal, as we’re not yet transiting the VPN to access the Key Vault via the private endpoint:

Let’s make sure the user we are using has the appropriate RBAC permissions to work with the data in the Key Vault, and it’s only the private endpoint issue that’s preventing us from having access. (Even an Owner will not have access to the Key Vault data plane by default.)

We will add the Key Vault Administrator RBAC role:

We need to link the private DNS zone for privatelink.vaultcore.azure.net into the Connectivity vnet:

Test: look up the Key Vault name on the DNS server

To test that the private DNS zone is working, I’ll log onto my DNS server VM and query it directly for the name of the Key Vault.

sudo apt install dnsutils
dig @127.0.0.1 kvnehubandspoketestdev.vault.azure.net

We know this is working here as it resolves to a private IP address in the Dev network range: 172.16.1.5.

Connect from isolated VM into the connectivity network via the VNG

Everything is looking good, but we haven’t yet connected our VPN client to the network!

Back in the VPN Gateway Overview page, download the connection profile by pressing the Download VPN client button.

In the zip file that you’ll get, we will transfer the script in the WindowsPowerShell folder across to the VPN client machine.

Run this PowerShell script. If successful, you’ll be able to go to Windows Settings > Network > VPN and see the new profile vnetHSTestConnectivity. Don’t connect to it just yet.

When we connect to the VPN, we need to also add rules so that Windows directs DNS requests for the private resources that need to be resolved inside the VPN to our DNS server in that network. This can be handled automatically by OpenVPN etc. using the higher end VPN Gateway SKU, but not the Basic SKU.

I’ve written a PowerShell script for connecting and disconnecting from the network that automates the management of these DNS policy rules to let us resolve the private names. Let’s take a look.

The scripts and configuration are in the GitHub repository that accompanies this post.

config.json contains the private DNS zones that will be resolved via the private DNS resolver, and the IP address of this VM inside the vnet.

{
    "VPNConfigurationName": "vnetHSTestConnectivity",
    "VPNGatewayRange": "192.168.240.0/24",
    "DNSClientNRPTRules": [
        ".vault.azure.net",
        ".table.core.windows.net",
        ".vaultcore.azure.net",
        ".servicebus.windows.net",
        ".queue.core.windows.net",
        ".file.core.windows.net",
        ".blob.core.windows.net",
        ".azurewebsites.net"
    ],
    "DNSServer": "172.16.0.4"
}

(We’re only using .vault.azure.net / .vaultcore.azure.net in this post, but this configuration is flexible!)

We will connect to the VPN by running Connect-BasicVPNGatewayWithPrivateDNS.ps1

We should now be connected to the VPN. We should be able to ping the DNS server at 172.16.0.4.

Let’s verify that we can resolve the private endpoint DNS name of the Key Vault to its internal IP address:

Resolve-DnsName kvnehubandspoketestdev.vault.azure.net

Great! We can see the IP4Address returned is in the spoke network range: 172.16.1.5.

Now let’s access the vault over the private endpoint by means of our VPN connection. For demonstration purposes, we will do this using a browser on our VPN client machine and accessing the Azure Portal.

Remember that before we saw this error?

We should now be able to generate a key:

and add a secret:

If we disconnect from the VPN, we should be unable to list the secrets again, due to the vnet restriction.

It’s important to use the corresponding disconnect script to disconnect, so that the DNS policy rules are removed and those Azure DNS namespaces don’t continue to try and resolve through an inaccessible DNS server!

.\Disconnect-BasicVPNGatewayWithPrivateDNS.ps1

Once disconnected from the VPN, we’re locked out of listing the secrets again!

However, Microsoft’s documentation is abundantly clear that, at the time of writing, there is no support for immutable backups via this method.

If you actually need to achieve immutable backup storage for Azure SQL database, you’ll need a different approach.

The Export button within Azure SQL Database can be used to export a .bacpac file. If this is stored in a storage account with immutability locked, you have a copy of your data that will be resilient, even to a Global Administrator compromise.

With regard to .bacpac exports, Microsoft helpfully reminds us that:

BACPACs are not intended to be used for backup and restore operations. Azure automatically creates backups for every user database. For details, see business continuity overview and Automated backups in Azure SQL Database or Automated backups in Azure SQL Managed Instance.

However, that leads me right back to “immutability is not supported” point regarding the backups they’re mentioning here. It seems remarkable that “business continuity” is mentioned in the context of backups that are very vulnerable in many BCP scenarios, given the world of ransomware we face today (and will face in the future!)

A .bacpac file held in immutable storage can be imported back into a new Azure SQL database to restore it, but it’s important to note Microsoft’s warning:

For an export to be transactionally consistent, you must ensure either that no write activity is occurring during the export, or that you’re exporting from a transactionally consistent copy of your database.

This is indeed critical. A copy can be made simply with the Copy button within Azure SQL Database. Once complete, press Export on the copy of the database. You can delete the copied database once the export is complete.

The truncated error message I received (and the reason for this blog post) when trying to import a .bacpac that was not transactionally consistent is as follows:

The ImportExport operation with Request Id failed due to 'Could not import package. Warning SQL72012: The object [data_0] exists in the target, but it will not be dropped even though you selected the 'Generate drop statements for objects that are in the target database but that are not in the source' check box. Warning SQL72012: The object [log] exists in the target, but it will not be dropped even though you selected the 'Generate drop statements for objects that are in the target database but that are not in the source' check box. Error SQL72014: Framework Mi'.

If you see this, you’ll need to export a copy of the database, as above, so that no transactions are occurring on that database copy for the duration of the export operation.

To be fair, Cloud Update taking precedence and causing other policies to be ignore is documented, although how to override this if you do need to wrestle control back from the Cloud Updates is buried a little in Microsoft’s document.

I had a test machine that was enrolled in the Cloud Update, but I now needed to be on Current Channel (Preview), so I couldn’t have it be controlled by Cloud Update anymore, as these preview channels aren’t an option in that portal. The test machine was added to the scope of an Intune Configuration Profile which set the update channel via Administrative Templates.

A simple check for updates in any Office app happily informed me I was already up to date. 🙁

I could get the device on the beta channel by running officesetup.exe /configure <xml>, with an XML file as follows:

<Configuration>
<Updates Channel="BetaChannel" />
</Configuration>

However, this wouldn’t stick – the next Office update would roll it right back to Current Channel.

I excluded an Entra ID group containing the primary user and the device from Cloud Update, but this didn’t help immediately. I didn’t have 24 hours available to me to wait for the exclusion to take effect.

In Tenant Settings, you can exclude a group from cloud update management, but it may take some “cloud time” to apply!

It turns out that once in Cloud Update, if we want to force Cloud Update off without waiting for the machine to drop out of the inventory, we must set this registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\cloud\office\16.0\Common\officeupdate

Value: ignoregpo, Type: DWORD, Value data: 0

Change ignoregpo from 1 to 0 here!

Now, the updates setting from HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\office will actually be honoured, and an update check should find the right channel!

Ingesting data from Zscaler Internet Access and Zscaler Private Access into a SIEM is a valuable technique for identifying risky endpoint activity or system compromise. It also gives you a (hopefully) immutable¹ copy of this audit data to support a post-incident investigation.

I’ve been able to configure both Zscaler Internet Access and Zscaler Private Access data to be ingested into Microsoft Sentinel², but occasionally have found that the somewhat circuitous path that ZIA data takes into the SIEM (NSS VM, to another Linux VM over syslog, then to Azure Monitor Agent, and finally to Sentinel) can be brittle. A reboot of the collector VMs has always fixed this, but you have to know that the data flow has stopped!

I have written a couple of KQL queries for this scenario – one for Zscaler Internet Access (ZIA) and one for Zscaler Private Access (ZPA).

Each will trigger an incident if zero log entries are received for the relevant service within a 2 hour period.

You can import these to your own Sentinel environment by clicking Import in Analytics rules and providing the ARM template files linked below.

Zscaler Internet Access

Download as ARM template

CommonSecurityLog | where DeviceVendor == "Zscaler" and DeviceProduct == "NSSWeblog"
| where TimeGenerated > ago(30d)
| summarize last_log = datetime_diff("second",now(), max(TimeGenerated))
| where last_log >= 7200

Set this to run against data for the last 2 hours, with the maximum “look back” period. The query will return 0 results if data ingestion is occurring correctly, so you will want to alert on >0 log entries.

Zscaler Private Access

Download as ARM template

ZPAUserActivity
| where LogTimestamp > ago(30d)
| summarize last_log = datetime_diff("second",now(), max(LogTimestamp))
| where last_log >= 7200

Set this to run against data for the last 2 hours, with the maximum “look back” period.

You will get an error “Failed to run the analytics rule query. One of the tables does not exist” if you have not completely configured the ZPA log ingestion, including adding the custom ZPAUserActivity function to your Sentinel workspace. Follow the Zscaler and Microsoft Sentinel Deployment Guide (“Configuring NSS VM-Based Log Ingestion for ZPA”, page 126).

1: The keys to the kingdom are then the Sentinel/LA workspace, which hopefully your attacker has not escalated privileges to be able to delete. There’s nothing like “immutable vaults” in Azure Recovery Vaults for Sentinel or Log Analytics workspaces. You can set a standard Azure lock, but a privileged attacker could just delete the lock!

2: Zscaler recently (just in time) updated the ZPA ingestion workflow to use the Azure Monitor Agent rather than the deprecated Log Analytics Agent. This took a little reconfiguring and was quite an involved process!

Users were experiencing a 5-15 second delay when saving a document to OneDrive or SharePoint, during which Word would show as “not responding”.

All machines in question use App Control for Business (WDAC).

The Cause

During the “not responding” period, Word is attempting to start the Web Client service, which is set to Manual.

svchost.exe launches, tries to load the WebClnt.dll library, but this is blocked by App Control for Business.

Word has to wait for this attempt to time out, before then giving up and saving anyway.

The Fix

Setting the Web Client service start type to Disabled prevents Word from attempting to start the service, fixing the delay.

The Diagnosis Process

Event Tracing for Windows and UIforETW strike again, along with the incredible utility of the public symbols for Office.

The process was similar to that which I documented here, where the process of saving comments in Word caused a hang. The key is to click Trace > Load Symbols to ensure we have function names in the trace.

Drilling down to the problem time area and then digging into the amount of time we spend in each function revealed that the time was being spent in davhlpr.dll!TriggerStartWebclientServiceIfNotRunning.

Well this does indeed sound like something to do with the Web Client service!

I’d also separately noticed frequent events in the CodeIntegrity Windows Event Log relating to WebClnt.dll. This library is blocked by the default rule set for App Control for Business, as apparently it can be used as a bypass for the feature.

Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. An attacker can use these applications or files to circumvent application allow policies, including WDAC:

…

• webclnt.dll/davsvc.dll

Code Integrity determined that a process \Device\HarddiskVolume4\Windows\System32\svchost.exe) attempted to load \Device\HarddiskVolume4\Windows\System32\WebClnt.dll that did not meet the Enterprise signing level requirements.

The error message is misleading — the DLL is signed (although I believe via a .cat file buried somewhere, as it’s part of the operating system). It’s actually this default rule set that explicitly blocks it, despite it being part of the OS!

Fair enough, I suppose. The difficulty here is that the process of Word trying to start the service, spawning a svchost.exe, only for it to be unable to to load webclnt.dll is taking seconds and seconds, while the user is unable to do any work. This adds up if it happens on every save of a document.

I had the idea perhaps to enable this DLL via an App Control rule, but this didn’t go anywhere, despite a test to attempt to exclude webclnt.dll from the ruleset.

Instead, I set the service to Disabled and tried to reproduce the issue.

Suddenly, instant save!

The service being disabled doesn’t seem to have any negative impact on Office applications — and indeed I can be quite confident this won’t break any other functionality our users rely on, since the Web Client DLL has been consistently blocked in all other contexts too!

It’s another W for Event Tracing for Windows, and the publication of the symbols for Microsoft Office. Thank you, Microsoft!

I recently made the mistake of seeing that a pacman upgrade to icu (International Components for Unicode) would break a few Electron packages, which I needed for the open source build of VS Code, among a few other options. (I generally like to avoid Electron apps, but VS Code is a rare exception!)

I was notified by pacman that there was a dependency issue here that could not be solved, so that the entire transaction was not possible.

My mistake was thinking “oh, I’ll just exclude icu from the upgrade, as it’s causing the dependency issue”. Usually these issues are fixed in a day or two, so I’d upgrade it later.

This was indeed a mistake.

Somehow, apps were now referencing the new icu that wasn’t there already. I rebooted, to discover that the GUI wouldn’t start, and I couldn’t even use pacman in single-user mode to roll back the previous transaction, as pacman itself depended upon icu.

I’d broken the very package manager that I needed to roll back. Oops!

Install media to the rescue

I booted into the Arch install media, and set about to address the issue.

chrooting into the target filesystem and using pacman wasn’t an option, as running the package manager from the target filesystem failed with the same dependency issue.

I had a few false starts with trying to run pacman from the install medium, pointing it at the mounted OS partition with --sysroot.

While this didn’t pan out, I remembered that pacstrap, while designed for install-time, presumably could install packages in the target filesystem without needing pacman itself. I was concerned that this might reinstall some base packages, but it turns out you can specify which packages to install manually on its command line.

So, I gathered the list of packages that needed upgrading by using pacman -Syu --sysroot /mnt against the target filesystem, and then supplied this package list to pacstrap:
pacstrap -G -i -M /mnt icu brltty electron27 electron28 electron29 electron30 freerdp freerdp2 harfbuzz-icu raptor
And… we’re back!

Lessons learned

• The manual isn’t joking about “Partial upgrades are unsupported”.
• Considerable caution is required when using pacman --exclude
• “The OS is ephemeral and I can rebuild it” is a bit too relaxed an attitude when you don’t really want to have to rebuild the OS at short notice. Back up the OS packages and libraries too.
• Really understanding the package manager and install process gives you the tools to pull yourself out of the holes you dig for yourself!

I frequently SSH into various systems from my primary Linux machine. There is an analogous issue to “too many browser tabs” that exists here — having too many SSH sessions open in different terminal tabs!

There is a risk in these cases of accidentally typing a higher-privileged sudo password into a lower security system by typing into the wrong terminal. There are various approaches that can help here; I have used screen banners with different colours before.

A good “last line of defence” approach to this risk that I have settled on is to make use of sudo‘s “lectures”. You will have seen the default:

We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

We can customise this, and also set it to always show, rather than just the first time you ever use sudo on that machine. We’ll create a custom lecture file with our desired text — in my case, the hostname I’m logged into, so I’m sure where I am before I type the password!

Then, use visudo to set these options:

Defaults lecture=always
Defaults lecture_file=/etc/custom_sudo_lecture

The Zabbix Agent 2 on Linux uses a non-root account by default (“zabbix”), and thus provides some protection against the worst outcomes of a potential vulnerability in the agent, or perhaps a takeover of a Zabbix server that monitors that agent.

The Agent on Windows, however, runs with NT AUTHORITY\SYSTEM, which has extensive privileges on the monitored system.

I have put together a little wrapper script around the Zabbix Agent 2 MSI installer which runs the installer, then reconfigures it to run as NT AUTHORITY\LocalService, which is a minimally privileged account.

You can find the script on GitHub. You’ll need to also grab the Zabbix Agent 2 MSI installer, rename it to zabbix-agent2.msi and provide that MSI in the same directory when you deploy.

It goes without saying that this is not officially supported, but I have not experienced any issues monitoring the standard items that are in the Windows by Zabbix Agent template. It is possible you will run into issues with unsupported items if the item in question does in fact require elevated permissions on the monitored host!

Hopefully this will be useful to others looking to monitor Windows systems with Zabbix, while maintaining as much of the principle of least privilege as possible!