File Copy from UNC Share to server

[Guest]

OK; if you can share one example, plus the exact error message you're getting, or the behavior you're not seeing, it would be helpful. Remember to turn on Verbose logging to see exactly what's happening.

The copy command is very straight-forward. Here is the example we have from our docs, and I modified it to use the UNC Path.

# copy all files and all subdirectories beneath it to the target,
# and log each individual file that is copied, and overwrite any files
Copy-Files(
    From: \\server\path\to\files,
    To: C:\Temp,
    Include: **,
    Verbose: true,
    Overwrite: true
);

With UNC Paths, the most likely scenario is that the Otter service doesn't have access to it. Typically this requires using a domain account (default is NETWORK SERVICE)

[Jonathan.Engstrom]

Here is an example I tried doing UNC first, then tried both local paths, and neither worked:

##AH:UseTextMode

Copy-Files
(
Include: **,
From: C:\Temp\Agent\Extensions,
To: C:\Temp2,
Verbose: true,
Overwrite: true
);

[Guest]

Can you share the logs from this block?

You should see a bunch of them with "Verbose: true".

[Jonathan.Engstrom]

Here are the logs from the job history. I am assuming it's not working as it isn't using the permissions assigned to the server, and there is no where to configure what permissions to use. CredSSP is disabled in our environment for security concerns. My account I wish to use is already stored as a credential, so I wish to be able to leverage that to execute jobs.

I already know I have access to the file share, and can copy it without issue.

DEBUG: 2018-12-17 14:14:24Z - Job 216 directly targets 1 server(s) by name.
DEBUG: 2018-12-17 14:14:24Z - Skipping collection run; execute only.
INFO : 2018-12-17 14:14:24Z - Collection run succeeded.
DEBUG: 2018-12-17 14:14:24Z - Beginning execution run...
INFO : 2018-12-17 14:14:31Z - Copying files from \fileserver.domain.local\share\scripts to C:\Temp2...
WARN : 2018-12-17 14:14:31Z - Source directory \fileserver.domain.local\share\scripts does not exist.
DEBUG: 2018-12-17 14:14:31Z - Cleaning up temporary files on Inedo Agent (v??, TESTSERVER:46336)...
DEBUG: 2018-12-17 14:14:31Z - Execution run complete.
WARN : 2018-12-17 14:14:31Z - Execution run succeeded with warnings.

[Guest]

That's the likely culprit then.

The copy job is running under whatever user the Inedo Agent Service is configured to run under. It sounds like you'd like to do something like this?

with credentials=<UserNamePasswordCredentials>
{
  // all remote commands executed here will be performed in a process
  // running under the specified credentials
}

Well, it's not available yet, but this is something we are planning. It's quite complicated, and I know it's in a PoC phase.

I don't have an ETA; but at least I can tell you that it's been spec'd out and is being prototyped, which is further than when it was just a rough idea.

[Jonathan.Engstrom]

OK, that is what I was figuring. I am glad this is being worked on, as it is a "Must Have" for automation and copying files to servers. I wish I could use ProGet for something like this, but I can't install agents on the servers at this time. We have to control how access is configured for specific items anyway, and can't change the Agent Service Account on the fly for that.

[Jonathan.Engstrom]

Hello, I am writing to see how this is progressing. Are there any rough ETA's available? Thanks!

[atripp]

Not any useful ETAs, but it's something we definitely want to accomplish this year (this has been a very long-standing request), just a matter of prioritizing which part of the year it gets done in, etc.

[Jonathan.Engstrom]

Alana, I was wondering, when you set up a server in Otter with Agentless Powershell, does it create a PSSession at all? If you can get the credentials from the database into a $cred variable, then with that use that to create a possession, and do a copy-item -tosession from there? Would that be possible? If this can work, it should be easy to set up, and it's awesome as it uses winrm witch already has to be open to use that for communication. Maybe this could be a stop-gap measure for now while something better is made?

[Guest]

Those are handled at different abstraction layers; the agent code doesn't have any knowledge of the context its being run in (i.e. OtterScript, the Service, etc).

That's the intent of that "with credentials" setup, to allow this information to pass down.