I have one package which loads data from excel using ace.oledb.12.0 driver to SQL server(same server where SQL agent service is running.).
When I ran this Step from SQL Agent using Infrastructure Service account it succeed.
When I ran this step using a credential account it is stopping the job as a failure 'Unexpected Termination'.
Funny part is this is running exactly fine for files with data size low(100kb-300kb) when run from both Infrastructure Service account and a Credential account.
But for my current file having size 4.5 mb it is failing via Credential account.
Is there a way I can capture why the job is getting terminated?
Disclaimer: I work for ZappySys
Looks like you need to find out detailed error message to know more. Did you deploy package using SSIS Project Mode in SSISDB or running as File System Package? When you run SSIS Package via Agent Job you will see very limited error message and many times its useless. So better to run package under SSIS Catalog so you see full execution log. If that is not possible then try to Add Some SSIS Log Provider (see below) for better logging on error messages.
How to add SSIS Log Provider in your package
How to view execution log in SSIS Catalog (See Step#10 in this link)
Related
I'm working on extracting data from a https get api. I am using the Power Query source in SSIS (SQL Server 2017 and SSDT 2017)
Everything works fine when I run the package locally. When I deploy and run the package on the server I get the following error:
Error: The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread's user context, which may be the case when the thread is impersonating.
I'm able run the package on the server with a C# extract with no issue. I would like to move away from the script task as the Power Query source is much faster.
Suggestions are very much appreciated.
This issue is resolved by using a Service Account that has sysadmin on the SSIS server. I believe this has something to do with the API using https.
I created a SSIS package that watches for files being created on another server using a WMI Event Watcher Task. This package works fine when I run it in VS. It works fine when I manually Execute it from the Integration Services Catalog. When I try to run it as a scheduled SQL Agent Job I get
Error: Watching for the Wql query caused the following system exception: "Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))". Check the query for errors or WMI connection for access rights/permissions.
My question is why does this not run as a SQL Agent Job when I can run it successfully several different ways? Based on the error code seems to be a COM/DCOM security issue.
So far I have:
Tried many web sites most are more or less like this
https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-troubleshooting?redirectedfrom=MSDN I have followed all the instructions on these websites with no change.
Gone back and gave even more permissions then specified by the website to the COM Limits and DCOM Config of the Windows Management and Instrumentation.
Have restarted the WMI service on the other server several times after each change.
Tried SA and myself as owner of the Job.
Tried my usual SQL Agent Proxy account and the default Server Agent Service Account (which is a Managed Service Account) as the Run As for the package.
Tried running as a 32 and 64 bit runtimes.
Have made the SQL Agent Proxy account and Server Agent Service Account Admins on the other server.
Tried hard coding my user name and password into the Connection Manager and used Windows Authentication.
* New tests *
Tested the SQL Agent Job using the File System as the package source instead of the SSIS Catalog, still failed with same error.
Tested running package using the Execute Package Utility and it worked!
The AgentSqlServer user does not have rights to launch WMI Querys on server, You should create a proxy account and join it à to the step on the SQL Job.
I am tearing my hair out with this particular issue, I have used SQL Agent Jobs for years and know there can be issues with permissions which I have always got around. But this issue I can't fathom. I am importing data from an Access Database to SQL Server via a SSIS package, I have had it successfully run via a SQL Job with no problem (using a proxy account). I need to change the login that runs the jobs, this has been set up with the same permissions and runs various jobs like running stored procedures. But when it tries to run the SSIS package it will not have it and I get a failed validation and returned error code 0xC020801C. It has exactly the same permissions, so why would it fail when I change the windows login account for the proxy? Any help would be hugely appreciative
Here is the short version of the problem: I have a discrete DTSX file that works fine on our Production server, but doesn't on our new Dev server.
Symptom: When run from a SQL-Server job, the job starts and nothing at all happens, and it never finishes... it just hangs, using very little system resources.
Some info: For Prod, the packages were developed on SQL-Server 2012 and run on an NT 2008 server. The new Dev server is also SQL-Server 2012, but runs on an NT 2012 server (in case that matters). I have duplicated the folder/file structure exactly, including drive name. The package uses an external dtsConfig file, but as I said - the folder/file structure is identical.
The SSIS service, SQL-Server Agent, and my remote login are all the same, and is a member of the server Administrator group on the Dev box. If I copy the command line text from the SQL job and run it in a CMD window using dtexec.exe, the package executes correctly. The job owner is my login, and the "run as" is the SQL-Agent, which - as I mentioned - is the same login. Since everything in the package uses integrated security, everything should be running using the same login whether on the command line or via the SQL-Agent, which should eliminate any user permission/credentials issues.
I tried adding SSIS logging to the package, logging everything I could. When I run the package from the command line, I get a ton of messages in the log. When I run the package via the SQL job, there are no messages at all in the log - nothing.
Whatever is going on, it's not getting far enough into the SSIS package to generate a single log entry. It's just stopping but not exiting or throwing an error. FWIW - I have the same problem with every other package I've tried.
Any ideas are appreciated...
I found the cause of the problem. The MS-SQL Server service was using a different login than the SSIS server service and the NT Agent service (it was using a local service account).
Once I changed the MS-SQL Server login to match the others (and restarted the service), the job ran correctly.
I am trying to schedule a SSIS2014 package via SQL Server Agent job. Both SSIS and SSMS are running on my local machine in the same domain. I am running SSMS with the same user Domain\Admin which is the creator of the SSIS package. SSMS 32-Bit and SSIS 32-Bit are running on Windows 7 64-Bit machine. I can run the package within SSIS without problems.
Using Microsofts KB article http://support.microsoft.com/kb/918760 and tutorial video http://technet.microsoft.com/en-us/library/dd440760%28v=sql.100%29.aspx I tried a couple of methods (proxy, configuration file, EncryptSensitiveWithPassword) but none of them worked for me.
When I use a proxy account to run the job step, the following message occurs:
Unable to start execution of step 1 (reason: Error authenticating proxy
`Domain\Admin`, system error: Logon failure: unknown user name or bad password.).
The step failed.
The proxy account uses the credentials identity Domain\Admin. Since the password fields for credential properties in SSMS cannot be left blank, I typed any password although my corresponding windows account has no password. So as mentioned above it's the same user account that created the SSIS package since Domain\Admin is stated in the CreatorName property of the SSIS package.
With this proxy, I tried to run SSIS jobs using the package ProtectionLevel's EncryptSensitiveWithUserKey and EncryptSensitiveWithPassword. Running the package manually within SSDT without problems, but from SSMS agent job the same error message appears. I tried the package sources "File System" and, after importing the package to MSDB, "SQL Server" and "SSIS Package Store". But exactly the same error message appears with each method.
Task manager shows that SSMS is running in administrator mode. Using Windows Component Services I added DCOM permissions for Domain\Admin to start and activate "Microsoft SQL Server Integration Services 12.0" from local. But the same error message appears. So in my opinion it's a problem with SSMS user account permissions (???) but unfortunately I don't know what exactly to do here. I tried the following:
In the system database MSDB (full path: Databases / System Databases / MSDB / Security / Logins) I assigned all available role memberships (Including db_ssisoperator, db_ssisltduser, db_ssisadmin) to Domain\Admin.
In server security (full path: Security / Logins) I assigned all available server roles. In the tab User Mapping, I assigned the MSDB database.
Still the same error message appears when I try to run the job. Does anybody have some ideas what I can try?