Service Bus https://docs.microsoft.com/archive/blogs/servicebus/feed.xml Wed, 06 Feb 2019 21:43:27 GMT en-US hourly 1 Emitting Empty Avro Files Now Optional on Azure Event Hubs Capture https://docs.microsoft.com/archive/blogs/servicebus/emitting-empty-avro-files-now-optional-on-azure-event-hubs-capture Tue, 05 Feb 2019 23:13:01 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2445 Turn off Emitting Empty Avro Files on Capture through Azure Portal If you do not have an Event Hub, check out Event Hubs documentation to create a new Event Hub. If you already have an Event Hub, turn on Capture and select your Capture Provider. Check or uncheck the “Do not empty emit empty files when no events occur during the Capture time window” option according to your preference.

Stay tuned on enabling this property using ARM template, CLI/Powershell (coming soon)!

 ]]> Enforcing TLS 1.2 use with Azure Service Bus https://docs.microsoft.com/archive/blogs/servicebus/enforcing-tls-1-2-use-with-azure-service-bus Thu, 22 Nov 2018 00:06:31 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2395 Long-term commitment to supporting protocols and protocol versions is a key expectation customers have from commercial cloud services. Deployed solutions, and especially widely deployed client applications that are often operated outside the original developer’s control, are expected to not become spontaneously broken and cut off from cloud services by protocols being retired.  When it comes to long-term support, security protocols such as Transport Layer Security (TLS, colloquially also still referred to as SSL) are the toughest to manage, because information security professionals rightfully push to expediently upgrade to the latest versions at the earliest time – with information security policies reflecting this – while there are significant client deployments “out there” which cannot be easily upgraded to that latest version, often also due to platform limitations. “Just change the code to the latest runtime and recompile” is often not a practical option for a variety of reasons.  Azure Service Bus is one of the oldest services in Azure, with some of its existing protocol surface area in active use by customers dating back to even before commercial availability in 2010, and there are quite a few applications that have been built and deployed years ago using TLS 1.0 and are considered by ISVs and/or their customers to “just work”, even if we here at Microsoft disagree from a security policy perspective. TLS 1.0 is problematic, but for some customers or their clients not problematic enough to rush to retire all uses of it in older systems. That’s why we still offer TLS 1.0 and TLS 1.1 as an endpoint option.  That all said: If application deployments under your control or watch are still relying on TLS 1.0 or TLS 1.1, those are on borrowed time. The clock is ticking loudly and many customers who are known to have such dependencies have already received or will receive communication from Azure to that effect; the Azure platform will retire TLS 1.0 and TLS 1.1 as a matter of global policy all at the same time for services that still support it.  Even while TLS 1.0 and TLS 1.1 remain an option on the Service Bus gateways, your own applications can ensure to be in full compliance with current policies and always use TLS 1.2. The TLS protocol version and the TLS cipher suites are ultimately always a client choice to make, and the client can always refuse to communicate further if the offered capabilities are outside of its desired compliance framework.  

Enforcing use of TLS 1.2 with in-support clients 

If your Service Bus clients are up to date, you are generally using TLS 1.2.  If you are using any version of the official .NET Standard client (Microsoft.Azure.ServiceBus on Nuget) or version 3.4.3 or later of the .NET Framework client (WindowsAzure.ServiceBus on Nuget) and you are using the .NET Framework 4.7.1 or newer, your application will automatically follow the .NET Framework guidance model for TLS and always follow the OS configuration settings and respective .NET Framework overrides. Current versions of Windows default to using TLS 1.2.  For .NET Framework 4.6, you will have to enforce the use of TLS 1.2 in the startup of your application by setting  

        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 

or by enforcing the use of HTTPS tunnelling (see further below).  If you are using the official Java client (azure-servicebus on Maven), the client will automatically follow the Java platform rules for enforcing TLS 1.2, where TLS 1.2 is the default.  If you are using a custom AMQP 1.0 client, refer to the respective project documentation for how to enforce TLS 1.2 use. The Microsoft lower-level AMQP libraries for .NET (Microsoft.Azure.Amqp and AmqpNetLite) follow the .NET Framework guidance and default to TLS 1.2. The Apache Qpid Proton AMQP libraries generally default to TLS 1.2 today. 

