Running Service Bus Server on a legacy domain without a fully qualified domain name

If you’re trying to host a Service Bus Server in your own domain, you might run into an issue that’s reported in this forum thread. This post will talk about that issue and more importantly, how to workaround it.

The Issue

First let’s briefly review the issue.

1. The installation of Service Bus was successful. This issue existed since Service Bus 1.0 RTM, so it doesn’t matter whether you’re installing RTM version or CU1.
2. After the installation you try to configure Service Bus with either the wizard or PowerShell cmdlet, but that will never succeed. If you open Control Panel => Administrative Tools => Services, look at Service Bus Message Broker service, you’ll find that it’s always in Starting state and will never transition into Started state.
3. Your domain name contains only one segment, or put it another way, your domain name doesn’t contain a dot. So your domain name looks like MyDomain and your fully qualified machine name looks like MyMachine.MyDomain, instead of MyDomain.com and MyMachine.MyDomain.com.

If you meet all above 3 conditions, then read on. Otherwise you might be running into a different issue.

The cause

The root cause of the issue is the domain name doesn’t qualify as a fully qualified domain name (FQDN), while the current implementation of Service Bus server requires a FQDN to be used. A FQDN must be in the form of Prefix.Suffix, where Prefix and Suffix cannot be empty strings.

Service Bus supports Windows Server 2008 R2 and later OS, on which you won’t be able to create a domain with a name that only contains one segment. However, this is possible with Windows Server 2003. It will give you a warning but will still allow you to do so if you insist. I suppose Windows Server 2000 won’t even warn you.

The solution

The solution is fairly straightforward, just put your Service Bus server in a domain with a FQDN. However, simple as it is, in reality it might be impossible to implement as normally domain name is something out of your control.

I can’t imagine why someone would create a new domain without a FQDN, Windows Server 2008 R2 won’t let you do that anyway. But I can imagine corporates that had their domains created a decade ago and used it ever since – domain structure isn’t something that can be easily changed or is desirable to be changed in a corporate environment.

So is there a way to make it work without a FQDN? The good news is there is!

The workaround

The workaround is a bit complicated, so you’ll need to follow the steps carefully.

To avoid getting you lost in the details, first let’s look at the outline of the workaround:

1. Create a new certificate with full machine name.
2. Edit Window Fabric setting to use full machine names.
3. Re-configure Service Bus farm.

With the outline in mind, now let’s go into all the details. Let’s say the domain name is MyDomain and the machine name is MyMachine, replace them with your own domain name and machine name when applying the workaround.

1. Create a new certificate with full machine name.

1.1 Make a copy of "C:\Program Files\Service Bus\1.0\Scripts\GeneratedClusterCert.inf" to another folder, let’s say C:\Temp.

1.2 Modify the following 2 lines, replace CloudSpecificHostName and *.CloudSpecificDomainName with your full machine name.

• Before change:
  • Subject = "CN=CloudSpecificHostName"
  • _continue_ = "DNS=*.CloudSpecificDomainName"
• After change:
  • Subject = "CN=MyMachine.MyDomain"
  • _continue_ = "DNS=MyMachine.MyDomain"

1.3 Open an administrator command line prompt and go to C:\Temp, run the following command, this will generate a new certificate AppfabricSSL.cer in current directory.

• certreq.exe -cert AppServerGeneratedSBCA -new GeneratedClusterCert.inf AppfabricSSL.cer

1.4 Open the generated AppfabricSSL.cer, copy out the Thumbprint and remove any spaces in between, this will be used in step 3.

1.5 [Optional] View the certificate store and make sure the generated certificate has been installed.

2. Edit Window Fabric setting to use full machine names.

2.1 Open "C:\Program Files\Windows Fabric\bin\Fabric\Fabric.Config.1.0\Settings.xml"

2.2 Replace *.MyDomain in the following lines with full machine name.

• Before change:
  • <Parameter Name="ClusterAllowedCommonNames" Value="*.MyDomain" />
  • <Parameter Name="ClientAuthAllowedCommonNames" Value="*.MyDomain" />
  • <Parameter Name="ServerAuthAllowedCommonNames" Value="*.MyDomain" />
• After change:
  • <Parameter Name="ClusterAllowedCommonNames" Value="MyMachine.MyDomain" />
  • <Parameter Name="ClientAuthAllowedCommonNames" Value="MyMachine.MyDomain" />
  • <Parameter Name="ServerAuthAllowedCommonNames" Value="MyMachine.MyDomain" />

c. Save the file.

3. Re-configure Service Bus farm by running the following commands in SB PowerShell.

3.1 Remove-SBHost

3.2 Set-SBCertificate -EncryptionCertificateThumbprint {ThumPrint} -FarmCertificateThumbprint {ThumPrint}

• The {ThumPrint} is what you write down in 1.4

3.3 Add-SBHost

After following the steps above, now SB Message Broker service should be started in a few minutes and you can send/receive messages to/from SB queues.

Note: The workaround described here is for single machine farms only. It might also work for multi machine farms with a few modifications, but I haven’t tried that.