I have created an Amazon EC2 Instance that provides Windows Server 2008 with SQL Sever 2008 pre-installed. Now in order to use the SQL Server for creating databases, or restoring backups of the databases that I have on my local machine, I need the "sa" password for SQL Server 2008.
I have tried using the following but with no luck:
sa
password
"blank password"
"same password as the admin password for my EC2 instance"
Could someone please guide me as to how to get started with using the Amazon EC2 Datacenter with respect to the "sa" password.
Thanks
A bit of an update as of 2010-07-01, using a fresh Amazon image of Windows 2008 Datacenter (with SQL Server Express), SQL server was running, but the sa account was neither enabled nor with a known password. Follow these steps to fix it:
Use SQL Server Management Studio to connect to your data base server using Windows Authentication (Administrator user, for instance).
Expand the Security and Logins groups.
Open the sa account.
On the default screen ("General") set a new Password as you see fit.
Select the "Status" screen on the left.
Set the "Login:" option to "Enabled".
Click the OK button.
Right-click the root node (this will name your SQL server) and select Properties.
Select the "Security" screen on the left.
Set "Server authentication" to "SQL Server and Windows Authentication mode"
Restart the SQL Server service.
Enjoy your new-found sa access! (finally)
On a fresh Amazon EC2 "small" instance, as of 2010-05-31, the SQL services are disabled by default.
Fix: Enable any service starting with "SQL".
"Start..Administrator Tools..Services".
Select every service starting with "SQL", set the startup type to "Automatic".
Start every service starting with "SQL".
Some services will refuse to start, don't worry about this.
Now, you can go back into "SQL Server Management Studio", and everything will work nicely.
Update
2010-05-31. I tested the instructions above, with a fresh Amazon EC2 instance with SQL Server installed, and everything worked just as I described.
Update
2010-10-07. The real reason Amazon EC2 disables SQL Server, by default, on a small instance is that it doesn't actually have enough RAM to run things properly. I'm not even sure why they installed it in the first place. From bitter experience, I'd recommend that you run MySQL, given the choice, as its faster and lighter, or upgrade to a decent sized instance.
Update
Another reason why SQL is disabled, by default:
I'm pretty sure they they want to avoid being "that" company that lets loose another
"code red" or "sql slammer" worm - #Dan Esparza
RDC to the server under Administrator and connect to MSSQL instance using Enterprise Studio, using trusted connection. Then go to Security and set sa password to what you need it to be.
The short answer for how to get into SQL Server is you must RDP to the server using the Administrator account for that server (not a domain admin) and then connect to SQL using Windows Authentication. From there, you can then enable sa or add any other accounts.
When running the Microsoft SQL Server Management Studio, make sure you run it as administrator even if you have administration rights.
You could not view the password directly as it would be present under syslogins in an encrypted format.
But, You can reset the pwd.
Login to SSMS with "Windows Authentication" --> Expand "Security--> Logins"
Under "Logins", Select the appropriate LoginName and open the properties window. There you can Provide a new Password to your login.
Related
I am installing an app and I am at the point where I am supposed to provide the server details. I installed SQL Server Express and I also installed SQL Server Management Studio.
This is the screenshot:
I did execute this command
select ##servername
but I got this response:
I am running this on my local machine. How can I find the database server address and also the server password?.
PS: I do not remember setting any password when installing SQL Server.
Thanks.
When you executed the command select ##servername, how were you connected to the server? Running that command required knowing the servername and authentication of some kind. I'm guessing you were connected to DESKTOP-KOJLCIF\SQLEXPRESS or .\SQLEXPRESS using windows authentication.
When you installed SQL Express, there was an option for Windows Authentication or SQL Server + Windows (aka Mixed Mode) Authentication. If you chose Windows Authentication (which is the default if I recall), you will not have SQL Server usernames or passwords.
The app you are installing appears to required SQL Auth, so you need to pick Mixed Mode in your setup (which allows both Windows Auth and SQL Auth). You can find this setting in recent versions of SQL Server Management Studio by right-clicking your database server in object explorer, going to Properties, and then looking at the Security page. Older versions of SQL require going to another tool included in the installation folders-- server configuration or some such, the name escapes me. Change the authentication to "SQL Server and Windows Authentication mode". I believe a SQL Server restart is required after doing this.
You can then create SQL logins with username and passwords and appropriate permissions using the GUI in SSMS (expand security folder under your server and look at the logins sub folder) or via CREATE LOGIN t-sql command.
There is a fixed sql login called 'sa' that will always exist if SQL Auth is enabled. You could right click this login, go to properties, and change the password. Be careful giving out your sa credentials to an app, as that can control the entire server.
I have a local SQL Server Express 2005, for which I don't know the SA password. I always connected with my NT login and I used that when I created a DB I want to access now.
My company split and I am a member of a new domain now. There are no connections with the old domain anymore. My account resides in the new user domain and is a local administrator on the computer where SQL Server runs.
I can access the Server through the Management Studio, but not my user DB anymore. I am not recognized as a Server Admin anymore either. Obviously, local NT administrators are not automatically mapped to be SQL Admins.
Is there a way to do that at this stage? Can I somehow recover access to the SA level of access?
Thanks in advance.
Not having tried this myself, but running the database in single user mode should give you SQL Server Admin privileges if you are a Windows Administrator on that local machine.
SQLServr.Exe –m
Found a technet post that describes the full procedure:
http://blogs.technet.com/b/sqlman/archive/2011/06/14/tips-amp-tricks-you-have-lost-access-to-sql-server-now-what.aspx
you may find this solution elegant:
https://www.mssqltips.com/sqlservertip/2682/recover-access-to-a-sql-server-instance/#comments
For me it did not work with SQL2016 but as the author states, it worked for him in older versions of MS SQL.
Quotes (from the above link):
Thanks to Mark Russinovich of Sysinternals fame, there is a very painless way to solve this problem without any downtime: PsExec. While it wasn't one of its primary design goals, PsExec allows you to run programs as the NT AUTHORITY\SYSTEM account, which - unlike "regular" Administrator accounts - has inherent access to SQL Server.
PsExec -s -i "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"
Now, you can go in to Security > Logins and add your account as a sysadmin, add other admin accounts, update the sa password, and do anything else you need to do to make your instance manageable. As you can see, I was able to connect in this way to both SQL Server 2008 and SQL Server 2012 instances from an instance of Management Studio 2012.
I have followed these steps https://www.windowsazure.com/en-us/manage/windows/how-to-guides/capture-an-image/ to capture an image of a VM. Used sysprep as mentioned and I was able to replicate the VM. The problem is that when I rdp into the machine, I can't connect to SLQ Server. Login fails for Windows Authentication. Usually this means that the SQL Server is on another domain, but in this case the error is on local machine.
So my question is, how to capture an image of a VM with SQL Server in Windows Azure and ensure that I can login with Windows Authentication at least when deployed?
I don't think you can, I think you will need SQL Server Authentication before sysprep (I haven't tested this), as far as I know this is the same on-premises and not an Azure feature per se...
If you run sysprep on Windows, you shouldn't have any expectations that the current principals provisioned in SQL Server will continue to work. SQL Servers references Windows accounts by their SIDs and running sysprep on Windows will create a new set of SIDs for the Windows account. Therefore, you will have to re-add them to SQL Server as you've discovered.
Adding a solution that worked for me, in case anyone facing same problem and haven't found any working solution.
After creating an Azure VM from the Image based on a generalized VM (sysprep run):
Launch SQL Server Configuration Manager.
Navigate to SQL Server Services.
Right click on SQL Server (SQLEXPRESS)->Properties from the right side panel.
Select 'This account:' and enter details of current VM Administrator credentials.
Apply changes and restart SQL Server.
Now, try connecting to the SQL Server. It should work.
I recently installed Microsoft SQL Server 2012 on a fresh Windows 7 installation, but whenever I want to run the server, I get the following error:
Error 1069: The service did not start due to a logon failure.
The following user is configured to start the service: NT Service\MSSQL$SQLEXPRESS
How can I fix this problem?
The answer to this may be identical to the problem with full blown SQL Server (NTService\MSSQLSERVER) and this is to reset the password. The ironic thing is, there is no password.
Steps are:
Right click on the Service in the Services mmc
Click Properties
Click on the Log On tab
The password fields will appear to have entries in them...
Blank out both Password fields
Click "OK"
This should re-grant access to the service and it should start up again. Weird?
NOTE: if the problem comes back after a few hours or days, then you probably have a group policy which is overriding your settings and it's coming and taking the right away again.
This happened to me. A policy on the domain was taking away the SQL Server user account's "Log on as a service" rights. You can work around this using JLo's solution, but does not address the group policy problem specifically and it will return next time the group policies are refreshed on the machine.
The specific policy causing the issue for me was:
Under, Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignments: Log on as a service
You can see which policies are being applied to your machine by running the command "rsop" from the command line. Follow the path to the policy listed above and you will see its current value as well as which GPO set the value.
While ("run as SYSTEM") works, people should be advised this means going from a minimum-permissions type account to an account which has all permissions in the world. Which is very much not a recommended setup best practices or security-wise.
If you know what you are doing and know your SQL Server will always be run in an isolated environment (i.e. not on hotel or airport wifi) it's probably fine, but this creates a very real attack vector which can completely compromise a machine if on open internets.
This seems to be an error on Microsoft's part and people should be aware of the implications of the workaround posted.
Short answer:
install Remote Server Administration tools on your SQL Server (it's an optional feature of Windows Server), reboot, then run SQL Server configuration manager, access the service settings for each of the services whose logon account starts with "NT Service...", clear out the password fields and restart the service. Under the covers, SQL Server Config manager will assign these virtual accounts the Log On as a Service right, and you'll be on your way.
tl;dr;
There is a catch-22 between default settings for a windows domain and default install of SQL Server 2012.
As mentioned above, default Windows domain setup will indeed prevent you from defining the "log on as a service" right via Group Policy Edit at the local machine (via GUI at least; if you install Powershell ActiveDirectory module (via Remote Server Administration tools download) you can do it by scripting.
And, by default, SQL Server 2012 setup runs services in "virtual accounts" (NT Service\ prefix, e.g, NT Service\MSSQLServer. These are like local machine accounts, not domain accounts, but you still can't assign them log on as service rights if your server is joined to a domain. SQL Server setup attempts to assign the right at install, and the SQL Server Config Management tool likewise attempts to assign the right when you change logon account.
And the beautiful catch-22 is this: SQL Server tools depend on (some component of) RSAT to assign the logon as service right. If you don't happen to have RSAT installed on your member server, SQL Server Config Manager fails silently trying to apply the setting (despite all the gaudy pre-installation verification it runs) and you end up with services that won't start.
The one hint of this requirement that I was able to find in the blizzard of SQL Server and Virtual Account doc was this: https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts, search for RSAT.
I had a similar issue that was resolved with the following:
In Services.MSC click on the Log On tab and add the user with minimum privileges and password (on the service that is throwing the login error)
By Starting Sql Server to run as Administrator
If the user is a domain user use Domain username and password
One possibility is when installed sql server data tools Bi,
while sql server was already set up.
Solution:-
1.Just Repair the sql server with the set up instance
if solution does not work ,
than its worth your time meddling with services.msc
I don't know how good of a solution this is it, but after following some of the other answer to this question without success, i resolved setting the connection user of the service MSSQLSERVER to "Local Service".
N.B: i'm using SQL Server 2017.
This is rather embarrassing, but I accidentally deleted my Windows account from the list of SQL Server 2008 users and I cannot for the life of me figure out how to re-add myself now that I don't have login privileges.
The server is running on my machine and the only other Windows users with access are IUSR, NETWORK SERVICE and SYSTEM. Is there anything I can do short of re-installing?
I also recently deleted my windows account from my local development 2008 server. I was able to use SQL server's Single User Mode to recreate my login and add it to the sysadmin role. It took just a few minutes, and I didn't have to admit my terrible error to anyone.
From MSDN:
Starting SQL Server in single-user mode enables any member of the
computer's local Administrators group to connect to the instance of SQL
Server as a member of the sysadmin fixed server role.
Here's how I reinstated myself:
Exit out of SSMS
Stop any SQL related services. I had to stop Reporting Services. Other SQL services such as SQL Agent will also use up your one, valuable connection.
Stop the SQL service
Start the SQL service with the extra parameter -m. This will put the SQL into Single User Mode. This means that SQL will only accept one connection.
Use sqlcmd to connect to your server with the -E trusted connection option. SQL will accept you into the sysadmin role if you're a local administrator.
In the interactive session, create your login and add to the sysadmins role.
USE master
GO
CREATE LOGIN [domain\username] FROM WINDOWS WITH DEFAULT_DATABASE=[Master]
GO
EXEC sp_addsrvrolemember #loginame=N'domain\username', #rolename=N'sysadmin'
GO
Stop the SQL service, remove the -m parameter and restart the service. You should now be able to go back into SSMS and continue using the server normally.
If you get the message:
Login failed for user 'domain\username'. Reason: Server is in single user
mode. Only one administrator can connect at this time.
Then there is something using your single connection. You'll need to find that service or connection and stop it before you can log in. Check SQL Agent, SQL Reporting Services, SQL Analysis Services etc.
Luckily, this wasn't too hard to fix (not that it should have been hard...)!
This blog post explains the steps for starting SQL Server in Single User Mode, which (for some reason) allowed me to login as my Windows administrator account, add the account to the user list (with CREATE LOGIN), enable the SA user and set its password to something I actually knew, and finally login as SA and give the Windows account sysadmin privileges.
Edit 07/05/13: Try this link instead.
Often SQL Server is installed so that any any local administrator is a SQL Server sysadmin.
If this is your case you can run Management Studio as administrator and then add any other windows user as a login in the Security section.
This solution worked for me.