Tag Archives: app volumes

VMware App Volumes Datastore Migration – 2.18

Posted on by

This is a guide for migrating App Volumes app stacks, metadata, and entitlements to a new datastore. I’ll also cover the clean up steps to remove references to the old location(s). What will not be covered are writable volumes.

These instructions are intended for App Volumes 2.18 and may be applicable to other versions in the 2.x branch. The steps for metadata cleanup were obtained through collaboration with VMware Business Critical Support.

Update: These steps continue to work through at least App Volumes 4.9 (2212).

Requirements

  • Administrator role in vSphere vCenter.
  • Administrator role in App Volumes Manager.
  • Administrator privileges to the App Volumes Manager operating system.
  • Access to the App Volumes database server, SQL Server Management Studio, and at least DBO privileges on the App Volumes database.
  • A recent database backup in case a rollback is required.

Summary Steps

  • Use Storage Groups to duplicate existing app stacks and metadata to a new datastore.
  • Remove the Storage Group after duplication has occurred.
  • Remove the old datastore.
  • Metadata cleanup

Continue reading →

VMware App Volumes Agents Fail when LDAP Channel Binding is Enabled

Posted on by

When applying the security enhancements in Microsoft KB 4034879, we noted that the VMware App Volumes desktop agents in our VDI environment stopped functioning. After setting the value LdapEnforceChannelBinding=1 on all Domain Controllers, desktop sessions returned an App Volumes error “NTLM Authentication Invalid: Authentication failed” and no app stacks were attached to the user session.

VMware KB 2146459 provides a workaround to the specific error by disabling NTLM authentication. The KB article stated that disabling the NTLM authentication challenge would reduce security. We reached out to support to clarify the risks imposed and they were able to confirm our suspicion that skipping this check would leave the environment exposed to a potential session impersonation attack, potentially exposing another user’s App Volumes assignments. I haven’t tested the theory, but we assume that an impersonated logon message could be sent to the App Volumes manager API for a different user, and that the manager would then comply by attaching any volumes assigned to the impersonated user.

According to VMware support, the issue exists because the App Volumes manager must be able to intercept and man-in-the-middle the NTLM authentication process. Enabling channel binding on NTLM effectively disables the man-in-the-middle approach.

There were no other workarounds available at this time.