Environment variables in MSIX package wont be used by AVD session host
Hi, We've been struggling with environment variables in MSIX packages. The package is created with Microsoft's MSIX Packaging Tool and a script was used under capture. Script is adding environment variables as we can see in the virtual registry after the package has been created. Problem is that session host will not use these environment variable keys. The package works, but there's a SSO feature which doesn't work because of the environment variables. If we add them manually on the session host the SSO feature works fine. We have tried the PSF tool using the fix there for environment variables, but once we change the AppxManifest.xml to point to PsfLauncher32.exe it gives the following error on the session host: 16.03.23 15:54:29 Error 403 avd-mgmt-7 error 0x80080207: Failure to get staging session for: \\?\Volume{9dc101d8-0130-4a01-xxxx-a81e0088b390}\applications\xxxx__trsqtdqqj719r. 16.03.23 15:54:29 Error 481 avd-mgmt-7 error 0x80080207: Opening the loose file package from location xxxx__trsqtdqqj719r failed. Any suggestions on what we can try?Create AVD App Attach ready apps and publish from within Visual Studio
Visual Studio offers the Windows developers an integrated workflow to easily create MSIX packages from within their development environment. But creating an App Attach ready app is a long process, and it is even more complicated to further publish it to AVD. Recommendation: To enable developers to create and test AVD App Attach ready apps, and publish from within their Visual Studio development environment.
MSIX app attach, disks are mounted but shortcuts are not published
Hi Team, Till last two weeks all our MSIX app attach applications were working successfully. However, now we see the disks are mounted but the shortcuts are not published in start menu. In addition, for User 1 two app shortcuts are available out of 3 apps published, and for user 2 none of them are published. We did verify assignment in application groups and the state is active for the apps. Is there any pointers or log files we should be looking at to pinpoint the issue? We had raised an MS case, but no luck yet.
