Brandon Richards reports: California resident Sean Mortazi filed a class action lawsuit against TikTok Inc. on June 11, 2026, alleging a data breach exposed the personal data of more than 2.4 billion users worldwide. The complaint, filed in the U.S. District Court for the Central District of California, claims TikTok stored unencrypted data and skipped basic...

Source

Introduction and motivation

Some of the projects I work on – notably V-Drum Explorer and At Your Service – use MIDI to interact with hardware devices.

I use a couple of packages for this depending on the nature of the interaction, but the one I use most often is managed-midi, which currently has its “source of truth” at https://github.com/atsushieno/managed-midi. This is a cross-platform library using the NuGet “bait-and-switch” approach to allow a single package with multiple implementations within it. Note that unlike the use of the term in commerce etc, “bait-and-switch” is not a derogatory term when it comes to NuGet packages. There’s no deception involved. (Do let me know if you have a more recent source of documentation for bait-and-switch; the current link is from 2014, back in the dark days of PCL.)

A few months ago, managed-midi stopped working properly on Windows 11 installations that were fully updated, due to aspects of Windows MIDI Services either changing or being introduced for the first time. (I haven’t dived into exactly what the change involved.) This
has broken other apps as well as the managed-midi library.

The author of managed-midi, Atsushi Eno, has accepted patches which I believe will fix the issue – but he doesn’t have any plans to work on the .NET stack any more, so it’s unlikely that there’ll be a new release of managed-midi without someone else getting involved. (Note: I’ve assumed he/him pronouns for Atsushi, but I’m happy to edit this blog post if that turns out to be wrong.)

And that’s where I’m possibly going to come in. This blog post is going to lay out my current plans and outline a few alternatives. This helps me just in terms of making my thoughts concrete, as well as providing an opportunity for feedback. (There’s no great way of getting feedback from all existing managed-midi users, but I’m hoping my readership can provide useful thoughts without necessarily having used the package directly.)

Possible forking and next steps

I’ve already created a fork of the repo, but just forking the repo itself doesn’t signify much. The big questions are whether I’m going to publish a fork of the code to NuGet, and what happens after that.

I should state up-front that I’ve been in touch with Atsushi on BlueSky, and he’s been very open and constructive. He’s happy for a wholesale fork to happen, and he’d then expect to effectively redirect traffic to the fork. This is in no way one of those community bust-ups we sometimes read about.

Now, I’m not going to claim I have huge amounts of time to take on another open source project. Right now, while I’m between jobs, I have more time than normal, but I’m hoping and expecting to be employed again soonish, at which point I naturally expect the new job to take most of my focus. I’d like to get the project into a state where it’s easy enough to update dependencies, publish new versions etc – but without spending a lot of time on new features etc.

Things get slightly difficult due to the current state of the project. It hasn’t been worked on very significantly for quite a while (just the first page of the commit history goes back to October 2019). To be really clear, I’m not in any way attacking Atsushi for this. I’ve got plenty of open source projects I haven’t updated for ages – I’m sure many of us have. I’m incredibly grateful to Atsushi for the updates that managed-midi has received over the years; it’s been a very valuable library to me. However, it does mean that the solution doesn’t even build for me after a simple clone.

Fork location

For most public projects, I like having a “core” repo and then my own personal fork. For example, Noda Time has https://github.com/nodatime/nodatime, and I create branches within https://github.com/jskeet/nodatime for PRs. Given that there isn’t already a suitable GitHub organization, I plan to stick with just my fork in https://github.com/jskeet/managed-midi.

Dropping some platforms

Several of the platforms being targeted are either out of date or at least being deprecated. I don’t like the idea of trying to maintain code that I can’t test, or which targets platforms or toolchains which are no longer supported. It’s really easy to get into that situation, trying to avoid breaking existing users.

But if I’m creating a new NuGet package anyway, I don’t have any existing users – even if the codebase itself is forked. Where there are platforms which are out of date, I’ll bump them to more recent versions. Where there are platforms which are no longer supported at all (or are already deprecated) I’ll drop them entirely – at least to start with.

