September 12, 2019 at 2:42 am
I am not sure if this is something possible, i would like to map a share to a drive letter using a particular login and if that login tries to hit that server remotely it should be able to see that mapped drive.
September 12, 2019 at 3:08 am
Please explain what you mean by "hit that server remotely". Is this from within SQL Server? What is the purpose of this?
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
September 12, 2019 at 3:17 am
This is related to another post i have , copy/pasting here
"In a nutshell we have a package stored in SSIS catalogue on Server – S1 which reads files from Server – S2 ( NAS share) and then the package stored in SSIS catalogue is executed via a C# app from Server – S3. All the servers are in the same domain and the process account executing package on S3 has full access to the NAS location on S2. Package is failing with an error message saying it cannot access the share, my hunch is the creds that is initiating the call from C# app is not propagating all the way to the NAS share, basically when it hits the NAS share the login is something like NT\Anonymous. Looks like enabling delegation at the account level should fix this issue, is that the only solution. Also i think i will need to create SPN, what do i create SPN to? Is it the SSIS service?"
I do have a work around, from server S3 i am using a execute SQL task and passing net use along with user name and password, there on all the tasks are able to use that share. Big concern is password is clear text, i know how to encrypt password using ps but then executing ps script via been a pain in neck.
September 12, 2019 at 3:22 am
I do have a work around, from server S3 i am using a execute SQL task and passing net use along with user name and password, there on all the tasks are able to use that share. Big concern is password is clear text, i know how to encrypt password using ps but then executing ps script via been a pain in neck.
Have you considered storing the password in a sensitive SSISDB environment variable and picking it up at runtime via a package parameter?
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
September 12, 2019 at 3:23 am
Not sure, how would that help in mapping a remote share? Any examples would be helpful
September 12, 2019 at 12:47 pm
Not sure, how would that help in mapping a remote share? Any examples would be helpful
My response was based on this comment by you:
I do have a work around, from server S3 i am using a execute SQL task and passing net use along with user name and password, there on all the tasks are able to use that share.
ExecuteSQL tasks can use sensitive parameters ...
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
September 12, 2019 at 3:19 pm
This might help: https://stackoverflow.com/questions/182750/map-a-network-drive-to-be-used-by-a-service/4763324#4763324
If you want a mapping to persist, there's a flag. You need to be logged in as the user to do this.
September 17, 2019 at 6:16 pm
I tried, looks like i may be running into double hop issue. Basically i wanted to map a share ( not drive ) outside of SSIS package so that all other processes can just use that share.
September 17, 2019 at 7:09 pm
Interesting. If you solve it, love to know (or get an article on the solution)
September 18, 2019 at 11:02 am
Would this do it?
https://ilovepowershell.com/2012/09/19/create-network-share-with-powershell-3/
Top of the page on DuckDuckGo "powershell create share"
September 18, 2019 at 7:57 pm
I did see that, doesn't really help. Let me know if this works for you:
i) On Server ( S1 ) map the share ( \\Server (S3)\temp) with a user U1 credentials
ii) On server (S2), deploy simple SSIS package in SSIS catalogue on S1 which reads file from share pointing to S3 and writing back to a db on S1 and execute that package via t-sql ( SSMS) or any other app under user U1.
Most likely you will notice that even on S1 you have mapped a share under user U1 creds, you will not able to access the share with SSISDB catalogue even though u are executing the package as user U1, double hop issue.
I was looking for a way to map this share ( not drive ) before hand and be able to remotely access for U1. I have a work around, i am still trying to come up with better solution.
September 19, 2019 at 1:06 pm
Sorry, I was just trying to help and that link sounded like exactly what you were after.
I did not try it, and shares are "discouraged" on our network.
To be honest, I gave up on SSIS with SS2008, it seemed to be a ridiculously more complicated version of DTS (which was already kludge-y, IMHO).
I just do everything in PoSh now.
September 19, 2019 at 2:57 pm
SSIS Vs any other tool is a whole another discussion :). I strongly believe in using right tool for the right job without going too crazy.
I was able to use PS script with encrypted creds to map the share, i was also able to execute the same package with different variables in parallel. I will probably document this on my blog .
Thanks
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply