Microsoft Mission Critical Blog articles

Azure OpenAI Architecture: The Decisions That Actually Matter (Part 3)

luciacasucci — Wed, 17 Jun 2026 16:39:08 GMT

Introduction

Part 1 of this series tackled the architectural decisions that shape any Azure OpenAI / Microsoft Foundry Models workload — capacity model, deployment scope, governance layer, grounding strategy, and quota engineering. Part 2 turned those decisions into a Well-Architected Framework discipline. Part 3 looks at the part that makes GenAI architecture genuinely different from a traditional service: the platform itself never stops moving.

Models are released, promoted to GA, moved to Legacy, deprecated, and eventually retired. New regions come online; certain features (such as Priority Processing) light up only on specific model versions and deployment scopes. Fine-tuned models inherit the lifecycle of their base. Performance characteristics shift between releases. Reliability in this world is not just uptime — it is the ability to absorb continuous change without disrupting production.

That discipline is GenAIOps: the people, processes, and tooling that turn model upgrades from emergency events into routine operations. Part 2 already covers the core lifecycle mechanics and upgrade policy trade-offs through a Well-Architected lens. Part 3 stays focused on the operational and architectural practices that make change safe: evaluation of pipelines, observability, routing patterns, prompt governance, and abstraction. Where details are time-sensitive — stage thresholds, SLA windows, regional rollout delays, capacity tier eligibility — they are flagged with "At the time of writing". Always confirm current behavior against Microsoft Learn before committing to a design.

Who is this series for?

Cloud and Solution Architects
Platform and product owners
Senior developers responsible for operating Azure OpenAI workloads in production

What you’ll learn in Part 3:

How to build an evaluation pipeline that promotes model upgrades the way CI/CD promotes code.
How to instrument full-stack observability so regressions surface early (latency, errors, token trends, quality drift).
How the Model Router pattern, canary releases, and tier-aware fallbacks turn model change into a configuration concern.
How to govern prompts as production artifacts with versioning, feature-flagged rollouts, and regression testing.
How to manage lifecycle-dependent assets (fine-tuned models) and regional rollout realities without firefighting — plus a GenAIOps Decision Matrix you can reuse as a checklist.

We’ve also included a summary decision matrix at the end of this post for quick reference.

1. Model lifecycle (recap)

Azure OpenAI/Microsoft Foundry models are living dependencies: new versions are released, promoted from Preview to GA, then eventually move through deprecation toward retirement. To avoid surprises, treat every deployed model version as having an expiration date and design so you can swap versions without rewriting application code. In general, use the Standard deployment auto-upgrade mode that preserves stability but guarantees continuity at retirement, and plan to deliberate blue/green migrations for dedicated (provisioned) capacity where auto-upgrade is not available. For the deeper mechanics (upgrade modes, retirement behavior, and migration playbooks), refer to Part 2’s Reliability section; the rest of this article focuses on the GenAIOps practices that make those upgrades routine.

Figure 1 — Models lifecycle

2. GenAIOps: Evaluating Before Promoting

Upgrading a model should not be a manual, subjective exercise. Azure AI Foundry provides evaluation capabilities that, combined with a regression prompt suite, turn model upgrades into measurable, repeatable decisions:

Side-by-side prompt comparisons across model versions.
Automated quality scoring (relevance, coherence, groundedness, safety, and fluency).
Structured-output validation (JSON conformance, schema validation).
Batch testing across comprehensive prompt libraries representative of real production traffic.
Custom evaluation metrics tailored to your domain.

Architectural best practice:

Maintain a curated regression prompt suite that mirrors real production traffic — including the long tail.
Run evaluation pipelines against candidate models before any production cut-over.
Integrate evaluation into CI/CD using Azure DevOps, GitHub Actions, or similar automation.
Define quality gates that must pass before promotion (e.g., groundedness ≥ a target threshold, p95 latency under a target budget). Pick numbers that fit your workload, not the article.

Model promotion should require passing the evaluation gates the same way application code requires passing unit tests. Without automated evaluation, model upgrades become high-risk, low-visibility events that teams avoid until forced by retirement deadlines — the exact pattern that keeps lifecycle work in the "emergency" column instead of the "scheduled" column.

Example evaluation workflow:

Trigger — a new model version reaches GA, or your migration playbook hits the R-90 step.
Deploy — the candidate model goes to a staging deployment.
Regress — the prompt suite (typically several hundred to several thousand prompts) is run against the candidate.
Compare — the candidate's outputs are scored against the current production model.
Inspect — humans review flagged differences; metrics, latency distributions, and cost-per-request go on the dashboard.
Gate — an approval step (manual or automated) decides whether the candidate proceeds to blue/green production deployment.

Figure 2 — Evaluation Pipeline

3. Observability: Full-Stack or It Didn't Happen

GenAIOps is more than one-time evaluation. Once a candidate's model has been promoted, you need continuous, end-to-end observability across the request path — not just at the model boundary. Without it, you are operating blind during model transitions.

At a minimum, instrument:

Prompt processing time (gateway through model invocation).
Model inference latency, expressed as p50, p95, and p99 — averages hide the experience of the slowest 5% of users.
Token consumption (prompt tokens, completion tokens, total) trended over time.
Error rates by class (429 throttling, 503 service unavailable, 400 validation errors, content-filter rejections).
Model version distribution — which versions are actually serving traffic right now.
User-satisfaction signals (thumbs-up/down, explicit feedback, session abandonment).

Many performance regressions only surface at scale. A model version that performs well in evaluation against a few hundred prompts may behave differently under production traffic patterns. Plan for that.

A practical metrics architecture on Azure tends to combine:

Application Insights for end-to-end request tracing across the application and gateway.
Azure Monitor for infrastructure, quota, and PTU utilization of metrics.
Custom telemetry for prompt-level success/failure tracking and quality scoring.
Log Analytics for forensic analysis when a regression is suspected.

Drift in model behavior rarely shows up as a single broken request — it surfaces as a slow shift in tail latency, fallback rate, or user-satisfaction signal. Monitoring that only looks at average will miss it.

4. The Model Router Pattern

As GenAI systems mature, a static single-model architecture becomes both limiting and expensive. A Model Router introduces dynamic, intelligent model selection in front of one or more model deployments.

Typical responsibilities of a router:

Send simple queries to a smaller, faster model and complex reasoning to a larger one.
Run canary releases of new model versions with percentage-based rollouts.
A/B test model variants to measure quality, latency, and cost differences.
Route to the right capacity tier — including falling back from Provisioned to Standard during migrations or capacity constraints.
Where the workload also needs lower-variance latency on the Standard side, route latency-critical traffic through Priority Processing on a Global Standard or Data Zone Standard (US) deployment, on a model version that supports it. (At the time of writing, Priority Processing is enabled by setting the service_tier attribute on the request and requires a model version released on or after 2025-12-01 — verify both eligibility constraints on Microsoft Learn before depending on it.

Decision logic can be driven by any combination of:

Query complexity (simple heuristics or a lightweight classifier).
User tier (e.g., free vs premium).
Response-time requirements (interactive vs background).
Cost constraints — pick the cheapest model that meets the quality bar.
Regional model availability and capacity.

Implementation options:

Azure API Management — built-in routing policies, weighted backends, retry policies.
Azure Front Door — global routing with health probes.
Custom routing service — maximum flexibility, more operational overhead.
Semantic Kernel or LangChain — framework-level routing logic embedded in the application.

Beyond cost and performance, the Model Router pattern decouples the application layer from any single model version. That decoupling is what makes lifecycle management tractable: when a model moves to Legacy, you change a router rule, not application code.

Figure 3 — Model Router Architecture vs Blue/Green Deployment

5. Prompt Lifecycle Governance

Prompts are not strings embedded in code. They are production artifacts that influence quality, cost, and safety, and they evolve almost as often as the models behind them. Treat them as first-class assets.

Prompt templates

Separate stable system instructions from dynamic content (user input and retrieved context). This lets you version, test, and audit each layer independently.

Version control

Store prompts in Git — full history, code review, branching, and tagging. Treat prompt changes the way you treat code changes: pull request, review, and test before merging.

Feature-flagged rollouts

Roll out prompt changes gradually using feature flags. Monitor the impact on a subset of users before exposing the change broadly. The same observability stack that watches model upgrades should watch prompt rollouts.

Regression testing

Maintain a regression suite of expected prompt behaviors and run it whenever prompts or models change. The suite reuses the same evaluation pipeline you built in Section 2.

Prompt-level metrics

Success rate — did the prompt achieve its intended outcome?
Fallback rate — how often did users rephrase or abandon?
Satisfaction score — explicit user feedback.
Token efficiency — average tokens per successful completion (a leading indicator of cost regression).

PII and privacy safeguards

Customer prompts and completions are not used to train base models. That means logging is safe for debugging — but defense in depth still applies:

Redact PII (names, emails, phone numbers, addresses) before logs are written.
Apply RBAC on Log Analytics workspaces so only the right roles can access raw prompt data.
Govern data retention with automated purging after a defined window.
Keep audit trails of who accessed which logs and when.

Prompt quality is not a one-time effort. It is an ongoing operational discipline that needs tooling, processing, and measurement, in the same way application code does.

Figure 4 — Prompt Lifecycle Governance

6. Fine-Tuned Models: The Hidden Retirement Risk

Fine-tuned models inherit the lifecycle of their base model. That creates a cascading retirement risk that many teams overlook.

During base-model deprecation:

New fine-tuning jobs against that base are blocked — you can no longer create new fine-tuned versions.
Existing fine-tuned deployments continue serving inference, with no immediate impact.

When the base model is retired:

Fine-tuned deployments stop responding (HTTP 404), exactly like any other deployment pinned to a retired version.

The migration imperative is straightforward: retrain fine-tuned models on the successor base model well before the retirement date, ideally during the predecessor's Legacy or Deprecated stage.

Architectural considerations:

Track base-model dependencies explicitly in your asset inventory — the same place you track library and runtime versions.
Schedule retraining workflows aligned with base-model lifecycle dates, not with team availability.
Validate fine-tuned model quality on the new base; behavior can shift between base versions.
Keep training datasets in version-controlled storage, so retraining is reproducible.
Re-evaluate whether fine-tuning is still necessary; newer base models, combined with better prompting (few-shot, chain-of-thought, structured outputs), sometimes remove the need entirely.

Common mistake: investing heavily in fine-tuning without budgeting for the recurring retraining cost and lifecycle overhead. Improved prompting on a newer base model is often the cheaper path.

7. Regional Rollouts and Multi-Region Strategy

Successor models are not always available in every Azure region simultaneously. Microsoft typically releases a new version in a subset of regions first, with broader rollout following over weeks or months. At the time of writing, the regional rollout schedule is published per model on Microsoft Learn — confirm before assuming a particular region will receive a release on a particular day.

Maintain staging deployments in early-release regions

Even if production runs elsewhere, maintain a staging deployment in regions that tend to receive new models earliest. That gives you visibility into the successor's behavior before it auto-upgrades into your primary region.

Pre-test successor models before primary auto-upgrades

If your production deployment uses "Once the current version expires", the upgrade will happen automatically. Pre-testing in an early-release region lets you catch behavioral changes before they hit live traffic.

Multi-region routing for lifecycle flexibility

Azure Front Door or Azure API Management with multi-region back-ends lets you route based on model availability, capacity headroom (one region may have quota while another is exhausted), and latency. Combined with the Model Router pattern from Section 6, this turns regional staggering from a constraint into an option.

Account for capacity-tier eligibility in your routing

Some capacity tiers are scoped to specific deployment scopes — Priority Processing, for example, is offered on Global Standard and Data Zone Standard (US) deployments at the time of writing. Bake those eligibility constraints into routing rules, so a fallback path does not silently land in an ineligible deployment.

Multi-region strategy is no longer just a disaster-recovery concern. It is also lifecycle resilience — the ability to test, stage, and absorb model changes without coupling your platform to a single region release schedule.

8. Future-Proofing Through Abstraction

Future-proofing is architectural, not procedural. The goal is to design systems that adapt to change without requiring code rewrites every time a model is promoted, deprecated, or retired.

Abstract model calls behind a service layer

Avoid calling Azure OpenAI APIs directly from the application code. Introduce an internal Model Service that owns model selection, retry and fallback, prompt-template lookup, and response validation. The application asks for an outcome ("summarize this", "classify that"); the Model Service decides which model and which prompt to use.

Externalize model names and configuration

Store model identifiers, versions, and parameters in configuration or feature flags — never as hard-coded strings. Changing models then becomes a configuration change, not a deployment.

Centralize prompt logic

Maintain prompts in a registry or template repository, not scattered across codebases. This enables centralized versioning, A/B testing without code changes, and prompt optimization that is decoupled from application releases.

Avoid scattering model identifiers across the codebase

Use constants, enums, or configuration references rather than literal model strings repeated across many files. The number of files that have to change at upgrade time is a leading indicator of how painful the upgrade will be.

Benefits of abstraction:

Seamless model replacement — swap models without touching application logic.
Multi-model strategies — the Model Router pattern becomes trivial to add.
Provider flexibility — integrating additional or alternative providers becomes a service-layer change, not an application to rewrite.
Faster adoption of new capabilities — reasoning controls, function calling, structured outputs land in one place.

Common mistake: Prototyping with direct API calls for speed and never refactoring. The technical debt accumulates until a model upgrade requires an emergency engineering sprint.

Figure 5 — Abstraction Layer for Future-Proofing.

Final Perspective

The most important shift this article asks for is a change in operational mindset:

Model upgrades are not emergencies. They are scheduled events.
Retirement deadlines are not surprising. They are published timelines, often with months of notice.
Architecture fails when teams treat models as static dependencies. They succeed when they treat models as evolving infrastructure.

In practice, GenAIOps means:

Automated evaluation that runs continuously, not just during migrations.
Controlled rollouts using blue/green or canary patterns.
Observability-driven decisions based on metrics, not intuition.
Lifecycle-aware planning, with retirement dates tracked alongside library and runtime upgrades.
Modular design that decouples applications from specific model versions.

Across the three parts of this series we have covered the architectural decisions that frame an Azure OpenAI / Microsoft Foundry Models workload (Part 1), the Well-Architected Framework discipline that keeps it sustainable (Part 2), and the GenAIOps practices that let it evolve without firefighting (Part 3). The organizations that succeed long-term are the ones that plan for model evolution from day one, invest in evaluation and observability tooling, decouple application logic from model specifics, and treat prompts and configurations as versioned artifacts.

Generative AI architecture is not about deploying a model endpoint. It is about building a platform that absorbs change gracefully as the AI landscape shifts. The retirement of a model should be a routine operational event, not a crisis. If your architecture makes model upgrades feel risky or expensive, refactor before the next retirement deadline forces your hand.

Lifecycle & GenAIOps Decision Matrix

Use this as a checklist when reviewing or signing off on the GenAIOps posture of an Azure OpenAI / Microsoft Foundry Models platform. One row per decision; one rule of thumb per row.

Area	Decision	Rule of thumb	Watch out for
Lifecycle	Version expiry tracking	Treat model versions as expiring dependencies: inventory every deployed model/version, track deprecation/retirement dates, and design so swapping versions is a configuration change (details on upgrade modes in Part 2).	Pinning versions without an owner; discovering retirement dates after an outage or emergency migration window.
Evaluation	Promotion gates	Pass the regression suite + meet domain-specific quality and latency thresholds before promoting any model.	Subjective "feels better" sign-off; gates that exist on paper but never block a release.
Evaluation	Pipeline integration	Evaluation runs in CI/CD on every candidate; the same suite watches prompt changes.	Manual evaluation runs that only happen under retirement pressure.
Observability	Latency and error metrics	Track p50/p95/p99 latency, 429/503/4xx rates, token trend, and model-version distribution. Alert on tail latency and sustained throttling.	Average-only dashboards; missed Service Health notifications for model retirements.
Observability	Quality drift	Trend per-prompt success rate, fallback rate, and user-satisfaction signals; surface drift before users complain.	Treating quality as a one-time evaluation event.
Architecture	Model Router	Centralize model selection, canary, and fallback (including Priority Processing on eligible deployments) behind a router service.	Application code that calls a specific model deployment by name; routing logic scattered across services.
Architecture	Abstraction layer	Application code asks for an outcome; the Model Service decides which model and prompt; configuration drives model selection.	Hard-coded model identifiers across many files; bypass paths that skip the service layer.
Prompts	Prompt governance	Prompts in Git, behind feature flags, with regression tests, prompt-level metrics, and PII redaction in logs.	Prompts copy-pasted across services; PII in logs; no rollback path for a regressed prompt.
Fine-tune	Fine-tuned model lifecycle	Track fine-tuned models against base-model dates; schedule retraining during the predecessor's Legacy/Deprecated window.	Treating fine-tuned models as permanent infrastructure; lost or unversioned training datasets.
Regional	Multi-region for lifecycle resilience	Maintain staging in early-release regions; route across regions to absorb staggered rollouts and capacity gaps.	Single-region production with no early-release staging; routing rules that ignore tier-eligibility constraints.

Disclaimer

I am a Microsoft employee. The views and opinions expressed in this article are my own and do not necessarily reflect those of Microsoft. This content is informational and educational; it is not an official Microsoft statement, recommendation, or commitment. Service tiers, model availability, lifecycle stages, deprecation timelines, regional rollouts, pricing, and SLAs evolve — always validate against the latest Microsoft Learn documentation before making architectural or migration decisions.

References

Power Platform tenant inventory — a community showcase of the API-first management surface

PravinT — Mon, 08 Jun 2026 13:54:14 GMT

Source: github.com/SweetsNSavories/VerseOps · MIT.

Figure 1 — VerseOps loaded against a live tenant. Per-row capacity (DB / File / Log / FinOps DB / FinOps File GB) is computed from the BAP $expand=properties.capacity call; per-env asset counts are joined client-side from the Inventory API result set. Tenant identifiers redacted; everything else is real.

Figure 2 — One environment row expanded. The row-details template fans out the inventory: Solutions / Apps / Flows / Agents (joined from the Inventory API and per-env Dataverse Web API calls), Power Pages sites (mspp_website table on the env's Dataverse), and the env's systemusers (with their assigned licenses joined from Microsoft Graph). All asset counts (9 / 3 / 53 / 241) are real.

Figure 3 — Total Assets drawer (click the Total Assets KPI tile). The whole panel is fed by a single tenant-wide Inventory API query; the per-type counts are computed client-side from assetType. The "most recent" name surfaces the freshest asset of each kind so an admin can sanity-check that the tenant feed is current.

Figure 4 — Licenses Consumed drawer (click the Licensed Users KPI tile). The list is the union of every assigned servicePlan from /users?$select=assignedLicenses rolled up to the SKU level using the tenant's subscribedSkus catalog from Microsoft Graph. SKU codes are public; the only tenant-specific data is the per-SKU seat count on the right.

Why this exists

The recurring questions at the start of every governance cycle are well known:

"How many environments do we actually have? Who owns the apps in them? How much Dataverse capacity is sitting in places no one remembers creating? Which makers left the company three months ago and still own production flows?"

The official answers — Power Platform admin center (PPAC), the Power Platform inventory page, and the Usage page — already exist and are the right starting point for daily work; they cover the common cases comprehensively. There are still moments, however, when an administrator needs:

A single offline snapshot they can search, sort, filter, and ship to a stakeholder without exposing the live admin center.
A diff between this morning and last Friday — what changed?
Joined views that the portal doesn't ship out of the box: per-env capacity × per-env asset count × per-env user count, all in one sortable grid.
The raw JSON behind every row, one click away, when something doesn't match what the portal shows.
A starting point — code they can fork, instrument, and turn into the governance tool they actually wanted.

VerseOps targets that long tail. The UI surface is roughly five files; every outbound call is enumerated in docs/network-endpoints.md. The codebase is deliberately small, read-only by design, and positioned as a foundation that adopting teams are expected to fork, instrument, and extend.

How it complements the official "Inventory" and "Usage" pages

Microsoft's Power Platform inventory gives administrators a unified view of agents, apps, and flows tenant-wide, refreshed within ~15 minutes. The Usage page tracks engagement and adoption. Both ship in the admin center today and should be every admin's first stop.

VerseOps is positioned as a complement, not a replacement:

Need	PPAC Inventory / Usage	VerseOps
Daily inventory browsing in a portal	✅ Recommended	n/a
Filter / sort / search on any column	✅	✅
Resource-detail drill-in (owner, env, dates)	✅	✅
Export to Excel	✅	✅ (CSV / cache copy)
Capacity (DB / File / Log / FinOps GB) joined per env on the same row as asset count	Partial	✅
One-click "show me the raw Dataverse / PPAC JSON" inspector	❌	✅
Local SQLite cache for offline browsing on a plane / in an air-gapped review	❌	✅
Diff between today's snapshot and yesterday's	❌	✅ (cache-based, on roadmap)
Source you can fork	n/a	✅ MIT, single solution
Telemetry sent to Microsoft / vendor	per Microsoft's data policy	None — zero outbound calls beyond Microsoft's own APIs

If you only ever need 1–4 above, stay in the admin center; it's faster and always up to date. VerseOps shows up when you need 5–11.

Architecture in one diagram

Key architectural properties:

Single process, no server-side footprint. Every call runs in the signed-in user's security context. There is no daemon, no sync job, no message bus. The operating system schedules the network calls; the user triggers a refresh.
Two distinct cloud planes. Management-plane calls (api.powerplatform.com, api.bap.microsoft.com, graph.microsoft.com) are kept separate from data-plane calls ({org}.crm.dynamics.com per environment), with audience switching handled centrally by the auth layer.
The local SQLite database is the only state. Removing %LOCALAPPDATA%\VerseOps\ returns the application to a blank slate. No other persistence exists.

What's actually feasible with the Power Platform API today

Microsoft has been very public about its shift from a UX-first to an API-first development model for Power Platform programmability: new capabilities ship in the API first, then propagate to SDKs, CLI, PowerShell cmdlets, and connectors. The Programmability and extensibility overview lays out the full toolchain — REST API, .NET SDK (Microsoft.PowerPlatform.Management), Python SDK, Power Platform CLI, PowerShell cmdlets, and the Power Platform for Admins V2 connector.

VerseOps is a deliberately small showcase of what the .NET SDK + Inventory API combination unlocks once you put a UI on it:

Capability	API used	SDK / endpoint
List every environment in the tenant with name / region / SKU / version / security group / default-flag	Power Platform API (PPAC)	Microsoft.PowerPlatform.Management SDK
Per-tenant capacity (DB / File / Log / FinOps DB / FinOps File GB)	Power Platform API (PPAC)	SDK Licensing.Tenant.GetCurrentCapacityAllocations()
Per-environment capacity in one tenant-wide call	BAP capacity (legacy GA)	GET /providers/Microsoft.BusinessAppPlatform/scopes/admin/environments?api-version=2020-10-01&$expand=properties.capacity
Every canvas app, model-driven app, code app, cloud flow, agent flow, and Copilot Studio agent in the tenant in one POST	Inventory API (preview)	POST https://api.powerplatform.com/resourcequery/resources/query?api-version=2024-10-01 (KQL-style query against PowerPlatformResources)
DLP policies + connector classification (Business / Non-Business / Blocked)	BAP Governance v2	GET /providers/PowerPlatform.Governance/v2/policies?api-version=2018-01-01
Per-env solutions / Power Pages sites / system users / roles / app + flow status	Dataverse Web API v9.2	GET {org}/api/data/v9.2/solutions, appmodules, workflows, canvasapps, systemusers, mspp_websites
User license SKU resolution + security-group display names	Microsoft Graph	GET /v1.0/subscribedSkus, /users, /groups, /directoryObjects/getByIds

The headline shape of this: one tenant-wide POST replaces what used to be N×6 per-environment GETs. For a tenant with 700 environments, that's the difference between ~4,000 round-trips per refresh and ~10. The same Microsoft.PowerPlatform.Management SDK that powers the new admin-center surfaces is the same one your tooling uses — there's no longer a "fast official one and a slow community one".

A note on the BAP API deprecation path

Several BAP routes the community has relied on for years are now in a clear consolidation track rather than a deprecation one — but the destination is the same. From the official Versioning and support page:

"The 2020-10-01 Generally available version of Power Platform API is specific to environment management and is also commonly referred to as Business Application Platform (BAP) API. The functionality of this set of endpoints are made available in the newer versions of Power Platform API along with many additional features after version 2022-03-01-preview."

In practice, what this means for tools like VerseOps:

BAP route VerseOps uses today	Status (May 2026)	Modern equivalent on api.powerplatform.com
/scopes/admin/environments?$expand=properties.capacity	GA (api-version=2020-10-01); functionally superseded but still recommended for tenant-wide capacity	Will move to a Licensing namespace endpoint as parity completes; track Programmability what's new
PowerPlatform.Governance/v2/policies (DLP)	Stable	Watch the new Connectivity / Governance namespace endpoints (e.g. List Connectors, shipped July 2025)
Microsoft.BusinessAppPlatform provider routes	All being mirrored under api.powerplatform.com namespaces (Licensing, EnvironmentManagement, AppManagement, Authorization, Governance, Connectivity)	Use the SDK — Microsoft maintains the mapping for you

Microsoft's official guidance is unambiguous: use the Power Platform API surface (api.powerplatform.com) and one of the official SDKs (.NET, Python, CLI, PowerShell, Power Platform for Admins V2 connector) for any new automation. BAP routes won't disappear without a deprecation cycle, but new features ship to api.powerplatform.com first and may never come back to BAP.

VerseOps reflects this exactly: every new feature added since April 2026 went to api.powerplatform.com, the BAP capacity client is isolated to a single ~150-line file (BapCapacityClient.cs) so it can be swapped out the moment the per-env capacity surface lands on the new API, and the token-acquisition layer (AuthService.cs) supports both audiences side by side until that day comes.

Who this helps

The MIT license permits unrestricted internal adaptation; adopting teams are encouraged to fork, re-brand, and re-sign the binary with their own enterprise code-signing certificate as part of internal distribution. Typical adopters include:

Power Platform administrators running quarterly governance reviews who need a single defensible snapshot of current tenant state.
Center-of-Excellence (CoE) leads who previously relied on the CoE Starter Kit and are moving to the in-product Inventory + Usage pages, but still require a code-level surface to extend.
FinOps and capacity owners identifying the ~5% of environments that consume 80% of Dataverse storage, with FinOps DB / FinOps File / Log GB visible on the same row as the environment name.
Mission-critical and regulated workloads (financial services, healthcare, public sector) where a desktop tool that authenticates as the human administrator, emits zero telemetry, and stores all state locally is materially easier to risk-accept than a SaaS dashboard.
Security and penetration-test teams who require a reproducible, auditable, signed Windows binary and a clear inventory of what it touches. The SBOM, SECURITY.md, SIGNING.md, and CodeQL workflow are committed to the repository.
Engineering teams learning the Power Platform API who want a non-trivial, well-commented .NET sample that exercises every major namespace.

Where this could go next

The same API surface that powers VerseOps today can support a substantially richer set of experiences. Candidate directions follow; community input on prioritization is welcome via the issue tracker.

1. An agentic governance assistant

Wrap the local SQLite cache + the same auth pipeline behind a Microsoft 365 Copilot agent (or a Foundry agent), and let an admin ask things like:

"Which environments grew the most this week and who owns the new flows?"
"List every canvas app with a deprecated connector that's still 'On' in a production env."
"Show me orphaned resources owned by users disabled in Entra in the last 30 days."

The Power Platform API + Inventory API already returns everything you need to answer these in seconds. The agent surface is just a new face for the same data — and because the cache is local, the agent can run without ever sending tenant data to a third party.

2. Periodic snapshots → drift report

A scheduled task that runs VerseOps.App --refresh --headless once a day, writes the SQLite snapshot to a versioned folder, and emails a delta. "Today vs yesterday: +12 canvas apps in the Default env, –3 envs decommissioned, capacity climbed 4.1 GB on org-prod-eu."

3. Multi-tenant fan-out for MSPs / consultancies

Same EXE, multiple tenant profiles, side-by-side comparison view. The auth layer already supports --tenant <guid>; the cache schema is per-tenant-keyed.

4. Plug-ins for the Inventory API custom queries

The Inventory API's POST /resourcequery/resources/query accepts arbitrary KQL-style projections. A plug-in directory of "common admin questions as queries" (orphaned apps, oldest unused flows, premium connector usage by env) could grow organically.

5. Sister tools in Python / TypeScript

The Python SDK is GA; a Jupyter notebook that mirrors VerseOps' three core panels (env list + capacity + assets) would be ~200 lines and would land instantly with the data-science crowd.

The repository is intended as a working base for these explorations: the foundational ~80% — authentication, caching, paging, retry, redaction, error capture, and theming — is already implemented and exercised against a live ~700-environment tenant. Proposals for any of the directions above can be filed on the issue tracker.

What's in the repository

Everything below is on main at github.com/SweetsNSavories/VerseOps, MIT-licensed:

The single WPF EXE — VerseOps.App/
API clients, one per Microsoft service — VerseOps.App/Inventory/Services/
SQLite catalog schema — VerseOps.App/Inventory/Sql/schema.sql
README.md — install, run, build
SECURITY.md — disclosure policy + threat model
SIGNING.md — three publish-with-signature paths (self-signed dev, Azure Trusted Signing, OV/EV)
docs/network-endpoints.md — every outbound host + OAuth scope
THIRD-PARTY-NOTICES.md + sbom.cdx.json — full dependency attribution + CycloneDX SBOM
CI: build, vulnerability scan, CodeQL — .github/workflows/
Branch protection ruleset (PR required, force-push blocked) — .github/branch-protection.json

Try it

git clone https://github.com/SweetsNSavories/VerseOps.git cd VerseOps dotnet build VerseOps.sln -c Release .\VerseOps.App\bin\Release\net10.0-windows\VerseOps.App.exe

Sign in with a tenant admin account (Power Platform Administrator or Dynamics 365 Administrator), click Refresh, and the first cold pull populates the local cache. Subsequent launches are instant from the cache; click Refresh again whenever you want a fresh snapshot.

Closing thought

The thesis behind this post is straightforward: an API-first Power Platform management surface puts a complete tenant inventory within reach in roughly 3,000 lines of C#. The official Inventory and Usage pages remain the right tool for daily-driver scenarios. The SDK and Inventory API together cover the long tail — the cases where an organization needs a specific join, requires offline operation, or needs the answer the same week.

VerseOps is offered to the community as that starting point. Issues and pull requests are welcome on the public tracker; security disclosures should follow the process documented in SECURITY.md.

— Praveen T · maintainer, VerseOps

References

Power Platform inventory — the in-product surface VerseOps complements
Power Platform admin center Usage page
Programmability and extensibility overview — official tooling map
Versioning and support — the BAP-vs-PPAC story
Programmability — What's new or changed — monthly release log
Power Platform API REST reference (latest)
Microsoft.PowerPlatform.Management on NuGet — the .NET SDK VerseOps consumes
Power Platform for Admins V2 connector — the no-code path to the same API
Tutorial: Create a daily capacity report — Microsoft's own end-to-end SDK example
Power Platform URLs and IP address ranges — for network allow-lists

Archiving Years of Dataverse Audit History Before You Prune It — A Pragmatic, Open Source Pattern

PravinT — Mon, 08 Jun 2026 13:53:50 GMT

Why the audit table is special

The audit table is different from the rest of Dataverse in two ways that matter for an archive design:

It’s an immutable, append-only record of who changed what, when, and from where — the closest thing Dataverse has to a forensic ledger.
The valuable part of an audit row is not the row itself; it’s the diff (old value → new value, attribute mask, related-record context). The audit row stores that diff in a packed changedata column, and the bound RetrieveAuditDetails function is what decodes it into a structured OldValue / NewValue / ChangedAttributes shape your downstream tools can actually query. Synapse Link with the Delta Lake profile will carry the changedata column to the lake, but you still need a parser on the other side; this pattern calls RetrieveAuditDetails at archive-time so what lands in the destination is already decoded and immediately queryable.

That combination makes the audit table the single most useful Dataverse table for:

Regulatory and compliance investigations
“Why did this opportunity status change in Q3 of 2022?” forensic queries (years after the fact)
Internal analytics on user behaviour and process adoption

It’s also the table that grows the fastest. The Dataverse default retention is 90 days, but in practice many enterprises extend that to several years — or set it to never delete — to retain evidence for compliance and forensic review. The result, often after five to seven years, is an audit table holding tens of GB to multiple TB of capacity, dominating the entitlement bill, and rarely accessed in normal operations.

At that point the storage conversation becomes unavoidable. The realistic choices are:

Keep buying entitlement. Predictable, but unbounded.
Move the cold tail somewhere cheaper that you control, then let Dataverse’s audit-deletion job reclaim the space. The hot months stay in Dataverse where users expect them; the years of historical evidence live in your own storage account, queryable when you need them.

This pattern is for option 2 — specifically, for the one-time bulk export of multi-year history, with the option to keep a slow trickle running afterwards if you want to top up.

A crucial point that often gets lost: this pipeline does not need to run live. It is perfectly reasonable to be deliberately months or years behind real-time. The goal is to get a defensible copy of cold data out — the rows you are about to allow Dataverse to delete — not to mirror the audit feed in real time.

What “good” looks like for an external audit copy

Before showing any code, here’s the rubric I held this design to. If you build your own, hold yours to the same rubric:

Property	Why it matters
Idempotent	Re-running the same time window must not duplicate rows. Network blips happen.
Crash-safe (exactly-once-effective)	If the process dies mid-window, the next run must replay the same window cleanly. The watermark advances only after the data is durable in the destination.
Bounded memory	A backlog of millions of audits cannot be loaded all at once.
Backpressure-aware	Dataverse rate-limits aggressively. Throttle responses must not drop rows.
Observable	Every window logs [entity] mode=BACKLOG/LIVE, lag=Nmin, window=10min, records=N so you can watch it work.
Sink-agnostic	The “where does it land” decision is config, not code. Storage choices change; the orchestrator shouldn’t.
Field-level discretion	Audit details can carry PII. The pattern should let admins narrow which attributes leave the platform.

The pattern

The pipeline is conceptually four stages, repeated per entity, per time window:

Three details in this picture do most of the resiliency work. They are deceptively simple:

Detail 1: Half-open time windows (ge / lt)

The boundary moment (09:10:00.000) belongs to window 2, not window 1. So adjacent windows never overlap and never gap, no matter how many times you replay. This is the same trick Kafka uses for offsets — it’s why you can run the loop with confidence.

Detail 2: The destination document key is the Dataverse auditid GUID

Dataverse already assigns a globally unique GUID to every audit row. That GUID becomes the document id in the sink. So when you upsert the same audit twice, the second write is a no-op overwrite of the first — idempotency for free, no client-side dedupe table to maintain.

Detail 3: The watermark moves after the write, not with it

The naive version of this pipeline does:

The resilient version raises a typed exception when any record fails, and the watermark update is conditional on a clean write:

This single change is the difference between “best effort” and “exactly-once-effective.” It’s also the mistake most often made when people roll their own.

Choosing where it lands

The orchestrator is sink-agnostic — it talks to a single AuditSink interface (get_state, update_state, write_audits) and the destination is a config switch, not a code change. The reference implementation ships with four production-shaped sinks plus a no-op for testing. None of them is the answer; they map to platforms enterprises already operate:

Sink	When to consider it
Azure Cosmos DB (NoSQL API)	Operational lookups — “show me everything user X did to record Y in 2022” in milliseconds. Hierarchical partition keys (/entity + /auditYearMonth) keep partitions small as the archive grows over years. Document TTL doubles as a retention policy if you want one. Serverless mode suits a slow-trickle archive workload.
Azure Data Lake Storage Gen2 (Parquet)	The cheap-cold-storage option. Years of audit history land as partitioned Parquet files (entity=…/year=…/month=…/), readable from Fabric notebooks, Synapse Serverless SQL, Databricks, or any Parquet engine. Costs scale with bytes, not throughput — ideal when the archive is rarely queried but must exist.
OneLake (Parquet)	Same Parquet shape as ADLS, but landed inside a Microsoft Fabric Lakehouse. Immediately queryable from a Fabric SQL endpoint, notebooks, and Power BI without further plumbing. The natural choice if your downstream BI is Fabric.
Snowflake (MERGE INTO)	The natural choice when Snowflake is already the analytics platform of record and adding a separate Microsoft analytics estate just for audit data isn’t on the table. MERGE INTO ... ON audit_id keeps the same idempotency contract as the Cosmos upsert, and the warehouse stays paused between archival batches.
No-op (logs only)	First-day connectivity testing. Confirms the Dataverse side works before you provision any storage.

A reasonable default split many enterprises arrive at:

ADLS Gen2 / OneLake (or Snowflake, if that’s your platform) holds the durable historical archive — cheap, partitioned, queryable when (rarely) needed.
Cosmos DB holds the most recent N months for fast operational lookup if there is a use case for it; otherwise skip it entirely.

Adding a sink for storage you already own (e.g., BigQuery, Redshift, on-prem object storage) is roughly 100 lines of Python and one factory entry.

What real-world numbers will look like

The worked test run above shows what a clean sandbox run looks like. Real numbers in your tenant will vary by orders of magnitude depending on:

How many entities have auditing enabled
The shape of RetrieveAuditDetails calls (more changed attributes per row = more bytes per call)
Dataverse Web API rate limits applicable to your environment
Concurrency you allow (max_concurrent_entities in the config)
Sink throughput (Cosmos serverless RU autoscale, ADLS upload bandwidth, Snowflake warehouse size)

The useful operational signal is not the absolute throughput — it’s that the throughput is stable and the per-window log lines tick predictably. If they don’t, look at lag, sink errors, or 429 responses from Dataverse before scaling up concurrency.

When to reach for it (and when not to)

Reasonable fit:

You have multiple years of accumulated audit history in Dataverse and need to move the cold tail off the platform before pruning to reclaim entitlement.
You want the decoded RetrieveAuditDetails payload (old value → new value, attribute mask, related-record context) landing in the destination ready to query — rather than the packed changedata column Synapse Link delivers, which still needs a parser on the consumer side.
Your analytics platform of record sits outside Azure (most commonly Snowflake) and you don’t want to add Synapse + ADLS + Spark to your stack just to land the audit table.
Synapse Link isn’t an option in your tenant — region pairing, governance review, or the cost floor of running ADLS + a Spark pool 24/7 don’t fit your environment.
You’re comfortable running this as a batch job — once for the historical backfill, then perhaps quarterly or annually to top up — rather than as a live continuous feed. Being deliberately months or years behind real-time is fine and often desirable.
You want field-level control over which attributes leave the platform — useful when audit details contain regulated data.

Not a good fit:

You can run Azure Synapse Link with the Delta Lake profile and you’re happy parsing the packed changedata column on the consumer side, and your destination is ADLS / Synapse / Power BI. That’s the supported, first-class path for the audit table — use it.
You only need current state of business tables (account, contact, opportunity). Use Synapse Link / Fabric Link — they do exactly that and you don’t need this pattern.
You need sub-second freshness in the destination. The pattern’s natural cadence is one window length (10 min in the reference config); for true real-time, use Dataverse webhooks or change-tracking APIs.
You don’t have somewhere to operate a small Python container, function, or scheduled job — even an annual one.
You don’t have an internal owner who can be paged when the schedule fails.

The reference implementation

The code that backs this post lives at https://github.com/SweetsNSavories/DataverseAuditLogSyn under MIT, with no warranty. The unified-deployment folder is the version this post describes — single Python codebase, swap sinks via config.json, runs locally / in a container / as an Azure Function.

If you want the implementation depth this post deliberately leaves out — exact API shapes, watermark math, partial-failure drill, sink-author checklist, hosting variants, observability hooks, and the full list of operational responsibilities a self-hosted export carries — it all lives in one place:

unified-deployment/DESIGN.md

Issues, forks, and pull requests welcome via the repo.

Generated 2026-05-14 from https://github.com/SweetsNSavories/DataverseAuditLogSyn/blob/main/docs/blog/archiving-dataverse-audit-logs.md · MIT licensed reference implementation, no warranty.

Azure OpenAI Architecture: The Decisions That Actually Matter (Part 2)

luciacasucci — Mon, 08 Jun 2026 13:53:24 GMT

Introduction

In Part 1 of this series, we walked through the architectural decisions that shape any Azure OpenAI / Microsoft Foundry Models workload: capacity model, deployment location, governance layer, grounding strategy, and quota engineering. Part 2 moves from decisions to discipline. Once you have made those choices, how do you make sure your design holds up to the Azure Well-Architected Framework (WAF)?

The five WAF pillars — Cost Optimization, Security, Reliability, Performance Efficiency, and Operational Excellence — apply just as strongly to GenAI systems as they do to traditional cloud workloads. In fact, they matter more, because GenAI systems are not static: models are upgraded and deprecated, quotas shift, usage patterns grow unpredictably, and new capacity tiers (such as Priority Processing) are introduced while you are running in production.

This post walks through each pillar in the context of Azure OpenAI in Microsoft Foundry, with best practices, common pitfalls, and the trade-offs Cloud Solution Architects (CSAs) tend to hit in real engagements. Where details are time-sensitive — pricing percentages, SLA windows, model retirement timelines, regional rollout delays — they are flagged with "At the time of writing". Always confirm current behavior against Microsoft Learn before committing to a design.

Who is this series for?

Cloud and Solution Architects
Platform and product owners
Senior developers responsible for operating Azure OpenAI workloads in production

What you’ll learn in Part 2:

How each WAF pillar maps to concrete Azure OpenAI design choices.
Where Priority Processing fits across cost and performance trade-offs (and what its eligibility constraints are).
How to plan for model lifecycle events — upgrades, deprecations, retirements — without firefighting.
Which signals to monitor day-to-day, and how to bake them into a GenAIOps loop.
A WAF Decision Matrix at the end of the article, to use as a reusable checklist.

In Part 3, we will look at the part that makes GenAI architecture genuinely different from a traditional service: the platform itself never stops moving.

We’ve also included a summary decision matrix at the end of this post for quick reference.

1. Cost Optimization: Designing for Sustainable Scale

Cost optimization in GenAI is primarily a capacity strategy problem, not just a token-pricing problem. The first question is whether to use pay-as-you-go capacity, reserved capacity, or one of the newer tiers in between.

Reserved capacity (Provisioned Throughput Units, PTUs)

If your workload is steady or growing predictably, you can significantly reduce costs by reserving capacity up front for 1 or 3 years. At the time of writing, reservations typically yield in the range of 30–50% savings compared to hourly pay-as-you-go rates — but the exact discount depends on term length, region, and the model family, so always confirm against the current Azure pricing page.

Fully utilizing a reserved (provisioned) deployment turns cloud spend into a predictable infrastructure investment, much like allocating VM or database capacity. This requires a mindset shift: treat a provisioned Azure OpenAI deployment as always-on infrastructure sized for peak demand, not as on-demand burst capacity.

Importantly, PTU quota is now model-agnostic within a region. You purchase generic throughput units that can be applied to any supported model in that region, so you do not risk stranded capacity when upgrading (say, from one GPT-4 family version to a newer one) or changing model versions. Your investment follows your architecture, not a specific model endpoint.

Avoid dynamic PTU "auto-scaling"

Unlike VM-based infrastructure, dynamically scaling Azure OpenAI capacity up and down to chase cost savings is not recommended. Additional capacity is not guaranteed to be instantly available when you need to scale up, especially if other tenants are consuming the region's resources. Frequent resizing can also negate the benefits of reservations and introduce performance variability. Unused PTUs are not waste — they are headroom that absorbs burst traffic. In practice, design for the peak load and optimize through reservations rather than trying to constantly dial capacity up and down.

Batch tier

Use Batch deployments for asynchronous, non-user-facing jobs (large-scale document processing, nightly data enrichment, evals, embeddings backfills). At the time of writing, Batch can reduce cost per token by up to around 50% compared to Standard pay-as-you-go calls, in exchange for a 24-hour completion window. It also takes pressure off your real-time deployments.

Priority Processing

For workloads that need prompt responses but do not yet warrant a full dedicated PTU deployment, Azure OpenAI offers Priority Processing. Functionally, it is pay-per-token like Standard, but with SLA-backed lower and more consistent latency on the shared infrastructure.

Activation: set the service_tier attribute on the request to "priority" (other values are "default" and "auto").
Model eligibility: at the time of writing, requires model versions released on or after 2025-12-01.
Deployment eligibility: only available on Global Standard or Data Zone Standard (US) deployments.
Pricing: at the time of writing, roughly 20–40% higher per-token cost than Standard, but still meaningfully cheaper than reserving PTU for a low-volume latency-critical path.

Treat Priority Processing as the natural in-between rung: more predictable than Standard for latency-sensitive production traffic, but without the commitment and capacity-planning effort of PTU.

Putting it together

Segment your workloads by interaction pattern and performance need, then assign the most cost-efficient capacity model to each. A common anti-pattern is over-provisioning expensive real-time capacity for jobs that could run asynchronously. Evaluate whether each use case truly requires sub-second latency, or whether a longer batch window (minutes or hours) is acceptable. Use real-time capacity for customer-facing queries and time-sensitive tasks; use Batch or Priority Processing for everything else, depending on tolerance for latency.

[Diagram 1 — Cost Strategy Layering]

2. Security: Compliance, Isolation, and Data Protection

Security in Azure OpenAI begins with deciding where your inference runs and how data is handled. This is often a compliance-driven decision before it is an architectural one.

Deployment scope

Global deployments — Maximize model availability and capacity by allowing Azure to route inference across regions. Pro: broad elasticity and access to the latest models. Con: data is not confined to a single geography, which may violate strict data residency requirements. Global also adds slight troubleshooting complexity, since requests can be served from various regions.
Data Zone deployments — Constrain inference to a specific zone or political boundary (for example, EU-only or US-only Data Zones). Pro: a compliance-friendly middle ground — data processing stays within a defined region set (for example, entirely within the EU to satisfy GDPR), while retaining more elasticity than a single region. Con: slightly reduced model availability and capacity headroom compared to Global.
Regional deployments — Confine inference to one Azure region. Pro: meets the most stringent data sovereignty requirements and can minimize latency for users in that region. Con: limited to the capacity and models available in one region, with no automatic overflow if the region is saturated. New model versions may also roll out to some regions later than others — at the time of writing we have observed delays of roughly 2–6 months for certain releases in specific regions; check Microsoft Learn for the current rollout schedule.

Choosing among these is a regulatory risk-management decision, not just an infrastructure preference. Engage your compliance and data governance teams early to determine the minimum scope of data movement that satisfies requirements. Many teams initially over-constrain this choice out of caution; it is often better to start with a broader deployment (Global or multi-region Data Zone) where permissible, and tighten the scope later if needed. Conversely, if your organization mandates that all data stay in-country, you might go straight to Regional and invest in architectural mitigation for its limitations (capacity planning, multi-region backup plans).

Baseline protections + defense in depth

Regardless of deployment type, Azure OpenAI provides baseline protections: it does not use your prompts or completions to train the underlying models, and all data is encrypted in transit (TLS 1.2+) and at rest (AES-256). Defense in depth is still essential — implement compensating controls at multiple layers:

Redact sensitive data from prompts (or prevent it from being entered) at the client or gateway layer. Use Azure API Management policies or custom middleware to strip out PII or secrets before requests reach the model.
Apply content filtering to both prompts and responses. Use the built-in content filters and/or Azure AI Content Safety to detect and block sensitive or undesirable input and output.
Use strong authentication and role-based access control. Front your Azure OpenAI endpoint with Microsoft Entra ID; scope tokens with least privilege (for example, the Cognitive Services OpenAI User role or managed identity access) instead of distributing master API keys. If a credential is compromised, the blast radius is limited.

Additional best practices

Managed Identities — use them for any internal communication between your application and Azure OpenAI (or other Azure services like storage and databases) instead of embedding API keys. This eliminates the risk of leaking secrets and simplifies credential rotation.
Private endpoints — enable Azure Private Link to keep traffic between your application and the Azure OpenAI service inside your virtual network and the Azure backbone, off the public internet.
Content Safety tooling — integrate Azure AI Content Safety or custom validation functions to scan prompts and completions for policy violations or confidential data. This extra inspection layer can catch issues the base filter misses, and lets you log or modify disallowed content before it reaches the user.

In short, security for GenAI is not just about encryption or API keys — it is about reducing the blast radius of any potential breach or misuse. Confine inference to approved locations, strip sensitive data before it reaches the model, and strictly limit which identities and networks can call your endpoints.

[Diagram 2 — Data Boundary Visualization]

3. Reliability: Designing for Change, Not Just Stability

Reliability in Azure OpenAI is as much about managing model evolution as it is about traditional uptime. Unlike static services, GenAI models are periodically updated and improved by the provider. New versions are released, older versions are deprecated and eventually retired — so a truly reliable system must plan for these changes just as carefully as it plans for hardware failures.

Model lifecycle

At the time of writing, Generally Available (GA) models are typically supported for at least 12 months after release, followed by a deprecation phase of roughly 6 months before retirement. Always confirm the current support windows on Microsoft Learn before locking in a design — these timelines have shifted in the past and may shift again as new model families ship.

When retirement hits:

Standard deployments still pinned to a retired model (with "No Auto-Upgrade" set) stop responding to requests entirely — the API typically returns HTTP 404 (or a similar error) for that model name.
Provisioned deployments using a retired model return HTTP 410 (Gone) errors until you manually switch them to a supported model.

In short, every model version you deploy has a built-in expiration date. Good reliability planning means never being caught unprepared by a model retirement.

Auto-upgrade modes for Standard deployments

Three modes are available:

Auto-upgrade to the latest version — the deployment moves to the new default model version as soon as Azure makes it available. Always on a supported version, but you have no control over timing. Generally not recommended for mission-critical production workloads, since new versions can have different behavior.
Upgrade only on retirement — the deployment stays on its current version until that version is about to be retired, then automatically switches to the latest. Recommended for most production Standard deployments: stability during the model's supported lifespan, with continuity guaranteed at retirement. You still need to test and adjust to the new version, but at least you do not face an outage if you miss the date.
No auto-upgrade — the deployment stays pinned to a specific version unless you change it manually. Not recommended for production: it puts the entire burden on you to track retirement timelines.

Most teams choose option 2 ("upgrade on retirement") for Standard. It allows controlled change during the model's supported period and provides a safety net at retirement. Proactively evaluate new versions for quality, performance, and cost before the forced swap, but the setting greatly reduces the risk of surprise outages.

Provisioned (PTU) migrations

Provisioned deployments do not support auto-upgrade — you must manage these migrations yourself. Azure sends retirement announcements via Azure Service Health alerts and emails, at the time of writing typically 60 days or more in advance. Have a runbook ready. Two approaches are common:

In-place migration — upgrade the deployment's model version through the portal or CLI. The endpoint stays the same and the model is updated behind it. Fast, no new connection string, but expect a brief disruption during the switch and rollback is not straightforward (you may need to contact support to re-enable the old version, if at all possible).
Side-by-side (blue/green) — create a new deployment with the new model version in parallel. Gradually shift traffic (for example, 10% via APIM routing rules), monitor, and roll back instantly if needed. Maximum control and safety, at the cost of running two deployments in parallel for the migration window.

Before any model migration, verify you have sufficient PTU quota in the region for the new model. More advanced models may require more throughput units for the same workload than smaller predecessors — at the time of writing, plan for the possibility that a new generation needs roughly two times (or more) the PTUs to deliver similar throughput. Request quota increases before you hit the upgrade window, not during it.

Multi-region strategy

Consider a multi-region strategy to improve reliability during model rollouts and deprecations. New model versions do not always appear in all regions simultaneously — at the time of writing, Microsoft often launches a model in one region (frequently East US or West Europe) first.

Maintain a secondary deployment in a "first-wave" region to evaluate new versions early.
Use a traffic manager (Azure Front Door, Traffic Manager) to fail over to a region where the model is still available if your primary region lags behind.
Multi-region active-active designs also protect you against single-region outages.

In essence, reliability for GenAI means designing for change. A highly reliable platform is not one that never changes; it is one that changes gracefully. Model upgrades, deprecations, and capacity adjustments should be routine, well-rehearsed events — not fire drills. Achieving this typically requires automation for detecting and applying updates, redundant deployments or regions for flexibility, and ongoing testing of new models well before your current ones retire.

[Diagram 3 — Model Upgrade Strategy]

4. Performance Efficiency: Predictability Over Raw Speed

Performance in GenAI is multi-dimensional. It is not just about raw throughput or the fastest response on an empty system — it is about consistent, predictable latency at scale. Users care that responses are reliably snappy under load, not just fast in ideal conditions.

Performance profiles by capacity model

Standard (shared infrastructure) — multi-tenant, no guaranteed latency SLA. Performance fluctuates with regional demand; you may see throttling (HTTP 429) at peak. Best-effort: great for development, testing, and non-critical workloads, but not a fit for consistent low latency under spikes.
Priority Processing — also shared infrastructure, but your requests jump the queue ahead of Standard traffic. At the time of writing, this is the only pay-per-token tier with an SLA on latency. Activated by setting the service_tier attribute to "priority" on each request (other values: "default", "auto"). Requires model versions released on or after 2025-12-01 and is only available on Global Standard or Data Zone Standard (US) deployments. Pricing premium is roughly 20–40% over Standard. The natural fit for latency-sensitive workloads at intermediate scale — better than Standard, without committing to PTU.
Provisioned Throughput (dedicated capacity) — reserved capacity with isolation from other tenants. The most consistent performance and the strongest Azure SLA on latency (typically bounded p50 and p99 within your provisioned capacity). If your application has strict response-time requirements or user-facing SLAs and the volume justifies it, PTU is the right answer.

A practical pattern: Standard for early-stage and non-critical scenarios; Priority Processing for latency-sensitive paths that have not yet earned a PTU reservation; PTU for steady, high-volume, latency-critical production traffic.

Model selection and configuration

Model size — smaller models generally respond faster than larger ones. Do not automatically pick the biggest model if a smaller one meets your quality bar.
max_tokens — capping response length caps worst-case latency and cost. A 500-token cap finishes sooner than 2000 tokens, even when users ask open-ended questions.
Sampling parameters — low temperature (more deterministic) and a high top_p can shave a small amount of processing overhead versus highly creative or multi-sample setups. Minor compared to model size and length, but real.
Streaming responses — enable streaming wherever possible. The first tokens arrive immediately while the model is still generating; perceived latency drops dramatically even when total time is unchanged.

Treat performance as an explicit design goal. Choose the right capacity model for the job, tune model settings to avoid unnecessary slowdowns, and do not over-engineer with a larger model than needed. A common mistake is defaulting to the biggest model "just in case". Benchmark — a smaller model with good prompt engineering often delivers a fraction of the latency at a fraction of the cost, with negligible quality loss.

5. Operational Excellence: Running GenAI as a Living System

Operational excellence in GenAI means treating your platform as a continuously evolving product. Models change, user behavior shifts, new features ship. Success requires ongoing monitoring, maintenance, and improvement processes — often called GenAIOps (or MLOps for generative AI).

Proactive monitoring

Set up Azure Service Health alerts for your Azure OpenAI / Foundry resource to be notified about service incidents and, importantly, upcoming model deprecations or retirements. At the time of writing, Microsoft typically gives around 60 days of notice for retirement events — but it is easy to miss those notifications if no one is watching. Early awareness lets you test new models and plan migrations calmly instead of reacting at the last minute.

Continuously track key metrics in Azure Monitor or Application Insights, with alerts on anomalies:

Latency percentiles — monitor p50, p95, and p99. A trend up in tail latency is an early warning of saturation or regression.
Error rates — watch HTTP 429 (throttling) and HTTP 503 (server) error trends. Spikes signal capacity limits or service-side issues.
Capacity utilization — for PTU, watch utilization continuously. Sustained operation near 100% means no headroom for bursts. On Standard, watch token usage against subscription limits and quotas.
Token consumption trends — track growth over time. Helps with cost forecasting and reveals runaway usage (unexpectedly popular features, looping clients).

Useful alerting practices: alert on p99 latency breaching a threshold, on any sustained increase in 429s, or when PTU utilization regularly exceeds around 80%. Early warning lets you scale up, optimize, adjust prompts, or throttle specific users before user experience suffers.

Evaluation and reproducibility

Use the evaluation tooling in Azure AI Foundry to compare outputs from two models side by side on a fixed set of test prompts. Re-evaluate periodically — slowly degrading quality often goes unnoticed without a structured comparison.

Implement Infrastructure-as-Code (IaC) and GitOps practices for your Azure OpenAI and supporting resources (APIM, storage, key vault, monitoring). Bicep, ARM, or Terraform templates checked into source control make environments reproducible across dev/test/prod, simplify recovery, and enable change tracking. If something breaks, you can roll back to a known-good configuration quickly.

In summary, operational excellence for GenAI is about continuous learning and improvement. Embrace an AI DevOps culture: invest in monitoring, train your team on model changes, keep optimizing prompts and configurations, and refine processes after each lesson learned. The effort pays off by preventing fire-drills and keeping the platform robust as it evolves.

Final Perspective and Key Takeaways

Applying the Well-Architected Framework to Azure OpenAI forces a higher level of architectural rigor — exactly what GenAI projects in production need. Each pillar drives concrete decisions.

Key takeaways from Part 2:

Cost Optimization — align capacity to workload patterns. Reserve for steady, predictable load; use Batch for offline jobs; use Priority Processing for latency-sensitive paths that do not yet justify PTU; do not pay for ultra-low latency you do not need.
Security — match deployment scope (Global, Data Zone, Regional) to compliance requirements, then layer controls (network isolation, identity and access, data sanitization, content filtering) to minimize blast radius.
Reliability — anticipate continuous model evolution. Use upgrade-on-retirement for Standard, run parallel deployments for PTU migrations, and design for multi-region failover where it matters. Reliability is about avoiding surprises, not just outages.
Performance Efficiency — choose the right capacity model, right-size models and responses, and use streaming. A smaller model with good prompt engineering often beats a bigger one on user experience.
Operational Excellence — treat the platform as a living product. Monitor, alert, automate, evaluate, and version everything as code. The discipline keeps the platform improving instead of decaying.

The organizations that succeed with Azure OpenAI / Microsoft Foundry Models are those that treat capacity planning, security and compliance, model lifecycle management, and governance as first-class design concerns — not afterthoughts. Generative AI architecture is not about deploying a model and walking away; it is about building a resilient, adaptable platform that gracefully evolves as models change and usage grows.

In Part 3, we bring everything together into a comprehensive reference architecture for an enterprise-grade Azure OpenAI platform — combining scalable capacity strategies, layered security and governance, proactive lifecycle (GenAIOps) practices, and multi-region resiliency into a cohesive blueprint ready for production.

[Diagram 4 — WAF pillars summary]

WAF Decision Matrix : Quick Reference

Use this as a checklist when reviewing or sign-off-ing an Azure OpenAI / Microsoft Foundry Models design. One row per decision; one rule of thumb per row.

Pillar	Decision	Rule of thumb	Watch out for
	Capacity tier mix	Variable load → Standard. Latency-critical → Priority Processing. Offline bulk → Batch. Steady high-volume → PTU.	Single-tier platforms over-pay for elasticity or under-deliver on latency.
Cost	Reservation term (PTU)	1- or 3-year terms for predictable workloads; size for peak, not for average.	Dynamic resizing of PTU to chase savings; capacity not guaranteed at scale-up time.
Cost	Priority Processing eligibility	Requires service_tier="priority", model 2025-12-01+, Global Standard or Data Zone Standard (US).	Assuming it works on every region/model — confirm eligibility before committing the design.
Security	Deployment scope	No residency rule → Global. Multi-region zone OK → Data Zone. Strict residency → Regional.	Over-constraining out of caution; or under-constraining and missing a compliance requirement.
Security	Identity and access	Microsoft Entra ID + Managed Identity + scoped roles. No master keys in apps.	Long-lived API keys distributed across teams.
Security	Network and data	Private Link for in-network traffic; PII redaction at the gateway; content filtering on prompts and responses.	Public endpoints, raw PII in prompts, only relying on the built-in filter.
Reliability	Auto-upgrade strategy	Standard → "upgrade on retirement". PTU → planned blue/green migration with sufficient quota in advance.	Pinning Standard with no auto-upgrade and forgetting; in-place PTU migration with no rollback path.
Reliability	Multi-region	Active-active (or first-wave secondary) for critical paths; traffic manager for failover.	Single-region production with no plan for capacity or model-rollout lag.
Performance	Capacity match	Match capacity tier to latency target: Standard for non-critical; Priority for latency-sensitive; PTU for SLA-bound.	Expecting Standard to deliver consistent low latency under spike load.
Performance	Model and response sizing	Pick the smallest model that meets quality. Cap max_tokens. Stream responses.	Defaulting to the largest model "just in case"; long uncapped responses; no streaming.
Operations	Monitoring and alerting	Track p50/p95/p99, 429/503 rates, PTU utilization, and token trends. Alert on tail latency and sustained throttling.	Average-only dashboards; missed Service Health notifications for model retirements.
Operations	IaC and GitOps	Bicep/ARM/Terraform under source control; reproducible dev/test/prod; pipeline-driven changes.	Click-ops in the portal; environment drift between dev and prod.

Disclaimer

I am a Microsoft employee. The views and opinions expressed in this article are my own and do not necessarily reflect those of Microsoft. This content is informational and educational; it is not an official Microsoft statement, recommendation, or commitment. Service tiers, model availability, pricing, SLAs, and feature eligibility evolve — always validate against the latest Microsoft Learn documentation before making architectural decisions.

References

Azure OpenAI Architecture: The Decisions That Actually Matter (Part 1)

luciacasucci — Mon, 08 Jun 2026 13:53:07 GMT

Generative AI demos often succeed because they hide the hard parts of architecture. They usually run under ideal conditions: low, steady traffic, no sudden bursts, no competing teams, and minimal regulatory scrutiny. In production, however, Azure OpenAI systems face a very different reality – variable loads, service quotas, compliance constraints, evolving model versions, and the need for cost visibility.

The difference between a great demo and a resilient production platform isn’t the model itself – it’s the early architectural decisions. The choices you make from day one determine whether your generative AI solution can handle real-world demand or buckle under pressure.

Who is this series for?

Cloud and Solution Architects
Platform and product owners
Senior developers responsible for operating Azure OpenAI workloads in production

What you’ll learn in Part 1: We’ll walk through five foundational design decisions for Azure OpenAI, explain why they matter, and highlight key trade-offs and pitfalls we’ve seen in real-world deployments:

Capacity Model – Choosing between Standard (PAYGO), Priority Processing, Batch, or Provisioned Throughput (PTU)
Deployment Location – Global vs. Data Zone vs. Regional hosting
Governance Layer – When and why to introduce a GenAI gateway
Grounding Strategy – When to use Retrieval-Augmented Generation (RAG)
Quota Engineering – How to plan for service limits and avoid throttling

In Part 2, we’ll translate these principles into concrete implementations: multi-region topologies, cost allocation strategies, observability and monitoring patterns, and other best practices for reliability, security, and DevOps in Azure OpenAI. Part 3 will connect these decisions to GenAIOps best practices to help ensure your solution is future-proof.

We’ve also included a summary decision matrix at the end of this post for quick reference.

1. Capacity Model: PAYGO, Priority, Batch, or Dedicated Throughput?

At the time of writing, Azure OpenAI (now part of Microsoft Foundry Models) offers four capacity models for hosting models, each with distinct cost, latency, and operational characteristics. Most production solutions combine two or more of these tiers:

Standard (pay-as-you-go, shared): Multi-tenant, elastic capacity. You pay per token, with no upfront commitment and no cost when idle.
Pros: Simple and flexible; ideal for dev/test and for moderate or unpredictable traffic patterns.
Cons: No guaranteed throughput or low-latency SLA – performance may vary with regional load. Under heavy usage, you may see high latency or HTTP 429 “Too Many Requests” errors due to shared capacity limits.
Priority Processing (pay-per-token, SLA-backed low latency): A pay-as-you-go service tier that routes traffic through reserved compute, giving consistent low latency for business-critical, user-facing workloads without buying PTUs. At the time of writing, it is available on Global Standard and Data Zone Standard (US) deployments and requires recent model versions (2025-12-01 or later). It can be enabled per deployment in Microsoft Foundry, or set on individual API calls via the optional service_tier attribute (auto / default / priority) on the chat completions and responses APIs. Always confirm current model and region eligibility in the Microsoft Learn article “Enable priority processing for Microsoft Foundry Models.”
Pros: Predictable, low-latency responses with the simplicity of pay-per-token billing – a strong fit for bursty, business-hour, or latency-sensitive traffic where PTU commitment isn’t justified. Uses the same Standard quota pool, and can be layered on top of PTU for steady-state capacity plus an elastic priority lane for spikes.
Cons: Per-token pricing is higher than Standard PAYGO. Requires eligible deployment types and current model versions, so it is not a drop-in for legacy deployments. Like all PAYGO modes, it is still subject to TPM/RPM limits and the same throttling behaviour if quota is exhausted.
Batch (asynchronous): Offline job processing. You submit requests in bulk (e.g., via a file) and receive results after up to 24 hours.
Pros: Optimized for high throughput at a much lower cost (roughly 50% less per token than real-time requests at the time of writing). Batch jobs use separate “enqueued tokens” quotas, so they won’t interfere with interactive traffic.
Cons: Not suitable for real-time use – no immediate responses or latency guarantees. Requires extra orchestration (staging requests, handling outputs). At the time of writing, Batch does not support embedding models, so vector indexing jobs must use Standard mode – always check the Azure OpenAI documentation for the latest supported model list.
Provisioned Throughput (dedicated PTUs): Reserved, dedicated capacity. You purchase a fixed amount of capacity (Provisioned Throughput Units) and pay for it hourly, whether used or not.
Pros: Guaranteed throughput and consistent low latency, since you’re isolated from other tenants; suitable for high-volume services with strict SLAs.
Cons: Requires careful sizing of PTUs to match your peak demand – under-provision and you’ll still get 429s (now self-inflicted), over-provision and you pay for unused capacity. In addition, output tokens count more heavily against PTU usage (e.g., generative tokens from GPT-4 consume multiple capacity units each), so planning must account for both prompt and completion length.

To right-size your PTU, you’ll need an estimate of the following metrics:

Requests per minute
Average tokens per request
Peak concurrency
Prompt + completion token size

By plugging these into the Azure OpenAI PTU Calculator (linked in the References section), you can get a first estimate of the size of purchase you need to make based on your consumption.

Most production solutions use a hybrid approach: for example, Provisioned capacity for steady, critical real-time traffic, Priority Processing for latency-sensitive bursts that exceed PTU headroom, Standard for overflow or early-stage apps, and Batch for large-scale offline processing. As a rule of thumb: if a user is waiting for a response, use a real-time endpoint (Standard, Priority, or PTU). Use PTU when you need strict latency consistency at high, predictable volume; use Priority Processing when you need SLA-backed low latency without committing to PTUs; use Standard for everything else interactive. If a task can be handled asynchronously, offload it to Batch to reduce cost and keep interactive systems responsive.

Pitfall – Sizing for average load instead of peak burst. One company provisioned capacity only for typical throughput and was overwhelmed when traffic spiked ~3× beyond normal. They maxed out their PTU allocation, triggering a flood of 429 errors. Lesson: model your peak tokens-per-minute (TPM) and requests-per-minute (RPM), not just the average, and add a safety margin to avoid unexpected throttling.

Insight – Separate real-time and background workloads. An initial version of a news analytics bot processed all articles on demand, leading to slow, costly responses. The team later moved heavy processing to Batch jobs (pre-computing article embeddings and summaries), cutting end-user latency by 80% and halving costs.

[Diagram 1 – Capacity Model and Deployment]

2. Deployment Location: Where Does Inference Run?

After choosing the capacity model, decide where your Azure OpenAI instance is hosted. This affects latency, scalability, compliance, and model availability. Azure provides three options:

Global – Your endpoint isn’t tied to a specific region.
Pros: Maximum elasticity and often the best performance stability, since Azure can route traffic to any available regional capacity. You also usually get access to new model releases first on global endpoints.
Cons: Data is processed across multiple regions (may violate strict data residency needs). Troubleshooting can be more complex when calls are served from various locations.
Data Zone – Inference is restricted to a defined geography (e.g., all Azure EU regions).
Pros: Ensures data stays within a specific political boundary for compliance (e.g., GDPR) while retaining some elasticity across multiple regional datacenters in that zone.
Cons: Smaller capacity pool than Global, and possibly a slight delay in getting certain new model versions compared to global rollout. A good balance if you require geographic control without completely sacrificing scalability.
Regional – Inference runs in a single Azure region that you choose.
Pros: Strict data residency and potentially minimal latency if your users are near that region.
Cons: No ability to burst to other regions – you are limited to one datacenter’s capacity. If that region faces high load or an outage, your service is impacted. Some model versions or features may also take longer to become available in a given region than on Global. For current model and region availability, refer to the Azure AI Foundry – Model Deployment Types documentation in the References section.

Pitfall – Over-constraining location without need. Some teams unnecessarily default to a narrow deployment. For instance, a company chose a local Regional deployment out of habit, then discovered the Azure OpenAI model they needed wasn’t available in that region for several months, forcing a last-minute migration to a broader Data Zone. Lesson: unless you have a clear compliance or latency requirement, start with a less restrictive option (Global or multi-region Data Zone) to avoid capacity or availability issues.

Example: One enterprise began with a Global deployment for performance and simplicity, but later had to move to an EU Data Zone to meet GDPR rules, trading some elasticity for compliance. Conversely, a team that started with a single-region setup ran into scaling limits and delayed feature rollouts; they eventually reconfigured to a Data Zone to tap into a larger resource pool.

3. Governance Layer: When a GenAI Gateway Is Needed

As Azure OpenAI usage scales to multiple applications or teams, direct API calls from each app become hard to manage. A central API gateway (such as an Azure API Management instance in front of the OpenAI endpoints) is recommended to enforce enterprise policies and provide a single point of oversight. A gateway enables:

Central Authentication & RBAC: Use Microsoft Entra ID for authentication instead of distributing API keys, and enforce role-based access so each app or team only accesses allowed resources.
Usage Quotas & Throttling: Allocate token or request quotas per application or client. This prevents one service from monopolizing the OpenAI service and can smooth out bursts by applying backpressure (e.g., returning 429s or queueing requests) before Azure OpenAI’s own limits are exceeded.
Intelligent Routing: Direct traffic flexibly – route most requests to a primary model deployment, send a fraction to a new model version (canary), or fail over to a secondary region or the Standard tier if the primary is constrained.
Unified Monitoring & Cost Management: Log all requests in one place. This gives you a clear view of consumption by team or feature, helps with debugging, and supports internal charge-back or cost governance.

A gateway doesn’t make the model faster or more scalable by itself – it’s about control, security, and manageability, not raw performance. That said, for any multi-team or multi-application scenario, a gateway quickly becomes essential to avoid “shadow AI” deployments and chaotic usage patterns.

When to add: Introduce a GenAI gateway once more than one application or team is using the service, or whenever you need to enforce cross-cutting policies. Implementing it early can save a lot of headaches compared to retrofitting it later.

Example: An e-commerce company initially allowed several departments to call the Azure OpenAI API directly. Soon, they had no clear visibility into who was using how many tokens, and costs spiked unexpectedly. They deployed an APIM gateway to require proper authentication, impose per-app quotas, and log usage metrics. The result was rapid identification of the top token-consuming app (preventing it from starving others) and much better cost control.

[Diagram 2 – GenAI Gateway Functionalities and deployment Location sprectrum]

4. Grounding Strategy: When to Use RAG (Retrieval-Augmented Generation)

Many enterprise use cases demand that the model’s answers include specific internal knowledge or citations. Retrieval-Augmented Generation (RAG) is the solution when your AI needs to ground its responses in external data. RAG works by retrieving relevant content from your own data sources and providing it to the model in the prompt:

Document Indexing: First, collect your reference documents (files, knowledge bases, etc.) and break them into chunks, optionally adding metadata (titles, tags). Store these in a vector index or search database after transforming each chunk into an embedding vector.
Relevant Retrieval: For each user query, create an embedding of the question and retrieve the top-matching document chunks from the index via similarity search.
Augmented Prompt: Prepend or append the retrieved text snippets to the model’s prompt (often along with instructions to use them for reference).
LLM Response: The model (e.g., GPT-4) processes the augmented prompt and generates an answer that incorporates the provided reference information (often with source citations if required).

By injecting enterprise data at prompt time, RAG can significantly reduce hallucinations and increase the factual accuracy of outputs. Users get answers that reflect real data you’ve provided, rather than just the model’s training data.

However, RAG adds complexity, latency, and cost. You must maintain additional infrastructure (embedding computation and a vector store or search index). Each query now has extra steps, typically adding 200–500 ms to response time. The vector database and compute for embeddings also incur costs – industry estimates often put a full RAG pipeline at 3–5× the cost of using the base model alone, especially at scale. You’ll need a strategy for keeping your index updated as source data changes, and robust handling for cases where no relevant data is found.

When to use RAG: Use RAG if your model must reliably incorporate proprietary, dynamic, or highly specific information that isn’t part of its training data, or when you need to provide source references for answers. If your scenario is more open-ended or doesn’t require up-to-date factual grounding, you can often skip RAG to keep the system simpler and faster.

Pitfall: Some teams adopt RAG by default, which can slow development and complicate the system unnecessarily. It’s often better to start with a simpler approach and add RAG later if you find the model’s answers need external support.

Examples: One consulting firm added RAG to their internal Q&A bot to leverage proprietary research. Answers became more accurate, but query latency jumped to ~5 seconds due to the retrieval overhead, forcing them to optimize their embeddings pipeline and caching. Conversely, a health company launched a chatbot without RAG and discovered it gave incorrect medical answers because it couldn’t reference the latest policy documents – a failure that a RAG approach could have mitigated.

[Diagram 3 – RAG High Level Flow and Anatomy]

5. Quota Engineering: Avoiding Bottlenecks and Throttling

The Azure OpenAI Service imposes quota limits to protect the system. If you don’t plan for these, they can become points of failure in production. Key limits include:

Tokens per Minute (TPM): Maximum tokens (input + output) your deployment can process per minute (your primary throughput cap).
Requests per Minute (RPM): Maximum number of API calls per minute.
Concurrent Requests: Maximum number of requests processed simultaneously.
Model-specific limits: Certain model types have their own constraints (e.g., the maximum request rate for GPT-4 may be lower than for GPT-3.5 due to higher computational load).

If you exceed these limits, Azure OpenAI will return errors – usually HTTP 429 (Too Many Requests) for quota exhaustion or 503 (Service Unavailable) if the service is stressed. In other words, hitting a quota isn’t a theoretical worry; it will result in rejected requests once you cross the threshold.

Quota Tiers and Deployment Types

Azure OpenAI uses a tiered quota system where limits depend on your subscription’s access level. Specific numeric quotas change frequently, so always verify against the Azure OpenAI Quota Guide (linked in the References section).

Tier 1 (Default): Standard quota allocations suitable for development and moderate production workloads. At the time of writing, GPT-4 deployments in Tier 1 commonly start at quotas in the low tens of thousands of TPM and around a thousand RPM, but exact values vary by region and model – always check the current Azure OpenAI Quota Guide for live numbers.
Tier 2 and Above: Higher quotas available through approval processes, typically for enterprise customers with demonstrated high-volume needs. These tiers can provide significantly more capacity than Tier 1; consult the Quota Guide for current multipliers and approval paths.

Standard (pay-as-you-go) deployments share regional quota pools and are subject to TPM/RPM limits that can vary by region and model. Provisioned Throughput (PTU) deployments operate differently – you purchase dedicated capacity measured in PTUs, and your throughput is determined by your PTU allocation rather than by TPM/RPM limits. PTUs still have implicit rate limits based on the processing capacity of your purchased units.

The Batch API uses a separate quota system with “enqueued tokens” limits, allowing much higher total throughput (often millions of tokens per day) but without real-time guarantees.

Best practices to manage quotas:

Capacity planning: Calculate your peak usage requirements (e.g., max prompt+completion tokens per request × peak requests per minute). Ensure your chosen plan or quota can handle this, or request an increase in advance.
Design for bursts: Traffic often comes in waves. Aim to operate well below your limits so you can absorb sudden surges. As a guideline, keep usage under ~70% of your TPM/RPM limits during normal operation, leaving headroom for peaks. If your usage is spiking above 85% regularly at the 95th percentile, it’s time to scale up capacity or optimize usage.
Graceful degradation: Implement exponential backoff (with jitter) on the client side when retries are necessary. This prevents a stampede of retries (a “retry storm”) that would otherwise compound the load problem. At the platform level, use queues or token-bucket rate limiters (possibly in your APIM gateway) to smooth bursts.
Circuit breakers: Have fallback plans for extreme scenarios. Temporarily disable non-critical features or queue requests when approaching critical limits to prevent a total outage.

Example: A fintech company’s trading chatbot ran fine in testing, but during a market surge their question volume tripled. This breached their tokens-per-minute quota and led to a flood of 429 errors. Worse, their code immediately retried each failed request without delay, intensifying the load and effectively causing a self-inflicted denial-of-service outage. They resolved it by using exponential backoff and partitioning users across multiple deployments.

[Diagram 4 – Quota Engineering]

Final Perspective and Key Takeaways

Ultimately, building a production-grade Azure OpenAI solution is much more about well-structured cloud architecture than about the model itself. An advanced model can underperform in a fragile setup, while even a basic model can excel in a solid architecture.

Key takeaways from Part 1:

Plan for peak loads. Design for the worst-case traffic (and add buffer), not the average. If you need strict performance guarantees, invest in dedicated capacity early.
Avoid unnecessary constraints. Don’t lock into a restricted deployment unless required by compliance or latency – new models and extra capacity reach global deployments first.
Use real-time vs. batch wisely. Real-time endpoints (Standard, Priority, or PTU) should be reserved for interactive, user-facing tasks; move large or non-urgent jobs to Batch for roughly half the cost per token (at the time of writing).
Pick the right real-time tier. Use Priority Processing when you need SLA-backed low latency without committing to PTUs, PTU for high, predictable volumes, and Standard for everything else interactive.
Implement a gateway for scale. If you have multiple applications or teams, use an API Management gateway for authentication, rate limiting, logging, and multi-region routing.
Adopt RAG only if needed. Don’t introduce a retrieval-augmented generation layer unless your application truly demands external data or source citations.
Engineer for limits and failure. Treat rate limits and error handling as fundamental design criteria. Build in monitoring, backoff, and fallback mechanisms so the system degrades gracefully.

In short, succeeding with Azure OpenAI in production means treating it as a full-stack architecture challenge rather than just an API integration. By proactively addressing scalability, deployment, governance, data grounding, and quotas, you can turn a promising demo into a stable, cost-efficient, and compliant AI platform.

In the next part, we’ll explore how to put these principles into practice – including multi-region architectures, cost-sharing strategies for teams, advanced monitoring/logging setups, and other patterns for making Azure OpenAI a robust enterprise service.

Decision Matrix: Quick Reference

Use this matrix as a fast first cut on the five Part 1 decisions. It is not a substitute for a full design review, but it captures the trade-offs most teams need to evaluate up front.

Decision	Choose this when…	Avoid when…	Primary risk
Capacity – Standard (PAYGO)	Dev/test, unpredictable or bursty traffic, MVPs, overflow	You need guaranteed latency or strict SLAs	429 throttling under shared load
Capacity – Priority Processing	Latency-sensitive, business-critical real-time traffic where you don’t want PTU commitment; burst lane on top of PTU	Deployment type / model version isn’t eligible; cost-sensitive, low-priority workloads	Higher per-token cost than Standard; still PAYGO quota-bound
Capacity – Batch	Async jobs, embeddings refresh, large offline summarization	User is waiting; or model is unsupported (e.g., embeddings, at the time of writing)	Up to 24h turnaround; orchestration overhead
Capacity – Provisioned (PTU)	High-volume real-time workloads with strict SLAs and predictable load	Demand is low or highly variable	Over-/under-provisioning costs
Deployment – Global	You want widest model availability and best elasticity	Strict data residency or regulatory constraints	Less control over where data is processed
Deployment – Data Zone	Geographic compliance (e.g., EU/US) with some elasticity	Single-region residency is mandated	Some lag on newest model versions
Deployment – Regional	Strict data residency or co-located low-latency users	You need to scale beyond one region’s capacity	Capacity ceilings and slower model rollout
Governance – GenAI Gateway	Multiple apps/teams, need RBAC, quotas, routing, central logging	Single small app where overhead exceeds benefit	Adds latency and another component to operate
Grounding – RAG	Need proprietary, dynamic, or cited answers	Open-ended creative tasks where freshness isn’t required	Latency, cost, and index freshness drift
Quota – Plan & Tier Up Early	You’re close to TPM/RPM ceilings or expecting growth	Your peak forecast is well below current quota	Last-minute throttling and outages

Tip: If you can only optimize for one decision in Part 1, start with capacity model and quota engineering – they are the two most common sources of production incidents we see in real deployments. Pairing PTUs (or Priority Processing) for steady, latency-sensitive traffic with Standard PAYGO for overflow is a pattern that consistently delivers both reliability and cost control.

Disclaimer

The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of Microsoft. The author is a Microsoft employee.

References

Enabling AI-Driven SAP Development with GitHub Copilot: Plans and Usage-Based Billing Transformation

AnuradhaKarnam — Mon, 08 Jun 2026 13:52:48 GMT

Introduction:

Empower SAP customers with a strategic understanding of GitHub Copilot offerings, including plan options, value realization, account models, and key considerations for enterprise adoption. Through a guided, step-by-step setup in Visual Studio Code, SAP developers will gain hands-on experience with GitHub Copilot and Copilot Chat in real-world development scenarios. In addition, a practical exercise demonstrates how to configure and optimize Copilot within Visual Studio Code enabling SAP teams to effectively adopt AI-assisted development and accelerate application delivery.

Imagine you are an SAP developer working within a fast-paced enterprise environment, tasked with delivering a new feature or extension for a business-critical application, such as SAP S/4HANA or SAP BTP. With limited familiarity with the existing codebase and tight delivery timelines, ensuring quality, performance, and reliability is essential. GitHub Copilot provides a powerful AI-assisted development experience that can help SAP developers accelerate delivery while maintaining high standards. It can interpret complex code, generate documentation, and assist in writing efficient, error-free code enabling teams to meet deadlines and deliver high-quality solutions with confidence.

GitHub Copilot plans for SAP Customers:

Starting June 1, 2026, GitHub is transitioning GitHub Copilot from a request-based billing model to a usage-based billing model. For SAP customers, this shift enables more granular cost alignment with actual AI usage across development teams, supporting improved transparency and budget control within SAP programs.

Organizations and enterprises can leverage this model to better manage consumption across SAP development scenarios such as S/4HANA extensions, BTP applications, and integrations while optimizing costs based on real usage patterns. Individual SAP developers will also benefit from flexible billing aligned to their actual Copilot usage.

GitHub Copilot Capabilities for SAP Development:

GitHub Copilot offers a range of capabilities designed to support SAP developers across the entire development lifecycle from coding and testing to collaboration and deployment.

GitHub Copilot in the CLI: SAP developers can use a chat-like interface directly in the terminal to interact with command-line tools. Copilot provides command suggestions and explanations, helping streamline development workflows for SAP integrations, deployments, and automation tasks.

AI-Generated Pull Request Summaries: Copilot generates intelligent summaries of pull requests, highlighting key changes, impacted files, and areas requiring attention. This enables SAP teams to accelerate code reviews and improve collaboration especially in complex enterprise environments. (Not available in the Free plan.)

GitHub Copilot Extensions
Copilot Extensions allow SAP customers to integrate external tools and systems such as SAP BTP services or other enterprise platforms into the development workflow. These extensions can be customized and shared to support organization-specific SAP scenarios.

Custom Instructions
SAP teams can tailor Copilot responses by providing context about development standards, tools and project requirements ensuring outputs align with SAP best practices and enterprise guidelines.

GitHub Copilot Memory (Public Preview)
Copilot can learn from and retain context about a repository, improving the relevance and quality of suggestions. This is particularly valuable for SAP projects with complex codebases and domain-specific logic.

GitHub Copilot Spaces
Organize SAP project assets such as code, documentation, and specifications into contextual “Spaces.” This ensures Copilot delivers responses grounded in the appropriate SAP business and technical context.

GitHub Copilot in GitHub Desktop
Automatically generate commit messages and descriptions based on SAP code changes, improving consistency, traceability, and developer efficiency.

GitHub Copilot Agents for SAP Development:

GitHub Copilot Chat in Visual Studio Code provides specialized agents designed to support different stages of the SAP development lifecycle ranging from planning to implementation and knowledge exploration.

Agent (Execution Agent)
Use the Agent when you need to implement a specific SAP development task, such as building extensions, integrations, or enhancements for SAP S/4HANA or SAP BTP.
The Agent can autonomously identify relevant files, propose code changes, execute supporting commands, and iteratively refine outputs to complete the task efficiently.

Plan (Planning Agent)
Use the Plan agent when you want to define a structured, step-by-step approach before implementation. This is particularly useful for SAP scenarios requiring careful design such as complex integrations or multi-system workflows. The Plan agent breaks down requirements into clear steps that can be executed by the Agent.

Ask (Knowledge Agent)
Use the Ask agent to explore SAP-related code, development patterns, or general technical concepts without making changes. This is ideal for understanding unfamiliar codebases, learning new SAP development paradigms, or clarifying architecture and best practices.

Implementing GitHub Copilot in SAP Environments:

SAP organizations can follow a structured approach to successfully set up and scale GitHub Copilot across development teams:

Subscribe and Select the Right Plan
Begin by subscribing to GitHub Copilot and selecting the appropriate plan (Business or Enterprise) based on your SAP landscape, governance needs, and scale of adoption.

Establish Governance and Policies
Define organizational policies to control how GitHub Copilot is used across SAP development scenarios. This includes enabling or restricting specific features to align with compliance, security, and SAP development standards.

Configure Secure Networking
Ensure secure connectivity by configuring proxy servers or firewalls to allow required Copilot endpoints. SAP customers may also need to manage SSL certificates to align with enterprise security requirements.

Provision Access to Development Teams
Enable GitHub Copilot for selected SAP developers or teams such as those working on SAP BTP extensions, integrations, or modernization initiatives. A phased rollout can help identify challenges and demonstrate early value before scaling organization wide.

Drive Adoption Across SAP Teams
Establish a structured enablement strategy including training, best practices, and internal champions to promote effective usage of Copilot within SAP development workflows. A self-service licensing model can further accelerate adoption.

Support Developer Authentication
In enterprise environments, ensure SAP developers complete the required authentication steps to access Copilot from their development tools, such as Visual Studio Code.

Enhance the Copilot Experience
SAP organizations can further optimize value by:

Integrating knowledge bases to provide SAP-specific context (Enterprise plan)

Customizing Copilot through tailored AI models aligned to SAP development needs

Leveraging Copilot Extensions to integrate SAP tools and other enterprise systems into the development workflow

Set Up GitHub Copilot in Visual Studio Code:

For SAP developers, setting up GitHub Copilot is a simple process:

Ensure you are using the latest version of Visual Studio Code to support modern SAP development workflows (e.g., SAP BTP and full-stack development).

In the Status Bar, select the GitHub Copilot icon and choose Use AI Features to begin setup.

If your account is already authenticated, select Set up Copilot to complete activation.

Follow the guided steps to authorize Copilot within your development environment.

If no subscription is assigned, SAP developers will be onboarded to the GitHub Copilot Free plan for initial evaluation.

Once setup is complete, GitHub Copilot is ready to assist with SAP development tasks such as code generation, documentation, and optimization.

Customize GitHub Copilot Settings for SAP Development:

SAP developers can tailor GitHub Copilot behavior to align with enterprise development standards and project requirements:

Access Settings by selecting the gear icon in the lower-left corner of Visual Studio Code.

Navigate to GitHub Copilot configurations, organized into key areas:

Code Editing Settings
Configure inline code suggestions, next-edit predictions, and language-specific behaviors to support SAP development languages and frameworks.

Chat Settings
Customize how Copilot Chat behaves, including terminal integration helpful for managing SAP build, deployment, and integration tasks.

Agent Settings
Control advanced capabilities such as agent mode, request limits, and tool approvals to align with SAP governance, security, and compliance requirements.

Selecting Where GitHub Copilot Agents Run in SAP Development:

In addition to selecting the appropriate Copilot agent for a specific task, SAP developers can control where the agent executes using the Agent Target option in the Chat view. This capability determines how the agent interacts with SAP development environments and when results are delivered.

Local Execution
Runs directly within the developer’s environment with full access to the workspace, tools, and codebase. Ideal for SAP developers working on real-time coding tasks, exploring complex SAP codebases, or making controlled updates where step-by-step review is required.

GitHub Copilot CLI (Local Background Execution)
Executes tasks in the background on the developer’s machine. Suitable for SAP scenarios where predefined tasks such as script generation, automation, or batch updates can run while developers continue working on other SAP components.

Cloud Execution
Runs remotely in GitHub and integrates with workflows such as issues and pull requests. This option is well-suited for SAP teams collaborating on large-scale projects, enabling developers to delegate tasks, generate pull requests, and streamline code reviews across distributed teams.

Third-Party Execution
Uses external AI platforms (such as Anthropic or OpenAI) to run agents either locally or in the cloud. This provides flexibility for SAP customers to integrate advanced AI capabilities into their development workflows, depending on enterprise architecture and governance requirements.

Controlling Agent Permissions (for SAP Customers):

You can define how much autonomy your digital agents have by using the Permissions settings within the Chat experience. Adjusting these levels allows you to balance operational efficiency with governance and oversight an important consideration in SAP-driven business processes.

Permission Level	Description
Default Approval	Only low-risk, read-only actions are executed automatically. Most agent-initiated actions require user confirmation, ensuring control over business-critical operations and data changes.
Bypass Approvals	All agent actions are automatically approved without user prompts. This setting streamlines workflows but should be used with appropriate governance controls, especially in sensitive SAP environments.
Autopilot	Enables fully autonomous execution. The agent handles actions end-to-end, including responding to clarification requests, without user intervention. Ideal for well-defined scenarios, but requires strong trust, monitoring, and compliance alignment.

Conclusion:

GitHub Copilot offers SAP organizations a powerful way to modernize development through AI-assisted engineering. It combines intelligent code generation, contextual insights, and advanced features like agents, CLI integration, and memory to accelerate delivery while maintaining enterprise-grade quality and compliance.

It’s usage-based billing model further enhances value by aligning costs with actual adoption, providing transparency, scalability, and control across scenarios such as S/4HANA extensions, SAP BTP applications, and integrations. With a structured approach, covering plan selection, governance, secure configuration, and phased rollout, organizations can integrate Copilot effectively while meeting SAP-specific standards. Ultimately, Copilot enables SAP teams to boost productivity, enhance collaboration, and drive innovation at scale, delivering faster time to market and sustained business value.

Reference links:

Plans for GitHub Copilot - GitHub Docs

Usage-based billing for individuals - GitHub Docs

Usage-based billing for organizations and enterprises - GitHub Docs

Databricks Lakebase: The operational database for AI agents and apps

anishekkamal — Fri, 01 May 2026 18:23:22 GMT

Understanding the Evolution: From Lakehouse to Lakebase

The modern data landscape has long been characterized by a fundamental schism: Online Transaction Processing (OLTP) systems, designed for high-frequency, low-latency transactions in applications, and Online Analytical Processing (OLAP) systems, optimized for complex queries, reporting, and machine learning on vast datasets. This division historically necessitated intricate and often fragile Extract, Transform, Load (ETL) processes to move and synchronize data between these disparate environments, leading to increased complexity, data duplication, and governance challenges.

Databricks Lakehouse architecture emerged to unify data warehousing and data lake f

unctionalities for analytical workloads, offering the flexibility of data lakes with the performance and governance of data warehouses. However, a critical piece remained: native, high-performance OLTP capabilities directly within this unified environment. This is where Databricks Lakebase enters the picture, representing a significant evolution by bringing fully managed PostgreSQL OLTP capabilities directly into the Databricks Data Intelligence Platform.

Lakebase addresses the need for a single, governed platform that can seamlessly handle both transactional and analytical workloads, thereby simplifying data architectures, reducing operational overhead, and accelerating the development of real-time applications and AI agents. By integrating OLTP at the core of the lakehouse, Databricks aims to create a truly unified data and AI platform.

1.Visualizing the architectural shift: Lakebase integrates seamlessly within the Databricks Lakehouse ecosystem.

The Architectural Innovation: Separation of Compute and Storage

At the heart of Databricks Lakebase's efficiency and scalability lies its innovative architecture, which fundamentally separates compute from storage. Unlike traditional monolithic databases where these components are tightly coupled, Lakebase decouples them, offering distinct advantages:

Elastic Scaling and Cost Efficiency

The transactional compute layer in Lakebase is serverless and ephemeral, meaning it can scale up or down dynamically based on demand. This includes the ability to scale to zero during periods of inactivity, significantly optimizing cost by ensuring you only pay for the compute resources actively used. Data, on the other hand, is persisted directly into low-cost, durable cloud object storage (e.g., Azure Blob Storage) using open formats like Delta Lake. This design not only reduces storage costs but also prevents vendor lock-in and allows other engines within the Databricks platform to access the data directly.

Open Data Formats and Interoperability

By storing data in open formats, Lakebase ensures high interoperability within the Databricks ecosystem and beyond. This approach eliminates the need for complex and time-consuming ETL processes to move transactional data to the analytical layer, as the data is inherently accessible to both. This foundational integration streamlines data pipelines and provides a unified view of data across all workloads.

Key Technical Capabilities and Features

Databricks Lakebase offers a rich set of features that make it a compelling solution for modern data architectures:

PostgreSQL Compatibility: Lakebase provides full PostgreSQL semantics, including ACID transactions, indexing capabilities, and support for standard JDBC/psql clients. This familiarity allows developers to leverage existing skills and tools, minimizing the learning curve.
Fully Managed Service: Databricks handles the complexities of provisioning, scaling, patching, backups, and ensuring high availability, freeing up development teams to focus on application logic rather than database administration.
Managed Change Data Capture (CDC): A crucial feature, managed CDC ensures that operational data in Lakebase remains synchronized with Delta Lake tables for analytical consumption. This continuous synchronization is vital for keeping BI models and AI applications updated with the freshest transactional data.
Autoscaling (Lakebase Autoscaling): The latest iteration of Lakebase features intelligent autoscaling of compute resources. It dynamically adjusts Compute Units (CU) based on various metrics like CPU load, memory usage, and working set size, preventing performance bottlenecks and out-of-memory (OOM) issues. It also supports branching and instant restore, enhancing developer agility and operational resilience.
Databricks Apps Synergy: Lakebase is designed to serve as the transactional backend for Databricks Apps, enabling the creation and deployment of interactive applications directly on the platform, leveraging governed data and powerful analytics.

Governance, Security, and Cost Efficiency with Lakebase

Adopting Databricks Lakebase brings significant benefits in terms of data governance, security, and overall cost management, aligning with the principles of a modern data intelligence platform.

2.Reverse ETL with Lakebase simplifies data activation for operational analytics.

Unified Governance through Unity Catalog

One of Lakebase's most powerful integrations is with Unity Catalog, Databricks' unified governance solution. This integration provides a single pane of glass for managing data assets across the entire Databricks Data Intelligence Platform. Lakebase databases can be registered as catalogs within Unity Catalog, extending its robust governance framework to operational data. This means:

Consistent Access Control: Policies defined for your lakehouse data automatically apply to Lakebase, ensuring uniform security and access management across both operational and analytical workloads.
Centralized Auditing and Lineage: Unity Catalog provides comprehensive auditing capabilities and data lineage tracking for Lakebase assets, simplifying compliance and offering transparent insights into data flows.
Simplified Security Management: By unifying governance, organizations can reduce the complexity of managing security policies across disparate systems, enhancing overall data security posture.

Robust Security and Data Protection

Lakebase is designed with enterprise-grade security in mind, leveraging existing cloud infrastructure and Databricks' security features:

Network Integration: It integrates seamlessly with cloud networking services (e.g., Azure Private Link) for secure, private connectivity.
Identity Management: Integration with enterprise identity providers (e.g., Microsoft Entra ID) ensures secure authentication and authorization.
Data Encryption: Data is encrypted at rest and in transit, protecting sensitive information throughout its lifecycle.
High Availability and Disaster Recovery: As a fully managed service, Lakebase inherently provides features for high availability and point-in-time recovery, ensuring operational resilience.

Optimized Cost Efficiency

The architectural separation of compute and storage, coupled with advanced autoscaling capabilities, contributes to significant cost savings compared to traditional database architectures:

Pay-as-you-go Compute: With serverless and autoscaling compute, you only pay for the resources consumed during active processing, with the ability to scale down to zero when idle.
Low-Cost Storage: Leveraging economical cloud object storage for data persistence drastically reduces storage costs.
Reduced ETL Overhead: By eliminating the need for complex ETL pipelines between OLTP and OLAP, organizations save on infrastructure, development, and maintenance costs associated with data movement and transformation. This can lead to reported savings of 40-50% in many environments.

Lakebase in Action: Powering Real-Time Applications and AI Agents

Databricks Lakebase opens up new possibilities for building intelligent, data-driven applications that require both transactional capabilities and deep analytical insights. Its unified approach simplifies development and accelerates time-to-market for innovative solutions.

Real-World Use Cases

Personalized Recommendations: Build real-time recommendation engines that leverage fresh transactional data from Lakebase to provide immediate and highly relevant suggestions to users.
Customer Segmentation and Real-Time Updates: Maintain and update customer profiles and segments in real-time, enabling personalized experiences and targeted marketing campaigns.
Feature Stores for Machine Learning: Utilize Lakebase as a feature store to serve low-latency features to AI models, ensuring that predictions and decisions are based on the most current data.
Stateful AI Agents: Develop AI agents that can maintain conversational state and interact dynamically with users, using Lakebase as a reliable backend for transactional data.
Order Processing Systems: Implement operational applications that require high-frequency reads, writes, and updates, such as order management or inventory systems, directly on the Databricks platform.
Interactive Workflow Tools: Create interactive data applications and dashboards that allow users to both view analytical insights and perform transactional updates within the same environment.

A Practical Code Snippet

Developing with Lakebase feels familiar due to its PostgreSQL compatibility. Here’s a simple example demonstrating basic CRUD (Create, Read, Update, Delete) operations within a Lakebase table:

-- Create a schema for your application CREATE SCHEMA app AUTHORIZATION CURRENT_USER; -- Create a table to store session data for an AI agent CREATE TABLE app.sessions ( session_id UUID PRIMARY KEY, user_id TEXT NOT NULL, state JSONB NOT NULL, created_at TIMESTAMPTZ DEFAULT now(), updated_at TIMESTAMPTZ ); -- Create an index to optimize queries on agent status CREATE INDEX ON app.sessions ((state->>'agentStatus')); -- Insert a new session record INSERT INTO app.sessions(session_id, user_id, state) VALUES (gen_random_uuid(), 'u-123', '{"agentStatus":"active","score":0.82}'); -- Update an existing session's state UPDATE app.sessions SET state = jsonb_set(state, '{score}', '0.91'::jsonb), updated_at = now() WHERE user_id='u-123'; -- Query active sessions SELECT user_id, state->>'score' as current_score FROM app.sessions WHERE (state->>'agentStatus') = 'active';

This SQL snippet showcases how developers can interact with Lakebase using standard PostgreSQL syntax, enabling rapid application development within the Databricks environment.

The Lakebase Advantage: Performance and Reliability

Beyond its unified architecture, Lakebase is engineered for predictable performance and robust reliability, essential for mission-critical operational applications.

The radar chart above provides an opinionated comparison of Databricks Lakebase against traditional OLTP systems across several key attributes. Lakebase demonstrates superior performance predictability, dynamic scalability, cost efficiency, and ease of management, coupled with strong data governance due to its integration with Unity Catalog. Traditional OLTP systems, while effective for their specific purposes, often score lower in these cloud-native, unified data platform metrics.

Reliability Features for Business Continuity

Lakebase integrates several critical reliability features that ensure business continuity and data integrity:

Branching: This feature allows developers to create isolated, production-like environments for testing changes without affecting the main operational database. It promotes safer development practices and faster iteration cycles.
Instant Restore and Point-in-Time Recovery (PITR): In the event of data corruption or accidental deletion, Lakebase enables quick restoration to a previous state, minimizing downtime and ensuring data resilience.
High Availability: As a managed service, Lakebase is designed for high availability, with automated failover mechanisms and robust infrastructure ensuring continuous operation.

Validation and Troubleshooting: Ensuring a Smooth Lakebase Experience

Successful implementation and ongoing operation of Databricks Lakebase rely on proper validation and an understanding of common troubleshooting steps. This section provides a framework for ensuring your Lakebase deployment meets performance and reliability expectations.

An introductory video to Lakebase, explaining its core functionality and benefits for data apps and AI agents.

Key Validation Steps

After provisioning and configuring your Lakebase instance, it's crucial to perform a series of validation tests:

Connectivity Verification: Confirm successful connections from your applications or development tools (e.g., psql, JDBC clients) to the Lakebase instance. Ensure that Unity Catalog registration is visible and properly configured for governance.
Performance Baseline: Conduct baseline QPS (Queries Per Second) tests and monitor latency under expected load conditions. Validate that autoscaling events occur as anticipated and that performance targets are met.
Data Synchronization (CDC): Test the end-to-end data flow by inserting/updating records in Lakebase and verifying their timely appearance in Delta Lake tables via managed CDC. If reverse synchronization (Delta to Lakebase) is configured, validate that as well.
Governance and Security Checks: Confirm that Unity Catalog permissions are correctly enforced for Lakebase assets and that audit logs accurately reflect data access and modification events. Verify network security configurations (e.g., Private Link) are functioning as intended.

Common Troubleshooting Scenarios

While Lakebase is designed for stability, understanding potential issues and their resolutions is key to efficient operation:

Problem Area	Symptom	Potential Cause(s)	Troubleshooting Step(s)
Performance	High latency, slow queries, autoscaling not triggering as expected.	Inefficient queries, missing indexes, insufficient compute resources, working set exceeding memory.	Inspect query plans, add appropriate indexes, monitor CU utilization, review autoscaling logs, consider increasing initial compute capacity if persistently underperforming.
Data Sync (CDC)	Stale data in Delta Lake, sync job failures, data inconsistencies.	Incorrect Unity Catalog permissions, CDC configuration errors, network issues, regional feature limitations.	Verify Unity Catalog access for CDC process, check CDC job logs for errors, confirm network connectivity between Lakebase and Delta Lake, consult Databricks documentation for regional CDC availability.
Connectivity	Unable to connect from application, authentication failures.	Incorrect connection strings, firewall rules blocking access, misconfigured private endpoints, invalid credentials/tokens.	Double-check connection parameters, review network security group (NSG) and firewall rules, validate Private Link configuration, ensure correct user/service principal credentials.
Governance	Unauthorized access, unexpected data visibility, audit log discrepancies.	Incorrect Unity Catalog access policies, schema mismatches, misconfigured external locations.	Review and refine Unity Catalog grants on Lakebase catalogs and schemas, verify external location configurations, ensure consistent data object naming conventions.
Feature Limitations	Specific PostgreSQL features or extensions not working.	Managed environment restrictions, unsupported extensions.	Consult Databricks documentation for supported PostgreSQL versions and extensions in Lakebase. Adapt application logic to use supported alternatives if necessary.

By proactively monitoring and understanding these aspects, Cloud Solution Architects can ensure robust and efficient operation of Lakebase within their Databricks ecosystem.

Conclusion

Databricks Lakebase represents a pivotal advancement in data architecture, fundamentally reshaping how organizations approach operational and analytical workloads. By seamlessly integrating a fully managed PostgreSQL OLTP engine directly into the Databricks Data Intelligence Platform, Lakebase addresses the long-standing challenge of data fragmentation. This unification not only simplifies complex ETL processes and reduces operational overhead but also extends robust governance and security through Unity Catalog across the entire data estate. The innovative separation of compute and storage, coupled with intelligent autoscaling, delivers unparalleled cost efficiency and dynamic performance. For Cloud Solution Architects, Lakebase offers a compelling path to building scalable, real-time applications and sophisticated AI agents, leveraging fresh transactional data alongside comprehensive analytical insights—all within a single, consistent, and highly performant environment. This strategic evolution of the lakehouse architecture empowers enterprises to unlock new levels of agility, innovation, and data-driven decision-making.

Service Principals in Microsoft Power Platform

Shdsouza — Fri, 01 May 2026 17:18:09 GMT

Shared Passwords Are a Ticking Time Bomb

Let’s be blunt: if your Power Platform automation runs on a shared service account password that three people know, you are one resignation away from every flow going dark, one password reset, one MFA change… That is all it takes.

The fix? A service principal, a non‑human application identity in Microsoft Entra ID that authenticates with certificates, never logs in interactively, and keeps running no matter who leaves. In Power Platform, it shows up as an Application User in Dataverse and can own flows, manage Power BI datasets, run Dataverse operations, and power your CI/CD pipelines.

Unlike a traditional shared service account (which carries the risk of password expiration, MFA prompts breaking automation, and credentials being overshared), a service principal authenticates using certificates or client secrets, has no mailbox, no interactive login, and cannot be accidentally used by a person.

For organizations running Power Automate flows, calling APIs, running Power Platform Pipelines or managing environments programmatically, service principals offer a fundamentally more secure, auditable, and manageable identity. They enable least-privilege access, integrate cleanly with Conditional Access policies, and eliminate the single point of failure that comes with tying critical automation to an individual employee's account. This lack of tether to an individual account means workloads do not need to be reassigned once someone leaves your organization. Put more simply, if your Power Platform workloads are still running under a named user or a shared "svc_powerautomate@company.com" account, it's time to reconsider.

Microsoft Advisory: “Best practice is to use service principals as the preferred identity model for Power Automate wherever supported, because shared user‑based service accounts introduce security, audit, and operational risks.”

In this blog, we will highlight opportunities to strengthen your security posture across the Power Platform with Service Principals alongside ideas for when a Service Principal may not be applicable for your scenario.

Getting Started:

Setting up a service principal is straightforward. Everything is documented on Microsoft Learn:

🔗Register an app in Entra ID — Microsoft Learn

🔗Manage application users — Microsoft Learn

🔗Service principal owned flows — Microsoft Learn

There are also many good blogs about step-by-step setup of the service principal, assigning permissions and assigning to an application user we won't be covering the setup here.

Let's go into detail how you can utilize a Service Principal to secure your Power Platform workloads.

Where Service Principals Shine in the Power Platform

⚡ Power Automate

In Power Automate, service principals establish durable ownership and authentication for enterprise automation. Flows run under a non‑human application identity, eliminating dependency on individual users and preventing failures caused by password rotation, MFA enforcement, or user departure.

Flow Ownership:
Assign the service principal as the primary owner to ensure flows continue running regardless of personnel changes. Service Principal‑owned flows require either a Process license (~$150/flow/month, stackable up to 10 for 2.5M actions/day) or pay‑as‑you‑go billing via Azure.

Authentication:
Service principals authenticate using client credentials, removing the standard 90‑day connection expiry. Only the client secret or certificate has an expiration, which can be configured (up to 24 months). For production workloads, store secrets in Azure Key Vault with rotation alerts.

Dataverse Connector:
Dataverse is the only standard connector with native service principal sign‑in. Selecting Connect with Service Principal ensures all Dataverse actions execute under the application identity with full audit attribution.

Non‑Service Principal Connectors:
Connectors such as SharePoint, Outlook, and Teams require delegated user context by design. Where app‑only execution is required, the HTTP connector can be used to call Microsoft Graph with application permissions, introducing a premium dependency.

✓ Service Principal‑Friendly

✓ Microsoft Dataverse (native SP sign‑in)

✓ Custom connectors (app‑only OAuth)

✓ HTTP via Graph API (app permissions)

⚠ Requires User Context

⚠ SharePoint (standard connector)

⚠ Outlook / Office 365

⚠ Teams (many actions)

⚠ Planner, OneDrive

🔗Support for service principal owned flows - Power Automate | Microsoft Learn

🔗 Manage connections to Dataverse — Microsoft Learn

📱 Power Apps and Dataverse

Your Service Principal’s Application User executes Dataverse operations from flows triggered by model‑driven apps. Audit logs clearly separate automated changes from human activity. Assign custom security roles scoped to exact tables (skip System Admin), use separate Service Principalss per solution area, and know that canvas apps can trigger Service Principal‑backed flows behind the scenes.

🔗Create a Dataverse application user — Microsoft Learn

📊 Power BI

This is where Service Principals quietly save organizations from one of the most common Power BI failures: dataset refresh breaking because the owner left. Take over semantic model ownership via the REST API and refreshes never fail from expired tokens again.

Workspace access: add Service Principal as Member or Admin
Semantic model ownership takeover via REST API
Automated refresh from PowerShell, Logic Apps, Azure Data Factory, or custom apps
XMLA endpoint access for model deployment and DAX queries (Premium/Fabric)
App Owns Data embedding for external users without Power BI licenses

Requirement: Tenant admin enables “Service principals can use Fabric APIs”. Service Principal added to workspace. API refresh needs Premium, Premium Per User, or Fabric capacity.

🔗Automate Premium tasks with Service Principals — Microsoft Learn

🔗Enhanced refresh REST API — Microsoft Learn

🛠️ Application Lifecycle Management (ALM) with Pipelines

Power Platform Pipelines are a built-in option for application lifecycle management native to the Power Platform. Pipelines bring ALM automation and continuous integration and continuous delivery (CI/CD) functionality into a native service that's designed to be usable by all members of your low-code team, regardless of technical capability. To learn how to set up pipelines in Power Platform, Microsoft has some fantastic documentation as well as a learning path on Learn.microsoft to guide you through the process.

We can utilize Service Principals in Pipelines as well. By default, a pipeline deploys as the requesting maker, meaning the maker needs elevated permissions to deploy to the target environment. Delegated deployments with Service Principals allow deployment without the maker needing elevated permissions in the downstream environment. The pipeline can run as a service principal (or pipeline stage owner), allowing makers to deploy without needing elevated permissions in target environments like production. Approvals may be required for security reasons, and can be automated or manual depending on your security requirements.

🔗PAC CLI: createserviceprincipal - Microsoft Learn

🛡️ Alternatives for Secure Workloads

While service principals offer an avenue to securing most workload scenarios on the Power Platform, they cannot cover all workload scenarios. In these cases, there are alternative approaches.

Azure Logic Apps support system-assigned and user-assigned managed identities, allowing workflows to authenticate directly to Azure resources without storing or managing any login credentials. This can offer an option when your workload can live outside Power Automate.

Some teams opt to retain shared service accounts. This is not best practice, but when undertaken, there are steps to harden these accounts. Dedicated Entra Conditional Access policies to enforce MFA, restricting sign in locations and devices can provide additional protection. For password rotation, Azure Key Vault centralizes credential storage and enables automatic secret rotation, reducing the risk of stale or exposed passwords.

Each of these approaches can be layered or combined with service principals depending on your organization's risk tolerance, licensing constraints, and connector support limitations.

🔗Governing Entra service accounts — Microsoft Learn

All Your Options at a Glance

Not sure which approach fits? Here is every option compared — from the gold standard to the fallback you hope to leave behind:

Option	MS Rec?	Key Benefit	Main Tradeoff	Security
SP + Process License	Yes	Gold standard. Certificate auth, clean audit.	~$150/flow/mo. Solutions required.	Highest
SP + Flow Groups	Yes (GA May ’26)	1 license across up to 25 flows.	Shared 250K/day action pool.	Highest
SP + Pay-as-you-go	Yes	Available today. No upfront cost.	Variable cost. Azure sub needed.	Highest
Hybrid: SP + SA	Pragmatic	SP owns; SA for delegated connectors.	SA still exists for connections.	Med‑High
Hardened SA Only	No	Simplest and no migration needed.	Interactive login risk. MS discourages.	Low
Logic Apps + MI	Yes (diff product)	Zero credentials. Consumption billing.	Full platform migration required.	Highest

⚠ All costs are approximate and vary by enterprise agreement. Verify with your Microsoft representative.

Microsoft‑validated: The dedicated service account fallback is a supported approach, not a workaround. Any alternative to service principals would need to be designed and accepted at the customer’s own risk.

Summary

Service principals replace shared, user‑based accounts with a non‑human application identity that is secure, auditable, and resilient. Eliminating password risk, improving governance, and ensuring Power Platform workloads continue running independent of employee lifecycle events

across the entire platform. The result is higher security, operational stability, and governance consistency.

The Bottom Line

Service principals are not optional polish. They are how Microsoft expects you to run enterprise automation in 2026. One Entra ID app registration. Four products. Zero shared passwords.

✓ Blocking interactive admin logins is correct. No supported scenario requires it.

✓ Hybrid model when needed. Service Principals where supported, hardened service accounts where not. Both documented by Microsoft.

✓ Start with pay‑as‑you‑go. Pilot a batch. Measure costs. Then commit. No upfront purchase needed.

Authors: Sheldon Dsouza + Marc Lotorto | Contributors: Rasha Al-Silmi, Ahmed Shaalan, Josh Flicker

All guidance aligned with Microsoft Learn and validated by Microsoft Advisory, April 2026

The Journey of Copilot: From Setup to Mastery for Azure SAP customers

AnuradhaKarnam — Fri, 01 May 2026 17:17:14 GMT

Introduction:

GitHub Copilot integrates as an extension or plugin within developer tools commonly used in SAP and Azure scenarios, such as Visual Studio, Visual Studio Code, and other supported IDEs. These tools are often used alongside SAP development (e.g., ABAP, CAP, or integrations with S/4HANA and Azure services).

Before you begin, ensure you have access to Copilot, through an organizational license (common in enterprise environments).

Install GitHub Copilot

Step 1: Install Required Extensions

Open Visual Studio Code
Go to Extensions (Ctrl + Shift + X)
Install the following extensions:

GitHub Copilot
GitHub Copilot Chat
GitHub Copilot for Azure (Microsoft extension)

When installing the Azure extension, it may prompt you to install additional Azure tools, accepting all required components.

Step 2: Sign in and Authenticate

Sign in to your GitHub account
Sign in to your Azure account
Complete authentication in the browser
Return to VS Code

Both logins are required:

GitHub → enables Copilot
Azure → enables Azure resource access and tools

Step 3: Enable and Verify Setup

Open Copilot Chat (Ctrl + Alt + I)
Check that Copilot is active
Verify Azure integration by typing a test prompt:
What Azure resources are deployed and running in my subscription?

If you get a response → setup is successful

Step 4: Configure Azure Context (Important for SAP)

Set your Azure tenant / subscription (Entra ID)
Ensure correct environment for:

SAP on Azure (S/4HANA, SAP NetWeaver)
SAP BTP extensions

Optional: Enable Agent Mode for automation tasks (deployments, scripts)

Get Started in Your SAP Development Environment

Open your preferred IDE (Visual Studio, VS Code, or Eclipse with SAP tooling)
Access the Copilot chat or assistant panel within the IDE
Sign in with your GitHub account (and organizational account if required)
Start using Copilot in your SAP development scenarios

Use Copilot for SAP Workloads

Inline suggestions

Get real-time code suggestions for SAP-related languages (e.g., JavaScript, Java, ABAP extensions, CAP models)

Ask questions in chat

Understand existing logic, SAP APIs, or integration patterns (e.g., “Explain this service” or “How does this SAP function work?”)

Generate and improve code

Create boilerplate logic, unit tests, and integration code faster
Identify performance or design improvements in existing SAP code

Enhance with SAP Context

Provide additional context (files, APIs, or SAP objects) to improve suggestions
Optionally connect Copilot to SAP data or services using enterprise integrations
Use Copilot to support:

SAP BTP extensions
S/4HANA integrations
Fiori/UI5 development and APIs

Once you start interacting with Copilot, it acts as an AI assistant within your SAP development workflow, helping you write code faster, understand existing logic, and accelerate innovation across your SAP and Azure landscape.

The Hidden Layer: Network Configuration for SAP Customers

As you begin using GitHub Copilot within your SAP development and integration environment, you may notice performance differences, especially when working within corporate networks. In most cases, Copilot connects securely to GitHub services over the internet using HTTPS, without requiring additional setup. However, in SAP enterprise environments where strict governance, security policies, and compliance controls are in place, network traffic is often routed through proxies, firewalls, or VPNs.

What You Need to Know

Copilot may require additional configuration when operating behind corporate proxies or firewalls
Proxy settings can be configured:

Directly within your IDE
Or through environment variables such as HTTP_PROXY and HTTPS_PROXY

Authentication to enterprise proxies may require:

Basic credentials
Or enterprise mechanisms such as Kerberos-based authentication

Enterprise Considerations for SAP Landscapes

Organizations may require custom SSL certificates for secure outbound connections
Network security policies may restrict access to external services
Required Copilot and GitHub endpoints must be allowed to ensure connectivity

Why This Matters for SAP Customers

In SAP environments especially those involving S/4HANA, SAP BTP, or hybrid/on‑premise systems network security is tightly controlled. Proper configuration ensures that Copilot can securely interact with external services while still complying with enterprise security standards. Once configured correctly, Copilot integrates seamlessly into your SAP development workflow, enabling secure, reliable, and high‑performance AI-assisted development within your governed enterprise environment.

Configure Network Settings (if required) for Azure SAP Environments

In Azure‑hosted SAP landscapes (such as S/4HANA on Azure, SAP BTP, or hybrid environments), network configuration plays a critical role in enabling GitHub Copilot securely. Network setup is primarily required in enterprise environments where security controls such as proxies, firewalls, VPNs, or Azure networking policies are enforced.

Default Behavior

GitHub Copilot connects securely over HTTPS
No additional configuration is required in open network environments

Proxy & Enterprise Network Configuration

If your Azure SAP environment uses controlled outbound access:

Configure proxy settings:
- HTTP_PROXY
- HTTPS_PROXY

Directly within your IDE (Visual Studio, VS Code)
Or via environment variables:

Supported authentication methods:

Basic authentication
Kerberos (common in enterprise identity setups)

Additional considerations:

Ensure required GitHub/Copilot endpoints are allowed in Azure firewall or network security groups
Install custom SSL certificates if your organization uses SSL inspection

Note: Visual Studio typically inherits Windows/Azure VM proxy settings

Troubleshooting Network Issues in Azure SAP Scenarios

If Copilot stops responding or behaves inconsistently, the issue is often related to enterprise network controls in Azure or hybrid SAP architectures.

Common Causes

Proxy or firewall blocking outbound connectivity
SSL certificate validation failures
VPN or private network restrictions (ExpressRoute / private endpoints)

Quick Diagnostics: Test connectivity from your Azure VM or development machine:

curl --verbose https://copilot-proxy.githubusercontent.com/_ping

If using a proxy: curl --verbose -x http://PROXY:PORT -i -L https://copilot-proxy.githubusercontent.com/_ping

HTTP 200 → Connectivity is working

Errors → Network blocking or configuration issue

Recommended Troubleshooting Steps

Verify proxy settings are correctly configured
Check SSL certificates and trust chain
Review Azure firewall, NSG, or proxy rules
Validate required endpoints are reachable
Enable verbose logs or diagnostics in your IDE for deeper analysis

Best Practice for Azure SAP Customers

Adopt a structured troubleshooting approach:

Validate connectivity
Trace the network path (proxy, firewall, DNS)
Fix configuration issues systematically

This aligns with the governance and operational discipline already used in SAP and Azure environments.

Outcome: A Confident Copilot User in Azure SAP

By following this approach, you move beyond basic usage and gain full control of Copilot within your enterprise landscape.

You will be able to:

Deploy and use Copilot across Azure SAP environments
Integrate it securely within enterprise networking constraints
Troubleshoot issues with confidence using systematic diagnostics

Conclusion:

GitHub Copilot is no longer a black box, it becomes a trusted, secure, and intelligent AI assistant seamlessly integrated into your Azure and SAP development ecosystem. As you adopt it into your workflow, development becomes faster, cleaner, and more efficient. More importantly, you gain a reliable partner that enhances productivity and supports innovation, ensuring that you are no longer coding alone, but collaborating with AI to deliver better outcomes.

Reference links:

https://docs.github.com/en/copilot/how-tos/set-up/install-copilot-extension

Get Started with GitHub Copilot - Visual Studio (Windows) | Microsoft Learn

https://learn.microsoft.com/en-us/azure/developer/github-copilot-azure/get-started?pivots=visual-studio-code

Network settings for GitHub Copilot - GitHub Docs

Troubleshooting network errors for GitHub Copilot - GitHub Docs

GitHub Copilot for SAP ABAP in VS Code: Setup Guid... - SAP Community

VDI, Teams, and what’s changing in 2026: VBSS becomes VMSS, and eCDN lands in the core license

jchristie — Thu, 30 Apr 2026 07:50:02 GMT

Audience: Mission Critical customers running Microsoft Teams on virtualized desktop platforms (Citrix, AVD, Windows 365, VMware/Omnissa Horizon).

TL;DR: Two Teams-on-VDI changes are converging: VMSS is already in Public Preview today as the successor to VBSS in the new VDI solution for Teams (Microsoft Learn - Screen sharing), and Microsoft eCDN is now included in Teams core license. This post previews the guidance our Support for Mission Critical (SfMC) Cloud Solution Architects (CSAs) are already walking customers through - because the cost of finding these issues in production is always higher than finding them in a pilot.

Why we’re flagging this now

SfMC exists to get ahead of changes like these. The SfMC CSA role is built on a simple principle: be a trusted advisor embedded alongside the customer team, not a reactive support line. SfMC CSAs work hand-in-hand with platform, network, security and service-ownership teams to build a deep “know-me” picture of the customer - their gold-image strategy, their VDI vendors, their peering topology, their CAB cadence, the history of what was tried and what didn’t stick. That context is the reason a readiness review lands in weeks, not months: your SfMC CSA isn’t starting from zero, they’re starting from knowing the estate.

Goodbye VBSS, hello VMSS - and it’s here now

Teams on VDI has used Video Based Screen Sharing (VBSS) for years - an efficient, encoded video stream for screen shares. That approach is being replaced by Virtual Machine Screen Sharing (VMSS) as part of Microsoft’s New VDI solution for Teams.

This isn’t a future roadmap item - VMSS is available in Public Preview today across Azure Virtual Desktop, Windows 365, Citrix and Amazon WorkSpaces, with Omnissa following. Microsoft’s guidance and support matrix is live on Microsoft Learn: New VDI solution for Teams - Screen sharing. If you have users on a pilot ring on VDI, you can light this up now, simply by activating Public Preview for them.

Spot the screen sharing stream no longer being offloaded to client side slimcore

Support depends on three things moving together: the Teams client on the session host, the virtualization vendor’s optimization component (Citrix HDX / AVD Multimedia Redirection / VMware-Omnissa Media Optimization), and the endpoint client (Windows App, Citrix Workspace App, Horizon Client). Where any one of those lags, screen share quietly falls back to a lesser modality - users don’t raise tickets, they just tolerate worse quality.

Because VMSS is already in preview, there’s a real window to get this right before it becomes the default path. On Mission Critical engagements, SfMC CSAs are already sitting with customer teams on VMSS readiness reviews: confirming client and plugin versions across the gold-image estate, rebuilding CQD dashboards so the baseline survives the cutover, and flagging any inline network appliance that still assumes the old VBSS flow. The “know-me” picture the SfMC CSA has built up makes that work fast - they already know which plugin versions the desktop team is running and which CAB window the next image refresh lands in.

Microsoft eCDN is now in the core Teams license

Microsoft eCDN - previously a paid add-on - is now included in the Microsoft Teams core license. It’s a WebRTC-based peer-to-peer mesh that offloads large-scale town halls and live events from the corporate WAN by peering video between clients on the same site.

If the business case for the add-on never cleared, that objection is gone. But “included” doesn’t mean “working”. The failure mode we see is consistent: customers enable eCDN because “it’s free now”, but the peering never works - because the client-to-client path is blocked by security controls nobody remembers adding. The town hall runs, the WAN still saturates, the CIO asks why the thing that was supposed to fix it didn’t.

Example eCDN portal dashboard

The VDI infrastructure question

Both changes elevate something that has always mattered but rarely been tested: VDI-to-VDI network reachability. The new Teams client needs to talk to Microsoft 365 media endpoints (usually already open) and to other VDI instances on the same site for eCDN peering.

That second requirement is where customers are consistently caught out. Most VDI builds treat each session host as an island - east-west traffic between session hosts is blocked by NSG, hypervisor firewall, or micro-segmentation policy, because it was never needed. With eCDN in the box, it is now needed - and the blocks are often in places the virtualization team doesn’t own.

This is where working hand-in-hand with the customer team pays off. The SfMC CSA convenes the platform, network, and security owners, translates the platform change into each team’s language, and makes sure nothing falls through the gaps between them. The specific hostnames, IP ranges, UDP/TCP port requirements, and peering-group configuration are all on Microsoft Learn (links below) - the hard work is operationalizing them against your estate, and that’s the work your SfMC CSA is built to drive.

If two or more of these apply to your estate, book the conversation with your SfMC CSA now:

Client version sprawl - multiple Teams versions in flight across gold images, or a long tail of unpatched Citrix Workspace App / Windows App / Horizon Client.

Missing or partial CQD data - gaps in building/subnet mapping, “unknown” network location for a meaningful share of streams, dashboards still filtered on legacy VBSS modality tags.

Recent east-west firewall changes - new micro-segmentation rollout, zero-trust project, or NSG rule consolidation in the last 12 months.

Recent live-event pain - WAN saturation, buffering, or join failures on the last town hall.

No eCDN subnet map, or a map that predates your current site/subnet topology.

Proxy or TLS-inspection changes forcing Teams media through an inspection device rather than bypassing it.

VPN full-tunnel without eCDN VPN exclusion.

Upcoming large broadcast in the next 90 days.

Closing thought

VMSS is in Public Preview today and eCDN is already in your Teams license. The window to pilot, validate and harden is open right now - and it closes the moment either of these becomes the default path for your users.

That’s what Support for Mission Critical is built for: Cloud Solution Architects working shoulder-to-shoulder with your team as trusted advisors, investing the time to genuinely know your estate - your platforms, your people, your change windows, your risks - so that when a shift like VMSS or eCDN arrives, the remediation plan is already half-written. Not a ticket-shop. A partnership.

If you’re running Teams on VDI at scale and you haven’t had the VMSS + eCDN conversation with your SfMC CSA yet - that’s the next call to book.

References

New VDI solution for Teams - Screen sharing (VMSS, Public Preview) - https://learn.microsoft.com/en-us/microsoftteams/vdi-2#screen-sharing

New VDI solution for Teams (overview) - https://learn.microsoft.com/en-us/microsoftteams/vdi-2

Microsoft Teams for VDI - install requirements - https://learn.microsoft.com/en-us/microsoftteams/teams-client-vdi-requirements-deploy

Microsoft eCDN networking requirements - https://learn.microsoft.com/en-us/ecdn/technical-documentation/network-requirements

eCDN peering groups and restrictions - https://learn.microsoft.com/en-us/ecdn/how-to/set-up-peering-groups

Microsoft 365 URLs and IP address ranges - https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges

Enterprise Security Assessment: A Strategic Lens for Mission Critical Environments

lakprasad — Wed, 29 Apr 2026 21:34:39 GMT

Understanding Enterprise Security at Scale

Understanding security posture at scale requires more than isolated control reviews or point‑in‑time assessments. The Enterprise Security Assessment (ESA) helps organizations understand their security posture across Azure, Microsoft 365, and hybrid environments from a true enterprise perspective. Instead of assessing individual services or workloads in isolation, ESA provides a single, enterprise‑wide view of security.

By examining identity, data security, endpoints, threat protection, and cloud infrastructure together, ESA helps uncover gaps that often span multiple teams and platforms. This broader perspective enables clearer prioritization, stronger alignment across security teams, and a more resilient foundation for long‑term security improvement.

ESA complements other Microsoft assessments, such as workload‑specific reviews, by connecting the bigger picture - to align security priorities across teams and platforms, fostering a more cohesive and resilient security approach.

From Standard Engagement to Strategic Partnership

An Enterprise Security Assessment is typically delivered as a focused engagement designed to establish an enterprise‑wide view of security posture. At Microsoft, we begin by reviewing Secure Score insights, analyzing a defined set of core security datasets, and correlating those signals across Azure and Microsoft 365.

For many organizations, this approach works well. Collecting and evaluating these datasets provides a high‑level understanding of security posture, highlights common gaps, and identifies priority improvement areas. In standard enterprise environments, ESA delivers actionable insights with minimal disruption and sets a solid foundation for security improvements.

How ESA Evolves in Mission‑Critical Environments

In large or mission‑critical environments, security is often distributed across multiple teams and tools. Operational constraints, regulatory requirements, and business dependencies introduce complexity that standard assessments cannot fully capture.

For mission‑critical customers, ESA goes beyond a baseline review and becomes more consultative. This typically includes:

📝 Structured discovery sessions across multiple security domains

🤝 Deep‑dive workshops with specialized teams

🎯 Validation of findings against real‑world operating models

🔄 Iterative analysis to validate findings against real operational conditions

This ensures recommendations reflect how security is actually managed, not just how it is documented.

Why Going Deeper Matters to Customers

For organizations operating at scale, this consultative ESA approach delivers significantly more than a standard readout:

A realistic, enterprise‑wide understanding of security posture, grounded in actual configurations and operating models
Clear visibility into cross‑team dependencies and systemic risks
Prioritized recommendations aligned to existing licenses, third‑party tools, and regulatory requirements
A realistic, phased security roadmap focused on adoption, not theory

The result is a clear starting point for security improvements that teams can execute with confidence.

A Continuous Improvement Model

ESA is not a one‑time exercise. For most customers, it becomes the foundation for ongoing security maturity.

Once a baseline is established, future ESAs are faster and more efficient, allowing organizations to track progress, validate improvements, and maintain alignment as environments evolve. Over time, ESA functions as an annual enterprise security health check, supported by follow‑up reviews and continuous improvement.

In mission‑critical environments, this means:

The first ESA requires deeper engagement investment
Building cross-team alignment takes time
Future assessments become smoother and more efficient once a baseline is established

Over time, ESA functions as an enterprise security health check that supports continuous improvement. It works best when treated as a starting point for continuous improvement, and Enterprise Security Alignment.

What Customers Gain from an Enterprise Security Assessment

A true enterprise view
Visibility across identity, data, devices, cloud workloads, and threat signals - without losing sight of critical details.
A customized security roadmap
Recommendations aligned to existing licenses, third‑party tools, hybrid footprints, and regulatory requirements - making adoption realistic, not aspirational.
Momentum and measurability
Many organizations track progress using dashboards or scorecards to measure improvement and sustain focus over time.
Repeatability
Once a baseline is established, future ESAs become easier and more efficient - serving as a regular health check rather than a brand‑new effort.
A consultative model
ESA delivers far more value than a one‑time assessment by fostering collaboration, shared understanding, and long‑term alignment.

A Foundation for Continuous Improvement

Enterprise security is complex, especially at scale. In mission‑critical environments, security success depends on embracing complexity, aligning teams, and moving beyond a standard assessment playbook.

An Enterprise Security Assessment is more than a snapshot. It’s an opportunity to build alignment, inform strategy, and create a resilient security foundation that evolves with the organization.

SharePoint Automatic Version History Cleanup (Intelligent Versioning)

jeresmith — Sat, 09 May 2026 16:53:42 GMT

What is SharePoint Automatic Version History Cleanup?

SharePoint Automatic Version History Cleanup is a feature in Microsoft 365 (SharePoint Online and OneDrive) that automatically manages and prunes file version history based on the age of versions and file activity. It is part of the “Version History Limits” functionality that gives admins control over how many versions to keep and for how long. When this Automatic mode is enabled (often referred to as Intelligent Versioning), SharePoint will no longer retain every single version up to the static limit indiscriminately. Instead, it will “thin out” older versions over time, keeping a higher density of recent versions and progressively fewer versions as they age. This ensures that most day-to-day edits remain recoverable, while redundant or stale versions from long ago are cleaned up.

Crucially, automatic cleanup does not require administrators or users to manually delete versions or set specific limits for each library. In the traditional model (Manual versioning), admins or site owners had to configure each library to keep a fixed number of versions (with a minimum of 100) and possibly specify a time-based deletion for older versions. In contrast, the Automatic setting uses built-in logic to manage versions dynamically. Microsoft’s internal testing and customer feedback guided this feature to address the major pain point of runaway version storage while maintaining “strong recoverability” for files.

Key characteristics of Automatic (Intelligent) Versioning:

Time-based retention algorithm: It looks at the age of each version and the file’s edit frequency to decide which versions to keep. Recent changes are kept in detail, whereas older changes are pruned, keeping only periodic snapshots.

Dynamic, ongoing cleanup: As new versions are created, older ones are evaluated and trimmed automatically in the background. This is not a one-time job, but a continuous policy is applied to the library.

Wider recovery window with fewer versions: Users still have access to versions spanning a long time period (e.g. many months or years), but without the full count of every minor change. The system preserves important restore points (like the first version of each week or day), assuming those are more valuable for recovery than every tiny edit.

Storage space optimization: By cutting down on redundant older versions, organizations see dramatic storage savings. Microsoft reports up to a 96% reduction in version storage over a 6-month period using automatic trimming, compared to keeping all versions under a 500-count limit.

Still protective of current versions: The most recent versions (within the last days or weeks) are generally all retained. The current file version is never deleted by the system, and recent version history remains robust for auditing and quick rollback needs.

Applies to Office documents (and more): Intelligent versioning is particularly beneficial for Office files (Word, Excel, PowerPoint) that save frequently, but it works for any files in SharePoint/OneDrive.

How the Automatic Cleanup Algorithm Works

When Automatic version limit is in effect, SharePoint uses a built-in tiered retention algorithm based on version age. In simple terms, the older a version is, the less frequently it’s kept. Here is a summary of the default intelligent retention logic:

Age of File Version	Retention by Automatic Cleanup
0–30 days old	Keep all versions. Every saved version from the last 30 days is preserved (upto 500 versions). This ensures you can track all recent changes in detail.
31–60 days old	Keep hourly versions. For versions in this range, the system prunes away some duplicates, aiming to retain roughly one version per hour of edit activity. In practice, if multiple versions were saved within the same hour, only the latest from that hour might be kept.
61–180 days old (2–6 mo.)	Keep daily versions. Versions older than two months get further thinned out to about one per day, preserving a daily snapshot of the file’s state.
Over 180 days old	Keep weekly versions. Very old versions (beyond ~6 months) are trimmed to approximately one per week, maintaining a weekly snapshot over long periods.

This tiered approach means that if a file is actively edited, you’ll have all of its versions from the past month, then a representative sampling of versions as you go back in time (hourly→daily→weekly). In effect, the algorithm removes redundant intermediate saves that are likely low-value (e.g. dozens of near-identical saves due to auto-save in a short period) while still keeping a timeline of the document’s evolution. If a file hasn’t been edited in a long time, its last saved versions will remain available at least until they hit the weekly or daily thresholds.

Maximum Number of Versions: Even under Automatic mode, SharePoint will not keep more than 500 versions of a file. This is a hard cap that remains in place for now. If a file continues to be edited very heavily over months or years, hitting 500 versions, the oldest versions will be trimmed to honor the cap. In practice, however, most files are unlikely to hit 500 retained versions under the automatic algorithm, because many interim versions would already be pruned by age. The 500 limit mainly serves as a safety net.

Expiration Labels in Version History UI: Once you switch a library or site to Automatic limits, you may notice in the Version History view that older versions get an “expiration date” label. These dates indicate when a given version is scheduled to be removed by the algorithm. For example, a version might show “Expires on 5/10/2026”, meaning the system will automatically delete it on that date (unless it gets preserved longer due to other rules). The most recent version is never assigned an expiration date (it does not expire at all), and very new versions may show “Never expires” until they age beyond the no-trim window.

Example of Automatic Cleanup in Action

Imagine a project plan (Excel file) that multiple team members edit daily over the course of the year. Under the old policy (500 versions, no expiration), if the team saves changes frequently, they might hit 500 versions in a few months, after which SharePoint starts dropping the oldest versions on each new save. If the editing is less frequent, they might not hit 500 for a long time, but all versions (even trivial ones) from throughout the year remain, eating storage.

With Automatic version cleanup enabled, SharePoint will keep every version for the first 30 days of rapid collaboration, then automatically trim and compress the version history:

After a few months, you’ll still have complete daily snapshots of how the file looked each day, but not every single save from, say, 4 months ago.

After a year, you might have weekly snapshots remaining from the early months.

The team can restore the file to any week in the past year, or any day in the past 6 months, or any hour in the past 60 days, etc., giving ample recovery points.

The storage used by this file’s version history will be dramatically lower than it would be under the old scheme (potentially just a few dozen versions retained instead of hundreds). In Microsoft’s example, automatic trimming yields ~96% storage reduction for versions over six months.

From the user perspective, nothing special needs to be done — version cleanup happens behind the scenes. Users still go to Version History on a document and see a list of versions, but with fewer ultra-fine-grained ones as they get older. Admins benefit by not having to constantly monitor or manually delete old versions to free space.

Configuring Automatic Version History Cleanup in SharePoint Online

Setting up Automatic version cleanup requires adjusting your SharePoint Online versioning settings at the appropriate level. Here’s how to configure it:

Organization-Level Default Setting (SharePoint Admin Center)

To enable intelligent version management across your tenant, navigate to your SharePoint admin center Settings and Version history limits.

Once this is saved, SharePoint Online will use Automatic (intelligent) version limits by default on any new libraries created in your tenant. Existing sites and libraries, however, do not retroactively change just by toggling this setting. They will continue with their current versioning settings until you update them (see below).

Verifying the setting: It may take some time for the new setting to propagate. You can confirm that it’s in effect by creating a new document library on a site (after enabling Automatic) and checking the library’s version settings or testing with a file.

If for any reason you need to switch back to manual settings globally, you can do so similarly in the Admin Center by choosing the manual option and specifying the number of versions and expiration days (if any). By default that might revert to 500 versions, no expiration. You can also manage this via PowerShell (see next section).

Site-Level and Library-Level Configuration

There are scenarios where you might not want to use the organization’s default for every site or library. SharePoint allows breaking the inheritance:

Site-level limits: A SharePoint site (site collection) can have its own version history policy that overrides the tenant by default for all libraries in that site. However, as of now, Microsoft’s UI does not provide a direct way to set site-level versioning in the admin center. You must use PowerShell cmdlets to configure a site’s setting. For example, to enable Automatic mode on a specific site (if the tenant default is not already automatic), you would run:

This flags that site to use automatic version limits for new libraries. (Add the -ApplyToExistingDocumentLibraries switch if you want to apply it to all current libraries on that site as well. Otherwise, existing libraries remain as they were, and only newly created libraries on that site use the new policy.)

Library-level limits: Site owners or admins can configure individual document libraries to have their own version limit settings, overriding both site and org defaults for that library. This is done either through the Library Settings in the SharePoint site UI or via PowerShell. In the library’s settings page (under “Versioning settings”), modern SharePoint should expose fields for the version limit and expiration if the admin has allowed that. For example, you might set one specific library to manual 100 versions, while the rest of the site follows Automatic, or vice versa, depending on needs.

In PowerShell, you can use Set-SPOListVersionPolicy to manage a specific library’s policy. For instance, to turn on Automatic for one library:

Or to set a manual limit on a library (say 200 versions, no expiration):

You can also specify a time limit (ExpireVersionsAfterDays) in combination with the version count if needed.

Keep in mind that lowering version limits on an existing library does not instantly delete all the extra versions above the new threshold. Instead, SharePoint will trim them gradually as new versions are added, to avoid large sudden deletions. According to Microsoft, if you reduce a library’s limit from 500 to 300, the next time someone edits a file that has, say, 500 versions, the system will purge up to 20 of the oldest versions on that save, then another 20 on the next save, and so on until the file complies with the 300 limit. This process prevents performance issues from mass deletion. (If you want immediate cleanup of a huge backlog of versions, consider using the trim job approach below.)

Using PowerShell for Tenant-Level Settings

For completeness, note that you can enable or disable the automatic versioning feature across the tenant via PowerShell as well. The relevant property is EnableAutoExpirationVersionTrim on the tenant:

To enable Automatic globally (equivalent to selecting Automatic in Admin Center):

This turns on the new “intelligent” version limits at the org level. After running this, you would typically also specify what you want the manual limits to be, in case you switch back or for any site still using manual. By default when turning on auto, SharePoint sets the global MajorVersionLimit to 500 and ExpireVersionsAfterDays to 0 (no time limit) behind the scenes.

To disable Automatic and revert to manual, you might run:

(This example sets a manual policy of 500 versions, no expiration. Adjust the numbers as needed, and note the UI minimums of 100 versions / 30 days if setting via UI.)

There are also PowerShell cmdlets to apply settings in bulk to sites. For example, you can iterate through all site collections and activate intelligent versioning for each one using a loop with Set-SPOSite -EnableAutoExpirationVersionTrim $true, as demonstrated in the SharePoint Diary blog. Use caution with such scripts, and run them in batches or during off-hours if you have many sites.

Trimming Existing Version History (On-Demand Cleanup Jobs)

Enabling Automatic mode will govern the retention of new versions going forward. But what about old versions that already exist from before you changed the setting? Those will not magically disappear the moment you switch modes. For example, if a library had 400 versions of a file and you turned on auto (or lowered the manual limit to 100), those 400 will still be there until new edits trigger the algorithm to clean up gradually. In some cases you might want to immediately reclaim storage by clearing out old versions in bulk, according to the new policy or other criteria. This is where SharePoint’s Version Trimming Jobs come in.

On-demand trimming allows admins to explicitly remove versions from existing files in a site or library. Microsoft provides PowerShell cmdlets to queue these jobs, which run asynchronously on the server to delete versions matching certain filters. There are three types of trim operations you can choose from:

Manual expiration trim: Delete versions older than a specified date threshold (e.g., remove all versions older than 180 days).

Manual count-based trim: Delete the oldest versions exceeding a specified count (e.g., keep the latest 100 versions and remove the rest).

Automatic trim: Apply the same intelligent algorithm to existing versions. This will simulate what the Automatic mode would have done and remove the excess versions accordingly (older ones may be outright deleted or assigned expiration dates depending on their age).

To use these, you’d run commands like:

1 # Example: Trim versions older than 180 days on an entire site

2 New-SPOSiteFileVersionBatchDeleteJob -Identity https://<siteURL> -DeleteBeforeDays 180

3 # Example: Trim to a count limit of 100 on a specific doc library

4 New-SPOListFileVersionBatchDeleteJob -Site https://<siteURL> -List "<LibraryName>" -MajorVersionLimit 100

5 # Example: Apply the automatic algorithm to trim versions on a site

6 New-SPOSiteFileVersionBatchDeleteJob -Identity https://<siteURL> -Automatic

These jobs permanently delete the matching versions (bypassing the recycle bin, so they cannot be recovered once trimmed). Microsoft therefore strongly recommends running a “What-if” analysis first: you can generate a Version Storage Report for a site or library and then simulate the trim to see how many versions would be deleted and how much space saved. This helps validate that you won’t accidentally remove something critical. The “What-if” process involves an auditing cmdlet (New-SPOSiteFileVersionExpirationReportJob) that produces a CSV of versions and their would-be deletion status under given rules, which you can review.

Trimming jobs run in the background and can take a significant amount of time for large libraries (possibly hours or days), particularly if thousands of versions are being evaluated. They tend to run during off-peak hours automatically. You can check the status of a job via PowerShell or the SharePoint admin center (there’s a page listing version trim jobs and their progress).

Important: Always inform site owners before trimming versions, and ideally take a backup or export of version history if the content is mission-critical. Once a version is deleted by a trim job, it’s gone for good (unless you restore the entire site from a backup). Trimming is irreversible and bypasses the recycle bin1.

Best Practices for Managing Version History in SharePoint Online

For IT administrators and power users managing SharePoint, here are best practices and considerations to get the most out of version history while avoiding pitfalls:

Adopt Automatic Versioning for Most Scenarios: Microsoft and real-world experience indicate that the Automatic (Intelligent) mode is optimal for the majority of use cases. It greatly reduces storage bloat while preserving the ability to recover recent and important versions. Make this your organization’s default unless you have a compelling reason not to. Many organizations have switched this on tenant-wide to curb runaway storage growth from versioning.

Use Manual Limits Where Necessary: There may be cases where a manual policy fits better. For example, a compliance-sensitive library might be required to keep all versions for at least 7 years, or conversely you might have a library of large video files where you only want the last 5 versions to save space. In such cases, set a specific manual limit (with or without expiration) appropriate to the scenario. For instance, you might configure 50 versions for a library with huge files, or “200 versions or 2 years” for a regulatory archive library. Document these deviations so you remember why they differ from the default.

Don’t Go Below 100 Versions/30 Days (UI Enforced Minimum): SharePoint Online’s interface won’t let you set extremely low limits – the rationale is to prevent administrators from accidentally setting a policy that could wipe out too much version history. Under the hood you can technically force lower values via APIs, but Microsoft strongly recommends against using less than 100 versions or trimming earlier than 30 days. Such aggressive limits could result in losing important recent edits and defeat the purpose of having version history. Stick to reasonable values that align with your recovery needs.

Educate Users on Versioning Impact: Ensure that site owners and users understand that versioning consumes storage. They should know that frequent saves (especially with AutoSave turned on) will generate many versions. This isn’t to discourage saving (the answer is not to turn off versioning!), but to reinforce why your organization manages versions the way it does. Users can also manually delete unnecessary versions from a file’s history if they know certain drafts or changes are not needed – though anything they delete manually goes to recycle bin for a period in case they made a mistake.

Leverage Reporting Tools: Take advantage of the Version Storage Usage report that Microsoft provides. This report can be run per site to see which libraries or files are consuming the most space via version history. It’s useful for identifying hotspots (e.g., a single file with 800+ versions taking 10 GB) and can guide you in applying proper limits or cleaning up. Before doing a large trim, always run the “what-if” analysis report to gauge impact.

Plan for Retention and Compliance: Be aware that retention policies and legal holds override version trimming. If a SharePoint site or an item is subject to a retention policy (through Microsoft Purview Compliance Center) or placed on eDiscovery hold, then no versions can be permanently deleted by any limit until that retention period is over. (Microsoft’s documentation explicitly states: “For items under a retention policy or hold, the document library’s versioning limits are ignored.”) This means your storage might continue to grow in those compliance scenarios. Best practice: coordinate with your compliance officers – if certain sites need infinite retention, you might leave their version limits looser (or just accept that storage will climb). Conversely, if you implement trimming, ensure it doesn’t conflict with any data retention requirements. The good news is that if a trim job encounters a version that is under retention/hold, it won’t delete it; it will tag an expiration date and then keep extending it until the hold is released, thereby not violating compliance.

Monitor Critically Important Documents: For content that is extremely sensitive or business-critical (e.g., an annually updated Policy document, or a legal contract file with tracked changes), you might want to keep more versions than usual or at least be very cautious with automated deletion. You can opt such libraries out of automatic trimming by setting a manual policy, or simply monitor their version history over time. Generally, Automatic mode is safe for even critical docs (since it preserves a broad range of history), but it’s wise to verify. If a particular version must be retained indefinitely (beyond what the algorithm would do), consider declaring the document a record or using a retention label on that version, which would prevent its deletion.

Conclusion

SharePoint’s Automatic Version History Cleanup (Intelligent Versioning) is a powerful feature that brings much-needed automation to version management. It keeps your SharePoint Online storage lean by removing redundant older versions while still providing a rich history of recent changes for recovery and audit purposes. By understanding how this feature works and following best practices — enabling it tenant-wide, adjusting specific libraries as needed, and considering organization-specific compliance requirements — IT administrators can significantly reduce storage costs and maintenance overhead.

With a sensible versioning strategy in place, you’ll ensure that users have the file history they need, when they need it, without letting “version sprawl” overwhelm your SharePoint environment. By configuring automatic cleanup and using the tools Microsoft provides (like reports and trim jobs), managing version history becomes a set-and-forget policy rather than a constant manual cleanup effort. This lets you and your users enjoy the benefits of versioning (easy recovery from mistakes, audit trails of changes) without the downsides of unchecked growth in your content databases.

With SharePoint Automatic Version History Cleanup, you can strike the right balance between data retention and storage efficiency – keeping your collaboration environments both agile and compliant.

Breaking the Shackles of Legacy Portals: Power Pages as Enterprise SaaS

PravinT — Mon, 20 Apr 2026 13:20:06 GMT

It's time to stop building "Portals" and start deploying Enterprise SaaS.

For years, enterprise teams building web portals have been shackled by rigid Dynamics 365 schemas and heavy, template-driven UIs. Traditional Power Apps Portals required developers to follow the portal's own schema structure—page templates, web forms, lists, content snippets—and inherit data models dictated by D365 modules. That era is over. Power Pages has evolved into a secure, enterprise-grade, low-code SaaS platform for creating, hosting, and administering business websites—and as of early 2026, two milestone GA releases have removed the last remaining constraints.

Here are six ways those shackles are broken:

🎨 1. UI Liberation with Single-Page Applications — Now GA

Single-Page Application support in Power Pages reached General Availability on February 8, 2026, starting with site version 9.8.1.x and later. Developers can now build fully custom, client-side rendered web applications using React, Angular, or Vue and deploy them directly to Power Pages using the Power Platform CLI. This is not a workaround or a bolt-on—Microsoft describes this GA release as making the SPA experience "production ready".

What this means in practice: the traditional portal constructs—ASP.NET and Liquid templates, web forms, lists—become optional implementation details, not architectural constraints. Your UI is completely custom and API-driven, calling Power Pages Web APIs for all data operations. The GA release also resolved issues where Power Pages platform styles could override custom CSS, and included updated guidance for authentication configuration and local development setup. Developers can run SPAs locally with full authentication and Web API access, enabling JavaScript hot reload and local debugging without deploying changes to the portal on every iteration.

At this point, the traditional portal schema becomes an implementation option—not a constraint.

(Ensure your Power Platform CLI is on the latest version for full capabilities.)

🗄️ 2. Data Model Autonomy — Your Entities, Your Rules

Power Pages connects to Microsoft Dataverse, but you are no longer forced to borrow a Dynamics 365 schema. Teams can design their own data model from scratch—whether it has five tables or hundreds with complex relationships—tailored to the business domain. Those custom Dataverse tables serve the SPA directly via Web APIs, without needing to build model-driven or canvas apps.

This is a fundamental departure. The platform uses the same shared business data stored in Dataverse that other Power Platform components can leverage, but your portal is no longer tethered to any pre-existing Dynamics module. You own your entity model entirely. The result: headless CMS flexibility backed by the security and reliability of Dataverse, without the overhead of a CRM schema you didn't ask for.

☁️ 3. Fully Managed Platform — No Infrastructure Burdens

Goodbye, custom web hosting and plumbing. Power Pages is a fully managed SaaS platform—Microsoft handles provisioning, hosting, CDN, scaling, and availability. Authentication is built in, with full support for enterprise identity providers including Microsoft Entra ID and Microsoft Entra External ID, along with table permissions and web roles enforcement on every API call. Organizations can also allow anonymous access or configure private sites as needed.

Even advanced backend needs are now covered natively. Server Logic in Power Pages reached General Availability on April 1, 2026, delivering native server-side JavaScript execution with the maturity, governance, and extensibility required for enterprise production workloads. Alongside GA, Microsoft announced two enhancements that reinforce enterprise readiness:

Governance control to disable external calls — administrators can restrict outbound connectivity from the Server Logic layer to comply with internal policies and regulatory requirements.

Support for unbound Dataverse custom actions — enabling deeper integration with existing business logic layers.

The result? Teams focus only on business logic, integrations, and user experience. As Hope Bradford, Senior Director of IT at Kelly Staffing, stated: "Power Pages lets us build personalized client experiences without managing complex infrastructure while maintaining enterprise trust and security." Kelly Staffing's Helix UX portal, built on Power Pages, Dataverse, and Power Automate, now handles over 38,000 client interactions per day.

🛡️ 4. Enterprise-Grade Security and Telemetry

Security and governance are first-class citizens on the platform. The 2025–2026 release wave introduced enterprise-grade controls for Power Pages including role-based access and authentication through Entra, Data Loss Prevention (DLP) rules for external data access, IP-based restrictions, maintenance mode options, and built-in diagnostics and monitoring dashboards. Across the broader Power Platform, Microsoft is investing in enterprise observability—the April 2026 update introduced alerting and data metrics in Power Platform Monitor (covering metrics such as app open success rate, time to interactive, data request success rate, and data request latency), enabling IT teams to define health thresholds, receive proactive notifications, and take guided action.

This level of governance—audit, monitoring, diagnostics—traditionally required significant custom engineering. Now it is out of the box.

💲 5. Scalable, Usage-Based Licensing

One of the most significant licensing shifts: Power Pages became its own product, decoupling from Power Apps licensing entirely. Both internal and external users now fall under the same licensing model, making Power Pages viable for internal use cases like HR services and request management—not just external portals.

The model is usage-based (Monthly Active Users), purchased as capacity packs per site:

Authenticated Users (Pre-paid): $200 per site/month for 100 users

Anonymous Users (Pre-paid): $75 per site/month for 500 users

Authenticated Users (Pay-As-You-Go): $4.00 per user/site/month, on-demand

Anonymous Users (Pay-As-You-Go): $0.30 per user/site/month, on-demand

Each authenticated-user subscription plan includes 2 GB database capacity and 16 GB file capacity. For applications serving tens of thousands of users, this capacity-based model is strategically superior to per-user or per-app seat licenses. Pay-as-you-go costs roughly twice as much as pre-paid capacity packs but suits seasonal or unpredictable usage patterns (e.g., tax season, annual HR enrollment).

Tradeoff to consider: Pre-paid packs require upfront commitment and do not roll over month to month, so organizations with highly variable traffic must carefully model usage to avoid over- or under-provisioning.

⚠️ Pricing disclaimer: The figures above are illustrative examples sourced from publicly available Microsoft documentation. Actual costs may vary based on customer type (enterprise vs. corporate), volume commitments, negotiated agreements, and account structure. Final pricing is determined through Microsoft account teams and contracts.

⚡ 6. Rapid Modernization with AI-Assisted Development

Power Pages now integrates directly with AI-assisted development workflows. Microsoft announced the public preview of the Power Pages plugin for GitHub Copilot CLI and Claude Code on February 24, 2026, providing an AI-assisted workflow for creating, deploying, and managing modern SPA sites on Power Pages. Developers can scaffold pages, configure data access, and wire up logic using natural language commands, dramatically reducing the time to modernize large enterprise applications.

SPAs are deployed using Power Platform CLI commands, and the entire development loop is designed to be streamlined for professional developers. This means that even large, complex in-house enterprise applications—hundreds of tables, complex relationships, tens of thousands of users—can be remodeled on Power Pages far more efficiently than legacy approaches required. You migrate your own custom model into Dataverse, build your SPA, wire up integrations, and the platform handles everything else.

The Bottom Line

If you are still managing custom Azure websites, maintaining SQL servers, or stitching together bespoke PaaS stacks for internal business tools, you are carrying unnecessary operational weight. Power Pages is no longer just a D365 portal. It is a fully managed, enterprise-grade SaaS platform that gives you total UI freedom (SPA support: GA since February 2026), native server-side logic (GA since April 2026), your own data architecture without D365 schema dependencies, built-in security and governance, and a licensing model that scales to enterprise volumes.

The industry is underestimating this shift. The shackles are off. Deploy, don't build.

LTRDisplay Control - End-to-End Implementation and Usage Guide

PravinT — Tue, 14 Apr 2026 14:00:42 GMT

1. Executive Summary

LTRDisplay is a Power Apps Component Framework (PCF) control for model‑driven apps that helps users browse Long Term Retention (LTR) data in a familiar grid‑and‑form experience.

GitHub SourceCode

The control is designed for archive‑first usage in Dataverse:

Fetch retained records with a selected view clause
Replay cached data without refetching
Open row details inside the same control
Review audit changes and related records
Minimize retained query calls through user‑local caching and lazy loading

This document provides:

Purpose and business value
Solution design and architecture
Import and validation steps
Full user manual
Repository fork and customization workflow

2. Purpose of the Control

2.1 Problem Statement

Retention data is valuable for:

Investigation
Support
Compliance
Historical analysis

However, users often require:

Fast browsing of retained records
Predictable filtering and navigation
Minimal load on retained query infrastructure
A form‑like experience for details, audit, and related data

2.2 LTRDisplay Objectives

LTRDisplay addresses these needs by:

Surfacing retained records directly in a model‑driven form
Reusing Dataverse views/forms metadata for familiarity
Introducing cache‑first interaction patterns
Supporting drill‑down across related records in one panel

3. Solution Design

3.1 Runtime Design

Main runtime behavior:

Archive‑focused mode by default
Selected view drives retained fetch clause
Grid renders from cached projection
Related records load only on explicit user action
Detail form and tabs render from metadata and selected row payload

3.2 Core Components

PCF shell:
LTRDisplayControl/index.ts
App state orchestration:
LTRDisplayControl/components/App.tsx
Grid and local filtering:
LTRDisplayControl/components/DynamicGrid.tsx
Metadata‑driven detail form:
LTRDisplayControl/components/DynamicForm.tsx
Dataverse access layer:
LTRDisplayControl/services/LtrService.ts
View/Form XML parsing:
LTRDisplayControl/utils/XmlParser.ts

3.3 Cache Model

Per‑user browser cache stores:

View datasets
Entity record dictionary by record id
Related datasets
Forms metadata
Relationship metadata

This enables:

Show Cached behavior without server refetch
Faster row‑open and navigation experience
Reduced retained query consumption

3.4 UX and Interaction Model

Fetch Archive button: calls retained fetch and updates cache
Show Cached button: reads cache and applies local filtering
Column filter flyouts: local filtering against projected rows
Detail tabs:
- Summary
- Record Data
- Audit History
- Related
Form switcher: choose available main forms for selected entity
Chrome toggle arrows: hide/show header and command bar behavior

3.5 Security Intent

LTRDisplay Main Form is intended for System Administrator users
Role‑based form visibility should restrict exposure to non‑admin users

4. Solution Packaging and Import

4.1 Distributed Artifacts

Latest packaged solution files:

solution/LTRDisplay_managed_latest.zip
solution/LTRDisplay_unmanaged_latest.zip

Unpacked inspection artifacts:

exports/unpacked_managed
exports/unpacked_unmanaged

4.2 Import in Power Platform (Recommended Managed Path)

Open target environment in Maker Portal
Go to Solutions
Select Import solution
Upload
solution/LTRDisplay_managed_latest.zip
Complete import and publish customizations

4.3 Post‑Import Validation Checklist

Validate the following:

LTRDisplay Main Form exists and is enabled
SystemUser form maps to
ltr_LTRDisplay.LTRDisplayControl
System Administrator can open the form
Non‑admin users do not get the admin‑targeted form
Fetch Archive returns retained rows
Show Cached replays cached rows
Record Data, Audit History, and Related tabs operate as expected

5. User Manual – Walkthrough

Step 1 – Open form with control visible

The form opens with Explorer – LTR and action controls.

Step 2 – Toggle form chrome for focus

Use the arrow controls to hide/show header and command bar.

Step 3 – Start retained fetch

Click Fetch Archive.
During loading, controls can be temporarily disabled.

Step 4 – Review fetched grid data

Rows appear in the grid after retained fetch completes.

Step 5 – Apply local column filter

Open a column filter, enter a value, and apply the filter.

Step 6 – Open a row into detail context

Select a grid row to open detail section and tabs.

Step 7 – Use form switcher

Open the detail form dropdown and choose alternate form layouts when available.

Step 8 – Inspect Record Data tab

Review key‑value field output.

Step 9 – Inspect Audit History tab

Review: Changed by, Changed on, Operation, Old and New value.

Step 10 – Use Related tab

Select relationship and click Load to fetch related rows lazily.

6. Fork and Customize the Repository

6.1 Fork and Clone

Fork the repository in GitHub
Clone your fork locally
Create a feature branch for your changes

6.2 Local Build Setup

From repository root:

npm install npm run build

6.3 Typical Customization Areas

Most teams customize:

App‑level behavior and UX flow
components/App.tsx
Grid columns and filter behavior
components/DynamicGrid.tsx
Detail tabs and rendering
components/DynamicForm.tsx
Dataverse query strategy
services/LtrService.ts
Styling and branding
css/LTRDisplayControl.css

6.4 Push Changes to Dataverse (Development Loop)

Use your existing PAC workflow in the target environment.

Typical sequence:

npm run build

pac pcf push --publisher-prefix ltr --incremental

pac solution publish

6.5 Export and Repackage

After validation in environment:

Export managed and unmanaged solution zips
Update:
- LTRDisplay_managed_latest.zip
- LTRDisplay_unmanaged_latest.zip
If needed, unpack for review under:
- exports/unpacked_managed
- exports/unpacked_unmanaged

6.6 Recommended Contribution Workflow

Keep changes scoped by feature branch
Run build before each push
Capture screenshots for changed UX behavior
Update docs in docs folder together with code
Submit PR with:
- Short validation checklist
- Test evidence

7. Operational Notes and Best Practices

Use managed package for consumer installation
Keep unmanaged package for internal customization scenarios
Treat retained fetches as expensive
Prefer cache replay when possible
Keep related loading on‑demand to control query volume
Preserve role‑based visibility for admin‑focused forms

8. Conclusion

LTRDisplay provides a practical archive exploration interface for Dataverse model‑driven apps with a strong focus on:

Usability
Cache efficiency
Operational control

By combining:

Managed distribution
Clear import validation
A straightforward customization model

Teams can adopt it quickly and evolve it safely for enterprise needs.

Getting Started with GitHub Copilot SDK

anishekkamal — Thu, 09 Apr 2026 21:43:21 GMT

GitHub Copilot has been a staple in developer workflows for a while — it suggests code, completes functions, and generally keeps you from looking up that one syntax for the hundredth time. But what if you could take that same intelligence and embed it directly into your own applications? That's exactly what the GitHub Copilot SDK lets you do.

Launched in technical preview in January 2026 and entering public preview on April 2nd, 2026, the SDK gives you programmatic access to Copilot's agentic engine. It's the same runtime that powers the Copilot CLI — just exposed as a library you can import into your own code, in your language of choice.

What Is the GitHub Copilot SDK?

The SDK is a multi-language library — Python, TypeScript, Go, .NET, and Java — that lets your application talk directly to Copilot's agent runtime. You don't have to build your own orchestration layer, manage model contexts, or figure out tool invocation protocols from scratch. All of that is handled for you.

Three core concepts are worth understanding upfront:

CopilotClient — your main entry point. It manages the connection to the Copilot CLI running in server mode.
Sessions — hold a persistent conversational context, meaning the agent remembers what's been said across multiple turns and can handle genuinely stateful workflows.
Tools — regular Python functions you register with the session. The agent calls them autonomously when it needs to interact with the outside world: query a database, hit an API, read a file.

For Python, getting started is a single command:

pip install github-copilot-sdk

You'll also need the Copilot CLI (https://docs.github.com/en/copilot/how-tos/set-up/install-copilot-cli) installed and accessible in your PATH, plus Python 3.11 or higher.

Read this on how to setup: copilot-sdk/python

Sending Your First Message

import asyncio from copilot import CopilotClient from copilot.session import PermissionHandler async def main(): async with CopilotClient() as client: async with await client.create_session( on_permission_request=PermissionHandler.approve_all, model="gpt-5", ) as session: done = asyncio.Event() def on_event(event): if event.type.value == "assistant.message": print(event.data.content) elif event.type.value == "session.idle": done.set() session.on(on_event) await session.send("Explain the difference between a list and a tuple in Python.") await done.wait() asyncio.run(main())

A couple of things to notice. The `async with` pattern handles all setup and teardown — no manual cleanup required. The `on_permission_request` parameter is required for every session; it's a handler the SDK calls before the agent executes any tool, allowing you to approve or deny the action. `PermissionHandler.approve_all` is the simplest option and perfect for getting started, but in production you'll want something more selective. More on that below.

Giving Your Agent Real Capabilities

Text in, text out is fine. But the real value of the SDK is that you can give the agent *tools* — functions it can call to interact with real systems. The `@define_tool` decorator makes this clean using Pydantic for parameter validation:

import asyncio from pydantic import BaseModel, Field from copilot import CopilotClient, define_tool from copilot.session import PermissionHandler class GetPriceParams(BaseModel): ticker: str = Field(description="Stock ticker symbol, e.g. MSFT") @define_tool(description="Fetch the current stock price for a given ticker") async def get_stock_price(params: GetPriceParams) -> str: # Replace with a real API call return f"The current price of {params.ticker} is $150.00" async def main(): async with CopilotClient() as client: async with await client.create_session( on_permission_request=PermissionHandler.approve_all, model="gpt-5", tools=[get_stock_price], ) as session: done = asyncio.Event() def on_event(event): if event.type.value == "assistant.message": print(event.data.content) elif event.type.value == "session.idle": done.set() session.on(on_event) await session.send("What's the current price of Microsoft stock?") await done.wait() asyncio.run(main())

When the prompt arrives, the agent works out that it should call `get_stock_price` with `ticker="MSFT"`, runs your function, and folds the result into its response. You don't wire up the function-calling logic yourself — the SDK handles dispatch, parameter parsing, and return value handling. Your job is just writing the function.

Streaming Responses in Real Time

If you're building anything interactive, waiting for a complete response before displaying anything feels slow. Setting `streaming=True` and listening for `assistant.message_delta` events fixes that immediately:

async with await client.create_session( on_permission_request=PermissionHandler.approve_all, model="gpt-5", streaming=True, ) as session: done = asyncio.Event() def on_event(event): match event.type.value: case "assistant.message_delta": print(event.data.delta_content or "", end="", flush=True) case "session.idle": done.set() session.on(on_event) await session.send("Write a Python function that validates an email address.") await done.wait()

Each chunk arrives as a `delta_content` string. Print it directly for a terminal UI, or accumulate chunks if you need the full response as a single string.

A Few Things Worth Knowing Before You Build

Billing: Every prompt counts against your GitHub Copilot subscription's premium request quota. If you're building automated workflows that fire off many requests — think CI pipelines or scheduled jobs — monitor usage. The SDK also supports BYOK (Bring Your Own Key), so you can plug in your own API keys from OpenAI, Azure AI Foundry, or Anthropic, which is a good option if you already have model deployments or want to separate usage billing.

Stability: The SDK is in public preview. It follows semantic versioning, so breaking changes come with a major version bump, but check the release notes between upgrades.

Permissions: For anything beyond experiments, replace `PermissionHandler.approve_all` with a custom handler. The SDK lets you inspect each tool request by kind — `shell`, `write`, `read`, `url`, `custom-tool` — and return `approved` or `denied` per request. That's where your security posture lives.

If You Want to Start — Start Here

One thing I've found working is that the best way to help customers adopt a technology is to actually use it yourself first. The Copilot SDK is a good candidate for that approach.

On the internal side, there are a handful of workflows that translate really well to agents.

Customer health reviews, for example — instead of manually pulling data from multiple tools before a call, you could build an agent that gathers recent Azure consumption,

Copilot seat usage, and open support tickets, then produces a plain-language summary. Account preparation used to mean 30 minutes of tab-switching; an agent with the right custom tools can reduce that to a prompt.

Incident prep is another one. When a customer hits an issue and needs a root cause summary fast, an agent that can read recent deployment logs, scan for known patterns, and draft a timeline is genuinely useful — both internally and as something you can walk through with the customer.

Building these tools yourself also gives you hands-on credibility when the architecture conversation comes up. You've already worked through the permission model, you've thought about BYOK, and you know where the rough edges are. That context matters more than any slide.

How to Help Customers Get Started

Most enterprise customers land in one of two places: they see Copilot as a developer IDE tool and haven't thought about embedding it in applications, or they've heard about agentic AI and don't know what a framework like this actually handles versus what they need to build themselves.

The clearest entry point is to start with a specific, bounded use case — not "let's build an AI agent" but "your support team answers the same 40 questions every week; let's route those through an agent that queries your internal knowledge base." That scope is small enough to deliver in a few days, concrete enough to measure, and immediately demonstrates how custom tools connect to real systems.

A few things worth surfacing early in the architecture conversation:

BYOK vs. Copilot subscription: Customers with existing Azure AI Foundry or OpenAI contracts can connect their own models. A quick win for enterprises who already have model deployments and don't want to provision Copilot seats for non-developer workloads.
Permission governance: The `on_permission_request` handler is where the security conversation lives. For customers in regulated industries, showing that every tool action can be audited and restricted at the code level — not just policy — tends to land well.
MCP integration: Customers with existing tool ecosystems (Jira, ServiceNow, internal APIs) can expose those as MCP servers rather than rewriting everything as custom tools. Worth raising early to avoid unnecessary rework.

Customer Use Cases

DevOps and platform engineering — Agents that validate infrastructure-as-code before deployment, flag security misconfigurations, or triage incidents by reading runbooks and change logs. These are high-value because they touch production workflows and have clear, measurable ROI.
Internal knowledge and support — An agent over internal documentation — wikis, policies, architecture decisions — that answers employee questions without requiring someone to search three separate systems. Especially valuable for large organizations where institutional knowledge is fragmented.
Developer productivity — Automating pull request summaries, generating release notes from commit history, or flagging potential issues in code changes. These compound fast: save 10 minutes per PR across a 500-developer org and you notice it quickly.
Reporting and operations — Generating weekly status reports, customer-facing summaries, or executive briefings by pulling from live data sources. The agent handles gathering and formatting; the human handles the judgment call.

The common thread is that the best use cases aren't about replacing people. They're about removing the repetitive connective tissue between tasks — so that your team, and your customers' teams, spend more time on the work that actually requires their expertise.

Where to Go from Here

The official SDK repo (https://github.com/github/copilot-sdk) has a Python cookbook with practical recipes, active documentation, and an Issues page that the team monitors closely. Session hooks, MCP server integration, and the system message API are all worth exploring once you're comfortable with the basics.

The hardest part is usually just the first 20 lines. Once the client is running and you've got a session sending messages, the rest clicks pretty quickly — and that first working agent is a compelling starting point for the customer conversation too.

The GitHub Copilot SDK is available in public preview at (https://github.com/github/copilot-sdk). Python 3.11+ required.

Recommended Resources for Deeper Insights

Migrating Azure Data Factory and Synapse Pipelines to Fabric Data Factory

claudiodasilva — Thu, 09 Apr 2026 19:36:15 GMT

Migrating data pipelines from Azure Data Factory (ADF) and Azure Synapse Pipelines to Microsoft Fabric Data Factory represents a significant modernization opportunity and a catalyst for accelerating AI innovation across the enterprise. With Fabric Data Factory, customers can unify their data estate, streamline data engineering workflows, and more effectively leverage real-time analytics, generative AI, and machine learning at scale.

This article outlines the key technical considerations for a successful migration from ADF/Synapse pipelines to Fabric Data Factory.

Fabric Data Factory vs. ADF and Synapse Pipelines: What’s Different?

Fabric Data Factory is officially described by Microsoft as the next generation of Azure Data Factory, built to handle your most complex data integration challenges with a simpler, more powerful approach. It retains ADF’s core engine capabilities while introducing major improvements enabled by Fabric’s unified, AI-centric platform including OneLake, expanded activities and native Copilot experiences.

A fundamental shift is the move to a fully managed SaaS model, with several important differences:

No infrastructure management: Fabric eliminates Azure Integration Runtimes entirely. Compute is managed automatically within a Fabric capacity. For on‑premises connectivity, the On‑Premises Data Gateway (OPDG) replaces ADF’s Self‑Hosted Integration Runtime.
No publish step: Pipelines are authored directly in the Fabric portal and can be saved or executed immediately, removing the separate publish step required in ADF.
Simplified data connections: Traditional Linked Services and Datasets are replaced by Connections and inline data properties within activities, reducing configuration complexity.
New native activities: Fabric introduces capabilities not available in ADF/Synapse pipelines, including Office 365 Outlook email, Teams messaging, semantic model refresh, Fabric notebooks, Invoke SSIS (preview), and Lakehouse maintenance (preview).
Enhanced CI/CD: Built‑in deployment pipelines support cherry‑picking, individual item promotion, Git integration, and SaaS‑native CI/CD beyond ADF’s ARM template–based approach.
AI Copilot: Fabric Data Factory includes Copilot to assist with pipeline creation and management, a capability not available in ADF or Synapse pipelines.

For more details see: Differences between Data Factory in Fabric and Azure - Microsoft Fabric | Microsoft Learn

Common Migration Challenges and Recommended Mitigations

Migrating to Fabric Data Factory introduces new choices and challenges. While the move to Fabric offers substantial benefits, success depends on understanding key differences, migration challenges and planning accordingly. The table below summarizes the most important considerations to help guide a smooth and successful transition.

Table 1. Migration Challenges and Mitigation
Challenge	Description	Recommended Mitigation
Feature Gaps	Some ADF/Synapse features (e.g., SSIS IR, Managed VNets, certain triggers) are not yet fully supported in Fabric.	Delay migration of affected pipelines or redesign using Fabric‑native alternatives. Monitor updates via the https://roadmap.fabric.microsoft.com
Mapping Data Flows	ADF Mapping Data Flows don’t directly map to Fabric equivalents.	Rebuild using Dataflow Gen2, Fabric Warehouse SQL, or Spark notebooks. Validate transformation logic and data types post‑migration.
Trigger Redesign	Fabric lacks centralized trigger management; scheduling must be defined at the pipeline level.	Recreate triggers per pipeline and apply standardized naming conventions and documentation to maintain operational clarity.
Global Parameters	ADF Global Parameters must be converted to Fabric Variable Libraries.	Use Microsoft’s conversion guidance and account for differences in data types and runtime usage patterns. See Convert Azure Data Factory Global Parameters to Fabric Variable Libraries.
Dynamic Connections	Fabric does not support dynamic linked service properties in the same way as ADF.	Parameterize connection objects within pipeline activities using dynamic content.
Deployment Performance	Some environments report slower execution of deployment pipelines in Fabric.	Break deployments into smaller logical units and validate performance during pilot phases prior to production rollout.
Capacity Planning	Fabric uses a fixed‑capacity compute model instead of ADF’s elastic pay‑as‑you‑go runtime.	Right‑size Fabric capacity based on peak load testing and continuously monitor usage with tools such as the Fabric Capacity Estimator.

Migration Tooling

Migration Assistant: Microsoft Fabric includes a built‑in Migration Assistant for both ADF and Synapse pipelines, designed specifically to support pipeline migrations. To assess migration readiness, open your ADF/Synapse pipeline instance, go to the authoring canvas, and select Migrate to Fabric (Preview) > Get started (Preview).

As shown in the assessment summary below, pipelines are grouped into migration readiness categories such as Ready, Needs Review, Coming Soon, and Unsupported. This classification gives engineering teams early visibility into potential migration risks by highlighting activities or configurations that may behave differently in Fabric and require validation or adjustment after migration (Needs review), features that are not currently supported in Fabric but are planned for future availability (Coming soon), or not available in Fabric and will require redesign or re‑implementation (Unsupported).

In enterprise environments with large pipeline estates, this insight is critical for avoiding unexpected failures or delays during migration.

After completing the assessment, you can proceed with the migration wizard and mount your ADF pipelines into Microsoft Fabric.

Mounting does not migrate your ADF pipelines to Fabric Data Factory at this stage. Instead, it creates a reference to your existing instances within the Fabric workspace without consuming Fabric capacity. After mounting, run pipelines side by side to validate behavior and results.

Once the side by side has been validated, select Migrate to Fabric button to proceed with connection mapping and the actual migration to Fabric Data Factory.

After completing the migration process, you will be presented with the Migration Results page. This view provides a summary of all selected pipeline resources along with their migration status and corresponding Fabric resource names. Successfully migrated pipelines are now available as Fabric‑native items within the workspace, while any errors or unmapped dependencies are flagged for further review.

For Synapse Analytics pipelines, you transition directly into the Fabric Data Factory experience (assess->map->migrate flow) rather than mounting first to reference Synapse pipelines externally.

For detailed migration steps, follow this link: Assess your Azure Data Factory and Synapse pipelines for migration to Fabric - Azure Data Factory | Microsoft Learn

PowerShell automation tool: Microsoft provides a PowerShell upgrade utility to accelerate migration from Azure Data Factory to Fabric Data Factory. Using the Microsoft.FabricPipelineUpgrade module, you can translate a large subset of ADF pipeline JSON into Fabric‑native definitions, giving you a fast, scalable starting point for migration. The tool covers common patterns such as Copy, Lookup, Stored Procedure, and standard control flow. Manual follow‑up is still required for edge cases (custom connectors, complex expressions, and some data flow scenarios).

Import-AdfFactory -SubscriptionId <your Subscription ID> -ResourceGroupName <your Resource Group Name> -FactoryName <your Data Factory Name> -PipelineName "pipeline1" -AdfToken $adfSecureToken | ConvertTo-FabricResources | Export-FabricResources -Region <region> -Workspace <workspaceId> -Token $fabricSecureToken

For step‑by‑step guidance, see: Detailed Tutorial for PowerShell-based Migration of Azure Data Factory Pipelines to Fabric - Microsoft Fabric | Microsoft Learn

Open‑Source Migration Tooling

In addition to Microsoft‑supported migration utilities, the Fabric Toolbox provides a set of open‑source tools designed to assist with migration planning, readiness analysis, and pipeline translation from ADF and Synapse to Fabric Data Factory.

Fabric Data Factory Migration Assistant PowerShell: An open‑source tool from the Fabric Toolbox that supports migration from both Azure Data Factory and Synapse ARM templates and built as a browser‑based single‑page application (SPA). https://github.com/microsoft/fabric-toolbox/tree/main/tools/FabricDataFactoryMigrationAssistant
Fabric Assessment Tool: An open‑source command‑line utility used to connect to and scan workspaces in order to extract inventory data and assess migration scope by creating a structured export of assets for planning and analysis.
https://github.com/microsoft/fabric-toolbox/tree/main/tools/fabric-assessment-tool

When to Use What?

Organizations typically adopt one of three migration strategies when transitioning ADF or Synapse pipelines to Fabric Data Factory:

Lift‑and‑Shift to accelerate transition timelines with minimal pipeline refactoring.
Modernization to re‑architect orchestration logic and fully leverage Fabric‑native analytics and AI capabilities.
Hybrid to balance migration velocity with targeted modernization of high‑value or low‑parity workloads.

The appropriate migration paths should be aligned with business priorities, existing integration patterns, and the desired pace of platform transformation, and is largely determined by the feature parity between existing ADF/Synapse assets and their Fabric Data Factory equivalents.

A range of migration tooling options are available depending on migration scope and pipeline complexity:

Built-In Fabric UI Assistant – Migrate to Fabric: Use this assistant to assess pipeline readiness across both ADF and Synapse environments, mount existing ADF pipelines into a Fabric workspace, perform side‑by‑side validation, or migrate supported Synapse pipelines directly into Fabric Data Factory experience.
PowerShell Upgrade Tool (Microsoft‑supported): Use this for bulk ADF migrations at scale, repeatable upgrades, and CI/CD‑driven pipeline conversion with a supported path.
Fabric Data Factory Migration Assistant PowerShell (Open Source): Use for early analysis, connector mapping, and generating a migration starting point outside the Fabric UI.
Fabric Assessment Tool (Open Source): Use before migration to understand scope, inventory, dependencies, and readiness across your Fabric and data estate.
Manual migration: best suited for complex, low‑parity pipelines and provides an opportunity to modernize architecture using Fabric’s native capabilities, delivering long‑term benefits in maintainability, performance, and cost.

Key Considerations for a Smooth Transition

Before migrating, it’s important to understand the architectural differences between Azure Data Factory or Synapse pipelines and Fabric Data Factory. Reviewing these differences early helps determine which pipeline components can be reused, translated, or redesigned for Fabric‑native execution.
Start by prioritizing low‑risk, high‑parity pipelines that can be migrated with minimal redesign.
Mounting existing ADF pipelines into Fabric enables gradual migration and side‑by‑side testing, allowing teams to validate compatibility before using conversion tools or replatforming workloads.
For larger environments, the Microsoft.FabricPipelineUpgrade PowerShell module or Open-Source tools can be used to migrate pipelines at scale while mapping linked services to Fabric connections.
Where possible, leverage Fabric‑native capabilities such as Copilot for pipeline authoring, and code fix, deployment pipelines for CI/CD, and OneLake shortcuts to access external data without duplication.
It’s also recommended to validate migrated pipelines under production‑like workloads to confirm performance and reliability before cutover.
For complex or large‑scale enterprise migrations, engaging Microsoft partners can help accelerate modernization efforts while minimizing operational risk. Partners | Microsoft Fabric

For detailed best practices guidance, refer to: Migration Best Practices for Azure Data Factory to Fabric Data Factory - Microsoft Fabric | Microsoft Learn

Summary

Migrating from Azure Data Factory or Synapse pipelines to Microsoft Fabric Data Factory represents a key step toward building a unified, AI‑ready analytics platform. By leveraging the built‑in migration assessment and associated tooling, organizations can perform pipeline‑level compatibility analysis, identify unsupported activities or configuration dependencies, and implement a phased modernization strategy aligned with workload readiness.

Successful transitions require a clear understanding of the architectural shift from ADF/Synapse’s PaaS to Fabric’s SaaS‑managed model, where compute is fully managed within the Fabric capacity, traditional Integration Runtimes are no longer required, and datasets and linked services are replaced with connection‑based configurations defined inline within pipeline activities.

By adopting Fabric‑native capabilities such as deployment pipelines for CI/CD, Copilot‑assisted pipeline authoring, and OneLake, organizations can standardize pipeline lifecycle management, enable governed access to shared data assets across domains, and support multi‑cloud integration through virtualized data access allowing pipelines to operate on distributed datasets without duplicating or relocating data across Lakehouse, Data Warehouse, and Real‑Time Analytics workloads within a unified Fabric workspace.

Chaos Engineering vs. STAF for SAP: Resilience Validation vs. Functional Assurance

AnuradhaKarnam — Wed, 01 Apr 2026 13:38:38 GMT

Introduction:

As SAP environments transition to cloud platforms such as Azure, one strategic question consistently surfaces:

“STAF proves SAP works, Chaos Engineering proves it survives. Why do we need both?”

The short answer: STAF and Chaos Engineering serve different purposes and treating them as interchangeable can expose SAP production environments to unseen risk.

A Quick Comparison for Mission Critical SAP Engagements

In the world of SAP on Azure, reliability and resilience are non-negotiable. Two powerful approaches. Chaos Engineering for SAP and SAP Testing Automation Framework (STAF) help ensure mission-critical workloads remain robust. But what sets them apart, and how do they complement each other?

Why This Matters

SAP workloads often underpin core business processes. Downtime or misconfiguration can lead to significant operational and financial impact. While both Chaos Engineering and STAF aim to improve system reliability, they do so in very different ways.

Chaos Engineering for SAP

Chaos Engineering is about proactively testing resilience by introducing controlled failures into your environment. Using tools like Azure Chaos Studio, engineers simulate real-world disruptions such as VM shutdowns, DNS failures, or network latency, to validate how SAP systems recover under stress.

Key Benefits:

Identifies hidden weaknesses in architecture.
Improves operational resilience through real-world failure scenarios.
Enables game days and BCDR drills for mission-critical workloads.

SAP Testing Automation Framework (STAF)

STAF focuses on automating high availability (HA) and configuration compliance testing for SAP clusters on Azure. It uses Ansible playbooks and Python modules to execute controlled failover scenarios like node crashes or process termination and generates auditable reports.

Key Benefits:

Speeds up deployment readiness.
Reduces manual testing effort.
Validates HA configurations against best practices.

Side-by-Side Comparison

Aspect	Chaos Engineering for SAP	SAP Testing Automation Framework (STAF)
Primary Goal	Validate resiliency under unpredictable conditions	Automate HA and configuration compliance testing
Scope	Infrastructure-level stress and failure injection	SAP cluster failover and HA validation
Approach	Simulate real-world outages (VM shutdown, DNS failure)	Controlled failover scenarios (node crash, process kill)
Tools Used	Azure Chaos Studio	Ansible playbooks + Python modules
Output	Observability insights, recovery behavior reports	Auditable HTML compliance reports
Use Case	BCDR drills, game days, proactive risk identification	Pre-go-live readiness, periodic HA audits
Complementarity	Tests resilience beyond planned scenarios	Ensures HA configuration meets best practices

When to Use Each

STAF → Before go-live or during periodic audits to validate HA setup.

Chaos Engineering → For resilience testing under unexpected failures and operational stress.

Key Takeaway

These approaches are complementary, not competing. Use STAF for structured HA validation and compliance. Use Chaos Engineering for real-world resilience testing and operational confidence.

Next Steps

Explore Azure Chaos Studio for chaos experiments.
Download STAF from GitHub and integrate it into your SAP deployment pipeline.
Combine both for a comprehensive resiliency strategy.

Conclusion:

The two concepts of STAF and Chaos Engineering are not alternatives but complements to each other. While the former tests the accuracy of the SAP system and the business processes involved in its functionality, the latter tests the system in the real world with failures to confirm its ability to cope with such failures in the cloud environment of Azure.

Therefore, the use of the STAF concept alone gives us the confidence that the SAP system works as expected, but the addition of Chaos Engineering gives us the confidence that the system will still work even when things go wrong.

Ref links:

SAP Testing Automation Framework (STAF):

About SAP Testing Automation Framework | Microsoft Learn

SAP Testing Automation Framework High Availability Testing | Microsoft Learn

anukarnam/SAPTesting-Automation-Framework-: The SAP Test Automation Framework is a set of tools and solutions developed to simplify and automate the process of testing SAP systems and other associated third-party applications. It helps to overcome the challenges associated with manual testing by offering strong automation solutions.

Chaos Engineering – Resilience & Failure Readiness:

What is Azure Chaos Studio? - Azure Chaos Studio | Microsoft Learn

Understand chaos engineering and resilience with Chaos Studio - Azure Chaos Studio | Microsoft Learn

Using Azure Chaos Studio to Fortify SAP Systems Testing and Resiliency | Microsoft Community Hub

Legacy SharePoint Authentication (IDCRL) Is Retiring — What to Do Before May 1, 2026

mikeleemsft — Tue, 03 Mar 2026 20:15:00 GMT

Audience: SharePoint admins, M365 admins, and anyone running automations that access SharePoint Online/OneDrive. This post explains what’s changing, how to detect legacy sign-ins, and the practical steps to move to modern authentication (OAuth) before the cutoff dates.

Microsoft is turning off a legacy SharePoint sign-in method called IDCRL (Identity Client Run Time Library). If you only access SharePoint and OneDrive through the browser or Microsoft 365 apps, you’re probably fine—but if you run scripts, Power BI refreshes, Power Automate flows, or third-party tools that store a username/password, you’ll want to update those connections to Modern Authentication (OAuth/OpenID Connect) now to avoid outages.

TL:DR (What you need to know)

Who’s most affected: Any non-interactive connection that stores a SharePoint username/password (scripts, scheduled jobs, Power BI refreshes, Power Automate flows, and third-party tools).

What’s changing: Microsoft is retiring legacy SharePoint authentication (IDCRL) for SharePoint Online and OneDrive for Business.

What to do: Move those connections to modern authentication (OAuth/OpenID Connect) using supported connectors, modules, or app registrations.

Key dates: Mid-February 2026 (legacy logins blocked by default), April 30, 2026 (last day an admin extension can keep legacy auth temporarily allowed), and May 1, 2026 (IDCRL fully retired and cannot be re-enabled).

Quick checklist

Inventory: list SharePoint connections you own (scripts, Power BI, Power Automate, third-party tools).

Spot legacy auth: saved passwords, “Basic” auth, or PowerShell -Credential/SharePointOnlineCredentials.

Migrate: switch to Modern Authentication (OAuth) using supported connectors/modules.

Test: run the script/refresh/flow end-to-end and confirm it still works.

Finish early: complete updates ahead of mid-February 2026, and no later than May 1, 2026.

What Is IDCRL and Why Is It Going Away?

IDCRL (Identity Client Run Time Library) is an older SharePoint sign-in approach used by some legacy apps and scripts. In plain terms, it’s the “just pass a username and password” style of authentication. While most interactive sign-ins moved to modern authentication years ago, some behind-the-scenes tools still use IDCRL—often without the person who set them up realizing it.

Why is Microsoft retiring it? Because password-based legacy flows are harder to protect and don’t align well with today’s security controls. Modern Authentication uses OpenID Connect and OAuth 2.0 with short-lived tokens (not stored passwords) and works cleanly with protections like MFA and Conditional Access. This is part of Microsoft’s broader “secure by default” direction—and it reduces risk for both individual accounts and the organization.

From Microsoft’s guidance, the main shift is stop sending passwords to SharePoint and start acquiring OAuth access tokens via the Microsoft identity platform. For custom solutions, that typically means using MSAL (Microsoft Authentication Library) and either an interactive sign-in (delegated permissions) or an app-only approach (application permissions) depending on your scenario.

Key Dates and Impact on Users

Here’s the timeline Microsoft shared for SharePoint Online and OneDrive for Business: mid-February 2026 is when remaining legacy (IDCRL) logins will be blocked by default. If customers need additional time to complete migration, tenant admins can temporarily allow legacy authentication again (extension) until April 30, 2026. Then, on May 1, 2026, IDCRL is fully retired and cannot be re-enabled.

In other words, anything still connected with an embedded username/password is likely to break. The risk is concentrated in custom integrations and automations (scripts, refreshes, flows, vendor tools) that still rely on legacy auth.

How Do I Know If I’m Using Legacy Authentication?

If you only access SharePoint/OneDrive through the browser, Microsoft 365 apps, or standard Microsoft connectors, you’re typically already using modern authentication. A simple rule of thumb: if a script, dataset, flow, or tool stores a SharePoint username/password, plan to modernize it. For the most common patterns and what to switch to, see How to Transition to Modern Authentication (Action Plan) below.

Check Microsoft Purview audit logs (recommended)

If you want a definitive answer (beyond “does this script store a password?”), review your tenant’s activity in Microsoft Purview audit and search for IDCRLSuccessSignIn events.

Open the Microsoft Purview portal and go to Audit.
Run an Audit search for an appropriate time range (start with the last 30–60 days).
Under Activities (operations name), select IDCRLSuccessSignIn.
Submit the search, review results, then export (download) the results for deeper filtering in Excel.

What to look for in the export

For IDCRLSuccessSignIn results, focus on the user/account, time pattern, and any available client/app details (for example, user agent, application name, or client IP) to pinpoint what’s generating the legacy sign-ins.

Look for patterns that match automation: recurring events (hourly/daily), service accounts, or sign-ins that line up with scheduled refreshes/flows. Then map those timestamps back to likely owners: Power BI datasets, Power Automate flows, scripts, or vendor tools.

If your export includes client/app identifiers, note any unexpected apps accessing SharePoint; those are the best candidates to validate and migrate first.

Cross-check suspicious entries with your inventory (scripts, Power BI datasets, Power Automate flows, vendor tools) and then update the matching connection to OAuth.

Not sure whether something you own is using legacy auth? A good starting point is to check how the connection was set up: if it relies on a stored password, plan to update it. If you’re still unsure, reach out to IT support or the vendor/developer of the tool—many providers have already published “modern auth” upgrade steps.

How to Transition to Modern Authentication (Action Plan)

If you own anything that connects to SharePoint behind the scenes, the goal is simple: move every connection to Modern Authentication and test it end-to-end well before the cutoff. Below are the most common “legacy” patterns and what to switch to.

Common legacy scenarios (and modern replacement)

1) PowerShell scripts or custom code that pass a username/password

If you’re using older SharePoint Online PowerShell patterns like -Credential, Get-Credential or SharePointOnlineCredentials, plan to update.

Use updated modules that default to OAuth or use PnP PowerShell with interactive sign-in or an Entra app (certificate/client ID) rather than stored credentials. Additionally, according to Microsoft’s announcement in the M365 admin center (MC1188595), the Microsoft.Online.SharePoint.PowerShell module (version 16.0.26712.12000 or newer) supports app-only authentication with a certificate and an Entra app registration (instead of legacy username/password patterns), using Connect-SPOService.

For custom apps, adopt token-based auth via MSAL and supported SharePoint libraries.

Example:

$appID = "1e499dc4-1988-48ef-8f4f-9756f4f04548" # This is your Entra App ID $tenant = "9cfc52cb-53da-4154-67e9-b20b170b7ba3" # This is your Tenant ID $thumbprint = "6EAD7303b5C7E27Dc4245989AD554642940BA093" # This is certificate thumbprint $cert = Get-ChildItem Cert:\LocalMachine\My\$thumbprint Connect-SPOService -Url 'https://contoso-admin.sharepoint.com' -Certificate $cert -ClientId $appID -TenantId $tenant

2) Power BI reports that connect to SharePoint using “Basic” credentials

In Power BI Desktop, open Data source settings for SharePoint connections and switch the authentication method to Microsoft (Organizational) Account / OAuth2.

After updating, re-publish and confirm scheduled refresh still works.

3) Power Automate flows (or workflows) that store a username/password

Prefer the official SharePoint connector (modern auth by default) over custom HTTP calls with stored credentials.

For custom connectors, use an Azure AD app registration and configure OAuth 2.0 so the flow uses tokens, not passwords.

4) Third-party tools (migration/sync/reporting) that use “other user” or stored credentials