At first glance, I think this means the following changes from the current targets:

• netstandard2.0: keep; this is the “bait” target
• net45: update to net48; used as the implementation for .NET Framework
• netcoreapp2.1: update to net10; used as the implementation for .NET
• net6.0-ios: drop for now
• MonoAndroid: drop for now
• XamariniOS: drop for now
• XamarinMac: drop for now
• uap10.0: drop for now

Yes, this means dropping all mobile targets for now, as well as UWP/UAP. I may be able to provide mobile targets via MAUI in the future, but I need to investigate that further. I don’t know much about the UWP/UAP world, or the Windows App SDK and WinUI. Again, I may be able to support WinUI in the future; it depends on time more than anything else.

In terms of the implementations of IMidiAccess available, I’m expecting to keep ALSA, WinMM and CoreMidiApi (dropping the latter if I can’t easily test it on my Mac Mini) and drop UWP, RtMidiSharp and PortMidiSharp. The implementations I’m dropping all come with significant caveats about the level of testing etc. I can add them back in later on if there’s demand, along with a good way of testing them. (I’m okay with running manual tests, even limited ones that just run against my drum kit, but I don’t want to ship anything that I’ve never run at all.)

Modernizing the build

The current repository uses:

• Shared project files (and projitems files) which I believe are still supported, but which I don’t have much experience of. It’s possible that I can use normal csproj files instead, but this will need further investigation. (If there’s good support for shared project files now, that might still be the best approach.)
• Old-style csproj files which I’ll definitely want to modernize to SDK-style.
• An old-style sln file, which I’ll definitely want to modernize to slnx.
• A nuspec file while I suspect may still be required; unclear as yet.
• Some slnf files which I’d never even seen before. I’m hoping to be able to delete these for now, as I think they’re more for developer convenience than anything else.

This will be a voyage of discovery of techniques I’ve never used, first understanding them at least as far as I need to, then modernizing where possible.

Naming

Currently the package is called managed-midi, but all the code is in namespaces rooted in Commons.Music.Midi. Some of the directory names don’t match namespaces (e.g. code for Commons.Music.Midi.Alsa is in a subdirectory called alsaseq).

Using shared projects quite possibly makes it hard/infeasible to make namespaces entirely match folder structure, but I’d like to do what I can here.

My current plan is to use the named ManagedMidi as both the namespace root and the NuGet package name.

Benefits:

• It’s a more conventional .NET name (for both a package and a namespace)
• It doesn’t imply any relation to Apache Commons or any other “commons” library
• It’s not used by anything else at the moment, as far as I can tell
• Making the NuGet package name match the namespace makes it easier to determine dependencies at a glance
• It makes it clear to all consumers that this is a new package; forcing work on users is a good way to get them to read documentation around migration (which I will obviously need to provide).

Downsides:

• Changing the package name (as opposed to asking Atsushi to let me publish new code to the existing package) means users will need to become aware of the new package in some out-of-band way; they won’t get prompted by Visual Studio, Renovate etc.
• Changing the namespace means users are likely to need to change multiple source files. If I just changed the package name, keeping the namespace of Commons.Music.Midi, then migrating would probably be simpler.

API deprecations

There are various obsolete parts of the public API, most notably IMidiAccess which is being replaced by IMidiAccess2, with (I believe) a plan to then effectively rename IMidiAccess2 to IMidiAccess. (IMidiAccess2 is just IMidiAccess with one extra member.)

My plan is to initially get everything working without changing code other than in terms of the namespace… but then I think it makes sense to remove all the obsolete members. At the moment we’re in a bit of an in-between state in terms of the public API, and I’d rather not do a full GA release in that state.

Which brings me on to…

Versioning

The current latest version of managed-midi is 1.10.1. My plan is to effectively ignore the current versioning, given that it’s for a different package than the one I intend to release. While I could start my versioning at 1.11.0 or 2.0.0 (modulo prerelease signifiers) I think it’ll be less confusing to just treat it as a brand new package. I’m therefore intending to create releases of:

• 1.0.0-alpha.1 (etc): initial hardly-change-any-code (but do drop platforms) releases
• 1.0.0-beta.1 (etc): breaking change to fix the stable API (so there’ll just be a non-obsolete IMidiAccess which has the extra member currently in IMidiAccess2, and all the obsolete members will be removed)
• 1.0.0: GA release once the betas look successful without reported issues

I’ll probably leave things in 1.0.0-beta.x for a while, as I expect it to take some time for current managed-midi users to migrate, and they’re bound to find issues that I haven’t found with my limited usage.

Non-goals

I’m not intending to revisit the whole public API or overall design as part of this process. If I find myself itching to do so, I’ll consider that for a v2.0 release, but I doubt that I’ll have enough time really. This is a perfectly good package which already works, so I’m trying to keep the changes to a minimum while taking the opportunity to create a v1.0 without obsolete members.

Alternatives

All of the above plans have alternatives, mostly fairly obvious ones. I could attempt to support the current set of target frameworks. I could avoid changing the namespace and/or package name. I could keep the obsolete members. I could continue the versioning scheme from where it was.

Most of these either create more work before I can first get to a release, or more technical debt (in the form of supporting deprecated platforms etc, or continuing with the obsolete members).

That said, there are arguments that could be made in favour of those alternatives, and I’d rather hear them now than after I’ve made an unfortunate choice.

Conclusion

I don’t know how typical this is of an open source fork event. I hope I’m doing the right thing by both Atsushi and the current users. Whether it’ll go smoothly or not is hard to tell ahead of time – there’s a lot about this (including MIDI itself) that I only have minimal experience of.

Please leave comments with any thoughts, particularly if you’re already a user of managed-midi.

AZURE ARCHITECTURE BLOG · 8 MIN READ

Author: Arturo Quiroga, Senior Partner Solutions Architect — Microsoft

---

Two months ago I published From Prompt to Production: Building Azure Architecture Diagrams with AI, introducing the open-source Azure Architecture Diagram Builder. The response was humbling — thousands of you read it, tried the tool, and filed issues and feature requests. A follow-up on how the Well-Architected Framework scoring works went deep on validation.

You asked, and the tool grew. This post is about what’s new since May — and one change big enough to reframe the whole project: the Azure Architecture Diagram Builder is no longer just an app you click. It’s a partner you chat with, and a tool other agents can call.

TL;DR. Three arcs of new capability: (1) Architecture Chat turns diagram design into a multi-turn conversation over the live canvas; (2) Blueprint Diagrams produce hand-drawn, whiteboard-style deliverables alongside the formal topology; and (3) the app now exposes its capabilities as a Model Context Protocol (MCP) server, so AI agents can generate, validate, cost, and render Azure architectures programmatically. Plus a 13-model fleet, deployment guides grounded in Microsoft Learn, and July output enhancements.

---

What’s new at a glance

---

From clicking to conversing: Architecture Chat

The single most common request after the launch post was some version of “I love the first diagram, but I want to iterate without re-writing the whole prompt.” Regenerating from scratch every time you tweak a requirement is slow and loses context.

Architecture Chat solves this. It’s a conversational panel that sits alongside the canvas and treats your diagram as a living document. Each message is a turn in an ongoing design session:

• “Add an Azure Front Door with WAF in front of the app tier.”
• “Now make the data layer zone-redundant.”
• “Swap the SQL Database for Cosmos DB and update the connections.”

Every turn reads the current state of the canvas — not the original prompt — so refinements compound naturally the way they would with a human architect at a whiteboard. The conversation auto-saves to history, so you can step back through the evolution of a design or branch from an earlier point.

Figure 1. Architecture Chat treats the diagram as a living document. Each message refines the current canvas — adding services, changing SKUs, or reorganizing groups — and the full exchange is saved to history.

The shift is subtle but important: architecture design stops being a one-shot prompt and becomes an iterative dialogue.

