ITProCloud Blog

Using MSIX AppAttach in Azure Virtual Desktop is great. To stage the MSIX AppAttach packages, the session host needs permission to read the package. If the package is placed on a “normal” file server, everything works as expected. But if the image on an Azure Files share, it would not work directly. In this case, the computer object has no permission to read data. You got the following error message:

SessionHost unhealthy: The following MSIX packages have failed to properly stage: [xxxxxxxxxxxx_yyyyyy, System.IO.FileNotFoundException: File not found.

The default approach

• Add the AVD computer objects in a global group
• Sync the group and the computer objects for the hosts
• Add the group with the RBAC Role “Storage File Data SMB Share Contributor” to the file share or storage account
• Give the global group NTFS read permission

After that, the hosts can access with their computer account the share.

The disadvantage is that if you deploy a new host, you have to add the computer object to the group and wait for the synchronization to AAD (for the group and the computer object). Meanwhile, the host cannot stage the package and cannot provide the application to the users :-(

Another approach or workaround

The issue is that the computer/system account cannot access the share. Another approach is to convince the system account to use a domain user for accessing Azure Files.

• Create a user account in AD and wait for replication
• Add the user with the RBAC Role “Storage File Data SMB Share Contributor” to the file share or storage account
• Give the user NTFS read permission

To convince the system account to use a specific user account accessing a specific Azure Files storage account. That can be tested with these two lines:

psexec -s cmd

cmdkey /add:wvdmsixdata.file.core.windows.net /user:[msix@itprocloud.de](mailto:msix@itprocloud.de) /pass:passwordOfMsixUser

Now, every time the host access wvdmsixdata.file.core.windows.net in the system context, the named user account is used - even for staging the MSIX AppAttach packages.

This step can be automized via a script directly after the rollout of a new session host. This allows the host to stage the packages directly.

You could use WVDAdmin, modify the deployment script, and run the cmdkey part after the domain join (psexec is not needed).

Another way to go is using Hydra with a script after the deployment. In this case, you could use the service account on a host pool level. Example script:

# Check, if service account is available
if ($global:Hydra_ServiceAccount_PSC -eq $null) {
  throw "Failed: Service account missing - The script needs a configured service account."
}

$fileServer="wvdmsixdata.file.core.windows.net"

$secret=[System.Net.NetworkCredential]::new("",$($global:Hydra_ServiceAccount_PSC.Password)).Password
cmdkey.exe /add:$fileServer /user:$($global:Hydra_ServiceAccount_PSC.UserName) /pass:$($secret)

$count=(Get-ChildItem "\\wvduserdata.file.core.windows.net\msix").Count
OutputWriter("The script has finished. Existing files: $count")

Note:

• This is a workaround!
• Make sure that the users’ password does not expire.