Forum Discussion

tadhgclifford's avatar
tadhgclifford
Copper Contributor
May 31, 2019

Publishing an exe that resides on a file share

In Azure Windows Virtual Desktop, has anyone published an app from a network drive yet?
I have an Azure file share, mounted as a mapped network drive on my session host pool. I managed to publish an .exe from the file share. However, it does not run every time that I launch it.
First thing in the morning, I can run the remote app successfully. However, when you close the remote app and the session changes status from active to disconnected - then when you try to open the app again, you get the message, "the program did not start on the remote computer." Tried using "Invoke-RdsUserSessionLogoff" in PowerShell but still can't open the remote app. If you close the remote app and reopen it before the session becomes disconnected, then you can reopen the remote app no problem. Is there an error log somewhere that I can check?
This only appears to be an issue for the app that I have published from the network drive/file share. The published apps which are locally installed don't have this issue. Any and all help would be greatly appreciated!

  • tadhgclifford : What kind of application are you trying to run from the file share (is it a click-to-run)? If you just connect to that VM directly and run the same command to launch the application, is it typically reliable? Lastly, are you able to launch a full desktop session (through Windows Virtual Desktop) then launch the application?

     

    Primarily, we don't see this scenario very often and would like to understand why it can't be installed locally.

    • tadhgclifford240's avatar
      tadhgclifford240
      Copper Contributor

      Christian_Montoya Yes it is a click-to-run exe. It's always reliable when launching the exe from a full desktop session. I have not tried to run it from a command based session. I was under the impression that I could not do this through PowerShell as the file share is mounted as a mapped drive.

       

      The current app design requires that it is installed centrally and then the users run the exe by clicking a shortcut from their desktop which points at the central location, i.e. file share which is mounted as a mapped drive.

      • tadhgclifford's avatar
        tadhgclifford
        Copper Contributor

        Christian_Montoyaa little bit more info on our app...

        when the exe is run for the first time from the file share/network location, it installs files into the appdata directory. The application then runs from there.

        On the WVD environment, it would appear that there is a file share mapping problem when the load balancer launches a session to one of the virtual desktops. As I said previously, this is only an issue after a previous session has been disconnected. It always works first time in the morning!

  • michawets's avatar
    michawets
    Iron Contributor

    Hi tadhgclifford ,

     

    Another suggestion I would like to add to Christian & Stefan:

    Try to publish a logon-script as the application in stead of the actual application, and start the application from the script.

    For example: create a super small vbs-script, where you test the network drive mapping to Azure Files, and then launch the application.

    When you can publish the application, publish cscript.exe/wscript.exe and add the script location as a parameter.

    Or a powershell-script could do the same trick.

     

    That way, the exe that is launched initially is locally available on the server.

    • tadhgclifford's avatar
      tadhgclifford
      Copper Contributor

      michawets Christian_Montoya Stefan Georgiev My remote app application has been working really well all week. I have not made any changes at all, yet it has been working consistently. Have you guys made any changes/improvements on the remote app side of WVD? If so, thanks!

Resources