Mike Dwyer
asked on
SSIS Package Configuration Warning: Failure importing configuration file
I am seeing a strange behavior in my SSIS package when using a network UNC for my package configuration. I’ve created a package configuration that looks to a network path for its configuration file. When I try to run this package from the designer I receive the warning that the configuration file cannot be found and failure importing configuration file. I’m using SQL Server 2012/ Sql Server Data Tools (aka BIDS).
When I store the configuration file on my local hard drive I get no warning. When I map the network path to a drive letter and set my path to the drive letter I get no warning. It’s only when I specify the path as a UNC.
As a further test, I created a simple package with a package configuration pointing to the UNC. I added a script task with some code that reads up the contents of that same config file specified as a UNC into a string variable. When I run the package from the designer, I still get the warnings that it can’t find the config file –but- the script task can read the contents of that config file without a problem.
This is a new one for me. Has anyone seen this behavior before?
When I store the configuration file on my local hard drive I get no warning. When I map the network path to a drive letter and set my path to the drive letter I get no warning. It’s only when I specify the path as a UNC.
As a further test, I created a simple package with a package configuration pointing to the UNC. I added a script task with some code that reads up the contents of that same config file specified as a UNC into a string variable. When I run the package from the designer, I still get the warnings that it can’t find the config file –but- the script task can read the contents of that config file without a problem.
This is a new one for me. Has anyone seen this behavior before?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
zephyr_hex (Megan)
Yes. If you can't access the network path, it's not going to work when you run the SSIS job. Also note that if you schedule the SSIS job, the account that runs the scheduled job also needs access to the path.
ASKER
Well, it can access the file using the full path.
I put a script task in the package that reads the config file contents just to prove that.
And when I was in the designer, it was able to read/write to that file when I set up the configuration in the first place.
However, I am guessing the methodology used by SSIS to load the file at runtime is doing something different and gets tripped up when trying to traverse the path, subfolder by subfolder. My guess, anyway. There's nothing on google about this.
I put a script task in the package that reads the config file contents just to prove that.
And when I was in the designer, it was able to read/write to that file when I set up the configuration in the first place.
However, I am guessing the methodology used by SSIS to load the file at runtime is doing something different and gets tripped up when trying to traverse the path, subfolder by subfolder. My guess, anyway. There's nothing on google about this.
So you could read/write using the UNC path in designer?
What account runs the job when you're not in designer, and does that account have access to the UNC path?
What account runs the job when you're not in designer, and does that account have access to the UNC path?
ASKER
Yes, there's no problem accessing a file in that folder at all....Except when SSIS tries to load the configuration.
Ok, problem solved! It was the fact that for one of the subfolders in my UNC I did not have rights to list the contents of that folder. Once I had their network folks give me rights to list contents, everything worked great. That's a strange one.
Ok, problem solved! It was the fact that for one of the subfolders in my UNC I did not have rights to list the contents of that folder. Once I had their network folks give me rights to list contents, everything worked great. That's a strange one.
ASKER
This post names the specific problem that was corrected to fix the problem.