... we do have a way to run in the logged on users' context.
It's right here - in the properties of the package:
... and if you run a batch as the logged on user with a simple "whoami" output to a text-file, it'll give you that. So the local variables should resolve fine.
Try a simple debugging with
whoami >> MyText.txt
<Other-thing-you-want-to-test> >> MyText.txt
Yeah... forgot to mention that I had set the package to run in the current user's context. Bad wording in original post, the "I need to... " should have been "I am running....".
I'll have a go at your test and see what that gives me.
I ran the executable in a batch file specifying the %userprofile% variable with the package set to run under the current user's account. The output of the batch file shows that it is pulling the current user's profile, but is failing on the executable. When I run the batch file straight up from a command prompt, it works as expected.
I was under the assumption that there isn't any difference between running the batch file manually from the command prompt (in the user's account, not elevated) and running the package through LD specifying the current user's account. Manually works fine, pushing with current user's account throw's a "The file handle is invalid" error.
I am running 2016.3 SU3 as well as current version of the agent.
I've attached the task log if that gives any clue.
Redirect.txt.zip 1.2 K
I've come up with a simple batch to test (intentionally failing & succeeding) with various user based contexts in this thread here -- Unable to deploy software when selecting "Run as a specified user" -- will the info (scroll to the bottom) of my test batch help you?
I suspect that your problem is that your batch file comes back with a non-0 return code (or "-2147024890" specifically) - which is your problem ... so the batch "fails" because of the non-0 return code, and so we stop right there.
User-context "activity" itself seems to be fine ... try things with the registry keys (testing both situations where the keys do / do not exist so you have controlled positive & negative results) ... chances are you are being tripped up by return codes (legitimate or otherwise).
I'm not sure that the issue is with return codes because LD is reporting correctly that the batch file is failing. Pushing through LD, the batch file fails and does not redirect the folders. Running the batch file that LD put in the sdmcache (open command prompt from within sdmcache and then launch the batch file) works fine, folders get redirected as they are supposed to.
I guess what I really need to know is what is the difference between running a batch file using current user's credentials and opening a command prompt and running the batch file?
I opened another discussion on this since this one was marked "assumed answered". I got around the issue that I originally posted in this thread by running the command in a batch file and it successfully pulls the user's profile and not the "systemprofile" that was resolving when trying to create the package as an executable package.
Thanks for your help.
The part about "assumed" answered is that you should be able to un-mark it as such . "Assumed" isn't a "guarantee" either way.
But no problems if you want to carry this into a separate thread / question.
If you want the technical differences, chances are you'll need to go via support who'd file a request for information type thing with dev ... on a high level, it should be the same as "Run As..." type command, but there's a chance that either your specific OS flavour and/or your GPO's may cause either hiccups or just inconsistent behaviour. Then again, could be that there's 3 different ways to get the same thing done (talking about "Run As ..." here) and something in your GPO / machine set up responds differently to what we should do (on a low Microsoft level).
Which - again - would be mainly an engineering level conversation.
The "basic" version is ... It's a "Run as..." really. Has been for 20+ years.
Thanks PHoffmann, that gives me the information I need.