I ran into an issue recently with the vCenter Server Appliance where the file based backup jobs suddenly stopped working on environments running 6.7. Attempts to run the backup job manually failed with the UI reporting “Location type SMB is not supported”, which is unexpected since SMB is supported.
Tag Archives: VMware
VMware App Volumes Datastore Migration – 2.18
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.
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
vCenter Storage Providers appear Offline after Host Certificates are Installed
I ran into an issue where configuring vSphere with an intermediate signing certificate and replacing certificates on all hosts would cause the storage providers to go offline. Refreshing host certificates would also cause the issue.
VMware support determined the cause was the removal of the vCenter SMS certificate in the hosts local trust store. This certificate is not pushed to the hosts when the trust store was refreshed. This behavior occurs at least on vSphere 6.7 and 7.0. To resolve the issue, it is necessary to manually add the SMS certificate to the hosts trust store.
VMware App Volumes Agents Fail when LDAP Channel Binding is Enabled
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.
VMware Identity Manager Reverts DNS Resolver Changes on Restart
I ran into a bug where the VMware Identity Manager / VMware WorkspaceONE virtual appliances (3.2.0.1) would not persist changes to network settings across reboots. Attempting to update the DNS resolver addresses were reverted when the appliance rebooted. It didn’t seem to matter whether the changes were applied on the vApp tab in vCenter, directly onto the appliance using vami_config_net, or by directly editing network configuration settings in the OS; all methods reverted the appliance’s DNS resolvers to the previous entries at reboot.
After some back and forth with VMware’s Business Critical Support, we determined that KB 54981 resolved the issue. The KB article is specific to changing IP addresses in a cloned system, but it applied to our case as well. Deleting the three backup files allowed the new resolver addresses to persist across reboots.