file download from network share via ps1 / bat snapin non functional
-
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,
-
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\boband then supply the password fordomain\bobto connect to the remote share to retrieve the file.
Then when your done issue the commandnet use t: /deleteto remove the share. -
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.
-
Thank you for the reply. I will give both a go and report back.
Appreciate the help!
Thank you again,
Mark
-
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
-
@mtanigawa if you’re hard coding the credentials in the snapin, there is another option. You can set
Snapin Arguments Hiddenand 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. -
@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.
-
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.
