When an existing user tried to login into Teams on a new device, they couldn't. However, Teams still worked fine on the old device where they logged in at an earlier point in time. Further investigation showed that the issue wasn't user-specific, the same happened to all users. This meant that the problem was organization-wide.

The issue was even more difficult to troubleshoot because there was no useful error message accompanying the failed login in Teams application. Fortunately it could easily be reproduced when trying to log into Teams from a private browser window. After logging in with a company Microsoft account, a page with a Sign in button showed up. Clicking the button didn't seem to do anything.

However, the browser developer tools provided more details. Each click resulted in a failed call to https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token. And the response body contained the following error message:

AADSTS500014: The service principal for resource 'https://api.spaces.skype.com' is disabled. This indicate that a subscription within the tenant has lapsed, or that the administrator for this tenant has disabled the application, preventing tokens from being issued for it.

This helped us discover that we weren't the only ones with this issue. And it identified the root cause of the error: the Microsoft Teams application has become disabled. Could we somehow reenable it?

It was time to take a closer look in the Microsoft Entra admin center. The Microsoft Teams app should be listed on the Enterprise apps page. It didn't look like it at first sight:

Removing the Application type == Enterprise Applications filter helped. Now, there were a lot of Microsoft Teams applications listed:

Microsoft Teams Services was the application I was looking for. On its Properties page I could see that it was Deactivated:

Toggling the Enabled for users to sign-in switch to Yes changed its Activation status to Activated. It was time try logging into Teams from a private browser window again. Unfortunately it still didn't work. But there was now a different error in the browser development tools:

AADSTS500014: The service principal for resource '00000003-0000-0ff1-ce00-000000000000' is disabled. This indicate that a subscription within the tenant has lapsed, or that the administrator for this tenant has disabled the application, preventing tokens from being issued for it.

Finding the right application in the Microsoft Entra Enterprise applications list was even easier this time. I could search by the Application ID value from the error message. It was the Office 365 SharePoint Service application and it was also Deactivated. I reactivated it the same way as Microsoft Teams. And I got yet another error when I tried to log in:

AADSTS7000112: Application 'a164aee5-7d0a-46bb-9404-37421d58bdf7'(Microsoft Teams AuthSvc) is disabled.

This time both the application Name and Application ID were listed in the error message. As if they were trying to make it easier for me. I reactivated Microsoft Teams AuthSvc just like the other two applications.

This finally fixed the issue for good. The login in the private browser window succeeded. I got a list of organizations I was added to. After choosing one of them I was logged into their Teams tenant. It worked from the Teams application as well. Let's just hope it stays that way.

And if not, I know what to check first. In the Microsoft Entra admin center the following Enterprise applications must be Activated (i.e., the Enabled for users to sign-in switch on the application Properties page must be set to Yes):

• Microsoft Teams Services, Application ID: cc15fd57-2c6c-4117-a88c-83b1d56b4bbe
• Office 365 SharePoint Online, Application ID: 00000003-0000-0ff1-ce00-000000000000
• Microsoft Teams AuthSvc, Application ID: a164aee5-7d0a-46bb-9404-37421d58bdf7

A server request filter is a method annotated with @ServerRequestFilter. To access a configuration property, inject it into is parent class:

public class Filters {
    @ConfigProperty(name="features.endpoints-enabled")
    boolean featureEndpointsEnabled;

    @ServerRequestFilter
    public RestResponse<?> featureFlagFilter(ContainerRequestContext requestContext) {
        if (!featureEndpointsEnabled &&
                !requestContext.getUriInfo().getPath().startsWith("/q/")) {
            return RestResponse.ResponseBuilder.notFound().build();
        }
        return null;
    }
}

When the method returns null, the processing will proceed, making the endpoint accessible. When the method returns a RestResponse, the processing stops and that response will be returned to the caller.

If you still want the Dev UI to work when you disable the endpoints, you need to check the requested path, and not block requests to paths which start with /q/.

To test the filter, you would need to change the value of a configuration property for the particular test. One way to do this is by using Quarkus test profiles. The test method must be placed in a separate test class which also acts as a test profile:

@QuarkusTest
@TestProfile(DisabledExampleResourceTest.class)
public class DisabledExampleResourceTest implements QuarkusTestProfile {

    @Override
    public Map<String, String> getConfigOverrides() {
        return Map.of(
                "features.endpoints-enabled", "false"
        );
    }

    @Test
    void testHelloEndpointDisabled() {
        given()
                .when().get("/hello")
                .then()
                .statusCode(404)
                .body(is(""));
    }
}

The getConfigOverrides method returns the key-value pairs of configuration properties to override.

You can find a sample project in my GitHub repository. It adds the filter to a new Quarkus project with a sample endpoint, and a test that validates its behavior.

Although request filters aren't all the flexible, they are a great fit for a functionality that affects all or many endpoints in the application.

To start with a clean slate, I first removed all the JDKs except the ones installed from IntelliJ IDEA. This included the ones listed in Windows Installed apps and those installed through vfox while I was testing it. I also made sure to delete the JAVA_HOME environment variable (at system and user level) and removed any Java related entries from the PATH environment variable (again at system and user level).

I then checked the JDKs I had installed in IntelliJ IDEA. To do that, I opened a Java project in IntelliJ IDEA, opened File > Project Structure... from the main menu and navigated to Platform Settings > SDKs. I selected each JDK in the list and copied the JDK home paths for future reference:

• openjdk-25: C:\Users\damir\.jdks\openjdk-25.0.1
• openjdk-23: C:\Users\damir\.jdks\openjdk-23.0.1

I decided to use JDK 25 by default, so I made the following changes to my user environment variables:

• I set JAVA_HOME to the JDK path: C:\Users\damir\.jdks\openjdk-25.0.1.
• I added the bin subfolder inside it to PATH: C:\Users\damir\.jdks\openjdk-25.0.1\bin.

This was enough to get Java 25 working in a newly opened terminal:

➜ java -version
openjdk version "25.0.1" 2025-10-21
OpenJDK Runtime Environment (build 25.0.1+8-27)
OpenJDK 64-Bit Server VM (build 25.0.1+8-27, mixed mode, sharing)

For switching to a different JDK version, I first created a generic PowerShell script that sets the JAVA_HOME and PATH variables correctly for a JDK in a given folder:

param(
  [Parameter(Mandatory)]
  [string]$Path
)

$env:JAVA_HOME = $Path
$env:Path = $env:JAVA_HOME + "\bin;" + $env:Path;

Two details worth mentioning:

• The environment variables are only changed for the given session. This allows me to use a different JDK version in each session.
• Having the bin subfolder added to the start of the PATH causes the files from this folder to be preferred over the ones from the default JDK, which is listed later in the path.

For convenience, I added the following two functions to my $PROFILE file:

Function Set-Jdk25
{
    Set-Jdk "C:\Users\damir\.jdks\openjdk-25.0.1"
}

Function Set-Jdk23
{
    Set-Jdk "C:\Users\damir\.jdks\openjdk-23.0.1"
}

Now I can use them to switch to a different JDK in the current session:

➜ Set-Jdk23
➜ java -version
openjdk version "23.0.1" 2024-10-15
OpenJDK Runtime Environment (build 23.0.1+11-39)
OpenJDK 64-Bit Server VM (build 23.0.1+11-39, mixed mode, sharing)

When I change the JDKs installed through IntelliJ IDEA, I only need to update the functions in my $PROFILE to match the set of installed JDKs and their paths. If I want to change the default JDK as well, I also need to update the JAVA_HOME and PATH environments accordingly.

The remote host may not meet VS Code Server's prerequisites for glibc and libstdc++ (The remote host does not meet the prerequisites for running VS Code Server)

The server did not meet the prerequisites, so I had to start looking for other solutions.

I decided to share the directory with the files I wanted to edit on the server so that I could access them from my computer. Using this approach, I managed to initialize a Git repository, but as soon as I wanted to perform any Git operation inside it, it failed with the following error:

fatal: detected dubious ownership in repository at '//my-server/my-share/my-dir'
'//my-server/my-share/my-dir' is owned by:
    (inconvertible) (S-1-5-21-577097838-3836064388-3576385918-3054)
but the current user is:
    MyWinPC/damir (S-1-5-21-804102101-2538954194-3365188178-1001)
To add an exception for this directory, call:

    git config --global --add safe.directory '%(prefix)///my-server/my-share/my-dir'

