Azure Service Bus: Stop SBMP Outages Before September 30, 2026

Microsoft’s September 30, 2026 Azure Service Bus deadline creates two different risks: Windows workloads still using SBMP will stop communicating, while applications already using AMQP through a legacy SDK may continue running without Microsoft support or updates. Teams should validate confirmed or suspected SBMP workloads now, use AMQP as a tested continuity measure where necessary, and plan migration to Azure.Messaging.ServiceBus according to operational risk.
Microsoft’s Azure Service Bus retirement notice confirms that WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus, and com.microsoft.azure.servicebus retire on September 30, 2026. Microsoft also states that the proprietary SBMP protocol will no longer be supported after that date, that WindowsAzure.ServiceBus uses SBMP by default, and that version 2.1 and later can use AMQP 1.0 when explicitly configured. Microsoft identifies Azure.Messaging.ServiceBus as the current .NET SDK.
The libraries do not necessarily become unusable immediately, but SBMP communication does. That distinction should drive every inventory and remediation decision. Finding an old package identifies technical debt; finding an effective SBMP connection identifies a looming outage.

Find the Workload Before Judging the Package​

The first task is not opening every Visual Studio solution. It is mapping the Windows processes that send to or receive from Service Bus, including applications whose source repositories, owners, or deployment documentation may be incomplete.
Use this sequence to build an inventory:

1. Export installed Windows services and capture their executable paths and service accounts.

Get-CimInstance Win32_Service |
    Select-Object Name, State, StartName, PathName |
    Export-Csv .\windows-services.csv -NoTypeInformation

1. Export scheduled tasks and identify executables, PowerShell scripts, batch files, and command-line arguments that may launch messaging jobs.

Get-ScheduledTask | ForEach-Object {
    $task = $_
    foreach ($action in $task.Actions) {
        [pscustomobject]@{
            TaskPath  = $task.TaskPath
            TaskName  = $task.TaskName
            Execute   = $action.Execute
            Arguments = $action.Arguments
        }
    }
} | Export-Csv .\scheduled-task-actions.csv -NoTypeInformation

1. On IIS servers, enumerate applications and their physical paths rather than searching only the default website directory.

Import-Module WebAdministration

Get-WebApplication |
    Select-Object Site, Path, PhysicalPath |
    Export-Csv .\iis-applications.csv -NoTypeInformation

1. Search source trees, deployment directories, configuration repositories, and build artifacts for retiring and current package names.

$roots = @(
    'C:\inetpub',
    'C:\Apps',
    'C:\Services',
    'D:\Apps'
)

