I have a number of Powershell scripts performing backup and file organisation tasks (using Robocopy).

As these operations are occuring on secured directories, Credentials are used.

Ideally I would like to call the scripts via a short powershell wrapper using the provided Powershell Process Task. This would be done with the "Powershell script text" as this will allow the use of VisualCron Variables.

Once these variables are set, our detailed scripts are called:

-- snip --
# Call the File Organise Script if there are files to process
IF ($ProcessFromDate -and $ProcessToDate)

{
& "C:\Batch\File_Organise_Process.ps1" "$FromDir" "$ToDir" "$FromSubDir" "$ToSubDir" "$FilePattern" $ProcessFromDate $ProcessToDate $ProcessMode $ProcessType
}
-- snip --

Whilst I specify a Credential this does not seem to be having the desired effect as the eventual RoboCopy Command issued from the called script gets either Direcory not found, or Not Authorised depending on the Credential.

e.g.

"

---

ROBOCOPY :: Robust File Copy for Windows

---

Started : Tue Dec 18 10:37:44 2012

2012/12/18 10:37:44 ERROR 5 (0x00000005) Getting File System Type of Source \\uqfile2.soe.uq.edu.au\fbs\shared\Intersectional\ePayments\BPay\Archive\
Access is denied.


2012/12/18 10:37:44 ERROR 5 (0x00000005) Getting File System Type of Destination \\uqfile2.soe.uq.edu.au\fbs\shared\Intersectional\ePayments\BPay\Archive\201212\
Access is denied.
"

Similarly if I Call the Same Scripts as a "Powershell File" the same issue occurs (replacing what would have come from the VisualCron Variables as hard coded values for testing).

If I run Exactly the same Powershell File script encapsulated in a short command file (attached) using the Execute Process Task and same credentials all is well.

Most of our powershell scripts at present from VisualCron are running this way (Powershell but wrapped in a command script) to get around this. We would ideally like to use the Powershell Process Task to take advantage of VisualCron Variables / substitution.

Is the fact that we are calling a modularised Powershell script rather than a large single script the issue ?

How is this VisualCron task running the powershell scripts ?
. . . . . as the answer to this may necessitate changes to the scripts ?

Make sure that "local login" and "load profile" is unchecked when trying to access network resource.

---

Hi Henrik,

No Joy, exactly the same behaviour:

From Task Process - Powershell - As Credential - both of those checkboxes unchecked

---

ROBOCOPY :: Robust File Copy for Windows

---

Started : Wed Dec 19 06:23:04 2012

2012/12/19 06:23:04 ERROR 5 (0x00000005) Getting File System Type of Source \\uqfile2.soe.uq.edu.au\fbs\shared\Intersectional\ePayments\BPay\Archive\
Access is denied.


2012/12/19 06:23:04 ERROR 5 (0x00000005) Getting File System Type of Destination \\uqfile2.soe.uq.edu.au\fbs\shared\Intersectional\ePayments\BPay\Archive\201212\
Access is denied.

---***---

Same Script via cmd shell wrapper using Task Process - Execute

---

ROBOCOPY :: Robust File Copy for Windows

---

Started : Wed Dec 19 06:27:36 2012

Source : \\uqfile2.soe.uq.edu.au\fbs\shared\Intersectional\ePayments\BPay\Archive\
Dest : \\uqfile2.soe.uq.edu.au\fbs\shared\Intersectional\ePayments\BPay\Archive\201212\

Files : *.*

Exc Dirs : Logs

Options : *.* /FFT /NDL /NFL /L /COPY:DAT /MOV /NP /IS /MAXAGE:20121217 /MINAGE:20121219 /R:0 /W:0

---

---

Total Copied Skipped Mismatch FAILED Extras
Dirs : 2 0 2 0 0 0
Files : 32 32 0 0 0 247
Bytes : 10.9 k 10.9 k 0 0 0 89.7 k
Times : 0:00:00 0:00:00 0:00:00 0:00:00

Ended : Wed Dec 19 06:27:36 2012

Log File : \\uqfile2.soe.uq.edu.au\fbs\shared\Intersectional\ePayments\BPay\Archive\Logs\File_Organise_Process_201212_MOVE.Log

What kind of Credential are you using. Should preferably be a user on the remote system? You can try the same with a File read or Write Task with that Credential to see if it works.

---

Hi Henrik,

Sorry for the slow response, XMAS.

As I have noted above the credential is fine I think - It works if I run the script in a wrapper via the "Process - Execute" Task.

It is a 'service' account that is a standard windows account, with access to the drives and folders on which the script is to operate. It is used in many other VisualCron Tasks (including the one mentioned above to run the wrapper for the powershell scripts).

It is used in other jobs for reads, writes, copies, deletes etc on these shares.

Perhaps this is an enhancement rather than a bug ? . . . as the credential is not used as I expect ?

"Process - Execute" Task has what I need (and most scripts need) - "Run Task As" - Credential

What "Process - Execute Script" and "Process - Powershell" seem to have based on the help text is a credential to access the <script> file . . . .

Is the Credential in Process - Powershell being used to execute the script ?

The Credential, in the Powershell Task, gives the current user (normally Local System - the user that the service VisualCron is running as, rights that the Credential have. It is important that this specific user has access to "uqfile2.soe.uq.edu.au". In most cases you should edit the Credential to run with "Local login" unchecked. But if it is a domain Credential you can also try with "Local login" and "Load profile" checked.

---

Henrik can I get you to try replicating my issue at your end ?

Create 2 Directories not locally / on a share.

my example is a machine called fbsprod02

Create 2 Directories
C:\CopyFrom
C:\CopyTo

Assign a Domain User associated with a credential with full access to both directories

put a dummy file in C:\CopyFrom.

Screen Shots and Script files attached FYI / to assist with this. I Used C:\Batch as the script path on the VisualCron Server machine.

1) If you run a VisualCron copy task without a credential copying from \\fbsprod02\c$\CopyFrom to \\fbsprod02\c$\CopyTo that should fail - Access Denied

2) If you associate the credential with the above and rerun the Copy Task that should work

The above is the baseline, nothing to do with Powershell.

Create a Process-Powershell command with the following as the text to execute:

<Not Powershell - just a robocopy command - but will serve as a test>

robocopy \\fbsprod02\c$\CopyFrom \\fbsprod02\c$\CopyTo /s /r:0 /w:0 /log:C:\Temp\Robo.txt

3) Run Task without a Credential - Expected to Fail - Access Denied
4) Run Task with a Credential - Expected to Work but for me doesn't - Still Access Denied

Exactly the same command but included in a powershell script called robocopy.ps1

5) Run Task without a Credential - Expected to Fail - Access Denied
6) Run Task with a Credential - Expected to Work but for me doesn't - Still Access Denied

Change the Task Type to Process - Execute and use the provided command wrapper to wrap the exact same powershell script:

7) Run Task without a Credential - Expected to Fail - Access Denied
8) Run Task with a Credential - Expected to Work - Copy Successfull

Just as a cross check we can use the same command as a command to execute

9) Run Robo as a Process Execute command line - Expected to Fail - Access Denied
10) Run Robo as a Process Execute command line - Expected to Work - Copy Successfull

Sorry if this is a little short hand. Please have a look at the attached screen prints / robocopy output and see if this makes sense.

Again I am using Robocopy simply as an easy to replicate and document 1 line example, obviously its not real powershell but serves as an example as I think my issue is credential / security related.