Tag Archives: numeric domain

hands up who’s got an all numerical domain suffix!

By “all numerical domain suffix”, i mean something like 1234.com, or server.567.pants.local. Does this mean you? Got exchange 2010? Wanna buy a DAG?

Cue maniacal laughter.

If you have an all numerical domain suffix, and you try to implement Database Availability Groups in Exchange 2010, you will probably experience a fail:

“blahblahblah.1234.com is not an acceptable witness server name. You must specify a host name or fully-qualifed domain name for the witness server.
Parameter name: FileShareWitnessServerName”.

And in the log there’ll be something similar to this:

[2012-08-13T010:38:27] WriteError! Exception = Microsoft.Exchange.Management.Tasks.DagFswUnableToParseWitnessServerNameException: The task was unable to use the specified witness server. Error: “blahblahblah.1234.com” is not an acceptable witness server name. You must specify a host name or fully-qualifed domain name for the witness server.
Parameter name: FileShareWitnessServerName
at Microsoft.Exchange.Management.Common.FileShareWitness.Initialize()
at Microsoft.Exchange.Management.SystemConfigurationTasks.AddDatabaseAvailabilityGroupServer.CheckFswSettings()

Ouch. Then you’ll get all distressed and google the error, and you’ll probably find that there is next to nothing on it, because no-one uses all numeric domain suffixes (suffices?). There’s a couple of threads on technet, which are confusing, and that’s your lot, pretty much.

Until June, anyway. Scott Schnoll did a marvellous piece at TechEd 2012 which includes an explanation of the error (it’s a bug…), when it will be fixed (no date as yet…) and how to fix it (use a different server). Importantly, he also mentioned how NOT to fix it (CNAME). The bit you’re after is about 55 minutes in. You’ll probably want to listen to the section that follows it carefully as well, as it explains a far more common problem that you will probably hit once you’ve got a machine that you can use as a FSW.

Mr Schnoll:


Other ways to fix it that don’t work:

Editing hosts files to point spurious FQDN to real IP address

The two methods we came up with:

1 – The one we used:

  1. Created a new server (DAGWitness)  and added to the 1234.comdomain
  2. Changed the FQDN of the DAGWitness to dag.local
  3. Added the Exchange Trusted Subsystem group to DAGWitness\Administrators group
  4. Added <ip addresses of DAGWitness>  DAGWitness.dag.local to the mailbox servers hosts files.
  5. Unchecked Register this connection’s address in DNS in the IPv4 properties (may have to delete DNS record if it has been created)
  6. Disabled the Windows Firewall on the DAGWitness server.
  7. Created DAG.
  8. Added DAG members.

2 – My solution. I suspect this is far more robust;

  1. Create a new server in a workgroup
  2. Install DNS services
  3. Create a new domain with forwarders for AD
  4. Create forwarders for new domain in AD
  5. Fritz permissions on the new server so ETS can create the share
  6. Create DAG

will it work? who knows – I have suspicions about the first method, and manually editing hosts files always sends a shiver down my spine. What happens in five years time when everyone who knows about the entry is gone? However it got the DAG installed, and, as this is a three-node DAG, I’m not sure anyone cares too much about the FSW anyway. Not until the primary site fails, anyway…