Update the tool to the latest version and confirm it supports modern authentication for SharePoint Online.

Run a full test (connect, read/write, scheduled jobs) well before the cutoff dates.

A few best practices while you’re updating

Don’t delay: Modernize your connections before mid-February 2026 (when legacy logins are blocked by default), and no later than May 1, 2026.

Extension (if needed): If you need more time, tenant admins can temporarily allow legacy authentication until April 30, 2026. Treat this as short-term mitigation while your complete migration and validation—not a long-term solution.

Use official solutions: Where possible, use Microsoft’s supported clients and connectors (like updated SharePoint PowerShell modules, Power BI’s OAuth login, and Power Automate SharePoint actions) instead of hard-coding credentials. These default options are already used by modern auth and will help ensure access continues.

Improve security: Embrace modern authentication to benefit from better security (support for MFA, conditional access, etc.) and to eliminate reliance on outdated passwords or legacy API calls.

Get help if needed: If you’re unsure how to update a specific application or script, contact your IT support team or the vendor/developer of the tool.

PowerShell: temporarily allow legacy authentication (extension)

If an extension is required, tenant admins can use SharePoint Online PowerShell to temporarily allow legacy authentication by setting AllowLegacyAuthProtocolsEnabledSetting and LegacyAuthProtocolsEnabled to $true.

