Tech blog by Tobias Fenster

Docker sandbox via SSH in VS Code for BC development

Sat, 08 Aug 2026 12:57:23 +0000

Running your coding agents in a TUI (Terminal User Interface) can feel very fast and convenient. At the same time, it can also be nice to have the full files ready, which makes it helpful to integrate your coding agent into your development environment. In my recent blog posts (1, 2, and 3), I have always shown TUIs because that was the only way with Docker Sandboxes. But that has now changed, because you can access your Sandbox via SSH, which opens up other options.

The TL;DR

Connecting to a development environment via SSH is not particularly new; VS Code has been able to do that for a long time, as explained in the official docs. Two years ago, I already shared two blog posts (1 and 2) describing how I use that in my preferred dev setup. The change now is that you can also use it for your Sandbox. The same security boundaries, networking monitoring, and credential injection are already conveniently available via an SSH connection. This is what it looks like:

Pretty neat, right?

The details

To be honest, the details are sparse, but to walk you through them: first, you need to set up the SSH functionality via sbx setup ssh. This configures SSH functionality for Sandboxes in general (also explained in the official docs). Note that if you are not sure whether you have done that in the past, you can always just re-run it without breaking anything.

The next step is to connect to the Sandbox via SSH. That requires an existing (but not necessarily running) Sandbox. Building on top of the recent blog posts mentioned above, I use sbx run --kit .\al\ copilot . to create a GitHub Copilot Sandbox with the “AL” mixin for Business Central development. I can then connect to it from VS Code. Note that in this case, the Sandbox is already running, but if it had been stopped, it would automatically have been started when the SSH request came in.

In the video, I had already selected the workspace within the Sandbox, but if you do that for the very first time, you also need to select that folder. The last step is then to start the agent you want to use which in my case is Copilot. After that, everything works as if you were using the Sandbox directly in the terminal, as you can also see in the demo video: I can interact with the Business Central backend without authentication because of the amazing credential injection feature of Docker Sandboxes.

Docker Sandbox, AL MCP Server and AI Runway improvements; and MVP renewal

Mon, 20 Jul 2026 13:32:33 +0000

This is a quick update on 3 tech and 1 personal topic: All of them would not have been worth a blog post, but all 4 combined make it valuable - I hope :)

The TL;DR

The very brief update:

Docker Sandboxes now support wildcards for credential injection. If you read one of my recent blog posts very closely, you may have seen that I cheated a tiny bit. That is no longer required.
The AL MCP Server can now work cleanly with externally injected credentials. Again referencing one of my recent blog posts, there I explicitly shared the shortcoming that has now been addressed by Microsoft.
AI Runway used to have an issue where an already installed Kubernetes AI Toolchain Operator (KAITO) was not correctly identified. Since the latest release, that is fixed and an Azure Kubernetes Service (AKS) cluster set up with --enable-ai-toolchain-operator just works.
I am a Microsoft MVP for another 12 months!

That’s it. Unless you want to understand a few more details, then the next sections are for you.

The Details: Docker Sandboxes

Looking back at the first blog post mentioned above, I shared the following configuration for a mixin kit that can be used to make a Docker Sandbox ready for the Azure DevOps MCP Server:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
schemaVersion: "1"
kind: mixin
name: az-devops
displayName: az-devops
description: Azure DevOps

network:
  allowedDomains:
    - "**.dev.azure.com"
    - "**.visualstudio.com"
  serviceDomains:
    4psnl.visualstudio.com: az-devops
    dev.azure.com: az-devops
    mcp.dev.azure.com: az-devops
  serviceAuth:
    az-devops:
      headerName: Authorization
      valueFormat: "Basic %s"

commands:
  install:
    - command: "mkdir /usr/local/share/npm-global/lib"
      user: "1000"
      description: Create missing folder

If you take a close look at line 12, you will see that I snuck in 4psnl.visualstudio.com as serviceDomain. The reason for that is that some interactions with Azure DevOps for quite old organizations use the old <your-org>.visualstudio.com URL structure. As you may have guessed from the name, 4psnl.visualstudio.com is one of the organizations used for the Dutch company group 4PS, my employer. But until recently, you couldn’t use wildcards when defining serviceDomains, so I had to add it explicitly, although that doesn’t make sense for anyone outside of 4PS. Fortunately, this was changed in one of the latest releases, so I can now write something like this:

1
2
3
4
5
6
7
8
9
network:
  ...
  serviceDomains:
    "*.visualstudio.com": az-devops
    ...
  serviceAuth:
    az-devops:
      headerName: Authorization
      valueFormat: "Basic %s"

With that in place, the Docker Sandbox will inject the right credentials into all traffic going to *.visualstudio.com without having to specify a dedicated org name.

I have also submitted this kit to the repo where Docker hosts them via this PR. I hope this will get accepted and then you can use it even more easily, but I’ll probably share another little update if and when that happens.

The Details: Authentication with the AL MCP Server

In the second blog post mentioned above, I explained that I had to use a little workaround to get authentication to work. The reason was that my backend used NavUserPassword authentication, but that made the AL MCP Server always ask for credentials. I could avoid this by using Windows authentication, but that was a) wrong and b) a bad workaround that probably would have fired back after a while.

Fortunately, Microsoft has decided to fix this based on a little GitHub issue where I reported the problem. The fix actually did quite a bit more, but most importantly for my scenario, it added a flag --noAuth to startup which makes the AL MCP never ask for credentials. So the MCP Server reference now needs to look like this and I want to specifically point out line 9:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "mcpServers": {
    "al": {
      "command": "/home/agent/.dotnet/tools/al",
      "args": [
        "launchmcpserver",
        "--transport",
        "stdio",
        "--noAuth",
        "."
      ],
      "env": {
        "DOTNET_ROOT": "/home/agent/.dotnet"
      }
    }
  }
}

With that, I can now interact with my backend through the MCP tools and it will never ask for credentials. As the Docker Sandbox injects the credentials, it just magically works! Same as above, I also created a PR to make the AL MCP preparation kit available in the Docker repo.

The change also introduced new environment variables that can be used for the same purpose:

BC_SERVER_URL
BC_SERVER_INSTANCE
BC_SERVER_PORT
BC_SERVER_USERNAME
BC_SERVER_PASSWORD
BC_ACCESS_TOKEN

I think the names are pretty self-explanatory. The first three can be used to overwrite the settings in your launch.json, the last three can be used for authentication. As I already have a great option for my scenario with the --noAuth param, I didn’t use those, but I am pretty sure that they will come in handy at some point.

In any case, great to see that Microsoft is willing to make changes to better support AI-assisted development.

The Details: KAITO recognized by AI Runway

Referencing the third blog post mentioned above, I showed this command to create an AKS cluster:

1
2
3
4
5
6
az aks create \
  --location $env:AZURE_LOCATION \
  --resource-group $env:AZURE_RESOURCE_GROUP \
  --name $env:CLUSTER_NAME \
  --enable-oidc-issuer \
  --generate-ssh-keys

At a later step, I showed how to manually install KAITO on top of it:

1
2
3
4
5
helm repo add kaito https://kaito-project.github.io/kaito/charts/kaito
helm install kaito-workspace kaito/workspace \
  --namespace kaito-workspace \
  --create-namespace \
  --set featureGates.disableNodeAutoProvisioning=true

Already at that time, the parameter --enable-ai-toolchain-operator existed and did install KAITO, but AI Runway failed to detect that. I raised a first issue about it and got the feedback that it was resolved, but it actually still didn’t work for me, so I raised another issue. This time, the fix also worked for me. So now all you need to do is set that parameter when creating the cluster like this:

1
2
3
4
5
6
7
az aks create \
  --location $env:AZURE_LOCATION \
  --resource-group $env:AZURE_RESOURCE_GROUP \
  --name $env:CLUSTER_NAME \
  --enable-oidc-issuer \
  --generate-ssh-keys \
  --enable-ai-toolchain-operator

With that in place, there is no need anymore to install KAITO separately, but AI Runway automatically finds it.

The Details: I am still an MVP

The last and actually least relevant piece of this blog post is the news that I got renewed as MVP, again in both the Azure (Kubernetes and Open Source) and Business Applications (Business Central) categories. It is my 10th year in the program and as you can probably imagine, I am quite proud about that. A lot of time and effort goes into maintaining that status and I am very thankful to both 4PS and Hilti for allowing me to invest some of my working time into that topic. On the other hand, in our world full of big challenges from geopolitics through environmental to societal problems, I still struggle to be as happy about it as I was in the past. Anyway, I actually am happy about it and I wanted to share that, so here we are.

Docker sandbox credential injection for Business Central

Fri, 12 Jun 2026 19:18:42 +0000

I recently blogged about how to use Docker Sandboxes and Kits to work with the AL MCP Server and the Azure DevOps MCP Server from GitHub Copilot in a secure way. Maybe you noticed, I showed how to inject the credentials for the Azure DevOps MCP Server, but not for the AL MCP Server, which actually is the Microsoft D365 Busines Central authentication. With a lot of help by Claude Code and the phantastic team at Docker, I figured out how to do that¹ and want to share it with you as well.

The TL;DR

Let me start by showing you the result:

As you can see, I never had to authenticate within the sandbox, because the credentials are injected by the proxy on the host. If you want to know how that works, join the ride.

The details: Injecting the credentials on the Sandbox side

On the Sandbox side, this looks very similar to what I have shown in the previous blog post for the Azure DevOps MCP Server:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
schemaVersion: "1"
kind: mixin
name: al
displayName: al
description: altool installation

network:
  allowedDomains:
    - dot.net
    - ci.dot.net
    - builds.dotnet.microsoft.com
    - api.nuget.org
    - fps-alpaca.westeurope.cloudapp.azure.com
  serviceDomains:
    fps-alpaca.westeurope.cloudapp.azure.com: bc
  serviceAuth:
    bc:
      headerName: Authorization
      valueFormat: "Basic %s"

credentials:
  sources:
    bc:
      env:
        - BC

commands:
  install:
    - command: "curl -fsSL https://dot.net/v1/dotnet-install.sh | bash -s -- --channel 8.0 && /home/agent/.dotnet/dotnet tool install --global Microsoft.Dynamics.BusinessCentral.Development.Tools"
      user: "1000"
      description: Install altool
  startup:
    - command: ["/bin/sh", "/home/agent/patch-al-crl.sh"]

environment:
  proxyManaged:
    - BC

My Business Central environment is a COSMO Alpaca container available at fps-alpaca.westeurope.cloudapp.azure.com, so I first need to give the sandbox access to that URL (line 13). Then the serviceDomains and serviceAuth in lines 14-19 define that we also want to inject credentials, which in turn are set up in lines 21-25. And we need to let the proxy know that it should manage those credenitals in lines 35-37.

Now all that is left is to define the secret bc on the host containing the actual credentials

1
echo "$([System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes("tfenster:Super5ecret!")))" | sbx secret set -g bc

Or at least I thought so initially. But if it would have been that easy, I would have shared it last time already. So why didn’t this work?

The details: The problem with basic auth / UserPassword

First, the container is set up with UserPassword aka basic authentication. But if the agent calls al_* commands requiring server auth like downloading symbols, then it always wants to get a username and password, which a) would be insecure and b) doesn’t work in this setup anyway. The other options are Azure Entra ID / AAD or NTLM / Windows authentication. I initially thought both would not be an option because, well, the container just isn’t configured that way. And for AAD, that is actually true. But Windows coincidentally does exactly what we need: It just calls the server without asking for anything. Of course, there is no Windows / NTLM user in our Linux sandbox, so without the proxy this wouldn’t work, but because the proxy injects the correct credentials, that is no problem.

Great, right? Unfortunately, not quite.

The details: The problem with Windows auth

Update: This part has become obsolete as Docker has implemented a fix for this in version 0.33.

The second problem is that if you use Windows auth, the AL MCP Server always strictly validates the Certificate Revocation List when making the connection to the server and the certificate that the Sandbox proxy injects doesn’t provide one. Now I could try to appear clever and claim how I figured that out and created a workaround, but credit where credit is due: Claude Code with Opus 4.6 did that… Here is the actual response after a lengthy bit of analyzing and some prodding by myself into the right direction

1
2
3
- The proxy does MITM SSL inspection, and the AL tool's Windows auth code path explicitly sets CheckCertificateRevocationList = true
- The proxy's MITM cert has no CRL endpoint, so the revocation check always failed
- Fix: patched Microsoft.Dynamics.Nav.Deployment.dll with Mono.Cecil to change that single CheckCertificateRevocationList = true call to false

There is a miniscule chance that I might have figured out the actual SSL issue as there always was just a generic “SSL connection failed” error message. And there is a chance of exactly 0% that I would have been able to come up with the following script that fixes it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
#!/bin/bash
set -e

# Patch Microsoft.Dynamics.Nav.Deployment.dll to disable CheckCertificateRevocationList.
# This is needed in sandbox environments where the proxy does MITM SSL inspection
# but the proxy cert has no CRL endpoint - causing Windows auth symbol downloads to fail.

DOTNET="${DOTNET_ROOT:-$HOME/.dotnet}/dotnet"
STORE="$HOME/.dotnet/tools/.store/microsoft.dynamics.businesscentral.development.tools"

# Find the DLL (handles any installed version)
DLL=$(find "$STORE" -name "Microsoft.Dynamics.Nav.Deployment.dll" 2>/dev/null | head -1)
if [ -z "$DLL" ]; then
  echo "ERROR: Microsoft.Dynamics.Nav.Deployment.dll not found. Is the AL tool installed?"
  exit 1
fi
echo "Found: $DLL"

# Skip if already patched (backup exists)
if [ -f "$DLL.bak" ]; then
  echo "Already patched (backup found at $DLL.bak). Skipping."
  exit 0
fi

# Build the patcher
PATCHER_DIR=$(mktemp -d)
trap "rm -rf $PATCHER_DIR" EXIT

cat > "$PATCHER_DIR/patcher.csproj" << 'EOF'
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Mono.Cecil" Version="0.11.4" />
  </ItemGroup>
</Project>
EOF

cat > "$PATCHER_DIR/Program.cs" << 'EOF'
using Mono.Cecil;
using Mono.Cecil.Cil;
using System;
using System.Linq;

var dllPath = args[0];
Console.WriteLine($"Patching: {dllPath}");

var asm = AssemblyDefinition.ReadAssembly(dllPath, new ReaderParameters { ReadWrite = true });
int patched = 0;

foreach (var type in asm.MainModule.Types)
    foreach (var method in type.Methods.Where(m => m.HasBody)) {
        var instrs = method.Body.Instructions;
        for (int i = 1; i < instrs.Count; i++) {
            var instr = instrs[i];
            if ((instr.OpCode == OpCodes.Callvirt || instr.OpCode == OpCodes.Call)
                && instr.Operand is MethodReference mr
                && mr.Name == "set_CheckCertificateRevocationList") {
                var prev = instrs[i-1];
                if (prev.OpCode == OpCodes.Ldc_I4_1
                    || (prev.OpCode == OpCodes.Ldc_I4 && (int)prev.Operand == 1)) {
                    prev.OpCode = OpCodes.Ldc_I4_0;
                    Console.WriteLine($"  Patched in {method.FullName}");
                    patched++;
                }
            }
        }
    }

if (patched == 0) {
    Console.WriteLine("No patch sites found - already patched or DLL structure changed.");
    Environment.Exit(2);
}

asm.Write();
Console.WriteLine($"Done ({patched} patch(es) applied).");
EOF

echo "Building patcher..."
cd "$PATCHER_DIR"
"$DOTNET" build -o "$PATCHER_DIR/out" -v q 2>&1 | tail -3

echo "Applying patch..."
cp "$DLL" "$DLL.bak"
chmod u+w "$DLL"
"$DOTNET" "$PATCHER_DIR/out/patcher.dll" "$DLL"
echo "Patch applied. Restart the AL MCP server to pick up the change."

After Claude came up with this beauty², I could put this script into files/home/patch-al-crl.sh in my kit folder. That puts the script into the home folder of the agent, so that I could reference it in my kit in the startup commands, see lines 32/33 in the spec above. And that is also the reason why you see me stop and start the AL MCP Server in the screen recording as very first step.

I’ll try to work with both the Docker and the BC team to potentially come up with a better solution, but I am quite happy that it works and also seems to do so in a stable way!

in a definitely clunky way, but hey, it works 😊 ↩
actually really not a beauty, but again, hey, it works! ↩

Using Docker Sandbox Kits

Thu, 21 May 2026 10:24:07 +0000

Have you ever felt the urge to just let your AI agents run in YOLO mode, but been too much of a responsible adult to do that? Or seen that new MCP Server with the tempting functionality that is just an npx call away from being used, but some security training (or actually common sense) told you that this isn’t such a great idea? Not sure what that says about my character, but I certainly have. It’s really tempting to let those agents just do their thing and pull in all the MCPs you can get to make them more poweful, but do I really want to give them access to my machine, let them run scripts on it, control my containers, have access to credentials, send data to whereever? Or let one of those claws run my business or personal life with access to all my credentials? Actually, that’s a hard no.

So what can I do? Fortunately, Docker came up with a cool new technology to safeguard against those issues and keep the AI in check: Sandboxes (and Sandbox Kits, but more on that later).

The TL;DR

First let me show you how that actually works. Safety often comes at the price of increased complexity and decreased efficiency, so I want to show you how it easy it is to use Sandboxes, improved with Kits, to set up an environment that GitHub Copilot can securely use to develop for Dynamics 365 Business Central and get input from Azure DevOps. My point is not that Copilot can do that¹, but how easy it is to set up an environment dramatically ramping up the security of that approach, so I’ll only show the initialization and proof that the interactions work:

So why is this more secure? Check out the official docs linked above, but in a nutshell: You get to run your agent with MCPs and whatever else it might use in a hardened micro-VM, which means that it doesn’t have access to the filesystem (other than the workspace), environment or Docker daemon on your host. It also has networking policies, blocking access to everything you don’t allow and it has a very cool feature to inject credentials in a way so that they are not visible inside the micro-VM. If you want to learn more, check the following details. There I will be using Kits as you can also see with the --kit parameters in the video above, which are one way to customize Sandboxes (another is Templates, more on that potentially in another blog post).

The details: Why more secure - networking

To illustrate the networking part, I want to show you the first kit I am using. It enables the usage of the AL MCP Server through the ALTool provided by Microsoft:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
schemaVersion: "1"
kind: mixin
name: al
displayName: al
description: altool installation

network:
  allowedDomains:
    - dot.net
    - ci.dot.net
    - builds.dotnet.microsoft.com
    - api.nuget.org
    - "**.lencr.org"
    - fps-alpaca.westeurope.cloudapp.azure.com

commands:
  install:
    - command: "curl -fsSL https://dot.net/v1/dotnet-install.sh | bash -s -- --channel 8.0 && /home/agent/.dotnet/dotnet tool install --global Microsoft.Dynamics.BusinessCentral.Development.Tools"
      user: "1000"
      description: Install altool

I want to focus on the network part (lines 7-14): Here you can see that I need to give it access to a few dot.net and microsoft.com URLs as we first need to install dotnet 8 (more on installation in another detail chapter). Then we need nuget.org access to install the ALTool as it is provided as dotnet tool. And to interact with my Business Central instance running on COSMO Alpaca, the agent also has to reach the fps-alpaca… URL. The tricky one was the **.lencr.org as I ran into SSL errors. Those were caused by dotnet checking the validity of the Let’s Encrypt certificate also against online revocation lists, so I had to enable that as well.

Now why is this relevant: With this you make sure that an agent (potentially running in YOLO mode) isn’t up- or downloading secrets, information, scripts or whatever might be harmful to and from sources and targets that you don’t approve. It requires a bit more work to set it up, but makes it way more secure!

On a side note, Sandboxes come with three predefined policies for networking: “open”, which allows everything (in case you don’t want to use the feature); “balanced”, which blocks everything by default, but has some typical and trusted dev sites enabled (e.g. the basics you need for GitHub Copilot, Claude, etc.); and “locked down”, which just blocks everything. I have started with balanced, so I only had to take care of the special demands of my workload.

The details: Why more secure - credentials

For the second feature I want to highlight, credential injection, here is my second kit, which enables access to the Azure DevOps MCP:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
schemaVersion: "1"
kind: mixin
name: az-devops
displayName: az-devops
description: Azure DevOps

network:
  allowedDomains:
    - "**.dev.azure.com"
    - "**.visualstudio.com"
  serviceDomains:
    4psnl.visualstudio.com: az-devops
    dev.azure.com: az-devops
    mcp.dev.azure.com: az-devops
  serviceAuth:
    az-devops:
      headerName: Authorization
      valueFormat: "Basic %s"

credentials:
  sources:
    az-devops:
      env:
        - AZ_DEVOPS_PAT

environment:
  proxyManaged:
    - AZ_DEVOPS_PAT
    
commands:
  install:
    - command: "mkdir /usr/local/share/npm-global/lib"
      user: "1000"
      description: Create missing folder

First, you see the by now familiar network part with allowedDomains (lines 7-10), in this case allowing access to the “new” dev.azure.com and old visualstudio.com domains used for Azure DevOps. Now for the part required for credential injection:

First, we define serviceDomains (lines 11-14). Those are domains where we want credentials to be injected. So whenever a call is made to 4psnl.visualstudio.com, dev.azure.com or mcp.dev.azure.com, the az-devops configuration is used.
Second, we define the serviceAuth (lines 15-18), referenced in the serviceDomains. Here you can see the definition of the name of the header and how the value is to be formatted. The %s is replaced by a secret we define later on the host.
Third, we need to configure where the credential is coming from in the credentials (lines 20-24), in this case pointing to an env variable
As last step, we define the environment (lines 26-28), letting it know that it should come from a proxyManaged variable called AZ_DEVOPS_PAT

Now where is the actual value coming from? I ran this little one-liner on the host²:

1
echo "$([System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes("tfenster@4psbau.de:ep75nho5o3p727ezkwy4jsyjr4g6qkepyaqalwivmgcgrdhm5o5q")))" | sbx secret set -g az-devops

This defines the authentication token I want to use for the service, which will be injected into all traffic going to the domains configured above. That enables me to do something like this in my MCP configuration inside of the Sandbox:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  "mcpServers": {
    "az-devops": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@azure-devops/mcp",
        "4psnl",
        "--authentication",
        "pat"
      ],
      "env": {
        "PERSONAL_ACCESS_TOKEN": "don't think so"
      }
    }
  }
}

You can see in lines 10 and 11 that I am using a token (PAT = personal access token) for authentication, but I am not atually providing the token as you see in line 14. Instead, the Sandbox networking stack injects the token correctly, so I never need to share it with the MCP and it never is visible from within the Sandbox. Really nice, right?

The details: Another aspect of Sandbox Kits - installs

The last feature in Sandbox Kits I want to mention is the install section below commands, which covers things that run once at creation. There are also startup commands, which run on every startup, but I haven’t used those. The installs that I have used are for the MCPs and on the AL MCP, it’s a bit more complicated, as we first need dotnet and then install the ALTool via dotnet tool install:

1
2
3
4
5
commands:
  install:
    - command: "curl -fsSL https://dot.net/v1/dotnet-install.sh | bash -s -- --channel 8.0 && /home/agent/.dotnet/dotnet tool install --global Microsoft.Dynamics.BusinessCentral.Development.Tools"
      user: "1000"
      description: Install altool

As you can see, we can also set the user (ID) and description.

On the Azure DevOps MCP, the installation is actually done through the npx command in .mcp.json shown above, but that failed because of a missing folder. I could easily mitigate that with an install as well:

1
2
3
4
5
commands:
  install:
    - command: "mkdir /usr/local/share/npm-global/lib"
      user: "1000"
      description: Create missing folder

As you can see, this gives you all the flexibility you might need for setting up your toolchain and it also makes sure you get a very stable, reproducable environment.

The details: Claws…

