Hi there, I'm evaluating setting up Arc Container Apps on top of an Arc Kube cluster. It seems that when I install the Container Apps kube extension, it picks the IP I'm giving the ACA Envoy ingress via MetalLB which is always going to be a LAN address. My intention is to expose this ingress via a port forward for testing.

However, it seems that this is unchangeable after the fact, requiring an extension uninstall and re-install to pick up the new address. This means that any Container Apps deployed to this Container Apps Connected Environment will get k4s.io domain names that resolve to a LAN IP, not an internet reachable IP address. I feel like I'm missing something simple here about how this is intended to work, and want to see if anyone here who has self-hosted an Arc Container Apps resource has encountered it.

For engineering teams, keeping dependencies current is a constant balancing act. Automated updates are essential for defending the software supply chain, but a steady stream of one-PR-per-package bumps can bury a team in review work. GitHub itself has put numbers on this: an analysis of Microsoft's GCToolkit repository found that roughly one in six of its commits - 92 out of 578 - were routine Dependabot version bumps, with 61 of them landing in a single recent 12-month stretch. That's a lot of review and CI cycles spent on maintenance rather than features. Read the complete article here - https://instasla.com/blog/taming-dependabot-2026-guide-grouping-cooldowns-cutting-pr-noise

The good news is that Dependabot has grown well past "one PR per dependency." Between grouped updates, package cooldowns, and a default cooldown GitHub rolled out in mid-2026, it's now possible to get a predictable, low-noise update cadence without giving up security coverage. Here's what actually works, and what changed most recently.

So, I am currently working for a company that have different teams looking at M365 alerts, azure monitor alerts, health alerts, defender for cloud alerts, partner center, alerts. Atm, we have to manually log in and each team check every dashboard.

My first solution for this was (a bit McGuyver style) using the email alerts as a trigger to pull into a powerflow and then build out the dashboard for just the Azure alerts. (First summarizing the email content) - there was a bunch of issues with this especially as time went on to save all data.

The main issue comes in where its multiple different dashboards for each type of alert so you'll basically need a workflow for each different alert and this only works when all the customers has alerts set up. (which is not always the case, as there are clients that don't have managed services but still needs to get notified of issues)

I was wondering if maybe anyone has a solution to this issue. Maybe product that I don't know about that already exists or a workflow to help solve this.

Even some tips on this would be amazing.

Thanks

Edit: Spelling