Set-SPOTenant -AllowLegacyAuthProtocolsEnabledSetting $true Set-SPOTenant -LegacyAuthProtocolsEnabled $true

Recommendation: Block time now to inventory and modernize your SharePoint connections, then run a full end-to-end test. Doing this early helps you avoid last-minute troubleshooting when a refresh, script, or workflow suddenly fails.

Next steps (recommended)

Run a Purview audit search for IDCRLSuccessSignIn (last 30–60 days) and identify the owners of each recurring legacy sign-in.

Prioritize and modernize the highest-impact items first (scheduled Power BI refreshes, production automations, service accounts, and vendor tools), then test end-to-end.

If you must use the temporary extension, set a firm internal deadline to turn it back off and complete migration before May 1, 2026.

Helpful Resources and Support

For further reading and technical guidance, please see the following official resource:

Microsoft 365 Developer Blog – Migrating from IDCRL to Modern Authentication in SharePoint – Explains the retirement decision and provides developer-oriented steps for migrating code and scripts to MSAL/OAuth.

Conclusion and call to action

IDCRL retirement is one of those changes that is easy to miss until something breaks—because the impact shows up in background jobs, not in day-to-day browser use. The good news is that the fix is straightforward: identify anything still using stored credentials and move it to modern authentication (OAuth) well before the deadline.

Inventory: list every script, dataset, flow, and vendor tool that connects to SharePoint/OneDrive.

Modernize: replace embedded usernames/passwords with OAuth via supported connectors, updated modules, or an Entra app registration.

Test: run each workload end-to-end (including scheduled runs) and confirm it behaves as expected.

Timeline reminder: legacy logins are blocked by default in mid-February 2026, extensions (if used) run through April 30, 2026, and IDCRL is fully retired on May 1, 2026.

Q&A

Q: Will this impact end users who only use SharePoint in a browser or the Microsoft 365 apps?
A: Typically, no. Most interactive sign-ins already use modern authentication. The main risk is with background processes that still send stored usernames/passwords.

Q: What’s most likely to break?
A: Anything non-interactive that connects to SharePoint/OneDrive using embedded credentials—PowerShell scripts, scheduled jobs, Power BI refreshes configured with “Basic” credentials, Power Automate flows/custom connectors that store passwords, and some third-party tools.

Q: How can I confirm whether my tenant is still using IDCRL?
A: Use Microsoft Purview audit and search for IDCRLSuccessSignIn. Export the results and look for recurring patterns (service accounts, scheduled times, consistent client/app details) to identify the source.

Q: What happens in mid-February 2026 vs. May 1, 2026?
A: In mid-February 2026, legacy (IDCRL) logins are blocked by default—so legacy-dependent workloads may start failing unless updated (or temporarily re-enabled). On May 1, 2026, IDCRL is fully retired and cannot be re-enabled.

