- To contain Notification Hubs then you must explicitly set the NamespaceType property to "NotificationHub"
- To contain Notification Hub & a messaging entity then you must create two namespaces - one to house Notification Hubs and another for messaging entities. Note that this is same as the existing portal behavior.
- To contain Messaging you can optionally set the NamespaceType property to “Messaging”.
Azure Service Bus – ‘NamespaceType’ default value change
Posted on October 17, 2014
Recently we announced that we are splitting the user experience between Service Bus and Notification Hubs to enable a better experience for Notification Hubs. Following up on the portal changes described in the previous blog post which are already in production for more than a month now, today we are announcing changes to the Create Namespace Service Bus PowerShell cmdlet (which ships with Azure PowerShell) and Create Namespace REST API. So if you are using the PowerShell cmdlets or REST API directly to create a Service Bus namespace, then these upcoming changes may impact you so keep reading ahead. Along with the portal changes - we had introduced a NamespaceType property on the Namespace. We had ensured in our service backend that customers who are using REST API or PowerShell to create a namespace will be able to contain both Notification Hub and Messaging entities (e.g. Queues, Topics, Relay, Event Hub). This was done, as indicated in the previous post, to allow customers to gradually transition off and start providing NamespaceType explicitly. We are now making the default of NamespaceType to be 'Messaging' to align with the Portal behavior. This means that if you are creating a namespace via PowerShell or REST API: