I've installed SQL Server Express 2019 on a Windows machine for Sitecore development. I had a hard drive crash and needed to rebuild; prior to the crash everything was working fine.
Mixed authentication is enabled, as is the SA account.
The Sitecore installer can connect to my local instance, and sets up the database structure, including a set of database logins. Everything looks OK in SSMS and initially works - I get the Welcome to Sitecore page.
However, connecting to SSMS and then trying to log in with the passwords Sitecore generated fails. When I try to set them in SQL Server, they don't take (I always get a bad password error).
I've tried as both my Windows account (which installed SQL Server) and as the sa account I configured at install. Also tried running as administrator.
The GUI and scripts seem to work fine, but the passwords never seem to get set. Prior to the crash I could connect to SSMS using the generated logins, and verify connectivity.
I'm at a loss where to go from here, other than imaging the machine and reinstalling a fresh copy of Windows.
I'm assuming that you had to reinstall SQL Server and then perform a database restore from a backup.
If this was the case, the users in the database, after the restore, were "orphaned", as they had no corresponding login in the master database. Even if Sitecore did create logins, they would have different SIDs to the users in the Sitecore database. The only way work with those users, would have been to restore a backup of the master database, in which case both server logins and database users would have had the same SIDs.
Failing that, your only option was to delete the users and re-create the logins and users correctly, which you did.
For future reference check out Microsoft's documentation on troubleshooting orphaned users in SQL Server.
So, no, this was not "a quirk with the installer and SQL Express or some kind of bug." ;-)
HTH Sean
Related
I am trying to restored a .bak file on an Azure SQL server through SSMS.
The reason why I am doing this is that my company unfortunately blocked any action on the Azure portal itself and therefore I have to find another way around.
I am able to connect successfully to the DB on Azure with my admin account through SSMS.
I first successfully restored the .bak on my local database. And then I am trying:
Again, I am able to connect through the same SSMS to the SQL db.
Moreover, when starting this procedure I get asked to connect first to the DB, which works successfully! What I mean is:
It doesn't give me any error, which is weird because if I try to connect with a wrong password it tells me right away that is wrong. So it kind of accepts it. It's only after when I really start the deployment that it gives me the problem:
Just for now, Azure SQL database doesn't support restore from .bak file.
You work flow should be right, restore the .bak file(database) into a local SQL Server firstly, then deploy the restored database to Azure with "Deploy database to Microsoft Azure SQL database".
Make sure you are using the server admin account of the Azure SQL database. Per my experience, the error is usually caused by the permission limits.
If all of these(SSMS) don't work, please thy other ways. Please try Data Migration Assistant(DMA) migrate the database. If DMA still give the same error, we can ensure that it's not caused by the tools, you need another higher Azure SQL database account permission.
HTH.
Working solution was to use the export data task:
For some reason this worked and the publish to ASQL task from SSMS didn't. I understand this is very based on the restrictions imposed by my company but at least this solution worked.
NOTE: as both Source and Destination use SQL Server Native Client .
Moreover when setting the Destination the refresh of the list of databases might not work (depending on your permissions on Server level) but if you type directly the name of the database it will work. Talking about this:
I had installed SQL server 2012 using windows authentication and attached a database that is on my C drive. Domain server failed and we have to rebuild domain server. The domain server name is now changed to new name. When I try to log in to the SQL 2012 Studio, I can not log in and I am getting an error login failed for the user.
All we did was add a letter to the domain server. Could someone direct how to correct the issue as SQL server 2012 studio is not allow me to login?
Thanking you,
Hem
This is about more than just changing the name. Domain memberships involve cyrptographic signatures that must also be replaced. All of the machines in your domain will need to re-join. You'll have a new account on your own machine. Yep, it sucks, and this is one reason why you should always keep at least 2 DCs.
Assuming you don't know any other account info, the only way to get back into the existing Sql Server instance is to restart Sql Server in single-user mode and connect as a local administrator. After you've done this, you'll need to recreate all of your logins.
Since you'll be recreating accounts and permission anyway, another option is to use this as opportunity to upgrade to a more recent Sql Server version. Sql Server 2012 is already major 3 releases behind. Shut down and uninstall the existing Sql Server instance. Install the new version of the Sql Server, where you know the sa login, and then attach to the old database mdf files.
Have you try to login with SQL authentication? (with SA account)
SQL:
DROP LOGIN [OldDomain\UserName]
GO
CREATE LOGIN [NewDomain\UserName] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [NewDomain\UserName]
GO
Then you will be able to login with your new domain name. (Make sure you change the domain name and username in the above SQL)
If you need to recover your sa password? Check this article How to recover SA password
I am trying to find a solution to three issues I have encountered recently relating to SQL Server 2014. I am not an expert with this stuff by any means, but I've sort of fallen into needing to learn it in my current role. I went from never using SSMS a few months ago to (Trying) to teach myself how to use SSIS and SSRS. I've made a ton of progress, but now I'm stuck actually getting everything automated the way I want it.
The biggest challenge, and root of all my problems, stems from the fact that I am not a local admin on my machine. It was great to finally get IT to install the programs, but they do not want to give me, or anyone not in IT in my company, local admin access. Apart from asking my director to try to convince them to do so, I'm hoping for some solutions that would mean I don't have to call them every day to run these programs.
My integration server is running, I've got my SSIS packages built, but I can't connect to the Integration Server through SSMS, as I am not a local admin on my machine. I've read about going through dcomcnfg settings for REMOTE access issues, but I'm worried that won't help here since I'm trying to do this from the local machine and it still doesn't work. Any ideas as to how I can change the settings so that it runs for non-admin accounts or just make it work?
SSRS: I've built a report, and want to deploy it, but I don't have access to the reporting services configuration manager either. For whatever reason my reporting server is stopped in the server configuration manager. When I click on it, it says to use reporting services config mgr to tweak settings, so a bit stuck. Appears to be the same issue - not a local admin. Again, are there any settings I can change (getting IT to log in as an admin and walking them through what to change is my only choice, essentially).
SQL Server agent appears to be the same issue...
I could probably run my reports now, but it would be so much nicer to use these programs to the full extent. Any help would be appreciated here. I tried to research as much as possible, but most solutions seem to relate to logging on myself as an admin, running things as admin, etc, and I just can't do that.
Thanks!
You do not need to be local admin on your machine, SSIS and SSAS require Windows Authentication to log on remotely to the server via SSMS and publishing anything to the server from BIDS / SSDT Visual Studio Shell also requires WinAuth, though you can work locally and then swap the package to the server via Ctrl-C, and also instead of deploying SSRS you can login directly to the report manager and upload an RDL file (report). To start and stop SQL Agent services you need Windows Authentication via SSMS (in your setup), but to view the SQL Agent you must be in the SQL Server SysAdmin role (or at a grain level SQL Agent Reader via the MSDB rights.
I recommend you attempt to not get local administrator rights and instead ask 'merely' for rights to read and write to the server drives, and to manage only the aspects of SQL Server and it's services with a domain login on the server. You will require this anyway to check ingress and egress file locations and debug production issues (unless you have FTP to the box).
You do not have access to stop or start SQL Agent from your client SSMS also because I believe you are accessing it via SQL Authentication, which is not ideal or secure. But if you do not see the agent on the bottom left of SSMS it is because you do not have rights. If you see the Agent and it is red then the service is disabled and must be started.
You will need to get direct access to the SQL box (and you do not need local admin to manage SQL Server, just a domain account with some service rights and drive rights). If your system administrators are running SQL Server under Local Admin, then they should not be managing SQL Server in the first place (see my write up hyperlinked below).
The SSRS Team at Microsoft has merged into the SharePoint team, and SharePoint 2013 wraps up all of the BI tools right into it, so that is something you should also consider if you plan on building out a BI shop at your firm, i.e. you may not have to if you already have SharePoint installed.
Good luck, don't get discouraged.
What user account would you recommend running the SQL Server Express 2008 services in a development environment?
I am having quite a problem with SQL Server.
When I installed it, my account was not an administrator, now it is. Apparently, since it was not an administrator of the machine, it is not an administrator of SQL Server, as a consequence I cannot create databases on my machine.
Now, I am on Windows 8, so it seems like SQL Server Configuration Manager is not as accesible as it was before, I managed to run it (I THINK!) from the MMC by running the following command: sqlservermanager10.msc.
Now, can anyone help me configure my current user as an SQL Server admin so I can create databases properly?
Thank you!
if I understand you correctly, you want your account to have sysadmin rights on SQL Server. You can either do this via SQL Server Management studio, or the SQLCMD command line utility. You don't use the SQL Server Configuration Manager.
You need to login as an existing SA (or whichever the identity has the sysadmin role).
Using TSQL via SQLCMD
Run the following command (replacing domain\user with your details)
USE [master]
GO
CREATE LOGIN [domain\user] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [domain\user]
GO
Via the UI
In SQL Server Management Studio
Navigate to the Security node of the server, and R-Click & Select New Login
In the New Login dialog enter your domain user into the Window Authentication box
Then on the Right side select Server Roles and then make sure SysAdmin is selected
Then Ok that dialog and the windows account will have SA rights. This means then you can full administer the SQL Server.
It's not clear at all what's going on here, but it sounds to me like you haven't got any sysadmins if #Preet isn't correct.
The local Administrators group is not a member of the sysadmin role on recent versions of SQL Server (2005+, IIRC), and if I recall the installer complains if you try to configure it that way. Instead, when you install the instance you specify the users or groups who will be granted the sysadmin role on the instance.
If you did not do this (I think it adds the account doing the installation by default) or used an account or group which was later deleted, had the SID changed, or some similar event, then you have an instance with no sysadmin logins that can authenticate. You may be able to add one by switching the server to single user mode or minimal configuration mode (-f instead of -m).
If none of that works, then you'll have to save your database files, nuke the instance, install the instance again, re-attach your database files, and go from there.
The only other thing I can think that it might be is that the instance is somehow running as a user account that doesn't have permissions to create files in the default database or log directory, but that seems highly unlikely.
I have taken DNN 6 backup in the following ways
Copy the DNN folder from C:\inetpub\wwwroot
Take Sqlserver 2008 Enterprise edition database backup
When I try to restore it, I am getting error:
Connection Error(s): Index #: 0 Source: .Net SqlClient Data Provider
Class: 14 Number: 18456 Message: Sql login failed
I am using the following link for restoration:
.../Install/InstallWizard.aspx
Note !!! When i change the database and username, it will install the fresh installation but not restoring backup database.
How to solve this problem?
Some of the answer here will depend on where/how you are restoring the database.
If you take a database from one server to the other, the user account does NOT come with it from a server login perspective. So after restoring the database, you will need to create a new user account for managing the access to the database.
I'm not sure about needing to run the /InstallWizard.aspx to perform a restore. The first step is to get the files laid down in the Windows directory you want, and then get the IIS setup and pointed properly ensuring that you have the right security access (Depending on your version of IIS) to the files. If you get all that right you will be good to go from a file perspective.
As far as SQL Server you will need to do a manual database restore and as Mitch says create a new account that will have access to the database - You will need to change both database access statements the web.config to specify the new user. (standard and legacy if they both exist) Finally, make sure that SQL server is configured in Mixed Mode Authentication if you are specifying a SQL user.