I'm working with a fresh installation of Server 2008 R2. I'm new to all things administration, so this could be a simple issue.
I'm installing SQL Server 2008 R2, and I've reached a point where it's asking me to create Service Accounts. I'm really just trying to do bare minimum here to get started with SharePoint.
I'm getting an error "The credentials you provided for the SQL Server Agent service are invalid. To continue, provide a valid account and password."
I get this error for the Analysis Services service as well.
Can someone explain to me what this means and how I can proceed with the installation?
After some searching I saw that the issue might lie in the fact that I was signed in as a local Administrator, so I created another user in Users via Computer Management and the same issue is occurring.
The SQL installation is not asking to create service accounts. It is asking which service accounts it should use to execute SQL Server. If you need to create accounts for this, you will need to do that through the usual user management tools, whether Active Directory or Local Users.
Depending on the purposes of this machine, you may be fine using one of the built in accounts, such as Network Service. Not a best practice, but maybe adequate for a short lived demo/dev machine.
More details on MSDN.
Related
I have just finished the development of my application on asp.net mvc connected with SQL server, and I will love to deploy it. I want to use Azure App service, but I got an error "Unable to connect to master or target server 'DATABASE_NAME'. You must have a user with the same password in master or target server 'DATABASE_NAME'". I have tried every thing I found online like modifying the SSDT, but nothing changed.
Please is there any recommendation to fix this issue? If not, Please what are other ways for me to launch the application. The application will be used internally for Sales purpose and I don't need any fancy hosting. Thank you in advance.
Did you setup the sql azure firewall to accept connections from your computer?
Even if you set it up once, it is possible that your internet provider attributed a different IP address to your computer. So you must redo your firewall set up again for your computer to be accepted.
It is important to know that only sql logins/passwords are accepted here. So you must give the login/password of the admin user that you mentioned at the moment of creation of you sql server azure (there is a step that sets it up when you create your azure database), or the login/password of a user you created and granted in this database.
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 have a situation where clients connecting to my webservice(that exists on another server) must access SQL Server databases and SSAS servers.
It must use the credentials of the client that is calling the service when accessing the SQL Servers and SSAS cubes.
For this to work I do
var winId = HttpContext.Current.User.Identity as WindowsIdentity;
var ctx = winId.Impersonate();
//Access Database/SSAS
ctx.Undo();
in my service which works fine when accessing SQL Server databases.
However when I access the SSAS servers I get
"The connection either timed out or was lost"
There are a number of posts like
http://denglishbi.wordpress.com/2009/03/31/windows-server-2008-kerberos-bug-%E2%80%93-transport-connection-issues-with-ssas-data/
http://sqlblogcasts.com/blogs/drjohn/archive/2009/03/28/kerberos-kills-large-mdx-queries-on-windows-server-2008-ssas.aspx
on this but I am using Windows Server 2008 R2
where my service lives so this should not be a problem as this bug should have been fixed by Microsoft.
Any information as to how to best diagnose this problem would be appreciated.
To clarify the SSAS servers do have SPNs. This was actually working at one point but has now stopped. Appears no sign of duplicate SPNs or anything.
What is interesting is it works intermittently on one SSAS server but seems to work all the time for the other.
They both have named SPNs as mentioned by this document
https://support.pyramidanalytics.com/entries/22056243-Configuring-Kerberos-Delegation-for-Named-Instances-of-SSAS-with-Active-Directory-and-additional-pro
My production environment is a load-balanced (and under heavy load) on a very large corporate Active Directory network. The following took a lot of testing to finally nail down settings that work.
I also run on Windows 2008 Server R2
My web services are in ASP.NET in IIS. For authentication I enabled "Windows Auth" and "ASP.NET Impersonation". Kernel mode is disabled and provider is "Negotiate:Kerboros"
SPNS and Trusted Delegation are setup for an AD account. My AD account looks like sys_myservice (sys_ is just a naming convention at my company)
The Application Pool identity is set to use the sys_myservice
After you make all these changes in your dev env, restart the entire server. For some odd reason this is always necessary when we bring on new servers and configure them.
With this setup my web services access SSAS, SQL Server, and more that use Windows Kerboros auth and all queries are performed correctly under the user's credentials.
The difference in my setup from yours is ASP.NET Impersonation is enabled at the IIS level. I had trouble doing the impersonation in code which is what you are trying to do. If you get code-level impersonation to work with your workflow I would be really interested in seeing you post an update.
Forgot to mention. My services are in a MVC application, I apply a global filter to all Action methods to force the application to authenticate all connections.
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
filters.Add(new System.Web.Mvc.AuthorizeAttribute());
}
and in my web.config system.web section
<authentication mode="Windows" />
<identity impersonate="true" />
I agree that the intermittently 'successful' SSAS instance is suspicious. I wonder if it's really using Kerberos all the time. Could be using a combination of negotiate/NTLM and Kerberos, with one auth method actually working and the other approaching failing. Might be worth another look at the SPN. This link might help: http://msdn.microsoft.com/en-us/library/dn194200.aspx
Did you try using Wireshark or any other Network Analysis tools to see anything red happening at that point of failure? Probably its better if you provide more troubleshooting observations from your end.
Also, does your web services has a Load balancer?
Regards,
Sasi.
I have created a SSIS Package and now want to deploy it, for that I am required to create the Integration Service Catalog,so I have SQL Server Evaluation Set up in that when I m trying to connect the integration service, I am getting following error,
Connecting to the Integration Services service on the computer
"RESHMAJADHAV"
failed with the following error: "Access is denied."
By default, only administrators have access to the Integration Services service.
On Windows Vista and later,
the process must be running with administrative privileges in
order to connect to the Integration Services service.
See the help topic for information on how to configure access to the service.
Also I have observed that my instance for SQL Server Evaluation edition is RESHMAJADHAV\SQL_SERVER_EVALU but when I am trying to connect this server, then this option is not shown under Integration Services as shown below,
.
I am unable to sort this out, since I am entirely new to this, please explain what can be the solution.
Please make a note, I also have sql server express edition ,but since it doesn't support to create the SSIS Integration service catalog then I installed the SQL Server Evaluation edition .
Also when I am trying to connect via SQL Database as shown in below image,
then while creating the integration service catalog, it is given the following error
Password validation failed.
The password doesn't meet the requirements of password of the password filter DLL.
Change database context to SSISDB.
One fact I have observed, I don't know whether it is related or not but when I am trying to enter password for my system, then also it's giving same error that password doesn't meet the requirement and also when while installing the SQL Server edition, it gave the same error, no doubt my password was very strong and fulfill all the requirements of strong password, currently I am trying to run my SQL Server with windows authentication mode and also I have tried to disable the strong password policies from the administrative tools but it's totally futile....any help will be greatly appreciated.
Go to all programs
Click on Microsoft SQL Server 2012 folder
Right click on SQL Server Management Studio
Click on Run as Administrator
This should take care of problem for now. (With this you need to always repeat the same process). To avoid this every time and for a more persistent solution you need to get permission(s). Please do the following process and you should be good.
In previous versions of SQL Server, by default when you installed SQL Server all users in the Users group had access to the Integration Services service. When you install the current release of SQL Server, users do not have access to the Integration Services service. The service is secure by default. After SQL Server is installed, the administrator must grant access to the service.
To grant access to the Integration Services service
Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying certain settings in the registry.
In the Component Services dialog, expand the Component Services > Computers > My Computer > DCOM Config node.
Right-click Microsoft SQL Server Integration Services 11.0, and then click Properties.
On the Security tab, click Edit in the Launch and Activation Permissions area.
Add users and assign appropriate permissions, and then click Ok.
Repeat steps 4 - 5 for Access Permissions.
Restart SQL Server Management Studio.
Restart the Integration Services Service.
(Source MSDN)
I hope this will help
I researched little bit and then I came to know it was actually the problem of HP Security Tool Manager service of HP Laptop which was messing with the password of system,SQL Setup and catalog of Integration Service,I uninstalled it from PC and now my problem is resolved..
look like you don't have a admin privilege.
so start->sql server->right click->run as administrator
it might solve !!!
it's not clear whether this is due to your windows password or the SSISDB encryption password http://fendy-huang.blogspot.com.au/2012/01/sql-server-2012-integration-services.html.
I suggest you think of a very long complicated password with a mixture of upper, lower and punctiation like this:
~~AgFcDeUk17aP9%3(5#hY,lTSs9+
and put that into the encryption field when creating the catalog. If that doesn't get around your error, try changing your windows password to that. The only way to solve thedr things is divide and conquer. Once you know which password is the issue you can attack it further.
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.