VMware EUC Win10 Compatibility Components

Updated: 1/4/2019



Semi-Annual Channel


Supported Fresh Install Only


Broad Deployment


Supported, reference KB


Not Supported


Windows 10 OS Version: 1607
(Ent, Pro)
1703 CBB
Semi-Annual Channel
(broad deployment)
(Ent, Pro, Edu)
Semi-Annual Channel
(broad deployment)
(Ent, Pro, Edu)
Full support 
Horizon 7            
Horizon Agent 7 NS NS NS NS NS NS
Horizon Agent 7.0.1 NS NS NS NS NS NS
Horizon Agent 7.0.2 SF SF NS NS NS NS
Horizon Agent 7.0.3 S S NS NS NS NS
Horizon Agent 7.1 S S S NS NS NS
Horizon Agent 7.2 S S S S-KB NS NS
Horizon Agent 7.3.2 S S S S-KB S NS
Horizon Agent 7.4 S S S S-KB S NS
Horizon Agent 7.5 S NS S S S NS
Horizon Agent 7.5.1 S NS S S S NS
Horizon Agent 7.6 S NS S S S S
Horizon Agent 7.7 S NS S S S S
App Volumes            
App Volumes 2.12 S S NS NS NS NS
App Volumes 2.13 S S S NS NS NS
App Volumes 2.14 S S S S S NS
App Volumes 2.15 S S S S S S
User Environment Manager            
User Environment Manager 9.2 S S S NS NS NS
User Environment Manager 9.3 S S S S NS NS
User Environment Manager 9.4 S S S S S NS
User Environment Manager 9.5 S S S S S NS
User Environment Manager 9.6 S S S S S S

Download this chart in Excel format!


UEM Supported Version with Windows 10

 Horizon Supported Version with Windows 10

 App Volumes Release Notes generally has Windows 10 support information

Interop Matrix (VMware components)

