The process could not be created for step 1 of job <job_id> (reason: 1314). The step failed. RRS feed

  • Question

  • Hi I am facing an issue running an SSIS package on a SQL Server 2005 SP2 machine


    Here's more information:


    1) The SSIS package that dumps data returned from a stored procedure call to an excel (CSV) file. The package owner is a SQL Login called AppAdmin. The login has user memberships/roles in two databases:


    1.1) Database AppDB - Has execute and select permissions.

    1.2) Database msdb - SQLAgentUser role


    The package has one step that is run as a SSIS Proxy account PrxApp. The Proxy is based on a credential CrdApp which is based on a windows account <domain>\AppAccount. This account is part of the Local Administrators group and also has SA rights in on the server. The same account is also used to run all the SQL Server Services on this machine. The machine is part of a 2-node cluster (A/P).


    When I try to execute this package (as a schedule or one-off), I am getting the error mentioned in the Subject. I have checked a few posts using google and have acted upon as many suggestions that I possibly could (e.g. change this, change that...did not do any registry modification, etc). Many of these posts have been talking about changing local security policy and adding the user to several groups. Did that, but still does not work in a SQL Agent Job.


    The account currently has the following rights (local security policy)


    • Act as part of OS
    • Perf. volume maint tasks
    • Lock pages in memory
    • Replace process level token


    One thing that I did notice and don't know if that affects the issue is that the following groups (and SQL Logins) are missing from my Windows groups listing (Computer Management\Users and Groups\Groups). Note that this is a Windows 2003 machine.


    (a) SQLServer2005MSSQLUser$<machine_name>

    (b) SQLServer2005SQLAgentUser$<machine_name>


    Now these groups (and logins in SQL Server) do exist on some other SQL2005 machines that I have checked to see what could be wrong.


    Any help at all is greatly appreciated. If you need any more information please let me know.



    Shishir Khandekar

    Wednesday, June 11, 2008 7:05 PM

All replies

  • Hi Shishir,

    I was having the issue you have described (reason 1314 without any additional information) and my case was a difference between the server and database collation. When the server collation was changed to match the database collation, the job was able to run without any problem.

    Please note that if you need to change your server collation, you will have to do a backup of the database and you will probably have to restore it afterwards (this also applies to any other database located on that server). You should also backup any jobs you have created as they will also disappear when changing the server collation.

    Thursday, July 30, 2009 2:52 PM
  • can you tell me?
    Source DB connection ? is SQL
    Destination DB connection ? is SQL
    To connect to Source DB you are using SQL connection or NT User connection?
    To connect to Destination DB you are using SQL connection or NT User connection?
    Are you making and droping tables in your SSIS?
    is your Package encripted with pass word?
    is your package working in a dev inviroment or in the BI?

    please provide more information about the security that you have and whats inside your pacakge/

    I had the same problem and it was security, and permissions

    Sincerely SH -- Please kindly don’t forget to mark the post(s) that answered your question and/or vote for the post
    Thursday, July 30, 2009 3:23 PM
  • 1314 = "A required privilege is not held by the client."

    It is the SQL Agent account with the trouble perhaps, and not just the proxy account.

    Make sure you reset the SQL Server service account by using the Configuration Manager, so that the service account you choose gets added into SQLServer2005SQLAgentUser$<machine_name>. If the current service account for SQL Agent is not in that group, add it to that group manually, or swap the service account to local system, save, then swap it back again to the desired account and type the password (using configuration manager)

    You may have missed a couple of the user rights (administrators group may not include these privileges)

    - Log on as a service (SeServiceLogonRight)
    - Act as part of the operating system (SeTcbPrivilege) (only on Windows 2000)
    - Log on as a batch job (SeBatchLogonRight)

    - Replace a process-level token (SeAssignPrimaryTokenPrivilege)
    - Bypass traverse checking (SeChangeNotifyPrivilege)
    - Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)

    Thanks, Jason

    Didn't get enough help here? Submit a case with the Microsoft Customer Support team for deeper investigation - http://support.microsoft.com/select/default.aspx?target=assistance
    Friday, July 31, 2009 6:09 AM