VMware Horizon Community
eyesonlyone
Contributor
Contributor
Jump to solution

AppStack makes Full Clone kinda "non-persistent"

Hey guys,

we have a curious problem when using appstacks on our full clones. When an AppStack is attached (not a writable volume!) everything gets reset after a restart. All files i saved locally during a session are gone after a restart ...

It´s like i mapped a writable volume and didn't reattached it after a restart.

The Problem exists with every AppStack.

Horizon View Version is 6.2

AppVolumes Version is 2.9

Hope you guys have an idea!

regards,

eyesonly

1 Solution

Accepted Solutions
Jason_Marshall
VMware Employee
VMware Employee
Jump to solution

App Volumes when used in a persistent environment will not persist user changes after a logoff or restart. This is by design in App Volumes versions 2.x. If a persistent environment is desired in conjunction with App Volumes the below requirements must be met.


Support for persistent (physical or virtual) endpoints is only given under the following constraints:

o Constant network connection to volumes location is required.

o Automatic updates for any system level processes or applications (Windows Update, Office Updater) should be disabled.

o Any updates to the OS should be scheduled with the App Volumes agent disabled or stopped and performed as a user with no volume assignments.


To stop the service:

Net stop svservice

Net stop svdriver

Perform updates

Reboot the endpoint


If disabling the service:

Sc config svservice start=disabled

Reboot

Perform updates

Sc config svservice start=auto


For user "stuff" add a Writable Volume Smiley Wink

View solution in original post

3 Replies
Jason_Marshall
VMware Employee
VMware Employee
Jump to solution

App Volumes when used in a persistent environment will not persist user changes after a logoff or restart. This is by design in App Volumes versions 2.x. If a persistent environment is desired in conjunction with App Volumes the below requirements must be met.


Support for persistent (physical or virtual) endpoints is only given under the following constraints:

o Constant network connection to volumes location is required.

o Automatic updates for any system level processes or applications (Windows Update, Office Updater) should be disabled.

o Any updates to the OS should be scheduled with the App Volumes agent disabled or stopped and performed as a user with no volume assignments.


To stop the service:

Net stop svservice

Net stop svdriver

Perform updates

Reboot the endpoint


If disabling the service:

Sc config svservice start=disabled

Reboot

Perform updates

Sc config svservice start=auto


For user "stuff" add a Writable Volume Smiley Wink

eyesonlyone
Contributor
Contributor
Jump to solution

Wow, i really hoped that's not the case :smileyconfused:.

I just wonder about the reason of this design decision? Shouldn't be a problem to let changes to the disk happen on a persistent desktop, does it?

How about mirage? will that work without disabling the appvolumes service first?

regards,

eyesonly

0 Kudos
Jason_Marshall
VMware Employee
VMware Employee
Jump to solution

This is what Mirage is designed to do. From a design perspective App Volumes is aimed at the highly managed environment. This almost always means non-persistent OS. However with some of the recent announcements, we are adding additional and expanded support in App Volumes or persistent environments.

0 Kudos