rss.livelink.threads-in-node

I don't want to pay extra for copilot

David_pc — Sat, 04 Apr 2026 23:06:56 GMT

How do I make sure I don't pay extra for something I rarely use? My subscription is £85pa (well, £84.99).

P..s. What's going on with this? Also got this social media sharing bar blocking part of this page.

When the audio pipeline decides to act up 😂🤌

kikero_exe — Sat, 04 Apr 2026 16:53:26 GMT

Ever since build 2820.x.x.x, I’ve been keeping an eye on one specific process — Audio Graph Isolation.

And this little troublemaker 😂 sometimes decides it wants to “spice up your day.”

Not by taking a few MB of RAM…

Oh no, no — it goes straight for several gigabytes 😂

So you’re just sitting there, wondering why your system suddenly starts lagging, why the audio sounds like a corrupted Star Trek transmission after a virus attack 🙈😂

You open Task Manager, sort by RAM usage…

And there it is, grinning at you, Audio Graph Isolation, quietly turning your system into its personal victim 🙈

How to deal with it until Microsoft finally fixes this regression?

Honestly — the only thing that works is:

👉 force‑killing Audio Graph Isolation in Task Manager

And boom, your system instantly gets its speed back.

Unfortunately, because of this regression, you have to keep an eye on this process regularly, since the RAM leak can happen anytime during idle —

whether you’re watching a movie, listening to music, or the system is just running with no user input.

Vector Drift in Azure AI Search: Three Hidden Reasons Your RAG Accuracy Degrades After Deployment

akankshaGahalout — Sat, 04 Apr 2026 15:00:00 GMT

What Is Vector Drift?

Vector drift occurs when embeddings stored in a vector index no longer accurately represent the semantic intent of incoming queries.

Because vector similarity search depends on relative semantic positioning, even small changes in models, data distribution, or preprocessing logic can significantly affect retrieval quality over time.

Unlike schema drift or data corruption, vector drift is subtle:

The system continues to function
Queries return results
But relevance steadily declines

Cause 1: Embedding Model Version Mismatch

What Happens

Documents are indexed using one embedding model, while query embeddings are generated using another. This typically happens due to:

Model upgrades
Shared Azure OpenAI resources across teams
Inconsistent configuration between environments

Why This Matters

Embeddings generated by different models:

Exist in different vector spaces
Are not mathematically comparable
Produce misleading similarity scores

As a result, documents that were previously relevant may no longer rank correctly.

Recommended Practice

A single vector index should be bound to one embedding model and one dimension size for its entire lifecycle.

If the embedding model changes, the index must be fully re-embedded and rebuilt.

Cause 2: Incremental Content Updates Without Re-Embedding

What Happens

New documents are continuously added to the index, while existing embeddings remain unchanged. Over time, new content introduces:

Updated terminology
Policy changes
New product or domain concepts

Because semantic meaning is relative, the vector space shifts—but older vectors do not.

Observable Impact

Recently indexed documents dominate retrieval results
Older but still valid content becomes harder to retrieve
Recall degrades without obvious system errors

Practical Guidance

Treat embeddings as living assets, not static artifacts:

Schedule periodic re-embedding for stable corpora
Re-embed high-impact or frequently accessed documents
Trigger re-embedding when domain vocabulary changes meaningfully

Declining similarity scores or reduced citation coverage are often early signals of drift.

Cause 3: Inconsistent Chunking Strategies

What Happens

Chunk size, overlap, or parsing logic is adjusted over time, but previously indexed content is not updated. The index ends up containing chunks created using different strategies.

Why This Causes Drift

Different chunking strategies produce:

Different semantic density
Different contextual boundaries
Different retrieval behavior

This inconsistency reduces ranking stability and makes retrieval outcomes unpredictable.

Governance Recommendation

Chunking strategy should be treated as part of the index contract:

Use one chunking strategy per index
Store chunk metadata (for example, chunk_version)
Rebuild the index when chunking logic changes

Design Principles

Versioned embedding deployments
Scheduled or event-driven re-embedding pipelines
Standardized chunking strategy
Retrieval quality observability
Prompt and response evaluation

Key Takeaways

Vector drift is an architectural concern, not a service defect
It emerges from model changes, evolving data, and preprocessing inconsistencies
Long-lived RAG systems require embedding lifecycle management
Azure AI Search provides the controls needed to mitigate drift effectively

Conclusion

Vector drift is an expected characteristic of production RAG systems. Teams that proactively manage embedding models, chunking strategies, and retrieval observability can maintain reliable relevance as their data and usage evolve. Recognizing and addressing vector drift is essential to building and operating robust AI solutions on Azure.

Entra CBA Preview Bug: Issuer Scoping Policy fails group claim (AADSTS500191)

alejlw — Sat, 04 Apr 2026 14:46:33 GMT

I am deploying a zero-trust, cloud-native Certificate-Based Authentication (CBA) architecture for a break-glass emergency access account in Microsoft Entra ID. I am intentionally bypassing Intune/MDM to prevent circular dependencies during an outage.

The PKI is generated via OpenSSL (Offline Root CA -> Client Cert). The cryptography is flawless:

- The OpenSSL chain verifies perfectly (openssl verify -CAfile...).

- The Root SKI and Client AKI are a perfect 1:1 hex match.

- The client cert EKU includes TLS Web Client Authentication.

- The client cert SAN includes othername: UPN::[break-glass-UPN].

- The Root CA and CRL are uploaded to Entra and publicly accessible via Azure Blob Storage.

The Issue:

When I attempt to restrict the Root CA using the "Certificate issuer scoping policy (Preview)" targeted to a specific Security Group (e.g., sg_cba), the TLS handshake drops and Entra throws:

Error: AADSTS500191: The certificate authority that issued your certificate has not been set up in the tenant.

Troubleshooting Performed:

1. Group Architecture: Verified via Microsoft Graph that the user is a direct, static member of sg_cba (Security Enabled, non-dynamic, not nested).

2. Micro-Group Bypass: Created a brand-new cloud-only micro-group with only the break-glass user. Waited for replication. Same 500191 error.

3. The Control Test (Success): If I completely remove the Preview scoping policy and move the targeting to the Generally Available (GA) tenant-wide trust ("All Users"), the login succeeds immediately. (I am securing this via High-Affinity binding matching the SKI to CertificateUserIDs).

The Ask:

Because the tenant-wide GA policy works perfectly, it mathematically proves the certificates, CRL, and bindings are correct. The failure is entirely isolated to the Preview scoping engine failing to correlate the incoming certificate to the Security Group claim fast enough.

- Has anyone successfully deployed the "Certificate issuer scoping policy (Preview)" using a targeted security group without it dropping the trust?

- Are there undocumented constraints on group evaluation during the CBA TLS handshake that cause this Preview feature to fail closed?

How to Secure Your Windows 11 PC (Complete Guide)

JohnNaguib — Sat, 04 Apr 2026 09:26:58 GMT

If you’re using Windows 11 daily—whether for work, gaming, or personal tasks security should never be an afterthought. As someone who has worked extensively with Windows systems, I can confidently say that Windows 11 is one of the most secure operating systems Microsoft has released. But here’s the catch: out-of-the-box security is only the starting point. To truly protect your PC, you need to actively configure and maintain it.

https://dellenny.com/how-to-secure-your-windows-11-pc-complete-guide/

Windows 11 What is this logo used for？

KevinHarvey — Sat, 04 Apr 2026 05:49:26 GMT

I saw an unknown logo on Windows 11 and would like to know what it is for.

Windows 11 Keeps Prompting GPU Driver Installation on Every Restart

BrantleyTaylor — Sat, 04 Apr 2026 04:46:41 GMT

My GPU driver is already installed, but Windows 11 still shows the installation prompt after every restart. Deleting the installer didn’t help. How to fix this?

