rss.livelink.threads-in-node

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.

Azure SRE Agent Architecture and Creation: Practical Benefits for SAP on Azure Customers

AnuradhaKarnam — Thu, 26 Feb 2026 19:08:02 GMT

Introduction:

SRE Agent is an AI-powered service designed to support site reliability engineering practices through automation and intelligent decision-making. It reduces operational toil, improves uptime, and delivers consistent results by seamlessly integrating with Azure services and external systems to perform operational tasks with limited manual intervention.

Azure SRE Agent reduces operational toil by automating routine and repetitive tasks, allowing teams to concentrate on high impact initiatives. Operational work frequently involves managing diverse Azure resources in combination with on-premises environments, often requiring orchestration across multiple tools. SRE Agent delivers an AI driven platform that unifies these systems and automates operational workflows from start to finish.

How Azure SRE Agent Architecture and Creation Benefit SAP on Azure Customers:

The SRE Agent architecture is particularly well suited for SAP workloads, which are inherently mission critical and span multiple Azure services, including compute, storage, networking, databases, and monitoring. By creating an Azure SRE Agent and associating it with SAP related resource groups, customers gain a unified operational control plane that continuously analyzes telemetry from Azure Monitor, logs, and metrics to identify issues impacting SAP availability, performance, and stability.

Through automated diagnostics, root cause analysis, and guided or approval-based remediation, Azure SRE Agent significantly reduces manual troubleshooting during SAP incidents. In addition, its support for scheduled health checks, configuration validation, and compliance audits aligns closely with SAP best practices and change controlled environments, enabling customers to transition from reactive operations to a proactive, automated, and scalable model that improves uptime and operational confidence at scale.

Centralized Azure Service Management Capabilities:

This diagram illustrates Azure SRE Agent as the centralized automation and intelligence layer that manages Azure resources through Azure CLI and REST APIs, providing a unified control plane for operational tasks across the platform. From this single point, the agent connects to five core service domains: Compute (such as Virtual Machines, App Service, Container Apps, AKS, Functions and more), Storage (including Blob storage, file shares, managed disks, and storage accounts), Networking (covering Vnets, load balancers, application gateways, and network security groups), Databases (Azure SQL, Cosmos DB, PostgreSQL, MySQL, and Redis), and Monitoring & Management (Azure Monitor, Log Analytics, Application Insights, and Azure Resource Manager). Together, the layout shows how Azure SRE Agent enables consistent, automated, and scalable operations across diverse Azure services from a single, AI-driven management layer.

Creating an SRE Agent in the Azure Portal:

Access the Azure portal and complete the following steps to create an SRE Agent.

From Home → Create a resource, search for “sre agent” in the Azure Marketplace. The results clearly highlight Azure SRE Agent (Preview) as an official Microsoft Azure service, confirming that it is provisioned like any other native Azure resource rather than an external tool or addon.

Please select the Azure subscription in which the agent will be deployed and confirm the available Azure SRE Agent (Preview) plan.

In the Basics step, select the subscription and resource group where the Azure SRE Agent will be created. You then provide agent specific details, including the agent's name and the Azure region in which the agent will be deployed and operated. This configuration ensures that the SRE Agent is established as a first-class Azure resource, governed, scoped, and managed using the same Azure constructs as any other native service.

In this step, you define the level of access the agent will have over the Azure resource groups it manages, ensuring alignment with your organization’s security and governance requirements.

Two permission levels are available:

Reader: The agent has read only access to the assigned resource groups. It can observe resource state, analyze telemetry, and generate insights, but any remediation actions require temporary elevation using the user’s permissions after explicit approval.

Privileged: The agent is granted permission to execute approved actions directly on detected resources and resource types within its assigned resource groups. This enables faster, more automated remediation while still operating within Azure RBAC controls and approval of workflows.

This screen confirms that the Azure SRE Agent (Preview) has been successfully deployed in the Azure Portal. The banner “Your deployment is complete” indicates that all required resources were provisioned without errors and that the agent is now active in the selected subscription and resource group.

This screen shows the Azure portal search experience after the Azure SRE Agent has been successfully deployed. By typing “my” in the top search bar, the portal surfaces both services and resources associated with the user’s subscription. Under the Resources section, the newly created Azure SRE Agent instance (for example, mysreapp) appears, confirming that the agent is now registered.

Below screen shows the Azure SRE Agent chat interface for the deployed agent (mysreapp) within the Azure portal. It represents the primary interaction surface where users engage with Azure SRE Agent using natural language to monitor, diagnose, and remediate issues across the Azure resources associated with the agent.

On the left navigation pane, users can manage chat threads, review activities, access the agent builder, monitor health and insights, and configure settings. The main panel displays a new chat thread with a prompt inviting the user to ask a question or execute a command. The quick action buttons (such as App Services, Container Apps and AKS) provide guided entry points to common operational scenarios, helping users get started quickly without needing to remember specific commands.

Once the chat window opens, Azure SAP customers can begin interacting with the Azure SRE Agent using natural language to monitor and manage their SAP landscapes on Azure. To get started, try questions such as:

What can you help me with my SAP systems?

Which SAP subscriptions, resource groups, or SAP related resources are you managing?

What alerts should I configure for my SAP workload (for example, SAP HANA, ASCS, or application servers)?

Show me a comparison of successful requests versus errors for SAP dependent applications across all subscriptions.

If you are troubleshooting a specific SAP issue, you can ask more targeted questions, for example:

Why is my SAP system or SAP HANA database slow?

Why is my SAP application or central services instance not responding?

Can you investigate issues with my SAP workload?

Can you retrieve key metrics (such as CPU, memory, disk I/O, or HANA latency) for my SAP resources?

Conclusion:

Azure SRE Agent empowers SAP customers with a centralized, AI driven operations layer built for managing complex, SAP landscapes on Azure. By integrating natively with Azure and using standard management interfaces, the agent delivers continuous, end-to-end visibility across the compute, storage, networking, database, and monitoring layers that underpin SAP workloads. This unified operational view enables teams to detect and understand issues affecting SAP availability, performance, and stability faster and with greater confidence.

By combining automated diagnostics, intelligent root cause analysis, and guided or approval-based remediation, Azure SRE Agent dramatically reduces manual effort and accelerates incident resolution. Built-in support for proactive health checks, configuration validation, and compliance auditing aligns with SAP best practices and change controlled environments, allowing customers to move beyond reactive firefighting.

Reference links:

Tutorial: Troubleshoot an App Using Azure SRE Agent and Azure App Service Preview | Microsoft Learn

Billing for Azure SRE Agent Preview | Microsoft Learn

Incident Management in Azure SRE Agent Preview | Microsoft Learn

Accelerating AKS Upgrades with Fleet Manager: Finding the Right Balance

manandak — Thu, 26 Feb 2026 20:11:11 GMT

Introduction

Upgrading Azure Kubernetes Service (AKS) clusters at scale can be time-consuming, especially when managing multiple environments and clusters. Azure Fleet Manager provides powerful controls to orchestrate these upgrades efficiently. However, with this flexibility comes important design considerations and trade-offs that platform teams must understand.

Disclaimer:

This article draws on publicly available documentation as of February 2026 and is intended to provide insight into how Fleet Manager manages AKS upgrades, along with the key factors to consider when defining an effective upgrade strategy.

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.

At the heart of AKS Fleet Manager upgrades are three foundational concepts: update runs, update stages, and update groups.

Update run: An update run represents an update being applied to a collection of AKS clusters, consisting of the update goal and sequence. The update goal describes the desired updates (for example, upgrading to Kubernetes version 1.28.3). The update sequence describes the exact order to apply the update to multiple member clusters, expressed using stages and groups. If unspecified, all the member clusters are updated one by one sequentially. An update run can be stopped and started.

Update stage: Update runs are divided into stages, which are applied sequentially. For example, a first update stage might update test environment member clusters, and a second update stage would then later update production environment member clusters. A wait time can be specified to delay between the application of subsequent update stages.

Update group: Each update stage contains one or more update groups, which are used to select the member clusters to be updated. Within an update stage, updates are applied to all the different update groups in parallel; within an update group, member clusters update sequentially. Each member cluster of the fleet can only be part of one update group.

Image Source – Azure Portal- > AKS Fleet Manager -> Upgrade Groups Explanation

The Approach

To reduce the overall time required to complete AKS upgrades across all clusters, there are two primary levers available:

Reduce the number of update stages, since stages are upgraded sequentially.
Increase the number of update groups within a stage, as update groups are upgraded in parallel. Each update stage can contain up to 50 update groups, allowing as many as 50 AKS clusters to be upgraded concurrently.

While both approaches can significantly speed up the upgrade process, each introduces its own risks that must be carefully considered.

Finding the right Balance

Reducing Update Stages: Speed at the Cost of Safety

Reducing the number of update stages typically means grouping AKS clusters from multiple environments—such as dev, test, and production—into one or two stages. Although this can shorten the overall upgrade timeline, it is not recommended.

This approach severely limits the time available to validate application behavior in lower environments before rolling changes into higher-risk environments like production. Microsoft best practices explicitly recommend keeping the first update stage small, with a minimal number of update groups. This helps contain the blast radius if a regression is introduced.

It’s also important to note that AKS does not currently support rollback after an upgrade. If a regression occurs, the only remediation option is to provision a new AKS cluster running the previous version, which can be both time-consuming and operationally expensive.

Increasing Update Groups: Parallelism with Capacity Risks

An alternative—and generally safer—approach is to increase the number of update groups starting from the second update stage onward. This allows more clusters to be upgraded in parallel, reducing the overall upgrade duration while still preserving a controlled validation phase.

However, parallel upgrades come with their own challenges. Running multiple AKS upgrades simultaneously increases the risk of failures due to capacity constraints in an Availability Zone, particularly when node pools rely on VM SKUs with limited availability. The risk grows even further when node pools are configured with a higher Max Surge value, as more nodes are created concurrently during upgrades.

At the time of writing this blog, there is one important limitation to be aware of:
If even a single AKS cluster upgrade fails, the entire Fleet upgrade run is halted. There is an open feature request to introduce a configurable safe-failure threshold, which would allow the upgrade process to continue even if a limited number of cluster upgrades fail:

👉 https://github.com/Azure/AKS/issues/5338

Conclusion: Designing a Thoughtful Upgrade Strategy

While Azure Fleet Manager makes it possible to significantly reduce the overall duration for AKS upgrade, doing so safely requires thoughtful planning. The key is to strike the right balance between:

Reducing overall upgrade duration by increasing parallelism, and

Minimize risk and disruption by preserving adequate validation stages and respecting capacity constraints.

Successful AKS upgrade strategies are rarely one-size-fits-all. They require close collaboration, environmental awareness, and a clear understanding of both platform limitations and operational risk. With the right design, Fleet Manager can be a powerful enabler for fast, safe, and scalable AKS upgrades.

For some additional resources, check out the following:

https://learn.microsoft.com/en-us/azure/kubernetes-fleet/overview

https://learn.microsoft.com/en-us/azure/kubernetes-fleet/concepts-update-orchestration

Create an Organizational Assets Library (including Multi-Geo & Information Barriers guidance)

mikeleemsft — Mon, 23 Feb 2026 14:53:27 GMT

Overview

This guide walks through a practical approach to setting up SharePoint Online (SPO) Organizational Assets Libraries (OAL). It includes optional guidance for more complex tenants—such as Multi-Geo and Information Barriers (IB) - because those scenarios are often under-documented.

What you’ll accomplish: Create and register Organizational Assets Libraries so templates, fonts, and brand images are available in Office apps, with notes for Multi-Geo, Information Barriers, Brand Center, and Copilot integration where applicable.

Applies to: Standard (single-geo) tenants, Multi-Geo tenants, tenants with Information Barriers, and environments using Brand Center and/or Copilot features for organizational assets.

Quick start (standard single-geo tenant)

Create a SharePoint site to host Organizational Assets Libraries (often the Brand Center site).
Create three document libraries (typical): ImageAssets, DocumentAssets (templates), FontAssets.
Grant your intended audience Read access (commonly Everyone except external users via the site’s Visitors group).
Enable the SharePoint Online Public CDN (tenant setting).
Add a Public CDN origin for each library path (one origin per library).
Upload approved assets (images, templates, fonts) into their respective libraries.
Register each library with Add-SPOOrgAssetsLibrary (repeat per library).
Validate registration and end-user experience, then allow up to 24 hours for Office apps to reflect changes.

If you’re Multi-Geo or using Information Barriers: follow the same flow, but repeat per geo and complete registration while the site is in Open IB mode (details below).

Key constraints and gotchas

Multi-Geo: plan a repeatable per-geo pattern (typically one Org Assets site + matching libraries per geo) and keep naming consistent.

Information Barriers (IB): Add-SPOOrgAssetsLibrary cannot be run when the target site is segmented—create and register libraries first (site in Open mode), then segment if needed.
The “Everyone except external users” principal may be hidden by default, but it’s still commonly used for broad read access.
Brand Center: many orgs host Org Assets Libraries in the Brand Center site; if Brand Center is created after libraries exist, it typically detects and uses them automatically.
A public CDN must be enabled to support Organizational Assets Libraries.

The “Everyone except external users” principal may be hidden by default, but it’s still commonly used for broad read access.
Brand Center: many orgs host Org Assets Libraries in the Brand Center site; if Brand Center is created after libraries exist, it typically detects and uses them automatically.
A public CDN must be enabled to support Organizational Assets Libraries.

Implementation steps

Prerequisites: SharePoint Online Management Shell access (or equivalent), permission to manage tenant settings, and the ability to create sites and libraries in each geo.

Create a site to host your Organizational Assets Libraries (many orgs use a communication site). For ease of support, keep the site name, library names, and structure consistent over time.

Note: A Communication site is recommended, but a Team site can also work.

Example site URLs: In a standard tenant you’ll have one site; in Multi-Geo you’ll typically use one per geo.

- Primary geo: https://contoso.sharepoint.com/sites/BrandCenter
- EUR geo: https://contosoEUR.sharepoint.com/sites/BrandCenter
- APC geo: https://contosoAPC.sharepoint.com/sites/BrandCenter

If your tenant uses Information Barriers, keep each site in Open IB mode while creating the Org Assets Libraries. You can segment the site later (if required) after libraries are created.

Configure a public CDN (required)

To use Brand Center and Organizational Assets Libraries, configure SharePoint Online to use a Public CDN.

Set-SPOTenantCdnEnabled -CdnType Public -Enable $true

Example output:

Public CDN enabled locations:

SITES/BRANDCENTER/FONTS

*/MASTERPAGE (configuration pending)

*/STYLE LIBRARY (configuration pending)

*/CLIENTSIDEASSETS (configuration pending)

Note: You will see the new CDN is in a pending state until complete. This will take some time.

Wait for the CDN to finish provisioning. Re-run the status/list commands until “pending” entries clear.

Get-SPOTenantCdnEnabled -CdnType Public Get-SPOTenantCdnOrigins -CdnType Public

Add CDN origins for each library

Add allowed CDN origins for each asset library path (typically one origin per library).

Example:

Add-SPOTenantCdnOrigin -OriginUrl sites/BrandCenter/ImageAssets -CdnType Public Add-SPOTenantCdnOrigin -OriginUrl sites/BrandCenter/TemplateAssets -CdnType Public Add-SPOTenantCdnOrigin -OriginUrl sites/BrandCenter/FontAssets -CdnType Public

Set permissions (required for broad consumption)

To ensure most users can consume the assets, grant Everyone except external users (often abbreviated as EEEU) Read access (commonly via the site’s Visitors group).

Example: add Everyone except external users to the Visitors group of the Organizational Assets site.

Connect-SPOService -Url 'https://contoso-admin.sharepoint.com' $tenant = "9cfc42cb-51da-4055-87e9-b20a170b6ba3" $site = Get-SPOSite -Identity "https://contoso.sharepoint.com/sites/BrandCenter" $group = Get-SPOSiteGroup $site -Group "BrandCenter Visitors" Add-SPOUser -LoginName ("c:0-.f|rolemanager|spo-grid-all-users/" + $tenant) -Site $site -Group $group.Title

Note: Organizational Assets Libraries respect SharePoint security trimming. If you need a narrower audience, grant Read to the appropriate groups instead of tenant-wide access. In many environments, Everyone except external users is required during registration (Add-SPOOrgAssetsLibrary) so Office can enumerate the library—test and confirm in your tenant before removing broad access.

Create libraries and upload assets

Create a document library for each asset type you plan to publish (for example: images, Office templates, fonts).

For example:

Upload your assets into the appropriate libraries.

Example:

Register each library using Add-SPOOrgAssetsLibrary. For this to work, Everyone except external users must already have access to the site (for example, via the Visitors group).

Office Template Library Example:

Add-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/DocumentAssets' -OrgAssetType OfficeTemplateLibrary

Image Document Library Example:

Add-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/ImageAssets' -OrgAssetType ImageDocumentLibrary

Font Document Library Example:

Add-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/FontAssets' -OrgAssetType OfficeFontLibrary -CdnType Public

Optional: Enable Copilot support for an image library (only applicable to ImageDocumentLibrary).

Set-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/ImageAssets' -OrgAssetType ImageDocumentLibrary -CopilotSearchable $true

Multi-Geo mini runbook (recommended pattern)

Use this as a simple tracking sheet so each geo ends up with a complete, consistent setup.

Geo	Site URL	Libraries	CDN origins added	Libraries registered
Primary	https://<tenant>.sharepoint.com/sites/<BrandCenterOrAssetsSite>	ImageAssets / DocumentAssets / FontAssets	Yes/No	Yes/No
EUR	https://<tenant>EUR.sharepoint.com/sites/<BrandCenterOrAssetsSite>	ImageAssets / DocumentAssets / FontAssets	Yes/No	Yes/No
APC	https://<tenant>APC.sharepoint.com/sites/<BrandCenterOrAssetsSite>	ImageAssets / DocumentAssets / FontAssets	Yes/No	Yes/No

Naming standard (strongly recommended): keep the same site path and the same library names in every geo (for example, always ImageAssets, DocumentAssets, FontAssets). This minimizes per-geo scripting differences and reduces support effort.

Wrap-up

At this point, each geo should have its own site, libraries, CDN origins, and registered Organizational Assets Libraries. From here, focus on governance (who can publish/approve assets), naming standards, and ongoing lifecycle management (retire old templates/fonts and keep branding current).

Validate configuration

Admin checks (PowerShell)

Confirm the Public CDN is enabled.
Confirm CDN origins include one entry per assets library path.
List registered Org Assets Libraries and verify each URL + type is present.

Get-SPOTenantCdnEnabled -CdnType Public Get-SPOTenantCdnOrigins -CdnType Public Get-SPOOrgAssetsLibrary

End-user checks (Office apps)

In PowerPoint/Word, confirm organizational templates appear in the template picker (if you registered an OfficeTemplateLibrary).
In Office font lists, confirm your org fonts appear (if you registered an OfficeFontLibrary).
For image libraries, confirm approved brand images appear in supported pickers; if you enabled -CopilotSearchable, confirm images are discoverable as expected.

Timing: New registrations and updates can take up to 24 hours to appear in Office apps. If you updated content, run Set-SPOOrgAssetsLibrary for each changed library, then wait for propagation.

Updating content in existing Org Assets Libraries

If you already have Organizational Assets Libraries registered and you need to publish updated templates, fonts, or images, use the process below. The high-level flow is: update content → run Set-SPOOrgAssetsLibrary (per library) → wait for propagation.

Replace or update content in each library. Upload the new versions of templates/fonts/images into the appropriate library (and remove/retire older versions if needed).
If Multi-Geo applies, repeat per geo. Update the matching libraries in each geo’s site so users in each geo get the same (or intentionally regional) set of assets.
Run Set-SPOOrgAssetsLibrary for each updated library. Execute the cmdlet against the library URL to refresh the configuration after content changes (run it once per library you updated).
Wait for Office app propagation. Allow up to 24 hours for updates to begin showing in Office apps.

Example:

Set-SPOOrgAssetsLibrary -LibraryUrl 'https://contoso.sharepoint.com/sites/BrandCenter/DocumentAssets' -OrgAssetType OfficeTemplateLibrary

Notes:

If your site is segmented by Information Barriers, confirm the cmdlet behavior in your environment before making changes, and prefer performing registration/updates while the site is in Open mode when possible.
For image libraries, if you are using Copilot integration settings (for example -CopilotSearchable), keep the setting consistent when you run Set-SPOOrgAssetsLibrary.
Make sure the intended audience still has Read access to the site/library; otherwise users may not see updates due to security trimming.

Please note: After registering (or updating) your assets libraries, it can take up to 24 hours before changes become available in Office apps.

Once fully enabled, Office apps will surface your templates and fonts. Below is an example.

Example of interacting with Org Assets from M365 Apps

Org Fonts from PowerPoint:

From SharePoint:

From Office Apps:

Troubleshooting tips

If Add-SPOOrgAssetsLibrary fails, confirm the site is not segmented by Information Barriers (Open mode during setup).
If assets don’t appear in Office apps, wait for propagation (up to 24 hours) and re-check that the library was registered successfully.
If CDN commands show “pending”, allow time for provisioning and re-run the status command.
If users can’t see assets, verify the site/library permissions include Everyone except external users (or the intended audience group).

Guidance: Using the SharePoint Online Public CDN

Enabling the SharePoint Online Public CDN is a required and supported configuration for Organizational Assets Libraries, Brand Center, and related Office experiences. While the word “public” can sound concerning, it’s important to understand what is (and is not) exposed.

We take great care to protect the data that runs your business. Data stored in the Microsoft 365 CDN is encrypted both in transit and at rest, and access to data in the Microsoft 365 SharePoint CDN is secured by Microsoft 365 user permissions and token authorization. Requests for data in the Microsoft 365 SharePoint CDN must be referred (redirected) from your Microsoft 365 tenant or an authorization token won't be generated. See: Content delivery networks - Microsoft 365 Enterprise | Microsoft Learn

What “Public CDN” actually means

Only explicitly approved library paths are cached

The CDN does not expose your entire tenant.
Administrators must explicitly register CDN origins (specific library paths).
If a library is not registered as a CDN origin, it is not served via the CDN.

No new content types are exposed

The CDN is intended for static, non-sensitive assets such as:

Brand images
Office templates
Fonts

It is not designed for documents containing confidential or regulated data.

Why Microsoft requires a Public CDN for Org Assets?

Performance and reliability

Office clients worldwide retrieve assets faster using geographically distributed edge caching.
This avoids repeated downloads from SharePoint origin sites.

Consistent Office app experiences

PowerPoint, Word, Excel, and Copilot rely on CDN-backed delivery to surface:

Templates
Fonts
Brand images

Without a public CDN, these features may not function correctly or at all.

Best practices

Use the practices below to keep Organizational Assets Libraries reliable, secure, and easy for end users to adopt. Where relevant, notes call out additional considerations for Multi-Geo, Information Barriers, Brand Center, and Copilot.

Governance and ownership checklist

Owners/publishers: named group who can add/change assets (limited membership).
Approvals: defined review/approval step before publishing new templates/fonts/images.
Versioning/retention: how you retire old assets and prevent outdated branding from appearing in pickers.
Rollback plan: how to revert a bad template/font/image quickly.
Change communication: how you notify users about new/updated assets and expected timing (up to 24 hours).

Assign clear owners (typically Brand/Comms) and a small admin group (typically IT) for each geo’s library and site.
Decide what is “approved” vs “draft” content, and enforce it with a simple publishing process (for example, a review checklist or an approvals flow).
Version and retire assets deliberately: keep one “current” template set and archive old assets to prevent users from picking outdated branding.

Information architecture and naming

Keep library names and structures consistent across geos (same library names, same folder conventions) to simplify support and documentation.
Use descriptive filenames users can recognize in pickers (for example, “Contoso_Proposal_Template_v3”).
Prefer a small number of clearly defined libraries by asset type (images, templates, fonts) rather than many small libraries.

Permissions and access

Ensure your intended audience has at least Read access to the site and libraries; Organizational Assets still follow SharePoint security trimming.
If you use broad access (for example, Everyone except external users), document it and pair it with tight contributor permissions so only approved publishers can change assets.
Avoid breaking inheritance in ways that make troubleshooting difficult—keep permissions simple and predictable whenever possible.

CDN configuration

Plan CDN changes ahead of time: enabling and provisioning can take time, and changes may not be immediate.
Register only the origins you need (one per assets library path) and keep them consistent across environments.
After changes, allow for propagation time before validating in Office apps.

Multi-Geo and Brand Center

Use a repeatable pattern: one site + matching libraries per geo, with the same structure and operational runbook.
Be aware Brand Center is created in the primary geo; confirm how your org wants to manage global vs regional assets.
Document which assets are global (shared everywhere) vs regional (geo-specific) to avoid confusion for publishers and users.

Information Barriers (IB) sequencing

Create and register Org Assets Libraries before segmenting the site when IB is enabled (create while the site is in Open mode, then segment later if required).
After segmentation, re-validate that the right audience can still read the libraries (and that publishers can still manage content).

Copilot readiness (image libraries)

Use consistent, high-quality metadata for images (titles, descriptions, and tags). Copilot search quality depends heavily on this.
If enabling image tagging integration, standardize on a tagging vocabulary (for example, brand terms, campaigns, departments, regions) so results are predictable.
Only enable Copilot searchable settings on libraries where content is approved and intended for broad reuse.

Q&A

Q: What is an Organizational Assets Library (OAL)?
A: It’s a SharePoint document library (or set of libraries) that you register so Office apps can surface approved templates, fonts, and images to users directly within the app experience.

Q: Do I need SharePoint Brand Center to use OAL?
A: No. You can use Organizational Assets Libraries without Brand Center. Brand Center can make asset management more accessible, for example, allowing SharePoint sites to use organizational branding, but OAL can be configured on its own.

Q: Why is a “Public CDN” required, and is it safe?
A: Office experiences rely on CDN-backed delivery for performance and reliability. “Public CDN” does not mean your whole tenant is exposed—only the specific library paths you register as CDN origins are cached. Access is still governed by Microsoft 365 authentication, token authorization, and SharePoint permissions.

Q: Can I use this guide in a standard (single-geo) tenant?
A: Yes. In a standard tenant you usually create one site and one set of libraries. The Multi-Geo guidance is only needed if your tenant is Multi-Geo (in which case you’ll typically repeat the pattern per geo).

Q: How do Information Barriers (IB) affect setup?
A: If a site is segmented, Add-SPOOrgAssetsLibrary cannot register the library. Create the site and register the libraries while the site is in Open mode, then segment afterward if required.

Q: Why does “Everyone except external users” (EEEU) matter?
A: In many environments, EEEU is required during library registration so Office can enumerate the library. However, OAL still respects SharePoint security trimming. If broad internal availability is the goal, a common pattern is to grant EEEU Read (often via the Visitors group) so Office apps can surface the assets to most internal users. If you need a narrower audience, use a group instead.

Q: How long until assets show up (or update) in Office apps?
A: It can take up to 24 hours for new registrations or updates to propagate. If you replaced content in an existing library, run Set-SPOOrgAssetsLibrary for each updated library, then allow time for Office apps to refresh.

Q: How do I update content in an existing Org Assets Library?
A: Replace the files in the library (and repeat across geos if applicable), then run Set-SPOOrgAssetsLibrary against each library you updated. After that, allow up to 24 hours for the updated assets to start showing in Office apps.

Q: Do I need to run Set-SPOOrgAssetsLibrary every time I replace files?
A: If you want Office apps to reliably pick up changes, run Set-SPOOrgAssetsLibrary after you update content (especially when publishing new/updated templates, fonts, or images). Treat it as the “refresh” step, then wait for propagation.

Q: When should I enable Copilot support (CopilotSearchable) for an image library?
A: Enable it only for libraries that contain approved, broadly reusable images and have strong metadata (title/description/tags). This helps ensure search results are on-brand and reduces the chance of surfacing unreviewed content.

Q: Can I undo this later?
A: Yes. You can unregister an Organizational Assets Library using SharePoint Online PowerShell (for example, Remove-SPOOrgAssetsLibrary) and remove CDN origins if you no longer need them. Plan governance so you can retire assets cleanly without disrupting users.

Q: Users can’t see the assets (or updates)—what should I check first?
A: Start with (1) permissions to the site/library (security trimming), (2) successful registration via Add-SPOOrgAssetsLibrary, (3) if you’re expecting an update, confirm you ran Set-SPOOrgAssetsLibrary for that library, (4) CDN provisioning status and configured origins, and (5) propagation time (up to 24 hours).

Additional Reading

Create an organization assets library - SharePoint in Microsoft 365 | Microsoft Learn

Connect organizational asset libraries to Copilot for an on-brand experience - SharePoint in Microsoft 365 | Microsoft Learn

Connect organizational asset libraries to PowerPoint for an on-brand experience - SharePoint in Microsoft 365 | Microsoft Learn

Set up and connect organizational asset library (OAL) with image tagging to Copilot search | Microsoft Learn

Add-SPOOrgAssetsLibrary (Microsoft.Online.SharePoint.PowerShell) | Microsoft Learn

SharePoint Brand Center - SharePoint in Microsoft 365 | Microsoft Learn

How to Enable Enterprise Brand Images with PowerPoint Copilot - SharePoint in Microsoft 365 | Microsoft Learn

Office 365 Content Delivery Network (CDN) Quickstart - Microsoft 365 Enterprise | Microsoft Learn

Use Office 365 Content Delivery Network (CDN) with SharePoint Online - Microsoft 365 Enterprise | Microsoft Learn

Content delivery networks - Microsoft 365 Enterprise | Microsoft Learn

Multi-Geo Capabilities in OneDrive and SharePoint - Microsoft 365 Enterprise | Microsoft Learn

Use Information Barriers with SharePoint | Microsoft Learn

Large Mailbox Migration to Exchange Online

thejimmartin — Thu, 19 Feb 2026 18:10:13 GMT

Migrating large mailboxes is challenging for enterprise Exchange teams, especially when mailboxes are over 100 GB or contain extensive recoverable items. Using Exchange Messaging Records Management (MRM) to reduce mailbox size before migration can speed up moves to Exchange Online.

Why Use MRM Before a Large Mailbox Migration?

Many organizations place mailboxes on litigation hold or in-place hold, causing the recoverable items in these mailboxes to grow significantly, often exceeding the 100 GB quota in Exchange Online. Quota adjustments can be requested, allowing up to about 240 GB for the combined size of the primary mailbox and recoverable items. Still, it's common for recoverable items alone to surpass this limit.

MRM lets you move content from the primary mailbox to an archive mailbox, reducing the primary's overall size. The archive mailbox may be hosted on-premises or in Exchange Online. Setting up the archive in Exchange Online is usually simpler, reducing the need for additional mailbox migrations. Occasionally, this process can result in the archive mailbox's recoverable items exceeding the 240 GB cap. Therefore, creating the archive in Exchange Online remains the most efficient solution.

Prerequisites

Archive mailbox created in Exchange Online
The archive mailbox must have the correct routing domain configured as the ArchiveDomain value
OAuth enabled in Exchange
AutoExpandingArchiveEnabled must be enabled for either mailbox or entire organization

MRM Configuration

The required retention policy tag is dependent upon where the data is located within the mailbox. Our primary focus is on recoverable items for mailboxes on holds; therefore, we need to create a tag to move recoverable items older than x number of days to archive.

New-RetentionPolicyTag -Name RecoverableItems_31_MoveToArchive -MessageClass * -RetentionAction MoveToArchive -AgeLimitForRetention 31.0:0:0 -Type RecoverableItems -RetentionEnabled:$True -Comment "Archive all items from the Recoverable Items over 31 days"

This tag must be added to a retention policy, and the retention policy must be assigned to the user being migrated. Once this is done, you can start the managed folder assistant (MFA) to move items into the remote archive.

Start-ManagedFolderAssistant user@contoso.com

Note: A new retention policy may need to be created specifically for these larger mailboxes.

Speed up expanded archives

One issue with migrating large mailboxes is the delay caused by auto-expanding archives. Thankfully, this delay depends on Exchange processes, which we can observe and activate manually when needed.

The first thing to do is keep an eye on your archive mailbox size. Once it hits 90GB, auto-expansion should kick in. To track this, check the mailbox statistics for the archive mailbox.

Get-MailboxStatistics <guid of MainArchive shard of MailUser> | fl *itemCount,*ItemSize

AssociatedItemCount	6
DeletedItemCount	290041
ItemCount	2
TotalDeletedItemSize	100 GB (107,374,646,793 bytes)
TotalItemSize	557.2 MB (584,222,341 bytes)

The results indicate that the TotalDeletedSize has reached 100GB, which is the established quota limit. At this threshold, the auxiliary archive should trigger the next time the managed folder assistant (MFA) runs against the mailbox. Manually start the MFA to expedite this process:

Start-ManagedFolderAssistant <guid of MainArchive shard of MailUser>

Confirm MFA has completed by checking the ELCLastSuccessTimestamp:

(Export-MailboxDiagnosticLogs -Identity <guid of MainArchive shard of MailUser> -ExtendedProperties).mailboxlog | Select-Xml -XPath "//MailboxTable/*" | select -ExpandProperty Node | ? {$_.name -like "ELC*"}

Once the auxiliary archive becomes available, Exchange will initiate the process of copying data into the new mailbox. The MFA must be triggered again to start copying data. Then we can proceed to verify whether any folders have been ghosted using the following steps:

$folders = Get-MailboxFolderStatistics -FolderScope recoverableitems <guid of MainArchive shard of MailUser>

$folders | ?{-Not $_.ContentFolder -and $_.VisibleItemsInFolder} | Sort-Object LastMovedTimeStamp | ft FolderSize,LastMoved*,Content*

FolderSize	LastMovedTimeStamp	ContentFolder	ContentMailboxGuid
17.79 GB	11/28/2024 10:25:07 PM	False	GUID of Aux archive
12.95 GB	11/28/2024 10:25:07 PM	False	GUID of Aux archive
1.371 MB	11/28/2024 10:25:07 PM	False	GUID of Aux archive
11.14 GB	11/28/2024 10:25:07 PM	False	GUID of Aux archive

These folders have been copied to an auxiliary archive but are not yet expired on the MainArchive, leaving about 43GB of storage pending release. MFA will free this space after its next run, once five days have passed since "11/28/2024 10:25:07 PM".

Our monitoring speeds up the process since MFA may take several days to finish. After five days from the LastMovedTimeStamp, we manually start the MFA using the following command:

Start-ManagedFolderAssistant <guid of MainArchive shard of MailUser>

You will notice these folders shrinking and the primary archive gaining free space.

If there are no ghosted folders and the mailbox is full or exceeds 90GB of recoverable items, start MFA to trigger expansion. It may help to run MFA more than once and confirm that it completed successfully.

Conclusion

Using Messaging Records Management (MRM) ahead of a large mailbox migration helps reduce primary mailbox and recoverable items pressure by moving older content into the archive, improving the likelihood of staying within Exchange Online limits and accelerating move performance. With the right prerequisites in place, you can actively monitor archive growth and expansion. When the archive approaches capacity or when ghosted folders are older than five days, targeted monitoring and triggering MFA against a mailbox can accelerate expansion and free space sooner—keeping migrations on track.

Use MRM to move Recoverable Items older than your chosen threshold into the archive before starting migrations.
Track archive statistics (especially TotalDeletedItemSize/TotalDeletedSize) to anticipate auto-expansion and identify bottlenecks.
Monitor ghosted folders and run MFA after the relevant LastMovedTimeStamp interval to accelerate cleanup.

Automating Azure OpenAI/Foundry Model Lifecycle Management

anishekkamal — Thu, 05 Feb 2026 12:39:21 GMT

Disclaimer: The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of Microsoft Corporation.

Last week, I got an Teams call from a customer: "Our production app just went down. Deployment is throwing authentication errors and we can't figure out why."

Working as a Cloud Solution Architect at Microsoft, I've debugged my fair share of Azure OpenAI issues. This one didn't take long to figure out—they were running a model version that Microsoft had retired three months ago. The retirement announcement?

Buried somewhere in their inbox, probably marked as read but never actually read. The result? Several hours of downtime and some very stressed engineers.

Here's the thing: this keeps happening. As teams spin up more Azure OpenAI deployments, keeping track of everything manually just doesn't work anymore.

The Challenge: Managing Azure OpenAI Deployments at Scale

You start with one Azure OpenAI/Foundry deployments, maybe two model deployments. Simple enough. Six months later? You've got 30+ deployments scattered across resource groups, different teams testing different model versions, and you're pretty sure you're paying for stuff nobody's using anymore.

Here are the main headaches I see teams dealing with:

Model Retirements Sneak Up On You - Microsoft updates and retires models regularly (GPT-4, GPT-3.5, you name it). If you're not actively tracking this, you'll find out the hard way when production breaks.

Ghost Deployments Everywhere - Remember that Provisioned Throughput Unit someone created for "just testing"? It's still running. Still costing $5,000/month. Still getting zero API calls. This stuff adds up fast.

Compliance is a Mess - When your auditor asks "who's been accessing these AI models and from where," digging through Azure Portal logs manually is nobody's idea of a good time.

No One Knows What's Actually Deployed - In bigger orgs, teams deploy models independently. Nobody has a complete picture of what's out there, where it's running, or what it's costing.

Tracking this manually doesn't scale. Spreadsheets are outdated the second you save them. You need something automated.

The Solution: An Open-Source Audit Tool

I built a tool that handles all of this automatically. It scans your Azure subscriptions, finds every OpenAI and AI Foundry deployment, pulls actual usage data from Azure Monitor, and flags models that are about to retire.

Here's what it does:

Finds all your Azure OpenAI and AI Services accounts automatically

Grabs real usage metrics—API calls, token counts, the works

Compares what you've deployed against Microsoft's official retirement schedules

Spits out CSV reports with everything you need: inventories, usage stats, retirement warnings

Can even configure diagnostic settings and pull detailed logs from Log Analytics if you need them

Best part? Zero dependencies. Just Python standard library. It runs Azure CLI commands under the hood (which you probably already have installed anyway).

Grab it here: https://github.com/anishek-microsoft/foundry_model_audit

How This Can Help You

Catch Cost Leaks Before They Drain Your Budget

Ever wonder if you've got deployments sitting idle? The audit shows you exactly which ones have zero usage. Those Provisioned Throughput Units (PTUs) are expensive—if one's been sitting there doing nothing for weeks, you'll know immediately.

Plan Model Migrations Without the Panic

Instead of scrambling when a model gets retired, you'll see it coming months in advance. The tool flags everything that's approaching retirement and even shows Microsoft's suggested replacements. You get time to test, update configs, and migrate smoothly. No emergency meetings, no rushed deployments.

Make Compliance Audits Actually Manageable

Need detailed logs showing who accessed your AI models and when? Enable diagnostic settings and the tool pulls all that data from Log Analytics into a clean CSV. When audit season rolls around, you've got comprehensive access reports ready to go instead of manually piecing together Portal logs.

Get Visibility Across Your Whole Organization

If your Azure environment is anything like most I work with, you've got multiple teams deploying independently. This gives you one complete picture: every account, every deployment, every region. You'll finally know what you're actually running and what it's costing.

How It Actually Works

The tool ties into Azure Resource Manager, Azure Monitor, and Log Analytics. Here's the flow:

Uses your existing `az login` session (no extra auth needed)
Scans Azure Resource Manager for OpenAI and AI Services accounts
Calls Azure REST APIs to list all deployments (handles different API versions automatically)
Pulls metrics from Azure Monitor—API calls, token counts, last 7 days of data
Checks deployments against a JSON file of Microsoft's official retirement dates
Optionally queries Log Analytics with KQL for detailed usage logs

I keep the retirement database (`model_retirements.json`) updated with Microsoft's docs. There's a helper script if you want to update it yourself from CSV exports.

Everything outputs to timestamped CSV files. Easy to open in Excel, diff between runs, or feed into your BI tools.

Getting Started

Three commands and you're running:

# Grab the code git clone https://github.com/anishek-microsoft/foundry_model_audit.git cd foundry_model_audit # Log into Azure if you haven't already az login # Run it python foundry_model_audit.py

You'll get a timestamped folder (like `foundry-audit-20260126-114221/`) with five CSV files:

openai_deployments.csv - Everything you've got deployed
targeted_deployments.csv - Specific models you're tracking with usage data
model_retirement_alerts.csv - What's retiring soon
log_analytics_detailed_logs.csv - Detailed audit logs (if you enabled diagnostics)
openai_no_diagnostics.csv - Accounts that don't have logging turned on

Want to check specific models?

python foundry_model_audit.py --target-models '[{"ModelName":"gpt-4","Versions":["0613","1106-preview"]}]'

Enable detailed logging:

python foundry_model_audit.py --enable-diag --diag-workspace-id "/subscriptions/.../workspaces/my-workspace"

