I have been running SQL Express on my local machine as part of a development environment for web development, but due to corporate requirements, recently had to change the computer name to join the new company domain. I also had to change my login/username as part of this process.
Because of this, I am no longer able to connect to my SQL Express instance, which i need to continue development. How can I migrate the existing SQL instance, which I connected to via Windows Authentication?
Let SQL Server engine works with Local System Account
as next:-
Press Window Button + R.
Type services.msc , then click Ok.
Select SQL Server Service , then choose properties.
Go to second tab Log On , then check Local System Account
Hope it helps.
Please try .\SQLEXPRESS instead of YourComputerName\SQLEXPRESS in server name.
Related
Today I installed Microsoft SQL Server Management Studio (SSMS) to install the sample database Northwind. After installing the program, I opened it and at the startup page under "Connect to server" there was a field called "Server name". I am totally new to databases so I couldn't figure out what I should do. I did a quick search on the internet and tried "SQLCMD -L" command in cmd to see available servers but instead, it returned;
;UID:Login ID=?;PWD:Password=?;Trusted_Connection:Use Integrated Security=?;*APP:Ap pName=?;*WSID:WorkStation ID=?;
So it seems like I don't have a database (at least as I understand it so).
Can you help me to install this sample in SMSS?
P.S.: I use Windows 7
To determine the name of the instance of the Database Engine
1-Log into Windows as a member of the Administrators group, and open Management Studio.
2-In the Connect to Server dialog box, click Cancel.
3-If Registered Servers is not displayed, on the View menu, click Registered Servers.
4-With Database Engine selected on the Registered Servers toolbar, expand Database Engine, right-click Local Server Groups, point to Tasks, and then click Register Local Servers. Expand Local Server Groups to see all the instances of the Database Engine installed on the computer displayed. The default instance is unnamed and is shown as the computer name. A named instance displays as the computer name followed by a backward slash () and then the name of the instance. For SQL Server Express, the instance is named \sqlexpress unless the name was changed during setup.
if you want to connect to a local database just type a dot(.) or type (localhost) and click on connect button
I'm working with ancient software using MS Access components on a Windows Server 2016 (configured as domain controller) Remote Desktop Terminal server (which I cannot circumvent or replace with local installations due to licensing hardware) that requires users to connect to a local SQL Server 2017 Express database.
Normal workflow is this:
User logs in to remote desktop with their own user/domain account
User starts software and uses it until end of workday, then closes software and remote desktop.
Situation now:
Being logged in as Administrator, I have access to the database and I can start the software and 'log in' on the software (using their software's dialog boxes) with the accounts specified in the database (table 'users'). But since we can't have everyone log in to the machine as Administrator (obviously) this is not a workable solution.
Back in the old days...
Back in 2009 when I did the installation of the old Windows 2008 R2 server in 2009 I remember installing SQL Server Express 2008 (?) and being able to run it as a sa user. This caused all connections to be run under this user as well, giving access to the database without problems by each and every (domain) user.
My problem now:
I can't seem to change the access to the database from user-based to a specific fixed user OR the administrator account for that matter. The access to the database is ALWAYS using the credentials of that of the USER.
I only see 2 ways out of this:
I set up some kind of sa-user replacement and run the database as that specific user account.
I give the domain group Personel access to the database in one way or the other.
My question for now:
Which option is best and/or where should I start looking for a solution?
In order to give every Remote Desktop User access to SQL Server via a database admin account, right click on the Server name and select properties. In the Select a page section of the Server properties dialog click Connections. Check the box next to "Allow remote connections to this server". Click OK to close the server properties dialog.
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.
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.