hockeyguyin714's Accepted Solutions

The communities forum is a huge resource like the previous people have suggested and I highly recommend it as well. UEM has about 36 videos in this playlist on VMware's youtube channel that ar... See more...
The communities forum is a huge resource like the previous people have suggested and I highly recommend it as well. UEM has about 36 videos in this playlist on VMware's youtube channel that are good to get you started: VMware User Environment Manager 9.2 Overview - YouTube UEM in 60 minutes is very dated but good reference point for getting started: VMware User Environment Manager Deployed in 60 Minutes or Less | VMware End-User Computing Blog When your looking for more detail the documentation pages are great: VMware User Environment Manager Documentation The documentation section in the UEM communities forum here is also a great place to get started as there are many recipes people have been working on that you can get good information. Just click documents and you can browse 100s of recipes.
So in your design you are assuming that the source never changes. AppStacks metadata file has to be updated as it tracks items like number of attachments, OS versions etc. The Data in the VMDK fi... See more...
So in your design you are assuming that the source never changes. AppStacks metadata file has to be updated as it tracks items like number of attachments, OS versions etc. The Data in the VMDK file does not change as it is attached as independent non persistent.  Your NFS will not be able to replicate that change because it is read only. It will update on the VSAN side but fail to update or replicate on the NETAPP side.  App Volumes does not have a source so it believes all storage luns are equal depending on which one has the latest data that is what it determines to overwrite.  The typical design recommendations for storage group is a single NFS shared between two sites so App Volumes would replicate via a Storage Group or multiple Storage Groups.  You are introducing something the product was not technically designed to account for.  I would recommend reviewing -  VMware App Volumes Deployment Considerations: VMware App Volumes 2.12 and Later Another option you could consider is manual replication after creating the AppStack on site B storage group to avoid the errors being ongoing.
Office 2016 is not supported at this time.  Based on the information below this is likely due to the click-to-run issue. The following may help but there is no guarantee. http://kb.vmware.com/... See more...
Office 2016 is not supported at this time.  Based on the information below this is likely due to the click-to-run issue. The following may help but there is no guarantee. http://kb.vmware.com/kb/2145079 Office 2016 has ClickToRun registry path in a different location.  I believe it is the following: exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY Let me know if that works.
You can view this under App Volumes Manager page - Directory  then select under Users, Groups or OU. You can then select the User, Group or OU. Go to Assignements section and check Override Pre... See more...
You can view this under App Volumes Manager page - Directory  then select under Users, Groups or OU. You can then select the User, Group or OU. Go to Assignements section and check Override Precedence. Then you can update occordingly.
This typically occurs because of firewall, trying to use port 443 when SSL is not enabled on the App Volumes Agent side, not putting in the correct App Volumes Manager information when installing... See more...
This typically occurs because of firewall, trying to use port 443 when SSL is not enabled on the App Volumes Agent side, not putting in the correct App Volumes Manager information when installing App Volumes agent,  as well as if you have not setup your Active Directory configuration to not allow non domain computers.