Full documentation, parameters, and examples are in the [README](https://github.com/anishek-microsoft/foundry_model_audit).

What to Look For in the Reports

Find the dead weight: Check `targeted_deployments.csv` for anything with `totalCalls_7d = 0`. If it's been sitting idle for a month, time to shut it down.
Spot the money burners: Filter for `sku = ProvisionedManaged` (those are PTUs) with low usage. You're paying fixed costs whether you use them or not. Low usage means you're probably wasting money.

Watch for upcoming retirements: In `model_retirement_alerts.csv`, anything retiring in less than 90 days needs your attention. Microsoft usually suggests what to upgrade to, so you've got a migration path.

Security check: In `log_analytics_detailed_logs.csv`, scan for weird `CallerIP` or `Identity` values. If you see API calls from places or accounts you don't recognize, that's worth investigating.

Things I'd Recommend

Run this regularly, not just once. Set up a weekly job (Azure Function or scheduled task, whatever works). Track how things change over time—usage patterns, costs, new deployments.

Don't let retirements surprise you. Set up some kind of alert for models retiring in the next 90 days. Give yourself time to plan migrations instead of firefighting.

Be smart about logging. Turn on diagnostics for production stuff where you need compliance trails. For test/dev environments? Maybe skip it to save on Log Analytics costs. (First 5GB/month is free, but it adds up if you're logging everything.)

Keep audit data secure. These logs have IP addresses, identities, sometimes request details. Don't commit them to Git. Use Azure Blob Storage with proper access controls. Encrypt if you're in a regulated industry.

Establish an audit cadence. Here's what I recommend:

Weekly: Run the full audit to catch new deployments and usage changes

Monthly: Review retirement alerts and plan migrations for anything < 90 days out

Quarterly: Deep-dive cost analysis—look for PTU optimization opportunities and capacity right-sizing

This schedule aligns well with Microsoft's typical model retirement announcement cadence (usually 90+ days notice).

Taking It Further: Automation and Dashboards

Running this manually is useful, but you're probably wondering: "Can I automate this whole thing?" Yep. Here's how I'd set it up:

Run Audits Automatically with Azure Functions

Deploy the script as an Azure Function with a timer trigger. Set it to run every Monday morning, whatever works for you.

Basic setup:

Timer trigger kicks off the audit weekly
Use Managed Identity so you don't have to mess with credentials
Save CSV files to Blob Storage
Event Grid notifies you when new reports are ready

Why this works well:

No servers to maintain

Scales automatically if needed

Built-in logs and monitoring

Consumption plan keeps costs low

Sample deployment:

import azure.functions as func import subprocess from azure.storage.blob import BlobServiceClient from datetime import datetime def main(mytimer: func.TimerRequest) -> None:     # Run the audit     result = subprocess.run(['python', 'foundry_model_audit.py'],                           capture_output=True, text=True)     # Upload results to Blob Storage     timestamp = datetime.utcnow().strftime('%Y%m%d-%H%M%S')     blob_service = BlobServiceClient.from_connection_string(os.environ['STORAGE_CONNECTION'])     # Upload each CSV file     for csv_file in ['openai_deployments.csv', 'targeted_deployments.csv', 'model_retirement_alerts.csv']:         blob_client = blob_service.get_blob_client(container='audit-reports', blob=f'{timestamp}/{csv_file}')         with open(csv_file, 'rb') as data:             blob_client.upload_blob(data)

Build Dashboards with Power BI

Once audit data is flowing to Blob Storage, hook up Power BI for some actual visibility:

Useful dashboard views:

Cost tracking
- How many deployments per account and region
- PTU deployments sitting idle (easy cost savings)
- Cost trends month-over-month
- Top 10 most expensive underused deployments

Retirement timeline
- Calendar showing when stuff's retiring
- Group by urgency (30/60/90 days out)
- Track migration progress

Usage patterns
- API call trends
- Token usage (prompt vs completion)
- Which deployments are actually getting hit
- Spot unusual spikes

Compliance view
- Which accounts have logging enabled
- Access patterns by user/service principal
- Overall audit coverage

Setup is pretty standard:

Connect to Blob Storage, import the CSVs with Power Query, build some visuals, set auto-refresh, publish to Power BI Service. Set up alerts for critical stuff (like models retiring in 30 days).

Get Alerts in Microsoft Teams

Use Power Automate to push notifications to Teams when stuff needs attention:

Flow setup:

Trigger when a new blob shows up (new audit report)
Parse the CSV for important stuff (retirements, unused PTUs)
Post an adaptive card to your Teams channel

You'll get messages like: "Hey, found 5 unused Provisioned deployments worth $12K/month" or "3 models retiring in next 90 days." Beats checking manually.

Enterprise Workflows with Logic Apps

For bigger setups, Logic Apps can orchestrate more complex stuff:

Loop through multiple subscriptions automatically
Route alerts to the right team owners
Create work items in Azure DevOps for migrations
Send exec summaries via email weekly

Basically turns this from a one-off script into a proper governance system that runs itself.

Wrapping Up

Managing Azure OpenAI at scale isn't easy. The cloud moves fast, models retire, costs creep up, and keeping track of everything manually just doesn't work past a certain point.

This tool won't solve every problem, but it'll give you visibility. You'll know what's deployed, what's actually being used, what's wasting money, and what's about to retire. That's a huge step up from flying blind.

Want to try it?

Grab the code:https://github.com/anishek-microsoft/foundry_model_audit)
Run `python foundry_model_audit.py` on your subscription
See what you find

Set this up, run it regularly, and save yourself some headaches.

Hardening Spring Boot Health Probes on AKS: How to Prevent Restart Storms Before They Start

AndreasSemmelmann — Thu, 05 Feb 2026 12:37:41 GMT

Overview

Transient platform degradations can turn into outages if health probes are overly strict or wired to the wrong endpoint. In this case study, multiple incidents were reported in which many Spring Boot pods restarted in a short time window on Azure Kubernetes Service (AKS), contributing to visible downtime.

A key lesson is that probing the consolidated /actuator/health endpoint can amplify blast radius: if any health contributor degrades, the overall endpoint can report unhealthy. When that endpoint is used for liveness, kubelet can restart pods at scale and create a feedback loop (mass restarts → node pressure → additional failures).

The remediation combined two changes:

separating liveness and readiness onto the dedicated Actuator probe endpoints (/actuator/health/liveness and /actuator/health/readiness), and
tuning probe thresholds (especially timeoutSeconds) to tolerate brief latency spikes.

This article targets platform engineers and SREs and provides a baseline configuration, a troubleshooting checklist, and a simple validation approach.

Environment (for reproducibility)

This scenario was observed on AKS (Kubernetes 1.30.3) with Spring Boot 2.3.x and an NGINX Ingress Controller deployed as a separate workload. Node OS image and JDK details are not required for the probe wiring and threshold tuning discussed here.

The Challenge

On AKS, even a short-lived control plane latency spike can ripple into workload behavior if kubelet health checks are configured too aggressively. Probes are meant to protect reliability, but when they are wired to the wrong signal they can turn a brief degradation into a restart loop.

Problem statement: Probe design amplified a transient AKS control plane degradation into a mass pod restart event.
Business impact: Visible downtime and unstable service behavior due to restart storms across multiple microservices.
Who’s affected: SREs, platform engineers, and application teams operating Spring Boot workloads on Kubernetes (especially AKS).

What Happened?

We saw a familiar pattern: many Spring Boot pods restarted within a short window, and probes started failing across a large part of the fleet at the same time.

Incident timeline

On 2025-03-25, downtime was reported across multiple Spring Boot-based microservices due to widespread pod restarts, and the event was associated with elevated Kubernetes API server connectivity/latency issues on the Linux node pool. A similar pattern was reported again on 2025-06-02: probes failed for many pods in a short window, restarts followed, and the system needed ~15 minutes to stabilize while CPU/memory pressure was elevated.

Why this failure mode is common

What made the situation worse was the probe design: liveness and readiness were both wired to the same composite health endpoint (/actuator/health) and the liveness timeout was very strict. Under transient latency, that combination can turn “brief slowness” into “restart many pods”, and restarts add even more pressure to nodes and the cluster.

The Solution

We kept the solution intentionally simple and AKS-focused: reduce the blast radius during transient cluster/platform slowness, and prevent kubelet from turning short probe timeouts into mass restarts.

Concretely, we did two things:

moved readiness/liveness to the dedicated Actuator probe endpoints, and
increased probe timeouts/thresholds to tolerate brief latency spikes.

1) Use dedicated Actuator probe endpoints

Spring Boot Actuator exposes health endpoints under /actuator/health. The consolidated endpoint is intentionally broad (it reflects multiple health contributors). For Kubernetes probes, it is usually better to use dedicated readiness/liveness endpoints so a transient dependency issue can stop traffic without forcing restarts.

In this case, we moved

readiness to /actuator/health/readiness (so AKS can stop sending traffic when the instance is not ready) and
liveness to /actuator/health/liveness (so short slowness does not trigger restarts).
We kept /actuator/health for human-facing checks and dashboards.

This article focuses on Kubernetes probe wiring and thresholds. The exact Spring Boot Actuator configuration (application.yml, environment variables, and the enabled health groups/contributors) is application-specific and does not change the core recommendation: use the dedicated probe endpoints for readiness/liveness and tune probe thresholds for transient latency.

If you want a minimal Spring Boot baseline for these endpoints (Spring Boot 2.3+), it typically looks like this:

management:
  endpoint:
    health:
      probes:
        enabled: true

2) Tune probe thresholds to match reality

If the platform experiences brief latency spikes, timeoutSeconds: 1 is often too aggressive for liveness.

Implementation (Step-by-Step)

The YAML snippets below illustrate the probe configurations used before and after the remediation.

Step 1 — Baseline probe behavior (before)

Scenario 1 (before): readiness + liveness wired to /actuator/health

Baseline/original readiness probe (as captured):

readinessProbe:
  httpGet:
    path: /actuator/health         # Spring Boot health endpoint for readiness
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

Baseline/original liveness probe (as captured; failureThreshold not specified):

livenessProbe:
  httpGet:
    path: /actuator/health         # Spring Boot health endpoint for liveness
    port: 8080
  initialDelaySeconds: 40
  periodSeconds: 15
  timeoutSeconds: 1
  # failureThreshold not specified (defaults apply)

Step 2 — Separate liveness and readiness endpoints (after)

Scenario 2 (after): readiness gates traffic, liveness avoids restart loops

Remediated readiness probe:

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 5
  timeoutSeconds: 5
  failureThreshold: 3

Remediated liveness probe:

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 30
  timeoutSeconds: 30
  failureThreshold: 5

Step 3 — Add a startup probe (recommended)

Use a startup probe to prevent liveness/readiness from flapping while the JVM warms up (classloading, DB migrations, cache priming). The values below are a safe starting point for many Spring Boot services; tune them based on observed startup time.

startupProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  # Allows up to 5 minutes for cold start: 30 * 10s = 300s
  failureThreshold: 30
  periodSeconds: 10
  timeoutSeconds: 5

Architecture / Dataflow

This diagram shows the causal chain at a glance: a transient platform issue can surface as slower health responses, which then interacts with probe thresholds to decide whether traffic is removed or containers restart.

Validation (How to Prove It Worked)

Validation is a simple before/after check: after the change, probe failures and restarts should drop, and short AKS/platform slowness should lead to traffic being gated (readiness) instead of mass restarts (liveness). If you can capture sanitized metrics, focus on restart rate, probe failures, ingress 5xx, recovery time, and (when available) control plane latency.

Troubleshooting Checklist (How to Diagnose)

Use this when you see synchronized restarts across many pods.

Confirm the restart pattern. Start by watching pods and checking placement.
1. ```
kubectl get pods -n <ns> -w
```
2. ```
kubectl get pods -n <ns> -o wide
```
Check events and probe failures. You want to see whether kubelet is killing containers due to probe timeouts.
1. ```
kubectl get events -n <ns> --sort-by=.lastTimestamp
```
2. ```
kubectl describe pod <pod> -n <ns>
```
Identify restart reasons. Look for CrashLoopBackOff, OOMKilled, and repeated probe failure events.

Validate Actuator endpoint behavior from inside the pod. This confirms which endpoint flips and how fast it responds.

kubectl exec -n <ns> <pod> -- curl -sS -m 5 http://127.0.0.1:8080/actuator/health

kubectl exec -n <ns> <pod> -- curl -sS -m 5 http://127.0.0.1:8080/actuator/health/readiness

kubectl exec -n <ns> <pod> -- curl -sS -m 5 http://127.0.0.1:8080/actuator/health/liveness

Correlate with AKS/platform signals. If available, correlate probe failures with control plane latency signals.

Security Notes (Don’t Create a New Exposure)

Treat Actuator as an internal-only surface. Probes need access, but that does not mean the internet does.

Controls that typically work well for this pattern:

Avoid routing Actuator endpoints through an internet-facing ingress.
If ingress is unavoidable, use internal exposure and strict allowlists.
Keep Actuator exposure minimal (only the health endpoints needed for probes).

Discussion & Feedback

If you’ve run similar AKS incidents, I’d love to compare notes:

Have you seen probe failures cascade into mass restarts?
Do you wire liveness to a “full health” endpoint today, and why?
What timeout and failure threshold values have proven reliable in production?

Resources

If you want to go deeper, these references cover the probe mechanics and the Spring Boot side of the health model:

⚠️ Microsoft Support Statement

This article represents field experiences and community best practices. For official Microsoft support and SLA-backed guidance:

Production issues: For production-impacting problems, contact Microsoft Support.

🔒 Customer Privacy Notice

This article describes real-world scenarios from customer engagements. All customer-specific information has been anonymized:

Company names are replaced with industry categories, exact metrics are generalized where necessary, and infrastructure details are sanitized.

🤝 Community Contribution

We welcome corrections, improvements, and additional real-world examples. If you spot an issue or have a better probe hardening pattern, share it via comments or reach out.

🤖 AI Tools Disclosure

Parts of this article were created with assistance from AI tools to improve clarity and structure. Review and validate all content before publication.

Conditional Access for Canvas Apps with Entra

mlotorto — Fri, 30 Jan 2026 15:50:56 GMT

In today's Power Platform landscape, administrators have a tough task securing the ever-increasing inventory of Canvas Apps across their tenant. Canvas apps often connect to sensitive data, run on a variety of devices, and serve diverse groups of users. That is why Conditional Access has become one of the most powerful tools in an admin’s toolkit, giving you fine grained control over how, where, and under what conditions users can access your apps.

In this post, I will walk through what Conditional Access means for canvas apps, how it empowers admins to maintain strong security without adding friction for legitimate users, and example steps to apply your own conditional access policies to an app with PowerShell.

What Conditional Access Brings to Canvas Apps

Conditional Access brings granular, app-level security controls from Microsoft Entra ID directly into Power Apps. Instead of applying blanket restrictions across the entire tenant, you can enforce requirements—like MFA, compliant devices, or trusted networks—only on the apps that need them.

This lets you match security to the sensitivity of each individual app.

Key Benefits for Admins

Tailored Protection for Sensitive Apps

Not every app requires strict controls. Conditional Access allows you to tighten security only for apps that handle sensitive or regulated data, without over restricting everything else.

Control Access by Device Type

Admins can easily block or allow specific device categories—like preventing mobile access to a high-risk app or requiring managed devices for apps that contain confidential information.

Alignment With Zero Trust

Conditional Access enforces identity, device, and session checks in real time, supporting a Zero Trust approach without adding unnecessary friction for legitimate users.

Environment-Specific Flexibility

You can apply stricter policies in production and lighter ones in development or testing, helping teams build efficiently while keeping sensitive environments locked down.

A Stronger Security Model

Conditional Access does not replace existing apps or data permissions—it complements them. App-level security roles control what users can do inside an app, while Conditional Access governs whether they can get into the app at all. Together, they create a much more robust security posture.

How to enable conditional access for a Canvas App example

In this example, I will detail steps to set up conditional access for a Canvas App to ensure tenant guest users are not able to access the app.

Step 1: Create an Authentication Context in Entra ID

Go to the Microsoft Entra Admin Center.
Navigate to Protection → Conditional Access → Authentication context.
Click + New authentication context.

Name it (e.g., BlockGuests_PowerAppX)

Enable Publish to apps

Save and note the Authentication Context ID

Step 2: Create a Conditional Access Policy

Go to Conditional Access → Policies → + New policy.
Name the policy (e.g., Block Guests from Power App X).

Assignments:

Users or workload identities:

- Include: Guest or external users

Target resources:

- Choose Authentication context

- Select the one you created earlier

Access controls:

Grant: Select Block access

Enable the policy and click Create.

Step 3: Assign the Authentication Context to the Power App

Use PowerShell to bind the Authentication Context to the specific Power App:

Open PowerShell as Administrator.
Connect to Power Apps

Add-PowerAppsAccount

Run the command to attach the context to your canvas app

Set-AdminPowerAppConditionalAccessAuthenticationContextIds

-EnvironmentName "<your-environment-name>" `

-AppName "<your-app-id>" `

-AuthenticationContextIds "<your-auth-context-id>"

This binding tells Power Apps: “When this app opens, trigger the Conditional Access policy tied to this context.”

Step 4: Test the Policy

Try accessing the app as a guest user.

You should see access blocked based on the Conditional Access policy.

Wrap Up

A Stronger Security Model

Bottom Line

Conditional Access gives admins the flexibility to apply the right security to the right app. Whether you are enforcing MFA, restricting device types, or securing production environments, it helps you protect sensitive data without slowing down the organization.

Documentation for further reading: Manage Power Apps - Power Platform | Microsoft Learn

Demo from Power CAT: Conditional Access Policies for Canvas Apps - Power CAT Live

Microsoft Sentinel and Dataverse Integration

jcollado — Wed, 28 Jan 2026 20:53:45 GMT

Integrating Microsoft Sentinel with Microsoft Dataverse brings advanced, unified security monitoring to your Power Platform environments.

Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) that collects and correlates logs from across Azure, Microsoft 365, and more to detect and respond to threats in real time.

By streaming Dataverse audit logs into Sentinel, organizations gain centralized visibility into Power Platform activity and can leverage Sentinel’s analytics and automation to rapidly detect suspicious behavior and enhance governance.

Benefits of Connecting Dataverse to Sentinel

Unified Visibility and Threat Detection: All Dataverse audit events (e.g. record access, changes, logins) are ingested into Sentinel, where they can be correlated with signals from identities, devices, and other applications. This holistic view enables detection of suspicious patterns that might be missed in isolation.

For example, security analysts can spot anomalies like:

- mass data exports

- unusual access locations

- sudden policy changes in Dataverse operations

Sentinel provides out-of-the-box analytics rules to flag many of these risky behaviors (such as a departing user downloading large datasets or deleting records) without requiring custom queries.

2. Faster Investigation and Response: With Dataverse logs in Sentinel, analysts can use Kusto Query Language (KQL) to quickly search and correlate Dataverse activity with other security logs (identity sign-ins, Office 365 events, etc.). This speeds up root-cause analysis during incidents.

Moreover, Sentinel’s SOAR capabilities mean you can trigger automated playbooks in response to Dataverse threats. For instance, if Sentinel detects an anomalous privilege escalation in Dataverse, it could automatically disable the user’s account or alert an admin via Teams. This rapid, automated response helps contain threats immediately, reducing the time to mitigate incidents.

3) Improved Governance and Compliance: Integrating Dataverse with Sentinel strengthens oversight of Power Platform usage. All audit logs are stored in Sentinel’s scalable data lake, allowing long-term retention for compliance at a lower cost than storing in Dataverse. By correlating Dataverse activity with other enterprise logs, organizations can ensure that Power Platform apps adhere to security policies and can prove compliance.

Prerequisites

Before deploying the integration, ensure the following prerequisites are in place:

Microsoft Sentinel workspace:

Microsoft Sentinel enabled in the workspace: (See Here to Onboard to a Microsoft Sentinel Workspace)

2. You must have permission to create Data Collection Rules (DCR) and Data Collection Endpoints in that workspace.

Roles and permissions in the Microsoft Sentinel platform | Microsoft Learn

Data collection rules in Azure Monitor - Azure Monitor | Microsoft Learn

Dataverse environment:

3. The Dataverse environment must be a production environment (Dataverse logging for Sentinel is only supported for production, not sandbox).

4. Your organization should be using Dynamics 365 Customer Engagement and/or Power Platform apps (since those rely on Dataverse).

5. Audit logging enabled: Auditing must be turned on for the Dataverse environment in the Power Platform admin settings (which also routes audit logs to Microsoft Purview).

Setup

With prerequisites met, follow these high-level steps to set up the Sentinel integration:

Enable Dataverse Auditing (if not already enabled).In the Power Platform admin center, ensuretenant-level and environment-level auditing is on. Dataverse auditing is not enabled by default, so this is critical. You’ll also need to enable auditing on the entity (table) level for all relevant Dataverse tables. Microsoft provides a managed solution to simplify this:

- Import the Audit Settings solution: If your environment uses Dynamics 365 CE apps, import the solution from aka.ms/AuditSettings/Dynamics; otherwise use aka.ms/AuditSettings/DataverseOnly. This managed solution will turn on detailed auditing for all standard tables (entities) in Dataverse.

- For any custom tables, manually enable auditing in their settings (toggle on Auditing for the entity).

- In each entity’s settings, under Auditing, enable the options for “Single record auditing” and “Multiple record auditing” to capture detailed create/update/delete events. Then save and publish these changes. Enabling these ensures you capture granular audit logs needed for Sentinel.

2. Install the Sentinel Solution and Connect Data Sources. In the Azure Sentinel portal Azure Portal or the Security Admin Portal Defender Portal navigate to the Content hub (or in Microsoft Defender portal, go to Content hub for Sentinel) and install the “Microsoft Sentinel Solution for Microsoft Business Applications.”

This deploys all the components (analytics rules, workbooks, connectors, etc.) for Power Platform integration. Once installed, go to Configuration > Data connectors in Sentinel. You will see new connectors available for:

- Microsoft Dataverse

- Microsoft Power Platform Admin Activity

- Microsoft Power Automate

(A connector for Dynamics 365 Finance & Operations is also included for organizations using Dynamics F&O). Follow this link for more details on F&O connector: Connect Microsoft Dynamics 365 Finance and Operations to Microsoft Sentinel | Microsoft Learn

For each relevant data connector (Dataverse, Power Platform Admin, Power Automate), open its page and select Connect. This step links your Dataverse environment’s audit stream to Sentinel via the Azure Monitor DCR infrastructure. After connecting, Sentinel will start listening for the audit logs from Purview.

ValidateData Ingestion. With auditing enabled and connectors in place, perform some sample activities in your Dataverse environment to generate logs (for example, create or update a row in a Dataverse table, change a Power Platform environment setting, run a Power Automate flow).

In general, Dataverse and Power Automate activity logs should begin flowing into Sentinel within a few minutes, whereas Power Platform admin logs (e.g. environment or D365 admin actions) may take up to an hour for the first time. Be patient and then verify ingestion by querying the logs in Sentinel. You can run KQL queries in the Logs blade of the Sentinel Azure portal (or the Hunting section of Defender portal) to confirm data is arriving.

For example, run a query on the PowerPlatformAdminActivity table to see if recent records exist.

After a successful setup, Microsoft Sentinel will be populating three main Log Analytics tables with your Dataverse-related logs (as listed below):

Log Analytics Table	Data Collected
PowerPlatformAdminActivity	Power Platform administrative logs (e.g. environment settings changes, user role assignments)
PowerAutomateActivity	Power Automate (Flow) activity logs (creation, runs, etc.)
DataverseActivity	Dataverse and model-driven app business data activity logs (create, update, delete events on records, etc.)

These tables contain the audit data that Sentinel will use for analysis. For instance, an update to a row in a Dataverse table will generate an event in the DataverseActivity table, whereas an administrative action like changing a Data Loss Prevention (DLP) policy or adding a user to an environment appears in PowerPlatformAdminActivity.

Analytics and Threat Detection Capabilities

Once the data is flowing, you can leverage Microsoft Sentinel’s powerful analytics and automation on your Dataverse logs. The Microsoft Business Apps Sentinel solution you installed comes with prebuilt analytics rules tailored to Dataverse and Power Platform scenarios. These rules will automatically generate incidents for suspicious patterns, such as:

Mass record downloads or deletions (which could indicate a potential data theft or misuse)

Anomalous access, like a user accessing Dataverse from an unusual location or at an odd time

Privilege escalations or policy changes, e.g. a user suddenly gaining a system admin role, or a DLP policy being turned off.

Security teams can also create custom detection rules using KQL to address organization-specific threats. All the Dataverse audit logs in Sentinel are fully queryable – for example, you could write a query to find when a particular record was modified and by whom, or to detect an unusual spike in Power Automate flow failures. These queries can be turned into new alert rules as needed. Sentinel provides interactive workbooks and a hunting interface to help visualize and drill into this data for proactive threat hunting.

In addition to detection, Sentinel enables automated response for Power Platform incidents. Using Playbooks (Logic Apps), you might automate actions like disabling a user’s Power Platform account, alerting the IT team via Microsoft Teams, or creating a ticket in ServiceNow whenever a high-severity Dataverse incident is detected. For example, if multiple deletion events are detected in a short span on a sensitive table, a playbook could immediately notify a security channel and suspend the user's access pending investigation. This kind of end-to-end automation greatly improves your security posture by reducing response times and ensuring consistent actions.

In summary, connecting Dataverse auditing to Microsoft Sentinel equips organizations with a unified view of business application activity and the advanced tools to detect, investigate, and respond to potential security issues in their Power Platform environments. It marries the rich audit data from Dataverse with Sentinel’s powerful SIEM capabilities – enabling proactive monitoring of user actions, quick identification of anomalies, and automated defense measures to protect your low-code applications. With the integration set up, Power Platform admins and security analysts can rest easier knowing that any unusual or malicious activity in Dataverse will light up on the Sentinel radar and be handled swiftly.

For detailed step-by-step guidance, refer to Microsoft’s documentation on connecting Power Platform (Dataverse) to Sentinel and Connect Microsoft Dynamics 365 Finance and Operations to Microsoft Sentinel | Microsoft Learn These resources provide deeper instructions and additional tips for a successful integration.

SAP RISE & HANA Data Migration: AWS S3 to Azure Blob Storage via Azure Storage Mover

AnuradhaKarnam — Wed, 21 Jan 2026 07:01:02 GMT

Introduction:

Cloud migration using Azure Storage Mover enables high‑volume data transfer from Amazon S3 into Azure Blob Storage as part of SAP on Azure modernization initiatives, including RISE and SAP HANA deployments. Azure Arc multicloud connectors provide control‑plane integration with AWS, allowing Azure to authenticate and discover S3 buckets and expose them as managed external resources.

Storage Mover then orchestrates the end‑to‑end data movement using S3 source and Blob target endpoints, supporting large‑scale migrations with telemetry, integrity validation, and incremental sync options. Migrated datasets land in Azure Blob Storage, where they can be consumed by SAP HANA, SAP Data Intelligence, SAP S/4Hana, BW/4Hana and downstream Azure analytics or backup workflows.

The process completes as the data lands in Azure Blob Storage, establishing a cloud‑native destination for ongoing analytics, applications, or archival needs. This guide outlines the essential prerequisites, service limits, and configuration steps required to implement migration with clarity and operational confidence.

End‑to‑End Migration with SAP Consumption Diagram:

The migration process begins with Amazon S3, which serves as source storage containing the files and folders you intend to transfer to Azure. Azure then connects securely to your AWS environment through the Azure Arc Multicloud Connector, which authenticates to AWS, discovers your S3 buckets, and exposes their inventory to Azure as part of its cross‑cloud control‑plane integration. Once connected, Azure Storage Mover a fully managed migration engine executes the data transfer using the configured S3 source endpoint and Azure Blob target endpoint.

Storage Mover supports large‑scale migrations of up to 500 million objects per job, provides incremental sync options, and offers detailed logging and job tracking for operational visibility. Once migrated datasets are staged in Azure Blob Storage, where they can be leveraged by SAP HANA, SAP Data Intelligence, SAP S/4HANA, BW/4HANA, and integrated Azure analytics or backup workflows. The cloud‑native destination that supports containers, lifecycle policies, and seamless integration with Azure analytics and application services such as Azure Synapse, Azure Data Factory, and AI workloads.

1) Prerequisites:

An active Azure subscription with the required permissions to manage Azure Storage Mover and Azure Arc resources.
An AWS account with access to the Amazon S3 bucket you plan to migrate.
A destination Azure Storage account to receive the transferred data.
An Azure Storage Mover resource already deployed in your Azure environment.

2) Service Limits:

Supports up to 500 million objects per migration job.
Allows a maximum of 10 concurrent migration jobs per subscription (higher limits available through support).
Archived objects are not automatically rehydrated: Data in Deep Archive or Glacier must be restored before migration.
Private networking is not supported: Secure data transfer is enforced using trusted Azure IP ranges.

3) Create Multicloud Connector for AWS:

Use Azure Arc to connect AWS services to Azure, enabling discovery and data transfer operations.
Steps include selecting subscription, region, AWS account ID, and adding Inventory and Storage Data Management solutions.

4) Configure Endpoints:

AWS S3 Source Endpoint - Navigate to Storage Endpoints → Source endpoints → Add endpoint. Select the AWS S3 bucket from the multicloud connector.
Azure Blob Storage Target Endpoint - Select your subscription, storage account, and blob container. Assign Storage Blob Data Contributor RBAC role.

5) Creating Migration Project & Job Definition:

Create a migration project under Project Explorer.
Add a Job Definition specifying source S3 endpoint and target Blob endpoint. Select migration mode: Mirror, Incremental, or Full copy.

6) Run & Monitor Migration Job:

Start the job from the Job Properties pan.
Monitor speed, progress %, and estimated completion time in Migration Overview. Review logs for warnings or transfer errors.

7) Post-Migration Validation:

Verify data integrity and completeness.
Conduct UAT testing.
Enable incremental sync if needed.
Optionally delete S3 bucket after migration is validated.

Conclusion:

The combined use of Azure Storage Mover and Azure Arc Multicloud Connector provides robust, scalable, and secure architecture for migrating data from Amazon S3 to Azure Blob Storage especially for SAP, RISE, and HANA modernization scenarios. By extending Azure’s control plane into AWS, Arc enables authenticated discovery of S3 buckets while Storage Mover orchestrates high‑throughput, policy‑driven data movement using defined source and target endpoints. With support for large object counts, telemetry, and sync capabilities, the solution ensures operational visibility and data integrity throughout the migration lifecycle. Once transferred, data lands in Azure Blob Storage, ready to integrate with SAP HANA, SAP Data Intelligence, SAP S/4HANA, BW/4HANA, and Azure-native analytics and AI services, establishing a high‑performance foundation for SAP workloads in the cloud.

Reference links:

Comparing Open-Source vs Closed LLMs for Enterprise Apps

ashishmahajan — Wed, 14 Jan 2026 18:52:02 GMT

Quiz

Let me start with a quick two‑question quiz to test your knowledge on Open‑Source LLMs vs Closed LLMs. The answers are provided at the end of this blog *.

1) Which category do GPT‑4, Claude, and Gemini LLMs fall under?

Open‑source models
Research only models
Closed / proprietary models
Edge only models

2) Which is a defining trait of open‑source LLMs?

Always hosted by hyperscalers
Full access to model weights and architecture
Higher accuracy than closed models
Built‑in enterprise support

Overview Of LLMs In Enterprise Context

LLMs are advanced AI models trained in vast data. They enable tasks such as summarization, translation, content creation, and data analysis.

When companies build applications that use AI, one of the most important decisions they face is choosing the right type of Large Language Model (LLM). There are two main choices: open‑source LLMs and closed or proprietary LLMs. Understanding the differences between them helps businesses decide which option fits their needs, goals, and security requirements.

Open‑source LLMs are models whose code and architecture are publicly available. This means companies can customize them, host them on Cloud or on-premises, and control how the data is handled. They offer flexibility and transparency, but they also require more technical skills and resources to manage.

Typical Enterprise Use Cases: Enterprises (including our customers) utilize LLMs across multiple domains to drive innovation and efficiency.

Some examples of where customers might use LLMs include chatbots, virtual assistants, code generation, document processing, knowledge management, market research, sentiment analysis, sales enablement, resume screening, incident root cause analysis, and financial fraud detection using narrative pattern analysis.

Key Considerations for LLM Adoption: Data privacy, security compliance, fine-tuning options for domain specific data, integration with existing enterprise systems, total cost of ownership, model accuracy & bias mitigation, resource requirements.

Types: Open-Source vs Closed LLMs

Open-Source LLMs: Open‑source Large Language Models (LLMs) are AI models whose model weights, architecture, and often training code are publicly available, allowing organizations to inspect, modify, fine‑tune, and deploy the models on their own infrastructure (cloud, on‑premises, or hybrid). Unlike proprietary models, open‑source LLMs give enterprises full control over how the model is hosted, secured, customized, and governed, but also place greater responsibility on the organization for operations, compliance, and lifecycle management.

They are also called open-weights.

Closed LLMs: Closed (Proprietary) Large Language Models (LLMs) are AI models whose architecture, training data, and model weights are not publicly available and are owned, hosted, and managed by a vendor. Enterprises consume these models via managed services or APIs, with the vendor responsible for infrastructure, scaling, security controls, and ongoing model updates. Organizations can use and configure these models but cannot inspect or modify the core model internals.

Comparative Analysis

	Open-Source LLMs	Closed (Proprietary) LLMs
Examples	• Meta (Facebook) - LlaMA 3, LlaMA 4 • Mistral AI - Devstral 2, Devstral Small 2, Mistral Large 3 • Alibaba - Qwen • Databricks - DBRX	• Microsoft - Azure OpenAI models • Open AI - GPT-4o, GPT-4 • Google – main Gemini models • Anthropic - Claude Sonnet 4.5, Claude Haiku 4.5, Claude Opus 4.5
Hosting / Deployment	Customer managed (Cloud/On prem). Runs on customer managed GPUs.	Vendor managed (mostly Cloud). API based or managed platform.
Model Access	Full access to weights	No access to internals
Customization	Full fine‑tuning	Prompt Engineering, RAG, Limited fine‑tuning
Operational Overhead	High	Low
Security / Governance	Customer responsible for Data Security and Model Governance	Built in Security, Guardrails, and Privacy Controls
Reliability & Performance	Requires strong AI maturity. Generally, no built in SLAs.	Preferred for regulated industries. Consistent performance and SLAs. Designed for production workloads at scale.
Support	Community driven support, Self managed operations	Vendor backed enterprise support, continuous updates, continuous updates, integrated troubleshooting
Incident Management	Internal teams	Vendor escalation paths
Cost implications and licensing models	No license fee. Costs include GPUs / compute, ML Engineering, Operations & Security.	Usage based pricing (Tokens / API calls). Predictable Cost and Lower Operational Burden.
Scalability, flexibility, and ease of integration	Scalability is customer managed and requires additional operational maturity. Integrates well with private data platforms but requires effort upfront.	Elastic, on demand scaling handled by vendor. Automatically handles Burst traffic, Global availability and Load balancing and failover. Fastest integration path with Plug and play APIs.

Demo

Internals of the Llama 3 model on Google Colab using Hugging Face Transformers library & Python code: Later, I plan to try something similar on the Azure platform using Microsoft Foundry. For this demo, I chose to use completely open‑source platforms.

This was done for two main reasons:

My goal was to show how easy it is to explore and interact with the open‑source Llama3 model without relying on any proprietary tools. By using openly available frameworks and environments, the entire workflow remains transparent, customizable, and accessible to anyone who wants to learn, experiment, or build with Llama 3 (or any open-source LLM) in a fully open ecosystem.

My other reason was to highlight open‑source tools and processes especially since these topics may come as talking points in customer conversations.

AI Tools Used:

Llama 3: Llama 3 is Meta's advanced, open-source family of Large Language Models (LLMs), offering reasoning, coding, and instruction-following capabilities for AI applications like Meta AI (on Facebook, Instagram, etc.), providing tools for developers. It comes in various sizes (8B, 70B, and larger) and versions (base and instruction-tuned).

Hugging Face: Hugging Face is a open‑source AI and machine learning platform used by developers, researchers, and enterprises to build, share, and deploy AI models. It is often described as the “GitHub of Machine Learning”, because it hosts millions of models, datasets, and applications in a collaborative community environment.

Hugging Face Transformers: Hugging Face Transformers is an open-source Python library that provides APIs and tools to access and use pre-trained machine learning models. It simplifies the application of complex AI models for tasks across various domains, including natural language processing (NLP), computer vision, and audio processing.

Google Colab: This is a free, cloud-based platform. It allows users to write and run Python code in a Jupyter Notebook environment through a web browser.

Jupyter Notebook: Jupyter Notebook is an open-source, web-based application for creating and sharing documents with live code, equations, visualizations, and narrative text. It is used for data cleaning, scientific computing, machine learning, and data exploration. It allows users to combine code execution (in Python, R, Julia, etc.) with rich text and output (like charts and images) in one interactive document, facilitating reproducible research and storytelling with data.

Python: Python is a high level‑, interpreted programming language known for its simple, readable syntax and wide range of uses in web development, data science, AI, automation, and more.

The Python code will examine the internals of the Llama 3 model on Google Colab, using Hugging Face and Python code. The Hugging Face Transformers library is used to load the model and inspect its configuration and architecture:

Step-1: Get access to the Llama 3 model on Hugging Face (e.g., meta-llama/Meta-Llama-3-8B).

Step-2: Generate a Hugging Face API Token with "read" or "write" permissions. Configure Hugging Face Access Token in Google Colab Environment.

Step-3: In Google Colab, create a Jupyter Notebook and write Python code for the following tasks (code in following section):

o Install Libraries: Install the necessary Python packages.

o Retrieve the token from Colab secrets.

o The Python script first loads the model’s configuration, then loads the model itself to examine its architecture and inspect its layers.

The screenshot from Google Colab environment:

Jupyter Notebook Python Code

Get access to the Llama 3 model on Hugging Face (e.g., meta-llama/Meta-Llama-3-8B). Install Libraries: Install the necessary Python packages.

!pip install transformers torch accelerate bitsandbytes

Generate a Hugging Face API token with "read" or “write” permissions

#!huggingface-cli login

from google.colab import userdata

from huggingface_hub import login

# Retrieve the token from Colab secrets

TokenAllAccessWrite = userdata.get('TokenAllAccessWrite')

# Log in to Hugging Face

if TokenAllAccessWrite:

login(TokenAllAccessWrite)

print("Successfully logged in to Hugging Face!")

else:

print("TokenAllAccessWrite not found in Colab secrets.")

Python Code to Inspect Llama 3 Internals. The following Python script loads the model's configuration and then the model itself, allowing you to print the architecture and inspect its layers.

# 1. Inspect the model configuration

# The config object contains hyperparameters defining the architecture (e.g., number of layers, hidden size, attention heads)

print(f"--- Loading Configuration for {model_id} ---")

config = AutoConfig.from_pretrained(model_id, token=True) # Use token=True if HF_TOKEN env var is set

print(config)

print("\n--- Key Architectural Details from Config ---")

print(f"Vocab size: {config.vocab_size}")

print(f"Hidden size: {config.hidden_size}")

print(f"Number of attention heads: {config.num_attention_heads}")

print(f"Number of hidden layers (Transformer blocks): {config.num_hidden_layers}")

print(f"Max position embeddings (Context length): {config.max_position_embeddings}")

print(f"Grouped Query Attention (GQA) num_key_value_heads: {config.num_key_value_heads}") # Llama 3 uses GQA

# 2. Load the actual model and inspect its structure

# This will download the model weights (approx. 16GB for 8B model) and cache them

# device_map="auto" efficiently loads the model across available resources (GPU/CPU)

print(f"\n--- Loading Model {model_id} to Inspect Architecture ---")

try:

model = AutoModelForCausalLM.from_pretrained(

model_id,

device_map="auto",

torch_dtype=torch.bfloat16, # Llama 3 trained in bfloat16

token=True

)

print("\n--- Model Architecture (pytorch modules) ---")

print(model)

# You can access specific layers, e.g., the first decoder layer

first_decoder_layer = model.model.layers[0]

print("\n--- Details of the First Decoder Layer ---")

print(first_decoder_layer)

except Exception as e:

print(f"\nAn error occurred: {e}")

print("Ensure you have requested access on Hugging Face and your token is set correctly.")

Conclusion

Decision-Making Considerations for Enterprises: Choosing the right LLM depends on enterprise goals, constraints and technical needs.

Careful evaluation of cost, scalability, security, and long-term sustainability will guide the decision towards Open-Source vs Closed LLMs.

Enterprises must weigh the benefits of open-source LLMs: Control, Autonomy, Customizable, Strong community support.

Enterprises must weigh the benefits of closed (proprietary) LLMs: Speed, High performance, Integrated services, Reliability, Governance.

Reference Links / Recommended Reading

Azure OpenAI in Foundry Models: https://azure.microsoft.com/en-us/products/ai-foundry/models/openai/

Hugging Face: https://huggingface.co/

Hugging Face Transformers:

https://huggingface.co/docs/transformers/en/index

https://github.com/huggingface/transformers

Google Colab: https://colab.research.google.com/

Llama 3: https://www.llama.com/models/llama-3/

Jupyter Notebook: https://jupyter.org/

Python: https://www.python.org/

* Quiz: The correct answers are option C for question 1 and option B for question 2.

Migration from SAP ERP On-Premises to SAP S/4HANA in Microsoft Azure

AnuradhaKarnam — Mon, 22 Dec 2025 21:00:39 GMT

This describes the tool guided migration of an on-premises SAP ERP system into Microsoft Azure, combined with a system conversion to SAP S/4HANA. The Software Update Manager (SUM) acts as the technical engine for the conversion. I will also explain how the SAP Cloud Appliance Library streamlines this process through a step-by-step approach.

In general, there are three primary paths for migrating to SAP S/4HANA:

Selective Data Transition
New Implementation
SAP S/4HANA System Conversion

1.System Conversion

It will break down into the Preparation Phase and Realization Phase.

Preparation Phase

System Requirements

This phase ensures that the current SAP ECC system, infrastructure, database, and operating system meet the minimum prerequisites for a conversion to SAP S/4HANA.
Key activities include:

Verifying supported OS, DB, and Unicode requirements

Checking add-ons and thirdparty components

Confirming hardware capacity (CPU, RAM, storage)

Assessing source release compatibility for SUM execution

This step forms the technical foundation before any planning can begin.

Maintenance Planner

SAP Maintenance Planner validates and prepares the system stack for conversion.
It checks:

Active add-ons and their compatibility

Installed components and required upgrade paths

Target SAP S/4HANA release stack

Required XML file generation for SUM

Outcome: A stack XML file used by SUM to guide the technical conversion.

Simplification Item Check (SICheck)

SICheck analyzes the ECC system for mandatory functional and technical changes required by SAP S/4HANA.
This includes:

Identifying simplification items (Example: Finance, Logistics, master data changes)

Highlighting inconsistencies in custom or standard objects

Showing mandatory actions before conversion (Example: Customer Vendor Integration (CVI) for Business Partner (BP), Open Item Management updates)

This provides a detailed “to-do list” to bring the system into an S/4HANAcompliant state.

Custom Code Preparation

This phase ensures that custom developments (Zprograms, enhancements, exits) will work on the S/4HANA environment.
Activities include:

Running ABAP Test Cockpit (ATC) checks

Identifying usage-based custom code via SAP Readiness Check / UPL

Adapting code for removed or deprecated data structures (Example: MATDOC, tables replaced in S/4HANA)

Planning remediation for performance or syntax changes

This ensures custom code does not break after conversion.

Realization Phase

Software Update Manager (SUM)

The Software Update Manager serves as the technical engine for system conversion.
It performs:

Database migration to SAP HANA

Software component upgrade to S/4HANA

Data conversion and migration

Technical downtime execution

Post-processing of the system landscape

SUM combines upgrade, migration, and conversion into one guided procedure. You can perform the conversion using the in-place option, allowing the existing SAP ECC system to remain on-premises. Alternatively, you can combine the move with a transition to a hyperscaler, an approach that becomes particularly powerful in the context of RISE with SAP.

RISE with SAP provides a comprehensive, modular cloud transformation offering that bundles software, infrastructure, and managed services into a single contract. It enables organizations to modernize their SAP landscape by running SAP S/4HANA in a hyperscaler environment (such as Microsoft Azure) while SAP takes responsibility for technical operations at the application layer. This includes lifecycle management, technical monitoring, SLA-backed operations, security patching, and upgrading orchestration. RISE also supports business transformation through embedded tools, extensibility options, and continuous innovation.

By integrating your system conversion with RISE with SAP, you can streamline the journey to S/4HANA, reduce operational overhead, shift from CAPEX (Capital Expenditure) to OPEX (Operational Expenditure), and accelerate innovation using cloud-scale capabilities while SUM delivers the technical conversion engine underneath.

Application-Specific Follow-Up Activities

After the technical conversion, functional teams’ complete configuration and validation tasks specific to their modules.
Example:

Finance: Activation of Universal Journal, data reconciliation, asset accounting migration

Logistics: Credit management migration, new ATP setup

Security: Role and authorization adjustments

SAP Basis and ABAP team: Fiori activation and launchpad configurations

Techno functional: Business validation and testing

SAP Basis: Cutover activities and golive preparation

These steps ensure that the converted system is functional, optimized, and ready for productive use.

Summary View:

Phase	Step	Purpose
Preparation	System Requirements	Ensure technical foundation is ready
	Maintenance Planner	Validate system stack & generate XML
	SICheck	Identify required functional simplifications
	Custom Code Preparation	Analyze & adapt custom developments
Realization	Software Update Manager	Perform technical upgrade & data conversion
	Application Follow-up	Complete module-specific configuration & validation

New implementation:

New Implementation with DMO (Database Migration Option)

A New Implementation (Greenfield approach) means building a completely new SAP S/4HANA system and migrating selected data into it.

How DMO fits in:

DMO is not used on the new S/4HANA system itself, instead it is used on the source ECC system when needed to support the transition process.

You would use DMO when you want to:

Upgrade and/or migrate the old ECC system to the SAP HANA database temporarily

Enable smoother extraction of data using SAP Migration Cockpit or 3rdparty ETL tools

Prepare the source system technically and functionally before data migration to the new S/4HANA system

DMO prepares the old system, but the final target is a clean, newly installed S/4HANA instance.

We have two options when using the Software Update Manager (SUM):

DMO with System Move:
In this scenario, SUM begins the procedure on the source system and then continues execution on the target system. This is typically used when migrating to a new host or infrastructure while performing the upgrade and database migration in one combined process.

DMO Migration Option – Move to SAP S/4HANA on a Hyperscaler (DMOVE2S4):
Here, SUM starts an additional application server that runs in the target environment but still belongs to the source system landscape. This enables a controlled transition to a hyperscaler environment (such as Azure) while completing the conversion and migration steps required for SAP S/4HANA.

In both cases, several preparatory tasks must be completed in the target environment, such as:

Selective Data Transition (SDT) with DMO:

Selective Data Transition is a hybrid approach between Brownfield and Greenfield.
It allows moving only the data you choose, such as:

Specific company codes

Selected historical periods

Organizational carveouts

M&A (Merger and acquisition) landscape consolidation

How DMO fits in:

DMO is typically used as the first step in preparing the source ECC system.

It migrates the source ECC system to SAP HANA

Performs required technical upgrades

Ensures compatibility with the S/4HANA data model

Prepares system objects so that selective extraction tools (SNP, Natuvion, CBS, etc.) can run

After DMO, partner tools extract selected data into the target S/4HANA system. DMO modernizes and upgrades the source system, enabling selective extraction and migration.

Target Environment Preparation Tasks (for DMO with System Move & DMOVE2S4)

Before SUM can execute migration steps in the target environment, several technical preparations must be completed. These ensure that the new infrastructure (IaaS, or hyperscaler) is fully ready for the handover from the source system.

Provisioning the Target Infrastructure

You must set up a clean, properly sized environment that will serve as the new application host or target system. This includes:

Creating virtual machines or hosts (on hyperscaler)

Ensuring CPU, RAM, and storage meet SAP sizing guidelines

Preparing appropriate disk layout for /usr/sap, /sapmnt, /hana/shared, and log/data volumes (for HANA scenarios)

Operating System Preparation

The OS must meet SAP and SUM prerequisites:

Install a certified OS version (Example: RHEL, SLES, Windows if applicable)

Apply required OS patches and kernel versions

Configure OS locales, time synchronization, and system limits (ulimits, transparent huge pages, UUID config)

Create SAP system users (Example: <sid>adm, sidadm, sapadm) if not automatically provisioned

Network and Connectivity Setup

DMO requires bidirectional connectivity between source and target systems:

Open required TCP ports (e.g., DIAG, RFC, HANA SQL ports, SAP Host Agent ports)

Validate hostname resolution using DNS or /etc/hosts

Set up VPN, ExpressRoute, or Peering if migrating to a hyperscaler

Ensure no restrictive firewalls block SUM or SAP Host Agent communication

SAP Host Agent Installation

SUM requires a functional Host Agent on the target system:

Install SAP Host Agent (latest version recommended)

Configure Host Agent service user and permissions

Validate connectivity from source to target Host Agent

File System Preparation

Depending on your architecture:

Set up NFS shares for /sapmnt (if shared in distributed system environments)

Prepare directories for SUM extraction and temporary files

Ensure proper ownership and permissions: sidadm:sapsys

Database Preparation

For HANA-based targets:

Provision SAP HANA DB following sizing guidelines

Configure data and log volumes with recommended I/O throughput

Install the correct HANA version compatible with your SUM stack

Validate HANA OS parameters (vm.dirty_background_ratio, thp, huge pages)

Ensure network configuration supports SAP HANA replication if needed

Software Staging and Media Preparation

For SUM to continue the target:

Download and stage SAP software media (kernel, stack files, SAP HANA installation media, archives)

Ensure directories are accessible to SUM during the handover phase

Upload SUM SAR files and extract them on the target host if required by your scenario

Security and User Setup

Depending on your landscape:

Configure secure shell (SSH) trust between source and target (for SUM)

Set up service users and groups (sapsys, <sid>adm)

Validate OS-level sudo rules if needed for certain scripts or root actions

Parameter Alignment Between Source & Target

To ensure SUM can continue seamlessly:

Synchronize system parameters (Example: time zone, code page, locale)

Ensure consistent SAP profiles (DEFAULT.PFL, instance profiles)

Confirm kernel patch levels where required

Storage & Backup Preparation

Before running SUM:

Configure snapshot policies if supported by your hyperscaler

Ensure backup tools or agents are installed (Azure Backup, thirdparty agents)

Validate I/O throughput to avoid SUM performance bottlenecks during migration

Validation & Health Checks

Before starting SUM:

Run OS validation scripts provided by SAP

Test Host Agent connectivity from the source system

Confirm network speed between source ↔ target meets SAP minimum requirements

Validate free disk space for SUM logs, dumps, and temporary directories

Summary Comparison

Approach	Target System	Role of DMO	When to Use
New Implementation	Brandnew S/4HANA installation	Prepares source ECC (HANA migration + upgrade) before extracting data	Modernization, redesign, bestpractice adoption
Selective Data Transition	Part-new, part-reused S/4HANA system	Prepares source ECC (technical readiness for selective extraction)	Carveouts, mergers, consolidations, partial history moves

System Conversion – Data Migration Option to Microsoft Azure:

The diagram illustrates a coordinated, tool driven, end-to-end migration path where:

The Customer sets direction and validates outcomes

Maintenance Planner creates a certified conversion plan

SAP CAL automatically provisions the Azure target landscape

SUM executes all technical conversion and database migration steps

Together, these components create a standardized, repeatable, and automated path to move from SAP ERP on-premises to SAP S/4HANA on Microsoft Azure.

Conclusion:

The Database Migration Option (DMO) of the Software Update Manager provides a powerful and flexible framework for transitioning SAP systems to SAP S/4HANA whether through a classic system conversion, a new implementation scenario, or a selective data transition approach. Both DMO with System Move and DMOVE2S4 extend these capabilities by enabling migrations to new infrastructure or hyperscale environments while maintaining a controlled, SAP supported technical procedure.

Regardless of which DMO scenario is selected, success hinges thoroughly preparing the target environment. Proper provisioning of infrastructure, operating system configuration, network readiness, SAP Host Agent installation, file system setup, software staging, and security alignment ensure a smooth and stable handover from source to target. These preparation activities minimize technical risk, reduce downtime, and enable SUM to execute migration and conversion with high reliability.

By combining SAP’s proven migration tooling with a well-prepared target landscape, organizations can confidently modernize their SAP footprint, leverage hyperscale scalability, and move toward a future ready SAP S/4HANA platform aligned with cloud transformation strategies.

Reference links:

SUM & DMO on SAP Help Portal: Software Update Manager | SAP Help Portal

SAP Note 2377305 – DMO: Database Migration Option: https://me.sap.com/notes/2377305

SAP Readiness Check: Integration Between SAP Readiness Check and SAP Cloud ALM | SAP Help Portal

SAP CAL Homepage: https://cal.sap.com/

RISE with SAP Overview: RISE with SAP | Transformation journey to SAP Business Suite

RISE with SAP S/4HANA Cloud documentation: https://help.sap.com/docs/RISE_WITH_SAP
SAP on Azure migration: SAP on Azure Migration – SAP Intelligent Enterprise | Microsoft Azure

Preparing for Azure PostgreSQL Certificate Authority Rotation: A Comprehensive Operational Guide

AndreasSemmelmann — Mon, 15 Dec 2025 18:55:36 GMT

The Challenge

It started with a standard notification in the Azure Portal: Tracking-ID YK3N-7RZ. A routine Certificate Authority (CA) rotation for Azure Database for PostgreSQL.

As Cloud Solution Architects, we’ve seen this scenario play out many times. The moment “certificate rotation” is mentioned, a wave of unease ripples through engineering teams. Let’s be honest: for many of us—ourselves included—certificates represent the edge of our technical “comfort zone.” We know they are critical for security, but the complexity of PKI chains, trust stores, and SSL handshakes can be intimidating. There is a silent fear: “If we touch this, will we break production?”

We realized we had a choice. We could treat this as an opportunity, and we could leave that comfort zone.

We approached our customer with a proactive proposal: Let’s use this event to stop fearing certificates and start mastering them. Instead of just patching the immediate issue, we used this rotation as a catalyst to review and upgrade the security posture of their database connections. We wanted to move from “hoping it works” to “knowing it’s secure.”

The response was overwhelmingly positive. The teams didn’t just want a quick fix; they wanted “help for self-help.” They wanted to understand the mechanics behind sslmode and build the confidence to manage trust stores proactively.

This guide is the result of that journey. It is designed to help you navigate the upcoming rotation not with anxiety, but with competence—turning a mandatory maintenance window into a permanent security improvement.

Two Levels of Analysis

A certificate rotation affects your environment on two distinct levels, requiring different expertise and actions:

Level	Responsibility	Key Questions	Actions
Platform Level	Cloud/Platform Teams	Which clusters, services, and namespaces are affected? How do we detect at scale?	Azure Service Health monitoring, AKS scanning, infrastructure-wide assessment
Application Level	Application/Dev Teams	What SSL mode? Which trust store? How to update connection strings?	Code changes, dependency updates, trust store management

This article addresses both levels - providing platform-wide detection strategies (Section 5) and application-specific remediation guidance (Platform-Specific Remediation).

Business Impact: In production environments, certificate validation failures cause complete database connection outages. A single missed certificate rotation has caused hours of downtime for enterprise customers, impacting revenue and customer trust.

Who’s Affected: DevOps engineers, SREs, database administrators, and platform engineers managing Azure PostgreSQL instances - especially those using: - Java applications with custom JRE cacerts - Containerized workloads with baked-in trust stores - Strict SSL modes (sslmode=verify-full, verify-ca)

The Solution

What we’ll cover:

🛡️ Reliability: How to prevent database connection outages through proactive certificate management

🔄 Resiliency: Automation strategies that ensure your trust stores stay current

🔒 Security: Maintaining TLS security posture while rotating certificates safely

Key Takeaway:

This rotation is a client trust topic, not a server change. Applications trusting root CAs (DigiCert Global Root G2, Microsoft RSA Root CA 2017) without intermediate pinning are unaffected. Risk concentrates where strict validation meets custom trust stores.

📦 Platform-Specific Implementation: Detailed remediation guides for Java, .NET, Python, Node.js, and Kubernetes are available in our GitHub Repository.

Note: The GitHub Repository. contains community-contributed content provided as-is. Test all scripts in non-production environments before use.

1. Understanding Certificate Authority Rotation

What Changes During CA Rotation?

Azure Database for PostgreSQL uses TLS/SSL to encrypt client-server connections. The database server presents a certificate chain during the TLS handshake:

Certificate Chain Structure:

Figure: Certificate chain structure showing the rotation from old intermediate (red, deprecated) to new intermediate (blue, active after rotation). Client applications must trust the root certificates (green) to validate the chain.

📝 Diagram Source: The Mermaid source code for this diagram is available in certificate-chain-diagram.mmd.

Why Root Trust Matters

Key Principle: If your application trusts the root certificate and allows the chain to be validated dynamically, you are not affected. The risk occurs when:

Custom trust stores contain only the old intermediate certificate (not the root)
Certificate pinning is implemented at the intermediate level
Strict validation is enabled (sslmode=verify-full in PostgreSQL connection strings)

2. Who Is Affected and Why

Risk Assessment Matrix

Application Type	Trust Store	SSL Mode	Risk Level	Action Required
Cloud-native app (Azure SDK)	OS Trust Store	require	🟢 Low	None - Azure SDK handles automatically
Java app (default JRE)	System cacerts	verify-ca	🟡 Medium	Verify JRE version (11.0.16+, 17.0.4+, 8u381+)
Java app (custom cacerts)	Custom JKS file	verify-full	🔴 High	Update custom trust store with new intermediate
.NET app (Windows)	Windows Cert Store	require	🟢 Low	None - automatic via Windows Update
Python app (certifi)	certifi bundle	verify-ca	🟡 Medium	Update certifi package (pip install --upgrade certifi)
Node.js app (default)	Built-in CAs	verify-ca	🟢 Low	None - Node.js 16+, 18+, 20+ auto-updated
Container (Alpine)	/etc/ssl/certs	verify-full	🔴 High	Update base image or install ca-certificates-bundle
Container (custom)	Baked-in certs	verify-full	🔴 High	Rebuild image with updated trust store

How to Read This Matrix

Use the above matrix to quickly assess whether your applications are affected by CA rotation. Here is an overview, how you read the matrix:

Column	Meaning
Application Type	What kind of application do you have? (e.g., Java, .NET, Container)
Trust Store	Where does the application store its trusted certificates?
SSL Mode	How strictly does the application validate the server certificate?
Risk Level	🟢 Low / 🟡 Medium / 🔴 High - How likely is a connection failure?
Action Required	What specific action do you need to take?

Risk Level Logic:

Risk Level	Why?
🟢 Low	Automatic updates (OS/Azure SDK) or no certificate validation
🟡 Medium	Manual update required but straightforward (e.g., pip install --upgrade certifi)
🔴 High	Custom trust store must be manually updated - highest outage risk

SSL Mode Security Posture

Understanding SSL modes is critical because they determine both security posture AND rotation impact. This creates a dual consideration:

SSL Mode	Certificate Validation	Rotation Impact	Security Level	Recommendation
disable	❌ None	✅ No impact	🔴 INSECURE	Never use in production
allow	❌ None	✅ No impact	🟠 WEAK	Not recommended
prefer	❌ Optional	✅ Minimal	🟡 WEAK	Not recommended
require	❌ No (Npgsql 6.0+)	✅ No impact	🟡 WEAK	Upgrade to verify-full
verify-ca	✅ Chain only	🔴 Critical	🔵 MODERATE	Update trust stores
verify-full	✅ Chain + hostname	🔴 Critical	🟢 SECURE	Recommended - Update trust stores

Key Insight: Applications using weak SSL modes (everything below verify-ca) are technically unaffected by CA rotation but represent security vulnerabilities. The safest path is verify-full with current trust stores.

⚖️ The Security vs. Resilience Trade-off

The Paradox: Secure applications (verify-full) have the highest rotation risk 🔴, while insecure applications (require) are unaffected but have security gaps.

Teams discovering weak SSL modes during rotation preparation face a critical decision:

Option	Approach	Rotation Impact	Security Impact	Recommended For
🚀 Quick Fix	Keep weak SSL mode (require)	✅ No action needed	⚠️ Security debt remains	Emergency situations only
🛡️ Proper Fix	Upgrade to verify-full	🔴 Requires trust store updates	✅ Improved security posture	All production systems

Our Recommendation: Use CA rotation events as an opportunity to improve your security posture. The effort to update trust stores is a one-time investment that pays off in long-term security.

Common Scenarios

Scenario 1: Enterprise Java Application

Problem: Custom trust store created 2+ years ago for PCI compliance
Risk: High - contains only old intermediate certificates
Solution: Export new intermediate from Azure, import to custom cacerts

Scenario 2: Kubernetes Microservices

Problem: Init container copies trust store from ConfigMap at startup
Risk: High - ConfigMap never updated since initial deployment
Solution: Update ConfigMap, redeploy pods with new trust store

Scenario 3: Legacy .NET Application

Problem: .NET Framework 4.6 on Windows Server 2016 (no Windows Update)
Risk: Medium - depends on manual certificate store updates
Solution: Import new intermediate to Windows Certificate Store manually

3. Trust Store Overview

A trust store is the collection of root and intermediate CA certificates that your application uses to validate server certificates during TLS handshakes. Understanding where your application’s trust store is located determines how you’ll update it for CA rotations.

Trust Store Locations by Platform

Category	Platform	Trust Store Location	Update Method	Auto-Updated?
OS Level	Windows	Cert:\LocalMachine\Root	Windows Update	✅ Yes
	Debian/Ubuntu	/etc/ssl/certs/ca-certificates.crt	apt upgrade ca-certificates	✅ Yes (with updates)
	Red Hat/CentOS	/etc/pki/tls/certs/ca-bundle.crt	yum update ca-certificates	✅ Yes (with updates)
Runtime Level	Java JRE	$JAVA_HOME/lib/security/cacerts	Java security updates	✅ With JRE updates
	Python (certifi)	site-packages/certifi/cacert.pem	pip install --upgrade certifi	❌ Manual
	Node.js	Bundled with runtime	Node.js version upgrade	✅ With Node.js updates
Custom	Custom JKS	Application-specific path	keytool -importcert	❌ Manual
	Container image	/etc/ssl/certs (baked-in)	Rebuild container image	❌ Manual
	ConfigMap mount	Kubernetes ConfigMap	Update ConfigMap, redeploy	❌ Manual

Why This Matters for CA Rotation

Applications using auto-updated trust stores (OS-managed, current runtime versions) generally handle CA rotations automatically. The risk concentrates in:

Custom trust stores created for compliance requirements (PCI-DSS, SOC 2) that are rarely updated
Baked-in container certificates from images built months or years ago
Outdated runtimes (old JRE versions, frozen Python environments) that haven’t received security updates
Air-gapped environments where automatic updates are disabled

When planning for CA rotation, focus your assessment efforts on applications in the “Manual” update category.

4. Platform-Specific Remediation

📦 Detailed implementation guides are available in our GitHub repository:

azure-certificate-rotation-guide

Quick Reference: Remediation by Platform

Platform	Trust Store Location	Update Method	Guide
Java	$JAVA_HOME/lib/security/cacerts	Update JRE or manual keytool import	java-cacerts.md
.NET (Windows)	Windows Certificate Store	Windows Update (automatic)	dotnet-windows.md
Python	certifi package	pip install --upgrade certifi	python-certifi.md
Node.js	Built-in CA bundle	Update Node.js version	nodejs.md
Containers	Base image /etc/ssl/certs	Rebuild image or ConfigMap	containers-kubernetes.md

Scripts & Automation

