A week ago I found myself with a predicament.
I had an application, virtualized with App-V which needed to run a script from a user’s network share (G to be exact). No problem, right? Just use <scriptbody> or <href> inside the *.OSD to invoke the script.
But what if the script sets an environment variable?
Wether you use <scriptbody> or <href>, a command-prompt will be started where the script will run in. But when the script is done the command-prompt will close and the environment variable will be vanished since it was set on the command-prompt process.
Darn, it’s logical… but I didn’t like it.
Then… I baked a script that I put in the sequence which invokes the script on the G: of the user and next start the application. That works!
But I would not post this if the solution was that obvious.
The sequence has a dependency; another sequence. This can be configured by using Dynamic Suite Compositioning (DCS).
When you make an *.OSD which starts a script and in that script you invoke the executable of the application within the sequence, the application will start.
However, when you have a DCS configuration, you will get an “access is denied” when the sequence tries to start the dependency sequence!
A colleague of mine mentioned that I’m using the SET-command to set the environment variable… but that with the SETX-command you can set the environment variable for the entire session and not just the one process the command runs under!
A little information about the SETX-command:
The SETX-command can be used to set an environment variable on both machine- and user-level.
A few examples:
SETX Variable Value Sets an environment variable for the entire current user environment.
SETX Variable Value –m Sets an environment variable for the entire machine.
To delete an environment variable, SETX itself does not provide that feature. For this, you will need a basic “regedit” command, something like this:
REG delete HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment /V _variable