Special thanks to Steven Hajny (https://www.linkedin.com/in/stevenzhajny/) for gathering this information

Horizon Install Order and Silent Installs

This blog post is regarding the correct order of installing/Uninstalling Horizon Agents, Silent Installs/Uninstalls, and enabling FIPS.


VMware Horizon Install Sequence Order 



Installation of various user experience, environment and VDI agents can cause unexpected issues of fail completely if installed in the incorrect order.
If you need to upgrade the Horizon View Agent you will need to reverse this process from the bottom-up.


1.     Hypervisor Tools


2.     VDI Agent


3.     VMware vRealize Operations Manager Agent

  • If you have a View 5.0 or 5.1 environment, you must manually install the desktop agent on your desktops. The vROPs Agent is included with the Horizon View agent 5.2 or later.


4.     VMware vRealize Log Insight Agent

  • If Log Insight is not deployed in the environment, skip this step.


4.     VMware User Environment Manager (UEM) Agent (formerly Immidio Flex+)

  • If VMware UEM is not deployed in the environment, skip this step.


5.     VMware App Volumes Agent

  • If VMware App Volumes is not deployed in the environment, skip this step.


Horizon View, Silent Install Instructions:






Paul Grevink has a good blog that walks through the View Agent components:



1.     In the View desktop, go to Start > Run, type regedit, and click OK. The Registry Editor window opens.

2.     Navigate to:


3.     Find the value that corresponds to the version of View Agent software that is installed. For example:

View 4.5 – {6F862EF7-F25E-4B3B-8345-FA005F12F668}
View 4.6 – {EFF57BA4-5BF2-403E-84BC-3469F9DAAACD}
View 5.0 – {5DD04237-3DCD-4735-BF8F-3BEEC0F61A6E}
View 5.1 – {CDA7820C-4849-4E55-A7B1-38E175B5F61C}
View 5.2 – {58D47F5C-618E-11E2-8D25-74C36188709B}
View 5.3 – {E3AD16CE-E5D6-4844-98FF-75E96EF7377F}
View 6.0 – {1230DF2B-7BA0-4AAD-80EA-527A3C3614D4}
View 6.1 – {A2E9FEAC-6D18-4890-9428-A6F53D600E01}

4.     To silently uninstall the View Agent, go to Start > Run, type cmd, and click OK.

5.     The command prompt opens launch a command prompt and run this command:

MsiExec.exe /X {AGENT_VALUE} /forcerestart /qn


Where the AGENT_VALUE is the value noted in Step 3.


VMware Horizon View, Silent Uninstall Instructions:



VMware vRealize Log Insight Manager, Silent Install Instructions:


  1. Log in to the Windows machine on which to install or update the vRealize Log Insight Windows agent.
  2. Open a Command Prompt window.
  3. Change to the directory where you have the vRealize Log Insight Windows agent .msi file.
  4. Run the following command to install or update with default values. Replace Version-Build_Number with your version and build number.

The /quiet option runs the command silently, and the /lxv option creates a log file in the current directory.

Drive:\path-to-msi_file>VMware-Log-Insight-Agent-Version-Build_Number.msi /quiet /lxv* li_install.log


(Optional) : Specify a user service account for the vRealize Log Insight Windows agent service to run under.

Drive:\path-to-msi_file>VMware-Log-Insight-Agent-*.msi SERVICEACCOUNT=domain\user SERVICEPASSWORD=user_password


VMware User Environment Manager, Silent Install Instructions:




msiexec.exe /i “VMware User Environment Manager 9.2 x64.msi” /qn INSTALLDIR=”C:\Program Files\Immidio” ADDLOCAL=”FlexProfilesSelfSupport” LICENSEFILE=”\\filesrv1\share\VMware UEM.lic” /l* InstallUEM.log



msiexec.exe /i “VMware User Environment Manager 9.2 x64.msi” /qn INSTALLDIR=”D:\Apps\VMware UEM” ADDLOCAL=”FlexProfilesSelfSupport” LICENSEFILE=”\\filesrv1\share\VMware UEM.lic” /l* InstallUEM.log

msiexec.exe /i “VMware User Environment Manager 9.2 x64.msi” /qn INSTALLDIR=”D:\Apps\VMware UEM” ADDLOCAL=”FlexProfilesSelfSupport” LICENSEFILE=”\\filesrv1\share\VMware UEM.lic” /l* InstallUEM.log\Flex Profiles\FlexEngine.exe


VMware App Volumes, Silent Install Instructions:




msiexec.exe /i “App Volumes Agent.msi” /qn MANAGER_ADDR=<Manager_FQDN/IP> MANAGER_PORT=<port>



msiexec.exe /i “App Volumes Agent.msi” /qn MANAGER_ADDR=appvm.vmbucket.com MANAGER_PORT=443


VMware App Volumes, Silent Upgrade Instructions:


  1. Open a Windows command prompt on your machine.
  2. Type the following command to upgrade the agent:

msiexec.exe /i “App Volumes Agent.msi” /qn REINSTALLMODE=vomus REINSTALL=ALL


Disabling EnforceSSLCertificateValidation with REGKEY

















You can disable SSL certificate validation after you have installed the App Volumes agent. To do this manually make the modification to registry to create your own .reg file to import. You will need to disable EnforceSSLCertificateValidation if you have FIPS enabled in your environment.

Registry location, set value to ‘00000000’ to disable:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\svservice\Parameters] “EnforceSSLCertificateValidation”=dword:00000000


Registry file import command: regedit.exe /s path of .reg file


Example of importing a registry file:


reg import c:\location\regfile.reg



Rarely needed, unless your organization has a hard security requirement, you may need to enable FIPS mode. Please keep in mind, enabling FIPS mode, can break a lot of things if not properly setup. You can Enable or disable the FIPS setting via a registry setting, GPO, or Local Policy. To check whether FIPS is enabled or disabled in the registry, follow the following steps:

  1. Press Windows Key+R to open the Run dialog.
  2. Type “regedit” into the Run dialog box (without the quotes) and press Enter.
  3. Navigate to “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\”.
  4. Look at the “Enabled” value in the right pane.
  5. If it’s set to “0”, FIPS mode is disabled. If it’s set to “1”, FIPS mode is enabled.
  6. To change the setting, double-click the “Enabled” value and set it to either “0” or “1”.
  7. Restart the computer.

FIPS mode needs to be enable on the Windows servers and on the golden image. 

For more information on FIPS mode, visit https://docs.vmware.com/en/VMware-Horizon-7/7.0/com.vmware.horizon-view.installation.doc/GUID-8A3ACF3D-05C5-4216-BD79-A53A72EE1D91.html

Steps for monitoring App Volumes with Log Insight Manager


The first step in this process is to install Log Insight Agent on ONE App Volumes Server per instance.

1. From the Log Insight Manager web portal navigate to the top-corner of the page selecting the three lines

2. Select ‘Administration’

3. Select ‘Agents’

4. Select the dropdown under ‘Agents’

5. Select ‘+ NEW GROUP’