An interesting aspect of the security model of Sandboxes, not connected to Kits, is that they run in micro-VMs, as explained in the beginning. One of the key reasons for that instead of running inside of a container is that some agents want to spin up containers, so Sandboxes need that ability to do that. But if they had access to the Docker daemon on the host, that would also give them access to other containers, again something that would create a security risk. Therefore, every Sandbox gets its own daemon inside of the micro-VM, not exposing any of the other containers potentially running.

That enables a very secure environment also for personal assistants like nanoclaw. Therefore, it was a great fit and as you can see here, that triggered a collaboration. I found it very interesting to see how a setup mostly aimed at developer security and productivity also is such a nice solution for a personal assistant, which is why I also wanted to mention that here.

you’ve seen that more than enough times by now, right? ↩
Don’t worry, this isn’t my real token ↩

Easier network access for AI Runway

Sat, 25 Apr 2026 08:06:54 +0000

I recently blogged about using AI Runway, but the networking setup was not ideal. The reason for that was that I couldn’t get the setup recommended by the AI Runway team up and running, but with their help I could figure it out. Therefore, this is just a small update on how that works.

The TL;DR

In the previous blog post, I created a dedicated Traefik ingress per model, which is of course not ideal. Instead, having a single gateway with the Gateway API Inference Extension which addresses the right model based on the request makes sense and that is also what the AI Runway docs suggest. With that in place and Llama-3.2:1B deployed, something like this works where 20.170.89.88 is the IP of the gateway

Request

1
2
3
4
POST http://20.170.89.88/v1/chat/completions
Content-Type: application/json

{"model": "llama-3.2-1b-instruct", "messages": [{"role": "user", "content": "who are you?"}]}

Response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
HTTP/1.1 200 OK
x-envoy-upstream-service-time: 1391
x-went-into-resp-headers: true
content-type: application/json
x-correlation-id: d691d871-689c-48c3-a2af-a7a3eef237c0
date: Sun, 26 Apr 2026 09:14:16 GMT
server: istio-envoy
connection: close
transfer-encoding: chunked

{
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "message": {
        "content": "I'm an artificial intelligence model known as Llama. Llama stands for \"Large Language Model Meta AI.\"",
        "role": "assistant"
      }
    }
  ],
  "created": 1777194855,
  "id": "d98279a5-6588-464a-8245-40e20b4a9220",
  "model": "llama-3.2-1b-instruct",
  "object": "chat.completion",
  "usage": {
    "completion_tokens": 23,
    "prompt_tokens": 15,
    "total_tokens": 38
  }
}

This might look similar to before, but I can now also deploy e.g. Gemma2:2B and do something like the following. Note that only the model in the request body changes

Request

1
2
3
4
POST http://20.170.89.88/v1/chat/completions
Content-Type: application/json

{"model": "gemma-2-2b-instruct", "messages": [{"role": "user", "content": "who are you?"}]}

Response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
HTTP/1.1 200 OK
x-envoy-upstream-service-time: 16533
x-went-into-resp-headers: true
date: Sun, 26 Apr 2026 09:16:58 GMT
content-type: application/json
x-correlation-id: da4973c9-721d-46fb-b237-b420e805b6ca
server: istio-envoy
connection: close
transfer-encoding: chunked

{
  "choices": [
    {
      "finish_reason": "stop",
      "index": 0,
      "message": {
        "content": "I am Gemma, an open-weights AI assistant. I'm a large language model, created by the Gemma team. I can generate text, translate languages, write different kinds of creative content, and answer your questions in an informative way. \n\nThink of me as a friendly AI companion who loves to chat and explore ideas with you!  😊  \n",
        "role": "assistant"
      }
    }
  ],
  "created": 1777195003,
  "id": "ddefa22d-70df-4e14-8c94-8f2a3684446c",
  "model": "gemma-2-2b-instruct",
  "object": "chat.completion",
  "usage": {
    "completion_tokens": 74,
    "prompt_tokens": 13,
    "total_tokens": 87
  }
}

Nice, right? As the setup is actually straight forward and it was more a failure on my side to do it right (and a small issue in AI Runway) that prevented it from working last time, there are not a lot of details to share. But if you want a step by step instruction on how to set it up, check the next section.

The details: Istio and body-based router

First we need the Gateway API and the Inference Extension as explained above:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PWSH C:\Users\tobia> kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml
customresourcedefinition.apiextensions.k8s.io/backendtlspolicies.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/gatewayclasses.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/gateways.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/grpcroutes.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/listenersets.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/referencegrants.gateway.networking.k8s.io created
customresourcedefinition.apiextensions.k8s.io/tlsroutes.gateway.networking.k8s.io created
validatingadmissionpolicy.admissionregistration.k8s.io/safe-upgrades.gateway.networking.k8s.io created
validatingadmissionpolicybinding.admissionregistration.k8s.io/safe-upgrades.gateway.networking.k8s.io created
PWSH C:\Users\tobia> kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.3.1/manifests.yaml
customresourcedefinition.apiextensions.k8s.io/inferencemodelrewrites.inference.networking.x-k8s.io created
Warning: resource customresourcedefinitions/inferenceobjectives.inference.networking.x-k8s.io is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/inferenceobjectives.inference.networking.x-k8s.io configured
customresourcedefinition.apiextensions.k8s.io/inferencepoolimports.inference.networking.x-k8s.io created
Warning: resource customresourcedefinitions/inferencepools.inference.networking.k8s.io is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
customresourcedefinition.apiextensions.k8s.io/inferencepools.inference.networking.k8s.io configured
customresourcedefinition.apiextensions.k8s.io/inferencepools.inference.networking.x-k8s.io created

Then we install Istio. Notable is the ENABLE_GATEWAY_API_INFERENCE_EXTENSION setting:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
PWSH C:\Users\tobia> istioctl install --set values.pilot.env.ENABLE_GATEWAY_API_INFERENCE_EXTENSION=true
        |\
        | \
        |  \
        |   \
      /||    \
     / ||     \
    /  ||      \
   /   ||       \
  /    ||        \
 /     ||         \
/______||__________\
____________________
  \__       _____/
     \_____/

This will install the Istio 1.29.1 profile "default" into the cluster. Proceed? (y/N) y
✔ Istio core installed ⛵️
✔ Istiod installed 🧠
✔ Ingress gateways installed 🛬
✔ Installation complete

With that, the base requirements are in place and we can create the inference gateway and deploy the body-based router:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
PWSH C:\Users\tobia> kubectl create namespace gateway
namespace/gateway created
PWSH C:\Users\tobia> @"
>> apiVersion: gateway.networking.k8s.io/v1
>> kind: Gateway
>> metadata:
>>   name: inference-gateway
>>   namespace: gateway
>> spec:
>>   gatewayClassName: istio  # Change to match your implementation
>>   infrastructure:
>>     annotations:
>>       # Required on AKS with Istio. Azure otherwise probes GET / on port 80,
>>       # but the gateway returns 404 there and the public IP can time out.
>>       service.beta.kubernetes.io/port_80_health-probe_protocol: tcp
>>   listeners:
>>     - name: http
>>       protocol: HTTP
>>       port: 80
>> "@ | kubectl apply -f -
gateway.gateway.networking.k8s.io/inference-gateway created
PWSH C:\Users\tobia> helm install body-based-router -n gateway --set provider.name=istio --version v1.3.1 oci://registry.k8s.io/gateway-api-inference-extension/charts/body-based-routing
Pulled: registry.k8s.io/gateway-api-inference-extension/charts/body-based-routing:v1.3.1
Digest: sha256:aedc6a36cdf1bf34d41886c525275b26711ce15996affc39d4eb94cd1f0f2dc8
I0426 10:47:03.065464   35936 warnings.go:110] "Warning: EnvoyFilter exposes internal implementation details that may change at any time. Prefer other APIs if possible, and exercise extreme caution, especially around upgrades."
NAME: body-based-router
LAST DEPLOYED: Sun Apr 26 10:47:02 2026
NAMESPACE: gateway
STATUS: deployed
REVISION: 1
DESCRIPTION: Install complete
TEST SUITE: None
NOTES:
Body-based routing extension deployed.

And that’s already it. We only need to figure out what the IP for our gateway is, e.g. like this

1
2
3
PWSH C:\Users\tobia> kubectl get gateway -n gateway inference-gateway
NAME                CLASS   ADDRESS        PROGRAMMED   AGE
inference-gateway   istio   20.170.89.88   True         15s

Or we can take a look into the AI Runway settings, which give us the same information

After deploying models as explained in the last blog post, we can now run inference against that IP as shown above. If you look into the deployments in the AI Runway dashboard, you even get a ready to run example

Just copy/pasting it works like a charm:

1
2
PWSH C:\Users\tobia> curl http://20.170.89.88/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "gemma-2-2b-instruct", "messages": [{"role": "user", "content": "Hello"}]}'
{"choices":[{"finish_reason":"stop","index":0,"message":{"content":"Hello! 👋  \n\nHow can I help you today? 😊 \n","role":"assistant"}}],"created":1777196088,"id":"b116b6f2-7b36-4f71-9f40-49266b9830d3","model":"gemma-2-2b-instruct","object":"chat.completion","usage":{"completion_tokens":16,"prompt_tokens":10,"total_tokens":26}}

Thanks to the AI Runway team, this is an amazingly easy starting point into running LLMs on your own Kubernetes backend!

Deploy LLMs on Azure Kubernetes Service with AI Runway

Tue, 31 Mar 2026 19:24:45 +0000

At this year’s MVP Summit, I joined a session with the one and only Brendan Burns where I first heard about AI Runway. The idea immediately caught my attention: run an LLM in your own environment, under your full control, but still with a very user-friendly experience. No mystery backend, no black box SaaS dependency, just your own Kubernetes cluster and a clean workflow.

In this post, I’ll walk through how I set this up on an Azure Kubernetes Service (AKS) cluster with the Kubernetes AI Toolchain Operator (KAITO) and Traefik traefik.

The TL;DR

If you want the short version: you can deploy an LLM on your own Kubernetes cluster in a surprisingly easy way using KAITO and AI Runway, manage it through a friendly dashboard, and expose both dashboard and model endpoints safely through Traefik with TLS.

To give you an idea, this is what the dashboard looks like:

And this is a deployment of an LLM in KAITO:

The details: Create the AKS cluster and install KAITO

Let’s start with the cluster and the AI toolchain foundation. I used these PowerShell environment variables first:

1
2
3
4
5
6
$env:AZURE_SUBSCRIPTION_ID="<your-subscription-id>"
$env:AZURE_RESOURCE_GROUP="airunway"
$env:AZURE_LOCATION="germanywestcentral"
$env:CLUSTER_NAME="cluster"
$env:DNS_LABEL="tfe-airunway"
$env:LE_EMAIL="you@example.com"

You would of course need to adjust those according to your subscription data and your preferences. Then create the resource group, AKS cluster, and a dedicated node pool for model workloads:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
az group create --name $env:AZURE_RESOURCE_GROUP --location $env:AZURE_LOCATION

az aks create \
	--location $env:AZURE_LOCATION \
	--resource-group $env:AZURE_RESOURCE_GROUP \
	--name $env:CLUSTER_NAME \
	--enable-oidc-issuer \
	--generate-ssh-keys

az aks nodepool add \
	--resource-group $env:AZURE_RESOURCE_GROUP \
	--cluster-name $env:CLUSTER_NAME \
	--name models \
	--node-count 1 \
	--min-count 1 \
	--max-count 10 \
	--node-vm-size Standard_D8ds_v5 \
	--enable-cluster-autoscaler

az aks get-credentials --resource-group $env:AZURE_RESOURCE_GROUP --name $env:CLUSTER_NAME --overwrite-existing

Note that we are using the Standard_D8ds_v5 VM size which includes only CPUs and no GPUs because I couldn’t get any VMs with GPUs at the moment on Azure for my dev/test subscription. But KAITO can also run CPU-only models.

With the cluster in place, install KAITO:

1
2
3
4
5
helm repo add kaito https://kaito-project.github.io/kaito/charts/kaito
helm install kaito-workspace kaito/workspace \
	--namespace kaito-workspace \
	--create-namespace \
	--set featureGates.disableNodeAutoProvisioning=true

That gives you the Kubernetes-native model management layer we need for the next steps.

The details: Add AI Runway and expose the dashboard through Traefik

Next, install AI Runway itself:

1
2
3
kubectl apply -f https://raw.githubusercontent.com/kaito-project/airunway/main/deploy/controller.yaml
kubectl apply -f https://raw.githubusercontent.com/kaito-project/airunway/main/deploy/dashboard.yaml
kubectl apply -f https://raw.githubusercontent.com/kaito-project/airunway/refs/heads/main/providers/kaito/deploy/kaito.yaml

To make the dashboard available from the internet, I installed Traefik and configured ACME/Let’s Encrypt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
helm repo add traefik https://traefik.github.io/charts
helm repo update

@"
ingressClass:
	enabled: true
	isDefaultClass: false
	name: traefik

providers:
	kubernetesIngress:
		enabled: true
	kubernetesGateway:
		enabled: false
	kubernetesCRD:
		enabled: true

logs:
	access:
		enabled: true
		format: common

service:
	annotations:
		service.beta.kubernetes.io/azure-dns-label-name: $env:DNS_LABEL

additionalArguments:
	- --certificatesresolvers.le.acme.email=$env:LE_EMAIL
	- --certificatesresolvers.le.acme.storage=/data/acme.json
	- --certificatesresolvers.le.acme.tlschallenge=true
	- --certificatesresolvers.le.acme.httpchallenge=true
	- --certificatesresolvers.le.acme.httpchallenge.entrypoint=web
"@ | helm upgrade --install traefik traefik/traefik `
	--namespace traefik `
	--create-namespace `
	--wait --timeout 10m `
	-f -

And this Ingress publishes the AI Runway dashboard:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
@"
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
	name: dashboard-ingress
	namespace: airunway-system
	annotations:
		traefik.ingress.kubernetes.io/router.entrypoints: websecure
		traefik.ingress.kubernetes.io/router.tls: "true"
		traefik.ingress.kubernetes.io/router.tls.certresolver: le
spec:
	ingressClassName: traefik
	tls:
	- hosts:
		- $env:DNS_LABEL.$env:AZURE_LOCATION.cloudapp.azure.com
	rules:
	- host: $env:DNS_LABEL.$env:AZURE_LOCATION.cloudapp.azure.com
		http:
			paths:
			- path: /
				pathType: Prefix
				backend:
					service:
						name: airunway
						port:
							number: 80
"@ | kubectl apply -f -

Now you can open the dashboard as is visible in the screenshot above and start deploying models from the UI.

The details: Deploy your first model, expose it, and test over HTTP

From the AI Runway dashboard, deploy llama3.2:1b first. Once it is running, expose the model service via Traefik as well. I used a middleware to strip an /openai prefix so the backend receives the expected path and because that is the way Microsoft Foundry exposes models.

Update: If you want a better, more flexible way to implement network access to the models, check this later blog post

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
@"
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
	name: strip-openai
	namespace: kaito-workspace
spec:
	stripPrefix:
		prefixes:
			- /openai
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
	name: llm-ingress
	namespace: kaito-workspace
	annotations:
		traefik.ingress.kubernetes.io/router.entrypoints: websecure
		traefik.ingress.kubernetes.io/router.tls: "true"
		traefik.ingress.kubernetes.io/router.tls.certresolver: le
		traefik.ingress.kubernetes.io/router.middlewares: kaito-workspace-strip-openai@kubernetescrd
spec:
	ingressClassName: traefik
	tls:
	- hosts:
		- $env:DNS_LABEL.$env:AZURE_LOCATION.cloudapp.azure.com
	rules:
	- host: $env:DNS_LABEL.$env:AZURE_LOCATION.cloudapp.azure.com
		http:
			paths:
			- path: /openai
				pathType: Prefix
				backend:
					service:
						name: llama3-2-1b-vqck
						port:
							number: 80
"@ | kubectl apply -f -

Finally, a first HTTP test against the OpenAI-compatible API endpoint:

1
2
3
4
5
6
7
8
9
10
11
12
POST https://tfe-airunway.germanywestcentral.cloudapp.azure.com/openai/v1/chat/completions
Content-Type: application/json

{
	"model": "llama-3.2-1b-instruct",
	"messages": [
		{
			"role": "user",
			"content": "generate a powershell script to recursively analyze the size of my home folder to a maximum depth of 5 levels"
		}
	]
}

The response will look something like this

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
HTTP/1.1 200 OK
Content-Type: application/json
Date: Tue, 31 Mar 2026 19:43:37 GMT
X-Correlation-Id: b3916e7e-b077-437a-bbbc-59c966d20c9e
Connection: close
Transfer-Encoding: chunked

{
  "created": 1774986196,
  "object": "chat.completion",
  "id": "14e7cc35-e81a-4616-bbce-70067f2a324e",
  "model": "llama-3.2-1b-instruct",
  "choices": [
    {
      "index": 0,
      "finish_reason": "stop",
      "message": {
        "role": "assistant",
        "content": "Here is a PowerShell script that recursively analyzes the size of your home folder to a maximum depth of 5 levels:\n```powershell\n# Get the current user's home directory\n$homeDir = Get-Location\n\n# Set the maximum depth\n$maxDepth = 5\n\n# Define the recursion function\nfunction Get-Size {\n    param ($path)\n\n    # Get the file count\n    Get-ChildItem -Path $path -Recurse | Measure-Object\n\n    # Get the size of each item\n    Get-ChildItem -Path $path | ForEach-Object {\n        Get-Size $_.FullName\n        Write-Host \"  \"\n        $itemSize = $_.Size\n        Write-Host $itemSize\n    }\n}\n\n# Call the function with the home directory\nGet-Size $homeDir\n```\nLet me explain what this script does:\n\n1. It gets the current user's home directory.\n2. It sets the maximum depth of the recursion to 5 levels.\n3. It defines a function `Get-Size` that takes a path as input and performs the following steps:\n\t* Gets the file count using `Get-ChildItem`.\n\t* Gets the size of each item using `Get-ChildItem` and `Measure-Object`.\n\t* Prints the size of each item, prefixed with a column of hyphens to indicate the depth of the item.\n4. Finally, the script calls the `Get-Size` function with the current user's home directory.\n\nTo use this script, simply copy and paste it into PowerShell, and it will recursively analyze the size of your home folder to a maximum depth of 5 levels. The output will be something like this:\n```\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n    -\n    -Size:\n        100KB\n        4KB\n        800KB\n        4KB\n        800KB\n        4KB\n        800KB\n```\nNote that this script will not be suitable for very large home directories, as it can take a significant amount of time to run. Also, be careful when running this script, as it will modify the file system of the current user."
      }
    }
  ],
  "usage": {
    "prompt_tokens": 33,
    "completion_tokens": 731,
    "total_tokens": 764
  }
}

This is what I really like about the setup: from zero to a working, externally reachable LLM endpoint with a proper dashboard and your own infrastructure control in a short amount of time.

The details: Using it with Business Central

I tried to set up the OpenAI integration in Microsoft Dynamics 365 Business Central as shown in the BC Tech sample for that topic, but that doesn’t work. I even don’t see a request coming in, so it looks to me like BC is somehow validating that it takes to Microsoft Foundry and not something that looks very similar. A pity…

But as I showed before, we can use the Business Central MCP Server e.g. in VS Code. You can configure your model there as “OpenAI compatible” like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    {
        "name": "AI Runway",
        "vendor": "customoai",
        "models": [
            {
                "id": "llama-3.2-1b-instruct",
                "name": "LLaMA 3.2:1B",
                "url": "https://tfe-airunway.germanywestcentral.cloudapp.azure.com/openai",
                "toolCalling": true,
                "vision": false,
                "maxInputTokens": 128000,
                "maxOutputTokens": 16000
            }
        ]
    }

With this in place and an MCP configuration like explained in the previous blog post, you can experiment with the BC MCP and the capabilities of different models. While e.g. the model I used above is quite small, it gave surprisingly good results in this context, but depending on what you want to achieve, your response might of course be different.

Using MCPs with GitHub Copilot without installing anything locally

Tue, 17 Mar 2026 21:44:59 +0000

MCP servers have radically changed how LLMs interact with resources outside their training data, and developers are already relying on them to get dramatically better results. But what if you are not a developer and still want to make use of them, but don’t want to install “developer stuff” on your machine? Or if you can’t or don’t want to install those MCP servers locally (and there are very good reasons for not doing that, more on that in a later blog post)? I’ll show you a setup which solves that problem. My scenario is that of a product manager working with Microsoft Dynamics 365 Business Central (BC). The code and user stories live in Azure DevOps, but that could easily also be GitHub and Jira or whatever you use. We will use the Azure DevOps MCP server as well as the AL Symbols MCP server.

The TL;DR

To just give it a try, go to https://github.com/tfenster/codespace-mcp, fork the repo and create a codespace through the “Code” action in the top right

Then you need to run az login in a terminal to connect to your Azure account. If you also want to interact with the structures of Business Central, you need to run the AL: Download symbols action or put other extensions you might want to reference into the .alpackages folder. Now all that is left to do is to start the MCP servers by opening the .vscode/mcp.json file and clicking on the “start” action. The Azure DevOps MCP will ask for the name of your organization, while the AL symbols MCP just starts.

With that in place, you can use GitHub Copilot to ask a question like “check work item 33 in project mcp-demo. Can you find any functionality in the AL symbols found in my workspace that would help me fulfill the requirement?” Work item 33 in my example is actually quite bad, it only has “We want the customers to be categorizable. The available categories shall be A, B and C” as description. Also the prompt isn’t great, but that’s not the point I want to make here. Copilot now does things like this:

I’ll help you check work item 33 and find relevant AL symbols in your workspace. Let me start by fetching the work item details.

Fetched work item 33 from mcp-demo project
Ran wit_get_work_item - azdo (MCP Server)
Searched for Customer-related objects in workspace

Now let me search your workspace for AL objects related to customers and categorization:

Ran al_packages - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed content from specified lines
Ran al_get_object_definition - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed 3 files
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed content.json, lines 1 to 200
Ran al_search_objects - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Reviewed content.json, lines 1 to 100

Summary: Work Item 33 Analysis

Requirement: “New customer categorization - We want the customers to be categorizable. The available categories shall be A, B and C”

Relevant AL Functionality Found in Your Workspace:

1. Customer Table (ID 18, Base Application)

Main table for customer data in your Dynamics 365 Business Central system

Currently has fields for classification, customer groups, and other metadata

This is the primary table you’ll need to extend to add categorization

2. Enum Pattern Examples Your workspace contains several enumeration patterns you can reference:

User Plan Experience (ID 9005) - Shows multi-value enum structure (Basic, Essentials, Premium, Other)

No. Series Implementation (ID 397) - Simpler two-value pattern

These demonstrate the standard syntax for creating choice fields

3. Table Extension Pattern

Serv. Customer Templ. (TableExtension ID 6451) shows how to extend the Customer Template table

Demonstrates field definitions with proper properties like Caption, DataClassification, and TableRelation

This pattern can be followed to add categorization functionality

Recommended Implementation Approach:

Create an Enum for customer categories with values A, B, and C

Extend the Customer Table using a TableExtension to add a new field for the category

Add UI controls (likely in a Customer page extension) to allow selection between the three categories

Use standard properties: Caption, OptionString/OptionMembers, and DataClassification

The enumeration and table extension patterns already exist in your system, so you can follow those established conventions for a consistent implementation.

Is this the most astonishing use of AI or the best solution for the requirement? Both definitely not. The point is something different: Copilot interacted with Azure DevOps (e.g. Ran wit_get_work_item - azdo (MCP Server)) and the AL extensions in the folder (e.g. Ran al_get_object_definition - al-symbols-mcp (MCP Server) or Ran al_search_objects - al-symbols-mcp (MCP Server)) to find answers to the question we ask. Without having to install anything potentially harmful locally. So if you struggle to provide GitHub Copilot with the right context and information to work on your requirements, this might be an easy way to make you faster, more efficient and provide higher quality to whoever has to pick up your requirements.

The details: Other interactions you might like

Other interactions with your content could be the following:

“what are acceptance criteria I might want to add to that work item”
After a bit of back and forth you will probably get a suitable list. Now you could try “please directly add them to the work item” and a call like Ran wit_update_work_item - azdo (MCP Server) would improve your work item like this

“what are other aspects i need to think about when validating this requirement”
This time, Copilot didn’t use any of the MCP tools, but came up with topics like business semantics, lifecycle rules, backward compatibility & migration, UI & usability, data quality controls, process impact, reporting & analytics, security & compliance, non-functional & operability and edge cases. Maybe not all of them are relevant, but certainly a good idea to think about those aspects briefly

“which standard features could I use to meet the requirement without coding”
Here Copilot again interacted with my local symbols

Ran al_search_objects - al-symbols-mcp (MCP Server) (did that 4 times)
Reviewed content.json, lines 1 to 80
Ran al_get_object_summary - al-symbols-mcp (MCP Server)
Ran al_search_objects - al-symbols-mcp (MCP Server)
Now let me get the full list of Customer table fields to identify what grouping/classification fields already exist.
Ran al_get_object_definition - al-symbols-mcp (MCP Server)
Ran terminal command: cat "/home/codespace/.vscode-remote/data/User/works...
Reviewed content from specified file

Good picture from the field list. Now I can give you a thorough, grounded answer based on what’s actually in your BC symbols.

Here are the standard BC features that could meet the requirement without any AL coding, ranked by fit:

Best fit — Dimensions

Global Dimension 1/2 Code (fields 16/17) or an additional dimension:

Create a new Dimension (e.g. CUST-CATEGORY) with Dimension Values A, B, C.

The Customer Card has a Dimensions action out of the box.

Filtering by dimension value works natively in Customer List, and in all standard reports.

Values are validated against the Dimension Values table, so only A/B/C are possible.

Limitation: the category doesn’t appear as a direct column on the Customer Card/List; it lives behind the Dimensions action, which may not match the business’s UX expectation.

Good fit — Customer Price Group (field 23, Customer Price Group table)

Create three Price Groups named A, B, C.

The field is already visible on the Customer Card (Invoicing FastTab).

Supports list filtering and look-up.

Limitation: semantically tied to pricing — if the business assigns it a non-price meaning it can cause confusion, and it may interfere with price calculation logic.

Reasonable fit — Territory Code (field 15, Territory table)

Create Territories A, B, C.

Already present on the Customer Card.

No strong semantic tie to other BC processes.

Limitation: Territory has its own reporting context (sales by territory) — reusing it for categorization pollutes that.

Possible fit — Customer Disc. Group (field 34, Customer Discount Group table)

Create discount groups A, B, C.

Visible on Customer Card.

Limitation: semantically tied to discount rules — same confusion risk as Price Group.

Limited fit — Statistics Group (field 26, Integer)

An integer field for segmenting customers in statistics.

Validated by being an integer — you could use 1=A, 2=B, 3=C.

Limitation: not user-friendly (shows numbers, not A/B/C labels), not directly filterable by label, and the field is often hidden in standard page layouts.

Summary recommendation

Option Label visible Direct card field Clean semantics Validated values

Dimension ✗ (behind action) ✗ ✓ ✓

Customer Price Group ✓ ✓ ✗ ✓

Territory Code ✓ ✓ ✓ (neutral) ✓

Customer Disc. Group ✓ ✓ ✗ ✓

Statistics Group ✗ (integer, hidden) ✓ (hidden) ✓ ✗

If the business can accept a slightly repurposed field: Territory Code is the cleanest no-code option — it’s neutral, already on the card, and supports A/B/C values with validation.

If UX purity matters (the field should be called “Customer Category”): none of these fully satisfy the requirement without at least a minor configuration step — you would need AL code to add and properly label a new field, or use Dimensions and accept the UX trade-off.

Option	Label visible	Direct card field	Clean semantics	Validated values
Dimension	✗ (behind action)	✗	✓	✓
Customer Price Group	✓	✓	✗	✓
Territory Code	✓	✓	✓ (neutral)	✓
Customer Disc. Group	✓	✓	✗	✓
Statistics Group	✗ (integer, hidden)	✓ (hidden)	✓	✗

Do I agree with all of this or does it even all make sense? I would say there are very good arguments to immediately dismiss some of them and basic BC knowledge would probably get you further. But imagine you are in a situation where you have an ISV solution that you don’t fully know or have limited documentation, but only the symbols. Or you just want to validate that you haven’t missed anything obvious. Then this could be a very helpful starting point.

“do i have any conflicting requirements in my backlog”

For this, Copilot looked at my backlog and identified a conflicting requirement

Let me pull the full backlog to check all work items against this requirement.

Ran wit_list_backlogs - azdo (MCP Server)
Ran wit_list_backlog_work_items - azdo (MCP Server)
Ran wit_get_work_items_batch_by_ids - azdo (MCP Server)

Yes — there is a direct conflict. Your backlog has two work items that describe the same feature with incompatible specifications:

Work Item 33 Work Item 34

Title New customer categorization New customer categories

Categories A, B, C Silver, Gold, Platinum

State New New

They are describing the same thing — a customer categorization field — but with different value sets. Implementing both would mean two overlapping classification fields on the customer, or one implementation that has to be changed right after the other is delivered.

This needs a decision before any code is written:

Are these the same requirement? If so, one should be closed as duplicate and the surviving one updated with the agreed value set (A/B/C labels, or Silver/Gold/Platinum, or perhaps both — e.g. A=Silver, B=Gold, C=Platinum).

Are these intentionally different fields? If the business wants both a tier label (Silver/Gold/Platinum) and a separate internal code (A/B/C), both IDs and field names need to be distinct and each work item should be clarified accordingly.

Would you like me to link them as duplicates, add a comment flagging the conflict, or update one of them?

	Work Item 33	Work Item 34
Title	New customer categorization	New customer categories
Categories	A, B, C	Silver, Gold, Platinum
State	New	New

This obviously was an easily identifiable one, but again, imagine yourself in a situation with a lot of requirements, potentially from a time when you weren’t working with a particular product where it might not be that easy to spot duplicates. Running it through Copilot could be highly valuable.

I hope this gave you some ideas about how to use the Azure DevOps and AL MCP servers to interact with and improve your requirements. And as mentioned in the beginning, even if you use a different toolset, by now chances are quite high that you can access it through an MCP server.

The details: Setup and configuration

If you are still following along and are techie enough to care about the technical setup, it is based on two files: devcontainer.json defines the container that makes up the Codespace:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
  "name": "MCP Codespace",
  "features": {
    "ghcr.io/devcontainers/features/node:1": {
      "version": "20"
    },
    "ghcr.io/devcontainers/features/azure-cli:1": {}
  },
  "postCreateCommand": "npm install -g @azure-devops/mcp",
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-dynamics-smb.al"
      ]
    }
  }
}

You can see that Node.js is added as a feature (lines 4-6) because we need that for the MCP servers. You also see the Azure CLI (line 7) needed for the authentication against Azure DevOps. Next, the installation of the Azure DevOps MCP server happens after the container is created via line 9 and last but not least, the VS Code AL extension is added via lines 10-16.

The MCP servers are configured in mcp.json:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "inputs": [
    {
      "id": "azdo_org",
      "type": "promptString",
      "description": "Azure DevOps organization name (e.g. 'contoso')"
    }
  ],
  "servers": {
    "azdo": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "${input:azdo_org}", "-d", "core", "work", "work-items", "test-plans"]
    },
    "al-symbols-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["al-mcp-server"]
    }
  }
}

Lines 2-8 define one input, in this case the Azure DevOps organization, which is later used in line 13 as part of the configuration of the Azure DevOps MCP Server (lines 9-14). Very similarly, the AL symbols MCP server is configured in 15-20. Pretty simple and straightforward, with the only exception maybe the configuration of the modules of Azure DevOps that you want to make available in line 13 as well. In this case, only the core, work, work-items and test-plans modules are activated.

Lessons learned for AI assistant usage with Docker Model Runner on ARM Windows

Sun, 01 Feb 2026 19:25:33 +0000

This is just a quick one to share two lessons I learned in the last few days when working with AI assistants and Docker Model Runner

Lesson 1: If you can’t connect, there might be an easy fix

Working with an ARM-based Windows laptop is fantastic, but it comes with a few drawbacks. I encountered one of these when I tried to follow a Docker Blog post about OpenCode with DMR. OpenCode is an open source AI coding agent and the blog post explains how you can connect it to DMR. As I have a Qualcomm Adreno GPU, I wanted to use that for inference, but here things got a bit tricky:

Windows (ARM) supports the Qualcomm 6xx series or later through the llama.cpp engine
Windows with WSL2 supports NVIDIA CUDA GPUs

