I am trying to set up Multi Server Administration so that I can easily update multiple instances of the same database across our network with ease. Where I am getting lost is how to set up the SQL SERVER AGENT service on the target machines.
Right now the SQL SERVER AGENT services on the machines are set to log on as NTSERVICE\SQL SERVER AGENT.
My SQL Server Agent process is set to log in as LocalSystem
My overall goal here is to figure out why I can't set any target servers from my machine, as I always run into the following error:
TITLE: Microsoft.SqlServer.Smo
------------------------------
MSX enlist failed for JobServer 'MYPC'.
For help, click: https://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=15.0.18206.0+((SSMS_Rel).191029-2112)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=MSX+enlist+JobServer&LinkId=20476
------------------------------
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
------------------------------
The enlist operation failed (reason: SQLServerAgent Error: Unable to connect to MSX 'MYPC'.) (Microsoft SQL Server, Error: 22026)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=14.00.2027&EvtSrc=MSSQLServer&EvtID=22026&LinkId=20476
------------------------------
BUTTONS:
OK
------------------------------
When looking at the log on my machine I see the following error when trying to enlist the target machine:
Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.
I'm not clear on the service accounts you have configured. At one point you state that it uses NTSERVICE\SQL SERVER AGENT but then you state "set to log in as LocalSystem "
From the Docs page , When the SQL Server Agent service is run under the Local System account, master server-target server operations are supported only if both the master server and the target server reside on the same computer.
You mention that this is across a network, therefore you should be using Domain Accounts for your SQL Agent service
LocalSystem has far too many permissions to be a secure choice - especially with a MultiServer configuration where a single server compromise may open all your servers. Whenever a local or virtual account is used then the network communications occur as the Computer Domain Account - e.g. if my server was named s1 in the MyDomain then the computer account would be MyDomain\S1$
I recommend that you configure SQL Agent to use a dedicated domain account, following the guide for permissions here. Additionally, to use multiserver job processing, the SQL Server Agent service account must be a member of the msdb database role TargetServersRole on the master server. The Master Server Wizard automatically adds the service account to this role as part of the enlistment process.
Related
I've been having troubles in creating new users on the SQL Server. Those were the steps I took:
Connect to the server via Windows authentication
Access Security > Logons > Create Logon
Create a new Logon to use SQL Server authentication
In each database, create new users (same name as logon). Those users were set Owned Schemas and Membership as db_datareader and db_datawriter
Close the connection and connect by the user created
After that process, I get the message:
It is not possible to connect to DESKTOP-QMQIHKL:
A connection with the server was successfully establishes, but during the logon process an error occurred. (provider: Shared Memory Provider, error: 0 - There is not a process in the other extreme of the pipe). (Microsoft SQL Server, Error: 233).
I've tried to overcome this error message by:
Opening SQL Server Configuration Manager and enable the TCP/IP protocol.
Opening Windows Services and executing both, SQL Server Browser and SQL Server (MSSQLSERVER).
None of that have worked. For that reason, I would like your help in solving this problem.
Have you enabled SQL Server authentication mode? By default, SQL Server is configured to use exclusively Windows authentication mode, so it will not accept your SQL Server authentication logins.
For changing the accepted authentication modes, see this article: https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/change-server-authentication-mode?view=sql-server-ver15
I've tried everything I can think of and now need help.
I'm trying to run a SQL Server Agent job that has one step in it which executes a SSAS Command that processes a dimension.
When running it, the job fails with the following error:
<Error ErrorCode="3238395904" Description="OLE DB error: OLE DB or ODBC error:
Login failed for user 'MyDomain\MyUserName'.; 28000; Cannot open database
"MyDatabase" requested by the login. The login failed.; 42000."
Source="Microsoft SQL Server 2012 Analysis Services" HelpFile="" />
The error message is pretty clear, but I cannot figure out where the issue is to fix it.
This is running on a named instance that is a test copy of the main instance on the same server.
The named instance service for both the database engine and SQL server agent are running under the "MyDomain\MyUserName" account.
The "MyDomain\MyUserName" account is set up as a "sysadmin" on the instance and has rights to "MyDatabase"
The SSAS Database uses "MyDomain\MyUserName" as impersonation (which is the same setup as the original, which works).
The SSAS Command within the job step is set to "Run as" a "SQL Server Agent Service Account"
The job owner is "MyDomain\MyUserName".
I've added the "MyDomain\MyUserName" as a server administrator under SSAS security.
I've even added the "NT Service\SQLServerAgent" (from the main instance) and the the "NT Service\SQLAgent$MyNamedInstance" (from the named instance) as a server administrators under SSAS security.
Geesh. It was the Server that was being used in the step calling the SSAS Command. It was still pointing to the old instance. Updating it the point to the new instance worked.
I have a SQL statement that merges 2 databases together, from 2 different servers (SQL Server 2012 for both).
The two servers are linked, so when executing the statement in a query window from Management Studio with the SA account it works perfectly.
However, I need to automatize this. I created a Job in the SQL Server Agent, and I keep getting an authentication error. This is because the user that is executing the SQL Server Agent service doesn't have the SA rights on both servers.
This is the error:
The OLE DB provider 'providerName' for the connection server
'serverName' reported an error. Authentication failed.
I tried setting a superadmin user from the Active Directory with all rights on both servers to execute the SQL Server Agent, but I still get the error.
Is there any way to fix this?
Thanks
You can store your linked server credentials with your linked server definition (forbid my picture editing skills ;-)):
Alternatively - and much more preferabele from security point of view - setup same account on both servers (you can then limit the account privileges as you need) and use the third option ('Be made using the login's current security context')
We have 2 SQL Servers in each of our environments. Server A is our Data Warehouse SQL Server and Server B is our OLTP server. We have the following environments PROD, STAGE, SIT, DEV. We have configured a linked sever on Server A in each environment to read, write and Exec a stored procedure on Server B. A SQL job was created on Server A to do a simple select statement from Server B to test the connection. The service account that will be running all of the jobs was configured as the job owner and "Run as User". In Prod, STAGE and SIT the test job is working. In DEV the test job is failing with the message "Access to the Remote Server is Denied because the current security context is not trusted"
I have logged in to server A as the service account and run the exact select command to server B in a query window and the command successfully returns results.
I tried a SQL job on Server A in DEV that calls an SSIS package. It uses the same service account as the test job via a proxy & credential. The SSIS package is calling a stored procedure on Server B. When I run this job it succeeds and executes a stored procedure on Server B that writes data to server B.
I validated that the Service account has administrator privileges set the same across all environments.
I validated that the Linked server has the same configuration across all environments.
I have tried to set up the Linked Server to link the service account on Server A to a SQL account on Server B
I have tried to set up the Linked Server to "Be made using the login's current security context" on Server B
I have tried changing the SQL job to run as an operating system CmdExec. SQLCMD -E -Q "select * from [Server].[Database].[Schema].table" using the same proxy and credential as the job that is working. This resulted in the following error
"A network-related or instance-specific effor has occured while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections."
I validated that the servers can ping each other.
I ran SQLCMD -L via the command line to validate that the servers are both present.
I enabled the Named Pipes protocol on both servers A and B in the configuration manager.
I tried running the test job under my credentials as an SA and got the same
"Access to the Remote Server is Denied because the current security context is not trusted" message.
I tried copying and pasting the SQL from the test job into a query window on Server A using my credentials and was able to run the query successfully.
I tried recreating the SQL job.
I tried restarting the SQL Services.
The only appreciable difference I can think of between this environment and the others is that Server A is a named instance and Server B is a default instance.
Also of note, the SQL Browser service on Server B is being run by a local account instead of a service account. SQL Browser on Server A is being run by a service account.
SQL Server was installed on the local PC by User1.
User1 has now left the company and a new account on the PC was created called User2.
User2 cannot access the local SQL Server installation.
Is it possible for User2 to access the local SQL Server without reinstalling?
Here is the error:
Cannot connect to mydatabasename.
Login failed for user 'myuser2name'. (.Net SqlClient Data Provider)
Server Name: mydatabasename
Error Number: 18456
Severity: 14
State: 1
Line Number: 65536
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=18456&LinkId=20476
The easiest way would be to log in via the "sa" account but I expect you don't have the password to this or it isn't enabled.
If you start the server in single-user mode you will be able to add additional users without reinstalling.
This MSDN page outlines all the steps but in brief they are
Stop all services for that instance (including Sql Agent and Integration services) using "Sql Server Configuration Manager"
Open up the properties window for the Sql Server instance you need to modify.
Add an additional startup parameter "-m"
Start the service (make sure you only start the Sql Server service)
Start SSMS using "Run as Administrator"
Connect to server using windows auth.
Add login.
Remove -m parameter from service and restart all services stopped above.