![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I am getting Error. Non-SysAdmins have been denied permission to run DTS Execution job steps without a proxy account. The step failed. How can I fix this. Thank you -- Jerry |
#3
| |||
| |||
|
#4
| |||
| |||
|
|
Hi Jerry, My understanding of your issue is that: Your SSIS package failed to run from a SQL Server Agent job step, but it could run from Development Studio. The error was: Login failed for user 'cdaccess'. [CLIENT: <local machine>] If I have misunderstood, please let me know. This is most likely a known issue in SQL Server 2005, and a KB article has been released for this issue. There are five approaches available to fix this issue: Method 1: Use a SQL Server Agent proxy account Create a SQL Server Agent proxy account. This proxy account must use a credential that lets SQL Server Agent run the job as the account that created the package or as an account that has the required permissions. This method works to decrypt secrets and satisfies the key requirements by user. However, this method may have limited success because the SSIS package user keys involve the current user and the current computer. Therefore, if you move the package to another computer, this method may still fail, even if the job step uses the correct proxy account. Method 2: Set the SSIS Package ProtectionLevel property to ServerStorage Change the SSIS Package ProtectionLevel property to ServerStorage. This setting stores the package in a SQL Server database and allows access control through SQL Server database roles. Method 3: Set the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword Change the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword. This setting uses a password for encryption. You can then modify the SQL Server Agent job step command line to include this password. Method 4: Use SSIS Package configuration files Use SSIS Package configuration files to store sensitive information, and then store these configuration files in a secured folder. You can then change the ProtectionLevel property to DontSaveSensitive so that the package is not encrypted and does not try to save secrets to the package. When you run the SSIS package, the required information is loaded from the configuration file. Make sure that the configuration files are adequately protected if they contain sensitive information. Method 5: Create a package template For a long-term resolution, create a package template that uses a protection level that differs from the default setting. This problem will not occur in future packages. For more detailed information, please refer to this article for the resolution: An SSIS package does not run when you call the SSIS package from a SQL Server Agent job step http://support.microsoft.com/default...b;EN-US;918760 If this issue persists, I recommend that you describe me your process detailed so that I can reproduce your issue for further research. If you have any other questions or concerns, please feel free to let me know. It is my pleasure to be of assistance. Charles Wang Microsoft Online Partner Support PLEASE NOTE: The partner managed newsgroups are provided to assist with break/fix issues and simple how to questions. We also love to hear your product feedback! Let us know what you think by posting - from the web interface: Partner Feedback - from your newsreader: microsoft.private.directaccess.partnerfeedback. We look forward to hearing from you! ================================================== ==== When responding to posts, please "Reply to Group" via your newsreader so that others may learn and benefit from this issue. ================================================== ==== This posting is provided "AS IS" with no warranties, and confers no rights. ================================================== ==== |
#5
| |||
| |||
|
#6
| |||
| |||
|
![]() |
| Thread Tools | |
| Display Modes | |
| |