none
Installing SharePoint 2013 - Failed to Create configuration database

    Question

  • I am having a problem seen but not answered elsewhere. I am using a domain Administrator account that works in MOSS2010 installations. SQL Server 2012 is setup (on a different machine) but I can see it, access it and use from the MOSS 2013 server. My SQL Server account has all the privileges under the sun yet the config wizard cannot create the database. Access Denied is the error on creating the mdf file but this is not possible. What else do I look for here?

    Geoff Schaller


    Geoff Schaller Software Objectives

    Saturday, May 18, 2013 11:28 AM

Answers

  • You've probably checked all these, but here are the basics.

    1. Turn off the Windows Firewall on both machines.  This is very common, but since you say you can see and access the SQL 2012 server from the SharePoint 2013 server that probably isn't the issue.
    2. Your SQL Service service account should be a domain account and have R/W privileges to where the mdf for databases will be created.
    3. Your install account must be a Local Admin on the SharePoint Server and have at least DBCreator and Security Admin roles in SQL on the SQL Server.
    4. Your farm account needs to be a domain account, but doesn't require any privileges to start since those will be assigned by the install account during installation.

    That should be all it takes.  You mentioned you can access the SQL server from the SharePoint server.  By access do you mean RDP or can you connect to the SQL server?  I would try creating an ODBC User DSN on the SharePoint server as your setup account.  If you can access and existing database on the SQL server through a DSN that would verify your security and connectivity.


    Paul Stork SharePoint Server MVP
    Principal Architect: Blue Chip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Saturday, May 18, 2013 12:13 PM

All replies

  • You've probably checked all these, but here are the basics.

    1. Turn off the Windows Firewall on both machines.  This is very common, but since you say you can see and access the SQL 2012 server from the SharePoint 2013 server that probably isn't the issue.
    2. Your SQL Service service account should be a domain account and have R/W privileges to where the mdf for databases will be created.
    3. Your install account must be a Local Admin on the SharePoint Server and have at least DBCreator and Security Admin roles in SQL on the SQL Server.
    4. Your farm account needs to be a domain account, but doesn't require any privileges to start since those will be assigned by the install account during installation.

    That should be all it takes.  You mentioned you can access the SQL server from the SharePoint server.  By access do you mean RDP or can you connect to the SQL server?  I would try creating an ODBC User DSN on the SharePoint server as your setup account.  If you can access and existing database on the SQL server through a DSN that would verify your security and connectivity.


    Paul Stork SharePoint Server MVP
    Principal Architect: Blue Chip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Saturday, May 18, 2013 12:13 PM
  • You could try manually creating the database using the following command:

    psconfig.exe -cmd Configdb create

    I encountered this error when installing SharePoint Foundation.  See my blog post for details and screenshots: http://www.adventuresinsharepoint.co.uk/index.php/2013/02/02/configuration-failed-failed-to-create-the-configuration-database/

    Saturday, May 18, 2013 4:36 PM
  • pls ensure max degree of parallelism is set to 1 and installation service account has dbo rights in sql database 

    Using SQL Server Management Studio
    To configure the max degree of parallelism option
    In Object Explorer, right-click a server and select Properties.
    Click the Advanced node.
    In the Max Degree of Parallelism box, select the maximum number of processors to use in parallel plan execution.

    Please remember to mark your question as "answered" if this solves your problem.


    Sunday, May 19, 2013 3:50 AM
  • Paul,

    You were on the right track but the real problem was a little bit more obscure and may serve as a warning for others. What happened was we decided to use a new instance of SQL Server 2012 on another VM as the database host. This instance was an in-house production instance running just fine. However the service account for SQL Server (nothing to do with SharePoint) was NTService\MSSQLSERVER. Now this is a hidden account and during the install, we moved all the default fodlers away from the C: drive to other drives. No problem except that this user could not create DBs. It could do everything else (which is why no-one noticed it). Bizarre. This is the default account the SQL Server installer uses and we assumed - not unreasonably - it would proivision the chosen folders appropriately. No such luck. So we supplied a genuine domain account and voila... it all works fine.

    We still can't "find" this created service account to review or alter its credentials so I would recommend to everyone to supply a genuine domain account and provision the various locations manually. Our SHarePoint install now proceeded as expected.

    Geoff Schaller
    Software Objectives


    Geoff Schaller Software Objectives



    Sunday, May 19, 2013 7:35 AM
  • NTService\MSSQLSERVER is essentially another one of the local built-in accounts.  I try to stay away from them when I'm doing SharePoint for exactly the reasons you specified.  That's why I suggested using a domain account for the SQL Service account in #2 above.

    Paul Stork SharePoint Server MVP
    Principal Architect: Blue Chip Consulting Group
    Blog: http://dontpapanic.com/blog
    Twitter: Follow @pstork
    Please remember to mark your question as "answered" if this solves your problem.

    Sunday, May 19, 2013 6:32 PM