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.

Comments

• Anonymous
  July 12, 2013
  Hi. What kind of modifications should I do to use this workaround for multi machine farm?

• Anonymous
  September 12, 2013
  This worked

• Anonymous
  March 03, 2014
  What if you don't have a domain? Is this an active directory domain? I use Service Bus 1.1. On one machine (my home computer - Win7 Home), I don't have a domain and I get the error described above (by your post)(The borker service stucks at startup). Creating a domain is something that I am not familiar with. On another machine with a domain (Win7 Pro), it fails to start the "Service Bus Gateway" service. To sum it all up, no matter what machine I use, it seems that the configuration wizard manages to find a reason to fail starting a service. Any suggestions are welcome. :)

• Anonymous
  March 03, 2014
  "On another machine with a domain (Win7 Pro), it fails to start the "Service Bus Gateway" service." By "fails" I mean that the service stucks at startup (once again).

• Anonymous
  March 03, 2014
  Finally, I forgot to metion that I try to use an account that doesn't belong to a domain. When I do try to use a domain account, the wizard claims that the password/username is wrong (while it deosn't seem to be the case). (As you can see, I am a little bit lost here...)

• Anonymous
  March 03, 2014
  "..the wizard claims that the password/username is wrong.." Correction: I have the impression that it said sth along these lines : "This is not a valid account for this job."

• Anonymous
  March 03, 2014
  ServiceBus.Gateway crashing: Application: Microsoft.ServiceBus.Gateway.exe Framework Version: v4.0.30319 Description: The application requested process termination through System.Environment.FailFast(string message). Message: Failed to start Service Bus Gateway Service. Stack:   at System.Environment.FailFast(System.String, System.Exception)   at Microsoft.ServiceBus.Gateway.Gateway.OnStart(System.String[])   at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(System.Object)   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()   at System.Threading.ThreadPoolWorkQueue.Dispatch()

• Anonymous
  March 03, 2014
  "Failure in adding ServiceBus user in the local group BUILTINAdministrators. Please add the user manually." The user WAS in this group. Go figure....

• Anonymous
  March 03, 2014
  The comment has been removed

• Anonymous
  March 07, 2014
  Now it won't work... social.msdn.microsoft.com/.../service-bus-11-wont-work-on-other-ports Go figure...

• Anonymous
  December 21, 2014
  duplicate localhost entries in the host file caused this issue for me - removed the duplicates and it worked for me..