Script	Purpose	Download	State
Scan-AKS-TrustStores.ps1	Scan all pods in AKS for trust store configurations	PowerShell	tested
validate-connection.sh	Test PostgreSQL connection with SSL validation	Bash	not tested
update-cacerts.sh	Update Java cacerts with new intermediate	Bash	not tested

5. Proactive Detection Strategies

Database-Level Discovery: Identifying Connected Clients

One starting point for impact assessment is querying the PostgreSQL database itself to identify which applications are connecting. We developed a SQL query that joins pg_stat_ssl with pg_stat_activity to reveal active TLS connections, their SSL version, and cipher suites.

🔍 Get the SQL Query: Download the complete detection script from our GitHub repository: detect-clients.sql

Important Limitations

This query has significant constraints that you must understand before relying on it for CA rotation planning:

Limitation	Impact	Mitigation
Point-in-time snapshot	Only shows currently connected clients	Run query repeatedly over days/weeks to capture periodic jobs and batch processes
No certificate details	Cannot identify which CA certificate the client is using	Requires client-side investigation (trust store analysis)
Connection pooling	May show pooler instead of actual application	Use application_name in connection strings to identify true source
Idle connections	Long-running connections may be dormant	Cross-reference with application activity logs

Recommended approach: Use this query to create an initial inventory, then investigate each unique application_name and client_addr combination to determine their trust store configuration and SSL mode.

Proactive Monitoring with Azure Monitor

To detect certificate-related issues before and after CA rotation, configure Azure Monitor alerts. This enables early warning when SSL handshakes start failing.

Why this matters: After CA rotation, applications with outdated trust stores will fail to connect. An alert allows you to detect affected applications quickly rather than waiting for user reports.

Official Documentation: For complete guidance on creating and managing alerts, see Azure Monitor Alerts Overview and Create a Log Search Alert.

Here is a short example of an Azure Monitor Alert definition as a starting point.

{ "alertRule": { "name": "PostgreSQL SSL Connection Failures", "severity": 2, "condition": { "query": "AzureDiagnostics | where ResourceType == 'SERVERS' and Category == 'PostgreSQLLogs' and Message contains 'SSL error' | summarize count() by bin(TimeGenerated, 5m)", "threshold": 5, "timeAggregation": "Total", "windowSize": "PT5M" } } }

Alert Configuration Notes:

Setting	Recommended Value	Rationale
Severity	2 (Warning)	Allows investigation without triggering critical incident response
Threshold	5 failures/5min	Filters noise while catching genuine issues
Evaluation Period	5 minutes	Balances responsiveness with alert fatigue
Action Group	Platform Team	Ensures quick triage and coordination

6. Production Validation

Pre-Rotation Validation Checklist

Inventory all applications connecting to Azure PostgreSQL
Identify trust store locations for each application
Verify root certificate presence in trust stores
Test connection with new intermediate in non-production environment
Update monitoring alerts for SSL connection failures
Prepare rollback plan if issues occur
Schedule maintenance window (if required)
Notify stakeholders of potential impact

Testing Procedure

We established a systematic 3-step validation process to ensure zero downtime. This approach moves from isolated testing to gradual production rollout.

🧪 Technical Validation Guide: For the complete list of psql commands, connection string examples for Windows/Linux, and automated testing scripts, please refer to our Validation Guide in the GitHub repository.

Connection Testing Strategy

The core of our validation strategy was testing connections with explicit sslmode settings. We used the psql command-line tool to simulate different client behaviors.

Test Scenario	Purpose	Expected Result
Encryption only (sslmode=require)	Verify basic connectivity	Connection succeeds even with unknown CA
CA validation (sslmode=verify-ca)	Verify trust store integrity	Connection succeeds only if CA chain is valid
Full validation (sslmode=verify-full)	Verify strict security compliance	Connection succeeds only if CA chain AND hostname match

Pro Tip: Test with verify-full and an explicit root CA file containing the new Microsoft/DigiCert root certificates before the rotation date. This validates that your trust stores will work after the intermediate certificate changes.

Step 1: Test in Non-Production

Validate connections against a test server using the new intermediate certificate (Azure provides test endpoints during the rotation window).

Step 2: Canary Deployment

Deploy the updated trust store to a single “canary” instance or pod. Monitor: - Connection success rate - Error logs - Response times

Step 3: Gradual Rollout

Once the canary is stable, proceed with a phased rollout: 1. Update 10% of pods 2. Monitor for 1 hour 3. Update 50% of pods 4. Monitor for 1 hour 5. Complete rollout

7. Best Practices and Lessons Learned

Certificate Management Best Practices

Practice	Guidance	Example
Trust Root CAs, Not Intermediates	Configure trust stores with root CA certificates only. This provides resilience against intermediate certificate rotations.	Trust Microsoft TLS RSA Root G2 and DigiCert Global Root G2 instead of specific intermediates
Automate Trust Store Updates	Use OS-provided trust stores when possible (automatically updated). For custom trust stores, implement CI/CD pipelines.	Schedule bi-annual trust store audits
Use SSL Mode Appropriately	Choose SSL mode based on security requirements. verify-ca is recommended for most scenarios.	See Security Posture Matrix in Section 2
Maintain Container Images	Rebuild container images monthly to include latest CA certificates. Use init containers for runtime updates.	Multi-stage builds with CA certificate update step
Avoid Certificate Pinning	Never pin intermediate certificates. If pinning is required for compliance, implement automated update processes.	Pin only root CA certificates if absolutely necessary

SSL Mode Decision Guide

SSL Mode	Security Level	Resilience	When to Use
require	Medium	High	Encrypted traffic without certificate validation. Use when CA rotation resilience is more important than MITM protection.
verify-ca	High	Medium	Validates certificate chain. Recommended for most production scenarios.
verify-full	Highest	Low	Strictest validation with hostname matching. Use only when compliance requires it.

Organizational Communication Model

Effective certificate rotation requires structured communication across multiple layers:

Layer	Responsibility	Key Action
Azure Service Health	Microsoft publishes announcements to affected subscriptions	Monitor Azure Service Health proactively
Platform/Cloud Team	Receives Azure announcements, triages criticality	Follow ITSM processes, assess impact
Application Teams	Execute application-level changes	Update trust stores, validate connections
Security Teams	Define certificate validation policies	Set compliance requirements

Ownership and Responsibility Matrix

Team	Responsibility	Deliverable
Platform/Cloud Team	Monitor Azure Service Health, coordinate response	Impact assessment, team notifications
Application Teams	Application-level changes (connection strings, trust stores)	Updated configurations, validation results
Security Teams	Define certificate policies, compliance requirements	Policy documentation, audit reports
All Teams (Shared)	Certificate lifecycle collaboration	Playbooks, escalation paths, training

Certificate Rotation Playbook Components

Organizations should establish documented playbooks including:

Component	Recommended Frequency	Purpose
Trust Store Audits	Bi-annual (every 6 months)	Ensure certificates are current
Certificate Inventory	Quarterly review	Know what certificates exist where
Playbook Updates	Annual or after incidents	Keep procedures current
Team Training	Annual	Build knowledge and confidence

Field Observations: Common Configuration Patterns

Pattern	Observation	Risk
Implicit SSL Mode	Teams don’t explicitly set sslmode, relying on framework defaults	Unexpected behavior during CA rotation
Copy-Paste Configurations	Connection strings copied without understanding options	Works until certificate changes expose gaps
Framework-Specific Defaults	Java uses JRE trust store, .NET uses Windows Certificate Store, Python depends on certifi package	Some require manual updates, some are automatic

Framework Trust Store Defaults

Framework	Default Trust Store	Update Method	Risk Level
Java/Quarkus	JRE cacerts	Manual or JRE update	Medium - requires awareness
.NET	Windows Certificate Store	Windows Update	Low - automatic
Node.js	Bundled certificates	Node.js version update	Low - automatic
Python	certifi package	pip install --upgrade certifi	High - manual intervention required

Knowledge and Confidence Challenges

Challenge	Impact	Mitigation
Limited certificate knowledge	Creates uncertainty and risk-averse behavior	Proactive education, hands-on workshops
Topic intimidation	“Certificates” can seem complex, leading to avoidance	Reality: Implementation is straightforward once understood
Previous negative experiences	Leadership concerns based on past incidents	Document successes, share lessons learned
Visibility gaps	Lack of visibility into application dependencies	Maintain certificate inventory, use discovery tools

Monitoring Strategy (Recommended for Post-Rotation):

While pre-rotation monitoring focuses on inventory, post-rotation monitoring should track:

Key Metrics: - Connection failure rates (group by application, SSL error types) - SSL handshake duration (detect performance degradation) - Certificate validation errors (track which certificates fail) - Application error logs (filter for “SSL”, “certificate”, “trust”)
Recommended Alerts: - Threshold: >5 SSL connection failures in 5 minutes - Anomaly detection: Connection failure rate increases >50% - Certificate expiry warnings: 30, 14, 7 days before expiration
Dashboard Components: - Connection success rate by application - SSL error distribution (validation failures, expired certificates, etc.) - Certificate inventory with expiry dates - Trust store update status across infrastructure

These metrics, alerts and thresholds are only starting points and need to be adjusted based on your environment and needs.

Post-Rotation Validation and Telemetry

Note: This article focuses on preparation for upcoming certificate rotations. Post-rotation metrics and incident data will be collected after the rotation completes and can inform future iterations of this guidance.

Recommended Post-Rotation Activities:

Here are some thoughts on post-rotation activities that could create more insights on the effectiveness of the preparation.

Incident Tracking:
After rotation completes, organizations should track: - Production incidents related to SSL/TLS connection failures - Services affected and their business criticality - Mean Time to Detection (MTTD) for certificate-related issues - Mean Time to Resolution (MTTR) from detection to fix
Success Metrics to Measure
1. Pre-Rotation Validation: - Number of services inventoried and assessed - Percentage of services requiring trust store updates - Testing coverage (dev, staging, production)
2. Post-Rotation Outcomes: - Zero-downtime success rate (percentage of services with no impact) - Applications requiring emergency patching - Time from rotation to full validation
Impact Assessment
Telemetry to Collect: - Total connection attempts vs. failures (before and after rotation) - Duration of any service degradation or outages - ustomer-facing impact (user-reported issues, support tickets) - Geographic or subscription-specific patterns
Continuous Improvement
1. Post-Rotation Review: - What worked well in the preparation phase? - Which teams or applications were unprepared? - What gaps exist in monitoring or alerting? - How can communication be improved for future rotations?
2. Documentation Updates: - Update playbooks with lessons learned - Refine monitoring queries based on observed patterns - Enhance team training materials - Share anonymized case studies across the organization

8. Engagement & Next Steps

Discussion Questions

We’d love to hear from the community:

What’s your experience with certificate rotations? Have you encountered unexpected connection failures during CA rotation events?
Which trust store update method works best for your environment? OS-managed, runtime-bundled, or custom trust stores?
How do you handle certificate management in air-gapped environments? What strategies have worked for your organization?

Share Your Experience

If you’ve implemented proactive certificate management strategies or have lessons learned from CA rotation incidents, we encourage you to:

Comment below with your experiences and tips
Contribute to the GitHub repository with additional platform guides or scripts
Connect with us on LinkedIn to continue the conversation

Call to Action

Take these steps now to prepare for the CA rotation:

Assess your applications - Use the Risk Assessment Matrix (Section 2) to identify which applications use sslmode=verify-ca or verify-full with custom trust stores
Import root CA certificates - Add DigiCert Global Root G2 and Microsoft RSA Root CA 2017 to your trust stores
Upgrade SSL mode - Change your connection strings to at least sslmode=verify-ca (recommended: verify-full) for improved security
Document your changes - Record which applications were updated, what trust stores were modified, and the validation results
Automate for the future - Implement proactive certificate management so future CA rotations are handled automatically (OS-managed trust stores, CI/CD pipelines for container images, scheduled trust store audits)

9. Resources

Official Documentation

Azure PostgreSQL:

PostgreSQL & libpq:

PostgreSQL libpq SSL Support - SSL mode options and environment variables
PostgreSQL psql Reference - Command-line tool documentation
PostgreSQL Server SSL/TLS Configuration

Certificate Authorities:

Community Resources

Tools and Scripts

Industry Context

Certificate rotation challenges are not unique to Azure PostgreSQL. Similar incidents have occurred across the industry:

Historical Incidents: - Let’s Encrypt Root Expiration (2021): Widespread impact when DST Root CA X3 expired, affecting older Android devices and legacy systems - DigiCert Root Transitions: Multiple cloud providers experienced customer impact during CA changes - Internal PKI Rotations: Enterprises face similar challenges when rotating internally-issued certificates

Relevant Standards: - NIST SP 800-57: Key Management Guidelines (certificate lifecycle best practices) - OWASP Certificate Pinning: Guidance on balancing security and operational resilience - CIS Benchmarks: Recommendations for TLS/SSL configuration in cloud environments

Authors

Author	Role	Contact
Andreas Semmelmann	Cloud Solution Architect, Microsoft	LinkedIn
Mpho Muthige	Cloud Solution Architect, Microsoft	LinkedIn

Disclaimers

Disclaimer:
The information in this blog post is provided for general informational purposes only and does not constitute legal, financial, or professional advice. While every effort has been made to ensure the accuracy of the information at the time of publication, Microsoft makes no warranties or representations as to its completeness or accuracy. Product features, availability, and timelines are subject to change without notice. For specific guidance, please consult your legal or compliance advisor.

Microsoft Support Statement:
This article represents field experiences and community best practices. For official Microsoft support and SLA-backed guidance:

Azure Support: https://azure.microsoft.com/support/
Official Documentation: https://learn.microsoft.com/azure/
Microsoft Q&A: https://learn.microsoft.com/answers/

Production Issues: Always open official support tickets for production-impacting problems.

Customer Privacy Notice:
This article describes real-world scenarios from customer engagements. All customer-specific information has been anonymized. No NDAs or customer confidentiality agreements were violated in creating this content.

AI-generated content disclaimer:
This content was generated in whole or in part with the assistance of AI tools. AI-generated content may be incorrect or incomplete. Please review and verify before relying on it for critical decisions. See terms

Community Contribution: The GitHub repository referenced in this article contains community-contributed scripts and guides. These are provided as-is for educational purposes and should be tested in non-production environments before use.

Tags: #AzurePostgreSQL #CertificateRotation #TLS #SSL #TrustStores #Operations #DevOps #SRE #CloudSecurity #AzureDatabase

In-App Notification PCF Control

PravinT — Mon, 15 Dec 2025 14:13:21 GMT

Overview

A robust Power Apps Component Framework (PCF) control for Dataverse, designed to deliver, display, and manage in-app notifications. This control supports secure environment variable lookup, publisher-agnostic logic, recipient resolution, and integrates with Microsoft Graph for advanced scenarios. It is built for easy adoption by developers and customers.

Testing Status: This control has been tested for minimum positive flow scenarios. Comprehensive testing for edge cases, error handling, and production readiness is recommended before deployment.

For more information about in-app notifications in Dataverse, see Microsoft Docs: Send in-app notifications within model-driven apps.

Build & Run

npm install npm run build

Features

Notification Delivery: Send notifications to users or groups in Dataverse.
Recipient Resolution: Fetch and display recipient names using systemuser IDs.
Environment Variable Lookup: Secure, publisher-agnostic configuration.
Microsoft Graph Integration: Authenticate and fetch data from Microsoft Graph using MSAL.js.
Robust UI: Modern, responsive React components with Fluent UI styling.
Error Handling: Graceful fallback for missing recipients and robust client-side logic.

Project Structure

NotificationControl/ components/ NotificationDetails.tsx # Displays notification details and recipient info NotificationForm.tsx # Main form for creating and sending notifications NotificationList.tsx # Lists all notifications and handles navigation NotificationForm.css # Styles for the notification form NotificationList.css # Styles for the notification list context/ NotificationContext.tsx # React context for notification state hooks/ useNotifications.ts # Custom hook for notification logic utils/ api.ts # Core notification logic, environment variable lookup, Graph API integration auth.ts # Authentication helpers for MSAL.js ControlManifest.Input.xml # PCF control manifest (input) ControlManifest.xml # PCF control manifest index.ts # Entry point for the control

Component Details & Usage

NotificationList.tsx

Purpose: Displays a list of notifications and allows navigation to detail view. Notifications are grouped by title and body for efficiency.
Props:
- notifications: Array of notification objects.
- onSelect: Handler to select a notification for detail view.
Key Features:
- Grouping: Notifications are grouped by title and body because the same notification is sent separately to each recipient in Dataverse. This prevents duplicate entries in the list view.
- Lazy Loading: Recipients are loaded on-demand (lazy loaded) when you click to view details, reducing initial load time and improving performance.
- Date Filtering: Only notifications from the last 7-14 days are loaded to keep the list manageable and avoid costly aggregation queries on large datasets.
Adoption:
- Use to provide users with an overview of all notifications. Passes context and props to child components.

Sent notifications grouped by title and body, showing count and recipient access.

NotificationDetails.tsx

Purpose: Displays the details of a notification, including title, body, icon, type, and recipient information.
Props:
- notification: The notification object to display.
- showSystemUsers: Whether to show recipient info.
- onBack: Handler to return to the notification list.
- context: Dataverse context for API calls.
Key Functions:
- fetchNames: Fetches recipient names from Dataverse using systemuser IDs. Handles missing recipients gracefully by showing "No recipient assigned".
Adoption:
- Use in detail view to show notification info and recipient names. Handles all edge cases for missing or undefined recipients.

Detail view with graceful fallback for missing recipients.

NotificationForm.tsx

Purpose: Main form for creating and sending notifications. Centralizes environment variable and authentication logic.
Props:
- context: Dataverse context for environment variable lookup and authentication.
Key Functions:
- Handles user input, MSAL authentication, and notification submission.
Features:
- Multiple recipient selection options: System Users, Teams, Queues, and Outlook DLs
- Required fields: Title and Body
- Optional settings: Icon Type (Info, Success, Error, Warning) and Notification Type (Toast, Banner)
Adoption:
- Use as the entry point for users to create and send notifications. Integrates with Microsoft Graph for advanced scenarios.

Comprehensive form with multiple recipient selection options: System Users, Teams, Queues, and Outlook DLs.

NotificationContext.tsx

Purpose: Provides global notification state and actions to components via React context.
Adoption:
- Use to share notification state and actions across components.

useNotifications.ts

Purpose: Custom React hook for fetching, sending, and managing notifications.
Adoption:
- Use in components to access notification logic and state.

api.ts

Purpose: Contains core logic for notification delivery, environment variable lookup, recipient resolution, and Microsoft Graph API integration.
Key Functions:
- getDLMemberObjectIds, getSystemUserIdsByObjectIds, getSystemUserNamesByIds: Utility functions for recipient resolution.
Adoption:
- Use for all backend logic and API calls related to notifications.

auth.ts

Purpose: Handles authentication logic using MSAL.js for Microsoft Graph API access.
Adoption:
- Use to authenticate users and obtain tokens for Graph API calls.

How to Adopt This Control

Import the control into your Dataverse environment.
Configure environment variables for publisher-agnostic setup.
Grant users read privileges on the appnotifications entity. Users receiving in-app notifications must have read privilege on the appnotifications table in Dataverse to view their notifications.
Use NotificationForm to create and send notifications.
Display notifications using NotificationList and NotificationDetails.
Integrate with Microsoft Graph by configuring Azure AD app registration and MSAL.js.
Customize styles using the provided CSS files.

Prerequisites: Environment Variables & Attaching the Control

1. Environment Variables Setup

Important: This control uses Dataverse environment variables (not local .env files) to store configuration values like Azure AD app registration details for Microsoft Graph integration.

Required Environment Variables: You must create the following environment variables in your Dataverse organization:

InAppNotif_App_Tenant_Id - Your Azure AD Tenant ID
InAppNotif_App_Client_Id - Your Azure AD App Registration Client ID (for Microsoft Graph/MSAL authentication)

How to Create Environment Variables in Dataverse:

Go to Power Apps Maker Portal (make.powerapps.com)
Select Solutions from the left navigation
Open your solution (or create a new one)
Click New > More > Environment variable
Create each variable:
- Display Name: InAppNotif App Tenant Id (or similar)
- Name: InAppNotif_App_Tenant_Id
- Data Type: Text
- Default Value: Your Azure AD Tenant ID
- Repeat for InAppNotif_App_Client_Id

How the Control Uses These Variables:

The control reads these environment variables at runtime using the Dataverse WebAPI:

// Example from api.ts const clientId = await getEnvironmentVariable("InAppNotif_App_Client_Id", context); const tenantId = await getEnvironmentVariable("InAppNotif_App_Tenant_Id", context);

This approach makes the control publisher-agnostic and easy to configure across different environments without modifying code.

2. Attaching the Control to a Form

This PCF control can be attached to any field on any form in Dataverse. The control supports the following field types:

Single Line of Text
Email
Phone
URL
Multiple Lines of Text
Whole Number

Important: The field value itself is not used by the control—it only serves as a placeholder for the control's UI. You can place this control on any entity (User, Account, Contact, custom entities, etc.) based on your requirements.

