I have a SQL Server 2019 with SSIS and I want to execute SSIS packages using SQL Agent jobs with proxy domain accounts.
Currently my sample SSIS packages are failing, all simply stating "Unexpected termination", with no additional errors in Basic or Verbose logging modes. Packages are doing various tasks, working with both local and remote files, all permissions to read/write to folders and files are set.
In the Event Viewer I can see the "The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID" for my proxy account.
Adding the proxy accounts to local Administrators group on VM solves the issue, but I would like to evade doing this.
Instead I have:
added permissions for my proxy accounts in Component Services/DCOM Config/Microsoft SQL Server Integration Services 15.0/Launch and Activation + Access + Configuration permissions
added proxy accounts to Distributed COM Users group. (basically following the SSIS Service MS Documentation these two solve the COM Server error)
granted local permissions to proxy accounts (Log on as a batch job, Log on as a service, Allow log on locally)
but I'm still ending up with Unexpected termination with no further errors/warnings and no further errors/warnings in event viewer as well.
Can anyone advise me what other (Windows) permissions am I missing so I don't have to resolve it using local Administrators group? Or where else I might find additional logs to search for errors?
Related
I am testing the azure file share with SSIS hosted on Azure VM. However, I am facing an issue while running the job.
Package execution through Visual Studio is successful
Package execution through catalog also is successful
Package execution through the Job is FAILING with the error The File Name "\.windows.net<FolderName>\file.csv" specified in the connection was not valid
I tried running the job with the proxy account having access to the Azure share folder (Same account used to run the package), however it failed with the same error.
Both UNC and as a mapped drive was tested.
Any suggestion or advice on this will be highly appreciated.
Thanks in advance.
Try giving read/write permissions (For the Azure share folder) to the SQL Database Engine Service account NT SERVICE\MSSQL$<Instance Name> and NT SERVICE\SQLSERVERAGENT (Where <Instance Name> should be replaced by the installed instance name):
Configure File System Permissions for Database Engine Access
Also, feel free to read more about SQL Server service accounts in the following documentation:
Configure Windows Service Accounts and Permissions
I have an extremely simple SSIS package on my SQL Server 2017 database instance, running via an agent job. I have created a credential and proxy account to run the integration service job. If the job owner is 'sa' the job will run fine. however if I change the job owner to the service account I need to have I get the following error:
The job failed. Unable to determine if the owner (THE_FUND\xyz_svc) of job MYPITAJob has server access (reason: Could not obtain information about Windows NT group/user 'THE_FUND\xyz_svc'<c/> error code 0x5. [SQLSTATE 42000] (Error 15404)
Additionally the service account is a local admin on the server, and sysadmin in sql server in an attempt to remove possible permission issues.
I created a credential using the service account as its identity. Then created a proxy account under SSIS Package Execution referencing the credential i created.
Would love to know what I am missing.
As it turns out the issue was related to Active Directory. The service account had no registered OU. Once the service account was removed, and recreated the OU was populated and everything with the SQL Server jobs started working. I guess sometimes SQL Server is not to blame. Once SQL Server was able to find the information it needed from AD, problem solved.
So we have a network address lets call it the Z drive that everyone has access to.
By everyone I mean the entire organization. For completeness, I actually went ahead and gave access to the actual SQL Server Agent.
The package runs fine on dev, but always fails with
The directory "Z:\SSIS_Test" does not exist
At first, I thought it was an issue of access. But how can't the SQL Server Agent access an everyone drive?
Also, I went in and run the package on the server myself as the caller and it still failed with same error. What gives? Am I not getting something?
Possible solutions
(1) Granting service accounts
Try giving read/write permissions to the SQL Database Engine Service account NT SERVICE\MSSQL$<Instance Name> and NT SERVICE\SQLSERVERAGENT (Where <Instance Name> should be replaced by the installed instance name):
Configure File System Permissions for Database Engine Access
I was facing the same issue, it looks like the "everyone" permission does not take into consideration service accounts (I am not sure). The issue was solved after granting the database engine and SQL agent service accounts. Also feel free to read more about SQL Server service account in the following documentation:
Configure Windows Service Accounts and Permissions
(2) Mapping drive within SQL Server
You can refer to the following article for more information:
Make Network Path Visible For SQL Server Backup and Restore in SSMS
Or you can try to use the full UNC path instead of the mapped drive.
If these solutions didn't worked, there are many other suggestions listed in the following answer, you can check it for more information:
SSIS File System Task Error while copying files between servers
I am attempting to deploy an SSIS package to a server. I can build connection managers to the target server and databases on that server. However, attempting to deploy the error appears:
There is an spn problem here: "The target principal name is incorrect." This typically happens when the SQL service originally ran under the Local System account and then was changed to a domain account. When running under the Local System account, sql-server registers an spn for every service it controls automatically up to active-directory, and attempts to unregister them when the service shuts down. The Local System account has the ability to communicate over the network as the computer account and thus can indicate to Active Directory as to when to make changes about itself and the SPN SQL Service wants to register. When you change the SQL Server account over to an AD domain user account, the Local System account immediately loses it's ability to control this; therefore you must manually delete the existing SPNs previously registered for that SQL service by Local System before registering new SPNs.
The Microsoft Kerberos Configuration Manager for SQL Server tool Hadi mentioned will, when run, very helpfully generate a script to fix the SQL service SPN from the command line. From the tool's instructions:
To Generate SPN List from Command Line:
Go to command line.
Switch to the folder where KerberosConfigMgr.exe
is.
Type KerberosConfigMgr.exe -q -l
For more command line option, type KerberosConfigMgr.exe -h
The SQL server script will call for deletion of old SPN(s) followed by the registration of new one(s) in order to fix issues. Until this is done you'll continue to get an authentication error when the kerberos clients obtain a ticket for the old invalid SPN - because it was never deleted and any Kerberos-aware service will always reject a ticket for a wrong SPN. After you make SPN changes, always be sure to restart the SQL Server service and right after that if you’re testing with a user have that user log out and log back in.
According to this Microsoft support article:
"Kerberos Configuration Manager is a diagnostic tool that helps troubleshoot Kerberos-related connectivity issues with SQL Server. These issues may trigger errors such as "Cannot generate SSPI context." "
You can get more info at :New tool: "Microsoft Kerberos Configuration Manager for SQL Server" is ready to resolve your Kerberos/Connectivity issues
I have created an SSIS package that will be deployed to client SQL installations (2005, 2008 or 2008 R2) to perform data extracts which provide a support tool for our product. The deployment process requires that a Windows AD account (normal user, no elevated privileges) is created as this is used as a service account to execute the SSIS package in a SQL Agent job by way of a credential and a proxy account. This all works perfectly and means I can restrict the privileges required to perform this job.
However, I wanted to include error logging in the SSIS package to the Windows Event Log. When I run the package in BIDS (which of course uses my own credentials) and force the failure of the package, it logs just fine. When I force the package to fail (by putting a duff connection string into the config file) whilst being run by the SQL Agent job, nothing is logged. The service account is being used and it is an authenticated user on my SQL Server host machine but it will not write to the event log. If I add the service account to the local administrators group, it writes to the log just fine, but I thought the idea of the Windows event log was that you did not need elevated privileges to write to it?
Our support teams are keen to use the Windows Event Log but I can see no way of doing so without granting high privileges to a service account which I would rather not do. Am I missing something? The Logging tab in the SSIS job step page doesn't seem to do a lot but perhaps that's what I'm missing?
Apologies if this is more suited to ServerFault, but I couldn't quite decide which side of the line this fell as it is a problem encountered during development. If it is then I'll relocate it.
Many thanks
Steve
If OS is 2003, check the SDDL syntax on who has access to write to the log with this: http://support.microsoft.com/kb/323076
If 2008, you can use wevtutil instead of manually typing in SDDL:
http://support.microsoft.com/kb/2028427
The service account can be given the permissions using the above.