Get-ChildItem $roots -Recurse -File -ErrorAction SilentlyContinue |
    Where-Object {
        $_.Extension -in '.config', '.json', '.xml', '.csproj', '.props',
        '.targets', '.cs', '.ps1'
    } |
    Select-String -Pattern `
        'WindowsAzure\.ServiceBus',
        'Microsoft\.Azure\.ServiceBus',
        'Microsoft\.ServiceBus\.Messaging',
        'Azure\.Messaging\.ServiceBus' |
    Select-Object Path, LineNumber, Line

1. Inspect application bin folders, publishing output, .deps.json files, packages.config, and project files. A clean source search does not prove that an older deployed Windows service was rebuilt from the repository under review.

Run discovery against deployment shares and server-local application directories as well as Git working copies. The executable registered as a Windows service or scheduled task is the operational dependency, even if its original repository or build definition is unavailable.
Treat configuration separately from code. An effective transport selection may come from an environment-specific transform, generated deployment configuration, or a shared component outside the application repository.
PowerShell inventory is discovery only. Package names and configuration strings identify candidates for inspection; they do not prove which protocol a running process uses.

---

The Package Name Is Only Half the Diagnosis​

The highest-risk result is WindowsAzure.ServiceBus without verified AMQP use. Microsoft says this package uses SBMP by default; version 2.1 and later can use AMQP 1.0 when explicitly configured.

Implementation decision box​

Finding	Decision
WindowsAzure.ServiceBus with no verified AMQP configuration	Treat it as an emergency validation and transport-remediation case. Confirm the deployed package version, test AMQP, and deploy only after end-to-end validation.
WindowsAzure.ServiceBus explicitly configured for AMQP	SBMP retirement is not the immediate protocol risk when the deployed client is verified to use AMQP, but the application still needs migration because the SDK is retiring.
Azure.Messaging.ServiceBus	The application is on the current .NET SDK. Check the rest of the message path for separate legacy producers, consumers, or tools.

Emergency continuity runbook​

For each suspected SBMP workload:

1. Assign one named owner with authority to coordinate testing and deployment.
2. Capture the deployed assembly or package version from the running application’s files or deployment record.
3. Record the effective transport configuration, including deployment transforms and external configuration sources.
4. Test AMQP in a representative environment using real message shapes and relevant network controls.
5. Deploy through normal change control, with a rollback plan and an agreed validation window.
6. Record the migration date to Azure.Messaging.ServiceBus; do not treat the AMQP bridge as permanent remediation.

The wider inventory still needs nuance:

Finding	September 30 impact	Immediate response
WindowsAzure.ServiceBus with no verified AMQP setting	Communication is at risk because its default is SBMP.	Verify the deployed version and effective configuration, then test AMQP immediately.
WindowsAzure.ServiceBus explicitly using AMQP	SBMP retirement is not the immediate protocol risk for the verified client, but the SDK becomes unsupported.	Keep the bridge temporary and schedule migration.
Microsoft.Azure.ServiceBus	Package presence alone does not establish an SBMP outage.	Confirm actual connectivity and prioritize migration by operational risk.
Azure.Messaging.ServiceBus	The workload uses the current SDK.	Verify that no legacy component remains in the same message path.

Do not add an AMQP-looking value to configuration and assume remediation is complete. For WindowsAzure.ServiceBus, verify that the deployed package is version 2.1 or later by checking package records, project references, deployment records, or the deployed assembly version. Then confirm how that specific application selects its transport. The correct implementation depends on its client-construction and configuration path.
This is a continuity measure, not a completed migration. Azure.Messaging.ServiceBus is the current SDK, while the older packages will receive no official support or updates after retirement.

A Protocol Change Still Needs Application Testing​

WindowsForum recommends treating an AMQP change as a production change rather than relying on a successful connection test. Validate the complete message path:

1. Send representative production-shaped messages from the changed client.
2. Receive them with every active consumer version.
3. Verify message bodies, application properties, identifiers, and content types.
4. Exercise the settlement and failure paths the application actually uses.
5. Test sessions, transactions, scheduled delivery, and duplicate-handling logic where applicable.
6. Run mixed-version tests when old and new producers or consumers will overlap.
7. Test the transport route permitted by the representative firewall or proxy policy.
8. Confirm that retry behavior does not duplicate business operations.
9. Include representative messages already waiting in queues or subscriptions.

Testing queued messages is a validation safeguard, not a claim that changing protocols makes existing messages unreadable. It establishes whether the bridge works with the workload’s actual backlog and message contract.
WindowsForum’s coverage of the Azure Update Delivery service-tag deprecation illustrates the broader inventory lesson. That retirement concerned a component used to facilitate Windows Update delivery through Azure Firewall, not Windows Update as a whole. Likewise, checking only the Service Bus namespace can miss a Windows client’s dependency on a retiring protocol or SDK.
WindowsForum recommends validating the first production rollout through application-level outcomes, not just Windows service state. Record whether representative sends and receives succeed, whether expected processing completes, and whether the application reports messaging failures.

Plan the Full SDK Migration Separately​

Moving to Azure.Messaging.ServiceBus should be managed as an application migration, not a blind package-reference replacement. Review the responsibilities of the existing integration and preserve the established message contract while the SDK changes.
The migration review should locate:

• Outgoing message construction.
• Body serialization and deserialization.
• Custom application properties.
• Receive and settlement behavior.
• Lock handling and long-running processing.
• Sessions and session state.
• Retry configuration and exception handling.
• Client creation, reuse, disposal, and shutdown.
• Queue, topic, subscription, and other management operations.

Avoid combining the SDK migration with an unrelated payload redesign unless the existing format blocks testing. Preserving the current contract first makes it easier to distinguish SDK migration problems from intentional schema changes.
For legacy .NET Framework services, WindowsForum recommends considering an adapter behind the application’s existing messaging interface. This can limit changes to the messaging layer, but teams should choose the design according to the application’s architecture and test coverage.
WindowsForum’s 2025 sunsetting guide frames Microsoft retirement planning as a sustained cross-product concern spanning operating systems, developer tools, applications, Azure services, and enterprise servers. Its Microsoft 365 retirement coverage similarly emphasizes that administrators must identify affected components rather than treating every announcement as a product-wide shutdown. The editorial lesson is straightforward: attach Service Bus remediation to a named application, owner, deployment path, and date—not merely to an Azure subscription.

---

Unsupported Does Not Mean Equally Safe​

A legacy SDK application verified to use AMQP does not face the same immediate protocol risk as a confirmed SBMP client. It may continue communicating after the deadline, but it will run on a retired SDK without official Microsoft support or updates.
Whether that is acceptable temporarily is an organizational risk decision. Rank each workload by verified protocol, business criticality, deployment difficulty, source availability, owner, and test coverage. Confirmed or suspected SBMP applications require urgent validation and remediation; legacy AMQP applications require controlled modernization.
By September 30, 2026, every Service Bus-connected Windows workload should either run on Azure.Messaging.ServiceBus or have documented evidence of AMQP use, a named owner, validated operational checks, and a dated migration plan. Package inventory finds candidates, but protocol validation identifies which services face the communications cutoff.

Frequently Asked Questions​

Does finding WindowsAzure.ServiceBus prove that an application uses SBMP?​

No. It identifies a high-priority candidate. Check the deployed package version, client-construction path, environment-specific configuration, and effective connectivity. WindowsAzure.ServiceBus defaults to SBMP, but version 2.1 and later can be explicitly configured for AMQP.

Is switching a legacy application to AMQP a complete migration?​

No. It can provide continuity beyond the SBMP cutoff, but the legacy SDK still retires on September 30, 2026. The long-term migration target is Azure.Messaging.ServiceBus.

Can PowerShell package searches prove the runtime protocol?​

No. They are discovery tools. They can find package references, but generated configuration, deployment transforms, wrappers, and stale binaries can make source results differ from the running application.

Should teams test messages already waiting in queues or subscriptions?​

Yes. Include representative queued messages in end-to-end validation so the changed client is tested against the real backlog and every active consumer. This is a prudent validation step, not an assertion that AMQP inherently breaks existing messages.

What should be remediated first?​

Start with WindowsAzure.ServiceBus workloads that have no verified AMQP configuration, especially critical services with difficult deployment procedures or weak ownership. Assign one owner, capture the deployed version and transport configuration, test AMQP, deploy through change control, and record the Azure.Messaging.ServiceBus migration date.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Message Transfers, Locks, and Settlement - Azure Service Bus | Microsoft Learn

   Learn how Azure Service Bus handles message transfers, locks, and settlement operations to ensure reliable message delivery and processing.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Important Changes: Azure Update Delivery Service Tag to Be Deprecated in 2024 | Windows Forum

   Azure Update Delivery service tag is a component that assists in facilitating the delivery of Windows updates to Azure Firewall. As of July 1, 2024, the...

   windowsforum.com

 

[ChatGPT]

Azure Service Bus workloads confirmed to use SBMP must move to AMQP before September 30, 2026, while applications identified only by a legacy SDK package need a separate migration and support-lifecycle review. Windows teams should inventory protocol evidence first, then map WindowsAzure.ServiceBus and Microsoft.Azure.ServiceBus dependencies without assuming that a package name proves the transport in use.
WindowsForum users have highlighted the key distinction: Microsoft’s shared September 30, 2026 deadline creates two risks. SBMP retirement threatens messaging connectivity, while support ending for legacy Azure Service Bus SDKs creates a modernization and supportability problem. Those findings should not be collapsed into one generic “legacy package” alert.

Discovery result	Required response
SBMP detected	Move to AMQP before September 30, 2026
WindowsAzure.ServiceBus or Microsoft.Azure.ServiceBus detected	Perform a migration and support-lifecycle review
Azure.Messaging.ServiceBus detected	Treat it as the current SDK family, but continue checking for legacy companion components

Package family alone does not establish protocol use.

Start With Protocol Risk, Not the Package Name​

Microsoft’s retirement announcement says applications using SBMP must move to AMQP before September 30, 2026. A confirmed SBMP dependency is therefore the highest-priority finding.
Finding an older client package is still important, but it answers a different question:

• WindowsAzure.ServiceBus identifies the Track 0 .NET client family.
• Microsoft.Azure.ServiceBus identifies the Track 1 .NET client family.
• Azure.Messaging.ServiceBus identifies the current Track 2 family.

These labels help organize the inventory. They do not, without additional evidence, prove which protocol a particular deployed process uses.
Use this decision tree:

1. Is there direct evidence that the workload uses SBMP?
   If yes, prioritize moving it to AMQP and completing production-representative testing before September 30, 2026.
2. Was WindowsAzure.ServiceBus detected?
   Record it as a Track 0 dependency and investigate the deployed application’s configuration, source, and runtime behavior. Do not infer the protocol from the package alone.
3. Was Microsoft.Azure.ServiceBus detected?
   Record it as a Track 1 dependency and open an SDK migration and support-lifecycle review. Do not classify it as protocol-safe solely from the assembly name.
4. Was Azure.Messaging.ServiceBus detected?
   Record it as the current SDK family, then check whether the same solution or host also contains an older service, plug-in, utility, or scheduled task.
5. Is the transport still unknown?
   Keep the finding open. An absence of obvious evidence is not confirmation that SBMP has been removed.

This approach avoids two errors: treating every legacy package as proof of an impending protocol outage, and treating a currently functioning workload as proof that no retirement work remains.

---

Find the Windows Services Carrying Legacy Clients​

WindowsForum’s Service Bus reports emphasize that Windows estates rarely map neatly to active Visual Studio solutions. Deployed servers may contain binaries from retired build systems, vendor installers, release archives, background services, and scheduled utilities whose repositories are no longer obvious.
That discovery pattern also appears in WindowsForum’s coverage of the Azure API for FHIR retirement: endpoint and dependency discovery must come before teams assume what kind of migration is required. The same principle applies here. Establish which executable talks to which Service Bus namespace before assigning remediation work.
Begin with source and deployment manifests. Search .csproj, packages.config, .props, .targets, and JSON files for the three package identifiers:

WindowsAzure.ServiceBus
Microsoft.Azure.ServiceBus
Azure.Messaging.ServiceBus

Use PowerShell to create an initial inventory:

Get-ChildItem C:\Apps -Recurse -File -Include `
  *.csproj,packages.config,*.props,*.targets,*.json |
  Select-String -Pattern `
  'WindowsAzure.ServiceBus|Microsoft.Azure.ServiceBus|Azure.Messaging.ServiceBus'

Then search deployed directories for matching assemblies:

Get-ChildItem C:\Apps -Recurse -File -Include `
  WindowsAzure.ServiceBus.dll,`
  Microsoft.Azure.ServiceBus.dll,`
  Azure.Messaging.ServiceBus.dll

These searches are inventory heuristics, not evidence of protocol use. A copied DLL might be unused, while a package reference may belong to a tool that never runs in production. Conversely, the main service directory may look current even though a plug-in, secondary executable, or maintenance job loads an older client.
Map Windows Service names to executable paths:

Get-CimInstance Win32_Service |
  Select-Object Name, DisplayName, State, StartName, PathName

Use PathName to locate each application directory and inspect the complete deployment tree. Repeat the exercise for:

• Task Scheduler jobs
• IIS-hosted applications
• Console utilities launched by automation
• Plug-in and shared-component directories
• Vendor products that exchange messages with the namespace
• Disaster-recovery or failover hosts
• Old release folders that may still be used for rollback

A historical WindowsForum report about Service Bus Server 1.1 update KB3030966 is a useful reminder that “Service Bus” can also refer to older on-premises components. Do not automatically classify every Service Bus-named assembly, service, or configuration file as an Azure Service Bus client. Confirm the product, executable, owner, and endpoint.

Search Configuration Without Exposing Secrets​

Search configuration stores and deployment templates for Azure Service Bus namespace endpoints, including strings containing servicebus.windows.net. Include ordinary .config and .json files, environment-variable definitions, deployment scripts, and the approved secret-management systems used by the organization.
Do not paste full connection strings into tickets or inventory spreadsheets. Record only what the remediation team needs:

• Host and executable
• Windows Service or scheduled-task name
• Application owner
• Service account
• Namespace endpoint
• Detected SDK family
• Protocol status: confirmed SBMP, confirmed AMQP, or unknown
• Evidence used for the classification
• Migration owner and target date
• Test status

Configuration searches remain discovery aids. Do not infer a protocol from the absence of a particular setting. If configuration is generated at deployment time or selected in code, the deployed files may not tell the whole story.
Source review, application logging, approved runtime diagnostics, and architecture records can help resolve unknown entries. Any protocol classification should cite the evidence actually observed rather than an assumption based on package age.

---

Treat the SDK Change as an Application Migration​

Once the protocol risk is classified, create a separate workstream for Track 0 and Track 1 dependencies. Microsoft identifies Azure.Messaging.ServiceBus as the current Track 2 SDK family, but replacing a package reference is not by itself proof that the application works correctly.
The exact test plan should come from the application’s existing behavior. Avoid assuming undocumented differences between SDK families; instead, enumerate what the workload actually does and verify those functions with the replacement.
For a sender, test representative message production, authentication, error reporting, and application-specific retry handling. For a receiver, test normal processing and every disposition or failure path the application relies on. If the workload uses sessions, scheduling, transactions, dead-letter processing, duplicate-detection assumptions, or management operations, include those features explicitly.
Mixed-version deployment also deserves testing. If old and new builds will overlap, validate that each can process the application’s real payloads and metadata. Treat this as a compatibility test requirement, not as a claim that all legacy and current clients behave identically.
WindowsForum’s reports about Windows 10 1507 and the Azure Update Delivery service tag show why lifecycle projects need separate technical and support criteria. A component may still exist or appear functional after a vendor milestone, but that does not erase the support decision. For Service Bus, document protocol remediation and SDK modernization independently.

Test Retirement Risks as Hypotheses​

Do not wait for the retirement date to discover whether monitoring can detect a messaging failure. Test the operational risks as hypotheses.
For example, determine whether a Windows Service could remain in the Running state while its Service Bus operations fail. This is a test case, not a universal Microsoft-backed behavior claim. In a controlled environment, interrupt the application’s messaging path and verify which alerts fire.
Monitoring should answer questions such as:

• Are sends and receives succeeding?
• Is processing age increasing?
• Are application retries or errors rising?
• Is dead-letter volume changing unexpectedly?
• Does the service expose a meaningful health signal beyond process state?
• Can operators connect an alert to the responsible host and application owner?

Likewise, do not assume that a Track 1 application will either stop or continue communicating after SDK support ends. The established fact is the support-lifecycle deadline. Continued operation, future compatibility, and organizational risk must be evaluated rather than promised.
Rollback plans also need testing. Before the deadline, determine whether the planned rollback build has any confirmed SBMP dependency. Do not state that rollback will categorically be impossible; instead, flag any SBMP-dependent rollback as a retirement risk that must be removed before production approval.

The Deadline Has Two Exit Criteria​

The September 30, 2026 program is complete only when it can answer two separate questions:

1. Has every confirmed production SBMP dependency been moved to AMQP?
2. Has every Track 0 or Track 1 dependency been migrated to the current SDK family or covered by a formally accepted lifecycle risk?

A single “legacy Service Bus” spreadsheet column is not enough. Confirmed SBMP findings belong at the top because Microsoft has set a protocol-retirement deadline. Legacy SDK findings require owners, migration plans, and support decisions even when the transport remains unknown or is separately confirmed as AMQP.
The immediate deliverable is a host-by-host inventory tying each Windows service, IIS application, scheduled process, and utility to its executable, namespace, SDK family, protocol evidence, owner, test results, and remediation state.

Frequently Asked Questions​

Does finding WindowsAzure.ServiceBus prove the application uses SBMP?​

No. It identifies the Track 0 package family, but package detection is an inventory heuristic rather than proof of protocol use. Investigate configuration, source, runtime evidence, and architecture records.

Does finding Microsoft.Azure.ServiceBus prove the application uses AMQP?​

Not from the supplied evidence. Record it as a Track 1 dependency and perform both a lifecycle review and any protocol verification required by the inventory process.

Is Azure.Messaging.ServiceBus the current SDK family?​

Yes. It is the Track 2 family identified in Microsoft’s migration guidance. Still inspect the host for older companion executables, plug-ins, and scheduled tasks.

What should be fixed first?​

Confirmed SBMP dependencies should receive the highest priority because Microsoft requires migration to AMQP before September 30, 2026. Unknown transports should be investigated promptly, while Track 0 and Track 1 findings should enter the SDK migration and support-lifecycle workstream.

Is a successful test message enough?​

No. Test the application’s actual send, receive, failure, recovery, monitoring, deployment, and rollback scenarios. The goal is evidence that the Windows workload operates correctly, not merely evidence that one message crossed a test queue.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Ending Support in 2026 - Microsoft Lifecycle | Microsoft Learn

   Find out which products will retire, reach end of support or move from mainstream support to extended support in 2026.

   learn.microsoft.com
2. Independent coverage: azure.microsoft.com
   
   https://azure.microsoft.com/en-us/updates/azure-service-bus-sbmp-protocol-retirement
3. Primary source: WindowsForum
   
   

   Azure Service Bus: Stop SBMP Outages Before September 30, 2026 | Windows Forum

   Microsoft’s September 30, 2026 Azure Service Bus deadline creates two different risks: Windows workloads still using SBMP will stop communicating, while...

   windowsforum.com