VirtualSpence's Posts

With App Volumes 4 you can create an application which contains multiple packages. Package = AppStack (2.x) = VMDK Programs are the actual bits that get installed to a package during the packaging process. When you create an assignment at the application level, you can only assign one of the packages contained in it. The idea is to create a workflow which allows you to manage the lifecycle of a particular piece of software more easily. Take this example for managing the lifecycle of Notepad++ : This is the preferred workflow to manage application lifecycle. However, you can certainly create packages containing multiple programs like this: For a lot more detail about what's new in App Volumes 4, check out this interactive demo: DEMO: App Volumes 4.0 Feature Review | Demo

Conceptually, this will work and VHDs are pretty easy to configure and deliver. I did some testing with App Volumes configured for VHD to share packages between my on-prem Horizon and Horizon Cloud Service on Microsoft Azure App Volumes implementations. However, App Volumes requires nonpersistent operating systems. Unless you're doing something like streaming np Win10 images to your physical PCs, this wouldn't be a supported configuration.

Hmmm, there are a few errors in the logs. Is the user account you're using to login to the packaging VM a local administrator or a standard user? Because you're trying to install/capture software, the account needs local admin permissions. Did you apply a valid certificate to the App Volumes Manager? If not, and you're still using the self-signed cert that comes with the installer, be sure to disable cert validation on the App Volumes agent.

Nothing quite like that in App Volumes. However, if you're using Horizon you could use the "send message" ability in the Horizon console to send an immediate alert to a user. It would work well for one-off notifications, but probably less useful for large assignments.

There shouldn't be anything special you need to do for this. If the apps (Windows apps or anything else you install in the base image) are on the IC base image, they should work when AppStacks/Packages are attached, unless the Package specifically includes programs that overwrite what's on the base image. Which version of App Volumes are you running? How are you creating your App Volumes packaging machine? A common practice is to use a clone of your IC base image with the Horizon agent removed as your packaging machine. This helps to ensure there is no configuration drift between the packaging machine and the VMs that will attach the Packages. Be sure to take a snapshot of the VM before you ever use the VM for packaging, and be sure to revert to snapshot between each use.

When using App Volumes with application publishing, the package must be attached to the RDS host at startup. This makes the program(s) contained in the package available to users who access the RDS host. Because of this, only assignments to the computer object (direct or using the OU where computers objects reside) are supported with RDSH. After you assign the package to the machine object, the RDS host must be rebooted so the package can be attached at startup. Have you tried rebooting the RDS host(s) after assigning to the OU? If you're still having trouble, please post manager and agent log snippet when the error occurs.

Is your packaging VM joined to the domain? If not, be sure you've configured your AVM to support non-domain entities (disabled by default in AV4). When preparing your packaging VM: Did you remove the Horizon agent and any anti-virus software? Did you shut the VM down and take a snapshot before any Packages were attached to the VM? See the following links for additional recommended practices for your packaging VM: Preparing a Packaging Virtual Machine Best Practices for Packaging Applications Verify the ESXi host your packaging VM is running on has access to the datastore where your packaging template and new Packages will be created. Do you see any specific errors in the AVManager > Activity > System Messages when the failure occurs? What about the agent logs on the Packaging VM?

Hey popvm​, I'm glad to hear your testing is going well. One of the benefits to using Folder Redirection is that you are simply providing a pointer to the operating system, rather than retrieving all the data. That is, when a user attempts to launch a Word document from the redirected Documents folder, Folder Redirection tells the OS to go get that file from a network share instead of locally. Because of this behavior, it shouldn't matter if you have 1 file or 1,000 files in the Documents folder. When you logon, Folder Redirection still tells the OS where on the network the Documents folder resides. It really shouldn't have much, if any impact on logon times. All that said, some folders tend to be more active than others, so redirecting them may consume extra resources. If you look at the Dynamic Environment Manager Folder Redirection policy settings, you'll see recommendations: Of course, all of these are just guidelines, and we recommend people always perform testing, as you are, before rolling into large scale production. Thanks for following up, and please keep us posted on your progress!

Lieven​ is right. FSLogix is using a filter driver. The filter driver makes it appear to Windows that the Profile Container (attached VHD) is just an extension of the existing C:\. Think of the filter driver as a layer that stitches the drives together, merging their content from the perspective of the Windows OS into a single drive. The filter driver is configured to intercept I/O operations bound for the C:\, and direct those destined for the profile locations to the VHD. The following is an oversimplified means of visualizing how this works. If you use Windows without a Profile Container, and without Folder Redir, the workflow looks like this: User creates a new document and saves it to the Documents folder. Windows checks the registry for the location of the Documents folder (in this case, C:\Users\<username>\Documents) and performs a write operation to store the file. If you introduce FSLogix with a Profile Container but without folder redirection, the workflow looks like this: User creates a new document and saves it to the Documents folder. Windows checks the registry for the location of the Documents folder (in this case, C:\Users\<username>\Documents) and performs a write operation to store the file. The FSLogix filter driver intercepts the write operation, and redirects the write from the actual C:\ to the Profile Container (VHD). To Windows, it appears as though the new document is located on the C:\, when in fact it's stored on the VHD. If you introduce Folder Redirection with the FSLogix Profile Container, the workflow looks like this: User creates a new document and saves it to the Documents folder. Windows checks the registry for the location of the Documents folder (in this case, folder redirection states this is \\server\share\Users\<username>\Documents) and performs a write operation to store the file. The FSLogix filter driver does not need to intercept the write operation, because the write is not destined for C:\.

