I am struggling to work out how to pass in the following path as a variable I can replay in order to copy a config file to a users roaming profile:-
Tried using getVariable as a constant value but this does not seem to work.
Any advice would be great.
Any of the commands that VSA can run will only be in the context of SYSTEM or the user credential that you have configured with the Credentials Management under Audit. The %APPDATA% environment will therefore always have the same value based on which of the two profiles has control of the process.
In this case you would need to place the file & a PoSh script onto the target, make sure you have a local admin credential set, and then execute the PoSh script as an administrative user to walk the $Env:SystemDrv\users folder to locate the associated users roaming data structure.
Clarifying one aspect of Pedra's post...
If the execution step is run as "User", it WILL execute as the currently logged in user. If you want it to run as the Credentials associated with the Agent via "Set Credentials"... or as a user you would like to impersonate as a one off in the script, you simply precede the execution step with either "Use Credentials" or "Impersonate User", step, then the "User" context will change to what you selected above... for ALL User executions that follow.
If you want it to run as the "Currently Logged in User", be aware that the user MUST be logged in at run time for it to work. You can test in the procedure with an IF statement to see if the user is logged in... something like
IF User logged in
Schedule this procedure to run again in 30 mins (for example)
Another option would be to user your procedure to schedule a one time task with login as the trigger. This can be controlled via CMD line, Google schTasks.exe to learn more. I will usually create a Custom System Info Field via Audit that I update in the procedure using updateSystemInfo() with some type of status so I can create a View to identify modified systems.
Hope this helps.
Thanks for all the responses.
Should have clarified that the AP will run against the logged in end user account.
Initially I ended up using FileCopy which understood the %APPDATA% variable but discovered it only works if the full destination path exists.
The config file (.xml) was supposed to drop into the sub directory called \config but because it was missing, it created a file called config.xml instead complete with the correct contents.
Had to supplement the above with a executeShellCommand (If Exist Else) statement to check the existence of the full path otherwise mkdir accordingly.
Looking at the built in commands I could not see one that checks for the existence of a directory path unless I am mistaken.
All commands executed as System and it was able to use the logged in users profile correctly.
Our software uses an app that runs in the user context, starts at user login and minimizes to the System Tray. We've used that to exchange commands between the user context and system context. The user can make specific requests that VSA triggers a response to as a SYSTEM process, and the SYSTEM process can make requests that are handled by the User process. The VSA can drop a script/bat file and then request the user process to execute it.
The user process is not difficult to create using most programming languages. Everything on the VSA side can be handled by monitors/procedures.