Q: We need more time—what does the “extension” do?
A: It temporarily allows legacy authentication again through April 30, 2026 while you complete migration. You can enable it with:
Set-SPOTenant -AllowLegacyAuthProtocolsEnabledSetting $true
Set-SPOTenant -LegacyAuthProtocolsEnabled $true
Use this as a short-term mitigation and set a firm plan to turn it back off after you modernize.

Q: What’s the recommended modern auth approach for PowerShell?
A: Use modern modules and token-based sign-in (OAuth). For automation, use an Entra app registration with a certificate (app-only) where appropriate. The updated Microsoft.Online.SharePoint.PowerShell module (v16.0.26712.12000+) also supports Connect-SPOService with certificate-based app-only authentication.

Q: What should I do for Power BI datasets that connect to SharePoint?
A: In Power BI Desktop, update the SharePoint data source authentication to Microsoft (Organizational) Account / OAuth2, then republish and validate that scheduled refresh succeeds.

Q: What about Power Automate flows or custom connectors?
A: Prefer the built-in SharePoint connector (modern auth by default). If you’re using custom HTTP actions or custom connectors, update them to use OAuth 2.0 with an Entra app registration rather than stored credentials.

Admin email template (notify owners identified in Purview)

Use the template below to contact the user/account you found in your IDCRLSuccessSignIn audit export. Copy/paste it into Outlook, then fill in the placeholders (timestamps, site, and any client details) so the recipient can quickly identify the workload.