6. Fill out the group name, i.e. ‘App Volumes Managers’

7. Select ‘New Group’

8. Select the dropdown under ‘Agents’ again and this time select your new Agent Group

9. From the dropdown select ‘IP Address’ (default)

10. Select ‘matches’

11. Manually enter the IP address for your App Volumes Manager instances. In this example, I have two sites aka two instances. The IP I am providing is the Load-balanced IP. You can also just put the direct broker IP for testing but we recommend App Volumes Managers be fronted with a load balancer.

12. Select ‘Refresh’

13. After selecting ‘Refresh’ you will see the App Volume Managers that you added in step eleven. If your servers do NOT populate continue until the end of the steps outlined.

14. Enable auto-update for all agents

15. Select ‘Edit’

16. Copy-past the following content into the dialog:

directory=C:\Program Files (x86)\CloudVolumes\Manager\log
directory=C:\Program Files (x86)\CloudVolumes\Manager\log

17. Select ‘Save Agent Group’

18. Finally, select ‘Refresh’ to validate your servers are populated

If you have completed all the above steps and still do NOT see your App Volume Managers in the agent list after selecting ‘refresh’ you could have something blocking traffic from the Managers to the Log Insight Collector. You do not need to manually edit any files local to the App Volumes Managers. When validating if data is collecting from dashboards you should wait a minimum of five to ten minutes after following the steps in this blog.

AppVolumes 2.12 and SQL AlwaysOn Migration

Hey all, I wanted to highlight an excellent blog post Mark Ma did about Migrating from a single SQL database with App Volumes to an AlwaysOn solution. With the recent release of App Volumes 2.12, we officially support Microsoft SQL Server AlwaysOn Availability Groups. SQL AlwaysOn Availability Groups is a great way to provide high availability and disaster recovery because live copies of your databases reside on secondary servers. By integrating SQL AlwaysOn with App Volumes, we ensure the most popular application layering product can be enjoyed by users in any situation. Uninstall 2.11 then Run setup wizard for 2.12

To accelerate your migration process, follow the steps below to migrate App Volumes from a single SQL database to SQL AlwaysOn Availability Groups (SQL 2014 Service Pack 1):

1. Launch the VMware App Volumes 2.12 Installation Wizard, and click Next.

2. Accept user agreement

3.Install App Volumes Manager

4. Launch App Volumes Manager Wizard.

5. Connect to an existing SQL Server Database (Pre-created)

6. Choose the single SQL server with the pre-created AppVolume database.

7. Choose https for secure connection.

8. Choose installation directory.

9. Install.

10. Finish.

11. Launch Manager Console.

12. Verify all services is working.

13. Stop App Volumes Manager Services

14. Backup AppVolume database.

15. Add AppVolume Database to SQL AlwaysON Availability Groups.

16. After verify Database is replicated in SQL AlwaysOn Availability Group change ODBC settings.

17. Edit 64 Bit ODBC settings.

18. Change SQL server from single SQL server to SQL AlwaysOn Availability Group Licenser.

19. Start App Volume Manager services.

20. Verify App Volumes Manager is up and running by launch the console.

I hope this post was valuable in helping you learn how to migrate App Volumes from single SQL Server database to SQL AlwaysOn Availability Groups (SQL 2014 Service Pack 2).

App Volumes and Blocked Ports

When installing a fresh App Volumes Manager, you might receive the error that HTTP port is in-use. Verify services such as Microsoft’s IIS is not running, if it is, remove it. To check what application is using what port on a Windows system execute the following from a command-line:

Syntax: Netstat<space>-anob

Netstat –anob

This will list all ACTIVE connections; example:


Syntax: Netstat<space>-anob<space>|<space>findstr<space>:<port>

Netstat –anob | findstr :80

Additional services you can check would be:

Service System Service Name Port(s)
SharePoint Server 80, 443
Windows Media Services WMServer 80
World Wide Web Publishing Service W32SVC 80, 443
SQL Reporting Service ReportServer 80
Sync Share Services SyncShareSvc 80
Web Deployment Agent Service MsDepSvc 80
Internet Information Server WAS, IISADMIN 80


HTTP (HTTP.SYS) Hidden Driver/Service

Windows Server 2003/2008/2012 and Windows XP(SP2)/Vista/7/8/10 comes with an HTTP front-end proxy service who’s job is to parse and forward incoming HTTP requests to other Services.

Values in URL “http://hostname:port/virtual_url_or_dir” are registered with it, and when an HTTP request comes in that matches on those values, that request gets routed to the other application or service (which itself is running on a different port).

HTTP.SYS is usually started “on demand” by other services (Windows Remote Management, Print Spooler, etc), and is not usually listening on port 80 until some other application registers a HOST ( + PORT (80) + virtual URL/DIR with it. HTTP.SYS runs under PID 4 (NT Kernel).

On some Windows systems, oftentimes port 80 is already taken by HTTP.SYS for use.

Show Reserved URLs:

netsh http show urlacl


Show active Registered URLs:

netsh http show servicestate


To Disable HTTP.SYS:

  • Control Panel > Device Manager
  • In menu View, select: Show hidden devices
  • Open tree: Non-plug and Play Drivers
  • Double-click: HTTP
  • Tab Driver – Group Startup
  • Switch from: Demand to Disabled

Or run this from the administrative privileged command-line (right click cmd.exe, select – run as admin):

  • net stop http /y
  • sc config http start= disabled

Windows Work Folders

Under Windows Server 2012 R2 and Windows 8, Microsoft has introduced a new feature called “Work Folders”, that synchronizes files/folders between different machines.

By default, “Work Folders” uses ports 80 and 443!

There are 3 options to get around this, from simplest to more difficult…

A) Disable the Windows ‘Sync Share Service’, named “SyncShareSvc”.

B) Remove/ “Work Folders” Server Role / Windows Feature:

  • Launch Server Manager. Click “Add roles and features”.
  • Server Roles -> File and Storage Services -> File and iSCSI Services -> Work Folders

C) Or change the ports “Work Folders” use:

Edit file:

Change ports from 80 to 11180 and 443 to 11443 (or something else)…


<binding protocol=”http” bindingInformation=”*:80:” />

<binding protocol=”https” bindingInformation=”*:443:” sslFlags=”0″ />


Then from a permissions-elevated command-line (right click cmd.exe, Run as admin), run:

Netsh http add urlacl url=http://*:11180/ user=”NT Authority\LOCAL SERVICE”
Netsh http add urlacl url=https://*:11443/ user=”NT Authority\LOCAL SERVICE”


Then from a permissions-elevated command-line (right click cmd.exe, Run as admin), run:

You’ll also need to follow more instructions here:

Configure App Volumes log rolling

App Volumes Manager logs are growing continuously, after a long while taking up substantial amounts of disk space. App Volumes can be configured to roll the logs after a specified size on disk has been reached.


On the manager server:

1) Open C:\Program Files (x86)\CloudVolumes\Manager\config\log4r.yml

2) Find the section output_templates under which standard_output section exists.

3) Change parameter CV_ROLL_LOGS to 1

4) To configure the size of each log before it is rolled change the maxsize attribute in the same section. The default is 20971520 bytes (20mb)

5) You can change the amount of files to keep using the max_backups attribute. The default is 3.


NOTE: Always keep as many logs as possible, as they may be required for problem analysis. If older logs do not exist, it may be more complicated or impossible to troubleshoot a future problem.

App Volumes Broker Service Deprecated


With the new App Volumes 2.10 release please make sure you uninstall the App Volumes broker service from your Horizon View Connection Server(s). Keeping the broker service enabled after upgrading/installing 2.10 will cause users to have poor performance when logging into their VDI desktops. With the new App Volumes 2.10, you no longer have the ability to utilize this broker service as it has been removed. VMware engineering has discovered from real-world customers and internal testing the broke service doesn’t give enough benefit to increasing login speeds. With that, keep in mind that 2.10 does increase the speed of logins compared to previous versions because the engineering team has increased the commands being sent to the hypervisor.

AppVolumes and Horizon Recompose Workaround

The following is a workaround for when you are impacted by recompose loops in Horizon View and using App Volumes. VMware engineering is aware of this problem and is working on a fix. The issue discovered is when multiple AppStacks are attached to VDI desktops and a recompose is initiated. The timing between when VMDK’s are detached from a VDI desktop and when Horizon tries to execute its recompose.

  1. On your gold image
    1. Copy ‘av.cmd‘ to ‘c:\Scripts\‘ on your gold image (Scripts folder is an example location but should match the path specified in image1)
    2. Copy ‘Prep Image for Snap.bat‘ to your gold image desktop
    3. Execute the batch file “Prep Image for Snap.bat” and this will power-down the VM. Once powered-down, create a snapshot for your View environment. (What the script is doing is stopping the AppVolumes service prior to you doing a snapshot once View spin’s up replicas or a refresh it starts the service.)
  2. Modify your View pool under ‘Guest Customization’ to include the path and filename to ‘av.cmd‘ (see Image1)
  3. Select OK to save settings. 


Av recompose fix









You should be able to recompose/refresh now with no issues.

Files: https://vmware.awmdm.com/MyDevice/s/581/4b5185cb-69ed-4a8e-8923-b845dd8422c1/AV-Fix.zip

Special thanks to Matthew Mabis from PSO, End-user Computing for creating this solution for customers.


Cloning AppStacks and Modifying Scripts

Recently while working onsite with a client I discovered they needed to have local windows accounts created upon AppStack attachment as required by their application. The customer didn’t want go through process of recreating the AppStack to achieve this. I was able to solve this problem by injecting scripts into the VMDK of the AppStack. These scripts are called at the time a volume is dynamically attached or at various points during system startup and logon. They are used in order only if present in the AppStack or Writable volume. If not present in the volume the batch file will be skipped.

All batch files are in the root of the AppStack or Writable Volume. They are only accessible on a system without agent.

For example if you assign a volume to a Windows system and there is a user logged in, what you would see in chronological order are the following steps taken automatically:


runs under the Windows SYSTEM. If the volume is attached from boot, this will run when SVSERVICE starts.


startup.bat runs under the Windows SYSTEM. If the volume is attached from boot, this will run when SVSERVICE starts.


shellstart.bat runs under the Windows USER. If the volume is attached before the user logs in, this is called just before the Windows shell launches.


startup_postsvc.bat runs under the Windows SYSTEM. This will only occur if there are services or drivers on the App Stack or Writable Volume.


logon_postsvc.bat runs under the Windows USER. This will only occur if there are services or drivers on the AppStack or Writable Volume.


allvolsattached.bat runs under the Windows USER. If multiple volumes are all attached at the same time (i.e. during user logon), then this is called only once.

  These scripts may contain any scriptable actions and are used to customize Windows desktop and application actions at various points in time during the system startup and user login processes. This is to ensure AppStack and Writable Volume data will function appropriately and provide the user with the best possible experience.

These scripts are case sensitive and should be utilized and/or modified with caution.

Batch File Details:

Optional wait times for each batch file may be configured. These are just part of the agent machine. Wait times are defined in seconds and all settings are stored as REG_DWORD registry entries in the following Windows registry path.


Registry keys may also be created on the agent machine using a command line.


reg.exe add HKLM\SYSTEM\CurrentControlSet\services\svservice\Parameters /v KeyValue /t REG_DWORD /d 60

End User System Batch Files

The following is a list of each batch file used on the end user system.


– Launched under the Windows SYSTEM when a volume is dynamically attached or during system startup prior to virtualization being activated. Optional wait time key: WaitPrestartup (default do not wait).


startup.bat – Launched under the Windows SYSTEM when a volume is dynamically attached or during system startup. (Right after the volume is virtualized) Optional wait time key: WaitStartup (default do not wait).


startup_postsvc.bat – Launched under the Windows SYSTEM after services have been started on the volume. This is only called when there are services on the volume which are needing to be started (not called unless there are services on volume). Optional wait time key: WaitStartupPostSvc (default do not wait).


logon.bat – Launched under the Windows USER at logon and before Windows Explorer starts. Optional wait time key: WaitLogon (default wait until it finishes).


logon_postsvc.bat – Launched under the Windows USER after services have been started. This is only called when there are services on the volume which are needing to be started (not called unless there are services on volume). Optional wait time key: WaitLogonPostsvc (default do not wait).


shellstart.bat – Launched under the Windows USER when a volume is dynamically attached or when Windows Explorer starts. Optional wait time key: WaitShellstart (default do not wait).


allvolattached.bat – Launched after all volumes have been processed (so if user has 3 AppStacks, this will be called after all 3 have loaded). Optional wait time key: WaitAllvolattached (default do not wait).


shellstop.bat – Launched under the Windows USER when Windows session logoff is initiated, but before Windows Explorer is terminated. Optional wait time key: WaitShellstop (default do not wait).


logoff.bat – Launched under the Windows USER during Windows session logoff when Windows Explorer has terminated, but before the volume has disconnected. Optional wait time key: WaitLogoff (default do not wait).


shutdown_presvc.bat – Launched under the Windows SYSTEM when the computer is being shutdown before services have been stopped. Optional wait time key: WaitShutdownPresvc (default do not wait).


shutdown.bat – Launched under the Windows SYSTEM when the computer is being shutdown after services have been stopped. Optional wait time key: WaitShutdown (default do not wait).  

Provisioning System Batch Files

The following is a list of each batch file used on the provisioning system

post_prov.bat – Launched at the end of provisioning to conduct any one-time steps which should be performed at the end of provisioning. Invoked at the point of clicking the provisioning complete pop-up while the volume is still virtualized. Optional wait time key: WaitPostProv (default wait forever).

The steps needed to perform such an operation are outlined here.


App Volumes Update Method

**** Initial preparation







  1. Select the source AppStack and click ‘Update’
  2. Give the new AppStack a name, select the appropriate storage, append the path with the new AppStack name, and enter a description if needed.
  3. Select ‘Create’ and ‘Wait for completion’ or ‘Perform in the background’
  4. Select ‘Update’
  5. Once ‘Update’ is selected you will need to wait until the AppStack is cloned. Once completed refresh your App Volumes Manager interface.
  6. The new AppStack you created should be present and show the status of ‘Un-provisioned’.

**** Provision Updated AppStack






  1. From the App Volumes Manager interface, select ‘AppStacks’
  2. Select your newly created AppStack (the one you just modified)
  3. Select ‘Provision’
  4. Enter the name of the provisioning virtual machine. The provisioning machine is typically a clean virtual machine with patches and limited applications installed.
  5. Select the provisioning virtual machine
  6. Select ‘Provision’
  7. Select ‘Start Provisioning’
  8. Once the AppStack is attached to your provisioning machine open the console to that virtual machine
  9. You will be greeted with a dialog box that says your now in provisioning mode.
  10. Select explorer and change the view to show hidden files/folders.
  11. Navigate to “C:\SnapVolumesTemp\MountPoints”

Note: Under MountPoints you will discover links. If you go into each link you will find a set of files such as batch scripts (startup.bat, etc.) You can make your changes at this point.

  1. Once you complete your changes, re-hide hidden files/folders
  2. Select ‘Ok’ on the App Volumes dialog to finish the capture process
  3. Select ‘Yes’ to the installation complete dialog
  4. Select ‘OK’ to the next dialog box which will reboot the virtual machine
  5. Once the provisioning machine has rebooted, login to complete the process
  6. Select ‘Ok’ at the ‘Provisioning successful’ dialog box. 

**** Editing an AppStack VMDK outside the AppStack “Update” option







  1. Select a virtual machine that does NOT have App Volumes Agent installed.
  2. Edit the settings of the virtual machine and add a drive. (Edit Settings > Add… > Hard Disk > Use an existing virtual disk)
  3. Navigate through the storage tree to your newly created AppStack and select the VMDK (i.e. \cloudvolumes\apps\<your new app>\<your new app.vmdk>
  4. Select ‘OK’ on the virtual machine settings interface to commit changes
  5. You should now see a new drive letter representing the new AppStack VMDK. Proceed to make any customizations you need.
  6. Once finished, edit the settings again of the virtual machine (you can do this step with the virtual machine powered-on or off)
  7. Select the newly added hard disk (the new AppStack VMDK you added)
  8. Select the button ‘remove’
  9. Select the button ‘Remove from virtual machine’
  10. Select ‘OK’ to commit changes to the virtual machine

Note: If you receive an error message that the VMDK is in shared-mode you can do one of two options to resolve this.

  • Select ‘Rescan’ in the App Volumes Manager portal > Volumes > AppStacks tab.
  • Delete .metadata file where the VMDK resides on the datastore. This option is typically needed if you clone the AppStack from the datastore side and don’t use the Update method as outlined above.


Your AppStack is now ready to test.

App Volumes and Persistent Desktops

I wanted to communicate expected behavior when using App Volumes and Persistent desktops. Special thanks to Matthew Mabis for discovering this. When a user logs-off or reboots the VMDK of the AppStacks are detach from the users virtual machine. If you are not using the Writable Volume feature that comes with App Volumes and using AppStacks be warned that any new applications installed will vanish once a reboot operation is executed regardless of your account permissions. App Volumes forces Windows to write to a hidden share (SVROOT) regardless if you are using Writable Volumes or not. Without UIA enabled a simple task like installing FileZilla will only reside on the VM temporary until the AppStack detaches. There is no work-around with this behavior and App Volumes was designed to operate this way we discovered. The following is an example of this behavior:

Av persistent desktops img1