Release Notes for Service Bus 1.1
Updated: December 1, 2015
Applies To: Service Bus for Windows Server 1.1
The following release notes contain known issues and late-breaking information about Service Bus for Windows Server (Service Bus 1.1).
The Service Bus for Windows Server 1.1 release contains a number of new features and capabilities. This topic summarizes the new features and contains links to more information.
The Service Bus for Windows Server 1.1 release includes support for brokered messaging features that were introduced in the Microsoft Azure Service Bus SDK versions 2.0 and 2.1. For more information, see:
The following are some highlights of the new features:
AMQP 1.0: Microsoft Azure Service Bus includes support for the Advanced Message Queuing Protocol (AMQP) version 1.0. AMQP is an efficient, reliable, wire-level messaging protocol that can be used to build robust, cross-platform messaging applications.
Event-driven message programing model: This feature introduces an event-driven, or “push,” messaging programming model, which is an alternative to a receive loop. This feature supports concurrent message processing, and enables processing messages at variable rates.
Shared Access Signature (SAS): Applications can now authenticate to Service Bus for Windows Server using either Shared Access Signature (SAS) authentication or, as before, through the integrated Windows Authentication. SAS authentication enables applications to authenticate to Service Bus using an access key configured on the service namespace, or on the entity that has specific rights associated with it. You can then use this key to generate a SAS token that clients can use to authenticate to Service Bus.
Message browse: Message browsing enables you to view available messages in a queue without locking the message or performing an explicit receive operation. This is useful for debugging, as well as in scenarios that involve monitoring.
Enable and disable send/receive: This feature gives you the ability to suspend and resume sending and receiving messages to and from queues and topics. You can enable this feature by using the Microsoft.ServiceBus.Messaging.EntityStatus enumeration and setting the QueueDescription.Status property.
Auto-delete for idle messaging entities: Auto-delete enables you to set an interval after which an idle queue, topic, or subscription is automatically deleted. If no send or receive activity occurs for the duration specified in the QueueDescription.AutoDeleteOnIdle property, the entity is deleted. However, if there are receive calls on the queue or subscription, the entity is not deleted (even if it contains no messages).
Retry policy: The Client-side Retry Policy feature enables you to set a retry policy on transient message delivery errors. The library continues the retry until the limit set in the NamespaceManagerSettings.OperationTimeout property is reached.
5-node farms: Service Bus for Windows Server now supports farms with up to 5 nodes.
Windows Azure Pack for Windows Server is a collection of Azure technologies, available to Microsoft customers at no additional cost for installation into your data center. It runs on top of Windows Server 2012 R2 and System Center 2012 R2 and, through the use of the Azure technologies, enables you to offer a rich, self-service, multi-tenant cloud, consistent with the public Azure management experience.
For more information about the Windows Azure Pack, see the Windows Azure Pack page.
The following are highlights of the new features available with the Windows Azure Pack integration:
Service Bus tenant portal: Windows Azure Pack offers a rich tenant portal to manage IT resources and services. Messaging with Service Bus is one of the supported services, as well as Virtual Machines, Web sites, SQL databases, and more. The Windows Azure Pack portal enables a subscription-based user experience similar to the one found in Azure.
Service Bus admin experience: Windows Azure Pack offers an administrator experience that enables you to deploy, manage and monitor resources and services.
Azure PowerShell cmdlets: Windows Azure Pack supports Azure PowerShell management for IT services, including Service Bus.
Because the two Service Bus products, Service Bus for Windows Server and Microsoft Azure Service Bus are on different release schedules, it is not guaranteed that the latest version of the Azure SDK will work with Service Bus for Windows Server. However, because all SDK versions are supported for backward compatibility on Microsoft Azure Service Bus, all SDK versions supported by Service Bus for Windows Server are also supported by Microsoft Azure Service Bus.
Every release of Service Bus for Windows Server includes the Azure SDK, delivered via NuGet. In the event of a preview release, we will specify the exact version of the SDK that supports that release.
The following diagram illustrates the Service Bus release cadence:
The following is a list of known issues in the Service Bus for Windows Server 1.1 release.
AMQP Java clients (and all non .NET clients) cannot send or receive to/from Service Bus. For these clients to work with Service Bus for Windows Server 1.1, you must disable a hidden feature known as Redirect. Do the following:
Open SQL Server Management Studio and connect to SbGatewayDatabase.
Please exercise extreme caution when running this step, as it involves an update command on the SQL database in which all the configuration information is stored:
update dbo.ServiceConfig set ConfigValue=N'DisableRedirect' where ConfigName=N'containernameresolutionmode' and Component=N'container'
If you have performed this step, the following step is not necessary.
Broker AMQP redirect port is not added to Windows firewall exceptions. To send or receive to/from Service Bus for Windows Server 1.1 using the AMQP protocol, you must perform one extra step after the configuration: add port 45672 to the inbound and outbound firewall exceptions list by running the following commands:
netsh advfirewall firewall set rule name="Service Bus Message Broker (out)" new LocalPort="9356,5672,5671,45672" netsh advfirewall firewall set rule name="Service Bus Message Broker" new LocalPort="9356,5672,5671,45672"
Set-SBCertificate does not set the certificate binding for the RP Https endpoint. To work around this issue, follow these steps to set the RPHttpsEndpoint SSL certificate binding (after running the Set-SBCertificate cmdlet):
Open a Service Bus for Windows Server PowerShell command window and run the Get-SBFarm cmdlet.
Obtain the RPHttpsPort property, and let the port value be 9359 (which is the default Resource Provider Https port).
In the PowerShell command window, run the following command:
Obtain the thumbprint of the farm SSL certificate (this is same as the farm certificate thumbprint from the Get-SBFarm cmdlet output).
Run this command from an administrator command prompt on all nodes of the farm:
Alternatively, you can run the following PowerShell script as an administrator on all nodes that are part of this Service Bus for Windows Server farm:
Service Bus for Windows Server fails to install due to a failure in Windows Fabric setup. In some localized versions (for example, Italian), the Windows Fabric setup (a prerequisite to installing Service Bus for Windows Server) fails. This is due to an incorrect time format in which 00:00:00 is represented as 00.00.00. To work around the issue, do the following:
Start Regedit.exe and navigate to HKEY_USERS\.DEFAULT\Control Panel\International.
Change the sTimeFormat value to h:mm:ss tt.
After the installation completes successfully, you can change the registry setting back to its original value.