I have SQL Server 2014 installed as a default instance MSSQLSERVER. My computer's name is DHAVAL-PC.
So I used to connect SQL Server database engine with DHAVAL-PC.
Coming to DNN 8 Installation, I used to type my server name as DHAVAL-PC and the empty database that I have created. But I am getting the following error:
Even I tried with MSSQLSERVER, DHAVAL-PC/MSSQLSERVER, ./MSSQLSERVER, ..
None of the server names worked.
My best guess is that DNN 8 service is not running with your identity (account). This identity can not login to the database server.
So figure out under which identity does this process/service run and then add this service account to the database, configure access rights too.
... or just create an SQL server account, with username/password and then set security to "User defined".
What identity is your site running under? Assuming you are using IIS look at the identity field of your application pool. If it is an application pool identity make sure you have granted owner permission on the database to that application pool.
To do that, add IIS APPPOOL\<application_pool_name> as a user/logon in sql server
Related
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
In SSMS, I'm trying to use the "Deploy Database to SQL Azure Database" utility.
I'm moving a small local database in SQL Server 2012 to Azure for hosting. But after entering the host database server connection parameters I always get a "Login Failed for user,...." error, referencing the name of the local database to be created on the server.
Why this would fail is unclear, since the database does not exist on the cloud server yet. Here is what I have done:
Set up a firewall exception for my local IP address.
Confirmed my server administrator user name and password
So now I am left guessing... Locally I use Windows Authentication. If a database is to be moved to the server, does it have to have SQL Server authentication, as is required on Azure host?
You need to have the SQL server Authentication enabled in order to be able to login to your database when you move it to Azure.
Once, you login through SQL server authentication, you can create your users then and have different logins for different users.
Hope this helps!
I'm trying to install SQL Server 2012 on Windows Server 2012, but when I get to:
The SQL Server Analysis Services are empty so I can't continue instalation proces. Any idea what Account Name should be there? And how to add it?
Not sure why a default is missing, but this is a service account, so as with any other service account, best practice is to create a user in AD for this purpose only and to assign this user account (making sure it has sufficient permissions on the local machine where SSAS is running) to the SSAS service on installation.
The MSA(Managed Service Account) must be created in the Active Directory by the domain administrator before SQL Server setup can use it for SQL Server services.
Check here ~ Configure Windows Service Accounts and Permissions
I am getting the following error when trying to deploy my SSRS reports on our SQL 2008 R2 Server "The report server cannot decrypt the symmetric key used to access sensitive or encrypted data in a report server database...". Most of the solutions on the Web suggest to delete the encryption keys, then reconfigure the datasources. I am still a beginner in SSRS, Is there another solution to fix this issue, Thanks
After checking this link Microsoft support link, it seems that this is a know issue in SSRS reports. And it seems the only way to fix it is to delete the Encryption keys.
Open Reporting Services Configuration Tool ( Programs->Microsoft SQL
Server 2008 R2 -> Configuration tools -> Reporting Services
Configuration Manager)
Go to Encryption Keys
Click Delete.
This solved my problem
I ran into this with a Microsoft Dynamics CRM 2016 Reporting Extensions Setup after changing the SQL Server Reporting Services account from services.msc. This is because the Microsoft Dynamics CRM 2016 Reporting Extensions Setup requires a non-local service account. https://technet.microsoft.com/en-us/library/hh699754.aspx The key trigger here that is likely the root cause seen in the Haasan's question was the changing of the SQL Server Reporting Services service account without backing up the encryption key. While what he did with deleting encryption keys worked, it has drawbacks of losing that encryption information and if possible, you should use the steps below to revert back to the original service account user and then change the service account using the steps documented below and in the reference article.
The identity account running the instance of Microsoft SQL Server Reporting Services where the Microsoft Dynamics CRM Reporting Extensions are running can’t be the local system or a virtual account. This is required for Microsoft Dynamics CRM reporting to work because the identity account must be added to the PrivReportingGroup Active Directory security group that is used by Microsoft Dynamics CRM.
The long story here is that when changing the SQL Server Reporting Services account, you need to do that from the SQL Server Services Reporting Manager as that will prompt you to back up the Symmetric encryption key that SQL Server Reporting Services uses and restore it with the new service account user.
The Report Server service uses the symmetric key to access the encrypted data in a report server database. This symmetric key is encrypted by using an asymmetric public key that corresponds to the computer and the user account that is used to run the Report Server service. When you change the user account that is used to run the Report Server service, the report server cannot use the asymmetric public key to decrypt the symmetric key. Therefore, the Report Server service cannot use the symmetric key to access the data from the report server database.
This will be doing the following when changing the service account from the SQL Server Reporting Services Reporting Manager:
Automatically adds the new account to the report server group created on the local computer. This group is specified in the access control lists (ACLs) that secure Reporting Services files.
Automatically updates the login permissions on the SQL Server Database Engine instance used to host the report server database. The new account will be added to the RSExecRole.
The database login for the old account will not be removed automatically. Be sure to remove accounts that are no longer in use. For more information, see Administer a Report Server Database (SSRS Native Mode) in SQL Server Books Online.
Granting database permissions to new service account only occurs if you configured the report server database connection to use the service account in the first place. If you configured the report server database connection to use a domain user account or a SQL Server database login, the connection information is not affected by the service account update.
Automatically updates the encryption key to include the profile information of the new account.
If like in my scenario, you happen to know what the previous service account user was, the fix is to change the SQL Server Report Service account user back to the originally specified account and then to use the SQL Server Reporting Services Reporting Manager to change the account and to ensure that you backup the encryption key as that process automates the restore of the encryption key when the new service account user is set.
References: https://msdn.microsoft.com/en-us/library/ms160340.aspx - Configure the Report Server Service Account (SSRS Configuration Manager)
https://support.microsoft.com/en-us/kb/842421 - You receive an error message in the Reporting Services trace log when you restart the Report Server service after you change the user account that is used to run the Report Server service (This is an old KB article, but the general problem and resolution still applies with newer versions of SQL Reporting Services)
Hopefully this might save someone some time if deleting the key is not an option.
I ran into this issue after moving the ReportServer and ReportServerTempDB from a working server to a different environment running Reporting Services. Deleting the encryption keys was not an option and I knew the password used to create the encryption key, so I took a backup of the key from the working server and restored it using Reporting Services Configuration Manager on the new environment. Refreshed the page and the error went away.
I am trying to use IIS 7.5 Application Pool identity as login on SQL Server 2008 R2 so that my ASP.NET web app can connect to the database...
Using this approach worked fine on my local dev machine (IIS 7.5 and SQL Server 2008 R2 on same machine).
However, when I try to set up the same on production (IIS and SQL servers are separate) I am unable to add "IIS APPPOOL\MyAppAppPool" login to SQL Server 2008 R2.
Notice that in either case you cannot use "Browse..." when creating a login in SQL Server since "IIS APPPOOL\MyAppAppPool" user identity is dynamic (or "special")...
Any ideas?
Update:
For more info on Application Pool Identities see here.
From article:
Whenever a new Application Pool is
created, the IIS management process
creates a security identifier (SID)
that represents the name of the
Application Pool itself. For example,
if you create an Application Pool with
the name "MyNewAppPool," a security
identifier with the name
"MyNewAppPool" is created in the
Windows Security system. From this
point on, resources can be secured by
using this identity. However, the
identity is not a real user account;
it will not show up as a user in the
Windows User Management Console.
That articles states (under "Accessing the Network") you still use the <domainname>\<machinename>$ aka machine account in the domain.
So if both servers are in "foobar" domain, and the web box is "bicycle", the login used to the SQL Server Instance is foobar\bicycle$
If you aren't in a domain, then there is no common directory to authenticate against. Use a SQL login with username and password for simplicity
Edit, after comment
If the domains are trusted then you can use the machien account still (use domain local groups for SQL Server, into which add a global groups etc)
As for using app pool identities, they are local to your web server only as per article. They have no meaning to SQL Server. If you need to differentiate sites, then use proper domain accounts for the App Pools.
You can't have it both ways...