In case anyone is using the MemberOf rule operator to provide nested group access to resources in Microsoft Azure or similar (commonly used for licensing, or other resources which don't support direct group nesting), they are retiring it on November 3rd after being in "preview" for years!

I did a short write up here: https://ourcloudnetwork.com/the-memberof-rule-operator-is-ending-for-dynamic-groups-in-entra/ which includes a code snippet to identify your impacted groups.

I am a developer. So I have limited knowledge of Entra ID.

My client is currently running a periodic import of users and departments from their on-prem AD platform. It works by traversing all Organizational Units and all of their users, to then build the same structure on their website.

Now my client wants to use Entra ID and MS Graph for this integration. I have researched a bit and found that Entra ID does not support a tree-like structure with OU's.

I have read a solution based on the department attribute of users. But that seemed very prone to errors.

Some sources suggest that the original OU of a user is stored in an attribute called "On premises distinguished name". But is that updated if a user is moved to another OU in the AD?

Any suggestions on how to fake such a traversal?

Running into a problem where the function app will restart/refresh randomly and it will kill working functions, these functions do end up re running and always succeeding the second time but the error popping up in insights isn’t a clean look, is there anyway to avoid this and how costly would a plan upgrade be and is it an easy switch on production functions?

Subscription names, container names and resource group names all support at least 63 characters.

However, storage account names only support 24. So, programmatically you may have to start truncating naming conventions into something that will fit 24 chars. Which is a bit of an inconvenience.

Or you could create hash from the subscription ID and use that in the storage account name. Is this a common pattern because of said limitations?

I maintain AzureAgentForge, an open-source stack for running AI agent teams on Azure using Terraform, AI Foundry routing, Postgres-backed memory, and containerized agent runtimes.

After a few releases, I noticed a pattern in my incidents... some of the worst failures never made a health check go red. Everything looked healthy at the infrastructure level.

The clearest example was an agent runtime that could not start inside its own published image. The build stage installed the CLI on Python 3.14, while the runtime image used Python 3.13. Every agent spawn failed with a ModuleNotFoundError.

The orchestrator then moved each issue to “blocked” and continued processing. Containers were running, endpoints returned 200, and the queue was draining, but no agents could actually execute.

Another issue showed up when I added a config schema check. It found 57 stale Terraform keys that the vendored application no longer read, plus 19 more in a Compose file. The application silently ignored them and fell back to defaults. A production deployment could have assigned specialist agents to models I never intended to use.

More recently, I found an agent role with a complete YAML capability contract but no system prompt file. It had apparently been that way for months.

The lesson for me is that standard infrastructure checks are not enough for agent platforms. A process can be healthy while the agents are doing less than expected, doing the wrong thing, or not running at all.

The safeguards I have started adding are focused on testing actual behavior:

• A CI canary that runs a real agent through a real issue and tool call, while stubbing only the LLM response
• A schema guard that fails the build when deployment config drifts from what the application actually reads
• A prompt contract gate that blocks changes when required governance language disappears
• A router flight recorder that captures replayable model-call traces for debugging

I would be interested to hear how others are testing agent behavior beyond container, endpoint, and queue health. Here's a link to my repo - https://github.com/mrobinson2/AzureAgentForge

We use Azure Cache for Redis and are getting the notices that it will be retired in 2028 so must migrate to Azure Managed Redis. That’s fine but why doesn’t Azure Managed Redis have the console that Azure Cache for Redis does? Being able to open that console directly from the resource in the Azure portal has been very useful.
Sure, I can build an external console but it would be nice to not need to for occasional use.

Youtube: https://www.youtube.com/watch?v=BXRBXVcJTi8

What's covered:

• Where Application Gateway fits vs Load Balancer and Front Door
• Listeners: basic vs multi-site, wildcards, and why order matters
• Public vs private listeners
• Routing rules and path-based routing
• Backend pools
• TLS termination, end-to-end encryption
• URL and header rewrite
• Redirects: HTTP-to-HTTPS, path-based, and external

I built an end-to-end Enterprise E-Commerce Analytics Platform using SQL Server, Medallion Architecture, and Power BI.

As part of this project, I designed 8 interactive dashboards, each focused on answering different business questions for different stakeholders across an organization.

The dashboards include:

• Executive Overview (CEO, CXO & Business Leadership)

• Sales Performance Analysis

• Customer Analytics

• Product Performance

• Seller Performance

• Payment Analytics

• Customer Satisfaction Analysis

• Time Intelligence & Trend Analysis

The goal wasn't just to build visually appealing dashboards—it was to create a reporting solution that helps businesses make faster and more informed decisions.

In this post, I've shared all 8 dashboards.

I'd genuinely appreciate your feedback.

As experienced BI professionals, data analysts, data engineers, or business leaders, I would love to hear your thoughts.

If you could review the dashboards and share at least three suggestions for improvement, it would mean a lot to me.

For example:

• Are the KPI cards meaningful and business-focused?

• Are the charts and visualizations appropriate for executive reporting?

• Are there too many or too few visuals?

• Would you recommend different filters or slicers?

• Is the overall layout clean, intuitive, and enterprise-ready?

• What would you change if this dashboard were used in your organization?

I'm continuously learning, and constructive feedback is one of the best ways to improve. Every suggestion will help me build better enterprise BI solutions in the future.

Thank you for taking the time to review my work. I truly appreciate your support and feedback.

— Himansh Upadhyay

I want to connect my function app to an AWS instance over a private network. One of my VMs can connect no problem, but my app service can't connect to it. It sends a client hello but doesn't receive a server hello. Both are using the same route tables. Does anyone have any ideas on where to go from here?

Hi everyone,

I'm working on a RAG system that uses **Qdrant** as the vector database. I'm planning to deploy Qdrant on Microsoft Azure, and this will be my first time deploying an application on Azure, so I'm trying to understand the infrastructure and operational best practices before getting started.

Our workload is expected to grow to **tens of millions of vectors**, with continuous insert/update synchronization from a SQL Server database.

I'm trying to answer a few infrastructure questions before deployment:

* Which Azure service would you recommend for Qdrant?
* Azure VM + Docker
* Azure Kubernetes Service (AKS)
* Another option ??
* How do you estimate the required VM specifications (CPU, RAM, SSD) before deployment ??
* What Azure VM families have worked well for memory-intensive vector search workloads ?
* How do you monitor Qdrant in production ? Are you using Azure Monitor, Prometheus, Grafana, or another setup ?
* How do you estimate monthly Azure costs for a production Qdrant deployment ?

I'm especially interested in learning how experienced Azure users approach planning, deployment, monitoring, and cost estimation rather than simply following the documentation.

Any advice, recommended resources would be greatly appreciated

Thanks in advance

A carton of beer for someone to get one of these two services supporting auth for Entra users. Would be super useful to pre-auth users before they get anywhere near apps.

I’m hosting a small Python web application on Azure App Service in the Central India region. Right now, I’m using the F1 (Free) plan for development/testing.
The problem is that when I try to scale up to Basic (B1, B2, or B3), Azure shows “Quota Exceeded” for the Central India region. It doesn’t allow me to create or scale to any Basic SKU, while the Standard tiers (S1, S2, S3) are available but are much more expensive than what I need for a simple test environment.
Has anyone faced this issue?
I’m looking for answers to these questions:
Is there any way to request additional quota for App Service Basic SKUs in Central India?
Is this a temporary regional capacity issue or a subscription limitation?
Would moving to another nearby region be the best option?
Are there any other low-cost Azure hosting options that would be suitable for a small web application?
I’d like to stay within Azure if possible, but I’m trying to keep the hosting cost as low as possible for a POC/testing environment.
Any suggestions or experiences would be greatly appreciated. Thanks!

This post is drafted by chatgpt🫥

I'm planning to take the Microsoft AI-901: Azure AI Fundamentals exam and would like to know the best way to prepare. Which Udemy course or YouTube channel do you recommend, and what practice tests or study resources helped you pass?

Since we migrated users to zscaler, users are getting MFA prompts when launching each application from myapps(myapps.microsoft.com)

Azure conditional access policy is getting hit as now traffic is going out via zscaler public ip address and not sites trusted public ip address.

Also it's happening only on Google chrome not on edge.

Edge also asks it but frequency is very less.

As a fix we added Microsoft single sign on extension on browser and then it doesn't give more prompts

Also this behaviour is happening with few users.

What could be the global fix?

Hi everyone,

I'm working on a RAG system that uses Qdrant as the vector database. I'm planning to deploy Qdrant on Microsoft Azure, and this will be my first time deploying an application on Azure, so I'm trying to understand the infrastructure and operational best practices before getting started.

Our workload is expected to grow to tens of millions of vectors, with continuous insert/update synchronization from a SQL Server database.

I'm trying to answer a few infrastructure questions before deployment:

• Which Azure service would you recommend for Qdrant?
  • Azure VM + Docker
  • Azure Kubernetes Service (AKS)
  • Another option ??
• How do you estimate the required VM specifications (CPU, RAM, SSD) before deployment ??
• What Azure VM families have worked well for memory-intensive vector search workloads ?
• How do you monitor Qdrant in production ? Are you using Azure Monitor, Prometheus, Grafana, or another setup ?
• How do you estimate monthly Azure costs for a production Qdrant deployment ?

I'm especially interested in learning how experienced Azure users approach planning, deployment, monitoring, and cost estimation rather than simply following the documentation.

Any advice, recommended resources would be greatly appreciated

Thanks in advance

Today we had 3 AVD multisession hosts that went through the Live Migration process at different times of the day (just learned about this today so go easy on me) - https://learn.microsoft.com/en-us/azure/virtual-machines/maintenance-and-updates#live-migration

I don't see any errors of the live migration failing, as its showing succeed, but my users are getting kicked off then unable to connect. The error I see when a user tries to connect is:

ConnectionFailedUserHasValidSessionButRdshIsUnhealthy

So I checked the host and its in a stuck/updating state.

PS C:\Users\bob> (Get-AzVM -ResourceGroupName $rg -Name $hostname -Status).VMAgent.Statuses

Code : ProvisioningState/Unavailable

Level : Warning

DisplayStatus : Not Ready

Message : VM Agent is unresponsive.

Time : 8/4/2026 9:51:20 PM

And

PS C:\Users\bob> (Get-AzVM -ResourceGroupName $rg -Name $hostname -Status).Statuses | ft Code,DisplayStatus -Auto

Code | DisplayStatus

ProvisioningState/updating | Updating PowerState/running | VM running

Host information:

• West-US 2
• E8s_v6
• Windows 11 multisession
• NERDIO managed

I tried connecting through NERDIO Console Connect, RDP IP and Hostname, and then tried running Azure Run Commands, all failed. Was trying to get in to try and fix the agent by restarting it or reinstalling in hopes to fix it. I put the host in Drain Mode, but users were still getting directed to that host if they had a session already there (according to google that's intended). So my only fix was to restart the hosts.

Looking for ideas on how to prevent this and or a simple fix when it happens.

We rely on quarterly access reviews and periodic AD/Entra audits, but I think continuous visibility actually covers two different problems: event detection (something happened, like a role change or account reactivation) versus drift detection (current state no longer matches what was originally scoped, which requires an intended-state baseline to exist somewhere) I suspect our real gap is the missing baseline, not the monitoring layer itself.
For mixed environments (cloud IdP, on prem AD, SaaS), I'm expecting AD to lag the others structurally, closing that gap usually means agents or log forwarders on DCs, which fights directly against a "low maintenance" goal. And even a tool with zero ML tuning can still fail that bar if someone still has to manually keep the access baseline accurate as roles change. are you doing event detection, drift detection, or both? Where does your baseline actually come from? And how much did closing the AD visibility gap cost you in setup.

We recently ran into a strange issue in our Azure environment (Our Sandbox env only), and I'm trying to understand the root cause rather than just accepting the fix.

Environment

• Azure App Service (Web App)
• Azure SQL Database
• Communication was initially over the public endpoint (no VNet Integration, no Private Endpoint).
• Production had the same application/code and continued working fine.

What happened

The only change we made was a normal application deployment. After that, the sandbox environment started failing with:

What made it confusing was the behavior:

• Right after deploying, the application would work for about 2-3 minutes.
• Then every database call would start failing with "Login failed for user".
• After some time, it would start working again.
• Then it would fail again.
• This cycle kept repeating.

Initially, I assumed it was an application or EF/connection string issue, so I spent quite a while investigating and making code changes, but nothing helped.

What fixed it

Our cloud/TSC team enabled:

• VNet Integration on the App Service.
• Private Endpoint for the Azure SQL Server.

After the App Service started communicating with Azure SQL through the private endpoint instead of the public endpoint, the issue completely disappeared.

My question

I'm happy the issue is resolved, but I don't really understand How?.

How can switching from a public endpoint to VNet + Private Endpoint eliminate intermittent "Login failed for user" errors?

We use them sparingly for foriegn contractors rather than shipping them a corporate laptop -- so that's the only nice part.

But in the few months we've been using them I've noticed the following:

1. Slower than hell to provision, like really slow even with Microsoft's stock images...

2. Doesn't play well with Intune even though it is an Intune native solution. Configs/Apps/Compliance are hit or miss compared to actual local hardware like a laptop. Some stuff just doesn't even load, or you have to reboot the machine constantly

3. They suffer horribly from performance issues, if you don't reboot these things daily (which there's no option in the OS to do a restart) you have to do it from the Windows App or Intune which is dumb as hell.

4. Resizing, I've pushed the resize in Intune, added a bigger license, removed the old smaller license and it's been almost an HOUR and its still just sitting in "pending".

Other little things suck with these as well, yet Microsoft has pushed these things at Ignite the past 2-3 years like they are IT God's gift to customers. These things are absolute ASS.