rss.livelink.threads-in-node

Windows 11 forces PIN validation on boot for Edge, Teams and Phone Link

Yagamikun — Mon, 12 Oct 2026 20:05:24 GMT

Hello. I am facing a persistent issue in Windows 11 where Microsoft Edge (running multiple windows and dozens of open tabs that I must keep active), Teams, and the Phone Link app demand PIN validation (Windows Hello) via toolbar prompts or "Your account requires attention" notifications upon every system startup. OneDrive is the only app that does not experience this issue.

I want to make it absolutely clear that I DO NOT want to disable any convenience features (automatic reopening of apps on boot and Edge startup boost are enabled by necessity), I DO NOT want to switch to a local account (I strictly need settings synchronization active between my other Windows 11 devices), and I DO NOT clear cookies on close.

To save time and avoid repetitive, generic troubleshooting steps, please note that I have already performed advanced troubleshooting procedures. I have disabled the Windows Hello requirement in settings, cleared credentials in Credential Manager, reset the Ngc security cache folder via terminal, applied local Group Policies for Edge, and even implemented a registry startup queue delay to prevent overcrowded login requests before the internet connection stabilizes.

The issue gets temporarily fixed for 2 or 3 startups after applying these fixes, but Windows automatically overwrites or ignores these directives and goes back to demanding the PIN to revalidate the Single Sign-On (SSO) token of my personal Hotmail email across native background apps.

There is clearly a hidden system maintenance scheduled task or a Cloud Identity Service component forcing this strict re-authentication cyclically, overriding user preferences. How can I stop Windows Hello from interfering with the automatic, silent login of these specific apps without breaking my device synchronization settings?

Call for perspectives: Endpoint Management Experiences of IT Professionals Survey

Yiyi_Cui — Mon, 12 Oct 2026 20:05:16 GMT

Hi Endpoint management community, we’d love to hear from you!
How do you manage employee devices today? Where do you turn for guidance and support? And how are you thinking about AI-enabled ways of working?
🔗 Share your perspective in our 15-minute survey: https://lnkd.in/gmjkFx8P

We’re especially interested in hearing from people in their first five years in the field, but all experience levels are welcome.
If someone in your network comes to mind who has relevant experience, feel free to pass the survey along!

Call for perspectives: Endpoint Management Experiences of IT Professionals Survey

Yiyi_Cui — Mon, 12 Oct 2026 20:01:30 GMT

The New Microsoft Copilot:

NicholasAquino — Mon, 12 Oct 2026 19:47:32 GMT

The way we work with AI is evolving quickly.

Microsoft recently introduced the new Microsoft Copilot experience, bringing together new ways to ask, delegate, build and automate work while giving organizations additional controls for managing AI usage and spend.

In our recent webinar, “New Microsoft Copilot App: Which Mode to Use, What It Costs, and Who Gets Access,” we took a closer look at what these changes mean for organizations and the people using Copilot every day.

Rather than trying to recreate the entire session here, this post highlights some of the major topics we covered. For the demonstrations, examples and deeper discussion, watch the accompanying webinar recording.

What we covered

The session focused on four major areas:

The evolution of the Microsoft Copilot experience
The roles of Home, Code and Autopilot
Microsoft Copilot Managed Runtime and enterprise governance
Usage-based AI and the emerging discipline of FinOps for AI

Together, these capabilities point toward a Copilot experience that extends beyond conversational assistance and toward increasingly sophisticated AI-enabled work.

A new Microsoft Copilot experience

Microsoft has announced three major capabilities for the new Copilot experience: Home, Code and Autopilot.

Home brings Chat and Cowork together as a starting point for work. Microsoft is also bringing Word, Excel and PowerPoint capabilities into the Copilot experience, making it possible to create and continue working with Office content without continually rebuilding context across applications.

There is an important distinction between Chat and Cowork.

Chat addresses the conversational interactions many people already associate with Copilot: asking questions, looking up information, creating drafts and staying informed.

Cowork is designed for work you delegate. Rather than simply responding to an individual prompt, Cowork can work through more complex tasks end-to-end and return results for you to review and iterate upon.

Microsoft has also said that the experience is moving toward a point where users won't necessarily need to decide which mode to choose. Users will describe what they want to accomplish and Copilot can route the work to the appropriate capability.

That reflects an important change in how we should think about AI at work. The conversation is expanding from “What can I ask Copilot?” toward “What work can I accomplish with Copilot?”

Code: turning ideas into working solutions

One of the capabilities we spent time discussing and demonstrating during the webinar was Code.

Code is designed to enable people to build solutions by describing what they want to create. Microsoft says the capability is powered by the same underlying technology as GitHub Copilot and is intended to make software creation accessible to both experienced developers and people who may not consider themselves traditional programmers.

During the webinar, we explored this concept through an application-building example based on a requirements document.

The point wasn't that application development suddenly requires no planning or technical discipline. It was to demonstrate how dramatically the starting point can change when AI can help translate business requirements into working software.

Watch the webinar recording to see the example and the resulting application.

Where does AI-generated code actually run?

Making application creation easier immediately raises another question:

How does an organization govern all of those applications?

Microsoft Copilot Managed Runtime is designed to address that challenge.

Microsoft describes Managed Runtime as an enterprise-grade platform for running code within the Microsoft 365 tenant boundary. It provides a common foundation incorporating Microsoft-operated cloud hosting, identity, governed data access and lifecycle management.

Managed Runtime already supports apps created through Copilot Cowork, Copilot Code and Microsoft Copilot Studio.

This creates an important separation between two ideas:

AI makes building easier. Enterprise controls still matter when that software runs.

Microsoft operates the platform, while organizations retain control over the boundaries within which applications operate.

Autopilot: AI that continues working

The webinar also explored Autopilot, which Microsoft describes as a persistent, proactive and personal agent that can continue working even when the user isn't actively interacting with it.

This represents another shift in the AI experience.

Chat is naturally interactive. You ask something and Copilot responds.

Agentic experiences introduce the idea of delegating work that can continue beyond that individual interaction. That opens new possibilities for ongoing research, monitoring, preparation and other work that benefits from persistence.

In the webinar, we discussed what this transition could mean for people who increasingly treat AI not simply as a place to ask questions, but as another resource available to help them get work done.

As AI becomes more capable, cost management matters too

More capable AI workloads can also require different approaches to licensing and consumption.

Microsoft uses Copilot Credits as a common currency for eligible services using usage-based billing. Microsoft describes this consumption model as complementary to fixed subscription licensing, especially as more advanced or multi-step workloads can vary considerably in the amount of work required to complete a task.

That leads directly to another major subject from our webinar: FinOps for AI.

As organizations expand their use of AI, several questions become increasingly important:

What are we consuming?
Which services and scenarios are driving that consumption?
What value are those scenarios creating?
Where should we invest or optimize next?

Control, measure and optimize

A useful way to think about FinOps for AI is through three activities:

Control

Organizations need mechanisms for governing access and spend.

Microsoft's Cost Management capabilities support controls around usage-based AI experiences, including spending policies, limits, alerts and billing methods.

Organizations can therefore begin establishing guardrails around how consumption-based AI services are introduced.

Measure

You can't optimize what you can't see.

Microsoft provides consumption information through its Copilot Cost Management capabilities, giving administrators visibility into Copilot Credit consumption across supported services.

This moves the AI cost conversation beyond simply purchasing technology and toward understanding how it is actually being consumed.

Optimize

Once organizations understand consumption, they can make more deliberate decisions about where AI is producing meaningful value and where different approaches may be appropriate.

That makes FinOps for AI more than a billing conversation. It becomes part of the broader process of deciding where and how an organization wants to scale AI.

A useful way to think about what comes next

Perhaps the biggest takeaway from the webinar is that Microsoft Copilot is expanding beyond a single conversational interaction model.

The emerging experience spans several ways of working:

Ask when you need information or immediate assistance.

Delegate when you want AI to take on a more complex body of work.

Build when you want to turn an idea or requirement into a solution.

Automate when work should continue beyond the immediate conversation.

And surrounding those experiences are the governance and cost-management capabilities organizations need as AI adoption grows.

Watch the full webinar

We've only touched on the highlights here.

In the full webinar, we walk through the new Copilot experience, demonstrate application creation with Code, discuss Autopilot and Managed Runtime, and spend additional time looking at the emerging FinOps capabilities organizations can use to understand and govern AI consumption.

Watch the accompanying video for the complete discussion and demonstrations.

Learn more

Want to explore these announcements and capabilities in more detail?

Check out these official Microsoft resources:

Microsoft Edge Enterprise — Intermittent Blue Coat Proxy Authentication Prompt

sharkbone — Mon, 12 Oct 2026 19:37:34 GMT

Product: Microsoft Edge for Business / Microsoft Edge Enterprise
Component: Proxy authentication, HTTP networking and integrated authentication
Operating system: Windows 11 Enterprise Proxy: Blue Coat / Broadcom forward proxy, port 8080
Proxy authentication configuration: Basic Auth/ IWARealm exact authentication method to be confirmed
Affected browser: Microsoft Edge for Business
Comparison browser: Mozilla Firefox, where the same behaviour has not been observed
Impact: Intermittent interruption of browsing and loss of access to existing tabs until the user reauthenticates

We are experiencing intermittent, unexpected proxy authentication prompts in Microsoft Edge for Business. The dialog states: Sign in to access this site. The proxy http://[bluecoat-host-url]:8080 requires a username and password. Your connection to this site is not secure. The prompt appears sporadically, sometimes while the browser is idle or while tabs displaying otherwise idle ServiceNow, deepl etc. pages cannot be accessed until user reauthenticates with autofill if proxy password is saved in order to be able to access those sites again. No explicit navigation or user interaction is necessarily taking place when the dialog appears. This behaviour was not observed previously and has become noticeable more recently especially since the migration of a lot of our workloads to the microsoft cloud. Firefox does not appear to exhibit the same symptom under comparable.

We suspect that a background request, a new or reused proxy connection, proxy-session reauthentication, or an incomplete integrated-authentication exchange may be triggering the prompt. However, we have not yet identified the exact request or established whether the root cause is Edge, the proxy configuration, PAC routing, or the authentication infrastructure. usage conditions.

Edge should silently authenticate to the configured enterprise proxy through the organisation's approved authentication mechanism, without unexpectedly displaying a credential prompt during normal browsing or background activity.

New accessibility updates for Microsoft Certification exams

LibertyMunson — Mon, 12 Oct 2026 19:08:20 GMT

Preparing for a Microsoft Certification exam? Explore upcoming case study updates and new options for scheduling approved accommodations online.

If you're preparing for a Microsoft Certification exam, two upcoming changes may make your exam experience easier to navigate and schedule. The case study interface is being redesigned for greater readability and accessibility, and Pearson's accommodations process is becoming more streamlined.

Certification exams should give every candidate a clear opportunity to demonstrate what they know. By making complex case studies easier to navigate and reducing friction in the accommodations process, these updates are designed to help candidates focus more fully on the skills being assessed.

Here's what is changing, when the updates will be available, and what you need to know before scheduling your exam.

A redesigned case study experience

Case study questions ask you to work through a detailed business scenario while answering related questions. Because that can mean viewing a large amount of information at once, the experience has been redesigned with readability, accessibility, and navigation in mind.

The updated case study format has begun rolling out, with the goal of making it available for all exams and languages by the end of the calendar year. The exam sandbox is expected to fully reflect the new format by the end of October 2026.

New features include:

1. A cleaner full-screen layout. View the question and supporting scenario side by side, then use the splitter bar to adjust how much space each receives.

New full-screen case study layout

2. A responsive layout. On smaller displays or when using zoom, magnification, or other assistive setups, the interface shifts to a single-column reading order. The question, answer area, and scenario content appear vertically, reducing the need for horizontal scrolling.

Responsive single-column layout

3. Faster navigation. Use the linked Case Study Contents outline to move directly to a section. "Back to top" and "Back to contents" controls in the bottom right corner of the screen help you return without scrolling through the entire scenario.

"Back to top" control in the bottom-right corner of the full-screen experience

"Back to contents" control in the bottom right corner of the responsive experience

More options for scheduling approved accommodations

Microsoft has also been working with Pearson to make requesting and scheduling accommodations simpler and faster.

Available now: Online scheduling for approved accommodations

Candidates with some preapproved accommodations can now book their exam online instead of calling the accommodations scheduling team. For example, extra testing time, the most commonly requested accommodation, can now be scheduled on the web. Some accommodations that require additional arrangements, such as a separate room, still require a phone call, but more accommodations are expected to move to online scheduling over time.

