Retirement of Azure Communication Services
Microsoft has announced several retirement and breaking changes in September 2026. One notable change is the retirement of Azure Communication Services as a standalone offering, scheduled to take effect on September 30, 2028. Organizations currently using Azure Communication Services should review the announcement, assess the potential impact on their environments, and begin planning accordingly. https://learn.microsoft.com/en-us/azure/communication-services/acs-retirement-and-breaking-changes-guide
Azure Local Storage: Choose the Architecture That Fits Your Business
Organizations modernize infrastructure in different ways. Some prioritize a simple, integrated platform; others need to preserve SAN investments, scale storage independently, or support workloads with different storage requirements. In this post, we'll explore the storage options available in Azure Local, when to use each one, and the business benefits they unlock. One Platform, Multiple Storage Architectures Azure Local brings multiple storage choices into a consistent, cloud-connected platform experience. Hyperconverged Infrastructure (Storage Spaces Direct) Storage Spaces Direct (S2D) provides a hyperconverged architecture where compute and storage are integrated into the same cluster. This model is ideal for customers looking for streamlined deployment experience, with infrastructure managed as a single platform and fewer organizational dependencies. Disaggregated Architecture (SAN Only) Azure Local supports validated external storage arrays connected through Fibre Channel or iSCSI. This architecture enables organizations to leverage existing storage investments and advanced storage services while independently scaling compute to support higher-capacity requirements. This gives customers the flexibility to work with supported storage vendors—including Dell, HPE, Hitachi, Lenovo, NetApp, and Everpure—while using the Fibre Channel or iSCSI connectivity already supported by Azure Local. Hybrid Architecture (Storage Spaces Direct + SAN) Customers can also combine Storage Spaces Direct and external storage to support different workload requirements within the same environment. This approach offers maximum flexibility, allowing organizations to align storage choices with application needs. Which Storage Option Should You Choose? If your goal is... Consider Simple integrated infrastructure Hyperconverged Expand an existing Azure Local cluster storage capacity Hybrid Reuse existing storage investments Hybrid or Disaggregated Independent compute and storage scaling Disaggregated Consolidate storage across workloads Disaggregated Advanced storage efficiency capabilities Disaggregated Flexible workload placement Hybrid Traditional three-tier architecture modernization Disaggregated Minimize infrastructure replacement Disaggregated Higher-scale compute clusters with more than 16 nodes Disaggregated Ready to size your solution? Use ODIN for Azure Local to translate workload, resiliency, growth, compute, and storage requirements into an example solution design. Use ODIN as a planning aid and validate the proposed configuration against official Azure Local documentation and with your preferred hardware and storage partners. Before finalizing your design, review External storage support for Azure Local for supported architectures and protocols, and Supported SAN solutions on Azure Local for validated storage partners and configurations. Use the comparison above to identify the most suitable architecture, then use ODIN, official Azure Local documentation, and partner guidance to validate workload sizing, supported configurations, and operational requirements. Modern Infrastructure Demands More Storage Flexibility Storage architecture decisions increasingly depend on more than capacity and performance. Organizations must also account for operational processes, maintenance planning, existing infrastructure, efficiency services, resiliency, and expected growth. These priorities influence whether an organization chooses an integrated, disaggregated, or hybrid architecture—and which benefits matter most in its environment. The following benefits explain where external storage can add value within that decision. Benefits of External Storage with Azure Local Protect Existing Investments Many organizations already operate enterprise storage platforms that support critical business applications. Azure Local enables customers to modernize compute infrastructure while continuing to leverage existing storage investments, operational expertise, backup strategies, and storage management processes. Get More Value from Every Terabyte Storage efficiency is becoming increasingly important as organizations scale virtualized environments, desktop infrastructure, databases, and application workloads. Many enterprise storage platforms offer advanced services such as compression, deduplication, thin provisioning, and capacity optimization. Organizations can leverage these capabilities while maintaining consistent Azure Local management experience. Spend Less Time Maintaining Infrastructure Operational efficiency is often just as important as infrastructure capabilities. Because compute and storage are separated in SAN-based architectures, organizations can independently manage storage and compute infrastructure. This can help simplify maintenance planning and reduce storage-related operational activities during maintenance events. Customers frequently cite more predictable maintenance windows, simplified update planning, mature storage monitoring practices, and reduced operational complexity. Scale on Your Terms One of the primary reasons organizations adopt external storage is flexibility. In hyperconverged environments, compute and storage typically scale together. With disaggregated storage, organizations can expand storage capacity independently from compute resources. This can be particularly valuable when storage growth outpaces CPU or memory requirements. Designed for Enterprise Resiliency Azure Local pairs cloud-connected infrastructure with the storage maturity Windows Server has refined over many generations. For external storage, that means working with the same well-understood technologies you already rely on—Fibre Channel and iSCSI connectivity, MPIO, dual fabrics, redundant controllers, and Cluster Shared Volumes—applied to the Azure Local platform. Because these are proven, standard building blocks, you have the flexibility to design highly available storage that fits your existing SAN investments and operational practices, rather than adapt to an unfamiliar model. For implementation requirements and configuration steps—including Fibre Channel, iSCSI, MPIO, array-side configuration, and presenting SAN-backed volumes as Cluster Shared Volumes see : Connect an external storage array to Azure Local. Real-World Scenarios Streamlined Infrastructure for Distributed Locations Retail stores, branch offices, and back-office environments can use a hyperconverged architecture to run applications on an integrated compute and storage platform. This approach simplifies deployment and day-to-day operations for locations that need consistent infrastructure without dedicated storage teams. Flexible Workload Placement Manufacturing and healthcare organizations can use a hybrid architecture when some workloads are best served by integrated Storage Spaces Direct and others require external SAN capacity or established storage services. This allows application teams to place workloads on the storage option that best meets their performance, resiliency, and operational requirements. Modernizing while Preserving SAN Investments A manufacturing organization, financial institution, or enterprise datacenter with established SAN platforms and processes can use a disaggregated architecture to modernize compute without redesigning storage operations, retraining teams, or immediately replacing proven infrastructure. Scaling Storage as Data Needs Grow Data-intensive environments—including manufacturing, fintech, and enterprise datacenters—may find that storage capacity grows faster than compute demand. A disaggregated architecture allows them to scale storage and compute independently, helping optimize infrastructure investments over time. Cost and Licensing Considerations Azure Local uses a monthly service fee based on the deployment configuration: Hyperconverged deployments (S2D only): Compute and storage are integrated in the same cluster using Storage Spaces Direct, with no external SAN storage. A monthly service fee of $10 per physical core/month applies. Disaggregated (SAN only), and hybrid storage configurations (S2D with SAN): Disaggregated deployments use external SAN storage instead of Storage Spaces Direct, while hybrid deployments with external storage combine Storage Spaces Direct with external SAN storage. Using external SAN storage has a monthly service fee of $20.1 per physical core/month applies. Prices are subjected to change. For current pricing details and applicable terms, visit Azure Local Pricing | Microsoft Azure. Choosing the Right Fit for Your Business Start with the operating model and workload requirements you need to support, then choose the architecture that best fits them. Azure Local provides a consistent platform experience across hyperconverged, disaggregated, and hybrid deployments. That consistency lets organizations modernize without treating storage architecture as a one-time, irreversible choice. The right storage strategy is the one that fits your workloads, operations, and growth plans. Learn more: Storage Spaces Direct overview; External storage support for Azure Local; Supported SAN solutions on Azure Local; Connect an external storage array to Azure Local; Azure Local pricing; and Azure Hybrid Benefit for Azure Local.Move to Modern SQL Server Licensing with Confidence
Why eligible customers should move to pay-as-you-go licensing (PAYG) For eligible SQL Server workloads, PAYG should be the preferred licensing approach when moving away from licenses and Software Assurance. It aligns billing with measured usage, adapts as the estate changes, and reduces the operational burden of managing fixed license quantities. The transition requires deliberate resource-configuration updates, but the result is a more flexible and manageable licensing model. Align cost with measured usage: Adopt consumption-based billing for eligible SQL Server resources instead of maintaining fixed license allocations. Scale without repeated license true-ups: Let billing adjust as workloads are added, removed, migrated, resized, or used intermittently. Manage licensing through Azure: Use Azure-based controls to review resource-level licensing and improve visibility across the estate. Reduce license administration: Spend less time tracking fixed quantities and aligning individual resources with license inventory. Optimize committed consumption: After establishing stable PAYG usage, evaluate applicable Azure savings plans or reservations to help reduce costs. Guidance for transitioning your resource settings Once your organization decides to adopt PAYG for eligible SQL Server workloads, update the license configuration on each resource so billing reflects that decision. A commercial or licensing change alone does not update resource-level settings. Plan this configuration work as part of the transition rather than treating it as a follow-up. Starting early gives teams time to validate security, networking, Azure Arc connectivity, billing, and operational processes before switching the broader estate. Automate the transition to pay-as-you-go SQL licensing at scale Choose the transition approach that fits your estate PowerShell for a controlled bulk change Use PowerShell when you need a targeted transition across a defined tenant, subscription, resource group, or resource scope. Discover and review resources before making changes. Test the transition with a limited scope. Update eligible resources in bulk when the organization is ready. Validate the resulting license configuration and billing signals. Azure Policy for ongoing governance Use Azure Policy to transition existing SQL resources to PAYG and continuously enforce the desired licensing configuration. Azure Policy helps identify configuration drift, maintain compliance, and automatically remediate non-compliant resources at scale. Define the approved license configuration for eligible resources. Assign policy at the appropriate subscription or resource group scope. Monitor compliance through centralized Azure views. Remediate resources that drift from the approved configuration. Recommended path to PAYG Commit to the PAYG target. Confirm which eligible workloads will move and identify the teams responsible for licensing, Azure, security, networking, and SQL operations. Prepare the estate. For SQL Server running outside of Azure, connect to Azure Arc. Inventory eligible SQL resources and confirm that Azure Arc connectivity and required organizational approvals are in place. Prove the transition. Test resource updates and billing behavior in a limited resource group or subscription. Move at scale. Use PowerShell for a controlled bulk transition, then apply Azure Policy for ongoing governance where appropriate. Verify and operate. Review the resulting configuration, monitor compliance, and reassess as the SQL estate grows or changes. Evaluate commitment-based savings. After establishing a stable PAYG usage pattern, assess whether an applicable Azure savings plan or reservation could reduce costs. Review eligibility, coverage, and commitment terms with your Microsoft representative. Learn more Automate the transition to pay-as-you-go SQL licensing at scale Manage licensing and billing of SQL Server enabled by Azure Arc Pricing guidance for SQL Server on Azure VMs Azure SQL Database pricing Eligibility, billing treatment, prerequisites, and available licensing options vary by resource and licensing arrangement. Review the applicable Microsoft terms and product guidance, and consult your Microsoft representative or licensing specialist as needed.SQL Server 2016 Extended Security Updates: Stay Protected While You Modernize
SQL Server 2016 reaches the end of extended support on July 14, 2026. After that date, instances that remain on SQL Server 2016 no longer receive regular security updates unless they are covered through Extended Security Updates (ESUs)). ESUs provide a time-bound security bridge for customers who need to maintain existing workloads while they upgrade to a supported SQL Server release or modernize to Azure SQL. SQL Server 2016 Extended Security Updates can be managed across multiple deployment models, including SQL Server enabled by Azure Arc for on-premises and other clouds, and SQL Server on Azure Virtual Machines. This provides a consistent protection path while customers assess modernization options and operational readiness. Today, we are making the Extended Security Updates subscription experience available in Azure so customers can enroll ahead of SQL Server 2016 reaching end of support, and be ready to receive Extended Security Updates when they are released. Why this matters now SQL Server follows a fixed lifecycle policy with mainstream support followed by extended support. Once SQL Server 2016 exits extended support, Extended Security Updates become the only for continued security coverage on that version. Extended Security Updates are intended as a temporary option for risk reduction, not as a long-term alternative to upgrade or modernization. For many production environments, the constraint is not awareness of the deadline but the complexity of the upgrade path. Application dependencies, validation requirements, change windows, and compliance controls sometimes make immediate migration impractical. Extended Security Updates help teams maintain security coverage during that transition period while they sequence remediation, testing, and platform changes. How SQL Server 2016 Extended Security Updates work Support window: SQL Server 2016 exits extended support on July 14, 2026. Extended Security Updates are available for up to three additional years, with coverage periods defined by the SQL Server 2016 lifecycle schedule through July 17, 2029. Supported scope and update model Eligible versions: SQL Server 2016. Extended Security Updates are also available for SQL Server 2014 until July 12, 2027. Eligible editions: Standard and Enterprise Update content: Extended Security Updates deliver critical security updates when applicable. They do not include new features, non-security bug fixes, non-critical security updates, or design changes. Operational note: SQL Server ESUs are not published on a fixed monthly cadence. They are released when qualifying vulnerabilities require a release. For Azure Arc-connected environments, Extended Security Updates subscriptions can be aligned to the deployment model, including virtual cores for VM-based deployments and physical cores for host-based scenarios. This gives organizations flexibility to match ESU coverage to how SQL Server is deployed and managed. How to acquire Extended Security Updates coverage Customers can acquire SQL Server ESU coverage in different ways depending on where SQL Server is running and how they prefer to purchase. For on-premises, edge, and other cloud environments, SQL Server enabled by Azure Arc provides the control plane to onboard instances, manage eligibility, and apply ESU subscription settings. For workloads already running on Azure Virtual Machines, customers can subscribe to ESU coverage through Azure-based controls. Customers can purchase that coverage as pay-as-you-go through Azure or through Volume Licensing on an annual basis for eligible licenses with active Software Assurance. When customers choose Volume Licensing, Azure Arc registration is still required to activate access to ESUs. SQL Server enabled by Azure Arc: Use Azure Arc to onboard eligible SQL Server instances outside Azure, manage Extended Security Updates subscription settings, and support both connected and qualifying disconnected scenarios. SQL Server on Azure Virtual Machines: Use Azure-based controls to subscribe to Extended Security Updates coverage for workloads running on Azure Virtual Machines. For SQL Server 2016, this now requires a paid ESU subscription rather than the previous no-additional-cost experience. Supported regions: Subscribing to Extended Security Updates for SQL Server on Azure VMs is only available in the supported regions listed. To subscribe to ESUs in an unsupported region, contact Microsoft Support to determine the appropriate ESU acquisition path. Volume Licensing: If you cannot subscribe to Extended Security Updates via Azure Arc, you can purchase through the Volume Licensing channel on an annual basis for eligible licenses with active Software Assurance. Talk to your Microsoft seller for more information. Azure Arc registration is still required to activate access to ESUs. Migrate to Azure SQL: Customers that are ready to modernize further can move to Azure SQL Database or Azure SQL Managed Instance, which removes Extended Security Updates dependency by moving to fully supported, cloud-managed SQL services. The following diagram summarizes how customers can obtain SQL Server 2016 Extended Security Updates coverage through Azure Arc and Azure Virtual Machines. What to do next Organizations still running SQL Server 2016 should use the remaining support window to assess estate readiness, determine the right Extended Security Updates subscription model, and define the target modernization path for each workload. For some environments, that means upgrading in place to a supported SQL Server version. For others, it means migrating and upgrading to Azure Virtual Machines or Azure SQL to simplify long-term operations. The important step is to make the transition plan executable before support ends. Learn more SQL Server end of support options SQL Server Extended Security Updates enabled by Azure Arc SQL Server enabled by Azure Arc Extend support for SQL Server with Azure VM SQL Server on Azure VM overview Migrate to Azure SQL
Workload Orchestration in the Azure portal is now available: Deploy in minutes, scale with ease
Edge deployments rarely stay simple for long. What begins as an application running on a single Kubernetes cluster can quickly expand across stores, factories, branches, or other distributed locations, each having different configuration needs. That is exactly where workload orchestration for Azure Arc comes in. Workload orchestration helps teams manage that complexity by providing a centralized approach to consistently define, configure, and deploy applications across distributed cloud, on-premises, and edge environments, all while catering to custom configuration needs of individual sites and deployment targets. See the experience in action Evaluating a new deployment approach often starts slowly: study the documentation, package an application, complete the setup, and only then decide whether it fits. The Azure portal reverses that order with its jumpstart onboarding experience. Bring your Azure Arc-enabled Kubernetes cluster and deploy a pre-packaged application in minutes. Whether you are validating a proof of concept or introducing the product to your broader team, the new portal onboarding experience turns the end-to-end workflow into something you can quickly try on your own cluster. Scale from first deployment to production Once you have validated the first deployment, you can evolve the same approach for production. Onboard your infrastructure into workload orchestration, organize your deployment sites into hierarchies, and define shared configurations for all deployments – all without leaving the portal. This lets you expand from one cluster to a distributed fleet while retaining centralized governance, repeatability, and site-level flexibility. Ready to try it? Try now by deploying your first application with workload orchestration in the Azure portal. Explore the product documentation for the complete set of capabilities.Tenant to Tenant Migration from Existing Hybrid Model
Our company was recently acquired, and the desire is to migrate our tenant into theirs. - we are in a Hybrid deployment (1 remaining OnPrem Exchange server** and using AzureAD Sync) - we are a relatively small shop (~51 accounts w/<400GB total in mailboxes, 200GB in OneDrive, very little in SharePoint) - we create users and mailboxes OnPrem and migrate them to O365 and manage them OnPrem **In preparation and testing for this, I have taken our OnPrem Exchange server out of the mailflow, pointed the MX records to O365, disabled the connectors, etc and mail flows perfectly fine. I also created a test user in our LocalAD and synced that account to O365 (didn't create a mailbox on the local Exchange server), assigned licensing and let it create an ExchangeOnline mailbox and that mail flows fine as well. - they are not hybrid - they are using Azure AD Sync. They create and manage users in their local AD and sync them to O365 (same as we do) - they do not have any OnPrem Exchange, so all of their users mailboxes are created in the cloud automatically as licenses are applied. The question is, what is the best approach? We've looked at some third party utilities for the migration that look good, but the concern with that method is what happens then to my local AD and AzureAD Sync; managing the existing users that were created, synced and then migrated; and my local users authenticating to it, etc? Are we going to be able to fully decommission the last Exchange server and not lose the ability to manage our folks. I need them to authenticate to our Local AD so do I then point AzureAD Sync to the domain in the new tenant? We talked about the possibility of simply creating the users manually in the other tenant, then exporting/importing their data to their new accounts (instead of migrating the account itself) to remove the need to maintain an OnPrem Exchange server if the users weren't created locally then migrated. How then does that affect them authenticating to our local AD since as I understand it, you cant sync from AzureAD back to a local AD. What about the possibility (same as what I wrote in BOLD above) of recreating all of the users in my local AD (with a different UPN), not creating mailboxes locally, syncing them to 0365, assigning licensing and letting the ExchangeOnline mailbox be created automatically (no mailbox migration like we are currently doing). Then we could import their PST to their new mailbox. Now, the users WOULD exist in our localAD and when we migrate that new batch of users to the new tenant, we could point AzureAD Sync to the new tenant and it should sync. AND since they never had a mailbox on our OnPrem Exchange server, there would be no need to maintain it. Appreciate any help on working through this!
Exchange SE Published Calendar URLs giving HTTP 500 error (both html and ics)
I'm getting an http 500 error when trying to browse any published calendar url. I already recreated the owa virtual directories and just updated to the latest patch level of Exchange Server SE. I did a failed request tracing for error 500 and I see the following info: When I got to that section of the web.config I see the following under rewrite: I tried using AI to "fix" this but it didn't fix anything. Can anyone offer any insite as to what's wrong here? Thanks! p.s. this was getting listed as spam so I will paste the text from the pictures in a reply below