Subject: Action required: Update a SharePoint/OneDrive connection using legacy authentication (IDCRL)

Hi <Name>,

We’re reaching out because Microsoft is retiring legacy SharePoint authentication (IDCRL). Our audit review indicates a legacy sign-in associated with your account. If the underlying workload isn’t updated, it may fail when legacy authentication is blocked/retired.

What we observed (from Microsoft Purview audit)

User/account: <UPN or service account>

Activity: IDCRLSuccessSignIn

Timestamp(s): <YYYY-MM-DD HH:MM TZ> (add 2–3 examples if recurring)

SharePoint site (if known): <site URL>

Client details (if available): <client/app, user agent, IP>

What we need from you

Please confirm what workload is generating this sign-in (for example: Power BI dataset refresh, Power Automate flow, PowerShell script, scheduled job, or a third-party tool).

If you’re not the owner, please reply with the correct owner/contact (a team name or distribution list is fine).

Timeline

Mid-February 2026: legacy logins blocked by default

May 1, 2026: IDCRL fully retired (cannot be re-enabled)

Note: if an extension is used, it is temporary and runs through April 30, 2026.

How we can help We can help update the connection to modern authentication (OAuth). In many cases this is as simple as re-authenticating with “Microsoft (Organizational) Account”/OAuth (Power BI), using the SharePoint connector (Power Automate), or updating scripts to use an Entra app registration with certificate-based authentication.

