We are in the process of upgrading from MOSS 2007 to SharePoint 2010.   I created a SharePoint 2010 development server.  All elements of the SharePoint environment are contained on this one server.  This has MSSQL Enterprise installed on it as well as SharePoint 2010.  I did an "attach database" of a copy of a database from our MOSS 2007 environment.  Everything was looking good.  This server was to be a template for a series of developer SharePoint environment in an ESX VMWare environment.  After the server was exactly the way we wanted it, we created a template of the original server and then provisioned a new virtual server from the template with a different server name.  Obviously nothing worked.  I ran STSADM -o renameserver and it completed fine.  One thing that happens now is that the SQL Server (MSSQLSERVER) service will not start.  Here is the error message in the event log:

The SQL Server (MSSQLSERVER) service terminated with service-specific error %%17058.

At the command prompt I went to c:\Program Files\Microsoft SQL Server\mssql10_50.mssqlserver\mssql\binn.

I ran the command sqlservr.exe /c

I get the following error:

2011-11-07 09:52:14.49 Server      Error: 17058, Severity: 16, State: 1.
2011-11-07 09:52:14.49 Server      initerrlog: Could not open error log file 'E:\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG'. Operating system error = 5(Access is denied.).

The account that I am using is a local administrator account.  Anyone have any ideas of where to go from here?  We really want to create these individual SharePoint environments for our developers in preparation for our upgrade to SharePoint 2010.  They need to rewrite some of our custom web parts.  Thanks for anyone that has an idea.

Did you change the name on the new server?  Change the domain?  FWIW, the SQL Server Database Engine service account should not be a Local Administrator.

For changing SQL Server names:

http://msdn.microsoft.com/en-us/library/ms14379

Thanks Trevor,

Yes, the server has a new name.  We want to have 7 of these servers stamped out with this configuration so that each developer has their own individual development environment.  So each server will have a different name.

OK, I now have the SQL service up and running.  Here is what I did.  I renamed the ERRORLOG file in the directory that was having the "access denied" (See my original post).  Once I did that the service started up and created a new ERRORLOG file.  My DBA's went into the SQL Management console and dropped the old name and added the new name.  I believe your link pointed how to do this, though my DBA's already seemed to know how to do that.  We then rebooted the server and all the services started up just fine.  My DBA went into SQL Management and verified that the old server name was no longer being used.

I than tried to run STSADM -O RENAMESERVER -oldservername <oldname> -newservername <newname>  and it ran just fine.  I also updated the SQL Client Alias running cliconfg.exe and changed the name from the oldname to the new name.  So far so good, I think.

Now when I go into SharePoint Central Admin, it wants to go to the Central Admin using the old servername.  Of course this server is no longer up and running.  While still in the web browser I then changed the URL to point to the new server (same port) and get

Service Unavailable

--------------------------------------------------------------------------------

HTTP Error 503. The service is unavailable

I checked the SharePoint 2010 Administration service and it is running.  Is there something I have to change in IIS?  Is there another STSADM or PowerShell command I should be running?  Thanks.

503 means the App Pool is shutdown most likely.  Check the System Event Log and see what, if any, errors it is reporting.

Were the VMs changed from one domain to another during the cloning process?

You were right Trevor.  The admin pool kept stopping.  I re-entered the password used by the identity and it no longer stops.  I then went in and re-entered the password for the pool identity on any pool that used it.

Now when I try to get to Central Admin I get the following message: Cannot connect to the configuration database.

Also when I try to go into SharePoint 2010 Management Shell it take a long time and then errors with the following: The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered.

I started to run the "SharePoint 2010 Products Configuration Wizard" but it also said it could not access the local farm.  It then wanted me to disconnect from the farm.  I decided against that. I have tried to do my own research on those error messages, but so far no go. Any other ideas?  Thanks again for your help.

 

 

• Edited by Hendro_ Monday, November 07, 2011 8:26 PM

I'm thinking your farm wasn't actually moved properly during the stsadm rename operation.  Can you try that again?

Tried running RenameServer again.  Here is the message I got:

Operation completed successfully.

You may also need to update any alternate access mappings referring to sldevmsp01.

 

I have not configured any alternate access mappings on this server.  Still getting the Cannot connect to the configuration database.

Perhaps what I'm going to have to do is build up these servers individually.  I wonder how people do this kind of thing without having to build development servers one at a time.

Hi,

Please make sure your app pool account has access to sql server and databases. i think it is a permission issue. You can change it into one of domain administrators to do a test.

And for your need, i suggest you'd better do the attach database migration or move all databases way to do it since change server name will cause lots of potiential issues.

Regards,

Seven

• Marked as answer by Seven M Friday, November 18, 2011 6:43 AM

I had a similar problem. I had error 17058 and Error 1068. I tired to manually start the SQL Services: Agent, Browser, and Server with no luck all failed to start.

Here's what I did to fix my problem. I went to Admin Tools. I clicked on Services. I clicked on each SQL Service and changed the Log On as credentials. I changed them to Local System Account and Allow service to interact with Desktop. See the following screen capture.

 

My current test system is as follows:

Windows Server 2008 SP1

MS SQL Server 2008 SP1

Cumulative Update 10

SCCM 2012 B2

Single Server and Signle Site that has DNS, AD, and DHCP installed on it.

If you're SQL services are not running than you cannot connect to the SQL DB..

Once I made my credential changes I tested connecting to my SQL DB by using the SQL Studio.

I hope this helps?

Brian @ pctekli

Hi DrChuck151,

Thanks, your answer was very useful!

Lhan Han

Great, thanks buddy, you save my time.

Thanks Dr Chuck, first answer and spot on.  Happy days

I know this post is old, but this needs to be said for any future people traveling to this question. This is dangerous and definitely NOT what you should do. I repeat DO NOT set you SQL server database engine service to run as as local administrator unless your instance is completely isolated. You are asking for someone to hack your system if you do this, because a hacker can exploit that service and give their self  full rights to your system. 

This should have never been posted as an answer by the moderators. Shame.