# SSIS with CData SSIS Components for Gmail fails when run on SQL server when run with proxy account **URL:** \ **Category:** CData Drivers\ **Tags:** question, ssis, gmail, sql-server, cdata\ **Created:** [May 21, 2025, 4:14pm UTC](https://community.cdata.com/t/ssis-with-cdata-ssis-components-for-gmail-fails-when-run-on-sql-server-when-run-with-proxy-account/1096 "2025-05-21T16:14:41Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![GritKit](https://avatars.discourse-cdn.com/v4/letter/g/ad7895/32.png) [@GritKit](https://community.cdata.com/u/GritKit)\ **Post date:** [May 21, 2025, 4:14pm UTC](https://community.cdata.com/t/ssis-with-cdata-ssis-components-for-gmail-fails-when-run-on-sql-server-when-run-with-proxy-account/1096/1 "2025-05-21T16:14:42Z")
The SSIS package runs fine on my local computer, but it fails with the following errors when run on the SQL Server. ![1452833a-dcbb-413b-9031-991c557f72db.png](https://us1.discourse-cdn.com/cdata/original/2X/8/8c9fe2329d42a9c5dae6f542715fd8fc95f834f5.png) Here is our setup: - Google API Client ID + Client Secret have been generated using **service account**. - SSIS package is run by an SQL Agent Job using **proxy account**. - Path to OAuthSettings.txt is specified as **C:\Users\Public\Documents\GMail**. Once I had the OAuthSettings.txt generated, I placed a copy to C:\Users\Public\Documents\GMail on the SQL server. - On my local computer I had run SSIS in Visual Studio and created a consent using the **service account** that I created Google API Client ID with. - SQL Server is on-prem and is accessible via RDC. - No Visual Studio is installed on the SQL Server. Am I missing anything in the above? Please advise. ---
**Author:** ![Ethem\_Q](https://sea3.discourse-cdn.com/cdata/user_avatar/community.cdata.com/ethem_q/32/1997_2.png) [@Ethem\_Q](https://community.cdata.com/u/Ethem_Q)\ **Post date:** [May 23, 2025, 10:06pm UTC](https://community.cdata.com/t/ssis-with-cdata-ssis-components-for-gmail-fails-when-run-on-sql-server-when-run-with-proxy-account/1096/2 "2025-05-23T22:06:09Z")
Hi ​ @GritKit The error message that you are getting _“[500] OAuthClientId and OAuthClientSecret are needed to initiate OAuth”_ is normally thrown when the OAuthClientId and OAuthClientSecret connection properties are missing in the connection manager. It could be that these connection properties which are considered sensitive are being cleared when the package is ran because of the ProtectionLevel of the package. Can you confirm what value you have set for the ProtectionLevel? ![61fe8a34-bfd7-4564-adf5-d4d7d6c24c92.png](https://us1.discourse-cdn.com/cdata/original/1X/501b76099bce3a862d872ed3a2942320f3d0b361.png) You might want to read more on possible recommendations how to fix the issue below: > **[SSIS package does not run when called from a job step - SQL Server](https://learn.microsoft.com/en-us/troubleshoot/sql/integration-services/ssis-package-doesnt-run-when-called-job-step)** > > This article provides resolutions for the problem that occurs when you call an SSIS package from a SQL Server Agent job step. If you have any other questions or issues you can reach out to the support team at [support@cdata.com](mailto:support@cdata.com) and one of our support specialists will further assist you. ---
**Author:** ![GritKit](https://avatars.discourse-cdn.com/v4/letter/g/ad7895/32.png) [@GritKit](https://community.cdata.com/u/GritKit)\ **Post date:** [May 28, 2025, 8:50pm UTC](https://community.cdata.com/t/ssis-with-cdata-ssis-components-for-gmail-fails-when-run-on-sql-server-when-run-with-proxy-account/1096/3 "2025-05-28T20:50:49Z")
​ @Ethem_Q  , thank you for your quick response. Your solution did not work for me due to my specific setup, but it helped me to find what works. I had **EncryptSensitiveWithUserKey** protection level set by default, but I also had the Client Secret being removed from the package when deployed to the server. Our packages are stored in SSISDB database, not physically on the server. Here is what works in my case: 1. I created a **project parameter** and instructed the CData Gmail Connection Manager to use it for **OAuthClientSecret** property instead of a hardcoded Client Secret Value (that would be automatically removed during deployment). 2. Then I added a code to my SQL Server configuration script to create this project parameter on the server. As a result, when the package gets deployed to the server, its Client Secret value is being supplied from the project parameter. 3. Since I no longer had sensitive data stored in the package, I set the **ProtectionLevel** to **DontSaveSensitive**.