Windows 11 Screen automatically turns warm without night mode

DevonZhang — Sat, 04 Apr 2026 04:45:09 GMT

My Windows 11 screen keeps turning warm automatically even with night mode off. It briefly normalizes when I click the screen then warms up again. How to fix this?

How XLOOKUP arguments apply in this case

MollyKitti — Sat, 04 Apr 2026 00:43:33 GMT

I'm not an Excel newbie, but I have never had cause to use XLOOKUP, INDEX, or MATCH before. I'm not understanding how the xlookup arguments would apply in my case or if index/match would be better. I have an array with months as my row headings and dates as my column headings. The array itself is filled with number of pages read each day. I'm trying to have a cell indicating on which date I did the maximum amount of reading. So I want to start with the max value of my array and return the month (row) and date (column) heading using xlookup. Whether those are in one cell or two, doesn't so much matter - it's a hobby tracker, but no matter how I try and call this, I end up with a value error

So for example, I would want this to return January 3rd. Every example I'm finding seems to show how to input Jan 3rd and return the value 758. What am I missing to look this up the other way around? Should I be using index or match instead?

Not understanding XLOOKUP arguments as they apply here

MollyKitti — Sat, 04 Apr 2026 00:31:08 GMT

undefined

April 2026 MSLE Newsletter available now!

RobinLBaldwin — Fri, 03 Apr 2026 23:27:05 GMT

Head over to the blog section and read the newest edition of the MSLE Newsletter, also available in Arabic, Chinese (Traditional), French, Portuguese, and Spanish

From the Microsoft Learn for Educators community page, select Blogs from the top navigation menu.
There, you’ll find the Microsoft Learn for Educators News blog where you can find the newsletter. Additional language versions can be found as attachments to the blog.

Expanding Azure Arc SQL Migration with a New Target: SQL Server on Azure Virtual Machines

danimir — Fri, 03 Apr 2026 22:55:58 GMT

Modernizing a SQL Server estate is rarely a single-step effort. It typically involves multiple phases, from discovery and assessment to migration and optimization, often spanning on-premises, hybrid, and cloud environments. SQL Server enabled by Azure Arc simplifies this process by bringing all migration steps into a single, cohesive experience in the Azure portal.

With the March 2026 release, this integrated experience is extended by adding SQL Server on Azure Virtual Machines as a new migration target in Azure Arc. Arc-enabled SQL Server instances can now be migrated not only to Azure SQL Managed Instance, but also to SQL Server running on Azure infrastructure, using the same unified workflow.

Expanding Choice Without Adding Complexity

By introducing SQL Server on Azure Virtual Machines as a migration target, Azure Arc now supports a broader range of migration strategies while preserving a single operational model. It becomes possible to choose between Azure SQL Managed Instance and SQL Server on Azure VMs without fragmenting migration tooling or processes.

The result is a flexible, scalable, and consistent migration experience that supports hybrid environments, reduces operational overhead, and enables modernization at a controlled and predictable pace.

One Integrated Migration Journey

A core value of SQL Server migration in Azure Arc is that the entire migration lifecycle is managed from one place. Once a SQL Server instance is enabled by Azure Arc, readiness can be assessed, a migration target selected, a migration method chosen, progress monitored, and cutover completed directly in the Azure portal.

This approach removes the need for disconnected tools or custom orchestration. The only prerequisite remains unchanged: the source SQL Server needs to be enabled by Azure Arc. From there, migration is fully integrated into the Azure Arc SQL experience.

A Consistent Experience Across Migration Targets

The migration experience for SQL Server on Azure Virtual Machines follows the same model already available for Azure SQL Managed Instance migrations in Azure Arc. The same guided workflow, migration dashboard, and monitoring capabilities are used regardless of the selected target.

This consistency is intentional. It allows teams to choose the destination that best fits their technical, operational, or regulatory requirements without having to learn a new migration process. Whether migrating to a fully managed PaaS service or to SQL Server on Azure infrastructure, the experience remains predictable and familiar.

Backup Log Shipping Migration to SQL Server in Azure VM

Migration to SQL Server on Azure Virtual Machines is based on backup and restore, specifically using log shipping mechanism. This is a well-established approach for online migrations that minimizes downtime while maintaining control over the cutover window.

In this model, database backups need to be uploaded from the source SQL Server to Azure Blob Storage. The migration engine will restore the initial full backup followed by ongoing transaction log and diff. backups. Azure Blob Storage acts as the intermediary staging location between the source and the target.

The Azure Blob Storage account and the target SQL Server running on an Azure Virtual Machine must be co-located in the same Azure region. This regional alignment is required to ensure efficient data transfer, reliable restore operations, and predictable migration performance.

Within the Azure Arc migration experience, a simple and guided UX is used to select the Azure Blob Storage container that holds the backup files. Both the selected storage account and the Azure VM hosting SQL Server must reside in the same Azure region.

Once the migration job is started, Azure Arc automatically restores the backup files to SQL Server on the Azure VM. As new log backups are uploaded to Blob Storage, they are continuously detected and applied to the target database, keeping it closely synchronized with the source.

Controlled Cutover on Your Terms

This automated restore process continues until the final cutover is initiated. When the cutover command is issued, Azure Arc applies the final backup to the target SQL Server on the Azure Virtual Machine and completes the migration.

The target database is then brought online, and applications can be redirected to the new environment. This controlled cutover model allows downtime to be planned precisely, rather than being dictated by long-running restore operations.

Getting started

To get started, Arc enable you SQL Server. Then, in the Azure portal, navigate to your Arc enabled SQL Server and select Database migration under the Migration menu on the left. For more information, see the SQL Server migration in Azure Arc documentation.

Windows news you can use: March 2026

Chris_Morrissey — Fri, 03 Apr 2026 21:00:00 GMT

This month, our Windows team shared a candid update on how we're thinking about Windows quality, what's changing behind the scenes, and how your real-world feedback is shaping the platform. It's all in a post entitled Our commitment to Windows quality. Windows + Devices EVP Pavan Davuluri walks through how we identify issues, prioritize fixes, and how the Windows Insider community helps make Windows more reliable before updates reach production environments. It's a helpful read if you're interested in learning more about how we build, measure, and strengthen Windows quality.

Now on to more highlights from March in this month's edition of Windows news you can use.

New in Windows update and device management

[AUTOPATCH] – Windows Autopatch update readiness is now generally available. It includes new capabilities to help you proactively detect and remediate device update issues. Reduce downtime, improve update success, and lower the security risk that comes from devices that aren't up to date.
[HOTPATCH] – Windows Autopatch is enabling hotpatch updates by default starting with the May 2026 security update. This change in default behavior will come to all eligible devices in Microsoft Intune and those accessing the service via Microsoft Graph API. New controls are available for those organizations that aren't ready to have hotpatch updates enabled by default.
[RSAT] – Remote Server Administration Tools (RSAT) are now officially supported on Arm-based Windows 11 PCs. You can now remotely manage Windows server roles and features using Windows devices built on Arm processors, just as you would with traditional x64-based PCs.
[SECURE BOOT] – The March 2026 security update introduces two new PowerShell features to help you manage the ongoing Secure Boot certificate rollout. The Get-SecureBootUEFI cmdlet now supports the -Decoded option, which displays Secure Boot certificates in a readable format. The Get-SecureBootSVN cmdlet lets you check the Secure Boot Security Version Number (SVN) of your device's UEFI firmware and bootloader. Use it to report whether the device follows the latest Secure Boot policy.
[PRINT] – Instead of requiring device-specific drivers, Windows is now released with a single, universal, inbox-class driver based on the industry standard IPP protocol and Mopria certification. If you're using a traditional x64 PC, including the latest Copilot+ PC running on Arm-based silicon, the print experience is the same: plug in (or connect over the network) and print.
[W365] – Windows 365 Frontline in shared mode is now available in Brazil South, Italy North, West Europe, New Zealand North, Mexico Central, Europe, Norway East, France Central, Spain Central, Germany West Central, and Switzerland North. Windows 365 is now available for Government Community Cloud (GCC & GCC-High) organizations in the US Gov Texas region. In addition, multi-region selection is now available for Windows 365 GCC & GCC-High.
[RDP] – Microsoft recently released a sample repository demonstrating how to build Remote Desktop Protocol (RDP) plugins using modern tools and development patterns.

New in Windows security

[DRIVERS] – Starting with the April 2026 security update, Microsoft is removing trust for all kernel drivers signed by the deprecated cross-signed root program. This update will help ensure that by default, you can only load kernel drivers the Windows Hardware Compatibility Program (WHCP) passes and signs. This new kernel trust policy applies to devices running Windows 11 and Windows Server 2025.
[SECURE BOOT] – Catch up on the latest FAQs by watching the March edition of Secure Boot: Ask Microsoft Anything (AMA) on demand. The next AMA will be April 23, 2026. Save the date and post your questions in advance or during the live event. New guidance and resources are now available, including:
- Video deep dive: Secure Boot certificate updates explained
- Guide: Secure Boot troubleshooting
- Reference: A closer look at the high confidence database
- Documentation and sample PowerShell scripts: Sample Secure Boot E2E automation
- Guide: Secure Boot certificate update status in the Windows Security app[SYSMON] – System Monitor (Sysmon) functionality is now natively available in Windows. Capture system events for threat detection and use custom configuration files to filter the events you want to monitor. Windows writes captured events to Windows Event Log, which allows security tools and other applications to use them.
[WDS] As announced in January 2026, the Unattend.xml file used in hands‑free deployment with Windows Deployment Services (WDS) poses a vulnerability when transmitted over an unauthenticated RPC channel. Beginning with the April 2026 security update, the second phase of hardening changes for CVE-2026-0386 begins. These changes will make hands‑free deployment disabled by default to enforce secure behavior. For detailed guidance, see Windows Deployment Services (WDS) Hands‑Free Deployment Hardening.

New in AI

[W365] [AGENTS] – Curious about the difference between Windows 365 for Agents and Microsoft Agent 365? Explore the distinct role of each product and learn how to use them together to run agentic workloads securely, at scale, and under enterprise governance.

To learn about latest capabilities for Copilot+ PCs, visit the Windows Roadmap and filter Platform by "Copilot+ PC Exclusives."

New in Windows Server

For the latest features and improvements for Windows Server, see the Windows Server 2025 release notes and Windows Server, version 23H2 release notes.

[EVENT] – Save the date for the Windows Server Summit, May 11-13. RSVP for three days of practical, engineering-led guidance on real-world operations, security, and hybrid scenarios supported by live Q&A.
[NVMe] – A basic NVMe-over-Fabrics (NVMe-oF) initiator is available in the latest Windows Server Insiders build. This release introduces an in-box Windows initiator for NVMe/TCP and NVMe/RDMA, enabling early evaluation of networked NVMe storage using native Windows Server components.

New in productivity and collaboration

Install the March 2026 security update for Windows 11, versions 25H2 and 24H2 to get these and other capabilities, which will be rolling out gradually:

[RECOVERY] – Quick Machine Recovery now turns on automatically for Windows Professional devices that are not domain‑joined and not enrolled in enterprise endpoint management. These devices receive the same recovery features available to Windows Home users. For domain‑joined or enterprise managed devices, Quick Machine Recovery stays off unless you enable it for your organization.
[NETWORK] – A built‑in network speed test is now available from the taskbar. The speed test opens in the default browser and measures Ethernet, Wi‑Fi, and cellular connections.
[CAMERA] – Control pan and tilt for supported cameras in the Settings app.
[SEARCH] – Using search on the taskbar? Preview search results by hovering and quickly seeing when more results are available with group headers.

New features and improvements are coming in the April 2026 security update. You can preview them by installing the March 2026 optional non-security update for Windows 11, versions 25H2 and 24H2. This update includes the gradual rollout of:

[SECURITY] –You can turn Smart App Control on or off without needing a clean install.
[SETTINGS] – The Settings > About page now provides a more structured and intuitive experience. Get clearer device specifications and easier navigation to related device components, including quick access to Storage settings.

Lifecycle reminders

Windows 10 Enterprise 2016 LTSB and Windows 10 IoT Enterprise 2016 LTSB will reach end of support on October 13, 2026. Windows Server 2016 will reach end of support on January 12, 2027. If your organization cannot migrate to newer, supported releases in time, explore the options available to help you keep your devices protected with monthly security updates. Extended Security Updates (ESU) are now available for purchase for Windows 10 Enterprise 2016 LTSB.

Check out our lifecycle documentation for the latest updates on Deprecated features in the Windows client and Features removed or no longer developed starting with Windows Server 2025.

Additional resources

Looking for the latest news and previews for Windows, Copilot, Copilot+ PCs, the Windows and Windows Server Insider Programs, and more? Check out these resources:

Windows Roadmap for new Copilot+ PCs and Windows features – filter by platform, version, status, and channel or search by feature name
Microsoft 365 Copilot release notes for latest features and improvements
Windows Insider Blog for what's available in the Canary, Dev, Beta, or Release Preview Channels
Windows Server Insider for feature preview opportunities
Understanding update history for Windows Insider preview features, fixes, and changes to learn about the types of updates for Windows Insiders

Join the conversation

If you're an IT admin with questions about managing and updating Windows, add our monthly Windows Office Hours to your calendar. We assemble a crew of Windows, Windows 365, security, and Intune experts to help answer your questions and provide tips on tools, best practices, and troubleshooting.

Finally, we're always looking to improve this monthly summary. Drop us a note in the Comments and let us know what we can do to make this more useful for you!

Continue the conversation. Find best practices. Bookmark the Windows Tech Community, then follow us @MSWindowsITPro on X and on LinkedIn. Looking for support? Visit Windows on Microsoft Q&A.

#IntuneForMSPs Meetup - June 2026

Pearl-Angeles — Fri, 03 Apr 2026 20:55:34 GMT

Save the date for June's #IntuneForMSPs Community Meetup! These community‑driven events bring together MSPs, Microsoft MVPs, and Intune experts to discuss top‑of‑mind topics shaping device management today. You'll gain practical insights, explore real‑world lessons learned, and hear invaluable peer perspectives to help deepen your technical skills while exploring ways to grow and differentiate your MSP practice. Beyond the tech, the series also offers ideas for strengthening service offerings, refining go‑to‑market approaches, and building lasting connections across the MSP community.

How do I participate?

Registration is not required. Add this event to your calendar and select Attend to receive reminders. Post your questions in advance, or any time during the live broadcast.

Stay informed, stay connected

Bookmark the Microsoft Intune for MSPs resource guide, your home for all things #IntuneForMSPs, for future session dates and resources to help you on your journey.

From box to business‑ready with Windows Autopilot - #IntuneForMSPs Meetup

Pearl-Angeles — Fri, 03 Apr 2026 20:48:56 GMT

Join us for the April #IntuneForMSPs community meetup featuring Microsoft MVP Steve Weiner. Steve will share practical, MSP-focused insights on using Windows Autopilot with Microsoft Intune to streamline device provisioning, reduce hands-on deployment time, and improve the onboarding experience for customers at scale. Learn real-world Windows Autopilot strategies that MSPs can apply immediately, common pitfalls to avoid, and tips on how to operationalize Windows Autopilot as part of a modern endpoint management practice.

How do I participate?

Registration is not required. Add this event to your calendar and select Attend to receive reminders. Post your questions in advance, or any time during the live broadcast.