---

The whiteboard deliverable: Blueprint Diagrams (BETA)

Formal topology diagrams with official Azure icons are perfect for documentation and stakeholder decks. But early-stage design conversations often want something looser — the hand-drawn feel of a whiteboard sketch that communicates intent without implying finality.

Blueprint Diagrams generate exactly that: a whiteboard-style render with nested zones (subscription → VNet → subnet), numbered flow arrows, and a deliberately sketchy aesthetic. You choose the output mode:

• Topology — the formal, icon-based diagram from the launch post
• Blueprint — the hand-drawn whiteboard style
• Both — generate the two side by side

Figure 2. The same architecture in two visual languages. Left: the formal, icon-based topology. Right: Blueprint mode — a whiteboard-style render with nested zones and numbered flow steps, plus a numbered legend explaining each hop. Use Blueprint for early design conversations and Topology for final documentation.

It’s the same underlying architecture — two visual languages for two different moments in the design lifecycle.

---

A fleet of 13 models: pick the right brain per task

The launch post shipped with multi-model support. That fleet has grown to 13 models across five providers, so you can match the model to the job — fast models for iteration, reasoning models for complex designs, code-optimized models for Bicep generation:

• OpenAI GPT-5.x — GPT-5.1, GPT-5.2, GPT-5.2 Codex, GPT-5.3 Codex, GPT-5.4, GPT-5.4 Mini
• DeepSeek — V3.2 Speciale, V4 Pro
• xAI Grok — 4.1 Fast, 4.3
• Mistral — Large 3
• MoonshotAI Kimi — K2.5, K2.7 Code

The Compare Models feature runs the same prompt through any subset of these in parallel and ranks them on service count, token usage, latency, and cost — with Fastest / Cheapest / Most Thorough badges — so you can make an evidence-based choice rather than a guess.

Figure 3. Multi-model comparison across the full 13-model fleet. Top: the results grid ranks every model on service count, connections, token usage, latency, and cost, with Fastest / Cheapest / Most Thorough badges. Bottom: an optional AI Critique uses a critic model to rank the outputs and explain each model’s strengths and gaps.

Adding a model is now a small, well-understood change — a testament to how the multi-provider abstraction has matured since May.

---

The headline: the Diagram Builder is now an MCP server

Here’s the change that reframes the project. Everything above is about a person using a web app. But the same capabilities — generating a diagram, validating it against WAF, estimating its cost, producing Bicep — are exactly the things an AI agent needs when it reasons about Azure architecture.

So we exposed them. The Azure Architecture Diagram Builder now runs as a Model Context Protocol (MCP) server. Any MCP-capable agent can call its tools with typed inputs and structured outputs:

This means an agent can hold a conversation like “design a HIPAA-compliant platform, check it against the Well-Architected Framework, tell me the monthly cost in West Europe, and give me the Bicep” — and the Diagram Builder answers each part programmatically, returning structured data the agent can reason over and chain.

Figure 4. The Diagram Builder as an MCP server inside Microsoft Scout. Top: from a natural-language request, the agent calls the render_diagram tool with structured parameters (title, format, direction, theme, region) and saves the returned SVG to its workspace. Bottom: the rendered architecture — grouped zones, labeled flows, and cost badges — appears inline in the conversation, generated entirely through agent tool calls.

The tool that started as a canvas for humans is now also a building block for agents. That’s the arc: from an app you click, to a partner you chat with, to a tool other agents call.

---

Grounded in Microsoft Learn, and sharper output

Two smaller-but-meaningful improvements round out the release:

• Microsoft Learn grounding. Deployment guides now search official Microsoft Learn documentation at generation time and cite it, so the guidance reflects current, authoritative practice rather than a model’s training snapshot.
• Output enhancements (July 2026). Rendered diagrams now carry per-service cost badges, support light and dark render themes, and include metadata panels that summarize the architecture — service counts, regions, and estimated cost — directly on the image.

---

Highlights