Coming in 2027

A modern accommodations request system in early 2027. The current accommodations request system will be replaced with a streamlined experience integrated into registration and scheduling, so candidates can request an accommodation when they register instead of through a separate process.

Expanded online scheduling in mid-2027. Web scheduling is planned to expand to accommodations that require a separate room or advance lead time to set up the delivery, allowing more candidates to schedule online without calling.

What certification candidates should know

Before your exam, use the exam sandbox to become familiar with the updated case study experience.
If you have a preapproved accommodation, check whether it can be scheduled online or still requires assistance by phone.
Review the accommodations documentation before registering so you understand the available options and any advance requirements.

These updates are designed to make Microsoft Certification exams easier to navigate and accommodations easier to schedule. Before your next exam, explore the updated experience in the exam sandbox and review the accommodations guidance to understand which scheduling options are available to you.

Find the right credential for your goals.

Multiple pinned Copilot chats disappeared and continue disappearing

jclarky1 — Mon, 12 Oct 2026 18:52:21 GMT

I am reporting an issue with Microsoft Copilot chat history.

Over the last several days I have had multiple conversations disappear from my chat history, including pinned chats. I did not delete these conversations.

The issue began with one older pinned conversation disappearing. Since then I have noticed additional chats are also missing.

I have already:

• Confirmed I am signed into the correct Microsoft account.

• Verified the chats were not intentionally deleted.

I contacted Microsoft Support regarding this issue. Support advised that some missing chat issues may be related to synchronisation, indexing, or service-side issues, but they were unable to investigate the account directly and referred me to this community.

Questions:

1. Has anyone else experienced multiple disappearing chats, especially pinned conversations?

2. Has Microsoft confirmed any recent synchronisation or migration issues affecting chat history?

3. Is there any route to have an account investigated for missing chat history?

4. Has anyone successfully recovered missing conversations?

These chats contained important information accumulated over many months, so any guidance would be greatly appreciated.

Understand your Azure backup estate, from protection flow to reviewed change

zmustafa — Mon, 12 Oct 2026 18:36:21 GMT

A protected item exists. Its policy has a sensible name. The vault appears in the inventory.

Before a busy booking period, the reliability team still has a practical question: which part of this protection chain needs attention, and what should we actually change?

Azure Backup supplies the protection capabilities, recovery points, jobs, and vault controls. Azure Resource Graph, Azure Resource Manager, Log Analytics, and Cost Management supply complementary evidence. The challenge at estate scale is bringing that evidence together around an operational decision.

Azure Support Agent's Backup Manager provides that review workflow. Start with a workload, follow an item through its policy and vault, investigate failures, and prepare a supported correction for explicit review. Cost helps explain the estate; recovery objectives help establish priority. Neither replaces understanding what is protected and how recently it was protected.

Our example is Contoso Booking, the capture's label for the built-in Contoso Hotels estate. Follow its legacy property-management VM, contoso-pms-vm, through protection review toward a possible vault-alerting proposal. The synthetic snapshot contains four vaults, four protected items, and one failed job in the 24-hour summary. Investigating that failure remains separate from improving the vault's alerts.

About the examples: Contoso's resources, jobs, and costs are synthetic. The five GIFs use native application components with deterministic browser-local fixtures. Demo writes are disabled; no proposal, approval, apply, or backend workflow was executed. Visible amounts and timestamps are illustrative. Live-operation instructions below are source-grounded procedures, not captured outcomes or performance measurements.

Watch the Backup Manager tour

The faster-paced, approximately 60-second tour visits all ten Manager tabs, including Managed changes, then Fleet and Cleanup. Use it for orientation; the focused animations below show flow controls, job triage, vault posture, DR context, and cost review.

Synthetic native-UI tour with demo writes disabled. The ledger is empty; navigation does not demonstrate proposal submission, approval, execution, or Azure change completion.

Start with one completed analysis

For a live scope, choose the connection and workload or subscription, then select Analyze backups. Ordinary Manager data tabs read the completed snapshot; changing tabs does not start another estate sweep. Built-in demo scopes need no analysis and offer no Analyze button.

That snapshot keeps item, policy, job, and vault views on the same analysis. Read the header's analyzed time alongside the protection percentage.

Azure Resource Graph provides the inventory backbone, including protected items, backup instances, policies, jobs, and Site Recovery information. Supplemental ARM reads inspect vault configuration. Cost Management and retail prices supply different cost inputs; Log Analytics supports longer-horizon reporting when vault diagnostics and access are configured.

Start with Reader-equivalent access to the selected resources and vaults, plus the application's backup_manager.read permission. Actual-spend queries need additional Cost Management access. Backup Reports need a suitable workspace and a service-principal or managed-identity connection; a pasted ARM token cannot query that different Log Analytics audience.

During analysis, inspect the phases and source results. An unreadable job source is different from a completed collection containing no matching jobs. Individual source failures can leave partial results, and per-vault enrichment warnings deserve attention even when the headline status looks reassuring. If every Resource Graph source fails, the previous snapshot is kept rather than replaced with a misleading empty estate.

There is an important scope detail: workload analysis currently collects the backup estate of the workload's member subscriptions. It is not a strict per-datasource membership filter. Match resource IDs before attributing every row, or every charge, to Contoso Booking.

For a broader review, management-group scope resolves visible descendant subscriptions and is analysis-only. Narrow to a workload or subscription before authoring Azure changes, and always inspect each ledger entry's own target and connection.

Read-only Azure analysis can save reports in the application. It does not mean that no local state changes, nor that all later interactions are cache-only: cost-period changes, retention modeling, scope discovery, and mutation preflights can make additional Azure reads.

Follow the protected item through policy and vault

Open Protection flow. The default chain runs from subscription through workload, resource type, policy, vault, and outcome. Add the Item column when the question concerns a particular machine rather than the estate's overall shape. Search by a visible resource, policy, or vault name to narrow the paths.

Trace contoso-pms-vm → its protected item → DefaultPolicy → rsv-demo-legacy.

These are relationships, not interchangeable labels. The source is the resource the team owns. The protected item represents its backup protection. The policy describes the relevant schedule and retention. The vault supplies the protection-management and security context.

Search the native flow, put Vault first, then switch to Cost weighting. These ribbons use synthetic estimates, not billed item charges. The unprotected branch represents detected gaps; verify its underlying rows before acting.

Click a bar or ribbon to highlight its complete paths. Begin with Items weighting: where does protection concentrate, and which policies or vaults are shared? Later, Cost weighting uses allocated actuals when available, otherwise estimates. A wider ribbon is not inherently a worse configuration; it may represent a deliberately shared service.

Use presets or a custom column chain to make the relationship readable. A saved perspective belongs to this browser, not a shared account-wide configuration.

Now open Protection and inspect contoso-pms-vm. Confirm its source, vault, policy, and protection state. Its latest recovery-point timestamp is missing and its age is unknown. The last-backup timestamp accompanies a failed status; it is not a successful recovery point. Verify the latest usable point against the workload's recovery objective.

Flow outcomes are prioritization cues. Their freshness rule uses a fixed 48-hour threshold, while Job inbox and DR use separate reference thresholds. Missing age can also produce an attention outcome. Read the timestamp and applicable objective before interpreting the color.

Keep unknown sources separate from protection gaps

The snapshot also contains retired-app-vm in rsv-demo-regional, flagged orphaned with protection stopped and data retained. That is separate from the failing PMS VM. Before treating the retained item as obsolete, ask whether its source is truly absent or outside the available evidence.

An orphaned item means the source was not found by the lookup. Retained backup data can still exist and incur charges. Source lookup is bounded, and a failed resource sweep disables orphan detection rather than making every item look deleted. Independently confirm important source-absence findings in Azure before making a lifecycle decision.

Unknown source status is therefore not equivalent to an unprotected resource. The former needs identity and visibility investigation; the latter needs a protection decision once the detection is verified. Stopped protection is another distinct state: the team may intentionally retain existing backup data without creating new points.

Gaps brings together detected backup-eligible resources without matched protection and findings ingested from Backup & DR Coverage. Keep their provenance visible. Coverage is the separate reference-based scoring workflow; its current live collector uses best-effort Resource Graph properties and does not collect the deep protected-item, job, restore-test, or Site Recovery pair evidence that its synthetic examples can display. Backup Manager has its own job collection.

That distinction prevents an empty Coverage job field from becoming “this workload has no backup jobs.” Use the Coverage reference to understand the finding, then verify the item and service evidence here or in Azure.

For a confirmed supported gap, select the intended resources, vault, and policy, then preview. Blocked targets explain their constraints, including subscription compatibility. Submission creates pending managed requests, not immediate protection. If arriving from a flow action, recheck the selection: the gap handoff can preselect snapshot gaps beyond the searched ribbon.

For retired-app-vm, assign source and retention verification before any lifecycle decision. Its orphan flag is not permission to discard retained backups.

Work the failure cluster, then verify each item's recovery point

Open Job inbox for the same completed analysis. This is not simply another failed-job list. It groups failures by Azure Backup error code and enriches known codes with a cause and remediation from the editable failure knowledge base.

In our scenario, contoso-pms-vm appears in a guest-agent availability cluster. The relevant code, UserErrorGuestAgentStatusUnavailable, points the reviewer toward the guest agent and backup extension prerequisites. The cluster connects the error to affected items and guidance, giving the platform owner a focused starting point.

Expand the guest-agent failure cluster, then open the contoso-aks protected-item drawer to illustrate detail inspection. That drawer is not the failing VM's recovery-point evidence. No retry, cancellation, guest repair, or backup operation is executed.

The cluster is a grouping of reported errors, not proof that every member shares one verified underlying cause. Read representative job messages and confirm each target. An unclassified code remains an investigation rather than acquiring a confident explanation from its badge.

Then check chronic failures. A recent successful job elsewhere in the vault does not resolve this item's unknown recovery point. Even a success for the same resource needs its operation type checked: configuration work is not the same as producing a usable backup point. For Booking, the handoff should include the source, error, missing recovery-point evidence, expected interval, and owner investigating the guest prerequisites.

Keep the history windows straight. Resource Graph supplies approximately seven days of backup job history, while Overview counters use a trailing 24-hour window. Here the summary shows one failed job; the wider cluster contains three failures for contoso-pms-vm. Job inbox also has display limits and filters. A missing row is not proof a job never ran. Longer-horizon questions belong with properly configured Backup Reports.

After investigating the cause, an authorized operator can draft Back up now where appropriate. That is an on-demand-backup proposal; applying it starts a real backup. Cancellation similarly has an operational effect and is supported for running Recovery Services jobs, not every job type.

Investigate before retrying; the example demonstrates neither repair nor a reduction in incidents.

Review retention without confusing a model with a policy edit

DefaultPolicy in rsv-demo-legacy is the next stop. Policies puts retention, protected-item counts, duplication, unused policies, and below-baseline findings together. The question is whether the policy matches the workload's obligations, not whether its name sounds standard.

Duplicate-looking policies can serve different operational boundaries. A policy with no matched items might be obsolete, intentionally staged, or incompletely observed. Unknown retention is not zero retention. Resolve those questions before consolidating anything.

For a live review, select the intended policy and open Model retention change. If you arrived from Protection flow, confirm the selection: that handoff opens Policies, not an already-selected impact model. Enter a proposed retention period and inspect the direction and recovery-point impact.

This is a read-only model, not a policy submission. Exact enumeration is bounded to a subset of candidate Recovery Services items; remaining items and Backup vault cases use estimates. The dialog distinguishes exact and estimated coverage. Those labels matter more than the apparent precision of a single removed-point total.

For Booking, ask whether the proposed period supports the actual recovery scenario and retention obligations. A shorter policy might look cheaper while removing the older point needed to recover from an error discovered late. Increasing retention does not repair the failed guest prerequisites or retroactively create points that were never produced.

Bring the workload owner and any relevant compliance owner into that decision. Record why a period is appropriate, which items were modeled exactly, and what still needs service-level verification. A model with an unknown starting policy is not ready to authorize a decrease.

The change registry supports policy targets, but the current Policies tab provides modeling, not a general policy-creation or policy-editing form. Arrange an actual edit through a separately reviewed supported workflow. Reversing a retention setting cannot recover points already pruned.

Turn vault posture into a specific control decision

Follow rsv-demo-legacy into Vaults. A vault score helps prioritize review, but the expanded control rows explain what that score represents. Read the values and any enrichment errors before choosing an action.

