For anyone out there who might see this we've also now found that removing the "virtualize registry" lines from the snapvol.cfg in any of our AppStacks has produced noticeable improvements in both the speed of sending print jobs and using the event viewer. Not sure this is a viable configuration though, or even what the virtualize registry lines are responsible for...
1 person found this helpful
I'd be surprised if a lot of programs work with that setup I'm pretty sure the virtualed_resistry settings redirect the expected registry entries to where the registry hives are mounted from the app stack.
We were thinking the same to be honest. We've also noticed that there always tends to be an extra 'SnapVolumes-####' hive mounted in the registry on our clones. For example, if we have one single App assignment/attachment there will be 2 x 'SnapVolumes-###' Reg keys under HKLM. If we had three stacks assigned then there would be 4 of these reg keys. There seems to be a large amount of sub keys and data within them too as when exported they tend to be several hundred MB. Are you able to comment on if your environment looks like this at all?
2 people found this helpful
The extra snapvol hyve I believe is for the delta disk. It keeps track of stuff that changes and need to be removed after logoff if you don't have a writable volume.
And if you were to remark out the virtualize_registry my guess is that close to none application will work within Appvolumes. If you remark something out the Appvolumes filterr driver will not touch that specific part of Windows. We for example excluded almost all TEMP folders (see other topic) in the writable and applications do start up quicker but at the end you will always miss some stuff you need to virtualize. It's a matter of finding the perfect balance for your environment.
Thanks Ray, at least we know this behaviour is "by design". What I can't quite understand is why those registry hives contain so much data. When we export them they end up being several hundred MB and contain around 2 million lines of registry in exported form. The result of this seems to be that operations that "parse" the registry such as eventvwr or printing seems to take much longer than they do without any AppStacks attached. Printing a basic one word test doc from MS Word takes around 45 seconds to the point it spools. Without appstacks this process takes just 19s.
We always believed that the capture process would be intelligent enough to only capture changes to the registry during the app install and not capture what appears to be essentially an entire copy of the registry minus a couple of arbitrary exceptions.
Out of interest what's your printing/event viewer performance like?
We see the same behaviour in the Event Viewer but to be honest I don't use it that much as it is a stateless machine so no much usefull info inthere anyway. Normally you need the eventviewer to check what went wrong and normally the machine has been cleaned by the time you want to look up that info in eventviewer.
The reason why it is that big is due to the fact that it merges all registry keys of the machine in those hyves. If you were to browse to the location c:\snapvolumestemp where it creates the mount point you would see that it does not only contain those folders that are created or are present within the appstack, it shows all available folders on your system. There are options to look into the folders or registry hyves that are only available within that appstack but you would need to bypass the Appvolumes Filter driver for that.