Enforcing use of TLS 1.2 with out-of-support clients 

The only scenarios where enforcing use of TLS 1.2 is substantially trickier involve using out-of-date clients where it’s impossible to follow the .NET Framework guidance to upgrade to .NET 4.7.2.  If you are using the .NET Framework client (WindowsAzure.ServiceBus on Nuget) with version 4.5.x of the .NET Framework and you are using the AMQP transport, you must use version 3.4.3 of that client or later to enforce the use of TLS 1.2.  If you are instead using the (default) NetMessaging transport, which is based on WCF, the .NET Framework versions 4.5.x and earlier have TLS version 1.0 hardcoded for the native WCF transport option, but for Service Bus you can circumvent this when you enforce HTTPS tunnelling, which follows the operating system default rules.   If you don’t have source code access or can’t change your deployment, and the client does not explicitly override the ServiceBusEnvironment.SystemConnectivity.Mode setting to ConnectivityMode.Tcp, you can simply enforce HTTPS tunnel usage by suppressing outbound connectivity on ports 9350-9354 with a local firewall.   You can enforce HTTPS usage by setting          ServiceBusEnvironment.SystemConnectivity.Mode=ConnectivityMode.Https 

Supported Cipher Suites 

A key concern with older implementations of TLS is that they prefer outdated cipher suites. The Service Bus TLS configuration only offers the following options, in order of service-side preference.   The last three options are only temporarily retained for compatibility with some of the oldest clients. 
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 
  • TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 
  • TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 
  • TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) 
  • TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 
  • TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 
 

Summary 

