PRODUCT IOTS » product-uem 6.3.0 GA

Current attempted approaches to open the UWP app from Windows service

1. Open a powershell instance through the Windows service and execute command to open the UWP app through it's app alias [1]
2. Since the UWP did not open with the above approach. Created a WPF app [2] and opened it through the Windows service. This WPF will try to open/communicate with the UWP app to start a remote share session

Due to the Windows service is running as a system process it does not have access to trigger interactive processes (anything UI related). To bypass this restriction we can create a new process under the currently logged in user from the system process and use that to do whatever is needed from the user's context [3]

[1] - https://blogs.windows.com/windowsdeveloper/2017/07/05/command-line-activation-universal-windows-apps/
[2] - https://learn.microsoft.com/en-us/visualstudio/get-started/csharp/tutorial-wpf
[3] - https://www.codeproject.com/Articles/35773/Subverting-Vista-UAC-in-Both-32-and-64-bit-Archite

Previously the new process created under the currently logged in user from the Windows Service had elevated privileges, this made the UWP app not load. It is now currently creating a new process without elevated privileges under the current user and passing the command line arguments to open the UWP app from anywhere in the Windows Service when we want to.

Due to this, the console app and the WPF app mentioned previously are removed from the project solution.

There is an issue with the release agent build where the IPC (Inter-Process Communication) between the UWP app and the background service is not working. There are no error logs found or the apps do not crash. This issue is currently investigated by using message tracing and logging [1] in the Windows Communication Foundation (WCF) service. These logs are readable through the Microsoft Service Trace Viewer tool [2] which is quite different to the carbon logs.

[1] - https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/tracing-and-message-logging
[2] - https://learn.microsoft.com/en-us/dotnet/framework/wcf/service-trace-viewer-tool-svctraceviewer-exe

Problem was identified as network isolation restriction for services running on localhost [1] which is where the WCF service is hosted.

Solution is to run this command [2] on each enrolled device to allow the UWP app to communicate with the WCF server hosted on the Windows Service. But this does not look like a practical solution. Further research will be done to see if there is a better approach.

[1] - https://learn.microsoft.com/en-us/windows/uwp/communication/interprocess-communication#loopback
[2] - https://github.com/microsoft/WindowsAppSDK/issues/113#issuecomment-868414733

Fixes with https://repository.entgra.net/proprietary/windows-agent/pulls/19