Day 39: AZ-140 Pt.4.2 - Managing Users & Apps - Configure Apps
Section 4: Manage User Environments & Apps (20-25%)
Install and configure apps on a session host
- Configure dynamic application delivery by using MSIX App Attach
- Implement application masking deploy an application as a RemoteApp
- Implement and manage OneDrive for Business for a multi-session environment
- Implement and manage Microsoft Teams AV Redirect
- Implement and manage browsers and internet access for Windows Virtual Desktop sessions
- Create and configure an application group
- Troubleshoot application issues related to Windows Virtual Desktop
- In the below steps, it should be noted I am not going to say click this n that, I will give a general overview but you will need to fill in the gaps with your knowledge of Azure.
- All opinions below are my own and are not representative of any company I am linked with.
- All scripts and information followed below is at your own risk and I hold no responsibility if you run any of it in production without testing in pre-production first.
MSIX app attach is a way to deliver MSIX applications to both physical and virtual machines. However, MSIX app attach is different from regular MSIX because it's made especially for Windows Virtual Desktop.
Essentially, what MSIX App Attach allows you to use existing MSIX packages in WVD environments.
What's cool about this is a few things:
- Existing MSIX apps you've created for line of business apps can be re-used for WVD.
- You can use SCCM packages, leveraging the same MSIX for physical workstations and virtual.
- No fussy application layering like in traditional environments (think ELM in Citrix).
- Utilize vendors producing more and more applications in MSIX so you don't need to package them yourselves, taking away requirements to manage off the shelf applications and updates.
- No requirements for on-prem steerage to host the files if you want to go fully cloud.
- Less environments being used, centralized locations, easier to upskill and support.
- A functioning Windows Virtual Desktop deployment. To learn how to deploy Windows Virtual Desktop (classic), see Create a tenant in Windows Virtual Desktop. To learn how to deploy Windows Virtual Desktop with Azure Resource Manager integration, see Create a host pool with the Azure portal.
- A Windows Virtual Desktop host pool with at least one active session host.
- This host pool must be in the validation environment.
- The MSIX packaging tool.
- An MSIX-packaged application expanded into an MSIX image that's uploaded into a file share.
- A file share in your Windows Virtual Desktop deployment where the MSIX package will be stored.
- The file share where you uploaded the MSIX image must also be accessible to all virtual machines (VMs) in the host pool. Users will need read-only permissions to access the image.
- If the certificate isn't publicly trusted, follow the instructions in Install certificates.
- Download 7zip.msi installer - https://www.7-zip.org/download.html
- Download MSIX Packaging Tool - https://www.microsoft.com/en-gb/p/msix-packaging-tool/9n5lw3jbcxkf?rtc=1&activetab=pivot:overviewtab
- Install 7zip to local machine using the MSIX packaging tool - this will create my MSIX file.
- Create my VHDX by using disk management, this will house my MSIX extracted files.
- Download the MSIX Manager tool - https://aka.ms/msixmgr
- Use the MSIX manager tool to publish the files to your VHDX and apply ACLS.
- Create a file store (within a storage account) in Azure
- Configure NTFS permissions so your host pool machines have access to the store.
- Configure Storage SMB contributor role in Azure for the host pool machines to the store.
- Upload the VHD into your store (I just copy / paste rather than upload through ARM).
- On each of the hostpool machines, make sure the cert for the MSIX is installed to "Trusted People" within Local Computers.
- In your hostpool, add the MSIX, note the file path needs to be \\filestore\store\nameofvhd
- It will can the file, check everything's all good with your MSIX and then it'll add it to your hostpool
- You then create an application group for the MSIX, and choose whether you want it in the hostpools itself or as an app that runs by itself but spins up a WVD box in the background to host the app, or both... just select both, its cool.
"Use Application Masking to manage user access of installed components. Application Masking may be used in both physical and virtual environments. Application Masking is most often applied to manage non-persistent, virtual environments, such as Virtual Desktops."
- Newer technology, cutting edge
- Repurpose existing MSI files
- Vendors often supply MSI files
- Ability to change an app on the fly without affecting users
- WVD VHD and MSIX VHD are different files
- Dynamic approach to modern management of devices
- Newer technology, cutting edge
- Difficult to learn, a lot of content to cover
- A more risky approach, can be unstable
- In Public Preview still, bugs / improvements missing
- MSIX packaging can be frustrating
- Limited shell integration / right click
- Older technology, more developed
- A more grounded base, wider understanding/guides available
- It just works, very granular and specific with rule sets
- Simple to learn and implement
- Can be used to hide apps via GPO if required
- Easy to get to grips with if you've used it in Citrix environments
- Less dynamic, gold image would need to be mounted and application updated
- Older technology, I imagine MS will be focusing on MSIX rather than updating both
- Although more granular, its more fiddly, as it requires all registry entries to be appropriately captured
- Funky things happen, for example: If you deploy Java and mask it, create a security group etc. for it, that will work, but if you allowed your users the ability to install an additional Java version, and that user doesn't have visibility of the version of Java you've installed, then App Masking will bug out and display the Java you've deployed in addition to the version the user has deployed, causing conflicts in the image and causing reboots / disconnects etc.
OneDrive provides a robust but simple-to-use cloud storage platform for small businesses, enterprises, and everything in between. Unlike other cloud storage providers, most of the advanced enterprise-focused features in OneDrive are available for every subscription type
- The minimum supported versions are: OneDrive 19.174.0902.0013 and FSLogix Apps 2.9.7486.53382.
- For Windows Server, the SMB network file sharing protocol is also required.
- The OneDrive sync app is not supported in remote app scenarios.
- The OneDrive sync app with FSLogix does not support running multiple instances of the same container simultaneously.
- Older systems only support VHDX, most newer use VHDX (which you should be using anyway).
Microsoft Teams on Windows Virtual Desktop supports chat and collaboration. With media optimizations, it also supports calling and meeting functionality.
Essentially with Teams, a big decision you have to make is with how you deploy it. The decision is do you want specific users to have Teams or all users that login to the device?
If you install teams for users, then it wont work in a non-persistent environment (non personal), this being one where a user is logging into a different machine (as part of a host pool) each time, however is you were using a personal allocation type, so a user has a set machine or physical box, then you can safely use the below for users.
However, is using a non persistent environment, you should probably be using the second command.
These examples also use the ALLUSERS=1 parameter. When you set this parameter, Teams Machine-Wide Installer appears in Programs and Features in Control Panel and in Apps & features in Windows Settings for all users of the computer. All users can then uninstall Teams if they have admin credentials. It's important to understand the difference between ALLUSERS=1 and ALLUSER=1. The ALLUSERS=1 parameter can be used in non-VDI and VDI environments, while the ALLUSER=1 parameter is used only in VDI environments to specify a per-machine installation.
The below links give more detail, but its simple a case of:
- Is your environment persistent or not?
- Have you installed Teams to your gold layer?
- Have you configured the WVD registry setting in your environment?