Please verify that your applications are configured to use TLS 1.2. If they do, and this is purely a client choice, your applications will be in compliance with all policies that require TLS 1.2.   While TLS 1.0 and TLS 1.1 is still an endpoint option on Service Bus, you should consider it urgent to move existing applications using out-of-support clients to TLS 1.2, because its foreseeable that these versions will be retired from use across all Azure cloud services.  ]]> Deprecating Service Management support for Azure Service Bus, Relay and Event Hubs https://docs.microsoft.com/archive/blogs/servicebus/deprecating-service-management-support-for-azure-service-bus-relay-and-event-hubs Thu, 01 Nov 2018 05:36:50 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2375 Resource Manager, our next-generation cloud infrastructure stack, is fully replacing the "classic" Service Management model. As a result, Service Management REST APIs and support for Service Bus, Relay, and Event Hubs will be retired on November 1, 2019. As with all changes of this type, we’re providing 12 months’ notice so you have adequate time to modify your services that use these APIs. For identification, these APIs have management.core.windows.net in the URI.  To continue using Service Bus, Relay, and Event Hubs, please move to Resource Manager by October 31, 2019. We encourage all customers who are still using Service Management APIs to make the switch soon to take advantage of the additional benefits of Resource Manager, which include resource grouping, tags, a streamlined deployment and management process, and fine-grained access control using RBAC. For more information on Azure Resource Manager vs Service Management, please see the TechNet Blog. For more information on Service Management and ARM APIs for Azure Service Bus, Relay and Event Hubs, please see our Azure Rest API documentation. ]]> Mixing Standard and Premium Service Bus with VNet Service Endpoints https://docs.microsoft.com/archive/blogs/servicebus/mixing-standard-and-premium-service-bus-with-vnet-service-endpoints Tue, 03 Jul 2018 22:54:58 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2355 VNET Service Endpoints for Azure Service Bus. There is an important caveat for this feature: once you enable a service endpoint for Service Bus you cannot mix Standard and Premium tiers on that VNet. Because Service Bus Standard does not support VNets the endpoint will be restricted to Premium namespaces only and the VNet will block traffic to the Standard namespace. As a result, for now, please do not enable VNet service endpoints in applications that mix Standard and Premium Service Bus namespaces. If you’re interested in mixing Premium and Standard Service Bus namespaces in the same VNet we’d like to hear from you. ]]> IP Filtering for Event Hubs and Service Bus https://docs.microsoft.com/archive/blogs/servicebus/ip-filtering-for-event-hubs-and-service-bus Wed, 27 Jun 2018 21:26:14 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2305
  • Rules allow you to specify accept and reject actions on IP masks
  • The rules work with IPv4 addresses
  • Rules are applied to the namespace level
  • You can have multiple rules and they are applied in order
  • The first rule that matches the IP address determines the accept or reject action
  • Requests from IPs that are rejected receive an unauthorized response
    • Today this features is available in the Azure portal (screenshot below) at the Event Hubs or Service Bus namespace level or via an ARM template Want tighter control of who is accessing your Event Hubs or Service Bus queues and topics? Give IP Filters a try today for your Service Bus or Event Hubs namespace!]]>         Azure Event Hubs and Service Bus Virtual Network Service Endpoints in preview https://docs.microsoft.com/archive/blogs/servicebus/azure-event-hubs-and-service-bus-virtual-network-service-endpoints-in-preview Wed, 27 Jun 2018 21:23:38 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2265 This blog was co-authored by Anitha Adusumilli , Principal Program Manager, Azure Networking and Sumeet Mittal, Program Manager, Azure Networking. Azure Event Hubs, a highly reliable and easily scalable data streaming PaaS offering has been prolific this year with new features such as Availability Zones and a big investment into Open Source with enabling support for Apache Kafka. Azure Service Bus, a feature rich cloud messaging PaaS offering that also just offered support for Availability Zones has also been busy. Today, both services are announcing public preview of Virtual Network Service Endpoints. This new feature adds to the security and control Azure customers have over their workload environments today. Now, traffic from your Virtual Network to your Premium Service Bus namespaces and Standard or Dedicated Azure Event Hubs namespaces can be kept secure from public Internet access and completely private on the Azure backbone network. Azure Event Hubs and Service Bus are joining the growing list of Azure services that have enabled Virtual Network Service Endpoints. Important info
    • Offered with Dedicated and Standard Event Hubs pricing plans as well as Premium Service Bus
    • The feature is offered for free aside from the usual Event Hubs and Service Bus costs
    • Available in all public Azure regions
    Azure Portal To enable this feature from the Azure portal you can visit the Virtual Networks blade, select or create the Virtual Network you want and then navigate to the Service endpoints section. Then enable the Microsoft.EventHub service endpoint or the Microsoft.ServiceBus endpoint. You can also create new virtual networks and virtual network rules from the Event Hubs or Service Bus namespace overview blades. Azure Resource Manager Also you can create Virtual Network rules using an ARM template. For example, the Service Bus template for creating Virtual Network rules looks like the following: { "$schema":"https://schema.management.azure.com/schemas/2014-04-01-preview/deploymentTemplate.json#", "contentVersion":"1.0.0.0", "parameters":{ "namespaceName":{ "type":"string", "metadata":{ "description":"Name of the namespace" } }, "vnetRuleName":{ "type":"string", "metadata":{ "description":"Name of the Virtual Network rule" } }, "virtualNetworkSubnetId":{ "type":"string", "metadata":{ "description":"subnet Azure Resource Manager ID" } } }, "resources": [ { "apiVersion": "2018-01-01-preview", "name": "[concat(parameters('namespaceName'), '/', parameters('vnetRuleName'))]", "type":"Microsoft.ServiceBus/namespaces/VirtualNetworkRules", "properties": { "virtualNetworkSubnetId": "[parameters('virtualNetworkSubnetId')]" } } ] } Next Steps For additional information take a look at our documentation for Service Bus service endpoints and Event Hubs service endpoints. As a bonus, if you are interested in a feature that allows you to create private connections to your on-premises infrastructure check out Service Bus IP Filtering or Event Hubs IP Filtering.]]>         Azure Service Bus is now offering support for Availability Zones in preview https://docs.microsoft.com/archive/blogs/servicebus/azure-service-bus-is-now-offering-support-for-availability-zones-in-preview Fri, 22 Jun 2018 00:59:01 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2235 disaster recovery features offers high availability and fault tolerance that can withstand zone and regional outages. Availability Zone support for Service Bus takes another step in the direction of keeping to our commitments in making sure customer cloud messaging between applications and services run as smoothly as possible.

    What regions will this be offered in during preview?

    • Central US
    • East US 2
    • France Central
    Support for additional regions will be offered soon. Learn more about Availability Zones.

    How can you enable AZ on your Service Bus premium namespace?

    You can enable Availability Zones on new namespaces only, we do not support migration of existing namespaces. If using an ARM template to create a Service Bus Premium namespace it is as simple as specifying an AZ supported region and setting the zoneRedundant property to true in the template: You can also enable zone-redundancy by creating a new namespace in the portal as shown below. It’s important to note that you cannot disable zone redundancy after enabling it on your namespace.

    Learn more about Azure Service Bus.

    ]]>         ACS Migration Guide https://docs.microsoft.com/archive/blogs/servicebus/acs-migration-guide Fri, 18 May 2018 01:22:00 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2215 Previously Service Bus namespaces could contain Queues/Topics, Event Hubs, Relays, or Notification Hubs. You may still be affected by the ACS deprecation if you are using an older namespace. For the scope of the below article, "Service Bus namespaces" includes older, mixed-entity namespaces. Access Control Service PowerShell has been released and is available here. This provides a direct replacement for the ACS functionality in the classic Azure portal.  Throughout this guide, ACS PowerShell examples have been added.   Access Control Service (ACS) is being retired soon (see blog post). Customers who are using ACS authorized Service Bus namespaces will need to migrate to Shared Access Signature (SAS) authorization prior to November 7, 2018 to protect themselves from unnecessary downtime. We recommend following the below steps to start your migration to SAS authorization, which will be the supported model going forward.

    1. Identify your ACS-Authorized Namespaces

    Check to see if you have an ACS buddy namespace provisioned. For a Service Bus namespace typollaktestACS, there will be typollaktestacs-sb ACS buddy namespace provisioned if you are using ACS authorization. You can run the below commands to see if an ACS namespace exists (or batch many together in one script): 
    PS C:\Users\typollak> nslookup typollaktestacs-sb.accesscontrol.windows.net
