Another "Failure to access the DBMS server."

[PaulHuffman]

I have new hardware running  SQL Server 2012 R2 and I'm trying to create my first Enterprise geodatabase on it but all I can get back using the two client machines I have running Desktop 10.3.1 and SQL Native Client is "Failure to access the DBMS server"  Don't understand this because I didn't have this problem with my install at a different location a couple months ago, and I just completed the instructor led course Deploying and Maintaining a Multiuser Geodatabase earlier this week.

My DBA set up the new servers as virtual servers on the same unit.  From my DBA I got:

  NSQL 192.168.3.222

  Administrator: *********

  SQL Server instance MSSQLSERVER

  sa: *********

  NSMAP 192.168.3.223

  Administrator: ************

But when I try to create my first geodatabase, I get Failure to access the DBMS server. If the SQL Native Communications driver were missing, or wrong, I think I would get a different error message,  something about communication to the SQL server. (How does one tell if the SQL Native client is installed on a client PC? Don't see it in Data Sources.)  I wondered if Windows firewall was blocking, but I turned off public and private firewall temporarily on the client NSMAP and the SQL Server NSSQL, no change. Also tried the trick to modify the host file on the client machine to resolve the SQL host name, no change.

I pulled the Create Enterprise Geodatadata tool results into a python window to make it easier to repeat iterations with minor changes. But it also makes it easy to copy and paste my attempt as text.

>>>

arcpy.CreateEnterpriseGeodatabase_management(database_platform="SQL_Server",

instance_name="MSSQLSERVER", database_name="Orthos", account_authentication="DATABASE_AUTH", database_admin="sa", database_admin_password="**********", sde_schema="SDE_SCHEMA", gdb_admin_name="sde", gdb_admin_password="sde", tablespace_name="", authorization_file="C:/Program Files

(x86)/ESRI/License10.3/sysgen/keycodes")

Runtime error Traceback (most recent call last): File "<string>",

line 1, in <module> File "c:\program files

(x86)\arcgis\desktop10.3\arcpy\arcpy\management.py", line 4857, in

CreateEnterpriseGeodatabase raise e ExecuteError: Failure to access

the DBMS server Failed to execute (CreateEnterpriseGeodatabase).

Maybe my DBA or I have made a typo. But this has me wondering now does the db account sde need to be created first? How does the RDMS know that the sde account has a password of sde?  Or is there something wrong with my network topology.  I can't ping the SQL server from my Desktop or from the neighboring server NSMAP, but I can Remote Desktop to both NSQL and NSMAP.  

[PaulHuffman]

Been trying to get a support ticket on this since last Friday.  Can't tell if it's stuck somewhere in the DOI or at ESRI.

[RebeccaStrauch__GISP]

fwiw, I think they must be swamped in tech support (or have tracking issues).  Had a ticket in for a couple days now with no real response (but I did get a ticket number yesterday am).  Usually I get feed back much faster than this.  (but my analyst may have changed)

[PaulHuffman]

Yes, it appears ESRI Tech support for enterprise geodatabases is backed up.  I got a response from BIA's OTSGS that I was assigned a ticket number early in April. 

[BrianTwardzik]

I'd imagine you'd want to install the MSSQL 2012 NativeClient driver on the arcgis server and client machines. Its from the MSSQL 2012 feature pack.

It should be reverse compatible with a MSSQL 2008 R2 server.

[PaulHuffman]

Thanks,  Brain.  Did that previously. 

[JohnBrockwell]

[PaulHuffman]

Good idea John, but it didn't work.  Thanks.

arcpy.CreateEnterpriseGeodatabase_management(database_platform="SQL_Server", instance_name="localhost/MSSQLSERVER", database_name="Orthos", account_authentication="DATABASE_AUTH", database_admin="sa", database_admin_password="1F******", sde_schema="SDE_SCHEMA", gdb_admin_name="sde", gdb_admin_password="***", tablespace_name="", authorization_file="C:\Users\Administrator\Documents\ArcGIS 10.3.1\keycodes")

Runtime error  Traceback (most recent call last):   File "<string>", line 1, in <module>   File "c:\program files (x86)\arcgis\desktop10.3\arcpy\arcpy\management.py", line 4857, in CreateEnterpriseGeodatabase     raise e ExecuteError: Failure to access the DBMS server Failed to execute (CreateEnterpriseGeodatabase). 

[BrianTwardzik]

Ah. Just try server name "NSQL" or "localhost"

The SQL Server browser service is only really consulted when you go looking for a non-default named instance. MSSQLSERVER is the default instance name, you don't need to specify it.

In fact, giving the instance name in that case may be causing you trouble -- that is unless you have another MSSQL server on that machine.

[PaulHuffman]

That's interesting.  When I try localhost on the SQL Server machine,  I get a different error.  Looks like it connected the SQL instance.

Error creating geodatabase admin user. [ERROR: Failed to create sqlserver login sde (-51).  Error: Underlying DBMS error (-51). Extended error code: (15118)  [Microsoft][SQL Server Native Client 11.0][SQL Server]Password validation failed. The password does not meet Windows policy requirements because it is not complex enough. ]

I thought everybody named their sde account sde, pw sde.  Tried again with sde password SdePassword2!, but this still said it was not good enough. What does it want?

Specifying the host name only, without the instance name, still didn't work on either client machine.

I took a look with SSMS file logged into the SQL machine,  and I have two versions of the database that were created when I tried Create Enterprise Geodatabase while logged into the SQL machine,  Orthos and Orthos2. But looking at users,  there is no sde user.  Also the schema seems to be owned by dbo.  Maybe the tool successfully made the databases, but failed to create a sde user, so the schema had to be dbo.

[RickGeittmann]

Paul,

Have you checked that you have connection permissions to the MSSQL on the server?

Use SSMS check to make sure you are mapped to the instance which allows connections.

You may not have the permissions to connect to the new instance nor the permissions to create a new DB.