This means that while I can technically run Docker Model Runner in WSL2, that setup can’t use my GPU. Unfortunately, OpenCode doesn’t support Windows ARM at the moment. That means that I have to use DMR running on the Windows “host” while OpenCode is running in WSL. Not a problem at first glance, because OpenCode connects to DMR via TCP (typically http://localhost:12434) anyway. But if you keep the networking defaults, then localhost in WSL os something different to localhost on the Windows host. You can often reach the same stuff from WSL by using host.docker.internal, but that doesn’t work in this case because DMR only listens on 127.0.0.1.

But when I adressed this to the Docker team¹, I was made aware of mirrored mode networking for WSL. If that is in place, the issue is no longer there, because to quote from the docs: “Connect to Windows servers from within Linux using the localhost address 127.0.0.1”. So now I can talk to localhost from WSL and get the same TCP connection as from the Windows host. That means that doing a curl to localhost as you see in the following screenshot hits DMR on the Windows side, hence giving me accelerated GPU inference.

The setup is explained well in the link mentioned above, but here is the configuration that works for me:

1
2
[wsl2]
networkingMode=mirrored

Lesson 2: Don’t just assume it works, but check

When I first tried to work with the GPU-based inference, I just assumed it works as I had looked up the documentation. However, that wasn’t true. docker model status revealed that llama.cpp failed to install:

1
2
3
Status:
llama.cpp: failed to install llama.cpp: Get "https://hub.docker.com/v2/namespaces/docker/repositories/docker-model-backend-llamacpp/tags/latest-opencl": dialing hub.docker.com:443 host via direct connection because Docker Desktop has no HTTPS proxy: connecting to hub.docker.com:443: dial tcp: lookup hub.docker.com: no such host
vllm: not installed

After setting DNS to 1.1.1.1 and 8.8.8.8 in my Docker Engine config like you see in the following snippet, the lookup worked:

1
2
3
4
5
6
7
8
{
  ...
  "dns": [
    "8.8.8.8",
    "1.1.1.1"
  ],
  ...
}

Restarting Docker Desktop then lead to the following docker model status output

1
2
3
4
5
6
docker model status
Docker Model Runner is running

Status:
llama.cpp: running llama.cpp latest-opencl (sha256:e12549787dbbb3b2c2e5d7a452edf7d64cd5a4a492679cc366b02f05d0efcc11) version: 091a46c
vllm: not installed

I also found the following entries in the ~\AppData\Local\Docker\log\host\inference-llama.cpp-server.log log:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[2026-01-28T13:36:52.100268000Z] ggml_opencl: selected platform: 'QUALCOMM Snapdragon(TM)'
[2026-01-28T13:36:52.109192500Z] 
[2026-01-28T13:36:52.109192500Z] ggml_opencl: device: 'Qualcomm(R) Adreno(TM) X1-85 GPU (OpenCL 3.0 Qualcomm(R) Adreno(TM) X1-85 GPU)'
[2026-01-28T13:36:52.109192500Z] ggml_opencl: OpenCL driver: OpenCL 3.0 QUALCOMM build: 827.0 Compiler DX.18.05.00
[2026-01-28T13:36:52.109192500Z] ggml_opencl: vector subgroup broadcast support: true
[2026-01-28T13:36:52.109192500Z] ggml_opencl: device FP16 support: true
[2026-01-28T13:36:52.109192500Z] ggml_opencl: mem base addr align: 128
[2026-01-28T13:36:52.109192500Z] ggml_opencl: max mem alloc size: 2048 MB
[2026-01-28T13:36:52.109192500Z] ggml_opencl: device max workgroup size: 1024
[2026-01-28T13:36:52.109192500Z] ggml_opencl: SVM coarse grain buffer support: false
[2026-01-28T13:36:52.109192500Z] ggml_opencl: SVM fine grain buffer support: false
[2026-01-28T13:36:52.109788100Z] ggml_opencl: SVM fine grain system support: false
[2026-01-28T13:36:52.109788100Z] ggml_opencl: SVM atomics support: false
[2026-01-28T13:36:52.110290100Z] ggml_opencl: flattening quantized weights representation as struct of arrays (GGML_OPENCL_SOA_Q)
[2026-01-28T13:36:52.110290100Z] ggml_opencl: using kernels optimized for Adreno (GGML_OPENCL_USE_ADRENO_KERNELS)
[2026-01-28T13:37:12.093103100Z] ggml_opencl: loading OpenCL kernels.............................................................................
[2026-01-28T13:37:12.142341200Z] ggml_opencl: default device: 'Qualcomm(R) Adreno(TM) X1-85 GPU (OpenCL 3.0 Qualcomm(R) Adreno(TM) X1-85 GPU)'
[2026-01-28T13:37:12.153408400Z] main: setting n_parallel = 4 and kv_unified = true (add -kvu to disable this)
[2026-01-28T13:37:12.153408400Z] build: 1 (34ce48d) with Clang 19.1.7 for Windows ARM64
[2026-01-28T13:37:12.153408400Z] system info: n_threads = 6, n_threads_batch = 6, total_threads = 12
[2026-01-28T13:37:12.153408400Z] 
[2026-01-28T13:37:12.157120900Z] system_info: n_threads = 6 (n_threads_batch = 6) / 12 | CPU : NEON = 1 | ARM_FMA = 1 | LLAMAFILE = 1 | REPACK = 1 | 
[2026-01-28T13:37:12.157120900Z] 
[2026-01-28T13:37:12.157120900Z] init: using 11 threads for HTTP server
[2026-01-28T13:37:12.158494800Z] start: setting address family to AF_UNIX
[2026-01-28T13:37:12.165082800Z] main: loading model
[2026-01-28T13:37:12.166654200Z] srv    load_model: loading model '<HOME>\.docker\models\bundles\sha256\cad0bdb32dd3c9d0f915949d3434912eba79d66662ca16

Bottom line: Connecting to the “host” localhost from WSL is actually quite easy and for GPU-backed inference, make sure that it actually works…²

One of the, if not the biggest benefit of being a Docker Captain is that you can reach out the team directly and very often get pretty quick reactions. ↩
On a side note, the responses from OpenCode are still very slow. But that is a different topic where you can follow the progress at https://github.com/docker/model-runner/issues/606 and I might update this blog post with a third lesson (if it turns out there is one here as well) ↩

Logging and service monitoring in Windows Containers and AKS

Thu, 01 Jan 2026 09:44:26 +0000

To continue on the topic of running Windows Server 2025 containers and doing so on the Azure Kubernetes Service (AKS), this blog post explains how you can use LogMonitor and ServiceMonitor to run and monitor your Windows applications safely in AKS.

The TL;DR

To just give it a try, clone https://github.com/tfenster/logged-iis, which has all the sources you need. Then do the following:

Create a cluster using CreateCluster.ps1
Deploy my demo IIS container with kubectl apply -f iis.yaml and get the external IP with kubectl get services
Open the IIS starting page on that IP with something like http://9.141.62.204 (your IP will of course be different)
Check the logs in Azure Monitor, which should show you something like this

This is now an IIS container deployed to AKS that monitors the IIS Windows Service (W3SVC) through ServiceMonitor and puts the relevant logs to STDOUT through LogMonitor, which can then be collected in Azure Monitor. Now let’s take a look at the details how we got there.

The details: The container image with ServiceMonitor, LogMonitor and LogMonitorConfig.json

To get this to work from the container perspective, I used the same approach as explained previously to get IIS running in a Nano Server. What is special for the LogMonitor and ServiceMonitor, is the installation in the Dockerfile, based on a blog post about LogMonitor.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
FROM mcr.microsoft.com/windows/servercore:ltsc2025 AS download
WORKDIR /download
RUN powershell -Command \
    Invoke-WebRequest -Uri "https://github.com/microsoft/IIS.ServiceMonitor/releases/download/v2.0.1.10/ServiceMonitor.exe" -OutFile ".\ServiceMonitor.exe"; \
    Invoke-WebRequest -Uri "https://github.com/microsoft/windows-container-tools/releases/download/v2.1.3/LogMonitor.exe" -OutFile ".\LogMonitor.exe"

FROM mcr.microsoft.com/windows/nanoserver:ltsc2025
WORKDIR /install
COPY install_iis.cmd ./
COPY --from=download /download/ ./
USER ContainerAdministrator
RUN install_iis.cmd
WORKDIR /LogMonitor
COPY LogMonitorConfig.json ./
ENTRYPOINT ["C:\\install\\LogMonitor.exe", "C:\\install\\ServiceMonitor.exe", "W3SVC"]

In the end, I want to run in a Nano Server, but that base image doesn’t have any capability to download a file¹, so I went multi-stage with a Server Core base for the downloads first as you can see in lines 1-5. The files are then moved into the final stage in line 10. As mentioned above, the installation of IIS is the same as in my previous blog post. You can also see how LogMonitor is used with a nested ServiceMonitor call to monitor the IIS service in line 15. This runs LogMonitor with a configuration explained below, but also ServiceMonitor, which exits when the service state changes from SERVICE_RUNNING to anything else.

Potentially also interesting is the configuration of the collected logs in LogMonitorConfig.json, based on a sample in the official docs.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
{
    "LogConfig": {
        "sources": [
            {
                "type": "EventLog",
                "startAtOldestRecord": true,
                "eventFormatMultiLine": false,
                "channels": [
                    {
                        "name": "application",
                        "level": "error"
                    },
                    {
                        "name": "system",
                        "level": "error"
                    }
                ]
            },
            {
                "type": "File",
                "directory": "c:\\inetpub\\logs",
                "filter": "*.log",
                "includeSubdirectories": true
            },
            {
                "type": "ETW",
                "eventFormatMultiLine": false,
                "providers": [
                    {
                        "providerName": "IIS: WWW Server",
                        "providerGuid": "3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83",
                        "level": "Information"
                    },
                    {
                        "providerName": "Microsoft-Windows-IIS-Logging",
                        "providerGuid": "7E8AD27F-B271-4EA2-A783-A47BDE29143B",
                        "level": "Information"
                    }
                ]
            }
        ]
    }
}

This collects information from the standard Windows event log (lines 4-18), from the IIS file-based logs (lines 19-24) and from the Event Tracing for Windows (ETW, lines 25-40). With that, we can see in STDOUT what goes on in the system generally and especially with IIS.

The details: AKS deployment

The AKS deployment in CreateCluster.ps1 is again very similar to what I shared before:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
az extension add --name aks-preview
az extension update --name aks-preview

az feature register --namespace "Microsoft.ContainerService" --name "AksWindows2025Preview"
az feature show --namespace Microsoft.ContainerService --name AksWindows2025Preview
az provider register --namespace Microsoft.ContainerService

$name = "akswin2025"
$region = "germanywestcentral"
$vmSize = "Standard_B4ls_v2"
az group create --name $name --location $region
az aks create -g $name -n $name --node-count 1 -s $vmSize --tier free --network-plugin azure --enable-app-routing --no-ssh-key --vm-set-type VirtualMachineScaleSets --network-plugin azure --enable-azure-monitor-metrics
az aks nodepool add --resource-group $name --cluster-name $name --os-type Windows --os-sku Windows2025 --name npwin --node-count 1 --ssh-access disabled --enable-fips-image
az aks enable-addons --addon monitoring --name $name --resource-group $name
az aks get-credentials --resource-group $name --name $name --overwrite-existing

Notable differences are:

The --enable-azure-monitor-metrics parameter in line 12 when the cluster is created. This enables monitoring generally for the AKS cluster via a Azure Monitor workspace. To learn more, check the official docs.
The monitoring addon, enabled via az aks enable-addons --addon monitoring... in line 14. This enables the collection of container logs. Again, to learn more, check the official docs

As explained above, LogMonitor with the right LogMonitorConfig.json makes sure that the right log entries end up in STDOUT and with the AKS setup explained here, that ends up in the workspace. With a KQL query like the following, also visible in the screenshot above, we can get e.g. the relevant parts from the IIS log files as they are also in STDOUT now:

1
2
3
4
5
6
7
8
9
ContainerLog
| union (ContainerLogV2
    | project-rename ContainerID = ContainerId
    | where ContainerName == "iis")
| extend d = parse_json(LogMessage. LogEntry)
| where LogMessage.Source == "File"
| extend Logline = d.Logline
| order by TimeGenerated desc
| project Logline

The deployment itself is trivial as you can see in iis.yaml. The only maybe relevant part is the usage of the tobiasfenster/logged-iis:nanoserver-ltsc2025 image, which is created using the Dockerfile above.

I hope this gives you an idea how to easily set up monitoring and logging for Windows containers in AKS, making them fit in the structure typically also used by Linux conatiners.

Of course, I could have used ADD in the Dockerfile, but that somehow isn’t intuitive for me, so I typically don’t. ↩

Running Windows Server 2025 workloads on Azure Kubernetes Service

Sun, 07 Dec 2025 11:56:43 +0000

A while ago, support for Windows Server 2025 in the Azure Kubernetes Service (AKS) was announced. Of course, I had to play around with it and in this blog post, I want to show you two scenarios: Running a Nano Server container enhanced by two FODs (see my recent blog post on the topic) and running a Microsoft Dynamics 365 Business Central container.

The TL;DR

To see it for yourself, you can do the following:

Clone my AKS Windows Server 2025 samples repo
Run CreateCluster.ps1 to create an AKS cluster with a Windows Server 2025 node pool
Run kubectl apply -f fod.yaml to deploy the nanoserver container with enabled IIS FOD
Run kubectl apply -f bc.yaml to deploy the Windows Server 2025 based BC container
Run kubectl get services to get the public IP addresses we need to use. This should give you something like

1
2
3
4
5
kubectl get services
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
bc           LoadBalancer   10.0.245.147   72.144.130.94   443:32055/TCP   15m
iis          LoadBalancer   10.0.36.200    9.141.62.204    80:30936/TCP    3h25m
kubernetes   ClusterIP      10.0.0.1       <none>          443/TCP         7d20h

Open http://<external IP of IIS>. In my example above, that would be http://9.141.62.204. This should give you the default IIS starting page

Open https://<external IP of BC>/BC?tenant=default. Again, in my example above, this would be https://72.144.130.94/BC?tenant=default. It uses a self-signed SSL certificate, so you will get a security warning. If you ignore that, you can log in with the user defined in the deployment, tfenster, and the defined password Super5ecret! to access the BC starting page

The details: Setting up the cluster

Let’s take a look at what CreateCluster.ps1 does:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
az extension add --name aks-preview
az extension update --name aks-preview

az feature register --namespace "Microsoft.ContainerService" --name "AksWindows2025Preview"
az feature show --namespace Microsoft.ContainerService --name AksWindows2025Preview
az provider register --namespace Microsoft.ContainerService

$name = "akswin2025"
$region = "germanywestcentral"
$vmSize = "Standard_B4ls_v2"
az group create --name $name --location $region
az aks create -g $name -n $name --node-count 1 -s $vmSize --tier free --network-plugin azure --enable-app-routing --no-ssh-key --vm-set-type VirtualMachineScaleSets --network-plugin azure
az aks nodepool add --resource-group $name --cluster-name $name --os-type Windows --os-sku Windows2025 --name npwin --node-count 1 --ssh-access disabled --enable-fips-image
az aks get-credentials --resource-group $name --name $name --overwrite-existing

First, since the feature we want is in preview, we add and potentially update the aks-preview extension to the Azure CLI (lines 1 and 2). Next, we register and show the AksWindows2025Preview feature and register the AKS provider (lines 4-6). Next, we set up the name, region and VM size for the cluster (lines 8-10). After that, we create the resource group and AKS cluster (lines 11 and 12), and then we add the Windows Server 2025 node pool (line 13). Finally, we get the credentials to interact with our cluster via kubectl (line 14). The entire script should produce an output similar to this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
PWSH C:\Users\tobia> az group create --name $name --location $region
{
  "id": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourceGroups/akswin2025",
  "location": "germanywestcentral",
  "managedBy": null,
  "name": "akswin2025",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}
PWSH C:\Users\tobia>
PWSH C:\Users\tobia> az aks create -g $name -n $name --node-count 1 -s $vmSize --tier free --network-plugin azure --enable-app-routing --no-ssh-key --vm-set-type VirtualMachineScaleSets --network-plugin azure
Default SSH key behavior will change. When no SSH key parameters are provided, the command will behave as if '--no-ssh-key' was passed instead of failing in next breaking change release(2.80.0) scheduled for Nov 2025.
Argument '--enable-app-routing' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
The behavior of this command has been altered by the following extension: aks-preview
The new node pool will enable SSH access, recommended to use '--ssh-access disabled' option to disable SSH access for the node pool to make it more secure.
{
  "aadProfile": null,
  "addonProfiles": null,
  "agentPoolProfiles": [
    {
      "artifactStreamingProfile": null,
      "availabilityZones": null,
      "capacityReservationGroupId": null,
      "count": 1,
      "creationData": null,
      "currentOrchestratorVersion": "1.32.9",
      "eTag": "401ba2c0-78b0-4a5e-9679-3579eb7519f3",
      "enableAutoScaling": false,
      "enableEncryptionAtHost": false,
      "enableFips": false,
      "enableNodePublicIp": false,
      "enableUltraSsd": false,
      "gatewayProfile": null,
      "gpuInstanceProfile": null,
      "gpuProfile": null,
      "hostGroupId": null,
      "kubeletConfig": null,
      "kubeletDiskType": "OS",
      "linuxOsConfig": null,
      "localDnsProfile": null,
      "maxCount": null,
      "maxPods": 30,
      "messageOfTheDay": null,
      "minCount": null,
      "mode": "System",
      "name": "nodepool1",
      "networkProfile": {
        "allowedHostPorts": null,
        "applicationSecurityGroups": null,
        "nodePublicIpTags": null
      },
      "nodeCustomizationProfile": null,
      "nodeImageVersion": "AKSUbuntu-2204gen2containerd-202511.07.0",
      "nodeInitializationTaints": null,
      "nodeLabels": null,
      "nodePublicIpPrefixId": null,
      "nodeTaints": null,
      "orchestratorVersion": "1.32",
      "osDiskSizeGb": 128,
      "osDiskType": "Managed",
      "osSku": "Ubuntu",
      "osType": "Linux",
      "podIpAllocationMode": null,
      "podSubnetId": null,
      "powerState": {
        "code": "Running"
      },
      "provisioningState": "Succeeded",
      "proximityPlacementGroupId": null,
      "scaleDownMode": "Delete",
      "scaleSetEvictionPolicy": null,
      "scaleSetPriority": null,
      "securityProfile": {
        "enableSecureBoot": false,
        "enableVtpm": false,
        "sshAccess": "LocalUser"
      },
      "spotMaxPrice": null,
      "status": null,
      "tags": null,
      "type": "VirtualMachineScaleSets",
      "upgradeSettings": {
        "drainTimeoutInMinutes": null,
        "maxBlockedNodes": null,
        "maxSurge": "10%",
        "maxUnavailable": "0",
        "minSurge": null,
        "nodeSoakDurationInMinutes": null,
        "undrainableNodeBehavior": null
      },
      "upgradeSettingsBlueGreen": {
        "batchSoakDurationInMinutes": null,
        "drainBatchSize": null,
        "drainTimeoutInMinutes": null,
        "finalSoakDurationInMinutes": null
      },
      "upgradeStrategy": "Rolling",
      "virtualMachineNodesStatus": null,
      "virtualMachinesProfile": null,
      "vmSize": "Standard_B4ls_v2",
      "vnetSubnetId": null,
      "windowsProfile": null,
      "workloadRuntime": "OCIContainer"
    }
  ],
  "aiToolchainOperatorProfile": null,
  "apiServerAccessProfile": null,
  "autoScalerProfile": null,
  "autoUpgradeProfile": {
    "nodeOsUpgradeChannel": "NodeImage",
    "upgradeChannel": null
  },
  "azureMonitorProfile": null,
  "azurePortalFqdn": "akswin2025-akswin2025-94670b-vqa7xrf8.portal.hcp.germanywestcentral.azmk8s.io",
  "bootstrapProfile": {
    "artifactSource": "Direct",
    "containerRegistryId": null
  },
  "creationData": null,
  "currentKubernetesVersion": "1.32.9",
  "disableLocalAccounts": false,
  "diskEncryptionSetId": null,
  "dnsPrefix": "akswin2025-akswin2025-94670b",
  "eTag": "ced84e53-96a5-4e6c-b33c-d1b732d81f34",
  "enableNamespaceResources": null,
  "enableRbac": true,
  "extendedLocation": null,
  "fqdn": "akswin2025-akswin2025-94670b-vqa7xrf8.hcp.germanywestcentral.azmk8s.io",
  "fqdnSubdomain": null,
  "hostedSystemProfile": {
    "enabled": false
  },
  "httpProxyConfig": null,
  "id": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourcegroups/akswin2025/providers/Microsoft.ContainerService/managedClusters/akswin2025",
  "identity": {
    "delegatedResources": null,
    "principalId": "4532f452-5dba-4965-9b9f-20d7d15ce9c5",
    "tenantId": "539f23a3-6819-457e-bd87-7835f4122217",
    "type": "SystemAssigned",
    "userAssignedIdentities": null
  },
  "identityProfile": {
    "kubeletidentity": {
      "clientId": "b37ac7a2-8cf1-4144-af8e-83d73649cb3f",
      "objectId": "44393190-32fe-406a-b7d9-801657bafc14",
      "resourceId": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourcegroups/MC_akswin2025_akswin2025_germanywestcentral/providers/Microsoft.ManagedIdentity/userAssignedIdentities/akswin2025-agentpool"
    }
  },
  "ingressProfile": {
    "gatewayApi": null,
    "webAppRouting": {
      "defaultDomain": {
        "enabled": false
      },
      "dnsZoneResourceIds": null,
      "enabled": true,
      "identity": {
        "clientId": "633a3b19-828a-4281-8cd5-c4a29eb143e8",
        "objectId": "a31f7c1d-538c-46ff-a578-75c372f4c433",
        "resourceId": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourcegroups/MC_akswin2025_akswin2025_germanywestcentral/providers/Microsoft.ManagedIdentity/userAssignedIdentities/webapprouting-akswin2025"
      },
      "nginx": {
        "defaultIngressControllerType": "AnnotationControlled"
      }
    }
  },
  "kind": "Base",
  "kubernetesVersion": "1.32",
  "linuxProfile": null,
  "location": "germanywestcentral",
  "maxAgentPools": 100,
  "metricsProfile": {
    "costAnalysis": {
      "enabled": false
    }
  },
  "name": "akswin2025",
  "networkProfile": {
    "advancedNetworking": null,
    "dnsServiceIp": "10.0.0.10",
    "ipFamilies": [
      "IPv4"
    ],
    "kubeProxyConfig": null,
    "loadBalancerProfile": {
      "allocatedOutboundPorts": null,
      "backendPoolType": "nodeIPConfiguration",
      "clusterServiceLoadBalancerHealthProbeMode": null,
      "effectiveOutboundIPs": [
        {
          "id": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourceGroups/MC_akswin2025_akswin2025_germanywestcentral/providers/Microsoft.Network/publicIPAddresses/9d9a1620-981c-4cb0-aaef-4edcb9ad03ee",
          "resourceGroup": "MC_akswin2025_akswin2025_germanywestcentral"
        }
      ],
      "enableMultipleStandardLoadBalancers": null,
      "idleTimeoutInMinutes": null,
      "managedOutboundIPs": {
        "count": 1,
        "countIpv6": null
      },
      "outboundIPs": null,
      "outboundIpPrefixes": null
    },
    "loadBalancerSku": "standard",
    "natGatewayProfile": null,
    "networkDataplane": "azure",
    "networkMode": null,
    "networkPlugin": "azure",
    "networkPluginMode": null,
    "networkPolicy": "none",
    "outboundType": "loadBalancer",
    "podCidr": null,
    "podCidrs": null,
    "podLinkLocalAccess": "IMDS",
    "serviceCidr": "10.0.0.0/16",
    "serviceCidrs": [
      "10.0.0.0/16"
    ],
    "staticEgressGatewayProfile": null
  },
  "nodeProvisioningProfile": {
    "defaultNodePools": "Auto",
    "mode": "Manual"
  },
  "nodeResourceGroup": "MC_akswin2025_akswin2025_germanywestcentral",
  "nodeResourceGroupProfile": null,
  "oidcIssuerProfile": {
    "enabled": false,
    "issuerUrl": null
  },
  "podIdentityProfile": null,
  "powerState": {
    "code": "Running"
  },
  "privateFqdn": null,
  "privateLinkResources": null,
  "provisioningState": "Succeeded",
  "publicNetworkAccess": null,
  "resourceGroup": "akswin2025",
  "resourceUid": "692b12472e7971000183169c",
  "schedulerProfile": null,
  "securityProfile": {
    "azureKeyVaultKms": null,
    "customCaTrustCertificates": null,
    "defender": null,
    "imageCleaner": null,
    "imageIntegrity": null,
    "kubernetesResourceObjectEncryptionProfile": null,
    "nodeRestriction": null,
    "workloadIdentity": null
  },
  "serviceMeshProfile": null,
  "servicePrincipalProfile": {
    "clientId": "msi",
    "secret": null
  },
  "sku": {
    "name": "Base",
    "tier": "Free"
  },
  "status": null,
  "storageProfile": {
    "blobCsiDriver": null,
    "diskCsiDriver": {
      "enabled": true,
      "version": "v1"
    },
    "fileCsiDriver": {
      "enabled": true
    },
    "snapshotController": {
      "enabled": true
    }
  },
  "supportPlan": "KubernetesOfficial",
  "systemData": null,
  "tags": null,
  "type": "Microsoft.ContainerService/ManagedClusters",
  "upgradeSettings": null,
  "windowsProfile": {
    "adminPassword": null,
    "adminUsername": "azureuser",
    "enableCsiProxy": true,
    "gmsaProfile": null,
    "licenseType": null
  },
  "workloadAutoScalerProfile": {
    "keda": null,
    "verticalPodAutoscaler": null
  }
}
PWSH C:\Users\tobia> az aks nodepool add --resource-group $name --cluster-name $name --os-type Windows --os-sku Windows2025 --name npwin --node-count 1 --ssh-access disabled --enable-fips-image
Argument '--ssh-access' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
The behavior of this command has been altered by the following extension: aks-preview
{
  "artifactStreamingProfile": null,
  "availabilityZones": null,
  "capacityReservationGroupId": null,
  "count": 1,
  "creationData": null,
  "currentOrchestratorVersion": "1.32.9",
  "eTag": "745d5d2e-c47c-479d-8fdc-98962788f5ca",
  "enableAutoScaling": false,
  "enableEncryptionAtHost": false,
  "enableFips": true,
  "enableNodePublicIp": false,
  "enableUltraSsd": false,
  "gatewayProfile": null,
  "gpuInstanceProfile": null,
  "gpuProfile": null,
  "hostGroupId": null,
  "id": "/subscriptions/94670b10-08d0-4d17-bcfe-e01f701be9ff/resourcegroups/akswin2025/providers/Microsoft.ContainerService/managedClusters/akswin2025/agentPools/npwin",
  "kubeletConfig": null,
  "kubeletDiskType": "OS",
  "linuxOsConfig": null,
  "localDnsProfile": null,
  "maxCount": null,
  "maxPods": 30,
  "messageOfTheDay": null,
  "minCount": null,
  "mode": "User",
  "name": "npwin",
  "networkProfile": {
    "allowedHostPorts": null,
    "applicationSecurityGroups": null,
    "nodePublicIpTags": null
  },
  "nodeCustomizationProfile": null,
  "nodeImageVersion": "AKSWindows-2025-gen2-26100.6905.251027",
  "nodeInitializationTaints": null,
  "nodeLabels": null,
  "nodePublicIpPrefixId": null,
  "nodeTaints": null,
  "orchestratorVersion": "1.32",
  "osDiskSizeGb": 300,
  "osDiskType": "Ephemeral",
  "osSku": "Windows2025",
  "osType": "Windows",
  "podIpAllocationMode": null,
  "podSubnetId": null,
  "powerState": {
    "code": "Running"
  },
  "provisioningState": "Succeeded",
  "proximityPlacementGroupId": null,
  "resourceGroup": "akswin2025",
  "scaleDownMode": "Delete",
  "scaleSetEvictionPolicy": null,
  "scaleSetPriority": null,
  "securityProfile": {
    "enableSecureBoot": false,
    "enableVtpm": false,
    "sshAccess": "Disabled"
  },
  "spotMaxPrice": null,
  "status": null,
  "tags": null,
  "type": "Microsoft.ContainerService/managedClusters/agentPools",
  "typePropertiesType": "VirtualMachineScaleSets",
  "upgradeSettings": {
    "drainTimeoutInMinutes": null,
    "maxBlockedNodes": null,
    "maxSurge": "10%",
    "maxUnavailable": "0",
    "minSurge": null,
    "nodeSoakDurationInMinutes": null,
    "undrainableNodeBehavior": null
  },
  "upgradeSettingsBlueGreen": {
    "batchSoakDurationInMinutes": null,
    "drainBatchSize": null,
    "drainTimeoutInMinutes": null,
    "finalSoakDurationInMinutes": null
  },
  "upgradeStrategy": "Rolling",
  "virtualMachineNodesStatus": null,
  "virtualMachinesProfile": null,
  "vmSize": "Standard_D8d_v5",
  "vnetSubnetId": null,
  "windowsProfile": {
    "disableOutboundNat": null
  },
  "workloadRuntime": "OCIContainer"
}
PWSH C:\Users\tobia> az aks get-credentials --resource-group $name --name $name --overwrite-existing
The behavior of this command has been altered by the following extension: aks-preview
Merged "akswin2025" as current context in C:\Users\tobia\.kube\config

If you then use a tool like AKS Desktop (highly recommended), you should see your cluster including the Windows Server 2025 node:

The details: Creating and deploying the IIS (and SSH client) container image

Creating the container image works very much along the lines of what I showed in my first blog post about FODs: We use a Dockerfile that calls a script to install the FOD. The difference this time is that I also wanted to demonstrate installing a second FOD: the OpenSSH client. The installation process is very similar; basically only the name in line 1 is different, as seen in install_ssh_client.cmd:

1
2
3
4
5
6
DISM /Online /Add-Capability /CapabilityName:Microsoft.NanoServer.OpenSSH.Client /NoRestart
if errorlevel 3010 (
    echo The specified optional feature requested a reboot which was suppressed.
    exit /b 0
)
@echo off

The Dockerfile consequently also needs a reference to that script, as you can see in line 6

1
2
3
4
5
6
7
8
FROM mcr.microsoft.com/windows/nanoserver:ltsc2025
WORKDIR /install
COPY install_*.cmd ./
USER ContainerAdministrator
RUN install_iis.cmd
RUN install_ssh_client.cmd
USER ContainerUser
CMD ["ping", "-t", "localhost"]

A simple docker build -t tobiasfenster/fod:v0.0.6 . followed by a docker push tobiasfenster/fod:v0.0.6 creates and pushes that image. Now, let’s run this in AKS! Before we can do that, however, we need to consider how we want to use the SSH client. In my case, I need a private key to connect. First, I need to make the key available in the AKS cluster using this command:

1
kubectl create secret generic ssh-key-secret --from-file=id_rsa=c:/users/tobia/.ssh/id_azure

Of course, your SSH key most likely won’t be in c:\users\tobia\.ssh\id_azure, so you’ll need to adjust that. With that in place, we can kubectl apply -f .\fod.yaml with the fod.yaml looking like this

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
apiVersion: apps/v1
kind: Deployment
metadata:
  name: iis
  labels:
    app: iis
spec:
  replicas: 1
  template:
    metadata:
      name: iis
      labels:
        app: iis
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
      - name: iis
        image: tobiasfenster/fod:v0.0.6
        resources:
          limits:
            cpu: 1
            memory: 800M
        ports:
          - containerPort: 80
        volumeMounts:
        - name: ssh-key-volume
          mountPath: c:/ssh-key
          readOnly: true
      volumes:
      - name: ssh-key-volume
        secret:
          secretName: ssh-key-secret
  selector:
    matchLabels:
      app: iis
---
apiVersion: v1
kind: Service
metadata:
  name: iis
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
    name: http
  selector:
    app: iis

The first part (lines 1-36) is the deployment which containes the container. The most interesting lines are 18 and 19, which define the container; 15 and 16 which make sure that it ends up on a Windows node; and 26-30 which mount the SSH key into the container. Due to lines 38-49, the container id available via the external IP as explained in the TL;DR. Therefore, this is all that is needed for the IIS part.

Now what if we want to make an outgoing SSH connection? We have the SSH client installed through the FOD, and the private key is available through the secret and volume. However, we must properly define the permissions, otherwise SSH will decline to use the key, displaying an error message such as this:

1
2
3
4
5
6
7
Bad permissions. Try removing permissions for user: NT AUTHORITY\\Authenticated Users (S-1-5-11) on file c:/ssh-key/id_rsa.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'c:\\ssh-key\\id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

To fix that, you can run something like

1
2
3
4
5
6
copy c:\ssh-key\id_rsa .

icacls "c:\install\id_rsa" /inheritance:r
icacls "c:\install\id_rsa" /remove "NT AUTHORITY\Authenticated Users"
icacls "c:\install\id_rsa" /remove "BUILTIN\Users"
icacls "c:\install\id_rsa" /grant:r "%USERNAME%:R"

This copies the key to a new folder and fixes the permissions by breaking the inheritance and removing everyone before adding the current user. After that, you should be able to use the key to SSH into a remote machine.

You have now seen how to create and use a Windows Server 2025 Nano Server image to run a container in AKS that serves a webpage through IIS and establishes SSH connections. You might now be wondering which other FODs are available. It’s surprisingly difficult to find out, but you can run a Windows Server 2025 container and query for it like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
docker run --user ContainerAdministrator -ti mcr.microsoft.com/windows/nanoserver:ltsc2025
Microsoft Windows [Version 10.0.26100.7171]
(c) Microsoft Corporation. All rights reserved.

C:\>DISM /Online /Get-Capabilities /Format:Table

Deployment Image Servicing and Management tool
Version: 10.0.26100.5074

Image Version: 10.0.26100.7171

Capability listing:


---------------------------------------------------- | -----------
Capability Identity                                  | State
---------------------------------------------------- | -----------
Microsoft.NanoServer.ADSI~~~~                        | Not Present
Microsoft.NanoServer.BITS.Admin~~~~                  | Not Present
Microsoft.NanoServer.CommandLine.Utilities~~~~       | Not Present
Microsoft.NanoServer.Datacenter.WOWSupport~~~~       | Not Present
Microsoft.NanoServer.Globalization~~~~               | Not Present
Microsoft.NanoServer.IIS~~~~                         | Not Present
Microsoft.NanoServer.OpenSSH.Client~~~~              | Not Present
Microsoft.NanoServer.OpenSSH.Server~~~~              | Not Present
Microsoft.NanoServer.Performance.Monitoring~~~~      | Not Present
Microsoft.NanoServer.PowerShell.Cmdlets~~~~          | Not Present
Microsoft.NanoServer.RemoteFS.Client~~~~             | Not Present
Microsoft.NanoServer.StateRepository~~~~             | Not Present
Microsoft.NanoServer.WinMgmt.RuntimeDependencies~~~~ | Not Present
Microsoft.NanoServer.WinMgmt~~~~                     | Not Present

The operation completed successfully.

I wouldn’t be able to tell you exactly what those FODs do.

The details: Creating and deploying the BC container image

The second scenario is a Business Central container based on a Windows Server 2025 base image. Since these images are not readily available, you first need the bccontainerhelper PowerShell module. Then, you can run something like this to create the image:

1
New-BcImage -artifactUrl (Get-BCArtifactUrl -type sandbox -country w1 -accept_insiderEula -select NextMajor) -imageName tobiasfenster/mybc -baseImage "mcr.microsoft.com/businesscentral:ltsc2025"

In my case, this gave me the image tobiasfenster/mybc:sandbox-28.0.43121.0-w1-mt. Because of that, we can run a simple deployment to AKS like you see in bc.yaml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bc
  labels:
    app: bc
spec:
  replicas: 1
  template:
    metadata:
      name: bc
      labels:
        app: bc
    spec:
      nodeSelector:
        "kubernetes.io/os": windows
      containers:
      - name: bc
        image: tobiasfenster/mybc:sandbox-28.0.43121.0-w1-mt
        ports:
        - containerPort: 443
        env:
        - name: username
          value: tfenster
        - name: password
          value: Super5ecret!
        - name: auth
          value: NavUserPassword
        - name: accept_eula
          value: "y"
        - name: accept_outdated
          value: "y"
  selector:
    matchLabels:
      app: bc
---
apiVersion: v1
kind: Service
metadata:
  name: bc
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 443
    name: https
  selector:
    app: bc

As in the previous example, the container is shown in lines 18 and 19, the Windows node selection is shown in lines 15 and 16, and the service that enables incoming traffic is shown in lines 37–48. The BC container has a special username and password setup (lines 23–28) and requires acceptance of the EULA and outdated image (lines 29–32) to run.

Of course, for real dev/test scenarios, you would need much more, but this gives you the basics to see that BC on Windows Server 2025 runs in AKS.

Tech blog by Tobias Fenster

Docker sandbox via SSH in VS Code for BC development

The TL;DR

The details

Docker Sandbox, AL MCP Server and AI Runway improvements; and MVP renewal

The TL;DR

The Details: Docker Sandboxes

The Details: Authentication with the AL MCP Server

The Details: KAITO recognized by AI Runway

The Details: I am still an MVP

Docker sandbox credential injection for Business Central

The TL;DR

The details: Injecting the credentials on the Sandbox side

The details: The problem with basic auth / UserPassword

The details: The problem with Windows auth

Using Docker Sandbox Kits

The TL;DR

The details: Why more secure - networking

The details: Why more secure - credentials

The details: Another aspect of Sandbox Kits - installs

The details: Claws…

Easier network access for AI Runway

The TL;DR

The details: Istio and body-based router

Deploy LLMs on Azure Kubernetes Service with AI Runway

The TL;DR

The details: Create the AKS cluster and install KAITO

The details: Add AI Runway and expose the dashboard through Traefik

The details: Deploy your first model, expose it, and test over HTTP

The details: Using it with Business Central

Using MCPs with GitHub Copilot without installing anything locally

The TL;DR

Summary: Work Item 33 Analysis

Recommended Implementation Approach:

The details: Other interactions you might like

Best fit — Dimensions

Good fit — Customer Price Group (field 23, Customer Price Group table)

Reasonable fit — Territory Code (field 15, Territory table)

Possible fit — Customer Disc. Group (field 34, Customer Discount Group table)

Limited fit — Statistics Group (field 26, Integer)

Summary recommendation

The details: Setup and configuration

Lessons learned for AI assistant usage with Docker Model Runner on ARM Windows

Lesson 1: If you can’t connect, there might be an easy fix

Lesson 2: Don’t just assume it works, but check

Logging and service monitoring in Windows Containers and AKS

The TL;DR

The details: The container image with ServiceMonitor, LogMonitor and LogMonitorConfig.json

The details: AKS deployment

Running Windows Server 2025 workloads on Azure Kubernetes Service

The TL;DR

The details: Setting up the cluster

The details: Creating and deploying the IIS (and SSH client) container image

The details: Creating and deploying the BC container image

Good fit — Customer Price Group (field 23, `Customer Price Group` table)

Reasonable fit — Territory Code (field 15, `Territory` table)

Possible fit — Customer Disc. Group (field 34, `Customer Discount Group` table)