Stay informed, stay connected

Bookmark the Microsoft Intune for MSPs resource guide, your home for all things #IntuneForMSPs, for future session dates and resources to help you on your journey.

#IntuneForMSPs Meetup - May 2026

Pearl-Angeles — Fri, 03 Apr 2026 20:45:11 GMT

Save the date for May's #IntuneForMSPs Community Meetup! These community‑driven events bring together MSPs, Microsoft MVPs, and Intune experts to discuss top‑of‑mind topics shaping device management today. You'll gain practical insights, explore real‑world lessons learned, and hear invaluable peer perspectives to help deepen your technical skills while exploring ways to grow and differentiate your MSP practice. Beyond the tech, the series also offers ideas for strengthening service offerings, refining go‑to‑market approaches, and building lasting connections across the MSP community.

How do I participate?

Registration is not required. Add this event to your calendar and select Attend to receive reminders. Post your questions in advance, or any time during the live broadcast.

Stay informed, stay connected

Bookmark the Microsoft Intune for MSPs resource guide, your home for all things #IntuneForMSPs, for future session dates and resources to help you on your journey.

Introducing TSGen: Automated TSG Generation @ Scale – Built by AI

Daniel-Genkin-MSFT — Fri, 03 Apr 2026 20:18:41 GMT

This post is a follow-up to the previous write-up at https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/the-future-of-ai-autonomous-agents-for-identifying-the-root-cause-of-cloud-servi/4412494?previewMessage=true. If you haven’t read it yet, it provides the background on why we started building TSGen, our Troubleshooting Guide Generator, and the core idea behind automated, scalable generation. This post outlines how we built TSGen on a cross-discipline team using AI for both research and engineering workflows, focusing on the core algorithm and some preliminary results.

The Challenge: Why Manual Troubleshooting Guides Fall Short

Operating cloud services at scale presents unique challenges for incident management. When issues arise, engineers rely on Troubleshooting Guides (TSGs) to diagnose and resolve problems quickly. However, manual TSG creation and maintenance can occasionally create bottlenecks. TSGs are often siloed across different platforms, making them difficult to locate during critical incidents. The content itself tends to be inconsistently structured between silos and occasionally incomplete, requiring engineers to interpret ambiguous instructions under time pressure. We ran an internal study examining over 4,000 TSGs mapped to thousands of incidents that revealed that while TSGs significantly reduce mitigation efforts when properly maintained, their quality varies dramatically. Engineers surveyed about TSG effectiveness consistently report issues with outdated information, missing steps, and lack of clarity. These quality gaps lead to extended incident resolution times, increased engineer fatigue, and higher operational costs.

Figure 1: Categorizing Weight of TSG Aspects on Time to Mitigate and On-Call Experience

The Solution: Automating Troubleshooting Guide creation with AI

The core technical innovation is the use of an AI system that automatically synthesizes high‑quality, structured Troubleshooting Guides (TSGs) directly from historical incident data, rather than relying on manual authoring. TSGen ingests diverse operational signals—such as past IcM incidents identified via monitor IDs or custom Kusto queries—and produces end‑to‑end, action‑oriented troubleshooting workflows within minutes. This shifts TSG creation from a labor‑intensive, error‑prone documentation task into an automated knowledge synthesis problem, enabling consistent structure and coverage across services.

A second key innovation is operational scalability with continuous relevance. TSGen is designed not only to generate new TSGs, but to keep them up‑to‑date as new incidents occur, addressing the chronic issue of stale or incomplete troubleshooting documentation. The system has already demonstrated practical effectiveness in pilot deployments, with dozens of generated TSGs accepted and published for real on‑call usage, showing that AI‑generated artifacts can meet production engineering standards rather than serving as drafts or suggestions.

Finally, TSGen explicitly targets dual consumption by humans and AI agents, generating structured outputs that are useful both for on‑call engineers and for automated agents involved in incident diagnosis. This positions TSGs as a shared, machine‑readable knowledge layer rather than static documents, reducing “tribal knowledge” and enabling faster, more reliable incident response at scale across Microsoft services.

Figure 2: Zero-ing in on the most common issues found in TSGs

TSGen's Five-Step Automated Workflow

TSGen addresses the manual TSG challenge through a sophisticated five-step automated workflow that transforms incident data into executable troubleshooting guides. The first step, Collection, gathers incident data from multiple sources including diagnostic logs, historical tickets, and troubleshooting documentation. This comprehensive data aggregation creates the foundation for intelligent TSG generation. The second step, Filtering, removes noise and irrelevant information from the collected data. Machine learning algorithms identify which incident attributes are most relevant for troubleshooting, eliminating false signals that could lead to incorrect guidance. The third step, Core Incident Selection, identifies representative incidents that exemplify common problem patterns. Rather than processing every incident individually, TSGen selects the most informative examples that capture the essential troubleshooting logic. The fourth step, Data Distillation, extracts key troubleshooting patterns and actionable steps from the selected incidents. This process analyzes successful resolution paths to identify the critical diagnostic checks and mitigation actions. The fifth and final step, TSG Generation, synthesizes the distilled information into structured, actionable troubleshooting guides. The output is a well-formatted TSG that engineers can follow systematically during incident response.

Figure 3: The TSGen Five-Step Workflow

From Manual to Automated: Real-World Impact

The shift from manual TSG creation to automated TSG maintenance delivers measurable benefits for incident management operations. Teams using automated TSG maintenance report significant reductions in time-to-mitigation for common incident types. Engineers spend less time searching for relevant documentation and interpreting ambiguous instructions by ensuring that all TSGs have consistent formatting and reliable information, allowing them to focus on complex problem-solving.

Figure 4: With The Presence of a TSG, Incident Mitigation time decreases by ~40%

Industry-Wide Implications for Cloud Operations

TSGen represents a broader trend toward intelligent automation in cloud operations. The challenges of maintaining high service availability while managing complex distributed systems affect organizations across industries. As cloud infrastructure grows in scale and complexity, the volume of potential incidents increases exponentially. Traditional manual approaches cannot keep pace with this growth. Automated TSG generation offers a scalable solution that improves with the volume of data it processes. Each incident handled by the system contributes to its collection of incident knowledge, creating a positive feedback loop for ever improving TSGs. This scalability benefit is particularly valuable for organizations operating multiple services or supporting global customer bases. The technology also democratizes incident management expertise. In traditional models, effective troubleshooting requires deep institutional knowledge that takes years to develop. Automated systems capture and codify this expertise, making it accessible to engineers at all experience levels. This knowledge transfer capability reduces dependency on veteran engineers and accelerates onboarding for new team members.

Key Benefits of Automated TSG Generation

Automated TSG generation delivers multiple strategic advantages for organizations managing cloud infrastructure:

Faster incident resolution reduces service disruptions and improves customer experience
Improved TSG quality through continuous learning ensures troubleshooting guidance remains accurate and comprehensive
Reduced operational costs result from decreased manual documentation maintenance and shorter incident durations
Enhanced engineer productivity allows technical teams to focus on innovation rather than repetitive troubleshooting tasks
Knowledge preservation captures institutional expertise in executable form, protecting organizations from knowledge loss when engineers transition
Scalability enables consistent incident management across growing infrastructure without proportional headcount increases
Data-driven insights from automated systems reveal patterns in incident types and resolution effectiveness, informing preventive measures

How We Built This Iteration

This iteration was developed in VS Code using Copilot CLI, with Claude models (including Opus 4.6) for implementation support and rapid iteration. This new iteration was primarily focused on improving output quality from the core algorithm, improving engineering efficiency / speed of iteration by migrating from Node.js to Python to simplify the codebase and speed up experimentation, and in deploying a new agentic playground to make it easier for teams across Microsoft to experiment and help beta test.

Learnings and Recommendations from Building with AI

This iteration was both a research and an engineering project. Our cross-discipline team leveraged AI at every level of development. The majority of the code that we developed for this new iteration was created by AI, allowing us to iterate and develop faster. A few practical learnings helped us get better outcomes and avoid rework:

Create a solid plan up front for each major change.
- We used the “Plan” mode in VS Code to have Claude AI models assist in defining what we want to make in a way that AI can leverage.
- For example, when we converted the codebase from NodeJS to Python, we made a new dedicated plan.

Be detailed in the initial description and write down explicit requirements as bullet points (including edge cases and non-goals).
- Our initial prompt to generate the plan was quite long. However, it was not highly structured. We focused primarily on getting the information into the AI, rather than giving it an actual handmade plan.
- For example, we included snippets such as what the new folder structure should be and that there should be no regressions in functionality.

If you already know how you want something to work, state it directly - specific instructions beat vague intent.
- Often models can produce solutions that you weren’t expecting. This can be good at times and inconvenient at other times. So, if you know what your end goal looks like, give code pointers and specific details for what functions should be named, what they should do, etc.
- During plan creation, answer follow-up questions with as much context as you can, so assumptions don’t creep in.

Often times when designing a plan, the AI will ask some follow up questions. We treated these as an opportunity to elaborate. When the model asks for a follow up, don’t be shy to give it a lot of information. This can help make sure that it delivers a result similar to what you are expecting.
- Read the plan critically and “negotiate” it as you go—treat the AI like a junior developer and make expectations explicit.
- After you have a plan, make sure to read it fully to ensure that little miscommunications don’t occur. This is similar to the previous point, where you want to make sure that everything is sufficiently detailed but also that the details align with what you are trying to create.

If a model isn’t producing good results, switch models and try again.
- Sometimes bringing in a new model can have the same effect as bringing in a different engineer with a fresh set of eyes. Especially given the speed of release for new models.

When the model is missing context, give hints about where to look (files, folders, examples, or the specific component to start from) so it can ground its plan.
- If a model is asking questions or creating code that does not align with your interpretation of the plan, try to ground the plan in examples. This can help drastically clear up the miscommunications.

Looking Forward: The Future of Intelligent Incident Management

The evolution of TSG automation points toward increasingly autonomous incident management systems. Current systems like TSGen focus on automating TSG generation and execution for known incident patterns. Future developments will likely expand into autonomous root cause analysis and predictive incident prevention. Advanced AI agents could execute complex diagnostic workflows without human intervention, escalating only when novel situations arise that require human judgment. Natural language processing capabilities will enable engineers to interact with troubleshooting systems conversationally, asking questions and receiving context-aware guidance. The integration of reinforcement learning could allow systems to optimize troubleshooting strategies in real-time based on success rates. These systems might automatically adjust their approaches when initial steps prove ineffective, exploring alternative resolution paths intelligently. Another promising direction involves cross-system learning, where troubleshooting knowledge from one service or organization informs incident management in others. This collective intelligence approach could accelerate the development of effective troubleshooting strategies industry-wide. The ultimate vision is incident management systems that continuously improve, require minimal human oversight, and prevent problems before they impact customers.

Removing Old MS 365 Account

bcole1 — Fri, 03 Apr 2026 20:10:50 GMT

I had a Office 365 account under the discontinued educational organization license. The cloud storage was supposed to be disabled by MS at some point. So, I bought a personal Ofc 365 subscription.

I tried to remove references to the old account and register my new license under a different email address, however my machine is still ate up with it, it still tries to save documents to that supposedly disabled Onedrive location and Office applications still confuse it. I scanned the system registry and there are hundreds of references to the old account & configuration. This is a problem on several of my home machines.

How do I totally nuke that old account?

Run the latest Azure Arc agent with Automatic Agent Upgrade (Public Preview)

yunishussein — Fri, 03 Apr 2026 19:30:06 GMT

Customers managing large fleets of Azure Arc servers need a scalable way to ensure the Azure Arc agent stays up to date without manual intervention. Per server configuration does not scale, and gaps in upgrade coverage can lead to operational drift, missed features, and delayed security updates.

To address this, we’re introducing two new options to help customers enable Automatic Agent Upgrade at scale: applied as a built-in Azure Policy and a new onboarding CLI flag.

The built-in policy makes it easy to check whether Automatic Agent Upgrade is enabled across a given scope and automatically remediates servers that are not compliant.

For servers being newly onboarded, customers can enable the feature at onboarding by adding the --enable-automatic-upgrade flag to the azcmagent connect command, ensuring the agent is configured correctly from the start.

What is Automatic Agent Upgrade?

Automatic Agent Upgrade is a feature, in public preview, that automatically keeps the Azure Connected Machine agent (Arc agent) up to date. Updates are managed by Microsoft, so once enabled, customers no longer need to manually manage agent upgrades.

By always running the latest agent version, customers receive all the newest capabilities, security updates, and bug fixes as soon as they’re released. Learn more: What's new with Azure Connected Machine agent - Azure Arc | Microsoft Learn.

Getting Started

Apply automatic agent upgrade policy

Navigate to the ‘Policy’ blade in the Azure Portal

Navigate to the ‘Compliance’ section and click ‘Assign Policy’

Fill out the required sections
- Scope: Subscription and resource group (optional) that policy will apply to
- Policy definition: Configure Azure Arc-enabled Servers to enable automatic upgrades

Navigate to the ‘Remediation’ tab and check the box next to ‘Create a remediation task’

Navigate to the ‘Review + create’ tab and press ‘Create’. The Policy has been successfully applied to the scope.

For more information on this process, please visit this article Quickstart: Create policy assignment using Azure portal - Azure Policy | Microsoft Learn.

Apply automatic agent upgrade CLI Flag

Adding the following flag enables automatic agent upgrade during onboarding

--enable-automatic-upgrade

While this flag can be used on a single server, it can also be applied at scale using one of the existing Azure Arc at scale onboarding methods and adding the flag Connect hybrid machines to Azure at scale - Azure Arc | Microsoft Learn.

Here is an at scale onboarding sample using a basic script.

azcmagent connect --resource-group {rg} --location {location} --subscription-id {subid} --service-principal-id {service principal id} --service-principal-secret {service principal secret} --tenant-id {tenant id} --enable-automatic-upgrade

To get started with this feature or learn more, please refer to this article Manage and maintain the Azure Connected Machine agent - Azure Arc | Microsoft Learn.

Secure HTTP‑Only AKS Ingress with Azure Front Door Premium, Firewall DNAT, and Private AGIC

kkaushal — Fri, 03 Apr 2026 19:15:55 GMT

Reference architecture and runbook (Part 1: HTTP-only) for Hub-Spoke networking with private Application Gateway (AGIC), Azure Firewall DNAT, and Azure Front Door Premium (WAF)

0. When and Why to Use This Architecture

Series note: This document is Part 1 and uses HTTP to keep the focus on routing and control points. A follow-up Part 2 will extend the same architecture to HTTPS (end-to-end TLS) with the recommended certificate and policy configuration.

What this document contains

Scope: Architecture overview and traffic flow, build/run steps, sample Kubernetes manifests, DNS configuration, and validation steps for end-to-end connectivity through Azure Front Door → Azure Firewall DNAT → private Application Gateway (AGIC) → AKS.

Typical scenarios

Private-by-default Kubernetes ingress: You want application ingress without exposing a public Application Gateway or public load balancer for the cluster.
Centralized hub ingress and inspection: You need a shared Hub VNet pattern with centralized inbound control (NAT, allow-listing, inspection) for one or more spoke workloads.
Global entry point + edge WAF: You want a globally distributed frontend with WAF, bot/rate controls, and consistent L7 policy before traffic reaches your VNets.
Controlled origin exposure: You need to ensure only the edge service can reach your origin (firewall public IP), and all other inbound sources are blocked.