It was because of a security measure, introduced in Git 2.35.2. Changing the ownership of the files on the share wasn't an option, so I executed the command suggested in the error message to bypass the check for that specific directory:

git config --global --add safe.directory '%(prefix)///my-server/my-share/my-dir'

This has indeed resolved the issue, so that I could perform all Git operations as usual, both form command line and from GUI clients.

Before proceeding, I wanted to make sure that all the files would have Linux line endings although I would be editing them from Windows. In Visual Studio Code you can use the Change End of Line Sequence command to select the line endings for each file:

This works great for existing files, but there's always a risk of forgetting to switch the line endings when creating a new file. To avoid this, it's best to set the default value in workspace settings:

This setting will be persisted in .vscode/settings.json file, which can also be added to the git repository:

{
  "files.eol": "\n"
}

Git has its own approach to handling end of line differences between Windows and Linux in files committed to a Git repository. If you're working in Windows, you most likely have it enabled globally with the core.autocrlf setting set to true. In this particular scenario, this setting would interfere with using Linux line endings in Windows. To prevent that, the setting can be turned off locally for this repository by running the following command from any directory inside it:

git config core.autocrlf false

With all this configured, I could edit the files on the remote Linux server from Visual Studio Code in Windows and have the files versioned in a Git repository, although Visual Studio Code couldn't connect remotely to the server using SSH. The experience was still inferior, but it worked well enough for my particular use case.

During initial git setup you need to configure your name and email address to be used in git commits. Many graphical git clients provide user interface to do it, but you can also do it from command line:

git config --global user.name "Me"
git config --global user.email "email@primary.domain"

This configuration is saved to ~/.gitconfig in your home folder:

[user]
    name = Me
    email = email@primary.domain

By default, these settings are going to be used for all repositories you work with on your machine. You can however override any git configuration value for a specific repository. This includes your name and email. Some graphical git clients support this as well, but you can also do it by running the following commands from a folder inside that repository:

git config user.name "Me"
git config user.email "email@secondary.domain"

This configuration is saved to .git/config located at the repository root folder:

[user]
    name = Me
    email = email@secondary.domain

When alternative configuration is set for a repository like this, the name and email from it are going to be used for all commits to this repository.

Although this configuration process is simple enough, it doesn't scale well if your client uses microservices. It's too easy to forget changing the configuration for every single microservice repository you clone to your machine and start contributing to it. And in that case the wrong email from your default global configuration is going to be used.

Fortunately, you can use conditional includes to set the same configuration for all git repositories inside a specific parent folder. On my work machine, I already have all repositories for a certain client inside the same folder, so this matches well with my existing organization.

To use conditional includes, you first need to create a file with git configuration settings in standard format so that you can include it. I put it in the folder containing all the repositories from a specific client, but you could put it anywhere you like:

[user]
    name = Me
    email = email@secondary.domain

Then, you need to open your global git configuration file in ~/.gitconfig and conditionally include the configuration file you just created:

[includeIf "gitdir:~/Git/MyClient/"]
    path = ~/Git/MyClient/.gitconfig

If a repository matches the path after gitdir, the configuration file specified after path will be evaluated and will override any configuration values defined earlier in your global configuration file. If you're in a case-insensitive file system, you might want to use gitdir/i instead of gitdir to make the path comparison case-insensitive.

For now, I'm only using conditional includes for user and email configuration when I need to change it for all repositories of a certain client. But it's a very flexible tool in the toolbelt, so I might find another use for it in the future.

As the first step, I had to add a new network device to the virtual machine. I'm hosting it inside Proxmox VE which made this fairly easy:

• Select the right virtual machine in the Server View tree view.
• Open its Hardware page.
• Select Network Device from the Add dropdown button.
• Keep the default values in the dialog unchanged and click Add

This was enough for the network interface to show up in my Ubuntu virtual machine, as I listed them using:

ip addr show

By comparing the output with the one from before I added the new network device, I could identify a new interface named ens##:

3: ens19: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether bc:24:11:2c:da:0f brd ff:ff:ff:ff:ff:ff
    altname enp0s19

Since its state was DOWN, I had to enable it first:

sudo ip link set ens19 up

This changed its state to UP:

3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:2c:da:0f brd ff:ff:ff:ff:ff:ff
    altname enp0s19
    inet6 fe80::be24:11ff:fe2c:da0f/64 scope link
       valid_lft forever preferred_lft forever

But it still didn't have an IPv4 (inet) address when compared to the other network interface:

3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:2c:da:0f brd ff:ff:ff:ff:ff:ff
    altname enp0s19
    inet 192.168.1.98/24 metric 100 brd 192.168.1.255 scope global dynamic ens19
       valid_lft 86352sec preferred_lft 86352sec
    inet6 fe80::be24:11ff:fe2c:da0f/64 scope link
       valid_lft forever preferred_lft forever

To ensure that its IP address will be predictable, I added a new IP reservation to my DHCP server before continuing. The MAC address of the network interface is listed after link/ether, i.e., bc:24:11:2c:da:0f in my case.

My Ubuntu server uses Netplan for network configuration. Its configuration file is located in /etc/netplan. I had to modify the only file there, named 50-cloud-init.yaml, and enable DHCP for the new network interface with an identical entry as it was already there for the old network interface:

network:
  ethernets:
    ens18:
      dhcp4: true
    ens19:
      dhcp4: true
  version: 2

I saved the the changes and applied them using:

sudo netplan apply

This was enough for the new network interface to acquire an IPv4 address:

3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:2c:da:0f brd ff:ff:ff:ff:ff:ff
    altname enp0s19
    inet 192.168.1.98/24 metric 100 brd 192.168.1.255 scope global dynamic ens19
       valid_lft 86399sec preferred_lft 86399sec
    inet6 fe80::be24:11ff:fe2c:da0f/64 scope link
       valid_lft forever preferred_lft forever

Still, I was a bit worried because of the following comment at the top of the /etc/netplan/50-cloud-init.yaml configuration file:

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}

The contents of the /etc/cloud/cloud-init.disabled file put me somewhat at ease:

Disabled by Ubuntu live installer after first boot.
To re-enable cloud-init on this image run:
  sudo cloud-init clean --machine-id

To be certain, I decided to reboot the virtual machine and check that the network interface remains properly configured afterwards. It did.

With all this in place, I could now modify my docker-compose.yml file to only publish the selected ports on one IP instead of all of them, using the extended ports syntax:

ports:
  - "192.168.1.98:80:80"
  - "192.168.1.98:443:443"

This allowed me to publish the same ports from two different containers, for each one on a different IP. Only the container with the ports published on the IP with port forwarding set up on my router can be accessed externally. The other one is only accessible in the internal network.

Only PowerShell tabs have "PowerShell" as their fixed title by default. Sure, Windows Terminal allows me to rename tabs, but I often don't bother to do it, especially since the title can easily become inaccurate.

Fortunately, PowerShell can also auto-update the tab title, it's just not configured to do so by default. And Oh My Posh, which I am using, has even better support for that. Again not enabled by default, at least not in the theme I chose.

To enable it, only a single line has to be added to your configuration file. If you don't know where that file is located, check your PowerShell $PROFILE file:

code $PROFILE

Inside it, there should be a call to oh-my-posh init pwsh, similar to the following:

oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\negligible.omp.json" | Invoke-Expression

The configuration file is passed as the value of the --config argument. If the file is located in $env:POSH_THEMES_PATH or only a name of the theme is used without the extension (e.g. --config negligible), you're still using one of the provided themes without any modifications. In that case, you should copy it from $env:POSH_THEMES_PATH to somewhere else, e.g., your home directory, before modifying it:

cp $env:POSH_THEMES_PATH/negligible.omp.json ~/my.negligible.omp.json

If you do that, don't forget to modify the oh-my-posh init pwsh call in your $PROFILE file to point to the file in the new location, e.g.:

oh-my-posh init pwsh --config "~\my.negligible.omp.json" | Invoke-Expression

Now you're ready to modify your configuration file, i.e., set a value for console_title_template to how you want your title to be set. The following would set it to your current directory:

{
  "console_title_template": "{{.PWD}}"
}

And make it look like this:

The setting value is formatted as an Oh My Posh template. You can learn about them in the documentation, or simply choose one of the common examples for tab title.

The setting will go into effect, when you open a new PowerShell tab or reload the profile in an already opened tab:

. $PROFILE

If you're a regular user of Windows Terminal or PowerShell in general as I am, you won't regret taking the time to configure auto updates for tab title. It doesn't take a lot of effort and it makes it much more convenient to switch between multiple tabs because you can immediately recognize the one you're looking for just by reading its title.

Linux Mint comes with a large collection of printer drivers, so most printers should be recognized automatically and just work. That was not the case for my printer. The add printer dialog suggested to use the driver for Xerox Phaser 6100 instead, but unfortunately my printer didn't like that and its error code suggested that I was using an incompatible printer driver.

On the bright side, Xerox offers a downloadable driver for Debian-based Linux distributions like Linux Mint. However, it's a 32-bit driver and when I tried to install the DEB package, it failed due to missing dependencies. I tried to fix broken dependencies with apt-get as suggested in a Linux Mint forum post and it worked:

sudo apt-get update
sudo apt-get install -f

I tried to add the printer through the dialog again, and it was correctly recognized now. But as soon as I tried to print a test page, it failed again. This time even before the print job was sent to the printer. But that meant that an error might be logged in /var/log/cups. And indeed it was:

D [12/Oct/2025:11:06:29 +0200] [Job 10] Xerox-Phaser-6000B: error while loading shared libraries: libcupsimage.so.2: cannot open shared object file: No such file or directory

I followed the advice from Ask Ubuntu and installed the missing 32-bit library:

sudo apt-get install libcupsimage2:i386

That was enough to get my printer working. The test page printed successfully. And printing from apps worked as well.

Now it was time to share the printer so that I could use it from my Windows 11 machine. I spent several hours tinkering with Samba without success: I could get the file sharing to work, but not printing.

In the end, I got it working without Samba, using only CUPS and IPP. I had to make the following changes in the CUPS configuration file, /etc/cups/cupsd.conf:

• To make CUPS accessible from the local network, I changed the line containing Listen localhost:631 to Listen 0.0.0.0:631.
• To allow access to the printers from the local network, I searched for the <Location /> block and added Allow all at the end to make it look like this:

  <Location />
    Order allow,deny
    Allow all
  </Location>
  

• To make the printer discoverable over the network, I changed Browsing Off to Browsing On.

I restarted CUPS to apply the configuration changes:

sudo systemctl restart cups

With these changes in place, it was time to connect to the printer from my Windows 11 machine. I opened Settings and navigated to Bluetooth & Devices, and to Printers & scanners from there. When I clicked on Add device next to Add a printer or scanner, the printer showed up:

I clicked Add device and waited for a long time with the Connecting status shown. Then it was Installing... for a couple of seconds, and finally Ready. The printer was added to my list of installed printers. I could successfully print the test page and use it from applications.

The process of getting my printer working wasn't as straightforward as I expected, but in the end I got it to work. It would likely take me much less time if I had more Linux experience. But even without it, i succeeded thanks to many resources online. And learned a few things in the process. Still better than replacing my old computer, printer, or both.

As described in a previous blog post, I am publishing NuGet packages using GitHub Actions. Until now, I had a NuGet API key stored in secrets and used it to authenticate with NuGet:

- name: Publish NuGet package  
  if: startsWith(env.tag, 'v')  
  run: dotnet nuget push nupkg/*.nupkg -k ${{ secrets.NUGET_API_KEY }} -s https://nuget.org

It worked perfectly fine for me. The only downside was having to update the API Key every year because the old one expired. Fortunately, NuGet reminds you about this in advance. It's only a couple of weeks since I had to do it last time, so I was very happy when I learned that I might not have to do it anymore.

The necessary steps are well described in the documentation.

First, a new policy has to be created in the Trusted Publishing section of your NuGet settings. You need to provide the following data:

• Policy Name: A name for the policy so that you will recognize it in the future. I used my project name.
• Package Owner: Your username or the name of the organization owning the package you will be publishing.
• Repository Owner: GitHub user or organization that owns the repository inside which the GitHub Actions workflow will be running.
• Repository: The name of the repository inside which the GitHub Actions workflow will be running.
• Workflow File: Name of the workflow (YAML) file inside .github/workflows directory for the workflow which will publish the package.
• Environment: Name of the GitHub Actions environment from which the package will be published. Can be empty if you're not using environments.

Once you have created the policy, it's time to modify the workflow file. In my case I only had to:

• Add a new step before the package publishing step to retrieve a temporary NuGet API key using OpenID Connect (OIDC). The NuGet Login action takes care of that. You only need to provide it your NuGet username (not email), preferably read from a secret (don't forget to add the secret to GitHub Actions if you use this approach):

  - name: NuGet login (get temporary API key using OIDC)  
    uses: NuGet/login@v1  
    id: login  
    with:  
      user: ${{secrets.NUGET_USER}}
  

• Read the NuGet API key for the publishing step from the output of this new step instead of from a secret:

  - name: Publish NuGet package  
    if: startsWith(env.tag, 'v')  
    run: dotnet nuget push nupkg/*.nupkg -k ${{ steps.login.outputs.NUGET_API_KEY }} -s https://nuget.org
  

After you commit these changes to your repository, the workflow should successfully publish the NuGet package using the trusted publishing flow instead of the long lived API key from the secrets. I tested the process by releasing a new patch version of my project.

When that succeeded, it was time for the final cleanup:

• I deleted the NuGet API key secret from GitHub Actions.
• I deleted the API key from the NuGet settings.

The trusted publishing flow was surprisingly simple to implement in a working GitHub Actions workflow for NuGet package publishing. The few changes that need to be done are well documented. I would recommend everyone who is publishing NuGet packages from GitHub Actions to replace the persisted API key with this new flow.

For me, it all started pretty simple, with one such service. I got its IP using the ping command and added a new network route. I could have used the route command, but I found it easier to use the New-NetRoute PowerShell cmdlet because it can resolve the network interface by its alias and I don't have to search for the index of my VPN interface on the route print output:

New-NetRoute -DestinationPrefix 13.227.180.4/32 -InterfaceAlias MyVPN -NextHop 192.168.2.1

With time, it got more complicated:

• There were domain names with more than one IP address. I could get all of those with a single call to the Resolve-DnsName cmdlet instead of multiple ping calls. But I still had to call New-NetRoute for each IP.
• The IP addresses of some domains changed with time. Now I had to keep track of those and every time, it happened, I had to remove the routes for the old IPs using the Remove-NetRoute cmdlet before adding new ones.

It all required too much effort to maintain and became error prone. It was time to write some scripts to simplify my life. After some thought and experimentation, I wrote the following PowerShell script and named it New-NetRouteForHostname.ps1:

param(
  [Parameter(Mandatory)]
  [string]$Hostname,
  [bool]$Persist = 0,
  [string]$InterfaceAlias = "MyVPN",
  [string]$NextHop = "192.168.2.1"
)

$addresses = Resolve-DnsName $Hostname | Where-Object {$_.Type -eq "A"}
foreach ($address in $addresses) {
  if ($Persist) {
    New-NetRoute -DestinationPrefix "$($address.IPAddress)/32" `
      -InterfaceAlias $InterfaceAlias -NextHop $NextHop
  } else {
    New-NetRoute -DestinationPrefix "$($address.IPAddress)/32" `
      -InterfaceAlias $InterfaceAlias -NextHop $NextHop -PolicyStore ActiveStore
  }
}

It first calls Resolve-DnsName to get all addresses, i.e., A records, for a domain name. It then calls New-NetRoute for each one to add a new network route for it. The script outputs the routes it added.

The $Persist parameter allows different handling for domain names based on whether their IPs are static or not:

• For domain names with static IPs, I set it to $true, so that PolicyStore is not set and the route is persisted across reboots and VPN reconnections.
• For domain names with IPs that change, I set it to $false. This sets the PolicyStore to ActiveStore so that the route isn't persisted.

The $InterfaceAlias and $NextHop parameters allow me to call the script for a different VPN connection. Their default values match my office VPN, so I can usually simply omit them:

New-NetRouteForHostname dynamic-ip.mydomain.net

Since the New-NetRoute requires admin privileges to run, the script must be run in an elevated PowerShell prompt, or using the sudo command:

sudo pwsh -Command New-NetRouteForHostname dynamic-ip.mydomain.net

I know that the script is far from perfect, but it's good enough for now. If needed, I can always improve it further.