Azure provides several complementary protections. Soft delete retains eligible deleted backup data for a recovery window. Immutability addresses changes that could remove recovery points prematurely. Multi-user authorization, or MUA, uses Resource Guard to add a separate authorization boundary around protected critical operations. These controls answer different questions; one is not a replacement for the others.

Microsoft's guidance on soft delete and multi-user authorization is the right companion to the review. In particular, Resource Guard authorization is not the same mechanism as approving a request inside Azure Support Agent.

In rsv-demo-legacy, soft delete is Disabled, MUA is None, and built-in backup failure alerts are Disabled. These are known fixture values, not unreadable controls. Review deletion protection and Resource Guard configuration as separate work; the narrow proposal example below addresses only alerts, not the vault's entire posture. In another estate, an unreadable Resource Guard association would mean unknown, not confirmed absence.

Expand the native vault controls, then inspect DR & drills. Soft delete and alerts are disabled; MUA is absent. This capture contains no hardening proposal, ledger handoff, or execution.

The native hardening controls support selected operations such as enabling soft delete, extending its retention, enabling built-in alerts, configuring diagnostics, and eligible storage or Cross Region Restore settings. They do not mean “automatically harden everything.” Unsupported and portal-only controls remain visible as separate work.

Resource Guard configuration, immutability locking, customer-managed keys, and private endpoints stay outside this drawer's automated actions. Redundancy also has lifecycle constraints: an occupied Recovery Services vault cannot simply switch backup redundancy, and Backup vault redundancy is fixed at creation. Cross Region Restore requires geo-redundant storage; enabling that capability is not executing a restore.

Beyond the capture, on a live writable connection, select Enable built-in alerts only and choose Draft hardening changes. Review created and skipped outcomes. Authoring reads and merges the current monitoring settings to preserve surrounding configuration; an unreadable setting prevents that alert proposal. This prepares a pending request, not an improved vault. Apply submits the change; verify its result in Azure. Enabling alerts neither fixes the guest-agent issue nor proves notification delivery.

If long-horizon reporting is also needed, treat diagnostics as another explicit decision with a reviewed workspace destination and ingestion implications. An enabled setting alone does not prove the resource-specific reporting tables contain usable data.

A proposal is not an Azure operation

For an authorized live proposal, Managed changes separates review from execution. Open the resulting alerting request and read its target, connection, operation, reason, and risk. Explain the intent: enable the vault's built-in failure alerts while the workload owner investigates the backup failures. No such request exists in the captured empty ledger.

Stage	Meaning for the reviewer
Pending	A request exists in the application. Submission has not changed Azure.
Approved	An authorized decision is recorded. Azure is still unchanged by that decision.
Applying	The approved operation has been submitted and is being tracked.
Applied or failed	Inspect the outcome and reconcile it with Azure before closing the work.

Drafting the vault request requires backup_manager.vault_write. Approval and apply require backup_manager.approve; execution also needs a writable connection and the relevant Azure rights. An application role cannot manufacture Azure permissions. Autonomous chat does not bypass this managed approval/apply sequence, and a gated connection is recommended. Arrange independent review operationally: requester/approver separation is not generally enforced.

Only Apply to Azure submits the approved operation. Azure Backup operations can be long-running, so an accepted request may remain applying while the server polls it. Closing the browser does not turn it into a failure or abandon its ledger tracking.

Read terminal errors carefully. A tracking timeout does not cancel or reverse the Azure operation; check the actual job before retrying. Updates carrying an expected-state hash can fail when the target changed during review. Backup Manager records that conflict as failed, not a separate stale status, and not every target has the same concurrency check.

For that proposed alerting correction, verification means reading the actual vault configuration, confirming the intended alert setting and preserved surrounding configuration, and running a fresh analysis. Notification behavior needs separate verification. None of these post-apply checks was performed in the synthetic capture.

Rollback is also bounded. Where offered, it creates a new pending inverse for review, approval, apply, and verification. Some updates require a stored before-state. A protection-create inverse can stop protection while retaining data; it is not deletion of the backups.

On-demand backups, job cancellations, Site Recovery tests and their cleanup, new vaults, and diagnostic creates have no general rollback here. Do not assume every control change has an inverse merely because the ledger includes a rollback action.

The manager exposes no Azure backup restore operation or destructive backup-data operation: no backup-data deletion, soft-deleted-item purge, immutability locking, soft-delete disabling, or container unregistration. Those stay in separately controlled Azure procedures. Restoring local history or reference revisions is different, as are Cross Region Restore configuration and Site Recovery test failover.

Protection coverage is not recovery assurance

At this point the Booking team can explain a protection relationship, an execution problem, and a possible alerting correction. It still has not established that the reservation service can recover to its required business state.

Recovery point objective, or RPO, concerns tolerable data loss expressed in time. A recent point helps assess that objective. Recovery time objective, or RTO, concerns restoring the service within the required time. That involves application dependencies, access, procedures, validation, and people, not just a backup timestamp.

Backup Manager's RPO assessment uses the editable reference tiers. Those are assessment inputs, not Azure settings. Missing point ages remain evidence gaps, and an apparently perfect percentage over an empty eligible set is not recovery proof. Likewise, a protection percentage describes the detector's eligible resources, not every dependency necessary to serve bookings.

DR & drills adds Site Recovery health, RPO context, and the drill register. A healthy replica and a recently exercised recovery procedure answer different questions. Follow Azure Site Recovery guidance for the applicable replication and test workflow.

Schedule drill creates an application register entry. It does not schedule or execute an Azure restore. A team performs an authorized rehearsal outside Backup Manager, reviews the result, and then records Passed or Failed with evidence. Recording an outcome is an immediate local governance action, not a pending Azure proposal. Never mark an unperformed exercise passed.

Actual Site Recovery test failover is a different supported workflow. Its request requires two distinct approvers and individual approval; that target-specific rule is not universal for every high-risk action. The UI defaults the test to NoNetwork. Applying it creates billable test resources, and later cleanup requires a separate reviewed request.

Neither workflow was executed here. Assign Booking's recovery exercise and establish its evidence requirements before changing the register; configuration review cannot stand in for that exercise.

Read cost as measured, estimated, and apportioned evidence

Now return to the same vault in Cost & waste. This is a supporting lens on the protection decision, not a separate hunt for the smallest bill. A retained item, a shared vault, and a policy obligation need operational explanation before a cost recommendation is useful.

The default period is the last complete month. Begin with the period, currency, and source status, then distinguish three kinds of input:

Reported actual spend: Cost Management supplies charges associated with the vault for the selected period and cost basis. This is the financial anchor when available.
Measured consumption: Backup Reports can provide consumption data used to weight an allocation. A measured quantity is not itself a directly metered item charge.
Estimated cost: Retail list prices and footprint assumptions model a monthly amount. They are planning inputs, not an invoice or a promised future charge.

The per-item view adds a fourth label that connects those inputs: apportioned actuals. Backup Manager takes vault-level spend and allocates it across protected items, using measured consumption when available, then estimated cost, then equal shares. Each row identifies the basis. The allocated figures reconcile to the vault total; reconciliation does not turn them into independently billed item records.

Review seeded list-price estimates and unavailable actuals, then move to Policies. Demo mode does not query Azure Cost Management; no measured consumption or apportioned actuals are shown. This is policy review, not a retention-change demonstration.

On a live scope with actuals available, inspect the meter breakdown and per-item allocation basis before attributing vault spend to a resource. Check the analysis scope: workload collection can include other resources in its member subscriptions. rsv-demo-legacy itself protects just one item in this fixture.

An absent actual-spend value is not zero spend. Read whether access, period coverage, or another source limitation prevented the result. Unattributed charges remain visible rather than being silently spread over convenient rows. Mixed currencies are kept separate, and partial periods are not used for a misleading estimate-versus-actual variance.

Similarly, the estimate assumes a full month at the current footprint. A vault populated during the month can legitimately differ from that model. Some protection mechanisms have costs outside the Backup service meters: Azure Disk Backup's snapshot billing is an important example. An unpriced or flagged zero is a reason to inspect the relevant service charges, not declare it free.

Recoverable waste prioritizes review candidates using actual spend when available and list prices otherwise. A stopped or apparently orphaned item may still be intentionally retained. Confirm ownership, source status, and obligations before proposing anything. The Cleanup view discussed below does not remove those Azure backups.

Keep the cost basis attached to the review. Savings would require an authorized change and a comparable billing review afterward; none is claimed here.

Use Fleet to choose the next review

The Manager · Fleet · Cleanup strip separates different levels of work. Manager investigates the selected scope. Fleet compares workloads using their stored analysis summaries. Opening that grid does not query Azure; selecting Analyze selected deliberately starts collection. Demo workloads cannot be launched.

For a reliability lead, the useful first sort is often the default worst-first order: workloads never analyzed, then gaps, protection percentage, and failing jobs. An unmeasured workload is an unknown needing attention, not automatically the least protected application.

Read Last analysis alongside every score. A freshly reviewed row should not be casually compared with a stale row collected before another workload's migration. The Fleet cost column is Est. cost / mo, even when the underlying analysis also collected actual spend. Open the workload's Cost & waste view for that distinction.

Selected workloads run through a server-owned durable batch, with two Backup Manager analyses admitted at a time. The queued work does not depend on an open browser. Return to inspect phases and outcomes; use the batch summary to distinguish failed, partial, and cancelled items.

Cancel pending removes queued work, not completed results or already-submitted Azure operations. Retry failed includes failed, partial, and cancelled batch outcomes. Check the reason before launching more work, and avoid overlapping Fleet and single-scope analyses under the assumption that they share one job record.

Fleet is workload-based. Subscription and management-group reviews remain individual Manager analyses. Use the grid to select the next evidence review, not to turn a stored score into a claim about the estate's current recoverability.

Keep review evidence without confusing Cleanup with backup deletion

The Booking review should leave something another operator can understand. Excel review pack exports the last completed snapshot: source context and limitations, protected items, jobs, policies, posture, gaps, DR, and cost. Downloading it does not start a new Azure collection.

Read Coverage & limitations before interpreting blank sheets or totals. During another analysis, the workbook still exports the previous completed result. Managed changes and drills are live application ledgers with a separate read timestamp; their connection-wide entries are not necessarily limited to the analyzed workload. Review identifiers before sharing the file.

Do not assume an applied request automatically created Evidence Locker evidence. Current apply tracking does not do that. Preserve the completed snapshot explicitly when required, and use actual exercise evidence for drill outcomes rather than a dashboard image.

Cleanup manages application storage. Its stored analyses are the reports used by the tabs; its analysis history contains compact records of earlier results. An orphaned stored analysis can refer to a deleted workload, removed connection, or obsolete report shape. That is unrelated to an orphaned protected item in Azure.

Purging a stored analysis also removes its Fleet summary, and the scope needs analysis again. History supports restorable trash and permanent purge. Permanent deletion requires the approve permission, but it is an immediate local operation, not an Azure change awaiting ledger approval.

Nothing here deletes backup data or modifies Azure protection. Audit records and Evidence Locker snapshots have independent retention. Treat Cleanup as report lifecycle management, with its own governance consequences, rather than a button for realizing the Cost & waste estimate.

How it's judged

A successful Backup Manager review is an explanation that survives a handoff. For Contoso Booking, the questions are concrete:

Can we trace the item? The source, protected item, policy, vault, and recovery-point evidence agree, with the connection and analysis time preserved.
Can we explain the concern? The failed-job cluster leads to specific source evidence; unknown sources and unreadable controls remain distinct from confirmed gaps.
Can we justify the action? The built-in-alerts proposal has an explicit purpose, target, owner, and permission boundary. It is not described as fixing the underlying backup failure.
Can we distinguish decisions from outcomes? Pending, approved, applying, and terminal states remain separate, with Azure readback required after an actual apply.
Can we state what remains unproven? Recovery assurance, notification behavior, and any financial benefit need evidence beyond the configuration and synthetic examples.

Keep a compact review note with the item identity, policy, vault, latest verified point or explicit unknown, failure investigation, control decision, and next responsible owner. Attach the cost basis if it influenced the decision. Record unavailable sources and the plan to resolve them alongside completed checks; uncertainty should not disappear when the meeting ends.

Revisit that note after policy, workload, or ownership changes and exercises. Compare the same scope and source visibility before claiming that a better headline score means better protection.

Try it read-first

Start with a narrow exercise that ends before any operational change:

Open Backup Manager in Azure Support Agent with an appropriately scoped read-only Azure connection. Choose one workload or subscription and inspect or explicitly refresh its analysis.
Trace one protected item through Protection flow, then confirm its source, policy, vault, and latest recovery point in Protection.
Inspect a related job cluster or an unavailable-source case. Record the evidence window and the difference between an observed failure and missing information.
Expand the vault's controls. Identify one supported proposal candidate and any separate portal-only work, without submitting a change or recording a drill outcome.
Check the cost basis and write a short review note. Stop before backup, test, cancellation, apply, reference edits, or Cleanup actions unless those are separately authorized.

The Backup Manager reference and operations guide cover permissions, supported workflows, source limitations, and verification in detail.

Azure Support Agent is open source on GitHub. Explore the project, contribute feedback, and review the installation guide before deploying. Hosting and connected Azure or model services can incur charges; self-hosting does not remove those costs or configured external-service data flows.

Start with a protection chain you can explain. The next step may be a reviewed change or a better question, not an unsupported recovery claim.

Fabric and Databricks Together

anishekkamal — Mon, 12 Oct 2026 18:34:46 GMT

Fabric and Azure Databricks overlap, but optimize different operating experiences. Fabric integrates OneLake, engineering, warehousing, real-time analytics, and Power BI as SaaS. Databricks combines Spark and SQL engineering, Unity Catalog, and a mature ML lifecycle. Delta Lake and ADLS Gen2 enable coexistence; Fabric metadata mirroring and OneLake shortcuts can expose Databricks tables without copying their files. The hard work is assigning ownership, security, compatibility, and service objectives at every handoff.

Place workloads by operating responsibility

Use Fabric where the product is a governed analytical experience—especially T-SQL marts, semantic models, Direct Lake, and Power BI. Use Databricks where the product is an engineering or ML execution system—especially complex Spark estates, feature engineering, training, and Unity Catalog-governed pipelines. Both can do more; this is a starting boundary, not an exclusivity rule. Add the second platform only when a clear handoff avoids duplicated work.

A common brownfield pattern keeps Bronze, Silver, and Gold engineering in Databricks and mirrors selected, BI-ready Gold schemas to Fabric. Fabric then owns its SQL endpoint, semantic model, reports, and consumer permissions. Create a physical Fabric Gold copy only when it changes the contract: security minimization, star-schema reshaping, incompatible Delta features, source isolation, recoverable snapshots, or measured performance value.

Shared Delta data does not merge identity, governance, runtime, or cost controls.

Use metadata mirroring with precise expectations

The mirrored Azure Databricks catalog capability is GA. Fabric represents selected Unity Catalog metadata, creates a read-only SQL analytics endpoint, and reaches the existing Delta files through shortcuts; it does not replicate the table data or create a write path. Supported additions and deletions can appear from seconds to minutes, and endpoint synchronization adds another clock. Mirroring is analytical access, not event transport or a guaranteed-latency replication service.

Treat prerequisites as security gates. Unity Catalog must be enabled; a metastore administrator must enable external data access, which is off by default. The connection principal needs explicit USE CATALOG, USE SCHEMA, SELECT, and EXTERNAL USE SCHEMA. EXTERNAL USE SCHEMA is not included in ALL PRIVILEGES or automatically granted to a schema owner. Use a non-personal identity, mirror the minimum useful Gold surface, and run post-deployment discovery, row-count or watermark, SQL, semantic, and deny-user probes.

Keep security and catalog boundaries separate

Unity Catalog permissions, row filters, column masks, and ABAC policies do not carry into Fabric. Configure Fabric workspace, item, and OneLake permissions independently, and map business-intent Entra groups into both systems. If required policy cannot be reproduced safely, publish a physically curated table whose rows and columns already satisfy the consumer contract. Preserve both lineage domains and record the handoff; public documentation does not promise automatic end-to-end stitching.

For firewall-protected external ADLS Gen2, separate two identities. OAuth or a service principal authorizes Databricks and Unity Catalog discovery. Fabric Workspace Identity traverses the storage firewall through trusted workspace access and needs least-privilege data-plane authorization. Trusted workspace access is GA but requires F capacity, is unavailable on Trial, and uses an Azure Storage resource-instance rule. The documented path does not support generalizing mirroring to Databricks workspace storage behind a firewall.

Make Delta and BI compatibility a release gate

A shared Delta format is a contract, not universal compatibility. Test column mapping, deletion vectors, liquid clustering, type widening, protocol versions, names, and data types through every intended engine. The Fabric SQL analytics endpoint supports name-mode column mapping but not ID mode. Fabric Runtime 1.3 is GA; Runtime 2.0 is public preview with newer Spark and Delta versions. Pin producers and block unreviewed protocol upgrades.

Direct Lake still requires semantic design, well-maintained tables, capacity, and concurrency testing. Verify grain, keys, relationships, measures, row-level security, file layout, framing after changes, cold and warm latency, and the selected Direct Lake mode. Zero-copy avoids one storage copy and replication pipeline; it does not eliminate Fabric capacity, source reads, producer compute, network, monitoring, or governance cost.

Coexistence decision checklist

One owner should accept each producer, consumer, network, security, semantic, incident, and cost contract. Deploy definitions, bind environment-specific connections, start the mirrored item, and verify runtime state; a successful pipeline deployment alone does not prove data is serving.

Decision	Production evidence
Placement	Primary platform and one-sentence handoff rationale; authoritative Gold contract named
Security	Least-privilege principals, firewall rule, Fabric policy mapping, allow and deny personas tested
Data	Runtime/protocol manifest; every engine passes schema evolution and feature tests
Consumption	SQL and Direct Lake readiness, semantic ownership, scale, concurrency, and fallback verified
Operations	Start/probe release steps, lag and failure telemetry, rollback, cost owner, and copy review date

Conclusion

Fabric and Databricks coexist cleanly when shared data does not blur platform boundaries. Start with a small set of curated Gold tables. Prove identity, denial, metadata freshness, Delta compatibility, Direct Lake behavior, monitoring, deployment, and rollback. Expand by owned data product, not catalog volume. The goal is to minimize duplicate work while giving every workload, policy, service objective, and bill a clear owner.

FinOps for Data and AI Workloads

anishekkamal — Mon, 12 Oct 2026 18:34:05 GMT

A VM-only review misses the unit economics of managed data and AI services. A useful review asks what it cost to produce one reliable outcome, then includes DBUs, capacity units, activity runs, integration-runtime compute, tokens, storage operations, data movement, and shared platform cost. Make spend attributable first; remove idle demand and unnecessary work; protect the service-level objective (SLO); and buy commitments only against a stable, measured baseline. FinOps is a continuous engineering loop, not a one-time savings exercise.

Measure the complete workload

Choose a denominator that reflects value: cost per successful pipeline run, terabyte promoted through a quality gate, business refresh, million events, or 1,000 accepted AI outcomes. Keep failed work, retries, and shared-cost allocation in the numerator. A lower hourly rate is a false saving if runtime doubles, freshness slips, quality falls, or spend moves to another team.

Tag workload, owner, environment, product, region, and SLO class. Allocate shared Fabric capacity, Databricks compute, integration runtimes, monitoring, and networking directly when reliable telemetry exists; otherwise publish a transparent proxy and retain an unallocated bucket. Budgets notify rather than stop services, and cost data can lag, so pair budgets and anomaly alerts with operational telemetry and an owned triage process.

Each workload layer has an independent meter and performance guardrail.

Match the execution contract to demand

For Azure Databricks, keep interactive exploration separate from scheduled jobs. Enforce auto-termination, tested VM families, practical autoscaling ranges, and required allocation tags. Compute policies are GA but require the Premium plan; lowering a policy limit does not retroactively terminate existing resources. Benchmark Photon, pools, spot capacity, and serverless on real workloads. Small files and poor clustering turn storage design into compute spend; predictive optimization is GA for eligible Unity Catalog managed tables, while VACUUM LITE remains Public Preview and needs an explicit preview exception.

Azure Data Factory meters orchestration, copy DIU-hours, data-flow execution and debug, and integration-runtime choices. Fabric Data Factory is GA and consumes capacity units, with OneLake storage considered separately. Prefer incremental movement, stop debug sessions, consolidate tiny activities only when retry and ownership boundaries remain clear, and count retry cost per successful run.

For ADLS Gen2, model capacity, read/write/list operations, tier transitions, retrieval, redundancy, retention penalties, and transfer. Cool, cold, and archive economics include minimum residence periods; archive is offline and rehydration can take hours. A lifecycle rule is not valid until restore, legal-hold, retention, and recovery objectives still pass.

Right-size shared capacity and AI requests

Fabric capacity must be managed at the timepoint and workspace level. Bursting and smoothing can consume future capacity, so monthly averages can hide interactive delays and throttling. Use the Capacity Metrics app with workload telemetry; isolate incompatible demand and pause nonproduction F capacity only after checking queued work and smoothed usage. Spark Autoscale Billing is a separate pay-as-you-go behavior, not part of bursting and smoothing.

For Foundry model deployments, compare Standard, priority processing, provisioned throughput, and Global Batch against the request shape. Provisioned throughput and Global Batch are GA where supported, but PTU quota does not guarantee capacity, and model, region, minimum, and reservation constraints apply. Use the smallest model that passes task-specific quality and safety tests; cap output and retries; batch asynchronous work; and meter search, storage, code, functions, and observability separately from tokens.

Protect performance with controlled experiments

State the expected meter reduction and freeze the comparison boundary: demand, data volume, model or runtime version, region, quality checks, and SLO. Record baseline cost, latency, freshness, failures, retries, and allocation. Change one major lever where practical, canary it, observe a representative peak and business cycle, and accept or roll back using both cost and SLO evidence. Map the actual network path; private endpoints improve isolation but add DNS, topology, and processing considerations and do not make every cross-region transfer free.

Operate on a regular rhythm: triage material anomalies daily, review idle and unallocated spend weekly, assess unit-cost and SLO evidence monthly, and revisit lifecycle, recovery, and commitments quarterly. Re-baseline after a model, runtime, capacity, region, retention, redundancy, or architecture change. This prevents an optimization that was valid for yesterday’s workload from becoming today’s reliability defect.

Production decision checklist

Commitments come last. Recheck current prices, status, region, quota, networking, and reservation terms at implementation time; none should be copied as a timeless constant.

Gate	Required evidence
Ownership	Workload, owner, denominator, SLO, and at least 95% allocation coverage
Demand	Idle time, retries, execution mode, file/request shape, and peak behavior measured
Guardrail	Quality, p95 latency, freshness, recovery, and rollback thresholds pass
Status	GA/Preview, plan, region, quota, capacity, and fallback recorded
Commitment	Only the post-optimization stable floor is reserved; renewal owner named

Conclusion

Durable FinOps joins the meter, owner, useful outcome, and SLO in one evidence chain. Start with visibility and allocation, choose the right execution model, remove waste, improve data and request shape, and right-size from peaks rather than averages. Apply rate optimization only afterward, then repeat whenever demand, architecture, model, region, or service behavior changes.

Governance Boundaries in Microsoft Foundry

anishekkamal — Mon, 12 Oct 2026 18:32:14 GMT

Microsoft Foundry governance works best when teams separate broad Azure controls from Foundry resource controls, project access, model deployment configuration, and agent endpoint permissions. This article provides a practical boundary map for production decisions, with public references and a checklist for implementation.

Use Azure subscription and resource group scope for enterprise-wide policy, allowed regions, tagging, budgets, and inherited access.
Use the Foundry resource as the administrative, security, networking, monitoring, and shared deployment boundary.
Use projects for team and workload organization, not as the only place to enforce enterprise controls.
Use model deployments to govern runtime model version, deployment type, capacity, filters, and rate behavior.
Use agent-scope access for narrow endpoint consumption, and prefer Microsoft Entra ID over API keys for production.

Why this matters

Microsoft Foundry is becoming the shared place where teams build agents, deploy models, connect tools, evaluate behavior, and operate AI systems. That consolidation is useful, but it also creates a practical governance question: should a control live at the Azure subscription, the Foundry resource, the project, the model deployment, or the agent endpoint? The answer matters because each boundary enforces a different kind of decision.

A five-boundary mental model

Start with the broadest boundary and move inward. The subscription or resource group is where enterprise Azure governance usually begins: allowed regions, required tags, cost grouping, resource locks, inherited role assignments, and Azure Policy initiatives. The Foundry resource is the administrative and security boundary for a Foundry environment. Microsoft describes it as the single management plane for agents, models, and tools, with unified RBAC, networking, and policies.

Separate control plane from data plane

The cleanest design conversations separate management actions from runtime actions. Control-plane decisions include creating resources and projects, assigning roles, configuring networking, creating connections, and deploying models. Data-plane activity includes inference, agent interaction, evaluation jobs, content safety calls, tracing, and monitoring. A role or lock that protects a resource from deletion does not automatically govern every runtime action. Production governance should deliberately combine Azure RBAC, Foundry RBAC, Azure Policy, network controls, deployment settings, and application logic.

RBAC guidance

Use Microsoft Entra ID for production wherever possible. Microsoft states that API keys are convenient for prototyping but coarse-grained, hard to audit per user, and not recommended for production least-privilege scenarios. Foundry roles are designed for Foundry-specific workflows: for example, builders, project managers, account owners, and agent consumers. Azure roles still matter for subscription, resource group, and role-assignment authority. Be conservative: check the current role table for the exact operation because model deployment, project building, agent publishing, and inference can use different permission surfaces.

Deployment governance is runtime governance

A model deployment is not just a model choice. It is where runtime posture becomes concrete. Deployment type affects where inferencing data can be processed: Global deployments may process in any Azure region, Data Zone deployments keep processing within the Microsoft-specified US, EU, or APAC data zone, and Standard deployments process in the deployment region. That makes deployment type a compliance and architecture decision, not only a performance or price decision.

Policy, preview, and availability

Azure Policy can enforce or audit important Foundry-adjacent requirements, including key access, customer-managed keys, private link, network restrictions, managed identity, model eligibility, and content filtering. Several AI/model-specific policy definitions are marked Preview, so treat them as promising controls rather than production defaults unless your organization accepts preview terms. Foundry also documents a tag to hide preview surfaces and custom RBAC patterns to block selected preview operations.

Recommended operating pattern

Use resource groups and subscriptions for enterprise policy, cost, and environment separation. Use separate Foundry resources when environments need different networking, keys, quotas, or administrative ownership. Use projects for team and workload separation inside a governed resource. Use model deployments to isolate runtime configuration, model version, data-processing posture, filters, and capacity. Use agent-scope access only when a consumer needs one agent endpoint, not the whole project. Prefer Entra ID and managed identities, and disable or tightly govern local key access where production controls require it.

Decision guide

Production checklist

Which boundary owns this control: Azure scope, Foundry resource, project, deployment, or agent endpoint?
Is the action control plane or data plane?
Is the model or feature generally available or Preview?
Where can inferencing data be processed for the chosen deployment type?
Which role grants only the needed permission at the narrowest useful scope?
Is enforcement handled by RBAC, Azure Policy, network isolation, deployment configuration, or application code?
Have region, quota, model availability, dependent services, Marketplace terms, and cloud environment been verified?

Conclusion

Governance in Microsoft Foundry is not a single switch. It is a layered design. Put enterprise constraints at Azure scope, shared platform controls at the Foundry resource, team workflows in projects, runtime posture in deployments, and consumer permissions at the agent endpoint. That separation keeps governance understandable, auditable, and easier to change as models, regions, deployment types, and platform features evolve.

Identity at Every Hop

anishekkamal — Mon, 12 Oct 2026 18:31:26 GMT

Use delegated On-Behalf-Of access only when a downstream service must enforce the signed-in user's permissions. Use a managed or agent identity for unattended work. At every hop, obtain a token for the intended audience instead of forwarding one issued for another service.

Model every hop as a boundary

A Teams request can involve a user, Teams app or bot, application backend, Foundry project or agent, MCP server, and protected API. Each component may use a different principal, token audience, permission model, and consent boundary. Decide whose authority each downstream resource should evaluate, then grant that principal only the required access.

For a Teams tab, getAuthToken() returns a JWT whose audience is the application's client ID. Send it to the backend over HTTPS and validate signature, issuer, audience, expiry, and tenant. It is not a general-purpose Microsoft Graph token. Bot SSO uses the Bot Framework token service; documented SSO supports one-to-one and group chats, not channel scope.

Do not authorize from a display name, email, or client-parsed claim. The backend must establish the trusted principal first, then apply application authorization. Teams SSO gets identity into the application; it does not grant automatic access to Foundry, a tool, Graph, or business data.

Each hop validates a token for its own audience; tokens are exchanged, not relayed. Original diagram.

Exchange tokens when user authority must travel

OAuth 2.0 OBO is for a middle-tier API calling another API under a signed-in user's delegated authority. The backend validates Token A, authenticates as a confidential client, and exchanges Token A at the tenant-specific Entra endpoint. Entra returns Token B for the downstream audience and scopes. Present Token B only to that resource.

OBO requires a user principal and delegated scopes. An app-only token cannot be used as the OBO assertion; use client credentials or managed identity when no user is present. Never relay the backend token to Graph, MCP, or another API. Relay breaks audience enforcement and can conflict with Conditional Access. Surface interaction-required claims challenges back to the client instead of hiding them as generic server failures.

Assign the correct Foundry identity

An agent identity is a specialized Entra service principal. Unpublished agents share a project-level development identity; publishing creates a distinct production agent identity. Permissions do not transfer automatically, so assign downstream roles to the published identity. At runtime, Agent Service obtains a scoped token for the target service; the audience is that service's resource identifier, not necessarily the MCP endpoint URL.

Apply Foundry RBAC at the narrowest useful scope. Foundry Agent Consumer is for invocation, Foundry User is for building and testing, and Foundry Project Manager supports project management and publishing. Prefer Entra authentication: resource keys provide coarse access and bypass these role distinctions. Role names may still appear under older Azure AI labels during rollout.

Treat MCP authorization as an explicit design

MCP defines tool discovery and invocation; it does not make a server trusted. For remote servers, choose no authentication only for intentionally public services. Otherwise use custom keys, custom OAuth, a user Entra token, project managed identity, or agent identity according to who must be authorized. A configured connection does not grant downstream permission by itself.

Toolbox can centralize credential injection, refresh, versioning, and policy behind an MCP-compatible endpoint. Allow-list required tools, require approval for risky writes, and log tool names, authorization outcomes, and approvals without logging tokens. Prefer managed identities or federated credentials to stored secrets.

For user-owned mail, files, or other delegated resources, choose supported user passthrough or OBO. For background jobs, use workload identity. When every published agent needs distinct permissions and audit, use its distinct agent identity. Use project managed identity only when all agents in that project should share the same Azure access after explicit risk review.

Practical identity checklist

Multitenant sign-in does not make every downstream exchange cross-tenant. Customer consent creates a service principal in the customer tenant, but Foundry's built-in OAuth identity passthrough requires the user's tenant to match the Foundry project tenant. Define tenant placement, administrator consent, issuer validation, and offboarding; use a validated custom OAuth design when built-in passthrough cannot meet the requirement.

Troubleshoot from the resource that rejected the request. A 401 usually points to a missing, expired, malformed, or wrong-audience token. A 403 usually means the identity is recognized but lacks permission, although service firewalls can also return 403. DNS failures, TCP timeouts, and private-endpoint routing errors are not repaired by adding RBAC.

Question	Production decision
Whose authority?	User: delegated OBO. Workload: managed or agent identity.
Correct token?	Validate issuer, audience, tenant, lifetime, scopes, and claims.
Correct principal?	Reassign target RBAC after publishing creates a new identity.
Tool governance?	Allow-list tools; approve side effects; broker shared credentials.
Cross-tenant?	Design consent and offboarding; built-in passthrough requires matching user and Foundry tenants.
Failure class?	Separate 401, 403, consent, DNS, firewall, routing, and timeout evidence.

Conclusion

Design identity before connecting tools. Ask who the downstream service should authorize, exchange tokens for the correct audience, and scope RBAC to the resulting principal. Validate consent, renewal, revocation, tool approval, and network reachability one hop at a time.

Announcing Windows Server vNext Preview Build 29683

StaceyCL_RM — Mon, 12 Oct 2026 18:29:27 GMT

Hello Windows Server Insiders!

Today we are pleased to release a new build of the next Windows Server Long-Term Servicing Channel (LTSC) Preview that contains both the Desktop Experience and Server Core installation options for Datacenter and Standard editions and Azure Edition (for VM evaluation only). Branding remains Windows Server 2025 in this preview - when reporting issues please refer to Windows Server vNext preview.

Build 29531 established a new Server preview baseline build. Please perform a clean install of Build 29531 (or later) using the installation media linked below.

Please note: Upgrades from Windows Server vNext preview builds older than 29531 are not supported. We encourage all Windows Server vNext preview users to perform a clean install using 29531 or later to successfully upgrade to future Windows Server vNext preview builds.

While upgrades from earlier Windows Server previews (Build 26525 and older) are not technically blocked by setup.exe, a number of known issues have been identified related to upgrades necessitating the establishment of a new baseline build for our Server vNext Preview Program.
The new baseline build (29531) will not be Flighted due to upgrade issues. Flighting support resumed with preview build 29550 or later.

What's New

[NEW] Introducing MSHardenedPolicyEval: Evaluating new default hardened security settings on Windows Server Core

Windows Server Core ships with a broad set of security-related configuration options spanning authentication, credential protection, cryptography and TLS, auditing, event logging, exploit mitigations, networking, PowerShell, printing, remote management, SMB, UAC, firewall policy, and more. Knowing whether a given machine is actually configured to the new default hardened values for all of these areas — and getting it there consistently — has traditionally required stitching together multiple tools and manual checks. MSHardenedPolicyEval.exe is a new built-in command-line tool that consolidates this into a single, authoritative mechanism. It evaluates the current machine state against a curated catalog of hardening policies spanning the registry, Local Security Authority (LSA) rights and SID assignments, audit subcategories, and SAM settings, and reports a per-group and overall hardening score. It can also apply the hardened values directly, or revert them back to their Windows Server 2025 defaults, making it useful both as a standalone assessment tool and as the mechanism behind scheduled hardening tasks on the system.

The tool exists to give administrators and Insiders a transparent, scriptable way to answer "how hardened is this server, and in what areas am I falling short?" without having to manually inspect dozens of registry keys, audit policies, and LSA settings. Because the same policy tables drive evaluation, apply, and revert, there's no drift between what's measured and what's enforced — a setting that counts toward your score is exactly the setting -ap will configure. Scores and policy bitmasks can be surfaced through the Windows event log and, optionally, TraceLogging, so the results are consumable by monitoring and telemetry pipelines rather than only by someone watching a console.

For supported usage: %SystemRoot%\System32\MSHardenedPolicyEval.exe must be run from an elevated administrator prompt and only runs on Windows Server SKUs. Running it with no arguments performs a read-only evaluation.

-v for verbose per-group and overall scores

-ap [selectors] to apply hardened values

-rp [selectors] to revert to non-hardened values

Omit the selector list to act on every supported group, or target specific categories/groups (e.g., -ap registry, -rp Printing, or -ap Audit,LSA) using comma-, semicolon-, or vertical-bar-separated, case-insensitive selectors.

-l [path] persists output to a log file (defaulting under %SystemRoot%\System32\LogFiles\MSHardenedPolicyEval\)

-t emits scores via TraceLogging

Note: Keep in mind that applying or reverting policy can require a reboot before the change is fully in effect, and some operations affect security-sensitive configurations — review the selectors you intend to use before running -ap / -rp broadly in critical environments.

Feedback Hub app is available for Server Desktop users!  The app should automatically update with the latest version, but if it does not, simply Check for updates in the app’s settings tab.

Known Issues

A race condition in the TLS hybrid key exchange implementation may cause the LSASS service to crash when hybrid groups are negotiated by a TLS server. To avoid this issue until the fix is released, please disable hybrid groups (X25519_MLKEM768, SecP256r1_MLKEM768, SecP384r1_MLKEM1024) using TLS cmdlets or Group Policy, as outlined here.

Server Core Upgrades and AppCompat FOD: Enabling AppCompat FOD after reinstall may fail due to legacy 3rd-party license compatibility issues on Server Core devices. Server Core users may be unable to install the latest AppCompat FOD after upgrading to build 29574. This appears to be limited to Server Core installations with 3rd-party application licenses that fail compatibility checks after upgrade. This will be addressed in a future build.

Upgrading from older builds of Windows Server vNext previews (26525 or older) are not supported. Please perform a clean install of build 29531 or later. Users may experience failures when attempting to upgrade from earlier previews (build 26525 and older). VMs may fail to upgrade or start after upgrade from older preview builds impacting live migration and failover cluster scenarios.

Download Windows Server Insider Preview (microsoft.com) Flighting: The label for this flight may incorrectly reference Windows 11. However, when selected, the package installed is the Windows Server vNext update. Please ignore the label and proceed with installing your flight. This issue will be addressed in a future release.

Available Downloads

Downloads to certain countries may not be available. See Microsoft suspends new sales in Russia - Microsoft On the Issues.

Windows Server Long-Term Servicing Channel Preview in ISO format in 18 languages, and in VHDX format in English only. 
Windows Server Datacenter Azure Edition Preview in ISO and VHDX format, English only.
Microsoft Server Languages and Optional Features Preview

 Keys: Keys are valid for preview builds only 

Server Standard: MFY9F-XBN2F-TYFMP-CCV49-RMYVH
Datacenter: 2KNJJ-33Y9H-2GXGX-KMQWH-G6H67
Azure Edition does not accept a key.

Symbols:  Available on the public symbol server – see Using the Microsoft Symbol Server. 

Expiration: This Windows Server Preview will expire October 15, 2027.

How to Download

Registered Insiders may navigate directly to the Windows Server Insider Preview download page. If you have not yet registered as an Insider, see GETTING STARTED WITH SERVER on the Windows Insiders for Business portal.

We value your feedback!

The most important part of the release cycle is to hear what's working and what needs to be improved, so your feedback is extremely valued. Please use the new Feedback Hub app for Windows Server if you are running a Desktop version of Server. If you are using a Core edition, or if you are unable to use the Feedback Hub app, you can use your registered Windows 10 or Windows 11 Insider device and use the Feedback Hub application.  In the app, choose the Windows Server category and then the appropriate subcategory for your feedback. In the title of the Feedback, please indicate the build number you are providing feedback on as shown below to ensure that your issue is attributed to the right version:

     [Server #####] Title of my feedback

See Give Feedback on Windows Server via Feedback Hub for specifics.

The Windows Server Insiders space on the Microsoft Tech Communities supports preview builds of the next version of Windows Server. Use the forum to collaborate, share and learn from experts.  For versions that have been released to general availability in market, try the Windows Server for IT Pro forum or contact Support for Business.

Diagnostic and Usage Information

Microsoft collects this information over the internet to help keep Windows secure and up to date, troubleshoot problems, and make product improvements. Microsoft server operating systems can be configured to turn diagnostic data off, send Required diagnostic data, or send Optional diagnostic data. During previews, Microsoft asks that you change the default setting to Optional to provide the best automatic feedback and help us improve the final product.

Administrators can change the level of information collection through Settings. For details, see http://aka.ms/winserverdata. Also see the Microsoft Privacy Statement.

Terms of Use

This is pre-release software - it is provided for use "as-is" and is not supported in production environments. Users are responsible for installing any updates that may be made available from Windows Update. All pre-release software made available to you via the Windows Server Insider program is governed by the Insider Terms of Use.

Help.microsoft.com talk to a person

kiosd — Mon, 12 Oct 2026 17:58:45 GMT

You can call Microsoft Tech Support directly at (I‑888 MICROSOFT 394 2105) for immediate assistance with a live representative. you can follow these steps:

Connect With a Live Agent
Direct Contact (I‑888 MICROSOFT 394 2105)
You can chat live or request a callback.
Follow the on‑screen prompts to start a live chat, Alternatively, select Call me back and provide your details
Launch the Get Help App
This app is built into Windows and connects you to Microsoft support. (I‑888 MICROSOFT 394 2105)
Press Windows key → type Get Help → open app
Enter 'Chat with an agent' in the search box, Hit Enter to proceed
Navigate to Support Options
The app provides a support button for further assistance. (I‑888 MICROSOFT 394 2105)
Scroll down and click the Support button, Select the product category (Xbox, Office, Outlook, etc.)
Choose Your Product or Service
Selecting the right category ensures you’re routed correctly.
Pick the product or service you need help with
Confirm your selection to continue

What’s new in Microsoft Entra: October 2026

Yina Arenas — Mon, 12 Oct 2026 17:25:18 GMT

Over the last few months, I've spent a lot of time with customers and our teams on one of the biggest security shifts ahead of us: securing an enterprise where people and AI agents are both acting on behalf of the business.

It’s a challenge shaping Microsoft's approach to Secure AI. And while AI makes the challenge urgent, the underlying problem is broader. Organizations need to give more people, applications, workloads, and agents access to more resources, while maintaining control without adding more friction and complexity.

Identity and network access are at the center of the transition.

Customers are clear about what they need. Across my conversations with identity and network access leaders and practitioners, and through our ongoing customer research, four outcomes consistently rise to the top:

Keep my organization trusted and resilient
Give users and agents secure access without friction
Reduce the cost and complexity of access management
Adopt AI safely at enterprise scale

So, we're making a change to this blog.

Starting this month, we’re organizing “What’s New” around the outcomes you're trying to achieve, rather than around our product architecture. Our goal is to make the connection between what we're shipping, the challenges you’re having, and where we're headed much clearer. I welcome your feedback on this new approach in the comments.

What I'd pay attention to this month

We’re acting on your feedback with new capabilities that:

Continue to make access more adaptive. Universal Continuous Access Evaluation in Global Secure Access can now use additional user-risk and device-revocation signals, including when a device is deleted, disabled, or becomes noncompliant.
Strengthen how workloads establish trust. Service-to-service token binding uses mutual TLS proof of possession to cryptographically bind an access token to the workload that originated it.
Take complexity out of everyday identity operations. From a guided path to Cloud Sync to Microsoft-managed certificates for TLS inspection, several of this month's updates are about making stronger security easier to deploy and operate.

Here's everything new in Microsoft Entra since September.

Outcome: Keep my organization trusted and resilient

Device signals added to Continuous Access Evaluation (CAE) in Global Secure Access

Give hybrid users fast, seamless, and secure access with Universal Continuous Access Evaluation (CAE) in Global Secure Access. Universal CAE adapts access based on a user’s location, optimizing the experience on the corporate network while maintaining strong security controls. It now supports user-risk and device-revocation signals, including when a device is deleted, disabled, or becomes noncompliant.

Public Preview

Service-to-service token binding enabled for Entra tokens

This capability uses mutual TLS proof of possession (mTLS PoP) to cryptographically bind an access token to the originating workload. The initial release supports managed identity workloads running on Trusted Launch or Confidential VM/VM Scale Sets, using the latest compatible .NET libraries to access Azure Key Vault. Organizations can enable it in a controlled manner, validate it in preproduction, and expand by cohort.

General Availability

Outcome: Give users and agents secure access without friction

Improved device registration user experience for Windows

When users access resources through supported native applications protected by Microsoft Entra Conditional Access policies that require token protection, they may need to register their device before access is granted. The improved experience lets users complete registration directly during sign-in—without navigating a separate workflow.

General Availability

Streamline access request workflows for users in ServiceNow

Users can request access packages and view their request history directly in ServiceNow. Designated approvers can review and approve or deny requests without leaving ServiceNow. Access packages, policies, and approver assignments remain centrally managed in Microsoft Entra ID Entitlement Management, combining a streamlined user experience with consistent governance.

General Availability

Enable B2B guest access with Global Secure Access

Guest users can connect through Global Secure Access while signed in to their home organization’s Microsoft Entra ID account. The client detects partner tenants where the user is a guest and offers an option to switch to the customer tenant context. Private traffic is then routed through the customer’s Global Secure Access service for secure, streamlined access.

Public Preview

Outcome: Reduce the cost and complexity of access management

Simplify migration from Microsoft Entra Connect Sync to Microsoft Entra Cloud Sync

The guided migration tool gives eligible organizations a structured path from Microsoft Entra Connect Sync to Microsoft Entra Cloud Sync. It brings key activities into one workflow: assessing readiness, setting up the provisioning agent and Cloud Sync configuration, activating Cloud Sync through a controlled transition, and validating the environment after activation.

General Availability

Move SAP SuccessFactors Provisioning to Workload Identity-based authentication

Microsoft Entra now supports Workload Identity-based authentication for SAP SuccessFactors provisioning, replacing long-lived usernames and passwords with Entra-managed credentials and short-lived, standards-based access tokens. Customers can upgrade authentication in place on existing provisioning jobs, without recreating or restarting them. This helps organizations move to a more secure model ahead of SAP SuccessFactors’ planned deprecation of basic authentication for its APIs in November 2026. The option supports inbound provisioning to Active Directory and Microsoft Entra ID, as well as writeback scenarios, while reducing manual credential handling and rotation.

Public Preview

Clear null or empty attribute values within Microsoft Entra provisioning

Microsoft Entra provisioning can now clear an existing target attribute when the corresponding source attribute is null or empty. Also known as null-value provisioning, this capability keeps target systems synchronized when values are removed from the system of record. It is available for API-driven inbound provisioning, Workday inbound user provisioning, and SAP SuccessFactors inbound user provisioning to Microsoft Entra ID and on-premises Active Directory.

Public Preview

Generate unique aliases with custom call-outs

Use custom call-outs with Azure Logic Apps during user provisioning to perform advanced attribute transformations for your organization. For example, custom call-outs can generate unique employee aliases. They are supported for create events in HR inbound, SaaS outbound, and cross-tenant synchronization provisioning flows in Microsoft Entra.

Public Preview

Discover and govern application groups and memberships

Microsoft Entra ID Governance can now discover groups and group memberships in connected applications. Administrators can identify local or orphaned groups without a matching Microsoft Entra object, as well as groups and users without a corresponding application assignment in Microsoft Entra ID. This helps organizations reconcile access, investigate potentially unauthorized access, and identify groups that should be governed through Microsoft Entra ID Governance.

Public Preview

Gain efficiency with Microsoft-managed certificates for TLS inspection in Global Secure Access

Previously, TLS inspection required customers to provision and manage their own certificates and trust chains. With Microsoft-managed certificates, Microsoft provisions the inspection certificate, removing the need for customers to operate their own certificate authority or public key infrastructure to use TLS inspection.

Public Preview

Outcome: Adopt AI safely at enterprise scale

AI is changing the security problem.

For decades, much of identity and access has been built around understanding who is requesting access, what they should be allowed to do, and under what conditions. Now we need to answer those same questions for AI agents that can reason, act, use tools, access data, and operate on behalf of people and organizations.

That's why Secure AI is an area I'm personally spending a lot of time on across Microsoft.

I believe the answer has to start with visibility and control. Organizations need to know what agents exist, understand what they can access and do, contain them within appropriate boundaries, and continuously adapt those protections as the agent, its context, and its risk change.

Identity and network access are foundational to that system, but they're not sufficient on their own. Securing AI will require us to connect identity, access, network, endpoint, data, application, and runtime signals with the ability to act when risk changes.

At Microsoft Ignite, November 17–20, we'll share much more about how we're approaching this across Microsoft, including the role Microsoft Entra and Agent 365 will play.

This is one of the areas I'm most excited about, and one you'll hear much more about from me.

Onwards,

Yina Arenas

CVP and Chief Product Officer of Identity and Network Access

Follow me on LinkedIn

Learn more about Microsoft Entra

Secure access for people and agents to AI, applications, and resources with comprehensive identity and network access solutions.

Qwen3.8-Flash-Next on two H100s in an Azure Spot VM

Wuyi_Weng — Mon, 12 Oct 2026 17:05:45 GMT

With 150,000 tokens of context, one request to Qwen3.8-Flash-Next decoded at about 200 tokens a second, and its first token arrived in under a second, because 95% of the prompt came from the cache. That held while the agents kept up to five requests running at once. At seven, one request in twenty waited 23 seconds or more for its first token. No error explained it; the dashboard did, one panel after another.

This post covers how to run the model on two H100 GPUs in one Azure VM and how to observe it: which signals matter for this kind of model, three places where a standard dashboard misreads it, and one serving flag that made a measurable difference. My previous post, Qwen3.8-27B on a $2 H100 Azure Spot VM: does it pay off?, walks through the base setup (the VM, the Compose stack, the LiteLLM gateway and the OpenTelemetry pipeline into Application Insights and Grafana) in more detail; here I focus on what changes for a bigger model.

What you're running

Qwen3.8-Flash-Next is a mixture-of-experts (MoE) model from Qwen, released in August 2026 under the qwen-community-1.0 license. A few of its properties shape how you serve it:

125B parameters, 6B active per token. Each token passes through a small share of the experts, so decoding reads far less than the full weights.
Mostly linear attention. Its 48 layers come in 12 blocks of three Gated DeltaNet layers, which keep a fixed-size state, and one Qwen Sparse Attention layer. Only those 12 sparse-attention layers keep a per-token KV cache.
A 51B n-gram embedding table (20 million bigram and trigram entries), which vLLM keeps in host memory on H100 GPUs.
A multi-token prediction (MTP) layer for speculative decoding, a 262,144-token context window (extendable to about one million with YaRN), and vision input.
Thinking on by default, with a reasoning_effort setting (xhigh by default, or medium or low).

Qwen's FP8 checkpoint, Qwen/Qwen3.8-Flash-Next-FP8, is 185.6 GB, too much for one 94 GB H100 even with the n-gram table in host memory. Split across two with tensor parallelism, it fits with room left for the KV cache:

Per GPU	GiB
Weights, n-gram table excluded, split in two	65.6
vLLM's share of the GPU at `--gpu-memory-utilization 0.90`	~84
Left for the KV cache, activations and CUDA graphs	~18

Why not 4-bit weights?

FP4 weights would save memory, but on an H100 they can be slower. The H100's tensor cores compute in FP8, not FP4, which arrived with Blackwell. NVIDIA publishes an NVFP4 checkpoint of this model, 132.7 GB, quantized for and tested on B200 and B300 GPUs, under the NVIDIA Open Model License in addition to Qwen's. vLLM v0.31.0 still loads it on an H100 by falling back to a Marlin kernel, which keeps the expert weights in 4 bits and unpacks them to BF16 for each matrix multiplication. That saves memory, not compute: the experts then multiply in BF16, whose peak rate on an H100 is half that of FP8.

In that checkpoint, only the routed experts are FP4. Attention, the shared experts and the other layers stay in BF16, and the n-gram table and the MTP layer stay in FP8. My estimate from its file sizes:

	FP8 (this post)	NVFP4 on H100 (estimate)
Weights on the GPUs, n-gram table excluded	131 GiB	~76 GiB
On one H100	Doesn't fit	Only just: a few GiB left for the KV cache, about one long agent session
KV cache on two H100s	1.5 million tokens, FP8 cache	About three times as much
Expert matrix math	FP8 tensor cores	BF16, after unpacking the weights

Which way it goes depends on the workload. Decoding mostly reads weights, so smaller weights can keep it fast. Prefill is mostly math, and coding agents send long prompts, so a slower prefill shows up as a longer wait for the first token whenever the cache misses. A cache three times larger would miss less often. I haven't measured this trade; if you try it, the panels later in this post show it, with time to first token and computed prefill set against the prefix-cache hit rate. For one GPU today, see the one-GPU alternative near the end of this post.

Step 1: Get a two-GPU Spot VM

The size is Standard_NC80adis_H100_v5: two H100 NVL GPUs with 94 GB each, 80 vCPUs and 640 GiB of memory. On October 12, 2026 it cost $3.22 an hour as an Azure Spot Virtual Machine in UK South, against $17.45 at the pay-as-you-go price: about 80% less, for capacity that Azure can take back with 30 seconds' notice (prices change; check the pricing page). In the two regions I compared, the Spot price was exactly twice the one-GPU size's.

Spot draws on your regional low-priority vCPU quota. This size takes 80 vCPUs of it, which in my subscription left no room in the same region for the one-GPU VM from the previous post. Plan for evictions: my two VMs of this size in UK South zone 2 ran 6 h 17 min and 6 h 30 min before Azure reclaimed them. Both kept their disks under the Deallocate eviction policy, so a restart in place reloads the model from disk in a few minutes.

The sample's infra/provision-spot-vm.sh creates this size, with the same private network as in the previous post: no public IP, outbound traffic through a NAT gateway, and administration through az vm run-command:

LOCATION=southeastasia ZONE=2 infra/provision-spot-vm.sh

Step 2: Prepare the host

The host bootstrap is the same as for one GPU: the data disk, the NVIDIA datacenter driver (595 branch), Docker and the NVIDIA Container Toolkit, in about four minutes. Then check how the two GPUs are connected, because tensor parallelism exchanges data between them in every layer:

$ nvidia-smi topo -m
        GPU0    GPU1    CPU Affinity    NUMA Affinity
GPU0     X      NV12    0-39            0
GPU1    NV12     X      40-79           1

NV12 means an NVLink bridge with 12 links. nvidia-smi nvlink --status lists 18 links per GPU, 12 active at 26.6 GB/s each and 6 inactive. Remember those six; they come back in the monitoring section.

Step 3: Serve it with vLLM

NVIDIA's NGC vLLM container that served the 27B predates this model, so the stack uses vLLM's own vllm/vllm-openai:v0.31.0 image, which knows the architecture and its MTP layer. The flags follow vLLM's recipe for this model, adjusted for two GPUs:

vllm serve /models/Qwen3.8-Flash-Next-FP8 \
  --served-model-name qwen3.8-flash-next-vllm \
  --tensor-parallel-size 2 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 32 \
  --max-num-batched-tokens 16384 \
  --enable-prefix-caching \
  --kv-cache-dtype fp8 \
  --attention-config.indexer_kv_dtype fp8 \
  --moe-backend triton \
  --no-enable-flashinfer-autotune \
  --spec-method mtp --spec-tokens 3 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder

Flag	Why
`--tensor-parallel-size 2`	Splits every layer across the two GPUs.
`--gpu-memory-utilization 0.90`	Under load each GPU reached 92 of 96 GB at this setting, so I left it there.
`--kv-cache-dtype fp8`, `--attention-config.indexer_kv_dtype fp8`	Stores the KV cache, and the sparse-attention indexer's, in FP8. The recipe's H100 command leaves these out; its H200 command, also a Hopper GPU, includes them. Why I added them is the subject of One flag, measured, below.
`--moe-backend triton`, `--no-enable-flashinfer-autotune`	The recipe's MoE kernels for Hopper GPUs.
`--spec-method mtp --spec-tokens 3`	Speculative decoding with the model's MTP layer.
`--reasoning-parser qwen3`, `--tool-call-parser qwen3_coder`	Thinking returned separately from the answer, and OpenAI-style tool calls.

Two container settings matter as well. vLLM pins each GPU's share of the n-gram table in host memory, so the container needs ulimits: memlock: -1, and the two tensor-parallel workers communicate through shared memory, so it needs ipc: host.

On a new VM, the download takes about 20 minutes and loading about 4 more. The startup log then tells you the two numbers that decide everything later:

Model loading took 65.58 GiB memory
GPU KV cache size: 1,506,691 tokens, Maximum concurrency for 262,144 tokens per request: 5.75x

Step 4: Check it

The smoke test from the previous post (an exact answer, a required tool call and a decode-speed run) passes, and one request generates 260 tokens a second with thinking off, against 166 for the 27B on one GPU. A 45-case basic evaluation (math and logic with and without thinking, knowledge, instruction following, generated code run against tests, tool calls, and needle retrieval at 30K and 120K tokens) scores 44 of 45, the same as the 27B. An agentic coding evaluation on 10 short Terminal-Bench 2.0 tasks solved 8.

Step 5: Observe it

The telemetry pipeline is the one from the previous post: an OpenTelemetry Collector on the VM scrapes vLLM, LiteLLM and NVIDIA's DCGM exporter, reads host and container statistics, receives LiteLLM's spans and tails the container logs, and sends all of it to Application Insights, which stores the metrics in an Azure Monitor workspace as Prometheus data. Grafana reads both. Two things changed for this model.

One dashboard for several models

The collector stamps every metric, span and log record with an upstream_model label naming the model the VM serves. A model variable at the top of the dashboard filters every panel by it and lets you pick one model, several or all. With more than one, each graph draws a line per model, so the 27B and Flash-Next appear side by side.

Two details made it work. The Azure Monitor workspace's label-values API requires exactly one metric name, so the variable's query is label_values(vllm:num_requests_running, upstream_model). And the VM's cost is now computed from the GPUs reporting in each minute times a price per GPU-hour, so a one-GPU and a two-GPU model are both costed correctly from one price.

Three numbers the dashboard got wrong at first

Per-request speed. The usual formula, 1 / histogram_quantile(0.5, ...inter_token_latency_seconds...), read a constant 57 tokens a second on this model while requests were really getting 150 to 260. Two things go wrong at once. With speculative decoding, vLLM records one inter-token interval per decode step, and each step produced about 2.4 tokens. And 99.7% of the steps landed in the histogram's 10–25 ms bucket, so the median is that bucket's midpoint, 17.5 ms, whatever the real speed. I used the same formula in the previous post's table; this one holds up better:

(sum(rate(vllm:generation_tokens_total[5m])) > 0)
  / clamp_min(sum(avg_over_time(vllm:num_requests_running[5m])), 1)

That's output tokens per second divided by the requests running. The clamp_min matters because the collector samples the running-request gauge every 15 seconds and misses short requests that start and end between samples. Without it, a minute of short requests read up to 668 tokens a second.

GPU health. DCGM's health check reported Fail on a healthy VM. Its NVLink watch reports the six inactive links on each GPU as down (dcgm_fr_nvlink_down), while the bridge's 12 links are up. The dashboard's health tile now leaves that one error code out, which leaves the Warn that power throttling raises under normal load.

Histogram means. OTLP histograms arrive in the Azure Monitor workspace as native histograms. histogram_quantile works on them, but histogram_sum, histogram_count and histogram_avg returned 0 or NaN for these metrics, so averages come from counter rates, as above, rather than from the histograms.

The panels that matter for this model

Question	PromQL
Are requests waiting, and for what?	`sum by (reason) (vllm:num_requests_waiting_by_reason)`: `capacity` means the KV cache is full
Is the KV cache holding the sessions?	`max(vllm:kv_cache_usage_perc)`, and the prefix-cache hit rate `sum(rate(vllm:prefix_cache_hits_total[5m])) / sum(rate(vllm:prefix_cache_queries_total[5m]))`
Is the GPU recomputing prompts?	`sum(rate(vllm:prompt_tokens_by_source_total{source="local_compute"}[5m]))` against `{source="local_cache_hit"}`, and `sum(increase(vllm:num_preemptions_total[5m]))`
How far does speculative decoding get?	`sum by (position) (rate(vllm:spec_decode_num_accepted_tokens_per_pos_total[5m])) / scalar(sum(rate(vllm:spec_decode_num_drafts_total[5m])))`
What crosses the PCIe bus?	`sum(dcgm_fi_prof_pcie_rx_bytes)`, host to GPU in bytes per second

The spans complete the picture. Each LiteLLM call carries its input and output tokens, time to first token, duration and finish reason, so decode speed per call is output tokens / (duration - time to first token), and you can group calls by prompt size. The spans also record each tool the client declares, which tells different agents apart without capturing a single prompt.

Load it with coding agents

A benchmark sends synthetic prompts at a fixed rate. Agents don't: their prompts grow with every turn, most of each prompt is the previous turn's, and between turns they run tools while the model waits. To see the model under that shape of load, I ran opencode, an open-source coding agent, as a load generator: one instance per local repository, each asked to review every file.

Agents that can edit files and run commands shouldn't be pointed at a dozen repositories for a load test, so every instance ran with an inline configuration that limits it to read-only tools. Passed in OPENCODE_CONFIG_CONTENT, it overrides the global and project opencode config files; only managed settings rank higher. The sample's load-test/review-readonly.json is a copy of the one I ran that also defines the gateway as an OpenAI-compatible provider and keeps agents away from .env files:

{
  "provider": {
    "litellm": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LiteLLM gateway",
      "options": { "baseURL": "{env:LOCAL_LLM_URL}/v1" },
      "models": { "local-llm": { "name": "local-llm", "limit": { "context": 245760, "output": 16384 } } }
    }
  },
  "model": "litellm/local-llm",
  "small_model": "litellm/local-llm",
  "permission": {
    "read": { "*": "allow", "*.env": "deny", "*.env.*": "deny", "*.env.example": "allow" },
    "glob": "allow", "grep": "allow", "list": "allow", "todowrite": "allow",
    "edit": "deny", "bash": "deny", "webfetch": "deny", "websearch": "deny",
    "external_directory": "deny", "question": "deny", "task": "deny", "doom_loop": "deny"
  },
  "mcp": { "playwright": { "enabled": false } },
  "lsp": false,
  "formatter": false,
  "snapshot": false,
  "autoupdate": false,
  "share": "disabled"
}