Key benefits (the “why”)

Layered security: WAF blocks common web attacks at the edge; the hub firewall enforces network-level allow lists and DNAT; App Gateway applies L7 routing to AKS.
Reduced public attack surface: Application Gateway and AKS remain private; only Azure Front Door and the firewall public IP are internet-facing.
Hub-spoke scalability: The hub pattern supports multiple spokes and consistent ingress controls across workloads.
Operational clarity: Clear separation of responsibilities (edge policy vs. network boundary vs. app routing) makes troubleshooting and governance easier.

When not to use this

Simple dev/test exposure: If you only need quick internet access, a public Application Gateway or public AKS ingress may be simpler and cheaper.
You require end-to-end TLS in this lab: This runbook is HTTP-only for learning; production designs should use HTTPS throughout.
You do not need hub centralization: If there is only one workload and no hub-spoke standardization requirement, the firewall hop may be unnecessary.

Prerequisites and assumptions

Series scope: Part 1 is HTTP-only to focus on routing and control points. Part 2 will cover HTTPS (end-to-end TLS) and the certificate/policy configuration typically required for production deployments.
Permissions: Ability to create VNets, peerings, Azure Firewall + policy, Application Gateway, AKS, and Private DNS (typically Contributor on the subscription/resource groups).
Networking: Hub-Spoke VNets with peering configured to allow forwarded traffic, plus name resolution via Private DNS.
Tools: Azure CLI, kubectl, and permission to enable the AKS AGIC addon.

Architecture Diagram

1. Architecture Components and Workflow

Workflow (end-to-end request path)
Client → Azure Front Door (WAF + TLS, public endpoint) → Azure Firewall public IP (Hub VNet; DNAT) → private Application Gateway (Spoke VNet; AGIC-managed) → AKS service/pods.

1.1 Network topology (Hub-Spoke)

Connectivity
Hub and Spoke VNets are connected via VNet peering with forwarded traffic allowed so Azure Front Door traffic can traverse Azure Firewall DNAT to the private Application Gateway, and Hub-based validation hosts can resolve private DNS and reach Spoke private IPs.

Hub VNet (10.0.0.0/16)
Purpose: Central ingress and shared services. The Hub hosts the security boundary (Azure Firewall) and optional connectivity/management components used to reach and validate private resources in the Spoke.

Azure Firewall in AzureFirewallSubnet (10.0.1.0/24); example private IP 10.0.1.4 with a Public IP used as the Azure Front Door origin and for inbound DNAT.
Azure Bastion (optional) in AzureBastionSubnet (10.0.2.0/26) for browser-based access to test VMs without public IPs.
Test VM subnet (optional) testvm-subnet (10.0.3.0/24) for in-VNet validation (for example, nslookup and curl against the private App Gateway hostname).

Spoke VNet (10.224.0.0/12)
Purpose: Hosts private application workloads (AKS) and the private layer-7 ingress (Application Gateway) that is managed by AGIC.

AKS subnet aks-subnet: 10.224.0.0/16 (node pool subnet for the AKS cluster).
Application Gateway subnet appgw-subnet: 10.238.0.0/24 (dedicated subnet for a private Application Gateway; example private frontend IP 10.238.0.10).
AKS + AGIC: AGIC programs listeners/rules on the private Application Gateway based on Kubernetes Ingress resources.

1.2 Azure Front Door (Frontend)

Role: Public entry point for the application, providing global anycast ingress, TLS termination, and Layer 7 routing to the origin (Azure Firewall public IP) while keeping Application Gateway private.

SKU: Use Azure Front Door Premium when you need WAF plus advanced security/traffic controls; Standard also supports WAF, but Premium is typically chosen for broader capabilities and enterprise patterns.
WAF support: Azure Front Door supports WAF with managed rule sets and custom rules (for example, allow/deny lists, geo-matching, header-based controls, and rate limiting policies).
What WAF brings: Adds edge protection against common web attacks (for example OWASP Top 10 patterns), reduces attack surface before traffic reaches the Hub, and centralizes L7 policy enforcement for all apps onboarded to Front Door.

Security note: Apply WAF policy at the edge (managed + custom rules) to block malicious requests early; origin access control is enforced at the Azure Firewall layer (see Section 1.3).

1.3 Azure Firewall Premium (Hub security boundary)

Role: Security boundary in the Hub that exposes a controlled public ingress point (Firewall Public IP) for Azure Front Door origins, then performs DNAT to the private Application Gateway in the Spoke.

Why Premium: Use Firewall Premium when you need advanced threat protection beyond basic L3/L4 controls, while keeping the origin private.
IDPS (intrusion detection and prevention): Premium can add signature-based detection and prevention to help identify and block known threats as traffic traverses the firewall.
TLS inspection (optional): Premium supports TLS inspection patterns so you can apply threat detection to encrypted flows when your compliance and certificate management model allows it.

Premium feature note (DNAT scenarios): These security features still apply when Azure Firewall is used for DNAT (public IP) scenarios. IDPS operates in all traffic directions; however, Azure Firewall does not perform TLS inspection on inbound internet traffic, so the effectiveness of IDPS for inbound encrypted flows is inherently limited. That said, Threat Intelligence enforcement still applies, so protection against known malicious IPs and domains remains in effect.

Hardening guidance: Enforce origin lockdown here by restricting the DNAT listener to AzureFrontDoor.Backend (typically via an IP Group) so only Front Door can reach the firewall public IP; use Front Door WAF as the complementary L7 control plane at the edge.

2. Build Steps (Command Runbook)

2.1 Set variables

$HUB_RG="HUB-VNET-Rgp"
$AKS_RG="AKS-VNET-RGp"
$LOCATION="eastus"

$HUB_VNET="Hub-VNet"
$SPOKE_VNET="Spoke-AKS-VNet"

$APPGW_NAME="spoke-appgw"
$APPGW_PRIVATE_IP="10.238.0.10"

Note: The commands below are formatted for PowerShell. When capturing output from an az command, use $VAR = (az ...).

2.2 Create resource groups

az group create --name $HUB_RG --location $LOCATION
az group create --name $AKS_RG --location $LOCATION

2.3 Create Hub VNet + AzureFirewallSubnet + Bastion subnet + VM subnet

# Create Hub VNet with AzureFirewallSubnet
az network vnet create -g $HUB_RG -n $HUB_VNET -l $LOCATION --address-prefixes 10.0.0.0/16 --subnet-name AzureFirewallSubnet --subnet-prefixes 10.0.1.0/24

# Create Azure Bastion subnet (optional)
az network vnet subnet create -g $HUB_RG --vnet-name $HUB_VNET -n "AzureBastionSubnet" --address-prefixes "10.0.2.0/26"

# Deploy Bastion (optional; requires AzureBastionSubnet)
az network public-ip create -g $HUB_RG -n "bastion-pip" --sku Standard --allocation-method Static
az network bastion create -g $HUB_RG -n "hub-bastion" --vnet-name $HUB_VNET --public-ip-address "bastion-pip" -l $LOCATION

# Create test VM subnet for validation
az network vnet subnet create -g $HUB_RG --vnet-name $HUB_VNET -n "testvm-subnet" --address-prefixes "10.0.3.0/24"

# Create a Windows test VM in the Hub (no public IP)
$VM_NAME = "win-testvm-hub"
$ADMIN_USER = "adminuser"
$ADMIN_PASS = ""
$NIC_NAME = "win-testvm-nic"

az network nic create --resource-group $HUB_RG --location $LOCATION --name $NIC_NAME --vnet-name $HUB_VNET --subnet "testvm-subnet"
az vm create --resource-group $HUB_RG --name $VM_NAME --location $LOCATION --nics $NIC_NAME --image MicrosoftWindowsServer:WindowsServer:2022-datacenter-azure-edition:latest --admin-username $ADMIN_USER --admin-password $ADMIN_PASS --size Standard_D2s_v5

