I have an SSIS 2008 package running on Win 2008 64-bit server. The package has an Execute Process Task that runs a net use command using cmd.exe to make a connection. This runs successfully when tested from the command prompt and runs successfully when the package is run in Visual Studio 2008. However, when the package is called from a SQLAgent job the package fails with the error (actual servernames and passwords removed): Failing Task Name = EPT Connect mapped drive Error Code = -1073573551 Error Detail = In Executing "C:\WINNT\system32\cmd.exe" "/C net use \\servername\foldername /USER:userid password" at "", The process exit code was "1" while the expected was "0". I have determined that a successfull connection should provide a exit code of 0. The job runs under a proxy account but as explained when the package has run from within VS 2008 it was also tested to run under the proxy account and is successful. It is not a 64-bit issue as I have tested it by running the package using the 32-bit version of dtexec.exe and the same problem occurs. Also I have found that by running a simple command process within the Execute Process Task such as dir *.* it is successful when run from the job indicating that it is in fact something related to the net use command itself when run from inside a job. I have run out of ideas to pursue this - would appreciate anyone's help ?

Let's back up a second, OK? I need to ask this: WHY are you needing to have a mapped drive? Best Practices for connecting to resources in SSIS packages says that you should use the full path of \\<server name>\<share name> instead of mapped drive letters. (I realize this may not answer your direct question, but may instead lead you to better desing practices, eliminating the issue all together.)Todd C - MSCTS SQL Server 2005 - Please mark posts as answered where appropriate.

Hi Paul R W, Based on my testing, while running the package under a SQL Server Agent proxy account, the password in the arguments can't be verified. The workaround to fix the issue is that: Run the SQL Server Agent service under a domain account. Run the step for the package under the SQL Server Agent service account. If you have any more questions, please feel free to ask. Thanks, Jin Chen

In response to Todd: The package is using the full path of \\server name\share name and not actually uisng mapped drive letters. Apologies for the confusion but that is what I meant by having to map a drive. In response to Jen: I'm glad that you have been able to reproduce the issue but I'm not sure the workaround would be excepted by the DBA's as this goes against the principle of least privilege. All the packages run under a proxy account rather than the SQL Server Agent service account, although granted I suppose it could be argued that the package does require this higher privilege in order to run because the password in the arguments can't be verified. I will run it by them but I'm not confident :-( However, this does seem to me to be an issue of sorts with the Execute Process Task and SQL Server Agent.

However, this does seem to me to be an issue of sorts with the Execute Process Task and SQL Server Agent. How are you defining the steps in the SQL Agent job to run the SSIS Package? Are you using the built-in option of "SQL Server Integration Services Package" or are you selecting something else like "Operating system (CmdEXE)"?Todd C - MSCTS SQL Server 2005 - Please mark posts as answered where appropriate.

Todd's on the right track here. You need to use the CmdExec step type to run the package - running it under the SSIS Job Step Type doesn't create a full user environment, so you can't use or create mapped drives.John Welch | www.varigence.com | www.agilebi.com | ssisUnit.codeplex.com

I'd already tried by running it both methods ie. as a SSIS Job Step type and using CmdExec but the end result is still the same.

If your package isn't using mapped drives, then what's the "net use" for? Talk to me now on

Isin't this already answered above ? It's using a mapped drive but not mapped drive letters as explained.

I'm not understanding why mapping a drive even came into the picture then. Is this not relevant information? It's been asked a couple times - why are you mapping a drive? Please explain what you're trying to accomplish with that... Talk to me now on

The FTP server on which we are connecting too has Unix running on it. This has Samba installed on this Unix Server in order to allow file sharing between computers running Windows and Unix. With Samba installed on the Unix server, the Windows File Server is then able to map Unix directories as shares in Windows. In order to make a connection to this share it is necessary to map a drive (because of where this Unix server sits in the domain on an old NT Server I believe). Therefore in the SSIS package we provide the necessary user id and password to connect to this Samba share. This works successfully except when the package is run from SQLServerAgent.

Ah - I think I understand. I have a similar setup, I think - a Samba share to a *NIX box. I don't know how much I can help you - cause I don't connect to that with SSIS, in or out of a job. But this is my experience: Mapping a drive isn't necessary - authenticating to the Samba share is. An easy way to do that is to map a drive, no question, but I wouldn't say it's something you need to do. Just trying to access the UNC should be enough to trigger an authentication challenge. Anyway, the problem is likely the same. Maybe we can try to break this down a little more. Can you make a SQL Agent job without any SSIS package runs in it? Just put a job step in to dump a DIR of the Samba location to a local text file. (I'm not clear if that's what you've already tried.) If that works, try a simple OS file copy from a local to the share and vice versa. Any/all of those should require the same permissions that running a package that accesses the share should need... I'd think. Talk to me now on

Apologies for the late response. I have sidetracked on other work (and TechEd). I should be in a position to give this a try in the next week or so and will post on the outcome. Thanks.

Hi Guys, Any resolution to this problem yet? I'm having the same issue, cannot map to a samba drive within an SSIS package called from a job or within a job itself being run as my SQL Service account which is also an admin to the DB.

Anyone resolve this yet.... I too have the same issue.

avoid using mapped network drives inside your SSIS package for things like file paths, control flow settings, log file locations, etc Instead use UNC path notations. (\\server\share\directory) if youre always running an SSIS package by hand using dtexec.exe, or through Business Intelligence Development Studio (BIDS), dtexecui.exe, etc you dont really have to worry about this.However, if youre running the package via a scheduler such as SQL Agent, youll run into perceived permission problems, or reports that files cannot be found. The issue with schedulers such as Agent is that they run under a service account that does not have access to mapped network drives. Mapped network drives are set up for your user-session when you log on to a computer. Even if you log in with the same account that the SQL Agent service uses, the service will still not have access to any drives you map because the service does not have access to the drives in *your* session.

Yes, as I've said, this is an authentication issue to the *NIX box. You should be using UNCs. In order for a UNC to work, the account executing the SSIS package must have appropriate permissions to get at the share. You probably need to set up a Proxy account to run the SSIS job step. Talk to me now on