Connecting Remote Shares via Powershell












0















I had a big problem which I just happened to solve, but it's a permissions issue I don't quite understand. Unfortunately I'm in a tight bind and no amount of googling in the past week has really helped, so perhaps someone could explain what happened here:



As part of an interface out to our customers we developed a Powershell script that maps a network drive on our web server WEB. The job step is run on a regular basis to validate the connection is active:



Connect Job



Owner: [JobsLogin]



Step 1: Connect Share



Type: PowerShell



Run as: Sql Server Agent Service Account



Command:



$ScriptsMap-Share.ps1 (My configuration values)


Map-Share.ps1



param (
[string]$DriveLetter,
[string]$Path,
[string]$User,
[string]$Password,
[string]$Persistent="No"
)
if (!(Test-Path "${DriveLetter}:"))
{
net use ${DriveLetter}: $Path /u:$User $Password /persistent:$Persistent
}


Then we run BCP to output the file to the mapped site:



declare @cmd varchar(2048)
SET @cmd = 'bcp "exec ' +
@SPName + ' " queryout "' + @DataFolder + @FileName + '.tmp" ' +
@BCPFlags
print @cmd

EXEC master..xp_cmdshell @cmd


At some point in the past week this mapping became unavailable and we started receiving the dreaded "BCP cannot open host-file" error message.



After an number of hours mapping network drives, deleting mapped network drives, running diagnostic command shell, pleading with god and then satan, checking registry values, I started to suspect that the mapped drive was not mapped for the user executing sp_cmdshell.



I ran exec sp_cmdshell "cd W:" and found that it wasn't working. I ran exec sp_cmdshell "net use" and saw that the status of W was "Unavailable". Finally, progress!



And a



exec sp_cmdshell "net use /delete W:"



exec sp_cmdshell "Powershell $ScriptsMap-Share.ps1 (My configuration values)"



later, everything works again!



But now I'm stuck, because I can't figure out how to run these commands in the job as the correct user (I've tried the services account with no success). I could change the Connect share job to run the powershell command but that seems like a hack to me (But I'm not a database guy, so maybe that is right).



Anyway, what is really going on here? What user is my drive getting mapped in the connect share job?










share|improve this question