2.4 Create Spoke VNet + AKS subnet + App Gateway subnet

# Create Spoke VNet
az network vnet create -g $AKS_RG -n $SPOKE_VNET -l $LOCATION --address-prefixes 10.224.0.0/12

# Create AKS subnet
az network vnet subnet create -g $AKS_RG --vnet-name $SPOKE_VNET -n aks-subnet --address-prefixes 10.224.0.0/16

# Create Application Gateway subnet
az network vnet subnet create -g $AKS_RG --vnet-name $SPOKE_VNET -n appgw-subnet --address-prefixes 10.238.0.0/24

2.5 Validate and delegate the App Gateway subnet (required)

# Validate subnet exists
az network vnet subnet show -g $AKS_RG --vnet-name $SPOKE_VNET -n appgw-subnet
az network vnet subnet show -g $AKS_RG --vnet-name $SPOKE_VNET -n appgw-subnet --query addressPrefix -o tsv

# Delegate subnet for Application Gateway (required)
az network vnet subnet update -g $AKS_RG --vnet-name $SPOKE_VNET -n appgw-subnet --delegations Microsoft.Network/applicationGateways

2.6 Create the private Application Gateway

az network application-gateway create -g $AKS_RG -n $APPGW_NAME --sku Standard_v2 --capacity 2 --vnet-name $SPOKE_VNET --subnet appgw-subnet --frontend-port 80 --http-settings-protocol Http --http-settings-port 80 --routing-rule-type Basic --priority 100 --private-ip-address $APPGW_PRIVATE_IP

2.7 Create AKS (public, Azure CNI overlay)

$AKS_SUBNET_ID = (az network vnet subnet show -g $AKS_RG --vnet-name $SPOKE_VNET -n aks-subnet --query id -o tsv)
$AKS_NAME = "aks-public-overlay"

az aks create -g $AKS_RG -n $AKS_NAME -l $LOCATION --enable-managed-identity --network-plugin azure --network-plugin-mode overlay --vnet-subnet-id $AKS_SUBNET_ID --node-count 2 --node-vm-size Standard_DS3_v2 --dns-name-prefix aks-overlay --generate-ssh-keys

2.8 Enable AGIC and attach the existing Application Gateway

$APPGW_ID = (az network application-gateway show -g $AKS_RG -n $APPGW_NAME --query id -o tsv)
az aks enable-addons -g $AKS_RG -n $AKS_NAME --addons ingress-appgw --appgw-id $APPGW_ID

2.9 Connect to the cluster and validate AGIC

az aks get-credentials -g $AKS_RG -n $AKS_NAME --overwrite-existing
kubectl get nodes

# Validate AGIC is running
kubectl get pods -n kube-system | findstr ingress

# Inspect AGIC logs (optional)
$AGIC_POD = (kubectl get pod -n kube-system -l app=ingress-appgw -o jsonpath="{.items[0].metadata.name}")
kubectl logs -n kube-system $AGIC_POD

2.10 Create and link Private DNS zone (Hub) and add an A record

Create a Private DNS zone in the Hub, link it to both VNets, then create an A record for app1 pointing to the private Application Gateway IP.

$PRIVATE_ZONE = "clusterksk.com"

az network private-dns zone create -g $HUB_RG -n $PRIVATE_ZONE

$HUB_VNET_ID = (az network vnet show -g $HUB_RG -n $HUB_VNET --query id -o tsv)
$SPOKE_VNET_ID = (az network vnet show -g $AKS_RG -n $SPOKE_VNET --query id -o tsv)

az network private-dns link vnet create -g $HUB_RG -n "link-hub-vnet" -z $PRIVATE_ZONE -v $HUB_VNET_ID -e false
az network private-dns link vnet create -g $HUB_RG -n "link-spoke-aks-vnet" -z $PRIVATE_ZONE -v $SPOKE_VNET_ID -e false

az network private-dns record-set a create -g $HUB_RG -z $PRIVATE_ZONE -n "app1" --ttl 30
az network private-dns record-set a add-record -g $HUB_RG -z $PRIVATE_ZONE -n "app1" -a $APPGW_PRIVATE_IP

2.11 Create VNet peering (Hub Spoke)

az network vnet peering create -g $HUB_RG --vnet-name $HUB_VNET -n "HubToSpoke" --remote-vnet $SPOKE_VNET_ID --allow-vnet-access --allow-forwarded-traffic
az network vnet peering create -g $AKS_RG --vnet-name $SPOKE_VNET -n "SpokeToHub" --remote-vnet $HUB_VNET_ID --allow-vnet-access --allow-forwarded-traffic

2.12 Deploy sample app + Ingress and validate App Gateway programming

# Create namespace
kubectl create namespace demo

# Create Deployment + Service (PowerShell)

@' apiVersion: apps/v1 kind: Deployment metadata: name: app1 namespace: demo spec: replicas: 2 selector: matchLabels: app: app1 template: metadata: labels: app: app1 spec: containers: - name: app1 image: hashicorp/http-echo:1.0 args: - "-text=Hello from app1 via AGIC" ports: - containerPort: 5678 --- apiVersion: v1 kind: Service metadata: name: app1-svc namespace: demo spec: selector: app: app1 ports: - port: 80 targetPort: 5678 type: ClusterIP '@ | Set-Content .\app1.yaml

kubectl apply -f .\app1.yaml

# Create Ingress (PowerShell)
@' apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: app1-ing namespace: demo annotations: kubernetes.io/ingress.class: azure/application-gateway appgw.ingress.kubernetes.io/use-private-ip: "true" spec: rules: - host: app1.clusterksk.com http: paths: - path: / pathType: Prefix backend: service: name: app1-svc port: number: 80 '@ | Set-Content .\app1-ingress.yaml

kubectl apply -f .\app1-ingress.yaml

# Validate Kubernetes objects
kubectl -n demo get deploy,svc,ingress
kubectl -n demo describe ingress app1-ing

# Validate App Gateway has been programmed by AGIC
az network application-gateway show -g $AKS_RG -n $APPGW_NAME --query "{frontendIPConfigs:frontendIPConfigurations[].name,listeners:httpListeners[].name,rules:requestRoutingRules[].name,backendPools:backendAddressPools[].name}" -o json

# If rules/listeners are missing, re-check AGIC logs from step 2.9
kubectl logs -n kube-system $AGIC_POD

2.13 Deploy Azure Firewall Premium + policy + public IP

Firewall deployment (run after sample Ingress is created)

$FWPOL_NAME = "hub-azfw-pol-test"
$FW_NAME = "hub-azfw-test"
$FW_PIP_NAME = "hub-azfw-pip"
$FW_IPCONF_NAME = "azfw-ipconf"

# Create Firewall Policy (Premium)
az network firewall policy create -g $HUB_RG -n $FWPOL_NAME -l $LOCATION --sku Premium

# Create Firewall public IP (Standard)
az network public-ip create -g $HUB_RG -n $FW_PIP_NAME -l $LOCATION --sku Standard --allocation-method Static

# Deploy Azure Firewall in Hub VNet and associate policy + public IP
az network firewall create -g $HUB_RG -n $FW_NAME -l $LOCATION --sku AZFW_VNet --tier Premium --vnet-name $HUB_VNET --conf-name $FW_IPCONF_NAME --public-ip $FW_PIP_NAME --firewall-policy $FWPOL_NAME

$FW_PUBLIC_IP = (az network public-ip show -g $HUB_RG -n $FW_PIP_NAME --query ipAddress -o tsv)
$FW_PUBLIC_IP

2.14 (Optional) Validate from Hub test VM