Since the May launch, the Azure Architecture Diagram Builder has grown from a design tool into an agent-ready platform:

• Conversational design: iterate on a diagram by chatting over the live canvas, with full history
• Two visual languages: formal topology and hand-drawn Blueprint, from the same architecture
• 13 models, five providers: choose the right brain per task, with evidence-based comparison
• Agent-ready: an MCP server exposing generation, validation, costing, and IaC as callable tools
• Grounded guidance: deployment guides cite live Microsoft Learn documentation
• Still open source: every capability above is available to inspect, extend, and contribute to

Try It Today

• Live demo: https://aka.ms/diagram-builder
• Source code: GitHub repository
• Documentation: See the Getting Started Guide for setup, and the repository’s MCP server directory for agent integration.

If you read the first post and tried the tool — thank you. The features above exist because you told me what you needed. Keep the feedback coming via GitHub Issues.

---

Tags: artificial intelligence · application · apps & devops · well architected · infrastructure

Keeping the UI thread free is always the best option. Unfortunately, there are situations where this is not entirely possible. Here’s a small progress spinner which keeps animating when the UI thread is busy.

This new alpha build has a quality of life improvement for the Move tools, support for CICP metadata, and good quality HDR->SDR tone mapping when opening HDR images with supported file types (including plugins).

You can read more about the CICP and HDR tone mapping support at https://x.com/rickbrewPDN/status/2072357433390047252 or https://bsky.app/profile/rickbrew.bsky.social/post/3mplx7ujotk2a

You can read more about 5.2 and what it includes by reading the release notes for the first alpha.

Change Log

Changes since 5.2 Alpha (build 9650):

• Changed: The Move Selection and Move Selected Pixels tools will now behave more intuitively when using constrained resizing (when holding shift). The aspect ratio that was used for a constrained resize used to be “locked in” when the selection was first drawn. The aspect ratio is now picked up when you start a constrained resize, and remembered until a non-constrained resize is performed.
• Added CICP metadata and color management support to the imaging framework 
  • See the CicpColorSpace struct in the PaintDotNet.Imaging namespace.
  • It has a CanColorTransformFrom property, indicating that it can be used as the source color space for the IImagingFactory.CreateColorTransformedBitmap or IBitmapSource.CreateColorTransformer extension methods.
  • It also has a CanCreateColorContext property that indicates when it is possible to create an IColorContext directly (ICC profiles can’t be generated for all CICP combinations) with the IImagingFactory.CreateColorContext(CicpColorSpace) extension method.
  • These can then be used by a FileType to provide a compatible image (“document”). Paint.NET’s color management is based on ICC color profiles, and some CICP color spaces (those involving PQ or HLG) cannot be expressed as an ICC color profile. Those images can, however, be transformed to an ICC-compatible color space with the aforementioned extension methods.
• Added HDR support to the new FileType plugin system
  • An image is tagged as HDR at load time via the IFileTypeDocument.Metadata.Hdr metadata section. Set IsHdrDocument to true, and optionally specify luminance data. The pixel format must be floating point (PixelFormats.Rgba64Half or PixelFormats.Rgba128Float), and the color context must be linearized.
  • Paint.NET does not yet support HDR editing, so it will convert the image to SDR with appropriate, high quality tone mapping.
• Added CICP support for AVIF, JPEG XL, and PNG.
• Added HDR tone mapping support for AVIF, HEIC, JPEG XL, JPEG XR, and PNG. If the image file being opened is HDR then it will be converted to SDR in an appropriate manner. Eventually Paint.NET will support HDR editing, this conversion process will go away, and the FileType plugins won’t even need to be updated.
• Added Rgb64, Rgb64Half, and Rgb128Float pixel formats for the imaging framework.
• Added a /disableCompositionSwapChain command-line parameter. This disables the use of Windows.UI.Composition, and should enable easier progress on the WINE effort.
• Fixed: When right-clicking on an image tab at the top, and then clicking on Open Containing Folder, two Explorer windows were being opened.
• Added a note in the installer about the new website address (https://www.paint.net). You can read more about it here: https://x.com/rickbrewPDN/status/2060397901650825238 or https://bsky.app/profile/rickbrew.bsky.social/post/3mmz73u6lzs2t

Download and Install

This build is available via the built-in updater as long as you have opted-in to pre-release updates. From within Settings -> Updates, enable “Also check for pre-release (beta) versions of paint.net” and then click on the Check Now button. You can also use the links below to download an offline installer or portable ZIP.

You can also download the installer here (for any supported CPU and OS), which is also where you can find downloads for offline installers, portable ZIPs, and deployable MSIs.

Hello Folks!

Welcome Back to AZ Update

A few years ago, Antony Bartolo and I launched a simple idea called AZ Update.

The goal was to provide a place where IT professionals could quickly understand what was changing in Azure, why it mattered, and what they should pay attention to next. The show became a weekly conversation focused on Azure news, infrastructure, operations, security, and the real-world impact of Microsoft's latest cloud updates.

Today, Azure is moving faster than ever.

Every week brings new services, platform capabilities, operational improvements, AI innovations, and architectural guidance. Keeping up is a full-time job. Most of us don't have time to read every blog post, release note, announcement, and documentation update.

That's why I'm bringing AZ Update back.

This time, as a weekly LinkedIn newsletter and this blog.  To be completely transparent I am using an AI Agent to parse the update list for any in the last 7 days, filter for Infra/Ops content and research product docs and help with the draft. I do review content and write the post myself.

Each edition will cut through the noise and focus on what matters most for cloud architects, platform engineers, infrastructure teams, SREs, security professionals, and IT operators. I'll share the Azure announcements worth your attention, explain why they're important, highlight practical implications, and point you to the resources that can help you go deeper.

Just a concise weekly briefing from one ITPro to another.

If your day-to-day involves building, operating, securing, or modernizing infrastructure in Azure, Azure Arc, AKS, hybrid environments, or the growing world of AI-powered operations, this newsletter is for you.

Welcome to the next chapter of AZ Update.

 

Here is week 1!

This week’s Azure infrastructure updates bring practical operational gains for security, platform reliability, disaster recovery, and identity-driven access control. Here is a detailed ITPro breakdown with implementation guidance you can use in production planning.

• Update #1 - Generally Available: Network Security Perimeter support for Azure Event Hubs
• Update #2 - Generally Available: Confidential Computing support for Azure Event Hubs Dedicated
• Update #3 - Generally Available: Support 5x churn in Azure Site Recovery
• Update #4 - Generally Available: Microsoft Entra ID-based access for Azure Blob Storage SFTP

Update #1 - Generally Available: Network Security Perimeter support for Azure Event Hubs

Why ITPros should care

Network Security Perimeter for Event Hubs changes how ITPros enforce connectivity boundaries around mission-critical event pipelines. Instead of depending only on isolated firewall rules per namespace, you can apply perimeter-aware controls that are easier to govern consistently across multiple services.

From an operations perspective, this is a service-level hardening improvement. It helps reduce accidental exposure and supports better audit conversations when security teams ask for clear evidence of allowed and denied paths.

Operational value

The operational value is stronger day-two control. You can standardise network access policy patterns for producer and consumer applications, reduce policy drift, and simplify incident investigations when unexpected traffic appears.

For production rollout, validate all dependencies first: private endpoints, DNS resolution, trusted service exceptions, managed identities, and cross-subscription network paths.

Real-world example with step-by-step guidance

1. Inventory current producer and consumer traffic flows, including private endpoints, DNS zones, and any trusted service allowances.
2. Deploy a pilot Event Hubs namespace with perimeter controls in non-production and mirror realistic ingestion and consumption traffic.
3. Apply least-privilege inbound and outbound perimeter rules, then execute end-to-end send/receive tests with representative message volume.
4. Review diagnostic logs for denies, refine exceptions only where business-justified, and capture evidence for change management.
5. Promote to production in stages with a rollback plan that restores previous network policy if message flow health degrades.

Technical details including code examples

Use the following sequence when validating that perimeter onboarding did not break data plane operations. The first command confirms your active Azure context, the second verifies endpoint reachability, and the third validates Event Hub metadata retrieval.

Run this safely in a test window before production enforcement. If connectivity and control-plane checks pass in test, repeat with production namespace read-only checks before enabling stricter policies.

az account show --output table Test-NetConnection <namespace>.servicebus.windows.net -Port 5671 az eventhubs eventhub show --resource-group <rg> --namespace-name <namespace> --name <eventhub> --output table

Expected outcome: TCP probe to port 5671 succeeds, and Event Hub metadata query returns without auth or network timeout errors. If probe fails, check DNS, NSGs, route tables, private endpoint linkage, and perimeter rule assignment scope.

Comprehensive Resources

• Azure update: Network Security Perimeter support for Azure Event Hubs
• Network Security Perimeter concepts
• Azure Event Hubs documentation
• Event Hubs networking and security

•  

Update #2 - Generally Available: Confidential Computing support for Azure Event Hubs Dedicated

Why ITPros should care

Confidential Computing support for Event Hubs Dedicated matters when ITPros operate regulated or high-sensitivity event streams. It extends protection expectations beyond encryption at rest and in transit, into stronger assurances during processing.

Compared with older architectures, this reduces the need for some compensating controls and helps security and operations teams align on platform-native protections for streaming workloads.

Operational value

Operationally, this strengthens trust boundaries for event ingestion platforms that feed analytics, SIEM, and business-critical automation. It also improves evidence posture for compliance reviews where data handling controls must be demonstrated end to end.

Before rollout, validate throughput impact, partition behaviour, client compatibility, and observability baselines so confidentiality controls do not create unexpected SLO regressions.

Real-world example with step-by-step guidance

1. Classify Event Hubs namespaces by sensitivity and select the first dedicated environment where enhanced confidentiality requirements apply.
2. Enable and validate in non-production with representative producer and consumer load, including peak and burst patterns.
3. Measure latency, throughput, and throttling trends before and after enablement to confirm workload behaviour remains acceptable.
4. Capture attestation and configuration evidence required by internal security governance or external auditors.
5. Roll out in waves by workload criticality, with rollback criteria tied to message latency, error rates, and throttling thresholds.

Technical details including code examples

This validation example confirms namespace details and metrics health so you can compare baseline vs post-change behaviour. The metrics query focuses on ingestion, egress, and throttling signals that commonly surface operational risk first.

Run with a least-privileged operations identity that can read namespace configuration and metrics. Avoid making unrelated changes while collecting baseline evidence.

az eventhubs namespace show --resource-group <rg> --name <namespace> --output jsonc az monitor metrics list --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.EventHub/namespaces/<namespace> --metric IncomingMessages OutgoingMessages ThrottledRequests --interval PT5M az account show --query user.name -o tsv

Expected outcome: namespace query succeeds, metrics return consistently, and no abnormal throttling spike appears after control changes. If results diverge, review dedicated capacity planning, partition strategy, RBAC scope, and workload profile fidelity.

Comprehensive Resources

• Azure update: Confidential Computing support for Azure Event Hubs Dedicated
• Event Hubs Dedicated overview
• Azure Confidential Computing overview
• Monitor Azure Event Hubs

•  

Update #3 - Generally Available: Support 5x churn in Azure Site Recovery

Why ITPros should care

Higher churn support in Azure Site Recovery is directly relevant for ITPros protecting write-intensive systems. It expands what can be replicated reliably, reducing DR exceptions for fast-changing workloads.

Compared with the previous operational envelope, this gives more room for modern transactional applications while still requiring disciplined capacity and replication health management.

Operational value

Operational value is improved DR coverage and better alignment between production write behaviour and recovery plans. Teams can protect more workloads without bespoke workaround architecture.

For production rollout, validate process server sizing, bandwidth headroom, cache storage performance, and sustained replication lag during peak change windows.

Real-world example with step-by-step guidance

1. Baseline current churn and replication lag for candidate workloads to identify which systems benefit most from the increased support.
2. Enable replication in a pilot for one high-churn workload and observe initial seeding and steady-state health.
3. Run test failover and reprotect to verify recovery objectives and operational runbook completeness.
4. Tune bandwidth and cache settings if lag increases during peak write intervals or backup overlap windows.
5. Onboard additional workloads incrementally and use replication health gates before each expansion wave.

Technical details including code examples

These commands are relevant for validating actual recovery readiness instead of configuration-only status. They expose protected item health and support controlled failover rehearsal.

Use a non-production network for test failover and document outputs so operations and business continuity stakeholders share the same readiness evidence.

az site-recovery fabric list --resource-group <rg> --vault-name <vault> -o table az site-recovery protected-item list --resource-group <rg> --vault-name <vault> --fabric-name <fabric> --protection-container <container> -o table az site-recovery recovery-plan test-failover --resource-group <rg> --vault-name <vault> --name <recoveryPlan> --network-id <testNetworkId>

Expected outcome: protected items remain healthy, lag remains within target, and test failover completes without consistency errors. If failures occur, inspect connectivity, process server capacity, cache throughput, and policy mappings.

Comprehensive Resources

• Azure update: Support 5x churn in Azure Site Recovery
• Azure Site Recovery documentation
• Monitor and troubleshoot Site Recovery
• Site Recovery capacity planning

•  

Update #4 - Generally Available: Microsoft Entra ID-based access for Azure Blob Storage SFTP

Why ITPros should care

This launch modernises SFTP access for Azure Blob Storage by bringing identity control closer to Microsoft Entra. ITPros gain stronger governance options than local-account-only models for many enterprise scenarios.

Operationally, the key change is identity lifecycle alignment: provisioning, review, and revocation can be managed with central identity processes instead of fragmented local credentials.

Operational value

The value is reduced credential sprawl, better auditability, and clearer access accountability across teams and external partners exchanging files over SFTP.

Before production, validate client compatibility, RBAC scope, network restrictions, access review cadence, and emergency break-glass procedures.

Real-world example with step-by-step guidance

1. Confirm SFTP is enabled on the storage account and validate networking model (public endpoint restrictions or private access path) matches policy.
2. Assign Entra-based permissions with least privilege and validate scope at storage account and container boundaries.
3. Test SFTP authentication and file operations using approved clients while collecting diagnostic logs for audit evidence.
4. Validate joiner-mover-leaver scenarios by changing membership and role assignments, then confirming access updates propagate correctly.
5. Roll out in stages by partner or workload segment with clear support ownership and incident response runbooks.

Technical details including code examples

This sequence verifies account capability and role assignment posture before user acceptance testing. It is useful for catching scope mistakes that often cause authentication-success/data-access-failure patterns.

Run safely by using a dedicated test identity and non-production storage account first; then repeat read-only validation in production before broad enablement.

az storage account show --name <storageAccount> --resource-group <rg> --query "{name:name,isSftpEnabled:isSftpEnabled,allowBlobPublicAccess:allowBlobPublicAccess}" -o jsonc az role assignment list --assignee <principalObjectId> --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<storageAccount> -o table az account show --query user.name -o tsv

Expected outcome: SFTP capability is enabled, expected role assignments are present, and test identity can perform allowed operations only. If sign-in works but file actions fail, inspect RBAC propagation delay, ACL/permission scope, and storage network restrictions.

Comprehensive Resources

• Azure update: Microsoft Entra ID-based access for Azure Blob Storage SFTP
• SFTP support for Azure Blob Storage
• Authorize blob data with Microsoft Entra ID
• Azure Storage security baseline

If you are planning adoption, start with one workload per update area, collect operational evidence, and standardise the validated pattern in your runbooks and IaC modules. That approach keeps change safe while accelerating delivery.

Cheers!

Pierre