bumped to the homepage by Community 1 min ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.




















    0















    I had a big problem which I just happened to solve, but it's a permissions issue I don't quite understand. Unfortunately I'm in a tight bind and no amount of googling in the past week has really helped, so perhaps someone could explain what happened here:



    As part of an interface out to our customers we developed a Powershell script that maps a network drive on our web server WEB. The job step is run on a regular basis to validate the connection is active:



    Connect Job



    Owner: [JobsLogin]



    Step 1: Connect Share



    Type: PowerShell



    Run as: Sql Server Agent Service Account



    Command:



    $ScriptsMap-Share.ps1 (My configuration values)


    Map-Share.ps1



    param (
    [string]$DriveLetter,
    [string]$Path,
    [string]$User,
    [string]$Password,
    [string]$Persistent="No"
    )
    if (!(Test-Path "${DriveLetter}:"))
    {
    net use ${DriveLetter}: $Path /u:$User $Password /persistent:$Persistent
    }


    Then we run BCP to output the file to the mapped site:



    declare @cmd varchar(2048)
    SET @cmd = 'bcp "exec ' +
    @SPName + ' " queryout "' + @DataFolder + @FileName + '.tmp" ' +
    @BCPFlags
    print @cmd

    EXEC master..xp_cmdshell @cmd


    At some point in the past week this mapping became unavailable and we started receiving the dreaded "BCP cannot open host-file" error message.



    After an number of hours mapping network drives, deleting mapped network drives, running diagnostic command shell, pleading with god and then satan, checking registry values, I started to suspect that the mapped drive was not mapped for the user executing sp_cmdshell.



    I ran exec sp_cmdshell "cd W:" and found that it wasn't working. I ran exec sp_cmdshell "net use" and saw that the status of W was "Unavailable". Finally, progress!



    And a



    exec sp_cmdshell "net use /delete W:"



    exec sp_cmdshell "Powershell $ScriptsMap-Share.ps1 (My configuration values)"



    later, everything works again!



    But now I'm stuck, because I can't figure out how to run these commands in the job as the correct user (I've tried the services account with no success). I could change the Connect share job to run the powershell command but that seems like a hack to me (But I'm not a database guy, so maybe that is right).



    Anyway, what is really going on here? What user is my drive getting mapped in the connect share job?










    share|improve this question














    bumped to the homepage by Community 1 min ago


    This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.


















      0












      0








      0








      I had a big problem which I just happened to solve, but it's a permissions issue I don't quite understand. Unfortunately I'm in a tight bind and no amount of googling in the past week has really helped, so perhaps someone could explain what happened here:



      As part of an interface out to our customers we developed a Powershell script that maps a network drive on our web server WEB. The job step is run on a regular basis to validate the connection is active:



      Connect Job



      Owner: [JobsLogin]



      Step 1: Connect Share



      Type: PowerShell



      Run as: Sql Server Agent Service Account



      Command:



      $ScriptsMap-Share.ps1 (My configuration values)


      Map-Share.ps1



      param (
      [string]$DriveLetter,
      [string]$Path,
      [string]$User,
      [string]$Password,
      [string]$Persistent="No"
      )
      if (!(Test-Path "${DriveLetter}:"))
      {
      net use ${DriveLetter}: $Path /u:$User $Password /persistent:$Persistent
      }


      Then we run BCP to output the file to the mapped site:



      declare @cmd varchar(2048)
      SET @cmd = 'bcp "exec ' +
      @SPName + ' " queryout "' + @DataFolder + @FileName + '.tmp" ' +
      @BCPFlags
      print @cmd

      EXEC master..xp_cmdshell @cmd


      At some point in the past week this mapping became unavailable and we started receiving the dreaded "BCP cannot open host-file" error message.



      After an number of hours mapping network drives, deleting mapped network drives, running diagnostic command shell, pleading with god and then satan, checking registry values, I started to suspect that the mapped drive was not mapped for the user executing sp_cmdshell.



      I ran exec sp_cmdshell "cd W:" and found that it wasn't working. I ran exec sp_cmdshell "net use" and saw that the status of W was "Unavailable". Finally, progress!



      And a



      exec sp_cmdshell "net use /delete W:"



      exec sp_cmdshell "Powershell $ScriptsMap-Share.ps1 (My configuration values)"



      later, everything works again!



      But now I'm stuck, because I can't figure out how to run these commands in the job as the correct user (I've tried the services account with no success). I could change the Connect share job to run the powershell command but that seems like a hack to me (But I'm not a database guy, so maybe that is right).



      Anyway, what is really going on here? What user is my drive getting mapped in the connect share job?










      share|improve this question














      I had a big problem which I just happened to solve, but it's a permissions issue I don't quite understand. Unfortunately I'm in a tight bind and no amount of googling in the past week has really helped, so perhaps someone could explain what happened here:



      As part of an interface out to our customers we developed a Powershell script that maps a network drive on our web server WEB. The job step is run on a regular basis to validate the connection is active:



      Connect Job



      Owner: [JobsLogin]



      Step 1: Connect Share



      Type: PowerShell



      Run as: Sql Server Agent Service Account



      Command:



      $ScriptsMap-Share.ps1 (My configuration values)


      Map-Share.ps1



      param (
      [string]$DriveLetter,
      [string]$Path,
      [string]$User,
      [string]$Password,
      [string]$Persistent="No"
      )
      if (!(Test-Path "${DriveLetter}:"))
      {
      net use ${DriveLetter}: $Path /u:$User $Password /persistent:$Persistent
      }


      Then we run BCP to output the file to the mapped site:



      declare @cmd varchar(2048)
      SET @cmd = 'bcp "exec ' +
      @SPName + ' " queryout "' + @DataFolder + @FileName + '.tmp" ' +
      @BCPFlags
      print @cmd

      EXEC master..xp_cmdshell @cmd


      At some point in the past week this mapping became unavailable and we started receiving the dreaded "BCP cannot open host-file" error message.



      After an number of hours mapping network drives, deleting mapped network drives, running diagnostic command shell, pleading with god and then satan, checking registry values, I started to suspect that the mapped drive was not mapped for the user executing sp_cmdshell.



      I ran exec sp_cmdshell "cd W:" and found that it wasn't working. I ran exec sp_cmdshell "net use" and saw that the status of W was "Unavailable". Finally, progress!



      And a



      exec sp_cmdshell "net use /delete W:"



      exec sp_cmdshell "Powershell $ScriptsMap-Share.ps1 (My configuration values)"



      later, everything works again!



      But now I'm stuck, because I can't figure out how to run these commands in the job as the correct user (I've tried the services account with no success). I could change the Connect share job to run the powershell command but that seems like a hack to me (But I'm not a database guy, so maybe that is right).



      Anyway, what is really going on here? What user is my drive getting mapped in the connect share job?







      sql-server-2014 permissions jobs powershell azure-vm






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Jul 15 '16 at 16:02









      C BauerC Bauer

      1085




      1085





      bumped to the homepage by Community 1 min ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







      bumped to the homepage by Community 1 min ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
























          1 Answer
          1






          active

          oldest

          votes


















          0














          Alright, so this solution has turned out to be pretty ugly. The end result is that I have to run the powershell command via the Powershell job step type and run it using xp_cmdshell in a sql job step type. Running it in both contexts guarentees the drive is mapped.



          I then run a secondary step for both environments in which I test to make sure the drive is mapped using the same logic, ie:



          Sql (CmdShell) Check



          exec xp_cmdshell 'powershell if(!(Test-Path -LiteralPath "W:")) {

          throw ("W: is not mapped")

          }'


          Powershell Check



          if(!(Test-Path -LiteralPath "W:")) {

          throw ("W: is not mapped")

          }





          share|improve this answer























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "182"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f144021%2fconnecting-remote-shares-via-powershell%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            Alright, so this solution has turned out to be pretty ugly. The end result is that I have to run the powershell command via the Powershell job step type and run it using xp_cmdshell in a sql job step type. Running it in both contexts guarentees the drive is mapped.



            I then run a secondary step for both environments in which I test to make sure the drive is mapped using the same logic, ie:



            Sql (CmdShell) Check



            exec xp_cmdshell 'powershell if(!(Test-Path -LiteralPath "W:")) {

            throw ("W: is not mapped")

            }'


            Powershell Check



            if(!(Test-Path -LiteralPath "W:")) {

            throw ("W: is not mapped")

            }





            share|improve this answer




























              0














              Alright, so this solution has turned out to be pretty ugly. The end result is that I have to run the powershell command via the Powershell job step type and run it using xp_cmdshell in a sql job step type. Running it in both contexts guarentees the drive is mapped.



              I then run a secondary step for both environments in which I test to make sure the drive is mapped using the same logic, ie:



              Sql (CmdShell) Check



              exec xp_cmdshell 'powershell if(!(Test-Path -LiteralPath "W:")) {

              throw ("W: is not mapped")

              }'


              Powershell Check



              if(!(Test-Path -LiteralPath "W:")) {

              throw ("W: is not mapped")

              }





              share|improve this answer


























                0












                0








                0







                Alright, so this solution has turned out to be pretty ugly. The end result is that I have to run the powershell command via the Powershell job step type and run it using xp_cmdshell in a sql job step type. Running it in both contexts guarentees the drive is mapped.



                I then run a secondary step for both environments in which I test to make sure the drive is mapped using the same logic, ie:



                Sql (CmdShell) Check



                exec xp_cmdshell 'powershell if(!(Test-Path -LiteralPath "W:")) {

                throw ("W: is not mapped")

                }'


                Powershell Check



                if(!(Test-Path -LiteralPath "W:")) {

                throw ("W: is not mapped")

                }





                share|improve this answer













                Alright, so this solution has turned out to be pretty ugly. The end result is that I have to run the powershell command via the Powershell job step type and run it using xp_cmdshell in a sql job step type. Running it in both contexts guarentees the drive is mapped.



                I then run a secondary step for both environments in which I test to make sure the drive is mapped using the same logic, ie:



                Sql (CmdShell) Check



                exec xp_cmdshell 'powershell if(!(Test-Path -LiteralPath "W:")) {

                throw ("W: is not mapped")

                }'


                Powershell Check



                if(!(Test-Path -LiteralPath "W:")) {

                throw ("W: is not mapped")

                }






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Jul 25 '16 at 15:05









                C BauerC Bauer

                1085




                1085






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Database Administrators Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f144021%2fconnecting-remote-shares-via-powershell%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Ronny Ackermann

                    Köttigit

                    MySQL 8.0.15 starts normally but any connection hangs