I create MSSQL job with console application (operating system - cmdExec), I get error with eason 193.
There is full message:
Executed as user: NT AUTHORITY\NETWORK SERVICE. The process could not
be created for step 1 of job 0x4CB38CF498AEE244A487876F4746F5A7
(reason: 193). The step failed.
What could be a cause of it?
Have you gotten this kind of error before or have you successfully created jobs in the past?
It's likely that that specific account doesn't have the permissions necessary to create the job. If you've got access to SQL Server Management Studio, you can use the two links to learn more about the permissions needed (inside of the MSDB database) as well as how to check and set those permissions for a specific account.
SQL Agent permissions Reference
Check and set permissions for SQL Agent Jobs
Related
I have a SSIS package which i tried to schedule as a job in SQL Server Agent.
In order to achieve this i have created a Credentials with User having SysAdmin role to the server. Also i have created a proxy account to run the job where the principals added for
SQLServerAgent,SQLServerOperator,SQLServerReader.
While configuring job selected package source as File system and given the package path to execute the same.
Package is running good and updating results to table stand alone but not working when executing via SQL Job.
Error:
The process could not be created for step 1 of job 0x7D722F8836388B46956B164E33DE8955 (reason: A required privilege is not held by the client). The step failed.,00:00:00,0,0,,,,0
Fix Tried: Modified the package security with Encryptallwithpassword and no luck still.
Check your SQL Server Agent service account to make sure it has permissions to the database and the folder where the packages are being called from.
The proxy account is the user that the package will run as, so make sure that is selected in the job step.
For package encryption, unless you are saving credentials in the package, you can set the protection level to "DontSaveSensitive". It sounds like the proxy account will have the permissions you need already assigned.
I have an SSIS package that takes database backups and it runs fine in visual studio but when executed from a database job it fails with the following error. The part I can't understand is that 'GS\BOS-DBMONITOR$' isn't a user. 'BOS-DBMONITOR' is the server name.
Error:
Executed as user: NT Service\SQLSERVERAGENT. Microsoft (R) SQL Server Execute Package Utility Version 11.0.2100.60 for 64-bit Copyright (C) Microsoft Corporation. All rights reserved. Started: 10:58:03 AM Error: 2014-07-30 10:58:04.33 Code: 0xC0024104 Source: Back Up Database Task Description: The Execute method on the task returned error code 0x80131904 (Login failed for user 'GS\BOS-DBMONITOR$'.). The Execute method must succeed, and indicate the result using an "out" parameter. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 10:58:03 AM Finished: 10:58:04 AM Elapsed: 0.593 seconds. The package execution failed. The step failed.
SQL Server Agent is the scheduler that comes with SQL Server. The first line of your error, Executed as user: NT Service\SQLSERVERAGENT specifies that your instance is running as the system user - not a "real" account. This machine is then trying to reach out to another computer and asks to log in to that SQL Server instance. SQL Server says "I'm not allowed to talk to strangers and GS\BOS-DBMONITOR$', you're strange."
How do you resolve it?
You need to let the foreign machines know about the account that's going to talk to them.
Use SQL Server Configuration Manager to change the service account from the the local account to a domain account MyDomain\NonExpiringAccount
Create a Credentialed user in the SQL Server instance on BOS-DBMONITOR and then assign them as a proxy for executing this, and any similar, SSIS packages. This allows the credentialed users' account to be presented to the foreign hosts. This has less potential impact on existing operations than changing the service account but requires more work
There's probably some voodoo you can work on all the servers you need to take a backup on to allow this user to log on but I wouldn't even go down that road. It's going to be work you have to perform on a per box basis and there's probably some security implications that go over my head
I have a package which runs under a service account which i have given proxy permissions to in SSIS Package Execution. However, when it starts to run i get the following error
Cannot open database "SSISDB" requested by the login. The login failed. Login failed for user 'ServiceAcountXXX'.
I am assuming that the service account has no access to the SSISDB database to record all that execution logging information. I thought that giving it the SSIS Package Execution access would automatically do that. Does anyone know what permissions I still need to give the service account so it will run ? When i ran the sql agent this wasn't an issue.
Erick
If I understand correctly, you've authorized a proxy to execute jobsteps of type SSIS. The remaining step, is to grand the credentials account for your proxy the ssis_admin role in the SSISDB catalog.
I am trying to set up reporting emailing SQL Server 2005 Reporting Services. When I click to save a subscription I recieve the following error:
An internal error occurred on the report server. See the error log for more details. (rsInternalError) Get Online Help The SELECT permission was denied on the object 'sysservers', database 'mssqlsystemresource', schema 'sys'.
I was under the impression Reporting Services uses the role RSExecRole which is created during installation. Isn't mssqlsystemresources something that is not supposed to, and not easily touched?
This is most because the user doesn't have permissions setup correctly. Can you check if RSEXECROLE doesn't have any DENY permissions and has correct permissions on the reportserver db.
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2007/11/6/3195.aspx
Based on the code in the above url, RSEXECROLE should have 323 rows on SQL Server 2005 SP3. Yours should match that.
Let me know what you find.
I am creating a SQL Server Replication using a script. When I try to execute
The job failed. Unable to determine if the owner (STAR\moorer7) of job L3BPT2M-Atlas-14 has server access (reason: Could not obtain information about Windows NT group/user 'STAR\moorer7', error code 0x5. [SQLSTATE 42000] (Error 15404)).
This is a job created by a script that defines replication.
How do I debug this?
Active Directory is refusing access to your SQL Agent. The Agent should be running under an account that is recognized by STAR domain controller.
For me, the jobs were running under DOMAIN\Administrator and failing with the error message "The job failed. Unable to determine if the owner (DOMAIN\administrator) of job Agent history clean up: distribution has server access (reason: Could not obtain information about Windows NT group/user 'DOMAIN\administrator', error code 0x5. [SQLSTATE 42000] (Error 15404)). To fix this, I changed the owner of each failing job to sa. Worked flawlessly after that. The jobs were related to replication cleanup, but I'm unsure if they were manually added or were added as a part of the replication set-up - I wasn't involved with it, so I am not sure.
We encountered similar errors in a testing environment on a virtual machine. If the machine name changes due to VM cloning from a template, you can get this error.
If the computer name changed from OLD to NEW.
A job uses this stored procedure:
msdb.dbo.sp_sqlagent_has_server_access #login_name = 'OLD\Administrator'
Which uses this one:
EXECUTE master.dbo.xp_logininfo 'OLD\Administrator'
Which gives this SQL error 15404
select text from sys.messages where message_id = 15404;
Could not obtain information about Windows NT group/user '%ls', error code %#lx.
Which I guess is correct, under the circumstances. We added a script to the VM cloning/deployment process that re-creates the SQL login.
In my case I was getting this error trying to use the IS_ROLEMEMBER() function on SQL Server 2008 R2. This function isn't valid prior to SQL Server 2012.
Instead of this function I ended up using
select 1
from sys.database_principals u
inner join sys.database_role_members ur
on u.principal_id = ur.member_principal_id
inner join sys.database_principals r
on ur.role_principal_id = r.principal_id
where r.name = #role_name
and u.name = #username
Significantly more verbose, but it gets the job done.
Just solved this problem. In my case it was domain controller is not accessible, because both dns servers was google dns.
I just add to checklist for this problem:
check domain controller is accessible
I was having the same issue, which turned out to be caused by the Domain login that runs the SQL service being locked out in AD. The lockout was caused by an unrelated usage of the service account for another purpose with the wrong password.
The errors received from SQL Agent logs did not mention the service account's name, just the name of the user (job owner) that couldn't be authenticated (since it uses the service account to check with AD).
I had to connect to VPN for the publish script to successfully deploy to the DB.
In our case, the Windows service account that SQL Server and SQL Agent were running under were locked out in Active Directory.
I just got this error and it turns out my AD administrator deleted the service account used by EVERY SQL Server instance in the entire company. Thank goodness AD has its own recycle bin.
See if you can run the Active Directory Users and Computers utility (%SystemRoot%\system32\dsa.msc), and check to make sure the account you are relying on still exists.