What version of App Volumes are you using? Is your template for Writable Volumes the same version? Are you only using Instant Clones? In regards to deletion if you manually delete the VM...
See more...
What version of App Volumes are you using? Is your template for Writable Volumes the same version? Are you only using Instant Clones? In regards to deletion if you manually delete the VM it will always delete all VMDKs as vCenter is designed to look at the VMX file and delete anything attached to the VM. Page 71 shows AVM_PROTECT_VOLUMES with a value of 1 which is designed to protect the volumes from being deleted when using Instant Clones or any time the pools are set to delete on logoff.. https://docs.vmware.com/en/VMware-App-Volumes/2.15/App-Volumes-Admin-Guide-215.pdf
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.
Correct. So App Volumes Manager will consider the entire AppStack including the metadata as part of the AppStack. The Metadata changing is typically what causes the replication to trigger in bot...
See more...
Correct. So App Volumes Manager will consider the entire AppStack including the metadata as part of the AppStack. The Metadata changing is typically what causes the replication to trigger in both directions for the Flat, Descriptor and Metatdata files. The copy will include all 3 pieces not just 1.
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.
Both NFS stores should be set to non attachable in App Volumes - Storage. The storage groups should be set to VSANSiteA+NFSSiteA in site A. Site B should VSANSiteB+NFSSiteB in site B. The rep...
See more...
Both NFS stores should be set to non attachable in App Volumes - Storage. The storage groups should be set to VSANSiteA+NFSSiteA in site A. Site B should VSANSiteB+NFSSiteB in site B. The replication sounds like you are doing this in some other function from NSFA to NSFB outside of App Volumes. If it is read only any updates will fail to NSF that is in read only mode. Which is expected behavior as you have blocked writes so we won't even be able to modify the metadata file which we use for tracking and updates. I would consider changing this setting of read only due to some issues you may have on SiteB on updating files. The storage group can be setup to auto replicate from VSANSiteA to NFSSiteA. The same could be done on SiteB as well.
There is a way to get this working without installing a third party executable. Even with the GPO Computer Configuration -->Administrative Templates --> Windows Components --> App Package Deploy...
See more...
There is a way to get this working without installing a third party executable. Even with the GPO Computer Configuration -->Administrative Templates --> Windows Components --> App Package Deployment --> Allow deployment operations in special profiles: Enabled it doesn't seem to allow logon with even one registry key that contains an App Store app. One of the main things I noticed is Calculator gets unregistered on second login even if you only capture the basic FTA outputs and nothing else in UEM. This can also happen on in place upgrades on a physical machines per a lot of Microsoft community threads upgrading to 1709. You will want to do 2 parts. Capture the following: [IncludeRegistryTrees] HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts HKCU\SOFTWARE\Microsoft\Windows\Shell\Associations HKCU\Software\Microsoft\Windows\CurrentVersion\ApplicationAssociationToasts [IncludeIndividualRegistryValues] HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserSignedIn Setup a logon script to reset calculator after the profile is loaded: powershell.exe Add-AppxPackage -register "'C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_10.1804.911.0_x64__8wekyb3d8bbwe\AppxManifest.xml' -DisableDevelopmentMode" I didn't test all the apps but the ones I did that were noticed as not present all work after the above work around.
Disable NTLM only applies to Computer logins on computer startup. This would still fail for authentication for the user. The difference is easily seen users are domain\username computers ar...
See more...
Disable NTLM only applies to Computer logins on computer startup. This would still fail for authentication for the user. The difference is easily seen users are domain\username computers are domain\computername$
Make sure ports 3001-3004 are also available and running. The message is distinct that App Volumes Agent did not reach App Volumes Manager. Are you using a load balancer for App Volumes Manag...
See more...
Make sure ports 3001-3004 are also available and running. The message is distinct that App Volumes Agent did not reach App Volumes Manager. Are you using a load balancer for App Volumes Manager?
You are correct it is a command line. Command line information starts on page 36 of the App Volumes Installation and Administration guide: http://pubs.vmware.com/appvolumes-30/topic/com.vmware....
See more...
You are correct it is a command line. Command line information starts on page 36 of the App Volumes Installation and Administration guide: http://pubs.vmware.com/appvolumes-30/topic/com.vmware.ICbase/PDF/appvolumes-30-install-admin.pdf
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.
It might be helpful to turn debug logging on the App Volumes Manager to see what Active Directory server was used to authenticate the user. App Volumes logs the LDAP failure code which should g...
See more...
It might be helpful to turn debug logging on the App Volumes Manager to see what Active Directory server was used to authenticate the user. App Volumes logs the LDAP failure code which should give you some key indication why it failed or timed out or whatever the issue was. http://kb.vmware.com/kb/2101668 You will want to look at production.log on the App Volumes Manager to see why the user failed to login. Make sure to turn debug logging off after you figure out the possible cause. App Volumes Manager will talk to the DC that first responds to the query for that domain. This can be controlled and limited by Active Directory Sites and Services to further increase success chances.
Typically this occurs if you have time skew between machines and the AD servers. Verify that all yours hosts and AD servers line up on the same time. Check Windows Event logs errors with time o...
See more...
Typically this occurs if you have time skew between machines and the AD servers. Verify that all yours hosts and AD servers line up on the same time. Check Windows Event logs errors with time or domain controller access.
If the NIC was truly disabled View would also be unaware of it powering on and would have no communication to the VM to report via the View Broker Integration Service. If View is aware the deskt...
See more...
If the NIC was truly disabled View would also be unaware of it powering on and would have no communication to the VM to report via the View Broker Integration Service. If View is aware the desktop is powered up there is a NIC for communication.
Just to clarify App Volumes 2.9.1 will help ease the pain of environments having this issue. The problem is that there is something going on in the infrastructure causing this issue in the first...
See more...
Just to clarify App Volumes 2.9.1 will help ease the pain of environments having this issue. The problem is that there is something going on in the infrastructure causing this issue in the first place. vCenter SSO failing to connect due to bad configuration or bad Active Directory Servers, Network issues or latency, vCenter SQL database issues to name a few, Active Directory replication issues. These items need to be addressed along with the hotfix to avoid it from happening in the future.