Anybody knows how to handle this.I deployed a SSIS.Then I create a job in which I add the config files.When running the SSIS, the config files used are the ones the developper was using instead of the ones defined in the job.I tried, redeploying, redefining the config files, deleting and recreating both the job and the ssis. Still, the config files I define are not used. When looking at the sql generated, the files are the adequate ones. However, at run time, I receive the message for a different file then the one defined: If I script the job and look at the command I get: @command =N'/SQL "\Import" /SERVER SQLSVR /CONFIGFILE "E:\Mssql\SSIS\Import\Configuration\LIVE\cnfg_Import_Properties.dtsConfig" /CHECKPOINTING OFF /REPORTING E', When looking at the generated log file, I get:OnWarning,SQLSVR08,GREGORY\IntServices,Import,{A08A9F3D-1DDB-4AAC-8791-371AD44D3B65},{3C719D08-E954-4396-A5B6-A76910E27ED9},1/6/2010 11:00:17 AM,1/6/2010 11:00:17 AM,-2147409902,0x,The configuration file name "C:\WD\Development\Main\SSIS\Import\Import\cnfg_Import_Properties.dtsConfig" is not valid. Check the configuration file name.Is there something I can do to force the usage of the config file defined at the job level and to forget the one the developper was using on his local computer?

Hi, is this your configuration file name "cnfg_Import_Properties.dtsConfig" ? As i know this should be a xml file. can you please cross check? Thanks- Let us TRY this | Dont forget to mark the post(s) that answered your question

Yes, the file is present under the same location and name and is of xml format.The file was created using the visual studio "Package Organization Manager" (right click in ssis package and click on package configurations...). By default, it creates files with extension .dtsConfig.I did edit it afterward to reflect the environment on which the ssis is deployed.

Is the E drive a local drive or a mapped network drive? (it won't work if it is a mapped drive) Does the ID running the job have access to that e:\ drive?Make sure you check the permissions of the ID running the job over the config file location and to be safe use a UNC path instead.http://rafael-salas.blogspot.com | Dont forget to mark the post(s) that answered your question

After the .dtsCofnig is created, can you remove the package configuration reference (i.e. created by the developer) used in the package?Thanks.

The E drive is local to the computer running the ssis and is accessible to sql agent service user. I do use a proxy in the step however and this one does not have access. Other ssis do not need access for the proxy either however.With regards to removing the file, do you recommend a specific method to do it. The Deactivating the package configurations alltogether, removing the file from the list of packages file using visual studio or some other method? What would happen if I remove the configuration file from the design interface but still provide it from the sql job?

With regards to removing the file, do you recommend a specific method to do it. The Deactivating the package configurations alltogether, removing the file from the list of packages file using visual studio or some other method? What would happen if I remove the configuration file from the design interface but still provide it from the sql job? You can use BIDS and remove the configuration references in the packages.If you remove these configuration references within the package, the configuration that you specify in the SQLAgent job is used.

The E drive is local to the computer running the ssis and is accessible to sql agent service user. I do use a proxy in the step however and this one does not have access. Other ssis do not need access for the proxy either however. So, you are acknowledging that the proxy account does not have access to the drive where the config file is stored. I may be missing something, but I would not expect the package to be able to apply package configuration if the account running it does not have access to the config file.http://rafael-salas.blogspot.com | Dont forget to mark the post(s) that answered your question

Adding permissions to the proxy user did not change the result.I will give a try to removing the files at design time.

Here are the two things I noticed which allowed me to fix this issue. 1 - The fact that the SSIS executed by the job was looking for the developper configuration file has no real impact other than generating warnings. To avoid this error, uncheck the configuration pagackages and build the project before deploying it. When deployed, the SSIS will stop looking for that file and rely only on the one defined in the job. 2 - When a property exists in the configuration file which is not present anymore in the ssis, the configuration file is just plain ignored at execution time. Rather than ignoring this particular property, the complete file is ignored altogether. This is the reason why my configuration defined in my configuration file were not taken into account. To fix, make sure all property in the configuration file exists in the properties of the SSIS. :(