05-31-2019 01:07 AM
05-31-2019 01:07 AM
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!
05-31-2019 03:23 PM
@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.
06-04-2019 04:49 AM
@christianmontoya 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.
06-06-2019 06:49 AM
@christianmontoyaa 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!
06-10-2019 09:05 AM
@tadhgclifford hello publishing a remote app from a network share has not been evaluated and its not a scenario we recommend (or the AppFoundation team recommends). In general for RDS/VDI apps must be present on the machine prior to user logged in or installed by the user after session is established. With click-to-run apps there are set of internal procedure/micro-services that do certain cleanup upon user logoff. Not all do it … it really depends how the app was written (if app was written not to put setting in the user profile should not be a problem...I tested this scenario a while back).
Click-to-run apps to run from network share but there are challenges (like those that you are experiencing) (additionally click-to-run apps do some weird stuff with user data unless coded for such scenario).
Logs: Try looking here %LocalAppData%\Temp
Also check converting Click-to-run to MSIX (repackage it there is a tool in the store). MSIX has the procedure/capabilities to clean itself quite nicely upon session disconnect.
06-12-2019 10:50 PM
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.
06-28-2019 05:03 AM