locked
AppV 5: Sequence shortcut to application located on network share RRS feed

  • Question

  • Hello,

    We have an application which is programmed to run directly from a network share.
    However, it needs some parts installed locally on the client too, to make it work.

    During sequencing using App-V 5.0, I installed the parts necessary on the client, and I created a shortcut to the network path e.g.: \\server\share\application.exe
    The sequencing process works fine, and the application gets published correctly to an App-V client.

    However, when launching the application we receive an error "The application was unable to start correctly (0xc000142). Click OK to close the application."
    In Event Viewer we notice following error in Applications and Services > Microsoft > AppV > Client > Virtual Applications: "The virtual applicatoin '\\server\share\application.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error:0x8DC02325-0x52E}"

    We notice that the sequenced application shortcut references: "\\server\share\application.exe  /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1"

    When launching the application directly (\\server\share\application.exe - without appvve parameter) it works fine (but at that moment it's missing the locally installed client components).
    When running the same application with parameter 'appvve', it fails (error message above).
    When copying the application to a local drive, it does run succesfully when using the 'appvve' parameter, but unfortunately this is not a supported scenario for the application we're talking about. It has to be run from the network share.

    So am I correct to say that App-V does not support running an executable located on a network share in the virtual bubble? Are there any solutions/workarounds to make this work anyway?

    I tried mapping the network share to a drive letter, but that didn't help either.

    
    
    
    
    

    Thursday, February 28, 2013 6:17 PM

Answers

  • Appears this was fixed in App-V 5 SP2 Hotfix 4..

    http://www.tmurgent.com/TMBlog/?p=2029

    Support for executables on network shares The App-V Client now correctly supports shortcuts to executables on a network share. It now performs user impersonation when a virtual application uses resources located on a network share. Previously, the only way to get this to work was to give the client computer account permission to the share.

    Monday, June 23, 2014 4:07 PM
  • Maybe it's a permission issue?

    You could try to add domain computers (or the system-name of your client computer (hostname$)) to the server.

    Monday, March 4, 2013 8:47 AM
  • Hi guys

    I have some good new and some bad news

    I've just been informed this issue has confirmed as known issue by MS and they're working on an architecture change in order to have a solution for this , as many customers have problems with it.

    the bad news are... the solution won't be on the close release of App-V 5.0 (probably SP3) that should be available on Spring 2014. 
    It will probably be only on the next release which will be on Fall 2014.

    I claimed that where I work this issue is on top priority and the number one reason for us of not being able to migrate packages from 4.x to 5.x.

    In order for this issue to get a higher priority is if each one of you will also contact MS and speak about this issue so they will be more awareness about it.

    better to have something than nothing...

    Tamir Levy


    Tamir Levy

    Wednesday, March 12, 2014 12:51 PM

All replies

  • Have you tried making the target of the shortcut a script? That would launch the application after the VE is started.


    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.


    This forum post is my own opinion and does not necessarily reflect the opinion or view of my employer, Microsoft, its employees, or other MVPs.

    Twitter: @stealthpuppy | Blog: stealthpuppy.com | The Definitive Guide to Delivering Microsoft Office with App-V

    Thursday, February 28, 2013 8:53 PM
    Moderator
  • As a matter of fact, I did. Your thinking seems logical, but it didn't work either. 

    I created added a launch.vbs script during sequencing, and changed the shortcut to this script. The script would then launch the real application running from the network share. Once deployed this shortcut is showing up on the client as a shortcut targetted to: "%LOCALAPPDATA%\Microsoft\AppV\Client\Integration\557B23AE-4942-4E3E-BE5F-1DA010EA7DAE\Root\launch.vbs  /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1"
    

    The contents of the launch.vbs script look like this: 

    Set WshShell = WScript.CreateObject("WScript.Shell")
    cmd = "\\share\server\application.exe"
    WshShell.Run(cmd)


    The script runs fine when launched without the 'appvve' parameter, but with the 'appvve' parameter it fires the same error message. 
    When looking at event logs, it seems that the launch.vbs was executed succesfully, but the App-V client Event Log shows again that the \\share\server\application.exe was not able to launch: 

    "The virtual application '\\server\share\application.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error:0x8DC02325-0x52E}"

    Friday, March 1, 2013 5:11 PM
  • Maybe it's a permission issue?

    You could try to add domain computers (or the system-name of your client computer (hostname$)) to the server.

    Monday, March 4, 2013 8:47 AM
  • Have you run Procmon to see if there's an issue with loading files?

    A previous Apll (namely with loading components like DLLs afterwards from the share)



    Falko

    Monday, March 4, 2013 11:22 AM
    Moderator
  • have you followed this article?
    Monday, March 4, 2013 12:29 PM
  • I have this exact same application scenario and error issue too.  I've been working all day trying to fix it.

    I found the MS article previously, but already had HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation set to 2.  The article covers an error message slightly different than what Bart and I are receiving.  The article covers this error:

    The virtual application 'path to virtualized executable' could not be started because the App-V Subsystem 'Virtual Filesystem' could not be initialized. {error: 0x74300C0A-0x20006}

    But the error we have is:

    The virtual application '\\server\share\application.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error:0x8DC02325-0x52E}

    I'm not giving up hope yet!

    -John


    Monday, March 4, 2013 10:33 PM
  • About Permission Issue (Ben De Vriese):

    When launching the application directly (\\server\share\application.exe - without appvve parameter) it works fine (but at that moment it's missing the locally installed client components). So this would make me think that there is no permission issue. 
    It's actually run from a domain computer in the same domain as the fileserver which is hosting the application. 

    About running ProcMon (kirk_tn): 

    I haven't gotten much time to investigate on this, but every time I launch ProcMon, ProcMon just becomes unreponsive after I launched the application trying to simulate the error.. I should do some more tests on this though..

    About this article (Tiberivs / techpatriot):

    I came accross the article as well during my research, but exactly as techpatriot pointed out, also in my environment the registry setting is already set to 2, and indeed the error message is just slightly different. 

    -

    Just one more addition to this: 

    I extended my tests using notepad.exe on a fileshare, and I happen to have the exact same issues. 
    Without the appvve parameter, it just launches correctly. With the appvve parameter, it fails with the same error.
    To note: I didn't have time today to create a new sequence for Notepad, so I just reused the same appvve GUID from my original application trying to launch notepad into that bubble: "\\server\share\notepad.exe /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1"
    So it seems as if any application on the fileshare will just not run in a App-V bubble. We're using a NetApp NAS. 

    Still no luck here.. so far..

    • Edited by Bart Billiet Monday, March 4, 2013 11:22 PM Fixed markup
    Monday, March 4, 2013 11:20 PM
  • I was getting the exact same error when trying to launch an application from a network share using the /appvve:% PackageId%_% VersionId% in the target box & the RunVirtual Registry Key (not at the same time).

    I was able to get around the problem by granting read access to the network folder for the computer account where you are launching Application From.

    Thursday, March 7, 2013 6:28 AM
  • MS is sort-of aware of this situation, however their action plan depends on the officially reported impact.

    Therefor I'd recommend you raise a support call, explaining the issue and - perhaps more important - the impact for your organization. I do understand that in many organizations it is not acceptable for security reasons to give all client machines (not only users)  read access to network shares, but MS needs to know that.

    And, as far as I know, if a call results in a Fix (Hotfix, SP), it will be refunded to you.



    Falko

    Twitter @kirk_tn   |  Blog kirxblog   |  Web kirx.org

    Thursday, March 7, 2013 7:24 AM
    Moderator

  • I am glad to say that adding the computer account (computername$) with read-only permissions to the fileshare solves the issue indeed. After that change, the application then launches correctly. As recommended by Kirk, I will raise a support case about this issue, as obviously we don't want to grant access to the file share for all our client machines. 

    Thanks. 


    Monday, March 11, 2013 12:08 PM
  • I was working on this same issue when I found this forum post.

    I found out that the computer account needs to be able to list the folder contents of the shared folder in which the executable to run resides. I've no idea why though. It does not need actual read permissions on the files in the folder. So it appears the comupter account does not read the executable itself. This allows security to be set quite tight by only granting the special right “List folder/ read data” and apply it to “This folder only”. This reduces risk as much as possible, although I agree it would be better if the computer account would not require any access to the shared folder.

    I've written an article about this on my blog: http://packnowledge.wordpress.com/



    • Edited by CvdKooij Thursday, March 21, 2013 12:23 PM
    Thursday, March 21, 2013 9:42 AM
  • Thanks CvdKooij! Very valuable information on the exact permissions needed. Nice summary on your blog.

    I investigated this matter some more myself too, and did a ProcMon trace on it. 
    In there you can clearly see that the process of launching the application goes like this: 

    1. AppVClient.exe performs operations to \\server\share\application.exe with desired access 'Read attributes, Read data, List Directory, Synchronize'. 
      This process runs with username 'NT AUTHORITY\SYSTEM' (computer account)
    2. After this process, the application is actually launched.
      At that moment application.exe will run under the user account of the person logged on to the system. 

    If the computer account has not been granted the desired access, step 2 will not be executed, and the application will fail with the know error: 

    "The virtual application '\\server\share\application.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error:0x8DC02325-0x52E}"

    Thursday, March 21, 2013 10:44 AM
  • Hello,

    I am using App-v 5.0 SP1 client and for some reason software from UNC path didn't start even I granted permissions to "Domain Computers".

    However I did get it working by launching software via cmd.

    Original (not working) target: \\server\share\notepad.exe /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1

    Working target: cmd /c start "" \\server\share\notepad.exe /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1

    Cheers, Hude

    • Proposed as answer by PennCollegeJim Monday, August 26, 2013 8:12 PM
    Thursday, July 4, 2013 12:18 PM
  • Hello,

    I am using App-v 5.0 SP1 client and for some reason software from UNC path didn't start even I granted permissions to "Domain Computers".

    However I did get it working by launching software via cmd.

    Original (not working) target: \\server\share\notepad.exe /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1

    Working target: cmd /c start "" \\server\share\notepad.exe /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1

    Cheers, Hude

    Same issue here. Somebody knows why?

    Regards, Andi

    Tuesday, September 24, 2013 9:49 AM
  • Unbelievable!

    I'm also having the same issue even after adding "Domain Computers" on the UNC path.

    if I copy the exe file locally then I manage to get it work but of course this is not a solution...

    it's a disaster! especially when half of our app's executable files are on a network location and we cannot migrate this way from App-V 4.6 (Which worked perferct with network executable) to App-V 5.0.

    any luck? has someone try to see if this issue happens in App-V 4.6 SP2 Beta?


    Tamir Levy

    Sunday, October 27, 2013 1:51 PM
  • can you try to give the computer account access to the 'super' Folder?

    if the executable is in \\server\share\subfolder\whatever.exe, try to grant access not only to 'subfolder', but to 'share'.. and don't forget that there are share and NTFS permissions.

    As a first try, grant 'full access' temporarily.


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Sunday, October 27, 2013 5:08 PM
    Moderator
  • Hi all,

    meanwhile I started a support request and solved this issue for me. MS is aware of that special behaviour. Hopefully they'll fix it soon.

    1. Initial situation: 

    a) Users get drive M: connected to share \\server1\apps\

    b) Users normally execute M:\app1\app1.exe --> that's the link you'll normally publish within your AppV 5.0 package --> but with AppV5 you get that "Virtual Shell" error

    2. My Solution:

    a) Grant Domaincomputers read permissions (NTFS and SHARE) on:

    1. "rootfolder" apps (\\server1\apps) --> NTFS permission
    2. folder app1 (subfolders and files inherit read permissions) --> NTFS permission
    3. share \\server1\apps\ --> share permission

    b) Modify published application link in AppV 5:

    I had to modify the published link to UNC --> \\server1\apps\app1\app1.exe instead of M:\app1\app1.exe

    That's my workaround for several applications.

    Andi

    Monday, October 28, 2013 6:15 AM
  • thank you Kirk

     it was the root permission in my case.

    I tried to run something from I:\413\PI and it ran only after I gave permission to I:\413

    definitely not a solution!!!

    I have 8 share for each user and 6 file servers for each site all over the country

    My package include a dll environment with registry keys so each person who wants to use it open a cmd and drag his own exe, wherever that is to the cmd and it runs.

    I'm not going to give permissions for "Domain Computers" to all my network just because Microsoft change the concept of accessing network executable files from virtual environment.

    did Microsoft said anything about a fix for this issue on App-V 5.0 SP2?

    it's a complete nightmare...


    Tamir Levy

    Tuesday, October 29, 2013 2:59 PM
  • Hello,

    I haven't heard anything specific for App-v 5.0 Sp2 that should address this behavior.

    You could test it with the public App-v 5.0 SP2 beta, and if that doesn't alter the behavior you could post it to the Connect-site.

    Connect-site;

    https://connect.microsoft.com/


    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, October 29, 2013 3:26 PM
  • speaking of Connect... I posted many issues more than a month ago (including this) and some of them - haven't got any comment on some of them...

    feels like someone abandoned the App-V section. :(


    Tamir Levy

    Wednesday, October 30, 2013 6:32 PM
  • I have used a vbscript to start the exe from within the package, install whatever you need, then make the vbs in the installdir locally (c:)

    Dim objShell
    Set objShell = WScript.CreateObject( "WScript.Shell" )
    objShell.Run("K:\Whatever")
    Set objShell = Nothing

    Make a shortcut to the VBS and change the icon and stop the capture


    Tuesday, January 7, 2014 7:58 AM
  • Hi Michiel, did you definitely get this to work?

    I've tried use a local vbs in the PVAD to run an exe via a unc path and also via a mapped drive.

    For the UNC path I get the error as described above (Virtual Shell error).

    For the mapped drive, this wont even launch as it appears to not be aware of the mapped drive at that point, even though it is mapped.

    Anyone else have any workarounds that work besides adding computer account permissions to ntfs/shares which is not practical in our environment.

    Thursday, January 16, 2014 6:40 AM
  • Hello,

    I am using App-v 5.0 SP1 client and for some reason software from UNC path didn't start even I granted permissions to "Domain Computers".

    However I did get it working by launching software via cmd.

    Original (not working) target: \\server\share\notepad.exe /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1

    Working target: cmd /c start "" \\server\share\notepad.exe /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1

    Cheers, Hude

    Hi Hude, I have tried the 2nd command line which you've indicated works (cmd /c ...), but I still get the same virtual shell error launching this way.

    Can you confirm this definitely works for you (I'm testing with App-V 5 SP1 as well)

    Thursday, January 16, 2014 6:55 AM
  • can you try to place your application (notepad.exe) one level deeper in the hierarchy (\\server\share\SUBFOLDER\notepad.exe (but still have the NTFS and Sharing permissions on \\server\share\)?

    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Thursday, January 16, 2014 3:33 PM
    Moderator
  • Hi Falko, I know this setup will work, but we don't want to be setting permissions for domain computers for all the server shares/ntfs perms that are currently in use for network applications.

    I was hoping for alternative workarounds but it appears there are none at this stage.

    Thanks

    Thursday, January 16, 2014 10:15 PM
  • Hi, at a conference (I think it was the German User Group) it was said that App-V might have an issue if it tries to access objects from a network share if the above folder can't be accessed. I'm not asking to change the permissions on any folder, I'm just asking to copy/locate the executabel into a new sub directory of the original one


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Friday, January 17, 2014 9:38 AM
    Moderator
  • I've done some testing on this with App-V 5 SP2 here's what I've found:

    I first created a folder name apps and shared it with everyone Full Control.
    Then under Apps I placed 2 folders named folder1 and Notepad++

    created a mapping x: \\fileserver\apps

    Made a App-V package that starts: x:\folder1\notepad++\notepad++.exe (using the /appvve option)
    Feeling lucky I tried starting this package:
    **FAIL** error in eventvwr: The virtual application 'X:\folder1\Notepad++\notepad++.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error: 0x8DC02425-0x3}

    - gave domain computers read access to notepad++ folder:
    **FAIL** error in eventvwr: The virtual application 'X:\folder1\Notepad++\notepad++.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error: 0x8DC02425-0x3}

    - gave domain computers read access to folder1\notepad++ folder:
    **FAIL** error in eventvwr: The virtual application 'X:\folder1\Notepad++\notepad++.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error: 0x8DC02425-0x3}

     - gave domain computers read access to d:\apps\folder1\notepad++ folder:
    **FAIL** error in eventvwr: The virtual application 'X:\folder1\Notepad++\notepad++.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error: 0x8DC02425-0x3}

    - changed the App-V package to start \\fileserver\apps\folder1\notepad++\notepad++.exe
    **SUCCESS**

    - removed the domain computers user rights:
    **FAIL** The virtual application '\\fileserver\apps\folder1\Notepad++\notepad++.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error: 0x8DC02225-0x5}

    - again gave domain computers read access to d:\apps\folder1\notepad++ folder:
    **SUCCESS**

    I can't believe that Microsoft would intentionally do this but is this going to be fixed or is everyone who is using App-V, condemned to alter packages to UNC paths+change userrights across the whole infrastructure? (if you don't want to resort to using vbs/cmd file hacks)

     


    Visit my Techblog at http://www.virtualistic.nl


    • Edited by AlphenIT Thursday, January 30, 2014 1:16 PM
    Thursday, January 30, 2014 1:15 PM
  • Hi all,

    I've been playing with the same issue....

    Network installed app,   run an installer on the client PC which sets up registry keys which point to the network server for .dlls,  short cut calls the .exe off the network server.    After reading the posts here I tried

    1. granting my citrix server ntfs rights to the files  -  Did not work.    

    2. #1 + added share permissions and granted read permissions to the citrix server -  worked

    3.  removed ntfs permissions but left share permissions  - worked

    4.  Removed share permissions explicit to the server and granted share permissions to a workstation group which contained the server -  Did not work.

    why does  #3 work but not #4

    Tuesday, February 18, 2014 10:33 PM
  • Why do I not see this issue on Connect? This problem really sucks, now I have to keep the domain computers account restricted as much as I can because sensitive application data sits with the network install (Accumap).

    www.bighatgroup.com

    Wednesday, March 5, 2014 11:05 PM
    Answerer
  • I agree with Kevin.

    this "By Design" issue is impossible to bypass by computer account permissions and I found it annoying that people marked this as the solution for this thread.

    first of all it's an overkill workaround.

    second of all it might be relevant for small App-V environments.
    we have hundreds of applications. at least 30% of them are network applications, or they have some executable on a share network location.

    I already contacted MS related to this issue and it turns our it's a known issue since App-V 5.0

    from what I've checked this issue hasn't been resolved not on SP1, not on SP2 and not on hotfix 1 of SP2 ( I don't know if it's on the net anymore)

    I know that most of the time we complain on a bug, the MVPs here guide us to contact Microsoft but on my opinion this channel should be exposed for enough people to redirect this issue for the development team.

    From all the 20 reasons that blocks us from migrating all of our packages from App-V 4.6 to App-V 5.0 - this one is with the highest severity


    Tamir Levy

    Saturday, March 8, 2014 8:12 PM
  • Hi guys

    I have some good new and some bad news

    I've just been informed this issue has confirmed as known issue by MS and they're working on an architecture change in order to have a solution for this , as many customers have problems with it.

    the bad news are... the solution won't be on the close release of App-V 5.0 (probably SP3) that should be available on Spring 2014. 
    It will probably be only on the next release which will be on Fall 2014.

    I claimed that where I work this issue is on top priority and the number one reason for us of not being able to migrate packages from 4.x to 5.x.

    In order for this issue to get a higher priority is if each one of you will also contact MS and speak about this issue so they will be more awareness about it.

    better to have something than nothing...

    Tamir Levy


    Tamir Levy

    Wednesday, March 12, 2014 12:51 PM
  • Appears this was fixed in App-V 5 SP2 Hotfix 4..

    http://www.tmurgent.com/TMBlog/?p=2029

    Support for executables on network shares The App-V Client now correctly supports shortcuts to executables on a network share. It now performs user impersonation when a virtual application uses resources located on a network share. Previously, the only way to get this to work was to give the client computer account permission to the share.

    Monday, June 23, 2014 4:07 PM
  • I can confirm that as well. I taught a class last week and Hotfix 4 fixed the issue.


    www.bighatgroup.com

    Monday, June 23, 2014 4:10 PM
    Answerer
  • Nice! Thanks for letting us know!
    We went for the approach of giving domain computer accounts permissions about a year ago, but the impersonation happening since hotfix4 is a way better and more standard solution.

    Friday, June 27, 2014 6:03 PM
  • As a matter of fact, I did. Your thinking seems logical, but it didn't work either. 

    I created added a launch.vbs script during sequencing, and changed the shortcut to this script. The script would then launch the real application running from the network share. Once deployed this shortcut is showing up on the client as a shortcut targetted to: "%LOCALAPPDATA%\Microsoft\AppV\Client\Integration\557B23AE-4942-4E3E-BE5F-1DA010EA7DAE\Root\launch.vbs  /appvve:557B23AE-4942-4E3E-BE5F-1DA010EA7DAE_C7B3C423-6E9A-4CE9-AC18-59C7F18F3FA1"
    

    The contents of the launch.vbs script look like this: 

    Set WshShell = WScript.CreateObject("WScript.Shell")
    cmd = "\\share\server\application.exe"
    WshShell.Run(cmd)


    The script runs fine when launched without the 'appvve' parameter, but with the 'appvve' parameter it fires the same error message. 
    When looking at event logs, it seems that the launch.vbs was executed succesfully, but the App-V client Event Log shows again that the \\share\server\application.exe was not able to launch: 

    "The virtual application '\\server\share\application.exe' could not be started because the App-V Subsystem 'Virtual Shell' could not be initialized. {error:0x8DC02325-0x52E}"

    Maybe, your call translates to:

    wscript.exe launch.vbs /appvve:abc_xyz 

    ... and the /appvve.abc_xyz could be being ignored because the launch script is not using it?  The script engine exe (omitted here) is what needs it.  However, seems the VE is kicking in somewhere, so I think I'm wrong anyway.

    Can I remind anyone who's reading this that it's risky practice to omit the script engine exe in calls to script files (eg vbs) (eg when setting up SCCM commands, or in your own bat/cmd/ps1 scripts)? 

    Suggest to try this (I have not tried it):

    cscript.exe /appvve:abc_xyz launch.vbs

    I don't know if this might work in SP2 without Hotfix 4.

    I have SP3 now so cannot test above in SP2 without hotfix.  But even with SP3, I'm still using call redirection (in my case: CMD.exe /C //UNC) because I can't edit a business-restricted \\UNC path directly in the sequencer (as a packager, I don't have access to the real, production share, and the sequencer has rabid validation that stops me saving a bare \\UNC shortcut lo a location it can't see).

    If I have any request, it's to make the validation like a warning, rather than a block, so that if I need to enter an arbitrary UNC string it will be allowed even if its existence cannot be verified.

    • Proposed as answer by StevieMcR Tuesday, June 28, 2016 9:34 AM
    • Unproposed as answer by StevieMcR Tuesday, June 28, 2016 9:35 AM
    Wednesday, March 25, 2015 12:58 AM
  • I had the same issue and the resolution was in fact very simple:

    Just make sure that the workingdir of the shortcut also points to that network share.

    At least this worked for me :) 

    • Proposed as answer by StevieMcR Tuesday, June 28, 2016 9:37 AM
    Tuesday, June 28, 2016 9:36 AM