A duplicate name exists on the network

There I was, doing some menial tasks associated with validating a full HA, multiple geographical site deployment.  We had just got the final Edge pool up, and were checking mobility client connections and functions.  In walks my client counterpart and he wants to deploy the monitoring server databases.  Previously the customer had modified the topology to include monitoring per pool, published the topology, and had reported that the databases did not install.

Easy-peasy says I.  So we opened the Topology Builder and worked through the process to deploy just a database.  We carefully chose our target server, changed the default locations for the data and the logs. For those readers who are dying to know how to accomplish this after having the pools already installed, here is a quick primer using Topology Builder.

(by no means is this an authoritative guide to installing monitoring databases – if you need that see this)

Adelante!  From the Topology Builder….

Select the SQL server you want, make sure it is highlighted, then click on advanced.

If your DBA does not care, you can leave these fields blank, if the DBA does care, then you will need to get with him/her and figure this out:

At this point, you are ready to go:

…and we were rewarded with the following announcement.

“You were not connected because a duplicate name exists on the network.”

In defense of our failure, the error message was in a very nice color of red.  In honor of that detailed bit of programming, you will note that I have colored my error message in the same brilliant hue.

We were using a service account that was a domain admin, had local logon rights to the target SQL server and was an SA equivalent on the target SQL server.  We double checked membership in the CSAdministrator and RTCUniversalServerAdmins groups. The SQL server was pingable.  The environment is using an alias for the SQL server FQDN.  So we verified that the FE pool member from which we were running PowerShell could see and ping the SQL server by FQDN, IP, and CName.  All good.  We also did a little judicious DNS peeking to make sure that a duplicate name did not exist.

So we tried the process again, but this time I brightly used the PowerShell cmdlet.

Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SQLServer.FQDN –Verbose

Failure, but the verbose option gave us another pretty red error with a bit more information…

WARNING: Install-CsDatabase failed.
WARNING: Detailed results can be found at "C:\Users\SVC_Lync\AppData\Local\Temp\5\Install-CsDatabase-201de519-f3ac-4f0f-a221-b0cacc897e27.html".
Install-CsDatabase : Command execution failed: You were not connected because a duplicate name exists on the network. If joining a domain, go to System in Control Panel to change the computer name and try again. If joining a workgroup, choose another workgroup name.

Not so good.

Having already checked permissions and names and DNS, we then turned to Bing’ing and the ubiquitous Google-fu.  After some detailed searching, some boring reading, and superfluous checking of various settings, I stumbled across this on Mark Menasi’s forum.  While it did not exactly apply, it was certainly worth a shot (after all, nothing else was working).  After a little discussion in which we decided on a plan to unwind this registry hack if results did not meet expectations, we did the following to the demon SQL server in question:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
Value name: DisableStrictNameChecking
Data type: REG_DWORD
Radix: Decimal
Value: 1

We then were successful with the install-csdatabase cmdlet.  LCsCdr and QoEMetrics databases are installed and we have data flowing.

YMMV.