Steps:

Navigate to the Form Editor
- Go to Power Apps Maker Portal (make.powerapps.com)
- Select Tables from the left navigation
- Choose your desired table (e.g., User, Account, Contact)
- Click on Forms tab
- Select and edit the form where you want to add notifications
Add or Select a Field
- Find an existing field that matches one of the supported types (Text, Email, Phone, URL, Multiple Lines, Whole Number)
- Or add a new field to the form if needed
- Click on the field to select it
Add the Custom Control
- With the field selected, click + Component in the right panel
- Or right-click the field and select Properties > Components tab
- Click + Component
- Search for and select NotificationControl
- The control will appear in the Components list
Configure Control Properties
- Label: Set a custom label (e.g., "Notifications")
- Hide label: Check this to hide the field label (recommended for cleaner UI)
- Form field width: Set to desired column width (default: 1 column)
- Show component on: Select platforms (Web, Mobile, Tablet)
- Click Done
Set as Primary Control (Optional)
- In the Components section, you'll see both the default field control and NotificationControl
- You can make NotificationControl the primary control for better visibility
- Or keep both and configure display preferences
Save and Publish
- Click Save to save your changes
- Click Publish to make the control available to users
- The control will now appear on the form when users access it

Example: NotificationControl configured on Primary Email field of User form

Result:

The control will appear on the form, showing all in-app notifications for the current environment
Users can view, create, and manage notifications directly from any form where the control is placed
The control displays with a "New Notification" button and list of existing notifications grouped by title/body

Prerequisites: Outlook DL Selection & Graph API Access

1. Outlook Distribution List (DL) Selection

To enable users to select Outlook Distribution Lists (DLs) for notifications, your control integrates with Microsoft Graph API. This requires:

Azure AD app registration with delegated permissions to read DLs and users.
Environment variable(s) to store the Azure AD Client ID and other config.

Steps:

Register an app in Azure AD (portal.azure.com > Azure Active Directory > App registrations).
Add delegated permissions for Group.Read.All, User.Read, and any other required Graph scopes.
Store the Client ID and other config in Dataverse environment variables.
Configure your control to use these variables for Graph API calls.

2. App Registration & Graph API Access

The app registration must allow access to Microsoft Graph for reading users and groups.
Redirect URI should be set for SPA (Single Page Application) and implicit grant enabled.
The control uses MSAL.js to authenticate and acquire tokens for Graph API.

Security Note:

By default, the control stores the authentication token in the browser (local/session storage) for convenience and seamless user experience.
If customers want to avoid storing tokens in the browser:
- They can disable persistent authentication or use a different MSAL configuration.
- This may require users to re-authenticate more frequently and could impact usability.
- Document this option in your deployment guide and provide configuration instructions.

Example MSAL config:

const msalConfig = { auth: { clientId: clientIdFromEnvVar, authority: "https://login.microsoftonline.com/common", redirectUri: window.location.origin }, cache: { cacheLocation: "sessionStorage", // or "localStorage" storeAuthStateInCookie: false } };

Redirect URI Requirement for MSAL Silent Authentication

Why You Need a Redirect URI

For MSAL.js to perform silent authentication (acquire tokens without user interaction), your Azure AD app registration must include a valid redirect URI. In Dataverse/Power Apps, this is often set to an empty HTML web resource.

Purpose:

The redirect URI is where MSAL will redirect the browser after authentication.
For silent authentication, MSAL uses an iframe and the redirect URI must be a valid, accessible page in your environment.
An empty HTML web resource is commonly used because it loads quickly and does not display content.

How to Set Up

Create an empty HTML web resource in Dataverse:
- Go to Power Apps > Solutions > Add > Web Resource.
- Name it (e.g., msal-redirect.html).
- Content can be just:<html><head></head><body></body></html>
- Save and publish.
Add the web resource URL as a redirect URI in Azure AD app registration:
- Go to Azure Portal > Azure Active Directory > App registrations > Your app.
- Under Authentication, add the web resource URL (e.g., https://<org>.crm.dynamics.com/WebResources/msal-redirect.html) as a redirect URI for SPA.
- Enable Access tokens and ID tokens under Implicit grant.

Important: When adding your web resource redirect URI as a SPA in Azure AD app registration, ensure you enable both Access token and ID token under Implicit grant. This allows MSAL.js to acquire tokens for authentication and API access, enabling seamless user experience and secure integration with Microsoft Graph.

Example

Redirect URI: https://yourorg.crm.dynamics.com/WebResources/msal-redirect.html

Why This Matters

Without a valid redirect URI, MSAL cannot complete silent authentication and users may be prompted to sign in more often.
The empty HTML web resource acts as a safe landing page for token acquisition.

Using Dataverse Teams for In-App Notifications

If your organization configures on-floor teams as Dataverse Teams (with members assigned in Dataverse), supervisors can leverage this feature to send targeted in-app notifications to their team members.

How It Works

Dataverse Team: A group entity in Dataverse that can have multiple users as members. Teams can represent departments, on-floor groups, or any logical unit.
Supervisor Use Case: If you are a supervisor and your team is set up as a Dataverse Team, you can select the team in the notification form and send in-app notifications to all its members at once.

Benefits

Targeted Communication: Easily notify all team members about important updates, tasks, or alerts.
Efficient Workflow: No need to select individual users; simply select the team and send the notification.
Integration: The PCF control fetches team members from Dataverse and ensures notifications are delivered to each member.

Example Scenario

A supervisor wants to notify their on-floor team about a shift change. The team is configured as a Dataverse Team. The supervisor selects the team in the notification form and sends the message. All team members receive the notification instantly in their Dataverse environment.

How to Set Up

Ensure your teams are created and configured in Dataverse (Power Apps > Teams).
Assign users as members to each team.
Use the notification form in the PCF control to select a team and send notifications.

This approach streamlines communication and ensures all relevant users are informed efficiently. For more details, see Microsoft Docs: Manage teams in Dataverse.

Using Queue Selection for Workstream Notifications

If your organization uses queues and workstreams (common in Customer Service or Omnichannel scenarios), you can leverage queue selection to send in-app notifications to all agents associated with a specific workstream.

How It Works

Queue: A Dataverse entity that holds work items and is associated with agents who can work on those items.
Workstream: A collection of queues and routing rules that define how work is distributed to agents.
Agent Use Case: Supervisors or admins can select a queue in the notification form to send in-app notifications to all agents assigned to that queue's workstream.

Benefits

Targeted Communication: Notify all agents working on a specific queue or workstream about important updates, new assignments, or urgent issues.
Efficient Workflow: No need to manually identify and select agents; simply select the queue and the control will resolve all associated agents.
Integration: The PCF control fetches queue members from Dataverse and ensures notifications are delivered to each agent.

Example Scenario

A supervisor wants to notify all agents working on the "Support Queue" about a critical system update. The supervisor selects the queue in the notification form and sends the message. All agents associated with that queue's workstream receive the notification instantly.

How to Set Up

Ensure your queues and workstreams are configured in Dataverse (Power Apps > Queues).
Assign agents to queues or workstreams.
Use the notification form in the PCF control to select a queue and send notifications to all associated agents.

This approach is especially useful for Customer Service and Omnichannel environments where agents are organized by workstreams. For more details, see Microsoft Docs: Manage queues in Dataverse.

For more details, see the Microsoft Docs: Use environment variables in Dataverse, Add PCF controls to forms, Microsoft Docs: Register an app with Azure AD, and MSAL.js configuration options.

Developer Notes

All components are documented with JSDoc comments for easy understanding.
Error handling and fallback logic are implemented for robust user experience.
The codebase is modular and easy to extend for new notification types or integrations.

Contributing

Fork the repository and create a pull request for improvements or bug fixes.
Please document new components and functions using JSDoc comments and update the README as needed.

Testing & Production Readiness

Current Testing Status: This control has been tested for minimum positive flow scenarios only.

Before Production Deployment:

Perform comprehensive testing including edge cases, error scenarios, and negative flows
Conduct security audits and vulnerability assessments
Test with your organization's specific Dataverse configuration and data
Validate performance under expected load conditions
Ensure compliance with your organization's governance and security policies

License

MIT

Disclaimer

USE AT YOUR OWN RISK

This control is provided as-is without any warranties, express or implied. Neither the author nor Microsoft Corporation are responsible for any issues, damages, or losses arising from the use, deployment, or adaptation of this control.

Important:

This control has been tested for minimum positive flow scenarios only
Organizations must conduct their own thorough review and testing before deployment
Ensure the control meets your organization's security, compliance, and design standards
No support or maintenance guarantees are provided

Responsibility: By using this control, you acknowledge that you have reviewed the code, tested it in your environment, and accept full responsibility for its deployment and operation within your organization.

Optimizing Exchange Online PowerShell

erscofie — Thu, 11 Dec 2025 14:12:36 GMT

The Exchange Online PowerShell module is a powerful tool. As environments scale and tasks grow in complexity, performance and reliability become critical. This post takes a holistic approach to optimizing Exchange Online management and automation in four parts:

Windows PowerShell performance tips
Best practices that apply to all M365 PowerShell modules
Best practices specific to the Exchange Online PowerShell module
The future of automation

=================

General Windows PowerShell Performance Tips

Seemingly obvious but often overlooked, if you want to get peak performance from any PowerShell module, you need to optimize Windows PowerShell itself.

Keep PowerShell Updated: Always use the latest supported version of PowerShell for security, compatibility, and performance improvements.
- Windows PowerShell 5.1 is preinstalled on the currently supported versions of Windows. Security updates and other patches are included in Windows Updates.
- For PowerShell 7, follow the steps here.

Disable telemetry if not needed by setting the POWERSHELL_TELEMETRY_OPTOUT environment variable:

$env:POWERSHELL_TELEMETRY_OPTOUT = "true"

=================

Best Practices for all M365 PowerShell Modules

These best practices are vital for, but not specific to Exchange Online PowerShell. In other words, although I’ve used Exchange Online cmdlets in the examples provided, all tips in this section apply to other M365-specific modules like SharePoint, Teams, or Security and Compliance PowerShell.

Use the latest module version to benefit from performance improvements and bug fixes.
- For Admins, establish a regular update cadence for all M365 PowerShell modules. Testing new releases on local machines or management servers is ideal for admins, as it offers flexibility and low risk if problems occur.
- Leverage auto-updates for automation tools, if available. For example, the Managed Dependencies feature for Azure Functions Apps.

Use service principal or app-only (sometimes called app-based) authentication for automation to avoid interactive logins and improve script reliability.
- App-only authentication in Exchange Online PowerShell and Security & Compliance PowerShell
- The exact name, requirements and config for app-only authentication can differ across other services or even in our documentation, but the use-case and benefits are universal for all M365 services.

Script smarter, not harder…

Parallel Processing:
- Leverage ForEach-Object -Parallel (in PowerShell 7+) or background jobs to perform bulk operations faster.

Use -ResultSize to return only the necessary data. This is especially beneficial when querying many objects.

Get-EXOMailbox -ResultSize 100

This example retrieves only the first 100 mailboxes (rather than default of 1,000), reducing resources and time to execute.

Prioritize service-side filtering when available. Not all filters are created equal. Understanding how, or more importantly, where filtering is done when using different methods can have a substantial impact on performance.
- Experienced PowerShell users know about pipelining with Where-Object to filter data. This is one example of client-side filtering.
- Most cmdlets available in the various M365 PowerShell modules support the -Filter parameter. This leverages service-side (a.k.a. server-side) filtering.

Get-EXOMailbox -Filter "Department -eq 'Sales'"

This example limits results to mailboxes for the sales department and leverages service-side filtering to ensure only the data we want is returned to the client.

Service-side filtering is much more efficient for several reasons. A deep-technical explanation of this is outside the scope of the current post, so you can take my word for it or seek out more information for yourself. There are plenty of great, easy to find articles across the web on this topic.

Following the above recommendations helps ensure that we, the users (and our tools), have a solid foundation for optimal performance. Next, let’s look at ways to ensure we get the best performance out of the Exchange Online module itself.

=================

Exchange Online PowerShell (EXO)

The Exchange Online PowerShell module (EXO V3+) introduced significant performance improvements, especially around how cmdlet help files are handled.

Use the Exchange Online V3 Module: The latest module supports REST-based cmdlets, offering better performance and reliability.

How much better and more reliable? I thought you’d never ask…

From REST API connections in the EXO V3 module:

The following table compares the benefits of REST API cmdlets to unavailable remote PowerShell cmdlets and the exclusive Get-EXO* cmdlets in the EXO V3 module

Remote PowerShell cmdlets (deprecated)

Get-EXO* cmdlets

REST API cmdlets

Security

Least secure

Highly secure

Highly secure

Performance

Low performance

High performance

Medium performance

Reliability

Least reliable

Highly reliable

Highly reliable

Functionality

All parameters and output properties available

Limited parameters and output properties available

All parameters and output properties available

Follow the guidelines from this doc. Don’t skip this!!
Microsoft Tech Community: Reducing Memory Consumption in EXO V3

=================

The Future! Microsoft Graph PowerShell SDK

The Microsoft Graph PowerShell SDK is the future of Microsoft 365 automation. It’s modular, cross-platform, and supports modern authentication. Graph can feel overwhelming to those who are comfortable with the current PowerShell modules. If you haven’t started using Graph because you aren’t sure where to start, I recommend you Install the Microsoft Graph PowerShell SDK and check out our aptly named “Getting started” documentation (don’t look at me like that).

Better yet, if you’re a Support for Mission Critical customer, ask your Customer Success Account Manager or Customer Solution Lead about the Microsoft-led training options and learn from an expert!

If you’re already using the Microsoft Graph PowerShell SDK, great! The tips outlined throughout this post can provide the same benefits with Graph.

=================

✅ Final Thoughts

Optimizing PowerShell performance isn’t just about speed – it’s about reliability, scalability, and resource efficiency. Whether you’re using PowerShell for daily management or building and maintaining automation tools for your organization, following these guidelines should have immediate and lasting benefits.

Navigating Microsoft's Copilot Studio and Azure AI Foundry

anishekkamal — Sat, 22 Nov 2025 01:33:03 GMT

Key Insights into Microsoft's AI Landscape

Copilot Studio: Excels in rapid, low-code/no-code development of conversational AI for quick deployment and Microsoft 365 integration.
Azure AI Foundry: Offers comprehensive, code-first AI lifecycle management for advanced customization, enterprise-grade solutions, and deep control over models and data.
Synergistic Approach: The most effective strategy often involves using Copilot Studio as the user-facing interface and Azure AI Foundry as the robust backend engine for complex AI tasks.

In the rapidly evolving landscape of artificial intelligence, Microsoft provides two powerful yet distinct platforms for AI development: Copilot Studio and Azure AI Foundry. While both aim to empower organizations with AI capabilities, they cater to different needs and technical expertise levels. Understanding their individual strengths and, crucially, how they can be strategically combined, is paramount for building effective and scalable AI solutions. This guide delves into the specific scenarios where each platform shines and illustrates the immense benefits of a unified approach.

Copilot Studio: Rapid Conversational AI Development

Simplifying AI Agent Creation for Business Users and Quick Deployments

Copilot Studio is designed for speed and accessibility, making it an ideal choice for users who need to build conversational AI agents without extensive coding knowledge. It offers a low-code/no-code environment that empowers business users, analysts, and citizen developers to create, deploy, and manage AI-powered chatbots and virtual assistants with remarkable efficiency.

Copilot Studio is accessible from https://copilotstudio.microsoft.com and can be used through different licensing options.

Key Characteristics and Use Cases of Copilot Studio

Copilot Studio's appeal lies in its user-friendly interface and seamless integration with the Microsoft ecosystem:

Low-code/No-code Development: Its visual canvas allows for intuitive design and deployment of agents, making AI accessible to a broader audience.
Rapid Deployment: Ideal for scenarios requiring quick prototyping and deployment of conversational bots, often within hours or days.
Microsoft 365 Integration: Tightly integrated with applications like Teams, Outlook, and SharePoint, it's perfect for enhancing productivity within the M365 environment. It can extend Microsoft 365 Copilot's capabilities to connect with external systems.
Simple Workflows: Best suited for tasks such as IT helpdesk FAQs, HR policy queries, basic customer service, and routine automation.
Limited Customization Needs: When pre-built templates and standard models are sufficient, Copilot Studio provides a straightforward path to implementation.

Examples of Copilot Studio in action include internal HR bots for answering common employee questions, customer service agents handling FAQs on websites, and bots automating routine tasks like generating reports or summarizing meetings. It prioritizes ease of use and quick time-to-value, making it a go-to for organizations seeking to rapidly implement conversational AI.

Azure AI Foundry: For Advanced AI Development

Comprehensive Control for Developers and Data Scientists

Azure AI Foundry, formerly known as Azure AI Studio, is a code-first, comprehensive platform built for developers and data scientists who demand granular control over the entire AI lifecycle. It provides a robust environment for building, deploying, managing, and monitoring complex, enterprise-grade AI applications.

The Azure AI Foundry Management Center is available from https://ai.azure.com. While there is no specific license cost for using Azure AI Foundry, note that the different underlying Azure services such as Azure OpenAI, Azure AI Search and the LLMs will incur consumption costs.

Key Characteristics and Use Cases of Azure AI Foundry

Azure AI Foundry is tailored for sophisticated AI projects requiring deep customization and robust governance:

Code-first Environment: It caters to developers and data scientists proficient in languages like Python and tools such as PromptFlow, offering unparalleled control over models and data.
Full AI Lifecycle Management: From model selection and grounding to prompt testing, deployment, evaluation, tracing, and monitoring, Azure AI Foundry covers every stage of AI development.
Advanced Customization: Ideal for scenarios requiring specialized models, stronger reasoning capabilities, image analysis, and domain-specific AI solutions.
Enterprise-Scale Solutions: Designed for production-ready applications that necessitate robust monitoring, tracing, compliance features, data security, and privacy.
Data-Sensitive Operations: Provides granular control over how AI models handle sensitive internal data, ensuring compliance and security.

Use cases for Azure AI Foundry include developing sophisticated AI agents for cyber threat detection, legal document summarization, visual issue detection in IT support, and orchestrating multi-agent systems. It's the platform of choice for organizations needing to own and manage all aspects of their copilots, ensuring high levels of customization, security, and scalability.

Azure AI Foundry specializes in advanced AI capabilities like Retrieval-Augmented Generation (RAG), model benchmarking, and multi-modal integrations.

When to Use Both

Combining Accessibility with Power for Comprehensive Solutions

For many organizations, the most effective AI strategy isn't choosing between Copilot Studio and Azure AI Foundry, but rather leveraging their complementary strengths. This hybrid approach allows for the agility of low-code development while maintaining the control and power of a code-first platform.

Strategic Integration Models

The synergy between Copilot Studio and Azure AI Foundry can manifest in several powerful ways:

Frontend/Backend Architecture: Copilot Studio can serve as the intuitive, user-facing conversational interface (the "front door"), while Azure AI Foundry acts as the powerful backend processing engine (the "engine room"). Copilot Studio captures user requests and routes complex queries or reasoning tasks to Azure AI Foundry for processing, leveraging its advanced models, knowledge bases, and enterprise controls.
Progressive Complexity and Cost Optimization: Begin with Copilot Studio for rapid prototyping and simpler AI agents. As requirements evolve and solutions demand deeper customization, integration with sensitive data, or robust governance, migrate or integrate complex components with Azure AI Foundry. This also allows for cost optimization by handling lightweight tasks in Copilot Studio while scaling heavy inference in Azure AI Foundry.
Leveraging Custom Models: Azure AI Foundry allows organizations to develop and deploy custom, specialized models. These models can then be directly integrated and consumed within Copilot Studio prompts, enabling low-code agents to leverage highly tailored and powerful AI capabilities.
Multi-channel Deployment and Enterprise Governance: Deploy Copilot Studio agents across various channels like Teams, web, and mobile, providing a consistent user experience. Simultaneously, utilize Azure AI Foundry for compliance-controlled processing, robust monitoring, and centralized governance of AI assets.

This combined approach allows organizations to harness the benefits of both platforms: the speed and accessibility of Copilot Studio for conversational AI, and the depth of control, customization, and full lifecycle management offered by Azure AI Foundry for advanced, enterprise-grade applications.

Comparative Analysis

A Side-by-Side Look at Capabilities and Best-Fit Scenarios

To further clarify the distinction and complementary nature of these platforms, let's compare their core capabilities and ideal applications:

Feature/Aspect	Copilot Studio	Azure AI Foundry	Combined Approach
Development Model	Low-code/No-code, visual canvas	Code-first, SDKs, PromptFlow	Hybrid: Low-code frontend, code-first backend
Primary Users	Business users, citizen developers, analysts	Developers, data scientists, AI engineers	Cross-functional teams
Speed of Deployment	Very fast (hours to days)	Moderate to fast (days to weeks, depending on complexity)	Fast prototyping, robust scaling
Customization Level	Limited (templates, connectors)	Extensive (custom models, tools, logic)	Tailored UX with advanced AI logic
Integration Ecosystem	Microsoft 365, Power Platform	Azure services, broad model catalog, external systems	Comprehensive M365 and broader enterprise integration
AI Lifecycle Management	Basic (build, test, publish, analytics)	Full (model selection, grounding, evaluation, monitoring, tracing)	Streamlined development with full control
Complexity of Use Cases	Simple FAQs, basic automation, routing	Complex reasoning, multi-agent systems, RAG over sensitive data	From simple Q&A to sophisticated enterprise AI
Governance & Control	Power Platform admin, basic ALM	Enterprise-grade security, compliance, isolation, detailed logging	User-friendly governance for agents, strict control for core AI
Cost Optimization	Efficient for lightweight tasks	Optimized for complex, scalable inference	Balancing efficiency for simple tasks with robust processing for complex ones

Getting Started with Building Custom Copilots

If you're exploring how to begin your journey with custom copilots, things should be starting to click. As someone deeply involved in learning experiences, I’ve seen firsthand that customers learn best by doing. So, to help you dive in, I recommend starting with these hands-on Microsoft Learn tutorials:

Copilot Studio:

Create and deploy an agent - Learn how to build and deploy an agent using Copilot Studio. This tutorial walks you through adding knowledge, testing content updates in real-time, and deploying your agent to a test page: Link to tutorial.
Building agents with generative AI - Discover how to create agents powered by generative AI. This module outlines key features and prerequisites to get you started: Link to tutorial.
Create and publish agents - Explore how to design agents tailored to real business scenarios—ones that both customers and employees can interact with: Link to tutorial.

Azure AI Foundry:

Build a basic chat app in Python - Set up your local dev environment with the Azure AI Foundry SDK, write prompts, run your app code, trace LLM calls, and perform basic evaluations: Link to tutorial.
Use the chat playground - This QuickStart shows you how to deploy a chat model and experiment with it in the Azure AI Foundry portal’s playground: Link to tutorial.
Azure AI Foundry documentation - Dive into the full documentation to learn how developers and organizations can rapidly build intelligent apps using prebuilt and customizable APIs and models: Link to tutorial.

Conclusion

Ultimately, the choice between Copilot Studio and Azure AI Foundry, or the decision to use both, hinges on the specific needs, technical capabilities, and strategic objectives of an organization. Copilot Studio offers an accessible entry point into AI, enabling rapid development of conversational agents for everyday business scenarios. Azure AI Foundry provides the deep control and comprehensive toolkit necessary for building complex, scalable, and highly customized AI solutions for the enterprise. The most forward-thinking approach for many organizations will be a hybrid one, leveraging Copilot Studio for agile, user-facing interactions and entrusting Azure AI Foundry with the heavy lifting of advanced AI model management and data processing. This synergistic model allows businesses to achieve both speed and scale, delivering powerful AI experiences while maintaining stringent control and compliance.

Azure AI Foundry vs. Azure Databricks – A Unified Approach to Enterprise Intelligence

anishekkamal — Wed, 05 Nov 2025 23:26:57 GMT

Key Insights into Azure AI Foundry and Azure Databricks

Complementary Powerhouses: Azure AI Foundry is purpose-built for generative AI application and agent development, focusing on model orchestration and rapid prototyping, while Azure Databricks excels in large-scale data engineering, analytics, and traditional machine learning, forming the data intelligence backbone.
Seamless Integration for End-to-End AI: A critical native connector allows AI agents developed in Foundry to access real-time, governed data from Databricks, enabling contextual and data-grounded AI solutions. This integration facilitates a comprehensive AI lifecycle from data preparation to intelligent application deployment.
Specialized Roles for Optimal Performance: Enterprises leverage Databricks for its robust data processing, lakehouse architecture, and ML model training capabilities, and then utilize AI Foundry for deploying sophisticated generative AI applications, agents, and managing their lifecycle, ensuring responsible AI practices and scalability.

In the rapidly evolving landscape of artificial intelligence, organizations seek robust platforms that can not only handle vast amounts of data but also enable the creation and deployment of intelligent applications. Microsoft Azure offers two powerful, yet distinct, services in this domain: Azure AI Foundry and Azure Databricks. While both contribute to an organization's AI capabilities, they serve different primary functions and are designed to complement each other in building comprehensive, enterprise-grade AI solutions.

Decoding the Core Purpose: Foundry for Generative AI, Databricks for Data Intelligence

At its heart, the distinction between Azure AI Foundry and Azure Databricks lies in their core objectives and the types of workloads they are optimized for. Understanding these fundamental differences is crucial for strategic deployment and maximizing their combined potential.

Azure AI Foundry: The Epicenter for Generative AI and Agents

Azure AI Foundry emerges as Microsoft's unified platform specifically engineered for the development, deployment, and management of generative AI applications and AI agents. It represents a consolidation of capabilities from what were formerly Azure AI Studio and Azure OpenAI Studio. Its primary focus is on accelerating the entire lifecycle of generative AI, from initial prototyping to large-scale production deployments.

Key Characteristics of Azure AI Foundry:

Generative AI Focus: Foundry streamlines the development of large language models (LLMs) and customized generative AI applications, including chatbots and conversational AI. It emphasizes prompt engineering, Retrieval-Augmented Generation (RAG), and agent orchestration.
Extensive Model Catalog: It provides access to a vast catalog of over 11,000 foundation models from various publishers, including OpenAI, Meta (Llama 4), Mistral, and others. These models can be deployed via managed compute or serverless API deployments, offering flexibility and choice.
Agentic Development: A significant strength of Foundry is its support for building sophisticated AI agents. This includes tools for grounding agents with knowledge, tool calling, comprehensive evaluations, tracing, monitoring, and guardrails to ensure responsible AI practices. Foundry Local further extends this by allowing offline and on-device development.
Unified Development Environment: It offers a single management grouping for agents, models, and tools, promoting efficient development and consistent governance across AI projects.
Enterprise Readiness: Built-in capabilities such as Role-Based Access Control (RBAC), observability, content safety, and project isolation ensure that AI applications are secure, compliant, and scalable for enterprise use.

Figure 1: Conceptual Architecture of Azure AI Foundry illustrating its various components for AI development and deployment.

Azure Databricks: The Powerhouse for Data Engineering, Analytics, and Machine Learning

Azure Databricks, on the other hand, is an Apache Spark-based data intelligence platform optimized for large-scale data engineering, analytics, and traditional machine learning workloads. It acts as a collaborative workspace for data scientists, data engineers, and ML engineers to process, analyze, and transform massive datasets, and to build and deploy diverse ML models.

Key Characteristics of Azure Databricks:

Unified Data Analytics Platform: Central to Databricks is its lakehouse architecture, built on Delta Lake, which unifies data warehousing and data lakes. This provides a single platform for data engineering, SQL analytics, and machine learning.
Big Data Processing: Excelling in distributed computing, Databricks is ideal for processing large datasets, performing ETL (Extract, Transform, Load) operations, and real-time analytics at scale.
Comprehensive ML and AI Workflows: It offers a specialized environment for the full ML lifecycle, including data preparation, feature engineering, model training (both classic and deep learning), and model serving. Tools like MLflow are integrated for tracking, evaluating, and monitoring ML models.
Data Intelligence Features: Databricks includes AI-assistive features such as Databricks Assistant and Databricks AI/BI Genie, which enable users to interact with their data using natural language queries to derive insights.
Unified Governance with Unity Catalog: Unity Catalog provides a centralized governance solution for all data and AI assets within the lakehouse, ensuring data security, lineage tracking, and access control.

Figure 2: The Databricks Data Intelligence Platform with its unified approach to data, analytics, and AI.

The Symbiotic Relationship: Integration and Complementary Use Cases

While distinct in their primary functions, Azure AI Foundry and Azure Databricks are explicitly designed to work together, forming a powerful, integrated ecosystem for end-to-end AI development and deployment. This synergy is key to building advanced, data-driven AI solutions in the enterprise.

Seamless Integration for Enhanced AI Capabilities

The integration between the two platforms is a cornerstone of Microsoft's AI strategy, enabling AI agents and generative applications to be grounded in high-quality, governed enterprise data.

Key Integration Points:

Native Databricks Connector in AI Foundry: A significant development in 2025 is the public preview of a native connector that allows AI agents built in Azure AI Foundry to directly query real-time, governed data from Azure Databricks. This means Foundry agents can leverage Databricks AI/BI Genie to surface data insights and even trigger Databricks Jobs, providing highly contextual and domain-aware responses.
Data Grounding for AI Agents: This integration enables AI agents to access structured and unstructured data processed and stored in Databricks, providing the necessary context and knowledge base for more accurate and relevant generative AI outputs. All interactions are auditable within Databricks, maintaining governance and security.
Model Crossover and Availability: Foundation models, such as the Llama 4 family, are made available across both platforms. Databricks DBRX models can also appear in the Foundry model catalog, allowing flexibility in where models are trained, deployed, and consumed.
Unified Identity and Governance: Both platforms leverage Azure Entra ID for authentication and access control, and Unity Catalog provides unified governance for data and AI assets managed by Databricks, which can then be respected by Foundry agents.

Here's a breakdown of how a typical flow might look:

Mindmap 1: Illustrates the complementary roles and integration points between Azure Databricks and Azure AI Foundry within an end-to-end AI solution.

When to Use Which (and When to Use Both)

Choosing between Azure AI Foundry and Azure Databricks, or deciding when to combine them, depends on the specific requirements of your AI project:

Choose Azure AI Foundry When You Need To:

Build and deploy production-grade generative AI applications and multi-agent systems.
Access, evaluate, and benchmark a wide array of foundation models from various providers.
Develop AI agents with sophisticated capabilities like tool calling, RAG, and contextual understanding.
Implement enterprise-grade guardrails, tracing, monitoring, and content safety for AI applications.
Rapidly prototype and iterate on generative AI solutions, including chatbots and copilots.
Integrate AI agents deeply with Microsoft 365 and Copilot Studio.

Choose Azure Databricks When You Need To:

Perform large-scale data engineering, ETL, and data warehousing on a unified lakehouse.
Build and train traditional machine learning models (supervised, unsupervised learning, deep learning) at scale.
Manage and govern all data and AI assets centrally with Unity Catalog, ensuring data quality and lineage.
Conduct complex data analytics, business intelligence (BI), and real-time data processing.
Leverage AI-assistive tools like Databricks AI/BI Genie for natural language interaction with data.
Require high-performance compute and auto-scaling for data-intensive workloads.

Use Both for Comprehensive AI Solutions:

The most powerful approach for many enterprises is to leverage both platforms. Azure Databricks can serve as the robust data backbone, handling data ingestion, processing, governance, and traditional ML model training. Azure AI Foundry then sits atop this foundation, consuming the prepared and governed data to build, deploy, and manage intelligent generative AI agents and applications. This allows for:

Domain-Aware AI: Foundry agents are grounded in enterprise-specific data from Databricks, leading to more accurate, relevant, and trustworthy AI responses.
End-to-End AI Lifecycle: Databricks manages the "data intelligence" part, and Foundry handles the "generative AI application" part, covering the entire spectrum from raw data to intelligent user experience.
Optimized Resource Utilization: Each platform focuses on what it does best, leading to more efficient resource allocation and specialized toolsets for different stages of the AI journey.

Comparative Analysis: Features and Capabilities

To further illustrate their distinct yet complementary nature, let's examine a detailed comparison of their features, capabilities, and typical user bases.

Radar Chart 1: This chart visually compares Azure AI Foundry and Azure Databricks across several key dimensions, illustrating their specialized strengths. Azure AI Foundry excels in generative AI and agent orchestration, while Azure Databricks dominates in data engineering, unified data governance, and traditional ML workflows.

A Detailed Feature Comparison

Feature Category	Azure AI Foundry	Azure Databricks
Primary Focus	Generative AI application & agent development, model orchestration	Large-scale data engineering, analytics, traditional ML, and AI workflows
Data Handling	Connects to diverse data sources (e.g., Databricks, Azure AI Search) for grounding AI agents. Not a primary data storage/processing platform.	Native data lakehouse architecture (Delta Lake), optimized for big data processing, storage, and real-time analytics.
AI/ML Capabilities	Foundation models (LLMs), prompt engineering, RAG, agent orchestration, model evaluation, content safety, responsible AI tooling.	Traditional ML (supervised/unsupervised), deep learning, feature engineering, MLflow for lifecycle management, Databricks AI/BI Genie.
Development Style	Low-code agent building, prompt flows, unified SDK/API, templates.	Code-first (Python, SQL, Scala, R), notebooks, IDE integrations.
Model Access & Deployment	Extensive model catalog (11,000+ models), serverless API, managed compute deployments, model benchmarking.	Training and serving custom ML models, including deep learning. Models available for deployment through MLflow.
Governance & Security	Azure-based security & compliance, RBAC, project isolation, content safety guardrails, tracing, evaluations.	Unity Catalog for unified data & AI governance, lineage tracking, access control, Entra ID integration.
Key Users	AI developers, business analysts, citizen developers, AI app builders.	Data scientists, data engineers, ML engineers, data analysts.
Integration Points	Native connector to Databricks AI/BI Genie, Azure AI Search, Microsoft 365, Copilot Studio, Power Platform.	Microsoft Fabric, Power BI, Azure AI Foundry, Azure Purview, Azure Monitor, Azure Key Vault.

Table 1: A comparative overview of the distinct features and functionalities of Azure AI Foundry and Azure Databricks

Concluding Thoughts

In essence, Azure AI Foundry and Azure Databricks are not competing platforms but rather essential components of a unified, comprehensive AI strategy within the Azure ecosystem. Azure Databricks provides the robust, scalable foundation for all data engineering, analytics, and traditional machine learning workloads, acting as the "data intelligence platform." Azure AI Foundry then leverages this foundation to specialize in the rapid development, deployment, and operationalization of generative AI applications and intelligent agents. Together, they enable enterprises to unlock the full potential of AI, transforming raw data into powerful, domain-aware, and governed intelligent solutions.

Frequently Asked Questions (FAQ)

What is the main difference between Azure AI Foundry and Azure Databricks?

- Azure AI Foundry is specialized for building, deploying, and managing generative AI applications and AI agents, focusing on model orchestration and prompt engineering. Azure Databricks is a data intelligence platform for large-scale data engineering, analytics, and traditional machine learning, built on a Lakehouse architecture.

Can Azure AI Foundry and Azure Databricks be used together?

- Yes, they are designed to work synergistically. Azure AI Foundry can leverage a native connector to access real-time, governed data from Azure Databricks, allowing AI agents to be grounded in enterprise data for more accurate and contextual responses.

Which platform should I choose for training large machine learning models?

- For training large-scale, traditional machine learning, and deep learning models, Azure Databricks is generally the preferred choice due to its robust capabilities for data processing, feature engineering, and ML lifecycle management (MLflow). Azure AI Foundry focuses more on the deployment and orchestration of pre-trained foundation models and generative AI applications.

Does Azure AI Foundry replace Azure Machine Learning or Databricks?

- No, Azure AI Foundry complements these services. It provides a specialized environment for generative AI and agent development, often integrating with data and models managed by Azure Databricks or Azure Machine Learning for comprehensive AI solutions.

How do these platforms handle data governance?

- Azure Databricks utilizes Unity Catalog for unified data and AI governance, providing centralized control over data access and lineage. Azure AI Foundry integrates with Azure-based security and compliance features, ensuring responsible AI practices and data privacy within its generative AI applications.

When Your CRM Plays Hide-and-Seek: The Mystery of Missing Columns in Dynamics 365

JeffM — Tue, 04 Nov 2025 21:20:22 GMT

What Happened?

Personal views across multiple organizations started showing empty columns, even though the data was there. For businesses that rely on these views for daily decisions, this isn’t a normal glitch—the end users can easily assume that “no data” in the view means no data in the record and make decisions based on an incomplete picture of customer information.

The Detective Work

Our investigation uncovered the culprit: a mismatch between two behind-the-scenes players—View XML and Fetch XML. Think of them as the blueprint and the builder. When they don’t talk to each other properly, your view looks fine but can’t fetch the data it needs.

Why It Matters

This isn’t just a tech hiccup—it’s a reminder of how small cracks in system design can ripple into big business headaches. It also highlights the need for smarter automation and better error detection in enterprise platforms.

The Fix (and the Frustration)

The good news? A manual fix was quickly identified over a year ago. The bad news? It was manual. And many impacted users didn’t even know that their views were bad. We needed a better solution and now, we have one.

Starting in October 2025, Microsoft rolled out a behind the scenes fix option. Once it’s turned on, any time a user opens a corrupted view, that view will be automatically updated to display the correct data. If the user has permission to edit the view, the updates will be saved so that the view will be permanently fixed. But there’s still a catch. Microsoft doesn’t want to enable a process that makes data changes (in this case, the data is the view definition) without your company’s permission. If your organization is running into this issue, here’s a quick test to assure that the new Microsoft fix will work for you:

Identify views that you know are not rendering properly and that you will be able to access

If you create a copy of a view that is corrupted, the copy will also have the corruption, so you can create additional views to test

In your browser URL bar, append the following to the end of your Dynamics URL: &flags=FCB.DataSetViewFixMissingFetchColumns=true

This will enables a “feature flag” that fixes the views issue, but only for the user that added the flag to the URL and only until their session expires. Other users will not see the update.

If your URL looks like this:
https://org7909d641.crm.dynamics.com/main.aspx?appid=12345678-1234-1234-1234-123456789012
… make it look like this and hit enter
https://org7909d641.crm.dynamics.com/main.aspx?appid=12345678-1234-1234-1234-123456789012&flags=FCB.DataSetViewFixMissingFetchColumns=true

Wait for Dynamics to reload

Test opening the corrupted views. You’ll see that they’re magically working as expected

When you are satisfied that this is working for you as desired, open a case with Microsoft Support and request that your organization be enabled for the DataSetViewFixMissingFetchColumns FCB. This will enable the fix for all users across your Dynamics organization

Takeaway: If your CRM starts acting like a magician hiding data, don’t panic. The data is still there—you just need to coax it back with the right fix. And now there’s an option to make sure that this issues goes away for good.

	Remote PowerShell cmdlets (deprecated)	*Get-EXO cmdlets**	REST API cmdlets
Security	Least secure	Highly secure	Highly secure
Performance	Low performance	High performance	Medium performance
Reliability	Least reliable	Highly reliable	Highly reliable
Functionality	All parameters and output properties available	Limited parameters and output properties available	All parameters and output properties available

rss.livelink.threads-in-node

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

TL:DR (What you need to know)

Quick checklist

What Is IDCRL and Why Is It Going Away?

Key Dates and Impact on Users

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

Check Microsoft Purview audit logs (recommended)

What to look for in the export

How to Transition to Modern Authentication (Action Plan)

A few best practices while you’re updating

PowerShell: temporarily allow legacy authentication (extension)

Next steps (recommended)

Helpful Resources and Support

Conclusion and call to action

Q&A

Admin email template (notify owners identified in Purview)

SharePoint and OneDrive Site User ID Mismatch Explored

Background Design Explained

Considerations for users removed from Entra ID

Preventive Measures to Avoid Site User ID Mismatches

Identity lifecycle best practices

Rehire scenarios

Tenant/domain changes

Operational hygiene

Cleanup Site User ID Mismatches

Summary

Further Reading

Finding and Remediating EWS App Usage Before Retirement

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

Start here: check your Message Center first

What the Exchange-App-Usage-Reporting script does

How the script complements the Microsoft 365 admin center EWS usage report

Step-by-step: run the script and generate the report

1) Download the code

2) Get active applications

3) Get sign-in activity report for an application

4) Get user license information (Kiosk and Frontline identification)

How to interpret the output (and prioritize fixes)

Don’t miss the Kiosk / Frontline Worker EWS blocks (end of June 2026)

Remediation options (what to do when you find an EWS dependency)

Quick checklist

Azure SRE Agent Architecture and Creation: Practical Benefits for SAP on Azure Customers

Introduction:

How Azure SRE Agent Architecture and Creation Benefit SAP on Azure Customers:

Centralized Azure Service Management Capabilities:

Creating an SRE Agent in the Azure Portal:

Access the Azure portal and complete the following steps to create an SRE Agent.

Conclusion:

Reference links:

Accelerating AKS Upgrades with Fleet Manager: Finding the Right Balance

Create an Organizational Assets Library (including Multi-Geo & Information Barriers guidance)

Overview

Quick start (standard single-geo tenant)

Key constraints and gotchas

Implementation steps

Configure a public CDN (required)

Add CDN origins for each library

Set permissions (required for broad consumption)

Create libraries and upload assets

Multi-Geo mini runbook (recommended pattern)

Wrap-up

Validate configuration

Admin checks (PowerShell)

End-user checks (Office apps)

Updating content in existing Org Assets Libraries

Example of interacting with Org Assets from M365 Apps

Troubleshooting tips

Guidance: Using the SharePoint Online Public CDN

What “Public CDN” actually means

No new content types are exposed

Why Microsoft requires a Public CDN for Org Assets?

Best practices

Governance and ownership checklist

Information architecture and naming

Permissions and access

CDN configuration

Multi-Geo and Brand Center

Information Barriers (IB) sequencing

Copilot readiness (image libraries)