....
Non-authoritative answer:
Name:   aad-ac-prod-sn1-001.cloudapp.net
Address: 70.37.92.127
Aliases: typollaktestacs-sb.accesscontrol.windows.net
         prod-sn1-001.accesscontrol.windows.net

    PS C:\Users\typollak> Connect-AcsAccount
Token authenticated successfully
PS C:\Users\typollak> Get-AcsNamespace -SubscriptionID 27150243-299a-426c-ba0b-68dd10cbd7aa

Name ManagementUrl Region State
---- ------------- ------ -----
typollaktestACS-sb https://typollaktestacs-sb.accesscontrol.windows.net USSC Active
    If the ACS namespace resolves or the Get-ACSNamespace cmdlet returns values, continue with the below steps. If nslookup fails with an error like 'Non-existent domain', or if no results are displayed via Get-ACSNamespace, you are not using ACS.

    2. Identify if You Are Using ACS in your Application

    The presence of an ACS buddy namespace does not necessarily mean that ACS authorization is being used. Even if an ACS buddy namespace is present, SAS authorization can be used. The following are some of the ways to determine if your Service Bus solution is using ACS.
    • Check your solution code for the following strings
      • "SharedSecretIssuer"
      • "SharedSecretValue"
      • "owner"
      • "SharedSecretTokenProvider" class references
     
    • Use Fiddler with decryption turned on (or any other network capture tool) to check for traffic to ACS. Look for traffic to <namespace>-sb.accesscontrol.windows.net.
     
    • Typical ACS errors have a reference to an error of form 'ACSxxxx' where xxxx represents a specific error code number.

    • You can use the Disable/Enable-ACSNamespace PowerShell cmdlets to disable/enable your ACS namespace like you would have in the classic Azure portal.  This could cause downtime for your service, but is a quick way to see where you rely on ACS.  Note: you must include the "-sb" extension.
    PS C:\Users\typollak> Disable-AcsNamespace -Name "typollaktestACS-sb"
Name Region
---- ------
typollaktestACS-sb USSC

PS C:\Users\typollak> Enable-AcsNamespace -Name "typollaktestACS-sb"
Name ManagementUrl Region
---- ------------- ------
typollaktestACS-sb https://typollaktestacs-sb.accesscontrol.windows.net USSC

    3. Migration Scenarios (from here)

      Unchanged Defaults If you are using the ACS default settings, you can just replace the ACS connection string with the SAS connection string provided in the Azure portal (https://portal.azure.com). Change your ACS connection string: 
    Endpoint=sb://<namespace>.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=[snip]
    To your SAS connection string: 
    Endpoint=sb://<namespace>.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=wG46rtpDCQRGRVnBsTx+eRbYQwkda0slQF1bHy1FBoA=
      You can see your connection strings via PowerShell using the Get-AzureRmServiceBusAuthorizationRule cmdlet: 
    PS C:\Users\typollak> Get-AzureRmServiceBusAuthorizationRule -ResourceGroupName $ResourceGroup -Namespace "typollaktestacs"

Id : /subscriptions/27150243-299a-426c-ba0b-68dd10cbd7aa/resourceGroups/Default-ServiceBus-SouthCentralUS/providers/Microsoft.ServiceBus/namespaces/typollaktestacs/AuthorizationRules/RootManageSharedAccessKey
Type :
Name : RootManageSharedAccessKey
Location :
Tags :
Rights : {Listen, Manage, Send}

Id : /subscriptions/27150243-299a-426c-ba0b-68dd10cbd7aa/resourceGroups/Default-ServiceBus-SouthCentralUS/providers/Microsoft.ServiceBus/namespaces/typollaktestacs/AuthorizationRules/Rule2
Type :
Name : Rule2
Location :
Tags :
Rights : {Manage, Listen, Send}

Id : /subscriptions/27150243-299a-426c-ba0b-68dd10cbd7aa/resourceGroups/Default-ServiceBus-SouthCentralUS/providers/Microsoft.ServiceBus/namespaces/typollaktestacs/AuthorizationRules/Rule3
Type :
Name : Rule3
Location :
Tags :
Rights : {Manage, Listen, Send}
    After choosing the key with the specific rights you want, get the key values using Get-AzureRmServiceBusKey: 
    PS C:\Users\typollak> Get-AzureRmServiceBusKey -ResourceGroupName $ResourceGroup -Namespace "typollaktestacs" -Name "Rule2"
PrimaryConnectionString       : Endpoint=sb://typollaktestacs.servicebus.windows.net/;SharedAccessKeyName=Rule2;SharedAccessKey=WYw3Hwu7OTSgiIrbVK2v0V+GSIXJwsGlO0E8b/FegeI=
SecondaryConnectionString     : Endpoint=sb://typollaktestacs.servicebus.windows.net/;SharedAccessKeyName=Rule2;SharedAccessKey=YCV+s+JkGUp/5UfKg5lLC/zHl7sFLmXX86AGv01cUUY=
AliasPrimaryConnectionString   :
AliasSecondaryConnectionString :
PrimaryKey                     : WYw3Hwu7OTSgiIrbVK2v0V+GSIXJwsGlO0E8b/FegeI=
SecondaryKey                   : YCV+s+JkGUp/5UfKg5lLC/zHl7sFLmXX86AGv01cUUY=
KeyName                       : Rule2
      You should also replace all SharedSecretTokenProvider references with a SharedAccessSignatureTokenProvider object, and use the SAS policies/keys from the Azure portal instead of the ACS owner account: From (ACS): 
    MessagingFactory mf = MessagingFactory.Create(runtimeUri, TokenProvider.CreateSharedSecretTokenProvider(issuerName, issuerSecret));
    Change to (SAS): 
    MessagingFactory mf = MessagingFactory.Create(runtimeUri, TokenProvider.CreateSharedAccessSignatureTokenProvider(keyName, key));
    Simple Rules If the application uses custom service identities with simple rules, the migration is straightforward in the case where an ACS service identity was created to provide access control on a specific queue. This scenario is often the case in SaaS-style solutions where each queue is used as a bridge to a tenant site or branch office, and the service identity is created for that particular site. In this case, the respective service identity can be migrated to a Shared Access Signature rule, directly on the queue. The service identity name can become the SAS rule name and the service identity key can become the SAS rule key. The rights of the SAS rule are then configured equivalent to the respectively applicable ACS rule for the entity. You can make this new and additional configuration of SAS in-place on any existing namespace that is federated with ACS, and the migration away from ACS is subsequently performed by using SharedAccessSignatureTokenProvider instead of SharedSecretTokenProvider. The namespace does not need to be unlinked from ACS. You can assign SAS keys with Manage, Send, or Listen privileges via the Azure portal or the Set-AzureRmServiceBusAuthorizationRule cmdlet.   
    PS C:\Users\typollak> Set-AzureRmServiceBusAuthorizationRule -ResourceGroupName "Default-ServiceBus-SouthCentralUS" -Namespace "typollaktestacs" -Name "Rule11" -Rights "Listen"

Id       : /subscriptions/27150243-299a-426c-ba0b-68dd10cbd7aa/resourceGroups/Default-ServiceBus-SouthCentralUS/providers/Microsoft.ServiceBus/namespaces/typollaktestacs/AuthorizationRules/Rule11
Type     :
Name     : Rule11
Location :
Tags     :
Rights   : {Listen}
      Relay Specific Guidance If you are using Relays, you might find something like below in your config file: 
    <behavior name="sharedSecretClientCredentials">
  <transportClientEndpointBehavior>
      <tokenProvider>
           <sharedSecret issuerName="ISSUER_NAME" issuerSecret="ISSUER_SECRET"/>
      </tokenProvider>
  </transportClientEndpointBehavior>
</behavior>
    Please change this to below, with the appropriate key name/value from your Shared Access Signature Policy in the portal. 
    <sharedAccessSignature keyName="KEY_NAME" key="KEY_VALUE"/>
      Please open a Service Bus support ticket here for urgent needs and immediate support. Additional questions can be sent to ACS-SB@microsoft.com.  

    FAQ

     

    How do I map my ACS access rules to SAS?

    • The general circumstances and solutions for this are outlined here.
    • One caveat is that at any level (namespace/entity), there is a limit of 12 SharedAccessAuthorization rules. If you need more, we recommend using SAS Tokens . We have a sample on how to create a Security Token Service (STS) to issue SAS Tokens to trusted applications. The sample is meant to serve only as a guideline, and can be easily modified for your scenarios.
     

    I don't use C#, what are my options?

    ]]>         Premium Messaging: High Performance Without Partitions https://docs.microsoft.com/archive/blogs/servicebus/premium-messaging-high-performance-without-partitions Wed, 16 May 2018 18:03:27 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2195 To summarize some important aspects of this:
    • Existing entities with partitions in Premium will not be changed, they will remain the same
    • New entities that are created with SDKs, CLI, PowerShell, ARM, Azure portal will be non-partitioned entities by default (without the ability to enable partitions)
    • There is no decrease in availability due to one partition, it will be just as good as partitioned entities
    • DO NOT set enable partition with ARM templates, by default Service Bus will not allow this
    • For Service Bus Standard Messaging customers we still encourage partitioning your entities
    Additional Benefits
    • A big benefit is that you no longer have to set partition keys for features like sessions, transactions, send via, and duplicate detection
    • If you use SignalR with Service Bus as the backbone it will now work seamlessly with Premium Messaging as SignalR only supports non-partition entities
    Happy Messaging!]]>         AMQP transaction support and Send Via are now generally available https://docs.microsoft.com/archive/blogs/servicebus/amqp-transaction-support-and-send-via-are-now-generally-available Tue, 15 May 2018 21:06:08 GMT https://blogs.msdn.microsoft.com/servicebus/?p=2185 https://github.com/Azure/azure-service-bus/tree/master/samples/DotNet/Microsoft.Azure.ServiceBus/TransactionsAndSendVia If you are new to the Transaction or the Send Via features, you may want to go through the official documentation. The feature is available across all regions and in Standard as well as our Premium SKU. It is available for both the .Net Standard and Java client. A Java sample will be available on GitHub shortly. Some key things to note:
    • Transactions cannot span more than one connection context, so your code needs to reflect that.
    • Receive is not part of the transaction. Only operations which do something with the message on the broker are part of the transaction. These are: Send, Complete, Dead letter, Defer. Receive itself already utilizes the Peek lock concept on the broker.
    • Send Via lets you cross entity boundaries within a transaction scope: A single transaction cannot theoretically span across entities. To support cross entity transaction, you can now send a message to a destination-queue via another queue. The transaction will be performed on the via-queue, and once successful, the message will be forwarded/transferred to its intended destination.
    Enjoy this great new feature!]]>