Please reply by: <target response date>

Thanks,
<Your name>
<Team/Role>
<Contact info>

Tip: Consider including 2–3 sample timestamps from the export (especially recurring ones) and, if you have it, the dataset/flow name or server/job name that matches the schedule. If you don’t get a response, follow up with the user’s manager or the owning team for the workload, and consider using the temporary extension only as a short-term mitigation while ownership is confirmed.

SharePoint and OneDrive Site User ID Mismatch Explored

Tania Menice — Tue, 03 Mar 2026 17:00:50 GMT

SharePoint / OneDrive request access dialog

In this post, we walk through why users who look ‘healthy’ on the surface can still experience issues, and we cover practical ways to prevent and fix them across identity lifecycle management, rehire scenarios, tenant changes, and operational hygiene.

Who this is for

Microsoft 365 / SharePoint admins troubleshooting unexpected Access denied issues in SharePoint or OneDrive.
Identity admins managing offboarding, rehiring, account restores, or account recreation in Microsoft Entra ID.
Migration teams performing tenant-to-tenant migrations, domain changes, or identity consolidation.

Background Design Explained

When a user is created in Microsoft Entra ID, there is no guarantee that the User Principal Name (UPN) is unique so there is a unique id (historically known as PUID) that is created and passed to SharePoint. When a user is granted permission to a SharePoint or OneDrive Site or file explicitly the user information is added to a hidden list User Information List (UIL) that stores basic details about the users.

Note: For users that are given permission via Office 365 Group, Security group, sharing link, the user profile information is not added until the first time the user interacts with the site or file.

The users unique id, UPN, and other user information will be added to the UIL.

Note: The User Information List (UIL) is maintained per site collection and is separate from Microsoft Entra ID and SharePoint User Profile Service.

As part of authorization, the unique id that is found in the UIL is evaluated to the unique id that is passed via the authentication token and if they do not match then the authorization fails and the user receives “Access Denied”.

Scenario: Taylor Smith (UPN taylor.smith@contoso.com) has confidential SharePoint/OneDrive access. Sometime after Taylor leaves the company, a new user joins the company with the same name and is assigned the same UPN. The new Taylor should not inherit the former Taylor’s access or content. SharePoint prevents this by checking a unique identifier via the User Information List (UIL), ensuring only matching IDs can access content.

Considerations for users removed from Entra ID

It’s common to notice users removed from Entra ID still showing up in SharePoint or OneDrive. SharePoint intentionally retains these accounts in the site’s User Information List to preserve:

Document meta data such as “Created By” or “Modified By” information
Audit and compliance records
Legacy permission references
Sharing and version history integrity

As a result, terminated or mail-disabled users may still appear in:

Site People lists (e.g., _layouts/15/people.aspx)
Group‑connected site membership views
SharePoint user pickers

This visibility is expected and not a security risk because:

A disabled or deleted Entra ID account cannot authenticate
SharePoint permissions are not re‑granted
The presence of the user record does not re‑enable access

Preventive Measures to Avoid Site User ID Mismatches

Preventing Site ID mismatches is largely about identity management. The goal is to avoid situations where a SharePoint site has one ID for a user and Entra ID has another. Here are strategies to minimize the chances of a mismatch occurring:

Identity lifecycle best practices

Avoid reusing a former employee’s UPN: If possible, do not create a new account with the same username. If you must reuse, ensure you’ve cleaned up the old account’s SharePoint presence (see next points) before the new user starts using SharePoint.

Rehire scenarios

Leverage account restores when rehiring: If an employee returns within Entra ID’s 30-day soft-delete window, restore the original account in Entra ID instead of creating a new one. This way, the user’s PUID is the same, and no mismatch will occur because as far as SharePoint is concerned it’s the same account. If outside the 30 days, restoration isn’t possible then extra cleanup will be needed.
Educate and coordinate with HR/IT for re-hires: Often, IT might not realize that creating a returning employee’s account from scratch can cause access issues. Train staff on Site ID mismatches so they know to restore the old account when possible or run diagnostics/cleanup quickly after creating a new account. A standard operating procedure for rehired employee account setup that includes checking for SharePoint conflicts is valuable.
Change UPNs by renaming, not recreating: If you need to change a user’s UPN (for example, after a name change or domain change), rename the existing account (Plan and troubleshoot User Principal Name changes in Microsoft Entra ID) rather than delete and create new. Entra ID allows updating the UPN of a user. SharePoint will typically update the user info entry’s UPN on next sync. This way, the user’s PUID stays consistent. Documentation:
- How UPN changes affect OneDrive - SharePoint in Microsoft 365 | Microsoft Learn
- Change your SharePoint domain name - SharePoint in Microsoft 365 | Microsoft Learn

Tenant/domain changes

Gracefully handle corporate domain transitions: In tenant-to-tenant migrations or domain swaps (such as consolidating two Entra ID tenants), be aware of PUIDs. Use migration tools that map old IDs to new ones or plan to run the fixes post-migration if users receive new IDs. If user/profile mapping isn’t available, treat it like bulk rehiring.

Operational hygiene

Implement a UPN reuse delay or alteration: Some organizations choose to alter the UPN of departing users for a period to prevent accidental reuse (for example, rename jdoe@company.com to jdoe_deactivated@company.com) before deletion. If your policies allow, avoiding UPN reuse entirely is the simplest way to prevent identity confusion.
Maintain documentation of user’s site access: Knowing which sites a user previously accessed makes it easier to clean up conflicts and restore access for legitimate rehires. Centralized, group-based permission management can also simplify re-permissioning once the mismatch is fixed. We have seen this accomplished in the following ways:
- Microsoft Graph Data Connect for SharePoint
- Custom scripts and Tools
- Third Party Tools
Clear SharePoint user info on departure (if feasible): For users who are permanently gone, you can remove them from SharePoint site collections, so old UIL entries don’t linger and later conflict with a reused UPN. This cleanup can be part of an offboarding checklist when appropriate. The cleanup will be 2 steps:
1. Locate which sites a user previously had access to:
  - If the user has been deleted from Entra then the use of custom scripts will be needed to identify sites that the user previously had access to. Example Script SPO-Sharing-Scripts/Readme-FindAccess-SPO.md at main · mikelee1313/SPO-Sharing-Scripts · GitHub
  - If the user still exists in Entra, use the SharePoint Data Access Governance reports to locate sites accessible for a given user. Data access governance reports - get site permission report for given users
2. Once you have a list of sites that the user has accessed, you will need to remove them from that site.
  - Create a script utilizing remove-spouser (Remove users from SharePoint) for all sites that the user had access to previously.
Process for guest users: If you remove guest users, consider also cleaning them from site permissions if they might be re-invited later.

Cleanup Site User ID Mismatches

Once there is a user encountering a Site User ID Mismatch then you will have to do a cleanup reactively. Review the article and use the tools outlined to address the OneDrive site as well as critical sites.

If you do not need an inventory of sites, the user had access to previously to facilitate restoring access to those files/sites then you could do a cleanup of the user through script. The following is an example of such a script:

If a user encounters a Site User ID Mismatch, follow these steps to resolve the issue:

Review the article "Fix site user ID mismatch in SharePoint or OneDrive" for guidance on addressing mismatches. Use the tools outlined in the article to fix issues with the OneDrive site and any other critical sites.
If you do not need an inventory of sites the user previously accessed, proceed with cleaning up the user using a script. Refer to SPO-Sharing-Scripts/Readme-SPOUserRemover.md at main · mikelee1313/SPO-Sharing-Scripts · GitHub for details that could be used. Use this option if restoring access to those files or sites is not required.
If you need an inventory of sites that the user previously had access to provide access later, then you will need a script or report of the permission inventory for the site prior to removing the user from the site.

Users can then move forward with sharing or resharing content/sites to the new user instance, which will write a new entry to the user information list, with the correct unique ID, allowing access.

Summary

User Site ID mismatches occur when a user is recreated with the same UPN but a different underlying identity, leading to SharePoint or OneDrive access issues.
SharePoint authorizes access using a unique ID (PUID) stored per site in the User Information List (UIL), not just the users' UPN.
Disabled or deleted users may still appear in SharePoint by design to preserve audit history and document ownership—this is not a security issue.
Prevention focuses on avoiding UPN reuse through process changes.
Resolution options depend on the scenario: admins can either remove the old user entry directly if access history is not needed, or inventory and clean up affected sites before resharing content to the new account, so the correct ID is written.

Finding and Remediating EWS App Usage Before Retirement

thejimmartin — Thu, 26 Feb 2026 22:18:04 GMT

In this post, we wanted to share a practical walk-through of discovering which Azure AD app registrations are still using Exchange Web Services (EWS), plus what the Kiosk/Frontline license changes mean as you plan your move to Microsoft Graph.

Microsoft has announced that Exchange Online EWS blocking with start on October 1, 2026. If you have line-of-business apps, third-party tools, or automation that still depends on EWS, you need two things: (1) an inventory of what’s using EWS today, and (2) a migration plan to supported alternatives – typically Microsoft Graph.

What’s changing (and why you should care now)

EWS retirement in Exchange Online: Microsoft will start blocking EWS requests to Exchange Online on October 1, 2026. The guidance is to migrate integrations to Microsoft Graph.
EWS access changes for Kiosk / Frontline licenses: Starting at the end of June 2026, Microsoft will start blocking EWS access for users without license rights to EWS (for example, certain Kiosk and Frontline Worker license types). This can cause EWS-based integrations for such licensed users to fail before the broader October retirement date.

Even if you plan to complete your Graph migration well ahead of October 2026, the end-of-June 2026 licensing-related blocks mean you should validate whether any users with those licenses assigned use EWS. That’s where the Exchange-App-Usage-Reporting script is useful: it helps you find app registrations with EWS permissions and correlate them with recent sign-in activity so you can prioritize remediation.

Start here: check your Message Center first

The first thing you can do is to check your tenant Message Center (you need either Global Admin or Privacy Reader roles) and search for "Update active Exchange Web Services Applications" in Inbox or Archive. If you do not have such messages, you likely do not have EWS usage in your tenant and are not impacted by this deprecation. We started to send EWS usage messages to all tenants in late December 2025.

What the Exchange-App-Usage-Reporting script does

The script is designed to answer a practical question: Which Azure AD app registrations in my tenant have EWS permissions, and are they still being used? At a high level, it:

Discovers application registrations that have permissions associated with Exchange/EWS-related access.
Queries sign-in activity for those applications to determine active applications.
Queries audit logs for EWS activity within the tenant.
Outputs report files that you can sort and share with app owners.
Outputs a user license report to help identify kiosk or frontline workers.

How the script complements the Microsoft 365 admin center EWS usage report

For customers in our WW service, the Microsoft 365 admin center EWS usage report is a great starting point because it summarizes EWS activity across your tenant and breaks down which EWS SOAP actions are being called and their volumes over time. That helps you quantify overall EWS dependency and spot the heaviest EWS workloads.

Where teams often get stuck is turning that usage signal into an actionable remediation plan (for example, identifying the exact Entra ID app registration/service principal, determining whether it is still actively used, and finding the people and mailboxes affected). Exchange-App-Usage-Reporting script is intended to bridge that gap by adding identity and operational context around EWS usage by:

App registration and ownership context: identifies Entra ID app registrations/service principals with EWS-related permissions so you can immediately pivot from “an app is calling EWS” to “this is the app object to remediate,” then route it to the right owner/team.
Recency and “is it still used?” signals: correlates apps to sign-in activity so you can prioritize the apps that are actively authenticating today versus stale registrations that may be safe to validate/decommission.
Authentication + permission model visibility: helps you distinguish whether usage is tied to application permissions versus delegated patterns, which matters for choosing the right Microsoft Graph migration approach and designing least-privilege access.
Mailbox population risk (Kiosk/Frontline): adds a user license report so you can quickly identify whether the EWS-dependent workflow touches mailboxes that may lose EWS access earlier (end of June 2026).
Exportable, app-centric worklists: produces CSVs you can sort/share (for example, by last sign-in) to drive an engineering backlog: confirm owner, confirm scenario, map EWS operations to Graph endpoints, and track progress to zero.

In practice, use the admin center report to understand what EWS operations are happening and at what scale, then use this script to determine which app registrations are responsible, who owns them, whether they’re still active, and which mailbox/license populations are most likely to experience impact first.

Customers with tenants that are not in our WW cloud should rely heavily on the script as admin center reports are not available.

Step-by-step: run the script and generate the report

1) Download the code

The repository for this solution can be found here

Note: The following permissions are required for the application:

AuditLogsQuery.ReadAll to query the audit logs for EWS activity
Application.Read.All to locate app registrations
AuditLogs.Read.All to query sign-in activity
Directory.Read.All to query user license information

Read this to create the Entra Admin Center application for the script.

2) Get active applications

Open a PowerShell session and change to the folder where you downloaded the script. You may need to unblock the files (for example, by using Unblock-File) before execution. Run the script with the following example syntax:

The output provides a list of applications with EWS permissions and the last sign-in for the associated service principal. A CSV file called App-SignInActivity-yyyyMMddhhmm will be created in the specified output path.

3) Get sign-in activity report for an application

Use the output from the previous step to get the sign-in activity for an application (you need to run this step for each application). Depending on the size of your tenant, you may also need to adjust the StartDate, EndDate, and have the Interval be 1 hour.

.\Find-EwsUsage.ps1 -OutputPath C:\Temp\Output -OAuthCertificate 8865BEC624B02FA0DE9586D13186ABC8BE265917 -CertificateStore CurrentUser -OAuthClientId 7a305061-1343-49c3-a469-378de4dbd90d -OAuthTenantId 9101fc97-5be5-4438-a1d7-83e051e52057 -PermissionType Application -Operation GetAppUsage -QueryType SignInLogs -Name TJM-EWS-SoftDelete-Script -AppId 86277a5c-d649-46fc-8bf6-48e2a684624b -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date).AddDays(-14) -Interval 8

The output provides a list of users that have signed into the application in the specified period requested. A CSV file called <AppId>-SignInEvents-yyyyMMddhhmm will be created in the specified output path.

4) Get user license information (Kiosk and Frontline identification)

For those organizations that have users with licenses that may be impacted by the upcoming enforcement in June, a report of user licenses can also be generated to help identify potential impact. The output from the previous step can be used to generate this license report. A single CSV file with the results from each application can also be merged into a single user license report.

.\Find-EwsUsage.ps1 -OutputPath C:\Temp\Output -OAuthCertificate 8865BEC624B02FA0DE9586D13186ABC8BE265917 -CertificateStore CurrentUser -OAuthClientId 7a305061-1343-49c3-a469-378de4dbd90d -OAuthTenantId 9101fc97-5be5-4438-a1d7-83e051e52057 -PermissionType Application -Operation GetUserLicenses -AppUsageSignInCsv C:\Temp\Output\86277a5c-d649-46fc-8bf6-48e2a684624b-SignInEvents-20260203122538.csv

How to interpret the output (and prioritize fixes)

Once you have the output files, sort by “last sign-in”. Apps with recent activity are your highest priority because they’re more likely to break production workloads when EWS is blocked. Apps with no sign-in data may be dormant, misconfigured, or retired—treat these as “needs validation,” not automatically “safe to ignore.”

Identify the owner of each app registration (or the business system it belongs to).
Confirm the workload: mailbox access patterns (read, send, calendar, contacts, etc.) and whether it uses application or delegated access.
Check mailbox populations the app touches—especially if any are assigned Kiosk / Frontline licenses that may lose EWS access at the end of June 2026.
Choose the migration target: Microsoft Graph API equivalents, supported Exchange Online features, or a vendor upgrade that removes EWS dependency.

Don’t miss the Kiosk / Frontline Worker EWS blocks (end of June 2026)

Recommended validation playbook:

Use the script output to build a shortlist of actively used EWS-enabled apps.
For each app, determine which mailboxes it accesses (application access policies, RBAC, service accounts, shared mailboxes, or user populations).
Cross-check those mailboxes’ license assignments for Kiosk / Frontline SKUs that may not include EWS rights.
Run a controlled test (non-production where possible) to confirm whether the integration depends on EWS for those mailboxes and whether the vendor has a Graph-based update available.
Evaluate if adding a different type of license for specific users is needed (for example, adding an Exchange Online Plan 1 or 2, which can still use EWS until October deprecation.)

Remediation options (what to do when you find an EWS dependency)

Upgrade or reconfigure the product: Many vendors have already moved to Microsoft Graph. Engage the vendor and request their Graph migration guidance and timelines.
Refactor custom code: Map EWS operations (mail, calendar, contacts) to Microsoft Graph endpoints and re-test auth flows, throttling, and permissions. More information on mappings can be found here.
Reduce blast radius: If an app truly must remain temporarily, scope it tightly using least-privilege permissions and (where applicable) scope the mailbox it has access to using RBAC—then treat it as a short-term exception with an expiration date.

Quick checklist

Run Exchange-App-Usage-Reporting and identify apps with recent EWS sign-in activity.
Track down app owners and document which mailboxes/workloads each app touches.
Assess exposure to the end-of-June 2026 licensing-related EWS blocks (Kiosk/Frontline).
Prioritize migrations to Microsoft Graph and validate functionality end-to-end.
Re-run the report periodically to confirm EWS usage is trending to zero.