Optional: From the Hub Windows test VM (created in step 2.3), confirm app1.clusterksk.com resolves privately and the app responds through the private Application Gateway.

# DNS should resolve to the private App Gateway IP
nslookup app1.clusterksk.com

# HTTP request should return the sample response (for example: "Hello from app1 via AGIC")
curl http://app1.clusterksk.com

# Browser validation (from the VM)
# Open: http://app1.clusterksk.com

2.15 Restrict DNAT to Azure Front Door (IP Group + DNAT rule)

$IPG_NAME = "ipg-afd-backend"
$RCG_NAME = "rcg-dnat"
$NATCOLL_NAME = "dnat-afd-to-appgw"
$NATRULE_NAME = "afd80-to-appgw80"

# 1) Get AzureFrontDoor.Backend IPv4 prefixes and create an IP Group
$AFD_BACKEND_IPV4 = (az network list-service-tags --location $LOCATION --query "values[?name=='AzureFrontDoor.Backend'].properties.addressPrefixes[] | [?contains(@, '.')]" -o tsv)
az network ip-group create -g $HUB_RG -n $IPG_NAME -l $LOCATION --ip-addresses $AFD_BACKEND_IPV4

# 2) Create a rule collection group for DNAT
az network firewall policy rule-collection-group create -g $HUB_RG --policy-name $FWPOL_NAME -n $RCG_NAME --priority 100

# 3) Add NAT collection + DNAT rule (source = AFD IP Group, destination = Firewall public IP, 80 → 80)
az network firewall policy rule-collection-group collection add-nat-collection -g $HUB_RG --policy-name $FWPOL_NAME --rule-collection-group-name $RCG_NAME --name $NATCOLL_NAME --collection-priority 1000 --action DNAT --rule-name $NATRULE_NAME --ip-protocols TCP --source-ip-groups $IPG_NAME --destination-addresses $FW_PUBLIC_IP --destination-ports 80 --translated-address $APPGW_PRIVATE_IP --translated-port 80

3. Azure Front Door Configuration

In this section, we configure Azure Front Door Premium as the public frontend with WAF, create an endpoint, and route requests over HTTP (port 80) to the Azure Firewall public IP origin while preserving the host header (app1.clusterksk.com) for AGIC-based Ingress routing.

Create Front Door profile: Create an Azure Front Door profile and choose Premium. Premium enables enterprise-grade edge features (including WAF and richer traffic/security controls) that you’ll use in this lab.

Attach WAF: Enable/associate a WAF policy so requests are inspected at the edge (managed rules + any custom rules) before they’re allowed to reach the Azure Firewall origin.
Create an endpoint: Add an endpoint name to create the public Front Door hostname (<endpoint>.azurefd.net) that clients will browse to in this lab.
Create an origin group: Create an origin group to define how Front Door health-probes and load-balances traffic to one or more origins (for this lab, it will contain a single origin: the Firewall public IP).
Add an origin: Add the Azure Firewall as the origin so Front Door forwards requests to the Hub entry point (Firewall Public IP), which then DNATs to the private Application Gateway.

Origin type: Public IP address
Public IP address: select the Azure Firewall public IP
Origin protocol/port: HTTP, 80
Host header: app1.clusterksk.com

Create a route: Create a route to connect the endpoint to the origin group and define the HTTP behaviors (patterns, accepted protocols, and forwarding protocol) used for this lab.

Patterns to match: /*
Accepted protocols: HTTP
Forwarding protocol: HTTP only (this lab is HTTP-only)
Then you need to add the Route

Review + create, then wait for propagation: Select Review + create (or Create) to deploy the Front Door configuration, wait ~30–40 minutes for global propagation, then browse to http://<endpoint>.azurefd.net/.

4. Validation (Done Criteria)

app1.clusterksk.com resolves to 10.238.0.10 from within the Hub/Spoke VNets (Private DNS link working).
Azure Front Door can reach the origin over HTTP and returns a 200/expected response (origin health is healthy).
Requests to http://app1.clusterksk.com/ (internal) and http://<your-front-door-domain>/ (external) are routed to app1-svc and return the expected http-echo text (Ingress + AGIC wiring correct).

Author: Kumar shashi kaushal (Sr Digital cloud solutions architect Microsoft)

rss.livelink.threads-in-node

I don't want to pay extra for copilot

When the audio pipeline decides to act up 😂🤌

Vector Drift in Azure AI Search: Three Hidden Reasons Your RAG Accuracy Degrades After Deployment

What Is Vector Drift?

Cause 1: Embedding Model Version Mismatch

Cause 2: Incremental Content Updates Without Re-Embedding

Cause 3: Inconsistent Chunking Strategies

Design Principles

Key Takeaways

Conclusion

Further Reading

Entra CBA Preview Bug: Issuer Scoping Policy fails group claim (AADSTS500191)

How to Secure Your Windows 11 PC (Complete Guide)

Windows 11 What is this logo used for？

Windows 11 Keeps Prompting GPU Driver Installation on Every Restart

Windows 11 Screen automatically turns warm without night mode

How XLOOKUP arguments apply in this case

Not understanding XLOOKUP arguments as they apply here

April 2026 MSLE Newsletter available now!

Expanding Azure Arc SQL Migration with a New Target: SQL Server on Azure Virtual Machines

Expanding Choice Without Adding Complexity

One Integrated Migration Journey

A Consistent Experience Across Migration Targets

Backup Log Shipping Migration to SQL Server in Azure VM

Controlled Cutover on Your Terms

Getting started

Windows news you can use: March 2026

New in Windows update and device management

New in Windows security

New in AI

New in Windows Server

New in productivity and collaboration

Lifecycle reminders

Additional resources

Join the conversation

#IntuneForMSPs Meetup - June 2026

How do I participate?

Stay informed, stay connected

From box to business‑ready with Windows Autopilot - #IntuneForMSPs Meetup

How do I participate?

Stay informed, stay connected

#IntuneForMSPs Meetup - May 2026

How do I participate?

Stay informed, stay connected

Introducing TSGen: Automated TSG Generation @ Scale – Built by AI

The Challenge: Why Manual Troubleshooting Guides Fall Short

The Solution: Automating Troubleshooting Guide creation with AI

TSGen's Five-Step Automated Workflow

From Manual to Automated: Real-World Impact

Industry-Wide Implications for Cloud Operations

Key Benefits of Automated TSG Generation

How We Built This Iteration

Learnings and Recommendations from Building with AI

Looking Forward: The Future of Intelligent Incident Management

Further Reading

Removing Old MS 365 Account

Run the latest Azure Arc agent with Automatic Agent Upgrade (Public Preview)

What is Automatic Agent Upgrade?

Getting Started

Apply automatic agent upgrade policy

Apply automatic agent upgrade CLI Flag

Secure HTTP‑Only AKS Ingress with Azure Front Door Premium, Firewall DNAT, and Private AGIC

0. When and Why to Use This Architecture

1. Architecture Components and Workflow

1.1 Network topology (Hub-Spoke)

1.2 Azure Front Door (Frontend)

1.3 Azure Firewall Premium (Hub security boundary)

2. Build Steps (Command Runbook)

2.1 Set variables

2.2 Create resource groups

2.3 Create Hub VNet + AzureFirewallSubnet + Bastion subnet + VM subnet

2.4 Create Spoke VNet + AKS subnet + App Gateway subnet

2.5 Validate and delegate the App Gateway subnet (required)

2.6 Create the private Application Gateway

2.7 Create AKS (public, Azure CNI overlay)

2.8 Enable AGIC and attach the existing Application Gateway

2.9 Connect to the cluster and validate AGIC

2.10 Create and link Private DNS zone (Hub) and add an A record

2.11 Create VNet peering (Hub ­ Spoke)

2.11 Create VNet peering (Hub Spoke)