I staged this in my lab this morning as follows: Create floating assignment, W10 IC pool. These desktops of course are refreshed after each log off. DEM was configured to enable Folder Redirection. FSLogix was configured for Profile Container. After logging in with a test user account, I verified the Profile Container was created and the user's folder was created on the Folder Redirection share. Using the logged in test account, I created a number of files and folders in "Documents", which is one of the redirected directories. Logging on and off several times, I could see the data being persisted from session to session. Navigating to the folder redirection network share, I could see the profile data was properly being redirected. I then performed a manual attachment of the test user's VHD on a management system, and browsed the contents. None of the files or folders I'd created as the test user in the Documents directory were present on the Profile Container. To summarize, my testing indicates Folder Redirection works with the FSLogix Profile Container without the need to configure FSLogix exclusions. If you find different behavior, please reach out and let's continue to discuss.

According to the interop matrix, App Volumes 4.0.1 is compatible back to Horizon 7.10.0: VMware Product Interoperability Matrices You can use the 2.18 agent with a 4 manager, but there are some considerations. Check out the App Volumes 4 Installation and Upgrade Considerations guide and check out the section on coexistence.

My thoughts inline in blue: 1) Is DEM + FSLogix a good solution for Persistent Desktops? I see many people mention them for Non-persistent desktop. Microsoft mentions physical machines in the FSLogix overview, but it's not clear to me whether it's supported with Profile Containers, Office Containers, or both, or if/what the exceptions might be. I've reached out in an attempt to confirm. FSLogix Overview - FSLogix | Microsoft Docs : FSLogix solutions may also be used to create more portable computing sessions when using physical devices. 2) Has anyone tried integrating DEM and FSLogix and if yes, how does it look performance, functionality and stability wise? @DEMdev already gave you the link showing our integration testing of Horizon with FSLogix Profile Containers. We've also some some work with Office Containers: Best Practices for Delivering Microsoft Office 365 in VMware Horizon 7 | VMware 3) How easy is it to configure? DEM and FSLogix are both simple setup, and have similar requirements. Both have an agent, both rely on network shares to store user data, and neither require any type of dedicated server or database. We have all sorts of resources for DEM on techzone.vmware.com to help you be successful: - Quick-Start Tutorial for User Environment Manager | VMware - Profiling Applications: VMware User Environment Manager Operational Tutorial | VMware - Mastering Dynamic Environment Manager | VMware In my experience working with FSLogix, it has been easy to install and test with. That said, I'm using a clean lab environment and not trying to design for a production implementation. If you're using Profile Containers to persist the entire user profile (including user data) using FSLogix VHD(X)s, you should consider end users will have data in virtual drives that may be attached to VMs most of the time, making it difficult to back them up. Adding Folder Redirection to your model may address this by getting user data off of the virtual disks. With DEM persisting configuration data, Folder Redirection persisting user data, and FSLogix persisting large caches of Office data (OneDrive, OST, etc), you may be able to consider your VHDs disposable, which simplifies your design and reduces admin overhead. 4) Anything we will have to consider when we are using it on vGPU environment? Nothing that I'm aware of, but I haven't personally done any work specifically using vGPU and FSLogix. 5) Is there a way to migrate existing profiles once we move to DEM + FSLogix? We are doing some work on the various options for migrating off of Persona Management to alternative solutions, such as DEM + Folder Redirection, FSLogix, App Volumes, etc. There's a lot more work to be done before we publish anything, but I can share a few thoughts on this. DEMdev already provided a KB article that walks you through the process of migrating from Persona Management to DEM + Folder Redirection. Early testing shows you can use that method, and simply add the FSLogix Office Container to the mix to help with Office Cache data (this model is particularly useful for non-persistent desktops that use O365). We've also had some success migrating PM data to FSLogix Profile Containers, but again we have to consider the long term management of user data. You mentioned moving from Win7 to Win10. Profile versions have been updated a lot from Win7 to Win10. MS has a nice table in this doc: Create mandatory user profiles (Windows 10) - Windows Client Management | Microsoft Docs I'm not sure how all that would play into your migration strategy, but it's definitely something to consider. I hope this helps, and would appreciate continuing the discussion here so others might benefit from what you learn through this process.

Agreed. It's important that there are no UWVs or other AppStacks/Packages assigned to the user/computer during packaging. Also, make sure you have a snapshot of your packaging machine before ANY volumes have been attached, and revert to snapshot between packaging sessions.

Thanks for sharing your findings, Lieven. I'm interested in learning more about how you're using the Profile Containers. 1. Are you storing user data locations such as the Documents folder in the container, or are you using Folder Redirection to redirect some parts of the profile to a network share? 2. Can you share any details about your process to backup the Profile Containers? I'm assuming users need to be disconnected to take a backup, and would like to understand how you approach this. Any info you can share would be greatly appreciated.

I'm sorry Natestack, but I'm unable to comment on roadmap items. What I can tell you is your request has been captured and the Product Management team is aware of it. Thank you, and please keep the feedback coming!