Forum Discussion
MSIX app attach Azure portal integration public preview
hello,
I still have this error The MSIX Application metadata expand request failed on all Session Hosts that it was sent to. Session Host: wvd-0, Error: Error accessing virtual disk at ≤\\http://disq.us/url?url=http%3A%2F%2Fstowvd.file.core.windows.net%3AbaMBd1fsU9jqGVMJMVBgv-L8_Rc&cuid=4572167\msix\bignotepadplusplus.vhd≥. (Code: 400)
As you can see, some stuffs are missing from the page ADD MSIX PACKAGE (we should see msix package, package application, display name....)
Same problem after recreating the hostpool on another region.
- Thomas-DeWitteFeb 07, 2021Iron Contributor
- Stefan GeorgievDec 20, 2020Iron ContributorThis is a permissions issue. The VMs in your host pool cannot access the path. Are you using Azure File? (check https://techcommunity.microsoft.com/t5/windows-virtual-desktop/step-by-step-guide-on-computer-account-auth-for-azure-files/td-p/1855164) if not put MSIX images on a folder on your c: drive and share it to everyone if that does not work pm me 🙂
- biginquebec130Dec 20, 2020Copper Contributor
hello Stefan
I checked once again permissions for session host on both share (RBAC) and directory level (NTFS) but I still have this error : “...Error accessing virtual disk at…”
Note that Host and storage account are joined to an Azure ADDS (not classic ADDS)
-RBAC : my host has the role Storage File Data SMB Share Contributor on the Storage account
(it’s also a member of an Azure AD group with this role)
-NTFS level : my Host has -modify- on the storage account’ Share
Note that the host can access and mount this vhd \\stoxxx.file.core.windows.net\msix\GoogleChrome_68.46.66.0_x64__74vyvr5aw93s6.vhdx
I tried put the vhd on a local share and it works like a charm.
Please help me to find where is my mistake with Azure File permissions in the Azure ADDS scenario.
Best regards
- nbird22Dec 21, 2020Iron Contributor
biginquebec130
Pretty sure this isnt supported. Games a bogey with AAD DS as there is no hybrid join capability so no writing back the devices to AAD. You're giving the Managed Identity of the VM access to FileShare, this isnt the AD object for which it'll determine has the correct NTFS permissions.
Keen to get confirmation/roadmap item for this scenario though as we have a few environments that use standalone AAD DS as opposed to classic ADDS with Synchronization.
- Mika_Seitsonen_SDec 19, 2020Copper Contributor
biginquebec130 the other fields only appear after the session host can access vhdx. For me, the cure was to recheck/grant permissions for session host on both share (RBAC) and directory level (NTFS). I then cleared Kerberos tickets for the computer account (effectively skipping restarting it) with command klist purge -li 0x3e7. After that it worked 🙂