• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

file download from network share via ps1 / bat snapin non functional

Scheduled Pinned Locked Moved Unsolved
FOG Problems
4
8
2.3k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M
    mtanigawa
    last edited by Jan 3, 2017, 6:28 AM

    Server
    • FOG Version: 1.3.0
    • OS: Ubuntu 16.04
    Client
    • Service Version: 0.11.7
    • OS: Windows 7
    Description

    While not the ideal “FOG” way of doing snapins, I am having issues using a powershell script to download a file from a remote local server. Under Fog 1.2.0, I did not have an issue with the ps1 (or bat) script copying a file from a remote server to the local disk.

    I have a .bat file that is added as a snapin. The .bat file contains a command to copy a file from a network share and then execute the downloaded file.

    The issue I am having is that the file does not get downloaded.

    FOG registers and runs the snapin without issue - local commands stored within the ps1 file execute correctly. The only area that doesn’t work is the request to download the file from the server.

    The script also runs without issue when manually run from the local computer. (It copies the files and executes the downloaded file).

    The remote server has a shared folder. Trying AnonymousLogon, Guest, SYSTEM with full (and read only) permissions has not allowed me any further luck in downloading the file.

    Looking for clarity on how I might be able to download a file from a server from a powershell script run as a snapin.

    Please let me know what additional information may be needed to assist with providing further help with this issue.

    Thank you for your time,

    1 Reply Last reply Reply Quote 0
    • G
      george1421 Moderator
      last edited by Jan 3, 2017, 2:18 PM

      First let me explain that I don’t use fog snapins so this may be a bit off point.

      But the FOG Client runs as SYSTEM (unless you changed the default). The SYSTEM account has no rights outside of the box that the FOG Client is running on. Even if another computer has a SYSTEM account, that account is different and not a domain account.

      To make your script work, it must run as, or connect to the remote share as someone who has rights on the remote share. If it was me I’d use a command like.
      net use t: \\server1\share1 /user:domain\bob and then supply the password for domain\bob to connect to the remote share to retrieve the file.
      Then when your done issue the command net use t: /delete to remove the share.

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

      1 Reply Last reply Reply Quote 1
      • W
        Wayne Workman
        last edited by Jan 3, 2017, 2:20 PM

        Probably permissions still. There are two tabs where “everyone” and “anonymous logon” must be put in, the sharing tab under advanced permissions, and under the security tab. That’s for no passwords. in your powershell script you can mount the share as a drive letter using specific credentials - do not use your admin creds, create a service account and give the service account modify permissions on the security tab, and full control on the sharing tab.

        So those are the two routes to go. Beyond that, do some logging. Send the output of the lines that use the share to a log so you can see what the errors are.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
        Daily Clean Installation Results:
        https://fogtesting.fogproject.us/
        FOG Reporting:
        https://fog-external-reporting-results.fogproject.us/

        1 Reply Last reply Reply Quote 0
        • M
          mtanigawa
          last edited by Jan 3, 2017, 11:18 PM

          @Wayne-Workman @george1421

          Thank you for the reply. I will give both a go and report back.

          Appreciate the help!

          Thank you again,

          Mark

          1 Reply Last reply Reply Quote 0
          • M
            mtanigawa
            last edited by Jan 4, 2017, 3:41 AM

            @Wayne-Workman @george1421

            I have tested and successfully deployed snapins in my method of choice. I have elected to use @george1421’s option as having an exposed share in our environment is not my first choice.

            Thank you for your help and pointing me in the right direction. I greatly appreciate it.

            Mark

            W 1 Reply Last reply Jan 4, 2017, 5:39 AM Reply Quote 0
            • J
              Joe Schmitt Senior Developer
              last edited by Jan 4, 2017, 3:59 AM

              @mtanigawa if you’re hard coding the credentials in the snapin, there is another option. You can set Snapin Arguments Hidden and put the password in the script’s arguments, that way the password will never be stored on disk, only in RAM for a very brief amount of time.

              Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG! Get in contact with me (chat bubble in the top right corner) if you want to join in.

              1 Reply Last reply Reply Quote 1
              • W
                Wayne Workman @mtanigawa
                last edited by Wayne Workman Jan 3, 2017, 11:45 PM Jan 4, 2017, 5:39 AM

                @mtanigawa only one option of the two I gave was an “exposed share” - I was intending to give many options. An unprotected share is better for troubleshooting purposes - which you or a future reader might find incredibly valuable one day.

                Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
                Daily Clean Installation Results:
                https://fogtesting.fogproject.us/
                FOG Reporting:
                https://fog-external-reporting-results.fogproject.us/

                1 Reply Last reply Reply Quote 0
                • M
                  mtanigawa
                  last edited by Jan 4, 2017, 8:48 AM

                  @Wayne-Workman @Joe-Schmitt

                  Thanks for the updated feedback. I will look into the hiding the password as suggested - the script I wrote is probably crude and ugly.

                  I have another (unrelated) question to ask, but tomorrow and on a new thread.

                  Thank you again for your time and appreciate the great help and support.

                  Mark.

                  1 Reply Last reply Reply Quote 0
                  • 1 / 1
                  1 / 1
                  • First post
                    6/8
                    Last post

                  203

                  Online

                  12.1k

                  Users

                  17.3k

                  Topics

                  155.3k

                  Posts
                  Copyright © 2012-2024 FOG Project