List your own MCP servers under mcp the same way. To run one agent by hand:

export LOCAL_LLM_URL=https://<your-domain>.ngrok-free.dev
export OPENCODE_CONFIG_CONTENT="$(cat load-test/review-readonly.json)"
cd ~/src/some-repo && opencode run --pure -m litellm/local-llm "Review every file in this repository."

The sample's load-test/launch.sh starts one per folder you list, a few seconds apart, and stops launching when the workstation runs low on memory.

Check it in a scratch folder first: ask an agent to create a file and run a command. In my test the agent wasn't offered those tools, and the folder stayed unchanged.

Three settings in it matter beyond safety. The context limit tells opencode when to compact the conversation; without it, sessions grew until the gateway rejected them as too long. Denying task stops an agent from starting sub-agents, so each instance is one session; with sub-agents allowed, 29 instances had 69 requests in flight. And each instance took 0.7–0.9 GB of memory on my workstation, so the workstation, not the GPU, capped the first run at 46 agents.

What the telemetry showed

Decode speed barely depends on context length

From the spans, here is the median decode speed of calls with at least 300 output tokens, by prompt size, next to the 27B's from the previous post's busy window:

Prompt size	Flash-Next, 1–2 requests at once	Flash-Next, 3–5 at once	27B, about 3 at once
Under 50K tokens	197–221	201	60–78
50–100K	192	183	63
150–200K	217	200	54
Over 200K	195	166	51

The 27B slowed by about a fifth as its prompts grew; Flash-Next held its speed. The architecture explains it: 36 of its 48 layers keep a fixed-size state, and the other 12 use sparse attention, so the work per token grows little with the context.

The n-gram table shows up on the PCIe bus

With the model decoding, DCGM reported 4.6–8.6 GB/s flowing from host to GPU over PCIe, rising and falling with the output rate and dropping to almost nothing when idle. On the 27B, which keeps everything in GPU memory, the same counter read 0.03 GB/s. The n-gram table is the part of this model that lives in host memory, so it's the likely source. That's at most an eighth of what the GPUs' PCIe 5.0 x16 links carry, so it isn't a bottleneck at this load, but it's worth a panel if you run more requests at once.

Sessions, not requests, fill the KV cache

Agentic traffic is mostly reused prompt. For hours, 88–95% of input tokens came from the prefix cache, and time to first token stayed under a second at 100,000 tokens and more. vLLM keeps each session's prompt in the cache between turns, so the next turn only processes what's new.

That works only while every active session's prompt fits, including the sessions that are between turns, running tools. With the KV cache in BF16, the cache held 840,277 tokens. Here is what happened when the agents went from five requests running at once to seven, with prompts of about 110,000 tokens at the median and up to 230,000:

15 minutes to (UTC)	Requests running, peak	KV cache, peak	Prefix-cache hits	Input recomputed	Preemptions	Time to first token, p50 / p95
04:15	5	72%	91%	2.1M tokens	0	0.7 s / 2.7 s
04:30	7	97%	45%	9.0M tokens	4	1.4 s / 25.5 s
04:45	7	98%	50%	6.8M tokens	2	3.9 s / 23.2 s
05:00	7	99%	74%	5.2M tokens	24	0.6 s / 14.5 s

At no point did vLLM run more than seven requests, against a limit of 32. The limit that mattered was memory: the sessions evicted each other's cached prompts, and each turn recomputed 100,000 tokens or more. The waiting-requests metric says so directly: up to four requests at a time waited, all with the reason label capacity.

One flag, measured

The KV cache in FP8 takes half the memory per token. With --kv-cache-dtype fp8 and --attention-config.indexer_kv_dtype fp8, the cache grew from 840,277 to 1,506,691 tokens in the same memory, and from 3.2 to 5.75 full-length contexts. The weights don't change, and neither did the checks: 260 tokens a second for one request and 44 of 45 on the evaluation, including both long-context retrievals.

Then I repeated the load on a fresh VM with eight of the read-only review agents described above, one session each. Their prompts grew to a median of 122,000 tokens and up to 235,000, a little larger than in the BF16 window. Measured the same way for both windows:

	BF16 cache, 04:15–05:00	FP8 cache, 07:23–07:38
Requests running, average / peak	3.3 / 7	6.4 / 8
Prompt size, p50 / max	112K / 229K	122K / 235K
KV cache, peak	99%	88%
Prefix-cache hits	58%	74%
Preemptions	30	0
Time to first token, p50 / p95 / max	0.9 s / 23.8 s / 42.2 s	1.1 s / 11.0 s / 20.7 s
Output tokens per second, all requests	219	415

Twice as many requests ran at once, the cache never filled, nothing was preempted, and the slowest first tokens arrived in half the time. The hit rate didn't climb back to 90%: review agents read new files on every turn, and no cache can serve tokens it hasn't seen. The two windows come from different agents, so take the comparison as indicative rather than exact; the cache panels tell the same story.

Past the cache

More agents don't help once the cache is full. With 46 agents on the FP8 cache, 21 requests ran and 24 waited for capacity, the cache stayed 97% full, and the prefix-cache hit rate fell to 0%. The GPUs spent their time on about 12,000 tokens a second of recomputed prompts against 400–450 of output, and the median time to first token passed 30 seconds.

Stopping the agents didn't free the server right away either. Their disconnects didn't make it through the gateways to vLLM, which worked through the 35 requests the agents had left queued, a few minutes of work for nobody, before the next test could start.

Rules of thumb

Size by sessions, not requests. The number of agent sessions that stay cached is roughly the KV cache size divided by a typical session's context: about 1.5 million / 100,000–150,000, so 10 to 15 here. The startup log gives you the first number, and the spans give you the second.
Watch why requests wait. vllm:num_requests_waiting_by_reason{reason="capacity"} rising means memory, which --max-num-seqs won't fix.
Read prefix-cache hits and recomputed input together. A falling hit rate with rising computed input is the cache thrashing, and time to first token follows within minutes.
Mind the thinking. 87–94% of output tokens were reasoning. For routine tool calls, a lower reasoning_effort is the client-side lever.

The one-GPU alternative

If one H100 is all you have, Strata, an open-source engine built for this model on consumer GPUs, runs Unsloth's ~4-bit GGUF on a single H100 NVL with every expert in GPU memory: 151 tokens a second for one request, 44 of 45 on the same evaluation and 9 of 10 agentic tasks. Concurrency is where it differs from vLLM: in version 0.1.42, four batch slots added only about 20% (177 tokens a second in total), and under the evaluation's mixed concurrent load they started failing requests, so I ran it one request at a time. Check newer releases if you need concurrency.

Try it

Sample code: wuyi-labs/2610-h100-qwen-38-flash-next, with provisioning, the vLLM Compose stack, the dashboard and the read-only opencode load test.
The model: Qwen3.8-Flash-Next on Hugging Face and vLLM's recipe for it.
The base setup: Qwen3.8-27B on a $2 H100 Azure Spot VM: does it pay off?, and Ingest OTLP data into Azure Monitor with the OpenTelemetry Collector.
KV cache quantization: Quantized KV cache in vLLM.
Load generation: opencode and its permissions.
Spot: Azure Spot Virtual Machines and Linux VM pricing.

Cowork Not Allowing Extensive Usage

castewa88 — Mon, 12 Oct 2026 16:51:02 GMT

As a part of the Copilot app updates, Tasks is becoming Cowork (https://support.microsoft.com/en-us/microsoft-365-copilot/learning/changes-microsoft-copilot-app). This support page (https://support.microsoft.com/en-us/microsoft-365-copilot/ai-credits-and-limits-for-microsoft-365-subscriptions) states that my subscription level includes "Extensive usage" for Cowork.

I have been using Tasks seemingly without limit since that feature was introduced. I recently began to familiarize myself with the new Cowork, and in only a few hours of exploring how it worked, I ended up with a message that I had "reached your monthly Cowork limit". At the beginning of the day on October 9 I had never used Cowork, and at the end of the day I was told to wait until November 1 to use it again.

Unable To Check Status of AI Limits & Credits

castewa88 — Mon, 12 Oct 2026 16:46:04 GMT

I am a Microsoft 365 Premium subscriber.

This support page (https://support.microsoft.com/en-us/microsoft-365-copilot/ai-credits-and-limits-for-microsoft-365-subscriptions) states "You can check the status of your limits and AI credits by selecting Services & subscriptions in your Microsoft account." However, there is no information about limits or credits listed for my account or subscription.

I've had two support chats (#7110092832 and #7110147952) about this over the weekend that lasted 2 HOURS. The technicians were not able to figure out why the information wasn't available for my account. They also were not able to tell me any more details about my limits, credits, or usage. The first chat ended by telling me to just try again in 24 hours, and the second ended by directing me to look for help in this forum.

Where can I see my limits and used/remaining credits?

A secure Azure landing zone for AI: private endpoints, managed identity, APIM token limits (Bicep)

GisliGudmundsson — Mon, 12 Oct 2026 16:33:19 GMT

I wrote up a reference pattern for running Azure AI Foundry workloads inside a secure landing zone: Foundry (AIServices) behind a private endpoint with the three required private DNS zones, local auth disabled in favour of managed identity, and Azure API Management in front using llm-token-limit and llm-emit-token-metric to control and measure token usage.

Article: https://gisli78.substack.com/p/a-secure-azure-landing-zone-for-ai

Code (Bicep, with automated tests): https://github.com/gislig/azure-ai-landing-zone

Feedback welcome, especially from anyone running this pattern in production.

#mvpbuzz #azure #azug #microsoft

Problemas con Copilot.

milagros0591 — Mon, 12 Oct 2026 16:30:12 GMT

Desde hace un par de días adquirí una suscripción de Microsoft 365 personal para usar Copilot en las apps de Office, en la aplicación Office de Excel me dice que "Alcance mi límite de preguntas por hoy", en Word que "No está disponible para mi región", en la app de Window, "no me muestra el chat" y en la app móvil que "mi dispositivo no es compatible para esa versión".

rss.livelink.threads-in-node

Windows 11 forces PIN validation on boot for Edge, Teams and Phone Link

Call for perspectives: Endpoint Management Experiences of IT Professionals Survey

Call for perspectives: Endpoint Management Experiences of IT Professionals Survey

The New Microsoft Copilot:

What we covered

A new Microsoft Copilot experience

Code: turning ideas into working solutions

Where does AI-generated code actually run?

Autopilot: AI that continues working

As AI becomes more capable, cost management matters too

Control, measure and optimize

Control

Measure

Optimize

A useful way to think about what comes next

Watch the full webinar

Learn more

Microsoft Edge Enterprise — Intermittent Blue Coat Proxy Authentication Prompt

New accessibility updates for Microsoft Certification exams

Preparing for a Microsoft Certification exam? Explore upcoming case study updates and new options for scheduling approved accommodations online.

A redesigned case study experience

More options for scheduling approved accommodations

Available now: Online scheduling for approved accommodations

Coming in 2027

What certification candidates should know

Multiple pinned Copilot chats disappeared and continue disappearing

Understand your Azure backup estate, from protection flow to reviewed change

Watch the Backup Manager tour

Start with one completed analysis

Follow the protected item through policy and vault

Keep unknown sources separate from protection gaps

Work the failure cluster, then verify each item's recovery point

Review retention without confusing a model with a policy edit

Turn vault posture into a specific control decision

A proposal is not an Azure operation

Protection coverage is not recovery assurance

Read cost as measured, estimated, and apportioned evidence

Use Fleet to choose the next review

Keep review evidence without confusing Cleanup with backup deletion

How it's judged

Try it read-first

Fabric and Databricks Together

Use metadata mirroring with precise expectations

Conclusion

FinOps for Data and AI Workloads

Measure the complete workload

Match the execution contract to demand

Right-size shared capacity and AI requests

Protect performance with controlled experiments

Production decision checklist

Conclusion

Governance Boundaries in Microsoft Foundry

Why this matters

A five-boundary mental model

Separate control plane from data plane

RBAC guidance

Deployment governance is runtime governance

Policy, preview, and availability

Recommended operating pattern

Decision guide

Production checklist

Conclusion

Identity at Every Hop

Exchange tokens when user authority must travel

Conclusion

Announcing Windows Server vNext Preview Build 29683

Hello Windows Server Insiders!

What's New

[NEW] Introducing MSHardenedPolicyEval: Evaluating new default hardened security settings on Windows Server Core

Feedback Hub app is available for Server Desktop users! The app should automatically update with the latest version, but if it does not, simply Check for updates in the app’s settings tab.

Known Issues

Available Downloads

How to Download

We value your feedback!

Diagnostic and Usage Information

Terms of Use

Help.microsoft.com talk to a person

What’s new in Microsoft Entra: October 2026

What I'd pay attention to this month

Feedback Hub app is available for Server Desktop users!  The app should automatically update with the latest version, but if it does not, simply Check for updates in the app’s settings tab.